DE102015113436A1

DE102015113436A1 - Verfahren und Vorrichtung zur Aktivierung und Protokollierung von Ereignisdatenaufzeichnung

Info

Publication number: DE102015113436A1
Application number: DE102015113436.5A
Authority: DE
Inventors: David Chronowski; Hussein F. NASRALLAH; Kevin Michael Bullister
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-08-29
Filing date: 2015-08-14
Publication date: 2016-03-03
Also published as: CN105383416B; US20160063776A1; CN105383416A

Abstract

Ein System umfasst einen Prozessor, der so konfiguriert ist, dass er eine Bedingung erkennt, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte. Der Prozessor ist ferner so konfiguriert, dass er die Ereignisdatenaufzeichnung startet und für eine vorbestimmte Zeitdauer nach der Bedingung fortsetzt. Außerdem ist der Prozessor so konfiguriert, dass er durch die Ereignisdatenaufzeichnung aufgezeichnete Daten speichert, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde. Der Prozessor ist ferner so konfiguriert, dass er die Daten auf ein Remote-System hochlädt, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.

Description

TECHNISCHES GEBIET
Die beispielhaften Ausführungsformen betreffen im Allgemeinen ein Verfahren und eine Vorrichtung zur Aktivierung und Protokollierung von Ereignisdatenaufzeichnung (EDR für engl. event data recording).
HINTERGRUND
Ähnlich einer Blackbox in einem Flugzeug weisen viele Fahrzeuge ein Ereignisdatenaufzeichnungsgerät auf, das die Aufzeichnung von Fahrzeugdaten ermöglicht, wenn sich ein Unfall ereignet, wobei die Aufzeichnung beim Bestimmen von Fahrzeugcharakteristiken (z. B. Geschwindigkeit, Fehlfunktion von Teilen, Traktionszuständen usw.), die zum Unfall geführt haben können, hilfreich sein kann. Derzeit werden die meisten EDRs als Speichervorrichtung zum Aufzeichnen eines Schnappschusses von Daten eingesetzt, die ein Unfallereignis umgeben. Typischerweise weisen EDRs Schwellen auf, die bestimmen, wann das Aufzeichnen beginnt. Diese Schwellen stehen typischerweise mit Bedingungen in Beziehung, die wahrscheinlich zu einem Unfall führen. In vielen Fällen werden Aufzeichnungen begonnen und dann später überschrieben, da der Fahrzeugbetriebsmodus eine oder mehrere Initiierungsschwellen überschritt, aber tatsächlich kein Unfallereignis eintrat. In diesen Fällen werden die EDR-Daten nicht zum Abrufen gesperrt, sondern durch spätere EDR-Ereignisse bei Überschreiten einer anderen Schwelle überschrieben.
US-Patent 8,139,820 betrifft im Allgemeinen Aufzeichnungsgeräte und Analysesysteme für Ausnahmeereignisse, die umfassen: fahrzeugmontierte Sensoren, die als Fahrzeugereignisaufzeichnungsgeräte ausgelegt sind, um sowohl diskrete als auch nicht-diskrete Daten zu erfassen; eine Diskretisierungseinrichtung; eine Datenbank und einen Analyseserver, die allesamt als ein Computernetz gekoppelt sind. Motorfahrzeuge mit Videokameras und Onboard-Diagnosesystemen erfassen Daten, wenn das Fahrzeug an einem Unfall oder einer anderen Anomalie (einem „Ereignis“) beteiligt ist. Stationsintern, d. h. in einer Diskretisierungseinrichtung, wo eine Interpretation von nicht-diskreten Daten erfolgt, werden erfasste Daten als eine Basis zur Erzeugung von diskreten Ergänzungsdaten zur weiteren Charakterisierung des Ereignisses verwendet. Solche interpretierten Daten werden mit erfassten Daten vereint und in eine Datenbank in einer Struktur eingegeben, welche durchsuchbar ist und welche logische oder mathematische Analyse durch automatische Maschinen unterstützt. Ein gekoppelter Analyseserver ist so ausgelegt, dass er die gespeicherten Daten auf vorgeschriebene Bedingungen überprüft und, wenn er solche findet, weitere Aktionen einleitet, die für die erkannte Bedingung geeignet sind.
Die US-Anmeldung Nr. 2006/0212195 betrifft im Allgemeinen ein Fahrzeugdatenaufzeichnungsgerät mit der Fähigkeit zu kontinuierlichem Aufzeichnen und Speichern von ausgewählten Daten sowohl über Fahrer- als auch Fahrzeugleistung, die, ohne darauf beschränkt zu sein, zurückgelegte Meilen, Geschwindigkeit, Beschleunigung/Entschleunigung, Bremsenaktivierung, Sicherheitsgurtgebrauch, Fahrzeugrichtung, Lenkungsanomalien, globale Position, Anprallkräfte und -richtung, Getriebestatus und Alkoholgebrauch umfassen werden. Insbesondere weist dieses Aufzeichnungsgerät eine erweiterte Datenspeicherkapazität, eine Alkohol-Zündschlosssperre, Echtzeit-GPS-Daten, leistungsarme Zellulartelefonstörung, und interne Drahtloskommunikationsfähigkeiten auf. Es verwendet mikroprozessorgesteuerte Elektronik zum Aufzeichnen, Speichern und Senden sowohl von Fahrer- als auch Fahrzeugleistungsdaten in einer datums- und zeitgestempelten Datei, die zum Erstellen von personalisierten Versicherungsprämien, Festlegen von Kraftfahrzeugsteuer- und Straßenbenutzungsgebühren, Auffinden von „Amber-Alert“-Opfern oder gestohlenen Fahrzeugen und, mit ihrem Vor-Ort-Zugriff, Bereitstellen von kritischen Verletzungsinformationsmechanismen für Notfallhelfer verwendet werden kann.
KURZDARSTELLUNG
In einer ersten beispielhaften Ausführungsform umfasst ein System einen Prozessor, der so konfiguriert ist, dass er eine Bedingung erkennt, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte. Der Prozessor ist ferner so konfiguriert, dass er die Ereignisdatenaufzeichnung startet und für eine vorbestimmte Zeitdauer nach der Bedingung fortsetzt. Außerdem ist der Prozessor so konfiguriert, dass er durch die Ereignisdatenaufzeichnung aufgezeichnete Daten speichert, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde. Der Prozessor ist ferner so konfiguriert, dass er die Daten auf ein Remote-System hochlädt, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.
In einer zweiten beispielhaften Ausführungsform umfasst ein System einen Prozessor, der so konfiguriert ist, dass er variable Eingabedaten von einer Mehrzahl von drahtlos verbundenen Fahrzeugen empfängt. Der Prozessor ist ferner so konfiguriert, dass er die empfangenen variablen Eingabedaten mit vorbestimmten Schwellen vergleicht, um zu bestimmen, ob eine Bedingung, die wahrscheinlich Ereignisdatenaufzeichnung (EDR) initiiert, in einem der Mehrzahl von Fahrzeugen bevorsteht. Außerdem ist der Prozessor so konfiguriert, dass er eine Anweisung für das Fahrzeug zum Warnen des Autofahrers ausgibt, und zwar für jedes Fahrzeug, bei welchem die Bedingung bevorsteht. Der Prozessor ist zudem so konfiguriert, dass er an jedes Fahrzeug, für welches die Bedingung bevorsteht, eine Anforderung ausgibt, welche Ereignisdatenaufzeichnung anfordert. Der Prozessor wurde ferner so konfiguriert, dass er Daten sammelt, die durch die angeforderte(n) Ereignisdatenaufzeichnung(en) aufgezeichnet wurden.
In einer dritten beispielhaften Ausführungsform umfasst ein computerimplementiertes Verfahren ein Erkennen einer Bedingung, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte. Das Verfahren umfasst ferner ein Starten und Fortsetzen der Ereignisdatenaufzeichnung für eine vorbestimmte Zeitdauer nach der Bedingung. Außerdem umfasst das Verfahren ein Speichern der durch die Ereignisdatenaufzeichnung aufgezeichneten Daten, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde. Das Verfahren umfasst ferner ein Hochladen der Daten auf ein Remote-System, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt ein beispielhaftes Fahrzeug-Computersystem dar;
2 stellt ein veranschaulichendes Beispiel von EDR-Überwachung dar;
3 stellt ein veranschaulichendes Beispiel eines Fahrer-Warnprozesses dar; und
4 stellt ein weiteres veranschaulichendes Beispiel von EDR-Überwachung dar.
AUSFÜHRLICHE BESCHREIBUNG
Wie erforderlich, werden hierin ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch von selbst, dass die offenbarten Ausführungsformen lediglich Beispiele der Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Einzelheiten von bestimmten Komponenten darzustellen. Daher sind die hierin offenbarten spezifischen Struktur- und Funktionsdetails nicht als einschränkend, sondern lediglich als repräsentative Basis für die Belehrung von Fachleuten über verschiedene Einsatzmöglichkeiten der vorliegenden Erfindung auszulegen.
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem 1 (VCS) für ein Fahrzeug 31. Ein Beispiel für solch ein fahrzeugbasiertes Computersystem 1 ist das SYNC-System, das von THE FORD MOTOR COMPANY hergestellt wird. Ein Fahrzeug, das mit einem fahrzeugbasierten Computersystem versehen ist, kann eine grafische Front-End-Schnittstelle 4 enthalten, die im Fahrzeug angeordnet ist. Der Benutzer kann außerdem in der Lage sein, mit der Schnittstelle zu interagieren, wenn sie zum Beispiel mit einem Berührungsbildschirm versehen ist. In einer weiteren beispielhaften Ausführungsform erfolgt die Interaktion durch Drücken von Tasten, ein sprachliches Dialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der beispielhaften Ausführungsform 1, die in 1 dargestellt ist, steuert ein Prozessor 3 mindestens einen gewissen Teil des Betriebs des fahrzeugbasierten Computersystems. Der innerhalb des Fahrzeugs vorgesehene Prozessor ermöglicht On-Board-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nichtbeständigen 5 als auch einem beständigen Speicher 7 verbunden. In dieser beispielhaften Ausführungsform ist der nichtbeständige Speicher ein Direktzugriffsspeicher (RAM), und der beständige Speicher ist ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher. Im Allgemeinen kann ein persistenter (nicht-transitorischer) Speicher alle Formen von Speichern umfassen, welche Daten bewahren, wenn ein Computer oder eine andere Vorrichtung ausgeschaltet wird. Diese umfassen, ohne darauf beschränkt zu sein, HDDs, CDs, DVDs, Magnetbänder, tragbare USB-Laufwerke und jede andere geeignete Form von persistentem Speicher.
Der Prozessor ist außerdem mit einer Anzahl von verschiedenen Eingängen versehen, die es dem Benutzer ermöglichen, über eine Schnittstelle eine Verbindung mit dem Prozessor herzustellen. In dieser beispielhaften Ausführungsform sind ein Mikrofon 29, ein Aux-Eingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der eine Touchscreen-Anzeige sein kann, und ein BLUETOOTH-Eingang 15 vorgesehen. Es ist auch ein Eingangswähler 51 vorgesehen, um einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Sowohl die Eingabe in das Mikrofon als auch in den Aux-Anschluss wird durch einen Wandler 27 von analog in digital umgewandelt, bevor sie zum Prozessor weitergegeben wird. Obwohl nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Zusatzkomponenten in Kommunikation mit dem VCS ein Fahrzeugnetzwerk (wie beispielsweise einen CAN-Bus, ohne darauf beschränkt zu sein) verwenden, um Daten an das oder von dem VCS (oder Komponenten davon) weiterzugeben.
Ausgänge zum System können eine Sichtanzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang umfassen, ohne darauf beschränkt zu sein. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 durch einen Digital-Analog-Wandler 9. Die Ausgabe kann zusammen mit den bidirektionalen Datenströmen, die bei 19 bzw. 21 dargestellt sind, auch an ein entferntes BLUETOOTH-Gerät, wie beispielsweise ein PND (personal navigation device) 54, oder ein USB-Gerät, wie beispielsweise ein Fahrzeugnavigationssystem 60, erfolgen.
In einer beispielhaften Ausführungsform verwendet das System 1 den BLUETOOTH-Sendempfänger 15, um mit einem mobilen Gerät (ND für engl. nomadic device) 53 eines Benutzers (z. B. Zellulartelefon, Smartphone, PDA oder beliebigen anderen Geräten mit Anschlussmöglichkeit an ein drahtloses Remote-Netzwerk) zu kommunizieren 17. Das mobile Gerät kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Eine beispielhafte Kommunikation zwischen dem mobilen Gerät und dem BLUETOOTH-Sendeempfänger ist durch das Signal 14 dargestellt.
Die Kopplung eines mobilen Geräts 53 und des BLUETOOTH-Sendeempfängers 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Demgemäß wird die CPU angewiesen, dass der BLUETOOTH-Sendeempfänger an Bord mit einem BLUETOOTH-Sendeempfänger in einem mobilen Gerät gekoppelt wird.
Daten können zum Beispiel unter Verwendung eines Datentarifs, Data-over-Voice oder von DTMF-Tönen, die mit dem mobilen Gerät 53 assoziiert sind, zwischen der CPU 3 und dem Netzwerk 61 kommuniziert werden. Alternativ kann es wünschenswert sein, ein Bord-Modem 63 mit einer Antenne 18 einzubeziehen, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Das mobile Gerät 53 kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netzwerk 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein zellulares USB-Modem sein, und die Kommunikation 20 kann zellulare Kommunikation sein.
In einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, dass eine API umfasst, um mit Modem-Anwendungssoftware zu kommunizieren. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder auf eingebettete Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sendeempfänger (wie beispielsweise dem, der in einem mobilen Gerät zu finden ist) durchzuführen. Bluetooth ist ein Teilsatz der IEEE 802 PAN(Netzwerk für den persönlichen Bereich)-Protokolle. IEEE 802 LAN(lokales Netzwerk)-Protokolle umfassen WiFi und weisen eine erhebliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide sind für drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Andere Kommunikationsmittel, die in diesem Bereich verwendet werden können, sind freiraumoptische Kommunikation (wie beispielsweise IrDA) und nichtstandardisierte Consumer IR-Protokolle.
In einer anderen Ausführungsform umfasst das mobile Gerät 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. Bei der Data-over-Voice-Ausführungsform kann eine Technik, die als Frequenzmultiplexverfahren bekannt ist, implementiert werden, wenn der Besitzer des mobilen Geräts über das Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Besitzer das Gerät nicht benutzt, kann der Datentransfer die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) verwenden. Obwohl das Frequenzmultiplexverfahren für analoge zellulare Kommunikation zwischen dem Fahrzeug und dem Internet üblich sein kann und auch noch verwendet wird, wurde es im Wesentlichen durch Hybride von Codemultiplexzugriff (CDMA), Zeitmultiplexzugriff (TDMA), Raummultiplexzugriff (SDMA) für digitale zellulare Kommunikation ersetzt. Dies sind allesamt ITU IMT-2000-(3G)-kompatible Standards und bieten Datenraten von bis zu 2 Mbit/s für stehende oder gehende Benutzer und 385 kbit/s für Benutzer in einem fahrenden Fahrzeug. 3G-Standards werden nun durch IMT-Advanced (4G) ersetzt, der 100 Mbit/s für Benutzer in einem Fahrzeug und 1 Gbit/s für stehende Benutzer bietet. Wenn der Benutzer einen Datentarif hat, der mit dem mobilen Gerät assoziiert ist, ist es möglich, dass der Datentarif Breitbandübertragung ermöglicht, und das System eine wesentlich breitere Bandbreite (Beschleunigung des Datentransfers) verwenden könnte. In noch einer anderen Ausführungsform ist das mobile Gerät 23 durch ein zellulares Kommunikationsgerät (nicht dargestellt) ersetzt, das im Fahrzeug 31 installiert ist. In noch einer weiteren Ausführungsform kann das ND 53 ein WLAN(wireless local area network)-Gerät sein, das zum Beispiel (und ohne Einschränkung) zur Kommunikation über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk imstande ist.
In einer Ausführungsform können ankommende Daten durch das mobile Gerät über Data-over-Voice oder einen Datentarif durch den BLUETOOTH-Sendeempfänger an Bord und in den fahrzeuginternen Prozessor 3 übermittelt werden. Im Falle von bestimmten temporären Daten zum Beispiel können die Daten auf dem HDD oder einem anderen Speichermedium 7 solange gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die mit dem Fahrzeug über eine Schnittstelle verbunden sein können, umfassen ein mobiles Navigationsgerät 54 zum Beispiel mit einem USB-Anschluss 56 und/oder einer Antenne 58, ein Fahrzeugnavigationsgerät 60 mit einem USB 62 oder einem anderen Anschluss, ein GPS-Gerät 24 an Bord oder ein entferntes Navigationssystem (nicht dargestellt) mit Anschlussmöglichkeit an das Netzwerk 61. USB ist eine Klasse von seriellen Netzwerkprotokollen. Die seriellen IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), EIA (Electronics Industry Association) serielle Protokolle, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Gerät-Gerät-Standards. Die meisten der Protokolle können für elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU mit einer Vielzahl von anderen Zusatzgeräten 65 in Kommunikation sein. Diese Geräte können durch eine drahtlose 67 oder drahtgebundene 69 Verbindung verbunden sein. Die Zusatzgeräte 65 können persönliche Medienabspielgeräte, drahtlose medizinische Geräte, tragbare Computer und dergleichen umfassen, ohne darauf beschränkt zu sein.
Außerdem oder alternativ könnte die CPU zum Beispiel unter Verwendung beispielsweise eines WiFi (IEEE 803.11) 71-Sendeempfängers mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein. Dies könnte der CPU den Anschluss an Remote-Netzwerke in Reichweite des lokalen Routers 73 ermöglichen.
Abgesehen davon, dass beispielhafte Prozesse durch ein in einem Fahrzeug befindliches Fahrzeug-Computersystem ausgeführt werden, können die beispielhaften Prozesse in bestimmten Ausführungsformen durch ein Computersystem in Kommunikation mit einem Fahrzeug-Computersystem ausgeführt werden. Solch ein System kann, ohne darauf beschränkt zu sein, ein drahtloses Gerät (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein entferntes Computersystem (z. B. und ohne Einschränkung einen Server) umfassen, das durch das drahtlose Gerät verbunden ist. Zusammen können solche Systeme als fahrzeugassoziierte Computersysteme (VACS für engl. vehicle associated computing systems) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACSs in Abhängigkeit von der jeweiligen Implementierung des Systems bestimmte Abschnitte eines Prozesses ausführen. Als ein Beispiel und ohne Einschränkung ist es dann, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einem gekoppelten drahtlosen Gerät aufweist, wahrscheinlich, dass den Prozess nicht das drahtlose Gerät ausführt, da das drahtlose Gerät Informationen nicht an und von sich selbst „senden und empfangen“ würde. Für einen Durchschnittsfachmann ist zu erkennen, wann es unangebracht ist, ein bestimmtes VACS auf eine bestimmte Lösung anzuwenden. Bei allen Lösungen ist vorgesehen, dass wenigstens das Fahrzeug-Computersystem (VCS für engl. vehicle computing system), das sich innerhalb des Fahrzeugs befindet, die beispielhaften Prozesse selbst ausführen kann.
In jeder der beispielhaften Ausführungsformen, die hierin erörtert werden, wird ein veranschaulichendes, nicht einschränkendes Beispiel eines Prozesses dargestellt, der von einem Computersystem durchgeführt werden kann. In Bezug auf jeden Prozess ist es möglich, dass das Computersystem, das den Prozess ausführt, für den beschränkten Zweck des Ausführens des Prozesses als ein Spezialprozessor zum Durchführen des Prozesses konfiguriert wird. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden, sondern sie sind als Beispiele von Typen von Prozessen zu verstehen, die zum Erreichen von Elementen der Erfindung durchgeführt werden können. Es können Schritte zu den beispielhaften Prozessoren zusätzlich hinzugefügt oder davon entfernt werden, wie gewünscht.
Im veranschaulichenden Beispiel, das in 2 gezeigt wird, ist ein EDR-Überwachungsprozess dargestellt. In den meisten EDR-Auslösesituationen werden die von der EDR gespeicherten Daten verworfen, da sich ein tatsächlicher Unfall, der die Verwendung der EDR-Daten erfordert, nicht ereignet. Wenn zum Beispiel, ohne Einschränkung, ein Fahrer eine Vollbremsung eines Fahrzeugs durchführt, kann dieser plötzliche Stillstand oder eine plötzliche Nickbewegung des Fahrzeugs das EDR-System auslösen.
Da es wünschenswert ist, Daten vor einem tatsächlichen Unfall zu sammeln, beginnt das EDR-System häufig an einem bestimmten Punkt vor einem Unfall mit dem Aufzeichnen. Da es unmöglich ist, zu wissen, wann sich ein tatsächlicher Unfall ereignet, beginnt das EDR-System im Allgemeinen mit dem Aufzeichnen, wenn ein Vorläuferereignis eintritt, das auf einen potenziellen Unfall hinweist. Die könnte, ohne darauf beschränkt zu sein, ein Außer-Kontrolle-geraten des Fahrzeugs, schnelle Entschleunigung, Nickbewegung des Fahrzeugs über einen bestimmten Winkel hinaus oder andere Ereignisse umfassen, die darauf hinweisen, dass ein Unfall bevorsteht.
Wenn das Vorläuferereignis nicht zu einem Unfall führt, verwirft die EDR die aufgezeichneten Daten im Allgemeinen einfach, da kein Unfall erkannt wurde und keine Daten benötigt werden, um die mögliche Ursache des Unfalls zu analysieren. In den beispielhaften Ausführungsformen ist es jedoch wünschenswert, die EDR-Daten zur künftigen Analyse zu bewahren.
Durch Verwenden von gespeicherten EDR-Daten können Flottenbetreiber sagen, welche Fahrer oder Fahrzeuge in unmittelbare Nähe von möglichen Unfällen geraten. Das heißt, die Betreiber können bestimmen, welche Fahrer oder Fahrzeuge beinahe Unfälle verursachen oder in Unfälle verwickelt werden, selbst wenn sich tatsächlich keine Unfälle ereignen.
Außerdem können durch Speichern und Analysieren von EDR-Daten Bedingungen, die zu Vor-Unfall-Auslösern führen, leichter beobachtet werden. Wenn zum Beispiel Abnutzung von Bremsen zu Fahrzeugen mit hohen EDR-Auslösern führt, kann dies leichter beobachtet werden, wenn andere zusätzliche EDR-Daten gespeichert werden, als wenn sich ein tatsächlicher Unfall ereignet.
Im veranschaulichenden Beispiel, das in 2 dargestellt ist, überwacht der Prozess den Start des EDR-Systems 201. Wie bereits erwähnt, kann dies zum Beispiel ein beliebiges Ereignis oder ein beliebiger Fahrzeugzustand sein, das/der das EDR-System veranlasst, mit dem Aufzeichnen von Daten zu beginnen. Solange das EDR-System nicht mit dem Aufzeichnen von Daten begonnen hat 203, fährt der Prozess fort, auf den Beginn des Aufzeichnungszustands zu überwachen. Sobald der Aufzeichnungszustand ausgelöst wurde, geht der Prozess weiter.
In Bezug auf die beispielhaften Ausführungsformen, die in dieser Figur beschrieben werden, ist zu erwähnen, dass ein Universalprozessor zum Zwecke des Ausführens einiger oder aller der hierin dargestellten beispielhaften Verfahren vorübergehend als ein Spezialprozessor aktiviert werden kann. Beim Ausführen von Code, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor bis zum Zeitpunkt des Abschlusses des Verfahrens vorübergehend in einen Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann im angemessenen Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor funktioniert, den Prozessor veranlassen, als Spezialprozessor zu fungieren, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variante davon bereitgestellt wird.
Zu dem Zeitpunkt, zu dem der Aufzeichnungszustand in diesem veranschaulichenden Beispiel beginnt, werden Betreiberdaten gespeichert 205. Diese Daten können verwendet werden, um eine Neigung eines bestimmten Betreibers zum Auslösen von EDR-Aufzeichnungszuständen zu beurteilen. Solch eine Analyse kann für einen Flottenverwalter beim Überprüfen von Personal nützlich sein. Außerdem werden die Umgebungsdaten gespeichert, die von Fahrzeugsensoren gemessen werden und von externen Anbietern erhältlich sind. Zum Beispiel können ohne Einschränkung Niederschlagszustände, Temperaturen, Fahrbahnreibungsbedingungen und andere Umgebungsdaten überwacht werden, um zu analysieren, welche Umgebungsdaten üblicherweise einen EDR-Aufzeichnungszustand (und demnach einen möglichen Unfall) auslösen oder zur Auslösung desselben beitragen.
Zu diesem Zweitpunkt werden auch Fahrzeugzustandsdaten gespeichert 207, damit Fahrzeugzustände überwacht werden können. Dies kann helfen, zu bestimmen, welche Fahrzeugzustände (niedrige Kraftstoffreserve, niedriger Reifendruck, unausgeglichene Ladung usw.) typischerweise zum Beginn von EDR-Aufzeichnung führen könnten.
Wenn ein ernstliches Ereignis (z. B. ein Unfall) eintritt 209, kann der Prozess dann alle aufgezeichneten Daten zur Verwendung durch Techniker zur Nach-Unfall-Analyse sperren 213. Dies ist ähnelt der aktuellen Funktion der EDR, wobei ein Unfall die Bewahrung von aktuellen EDR-Daten bewirkt.
Wenn kein ernstliches Ereignis vorliegt, aber die EDR-Bedingungen zum Aufzeichnen weiterhin andauern 215, fährt der Prozess fort, alle entsprechenden Zustandsdaten aufzuzeichnen, bis keine EDR-Aufzeichnungsbedingungen mehr vorliegen oder bis ein ernstliches Ereignis eintritt.
In den aktuellen EDR-Systemen löscht das System die Daten, sobald keine Aufzeichnungsbedingungen mehr vorliegen, wodurch eine Analyse der Daten in Nicht-Unfall-Situationen verhindert wird. In den beispielhaften Ausführungsformen speichert der Prozessor, sobald das EDR-System mit dem Aufzeichnen der Daten aufhört, jedoch Daten zum späteren Hochladen derselben auf ein Remote-System zur Analyse, selbst wenn kein ernstliches Ereignis eingetreten ist.
Falls oder wenn das lokale Aufzeichnungssystem zum Beispiel durch einen Fahrzeugcomputer unter Verwendung einer drahtlose Verbindung mit einem drahtlosen Telefon zum Herstellen einer Verbindung zum Remote-Server verbunden ist, lädt der Prozess die Daten auf den Remote-Server hoch 223. Wenn keine Verbindung hergestellt wird 219, kann der Prozess eine Zeit lang versuchen, eine Verbindung herzustellen 221. Wenn noch immer keine Verbindung hergestellt wird, kann der Prozess wieder zum Überwachen und Aufzeichnen zurückkehren und die Daten zu einem zukünftigen Zeitpunkt hochladen, wenn eine Verbindung hergestellt wird.
Im veranschaulichenden Beispiel, das in 3 gezeigt wird, ist ein Fahrerüberwachungsprozess dargestellt. In diesem Beispiel können Fahrerzustände und Fahrzeugzustände überwacht werden, um zu bestimmen, ob eine EDR-Auslösebedingung bevorsteht. Basierend auf den beobachteten Auslösern zur EDR-Aufzeichnung (entweder allgemein oder spezifisch für diesen Fahrer/dieses Fahrzeug) kann der Prozess Fahrzeugzustandsänderungen beobachten und bestimmen, ob ein Beginn einer EDR-Bedingung wahrscheinlich ist.
In Bezug auf die beispielhaften Ausführungsformen, die in dieser Figur beschrieben werden, ist zu erwähnen, dass ein Universalprozessor zum Zweck des Ausführens einiger oder aller der hierin dargestellten beispielhaften Verfahren vorübergehend als ein Spezialprozessor aktiviert werden kann. Beim Ausführen von Code, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor bis zum Zeitpunkt des Abschlusses des Verfahrens vorübergehend in einen Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann im angemessenen Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor funktioniert, den Prozessor veranlassen, als Spezialprozessor zu fungieren, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variante davon bereitgestellt wird.
In diesem veranschaulichenden Beispiel identifiziert der Prozessor einen Betreiber 303, Umgebungsvariablen 305 und Fahrzeugzustände 307, sobald das Fahrzeug gestartet ist 301. Diese Daten werden zum Vergleich mit bekannten variablen Bedingungen verwendet, die den Beginn von EDR-Aufzeichnungsbedingungen bewirken (mögliche bevorstehende Unfälle identifizieren) können.
Außerdem werden in diesem veranschaulichenden Beispiel Variablen geladen 309, die den Beginn von EDR-Aufzeichnungsbedingungen bewirken können. Diese können allgemeine Variablen (z. B. Fahrzeuggeschwindigkeit) oder fahrer- oder fahrzeugspezifische Variablen sein. In einigen Fällen können allgemeine Variablen mit ihnen assoziierte Werte aufweisen, die auf einem Fahrer oder Fahrzeug basieren, nach welchen Werten im Allgemeinen das Eintreten von EDR-Aufzeichnungszuständen für einen spezifischen Fahrer oder ein spezifisches Fahrzeug zu beobachten ist. In anderen Fällen können die Variablen allgemeine Schwellenwerte damit assoziiert aufweisen, wonach im Allgemeinen EDR-Zustände eintreten.
Es kann zum Beispiel beobachtet werden, dass, wenn der Fahrer Joe ist, ein EDR-Zustand im Allgemeinen bei einer angehäuften Schneemenge auf der Straße von mehr als einem Zoll eintritt. So kann für diesen Fahrer eine Schneemengen-Umgebungsvariable eine Schwelle von einem Zoll aufweisen. Es kann außerdem beobachtet werden, dass über 128 Kilometer pro Stunde (achtzig Meilen pro Stunde) alle Fahrer häufiger EDR-Zustände erfahren, so dass eine Geschwindigkeitsvariable eine Grenze von 128 km/h damit assoziiert aufweisen kann.
Sobald alle Kennungen und Variablen (zusammen mit den entsprechenden Schwellen) geladen wurden, kann der Prozess mit dem Überwachen von Fahrparametern 311 beginnen. Dies kann sowohl die Fahrzustände des Fahrzeugs als auch Umgebungsbedingungen betreffen, unter welchen das Fahrzeug fährt. Der Prozess kann zum Beispiel außerdem Fahreraufmerksamkeitszustände überwachen, wenn solch eine Überwachung verfügbar ist.
Jeder einzelne der überwachten Parameter kann mit den Schwellen verglichen werden, die mit den Gefahrenzustandsvariablen assoziiert sind 313. Diese Daten können verwendet werden, um zu bestimmen, ob eine Variable oder Variablen auf den wahrscheinlichen Beginn eines Vor-Unfall-EDR-Aufzeichnungszustands hinweist bzw. hinweisen. Wenn eine Übereinstimmung zwischen den Gefahrenzustandsparametern und den Variablen vorliegt 315, kann der Prozess dem Fahrer die Variablenschwellen melden 317, die überschritten wurden (zum Beispiel ohne Einschränkung „Geschwindigkeit über einer Sicherheitsschwelle“ oder „Schneeanhäufung kann das Fahren gefährlich machen“). Wenn der Fahrer die Variable kontrollieren kann, kann der Fahrer in Reaktion den Zustand unter die Schwelle bringen, obwohl in manchen Fällen das Beste, was der Fahrer tun kann, ist, weitere Vorsichtmaßnahmen zu treffen, da der Fahrer tatsächlich das Wetter nicht ändern kann.
4 stellt ein veranschaulichendes Beispiel eines cloudbasierten Prozesses zur Datenanalyse und zum EDR-Aufzeichnungsstart dar. In diesem veranschaulichenden Beispiel machen mehrere Fahrzeuge Meldung an ein cloudbasiertes System, das eine Variablenanalyse durchführt und auf Wunsch EDR-Aufzeichnung anfordern kann, falls Daten für Fahrzeuge in bestimmten Zuständen zur weiteren Analyse gewünscht werden.
In Bezug auf die beispielhaften Ausführungsformen, die in dieser Figur beschrieben werden, ist zu erwähnen, dass ein Universalprozessor zum Zweck des Ausführens einiger oder aller der hierin dargestellten beispielhaften Verfahren vorübergehend als ein Spezialprozessor aktiviert werden kann. Beim Ausführen von Code, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor bis zum Zeitpunkt des Abschlusses des Verfahrens vorübergehend in einen Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann im angemessenen Umfang Firmware, die gemäß einem vorkonfigurierten Prozessor funktioniert, den Prozessor veranlassen, als Spezialprozessor zu fungieren, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variante davon bereitgestellt wird.
In diesem Beispiel fordert der Prozess Fahrzeugdaten von einem oder mehreren angeschlossenen Fahrzeugen an, die mit dem Remote-System in Verbindung stehen 401. Für jedes Fahrzeug, von dem Daten angefordert wurden, werden die Daten gesammelt und empfangen 403. Diese Daten können, ohne darauf beschränkt zu sein, Geschwindigkeitsdaten, Wetterdaten, Fahrerdaten und im Allgemeinen alle Daten umfassen, die beim Analysieren von wahrscheinlich bevorstehenden EDR-Zuständen nützlich wären oder die beim Analysieren von Fahrzeugbedingungen nützlich wären, die zu Fahrzeugproblemen führen.
Die gesammelten Daten können dann allgemein mit Schwellen für bekannte EDR-Anfangsbedingungen verglichen werden 405, die dazu neigen, anzuzeigen, ob das System wahrscheinlich eine Bedingung auslöst, unter welcher EDR-Aufzeichnung erfolgt, oder nicht. Die allgemeine Natur des Vergleichs hierbei bedeutet, dass die Daten mit Schwellen für alle Fahrzeuge/Fahrer oder für eine Klasse von Fahrzeugen/Fahrern verglichen werden.
Wenn basierend auf den gesammelten Daten eine Übereinstimmung festgestellt wird 407, dass ein EDR-Zustand bevorstehen kann, kann der Prozess den Fahrer warnen 409. Dies könnte in jeder geeigneten Form sein, die eine optische Warnung, eine akustische Warnung usw. umfasst, ohne darauf beschränkt zu sein. Außerdem würde eine Warnung an einen Flottenbetreiber für das spezifische Fahrzeug ausgegeben, falls gewünscht.
Der Prozess kann EDR-Aufzeichnung außerdem zu dem Zeitpunkt anweisen, zu dem die Bedingung erkannt wird 411. Dies kann helfen, Daten zu bewahren, um zu zeigen, welche Bedingungen nach der Warnung eintraten, und helfen zu bestimmen, ob der Fahrer Vorbeugemaßnahmen traf oder weiterhin auf die gleiche Weise fuhr. Die Daten könnten auch zum Vergleich mit früher beobachteten Daten verwendet werden, um zu zeigen, ob die Ausgabe der Warnung geeignet war und/oder die Wahrscheinlichkeit eines tatsächlichen Unfalls reduzierte, was aus den aufgezeichneten EDR-Daten beobachtet werden kann. Da der tatsächliche EDR-Beginn durch die Ausgabe der Warnung vermieden werden kann, kann es nützlich sein, zu sehen, bis zu welchem Grad die tatsächlichen Verhaltensänderungen erfolgten.
Neben dem allgemeinen Vergleich kann der Prozess die empfangenen Daten auch mit bekannten Variablen vergleichen, die den fahrerspezifischen Schwellen entsprechen, welche eine EDR-Aufzeichnung für einen spezifischen Fahrer oder ein spezifisches Fahrzeug auslösen 413. Dies kann helfen, wahrscheinlich bevorstehende EDR-Aufzeichnungszustände für einen spezifischen Fahrer oder ein spezifisches Fahrzeug zu bestimmen.
Wenn eine Übereinstimmung vorliegt 415, gibt der Prozess wieder eine Meldung aus 417. Die Meldung kann an den entsprechenden Beteiligten und in der oder den geeigneten Form(en) erfolgen. Neben der Meldungsausgabe kann der Prozess wieder eine EDR-Aufzeichnung anweisen 419, um die Fahrerreaktion auf die Meldung zu beurteilen.
Wenn in diesem Prozess keine EDR-Aufzeichnung angewiesen wurde 421, endet der Prozess. Wenn die EDR-Aufzeichnung jedoch angewiesen wurde, fordert der Prozess die aufgezeichneten EDR-Daten von dem bzw. den entsprechenden Fahrzeug(en) an und speichert/analysiert die Daten, soweit erforderlich, sobald die Daten empfangen wurden.
Es folgt eine Anzahl von EDR-bezogenen Szenarios, welche die EDR-Daten und bewahrte Variablen verwenden. Diese dienen lediglich Veranschaulichungszwecken und sollen den Schutzbereich der Erfindung in keiner Weise einschränken.
Beispiel 1:

Aktoren: Telematik-Steuereinheit (TCU)
Vorbedingungen: Die TCU ist wach und in Betrieb, die TCU ist so konfiguriert, dass sie 1-Draht mit Fahrer-ID unterstützt.
Beschreibung des Szenarios: Die TCU überwacht 1-Draht-Netz kontinuierlich auf Verbindung einer Fahreridentifikationsvorrichtung für eine vorbestimmte und konfigurierbare Dauer nach dem Übergang der Zündung in eine BETRIEB/EIN-Position. Die TCU sendet eine Meldung und Daten, wenn die Fahreridentifikationsvorrichtung gefunden wird.

Prozess:

1) Nach dem Übergang der Zündung auf BETRIEB/EIN aktiviert die TCU einen Zeitgeber fester und konfigurierbarer Dauer und überwacht kontinuierlich auf die Anwendung einer Fahreridentifikationsvorrichtung im 1-Draht-Netz.
2) Wenn die TCU die Verbindung einer 1-Draht-Fahreridentifikationsvorrichtung erkennt, gibt die TCU eine Fahrer-ID-Meldung aus und erzeugt die folgenden Datenbündel: 1-Draht-, VSTAT- und GPS-Info-Bündel.
3) Die TCU sendet die Meldung und die Daten an den ESB oder den Webdienst.
4) Wenn die TCU eine Fahreridentifikationsvorrichtung nicht vor dem Ablauf des Dauerzeitgebers liest oder erkennt, gibt die TCU eine Fahrer-ID-Fehler-Meldung aus, die außerdem VSTAT- und GPS-Info-Bündel umfasst.
5) Die TCU gibt die Fehlermeldung und die Datenbündel an den ESB oder den Webdienst aus.

