DE102023208552B4

DE102023208552B4 - Kollisionserkennung bei mobiler vorrichtung

Info

Publication number: DE102023208552B4
Application number: DE102023208552.6A
Authority: DE
Inventors: Vinay R. Majjigi; Sriram Venkateswaran; Aniket Aranake; Tejal Bhamre; Alexandru Popovici; Parisa Dehleh Hossein Zadeh; Yann Jerome Julien Renard; Yi Wen Liao; Stephen P. Jackson; Rebecca L. Clarkson; Henry Choi; Paul D. Bryan; Mrinal AGARWAL; Ethan Goolish; Richard G. Liu; Omar Aziz; Alvaro J. Melendez Hasbun; David Ojeda Avellaneda; Sunny Kai Pang Chow; Pedro O. Varangot
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2022-09-06
Filing date: 2023-09-05
Publication date: 2026-04-30
Anticipated expiration: 2043-09-06
Also published as: DE102023208552A1; KR20240034147A; US20240075895A1; US12485842B2

Abstract

Verfahren, dadurch gekennzeichnet, dass es folgendes umfasst:Erkennen eines Kollisionsereignisses an einer Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) mit mindestens einem Prozessor (301, 302, 1702, 1703, 2002, 2304);Extrahieren von multimodalen Merkmalen (306) aus Sensordaten, die durch mehrere Erfassungsmodalitäten der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) erzeugt werden, mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304);Berechnen mehrerer Kollisionsentscheidungen mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304), basierend auf mehreren Maschinenlernmodellen (307), die auf die multimodalen Merkmale (306) angewendet werden; undBestimmen, dass eine schwere Fahrzeugkollision aufgetreten ist, mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304) unter Einbeziehung der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell (2204).

Description

TECHNISCHES GEBIET
Diese Offenbarung bezieht sich allgemein auf die Verwendung einer mobilen Vorrichtung, um zu erkennen, wenn sich ein Benutzer in einem schweren Automobilunfall befindet.
HINTERGRUND
Wenn ein Fahrer oder ein Mitfahrer bei einem schweren Automobilunfall verletzt oder anderweitig beeinträchtigt wird, kann der Fahrer oder der Mitfahrer unfähig sein, mit seinem Mobiltelefon oder Autotelefon einen Notdienst anzurufen. Dies ist besonders schlimm, wenn der Unfall an einem Ort auftritt, an dem keine Passanten sind, die dem Fahrer oder Mitfahrer helfen können.
Das Stand der Technik Dokument DE 10 2021 115 371 A1 offenbart eine Kommunikation zwischen autonomen Fahrzeugen und ungeschützten Verkehrsteilnehmern.
Das Stand der Technik Dokument DE 10 2021 203 354 B4 offenbart ein Verfahren zum Bestimmen einer zukünftigen Unfallschwere eines Kraftfahrzeugs mit einem Objekt mittels eines Assistenzsystems des Kraftfahrzeugs.
Das Stand der Technik Dokument DE 10 2022 104 129 A1 offenbart ein Verfahren zur Ermittlung einer bei einer Kollision eines Fahrzeugs auf zumindest einen Fahrzeuginsassen des Fahrzeugs erfolgte, zumindest eine gesundheitliche Auswirkung, ein Verfahren zum Trainieren einer Prognosefunktion, eine Überwachungsvorrichtung, ein Fahrzeug, umfassend eine Überwachungsvorrichtung sowie eine Trainingsvorrichtung.
Das Stand der Technik Dokument DE 10 2022 111 037 A1 offenbart ein Verfahren zur Verarbeitung von Daten, die sich auf ein Fahrzeugereignis für ein Fahrzeug beziehen, welches umfasst: Erhalten von Fahrzeugsensordaten von einem oder mehreren Fahrzeugsensoren, die sich auf das Fahrzeugereignis beziehen; und Bestimmen einer Bewertung des Fahrzeugereignisses über einen Prozessor, einschließlich eines Fehlers oder einer Schwere oder beidem, die dem Fahrzeugereignis zugeordnet sind, basierend auf den Fahrzeugsensordaten.
Das Stand der Technik Dokument DE 10 2022 120 111 A1 offenbart eine Schätzung der Schwere von Verletzungen durch Venrwndung einer fahrzeuginternen Wahrnehmung.
KURZDARSTELLUNG
Die vorliegende Erfindung ist in den unabhängigen Ansprüchen definiert. Vorteilhafte Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
Es werden Ausführungsformen für eine Kollisionserkennung an einer oder mehreren mobilen Vorrichtungen (z. B. Smartwatch und/oder Smartphone) offenbart. In einigen Ausführungsformen umfasst ein Verfahren: Erkennen eines Kollisionsereignisses an einer Kollisionsvorrichtung mit mindestens einem Prozessor; Extrahieren von multimodalen Merkmalen aus Sensordaten, die durch mehrere Erfassungsmodalitäten der Kollisionsvorrichtung erzeugt werden, mit dem mindestens einen Prozessor; Berechnen mehrerer Kollisionsentscheidungen mit dem mindestens einen Prozessor, basierend auf mehreren Maschinenlernmodellen, die auf die multimodalen Merkmale angewendet werden; und Bestimmen, dass eine schwere Fahrzeugkollision aufgetreten ist, mit dem mindestens einen Prozessor unter Einbeziehung der Kollisionsvorrichtung basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell.
In einigen Ausführungsformen umfasst das Verfahren ferner als Reaktion auf das Bestimmen einer schweren Kollision das Darstellen einer Benachrichtigung auf einem Bildschirm der Kollisionsvorrichtung, die eine Antwort von einem Benutzer der Kollisionsvorrichtung anfordert.
In einigen Ausführungsformen umfasst das Verfahren ferner das Bestimmen, ob die Kollisionsvorrichtung für einen vorbestimmten Zeitraum stationär ist; als Reaktion darauf, dass die Kollisionsvorrichtung für den vorbestimmten Zeitraum stationär ist, Starten eines Zeitgebers oder Zählers; Bestimmen, dass der Zeitgeber oder Zähler eine Schwellenzeit bzw. -zahl erreicht; und Eskalieren der Benachrichtigung.
In einigen Ausführungsformen umfasst das Verfahren als Ergebnis des Eskalierens ferner das Bestimmen, dass nach dem Erreichen der Schwellenzeit oder -zahl keine Antwort auf die Benachrichtigung empfangen wurde, wobei unter Verwendung eines oder mehrerer Kommunikationsmodalitäten der Kollisionsvorrichtung automatisch Kontakt zu Notdiensten aufgenommen wird.
In einigen Ausführungsformen umfasst das Verfahren: Senden von mindestens einem der multimodalen Merkmale, Kollisionsentscheidungen, Inferenz einer schweren Kollision oder Benutzerinteraktionen mit der Benachrichtigung an einen Netzwerkservercomputer; Empfangen mindestens einer Aktualisierung zu mindestens einem Parameter von mindestens einem Maschinenlernmodell oder dem Schweregradmodell von dem Netzwerkserver; und Aktualisieren des mindestens einen Parameters mit der mindestens einen Aktualisierung mit dem mindestens einen Prozessor.
In einigen Ausführungsformen ist mindestens eines der multimodalen Merkmale eine Verzögerungsimpulssignatur, die in Beschleunigungsdaten vorhanden ist.
In einigen Ausführungsformen ist mindestens eines der multimodalen Merkmale ein Schalldruckniveau von Audiodaten, die von mindestens einem Mikrofon der Kollisionsvorrichtung erfasst werden.
In einigen Ausführungsformen ist mindestens eines der multimodalen Merkmale eine Druckänderung aufgrund von Airbag-Entfaltung im Fahrzeug.
In einigen Ausführungsformen ist mindestens eines der multimodalen Merkmale ein Geschwindigkeitsabfall der Kollisionsvorrichtung.
In einigen Ausführungsformen umfasst das Verfahren ferner: Empfangen von kollisionsbezogenen Merkmalen von einer Begleitvorrichtung, die mit der Kollisionsvorrichtung gekoppelt ist, mit dem mindestens einen Prozessor; Berechnen mehrerer Kollisionsentscheidungen basierend auf mehreren Maschinenlernmodellen, die auf die multimodalen Merkmale und absturzbezogenen Merkmale angewendet werden, mit dem mindestens einen Prozessor; und Ableiten, dass eine schwere Fahrzeugkollision aufgetreten ist, mit dem mindestens einen Prozessor unter Einbeziehung der Kollisionsvorrichtung basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell.
In einigen Ausführungsformen umfasst das Verfahren ferner das Abgleichen von Epochen für die multimodalen Merkmale mit Epochen für die zusätzlichen multimodalen Merkmale, um Fehlausrichtung zwischen Epochengrenzen zu entfernen.
Andere Ausführungsformen beziehen sich auf eine Vorrichtung, ein System und ein computerlesbares Medium.
Bestimmte hier beschriebene Ausführungsformen bieten einen oder mehrere der folgenden Vorteile. Die offenbarten Kollisionserkennungsausführungsformen ermöglichen es einer Kollisionsvorrichtung (z. B. Smartphone, Smartwatch), automatisch zu erkennen, wenn sich ein Benutzer in einer Fahrzeugkollision befindet, während auch das Auftreten falscher Kollisionserkennungen reduziert wird. Wenn eine Kollision erkannt wird, stellt die Kollisionsvorrichtung eine Benutzerschnittstelle dar, die den Benutzer für einen Zeitraum warnt. Wenn der Benutzer reaktionsfähig ist, kann er über den Bildschirm wischen oder eine andere Eingabe bereitstellen, um sofort Notdienste anzurufen oder die Warnung auszublenden, wenn der Benutzer keine Notdienste benötigt. Wenn nach Ablauf des Zeitraums keine Benutzerinteraktion mit der Kollisionsvorrichtung erfolgt, beginnt ein Countdown. Wenn der Countdown endet, werden automatisch Notdienste und/oder die Notfallkontaktliste des Benutzers über einen Telefonanruf oder eine Textnachricht kontaktiert.
KURZBESCHREIBUNG DER ZEICHNUNGEN

