DE112019003316T5

DE112019003316T5 - Verteiltes berechnungsverfahren, vorrichtung und system

Info

Publication number: DE112019003316T5
Application number: DE112019003316.6T
Authority: DE
Inventors: Ned M. Smith; Nathan Heldt-Sheller; Shantanu Kulkarni; Siddharth Jain
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-06-29
Filing date: 2019-05-16
Publication date: 2021-04-08
Also published as: WO2020005406A1; US20190041853A1

Abstract

Vorrichtungen, Verfahren und Systeme zur Durchführung einer verteilten Berechnungsaufgabe durch ein CA/AD (Computer-Assisted/ Autonomous Drivingcomputergestütztes/autonomes Fahren) -Fahrzeug sind hierin offenbart. In Ausführungsformen kann eine Vorrichtung eine Kommunikationsschnittstelle angeordnet in dem CA/AD-Fahrzeug zum Empfangen der Berechnungsaufgabe beinhalten. In Ausführungsformen ist die Berechnungsaufgabe Teil einer Sammlung verteilter Berechnungsaufgaben, die dem CA/AD-Fahrzeug oder anderen Berechnungsvorrichtungen zumindest teilweise basierend auf Ressourcen, die dem CA/AD-Fahrzeug und den anderen Berechnungsvorrichtungen zur Verfügung stehen, zugewiesen werden. In Ausführungsformen kann eine Berechnungsmaschine die Berechnungsaufgabe zumindest teilweise unter Verwendung der verfügbaren Ressourcen des CA/AD-Fahrzeugs durchführen. Andere Ausführungsformen können offenbart und beansprucht sein.

Description

Verwandte Anmeldungen
Diese Anmeldung beansprucht Priorität gegenüber der US-Anmeldung 16/023,637 mit dem Titel „DISTRIBUTED COMPUTE METHOD, APPARATUS AND SYSTEM“, eingereicht am 29. Juni 2018.
Technisches Gebiet
Die vorliegende Offenbarung betrifft die Gebiete der Vernetzung, der verteilten Berechnung und des computergestützten oder autonomen Fahrens für Fahrzeuge, insbesondere Verfahren, Vorrichtungen und Systeme im Zusammenhang mit der Ausnutzung von Ressourcen von autonomen oder semiautonomen Fahrzeugen für die verteilte Berechnung.
Allgemeiner Stand der Technik
Die hierin bereitgestellte Hintergrundbeschreibung dient dem Zweck der allgemeinen Vorstellung des Kontextes der Offenbarung. Sofern hierin nicht anders angegeben, stellen die in diesem Abschnitt beschriebenen Materialien keinen Stand der Technik für die Ansprüche in dieser Anmeldung dar und gelten durch Einschluss in diesen Abschnitt nicht als Stand der Technik.
Für gemeinsam genutzte Berechnungslösungen können aufgrund von Zeitplanungs, Datenlokalitäts- und Synchronisationsanforderungen Gemeinkosten anfallen. Algorithmen für das Management einer verteilten Berechnung lassen sich häufig nicht gut skalieren und zur Verfügung stehende Arbeitslasten können unter Verwendung traditionellerer Hosting-Umgebungen kostengünstiger sein. Des Weiteren bestehen Sicherungs- und Sicherheitsrisiken hinsichtlich einer Isolierung der ,normalen' Arbeitslast von der ‚ausgelagerten' Arbeitslast für die Berechnung.
Figurenliste
Ausführungsformen werden durch die folgende detaillierte Beschreibung in Verbindung mit den beigefügten Zeichnungen leicht verstanden werden. Zur Vereinfachung dieser Beschreibung bezeichnen gleiche Referenzziffern gleiche Strukturelemente. Ausführungsformen sind in den Figuren der beigefügten Zeichnungen beispielhaft und nicht einschränkend veranschaulicht.

1 veranschaulicht eine Anordnung, die Zwischenverbindungen zeigt, die zwischen einem Netzwerk und Internet der Dinge (IoT - Internet of Things) - Netzwerken vorliegen können, in Übereinstimmung mit verschiedenen Ausführungsformen.
2 veranschaulicht eine beispielhafte Domänentopologie in Übereinstimmung mit verschiedenen Ausführungsformen.
3 veranschaulicht ein beispielhaftes Cloud-Computing-Netzwerk oder eine Cloud in Kommunikation mit einer Reihe von IoT-Geräten, einschließlich eines oder mehrerer Systeme für computergestütztes oder autonomes Fahren (CA/AD - Computer-Assisted/Autonomous Driving), in Übereinstimmung mit verschiedenen Ausführungsformen.
4 veranschaulicht eine Anordnung eines Cloud-Computing-Netzwerks oder einer Cloud in Kommunikation mit einem Mesh-Netzwerk von IoT-Geräten oder einem IoT-Fog in Übereinstimmung mit verschiedenen Ausführungsformen.
5 veranschaulicht eine beispielhafte Arbeitslastverteilungsumgebung im Zusammenhang mit einem oder mehreren CA/AD (Computer-Assisted/Autonomous Driving - computergestütztes/autonomes Fahren) - Fahrzeugen in Übereinstimmung mit verschiedenen Ausführungsformen.
6 veranschaulicht eine beispielhafte Hosting-Plattform, einschließlich des einen oder der mehreren CA/AD-Fahrzeuge von 5, in Übereinstimmung mit verschiedenen Ausführungsformen.
7 veranschaulicht eine Blockdiagrammansicht eines beispielhaften computergestützten oder autonomen Fahrsystems in Übereinstimmung mit verschiedenen Ausführungsformen.
8 veranschaulicht einen beispielhaften Prozess für das Zuweisen einer Kunden-Arbeitslast zu einem CA/AD-Fahrzeug in Übereinstimmung mit verschiedenen Ausführungsformen.
9 veranschaulicht einen beispielhaften Prozess für das Empfangen und Durchführen einer Berechnungsaufgabe durch ein CA/AD-Fahrzeug in Übereinstimmung mit verschiedenen Ausführungsformen.
10 veranschaulicht eine beispielhafte Implementierung einer Berechnungsplattform, die zur praktischen Umsetzung verschiedener Aspekte der vorliegenden Offenbarung geeignet ist, gemäß verschiedenen Ausführungsformen.
11 veranschaulicht ein beispielhaftes Computersystem, das zur Verwendung bei der praktischen Umsetzung der vorliegenden Offenbarung (oder Aspekten davon) geeignet ist, in Übereinstimmung mit verschiedenen Ausführungsformen.
12 veranschaulicht ein beispielhaftes Speichermedium mit Anweisungen, die dazu konfiguriert sind, einem computergestützten oder autonomen Fahrsystem die praktische Umsetzung der vorliegenden Offenbarung zu ermöglichen, in Übereinstimmung mit verschiedenen Ausführungsformen.