Nachbedingungen: Die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 2

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist wach und in Betrieb, die TCU ist so konfiguriert, dass sie 1-Draht mit Temperatursensor unterstützt.
Beschreibung des Szenarios: Bei einer vordefinierten und konfigurierbaren Kadenz fordert die TCU 1-Draht-Temperatursensoren periodisch auf, Daten bereitzustellen. Die TCU gibt dann eine Meldung aus und sendet Daten an den ESB oder den Webdienst. Die TCU sendet eine Fehlermeldung, wenn ein Temperatursensor auf eine Aufforderung nicht antwortet.

Schritte:

1) Die TCU fordert Temperatursensoren, die mit dem 1-Draht-Netz verbunden sind, periodisch auf, Temperaturdaten bereitzustellen. Die Aufforderungen werden bei einer vorbestimmten und konfigurierbaren Rate ausgegeben.
2) Bei Empfang einer Antwort vom Temperatursensor erzeugt die TCU eine Meldung und sammelt oder bildet die folgenden Datenbündel: 1-Draht-, VSTAT- und GPS-Info-Bündel.
3) Die TCU gibt die Meldung und die Datenbündel an den Webdienst oder ESB aus.
4) Bei Nichtempfang einer Antwort von einem der an das 1-Draht-Netz angeschlossenen Temperatursensoren nach einer konfigurierbaren Anzahl von Wiederholungsversuchen gibt die TCU eine Fehlermeldung aus und bezieht VSTAT- und GPS-Info-Bündel ein.
5) Die TCU sendet die Fehlermeldung und die Datenbündel an den Webdienst oder ESB.