1 veranschaulicht eine Smartwatch für die Kollisionserkennung gemäß einer oder mehreren Ausführungsformen.
2 ist eine Kollisionserkennungszeitlinie gemäß einer oder mehreren Ausführungsformen.
3 ist ein Blockdiagramm eines Kollisionserkennungssystems gemäß einer oder mehreren Ausführungsformen.
4A ist eine Tabelle, in der beobachtete Sensorsignale und entsprechende Erfassungsmodi für Sensoren einer Kollisionsvorrichtung gemäß einer oder mehreren Ausführungsformen aufgelistet sind.
4B ist ein Diagramm von Verzögerungsimpuls und Aufprallsignaturen in Trägheitssensorsignalen, die eine Kollision anzeigen, gemäß einer oder mehreren Ausführungsformen.
4C ist ein Diagramm eines lauten Audiosignals, das eine Kollision angibt, gemäß einer oder mehreren Ausführungsformen.
4D ist ein Diagramm von plötzlichem Druckwechsel, das eine Airbag-Entfaltung während einer Kollision gemäß einer oder mehreren Ausführungsformen angibt.
4E ist ein Diagramm eines großen Geschwindigkeitsabfalls, der eine Fahrzeugkollision angibt, gemäß einer oder mehreren Ausführungsformen.
5A ist ein Diagramm der Trägheitsbeschleunigung gemäß einer oder mehreren Ausführungsformen.
5B ist ein Diagramm der normalisierten horizontalen Beschleunigung gemäß einer oder mehreren Ausführungsformen.
5C ist ein Histogramm der Wahrscheinlichkeit als Funktion der Spitzenverzögerung für aggregierte Verzögerungsimpulse gemäß einer oder mehreren Ausführungsformen.
6A ist ein Diagramm einer nominalen Airbagdrucksignatur aufgrund der Entfaltung während einer Kollision gemäß einer oder mehreren Ausführungsformen.
6B ist ein Diagramm der Wahrscheinlichkeit als Funktion des Spitzendrucks für eine aggregierte Spitzendruckstörung, die auf die breite Masse bezogene falsch Positive und richtig Positive für eine Kollision gemäß einer oder mehreren Ausführungsformen zeigt.
7A ist ein Diagramm, das einen Schalldruckpegel (SPL) während einer Kollision gemäß einer oder mehreren Ausführungsformen zeigt.
7B ist ein Diagramm der Wahrscheinlichkeit als Funktion der Dauer für eine Berstdauer von SPL über 130 db innerhalb von 200 ms, die auf die breite Masse bezogene falsch Positive und richtig Positive für eine Kollision gemäß einer oder mehreren Ausführungsformen zeigt.
8 ist ein Zustandsmaschinendiagramm zum Auslösen eines Notsignals (nachstehend „SOS-Signal“) gemäß einer oder mehreren Ausführungsformen.
9A ist eine Zeitlinie zum sicheren Benachrichtigen eines Benutzers nach einer erkannten Kollision gemäß einer oder mehreren Ausführungsformen.
9B ist eine Zustandsmaschine für einen Warneskalierungsfluss gemäß einer oder mehreren Ausführungsformen.
10 veranschaulicht die Verwendung mehrerer Kollisionsvorrichtungen zum Erkennen von Kollisionen gemäß einer oder mehreren Ausführungsformen.
11 veranschaulicht einen Querschnitt eines Softwarestacks für die Kollisionserkennung gemäß einer oder mehreren Ausführungsformen.
12A und 12B veranschaulichen die Epoche zur Zeitausrichtung für multimodale Kollisionserkennung gemäß einer oder mehreren Ausführungsformen.
13A-13C veranschaulichen die Modellierung falsch positiver Risiken aufgrund von Zeitsteuerung gemäß einer oder mehreren Ausführungsformen.
14A und 14B veranschaulichen das Abgleichen von Epochen über zwei Kollisionsvorrichtungen gemäß einer oder mehreren Ausführungsformen.
15 veranschaulicht einen Erkennungsdienst auf der Kollisionsvorrichtung gemäß einer oder mehreren Ausführungsformen.
16 veranschaulicht einen Verzögerungspuffer, der bewirkt, dass die Kollisionsvorrichtung für einen vorbestimmten Zeitraum vor der Verarbeitung pausiert, gemäß einer oder mehreren Ausführungsformen.
17 veranschaulicht ein verteiltes und geschlossenes System zum aktiven Modifizieren des Kollisionserkennungsverhaltens gemäß einer oder mehreren Ausführungsformen.
18A und 18B veranschaulichen eine Architektur für die auf die breite Masse bezogene Datensammlung und -verarbeitung gemäß einer oder mehreren Ausführungsformen.
19 ist ein Zustandsmaschinendiagramm, das Anomalieerfassungsvorgänge veranschaulicht, gemäß einer oder mehreren Ausführungsformen.
20 ist ein Blockdiagramm eines großangelegten Backend-Datenanalysesystems gemäß einer oder mehreren Ausführungsformen.
21 veranschaulicht einen einstellbaren Systemprozess gemäß einer oder mehreren Ausführungsformen.
22 ist ein Flussdiagramm eines Prozesses zur Kollisionserkennung, wie unter Bezugnahme auf 1-21 beschrieben.
23 ist ein Blockdiagramm einer Vorrichtungsarchitektur zum Implementieren der Merkmale und Prozesse, die unter Bezugnahme auf die 1-22 gemäß einer Ausführungsform beschrieben sind.

