DE102019121437A1 - Modulare konfigurierbare Plattformarchitektur für CA/AD-Fahrzeuge - Google Patents

Modulare konfigurierbare Plattformarchitektur für CA/AD-Fahrzeuge Download PDF

Info

Publication number
DE102019121437A1
DE102019121437A1 DE102019121437.8A DE102019121437A DE102019121437A1 DE 102019121437 A1 DE102019121437 A1 DE 102019121437A1 DE 102019121437 A DE102019121437 A DE 102019121437A DE 102019121437 A1 DE102019121437 A1 DE 102019121437A1
Authority
DE
Germany
Prior art keywords
vehicle
uavs
uav
specific use
docking
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019121437.8A
Other languages
English (en)
Inventor
Divya Vijayaraghavan
Nageen Himayat
Florence Pon
Fatema Adenwala
Ankitha Chandran
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102019121437A1 publication Critical patent/DE102019121437A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/10—Simultaneous control of position or course in three dimensions
    • G05D1/101—Simultaneous control of position or course in three dimensions specially adapted for aircraft
    • G05D1/102—Simultaneous control of position or course in three dimensions specially adapted for aircraft specially adapted for vertical take-off of aircraft
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60P—VEHICLES ADAPTED FOR LOAD TRANSPORTATION OR TO TRANSPORT, TO CARRY, OR TO COMPRISE SPECIAL LOADS OR OBJECTS
    • B60P3/00—Vehicles adapted to transport, to carry or to comprise special loads or objects
    • B60P3/06—Vehicles adapted to transport, to carry or to comprise special loads or objects for carrying vehicles
    • B60P3/11—Vehicles adapted to transport, to carry or to comprise special loads or objects for carrying vehicles for carrying aircraft
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00—Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64C—AEROPLANES; HELICOPTERS
    • B64C39/00—Aircraft not otherwise provided for
    • B64C39/02—Aircraft not otherwise provided for characterised by special use
    • B64C39/024—Aircraft not otherwise provided for characterised by special use of the remote controlled vehicle type, i.e. RPV
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U70/00—Launching, take-off or landing arrangements
    • B64U70/90—Launching from or landing on platforms
    • B64U70/92—Portable platforms
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/0088—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots characterized by the autonomous decision making process, e.g. artificial intelligence, predefined behaviours
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61G—TRANSPORT, PERSONAL CONVEYANCES, OR ACCOMMODATION SPECIALLY ADAPTED FOR PATIENTS OR DISABLED PERSONS; OPERATING TABLES OR CHAIRS; CHAIRS FOR DENTISTRY; FUNERAL DEVICES
    • A61G3/00—Ambulance aspects of vehicles; Vehicles with special provisions for transporting patients or disabled persons, or their personal conveyances, e.g. for facilitating access of, or for loading, wheelchairs
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U10/00—Type of UAV
    • B64U10/10—Rotorcrafts
    • B64U10/13—Flying platforms
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U2101/00—UAVs specially adapted for particular uses or applications
    • B64U2101/20—UAVs specially adapted for particular uses or applications for use as communications relays, e.g. high-altitude platforms
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U2101/00—UAVs specially adapted for particular uses or applications
    • B64U2101/30—UAVs specially adapted for particular uses or applications for imaging, photography or videography
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U2101/00—UAVs specially adapted for particular uses or applications
    • B64U2101/30—UAVs specially adapted for particular uses or applications for imaging, photography or videography
    • B64U2101/31—UAVs specially adapted for particular uses or applications for imaging, photography or videography for surveillance
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U2101/00—UAVs specially adapted for particular uses or applications
    • B64U2101/60—UAVs specially adapted for particular uses or applications for transporting passengers; for transporting goods other than weapons
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U2201/00—UAVs characterised by their flight controls
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U30/00—Means for producing lift; Empennages; Arrangements thereof
    • B64U30/20—Rotors; Rotor supports
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B64—AIRCRAFT; AVIATION; COSMONAUTICS
    • B64U—UNMANNED AERIAL VEHICLES [UAV]; EQUIPMENT THEREFOR
    • B64U80/00—Transport or storage specially adapted for UAVs
    • B64U80/80—Transport or storage specially adapted for UAVs by vehicles
    • B64U80/86—Land vehicles