Beispiel 3

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist wach und in Betrieb, die TCU ist so konfiguriert, dass sie AKTIV ist, die TCU ist so konfiguriert, dass sie Ausgangsereignisse erkennt.
Beschreibung des Szenarios: Die TCU überwacht kontinuierlich den Status der externen festverdrahteten Ausgänge während aller TCU-Betriebs- und -Leistungsmodi. Wenn der TCU vom ESB oder dem Webdienst befohlen wird oder sie intern bestimmt, dass ein Ausgang funktionieren muss. Die TCU sendet die Meldung und die Daten an den Webdienst.

Schritte:

1) Bei Empfang eines vom Webdienst/ESB ausgegebenen OTA-Befehls oder der internen Entscheidung durch die TCU zum Aktivieren oder Deaktivieren eines Ausgangs. Die TCU bildet eine Ausgangsmeldung und sammelt die folgenden Datenbündel: VSTAT- und GPS-Info-Bündel.
2) Die TCU gibt die Meldung und die Datenbündel an den Webdienst oder ESB aus.
3) Bei Versagen der TCU, die TCU zu aktivieren, wie gefordert, gibt die TCU eine Ausgangsfehlermeldung und VSTAT- u. GPS-Info-Bündel aus.
4) Die TCU gibt die Fehlermeldung und die Bündel an den Webdienst/ESB aus.

