DE102021132562A1 - Verfahren und vorrichtung zur handhabung einer autonomen flotte unter verwendung von broadcast-führung - Google Patents

Verfahren und vorrichtung zur handhabung einer autonomen flotte unter verwendung von broadcast-führung Download PDF

Info

Publication number
DE102021132562A1
DE102021132562A1 DE102021132562.5A DE102021132562A DE102021132562A1 DE 102021132562 A1 DE102021132562 A1 DE 102021132562A1 DE 102021132562 A DE102021132562 A DE 102021132562A DE 102021132562 A1 DE102021132562 A1 DE 102021132562A1
Authority
DE
Germany
Prior art keywords
vehicles
vehicle
evacuation
server
communication
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
DE102021132562.5A
Other languages
English (en)
Inventor
Oliver Lei
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.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
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 Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102021132562A1 publication Critical patent/DE102021132562A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • 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
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • B60W60/0027—Planning or execution of driving tasks using trajectory prediction for other traffic participants
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications
    • G08G1/0141—Measuring and analyzing of parameters relative to traffic conditions for specific applications for traffic information dissemination
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/091—Traffic information broadcasting
    • G08G1/094—Hardware aspects; Signal processing or signal properties, e.g. frequency bands
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096708—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control
    • G08G1/096725—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control where the received information generates an automatic action on the vehicle control
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096733—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place
    • G08G1/096741—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place where the source of the transmitted information selects which information to transmit to each vehicle
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096775—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is a central station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/27—Control channels or signalling for resource management between access points

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Atmospheric Sciences (AREA)
  • Chemical & Material Sciences (AREA)
  • Multimedia (AREA)
  • Analytical Chemistry (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Traffic Control Systems (AREA)

Abstract

Ein Server kann bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von autonomen Fahrzeugen unter Bedingungen, die für die Verwendung der autonomen Fahrzeuge zur Evakuierung geeignet sind, verloren gegangen ist. Der Server kann auch Evakuierungspunkte bestimmen und einen geografischen Umkreis um jeden Evakuierungspunkt bestimmen, wobei der Umkreis voraussichtlich ausreichend Fahrzeuge umfasst, um den Evakuierungspunkt auf Grundlage von bestimmten Evakuierungsbedürfnissen eines gegebenen Evakuierungspunkts zu bedienen. Ferner kann der Server eine Evakuierungsanweisung für jeden Evakuierungspunkt formulieren, wobei jede Anweisung einen oder mehrere Parameter aufweist, einschließlich mindestens des geografischen Umkreises, der einem gegebenen Evakuierungspunkt entspricht, wobei eine gegebene Evakuierungsanweisung Fahrzeuge, die die Anweisung ausführen, anweist, zu dem entsprechenden Evakuierungspunkt zu fahren. Der Server kann zusätzlich einen Broadcast einer oder mehrerer der Evakuierungsanweisungen von einem ATSC-Sender, für den bekannt ist, dass er eine geografische Region abdeckt, die mindestens einen Teil des geografischen Umkreises jeder übertragenen Evakuierungsanweisung beinhaltet, anweisen.

Description

  • GEBIET DER TECHNIK
  • Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Vorrichtungen zur Handhabung einer autonomen Flotte unter Verwendung von Broadcast-Führung.
  • ALLGEMEINER STAND DER TECHNIK
  • Vernetzte Fahrzeuge weisen die Fähigkeit auf, Daten sowohl zu senden als auch zu empfangen. In vielen Fällen wird dies über eine direkte 1:1 -Verbindung erreicht, bei der ein Fahrzeug eine Verbindung mit einem Fernzugriffsserver herstellt und nützliche Daten (Kartenaktualisierung, Softwareaktualisierung usw.) empfängt oder sendet. In Fällen, in denen die Verbindung zum Beispiel unter Verwendung von Mobilfunkdiensten unterstützt wird, kann dies insgesamt zu hohen Datenkosten führen, wenn ein Verteiler der Daten (z. B. ein Erstausrüster (Original Equipment Manufacturer - OEM)) die Daten an eine große Anzahl von Fahrzeugen senden muss.
  • Die Advanced Television System Committee-(ATSC-)Technologie 3.0 ermöglicht die Verwendung einer Rundfunkfrequenz, um Daten per Broadcast zu übertragen, und dann können unterschiedliche Fahrzeuge oder andere Instanzen die Daten als Teil eines Broadcasts empfangen. Dies stellt eine 1:n-Möglichkeit bereit, beinhaltet jedoch typischerweise keine beabsichtigte direkte Kommunikation mit einer einzelnen Einheit. Das heißt, dass die Informationen Teil eines Broadcasts sind und die empfangenden Instanzen dann die in dem Broadcast beinhalteten Daten empfangen und verarbeiten müssen, wenn die Daten möglicherweise nicht für eine gegebene empfangende Instanz gedacht waren oder für diese Instanz nicht anwendbar sind.
  • KURZDARSTELLUNG
  • In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, zu bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von autonomen Fahrzeugen unter Bedingungen, die für die Verwendung der autonomen Fahrzeuge für Evakuierungszwecke als geeignet vordefiniert sind, verloren gegangen ist. Der Prozessor ist zudem dazu konfiguriert, einen oder mehrere Evakuierungspunkte zu bestimmen und einen geografischen Umkreis um jeden Evakuierungspunkt zu bestimmen, wobei der Umkreis voraussichtlich ausreichend Fahrzeuge umfasst, um den Evakuierungspunkt auf Grundlage von bestimmten Evakuierungsbedürfnissen eines gegebenen Evakuierungspunkts zu bedienen Ferner ist der Prozessor dazu konfiguriert, eine Evakuierungsanweisung für jeden Evakuierungspunkt zu formulieren, wobei jede Anweisung einen oder mehrere Parameter aufweist, einschließlich mindestens des geografischen Umkreises, der einem gegebenen Evakuierungspunkt entspricht, wobei eine gegebene Evakuierungsanweisung Fahrzeuge, die die Anweisung ausführen, anweist, zu dem entsprechenden Evakuierungspunkt zu fahren. Der Prozessor ist zusätzlich dazu konfiguriert, einen Broadcast einer oder mehrerer der Evakuierungsanweisungen von einem ATSC-Sender, für den bekannt ist, dass er eine geografische Region abdeckt, die mindestens einen Teil des geografischen Umkreises jeder übertragenen Evakuierungsanweisung beinhaltet, anzuweisen.
  • In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, zu bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von nicht verbundenen Fahrzeugen verloren gegangen ist, was einen Kommunikationsverlust über mindestens ein Mobilfunknetz für mindestens einen gegebenen Bereich oder einen Kommunikationsverlust, der mit mindestens einem Namen eines nicht verbundenen Mobilfunkzugangspunkts korreliert, darstellt. Der Prozessor ist zudem dazu konfiguriert, als Reaktion auf das Bestimmen, dass die Zweiwegekommunikation verloren gegangen ist, den Namen des mindestens einen Mobilfunknetzes oder des nicht verbundenen Zugangspunkts, über den die Kommunikation verloren gegangen ist, zu bestimmen. Zusätzlich ist der Prozessor dazu konfiguriert, eine Kommunikationsalternative für die Vielzahl von nicht verbundenen Fahrzeugen, die mindestens einen Namen eines Ersatznetzes oder Ersatzzugangspunkts darstellt, auf Grundlage dessen zu bestimmen, ob die Kommunikation über den mindestens einen Namen eines Mobilfunknetzes oder eines nicht verbundenen Zugangspunkts verloren gegangen ist. Der Prozessor ist zudem dazu konfiguriert, den Broadcast der Kommunikationsalternative als Teil einer Umprogrammierungsanweisung von dem ATSC-Sender/Empfänger anzuweisen.
  • In einer dritten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, die Evakuierungsbedürfnisse für eine Vielzahl von Evakuierungspunkten zu bestimmen. Der Prozessor ist zudem dazu konfiguriert, einen geografischen Umkreis für jeden Evakuierungspunkt zu bestimmen, der eine Anzahl von autonomen Fahrzeugen umfasst, die voraussichtlich zum Bedienen der Evakuierung eines gegebenen Evakuierungspunkts geeignet sind. Ferner ist der Prozessor dazu konfiguriert, eine Evakuierungsanweisung für jeden Evakuierungspunkt, einschließlich des für jeden Evakuierungspunkt bestimmten geografischen Umkreises, als einen Parameter zum Annehmen einer gegebenen Anweisung zu formulieren und einen Broadcast der Evakuierungsanweisungen von einem ATSC-Sender anzuweisen.
  • Figurenliste
    • 1 zeigt ein veranschaulichendes ATSC-System in Kommunikation mit einem Cloud-Server und mehreren Fahrzeugen;
    • 2 zeigt einen veranschaulichenden Prozess zum Erfassen und Melden einer Unregelmäßigkeit;
    • 3 zeigt einen veranschaulichenden Prozess zum Bearbeiten gemeldeter Unregelmäßigkeiten;
    • 4 zeigt einen veranschaulichenden Prozess zum Senden eines ATSC-Broadcasts;
    • 5A und 5B zeigen veranschaulichende Prozesse zum Vorbereiten von Broadcasts auf unterschiedlichen veranschaulichenden Unregelmäßigkeiten;
    • 6 zeigt ein veranschaulichendes Beispiel eines Prozesses zum Bearbeiten empfangener Broadcasts;
    • 7 zeigt ein veranschaulichendes Beispiel für autonome Fahrzeuge, die eine Vielzahl von Zonen bedienen;
    • 8 zeigt einen veranschaulichenden Prozess für den Einsatz eines autonomen Fahrzeugs unter Verwendung von Broadcast;
    • 9 zeigt einen veranschaulichenden Prozess zum Bearbeiten eines Einsatzes;
    • 10 zeigt einen veranschaulichenden Prozess zum Umfunktionieren eines Einsatzes;
    • 11 zeigt einen veranschaulichenden Prozess zur Bereitstellung eines Mobilfunkanbieters unter Verwendung von Broadcast;
    • 12 zeigt einen veranschaulichenden Prozess zum Bearbeiten der Bereitstellung eines Mobilfunkanbieters;
    • 13A und 13B zeigen veranschaulichende Prozesse zum Sammeln von Daten unter Verwendung von Broadcast und Antwort;
    • 14 zeigt einen veranschaulichenden Prozess zur selektiven Verkehrsroutenführung;
    • 15 zeigt einen veranschaulichenden Prozess zum Bearbeiten von selektiver Verkehrsroutenführung;
    • 16 zeigt einen veranschaulichenden Prozess zum Einstelen eines adaptiven Modells zur selektiven Verkehrsroutenführung;
    • 17 zeigt einen veranschaulichenden Prozess zum Bearbeiten von Kartendaten aus einem Broadcast selektiver Routenführung;
    • 18A und 18B zeigen veranschaulichende Prozesse zum Bearbeiten selektiver Warnungen;
    • 19 zeigt einen veranschaulichenden Prozess zum Aktualisieren von periodischen Ladedaten;
    • 20 zeigt einen veranschaulichenden Prozess zum Bearbeiten von Ladewarnungen;
    • 21 zeigt einen veranschaulichenden Prozess zum Broadcasten von Softwareaktualisierungen;
    • 22 zeigt einen veranschaulichenden Prozess zum Bearbeiten des Aktualisierungs-Broadcasts; und
    • 23 zeigt einen veranschaulichenden Prozess zum Anpassen des Broadcastens von Softwareaktualisierungen.
  • DETAILLIERTE BESCHREIBUNG
  • Wie erfordert, werden in dieser Schrift ausführliche Ausführungsformen offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft sind und in unterschiedlichen und alternativen Formen ausgeführt werden können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Deshalb sind in dieser Schrift offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann den unterschiedlichen Einsatz des beanspruchten Gegenstands zu lehren.
  • Zusätzlich zur Ausführung beispielhafter Prozesse durch ein Fahrzeugrechensystem, das sich in einem Fahrzeug befindet, können die beispielhaften Prozesse in bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann unter anderem eine drahtlose Vorrichtung (z. B. unter anderem ein Mobiltelefon) oder ein entferntes Rechensystem (z. B. unter anderem ein Server) beinhalten, das über die drahtlose Vorrichtung verbunden ist. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (vehicle associated computing systems - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten der VACS abhängig von der konkreten Umsetzung des Systems bestimmte Abschnitte eines Prozesses durchführen. Wenn ein Prozess zum Beispiel und ohne Einschränkung einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Abschnitt des Prozesses nicht durchführt, da die drahtlose Vorrichtung Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Der Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem auf eine gegebene Lösung anzuwenden.
  • In jeder der in dieser Schrift erörterten veranschaulichenden Ausführungsformen wird ein beispielhaftes nicht einschränkendes Beispiel für einen Prozess gezeigt, der durch ein Rechensystem durchgeführt werden kann. Im Hinblick auf jeden Prozess ist es möglich, dass das Rechensystem, das den Prozess ausführt, für den begrenzten Zweck des Ausführens des Prozesses als Spezialprozessor zum Durchführen des Prozesses konfiguriert wird. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden, sondern sind als Beispiele für Arten von Prozessen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu erzielen. Je nach Wunsch können zusätzliche Schritte den beispielhaften Prozessen hinzugefügt oder daraus entfernt werden.
  • In Bezug auf die veranschaulichenden Ausführungsformen, die in den Figuren beschrieben sind und die veranschaulichende Prozessabläufe zeigen, ist anzumerken, dass ein Universalprozessor vorübergehend als Spezialprozessor zum Zwecke des Ausführens einiger oder aller der beispielhaften Verfahren, die durch diese Figuren gezeigt sind, aktiviert werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend so lange zum Spezialprozessor umfunktioniert werden, bis das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann im geeigneten Umfang Firmware, die gemäß einem im Voraus konfigurierten Prozessor wirkt, den Prozessor dazu veranlassen, als ein Spezialprozessor zu wirken, der zum Zwecke des Durchführens des Verfahrens oder einer sinnvollen Variante davon bereitgestellt wird.
  • Unter Verwendung eines Servers in Verbindung mit ATSC-Rundfunkstationen kann eine Broadcast-Entität (z. B. OEM) gezielte Daten vorbereiten und senden, die dazu ausgestaltet sind, mehrere Fahrzeuge innerhalb des Broadcast-Bereichs einer Station in einer 1:n-Weise zu erreichen. Das heißt, dass anstatt die Daten an jedes Fahrzeug einzeln über eine direkte Verbindung mit einem bestimmten Fahrzeug zu liefern, kann die Instanz Daten vorbereiten, die für eine bestimmte Gruppe von Fahrzeugen nützlich sind, und die Daten und Anweisungen senden, um an eine ATSC-Station zu broadcasten. Die Station kann dann den ATSC-Broadcast senden und eine große Anzahl von Fahrzeugen kann die Daten gleichzeitig empfangen.
  • Da die Daten möglicherweise nur für eine Teilmenge von empfangenden Fahrzeugen anwendbar oder relevant sind, kann der Server auch Informationen vorbereiten, welche die Fahrzeuge angeben, für welche die Daten gelten. Wenn sich die Daten zum Beispiel auf eine Straßenunregelmäßigkeit beziehen, kann der Server einen Koordinatenbereich um die Unregelmäßigkeit oder eine Tageszeit festlegen, zu der die Unregelmäßigkeit anwendbar ist usw. Wenn die Daten eine Softwareaktualisierung betreffen, kann der Server eine Softwareversion oder sogar einen Satz konkreter Elemente der Fahrzeugidentifikationsnummer (vehicle identification number - VIN) oder elektronischen Seriennummer (ESN) festlegen.
  • Wenn ein Fahrzeug den Broadcast empfängt, kann es Parameterdaten überprüfen, die dem Broadcast zugeordnet sind, um die Anwendbarkeit der in dem Broadcast enthaltenen Daten zu bestimmen. Wenn die Parameterdaten angeben, dass das Fahrzeug die Broadcast-Daten verwenden kann, dann kann das Fahrzeug den Broadcast verarbeiten oder an das richtige interne System (Aktualisierungsprozess, Navigationssystem usw.) zum Bearbeiten senden.
  • Durch die veranschaulichenden Ausführungsformen und dergleichen können erhebliche Kosteneinsparungen zum Kommunizieren von Daten an eine große Gruppe von Fahrzeugen erreicht werden, sowie eine Beschleunigung der Zustellung über den Broadcast an alle Fahrzeuge gleichzeitig. Der Broadcast kann ebenfalls bestehen bleiben, sodass Fahrzeuge, die in einen Broadcast-Bereich einfahren, während der Broadcast läuft, weiterhin den Broadcast empfangen und davon profitieren können.
  • 1 zeigt ein veranschaulichendes ATSC-Rundfunksystem 101 in Kommunikation mit einem Server 113 der Cloud 111 und mehreren Fahrzeugen 121, 131, 141. In diesem Beispiel ist das ATSC-System 101 eine ATSC-Rundfunkstation, die in der Lage ist, ATSC-Broadcasts an einen bekannten Broadcast-Bereich zu senden. Die Station beinhaltet eine Art von Prozess 105 zum Empfangen von Aktualisierungen, der üblicherweise mit einem Weitverkehrsnetz (z. B. dem Internet) verbunden ist, das aber auch eine Mobilfunk- oder andere Verbindung nutzen kann. Durch den Prozess 105 empfängt die Station 101 Anweisungen von dem Server 113 der Cloud 111 und verarbeitet diese Anweisungen, um einen Broadcast an einem Stationscomputer auszuarbeiten, der mit einem Prozessor 103 ausgestattet ist. Sobald der Broadcast bereit ist, kann der Prozessor 103 den ATSC-Sender 107 anweisen, den Broadcast an beliebige Fahrzeuge 121, 131 innerhalb eines Empfangsbereichs zu senden.
  • In dem gezeigten Beispiel kann eines der Fahrzeuge 121, 131, 141 eine Unregelmäßigkeit über eine Mobilfunkverbindung oder eine andere Verbindung an den Server 113 der Cloud 111 melden. In einigen Fällen, wie etwa dem Fahrzeug 141, kann das Fahrzeug eine Sensorreihe 147 beinhalten. Diese Reihen können in autonomen Fahrzeugen 141 üblicher sein, die eine Vielzahl von Erfassungssystemen beinhalten können, die anderen Fahrzeugen 121, 131 nicht bereitgestellt werden.
  • In anderen Fällen kann das Fahrzeug ein von einem Menschen angetriebenes Fahrzeug 121, 131 sein und kann einen Prozessor 123, einen ATSC-Sendeempfänger 125, einen Navigationsprozess oder -prozessor 127 und andere fahrzeuginterne Prozesse oder Prozessoren und eine Telematiksteuereinheit (telematics control unit - TCU) 129 beinhalten. Falls und wenn das Fahrzeug 121 eine Unregelmäßigkeit erfasst, wie etwa einen fahrzeuginternen Softwarefehler, kann das Fahrzeug 121 die Unregelmäßigkeit dem Server 113 unter Verwendung der TCU 129 und einer Mobilfunkverbindung oder einer anderen direkten Verbindung (z. B. Wi-Fi) melden. 1 zeigt das Fahrzeug 141, das Mobilfunkdaten durch die TCU 149 über einen Mobilfunkmast an den Cloud-Server 113 kommuniziert. Dieses Fahrzeug 141 könnte Unregelmäßigkeiten melden, die durch die Sensoren 147, den Verkehr, Softwarefehler usw. erfasst wurden. Jedes Fahrzeug kann potentiell eine Unregelmäßigkeit an die Cloud 111 kommunizieren.
  • Das Fahrzeug 131 weist ähnliche Komponenten wie das Fahrzeug 121 auf, ist jedoch zum Zwecke des Vorführens, dass der Broadcast von dem ATSC-Sender 107 der Station 101 1:n ist, als ein einzelnes Fahrzeug 131 gezeigt. Die in dem Beispiel gezeigte Antenne ist ein ATSC-Empfänger 135.
  • Das Fahrzeug 141 ist ein autonomes Fahrzeug oder ein anderes Fahrzeug mit verbesserten Sensoren 147 und kann außerdem eine Reihe von straßenbasierten Unregelmäßigkeiten (z. B. Schlaglöcher) erfassen. Andere Fahrzeuge 121, 131 können ebenfalls Verkehrs- und Straßenunregelmäßigkeiten (z. B. Verkehr, Baustelle) erfassen, sind jedoch möglicherweise nicht so gut ausgestattet, um Dinge wie Schlaglöcher zu erfassen. Wenn das Fahrzeug 141 einen Straßenzustand erfasst, der mit anderen Fahrzeugen 121, 131 geteilt werden sollte (zum Beispiel auf Grundlage eines vordefinierten Satzes dessen, welche erfassten Zustände geteilt werden sollten), kann das Fahrzeug 141, das ebenfalls eine TCU 149 und einen Zentralprozessor 143 aufweist, die TCU 149 verwenden, um den Zustand über eine Mobilfunkverbindung an den Server 113 zu melden. Dieses Fahrzeug 141 weist außerdem einen ATSC-Empfänger 145 zum Empfangen von ATSC-Broadcasts von dem ATSC-Sender 107 oder dergleichen auf.
  • Der Server 113 empfängt alle gemeldeten Unregelmäßigkeiten und bestimmt, welche Fahrzeuge von den Unregelmäßigkeiten betroffen sein können und/oder wie die Unregelmäßigkeiten behoben werden können, wenn die Unregelmäßigkeit etwas ist, das behoben werden kann (z. B. eine Softwareaktualisierung). Der Server 113 packt dann Lieferanweisungen, zusammen mit beliebigen Parametern, die von den Fahrzeugen 121, 131, 141 verwendet werden können, um zu bestimmen, ob ein empfangener Broadcast anwendbar ist, und dann liefert der Server 113 das Datenpaket an die Station 101. Die Station 101 kann dann das Datenpaket an die unterschiedlichen Fahrzeuge 121, 131, 141 senden, welche die Anwendbarkeit der Daten individuell bestimmen können.
  • Da die Daten eine Aktualisierung der Software beinhalten können, kann zum Beispiel selbst ein meldendes Fahrzeug 121 von den Daten profitieren. In anderen Fällen kann das empfangende Fahrzeug 141 die Daten empfangen und auf Grundlage der Tatsache, dass die Daten/Lösung empfangen wurden, bestätigen, dass eine Straßen- oder Verkehrsunregelmäßigkeit erfolgreich gemeldet wurde.
  • 2 zeigt einen veranschaulichenden Prozess zum Erfassen und Melden einer Unregelmäßigkeit. In diesem Beispiel erfasst der auf einem Prozessor 143 des Fahrzeugs 141 ausgeführte Prozess bei 201 ein meldepflichtiges Ereignis. Dies kann zum Beispiel eine Straßenunregelmäßigkeit, eine Verkehrsunregelmäßigkeit, eine Änderung einer Straße (neue Straße, Straßensperrung usw.), einen Softwarefehler oder ein anderes im Voraus definiertes meldepflichtiges Ereignis beinhalten.
  • Wenn es der Unregelmäßigkeit zugeordnete Parameter gibt, kann das Fahrzeug 141 die Parameter bei 203 einstellen. Zum Beispiel können der Straßenunregelmäßigkeit derselben zugeordnete geografische Koordinaten, sowie eine Fahrtrichtung oder Tageszeit aufweisen. Eine Softwareunregelmäßigkeit kann Parameter wie eine derselben zugeordnete Softwareart oder -version, sowie Parameter aufweisen, die bestimmten Fahrzeugsystemen entsprechen, welche die Software nutzen oder beinhalten. Das Fahrzeug 141 sendet dann bei 205 die Unregelmäßigkeit und die Parameter an den Server 113. Der Server 113 kann auch an den OEM berichten, der dann eine Softwarekorrektur vorbereiten kann, um das gemeldete Problem zu beheben. Wenn die Softwarekorrektur nicht bereits aussteht, kann der OEM einige Zeit in Anspruch nehmen, um die Lösung für das gemeldete Problem zu klären und zu veröffentlichen.
  • Da das Senden der Parameter dazu führen kann, dass eine ATSC-Aktualisierung gesendet wird, bestimmt das Fahrzeug 141 in diesem Beispiel bei 207, ob eine ATSC-Aktualisierung über den ATSC-Empfänger 145 empfangen wurde. Dies könnte eine Meldung der Straßenunregelmäßigkeit oder eine Softwareaktualisierung sein, um ein identifiziertes Problems zu korrigieren. Da die Verarbeitung der Aktualisierung oder der Meldung etwas Zeit in Anspruch nehmen könnte, kann das Fahrzeug 141 bei 209 warten und fortfahren, bezüglicher der ATSC-Aktualisierung zu prüfen. Oder das Fahrzeug 141 kann einfach die ATSC-Aktualisierung empfangen, sobald sie verfügbar ist, ohne wiederholtes Prüfen.
  • Wenn der vorgeschriebene Zeitraum verstreicht, ist es möglich, dass ein Fehler aufgetreten ist, der die ATSC-Aktualisierung verhindert, oder die Softwarekorrektur ist noch nicht verfügbar. Dementsprechend kommuniziert das Fahrzeug 141 in diesem Beispiel bei 211 direkt mit dem Aktualisierungsserver 113. Wenn der Server 113 das Fahrzeug 141 bei 213 darüber benachrichtigt, dass die Aktualisierung verarbeitet wurde, kann das Fahrzeug 141 die lokalen Daten zum Melden der Unregelmäßigkeit bei 217 löschen. Die gleiche Löschung kann auftreten, wenn das Fahrzeug 141 die ATSC-Aktualisierung empfängt, die es auf Grundlage der gesendeten Daten erwartet. In anderen Beispielen, kann, wenn das Fahrzeug eine Unregelmäßigkeit meldet, es einfach die Daten löschen und der Server wird die Unregelmäßigkeit zu gegebener Zeit beheben. In einem derartigen Beispiel muss das Fahrzeug keine Aktualisierung direkt von dem Server empfangen und/oder sich bei dem Server zurückmelden.
  • Wenn ein Problem mit der Aktualisierung aufgetreten ist oder der Server 113 die Daten erneut benötigt, kann das Fahrzeug 141 die Daten bei 215 erneut senden und den Prozess wiederholen. Da der Server 113 möglicherweise Zeit benötigt, um die Aktualisierung zu bearbeiten, und möglicherweise weitere Zeit benötigt, um die Aktualisierung über die Station 101 zu senden, trennt sich das Fahrzeug 141 in diesem Beispiel, ohne notwendigerweise eine anfängliche Bestätigung der Aktualisierungsverarbeitung zu empfangen, da das Fahrzeug 141 den ATSC-Broadcast dennoch als Bestätigung empfangen kann, sobald die Aktualisierung bearbeitet wurde.
  • 3 zeigt einen veranschaulichenden Prozess zum Bearbeiten gemeldeter Unregelmäßigkeiten, die zum Beispiel durch den Server 113 ausgeführt werden. In diesem Beispiel empfängt der Server 113 bei 301 die Meldung der Unregelmäßigkeit. Da mehr als ein Fahrzeug 121, 131, 141 die gleiche Unregelmäßigkeit melden kann, insbesondere in Bezug auf Straßen- und Verkehrsunregelmäßigkeiten, bestimmt der Server 113 bei 303, ob die Unregelmäßigkeit bereits verarbeitet wurde (d. h. zuvor empfangen wurde). Wenn die Unregelmäßigkeit bereits verarbeitet wurde, speichert der Server 113 bei 309 eine Meldung für das meldende Fahrzeug, falls das Fahrzeug 141 mit dem Server kommuniziert, um zu bestimmen, ob die Meldung verarbeitet wurde.
  • Wenn die Meldung nicht bereits verarbeitet wurde, verarbeitet der Server 113 die Meldung und stellt bei 305 Parameter ein, die den Fahrzeugen entsprechen, für welche die Aktualisierung/der Broadcast gilt. Dies kann auch das Erlangen einer Softwareaktualisierung zur Verteilung, das Identifizieren von Fahrzeugparametern für eine Softwareaktualisierung, das Definieren eines Geofences um eine Straßenunregelmäßigkeit usw. beinhalten. Der Server 113 kann ferner eine Dauer für den Broadcast und/oder anwendbare Tageszeiten und Wochentage für den Broadcast beinhalten, und dann sendet der Server 113 die Anweisungen und Daten bei 307 an die ATSC-Station 101.
  • 4 zeigt einen veranschaulichenden Prozess zum Senden eines ATSC-Broadcasts, der zum Beispiel durch die Station 101 ausgeführt werden kann. In diesem Beispiel empfängt die Station 101 bei 401 die Broadcast-Daten und alle anwendbaren Parameter von dem Server 113. Da die Daten möglicherweise für den Broadcast umgewandelt werden müssen, wie etwa das Beinhalten einer Broadcast-Kopfdatei, kann die Station 101 bei 303 beliebige Empfangsparameter einstellen, die in der Kopfdatei beinhaltet sein sollen. Dies kann zum Beispiel geografische Parameter, Fahrtrichtungsparameter oder Fahrzeug-VIN- oder ESN-Parameter beinhalten.
  • Die Station sendet dann die Daten bei 405 als Teil eines ATSC-Broadcasts. Wenn der Broadcast bei 407 einen definierten Zeitraum aufweist, der nicht abgelaufen ist, kann die Station 101 bei 409 einen vordefinierten Zeitraum warten und dann den Broadcast erneut senden. Da die Station 101 aufgefordert sein kann, eine große Anzahl von Datensätzen per Broadcast zu übertragen, kann die Station 101 eine Wartezeit zwischen den Broadcasts erfordern, die auch in Bezug auf eine Art von Broadcast definiert sein kann - z. B. wird ein Notfall-Broadcast laufen, bis der Notfall nachlässt, aber eine Schlaglochbenachrichtigung wird möglicherweise nur alle X Minuten per Broadcast gesendet, es sei denn, es stehen keine anderen Broadcasts an. Sobald der vordefinierte Zeitraum abläuft oder sobald die Unregelmäßigkeit nachlässt, kann die Station 101 den Broadcast bei 411 aus einer Broadcast-Warteschlange entfernen.
  • Die 5A und 5B zeigen veranschaulichende Prozesse zum Vorbereiten von Broadcasts auf unterschiedlichen veranschaulichenden Unregelmäßigkeiten, die zum Beispiel durch den Server 113 ausgeführt werden können. Wenn der Server 113 eine bestimmte Unregelmäßigkeit empfängt, kann der Server 113 die Unregelmäßigkeit parametrieren, um zu definieren, welche Fahrzeuge 121, 131, 141 einen von der Station 101 gesendeten Daten-Broadcast tatsächlich verarbeiten sollen. Während veranschaulichende Straßenunregelmäßigkeiten und Softwareunregelmäßigkeiten in den 5A bzw. 5B gezeigt sind, versteht es sich, dass jede Art von Unregelmäßigkeit, die erfasst werden könnte, zum Melden definiert ist und für die das Melden an mehrere Fahrzeuge aus geeignete Weise gehandehabt werden könnte, auf ähnliche Weise bearbeitet werden könnte.
  • In 5A empfängt der Server 113 bei 501 eine Meldung über eine Straßenunregelmäßigkeit. Dies kann zum Beispiel eine Straßengefahr (Schlagloch), eine neue Straße, eine Straßensperrung, ein Baustellenbereich, ein gefährlicher Zustand, eine Wetterlage usw. beinhalten. In diesem Beispiel bestimmt der Server 113 bei 503 einen anwendbaren Geofence-Radius (oder Umkreis). Zum Beispiel kann ein Schlagloch einen beschränkten Umkreis einer Meile und eine derselben zugeordnete Gerichtetheit aufweisen (angesichts der wahrscheinlichen begrenzten Auswirkung auf den meisten Verkehr), während ein massiver Baustellenumweg einen demselben zugeordneten Radius von 5-10 Meilen aufweisen könnte, was den Fahrern Zeit zum Wechseln einer Strecke vor dem Erreichen einer Stauung gibt.
  • Der Server 113 stellt dann bei 505 beliebige geographische Parameter ein, die der Unregelmäßigkeit zugeordnet werden sollen. Dies kann zum Beispiel Gerichtetheit, Grenzen zur Verarbeitung und beliebige andere relevante Informationen beinhalten. Zum Beispiel kann bei einem Schlagloch nicht nur der Radius auf 0,5 Meilen eingestellt sein, sondern der Server 113 kann außerdem einen konkreten Straßenparameter einstellen, sodass nur Fahrzeuge innerhalb einer halben Meile von dem Schlagloch, die in eine vorgegebene Richtung fahren, und auf der gegebenen Straße, die Daten in Bezug auf das Schlagloch verarbeiten werden.
  • Der Server 113 kann außerdem bei 507 eine Artkennung (type-flag) setzen, die eine Art von Unregelmäßigkeit definiert (die dann in dem Broadcast beinhaltet wird). Bestimmte Fahrzeugbesitzer möchten möglicherweise bestimmte Meldungen ignorieren, um eine Überflutung zu vermeiden, so zum Beispiel, wenn die Unregelmäßigkeit von der Art Wetter und Regen ist, einige Fahrzeugbesitzer diese Unregelmäßigkeit ignorieren können (es ist ihnen egal, ob sie durch Regen fahren), während andere dies möglicherweise nicht tun.
  • Der Server 113 bereitet dann bei 309 ein Datenpaket vor, das die Identifikation der Unregelmäßigkeit sowie beliebiger Verarbeitungsparameter und jede vorgeschlagene Maßnahme zur Vermeidung der Unregelmäßigkeit beinhalten kann. Dies kann ein detaillierter Plan sein oder so einfach sein, wie zum Beispiel „Vermeiden Sie das Fahren auf der Spur ganz links zwischen 11 und 12 Mile Roads auf der Telegraph Road., um ein Schlagloch zu vermeiden“. Wenn die Unregelmäßigkeit groß ist, können Navigationssysteme in der Lage sein, um sie herum zu führen, aber wenn die Unregelmäßigkeit stark örtlich begrenzt ist, können GPS-Koordinaten unzureichend sein, um einen Fahrzeugstandort in Bezug auf die Unregelmäßigkeit zu bestimmen, und somit kann der Server zusätzliche Anweisungen bereitstellen, um die örtlich begrenzte Unregelmäßigkeit zu vermeiden.
  • In 5B empfängt der Server 113 bei 511 eine Meldung über eine Softwareunregelmäßigkeit. Dies kann zum Beispiel eine Funktionsstörung der Software, einen Fehler in einer Anzeige oder einen anderen gemeldeten Softwarefehler beinhalten. Der Fehlerbericht kann außerdem eine Softwareversion und/oder ein Fahrzeugsystem beinhalten, für das die Software gilt (z. B. Softwarefehler in Version 1.02 der Heizungssteuerungssoftware für ein beheiztes Fahrzeugsitzmodul).
  • Der Server 113 bestimmt dann bei 513, ob ein Patch oder eine Aktualisierung verfügbar ist. Selbst wenn kein Patch vorhanden ist, kann der Server 113 den Fehler Fahrzeugbesitzern per E-Mail oder anderen Verfahren melden, welche die betroffene Softwareversion installiert haben, was der Server 113 ebenfalls bei 513 bestimmen kann. Der Server 113 kann dann bei 515 Fahrzeugparameter einstellen, wie etwa Fahrzeuge, welche die bestimmte Modul- und/oder Softwareversion aufweisen. Dies könnte auch einen VIN- oder einen ESN-Parameter beinhalten, die einen Satz von Fahrzeugen angeben, wenn die Fahrzeuge, auf welche die Aktualisierung angewendet wurde, durch eine derartige Identifikationsnutzung identifizierbar waren.
  • Der Server 113 kann bei 517 eine Softwarekorrektur oder andere Daten beinhalten, die zum Erlangen einer Softwareaktualisierung oder Patch-Software verwendet werden können. Wenn die Software zum Beispiel nicht über eine Aktualisierung per Funk korrigiert werden kann, könnte die Korrektur Anweisungen beinhalten (die an einen Fahrzeuginsassen geliefert werden können), um einen Besuch beim Händler zu planen. Schließlich bereitet der Server 113 das Softwarepaket zusammen mit Broadcast-Anweisungen bei 519 für die Lieferung vor und sendet dann die Daten an die Station 101.
  • 6 zeigt ein veranschaulichendes Beispiel eines Prozesses zum Bearbeiten empfangener Broadcasts, die zum Beispiel durch das Fahrzeug 121 ausgeführt werden können. In diesem Beispiel empfängt das Fahrzeug 121 bei 601 den ATSC-Broadcast. Da ein Fahrzeug 121 alle ATSC-Broadcasts empfängt, während es sich innerhalb einer Broadcast-Region befindet, muss das Fahrzeug 121 möglicherweise einen Prozess zum Bearbeiten der Broadcasts aufweisen, um zu vermeiden, dass Verarbeitungszyklen und Energie beim Bearbeiten von nichtanwendbaren Broadcasts verschwendet werden.
  • Wenn der Broadcast bei 603 geografische Parameter beinhaltet, behandelt das Fahrzeug 121 die Daten als einen Verkehrsunregelmäßigkeitsvorfall. Wenn der Broadcast bei 605 Fahrzeugidentifikationsparameter oder System- oder Softwareparameter beinhaltet, behandelt das Fahrzeug 121 die Daten als eine Softwareproblembenachrichtigung. Andere Parameter könnten ebenfalls verwendet werden, um andere Arten von Broadcasts als geeignet zu identifizieren.
  • Wenn die Daten eine Verkehrsunregelmäßigkeit sind, bestimmt das Fahrzeug 121, ob die vorliegenden GPS-Koordinaten für das Fahrzeug 121 mit einem Koordinatensatz übereinstimmen, der für den Verkehrs-Broadcast bei 607 definiert wurde. In anderen Fällen kann eine Fahrzeugfahrtrichtung oder eine Straße zum Abgleichen oder eine Bestimmung verwendet werden, ob sich beliebige zutreffende Koordinaten entlang einer Fahrzeugstrecke befinden. Wenn es eine aktuelle Übereinstimmung gibt (d. h. der Broadcast gilt sofort für das Fahrzeug), sendet das Fahrzeug 121 bei 615 die aktualisierten Daten an das Fahrzeugnavigationssystem.
  • Wenn keine aktuelle Übereinstimmung vorliegt, garantiert dies nicht, dass die Daten nie für dieses bestimmte Fahrzeug gelten werden, da sich die Daten auf einen Straßenzustand in der Nähe beziehen und das Fahrzeug fährt. Dementsprechend bestimmt das Fahrzeug 121, ob eine gegenwärtige Strecke (oder Fahrtrichtung und Straße) das Fahrzeug 121 in den relevanten Koordinatensatz befördern wird. Wenn es bei 609 eine Streckenübereinstimmung gibt, kann das Fahrzeug 121 die Daten bei 613 zur Verwendung einreihen, wenn die aktuellen GPS-Daten übereinstimmen, oder das Fahrzeug 121 kann die Daten ansonsten bei 611 ignorieren.
  • Wenn die Daten eine Softwareaktualisierung betreffen, bestimmt das Fahrzeug 121 bei 617, ob das Fahrzeug 121 die relevante identifizierte Softwareversion oder das relevante identifizierte Softwaremodul beinhaltet. Falls nicht, ignoriert das Fahrzeug 121 die Daten bei 619, aber wenn es eine Übereinstimmung gibt, sendet das Fahrzeug 121 die Daten bei 621 an einen Softwareaktualisierungsprozess, um sie bei Bedarf zu bearbeiten. Wenn keine Software vorhanden ist, kann das Fahrzeug 121 die Daten an einen Benachrichtigungsprozess senden, um zum Beispiel den Fahrer zu benachrichtigen, dass eine Korrektur benötigt wird, die jedoch nicht per Funk verfügbar ist.
  • Zusätzlich zu den vorhergehenden veranschaulichenden Beispielen gibt es unzählige andere Funktionen, die auf Grundlage des 1:n-Modells der Übermittlung von ATSC-Broadcasts erreicht werden können. Während dieses Modell gewisse Herausforderungen darstellt, da es keine direkte wechselseitige Kommunikation mit einer empfangenden Entität gibt (obwohl diese Entität später zurückberichten kann), ermöglicht das Modell auch einige einzigartige Möglichkeiten, Informationen kostengünstig massenhaft zu übertragen, Daten zu sammeln und adaptiv bestimmte Situationen zu verwalten, in denen direkte 1:1-Kommunikation zu viel Bandbreite verbrauchen und/oder unerschwinglich sein kann.
  • Zum Beispiel wird der Beginn autonomer Fahrzeuge Tausende von unbemannten Fahrzeugen auf den Straßen bereitstellen. 7 zeigt ein veranschaulichendes Beispiel für autonome Fahrzeuge 701, die eine Vielzahl von Zonen 703, 705, 707 zu einem Zeitpunkt bedienen, zu dem die Mobilfunknetze 709, 711 und 713 ausfallen (z. B. aufgrund von Naturphänomenen). Da autonome Fahrzeuge 701 Informationen und Anweisungen aus der Cloud erhalten werden und diese Übertragung häufig über ein zelluläres Kommunikationsmedium erfolgt, bedeutet der Verlust dieser Netze 709, 711 und 713 einen vollständigen oder teilweisen Verlust der Kontrolle über die Fahrzeuge 701.
  • Gleichzeitig sind sie, da es sich um unbemannte Fahrzeuge handelt, in einer derartigen Situation sowohl sehr nützlich für Transportzwecke und sie können auch größeren Gefahren ausgesetzt sein, zumindest wenn sie keine Fahrgäste haben, da keine Menschen an Bord sein werden. Somit kann ein Verlust der Mobilfunkkommunikation einen Verlust der Kommunikation mit einer Flotte von Nutzfahrzeugen 701 zu einem Zeitpunkt bereitstellen, zu dem diese Fahrzeuge 701 zu den nützlichsten Fahrzeugen 701 auf den Straßen gehören würden.
  • Und in einer Situation, in der die meisten oder alle Fahrzeuge 701 autonom sind, kann dies einen Beinaheverlust einer gesamten Flotte von fast allen oder allen Fahrzeugen 701 auf den Straßen bedeuten.
  • ATSC-Broadcasten kann dazu verwendet werden, in einer derartigen Situation zu unterstützen, da diese Fahrzeuge 701 angewiesen werden können, über einen direkten Broadcast von einem ATSC-Sender 715 zu einem bestimmten Bedarfsziel zu fahren. Dies hat häufig die Wirkung, dass Fahrzeuge 701 in Massen eingesetzt werden, da die Mobilfunknetze in diesem Szenario ausfallen, den Fahrzeugen 701 möglicherweise nicht die Fähigkeit zur Verfügung steht, Ankünfte oder den Empfang von Anweisungen zu melden, aber es ist auch der Fall, dass der Standort vieler Fahrzeuge 701 kurz vor einer Mobilfunkunterbrechung bekannt sein wird, entweder auf Grundlage eines beabsichtigten Ziels oder eines aktuellen Standorts im Ruhezustand.
  • Dann können betroffene Bereiche in Zonen 701, 703, 705 unterteilt werden. Solchen Fahrzeugen 701 in jeder Zone kann eine bestimmte Aufgabe zugewiesen werden. Ferner ist es möglich, Zonen auf Grundlage von gegenwärtigen GPS-Koordinaten zu bestimmen, die Fahrzeugen noch bekannt sein können. In jedem Fall oder unter Verwendung beider Konzepte kann eine Teilmenge von Fahrzeugen 701 in der Nähe einer Evakuierungsstelle zum Beispiel mit der Fahrt zur Evakuierungsstelle beauftragt werden, um Menschen zu evakuieren. Während dies dazu führen kann, dass zusätzliche Fahrzeuge 701 an einen bestimmten Standort gesendet werden, ist aus einer Fülle von Vorsichtsmaßnahmen und mit der Erwartung, dass nicht alle Fahrzeuge 701 ankommen können, das Ergebnis der Überversorgung von Fahrzeugen 701 zur Evakuierung sicherlich besser als diese Fahrzeuge 701 ohne Anweisungen im Leerlauf zu belassen.
  • Wenn Fahrzeuge 701 einen gegebenen Standort verlassen, können Nachrichten (z. B. von einem Menschen über ein Funkgerät) zurückgesendet werden, um in einen Koordinierungsprozess eingespeist zu werden, der auf einem Regierungsserver 721 oder einem anderen geeigneten Koordinierungsserver ausgeführt wird), der alle Fahrzeuge 701, die zu dem nun evakuierten Standort fahren oder sich dort befinden, umzufunktionieren und diese Fahrzeuge 701 an einen oder mehrere Standorte zu senden. Auf diese Weise können die autonomen Fahrzeuge 701 weiterhin die Evakuierung und den Transport unterstützen, obwohl eine direkte Kommunikation mit diesen Fahrzeugen 701 derzeit nicht verfügbar ist. Da das Fahrzeug 701 in der Lage sein kann, auf Grundlage von Onboard-Computing und Fahrzeug-zu-Fahrzeug (V2V)-und Fahrzeug-zu-Infrastruktur (V2I)-Kommunikation oder einem Teil dieser Kommunikation, wenn einige nicht verfügbar sind, zu einem Ziel zu fahren und zu navigieren, muss das Fehlen von Mobilfunkkommunikation kein vollständiges Hindernis für die Beauftragung und Fahrt von autonomen Fahrzeugen darstellen.
  • 8 zeigt einen veranschaulichenden Prozess für den Einsatz eines autonomen Fahrzeugs unter Verwendung von Broadcast. In diesem veranschaulichenden Beispiel ist ein Koordinierungsprozess zum Beispiel durch den Stadtserver 721 ausführbar. Der Server 721 erfasst oder empfängt bei 801 eine Angabe eines Mobilfunkausfalls für einen Teil oder den gesamten Bereich, für den der Server 721 verantwortlich ist. Der Server 721 kann normalerweise keine Kontrolle oder Rechte zum Beauftragen von Fahrzeuge 701 haben, außer in einer Notfallsituation; wenn aber ein Mobilfunknetz ausfällt und/oder wenn ein Notfall-Broadcast von einem Fahrzeug 701 empfangen wird, kann das Fahrzeug 701 in einen Modus wechseln, der es Befehlen von dem Stadtserver 721 ermöglicht, Ziele des Fahrzeugs anzuweisen.
  • Wenn der Netzausfall zum Beispiel auf einen vorübergehenden Ausfall zurückzuführen wäre oder wenn das Notsignal ein Test war, wäre das Annehmen derartiger Befehle durch das Fahrzeug 701 kein Problem, da keine Befehle empfangen werden würden. Ferner können die Fahrzeuge 701 warten, bis eine aktuelle Strecke abgeschlossen ist oder bis keine Fahrgäste mehr verbleiben, bevor sie den Zustand wechseln, um derartige Befehle anzunehmen, sodass zusätzliche Zusicherungen vorliegen können, dass ein aktuell besetztes Fahrzeug 701 nicht erneut beauftragt wird, während es bereits als Transport dient.
  • Wenn der Server 721 ein OEM-Server oder ein Server, der bereits über Steuerprivilegien verfügt, ist, kann die Koordinierung, welche Fahrzeuge 701 erneut bearbeitet werden sollen, auf Grundlage einer Kenntnis darüber erfolgen, welche Fahrzeuge 701 bereits verwendet wurden oder mit einer Abholung beauftragt wurden. Der Stadtserver 721 könnte auf Wunsch ebenfalls Zugang zu einer derartigen Einspeisung haben und könnte so ferner sicherstellen, dass bis zu einem geeigneten Zeitpunkt (z. B. keine Fahrgäste anwesend) keine Fahrzeuge 701 unter Verwendung umfunktioniert wurden.
  • Der Server 721 kann dann eine Einsatzstrategie zum Beispiel auf Grundlage von bekannten Evakuierungsbereichen formulieren. Dies kann eine beliebige Art von angemessener Priorisierung beinhalten, die üblicherweise den Planern für Evakuierungsszenarien vorbehalten wäre. Die Formulierung des Einsatzes bei 803 kann zum Beispiel ein Definieren von Geofences um bekannte Evakuierungspunkte beinhalten, um sicherzustellen, dass eine geeignete Anzahl bekannter Fahrzeuge 701 einen gegebenen Assistenzbefehl empfängt. In einigen Fällen kann dies auf Grundlage von Gesamtfahrzeugstandorten erfolgen (z. B. Festlegen des Geofence an einem Umkreis auf Grundlage des Umfassens der 50 Fahrzeuge 701, die dem Ort, der 40 Fahrzeuge erfordert, am nächsten sind) und in anderen Fällen kann dies eine Annahme auf Grundlage von typischer Fahrzeugdichte sein, wenn die genauen Standorte aller Fahrzeuge 701 nicht bekannt sind oder nicht bekannt sein können (z. B. typischerweise 10 Fahrzeuge 701 pro Block in einer Stadt, Setzen des Fence bei einem 2x2-Block-Gitter mit dem Evakuierungspunkt in der Mitte und Annehmen, dass ungefähr 40 Fahrzeuge 701 verfügbar sind).
  • Die Formulierung der Fences ist ein dynamischer Prozess, der wiederholt werden kann, wenn verschiedene Punkte evakuiert werden. Bestimmte Fahrzeuge 701 können zu weiteren Punkten entsendet werden und diese Beauftragung kann sogar aus einer Zone oder einem Geofence stammen, die/der sich nicht innerhalb des Fences für diese Punkte befinden. Zum Beispiel kann eine Teilmenge von Fahrzeugen 701 angewiesen werden, mit der Fahrt zu einem weiteren Punkt, dem ansonsten Fahrzeuge fehlen könnten, zu beginnen.
  • Obwohl alle Fahrzeuge 701 innerhalb eines Fences auf Grundlage dessen, dass sie sich innerhalb des Fences befinden, die gleiche Nachricht empfangen, könnte diese Neubeauftragung durch einen relativ einfachen Prozess erreicht werden. Zum Beispiel könnten Fahrzeuge 701 mit bestimmten Eigenschaften (z. B. hohe Kapazität, hohe Kraftstoffreichweite, Geländefähigkeit) an entfernte Regionen gesendet werden und würden diesen anderen Befehl auf Grundlage der Eigenschaft des Fahrzeugs 701 sowie der geografischen Eigenschaft, sich innerhalb eines Geofences zu befinden, empfangen.
  • In einem anderen Beispiel könnte hochgerechnet oder bekannt sein, dass sich 200 Fahrzeuge 701 in einem Bereich befinden, der nur 100 Fahrzeuge 701 an dem Evakuierungspunkt A benötigte, und es gab einige abgelegene Bereiche, die nur 20 Fahrzeuge 701 aufwiesen, aber jeweils 30 Fahrzeuge 701 an den Evakuierungspunkten B und C benötigten.
  • Eine Option könnte darin bestehen, alle 200 Fahrzeuge 701 an den Evakuierungspunkt A zu senden und dann die Fahrzeuge 701, die nach Abschluss der Evakuierung bei Punkt A nicht verwendet wurde, umzufunktionieren. Dies würde jedoch ein Senden von weitaus mehr Fahrzeugen 701 als erforderlich an den Evakuierungspunkt A beinhalten. Lediglich als Beispiel bestünde eine alternative Lösung darin, einen Anweisungssatz an die 200 Fahrzeuge zu senden, wobei die Anweisung zwei alternative Standorte B und C und eine Anweisung für ein gegebenes Fahrzeug 701, einen Randomisierer zu betreiben, beinhaltet.
  • Es wird angenommen, dass es als akzeptabel erachtet wurde, 150 Fahrzeuge 701 zu dem größeren Evakuierungspunkt A (falls einige Fahrzeuge 701 es nicht schaffen) und jeweils 25 zu den äußeren Punkten B und C zu senden. Dies würde jedem Punkt 150 % der benötigten Fahrzeuge 701 geben, die in Richtung eines jeweiligen Standorts fahren.
  • In diesem Beispiel könnte jedes Fahrzeug 701 zwischen 1 und 4 randomisieren. Wenn das Fahrzeug 701 eine 1 oder 2 erzeugt, würde es den primären Anweisungen zu dem großen Evakuierungspunkt A folgen, wenn das Fahrzeug 701 eine 3 erzeugt, würde es zu Punkt B fahren, und wenn es eine 4 erzeugt, würde es zu Punkt C fahren. Dies würde im Allgemeinen zu einer groben Näherung der korrekten Anzahl von Fahrzeugen 701 führen, die zu jedem Punkt fahren. Die Randomisierung würde wahrscheinlich zu einigen Abweichungen führen (z. B. 154 Fahrzeuge 701 zu A, 52 Fahrzeuge 701 zu B, 44 Fahrzeuge 701 zu C), aber bei einer größeren Anzahl von Fahrzeugen 701 würde sich dies abflachen, und jedem Standort werden bereits 150 % des eigentlichen Bedarfs gesendet, sodass eine gewisse Varianz immer noch die korrekte Anzahl von Mindestfahrzeugen 701 aufweisen sollte, die zu einem gegebenen Standort fahren.
  • Dies ermöglicht eine gewisse Granularität der Steuerung, obwohl keine direkte Steuerung der Fahrzeuge 701 erreicht werden kann. Ferner könnten, wenn die große Zone (200 Fahrzeugzone) Fahrzeuge 701 aufweist, die über die gesamte Fläche verteilt sind, Fahrzeuge 701, die sich näher an B oder näher an C befinden, vom Erreichen des weiteren Ergebnisses ausgenommen werden. Dies würde zum Beispiel dadurch erreicht werden, dass ein Fahrzeug 701 angewiesen wird, dass, wenn es C als das Ziel auf Grundlage der Randomisierung erzeugt, sich aber in einem „No-C-Auswahl“-Fence befindet, es stattdessen erneut randomisiert oder spezifisch A oder B zugewiesen werden würde. B kann eine bessere Wahl sein, da die Wahrscheinlichkeit eines falsch positiven Ergebnisses für B oder C gleich wäre (25 %) und somit ein gleicher Prozentsatz der Fahrzeuge 701 in jeder Region falsch positive Ergebnisse erzeugen würde, aber ihre Ziele ohne eine direkte Steuerung oder Kenntnis der anderen Fahrzeuge austauschen würde.
  • Eine Gewichtung oder andere Beschränkungen könnten dazu verwendet werden, die Zufälligkeit zu variieren, sodass Fahrzeuge 701 in der großen Zone, die ebenfalls B am nächsten waren, die höchste Wahrscheinlichkeit für eine Randomisierung auf B hatten, und das gleiche gilt mit C. Die ATSC-Anweisungen müssen es nicht einmal wissen, wo sich Fahrzeuge 701 tatsächlich befinden, um dies zu erreichen; es kann einfach auf Grundlage von gegenwärtigen GPS-Koordinaten eine Gewichtung zugewiesen werden, sodass ein gegebenes Fahrzeug 701 die richtige Gewichtung für dieses Fahrzeug 701 bestimmen kann.
  • Eine genauere Steuerung kann erreicht werden, wenn mehr Informationen über Fahrzeugstandorte genau bekannt sind, aber in bestimmten wetterbezogenen Situationen oder sogar in städtischen Straßenschluchten kann es schwierig gewesen sein, genau zu wissen, wo sich jedes Fahrzeug 701 befand, bevor der Kontakt verloren wurde, und somit könnte das einfache Wissen, dass sich 200 Fahrzeuge 701 in der Zone A befinden, ausreichende Informationen darstellen, um einige der hierin bereitgestellten Techniken und dergleichen zu verwenden.
  • Wenn der genaue Standort jedes Fahrzeugs 701 bekannt wäre, könnte der Server 721 einfach die Zonen neu zeichnen, um die korrekte Anzahl von Fahrzeugen 701 in den Zonen zu platzieren, die B und C bedienen (z. B. die Zonen um B und C erweitern, um diese bestimmten Fahrzeuge zu umschließen).
  • Nach dem Formulieren eines geplanten Einsatzes, einschließlich beliebiger Variationen, wie etwa der vorhergehenden und dergleichen, kann der Server 721 den ATSC-Sender 715 (oder die Station, die den Sender bedient) anweisen, Anweisungen für Fahrzeuge 701 per Broadcast zu übertragen. Unter Verwendung des vorhergehenden Beispiels für die Evakuierungspunkte A, B und C und die entsprechenden Zonen A, B und C könnten die Anweisungen für alle Zonen in der Übertragung enthalten sein. Da die Anweisungen auf Grundlage von GPS-Koordinaten eines gegebenen Fahrzeugs 701 adressiert werden können, empfängt jedes Fahrzeug 701 alle Anweisungen und verwirft einfach die irrelevanten Anweisungen (oder speichert sie in einer Warteschlange zur Prüfung, nachdem ein aktueller Anweisungssatz abgeschlossen ist). Die Auswahl, welchen Anweisungen zu folgen ist, kann auf Parametern wie etwa GPS-Koordinaten, Eigenschaften des Fahrzeugs 701 (Kapazität, Kraftstoffbereich, Geländefähigkeit, Karosseriefarbe usw.) oder anderen angemessenen Parametern basieren, die durch den Server 721 mit einem gegebenen Satz von Anweisungen verknüpft sind. Wenn der Zustandssatz eines Fahrzeugs (die vorhergehenden Parameter und dergleichen) mit denjenigen übereinstimmt, die einem Satz von Anweisungen zugewiesen sind, sind dies die Anweisungen, die das Fahrzeug 701 ausführen wird.
  • Die ATSC-Übertragung kann periodisch fortgesetzt werden und wenn ein Standort (z. B. A) bei 807 die Evakuierung abgeschlossen hat, kann der Server 721 einen neuen Einsatz auf Grundlage aller Fahrzeuge 701 formulieren, die nun verfügbar sind und die entweder A nicht bedienen mussten oder die Ablieferung von Evakuierten abgeschlossen haben. Die Rückmeldung muss möglicherweise von jemandem an Standort A oder über einen anderen Indikator erfolgen, aber der Server 721 kann diese Rückmeldung einbeziehen und einen neuen Anweisungssatz senden, der nach Bedarf eine Neuzuweisung von Zonen beinhalten kann. Jedes Fahrzeug 701, für das die neuen Anweisungen gelten und das nicht aktuell Personen evakuiert (d. h. Fahrgäste an Bord hat), kann die neuen Anweisungen auf Grundlage der Parameterübereinstimmung wie vorstehend ausführen. Dies kann ein Maß an Flottenverwaltung bereitstellen, auch wenn der direkte Kontakt mit der Flotte verloren gehen kann. Wenn bei 809 angegeben wird, dass alle Evakuierungen abgeschlossen sind, kann der Server 721 einen Satz von Anweisungen, die Fahrzeuge 701 für die Dauer des verlorenen Kontakts an eine geeignete Deckung senden, formulieren und senden.
  • Bestimmte Deckungsorte, wie etwa bezeichnete überdachte Parkplätze, können eine lokalisierte direkte Kommunikation mit den Fahrzeugen 701 bereitstellen, die dort Schutz suchen, und dies kann es dem Server 721 ermöglichen, die Ressourcenzuweisung innerhalb eines Bereichs neu zu bewerten, wenn diese Fahrzeuge 701 erneut benötigt werden, bevor die Mobilfunknetze 709, 711, 713 wieder online gehen. Da die lokalisierte Kommunikation eine direkte Kommunikation bereitstellt, kann der Server 721 an jedes Fahrzeug 701 zunächst einen spezifischen Anweisungssatz senden (wenn die Fahrzeuge 701 erneut eingesetzt werden) und dann können die ATSC-Übertragungen fortgesetzt werden, bis die Fahrzeuge 701 wieder in Deckung gesendet werden.
  • Es ist auch möglich, dass mehrere ATSC-Sender unterschiedliche Regionen abdecken, und die Auswahl, welche Anweisungen über welche Sender übertragen werden sollen, kann im Vergleich zu bekannten Abdeckungsbereichen eines gegebenen ATSC-Senders auf einer Korrelation von geografischen Perimetern, die mit Anweisungen assoziiert sind, basieren. Dies könnte zu einer gewissen Überlappung der Übertragung führen, aber die Fahrzeuge 701 entscheiden letztendlich, welche Anweisungen befolgt werden sollen, und daher sollte das Empfangen von doppelten Anweisungen keine erhebliche Herausforderung darstellen. Dies kann noch abgemildert werden, indem jedes Fahrzeug 701 mit einer bereits zugewiesenen Aufgabe andere Anweisungen ignoriert, bis entweder diese Aufgabe abgeschlossen ist oder eine Anweisung mit zum Beispiel einem Übersteuerungsparameter empfangen wird, die angibt, dass das Fahrzeug 701 eine gegenwärtige Aufgabe übergehen sollte und die Übersteuerungsanweisung ausführen sollte.
  • 9 zeigt einen veranschaulichenden Prozess zum Bearbeiten eines Einsatzes, das zum Beispiel durch ein Fahrzeug 701 ausführbar ist. Wie zuvor beschrieben, kann ein gegebenes Fahrzeug 701 bei 901 einen ATSC-Broadcast empfangen, der mehr Anweisungen beinhaltet als diejenigen, die für das gegebene Fahrzeug 701 vorgesehen sind. Der Server 721 kann jedem Anweisungssatz einen Parametersatz (einen oder mehrere) zugewiesen haben und das Fahrzeug 701 kann verschiedene Parametersätze im Vergleich zu seinem eigenen Zustandssatz (z. B. Standort, Eigenschaften, sogar Kraftstoff oder andere dynamische Eigenschaften) in Betracht ziehen, um zu entscheiden, welche Anweisungen auf Grundlage von passenden Parametern ausgeführt werden sollen.
  • Anweisungen können sogar Parameter aufweisen, die zum Beispiel auf der verbleibenden fahrbaren Entfernung basieren. Unter Verwendung des Beispiels der Punkte A, B, C könnte, wenn ein Fahrzeug 701 in Zone A war und angewiesen wurde, zu Punkt C zu fahren, aber keine ausreichende verbleibende zurücklegbare Entfernung aufwies, das Fahrzeug 701 diese Anweisung ignorieren und eine Anweisung neu auswählen, die abgesehen von C die nächstgelegene Übereinstimmung war (B oder A).
  • Der Server 721 verknüpft möglicherweise keine Parameter, wie etwa die zurücklegbare Entfernung, mit der anfänglichen Auswahl eines Anweisungssatzes, da der Server 721 nicht weiß, wie weit ein gegebenes Fahrzeug 701 von einem Evakuierungspunkt entfernt ist. Aber sobald das Fahrzeug 701 den Satz ausgewählt hat, kann das Fahrzeug 701 diese Bestimmung treffen, indem es den Evakuierungspunkt, seinen gegenwärtigen Standort und ein letztes Ziel kennt. In einer anderen Option könnte der Auswahlparameter dies berücksichtigen, indem dem Fahrzeug 701 Evakuierungs- und Zielkoordinaten bereitgestellt werden (wo die Evakuierten abgesetzt werden), und das Fahrzeug 701 verfügt über Anweisungen, dieses Koordinatenpaar zu verwenden, um zu bestimmen, ob das Fahrzeug 701 eine solche Fahrt vor dem Auswählen dieses Anweisungssatzes durchführen kann.
  • Das Fahrzeug 701 kann Anweisungen, die gegenwärtig nicht ausgeführt werden, bei 903 verwerfen oder in eine Warteschlange stellen. Wenn die gegenwärtig angenommene Anweisung eine oder mehrere Strecken beinhaltet, die durch das Fahrzeug 701 bei 905 ausgeführt werden sollen, führt das Fahrzeug 701 diese Strecken bei 907 aus. Einige Fahrzeuge 701 können zum Beispiel eine Anweisung erhalten, an Ort und Stelle zu bleiben, wodurch sie als Ressource für beliebige lokale Bedürfnisse, die auftreten, verbleiben, ohne dass ihre Kraftstoffzufuhr erschöpft wird, indem sie (aus der Perspektive dieses Fahrzeugs) zu einem zu weit entfernten Standort für entfernte Evakuierungspunkte gesendet werden.
  • 10 zeigt einen veranschaulichenden Prozess zum Umfunktionieren eines Einsatzes. Wie zuvor angemerkt, kann, wenn die Evakuierung eines gegebenen Evakuierungspunkts abgeschlossen ist, eine Form von Rückmeldung verwendet werden, um den Server 721 darüber zu informieren, dass die Evakuierung bei 1001 abgeschlossen ist. Dies kann zum Beispiel Funkkommunikation zwischen zwei Menschen, von denen einer die Daten in einen Server eingibt, Funkkommunikation mit dem Server 721, die angibt, dass die Evakuierung abgeschlossen ist (z. B. Spracherkennung, codierte Übertragung usw.), oder sogar ein oder mehrere Fahrzeuge 701, die einen Erfolg melden, wenn diese Fahrzeuge 701 in eine Zone fahren, in der noch Mobilfunkkommunikation besteht und eine direkte Kommunikation mit einem Fahrzeug 701 erneut erreicht werden kann, beinhalten.
  • An diesem Punkt muss der Server 721 möglicherweise einen neuen Evakuierungsplan formulieren, um verbleibende Evakuierungspunkte zu berücksichtigen. Da der Server 721 möglicherweise eine Vielzahl von zusätzlichen Fahrzeugen 721 an den Evakuierungsort gesendet hat, kann der Server 721 eine kurze Beendigungsanweisung an die Fahrzeuge 701 in einer gegebenen Zone senden, was dazu führen kann, dass diese Fahrzeuge 701 an Ort und Stelle warten, anstatt sie alle weiter zum Evakuierungspunkt fahren zu lassen. Ob dies getan werden kann oder nicht, kann zum Beispiel auf Grundlage davon bestimmt werden, ob es einfacher ist, diese Fahrzeuge 701 auf Grundlage von Annahmen über ihren gegenwärtigen Standort oder dem Wissen, dass sie alle an dem bekannten Standort der Evakuierungszone beginnen, erneut einzusetzen.
  • In einem derartigen Fall können die Fahrzeuge 701 dazu programmiert sein, neue Anweisungen zu ignorieren, während eine vorliegende Anweisung ausgeführt wird (da das Fahrzeug 701 nicht weiß, dass die Evakuierung abgeschlossen ist). In diesem Fall kann die Anweisung eine Übersteuerungsanweisung sein, die von allen Fahrzeugen empfangen wird, von den Fahrzeugen 701 in einer gegebenen Zone angenommen wird und dann auf Grundlage des Übersteuerungsparameters ausgeführt wird (anstatt in die Warteschlange gestellt oder verworfen zu werden), und die bei Abwesenheit des Übersteuerungsparameters nicht aufgetreten wäre, wobei die Anweisung andernfalls in die Warteschlange gestellt oder verworfen worden wäre.
  • Während die Fahrzeuge 701 warten (falls erforderlich), identifiziert der Server 721 bei 1005 neue oder andere Evakuierungszonen oder -punkte, zu denen die Fahrzeuge 701 fahren können, und formuliert dann bei 803 (ähnlich 803) einen neuen Evakuierungsplan und überträgt diesen Plan bei 805.
  • 11 zeigt einen veranschaulichenden Prozess zur Bereitstellung eines Mobilfunkanbieters unter Verwendung von Broadcast. Dieser Prozess könnte von einem Server 721 ausgeführt werden, obwohl der Prozess in diesem Fall häufiger von einem OEM-Server 721 als einem Stadtverwaltungsserver ausgeführt werden würde. Aus Gründen der Veranschaulichung ist es jedoch nicht unbedingt wichtig, wer den Server bereitstellt, sondern einfach, dass ein Server 721 in Kommunikation mit einem ATSC-Sender 715 (oder einer Steuerung des Senders) die Übertragung der verschiedenen hierin erörterten Anweisungen und Anforderungen anweisen kann.
  • In diesem Beispiel verteilt der Server 721 als Reaktion auf einen erkannten Fehler in einem oder mehreren Mobilfunknetzen Anweisungen zum Umprogrammieren von Mobilfunkprofilen. So kann zum Beispiel in dem vorhergehenden Beispiel eines wetterbezogenen Vorfalls, der ein oder mehrere Mobilfunknetze deaktiviert, vor dem Verwenden der ATSC-Technologie zum Senden von Anweisungen an Fahrzeuge 701 der Server 721 (oder ein anderer Server) versuchen, einen Prozess wie etwa dieses Beispiel oder dergleichen auszuführen, um, wenn möglich, die direkte Kontrolle über die Fahrzeuge 701 aufrechtzuerhalten. Wenngleich dies kein notwendiger Schritt vor dem Senden von ATSC-Evakuierungsanweisungen ist, kann die direkte Steuerung über die Fahrzeuge 701 das Lenken dieser Fahrzeuge 701 erleichtern; wenn also ein einfacher Versuch, verlorene Mobilfunkverbindungen neu zu konfigurieren, unternommen werden kann, während der Server 721 zum Beispiel einen Evakuierungsplan formuliert, kann es sich lohnen, in einigen Fällen zu senden.
  • In Mobilfunknetzen können bestimmte Ausfälle auftreten, die zum Beispiel das Lenken von einem Netzwerk A zu einem Backend-Server, einen vollständigen Ausfall des Netzwerks A, der die Verwendung eines anderen Netzwerks B erfordert, usw. beinhalten. Dieses Problem wurde bereits zuvor erkannt und Vorschläge zur Behebung des Problems beinhalten typischerweise ein Verwenden eines abnehmenden Signals an A, um neue Informationen über B zu empfangen, was einem Fahrzeug 701 den Übergang ermöglicht, wenn das Signal an A unbrauchbar wird. Das Problem mit einer derartigen Lösung besteht darin, dass, wenn Netzwerk A plötzlich und unerwartet verloren geht (z. B. ein Turm umgerissen oder deaktiviert wird), keine Planung stattgefunden hat und daher das Fahrzeug 701 einfach ohne eine Verbindung zurückgelassen wird.
  • Da dem Fahrzeug 701 eine aktive Verbindung fehlt, hat das Fahrzeug 701 keine Möglichkeit, eine Umprogrammierung oder eine beliebige andere Kommunikation anzufordern oder das Netzwerk sogar darüber zu informieren, dass es die Verbindung verloren hat (im Gegensatz dazu wurde es zum Beispiel einfach geparkt und heruntergefahren). Somit bieten zum Beispiel in unerwarteten Trennungs- und Netzwerkunterbrechungssituationen die vorherigen Systeme zur Planung im Voraus für eine Trennung auf Grundlage eines abnehmenden Signals oder sogar eines bevorstehenden bekannten Signalverlusts nicht viel nützliche Unterstützung.
  • Wenn der Server 721 bei 1101 einen Netzwerkausfall erfasst oder darüber benachrichtigt wird, kann der Server 721 in diesem Beispiel auch bestimmen oder darüber benachrichtigt werden, welche Art von Fehler aufgetreten ist. Zum Beispiel kann der Server 721 benachrichtigt werden, wenn der Fehler auf ein deaktiviertes Netzwerk oder auf eine Fehlfunktion des Lenken zwischen dem Funknetz und dem Backend zurückzuführen ist. In dem ersten Beispiel bestimmt der Server 721 einen neuen Träger, und in dem letzteren Beispiel bestimmt der Server 721 einen neuen Zugangspunktnamen (APN) für dasselbe Netzwerk, was ein anderes Lenken ermöglicht, wenn die vorherige Verbindung zwischen dem Funknetz und dem Backend nicht funktionierte. Diese werden bei 1103 bestimmt und können alle Fahrzeuge und nicht nur AV beinhalten.
  • Um ein neues Netzwerk nicht zu überlasten, kann der Server 721 zum Beispiel eine Vielzahl von Alternativen für ein verlorenes Netzwerk bestimmen, sodass der gesamte Netzwerkverkehr nicht sofort auf ein neues Netzwerk verschoben wird. In einem derartigen Fall teilt der Server 721 die neuen Netzwerkprofile wie zuvor auf Grundlage eines Parameters bei 1105. Dies kann zum Beispiel auf Abdeckungsbereichen basieren, die bessere oder schlechtere unterschiedliche Netzwerke aufweisen (z. B. überspannt das Netzwerk D Abdeckungsbereiche der Netzwerke E und F, das Netzwerk D fällt aus, der Server 721 kann Fahrzeuge 701 in Bereichen anweisen, die besser durch E bedient werden, um E zu verwenden, und dasselbe gilt für F). Die Parameter können zum Beispiel auch einen Parameter beinhalten, den das Fahrzeug 701 hauptsächlich in dem Netzwerk D (oder in welchem Netzwerk auch immer der Fehler behoben wurde) verwendet hat oder zuvor damit verbunden war. Dies kann zum Beispiel beinhalten, dass der Server 721 neue Netzwerkprofile an Fahrzeuge in per Geofencing eingegrenzten Bereichen per Broadcast sendet, um zu einem neuen Netzwerk zu wechseln, das einem Bereich zugewiesen ist. Jeder Geofence kann ein neues Netzwerk und ein ihm zugewiesenes Profil aufweisen, und dies kann Fahrzeuge aufnehmen, die ansonsten kein gegebenes alternatives Netzwerk kennen und denen ansonsten kein Profil für dieses Netzwerk fehlt.
  • Der Server 721 kann alternative Netzwerke auf eine beliebige angemessene Weise bereitstellen, was nicht ausschließt, dass alle Fahrzeuge 701 angewiesen werden, zu einem einzelnen neuen Netzwerk zu wechseln. Der Server 721 weist den Sender 715 an, die Umprogrammierungsanweisungen bei 1107 zu senden.
  • Da in diesem Beispiel Fahrzeuge 701, die die Kommunikation mit dem Server 721 verloren haben, nun die Kommunikation wiedererlangen, kann der Server 721 tatsächlich eine Rückmeldung empfangen, sobald sich die Fahrzeuge 701 bei 1109 mit dem neuen Netzwerk verbinden. Dies ermöglicht es dem Server 721, zumindest teilweise sicherzustellen, dass die Umprogrammierungsanweisungen erfolgreich waren, sowie zu bestimmen, ob eine bestimmte Umprogrammierungsanweisung nicht funktioniert oder ein neues vorgeschlagenes Netzwerk nicht zu funktionieren scheint.
  • Der Server 721 kann wissen, mit wie vielen Fahrzeugen 701 er die Verbindung verloren hat, als ein Netzwerk ausgefallen ist, was es dem Server 721 ermöglicht, den Erfolg einer beliebigen Umprogrammierungsanweisung bis zu einem gewissen Grad zu bestimmen. In diesem Beispiel prüft der Server 721 bei 1111, ob ein bestimmter Prozentsatz von verlorenen Fahrzeugen 701 über ein neues Netzwerk wieder online ist. Das heißt, unter Verwendung des Beispiels der D-, E-, F-Netzwerke kann der Server 721 die Kommunikation mit 5000 Fahrzeugen 701 verlieren, wenn das Netzwerk D ausfällt. Auf Grundlage der geografischen Kapazität, der Netzwerkkapazität usw. kann der Server 721 Anweisungen an 2000 Fahrzeuge 701 senden, um zu Netzwerk E zu wechseln, und 3000 Fahrzeuge 701, um zu Netzwerk F zu wechseln. Da der Server möglicherweise keine Kontrolle darüber hat, wie vielen Fahrzeugen er eine Nachricht über ATSC endet, da es sich um einen Broadcast handelt, können Geofencing oder Randomisierung in Umprogrammierungsanweisungen eingeschlossen sein, wie zuvor erörtert. Zum Beispiel kann der Server Profile auf Grundlage von Geofences zuweisen, die mehr oder weniger 2000 bzw. 3000 Fahrzeuge abdecken sollten, und/oder könnte Anweisungen an jedes Fahrzeug senden, um zwischen 1 und 5 zu randomisieren, wobei 1 und 2 zu Netzwerk E und 3-5 zu Netzwerk F gehen.
  • Wenn sie sich mit dem Netzwerk verbinden, stellen die Fahrzeuge 701 die Kommunikation mit dem Server wieder her, und so kann der Server 721 einen Prozentsatz der Fahrzeuge 701 bestimmen, die sich erneut verbunden haben. In diesem Beispiel kann der Prozentsatz bei einer bestimmten Anzahl als akzeptabel vordefiniert sein, was die Wahrscheinlichkeit berücksichtigen kann, dass bestimmte Fahrzeuge 701 einfach ausgeschaltet wurden oder anderweitig absichtlich getrennt wurden. Wenn der Prozentsatz bei 1111 zum Beispiel 90 Prozent für das Netzwerk E erreicht, kann der Server 721 das Broadcasten von Anweisungen zum Umfunktionieren an das Netzwerk E beenden.
  • Gleichzeitig kann der Wiederverbindungsprozentsatz für das Netzwerk F gegenwärtig nur bei 30 Prozent liegen. In einem derartigen Fall kann der Server 721 bei 1113 eine Zeitüberschreitungsverzögerung abwarten und dann entweder einen Broadcast erneut senden und/oder einen gewissen Prozentsatz der Fahrzeuge 701, die angewiesen sind, sich mit F zu verbinden, an E neu zuweisen. Somit, wenn E die weiter erhöhte Last handhaben kann und der Server 721 weiß, dass die Änderung zu E weitgehend erfolgreich war, kann der Server 721 bei 1115 die Fahrzeuge 701, die sich noch nicht erfolgreich mit F verbunden haben, zu E überführen. Zusätzlich oder alternativ kann der Server 721 die anfängliche Anweisung zum Verbinden mit F erneut broadcasten, da eine Anzahl von Fahrzeugen 701 die Anweisung aus einem anderen Grund (z. B. Interferenzursache durch städtische Straßenschluchten, im Untergrund befindlich usw.) nicht empfangen haben kann. Sobald ein geeigneter Prozentsatz aller Fahrzeuge 701 wieder verbunden ist, kann der Server 721 bei 1117 die Broadcast-Anweisung für alle neuen Netzwerke oder Zugangspunktnamen beenden.
  • 12 zeigt einen veranschaulichenden Prozess zum Bearbeiten der Bereitstellung eines Mobilfunkanbieters. Dieser beispielhafte Prozess kann zum Beispiel dadurch ausgeführt werden, dass ein Fahrzeug 701 Anweisungen von einem entfernten Server 721 empfängt.
  • In diesem veranschaulichenden Beispiel empfängt das Fahrzeug 701 eine ATSC-Nachricht, die ein neues Mobilfunknetz oder einen neuen Zugangspunktnamen angibt, der durch das Fahrzeug 701 verwendet werden könnte. Da der Server 721, der die Nachrichtenübermittlung koordiniert, diese Informationen an alle Fahrzeuge 701 senden kann, die von einer Trennung betroffen sein könnten, aber nicht betroffen waren, kann die Nachricht einen oder mehrere Parameter (z. B. GPS-Standort, eine jetzt verloren gegangene Verbindungsidentifikation usw.) zur Anwendung der Nachricht beinhalten und das Fahrzeug 701 kann bei 1203 bestimmen, ob der relevante Parameter zutrifft.
  • Da der Parameter einfach ein eingestellter GPS-Standort sein kann, wie etwa ein Geofence, da der ATSC-Sender 715 einen Bereich abdecken kann, der größer als ein betroffener Bereich ist, und somit die Nachricht als nur für Fahrzeuge 701 in dem betroffenen Bereich zutreffend kennzeichnen kann, kann eine zusätzliche Überlegung durch das Fahrzeug 701 darin bestehen, ob das Fahrzeug 701 bei 1205 aktuell eine unterbrochene Verbindung erfährt. Das heißt, selbst wenn der Server 721 die verlorenen Verbindungen in der Nachricht nicht identifiziert, kann sich das Fahrzeug 701 in dem betroffenen Bereich befinden (und somit die Nachricht empfangen und verarbeiten), aber möglicherweise keine verlorene Verbindung erfahren, was das Fahrzeug 701 veranlassen würde, die Nachricht bei 1207 zu verwerfen. In anderen Beispielen kann der Server 721 eine Identifizierung der verlorenen Verbindung in der Nachricht beinhalten, sodass nur Fahrzeuge 701, die zuvor mit der verlorenen Verbindung verbunden waren, die Nachricht sogar ohne Verwerfen an erster Stelle verarbeiten.
  • Wenn die Nachricht bei 1209 einen neuen Zugangspunktnamen beinhaltet, kann das Fahrzeug 701, das die Nachricht empfängt und verarbeitet, ein Kommunikationsprofil dieses Fahrzeugs 701 wechseln, um den neuen Zugangspunktnamen bei 1211 zu verwenden. Alternativ, wenn die Nachricht ein neues Mobilfunkprofil beinhaltet, das bei 1213 einen neuen Netzbetreiber definiert, der verwendet werden soll, kann das Fahrzeug 701 die Informationen dazu verwenden, die Telematiksteuereinheit (TCU) neu zu programmieren, um das neu identifizierte Netzwerk bei 1215 zu verwenden. Dies kann die Verwendung eines identifizierten neuen Zugangspunktnamens (APN) bei 1217 beinhalten. Es können auch andere Kommunikationsalternativen angewiesen sein und dies sind lediglich Beispiele für mehrere Alternativen und ihre Verwendung.
  • 13A und 13B zeigen veranschaulichende Prozesse zum Sammeln von Daten unter Verwendung von Broadcast und Antwort. Dies ist ein allgemeines Konzept, das veranschaulicht, wie ATSC-Technologie dazu verwendet werden kann, eine Vielzahl von Daten von Fahrzeugen 701 innerhalb eines Broadcast-Bereichs des ATSC-Senders zu sammeln.
  • Aus vielen Gründen möchte ein OEM oder eine andere autorisierte Partei möglicherweise ein bestimmtes Element oder bestimmte Datenelemente von einer Vielzahl von Fahrzeugen 701 auf einmal sammeln. Wenn es zum Beispiel zu schneien begonnen hat, möchte die interessierte Partei möglicherweise wissen, wie viele Fahrzeuge 701 die Geschwindigkeit unter 25 Meilen pro Stunde reduziert haben. Um Ergebnisse von Fahrzeugen 701, die auf Straßen mit niedriger Geschwindigkeit fahren, auszuschließen, könnten diese Straßen als zusätzlicher Parameter dienen und durch Broadcasten der Anforderung an alle Fahrzeuge 701 in einem Übertragungsbereich und durch Empfangen von Antworten praktisch einer beliebigen Teilmenge von Fahrzeugdaten für eine Region, oder für bestimmte Arten von Fahrzeugen 701 innerhalb des Broadcast-Radius, schnell erhalten werden.
  • Die vorangehende Anforderung könnte auf vielfältige Weise formuliert werden. Es werden mehrere nicht einschränkende Beispiele dargelegt, wie ein Fahrzeug 701 die Nachricht verwerfen oder diese annehmen und antworten würde. Eine Wahl wäre, Annahmeparameter von Geschwindigkeit <25 mph und Standort = eine beliebige Straße mit einer Geschwindigkeitsbegrenzung >25 mph einzustellen. Dann würden nur Fahrzeuge 701 mit den richtigen Geschwindigkeiten und Standorten sogar die Nachricht zum Beginnen annehmen und diese Fahrzeuge 701 könnten ihre Geschwindigkeiten oder die einfache Tatsache der Fahrt unter 25 mph ohne weitere Berücksichtigung melden. Der Bericht könnte über die Telematiksteuereinheit der Fahrzeuge 701 zurück an den OEM oder die autorisierte Partei erfolgen.
  • Ein weiteres Beispiel wäre, die Geschwindigkeit des Fahrzeugs 701 in dem Bericht anzufordern, aber nur auf Straßen mit Geschwindigkeitsbegrenzungen >25 mph. Dann würden alle Fahrzeuge 701, die auf Straßen mit Geschwindigkeitsbegrenzungen über 25 mph fahren, ihre Geschwindigkeit melden. Ein drittes Beispiel könnte darin bestehen, Annahmeparameter zum „Fahren mit mehr als 10 mph unter der bekannten Geschwindigkeitsbegrenzung“ festzulegen, wodurch vermieden werden würde, bestimmen zu müssen, welche bestimmten Straßen niedrigere Geschwindigkeitsbegrenzungen unter 25 mph aufweisen, und die Fahrzeuge 701 könnten bestimmen (unter der Annahme, dass sie Navigationssysteme aufgewiesen haben, die die gegenwärtige Geschwindigkeitsbegrenzung oder einen anderen Zugriff auf derartige Daten angeben), ob sie beide um mehr als 10 mph unter einer angegebenen Geschwindigkeitsbegrenzung gefahren sind. Dies könnte dazu führen, dass sich einige Fahrzeuge 701 melden, die 15 mph auf einer Straße mit 25 mph gefahren sind, aber das können auch nützliche Informationen sein. Darüber hinaus könnte die Nachricht selbst Meldebeschränkungen beinhalten, die diese Fahrzeuge 701 in Bezug auf die Meldung beschränkt haben.
  • Fahrzeuge 701 verwerfen nicht notwendigerweise Nachrichten, die nicht zutreffen; sie können auch bestimmte Nachrichten auf Grundlage anwendbarer Parameter in eine Warteschlange stellen. Wenn zum Beispiel der Parameter dynamisch war und durch das Fahrzeug erfüllt werden könnte, kann die Nachricht für einen vorbestimmten Zeitraum oder für einen nachrichtendefinierten Zeitraum in die Warteschlange gestellt werden. Wenn der Parameter statisch war (z. B. vehicle_type = SUV) und das Fahrzeug 701 möglicherweise nie den Parameter erfüllen könnte (z. B. war das Fahrzeug 701 kein SUV und wäre dies auch nie), kann die Nachricht verworfen werden.
  • In dem gezeigten Beispiel empfängt ein Server 721 bei 1301 eine Datenanforderung. Dies könnte von einem anderen entfernten Server (z. B. fordert ein städtischer Dienstserver die vorhergehenden Daten von einem OEM-Server 721 an, um die Verkehrsantwort auf einen Schneesturm zu messen) oder von einem anderen OEM-internen System stammen. Zum Beispiel können Techniker an einem Projekt arbeiten und einen Datenpunkt benötigen, um zu verstehen, wie ein aktuelles System verwendet wird. Die Techniker könnten relevante Parameter entwickeln (z. B. Fahrzeuge 701, die unter Temperaturbedingungen über 90 Grad fahren, Fahrzeuge 701, die mit gekühlten Sitzen ausgestattet sind, um zu bestimmen, wie viele dieser Fahrzeuge 701 gekühlte Sitze bei diesen Temperaturen verwendeten) und anfordern, dass der Server 721 derartige Meldungsanforderungen an Fahrzeuge 701 über einen großen Bereich (wie etwa landesweit) über eine Vielzahl von ATSC-Sendern 715 aussendet.
  • Der Server 721 könnte bei 1303 die relevanten Parameter zum Annehmen der Nachricht und/oder relevante Parameter zum Einreihen in die Warteschlange und/oder relevante Parameter für das Fahrzeug 701, die bei der Meldung berücksichtigt werden sollen, zuweisen. Der Server 721 weist dann die Vielzahl von ATSC-Sendern 715 an, den Broadcast zu senden, und Fahrzeuge 701, die den Broadcast empfangen, für die der Broadcast gilt, können sich selbst als geeignet und wie durch den Broadcast definiert melden.
  • Wenn ein Fahrzeug 701 bei 1307 den Broadcast empfängt, bestimmt das Fahrzeug 701 auf Grundlage der Annahmeparameter bei 1309, ob die Nachricht oder Anforderung für dieses Fahrzeug 701 gilt. Erneut kann dies zum Beispiel Umgebungsparameter, geografische Parameter, Eigenschaften des Fahrzeugs 701 usw. beinhalten. Wenn die Parameter nicht erfüllt sind, kann das Fahrzeug 701 bei 1311 bestimmen, ob es Warteschlangenparameter gibt, die der Nachricht zugeordnet sind. In einigen Beispielen können keine Warteschlangenparameter vorhanden sein, sondern das Fahrzeug 701 kann stattdessen, wie zuvor angemerkt, eine Nachricht in eine Warteschlange einreihen oder nicht, basierend darauf, ob das Fahrzeug 701 die Annahmeparameter zu einem späteren Zeitpunkt erfüllen könnte (z. B. Wetter oder Geschwindigkeit könnten erreicht werden, eine Änderung des Karosserietyps des Fahrzeugs 701 könnte nicht).
  • Wenn das Fahrzeug 701 bestimmt, dass keine Warteschlange benötigt wird, kann das Fahrzeug 701 die Nachricht bei 1315 verwerfen. Andernfalls kann das Fahrzeug 701 die Nachricht bei 1317 in eine Warteschlange stellen, was dazu führen kann, dass die Nachricht zu einem Zeitpunkt verarbeitet wird, zu dem der Parameter bei 1309 erfüllt ist. Sobald die Nachricht von dem Fahrzeug verarbeitet wurde, antwortet das Fahrzeug 701 bei 1313 auf die Abfrage in der Nachricht, wiederum gemäß beliebigen Anweisungen und/oder Einschränkungen, die in der Nachricht spezifiziert sind.
  • In noch einem weiteren beispielhaften Anwendungsfall der ATSC-Technologie kann das dynamische Routen von Fahrzeugen 701 außerhalb eines Ortes auf eine Weise erreicht werden, die Netzwerke, die bereits unter erhöhtem Verkehr zu leiden haben, nicht überfordert. Es ist üblich, dass Mobilfunknetze während bestimmter Ereignisse mit hoher Kapazität, wie etwa Sportereignissen, überlastet werden. Zehntausende oder Hunderttausende von zusätzlichen Vorrichtungen versuchen möglicherweise, ein Netzwerk zu verwenden, was die Reaktionsfähigkeit des Netzwerks extrem belasten kann.
  • Während all diese Menschen dazu neigen, über einen längeren Zeitraum einzutreffen, neigen sie alle dazu, ungefähr zur gleichen Zeit zu gehen, wenn das Ereignis vorbei ist. Dies bedeutet, dass ein Netzwerk möglicherweise 100x oder 1000x so viele Datenanforderungen für Navigationsinformationen unterstützen muss, wie es gewohnt ist zu unterstützen. Eine Lösung besteht darin, die Fahrzeuge 701 einfach auf ihre eigenen internen Navigationscomputer zurückgreifen zu lassen, die eine Routenführung auch in Abwesenheit eines aktiven Mobilfunknetzes bereitstellen können, aber bestimmten Fahrzeugen 701 fehlen derartige Computer und viele andere Benutzer bevorzugen eine Routenführung, die auch die aktuellen Verkehrsbedingungen angibt, insbesondere wenn der Verkehr sehr stark sein wird, wie in dem vorstehenden Szenario. Wenn alle diese Anforderungen in etwa dem gleichen Zeitrahmen an das Netzwerk gesendet werden, insbesondere wenn die Anforderungen aus Gründen wie Verkehrsaktualisierungen noch nicht abgeschlossen sind, ist das Netzwerk häufig nicht in der Lage, auf den Großteil dieser Anforderungen zu reagieren, was zu noch weiteren Verlangsamungen des Fahrzeugverkehrs führt.
  • Durch die Verwendung der ATSC-Technologie ist es möglich, Fahrzeuge 701 strategisch aus einem Ort heraus zu leiten, Verkehrsberichte nahezu in Echtzeit bereitzustellen und sich an sich ändernde Verkehrsbedingungen anzupassen, während die Mobilfunknetze nur begrenzt belastet werden. In einigen Fällen stellen die veranschaulichenden Ausführungsformen eine sehr begrenzte oder möglicherweise keine Belastung für die Netzwerke dar (wenn sich Fahrzeuge 701 nicht zurückmelden), in anderen Fällen wird bei denjenigen mit einigen Rückmeldungsaspekten eine begrenzte Belastung auf die Netzwerke ausgeübt, aber weit weniger als die Belastung als wenn sich alle Benutzer für alle verkehrsbezogenen Entscheidungen auf zellulär übertragene Daten stützten.
  • Wenn zum Beispiel 50.000 Fahrzeuge 701 einen Ort in einer Infrastruktur verlassen, der normalerweise nicht so viel Fahrzeugverkehr befördert, ermöglichen die veranschaulichenden Ausführungsformen eine selektive Routenführung dieser Fahrzeuge 701 auf Grundlage von gegenwärtigen Standorten, optimalen Routen relativ zu gegenwärtigen Standorten und sogar eine Anpassung bestimmter alternativer Routen, die für einige Fahrzeuge 701 geeignet sind und für andere nicht (z. B. niedrige Brücken).
  • In diesen gleichen Situationen, selbst wenn eine einzelne Instanz die Verkehrssteuerung vereinheitlicht, könnte der Zugriff auf diese Instanz durch Mobilfunknetze extrem eingeschränkt sein. In den veranschaulichenden Ausführungsformen kann jedoch ein einheitliches Führungssystem, wie etwa ein Stadt- oder OEM-Server 721, Ausfahrtsrouten für Fahrzeuge 701 auf Grundlage dessen, wo sich diese Fahrzeuge 701 gegenwärtig befinden, entwickeln. Das heißt, anstatt dass allen Fahrzeugen 701 eine allgemeine bevorzugte Route oder primäre Routen zu bestimmten Verkehrsadern (z. B. Autobahnen) zugewiesen werden, kann der Server 721 Anweisungen unterteilen und die Anweisungen mit Geofencing liefern, sodass ein Fahrzeug 701 in einem gegebenen Geofence Anweisungen empfangen kann, die für dieses Fahrzeug 701 auf Grundlage des Standorts dieses Fahrzeugs relevant sind, selbst wenn der Server 721 nicht konkret weiß, dass sich das Fahrzeug 701 dort befindet.
  • Die Anweisungen können für einzelne Geofences oder als ein großer Satz von Kartendaten gesendet werden, wobei Fahrzeuge 701 Daten auf Grundlage ihrer eigenen bestimmten Standortdaten selektiv empfangen oder nutzen können. Die Lösung wird in Bezug auf eine formulierte koordinierte Karte beschrieben, wobei Fahrzeuge 701 Anweisungen von der Karte folgen, die für den aktuellen Koordinatensatz des Fahrzeugs relevant sind, obwohl es sich versteht, dass auch einzelne Blöcke von Anweisungen, die mit Koordinatensätzen korreliert sind, gesendet werden könnten, oder kleinere Blöcke von Kartendaten, die mit Koordinatensätzen korreliert sind, wobei ein gegebenes Fahrzeug 701 eine Nachricht auf Grundlage ihrer gegenwärtigen Koordinaten und/oder Eigenschaften annehmen, in eine Warteschlange stellen oder verwerfen würde.
  • Da die Übertragung der Daten nicht auf den Mobilfunknetzen beruht, sondern auf einem Broadcast-Medium, das eine beliebige Anzahl von Fahrzeugen 701 auf einmal erreichen kann, kann der Server 721 auch Kartendaten oder Anweisungen, so wie geeignet, aktualisieren und erneut senden, vorausgesetzt, sie befinden sich in einem Kommunikationsbereich eines Broadcasts. Wenn beispielsweise ein Unfall auftritt, kann der Server 721 Fahrzeuge 701 in bestimmten Geofences mit einer begrenzten oder vollständigen Kartenaktualisierung schnell umleiten, wodurch reaktive, koordinierte Verkehrsführung mit angemessenen Zusicherungen, dass die Führung alle erreichen wird, bereitgestellt wird und von allen oder den meisten Fahrzeugen 701, die einen ATSC-Empfänger beinhalten, verwendet werden kann.
  • Kartendaten können ferner Führung auf Grundlage eines Typs des Fahrzeugs 701 oder sogar auf Grundlage eines möglichen Ziels des Fahrzeugs 701 beinhalten. Zum Beispiel kann eine Hauptstraße außerhalb der Stadt zu zwei Autobahnen N und M führen. Wenn ein Fahrzeug 701 auf die Autobahn N fährt, kann es eine bessere Route geben, als wenn ein Fahrzeug 701 auf die Autobahn M fährt. Die Daten für die Ausfahrtstrategie (Teilmenge der Karte) würde von allen Fahrzeugen 701 im Geofence X angenommen werden, obwohl einige Fahrzeuge 701 zu M fahren und einige Fahrzeuge 701 nach zu fahren.
  • Eine Option besteht einfach darin, die Fahrzeuge 701 ihre eigene beste Route auf Grundlage der anwendbaren Kartendaten ableiten zu lassen (z. B. empfiehlt der Server 721 Straßen oder zu vermeidende Straßen, um M oder N zu erreichen). Ein potentielles Problem mit dieser Lösung wäre jedoch, dass, wenn jedes Fahrzeug 701 die gleiche Teilroute wähle, diese Teilroute suboptimal werden würde, da zum Beispiel der gesamte M-Verkehr zur Teilroute M_1 fahren würde. Eine Möglichkeit, beliebige Bedenken hinsichtlich dieser Frage anzugehen, wäre die Verwendung einiger der hierin zuvor dargelegten Randomisierungsvorschläge, wobei der Server 721 zum Beispiel 3 angemessene Alternativen berechnet und dann ein gegebenes Fahrzeug 701 an Bord randomisiert, um eine Route auszuwählen. Dies würde eine angemessene Erwartung, den Verkehr gleichmäßig zwischen den Alternativen aufzuteilen, aufweisen und wenn zum Beispiel eine Straße die doppelte Kapazität von zwei anderen aufweist, könnte ½ die Randomisierung dieser Straße zugewiesen werden und ¼ jeder der anderen zwei Straßen, um die Unterschiede in der Kapazität auszugleichen.
  • Es kann auch sinnvoll sein, einige Fahrzeuge 701 zu verzögern, sodass nicht alle Fahrzeuge 701 zur gleichen Zeit an M oder N ankommen, sodass einige der alternativen Routen dazu ausgestaltet sein können, die Ankunft der Fahrzeuge 701 darauf zu verzögern, was jedoch die abschließende Wirkung haben könnte, den gesamten Verkehr in Bewegung zu halten.
  • Aufgrund von Lösungen wie dieser können Fahrer entscheiden, einem empfohlenen Weg nicht zu folgen (in dem Wissen, dass sie sich auf dem „langsameren“ Weg befinden). Wenn Fahrzeuge 701 von einem geplanten Weg abweichen, kann eine Meldung an den Server 721 erfolgen, um es dem Server 721 zu ermöglichen, die Modellierung anzupassen und neue Lösungen bereitzustellen, um den Verkehr so reibungslos wie möglich zu halten.
  • Somit könnten, obwohl sich alle Fahrzeuge 701 in der Region X anfänglich auf der gleichen Straße befinden, die zu M und N führt, diese Fahrzeuge 701 auf Grundlage dessen, welche Autobahn benötigt war, und auf Grundlage einer angemessenen Zuordnung zwischen Routenalternativen Richtungen, die in den Teilrouten M_1, M_2, M_3, N_1 und N_2 resultiert haben, empfangen und verarbeiten. Straßenindikatoren, die die Nützlichkeit (oder in einigen Fällen Unmöglichkeit) einer gegebenen Straße bereitstellen, könnten ebenfalls enthalten sein, was dazu beitragen kann, zu vermeiden, dass Fahrer Straßen befahren, die zu einer erheblichen Verkehrszunahme und/oder einer unpassierbaren Situation führen. Und, wenn sich der Verkehr verlagert und die Fahrzeuge 701 zurückfahren oder einen Bereich räumen, können eine vollständige oder teilweise Umleitung und neue Empfehlungen durch den Server 721 erzeugt und an die Fahrzeuge 701 geliefert werden, ohne sich Gedanken darüber zu machen, ob die Mobilfunknetze als Hindernis für die Bereitstellung der Führung überlastet sind.
  • Außerdem sind in vielen Städten bestimmte Straßen einfach vorübergehend gesperrt und Navigationsdaten geben dies möglicherweise nicht an. Um zu vermeiden, dass viele Fahrzeuge 701 eine scheinbar intelligente Route wählen, nur um auf eine geschlossene und unpassierbare Straße zu treffen, dann zurückfahren und erneut zum allgemeinen Verkehrsfluss hinzugefügt werden zu müssen, kann die Karte derartige Schließungen beinhalten, sodass Navigationssysteme diese berücksichtigen können.
  • 14 zeigt einen veranschaulichenden Prozess zur selektiven Verkehrsroutenführung, ausführbar zum Beispiel durch einen Server 721. In diesem Beispiel plant der Server 721 Ausfahrtsstrategien für eine Vielzahl von Ausfahrtswegen, die eine Stadt verlassen, auf Grundlage des Fahrzeugtyps 701, des Fahrzeugstandorts, des erwarteten Verkehrs, des gegenwärtigen Verkehrs, eventueller Ziele usw. Eventuelle Ziele müssen nicht das tatsächliche Ziel eines Fahrzeugs sein, sondern zum Beispiel eine Hauptausfahrtsader, an der das Fahrzeug 701 bevorzugt ankommen möchte. Vorausgesetzt, dass ein letztendliches Ziel außerhalb der Stadt liegt, wird praktisch jeder Weg aus der Stadt eine derartige Ader beinhalten, auch wenn es insgesamt ein paar Dutzend solcher Adern gibt.
  • Der Server 721 kann bevorzugte Abflussvolumina zum Beispiel bei 1401 auf Grundlage der Kapazität von Straßen und einer Erwartung oder Kenntnis davon, wo sich Fahrzeuge 701 im Allgemeinen derzeit befinden, bestimmen. Auf Grundlage von geeigneten Routen für Verkehr nach außerhalb der Stadt kann der Server 721 die Routen bei 1403 dann auf eine Weise teilen, die erwartete Verkehrsströme angemessen berücksichtigt.
  • Dies kann zum Beispiel das Zuweisen von geografischen und/oder zufälligen Parametern zu jeder Route bei 1405 beinhalten (z. B. Parameter, die vorgeben, welche Fahrzeuge 701 welche Route verwenden sollten, auf Grundlage dessen, wo sich diese Fahrzeuge 701 derzeit befinden). Der Server 721 kann dann die Kartendaten an einen ATSC-Sender 715 senden und bei 1407 den Broadcast der Kartendaten anweisen.
  • 15 zeigt einen veranschaulichenden Prozess zum Bearbeiten von selektiver Verkehrsroutenführung, ausführbar zum Beispiel durch ein gegebenes Fahrzeug 701. In diesem Beispiel empfängt das Fahrzeug 701 den ATSC-Broadcast, während es sich in einem ATSC-Broadcast-Abdeckungsbereich befindet. Die Kartendaten können von allen Fahrzeugen 701 empfangen und verarbeitet werden oder es kann zum Beispiel für die Verarbeitung der Kartendaten davon ausgegangen werden, dass sich das Fahrzeug 701 innerhalb einer geografischen Grenze befindet, die durch den Broadcast festgelegt ist (z. B. eine Grenze, die den gesamten Ort überspannt, für den Ausfahrtswege werden bestimmt). Wenn der Verarbeitungsparameter bei 1503 übereinstimmt, verarbeitet das Fahrzeug 701 die Kartendaten, was ein vorübergehendes Integrieren der Kartendaten in den fahrzeugeigenen Navigationssatz beinhalten kann.
  • Wenn es keine Übereinstimmung gibt, kann das Fahrzeug 701 die Daten bei 1513 verwerfen oder, wenn die Fahrzeugroute zum Beispiel Koordinaten beinhaltet, die das Fahrzeug 701 innerhalb der Parameterkoordinaten befördern werden (wodurch die Daten anwendbar werden), kann das Fahrzeug 701 die Daten dahingehend speichern, ob und wann dies auftritt.
  • Wenn die Daten für das Fahrzeug 701 gelten (z. B. das Fahrzeug 701 befindet sich in diesem Beispiel innerhalb der Parametergrenzen zum Verarbeiten der Daten), kann das Fahrzeug 701 bei 1504 auf einen lokalen Datensatz innerhalb der Kartendaten zugreifen. Das heißt, wenn die Kartendaten in Geofencing-Standorte innerhalb des Orts unterteilt sind, kann sich das Fahrzeug 701 innerhalb eines dieser Geofencing-Standorte befinden. Wenn sich das Fahrzeug 701 innerhalb des Orts, aber nicht an einem beliebigen Geofence-Standort innerhalb des Orts befindet, für den ein Ausfahrtsweg definiert ist (z. B. das Fahrzeug 701 ist nur ein lokaler Anwohner, der lokale Geschäfte tätigt), kann sich das Fahrzeug 701 dazu entscheiden, vorherige On-Board-Navigationsdaten zu verwenden.
  • Eine andere Möglichkeit, zwischen Anwohnern und ausfahrendem Verkehr zu unterscheiden, besteht darin, eine oder mehrere Hauptausfahrtsdurchgangsstraßen Ausfahrtswegen zuzuordnen, die der Server 721 innerhalb eines gegebenen Geofence-Standortes innerhalb des Orts plant. Dies wären typischerweise Zwischenziele für ein Fahrzeug 701, das die Stadt verlässt (z. B. eine Autobahn auf dem Weg zu einem Zuhause), aber der größte Verkehr, der die Stadt tatsächlich verlässt, würde wahrscheinlich eine dieser Durchgangsstraßen nutzen. Somit wird, wenn ein gegebenes Fahrzeug 701, das die Daten empfängt, einen eingestellten Navigationsweg aufweist, der eine dieser Durchgangsstraßen beinhaltet, das Fahrzeug 701 als aus der Stadt ausfahrend betrachtet und kann wissen, dass es die Daten auf Grundlage der Zuordnung des Zwischenstreckenziels zu dem Ausfahrtsweg verwendet. Wenn einem Fahrzeug 701 ein derartiges Zwischenziel fehlt (oder kein festgelegter Weg vorliegt), kann das Fahrzeug 701 als mit lokaler Fahrt befasst angesehen werden und kann sich auf Informationsdaten, wie etwa Straßensperrungen, verlassen, die in den Kartendaten enthalten sind, kann jedoch Ausfahrtswegstrategien meiden, um einfach dorthin zu gelangen, wo der lokale Fahrer innerhalb des Orts fährt.
  • Andere Fahrzeuge 701 können kein festgelegtes Ziel aufweisen, können jedoch zum Beispiel einen „Zuhause-Standort“ aufweisen, der sich außerhalb des Orts befindet. Um die Anwendbarkeit der Ausfahrtswegstrategien auf diese Fahrzeuge 701 zu bestimmen, können die Fahrzeuge 701, die keinen Ausfahrtsweg, aber einen Zuhause-Standort außerhalb der Stadt aufweisen, den Zuhause-Standort zum Zwecke der Bestimmung der Anwendbarkeit von Ausfahrtswegstrategien und zur Auswahl eines bestimmten Zwischenziels (beabsichtigte Hauptdurchgangsstraße) als ein gegenwärtiges Ziel behandeln.
  • Sobald ein Fahrzeug 701 die Anwendbarkeit eines gegebenen Ausfahrtswegs oder Ausfahrtswegsatzes, der den gegenwärtigen Koordinaten des Fahrzeugs innerhalb des Orts entspricht, bestimmt hat, kann das Fahrzeug 701 bei 1505 eine gegenwärtige Route gemäß von dem Server empfohlenen Ausfahrtswegen, die mit diesem Ort korreliert sind, einstellen. Dies kann zum Beispiel einen einzelnen empfohlenen Weg, mehrere Wege zu mehreren unterschiedlichen Zwischenzielen oder sogar eine Vielzahl von Wegen zu einem einzelnen Zwischenziel beinhalten. In dem letzteren Fall kann das Fahrzeug 701 zufällig oder halb zufällig (oder gemäß einer anderen vernünftigen Strategie) zwischen der Vielzahl von Wegen wählen, die alle an demselben Zwischenstandort (Hauptdurchgangsstraße) enden.
  • Das Fahrzeug 701 gibt in einigen Fällen auch bei 1507 einen Bericht an den Server 721 aus. Dies kann in Abhängigkeit von dem Niveau des Mobilfunkverkehrs möglich sein oder nicht, aber das Fahrzeug 701 könnte auch mit einer einfachen Textnachricht oder einem anderen grundlegenden Datenelement, das einen beabsichtigten Weg angibt, der den Server 721 auf dem Laufenden halten könnte, ohne das Netzwerk mit Daten zu überlasten, berichten. Zum Beispiel kann jedem Ausfahrtsweg einfach eine Nummer zugewiesen sein und das Fahrzeug 701 könnte die Nummer des ausgewählten Wegs melden, sodass eine einfache Textnachricht mit wenigen Zeichen dazu dienen kann, die Absicht des Fahrzeugs zu melden und es dem Server 721 zu ermöglichen, die Ausfahrtswegstrategie auf Grundlage davon, wie viele Fahrzeuge die beabsichtigte Verwendung eines gegebenen Wegs gemeldet haben, einzustellen. Andere Rückmeldungen könnten von Kameravideos von Kameras, die an der Fahrbahnseite installiert sind, oder von Hubschrauberüberwachung stammen.
  • Wenn der Server 721 eine Rückmeldung erhalten kann, kann er schnell bestimmen, ob ein gegebener Weg überfordert ist oder sein wird, und kann sofortige Schritte unternehmen und erneut einen Broadcast senden, um eine Situation zu mildern, bevor sie sich vollständig entwickelt hat. Wenn zum Beispiel 100 Fahrzeuge 701 beabsichtigen, einen Weg zu verwenden, den der Server 721 nur für 50 Fahrzeuge vorgesehen hat, könnte der Server 721 einen oder mehrere Geofences um Teilmengen von Straßen, die zu diesem Weg führen, neu zeichnen (und somit vermutlich eine Teilmenge dieser Fahrzeuge umfassen) und unterschiedliche Ausfahrtswege über ATSC-Broadcast empfehlen. Aktualisierte und adaptive Empfehlungen können somit massenhaft und nach Bedarf bereitgestellt werden, ohne sich auf die Bereitstellung durch das Mobilfunknetz zu verlassen.
  • Während das Fahrzeug 701 entlang eines Wegs fährt, kann der Fahrer aus welchem Grund auch immer wählen, von dem Weg abzuweichen. Wenn das Fahrzeug 701 auf dem Weg bleibt, ist möglicherweise nichts zu melden, um den Mobilfunkverkehr gering zu halten und da der Server 721 bereits weiß, welcher Weg für dieses Fahrzeug 701 ausgewählt wurde. Wenn der Fahrer jedoch bei 1509 von dem Weg abweicht, kann das Fahrzeug 701 die Abweichung bei 1511 melden, sodass der Server 721 dies berücksichtigen kann, insbesondere wenn es zu einer Massenabweichung von einem Weg kommt, was ebenfalls dazu neigen kann, darauf hinzuweisen, dass der Weg schlecht ist oder überfüllt ist.
  • 16 zeigt einen veranschaulichenden Prozess zum Einstelen eines adaptiven Modells zur selektiven Verkehrsroutenführung. Dies ist ein Beispiel dafür, wie der Server 721 als Reaktion darauf, dass Fahrzeuge 701 verschiedene Änderungen der Position, die Wegenutzung, Abweichungen usw. melden, den Ausfahrtsweg für Geofence-Standorte innerhalb eines Ortes einstellt.
  • Da der Server 721 möglicherweise nicht genau weiß, wie viele Fahrzeuge 701 sich an einem bestimmten Geofence-Standort befinden, wenn anfängliche Daten und Ausfahrtswege gesendet werden, oder wie viele Fahrzeuge 701 sich dafür entscheiden, einen gegebenen Weg zu verwenden, kann es nützlich sein, wenn sich der Server 721 anpassen kann, um beliebige erwartete Verkehrsüberläufe zu melden und auszugleichen. Dementsprechend kann der Server 721, wenn Fahrzeuge 701 Standorte oder eine Wegeauswahl melden, die Ausfahrtswegmodellierung einstellen, was ein Bereitstellen zusätzlicher Ausfahrtswege für einen Geofence-Standort oder ein Umfunktionieren von ungenutzten Ausfahrtswegen für einen Standort zu einem anderen Standort (z. B. einem benachbarten Standort) oder ein einfaches Neuzeichnen von Geofence-Grenzen nach Bedarf aus Gründen, wie in dieser Schrift erwähnt und dergleichen, beinhalten kann. Die Modellaeinstellung kann die Bezeichnung des Fahrzeugs 701 für ausgewählte Ausfahrtswege oder Vorhersagen, ob die Fahrzeuge 701 einfach aktuelle Standorte melden, beinhalten, und wenn ein offensichtlicher Überlaufzustand auftritt oder bei 1605 auftreten wird, kann der Server 721 den Überlauf bei 1607 durch Aufteilen der Ausfahrtswege auf eine gewisse Weise, die eine alternative Ausfahrtswegführung für mindestens eine Teilmenge der Fahrzeuge 701 vorschlägt, die voraussichtlich zu einem Überlauf führen, einstellen.
  • Der Server könnte zum Beispiel sogar erkennen, dass für eine gegebene Kreuzung prognostiziert wurde, dass sie eine Absicherung für 30 Fahrzeuge in einer einzigen Richtung aufweist, wenn die anfängliche Strategie darin bestand, diese Absicherung auf nicht mehr als 20 Fahrzeuge zu reduzieren. Die selektive neue Wegeführung kann eine Grenze neu zeichnen, sodass die letzten 10 Fahrzeuge 701 in der Schlange (falls und wenn sich die Schlange bildet, basierend darauf, wo sich diese Fahrzeuge 701 voraussichtlich befinden werden) angewiesen werden, einen neuen oder anderen Ausfahrtsweg zu nehmen, der für diese Fahrzeuge 701 verhindert, an der Kreuzung warten zu müssen. Die ersten 20 Fahrzeuge 701 passen in die ursprüngliche Strategie, aber die anderen 10 Fahrzeuge 701 (geben oder nehmen) können sofort einen neuen Ausfahrtsweg wählen, der verhindert, dass die Absicherung für 30 Fahrzeuge auftritt oder andauert. Während die ersten 20 Fahrzeuge 701 warten, werden sogar neue Fahrzeuge 701, die in die Grenze für die letzten 10 Fahrzeuge 701 einfahren, in die neue Wegeführung aufgenommen, sodass dies effektiv dazu beitragen sollte, die Absicherung kontinuierlich zu verhindern, bis und wenn die alternativen Wege ebenfalls überlastet sind. Die relevanten Parameter zur Verwendung der neuen Wege werden dann bei 1405 festgelegt (z. B. wenn sich das Fahrzeug 701 an einer Position befindet, an der eine erwartete Absicherung für 20 Autos vor diesem Fahrzeug 701 an einer Ampel liegt) und der Server 721 kann die Lieferung der aktualisierten Kartendaten über ATSC bei 1407 anweisen.
  • 17 zeigt einen veranschaulichenden Prozess zum Bearbeiten von Kartendaten aus einem Broadcast mit selektiver Routenführung. Erneut verwendet dieses Beispiel das Konzept einer Gesamtkarte, die festgelegte Ausfahrtswege für gegebene Geofencing-Standorte innerhalb des Ortes der Karte oder einen Ort innerhalb der Karte beinhaltet, aber ein ähnliches Konzept könnte sich auf eine Reihe von Anweisungen erstrecken, die jeweils korrelierte Annahmeparameter für einen gegebenen Geofence-Bereich, in dem sich ein empfangendes Fahrzeug 701 gegenwärtig befindet, aufweisen.
  • In diesem Beispiel empfängt das Fahrzeug 701 bei 1701 die Gesamtkarte und bestimmt bei 1703 einen Satz von für das Fahrzeug anwendbaren Parametern, wie zum Beispiel den gegenwärtigen Standort, Eigenschaften des Fahrzeugs 701 (Höhe, Breite usw.), Zwischenziel (Hauptdurchgangsstraße) usw. Unter Verwendung der Kartendaten und der Ausfahrtswege, die Fahrzeugen 701 zugewiesen sind, die die Eigenschaften und den Standort des Objektfahrzeugs 701 aufweisen, kann das Fahrzeug 701 einen oder mehrere empfohlene Ausfahrtswege auf Grundlage des gegenwärtigen Standorts des Fahrzeugs und des beabsichtigten Zwischenziels bei 1705 zeigen.
  • In diesem Beispiel wird, solange das Fahrzeug 701 einem der empfohlenen Wege folgt, keine Meldung verwendet, obwohl in jedem Fall eine anfängliche Meldung über einen beabsichtigten oder vorhandenen Ausfahrtsweg gesendet werden kann. Wenn das Fahrzeug 701 bei 1707 von einem empfohlenen Ausfahrtsweg abweicht, kann das Fahrzeug 701 den gegenwärtigen Standort des Fahrzeugs 701 und/oder einen beliebigen beabsichtigten neuen Ausfahrtsweg bei 1709 melden, wenn ein Ausfahrtsweg verwendet wird. Die Wahl einer Abweichung durch den Fahrer kann auch dazu führen, dass bei 1711 ein neuer Parameter anwendbar ist, der zum Beispiel ein Eintreten in eine neue Geofencing-Grenze mit unterschiedlichen Ausfahrtswegen beinhalten kann. Wenn kein neuer Parameter anwendbar ist, kann das Fahrzeug 701 bei 1713 zur Verwendung von Standardnavigation zurückkehren, die immer noch Straßensperrungen oder andere Daten berücksichtigen kann, die durch die Kartendaten angegeben werden, die sich jedoch nicht auf einen bestimmten serverdefinierten Ausfahrtsweg stützen können.
  • In diesem Beispiel kann das Fahrzeug 701, wenn das Navigationssystem das Fahrzeug 701 zu einem beliebigen Zeitpunkt in eine Situation bringt, in der ein neuer Parameter gilt, und/oder innerhalb eines anwendbaren Parameters vorheriger Daten bei 1715 zurück bringt, eine aktualisierte empfohlene Wegführung auf Grundlage des Parameters zeigen.
  • Zum Beispiel kann sich ein Benutzer im Geofence X anfänglich dafür entscheiden, den Ausfahrtsweg M_1 zu verwenden. Dies kann gemeldet werden und das Fahrzeug 701 kann die Fahrt auf dem Ausfahrtsweg M_1 beginnen. Dann kann der Benutzer entscheiden, einen Umweg zu einem Lebensmittelgeschäft zu machen, das sich nicht auf einem beliebigen Ausfahrtsweg befindet, aber innerhalb von X existiert. Der Benutzer verlässt M_1 und das Fahrzeug 701 meldet die Ausfahrt. Da sich der Benutzer immer noch innerhalb von X befindet, kann der Weg für X immer noch gezeigt werden, aber das Fahrzeug 701 verwendet die Navigation an Bord, um zum Lebensmittelgeschäft zu navigieren, was keiner vom Server festgelegten Strategie entspricht.
  • Wenn sich das Lebensmittelgeschäft innerhalb des Geofence Y, benachbart zu X, befindet, können, wenn das Fahrzeug 701 in die Region Y gefahren ist, die Ausfahrtswegempfehlungen aktualisiert werden (wobei empfohlene Routen außerhalb der Stadt gezeigt werden), aber das Fahrzeug 701 würde immer noch mithilfe von On-Bord-Navigationsdaten zu dem Lebensmittelgeschäft fahren. Wenn der Benutzer die Fahrt zu dem Geschäft abgeschlossen hat, kann der Benutzer dann einen empfohlenen Ausfahrtsweg R_1 erneut betreten, der der Region Y entspricht, in der sich das Fahrzeug 701 nun befindet, und diese Daten könnten gemeldet werden und das Fahrzeug 701 könnte damit beginnen, sich auf die Ausfahrtstrategien für Y und R_1 auf Grundlage dessen, wo sich das Fahrzeug 701 nun befindet, und auf Grundlage des Wegs, den das Fahrzeug 701 nun fährt, zu stützen. All dies kann durch die veranschaulichenden Ausführungsformen mit wenig bis keiner Kommunikation zwischen dem Server 721 und dem Fahrzeug 701 berücksichtigt werden und somit ist die Belastung des Mobilfunknetzes sehr gering, obwohl das Fahrzeug 701 (aus Sicht des Fahrers) höhst relevante und spezifische Informationen, die für seinen gegenwärtigen Standort und offensichtlichen Absichten relevant sind, empfängt.
  • 18A und 18B zeigen veranschaulichende Prozesse zum Bearbeiten selektiver Warnungen. Dies ist ein Konzept, das ermöglicht, dass Fahrzeugwarnungen an alle Fahrzeuge 701 innerhalb einer Broadcast-Region per Broadcast gesendet werden, aber nur Fahrzeuge 701, für die eine Warnung gilt, müssen die Nachrichten verarbeiten. Ein grundlegendes Beispiel dafür könnte eine Rückrufbenachrichtigung beinhalten, wobei der Server 721 die Benachrichtigung bei 1801 empfangen würde und bestimmen würde, dass Fahrzeuge 701, die bestimmte Eigenschaften (Marke, Modell) oder bestimmte Teile (XYZ-Bremssysteme) aufweisen, benötigt werden, um die Nachricht anzunehmen, und so könnte dieser Parameter (die Eigenschaft) bei 1803 als der Annahme- und Verarbeitungsparameter für die Nachricht festgelegt werden. Der Server 721 könnte dann den ATSC-Sender/Empfänger anweisen, die Nachricht per Broadcast zu senden.
  • Ein Fahrzeug 701 kann dann bei 1811 den Broadcast empfangen und bei 1813 bestimmen, ob das Fahrzeug 701 die notwendige Eigenschaft (z. B. Marke, Modell, XYZ-Bremssystem usw.) zum Verarbeiten der Nachricht beinhaltet hat. Wenn es keine Übereinstimmung gab, kann das Fahrzeug 701 die Nachricht bei 1815 verwerfen. Sofern der Parameter keine Bedingung war, die schließlich erfüllt werden könnte (z. B. aktuelle Motortemperatur plus Marke und Modell, wobei das Fahrzeug 701 Marke und Modell erfüllt, aber nicht die aktuelle Motortemperatur), kann es wenig Grund geben, die Nachricht in eine Warteschlange einzureihen.
  • Außerdem wird in diesem Beispiel in Betracht gezogen, dass ein gegebener Insasse (z. B. ein Besitzer) eine Bedingung für die Zustellung der Nachricht sein kann, sodass zum Beispiel alle Fahrzeuge 701 mit der Eigenschaft die Nachricht handhaben können, aber dann können diese Fahrzeuge 701 bei 1817 ferner bestimmen, ob ein Besitzer oder ein anderer bezeichneter Empfänger (typischerweise gekennzeichnet durch eine Eigenschaft, die das Fahrzeug 701 bestimmen kann, z. B. nicht „Bob Smith“, sondern eher „vordefinierter primärer Benutzer“) in dem Fahrzeug 701 vorhanden ist, wenn die Nachricht empfangen wird. Die Anwesenheit eines Benutzers kann auf Grundlage einer gegenwärtig gekoppelten oder vorliegenden Vorrichtung, die einem Besitzer oder primären Benutzer entspricht, durch die Verwendung einer Kamera oder einer anderen biometrischen Vorrichtung oder einer anderen Anzahl ähnlicher Verfahren bestimmt werden.
  • Wenn der Benutzer anwesend ist, kann das Fahrzeug 701 die Nachricht bei 1819 auf einer fahrzeuginternen Anzeige anzeigen. Wenn der Benutzer nicht anwesend ist, kann das Fahrzeug 701 bei 1821 versuchen, die Nachricht an eine bekannte Benutzervorrichtung (z. B. Telefon) weiterzuleiten. Dies kann auch dazu führen, dass die Nachricht bei 1823 in dem Fahrzeug 701 in eine Warteschlange eingereiht wird. Wenn eine Nachricht in die Warteschlange eingereiht wird, kann dann, falls und wenn ein Benutzer später bei 1825 vorhanden ist, und unter der Annahme, dass die Nachricht bei 1827 nicht abgelaufen ist, die Nachricht im Fahrzeug zugestellt werden. Einige Nachrichten können nur zeitlich relevant sein und können daher eine damit verbundene Zeitüberschreitung aufweisen, sodass eine spätere Zustellung einer nun irrelevanten Nachricht einen Benutzer nicht verwirrt.
  • 19 zeigt einen veranschaulichenden Prozess zum Aktualisieren von periodischen Ladedaten. Dies ist ein weiteres Beispiel für die Verwendung der ATSC-Technologie, um Echtzeitaktualisierungen der Ladeverfügbarkeit von Elektrofahrzeugen (EV) bereitzustellen. Es gibt relativ zu der Anzahl von Stellen, an denen benzinbetriebene Fahrzeuge 701 betankt werden können, eine begrenzte Anzahl von Orten auf der Welt, an denen EV aufgeladen werden können. Außerdem benötigen EV im Gegensatz zu Benzinfahrzeugen erheblich länger zum Betanken. Die Kombination dieser Faktoren kann es wünschenswert machen, die Verfügbarkeit des EV-Ladens, die jederzeit begrenzt sein kann, sowie alle Wartezeiten, die mit dem Laden verbunden sind und die in Bezug auf andere Betankungszeiten erheblich sein können, zu kennen.
  • Eine Möglichkeit besteht darin, dass Fahrzeuge 701 Aktualisierungen zum Laden von Elektrofahrzeugen über eine direkte Verbindung anfordern. Dies ist eine periodische Lösung für Echtzeitaktualisierungen und erfordert ferner insgesamt eine große Bandbreite. Selbst wenn diese Informationen einzeln an Fahrzeuge übertragen würden, wäre die Menge an Bandbreite, die durch derartige Informationen weltweit verbraucht wird, andauernd und massiv. Darüber hinaus würden die Fahrzeuge 701 entweder zu viele Informationen benötigen oder müssten ihre Standorte melden, damit nützliche Informationen empfangen werden können, und jede Lösung verbraucht zusätzliche Bandbreite und verursacht zusätzliche Kosten.
  • Unter Verwendung von ATSC kann die Verfügbarkeit von lokalem EV-Laden an alle Fahrzeuge 701 in Echtzeit bei begrenzten Kosten unter Verwendung von keiner Mobilfunkbandbreite per Broadcast übertragen werden. Da nur Fahrzeuge 701 innerhalb des Broadcast-Bereichs die Informationen empfangen, besteht keine Notwendigkeit, dass die Fahrzeuge 701 Koordinaten melden. Da die gesamte Verfügbarkeit relevanten geografischen Parametern zugeordnet werden kann, kann ein gegebenes Fahrzeug 701 zudem die meisten Informationen ignorieren, die nicht geografisch relevant sind. Somit kann ein einzelner Broadcast aller verfügbaren EV-Stationen für einen gegebenen Broadcast-Bereich dargestellt werden, was die gegenwärtige Verfügbarkeit darstellt, und die Fahrzeuge 701 können entscheiden, welche Informationen relevant sind und welche Informationen ignoriert werden sollten.
  • Ferner können diese Informationen aktualisiert werden, wenn Plätze frei werden und/oder reserviert werden, und somit kann ein angemessener nahezu kontinuierlicher Bestand an lokal verfügbarem Laden bei Bedarf mit geringem finanziellen und Bandbreitenaufwand bereitgestellt werden. Dies kann zusätzlich die Belastung für Mobilfunknetze reduzieren und die Fahrzeuge 701 müssen während der Fahrt nicht kontinuierlich nach Stationsinformationen suchen und diese anfordern, es sei denn, sie befinden sich außerhalb der Bereichs von beliebigen ATSC-Übertragungen und benötigen Aufladeinformationen.
  • Auf der Broadcast-Seite der Dinge zeigt 19 mehrere veranschaulichende Prozesse, die dazu verwendet werden können, Aktualisierungen der EV-Verfügbarkeit bereitzustellen. Ein Server 721 kann beide Prozesse ausführen, wobei ein Pfad ein Anforderungspfad ist und ein Pfad ein Push-Pfad ist. In diesem Beispiel kann der Server 721 in jedem bestimmten Zeitintervall bei 1901 bei 1903 aktualisierte Lade-/Reservierungsinformationen anfordern. Reservierungsinformationen können als Verwendungsinformationen gezählt werden, da die Reservierung sowohl einen Haltezeitraum als auch einen Verwendungszeitraum darstellen kann. Reservierungen, die nicht erfüllt werden, werden auf dem anderen Pfad adressiert, aber wenn in diesem Beispiel Informationen angefordert werden, behandelt der Server 721 reservierte Buchten als verwendete Buchten.
  • Sobald der Server 721 bei 1905 Aktualisierungen von den verschiedenen EV-Stationen innerhalb einer Broadcast-Region eines gegebenen ATSC-Senders 715 empfängt, kann der Server 721 bei 1907 Parameter einstellen, wie nachstehend erörtert. Ein einzelner Server 721 kann den Empfang von Daten aus einer Vielzahl von ATSC-Broadcast-Regionen handhaben, sodass der Server 721 zum Beispiel staatliche oder sogar landesweite Daten empfangen könnte und die Daten bei 1906 basierend darauf sortieren könnte, welche Meldestandorte welchen ATSC-Broadcast-Regionen entsprechen. Da der Server 721 diese Informationen in den meisten, wenn nicht allen Fällen über drahtgebundene Netzwerkverbindungen erhalten kann, gibt es weniger Kosten- und Bandbreiteneinschränkungen als bei Fahrzeugen 701, die diese Informationen anfordern. Und da der Server 721 diese Informationen über ATSC übermitteln kann, kann das Mobilfunknetz weitgehend unbelastet bleiben.
  • In dem Push-Modell kann der Server 721 bei 1911 Informationen über eine Zustandsänderung an einer gegebenen Station empfangen. Dies kann einem abgeschlossenen Laden, einem nahezu abgeschlossenen Laden, einem Abschluss der Reservierung, einem Abschluss der Reservierung oder einer Stornierung einer Reservierung entsprechen. Welche Daten durch den Server 721 empfangen werden, kann davon abhängen, wie detailliert der Server 721 die Verfügbarkeitsinformationen verfolgt.
  • Als Reaktion auf das Empfangen einer Benachrichtigung von einer Station bei 1911 kann der Server 721 bei 1913 seine eigenen internen Daten einstellen, was bewirken kann, dass eine neue ATSC-Benachrichtigung gesendet wird, oder was eine bevorstehende ATSC-Benachrichtigung modifizieren kann. Zum Beispiel kann der Server 721 Aktualisierungen alle 5 Minuten, 10 Minuten usw. senden. Wenn der Server 721 bis zur Benachrichtigung nicht ständig Live-Daten sammelt, dann könnten bestimmte Zustandsänderungen ab dem Zeitpunkt, zu dem Daten gesammelt wurden, relativ zu dem Zeitpunkt, zu dem die Benachrichtigung gesendet wurde, auftreten. Indem Stationen wie vorstehend beschrieben Zustandsänderungen melden, kann die Genauigkeit der gemeldeten Informationen in einigen Fällen in Abhängigkeit von Datensammlungs- und Berichtsstrategien verbessert werden.
  • Sobald geeignete Daten gesammelt wurden und wenn der Server 721 einen Bericht senden wird, kann der Server 721 Annahme- oder Anwendbarkeitsparameter für den Bericht und/oder Teilmengen von Daten in dem Bericht einstellen. Zum Beispiel können Annahmeparameter relative Geofences innerhalb der Daten um die verschiedenen Ladestationen definieren und ein Fahrzeug 701 kann die Daten nur dann annahmen, wenn es sich innerhalb eines Bereichs einer dieser Stationen befindet.
  • In anderen Fällen können die Fahrzeuge 701 vom Besitzer definierte Annahmeparameter aufweisen, wobei sie wissen, dass es sich bei den Daten lediglich um Ladedaten handelt, und die Fahrzeuge 701 können die Daten nur dann annehmen und verarbeiten, wenn sich das Fahrzeug 701 zum Beispiel innerhalb einer Entfernung X von einer Station befindet oder sich bei einer Ladung von Y % befindet. In anderen Fällen können alle EV benachrichtigt werden, wenn eine Ladestation innerhalb eines bestimmten Bereichs verfügbar ist, falls ein Besitzer eine Ladung erhöhen möchte, selbst wenn das Laden nicht sofort erforderlich ist, da der Besitzer zumindest weiß, dass eine Bucht zu diesem unmittelbaren Zeitpunkt und in der Nähe eines Fahrzeugs 701 wahrscheinlich zur Verwendung verfügbar ist.
  • Sobald beliebige relevante Parameter eingestellt wurden, kann der Server 721 einen gegebenen ATSC-Sender 715 oder eine Station, die den Sender 715 steuert, anweisen, die Aktualisierung bei 1909 zu senden.
  • 20 zeigt einen veranschaulichenden Prozess zum Bearbeiten von Ladewarnungen. Ein Fahrzeug 701 kann den ATSC-Broadcast bei 2001 empfangen und dann wählen, ob die Daten relevant sind oder nicht. Fahrzeuge 701, denen die EV-Fähigkeit fehlt, können die Nachricht dennoch empfangen und die Nachricht verwerfen, da diese Fahrzeuge 701 die Informationen nicht benötigen. Andere Fahrzeuge 701 in dem Broadcast-Bereich können zu weit von einer Station entfernt sein oder müssen nicht aufgeladen werden und können daher die Nachricht bei 2005 ebenfalls verwerfen. Die Nachricht kann in eine Warteschlange eingereiht werden, aber da diese Informationen Echtzeitdaten darstellen und sich ständig ändern, ist das Einreihen in die Warteschlange für einen signifikanten Zeitraum möglicherweise nicht zu nützlich. Nichtsdestotrotz ist eine Warteschlange unter bestimmten Umständen oder bei Bedarf möglich (z. B. wenn ein Fahrzeug 701 im Begriff ist, einen Ladeschwellenwert zu überschreiten oder wenn sich ein Fahrzeug 701 einem anwendbaren Bereich nähert, aber noch nicht in dem Bereich ist).
  • Wenn es bei 2003 eine Übereinstimmung von Parametern gibt, die angibt, dass das Fahrzeug 701 eine Handlung durchführen sollte, kann das Fahrzeug 701 bei 2007 eine Empfehlung oder Informationen über lokale verfügbare Ladestationen darlegen. Welche Daten durch das Fahrzeug 701 in Betracht gezogen und dargelegt werden, kann auch eine Funktion des Ladezustands sein; beispielsweise können Fahrzeuge 701, die lediglich Erhöhungskandidaten sind, zum Beispiel über 50 Prozent Ladung, nur sehr nahe Stationen sehen, aber Fahrzeugen 701, die unter 10 Prozent liegen, können zum Beispiel Daten für eine weitere Region angezeigt werden, da diese Fahrzeuge 701 kritischer geladen werden müssen.
  • Außerdem kann in diesem Beispiel ein Fahrzeug 701 eine Ladestation bei 2009 reservieren. Dies kann ein Senden einer Nachricht an die Ladestation, die eine Reservierung anfordert, beinhalten. Wenn das Fahrzeug 701 bei 2009 keine Stationsbucht reservieren möchte, kann das Fahrzeug 701 den aktuellen Datensatz verwerfen und auf eine Aktualisierung aus dem nächsten Bericht warten. Andernfalls kann das Fahrzeug 701 die Station bei 2011 kontaktieren und versuchen, eine Bucht zu reservieren. Wenn die Anforderung nicht erfolgreich ist, kann das Fahrzeug 701 diese Daten von der Anzeige entfernen (da die Bucht reserviert oder verwendet wurde) und die Informationen mit der Modifikation erneut darstellen.
  • Wenn das Fahrzeug 701 die Ladestation bei 2013 erfolgreich reserviert, kann das Fahrzeug 701 diese Informationen auch direkt an den Server 721 melden, sodass der Server 721 dies als eine Zustandsänderung für diese Station behandeln kann und die nächsten zu sendenden Daten entsprechend aktualisieren kann. Ähnliche Aktualisierungen können gesendet werden, wenn ein Fahrzeug 701 eine Ladestation verwendet, an einer Station ankommt, das Laden beendet usw., sodass der Server 721 nicht notwendigerweise auf die Stationen selbst angewiesen ist, um Ladezustände für verschiedene Stationen zu aktualisieren.
  • Noch eine weitere mögliche Verwendung für die ATSC-Übertragung besteht darin, Softwareaktualisierungen per Broadcast zu übertragen, um eine Vielzahl von Fahrzeugen 701 gleichzeitig zu erreichen, während die Übertragungskosten verringert werden. Fahrzeuge 701, die mit Leistung versorgt werden, wenn eine Aktualisierung der Broadcast übertragen wird, können die Aktualisierung empfangen, dies könnte jedoch nur eine Teilmenge von Fahrzeugen 701 in einem gegebenen Bereich sein. Die Herausforderung für eine Broadcast-Planung der Aktualisierung besteht darin, zu bestimmen, wann eine geeignete Anzahl von Fahrzeugen 701 die Aktualisierung per Broadcast empfangen hat, und dann möglicherweise eine direkte Übertragung zu verwenden, um die Aktualisierung an Fahrzeugen 701 zu erhalten, die nicht über die Aktualisierung verfügen. Ferner sind, während die Kosten für die Verwendung von ATSC viel geringer sein können als das direkte Kommunizieren mit der gleichen Anzahl von Fahrzeugen 701, die ein einzelner Broadcast erreichen würde, die Kosten wahrscheinlich ungleich null und daher besteht ein Wunsch, Daten, die nur durch einen winzigen Prozentsatz von Fahrzeugen 701 innerhalb eines Übertragungsbereichs benötigt werden, nicht übermäßig per Broadcast zu übertragen, insbesondere wenn nicht bekannt ist, ob diese Fahrzeuge 701 online sind oder nicht.
  • Um das Senden von Aktualisierungen auszugleichen sowie den Erfolg einer Übertragung zu messen, beinhaltet dieses veranschaulichende Beispiel eine Rückmeldungskomponente, bei der Fahrzeuge 701 Erfolg, Teilerfolg, Fehler, Abschluss der Installation usw. melden können. Das System korrigiert möglicherweise im laufenden Betrieb keine Fehler, aber das Wissen, dass eine große Teilmenge von Fahrzeugen 701 in einem Übertragungsbereich keine Aktualisierung empfangen hat, könnte ein guter Grund sein, die Aktualisierung sofort erneut zu senden oder zu berücksichtigen, was das Problem sein könnte, das wahrgenommene Problem zu beheben und die Aktualisierung dann erneut zu senden.
  • Ferner kann es eine Anzahl von Kanälen geben, die mit ATSC assoziiert sind, und nur eine Teilmenge dieser Kanäle kann für eine Aktualisierung verwendet werden. Broadcasts können erhöhte Kanäle und erhöhte Frequenz oder verringerte Mengen von beiden verwenden, um sich an gemeldete Aktualisierungen und Probleme anzupassen. Die Kritikalität einer Aktualisierung kann auch Verwendungsniveaus vorgeben.
  • Zum Beispiel kann der Server 721, wenn der Prozentsatz unvollständiger Downloads eines Broadcast-Datei-Images über einem ersten Schwellenwert liegt, ohne Einschränkung eine erhöhte Kanalnutzung für den Broadcast und/oder erhöhte Frequenz anfordern. Prozentsätze über einem unteren Schwellenwert (was mehr Erfolg angibt) können zu einer einfachen Erhöhung der Frequenz führen. Prozentsätze unter einem bestimmten Schwellenwert (was einen umfassenden Erfolg angibt) kann dazu führen, dass sich der Server 721 dazu entscheidet, direkte Kommunikation zu verwenden, um die Übertragung eines Datei-Images abzuschließen, wobei Fahrzeuge 701 immer noch das vollständige Datei-Image aufweisen.
  • 21 zeigt einen veranschaulichenden Prozess zum Broadcasten von Softwareaktualisierungen, ausführbar zum Beispiel durch einen Server 721. In diesem Beispiel empfängt der Server 721 bei 2102 eine Aktualisierung, die zu einem oder mehreren Fahrzeugen 701 innerhalb einer ATSC-Broadcast-Region gehen soll. Wenn die Gesamtanzahl von Fahrzeugen 701, für die bekannt oder geplant ist, dass sie sich innerhalb der Broadcast-Region befinden, unter einem vordefinierten Schwellenwert liegt, was von den prognostizierten Kosten des Broadcasts und der Wahrscheinlichkeit des Empfangs gegenüber den Kosten des einfachen direkten Kontaktierens dieser Fahrzeuge 701 abhängig sein kann, kann der Server 721 bei 2103 Annahme- und/oder Ausführungsparameter einstellen. Wie zuvor können diese Parameter Eigenschaften des Fahrzeugs 701 (z. B. Marke, Modell, Softwareversion, Softwarepaket, zutreffende Komponente usw.) oder einen beliebigen anderen geeigneten Parameter beinhalten.
  • Der Server 721 kann dann die Übertragung eines Datei-Images der Aktualisierung zusammen mit den Parametern von einem ATSC-Sender anweisen. Wenn Fahrzeuge 701 die Aktualisierung empfangen und verarbeiten, können diese Fahrzeuge 701 bei 2107 an den Server melden, wodurch der Server 721 bestimmen kann, wie viele Fahrzeuge 701 einen Teil der Aktualisierung empfangen haben, wie viele die gesamte Aktualisierung empfangen haben, wie viele dazu in der Lage waren die Aktualisierung zu verarbeiten usw. Da viele Aktualisierungen nicht verarbeitet werden können, bis ein Fahrzeug 701 angehalten und/oder heruntergefahren ist, können die Informationen über eine erfolgreiche Installation verzögert werden. Dementsprechend kann es sein, dass die Rückmeldung in einigen Fällen nicht sofort erfolgt, obwohl der Server 721 zumindest in der Lage sein kann, relativ schnell zu messen, wie viele Fahrzeuge 701 ein gesamtes Datei-Image erfolgreich empfangen haben.
  • Wenn der Server 721 bei 2107 eine Rückmeldung empfängt, kann der Server 721 gemeldete offensichtliche Fehler bestimmen und/oder Fehlerursachen auf Grundlage von gemeldeten Stufen des vollständigen oder teilweisen Empfangs des Datei-Images vorhersagen. Zum Beispiel kann ein erster Fehlerschwellenwert (z. B. 30 % + Nichtempfangen eines vollständigen Datei-Images) bei 2109 den Server 721 dazu veranlassen, bei 2111 die Kanalverwendungsanforderungen zu erhöhen und die Broadcast-Frequenz auf eine erste Stufe bei 2117 zu erhöhen. Ein zweiter Fehlerschwellenwert (z. B. 20 %-30 % Nichtempfangen eines vollständigen Datei-Images) bei 2113 kann bewirken, dass der Server 721 bei 2117 eine Antworthäufigkeit erhöht, aber möglicherweise nicht die Verwendung eines zusätzlichen Kanals oder mehr erfordert. Ein dritter Schwellenwert (z. B. 10 %-20 % Nichtempfangen eines vollständigen Datei-Images) bei 2115 kann dazu führen, dass bei 2117 eine noch geringere Anzahl von wiederholten Anforderungen festgelegt wird. Wenn die Fehlerrate unter dem letzten Schwellenwert liegt, was bedeutet, dass ein vordefinierter annehmbarer Prozentsatz oder eine vordefinierte Anzahl von Fahrzeugen 701 gemeldet haben, dass sie die Aktualisierung vollständig empfangen haben, kann der Server 721 wählen, die verbleibenden Fahrzeuge 721 einfach direkt anstatt bei 2119 zu kontaktieren.
  • Während ein Server 721 möglicherweise nicht genau weiß, welche Fahrzeuge 701 sich zu einem bestimmten Zeitpunkt in einer ATSC-Broadcast-Region befinden oder welche Fahrzeuge 701 aktiv sind, kann er eine Liste aller Fahrzeuge 701 aufweisen, die für eine Aktualisierung vorgesehen sind (z. B. eine VIN-Liste). Wenn sich Fahrzeuge 701 melden, kann der Server 721 diese Fahrzeuge 701 von der Liste streichen, und wenn ein ausreichend niedriger Prozentsatz oder eine ausreichend geringe Anzahl an Fahrzeugen 701 verbleibt, kann der Server 721 damit beginnen, diese Fahrzeuge 701 selektiv zu kontaktieren.
  • 22 zeigt einen veranschaulichenden Prozess zum Bearbeiten des Broadcasts der Aktualisierung. In diesem Beispiel empfängt das Fahrzeug 701 bei 2201 eine Aktualisierungs- oder Patch-Benachrichtigung von dem Server 721. Auf Grundlage von Parametern, die dem Broadcast zugeordnet sind (z. B. Fahrzeugmarke, Modell, Softwareversion, Komponente usw.), bestimmt das Fahrzeug 701 bei 2203, ob beliebige erforderliche Eigenschaften des Fahrzeugs 701 mit den Parametern für die Annahme und Verarbeitung übereinstimmen. Falls nicht, kann das Fahrzeug 701 die Nachricht bei 2205 verwerfen. Andernfalls kann das Fahrzeug 701 bei 2207 Statistiken über den Download aufzeichnen, zum Beispiel, welcher Kanal verwendet wurde, wie lange der Download gedauert hat, Vollständigkeit usw.
  • Nachdem das Fahrzeug 701 die Datei bei 2209 gespeichert hat, kann das Fahrzeug 701 die aufgezeichneten Statistiken auch bei 2211 an den Server 721 melden. Dies kann es dem Server 721 ermöglichen, die festgestellten Einstellungen vorzunehmen, sowie zu bestimmen, ob bestimmte Kanäle eine angemessene Abdeckung bereitstellen und ob beliebige Kanäle mit Problemen, die durch die Rückmeldung für Fahrzeuge 701 unter Verwendung eines gegebenen Kanals bestimmbar sind, eine schlechtere Leistung als andere Kanäle widerspiegeln. Dies kann auch zum Ändern eines Broadcast-Kanals führen. Dies kann auch Leistungsprobleme für ein Fahrzeug 701 aufzeigen, wie etwa ein Fahrzeug 701, das eine schlechte Leistung von einem Kanal empfängt, der für andere Fahrzeuge 701 gut funktioniert, was Probleme mit einem Empfänger des Fahrzeugs 701 aufdecken kann und eine Möglichkeit bereitstellen kann, diese Probleme zu beheben.
  • 23 zeigt einen veranschaulichenden Prozess zum Anpassen des Broadcastens von Softwareaktualisierungen und Angehen von festgestellten Problemen, ausführbar zum Beispiel durch einen Server 721. In diesem Beispiel empfängt der Server 721 bei 2301 eine Rückmeldung des Fahrzeugs 701. Dies kann zum Beispiel den von dem Fahrzeug verwendeten Kanal 701, die Vollständigkeit des Downloads, die Downloadzeit, die Downloadgeschwindigkeit usw. beinhalten.
  • Wenn ein oder mehrere Fahrzeuge 701, die einen bestimmten Kanal verwenden, alle Statistiken zu schlechter Leistung für diesen Kanal melden (z. B. unter Schwellenwerterwartungen oder relativ zu anderen Kanälen), kann der Server 721 versuchen, bei 2303 zu bestimmen, ob ein Problem mit dem gegebenen Kanal vorliegt. Wenn der Kanal ein Problem aufweist, kann der Server 721 bei 2109 zu einem Fehlerbewertungsprozess verzweigen.
  • In anderen Fällen kann der Fehler fahrzeugseitig erscheinen. Wenn ein einzelnes Fahrzeug oder Fahrzeuge 701, die keine bestimmte verbindende Eigenschaft teilen (z. B. dasselbe geografische Gebiet oder Standort nahe anderen Fahrzeugen, bestimmte Hardware, gemeinsame Softwareversionen oder Firmwareversionen usw.), das Problem melden, kann der Server 721 bei 2305 bestimmen, dass das Problem bei den Fahrzeugen 701 selbst liegt (z. B. Teil- oder Softwarefehler) und der Server 721 kann bei 2307 die einzelnen Fahrzeuge 701 kontaktieren, um zu versuchen, das Problem zu diagnostizieren und zu beheben.
  • Wenn der Server 721 beobachtet, dass es ein einheitliches Merkmal unter den Fahrzeugen 701 gibt, die den Fehler erfahren, aber dass andere Fahrzeuge 701 auf demselben Kanal keinen Fehler erfahren (bestätigen, dass der Fehler nicht mit dem Kanal selbst zusammenhängt), kann der Server 721 bestimmen, dass das Problem zum Beispiel bei einer Softwareversion liegt. In solchen Fällen kann der ATSC-Sender 715 dazu verwendet werden, die Besitzer des Fahrzeugs 701 zu benachrichtigen, dass die Fahrzeuge 701 repariert werden müssen. Der Server 721 kann den Hersteller des Fahrzeugs 701 oder des Teils kontaktieren und bestimmen, ob eine Warnung vorhanden ist, die bei 2309 ausgegeben werden sollte, und kann dann bei 1801 zum Warnen der Besitzer des Fahrzeugs 701 abzweigen. Wenn möglich, kann der Server 721 auch veranlassen, dass der Patch für das Problem (und/oder die aktuelle Aktualisierung, die die Fahrzeuge 701 nicht empfangen können) direkt an diese Fahrzeuge 701 gesendet wird. Wenn das Kommunikationsproblem rechtzeitig behoben werden kann, können diese Fahrzeuge 701 von einer weiteren ATSC-Übertragung des Patches, den sie zuvor nicht empfangen konnten, profitieren.
  • Wenngleich vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und keine einschränkenden Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen. Des Weiteren können die Merkmale verschiedener Ausführungsformen zur Umsetzung auf logische Weise kombiniert werden, um situationsgerechte Variationen von in dieser Schrift beschriebenen Ausführungsformen herzustellen.
  • Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, das Folgendes aufweist: einen Prozessor, der zu Folgendem konfiguriert ist: zu bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von autonomen Fahrzeugen unter Bedingungen, die für die Verwendung der autonomen Fahrzeuge für Evakuierungszwecke als geeignet vordefiniert sind, verloren gegangen ist; einen oder mehrere Evakuierungspunkte zu bestimmen; einen geografischen Umkreis um jeden Evakuierungspunkt zu bestimmen, wobei der Umkreis voraussichtlich ausreichend Fahrzeuge umfasst, um den Evakuierungspunkt auf Grundlage von bestimmten Evakuierungsbedürfnissen eines gegebenen Evakuierungspunkts zu bedienen; eine Evakuierungsanweisung für jeden Evakuierungspunkt zu formulieren, wobei jede Anweisung einen oder mehrere Parameter aufweist, einschließlich mindestens des geografischen Umkreises, der einem gegebenen Evakuierungspunkt entspricht, wobei eine gegebene Evakuierungsanweisung Fahrzeuge, die die Anweisung ausführen, anweist, zu dem entsprechenden Evakuierungspunkt zu fahren; und den Broadcast einer oder mehrerer der Evakuierungsanweisungen von einem ATSC-Sender, von dem bekannt ist, dass er eine geografische Region abdeckt, die mindestens einen Teil des geografischen Umkreises jeder übertragenen Evakuierungsanweisung beinhaltet, anzuweisen.
  • Gemäß einer Ausführungsform beinhaltet das Bestimmen, dass die Kommunikation verloren gegangen ist, ein Erfassen eines Ausfalls eines oder mehrerer Mobilfunknetze, die Fahrzeugkommunikation bereitstellen.
  • Gemäß einer Ausführungsform basiert der geografische Umkreis auf zuletzt bekannten Standorten von mindestens einer Teilmenge der Vielzahl von autonomen Fahrzeugen, sodass eine geschätzte Anzahl von Fahrzeugen, die zum Bedienen eines gegebenen Evakuierungspunkts verfügbar sind, dazu verwendet werden kann, zu bestimmen, ob der Umkreis mindestens teilweise auf Grundlage der zuletzt bekannten Standorte ausreichend Fahrzeuge umfasst.
  • Gemäß einer Ausführungsform basiert der geografische Umkreis auf zuletzt bekannten Zielen von mindestens einer Teilmenge der Vielzahl von autonomen Fahrzeugen, sodass eine geschätzte Anzahl von Fahrzeugen, die zum Bedienen eines gegebenen Evakuierungspunkts verfügbar sind, dazu verwendet werden kann, zu bestimmen, ob der Umkreis mindestens teilweise auf Grundlage des zuletzt bekannten Ziels ausreichend Fahrzeuge umfasst.
  • Gemäß einer Ausführungsform beinhaltet die Anzahl von ausreichenden Fahrzeugen eine prognostizierte Anzahl von Evakuierten plus einen vordefinierten Überschuss.
  • Gemäß einer Ausführungsform beinhaltet die Evakuierungsanweisung mehrere mögliche Evakuierungspunkte und einen Randomisierungsparameter, der mit jedem der mehreren möglichen Evakuierungspunkte assoziiert ist, wobei der Randomisierungsparameter von einem Fahrzeug verwendet werden kann, um zufällig einen der mehreren möglichen Evakuierungspunkte auszuwählen.
  • Gemäß einer Ausführungsform ist der Prozessor ferner zu Folgendem konfiguriert: als Reaktion auf das Bestimmen, dass die Zweiwegekommunikation verloren gegangen ist, ein erstes Netzwerk zu bestimmen, über das die Kommunikation verloren gegangen ist; eine Kommunikationsalternative für nicht verbundene Fahrzeuge zu bestimmen, wobei die nicht verbundenen Fahrzeuge zuvor das erste Netzwerk verwendet haben, mit dem die Kommunikation verloren gegangen ist; und den Broadcast der Kommunikationsalternative als Teil einer Umprogrammierungsanweisung von dem ATSC-Sender/Empfänger anzuweisen.
  • Gemäß einer Ausführungsform beinhaltet die Kommunikationsalternative einen Namen eines alternativen Zugangspunkts alternativ zu einem Namen eines nicht verbundenen Zugangspunkts, der aktuell von den nicht verbundenen Fahrzeugen verwendet wird.
  • Gemäß einer Ausführungsform ist der Name des nicht verbundenen Zugangspunkts in der Kommunikationsalternative als ein Parameter zum Annehmen der Nachricht, die die Kommunikationsalternative beinhaltet, beinhaltet.
  • Gemäß einer Ausführungsform beinhaltet die Kommunikationsalternative ein alternatives Netzwerkprofil alternativ zu einem nicht verbundenen Netzwerk, das aktuell von den nicht verbundenen Fahrzeugen verwendet wird.
  • Gemäß einer Ausführungsform ist der Name des nicht verbundenen Netzwerks in der Kommunikationsalternative als ein Parameter zum Annehmen der Nachricht, die die Kommunikationsalternative beinhaltet, beinhaltet.
  • Gemäß einer Ausführungsform beinhaltet die Kommunikationsalternative eine Vielzahl von Kommunikationsalternativen und jede der Vielzahl von Alternativen beinhaltet einen oder mehrere damit assoziierte Parameter als Parameter zum Umschalten zu einer gegebenen Alternative auf Grundlage davon, ob die Parameter für die gegebene Alternative mit Fahrzeugparametern übereinstimmen.
  • Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, das Folgendes aufweist: einen Prozessor, der zu Folgendem konfiguriert ist: zu bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von nicht verbundenen Fahrzeugen verloren gegangen ist, was einen Kommunikationsverlust über mindestens ein Mobilfunknetz für mindestens einen gegebenen Bereich oder ein Kommunikationsverlust, der mit mindestens einem Namen eines nicht verbundenen Mobilfunkzugangspunkts korreliert, darstellt; als Reaktion auf das Bestimmen, dass die Zweiwegekommunikation verloren gegangen ist, den Namens des mindestens einen Mobilfunknetzes oder nicht verbundenen Zugangspunkts, über den die Kommunikation verloren gegangen ist, zu bestimmen; eine Kommunikationsalternative für die Vielzahl von nicht verbundenen Fahrzeugen, die mindestens einen Namen eines Ersatznetzes oder Ersatzzugangspunkts darstellt, auf Grundlage dessen zu bestimmen, ob die Kommunikation über den mindestens einen Namen eines Mobilfunknetzes oder eines nicht verbundenen Zugangspunkts verloren gegangen ist; und den Broadcast der Kommunikationsalternative als Teil einer Umprogrammierungsanweisung von dem ATSC-Sender/Empfänger anzuweisen.
  • Gemäß einer Ausführungsform beinhaltet die Kommunikationsalternative einen Namen eines alternativen Zugangspunkts alternativ zu einem Namen eines nicht verbundenen Zugangspunkts, der aktuell von den nicht verbundenen Fahrzeugen verwendet wird.
  • Gemäß einer Ausführungsform ist der Name des nicht verbundenen Zugangspunkts in der Kommunikationsalternative als ein Parameter zum Annehmen der Nachricht, die die Kommunikationsalternative beinhaltet, beinhaltet.
  • Gemäß einer Ausführungsform beinhaltet die Kommunikationsalternative einen Namen eines alternativen Netzwerks alternativ zu einem nicht verbundenen Netzwerk, das aktuell von den nicht verbundenen Fahrzeugen verwendet wird.
  • Gemäß einer Ausführungsform ist der Name des nicht verbundenen Netzwerks in der Kommunikationsalternative als ein Parameter zum Annehmen der Nachricht, die die Kommunikationsalternative beinhaltet, beinhaltet.
  • Gemäß einer Ausführungsform beinhaltet die Kommunikationsalternative eine Vielzahl von Kommunikationsalternativen und jede der Vielzahl von Alternativen beinhaltet einen oder mehrere damit assoziierte Parameter als Parameter zum Umschalten zu einer gegebenen Alternative auf Grundlage davon, ob die Parameter für die gegebene Alternative mit Fahrzeugparametern übereinstimmen.
  • Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, das Folgendes aufweist: einen Prozessor, der zu Folgendem konfiguriert ist: die Evakuierungsbedürfnisse für eine Vielzahl von Evakuierungspunkten zu bestimmen; einen geografischen Umkreis für jeden Evakuierungspunkt, der eine Anzahl von autonomen Fahrzeugen umfasst, die voraussichtlich zum Bedienen der Evakuierung eines gegebenen Evakuierungspunkts geeignet sind, zu bestimmen; eine Evakuierungsanweisung für jeden Evakuierungspunkt zu formulieren, einschließlich des für jeden Evakuierungspunkt bestimmten geografischen Umkreises als Parameter zum Annehmen einer gegebenen Anweisung; und den Broadcast der Evakuierungsanweisungen von einem ATSC-Sender anzuweisen.
  • Gemäß einer Ausführungsform ist der Prozessor ferner zu Folgendem konfiguriert: zu bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von nicht verbundenen Fahrzeugen verloren gegangen ist, als Reaktion auf das Bestimmen, dass die Zweiwegekommunikation verloren gegangen ist, ein erstes Netzwerk zu bestimmen, über das die Kommunikation verloren gegangen ist; eine Kommunikationsalternative zu dem ersten Netzwerk für nicht verbundene Fahrzeuge zu bestimmen, um die Verbindung wiederherzustellen; und den Broadcast der Kommunikationsalternative als Teil einer Umprogrammierungsanweisung von dem ATSC-Sender/Empfänger anzuweisen.

Claims (15)

  1. System, umfassend: einen Prozessor, der zu Folgendem konfiguriert ist: zu bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von autonomen Fahrzeugen unter Bedingungen, die für die Verwendung der autonomen Fahrzeuge für Evakuierungszwecke als geeignet vordefiniert sind, verloren gegangen ist; einen oder mehrere Evakuierungspunkte zu bestimmen; einen geografischen Umkreis um jeden Evakuierungspunkt zu bestimmen, wobei der Umkreis voraussichtlich ausreichend Fahrzeuge umfasst, um den Evakuierungspunkt auf Grundlage von bestimmten Evakuierungsbedürfnissen eines gegebenen Evakuierungspunkts zu bedienen; eine Evakuierungsanweisung für jeden Evakuierungspunkt zu formulieren, wobei jede Anweisung einen oder mehrere Parameter aufweist, einschließlich mindestens des geografischen Umkreises, der einem gegebenen Evakuierungspunkt entspricht, wobei eine gegebene Evakuierungsanweisung Fahrzeuge, die die Anweisung ausführen, anweist, zu dem entsprechenden Evakuierungspunkt zu fahren; und einen Broadcast einer oder mehrerer der Evakuierungsanweisungen von einem ATSC-Sender, für den bekannt ist, dass er eine geografische Region abdeckt, die mindestens einen Teil des geografischen Umkreises jeder übertragenen Evakuierungsanweisung beinhaltet, anzuweisen.
  2. System nach Anspruch 1, wobei das Bestimmen, dass die Kommunikation verloren gegangen ist, ein Erfassen eines Ausfalls eines oder mehrerer Mobilfunknetze, die Fahrzeugkommunikation bereitstellen, beinhaltet.
  3. System nach Anspruch 1, wobei der geografische Umkreis auf zuletzt bekannten Standorten von mindestens einer Teilmenge der Vielzahl von autonomen Fahrzeugen basiert, sodass eine geschätzte Anzahl von Fahrzeugen, die zum Bedienen eines gegebenen Evakuierungspunkts verfügbar sind, dazu verwendet werden kann, zu bestimmen, ob der Umkreis mindestens teilweise auf Grundlage der zuletzt bekannten Standorte ausreichend Fahrzeuge umfasst.
  4. System nach Anspruch 1, wobei der geografische Umkreis auf zuletzt bekannten Zielen von mindestens einer Teilmenge der Vielzahl von autonomen Fahrzeugen basiert, sodass eine geschätzte Anzahl von Fahrzeugen, die zum Bedienen eines gegebenen Evakuierungspunkts verfügbar sind, dazu verwendet werden kann, zu bestimmen, ob der Umkreis mindestens teilweise auf Grundlage des zuletzt bekannten Ziels ausreichend Fahrzeuge umfasst.
  5. System nach Anspruch 1, wobei die Anzahl von ausreichenden Fahrzeugen eine prognostizierte Anzahl von Evakuierten plus einen vordefinierten Überschuss beinhaltet.
  6. System nach Anspruch 1, wobei die Evakuierungsanweisung mehrere mögliche Evakuierungspunkte und einen Randomisierungsparameter, der mit jedem der mehreren möglichen Evakuierungspunkte assoziiert ist, beinhaltet, wobei der Randomisierungsparameter von einem Fahrzeug verwendet werden kann, um zufällig einen der mehreren möglichen Evakuierungspunkte auszuwählen.
  7. System nach Anspruch 1, wobei der Prozessor ferner zu Folgendem konfiguriert ist: als Reaktion auf das Bestimmen, dass die Zweiwegekommunikation verloren gegangen ist, ein erstes Netzwerk, über das die Kommunikation verloren gegangen ist, zu bestimmen; eine Kommunikationsalternative für nicht verbundene Fahrzeuge zu bestimmen, wobei die nicht verbundenen Fahrzeuge zuvor das erste Netzwerk verwendet haben, mit dem die Kommunikation verloren gegangen ist; und den Broadcast der Kommunikationsalternative als Teil einer Umprogrammierungsanweisung von dem ATSC-Sender/Empfänger anzuweisen.
  8. System nach Anspruch 7, wobei die Kommunikationsalternative einen Namen eines alternativen Zugangspunkts alternativ zu einem Namen eines nicht verbundenen Zugangspunkts, der aktuell von den nicht verbundenen Fahrzeugen verwendet wird, beinhaltet.
  9. System nach Anspruch 8, wobei der Name des nicht verbundenen Zugangspunkts in der Kommunikationsalternative als ein Parameter zum Annehmen der Nachricht, die die Kommunikationsalternative beinhaltet, beinhaltet ist.
  10. System nach Anspruch 7, wobei die Kommunikationsalternative ein Profil eines alternativen Netzwerks alternativ zu einem nicht verbundenen Netzwerk, das aktuell von den nicht verbundenen Fahrzeugen verwendet wird, beinhaltet.
  11. System nach Anspruch 10, wobei der Name des nicht verbundenen Netzwerks in der Kommunikationsalternative als ein Parameter zum Annehmen der Nachricht, die die Kommunikationsalternative beinhaltet, beinhaltet ist.
  12. System nach Anspruch 7, wobei die Kommunikationsalternative eine Vielzahl von Kommunikationsalternativen beinhaltet und jede der Vielzahl von Alternativen einen oder mehrere damit assoziierte Parameter als Parameter zum Umschalten zu einer gegebenen Alternative auf Grundlage davon, ob die Parameter für die gegebene Alternative mit Fahrzeugparametern übereinstimmen, beinhaltet.
  13. System, umfassend: einen Prozessor, der zu Folgendem konfiguriert ist: zu bestimmen, dass die Zweiwegekommunikation mit einer Vielzahl von nicht verbundenen Fahrzeugen verloren gegangen ist, was einen Kommunikationsverlust über mindestens ein Mobilfunknetz für mindestens einen gegebenen Bereich oder einen Kommunikationsverlust, der mit mindestens einem Namen eines nicht verbundenen Mobilfunkzugangspunkts korreliert, darstellt; als Reaktion auf das Bestimmen, dass die Zweiwegekommunikation verloren gegangen ist, den Namen des mindestens einen Mobilfunknetzes oder des nicht verbundenen Zugangspunkts, über den die Kommunikation verloren gegangen ist, zu bestimmen; eine Kommunikationsalternative für die Vielzahl von nicht verbundenen Fahrzeugen, die mindestens einen Namen eines Ersatznetzes oder Ersatzzugangspunkts darstellt, auf Grundlage dessen zu bestimmen, ob die Kommunikation über den mindestens einen Namen eines Mobilfunknetzes oder eines nicht verbundenen Zugangspunkts verloren gegangen ist; und den Broadcast der Kommunikationsalternative als Teil einer Umprogrammierungsanweisung von dem ATSC-Sender/Empfänger anzuweisen.
  14. System nach Anspruch 13, wobei die Kommunikationsalternative einen Namen eines alternativen Zugangspunkts alternativ zu einem Namen eines nicht verbundenen Zugangspunkts, der aktuell von den nicht verbundenen Fahrzeugen verwendet wird, beinhaltet.
  15. System nach Anspruch 14, wobei der Name des nicht verbundenen Zugangspunkts in der Kommunikationsalternative als ein Parameter zum Annehmen der Nachricht, die die Kommunikationsalternative beinhaltet, beinhaltet ist.
DE102021132562.5A 2020-12-09 2021-12-09 Verfahren und vorrichtung zur handhabung einer autonomen flotte unter verwendung von broadcast-führung Pending DE102021132562A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/115,981 US11412479B2 (en) 2020-12-09 2020-12-09 Method and apparatus for autonomous fleet handling using broadcast guidance
US17/115,981 2020-12-09

Publications (1)

Publication Number Publication Date
DE102021132562A1 true DE102021132562A1 (de) 2022-06-23

Family

ID=81847366

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021132562.5A Pending DE102021132562A1 (de) 2020-12-09 2021-12-09 Verfahren und vorrichtung zur handhabung einer autonomen flotte unter verwendung von broadcast-führung

Country Status (3)

Country Link
US (2) US11412479B2 (de)
CN (1) CN114630295A (de)
DE (1) DE102021132562A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20230030850A (ko) * 2021-08-26 2023-03-07 현대자동차주식회사 머신러닝 기반 방송 정보를 제공하는 방법 및 그 장치

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IE20030139A1 (en) * 2002-02-27 2003-10-01 Ind Interfaces Ltd A risk mapping system
US20090106036A1 (en) 2007-10-22 2009-04-23 Kazuya Tamura Method and system for making automated appointments
US9098839B2 (en) 2008-08-01 2015-08-04 Sony Computer Entertainment America, LLC Incentivizing commerce by regionally localized broadcast signal in conjunction with automatic feedback or filtering
US8406986B2 (en) * 2010-04-27 2013-03-26 International Business Machines Corporation Emergency routing within a controllable transit system
US20170169625A1 (en) 2011-12-21 2017-06-15 Scope Technologies Holdings Limited Developing and using a vehicle diagnostic distributed database
US20140258455A1 (en) 2013-03-09 2014-09-11 Microchip Technology Incorporated Geolocated Network
JP6071792B2 (ja) * 2013-07-31 2017-02-01 株式会社東芝 社会情報提供システムおよび社会情報配信装置
US10523772B2 (en) * 2014-10-03 2019-12-31 Drive Time Metrics, Inc. Cross channel in-vehicle video consumption measurement and analysis
US9513134B1 (en) * 2015-12-16 2016-12-06 International Business Machines Corporation Management of evacuation with mobile objects
US10659849B2 (en) * 2016-08-12 2020-05-19 Sharp Kabushiki Kaisha Systems and methods for signaling of emergency alert messages
US10433022B2 (en) 2016-11-15 2019-10-01 Siden, Inc. A Delaware C Corp Method and system for providing non-real-time content distribution services
CA3044996A1 (en) * 2016-11-28 2018-05-31 Sharp Kabushiki Kaisha Systems and methods for signaling of emergency alert messages
US10341722B2 (en) 2016-12-22 2019-07-02 DISH Technologies L.L.C. Distributed indoor smart antenna system for over-the-air television reception
KR101844472B1 (ko) * 2017-05-10 2018-04-02 김경수 원격 방재 시스템
JP6958243B2 (ja) * 2017-11-01 2021-11-02 トヨタ自動車株式会社 自動運転車両
JP6962865B2 (ja) 2018-05-30 2021-11-05 本田技研工業株式会社 自動運転車両
US10659947B1 (en) * 2018-11-12 2020-05-19 Electronics And Telecommunications Research Institute Apparatus and method for transmitting shelter location information based on ATSC 3.0, and apparatus and method for receiving shelter location information based on ATSC 3.0
JP2020123825A (ja) * 2019-01-30 2020-08-13 ソニーセミコンダクタソリューションズ株式会社 信号処理装置、信号処理方法、受信装置、及び信号処理プログラム
US10870433B2 (en) * 2019-04-11 2020-12-22 Ford Global Technologies, Llc Emergency route planning system
JP7234872B2 (ja) * 2019-09-12 2023-03-08 トヨタ自動車株式会社 車両遠隔指示システム
US20210225092A1 (en) * 2020-01-16 2021-07-22 Ford Global Technologies, Llc Method and apparatus for one to many vehicle broadcast handling
US11648855B2 (en) * 2020-06-04 2023-05-16 Uatc, Llc Systems and methods for seat reconfiguration for autonomous vehicles
US11323778B2 (en) * 2020-09-23 2022-05-03 Sony Group Corporation Unified programming guide for content associated with broadcaster and VOD applications

Also Published As

Publication number Publication date
CN114630295A (zh) 2022-06-14
US20220182975A1 (en) 2022-06-09
US20220369286A1 (en) 2022-11-17
US11882572B2 (en) 2024-01-23
US11412479B2 (en) 2022-08-09

Similar Documents

Publication Publication Date Title
DE102011120965B4 (de) Informationserfassungssystem unter Verwendung von Mehrfachfunk-Telematikvorrichtungen
DE102015000403B3 (de) Übertragen von Streckendaten an ein Kraftfahrzeug
DE102011116972B4 (de) Intelligente Telematik-Informationsverbreitung unter Verwendung von Delegations-, Abruf- und Weitergabealgorithmen
JP6477391B2 (ja) グループ走行運用システム
US20180365994A1 (en) Traffic control method, and apparatus
DE102019106881A1 (de) Verringerung der Kanalüberlastung in der Kommunikation zwischen Fahrzeugen
US20230030446A1 (en) Remote driving method, apparatus, and system, device, and medium
DE102016207984B3 (de) Verfahren und Vorrichtung zur Übertragung von durch ein fahrendes Fahrzeug erfassten Fahrwegdaten an eine zentrale Datenbank unter verbesserter Wahrung der Privatsphäre
EP3665914A1 (de) Verfahren zum koppeln eines endfahrzeugs mit einem stationären datennetzwerk sowie system zum durchführen des verfahrens
DE102015215333A1 (de) Vorrichtung zum Laden von Daten aus einer stationären Drahtloskommunikationsinfrastruktur während einer Fortbewegung
DE112020005665T5 (de) Steuervorrichtung, mobiles Objekt, Verwaltungsserver, Basisstation, Kommunikationssystem undKommunikationsverfahren
DE102020127425A1 (de) Autonome Fahrzeugstationen
DE102021132562A1 (de) Verfahren und vorrichtung zur handhabung einer autonomen flotte unter verwendung von broadcast-führung
DE102022101597A1 (de) Verfahren und einrichtung zum übertragen per broadcast und bearbeiten einer adaptiven routenführung
US20210256842A1 (en) System, method and apparatus supporting navigation
EP3586326B1 (de) System und verfahren zur sicheren und effizienten bereitstellung von zumindest teilautonomen fahrmodi
DE112021006291T5 (de) Kommunikationsverwaltungseinrichtung, kommunikationsverwaltungsverfahren, kommunikationsverwaltungsprogramm, fahrassistenzvorrichtung, fahrassistenzverfahren und fahrassistenzprogramm
DE102021132216A1 (de) Verfahren und Vorrichtung für Broadcast von Softwareaktualisierungen
DE102014100569A1 (de) Navigationsverfahren und Navigationssystem
DE102022113890A1 (de) Systeme und verfahren zum betreiben von drohnenflügen über öffentlichen strassen
DE102021108040A1 (de) Verwalten der energie elektronischer einrichtungen in einem fahrzeug
EP3363218B1 (de) Verfahren und vorrichtung zur selektiven übertragung von daten
WO2020099008A1 (de) Verfahren zur erstellung einer abdeckungskarte für ein drahtloses kommunikationssystem und abdeckungskarte
DE102022124723A1 (de) Datenauslagerungsverwaltung für verbundene fahrzeuge
DE102017104477A1 (de) Progressive pflege von landkarten bei einer mobilen navigationseinheit

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: LORENZ SEIDLER GOSSEL RECHTSANWAELTE PATENTANW, DE