Detaillierte Beschreibung
Hierin werden Vorrichtungen, Verfahren und Systeme im Zusammenhang mit einer verteilten Berechnung unter Verwendung der Berechnungsressourcen in computergestützten oder autonomen Fahrzeugen und Systemen offenbart. In Ausführungsformen kann eine Vorrichtung zum Durchführen einer Berechnungsaufgabe eine Kommunikationsschnittstelle aufweisen, die in einem CA/AD (Computer-Assisted/Autonomous Driving - computergestütztes/autonomes Fahren) -Fahrzeug angeordnet ist. Die Berechnungsaufgabe kann in Ausführungsformen Teil einer Sammlung verteilter Berechnungsaufgaben sein, die dem CA/AD-Fahrzeug und anderen Berechnungsvorrichtungen zugewiesen werden. Eine Zuweisung einer verteilten Berechnungsaufgabe durch einen entfernten Management-Server (oder die Vorrichtung selbst) kann in Ausführungsformen zumindest teilweise auf Ressourcen basieren, die dem CA/AD-Fahrzeug und den anderen Berechnungsvorrichtungen zur Verfügung stehen. Das CA/AD-Fahrzeug kann in Übereinstimmung mit verschiedenen Ausführungsformen eine Verarbeitungseinheit, wie z.B. eine Berechnungsmaschine gekoppelt an die Kommunikationsschnittstelle, zum Empfangen der Berechnungsaufgabe und zum Durchführen der Berechnungsaufgabe zumindest teilweise unter Verwendung der zur Verfügung stehenden Ressourcen des CA/AD-Fahrzeugs aufweisen.
In der nun folgenden Beschreibung wird auf die beigefügten Zeichnungen verwiesen, welche einen Teil hiervon bilden, wobei gleiche Ziffern durchweg gleiche Teile bezeichnen und in welchen veranschaulichend Ausführungsformen gezeigt sind, die praktisch umgesetzt werden können. Es soll verstanden werden, dass auch andere Ausführungsformen genutzt werden können und strukturelle oder logische Veränderungen vorgenommen werden können, ohne sich vom Umfang der vorliegenden Offenbarung zu entfernen. Daher ist die folgende detaillierte Beschreibung nicht in einem einschränkenden Sinn zu sehen, und der Umfang von Ausführungsformen wird durch die angehängten Ansprüche und ihre Äquivalente definiert.
Operationen verschiedener Verfahren können wiederum als mehrere einzelne Aktionen oder Operationen beschrieben sein, in einer Art und Weise, die ein Verständnis des beanspruchten Gegenstandes am besten unterstützt. Jedoch soll die Reihenfolge der Beschreibung nicht implizieren, dass diese Operationen notwendigerweise reihenfolgeabhängig sind. Insbesondere können diese Operationen auch nicht in der Reihenfolge ihrer Vorstellung durchgeführt werden. Die beschriebenen Operationen können in einer unterschiedlichen Reihenfolge als in den beschriebenen Ausführungsformen durchgeführt werden. Verschiedene zusätzliche Operationen können durchgeführt werden und/oder beschriebene Operationen können in zusätzlichen Ausführungsformen weggelassen, aufgeteilt oder kombiniert werden.
Zum Zweck der vorliegenden Offenbarung bedeutet der Ausdruck „A und/oder B“ (A), (B) oder (A und B). Zum Zweck der vorliegenden Offenbarung bedeutet der Ausdruck „A, B und/oder C“ (A), (B), (C), (A und B), (A und C), (B und C) oder (A, B und C).
Die Beschreibung kann die Ausdrücke „in einer Ausführungsform“ oder „in Ausführungsformen“ verwenden, welche sich jeweils auf eine oder mehrere der gleichen oder unterschiedlichen Ausführungsformen beziehen können. Des Weiteren sind die Begriffe „umfassen“, „beinhalten“, „aufweisen“ und dergleichen, wie in Bezug auf Ausführungsformen der vorliegenden Offenbarung verwendet, synonym.
Die vorliegende Offenbarung wird unter Verweis auf Flussdiagramm-Veranschaulichungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es wird verstanden werden, dass jeder Block der Flussdiagramm-Veranschaulichungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagramm-Veranschaulichungen und/oder Blockdiagrammen durch Computerprogramm-Anweisungen implementiert werden können. Diese Computerprogramm-Anweisungen können an einen Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zum Erzeugen einer Maschine bereitgestellt werden, derart, dass die Anweisungen, welche über den Prozessor des Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Implementieren der Funktionen/Aktionen, die in dem/den Flussdiagramm- und/oder Blockdiagramm-Block oder -Blöcken spezifiziert sind, erzeugen.
Die Flussdiagramme und Blockdiagramme in den Figuren veranschaulichen die Architektur, Funktionalität und Operationen möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in den Flussdiagrammen oder Blockdiagrammen ein/en Modul, Segment oder Abschnitt von Code darstellen, welches/r eine oder mehrere ausführbare Anweisungen zur Implementierung der spezifizierten logischen Funktion(en) umfasst. Es sei auch darauf hingewiesen, dass in einigen alternativen Implementierungen die in dem Block angegebenen Funktionen auch in einer anderen Reihenfolge als der in den Figuren angegebenen stattfinden können. Zum Beispiel können zwei aufeinanderfolgend gezeigte Blöcke tatsächlich im Wesentlichen zeitgleich ausgeführt werden, oder die Blöcke können gelegentlich, in Abhängigkeit von der beteiligten Funktionalität, in umgekehrter Reihenfolge ausgeführt werden. Es sei auch darauf hingewiesen, dass jeder Block der Blockdiagramme und/oder Flussdiagramm-Veranschaulichungen und Kombinationen von Blöcken in den Blockdiagrammen und/oder Flussdiagramm-Veranschaulichungen durch Hardware-basierte Spezialsysteme, welche die spezifizierten Funktionen oder Aktionen durchführen, oder Kombinationen von Spezialhardware und Computeranweisungen implementiert werden können.
Obwohl ein Flussdiagramm die Operationen als einen sequentiellen Prozess beschreiben kann, können viele der Operationen parallel, zeitgleich oder gleichzeitig durchgeführt werden. Außerdem kann die Reihenfolge der Operationen neu geordnet werden. Ein Prozess kann beendet sein, wenn seine Operationen abgeschlossen sind, er kann jedoch auch zusätzliche Schritte aufweisen, die in der/den Figur(en) nicht enthalten sind. Ein Prozess kann einem Verfahren, einer Funktion, einer Prozedur, einer Unterroutine, einem Unterprogramm und dergleichen entsprechen. Wenn ein Prozess einer Funktion entspricht, kann seine Beendigung einer Rückkehr der Funktion zu der aufrufenden Funktion und/oder der Hauptfunktion entsprechen. Des Weiteren kann ein Prozess durch Hardware, Software, Firmware, Middleware, Mikrocode, Hardware-Beschreibungssprachen oder jegliche Kombination davon implementiert werden. Wenn er in Software, Firmware, Middleware oder Mikrocode implementiert wird, können der Programmcode oder Codesegmente zum Durchführen der notwendigen Aufgaben in einem maschinen- oder computerlesbaren Medium gespeichert sein. Ein Codesegment kann eine Prozedur, eine Funktion, ein Unterprogramm, ein Programm, eine Routine, eine Unterroutine, ein Modul, Programmcode, ein Softwarepaket, eine Klasse oder jegliche Kombination von Anweisungen, Datenstrukturen, Programmanweisungen und dergleichen darstellen.
Wie hierin verwendet, kann sich der Begriff „Schaltungen“ auf eine anwendungsspezifische integrierte Schaltung (ASIC - Application Specific Integrated Circuit), ein feldprogrammierbares Gate-Array (FPGA - Field Programmable Gate Array), eine elektronische Schaltung, einen Prozessor (gemeinsam genutzt, dediziert oder eine Gruppe), eine Grafikverarbeitungseinheit (GPU - Graphics Processing Unit) und/oder Arbeitsspeicher (gemeinsam genutzt, dediziert oder eine Gruppe), die/das/der ein oder mehrere Software- oder Firmware-Programme ausführt, welche Maschinenanweisungen (erzeugt aus Assembler-Anweisungen oder zusammengestellt aus Sprachanweisungen einer höheren Ebene) aufweisen, eine kombinatorische Logikschaltung und/oder andere geeignete Komponenten, welche die beschriebene Funktionalität bereitstellen, beziehen, ein Teil davon sein oder diese beinhalten. Wie hierin verwendet, kann der Begriff „Modul“ Logik (einschließlich Betriebssysteme oder Anwendungsanweisungen, Daten usw.), die zumindest teilweise in Schaltungen betriebsfähig ist, beinhalten. Die Schaltungen können das Modul implementieren, um das Modul zum Durchführen von hierin beschriebenen Operationen zu veranlassen. Wie hierin verwendet, kann der Begriff „Arbeitsspeicher“ ein oder mehrere Hardware-Geräte zum Speichern von Daten darstellen, einschließlich Direktzugriffsspeicher (RAM - Random Access Memory), magnetischem RAM, Kernspeicher, Nur-Lese-Speicher (ROM - Read Only Memory), Magnetplatten-Speichermedien, optischen Speichermedien, Flashspeichergeräten und/oder anderen maschinenlesbaren Medien zum Speichern von Daten. Der Begriff „computerlesbares Medium“ kann Arbeitsspeicher, tragbare oder feststehende Speichergeräte, optische Speichergeräte, drahtlose Kanäle und verschiedene andere Medien, die zum Speichern, Enthalten oder Tragen einer (von) Anweisung(en) und/oder Daten in der Lage sind, beinhalten, ist jedoch nicht darauf beschränkt.
Wie hierin verwendet, kann der Begriff „Computergerät“ jegliches physisches Hardware-Gerät beschreiben, das zum sequentiellen und automatischen Ausführen einer Sequenz arithmetischer oder logischer Operationen in der Lage ist und zum Aufzeichnen/Speichern von Daten auf einem maschinenlesbaren Medium und Senden und Empfangen von Daten von einem oder mehreren anderen Geräten in einem Kommunikationsnetzwerk ausgestattet ist. Ein Computergerät kann als synonym zu einem Computer, einer Berechnungsplattform, einem Berechnungsgerät usw. betrachtet werden und kann im Folgenden gelegentlich derart bezeichnet sein. Der Begriff „Computersystem“ kann jegliche Art miteinander verbundener elektronischer Geräte, Computergeräte oder Komponenten davon beinhalten, wie z.B. Mobiltelefone oder Smartphones, Tablet-PCs, tragbare Berechnungsgeräte, autonome Sensoren, Laptops, Desktop-PCs, Videospielkonsolen, digitale Media-Player, Handheld-Nachrichtenübermittlungsgeräte, PDAs, E-Book-Reader, Augmented-Reality-Geräte, USB (Universal Serial Bus) -Hubs, KVM (Keyboard Video Mouse) - Schalter/-Hubs, Dockingstationen, Port-Replikatoren, Server-Computergeräte (z.B. eigenständig, Rack-montiert, Blade usw.), Cloud-Computing-Dienste/Systeme, Netzwerkelemente und/oder jegliche anderen ähnlichen elektronischen Geräte. Außerdem kann sich der Begriff „Computersystem“ und/oder „System“ auf verschiedene Komponenten eines Computers beziehen, die kommunikativ miteinander gekoppelt sind. Des Weiteren kann sich der Begriff „Computersystem“ und/oder „System“ auf mehrere Computergeräte und/oder mehrere Berechnungssysteme beziehen, die kommunikativ miteinander gekoppelt sind und zum gemeinsamen Nutzen von Berechnungs- und/oder Vernetzungsressourcen konfiguriert sind.
Wie hierin verwendet, kann sich der Begriff „Netzwerkelement“ auf ein oder mehrere Computergeräte oder ein oder mehrere elektronische Geräte beziehen, das/die ein oder mehrere verdrahtete oder drahtlose Netzwerke bereitstellt/bereitstellen (oder Zugang dazu bereitstellen). Ein „Netzwerkelement“ kann als synonym zu einem vernetzten Computer, Vernetzungshardware, Netzwerkausrüstung, einem Zugangspunkt, einem Router, einem Schalter, einem Hub, einer Brücke, einem Gateway, einer Basisstation, einem Kernnetzwerkelement, einem Server und/oder einem anderen ähnlichen Gerät betrachtet werden und/oder derart bezeichnet sein. Der Begriff „Netzwerkelement“ kann Ausrüstung beschreiben, die Funk-Basisband-Funktionen für die Daten- und/oder Sprachkonnektivität zwischen einem Netzwerkelement und einem oder mehreren Benutzern bereitstellt.
Wie hierin verwendet, kann sich der Begriff „Berechnungsressource“, „Hardware-Ressource“, „Ressource“ usw. auf ein physisches oder virtuelles Gerät, eine physische oder virtuelle Komponente innerhalb einer Berechnungsumgebung und/oder eine physische oder virtuelle Komponente innerhalb eines bestimmten Gerätes beziehen, wie z.B. Computergeräte, mechanische Geräte, Speicherplatz, Prozessor/CPU-Zeit und/oder Prozessor/CPU-Nutzung, Hardware-Zeit oder - Nutzung, elektrische Leistung, Eingabe/Ausgabe-Operationen, Anschlüsse oder Netzsteckdosen, Kanal-/Verknüpfungszuweisung, Durchsatz und/oder dergleichen. Wie hierin verwendet, kann sich der Begriff „Netzwerkressource“ auf Berechnungsressourcen beziehen, auf die durch Computergeräte über ein Kommunikationsnetzwerk zugegriffen werden kann.
Das Internet der Dinge (IoT - Internet of Things) ist ein Konzept, bei welchem eine große Zahl von Berechnungsgeräten miteinander und mit dem Internet verbunden sind, um Funktionalität und Datenerfassung, gelegentlich auf niedrigem Niveau, bereitzustellen. Wie hierin verwendet, kann ein IoT-Gerät jedoch auch ein semiautonomes oder autonomes Gerät beinhalten, das eine Funktion durchführt, wie z.B. ein CA/AD-Fahrzeug und/oder ein CA/AD-System, das in das CA/AD-Fahrzeug integriert ist und/oder dieses anderweitig unterstützt, einschließlich zum Durchführen von Abtastung oder Steuerung, unter anderen Funktionen, in Kommunikation mit anderen IoT-Geräten und einem breiteren Netzwerk, wie z.B. dem Internet. Gelegentlich sind IoT-Geräte in Arbeitsspeicher, Größe oder Funktionalität beschränkt, wodurch der Einsatz größerer Zahlen zu ähnlichen Kosten gegenüber kleineren Zahlen von größeren Geräten gestattet wird. Jedoch kann ein IoT-Gerät auch ein Smartphone, ein Laptop, ein Tablet oder ein PC oder ein anderes größeres Gerät sein, wie z.B. ein CA/AD-Fahrzeug, wie oben angegeben. Ferner kann ein IoT-Gerät ein virtuelles Gerät sein, wie z.B. eine Anwendung auf einem Smartphone oder einem anderen Berechnungsgerät. IoT-Geräte können IoT-Gateways beinhalten, die zum Koppeln von IoT-Geräten mit anderen IoT-Geräten und mit Cloud-Anwendungen zur Datenspeicherung, Prozesssteuerung und dergleichen verwendet werden.
Netzwerke von IoT-Geräten können kommerzielle und Heimautomationsgeräte beinhalten, wie z.B. Wasserverteilungssysteme, Stromverteilungssysteme, Rohrleitungssteuersysteme, Anlagensteuersysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Auf die IoT-Geräte kann über entfernte Computer, Server und andere Systeme zugegriffen werden, zum Beispiel zur Steuerung von Systemen oder zum Zugriff auf Daten.
Das zukünftige Wachstum des Internets kann sehr große Zahlen von IoT-Geräten beinhalten. Dementsprechend beschäftigt sich, wie hierin beschrieben, eine Reihe von Innovationen für das zukünftige Internet mit dem Bedarf, dass all diese Schichten ungehindert wachsen, mit der Feststellung und dem Zugänglichmachen angeschlossener Ressourcen und der Unterstützung der Fähigkeit, angeschlossene Ressourcen zu verbergen und aufzugliedern. Es kann jegliche Zahl von Netzwerkprotokollen und Kommunikationsstandards zum Einsatz kommen, wobei jedes Protokoll und jeder Standard dazu ausgelegt ist, sich mit spezifischen Zielen zu beschäftigen. Ferner sind die Protokolle Teil des Gefüges, das durch den Menschen zugängliche Dienste unterstützt, welche ungeachtet von Ort, Zeit oder Raum arbeiten. Zu den Innovationen zählen Dienstbereitstellung und die damit im Zusammenhang stehende Infrastruktur, wie z.B. Hardware und Software. Die Dienste können in Übereinstimmung mit den Bedingungen der Dienstqualität (QoS - Quality of Service), die in Dienstebenen- und Dienstbereitstellungsvereinbarungen spezifiziert sind, bereitgestellt werden. Die Verwendung von IoT-Geräten und -Netzwerken stellt eine Reihe neuer Herausforderungen in einem heterogenen Netzwerk der Konnektivität, welches eine Kombination aus verdrahteten und drahtlosen Technologien umfasst, wie in 1 und 2 gezeigt, dar.
1 ist eine vereinfachte Zeichnung, die Zwischenverbindungen, die zwischen dem Internet 100 und IoT-Netzwerken vorliegen können, in Übereinstimmung mit verschiedenen Ausführungsformen zeigt. Die Zwischenverbindungen können kleinere Netzwerke 102, bis hinunter zum dem einzelnen IoT-Gerät 104, an das Faser-Backbone 106 des Internets 100 koppeln. Zur Vereinfachung der Zeichnung ist nicht jedes Gerät 104 oder jedes andere Objekt beschriftet.
In 1 sind übergeordnete Anbieter, welche auch als Tier-1-Anbieter 108 bezeichnet sein können, durch das Faser-Backbone des Internets an andere Anbieter, wie z.B. sekundäre oder Tier-2-Anbieter 110, gekoppelt. In einem Beispiel kann ein Tier-2-Anbieter 110 an einen Turm 112 eines LTE-Mobilfunknetzes gekoppelt sein, zum Beispiel durch weitere Faserverknüpfungen, durch Mikrowellenkommunikation 114 oder durch andere Kommunikationstechnologien. Der Turm 112 kann über eine LTE-Kommunikationsverknüpfung 116, zum Beispiel über einen zentralen Knoten 118, an ein Mesh-Netzwerk, welches die IoT-Geräte 104 beinhaltet, gekoppelt sein. Die Kommunikation zwischen den einzelnen IoT-Geräten 104 kann auch auf den LTE-Kommunikationsverknüpfungen 116 basieren. In einem weiteren Beispiel kann ein Hochgeschwindigkeits-Uplink 120 einen Tier-2-Anbieter 110 an ein Gateway (GW) 120 koppeln. Eine Reihe von IoT-Geräten 104 kann mit dem GW 120 und über das GW 120, zum Beispiel über die BLE-Verknüpfungen 122, miteinander kommunizieren.
Das Faser-Backbone 106 kann untere Ebenen von Dienstanbietern, wie z.B. die Tier-3-Anbieter 124, an das Internet koppeln. Ein Tier-3-Anbieter 124 kann als ein allgemeiner Internetdienstanbieter (ISP - Internet Service Provider) betrachtet werden, welcher zum Beispiel Zugang zu dem Faser-Backbone 110 von einem Tier-2-Anbieter 110 erwirbt und Zugang zu einem GW eines Unternehmens 126 und anderen Kunden bereitstellt. Von dem GW eines Unternehmens 126 kann ein drahtloses lokale Netz (WLAN - Wireless Local Area Network) zum Kommunizieren mit den IoT-Geräten 104 über die Wi-Fi®-Verknüpfungen 128 verwendet werden. Eine Wi-Fi-Verknüpfung 128 kann auch zum Koppeln an ein LPWA (Low Power Wide Area) -GW 130 verwendet werden, welches über die LPWA-Verknüpfungen 132, die zum Beispiel mit der LoRaWan-Spezifikation veröffentlicht von der LoRa-Alliance kompatibel sind, mit den IoT-Geräten 104 kommunizieren kann.
Der Tier-3-Anbieter 124 kann auch Zugang zu einem Mesh-Netzwerk 134 über ein Koordinator-Gerät 136 bereitstellen, welches unter Verwendung jeglicher Zahl von Kommunikationsverknüpfungen, wie z.B. eine LTE-Mobilfunkverknüpfung, eine LPWA-Verknüpfung oder eine Verknüpfung 138 basierend auf dem IEEE 802.15.4-Standard, wie z.B. Zigbee®, mit dem Tier-3-Anbieter 124 kommuniziert. Andere Koordinator-Geräte 136 können eine Kette von Verknüpfungen bereitstellen, die einen Cluster-Baum verknüpfter Geräte bildet.
Die IoT-Geräte 104 können j egliches/r Objekt, Gerät, Sensor oder „Ding“ sein, das/der in Hardware- und/oder Software-Komponenten eingebettet ist, die das/den Objekt, Gerät, Sensor oder „Ding“, das/der zum Aufnehmen und/oder Aufzeichnen von Daten im Zusammenhang mit einem Ereignis in der Lage ist und zum Kommunizieren derartiger Daten mit einem oder mehreren anderen Geräten über ein Netzwerk in der Lage ist, mit wenig oder ganz ohne Benutzereingriff befähigen. Zum Beispiel können die IoT-Geräte 104 in verschiedenen Ausführungsformen abiotische Geräte sein, wie z.B. autonome Sensoren, Messuhren, Messgeräte, Bildaufnahmegeräte, Mikrofone, MTC (Machine-Type Communication - Maschinenkommunikation) -Geräte, Maschine-zu-Maschine (M2M) -Geräte, lichtemittierende Geräte, audioemittierende Geräte, Audio- und/oder Videoabspielgeräte, elektromechanische Geräte (z.B. Schalter, Aktor usw.) und dergleichen. In einigen Ausführungsformen können die IoT-Geräte 104 biotische Geräte sein, wie z.B. Überwachungsimplantate, Biosensoren, Biochips und dergleichen. In anderen Ausführungsformen kann ein IoT-Gerät 104 ein Computergerät sein, das in einem Computersystem eingebettet und mit Kommunikationsschaltungen des Computersystems gekoppelt ist. In derartigen Ausführungsformen kann das IoT-Gerät 104 ein Ein-Chip-System (SoC - System on Chip), eine universelle integrierte Schaltungskarte (UICC - Universal Integrated Circuitry Card), eine eingebettete UICC (eUICC - embedded UICC) und dergleichen sein und das Computersystem kann eine Mobilstation (z.B. ein Smartphone) oder ein Endgerät, ein Laptop, ein tragbares Gerät (z.B. eine Smart-Watch, ein Fitness-Tracker usw.), ein „intelligentes“ Gerät (z.B. ein Fernsehgerät, ein Kühlschrank, ein Sicherheitssystem usw.) und dergleichen sein.
Jedes der IoT-Geräte 104 kann ein oder mehrere Speichergeräte und einen oder mehrere Prozessoren zum Aufnehmen und Speichern/Aufzeichnen von Daten beinhalten. Jedes der IoT-Geräte 104 kann angemessene Kommunikationsschaltungen (z.B. Sendeempfänger, Modem, Antennenelemente usw.) zum Kommunizieren (z.B. Senden und Empfangen) aufgenommener und gespeicherter/aufgezeichneter Daten beinhalten. Ferner kann jedes IoT-Gerät 104 auch andere Sendeempfänger zur Kommunikation unter Verwendung zusätzlicher Protokolle und Frequenzen beinhalten. Gemäß verschiedenen Ausführungsformen können die IoT-Geräte 104 mit Informationen (hierin z.B. als „Modemprofile“ bezeichnet) zum Konfigurieren konfigurierbarer Kommunikationsschaltungen zum Durchführen von Kommunikation in einer entsprechenden Kommunikationsumgebung ausgestattet sein. Dies kann es den IoT-Geräten 104 gestatten, unter Verwendung mehrerer drahtloser Kommunikationsprotokolle zu kommunizieren, ohne dass ein IoT-Gerät 104 separate Hardware-Kommunikationsmodule für jedes drahtlose Kommunikationsprotokoll beinhalten muss. Bei den drahtlosen Kommunikationsprotokollen kann es sich um jeglichen geeigneten Satz von standardisierten Regeln oder Anweisungen handeln, die durch die IoT-Geräte 104 zum Kommunizieren mit anderen Geräten implementiert werden, einschließlich Anweisungen zum Zusammenfügen/Zerlegen von Daten, Anweisungen zum Modulieren/Demodulieren von Signalen, Anweisungen zum Implementieren von Protokollstapeln und dergleichen. Zum Beispiel können die IoT-Geräte 104 Kommunikationsschaltungen beinhalten, die zum Kommunizieren in Übereinstimmung mit einem oder mehreren P2P (Person-to-Person) oder PAN (Personal Area Network) -Protokollen (z.B. auf IEEE 802.15.4 basierende Protokolle, einschließlich ZigBee, 6LoWPAN (IPv6 over Low power Wireless Personal Area Netzwerke), WirelessHART, MiWi, Thread usw.; WiFi-Direct; Bluetooth/BLE-Protokolle; ANT-Protokolle; Z-Wave; LTE D2D oder ProSe; UPnP und dergleichen) konfigurierbar sind und zum Kommunizieren unter Verwendung von einem oder mehreren LAN- und/oder WLAN-Protokollen (z.B. Wi-Fi-basierte Protokolle oder IEEE 802.11-Protokolle, wie z.B. IEEE 802.16-Protokolle); einem oder mehreren Mobilfunk-Kommunikationsprotokollen (z.B. LTE/LTE-A, UMTS, GSM, EDGE, Wi-MAX usw.) und dergleichen konfigurierbar sind. In Ausführungsformen können eines oder mehrere aus dem Turm 112, dem GW 120, 126 und 130, dem Koordinator-Gerät 136 und so weiter auch in die hierin beschriebenen Ausführungsformen eingeschlossen sein, insbesondere unter Bezugnahme auf 5-11.
Die Technologien und Netzwerke können das exponentielle Wachstum von Geräten und Netzwerken ermöglichen. Mit dem Wachstum der Technologien kann das Netzwerk für Selbstmanagement, funktionale Weiterentwicklung und Zusammenarbeit entwickelt werden, ohne einen direkten Eingriff durch den Menschen zu erfordern. Somit ermöglichen die Technologien Netzwerken ein Funktionieren ohne zentralisierte gesteuerte Systeme. Die hierin beschriebenen Technologien können das Netzwerkmanagement und Operationsfunktionen über die aktuellen Fähigkeiten hinaus automatisieren.
2 veranschaulicht eine beispielhafte Domänentopologie 200, die für eine Reihe von IoT-Netzwerken, die über die Backbone-Verknüpfungen 202 an die GWs 204 gekoppelt sind, verwendet werden kann, in Übereinstimmung mit verschiedenen Ausführungsformen. Gleich nummerierte Gegenstände sind wie in Bezug auf 1 beschrieben. Ferner ist zur Vereinfachung der Zeichnung nicht jedes Gerät 104 oder jede Kommunikationsverknüpfung 116, 122, 128 oder 132 beschriftet. Die Backbone-Verknüpfungen 202 können jegliche Zahl verdrahteter oder drahtloser Technologien beinhalten und können Teil eines LAN (Local Area Network), eines WAN (Wide Area Network) oder des Internets sein. Ähnlich wie bei 1 können in Ausführungsformen ein oder mehrere aus den IoT-Geräten 104, dem GW 204 und so weiter in hierin beschriebene Ausführungsformen eingeschlossen sein, insbesondere unter Bezugnahme auf 5-13.
Die Netzwerktopologie 200 kann jegliche Zahl von Arten von IoT-Netzwerken beinhalten, wie z.B. ein Mesh-Netzwerk 206 unter Verwendung der BLE-Verknüpfungen 122. Zu anderen IoT-Netzwerken, die vorliegen können, zählen ein WLAN-Netzwerk 208, ein Mobilfunknetz 210 und ein LPWA-Netzwerk 212. Jedes dieser IoT-Netzwerke kann Möglichkeiten für neue Entwicklungen, wie hierin beschrieben, bereitstellen. Zum Beispiel kann die Kommunikation zwischen den IoT-Geräten 104, wie z.B. über die Backbone-Verknüpfungen 202, durch ein dezentralisiertes System für Authentifizierung, Autorisierung und Abrechnung (AAA - Authentication, Authorization and Accounting) geschützt sein. In einem dezentralisierten AAA-System können verteilte Systeme für Bezahlung, Gutschrift, Prüfung, Autorisierung und Authentifizierung über eine miteinander verbundene heterogene Infrastruktur hinweg implementiert sein. Dies gestattet es Systemen und Netzwerken, sich in Richtung autonomer Operationen zu bewegen.
Bei diesen Arten von autonomen Operationen können Maschinen Verträge für Personal abschließen und Partnerschaften mit anderen Maschinennetzwerken aushandeln. Dies kann das Erreichen gemeinsamer Ziele und einer ausgeglichenen Dienstbereitstellung gegenüber umrissenen, geplanten Dienstgütevereinbarungen gestatten sowie Lösungen erreichen, die Ablesung, Messungen, Rückverfolgung und Nachverfolgung bereitstellen. Die Erstellung neuer Lieferkettenstrukturen und -verfahren kann das Erstellen einer Vielzahl von Diensten ermöglichen, die hinsichtlich ihres Wertes untersucht und ohne jeglichen menschlichen Eingriff zusammengelegt werden.
Die IoT-Netzwerke können ferner durch die Integration von Abtasttechnologien, wie z.B. Ton, Licht, elektronischem Verkehr, Gesichts- und Mustererkennung, Geruch oder Vibration, in die autonomen Organisationen verbessert werden. Die Integration von sensorischen Systemen kann die systematische und autonome Kommunikation und Koordination der Dienstbereitstellung gegenüber einer auf vertraglich vereinbarten Dienstzielen, Orchestrierung und Dienstqualität (QoS - Quality of Service) basierten Zusammenarbeit und Verschmelzung von Ressourcen gestatten.
Das Mesh-Netzwerk 206 kann durch Systeme verbessert werden, die Inline-Daten-zu-Information-Transformationen durchführen. Zum Beispiel können sich selbst bildende Ketten von Verarbeitungsressourcen, die ein Mehrfachverbindungsnetzwerk umfassen, die Transformation von Rohdaten zu Informationen in einer effizienten Art und Weise verteilen, wie auch die Fähigkeit zur Differenzierung zwischen Werten und Ressourcen und dem jeweiligen dazugehörigen Management. Des Weiteren können geeignete Infrastrukturkomponenten und ressourcenbasierte Vertrauens- und Dienstindizes eingefügt werden, um die Datenintegrität, -qualität und -sicherheit zu verbessern und eine Metrik der Datenzuverlässigkeit bereitzustellen.
Das WLAN-Netzwerk 208 kann Systeme einsetzen, die eine Standardumwandlung durchführen, um Mehrfachstandard-Konnektivität bereitzustellen, wodurch den IoT-Geräten 104 die Verwendung unterschiedlicher Protokolle zum Kommunizieren ermöglicht wird. Weitere Systeme können nahtlose Interkonnektivität über eine Mehrfachstandard-Infrastruktur, die sichtbare Internet-Ressourcen und verborgene Internet-Ressourcen umfasst, hinweg bereitstellen.
Die Kommunikation in dem Mobilfunknetz 210 kann durch Systeme verbessert werden, die Daten auslagern, die Kommunikation zu entfernteren Geräten erweitern oder beides. Das LPWA-Netzwerk 212 kann Systeme beinhalten, die Nicht-IP (Internet-Protokoll) -zu-IP-Zwischenverbindungen, -Adressierung und -Routing durchführen.
3 veranschaulicht ein beispielhaftes Cloud-Computing-Netzwerk oder eine Cloud 302 in Kommunikation mit einer Reihe von IoT (Internet of Things) - Geräten in Übereinstimmung mit verschiedenen Ausführungsformen. In Ausführungsformen können zu den IoT-Geräten ein oder mehrere Systeme oder Fahrzeuge für computergestütztes oder autonomes Fahren (CA/AD - Computer-Assisted/Autonomous Driving) zählen. Die Cloud 302 kann das Internet, ein oder mehrere Mobilfunknetze, ein LAN (Local Area Network) oder ein WAN (Wide Area Network), einschließlich proprietärer und/oder Unternehmensnetzwerke für ein Unternehmen oder eine Organisation, oder Kombinationen davon darstellen. Komponenten, die für ein derartiges Kommunikationssystem verwendet werden, können zumindest teilweise von der Art des ausgewählten Netzwerks und/oder der ausgewählten Umgebung abhängen. Protokolle und Komponenten für das Kommunizieren über derartige Netzwerke sind gut bekannt und werden hierin nicht im Detail diskutiert. Jedoch sollte verstanden werden, dass die Cloud 302 mit einem Netzwerkbetreiber assoziiert sein kann, der Ausrüstung oder andere Elemente besitzt oder steuert, die zum Bereitstellen von netzwerkbezogenen Diensten notwendig sind, wie z.B. eine oder mehrere Basisstationen oder Zugangspunkte und ein oder mehrere Server zum Routen von digitalen Daten oder Telefonanrufen (zum Beispiel ein Kernnetzwerk oder Backbone-Netzwerk).
Die IoT-Geräte in 3 können die gleichen oder ähnliche wie die IoT-Geräte 104 sein, die in Bezug auf 1-2 diskutiert wurden. Zu den IoT-Geräten kann jegliche Zahl von unterschiedlichen Gerätearten, gruppiert in verschiedenen Kombinationen, zählen, wie z.B. die IoT-Gruppe 306, die IoT-Geräte beinhalten kann, die einen oder mehrere Dienste für einen bestimmten Benutzer, Kunden, Organisationen usw. bereitstellen. Ein Dienstanbieter kann die IoT-Geräte in der IoT-Gruppe 306 für einen bestimmten Bereich (z.B. ein Standort, Gebäude usw.) einsetzen, um den einen oder die mehreren Dienste bereitzustellen. In einem Beispiel kann die IoT-Gruppe 306 eine Verkehrssteuerungsgruppe sein, wobei die IoT-Geräte in der IoT-Gruppe 306 Ampeln, Verkehrsflussüberwachungsgeräte, Kameras, Wettersensoren und dergleichen beinhalten können, um Verkehrssteuerungs- und Verkehrsanalysedienste für eine bestimmte Gemeinde oder eine andere ähnliche Instanz bereitzustellen. Ähnlich wie bei 1-2 können in Ausführungsformen ein oder mehrere der IoT-Geräte 314-324, das GW 310 und so weiter in die hierin beschriebenen verschiedenen Ausführungsformen integriert sein, insbesondere unter Bezugnahme auf 5-9. Zum Beispiel kann die IoT-Gruppe 306, oder jegliche der hierin diskutierten IoT-Gruppen, in einigen Ausführungsformen eine Hosting-Plattform beinhalten, die ein oder mehrere CA/AD (Computer-Assisted/Autonomous Driving) -Fahrzeuge und/oder Arbeitslastverteilungsdienste aufweist, welche unten in Bezug auf 5-9 diskutiert werden.
Die IoT-Gruppe 306 oder andere Untergruppen können über drahtlose Verknüpfungen 308, wie z.B. LPWA-Verknüpfungen und dergleichen, in Kommunikation mit der Cloud 302 stehen. Ferner kann ein verdrahtetes oder drahtloses Unternetzwerk 312 den IoT-Geräten das Kommunizieren miteinander gestatten, wie z.B. über ein lokales Netzwerk, ein drahtloses lokales Netzwerk und dergleichen. Die IoT-Geräte können auch ein anderes Gerät, wie z.B. ein GW 310, zum Kommunizieren mit der Cloud 302 verwenden. Zu anderen Gruppen von IoT-Geräten können, unter vielen anderen, entfernte Wetterstationen 314, lokale Informationsterminals 316, Alarmsysteme 318, Geldautomaten 320, Alarmtafeln 322 oder sich bewegende Fahrzeuge, wie z.B. Rettungsfahrzeuge 324 oder andere Fahrzeuge 326, zählen. Jedes dieser IoT-Geräte kann in Kommunikation mit anderen IoT-Geräten, mit den Servern 304 oder mit beiden stehen.
Wie in 3 zu sehen ist, kann eine große Zahl von IoT-Geräten über die Cloud 302 kommunizieren. Dies kann es gestatten, dass unterschiedliche IoT-Geräte selbständig Informationen anfordern oder an andere Geräte bereitstellen. Zum Beispiel kann die IoT-Gruppe 306 eine aktuelle Wettervorhersage von einer Gruppe von entfernten Wetterstationen 314 anfordern, welche die Vorhersage ohne menschliches Zutun bereitstellen können. Ferner kann ein Rettungsfahrzeug 324 durch einen Geldautomaten 320 alarmiert werden, dass gerade ein Einbruch stattfindet. Wenn sich das Rettungsfahrzeug 324 dem Geldautomaten 320 nähert, kann es auf die Verkehrssteuerungsgruppe 306 zugreifen, um freie Durchfahrt zum Standort anzufordern, zum Beispiel indem Ampeln auf Rot geschaltet werden, um Querverkehr an einer Kreuzung ausreichend früh zu blockieren, damit das Rettungsfahrzeug 324 ungehinderte Durchfahrt an der Kreuzung hat.
In einem weiteren Beispiel kann die IoT-Gruppe 306 eine industrielle Steuerungsgruppe (auch bezeichnet als eine „verbundene Fabrik“, eine „Industrie 4.0“-Gruppe und dergleichen) sein, wobei die IoT-Geräte in der IoT-Gruppe 306 Maschinen oder Geräte mit eingebetteten IoT-Geräten, Funkfrequenzidentifikation (RFID - Radiofrequency Identification) -Lesegeräte, Kameras, Client-Computergeräte innerhalb einer Herstellungsanlage und dergleichen beinhalten können, um Produktionssteuerung, selbstoptimierte oder dezentralisierte Aufgabenmanagementdienste, Analysedienste usw. für einen bestimmten Hersteller oder Fabrikbetreiber bereitzustellen. In diesem Beispiel kann die IoT-Gruppe 306 über das GW 310 und die Cloud 302 mit den Servern 304 kommunizieren, um aufgenommene Daten bereitzustellen, welche verwendet werden können, um Leistungsüberwachung und -analyse an den Hersteller oder Fabrikbetreiber bereitzustellen. Außerdem können die IoT-Geräte in der IoT-Gruppe 306 untereinander und/oder mit anderen IoT-Geräten anderer IoT-Gruppen kommunizieren, um selbst Entscheidungen zu treffen und ihre Aufgaben so eigenständig wie möglich durchzuführen.
Cluster von IoT-Geräten, wie z.B. die durch 3 gezeigten IoT-Gruppen, können zum Kommunizieren mit anderen IoT-Geräten sowie mit der Cloud 302 ausgestattet sein. Dies kann den IoT-Geräten das Bilden eines Ad-hoc-Netzwerks zwischen den Geräten gestatten, wodurch ihnen gestattet wird, als ein einzelnes Gerät zu funktionieren, welches als ein Fog-Gerät bezeichnet werden kann. Dies wird in Bezug auf 4 weiter diskutiert.
4 veranschaulicht eine Anordnung 400 eines Cloud-Computing-Netzwerks oder einer Cloud 302 in Kommunikation mit einem Mesh-Netzwerk von IoT-Geräten, welche als ein Fog-Gerät 402 bezeichnet werden können, das am Rand der Cloud 302 arbeitet, in Übereinstimmung mit verschiedenen Ausführungsformen. Gleich nummerierte Gegenstände sind wie in Bezug auf 1-3 beschrieben. In diesem Beispiel ist das Fog-Gerät 402 eine Gruppe von IoT-Geräten an einer Kreuzung. Das Fog-Gerät 402 kann in Übereinstimmung mit Spezifikationen etabliert sein, die, unter anderem, durch das OpenFog Consortium (OFC) und die Open Connectivity Foundation™ (OCF) veröffentlicht wurden.
Daten können aufgenommen, gespeichert/aufgezeichnet und zwischen den IoT-Geräten 404 kommuniziert werden. Eine Analyse der Verkehrsfluss- und Verkehrssteuerungsschemata kann durch die Aggregatoren 406 implementiert werden, die über ein Mesh-Netzwerk in Kommunikation mit den IoT-Geräten 404 und miteinander stehen. Über die GWs 310, die über das Mesh-Netzwerk in Kommunikation mit den IoT-Geräten 404 und den Aggregatoren 406 stehen, können Daten in die Cloud 302 hochgeladen und Befehle aus der Cloud 302 empfangen werden. Ähnlich wie bei 1-3 können in Ausführungsformen ein oder mehrere der IoT-Geräte 404, Aggregatoren 406 und so weiter in die hierin beschriebenen verschiedenen Ausführungsformen integriert sein, insbesondere unter Bezugnahme auf 5-9. Zum Beispiel kann das Fog-Gerät 402, oder jegliche der hierin diskutierten Gruppierung von Geräten, in einigen Ausführungsformen das/die CA/AD-Fahrzeug(e) oder CA/AD-Systeme, einen entfernten Arbeitslastverteilungsserver und/oder ein oder mehrere Geräte beinhalten, die unten in Bezug auf 5-9 diskutiert sind.
In dem Fog-Gerät 402 kann jegliche Zahl von Kommunikationsverknüpfungen verwendet werden. Verknüpfungen mit kürzerer Reichweite 408, die zum Beispiel mit IEEE 802.15.4 kompatibel sind, können lokale Kommunikation zwischen IoT-Geräten bereitstellen, die sich nahe zueinander oder zu anderen Geräten befinden. Verknüpfungen mit größerer Reichweite 410, die zum Beispiel mit LPWA-Standards kompatibel sind, können Kommunikation zwischen den IoT-Geräten und den GWs 310 bereitstellen. Zur Vereinfachung des Diagramms wurde nicht jede Kommunikationsverknüpfung 408 oder 410 mit einer Referenznummer beschriftet.
Das Fog-Gerät 402 kann als ein massiv zusammenhängendes Netzwerk angesehen werden, wobei eine Reihe von IoT-Geräten zum Beispiel durch die Kommunikationsverknüpfungen 408 und 410 in Kommunikation miteinander stehen. Das Netzwerk kann unter Verwendung der OIC (Open Interconnect Consortium) -Standardspezifikation 1.0, veröffentlicht durch die Open Connectivity Foundation™ (OCF) am 23. Dezember 2015, etabliert werden. Dieser Standard gestattet Geräten das gegenseitige Erkennen und den Aufbau von Kommunikation für Zwischenverbindungen. Es können auch andere Zwischenverbindungsprotokolle verwendet werden, einschließlich zum Beispiel des AllJoyn-Protokolls von der AllSeen-Allianz, des OLSR (Optimized Link State Routing) -Protokolls oder B.A.T.M.A.N (Better Approach To Mobile Ad-hoc Networking), unter vielen anderen.
Die Kommunikation von jeglichem IoT-Gerät kann entlang des geeignetsten Pfades zwischen jeglichen der IoT-Geräte geführt werden, um die GWs 310 zu erreichen. In diesen Netzwerken kann die Zahl der Zwischenverbindungen eine wesentliche Redundanz bereitstellen, wodurch eine Aufrechterhaltung der Kommunikation gestattet wird, selbst beim Verlust einer Reihe von IoT-Geräten.
Möglicherweise sind nicht alle der IoT-Geräte permanente Mitglieder des Fog-Gerätes 402. In dem Beispiel in der Zeichnung 400 sind drei transiente IoT-Geräte dem Fog-Gerät 402 beigetreten, ein erstes mobiles Gerät 412, ein zweites mobiles Gerät 414 und ein drittes mobiles Gerät 416. Das Fog-Gerät 402 kann Clients in der Cloud 302, wie z.B. 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ät 402 ohne das Identifizieren jeglichen spezifischen IoT-Gerätes 404 innerhalb des Fog-Gerätes 402 stattfinden. Dementsprechend können, wenn jegliches IoT-Gerät 404 ausfällt, andere IoT-Geräte 404 in der Lage sein, eine Ressource festzustellen und zu steuern. Zum Beispiel können die IoT-Geräte 404 verdrahtet sein, um es jeglichem einen der IoT-Geräte 404 zu gestatten, Messungen, Eingaben, Ausgaben usw. für die anderen IoT-Geräte 404 zu steuern. Die Aggregatoren 406 können auch Redundanz in der Steuerung der IoT-Geräte 404 und anderer Funktionen des Fog-Gerätes 402 bereitstellen.
In einigen Beispielen können die IoT-Geräte mit Hilfe eines imperativen Programmierstils konfiguriert sein, wobei z.B. jedes IoT-Gerät eine spezifische Funktion und spezifische Kommunikationspartner aufweist. Jedoch können die IoT-Geräte, welche das Fog-Gerät 402 bilden, auch in einem deklarativen Programmierstil konfiguriert sein, welcher den IoT-Geräten das Neukonfigurieren ihrer Operationen und Kommunikation gestattet, wie z.B. das Bestimmen benötigter Ressourcen als Reaktion auf Bedingungen, Anfragen und Geräteausfälle. Dies kann durchgeführt werden, wenn transiente IoT-Geräte, wie z.B. die Geräte 412, 414, 416, dem Fog-Gerät 402 beitreten. Wenn transiente oder mobile IoT-Geräte in den Fog 402 eintreten oder diesen verlassen, kann das Fog-Gerät 402 sich selbst derart neu konfigurieren, dass es diese Geräte beinhaltet. Dies kann durchgeführt werden, indem eine temporäre Gruppe der Geräte 412 und 414 und des dritten mobilen Gerätes 416 gebildet wird, um die IoT-Geräte 404 zu steuern oder anderweitig damit zu kommunizieren. Wenn eines oder beide der Geräte 412, 414 autonom ist/sind, kann die temporäre Gruppe Anweisungen an die Geräte 412, 414 bereitstellen. Wenn die transienten Geräte 412, 414 und 416 die unmittelbare Umgebung des Fog-Gerätes 402 verlassen, kann es sich selbst neukonfigurieren, um diese IoT-Geräte aus dem Netzwerk zu eliminieren. Das Fog-Gerät 402 kann sich auch selbst in Funktionseinheiten aufteilen, wie z.B. die IoT-Geräte 404 und andere IoT-Geräte in der Nähe zu einem bestimmten Bereich oder einem geografischen Merkmal oder andere IoT-Geräte, die eine bestimmte Funktion durchführen. Diese Art der Kombination kann die Bildung größerer IoT-Konstrukte unter Verwendung von Ressourcen aus dem Fog-Gerät 402 ermöglichen.
Wie durch das Fog-Gerät 402 veranschaulicht, ist die organische Entwicklung von IoT-Netzwerken von zentraler Bedeutung für die Maximierung des Nutzens, der Verfügbarkeit und der Widerstandsfähigkeit von IoT-Implementierungen. Ferner gibt das Beispiel die Nützlichkeit von Strategien zur Verbesserung des Vertrauens und damit der Sicherheit an. Die lokale Identifizierung von Geräten kann bei Implementierungen wichtig sein, da die Dezentralisierung der Identität sicherstellt, dass keine zentrale Autorität ausgenutzt werden kann, um eine Imitation von Objekten zu gestatten, die möglicherweise innerhalb der IoT-Netzwerke vorliegen. Ferner senkt eine lokale Identifizierung den Kommunikationsaufwand und die Latenz.
Nun wird auf 5 Bezug genommen, welche eine beispielhafte Arbeitslastverteilungsumgebung 500 im Zusammenhang mit einem oder mehreren CA/AD (Computer-Assisted/Autonomous Driving - computergestütztes/autonomes Fahren) -Fahrzeugen (im Folgenden „Fahrzeug(e)“) in Ausführungsformen veranschaulicht. Mehrere Hosting-Plattformen 509, 511 und 519 können an einen Arbeitslastauslagerungs- oder Arbeitslastverteilungsdienst 527 gekoppelt sein, welcher wiederum für die Ausführungsform kommunikativ an die Kunden C1 533, C2 535 und C_N 537 gekoppelt sein kann. Jede der Hosting-Plattformen 509, 511 und 519 kann in Übereinstimmung mit verschiedenen Ausführungsformen mit einem entsprechenden Satz von einem oder mehreren Fahrzeugen assoziiert sein. Wie für die Ausführungsform gezeigt, kann die beispielhafte Hosting-Plattform 509 mit mehreren Fahrzeugen 507 assoziiert sein, zu welchen die Fahrzeuge 501, 503 und 505 zählen können. Dementsprechend kann für die Ausführungsform die zusätzliche Hosting-Plattform 511 mit mehreren Fahrzeugen 510 assoziiert sein, zu welchen die Fahrzeuge 513, 515 und 517 zählen können. Des Weiteren kann in der Ausführungsformen die zusätzliche Hosting-Plattform 519 mehrere Fahrzeuge 512 beinhalten, einschließlich der Fahrzeuge 521, 523 und 525.
In Ausführungsformen kann ein computergestütztes oder autonomes (CA/AD) Fahrsystem (detaillierter veranschaulicht in Bezug auf 7) in einem oder mehreren der Fahrzeuge angeordnet sein. In Ausführungsformen kann das CA/AD-Fahrsystem eine Berechnungsaufgabe empfangen. In Ausführungsformen kann die Berechnungsaufgabe Teil einer Sammlung verteilter Berechnungsaufgaben sein, die dem CA/AD-Fahrsystem teilweise basierend auf Ressourcen, die dem assoziierten Fahrzeug und anderen Berechnungsvorrichtungen, zu welchen andere CA/AD-Fahrzeuge zählen können, zur Verfügung stehen, zugewiesen werden können. Wie gezeigt wird, kann der Arbeitslastverteilungsdienst 527 in Ausführungsformen die verteilte Berechnungsaufgabe z.B. an das Fahrzeug 501 zuweisen. In Ausführungsformen kann der Arbeitslastverteilungsdienst 527 eine Kunden-Arbeitslastanfrage von einem oder mehreren Kunden, z.B. C1 533, C2 535 und/oder C_N 537, empfangen. In Ausführungsformen können die Arbeitslasten Berechnungsaufträge in Bezug auf rechnerisch intensive Aufgaben, wie z.B. das Ausführen eines ressourcenintensiven Algorithmus und/oder das Verarbeiten großer Mengen von Daten von Kunden, wie z.B. der Industrie, der wissenschaftlichen Gemeinschaft und/oder Einzelnen, beinhalten, jedoch nicht darauf beschränkt. Eine Arbeitslast kann jegliche/n geeignete/n Berechnungsauftrag oder -aufgabe beinhalten, zu dessen/deren Durchführung eine Hosting-Plattform geeignet ist. Zum Beispiel können Arbeitslasten von der Handhabung von Transaktionen von Einzelhandelswebseiten während Zeiträumen mit hoher Nachfrage bis hin zu Bitcoin- oder ETHEREUM®-Knotenanwendungen und/oder Anwendungen in Bezug auf Videospiele reichen. In einigen Ausführungsformen können eine Arbeitslast und ihre Anforderungen in einer Dienstgütevereinbarung (SLA - Service Level Agreement) spezifiziert sein. In Ausführungsformen kann die SLA spezifische Anforderungen für die Berechnungsaufträge sowie Sicherheitsstandards (z.B. das Verschlüsseln aller gespeicherten und gesendeten Daten), Leistung (z.B. Reaktionszeiten), Eigentümerschaft von Daten und dergleichen beschreiben. Zusätzlich zur Erfüllung von Parametern und Beschreibungen (z.B. Verarbeitung der Daten in Übereinstimmung mit einem Algorithmus und/oder dergleichen für einen spezifischen Auftrag), kann die Arbeitslast das Beobachten, Überwachen und Verfolgen anderer Anforderungen der SLA wie oben angegeben (das Erfüllen von Sicherheitsstandards und dergleichen) beinhalten.
Dementsprechend kann der Arbeitslastverteilungsdienst 527 in Ausführungsformen eine Kunden-Arbeitslast an eine oder mehrere der Hosting-Plattformen 509, 511 und 519 zuweisen, zumindest teilweise basierend auf Ressourcen der Fahrzeuge, die mit der zugewiesenen Plattform assoziiert sind. In Ausführungsformen können die Ressourcen jegliche geeigneten Ressourcen beinhalten, die einem oder mehreren der Fahrzeuge zur Verfügung stehen. In verschiedenen Ausführungsformen können zu den Ressourcen Rechenleistung, Speicherung (und/oder partitionierbare Speicherung), Verfügbarkeit vertrauenswürdiger Hardware und/oder Software, Netzwerkkonnektivität, ein vorhersagbarer Standort, Sensoren des Fahrzeugs und Energie, die einem oder mehreren der Fahrzeuge zur Verfügung steht, zählen, jedoch nicht darauf beschränkt. In Ausführungsformen können zu Ressourceninformationen auch Verlaufsinformationen im Zusammenhang mit dem Fahrzeug, um das Vorhersagen einer Verfügbarkeit der Ressourcen zu gestatten, zählen oder durch diese begleitet werden. In Ausführungsformen können Verlaufsinformationen von dem mindestens einen anderen CA/AD-Fahrzeug empfangen und analysiert werden, um eine Verfügbarkeit der Ressourcen des mindestens einen anderen CA/AD-Fahrzeugs vorherzusagen, um bei der Paarung der CA/AD-Fahrzeuge zum gemeinsamen Durchführen der Berechnungsaufgaben zu helfen.
In Ausführungsformen kann sich der Arbeitslastverteilungsdienst 527 auf einem oder mehreren Servern in der Cloud befinden. In Ausführungsformen kann eine Arbeitslast, die einer Hosting-Plattform zugewiesen wird, eine eigenständige Arbeitslast sein. In Ausführungsformen kann eine Arbeitslast, die einer Hosting-Plattform zugewiesen wird, ein Teil einer größeren Arbeitslast sein, wobei die anderen Teile anderen Hosting-Plattformen zugewiesen werden können oder auf anderen Servern in der Cloud durchgeführt werden.
Dementsprechend kann der Arbeitslastverteilungsdienst 527 in Ausführungsformen eine Hosting-Plattform-Warteschlange 529 und eine Arbeitslastwarteschlage 531 derart bestimmen und managen, dass Ressourcen der Hosting-Plattformen, z.B. 509, 511 und/oder 519, mit Bedürfnissen von Arbeitslasten im Zusammenhang mit Arbeitslastanfragen durch einen oder mehrere der Kunden C1 533, C2 535 und/oder C_N 537 übereinstimmen. Es sei darauf hingewiesen, dass, der Klarheit halber, jede Hosting-Plattform in 5 drei Fahrzeuge beinhaltet, jedoch können Ausführungsformen jegliche geeignete Zahl von Fahrzeugen beinhalten, die aus einer Mehrzahl von Fahrzeugen stammen können, um Dienste für die hierin beschriebenen Zwecke bereitzustellen. Des Weiteren kann in Ausführungsformen jegliche geeignete Zahl von Hosting-Plattformen (z.B. HP_N) vorliegen, um verfügbare Fahrzeuge und/oder Permutationen verfügbarer Fahrzeuge zur Entsprechung von Arbeitslastanfragen aufzunehmen.
6 veranschaulicht detaillierter die Hosting-Plattform 509, einschließlich der CA/AD-Fahrzeuge 501, 503 und 505, in Übereinstimmung mit verschiedenen Ausführungsformen. In Ausführungsformen können die Fahrzeuge 501, 503 und 505 jeweils mit den entsprechenden beispielhaften Fahrzeug-Ressourcenprofilen 621, 623 und 625 assoziiert sein. Zum Beispiel kann, wie für die Ausführungsform veranschaulicht, das Fahrzeug-Ressourcenprofil 621 für das Fahrzeug 501 eine verfügbare Leistung von 30 Watt/Stunde (30 W/h), die Sensortypen „s1“ und „s2“, ein Verfügbarkeitsfenster für die Ressourcen (z.B. eine Start-Stopp-Zeit des Fahrzeugs, die angibt, wenn das Fahrzeug geparkt ist und Ressourcen potentiell verfügbar sind), eine Berechnungsleistung von 10 Mega-FLOPS und einen Speicher von 2 GB angeben. Es sei darauf hingewiesen, dass die Sensortypen in Ausführungsformen mit jeglichen geeigneten Sensorgeräten assoziiert sein können, die zum Beispiel, jedoch nicht darauf beschränkt, Kameradaten, RADAR-Daten, LIDAR (Light Detection and Ranging) -Daten, Strahlungstemperaturdaten oder GPS (Global Positioning System) -Daten bereitstellen können. Wie in 6 veranschaulicht, führen die Fahrzeug-Ressourcenprofile 623 und 625 verschiedene beispielhafte Ressourcen, die mit den Fahrzeugen 503 und 505 assoziiert sind, für die Ausführungsformen auf. Wie oben angegeben, steht das Fahrzeug 505 in Ausführungsformen für CA/AD...n, da jegliche geeignete Zahl von Fahrzeugen zum Durchführen einer Client-Arbeitslast in der beispielhaften Hosting-Plattform 509 enthalten sein kann.
Es sei darauf hingewiesen, dass in Ausführungsformen Ressourcen der Fahrzeuge zur Verfügung stehen können, wenn ein oder mehrere der Fahrzeuge geparkt sind. In Ausführungsformen kann das Fahrzeug 501 angewiesen werden, oder selbst bestimmen, ein Netzwerk mit den Fahrzeugen 503 und 505 zu bilden, zumindest teilweise basierend auf einer vorhersagbaren physischen Nähe zu den anderen Fahrzeugen 503 und 505, einer Wahrscheinlichkeit, dass ihnen eine ähnliche Arbeitslast zugewiesen wird, und einer physischen Nähe zu einem Netzwerk mit hoher Bandbreite (z.B. eine 5G-Antenne, die sich auf oder nahe einem nahegelegenen Parkhaus oder Parkplatz befindet). Zum Beispiel können die Fahrzeuge 501, 503 und 505, wie veranschaulicht, unter Verwendung eines Netzwerkbildungsprotokolls, z.B. eines DANF (Dynamic Adhoc Network Formation) -Protokolls, ein Netzwerk bilden.
In Ausführungsformen kann der Arbeitslastverteilungsdienst 527 (von 5) eine Kunden-Arbeitslastanfrage von einem oder mehreren Kunden empfangen. In Ausführungsformen kann der Arbeitslastverteilungsdienst 527 auch mehrere Ressourcenprofile empfangen, die mehreren Hosting-Plattformen entsprechen, welche mehrere CA/AD-Fahrzeuge beinhalten. In Ausführungsformen kann eine Berechnungseinheit, wie z.B. ein entfernter Server oder ein oder mehrere CA/AD-Systeme oder Fahrsystem(e), ein oder mehrere gemeinsame Hosting-Profile zusammenlegen, damit diese jedem einer entsprechenden Mehrzahl von CA/AD-Fahrzeugen, z.B. 507, 510 und 512 von 5, entsprechen. Außerdem kann die Berechnungseinheit, wie in 6 gezeigt, in Ausführungsformen ein oder mehrere gemeinsame Hosting-Profile 630, 633 und/oder 635, die mit einer einzelnen Hosting-Plattform 509 assoziiert sind, zumindest teilweise basierend auf Fahrzeug-Ressourcenprofilen, z.B. 621, 623 und 625, erstellen. Dementsprechend können in Ausführungsformen verschiedene gemeinsame Hosting-Profile 630, 633 und/oder 635 eine Kombination aus Ressourcen von einem oder mehreren der einzelnen Fahrzeug-Ressourcenprofile 621, 623, und 625 beinhalten, die mit einer Vielzahl von Arbeitslasten übereinstimmen können. In verschiedenen Ausführungsformen kann die Berechnungseinheit Ressourcen der Fahrzeuge, z.B. Speicher, in einer Art und Weise partitionieren, die einer Plattform das Unterstützen mehrerer Arbeitslasten gestattet.
Des Weiteren können in Ausführungsformen zusätzliche andere Berechnungseinheiten als Fahrzeuge in die Ressourcenprofile eingeschlossen werden oder können berücksichtigt werden, wenn Arbeitslasten mit Hosting-Plattformen oder Fahrzeugen abgeglichen werden. In verschiedenen Ausführungsformen kann zum Isolieren einer „normalen“ Arbeitslast von der Berechnungsaufgabe eine Bescheinigungs- und Schutzbereichs- oder Container-Technologie eingesetzt werden (unten in Bezug auf 8 und 9 diskutiert). In Ausführungsformen können mehrere Arbeitslasten mehreren Containern entsprechen, wobei jeder Container eine entsprechende Arbeitslast einkapselt. Des Weiteren können Operationen und Speicher innerhalb von Containern innerhalb eines Fahrzeugs und/oder einer Berechnungseinheit isoliert werden. In verschiedenen Ausführungsformen können Benutzer von Fahrzeugen, z.B. 501, 503 und 505, für die Nutzung ihres Fahrzeugs bei der Durchführung von Aufgaben entschädigt werden. Es sei darauf hingewiesen, dass in verschiedenen Ausführungsformen jedes der Fahrzeuge einen Blockchain-Verarbeitungsknoten umfassen kann. In einigen Ausführungsformen kann jedes Fahrzeug, das mit einer Hosting-Plattform assoziiert ist, die Zusammenlegung und Pflege eines gemeinsamen Hosting-Profils zumindest teilweise basierend auf Ressourcenprofilen einzelner Fahrzeuge der mehreren Fahrzeuge unterstützen. In verschiedenen anderen ähnlichen Ausführungsformen kann jedes Fahrzeug zum Zweck der Durchführung einer zugewiesenen Arbeitslast von einem Kunden, z.B. das Durchführen von Aufgaben als ein Ethereum- oder ein anderer Knoten, einen Blockchain-Verarbeitungsknoten bilden. Dementsprechend können sich eine oder mehrere Hosting-Plattformen 509, 511 oder 519 in einer Cloud 302 oder auf die Fahrzeuge 501, 503 und 505 verteilt befinden.
Nun wird auf 7 Bezug genommen, in welcher eine Blockdiagrammansicht eines beispielhaften computergestützten oder autonomen Fahrsystems (CA/AD) in Übereinstimmung mit verschiedenen Ausführungsformen gezeigt wird. Wie veranschaulicht, kann das CA/AD-System 700 eine oder mehrere Kommunikationsschnittstellen 706, eine Berechnungsmaschine oder Verarbeitungseinheit 704, einen Speicher 703 und einen Hauptcontroller 702 beinhalten, die wie gezeigt miteinander gekoppelt sind. In Ausführungsformen kann der Hauptcontroller 702 zum Ausgeben der Steuerbefehle 712 an die Antriebselemente 714 eines CA/AD-Fahrzeugs, z.B. des Fahrzeugs 501, konfiguriert sein (z.B. an einen Motor, einen Elektromotor, ein Bremssystem, ein Antriebssystem, Räder, ein Getriebe und eine Batterie und so weiter). In Ausführungsformen kann die vertrauenswürdige Hardware 785 einen Schutzbereich oder Container 780 beinhalten, der einen Arbeitsspeicher und/oder Speicher 703 zum Isolieren von privaten Berechnungsdaten und Berechnungscode im Zusammenhang mit einer empfangenen Berechnungsaufgabe aufweisen kann. In Ausführungsformen kann die Verarbeitungseinheit 704 privaten Berechnungscode im Zusammenhang mit der Berechnungsaufgabe innerhalb des Containers 780 ausführen. In Ausführungsformen kann die Verarbeitungseinheit 704 ein Prozessor sein, der zum Schützen der Vertraulichkeit einer Berechnung durch das Isolieren des privaten Codes und der privaten Daten, einschließlich von einem Betriebssystem und Geräten, die an den Systembus gekoppelt sind, ausgestattet ist, z.B. ein Intel® Prozessor mit SGX® (Software Guard Extensions) - Unterstützung.
In Ausführungsformen kann die Berechnungsaufgabe über die beispielhafte Hosting-Plattform 509 empfangen werden. In Ausführungsformen kann eine der einen oder mehreren Kommunikationsschnittstellen 706 zum Empfangen der Berechnungsaufgabe 750 von einem Arbeitslast-Auslagerungsdienst, z.B. dem Arbeitslastverteilungsdienst 527, konfiguriert sein. Eine oder mehrere Kommunikationsschnittstellen 706 können auch zum Empfangen verschiedener Sensordaten 710 von den Sensoren 708 für die Ausführungsform konfiguriert sein. In Ausführungsformen können die Sensordaten 710 Kameradaten, Strahlungstemperaturdaten oder GPS-Daten umfassen, z.B. Kameradaten, Strahlungstemperaturdaten oder GPS-Daten, die entsprechend durch eine Kamera, einen Strahlungstemperatursensor oder einen GPS-Sensor 208, die/der in dem CA/AD-Fahrzeug 501 angeordnet ist, gesammelt werden. In Ausführungsformen können die eine oder die mehreren Kommunikationsschnittstellen 706 zum Senden von Informationen an die Hosting-Plattform oder den Arbeitslast-Auslagerungsdienst konfiguriert sein. In Ausführungsformen können die Informationen in Bezug auf die Berechnungsaufgabe (einschließlich Aufgabe abgeschlossen oder teilweise abgeschlossen) und/oder Ressourcendaten, einschließlich der Sensordaten 710, beinhalten. In Ausführungsformen können die Informationen Daten beinhalten, wie z.B. die Ressourcendaten 705, einschließlich Verlaufsdaten, die im sicheren Speicher 703 gespeichert sind. Der Eigentümer, der Fahrer und/oder der Mitfahrer kann sich während der Durchführung der Berechnungsaufgabe vorübergehend von dem geparkten CA/AD-Fahrzeug 501 entfernen. In Ausführungsformen können Informationen in Bezug auf eine Bezahlung für die gesamte oder einen Teil der Berechnungsaufgabe, die abgeschlossen wurde, über die Kommunikationsschnittstelle 706 von der Hosting-Plattform oder dem Arbeitslastverteilungsdienst für einen Eigentümer des CA/AD-Fahrzeugs 501 empfangen werden.
In Ausführungsformen können die eine oder die mehreren Kommunikationsschnittstellen 706 eine Kommunikationsschnittstelle, wie z.B. einen I²-Bus, einen IDE (Integrated Drive Electronic) -Bus, einen SATA (Serial Advanced Technology Attachment) -Bus, einen PCI (Peripheral Component Interconnect) -Bus, einen USB (Universal Serial Bus), eine NFC (Near Field Communication) -Schnittstelle, eine Bluetooth®-Schnittstelle, WiFi und so weiter, zum Empfangen der Sensordaten 710 von den Sensoren 708 beinhalten. In Ausführungsformen kann die Verarbeitungseinheit 704 über die Kommunikationsschnittstelle(n) 706 zum Empfangen der Sensordaten 710 über die Umgebungsbedingungen des Bereichs rund um oder angrenzend an das CA/AD-Fahrzeug, während das CA/AD-Fahrzeug geparkt ist, konfiguriert sein. Ferner kann die Verarbeitungseinheit 704 zum kontinuierlichen oder periodischen Analysieren der Sensordaten 710 und zum Sammeln der Verlaufsdaten (wie oben angegeben) in Bezug auf die Ressourcenverfügbarkeit (z.B. Zeiten, wenn das CA/AD-Fahrzeug geparkt ist, Routen, Energieverfügbarkeit und dergleichen) konfiguriert sein.
In Ausführungsformen kann die Verarbeitungseinheit 704 in Hardware, z.B. einer ASIC oder einer programmierbaren kombinatorischen Logikschaltung (z.B. (FPGA)), oder Software (die durch einen Prozessor und eine Arbeitsspeicheranordnung ausgeführt wird) oder Kombination davon implementiert sein. Wie unten in Verbindung mit 9 angegeben, kann ein Hardware-Beschleuniger oder eine programmierbare Hardware-Logik 707 (z.B. ein FPGA) programmierbar sein, um verschiedene Bedürfnisse verschiedener Kunden-Arbeitslasten zu erfüllen. In verschiedenen Ausführungsformen können die Verarbeitungseinheit 704 und/oder der sichere Speicher 703 in einer separaten vertrauenswürdigen/gesicherten Ausführungsumgebung arbeiten oder es kann in einer solchen darauf zugegriffen werden, welche von der allgemeinen Ausführungsumgebung für Anwendungen in Bezug auf die autonomen Fahrzeugoperationen und Zugriff durch den Fahrer getrennt, isoliert und geschützt ist. In Ausführungsformen können Arbeitslast-bezogene Verarbeitung und Speicherung in Schutzbereichen implementiert sein.
Nun wird auf 8 Bezug genommen, in welcher ein beispielhafter Prozess für das Zuweisen einer Kunden-Arbeitslast zu einem CA/AD-Fahrzeug in Übereinstimmung mit verschiedenen Ausführungsformen gezeigt wird. Wie veranschaulicht wird, kann der Prozess 800 Operationen beinhalten, die in den Blöcken 803-809 durchgeführt werden. Die Operationen können z.B. durch einen oder mehrere externe/n oder entfernte/n Arbeitslast-Managementserver, der/die sich in einer Cloud und/oder einem GSM EDGE-Netzwerk befindet/befinden (siehe z.B. 1-4), oder durch das CA/AD-System 700 von 7, als Teil einer vertrauenswürdigen Anordnung zwischen CA/AD-Fahrzeugen (z.B. in einer Ausführungsform über eine Blockchain-Anordnung), durchgeführt werden. In alternativen Ausführungsformen kann der Prozess 800 zum Zuweisen der Kunden-Arbeitslast mehr oder weniger Operationen beinhalten oder einige der Operationen können in unterschiedlicher Reihenfolge durchgeführt werden. Der Prozess 800 kann mit Block 803 starten, in welchem in einer Ausführungsform eine Kunden-Arbeitslastanfrage empfangen (z.B. von einem Client) oder abgerufen (von einer entfernten oder lokalen Anfragewarteschlange) werden kann. In Ausführungsformen kann eine Authentifizierung der Identifikation und/oder der Ressourcen der CA/AD-Fahrzeuge über einen Fernprüfungsnachweis (mit Bezug auf 9 unten weiter diskutiert) empfangen werden. Zum Beispiel kann eine Kunden-Arbeitslastanfrage in verschiedenen Ausführungsformen eine Dienstgütevereinbarung (SLA - Service Level Agreement) beinhalten oder einer solchen entsprechen. In einigen Ausführungsformen kann die SLA analysiert werden, um zu bestimmen, welche Arten von Ressourcen möglicherweise zum Erfüllen der Vereinbarung oder Anfrage benötigt werden, z.B. eine angemessene Menge verfügbarer Energie, Berechnungsleistung, Speicher, Verarbeitungsleistung, Sensortyp und dergleichen. Für die Ausführungsform können im nächsten Block, 805, mehrere Ressourcenprofile, die mit entsprechenden mehreren Hosting-Plattformen oder einer anderen Aggregation von CA/AD-Fahrzeugen, die Aufgaben durchführen können, assoziiert sind, empfangen oder abgerufen werden (von einer entfernten Datenbank oder einem lokalen Cache). In Ausführungsformen kann eine Hosting-Plattform ein zuvor registriertes oder mehrere zuvor registrierte Ressourcenprofile aufweisen, zumindest teilweise basierend auf gemeinsamen Ressourcen und Verlaufsinformationen von mehreren CA/AD-Fahrzeugen, um anzugeben, dass die mehreren Fahrzeuge zum Empfangen einer Arbeitslast zur Verfügung steht. In Ausführungsformen kann eine weitere Authentifizierung von Ressourcen der CA/AD-Fahrzeuge über einen Fernprüfungsnachweis (nicht gezeigt) empfangen werden. Dementsprechend werden in Ausführungsformen im nächsten Block, 807, die Kunden-Arbeitslastanfrage und Ressourcenprofile analysiert, um z.B. basierend auf der SLA und Ressourcen eine Übereinstimmung zum Erfüllen der SLA zu bestimmen. Und schließlich kann für die Ausführungsform in einem Block 809 eine Kunden-Arbeitslast in Bezug auf die Arbeitslastanfrage zumindest teilweise basierend auf der Analyse zu einer ausgewählten Hosting-Plattform zugewiesen werden. In Ausführungsformen kann dann die Zuweisung, zusammen mit Informationen in Bezug auf die Kunden-Arbeitslast, an die ausgewählte Plattform, die mehrere CA/AD-Fahrzeuge beinhaltet, gesendet werden. In alternativen Ausführungsformen kann die Zuweisung mit Standortinformationen gesendet werden, welche identifizieren, wo die Kunden-Arbeitslast abgerufen werden kann.
Nun wird auf 9 Bezug genommen, in welcher ein beispielhafter Prozess für das Empfangen/Abrufen und Durchführen einer Berechnungsaufgabe durch ein CA/AD-Fahrzeug in Übereinstimmung mit verschiedenen Ausführungsformen gezeigt wird. Wie veranschaulicht wird, kann der Prozess 900 Operationen beinhalten, die in den Blöcken 901-917 durchgeführt werden. In alternativen Ausführungsformen kann der Prozess 900 zum Empfangen/Abrufen und Durchführen der Berechnungsaufgabe mehr oder weniger Operationen beinhalten oder einige der Operationen können in unterschiedlicher Reihenfolge durchgeführt werden. Der Prozess 900 kann mit Block 901 beginnen, in welchem das CA/AD-Fahrzeug („Fahrzeug“) eine Verbindung mit einer Hosting-Plattform (z.B. die Hosting-Plattform 509) und/oder einem Arbeitslastverteilungsdienst (z.B. der Arbeitslastverteilungsdienst 527) aufbauen kann. In Ausführungsformen kann das Fahrzeug die Verbindung aufbauen, um eine Verfügbarkeit zum Durchführen einer Berechnungsaufgabe anzugeben, indem die Verfügbarkeit bei einem Netzwerk aus mehreren anderen Fahrzeugen, die ähnlich zum Durchführen einer Arbeitslast in Bezug auf die Berechnungsaufgabe zur Verfügung stehen, registriert wird.
In Ausführungsformen kann das Fahrzeug ein CA/AD-System aufweisen, das Hardware und/oder Software (HW/SW) -Sicherheit beinhaltet. In Ausführungsformen können die vertrauenswürdige Hardware und Software des CA/AD-Systems Schutzbereiche oder Container für das Aufnehmen von Ressourcen, wie z.B. Speicher, RAM und dergleichen, bereitstellen. Dementsprechend kann für die Ausführungsform während oder vor der Verbindung des Fahrzeugs eine sichere Authentifizierung des Fahrzeugs im Block 901a stattfinden, z.B. über einen Sicherheitsauthentifizierungs-Server, um es der Hosting-Plattform und/oder dem Arbeitslastverteilungsdienst zu gestatten, dem Fahrzeug zu vertrauen. In Ausführungsformen kann der Sicherheitsauthentifizierungs-Server auch bei der Bereitstellung eines sicheren Verfahrens zur Bescheinigung von Ressourcen und Berechnungsfähigkeit des Fahrzeugs helfen. In Ausführungsformen kann die Bescheinigung von Ressourcen und Berechnungsfähigkeit bei der Bestimmung einer Menge und eines Typs von Berechnungsaufgaben, die dem Fahrzeug zugewiesen werden können (wie z.B. in Bezug auf 8 durchgeführt), helfen. In Ausführungsformen kann das CA/AD-System eine vertrauenswürdige Ausführungsumgebung aufweisen, z.B. die SGX® (Software Guard Extensions) -basierte vertrauenswürdige Ausführungsumgebung (TEE - Trusted Execution Environment) von Intel, und der sichere Authentifizierungsserver kann einen SGX®-Authentifizierungsserver aufweisen.
Im nächsten Block, 905, kann das Fahrzeug in Ausführungsformen eine Berechnungsaufgabe und/oder Informationen in Bezug auf eine assoziierte Arbeitslast empfangen, die von der Hosting-Plattform und/oder dem Arbeitslastverteilungsdienst gesendet werden. Wie zuvor beschrieben, kann das Fahrzeug in Ausführungsformen die Zuweisungsinformationen zusammen mit Standortinformationen empfangen, welche angeben, wo Informationen im Zusammenhang mit der Berechnungsaufgabe abgerufen werden können. In Ausführungsformen kann die Hosting-Plattform und/oder der Arbeitslastverteilungsdienst für die Dauer der Durchführung der Berechnung Anwendungen auf dem CA/AD-System installieren. Als nächstes kann das Fahrzeug bei Empfang oder Abruf der Berechnungsaufgabe (und Installation der notwendigen Software) in einem Block 907 die Berechnungsaufgabe durchführen. Es sei darauf hingewiesen, dass in verschiedenen Ausführungsformen ein Hardware-Beschleuniger (wie z.B. ein FPGA) in dem CA/AD-System in Echtzeit umprogrammiert werden kann, um eine Berechnungsfunktionalität zumindest teilweise basierend auf einer zugewiesenen Berechnungsaufgabe zu optimieren oder zu erhöhen. Des Weiteren kann in Ausführungsformen wieder eine sichere und dynamische Bescheinigung des CA/AD-Systems während der Durchführung der Berechnungsaufgabe bereitgestellt werden. In einem nächsten Entscheidungsblock 911 kann sich, wenn das Fahrzeug (und/oder die Hosting-Plattform) eine Benachrichtigung empfangen hat, dass beim Hersteller Software- oder Firmware-Updates für das Fahrzeug zur Verfügung stehen, das Fahrzeug in einem Block 917 von der Hosting-Plattform und/oder dem Arbeitslastverteilungsdienst trennen. Wenn dem nicht so ist, kann das CA/AD-System in Ausführungsformen mit dem Durchführen der Berechnungsaufgabe fortfahren. Für die Ausführungsform fährt der Prozess mit einem nächsten Block, 913, fort, in welchem, wenn der Fahrer das Fahrzeug nutzen möchte, das Fahrzeug in einem Block 917 die Verbindung trennen kann. Ansonsten kann das CA/AD-System in Ausführungsformen mit der Durchführung der Berechnungsaufgabe fortfahren. In Ausführungsformen kann, wenn das Fahrzeug die Verbindung mit der Hosting-Plattform in Block 917 getrennt hat, bevor die Berechnungsaufgabe abgeschlossen wurde, das Fahrzeug die Berechnungsaufgabe unterbrechen, bis das Fahrzeug das Durchführen der Berechnungsaufgabe wieder aufnehmen kann, die teilweise abgeschlossene Berechnungsaufgabe zur Fortsetzung an andere Fahrzeuge in der Hosting-Plattform senden oder die teilweise abgeschlossene Berechnungsaufgabe zur Neuzuweisung zurück an den Arbeitslastverteilungsdienst senden. In Ausführungsformen kann ein Senden das Senden der Zwischenergebnisse oder -zustände der teilweise abgeschlossenen Berechnungsaufgabe vor dem Trennen der Verbindung zu der Hosting-Plattform und/oder dem Arbeitslastverteilungsdienst beinhalten.
In Ausführungsformen ist, wenn das CA/AD-System in der Lage ist, die Durchführung der Berechnungsaufgabe bis zum Abschluss fortzusetzen, die Antwort in Block 915 schließlich „Ja“, und das Fahrzeug kann in Block 917 die Verbindung zur Hosting-Plattform und/oder zum Arbeitslastverteilungsdienst trennen. Es sei darauf hingewiesen, dass in verschiedenen Ausführungsformen, nachdem die Verbindung des Fahrzeugs getrennt wurde, ein vorheriger Fahrsystemzustand gespeichert werden kann. In Ausführungsformen kann eine vertrauenswürdige Ausführungstechnologie (z.B. eine TXT-Technologie), welche für dynamische Verifizierung modifiziert werden kann, zum Verifizieren des vorherigen Fahrsystemzustands verwendet werden, ohne das CA/AD-System neu zu starten. Es sei darauf hingewiesen, dass in Ausführungsformen, wenn das CA/AD-System beeinträchtigt ist, das CA/AD-System den Fehler an die Hosting-Plattform melden kann und seine beabsichtigte Operation nicht wieder aufnimmt, bis der Fehler korrigiert wurde. In Ausführungsformen können, nachdem die Verbindung zu dem Fahrzeug getrennt wurde, die Hosting-Plattform und/oder der Arbeitslastverteilungsdienst eine Arbeitsmenge, die durch das CA/AD-System durchgeführt wurde, bestimmen, um den Fahrer oder Fahrzeugeigentümer entsprechend zu entschädigen.
In Ausführungsformen kann das CA/AD-System, nach dem Trennen der Verbindung in Block 917, in einem Block 919 bestimmen, ob es für das CA/AD-System angemessen ist, sich neu zu verbinden (z.B. wie in den Einstellungen durch den Fahrer oder Fahrzeugeigentümer oder durch eine Voreinstellung angegeben). In Ausführungsformen kann der Prozess, wenn die Antwort „Nein“ ist, in einem nächsten Block enden. Wenn die Antwort „Ja“ ist, kehrt der Prozess zu Block 901 zurück, in welchem das Fahrzeug wieder eine Verbindung mit der Hosting-Plattform und/oder dem Arbeitslastverteilungsdienst 527 aufbauen kann. In Ausführungsformen kann das Fahrzeug eine Prüfung vornehmen, um zu bestimmen, ob das CA/AD-System eine zuvor nicht abgeschlossene Berechnungsaufgabe durch das Fahrzeug fortsetzen sollte, oder es kann der Hosting-Plattform und/oder dem Arbeitslastverteilungsdienst 527 anzeigen, dass es wieder zur Durchführung einer neuen Berechnungsaufgabe zur Verfügung steht.
10 ist ein Blockdiagramm eines Beispiels von Komponenten, die in einem IoT-Gerät 1050 zur Implementierung der hierin beschriebenen Techniken vorliegen können. Das IoT-Gerät 1050 kann jegliche Kombinationen der Komponenten beinhalten, die in dem Beispiel gezeigt sind oder auf die in der Offenbarung oben verwiesen wird. Die Komponenten können als ICs, Teile davon, diskrete elektronische Geräte oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, angepasst in dem IoT-Gerät 1050, oder als Komponenten, die anderweitig innerhalb eines Chassis eines größeren Systems eingeschlossen sind, implementiert sein. Außerdem soll das Blockdiagramm von 10 eine umfassende Ansicht von Komponenten des IoT-Gerätes 1050 zeigen. Jedoch können in anderen Implementierungen einige der gezeigten Komponenten weggelassen sein, zusätzliche Komponenten können vorliegen und es kann eine unterschiedliche Anordnung der gezeigten Komponenten erfolgen.
Das IoT-Gerät 1050 kann vertrauenswürdige Hardware 1085 aufweisen, welche einen Prozessor 1052 beinhalten kann, bei welchem es sich um einen Mikroprozessor, einen Mehrkernprozessor, einen Multithread-Prozessor, einen Energiesparprozessor, einen eingebetteten Prozessor oder ein anderes bekanntes Verarbeitungselement handeln kann. Der Prozessor 1052 kann Teil eines Ein-Chip-Systems (SoC - System on a Chip) sein, in welchem der Prozessor 1052 und andere Komponenten in eine einzelne integrierte Schaltung oder ein einzelnes Paket, wie z.B. die Edison™- oder Galileo™-SoC-Platinen von Intel, gebildet sind. Als ein Beispiel kann der Prozessor 1052 einen auf einem Intel® Architecture Core™ basierenden Prozessor aufweisen, wie z.B. einen Quark™, einen Atom™, einen i3, einen i5, einen i7 oder einen Prozessor der MCU-Klasse oder einen anderen derartigen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien erhältlich ist. Jedoch kann auch jegliche Zahl anderer Prozessoren zum Einsatz kommen, wie sie z.B. von Advanced Micro Devices, Inc. (AMD) in Sunnyvale, Kalifornien erhältlich sind, ein MIPS-basiertes Design von MIPS Technologies, Inc. in Sunnyvale, Kalifornien, ein ARM-basiertes Design lizenziert von ARM Holdings, Ltd. oder einem Kunden davon oder ihren Lizenznehmern oder Anwendern. Zu den Prozessoren können Einheiten wie z.B. ein A5-A10-Prozessor von Apple® Inc., ein Snapdragon™-Prozessor von Qualcomm® Technologies, Inc. oder ein OMAP™-Prozessor von Texas Instruments, Inc. zählen. In Ausführungsformen kann der Prozessor 1052 an einen Hardware-Beschleuniger 1053 gekoppelt sein, welcher in einigen Ausführungsformen z.B. programmierbare Logik aufweisen kann, wie z.B. ein neu programmierbares FPGA, das gemäß einer Berechnungsaufgabe spezifisch angepasst werden kann.
Der Prozessor 1052 kann über eine Zwischenverbindung 1056 (z.B. einen Bus) mit einem Systemarbeitsspeicher 1054 kommunizieren. Es kann jegliche Zahl von Arbeitsspeichergeräten zum Einsatz kommen, um eine entsprechende Menge an Systemarbeitsspeicher bereitzustellen. Als Beispiel kann der Arbeitsspeicher Direktzugriffsspeicher (RAM - Random Access Memory) in Übereinstimmung mit einem JEDEC (Joint Electron Devices Engineering Council) -Design sein, wie z.B. die DDR- oder die mobilen DDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In verschiedenen Implementierungen können die einzelnen Arbeitsspeichergeräte aus jeglicher Zahl von unterschiedlichen Pakettypen bestehen, wie z.B. SDP (Single Die Package), DDP (Dual Die Package) oder Q17P (Quad Die Package). In einigen Beispielen können diese Geräte direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit einem geringeren Profil bereitzustellen, während die Geräte in anderen Beispielen als ein oder mehrere Arbeitsspeichermodule konfiguriert sind, die wiederum über ein entsprechendes Verbindungselement an die Hauptplatine gekoppelt sind. Es kann auch jegliche Zahl anderer Arbeitsspeicherimplementierungen zum Einsatz kommen, wie z.B. andere Arten von Arbeitsspeichermodulen, z.B. DIMMs (Dual Inline Memory Modules) unterschiedlicher Varietäten, einschließlich, jedoch nicht darauf beschränkt, Mikro-DIMMs oder Mini-DIMMs.
Zum Bereitstellen einer dauerhaften Speicherung von Informationen, wie z.B. Daten, Anwendungen, Betriebssystemen und so weiter, kann auch ein Speicher 1058 über die Zwischenverbindung 1056 an den Prozessor 1052 gekoppelt sein. In einem Beispiel kann der Speicher 1058 über ein SSDD (Solid-State Disk Drive) implementiert sein. Zu anderen Geräten, die als der Speicher 1058 eingesetzt werden können, zählen Flashspeicherkarten, wie z.B. SD-Karten, Mikro-SD-Karten, xD-Bildkarten und dergleichen, und USB-Flash-Laufwerke. Bei Niedrigenergieimplementierungen kann der Speicher 1058 integrierter Arbeitsspeicher oder Register im Zusammenhang mit dem Prozessor 1052 sein. Jedoch kann der Speicher 1058 in einigen Beispielen auch unter Verwendung eines Mikro-Festplattenlaufwerks (HDD - Hard Disk Drive) implementiert sein. Ferner kann jegliche Zahl neuer Technologien zusätzlich zu den oder anstelle der beschriebenen Technologien als der Speicher 1058 zum Einsatz kommen, wie z.B., u.a., Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
Die Komponenten können über die Zwischenverbindung 1056 kommunizieren. Die Zwischenverbindung 1056 kann jegliche Zahl von Technologien aufweisen, einschließlich ISA (Industry Standard Architecture), EISA (Extended ISA), PCI (Peripheral Component Interconnect), PCIx (Peripheral Component Interconnect extended), PCIe (PCI express) oder jegliche Zahl anderer Technologien. Die Zwischenverbindung 1056 kann ein proprietärer Bus sein, wie er zum Beispiel in einem SoC-basierten System eingesetzt wird. Es können auch andere Bus-Systeme enthalten sein, wie z.B., u.a., eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Energie-Bus.
Die Zwischenverbindung 1056 kann den Prozessor 1052 für die Kommunikation mit anderen Mesh-Geräten 1064 an einen Mesh-Sendeempfänger 1062 koppeln. Der Mesh-Sendeempfänger 1062 kann jegliche Zahl von Frequenzen und Protokollen verwenden, wie z.B. 2,4 Gigahertz (GHz) Übertragungen gemäß dem IEEE 802.15.4 Standard, unter Verwendung, u.a., des BLE (Bluetooth® Low Energy) -Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Jegliche Zahl von Funkgeräten, konfiguriert für ein bestimmtes drahtloses Kommunikationsprotokoll, kann für die Verbindungen zu den Mesh-Geräte 1064 eingesetzt werden. Zum Beispiel kann eine WLAN-Einheit zum Implementieren von Wi-Fi™-Kommunikation in Übereinstimmung mit dem IEEE (Institute of Electrical and Electronics Engineers) -Standard 802.11 verwendet werden. Außerdem kann drahtlose Weitbereichskommunikation, z.B. gemäß einem Mobilfunkprotokoll oder einem anderen drahtlosen Weitbereichsprotokoll, über eine WWAN-Einheit stattfinden.
Der Mesh-Sendeempfänger 1062 kann unter Verwendung mehrerer Standards oder Funkgeräte für die Kommunikation in unterschiedlichen Bereichen kommunizieren. Zum Beispiel kann das IoT-Gerät 1050 mit nahen Geräten, z.B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf BLE oder eines anderen Niedrigenergie-Funkgerätes kommunizieren, um Energie zu sparen. Weiter entfernte Mesh-Geräte 1064, z.B. innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkgeräte im mittleren Leistungsbereich erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät auf unterschiedlichen Leistungsebenen stattfinden oder können über separate Sendeempfänger stattfinden, zum Beispiel einen lokalen Sendeempfänger unter Verwendung von BLE und einen separaten Mesh-Sendeempfänger unter Verwendung von ZigBee.
Ein drahtloser Netzwerk-Sendeempfänger 1066 kann zum Kommunizieren mit Geräten oder Diensten in der Cloud 1000 über lokale oder Weitbereichs-Netzwerkprotokolle enthalten sein. Der drahtlose Netzwerk-Sendeempfänger 1066 kann ein LPWA-Sendeempfänger sein, der, u.a., den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Das IoT-Gerät 1050 kann unter Verwendung eines LoRaWAN™ (Long Range Wide Area Network), entwickelt durch Semtech und die LoRa Alliance, über einen weiten Bereich kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit jeglicher Zahl von anderen Cloud-Sendeempfängern, die Kommunikation mit großer Reichweite und niedriger Bandbreite implementieren, wie z.B. Sigfox, und anderen Technologien verwendet werden. Ferner können auch andere Kommunikationstechniken, wie z.B. Zeitschlitz-Kanal springen, beschrieben in der Spezifikation IEEE 802.15.4e, zum Einsatz kommen.
Jegliche Zahl anderer Funkkommunikation und -protokolle kann zusätzlich zu den genannten Systemen für den Mesh-Sendeempfänger 1062 und den drahtlosen Netzwerk-Sendeempfänger 1066, wie hierin beschrieben, verwendet werden. Zum Beispiel können die Funksendeempfänger 1062 und 1066 einen LTE- oder einen anderen Mobilfunk-Sendeempfänger verwenden, der Wechselspektrum (SPA/SAS) -Kommunikation für die Implementierung von Hochgeschwindigkeitskommunikation nutzt. Ferner kann auch jegliche Zahl anderer Protokolle zum Einsatz kommen, wie z.B. Wi-Fi®-Netzwerke für Kommunikation mit mittlerer Geschwindigkeit und die Bereitstellung von Netzwerkkommunikation.
Die Funksendeempfänger 1062 und 1066 können Funkgeräte beinhalten, die mit jeglicher Zahl von 3GPP (Third Generation Partnership Project) - Spezifikationen kompatibel sind, insbesondere LTE (Long Term Evolution), LTE-A (Long Term Evolution-Advanced) und LTE-A Pro (Long Term Evolution-Advanced Pro). Es lässt sich festhalten, dass Funkgeräte, die mit jeglicher Zahl von anderen feststehenden, mobilen oder Satelliten-Kommunikationstechnologien und -standards kompatibel sind, ausgewählt werden können. Zu diesen kann zum Beispiel jegliche Mobilfunk-Weitbereichsfunk-Kommunikationstechnologie, welche z.B. ein Kommunikationssystem der 5. Generation (5G) beinhalten kann, eine GSM (Global System for Mobile Communication) - Funkkommunikationstechnologie, eine GPRS (General Packet Radio Service) - Funkkommunikationstechnologie, eine EDGE (Enhanced Data Rates for GSM Evolution) -Funkkommunikationstechnologie oder eine UMTS (Universal Mobile Telecommunications System) -Kommunikationstechnologie zählen. Zusätzlich zu den oben aufgeführten Standards kann jegliche Zahl von Satelliten-Uplink-Technologien für den drahtlosen Netzwerk-Sendeempfänger 1066 verwendet werden, einschließlich zum Beispiel, u.a., Funkgeräte gemäß den Standards ausgegeben durch die ITU (International Telecommunication Union) oder das ETSI (European Telecommunications Standards Institute). Die hierin bereitgestellten Beispiele werden somit als für verschiedene andere Kommunikationstechnologien, sowohl bereits vorliegend als auch noch nicht formuliert, geltend, verstanden.
Ein Netzwerkschnittstellen-Controller (NIC) 1068 kann enthalten sein, um verdrahtete Kommunikation mit der Cloud 1000 oder mit anderen Geräten, wie z.B. den Mesh-Geräten 1064, bereitzustellen. Die verdrahtete Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie z.B., unter vielen anderen, einem CAN (Controller Area Network), einem LIN (Local Interconnect Network), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET. Ein zusätzlicher NIC 1068 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu gestatten, zum Beispiel ein NIC 1068, welcher Kommunikation zur Cloud über das Ethernet bereitstellt, und ein zweiter NIC 1068, welcher Kommunikation zu anderen Geräten über eine andere Art von Netzwerk bereitstellt.
Die Zwischenverbindung 1056 kann den Prozessor 1052 an eine externe Schnittstelle 1070 koppeln, die zum Verbinden externer Geräte oder Untersysteme verwendet wird. Zu den externen Geräten können Sensoren 1072, wie z.B. Beschleunigungsmesser, Pegelsensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, GPS (Global Positioning System) -Sensoren, Drucksensoren, Luftdrucksensoren und dergleichen zählen. Die externe Schnittstelle 1070 kann ferner zum Verbinden des IoT-Gerätes 1050 mit Aktoren 1074 verwendet werden, wie z.B. Leistungsschaltern, Ventilantrieben, einem akustischen Tonerzeuger, einem visuellen Warngerät und dergleichen.
In einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe (E/A) -Geräte innerhalb des IoT-Gerätes 1050 vorliegen oder damit verbunden sein. Zum Beispiel kann eine Anzeige oder ein anderes Ausgabegerät 1084 enthalten sein, um Informationen anzuzeigen, wie z.B. Sensorablesungen oder Aktorpositionen. Ein Eingabegerät 1086, wie z.B. ein Touchscreen oder ein Tastenfeld, kann zum Annehmen einer Eingabe enthalten sein. Ein Ausgabegerät 1084 kann jegliche Zahl von Audio- oder Sichtanzeigeformen beinhalten, einschließlich einfacher visueller Ausgaben, wie z.B. Binärstatus-Indikatoren (z.B. LEDs) und visuelle Mehrzeichenausgaben, oder komplexerer Ausgaben, wie z.B. Anzeigebildschirme (z.B. LCD-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimedia-Objekten und dergleichen durch die Operationen des IoT-Gerätes 1050 erzeugt oder erstellt wird.
Eine Batterie 1076 kann das IoT-Gerät 1050 antreiben, obwohl in Beispielen, in welchen das IoT-Gerät 1050 an einem festen Standort installiert ist, dieses auch eine Stromversorgung aufweisen kann, die an ein Stromnetz gekoppelt ist. Die Batterie 1076 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie, wie z.B. eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
Ein Batteriemonitor/-ladegerät 1078 kann in dem IoT-Gerät 1050 enthalten sein, um den Ladezustand (SoCH - State of Charge) der Batterie 1076 zu verfolgen. Der/Das Batteriemonitor/-ladegerät 1078 kann auch zum Überwachen anderer Parameter der Batterie 1076 verwendet werden, um Ausfallvorhersagen bereitzustellen, wie z.B. den Erhaltungszustand (SoH - State of Health) und den Funktionszustand (SoF - State of Function) der Batterie 1076. Der/Das Batteriemonitor/-ladegerät 1078 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie z.B. eine LTC4020 oder eine LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor in Phoenix, Arizona, oder eine IC aus der UCD90xxx-Familie von Texas Instruments in Dallas, TX. Der/Das Batteriemonitor/-ladegerät 1078 kann die Informationen zu der Batterie 1076 über die Zwischenverbindung 1056 an den Prozessor 1052 kommunizieren. Der/Das Batteriemonitor/-ladegerät 1078 kann auch einen Analog-Digital-Wandler (ADC - Analog-to-Digital Converter) beinhalten, welcher dem Prozessor 1052 das direkte Überwachen der Spannung der Batterie 1076 oder des Stromflusses von der Batterie 1076 gestattet. Die Batterieparameter können zum Bestimmen von Aktionen, die das IoT-Gerät 1050 durchführen kann, wie z.B. Sendefrequenz, Mesh-Netzwerkoperation, Abtastfrequenz und dergleichen, verwendet werden.
Eine Stromversorgung 1080 oder eine andere Energiezuführung, die an ein Stromnetz gekoppelt ist, kann zum Laden der Batterie 1076 mit dem Batteriemonitor/-ladegerät 1078 gekoppelt sein. In einigen Beispielen kann die Stromversorgung 1080 durch einen drahtlosen Stromempfänger ersetzt sein, um den Strom drahtlos zu erhalten, zum Beispiel durch eine Rahmenantenne in dem IoT-Gerät 1050. Eine drahtlose Batterieladeschaltung, wie z.B., u.a., ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in dem Batteriemonitor/-ladegerät 1078 enthalten sein. Die gewählten spezifischen Ladeschaltungen hängen von der Größe der Batterie 1076 und somit vom erforderlichen Strom ab. Das Aufladen kann, u.a., unter Verwendung des Airfuel-Standards, veröffentlicht durch die Airfuel Alliance, des drahtlosen Qi-Ladestandards, veröffentlich durch das Wireless Power Consortium, oder des Rezence-Ladestandards, veröffentlicht durch die Alliance for Wireless Power, erfolgen.
Der Speicher 1058 kann Anweisungen 1082 in Form von Software-, Firmware- oder Hardware-Befehlen zum Implementieren der hierin beschriebenen Techniken beinhalten. Obwohl derartige Anweisungen 1082 als Codeblöcke, die in dem Arbeitsspeicher 1054 und dem Speicher 1058 enthalten sind, gezeigt sind, kann verstanden werden, dass jegliche der Codeblöcke durch Hardware-Schaltungen ersetzt sein können, zum Beispiel eingebaut in eine anwendungsspezifische integrierte Schaltung (ASIC - Application Specific Integrated Circuit).
In einem Beispiel können die Anweisungen 1082, die über den Arbeitsspeicher 1054, den Speicher 1058 oder den Prozessor 1052 bereitgestellt werden, als ein nichttransitorisches, maschinenlesbares Medium 1060 verkörpert sein, welches Code zum Steuern des Prozessors 1052 zum Durchführen elektronischer Operationen in dem IoT-Gerät 1050 beinhaltet. Der Prozessor 1052 kann über die Zwischenverbindung 1056 auf das nichttransitorische, maschinenlesbare Medium 1060 zugreifen. Zum Beispiel kann das nichttransitorische, maschinenlesbare Medium 1060 durch Geräte verkörpert sein, die für den Speicher 1058 von 10 beschrieben sind, oder kann spezifische Speichereinheiten aufweisen, wie z.B. optische Platten, Flashlaufwerke oder jegliche Zahl anderer Hardware-Geräte. Das nichttransitorische, maschinenlesbare Medium 1060 kann Anweisungen zum Steuern des Prozessors 1052 zum Durchführen einer/s spezifischen Aktionssequenz oder -flusses beinhalten, zum Beispiel wie in Bezug auf das/die Flussdiagramm(e) und Blockdiagramm(e) der oben gezeigten Operationen und Funktionalität beschrieben.
Nun wird auf 11 Bezug genommen, in welcher ein Blockdiagramm eines Computergerätes, das für Praxisaspekte der vorliegenden Offenbarung geeignet ist, in Übereinstimmung mit verschiedenen Ausführungsformen veranschaulicht wird. Wie gezeigt wird, kann das Computergerät 1100 in Ausführungsformen einen oder mehrere Prozessoren 1102, wie zum Beispiel einen INTEL® XEON®- oder ATOM®-Prozessor, und den Systemspeicher 1104 beinhalten. Jeder Prozessor 1102 kann einen oder mehrere Prozessorkerne aufweisen. In Ausführungsformen können ein oder mehrere Prozessoren 1102 einen oder mehrere Hardware-Beschleuniger (wie z.B. ein FPGA) beinhalten. Der Systemspeicher 1104 kann jeglichen bekannten flüchtigen oder nichtflüchtigen Arbeitsspeicher beinhalten. Außerdem kann das Computergerät 1100 das/die Massenspeichergerät(e) 1106 (wie z.B. Solid-State-Laufwerke), die Eingabe/Ausgabe-Geräteschnittstelle 1108 (zur Schnittstellenbildung z.B. mit Sensoren) und die Kommunikationsschnittstellen 1110 (wie z.B. Netzwerkschnittstellenkarten, Modems und so weiter, zur Schnittstellenbildung z.B. mit Geräten, die mit dem Eigentümer, Fahrer oder Mitfahrer des A/SA-Fahrzeugs assoziiert sind) aufweisen. Die Elemente können über den Systembus 1112 aneinandergekoppelt sein, welcher einen oder mehrere Busse darstellen kann. Im Fall von mehreren Bussen können diese durch eine oder mehrere Busbrücken (nicht gezeigt) überbrückt sein.
Jedes dieser Elemente kann seine herkömmlichen, in der Technik bekannten Funktionen durchführen. Insbesondere können der Systemspeicher 1104 und das/die Massenspeichergerät(e) 1106 zum Speichern einer Arbeitskopie und einer permanenten Kopie des ausführbaren Codes der Programmierungsanweisungen, welche die zuvor beschriebenen Operationen implementieren, eingesetzt werden, einschließlich, jedoch nicht darauf beschränkt, Operationen im Zusammenhang mit dem Verteilen und Durchführen von Berechnungsaufgaben in CA/AD-Fahrzeugen, die zuvor in Bezug auf 8 und 9, das CA/AD-System von 7, die Hosting-Plattform 509 und/oder den Arbeitslast-Auslagerungs- oder -Verteilungsdienst 527 beschrieben wurden, sowie der Berechnungsaufgaben und ihren assoziierten Daten, gemeinsam bezeichnet als Berechnungslogik und/oder -daten 1122. In einer Ausführungsform kann das Arbeitslastauslagerungssystem über die Kommunikationsschnittstellen 1110 mehrere Hosting-Profile empfangen, wobei jedes der mehreren Hosting-Profile ein Ressourcenprofil beinhaltet, welches Ressourcen der mehreren CA/AD-Fahrzeuge kombiniert. In Ausführungsformen können die Hosting-Profile Daten, die zumindest teilweise auf Verlaufsrouten, Energieverbrauch und einer Inhaltssammlung basieren, entsprechend des einen oder der mehreren der CA/AD-Fahrzeuge aus den mehreren Fahrzeugen beinhalten. In Ausführungsformen kann sich die Inhaltssammlung auf Inhalt beziehen, der durch einen oder mehrere Sensoren gesammelt wird.
In Ausführungsformen können die Kommunikationsschnittstellen 1110 die Kunden-Arbeitslast und die mehreren Hosting-Profile an den Prozessor bereitstellen, wobei der Prozessor die Kunden-Arbeitslast und die mehreren Hosting-Profile analysieren soll und, zumindest teilweise basierend auf der Analyse, die Kunden-Arbeitslast an ausgewählte mehrere CA/AD-Fahrzeuge, die einem ausgewählten Hosting-Profil entsprechen, zuweisen soll. Die Programmierungsanweisungen können Assembler-Anweisungen, die durch den/die Prozessor(en) 1102 unterstützt werden, oder Hochsprachen, wie zum Beispiel C, die in derartige Anweisungen kompiliert werden können, umfassen. In Ausführungsformen können einige der Funktionen, die durch die Berechnungsmaschine oder Verarbeitungseinheit 704 von 7 durchgeführt werden, stattdessen mit einem Hardware-Prozessor 1103 implementiert werden. In Ausführungsformen können ein oder mehrere Prozessoren 1102, der Systemspeicher 1104 und/oder die Massenspeichergeräte 1106 in einem Container oder Schutzbereich enthalten sein, um Berechnungen im Zusammenhang mit einer verteilten Arbeitsaufgabe, wie in Bezug auf 5-9 diskutiert, zu isolieren.
Die permanente Kopie des ausführbaren Codes der Programmierungsanweisungen und/oder die Bitströme zum Konfigurieren des Hardware-Beschleunigers 1103 können bereits im Werk in dem/den permanenten Massenspeichergerät(en) 1106 oder dem Hardware-Beschleuniger 1103 platziert werden, oder vor Ort, zum Beispiel durch ein Verteilungsmedium (nicht gezeigt), wie z.B. eine CD, oder über die Kommunikationsschnittstelle 1110 (von einem Verteilungsserver (nicht gezeigt)).
Nun wird auf 12 Bezug genommen, in welcher ein beispielhaftes nichttransitorisches, computerlesbares Speichermedium mit darauf konfigurierten Anweisungen zur praktischen Umsetzung aller oder ausgewählter der Operationen im Zusammenhang mit dem Zuweisen und/oder Durchführen von Arbeit an einer verteilten Berechnungsaufgabe durch ein zuvor beschriebenes CA/AD-System oder -Fahrzeug in Übereinstimmung mit verschiedenen Ausführungsformen gezeigt wird. Wie veranschaulicht wird, kann das nichttransitorische, computerlesbare Speichermedium 1202 den ausführbaren Code einer Reihe von Programmierungsanweisungen 1204 beinhalten. Der ausführbare Code der Programmierungsanweisungen 1204 kann dazu konfiguriert sein, es einem System, z.B. dem CA/AD-System 700 oder dem Computersystem 1100, als Reaktion auf die Ausführung des ausführbaren Codes/der Programmierungsanweisungen zu ermöglichen, z.B. verschiedene Operationen im Zusammenhang mit 5-9 durchzuführen. In alternativen Ausführungsformen kann/können sich der/die ausführbare Code/Programmierungsanweisungen 1204 stattdessen auf mehreren nichttransitorischen, computerlesbaren Speichermedien 1202 befinden. In wieder anderen Ausführungsformen kann/können der/die ausführbare Code/Programmierungsanweisungen 1204 in einem transitorischen, computerlesbaren Medium, wie z.B. Signalen, codiert sein.
In Ausführungsformen kann ein Prozessor zusammen mit einem computerlesbaren Speichermedium gepackt sein, welches einen Teil des oder den gesamten ausführbaren Code der Programmierungsanweisungen 1204 aufweist, die zur praktischen Implementierung aller oder ausgewählter der zuvor in Bezug auf 5-9 beschriebenen Operationen konfiguriert sind. Für eine Ausführungsform kann ein Prozessor zusammen mit derartigem ausführbarem Code 1204 gepackt sein, um ein SiP (System in Package) zu bilden. Für eine Ausführungsform kann ein Prozessor auf dem gleichen Chip mit einem computerlesbaren Speichermedium, das derartigen ausführbaren Code 1204 aufweist, integriert sein. Für eine Ausführungsform kann ein Prozessor zusammen mit einem computerlesbaren Speichermedium, das derartigen ausführbaren Code 1204 aufweist, gepackt sein, um ein SoC (System on Chip) zu bilden. Für mindestens eine Ausführungsform kann das SoC z.B. in dem CA/AD-System 700 genutzt werden.
Somit wurde ein/e verbesserte/s Verfahren und Vorrichtung für autonomes oder semiautonomes Parken beschrieben. Der Ansatz kann für Elektrofahrzeuge mit Batterien, wie z.B. Li-Ionen-Batterien, besonders hilfreich sein, deren Nutzungsdauer empfindlich gegenüber der Temperatur ihrer Betriebsbedingungen ist.
Beispiel 1 ist eine Vorrichtung zur Durchführung einer Berechnungsaufgabe, welche eine Kommunikationsschnittstelle, die in einem CA/AD (Computer-Assisted/Autonomous Driving - computergestütztes/autonomes Fahren) -Fahrzeug angeordnet ist, zum Empfangen der Berechnungsaufgabe, wobei die Berechnungsaufgabe Teil einer Sammlung verteilter Berechnungsaufgaben ist, die dem CA/AD-Fahrzeug oder anderen Berechnungsvorrichtungen zugewiesen werden, und jede Berechnungsaufgabe zumindest teilweise basierend auf Ressourcen, die dem CA/AD-Fahrzeug und den anderen Berechnungsvorrichtungen zur Verfügung stehen, evaluiert wird; und eine Verarbeitungseinheit, die in dem CA/AD-Fahrzeug angeordnet und mit der Kommunikationsschnittstelle gekoppelt ist, zum Empfangen der Berechnungsaufgabe von der Kommunikationsschnittstelle und zum Durchführen der Berechnungsaufgabe zumindest teilweise unter Verwendung der verfügbaren Ressourcen des CA/AD-Fahrzeugs umfasst.
Beispiel 2 ist die Vorrichtung von Beispiel 1, wobei mindestens eine der anderen Berechnungsvorrichtungen ein anderes CA/AD-Fahrzeug ist, das in mehreren CA/AD-Fahrzeugen enthalten ist.
Beispiel 3 ist die Vorrichtung von Beispiel 2, wobei zu den Ressourcen, die dem CA/AD-Fahrzeug und dem mindestens einen anderen CA/AD-Fahrzeug zur Verfügung stehen, Berechnungssystemressourcen und/oder Sensordatenressourcen zählen.
Beispiel 4 ist die Vorrichtung von Beispiel 3, wobei zu den Berechnungssystemressourcen ein ausgewähltes eines oder mehrere von verfügbarer/m Rechenleistung, Speicher und vertrauenswürdiger Hardware zählen und Informationen in Bezug auf die Berechnungssystemressourcen in einem Berechnungssystemressourcenprofil eines entsprechenden CA/AD-Fahrzeugs enthalten sind.
Beispiel 5 ist die Vorrichtung von Beispiel 3, wobei zu den Sensordatenressourcen Ressourcen in Bezug auf Externalitäten, die durch Sensoren des CA/AD-Fahrzeugs oder des mindestens einen anderen CA/AD-Fahrzeugs erkannt werden, zählen und sich diese auf eine Netzwerkkonnektivität, einen Standort oder einen vorhersagbaren Standort beziehen, und wobei Informationen in Bezug auf die Sensordatenressourcen in einem Sensordatenressourcenprofil eines entsprechenden CA/AD-Fahrzeugs enthalten sind.
Beispiel 6 ist die Vorrichtung von Beispiel 3, wobei die Kommunikationsschnittstelle zumindest teilweise basierend auf einer vorhersagbaren physischen Nähe zu dem mindestens einen anderen CA/AD-Fahrzeug und einer physischen Nähe zu einem Netzwerk mit hoher Bandbreite ein Netzwerk mit dem mindestens einen anderen CA/AD-Fahrzeug bilden soll, und wobei den CA/AD-Fahrzeugen eine ähnliche Arbeitslast in Bezug auf die Berechnungsaufgabe zugewiesen werden soll.
Beispiel 7 ist die Vorrichtung von Beispiel 6, wobei die Ressourcen der CA/AD-Fahrzeuge zur Verfügung stehen, wenn die CA/AD-Fahrzeuge geparkt sind.
Beispiel 8 ist die Vorrichtung von Beispiel 2, wobei jedes der CA/AD-Fahrzeuge einen Blockchain-Verarbeitungsknoten zur Unterstützung bei der Zusammenlegung und Pflege eines gemeinsamen Hosting-Profils zumindest teilweise basierend auf Ressourcenprofilen einzelner CA/AD-Fahrzeuge der mehreren CA/AD-Fahrzeuge umfasst.
Beispiel 9 ist die Vorrichtung von Beispiel 2, wobei die Verarbeitungseinheit ferner Verlaufsinformationen von dem mindestens einen anderen CA/AD-Fahrzeug empfangen soll und die Verlaufsinformationen zum Vorhersagen einer Verfügbarkeit der Ressourcen des mindestens einen anderen CA/AD-Fahrzeugs zum Unterstützen beim Paaren der CA/AD-Fahrzeuge zum gemeinsamen Durchführen der Berechnungsaufgaben analysieren soll.
Beispiel 10 ist die Vorrichtung von Beispiel 9, wobei die Verarbeitungseinheit zumindest teilweise basierend auf gemeinsamen Ressourcen und den Verlaufsinformationen ein Hosting-Profil an einem externen Server registrieren soll, um anzugeben, dass die mehreren CA/AD-Fahrzeuge zum Empfangen einer Arbeitslast von einem Kunden zur Verfügung stehen.
Beispiel 11 ist die Vorrichtung von Beispiel 10, wobei die Verarbeitungseinheit ferner Ressourcen der mehreren Fahrzeuge partitionieren soll, um anzugeben, dass die Gruppe zum Unterstützen mehrerer Arbeitslasten zur Verfügung steht.
Beispiel 12 ist die Vorrichtung von Beispiel 11, wobei die mehreren Arbeitslasten mehreren Containern entsprechen, wobei jeder Container eine entsprechende Arbeitslast einkapselt.
Beispiel 13 ist die Vorrichtung von einem der Beispiele 1-12, wobei die Vorrichtung ein computergestütztes oder autonomes Fahrsystem angeordnet in dem CA/AD-Fahrzeug ist und ferner zum Empfangen von Sensordaten, über die Kommunikationsschnittstelle, von Sensoren des CA/AD-Fahrzeugs in Bezug auf die Verfügbarkeit der CA/AD-Ressourcen gekoppelt ist, und wobei die Sensordaten mindestens eines aus Kameradaten, RADAR-Daten, LIDAR (Light Detection and Ranging) -Daten, Strahlungstemperaturdaten oder GPS (Global Positioning System) -Daten umfassen.
Beispiel 14 ist die Vorrichtung von einem der Beispiele 1-13, wobei die Vorrichtung das CA/AD-Fahrzeug ist und das autonome Fahrsystem und Fahrelemente gekoppelt an das autonome Fahrsystem, einschließlich eines oder mehrerer aus einem Motor, einem Elektromotor, einem Bremssystem, einem Antriebssystem, Rädern, einem Getriebe und einer Batterie, umfasst.
Beispiel 15 ist die Vorrichtung von einem der Beispiele 1-14, wobei die Verarbeitungseinheit ein feldprogrammierbares Gate-Array umfasst, das zumindest teilweise basierend auf einer Arbeitslast in Bezug auf die Berechnungsaufgabe programmierbar ist.
Beispiel 16 ist ein Verfahren zur Zuweisung einer Arbeitslast, welches Folgendes umfasst: Empfangen, an einem Arbeitslast-Managementserver, einer Kunden-Arbeitslastanfrage; Empfangen, an dem Arbeitslast-Managementserver, mehrerer Ressourcenprofile, die mehreren Hosting-Plattformen entsprechen, welche jeweils mehrere CA/AD-Fahrzeuge beinhalten; und Analysieren, durch den Arbeitslast-Managementserver, der Arbeitslastanfrage und der mehreren Ressourcenprofile; und Zuweisen einer Arbeitslast in Bezug auf die Arbeitslastanfrage zu einer ausgewählten Hosting-Plattform zumindest teilweise basierend auf der Analyse.
Beispiel 17 ist das Verfahren von Beispiel 16, wobei das Analysieren, durch den Arbeitslast-Managementserver, der Arbeitslastanfrage das Abgleichen von einem oder mehreren der mehreren Ressourcenprofile mit einer oder mehreren von mehreren Kunden-Arbeitslasten basierend auf Informationen in Bezug auf Ressourcen, welche mindestens eines aus einer vorhersagbar verfügbaren Energie, einer Berechnungsleistung, einem Speicher und Sensordaten beinhalten, beinhaltet.
Beispiel 18 ist das Verfahren von Beispiel 16, welches ferner das Senden von Informationen in Bezug auf die Arbeitslast an die ausgewählte Hosting-Plattform zur Durchführung der Arbeitslast durch die mehreren CA/AD-Fahrzeuge, die in der Hosting-Plattform enthalten sind, umfasst.
Beispiel 19 ist das Verfahren von Beispiel 16, welches ferner das Empfangen einer Authentifizierung von Ressourcen der CA/AD-Fahrzeuge aus den mehreren Fahrzeugen über einen Fernprüfungsnachweis umfasst.
Beispiel 20 ist mindestens ein computerlesbares Medium (CRM - Computer-Readable Medium), das mehrere Anweisungen umfasst, die dazu geeignet sind, ein computergestütztes oder autonomes Fahrsystem, das in einem Fahrzeug angeordnet ist, als Reaktion auf die Ausführung der Anweisungen zum Durchführen des Folgenden zu veranlassen: Angeben einer Verfügbarkeit zum Durchführen einer Berechnungsaufgabe; Empfangen der Berechnungsaufgabe, wobei die Berechnungsaufgabe eine verteilte Berechnungsaufgabe ist, die dem Fahrzeug zumindest teilweise basierend auf Ressourcen, die dem CA/AD-Fahrzeug und anderen Berechnungsvorrichtungen zur Verfügung stehen, zugewiesen wird; und Durchführen der Berechnungsaufgabe.
Beispiel 21 ist das CRM von Beispiel 20, wobei das Angeben der Verfügbarkeit zum Durchführen der Berechnungsaufgabe das Registrieren der Verfügbarkeit in einem Netzwerk aus mehreren anderen Fahrzeugen, die ähnlich zum Durchführen einer Arbeitslast in Bezug auf die Berechnungsaufgabe zur Verfügung stehen, umfasst.
Beispiel 22 ist das CRM von einem der Beispiele 20-21, welches ferner das Durchführen der Berechnungsaufgabe innerhalb einer vertrauenswürdigen Hardware-Umgebung umfasst.
Beispiel 23 ist ein Arbeitslastauslagerungssystem, welches Folgendes umfasst: einen Prozessor; einen Arbeitsspeicher; und eine Netzwerkschnittstelle, die an den Prozessor und den Arbeitsspeicher gekoppelt ist, die zu Folgendem ausgelegt ist: Empfangen einer Kunden-Arbeitslast; Empfangen mehrerer Hosting-Profile, wobei jedes der mehreren Hosting-Profile ein Ressourcenprofil beinhaltet, das Ressourcen von mehreren CA/AD-Fahrzeugen kombiniert; und Bereitstellen der Kunden-Arbeitslast und der mehreren Hosting-Profile an den Prozessor, wobei der Prozessor zu Folgendem ausgelegt ist: Analysieren der Kunden-Arbeitslast und der mehreren Hosting-Profile; und, zumindest teilweise basierend auf der Analyse, Zuweisen der Kunden-Arbeitslast an ausgewählte mehrere CA/AD-Fahrzeuge, die einem ausgewählten Hosting-Profil entsprechen.
Beispiel 24 ist das Arbeitslastauslagerungssystem von Beispiel 23, welches einen entfernten Server, der sich in einem EDGE (Enhanced Data for Global System for Mobile Communications) -Netzwerk befindet, umfasst und ferner die CA/AD-Fahrzeuge umfasst, die kommunikativ an den entfernten Server gekoppelt sind.
Beispiel 25 ist das Arbeitslastauslagerungssystem von einem der Beispiele 23-24, wobei die Netzwerkschnittstelle ferner abgeschlossene Arbeit in Bezug auf die Kunden-Arbeitslast von einem oder mehreren der CA/AD-Fahrzeuge empfangen soll und Daten in Bezug auf eine Zahlung an einen Eigentümer von einem oder mehreren der CA/AD-Fahrzeuge aus den mehreren Fahrzeugen senden soll.
Beispiel 26 ist eine Vorrichtung, welche Mittel für Folgendes beinhaltet: Empfangen einer Kunden-Arbeitslastanfrage; Empfangen mehrerer Ressourcenprofile, die mehreren Hosting-Plattformen entsprechen, welche jeweils mehrere CA/AD-Fahrzeuge beinhalten; Analysieren der Arbeitslastanfrage und der mehreren Ressourcenprofile; und, zumindest teilweise basierend auf der Analyse, Zuweisen einer Arbeitslast in Bezug auf die Arbeitslastanfrage an eine ausgewählte Hosting-Plattform.
Beispiel 27 ist die Vorrichtung von Beispiel 26, welche ferner Mittel zum Empfangen einer Authentifizierung von Ressourcen der CA/AD-Fahrzeuge aus den mehreren Fahrzeugen über einen Fernprüfungsnachweis umfasst.
Obwohl hierin zum Zweck der Beschreibung bestimmte Ausführungsformen veranschaulicht und beschrieben wurden, kann eine breite Vielfalt alternativer und/oder äquivalenter Ausführungsformen oder Implementierungen, kalkuliert zum Erfüllen der gleichen Zwecke, die gezeigten und beschriebenen Ausführungsformen ersetzen, ohne sich vom Umfang der vorliegenden Offenbarung zu entfernen. Diese Anmeldung soll jegliche Anpassungen oder Variationen der hierin diskutierten Ausführungsformen abdecken. Daher ist eindeutig beabsichtigt, dass die hierin beschriebenen Ausführungsformen lediglich durch die Ansprüche begrenzt sein sollen.
Wo die Offenbarung „ein“ oder „ein erstes“ Element oder das Äquivalent davon wiedergibt, beinhaltet eine derartige Offenbarung ein oder mehrere derartige Elemente, wobei zwei oder mehr derartige Elemente weder erforderlich noch ausgeschlossen sind. Ferner werden Ordnungszahlindikatoren (z.B. erste/r/s, zweite/r/s oder dritte/r/s) für identifizierte Elemente zur Unterscheidung zwischen den Elementen verwendet und geben weder eine erforderliche oder begrenzte Zahl derartiger Elemente an oder implizieren eine solche noch geben sie eine bestimmte Position oder Reihenfolge derartiger Elemente an, es sei denn etwas anderes ist spezifisch angegeben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 16/023637 [0001]

Claims

Vorrichtung zur Durchführung einer Berechnungsaufgabe, welche Folgendes umfasst: eine Kommunikationsschnittstelle, die in einem CA/AD (Computer-Assisted/Autonomous Driving - computergestütztes/autonomes Fahren) -Fahrzeug angeordnet ist, zum Empfangen der Berechnungsaufgabe, wobei die Berechnungsaufgabe Teil einer Sammlung verteilter Berechnungsaufgaben ist, die dem CA/AD-Fahrzeug oder anderen Berechnungsvorrichtungen zugewiesen werden, und jede Berechnungsaufgabe zumindest teilweise basierend auf Ressourcen, die dem CA/AD-Fahrzeug und den anderen Berechnungsvorrichtungen zur Verfügung stehen, evaluiert wird; und eine Verarbeitungseinheit, die in dem CA/AD-Fahrzeug angeordnet und mit der Kommunikationsschnittstelle gekoppelt ist, zum Empfangen der Berechnungsaufgabe von der Kommunikationsschnittstelle und zum Durchführen der Berechnungsaufgabe zumindest teilweise unter Verwendung der verfügbaren Ressourcen des CA/AD-Fahrzeugs.
Vorrichtung nach Anspruch 1, wobei mindestens eine der anderen Berechnungsvorrichtungen ein anderes CA/AD-Fahrzeug ist, das in mehreren CA/AD-Fahrzeugen enthalten ist.
Vorrichtung nach Anspruch 2, wobei zu den Ressourcen, die dem CA/AD-Fahrzeug und dem mindestens einen anderen CA/AD-Fahrzeug zur Verfügung stehen, Berechnungssystemressourcen und/oder Sensordatenressourcen zählen.
Vorrichtung nach Anspruch 3, wobei zu den Berechnungssystemressourcen ein ausgewähltes eines oder mehrere von verfügbarer/m Rechenleistung, Speicher und vertrauenswürdiger Hardware zählen und Informationen in Bezug auf die Berechnungssystemressourcen in einem Berechnungssystemressourcenprofil eines entsprechenden CA/AD-Fahrzeugs enthalten sind.
Vorrichtung nach Anspruch 3, wobei zu den Sensordatenressourcen Ressourcen in Bezug auf Externalitäten, die durch Sensoren des CA/AD-Fahrzeugs oder des mindestens einen anderen CA/AD-Fahrzeugs erkannt werden, zählen und sich diese auf eine Netzwerkkonnektivität, einen Standort oder einen vorhersagbaren Standort beziehen, und wobei Informationen in Bezug auf die Sensordatenressourcen in einem Sensordatenressourcenprofil eines entsprechenden CA/AD-Fahrzeugs enthalten sind.
Vorrichtung nach Anspruch 3, wobei die Kommunikationsschnittstelle zumindest teilweise basierend auf einer vorhersagbaren physischen Nähe zu dem mindestens einen anderen CA/AD-Fahrzeug und einer physischen Nähe zu einem Netzwerk mit hoher Bandbreite ein Netzwerk mit dem mindestens einen anderen CA/AD-Fahrzeug bilden soll, und wobei den CA/AD-Fahrzeugen eine ähnliche Arbeitslast in Bezug auf die Berechnungsaufgabe zugewiesen werden soll.
Vorrichtung nach Anspruch 6, wobei die Ressourcen der CA/AD-Fahrzeuge zur Verfügung stehen, wenn die CA/AD-Fahrzeuge geparkt sind.
Vorrichtung nach Anspruch 2, wobei jedes der CA/AD-Fahrzeuge einen Blockchain-Verarbeitungsknoten zur Unterstützung bei der Zusammenlegung und Pflege eines gemeinsamen Hosting-Profils zumindest teilweise basierend auf Ressourcenprofilen einzelner CA/AD-Fahrzeuge der mehreren CA/AD-Fahrzeuge umfasst.
Vorrichtung nach Anspruch 2, wobei die Verarbeitungseinheit ferner Verlaufsinformationen von dem mindestens einen anderen CA/AD-Fahrzeug empfangen soll und die Verlaufsinformationen zum Vorhersagen einer Verfügbarkeit der Ressourcen des mindestens einen anderen CA/AD-Fahrzeugs zum Unterstützen beim Paaren der CA/AD-Fahrzeuge zum gemeinsamen Durchführen der Berechnungsaufgaben analysieren soll.
Vorrichtung nach Anspruch 9, wobei die Verarbeitungseinheit zumindest teilweise basierend auf gemeinsamen Ressourcen und den Verlaufsinformationen ein Hosting-Profil an einem externen Server registrieren soll, um anzugeben, dass die mehreren CA/AD-Fahrzeuge zum Empfangen einer Arbeitslast von einem Kunden zur Verfügung stehen.
Vorrichtung nach Anspruch 10, wobei die Verarbeitungseinheit ferner Ressourcen der mehreren Fahrzeuge partitionieren soll, um anzugeben, dass die Gruppe zum Unterstützen mehrerer Arbeitslasten zur Verfügung steht.
Vorrichtung nach Anspruch 11, wobei die mehreren Arbeitslasten mehreren Containern entsprechen, wobei jeder Container eine entsprechende Arbeitslast einkapselt.
Vorrichtung nach Anspruch 1, wobei die Verarbeitungseinheit ein feldprogrammierbares Gate-Array umfasst, das zumindest teilweise basierend auf einer Arbeitslast in Bezug auf die Berechnungsaufgabe programmierbar ist.
Vorrichtung nach einem der Ansprüche 1-13, wobei die Vorrichtung ein computergestütztes oder autonomes Fahrsystem angeordnet in dem CA/AD-Fahrzeug ist und ferner zum Empfangen von Sensordaten, über die Kommunikationsschnittstelle, von Sensoren des CA/AD-Fahrzeugs in Bezug auf die Verfügbarkeit der CA/AD-Ressourcen gekoppelt ist, und wobei die Sensordaten mindestens eines aus Kameradaten, RADAR-Daten, LIDAR (Light Detection and Ranging) -Daten, Strahlungstemperaturdaten oder GPS (Global Positioning System) -Daten umfassen.
Vorrichtung nach Anspruch 14, wobei die Vorrichtung das CA/AD-Fahrzeug ist und das autonome Fahrsystem und Fahrelemente gekoppelt an das autonome Fahrsystem, einschließlich eines oder mehrerer aus einem Motor, einem Elektromotor, einem Bremssystem, einem Antriebssystem, Rädern, einem Getriebe und einer Batterie, umfasst.
Verfahren zur Zuweisung einer Arbeitslast, welches Folgendes umfasst: Empfangen, an einem Arbeitslast-Managementserver, einer Kunden-Arbeitslastanfrage; Empfangen, an dem Arbeitslast-Managementserver, mehrerer Ressourcenprofile, die mehreren Hosting-Plattformen entsprechen, welche jeweils mehrere CA/AD-Fahrzeuge beinhalten; und Analysieren, durch den Arbeitslast-Managementserver, der Arbeitslastanfrage und der mehreren Ressourcenprofile; und Zuweisen einer Arbeitslast in Bezug auf die Arbeitslastanfrage zu einer ausgewählten Hosting-Plattform zumindest teilweise basierend auf der Analyse.
Verfahren nach Anspruch 16, wobei das Analysieren, durch den Arbeitslast-Managementserver, der Arbeitslastanfrage das Abgleichen von einem oder mehreren der mehreren Ressourcenprofile mit einer oder mehreren von mehreren Kunden-Arbeitslasten basierend auf Informationen in Bezug auf Ressourcen, welche mindestens eines aus einer vorhersagbar verfügbaren Energie, einer Berechnungsleistung, einem Speicher und Sensordaten beinhalten, beinhaltet.
Verfahren nach Anspruch 16, welches ferner das Senden von Informationen in Bezug auf die Arbeitslast an die ausgewählte Hosting-Plattform zur Durchführung der Arbeitslast durch die mehreren CA/AD-Fahrzeuge, die in der Hosting-Plattform enthalten sind, umfasst.
Verfahren nach Anspruch 16, welches ferner das Empfangen einer Authentifizierung von Ressourcen der CA/AD-Fahrzeuge aus den mehreren Fahrzeugen über einen Fernprüfungsnachweis umfasst.
Computerlesbares Medium (CRM - Computer-Readable Medium) bzw. computerlesbare Medien, das mehrere Anweisungen umfasst, die dazu geeignet sind, ein computergestütztes oder autonomes Fahrsystem, das in einem Fahrzeug angeordnet ist, als Reaktion auf die Ausführung der Anweisungen zum Durchführen des Verfahrens nach einem der Ansprüche 16-19 zu veranlassen.
Arbeitslastauslagerungssystem, welches Folgendes umfasst: einen Prozessor; einen Arbeitsspeicher; und eine Netzwerkschnittstelle, die an den Prozessor und den Arbeitsspeicher gekoppelt ist, die zu Folgendem ausgelegt ist: Empfangen einer Kunden-Arbeitslast; Empfangen mehrerer Hosting-Profile, wobei jedes der mehreren Hosting-Profile ein Ressourcenprofil beinhaltet, das Ressourcen von mehreren CA/AD-Fahrzeugen kombiniert; und Bereitstellen der Kunden-Arbeitslast und der mehreren Hosting-Profile an den Prozessor, wobei der Prozessor zu Folgendem ausgelegt ist: Analysieren der Kunden-Arbeitslast und der mehreren Hosting-Profile; und zumindest teilweise basierend auf der Analyse, Zuweisen der Kunden-Arbeitslast an ausgewählte mehrere CA/AD-Fahrzeuge, die einem ausgewählten Hosting-Profil entsprechen.
Arbeitslastauslagerungssystem nach Anspruch 21, welches einen entfernten Server, der sich in einem EDGE (Enhanced Data for Global System for Mobile Communications) -Netzwerk befindet, umfasst und ferner die CA/AD-Fahrzeuge umfasst, die kommunikativ an den entfernten Server gekoppelt sind.
Arbeitslastauslagerungssystem nach einem der Ansprüche 21-22, wobei die Netzwerkschnittstelle ferner abgeschlossene Arbeit in Bezug auf die Kunden-Arbeitslast von einem oder mehreren der CA/AD-Fahrzeuge empfangen soll und Daten in Bezug auf eine Zahlung an einen Eigentümer von einem oder mehreren der CA/AD-Fahrzeuge aus den mehreren Fahrzeugen senden soll.
Vorrichtung, welche Mittel für Folgendes umfasst: Empfangen einer Kunden-Arbeitslastanfrage; Empfangen mehrerer Ressourcenprofile, die mehreren Hosting-Plattformen entsprechen, welche jeweils mehrere CA/AD-Fahrzeuge beinhalten; Analysieren der Arbeitslastanfrage und der mehreren Ressourcenprofile; und Zuweisen einer Arbeitslast in Bezug auf die Arbeitslastanfrage zu einer ausgewählten Hosting-Plattform zumindest teilweise basierend auf der Analyse.
Vorrichtung nach Anspruch 24, welche ferner Folgendes umfasst: Mittel zum Empfangen einer Authentifizierung von Ressourcen der CA/AD-Fahrzeuge aus den mehreren Fahrzeugen über einen Fernprüfungsnachweis.