Nachbedingungen: Die Ausgangsmeldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 4

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist wach und betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist (zum Bereitstellen von Meldungen konfiguriert ist... inaktiv: die TCU stellt keine Meldungen bereit), die TCU ist so konfiguriert, dass sie Onboard-Warnungen bereitstellt.
Beschreibung des Szenarios: Die TCU gibt eine Meldung an den Webdienst aus, wenn die TCU eine Onboard-Warnung an den Betreiber ausgeführt hat.

Schritte:

1) Bei Ausführung einer Onboard-Warnung gibt die TCU eine Meldung an den ESB oder den Webdienst aus.
2) Die TCU bildet die folgenden Datenbündel: VSTAT- u. GPS-Info-Bündel.
3) Bei Versagen der TCU, die Onboard-Warnung auszuführen, wie gefordert, gibt die TCU eine Onboard-Warnung-Fehler-Meldung und VSTAT- u. GPS-Info-Bündel aus.
4) Die TCU gibt die Meldung und die Bündel an den Webdienst/ESB aus.

Nachbedingungen: Die Onboard-Warnmeldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 5

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Die TCU überwacht kontinuierlich den Status aller externen festverdrahteten Eingänge in die TCU während aller TCU-Betriebs- und -Leistungsmodi. Wenn die TCU eine Zustandsänderung erkennt, die darauf hinweist, dass eine externe Vorrichtung, die an den Eingangsanschluss der TCUs angeschlossen ist, aktiviert oder deaktiviert wurde, sendet die TCU eine Meldung und Daten an den Webdienst.

Schritte:

1) Bei Erkennen einer Zustandsänderung an einem festverdrahteten Eingang in die TCU gibt die TCU eine Warnung aus und sammelt die folgenden Datenbündel: VSTAT und GPS-Info.
2) Die TCU gibt die Meldung und die Datenbündel an den Webdienst oder ESB aus.

Nachbedingungen: Ein Eingangsmeldungscode und Fahrzeugschnappschussdaten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.

Beispiel 6

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist wach und in Betrieb, der Fahrzeugzündstatus ist „Eingeschaltet“, „Zubehör-Ein-Modus“ oder „Betrieb“, die TCU wurde so konfiguriert, dass sie Fahrersicherheitsmeldungen bereitstellt.
Beschreibung des Szenarios: Die TCU überwacht den HSCAN-Netzverkehr des Fahrzeugs oder führt interne Berechnungen oder Vergleiche durch, wenn die TCU bestimmt hat, dass eine Fahrersicherheitsbedingung oder ein Fahrersicherheitsereignis begonnen oder geendet hat. Die TCU erzeugt eine Fahrersicherheitsmeldung und benachrichtigt den Dienstanbieter bei Beginn und Ende jedes Ereignisses.

Schritte:

1) Die TCU ist so konfiguriert, dass sie Fahrersicherheitsmeldungen bereitstellt.
2) Gemäß Anforderungen, wenn die TCU den Beginn oder das Ende einer sicherheits- oder verhaltensbezogenen Fahrbedingung erkennt. Die TCU erzeugt eine Fahrersicherheitsmeldung.
3) Die TCU sammelt Fahrersicherheits-, VSTAT- u- GPS-Info-Bündel.
4) Die TCU erzeugt einen Meldungscode und die Datenbündel und gibt einen Datensatz an den ESB oder den Webdienst aus.

Nachbedingungen: Die TCU ist bereit, eine andere Meldung zu erkennen, die TCU hat die Fahrersicherheitsmeldung gesendet, die TCU hat das VSTAT-Bündel gesendet, die TCU hat das GPS-Info- u. Fahrersicherheitsbündel gesendet.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 7

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, On- und Offboard-Clients sind angeschlossen, die TCU ist so konfiguriert, dass sie Ausgabevorrichtungen unterstützt.
Beschreibung des Szenarios: Der Webdienst gibt einen Befehl an die TCU aus, einen festverdrahteten TCU-Ausgang zu aktivieren oder deaktivieren. Die TCU führt den Befehl aus und antwortet mit einer Antwort, die angibt, ob der Befehl erfolgreich ausgeführt wurde.

Schritte:

