DE112018007704T5

DE112018007704T5 - Modulares System für das Internet der Dinge

Info

Publication number: DE112018007704T5
Application number: DE112018007704.7T
Authority: DE
Inventors: Christopher Lucero; Khine Han; Joshua Heppner; Christopher Rossi; Hadi Sharifi; Aniekeme Udofia; Abdul Bailey; Katherine Perkins; Kevin Hudson; Roderick Kronschnabel; Neha Purushothaman
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-12-21
Filing date: 2018-12-21
Publication date: 2021-03-11
Also published as: KR20210095037A; US20210307189A1; US11653467B2; WO2020131121A1; CN113170581A

Abstract

In einigen Beispielen weist eine Internet-der-Dinge- (IoT) Vorrichtung mehrere Platinen und einen oder mehrere Verbinder zum Koppeln von IoT-Modulen mit einer oder mehreren der mehreren Platinen und zum Koppeln der mehreren Platinen miteinander auf. Die Verbinder weisen Stapelverbinder auf beiden Seiten von mindestens einigen der Platinen und mindestens einigen der mit den Platinen zu koppelnden IoT-Module auf. Die Stapelverbinder ermöglichen, die IoT-Module und die Platinen so miteinander zu koppeln, dass Platinen und Module nicht falsch eingesetzt werden können.

Description

Technisches Gebiet
Die vorliegenden Techniken betreffen allgemein Internet-der-Dinge-(IoT) Geräte und/oder IoT-Systeme.
Hintergrund
Ein aktuelle Sichtweise des Internets ist die Verbindung von Clients, wie PCs, Tablets, Smartphones, Server, digitalen Fotorahmen und vielen anderen Arten von Geräten, mit öffentlich zugänglichen Rechenzentren, die in Serverfarmen gehostet werden. Diese Sichtweise stellt jedoch nur einen kleinen Teil der Gesamtnutzung des global verbundenen Netzwerks dar. Derzeit existiert eine sehr große Anzahl verbundener Ressourcen, die jedoch nicht öffentlich zugänglich sind. Beispiele hierfür sind Unternehmensnetzwerke, private organisationseigene Steuernetzwerke, und Überwachungsnetzwerke auf der ganzen Welt, die häufig zur Gewährleistung der Anonymität Peer-to-Peer-Relais verwenden.
Es wird geschätzt, dass das Internet der Dinge (IoT) die Internetkonnektivität bis 2020 auf mehr als 15 Milliarden Geräte bringen kann. Für Organisationen können IoT-Geräte Möglichkeiten zur Überwachung, Verfolgung oder Steuerung anderer Geräte und Gegenstände, einschließlich weiterer IoT-Geräte, andere Haushalts- und Industriegeräte, Artikel in Fertigungs- und Lebensmittelproduktionsketten, und dergleichen, bereitstellen. Die Entstehung von IoT-Netzwerken hat als Katalysator für tiefgreifende Veränderungen in der Entwicklung des Internets gedient. In Zukunft wird sich das Internet wahrscheinlich von einem hauptsächlich auf Menschen ausgerichteten Werkzeug zu einer Infrastruktur entwickeln, in der Menschen möglicherweise Minderheitenakteure in einer vernetzten Welt von Geräten sind.
In dieser Hinsicht wird das Internet zu einem Kommunikationssystem für Geräte und Gerätenetzwerke, um nicht nur mit Rechenzentren, sondern auch miteinander zu kommunizieren. Die Geräte können funktionale Netzwerke oder virtuelle Geräte bilden, um Funktionen auszuführen, die sich auflösen können, sobald die Funktion ausgeführt ist. Es existiert eine Herausforderung dahingehend, zuverlässige, sichere und identifizierbare Geräte zu ermöglichen, die bei Bedarf Netzwerke bilden können, um Aufgaben zu erfüllen.
IoT-Geräte sind physische Objekte, die in einem Netzwerk kommunizieren können und Sensoren, Aktoren und andere Eingabe- /Ausgabekomponenten aufweisen können, beispielsweise um Daten zu sammeln oder Aktionen aus einer realen Umgebung auszuführen. Beispielsweise können IoT-Geräte Geräte mit geringem Stromverbrauch aufweisen, die in alltägliche Dinge, wie etwa Gebäude, Fahrzeuge, Pakete usw. eingebettet sind oder an diese angeschlossen sind, um eine zusätzliche Ebene an künstlicher sensorischer Wahrnehmung dieser Dinge bereitzustellen. IoT-Geräte sind populärer geworden, und Anwendungen, die diese Geräte verwenden, haben zugenommen.
Es wurden verschiedene Spezifikationen zum effektiveren miteinander Verbinden und Betreiben von IoT-Geräten und Anwendungsfälle von IoT-Netzwerken vorgeschlagen. Dazu gehören die Spezialisierung von Kommunikationsspezifikationen, die von Gruppen, wie dem IEEE-Institut (Institute of Electrical and Electronics Engineers), verteilt werden, und die Spezialisierung von Architekturen und Konfigurationsstandards für Anwendungsinteraktionen, die von Gruppen, wie der OCF (Open Connectivity Foundation), verteilt werden.
Figurenliste

1 veranschaulicht Verbindungen, die gemäß einigen Ausführungsformen im Internet vorhanden sein können.
2 veranschaulicht eine Netzwerktopologie für eine Anzahl von Internet-der-Dinge- (IoT) Netzwerken, die über Backbone-Verbindungen mit Gateways gekoppelt sind, gemäß einigen Ausführungsformen.
3 veranschaulicht ein Cloud-Computing-Netzwerk oder eine Cloud in Kommunikation mit einer Anzahl von IoT-Geräten, gemäß einigen Ausführungsformen.
4 veranschaulicht ein Cloud-Computing-Netzwerk oder eine Cloud in Kommunikation mit einem Maschennetzwerk von IoT-Geräten, das als Fog-Gerät bezeichnet werden kann, und die am Rand der Cloud arbeiten, gemäß einigen Ausführungsformen.
5, die 5A und 5B aufweist, veranschaulicht eine Plattform oder ein System gemäß einigen Ausführungsformen.
6, die 6A und 6B aufweist, veranschaulicht eine Plattform oder ein System gemäß einigen Ausführungsformen.
7 veranschaulicht ein System gemäß einigen Ausführungsformen.
8 veranschaulicht Komponenten-Plugin-Module (CPMs) gemäß einigen Ausführungsformen.
9 veranschaulicht ein System gemäß einigen Ausführungsformen.
10 veranschaulicht ein System gemäß einigen Ausführungsformen.
11 veranschaulicht ein System gemäß einigen Ausführungsformen.
12 veranschaulicht ein System gemäß einigen Ausführungsformen.
13 veranschaulicht ein System gemäß einigen Ausführungsformen.
14 veranschaulicht ein System gemäß einigen Ausführungsformen.
15 veranschaulicht ein System gemäß einigen Ausführungsformen.
16 veranschaulicht ein System gemäß einigen Ausführungsformen.
17 veranschaulicht ein System gemäß einigen Ausführungsformen.
18 veranschaulicht ein System gemäß einigen Ausführungsformen.
19 veranschaulicht ein System gemäß einigen Ausführungsformen.
20 veranschaulicht ein System gemäß einigen Ausführungsformen.
21 veranschaulicht ein System gemäß einigen Ausführungsformen.
22 veranschaulicht ein System gemäß einigen Ausführungsformen;
23 veranschaulicht ein System gemäß einigen Ausführungsformen;
24 ist ein Blockdiagramm eines Beispiels von Komponenten, die in einem IoT-Gerät vorhanden sein können, gemäß einigen Ausführungsformen.
25 ist ein Blockdiagramm eines oder mehrerer nichtflüchtiger maschinenlesbarer Medien, die Code aufweisen, um einen oder mehrere Prozessoren anzuweisen, Anweisungen gemäß einigen Ausführungsformen zu implementieren.

In der gesamten Offenbarung und in den Figuren werden, um auf ähnliche Komponenten und Merkmale zu verweisen, die gleichen Bezugszeichen verwendet. Die Nummern der 100er-Reihe beziehen sich auf Merkmale, die ursprünglich in 1 gefunden wurden; Nummern in der Serie 200 beziehen sich auf Merkmale, die ursprünglich in 2 gefunden wurden; und so weiter.
Beschreibung der Ausführungsformen
Einige Ausführungsformen betreffen Internet-der-Dinge- (IoT) Geräte und/oder IoT-Systeme. Beispielsweise wird in einigen Ausführungsformen eine Plattform für IoT-Sensoren bereitgestellt. Die Plattform kann beispielsweise ein IoT-Sensor-Hub sein.
In einigen Ausführungsformen können Formfaktoren verwendet werden, um eine Plug-and-Play-Konnektivität einer Vielzahl von Systemkomponenten oder -modulen bereitzustellen (wie beispielsweise Rechenmodule, Konnektivitätsmodule und/oder Sensormodule). Diese Art von Plug-and-Play-Konnektivität kann bereitgestellt werden, um IoT-Edge-Nutzungsmodelle zu unterstützen.
In einigen Ausführungsformen können infinite Bausteine verwendet werden, um Module so zu konfigurieren, dass Signale ohne Kurzschluss durchgeleitet werden können. In einigen Ausführungsformen können Module auf austauschbare und/oder erweiterbare Weise verwendet werden. Signale können ungeachtet, wo sie in der Plattform platziert werden, aufrechterhalten werden. Module können so angeordnet werden, dass sie nicht falsch platziert werden können, und korrekte Signale aufrechterhalten werden. Außerdem kann in einigen Ausführungsformen die Anzahl von Sensoren auf eine beliebige erforderliche Anzahl von Sensoren erweitert werden. In ähnlicher Weise kann auch die Anzahl der Konnektivitätsmodule (und/oder Funkgeräte) und/oder die Anzahl der Rechenmodule auf eine beliebige erforderliche Anzahl erweitert werden. Entwickler können ein Modul in der Plattform so entwickeln, dass es problemlos in das Ökosystem integriert werden kann. In einigen Ausführungsformen kann Strom beispielsweise durch Batterie-, Solar- oder Wandstrom bereitgestellt werden. In einigen Ausführungsformen können Module, wie Funkgeräte oder Sensoren, auf modulare Weise zu der Plattform hinzugefügt werden.
In einigen Ausführungsformen kann die mechanische und Signalstruktur der Plattform auf eine Weise angeordnet werden, die absolut sicher ist. In einigen Ausführungsformen ist Software auf eine Weise enthalten, dass Module aktualisiert werden können (beispielsweise über eine drahtlose und/oder drahtgebundene Übertragung). Aktualisierungen können auf eine Weise gesendet werden, dass das Upgrade an das richtige Modul in der Plattform geht (in einigen Ausführungsformen kann ein Upgrade beispielsweise direkt an das richtige Modul gehen, statt ein anderes Modul zu durchlaufen).
In einigen Ausführungsformen können skalierbare, stapelbare und/oder konfigurierbare Module (beispielsweise externe Sensormodule, Funkmodule, Prozessormodule usw.) erstellt werden. In einigen Ausführungsformen kann jedes der Module eine Mikroprozessorsteuereinheit (MCU) aufweisen. Ein flexibles Framework ermöglicht unbegrenzte Anwendungsfälle von Interoperabilität. In einigen Ausführungsformen kann ein farbcodiertes System aus stapelbaren, intelligenten Modulen mit mehreren MCUs (Mikroprozessorsteuereinheiten), Funkgeräten und Sensoren verwendet werden. In einigen Ausführungsformen können modulare Schaltplan- und Layouttechniken eine schnelle Umwandlung von Mehrplatinendesigns in integrierte monolithische Platinendesigns und/oder System-in-Gehäuse- (SiP) Designs ermöglichen. In einigen Ausführungsformen kann ein flexibles, lose gekoppeltes Firmware-Modul-Framework eine Möglichkeit bieten, Firmware-Komponenten zusammenzubringen, die von verteilten Entwicklungsteams entwickelt wurden. Dies kann dazu beitragen, die Codeentwicklungs- und Integrationszeit zu verkürzen.
In einigen Ausführungsformen wird eine Architektur implementiert, die sehr einfach zu skalieren ist und daher in der Lage ist, Low-End-Systeme, wie Bare-Metal-MCU-Designs, zu unterstützen, und auch in der Lage ist, High-End-MCU-basierte eingebettete Systeme, die ein Echtzeit-Betriebssystem (RTOS) verwenden, zu unterstützen. In einigen Ausführungsformen können Plug-and-Play-Firmware-Bausteine verwendet werden, um die visuelle Firmware-Programmierung unter Verwendung grundlegender Firmware-Entwicklungs-Plugins zu unterstützen. Einfaches Ziehen und Ablegen von Firmware-Komponenten kann implementiert werden, um Firmware-Images unter Verwendung einer grafischen Benutzeroberfläche (GUI) zu erzeugen, ohne dass beispielsweise Glue-Code geschrieben werden muss.
In einigen Ausführungsformen ermöglicht ein modulares Mehrplatinen-System ein Mischen und Anpassen unterschiedlicher aufgabenspezifischer Platinen, wie etwa IoT-Platinen, um eine bestimmte Lösung für einen gegebenen Anwendungsfall zu erzeugen. Diese Systeme können beispielsweise für IoT-Edge- oder Gateway-Lösungen verwendet werden. In einigen Ausführungsformen kann das modulare System ein Plugin-Sensormodul für ein Gateway sein, beispielsweise mit Sensordatensammlung und Rechenressourcen, die an einem Zugangspunkt eingespeist werden. Die drahtgebundene Kommunikation kann von dem System unterstützt werden. Die drahtlose Kommunikation mit entfernten Sensorknoten und mehreren Funkgeräten kann ebenfalls von dem System unterstützt werden.
In einigen Ausführungsformen kann eine modulare Lösung eine Bewertung von Modulen ermöglichen und eine Datensammlung ohne größere Investition bereitstellen. Sobald eine optimale Konfiguration basierend auf Prototypisierung und Testen von modularer Anordnungen bestimmt wurde, kann eine finale hochintegrierte Lösung implementiert werden, die für eine Herstellung in hohen Stückzahlen kostenoptimiert ist. Außerdem kann der modulare Aufbau zu einer Standardisierung durch die IoT-Industrie um ein modulares Framework führen.
Die 1 bis 4 weisen beispielhafte Betriebsumgebungen auf, wie Internet-der-Dinge- (IoT) Umgebungen, in denen die hier beschriebenen Prinzipien verwendet werden können. Die beispielhaften Betriebsumgebungen der 1 bis 4 können hierin beschriebene Prinzipien verwenden, die ein IoT-Netzwerk oder -System betreffen (beispielsweise IoT-Netzwerke, IoT-Systeme, IoT-Geräte, Fog-Geräte (bzw. „Fog Devices“), Fog-Netzwerke, Edge-Geräte (bzw. „Edge Devices“), Edge-Netzwerke, Foglets, usw.), wie in den Zeichnungen veranschaulicht und in Bezug darauf beschrieben wird.
Das Internet der Dinge (IoT) ist ein System, in dem eine große Anzahl von Computergeräten miteinander und mit einem Kommunikationsnetz (z. B. dem Internet) verbunden sind, um eine Funktionalität, wie Datenerfassung und -verwendung, auf sehr niedriger Ebene in Netzwerken bereitzustellen. Niedrige Ebenen deutet auf Geräte hin, die sich an oder in der Nähe von Rändern bzw. Kanten („Edges“) von Netzwerken befinden, wie etwa die letzten Geräte vor dem Ende des Netzwerks. Wie hierin verwendet, kann ein IoT-Gerät ein Gerät aufweisen, das eine Funktion, wie Erfassen oder Steuern, unter anderem, in Kommunikation mit anderen IoT-Geräten und einem Kommunikationsnetzwerk ausführt. Das IoT-Gerät kann ein autonomes Gerät oder ein halbautonomes Gerät aufweisen, das dazu konfiguriert ist, eine oder mehrere Funktionen auszuführen. IoT-Geräte können häufig in Bezug auf Speicher, Größe oder Funktionalität eingeschränkt sein, wodurch ermöglicht wird, größere Anzahlen zu ähnlichen Kosten auf einer kleineren Anzahl größerer Geräte zu installieren. Jedoch kann ein IoT-Gerät ein Smartphone, ein Laptop, ein Tablet, ein PC und/oder ein anderes größeres Gerät sein. Ferner kann ein IoT-Gerät ein virtuelles Gerät sein, wie etwa eine Anwendung auf einem Smartphone oder einem anderen Rechengerät. IoT-Geräte können IoT-Gateways aufweisen, die zum Koppeln von IoT-Geräten mit anderen IoT-Geräten und Cloud-Anwendungen, zur Datenspeicherung, Prozesssteuerung und dergleichen verwendet werden.
Netzwerke von IoT-Geräten können kommerzielle und Heimgeräte aufweisen, wie etwa Wasserverteilungssysteme, Stromverteilungssysteme, Pipeline-Steuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Auf die IoT-Geräte kann über eine Steuerung, wie etwa ein Computer, Server und andere Systeme, zugegriffen werden, beispielsweise um Systeme zu steuern oder auf Daten zuzugreifen. Die Steuerung und die IoT-Geräte können entfernt voneinander angeordnet sein.
Das Internet kann dazu konfiguriert werden, Kommunikationen mit einer großen Anzahl von IoT-Geräten bereitzustellen. Dementsprechend sind, wie hierin beschrieben, eine Reihe von Innovationen für das zukünftige Internet darauf ausgelegt, den Bedarf an Netzwerkschichten von zentralen Servern über Gateways bis hin zu Edge-Geräten abzudecken, ungehindert zu wachsen, verbundene Ressourcen zu entdecken und zugänglich zu machen, und die Fähigkeit, verbundene Ressourcen auszublenden und zu unterteilen, zu unterstützen. Es kann eine beliebige Anzahl von Netzwerkprotokollen und Kommunikationsstandards verwendet werden, wobei jedes Protokoll und jeder Standard so ausgelegt ist, dass bestimmte Ziele erreicht werden. Darüber hinaus sind die Protokolle Teil der Struktur, die für Menschen zugängliche Dienste unterstützt, die unabhängig von Ort, Zeit oder Raum arbeiten. Die Innovationen weisen Bereitstellung von Diensten und die dazugehörige Infrastruktur, wie Hardware und Software, auf. Die Dienste können gemäß den in Dienstgüte- und Diensterbringungsvereinbarungen spezifizierten Dienstgüte- (QoS) Bedingungen bereitgestellt werden. Die Verwendung von IoT-Geräten und -Netzwerken stellt eine Reihe neuer Herausforderungen in einem heterogenen Konnektivitätsnetzwerk dar, das eine Kombination von drahtgebundenen und drahtlosen Technologien, wie in den 1 und 2 dargestellt wird, aufweist.
1 ist eine Zeichnung von Verbindungen, die zwischen dem Internet 100 und IoT-Netzwerken vorhanden sein können, gemäß einigen Ausführungsformen. Die Verbindungen können kleinere Netzwerke 102, bis hinunter zu dem einzelnen IoT-Gerät 104, mit dem Backbone 106 des Internets 100 koppeln. Um die Zeichnung zu vereinfachen, ist nicht jedes Gerät 104, oder andere Objekt, beschriftet.
In 1 sind Top-Level-Anbieter, die als Tier-1- („T1“) Anbieter 108 bezeichnet werden können, durch den Backbone 106 des Internets mit anderen Anbietern, wie dem Sekundär- oder Tier-2- („T2“) Anbieter 110, gekoppelt. In einigen Aspekten kann der Backbone 106 Glasfaserverbindungen aufweisen. In einem Beispiel kann ein T2-Anbieter 110 beispielsweise durch weitere Verbindungen, durch Mikrowellenkommunikation 114, oder durch andere Kommunikationstechnologien, an einen Turm 112 eines LTE-Mobilfunknetzes koppeln. Der Turm 112 kann über eine LTE-Kommunikationsverbindung 116, beispielsweise über einen zentralen Knoten 118 mit einem Maschennetzwerk, das IoT-Geräte 104 aufweist, gekoppelt sein. Die Kommunikation zwischen den einzelnen IoT-Geräten 104 kann auch auf LTE-Kommunikationsverbindungen 116 basieren.
In einem anderen Beispiel kann eine Hochgeschwindigkeits-Aufwärtsstrecke 119 einen T2-Anbieter 110 mit einem Gateway 120 koppeln. Eine Anzahl von IoT-Geräten 104 kann mit dem Gateway 120 und miteinander über das Gateway 120, beispielsweise über BLE- (Bluetooth® Low Energy) Verbindungen 122, kommunizieren.
Der Backbone 106 kann niedrigere Ebenen von Dienstanbietern, wie etwa Tier-3- („T3“) Anbieter 124, mit dem Internet koppeln. Ein T3-Anbieter 124 kann als allgemeiner Internetdienstanbieter (ISP) angesehen werden, der beispielsweise Zugang von einem T2-Anbieter 110 zu dem Backbone 106 kauft und einen Zugriff an ein Unternehmensgateway 126 und andere Kunden bereitstellt.
Von dem Unternehmensgateway 126 ausgehend kann ein drahtloses lokales Netzwerk (WLAN) verwendet werden, um über Wi-Fi®-Verbindungen 128 mit IoT-Geräten 104 zu kommunizieren. Eine Wi-Fi-Verbindung 128 kann auch dazu verwendet werden, um mit einem Niederenergie-Weitbereichs- (LPWA) Gateway 130 zu koppeln, das mit IoT-Geräten 104 über LPWA-Verbindungen 132, beispielsweise kompatibel mit der von der LoRa-Allianz publizierten LoRaWAN-Spezifikation, kommunizieren kann.
Der T3-Anbieter 124 kann auch über ein Koordinatorgerät 136, das mit dem T3-Anbieter 124 unter Verwendung einer beliebigen Anzahl von Kommunikationsverbindungen kommuniziert, wie etwa einer LTE-Mobilfunkverbindung, einer LPWA-Verbindung oder einer auf dem IEEE 802.15.4-Standard basierenden Verbindung 138, wie etwa Zigbee®, Zugriff auf ein Maschennetzwerk 134 gewähren. Andere Koordinatorgeräte 136 können eine Kette von Verbindungen bereitstellen, die einen oder mehrere Clusterbäume von verknüpften Geräten bilden.
In einigen Aspekten weisen ein oder mehrere IoT-Geräte 104 den geeigneten Sendeempfänger für die Kommunikation mit anderen Geräten auf. Ferner können ein oder mehrere IoT-Geräte 104 andere Funk-, optische oder akustische Sendeempfänger sowie drahtgebundene Netzwerkschnittstellen für eine Kommunikation unter Verwendung zusätzlicher Protokolle und Frequenzen aufweisen. In einigen Aspekten weisen ein oder mehrere IoT-Geräte 104 Komponenten auf, die in Bezug auf 12 beschrieben werden.
Die Technologien und Netzwerke können das Wachstum von Geräten und Netzwerken ermöglichen. Da die Technologien wachsen, kann das Netzwerk für eine Selbstverwaltung, Funktionsentwicklung und/oder Zusammenarbeit, ohne dass ein direktes Eingreifen des Menschen erforderlich ist, entwickelt werden. Somit können die Technologien Netzwerke dazu in die Lage versetzen, ohne zentral gesteuerte Systeme zu funktionieren. Die hier beschriebenen Technologien können die Netzwerkverwaltungs- und Betriebsfunktionen über die aktuellen Fähigkeiten hinaus automatisieren. Ferner können die Ansätze die Flexibilität bereitstellen, eine zentralisierte Steuerung ohne menschliches Eingreifen, eine zentralisierte Steuerung, die automatisiert ist, oder beliebige Kombinationen davon zu haben.
2 ist eine Zeichnung einer Netzwerktopologie 200, die für eine Anzahl von Internet-der-Dinge- (IoT) Netzwerken verwendet werden kann, die über Backbone-Verbindungen 202 mit Gateways 204 gekoppelt sind, gemäß einigen Ausführungsformen. Gleich nummerierte Gegenstände sind wie in Bezug auf 1 beschrieben. Um die Zeichnung zu vereinfachen, ist nicht jedes Gerät 104 oder jede Kommunikationsverbindung 116, 122, 128 oder 132 beschriftet. Die Backbone-Verbindungen 202 können eine beliebige Anzahl von drahtgebundenen oder drahtlosen Technologien aufweisen und können Teil eines lokalen Netzwerks (LAN), eines Weitverkehrsnetzwerks (WAN) oder des Internets sein.
Obwohl die Topologien in 2 Nabe und Speiche sind, und die Topologien in 1 Peer-to-Peer sind, kann beobachtet werden, dass diese nicht in Konflikt stehen, sondern dass Peer-to-Peer-Knoten sich durch Gateways wie Nabe und Speiche verhalten können. In 2 kann auch beobachtet werden, dass eine Subnetz-Topologie mehrere Gateways aufweisen kann, wodurch sie eher eine Hybridtopologie als eine reine Nabe-und-Speiche-Topologie (oder als eine strikte Nabe-und-Speiche-Topologie) darstellt.
Die Netzwerktopologie 200 kann eine beliebige Anzahl von Arten von IoT-Netzwerken aufweisen, wie etwa ein Maschennetzwerk 206, das BLE-(Bluetooth® Low Energy) Verbindungen 122 verwendet. Andere IoT-Netzwerke, die vorhanden sein können, weisen ein WLAN-Netzwerk 208, ein zellulares Netzwerk 210 und ein LPWA-Netzwerk 212 auf. Jedes dieser IoT-Netzwerke kann Möglichkeiten für neue Entwicklungen bereitstellen, wie hierin beschrieben wird.
Beispielsweise kann die Kommunikation zwischen IoT-Geräten 104, wie etwa über die Backbone-Verbindungen 202, durch ein dezentrales System zur Authentifizierung, Autorisierung und Abrechnung (AAA) geschützt werden. In einem dezentralen AAA-System können verteilte Zahlungs-, Kredit-, Auditierungs-, Autorisierungs-, Vermittlungs-, Arbitrierungs- und Authentifizierungssysteme über eine verbundene heterogene Infrastruktur implementiert werden. Dadurch wird Systemen und Netzwerken ermöglicht, sich in Richtung eines autonomen Betriebs zu bewegen.
Bei diesen Arten von autonomen Operationen können Maschinen Verträge für menschliche Ressourcen abschließen und Partnerschaften mit anderen Maschinennetzwerken aushandeln. Dies kann es ermöglichen, gemeinsame Ziele und eine ausgewogene Servicebereitstellung gegenüber skizzierten geplanten Dienstebenen-Vereinbarungen zu erreichen, sowie Lösungen zu erreichen, die Zählungen, Messungen sowie Rückverfolgbarkeit und Nachverfolgbarkeit bereitstellen. Die Erzeugung neuer Prozesskettenstrukturen und -verfahren kann es Möglich machen, eine Vielzahl von Diensten zu erzeugen, nach Werten abzubauen, und aufzugeben, ohne ein menschliches Eingreifen.
Ferner können die IoT-Netzwerke weiter verbessert werden, indem Sensortechnologien, wie etwa Ton, Licht, elektronischer Verkehr, Gesichts- und Mustererkennung, Geruch und Vibration, in die autonomen Organisationen integriert werden. Die Integration von sensorischen Systemen kann eine systematische und autonome Kommunikation und Koordination der Dienstbereitstellung in Bezug auf vertragliche Serviceziele, Orchestrierung und QoS-basiertes Schwärmen, und Zusammenführen von Ressourcen ermöglichen.
Das Maschennetzwerk 206 kann durch Systeme erweitert werden, die inline Daten-zu-Informationen-Transformationen durchführen. Beispielsweise können sich selbst bildende Ketten von Verarbeitungsressourcen, die ein Mehrverbindungsnetzwerk umfassen, die Umwandlung von Rohdaten in Informationen auf effiziente Weise verteilen. Dies kann eine solche Funktionalität als eine erste Stufe ermöglichen, die eine erste numerische Operation ausführt, bevor das Ergebnis an eine andere Stufe übergeben wird, wobei die nächste Stufe dann eine andere numerische Operation ausführt und dieses Ergebnis an eine andere Stufe weitergibt. Das System kann die Möglichkeit bereitstellen, zwischen Assets und Ressourcen und der jeweiligen dazugehörigen Verwaltung zu differenzieren. Darüber hinaus können die richtigen Komponenten von infrastruktur- und ressourcenbasierten Vertrauens- und Dienstindizes eingefügt werden, um die Datenintegrität und Qualitätssicherung zu verbessern und eine Metrik des Datenvertrauens bereitzustellen.
Wie hierin beschrieben, kann das WLAN-Netzwerk 208 Systeme verwenden, die eine Standardkonvertierung durchführen, um eine Multi-Standard-Konnektivität bereitzustellen, wodurch IoT-Geräte 104, die unterschiedliche Protokolle verwenden, kommunizieren können. Weitere Systeme können eine nahtlose Interkonnektivität über eine Multi-Standard-Infrastruktur hinweg bereitstellen, die sichtbare Internetressourcen und versteckte Internetressourcen umfasst.
Kommunikationen in dem zellularen Netzwerk 210 können durch Systeme verbessert werden, die Daten auslagern, die Kommunikation auf entferntere Geräte ausdehnen, oder beides. Das LPWA-Netzwerk 212 kann Systeme aufweisen, die Nicht-Internetprotokoll- (IP) zu IP-Verbindungen, Adressierung und Routing durchführen.
3 ist eine Zeichnung 300 eines Cloud-Computing-Netzwerks oder einer Cloud 302 in Kommunikation mit einer Anzahl von Internet-der-Dinge-(IoT) Geräten, gemäß einigen Ausführungsformen. Die Cloud 302 kann das Internet darstellen, oder kann ein lokales Netzwerk (LAN) sein, oder ein Weitverkehrsnetzwerk (WAN), wie etwa ein proprietäres Netzwerk für ein Unternehmen, oder ein Intranet. Die IoT-Geräte können eine beliebige Anzahl unterschiedlicher Gerätetypen aufweisen, die in verschiedenen Kombinationen gruppiert sind. Ferner können, wie hierin verwendet, die IoT-Geräte eine beliebige Anzahl anderer Arten von Geräten aufweisen, wie etwa einen Personal Computer, ein Tablet, ein Smartphone, einen Smart-Fernseher, und dergleichen. Beispielsweise kann eine Verkehrssteuerungsgruppe 306 IoT-Geräte entlang von Straßen in einer Stadt aufweisen. Diese IoT-Geräte können Ampeln, Verkehrsflussmonitore, Kameras, Wettersensoren, und dergleichen aufweisen. Die Verkehrssteuerungsgruppe 306 oder andere Untergruppen können über drahtlose Verbindungen 308, wie LPWA-Verbindungen und dergleichen, mit der Cloud 302 in Kommunikation stehen. Ferner kann ein drahtgebundenes oder drahtloses Subnetz 312 es den IoT-Geräten ermöglichen, miteinander zu kommunizieren, beispielsweise über ein lokales Netzwerk (LAN), ein drahtloses lokales Netzwerk (WLAN), und dergleichen. Die IoT-Geräte können ein anderes Gerät, wie etwa ein Gateway 310, dazu verwenden, um mit der Cloud 302 zu kommunizieren. In einigen Beispielen kann das Subnetz 312 eines oder mehrere der IoT-Geräte unter Verwendung eines drahtgebundenen Netzwerks mit dem Gateway 310 koppeln.
Jedes der IoT-Geräte kann auch einen oder mehrere Server (nicht gezeigt) verwenden, die betriebsmäßig entlang des Gateways 310 oder zwischen der Gruppe 306 und dem Gateway 310 angeordnet sind, um die Kommunikation der Gruppe 306 mit der Cloud 302 oder mit dem Gateway 310 zu erleichtern. Beispielsweise kann der eine oder die mehreren Server als Netzwerkzwischenknoten arbeiten, um eine lokale Edge-Cloud- oder Fog-Implementierung inmitten eines lokalen Netzwerks zu unterstützen.
Die Netzwerktopologie kann verschiedene Arten von IoT-Netzwerken aufweisen, wie etwa ein Maschennetzwerk über BLE- (Bluetooth® Low Energy) Verbindungen. Andere Arten von IoT-Netzwerken können ein drahtloses lokales Netzwerk (WLAN) zur Kommunikation mit IoT-Geräten über IEEE 802.11- (Wi-Fi®) Verbindungen und ein Mobilfunknetz zur Kommunikation mit IoT-Geräten über ein LTE/LTE-A (4G) oder 5G-Mobilfunknetz, und ein LPWA-Netzwerk aufweisen. Ein LPWA-Netzwerk kann mit der von der LoRa-Allianz erlassenen Langreichweiten-Weitbereichsnetzwerk- (LoRaWAN™) Spezifikation kompatibel sein. Die Netzwerktopologie oder das/die IoT-Netzwerk(e) können IPv6 über ein Niederenergie-Weitbereichsnetzwerke-(LPWAN) Netzwerk aufweisen, das mit einer von der IETF (Internet Engineering Task Force) erlassenen Spezifikation kompatibel ist. Ferner können die jeweiligen IoT-Netzwerke über mehrere Kommunikationsverbindungen, wie etwa eine LTE-Mobilfunkverbindung, eine LPWA-Verbindung oder einer auf dem IEEE 802.15.4-Standard basierenden Verbindung, wie etwa Zigbee®, und so weiter, mit einem externen Netzwerkanbieter (z. B. einem Tier-2- oder Tier-3-Anbieter) kommunizieren. Die jeweiligen IoT-Netzwerke können auch über Netzwerk- und Internetanwendungsprotokolle, wie etwa CoAP (Constrained Application Protocol) betrieben werden. Die jeweiligen IoT-Netzwerke können auch in Koordinatorgeräte integriert werden, die eine Kette von Verbindungen bereitstellen, die ein Clusterbaum von verknüpften Geräten und Netzwerken bilden.
Obwohl drahtlose Netzwerke und drahtgebundene Netzwerke, wie LPWA-Verbindungen, optische Verbindungen und dergleichen, beschrieben werden, kann angemerkt werden, dass jede Art von Netzwerk verwendet werden kann, um die Geräte miteinander oder mit einem Gateway 310 zu koppeln. Ein Netzwerk oder eine zusammengesetzte Gruppe von Geräten können sowohl drahtgebundene als auch drahtlose Verbindungen aufweisen und beide gleichzeitig zwischen Knoten, Peers und Gateway-Geräten verwenden. Ferner kann das Netzwerk oder die zusammengesetzte Gruppe von Geräten drahtgebundene Netzwerke, drahtlose Netzwerke oder beides, um mit der Cloud zu kommunizieren, und beliebige Computergeräte mit höherer Leistung, die möglicherweise teilnehmen, um Dienste oder Unterstützung für das, was hier offenbart ist, bereitzustellen, verwenden. Somit kann jede Verbindung 308 oder jedes Netzwerk 312 eine drahtgebundene Verbindung oder eine drahtlose Verbindung verwenden. Ferner können IoT-Geräte ohne Verwendung eines Gateways 310 in direkter Kommunikation mit anderen Geräten in der Cloud 302 stehen. Außerdem können die Verbindungen 308 optische Signalpfade zwischen sowohl IoT-Geräten und der Cloud 302 als auch den Gateways 310 verwenden, einschließlich der Verwendung von MUXing/DeMUXing-Komponenten, die die Verbindung der verschiedenen Geräte erleichtern.
IoT-Geräte können entfernte Wetterstationen 314, lokale Informationsterminals 316, Alarmsysteme 318, Geldautomaten 320, Alarmtafeln 322 oder sich bewegende Fahrzeuge, wie Notfallfahrzeuge 324 oder andere Fahrzeuge 326, aufweisen, unter vielem anderem. Jedes dieser IoT-Geräte kann mit anderen IoT-Geräten, mit Servern 304, oder mit beiden, kommunizieren.
Wie aus 3 ersichtlich ist, kann eine große Anzahl von IoT-Geräten über die Cloud 302 kommunizieren. Dies kann es unterschiedlichen IoT-Geräten ermöglichen, Informationen autonom an andere Geräte bereitzustellen oder von diesen anzufordern. Beispielsweise kann die Verkehrssteuerungsgruppe 306 eine aktuelle Wettervorhersage von einer Gruppe entfernter Wetterstationen 314 anfordern, die die Vorhersage ohne menschliches Eingreifen bereitstellen können. Ferner kann ein Notfallfahrzeug 324 von einem Geldautomaten 320 alarmiert werden, dass ein Einbruch im Gange ist. Wenn das Notfallfahrzeug 324 in Richtung des Geldautomaten 320 fährt, kann es auf die Verkehrssteuerungsgruppe 306 zugreifen, um eine Freigabe für den Ort anzufordern, beispielsweise durch auf Rot schaltende Ampeln, um den Querverkehr an einer Kreuzung in ausreichender Zeit für das Notfallfahrzeug 324 zu blockieren, um ungehinderten Zugang zu der Kreuzung zu haben.
Wie hierin beschrieben, können einige der IoT-Geräte, wenn sich Bedingungen ändern, höhere Belastungen erfahren, was zu einer höheren Latenz, einer verringerten Leistung, oder zu Datenverlust führt. Wenn sich beispielsweise das Einsatzfahrzeug 324 der Kreuzung nähert, kann die erhöhte Kommunikation zwischen Ampeln Steuerungen in den Ampeln überlasten. Dementsprechend kann die Verkehrssteuerungsgruppe 306 Vorgänge, wie eine Ampelsteuerung, von den Ampeln auf andere Geräte in der Verkehrssteuerungsgruppe 306, wie etwa Datenaggregatoren, Server oder andere Geräte, verlagern. Diese Geräte können sich lokal in der Verkehrssteuerungsgruppe 306 befinden, oder es wird über ein Netzwerk darauf zugegriffen. Die zur Implementierung der Anwendung verwendeten Geräte können die Systeme an dem Einsatzfahrzeug 324 selbst aufweisen.
Cluster von IoT-Geräten, wie etwa die entfernten Wetterstationen 314 oder die Verkehrssteuerungsgruppe 306, können dafür ausgestattet sein, mit anderen IoT-Geräten sowie mit der Cloud 302 zu kommunizieren. Dies kann es den IoT-Geräten ermöglichen, ein Ad-Hoc-Netzwerk zwischen den Geräten zu bilden, um ihnen zu ermöglichen, als einzelnes Gerät zu fungieren, das als Fog-Gerät bezeichnet werden kann. Das Fog-Gerät wird in Bezug auf 4 weiter diskutiert.
4 ist eine Zeichnung 400 eines Cloud-Computing-Netzwerks oder einer Cloud 302 in Kommunikation mit einem Netzwerk (beispielsweise einem Maschennetzwerk) von IoT-Geräten, die als Fog-Gerät 402 bezeichnet werden können, die am Rand der Cloud 302 arbeiten, gemäß einigen Ausführungsformen. Gleich nummerierte Gegenstände sind wie in Bezug auf 3 beschrieben. Wie hierin verwendet, ist ein Fog-Gerät 402 eine Gruppe von Geräten, die gruppiert werden können, um eine bestimmte Funktion auszuführen, wie, unter anderem, Verkehrssteuerung, Wettersteuerung, Anlagensteuerung, Hausüberwachung, und dergleichen.
Objekte, wie die IoT-Geräte, können interagieren, um eine größere Funktion, ein Ziel, oder einen Workflow zu erreichen, beispielsweise um ein Fog-Gerät zu bilden. Objekte können hinsichtlich ihres Typs, z. B. der ausgeführten Funktion, und Instanz, z. B. Anwesenheit, identifiziert werden. Mehrere Objektinstanzen können dieselbe Typidentität, jedoch eindeutige Instanzidentitäten, haben. Ferner können mehrere Objektinstanzen in Gruppen organisiert sein, in denen eine Instanz der Gruppierung eine Identität haben kann. Eine Gruppe von Objekten, die aufgrund ihres Typs, z. B. Funktion, Status und Schnittstellensemantik, auf eine bestimmte Weise interagieren, können ein zusammengesetztes Objekt darstellen. Die Zusammensetzung selbst kann eine Typ- und Instanzabstraktion aufweisen. Daher folgen zusammengesetzte Objekte denselben Identitätsregeln wie atomare Objekte. Die Zusammensetzung mit Typ- und Instanzeigenschaften ermöglicht eine Objekterweiterbarkeit durch Zusammensetzung.
Das Objekt kann so lange andauern wie ein einzelnes Gerät, wie etwa ein Kühlschrank, oder nur bis eine aktuelle Funktion abgeschlossen ist. Beispielsweise kann ein Kühlschrank als ein zusammengesetztes Objekt oder ein Fog-Gerät 402 angesehen werden, das aus mehreren anderen Objekten besteht, wie etwa einem Licht, einem Kompressor, einem Temperatursensor, einem Thermostat, einem Wasserspender, einer Eismaschine und dergleichen. Die anderen Objekte können jeweils atomar sein oder können selbst zusammengesetzte Objekte sein. Beispielsweise kann eine Eismaschine ein zusammengesetztes Objekt sein, das aus atomaren Objekten gebildet ist, wie etwa einem Temperatursensor, einem Thermostat, einem magnetisch betätigtem Wasserventil, einem Zeitgeber, einer Eisschale und dergleichen. Ein Beispiel für ein virtuelles zusammengesetztes Objekt oder ein Fog-Gerät 402, das aus einer Anzahl physischer Geräte besteht, ist die hier beschriebene Kreuzung und das Notfallcluster.
Dementsprechend kann die Objektidentität im Kontext von drei Abstraktionen verstanden werden: Objektinstanz, Objekttyp und Metaidentität. Eine Objektinstanz ist ein Rechenelement, das endliche Ressourcen, wie Speicher, CPU, Bandbreite, Status, und dergleichen, belegt. Die Objektinstanziierung hat einen Lebenszyklus, der das Erzeugen, Mutieren und Löschen umfasst. Ein Objekttyp ist ein logisches Konstrukt, das erwartetes oder mögliches Verhalten, Zustände und Zusammensetzung deklariert. Der Objekttyp kann Einschränkungen für das Verhalten und die Interaktion von Objekten beim Instanziieren festlegen. Der Objekttyp kann auch die Arten von Anforderungen angeben, auf die das Objekt antworten kann, z. B. die Schnittstelle.
Eine Metaidentität ist ein Weg zum Definieren eines Metadatenkontexts, in dem das Objekt existieren kann. Einem Objekt ist es möglicherweise nicht bekannt, dass es die in Metaidentität einkapselt ist. Objektinstanzen können Stereotypisierungsinformationen dynamisch anwenden, indem sie eine Gruppe mit dem gewünschten Metadatenkontext definieren und das Objekt dann in die Gruppe einschreiben.
Authentifizierung und Identität sind zusammengefasste Aspekte. Eine Objektidentität kann nicht geglaubt werden, wenn sie nicht authentifiziert ist. Jedoch ist eine Authentifizierung ohne Identität nur begrenzt nützlich. Asymmetrische Schlüsselsignaturen, wie ECDSA (Elliptic Curve Digital Signature Algorithm), RSA oder dergleichen, sind für die Authentifizierung nützlich, unter der Erwartung, dass die Fähigkeit zum Replizieren und Verteilen des privaten Schlüssels eingeschränkt ist. Die Verwendung des Schlüssels begründet einen Beweis dafür, dass ein Auftraggeber oder Vertreter Zugriff auf den Schlüssel hat, obwohl er eingeschränkt ist. Daher muss der Auftraggeber oder Vertreter authentisch sein.
Die Semantik der Authentifizierung folgt, wenn sie auf Objektidentitäten angewendet wird, auch den drei Abstraktionen von Objektinstanz, Objekttyp und Metaidentität. Für eine Objektinstanz begründet die Authentifizierungs-Challenge-Antwort, dass die aktuelle Interaktion nur mit einer bestimmten Instanziierung des Objekts erfolgen kann. Für einen Objekttyp attestiert die Authentifizierungs-Challenge-Antwort, dass die aktuelle Interaktion durch die Semantik der Typidentifikation eingeschränkt wird. Für die Metaidentität kategorisiert die Authentifizierungs-Challenge-Antwort die aktuelle Interaktion gemäß dem definierten Kontext.
Blockchains können verwendet werden, um die Informationen sowohl zur Authentifizierung als auch zur Formierung der Geräte bereitzustellen. Blockchains können verwendet werden, um die Identifikation zu dezentralisieren, da sie eine Übereinkunft zwischen Geräten hinsichtlich der derzeit verwendeten Namen und Identitäten bereitstellen können. Wie hierin verwendet, ist eine Blockchain eine verteilte Datenbank von Identitätsdatensätzen, die aus Datenstrukturblöcken besteht. Ferner kann, wie hierin verwendet, der Begriff Blockchain ein oder mehrere andere verteilte Rechnungsführungssysteme aufweisen. Andere verteilte Rechnungsführungsansätze umfassen Ripple, Hyperledger, Multichain, „Keyless Signature Infrastructure“, und dergleichen. Jeder Datenstrukturblock basiert auf einer Transaktion, wobei die Ausgabe eines neuen Namens an ein Gerät, ein zusammengesetztes Gerät oder ein virtuelles Gerät ein Beispiel für eine Transaktion ist.
Unter Verwendung von Blockchains zur Identifizierung kann ein Identitätswechsel durch Beobachtung der erneuten Ausgabe von Namen und Identitäten ohne entsprechende Beendigung detektiert werden. Öffentliche Blockchains können am nützlichsten sein, da sie es einer vielfältigen Community von Beobachtern ermöglichen können, Falschbenennung, schädliche Benennung, oder Fehler einer Benennungsinfrastruktur zu erkennen. Somit kann eine vertrauenswürdige Identitätsinfrastruktur für das Vertrauen in IoT-Netzwerke von zentraler Bedeutung sein.
Obwohl das Fog-Gerät 402 in diesem Beispiel als Maschennetzwerk gezeigt ist, müssen die Geräte unter Verwendung von Gateways 310 zur Kommunikation mit Geräten in der Cloud 302 nicht notwendigerweise Teil eines Maschennetzwerks sein oder sich sogar in Nähe zueinander befinden, um ein Fog-Gerät zu bilden. Somit müssen die Geräte nicht in direkter Funk- oder Netzwerkkommunikation miteinander stehen oder sich in unmittelbarer Nähe zueinander befinden, sondern können basierend auf der Funktion eine Ad-hoc-Gruppe bilden. Die Bildung des Fog-Geräts 402 kann so einfach sein wie ein gemeinsames Nutzen von Namens-, Typ- und Identifikationsinformationen, beispielsweise Gruppenidentitätsanmeldeinformationen, unter den unterschiedlichen Geräten, die das Fog-Gerät bilden. Dies kann es jedem Gerät ermöglichen, als Vertreter des Fog-Geräts 402 zu fungieren, wobei eine für das Gerät spezifische Identität bereitgestellt wird. Obwohl das Fog-Gerät 402 in diesem Beispiel aus Geräten an einem einzigen Ort besteht, können Fog-Geräte beispielsweise Geräte an mehreren Orten aufweisen, die zur Bereitstellung spezifischer Dienste ausgebildet sind. Beispielsweise kann das Fog-Gerät 402 entfernte Wetterstationen aufweisen, die sich in der Cloud 302 befinden. Ferner kann ein Server 304, der sich in einem Rechenzentrum befindet, in dem Fog-Gerät 402 zur Datenanalyse und anderen Diensten enthalten sein.
Die hier beschriebenen Orchestrierungstechniken können mit Fog-Geräten oder in IoT-Netzwerken, die keine Fog-Geräte aufweisen, verwendet werden, wie in Bezug auf 3 beschrieben wurde. In einem Beispiel kann die Orchestrierung innerhalb eines Fog-Geräts stattfinden, um Arbeitslasten von überlasteten Geräten auf weniger ausgelastete Geräte zu übertragen. Ferner können die Orchestrierungstechniken zwischen Fog-Geräten verwendet werden, um Arbeitslasten von überlasteten Fog-Geräten auf weniger ausgelastete Fog-Geräte zu übertragen. In jedem dieser Fälle kann die Übertragung der Arbeitslast für einen Benutzer transparent sein.
In einigen Beispielen weist das Fog-Gerät 402 eine Gruppe von IoT-Geräten an einer Verkehrskreuzung auf. Das Fog-Gerät 402 kann unter anderem gemäß den von dem OpenFog-Konsortium (OFC) publizierten Spezifikationen eingerichtet werden. Diese Spezifikationen ermöglichen die Bildung einer Hierarchie von Rechenelementen zwischen den Gateways 310, die das Fog-Gerät 402 mit der Cloud 302 koppeln, und mit Endpunktgeräten, wie etwa Ampeln 404 und Datenaggregatoren 406, in diesem Beispiel. Das Fog-Gerät 402 kann die kombinierten Verarbeitungs- und Netzwerkressourcen nutzen, die das Kollektiv von IoT-Geräten bereitstellt. Dementsprechend kann ein Fog-Gerät 402 für eine beliebige Anzahl von Anwendungen verwendet werden, die beispielsweise Finanzmodellierung, Wettervorhersage, seismische Messung, Verkehrsanalysen, Sicherheitsüberwachung und dergleichen aufweisen.
Beispielsweise kann der Verkehrsfluss durch die Kreuzung durch mehrere Ampeln 404 (z. B. drei Ampeln 404) gesteuert werden. Die Analyse des Verkehrsflusses und der Steuerschemata kann durch Aggregatoren 406 implementiert werden, die über ein Maschennetzwerk mit den Ampeln 404 und miteinander in Kommunikation stehen. Die Implementierung der Verkehrsflussanwendungen kann in den Ampeln 204 selbst stattfinden. Daten können in die Cloud 302 hochgeladen werden, und Befehle können von der Cloud 302 über Gateways 310, die über das Maschennetzwerk mit den Ampeln 404 und den Aggregatoren 406 in Verbindung stehen, empfangen werden.
Eine beliebige Anzahl von Kommunikationsverbindungen kann in dem Fog-Gerät 402 verwendet werden. Kurzreichweitigere Verbindungen 408 (beispielsweise kurzreichweitigere Funkverbindungen), die beispielsweise mit IEEE 802.15.4 kompatibel sind, können eine lokale Kommunikation zwischen IoT-Geräten bereitstellen, die sich in der Nähe der Kreuzung befinden. Längerreichweitigere Verbindungen 410 (beispielsweise längerreichweitigere Funkverbindungen), die beispielsweise mit LPWA-Standards kompatibel sind, können eine Kommunikation zwischen den IoT-Geräten und den Gateways 310 bereitstellen. Um das Diagramm zu vereinfachen, ist nicht jede Kommunikationsverbindung 408 oder 410 mit einem Bezugszeichen gekennzeichnet. Ferner muss nicht jedes Gerät, das an dem Fog-Gerät 402 teilnimmt, in der Nähe der anderen Geräte oder in der direkten Funkkommunikation angeordnet sein. Beispielsweise kann das Fog-Gerät 402 eine Wetterstation aufweisen, die sich in einem anderen Netzwerk befindet. Die Benennung und Typisierung können identifizieren, ob ein bestimmtes IoT-Gerät an einem Fog-Gerät 402 teilnimmt.
Eine oder mehrere oder alle der Kommunikationsverbindungen 408 und 410 können durch eine drahtgebundene Verbindung zwischen zwei beliebigen Geräten ersetzt werden. Ferner muss das Netzwerk, das das Fog-Gerät 402 bildet, kein Maschennetzwerk sein, sondern kann ein Standardnetzwerk sein, in dem jedes Gerät durch eine drahtgebundene oder drahtlose Verbindung mit den Gateways 310 mit anderen Geräten gekoppelt ist.
Das Fog-Gerät 402 kann als ein miteinander verbundenes Netzwerk (beispielsweise als ein massiv-verbundenes Netzwerk) betrachtet werden, bei dem eine Anzahl von IoT-Geräten miteinander kommunizieren, beispielsweise direkt über die Kommunikationsverbindungen 408 und 410, über die Cloud 302 über eine Netzwerkkommunikationsverbindung, oder über ein Gateway 310. Für Geräte, die sich in einer Nähe zueinander befinden, kann das Netzwerk unter Verwendung der am 23. Dezember 2015 von der Open Connectivity Foundation™ (OCF) publizierten Standardspezifikation 1.0 des Open Interconnect Consortium (OIC) 1.0 eingerichtet werden. Dieser Standard ermöglicht es Geräten, sich gegenseitig zu entdecken, und Kommunikationen für Verbindungen herzustellen. Andere Verbindungs- und Interoperabilitätsprotokolle können ebenfalls verwendet werden, die, unter vielen anderen, beispielsweise die 2008 von der OPC-Foundation publizierte Open Platform Communications (OPC) Unified Architecture, das AllJoyn-Protokoll der AllSeen Alliance, das OLSR- (Optimized Link State Routing) Protokoll, oder den B.A.T.M.A.N. („better approach to mobile ad-hoc networking“) aufweisen.
In einigen Aspekten kann die Kommunikation von einem IoT-Gerät, um die Gateways 310 zu erreichen, entlang des bequemsten Pfades geleitet werden, beispielsweise, unter anderen, dem Pfad mit der geringsten Anzahl von Zwischensprüngen oder der höchsten Bandbreite. In diesen Netzwerken stellt die Anzahl der Verbindungen eine erhebliche Redundanz bereit, sodass die Kommunikation auch bei Verlust einer Reihe von IoT-Geräten aufrechterhalten werden kann.
In einigen Aspekten kann das Fog-Gerät 402 temporäre IoT-Geräte aufweisen. Mit anderen Worten, möglicherweise sind nicht alle IoT-Geräte permanente Mitglieder des Fog-Geräts 402. Beispielsweise sind in dem beispielhaften System 400 drei transiente IoT-Geräte dem Fog-Gerät 402 beigetreten, ein erstes Fahrzeug 412, ein zweites Fahrzeug 414, und ein Fußgänger 416. In diesen Fällen kann das IoT-Gerät in die Fahrzeuge 412 und 414 eingebaut sein, oder kann eine App auf einem Smartphone sein, das von dem Fußgänger 416 getragen wird. Andere IoT-Geräte können ebenfalls vorhanden sein, wie etwa IoT-Geräte in Fahrradcomputern, Motorradcomputern, Drohnen und dergleichen.
Wie hierin beschrieben, können die Anwendungen, die das Fog-Gerät steuern, auf einer beliebigen Anzahl von Ebenen arbeiten, in Abhängigkeit von einer Anzahl von Faktoren, wie dem Zweck jedes Geräts und der Auslastung der Systeme. Beispielsweise können die Ampeln 404 Sensoren überwachen, um sich nähernden Verkehr, wie Fahrzeuge, Fußgänger, Fahrräder, und dergleichen, zu identifizieren, um eine Verkehrssteuerungsanwendung zu implementieren. Die Sensoren können Kameras sein, die Streaming-Videos der Straßen erfassen und das Streaming-Video zur Analyse an die Ampeln 404 weiterleiten. Unter normalen Betriebsbedingungen können die Ampeln 404 miteinander kooperieren, um zu bestimmen, welche Straßen grüne Ampeln und welche Straßen rote Ampeln haben.
Jedoch können während Perioden, in denen der Verkehr besonders stark ist, die Ampeln 404 überlastet sein. Dementsprechend kann eine Verkehrsanalyseaufgabe zu den Datenaggregatoren 406 oder zu den Gateways 310 verschoben werden. Ferner kann die Verkehrsanalyseaufgabe zu anderen Geräten verschoben werden, die mit der Ampel 404 als Teil des Fog-Geräts 402 in Kontakt stehen, wie etwa Fahrzeuge 412 und 414 oder der Server 304, in Abhängigkeit von der Kontaktzeit, der Fähigkeit des Fahrzeugs 412 oder 414, der Netzwerklatenz, und dergleichen. Sobald die Auslastung wieder normal ist, kann die Verkehrsanalyseaufgabe zurück zu den Ampeln 404 verschoben werden.
Das aus den IoT-Geräten gebildete Fog-Gerät 402 kann Clients in der Cloud 302, wie beispielsweise dem Server 304, als ein einzelnes Gerät präsentiert werden, das sich am Rand der Cloud 302 befindet. In diesem Beispiel kann die Steuerkommunikation zu spezifischen Ressourcen in dem Fog-Geräts 402 auftreten, ohne ein bestimmtes IoT-Gerät in dem Fog-Gerät 402 zu identifizieren. Falls dementsprechend ein IoT-Gerät in dem Fog-Geräts 402 ausfällt, können andere IoT-Geräte in dem Fog-Geräts 402 eine Ressource, wie etwa einen Aktuator oder ein anderes Gerät, das an ein IoT-Gerät angeschlossen ist, entdecken und steuern. Beispielsweise können die Ampeln 404 so verdrahtet sein, dass eine der Ampeln 404 dazu dient, Lichter für die anderen Ampeln 404 zu steuern. Die Aggregatoren 406 können auch Redundanz bei der Steuerung der Ampeln 404 und anderer Funktionen des Fog-Geräts 402 bereitstellen.
In einigen Beispielen können die IoT-Geräte unter Verwendung eines imperativen Programmierstils konfiguriert werden, wobei z. B. jedes IoT-Gerät eine spezifische Funktion und Kommunikationspartner hat. Die IoT-Geräte, die das Fog-Gerät 402 bilden, können jedoch in einem deklarativen Programmierstil konfiguriert sein, wodurch den IoT-Geräte ermöglicht wird, ihre Operationen und Kommunikationen neu zu konfigurieren, beispielsweise um die erforderlichen Ressourcen als Reaktion auf Bedingungen, Abfragen und Gerätefehler zu bestimmen. Dies kann durchgeführt werden, wenn transiente IoT-Geräte, wie der Fußgänger 416, dem Fog-Gerät 402 beitreten.
Eine Kombination von IoT-Geräten, die einen imperativen Programmierstil verwenden, und Geräten, die einen deklarativen Programmierstil verwenden, kann in Anwendungen verwendet werden. Beispielsweise können allgemeinere IoT-Geräte einen deklarativen Programmierstil verwenden, um sich an sich ändernde Bedingungen anzupassen. Eingeschränktere IoT-Geräte, wie etwa Sensorgeräte, haben möglicherweise nicht die Programmierleistung, um adaptivere Software zu enthalten.
Da der Fußgänger 416 wahrscheinlich langsamer reist als die Fahrzeuge 412 und 414, kann sich das Fog-Gerät 402 selbst neu konfigurieren, um zu gewährleisten, dass der Fußgänger 416 genügend Zeit hat, durch die Kreuzung zu gelangen. Dies kann durchgeführt werden, indem eine temporäre Gruppe der Fahrzeuge 412 und 414 und des Fußgängers 416 gebildet wird, um die Ampeln 404 zu steuern. Falls eines oder beide der Fahrzeuge 412 oder 414 autonom sind, kann die temporäre Gruppe die Fahrzeuge anweisen, vor den Ampeln langsamer zu werden. Ferner kann, falls alle Fahrzeuge an der Kreuzung autonom sind, der Bedarf an Verkehrssignalen verringert werden, da die Kollisionsvermeidungssysteme der autonomen Fahrzeuge stark verschachtelte Verkehrsmuster ermöglichen, die für die Verkehrsampeln zu komplex zu verwalten sind. Jedoch können die Ampeln 404 für den Fußgänger 416, Radfahrer oder nicht autonome Fahrzeuge immer noch wichtig sein.
Wenn die transienten Geräte 412, 414 und 416 die Nähe der Kreuzung des Fog-Geräts 402 verlassen, kann sich das Fog-Gerät 402 selbst neu konfigurieren, um diese IoT-Geräte aus dem Netzwerk zu entfernen. Wenn sich andere transiente IoT-Geräte der Kreuzung nähern, kann sich das Fog-Gerät 402 neu konfigurieren, um diese Geräte einzubeziehen.
Das Fog-Gerät 402 kann die Ampeln 404 für eine Anzahl von Kreuzungen, beispielsweise entlang einer Straße, zusammen mit allen transienten IoT-Geräten entlang der Straße aufweisen. Das Fog-Gerät 402 kann sich dann selbst in Funktionseinheiten aufteilen, wie beispielsweise die Ampeln 404 und andere IoT-Geräte in der Nähe einer einzelnen Kreuzung. Diese Art der Kombination kann die Bildung größerer IoT-Konstrukte, z. B. Gruppen von IoT-Geräten, die eine bestimmte Funktion ausführen, in dem Fog-Gerät 402 möglich machen.
Falls beispielsweise ein Notfallfahrzeug dem Fog-Gerät 402 beitritt, kann ein Notfallkonstrukt oder ein virtuelles Gerät erzeugt werden, das alle Ampeln 404 für die Straße aufweist. Dies kann die Steuerung der Verkehrsflussmuster für die gesamte Straße ermöglichen. Das Notfallkonstrukt kann die Ampeln 404 entlang der Straße anweisen, für den Gegenverkehr rot und für das Notfallfahrzeug grün zu bleiben, wodurch die Passage des Notfallfahrzeugs beschleunigt wird. Das Notfallkonstrukt kann eine Anzahl von Anwendungen und Funktionsblöcken aufweisen, die von einem Aufgabenbild-Repository in dem Fog-Gerät 402 aktiviert wurden, oder von dem Server 304 oder anderen Geräten in der Cloud 302 auf das Fog-Gerät 402 heruntergeladen wurden. Ferner können die Aufgabenbilder von einem Einsatzfahrzeug, das dem Fog-Geräts 402 beitritt, heruntergeladen werden.
Das Notfallkonstrukt kann die eingesetzten Anwendungen verwenden, um den Ort und die Fahrbahn für das Notfallfahrzeug zu bestimmen. Anwendungen können dann die Ampeln 404 entlang der Straße anweisen, für den Gegenverkehr rot und für das Einsatzfahrzeug grün zu bleiben, wodurch die Passage des Einsatzfahrzeugs beschleunigt wird.
Wie durch das Fog-Gerät 402 veranschaulicht, ist die organische Entwicklung von IoT-Netzwerken für die Verbesserung oder Maximierung des Nutzens, der Verfügbarkeit, und der Ausfallsicherheit von IoT-Implementierungen von zentraler Bedeutung. Die Verwendung von Anwendungen, die auf unterschiedliche Computergeräte verlagert werden, kann beispielsweise die Anpassungsfähigkeit des Fog-Geräts 402 erhöhen und eine einfachere Integration neuer Funktionen bereitstellen.
Das Beispiel zeigt die Nützlichkeit von Strategien zur Verbesserung des Vertrauens und damit der Sicherheit. Die lokale Identifizierung von Geräten kann bei Implementierungen wichtig sein, da die Dezentralisierung der Identität gewährleistet, dass eine zentrale Autorität nicht dazu ausgenutzt werden kann, den Identitätswechsel von Objekten, die möglicherweise in den IoT-Netzwerken vorhanden sind, zu ermöglichen. Darüber hinaus verringert die lokale Identifizierung den Kommunikationsaufwand und die Latenz.
Netzwerke von Geräten können in einer MEC- (Multi-Access Edge Computing) Umgebung bereitgestellt werden. Multi-Access-Edge-Computing (MEC), auch als Mobile-Edge-Computing bezeichnet, kann Anwendungsentwicklern und Inhaltsanbietern Cloud-Computing-Ressourcen und eine Informationstechnologie-Dienstumgebung am Rand eines Netzwerks bieten. Ein MEC-System kann einen MEC-Orchestrator und einen MEC-Plattformmanager aufweisen, die die Bereitstellung eines Dienstes für ein Benutzergerät (UE) durch einen Dienstanbieter durch einen oder mehrere Zugriffspunkte oder einen oder mehrere MEC-Hosts verwalten.
Die MEC-Umgebung kann Teil eines Funkzugangsnetzwerks (RAN) sein, das für Drittanbieter geöffnet wurde, beispielsweise Clearingstellen für Blockchain-Transaktionen. Das RAN kann ein System mit hoher Bandbreite und geringer Latenz bereitstellen, das es Fog-Geräten 402 ermöglicht, effizienter mit Anwendungen und Diensten in der Cloud 302 zu arbeiten. Dementsprechend kann die Cloud 302 als Cloud- oder Fog-Server angesehen werden, der am Rand eines Mobilfunknetzes ausgeführt wird und Aufgaben durchführt, die mit einer herkömmlichen Netzwerkinfrastruktur möglicherweise nicht erreicht werden können. Maschine-zu-Maschine-Gateway- und Steuerfunktionen, wie die Beispiele von IoT-Geräten, die in Bezug auf die 3 und 4 beschrieben wurden, sind ein Beispiel. In einem MEC-Netzwerk wird die Verarbeitungsleistung, wie Server, näher an den Rand von Netzwerken gebracht. Beispielsweise befinden sich die Aggregatoren 406 innerhalb des Fog-Geräts 402.
5A veranschaulicht eine Plattform 500 (und/oder ein System 500) gemäß einigen Ausführungsformen. In einigen Ausführungsformen ist die Plattform 500 eine modulare Plattform und/oder ein modulares System. In einigen Ausführungsformen ist die Plattform 500 eine drahtgebundene Sensorplattform. In einigen Ausführungsformen ist die Plattform 500 eine drahtlose Sensorplattform. In einigen Ausführungsformen ist die Plattform 500 eine IoT-Plattform. In einigen Ausführungsformen ist die Plattform 500 ein IoT-System. In einigen Ausführungsformen ist die Plattform 500 ein IoT-Gerät. In einigen Ausführungsformen kann die Plattform 500 alles oder ein Teil eines der Geräte in einem IoT-System sein. Beispielsweise kann in einigen Ausführungsformen die Plattform 500 alles oder ein Teil eines der Geräte in einer der IoT-Umgebungen der 1 bis 4 sein. In einigen Ausführungsformen ist die Plattform 500 eine IoT-Sensorplattform. In einigen Ausführungsformen ist die Plattform 500 ein IoT-Sensor-Hub. In einigen Ausführungsformen kann die Plattform 500 in einem drahtlosen Sensornetzwerk (WSN) enthalten sein. Die Plattform 500 kann einige oder alle eines Rechenmoduls 502, eines Konnektivitätsmoduls 504, einer Basisplatine 506, einer Sensorbasisplatine 508, und ein oder mehrerer Sensormodule 510 aufweisen (zwei diskrete Sensormodule 510 sind beispielhaft in 5A dargestellt). In einigen Ausführungsformen veranschaulicht 5B die Plattform 500 von 5A, wobei die Komponenten, wie die Module und Platinen, miteinander gekoppelt sind. Es wird angemerkt, dass die Plattform 500 hier zwar als Plattform bezeichnet wird, in einigen Ausführungsformen jedoch auch als System 500 bezeichnet werden kann.
In einigen Ausführungsformen werden Verbinder verwendet, so dass Verbindungen nur auf eine bestimmte Weise hergestellt werden können. In einigen Ausführungsformen sind die Verbinder Stapelverbinder (die beispielsweise zweiseitige Module verwenden). In einigen Ausführungsformen sind die Verbinder Hirose-Verbinder. In einigen Ausführungsformen werden Verbinder (beispielsweise die in den Plattformen 500 enthalten Verbinder) so verwendet, dass Verbindungen nur auf eine bestimmte Weise hergestellt werden können, indem zweiseitige Module und Stapelverbinder verwendet werden. Beispielsweise wird in einigen Ausführungsformen eine Verbinderpaarung verwendet, bei der zweiseitige Module mit Stapelverbindern auf beiden Seiten einer Platine (beispielsweise auf beiden Seiten einer Leiterplatte) ermöglicht, dass innerhalb der Plattform (oder des Systems) zusätzliche Module gestapelt werden (beispielsweise oben und unten gestapelt. Beispielsweise kann die Verbinderpaarung dazu verwendet werden, dass andere Platinen, Module usw. nicht falsch eingesetzt werden können.
In einigen Ausführungsformen kann das Rechenmodul 502 unter anderem ein Mikrocontrollereinheitsmodul (oder MCU-Modul), ein Prozessoreinheitsmodul, ein Mikroprozessoreinheitsmodul (oder MPU-Modul) usw. sein. In einigen Ausführungsformen können Formfaktoren verwendet werden, so dass verschiedene Hersteller von Komponenten diese Komponenten in die Plattform 500 einstecken können. Beispielsweise können verschiedene Sensorhersteller ihre Sensormodule so entwerfen, dass sie in die Plattform 500 eingesteckt werden, können verschiedene Computerhersteller ihre Rechenmodule so entwerfen, dass sie in die Plattform 500 eingesteckt werden, und/oder können verschiedene Konnektivitätshersteller (beispielsweise Funkgerätehersteller) ihre Konnektivitätsmodule so entwerfen, dass sie in die Plattform 500 eingesteckt werden. In einigen Ausführungsformen kann die Plattform 500 ein flexibles, modulares Hardware-Edge-System für das Internet der Dinge (IoT) sein. In einigen Ausführungsformen kann die Plattform 500 eine Edge- und/oder Fog-Sensorplattform zum Sammeln von Daten im Internet der Dinge (IoT) sein. In einigen Ausführungsformen kann die Plattform 500 eine IoT-Plattform und/oder ein IoT-Gerät sein, das in einem IoT-System enthalten sein kann. In einigen Ausführungsformen ist die Plattform 500 ein System, in dem verschiedene Sensoren, Kommunikations- oder Konnektivitätsgeräte (beispielsweise Funkgeräte), Mikroprozessoreinheiten (oder Mikrocontrollereinheiten) enthalten sein können. Obwohl in 5 verschiedene Module gezeigt werden, können diese Module in einigen Ausführungsformen anders angeordnet sein. Beispielsweise können Module in einigen Ausführungsformen relativ zueinander vertikal angeordnet sein, und in anderen Ausführungsformen können sie nebeneinander angeordnet sein. Beispielsweise könnten anstelle eines Prozessormoduls 502 neben dem Kommunikationsmodul 504 zwei Kommunikationsmodule 504 in 5 Seite-an-Seite angeordnet sein, und in einigen Ausführungsformen könnte ein Prozessormodul 502 über einem oder beiden dieser Module 504 angeordnet sein.
In einigen Ausführungsformen kann die Platine 506 Rechenschlitze 562, Konnektivitätsschlitze 564, Verbinder 566 (beispielsweise I2C-, UART- und/oder GPIO-Verbinder), einen Leistungsschalter 568, einen Rücksetzknopf 569, einen Batterieport 570, Verbinder 572 (beispielsweise USB-Verbinder), eine Stromeingangsbuchse 574 und andere Elemente aufweisen. Beispielsweise weist in einigen Ausführungsformen die Platine 506 einen oder mehrere Platine-zu-Platine-Stapelverbinder auf einer Unterseite (in 5A oder 5B nicht dargestellt) zum Verbinden mit der Platine 508 auf. In einigen Ausführungsformen erstrecken sich Verbindungsmittel 512 (beispielsweise Schrauben) durch die Platinen 502 und 504 und passen mit Verbindungspunkten auf der Platine 506 zusammen.
In einigen Ausführungsformen kann die Platine 508 Platine-zu-Platine-Verbinder 582 aufweisen, die mit Platine-zu-Platine-Verbindern auf der Unterseite der Platine 506 gekoppelt sein können. Die Platine 506 kann auch Abstandshalter 584 und Abschirmungsverbinder 586 aufweisen. Es wird angemerkt, dass einige Ausführungsformen sowohl Schilde als auch Dongles zulassen. In einigen Ausführungsformen erstrecken sich Verbindungsmittel 512 (beispielsweise Schrauben) durch Platinen 510 und passen mit Verbindungspunkten auf Platine 508 zusammen.
6A veranschaulicht eine Plattform 600 (und/oder ein System 600) gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann jedes der Elemente der Plattform 600 gleich oder ähnlich zu den Elementen der Plattform 500 sein. In einigen Ausführungsformen ist die Plattform 600 eine modulare Plattform und/oder ein modulares System. In einigen Ausführungsformen ist die Plattform 600 eine drahtgebundene Sensorplattform. In einigen Ausführungsformen ist die Plattform 600 eine drahtlose Sensorplattform. In einigen Ausführungsformen ist die Plattform 600 eine IoT-Plattform. In einigen Ausführungsformen ist die Plattform 600 ein IoT-System. In einigen Ausführungsformen ist die Plattform 600 ein IoT-Gerät. In einigen Ausführungsformen kann die Plattform 600 alles oder ein Teil eines der Geräte in einem IoT-System sein. Beispielsweise kann in einigen Ausführungsformen die Plattform 600 alles oder ein Teil eines der Geräte in einer der IoT-Umgebungen der 1 bis 4 sein. In einigen Ausführungsformen ist die Plattform 600 eine IoT-Sensorplattform. In einigen Ausführungsformen ist die Plattform 600 ein IoT-Sensor-Hub. In einigen Ausführungsformen kann die Plattform 600 in einem drahtlosen Sensornetzwerk (WSN) enthalten sein. Die Plattform 600 kann einige oder alle eines oder mehrerer Rechenmodule 602, eines oder mehrerer Konnektivitätsmodule 604, eines oder mehrerer Sensormodule 610, einer oder mehrerer Mini-Stack-Basisplatinen 622 und einer oder mehrerer Batterien 624 aufweisen. In einigen Ausführungsformen veranschaulicht 6B die Plattform 600 von 6A, wobei die Komponenten, wie etwa die Module und Platine, miteinander gekoppelt sind. In einigen Ausführungsformen werden Verbinder in der Plattform 600 auf ähnliche Weise wie die in der Plattform 500 hergestellten Verbindungen verwendet. Es wird angemerkt, dass die Plattform 600 hier zwar als Plattform bezeichnet wird, in einigen Ausführungsformen jedoch auch als System 600 bezeichnet werden kann.
In einigen Ausführungsformen können die Plattform 500 und/oder die Plattform 600 einen flexiblen Rahmen bereitstellen, in dem verschiedene Anwendungsfälle implementiert sein können. In einigen Ausführungsformen können die Plattform 500 und/oder die Plattform 600 stapelbare intelligente Module aufweisen, die mehrere MCUs, Funkgeräte und/oder Sensoren aufweisen. In einigen Ausführungsformen stellen die Plattform 500 und/oder die Plattform 600 ein modulares Layout bereit, das beispielsweise die Umwandlung von Mehrplatinendesigns in integrierte Platinendesigns (beispielsweise integrierte monolithische Platinendesigns) und System-in-Gehäuse- (SiP) Designs erleichtern kann.
Verschiedene Hersteller oder Kunden auf Systemebene, die Sensoren zum Evaluieren von Daten in einer IoT-Umgebung verwenden möchten, können die Plattform 500 und/oder Plattform 600 verwenden, um Module zu stapeln, um Erfassungsbedarf, unter anderen in der Landwirtschaft, im Einzelhandel, in der Industrie, im Automotive-Bereich usw. zu erfüllen. In einigen Ausführungsformen können die Plattform 500 und/oder die Plattform 600 als Kit für einen solchen Systemebenen-Hersteller oder Kunden verwendet werden, um eine Lösung für einen bestimmten Erfassungsbedarf zusammenzustellen. Sobald die Plattform 500 und/oder Plattform 600 fertiggestellt ist, kann der Systemebene-Hersteller oder Kunde ein solches Kit beispielsweise dazu verwenden, um die Lösung zu implementieren, und dann später eine Integrationsversion, beispielsweise auf einer einzelnen Platine, mit hohen Stückzahlen bereitstellen.
In einigen Ausführungsformen können die Module und Platinen in der Plattform 500 und/oder der Plattform 600 farbcodiert sein, um die Verwendung zu erleichtern. Beispielsweise können in einigen Ausführungsformen das Rechenmodul 502, das Rechenmodul 602 und/oder eine Platine und/oder andere Komponenten des Moduls 502 oder des Moduls 602 eine erste Farbe, etwa Blau, haben, das Konnektivitätsmodul 504, das Konnektivitätsmodul 604 und/oder eine Platine und/oder andere Komponenten des Moduls 504 oder des Moduls 604 können eine zweite Farbe, wie etwa Grün, haben, und die Sensormodule 510, die Sensormodul 610 und/oder Platinen und/oder andere Komponenten der Module 510 oder des Moduls 610 können eine dritte Farbe, wie etwa Rot, haben. Es wird angemerkt, dass, obwohl das Stapeln von Platinen und/oder Modulen der Plattform 500 und/oder Plattform 600 vertikal implementiert werden kann, ein anderes Stapeln implementiert werden kann. Beispielsweise können in einigen Ausführungsformen Platinen und/oder Module horizontal gestapelt werden.
In einigen Ausführungsformen können zusätzliche Konnektivitätsmodule, Rechenmodule und/oder Sensormodule enthalten sein. Beispielsweise könnten in einigen Ausführungsformen die Module 502 und 504 beides Rechenmodule sein, und ein oder mehrere Konnektivitätsmodule könnten an anderer Stelle enthalten sein. In einigen Ausführungsformen könnten die Module 502 und 504 beide Konnektivitätsmodule sein, und ein oder mehrere Rechenmodule könnten an anderer Stelle enthalten sein.
In einigen Ausführungsformen können das Rechenmodul 502 und/oder das Rechenmodul 602 einen Mikroprozessor, einen Mehrkernprozessor, einen Multithread-Prozessor, einen Ultra-Niederspannungsprozessor, einen eingebetteten Prozessor oder ein anderes bekanntes Verarbeitungselement aufweisen. Der in dem Rechenmodul 502 oder 602 enthaltene Prozessor kann Teil eines Systems-auf-Chip (SoC) sein, in dem der Prozessor und andere Komponenten zu einer einzelnen integrierten Schaltung oder einem einzelnen Gehäuse ausgebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel. Beispielsweise kann der Prozessor einen Intel®-Architecture-Core™-basierten Prozessor aufweisen, wie etwa einen Quark™, einen Atom™, einen i3, einen i5, einen i7, einen Xeon®, einen Xeon-Phi™-Coprozessor, oder einen Prozessor der MCU-Klasse, oder einen anderen solcher Prozessoren, erhältlich von Intel® Corporation, Santa Clara, CA. Es kann jedoch eine beliebige Anzahl anderer Prozessoren verwendet werden, wie etwa einer, der von Advanced Micro Devices, Inc. (AMD) aus Sunnyvale, CA, erhältlich ist, einem mit MIPS-basiertem Design von MIPS Technologies, Inc. aus Sunnyvale, CA, einem mit ARM-basierten Design, lizenziert von ARM Holdings, Ltd., oder einem Kunden davon oder deren Lizenznehmern oder Anwendern. Die Prozessoren können Einheiten, wie etwa einen Prozessor von Apple® Inc. (beispielsweise einen A5-A10-Prozessor von Apple® Inc.), einen Snapdragon™ -Prozessor von Qualcomm® Technologies, Inc., oder einen OMAP™ -Prozessor von Texas Instruments, Inc. aufweisen.
In einigen Ausführungsformen können das Kommunikationsmodul 504 und/oder das Kommunikationsmodul 604 unter Verwendung mehrerer Standards oder Funkgeräte für die Kommunikation in unterschiedlichen Reichweiten kommunizieren. Beispielsweise können sie mit geografisch benachbarten Geräten, z. B. innerhalb von etwa 10 Metern, unter Verwendung eines auf BLE basierenden lokalen Sendeempfängers oder eines anderen Niederenergie-Funkgeräts kommunizieren, um Energie zu sparen. Weiter entfernte Geräte, z. B. innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkgeräte mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät mit unterschiedlichen Leistungsstufen oder über separate Sendeempfänger, beispielsweise einen lokalen Sendeempfänger unter Verwendung von BLE und einen separaten Maschen-Sendeempfänger unter Verwendung von ZigBee, stattfinden. Ein Sendeempfänger kann auch als Adresse, auf die der Chip direkt zugreifen kann, in eine MCU integriert sein, wie etwa in den von Intel erhältlichen Curie®-Einheiten. Es kann eine beliebige Anzahl anderer Funkkommunikationen und -protokollen verwendet werden. Beispielsweise können die Funkkommunikationsmodule einen LTE- oder einen anderen zellularen Sendeempfänger aufweisen, der Spreizspektrums- (SPA/SAS) Kommunikationen zur Implementierung einer Hochgeschwindigkeitskommunikation verwendet, etwa für Videoübertragungen. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für die Kommunikation mit mittlerer Geschwindigkeit, wie etwa Standbilder, Sensorauslesungen und die Bereitstellung von Netzwerkkommunikation.
In einigen Ausführungsformen können kleine Würfel (beispielsweise Würfel von einem Zoll mal einem Zoll mal einem halben Zoll, in einigen Ausführungsformen) erzeugt werden, um auf eine Weise implementiert zu werden, die zuvor unter Verwendung größerer Platinen (beispielsweise unter Verwendung von 3 Zoll mal 5 Zoll-Platinen) implementiert wurde. Mehrere Versionen der Plattform 500 und/oder der Plattform 600 können in einem Bereich durchgehend implementiert werden, beispielsweise in einem Haus, einem Kraftwerk, einem Büro oder einer Stadt, wobei eine drahtgebundene oder drahtlose Verbindung verwendet wird. Dies kann beispielsweise unter Verwendung von intelligentem Stapeln und Durchleiten von Pin-Signalen implementiert werden.
In einigen Ausführungsformen können die Plattform 500 und/oder die Plattform 600 der Sensor, die Edge und/oder der Aggregator von sich selbst sein. Beispielsweise kann in einigen Ausführungsformen eine große Anzahl von Plattformen 600 (beispielsweise 10 Plattformen 600) in einem IoT-Netzwerk enthalten sein, die alle eine oder mehrere der Plattformen 500 versorgen (beispielsweise 10 Plattformen 600, die eine Plattform 500 versorgen), wobei die Plattformen 600 Sensoren sind und die Plattform 500 eine Sensornabe ist. In einigen Ausführungsformen kann ein IoT-Netzwerk eine Anzahl von ultimativen Edge-Geräten (beispielsweise Sensoren), wie etwa Plattformen 600, aufweisen, die wie ein Mini-Stapel aussehen, oder ein oder mehrere Aggregationspunkte können Informationen von diesen Edge-Geräten sammeln (beispielsweise können die Aggregationspunkte eine oder mehrere Plattformen 500 sein), und dann werden Aggregatoren zu einem IoT-Gateway gespeist, das zu einer Cloud gespeist werden kann (beispielsweise in einem IoT-Netzwerk, wie etwa eines von denen, die in den 1 bis 4 veranschaulicht sind).
In einigen Ausführungsformen (beispielsweise die, welche in den 5A, 5B, 6A und/oder 6B veranschaulicht sind) ermöglicht ein modulares Mehrplatinensystem ein Mischen unterschiedlicher aufgabenspezifischer Platinen, um eine Lösung für einen gegebenen Anwendungsfall zu erzeugen. In einigen Ausführungsformen können IoT-Edge- oder Gateway-Lösungen erstellt werden. In einigen Ausführungsformen kann das System als ein einsteckbares Sensormodul für ein Gateway verwendet werden, wobei Sensordaten gesammelt und Ressourcen berechnet werden, die in einen Zugangspunkt eingespeist werden. Drahtlose Kommunikation, drahtgebundene Kommunikation, entfernte Sensorknoten und mehrere Funkgeräte können ebenfalls von dem System unterstützt werden. In einigen Ausführungsformen ermöglicht eine modulare Systemlösung eine schnelle Evaluierung von Bestandteilsgeräten sowie eine Datensammlung für verschiedene Implementierungen, ohne größere Investition. Sobald eine optimale Konfiguration basierend auf Prototypisierung und Tests bestimmt wurde, kann eine finale hochintegrierte Lösung implementiert werden, die für die Fertigung in hohen Stückzahlen kostenoptimiert ist. Außerdem können verschiedene Modulanbieter von Sensor-, Funk- und Computerlösungen in das modulare Framework investieren, und es für eine schnelle Einführung gemeinsam entwickeln und standardisieren. Ferner kann das modulare System beispielsweise Daten in die IoT-Fog einspeisen.
In einigen Ausführungsformen (beispielsweise die, welche in den 5A, 5B, 6A und/oder 6B veranschaulicht sind) kann durch Erzeugen eines „Mischen und Anpassen“-Rahmenwerks für verschiedene Sensor-Kit-Bestandteile, die durch die Verwendung einer gemeinsamen Systembelegung vertikal oder horizontal gestapelt werden können, eine schnelle Systemlösung zur Evaluierung der Datensammlung bereitgestellt werden, die zur weiteren Datenanalyse und für Anwendungsfälle an die Fog und/oder die Cloud gesendet werden kann. In einigen Ausführungsformen kann das Verbindersystemlayout unbegrenzte Stapel und Kombinationen von Sensoren, Funkgeräten, MCUs und Batterien (oder Netzstrom) ermöglichen.
In einigen Ausführungsformen können verschiedene Standardformfaktoren verwendet werden. Beispielsweise kann ein Formfaktor für die Plattform 500, die in 5A und 5B veranschaulicht ist, zur Entwicklung und für mehrere Sensoren/Verbindungen (beispielsweise eine Sensornabe) vorgesehen sein. In einigen Ausführungsformen kann ein Formfaktor für die Plattform 500 ungefähr 2,4 Zoll mal 3 Zoll betragen. In ähnlicher Weise kann ein Formfaktor für die Plattform 600, die in 6A und 6B veranschaulicht wird, für kleine Anwendungen vorgesehen sein, die der Datenerfassung am nächsten liegt (beispielsweise ein Mini-Stapel). In einigen Ausführungsformen kann ein Formfaktor für die Plattform 600 ungefähr 1 Zoll mal 1,3 Zoll betragen. In einigen Ausführungsformen kann eine physisch größere Entwicklungskonfiguration mit vollständigen Debug-Funktionen und zahlreichen Test- und Erweiterungs-Hooks für eine schnellere System- und Softwareentwicklung verwendet werden. Diese Konfiguration kann einfach in eine viel kleinere, gestapelte Konfiguration konvertiert werden, um realistische Zwischenlösungen zur Prototypisierung und für Tests zu erstellen.
In einigen Ausführungsformen können mehrere Verbinderabstände mit variablen Stapelhöhen und Montagehardware zum Stapeln von Platinen in unterschiedlichen Größenordnungen innerhalb derselben Plattform verwendet werden. Beispielsweise können kleine Stapelverbinder (beispielsweise mit ungefähr 0,4 mm Abstand) verwendet werden, um Stapelhöhen (beispielsweise mit ungefähr 1,5 mm bis 4 mm zwischen den Platinen) für das Mini-Stapeln auf modularer Ebene zu unterstützen. Mittlere Stapelverbinder (beispielsweise mit ungefähr 0,8 mm Abstand) können verwendet werden, um Stapelhöhen (beispielsweise mit ungefähr 5 mm bis 17 mm zwischen den Platinen) für das Makro-Stapeln auf der Ebene der Basisplatine zu unterstützen. Große Stapelverbinder (beispielsweise mit ungefähr 25,4 mm Abstand) können verwendet werden, um Stapelhöhen (beispielsweise mit ungefähr 12,7 mm und 50,8 mm zwischen den Platinen) für das Stapeln von Schildern (wie beispielsweise das Arduino-Schildstapeln) zu unterstützen. In einigen Ausführungsformen werden alle Stapelverbinderpaare (beispielsweise alle mit kleinem, mittlerem und großem Teilungen) absichtlich mit Verbindern aus der gleichen Herstellerserie entworfen, jedoch mit unterschiedlichen Pinzahlen, um ein falsches Stapeln zu verhindern (beispielsweise eine polarisierte Stapelverbindung), und um während des Anbringens visuelle Hinweise auf die richtige Ausrichtung der Platine zu geben.
In einigen Ausführungsformen (beispielsweise in einigen Ausführungsformen der Plattformen 500 und/oder 600) können einzelne Platinen und Module zusammenpassende männliche und weibliche Verbinder mit vollständigem Durchgangsdesign und einer variablen Verbinderhöhe verwenden, die für die lokalen Schaltungen auf jeder Platine geeignet ist. Auf diese Weise können Platinen in beliebiger Reihenfolge gestapelt werden, ohne dass man sich Gedanken über eine physische Kollision von Komponenten machen muss. In einigen Ausführungsformen sind die Pinbelegung der Stapelverbinder unabhängig von der Funktion jeder Platine, wodurch das Stapeln verschiedener Rechen-, Konnektivitäts- und Erfassungsmodule sowie von Basissystemen und Abschirmungen, unabhängig von Funktion oder Reihenfolge ermöglicht wird. In einigen Ausführungsformen ermöglichen Seite-an-Seite angeordnete Modulstapel-Platinendesigns, dass Module seitlich gestapelt werden (d. h. nicht nur in Z-Richtung, sondern auch in X-Richtung und Y-Richtung, oder in einer Kombination davon). In einigen Ausführungsformen werden Verbinder verwendet (beispielsweise sind Verbinder in den Plattformen 500 und 600 enthalten), so dass Verbindungen nur auf eine bestimmte Weise hergestellt werden können (beispielsweise unter Verwendung von zweiseitigen Modulen und Stapelverbindern). Beispielsweise wird in einigen Ausführungsformen eine Verbinderpaarung verwendet, bei der zweiseitige Module mit Stapelverbindern auf beiden Seiten einer Platine (beispielsweise auf beiden Seiten einer Leiterplatte) ermöglichen, das innerhalb der Plattform (oder des Systems) zusätzliche Module gestapelt werden (beispielsweise oben und unten gestapelt). Beispielsweise kann die Verbinderpaarung dazu verwendet werden, dass andere Platinen, Module usw. nicht falsch eingesetzt werden können. Auf diese Weise können die Plattformen 500 und 600 ein modulares Hardware-Design aufweisen, das für Entwickler ein Plug-and-Play von Komponenten (wie etwa Modulen) von unterschiedlichen Hersteller, um IoT-Edge-Nutzungsmodelle zu unterstützen , ermöglicht. Plug-and-Play-Module können gemäß einigen Ausführungsformen implementiert werden, um unterschiedlichen Entwicklern und Herstellern zu ermöglichen, einfach zwischen unterschiedlichen Modulgeräten wechseln zu können. Dies kann beispielsweise den Austausch von Rechenlösungen, Stromversorgungslösungen, Funklösungen und/oder Sensorlösungen ermöglichen, unter anderem. Wie hierin beschrieben, können verschiedene Module (wie etwa Rechenmodule, Konnektivitätsmodule, Sensormodule, Stromversorgungsmodule usw.) so gestaltet sein, dass sie an eine entsprechende Basisplatine angeschlossen werden können (und/oder dass mehr als ein Modul und/oder mehr als eine Art von Modulen an eine Basisplatine angeschlossen werden kann).
In einigen Ausführungsformen kann ein optimaler Signalabstand und eine Abdeckung erreicht werden, indem einzelne Modulpositionen entlang von Kanten der Basisplatine ausgerichtet werden. Wenn diese Modulpositionen mit Funkmodule mit Hochfrequenz- (HF) Antennen bestückt werden, werden deren HF-Antennen auf natürliche Weise in Richtung der Kanten der Basisplatine und voneinander weggedreht. Daher kann die Basisplatine gleichzeitig mit mehreren Funkmodule mit weniger HF-Interferenzen bestückt werden, da die HF-Antennen aufgrund der Modulausrichtung physisch so weit wie möglich voneinander entfernt sind. Ausschlüsse („Keepouts“) (Platzierung und Routing) entlang der Kanten der Basisplatine stellen nicht nur die beste HF-Leistung für die HF-Antenne bereit, sondern sind auch leichter zu erreichen auf dem Basisplatinen-Design als ein Ausschluss in der Mitte der Basisplatine. In einigen Ausführungsformen können in einigen kleineren gestapelten Konfigurationen HF-Antennenausschlüsse an allen Modulen aufrechterhalten werden, einschließlich Modulen, die selbst keine Funkmodule sind. Dies kann eine vertikale Ausschlusszone über und unter den HF-Antennen eines Funkmoduls bereitstellen, wodurch ermöglicht wird, dass diese Funkmodule an einer beliebigen Stelle in dem Stapel mit der geringsten Auswirkung auf ihre HF-Antenne sitzen können.
In einigen Ausführungsformen kann Software in Verbindung mit modularen Systemen und/oder Plattformen (wie beispielsweise die Plattform 500 oder die Plattform 600) implementiert werden. In einigen Ausführungsformen möchte, wenn ein Modul an die Plattform angeschlossen ist, die Software beispielsweise sofort wissen, welche Art von Modul angeschlossen ist,. Beispielsweise kann die Software bestimmen, dass ein an die Plattform angeschlossenes Sensormodul ein Temperatursensor ist. Als Reaktion darauf wird auf eine Bibliothek von Temperatursensoren zugegriffen, um zu bestimmen, welcher Temperatursensor angeschlossen ist, und die Software kann den neu angeschlossenen Temperatursensor auch im laufenden Betrieb kalibrieren. Die Firmware kann beispielsweise zurückgespeist und aufgespielt (bzw. „flashed“) werden.
Aufgrund von Anforderungen nach geringer Leistung und einer schnellen Echtzeitausführung, die an eine tief eingebettete Firmware auf Mikrocontroller- (beispielsweise MCU) Basis gestellt werden, können einige Entwicklungsteams hoch abgestimmte und angepasste Firmware-Stacks erstellen, die als Punktlösungen enden, die nicht können einfach und schnell beispielsweise auf anderen MCUs mit unterschiedlichen CPU-Architekturen wiederverwendet werden können. Um beispielsweise einen Mangel an Portabilität und Wiederverwendbarkeit über MCU-Architekturen hinweg zu beheben, kann in einigen Ausführungsformen eine Hardware-, Firmware- und/oder Softwarearchitektur einen Datenmanager (und/oder einen intelligenten Datenrouter) verwenden, der auf einem Ziel-MCU-Anwendungsbereich ausgeführt werden kann.
In einigen Ausführungsformen kann in einer Plattform, wie beispielsweise in der Plattform 500, die in 5A und/oder 5B veranschaulicht ist, und/oder der Plattform 600, die in 6A und/oder 6B veranschaulicht ist, eine große Anzahl von möglichen Bausteinen verwendet werden, um auf einer Architektur gestapelt zu werden, beispielsweise für IoT-Edge-Geräteimplementierungen. In einigen Ausführungsformen kann die Plattform auf eine Weise angeordnet sein, dass Signale durchgelassen und nicht kurzgeschlossen werden können (beispielsweise zwischen verschiedenen Platinen und/oder zwischen verschiedenen Modulen in der Plattform). Beispielsweise können die Signale auf eine Weise weitergeleitet werden, dass sie etwas bedeuten, und die Signale sind immer Kommunikationssignale, unabhängig davon, wo die Module platziert sind. Das heißt, in einigen Ausführungsformen ist die Plattform so angeordnet, dass die Module des Stapels nicht falsch gestapelt werden können und eine korrekte Signalisierung aufrechterhalten werden kann. In einigen Ausführungsformen kann eine beliebige Anzahl von Sensoren (beispielsweise Sensormodule oder Sensorknoten) in einem Plattformstapel verwendet werden. Außerdem ist der Plattformstapel auf eine Weise implementiert, dass ein Hersteller sein Modul zu dem Stapel hinzufügen kann und es als Teil des Ökosystems hinzufügen kann. In einigen Ausführungsformen können die Plattformen batteriebetrieben, solarbetrieben und/oder netzbetrieben sein. In einigen Ausführungsformen können Abschirmungen und/oder hängende Kabel (oder Dongles) enthalten sein.
In einigen Ausführungsformen ist die Plattform austauschbar und/oder erweiterbar. In einigen Ausführungsformen können die Plattformen so verwendet werden, dass verschiedene Hersteller ihr Modul auf eine Weise in den Plattformstapel einstecken können, die ähnlich zu dem Einstecken eines Lego-Blockmoduls in die Plattform ist (beispielsweise Einstecken eines oder mehrerer Module, die ein oder mehrerer Sensormodule, ein oder mehrere Rechenmodule, ein oder mehrere Konnektivitätsmodule und/oder ein oder mehrere Stromversorgungsmodule usw. aufweisen). Die Plattform kann diese Funktionalität basierend auf mechanischen und Signalstrukturen bereitstellen, wie hier veranschaulicht und/oder beschrieben wird. Außerdem können in einigen Ausführungsformen Aktualisierungen für jedes der Module in der Plattform über die Luft („over the air“) bereitgestellt werden, so dass das richtige Aktualisierung durch das richtige Modul in der Plattform empfangen wird. Dies kann bewerkstelligt werden, ohne dass beispielsweise ein Rechenmodul über einen Rechenpfad, ein Funkmodul (oder ein Konnektivitätsmodul) über den Funkpfad (oder Konnektivitätspfad) usw. aktualisiert werden muss. Aktualisierungen können beispielsweise über Funk, drahtlos, über Kabel, über USB und/oder über andere Optionen durchgeführt werden.
In einigen Ausführungsformen können die Plattformen 500 und/oder 600 in einem drahtlosen Sensornetzwerk (WSN) enthalten sein. In einigen Ausführungsformen können die Plattformen 500 und/oder 600 in einem drahtgebundenen Netzwerk enthalten sein. Die Plattformen 500 und/oder 600 können verwendet werden, um zuvor nicht verbundene Lösungen, wie beispielsweise Rechenlösungen, Sensorlösungen, Konnektivitätslösungen, Stromversorgungslösungen usw., zu verbinden. Sie stellen eine Plattform bereit, die es beispielsweise für Sensorunternehmen einfach macht, Produkte herzustellen, die einfach mit der Plattform zu verbinden sind. Kunden können dann verschiedene Lösungen ausprobieren, um Konfigurationen in Plattformstapeln zusammenzustellen, die ihren Anforderungen entsprechen (ob beispielsweise Landwirtschaft, Einzelhandel, Industrie, Automobil usw., unter anderem). Sobald sie sich mit der Stapelung wohl fühlen, können sie zu einer Fertigungsversion der Plattform mit hohen Stückzahlen übergehen (beispielsweise unter Verwendung der Plattform 500 und/oder 600, dann die Anordnung finalisieren und alles für eine Produktion mit hohen Stückzahlen auf eine Platine bringen).
7 veranschaulicht ein System 700 gemäß einigen Ausführungsformen. Das System 700 kann eine konfigurierbare Architektur aufweisen, die auf Hardware, Software und/oder Firmware basieren kann. Die konfigurierbare Architektur kann in einem flexiblen und modularen System implementiert werden (beispielsweise innerhalb eines IoT-Systems, einer Plattform 500 und/oder 600). In einigen Ausführungsformen kann das System 700 in einem der Geräte in einer der IoT-Umgebungen der 1 bis 4 enthalten sein. In einigen Ausführungsformen kann das System 700 eine tief eingebettete Firmware (beispielsweise für ein IoT-System) aufweisen. Das System 700 weist einen Datenmanager 702, einen Datenmanager-Client 704, mehrere µ-Treiber (Mikrotreiber oder Mikro-Treiber) 706a, ..., 706n, mehrere Sensoren und/oder Geräte 708a, ... 708n und einen oder mehrere virtuelle Treiber 710 auf. In einigen Ausführungsformen kann der Datenmanager-Client 704 eine oder mehrere Anwendungen (eine oder mehrere Apps), wie etwa Softwareanwendungen, aufweisen. In einigen Ausführungsformen weist der Datenmanager 702 einen Publizierer-Abonnenten (Pub-Sub) 722, einen Client-Registrierungsmanager (CRM) 724, einen Aktualisierungsmanager 726 und einen Konfigurationsmanager (Konfig.-Manager) 728 auf. In einigen Ausführungsformen kann ein Datenmanager 702 ein Datenrouter sein. In einigen Ausführungsformen kann der Datenmanager 702 ein intelligenter Datenrouter (IDR) sei.
In einigen Ausführungsformen veranschaulicht 7 den Datenfluss, wobei ein Beispiel dafür bereitgestellt wird, wie Komponenten mit dem Datenmanager 702 (und/oder dem intelligenten Datenrouter oder IDR 702) verbunden sind, um Daten über einen Stapel (beispielsweise über einen Software-Stack und/oder im gesamten Firmware-Stack) auszutauschen. Der Datenmanager 702 kann einen Mechanismus für verschiedene Clients (wie beispielsweise Beschleunigungsmesser-Mikrotreiber, Steuerungsschaltertreiber, Umgebungserfassungsalgorithmen usw.) bereitstellen, unter anderem, um sich bei dem Datenmanager als gültiges Plugin zu registrieren, Hostsystemressourcen anzufordern, Daten/Ereignisse auf einem oder mehreren Clients zu publizieren, Ereignisbenachrichtigungen über zuvor abonnierte Ereignisse/Daten zu empfangen, und/oder Aufgaben ausführen (beispielsweise, um Routineaufgaben ausführen). Clients des Datenmanagers 702 können Komponenten-Plugin-Module oder steckbare Komponentenmodule („Component Pluggable Modules“) (CPMs) sein. Die steckbaren Komponentenmodule können allesamt eindeutige Kennungen (eindeutige ID) aufweisen, die eine Art von Anmeldeinformationen sein können, die es ihnen ermöglichen, mit dem Datenmanager 702 zu interagieren.
Der Publizierer-Abonnent 722 kann auch als Bereitsteller von Publizierer-Abonnenten-Diensten und/oder als Publizierer-Abonnenten-Router bezeichnet werden. Der Publizierer-Abonnent 722 kann eine Schnittstelle für µ-Treiber, virtuelle µ-Treiber und Anwendungen bereitstellen, um beispielsweise Daten und/oder Ereignisse zu publizieren und eine Benachrichtigung über die Verfügbarkeit zuvor abonnierter Daten und/oder Ereignisse zu empfangen. Der Publizierer-Abonnent 722 kann Daten zwischen Clients, die Daten publizieren, und Datenmanager-Clients, die zuvor die publizierten Daten abonniert haben, routen. Der Publizierer-Abonnent 722 kann einen oder mehrere µ-Treiber (beispielsweise einen oder mehrere der µ-Treiber 706a, ..., 706n und/oder virtuelle µ-Treiber 710) aktualisieren, beispielsweise aufgrund der Verfügbarkeit von Daten/Ereignissen. Steckbare Komponentenmodule (CPMs) können sich bei dem Client-Registrierungsmanager (CRM) 724 registrieren, um andere Aktualisierungen und/oder Ereignisse der CPM-Datenausgabe usw. zu empfangen.
Einer oder mehrere der µ-Treiber 706a, ..., 706n können mit einem oder mehreren Sensoren/Geräten 708a, ..., 708n unter Verwendung einer Verbindung wie beispielsweise I2C, SPI, UART, SPI, USB, GPIO, unter anderen, gekoppelt sein. Die µ-Treiber (beispielsweise einer oder mehrere der µ-Treiber 706a, ..., 706n und/oder virtuellen µ-Treiber 710) können Daten mit anderen µ-Treibern oder virtuellen µ-Treibern unter Verwendung eines Publikations-Abonnenten-Mechanismus (beispielsweise, unter Verwendung des Publizierer-Abonnenten 722) gemeinsam nutzen. Die gemeinsam genutzten Informationen können beispielsweise ein einfaches Ereignissignal oder ein Nachrichtenpuffer sein. Die µ-Treiber (beispielsweise die µ-Treiber 706a,..., 706n) können Treiber sein, die an physische Geräte gebunden sind (beispielsweise an Sensor(en)/Gerät(e) 708a,..., 708n gebunden). Die virtuellen µ-Treiber(beispielsweise ein oder mehrere µ-Treiber710) können Treiber sein, die nicht an physische Geräte gebunden sind (beispielsweise ein Block, der Metadaten generiert).
Obwohl der Client-Registrierungsmanager (CRM) 724 als von dem Publizierer-Abonnenten 722 getrennt veranschaulicht wird, ist anzumerken, dass in einigen Ausführungsformen der Client-Registrierungsmanager (CRM) 724 in dem Publizierer-Abonnenten 722 enthalten sein kann. Das Client-Registrierungsmodul (CRM) 724 kann dafür verantwortlich sein, zu validieren, ob jedes Komponenten-Plugin-Modul (CPM) ein legitimes und schnittstellenkonformes Modul ist.
Der Konfigurationsmanager 728 kann einen oder mehrere Datenmanager-Clients 704 (oder in einigen Ausführungsformen einen oder mehrere Daten-/Ereignis-Abonnenten) bereitstellen, um ein Verhalten des Datenmanagers 702 oder eines anderen Datenmanager-Clients (beispielsweise einen oder mehrere Datenmanager-Clients 704) oder einen oder mehrere Daten- /Ereignis-Publizierer zu konfigurieren. In einigen Ausführungsformen konfiguriert der Konfigurationsmanager 728 zur Laufzeit µ-Treiber (beispielsweise einen oder mehrere der µ-Treiber 706a, ..., 706n und/oder virtuellen µ-Treiber 710).
Der Aktualisierung Manager 726 kann einen oder mehrere Ereignis- /Daten-Pushs von µ-Treibern empfangen (beispielsweise von einem oder mehreren der µ-Treibern 706a, ..., 706n und/oder virtuellen µ-Treibern 710). Der Aktualisierungsmanager 726 kann Daten serialisieren und den Publizierer-Abonnenten 722 über die Verfügbarkeit von Daten/Ereignissen benachrichtigen. Der Aktualisierungsmanager 726 kann einem oder mehreren Datenmanager-Clients 704 (oder Daten-/Ereignis-Publizierern) die Möglichkeit geben, seine Daten an Abonnenten (oder Datenmanager-Clients) rundzusenden, die benachrichtigt werden möchten, wenn neue Daten von einem bestimmten Publizierer verfügbar sind. Der Aktualisierungsmanager 726 ist möglicherweise nicht dafür verantwortlich, den abonnierenden Client zu benachrichtigen, kann jedoch dafür verantwortlich sein, die publizierten Daten basierend auf von dem Abonnenten vorgewählten Datenfilteroptionen zu konditionieren. Der Aktualisierungsmanager 726 kann beispielsweise wenige vorgefertigte Filter unterstützen, aber ein Systemintegrator kann einen benutzerspezifischen Datenfilter mit einem oder mehreren Streams verbinden, die durch den Datenmanager 702 geroutet werden.
In einigen Ausführungsformen kann der Datenmanager-Client 704 (und/oder eine oder mehrere Anwendungen innerhalb des Datenmanager-Clients 704) Dinge darstellen, wie beispielsweise Clients (oder Apps), die Daten in dem Datenmanager 702 abonnieren. Der Datenmanager 702 muss nichts über den Dateninhalt wissen, kann jedoch Daten abrufen und die Daten an Geräte routen, die danach fragen. Diese Daten können von dem Datenmanager 702 mit einer Rate geroutet werden, mit der sie angefordert werden. Gerätetreiber (wie beispielsweise die Mikrotreiber 706a, ..., 706n, die virtuellen Mikrotreiber 710 usw.) können als Datenpunkte angesehen werden, die von einer Datenquelle (beispielsweise durch ein physisches Gerät, einen virtuellen Treiber usw.) generiert werden. Der Datenmanager 702 kann die Daten an die physische Welt senden und/oder etwas erstellen (beispielsweise kann er etwas auf einem Modul, wie etwa einem Rechenmodul, erstellen). Beispielsweise kann in einigen Ausführungsformen ein Gerät, wie etwa ein intelligentes Licht (und/oder eine intelligente Lichtanwendung), erstellt werden. Daten können von dem Datenmanager 702 von mehreren Datenanbietern mit einer beliebigen Rate erhalten werden, mit der diese Daten abonniert werden, und dann werden die Daten verarbeitet und gemeldet, und/oder die Daten werden verwendet, um ein Licht anzusteuern, beispielsweise basierend auf dem, was aus den Daten gelernt wird. Obwohl ein Beispiel für intelligentes Licht erwähnt wurde, wird angemerkt, dass das System generisch ist, und beliebiges auf dem System aufgebaut werden kann. In einer Ausführungsform, in der eine Bibliothek erstellt wurde (beispielsweise für einen Kunden), können der Datenmanager-Client 704 (und/oder Apps) Benutzer des Frameworks sein (beispielsweise, um neue Funktionen auf dem System-Framework aufzubauen).
In einigen beispielhaften Ausführungsformen kann der Datenmanager-Client 704 (und/oder eine Anwendung innerhalb des Datenmanager-Clients 704) Funktionen, wie etwa ein Anpassen einer Lichtintensität in einem Raum (und/oder ein Anpassen eines Farbtons eines oder mehrerer Fenster) basierend auf von außen kommenden Umgebungslichtbedingungen ausführen. Der Datenmanager-Client 704 (oder die App) kann beispielsweise eine Tageszeit und/oder ein physisches Gerät, wie etwa einen Umgebungslichtsensor und/oder einen Infrarotsensor, abonnieren und die Daten erhalten (beispielsweise die Daten über ein WLAN-Netzwerk oder über ein anderes Netzwerk erhalten). Jedes Mal, wenn eine Änderung der Daten auftritt, können die Sensoren (beispielsweise einer oder mehrere der Sensoren/Geräte 708a,..., 708n) ein Interrupt generieren, und ein Treiber, wie etwa ein Mikrotreiber (beispielsweise einer oder mehrere der Mikrotreiber 706a, ..., 706n), kann die Daten verarbeiten. Auf diese Weise kann der an den Sensor gebundene Mikrotreiber, wenn ein Sensor ein Ereignis erkennt (beispielsweise aufgrund einer Überschreitung eines Schwellenwerts), die Daten verarbeiten und ein Ereignis an der Datenmanager 702 schieben (Engl.: „push“) (beispielsweise ein Ereignis durch den Aktualisierungsmanager 726 schieben). Der Datenmanager weiß, wer diese Daten abonniert, und kann die Daten dann dem richtigen Datenclient-Manager 726 und/oder der richtigen Anwendung, die die Daten abonniert, zuführen. Mehrere Datenquellen (beispielsweise Tageszeit, ein Infrarotsensor und ein Umgebungslichtsensor) können alle der App signalisieren, und die App kann die Informationen aggregieren und eine Entscheidung treffen, die beispielsweise auf der jeweiligen Anwendung basiert. Der Anwendungsentwickler muss nicht wissen, wie die Sensoren funktionieren, und muss keine Zeit damit verbringen, herauszufinden, wie ein Treiber für das Gerät geschrieben wird. Der Datenmanager-Client (und/oder die App) muss nur wissen, nach welchen Daten er sucht. Komponenten (beispielsweise Komponenten und/oder Module des Systems 700, 500 und/oder 600) können in einer mit der Schnittstelle konsistenten Weise in das System eingesteckt werden. Der Treiber kann in einem Mikrocontroller (beispielsweise einer MCU) als Bibliothek in einem Modul vorhanden sein, und alles kann ohne zusätzliche Anforderungen der App (zusätzliche Anforderungen, wie etwa das Erstellen eines Treibers, das Wissen, wie die Sensoren funktionieren, wie der Treiber zusammengefügt wird, in welche Register geschrieben werden soll, usw.) eingesteckt werden und zusammenarbeiten. Der Datenmanager-Client und/oder die App können nur bestimmte Daten anfordern, und die Daten werden dem Datenmanager-Client und/oder der App zur Verfügung gestellt, sobald sie verfügbar sind. Der Datenmanager 702 kann den Datenmanager-Client (und/oder die App) benachrichtigen, wenn die Daten verfügbar sind, und der Datenmanager-Client (und/oder die App) kann neue Daten generieren oder eine Aufgabe ausführen usw. (beispielsweise kann der Datenmanager-Client und/oder die App die Beleuchtung und/oder den Farbton in einem oder mehreren Fenstern anpassen, in einigen beispielhaften Ausführungsformen).
Es wird angemerkt, dass die Architektur des Systems 700 flexibel ist, und dass viele Ausführungsformen möglich sind. Ausführungsformen des Systems 700 sind nicht auf die bestimmte Anordnung von Elementen in 7 beschränkt. In dem System 700 können sich der Datenmanager-Client 704 und/oder eine App auf verschiedene Arten mit Treibern und/oder Sensoren verbinden (beispielsweise in Abhängigkeit davon, wie der Datenclient-Manager 704 und/oder die App die Informationen abonnieren). Beispielsweise kann der Publizierer-Abonnent 722 mit dem Konfigurationsmanager 728 arbeiten, um einen Mikrotreiber so zu konfigurieren, dass er sich auf eine bestimmte Weise verhält. Wenn Daten verfügbar sind, kann der Mikrotreiber ein Ereignis und/oder Daten über den Pub-Sub 722 schieben (beispielsweise an den Aktualisierungsmanager 726). Der Pub-Sub 722 kann bestimmen, ob dem Datenclient-Manager 704 und/oder App Daten bereitgestellt werden sollen, wie viele Kopien erzeugt werden sollen, diese an einen oder mehrere andere Mikrotreiber (beispielsweise den Mikrotreiber 706n) und/oder an einen oder mehrere virtuelle Treiber (beispielsweise einen oder mehrere virtuelle Mikrotreiber 710) weitergeben, usw. Auf diese Weise kann 7 eine Implementierung veranschaulichen, bei der Daten von Sensor(en)/Gerät(en) 708a über den Mikrotreiber 706a durch den Aktualisierungsmanager 726 erhalten werden, und durch den Pub-Sub 722, beispielsweise basierend auf dem Abonnementstatus, an den Datenclient-Manager 704 (und/oder eine oder mehrere Apps), den Mikrotreiber 706n und/oder den virtuellen Mikrotreiber 710 bereitgestellt werden können. Andere Implementierungen sind möglich (beispielsweise in Abhängigkeit von bestimmten Ausführungsformen, basierend darauf, wer veröffentlicht und wer abonniert).
Das System 700 ermöglicht es Entwicklern, basierend auf verschiedenen Schnittstellen, unabhängig voneinander zu laufen. Falls beispielsweise ein Geräte- oder App-Entwickler seine Schnittstelle zu einer anderen App oder einem anderen Gerät veröffentlicht, kann ein Entwickler eine App einbringen und mit dem Geräte- oder App-Entwickler zusammenarbeiten. In einigen Ausführungsformen kann der Datenmanager 702 eine Hardware-, Software- und/oder Firmware-Architektur verwenden. Der Datenmanager 702 kann in einer MCU und/oder in einem Rechenmodul enthalten sein. Der Datenmanager 702 kann beispielsweise in einem der Module des Systems 500 und/oder des Systems 600 enthalten sein. Der Datenmanager 702 kann in einem Ziel-MCU-Anwendungsbereich ausgeführt werden. Dies kann beispielsweise eine Portierbarkeit und Wiederverwendbarkeit über MCU-Architekturen hinweg bereitstellen.
Der Datenmanager 702 (beispielsweise ein intelligenter Datenrouter oder IDR) kann dazu entworfen sein, bei einem Bestimmen seiner Beziehung zu anderen Komponenten in einem System (beispielsweise zu anderen Firmware-Komponenten in einem eingebetteten System) Eigenschaften des Nutzlastdatenverkehrs zu nutzen. In einigen Ausführungsformen ist das System lose gekoppelt und einfach gemacht, um andere Firmware-Komponenten dynamisch an das System binden zu können, ohne beispielsweise deren interne Struktur zu verstehen. Ein Modul (beispielsweise ein BLE-Modul) kann Daten beispielsweise an einen Algorithmus zur Erkennung menschlicher Anwesenheit senden, ohne zu wissen, welche Routinen im Treiber erforderlich sind, um Daten von dem Modul ordnungsgemäß zu erhalten.
Der Datenmanager 702 (beispielsweise ein intelligenter Datenrouter oder IDR) kann auf eine Weise aufgebaut sein, dass Firmware-Komponenten in einem eingebetteten System Faktoren, wie etwa einen datentypunabhängigen Informationsaustausch, die Komponentensitzungs-ID und/oder einen Komponenten-Aufgabenausführung-Auslöser adressieren können, beispielsweise, um effizient ausgeführt zu werden, während gleichzeitig eine Portabilität und einfache Wiederverwendung gewährleistet wird. Der Datenmanager 702 kann unabhängig von Inhalten von Dateneingaben der Komponenten sein, wobei der Datenpuffer beispielsweise Routing-Informationen enthält. Auf diese Weise können Informationen von einer Firmware-Komponente verarbeitet werden, die die Daten zuvor abonniert hat. In einigen Ausführungsformen ist eine eindeutige ID, die jeder Datenmanager-Clientkomponente zugewiesen ist, alles, was zum Senden oder Empfangen von Informationen über den Datenmanager 702 erforderlich ist. In einigen Ausführungsformen ist der Datenmanager 702 unabhängig von dem MCU-Aufgabenplaner und kann Bare-Metall-MCU und Echtzeitbetriebssystem- (RTOS) basierte Aufgabenausführungssysteme unterstützen. Der Datenmanager 702 kann mit präemptiven und nicht präventiven Firmware-Aufgabenplanern kompatibel sein.
In einigen Ausführungsformen ist eine tief eingebettete Integration von Firmware-Komponenten (beispielsweise Steuerkopplung), bei der Komponenten eng miteinander verbunden sind und eine gründlichen Kenntnis der Schnittstellen der Firmware-Komponenten und eine sorgfältige Entkopplung zur Anpassung an verschiedene andere Merkmale/Fähigkeiten erfordern, nicht erforderlich. In einigen Ausführungsformen kann eine Architektur, wie etwa eine Firmware-Architektur, verwendet werden, die ein Firmware-Framework bereitstellt, das unabhängig entwickelte, tief eingebettete Firmware-Komponenten miteinander verbinden kann, ohne komplexe Kenntnis einer inneren Funktionsweise der Komponenten zu haben.
In einigen Ausführungsformen kann ein Datenmanager oder ein intelligenter Datenrouter (beispielsweise der Datenmanager 702) als ein intelligenter Datenbroker fungieren, der für ein Routen einer Datennutzlast zwischen Firmware-Komponenten verantwortlich ist. Der Datenbroker kann es Firmware-Komponenten ermöglichen, Informationen miteinander auszutauschen, ohne dass Konstrukte (beispielsweise ohne „C“-Funktionsaufrufe) der Datenursprungs-Firmware-Komponente in die Datenziel-Firmware-Komponente eingebettet sind. Dies kann beispielsweise dazu führen, dass das System lose Daten koppelt. Diese Flexibilität stellt Entwicklern oder Systemintegratoren eine Möglichkeit bereit, tief eingebettete Firmware-Lösungen unter Verwendung von neuen Firmware-Komponenten (beispielsweise Firmware, die für ein aktuelles Projekt entwickelt wurde), bereits vorhandenen Firmware-Komponenten, und/oder von Drittanbietern entwickelten Firmware-Komponenten schnell zu erzeugen.
In einigen Ausführungsformen kann ein flexibles, lose gekoppeltes Firmware-Modul-Framework implementiert werden. Firmware-Komponenten, die von verteilten Entwicklungsteams entwickelt wurden, können zusammen integriert werden (beispielsweise zusammengeklebt werden), was beispielsweise die Codeentwicklungs- und Integrationszeit signifikant verringern kann. In einigen Ausführungsformen kann die Architektur sehr einfach skalierbar sein, wodurch Low-End-Systeme, wie etwa Bare-Metal-MCU-Designs, sowie andere Designs unterstützt werden, einschließlich eingebetteter High-End-MCU-basierter Systeme, die ein Echtzeitbetriebssystem (RTOS) verwenden. In einigen Ausführungsformen unterstützen Plug-and-Play-Bausteine eine einfache visuelle Firmware-Programmierung unter Verwendung grundlegender Firmware-Entwicklungs-IDE-(integrierte Entwicklungsumgebung) Plugins (wie beispielsweise Eclipse-Plugins). Ein einfaches Ziehen und Ablegen von Firmware-Komponenten kann implementiert werden, um Firmware-Images unter Verwendung einer grafischen Benutzeroberfläche (GUI) zu erstellen, ohne dass Klebercode geschrieben werden muss.
In einigen Ausführungsformen kann ein Firmware-Stack (oder Software-Stack), wie beispielsweise ein Stack, der Merkmale des Systems 700 und/oder des Datenmanagers 702 implementiert, sowohl mit RTOS- als auch mit Bare-Metal-MCU-basierten eingebetteten Systemen kompatibel sein, und kann zwischen RTOS- und Bare-Metal-MCU-basierten eingebetteten Systemen austauschbar sein. Der Firmware-Stack kann ein Firmware-Stack auf Anwendungsebene sein, der sich nahtlos in Systeme mit eingebetteten Echtzeitbetriebssystemen oder in Systeme mit Bare-Metal-Regelkreisen integrieren lässt. Der Stack kann Firmware-Komponenten, Schnittstellen und Entwicklungswerkzeuge aufweisen, die für die schnelle Entwicklung tief eingebetteter Firmware-basierter Systeme erforderlich sind. Die Firmware-Stack-Komponenten können Daten aus unterschiedlichen Quellen zeitnah abrufen, die Daten verfeinern und die Daten über einen Datenmanager (wie beispielsweise den Datenmanager 702) entweder an Kunden innerhalb des Frameworks oder an externe Verbraucher schieben. IDE-Entwicklungswerkzeuge können eine Umgebung bereitstellen, in der unterschiedliche Firmware-Komponenten zusammengefügt werden können, ohne die internen Konstrukte genau zu kennen. Der Firmware-Stack kann beispielsweise einen Datenmanager (oder einen intelligenten Datenrouter), wie etwa den Datenmanager 702, aufweisen, und kann zusätzlich beispielsweise ein oder mehrere Anwendungsmodule, ein oder mehrere Energieverwaltungsmodule, und/oder ein oder mehrere drahtgebundene und/oder drahtlose Anwendungsnetzwerkprotokolladapter aufweisen.
Jeder Block, der an einen Datenmanager, Datenrouter oder intelligenten Datenrouter (wie beispielsweise den Datenmanager 702) angeschlossen wird, kann ein Komponenten-Plugin-Modul sein (auch als steckbares Komponentenmodul oder CPM bezeichnet). Damit der Datenmanager 702 (oder Datenrouter oder IDR) funktioniert, kann ein vorbestimmter Vertrag zwischen den Modulen eingerichtet werden. Eine Deskriptortabelle kann verwendet werden, um ein Framework für ein CPM zu definieren, gemäß einigen Ausführungsformen. Header und andere Codes, Tabellen usw. können verwendet werden, um beispielsweise die Identität eines Moduls, wie Daten dieses Moduls geroutet werden können, Anforderungen an das Routen der Daten dieses Moduls, den Ort der Modulressourcen, usw. zu bestimmen. Beispielsweise können jeder der Sensoren in 7, der Datenmanager-Client 704 und/oder beliebige Apps in dem Datenmanager-Client 704 CPMs als Wrapper oder Schnittstelle verwenden, gemäß einigen Ausführungsformen. Beispielsweise können CPMs als Wrapper oder Schnittstelle verwendet werden, um zu ermöglichen, dass ein Gerät, eine App oder ein Treiber usw. an einen Datenmanager, Datenrouter oder IDR usw., wie etwa den Datenmanager 702, angeschlossen wird.
8 veranschaulicht Komponenten-Plugin-Module (CPMs) 800 (auch als steckbare Komponentenmodule bezeichnet) gemäß einigen Ausführungsformen. 8 zeigt drei CPMs 802, 804 und 812, aber es kann eine beliebige Anzahl von CPMs implementiert werden, gemäß einigen Ausführungsformen. Jedes der CPMs kann über Techniken, wie beispielsweise FDK (Funktionsentwicklungskit) oder WSN (drahtloses Sensornetzwerk), konfiguriert werden. Jedes der CPMs 802, 804, ..., 812 kann durch eine eindeutige Komponentenkennung (beispielsweise „APPID“) identifiziert werden. Die eindeutige Komponentenkennung kann beispielsweise durch eine eindeutige 16-Bit-Komponentenkennung identifiziert werden. Beispielsweise kann in einigen Ausführungsformen das CPM 802 mit einer Funktions-ID = 1 identifiziert werden, kann das CPM 804 mit einer Funktions-ID = 2 identifiziert werden, können andere Zwischen-CPMs zwischen CPM 804 und 812 mit anderen Funktions-IDs identifiziert werden, und kann das CPM 812 beispielsweise mit einer Funktions-ID = n identifiziert werden. In einigen Ausführungsformen kann jedes der CPMs Parameter, wie etwa Status (beispielsweise Statusvariablen), Konfiguration (beispielsweise Konfigurationsvariablen) und Verfahren aufweisen. Die Statusparameter in den CPMs können eine schreibgeschützte Parameterliste aufweisen, die die Statusinformationen eines Moduls enthält. Sie kann unter Verwendung der Intertask-Kommunikationsmechanismen des Frameworks größtenteils gemeinsam genutzt werden (beispielsweise ohne festes Format). Die Statusparameter können Statusvariablen sein, die einen aktuellen Status des CPM anzeigen. Die Konfigurationsparameter in den CPMs können eine Lese- /Schreibliste aufweisen, die die Konfigurationsinformationen eines Moduls enthält (beispielsweise Informationen, wie etwa die GPIO-Nummer, Kommunikationsport-ID, Kalibrierungs-/Konfigurationstabellen, Standardzustände, WSN-Protokoll-IDs usw.). Die Konfigurationsparameter in den CPMs können das Laufzeitverhalten des CPM bestimmen und können von einem anderen CPM oder direkt von dem Datenmanager (oder IDR) konfiguriert werden. Das Verfahrensparameter in den CPMs können einen Satz von Operationen (privat und öffentlich) aufweisen, die während der Operation eines Moduls aufgerufen werden können. Die Verfahren in den CPMs können entweder die Plugin-Anforderungen des Datenmanagers (oder IDR) erfüllen, oder eine interne Funktion ausführen.
9 veranschaulicht ein System 900 gemäß einigen Ausführungsformen. In einigen Ausführungsformen ist das System 900 ein CPM-(Komponenten-Plugin-Modul) System. Das System 900 weist mehrere Komponenten-Plugin-Module (CPMs) 902a,..., 902n (auch als steckbare Komponentenmodule bezeichnet) auf. Eine beliebige Anzahl von CPMs 902 kann in dem System 900 enthalten sein, gemäß einigen Ausführungsformen. In einigen Ausführungsformen können die CPMs 902a, ..., 902n den CPMs 802, 804, ..., 812 ähnlich oder gleich sein. Das System 900 weist auch eine Eintragsfunktionszeigertabelle 904, eine CPM-Konfigurationstabelle 906 und ein beispielhafte Gerätespeicherpartitionierung 908 auf. Es wird angemerkt, dass in einigen Ausführungsformen die Eintragsreihenfolge der CPMID in den Tabellen (beispielsweise in der Tabelle 904 und der Tabelle 906) irrelevant ist und in beliebiger Reihenfolge organisiert sein kann.
In einigen Ausführungsformen können die CPMs 902a, ..., 902n jeweils Statusparameter (oder Statusvariablen), Konfigurationsparameter (oder Konfigurationsvariablen) und Verfahren aufweisen, die beispielsweise den CPMs von 8 ähnlich sein können. Jedes CPM kann mit einem Funktionszeiger (beispielsweise Func1, ..., Funcn) der Eintragsfunktionszeigertabelle 904 verknüpft sein. In einigen Ausführungsformen kann die Eingabezeigerfunktionstabelle 904 Eintragsfunktionszeiger aufweisen, die eine CPMID (beispielsweise eine 16-Bit-CPMID) und eine CPM-Eintrags_Tabelle, in der beispielsweise Eintragsfunktionszeiger gespeichert sind, enthalten. Die Eintragsfunktionszeiger *ptr_Func1_Init(),..., *ptr_Funcn_Init()) usw. zeigen auf eine Stelle im Speicher 908, an der sich beispielsweise der CPM-Code befindet. In einigen Ausführungsformen kann der Speicher 908 eine Funktionskonfigurationstabellenpartition (FunkCfgTabelle), eine CPM-Eintragstabellenpartition (CPM_Eintrags_Tabelle), eine Heappartition, eine Stapelpartition, eine Anwendungs- und Echtzeitbetriebssystem- (App + RTOS) Partition, und eine Bootloader-Partition aufweisen. Ein Konfigurator kann aus der Tabelle 904 eine CPM_Eintrags_Tabelle.h generieren, und eine Verknüpfungs-Zeit-Partitionierung für die CPM_Eintrags_Tabelle -Partition in dem Speicher 908 bereitstellen. In einigen Ausführungsformen kann jeder CPM Konfigurationsparameter mit der CPM-Konfigurationstabelle 906 verknüpft sein. Ein Konfigurator kann aus der Tabelle 906 FuncCfgTabelle.bin generieren, und eine Verknüpfungs-Zeit-Partitionierung zu der FuncCfgTabelle-Partition des Speichers 908 bereitstellen.
In einigen Ausführungsformen verwendet ein Client-Registrierungsmanager (CRM) (wie beispielsweise der CRM 724) einen eindeutigen Identifikationscode (beispielsweise 16 bis 32 Bit, in Abhängigkeit von der Systemkonfiguration), wie etwa einen CPMID, um eine eindeutige Identifizierung jedes CPM (beispielsweise jedes CPM 902a,..., 902n) durchzuführen, und weist genügend Ressourcen zu, um die Aufgaben jedes CPM ordnungsgemäß auszuführen. Das CRM kann sich auch auf die eindeutige CPM-Kennung (CPMID) stützen, um beispielsweise die in einer Eintragsfunktionszeigertabelle gespeicherte Eintragszeigerfunktion eines CPM (beispielsweise *ptr_Func1_Init(),..., *ptr_Funcn_Init() usw.) nachzuschlagen. Eine Eingabefunktionszeigertabelle 904 kann beispielsweise für den Abschluss eines CPM-Plugin-Prozesses verantwortlich sein. Das CRM kann auch die CPMID (eindeutige CPM-Kennung) verwenden, um die Laufzeitkonfigurationsdaten eines CPM nachzuschlagen, und kann dann die Konfigurationsdaten während der Initialisierungsphase des CPM auf das Ziel-CPM kopieren. Systemdesigner können diesen Konfigurationsdatenbereich verwenden, um beliebige Informationen, wie beispielsweise die Kalibrierung, Systemlaufzeitverhaltenskonfiguration, usw., zu speichern. Zusätzlich zu einem Erhalten einer eindeutigen CPMID kann ein CPM auch eine Liste von Ereignissen in dem CRM (beispielsweise dem CRM 724) registrieren, das von einem Publizierer-Abonnenten-Router (beispielsweise durch den Publizierer-Abonnenten 722) verwendet werden kann, um den Datenaustausch zwischen CPMs zu erleichtern. Das Kombinieren des CPM-Eintragsfunktionszeigers von Tabelle 904, der CPM-Konfigurationstabelle 906 und der eindeutigen CPM-ID (CPMID) auf diese Weise kann einem Systemdesigner ein Framework bereitstellen, um die Entwicklungsphase des Anwendungscodes eines Systems von seiner Laufzeitkonfigurationsphase zu entkoppeln. Ein CPM kann somit zur Entwurfszeit oder sogar nach der Bereitstellung des Systems erzeugt und in ein eingebettetes System integriert werden.
10 veranschaulicht ein System 1000, in dem ein Komponenten-Plugin-Modul (CPM) zu Komponenten-Plugin-Modul (CPM) Datenaustausch (beispielsweise ein Ereignisdatenaustausch) implementiert werden kann, gemäß einigen Ausführungsformen. Das System 1000 weist einen Lichtsensor CPM 1002, einen intelligenten Datenrouter (IDR) 1004 und ein CPM 1006 auf. In einigen Ausführungsformen kann jedes der CPMs in 10 gleich oder ähnlich zu anderen CPMs hier sein (beispielsweise kann es gleich oder ähnlich zu einem der CPMs 802, 804, ..., 812, 902a, ..., 902n usw. sein). In einigen Ausführungsformen ist das CPM 1002 ein Lichtsensor-CPM (beispielsweise mit einer CPMID = 3). In einigen Ausführungsformen ist der intelligente Datenrouter 1004 ein Datenmanager (wie beispielsweise der Datenmanager 702). In einigen Ausführungsformen ist das CPM 1006 ein Flüssigkristallanzeige- (LCD) Treiber (beispielsweise mit einer CPMID = 20).
In einigen Ausführungsformen ist das System 1000 ein eingebettetes System, das einen Lichtsensor (CPM 1002) verdrahtet, der Lichtsensordaten an den IDR 1004 sendet. Das CPM 1006 kann ein Lichtsensor-Schwellenereignis-Abonnent sein, der mit dem IDR 1004 verdrahtet ist. Sobald der Lichtsensor des CPM 1002 einen Schwellenwert überschreitet, kann ein Ereignis generiert und an den IDR 1004 gesendet werden. Der IDR 1004 kann dann seine Abonnentendatenbank durchsuchen, um zu sehen, welche CPMID dem Lichtschwellenereignis zugeordnet wurde. Ein gültiges Abonnenten-CPM 1006 (ein LCD-Treiber mit CPMID = 20) kann dann durch den IDR 1004 über das Lichtereignis von dem Lichtsensor 1002 benachrichtigt werden.
11 veranschaulicht ein System 1100, in dem ein Komponenten-Plugin-Modul (CPM) zu Komponenten-Plugin-Modul (CPM) Datenaustausch (beispielsweise ein Ereignisdatenaustausch) implementiert werden kann, gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann ein CPM-zu-zwei-CPM-Datenaustausch (wie etwa ein Ereignisdatenaustausch) gemäß einigen Ausführungsformen implementiert werden. Das System 1100 weist einen Lichtsensor CPM 1102, einen intelligenten Datenrouter (IDR) 1104, ein CPM 1106 und ein CPM 1108 auf. In einigen Ausführungsformen kann jedes der CPMs in 11 gleich oder ähnlich zu anderen CPMs hierin sein (beispielsweise kann es gleich oder ähnlich zu einem der CPMs 802, 804, ..., 812, 902a, ..., 902n, 1002, 1006 usw. sein). In einigen Ausführungsformen ist das CPM 1102 ein Lichtsensor - CPM (beispielsweise mit einer CPMID = 2). In einigen Ausführungsformen ist der intelligente Datenrouter 1104 ein Datenmanager (wie beispielsweise der Datenmanager 702). In einigen Ausführungsformen ist das CPM 1106 ein Flüssigkristallanzeige- (LCD) Treiber (beispielsweise mit einer CPMID = 5). In einigen Ausführungsformen ist das CPM 1108 ein BLE- (Bluetooth® Low Energy) Protokolladapter (beispielsweise mit einer CPMID = 8).
In einigen Ausführungsformen ist das System 1100 ein eingebettetes System, das einen Lichtsensor (CPM 1102) verdrahtet, der ein Lichtschwellenereignis an den IDR 1104 sendet. Das System 1100 verdrahtet auch zwei Lichtschwellenereignis-Abonnenten (CPM 1106 und CPM) 1108) mit dem IDR 1104. Sobald der Lichtsensor des CPM 1102 einen Schwellenwert überschreitet, kann ein Ereignis generiert und an den IDR 1104 gesendet werden. Der IDR 1104 kann dann seine Abonnentendatenbank durchsuchen, um zu sehen, welche CPMID dem Lichtschwellenereignis zugeordnet ist. Gültige Abonnenten-CPM 1106 (ein LCD-Treiber mit CPMID = 5 und ein BLE-Protokolladapter mit einer CPMID = 8) können dann von dem IDR 1104 über das Lichtereignis von dem Lichtsensor 1102 benachrichtigt werden.
12 veranschaulicht ein System 1200, in dem ein Komponenten-Plugin-Modul (CPM) zu Komponenten-Plugin-Modul (CPM) Datenaustausch (beispielsweise ein Ereignisdatenaustausch und/oder ein gefilterter Datenaustausch) implementiert werden kann, gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann ein CPM-zu-zwei-CPM-Datenaustausch (wie etwa ein Ereignisdatenaustausch) und/oder ein gefilterter Datenaustausch implementiert werden, gemäß einigen Ausführungsformen. Das System 1200 weist einen Lichtsensor CPM 1202, einen intelligenten Datenrouter (IDR) 1204, ein CPM 1206, ein CPM 1208 und ein Vibrationsfilter 1210 (beispielsweise ein benutzerspezifisches Vibrationsfilter 1210) auf. In einigen Ausführungsformen kann jedes der CPMs in 12 gleich oder ähnlich zu anderen CPMs hierin sein (beispielsweise kann es gleich oder ähnlich zu einem der CPMs 802, 804, ..., 812, 902a, ..., 902n , 1002, 1006, 1102, 1106, 1108 usw.) sein. In einigen Ausführungsformen ist das CPM 1202 ein Vibrationssensor-CPM (beispielsweise mit einer CPMID = 10). In einigen Ausführungsformen ist der intelligente Datenrouter 1204 ein Datenmanager (wie beispielsweise der Datenmanager 702). In einigen Ausführungsformen ist das CPM 1206 ein Flüssigkristallanzeige- (LCD) Treiber (beispielsweise mit einer CPMID = 5). In einigen Ausführungsformen ist das CPM 1208 ein BLE- (Bluetooth® Low Energy) Protokolladapter (beispielsweise mit einer CPMID = 8).
In einigen Ausführungsformen ist das System 1200 ein eingebettetes System, das einen Vibrationssensor (CPM 1202) verdrahtet, der Routenausgangsvibrationsdatenablesungen an den IDR 1204 sendet. Der IDR 1204 routet eine Kopie der Vibration an ein LCD-Treiber-CPM (beispielsweise das CPM 1206). Der IDR routet auch die ausgegebenen Vibrationsdatenablesungen durch einen Filter, wie etwa einem benutzerspezifischen Vibrationsfilter (beispielsweise das Filter 1210) und routet dann den gefilterten Sensortreiber an einen BLE-Protokolladapter (beispielsweise das CPM 1208) zur Sendung an einen externen Host (beispielsweise an ein IoT-Edge-Gateway).
Obwohl hierin verschiedene beispielhafte Systeme mit einem CPM-Ereignisdatenaustausch veranschaulicht und beschrieben wurden (beispielsweise die, welche hierin in den 10 bis 12 veranschaulicht und beschrieben wurden), wird angemerkt, dass viele andere Systeme implementiert werden können, gemäß einigen Ausführungsformen. Systeme mit einem CPM-Ereignisdatenaustausch gemäß einigen Ausführungsformen sind nicht auf die in den 10 bis 12 veranschaulichten und unter Bezugnahme auf diese Zeichnungen beschriebenen beschränkt.
Einige Systeme verwenden Basissysteme und Abschirmungen mit einem festen Satz von Verbindern mit niedriger Pin-Anzahl. Es können Abschirmplatinen mit unterschiedlicher Funktionalität verwendet werden, die über einen oder zwei Anschlusspins (beispielsweise einen 3,3-V-Anschlusspin oder einen 5-V-Anschlusspin) mit Strom versorgt werden. Verbinder mit niedriger Pin-Anzahl stellen möglicherweise einen begrenzten Satz von Stromschnittstellen bereit, und der Gesamtformfaktor ist möglicherweise zu groß für das Sensorsystem. Separate Netzteile, die sich in einem anderen Strombereich als in der die Haupt-MCU befinden, werden möglicherweise nicht von den Basissystemen bereitgestellt, und ein MCU-Austausch ist möglicherweise nicht möglich, ohne das Basissystem vollständig auszutauschen. In einigen Ausführungsformen kann jedoch ein modulares System (beispielsweise ein modulares IoT-System, wie etwa ein modulares IoT-Edge-System) die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls und/oder eines Haupt-MCU-Rechenmoduls) sowie Konnektivitätsmodule und Sensormodule unterstützen.
13 veranschaulicht ein System 1300 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System 1300 in jedem anderen hier veranschaulichten und/oder beschriebenen System bereitgestellt werden. Beispielsweise kann in einigen Ausführungsformen das System 1300 in demselben System enthalten sein wie beispielsweise das System 500, das System 600 und/oder das System 700. In einigen Ausführungsformen kann das System 1300 in einem der Geräte in einer der IoT-Umgebungen der 1 bis 4 enthalten sein. Das System 1300 kann ein System sein, das die Energieversorgung für ein modulares System, wie etwa ein modulares IoT-Edge-System, bereitstellen kann. In einigen Ausführungsformen kann das System 1300 in einem modularen System (beispielsweise einem modularen IoT-System, wie etwa einem modularen IoT-Edge-System) enthalten sein, das die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmoduls, des Moduls 502 und/oder des Moduls 602) sowie von Konnektivitätsmodulen (beispielsweise Modul 504 und/oder Modul 604) und Sensormodulen (beispielsweise Modul 510 und/oder Modul 610) unterstützen kann. In einigen Ausführungsformen kann die Stromversorgung von den angeschlossenen Modulen unabhängig sein. In einigen Ausführungsformen kann eine Flexibilität bereitgestellt werden, indem beispielsweise ein Stromversorgungspfad und ein Steuersystem mit mehreren Quellen mit einem geeigneten Leistungssequenzierungsdesign verwendet werden, um das gesamte System (beispielsweise das gesamte Edge-System) mit Strom zu versorgen. Dies kann beispielsweise eine DC-Buchse, USB-Anschlüsse, PoE (Stromversorgung über Ethernet), Energy-Harvesting und/oder mehrere Batteriechemien (beispielsweise Lithiumionen, Lithiumpolymer, Alkali und andere) beinhalten.
Das System 1300 kann eine Basisplatine 1302, ein Rechenmodul 1304, ein Modul 1306 (beispielsweise ein Sensormodul 1306, ein Konnektivitätsmodul 1306 und/oder andere Zusatzmodule 1306) und ein oder mehrere Zusatzmodule auf der Platine 1308 (beispielsweise eine oder mehrere stapelbare Basis-Zusatzplatinen 1308) beinhalten. Das System 1300 kann eine MCU-unabhängige Stromversorgung bereitstellen, die durch eine eigenständige integrierte Lösung erreicht werden kann, wobei vereinfachte und benutzerfreundliche feste Schienen an der Verbindung mit der Basisplatine und anderen Modulen verbleiben.
Die Basisplatine 1302 kann Eingangsports 1312 aufweisen, die beispielsweise Zubehörverbinder (beispielsweise Zubehörkabelverbinder), wie etwa einen Verbinder, der mit 3,3 V- oder 5 V-Stromschienen verbunden werden kann, und/oder einen benutzerspezifischen Kabelverbinder aufweisen können, an dem alle gemeinsam genutzten Stromschienen repliziert werden können (beispielsweise für lange Kabellängen). Die Basisplatine 1302 kann auch Ausgangsports 1314 aufweisen, wie beispielsweise einen oder mehrere USB-Ports, eine DC-Barrel-Buchse und einen Ethernet-Port usw. Die Basisplatine 1302 kann auch eine Batterie 1316 (beispielsweise ein Lithiumpolymer- oder LiPo-Batterie, eine Alkalibatterie usw.) aufweisen. Die Basisplatine 1302 kann außerdem auch ein Batterieladegerät 1318 (beispielsweise ein Energieverwaltungsgerät) aufweisen, das zum Laden der Batterie 1316 verwendet werden kann. In einigen Ausführungsformen kann das Batterieladegerät 1318 geerntete Energie empfangen (beispielsweise unter Verwendung von Licht, Vibration und/oder oder anderer Harvested-Energy-Verfahren). Die geerntete Energie kann verwendet werden, um die Batterie 1316 zusätzlich aufzuladen. Die Basisplatine 1302 kann auch einen Leistungssequenzer (beispielsweise einen benutzerspezifischen Leistungssequenzer) aufweisen, der eine Leistungssequenzierung für mehrere Spannungsregler 1322 (beispielsweise eine beliebige Anzahl von Spannungsreglern 1322 und/oder Hochstromspannungsreglern 1322) bereitstellen kann. Die Basisplatine 1302 kann auch einen Schalter 1324, einen Schalter 1326, einen Schalter 1328 und einen oder mehrere Verbinder 1330 (beispielsweise einen oder mehrere Stapelverbinder 1330) aufweisen. In einigen Ausführungsformen können einer oder mehrere der Verbinder 1330 Verbinder für Spannungsschienen aufweisen, die eine 1,8-V-Schiene, eine 3,3-V-Schiene, eine 5-V-Schiene, eine Spannungseingangsausgangs- (V_IO) Schiene, eine Systemspannung- (VSYS) Schiene, zusätzliche Spannungsschienen, die in 13 nicht veranschaulicht sind, und/oder beispielsweise eine Vx-Spannungsschiene aufweisen. In einigen Ausführungsformen können die 1,8-V-Schiene und die 3,3-V-Schiene des Verbinders 1330 sowohl als Eingangsport als auch als Ausgangsport dienen. In einigen Ausführungsformen können die 5-V-Schiene, die V_IO-Schiene, die VSYS-Schiene, ..., und/oder die Vx-Schiene des Verbinders 1330, usw. als Ausgangsport dienen. Es wird angemerkt, dass die Basisplatine 1302 mehr Spannungsregler 1322 und Verbinder 1330 auf eine Weise aufweisen kann, die skalierbar ist und mehr Spannungen und/oder andere Spannungen als die in 13 veranschaulichten beispielhaften Spannungen unterstützen kann.
In einigen Ausführungsformen kann das Rechenmodul eines oder mehrere von dem Modul 502, dem Modul 602, einem oder mehreren MCU-Rechenmodulen und/oder einem oder mehreren Systemen-auf-Modul (SoM) sein. Das Rechenmodul 1304 kann einen oder mehrere Verbinder 1342 (beispielsweise einen oder mehrere Stapelverbinder 1342 oder einen oder mehrere modulseitige Stapelverbinder 1342) aufweisen. In einigen Ausführungsformen können einige oder alle der Verbinder 1342 mit einem jeweiligen Verbinder 1330 gekoppelt sein. In einigen Ausführungsformen können einer oder mehrere der Verbinder 1342 Verbinder für Spannungsschienen aufweisen, die eine 1,8-V-Schiene, eine 3,3-V-Schiene, eine 5-V-Schiene Beispielsweise eine Schiene, eine Spannungseingangsausgangs- (V_IO) Schiene und eine Systemspannungs- (VSYS) Schiene aufweisen. Zusätzliche Spannungsschienen, die in 13 nicht dargestellt sind, können beispielsweise in den Verbindern 1342 enthalten sein. In einigen Ausführungsformen können die 1,8-V-Schiene und die 3,3-V-Schiene der Verbinder 1342 als Ausgangsport dienen. In einigen Ausführungsformen können beispielsweise die 5-V-Schiene, die V_IO-Schiene und/oder die VSYS-Schiene der Verbinder 1342 als Eingangsport dienen. Das Rechenmodul 1304 kann auch eine integrierte Stromversorgungsschaltung 1344 und Spannungsregler 1346 (beispielsweise Spannungsregler 1346 mit integrierten passiven Komponenten) aufweisen.
Das Modul 1308 kann einen oder mehrere Verbinder 1362 (beispielsweise einen oder mehrere Stapelverbinder 1362 oder einen oder mehrere modulseitige Stapelverbinder 1362) aufweisen. In einigen Ausführungsformen können einige oder alle der Verbinder 1362 mit einem jeweiligen Verbinder 1330 gekoppelt sein. In einigen Ausführungsformen können einer oder mehrere der Verbinder 1362 Verbinder für Spannungsschienen aufweisen, die beispielsweise eine 1,8-V-Schiene, eine 3,3-V-Schiene, eine 5-V-Schiene eine Schiene, eine Spannungseingangsausgang- (V_IO) Schiene und eine Systemspannung- (VSYS) Schiene aufweisen. Zusätzliche Spannungsschienen, die in 13 nicht dargestellt sind, können beispielsweise in Verbindern 1362 enthalten sein. In einigen Ausführungsformen können beispielsweise die 1,8-V-Schiene, die 5-V-Schiene, die V_IO-Schiene und/oder die VSYS-Schiene der Verbinder 1362 als Eingangsport dienen. Das Modul 1308 kann auch Pegelumsetzer 1364 und eine integrierte Schaltung 1366 aufweisen. Die Pegelumsetzer 1364 können beispielsweise Pegelumsetzer zum Gewährleisten der Spannungskompatibilität unabhängig von dem verwendeten Sensortyp sein. Je nach Bedarf kann jedes Modul 1306 (beispielsweise jedes Sensormodul) eine oder mehrere der verfügbaren Stromschienen abgreifen.
Eine oder mehrere Zusatzplatinen 1308 können einen Anschlussblock 1382, auswählbare Quellen 1384 für Strompins und Abschirmbuchsen 1386 aufweisen. Die eine oder die mehreren Zusatzplatinen 1308 können zusätzliche Zusatzplatinen aufweisen, die Stromschienen der Verbinder 1330 bereitstellen oder diese abgreifen können.
Der Schalter 1324 der Basisplatine 1302 kann einen Ausgang entweder von einem von der MCU generierten Spannungsregler 1346 (beispielsweise über die 1,8-V-Stromschienen) oder einem auf der Basisplatine 1302 enthaltenen Spannungsregler für höherem Strom (beispielsweise einen oder mehrere der Spannungsregler 1322 oder einen anderen Spannungsregler auf der Basisplatine 1302) auswählen. Der Schalter 1326 der Basisplatine 1302 kann einen Ausgang entweder von einem von der MCU generierten Spannungsregler 1346 (beispielsweise über die 3,3-V-Stromschienen) oder einem auf der Basisplatine 1302 enthaltenen Spannungsregler mit höherem Strom (beispielsweise einem oder mehrere der Spannungsregler 1322 oder einen anderen Spannungsregler auf der Basisplatine 1302) auswählen. Der Schalter 1328 der Basisplatine 1302 kann einen Ausgang von einem ersten von der MCU generierten Spannungsregler 1346 (beispielsweise durch die 1,8-V-Stromschienen), von einem zweiten von der MCU generierten Spannungsregler 1346 (beispielsweise durch die 3,3-V-Stromschienen) auswählen) oder einen auf der Basisplatine 1302 enthaltenen Spannungsregler mit höherem Strom (beispielsweise einen oder mehrere der Spannungsregler 1322 oder einen anderen Spannungsregler auf der Basisplatine 1302) auswählen.
In einigen Ausführungsformen können ein oder mehrere Rechenmodule (beispielsweise eines oder mehrere von Modul 502, Modul 602 und/oder Modul 1304) ein oder mehrere MCU-Rechenmodule und/oder ein oder mehrere Rechensysteme-auf-Modul (ein oder mehrere Rechen-SoM) sein. Die Rechenmodule können eine vollständig integrierte Leistungssequenzierung haben, können Spannungsreglungslösungen haben, die über alle Moduldesigns hinweg standardisiert werden können, und/oder für das verwendete Rechenmodul in Bezug auf die Stromversorgungslösung von der Basisplatine transparent sein (beispielsweise von der Basisplatine 1302 oder beispielsweise von einer der in den 5A, 5B, 6A und/oder 6B veranschaulichten Platinen oder Basisplatinen).
In einigen Ausführungsformen kann eine flexible Stromversorgung erreicht werden, indem ein oder mehrere Rechenmodule (beispielsweise das Modul 1304) mit integrierten Stromversorgungen erzeugt und verwendet wird, die passive Komponenten, wie etwa Schaltinduktoren und Kondensatoren, beispielsweise für On-Chip-Spannungsregler (beispielsweise für den Spannungsregler 1346 mit integrierten passiven Komponenten) enthalten können. In einigen Ausführungsformen kann eine Leistungssequenzierungsschaltung enthalten sein, die verwendet werden kann, um zu gewährleisten, dass das Stromversorgungsubsystem wirklich eigenständig ist. Jedes Rechenmodul (beispielsweise das Modul 1304) kann als Blackbox mit mehreren gemeinsamen Eingangs- und Ausgangsspannungsschienen behandelt werden, die eine austauschbare MCU-Lösung möglich machen können. Wie in 13 veranschaulicht, können zusätzliche Pins an verschiedenen Verbindern (beispielsweise verschiedenen Stapelverbindersystemen) für andere Spannungsschienen vorgesehen sein, die nicht von dem Rechenmodul generiert werden. Dass alle Spannungsschienen für alle Module an den Stapelanschlüssen verfügbar sind, ermöglicht jedem einzelnem Modul, ein Netzteil auswählen und zu verwenden, einfach, indem es sich damit verbindet. Dadurch, dass alle Spannungen für die verschiedenen Module verfügbar sind, kann für jedes einzelne Modul auch ermöglicht werden, geeignete Spannungspegelumsetzer zu verwenden (beispielsweise, falls dies von der integrierten Schaltung benötigt wird).
In einigen Ausführungsformen kann die Wiederverwendung der Plattform auf eine Weise implementiert werden, um das Design zu beschleunigen und die Entwicklungskosten niedrig zu halten, wodurch kontinuierlich wechselnden Anforderungen Rechnung getragen wird, Skaleneffekte erzielt (beispielsweise niedrigere Teilekosten durch höhere Stückzahlen), und die Markteinführungszeit verkürzt wird. Durch Bereitstellen einer Stromversorgung über mehrere Stapelverbindersysteme, wie in 13 veranschaulicht und unter Bezugnahme auf diese beschrieben, können beispielsweise gemeinsame Plattform-Stromschienen für eine große Anzahl von Modulen verfügbar gemacht werden. Eine solche modulare Plattform kann gemeinsame, wiederverwendbare Systembestandteile bereitstellen und gleichzeitig zahlreiche unterschiedliche Systemanforderungen erfüllen (beispielsweise zahlreiche unterschiedliche Anforderungen an IoT-Edge-Systemen bedienen). Gemeinsame Module können auch der Schlüssel zur Wiederverwendung von Software und Firmware sein, wodurch das Design weiter beschleunigt und die Entwicklungskosten gesenkt werden können.
In einigen Ausführungsformen können Spannungsschienen, die in verschiedenen Verbindern von 13 veranschaulicht sind (beispielsweise die Verbinder 1330, 1342 und/oder 1362), eine E/A-Schiene, eine Systemschiene, eine 1,8-V-Schiene, eine 3,3 V-Schiene, 5-V-Schiene usw. aufweisen, und können skalierbar sein, um Schienen mit zusätzlichen und verschiedenen Spannungswerten aufzuweisen. Diese Spannungsschienen können bestimmte Pins an modularen Stapelverbindern aufweisen, die eine Brücke zwischen dem Modul (beispielsweise dem Rechenmodul 1304) und seiner Basisplatine oder Trägerplatine (beispielsweise der Platine 1302) erzeugen können. Das Rechenmodul (beispielsweise das Modul 1304) kann so gestaltet sein, dass es für seinen Strombedarf autark ist, indem es nur auf die Pins einer gemeinsamen Schiene abgreift, die an den Modulstapelanschlüssen zugewiesen sind, und verfügbare Spannungsschienen beispielsweise in Abhängigkeit von seinem On-Chip-Spannungsintegratoren bereitstellt. Die Basisplatine (beispielsweise die Basisplatine 1302) kann so konfiguriert sein, dass sie alle Schienen ergänzt, die nicht von dem Rechenmodul bereitgestellt werden, oder Hochstromschienenanforderungen erfüllt und anderen Stapelmodulen oder Basisplatinen ermöglicht, von diesen Schienen gespeist zu werden. Dies kann beispielsweise in einer Weise implementiert werden, die unabhängig von der Leistungsfähigkeit des Rechenmoduls ist.
Für Rechenmodule mit mehreren Kernen (wie beispielsweise ein Rechenmodul mit Hochleistungs- und Niederleistungs-Kernen) kann die Stromversorgungshardware eine Auswahl zwischen den beiden Kernen ermöglichen (beispielsweise für angeschlossene Peripherie-E/As und/oder zur detaillierten Leistungsregelung bei leistungsempfindlichen Systemen).
In einigen Ausführungsformen kann eine benutzerspezifische Leistungssequenzierung implementiert werden. Beispielsweise kann eine benutzerspezifische Leistungssequenzierung unter Verwendung einer Zustandsmaschine implementiert werden, die in kleine einmal programmierbare (OTP) Geräte programmiert ist, um die Startzeiten mehrerer Netzteile zu steuern (beispielsweise, um hohe Lastströme zu vermeiden, die bewirken, dass das Hauptschaltnetzteil zurückklappt oder in einem Softstart-Modus feststeckt). Basisplatinen des Systems können so gestaltet sein, dass sie alle Eingangs-/Ausgangs- (E/A) Schienen unterstützen und unterschiedliche Spannungsanforderungen erfüllen, die beispielsweise durch die Pinbelegung der Stapelverbinder definiert sind.
In einigen Ausführungsformen sind alle anderen gestapelten Module (beispielsweise Konnektivitäts- und Sensormodule, wie etwa das Modul 1306) auch mit denselben Spannungsschienen des modularen Stapelverbinders verbunden wie das Rechenmodul (beispielsweise das Modul 1304), und sind dafür gestaltet, in ihren eigenen Modulen autark sein. Auf diese Weise können sich diese Module (beispielsweise das Modul 1306) bei Bedarf auf diese gemeinsam genutzten Spannungsschienenpins an den Stapelverbindern stützen. Die Auswahl der E/A-Spannungsschienen (beispielsweise 1,8 V oder 3,3 V) für die gesamte Plattform (oder das gesamte System) kann auch durch einfache Benutzerauswahl der E/A-Schiene auf die entsprechende und verfügbare Spannungsschiene abgebildet werden.
In einigen Ausführungsformen können Modularität, Interoperabilität und Erweiterbarkeit einer Plattform oder eines Systems unter Verwendung von simultanen Stapelverbindungssystemen erreicht werden, die sich alle innerhalb derselben Plattform oder desselben Systems befinden. Stapelverbinderbelegungen für die Stromversorgung können unabhängig von der Funktion jeder Platine oder jedes Moduls sein, wodurch ein Stapeln von verschiedenen Computer-, Konnektivitäts- und Erfassungsmodulen sowie ganzer Basissysteme und Zubehörplatinen (oder Abschirmplatinen) ermöglicht wird, ungeachtet ihrer Funktion oder Stapelreihenfolge. Dies kann bewerkstelligt werden, indem beispielsweise ein vollständiges Durchgangs-Pinbelegungs-Design für jeden einzelnen Gegenstecker verwendet wird, so dass die Platinen in beliebiger Reihenfolge gestapelt werden können. Eine Steckdose mit variabler Höhe, bei der die Höhe der lokalen Schaltung auf jeder Platine entspricht, kann das Stapeln von Platinen in beliebiger Reihenfolge, ohne dass eine physische Kollision der Komponenten bedacht werden muss, ermöglichen.
In einigen Ausführungsformen kann mit einer gemeinsamen Basisplatinenstapel-Pinbelegung eine Basisplatine (beispielsweise die Basisplatine 1302) als eigenständiges System verwendet werden, oder kann unter Verwendung zusätzlicher Basisplatinen, die unter Verwendung von Basisplatinen-Makrostapeln-Verbindern zusammengesteckt, erweitert werden. Spannungsschienen können in allen Stapelverbindern in dem gesamten System unter Verwendung einer vollständigen Durchgangs-Pinbelegung bereitgestellt werden.
In einigen Ausführungsformen können Pinbelegungen für stapelbare Designs die Verwendung von temporären Test- und/oder Programmierplatinen ermöglichen. Dies kann beispielsweise die Verbindung eines Busanalysators in den modularen Stapel, der zum Beobachten und Debuggen von Busaktivitäten im System verwendet werden kann, ermöglichen. Der Analysator kann dann ohne Konsequenz oder Restschaltung entfernt werden. Beispielsweise könnte ein USB-zu-I2C-Protokollanalysator/Adapter (wie beispielsweise ein Aardvark/Beagle 3.3VI/O-Werkzeug) auf einem Interposer mit einer geeigneten modularen Pinbelegung bestückt werden, um eine Analyse (oder ein Sniffing) von 1,8 V- oder 3,3 V-Sensormodulen zu ermöglichen. In einigen Ausführungsformen kann beispielsweise das Energieversorgungssystem (beispielsweise das System 1300) das Anschließen verschiedener technischer Debugging-Werkzeuge unterstützen.
14 veranschaulicht ein System 1400 gemäß einigen Ausführungsformen. In einigen Ausführungsformen können Teile des Systems 1400 ein beliebiges anderes hier veranschaulichte und/oder beschriebene System aufweisen. In einigen Ausführungsformen ist das System 1400 ein IoT-System. In einigen Ausführungsformen kann das System 1400 in jeder der IoT-Umgebungen der 1 bis 4 enthalten sein. In einigen Ausführungsformen ist das System 1400 ein sicheres, erweiterbares Netzwerk für ein flexibles Hardware-Edge-System für das Internet der Dinge. In einigen Ausführungsformen ist das System 1400 ein sicheres, erweiterbares Netzwerk für das Internet der Dinge. Beispielsweise kann in einigen Ausführungsformen das System 1400 beispielsweise eines oder mehrere von jedem von dem System 500, System 600, System 700 und/oder System 1300 aufweisen. Das System 1400 weist mehrere Sensorknoten, wie beispielsweise die Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418 auf. In einigen Ausführungsformen können jeder oder mehrere der Sensorknoten in 14 gleich oder ähnlich zu beispielsweise einem der Systeme 500, 600, 700 oder 1300 sein. In einigen Ausführungsformen können einer oder mehrere der Sensorknoten in System 1400 beispielsweise Sensor-Edge-Geräte oder Aggregationspunkte in einem IoT-System sein. In einigen Ausführungsformen kann jedes der hier veranschaulichten und/oder beschriebenen Systeme (beispielsweise jedes der hier veranschaulichten und/oder beschriebenen modularen Systeme) Sensor-Edge-Geräte oder Aggregationspunkte in dem System 1400 sein. Das System 1400 kann auch ein Gateway 1422 und ein Gateway 1404 aufweisen. Das System 1400 kann auch einen zentralen Netzwerkkoordinator 1432 aufweisen (beispielsweise in der Cloud, in einigen Ausführungsformen). In einigen Ausführungsformen kann das System 1400 Daten von einem Edge-Gerät (wie etwa einem oder mehreren der Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418) bis zu einem Gateway (wie etwa eines oder mehrere der Gateways 1422 und 1424) und zu der Cloud (beispielsweise zum zentralen Netzwerkkoordinator 1432) übertragen.
Obwohl in 14 eine bestimmte Anzahl von Sensorknoten, Gateways und zentralen Netzwerkkoordinatoren enthalten ist, wird angemerkt, dass in einigen Ausführungsformen eine beliebige Anzahl von Sensorknoten, Gateways und sogar zentralen Netzwerkkoordinatoren enthalten sein kann. In einigen Ausführungsformen können die Sensorknoten 1402, 1404, 1406 und/oder 1408 über eine drahtgebundene oder drahtlose Kommunikation mit dem Gateway 1422 kommunizieren. In einigen Ausführungsformen können die Sensorknoten 1412, 1414, 1416 und/oder 1418 über eine drahtgebundene oder drahtlose Kommunikation mit dem Gateway 1424 kommunizieren. In einigen Ausführungsformen können das Gateway 1422 und/oder das Gateway 1424 mit dem zentralen Netzwerkkoordinator 1432 über eine drahtgebundene oder drahtlose Kommunikation kommunizieren. In einigen Ausführungsformen kann jede der drahtlosen Kommunikationen in dem System 1400 beispielsweise eine BluetoothO Low Energy (BLE), eine IEEE 802-Kommunikation, wie etwa IEEE 802.15.4, WiFi, usw. aufweisen. In einigen Ausführungsformen kann jede der drahtlosen Kommunikationen in dem System 1400 eine sichere drahtlose Kommunikation sein.
In einigen Ausführungsformen ist das System 1400 ein sicheres und erweiterbares Netzwerk. In einigen Ausführungsformen ist das System 1400 beispielsweise ein sicheres und erweiterbares Netzwerk für ein Referenz-Edge-/Fog-Sensor-Kit zum Sammeln von Daten im Internet der Dinge. In einigen Ausführungsformen kann das System 1400 einen sicheren Mechanismus für die Attestierung eines entfernten Sensorknotens bereitstellen. In einigen Ausführungsformen kann das System 1400 eine Standortverfolgung bereitstellen (beispielsweise in Innenräumen und/oder in einer Fabrik). In einigen Ausführungsformen ist das System 1400 ein lose gekoppeltes, heterogenes, drahtloses persönliches Bereichsnetzwerk (WPAN), in dem verteilte räumlich angeordnete Knoten (beispielsweise Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418) virtuell als nahtloses monolithisches WPAN-Netzwerk verwaltet werden können.
In einigen Ausführungsformen ist das System 1400 ein sicheres Netzwerk, das beispielsweise eine digitale Signaturtechnologie implementiert, die eine direkte anonyme Attestierung und Vertrauensbasis für Sensorknoten bereitstellen kann und eine sichere Bereitstellung und Attestierung von Sensorknoten ermöglichen kann. In einigen Ausführungsformen ist das System 1400 ein Netzwerk aus Gateways und Sensorknoten, das von einem Cloudbasierten zentralen Netzwerkkoordinator 1432 koordiniert wird. Das System 1400 kann eine standortbezogene Netzwerkkoordination aufweisen, die den aktuellen und zukünftigen Standort eines Netzwerkbereitstellungs-basierten drahtlosen Knotens verwaltet (beispielsweise unter Verwendung einer Ortstrajektorien-Vorhersage). Die automatische Kanalverwaltung kann gewährleisten, dass Kanäle effektiv verwaltet werden, um den Datendurchsatz zu maximieren. Die Sitzungsverwaltung (beispielsweise unter Verwendung von Knotenauthentifizierung, -vertraulichkeit und/oder -autorisierung) kann verwalten, wie Sensoren Gateways beitreten, verlassen und queren. In einigen Ausführungsformen stellt die Wiederherstellung verwaister Knoten einen Mechanismus bereit, um zuvor zugeordnete Knoten, die kürzlich verwaist sind, wiederherzustellen.
In einigen Ausführungsformen kann jeder Sensorknoten (beispielsweise jeder Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418) mit einem eigenen eindeutigen privaten Schlüssel versehen sein, der den Sensorknoten als authentisch identifizieren kann und sichere Identifikation und Vertrauen bereitstellen kann. In einigen Ausführungsformen weist das System 1400 ein heterogenes drahtloses Netzwerk (beispielsweise ein heterogenes WPAN) auf, das den Sensorknoten (beispielsweise die Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418) von verschiedenen drahtlosen Protokollen (beispielsweise drahtlose Protokolle, wie BLE, 802.15.4 usw.) die Teilnahme am Netzwerk erlauben kann. Nach dem Einschalten beginnt ein Sensorknoten (beispielsweise einer oder mehrere der Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418) in einem nicht authentifizierten Zustand und signalisiert per Funkbake („Beacon“) drahtlos seine Anwesenheit. Ein Gateway (wie beispielsweise das Gateway 1422 und/oder das Gateway 1424) kann auf Sensorknoten horchen, die darauf warten, dem Netzwerk beizutreten. Bei Erkennung wird der Knoten identifiziert, und ein sicherer Authentifizierungsprozess erfolgt. Authentifizierte Sensorknoten können dann dem Netzwerk beitreten und Konfigurations- und Betriebsparameter empfangen. Bei der Authentifizierung und Konfiguration können Sensorknoten (beispielsweise die Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und/oder 1418) Sensordaten an das Gateway (beispielsweise an das Gateway 1422 und/oder Gateway 1424) senden. Zeitmultiplex (TDM) kann verwendet werden, um drahtlose Kanäle effizient zu verwalten, den Datendurchsatz zu maximieren, und Skalierbarkeit für eine große Anzahl von Sensorknoten bereitzustellen. In einigen Ausführungsformen können Sensordaten während des Transits zwischen einem Sensorknoten (beispielsweise einem oder mehreren der Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418) und dem Gateway (beispielsweise dem Gateway und/oder Gateway 1424) verschlüsselt werden. Ein zentraler Netzwerkkoordinator (beispielsweise der zentrale Netzwerkkoordinator 1432) kann Positions- und Telemetriedaten für jeden Sensorknoten verfolgen. Der zentrale Netzwerkkoordinator 1432 kann jeden der Sensorknoten 1402, 1404, 1406, 1408, 1412, 1414, 1416 und 1418 verwalten, und neue Knoten können verwaltet, bereitgestellt und von der Cloud außer Dienst gestellt werden. In einigen Ausführungsformen kann die Sitzungsverwaltung einen reibungslosen Übergang sicherstellen, wenn sich ein Sensorknoten von der Position des einen Gateways zu einer anderen bewegt (beispielsweise zwischen den Gateways 1422 und 1424). In einigen Ausführungsformen können ein oder mehrere Fehlerzustände erkannt und gemindert werden (wie beispielsweise die Wiederherstellung eines verwaisten Sensorknotens usw.)
15 veranschaulicht eine Plattform 1500 (und/oder ein System 1500) gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann jedes der Elemente der Plattform 1500 gleich oder ähnlich zu Elementen des Systems 500, des Systems 600, des Systems 700, des Systems 1300 usw. sein. In einigen Ausführungsformen ist die Plattform 1500 eine modulare Plattform und/oder ein modulares System. In einigen Ausführungsformen ist die Plattform 1500 eine drahtlose Sensorplattform. In einigen Ausführungsformen ist die Plattform 1500 eine IoT-Plattform. In einigen Ausführungsformen kann die Plattform 1500 alles oder ein Teil eines der Geräte in einem IoT-System sein. Beispielsweise kann in einigen Ausführungsformen die Plattform 1500 alles oder ein Teil eines der Geräte in einer der IoT-Umgebungen der 1 bis 4 sein. In einigen Ausführungsformen ist die Plattform 1500 eine IoT-Sensorplattform. In einigen Ausführungsformen ist die Plattform 1500 ein IoT-Sensor-Hub. Die Plattform 1500 kann einige oder alle von einem oder mehreren Rechenmodulen 1502, einem oder mehreren Konnektivitätsmodulen 1504, einem oder mehreren Sensormodulen 1510 und einem oder mehreren Stromversorgungsmodule 1532 aufweisen. In einigen Ausführungsformen werden Verbinder in der Plattform 1500 auf eine Weise wie die in der Plattform 500, der Plattform 600, der Plattform 1300, usw. hergestellten Verbindungen verwendet. Es wird angemerkt, dass, während die Plattform 1500 hier als Plattform bezeichnet wird, sie in einigen Ausführungsformen auch als System 1500 bezeichnet werden kann.
Ähnlich den Plattformen 500 und 600 der 5A, 5B, 6A und/oder 6B ist die Plattform 1500 von 15 ein flexibles System von Platinen, um die Austauschbarkeit von Modulen, wie beispielsweise einem oder mehreren Stromversorgungsmodulen, einem oder mehreren Konnektivitätsmodulen, einem oder mehreren Rechenmodulen, einem oder mehreren Sensormodulen usw. zu erlauben. Das System 1500 ist ein modulares, konfigurierbares Sensorsystem, das mehrere MCU-Geräte aufweisen kann. In einigen Ausführungsformen kann jedes der Module und/oder MCU-Geräte in 15 und anderen hier veranschaulichten und beschriebenen Systeme einen eigenen On-Chip-Flashspeicher haben, und alle Module und/oder MCU-Geräte können mit neuer Firmware aufgerüstet werden. Aufgrund der Flexibilität des Systems können mehrere Wege zum Flashen jedes der Module und/oder MCUs bereitgestellt werden, gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System über die Luft (OTA) aktualisiert werden. Dies kann anspruchsvoller sein, wenn sich die Edge-Module/Geräte beispielsweise in mehreren drahtlosen Konfigurationen befinden.
Einige Ausführungsformen betreffen ein modulares System, das sowohl in der Hardware als auch im Typ des drahtlosen Netzwerks (beispielsweise Stern, Baum, Netz usw.) flexibel ist, und mehrere Möglichkeiten erfordert, um Firmware-Aktualisierungen für das Gerät bereitzustellen. In einigen Ausführungsformen kann die Hardware intelligent entworfen sein, um die Hardware in dem Stapel selbst zu identifizieren, und die erforderliche Firmware zuzuordnen. Möglicherweise sind mehrere OTA-Implementierungen notwendig, und die notwendige Implementierung kann sich selbst identifiziert, bevor Aktualisierungen ausgegeben („pushing out“) werden. Gemäß einigen Ausführungsformen können OTA-Aktualisierungen und ein Aufspielen („Flashen“) zur Bereitstellung von Firmware-Aktualisierungen in flexiblen Systemen, die die Hardware oder Implementierung im laufenden Betrieb ändern können, implementiert werden (wie es beispielsweise in flexiblen Systemen implementiert wird, wie hierin veranschaulicht und/oder in Bezug darauf beschrieben).
Flexible Systeme mit veränderbarer Hardware oder Implementierung, wie hierin beschrieben, können einzigartige Weisen zum Aktualisieren des gesamten Sensorsystems bereitstellen. Die Platinen selbst können mit adressierbaren elektrisch löschbaren programmierbaren Nur-Lese-Speichern (EEPROMs) ausgestattet sein, so dass eine aktuelle Konfiguration beispielsweise von einem Datensatzmanager bestimmt werden kann und ein geeigneter Code automatisch lokal aufgespielt werden kann. Eine große Vielfalt unterschiedlicher Konfigurationen ist möglich, gemäß einigen Ausführungsformen, da das Vorhandensein von Platinen (oder das Fehlen davon) flexible Aktualisierungsanordnungen sowohl über Hardware als auch über die Luft (OTA) erfordern kann. Hier beschriebene Systeme können auf schnelle Prototypisierung (beispielsweise schnelle Prototypisierung von Edge-Lösungen) abzielen, und können so entworfen sein, dass die Markteinführungszeit verkürzt wird.
Einige Ausführungsformen betreffen die flexible Aktualisierung eines Systems, was durch das Vorhandensein mehrerer MCUs, die beispielsweise dazu in der Lage sind, Master/Slave-Modi auszutauschen, verkompliziert werden kann. Das intelligente Aufspielen des geeigneten Codes kann auf den vorhandenen Platinen basieren, um zu gewährleisten, dass Hardware und Firmware übereinstimmen. Die OTA-Aktualisierung kann gemäß einigen Ausführungsformen implementiert werden, die mehrere drahtlose Netzwerkkonfigurationen handhaben (beispielsweise mehrere WPAN-Konfigurationen). In einigen Ausführungsformen kann ein Firmware-Aktualisierung eines unzuverlässigen Netzwerks implementiert werden. Beispielsweise sind Netzwerke, wie etwa IoT-Netzwerke, Maschennetzwerke, LoPAN usw. nicht sehr zuverlässig, was Herausforderungen beispielsweise für eine Aktualisierung über die Luft (OTA) bereitstellt.
16 veranschaulicht ein System 1600 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System 1600 in jedem anderen hier veranschaulichten und/oder beschriebenen System bereitgestellt werden. Beispielsweise kann in einigen Ausführungsformen das System 1600 in demselben System enthalten sein wie beispielsweise das System 500, das System 600, das System 700, das System 1300, das System 1400 und/oder das System 1500. In einigen Ausführungsformen kann das System 1600 in jeder der IoT-Umgebungen der 1 bis 4 enthalten sein. Das System 1600 kann ein modulares System, wie etwa ein modulares IoT-Edge-System, aufweisen. In einigen Ausführungsformen kann das System 1600 ein modulares System (beispielsweise ein modulares IoT-System, wie etwa ein modulares IoT-Edge-System) aufweisen, das die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmoduls, des Moduls 502, Moduls 602, Moduls 1304 und/oder des Modul 1502) sowie von Konnektivitätsmodulen (beispielsweise Modul 504, Modul 604, Modul 1306 und/oder Modul 1504) und Sensormodulen (beispielsweise Modul 510, Modul 610, Modul 1306 und/oder Modul 1510) unterstützen kann. In einigen Ausführungsformen weist das System 1600 ein flexibles, modulares Hardware-Edge-System für das Internet der Dinge (IoT) auf. In einigen Ausführungsformen kann die Firmware in dem System 1600 aktualisiert werden.
Das System 1600 kann ein System 1602 (beispielsweise ein Edge-System), ein oder mehrere Geräte 1604 und einen Computer 1606 aufweisen. Das System 1602 kann ein Rechenmodul 1622, ein Konnektivitätsmodul 1624 und ein Flashmodul 1626 aufweisen. In einigen Ausführungsformen kann das Rechenmodul 1622 gleich oder ähnlich zu einem oder mehreren Hauptrechenmodulen, einem MCU-Rechenmodul, einem Haupt-MCU-Rechenmodul, dem Modul 502, dem Modul 602, dem Modul 1304 und/oder dem Modul 1502 sein. In einigen Ausführungsformen kann das Konnektivitätsmodul gleich oder ähnlich zu einem oder mehreren von dem Modul 504, Modul 604, Modul 1306 und/oder Modul 1504 sein. In einigen Ausführungsformen kann das Flashmodul 1626 ein serielles Peripherieschnittstellen- (SPI) Flashmodul sein. In einigen Ausführungsformen können die Geräte 1604 jedes Gerät sein, das ein Signal (beispielsweise ein drahtloses Kommunikationssignal) bereitstellt. In einigen Ausführungsformen können die Geräte 1604 beispielsweise eines oder mehrere von einem Telefon/Laptop/Tablet-Computergerät 1642, einem Gateway/WLAN-Manager (beispielsweise einem Gateway/WPAN-Manager) 1644 und/oder einem Edge-Knoten 1646 (beispielsweise ein Edge-Knoten in ein Maschennetzwerk) aufweisen.
In einigen Ausführungsformen stehen ein oder mehrere Geräte 1604 über ein drahtloses Protokoll (beispielsweise über BLE oder IEEE 802.15.4) in drahtloser Kommunikation mit dem System 1602 (beispielsweise mit dem Konnektivitätsmodul 1624). Die Geräte 1604 können das drahtlose Signal bereitstellen, um eine Vielfalt von Über-die-Luft- (OTA) Flash-Aktualisierungen, wie etwa Firmware-Aktualisierungen, durchzuführen, die beispielsweise einen OTA-Rechenmodul-Flashs über die Leitung 1652 (beispielsweise ein OTA-Rechen-MCU-Flash), einen OTA-Konnektivitätsmodul-Flash über die Leitung 1654 (beispielsweise einen OTA-Konnektivitätsmodul-Flash über das Flashmodul 1626) und/oder einen direkten OTA-Konnektivitätsmodul-Flash über die Leitung 1656 (beispielsweise einen direkten OTA-Konnektivitätsmodul-Flash) aufweisen.
In einigen Ausführungsformen weist das System 1602 einen Rechenmodul-USB-Port 1662 (beispielsweise einen MCU-USB-Port), einen USB-Port 1664 (beispielsweise einen FTDI-USB-Port), einen Wandlerchip 1666 (beispielsweise einen FTDI zu JTAG-Wandlerchip und/oder einem FTDI-Chip), einen Header 1668 (beispielsweise einen 10-poligen JTAG-Header) und einen Eingangs-/Ausgangs-Bit-Bang-Multiplexer 1670 (beispielsweise einen I/O-Bit-Bang-Mux, einen Allzweck-I/O-Bit-Bang-Mux und/oder einen GPIO-Bit-Bang-Mux) auf. In einigen Ausführungsformen weist das Rechenmodul 1622 einen Testport 1672 (beispielsweise einen gemeinsamen Testaktionsgruppenport und/oder einen JTAG-Port) und einen On-Chip-Flashspeicher 1674 auf. In einigen Ausführungsformen weist das Konnektivitätsmodul 1624 einen Serial-Wire-Debug- (SWD) Port 1682 und ein On-Chip-Flashspeicher 1684 auf. In einigen Ausführungsformen weist das System 1600 auch einen Debugger 1690 (beispielsweise einen JTAG-Debugger) auf.
In einigen Ausführungsformen ist der Computer 1606 mit dem USB-Port 1664 gekoppelt, um einen Rechenmodul-Flash über den USB-Port 1604, den Konverter 1606 und den JTAG-Port 1672 zu dem On-Chip-Flashspeicher 1674 bereitzustellen. In einigen Ausführungsformen ist der Computer 1606 mit dem USB-Port 1662 gekoppelt, um einen Konnektivitätsmodul-Flash über den USB-Port 1662, den E/A-Bit-Bang 1670 und dem Serial-Wire-Debug 1682 zu dem On-Chip-Flashspeicher 1684 bereitzustellen. Es wird angemerkt, dass in einigen Ausführungsformen bei diesem Flash ein Bootloader vorinstalliert sein kann. In einigen Ausführungsformen ist der Computer 1606 mit dem Debugger 1690 gekoppelt, um einen Konnektivitätsmodul-Flash über den Debugger 1690, den Header 1668 und den Serial-Wire-Debug 1682 zu dem On-Chip-Flashspeicher 1684 bereitzustellen.
17 veranschaulicht ein System 1700 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System 1700 in jedem anderen hier veranschaulichten und/oder beschriebenen System bereitgestellt werden. Beispielsweise kann in einigen Ausführungsformen das System 1700 in demselben System wie das System 500, das System 600, das System 700, das System 1300, das System 1400, das System 1500 und/oder das System 1600 enthalten sein. In einigen Ausführungsformen kann das System 1700 in jeder der IoT-Umgebungen der 1 bis 4 enthalten sein. Das System 1700 kann ein modulares System, wie etwa ein modulares IoT-Edge-System, aufweisen. In einigen Ausführungsformen kann das System 1700 ein modulares System (beispielsweise ein modulares IoT-System, wie etwa ein modulares IoT-Edge-System) aufweisen, das die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmodul, des Moduls 502, Moduls 602, Moduls 1304 und/oder Moduls 1502) sowie von Konnektivitätsmodulen (beispielsweise Modul 504, Modul 604, Modul 1306 und/oder Modul 1504) und Sensormodulen (beispielsweise Modul 510, Modul 610, Modul 1306 und/oder Modul 1510) unterstützen kann. In einigen Ausführungsformen weist das System 1600 ein flexibles, modulares Hardware-Edge-System für das Internet der Dinge (IoT) auf. In einigen Ausführungsformen kann die Firmware in dem System 1700 aktualisiert werden.
Das System 1700 kann ein System 1702 (beispielsweise ein Edge-System), ein oder mehrere Geräte 1704, und einen Computer 1706 aufweisen. Das System 1702 kann ein kombiniertes Rechen-/Konnektivitätsmodul 1722 und ein Flashmodul 1726 aufweisen. In einigen Ausführungsformen kann das Rechen-/Konnektivitätsmodul 1722 die gleichen oder ähnliche Funktionalität und Merkmale aufweisen wie eines oder mehrere eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmoduls, des Moduls 502, des Moduls 602, des Moduls 1304, des Moduls 1502, des Moduls 504, des Moduls 604, des Moduls 1306 und/oder des Moduls 1504. In einigen Ausführungsformen kann das Flashmodul 1726 ein Flashmodul mit serieller Peripherieschnittstelle (SPI) sein. In einigen Ausführungsformen können die Geräte 1704 jedes Gerät sein, das ein Signal (beispielsweise ein drahtloses Kommunikationssignal) bereitstellt. In einigen Ausführungsformen können die Geräte 1704 beispielsweise eines oder mehrere von einem Telefon/Laptop/Tablet-Computergerät 1742, einem Gateway/WLAN-Manager (beispielsweise einem Gateway/WPAN-Manager) 1744 und/oder einem Edge-Knoten 1746 (beispielsweise einem Edge-Knoten in einem Maschennetzwerk) sein.
In einigen Ausführungsformen stehen ein oder mehrere Geräte 1704 in drahtloser Kommunikation mit dem System 1602 (beispielsweise mit dem Rechen-/Konnektivitätsmodul 1722) über ein drahtloses Protokoll (beispielsweise über BLE oder IEEE 802.15.4). Die Geräte 1704 können das drahtlose Signal bereitstellen, um eine Vielfalt von Über-die-Luft- (OTA) Flash-Aktualisierungen, wie beispielsweise Firmware-Aktualisierungen, durchzuführen, die beispielsweise einen OTA-Flash über die Leitung 1754 (beispielsweise einen OTA-SoC-Flash und/oder eines OTA-Moduls-Flash durch das Flashmodul 1726) und/oder einen direkten OTA-Modul-Flash über die Leitung 1756 (beispielsweise einen direkten OTA-SoC-Flash) aufweisen.
In einigen Ausführungsformen weist das System 1702 einen Modul-USB-Port 1762 (beispielsweise einen MCU-USB-Port) und einen Header 1768 (beispielsweise einen 10-poligen JTAG-Header) auf. In einigen Ausführungsformen weist das Berechnungs-/Konnektivitätsmodul 1722 einen SWD-Port 1682 (Serial Wire Debug) und einen On-Chip-Flashspeicher 1792 auf. In einigen Ausführungsformen weist das System 1600 auch einen Debugger 1790 (beispielsweise einen JTAG-Debugger) auf.
In einigen Ausführungsformen ist der Computer 1706 mit dem USB-Port 1762 gekoppelt, um einen Rechen-/Konnektivitätsmodul-Flash über den USB-Port 1762 zu dem On-Chip-Flashspeicher 1792 bereitzustellen. Es wird angemerkt, dass in einigen Ausführungsformen dieser Flash einen voraufgespielten Bootloader auf dem Rechen-/Konnektivitätsmodul 1722 beinhalten kann. In einigen Ausführungsformen ist der Computer 1706 mit dem Debugger 1790 gekoppelt, um einen Rechen-/Konnektivitätsmodul-Flash über den Debugger 1790, den Header 1768 und den Serial-Wire-Debug 1782 zu dem On-Chip-Flashspeicher 1792 bereitzustellen.
Das System 1600 von 16 und das System 1700 von 17 richten Programmierpfade zum Aktualisieren der Firmware ein (beispielsweise von einer einzelnen Werkzeug- und Host-Verbindung). Jedes Gerät (beispielsweise ein Modul oder SoC) kann die Flexibilität haben, unter Verwendung seiner nativen, vom Hersteller bereitgestellten Programmierwerkzeuge und seiner Software aktualisiert zu werden. Beispielsweise kann eine MCU auf dem Rechenmodul (oder einer Rechenkarte oder einem Rechensystem auf dem Modul) physisch mit einem integrierten Funkgerät auf dem Kommunikationsmodul gepaart sein. Um das Kommunikationsmodul (beispielsweise das Konnektivitätsmodul 1624) zu aktualisieren, kann das Rechenmodul als eine einzelne Schnittstelle zum Programmieren verwendet werden. Eine MCU des Kommunikationsmoduls (beispielsweise On-Chip-Flashspeicher an dem Konnektivitätsmodul 1624) kann von dem Rechenmodul (beispielsweise dem Rechenmodul 1622) beispielsweise durch Bit-Banging der Programmierpins des Konnektivitätsmoduls/Kommunikationsmoduls (beispielsweise Bit-Banging der Programmierpins des Konnektivitätsmoduls 1624 unter Verwendung des GPIO-Bit-Bang 1670) aufgespielt werden. Alternativ können die Programmierpins des Konnektivitätsmoduls 1624 parallel zu dem SWD- (Serial Wire Debug) Verbinder 1682 für die Standalone-Programmierung mit den Werkzeugen des Herstellers verbunden sein (beispielsweise über den Debugger 1690 und den Header 1668). In einigen Ausführungsformen kann die Bestimmung, welche Programmierschnittstelle verwendet wird, von dem Benutzer durch Schalter wählbar sein (beispielsweise unter Verwendung von zwei Inline-Gehäuseschaltern oder DIP-Schaltern), die den Rest und den GPIO-Bit-Banging-Mux 1670 steuern.
In einigen Ausführungsformen kann aufgrund der Flexibilität des Systems (beispielsweise eines flexiblen modularen Systems) und des potenziell begrenzten Speichers, der auf der MCU verfügbar ist, nur Code, der für den vorliegenden Satz von Platinen benötigt wird, während des Aufspielens für das System aufgespielt werden. Wenn beispielsweise ein Drucksensor in dem System vorhanden ist, aber kein Temperatursensor in dem System vorhanden ist, kann das System die Firmware für den Drucksensor automatisch erkennen und nur die Firmware für den Drucksensor aufspielen, und kann die Firmware für den Temperatursensor entfernen. Dies kann unter Verwendung von adressierbaren EEPROMs auf den Basisplatinen und Modulen implementiert werden, damit ein EEPROM-Datensatzmanager einzelne nützliche Platineninformationen und Verbindungsinformationen speichern kann, sodass das System automatisch bestimmen kann, welche Module verbunden sind und welche Verbindungen daher benötigt werden. Die geeignete Firmware kann nach Bestimmung der in dem System vorhandenen Platinen und/oder Module aufgespielt werden. Auf diese Weise kann das System bestimmen, dass die Firmware mit der in dem System vorhandenen Hardware zusammenpasst.
In einigen Ausführungsformen können Geräte, Module, SoCs usw. auch über die Luft (OTA) programmiert werden. Diese Funktionalität ist möglicherweise für Funkgeräte, Module, SoCs usw. (wie beispielsweise das Konnektivitätsmodul 1624) möglich, muss jedoch möglicherweise zusätzlich für andere Geräte, Module, SoCs usw. (beispielsweise andere Geräte der MCU-Klasse), die keine On-Chip-Funkfunktionen haben, erzeugt werden. In einigen Ausführungsformen kann gewährleistet werden, dass ein OTA-Programm ohne Beschädigung empfangen wird, indem der On-Chip-Flashspeicher-Speicher so partitioniert wird, dass ein gültiger programmierbarer Bereich immer intakt ist, während ein neues Programm empfangen und verifiziert wird. Der Speicherplatz für ein OTA-fähiges Programm kann immer in Reserve gehalten werden, jedoch kann dies die Programmgröße des Geräts einschränken. In einigen Ausführungsformen kann ein externes Flash-Gerät (beispielsweise ein externes SPI-Flash-Gerät, ein Flashmodul 1626 und/oder ein Flashmodul 1726) verwendet werden, das eine eingehende Aktualisierung speichern kann. Ein solches externes Flash-Gerät kann den verfügbaren Code-Speicherplatz für das System erhöhen. Falls andere Geräte, Module, SoCs usw. in dem System durch das Hauptrechenmodul (beispielsweise dem Haupt-MCU-Rechensystem auf dem Modul) programmierbar sind, dann kann unter Verwendung eines einzelnen Flashspeichermoduls (beispielsweise eines externen SPI-Flash-Geräts, dem Flashmodul 1626 und/oder dem Flashmodul 1726) die volle Programmspeichergröße jedes Geräts, Moduls, SoCs usw. in dem System vergrößert werden, während weiterhin eine OTA-Fähigkeit bereitgestellt wird. Die Aktualisierung (beispielsweise Firmware-Aktualisierung) kann drahtlos bereitgestellt werden (beispielsweise von einem Gerät, wie etwa dem Telefon/Tablet/Laptop 1642, dem Gateway/Drahtlos-Manager 1644, dem Edge-Knoten 1646, dem Telefon/Tablet/Laptop 1742, dem Gateway/Drahtlos-Manager 1744 und/oder dem Edge-Knoten 1746 über ein Modul, wie etwa dem Modul 1622 und/oder dem Modul 1722, an ein Flashmodul, wie dem Flashmodul 1626 und/oder dem Flashmodul 17256), und im Flash-Speicher gespeichert werden (beispielsweise gespeichert in dem SPI-Flash-Speicher, dem Flashmodul 1626, dem Flashmodul 1726, dem On-Chip-Flashspeicher 1674, dem On-Chip-Flashspeicher 1684 und/oder dem On-Chip-Flashspeicher 1792). Sobald das Rechenmodul vollständig in dem Flash-Speicher gespeichert und validiert ist, kann es ein anderes Gerät, Modul und/oder SoC usw. zurücksetzen, um das neue Firmware-Upgrade durchzuführen.
In einigen Ausführungsformen können in Abhängigkeit von der Konfiguration des Systems das Funkgerät, das Modul und/oder der SoC usw. (beispielsweise das Konnektivitätsmodul 1624) möglicherweise leistungsfähiger sein als das/der Rechengerät, -modul, der -SoC usw. (beispielsweise das MCU-Rechen-SoM und/oder das Rechenmodul 1622 usw.). In einer solchen Implementierung kann das modulare System so entworfen sein, dass das/der Funkgerät/Modul/SoC (beispielsweise das Konnektivitätsmodul 1624) auch in der Lage ist, das Rechenmodul (beispielsweise das MCU-Rechen-SoM und/oder das Rechenmodul 1622) zurückzusetzen. Dies kann unter Verwendung von analogen Schaltungen (z. B. unter Verwendung von Bipolartransistorpaaren oder BJT-Paaren) bewerkstelligt werden, um zu ermöglichen, dass jedes Modul, Gerät, SoC usw. das andere zurücksetzen kann, während es von einem Zurücksetzen des Hauptsystems entkoppelt wird. Dies ist in 16 beispielsweise durch die Rücksetzleitungen zwischen dem Rechenmodul 1622 und dem Konnektivitätsmodul 1624 veranschaulicht. Eine solche Mehrfachrücksetzfunktionalität kann in modularen Systemen verwendet werden, die die Fähigkeit haben, sich weiterzuentwickeln.
Gemäß einigen Ausführungsformen können Systeme in einer Vielzahl unterschiedlicher Netzwerkkonfigurationen verteilt sein. Beispielsweise können gemäß einigen Ausführungsformen Systeme in verschiedenen Konfigurationen bereitgestellt werden, die Stern-, Baum-, Netz-, Kaskaden- und/oder Direktzugriffsbereitstellungen aufweisen. In einigen Ausführungsformen kann eine standortübergreifende verteilte Drahtlosnetzwerk- (beispielsweise ein WPAN) Über-die-Luft- (OTA) Firmware-Aktualisierung über verschiedene drahtlose Protokolle implementiert werden, die unter anderem beispielsweise Bluetooth Low Energy (BLE), eine drahtloses Personal Bereichsnetzwerk (WPAN), eine drahtloses Personal Area Network (LoPAN) mit geringem Stromverbrauch, ein drahtloses IPv6 Personal Area Network mit geringem Stromverbrauch (6LoWPAN), Thread, ZigBee, IEEE 802.15.4e usw. aufweisen.
In einigen Ausführungsformen kann eine kaskadierende OTA-Aktualisierung (beispielsweise eine Firmware-Aktualisierung) beispielsweise in vermaschten oder baumbasierten Netzwerken implementiert werden. Die Firmware-Aktualisierung kann mit einem oder mehreren Knoten beginnen, die direkt mit dem Drahtlos-Manager verbunden sind (beispielsweise einem WPAN-Manager), sobald der/die Knoten ein Firmware-Aktualisierung abgeschlossen haben. Die Aktualisierung wird in Zusammenarbeit mit dem Drahtlos-Manager fortgesetzt, um die Firmware des/der nebenliegenden Knotens/Knoten und/oder der Knoten in seinem Teilbaum zu aktualisieren. Die Firmware kann von Knoten zu Knoten weitergegeben werden, oder, wenn die Entfernung es zulässt, können die Knoten vorübergehend eine Verbindung zu dem Drahtlos-Manager herstellen.
In einigen Ausführungsformen kann eine Sternkonfigurations-OTA-Aktualisierung (beispielsweise ein Firmware-Aktualisierung) implementiert werden. Bei jedem aktivierten Knoten wird das Firmware-Image direkt durch den Drahtlos-Manager (beispielsweise durch einen WPAN-Manager) aktualisiert. Dies erfordert keine Vernetzung, und eine Zusammenarbeit mit anderen Knoten ist nicht erforderlich.
In einigen Ausführungsformen kann eine Direktzugriffs-OTA-Aktualisierung (beispielsweise ein Firmware-Aktualisierung) implementiert werden. Ein Direktzugriffs-OTA-Aktualisierung kann ähnlich zu einer Sternkonfigurations-OTA-Aktualisierung sein. Bei einer Direktzugriffs-OTA-Aktualisierung können andere Knoten den Drahtlos-Manager (beispielsweise einem WPAN-Manager) beim Routen der Firmware-Aktualisierung-Pakete an den Zielknoten unterstützen.
18 veranschaulicht ein System 1800 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System 1800 ein beliebiges anderes System, Plattform, Module usw., die hier veranschaulicht und/oder beschrieben sind, aufweisen. Beispielsweise kann in einigen Ausführungsformen das System 1800 beispielsweise eines der Elemente des Systems 500, des Systems 600, des Systems 700, des Systems 1300, des Systems 1400, des Systems 1500, des Systems 1600 und/oder des Systems 1700 aufweisen. In einigen Ausführungsformen kann das System 1800 in jeder der IoT-Umgebungen der 1 bis 4 enthalten sein. In einigen Ausführungsformen ist das System 1800 ein Netzwerk in einer Maschennetzwerkkonfiguration. In einigen Ausführungsformen kann eine OTA-Aktualisierung (beispielsweise ein OTA-Firmware-Aktualisierung) in dem System 1800 implementiert sein.
Das System 1800 weist einen Drahtlos-Manager 1802 (beispielsweise einen WPAN-Manager 1802) und Knoten 1804, 1806, 1808, 1810, 1812 und 1814 (beispielsweise Edge-Knoten 1804, 1806, 1808, 1810, 1812 und 1814) auf. Es wird angemerkt, dass das System 1800 eine beliebige Anzahl von Funkmanagern und eine beliebige Anzahl von Knoten aufweisen kann, und Ausführungsformen sind nicht auf die Anordnung oder Anzahl von Elementen von 18 beschränkt. In einigen Ausführungsformen können einer oder mehrere der Knoten 1804, 1806, 1808, 1810, 1812 und 1814 ein modulares System (beispielsweise ein modulares IoT-System, wie etwa ein modulares IoT-Edge-System) aufweisen, das die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmoduls, des Moduls 502, des Moduls 602, des Moduls 1304, des Moduls 1502, des Moduls 1622 und/oder des Moduls 1722) sowie von Konnektivitätsmodulen (beispielsweise Modul 504, Modul 604, Modul 1306, Modul 1504, Modul 1624 und/oder Modul 1722) und Sensormodulen (beispielsweise Modul 510, Modul 610, Modul 1306 und/oder Modul 1510) unterstützen kann. In einigen Ausführungsformen können einer oder mehrere der Knoten 1804, 1806, 1808, 1810, 1812 und 1814 ein flexibles, modulares Hardware-Edge-System für das Internet der Dinge (IoT) aufweisen. In einigen Ausführungsformen kann die Firmware in dem System 1800 aktualisiert werden (beispielsweise ein OTA-Firmware-Aktualisierung).
In 18 kann der Drahtlos-Manager 1802 jeden der Knoten 1804, 1806, 1808, 1810, 1812 und 1814 unter Verwendung der hier beschriebenen OTA-Firmware-Aktualisierung aktualisieren (beispielsweise können einer oder mehrere der Knoten 1804, 1806, 1808, 1810, 1812 und 1814 unter Verwendung von Techniken, die in Bezug auf 16 oder 17 veranschaulicht und/oder beschrieben sind, OTA-aktualisiert werden und/oder einer oder mehrere der Knoten 1804, 1806, 1808, 1810, 1812 und 1814 können gleich oder ähnlich zu dem System 1602 und/oder dem System 1702 sein). In einigen Ausführungsformen können beliebige Geräte, Module, MCUs, SoCs usw. eines der Knoten 1804, 1806, 1808, 1810, 1812 und 1814 beispielsweise unter Verwendung von Techniken, die in Bezug auf 16 oder 17 veranschaulicht und/oder beschrieben sind, OTA-aktualisiert werden. Die Pfeile in 18 veranschaulichen einen von vielen möglichen Aktualisierungspfaden für die OTA-Aktualisierung, die den Knoten 1804, 1806, 1808, 1810, 1812 und/oder 1814 bereitgestellt werden.
19 veranschaulicht ein System 1900 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System 1900 ein beliebiges andere hier veranschaulichte und/oder beschriebene System, Plattform, Module usw. aufweisen. Beispielsweise kann in einigen Ausführungsformen das System 1900 beispielsweise eines der Elemente des Systems 500, des Systems 600, des Systems 700, des Systems 1300, des Systems 1400, des Systems 1500, des Systems 1600 und/oder des Systems 1700 aufweisen. In einigen Ausführungsformen kann das System 1900 in jeder der IoT-Umgebungen der 1 bis 4 enthalten sein. In einigen Ausführungsformen ist das System 1900 ein Netzwerk in einer Sternnetzwerkkonfiguration. In einigen Ausführungsformen kann eine OTA-Aktualisierung (beispielsweise ein OTA-Firmware-Aktualisierung) in das System 1900 implementiert werden.
Das System 1900 weist einen Drahtlos-Manager 1902 (beispielsweise einen WPAN-Manager 1902) und Knoten 1904, 1906, 1908, 1910 und 1912 (beispielsweise Edge-Knoten 1904, 1906, 1908, 1910 und 1912) auf. Es wird angemerkt, dass das System 1900 eine beliebige Anzahl von Funkmanagern und eine beliebige Anzahl von Knoten aufweisen kann, und Ausführungsformen nicht auf die Anordnung oder Anzahl von Elementen von 19 beschränkt sind. In einigen Ausführungsformen können einer oder mehrere der Knoten 1904, 1906, 1908, 1910 und 1912 ein modulares System (beispielsweise ein modulares IoT-System, wie etwa ein modulares IoT-Edge-System) aufweisen, das die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmoduls, des Moduls 502, des Moduls 602, des Moduls 1304, des Moduls 1502, des Moduls 1622 und/oder des Moduls 1722) sowie von Konnektivitätsmodulen (beispielsweise Modul 504, Modul 604, Modul 1306, Modul 1504, Modul 1624 und/oder Modul 1722) und Sensormodulen (beispielsweise Modul 510, Modul 610, Modul 1306 und/oder Modul 1510) unterstützen kann. In einigen Ausführungsformen können einer oder mehrere der Knoten 1904, 1906, 1908, 1910 und 1912 ein flexibles, modulares Hardware-Edge-System für das Internet der Dinge (IoT) aufweisen. In einigen Ausführungsformen kann die Firmware in dem System 1900 aktualisiert werden (beispielsweise eine OTA-Firmware-Aktualisierung).
In 19 kann der Drahtlos-Manager 1902 jeden der Knoten 1904, 1906, 1908, 1910 und 1912 unter Verwendung der hier beschriebenen OTA-Firmware-Aktualisierung aktualisieren (beispielsweise können einer oder mehrere der Knoten 1904, 1906, 1908, 1910 und 1912 unter Verwendung von Techniken, die in Bezug auf 16 oder 17 veranschaulicht und/oder beschrieben sind, OTA-aktualisiert werden, und/oder einer oder mehrere der Knoten 1904, 1906, 1908, 1910 und 1912 können gleich oder ähnlich zu dem System 1602 und/oder dem System 1702 sein). In einigen Ausführungsformen können beliebige Geräte, Module, MCUs, SoCs usw. von einem der Knoten 1904, 1906, 1908, 1910 und 1912 beispielsweise unter Verwendung von Techniken, die in Bezug auf 16 oder 17 veranschaulicht und/oder beschrieben sind, OTA-aktualisiert werden. Die Pfeile in 19 veranschaulichen mögliche Aktualisierungspfade für die OTA-Aktualisierung, die den Knoten 1904, 1906, 1908, 1910 und/oder 1912 bereitgestellt werden.
20 veranschaulicht ein System 2000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System 2000 ein beliebiges andere hier veranschaulichte und/oder beschriebene System, Plattform, Module usw. aufweisen. Beispielsweise kann in einigen Ausführungsformen das System 2000 beispielsweise eines der Elemente des Systems 500, des Systems 600, des Systems 700, des Systems 1300, des Systems 1400, des Systems 1500, des Systems 1600 und/oder des Systems 1700 aufweisen. In einigen Ausführungsformen kann das System 2000 in jeder der IoT-Umgebungen der 1 bis 4 enthalten sein. In einigen Ausführungsformen ist das System 2000 ein Netzwerk in einer OTA-Beispielkonfiguration mit direkter Adresse. In einigen Ausführungsformen kann ein OTA-Aktualisierung (beispielsweise eine OTA-Firmware-Aktualisierung) in dem System 2000 implementiert werden.
Das System 2000 weist einen Drahtlos-Manager 2002 (beispielsweise einen WPAN Manager 2002) und die Knoten 2004, 2006, 2008 und 2010 (beispielswiese Edge-Knoten 2004, 2006, 2008 und 2010) auf. Es wird angemerkt, dass das System 2000 eine beliebige Anzahl von Funkmanagern und eine beliebige Anzahl von Knoten aufweisen kann, und Ausführungsformen sind nicht auf die Anordnung oder Anzahl von Elementen von 20 beschränkt. In einigen Ausführungsformen können einer oder mehrere der Knoten 2004, 2006, 2008 und 2010 ein modulares System (beispielsweise ein modulares IoT-System, wie etwa ein modulares IoT-Edge-System) aufweisen, das die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmoduls, des Moduls 502, des Moduls 602, des Moduls 1304, des Moduls 1502, des Moduls 1622 und/oder des Moduls 1722) sowie von Konnektivitätsmodulen (beispielsweise Modul 504, Modul 604, Modul 1306, Modul 1504, Modul 1624 und/oder Modul 1722) und Sensormodulen (beispielsweise Modul 510, Modul 610, Modul 1306 und/oder Modul 1510) unterstützen kann. In einigen Ausführungsformen können einer oder mehrere der Knoten 2004, 2006, 2008 und 2010 ein flexibles, modulares Hardware-Edge-System für das Internet der Dinge (IoT) aufweisen. In einigen Ausführungsformen kann die Firmware in dem System 2000 aktualisiert werden (beispielsweise eine OT A-Firmware-Aktualisierung).
In 20 kann der Drahtlos-Manager 2002 jeden der Knoten 2004, 2006, 2008 und 2010 unter Verwendung der hier beschriebenen OTA-Firmware-Aktualisierung aktualisieren (beispielsweise können einer oder mehrere der Knoten 2004, 2006, 2008 und 2010 unter Verwendung Techniken, die in Bezug auf 16 oder 17 veranschaulicht und/oder beschrieben sind, OTA-aktualisiert werden und/oder einer oder mehrere der Knoten 2004, 2006, 2008 und 2010 können gleich oder ähnlich zu dem System 1602 und/oder dem System 1702 sein). In einigen Ausführungsformen können alle Geräte, Module, MCUs, SoCs usw. eines der Knoten 2004, 2006, 2008 und 2010 beispielsweise unter Verwendung von Techniken, die in 16 oder 17 veranschaulicht und/oder beschrieben sind, OTA-aktualisiert werden. Die Pfeile in 20 veranschaulichen einen von vielen möglichen Aktualisierungspfaden für die OTA-Aktualisierung. Insbesondere veranschaulichen die Pfeile in 20 einen Aktualisierungspfad zum Aktualisieren des Knotens 2006 unter Verwendung einer OTA-Aktualisierung mit direkter Adresse (beispielsweise, wenn der Knoten 2006 ein Zielaktualisierungsknoten ist).
21 veranschaulicht ein System 2100 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann das System 2100 in jedem anderen hier veranschaulichten und/oder beschriebenen System bereitgestellt werden. Beispielsweise kann in einigen Ausführungsformen das System 2100 beispielsweise in demselben System wie das System 100, das System 200, das System 300, das System 400, das System 500, das System 600, das System 700, das System 1300, das System 1400, das System 1500, das System 1600, System 1700, System 1800, System 1900 und/oder System 2000 enthalten sein. In einigen Ausführungsformen kann das System 2100 in jeder der IoT-Umgebungen der 1 bis 4 enthalten sein. Das System 2100 kann eine Cloud 2102 und ein Gateway 2104 aufweisen, wobei Daten zwischen der Cloud 2102 und dem Gateway 2104 fließen (beispielsweise unter Verwendung von drahtgebundenen und/oder drahtlosen Kommunikationsprotokollen).
Das System 2100 kann auch ein Sensorcluster 2106 aufweisen. Daten können zwischen dem Gateway 2104 und dem Sensorcluster 2106 unter Verwendung eines drahtlosen Protokolls (beispielsweise BLE, IEEE 802.15.04 oder eines anderen drahtlosen Protokolls) fließen. In einigen Ausführungsformen können einer oder mehrere der Sensoren in dem Cluster 2106 ein Master-Cluster sein, das eine zusätzliche Steuerung bereitstellen kann. In einigen Ausführungsformen können einer oder mehrere der Sensoren in dem Sensorcluster 2106 ein modulares System, wie etwa ein modulares IoT-Edge-System, aufweisen. In einigen Ausführungsformen können einer oder mehrere der Sensoren in dem Sensorcluster 2106 ein modulares System (beispielsweise ein modulares IoT-System, wie etwa ein modulares IoT-Edge-System) aufweisen, das die Austauschfähigkeit eines Rechenmoduls (beispielsweise eines Hauptrechenmoduls, eines MCU-Rechenmoduls, eines Haupt-MCU-Rechenmoduls, eines Moduls 502, des Moduls 602, des Moduls 1304 und/oder des Moduls 1502) sowie von Konnektivitätsmodulen (beispielsweise Modul 504, Modul 604, Modul 1306) und/oder Modul 1504) und Sensormodulen (beispielsweise Modul 510, Modul 610, Modul 1306 und/oder Modul 1510) unterstützen kann. In einigen Ausführungsformen können einer oder mehrere der Sensoren in dem Sensorcluster 2106 ein flexibles, modulares Hardware-Edge-System für das Internet der Dinge (IoT) aufweisen. In einigen Ausführungsformen kann das System 2100 eine frühzeitige Fehlererkennung für IoT-Geräte bereitstellen (beispielsweise für IoT-Edge-Geräte mit geringer Leistung und/oder einen oder mehrere der Sensoren in dem Sensorcluster 2106).
Edge-Sensoren können unintelligente Komponenten sein, die lediglich Daten lesen und die Daten zur weiteren Analyse an das Gateway und/oder die Cloud übertragen. Die Edge-Sensoren könnten jedoch fehlerhaft sein und fehlerhafte Daten senden, ohne von dem Gateway und/oder der Cloud als fehlerhaft erkannt zu werden, da die Erkennung beispielsweise in der Cloud, in dem Gateway und/oder in dem Aggregator und nicht zum Zeitpunkt des Lesens der Daten von erfolgen kann. Es gibt potenzielle Probleme damit, sich auf Gateway- und/oder Cloud-Analysen zu verlassen, um Fehler in den Messwerten und Fehler in den Edge-Sensoren zu erkennen. Wenn die Edge-Sensoren beispielsweise keine intelligenten Geräte sind, kann der Aggregator oder das Gateway, wenn ein Gerät verdeckt oder deaktiviert ist, zu einem einzelnem Fehlerpunkt werden. In einigen Ausführungsformen können Edge-Sensorgeräte eine zusätzliche Fähigkeit aufweisen, Fehler und/oder fehlerhafte Daten zu erkennen, selbst wenn sie beispielsweise von der Cloud getrennt sind.
Das System 2100 weist Sensoren auf, die zu einem Sensorcluster 2106 kombiniert sind. Die Sensoren in dem Cluster 2106 können flexible modulare Sensoren sein (beispielsweise in einem flexiblen modularen Sensorkit oder FMSK). Das Hinzufügen flexibler modularer Sensoren zu dem Cluster 2106 kann intelligente Sensoren in einer IoT-Umgebung bereitstellen. In einigen Ausführungsformen kann jeder Sensor innerhalb des Clusters 2106 einen Mikrocontroller (oder eine MCU) mit geringer Leistung von einer flexiblen modularen Sensorplattform aufweisen. Zu diesen Sensoren können verschiedene Kommunikationsmodule (oder Konnektivitätsmodule) hinzugefügt werden. Das gepunktete Oval und die Pfeile, die den Cluster 2106 der Sensoren in 21 umgeben, veranschaulichen einen Algorithmus (beispielsweise einen Round-Robin-Algorithmus), bei dem das Cluster 2106 einen Knoten als Master-Sensor auswählt. Die Daten von jedem der Sensorknoten in dem Cluster 2106 können an den Master-Sensorknoten gesendet werden (beispielsweise als Unicast an den Master-Sensorknoten gesendet werden). Der Master-Sensor kann beispielsweise ein Regressionsmodell in Maschinensprache (ML) an den gesammelten Knoten-Daten von allen Sensoren in dem Cluster 2106 ausführen. Der Mastersensor kann die gesammelten Daten verwenden, um Ausreißerdaten (beispielsweise fehlerhafte Daten), den Statusstatus der Sensoren usw. zu erkennen und die Möglichkeit eines Ausfalls für jeden Sensorknoten vorherzusagen. Daher kann in einigen Ausführungsformen eine intelligente Analyse zu IoT-Sensorknoten gebracht werden. In IoT-Umgebungen, in denen Tausende (oder mehr) Sensorgeräte enthalten sind (beispielsweise an der Edge), kann eine große Analyselast beispielsweise von der Cloud und/oder dem Gateway abgenommen werden. In einigen Ausführungsformen können Datenzuverlässigkeit und Hardwarefehlerkennung auf Sensorebene implementiert werden.
Wie hierin beschrieben, können flexible modulare Plattformen (oder Systeme) Verarbeitungsfähigkeiten bereitstellen und können an der Edge eines IoT-Systems und/oder in einer IoT-Umgebung verwendet werden. Der Sensorcluster 2106 kann diese Arten von modularen Systemen verwenden, um Analysen durchzuführen und/oder fehlerhafte Daten und Hardware zu erkennen, Fehler vorherzusagen usw. Auf diese Weise kann Logik an der Edge (beispielsweise bei Sensoren in dem Cluster 2106)), am Gateway (beispielsweise am Gateway 2104) und in der Cloud (z. B. Cloud 2102) enthalten sein. Die Logik in der Cloud 2102 und/oder in dem Gateway 2104 kann Daten sammeln und auch Modi für maschinelles Lernen (ML) erstellen. Die Logik in der Cloud 2102 und/oder im Gateway 2104 kann auch Modelle für maschinelles Lernen (ML) auf einem oder mehreren (oder allen) Sensoren in dem Cluster 2106 regelmäßig aktualisieren.
Jeder Sensor in dem Cluster 2106 kann ein Kommunikationsmodul (beispielsweise ein Bluetooth-, BLE- und/oder IEEE 802.15.04-Modul) für die Knoten- und Gateway-Kommunikation verwenden. In einigen Ausführungsformen können Sensoren mit einem ähnlichen Zweck in demselben Cluster 2106 zusammengefasst werden. Es wird angemerkt, dass in einigen Ausführungsformen eine beliebige Anzahl von Clustern 2106 mit jeweils einer beliebigen Anzahl von Sensoren implementiert werden kann. In einigen Ausführungsformen kann eine beliebige Anzahl von Gateways 2104 verwendet werden.
In einigen Ausführungsformen suchen neue Sensoren nach Clustern (wie etwa dem Cluster 2106), anderen Sensoren und Gateways (beispielsweise in der Nähe des neuen Sensors und/oder in einem vorbestimmten Abstand des neuen Sensors). In einigen Ausführungsformen kann der Sensor, wenn er ein Cluster findet, dem Cluster beitreten. Wenn der Sensor kein Cluster findet, aber einen anderen Sensor, können beide Sensoren ein Cluster erzeugen und dem neu erzeugten Cluster beitreten. Wenn der Sensor bereits Teil eines Clusters ist und ein anderes Cluster findet, kann der Hauptsensor beider Cluster informiert und die Cluster zusammengeführt werden, um in einem Cluster enthalten zu sein. Wenn der Sensor ein Gateway findet, kann er dieses Gateway als mögliches Gateway zum Senden von Daten speichern, um die Cloud zu erreichen.
22 veranschaulicht einen Fluss 2200 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann der Fluss 2200 beispielsweise unter Verwendung eines der hier veranschaulichten und/oder beschriebenen Prozessoren, IoT-Geräte, Sensoren, Cluster, Module usw. implementiert werden. Beispielsweise kann in einigen Ausführungsformen der Fluss 2200 durch einen oder mehrere der in dem Sensorcluster 2106 enthaltenen Sensoren und/oder Hauptsensoren implementiert werden. In einigen Ausführungsformen wird der Fluss 2200 durch einen Sensor implementiert. Beispielsweise kann der Fluss 2200 durch einen Sensor implementiert werden, der sich in einem flexiblen modularen Sensorkit (FMSK) befindet. In einigen Ausführungsformen wird der Fluss 2200 von einem Sensor implementiert, der versucht, ein Cluster mit anderen Sensoren zu verbinden, die einen ähnlichen Zweck (oder denselben Zweck) haben. In einigen Ausführungsformen wird der Fluss 2200 von einem Sensor implementiert, der nach Clustern, anderen Sensoren und/oder Gateways sucht (beispielsweise von einem Sensor, der nach Clustern, anderen Sensoren und/oder Gateways sucht, die sich in der Nähe innerhalb einer bestimmten Entfernung, wie etwa einer vordefinierten Entfernung, zu dem Sensor befinden).
Bei 2202 wird eine Suche durchgeführt, um nach Geräten zu suchen (beispielsweise, um nach IoT-Geräten zu suchen), wie beispielsweise Gateways, Cluster und/oder Sensoren. Bei 2204 wird eine Bestimmung getroffen, ob ein Cluster bei 2202 identifiziert wurde. Falls bei 2204 bestimmt wird, dass ein Cluster gefunden wurde, kann dem Cluster bei 2206 beigetreten werden. Nachdem dem Cluster bei 2206 beigetreten wurde, wird bei 2208 eine Bestimmung gemacht, ob ein Gateway gefunden wurde. Falls bei 2208 bestimmt wird, dass ein Gateway gefunden wurde, geht der Fluss 2200 zu einem Ende 2210 über. Falls bei 2208 bestimmt wird, dass kein Gateway gefunden wurde, kehrt der Fluss zu 2202 zurück. Falls bei 2204 bestimmt wird, dass kein Cluster gefunden wurde, bewegt sich der Fluss 2200 zu 2212, um zu bestimmen, ob ein Knoten identifiziert wurde (beispielsweise, um zu identifizieren, ob ein anderer Knoten, wie etwa ein Sensor, identifiziert wurde). Falls bei 2212 bestimmt wird, dass ein Knoten gefunden wurde, wird bei 2214 ein Cluster erzeugt (beispielsweise werden in einigen Ausführungsformen sowohl ein Knoten, der den Fluss 2200 implementiert, wie etwa ein Sensor, der den Fluss 2200 implementiert, als auch der andere Knoten, der bei 2212 identifiziert sowie auch bestimmt wurde, wie etwa ein anderer Sensor, beide zu dem bei 2214 erstellten Cluster hinzugefügt). Dann wird bei 2216 eine Bestimmung durchgeführt, ob ein Gateway gefunden wurde. Falls bei 2216 bestimmt wird, dass ein Gateway identifiziert wurde, bewegt sich der Fluss 2200 zu dem Ende 2210. Falls bei 2216 nicht bestimmt wird, dass ein Gateway identifiziert wurde, kehrt der Fluss zu 2222 zurück. Falls bei 2212 nicht bestimmt wird, dass ein Knoten identifiziert wurde, wird bei 2218 bestimmt, ob ein Gateway gefunden wurde. Falls bei 2218 bestimmt wird, dass ein Gateway identifiziert wurde, bewegt sich der Fluss zu 2220, wo das identifizierte Gateway zu einer Liste möglicher Gateways hinzugefügt wird, mit denen der Knoten kommunizieren kann. Dann wird bei 2222 bestimmt, ob der Knoten (beispielsweise der Sensorknoten) ein Cluster gefunden hat, in den er aufgenommen werden soll. Falls bei 2222 bestimmt wird, dass der Knoten ein Cluster gefunden hat, endet der Fluss bei 2210. Falls bei 2222 bestimmt wird, dass der Knoten kein Cluster gefunden hat, kehrt der Fluss zu 2202 zurück.
Einige Ausführungsformen betreffen ein Modell des maschinellen Lernens (ML). Beispielsweise können einige Ausführungsformen eine kubische Polynomregression mit mehreren Varianten zum Erkennen von Datenausreißern (beispielsweise fehlerhaften Daten), des Knotenzustands und/oder zum Vorhersagen des Knotenzustands verwenden. Das Modell des maschinellen Lernens kann beispielsweise unter Verwendung historischer Werte von gelesenen Daten, des Sensorzustands, eines Zählers, der angibt, wie lange ein Sensor aktiv war, eines Zählers, der eine Zahl angibt, die einer Anzahl gelesener Daten entspricht, eines Stroms zu einem Zeitpunkt des Lesens und/oder einer Spannung zum Zeitpunkt des Lesens usw. erstellt werden.
In einigen Ausführungsformen kann ein Regressionsmodell für maschinelles Lernen (ML) drahtlos aktualisiert werden. Beispielsweise kann ein FMSK- (Edge Flexible Modular Sensor Kit) Cluster ein maschinelles Lernmodell über die Luft aus der Cloud erhalten. In einigen Ausführungsformen kann ein maschinelles Lernmodell unter Verwendung von historischen Daten, oder von Daten, die frisch von einem oder mehreren Sensoren empfangen wurden, erstellt werden. In einigen Ausführungsformen erhält jeder Sensor in einem Cluster von Sensoren eine Kopie des maschinellen Lernens. Der Sensor kann dieses Modell zur Erkennung und Validierung verwenden. Die Cloud kann regelmäßig neue Daten von der Edge verwenden, um das Modell des maschinellen Lernens zu aktualisieren. Die Cloud kann das Modell des maschinellen Lernens auf einem oder mehreren Masterknoten (beispielsweise einem oder mehreren Mastersensoren) des Clusters bereitstellen. Ein Masterknoten (beispielsweise ein Mastersensor) kann das Modell des maschinellen Lernens an alle Knoten (beispielsweise an alle Sensoren) in einem Cluster verteilen.
In einigen Ausführungsformen kann jedes Cluster einen Masterknoten (beispielsweise einen Mastersensor) aufweisen, der beispielsweise unter Verwendung eines Round-Robin-Auswahlverfahrens ausgewählt wird (beispielsweise periodisch ausgewählt wird). In einigen Ausführungsformen führt nur ein Hauptsensor die Analyse durch, um die von den Sensoren bereitgestellten Daten und das Verhalten jedes Sensors auszuwerten, obwohl alle Sensoren in einem Cluster Zugriff auf ein maschinelles Lernmodell haben können. In einigen Ausführungsformen ist der Mastersensor für die Kommunikation mit einem Gateway und/oder mit der Cloud verantwortlich. In einigen Ausführungsformen kann der Sensor, der der Hauptsensor ist, periodisch geändert werden, um einen einzelnen Fehlerpunkt zu vermeiden.
In einigen Ausführungsformen liest in einer normalen Situation, in der ein Sensorcluster Daten liest, jeder einzelne Sensor (beispielsweise jeder FMSK-Sensor) Daten und Unicast-Daten zu einem Hauptsensor des Clusters. Der Hauptknoten kann alle Daten von allen anderen Knoten sammeln und eine Analyse durchführen, um die Richtigkeit der Daten und den Zustand jedes Knotens zu bewerten, und kann eine Ausfallmöglichkeit für jeden der Knoten vorhersagen. Der Masterknoten kann diese Daten an ein Gateway und/oder an die Cloud senden.
In einigen Ausführungsformen kann der Masterknoten in einer Situation, in der Daten von einem fehlerhaften Sensor gelesen werden können, wobei das Sensorcluster Daten liest, alle Daten empfangen. Bei Verwendung eines Regressionsmodells für maschinelles Lernen können Daten als fehlerhaft gekennzeichnet werden. In dieser Situation kann der Master von dem Knoten verlangen, dass er einen weiteren Lesevorgang durchführt. Falls die neu gelesenen Daten korrekt sind, werden die vorherigen Daten aufgrund einer fehlerhaften Bereitschaft empfangen und können verworfen werden. Falls die neu gelesenen Daten immer noch fehlerhaft sind, kann der Master einen Sensor auffordern, die Daten ein drittes Mal zu lesen. Falls die Daten nach dem dritten Lesevorgang immer noch fehlerhaft sind, wird das Gerät (Sensor, Knoten usw.) als fehlerhaft gekennzeichnet, und alle Daten (einschließlich der fehlerhaften Daten, die als fehlerhaft gekennzeichnet sind) können an ein Gateway und/oder an die Cloud gesendet werden.
23 veranschaulicht einen Fluss 2300 gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann der Fluss 2300 beispielsweise unter Verwendung eines der hier veranschaulichten und/oder beschriebenen Prozessoren, IoT-Geräte, Sensoren, Cluster, Module usw. implementiert werden. In einigen Ausführungsformen wird der Fluss 2300 durch einen Sensor implementiert. Beispielsweise kann in einigen Ausführungsformen der Fluss 2300 von einem oder mehreren der in dem Sensorcluster 2106 enthaltenen Sensoren und/oder Hauptsensoren implementiert werden. Der Fluss 2300 kann von einem Sensor implementiert werden, der sich in einem flexiblen modularen Sensorkit (FMSK) befindet. In einigen Ausführungsformen kann der Fluss 2300 ein maschinelles Lernmodell implementieren. Beispielsweise kann der Fluss 2300 eine kubische Polynomregression mit mehreren Varianten verwenden, um fehlerhafte Daten und/oder den Knotenzustand zu erkennen, und kann den Knotenzustand vorhersagen.
Bei 2302 kann ein Master Daten von einem oder mehreren Sensoren empfangen (beispielsweise kann ein Master-Sensor in einem Sensorcluster Daten von einem oder mehreren Sensoren in dem Cluster empfangen). Maschinelles Lernen (ML) kann bei 2304 auf die Daten angewendet werden (beispielsweise, um zu bestimmen, ob die Daten fehlerhaft sind). Bei 2306 wird bestimmt, ob ein Datenausreißer identifiziert wurde (beispielsweise, um zu bestimmen, ob fehlerhafte Daten identifiziert wurden). Falls bei 2306 bestimmt wird, dass ein Datenausreißer identifiziert wurde, kann bei 2308 eine Anforderung an Knoten mit fehlerhaften Daten gesendet werden, um neue Daten zu senden (beispielsweise, um die Daten erneut zu senden, um korrekte Daten zu erhalten). Ein Zähler kann bei 2308 und/oder bei 2310 inkrementiert werden, und bei 2310 kann bestimmt werden, ob der Zähler gleich einer vorbestimmten Zahl ist (beispielsweise, ob der Zähler gleich drei ist, falls der Fluss 2300 dreimal eine Überprüfung fehlerhafter Daten implementiert, um zu bestimmen, ob korrekte Daten erhalten werden können oder ob jedes Mal nur fehlerhafte Daten empfangen werden). Falls die vorbestimmte Anzahl bei 2310 erreicht ist, können ein oder mehrere Sensoren, die fehlerhafte Daten senden, bei 2312 markiert werden. Dann werden bei 2314 Daten für die Übertragung vorbereitet und an ein Gateway und/oder an die Cloud gesendet. Falls die vorbestimmte Anzahl bei 2310 nicht erreicht wurde, kehrt der Fluss zu 2304 zurück, um maschinelles Lernen auf die Daten anzuwenden. Falls bei 2306 bestimmt wird, dass kein Datenausreißer identifiziert wurde, werden bei 2314 Daten für die Übertragung vorbereitet und an ein Gateway und/oder an die Cloud gesendet.
24 ist ein Blockdiagramm eines Beispiels von Komponenten, die in einem IoT-Gerät 2400 vorhanden sein können, um eine der hier veranschaulichten oder beschriebenen Techniken zu implementieren. Das IoT-Gerät 2400 kann beliebige Kombinationen der in dem Beispiel gezeigten Komponenten aufweisen. Die Komponenten können als ICs, Teile davon, diskrete elektronische Geräte oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in dem IoT-Gerät 2400 angepasst sind, oder als Komponenten, die anderweitig in einem Chassis eines größeren Systems enthalten sind, implementiert werden. Das Blockdiagramm von 24 ist dazu vorgesehen, eine Ansicht von Komponenten des IoT-Geräts 2400 auf hoher Ebene zu zeigen. Einige der gezeigten Komponenten können jedoch weggelassen werden, zusätzliche Komponenten können vorhanden sein, und eine andere Anordnung der gezeigten Komponenten können in anderen Implementierungen auftreten.
Das IoT-Gerät 2400 kann einen Prozessor 2402 aufweisen, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultra-Niederspannungsprozessor, ein eingebetteter Prozessor oder ein anderes bekanntes Verarbeitungselement sein kann. Der Prozessor 2402 kann Teil eines Systems-auf-Chip (SoC) sein, in dem der Prozessor 2402 und andere Komponenten zu einer einzelnen integrierten Schaltung oder einem einzelnen Gehäuse gebildet sind, wie etwa die Edison™ - oder Galileo™-SoC-Platinen von Intel. Beispielsweise kann der Prozessor 2402 einen Intel®-Architecture-Core™-basierten Prozessor aufweisen, wie etwa einen Quark™, einen Atom™, einen i3, einen i5, einen i7, einen Xeon®, einen Xeon Phi™-Coprozessor, oder einen Prozessor der MCU-Klasse, oder einen anderen solchen Prozessor, erhältlich von Intel® Corporation, Santa Clara, CA. Es können jedoch beliebig viele andere Prozessoren verwendet werden, die etwa erhältlich sind von Advanced Micro Devices, Inc. (AMD) aus Sunnyvale, CA, einem MIPS-basierten Design von MIPS Technologies, Inc. aus Sunnyvale, CA, einem lizenzierten ARM-basierten Design von ARM Holdings, Ltd., oder einem Kunden davon, oder deren Lizenznehmern oder Anwendern. Die Prozessoren können Einheiten, wie etwa einen Prozessor von Apple® Inc. (beispielsweise einen A5-A10-Prozessor von Apple® Inc.), einen Snapdragon™-Prozessor von Qualcomm® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. aufweisen.
Der Prozessor 2402 kann über einen Bus 2406 mit einem Systemspeicher 2404 kommunizieren. Eine beliebige Anzahl von Speichergeräten kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiel kann der Speicher ein Direktzugriffsspeicher (RAM) gemäß einem auf dem JEDEC (Joint Electron Devices Engineering Council) basierenden LPDDR- (Low Power Double Data Rate) basierten Design sein, wie dem aktuellen LPDDR2-Standard gemäß JEDEC JESD 209 bis 2E (veröffentlicht im April 2009), oder einem LPDDR-Standard der nächsten Generation, wie LPDDR3 oder LPDDR4, der Erweiterungen für LPDDR2 zur Erhöhung der Bandbreite bereitstellt. In verschiedenen Implementierungen können die einzelnen Speichergeräte von einer beliebigen Anzahl unterschiedlicher Gehäusetypen sein, wie etwa ein Einzelchip-Gehäuse (SDP), ein Doppelchip-Gehäuse (DDP) oder ein Quad-Die-Gehäuse (Q17P). Diese Geräte können in einigen Ausführungsformen direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit niedrigerem Profil bereitzustellen, während in anderen Ausführungsformen die Geräte als ein oder mehrere Speichermodule konfiguriert sind, die wiederum über einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Es kann eine beliebige Anzahl anderer Speicherimplementierungen verwendet werden, wie etwa andere Arten von Speichermodulen, z. B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, die microDIMMs oder MiniDIMMs aufweisen, aber nicht darauf beschränkt sind. Beispielsweise kann ein Speicher eine Größe zwischen 2 GB und 16 GB haben und als DDR3LM-Paket oder als LPDDR2- oder LPDDR3-Speicher konfiguriert sein, der über ein Ball Grid Array (BGA) auf ein Motherboard gelötet ist.
Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssysteme usw. bereitzustellen, kann ein Massenspeicher 2408 auch über den Bus 2406 mit dem Prozessor 2402 gekoppelt sein. Um ein dünneres und leichteres Systemdesign zu ermöglichen, kann der Massenspeicher 2408 über eine Solid-State-Laufwerk (SSD) implementiert werden. Andere Geräte, die für den Massenspeicher 2408 verwendet werden können, weisen Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, xD-Bild-Karten und dergleichen, und USB-Flash-Laufwerke auf.
In Implementierungen mit geringem Stromverbrauch kann der Massenspeicher 2408 ein On-Die-Speicher oder ein Register sein, das dem Prozessor 2402 zugeordnet ist. In einigen Beispielen kann der Massenspeicher 2408 jedoch unter Verwendung eines Mikro-Festplattenlaufwerks (HDD) implementiert werden. Ferner kann eine beliebige Anzahl neuer Technologien für den Massenspeicher 2408 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie etwa, unter anderem, Widerstandsänderungsspeicher, Phasenänderungsspeicher, holographische Speicher oder chemische Speicher. Beispielsweise kann das IoT-Gerät 2400 die 3D-XPOINT-Speicher von Intel® und Micron® aufweisen.
Die Komponenten können über den Bus 2406 kommunizieren. Der Bus 2406 kann eine beliebige Anzahl von Technologien aufweisen, die die Industriestandardarchitektur (ISA), erweiterte ISA (EISA), Peripheriekomponentenverbindung (PCI), Peripheriekomponentenverbindung (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien aufweisen. Der Bus 2406 kann ein proprietärer Bus sein, der beispielsweise in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie unter anderem beispielsweise eine I²C-Schnittstelle, eine I³C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen, und ein Leistungsbus.
Der Bus 2406 kann den Prozessor 2402 mit einem Maschen-Sendeempfänger 2410 für die Kommunikation mit anderen Maschen-Geräten 2412 koppeln. Der Maschen-Sendeempfänger 2410 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie beispielsweise 2,4-Gigahertz- (GHz) Übertragungen gemäß dem IEEE 802.15 .4 Standard, unter Verwendung des Bluetooth® Low Energy (BLE) Standards, wie er unter anderem von der Bluetooth® Special Interest Group oder dem ZigBee® Standard definiert wird. Für die Verbindungen zu den Maschen-Geräten 2412 kann eine beliebige Anzahl von Funkgeräten verwendet werden, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind. Beispielsweise kann eine WLAN-Einheit verwendet werden, um eine Wi-Fi™-Kommunikation gemäß dem IEEE-(Institut für Elektrik und Elektronik für Ingenieure) 802.11-Standard zu implementieren. Außerdem kann eine drahtlose Weitverkehrskommunikation, z. B. gemäß einem zellularen oder einem anderen drahtlosen Weitverkehrsprotokoll, über eine WWAN-Einheit erfolgen.
Der Maschen-Sendeempfänger 2410 kann unter Verwendung mehrerer Standards oder Funkgeräte für die Kommunikation in verschiedenen Bereichen kommunizieren. Beispielsweise kann das IoT-Gerät 2400 mit geografisch benachbarten Geräten, z. B. innerhalb von etwa 10 Metern, unter Verwendung eines auf BLE basierenden lokalen Sendeempfängers oder eines anderen Funkgeräts mit geringer Leistung kommunizieren, um Energie zu sparen. Weiter entfernte Maschengeräte 2412, z. B. innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkgeräte mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät mit unterschiedlichen Leistungsstufen oder über separate Sendeempfänger, beispielsweise einen lokalen Sendeempfänger unter Verwendung von BLE und einen separaten Maschen-Sendeempfänger unter Verwendung von ZigBee, stattfinden. Der Maschen-Sendeempfänger 2410 kann als Adresse, auf die der Chip direkt zugreifen kann, in eine MCU integriert sein, wie etwa in die von Intel erhältlichen Curie®-Einheiten.
Ein Aufwärtsstrecken-Sendeempfänger 2414 kann enthalten sein, um mit Geräten in der Cloud 302 zu kommunizieren. Der Aufwärtsstrecken-Sendeempfänger 2414 kann ein LPWA-Sendeempfänger sein, der dem IEEE 802.15.4, IEEE 802.15.4g, IEEE 802.15.4e, IEEE 802.15.4k oder NB-IoT-Standards, unter anderem, folgt. Das IoT-Gerät 2400 kann über einen weiten Bereich unter Verwendung des von Semtech und der LoRa-Allianz entwickelten LoRaWAN™ (langreichweitiges Weitbereichsnetzwerk) kommunizieren. Die hier beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Sendeempfänger verwendet werden, die Kommunikation mit großer Reichweite und geringer Bandbreite implementieren, wie etwa Sigfox, Weightless-P von der Weightless Special Interest Group, Random Phase Multiple Access (RPMA®) von Ingenu, und anderen Technologien. Ferner können andere Kommunikationstechniken verwendet werden, wie etwa das in der IEEE 802.15.4e-Spezifikation beschriebene zeitgeschlitzte Kanal-Hopping.
Zusätzlich zu den hier beschriebenen Systemen für den Maschen-Sendeempfänger 2410 und den Aufwärtsstrecken-Sendeempfänger 2414 kann eine beliebige Anzahl anderer Funkkommunikationen und -protokolle verwendet werden. Beispielsweise können die Funk-Sendeempfänger 2410 und 2412 einen LTE- oder einen anderen zellularen Sendeempfänger aufweisen, der Spreiz-Spektrum-Kommunikation (SPA/SAS) zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet, wie etwa für Videoübertragungen. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für die Kommunikation mit mittlerer Geschwindigkeit, wie etwa Standbilder, Sensorablesungen, und die Bereitstellung der Netzwerkkommunikation.
Die Funk-Sendeempfänger 2410 und 2412 können Funkgeräte aufweisen, die mit einer beliebigen Anzahl von 3GPP- (Partnerschaftsprojekt der dritten Generation) Spezifikationen kompatibel sind, insbesondere Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), Long Term Evolution-Advanced Pro (LTE-A Pro) oder Narrow Band IoT (NB-IoT), unter anderem. Es kann angemerkt werden, dass Funkgeräte ausgewählt werden können, die mit einer beliebigen Anzahl anderer fester, mobiler oder Satellitenkommunikationstechnologien und -standards kompatibel sind. Diese können beispielsweise jede zellulare Weitbereichs-Funkkommunikationstechnologie aufweisen, die z. B. ein 5G-Kommunikationssystem (5. Generation), eine GSM- (globales System für Mobilkommunikationen) Funkkommunikationstechnologie, eine GPRS- (General Packet Radio Service) Funkkommunikationstechnologie, oder eine EDGE-(Enhanced Data Rates for GSM Evolution) Funkkommunikationstechnologie aufweisen. Andere Funkkommunikationstechnologien des Partnerschaftsprojekts der dritten Generation (3GPP), die verwendet werden können, umfassen UMTS (Universal Mobile Telecommunications System), FOMA (Freedom of Multimedia Access), 3GPP LTE (Long Term Evolution), 3GPP LTE Advanced (Long Term Evolution Advanced), 3GPP LTE Advanced Pro (Long Term Evolution Advanced Pro), CDMA2000 (Code Division Multiple Access 2000), CDPD (Cellular Digital Packet Data), Mobitex, 3G (dritte Generation), CSD (Circuit Switched Data), HSCSD (High-Speed Circuit-Switched Data), UMTS (3G) (Universal Mobile Telecommunications System (dritte Generation)), W-CDMA (UMTS) (Wideband Code Division Multiple Access (Universal Mobile Telecommunications System)), HSPA (Hochgeschwindigkeitspaketzugriff), HSDPA (Hochgeschwindigkeits-Abwärtsstrecken-Paketzugriff), HSUPA (Hochgeschwindigkeits-Aufwärtsstrecken-Paketzugriff), HSPA+ (Hochgeschwindigkeitspaketzugriff Plus), UMTS-TDD (Universal Mobile Telecommunications System - Time-Division Duplex), TD-CDMA (Time Division - Code Division Multiple Access), TD-(Time Division - Synchronous Code Division Multiple Access), 3GPP Rel. 8 (Pre-4G) (Partnerschaftsprojekt der 3. Generation, Release 8 (Pre-4th Generation)), 3GPP Rel. 9 (Partnerschaftsprojekt der 3. Generation, Release 9), 3GPP Rel. 10 (Partnerschaftsprojekt der 3. Generation, Release 10), 3GPP Rel. 11 (Partnerschaftsprojekt der 3. Generation, Release 11), 3GPP Rel. 12 (Partnerschaftsprojekt der 3. Generation, Release 12), 3GPP Rel. 13 (Partnerschaftsprojekt der 3. Generation, Release 13), 3GPP Rel. 14 (Partnerschaftsprojekt der 3. Generation, Release 14), 3GPP LTE Extra, LTE Licensed-Assisted Access (LAA), UTRA (UMTS Terrestrial Radio Access), E-UTRA (Evolved UMTS Terrestrial Radio Access), LTE Advanced (4G) (Long Term Evolution Advanced (4. Generation)), cdmaOne (2G), CDMA2000 (3G) (Code division multiple access 2000 (dritte Generation)), EV-DO (Evolution-Data Optimized or Evolution-Data Only), AMPS (1G) (Advanced Mobile Phone System (Ist Generation)), TACS/ETACS (Total Access Communication System/Extended Total Access Communication System), D-AMPS (2G) (Digital AMPS (2nd Generation)), PTT (Push-to-talk), MTS (Mobile Telephone System), IMTS (Improved Mobile Telephone System), AMTS (Advanced Mobile Telephone System), OLT (norwegisch für Offentlig Landmobil Telefoni, öffentliches terrestrisches Mobilfunknetz), MTD (schwedische Abkürzung für Mobiltelefoniesystem D, oder mobiles Telefoniesystem D), Autotel/PALM (Public Automated Land Mobile), ARP (finnisch für Autoradiopuhelin, „Autoradiotelefon“), NMT (Nordic Mobile Telephony), Hicap (High capacity version of NTT (Nippon Telegraph and Telephone)), CDPD (Cellular Digital Packet Data), Mobitex, DataTAC, iDEN (Integrated Digital Enhanced Network), PDC (Personal Digital Cellular), CSD (Circuit Switched Data), PHS (Personal Handy-phone System), WiDEN (Wideband Integrated Digital Enhanced Network), iBurst, Unlicensed Mobile Access (UMA, auch bezeichnet als 3GPP generisches Zugriffsnetzwerk, oder GAN-Standard)), WiGig- (Wireless Gigabit Alliance) Standard, mm-Wellen-Standards im Allgemeinen (drahtlose Systeme, die bei 10-90 GHz und darüber arbeiten, wie etwa WiGig, IEEE 802.11ad, IEEE 802.11 ay, und dergleichen. Zusätzlich zu den oben aufgeführten Standards kann eine beliebige Anzahl von Satelliten-Aufwärtsstrecken-Technologien für den Aufwärtsstrecken-Sendeempfänger 2414 verwendet werden, die beispielsweise Funkgeräte aufweisen, die den von der ITU (International Telecommunication Union) oder dem ETSI (European Telecommunications Standards Institute) herausgegebenen Standards entsprechen, unter anderen. Unter den hier bereitgestellten Beispielen wird somit verstanden, dass sie auf verschiedene andere Kommunikationstechnologien anwendbar sind, sowohl existierende als auch noch nicht formulierte.
Eine Netzwerkschnittstellensteuerung (NIC) 2416 kann enthalten sein, um eine drahtgebundene Kommunikation mit der Cloud 302 oder anderen Geräten, wie etwa den Maschen-Geräten 2412, bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder auf anderen Arten von Netzwerken basieren, wie etwa dem Steuerungsbereichsnetzwerk (Controller Area Network) CAN), LIN (Local Interconnect Network), DeviceNet, ControlNet, Data Highway+, EtherCAT, SERCOS, PROFIBUS, PROFINET RT oder PROFINET IRT. Eine zusätzliche NIC 2416 kann enthalten sein, um die Verbindung zu einem zweiten Netzwerk zu ermöglichen, beispielsweise eine NIC 2416, die die Kommunikation mit der Cloud über Ethernet bereitstellt, und eine zweite NIC 2416, die die Kommunikation mit anderen Geräten über einen anderen Netzwerktyp bereitstellt.
Der Bus 2406 kann den Prozessor 2402 mit einer Schnittstelle 2418 koppeln, die zum Verbinden externer Geräte verwendet wird. Die externen Geräte können Sensoren 2420 aufweisen, wie etwa Beschleunigungsmesser, Füllstandsensoren, Durchflusssensoren, Temperatursensoren, Drucksensoren, Luftdrucksensoren und dergleichen. Die Schnittstelle 2418 kann verwendet werden, um das IoT-Gerät 2400 mit Aktuatoren 2422 zu verbinden, wie beispielsweise Leistungsschaltern, Ventilaktuatoren, einem Generator für hörbaren Schall, einem visuellen Warngerät, und dergleichen.
Obwohl nicht gezeigt, können verschiedene Eingabe-/Ausgabe- (E/A) Geräte innerhalb des IoT-Geräts 2400 vorhanden sein oder mit diesem verbunden sein. Beispielsweise kann eine Anzeige enthalten sein, um Informationen wie etwa Sensorablesungen oder eine Aktuatorposition, anzuzeigen. Ein Eingabegerät, wie etwa ein Touchscreen oder eine Tastatur, kann enthalten sein, um Eingaben zu akzeptieren.
Eine Batterie 2424 kann das IoT-Gerät 2400 mit Strom versorgen, obwohl in Beispielen, in denen das IoT-Gerät 2400 an einem festen Ort montiert ist, eine Stromversorgung mit einem Stromnetz gekoppelt sein kann. Die Batterie 2424 kann eine Lithium-Ionen-Batterie, eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie, ein Hybrid-Superkondensator, und dergleichen sein.
Ein Batterie-Überwachungs-/Ladegerät 2426 kann in dem IoT-Gerät 2400 enthalten sein, um den Ladezustand (SoCh) der Batterie 2420 zu verfolgen. Das Batterie-Überwachungs-/Ladegerät 2426 kann dazu verwendet werden, um andere Parameter der Batterie 2424 zu überwachen, um Fehlervorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 2424. Das Batterie-Überwachungs-/Ladegerät 2426 kann eine integrierte Batterieüberwachungsschaltung, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, ein ADT7488A von ON Semiconductor aus Phoenix, Arizona, oder eine IC der UCD90xxx-Familie von Texas Instruments aus Dallas, TX, aufweisen. Das Batterie-Überwachungs-/Ladegerät 2426 kann die Informationen über die Batterie 2424 über den Bus 2406 an den Prozessor 2402 kommunizieren. Das Batterie-Überwachungs-/Ladegerät 2426 kann auch einen Analog-Digital-Wandler (ADC) aufweisen, der es dem Prozessor 2402 ermöglicht, die Spannung der Batterie 2426 oder den Stromfluss von der Batterie 2424 direkt zu überwachen. Die Batterieparameter können dazu verwendet werden, um Aktionen zu bestimmen, die das IoT-Gerät 2400 ausführen kann, wie etwa Übertragungsfrequenz, Maschennetzbetrieb, Erfassungsfrequenz und dergleichen.
Ein Stromversorgungsblock 2428 oder eine andere mit einem Netz gekoppelte Stromversorgung kann mit dem Batterie-Überwachungs-/Ladegerät 2426 gekoppelt sein, um die Batterie 2424 aufzuladen. In einigen Beispielen kann der Stromversorgungsblock 2428 durch einen drahtlosen Energieempfänger ersetzt werden, um Energie drahtlos zu erhalten, beispielsweise über eine Rahmenantenne in dem IoT-Gerät 2400. Eine drahtlose Batterieladeschaltung, wie etwa beispielsweise ein LTC4020-Chip von Linear Technologies aus Milpitas, CA, kann in dem Batterie-Überwachungs-/Ladegerät enthalten sein. Die gewählten spezifischen Ladeschaltungen hängen von der Größe der Batterie 2424 und damit vom erforderlichen Strom ab. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance herausgegebenen Airfuel-Standards, des vom Wireless Power Consortium herausgegebenen Qi-Standards für drahtloses Laden, oder des von der Alliance for Wireless Power herausgegebenen Rezence-Ladestandards durchgeführt werden. In einigen Beispielen kann der Stromversorgungsblock 2428 durch Sonnenkollektoren, einen Windgenerator, einen Wassergenerator oder andere natürliche Energiesysteme erweitert oder ersetzt werden.
Der Speicher 2408 kann eine Anzahl von Modulen zum Implementieren einer der hier beschriebenen Techniken aufweisen. Obwohl als Codeblocks in dem Massenspeicher 2408 gezeigt, kann verstanden werden, dass jedes der Module ganz oder teilweise durch festverdrahtete Schaltungen ersetzt werden kann, die beispielsweise in eine anwendungsspezifische integrierte Schaltung (ASIC) eingebaut sind. Der Massenspeicher 2408 gemäß einigen Ausführungsformen kann Anweisungen 2430 aufweisen. Die Anweisungen 2430 können Code zum Implementieren einer der hier beschriebenen Techniken aufweisen. In einigen Ausführungsformen können alle oder einige der Anweisungen 2430 im Prozessor 2402 und/oder im Speicher 2404 enthalten sein. Das heißt, in einigen Ausführungsformen können Anweisungen 2430 im Prozessor 2402, im Prozessor 2404, im Speicher 2408 enthalten sein, und/oder können in einer beliebigen Kombination von einem oder mehreren Prozessoren 2402, Speichern 2404 und/oder Speichern 2408 enthalten sein.
In einigen Ausführungsformen kann das IoT-Gerät 2400 ein System oder ein Subsystem zum Implementieren einer der hier beschriebenen Techniken aufweisen. Beispielsweise kann in einigen Ausführungsformen das IoT-Gerät 2400 ein System oder ein Subsystem sein oder aufweisen, wie beispielsweise ein Edge-Gerät, ein Fog-Gerät, ein Gateway oder ein anderes IoT-Gerät, das eine der hier veranschaulichten und beschriebenen Techniken implementiert.
Beispiele und Ausführungsformen verschiedener Techniken wurden hierin beispielsweise als unter Verwendung eines Prozessors, der gespeicherte Anweisungen ausführt, implementiert veranschaulicht und beschrieben. Es wird jedoch angemerkt, dass andere Beispiele und Ausführungsformen einer dieser Techniken andere Implementierungen aufweisen können. Beispielsweise kann jede der hier veranschaulichten oder beschriebenen Techniken in irgendeiner Hardware, Software, Firmware oder in irgendeiner Kombination davon implementiert werden. Einige Ausführungsformen können beispielsweise unter Verwendung einer anwendungsspezifischen integrierten Schaltung (ASIC) oder eines feldprogrammierbaren Gate-Arrays (FPGA) implementiert werden.
25 ist ein Blockdiagramm eines oder mehrerer beispielhafter nichtflüchtiger, maschinenlesbarer Medien 2500 (oder eines Mediums 2500), die Anweisungen (oder Code) aufweisen, um einen Prozessor 2502 anzuweisen, eine der hierin beschriebenen Techniken zu implementieren, gemäß einigen Ausführungsformen. Der Prozessor 2502 kann über einen Bus 2504 auf das eine oder die mehreren nichtflüchtigen maschinenlesbaren Medien 2500 zugreifen. Der Prozessor 2502 und der Bus 2504 können wie in Bezug auf den Prozessor 2402 und den Bus 2406 von 24 beschrieben ausgewählt werden. Das nichtflüchtige maschinenlesbare Medium 2500 kann Geräte aufweisen, die für den Massenspeicher 2408 von 24 beschrieben sind, oder kann optische Platten, USB-Sticks oder eine beliebige Anzahl anderer Hardwaregeräte aufweisen.
Das eine oder die mehreren nicht nichtflüchtigen maschinenlesbaren Medien 2500 können Anweisungen 2506 (die auch als Code 2506 bezeichnet werden können) aufweisen, um den Prozessor 2502 anzuweisen, unter anderem eine der hier beschriebenen Techniken zu implementieren.
In einigen Ausführungsformen können die hier beschriebenen Techniken von einem Prozessor, wie etwa dem Prozessor 2402 oder dem Prozessor 2502, auf dem Software oder Firmware oder eine Kombination davon ausgeführt wird, implementiert werden. In einigen Ausführungsformen können die hier beschriebenen Techniken jedoch unter Verwendung anderer Arten von Prozessoren oder Steuerungen implementiert werden. Beispielsweise können in einigen Ausführungsformen die hier beschriebenen Techniken beispielsweise durch ein FPGA (feldprogrammierbares Gate-Array) implementiert werden.
Die hier beschriebenen Techniken können dazu verwendet werden, eine beliebige Anzahl von IoT-Netzwerken für verschiedene Zwecke zu implementieren. Zusätzliche Anwendungen können implementiert werden.
Beispiel 1 In einigen Beispielen weist eine modulare Internet-der-Dinge- (IoT) Vorrichtung mehrere Platinen und Verbinder zum Koppeln der IoT-Module mit einer oder mehreren der mehreren Platinen und zum Koppeln der mehreren Platinen miteinander auf, wobei die Verbinder Stapelverbinder auf beiden Seiten von mindestens einigen der Platinen und mindestens einigen der mit den Platinen zu koppelnden IoT-Module umfassen, wobei die Stapelverbinder ermöglichen, die IoT-Module und die Platinen so miteinander zu koppeln, dass Platinen und Module nicht falsch eingesetzt werden können.
Beispiel 2 weist den Gegenstand von Beispiel 1 auf. Die Stapelverbinder stellen eine gemeinsame Pinbelegung für die Platinen und die IoT-Module bereit.
Beispiel 3 weist den Gegenstand eines der Beispiele 1 bis 2 auf. Die Stapelverbinder stellen eine polarisierte Stapelverbindung bereit.
Beispiel 4 weist den Gegenstand eines der Beispiele 1 bis 3 auf. Die Stapelverbinder weisen ein vollständiges Durchgangsdesign auf.
Beispiel 5 weist den Gegenstand eines der Beispiele 1 bis 4 auf. Die Stapelverbinder weisen eine variable Verbinderhöhe auf, um lokale Schaltungen auf einer Platine oder einem IoT-Modul aufzunehmen.
Beispiel 6 weist den Gegenstand eines der Beispiele 1 bis 5 auf. Jede Platine kann in beliebiger Reihenfolge ohne physische Kollision von Komponenten gestapelt werden.
Beispiel 7 weist den Gegenstand eines der Beispiele 1 bis 6 auf. Pinbelegungen der Stapelverbinder sind von einer Funktion jeder Platine unabhängig.
Beispiel 8 weist den Gegenstand eines der Beispiele 1 bis 7 auf. Die IoT-Module weisen ein oder mehrere IoT-Rechenmodule, ein oder mehrere IoT-Konnektivitätsmodule, ein oder mehrere IoT-Sensormodule, und/oder ein oder mehrere IoT-Stromversorgungsmodule auf.
Beispiel 9 weist den Gegenstand eines der Beispiele 1 bis 8 auf. Die Pinbelegung der Stapelverbinder von einer Funktion jeder Platine unabhängig, um ein Stapeln unterschiedlicher IoT-Module, Basissysteme und/oder Abschirmungen unabhängig von Funktion oder Reihenfolge zu ermöglichen.
Beispiel 10 weist den Gegenstand eines der Beispiele 1 bis 9 auf. Die Stapelverbinder ermöglichen ein vertikales Stapeln.
Beispiel 11 weist den Gegenstand eines der Beispiele 1 bis 10 auf. Die Stapelverbinder ermöglichen ein horizontales Stapeln.
Beispiel 12 weist den Gegenstand eines der Beispiele 1 bis 11 auf. Die Stapelverbinder ermöglichen Modulpositionen entlang von Kanten von mindestens einigen der Platinen.
Beispiel 13 weist den Gegenstand eines der Beispiele 1 bis 12 auf. Die Stapelverbinder ermöglichen Konnektivitätsmodulpositionen entlang von Kanten von mindestens einigen der Platinen.
Beispiel 14 weist den Gegenstand eines der Beispiele 1 bis 13 auf. Ausschlüsse befinden sich entlang von Kanten von mindestens einigen der Platinen.
Beispiel 15 weist den Gegenstand eines der Beispiele 1 bis 14 auf. Ausschlüsse auf den IoT-Modulen an einer gemeinsamen Position stellen eine gemeinsame Ausschlusszone auf jedem der IoT-Module für IoT-Funkmodulantennen bereit.
Beispiel 16 In einigen Beispielen weist eine Internet-der-Dinge- (IoT) Vorrichtung einen Datenmanager zum Routen von Daten an unabhängig entwickelte Komponenten in einem IoT-System auf, wobei der Datenmanager dazu dient, zu ermöglichen, dass die Komponenten einen datentypunabhängigen Informationsaustausch miteinander implementieren, und der Datenmanager dazu dient, jeder Komponente eine eindeutige Kennung zuzuweisen, um die Komponente in die Lage zu versetzen, Informationen über den Datenmanager zu senden und/oder zu empfangen.
Beispiel 17 weist den Gegenstand von Beispiel 16 auf. Der Datenmanager kann in einem Zielsteuerungs-Anwendungsbereich ausgeführt werden.
Beispiel 18 weist den Gegenstand eines der Beispiele 16 bis 17 auf. Der Datenmanager ist von Inhalten von Dateneingaben der Komponenten unabhängig.
Beispiel 19 weist den Gegenstand eines der Beispiele 16 bis 18 auf. Der Datenmanager dient dazu, die Komponenten lose zu koppeln und dynamisch an das IoT-System zu binden, ohne deren interne Struktur zu verstehen.
Beispiel 20 weist den Gegenstand eines der Beispiele 16 bis 19 auf. Der Datenmanager dient dazu, Charakteristiken des Nutzlastdatenverkehrs zu verwenden, um seine Beziehung zu Komponenten in einem eingebetteten System zu bestimmen.
Beispiel 21 weist den Gegenstand eines der Beispiele 16 bis 20 auf. Der Datenmanager weist einen Publizierer-Abonnenten zum Routen von Daten zwischen den Komponenten auf. Eine oder mehrere der Komponenten können Daten in dem IoT-System publizieren und/oder abonnieren.
Beispiel 22 weist den Gegenstand eines der Beispiele 16 bis 21 auf. Der Datenmanager ist mit präemptiven und nicht präemptiven Aufgabenplanern kompatibel.
Beispiel 23 weist den Gegenstand eines der Beispiele 16 bis 22 auf. Die Komponenten sind unabhängig entwickelte, tief eingebettete Komponenten. Der Datenmanager dient dazu, die Komponenten miteinander zu verbinden, ohne eine komplexe Kenntnis einer inneren Funktionsweise der Komponenten zu haben.
Beispiel 24 weist den Gegenstand eines der Beispiele 16 bis 23 auf. Der Datenmanager dient dazu, den Komponenten zu ermöglichen, Informationen miteinander auszutauschen, ohne dass Konstrukte der Datenursprungskomponente in eine Datenzielkomponente eingebettet werden.
Beispiel 25 weist den Gegenstand eines der Beispiele 16 bis 24 auf. Der Datenmanager weist einen Client-Registrierungsmanager zum Validieren jeder Komponente unter Verwendung eines Komponenten-Plugin-Moduls auf.
Beispiel 26 weist den Gegenstand eines der Beispiele 16 bis 25 auf. Der Datenmanager weist einen Konfigurationsmanager auf, um einem oder mehreren Datenmanager-Clients zu ermöglichen, ein Verhalten des Datenmanagers oder eines anderen Datenmanager-Clients zu konfigurieren.
Beispiel 27 weist den Gegenstand eines der Beispiele 16 bis 26 auf. Der Datenmanager weist einen Daten-/Ereignisabonnenten auf, um einem oder mehreren Datenmanager-Clients zu ermöglichen, ein Verhalten des Datenmanagers oder eines Daten-/Ereignispublizierers zu konfigurieren.
Beispiel 28 weist den Gegenstand eines der Beispiele 16 bis 27 auf. Der Datenmanager weist einen Publizierer-Abonnenten zum Routen von Daten zwischen Komponenten, die Daten publizieren, und Komponenten, die Daten abonnieren, auf.
Beispiel 29 In einigen Beispielen weist eine Internet-der-Dinge- (IoT) Vorrichtung mehrere integrierte Stromversorgungen, die passive Komponenten für On-Chip-Spannungsregler aufweisen, mehrere Spannungsschienen, die unterschiedlichen Spannungswerten entsprechen, eine Leistungssequenzierungsschaltung zur Bereitstellung einer eigenständigen Stromversorgung, und einen oder mehrere modulare Stapelverbinder, um die mehreren Spannungsschienen mit einem anderen Gerät zu koppeln, auf.
Beispiel 30 weist den Gegenstand von Beispiel 29 auf. Die IoT-Vorrichtung ist ein IoT-Modul.
Beispiel 31 weist den Gegenstand eines der Beispiele 29 bis 30 auf. Die IoT-Vorrichtung weist ein oder mehrere IoT-Rechenmodule, ein IoT-Sensormodul und/oder ein IoT-Konnektivitätsmodul auf.
Beispiel 32 weist den Gegenstand eines der Beispiele 29 bis 31 auf. Der eine oder die mehreren modularen Stapelverbinder dienen zum Koppeln der mehreren Spannungsschienen mit einer Platine und/oder einem IoT-Modul.
Beispiel 33 weist den Gegenstand eines der Beispiele 29 bis 32 auf. Die passiven Komponenten weisen Schaltinduktoren und Kondensatoren auf.
Beispiel 34 weist den Gegenstand eines der Beispiele 29 bis 33 auf. Ein Stromversorgungspfad und ein Steuerungssystem mit mehreren Quellen weisen eine Leistungssequenzierung auf.
Beispiel 35 weist den Gegenstand eines der Beispiele 29 bis 34 auf. Die IoT-Vorrichtung ist ein IoT-Edge-Gerät.
Beispiel 36 weist den Gegenstand eines der Beispiele 29 bis 35 auf. Mehrere Spannungen stehen mehreren IoT-Modulen über die Stapelverbinder zur Verfügung.
Beispiel 37 weist den Gegenstand eines der Beispiele 29 bis 36 auf. Die IoT-Vorrichtung dient zum Abgreifen von Pins einer gemeinsamen Schiene der Stapelverbinder und zum Bereitstellen von Spannung in Abhängigkeit von Spannungsintegratoren auf dem Chip.
Beispiel 38 weist den Gegenstand eines der Beispiele 29 bis 37 auf. Pins einer gemeinsamen Schiene der Stapelverbinder können zum Empfangen von Spannungen verwendet werden.
Beispiel 39 weist den Gegenstand eines der Beispiele 29 bis 38 auf. Die Leistungssequenzierungsschaltung verwendet programmierbare Zustandsmaschinengeräte, um die Startzeiten mehrerer Netzteile zu steuern.
Beispiel 40 In einigen Beispielen weist eine Internet-der-Dinge- (IoT) Vorrichtung einen eindeutigen privaten Schlüssel auf zum Identifizieren, ob die IoT-Vorrichtung authentisch ist, und zur Sicherung der Identifikation und des Vertrauens. Die IoT-Vorrichtung weist auch einen Modus zum Starten in einem nicht authentifizierten Zustand und zum drahtlosen Signalisieren per Funkbake der Präsenz der IoT-Vorrichtung, einen Authentifizierungsmodus zum Verbinden mit einem IoT-Netzwerk, und einen Sender zum Senden von Daten an das IoT-Netzwerk nach der Authentifizierung auf.
Beispiel 41 weist den Gegenstand von Beispiel 40 auf. Ein Zeitmultiplexer ist dazu vorgesehen, drahtlose Kanäle zu verwalten, den Durchsatz zu maximieren, und Skalierbarkeit bereitstellen.
Beispiel 42 weist den Gegenstand eines der Beispiele 40 bis 41 auf. Ein Empfänger soll Daten von dem IoT-Netzwerk empfangen.
Beispiel 43 weist den Gegenstand eines der Beispiele 40 bis 42 auf. Ein Verschlüsseler ist dazu vorgesehen, Daten zu verschlüsseln, die an das IoT-Netzwerk gesendet werden.
Beispiel 44 weist den Gegenstand eines der Beispiele 40 bis 43 auf. Ein Detektor ist dazu vorgesehen, Fehlerzustände zu erkennen.
Beispiel 45 In einigen Beispielen weist eine Internet-der-Dinge- (IoT) Vorrichtung einen oder mehrere Stapelverbinder zum Koppeln der IoT-Vorrichtung mit einer oder mehreren Platinen und/oder einem oder mehreren IoT-Modulen, einen Empfänger zum Empfangen einer aktuellen Konfiguration, und einen zu aktualisierenden On-Chip-Flashspeicher auf, wobei der On-Chip-Flashspeicher dazu dient, ein Flash-Aktualisierung über den Empfänger zu empfangen.
Beispiel 46 weist den Gegenstand von Beispiel 45 auf. Der On-Chip-Flashspeicher soll basierend auf Hardware- und Firmware-Übereinstimmungen aktualisiert werden.
Beispiel 47 weist den Gegenstand eines der Beispiele 45 bis 46 auf. Der On-Chip-Flashspeicher soll basierend auf Platinen und/oder IoT-Modulen, die mit der IoT-Vorrichtung gekoppelt sind, aktualisiert werden.
Beispiel 48 weist den Gegenstand eines der Beispiele 45 bis 47 auf. Der Empfänger dient dazu, die IoT-Vorrichtung unter Verwendung eines drahtlosen persönlichen Bereichsnetzwerks mit einem IoT-System zu koppeln.
Beispiel 49 weist den Gegenstand eines der Beispiele 45 bis 48 auf. Der On-Chip-Flashspeicher dient dazu, die Flash-Aktualisierung über Bit-Banging an Programmierpins der IoT-Vorrichtung empfangen.
Beispiel 50 weist den Gegenstand eines der Beispiele 45 bis 49 auf. Falls die IoT-Vorrichtung direkt mit einem Drahtlos-Manager verbunden ist, soll der On-Chip-Flashspeicher die Flash-Aktualisierung empfangen, bevor Knoten, die nicht direkt mit dem Drahtlos-Manager verbunden sind, eine Flash-Aktualisierung empfangen.
Beispiel 51 weist den Gegenstand eines der Beispiele 45 bis 50 auf. Die IoT-Vorrichtung dient zur Flash-Aktualisierung von IoT-Geräten, die sich neben der IoT-Vorrichtung befinden.
Beispiel 52 weist den Gegenstand eines der Beispiele 46 bis 51 auf. Der On-Chip-Flashspeicher dient dazu, die Flash-Aktualisierung von einem Drahtlos-Manager zu empfangen.
Beispiel 53 weist den Gegenstand eines der Beispiele 46 bis 52 auf. Der On-Chip-Flashspeicher dient dazu, die Flash-Aktualisierung von einem IoT-Gerät zu empfangen, das sich neben der IoT-Vorrichtung befindet.
Beispiel 54 In einigen Beispielen weist eine Internet-der-Dinge-(IoT) Vorrichtung einen Empfänger zum Empfangen einer Angabe, ob die IoT-Vorrichtung ein Master-IoT-Knoten ist, auf. Falls die IoT-Vorrichtung ein Master-IoT-Knoten ist, dient der Empfänger dazu, Daten von anderen IoT-Knoten empfangen, die keine Master-IoT-Knoten sind. Ein Sender ist dazu vorgesehen, Daten an einen Master-IoT-Knoten senden, falls die IoT-Vorrichtung kein Master-IoT-Knoten ist.
Beispiel 55 weist den Gegenstand von Beispiel 54 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, und, falls die IoT-Vorrichtung von IoT-Knoten gefunden hat, dem Cluster beitreten.
Beispiel 56 weist den Gegenstand eines der Beispiele 54 bis 55 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat. Falls die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, dient der Prozessor dazu, die IoT-Vorrichtung dem Cluster beitreten lassen. Falls die IoT-Vorrichtung kein Cluster von IoT-Knoten gefunden hat, dient der Prozessor dazu, zu bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet. Falls die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet, dient der Prozessor dazu, ein neues Cluster von IoT-Knoten mit dem gefundenen IoT-Knoten zu erzeugen.
Beispiel 57 weist den Gegenstand eines der Beispiele 54 bis 56 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung Teil eines IoT-Clusters ist, zu bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich in einem Cluster von IoT-Knoten befindet, und das IoT-Cluster der IoT-Vorrichtung und das Cluster von IoT-Knoten der gefundenen IoT-Knoten zusammenführen.
Beispiel 58 weist den Gegenstand eines der Beispiele 54 bis 57 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung ein IoT-Gateway gefunden hat, und das gefundene IoT-Gateway als mögliches IoT-Gateway, an das Daten gesendet werden sollen, zu speichern.
Beispiel 59 weist den Gegenstand eines der Beispiele 54 bis 58 auf. Ein Prozessor ist dazu vorgesehen, maschinelles Lernen auf empfangene Daten anwenden, und zu bestimmen, ob ein Ausreißer existiert. Falls ein Ausreißer existiert, dient der Prozessor dazu, neue Daten anfordern. Falls kein Ausreißer existiert, dient der Prozessor dazu, eine Datenübertragung vorbereiten.
Beispiel 60 weist den Gegenstand eines der Beispiele 54 bis 59 auf. Ein Prozessor ist dazu vorgesehen, maschinelles Lernen auf empfangene Daten anwenden, und zu bestimmen, ob ein Ausreißer existiert. Falls ein Ausreißer existiert, dient der Prozessor dazu, neue Daten anzufordern. Der Prozessor dient dazu, zu bestimmen, ob ein Ausreißer für mehr als einen Schwellenwert vorhanden war. Falls ein Ausreißer für mehr als einen Schwellenwert vorhanden war, dient der Prozessor dazu, den Ausreißer als fehlgeschlagen zu markieren. Falls kein Ausreißer existiert, dient der Prozessor dazu, eine Datenübertragung vorbereiten.
Beispiel 61 weist den Gegenstand eines der Beispiele 1 bis 60 auf. Eine modulare Internet-der-Dinge- (IoT) Vorrichtung weist mehrere Platinen und Verbinder zum Koppeln der IoT-Module mit einer oder mehreren der mehreren Platinen und zum Koppeln der mehreren Platinen miteinander auf, wobei die Verbinder Stapelverbinder auf beiden Seiten von mindestens einigen der Platinen und mindestens einigen der mit den Platinen zu koppelnden IoT-Module umfassen, wobei die Stapelverbinder ermöglichen, die IoT-Module und die Platinen so miteinander zu koppeln, dass Platinen und Module nicht falsch eingesetzt werden können.
Beispiel 62 weist den Gegenstand eines der Beispiele 1 bis 61 auf. Die Stapelanschlüsse stellen eine gemeinsame Pinbelegung für die Platinen und die IoT-Module bereit.
Beispiel 63 weist den Gegenstand eines der Beispiele 1 bis 62 auf. Die Stapelverbinder stellen eine polarisierte Stapelverbindung bereit.
Beispiel 64 weist den Gegenstand eines der Beispiele 1 bis 63 auf. Die Stapelverbinder weisen ein vollständiges Durchgangsdesign auf.
Beispiel 65 weist den Gegenstand eines der Beispiele 1 bis 64 auf. Die Stapelverbinder weisen eine variable Verbinderhöhe auf, um lokale Schaltungen auf einer Platine oder einem IoT-Modul aufzunehmen.
Beispiel 66 weist den Gegenstand eines der Beispiele 1 bis 65 auf. Jede Platine kann in beliebiger Reihenfolge ohne physische Kollision von Komponenten gestapelt werden.
Beispiel 67 weist den Gegenstand eines der Beispiele 1 bis 66 auf. Pinbelegungen der Stapelverbinder sind von einer Funktion jeder Platine unabhängig.
Beispiel 68 weist den Gegenstand eines der Beispiele 1 bis 67 auf. Die IoT-Module weisen ein oder mehrere IoT-Rechenmodule, ein oder mehrere IoT-Konnektivitätsmodule, ein oder mehrere IoT-Sensormodule und/oder ein oder mehrere IoT-Stromversorgungsmodule auf.
Beispiel 69 weist den Gegenstand eines der Beispiele 1 bis 68 auf. Die Pinbelegung der Stapelverbinder ist von einer Funktion jeder Platine unabhängig, um ein Stapeln unterschiedlicher IoT-Module, Basissysteme und/oder Abschirmungen unabhängig von Funktion oder Reihenfolge zu ermöglichen.
Beispiel 70 weist den Gegenstand eines der Beispiele 1 bis 69 auf. Die Stapelverbinder ermöglichen ein vertikales Stapeln.
Beispiel 71 weist den Gegenstand eines der Beispiele 1 bis 70 auf. Die Stapelverbinder ermöglichen ein horizontales Stapeln.
Beispiel 72 weist den Gegenstand eines der Beispiele 1 bis 71 auf. Die Stapelverbinder ermöglichen Modulpositionen entlang von Kanten von mindestens einigen der Platinen.
Beispiel 73 weist den Gegenstand eines der Beispiele 1 bis 72 auf. Die Stapelverbinder ermöglichen Konnektivitätsmodulpositionen entlang von Kanten von mindestens einigen der Platinen.
Beispiel 74 weist den Gegenstand eines der Beispiele 1 bis 73 auf. Ausschlüsse befinden sich entlang von Kanten von mindestens einigen der Platinen.
Beispiel 75 weist den Gegenstand eines der Beispiele 1 bis 74 auf. Ausschlüsse auf den IoT-Modulen an einer gemeinsamen Position stellen eine gemeinsame Ausschlusszone auf jedem der IoT-Module für IoT-Funkmodulantennen bereit.
Beispiel 76 weist den Gegenstand eines der Beispiele 1 bis 75 auf. Eine Internet-der-Dinge- (IoT) Vorrichtung weist einen Datenmanager zum Routen von Daten an unabhängig entwickelte Komponenten in einem IoT-System auf, wobei der Datenmanager dazu dient, zu ermöglichen, dass die Komponenten einen datentypunabhängigen Informationsaustausch miteinander implementieren, der Datenmanager dazu dient, jeder Komponente eine eindeutige Kennung zuzuweisen, um die Komponente in die Lage zu versetzen, Informationen über den Datenmanager zu senden und/oder zu empfangen.
Beispiel 77 weist den Gegenstand eines der Beispiele 1 bis 76 auf. Der Datenmanager kann in einem Anwendungsbereich der Zielsteuerung ausgeführt werden.
Beispiel 78 weist den Gegenstand eines der Beispiele 1 bis 77 auf. Der Datenmanager ist von Inhalten von Dateneingaben der Komponenten unabhängig.
Beispiel 79 weist den Gegenstand eines der Beispiele 1 bis 78 auf. Der Datenmanager dient dazu, die Komponenten lose zu koppeln und dynamisch an das IoT-System zu binden, ohne deren interne Struktur zu verstehen.
Beispiel 80 weist den Gegenstand eines der Beispiele 1 bis 79 auf. Der Datenmanager dient dazu, Charakteristiken des Nutzlastdatenverkehrs zu verwenden, um seine Beziehung zu Komponenten in einem eingebetteten System zu bestimmen.
Beispiel 81 weist den Gegenstand eines der Beispiele 1 bis 80 auf. Der Datenmanager weist auf einen Publizierer-Abonnenten zum Routen von Daten zwischen den Komponenten auf. Eine oder mehrere der Komponenten können Daten in dem IoT-System publizieren und/oder abonnieren.
Beispiel 82 weist den Gegenstand eines der Beispiele 1 bis 81 auf. Der Datenmanager ist mit präemptiven und nicht präemptiven Aufgabenplanern kompatibel.
Beispiel 83 weist den Gegenstand eines der Beispiele 1 bis 82 auf. Die Komponenten sind unabhängig entwickelte, tief eingebettete Komponenten. Der Datenmanager dient dazu, die Komponenten miteinander zu verbinden, ohne eine komplexe Kenntnis einer inneren Funktionsweise der Komponenten zu haben.
Beispiel 84 weist den Gegenstand eines der Beispiele 1 bis 83 auf. Der Datenmanager dient dazu, den Komponenten zu ermöglichen, Informationen miteinander auszutauschen, ohne dass Konstrukte der Datenursprungskomponente in eine Datenzielkomponente eingebettet werden.
Beispiel 85 weist den Gegenstand eines der Beispiele 1 bis 84 auf. Der Datenmanager weist einen Client-Registrierungsmanager zum Validieren jeder Komponente unter Verwendung eines Komponenten-Plugin-Moduls auf.
Beispiel 86 weist den Gegenstand eines der Beispiele 1 bis 85 auf. Der Datenmanager weist einen Konfigurationsmanager auf, um einen oder mehreren Datenmanager-Clients zu ermöglichen, ein Verhalten des Datenmanagers oder eines anderen Datenmanager-Clients zu konfigurieren.
Beispiel 87 weist den Gegenstand eines der Beispiele 1 bis 86 auf. Der Datenmanager weist einen Daten-/Ereignisabonnenten auf, um einen oder mehreren Datenmanager-Clients zu ermöglichen, ein Verhalten des Datenmanagers oder eines Daten-/Ereignispublizierers zu konfigurieren.
Beispiel 88 weist den Gegenstand eines der Beispiele 1 bis 87 auf. Der Datenmanager weist einen Publizierer-Abonnenten zum Routen von Daten zwischen Komponenten, die Daten publizieren, und Komponenten, die Daten abonnieren, auf.
Beispiel 89 weist den Gegenstand eines der Beispiele 1 bis 88 auf. Eine Internet-der-Dinge- (IoT) Vorrichtung weist mehrere integrierte Stromversorgungen, die passive Komponenten für On-Chip-Spannungsregler aufweisen, mehrere Spannungsschienen, die unterschiedlichen Spannungswerten entsprechen, eine Leistungssequenzierungsschaltung zur Bereitstellung einer eigenständigen Stromversorgung, und eine oder mehr modulare Stapelverbinder zum Koppeln der mehreren Spannungsschienen mit einem anderen Gerät auf.
Beispiel 90 weist den Gegenstand eines der Beispiele 1 bis 89 auf. Die IoT-Vorrichtung ist ein IoT-Modul.
Beispiel 91 weist den Gegenstand eines der Beispiele 1 bis 90 auf. Die IoT-Vorrichtung weist ein oder mehrere IoT-Rechenmodule, ein IoT-Sensormodul und/oder ein IoT-Konnektivitätsmodul auf.
Beispiel 92 weist den Gegenstand eines der Beispiele 1 bis 91 auf. Der eine oder die mehreren modularen Stapelverbinder dienen zum Koppeln der mehreren Spannungsschienen mit einer Platine und/oder einem IoT-Modul.
Beispiel 93 weist den Gegenstand eines der Beispiele 1 bis 92 auf. Die passiven Komponenten weisen Schaltinduktoren und Kondensatoren auf.
Beispiel 94 weist den Gegenstand eines der Beispiele 1 bis 93 auf. Ein Stromversorgungspfad und ein Steuerungssystem mit mehreren Quellen weisen eine Leistungssequenzierung auf.
Beispiel 95 weist den Gegenstand eines der Beispiele 1 bis 94 auf. Die IoT-Vorrichtung ist ein IoT-Edge-Gerät.
Beispiel 96 weist den Gegenstand eines der Beispiele 1 bis 95 auf. Mehrere Spannungen stehen mehreren IoT-Modulen über die Stapelverbinder zur Verfügung.
Beispiel 97 weist den Gegenstand eines der Beispiele 1 bis 96 auf. Die IoT-Vorrichtung dient zum Abgreifen von Pins einer gemeinsamen Schiene der Stapelverbinder und zum Bereitstellen von Spannung in Abhängigkeit von Spannungsintegratoren auf dem Chip.
Beispiel 98 weist den Gegenstand eines der Beispiele 1 bis 97 auf. Pins einer gemeinsamen Schiene der Stapelverbinder können zum Empfangen von Spannungen verwendet werden.
Beispiel 99 weist den Gegenstand eines der Beispiele 1 bis 98 auf. Die Leistungssequenzierungsschaltung verwendet programmierbare Zustandsmaschinengeräte, um Startzeiten mehrerer Netzteile zu steuern.
Beispiel 100 weist den Gegenstand eines der Beispiele 1 bis 99 auf. Eine Internet-der-Dinge- (IoT) Vorrichtung weist einen eindeutigen privaten Schlüssel zum Identifizieren, dass die IoT-Vorrichtung authentisch ist, und zur Sicherung der Identifikation und des Vertrauens auf. Die IoT-Vorrichtung weist einen Modus zum Starten in einem nicht authentifizierten Zustand und zum drahtlosen Signalisieren per Funkbake der Präsenz der IoT-Vorrichtung, einen Authentifizierungsmodus zum Beitreten zu einem IoT-Netzwerk, und einen Sender zum Senden von Daten an das IoT-Netzwerk nach der Authentifizierung auf.
Beispiel 101 weist den Gegenstand eines der Beispiele 1 bis 100 auf. Ein Zeitmultiplexer dient dazu, drahtlose Kanäle zu verwalten, den Durchsatz zu maximieren und eine Skalierbarkeit bereitzustellen.
Beispiel 102 weist den Gegenstand eines der Beispiele 1 bis 101 auf. Ein Empfänger ist dazu vorgesehen, Daten von dem IoT-Netzwerk zu empfangen.
Beispiel 103 weist den Gegenstand eines der Beispiele 1 bis 102 auf. Ein Verschlüsseler ist dazu vorgesehen, Daten zu verschlüsseln, die an das IoT-Netzwerk gesendet werden.
Beispiel 104 weist den Gegenstand eines der Beispiele 1 bis 103 auf. Ein Detektor ist dazu vorgesehen, Fehlerzustände zu erkennen.
Beispiel 105 weist den Gegenstand eines der Beispiele 1 bis 104 auf. Eine Internet-der-Dinge- (IoT) Vorrichtung weist einen oder mehrere Stapelverbinder zum Koppeln der IoT-Vorrichtung mit einer oder mehreren Platinen und/oder einem oder mehreren IoT-Modulen, einen Empfänger zum Empfangen einer aktuellen Konfiguration, und einen zu aktualisierenden On-Chip-Flashspeicher auf, wobei der On-Chip-Flashspeicher dazu dient, eine Flash-Aktualisierung über den Empfänger zu empfangen.
Beispiel 106 weist den Gegenstand eines der Beispiele 1 bis 105 auf. Der On-Chip-Flashspeicher soll basierend auf Hardware- und Firmware-Übereinstimmungen aktualisiert werden.
Beispiel 107 weist den Gegenstand eines der Beispiele 1 bis 106 auf. Der On-Chip-Flashspeicher soll basierend auf Platinen und/oder IoT-Modulen, die mit der IoT-Vorrichtung gekoppelt sind, aktualisiert werden.
Beispiel 108 weist den Gegenstand eines der Beispiele 1 bis 107 auf. Der Empfänger dient dazu, die IoT-Vorrichtung unter Verwendung eines drahtlosen persönlichen Bereichsnetzwerks mit einem IoT-System zu koppeln.
Beispiel 109 weist den Gegenstand eines der Beispiele 1 bis 108 auf. Der On-Chip-Flashspeicher soll die Flash-Aktualisierung über Bit-Banging an Programmierpins der IoT-Vorrichtung empfangen.
Beispiel 110 weist den Gegenstand eines der Beispiele 1 bis 109 auf. Falls die IoT-Vorrichtung direkt mit einem Drahtlos-Manager verbunden ist, soll der On-Chip-Flashspeicher die Flash-Aktualisierung empfangen, bevor Knoten, die nicht direkt mit dem Drahtlos-Manager verbunden sind, ein Flash-Aktualisierung empfangen.
Beispiel 111 weist den Gegenstand eines der Beispiele 1 bis 110 auf. Die IoT-Vorrichtung dient zur Flash-Aktualisierung von IoT-Geräten, die sich neben der IoT-Vorrichtung befinden.
Beispiel 112 weist den Gegenstand eines der Beispiele 1 bis 111 auf. Der On-Chip-Flashspeicher soll die Flash-Aktualisierung von einem Drahtlos-Manager empfangen.
Beispiel 113 weist den Gegenstand eines der Beispiele 1 bis 112 auf. Der On-Chip-Flashspeicher soll die Flash-Aktualisierung von einem IoT-Gerät empfangen, das sich neben der IoT-Vorrichtung befindet.
Beispiel 114 weist den Gegenstand eines der Beispiele 1 bis 113 auf. Eine Internet-der-Dinge- (IoT) Vorrichtung weist einen Empfänger zum Empfangen einer Angabe, ob die IoT-Vorrichtung ein Master-IoT-Knoten ist, auf. Falls die IoT-Vorrichtung ein Master-IoT-Knoten ist, dient der Empfänger dazu, Daten von anderen IoT-Knoten empfangen, die keine Master-IoT-Knoten sind. Ein Sender ist dazu vorgesehen, Daten an einen Master-IoT-Knoten zu senden, falls die IoT-Vorrichtung kein Master-IoT-Knoten ist.
Beispiel 115 weist den Gegenstand eines der Beispiele 1 bis 114 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, und, falls die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, dem Cluster beitreten.
Beispiel 116 weist den Gegenstand eines der Beispiele 1 bis 115 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat. Falls die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, dient der Prozessor dazu, die IoT-Vorrichtung dem Cluster beitreten zu lassen. Falls die IoT-Vorrichtung kein Cluster von IoT-Knoten gefunden hat, dient der Prozessor dazu, zu bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet. Falls die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet, dient der Prozessor dazu, ein neues Cluster von IoT-Knoten mit dem gefundenen IoT-Knoten zu erzeugen.
Beispiel 117 weist den Gegenstand eines der Beispiele 1 bis 116 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung Teil eines IoT-Clusters ist, zu bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich in einem Cluster von IoT-Knoten befindet, und das IoT-Cluster der IoT-Vorrichtung und das Cluster von IoT-Knoten der gefundenen IoT-Knoten zusammenzuführen.
Beispiel 118 weist den Gegenstand eines der Beispiele 1 bis 117 auf. Ein Prozessor ist dazu vorgesehen, zu bestimmen, ob die IoT-Vorrichtung ein IoT-Gateway gefunden hat, und das gefundene IoT-Gateway als mögliches IoT-Gateway, an das Daten gesendet werden sollen, zu speichern.
Beispiel 119 weist den Gegenstand eines der Beispiele 1 bis 118 auf. Ein Prozessor ist dazu vorgesehen, maschinelles Lernen auf empfangene Daten anwenden, und zu bestimmen, ob ein Ausreißer existiert. Falls ein Ausreißer existiert, dient der Prozessor dazu, neue Daten anfordern. Falls kein Ausreißer existiert, dient der Prozessor dazu, eine Datenübertragung vorbereiten.
Beispiel 120 weist den Gegenstand eines der Beispiele 1 bis 119 auf. Ein Prozessor ist dazu vorgesehen, maschinelles Lernen auf empfangene Daten anwenden, und zu bestimmen, ob ein Ausreißer existiert. Falls ein Ausreißer existiert, dient der Prozessor dazu, neue Daten anfordern. Der Prozessor dient dazu, zu bestimmen, ob ein Ausreißer mehr als einen Schwellenwert existiert hat. Falls ein Ausreißer mehr als einen Schwellenwert existiert hat, dient der Prozessor dazu, den Ausreißer als fehlgeschlagen zu markieren. Falls kein Ausreißer existiert, dient der Prozessor dazu, eine Datenübertragung vorbereiten.
Beispiel 121 In einigen Beispielen weist ein Verfahren zum Zusammenbauen einer modularen Internet-der-Dinge- (IoT) Vorrichtung Bereitstellen von Verbindern zum Koppeln mehrerer Platinen mit anderer Platinen und mit IoT-Modulen auf. Die Verbinder weisen Stapelverbinder auf beiden Seiten von mindestens einigen der Platinen und mindestens einigen der mit den Platinen zu koppelnden IoT-Module auf. Die Stapelverbinder ermöglichen, die IoT-Module und die Platinen so miteinander zu koppeln, dass Platinen und Module nicht falsch eingesetzt werden können.
Beispiel 122 weist den Gegenstand von Beispiel 121 auf. Die Stapelverbinder stellen eine gemeinsame Pinbelegung für die Platinen und die IoT-Module bereit.
Beispiel 123 weist den Gegenstand eines der Beispiele 121 bis 122 auf. Die Stapelverbinder stellen eine polarisierte Stapelverbindung bereit.
Beispiel 124 weist den Gegenstand eines der Beispiele 121 bis 123 auf. Die Stapelverbinder weisen ein vollständiges Durchgangsdesign auf.
Beispiel 125 weist den Gegenstand eines der Beispiele 121 bis 124 auf. Die Stapelverbinder weisen eine variable Verbinderhöhe auf, um lokale Schaltungen auf einer Platine oder einem IoT-Modul aufzunehmen.
Beispiel 126 weist den Gegenstand eines der Beispiele 121 bis 125 auf. Jede Platine kann in beliebiger Reihenfolge ohne physische Kollision von Komponenten gestapelt werden.
Beispiel 127 weist den Gegenstand eines der Beispiele 121 bis 126 auf. Pinbelegungen der Stapelverbinder sind von einer Funktion jeder Platine unabhängig.
Beispiel 128 weist den Gegenstand eines der Beispiele 121 bis 127 auf. Die IoT-Module weisen ein oder mehrere IoT-Rechenmodule, ein oder mehrere IoT-Konnektivitätsmodule, ein oder mehrere IoT-Sensormodule und/oder ein oder mehrere IoT-Stromversorgungsmodule auf.
Beispiel 129 weist den Gegenstand eines der Beispiele 121 bis 128 auf. Die Pinbelegung der Stapelverbinder ist von einer Funktion jeder Platine unabhängig, um das Stapeln unterschiedlicher IoT-Module, Basissysteme und/oder Abschirmungen unabhängig von Funktion oder Reihenfolge zu ermöglichen.
Beispiel 130 weist den Gegenstand eines der Beispiele 121 bis 129 auf. Die Stapelverbinder ermöglichen ein vertikales Stapeln.
Beispiel 131 weist den Gegenstand eines der Beispiele 121 bis 130 auf. Die Stapelverbinder ermöglichen ein horizontales Stapeln.
Beispiel 132 weist den Gegenstand eines der Beispiele 121 bis 131 auf. Die Stapelverbinder ermöglichen Modulpositionen entlang von Kanten von mindestens einigen der Platinen.
Beispiel 133 weist den Gegenstand eines der Beispiele 121 bis 132 auf. Die Stapelverbinder ermöglichen Konnektivitätsmodulpositionen entlang von Kanten von mindestens einigen der Platinen.
Beispiel 134 weist den Gegenstand eines der Beispiele 121 bis 133 auf. Ausschlüsse befinden sich entlang von Kanten von mindestens einigen der Platinen.
Beispiel 135 weist den Gegenstand eines der Beispiele 121 bis 134 auf. Ausschlüsse auf den IoT-Modulen an einer gemeinsamen Position stellen eine gemeinsame Ausschlusszone auf jedem der IoT-Module für IoT-Funkmodulantennen bereit.
Beispiel 136 In einigen Beispielen weist ein Verfahren Routen von Daten an unabhängig entwickelte Komponenten in einem IoT-System, wodurch den Komponenten ermöglicht wird, einen datentypunabhängigen Informationsaustausch miteinander zu implementieren, und Zuweisen einer eindeutigen Kennung zu jeder Komponente, um die Komponente in die Lage zu versetzen, Informationen zu senden und/oder zu empfangen, auf.
Beispiel 137 weist den Gegenstand von Beispiel 136 auf. Das Verfahren wird in einem Anwendungsbereich der Zielsteuerung implementiert.
Beispiel 138 weist den Gegenstand eines der Beispiele 136 bis 137 auf. Das Verfahren ist von Inhalten von Dateneingaben der Komponenten unabhängig.
Beispiel 139 weist den Gegenstand eines der Beispiele 136 bis 138 auf. Das Verfahren besteht darin, die Komponenten lose zu koppeln und Komponenten dynamisch an das IoT-System zu binden, ohne deren interne Struktur zu verstehen.
Beispiel 140 weist den Gegenstand eines der Beispiele 136 bis 139 auf. Das Verfahren besteht darin, Merkmale eines Nutzlastdatenverkehrs zu verwenden, um seine Beziehung zu Komponenten in einem eingebetteten System zu bestimmen.
Beispiel 141 weist den Gegenstand eines der Beispiele 136 bis 140 auf. Das Verfahren routet Daten zwischen den Komponenten unter Verwendung von Publizierer-Abonnenten-Techniken. Eine oder mehrere der Komponenten können Daten in dem IoT-System publizieren und/oder abonnieren.
Beispiel 142 weist den Gegenstand eines der Beispiele 136 bis 141 auf. Das Verfahren ist mit präemptiven und nicht präemptiven Aufgabenplanern kompatibel.
Beispiel 143 weist den Gegenstand eines der Beispiele 136 bis 142 auf. Die Komponenten sind unabhängig entwickelte, tief eingebettete Komponenten. Das Verfahren weist Verbinden der Komponenten, ohne eine komplexe Kenntnis der inneren Funktionsweise der Komponenten zu haben, auf.
Beispiel 144 weist den Gegenstand eines der Beispiele 136 bis 143 auf. Das Verfahren weist Ermöglichen, dass die Komponenten Informationen miteinander austauschen, ohne dass Konstrukte der Datenursprungskomponente in eine Datenzielkomponente eingebettet werden, auf.
Beispiel 145 weist den Gegenstand eines der Beispiele 136 bis 144 auf. Das Verfahren weist Validieren jeder Komponente unter Verwendung eines Komponenten-Plugin-Moduls auf.
Beispiel 146 weist den Gegenstand eines der Beispiele 136 bis 145 auf. Das Verfahren weist Ermöglichen, dass ein oder mehrere Datenmanager-Clients ein Verhalten des Datenmanagers oder eines anderen Datenmanager-Clients konfigurieren, auf.
Beispiel 147 weist den Gegenstand eines der Beispiele 136 bis 146 auf. Das Verfahren weist Ermöglichen, dass ein oder mehrere Datenmanager-Clients ein Verhalten des Datenmanagers oder eines Daten-/Ereignispublizierers konfigurieren, auf.
Beispiel 148 weist den Gegenstand eines der Beispiele 136 bis 147 auf. Das Verfahren weist Routen von Daten zwischen Komponenten, die Daten publizieren, und Komponenten, die Daten abonnieren, auf.
Beispiel 149 In einigen Beispielen weist ein Internet-der-Dinge-(IoT) Verfahren Bereitstellen von mehreren integrierten Stromversorgungen, die passive Komponenten für On-Chip-Spannungsregler aufweisen, wobei mehrere Spannungsschienen unterschiedlichen Spannungswerten entsprechen, auf. Das Verfahren weist eine Leistungssequenzierung zur Bereitstellung einer eigenständigen Stromversorgung, und Verwenden eines oder mehrerer modularer Stapelverbinder zum Koppeln der mehreren Spannungsschienen mit einem anderen Gerät auf.
Beispiel 150 weist den Gegenstand von Beispiel 149 auf. Das Verfahren weist Bereitstellen eines IoT-Moduls auf.
Beispiel 151 weist den Gegenstand eines der Beispiele 149 bis 150 auf. Das IoT-Verfahren weist Bereitstellen eines oder mehrerer IoT-Rechenmodule, eines IoT-Sensormoduls und/oder eines IoT-Konnektivitätsmoduls auf.
Beispiel 152 weist den Gegenstand eines der Beispiele 149 bis 151 auf. Das Verfahren weist Verwenden eines oder mehrerer modularer Stapelverbinder zum Koppeln der mehreren Spannungsschienen mit einer Platine und/oder einem IoT-Modul auf.
Beispiel 153 weist den Gegenstand eines der Beispiele 149 bis 152 auf. Die passiven Komponenten weisen Schaltinduktoren und Kondensatoren auf.
Beispiel 154 weist den Gegenstand eines der Beispiele 149 bis 153 auf. Das Verfahren weist eine Leistungssequenzierung unter Verwendung eines Stromversorgungspfads und eines Steuerungssystems mit mehreren Quellen auf.
Beispiel 155 weist den Gegenstand eines der Beispiele 149 bis 154 auf. Die IoT-Vorrichtung ist ein IoT-Edge-Gerät.
Beispiel 156 weist den Gegenstand eines der Beispiele 149 bis 155 auf. Das Verfahren weist Bereitstellen und/oder Empfangen mehrerer Spannungen zu/von mehreren IoT-Modulen über die Stapelverbinder auf.
Beispiel 157 weist den Gegenstand eines der Beispiele 149 bis 156 auf. Das Verfahren weist Abgreifen von Pins einer gemeinsamen Schiene der Stapelverbinder und Bereitstellen einer Spannung in Abhängigkeit von den On-Chip-Spannungsintegratoren auf.
Beispiel 158 weist den Gegenstand eines der Beispiele 149 bis 157 auf. Das Verfahren weist Verwenden von Pins einer gemeinsamen Schiene der Stapelverbinder zum Empfangen von Spannungen auf.
Beispiel 159 weist den Gegenstand eines der Beispiele 149 bis 158 auf. Das Verfahren weist eine Leistungssequenzierung unter Verwendung von programmierbaren Zustandsmaschinengeräten, um die Startzeiten mehrerer Netzteile zu steuern, auf.
Beispiel 160 In einigen Beispielen weist ein Internet-der-Dinge-(IoT) Verfahren Verwenden eines eindeutigen privaten Schlüssels zum Identifizieren, dass die IoT-Vorrichtung authentisch ist, und zur Sicherung der Identifikation und des Vertrauens auf. Das Verfahren weist Starten in einem nicht authentifizierten Zustand und ein drahtloses Signalisieren per Funkbake der Präsenz der IoT-Vorrichtung, Authentifizieren, Beitreten zu einem IoT-Netzwerk, und Senden von Daten an das IoT-Netzwerk nach der Authentifizierung auf.
Beispiel 161 weist den Gegenstand von Beispiel 160 auf. Das Verfahren weist Zeitmultiplexen zum Verwalten von drahtlosen Kanälen, Maximieren des Durchsatzes, und Bereitstellen von Skalierbarkeit auf.
Beispiel 162 weist den Gegenstand eines der Beispiele 160 bis 161 auf. Das Verfahren weist Empfangen von Daten von dem IoT-Netzwerk auf.
Beispiel 163 weist den Gegenstand eines der Beispiele 160 bis 162 auf. Das Verfahren weist Verschlüsseln von Daten, die an das IoT-Netzwerk gesendet werden, auf.
Beispiel 164 weist den Gegenstand eines der Beispiele 160 bis 163 auf. Das Verfahren weist Erkennen von Fehlerzuständen auf.
Beispiel 165 In einigen Beispielen weist ein Internet-der-Dinge- (IoT) Verfahren Verwenden eines oder mehrerer Stapelverbinder zum Koppeln einer IoT-Vorrichtung mit einer oder mehreren Platinen und/oder einem oder mehreren IoT-Modulen, Empfangen einer aktuellen Konfiguration, und Aktualisieren eines On-Chip-Flashspeichers durch Empfangen einer Flash-Aktualisierung über den Empfänger auf.
Beispiel 166 weist den Gegenstand von Beispiel 165 auf. Das Verfahren weist Aktualisieren des Flashspeichers basierend auf Hardware- und Firmware-Übereinstimmungen auf.
Beispiel 167 weist den Gegenstand eines der Beispiele 165 bis 166 auf. Das Verfahren weist Aktualisieren des On-Chip-Flashspeichers basierend auf Platinen und/oder IoT-Modulen, die mit der IoT-Vorrichtung gekoppelt sind, auf.
Beispiel 168 weist den Gegenstand eines der Beispiele 165 bis 167 auf. Das Verfahren weist Koppeln der IoT-Vorrichtung an ein IoT-System unter Verwendung eines drahtlosen persönlichen Bereichsnetzwerks auf.
Beispiel 169 weist den Gegenstand eines der Beispiele 165 bis 168 auf. Das Verfahren weist Empfangen der Flash-Aktualisierung über Bit-Banging an Programmierpins der IoT-Vorrichtung auf.
Beispiel 170 weist den Gegenstand eines der Beispiele 165 bis 169 auf. Das Verfahren weist auf, falls die IoT-Vorrichtung direkt mit einem Drahtlos-Manager verbunden ist, Empfangen der Flash-Aktualisierung, bevor Knoten, die nicht direkt mit dem Drahtlos-Manager verbunden sind, ein Flash-Aktualisierung empfangen.
Beispiel 171 weist den Gegenstand eines der Beispiele 165 bis 170 auf. Das Verfahren weist Aktualisieren des Flashspeichers von IoT-Geräten, die sich neben der IoT-Vorrichtung befinden, auf.
Beispiel 172 weist den Gegenstand eines der Beispiele 166 bis 171 auf. Das Verfahren weist Empfangen der Flash-Aktualisierung von einem Drahtlos-Manager auf.
Beispiel 173 weist den Gegenstand eines der Beispiele 166 bis 172 auf. Das Verfahren weist Empfangen der Flash-Aktualisierung von einem IoT-Gerät, das sich neben der IoT-Vorrichtung befindet, auf.
Beispiel 174 In einigen Beispielen weist ein Internet-der-Dinge-(IoT) Verfahren Empfangen einer Angabe, ob eine IoT-Vorrichtung ein Master-IoT-Knoten ist, auf. Falls die IoT-Vorrichtung ein Master-IoT-Knoten ist, weist das Verfahren Empfangen von Daten von anderen IoT-Knoten, die keine Master-IoT-Knoten sind, auf. Das Verfahren weist Senden von Daten an einen Master-IoT-Knoten, falls die IoT-Vorrichtung kein Master-IoT-Knoten ist, auf.
Beispiel 175 weist den Gegenstand von Beispiel 174 auf. Ein Verfahren weist Bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, und falls die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, Beitreten zu dem Cluster auf.
Beispiel 176 weist den Gegenstand eines der Beispiele 174 bis 175 auf. Das Verfahren weist Bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, auf. Das Verfahren weist Suchen eines Clusters von IoT-Knoten und Beitreten zu dem Cluster auf. Falls die IoT-Vorrichtung kein Cluster von IoT-Knoten gefunden hat, weist das Verfahren Bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet, auf. Das Verfahren weist auf, falls die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet, Erzeugen eines neuen Clusters von IoT-Knoten mit dem gefundenen IoT-Knoten.
Beispiel 177 weist den Gegenstand eines der Beispiele 174 bis 176 auf. Das Verfahren weist Bestimmen, ob die IoT-Vorrichtung Teil eines IoT-Clusters ist, Bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich in einem Cluster von IoT-Knoten befindet, und Zusammenführen des IoT-Clusters der IoT-Vorrichtung und des Clusters von IoT-Knoten des gefundenen IoT-Knotens auf.
Beispiel 178 weist den Gegenstand eines der Beispiele 174 bis 177 auf. Das Verfahren weist Bestimmen, ob die IoT-Vorrichtung ein IoT-Gateway gefunden hat, und Speichern des gefundenen IoT-Gateways als mögliches IoT-Gateway, an das Daten gesendet werden sollen, auf.
Beispiel 179 weist den Gegenstand eines der Beispiele 174 bis 178 auf. Das Verfahren weist Anwenden von maschinellem Lernen auf empfangene Daten und Bestimmen, ob ein Ausreißer existiert, auf. Das Verfahren weist Anfordern von neuen Daten, falls ein Ausreißer existiert, auf. Das Verfahren weist Vorbereiten einer Datenübertragung, falls kein Ausreißer existiert, auf.
Beispiel 180 weist den Gegenstand eines der Beispiele 174 bis 179 auf. Das Verfahren weist Anwenden von maschinellem Lernen auf empfangene Daten und Bestimmen, ob ein Ausreißer existiert, auf. Das Verfahren weist Anfordern von neuen Daten, falls ein Ausreißer existiert, auf. Das Verfahren weist Bestimmen, ob ein Ausreißer mehr als einen Schwellenwert existiert hat, auf. Das Verfahren weist Markieren des Ausreißers als fehlgeschlagen, falls ein Ausreißer mehr als einen Schwellenwert existiert hat, auf. Das Verfahren weist Vorbereiten einer Datenübertragung, falls kein Ausreißer existiert, auf.
Beispiel 181 weist den Gegenstand eines der Beispiele 121 bis 180 auf. Ein Verfahren zum Zusammenbauen einer modularen Internet-der-Dinge- (IoT) Vorrichtung weist Bereitstellen von Verbindern zum Koppeln mehrerer Platinen mit anderen Platinen und mit IoT-Modulen auf. Die Verbinder weisen Stapelverbinder auf beiden Seiten von mindestens einigen der Platinen und mindestens einigen der mit den Platinen zu koppelnden IoT-Module auf. Die Stapelverbinder ermöglichen es, die IoT-Module und die Platinen so miteinander zu koppeln, dass Platinen und Module nicht falsch eingesetzt werden können.
Beispiel 182 weist den Gegenstand eines der Beispiele 121 bis 181 auf. Die Stapelanschlüsse stellen eine gemeinsame Pinbelegung für die Platinen und die IoT-Module bereit.
Beispiel 183 weist den Gegenstand eines der Beispiele 121 bis 122 auf. Die Stapelverbinder stellen eine polarisierte Stapelverbindung bereit.
Beispiel 184 weist den Gegenstand eines der Beispiele 121 bis 123 auf. Die Stapelverbinder weisen ein vollständiges Durchgangsdesign auf.
Beispiel 185 weist den Gegenstand eines der Beispiele 121 bis 124 auf. Die Stapelverbinder weisen eine variable Verbinderhöhe auf, um lokale Schaltungen auf einer Platine oder einem IoT-Modul aufzunehmen.
Beispiel 186 weist den Gegenstand eines der Beispiele 121 bis 125 auf. Jede Platine kann in beliebiger Reihenfolge ohne physische Kollision von Komponenten gestapelt werden.
Beispiel 187 weist den Gegenstand eines der Beispiele 121 bis 126 auf. Pinbelegungen der Stapelverbinder sind von eine Funktion jeder Platine unabhängig.
Beispiel 188 weist den Gegenstand eines der Beispiele 121 bis 127 auf. Die IoT-Module weisen ein oder mehrere IoT-Rechenmodule, ein oder mehrere IoT-Konnektivitätsmodule, ein oder mehrere IoT-Sensormodule und/oder ein oder mehrere IoT-Stromversorgungsmodule auf.
Beispiel 189 weist den Gegenstand eines der Beispiele 121 bis 128 auf. Die Pinbelegung der Stapelverbinder ist unabhängig von einer Funktion jeder Platine, um das Stapeln unterschiedlicher IoT-Module, Basissysteme und/oder Abschirmungen unabhängig von Funktion oder Reihenfolge zu ermöglichen.
Beispiel 190 weist den Gegenstand eines der Beispiele 121 bis 129 auf. Die Stapelverbinder ermöglichen ein vertikales Stapeln.
Beispiel 191 weist den Gegenstand eines der Beispiele 121 bis 130 auf. Die Stapelverbinder ermöglichen ein horizontales Stapeln.
Beispiel 192 weist den Gegenstand eines der Beispiele 121 bis 131 auf. Die Stapelverbinder ermöglichen Modulpositionen entlang von Kanten von mindestens einigen der Platinen.
Beispiel 193 weist den Gegenstand eines der Beispiele 121 bis 132 auf. Die Stapelverbinder ermöglichen Konnektivitätsmodulpositionen von Kanten von mindestens einigen der Platinen.
Beispiel 194 weist den Gegenstand eines der Beispiele 121 bis 133 auf. Ausschlüsse befinden sich entlang von Kanten von mindestens einigen der Platinen.
Beispiel 195 weist den Gegenstand eines der Beispiele 121 bis 134 auf. Ausschlüsse auf den IoT-Modulen an einer gemeinsamen Position stellen eine gemeinsame Ausschlusszone auf jedem der IoT-Module für IoT-Funkmodulantennen bereit.
Beispiel 196 In einigen Beispielen weist ein Verfahren Routen von Daten an unabhängig entwickelte Komponenten in einem IoT-System, wodurch den Komponenten ermöglicht wird, einen datentypunabhängigen Informationsaustausch miteinander zu implementieren, und Zuweisen einer eindeutigen Kennung zu jeder Komponente, um die Komponente in die Lage zu versetzen, Informationen zu senden und/oder zu empfangen, auf.
Beispiel 197 weist den Gegenstand von Beispiel 136 auf. Das Verfahren wird in einem Zielsteuerungs-Anwendungsbereich implementiert.
Beispiel 198 weist den Gegenstand eines der Beispiele 136 bis 137 auf. Das Verfahren ist von Inhalten von Dateneingaben der Komponenten unabhängig.
Beispiel 199 weist den Gegenstand eines der Beispiele 136 bis 138 auf. Das Verfahren besteht darin, die Komponenten lose zu koppeln und Komponenten dynamisch an das IoT-System zu binden, ohne deren interne Struktur zu verstehen.
Beispiel 200 weist den Gegenstand eines der Beispiele 136 bis 139 auf. Das Verfahren besteht darin, Charakteristiken eines Nutzlastdatenverkehrs zu verwenden, um seine Beziehung zu Komponenten in einem eingebetteten System zu bestimmen.
Beispiel 201 weist den Gegenstand eines der Beispiele 136 bis 140 auf. Das Verfahren routet Daten zwischen den Komponenten unter Verwendung von Publizierer-Abonnenten-Techniken. Eine oder mehrere der Komponenten können Daten in dem IoT-System publizieren und/oder abonnieren.
Beispiel 202 weist den Gegenstand eines der Beispiele 136 bis 141 auf. Das Verfahren ist mit präemptiven und nicht präemptiven Aufgabenplanern kompatibel.
Beispiel 203 weist den Gegenstand eines der Beispiele 136 bis 142 auf. Die Komponenten sind unabhängig entwickelte, tief eingebettete Komponenten. Das Verfahren weist Verbinden der Komponenten, ohne eine komplexe Kenntnis einer inneren Funktionsweise der Komponenten zu haben, auf.
Beispiel 204 weist den Gegenstand eines der Beispiele 136 bis 143 auf. Das Verfahren weist Ermöglichen, dass die Komponenten Informationen miteinander austauschen, ohne dass Konstrukte der Datenursprungskomponente in eine Datenzielkomponente eingebettet werden, auf.
Beispiel 205 weist den Gegenstand eines der Beispiele 136 bis 144 auf. Das Verfahren weist Validieren jeder Komponente unter Verwendung eines Komponenten-Plugin-Moduls auf.
Beispiel 206 weist den Gegenstand eines der Beispiele 136 bis 145 auf. Das Verfahren weist Ermöglichen, dass ein oder mehrere Datenmanager-Clients ein Verhalten des Datenmanagers oder eines anderen Datenmanager-Clients konfigurieren, auf.
Beispiel 207 weist den Gegenstand eines der Beispiele 136 bis 146 auf. Das Verfahren weist Ermöglichen, dass ein oder mehrere Datenmanager-Clients ein Verhalten des Datenmanagers oder eines Daten-/Ereignispublizierers konfigurieren, auf.
Beispiel 208 weist den Gegenstand eines der Beispiele 136 bis 147 auf. Das Verfahren weist Routen von Daten zwischen Komponenten, die Daten publizieren, und Komponenten, die Daten abonnieren, auf.
Beispiel 209 In einigen Beispielen weist ein Internet-der-Dinge- (IoT) Verfahren Bereitstellen von mehreren integrierten Stromversorgungen, die passive Komponenten für On-Chip-Spannungsregler aufweisen, wobei mehrere Spannungsschienen unterschiedlichen Spannungswerten entsprechen, auf. Das Verfahren weist eine Leistungssequenzierung, um eine eigenständige Stromversorgung bereitzustellen, und Verwenden eines oder mehrerer modularer Stapelverbinder, um die mehreren Spannungsschienen mit einem anderen Gerät zu koppeln, auf.
Beispiel 210 weist den Gegenstand von Beispiel 149 auf. Das Verfahren weist Bereitstellen eines IoT-Moduls auf.
Beispiel 211 weist den Gegenstand eines der Beispiele 149 bis 150 auf. Das IoT-Verfahren weist Bereitstellen eines oder mehrerer IoT-Rechenmodule, eines IoT-Sensormoduls und/oder eines IoT-Konnektivitätsmoduls auf.
Beispiel 212 weist den Gegenstand eines der Beispiele 149 bis 151 auf. Das Verfahren weist Verwenden eines oder mehrerer modularer Stapelverbinder zum Koppeln der mehreren Spannungsschienen mit einer Platine und/oder einem IoT-Modul auf.
Beispiel 213 weist den Gegenstand eines der Beispiele 149 bis 152 auf. Die passiven Komponenten weisen Schaltinduktoren und Kondensatoren auf.
Beispiel 214 weist den Gegenstand eines der Beispiele 149 bis 153 auf. Das Verfahren weist eine Leistungssequenzierung unter Verwendung eines Stromversorgungspfads und eines Steuerungssystems mit mehreren Quellen auf.
Beispiel 215 weist den Gegenstand eines der Beispiele 149 bis 154 auf. Die IoT-Vorrichtung ist ein IoT-Edge-Gerät.
Beispiel 216 weist den Gegenstand eines der Beispiele 149 bis 155 auf. Das Verfahren weist Bereitstellen und/oder Empfangen mehrerer Spannungen zu/von mehreren IoT-Modulen über die Stapelverbinder auf.
Beispiel 217 weist den Gegenstand eines der Beispiele 149 bis 156 auf. Das Verfahren weist Abgreifen von Pins einer gemeinsamen Schiene der Stapelverbinder und Bereitstellen einer Spannung in Abhängigkeit von den On-Chip-Spannungsintegratoren auf.
Beispiel 218 weist den Gegenstand eines der Beispiele 149 bis 157 auf. Das Verfahren weist Verwenden von Pins einer gemeinsamen Schiene der Stapelverbinder zum Empfangen von Spannungen auf.
Beispiel 219 weist den Gegenstand eines der Beispiele 149 bis 158 auf. Das Verfahren weist eine Leistungssequenzierung unter Verwendung von programmierbaren Zustandsmaschinengeräten, um die Startzeiten mehrerer Netzteile zu steuern, auf.
Beispiel 220 In einigen Beispielen weist ein Internet der Dinge- (IoT) Verfahren Verwenden eines eindeutigen privaten Schlüssels zum Identifizieren, ob die IoT-Vorrichtung authentisch ist, und zur Sicherung der Identifikation und des Vertrauen auf. Das Verfahren weist Starten in einem nicht authentifizierten Zustand und ein drahtloses Signalisieren per Funkbake der Präsenz der IoT-Vorrichtung, Authentifizieren, Beitreten in ein IoT-Netzwerk, und Senden von Daten an das IoT-Netzwerk nach der Authentifizierung auf.
Beispiel 221 weist den Gegenstand von Beispiel 160 auf. Das Verfahren weist Zeitmultiplexen zum Verwalten von drahtlosen Kanälen, Maximieren des Durchsatzes, und Bereitstellen von Skalierbarkeit auf.
Beispiel 222 weist den Gegenstand eines der Beispiele 160 bis 161 auf. Das Verfahren weist Empfangen von Daten von dem IoT-Netzwerk auf.
Beispiel 223 weist den Gegenstand eines der Beispiele 160 bis 162 auf. Das Verfahren weist Verschlüsseln von Daten, die an das IoT-Netzwerk gesendet werden, auf.
Beispiel 224 weist den Gegenstand eines der Beispiele 160 bis 163 auf. Das Verfahren weist Erkennen von Fehlerzuständen auf.
Beispiel 225 In einigen Beispielen weist ein Internet-der-Dinge- (IoT) Verfahren Verwenden eines oder mehrerer Stapelverbinder zum Koppeln einer IoT-Vorrichtung mit einer oder mehreren Platinen und/oder einem oder mehreren IoT-Modulen, Empfangen einer aktuellen Konfiguration, und Aktualisieren eines On-Chip-Flashspeicher durch Empfangen einer Flash-Aktualisierung über den Empfänger auf.
Beispiel 226 weist den Gegenstand von Beispiel 165 auf. Das Verfahren weist Aktualisieren des Flashspeichers basierend auf Hardware- und Firmware-Übereinstimmungen auf.
Beispiel 227 weist den Gegenstand eines der Beispiele 165 bis 166 auf. Das Verfahren weist Aktualisieren des On-Chip-Flashspeichers basierend auf Platinen und/oder IoT-Modulen, die mit der IoT-Vorrichtung gekoppelt sind, auf.
Beispiel 228 weist den Gegenstand eines der Beispiele 165 bis 167 auf. Das Verfahren weist Koppeln der IoT-Vorrichtung an ein IoT-System unter Verwendung eines drahtlosen persönlichen Bereichsnetzwerks auf.
Beispiel 229 weist den Gegenstand eines der Beispiele 165 bis 168 auf. Das Verfahren weist Empfangen der Flash-Aktualisierung über Bit-Banging an Programmierpins der IoT-Vorrichtung auf.
Beispiel 230 weist den Gegenstand eines der Beispiele 165 bis 169 auf. Das Verfahren weist auf, falls die IoT-Vorrichtung direkt mit einem Drahtlos-Manager verbunden ist, Empfangen der Flash-Aktualisierung, bevor Knoten, die nicht direkt mit dem Drahtlos-Manager verbunden sind, ein Flash-Aktualisierung empfangen.
Beispiel 231 weist den Gegenstand eines der Beispiele 165 bis 170 auf. Das Verfahren weist Aktualisieren des Flashspeichers von IoT-Geräten, die sich neben der IoT-Vorrichtung befinden, auf.
Beispiel 232 weist den Gegenstand eines der Beispiele 166 bis 171 auf. Das Verfahren weist Empfangen der Flash-Aktualisierung von einem Drahtlos-Manager auf.
Beispiel 233 weist den Gegenstand eines der Beispiele 166 bis 172 auf. Das Verfahren weist Empfangen der Flash-Aktualisierung von einem IoT-Gerät, das sich neben der IoT-Vorrichtung befindet, auf.
Beispiel 234 In einigen Beispielen weist ein Internet-der-Dinge- (IoT) Verfahren Empfangen einer Angabe, ob eine IoT-Vorrichtung ein Master-IoT-Knoten ist, auf. Falls die IoT-Vorrichtung ein Master-IoT-Knoten ist, weist das Verfahren Empfangen von Daten von anderen IoT-Knoten, die keine Master-IoT-Knoten sind, auf. Das Verfahren weist Senden von Daten an einen Master-IoT-Knoten, falls die IoT-Vorrichtung kein Master-IoT-Knoten ist, auf.
Beispiel 235 weist den Gegenstand von Beispiel 174 auf. Ein Verfahren weist Bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, und, falls die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, Beitreten zu dem Cluster auf.
Beispiel 236 weist den Gegenstand eines der Beispiele 174 bis 175 auf. Das Verfahren weist Bestimmen, ob die IoT-Vorrichtung ein Cluster von IoT-Knoten gefunden hat, auf. Das Verfahren weist Suchen eines Clusters von IoT-Knoten und Beitreten zu dem Cluster auf. Falls die IoT-Vorrichtung kein Cluster von IoT-Knoten gefunden hat, weist das Verfahren Bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet, auf. Das Verfahren weist auf, falls die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich nicht in einem Cluster von IoT-Knoten befindet, Erzeugen eines neuen Clusters von IoT-Knoten mit dem gefundenen IoT-Knoten.
Beispiel 237 weist den Gegenstand eines der Beispiele 174 bis 176 auf. Das Verfahren weist Bestimmen, ob die IoT-Vorrichtung Teil eines IoT-Clusters ist, Bestimmen, ob die IoT-Vorrichtung einen IoT-Knoten gefunden hat, der sich in einem Cluster von IoT-Knoten befindet, und Zusammenführen des IoT-Clusters der IoT-Vorrichtung und des Clusters von IoT-Knoten des gefundenen IoT-Knotens auf.
Beispiel 238 weist den Gegenstand eines der Beispiele 174 bis 177 auf. Das Verfahren weist Bestimmen, ob die IoT-Vorrichtung ein IoT-Gateway gefunden hat, und Speichern des gefundenen IoT-Gateways als mögliches IoT-Gateway, an das Daten gesendet werden sollen, auf.
Beispiel 239 weist den Gegenstand eines der Beispiele 174 bis 178 auf. Das Verfahren weist Anwenden von maschinellem Lernen auf empfangene Daten und Bestimmen, ob ein Ausreißer existiert, auf. Das Verfahren weist Anfordern von neuen Daten, falls ein Ausreißer existiert, auf. Das Verfahren weist Vorbereiten einer Datenübertragung, falls kein Ausreißer existiert, auf.
Beispiel 240 weist den Gegenstand eines der Beispiele 174 bis 179 auf. Das Verfahren weist Anwenden von maschinellem Lernen auf empfangene Daten und Bestimmen, ob ein Ausreißer existiert, auf. Das Verfahren weist Anfordern neuer Daten, falls ein Ausreißer existiert, auf. Das Verfahren weist Bestimmen, ob ein Ausreißer mehr als einen Schwellenwert existiert hat, auf. Das Verfahren weist auf, falls ein Ausreißer mehr als einen Schwellenwert existiert hat, Markieren des Ausreißers als fehlgeschlagen. Das Verfahren weist Vorbereiten der Datenübertragung, falls kein Ausreißer existiert, auf.
Beispiel 241 weist eine Vorrichtung auf, die Mittel zum Durchführen eines Verfahrens wie in einem anderen Beispiel aufweist.
Beispiel 242 weist einen maschinenlesbaren Speicher auf, der maschinenlesbarer Anweisungen aufweist, die dazu dienen, wenn sie ausgeführt werden, ein Verfahren zu implementieren oder eine Vorrichtung zu realisieren wie in jedem anderen Beispiel.
Beispiel 243 weist ein oder mehrere computerlesbare Medien auf, die Anweisungen aufweisen, die, wenn sie ausgeführt werden, dazu dienen, ein Verfahren zu implementieren oder eine Vorrichtung zu realisieren wie in jedem anderen Beispiel.
Einige Ausführungsformen können in einer von Hardware, Firmware und Software oder einer Kombination davon implementiert werden. Einige Ausführungsformen können auch als Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind, das von einer Computerplattform gelesen und ausgeführt werden kann, um die hier beschriebenen Operationen auszuführen. Ein maschinenlesbares Medium kann einen beliebigen Mechanismus zum Speichern oder Senden von Informationen in einer Form aufweisen, die von einer Maschine, z. B. einem Computer, gelesen werden können. Beispielsweise kann ein maschinenlesbares Medium unter anderem einen Nur-Lese-Speicher (ROM); Direktzugriffsspeicher (RAM); Speichermedien für Magnetplatten; optische Speichermedien; Flash-Speichergeräte; oder elektrische, optische, akustische oder sich in anderer Form ausbreitende Signale, z. B. Trägerwellen, Infrarotsignale, digitale Signale, oder die Schnittstellen, die Signale senden und/oder empfangen, aufweisen.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel. Die Bezugnahme in der Beschreibung auf „Ausführungsform“, „eine Ausführungsform“, „einige Ausführungsformen“, „verschiedene Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass eine bestimmte Charakteristik, eine bestimmte Struktur oder eine bestimmtes Merkmal, das in Verbindung mit den Ausführungsformen beschrieben wurde, in mindestens einigen Ausführungsformen, aber nicht notwendigerweise allen Ausführungsformen der Techniken enthalten ist. Die verschiedenen Erscheinungsformen von „Ausführungsform“, „einer Ausführungsform“ oder „einigen Ausführungsformen“ betreffen nicht notwendigerweise alle dieselben Ausführungsformen. Elemente oder Aspekte einer Ausführungsform können mit Elementen oder Aspekten einer anderen Ausführungsform kombiniert werden.
Nicht alle hierin beschriebenen und veranschaulichten Komponenten, Merkmale, Strukturen, Eigenschaften usw. müssen in einer bestimmten Ausführungsform oder Ausführungsformen enthalten sein. Falls in der Spezifikation eine Komponente, ein Merkmal, eine Struktur oder eine Charakteristik beispielsweise mit „sollte“, „dürfte“, „kann“ oder „könnte“ angegeben ist, muss diese bestimmte Komponente, dieses Merkmal, diese Struktur oder diese Charakteristik nicht notwendigerweise enthalten sein. Falls sich die Spezifikation oder der Anspruch auf „eines“ oder „ein“ Element bezieht, bedeutet dies nicht, dass nur eines der Elemente existiert. Falls sich die Spezifikation oder die Ansprüche auf „ein zusätzliches“ Element beziehen, schließt dies nicht aus, dass mehr als eines der zusätzlichen Elemente existieren.
Es ist anzumerken, dass, obwohl einige Ausführungsformen in Bezug auf bestimmte Implementierungen beschrieben wurden, gemäß einigen Ausführungsformen auch andere Implementierungen möglich sind. Außerdem muss die Anordnung und/oder Reihenfolge von Schaltungselementen oder anderen Merkmalen, die in den Zeichnungen veranschaulicht und/oder hierin beschrieben sind, nicht notwendigerweise in der besonderen veranschaulichten und beschriebenen Weise angeordnet sein. Viele andere Anordnungen sind möglich, gemäß einigen Ausführungsformen.
In jedem in einer Figur gezeigten System können in einigen Fällen die Elemente jeweils das gleiche Bezugszeichen oder ein anderes Bezugszeichen aufweisen, um anzuzeigen, dass die veranschaulichten Elemente unterschiedlich und/oder ähnlich sein könnten. Jedoch kann ein Element flexibel genug sein, um unterschiedliche Implementierungen zu haben und mit einigen oder allen hier gezeigten oder beschriebenen Systemen zu funktionieren. Die verschiedenen in den Figuren gezeigten Elemente können gleich oder unterschiedlich sein. Welches davon als erstes Element und welches als zweites Element bezeichnet wird, ist beliebig.
Die Techniken sind nicht auf die hier aufgeführten bestimmen Einzelheiten beschränkt. Tatsächlich werden Fachleute, die den Nutzen dieser Offenbarung genießen, erkennen, dass im Rahmen der vorliegenden Techniken viele andere Variationen von der vorstehenden Beschreibung und den Zeichnungen vorgenommen werden können. Dementsprechend sind es die folgenden Ansprüche, einschließlich etwaiger Änderungen, die den Umfang der Techniken definieren.

Claims

Modulare Internet-der-Dinge- (IoT) Vorrichtung, umfassend: mehrere Platinen; Verbinder zum Koppeln von IoT-Modulen mit einer oder mehreren der mehreren Platinen und zum Koppeln der mehreren Platinen miteinander, wobei die Verbinder Stapelverbinder auf beiden Seiten von mindestens einigen der Platinen und mindestens einigen der mit den Platinen zu koppelnden IoT-Module umfassen, wobei die Stapelverbinder ermöglichen, die IoT-Module und die Platinen so miteinander zu koppeln, dass Platinen und Module nicht falsch eingesetzt werden können.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die Stapelverbinder eine gemeinsame Pinbelegung für die Platinen und die IoT-Module bereitstellen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die Stapelverbinder eine polarisierte Stapelverbindung bereitstellen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die Stapelverbinder ein vollständiges Durchgangsdesign aufweisen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die Stapelverbinder eine variable Verbinderhöhe aufweisen, um lokale Schaltungen auf einer Platine oder einem IoT-Modul aufzunehmen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei jede Platine in beliebiger Reihenfolge ohne physische Kollision von Komponenten gestapelt werden kann.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei Pinbelegungen der Stapelverbinder von einer Funktion jeder Platine unabhängig sind.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die IoT-Module ein oder mehrere IoT-Rechenmodule, ein oder mehrere IoT-Konnektivitätsmodule, ein oder mehrere IoT-Sensormodule, und/oder ein oder mehrere IoT-Stromversorgungsmodule umfassen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei Pinbelegungen der Stapelverbinder von einer Funktion jeder Platine unabhängig sind, um ein Stapeln unterschiedlicher IoT-Module, Basissysteme und/oder Abschirmungen unabhängig von Funktion oder Reihenfolge zu ermöglichen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die Stapelverbinder dazu dienen, ein vertikales Stapeln oder horizontales Stapeln zu ermöglichen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die Stapelverbinder dazu dienen, Modulpositionen entlang von Kanten von mindestens einigen der Platinen zu ermöglichen.
Modulare IoT-Vorrichtung nach Anspruch 1, wobei die Stapelverbinder dazu dienen, Konnektivitätsmodulpositionen entlang von Kanten von mindestens einigen der Platinen zu ermöglichen.
Modulare IoT-Vorrichtung nach Anspruch 1, umfassend Ausschlüsse entlang von Kanten von mindestens einigen der Platinen.
Modulare IoT-Vorrichtung nach Anspruch 1, umfassend Ausschlüsse an den IoT-Modulen an einer gemeinsamen Position, um eine gemeinsame Ausschlusszone an jedem der IoT-Module für IoT-Funkmodulantennen berei tzustellen.
Modulare IoT-Vorrichtung nach Anspruch 1, umfassend: mehrere integrierte Stromversorgungen, die passive Komponenten für On-Chip-Spannungsregler aufweisen; mehrere Spannungsschienen, die unterschiedlichen Spannungswerten entsprechen; eine Leistungssequenzierungsschaltung zur Bereitstellung einer eigenständigen Stromversorgung; und einen oder mehrere modulare Stapelverbinder zum Koppeln der mehreren Spannungsschienen mit einem anderen Gerät.
Modulare IoT-Vorrichtung nach Anspruch 1, umfassend: einen eindeutigen privaten Schlüssel zum Identifizieren, ob die IoT-Vorrichtung authentisch ist, und zur Sicherung der Identifikation und des Vertrauens; einen Modus zum Starten in einem nicht authentifizierten Zustand und zum drahtlosen Signalisieren per Funkbake der Präsenz der IoT-Vorrichtung; einen Authentifizierungsmodus zum Beitreten zu einem IoT-Netzwerk; und ein Sender zum Senden von Daten an das IoT-Netzwerk nach der Authentifizierung.
Modulare IoT-Vorrichtung nach Anspruch 1, umfassend: einen oder mehrere Stapelverbinder zum Koppeln der IoT-Vorrichtung mit einer oder mehreren Platinen und/oder einem oder mehreren IoT-Modulen; einen Empfänger zum Empfangen einer aktuellen Konfiguration; und einen zu aktualisierenden On-Chip-Flashspeicher, wobei der On-Chip-Flashspeicher dazu dient, eine Flash-Aktualisierung über den Empfänger zu empfangen.
Modulare IoT-Vorrichtung nach Anspruch 1, umfassend: einen Empfänger zum Empfangen einer Angabe, ob die IoT-Vorrichtung ein Master-IoT-Knoten ist; falls die IoT-Vorrichtung ein Master-IoT-Knoten ist, Empfangen, durch den Empfänger, von Daten von anderen IoT-Knoten, die keine Master-IoT-Knoten sind, und einen Sender zum Senden von Daten an einen Master-IoT-Knoten, falls die IoT-Vorrichtung kein Master-IoT-Knoten ist.
Modulare IoT-Vorrichtung nach einem der Ansprüche 1 bis 18, umfassend: einen Datenmanager zum Routen von Daten an unabhängig entwickelte Komponenten in einem IoT-System, wobei der Datenmanager dazu dient, zu ermöglichen, dass die Komponenten einen datentypunabhängigen Informationsaustausch miteinander implementieren, wobei der Datenmanager dazu dient, jeder Komponente eine eindeutige Kennung zuzuweisen, um die Komponente in die Lage zu versetzen, Informationen über den Datenmanager zu senden und/oder zu empfangen.
Internet-der-Dinge- (IoT) Vorrichtung, umfassend: einen Datenmanager zum Routen von Daten an unabhängig entwickelte Komponenten in einem IoT-System, wobei der Datenmanager dazu dient, zu ermöglichen, dass die Komponenten einen datentypunabhängigen Informationsaustausch miteinander implementieren, wobei der Datenmanager dazu dient, jeder Komponente eine eindeutige Kennung zuzuweisen, um die Komponente in die Lage zu versetzen, Informationen über den Datenmanager zu senden und/oder zu empfangen.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager von Inhalten von Dateneingaben der Komponenten unabhängig ist.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager dazu dient, die Komponenten lose zu koppeln und Komponenten dynamisch an das IoT -System zu binden, ohne deren interne Struktur zu verstehen.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager einen Publizierer-Abonnenten zum Routen von Daten zwischen den Komponenten umfasst, wobei eine oder mehrere der Komponenten Daten in dem IoT-System publizieren und/oder abonnieren können.
IoT-Vorrichtung nach Anspruch 20, wobei die Komponenten unabhängig voneinander entwickelte, tief eingebettete Komponenten sind, wobei der Datenmanager die Komponenten miteinander verbindet, ohne eine komplexe Kenntnis einer inneren Funktionsweise der Komponenten zu haben.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager dazu dient, den Komponenten zu ermöglichen, Informationen miteinander auszutauschen, ohne dass Konstruktionen der Datenursprungskomponente in eine Datenzielkomponente eingebettet sind.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager einen Client-Registrierungsmanager zum Validieren jeder Komponente unter Verwendung eines Komponenten-Plugin-Moduls aufweist.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager einen Konfigurationsmanager zum Ermöglichen, dass ein oder mehrere Datenmanager-Clients ein Verhalten des Datenmanagers oder eines anderen Datenmanager-Clients konfigurieren, aufweist.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager einen Daten-/Ereignisabonnenten zum Ermöglichen, dass ein oder mehrere Datenmanager-Clients ein Verhalten des Datenmanagers oder eines Daten-/Ereignispublizierers konfigurieren, aufweist.
IoT-Vorrichtung nach Anspruch 20, wobei der Datenmanager einen Publizierer-Abonnenten zum Routen von Daten zwischen Komponenten, die Daten publizieren, und Komponenten, die Daten abonnieren, aufweist.