DETAILLIERTE BESCHREIBUNG
Kollisionserkennungsübersicht
1 veranschaulicht eine beispielhafte Kollisionsvorrichtung, eine Smartwatch 100, für die Kollisionserkennung gemäß einer oder mehreren Ausführungsformen. Andere Beispiele für Kollisionsvorrichtungen schließen ein Smartphone und einen Tablet-Computer ein. Die offenbarten Kollisionserkennungsausführungsformen ermöglichen es einer Kollisionsvorrichtung, wie einer Smartwatch 100, zu erkennen, wenn sich ein Benutzer in einer Kollision befindet, während auch das Auftreten falscher Kollisionserkennungen reduziert wird. In einigen Ausführungsformen stellt die Smartwatch 100, wenn eine Kollision erkannt wird, eine Benutzerschnittstelle (UI) 101 mit einer Wohlbefindensprüfung für einen vorbestimmten Zeitraum dar. Wenn der Benutzer reaktionsfähig ist, kann der Benutzer über die Anforderung „SOS-Notrufe“ 102 wischen, um Notdienste zu kontaktieren, oder auf „Abbrechen“ tippen, um die Warnung abzubrechen. Wenn jedoch nach Ablauf des vorbestimmten Zeitraums der Benutzer nicht reagiert (z. B. gibt es keine Benutzerinteraktion mit UI 101), startet ein Countdown-Timer (z. B. von 10 herunterzählend). Wenn der Countdown endet, werden automatisch Notdienste und/oder die Notfallkontaktliste des Benutzers durch eine oder mehrere Kommunikationsmodalitäten (z. B. einen Telefonanruf oder eine Textnachricht) kontaktiert.
In einigen Ausführungsformen beginnt, wenn Notdienste den SOS-Anruf annehmen, ein digitaler Assistent auf der Smartwatch 100, eine Audionachricht von einem Lautsprecher auf der Smartwatch 100 abzuspielen, die angibt, dass der Benutzer einen Unfall hatte. In einigen Ausführungsformen wird die Audionachricht auf einer Schleife mit einer vorbestimmten Sekundenzahl von Stummzeiten zwischen jeder Wiedergabe abgespielt. Der digitale Assistent übermittelt auch den geschätzten Standort des Benutzers (z. B. Breitengrad und Längengrad der Smartwatch 100) und einen Suchradius an Notdienste. In einigen Ausführungsformen kann die geschätzte Position des Benutzers während des Anrufs angekündigt werden oder in einer Textnachricht oder E-Mail angegeben werden und/oder auch durch den Lautsprecher der Smartwatch 100 angekündigt werden, falls drahtlose Kommunikationen an der Unfallstelle betriebsfähig sind (z. B. keine Signale).
2 ist eine Kollisionserkennungsereigniszeitlinie 200 gemäß einer oder mehreren Ausführungsformen. Bei t=0 Sekunden wird das Kollisionsereignis 201 durch die Smartwatch 100 erkannt. Bei t=15 Sekunden wird eine Benachrichtigung 202 auf UI 10 mit einer Wohlbefindensprüfung dargestellt, wie in 1 gezeigt. Wenn der Benutzer für N Sekunden (z. B. N=30 Sekunden) nach dem Senden der Benachrichtigung nicht reagiert, wird ein Countdown mit einer hörbaren Warnung 203 gestartet. Wenn es nach Abschluss des Countdowns keine Antwort vom Benutzer gibt (z. B. keine Interaktion mit UI 101), werden Notdienste 204 kontaktiert (z. B. 911 gewählt). Diese beispielhafte Zeitlinie 200 dient zu veranschaulichenden Zwecken. Es können auch andere Zeitlinien mit unterschiedlichen Zeitgrenzen oder unterschiedliche Anzahlen und/oder Arten von Warnungseskalationen verwendet werden.
Beispiel Kollisionserkennungssystem
3 ist ein Blockdiagramm eines Kollisionserkennungssystems 300 für eine mobile Vorrichtung gemäß einer oder mehreren Ausführungsformen. Das System 300 könnte zum Beispiel auf der in 1 gezeigten Smartwatch 100 implementiert sein.
Das System 300 schließt einen Niederleistungsprozessor 301, einen Anwendungsprozessor 302 (hierin auch als „Allzeitprozessor“ (AOP) bezeichnet), eine SOS-Zustandsmaschine 303 und Kollisionserkennungsclients 304 ein. Der Niederleistungsprozessor 301 verbraucht weniger Strom als der Anwendungsprozessor 302. Aus mindestens diesem Grund wird der Niederleistungsprozessor 301 kontinuierlich ausgeführt, um Auslöser zu erkennen, die eine schwere Fahrzeugkollision angeben (nachstehend als „Kollisionsereignisauslöser“ bezeichnet). Die Kollisionsereignisauslöser können beispielsweise basierend auf verschiedenen beobachteten Signalen von mehreren Sensoren auf der Kollisionsvorrichtung erzeugt werden. Der Erkennungsdienst 305, der auf dem Anwendungsprozessor 302 ausgeführt wird, überwacht die von dem Niederleistungsprozessor 301 gesendeten Kollisionsauslöserereignissignale. Wenn ein Auslöserereignis (siehe gestrichelte Linie) empfangen wird, wird eine Epoche gestartet und der Erkennungsdienst 305 extrahiert multimodale Merkmale 306 von Sensorströmen, die von den Sensoren ausgegeben werden. Zum Beispiel ruft der Erkennungsdienst 305 Abtastwerte von Sensordaten aus einem IMU-Puffer, Audiopuffer, Barometerpuffer und GPS-Puffer für jede Epoche ab. Multimodale Merkmale 306 werden aus den gepufferten Sensordaten (z. B. Beschleunigung, Drehzahl, Druck, Geschwindigkeit, Audioausschnitten) extrahiert und in Maschinenlernmodelle 307 eingegeben, um Kollisionsentscheidungen zu erzeugen, wie Airbag-Entfaltung, schwere Kollision, Überschlagkollision, Aufprallenergie/-direktionalität und Stille. Insbesondere werden Modelle 307 auf multimodale Merkmale angewendet, um Schätzungen zu erzeugen, ob ein Airbag entfaltet wurde, ob eine Kollision aufgetreten ist, ob eine Überschlagkollision aufgetreten ist, ob Aufprallenergie/-direktionalität aufgetreten ist, die eine Kollision angeben, und ein Zeitraum von Stille (z. B. keine Beobachtung vorhandener Signale), der eine Kollision angibt, (herein als „Kollisionsentscheidungen“ bezeichnet). Die Modelle 307 können beliebige geeignete überwachte oder unüberwachte Maschinenlernmodelle implementieren, einschließlich, aber nicht beschränkt auf: Regressionsmodelle (z. B. lineare, logistische), Entscheidungsbäume, Random-Forest, Support-Vektor-Maschinen, neuronale Netzwerke (z. B. faltende neuronale Netzwerke), Klassifikatoren, Naive Bayes, Clustering, Dimensionalitätsreduktion (z. B. Hauptkomponentenanalyse (PCA) usw.
Die durch Modelle 307 ausgegebenen Kollisionentscheidungen werden in die Inferenzmaschine 308 eingegeben. Die Inferenzmaschine 308 verwendet einen Schweregrad-Modell, einen Modusdetektor und Kollisionsmerkmale, um abzuleiten, ob eine schwere Kollision aufgetreten ist. In einigen Ausführungsformen gibt die Inferenzmaschine 308 auf der Grundlage der Unfallentscheidungen eine Wahrscheinlichkeit aus, dass eine schwere Kollision aufgetreten ist.
Wenn die Wahrscheinlichkeit über einem spezifizierten Schwellenwert liegt, wird eine schwere Kollision vorhergesagt und an die SOS-Zustandsmaschine 303 gesendet, die eine UI-Eskalation durchführt, wie unter Bezugnahme auf 8 beschrieben. Wenn der Eskalationspegel auf den Pegel des Kontaktierens von Notdiensten ansteigt (z. B. nicht reagierende Benutzer nach einem Zeitraum/Countdown), werden die Kollisions-Clients 304 (z. B. eine Telefonie-Anwendung, eine Nachrichtenanwendung, eine E-Mail-Anwendung, ein digitaler Assistent) benachrichtigt, sodass Notdienste und/oder Notfallkontakte aufgerufen werden, wie unter Bezugnahme auf 1 und 2 beschrieben. Wenn die SOS-Zustandsmaschine 303 deeskaliert (z. B. der Benutzer die Option „Abbrechen“ 103 vor Ablauf des Zeitraums/Countdowns berührt), wird ein Deskalationssignal an den Niederleistungsprozessor 301 übermittelt, um den Auslöseprozess zurückzusetzen.
4A ist eine Tabelle, in der beobachtete Signale und entsprechende Erfassungsmodi für Sensoren einer Kollisionsvorrichtung (z. B. Smartwatch 100) gemäß einer oder mehreren Ausführungsformen aufgelistet sind. Sensoren können, ohne darauf beschränkt zu sein, einzelne Trägheitssensoren (z. B. Beschleunigungsmesser, Gyroskop) oder eine Trägheitsmesseinheit (IMU), die mehrere Trägheitssensoren enthält, Signale von einem globalen Navigationssatellitensystem (GNSS), wie dem Global Positioning System (GPS), BeiDou usw., Druckänderungen, die von einem Drucksensor (z. B. einem Barometer) gemessen werden, und Audiosignale, die von einem oder mehreren Mikrofonen der Kollisionsvorrichtung erfasst werden, einschließen. Einige Beispiele für beobachtete Signale schließen ein, ohne darauf beschränkt zu sein, Vorkollisionsignaturen, die in IMU-Daten und GPS-Daten erfasst werden, Aufprallgröße, die aus IMU-Daten bestimmt wird, Überschlagerkennung, die aus IMU-Daten und Audiodaten bestimmt wird, Airbag-Entfaltung, die aus Druckdaten und Audiodaten bestimmt wird, Kollisiongeräuschen, die aus Audiodaten und Vorkollisionssignaturen bestimmt werden, die aus IMU-Daten und GPS-Daten bestimmt werden.
4B ist ein Diagramm von Verzögerungsimpuls und Aufprallsignaturen in Trägheitssensordaten, die eine Kollision anzeigen, gemäß einer oder mehreren Ausführungsformen. Die vertikale Achse ist Beschleunigung und die horizontale Achse ist Zeit (s). Die Beschleunigung wird von einer IMU der Kollisionsvorrichtung erhalten. Die Signatur zeichnet sich durch scharfe Impulse aus, die eine spezifizierte Größe für eine spezifizierte Dauer überschreiten. Die Signaturen können empirisch aus z. B. Kollisiontestdaten gewonnen werden.
4C ist ein Diagramm der Lautstärke eines Audioausschnitts, der eine Kollision anzeigt, gemäß einer oder mehreren Ausführungsformen. Die vertikale Achse ist die Lautstärke (dB) und die horizontale Achse ist Zeit (Sekunden). Das Audio kann durch Abtasten der Ausgabe eines oder mehrerer Mikrofone der Kollisionsvorrichtung und Speichern der Abtastwerte in einem Puffer erhalten werden. Die Audiosignatur zeichnet sich durch einen Anstieg des Lautstärkepegels von einer Umgebungsaudiobasislautstärke über eine spezifizierte Dauer (Anstiegszeit) aus, gefolgt von einer spezifizierten Dauer auf dem höheren Lautstärkepegel, gefolgt von einer Rückkehr zu dem Umgebungsaudiobasislautstärkepegel. Die Signatur kann empirisch aus z. B. Kollisiontestdaten erhalten werden.
4D ist ein Diagramm von plötzlichem Druckwechsel, das eine Airbag-Entfaltung während einer Kollision gemäß einer oder mehreren Ausführungsformen angibt. Die vertikale Achse ist Druck (kPA) und die horizontale Achse ist Zeit (Sekunden). Eine Druckänderung kann von einem Barometer der Kollisionsvorrichtung erhalten werden. Die Drucksignatur zeichnet sich durch einen plötzlichen Druckanstieg aus einem Nullbasisdruck (Anstiegszeit) aus, gefolgt von einer Rückkehr zu dem Basisdruck über eine spezifizierte Dauer. Die Signatur kann empirisch aus z. B. Kollisiontestdaten erhalten werden.
4E ist ein Diagramm eines großen GPS-Geschwindigkeitsabfalls, der eine Fahrzeugkollision angibt, gemäß einer oder mehreren Ausführungsformen. Die vertikale Achse ist GPS-Geschwindigkeit und die horizontale Achse ist Zeit. Die Geschwindigkeitssignatur zeichnet sich durch einen großen Geschwindigkeitsabfall von einer Nenngeschwindigkeit zu einer niedrigeren Geschwindigkeit über eine spezifizierte Dauer aus. Die Signatur kann empirisch aus z. B. Kollisiontestdaten erhalten werden.
5A ist ein Diagramm der Trägheitsbeschleunigung gemäß einer oder mehreren Ausführungsformen. Der Beschleunigungsmesser in der IMU wird verwendet, um eine plötzliche Verzögerung während des Aufpralls einer Kollision zu messen. Die normalisierte durchschnittliche Verzögerung wird wie in Gleichung [1] gezeigt, aus den horizontalen Komponenten der Beschleunigung α_x, α_y berechnet: $A v e D e c e l e r a t i o n = {‖ \sum_{t} 〚 (a_{x} 〛, a_{y}) ‖}_{2}$
5B ist ein Diagramm der normalisierten horizontalen Beschleunigung, die eine Kollision anzeigt. Die in der Figur gezeigte Kollisionsimpulsdauer zeigt eine Kollision an.
5C ist ein Histogramm der Wahrscheinlichkeit als Funktion der Spitzenverzögerung für aggregierte (z. B. auf die breite Masse bezogene) Verzögerungsimpulse gemäß einer oder mehreren Ausführungsformen. Die vertikale Achse ist die Wahrscheinlichkeit und die horizontale Achse ist eine Spitzenverzögerung. Auf die breite Masse bezogene falsch Positive und richtig Positive werden gezeigt. Die auf die breite Masse bezogenen Daten wurden von Testvorrichtungen gesammelt, um falsche Positive (keine Kollisionen) und richtig Positive (Kollisionen) zu bestimmen. Wie zu beobachten ist, ist die Verzögerungsimpulssignatur ein guter Indikator für eine Kollision, wenn die Spitzenbeschleunigung größer als 5 g ist.
6A ist ein Diagramm einer nominalen Airbagdrucksignatur aufgrund der Entfaltung während einer Kollision gemäß einer oder mehreren Ausführungsformen. Diese Funktion erkennt große Druckstörungen, die durch eine Airbag-Entfaltung und Kabinenverformung verursacht werden. Die Bedeutung dieses Merkmals besteht darin, dass sich Airbags in einer schweren Kollision mit dreimal so hoher Wahrscheinlichkeit entfalten, was dieses Merkmal zu einem guten Indikator einer schweren Kollision macht. Die vertikale Achse ist Druck (kPa) und die horizontale Achse ist Zeit (ms). Es wird die nominale Airbagdrucksignatur gezeigt, die durch eine plötzliche Druckspitze über eine spezifizierte Dauer gekennzeichnet ist.
6B ist ein Diagramm der Wahrscheinlichkeit als Funktion des Spitzendrucks für aggregierte Spitzendruckstörungen. Es werden auf die breite Masse bezogene falsch Positive (keine Kollision) und richtig Positive (Kollision) gezeigt. Wie zu erkennen ist, ist die Airbagdrucksignatur ein guter Indikator einer Kollision, wenn der Druck etwa 0,5 kPa überschreitet.
7A ist ein Diagramm, das einen Schalldruckpegel (SPL) während einer Kollision gemäß einer oder mehreren Ausführungsformen zeigt. Die vertikale Achse ist Schalldruckpegel (dB) und die horizontale Achse ist Zeit (ms). Es werden die menschliche Schmerzschwelle sowie ein Presslufthammer-SPL in einem Abstand von 2 m gezeigt. Während einer Kollision steigt ein SPL-Bersten innerhalb einer spezifizierten Dauer (z. B. 200 ms) über 130 dB an.
Als Schallmerkmale können Airbag-Entfaltung und Metall- und Glasbruchtöne verwendet werden. Schallmerkmale sind weniger empfindlich gegenüber Autofenstern, die geschlossen werden, als die Luftdrucksignatur, die unter Bezugnahme auf 6C beschrieben wird. Schallmerkmale weisen eine hohe Datenrate auf, die zahlreiche Frequenzbandmerkmale bietet. Schallmerkmale sind auch unabhängig vom gekoppelten oder projektilartigen Zustand der Kollisionsvorrichtung.
7B ist ein Histogramm der Wahrscheinlichkeit als Funktion der SPL-Berstdauer. Auf die breite Masse bezogene falsch Positive und richtig Positive werden gezeigt. Dieses Histogramm zeigt, dass die Berstdauer von SPL über 130 dB innerhalb von 200 ms ein guter Indikator für eine Kollision ist.
8 ist ein Zustandsmaschinendiagramm zum Auslösen eines Notsignals (nachstehend „SOS-Signal“) gemäß einer oder mehreren Ausführungsformen. Wenn eine Kollision erkannt wird, wird zur SOS-Zustandsmaschine 303 (3) übergegangen. Die SOS-Zustandsmaschine 303 synchronisiert den Fluss mit sowohl lokalen als auch gepaarten Vorrichtungskollisionsprozessen. In einigen Ausführungsformen schließt die SOS-Zustandsmaschine 303 die Zustände ein: INAKTIV 801 POTENZIAL 802, STAGING 803, BENACHRICHTIGEN 804 UND VERARBEITEN 805.
Wenn der Niederleistungsprozessor 301 (3) ein Kollisionsauslöserereignis erkennt, geht die SOS-Zustandsmaschine 303 zu POTENZIAL 802 über. Wenn die Inferenzmaschine 308 eine richtige Kollision annimmt, geht die SOS-Zustandsmaschine 303 zu STAGING 803 über; anderenfalls geht die SOS-Zustandsmaschine 303 zurück zur INAKTIV 801. Wenn die SOS-Zustandsmaschine 3030 in STAGING 803 ist und eine gepaarte Vorrichtung eine richtige Kollision erkennt, geht die SOS-Zustandsmaschine 303 zu VERARBEITEN 805 über. Wenn die SOS-Zustandsmaschine 303 in INAKTIV 801 ist und eine gepaarte Vorrichtung eine richtige Kollision erkennt, geht die SOS-Zustandsmaschine 303 zu VERARBEITEN 805 über.
Nach dem Warten für ein Zeitintervall (einem Fenster für die Koordination einer gepaarten Vorrichtung) in STAGING 803 geht SOS-Zustandsmaschine 303 zu BENACHRICHTIGEN 804 über. Nach dem Benachrichtigen der gepaarten Vorrichtung über eine richtige Kollision geht die SOS-Zustandsmaschine 303 zu VERARBEITEN 805 über. Die SOS-Zustandsmaschine 303 geht zu INAKTIV 801 über, wenn die SOS-Warnung beendet ist oder das System eine Zeitbegrenzung überschreitet oder eine Kollisionentscheidung durch die SOS-UI-Eskalation verworfen wird.
9A ist eine Zeitlinie 900 zum sicheren Benachrichtigen eines Benutzers nach einer erkannten Kollision gemäß einer oder mehreren Ausführungsformen. Jede Interaktion mit einer Kollisionsvorrichtung während des Fahrens kann störend sein. Somit wird die UI-Benachrichtigung verzögert durch Erfassen, dass sich die Kollisionsvorrichtung nicht bewegt (auch als „Stationarität“ bezeichnet), und/oder es anderweitig eine sichere Zeit ist, um eine Benachrichtigung darzustellen. Stationarität kann durch eine Anzahl von Erfassungsmodalitäten bestimmt werden, einschließlich, aber nicht beschränkt auf: GNSS, WIFI, Höhenmesser und Integration mit dem Computer des Fahrzeugs (z. B. Tachometer).
In der Zeitlinie 900 beginnt das UI-Eskalationsfenster 901 X Sekunden, nachdem eine Kollision erkannt wird, und wird für einen spezifizierten Zeitraum fortgesetzt. Im Falle einer Kollision ist ein Fahrzeug des Benutzers oft nicht sofort stationär und/oder das Fahrzeug wird stationär, aber der Benutzer fährt weiter, um sich zu einem sicheren Ort (z. B. Standstreifen einer Autobahn) zu begeben. In solchen Szenarien soll für eine ausreichende Dauer einer Stationarität gewartet werden, bevor die Benachrichtigung präsentiert wird, um sicherzustellen, dass der Benutzer im Stillstand ist. Wenn keine Stationarität durch die Erfassungsmodalitäten bestimmt werden kann, wird eine Benachrichtigung (z. B. eine UI mit Wohlbefindensprüfung) auf einer Anzeige der Kollisionsvorrichtung dargestellt. Wenn eine falsch positive Kollision erkannt wird und der Benutzer mit Fahrgeschwindigkeit weiterfährt, läuft die Benachrichtigung nach dem Warten einer Dauer, die zum Erkennen von Stationarität ausreicht, ab.
9B ist eine beispielhafte Zustandsmaschine 902 zum Steuern des UI-Eskalationsflusses gemäß einer oder mehreren Ausführungsformen. Wenn eine schwerere Kollision erkannt wird, wartet die Zustandsmaschine 902 für eine vorbestimmte Zeitdauer (z. B. unter Verwendung eines Zählers), wie durch eine oder eine Kombination von Erfassungsmodalitäten bestimmt, auf die Stationarität 903. Wenn die Stationaritätszählung einen Schwellenwert erreicht (z. B. größer oder gleich einem Schwellenwert), geht die Zustandsmaschine 902 in einen Eskalationszustand 904 über und ein UI-Eskalationsfenster 901 wird auf der Kollisionsvorrichtung dargestellt.
In einigen Ausführungsformen schließt eine Stationaritätsprüfung, die vor einer UI-Benachrichtigung erfüllt werden muss, ein Erfüllen einer spezifizierten GPS-Geschwindigkeit-Schwellengeschwindigkeit (z. B. 3 mph) und das Erfüllen einer spezifizierten Zeitzahl (z. B. >= 30 Sekunden) ein. Ein Zeitzähler wird zurückgesetzt, wenn die GPS-Geschwindigkeit einen spezifizierten Schwellenwert erreicht (z. B. >5 mph). Wenn die GPS-Geschwindigkeit nicht verfügbar ist, wird der Vorgang nicht durchgeführt. In einigen Ausführungsformen weist die Prüfung auf Stationarität mehrere Randbedingungen auf. Zum Beispiel eskaliert die UI nicht vor P Sekunden (z. B. 20 Sekunden), und wenn sie nicht um Q Sekunden (z. B. 60 Sekunden) eskaliert wird, wird die GPS-Historie auf die vergangenen M Abtastungen (z. B. 10 Abtastungen) überprüft, und die UI wird dann unter Verwendung eines stärker entspannten Stationaritätsprüfung eskaliert. Ein Beispiel für eine entspannte Stationaritätsprüfung schließt eine äquivalente Stationaritätsabtastung, wie die GPS-Geschwindigkeit, die einen Schwellenwert erfüllt, oder einen fehlenden GPS-Abtastwert, und eine Anzahl von äquivalenten Stationaritätsabtastwerten ein, die einen spezifizierten Schwellenwert Z von W Abtastwerten (Z. B. 8 von 12 Abtastwerten) erfüllen.
10 veranschaulicht die Verwendung mehrerer Vorrichtungen zum Erkennen von Kollisionen gemäß einer oder mehreren Ausführungsformen. Während einer Fahrzeugkollision erkennen mehrere Vorrichtungen 1001, 1002 in dem Fahrzeug Kollisionssignaturen, einschließlich, aber nicht beschränkt auf Smartwatches, Smartphones und Tablet-Computer. Durch Kombinieren der Informationen von den mehreren Vorrichtungen 1001, 1002 nimmt die Kollisionserkennungsleistung zu. Da die Fahrzeugumgebung während einer Kollision ähnliche Kollisionssignaturen in Kollisionsvorrichtungen aufweist, werden in einigen Ausführungsformen alle verfügbaren Kollisionsvorrichtungen und ihre jeweiligen Erfassungsmodalitäten verwendet, um Kollisionsdaten zu kombinieren, um eine Kollision mit der höchsten Konfidenz zu erkennen. In dieser Ausführungsform werden Kollisionsdaten von den Kollisionsvorrichtungen 1001, 1002 gemeinsam genutzt, und wenn die Kollisiondaten angeben, dass beide Kollisionsvorrichtungen 1001, 1002 Kollisionen erkennen, wird die Arbitrierungslogik verwendet, um vorzugsweise eine der Kollisionsvorrichtungen 1001, 1002 auszuwählen, um die UI-Eskalation anzuheben.
Unter erneuter Bezugnahme auf 10 wirken die Kollisionsvorrichtung 1001 (z. B. eine Smartwatch) und die Kollisionsvorrichtung 1002 (z. B. ein Smartphone) in bidirektionalen Nachrichten zusammen, um kollisionbezogene Merkmale anzufordern und zu senden. In dem gezeigten Beispiel wertet die Kollisionsvorrichtung 1001 Kollisionmerkmale durch das Erfassen von Modalitäten aus, und sendet die Merkmale an die Kollisionsvorrichtung 1002. In ähnlicher Weise wertet die Kollisionsvorrichtung 1002 Kollisionsmerkmale aus, die durch ihre eigenen Erfassungsmodalitäten erkannt werden, und sendet diese Merkmale an die Kollisionsvorrichtung 1001. Jede Kollisionsvorrichtung 1001, 1002 kombiniert ihre lokal erkannten und empfangenen Kollisionmerkmale, um darauf zu schließen, dass eine schwere Kollision aufgetreten ist. Wenn auf eine schwere Kollision geschlossen wird, initiiert die Kollisionsvorrichtung 1001 die UI-Eskalation und die Kollisionsvorrichtung 1002 deeskaliert die UI-Eskalation, da die UI-Eskalation von der Kollisionsvorrichtung 1001 gehandhabt wird.
11 veranschaulicht einen Querschnitt eines Softwarestacks 1100 zur Kollisionserkennung gemäß einer oder mehreren Ausführungsformen. Unter Bezugnahme auf die linke Figur aggregiert der Niederleistungsprozessor 301 Rohsensordaten von verschiedenen Sensordatenströmen, wie IMU-Daten (Beschleunigung, Drehzahl, Höhe), Barometer (Druckänderung), Audio (Audioabtastwerte, die von Mikrofon(en) erfasst werden) und GPS-Daten (z. B. GPS-Geschwindigkeit). Die Sensordaten werden nach einem Kollisionsauslöserereignis an den Anwendungsprozessor 302 gesendet. Wenn eine Begleitvorrichtung (z. B. Smartphone) verfügbar ist, werden Kollisionsmerkmale auch dem Anwendungsprozessor 302 durch eine drahtlose Kommunikationsverbindung (z. B. Bluetooth) zwischen der Kollisionsvorrichtung und der Begleitvorrichtung bereitgestellt.
Der Erkennungsdienst 305, der auf dem Anwendungsprozessor 302 läuft, implementiert eine Flusssteuerung 1101, der eine Kollisionserkennungsverarbeitungspipeline verwaltet, die eine multimodale Merkmalsschicht 306 Schätzschicht 307 und Inferenzschicht 308 einschließt. Die Inferenzschicht 308 gibt eine Entscheidung der schweren Klasse auf der Grundlage von Kollisionsentscheidungen aus, die durch Maschinenlernmodelle ausgegeben werden, die eine Schätzschicht 307 implementiert haben, und sendet die Entscheidung der schweren Kollision an SOS-Zustandsmaschine 303. Die SOS-Zustandsmaschine 303 initiiert eine UI-Eskalation 1102 oder eine Deskalation unter Verwendung von Zeitgebern, Countdowns und ob der Benutzer auf die UI-Eskalation reagiert (z. B. einen SOS-Anruf initiiert oder abbricht).
Wie im unteren Teil von 11 gezeigt, kombiniert der Erkennungsdienst 305 in einem ersten n-zweiten Fenster (z. B. n=1 s) die Sensordatenströme miteinander und sortiert die Ströme für die Flusssteuerung 1101. Die Flusssteuerung 1101 teilt die Ströme wieder in N Mess-/Beobachtungsepochen (z. B. N=4). Die Ströme werden in die Merkmalsschicht 306 eingegeben, die Merkmale aus den Sensorströmen extrahiert und einen Merkmalsvektor pro Epoche ausgibt, der alle Merkmale einschließt.
Der Merkmalsvektor pro Epoche wird in die Schätzschicht 307 eingegeben, die Kollisionsentscheidungen (z. B. Kollision, Überschlag, Airbag-Entfaltung, Aufprallenergie usw.) basierend auf verschiedenen Sensordaten unter Verwendung von Maschinenlernmodellen berechnet. Die Ausgabe der Schätzschicht 307 wird in die Inferenzschicht 308 eingegeben, die basierend auf einem Schweregradmodell vorhersagt/schlussfolgert, dass eine schwere Kollision aufgetreten ist. Zum Beispiel erzeugt die Inferenzschicht 308 eine Wahrscheinlichkeit, dass eine schwere Kollision aufgetreten ist, wenn die Wahrscheinlichkeit eine spezifizierte Schwellenwahrscheinlichkeit erfüllt (z. B. überschreitet).
12A veranschaulicht eine Zeitausrichtung für eine multimodale Kollisionserkennung für einen Nennfall auf einer einzelnen Vorrichtung gemäß einer oder mehreren Ausführungsformen. In diesem Beispiel werden 4 Epochen gezeigt: P₀, P₁, P₂ und P₃ und es gibt einen Merkmalsvektor pro Epoche. In einigen Ausführungsformen dauert eine Epoche n-Sekunden und die Epochen überlappen sich zeitlich (z. B. 50 % Überlappung). Im gezeigten Beispiel überlappt P₁ P₀ und P₂, und P₂ überlappt P₁ und P₃. In diesem Beispiel sind die Epochen, die das Unfallereignis enthalten, P₁ und P₂. In Epochen P₁ und P₂ wird der Verzögerungsimpuls-Merkmalsbericht auf IMU=Wahr gesetzt (ein Verzögerungsimpuls wurde erkannt) und der Audiomerkmalsbericht wird auf isAudio=Wahr gesetzt (Audio der Kollision wurde erfasst). In diesem Beispiel vereinigen die Kollisions- und Überschlagmodelle in der Schätzschicht 307 diese Merkmale, um eine Kollisionsentscheidung (eine Kollision wurde erkannt) bzw. Überschlagentscheidung (der Aufprall war eine Überschlagkollision, die in der Regel schwerer ist) zu treffen.
12B veranschaulicht die Verwendung von 4-Sekunden-Epochen mit 50 % Überlappung, die in die Merkmalsschicht 306 eingegeben werden, die einen Merkmalsvektor pro Epoche ausgibt, der dann in die Schätzschicht 308 eingegeben wird, die Kollisions- und Überschlagkollisionentscheidungen ausgibt.
13A-13C veranschaulichen die Modellierung falsch positiver Risiken aufgrund von Zeitsteuerung gemäß einer oder mehreren Ausführungsformen. Im gezeigten Beispiel sind die überlappenden Epochen P₀, P₁, P₂ und P₃ die gleichen wie in 12A gezeigt. In 13A enthalten P₁ und P₂ ein IMU-Ereignis und ein Audioereignis, wenn die Ereignisse durch eine Zeitverzögerung t_delay getrennt sind, die kleiner als 2 Sekunden ist. In 13B enthält keine Epoche sowohl das IMU- als auch das Audioereignis, wenn die Ereignisse durch eine Zeitverzögerung t_delay getrennt sind, die größer als 2 Sekunden ist. 13C veranschaulicht, dass die Wahrscheinlichkeit, dass beide Ereignisse in dieselbe Epoche fallen, 100 % beträgt, wenn t_delay kleiner als 2 Sekunden ist. Dementsprechend müssen die Merkmale um nicht mehr als 2 Sekunden zeitlich getrennt sein, um falsch Positive zu reduzieren.
14A und 14B veranschaulichen das Abgleichen von Epochen über zwei Vorrichtungen gemäß einer oder mehreren Ausführungsformen. Die oberen Abschnitte von 14A und 14B veranschaulichen die Epochen W₀, W₁ und W₂ für eine erste Kollisionsvorrichtung (z. B. eine Smartwatch), und die unteren Abschnitte von 14A und 14B veranschaulichen die Epochen P₀, P₁ und P₂ für eine zweite Kollisionsvorrichtung (z. B. ein Smartphone).
Um Fehlausrichtungen zwischen Epochengrenzen zu handhaben, ist eine Zone von zurückgehaltenen Epochen definiert als: $t (W_i - 2 \leq (P_j) < t (W_i) + 2,$ wobei die „2“-Werte von links nach rechts in Gleichung [2] nachstehend als Rückblickzeit lookBackTime bzw. Vorschauzeit lookForwardTime bezeichnet werden und gemäß 13A-13C abgeleitet werden. Die Epochen, die in die Zone von zurückgehaltenen Epochen fallen, haben eine Überlappung von mehr als oder gleich 50 %. Die Zone der zurückgehaltenen Epochen verlängert den falsch positiven Bereich auf +/- 6 Sekunden, wie in 14B gezeigt. In einigen Ausführungsformen wird die Vorschauzeit lookForwardTime durch Einführen einer Verzögerung unter Verwendung eines Puffers (Verzögerungspuffergröße delauBufferSize) auf der ersten Vorrichtung zur Datenverarbeitung erreicht, wodurch die Remoteaudiodatenzeit erreicht werden kann.
15 veranschaulicht einen Erkennungsdienst (z. B. Erkennungsdienst 305 in 3) gemäß einer oder mehreren Ausführungsformen. In einigen Ausführungsformen kann der Erkennungsdienst die Ausführung auf einer ersten Vorrichtung 1500 (z. B. einer Smartwatch) verzögern, um der zweiten Vorrichtung 1501 (z. B. einem Smartphone) Zeit zu ermöglichen, um Audioergebnisse zu senden. Sensordaten werden gepuffert und die Verarbeitung um N Sekunden (z. B. N=5) verzögert. Die Flusssteuerung und die Verarbeitung werden gelöscht, wenn inaktive und empfangene Audiorahmen gespeichert und auf das nächste Triggerereignis angewendet werden. Die Audiorahmen werden innerhalb eines Zeitfensters gespeichert und verarbeitet [lookBackTime, +lookForwardTime].
Unter erneuter Bezugnahme auf 15 beobachtet die erste Vorrichtung 1500 (z. B. eine Smartwatch) ein Kollisionauslöserereignis und löst die zweite Vorrichtung 1501 (z. B. ein Smartphone 1501) aus. Als Reaktion darauf sendet die zweite Vorrichtung 1501 ein Audioergebnis alle N Sekunden an die erste Vorrichtung 1500, die von der ersten Vorrichtung 1501 gepuffert wird. Die erste Vorrichtung 1501 verzögert die Verarbeitung um N Sekunden (N=5), initialisiert dann eine Auslösesitzung und eine Flusssteuerung 1101. Die Flusssteuerung 1101 liefert Audioergebnisse, die gepuffert wurden, und beginnt, das von der zweiten Vorrichtung 1501 empfangene Audio zu epochieren.
16 veranschaulicht einen Verzögerungspuffer 1600, der bewirkt, dass die Kollisionsvorrichtung für einen vorbestimmten Zeitraum vor der Verarbeitung pausiert, gemäß einer oder mehreren Ausführungsformen. Der obere Abschnitt von 16 ist der Prozessfluss auf der ersten Vorrichtung 1500 (z. B. Smartwatch), und der untere Abschnitt von 16 ist der Prozessfluss auf der zweiten Vorrichtung 1501 (z. B. Smartphone). Bei der zweiten Vorrichtung 1501 startet der Erkennungsdienst 1601 die Flusssteuerung 1101, die die 4-Sekunden-Epochen mit 50 % Überlappung verarbeitet, die in die Merkmalsschicht 306 eingegeben werden. Die Merkmale werden drahtlos an die erste Vorrichtung 1500 gesendet, wo sie 5 Sekunden lang im Verzögerungspuffer 1600 gespeichert werden, bevor sie durch die Flusssteuerung 1101 verarbeitet und in die Merkmalsschicht 306 eingegeben werden. Die Ausgabe der Merkmalsschicht 306 schließt multimodale Merkmale ein, die von der zweiten Vorrichtung 1501 empfangen werden (z. B. isAudio), die mit anderen Merkmalen (z. B. isIMU), die auf der ersten Vorrichtung 1500 erzeugt werden, zu einem einzelnen Merkmalsvektor kombiniert werden. Der Merkmalsvektor wird dann in die Schätzschicht 307 eingegeben, die Kollisionsentscheidungen erzeugt, wie zuvor unter Bezugnahme auf 3 beschrieben.
17 veranschaulicht ein verteiltes und geschlossenes System 1700 zum aktiven Modifizieren des Kollisionserkennungsverhaltens gemäß einer oder mehreren Ausführungsformen. Das System 1700 ist ein verteiltes geschlossenes Kollisionserkennungssystem, das eine dynamische Änderung des Verhaltens basierend auf Feldstatistiken ermöglicht. In einigen Ausführungsformen schließt das System 1700 Kollisionserkennungsvorrichtungen 1701 (z. B. Smartwatches, Smartphones) ein, die Erkennungsereignisse an den Analyseprozessor 1702 senden, der auf einem oder mehreren Netzwerkservercomputern arbeitet. Die Kollisionserkennungsvorrichtungen 1701 senden auch Algorithmusmerkmalswerte an den Backend-Analyseprozessor 1703, der auf dem einen oder den mehreren Netzwerkdienstcomputern arbeitet. Der Analyseprozessor 1702 erzeugt Erkennungsstatistiken, die an den OTA-Aktualisierungsprozessor 1704 des Luftaktuators gesendet werden, der neue Algorithmusparameter auf die Kollisionserkennungsvorrichtungen 1701 pusht, wie unter Bezugnahme auf 18 ausführlicher beschrieben.
18A und 18B veranschaulichen eine Softwarearchitektur 1800 für eine groß angelegte Datensammlung und -verarbeitung gemäß einer oder mehreren Ausführungsformen. Insbesondere erzeugt das System 1800 neue Algorithmusparameter für Kollisionserkennungsalgorithmen, die auf Kollisionsvorrichtungen im Feld ausgeführt werden.
Sensorströme (z. B. Audio, Axialkopf, GPS-Geschwindigkeit, Druck, Beschleunigung, Vorrichtungsbewegung usw.) werden erfasst/abgetastet und im Speicher 1801 der Kollisionsvorrichtung(en) gespeichert. In einigen Ausführungsformen werden die Audiodaten in SPL-by-SPL-Berechnung 1802 auf den Kollisionsvorrichtungen umgewandelt und der SPL wird im Speicher 1801 gespeichert. Der IMU-Auslöser 1803 erzeugt Kollisionsauslöserereignisse basierend auf Vorrichtungsbewegungsdaten. In einigen Ausführungsformen empfängt der IMU-Auslöser 1803 auch Fahrzustandsdaten von dem Aktivitätsklassifikator 1804, der auf den Kollisionsvorrichtungen ausgeführt wird. Die Fahrzustandsdaten zeigen z. B. basierend auf einem Klassifikator, der auf verschiedene Sensordaten angewendet wird (z. B. Beschleunigung), dass die Kollisionsvorrichtung (und damit der Benutzer) derzeit in einem Fahrzeug fährt. In einigen Ausführungsformen, wenn die Fahrzustandsdaten angeben, dass sich die Kollisionsvorrichtung nicht in einem Fahrzeug befindet, erfolgt der Auslöser nicht. Wenn der IMU-Auslöser 1803 einen Kollisionsereignisauslöser erkennt, startet ein Startdaemon 1805 den Anomalieerkennungsdaemon 1806.
Der Anomalieerkennungsdaemon 1806 wird kontinuierlich auf den Kollisionsvorrichtungen in der Feldüberwachung für Kollisionauslöserereignisse ausgeführt. In einigen Ausführungsformen wird ein Prüfen des Mobilprofils 1807 der Benutzer durchgeführt, um zu bestimmen, ob die Benutzer zugestimmt haben, Kollisionsdaten mittels ihrer Kollisionsvorrichtung 1808 zu teilen. Wenn die Benutzer zugestimmt haben, sammelt der Daemon 1806 die Kollisionsdaten 1809 (z. B. Merkmale, Schätzungen, Inferenz, SOS-UI-Eskalationen) und sendet Kollisionsdaten 1809 an den Hochlader 1810, der Kollisionsdaten 1809 an den Sicherungsdatenprozessor-Endpunkt 1811 sendet (z. B. implementiert auf Netzwerkservercomputern). Der Sicherungsdatenprozessor-Endpunkt 1811 ist eine groß angelegte Datenverarbeitungsarchitektur, die eine Vielzahl von virtuellen Maschinen 1813 zum Simulieren von Kollisionsinformationen hostet, die von Kollisionsvorrichtungen gesammelt wurden. Zum Beispiel simulieren virtuelle Maschinen 1813 (auch als „Replay“ bezeichnet) Kollisionsereignisse unter Verwendung der Kollisiondaten, um zu bestimmen, ob neue Algorithmusparameter (z. B. Schwellenwerte, Gewichte, Koeffizienten usw.) für die installierte Basis von Kollisionsvorrichtungen im Feld erzeugt werden müssen. Die neuen Parameter werden durch Mobile-Assets-Endpunkt/-Server 1815 auf die Kollisionsvorrichtungen heruntergeladen. Die Parameter werden mit den neuen Algorithmusparametern aktualisiert.
19 ist ein Zustandsmaschinendiagramm, das das Hochladen von Kollisionsdaten auf den Sicherungsdatenprozessorendpunkt 1811 gemäß einer oder mehreren Ausführungsformen veranschaulicht. Das Ziel des Daemons 1806 besteht darin, Kollisionsdaten auf den Sicherungsdatenprozessor-Endpunkt 1811 hochzuladen, sodass die Daten parallel durch Speicher-/CPU-intensive Algorithmen ausgeführt werden können, um eine Charge von Sensordaten in Kollisionserkennungs- und Nichtkollisionserkennungsereignisse zu klassifizieren, wie unter Bezugnahme auf 20 ausführlicher beschrieben.
In einigen Ausführungsformen werden die Zustände des Daemon 1806 in drei Typen klassifiziert: Inaktiv 1901, Erkennen 1902 und Hochladen 1903. Wenn eine Kollisionsvorrichtung eingeschaltet wird, ist der Anwendungsprozessor 302 konfiguriert, um einen Dienst zu starten, um eine Konfiguration für die Kollisionsvorrichtung von dem Mobile-Asset-Endpunkt 1813 herunterzuladen (siehe 18). IDLE-Daemon 1901 (inaktiv) wartet auf Nachrichten (z. B. Interprozess-Kommunikationsnachrichten) vom Niederleistungsprozessor 301. Als Reaktion auf die Nachrichten (Auslösernachricht) gibt der Anwendungsprozessor 302 ein Triggerereignis aus, das den Erkennungsdienst 305 startet (3). Die Kollisiondaten werden vom Erkennungsdienst 305 zum Hochladen an den Sicherungsdatenprozessor-Endpunkt 1812 gespoolt. Der Hochladedaemon 1806 lädt die Kollisiondaten auf den Sicherungsdatenprozessor-Endpunkt 1811.
20 ist ein Blockdiagramm eines Backend-Datenanalysesystems 2000 gemäß verschiedenen Ausführungsformen. Das System 2000 ist konfiguriert, um eine falsch positive Eskalationsrate zu identifizieren, die verwendet wird, um zu bestimmen, ob eine Verbesserung des Kollisionserkennungalgorithmus erforderlich ist. Ausgehend vom linken Teil von 20 wird ein durch den Niederleistungsprozessor 301 (3) erzeugtes Kollisionsauslöserereignis durch die Anreicherungsprüfung 2001 verarbeitet, um eine Wahrscheinlichkeit zu bestimmen, ob ein bestimmter Kollisionsereignisauslöser als tatsächlich eine Kollision (bestanden) oder keine Kollision (nicht bestanden) war. Der Auslöser wird auch an den Analyseserver 2002 gesendet. Die Ausgabe der Anreicherungsprüfung 2001 wird an den Sicherungsserver 2003 gesendet. Der Sicherungsserver 2003 teilt 2004 die Datenausgabe durch die Anreicherungsprüfung 2001 in die separaten Verarbeitungswege bestanden/nicht bestanden auf. Die Kollisionsdaten werden durch die Zurechnungsfähigkeitsprüfung 2005a, 2005b in den Verarbeitungswegen verarbeitet, und wenn die Daten die Zurechnungsfähigkeitsprüfungen 2005a, 2005b bestehen, werden die Kollisiondaten in die Kollisionsdetektoren 2006a, 2006b eingegeben, die die Kollisionereignisse unter Verwendung der Kollisiondaten für Bestehen (f_pass) und Nichtbestehen (f_fail) simulieren.
Die Ausgänge der Kollisiondetektoren 2006a, 2006b werden in den Invertabtaster 2007 eingegeben. Der Invertabtaster 2007 tastet die Kollisiondaten ab, bis eine vorspezifizierte Anzahl von Kollisionsauslöserereignissen beobachtet wird. In einigen Ausführungsformen wird die Anzahl der beobachteten Kollisionsauslöserereignisse vorbestimmt und die Abtastgröße ist eine zufällige Variable, die einer negativen Binomialverteilung folgt.
Die Ausgabe der Invertabtastung 2007 (f) wird durch Fahrstunden pro Auslöser T geteilt, was durch den Analyseprozessor 2002 berechnet wird, was die falsch positive Rate T/f ergibt. Die falsch positive Rate kann dann verwendet werden, um zu bestimmen, ob die auf den Kollisionsvorrichtungen ausgeführten Kollisionserkennungsalgorithmen beispielsweise mit neuen Abstimmungsparametern verbessert werden müssen.
21 veranschaulicht einen einstellbaren systeminternen Algorithmus gemäß einer oder mehreren Ausführungsformen. Aufgrund der großen Menge von auf die breite Masse bezogenen Kollisionsdaten wird ein abstimmbarer OTA-Betriebspunkt verwendet, wie in 21 gezeigt. Die OTA-Frequenz wird so abgestimmt, dass sie eine Balance zwischen Kollisionen mit dem niedrigsten Schweregrad (am häufigsten und wenigste Notwendigkeit von Hilfe) und Kollisionen mit dem höchsten Schweregrad (am seltensten, am meisten hilfebedürftig) trifft. 21 zeigt auch ein Diagramm von FP (Stunden pro Erkennung) als Funktion des OTA-Abstimmungsparameters. 21 zeigt auch ein Diagramm der Wahrscheinlichkeit einer schweren Verletzung als Funktion des OTA-Abstimmungsparameters. Es ist zu beachten, dass der OTA-Abstimmungsparameter so gewählt wird, dass er nur auf die schwersten Kollisionen und Kollisionen mit einer geringeren Wahrscheinlichkeit schwerer Verletzung abzielt.
Beispielprozess
22 ist ein Flussdiagramm eines Prozesses 2200 zur Kollisionserkennung, wie unter Bezugnahme auf 1-21 beschrieben. Der Prozess 2200 schließt die Schritte ein: Erkennen eines Kollisionereignisses auf einer Kollisionsvorrichtung (2201); Extrahieren multimodaler Merkmale aus Sensordaten, die durch mehrere Erfassungsmodalitäten der Kollisionsvorrichtung (2202) erzeugt werden; Berechnen mehrerer Kollisionsentscheidungen basierend auf mehreren Maschinenlernmodellen, die auf die multimodalen Merkmale angewendet (2203) werden; und Bestimmen, dass eine schwere Fahrzeugkollision aufgetreten ist, unter Einbeziehung der Kollisionsvorrichtung basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell (2204).
Jeder dieser Schritte wurde zuvor unter Bezugnahme auf 1-21 ausführlich beschrieben.
Beispielvorrichtungsarchitektur
23 ist ein Blockdiagramm einer Kollisionsvorrichtungsarchitektur 2300 zur Implementierung der in 1-22 beschriebenen Merkmale und Prozesse. Die Architektur 2300 kann eine Speicherschnittstelle 2302, einen oder mehrere Hardware-Datenprozessoren, Bildprozessoren und/oder Prozessoren 2304 und Peripheriegeräte-Schnittstellen 2306 einschließen. Die Speicherschnittstelle 2302, der eine oder die mehreren Prozessoren 2304 und/oder die Peripherieschnittstelle 2306 können separate Komponenten sein oder können in eine oder mehrere integrierte Schaltungen integriert sein. Die Systemarchitektur 2300 kann in jeder geeigneten elektronischen Vorrichtung zur Kollisionserkennung eingeschlossen sein, einschließlich, aber nicht beschränkt auf: eine Smartwatch, ein Smartphone, ein Fitnessband und eine beliebige andere Vorrichtung, die von einem Benutzer angebracht, getragen oder gehalten werden kann.
Sensoren, Vorrichtungen und Untersysteme können mit der Peripherieschnittstelle 2306 gekoppelt sein, um Mehrfachfunktionalitäten bereitzustellen. Zum Beispiel können ein oder mehrere Bewegungssensoren 2310, ein Lichtsensor 2312 und ein Näherungssensor 2314 mit der Peripherieschnittstelle 2306 gekoppelt sein, um die Bewegungserfassung (z. B. Beschleunigung, Rotationsraten), Beleuchtungs- und Näherungsfunktionen der am Körper tragbaren Vorrichtung zu erleichtern. Ein Ortungsprozessor 2315 kann mit der Peripherieschnittstelle 2306 verbunden werden, um eine Geo-Positionierung bereitzustellen. In einigen Implementierungen kann der Standortprozessor 2315 ein GNSS-Empfänger sein, wie der Global-Positioning-System- (GPS-) Empfänger. Ein elektronisches Magnetometer 2316 (z. B. ein Mikrochip) kann ebenfalls mit Peripherieschnittstelle 2306 verbunden sein, um Daten bereitzustellen, die verwendet werden können, um die Richtung des magnetischen Nordpols zu bestimmen. Das elektronische Magnetometer 2316 kann Daten an eine elektronische Kompassanwendung liefern. Ein oder mehrere Bewegungssensoren 2310 können einen oder mehrere Beschleunigungsmesser und/oder Gyroskope einschließen, die dafür ausgelegt sind, Änderungen der Geschwindigkeit und der Bewegungsrichtung bestimmen. Das Barometer 2317 kann konfiguriert sein, um den Atmosphärendruck (z. B. Druckänderung innerhalb eines Fahrzeugs) zu messen. Der Biosignalsensor 2320 kann eines oder mehrere von einem PPG-Sensor, einem Elektroenzephalogramm- (EEG-) Sensor, einem Elektrokardiogramm- (EKG-) Sensor, einem Elektromyogramm- (EMG-) Sensor, einem Mechanomyogramm- (MG-) Sensor (z. B. piezo-resistiven Sensor) zum Messen von Muskelaktivität/-kontraktionen, einem Elektrookulographie- (EOG-) Sensor, einem galvanischen Hautantwort- (GSR-) Sensor, einem Magnetencephalogramm- (MEG-) Sensor und/oder einem oder mehreren anderen geeigneten Sensoren, die konfiguriert sind, um Biosignale zu messen, sein.
Kommunikationsfunktionen können durch drahtlose Kommunikationsuntersysteme 2324 erleichtert werden, die Empfänger für Funkfrequenzen (RF-) und Sender (oder Sendeempfänger) bzw. optische (z. B. Infrarot-) Empfänger und Sender einschließen können, ermöglicht werden. Das jeweilige Design und die jeweilige Implementierung des Kommunikationsuntersystems 2324 können von dem bzw. den Kommunikationsnetz(en) abhängen, über das bzw. über die eine mobile Vorrichtung operieren soll. Zum Beispiel kann die Architektur 2300 Kommunikationssubsysteme 2324 einschließen, die dafür ausgelegt sind, über ein GSM-Netz, ein GPRS-Netz, ein EDGE-Netz, ein Wi-Fi™-Netz und ein Bluetooth™-Netz zu arbeiten. Insbesondere können die drahtlosen Kommunikationsuntersysteme 2324 Hosting-Protokolle einschließen, sodass die Kollisionsvorrichtung als Basisstation für andere drahtlose Vorrichtungen konfiguriert werden kann.
Ein Audio-Untersystem 2326 kann mit einem Lautsprecher 2328 und einem Mikrophon 30 gekoppelt sein, um sprachgestützte Funktionen zu unterstützen, beispielsweise Stimmerkennung, Stimmreplikation, digitales Aufzeichnen und Telefoniefunktionen. Das Audiosubsystem 2326 kann dafür ausgelegt sein, Sprachbefehle vom Benutzer zu empfangen. Das Audiosubsystem 2326 kann verwendet werden, um Audio während einer Kollision zu erfassen und das Audio in SPL für die Kollisionserkennungsverarbeitung umzuwandeln.
Das E/A-Subsystem 2340 kann eine berührungsempfindliche Steuerung 2342 und/oder eine oder mehrere andere Eingabesteuerungen 2344 einschließen. Die berührungsempfindliche Steuerung 2342 kann mit einer berührungsempfindlichen Oberfläche 2346 oder gekoppelt sein. Die berührungsempfindliche Oberfläche 2346 und die berührungsempfindliche Steuerung 2342 können beispielsweise einen Kontakt und eine Bewegung oder eine Unterbrechung davon unter Verwendung einer beliebigen von einer Mehrzahl von auf Berührungsempfindlichkeit basierenden Technologien, unter anderem mit auf Kapazität, Widerstand, Infrarot- und Oberflächenakustikwellen basierenden Technologien, ebenso wie anderer Näherungssensor-Arrays oder anderer Elemente zur Bestimmung eines oder mehrerer Kontaktpunkte mit der berührungsempfindlichen Oberfläche 2346, erkennen. Die Berührungsoberfläche 2346 kann zum Beispiel einen Touchscreen oder die digitale Krone einer Smartwatch einschließen. Das E/A-Subsystem 2340 kann eine haptische Maschine oder Vorrichtung zur Bereitstellung eines haptischen Feedbacks (z. B. Vibrationen) in Reaktion auf die Befehle vom Prozessor 2304 einschließen. In einer Ausführungsform kann die berührungsempfindliche Oberfläche 2346 eine druckempfindliche Oberfläche sein.
Eine oder mehrere Eingabesteuerungen 2344 können mit anderen Eingabe-/Steuervorrichtungen 2348, wie einer oder mehreren Schaltflächen, mit Kippschaltern, einem Rändelrad, einem Infrarotanschluss und einem USB-Anschluss, gekoppelt sein. Die eine oder mehreren Schaltflächen (nicht dargestellt) können eine Lauter-/Leiser-Schaltfläche für eine Lautstärkeregelung des Lautsprechers 2328 und/oder eines Mikrofons 2330 einschließen. Die berührungsempfindliche Oberfläche 2346 oder andere Steuerungen 2344 (z. B. eine Schaltfläche) können Fingerabdruck-Identifikationsschaltungen zur Verwendung mit einer Fingerabdruck-Authentifizierungsanwendung einschließen oder daran gekoppelt sein, um einen Benutzer basierend auf dessen Fingerabdruck/-abdrücken zu authentifizieren.
In einer Umsetzung kann ein Drücken der Schaltfläche für eine erste Dauer eine Sperre der berührungsempfindlichen Oberfläche 2346 aufheben; und ein Drücken der Schaltfläche für eine zweite Dauer, die länger als die erste Dauer ist, kann die Stromzufuhr zu der mobilen Vorrichtung ein- oder ausschalten. Der Benutzer kann in der Lage sein, eine Funktionalität einer oder mehrerer der Schaltflächen individuell anzupassen. Die berührungsempfindliche Oberfläche 2346 kann beispielsweise auch verwendet werden, um virtuelle oder Soft-Tasten zu implementieren.
In einigen Umsetzungen kann die mobile Vorrichtung aufgezeichnete Audio- bzw. Videodateien, wie MP3-, AAC- und MPEG-Dateien, wiedergeben. In manchen Umsetzungen kann die mobile Vorrichtung die Funktionalität eines MP3-Players einschließen. Es können auch andere Eingabe-/Ausgabe- und Steuervorrichtungen verwendet werden.
Die Speicherschnittstelle 2302 kann mit einem Speicher 2350 gekoppelt sein. Der Speicher 2350 kann einen Hochgeschwindigkeitsspeicher mit wahlfreiem Zugriff und/oder einen nichtflüchtigen Hochgeschwindigkeitsspeicher einschließen, beispielsweise eine oder mehrere Magnetplattenspeichervorrichtungen, eine oder mehrere optische Speichervorrichtungen bzw. einen Flash-Speicher (z. B. NAND, NOR). Der Speicher 2350 kann das Betriebssystem 2352 speichern, wie das iOS-Betriebssystem, das von Apple Inc., Cupertino, Kalifornien entwickelt wurde. Das Betriebssystem 2352 kann Anweisungen zur Handhabung grundlegender Systemdienste und zur Durchführung Hardware-abhängiger Aufgaben einschließen. In manchen Implementierungen kann das Betriebssystem 2352 einen Kernel (z. B. einen UNIX-Kernel) einschließen.
Der Speicher 2350 kann auch Kommunikationsanweisungen 2354 speichern, um die Kommunikation mit einer oder mehreren zusätzlichen Vorrichtungen, einem oder mehreren Computern bzw. einem oder mehreren Servern zu ermöglichen, wie Anweisungen zum Implementieren eines Softwarestacks für verdrahtete oder drahtlose Kommunikationen mit anderen Vorrichtungen. Der Speicher 2350 kann Anweisungen der grafischen Benutzerschnittstelle 2356 einschließen, um die Verarbeitung der grafischen Benutzerschnittstelle zu erleichtern; Sensorverarbeitungsanweisungen 2358, um sensorbezogene Verarbeitung und Funktionen zu ermöglichen; Telefonanweisungen 2360, um telefonbezogene Prozesse und Funktionen zu erleichtern; Anweisungen für die elektronische Nachrichtenübermittlung 2362, um Prozesse und Funktionen zu ermöglichen, die sich auf die elektronische Nachrichtenübermittlung beziehen; Webbrowsing-Anweisungen 2364, um Prozesse und Funktionen zu ermöglichen, die sich auf das Webbrowsing beziehen; Medienverarbeitungsanweisungen 2366, um Prozesse und Funktionen zu erleichtern, die sich auf die Medienverarbeitung beziehen; GNSS-/Standortanweisungen 2368, um GNSS- und standortbezogene Prozesse und Anweisungen zu erleichtern; und Kollisionserkennungsanweisungen 2370, die die in Bezug auf 1-22 beschriebenen Kollisionserkennungsprozesse implementieren. Der Speicher 2350 schließt ferner andere Anwendungsanweisungen 2372 ein, einschließlich, aber nicht beschränkt auf Anweisungen für Anwendungen, die eine Kollisionserkennungsausgabe verwenden.
Jede der oben genannten Anweisungen und Anwendungen kann einem Satz von Anweisungen zur Durchführung einer oder mehrerer der oben beschriebenen Funktionen entsprechen. Diese Anweisungen müssen nicht als separate Software-Programme, Abläufe oder Module implementiert werden. Der Speicher 2350 kann zusätzliche Anweisungen oder weniger Anweisungen einschließen. Ferner können verschiedene Funktionen der mobilen Vorrichtung in Hardware und/oder in Software implementiert werden, einschließlich eines oder mehrerer Signalverarbeitungsschaltkreise und/oder eines oder mehrerer anwendungsspezifischer integrierter Schaltkreise.

Claims

Verfahren, dadurch gekennzeichnet, dass es folgendes umfasst: Erkennen eines Kollisionsereignisses an einer Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) mit mindestens einem Prozessor (301, 302, 1702, 1703, 2002, 2304); Extrahieren von multimodalen Merkmalen (306) aus Sensordaten, die durch mehrere Erfassungsmodalitäten der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) erzeugt werden, mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304); Berechnen mehrerer Kollisionsentscheidungen mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304), basierend auf mehreren Maschinenlernmodellen (307), die auf die multimodalen Merkmale (306) angewendet werden; und Bestimmen, dass eine schwere Fahrzeugkollision aufgetreten ist, mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304) unter Einbeziehung der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell (2204).
Verfahren nach Anspruch 1, ferner umfassend: als Reaktion auf das Bestimmen einer schweren Kollision das Darstellen einer Benachrichtigung (202) auf einem Bildschirm der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202), die eine Antwort von einem Benutzer der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) anfordert.
Verfahren nach Anspruch 2, ferner umfassend: Bestimmen, ob die Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) für einen vorbestimmten Zeitraum stationär ist; als Reaktion darauf, dass die Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) für den vorbestimmten Zeitraum stationär ist, Starten eines Zeitgebers oder Zählers; Bestimmen, dass der Zeitgeber oder Zähler eine Schwellenzeit bzw. -zahl erreicht; und Eskalieren der Benachrichtigung (202).
Verfahren nach Anspruch 3, ferner umfassend: als Ergebnis des Eskalierens Bestimmen, dass nach dem Erreichen der Schwellenzeit oder -zahl keine Antwort auf die Benachrichtigung (202) empfangen wurde, wobei unter Verwendung eines oder mehrerer Kommunikationsmodalitäten der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) automatisch Kontakt zu Notdiensten aufgenommen wird.
Verfahren nach Anspruch 1, ferner umfassend: Senden von mindestens einem der multimodalen Merkmale (306), Kollisionsentscheidungen, Inferenz einer schweren Kollision oder Benutzerinteraktionen mit der Benachrichtigung (202) an einen Netzwerkservercomputer; Empfangen mindestens einer Aktualisierung zu mindestens einem Parameter von mindestens einem Maschinenlernmodell (307) oder dem Schweregradmodell (2204) von dem Netzwerkserver; und Aktualisieren des mindestens einen Parameters mit der mindestens einen Aktualisierung mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304).
Verfahren nach Anspruch 1, wobei mindestens eines der multimodalen Merkmale (306) eine Verzögerungsimpulssignatur ist, die in Beschleunigungsdaten vorhanden ist.
Verfahren nach Anspruch 1, wobei mindestens eines der multimodalen Merkmale (306) ein Schalldruckniveau von Audiodaten ist, die von mindestens einem Mikrofon der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) erfasst werden.
Verfahren nach Anspruch 1, wobei mindestens eines der multimodalen Merkmale (306) eine Druckänderung aufgrund von Airbag-Entfaltung in dem Fahrzeug ist.
Verfahren nach Anspruch 1, wobei mindestens eines der multimodalen Merkmale (306) ein Geschwindigkeitsabfall der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) ist.
Verfahren nach Anspruch 1, ferner umfassend: Empfangen von kollisionsbezogenen Merkmalen von einer Begleitvorrichtung, die mit der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) gekoppelt ist, mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304); Berechnen mehrerer Kollisionsentscheidungen basierend auf mehreren Maschinenlernmodellen (307), die auf die multimodalen Merkmale (306) und absturzbezogenen Merkmale angewendet werden, mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304); und Ableiten, dass eine schwere Fahrzeugkollision aufgetreten ist, mit dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304) unter Einbeziehung der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell (2204).
Verfahren nach Anspruch 8, ferner umfassend: Abgleichen von Epochen für die multimodalen Merkmale (306) mit Epochen für die zusätzlichen multimodalen Merkmale (306), um Fehlausrichtung zwischen Epochengrenzen zu entfernen.
Einrichtung, umfassend: mindestens einen Bewegungssensor (2310); mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304); einen Speicher (1801, 2350), der Anweisungen (2364) speichert, die, wenn sie von dem mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304) ausgeführt werden, den mindestens einen Prozessor (301, 302, 1702, 1703, 2002, 2304) veranlassen, kennzeichnende Vorgänge durchzuführen, die Folgendes umfassen: Erkennen eines Kollisionsereignisses mindestens teilweise basierend auf Sensordaten von dem mindestens einen Bewegungssensor (2310); Extrahieren multimodaler Merkmale (306) aus Sensordaten, die durch mehrere Erfassungsmodalitäten der Einrichtung erzeugt werden; Berechnen mehrerer Kollisionsentscheidungen basierend auf mehreren Maschinenlernmodellen (307), die auf die multimodalen Merkmale (306) angewendet werden; und Ableiten, dass eine schwere Fahrzeugkollision aufgetreten ist, unter Einbeziehung der Einrichtung basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell (2204).
Einrichtung nach Anspruch 12, ferner umfassend: als Reaktion auf das Bestimmen einer schweren Kollision das Darstellen einer Benachrichtigung (202) auf einem Bildschirm der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202), die eine Antwort von einem Benutzer der Einrichtung anfordert.
Einrichtung nach Anspruch 13, ferner umfassend: Bestimmen einer Stationarität der Einrichtung; Starten eines Zeitgebers oder Zählers; Bestimmen, dass der Zeitgeber oder Zähler eine Schwellenzeit bzw. -zahl erreicht; und Darstellen der Benachrichtigung (202) auf dem Bildschirm der Einrichtung, die eine Antwort von einem Benutzer der Einrichtung anfordert.
Einrichtung nach Anspruch 14, ferner umfassend: Bestimmen, dass keine Antwort auf die Benachrichtigung (202) von dem Benutzer empfangen wurde; und automatisches Kontaktieren von Notdiensten unter Verwendung eines oder mehrerer Kommunikationsmodalitäten der Einrichtung.
Einrichtung nach Anspruch 12, wobei mindestens eines der multimodalen Merkmale (306) eine Verzögerungsimpulssignatur ist, die in Beschleunigungsdaten vorhanden ist.
Einrichtung nach Anspruch 12, wobei mindestens eines der multimodalen Merkmale (306) ein Schalldruckniveau von Audiodaten ist, die von mindestens einem Mikrofon der Einrichtung erfasst werden.
Einrichtung nach Anspruch 12, wobei mindestens eines der multimodalen Merkmale (306) eine Druckänderung aufgrund von Airbag-Entfaltung in dem Fahrzeug ist.
Einrichtung nach Anspruch 12, wobei mindestens eines der multimodalen Merkmale (306) ein Geschwindigkeitsabfall der Einrichtung ist.
Einrichtung nach Anspruch 12, ferner umfassend: Empfangen von kollisionsbezogenen Merkmalen von einer Begleitvorrichtung, die mit der Einrichtung gekoppelt ist; Berechnen mehrerer Kollisionsentscheidungen basierend auf mehreren Maschinenlernmodellen (307), die auf die multimodalen Merkmale (306) und absturzbezogenen Merkmale angewendet werden; und Ableiten, dass eine schwere Fahrzeugkollision aufgetreten ist, unter Einbeziehung der Kollisionsvorrichtung (1001, 1002, 1808, 2201, 2202) basierend auf den mehreren Kollisionsentscheidungen und einem Schweregradmodell (2204).
Einrichtung nach Anspruch 20, ferner umfassend: Abgleichen von Epochen für die multimodalen Merkmale (306) mit Epochen für die zusätzlichen multimodalen Merkmale (306), um Fehlausrichtung zwischen Epochengrenzen zu entfernen.
Einrichtung nach Anspruch 12, ferner umfassend: Senden von mindestens einem der multimodalen Merkmale (306), Kollisionsentscheidungen, Inferenz einer schweren Kollision oder Benutzerinteraktionen mit der Benachrichtigung (202) an einen Netzwerkserver; Empfangen mindestens einer Aktualisierung zu mindestens einem Parameter von mindestens einem Maschinenlernmodell (307) oder dem Schweregradmodell (2204); und Aktualisieren des mindestens einen Parameters mit der mindestens einen Aktualisierung.