1) Der Webdienst gibt einen Befehl aus, um die TCU aufzufordern, einen Ausgang zu aktivieren oder deaktivieren.
2) Die TCU empfängt den Befehl und führt die angeforderten Prozeduren aus, um den TCU-Ausgang zu aktivieren oder deaktivieren.
3) Nach der Ausführung des Befehls oder der versuchten Ausführung des Befehls gibt die TCU eine Antwortnachricht an den Webdienst aus, siehe Anwendungsfall bzgl. Ausgangsmeldung.

Nachbedingungen: Die TCU ist bereit, eine andere Meldung oder einen anderen Befehl zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 8

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, On- und Offboard-Clients sind angeschlossen, die TCU ist so konfiguriert, dass sie Onboard-Warnungen unterstützt.
Beschreibung des Szenarios: Der Webdienst gibt einen Befehl an die TCU aus, eine Onboard-Warnung an einen Betreiber zu aktivieren. Die TCU führt den Befehl aus und antwortet mit einer Antwort, die angibt, ob der Befehl erfolgreich ausgeführt wurde.

Schritte:

1) Der Webdienst gibt einen Befehl aus, um die TCU aufzufordern, eine Onboard-Warnung auszugeben oder zu beenden.
2) Die TCU empfängt den Befehl und führt die angeforderten Prozeduren aus, um die Onboard-Warnung zu aktivieren oder deaktivieren.
3) Nach der Ausführung des Befehls oder der versuchten Ausführung des Befehls gibt die TCU eine Antwortnachricht an den Webdienst aus, siehe Anwendungsfall bzgl. Onboard-Warnmeldung.

Nachbedingungen: Die TCU hat die Warnung ausgeben und den WEB-Diensten geantwortet, ob es getan wurde oder nicht.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 9

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, On- und Offboard-Clients sind angeschlossen.
Beschreibung des Szenarios: Der Webdienst hat einen Diagnosebefehl zum Ausführen eines Diagnosedienstes an die TCU ausgeben. Die TCU führt den Befehl aus und antwortet mit einer Antwort, die den Anforderungsstatus und die erforderlichen Daten angibt.

Schritte:

1) Der Webdienst gibt einen Befehl aus, um die TCU aufzufordern, einen Diagnosedienst auszuführen.
2) Die TCU führt den in Diagnosedienst aus, der in einem DiagDataFromCloud-Datenbündel enthalten ist, das vom Webdienst oder dem ESB gesendet wird.
3) Nach der Ausführung der Dienstanforderung oder der versuchten Ausführung der Dienstanforderung sammelt die TCU die Diagnoseantwort von der Ziel-ECU.
4) Die TCU packt die Diagnoseantwort(en) in ein DiagDataFromVehicle-Datenbündel.
5) Die TCU gibt eine Diagnosedatenmeldung mit dem DiagDataFromVehicle-Datenbündel an den Webdienst aus.

Nachbedingungen: Die TCU hat dem Webdienst mit Erfolg oder Misserfolg des Webbefehls geantwortet, die TCU hat die angeforderten Daten an den Webdienst übermittelt, die TCU ist bereit, eine andere Meldung oder einen anderen Befehl zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 10

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, On- und Offboard-Clients sind angeschlossen.
Beschreibung des Szenarios: Der Webdienst hat einen Diagnosebefehl zur wiederholten Ausführung eines Diagnosedienstes an die TCU ausgeben. Die TCU führt den Befehl aus und antwortet mit einer Antwort, die den Status der Anforderung und angeforderten Daten angibt. Die TCU führt den Befehl mit der spezifizierten Kadenz aus, bis die TCU einen Befehl zum Beenden der Dienstanforderung empfängt.

Schritte:

1) Der Webdienst gibt einen Befehl aus, um die TCU aufzufordern, einen Diagnosedienst auszuführen.
2) Die TCU führt den in Diagnosedienst aus, der in einem DiagDataFromCloud-Datenbündel enthalten ist, das vom Webdienst oder dem ESB gesendet wird.
3) Nach der Ausführung der Dienstanforderung oder der versuchten Ausführung der Dienstanforderung sammelt die TCU die Diagnoseantwort von der Ziel-ECU.
4) Die TCU packt die Diagnoseantwort(en) in ein DiagDataFromVehicle-Datenbündel.
5) Die TCU gibt eine Diagnosedatenmeldung mit dem DiagDataFromVehicle-Datenbündel an den Webdienst aus.
6) Die TCU fährt mit der Wiederausführung des Diagnosebefehls mit der definierten Kadenz fort, wie vom ESB angewiesen, der den Diagnosebefehl ausgab.
7) Die TCU fährt mit der Ausführung der Diagnoseanforderung fort, bis ihr vom Webdienst oder dem ESB befohlen wird, die Diagnoseanforderungen zu beenden.

Nachbedingungen: Die TCU hat dem Webdienst mit Erfolg oder Misserfolg des Webbefehls geantwortet, die TCU hat die angeforderten Daten an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung oder einen anderen Befehl zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 11

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, On- und Offboard-Clients sind angeschlossen, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Der TCU wurde vom ESB die Durchführung einer Diagnosedienstanforderung an Onboard-Modulen befohlen, oder sie hat diese automatisch durchgeführt. Die TCU hat den angeforderten oder vorgeschriebenen Dienst ausgeführt und sendet die angeforderten Diagnosedaten zurück.

Schritte:

1) Die TCU hat die angeforderte oder vorgeschriebene Diagnosedienstanforderung durchgeführt.
2) Die TCU hat eine Diagnoseantwort von den Ziel-ECUs empfangen.
3) Die TCU packt die Diagnoseantworten wieder in ein DiagDataFromVehicle-Bündel und bildet VSTAT- und GPS-Info-Bündel.
4) Die TCU gibt eine Diagnosedatenmeldung und die Bündel an den Webdienst/ESB aus.

Beispiel 12

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, On- und Offboard-Clients sind angeschlossen.
Beschreibung des Szenarios: Der Webdienst hat einen Annullierungsbefehl zum Beenden des angeforderten Diagnosedienstes an die TCU ausgegeben. Die TCU führt den Befehl aus und antwortet mit einer Antwort, die den Status der Anforderung und angeforderten Daten angibt.

Schritte:

1) Der Webdienst gibt einen Befehl aus, um die TCU aufzufordern, einen zuvor angeforderten Diagnosedienst zu beenden.
2) Die TCU führt die Befehle aus.
3) Nach der Ausführung des Befehls oder der versuchten Ausführung des Befehls gibt die TCU eine Diagnosedatenmeldung an den Webdienst aus.

Beispiel 13

Schritte:

Beispiel 14

Schritte:

Nachbedingungen: Die TCU hat die Warnung ausgeben und den Webdiensten geantwortet, ob es getan wurde oder nicht.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 15

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, On- und Offboard-Clients sind angeschlossen.
Beschreibung des Szenarios: Der Webdienst hat einen Diagnosebefehl zum Ausführen eines Diagnosedienstes an die TCU ausgeben. Die TCU führt den Befehl aus und antwortet mit einer Antwort, die den Status der Anforderung und angeforderten Daten angibt.

Schritte:

Beispiel 16

Schritte:

Beispiel 17

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist wach und in Betrieb, On- und Offboard-Clients sind angeschlossen, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Der TCU wurde vom ESB die Durchführung einer Diagnosedienstanforderung an Onboard-Modulen befohlen, oder sie hat diese automatisch durchgeführt. Die TCU hat den angeforderten oder vorgeschriebenen Dienst ausgeführt und sendet die angeforderten Diagnosedaten zurück.

Schritte:

Beispiel 18

Schritte:

Beispiel 19

Aktoren: TCU-Modul
Vorbedingungen: Der Fahrzeugzündungsstatus ist „Eingeschaltet“, „Zubehör-Ein-Modus“ oder „Betrieb“, die TCU wurde so konfiguriert, dass sie Fahrerwarnmeldungen bereitstellt, der Antriebsstrang läuft, alle gemäß FMVSS erforderlichen Lampenprüfungen wurden durchgeführt.
Beschreibung des Szenarios: Die TCU hat bestimmt, dass eine Fahrerwarnung für den Fahrer angezeigt wird. Die TCU erzeugt eine Fahrerwarnmeldung und benachrichtigt den Dienstanbieter bei Beginn und Ende jeder Warnung, die dem Fahrer angezeigt wird.

Schritte:

1) Die TCU ist so konfiguriert, dass sie Fahrerwarnmeldungen bereitstellt.
2) Wenn die TCU eine Zustandsänderung oder Pegeländerung bei irgendeiner überwachten Warnung erkennt. Die TCU gibt eine Fahrerwarnmeldung aus.
3) Die TCU sammelt ein VSTAT- u. GPS-Info-Bündel.
4) Die TCU stellt ein FAHRERWARNUNGS-Bündel zusammen.
5) Die TCU stellt ein FAHRTBERICHTS-Bündel zusammen.
6) Die TCU erzeugt eine Meldung und gibt sie mit den Datenbündeln an den ESB oder den Webdienst aus.

Nachbedingungen: Die TCU ist bereit, eine andere Warnung zu erkennen, die TCU hat die Fahrerwarnmeldung ausgegeben.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 20

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Die TCU überwacht die Fahrzeuggeschwindigkeit. Wenn die Fahrzeuggeschwindigkeit für eine konfigurierbare Zeitdauer über eine konfigurierbare Fahrzeuggeschwindigkeitseinstellung angestiegen ist. Die TCU gibt eine BEWEGUNG-NACH-STOPP-Meldung aus.

Schritte:

1) Die TCU bestimmt die Fahrzeuggeschwindigkeit.
2) Wenn die Fahrzeuggeschwindigkeit > GESTOPPT-GESCHWINDIGKEITS-Konfiguration, dann startet die TCU den Nach-Stopp-Dauerzeitgeber.
3) Wenn der Nach-Stopp-Dauerzeitgeber > NACH-STOPP-ZEIT-Konfiguration, dann registriert die TCU die BEWEGUNG-NACH-STOPP-Warnung.
4) Die TCU sammelt VSTAT- u. GPS-Info.
5) Die TCU sammelt ein FAHRTBERICHTS-Bündel.
6) Die TCU sammelt ein FAHRERWARNUNGS-Bündel.
7) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, Datenbündeln und Korrelations-ID als Nutzdaten aus.
8) Die TCU gibt die Datensatzmeldung und die Datenbündel an den
Webdienst aus.

Nachbedingungen: Die BEWEGUNG-NACH-STOPP-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 21

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Die TCU überwacht die Fahrzeuggeschwindigkeit. Wenn die Fahrzeuggeschwindigkeit für eine konfigurierbare Zeitdauer unter eine konfigurierbare Fahrzeuggeschwindigkeitseinstellung gefallen ist. Die TCU gibt eine GESTOPPT-Meldung aus.

Schritte:

1) Die TCU bestimmt die Fahrzeuggeschwindigkeit.
2) Wenn die Fahrzeuggeschwindigkeit < GESTOPPT-GESCHWINDIGKEITS-Konfiguration, dann startet die TCU den Gestoppt-Dauerzeitgeber.
3) Wenn der Gestoppt-Dauerzeitgeber > STOPPZEIT-Konfiguration, dann registriert die TCU den GESTOPPT-Meldungscode.
4) Die TCU sammelt VSTAT- u. GPS-Info.
5) Die TCU sammelt ein FAHRTBERICHTS-Bündel.
6) Die TCU sammelt ein FAHRERWARNUNGS-Bündel.
7) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, Datenbündeln und Korrelations-ID als Nutzdaten aus, die TCU gibt die Meldungen und Datenbündel an den Webdienst aus.