Landscapes

  • Engineering & Computer Science (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Automation & Control Theory (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Remote Sensing (AREA)
  • Health & Medical Sciences (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Public Health (AREA)
  • Business, Economics & Management (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Game Theory and Decision Science (AREA)
  • Medical Informatics (AREA)
  • Traffic Control Systems (AREA)

Abstract

Bei Ausführungsformen beinhaltet ein CA/AD-Fahrzeug (CA/AD: computer-assisted or autonomous driving - computergestütztes oder autonomes Fahren) eine Andockplattform, um ein oder mehrere unbemannte Luftfahrzeuge (UAVs) unterschiedlicher Typen zum Andocken an dem CA/AD-Fahrzeug zu empfangen, wobei jedes UAV mindestens einen Sensor beinhaltet, der für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet ist, und eine UAV-Schnittstelle, um mit dem einen oder den mehreren angedockten UAVs zu kommunizieren, einschließlich zum Empfangen von Sensordaten, die durch das eine oder die mehreren UAVs erhalten werden. Bei Ausführungsformen wird das CA/AD-Fahrzeug zumindest teilweise basierend auf dem einen oder den mehreren an dem CA/AD-Fahrzeug angedockten UAVs für eine spezifische Verwendung konfiguriert.

Description

  • Gebiet
  • Die vorliegende Offenbarung betrifft das Gebiet von computergestütztem oder autonomem Fahren (CA/AD: computer-assisted or autonomous driving). Genau gesagt betrifft die vorliegende Offenbarung ein Verfahren und eine Vorrichtung für eine modulare konfigurierbare Plattformarchitektur für CA/AD-Fahrzeuge.
  • Hintergrund
  • Für CA/AD-Fahrzeuge sind viele Verwendungen beabsichtigt. Viele dieser Verwendungen sind komplex und erfordern infolgedessen spezialisierte Werkzeuge und Sensoren sowie Hardware- und Softwareplattformen. Zukünftige Krankenwagen können zum Beispiel speziell konfigurierte CA/AD-Fahrzeuge sein, die einen Innenraum erfordern, der Notfall- und Erste-Hilfe-Ausrüstung unterstützt. Zusätzlich dazu können zum Beispiel zukünftige Taxis oder Schulbusse CA/AD-Fahrzeuge sein, deren Innenraum dazu eingerichtet ist, älteren Menschen, Kleinkindern, Kindern mit speziellen Bedürfnissen usw. zu dienen. Ein derartiges spezialisiertes Fahrzeug wird möglicherweise eine Erfassungsplattform benötigen, die für seine Umgebung und seinen Betriebsmodus zugeschnitten ist. Die für jeden spezialisierten Typ von CA/AD-Fahrzeug benötigten Anpassungen und Spezialisierungen erfordern eine erhebliche Investition für jedes CA/AD-Fahrzeug, die prohibitiv sein kann.
  • Figurenliste
    • 1 veranschaulicht einen Überblick für eine Umgebung zum Integrieren und Verwenden der konfigurierbaren Plattformarchitektur der vorliegenden Offenbarung gemäß verschiedenen Ausführungsformen.
    • 2 veranschaulicht ein beispielhaftes konfigurierbares modulares CA/AD-Fahrzeug gemäß verschiedenen Ausführungsformen.
    • 3 veranschaulicht eine beispielhafte Reihe von Nachrichten zwischen einem beispielhaften Dienstzentrum, einem beispielhaften konfigurierbaren CA/AD-Fahrzeug und zweckmäßigen unbemannten Luftfahrzeugen (UAVs: unmanned aerial vehicles) gemäß verschiedenen Ausführungsformen.
    • 4 veranschaulicht beispielhafte Ports, die in einem CA/AD-Fahrzeug zur Verbindung mit einem oder mehreren Hardwaremodulen bereitgestellt sind, gemäß verschiedenen Ausführungsformen.
    • 5 veranschaulicht ein beispielhaftes modulares CA/AD-Fahrzeug, das ursprünglich für den Betrieb in einem Taximodus konfiguriert war und als Reaktion auf eine Notfallsituation zum Arbeiten in einem Krankenwagenmodus geändert wird, gemäß verschiedenen Ausführungsformen.
    • 6 veranschaulicht einen Überblick für den Betriebsfluss eines Prozesses zum Empfangen eines ersten Auftragstyps, Arbeiten in einem ersten Betriebsmodus gemäß dem ersten Auftrag und, als Reaktion auf die Detektion einer Notfallbedingung, Rekonfigurieren für das Arbeiten in einem zweiten Betriebsmodus, gemäß verschiedenen Ausführungsformen.
    • 7 veranschaulicht einen Überblick für den Betriebsfluss eines Prozesses, damit ein CA/AD-Fahrzeug einen spezifischen Verwendungsauftrag empfängt, für den Auftrag konfiguriert wird und den Auftrag durchführt, gemäß verschiedenen Ausführungsformen.
    • 8 veranschaulicht ein beispielhaftes UAV einschließlich eines oder mehrerer Sensoren, um an einer an dem CA/AD-Fahrzeug bereitgestellten Plattform anzudocken, gemäß verschiedenen Ausführungsformen.
    • 9 veranschaulicht eine Softwarekomponentenansicht des konfigurierbaren Plattformverwaltungssystems gemäß verschiedenen Ausführungsformen.
    • 10 veranschaulicht eine Hardwarekomponentenansicht des konfigurierbaren Plattformverwaltungssystems gemäß verschiedenen Ausführungsformen.
    • 11 veranschaulicht ein Speicherungsmedium mit Anweisungen zum Umsetzen von Ausführungsformen der Prozesse der 3, 5, 6 und 7.
  • Ausführliche Beschreibung
  • Bei Ausführungsformen beinhaltet eine Vorrichtung zum computergestützten oder autonomen Fahren (CA/AD) eine an einem CA/AD-Fahrzeug angeordnete Andockplattform, um ein oder mehrere unbemannte Luftfahrzeuge (UAVs) unterschiedlicher Typen zum Andocken an dem CA/AD-Fahrzeug zu empfangen, wobei jedes UAV mindestens einen Sensor beinhaltet, der für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet ist, und eine an dem CA/AD-Fahrzeug angeordnete UAV-Schnittstelle, um mit dem einen oder den mehreren angedockten UAVs zu kommunizieren, einschließlich zum Empfangen von Sensordaten, die durch das eine oder die mehreren UAVs erhalten werden. Bei Ausführungsformen wird das CA/AD-Fahrzeug zumindest teilweise basierend auf dem einen oder den mehreren an dem CA/AD-Fahrzeug angedockten UAVs für eine spezifische Verwendung konfiguriert.
  • Bei Ausführungsformen beinhaltet ein Verfahren zum Betreiben eines dynamisch rekonfigurierbaren CA/AD Empfangen, durch das CA/AD-Fahrzeug, eines oder mehrerer UAVs unterschiedlicher Typen, die an dem CA/AD angedockt werden sollen, wobei jedes UAV einen oder mehrere Sensoren beinhaltet, die für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet sind, und Andocken des einen oder der mehreren UAVs an eine Andockplattform des CA/AD-Fahrzeugs. Das Verfahren beinhaltet ferner Verbinden des CA/AD-Fahrzeugs über eine UAV-Schnittstelle mit dem einen oder den mehreren UAVs, um Sensordaten des einen oder der mehreren Sensoren des einen oder der mehreren UAVs zu erhalten, wobei die Sensordaten beim Betrieb des CA/AD-Fahrzeugs gemäß der konfigurierbaren spezifischen Verwendung verwendet werden.
  • Bei Ausführungsformen beinhaltet ein UAV zum Konfigurieren eines CA/AD-Fahrzeugs (CA/AD: computergestütztes oder autonomes Fahren) einen oder mehrere Sensoren, die für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet sind; und einen Andockmechanismus zum sicheren Andocken des UAV an dem CA/AD-Fahrzeug. Bei Ausführungsformen wird das CA/AD-Fahrzeug zumindest teilweise basierend auf dem an dem CA/AD-Fahrzeug angedockten UAV für die spezifische Verwendung konfiguriert.
  • Bei Ausführungsformen beinhaltet ein System einen Satz von UAVs, wobei jedes UAV des Satzes einen oder mehrere Sensoren beinhaltet, die für eine spezifische Verwendung eines dynamisch rekonfigurierbaren CA/AD-Fahrzeugs ausgerichtet sind, und das dynamisch rekonfigurierbare CA/AD-Fahrzeug. Das CA/AD-Fahrzeug beinhaltet eine Andockplattform zum Andocken des Satzes von UAVs, sodass es für die spezifische Verwendung konfiguriert wird, und eine UAV-Schnittstelle zum Kommunizieren mit dem Satz von UAVs, einschließlich zum Empfangen von Sensordaten, die durch jedes der UAVs in dem Satz erhalten werden. Bei Ausführungsformen wird die spezifische Verwendung, für die das CA/AD konfiguriert ist, durch das Ersetzen des Satzes von angedockten UAVs mit einem anderen geändert.
  • In der folgenden Beschreibung wird Bezug auf die begleitenden Zeichnungen genommen, die einen Teil hiervon bilden, wobei gleiche Zahlen (oder gegebenenfalls die letzten beiden Ziffern einer Zahl eines Indexes) durchweg gleiche Teile bezeichnen, und in welchen durch Veranschaulichung Ausführungsformen gezeigt sind, die umgesetzt werden können. Es versteht sich, dass andere Ausführungsformen genutzt werden können und strukturelle oder logische Änderungen vorgenommen werden können, ohne von dem Schutzumfang der vorliegenden Offenbarung abzuweichen. Demzufolge ist die folgende ausführliche Beschreibung nicht in einem beschränkenden Sinne aufzufassen und ist der Schutzumfang von Ausführungsformen durch die angehängten Ansprüche und deren Äquivalente definiert.
  • Vorgänge verschiedener Verfahren können wiederum als mehrere diskrete Handlungen oder Vorgänge in einer Weise beschrieben sein, die außerordentlich hilfreich für das Verständnis des beanspruchten Gegenstands ist. Jedoch sollte die Reihenfolge der Beschreibung nicht derart ausgelegt werden, dass sie impliziert, dass diese Vorgänge unbedingt von der Reihenfolge abhängen. Insbesondere werden diese Vorgänge möglicherweise nicht in der Reihenfolge der Darstellung durchgeführt werden. Beschriebene Vorgänge werden möglicherweise in einer anderen Reihenfolge als in den beschriebenen Ausführungsformen ausgeführt. Verschiedene zusätzliche Vorgänge können durchgeführt werden und/oder beschriebene Vorgänge können in zusätzlichen Ausführungsformen weggelassen, geteilt oder kombiniert werden.
  • Zum Zwecke der vorliegenden Offenbarung bedeutet der Ausdruck „A und/oder B“ (A), (B) oder (A und B). Zum Zwecke 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 verwendet möglicherweise die Ausdrücke „bei einer Ausführungsform“ oder „bei Ausführungsformen“, die jeweils auf eine oder mehrere derselben oder verschiedene Ausführungsformen verweisen. Weiterhin sind die Begriffe „umfassend“, „einschließlich“, „aufweisend“ und dergleichen, wie sie mit Bezug auf Ausführungsformen der vorliegenden Offenbarung verwendet werden, synonym.
  • Außerdem wird angemerkt, dass Ausführungsformen als ein Prozess beschrieben werden können, der als ein Flussplan, ein Flussdiagramm, ein Datenflussdiagramm, ein Strukturdiagramm oder ein Blockdiagramm dargestellt wird. Obwohl ein Flussdiagramm die Vorgänge als einen sequenziellen Prozess beschreiben kann, können viele Vorgänge parallel, gleichlaufend oder gleichzeitig durchgeführt werden. Zusätzlich kann die Reihenfolge der Vorgänge umsortiert werden. Ein Prozess kann beendet werden, wenn seine Vorgänge abgeschlossen sind, kann aber auch zusätzliche Schritte aufweisen, die in der (den) Figur(en) nicht enthalten sind. Ein Prozess kann einem Verfahren, einer Funktion, einer Prozedur, einer Subroutine, einem Subprogramm und dergleichen entsprechen. Wenn ein Prozess einer Funktion entspricht, kann sein Abbruch einer Rückkehr der Funktion zu der Aufruffunktion und/oder der Hauptfunktion entsprechen. Des Weiteren kann ein Prozess durch Hardware, Software, Firmware, Middleware, Mikrocode, Hardwarebeschreibungssprachen oder einer beliebigen 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 einer Maschine oder einem computerlesbaren Medium gespeichert sein. Ein Codesegment kann eine Prozedur, eine Funktion, ein Unterprogramm, ein Programm, eine Routine, eine Subroutine, ein Modul, Programmcode, ein Softwarepaket, eine Klasse oder eine beliebige Kombination von Anweisungen, Datenstrukturen, Programmanweisungen und dergleichen repräsentieren.
  • Wie nachfolgend einschließlich in den Ansprüchen verwendet, kann sich der Begriff „Schaltkreis“ auf eine anwendungsspezifische integrierte Schaltung (ASIC - Application Specific Integrated Circuit), eine elektronische Schaltung, einen Prozessor (gemeinsam genutzt, dediziert oder als Gruppe) und/oder einen Speicher (gemeinsam genutzt, dediziert oder als Gruppe), die ein oder mehr Software- oder Firmware-Programme ausführen, eine kombinatorische Logikschaltung und/oder andere geeignete Hardwarekomponenten beziehen, ein Teil davon sein oder diese beinhalten, die die beschriebene Funktionalität bereitstellen. Bei manchen Ausführungsformen kann der Schaltkreis ein oder mehrere Software- oder Firmwaremodule implementieren oder mit dem Schaltkreis assoziierte Funktionen können durch diese implementiert werden.
  • Wie nachfolgend einschließlich in den Ansprüchen verwendet, kann der Begriff „Speicher“ eine oder mehrere Hardwareeinrichtungen zum Speichern von Daten repräsentieren, einschließlich Direktzugriffsspeicher (RAM), magnetischen RAM, Kernspeicher, Nurlesespeicher (ROM) magnetischen Plattenspeicherungsmedien, optischen Speicherungsmedien, Flash-Speichereinrichtungen und/oder anderen maschinenlesbaren Medien zum Speichern von Daten. Der Begriff „computerlesbares Medium“ kann unter anderem Speicher, portable oder feste Speicherungseinrichtungen, optische Speicherungseinrichtungen, Drahtloskanäle und verschiedene andere Medien beinhalten, die in der Lage sind, eine oder mehrere Anweisungen und/oder Daten zu speichern, zu enthalten oder zu führen.
  • Wie nachfolgend einschließlich in den Ansprüchen verwendet, kann der Begriff „Rechenplattform“ synonym als eine Computereinrichtung, eine Recheneinrichtung, eine Client-Einrichtung oder ein Client, ein Mobiltelefon, eine mobile Einheit, ein mobiles Endgerät, eine mobile Station, ein mobiler Benutzer, eine mobile Ausrüstung, eine Benutzerausrüstung (UE), ein Benutzerendgerät, eine Maschinentypkommunikation(MTC)-Einrichtung, eine Maschine-zu-Maschine(M2M)-Einrichtung, eine M2M-Ausrüstung (M2ME), eine Internet-der-Dinge(IoT)-Einrichtung, ein Teilnehmer, ein Benutzer, ein Empfänger usw. angesehen werden und kann nachfolgend gelegentlich als diese bezeichnet werden, und kann eine beliebige physische Hardwareeinrichtung beschreiben, die in der Lage ist, eine Sequenz von arithmetischen oder logischen Operationen sequenziell und automatisch auszuführen, dazu ausgestattet ist, Daten auf einem maschinenlesbaren Medium aufzuzeichnen/zu speichern und Daten von einer oder mehreren anderen Einrichtungen in einem Kommunikationsnetz zu übertragen und zu empfangen. Des Weiteren kann der Begriff „Rechenplattform“ einen beliebigen Typ von elektronischer Einrichtung beinhalten, wie etwa ein Zellulartelefon oder Smartphone, einen Tablet-Personal-Computer, eine tragbare Recheneinrichtung, einen autonomen Sensor, Personal Digital Assistants (PDAs), einen Laptop-Computer, einen Desktop-Personal-Computer, eine Videospielkonsole, einen digitalen Medien-Player, eine fahrzeuginterne Infotainment- (IVI) und/oder eine auto interne Entertainment(ICE)-Einrichtung, ein fahrzeuginternes Rechensystem, ein Navigationssystem, ein autonomes Fahrsystem, ein Fahrzeug-zu-Fahrzeug(V2V)-Kommunikationssystem, ein Fahrzeug-zu-Allem(V2X)-Kommunikationssystem, eine handgehaltene Messaging-Einrichtung, ein Personal Data Assistant, einen elektronischen Buch-Reader, eine Einrichtung mit erweiterter Realität und/oder eine beliebige andere gleichartige elektronische Einrichtung.
  • Wie nachfolgend einschließlich in den Ansprüchen verwendet, kann sich der Begriff „Verknüpfung“ oder „Kommunikationsverknüpfung“ auf ein beliebiges Übertragungsmedium beziehen, entweder greifbar oder nicht greifbar, das zum Kommunizieren von Daten oder eines Datenstroms verwendet wird. Zusätzlich dazu kann der Begriff „Verknüpfung“ synonym und/oder äquivalent zu „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugangskanal“, „Datenzugangskanal“, „Kanal“, „Datenverbindung“, „Funkverbindung“, „Träger“, „Hochfrequenzträger“ und/oder einem beliebigen anderen gleichartigen Begriff sein, der einen Pfad oder ein Medium bezeichnet, über den bzw. das Daten kommuniziert werden.
  • Unter Berücksichtigung der vielen Anwendungen, die ein CA/AD-Fahrzeug durchführen kann, ist bei Ausführungsformen ein modulares CA/AD-Fahrzeug bereitgestellt, das für mehrere Anwendungen, Betriebsmodi oder Aufgaben konfigurierbar ist. Das CA/AD kann zum Beispiel als ein „Krankenwagen als einen Dienst“-Fahrzeug verwendet werden, das einen Innenraum erfordert, der Notfall- und Erste-Hilfe-Ausrüstung unterstützt. Alternativ dazu kann das CA/AD-Fahrzeug konfiguriert sein, als ein regulärer oder spezialisierter Taxidienst zu arbeiten, wobei der Innenraum des Fahrzeugs sowie seine Betriebshardware und -software jeweils dazu ausgelegt sind, ältere Menschen, ein Kleinkind, Kinder mit speziellen Bedürfnissen oder dergleichen zu transportieren. Des Weiteren kann das CA/AD-Fahrzeug temporär mit verschiedenen Erfassungsplattformen ausgestattet werden, die für die Fahrzeugumgebung oder die durchzuführende Aufgabe in einer speziellen Konfiguration zugeschnitten sind. Zum Beispiel können bei schlechten Wetterbedingungen mehrere Sensoren verwendet werden oder zusätzliche, redundante oder präzisere Sensoren können bei dichten und/oder gefährlichen Umgebungen verwendet werden. Bei Ausführungsformen werden diese temporären Erweiterungen eines Basissensorarrays durch UAVs bereitgestellt, die an dem modularen CA/AD-Fahrzeug andocken und sich dann über eine UAV-Schnittstelle des Fahrzeugs mit einem bordinternen Verwaltungssystem des CA/AD-Fahrzeugs verbinden.
  • In dem Artikel Cognitive Internet cf Vehicles in Computer Communications 120 (2018) 58-70, durch Min Chen, et al. postulierten die Autoren das Konzept von CloV (Cognitive Internet of Vehicles - kognitives Internet von Fahrzeugen). CloV repräsentiert einen geschichteten Ansatz zur Gestaltung der verschiedenen in einem CA/AD-Fahrzeug durchgeführten Funktionen. CloV postuliert einen Stapel, der angefangen an der Unterseite Erfassungs-, Kommunikations-, Wahrnehmungs-, Steuerungs- und Anwendungsschichten beinhaltet. Der Meinung der Erfinder hiervon nach müssen sich CA/AD-Fahrzeuge hinsichtlich des konzeptuellen Frameworks von CloV dynamisch an jeder Schicht des CloV-Stapels anpassen, um Änderungen in der Umgebung und dem Fahrerstatus effektiv zu detektieren und darauf zu reagieren. Dies ist jedoch bis jetzt eine dringende Herausforderung für Anwender von CloV gewesen.
  • Somit ist bei Ausführungsformen eine modulare konfigurierbare Plattformarchitektur bereitgestellt, um die dringende Herausforderung für Echtzeit-Anpassungsfähigkeit in CA/AD-Fahrzeugen anzusprechen. Um defekte Sensoren und Hardware in Echtzeit auszutauschen sowie bestehende bordinterne Sensoren zu erweitern und nicht länger benötigte Sensorarrays zu entfernen, wenn ein Betriebsmodus des CA/AD-Fahrzeugs geändert wird, wird UAV-Technologie genutzt. Zusätzlich dazu wird FPGA-Technologie in Kombination mit einer oder mehreren CPUs verwendet, damit Arbeitsumfänge dynamisch hin und her getauscht werden, um Arbeitsumfangsbeschleunigung adaptiv zu priorisieren.
  • Jetzt unter Bezug auf 1, bei der ein Überblick für eine Umgebung zum Integrieren und Verwenden der modularen konfigurierbaren CA/AD-Fahrzeugtechnologie der vorliegenden Offenbarung gemäß verschiedenen Ausführungsformen veranschaulicht ist. Wie dargestellt, beinhaltet eine beispielhafte Umgebung 105 ein modulares Fahrzeug 152 mit einem Motor, einem Getriebe, Achsen, Rädern und so weiter. Des Weiteren beinhaltet das Fahrzeug 152 ein fahrzeuginternes Infotainment(IVI)-System 100 mit einer Anzahl von Infotainment-Untersystemen/-Anwendungen, z. B. Instrumentencluster-Untersystem/-Anwendungen, Vordersitz-Infotainment-Untersystem/-Anwendung, wie etwa ein Navigationsuntersystem/eine Navigationsanwendung, ein Medienuntersystem/eine Medienanwendung, ein Fahrzeugstatusuntersystem/eine Fahrzeugstatusanwendung und so weiter, und einer Anzahl von Rücksitz-Entertainment-Untersystemen/-Anwendungen.
  • Ferner ist das Fahrzeug 152 mit einem konfigurierbaren Plattformverwaltungssystem (CPM) 150 der vorliegenden Offenbarung ausgestattet, um dem Fahrzeug 152 eine computergestützte oder autonome Verwaltung bereitzustellen, einschließlich Empfangen eines operativen Auftrags von einem Dienstzentrum, um als Reaktion auf einen derartigen Auftrag konfiguriert oder rekonfiguriert zu werden, und Interagieren mit einem oder mehreren UAVs, die zum Konfigurieren oder Rekonfigurieren von diesem verwendet werden. Nachdem es konfiguriert ist, soll das CPM-System 150 die Durchführung des Auftrags überwachen und verwalten, wie unten ausführlich beschrieben.
  • Die Umgebung 105 beinhaltet allgemein mehrere CA/AD-Fahrzeuge, und somit ist auch ein anderes beispielhaftes Fahrzeug 153 als eine repräsentative Darstellung anderer Fahrzeuge in der Umgebung 105 dargestellt. Bei tatsächlichen Ausführungsformen können mehr oder weniger Fahrzeuge verwendet werden. Das Fahrzeug 153 ist auch mit einem fahrzeuginternen System 101 mit einem ähnlichen CPM-System 151 der vorliegenden Offenbarung ausgestattet.
  • Bei manchen Ausführungsformen ist das CPM-System 150/151 ferner dazu ausgelegt, bei der Bestimmung, dass eine mögliche Notfallbedingung, wie etwa ein medizinisches Ereignis, aufgetreten ist, jeweilige physische oder emotionale Zustände eines oder mehrerer Insassen individuell zu beurteilen. Ein derartiges medizinisches Ereignis kann zum Beispiel infolge eines Unfalls oder einer Fehlfunktion des Fahrzeugs 152/153 aufgetreten sein, der bzw. die durch das CPM 150/151 bestimmt wird. Alternativ dazu kann das medizinische Ereignis nicht mit einem Fahrzeugvorfall in Beziehung stehen und kann gegebenenfalls ein akuter Zustand eines Mitfahrers oder des Fahrers sein. Wie unten beschrieben, soll eine Konfiguration der Fahrzeuge 152/153 einen Taxidienst bereitstellen, und dies kann einen spezialisierten Taxidienst für ältere Menschen, Kinder mit speziellen Bedürfnissen oder dergleichen beinhalten, die medizinische Ereignisse während der Fahrt wahrscheinlicher erleiden können. Jeder beurteilte Insasse kann ein Fahrer oder ein Mitfahrer des Fahrzeugs 152/153 sein. Jeder Insasse kann zum Beispiel beurteilt werden, um zu bestimmen, ob der Zustand des Insassen kritisch und gestresst, mittelschwer und/oder gestresst, minderschwer, aber gestresst, minderschwer und nicht gestresst, oder nicht krank, nicht verletzt und nicht gestresst ist. Bei manchen Ausführungsformen ist das CPM-System 150/151 ferner dazu ausgelegt, nach der Bestimmung, dass das Fahrzeug 152/153 bei einem Fahrzeugvorfall beteiligt ist, den Fahrzeugzustand zu beurteilen. Das Fahrzeug kann zum Beispiel beurteilt werden, um zu bestimmen, dass es schwer beschädigt und nicht funktionsfähig, mittelmäßig beschädigt, aber nicht funktionsfähig, mittelmäßig beschädigt, aber funktionsfähig, oder leicht beschädigt und funktionsfähig ist. Bei manchen Ausführungsformen ist das CPM-System 150/151 ferner dazu ausgelegt, nach der Bestimmung, dass das Fahrzeug 152/153 an einem Fahrzeugvorfall beteiligt ist, den Zustand eines Bereichs um das Fahrzeug 152/153 herum zu beurteilen. Der Bereich um das Fahrzeug 152/153 herum kann zum Beispiel beurteilt werden, um zu bestimmen, ob es einen sicheren Seitenstreifenbereich gibt, in den das Fahrzeug 152/153 sicher bewegt werden kann, ob das Fahrzeug 152/153 funktionsfähig ist oder ob es einen geeigneten naheliegenden Bereich gibt, in dem ein Ersatzfahrzeug, das als Reaktion auf einen Notruf durch das Fahrzeug 152/153 gesendet wird, parken und Mitfahrer vom Fahrzeug 152/153 einladen kann.
  • Weiterhin unter Bezugnahme auf 1 können das Fahrzeug 152 und das Fahrzeug 153 jeweils Sensoren 110 bzw. 111 und Fahrsteuereinheiten 120 bzw. 121 beinhalten. Bei Ausführungsformen sind die Sensoren 110/111 dazu ausgelegt, dem CPM 150/151 verschiedene Sensordaten bereitzustellen, um dem CPM zu ermöglichen, Navigations- sowie Betriebsentscheidungen zu treffen. Bei manchen Ausführungsformen können die Sensoren 110/111 Kameras (nach außen zeigend sowie nach innen zeigend), LiDAR-Sensoren (LiDAR: light detection and ranging - Lichtdetektion und -entfernungsmessung), Mikrofone, Beschleunigungsmesser, Gyroskope, inertiale Messeinheiten (IMU), Motorsensoren, Antriebsstrangsensoren, Reifendrucksensoren, Andockplattformdrucksensoren und so weiter beinhalten. Die Fahrsteuereinheiten 120/121 können elektronische Steuereinheiten (ECUs) beinhalten, die den Betrieb des Motors, des Getriebes, der Lenkung und/oder des Bremsens des Fahrzeugs 152/153 steuern. Wie unten ausführlicher beschrieben, können die Sensoren 110/111 durch zusätzliche, spezialisierte oder genauere Sensoren erweitert werden, die in auf oder in dem Fahrzeug 152/153 landenden UAVs bereitgestellt sind.
  • Bei manchen Ausführungsformen ist das CPM-System 150/151 ferner dazu ausgelegt, eine Insassenversorgungshandlung oder eine Fahrzeughandlung zumindest teilweise basierend auf der einen oder den mehreren Beurteilungen des Zustands des einen oder der mehreren Insassen, der Beurteilung des Fahrzeugzustands, der Beurteilung eines Zustands des umliegenden Bereichs und des dann durch das Fahrzeug durchgeführten gegenwärtigen Auftrages zu bestimmen und/oder zu empfehlen. Bei Ausführungsformen kann das CPM 150/151 Fahrbefehle für die Fahrsteuereinheiten 120/121 erstellen oder bewirken, dass diese erstellt werden, um das Fahrzeug 152/153 zu bewegen, sodass die Insassen- oder Fahrzeugversorgungshandlung hinsichtlich des gegenwärtigen Auftrags des CA/AD-Fahrzeugs umgesetzt wird oder dazu beigetragen wird, dass diese umgesetzt wird. Bei manchen Ausführungsformen kann die empfohlene Insassenversorgungshandlung und/oder Fahrzeughandlung durch einen Fahrer oder Mitfahrer des Fahrzeugs aufgehoben oder modifiziert werden.
  • Das Fahrzeug 152/153 beinhaltet außerdem eine Andockplattform 135, wie am Fahrzeug 153 dargestellt, um einem oder mehreren UAVs 125 zu ermöglichen, sich physisch mit den Fahrzeugen zu verbinden, damit das Fahrzeug unterstützt wird, sich selbst für einen Betriebsmodus zu konfigurieren, der sich für seinen dann gegenwärtigen Auftrag eignet. Sobald sie angedockt sind, verbinden sich die UAVs über eine UAV-Schnittstelle mit dem CPM-System des Fahrzeugs 152/153. Das Fahrzeug 152 ist mit zwei an dessen Oberseite angedockten UAVs dargestellt, während das Fahrzeug 153 ohne UAVs dargestellt ist. Dies veranschaulicht eine beispielhafte Situation, bei der das Fahrzeug 152 weiterhin eine Mission durchführt und somit vom assoziierten Satz von UAVs 152 erfordert, zusätzliche Erfassungs- oder Konnektivitätsfähigkeiten bereitzustellen, während das Fahrzeug 153 eine Mission beendet hat und seine UAVs zur Wiederverwendung mit einem anderen CA/AD-Fahrzeug zurück zu einem Dienstzentrum gesendet hat. Zu dem veranschaulichten Zeitpunkt hat das Fahrzeug 153 entweder noch keinen neuen Auftrag empfangen oder hat zum Beispiel einen neuen Auftrag empfangen, aber noch keinen Satz von UAVs für dessen Konfiguration für diesen neuen Auftrag empfangen.
  • Bei manchen Ausführungsformen kann das CPM-System 100 entweder alleine oder als Reaktion auf Benutzerinteraktionen über einen Drahtlossignalrepeater oder eine Basisstation auf einem Sendemast 156 in der Nähe des Fahrzeugs 152 oder über ein oder mehrere private und/oder öffentliche verdrahtete und/oder drahtlose Netze 158 mit einem oder mehreren fahrzeugexternen Ferninhaltsservern 160 kommunizieren oder interagieren. Die Server 160 können mit einem Dienstzentrum, das die Fahrzeuge 152/153 mit ihren verschiedenen operativen Einsätzen versieht, assoziierte Server, mit Strafverfolgung assoziierte Server, mit einem Kunden des Dienstzentrums assoziierte Server, wie etwa zum Beispiel einem Klienten, der ein oder mehrere Fahrzeuge zum Durchführen einer Nachtüberwachung einer Nachbarschaft oder eines anderen Grundstücks mietet, oder ein Server eines Taxidienstanbieters, der eine Flotte von CA/AD-Fahrzeugen auf Bedarfsbasis betreibt, sein. Die Server 160 können alternativ dazu Server eines oder mehrerer Krankenhäuser sein, wenn sich das Fahrzeug in einem Krankenwagenbetriebsmodus befindet, oder selbst wenn es sich nicht in diesem befindet, aber in einer Situation befindet, wenn es als Reaktion auf einen medizinischen Notfall, der bei einem seiner Mitfahrer auftritt, schnell rekonfiguriert werden muss, um im Krankenwagenmodus zu arbeiten, wie unten in Verbindung mit den 5 und 6 ausführlich beschrieben. Als eine weitere Alternative können die Server 160 Drittparteiserver sein, die Dienste bezüglich eines Fahrzeugvorfalls bereitstellen, wie etwa das Weiterleiten von Berichten/Informationen zu Versicherungsgesellschaften, Werkstätten und so weiter zur Speicherung und anschließender Überprüfung durch Strafverfolgung, Versicherungssachverständige und so weiter. Beispiele für private und/oder öffentliche verdrahtete und/oder drahtlose Netze 158 können das Internet, das Netz eines Zellulardienstanbieters und so weiter beinhalten. Es versteht sich, dass der Sendemast 156 verschiedene Masten zu unterschiedlichen Zeiten/an unterschiedlichen Orten sein kann, während das Fahrzeug 152/153 zu einem Ziel fährt oder anderweitig fährt, wie für den dann vorherrschenden Betriebsmodus geeignet.
  • Diese und andere Aspekte der Fahrzeuge 152/153 und des CPM-Systems 150/152 werden ferner unter Bezugnahme auf die verbleibenden Figuren besprochen.
  • Wie oben angemerkt, wird bei Ausführungsformen ein CA/AD-Fahrzeug mit mobilen UAVs kombiniert, die ermöglichen, dass das Fahrzeug für einen gegebenen Auftrag konfiguriert wird. Bei Ausführungsformen ermöglichen die UAVs außerdem, dass das Fahrzeug physisch modifiziert wird, um andere Formen oder Zwecke mit unterschiedlichen Fähigkeiten anzunehmen, ohne eine Rückkehr zu der Dienstzentrumeinrichtung zu erfordern. Bei Ausführungsformen ist das Fahrzeug mit einer Auflade- oder Andockplattform für unterschiedliche Typen von UAVs ausgestattet, die wie angemerkt, sobald sie an der Plattform angedockt und mit dem CA/AD-Fahrzeug verbunden sind, dem Fahrzeug ermöglichten, andere Charakter anzunehmen. Ein gegebenes UAV kann zum Beispiel einen „dynamischen LIDAR“-Sensor bereitstellen, der dem Fahrzeug ermöglicht, auf Stadtstraßen im autonomen Modus zu arbeiten. Oder ein UAV kann zum Beispiel eine Notfalloperationsausrüstung bereitstellen, die für einen Notfalleinsatzverwendungsfall oder den Betrieb im Krankenwagenmodus benötigt wird.
  • Bei Ausführungsformen wird ein CA/AD-Fahrzeug mit einer modularen Plattform ferner durch das Anpassen von Software für verwendungsspezifische Hardware oder eine spezielle Dienstkonfiguration unterstützt. Gemäß verschiedenen Ausführungsformen ist eine flexible, dynamisch erweiterbare CA/AD-Dienstplattform für verschiedene Verwendungsfälle mit eingebauten Fehlertoleranzfähigkeiten anpassbar. Bei Ausführungsformen ist das CA/AD-Fahrzeug mit Hardware- und Softwarekomponenten ausgestattet, die sich dynamisch auf ändernde Arbeitsumfänge anpassen können.
  • 2 veranschaulicht ein beispielhaftes modulares CA/CD-Fahrzeug, das durch eine UAV-Unterstützung ergänzt wird, gemäß verschiedenen Ausführungsformen. Unter Bezugnahme auf 2 ist ein CA/AD-Fahrzeug 205 dargestellt, wobei zwei Typen von UAVs auf der Oberseite des CA/AD-Fahrzeugs angedockt sind. Die UAVs sind an einer Andockplattform 230 angedockt. Die Andockplattform 230 beinhaltet Aufladestreifen (nicht dargestellt), um jegliche UAVs geladen zu halten, die an ihr angedockt haben. Obwohl nur zwei UAVs in 2 dargestellt sind, kann es bei Ausführungsformen mehr oder weniger UAVs geben, die an einem gegebenen CA/AD-Fahrzeug zu einer beliebigen gegebenen Zeit angedockt sind. Die beiden dargestellten UAVs repräsentieren zwei allgemeine Typen von UAV, die an einem CA/AD-Fahrzeug bei verschiedenen Ausführungsformen andocken können. Obwohl dies in dem Beispiel von 2 nicht dargestellt ist, können UAVs bei alternativen Ausführungsformen auch innerhalb des CA/AD-Fahrzeugs andocken, wie etwa zum Beispiel, wenn das UAV ein dritter Typ von UAV ist, das ein oder mehrere Objekte oder eine oder mehrere Einrichtungen als Teil der Konfiguration für eine spezialisierte Verwendung zu dem CA/AD-Fahrzeug liefert. Die Hardwaregegenstände können zum Beispiel ein SECC-Modul (SECC: single edge contact cartridge - Single-Edge-Kontakt-Patrone) beinhalten, das in einen Port im Innenraum des CA/AD einzusetzen ist, oder das gelieferte Objekt kann ein Satz von medizinischer Ausrüstung sein, der innerhalb des CA/AD zur Verfügung zu stellen ist, wenn es zum Arbeiten als ein Krankenwagen konfiguriert ist.
  • Bei Ausführungsformen, wie dargestellt, können beispielhafte UAVs Konnektivitäts-UAVs 210 oder zusätzliche Erfassungs-UAVs 220 sein. Bei Ausführungsformen stellen die Konnektivitäts-UAVs 210 einem CA/AD-Fahrzeug zusätzliche Konnektivität bereit, wenn sein Auftrag dies erfordert, wie etwa zum Beispiel eine Satellitenkommunikationsverbindung, wenn das CA/AD-Fahrzeug in einem Bereich mit geringer Zellularnetzabdeckung arbeitet. Oder falls zum Beispiel dem CA/AD-Fahrzeug zur Verfügung steht, mit einem Netz verbunden zu werden, und ein anderes Zellularnetz mit besserer Konnektivität auf den Markt kommt, kann ein UAV an dem Fahrzeug andocken, um eine Konnektivität für dieses zusätzliche Zellularnetz bereitzustellen. Die zusätzlichen Erfassungs-UAVs stellen zusätzliche Sensoren bereit, die nicht allgemein in der Basisplattform des modularen CA/AD-Fahrzeugs bereitgestellt sind. Diese Sensoren können zum Beispiel für einen Nachterfassungsbetriebsmodus, der beispielsweise Teil eines Sicherheitsdienstauftrags sein kann, Infrarot- oder andere Nachtsichtsensoren und -kameras beinhalten. Oder zum Beispiel für einen Betriebsmodus mit autonomem Fahren können die durch ein UAV bereitgestellten Sensoren hochpräzise Positionierungssensoren beinhalten, wie etwa LIDAR- oder Millimeterwellen(MM-Wellen)-Positionierungseinrichtungen. Bei Ausführungsformen sind alle an oder in dem CA/AD-Fahrzeug 205 angedockten UAVs über die UAV-Schnittstelle 215 mit der CPU-und-FPGA-Plattformarchitektur des Fahrzeugs verknüpft, die eine beispielhafte CPM-Systemanwendung ausführen kann, wie oben beschrieben.
  • Obwohl dies nicht in 2 dargestellt ist, ist bei Ausführungsformen der Innenraum des CA/AD-Fahrzeugs auch für jeden in Erwägung gezogenen Dienst oder entsprechenden Betriebsmodus anpassbar. Es wird angemerkt, dass, obwohl ein beispielhaftes CA/AD-Fahrzeug offensichtlich in der Lage ist, zu einem Dienstleistungsstandort zur Wartung oder zum Anpassen seiner Plattform zu fahren, die UAV-Unterstützung bei Ausführungsformen Aktualisierungen und Rekonfiguration ermöglicht, wenn das CA/AD-Fahrzeug betriebsunfähig ist oder wenn Stau oder Verkehr dem CA/AD-Fahrzeug nicht ermöglicht, eine Dienstleistung zügig zu empfangen. Alternativ dazu, wenn hochentwickelte UAVs verwendet werden, um Konnektivität, ein Sensorarray hinzuzufügen sowie benötigte Ausrüstung zu liefern, ist es häufig überhaupt nicht so oft notwendig, „das CA/AD-Fahrzeug nach Hause zu bringen“ (z. B. zu dem Dienstzentrum), falls es zweckmäßig arbeitet und mehrere aufeinanderfolgende Male im Feld einfach rekonfiguriert werden kann. Bei Ausführungsformen ermöglicht die UAV-Unterstützung auch, dieselbe Hardware über viele Anwendungen gemeinsam zu nutzen und dynamisch variable Nachfrage anzusprechen.
  • Bei Ausführungsformen ist auch eine konfigurierbare Plattformarchitektur mit Zentralverarbeitungseinheit und feldprogrammierbarem Gate-Array (CPU-und-FPGA-Plattformarchitektur) im CA/AD-Fahrzeug bereitgestellt. Dies wird durch eine CPU-und-FPGA-Plattformarchitektur 240 angegeben, die allgemein zu dem Innenraum des Fahrzeugs 205 zeigt, wo sie sich befindet. Bei Ausführungsformen ermöglicht die konfigurierbare Plattformarchitektur 240 die Implementierung des oben erwähnten CloV-Modells mit Echtzeit-Anpassungsfähigkeit für Arbeitsumfänge. Bei Ausführungsformen sind zum Beispiel partielle Rekonfigurationsgebiete in einem FPGA spezifischen CloV-Schichten dediziert, was ein dynamisches Hin- und Hertauschen von schichtspezifischen Arbeitsumfängen ermöglicht. Bei Ausführungsformen ermöglicht dies eine gleichzeitige Verarbeitung der CloV-Erfassungs-, -Kommunikations-, -Wahrnehmungs-, -Steuerungs- und -Anwendungsschi chten. Darüber hinaus kann bei Ausführungsformen das im Fahrzeug 205 ausgeführte CPM-System adaptiv auf die Inline-Verarbeitung abgestimmt werden, indem mehr Speicherbandbreite, mehr Vernetzungs-E/A-Fähigkeit, gewichtete Arbitration zum Auswählen der Anzahl und Bandbreite von E/A-Verknüpfungen wie etwa PCIe und UPI, die die CPU und das FPGA verbinden, und Bilderfassung auf dem FPGA genutzt werden. Zusätzlich dazu kann das System bei Ausführungsformen adaptiv auf eine Lookaside-Verarbeitung abgestimmt werden, die eine gewichtete Arbitration zwischen CPU-zu-FPGA-Konnektivitätsverknüpfungen nutzt, um eine mit CPU-zu-FPGA-Datentransfers assoziierte Latenz zu reduzieren.
  • Bei Ausführungsformen ermöglicht die modulare Architektur des CA/CD-Fahrzeugs ein periodisches Upgraden von Arbeitsumfängen während der Lebensdauer des CA/CD-Fahrzeugs. Sie unterstützt ferner einen adaptiven Arbeitsumfangstausch, um auf Verkehrsszenarien (oder andere Szenarien) zu reagieren, die erfordern können, dass eine spezielle Anwendung in Echtzeit priorisiert wird. Zum Beispiel für Betriebsmodi, bei denen ein Fahrer vorhanden ist, die Verarbeitung der Patientendaten des Fahrers als Reaktion auf einen Notfall.
  • 3 veranschaulicht eine beispielhafte Reihe von Nachrichten zwischen einem beispielhaften Dienstzentrum, einem beispielhaften konfigurierbaren CA/AD-Fahrzeug und spezialisierten UAVs gemäß verschiedenen Ausführungsformen. 3 veranschaulicht auch Flüge, die durch die spezialisierten UAVs als Reaktion auf einen Teil der Nachrichten vorgenommen werden (in dickeren grauen Pfeilen 327, 335 und 345 dargestellt). In dem Beispiel von 3 wird ein rekonfigurierbares CA/AD-Fahrzeug rekonfiguriert, um von einer ersten Nachtüberwachungsmission zu einer zweiten Mission: autonomes Fahren in einer geschäftigen Stadt, zu wechseln. In dem Beispiel von 3 werden die unterschiedlichen Erfassungsfähigkeiten angepasst, die durch das CA/AD-Fahrzeug für diese beiden Verwendungsfälle benötigt werden, indem ein erster Satz von UAVs an dem CA/AD-Fahrzeug mit einem zweiten Satz von UAVs, der unterschiedliche Erfassungsfähigkeiten aufweist, ersetzt wird.
  • Unter Bezugnahme auf 3, wie bei 350 dargestellt, ist Nachtüberwachung die Anfangsmission für das CA/AD-Fahrzeug. Ein Dienstzentrum 315 leitet an, dass das CA/AD-Fahrzeug konfiguriert wird, indem eine zusätzliche Nachtsichterfassungsfähigkeit, wie bei 350 dargestellt, hinzugefügt wird sowie Nachtaufnahmekameras zu dem CA/AD-Fahrzeug hinzugefügt werden. Die Mission kann zum Beispiel durch einen routinemäßigen Wohngebietssicherheitsdienst durchgeführt werden oder sie kann zum Beispiel durch ein autonomes Fahrzeug durchgeführt werden, dass für die Polizei, das Militär oder eine private Sicherheitsfirma betrieben wird, die bzw. das einen hochwertigen Vermögensgegenstand oder ein hochwertiges Ziel beschützt. Um den Prozess zu initiieren, sendet das Dienstzentrum 315 eine Nachricht 321 zu dem CA/AD-Fahrzeug 310, die eine Erstellung des Dienstmodells anleitet. Zusätzlich dazu wird zu ungefähr derselben Zeit eine Nachricht 323 vom Dienstzentrum 315 zu spezialisierten UAVs 305 gesendet, um Missionseinzelheiten zu erstellen. Als Reaktion darauf kontaktieren die UAVs, in diesem Fall Nachtüberwachungs-UAVs 355, das Fahrzeug 310, um die Missionseinzelheiten zu bestätigen, und fliegen zu dem Fahrzeug und docken an diesem an. Nach dem Empfang der Nachricht 323 senden die spezialisierten UAVs 305 eine Nachricht 325 zu dem Fahrzeug 310 zur Bestätigung der Missionseinzelheiten und fliegen dann, wie durch einen Richtungspfeil 327 dargestellt, zu dem Fahrzeug 310 und docken an diesem an. Wie unter Bezugnahme auf 2 angemerkt, weist eine Andockplattform am CA/AD-Fahrzeug 310 bei Ausführungsformen Aufladestreifen auf, sodass die UAVs während des Andockens vollständig geladen bleiben.
  • Erneut unter Bezugnahme auf 3 bereitet das CA/AD-Fahrzeug 310 bei Block 330 als Reaktion auf die Ankunft der UAVs 305 seine Erfassungsplattform auf Nachtsicht-UAVs 355 vor und passt seine Hardwarekonfiguration auf die Unterstützung der Nachtüberwachung an. Bei Ausführungsformen kann dies das Schalten des FPGA zum Laden eines neuen Arbeitsumfangs beinhalten. Wenn die Nachtüberwachungsmission abgeschlossen ist, sendet das CA/AD-Fahrzeug 310 eine Nachricht 333 zum Dienstzentrum 315, die dem Dienstzentrum 315 mitteilt, dass die Mission durchgeführt wurde.
  • Zusätzlich dazu, wie bei Block 336 dargestellt, beendet das CA/AD-Fahrzeug 310 seine bestehende Konfiguration (z. B. „Nachtüberwachung“) und weist, da es keinen Bedarf mehr für ein Nachterfassungssensorarray gibt, die UAVs 355 hinsichtlich der nächsten Schritte an. Die letztgenannte Nachricht ist nicht in 3 dargestellt, da sie über eine interne UAV-Schnittstelle zwischen zum Beispiel dem CPM-System des CA/AD-Fahrzeugs, das auf der CPU des Fahrzeugs ausgeführt wird, und den verbundenen UAVs gesendet wird, wie oben in Verbindung mit 2 beschrieben. Als Reaktion auf die Anweisung vom CA/AD-Fahrzeug 310 kehren die Nachtüberwachungs-UAVs 355 zum Dienstzentrum 350 zurück, wie durch einen Richtungspfeil 335 dargestellt.
  • Erneut unter Bezugnahme auf 3 leitet bei Block 353 das Dienstzentrum 315 an, dass das CA/AD-Fahrzeug für autonomes Fahren (AD) in einer Stadt konfiguriert wird. Dies beinhaltet das Hinzufügen von UAVs für eine hochpräzise und zuverlässige Erfassung, das Hinzufügen von UAVs für V2X-Konnektivität, das Hinzufügen von Lidar, Radar und Kameras und von Sensoren zur MM-Wellen-Positionierung. Zusätzlich dazu erfordert dies das Verwenden eines bestehenden oder neu aktualisierten AD-Arbeitsumfangs. Um den Prozess zu initiieren, sendet das Dienstzentrum 315 eine Nachricht 337 zu dem CA/AD-Fahrzeug 310, die eine Rekonfiguration seiner Mission anleitet. Zusätzlich dazu wird zu ungefähr derselben Zeit eine Nachricht 340 vom Dienstzentrum 315 zu spezialisierten UAVs 305 gesendet, um Missionseinzelheiten zu erstellen. Als Reaktion darauf kontaktieren die UAVs, in diesem Fall AD-Erfassungs-UAVs 357, das Fahrzeug 310, um die Missionseinzelheiten zu bestätigen, und fliegen zu dem Fahrzeug und docken an diesem an, wie bei Block 357 dargestellt. Nach dem Empfang der Nachricht 343 senden die AD-Erfassungs-UAVs 357 somit eine die Missionseinzelheiten bestätigende Nachricht 343 zu dem Fahrzeug 310 und fliegen dann, wie durch einen Richtungspfeil 345 dargestellt, zu dem Fahrzeug 310 und docken an diesem an. Wie unter Bezugnahme auf 2 angemerkt, weist eine Andockplattform am CA/AD-Fahrzeug 310 bei Ausführungsformen Aufladestreifen auf, sodass die UAVs während des Andockens vollständig geladen bleiben.
  • Als Reaktion auf die Ankunft der AD-Erfassungs-UAVs 357, wie bei Block 347 dargestellt, wird das CA/AD-Fahrzeug 310 für AD rekonfiguriert und passt seine Hardwarekonfiguration für die Unterstützung von AD an. Bei Ausführungsformen kann dies das Schalten des FPGA zum Laden eines neuen Arbeitsumfangs beinhalten.
  • 4 veranschaulicht beispielhafte Ports 400, die in einem CA/AD-Fahrzeug zur Verbindung mit einem oder mehreren Hardwaremodulen bereitgestellt sind, gemäß verschiedenen Ausführungsformen. Bei Ausführungsformen können das eine oder die mehreren Hardwaremodule durch ein oder mehrere UAVs geliefert werden, die temporär an dem CA/AD-Fahrzeug zum Konfigurieren des CA/AD-Fahrzeugs für eine spezifische Verwendung angedockt sind. Bei Ausführungsformen können zum Beispiel SECC (Single Edge Contact Cartridges) zum Implementieren von Modularität verwendet werden. Durch das Einsetzen eines SECC-Moduls in einen der SECC-Ports (Slots) 400, kann ein Modul, das für den dann gegenwärtigen Betriebsmodus (die dann gegenwärtige Mission) eines beispielhaften CA/AD-Fahrzeugs geeignet ist, durch das CA/AD-Fahrzeug genutzt werden. Die untenstehende Tabelle 1 veranschaulicht eine beispielhafte Portzuweisung für jeden von drei Ports 400, wobei jeder Port ein Steuermodul empfängt, das für eine andere Funktionalität ausgerichtet ist, entweder Umgebungssteuerung (Port 1), Kommunikationen (Port 2) oder Berechnung (Port 3). Tabelle 1
    Port-Nr. Funktion Kundenspezifisches Taxi Krankenwagen Performance-Fahren
    1 UmgebungsSteuerung Spezielle Beleuchtung, Lufttemperatursteuerungen, intelligente Sitzplätze Lebenserhaltung Extreme Wetterbedingungen und Bedingungen einer physischen Straße (oder eines Geländes)
    2 Kommunikationen Entfernte visuelle Bestätigung von Mitfahrern, entfernte Türoperationen für Mitfahrersicherheit Für entfernte Notfallarztunterst ützung Interaktion mit einer Vielzahl von Sensoren, die zur Fahrrückmeldesteuer ung benötigt werden
    3 Berechnung Arbeitsumfänge für entfernten Fahrzeugbetrieb Arbeitsumfänge für Lebenserhaltung Arbeitsumfänge für extreme Bedingung
  • Unter Bezug auf Tabelle 1 ist die Funktionalität, die jeder Port der Ports 1-3 in 4 jeweils anspricht, in Spalte 2 bereitgestellt. Die Spalten 3-5 der Tabelle 1 befassen sich jeweils mit einem Betriebsmodus oder einer spezialisierten Verwendung eines beispielhaften CA/CD-Fahrzeugs, und für jeden der in Spalte 1 aufgelisteten und in Spalte 2 der Tabelle 1 beschriebenen Ports wird die geeignete Funktionalität, die durch ein in den jeweiligen Port eingestecktes SECC-Modul bereitgestellt wird, beschrieben. Unter Bezugnahme auf Spalte 3, für eine Verwendung als kundenspezifisches Taxi, liefert somit die Umgebungssteuerung (Port 1), die durch ein beispielhaftes SECC-Modul bereitgestellt wird, eine spezialisierte Beleuchtung, Lufttemperatursteuerungen und intelligente Sitzplätze, um z. B. zu bestimmen, ob sich ein Mitfahrer in oder nicht mehr in seinem Sitz befindet. Für Port 2, Kommunikationen, für die spezialisierte Verwendung als kundenspezifisches Taxi, liefert ein beispielhaftes SECC-Modul zum Beispiel eine entfernte visuelle Bestätigung von Mitfahrern und entfernte Türoperationen zur Mitfahrersicherheit. Für Port 3, Berechnung, liefert schließlich ein beispielhaftes SECC-Modul bei Ausführungsformen Arbeitsumfänge zum entfernten Fahrzeugbetrieb. In jeder der Spalten 4 und 5 beschreibt die Tabelle 1 ähnliche Funktionalitäten, die beispielhafte SECC-Module bei Ausführungsformen für den Krankenwagen- bzw. Performance-Fahren-Betriebsmodus, oder spezialisierte Verwendungen dafür, eines beispielhaften CA/AD-Fahrzeugs gemäß verschiedenen Ausführungsformen bereitstellen können.
  • Es wird angemerkt, dass bei Ausführungsformen die Verwendung von eigenständigen SECC-Modulen oder dergleichen zum Implementieren von Modularität auch von verschiedenen vorteilhaften Merkmalen der SECC-Module profitieren, die unabhängig betriebene Wärmelösungen und Eingrenzung von elektromagnetischer Störung (EMI) beinhalten. Bei Ausführungsformen ermöglichen SECC-Module einem CA/AD-Fahrzeug, die zweckmäßige Hardware, Software und Arbeitsumfänge, die zum Upgraden des Systems benötigt werden, anstatt kostspielige zweckmäßig gebaute Systeme auszutauschen. Bei manchen Ausführungsformen kann sich ein menschlicher Arbeiter an Bord des CA/AD-Fahrzeugs befinden, und dieser Arbeiter kann die geeigneten SECC-Module in die Ports 400 einstecken, wenn das Fahrzeug konfiguriert oder rekonfiguriert wird. Derartige Arbeiter können bei Ausführungsformen Teil des bereitgestellten Dienstes, und nicht beim Fahren des Fahrzeugs beteiligt sein, das wahrscheinlich vollständig computergesteuert sein kann. Im Krankenwagenmodus oder im spezialisierten Taximodus wird zum Beispiel in Erwägung gezogen, dass Sanitäter bzw. Aufsichtspersonen im Innenraum des CA/AD-Fahrzeugs anwesend sind, um Patienten bzw. Kunden zu unterstützen. Bei anderen Ausführungsformen, bei denen keine Menschen im CA/AD-Fahrzeug anwesend sind, wie etwa bei einer Nachtüberwachungsmission, können ein oder mehrere Roboterarme, die entfernt durch einen Dienstzentrumoperator geführt werden, innerhalb des CA/AD-Fahrzeugs bereitgestellt sein, um SECC-Module wie erforderlich aus einem geeigneten Port herauszunehmen und an diesen anzuschließen. Bei manchen Ausführungsformen können SECC-Module, die gewöhnlich durch das CA/AD-Fahrzeug verwendet werden, selbst bei Nichtverwendung an Bord gehalten werden und bei Bedarf wiederholt hin und her getauscht werden. Bei anderen Ausführungsformen, falls eine für das CA/AD-Fahrzeug relativ rare Rekonfiguration durch das Dienstzentrum für eine spezialisierte Verwendung angewiesen wird, kann eine Lieferdrohne die benötigten SECC-Module zu dem CA/AD-Fahrzeug bringen und kann sogar auf einer innengelegenen Andockplattform landen, die Module liefern und dann wegfliegen. Ein menschlicher Arbeiter oder zum Beispiel der eine oder die mehreren oben beschriebenen Teleoperation-Roboterarme können dann die geeigneten SECC-Module in die erforderlichen Ports einstecken. Als eine weitere Alternative kann ein CA/AD-Fahrzeug natürlich zur Rekonfiguration zurück zum Dienstzentrum gerufen werden.
  • Zusätzliche Typen von Dienstmodellen mit unterschiedlichen UAV-Fähigkeiten sind auch möglich. Bei manchen Ausführungsformen können Dienst-UAVs zur Redundanz oder als Ersetzungen im Fall eines tatsächlichen oder eines vorhergesagten Ausfalls verwendet werden. Wie außerdem oben angemerkt, können bei Ausführungsformen UAVs mit unterschiedlichen Kommunikationsfähigkeiten bei einem CA/AD-Fahrzeug eingesetzt werden, falls sich die Drahtloskonnektivität, die in einem gegebenen Dienstbereich oder an einem geographischen Standort verfügbar ist, von der unterscheidet, die die dann gegenwärtige Hardware oder die angedockten UAVs handhaben können. Fall es zum Beispiel darüber hinaus regnet oder das Auto in Bereichen mit extremer Temperatur betrieben wird, können UAVs mit einer Ausrüstung verwendet werden, die sich für das extreme Wetter eignet. Bei Ausführungsformen können die wie in den obigen Beispielen beschriebenen UAVs somit den „normalen“ Satz von UAVs erweitern oder sogar ersetzen, der gewöhnlich bei einer gegebenen Konfiguration verwendet wird, wenn dies spezielle Umstände erfordern. Ein Beispiel dafür ist ein CA/CD-Fahrzeug, das für einen Krankenwagendienst konfiguriert ist, wenn ein extremer Schneesturm erwartet wird oder eingetreten ist, wodurch alle „normalen“ Routen, die der Krankenwagendienst verwendet, jetzt gefährlich sind, eine andere Netzwerkkonnektivität aufweisen und zusätzliche Sensorarrays für sicheres Fahren erfordern, oder dergleichen.
  • Bei Ausführungsformen können Lieferungs-UAVs verwendet werden, wie etwa zum Beispiel, wenn die Mission lautet, Pakete zu einem gegebenen entfernten Dienstbereich zu liefern. Bei derartigen Ausführungsformen wird, anstatt ein UAV zu einem entfernten Bereich zu fliegen, ein beispielhaftes CA/AD-Fahrzeug mit den zu liefernden Paketen beladen und die UAVs für die letzte Etappe verwendet. Bei derartigen Ausführungsformen parkt das CA/AD-Fahrzeug entweder in einer Nachbarschaft oder fährt durch diese hindurch, und die UAVs an Bord liefern ihre Pakete zu nahegelegenen Gebäuden oder Häusern. Im Endeffekt ist dies ein Versandunternehmen mit UAVs anstatt Fahrern/Lieferanten. Bei derartigen Ausführungsbeispielen wird das CA/AD-Fahrzeug rekonfiguriert, um das Lagern von Paketen zu ermöglichen, sowie mit neuer Software rekonfiguriert, um eine systematische Paketlieferung zu verwalten (z. B. Verfolgen aller UAVs, Setzen von Lieferaufgaben in eine Warteschlange, Senden von Warnungen zu Paketempfängern usw.).
  • 5 veranschaulicht ein Beispiel für einen Rekonfigurationsprozess eines modularen konfigurierbaren CA/AD-Fahrzeugs gemäß verschiedenen Ausführungsformen. In dem Beispiel von 5 wurde ein modulares CA/AD-Fahrzeug ursprünglich für den Betrieb in einem Taximodus konfiguriert. Als Reaktion auf eine Notfallsituation mit einem Taximitfahrer wird das Fahrzeug jedoch spontan (und im Feld) rekonfiguriert, um in einem Krankenwagenmodus zu arbeiten, gemäß verschiedenen Ausführungsformen. Obwohl in dem speziellen Beispiel von 5 die Rekonfiguration als Reaktion auf eine Notfallbedingung durchgeführt wird, ist dies im Allgemeinen nicht notwendigerweise der Fall.
  • Unter Bezugnahme auf 5 ist ein CA/AD-Fahrzeug 510 für einen Taximodus konfiguriert worden und wird in diesem betrieben. Als Teil seines Taxiauftrags haben Taximodus-UAVs 151 an einer Andockplattform auf dem Dach des Fahrzeugs 510 angedockt. Die Taximodus-UAVs 510 können zum Beispiel UAVs beinhalten, die mit hochpräzisen Positionierungssensoren, wie etwa zum Beispiel LIDAR- oder Millimeterwellen(MM-Wellen)-Positionierungssensoren, sowie Drahtlosschnittstellen zu Cloud-Servern ausgestattet sind, die eine dynamische Echtzeit-Routenführung basierend auf den aktuellen Verkehrs- und Hindernisdaten bereitstellen.
  • Bei 513 wird angenommen, dass ein oder mehrere Mitfahrer einen medizinischen Notfall erlitten haben und dass die „Erfassungsschicht“, um die CloV-Kategorien zu verwenden, des CA/AD-Fahrzeugs den Notfall detektiert hat, entweder durch eine Mitfahreranfrage, eine Innenkamera, eine unregelmäßige Bewegung des betroffenen Mitfahrers, wie durch intelligente Sitzsensorarrays detektiert, oder dergleichen. Als Reaktion auf den medizinischen Notfall wird das CA/AD-Fahrzeug umgehend rekonfiguriert. Dies wird in 5 bei 515 durch Handlungen widergespiegelt, die an der „adaptiven CloV-Echtzeit-Schicht“ des CPM-Systems der CA/AD-Fahrzeuge vorgenommen werden. Die Reaktion beinhaltet zwei beispielhafte Aufgaben, die sowohl die FPGA+CPU- als auch UAV-Funktionalität beinhalten. Bei einer ersten beispielhaften Aufgabe wechseln die FPGA und CPU zu einem medizinischen Notfallarbeitsumfang. Wie oben angemerkt, kann dies durch das Hinzufügen eines FPGA oder zum Beispiel durch das Laden eines schon im Speicher zur Verfügung stehenden Moduls oder zum Beispiel durch das Ersetzen eines Satzes von SECC-Hardwaremodulen, die auf „kundenspezifisches Taxi“ ausgerichtet sind, mit neuen, die auf „Krankenwagen“ ausgerichtet sind, erzielt werden, wie in Tabelle 1 bereitgestellt und wie oben beschrieben. Zusätzlich dazu erstellt zum Beispiel das auf der CPU ausgeführte CPM eine Kommunikation mit der nächstgelegenen medizinischen Einrichtung und teilt ihr mit, dass ein emergenter Patient zu ihr geroutet wird. Insofern möglich wird auf Patientendaten bezüglich des Individuums zugegriffen, die bei jeglichen Behandlungsversuchen an Bord auf der Strecke zu verwenden sind. Falls das CA/AD-Fahrzeug in einem Taximodus ohne menschliche Aufsichtsperson arbeitete, kann bei Ausführungsformen ein Sanitäter auf dem Weg zu der medizinischen Einrichtung abgeholt werden, um den Pateinten auf der Strecke zu betreuen. Das Dienstzentrum kann zum Beispiel ein anderes gegenwärtig im Krankenwagenmodus arbeitendes CA/AD-Fahrzeug ohne Patienten so routen, dass es mit dem Fahrzeug 510 zusammentrifft, sodass ein Sanitäter oder ein anderer Gesundheitsexperte in das Fahrzeug 510 einsteigen kann.
  • Bei einer zweiten beispielhaften Aufgabe werden die Taximodus-UAVs zurück zum Dienstzentrum gesendet und neue UAVs werden gesendet, um das CA/AD-Fahrzeug 510 zum Arbeiten im Krankenwagenmodus zu konfigurieren. Diese UAVs können zum Beispiel durch die medizinische Einrichtung ausgesendete UAVs 525 mit Navigationssensoren, die zum Führen von Notfallfahrzeugen in Bereichen mit hohem Verkehrsaufkommen konzipiert sind, und ein Live-Verkehrs-Feed-UAV 527 beinhalten, um eine Konnektivität zu einem Live-Verkehrs-Feed-Server bereitzustellen, sodass das CA-Fahren des Fahrzeugs erweitert wird. Zusätzlich dazu kann das Lieferungs-UAV 523 zum Beispiel bei Ausführungsformen medizinische Ausrüstung, Arzneimittel oder andere Gegenstände, die zum Betreuen des Patienten benötigt werden, auf der Strecke zum Krankenhaus liefern. Bei Ausführungsformen können sowohl das Lieferungs-UAV 523 als auch das medizinische UAV 525 am Krankenhaus basiert sein und können zu dem Fahrzeug (jetzt Fahrzeug 520) fliegen, um eine schnelle Rekonfiguration zum Krankenwagenmodus zu erzielen. Bei derartigen Ausführungsformen kann das medizinische UAV medizinische Echtzeit-Informationen, einschließlich Vitalparametern, EKG-Ergebnissen oder dergleichen, in einem Direkt-Feed zu dem Krankenhaus senden, sodass Notaufnahme(ER: Emergency Room)-Personal am Krankenhaus schon über den Fall des Patienten Bescheid wissen, wenn er an der ER des Krankenhauses eintrifft. Sobald alle Rekonfigurationen erzielt wurden, wie bei 520 dargestellt, arbeitet das CA/AD-Fahrzeug im Krankenwagenmodus.
  • Jetzt unter Bezugnahme auf 6 ist ein Überblick für den Betriebsfluss eines Prozesses 600 zum Empfangen eines ersten Auftragstyps, Arbeiten in einem ersten Betriebsmodus gemäß dem ersten Auftrag und, als Reaktion auf die Detektion einer Notfallbedingung, Rekonfigurieren für das Arbeiten in einem zweiten Betriebsmodus gemäß verschiedenen Ausführungsformen dargelegt. Der Prozess 600 verwendet zur Vereinfachung der Veranschaulichung den in 5 veranschaulichten und oben beschriebenen beispielhaften ersten Betriebsmodus und zweiten Betriebsmodus. Der Prozess 600 kann durch ein CA/AD-Fahrzeug, wie etwa zum Beispiel die Fahrzeuge 152 oder 153 von 1 oder das Fahrzeug 205 von 2 durchgeführt werden. Oder zum Beispiel genauer gesagt, kann der Prozess 600 durch das CA/AD-Fahrzeug 510 und 520 (das dasselbe Fahrzeug in zwei Betriebsmodi ist) durchgeführt werden. Der Prozess 600 kann Blöcke 610 bis 660 beinhalten. Bei alternativen Ausführungsformen kann der Prozess 600 mehr oder weniger Vorgänge aufweisen und können manche der Vorgänge in unterschiedlicher Reihenfolge durchgeführt werden.
  • Der Prozess 600 beginnt bei Block 610, bei dem das CA/AD-Fahrzeug einen Taximodusauftrag von einem Dienstzentrum empfängt. Der Auftrag identifiziert ein oder mehrere UAVs, mit denen das CA/AD-Fahrzeug rechnen kann und die an dem Fahrzeug anzudocken sind. Bei dem abgebildeten Beispiel beinhaltet jedes UAV einen oder mehrere Sensoren, die auf die spezielle Anwendung ausgerichtet sind, hier einen Taxidienst. Somit können die UAVs zum Beispiel präzise Positionierungssensoren bereitstellen, die in sehr dichten Stadtkernen genau sind.
  • Vom Block 610 geht der Prozess 600 zum Block 620 über, bei dem das eine oder die mehreren UAVs, die helfen sollen, das CA/AD-Fahrzeug für den Taximodusbetrieb zu konfigurieren, an der Andockplattform des Fahrzeugs angedockt sind. Vom Block 620 geht der Prozess 600 zum Block 630 über, bei dem das CA/AD-Fahrzeug zum Beispiel über ein CPM-System, wie oben beschrieben, über eine UAV-Schnittstelle mit dem einen oder den mehreren UAVs verbunden wird, die jetzt an der Andockplattform angedockt sind.
  • Vom Block 630 geht der Prozess 600 zum Block 640 über, bei dem das CA/AD-Fahrzeug, das jetzt vollständig dafür konfiguriert ist, im Taximodus arbeitet und demnach Mitfahrer abholt und absetzt. Vom Block 640 geht der Prozess 600 zum Abfrageblock 645, bei dem das CA/AD-Fahrzeug bestimmt, ob ein Mitfahrer einen medizinischen Notfall erleidet. Falls „Nein“ beim Abfrageblock 645, dann kehrt der Prozess 600 zum Block 640 zurück und fährt damit fort, im Taximodus zu arbeiten. Bei Ausführungsformen können die Blöcke 640 und 645 somit eine kontinuierliche Schleife für ein beliebiges CA/AD-Fahrzeug bilden, das in einem Taximodus, Schulbusmodus usw. arbeitet, bei dem ein Risiko besteht, dass ein Mitfahrer möglicherweise einen medizinischen Notfall erleidet. Dies veranschaulicht einen der wesentlichen Vorteile des modularen konfigurierbaren CA/AD-Fahrzeugs gemäß verschiedenen Ausführungsformen. Es gibt häufig in Beziehung stehende Betriebsmodi, bei denen ein gegebenes Fahrzeug anfänglich für einen Betriebsmodus konfiguriert sein kann und am Ende nicht selten zu dem anderen rekonfiguriert wird. Somit kann ein Auftreten der Rekonfiguration statistisch erwartet und Vorbereitungen für eine schnelle und effiziente Rekonfiguration in das System eingebaut werden, wie etwa zum Beispiel durch das regelmäßige Einlagern von SECC-Hardwaremodulen und FPGAs für beide Betriebsmodi im Fahrzeug und das Entwickeln von effizienten UAV-Ersetzungsprotokollen, falls eine Änderung stattfinden sollte. Ein derartiges Protokoll kann bei Ausführungsformen darin bestehen, Taximodus-UAVs und Krankenwagen-UAVs an einem oder mehreren Satellitendienstzentren, in der Nähe der Routen, auf denen die Taxidienst-CA/AD-Fahrzeuge normalerweise fahren, wie etwa in einem Stadtzentrum oder einem Hauptgeschäftsbereich, zur Verfügung zu haben oder, wie oben beschrieben, in UAV-„Hangars“ an lokalen Traumazentren bereitgestellt zu sein, die, sobald es im Krankenwagenmodus arbeitet, die Hauptziele des CA/AD-Fahrzeugs sind.
  • Erneut unter Bezugnahme auf 6, falls die Rückgabe am Abfrageblock 645 „Ja“ war, dann geht der Prozess 600 zum Block 650, bei dem er beginnt, für einen Krankenwagenbetriebsmodus rekonfiguriert zu werden. Somit wird ein Arbeitsumfang für einen medizinischen Notfall gegebenenfalls für das FPGA und die CPU geladen und installiert. Sobald er installiert und geladen ist, bestimmt der medizinische Arbeitsumfang zum Beispiel ein nächstgelegenes Krankenhaus und beginnt Kommunikationen mit diesem, wie zum Beispiel bei 515 der oben beschriebenen 5 dargestellt. Vom Block 650 geht der Prozess 600 zum Block 660, bei dem das CA/AD-Fahrzeug beim Krankenhaus anfordert, ein oder mehrere medizinische UAVs zum Andocken zu ihm zu senden, um das Fahrzeug sowohl im Allgemeinen für das Arbeiten im Krankenwagenmodus zu konfigurieren, als auch insbesondere den Patienten und das Krankenhaus auf die Ankunft des Patienten am designierten Krankenhaus vorzubereiten.
  • Die medizinischen UAVs können, sobald sie am Fahrzeug angedockt sind, medizinische Echtzeit-Informationen, einschließlich Vitalparametern, EKG-Ergebnissen oder dergleichen, in einem Direkt-Feed zu dem Krankenhaus senden, sodass Notaufnahme(ER: Emergency Room)-Personal am Krankenhaus schon über den Fall des Patienten Bescheid wissen, wenn er an der ER des Krankenhauses ankommt, und es kann auf seine Akte zugegriffen werden. Zusätzlich dazu können die medizinischen UAVs bei Ausführungsformen medizinische Ausrüstung, Arzneimittel oder andere Gegenstände, die zum Betreuen des Patienten gemäß den spezifischen Protokollen des Krankenhauses benötigt werden, auf der Strecke zum Krankenhaus liefern. Als eine weitere Alternative kann ein medizinisches UAV zum Beispiel auf eine Innenkamera am CA/AD-Fahrzeug zugreifen, ein Live-Feed des Patienten zu der ER des Krankenhauses senden, sodass Traumaärzte beginnen können, an dem Fall zu arbeiten, selbst bevor der Patient ankommt. Bei alternativen Ausführungsformen können die medizinischen UAVs nicht vom Krankenhaus, sondern vom Dienstzentrum gesendet werden.
  • Vom Block 660 geht der Prozess 600 zum Block 670, bei dem die medizinischen UAVs angedockt sind, über eine UAV-Schnittstelle mit dem CPM des CA/AD-Fahrzeugs verbunden sind und das CA/AD-Fahrzeug im vollen Krankenwagenmodus arbeitet.
  • Jetzt unter Bezug auf 7 ist ein Überblick für den Betriebsfluss eines Prozesses 700 zum Empfangen eines spezifischen Verwendungsauftrags, Konfiguriertwerden für den Auftrag und Durchführen des Auftrags dargestellt. Der Prozess 700 kann durch ein CA/CD-Fahrzeug, wie etwa zum Beispiel die Fahrzeuge 152 oder 153 von 1 oder das Fahrzeug 205 von 2, durchgeführt werden. Der Prozess 700 kann Blöcke 710 bis 760 beinhalten. Bei alternativen Ausführungsformen kann der Prozess 700 mehr oder weniger Vorgänge aufweisen und können manche der Vorgänge in unterschiedlicher Reihenfolge durchgeführt werden.
  • Der Prozess 700 beginnt bei Block 710, bei dem das CA/AD-Fahrzeug einen spezifischen Verwendungsauftrag von einem Dienstzentrum empfängt. Der Auftrag identifiziert ein oder mehrere UAVs, die an das CA/AD-Fahrzeug anzudocken sind und jeweils einen oder mehrere Sensoren beinhalten, die auf die spezifische Verwendung ausgerichtet sind.
  • Vom Block 710 geht der Prozess 700 zum Block 720 über, bei dem das eine oder die mehreren UAVs, die helfen, das CA/AD-Fahrzeug für die spezifische Verwendung zu konfigurieren, an der Andockplattform des Fahrzeugs angedockt und über eine UAV-Schnittstelle mit dem CA/AD-Fahrzeug verbunden werden, sodass das Fahrzeug Daten von jedem des einen oder der mehreren Sensoren der UAVs erhält. Vom Block 720 geht der Prozess 700 zum Block 730 über, bei dem das CA/AD-Fahrzeug mindestens eines mehrerer Hardwaremodule empfängt, um das CA/AD-Fahrzeug zusätzlich für die spezifische Verwendung zu konfigurieren. Die Hardwaremodule können zum Beispiel SECC-Module oder dergleichen sein, die in Ports innerhalb des CA/AD-Fahrzeugs eingesteckt werden, wie oben in Verbindung mit 4 und Tabelle 1 beschrieben.
  • Vom Block 730 geht der Prozess 700 zum Block 740, bei dem das Fahrzeug mit dem mindestens einen Hardwaremodul verbunden wird. Bei manchen Ausführungsformen kann sich zum Beispiel, und wie oben angemerkt, ein menschlicher Arbeiter an Bord des CA/AD-Fahrzeugs befinden, und dieser Arbeiter kann die geeigneten Hardwaremodule in geeignete Ports einstecken. Derartige Arbeiter können bei Ausführungsformen Teil des bereitgestellten Dienstes, und nicht beim Fahren des Fahrzeugs beteiligt sein, das wahrscheinlich vollständig computergesteuert sein kann. Im Krankenwagenmodus oder im spezialisierten Taximodus wird zum Beispiel in Erwägung gezogen, dass Sanitäter bzw. Aufsichtspersonen im Innenraum des CA/AD-Fahrzeugs anwesend sind, um Patienten bzw. Kunden zu unterstützen. Bei anderen Ausführungsformen, bei denen keine Menschen im CA/AD-Fahrzeug anwesend sind, wie etwa wenn die spezifische Verwendung eine Nachtüberwachung ist, können ein oder mehrere Roboterarme, die zum Beispiel entfernt durch einen Dienstzentrumoperator geführt werden, innerhalb des CA/AD-Fahrzeugs bereitgestellt sein, um Hardwaremodule wie erforderlich aus einem geeigneten Port herauszunehmen und an diesen anzuschließen. Bei manchen Ausführungsformen können die Hardwaremodule, die gewöhnlich durch das CA/AD-Fahrzeug verwendet werden, selbst bei Nichtverwendung an Bord gehalten werden und bei Bedarf wiederholt hin und her getauscht werden. Bei anderen Ausführungsformen, falls eine für das CA/AD-Fahrzeug relativ rare Rekonfiguration durch das Dienstzentrum für eine spezialisierte Verwendung angewiesen wird, kann eine Lieferdrohne die notwendigen Hardwaremodule zu dem CA/AD-Fahrzeug bringen und kann sogar auf einer innengelegenen Andockplattform landen, die Module liefern und dann wegfliegen. Ein menschlicher Arbeiter oder zum Beispiel der eine oder die mehreren oben beschriebenen Teleoperation-Roboterarme können dann die Hardwaremodule mit dem CA/AD-Fahrzeug verbinden. Als eine weitere Alternative kann ein CA/AD-Fahrzeug natürlich zur Rekonfiguration zurück zum Dienstzentrum gerufen werden.
  • Vom Block 750 geht der Prozess 700 zum Abfrageblock 755, bei dem bestimmt wird, ob die Mission des CA/AD-Fahrzeugs in diesem speziellen Betriebsmodus abgeschlossen wurde. Bei Ausführungsformen kann diese Bestimmung auf verschiedene Weisen vorgenommen werden. Bei einem Beispiel kann der spezifische Verwendungsauftrag eine deutlich definierte Zielsetzung anweisen, die bei Abschluss die Mission beendet, wie etwa bei Tagesanbruch zum Beispiel den Betrieb im Nachtüberwachungsmodus beendet. Bei anderen Beispielen kann das CA/AD-Fahrzeug jedes Mal melden, wenn eine Aufgabe entsprechend der spezifischen Gesamtverwendung abgeschlossen ist, wie etwa bei jeder abgeschlossenen Fahrt im Taxi- oder Krankenwagenmodus, und kann eine Antwort empfangen, um entweder damit fortzufahren, für eine definierte Anzahl von zusätzlichen Fahrten damit fortzufahren oder den Betrieb anzuhalten. Oder bei noch einem anderen Beispiel, bei dem ein CA/AD-Fahrzeug selbst eine Rekonfiguration aufgrund eines Notfalls auslöste, wie in den 5 und 6 veranschaulicht, kann, sobald der Patient zu dem nahegelegenen Krankenhaus geliefert wurde, das Protokoll lauten, dass der Betrieb im rekonfigurierten Modus unmittelbar aufhört, und das Fahrzeug zu seinem ursprünglichen Betriebsmodus zurückkehrt, der seine eigenen Missionsabschlusskriterien aufweist.
  • Falls die Rückgabe beim Abfrageblock 755 „Ja“ lautete, geht dann der Prozess 700 zum Block 760, bei dem er einen Missionsabschluss zu dem Dienstzentrum meldet und die angedockten UAVs anweist, zum Dienstzentrum zurückzukehren, das ein Satellitendienstzentrum sein kann, das als ein lokaler „UAV-Hangar“ fungiert, wie oben beschrieben.
  • Falls die Rückgabe beim Abfrageblock 755 jedoch „Nein“ lautete, dann kehrt der Prozess 700 zum Block 750 zurück und fährt damit fort, gemäß dem spezifischen Verwendungsauftrag zu arbeiten.
  • 8 veranschaulicht ein beispielhaftes UAV 800 einschließlich eines oder mehrerer Sensoren, um an einer an dem CA/AD-Fahrzeug bereitgestellten Plattform anzudocken, gemäß verschiedenen Ausführungsformen. Unter Bezug darauf beinhaltet ein beispielhaftes UAV 800 eine Nutzlast 820 und Rotoren 830. In dem Beispiel von 8 weist das UAV vier Rotoren auf. Bei alternativen Ausführungsformen können mehr oder weniger Rotoren verwendet werden. Jeder der Rotoren 830 beinhaltet einen Motor 831 (nur für einen Rotor dargestellt). Jeder Rotor ist durch einen Verbindungsstab 833 (nur für einen Rotor dargestellt) an der zentralen Nutzlast 820 angebracht. Bei Ausführungsformen ist die Nutzlast 820 mit einem oder mehreren Sensoren 810 ausgestattet, wobei der eine oder die mehreren Sensoren Funktionalität für ein CA/AD-Fahrzeug hinzufügen und es dadurch für eine spezielle Verwendung konfigurieren. Das UAV 800 beinhaltet bei Ausführungsformen ferner eine CA/AD-Fahrzeugschnittstelle 815, über die, sobald es an einem beispielhaften CA/AD-Fahrzeug angedockt ist, das CA/AD-Fahrzeug auf Daten von bordinternen Sensoren 810 zugreift, einschließlich durch verschiedene Softwareprogramme und Anwendungen, die auf seiner CPU-und-FPGA-Plattform ausgeführt werden, wie oben beschrieben.
  • Bei manchen Ausführungsformen stellt das UAV 800 einem CA/AD-Fahrzeug, an dem es angedockt ist, zusätzliche Konnektivität bereit, wenn dies der Auftrag des CA/AD-Fahrzeugs erfordert, wie etwa zum Beispiel eine Satellitenkommunikationsverbindung, wenn das CA/AD-Fahrzeug in einem Bereich mit geringer Zellularnetzabdeckung arbeitet. Oder falls zum Beispiel dem CA/AD-Fahrzeug zur Verfügung steht, mit einem Netz verbunden zu werden, und ein anderes Zellularnetz mit besserer Konnektivität auf den Markt kommt, kann ein UAV 800 an dem Fahrzeug andocken, um eine Konnektivität zu diesem zusätzlichen Zellularnetz bereitzustellen.
  • Bei Ausführungsformen beinhalten die Sensoren 810 zusätzliche Sensoren, die nicht gewöhnlich in der Basisplattform eines modularen CA/AD-Fahrzeugs bereitgestellt sind. Diese Sensoren können zum Beispiel für einen Nachterfassungsbetriebsmodus, der beispielsweise Teil eines Sicherheitsdienstauftrags sein kann, Infrarot- oder andere Nachtsichtsensoren und -kameras beinhalten. Oder zum Beispiel für eine spezifische Verwendung zum autonomen Fahren können die im UAV 800 bereitgestellten Sensoren hochpräzise Positionierungssensoren beinhalten, wie etwa LIDAR- oder Millimeterwellen(MM-Wellen)-Positionierungseinrichtungen.
  • Bei Ausführungsformen beinhaltet das UAV 800 einen Laderaum 850, um verschiedene Gegenstände zu halten, die entweder zu einem CA/AD-Fahrzeug zu liefern sind, an dem das UAV 800 temporär andockt, oder, in einer spezifischen Verwendung eines automatisierten Lieferungsdienstes, bei der das UAV Pakete zu Personen liefert, indem es von einer Andockplattform des CA/AD-Fahrzeugs zu einem Wohnsitz des Kunden oder einen Geschäftsstandort fliegt. Bei Ausführungsformen können Gegenstände, die im Laderaum 850 zu transportieren und dann zu einem CA/AD-Fahrzeug zu liefern sind, ein oder mehrere Hardwaremodule zum Konfigurieren des CA/AD-Fahrzeugs für eine spezifische Verwendung beinhalten, wie etwa mehrere SEC-Module, wie oben beschrieben. Oder bei Ausführungsformen können Gegenstände, die zu einem CA/AD-Fahrzeug zu liefern sind, Werkzeuge und andere Geräte beinhalten, die während des Betriebs gemäß einer spezifischen Verwendung zu verwenden sind, wie etwa medizinische Ausrüstung, Arzneimittel, intravenöse Vorrichtungen und Flüssigkeiten und dergleichen, wenn die spezifische Verwendung des CA/AD-Fahrzeugs die eines Krankenwagendienstes ist.
  • Jetzt unter Bezugnahme auf 9, bei der eine Softwarekomponentenansicht des CPM-Systems gemäß verschiedenen Ausführungsformen veranschaulicht ist. Wie dargestellt, beinhaltet ein CPM-System 900, das das CPM-System 100 sein könnte, für die Ausführungsformen Hardware 902 und Software 910. Die Software 910 beinhaltet einen Hypervisor 912, der eine Anzahl von virtuellen Maschinen (VMs) 922-928 hostet. Der Hypervisor 912 ist dazu ausgelegt, eine Ausführung der VMs 922-928 zu hosten. Die VMs 922-928 beinhalten zwei Dienst-VMs 922 und 924 und eine Anzahl von Benutzer-VMs 926-928. Die Dienstmaschine 922 beinhaltet ein Dienst-OS, das eine Ausführung einer Anzahl von Instrumentenclusteranwendungen 932 hostet. Die Dienstmaschine 924 beinhaltet ein zweites Dienst-OS, das eine Ausführung von UAV-Schnittstellenanwendungen und Hardwaremodulschnittstellenanwendungen hostet. Die Benutzer-VMs 926-928 können eine erste Benutzer-VM 926 mit einem ersten Benutzer-OS, das eine Ausführung von fahrzeuginternen Infotainment-Anwendungen 936 hostet, und eine zweite Benutzer-VM 928 mit einem zweiten Benutzer-OS, das eine Ausführung eines konfigurierbaren Plattformverwaltungssystems hostet, einschließlich Fahrgastraumanwendungen bezüglich der dann gegenwärtigen spezifischen Verwendung des CA/AD-Fahrzeugs 938 und so weiter, beinhalten.
  • Mit der Ausnahme der CPM-Technologie 150, 151 der aufgenommenen vorliegenden Offenbarung, können die Elemente 912-938 der Software 910 ein beliebiges einer Anzahl dieser in der Technik bekannten Elemente sein. Der Hypervisor 912 kann zum Beispiel ein beliebiger einer Anzahl von in der Technik bekannten Hypervisors sein, wie etwa KVM, ein Open-Source-Hypervisor, Xen, verfügbar von Citrix Inc, in Fort Lauderdale, Florida, USA, oder VMware, verfügbar von VMware Inc in Palo Alto, Kalifornien, USA, und so weiter. Gleichermaßen können das Dienst-OS der Dienst-VMs 922-924 und das Benutzer-OS der Benutzer-VMs 926-928 ein beliebiges einer Anzahl von in der Technik bekannten OS sein, wie etwa Linux, z. B. verfügbar von Red Hat Enterprise in Raleigh, North Carolina, USA, oder Android, verfügbar von Google in Mountain View, Kalifornien, USA.
  • Jetzt unter Bezugnahme auf 10, bei der eine beispielhafte Rechenplattform veranschaulicht ist, die sich zur Verwendung zum Umsetzen der vorliegenden Offenbarung gemäß verschiedenen Ausführungsformen eignen kann. Wie dargestellt, kann eine Rechenplattform 1000, die die Hardware 1002 von 10 sein kann, einen oder mehrere Systeme-auf-Chip (SoCs) 1002, einen ROM 1003 und einen Systemspeicher 1004 beinhalten. Jedes SoC 1002 kann einen oder mehrere Prozessorkerne (CPUs), eine oder mehrere Grafikprozessoreinheiten (GPUs), einen oder mehrere Beschleuniger, wie etwa Computervision- (CV) und/oder Deep-Leaming(DL)-Beschleuniger, beinhalten. Der ROM 1003 kann BIOS (basic input/output system services) 1005 beinhalten. Die CPUs, GPUs und CV-/DL-Beschleuniger können beliebige einer Anzahl dieser in der Technik bekannten Elemente sein. Gleichermaßen können der ROM 1003 und das BIOS 1005 beliebige einer Anzahl von in der Technik bekannten ROM und BIOS sein und der Systemspeicher 1004 kann ein beliebiger einer Anzahl von in der Technik bekannten flüchtigen Speicherungen sein.
  • Zusätzlich dazu kann die Rechenplattform 1000 persistente Speicherungseinrichtungen 1006 beinhalten. Ein Beispiel für die persistenten Speicherungseinrichtungen 1006 kann unter anderem Flash-Laufwerke, Festplatten, CD-ROM (compact disc read-only memory) und so weiter beinhalten Des Weiteren kann die Rechenplattform 1000 eine Eingabe/Ausgabe-Einrichtungsschnittstelle 1008 (wie etwa zum Koppeln mit einer Anzeige, einer Tastatur, einer Cursorsteuerung und so weiter) und eine Kommunikationsschnittstelle 1010 (wie etwa zum Koppeln mit Netzwerkschnittstellenkarten, Modems und so weiter) beinhalten. Die E/A-Einrichtungsschnittstelle 1008 kann ferner eine beliebige Anzahl von in der Technik bekannten E/A-Einrichtungen beinhalten, wie etwa zum Beispiel Sensoren 1020. Beispiele für Kommunikationseinrichtungen, die mit der Kommunikationsschnittstelle 1010 verbunden sein können, können unter anderem Vernetzungsschnittstellen für Bluetooth®, Nahfeldkommunikation (NFC), WiFi, Zellularkommunikation (wie etwa LTE 4G/5G) und so weiter beinhalten. Die Elemente können mittels eines Systembusses 1011, der einen oder mehrere Busse repräsentieren kann, miteinander gekoppelt sein. Im Fall mehrerer Busse können sie durch eine oder mehrere (nicht gezeigte) Busbrücken verbunden sein.
  • Jedes dieser Elemente kann seine in der Technik bekannten herkömmlichen Funktionen durchführen. Insbesondere kann der ROM 1003 das BIOS 1005 mit einem Bootloader beinhalten. Der Systemspeicher 1004 und die persistente Speicherung 1006 können eingesetzt werden, um eine Arbeitskopie und eine permanente Kopie der Programmierungsanweisungen zu speichern, die die Operationen implementieren, die mit dem Hypervisor 112, dem Dienst-/Benutzer-OS der Dienst-/Benutzer-VM 1022-1028 und Komponenten der CPM-Technologie 150 (wie etwa der UAV-Schnittstelle 215, des CA/AD-Fahrzeugs 205, der Andockplattform 230, modularen Hardwaremodulen, die über die SECC-Ports 400 verbunden sind, oder dergleichen und so weiter), die zusammengefasst als Rechenlogik 1022 bezeichnet werden, assoziiert sind. Die verschiedenen Elemente können durch Assembleranweisungen, die von dem/den Prozessorkern(en) der SoCs 1002 unterstützt werden, oder durch höhere Programmiersprachen, wie etwa zum Beispiel C, implementiert werden, die in solche Anweisungen kompiliert werden können.
  • Zusätzlich dazu kann die Rechenplattform 1000 Hardwaremodulports 1025 beinhalten, wie etwa zum Beispiel SECC-Ports, in die eine oder mehrere Hardwaremodulpatronen1027 eingesteckt werden, um Modularität bereitzustellen. Die Hardwaremodulpatronen 1027 können zum Beispiel SEC-Patronen sein. Um sich mit einem oder mehreren UAVs zu verbinden, die an oder in einem CA/AD-Fahrzeug angedockt sind, in dem die Rechenplattform 1000 bereitgestellt ist, kann die Rechenplattform 1000 auch eine UAV-Schnittstelle 1030 beinhalten.
  • Wie durch einen Fachmann erkannt wird, kann die vorliegende Offenbarung als Verfahren oder Computerprogrammprodukte umgesetzt werden. Dementsprechend kann die vorliegende Offenbarung zusätzlich zu ihrer Umsetzung in Hardware, wie zuvor beschrieben, die Form einer vollständigen Softwareausführungsform (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Ausführungsform, die Software- und Hardwareaspekte kombiniert, annehmen, die alle allgemein als eine „Schaltung“, ein „Modul“ oder ein „System“ bezeichnet werden. Des Weiteren kann die vorliegende Offenbarung die Form eines Computerprogrammprodukts annehmen, das in einem beliebigen greifbaren oder nichtflüchtigen Ausdrucksmedium mit im Medium umgesetztem computernutzbarem Programmcode umgesetzt ist.
  • 11 veranschaulicht ein beispielhaftes computerlesbares nichtflüchtiges Speicherungsmedium, das sich zur Verwendung zum Speichern von Anweisungen eignen kann, die bewirken, dass eine Vorrichtung als Reaktion auf eine Ausführung der Anweisungen durch die Vorrichtung ausgewählte Aspekte der vorliegenden Offenbarung umsetzt. Wie dargestellt, kann das nichtflüchtige computerlesbare Speicherungsmedium 1102 eine Anzahl von Programmieranweisungen 1104 beinhalten. Die Programmieranweisungen 1104 können dazu ausgelegt sein, einer Einrichtung, z. B. der Rechenplattform 1000, als Reaktion auf eine Ausführung der Programmanweisungen zu ermöglichen, (Aspekte des) Hypervisors 112, des Dienst-/Benutzer-OS der Dienst-/Benutzer-VM 122-128 und ausgewählte Funktionalitäten von Komponenten der CPM-Technologie 150 (wie etwa der UAV-Schnittstelle 215, des CA/AD-Fahrzeugs 205, der Andockplattform 230, modularen Hardwaremodulen, die über SECC-Ports 400 verbunden sind, oder dergleichen und so weiter) zu implementieren. Bei alternativen Ausführungsformen können die Programmieranweisungen 1104 stattdessen auf mehreren computerlesbaren nichtflüchtigen Speicherungsmedien 1102 angeordnet sein. Bei noch anderen Ausführungsformen können die Programmieranweisungen 1104 auf computerlesbaren flüchtigen Speicherungsmedien 1102 angeordnet sein, wie etwa Signalen.
  • Es kann eine beliebige Kombination eines oder mehrerer computernutzbarer oder computerlesbarer Medien genutzt werden. Das computernutzbare oder computerlesbare Medium kann zum Beispiel unter anderem ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine elektronische, magnetische, optische, elektromagnetische, Infrarot- oder Halbleitervorrichtung oder -einrichtung oder ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleiterpropagationsmedium sein. Spezifischere Beispiele (eine unvollständige Liste) des computerlesbaren Mediums würde das Folgende beinhalten: eine elektrische Verbindung mit einem oder mehreren Drähten, eine portable Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Nurlesespeicher (ROM), einen löschbaren programmierbaren Nurlesespeicher (EPROM oder Flash-Speicher), eine optische Faser, eine portable CD-ROM (compact disc read-only memory), eine optische Speicherungseinrichtung, Übertragungsmedien, wie etwa jene, die das Internet oder ein Intranet unterstützen, oder eine magnetische Speicherungseinrichtung. Es ist anzumerken, dass das computernutzbare oder computerlesbare Medium selbst Papier oder ein anderes geeignetes Medium sein kann, auf dem das Programm ausgedruckt ist, da das Programm beispielsweise über ein optisches Scannen des Papiers oder anderen Mediums elektronisch erfasst, dann kompiliert, interpretiert oder anderweitig auf eine geeignete Art und Weise verarbeitet werden kann, falls notwendig, und dann in einem Computerspeicher gespeichert werden kann. Im Zusammenhang dieses Dokuments kann ein computernutzbares oder computerlesbares Medium ein beliebiges Medium sein, das das Programm zur Verwendung durch das Anweisungsausführungssystem, der Anweisungsausführungsvorrichtung oder der Anweisungsausführungseinrichtung oder in Verbindung mit diesen enthalten, speichern, kommunizieren, propagieren oder transportieren kann. Das computernutzbare Medium kann ein propagiertes Datensignal mit dem darauf umgesetzten computernutzbaren Programmcode entweder im Basisband oder als Teil einer Trägerwelle beinhalten. Der computernutzbare Programmcode kann unter Verwendung eines beliebigen geeigneten Mediums übertragen werden, einschließlich unter anderem drahtlos, drahtgebunden, optisches Faserkabel, HF usw.
  • Computerprogrammcode zum Ausführen von Operationen der vorliegenden Offenbarung kann in beliebiger Kombination von einer oder mehreren Programmiersprachen geschrieben werden, einschließlich einer objektorientierten Programmiersprache, wie zum Beispiel Java, Smalltalk, C++ oder dergleichen, und herkömmlicher prozeduraler Programmiersprachen, wie zum Beispiel der Programmiersprache „C“, oder ähnlicher Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als ein alleinstehendes Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem Ferncomputer oder vollständig auf dem Ferncomputer oder Server ausgeführt werden. In dem letztgenannten Szenario kann der Ferncomputer über eine beliebige Art von Netzwerk mit dem Computer des Benutzers verbunden sein, einschließlich eines Lokalnetzwerks (LAN) oder eines großflächigen Netzwerks (WAN), oder die Verbindung kann mit einem externen Computer (zum Beispiel über das Internet unter Verwendung eines Internetdienstanbieters) hergestellt werden.
  • Die vorliegende Offenbarung wird unter Bezugnahme auf Flussdiagrammveranschaulichungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Flussdiagrammveranschaulichungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammveranschaulichungen und/oder Blockdiagrammen durch Computerprogrammanweisungen implementiert werden können. Diese Computerprogrammanweisungen können einem Prozessor eines Allgemeincomputers, Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Anweisungen, die über dem Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Implementieren der Funktionen/Handlungen erzeugen, die in dem/den Flussdiagramm- und/oder Blockdiagramm-Block oder -Blöcken spezifiziert sind.
  • Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert werden, die einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung anleiten können, auf eine spezielle Art und Weise zu fungieren, sodass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel erzeugen, der Anweisungsmittel beinhaltet, die die Funktion/Handlung implementieren, die in dem/den Flussdiagramm- und/oder Blockdiagramm-Block oder -Blöcken spezifiziert sind.
  • Die Computerprogrammanweisungen können auch auf einen Computer oder eine andere programmierbare Datenverarbeitungsvorrichtung geladen werden, um zu bewirken, dass eine Reihe von Operationsschritten auf dem Computer oder der anderen programmierbaren Vorrichtung durchgeführt werden, damit ein computerimplementierter Prozess erzeugt wird, sodass die Anweisungen, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Prozesse zum Implementieren der Funktionen/Handlungen bereitstellen, die in dem/den Flussdiagramm- und/oder Blockdiagramm-Block oder -Blöcken spezifiziert sind.
  • Die Flussdiagramme und Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen der Systeme, Verfahren und Computerprogrammprodukte gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung. Angesichts dessen kann jeder Block in den Flussdiagrammen oder Blockdiagrammen ein Modul, ein Segment oder einen Teil von Code repräsentieren, das bzw. der eine oder mehrere ausführbare Anweisungen zum Implementieren der spezifizierten Logikfunktion(en) umfasst. Es sollte auch angemerkt werden, dass bei manchen alternativen Implementierungen die in dem Block angemerkten Funktionen nicht in der in den Figuren angemerkten Reihenfolge stattfinden können. Zwei nacheinander dargestellte Blöcke können zum Beispiel tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in Abhängigkeit von der einbezogenen Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es wird auch angemerkt, dass jeder Block der Blockdiagramme und/oder der Flussdiagrammveranschaulichung und Kombinationen von Blöcken in den Blockdiagrammen und/oder der Flussdiagrammveranschaulichung durch hardwarebasierte Spezialsysteme, die die spezifizierten Funktionen oder Handlungen durchführen, oder Kombinationen von Spezialhardware und Computeranweisungen implementiert werden können.
  • Die hierin verwendete Terminologie dient nur dem Zweck des Beschreibens von speziellen Ausführungsbeispielen und ist nicht als Einschränkung der Offenbarung beabsichtigt. So wie sie hierin verwendet werden, sollen die Singularformen „ein“, „eine“ und „der/die/das“ auch Pluralformen umfassen, es sei denn, dass der Zusammenhang eindeutig etwas anderes angibt. Es versteht sich ferner, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn in dieser Patentschrift verwendet, das Vorhandensein aufgeführter Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente und/oder Komponenten spezifiziert, aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon ausschließt.
  • Ausführungsformen können als ein Computerprozess, ein Rechensystem oder als ein Herstellungsartikel wie etwa ein Computerprogrammprodukt von computerlesbaren Medien implementiert werden. Das Computerprogrammprodukt kann ein Computerspeicherungsmedium sein, das durch ein Computersystem lesbar ist und Computerprogrammanweisungen zum Ausführen eines Computerprozesses codiert.
  • Die entsprechenden Strukturen, das entsprechende Material, die entsprechenden Handlungen und Äquivalente aller Mittel oder Schritte plus Funktionselemente in den untenstehenden Ansprüchen sollen eine beliebige Struktur, ein beliebiges Material oder eine beliebige Handlung zum Durchführen der Funktion in Kombination mit anderen beanspruchten Elementen beinhalten, und werden spezifisch beansprucht. Die Beschreibung der vorliegenden Offenbarung ist für Veranschaulichungs- und Beschreibungszwecke dargelegt worden, aber es wird nicht beabsichtigt, dass sie vollständig oder für die Offenbarung in der offenbarten Formen beschränkend ist. Viele Modifikationen und Variationen werden Durchschnittsfachleuten ersichtlich, ohne vom Schutzumfang und Gedanken der Offenbarung abzuweichen. Die Ausführungsform wurde gewählt und beschrieben, um die Prinzipien der Offenbarung und die praktische Anwendung am besten zu erläutern und um anderen Durchschnittsfachleuten zu ermöglichen, die Offenbarung für Ausführungsformen mit verschiedenen Modifikationen zu verstehen, wie sie sich für die spezielle in Erwägung gezogene Verwendung eignet.
  • Somit sind verschiedene Ausführungsbeispiele der vorliegenden Offenbarung beschrieben worden, einschließlich unter anderem:
  • BEISPIELE
  • Beispiel 1 ist ein CA/AD-Fahrzeug (CA/AD: computer-assisted or autonomous driving - computergestütztes oder autonomes Fahren), das Folgendes umfasst: eine Andockplattform, um ein oder mehrere unbemannte Luftfahrzeuge (UAVs) unterschiedlicher Typen zum Andocken an dem CA/AD-Fahrzeug zu empfangen, wobei jedes UAV mindestens einen Sensor beinhaltet, der für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet ist, und eine UAV-Schnittstelle, um mit dem einen oder den mehreren angedockten UAVs zu kommunizieren, einschließlich zum Empfangen von Sensordaten, die durch das eine oder die mehreren UAVs erhalten werden. Das CA/AD-Fahrzeug wird zumindest teilweise basierend auf dem einen oder den mehreren an dem CA/AD-Fahrzeug angedockten UAVs für eine spezifische Verwendung konfiguriert.
  • Beispiel 2 ist die Vorrichtung des Beispiels 1, ferner umfassend eine Hauptfahrzeugplattform, die allen Verwendungen, für die das CA/AD-Fahrzeug konfiguriert werden kann, gemein ist.
  • Beispiel 3 ist die Vorrichtung des Beispiels 1, ferner umfassend eine Hardwaremodulschnittstelle, die an dem CA/AD-Fahrzeug angeordnet ist, um mit mindestens einem mehrerer Hardwaremodule verbunden zu werden, um ferner das CA/AD-Fahrzeug für die spezifische Verwendung zu konfigurieren.
  • Beispiel 4 ist die Vorrichtung des Beispiels 3, wobei die Hardwaremodulschnittstelle mindestens einen Port zum Empfangen des einen Hardwaremoduls mit einem SECC-Formfaktor (SECC: single edge contact cartridge - Single-Edge-Kontakt-Patrone) beinhaltet.
  • Beispiel 5 ist die Vorrichtung des Beispiels 3, wobei die Hardwaremodulschnittstelle mehrere Ports beinhaltet, jeweils zum Verbinden mit einem Schaltkreis des Hardwaremoduls, der einen vordefinierten Typ von Steuerung bereitstellt.
  • Beispiel 6 ist die Vorrichtung des Beispiels 5, wobei der vordefinierte Typ von Steuerung entweder eine Umgebungssteuerung, eine Kommunikationssteuerung oder eine Berechnungssteuerung ist.
  • Beispiel 7 ist die Vorrichtung des Beispiels 1, wobei die Andockplattform ferner dazu ausgelegt ist, ein oder mehrere Lieferungs-UAVs zu empfangen, die zum Liefern von Paketen vom CA/AD-Fahrzeug zu einem Kunden zu verwenden sind.
  • Beispiel 8 ist die Vorrichtung des Beispiels 7, ferner umfassend eine Hardwaremodulschnittstelle, die an dem CA/AD-Fahrzeug angeordnet ist, um mit mindestens einem mehrerer Hardwaremodule verbunden zu werden, um ferner das CA/AD-Fahrzeug für eine spezifische Verwendung der Paketlieferung zu konfigurieren.
  • Beispiel 9 ist die Vorrichtung des Beispiels 1, wobei die Andockplattform ferner dazu ausgelegt ist, ein oder mehrere Lieferungs-UAVs zu empfangen, um zusätzliche Fahrzeugteile oder -ausrüstung zum CA/AD-Fahrzeug zu liefern, die für die spezifische Verwendung benötigt werden.
  • Beispiel 10 ist die Vorrichtung des Beispiels 9, ferner umfassend einen Roboterarm zum Greifen der zusätzlichen Fahrzeugteile oder -ausrüstung, und diese entweder dem CA/AD-Fahrzeug bereitzustellen oder auf diesem zu installieren.
  • Beispiel 11 ist die Vorrichtung des Beispiels 1, wobei die spezifische Verwendung entweder ein Nachtüberwachungsdienst, ein Taxidienst, ein entfernter Paketlieferdienst oder ein Krankenwagendienst ist.
  • Beispiel 12 ist die Vorrichtung des Beispiels 1, ferner umfassend einen Sendeempfänger zum Empfangen eines spezifischen Verwendungsauftrags von einem Dienstzentrum und zum Bestätigen seines Empfangs.
  • Beispiel 13 ist die Vorrichtung des Beispiels 12, wobei der spezifische Verwendungsauftrag eine Identifikation des einen oder der mehreren UAVs beinhaltet, die an der Andockplattform anzudocken sind.
  • Beispiel 14 ist die Vorrichtung des Beispiels 1, wobei die spezifische Verwendung, für die das CA/AD-Fahrzeug konfiguriert ist, geändert wird, während sich das CA/AD-Fahrzeug in Bewegung befindet.
  • Beispiel 15 ist ein UAV zum Konfigurieren eines CA/AD-Fahrzeugs, das Folgendes umfasst: einen oder mehrere Sensoren, die für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet sind; und einen Andockmechanismus zum sicheren Andocken des UAV an dem CA/AD-Fahrzeug; wobei das CA/AD-Fahrzeug für die spezifische Verwendung zumindest teilweise basierend auf dem an dem CA/AD-Fahrzeug angedockten UAV konfiguriert wird.
  • Beispiel 1 ist das UAV des Beispiels 15, ferner umfassend eine CA/AD-Fahrzeugschnittstelle zum Kommunizieren mit dem CA/AD-Fahrzeug, einschließlich zum Übertragen von Sensordaten, die durch das UAV erhalten werden.
  • Beispiel 17 ist das UAV des Beispiels 15, wobei das UAV ein Lieferungs-UAV ist, um dem CA/AD-Fahrzeug Teile oder Ausrüstung für die spezifische Verwendung bereitzustellen.
  • Beispiel 18 ist das UAV des Beispiels 15, wobei entweder die spezifische Verwendung eine Nachterfassung ist und der eine oder die mehreren Sensoren einen Infrarotsensor und/oder einen Nachtsichtsensor und/oder eine Nachtsichtkamera beinhalten; oder die spezifische Verwendung ein autonomes Fahren ist und der eine oder die mehreren Sensoren einen hochpräzisen Positionierungssensor und/oder LIDAR und/oder eine Millimeterwellen(MM-Wellen)-Positionierungseinrichtung beinhalten.
  • Beispiel 19 ist ein Verfahren zum Betreiben eines dynamisch rekonfigurierbaren CA/AD-Fahrzeugs, umfassend: Empfangen, durch das CA/AD-Fahrzeug, eines oder mehrerer UAVs unterschiedlicher Typen, die an dem CA/AD-Fahrzeug anzudocken sind, wobei jedes UAV einen oder mehrere Sensoren beinhaltet, die für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet sind; Andocken des einen oder der mehreren UAVs an eine Andockplattform des CA/AD-Fahrzeugs; und Verbinden des CA/AD-Fahrzeugs über eine UAV-Schnittstelle des CA/AD-Fahrzeugs mit dem einen oder den mehreren UAVs, um Sensordaten von jedem des einen oder der mehreren Sensoren des einen oder der mehreren UAVs zu erhalten, wobei die Sensordaten im Betrieb des CA/AD-Fahrzeugs gemäß der konfigurierbaren spezifischen Verwendung verwendet werden.
  • Beispiel 20 ist das Verfahren des Beispiels 19, ferner umfassend: Verbinden, über eine Hardwaremodulschnittstelle, die an dem CA/AD-Fahrzeug angeordnet ist, der Schnittstelle einschließlich eines oder mehrerer Ports mit mindestens einem mehrerer Hardwaremodule, die in einen Port der Schnittstelle eingesteckt werden, wobei mindestens ein Hardwaremodul das CA/AD für die spezifische Verwendung zusätzlich konfigurieren soll.
  • Beispiel 21 ist das Verfahren des Beispiels 19, wobei das Empfangen eines oder mehrerer UAVs unterschiedlicher Typen ein Empfangen eines oder mehrerer Lieferungs-UAVs beinhaltet, um Teile oder Ausrüstung bereitzustellen, die für die spezifische Verwendung benötigt werden.
  • Beispiel 22 ist das Verfahren des Beispiels 19, wobei die spezifische Verwendung, für die das CA/AD-Fahrzeug konfiguriert ist, geändert wird, während sich das CA/AD-Fahrzeug in Bewegung befindet.
  • Beispiel 23 ist das Verfahren des Beispiels 22, wobei entweder die spezifische Verwendung eine Nachterfassung ist und der eine oder die mehreren Sensoren einen Infrarotsensor und/oder einen Nachtsichtsensor und/oder eine Nachtsichtkamera beinhalten; oder die spezifische Verwendung ein autonomes Fahren ist und der eine oder die mehreren Sensoren einen hochpräzisen Positionierungssensor und/oder LIDAR und/oder eine Millimeterwellen(MM-Wellen)-Positionierungseinrichtung beinhalten.
  • Beispiel 24 ist ein System, das Folgendes umfasst: einen Satz von UAVs, wobei jedes UAV des Satzes einen oder mehrere Sensoren beinhaltet, die für eine spezifische Verwendung eines dynamisch rekonfigurierbaren CA/AD-Fahrzeugs (CA/AD: computergestütztes oder autonomes Fahren) ausgerichtet sind; und das dynamisch rekonfigurierbare CA/AD-Fahrzeug, das Folgendes umfasst: eine Andockplattform zum Andocken des Satzes von UAVs an dem CA/AD-Fahrzeug und dadurch Veranlassen, dass das CA/AD-Fahrzeug für die spezifische Verwendung konfiguriert wird; und eine UAV-Schnittstelle zum Kommunizieren mit dem Satz von UAVs, einschließlich zum Empfangen von Sensordaten, die durch jedes der UAVs in dem Satz erhalten werden, wobei die spezifische Verwendung, für die das CA/AD konfiguriert ist, geändert wird, indem der Satz von angedockten UAVs untereinander ersetzt wird.
  • Beispiel 25 ist das System des Beispiels 24, wobei das CA/AD-Fahrzeug ferner eine modulare Fahrzeugplattform umfasst, die allen der spezifischen Verwendungen, für die das CA/AD konfiguriert werden kann, gemein ist.
  • Beispiel 26 ist das System des Beispiels 24, wobei das CA/AD-Fahrzeug ferner eine Hardwaremodulschnittstelle umfasst, um mit mindestens einem mehrerer Hardwaremodule verbunden zu werden, die, wenn sie verbunden sind, ferner das CA/AD-Fahrzeug für die spezifische Verwendung konfigurieren.
  • Beispiel 27 ist das System des Beispiels 24, wobei die Andockplattform dazu eingerichtet ist, den Satz von UAVs anzudocken, während sich das CA/AD-Fahrzeug in Bewegung befindet.
  • Beispiel 28 ist eine Vorrichtung, die Folgendes umfasst: Mittel zum Empfangen eines oder mehrerer UAVs unterschiedlicher Typen, die an einem CA/AD-Fahrzeug anzudocken sind, wobei jedes UAV einen oder mehrere Sensoren beinhaltet, die für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet sind; Mittel zum Andocken des einen oder der mehreren UAVs an eine Andockplattform des CA/AD-Fahrzeugs; und Mittel zum Verbinden des CA/AD-Fahrzeugs über eine UAV-Schnittstelle des CA/AD-Fahrzeugs mit dem einen oder den mehreren UAVs, um Sensordaten von jedem des einen oder der mehreren Sensoren des einen oder der mehreren UAVs zu erhalten, wobei die Sensordaten im Betrieb des CA/AD-Fahrzeugs gemäß der konfigurierbaren spezifischen Verwendung verwendet werden.
  • Beispiel 29 ist die Vorrichtung des Beispiels 28, ferner umfassend: Mittel zum Verbinden, über ein Hardwaremodulschnittstellenmittel, das an dem CA/AD-Fahrzeug angeordnet ist, des Schnittstellenmittels einschließlich eines oder mehrerer Ports mit mindestens einem mehrerer Hardwaremodule, die in einen Port des Schnittstellenmittels eingesteckt werden, wobei mindestens ein Hardwaremodul das CA/AD für die spezifische Verwendung zusätzlich konfigurieren soll.
  • Beispiel 30 ist die Vorrichtung des Beispiels 28, wobei das Mittel zum Empfangen Mittel zum Empfangen des oder der mehreren Lieferungs-UAVs beinhaltet, um Teile oder Ausrüstung bereitzustellen, die für die spezifische Verwendung benötigt werden.
  • Beispiel 31 ist die Vorrichtung des Beispiels 28, wobei entweder die spezifische Verwendung eine Nachterfassung ist und der eine oder die mehreren Sensoren einen Infrarotsensor und/oder einen Nachtsichtsensor und/oder eine Nachtsichtkamera beinhalten; oder die spezifische Verwendung ein autonomes Fahren ist und der eine oder die mehreren Sensoren einen hochpräzisen Positionierungssensor und/oder LIDAR und/oder eine Millimeterwellen(MM-Wellen)-Positionierungseinrichtung beinhalten.

Claims (25)

  1. Vorrichtung für computergestütztes oder autonomes Fahren (CA/AD), umfassend: eine Andockplattform, die an einem CA/AD-Fahrzeug angeordnet ist, um ein oder mehrere unbemannte Luftfahrzeuge (UAVs) unterschiedlicher Typen zum Andocken an dem CA/AD-Fahrzeug zu empfangen, wobei jedes UAV mindestens einen Sensor beinhaltet, der für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet ist; und eine UAV-Schnittstelle, die an dem CA/AD-Fahrzeug angeordnet ist, zum Kommunizieren mit dem einen oder den mehreren angedockten UAVs, einschließlich zum Empfangen von Sensordaten, die durch das eine oder die mehreren UAVs erhalten werden, wobei das CA/AD-Fahrzeug zumindest teilweise basierend auf dem einen oder den mehreren an dem CA/AD-Fahrzeug angedockten UAVs für eine spezifische Verwendung konfiguriert wird.
  2. Vorrichtung nach Anspruch 1, ferner umfassend eine Hauptfahrzeugplattform, die allen Verwendungen, für die das CA/AD-Fahrzeug konfiguriert werden kann, gemein ist.
  3. Vorrichtung nach Anspruch 1, ferner umfassend eine Hardwaremodulschnittstelle, die an dem CA/AD-Fahrzeug angeordnet ist, um mit mindestens einem mehrerer Hardwaremodule verbunden zu werden, um ferner das CA/AD-Fahrzeug für die spezifische Verwendung zu konfigurieren.
  4. Vorrichtung nach Anspruch 3, wobei die Hardwaremodulschnittstelle mindestens einen Port zum Empfangen des einen Hardwaremoduls mit einem SECC-Formfaktor (SECC: single edge contact cartridge - Single-Edge-Kontakt-Patrone) beinhaltet.
  5. Vorrichtung nach Anspruch 3, wobei die Hardwaremodulschnittstelle mehrere Ports beinhaltet, jeweils zum Verbinden mit einem Schaltkreis des Hardwaremoduls, der einen vordefinierten Typ von Steuerung bereitstellt.
  6. Vorrichtung nach Anspruch 5, wobei der vordefinierte Typ von Steuerung entweder eine Umgebungssteuerung, eine Kommunikationssteuerung oder eine Berechnungssteuerung ist.
  7. Vorrichtung nach Anspruch 1, wobei die Andockplattform ferner dazu ausgelegt ist, ein oder mehrere Lieferungs-UAVs zu empfangen, die zum Liefern von Paketen vom CA/AD-Fahrzeug zu einem Kunden zu verwenden sind.
  8. Vorrichtung nach Anspruch 7, ferner umfassend eine Hardwaremodulschnittstelle, die an dem CA/AD-Fahrzeug angeordnet ist, um mit mindestens einem mehrerer Hardwaremodule verbunden zu werden, um ferner das CA/AD-Fahrzeug für eine spezifische Verwendung der Paketlieferung zu konfigurieren.
  9. Vorrichtung nach Anspruch 1, wobei die Andockplattform ferner dazu ausgelegt ist, ein oder mehrere Lieferungs-UAVs zu empfangen, um zusätzliche Fahrzeugteile oder -ausrüstung zum CA/AD-Fahrzeug zu liefern, die für die spezifische Verwendung benötigt werden.
  10. Vorrichtung nach Anspruch 9, ferner umfassend einen Roboterarm zum Greifen der zusätzlichen Fahrzeugteile oder -ausrüstung, und sie entweder dem CA/AD-Fahrzeug bereitzustellen oder auf diesem zu installieren.
  11. Vorrichtung nach Anspruch 1, wobei die spezifische Verwendung entweder ein Nachtüberwachungsdienst, ein Taxidienst, ein entfernter Paketlieferdienst oder ein Krankenwagendienst ist.
  12. Vorrichtung nach Anspruch 1, ferner umfassend einen Sendeempfänger zum Empfangen eines spezifischen Verwendungsauftrags von einem Dienstzentrum und zum Bestätigen seines Empfangs.
  13. Vorrichtung nach Anspruch 12, wobei der spezifische Verwendungsauftrag eine Identifikation des einen oder der mehreren UAVs beinhaltet, die an der Andockplattform anzudocken sind.
  14. Vorrichtung nach einem der Ansprüche 1-13, wobei die spezifische Verwendung, für die das CA/AD-Fahrzeug konfiguriert ist, geändert wird, während sich das CA/AD-Fahrzeug in Bewegung befindet.
  15. UAV zum Konfigurieren eines CA/AD-Fahrzeugs (CA/AD: computer-assisted or autonomous driving - computergestütztes oder autonomes Fahren), umfassend: einen oder mehrere Sensoren, die für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet sind; und einen Andockmechanismus zum sicheren Andocken des UAV an dem CA/AD-Fahrzeug; wobei das CA/AD-Fahrzeug zumindest teilweise basierend auf dem an dem CA/AD-Fahrzeug angedockten UAV für die spezifische Verwendung konfiguriert wird.
  16. UAV nach Anspruch 15, ferner umfassend eine CA/AD-Fahrzeugschnittstelle zum Kommunizieren mit dem CA/AD-Fahrzeug, einschließlich zum Übertragen von Sensordaten, die durch das UAV erhalten werden.
  17. UAV nach Anspruch 15, wobei das UAV ein Lieferungs-UAV ist, um dem CA/AD-Fahrzeug Teile oder Ausrüstung für die spezifische Verwendung bereitzustellen.
  18. UAV nach einem der Ansprüche 15-17, wobei entweder: die spezifische Verwendung Nachterfassung ist, und der eine oder die mehreren Sensoren einen Infrarotsensor und/oder einen Nachtsichtsensor und/oder eine Nachtsichtkamera beinhalten; oder die spezifische Verwendung ein autonomes Fahren ist, und der eine oder die mehreren Sensoren einen hochpräzisen Positionierungssensor und/oder LIDAR und/oder eine Millimeterwellen(MM-Wellen)-Positionierungseinrichtung beinhalten.
  19. Verfahren zum Betreiben eines dynamisch rekonfigurierbaren CA/AD-Fahrzeugs, umfassend: Empfangen, durch das CA/AD-Fahrzeug, eines oder mehrerer UAVs unterschiedlicher Typen, die an dem CA/AD-Fahrzeug anzudocken sind, wobei jedes UAV einen oder mehrere Sensoren beinhaltet, die für eine konfigurierbare spezifische Verwendung des CA/AD-Fahrzeugs ausgerichtet sind; Andocken des einen oder den mehreren UAVs an eine Andockplattform des CA/AD-Fahrzeugs; und Verbinden des CA/AD-Fahrzeugs über eine UAV-Schnittstelle des CA/AD-Fahrzeugs mit dem einen oder den mehreren UAVs, um Sensordaten von einem oder mehreren Sensoren des einen oder der mehreren UAVs zu erhalten, wobei die Sensordaten beim Betrieb des CA/AD-Fahrzeugs gemäß der konfigurierbaren spezifischen Verwendung verwendet werden.
  20. Verfahren nach Anspruch 19, das ferner Folgendes umfasst: Verbinden, über eine Hardwaremodulschnittstelle, die an dem CA/AD-Fahrzeug angeordnet ist, der Schnittstelle einschließlich eines oder mehrerer Ports mit mindestens einem mehrerer Hardwaremodule, die in einem Port der Schnittstelle eingesteckt werden, wobei mindestens ein Hardwaremodul das CA/AD für die spezifische Verwendung zusätzlich konfigurieren soll.
  21. Verfahren nach Anspruch 19 oder 20, wobei das Empfangen eines oder mehrerer UAVs unterschiedlicher Typen ein Empfangen eines oder mehrerer Lieferungs-UAVs beinhaltet, um Teile oder Ausrüstung bereitzustellen, die für die spezifische Verwendung benötigt werden.
  22. System, das Folgendes umfasst: einen Satz von UAVs, wobei jedes UAV des Satzes einen oder mehrere Sensoren beinhaltet, die für eine spezifische Verwendung eines dynamisch rekonfigurierbaren CA/AD-Fahrzeugs (CA/AD: computer-assisted or autonomous driving - computergestütztes oder autonomes Fahren) ausgerichtet sind; und das dynamisch rekonfigurierbare CA/AD-Fahrzeug, das Folgendes umfasst: eine Andockplattform zum Andocken des Satzes von UAVs an dem CA/AD-Fahrzeug, und dadurch Veranlassen, dass das CA/AD-Fahrzeug für die spezifische Verwendung konfiguriert wird; und eine UAV-Schnittstelle zum Kommunizieren mit dem Satz von UAVs, einschließlich zum Empfangen von Sensordaten, die durch jedes der UAVs in dem Satz erhalten werden, wobei die spezifische Verwendung, für die das CA/AD konfiguriert ist, durch das Ersetzen des Satzes von angedockten UAVs mit einem anderen geändert wird.
  23. System nach Anspruch 22, wobei das CA/AD-Fahrzeug ferner eine modulare Fahrzeugplattform umfasst, die allen der spezifischen Verwendungen, für die das CA/AD konfiguriert werden kann, gemein ist.
  24. System nach Anspruch 22, wobei das CA/AD-Fahrzeug ferner eine Hardwaremodulschnittstelle umfasst, um mit mindestens einem mehrerer Hardwaremodule verbunden zu werden, die, wenn sie verbunden sind, ferner das CA/AD-Fahrzeug für die spezifische Verwendung konfigurieren.
  25. System nach einem der Ansprüche 22-24, wobei die Andockplattform dazu eingerichtet ist, den Satz von UAVs anzudocken, während sich das CA/AD-Fahrzeug in Bewegung befindet.
DE102019121437.8A 2018-09-25 2019-08-08 Modulare konfigurierbare Plattformarchitektur für CA/AD-Fahrzeuge Pending DE102019121437A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/141,710 2018-09-25
US16/141,710 US20190047462A1 (en) 2018-09-25 2018-09-25 Modular configurable platform architecture for ca/ad vehicles

Publications (1)

Publication Number Publication Date
DE102019121437A1 true DE102019121437A1 (de) 2020-03-26

Family

ID=65274672

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019121437.8A Pending DE102019121437A1 (de) 2018-09-25 2019-08-08 Modulare konfigurierbare Plattformarchitektur für CA/AD-Fahrzeuge

Country Status (3)

Country Link
US (1) US20190047462A1 (de)
CN (1) CN110936882A (de)
DE (1) DE102019121437A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021200480B3 (de) 2021-01-20 2022-04-28 Volkswagen Aktiengesellschaft Kraftfahrzeugüberwachung durch Drohne

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11300978B1 (en) * 2018-07-09 2022-04-12 Carnegie Mellon University System, method, and computer program product for transporting an unmanned vehicle
US11929157B2 (en) * 2018-11-02 2024-03-12 Stryker Corporation Techniques for transporting autonomous patient support apparatuses and medical equipment to an incident scene
US10479528B1 (en) * 2018-11-06 2019-11-19 Ping Liang Network of distributed drone system and parking pads
US11099580B2 (en) * 2019-02-04 2021-08-24 Ford Global Technologies, Llc Systems and methods for providing navigation assistance to a delivery robot
US11391649B2 (en) * 2019-05-29 2022-07-19 Pony Ai Inc. Driving emulation system for an autonomous vehicle
US11597515B2 (en) * 2019-08-19 2023-03-07 Epazz, Inc. Charging/re-charging drone assembly system and apparatus
JP7238741B2 (ja) * 2019-11-21 2023-03-14 トヨタ自動車株式会社 システム、情報処理装置、及び、情報処理方法
US11584014B2 (en) 2020-01-23 2023-02-21 Ford Global Technologies, Llc Robotic apparatus for vehicle occupant protection
US20220157178A1 (en) * 2020-11-16 2022-05-19 Gm Cruise Holdings Llc Disaster and emergency surveillance using a distributed fleet of autonomous robots
US11919665B2 (en) * 2020-11-20 2024-03-05 TB2 Aerospace Unmanned aerial vehicles with cargo pods providing supplemental power and docking stations for recharging the cargo pods
CN113143605A (zh) * 2021-04-25 2021-07-23 杭州迅蚁网络科技有限公司 一种救护系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021200480B3 (de) 2021-01-20 2022-04-28 Volkswagen Aktiengesellschaft Kraftfahrzeugüberwachung durch Drohne

Also Published As

Publication number Publication date
US20190047462A1 (en) 2019-02-14
CN110936882A (zh) 2020-03-31

Similar Documents

Publication Publication Date Title
DE102019121437A1 (de) Modulare konfigurierbare Plattformarchitektur für CA/AD-Fahrzeuge
Campion et al. A review and future directions of UAV swarm communication architectures
US11538345B2 (en) Node of a blockchain airspace management system
US9933780B2 (en) Systems and methods for remote distributed control of unmanned aircraft
CN110853411B (zh) 单一飞行员驾驶系统及控制方法
DE102020118412A1 (de) Unabhängige sicherheitsüberwachung eines automatisierten fahrsystems
Nneji et al. Exploring concepts of operations for on-demand passenger air transportation
US20180096588A1 (en) System and method for workflow management in isolated environments
CN109116777A (zh) 汽车电子系统体系架构
DE112017006295T5 (de) Abholen und absetzen von fluggästen an einem flughafen unter verwendung eines autonomen fahrzeugs
Price et al. Urban air mobility operational concept (opscon) passenger-carrying operations
DE102019117616A1 (de) Handhabung von mitfahrdiensten bei autonomen fahrzeugen
CN110058564A (zh) 重新配置用于无人驾驶运载器的模块上系统的系统和方法
DE102020127254A1 (de) Verbesserte drohnenfahrzeugintegration und -steuerungen
DE102020100185A1 (de) Kraftfahrzeugsysteme mit mehreren drohnen und verwendungsverfahren
DE112017007989T5 (de) Anwendungsprioritätsbasierte energieverwaltung für eine computervorrichtung
EP3618400A2 (de) Systeme und verfahren zur kontextbewussten netzwerknachrichtenfilterung
DE102020100261A1 (de) Systeme, verfahren und vorrichtungen zur fahrzeugintegration von unbemannten luftfahrzeugsystemen
Si-Mohammed et al. Supporting unmanned aerial vehicle services in 5G networks: New high-level architecture integrating 5G with U-space
CN116405101A (zh) 低空数字资源和数字基础设施的监测管控处置系统及方法
Manju et al. Drones in smart cities
DE102016116860A1 (de) System und Verfahren zum Betreiben von autonom fahrenden Nutzfahrzeugen
DE102021117311A1 (de) Steuer- und Navigationsvorrichtung für ein autonom bewegtes System und autonom bewegtes System
Athavale et al. Chip-level considerations to enable dependability for eVTOL and Urban Air Mobility systems
DE112016006488T5 (de) System und verfahren zum bereitstellen eines mobilitätsnetzes