-
Die vorliegende Erfindung betrifft ein Verfahren zum Teleoperieren eines Fahrzeuges. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
(Teil)autonome Fahrzeuge nach dem Stand der Technik besitzen heute noch eine Fahrzeugführungsschnittstelle („Fahrerarbeitsplatz“) sowie setzen heute noch eine fahrtüchtige und zum Führen des Fahrzeuges autorisierte Person als Fahrzeuginsassen voraus, welche die Führung des Fahrzeugs bei Bedarf zu übernehmen vermag. Je nach Automatisierungsgrad und Technologiefortschritt ist es in Zukunft geplant abschnittsweise bzw. für die gesamte Fahrstrecke auf die Notwendigkeit der Übernahme eines fahrtüchtigen Fahrers innerhalb des Fahrzeugs in kritischen Situationen zu verzichten. Um dennoch mit Systemunwägbarkeiten bzw. -unzulänglichkeiten umgehen zu können, wird vor diesem Hintergrund in zahlreichen Forschungsprojekten am sogenannten teleoperierten Fahren (teleoperated driving, ToD) gearbeitet. Beim ToD kann die Fahraufgabe und/oder das Fahrzeug im Wege einer Fernsteuerung bei der Bewältigung von technischen Unzulänglichkeiten des (teil)autonomen Fahrsystems oder herausfordernder Szenarien - wie Umleitungen über alternative und unkonventionelle Fahrwege bzw. Routen o. ä. - durch einen externen Bediener in einer Leitstelle, den sogenannten Operator, zeitweise unterstützt und/oder gänzlich übernommen werden. Fahrzeug und Leitstelle bzw. deren Betreiber sind hierzu durch ein Mobilfunknetzwerk von geringer Latenz und hoher Datenrate miteinander verbunden.
-
US 9,494,935 B2 offenbart Computervorrichtungen, Systeme und Verfahren für die Fernbedingung eines autonomen Passagierfahrzeugs. Wenn ein autonomes Fahrzeug einer unerwarteten Umgebung wie z. B. einer Straßenbaustelle oder einem Hindernis begegnet, die für autonome Bedienung ungeeignet ist, können die Fahrzeugsensoren Daten über das Fahrzeug und die unerwartete Umgebung, einschließlich Bilder, Radar- und Lidar-Daten usw. erfassen. Die erfassten Daten können zu einem entfernten Bediener gesendet werden. Der entfernte Bediener kann das Fahrzeug manuell entfernt bedienen oder dem autonomen Fahrzeug Anweisungen erteilen, die von verschiedenen Fahrzeugsystemen ausgeführt werden sollen. Die zu dem entfernten Bediener gesendeten erfassten Daten können optimiert werden, um Bandbreite zu sparen, indem z. B. eine eingeschränkte Untermenge der erfassten Daten versendet wird.
-
Ein Fahrzeug gemäß
US 9,767,369 B2 kann ein oder mehrere Bilder einer Umgebung des Fahrzeugs empfangen. Das Fahrzeug kann auch eine Umgebungskarte erhalten. Das Fahrzeug kann auch mindestens ein Merkmal in den Bildern mit einem oder mehreren Merkmalen in der Karte abgleichen. Das Fahrzeug kann auch einen bestimmten Bereich in dem einen oder den mehreren Bildern identifizieren, der einem Teil der Karte entspricht, der sich in einem Schwellenabstand zu dem einen oder den mehreren Merkmalen befindet. Das Fahrzeug kann auch das eine oder die mehreren Bilder bzw. Sensorsignale komprimieren, um eine geringere Menge an Details in den Aufnahmebereichen als dem gegebenen Bereich aufzunehmen. Das Fahrzeug kann die komprimierten Bilder auch einem entfernten System bereitstellen und darauf ansprechend Betriebsanweisungen von dem entfernten System empfangen.
-
Systeme und Verfahren gemäß
US 9,465,388 B1 ermöglichen es einem autonomen Fahrzeug, Hilfe von einem entfernten Bediener anzufordern, wenn das Vertrauen des Fahrzeugs in den Betrieb gering ist oder ein technisches Problem oder eine technische Unzulänglichkeit oder es eine externe Situation erfordert. Ein beispielhaftes Verfahren umfasst das Betreiben eines autonomen Fahrzeugs in einem ersten autonomen Modus. Das Verfahren kann auch das Identifizieren einer Situation umfassen, in der ein Vertrauensniveau eines autonomen Betriebs im ersten autonomen Modus unter einem Schwellenwertniveau liegt. Das Verfahren kann ferner das Senden einer Anfrage zur Unterstützung an einen entfernten Assistenten umfassen, wobei die Anfrage Sensordaten einschließt, die einen Teil einer Umgebung des autonomen Fahrzeugs darstellen. Das Verfahren kann zusätzlich das Empfangen einer Antwort von dem entfernten Assistenten umfassen, wobei die Antwort einen zweiten autonomen Betriebsmodus angibt. Das Verfahren kann auch bewirken, dass das autonome Fahrzeug in der zweiten autonomen Betriebsart gemäß der Antwort von dem entfernten Assistenten arbeitet.
-
US 9,720,410 B2 offenbart ein weiteres Verfahren zur Fernunterstützung für autonome Fahrzeuge in vorbestimmten Situationen.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Teleoperieren eines Fahrzeuges, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes maschinenlesbares Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Ein Vorzug dieser Lösung liegt in der eröffneten Möglichkeit einer (optimierten) Zuordnung von Operatoren für das teleoperierte Fahren zu automatisierten Fahrzeugen, die diese Dienstleistung anfordern bzw. schon verwenden, und dem dynamischen Wechsel dieser Operatoren. Hierzu werden vorhandene Kommunikationsressourcen und ToD-Dienstleister (service provider) erfasst und bewertet, um eine effiziente Verwendung dieser Ressourcen gewährleisten zu können. Durch Verwendung von redundanten Übertragungswegen und Vermittlung zwischen den ToD-Service-Providern können geringe Latenzen gewährleistet werden, was einen nahtlosen Wechsel der ToD-Service-Provider ermöglicht. Hierdurch kann teleoperiertes Fahren auch unter schwierigen Randbedingungen durchgeführt bzw. können durch entsprechende Verteilung auf verfügbare ToD-Service-Provider möglichst viele Fahrzeuge gleichzeitig bedient werden. Für die initiale Vermittlung unter Berücksichtigung der für den Fahrbetrieb notwendigen und vorhandenen Ressourcen zwischen Fahrzeug und Operator sowie die Übergabe von bereits gesteuerten Fahrzeugen zwischen den verschiedenen Service-Providern kommt ein Dispatcher zum Einsatz.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass die Dienstleistungsunternehmen jeweils eine oder mehrere (örtlich verteilte bzw. Kompetenz- und aufgabenorientierte) Leitstellen betreiben, deren Operatoren durch einen (automatisierten oder menschlichen oder einer Kombination aus beiden) Leitstellendisponenten zugeteilt werden. Der Disponent verwaltet sämtliche Ressourcen und Fähigkeiten seiner Leitstelle(n) und meldet diese zusammen mit deren Verfügbarkeit dem bzw. den Dispatcher Services. Je nach Größe des Unternehmens (Anzahl der Leitstellen) können auch unternehmensinterne Dispatcherfunktionen realisiert sein, speziell, wenn Flottenbetreiber ihr eigenes Leitstellennetz betreiben. Auf diese Weise wird eine skalierungsfähige ToD-Lösung geschaffen, die durch Nutzung von Dispatcher-Services (unter Verwendung einer zentralisierten oder auch in Kombination mit einer verteilten bzw. hierarchisch aufgebauten Dispatcher-Architektur) simultane ToD-Anfragen für eine Vielzahl von Fahrzeugen zeiteffizient und bedarfsgerecht bearbeiten kann. Hierbei werden durch Analyse, Verwaltung und kooperative Nutzung verschiedener Übertragungswege, vorhandener ToD-Service-Provider-Ressourcen und ToD-Operatoren, der notwendigen ToD-Unterstützung sowie der ToD-Qualifikation ToD-Anfragen und ToD-Operatoren zusammengeführt.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass zur Übergabe (handover) der Steuerfunktion von einem ersten Operator an einen zweiten Operator der zweite Operator die Steuerfunktion vom ersten Operator anfordert, wobei die Übergabe erst vollzogen wird, wenn der zweite Operator die Steuerfunktion vollständig übernommen hat. Ein Vorteil dieser Ausführungsform ist die Realisierung eines nahtlosen Wechsels des Operators auch während eines laufenden Fahrmanövers, um abhängig von benötigter ToD-Fahrsituation, Gefährdungsstufe und Ortskenntnissen den passenden Operator mit entsprechender Freigabestufe (Eignung) verwenden zu können.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
- 1 schematisch ein mit der Cloud verbundenes Fahrzeug.
- 2 das Blockdiagramm einer Infrastruktur.
- 3 das Flussdiagramm eines Verfahrens.
- Ausführungsformen der Erfindung
-
1 illustriert einen Grundgedanken der nachfolgend im Einzelnen vorgestellten Lösung: Gerät ein automatisiertes Fahrzeug (11) in eine Situation, die es nicht selbständig zu bewältigen vermag oder erkennt es eine Systemdegradation (z.B. mittels seines Fahrzeugdiagnosesystems), die eine Unterstützung erfordert, sendet es eine Assistenz-Anfrage an einen sogenannten Dispatcher (20). Der Dispatcher (20) bewertet den vom Fahrzeug (11) übermittelten Fehlergrund oder analysiert die Situation des Fahrzeuges (11) anhand der ihm vorliegenden Fahrzeug-, Fehler- oder Sensordaten und leitet die Anfrage an einen ToD-Service-Provider weiter, welcher die notwendigen Operator-Ressourcen und Fähigkeiten besitzt, um das Fahrzeug (11) wieder in den regulären Fahrbetrieb zu versetzen bzw. einen betriebssicheren Zustand (safe state) herbeizuführen, falls es die Umstände - z. B. aufgrund von Defekten - nicht mehr erlauben, das Fahrzeug (11) weiter in Betrieb zu halten.
-
Das Fahrzeug (11) bekommt hierzu spätestens beim Start der automatisierten Fahrfunktion eine Rangliste von Dispatchern (20) übermittelt. Aus Sicherheitsgründen werden hierbei Grundprinzipien der Redundanz angewendet, indem beispielsweise mehrere Listen und Dispatcher-Service-Center genutzt werden. Es kann auch mehrere derartige Listen geben, die je nach Fehler-Kritikalität herangezogen werden, um in Notfällen gezielt eine Direktverbindung herzustellen. Diese Listen werden regelmäßig z.B. auch entsprechend der Fahrzeugposition und Verfügbarkeit der Dispatcher aktualisiert.
-
Gerät das Fahrzeug (11) während des Fahrbetriebes in einen nicht spezifizierten Zustand bzw. wird eine technische Unzulänglichkeit oder der Bedarf einer Fernunterstützung durch das Fahrzeug festgestellt, sendet es an den ersten Dispatcher (20) aus dieser Liste die Anfrage, die Fahrfunktion einem zu einem ToD-Service-Provider gehörigen Operator (12) zu übertragen. Diese Anfrage beinhaltet typischerweise die folgenden Informationen:
- • das Umfeld des Fahrzeuges (11), etwa dessen Ort und von ihm erkannte Objekte,
- • die geplante Route oder einschlägige Betriebsmodi,
- • den Fahrzeugtyp und -hersteller oder die Fahrzeugkonfiguration,
- • die im Wege einer Gefahrenanalyse beispielsweise hinsichtlich Gefahrenpotential und Zeitfenster durch Fahrzeug (11) oder Dispatcher (20) ermittelte Kritikalität, wobei mindestens die Überführung in einen sicheren Zustand anzustreben ist,
- • die Kommunikationsqualität oder eine Klassifizierung des Ü bertragu ngskanals,
- • etwaige durch das Fahrzeug (11) erkannte Fehler bzw. Art und Umfang der gewünschten Dienstleistung sowie
- • ggf. Software- und Hardware-Versionen einzelner im Fahrzeug (11) verbauter Komponenten (13, 14), die für die ToD-Funktionalität notwendig sind bzw. eine Auswirkung auf selbige haben könnten.
-
Bei der Klassifizierung der Übertragungskanäle (Typisierung) und der damit verbundenen Festlegung derer Eignung für ein erfindungsgemäßes Verfahren sind Informationen über Latenz, Bandbreite, effektiven Datendurchsatz (abhängig von der Bitfehlerrate) und Netzabdeckung des Übertragungsmediums im gesamten Einsatzgebiet wünschenswert. Auch kann die im Fahrzeug ermittelte Quality of Service des Übertragungskanals entsprechend herangezogen werden.
-
2 illustriert eine erfindungsgemäße Infrastruktur in ihrer Gesamtheit. Als deren Kernkomponente vermittelt der Dispatcher (20) Anfragen zwischen den durch die ToD-Service-Provider (18) bereitgestellten Operatoren (12) und die durch die Fahrzeuge (11) benötigten ToD-Ressourcen. Viele verschiedene Fahrzeuge (11) werden vielen verschiedenen Operatoren (12) der ToD-Service-Provider (18) anhand deren - durch vorhandene Ressourcen und Fähigkeiten bestimmbare - Eignung zugeordnet, was eine optimale Auslastung ermöglicht. Die ToD-Service-Provider (18) senden hierzu u. a. die folgenden Statusinformationen in regelmäßigen Abständen bzw. Änderungen an die Dispatcher (20):
- • unterstützte Fahrsituationen,
- • unterstützte Gefährdungsstufen,
- • vorhandene Ortskenntnisse,
- • aktuell verfügbare Operatoren (12) mit entsprechenden Fähigkeiten,
- • aktuell vorhandenes geeignetes Equipment bzw.
- • unterstützte Fahrzeugtypen.
-
Der Dispatcher (20) vermittelt die Übergabe von ToD-Anfragen aus den Fahrzeugen (11) an die ToD-Service-Provider (18) und deren geeignete Operatoren (12). Der Dispatcher (20) kann zudem während eines laufenden Fahrmanövers einen Handover sowohl zwischen ToD-Service-Providern (18) als auch zwischen Operatoren (12) ermöglichen, um deren nahtlosen Wechsel zu ermöglichen und die Latenz selbst bei der Teleoperation eines beweglichen Fahrzeuges (11) zu minimieren. Alle Operationen erfolgen aus Sicherheitsgründen vorzugsweise unter Verwendung von redundanten Übertragungswegen. Außerdem steuert der Dispatcher (20) die kooperative Nutzung von Übertragungskanälen durch Abstimmung unter allen aktuellen Teilnehmern. Zur Bewertung der Übertragungskapazitäten ist eine Klassifizierung der Übertragungskanäle wünschenswert. Des Weiteren ist es empfehlenswert, die in Abhängigkeit von der Art der Steuerfunktion (14) benötigten Ressourcen zu bestimmen. Hierdurch ist es möglich, zu ermitteln, ob eine Steuerung überhaupt durchführbar ist oder sogar mehrere Steuerungen zeitgleich möglich sind. Nach der Identifikation der für die anstehenden Steuerfunktionen benötigten Übertragungsressourcen unter Berücksichtigung von Merkmalen wie Technologie (Latenz), Bandbreite und Redundanz (funktionale Sicherheit) können diese durch den Dispatcher systemübergreifend z.B. unter Verwendung einer gemeinsamen Datenbank reserviert und dem Fahrzeug (11) und ToD-Service-Providern (18) zur Umsetzung des Fahrmanövers bzw. der Fahrfunktion zugeteilt werden.
-
In Abhängigkeit von den oben genannten Eigenschaften und der Verfügbarkeit bzw. Schulung der Operatoren (12) sind für eine ToD-Operation entweder ganze Fahrmanöver in Echtzeit (realtime) bis zu bestimmten Geschwindigkeiten, oder nur die Freigabe einzelner Aktionen oder ggf. nur die Übermittlung von Trajektorien für ein Fahrzeug (11) oder nur ein Monitoring von Sensorinformationen möglich. In Abhängigkeit von den oben genannten Eigenschaften und der Verfügbarkeit bzw. Schulung der Operatoren (12) sind die verschiedenen ToD-Operationen für verschiedene Fahrzeuge möglicherweise zeitgleich oder nur sequenziell entsprechend einer Priorisierung durch Dispatcher realisierbar.
-
Sämtliche hier beschriebenen Aktionen sollten unter Berücksichtigung der funktionalen Sicherheit (FuSi) stattfinden. Eine Protokollierung der durchgeführten Aktionen, wie sie etwa in der Luftfahrt mittels einer sogenannten Blackbox praktiziert wird, sollte im Fahrzeug (11) bzw. auch zusätzlich beim ToD-Service-Provider (18) erfolgen.
-
Die reguläre Arbeitsweise eines Dispatchers (20) bei der Kopplung eines Fahrzeuges (11) mit einem ToD-Operator (12) sei nunmehr unter zusätzlicher Bezugnahme auf 3 erläutert:
- 1. Alle verfügbaren ToD-Service-Provider (18) senden die ihnen verfügbaren Informationen an den Dispatcher (20). In Betracht kommen etwa die jeweiligen Kapazitäten und Leistungen mit Preisangaben sowie das Gebiet, in dem der Service angeboten wird (Prozess 1 - 3).
- 2. Eine Kommunikationseinheit (13) im Fahrzeug (11) sammelt Informationen und sendet sie an den Dispatcher (20). Zu denken ist hierbei an Art und Anzahl der Übertragungsstrecken einschließlich deren Klassifizierung, aktuelle Situation (Geschwindigkeit, Ort, Route, Art der Ablaufstörung, Einschätzung der Kritikalität einer Fahrsituation, usw.), Service-Vertragsinformationen, Fahrzeugtyp sowie Hard- und Software-Stände (Prozess 2 - 3).
- 3. Der Dispatcher (20) sendet eine Liste mit geeigneten und verfügbaren Operatoren (12) passender Freigabestufe und mit entsprechend ausreichenden auf das Fahrzeug abgestimmte Übertragungsressourcen einschließlich deren Kosten an das Fahrzeug (11) (Prozess 3 - 3).
- 4. Die Auswahl des Operators (12) erfolgt automatisch (basierend auf hinterlegten Auswahlkriterien) oder manuell durch einen Fahrzeuginsassen über eine übertragene Auswahlliste (Prozess 4 - 3).
- 5. Der Dispatcher (20) reserviert die für die Art der Steuerung notwendigen Übertragungsressourcen unter Berücksichtigung von Technologie (Latenz), Bandbreite und Redundanz (funktionale Sicherheit).
- 6. Der Dispatcher (20) sendet eine Übernahme-Aufforderung (request) an den Operator (Prozess 5 - 3).
- 7. Der Operator (12) nimmt den Auftrag an und verbindet sich mit dem Fahrzeug (Prozess 6 - 13).
- 8. Der Operator (12) übernimmt die Monitoring- oder Steuerfunktion (14) des Fahrzeuges je nach erlaubter Freigabestufe und Übertragungsqualität (Prozess 7 - 13).
-
Ein Handover zwischen Service-Providern (18) - z. B. weil ein Fahrzeug (11) den Wechseln in neuen Zuständigkeitsbereich eines Service-Providers (18) erkennt - könnte sodann wie folgt verlaufen:
- 1. Stellt das ferngesteuerte Fahrzeug (11) fest, dass das Fahrzeug den Zuständigkeitsbereich des aktuellen Operators / ToD-Service-Providers (18) verlassen wird oder verlassen hat, sendet die Kommunikationseinheit (13) im Fahrzeug (11) eine entsprechende ToD-Anfrage mit den relevanten Informationen zur Fahrsituation an den Dispatcher (20).
- 2. Der Dispatcher (20) sendet eine Liste mit möglichen Operatoren (12) einschließlich deren Kosten an das Fahrzeug (11). Der aktuelle ToD-Operator (12) wird darüber informiert und kann je nach Situation einem Wechsel zum aktuellen Zeitpunkt widersprechen.
- 3. Das Fahrzeug (11) mit seiner Kommunikationseinheit (13) und ToD-System wählt selbständig einen entsprechenden neuen Service-Provider (18) aus oder bittet den Fahrzeuginsassen, einen neuen Service-Provider (18) auszuwählen. Erfolgt die Auswahl je nach Fahrsituation nicht rechtzeitig, kann der ToD-Operator (12) eine Auswahl treffen bzw. der ToD-Operator (12) wird aufgefordert das Fahrzeug (11) in einen sicheren Zustand zu überführen. Es erfolgt eine entsprechende Rückmeldung an den Dispatcher (20).
- 4. Der Dispatcher (20) kontaktiert daraufhin die Operatoren (12) und informiert sie über den anstehenden Wechsel.
- 5. Der erste Operator (12) transferiert sämtliche für den ToD-Fahrbetrieb notwendigen Daten an den zweiten Operator (12).
- 6. Der zweite Operator (12) verbindet sich mit dem Fahrzeug (11) und macht sich - ggf. in telefonischer Absprache mit dem ersten Operator (12) - mit der Fahrsituation vertraut.
- 7. Wenn der zweite Operator (12) zur Übernahme bereit ist, sendet er einen Request zur finalen Übergabe der Steuerung an den ersten Operator (12), der diesen bestätigen muss. Nach der Bestätigung übernimmt damit auch der zweite Operator symbolisch die Verantwortung.
- 8. Der erste Operator (12) kann sich noch eine gewisse Zeit lang vergewissern, dass der zweite Operator (12) die Situation beherrscht, und beendet hernach die Verbindung zum Fahrzeug (11). Hierdurch werden seine Ressourcen wieder freigegeben. Falls es dem zweiten Operator (12) nicht gelingt, die Situation zu beherrschen, kann ein Request zur Rück-Übernahme an den ersten Operator zurückgesendet werden. Der erste Operator muss diesen Request bestätigen. Damit wird die Verantwortung symbolisch vom zweiten an den ersten Operator (12) zurückübertragen, der somit die Steuerung - ggf. unter Einbußen hinsichtlich der Servicequalität oder Inkaufnahme eines höheren Ressourcenverbrauches - wieder übernimmt, der Dispatcher (20) vermittelt - gemäß dem im Folgenden beleuchteten Verfahren - einen neuen, dritten Operator (12) oder der erste Operator (12) versetzt das Fahrzeug (11)
- - etwa durch Parken - in einen sicheren Zustand, falls er die aktuelle Fahrsituation nicht länger beherrscht.
-
Ein Handover zwischen ToD-Operatoren (12) - z. B. weil ein ToD-Operator (12) seine gegenwärtige Aufgabe nicht abschließen kann, z. B. weil ein Operator nicht die notwendige Freigabestufe (Qualifikationsstufe besitzt) oder weil Fahrzeug Zuständigkeitsbereich des ToD-Operators verlässt - gestaltet sich auf dieser Grundlage folgendermaßen:
- 1. Der ToD-Operator (12) steuert ein Fahrzeug (11), kann diese Steuerung jedoch nicht fortsetzen, z. B. weil hierzu eine höhere Qualifikation notwendig ist oder er ein Problem nicht selbstständig lösen kann oder er feststellt, dass das Fahrzeug seinen Zuständigkeitsbereich verlässt.
- 2. Der ToD-Operator (12) initiiert einen Wechsel des Operators (12) oder Service-Providers (18), indem er eine diesbezügliche Aufforderung unter Konkretisierung der notwendigen Unterstützung und Qualifikation des neuen, zweiten Operators (12) oder Providers (18) entweder über das Fahrzeug (11) zur Bestätigung und Weiterleitung an den Dispatcher (20) zurücksendet oder entsprechend bestehender Service-Verträge zur Neuvergabe des ToD-Auftrags direkt an den Dispatcher (20) sendet. Aus Sicherheitsgründen kann der erste ToD-Operator (12) einen Wechsel auch unter Benennung eines direkten geeigneten zweiten ToD-Operators (12) im nahen Umfeld des ersten ToD-Operators (12) anfragen. Letztere Anfrage kann direkt erfolgen oder durch den Leitstellendisponenten (21) des Service-Providers (18) weitervermittelt werden. Der Dispatcher wird entsprechend über die Anfrage informiert und vermittelt zwischen den beiden Operateuren.
- 3. Das weitere Vorgehen entspricht den oben für einen Handover zwischen Service-Providern (18) beschriebenen Schritten 4 bis 9.
-
Beachtung gebührt dem Verhalten in besonderen Situationen. Falls sich etwa zwei teilautomatisierte oder gar autonome Fahrzeuge (11) - z. B. bei einer Begegnung auf schmaler Straße - gegenseitig blockieren, kann diese Blockade (deadlock) dadurch aufgelöst werden, dass beide Fahrzeuge (11) einen ToD-Request senden, die Operatoren (12) untereinander Kontakt aufnehmen und die Situation auflösen. Die Kontaktaufnahme mit einem anderen Operator (12) ist etwa möglich, indem der erste Operator (12) - z. B. unter Angabe des amtlichen Kennzeichens des anderen Fahrzeuges (11) - eine Kontaktanfrage über den Dispatcher (20) schickt.
-
Eine Verwaltung von Anfragen in Warteschlangen - vergleichbar den von Call-Centern bekannten „Warteschleifen“ - kann bei mangelnder Verfügbarkeit von ToD-Operatoren (12) oder Überlastung des Übertragungskanals oder anderweitiger Ressourcen notwendig werden. Eine von der Reihenfolge ihres Eintreffens abweichende Abarbeitung von Anfragen mag etwa bei Gefahr in Verzug, z. B. auf Autobahnen bei hoher Geschwindigkeit oder in Notlagen, zur Auflösung von Staus durch taktisches Handeln auf Basis der Position der einzelnen Fahrzeuge (11), angesichts Umfang und Aufwand des anstehenden Eingriffs oder abhängig von der Art der erworbenen Dienstleistung (Premium, Standard, Basic, Eco usw.) geboten sein.
-
Um Übertragungsbandbreite und Ressourcen beim ToD-Service-Provider (18) einzusparen, können unter vorgegebenen Randbedingungen (Übertragungs)-Ressourcen gebündelt werden. Auch ist es möglich, dass kürzlich durchgeführte Fahrmanöver an gleicher Stelle zum Teil automatisiert wiederverwendet werden. Dies gilt, wenn - etwa bei aufgestautem Verkehr z.B. durch einen Unfall - ein durch ein anderes teleoperiertes Fahrzeug (11) bereits überwundenes Hindernis erfolgreich umfahren wurde und eines der Nachfolgefahrzeuge in der gleichen Situation aufgrund der Gegebenheiten und Systemeigenschaften die gleiche Unterstützung benötigt. So kann z.B. eine Trajektorie durch einen ToD-Operator (12) während des ferngesteuerten Fahrens aufgezeichnet werden und anderen ToD-Operateuren (12) oder teilautomatisiert nachfolgenden Fahrzeugen (11) zur Verfügung gestellt werden. Auch ist die Aufforderung zur Aneinanderreihung mehrerer Fahrzeuge (11) zu einer Kolonne (platoon) zur Bündelung von Anfragen, die dann alle einer gleichen Trajektorie zur Umfahrung der Gefahrensituation folgen sollen, ein geeignetes Verfahren.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 9494935 B2 [0003]
- US 9767369 B2 [0004]
- US 9465388 B1 [0005]
- US 9720410 B2 [0006]