Nachbedingungen: Die GESTOPPT-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 22

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist, die Zeit des Fahrtberichts-Zeitzählers ist abgelaufen.
Beschreibung des Szenarios: Wenn der konfigurierbare Zeitzähler für konfigurierbare Fahrtberichts- oder Hauptmeldungen der TCU abgelaufen ist. Die TCU registriert eine Fahrtberichtsmeldung, sammelt und sendet dann den Meldungscode und VSTAT- u. GPS-Info-Daten an den Webdienst.

Schritte:

1) Das Limit des Zeitgebers für periodische Fahrtberichts-(Haupt)meldungen der TCU wurde überschritten oder ist abgelaufen.
2) Die TCU registriert die Fahrtberichts(15 min)-Meldung.
3) Die TCU sammelt VSTAT- u. GPS-Info.
4) Die TCU sammelt ein FAHRTBERICHTS-Bündel.
5) Die TCU sammelt ein FAHRERWARNUNGS-Bündel.
6) Die TCU setzt den Zeitgeber oder Zähler zurück.
7) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, Datenbündel und Korrelations-ID als Nutzdaten aus.
8) Die TCU gibt die Datensatzmeldung und die Datenbündel an den
Webdienst aus.

Nachbedingungen: Die periodische Fahrtberichtsmeldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 23

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist, Neben- oder Kurzzeitzähler ist abgelaufen.
Beschreibung des Szenarios: Wenn der konfigurierbare Neben-Zeitgeber der TCU abgelaufen ist. Die TCU registriert eine Nebenereignismeldung, sammelt und sendet dann den Meldungscode und VSTAT- u. GPS-Info-Daten an den Webdienst.

Schritte:

1) Der auf der konfigurierbaren Fahrzeugstatusmeldezeit basierte Zähler der TCU ist abgelaufen.
2) Die TCU registriert den Nebenmeldungscode.
3) Die TCU sammelt VSTAT- u. GPS-Info-Bündel.
4) Die TCU setzt den Zähler oder Zeitgeber zurück.
5) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, Datenbündel und Korrelations-ID als Nutzdaten aus.
6) Die TCU gibt die Datensatzmeldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Die Fahrzeugstatus(2 min)-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 24

Schritte:

Beispiel 25

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Die TCU bestimmt, dass der Antriebsstrang in einen aktivierten oder Betriebszustand übergegangen ist und sendet eine EngON(MtrEIN)-Meldung mit Datenbündeln.

Schritte:

1) Die TCU bestimmt den Motor-Antriebsstrangzustand als aktiv.
2) BEV u. HEV: Die TCU bestimmt den Motorzustand als aktiv.
3) Die TCU gibt die EngOn-Meldung aus.
4) Die TCU sammelt VSTAT- u. GPS-Info.
5) Die TCU sammelt ein FAHRTBERICHTS-Bündel.
6) Die TCU sammelt ein FAHRERWARNUNGS-Bündel.
7) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, Datenbündeln und Korrelations-ID als Nutzdaten aus.
8) Die TCU gibt die Datensatzmeldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Die EngON-Meldung und die Datenbündel wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 26

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Die TCU bestimmt, dass der Antriebsstrang in einen Aus- oder Nicht-Betriebszustand übergegangen ist. Die TCU sendet eine EngOFF(MtrAUS)-Meldung mit Datenbündeln.

Schritte:

1) Die TCU bestimmt, dass der Motor nicht in Betrieb ist.
2) BEV u. HEV: Die TCU bestimmt, dass der Antriebsstrang auf AUS ist.
3) Die TCU gibt den EngOff-Meldungscode aus.
4) Die TCU sammelt VSTAT- u. GPS-Info.
5) Die TCU sammelt ein FAHRTBERICHTS-Bündel.
6) Die TCU sammelt ein FAHRERWARNUNGS-Bündel.
7) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, Datenbündeln und Korrelations-ID als Nutzdaten aus.
8) Die TCU gibt die Datensatzmeldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Der Motorbetriebsmodus ist der AUS- oder Nicht-Betriebszustand, der ENGOFF-Meldungscode und die Daten wurden den Webdienst gesendet, die TCU wartet darauf, zusätzliche Meldungsbedingungen zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstellen.

Beispiel 27

Aktoren: TCU-Modul
Vorbedingungen: Der Zündungsstatus ist „Betrieb“, die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Wenn das Fahrzeug aus irgendeinem anderen Betriebszustand in den Aus- oder Nicht-Betriebszustand übergeht, registriert die TCU eine IgnOff(ZdgAus)-Meldung, sammelt und sendet dann den Meldungscode und VSTAT- u. GPS-Info-Daten an den Webdienst.

Schritte:

1) Die TCU bestimmt den Zündungszustand.
2) Bei Übergang von irgendeinem anderen Zustand auf ZündungAUS sendet die TCU eine Meldung.
3) Die TCU gibt die IGNOff-Meldung aus.
4) Die TCU sammelt VSTAT- u. GPS-Info.
5) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, VSTAT u. GPS-Info und Korrelations-ID als Nutzdaten aus.
6) Die TCU gibt die Datensatzmeldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Der IgnOFF-Meldungscode und Fahrzeugschnappschuss- u. GPS-Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 28

Aktoren: TCU-Modul
Vorbedingungen: Der Zündungsstatus ist „Aus“, die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Wenn das Fahrzeug aus dem Aus- oder Nicht-Betriebszustand in irgendeinen anderen Betriebszustand übergeht, registriert die TCU eine IgnRun(ZdgBetrieb)-Meldung, sammelt und sendet dann den Meldungscode und VSTAT- u. GPS-Info-Daten an den Webdienst.

Schritte:

1) Die TCU bestimmt den Zündungszustand.
2) Bei Übergang von irgendeinem anderen Zündungszustand auf Zündung = BETRIEB oder Zubehör-Ein-Modus sendet die TCU eine Meldung.
3) Die TCU gibt den IGNrun-Meldungscode aus und sammelt VSTAT u. GPS-Info.
4) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, VSTAT u. GPS-Info und Korrelations-ID als Nutzdaten aus.
5) Die TCU gibt die Datensatzmeldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Der IgnRun-Meldungscode und VSTAT- u. GPS-Bündeldaten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Upload/Download (zellulare Verbindung), Fahrzeugsystemschnittstelle.

Beispiel 29

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist wach und im Vollleistungs- oder Niederleistungsmodus.
Beschreibung des Szenarios: Wenn die TCU Bedingungen erkennt, die darauf hinweisen, dass das GPS einen GPS-Dimensionsgrad von 3D erreicht hat. Die TCU gibt eine GPS-3D-FIX-Meldung aus.

Schritte:

1) The TCU überwacht die HSCAN-Signale, die vom GPSM-Modul bereitgestellt werden, oder äquivalente Signale, die von einer internen oder einer dedizierten GPS-Antenne bereitgestellt werden.
2) Die TCU überwacht GPS-Dimensions-Info.
3) Bei GPS_dimension = 3D fix registriert die TCU den GPS-3D-FIX-Meldungscode.
4) Die TCU sammelt VSTAT- u. GPS-Info.
5) Die TCU erzeugt einen MQTT-Datensatz mit einem entsprechenden MQTT-Header und gibt ihn mit Meldungscode, VSTAT u. GPS-Info und Korrelations-ID als Nutzdaten aus, sie gibt die Meldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Die TCU ist bereit, eine andere Meldung zu erkennen.

Beispiel 30

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie Polizeimeldungen bereitstellt, die Querbeschleunigung überschreitet 8 m/s², oder das Bremsmoment überschreitet 5000 Nm, Überwachungsvorrichtung mit gesendeter Meldung, dass das Fahrzeug in den Verfolgungsmodus eingetreten ist, die TCU ist so konfiguriert, dass sie AKTIV ist (zum Bereitstellen von Meldungen konfiguriert ist... INAKTIV: die TCU stellt keine Meldungen bereit), das Fahrzeug ist in den Verfolgungsmodus eingetreten.
Beschreibung des Szenarios: Nur Polizeifahrzeuge; die TCU ist so konfiguriert, dass sie Polizeifahrzeugoptionen unterstützt. Nachdem die TCU die Verfolgungsmodusbedingung erkannt hat, gibt die TCU eine Polizei-Verfolgungsmodusmeldung aus und fährt fort, alle 5 Sekunden Verfolgungsmodusmeldungen auszugeben, bis die Bedingungen anzeigen, dass der Verfolgungsmodus geendet hat.

Schritte:

1) Die TCU überwacht Querbeschleunigungs- und Bremsmomentdaten.
2) Wenn die Querbeschleunigung 8 m/s² überschreitet oder das Bremsmoment 5000 Nm überschreitet, gibt die TCU eine Verfolgungsmodusmeldung aus und startet einen 45-Sekunden-Zeitgeber.
3) Die TCU sammelt VSTAT- und GPS-Info-Bündel und sendet diese Bündel mit jeder Verfolgungsmodusmeldung, welche die TCU ausgibt.
4) Die TCU gibt die Meldung und die Datenbündel an den Webdienst aus.
5) Die Verfolgungsmodusmeldungen werden kontinuierlich alle 5 Sekunden mit aktualisierten VSTAT- und GPS-Info-Bündeln neu ausgegeben und an den Webdienst ausgegeben, bis der 45-Sekunden-Zeitgeber endet.
6) Wenn die TCU vor dem Ablauf des 45-Sekunden-Zeitgebers eine Querbeschleunigung von über 8 m/s² oder ein Bremsmoment von über 5000 Nm erfährt, wird der Zeitgeber zurückgesetzt und die Verfolgungsmodusmeldungen werden für weitere 45 Sekunden fortgesetzt.

Nachbedingungen: Die Polizei-Verfolgungsmodusmeldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 31

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist, die TCU ist so konfiguriert, dass sie Polizei-Funktionen unterstützt, die TCU weist einen Eingangsanschluss auf, der zum Unterstützen einer Polizeisirene ausgelegt ist.
Beschreibung des Szenarios: Nur Polizeifahrzeuge; die TCU ist so konfiguriert, dass sie Polizeifahrzeugoptionen unterstützt. Nachdem die TCU durch Überwachen von designierten und konfigurierten Eingangsanschlüssen erkannt hat, dass eine Polizeisirene aktiviert wurde, gibt die TCU eine SIRENE-EIN-Meldung an den Webdienst aus.

Schritte:

1) Die TCU hat bestimmt, dass die Polizeisirene aktiviert wurde.
2) Die TCU gibt eine SIRENE-EIN-Meldung mit Datenbündeln aus.
3) Die TCU sammelt Fahrzeugstatus- oder VSTAT- und GPS-Info-Bündel bei allen Meldungen.
4) Die TCU gibt die Meldung und den Datensatz an den Webdienst aus.

Nachbedingungen: Die Polizeisirene-Ein-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 32

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist, die TCU ist so konfiguriert, dass sie Polizei-Funktionen unterstützt, die TCU weist einen Eingangsanschluss auf, der zum Unterstützen einer Polizeisirene ausgelegt ist.
Beschreibung des Szenarios: Nur Polizeifahrzeuge; die TCU ist so konfiguriert, dass sie Polizeifahrzeugoptionen unterstützt. Nachdem die TCU durch Überwachen von designierten und konfigurierten Eingangsanschlüssen erkannt hat, dass eine Polizeisirene deaktiviert wurde, gibt die TCU eine SIRENE-AUS-Meldung an den Webdienst aus.

Schritte:

1) Die TCU hat bestimmt, dass die Polizeisirene deaktiviert wurde.
2) Die TCU gibt eine SIRENE-AUS-Meldung mit Datenbündeln aus.
3) Die TCU sammelt VSTAT- und GPS-Info-Bündel mit allen Meldungen.
4) Die TCU gibt die Meldung und den Datenbündel-Datensatz an den Webdienst aus.

Nachbedingungen: Die Polizeisirene-Aus-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 33

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist, die TCU ist so konfiguriert, dass sie Polizei-Funktionen unterstützt, die TCU weist einen Eingangsanschluss auf, der zum Unterstützen eines Polizeilichtbalkens ausgelegt ist.
Beschreibung des Szenarios: Nur Polizeifahrzeuge; die TCU ist so konfiguriert, dass sie Polizeifahrzeugoptionen unterstützt. Nachdem die TCU durch Überwachen von designierten und konfigurierten Eingangsanschlüssen erkannt hat, dass ein Polizeilichtbalken aktiviert wurde, gibt die TCU eine LICHTBALKEN-EIN-Meldung an den Webdienst aus.

Schritte:

1) Die TCU hat bestimmt, dass der Polizeilichtbalken aktiviert wurde.
2) Die TCU gibt eine LICHTBALKEN-EIN-Meldung mit Datenbündeln aus.
3) Die TCU sammelt VSTAT- und GPS-Info-Bündel bei allen Meldungen.
4) Die TCU gibt die Datensatzmeldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Die Polizeilichtbalken-Ein-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 34

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie aktiv ist, die TCU ist so konfiguriert, dass sie Polizei-Funktionen unterstützt, die TCU weist einen Eingangsanschluss auf, der zum Unterstützen eines Polizeilichtbalkens ausgelegt ist.
Beschreibung des Szenarios: Nur Polizeifahrzeuge; die TCU ist so konfiguriert, dass sie Polizeifahrzeugoptionen unterstützt. Nachdem die TCU durch Überwachen von designierten und konfigurierten Eingangsanschlüssen erkannt hat, dass ein Polizeilichtbalken deaktiviert wurde, gibt die TCU eine LICHTBALKEN-AUS-Meldung an den Webdienst aus.

Schritte:

1) Die TCU hat bestimmt, dass der Polizeilichtbalken deaktiviert wurde.
2) Die TCU gibt eine LICHTBALKEN-AUS-Meldung mit Datenbündeln aus.
3) Die TCU sammelt VSTAT- und GPS-Info-Bündel bei allen Meldungen.
4) Die TCU gibt die Datensatzmeldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Die Polizeilichtbalken-AUS-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 35

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, EDRTriggerEvntSyncLateral hat ausgelöst, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Nur Polizeifahrzeuge; die TCU ist so konfiguriert, dass sie Polizeifahrzeugoptionen unterstützt. Nachdem die TCU einen EDRTriggerEvntSync-Übergang auf aktiv erkannt hat, gibt die TCU eine Polizei-EDR-Meldung aus.

Schritte:

1) Die TCU hat bestimmt, dass das Fahrzeug Bedingungen erfährt, die ein EDR-Ereignis herbeiführen.
2) Die TCU gibt eine EDR-Meldung mit Datenbündeln aus.
3) Die TCU sammelt VSTAT- und GPS-Info-Bündel und sendet diese Bündel mit jeder EDR-Meldung, welche die TCU ausgibt.
4) Die TCU gibt die Meldung und die Datenbündel an den Webdienst aus.
5) Die EDR-Meldungen werden kontinuierlich alle 5 Sekunden mit aktualisierten VSTAT- und GPS-Info-Bündeln neu ausgegeben und an den Webdienst ausgegeben, bis der 45-Sekunden-Zeitgeber endet.
6) Wenn die TCU vor dem Ablauf des 45-Sekunden-Zeitgebers zusätzliche EDR-Ereignisse erfährt, wird der Zeitgeber zurückgesetzt und die EDR-Meldungen werden für weitere 45 Sekunden fortgesetzt.

Nachbedingungen: Die Polizei-EDR-Meldung und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 36

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU weist den AKTIV-Zustand aktiviert auf, die Zündung ist in der ZÜNDSCHLÜSSEL-AUS-Position, die TCU ist in den Niederleistungs- oder Schlafmodus übergegangen.
Beschreibung des Szenarios: Die TCU wacht gemäß einem konfigurierbaren Zeitgeber periodisch aus dem Niederleistungs- oder Schlafmodus auf. Die Standardzeit oder der Standardwert ist 12 Stunden. Bei Aufwachen erfasst die TCU GPS- und Fahrzeugdaten, stellt eine MQTT-Verbindung her und sendet Daten an den ESB oder den Webdienst. Bei Fertigstellung kehrt die TCU wieder in den Niederleistungs- oder Schlafmodus zurück.

Schritte:

1. Der TCU-Schlafzeitgeber ist abgelaufen.
2. Die TCU weckt den Fahrzeugbus, um GPS- und Fahrzeugdaten einzuholen.
3. Die TCU bildet VSTAT- und GPS-Info-Bündel.
4. Die TCU stellt eine MQTT-Verbindung zum ESB oder dem Webdienst her.
5. Die TCU gibt Datensätze an den ESB oder den Webdienst aus.
6. Die TCU tritt wieder in den Niederleistungs- oder Schlafmodus ein.

Nachbedingungen: Die TCU kehrt in den Niederleistungs- oder Schlafmodus zurück und wartet auf Fahrzeugmeldebedingungen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 37

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie eine generische Meldung ausgibt, die TCU wurde so konfiguriert, dass sie ein HSCAN-Signal und Daten assoziiert, die zum Ausgeben der generischen Meldung erforderlich sind, die TCU ist so konfiguriert, dass sie aktiv ist.
Beschreibung des Szenarios: Die TCU wurde so konfiguriert, dass sie generische Meldungen ausgibt. Die TCU hat bestimmt, dass das konfigurierte HSCAN-Signal in einen Zustand übergegangen ist, der die Ausgabe einer Meldung erfordert. Die TCU gibt die Meldung mit den erforderlichen Datenbündeln aus.

Schritte:

1. Die TCU hat bestimmt, dass das Fahrzeug Bedingungen erfährt, welche die Ausgabe einer generischen Meldung herbeiführen.
2. Die TCU gibt eine generische Meldung # mit Datenbündeln aus.
3. Die TCU sammelt VSTAT- u. GPS-Info.
4. Die TCU gibt die generische Meldung und die Datenbündel an den Webdienst aus.

Nachbedingungen: Die generische Meldung # und die Daten wurden an den Webdienst gesendet, die TCU ist bereit, eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 38

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist so konfiguriert, dass sie HSCAN-Rahmen streamt, die TCU ist so konfiguriert, dass sie ausgewählte HSCAN-Rahmen streamt, die TCU ist so konfiguriert, dass sie aktiv ist, die TCU weist eine aktive Verbindung zum ESB oder dem Webdienst auf.
Beschreibung des Szenarios: Die TCU wurde so konfiguriert, dass sie die TCU befähigt, Fahrzeugdaten in Echtzeit zu streamen, wenn die Daten im HSCAN-Netz des Fahrzeugs empfangen werden. In diesem Modus empfängt die TCU HSCAN-Nachrichten, und lädt die unverarbeiteten HSCAN-Rahmen als MQTT-Nutzdaten zur Übertragung an den Webdienst oder den ESB.

Schritte:

1. Die TCU stellt eine MQTT-Verbindung zum ESB oder dem Webdienst her.
2. Die TCU empfängt designierte HSCAN-Nachrichten vom HSCAN-Netz des Fahrzeugs.
3. Die TCU speichert 30-Sekunden-Inkremente von kontinuierlichen HSCAN-Daten.
4. Die TCU gibt eine CANNET-Meldung aus und bündelt ein 30-Sekunden-Intervall von HSCAN-Daten zu einem SVHSCAN-Bündel und sendet die Meldungsdaten per Broadcast an den Webdienst oder gibt sie an diesen aus.
5. Die TCU speichert und bündelt kontinuierlich HSCAN-Daten und gibt diese kontinuierlich an den Webdienst aus.

Nachbedingungen: Die Daten wurden durch den ESB oder den Webdienst erfolgreich empfangen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 39

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, der ESB ist betriebsbereit, die TCU weist als Standardkonfiguration „inaktiv“ auf, die TCU weist als Standardkonfiguration „nicht autorisiert“ auf.
Beschreibung des Szenarios: Die TCU wurde von einem Monteur vor Ort in einem Fahrzeug installiert. Die TCU bestimmt, ob sich der Leistungsmodus oder die VIN geändert hat. Die TCU stellt eine zellulare Verbindung her und gibt eine Autorisierungsanforderung an einen Dienstanbieter aus.

Schritte:

1) Nach der Leistungszufuhr zur TCU stellt die TCU eine zellulare Verbindung zum ESB, MQTT-Nachrichtenbroker oder Webdienst her.
2) Wenn entweder die TCU bestimmt, dass der Leistungsmodus „Leistung zuerst zugeführt“ ist, oder die TCU eine neue VIN erkennt. Die TCU kehrt zur Standardkonfiguration zurück. Die TCU muss eine Autorisierungsanforderung an den ESB ausgeben.
3) Die TCU setzt das Bereitstellungsgrund-Flag auf „Leistung zuerst zugeführt“ oder „Neue VIN“ im Bereitstellungsbündel, wie durch die Bedingungen gefordert.
4) Die TCU sendet die Autorisierungsanforderung mit dem Bereitstellungsbündel, dem VSTAT-Bündel und dem GPS-Info-Bündel an den Webdienst.
5) Der ESB verarbeitet die Autorisierungsanforderung.
6) Der ESB sendet einen Diagnosebefehl mit Konfigurationsdaten zum Ändern des TCU-Betriebszustands auf AKTIV und des TCU-Autorisierungszustands als AUTORISIERT.

Nachbedingungen: Die TCU sendet unverzüglich eine TCU-Konfigurationsanforderung und eine Fahrzeuginhaltsabfrageanforderung per Anwendungsfall und Anforderung an den ESB, der TCU-Status ist nun aktiv und autorisiert.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 40

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist aktiv und wach, die TCU hat die Autorisierungsanforderung abgeschlossen.
Beschreibung des Szenarios: Die TCU sendet die Anforderung an den Webdienst, wobei sie den ESB oder den Webdienst auffordert, Diagnosebefehle an die TCU auszugeben, um andere Module oder ECUs abzufragen, um Fahrzeugmerkmale und -inhalt zur Unterstützung von Mannschaftsführermerkmalen zu bestimmen.

Schritte:

1) Die TCU initiiert eine Fahrzeuginhaltsabfrageanforderung an den ESB oder Webdienst.
2) Die TCU sendet die Anforderung zusammen mit dem Bereitstellungsbündel, dem VSTAT-Bündel und dem GPS-Info-Bündel an den ESB.
3) Der ESB sendet einen Diagnosebefehl zum Abfragen der Module an die TCU.
4) Die Fahrzeugmodule antworten auf die TCU-Anfrage mit Diagnosedaten.
5) Die TCU sendet die Diagnosedaten an den ESB.
6) Der ESB sendet weiterhin Diagnosebefehle zum Abfragen der Module an die TCU, bis der ESB Konfigurationsdaten von allen der angeforderten Module sammelt.
7) Der ESB verarbeitet die Konfigurationsdaten, um die TCU-Konfiguration zu bestimmen.

Nachbedingungen: Die TCU ist bereit, den TCU-Konfigurationsbefehl zu akzeptieren und eine andere Meldung zu erkennen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 41

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist aktiv und wach.
Beschreibung des Szenarios: Die TCU prüft den Konfigurationsstatus; wenn die TCU nicht konfiguriert wurde, gibt die TCU eine TCU-Konfigurationsanforderung per Anforderung nach jeder Zündung-Ein-Meldung an den ESB aus.

Schritte:

1) Wenn die TCU nicht konfiguriert wurde, sendet die TCU eine TCU-Konfigurationsanforderung mit dem Bereitstellungsbündel, dem VSTAT-Bündel und dem GPS-Info-Bündel an den ESB.
2) Der ESB verarbeitet die Konfigurationsanforderung und sendet einen Diagnosebefehl mit Konfigurationsdaten an die TCU.
3) Die TCU verarbeitet den Diagnosebefehl und schreibt Konfigurationsdaten in die korrekten Speicherorte.
4) Nach Abschluss des Konfigurationsschreibvorgangs liest die TCU die gespeicherten Konfigurationsdaten aus und sendet die Daten als ein Diagnosebündel an den ESB.
5) Der ESB empfängt die Diagnosedaten von der TCU und bestätigt, dass die korrekte Konfiguration verarbeitet wurde.
6) Der ESB gibt einen Diagnosebefehl zum Löschen aller Diagnosefehlercodes an die TCU aus.

Nachbedingungen: Die TCU ist bereit, eine andere Meldung zu erkennen, die TCU ist bereit für einen anderen Befehl, der TCU-Konfiguration-nicht-abgeschlossen-Meldungscode wurde gesendet.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Beispiel 42

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU ist wach.
Beschreibung des Szenarios: Die TCU hat Bedingungen erkannt, die darauf hinweisen, dass die Ausgabe einer BEREITSTELLUNGS-Meldung an den ESB oder den Webdienst erforderlich ist.

Schritte:

1) Die TCU ist auf eine Bedingung gestoßen, welche die Ausgabe einer Rücksetzungs-/Bereitstellungsmeldung erfordert.
2) Die TCU registriert die Bereitstellungsmeldung.
3) Die TCU sammelt VSTAT- u. GPS-Info-Bündel.
4) Die TCU sammelt ein BEREITSTELLUNGS-Bündel (umfasst den Grund für die Meldung).

Nachbedingungen: Die TCU ist bereit, eine andere Meldung zu erkennen.

Beispiel 43

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist aktiv, die TCU liest HSCAN-Nachrichten, Nachrüst-Tool ist angeschlossen.
Beschreibung des Szenarios: Die TCU überwacht kontinuierlich den HSCAN-Verkehr, wenn der TCU HSCAN-Verkehr erkennt, der anzeigt, dass ein Dienst-Tool an den Bus angeschlossen ist. Die TCU gibt eine Prüfer-präsent-Meldung an den Webdienst aus.

Schritte:

1) Die TCU erkennt, dass ein Prüf-Tool an den HS CAN angeschlossen ist.
2) Die TCU gibt den Prüfer-präsent-Meldungscode aus.
3) Die TCU sammelt VSTAT- u. GPS-Info-Bündel.

Nachbedingungen: Die TCU ist bereit, eine andere Meldung zu erkennen.

Beispiel 44

Aktoren: TCU-Modul
Vorbedingungen: Die TCU ist betriebsbereit, die TCU hat ein erstes Leistungszufuhrereignis durchlaufen ODER die TCU liest eine neue VIN, die TCU hat eine MQTT-Verbindung zum Webdienst hergestellt, die TCU hat ein Bereitstellungs-, GPS-Info- und VSTAT-Bündel ausgegeben, die TCU hat den Autorisierungsprozess abgeschlossen,
Beschreibung des Szenarios: Die TCU wurde erfolgreich mit Leistung versorgt und hat eine MQTT-Verbindung zum ESB-Nachrichtenbroker hergestellt. Die TCU gibt einen Diagnosebefehl bzw. eine Diagnoseanforderung zum Ausführen einer Selbsttest-Diagnoseroutine an ein BCM aus. Dies zeigt dem Monteur an, dass die TCU korrekt installiert wurde.

Schritte:

1. Die TCU gibt einen Dienst 0x31 mit der Routinekennung 0x0202 an das BCM aus.
2. Das BCM empfängt einen Diagnosebefehl.
3. Das BCM führt den Befehl aus.
4. Die TCU liest die Diagnosebefehlsantwort vom BCM.
5. Positive Antwort empfangen, Befehl ausgeführt; die TCU sendet eine Diagnosemeldung und ein Diagnosebündel an den ESB oder den Webdienst.
6. Negative Antwort empfangen, Befehl nicht ausgeführt; die TCU sendet eine Diagnosemeldung und ein Diagnosedatenbündel an den ESB oder den Webdienst.

Nachbedingungen: BCM-Selbsttest ausgeführt, die TCU beginnt mit dem Überwachen des Fahrzeugs auf Meldungsbedingungen.
Schnittstellen: OTA-Broadcast oder Download von zellularem Netz, Fahrzeugsystemschnittstelle.

Obwohl 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 Spezifikation verwendeten Ausdrücke beschreibende statt einschränkende Ausdrücke, und es versteht sich von selbst, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Schutzbereich der Erfindung abzuweichen. Außerdem können die Merkmale von verschiedenen Implementierungsausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
Es wird ferner beschrieben:

A. System, umfassend: einen Prozessor, der konfiguriert ist zum: Erkennen einer Bedingung, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte; Starten und Fortsetzen der Ereignisdatenaufzeichnung für eine vorbestimmte Zeitdauer nach der Bedingung; Speichern von Daten, die durch die Ereignisdatenaufzeichnung aufgezeichnet wurden, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde; und Hochladen der Daten auf ein Remote-System, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.
B. System nach A, wobei die Bedingung von einem Hersteller vordefiniert ist.
C. System nach A, wobei die Bedingung einen bevorstehenden Unfall anzeigt.
D. System nach A, wobei das Remote-System ein Kraftfahrzeughersteller-Server ist.
E. System nach A, wobei das Remote-System ein Flottenverwaltungsserver ist.
F. System nach A, wobei sich die Bedingung auf einen Bremszustand des Fahrzeugs bezieht.
G. System nach A, wobei sich die Bedingung auf einen Bewegungszustand des Fahrzeugs bezieht.
H. System nach A, wobei sich die Bedingung auf eine Geschwindigkeitsänderung des Fahrzeugs bezieht.
I. System, umfassend: einen Prozessor, der konfiguriert ist zum: Empfangen von variablen Eingabedaten von einer Mehrzahl von drahtlos verbundenen Fahrzeugen; Vergleichen der empfangenen variablen Eingabedaten mit vorbestimmten Schwellen, um zu bestimmen, ob eine Bedingung, die wahrscheinlich eine Ereignisdatenaufzeichnung (EDR) initiiert, in einem der Mehrzahl von Fahrzeugen bevorsteht; Ausgeben für jedes Fahrzeug, bei welchem die Bedingung bevorsteht, einer Anweisung für das Fahrzeug, einen Autofahrer zu warnen; Ausgeben an jedes Fahrzeug, für welches die Bedingung bevorsteht, einer Anforderung, welche die Ereignisdatenaufzeichnung anfordert; und Sammeln der Daten, die durch die angeforderte(n) Ereignisdatenaufzeichnung(en) aufgezeichnet wurden.
J. System nach I, wobei die Warnung eine optische Warnung ist.
K. System nach I, wobei die Warnung eine akustische Warnung ist.
L. System nach I, wobei der Prozessor außerdem so konfiguriert ist, dass er eine Warnung an einen Flottenbetreiber ausgibt.
M. System nach Anspruch 9, wobei die Daten gesammelt werden, während die Aufzeichnung läuft.
N. System nach I, wobei die Daten nach der Ereignisdatenaufzeichnung gesammelt werden.
O. Computerimplementiertes Verfahren, umfassend: das Erkennen einer Bedingung, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte; das Starten und Fortsetzen der Ereignisdatenaufzeichnung für eine vorbestimmte Zeitdauer nach der Bedingung; das Speichern von Daten, die durch die Ereignisdatenaufzeichnung aufgezeichnet wurden, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde; und das Hochladen der Daten auf ein Remote-System, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.
P. Verfahren nach O, wobei die Bedingung von einem Hersteller vordefiniert ist.
Q. Verfahren nach O, wobei die Bedingung einen bevorstehenden Unfall anzeigt.
R. Verfahren nach O, wobei das Remote-System ein Kraftfahrzeughersteller-Server ist.
S. Verfahren nach O, wobei das Remote-System ein Flottenverwaltungsserver ist.

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 8139820 [0003]

Zitierte Nicht-Patentliteratur

IEEE 802 PAN [0021]
IEEE 1394 [0024]
IEEE 1284 [0024]
IEEE 803.11 [0026]

Claims

System, umfassend: einen Prozessor, der konfiguriert ist zum: Erkennen einer Bedingung, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte; Starten und Fortsetzen der Ereignisdatenaufzeichnung für eine vorbestimmte Zeitdauer nach der Bedingung; Speichern von Daten, die durch die Ereignisdatenaufzeichnung aufgezeichnet wurden, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde; und Hochladen der Daten auf ein Remote-System, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.
System nach Anspruch 1, wobei die Bedingung von einem Hersteller vordefiniert ist.
System nach Anspruch 1, wobei die Bedingung einen bevorstehenden Unfall anzeigt.
System nach Anspruch 1, wobei das Remote-System ein Kraftfahrzeughersteller-Server ist.
System nach Anspruch 1, wobei das Remote-System ein Flottenverwaltungsserver ist.
System nach Anspruch 1, wobei sich die Bedingung auf einen Bremszustand des Fahrzeugs bezieht.
System nach Anspruch 1, wobei sich die Bedingung auf einen Bewegungszustand des Fahrzeugs bezieht.
System nach Anspruch 1, wobei sich die Bedingung auf eine Geschwindigkeitsänderung des Fahrzeugs bezieht.
System, umfassend: einen Prozessor, der konfiguriert ist zum: Empfangen von variablen Eingabedaten von einer Mehrzahl von drahtlos verbundenen Fahrzeugen; Vergleichen der empfangenen variablen Eingabedaten mit vorbestimmten Schwellen, um zu bestimmen, ob eine Bedingung, die wahrscheinlich eine Ereignisdatenaufzeichnung (EDR) initiiert, in einem der Mehrzahl von Fahrzeugen bevorsteht; Ausgeben für jedes Fahrzeug, bei welchem die Bedingung bevorsteht, einer Anweisung für das Fahrzeug, einen Autofahrer zu warnen; Ausgeben an jedes Fahrzeug, für welches die Bedingung bevorsteht, einer Anforderung, welche die Ereignisdatenaufzeichnung anfordert; und Sammeln der Daten, die durch die angeforderte(n) Ereignisdatenaufzeichnung(en) aufgezeichnet wurden.
System nach Anspruch 9, wobei die Warnung eine optische Warnung ist.
System nach Anspruch 9, wobei die Warnung eine akustische Warnung ist.
System nach Anspruch 9, wobei der Prozessor außerdem so konfiguriert ist, dass er eine Warnung an einen Flottenbetreiber ausgibt.
System nach Anspruch 9, wobei die Daten gesammelt werden, während die Aufzeichnung läuft.
System nach Anspruch 9, wobei die Daten nach der Ereignisdatenaufzeichnung gesammelt werden.