Plötzliches Unvermögen durch Myokardinfarkt:
Kamerabasierte Erkennung, Einflussfaktoren und Anwendungsgrenzen
Vasiliy Seibert Hochschule Furtwangen
Fakultät Informatik Furtwangen, Deutschland vasiliy.sviyazov@hs-furtwangen.de
D
Sarah Moser Hochschule Furtwangen
Fakultät Informatik Furtwangen, Deutschland sarah.moser@hs-furtwangen.de
D
Alexander Garkawyj Hochschule Furtwangen
Fakultät Informatik Furtwangen, Deutschland alexander.garkawyj@hs-furtwangen.de
Abstract— Plötzliches Unvermögen ist strategisches Thema und Meilenstein auf der Euro-NCAP Roadmap für das Jahr 2025. Diese Arbeit widmet sich der Frage nach der Umsetzbarkeit und rechtlichen Rahmenbedingungen kamerabasierter Innenraumüberwachung im Hinblick auf die Erkennung plötzlichen Unvermögens durch Myokardinfarkt.
Nach einleitender Definition des Terminus „Plötzliches Unvermögen/Sudden Sickness“ erfolgt eine Übersicht der NCAP Anforderungen sowie ein Überblick über den aktuellen Forschungs- und Entwicklungsstand. Im Folgenden wird auf Anforderungen aus Verbraucher- und Datenschutzsicht eingegangen. Schwerpunkt dieses Papers bildet die Erstellung, Umsetzung und Bewertung von Use Cases zur Erkennung einer Sudden Sickness durch Myokardinfarkt. Abschließend werden offene Forschungsfragen erläutert. Ein experimentelles Beispielsystem wurde exemplarisch umgesetzt und evaluiert.
Die wesentlichen Erkenntnisse dieses Prototypen waren, dass besonderer Fokus/Aufmerksamkeit gelegt werden muss auf die Leistungsfähigkeit der Zielhardware, insbesondere im Hinblick auf Echtzeitanforderungen.
Keywords—ADAS, Sudden Sickness, Driver Monitoring Systems, Plötzliches Unvermögen, Innenraumüberwachung, Myokardinfarkt, Euro NCAP Anforderungen, kamerabasierte Systeme, Use Cases, StvG
I. MOTIVATION
Mit zunehmendem Ausbau von Netzwerkinfrastruktur (5G) und technischem Fortschritt auf den Gebieten akustischer, optischer und haptischer Sensorik werden Nutzungsszenarien im Bereich der Überwachung von Personen im Fahrzeuginnenraum (PKW bis 3,5t) zunehmend präziser. Dies ist von immanenter Bedeutung zur Erreichung der festgelegten Ziele und Anforderungen der Euro-NCAP Roadmap sowie zur Umsetzung von autonomen Fahren gemäß SAE J3016 („Society of Automotive Engineers“) Level 3 bis 5. Für Level 1 (z.B. Spurhalteassistent oder ACC) und Level 2 Systeme gilt, dass der Fahrer jederzeit in das System eingreifen können muss und das System aktiv den Fahrer informiert. Level 3 Systeme (z.B. Staupilot) erfordert keine grundsätzliche Interaktion des Fahrers, es sei denn, er wird aktiv dazu aufgefordert. Level 4 Systeme (situationsabhängig autonom Pedalerie/Lenkrad optional verbaut) und Level 5 Systeme (situationsunabhängig
autonom ohne verbaute Pedalerie/Lenkrad) sehen diese Aufforderung nicht vor.
Advanced Driver Assistance Systems (ADAS) tragen durch Überwachung des Fahrzeugumfelds durch Lidar (light imaging, detection and ranging)-, Radar (radio detection and ranging) und Ultraschallsensoren zur Senkung von Unfallraten bei. In den meisten Fällen sind diese Unfälle durch externe Einflüsse und Fehlverhalten des Fahrzeugführers begründet. Wie in Abb. 1 dargestellt, entfallen rund 4% aller Unfälle auf medizinisch begründete Ursachen. Vergleicht man diesen Wert mit dem Wert für unangepasste Geschwindigkeit, erscheint dieser als gering. Betrachtet man die Tatsache, dass eine Überalterung der Gesellschaft zu erwarten ist [8] in Kombination mit gleichbleibender, oder steigender, aktiven Teilnahme am Verkehrsgeschehen durch ältere Personen, ist eine Häufung von medizinischen Insuffizienzen als Unfallursache wahrscheinlich.
Hochrechnungen [8] gehen davon aus, dass bis 2050 etwa 30% der Bevölkerung über 65 Jahre oder älter sein werden.
Mit zunehmendem Alter steigt die Gefahr von multiplen Insuffizienzen, deren Symptome häufig allein durch Kamerasysteme nicht eindeutig voneinander zu unterscheiden sind. Risiken und Auswirkungen solch gefährlicher Situationen, die durch plötzliches Unvermögen entstehen, können durch die zuvor genannte Sensorik erkannt und teilweise auch gemildert, jedoch nicht vollständig verhindert werden. Genannt sei hier das Stichwort „Predictability“, einer noch weitestgehend unbehandelten Forschungsfrage.
ADAS Systeme sollen potenzielle Unfallgefahren erkennen und den Fahrer warnen bzw. bei Nichtreaktion des Fahrers entsprechende Reaktionen einleiten. Um diese (Sicherheits-) Lücke zu schließen, wurde „Sudden Sickness/ Plötzliches Unvermögen“ als strategisches Ziel in die Euro-NCAP Roadmap für 2025 aufgenommen [1]. Potenzielle Lösungsansätze zur multisensorischen Erkennung von Plötzlichem Unvermögen sind: Gesten-, Gesichts-, und Positionserkennung, Puls- und Blutdruckmessung, cEKG, wireless EEG, sowie Müdigkeitserkennung. Weitere relevante Daten zur späteren Fusion mit den Kameradaten stammen i.d.R. aus Sensoren zur Lenkwinkelbestimmung, Straßenlage, Geschwindigkeit und Umfeldsensorik.
Abb. 1. Medizinisch begründete Unfallursachen
In diesem Paper werden Anforderungen sowie Herausforderungen exemplarisch diskutiert und im Hinblick auf Umsetzbarkeit analysiert. Spezifische Herausforderungen an Kamerasysteme zur Innenraumüberwachung sehen die Autoren in den Bereichen:
- Unterscheidung primärer physiognomischer Attribute (Augenabstand, Augengröße und Form)
- Physischer Attribute wie Alter, Geschlecht, Größe, Kopfform und Behaarung
- Umgang mit teilweise oder gänzlich fehlenden körperlichen Attributen, beispielsweise einseitige Erkrankungen/Veränderungen des Sehapparats, Einäugigkeit)
- Sonstige, nicht zur Fahruntauglichkeit führende Behinderungen (Ticks, Muskelzuckungen)
- Kopfbedeckungen, Sehhilfen, Makeup - Lichtverhältnisse (Dunkelheit, Blendung) - Straßenverhältnisse
II. PLÖTZLICHES UNVERMÖGEN
Allgemein gilt der Nachweis einer gültigen Fahrerlaubnis als ausreichend, um ein Fahrzeug im öffentlichen Raum zu bewegen. Leidet der Fahrzeugführer an körperlichen oder geistigen Einschränkungen, kann diese Erlaubnis nur aufrechterhalten werden, sofern Vorsorge getroffen wurde, um weitere Verkehrsteilnehmer nicht zu gefährden (§ 2, Absatz 1 Fahrerlaubnisverordnung (FeV)). Petch [3] zufolge entfallen nur etwa 0,15% bis 0,34% der gemeldeten Unfälle auf plötzlichem Unvermögen. Im Zuge der 2020er Revision entwickelte die Euro NCAP folgenden Definitionsvorschlag:
Impaired driving – A driver who is disconnected from the driving task or not in a physical state that is sufficient for safe driving [7]. Weiterhin definiert die NCAP Zustände, in denen ein sicheres Führen eines Fahrzeuges nicht mehr gewährleistet ist:
1. Müdigkeit 2. Ablenkung
3. Fahren unter Einfluss schädlicher Substanzen oder Alkohol
4. Sudden Sickness (Plötzliche und unerwartete Krankheit, die zur Fahruntüchtigkeit führt)
Aus medizinischer Sicht steht plötzliches Unvermögen für einen Körperlichen Zustand, der in kürzester Zeit zur Fehlfunktion lebenswichtiger oder lebenserhaltender
Maßnahmen führt. Vertreter plötzlich auftretender Dysfunktionen sind unter anderem:
- 0,02-0,63% Hypoglykämie [5]
- Herzinfarkt (Myokardinfarkt) [1]
- 0,2%/Jahr Wahrscheinlichkeit durch Fehlfunktion implantierter Defibrillatoren / Herzschrittmacher [4]
- <16% bei vasovagale, kardialen Synkopen [1]
- Akute respiratorische Insuffizienz, z.B. durch COPD (Chronisch obstruktive Lungenerkrankung) oder ARDS (Akutes Atemnotsyndrom)
Die genannten Prozentwerte basieren auf einer durchschnittlichen Fahrzeit von 8h/Tag bei Berufsfahrern und 30 Minuten/Tag für Privatfahrer. Diese Annahmen wurden im Artikel „Fahreignung bei kardiovaskulären Erkrankungen“
von H.H. Klein diskutiert [1]. Zu den medizinisch relevanten Vorzeichen einer plötzlichen Herzerkrankung zählen unter anderem: Luftnot, Übelkeit und Schwindel, ungleiche Pupillenreaktion, Taubheitsgefühle. Eine solch diffuse und vielschichtige (nicht allein durch Überwachung der Augen zu erkennende) Symptomatik stellt große Herausforderungen in Sachen zuverlässiger Detektion unter Zuhilfenahme kamerabasierter Überwachungssysteme. Tabelle 1 fasst die klinische Symptomatik der für dieses Paper als relevant eingestuften Anwendungsfälle zusammen.
TABELLE I. KLINISCHE SYMPTOMATIK
Anwendungsfall Symptomatik
Myokardinfarkt Druck/beengende oder brennende Schmerzen in der Brust (Ausstrahlung in Hals, Brustkorb, Schultern, Arme möglich), Atemnot, (Todes)Angst, Übelkeit, unregelmäßiger Puls, Blässe, Schweißausbruch
Akute
respiratorische Insuffizienz
Luftnot, Husten, Auswurf (schaumig, eitrig, blutig), Brustschmerzen, Kollaps, Ohnmacht, bläuliche Verfärbung von Lippen und Extremitäten
Hypoglykämie Schneller/rasender Puls, kalter Schweiß, Blässe, Zittern/Unruhe, Konzentrationsstörungen
Tabelle 1 - Klinische Symptome [2]
III. REGULATORISCHE UND RECHTLICHE
RAHMENBEDINGUNGEN
A. Euro NCAP Roadmap & Anforderungen
Die Euro NCAP Roadmap sieht eine marktreife Entwicklung und Umsetzung des „Driver State Monitoring“
bis 2023 vor [1]. Dies umfasst neben Zustandserkennung des Fahrers auch entsprechende Systemreaktionen (z.B. Warnung und Eingriff durch das System nach erkanntem Unvermögen durch Veränderung des Fahrzeugzustands). Die vorgeschlagenen Fahrzeugmodi umfassen:
“High sensitivity mode” - striktere Kriterien zur Erkennung und Intervention in Kombination mit weiteren ADAS Systemen, um das Unvermögen des Fahrers zu kompensieren. “Reduced Speed Mode” – Drosselung der Geschwindigkeit bis zum Stillstand bei gleichzeitiger
Steigerung der Systemsensitivität. “Emergency Stop Manoeuvre” – Kontrolliertes Verzögern des Fahrzeugs bis V(current) = 0km/h am Fahrbahnrand mit gleichzeitigem Absetzen eines Notrufes sowie Betätigung der Warnblinkanlage.
Für eine Zulassung zum NCAP Test muss das Vehicle under Test (VuT) über einen Anschnallassistenten sowie eine Erkennung von Insassen auf mindestens einem Rücksitz verfügen. Zusätzlich muss das VuT über AEB (Autonomous Emergency Braking), LSS (Lane Support Systems) und/oder SAS (Speed Assist Systems) verfügen.
Weiterhin muss der Hersteller ausreichend Details zur Implementierung und bereits durchgeführter Testfälle des DMS zur Verfügung stellen, sowie etwaige Simulationen und Testdaten deutlich zur Unterscheidung kennzeichnen. Das DMS muss während jedes Fahrzyklus standardmäßig betriebsbereit und aktiv sein. Ein versehentliches Abschalten ist nicht zulässig (z.B. durch falsche Positionierung der Taste im Cockpit). Im Rating für 2020 können nach erfolgreicher NCAP Prüfung maximal 3.0 Punkte (1 Punkt für DMS sowie 2 Punkte für vorhandene Gurtwarner) angerechnet werden.
Für dieses Paper relevant ist der Ansatz einer zeitlichen Begrenzung, wann von einem plötzlichem Unvermögen ausgegangen werden kann.
B. Datenschutz
Die Erhebung und Verarbeitung personenbezogener Daten unterliegt europäischem Datenschutz EU-2016/679 sowie dem Bundesdatenschutzgesetz (BDSG). Hierzu gehören auch Daten, die im Zuge der Fahrerüberwachung erhoben und gesammelt werden. Von personenbezogenen Daten ist die Rede, sobald Daten einer „bestimmten Person“
zugeordnet werden können oder Bezug zu einer
„bestimmbaren“ Person nehmen. Sobald ein Fahrzeug zugelassen wird, ist der Halter über die Fahrgestellnummer identifizierbar. Diese und ähnlich eindeutige Daten „gehören“
somit dem Halter, nicht etwa dem Fahrzeughersteller oder Zulieferbetrieben. Sog. Event-Data-Recorder sind als closed- loop Systeme anzulegen, die eine Zuordnung oder Identifikation des Fahrzeugführers verhindern sollen. Eine beabsichtige Manipulation oder eine unbeabsichtigte Verbreitung soll damit verhindert werden. Für Systeme zur Müdigkeitserkennung gilt, dass sie nicht kontinuierlich Daten aufzeichnen sollen, was für eine lückenlose Diagnostik zur Erkennung plötzlichen Unvermögens so nicht tragbar ist.
Diese Systeme leben von der Aktualität ihrer Daten und der Verarbeitung in Echtzeit. Von Interesse ist in diesem Zusammenhang die Frage der Datenvorhaltung zur weiteren Verarbeitung (z.B. im nichtflüchtigen Speicher). Wörtlich ist von „should not continuously record nor retain any data“1 die Rede. Gleich wie es im Jahr 2015 eine EU Verordnung zur Erhebung und Verarbeitung der Daten durch Notrufassistenten2 (sog. eCalls) gab, ist dies auch für Driver Monitoring Systeme zu erwarten.
In einer Entschließung [12] aus dem Jahr 2014 forderte der Bundesbeauftragte für Datenschutz und Sicherheit die Automobilindustrie dazu auf, den Endkunden/Nutzer über alle gesammelten Daten und Schnittstellen zur Übertragung dieser Daten aufzuklären und dies schriftlich zu fixieren (gemäß § 4 Abs. 1 BDSG). Zudem fordert dieses Schreiben „Privacy by Design“ (die Systemkonzeption unter Datenschutzaspekten) sowie „Privacy by default“ (nutzerfreundliche Grundeinstellungen im Hinblick auf Datenschutz). Zudem gilt der Grundsatz der Datensparsamkeit, also der Vermeidung
von Aufzeichnung oder Verarbeitung nicht notwendiger Daten. Basierend auf zuvor genannter Erschließung erarbeitet der VDA (Verband der Automobilindustrie) gemeinsam mit dem Bundesdatenschutzbeauftragten eine Erklärung [13], welche die Begriffe Personenbezogenheit, Verantwortliche Stelle (gem. § 3 Abs. 7 BDSG), Datenhoheit präzisiert sowie Angaben zum Zeitpunkt der Datenerhebung („online“ gem. § 3 Abs. 3 BDSG bzw. „offline“ gem. § 6c BDSG), Auskunftsrecht (gem. § 34 BDSG) und Zulässigkeit der Datenerhebung macht (gem. 28 Abs. 1 S. 1 Nrn. 1 oder 2 BDSG, §§ 11 ff. Telemediengesetz).
Die uns vorliegende Gesetzesnovelle der StVG nennt in
§1g verpflichtend zu speichernde Daten, die nach Meinung der Autorin dieses Kapitels im Kontrast zum Gebot der Datensparsamkeit stehen. Im Folgenden sind dies [15]:
• Fahrzeugidentifizierungsnummer, Positionsdaten
• Anzahl und Zeiten der Nutzung sowie der Aktivierung und der Deaktivierung der autonomen Fahrfunktion
• Anzahl und Zeiten der Freigabe von alternativen Fahrmanövern
• Systemüberwachungsdaten einschließlich Daten zum Softwarestand,
• Umwelt- und Wetterbedingungen
• Vernetzungsparameter wie beispielsweise Übertragungslatenz und verfügbare Bandbreite
• Name der aktivierten und deaktivierten passiven und aktiven Sicherheitssysteme, Daten zum Zustand dieser Sicherheitssysteme sowie die Instanz, die das Sicherheitssystem aus-gelöst hat
• Fahrzeugbeschleunigung in Längs- und Querrichtung
• Geschwindigkeit, Spannungsversorgung
• Status der lichttechnischen Einrichtungen
• Von extern an das Kraftfahrzeug gesendete Befehle und Informationen
Die zuvor genannten Daten sind bei Eingriffen durch die Technische Aufsicht, Konfliktszenarien, nicht-planmäßigen Spurwechseln sowie Störungen im Betriebsablauf aufzuzeichnen. Nach Abs.4 werden ebenfalls Vor- und Nachname sowie Qualifikation der technischen Aufsicht erhoben. Der so entstehende Datensatz ist dem Kraftfahrtbundesamt auf Verlagen vorzulegen. Die Daten beim KbA werden 3 Jahre nach Einstellung (= Abmeldung) des Fahrzeuges gelöscht. Anonymisierte Daten werden vom KbA zu Zwecken der Forschung zur Verfügung gestellt.
C. StVG (Straßenverkehrsgesetz)
Plötzliches Unvermögen, zeichnet sich vor allem durch die Unabwendbarkeit und Unvorhersehbarkeit des Auftretens aus. Dies ist von großer juristischer Bedeutung von Unfällen mit Schadensfolge. So kann ein Fahrer zum Zeitpunkt der Vertragsunterzeichnung vollkommen Fahrtüchtig gewesen sein. Eine Arglist oder Täuschung des Versicherers ist hiermit auszuschließen. Ist folglich eine grundsätzliche Fahreignung gegeben, ist ein potenzieller Schaden über Haftpflicht-, Teil-, und Vollkasko zu regeln. Eine Veränderung der Haftungslage ist ebenfalls auszuschließen, wenn in Folge eines plötzlichen
Unvermögens das Fahrzeug durch vorhandene Assistenzsysteme an den Fahrbahnrand überführt und zum Stillstand gebracht wird. Ein zum Stillstandbringen auf dem eigenen Fahrstreifen erscheint weder sinnvoll noch erstrebenswert (Urteil des BGH, NZV 1995, 145 und Urteil des OLG Brandenburg, BeckRS 2008, 14677). Etwaige Schadenersatzforderungen müssen durch den Verursacher jedoch nach § 7 StVG (Straßenverkehrsgesetz) nicht geleistet werden; eine Gefährdungshaftung wird aufgrund der Unabwendbarkeit des Ereignisses ausgeschlossen.
Im Februar 2021 wurde ein Gesetzentwurf der CSU vorgestellt, wonach §1c um die §§1d bis 1l erweitert werden sollten. Dies schließt auch eine Definition von autonom fahrenden Fahrzeugen ein. Von besonderem Interesse ist (3):
„Technische Aufsicht eines Kraftfahrzeugs mit autonomer Fahrfunktion im Sinne dieses Gesetzes ist diejenige natürliche Person, die dieses Kraftfahrzeug während des Betriebs gemäß
§ 1e Absatz 2 Nummer 8 deaktivieren und für dieses Kraftfahrzeug gemäß § 1e Absatz 2 Nummer 4 und Absatz 3 Fahrmanöver freigeben kann. [15]“, da dies bei absichtlicher Deaktivierung des ADAS Systems vermutlich (zum Zeitpunkt dieser Arbeit liegen noch keine entsprechenden Quellen vor) eine Haftung durch den Hersteller ausschließt. Systeme, welche sich nicht deaktivieren lassen, müssen gem. (2), Absatz 7 selbstständig ihre Systemgrenzen erkennen und bei Bedarf/Störung in einen risikominimierenden Zustand gelangen, indem die Warnblinkanlage gestartet und das Fahrzeug an einer sicheren Stelle zum Halten gebracht wird [15].
IV. FORSCHUNGSSTAND
BMW forscht an einem Autobahn-Notfallpiloten, der das Fahrzeug sicher an den Fahrbahnrand bringen soll.
Entsprechende Funktionsarchitekturen und Entscheidungsbäume wurden vorgestellt [10]. Eine zentrale Forschungsfrage war, wie man andere Verkehrsteilnehmer zu rücksichtsvollem und kooperativen Verhalten im medizinischen Ernstfall anregen kann [11]. Abbildung 2 zeigt die Erkennbarkeit möglicher Ursachen für plötzliches Unvermögen, wie bereits durch Mirwaldt, Bartels, Thanh- Binh To und Pascheka dargelegt. In derzeitig verfügbaren Ausstattungsvarianten aktueller Fahrzeugmodelle verschiedener Autohersteller wird das Fahrzeug auf der momentan befahrenen Fahrbahnspur durch das “Emergency Stop Manoeuvre” zum Stillstand gebracht. Alarmierende akustische und visuelle Signale machen andere Verkehrsteilnehmer auf einen Notfall im Fahrzeug aufmerksam, wie der neue Volkswagen Golf 8 demonstrieren kann [17].
Abb. 2. Toyota Driver-monitoring Function [16]
Im Kontext der Erkennung, ob der Fahrer seine Aufmerksamkeit auf den Verkehr gerichtet hat, wird eine im
Kombiinstrument verbaute Infrarotkamera zur Überwachung des Fahrers verwendet. Beim nicht auf den Verkehr gerichteten Blick (durch Ausrichtung des Kopfes, Körperhaltung und verschlossenen Augen) und einer vom ADAS vernommenen Kollisionsgefahr, benachrichtigt das Fahrzeug den Fahrer durch mehrere Alarmmöglichkeiten (visuell, akustisch, Bremsstöße). Erhält das Fahrzeug keine Reaktion vom Fahrer führt es selbstständig eine Notbremsung durch, siehe auch „Toyota Enhanced Pre-Crash Safety System“ [16]. Neben Kamerabasierten Detektionsmethoden werden auch Lenkräder mit Induktionssensoren verwendet, um festzustellen, ob der Fahrer das Fahrzeug führt. Die darauffolgenden Maßnahmen des Fahrzeugs auf einen nicht reagierenden Fahrer sind identisch zu kamerabasierten Varianten [17].
Abb. 3. Erkennbarkeit medizinisch begründeter Fahruntauglichkeiten [7]
Um die Frage nach möglicher und vor allem zuverlässiger Detektion eines Myokardinfarktes hinsichtlich Machbarkeit zu beantworten, ist eine Bewertung verfügbarer, minimalinvasiver oder drahtloser Sensorik notwendig. Zur Betrachtung kamen bei [7]: cEKG (Capacitve EKG, Verbauung einer Elektrode in der Sitzfläche sowie einer Referenz in der Lehne), Ballistokardiografie (BCG, indirekte Messung durch Drucksensoren parallel zur Wirbelsäule), kamerabasierte Verfahren, Magnetisch-Induktive Verfahren, radarbasierte Verfahren, Elektroenzephalographie (EEG auch kontaktlos in Kopfnähe möglich). Abbildung 3 (entnommen aus [7]) stellt die zuvor genannten Möglichkeiten in Zusammenhang mit einem potenziellen Verbauort im Fahrzeug dar.
Abb. 4. Verbauorte und Detektierbarkeit nach [7]
V. FORSCHUNGSFRAGE/-METHODIK
Dieses Paper stellt sich der Frage, nach zuverlässiger Erkennung der eine Myokardinfarktes durch das vorliegende und in Unterkapitel B beschriebene System.
A. Strategischer Literatur-Review
Zur Beantwortung der Forschungsfrage kamen einerseits ein strategischer Literatur-Review nach Kitchenham [14] zur Anwendung, zum anderen die prototypische Umsetzung des Use Cases „Plötzliches Unvermögen“. Zur Eingrenzung der Literatur wurden, absteigend nach Relevanz, folgende Kriterien erarbeitet:
TABELLE II. LITERATURAUSWAHLKRITERIEN
Literatur Kat
Bücher/Artikel zum Thema Plötzliches Unvermögen UND klinischer Symptomatik mit Bezug auf Herzinfarkt, aktue respiratorische Insuffizienz und Hypoglykämie
A
Bücher/Artikel zum Thema Plötzliches Unvermögen ODER klinischer Symptomatik mit Bezug auf Herzinfarkt ODER aktue respiratorische Insuffizienz ODER Hypoglykämie
B
Artikel zu Euro NCAP Anforderungen/ Roadmap C Konferenz-Paper, Interviews oder Artikel zu
aktuellen ADAS Systemen D
Tabelle 2 – Kriterien
Basierend auf o.g. Kriterien konnten primär die in Tabelle 3 Literaturauswahl
genannten Quellen in Betracht gezogen werden.
TABELLE III. LITERATURAUSWAHL
Literatur Kat.
- P. Waldmann, N. Kaempchen, M. Ardelt, F. Homm, „Der Nothalteassistent – abgesichertes Anhalten bei plötzlicher Fahrunfähigkeit des Fahrzeugführers“, 2010
- Mirwaldt, P., Bartels, A., To T.-B., Pascheka P. „Gestaltung eines Notfallassistenzsystems bei medizinisch bedingter Fahrunfähigkeit“
A
Klein, H., Krämer, A., Pieske, B. et al. „Fahreignung bei kardiovaskulären Erkrankungen. (2010) B https://www.euroncap.com/en/for-engineers/technical-
papers/ C
- H. Ehmen „Fahrleistungsrelevante Parameter im Alter“, 2010
. “Datenschutz im Kraftfahrzeug – Automobilindustrie ist gefordert“ 88. Konferenz der Datenschutzbeauftragten des Bundes und der Länder, 2014
D
Tabelle 3 Literaturauswahl
B. Versuchsaufbau/Prototyp
Zur prototypischen Umsetzung des Use Cases kam zur Anwendung:
- Raspberry Pie 4, 4 GB RAM (Raspebian [Raspberry Pi OS])
- Speicherkarte Kingston 16 GB - Logitech USB Webcam - XboX® One S Controller
- JBL®Lautsprecher mit AUX Verbindung - 1 x Powerbank (6000 mAh, 5 V, 2 A) - VNC Viewer/Server
- Thonny Python IDE - TensorFlow - Kabel etc.
- Versuchslaptop
VI. USE CASE 1:ERKENNUNG UND MÖGLICHE REAKTION AUF
PLÖTZLICHES UNVERMÖGEN DURCH MYOKARDINFARKT
A. Beschreibung
Die Autoren dieses Papers wollen sich mit theoretisch realitätsnahen Use Cases, beim Eintreten von Myokardinfarkten am Fahrer, befassen und diesen Anwendungsfall prototypisch umsetzen.
Abb. 5. Use Case Diagramm – Plötzliches Unvermögen [Eigene Darstellung]
In diesem UML Diagramm sind die Akteure Fahrer,
„Driver State Monitoring“ und „Advanced Driver Assistant Systems“ zu erkennen. Außerdem lässt sich die Systemgrenze „Plötzliches Unvermögen“ in die Bereiche
„Erkennung“ (Überwachung des Fahrers durch das „Driver State Monitoring“) und „Eingriff“ (Initialisierung von Maßnahmen durch das „Driver State Monitoring“ und der Ausführung durch das „Advanced Driver Assistant System“) unterteilen. Innerhalb der Erkennung befinden sich die Use Cases:
• Fahrzeug bedienen
• Fahrerstatus beobachten
• Unvermögen erkennen
Innerhalb des Eingriffs befinden sich die Use Cases mit Extension Points:
• Warnung
• Abstand- und Spurkontrolle
• Warnsignale
• Milder Eingriff
• Gurtanziehen
• Brems- und Lenkmanöver
• Harter Eingriff
• Warnblinklicht und Hupe
• Nothaltemanöver
Von Interesse innerhalb dieser Ausarbeitung sind die Use Cases „Unvermögen Erkennen“, „Warnung“, „Milder Eingriff“ und „Harter Eingriff“ (siehe Abb. 6., Abb. 7., Abb.8. und Abb. 9.).
B. Anforderungen an die Use-Cases
Mit Berücksichtigung der Euro-NCAP Anforderungen und dem Ziel der Erkennung eines Myokardinfarktes wurden zum Entwurf des Use Case „Unvermögen Erkennen“
mehrere Überlegungen getroffen. Diese beinhalten die Herannahme von Tabelle 1 – Klinische Symptome und dessen Identifikationsmerkmale eines Myokardinfarktes. Es wird herausgeleitet, dass Kopfposition (Fall nach vorne, nach unten sehend, nach hinten lehnend, nach hinten gebogen, Blickrichtung), Augen (Zeit offener Augen, Zeit geschlossener Augen, Pupillenerweiterung), Mimik (Augenbrauen Position, Mundwinkel), Körperhaltung (nach vorne lehnend, nach hinten lehnend, seitlich lehnend, Position Hände) und Fahrverhalten (Lenkverhalten, Pedalbedienung, Hände am Lenkrad, Einhaltung der Fahrspur) zu identifizierende Eingabedaten für die Detektion des plötzlichen Unvermögens sind. Erweiterbar sind die Eingabedaten bei Überwindung technischer Herausforderungen auf Körpertemperatur, Puls und Sprache.
Kompromisse wurden jedoch in der Umsetzung des Prototyps vorgenommen und zur Erhöhung der Stabilität der Erfassung (fehlerfreie Erfassung eines Unvermögens) die Qualität (Menge an zu identifizierenden Daten) reduziert.
Somit entschieden sich die Autoren die Kopfposition, Augen und Mimik in der Umsetzung nicht zu berücksichtigen, was nicht die Bedeutsamkeit dieser Daten ausschließt. Durch die Limitierung der zur Verfügung stehenden Hardware (wie in B. Versuchsaufbau/Prototyp ersichtlich) verzichten die Autoren auf Eingabedaten der Kategorie Fahrverhalten.
C. Beschreibung theoretisch realitätsnaher Use-Cases Durch die Überlegungen der Autoren wurden mit den gesammelten Informationen die drei nennenswerten Use Cases innerhalb des Use Case „Plötzliches Unvermögen“
herausgearbeitet, um eine detailliertere Übersicht zum DSM System im Fall eines Plötzlichen Unvermögens zu beschreiben.
TABELLE IV. USE CASE -WARNUNG Textuelle
Beschreibung von Use Case
Warnung
Vorbedingung Funktionsfähigkeit aller ADAS Einheiten, Fahrzeug fahrtüchtig, Fahrer fahrfähig
Nachbedingung im Erfolgsfall
- Übergang in „Milder Eingriff“
- Fahrer bestätigt seine Teilnahme Nachbedingung
im Misserfolg
- Fahrer bestätigt seine Teilnahme Akteure Fahrer, ADAS, DSM
Auslösendes Ereignis
- Fahrer hat die Hände nicht am Lenkrad - Fahrer dreht den Kopf weg von der Straße - Fahrer hat geschlossene Augen
- Kopf vom Fahrer verweilt in einer ungeeigneten Position
- Körper vom Fahrer verweilt in einer ungeeigneten Position
- Fahrer Lenkverhalten stimmt nicht mit Spurstreifen überein
- Fahrer Beschleunigungs- und Bremsverhalten stimmt nicht mit zulässiger Geschwindigkeit überein Ablauf 1. ADAS greift ein (hält Fahrzeug auf der Spur,
vermeidet Auffahrunfälle und Kollisionen) und ein Signalton (je Sekunde) und Gelbe Signalfarbe am Tacho und Benachrichtigung (Achtung, fahren) 2. Warte auf Bestätigung des Fahrers (wieder Fahrtüchtig)
3. 3 Sekunden nach Start „Warnung“ Übergang in
„Milder Eingriff“
Alternativen 2a1. Der Fahrer legt die Hände ans Lenkrad und steuert das Fahrzeug
2a2. Der Fahrer schaut wieder auf die Straße 2b1. Der Fahrer richtet seinen Körper auf die gewohnte fahr Position
2b2. Der Fahrer schaut wieder auf die Straße 2c1. Der Fahrer schaut wieder auf die Straße 2c2. Der Fahrer bestätigt seine Fahrtüchtigkeit Tabelle 4 Textueller Use Case – Warnung [Eigene Darstellung]
TABELLE V. USE CASE –MILDER EINGRIFF Textuelle
Beschreibung von Use Case
Milder Eingriff
Vorbedingung Eingabeanforderung aus Warnung nicht erfolgt, alle ADAS Einheiten aktiv, Fahrzeug fahrtüchtig Nachbedingung
im Erfolgsfall
- Übergang in „Harter Eingriff“
- Fahrer bestätigt seine Teilnahme Nachbedingung
im Misserfolg - Fahrer bestätigt seine Teilnahme Akteure Fahrer, ADAS, DSM
Auslösendes Ereignis
- Fehlende Fahrbeteiligung vom Fahrer - Fehlende Bestätigung zur Fahrtüchtigkeit vom Fahrer
- Erfassung des plötzlichen Unvermögens (Systemgrenze Myokardinfarkt)
Ablauf 1. Passagieranschnallgurte werden gestrafft und Alarmsignal wird lauter und Rote Alarmfarbe und Benachrichtigung (Notfall Stopp wird eingeleitet) 2. Fahrzeug kann nicht mehr beschleunigen 3. Fahrzeug tätigt zwei Bremsstöße 4. „Harter Eingriff“ wird eingeleitet Alternativen 1a1. Der Fahrer schaut wieder auf die Straße
1a2. Der Fahrer richtet seinen Körper auf die gewohnte fahr Position
1a3 Der Fahrer legt die Hände ans Lenkrad und steuert das Fahrzeug
1a4. Der Fahrer bestätigt seine Fahrtüchtigkeit (Für 2, 3 und 4 wiederholen)
Tabelle 5 Textueller Use Case – Milder Eingriff [Eigene Darstellung]
TABELLE VI. USE CASE –HARTER EINGRIFF Textuelle
Beschreibung von Use Case
Harter Eingriff
Vorbedingung Eingabeanforderung aus Warnung und Milder Eingriff nicht erfolgt, alle ADAS Einheiten aktiv, Fahrzeug fahrtüchtig, Myokardinfarkt detektiert Nachbedingung
im Erfolgsfall
- Fahrzeug Startbereit Nachbedingung
im Misserfolg
- Fahrzeug Startbereit Akteure Fahrer, ADAS, DSM Auslösendes
Ereignis
- Fehlende Fahrbeteiligung vom Fahrer - Fehlende Bestätigung zur Fahrtüchtigkeit vom Fahrer
Ablauf 1. Warnblinklicht und Hupe und Auffahrt- und Kollisionsassistent aktiv bis zum Stillstand
2. Spur halten
3. Spurwechsel Richtung Fahrbahnrand 4. Am Fahrbahnrand halten
Alternativen 2a1. Gefahrensituation zwingt zum sofortigen Nothalt
3a1. Gefahrensituation zwingt zum sofortigen Nothalt
3b1. Spurwechsel nicht möglich 3b2. Auf freie Spur warten
3b3. Keine Möglichkeit zum Spurwechsel 3b4. Auf der Spur halten
3c1. Spurwechsel nicht möglich 3c2. Auf freie Spur warten 3c3. Weiter mit 3.
4a1. Gefahrensituation zwingt zum sofortigen Nothalt
Tabelle 6 Textueller Use Case – Harter Eingriff [Eigene Darstellung]
D. Beschreibung theoretisch realitätsnaher Eskalationsstufen
Abb. 6. Funktionen in den Eskalationsstufen [Eigene Darstellung]
Das DSM darf nicht deaktivierbar sein und muss mit Beginn der Fahrzeugbedienung aktiv sein. Ungeachtet des Myokardinfarktes wird das DSM jede Eingabedate auf Einschränkung der Fahrsicherheit auswerten. Wird eine Einschränkung erfasst, greift der Use Case „Warnung“ mit der ersten Eskalationsstufe. Parallel zur „Warnung“ wird das DSM weiterhin Daten auswerten und diese kategorisieren.
Werden alle auf einen Myokardinfarkt hinweisende Daten erfasst und Daten ausgeschlossen, die auf andere medizinische Ursachen deuten, dann wird diese Information bei der Verständigung des Rettungsdienstes verwendet.
Im Use Case „Warnung“ wird der Fahrer darüber benachrichtigt, dass seine Aufmerksamkeit nicht mehr auf den Straßenverkehr und der Fahrzeugführung ausgelegt ist und dieser sich diesen wieder widmen soll. Das DSM ist im Prozess die Herkunft der Ablenkung zu identifizieren. Für den Eintritt ist die Herkunft nicht entscheidend, sondern die
Sicherheitsmaßnahmen. Parallel zur Benachrichtigung über die mangelnde Aufmerksamkeit werden die notwendigen ADAS Systeme (Abstandstempomat, Spurhalteassistent, Kollisionsnotfallassistent) aktiviert, um Gefahren während der Ablenkung zu vermeiden. Reagiert der Fahrer nicht, festgestellt durch Daten vom DSM oder fehlender Knopfdruckbestätigung und fehlender korrekter Führung des Fahrzeugs und Ablauf der Abfragezeit wird in die 2.
Eskalationsstufe übergegangen und der Use Case „Milder Eingriff“ gestartet.
In der 2. Eskalationsstufe werden Benachrichtigungstöne und visuelle Nachrichten auf dem Tacho deutlicher (Lauterer Ton, aufblinkende Anzeige). Angelegte Passagiergurte werden gestrafft, um die Passagiere bei einer möglichen Kollision zu schützen und den Fahrer, wenn möglich, zu warnen. Anschließend führt das Fahrzeug Bremsstöße durch, um den Fahrer gegebenenfalls wach zu rütteln und andere Verkehrsteilnehmer über eine ungewöhnliche Situation zu informieren. Reagiert der Fahrer nicht, festgestellt durch Daten vom DSM oder fehlender Knopfdruckbestätigung und fehlender Eingriff und korrekter Führung des Fahrzeugs geht das Fahrzeug in die 3. Eskalationsstufe über und der Use Case
„Harter Eingriff“ tritt ein und der Myokardinfarkt des Fahrers bestätigt. Des Weiteren beschleunigt das Fahrzeug in dieser Stufe nicht weiter.
In der 3. Eskalationsstufe alarmiert das betroffene Fahrzeug andere Verkehrsteilnehmer durch Hupen und Warnlichtsignale, die bis zum Stillstand fortgeführt werden.
Der Stillstand auf der aktuell befahrenen Spur oder am Fahrbahnrand ist abhängig von der Straßenbeschaffenheit.
Spurhalte-, Spurwechsel-, Notfallbrems- und Kollisionswarnsysteme werden verwendet, um das führerlose Fahrzeug so zu navigieren, dass Kollisionen mit anderem Verkehrsteilnehmer und der Umgebung vermieden werden.
Neben der Geschwindigkeitsverringerung bis zu Stillstand, werden die Systeme das Fahrzeug an den Fahrbahnrand navigieren. Erfolgte der Halt bis zum Stillstand wird die 4.
Eskalationsstufe eingeleitet. Andere Verkehrsteilnehmer werden durch die Warnblinklichtanlage und durch akustische und visuelle Benachrichtigungen aufmerksam gemacht und informiert, dass der Fahrer an einem Myokardinfarkt leidet.
Das Fahrzeug wird ebenfalls entriegelt. Es folgt ein Notruf bei der vom Fahrzeughersteller hinterlegten Stelle. Der Beantwortende aus der Notrufstelle wird die Lage analysieren und die notwendigen Notfallkräfte verständigen.
E. Beschreibung der prototypischen Use-Cases
Mit dem Kompromiss die Stabilität der Erfassung zu erhöhen, durch Reduzierung der Qualität (Rauswurf der Eingabedaten Augen, Mimik, Kopfhaltung) und der hardwareseitigen Einschränkung des Prototyps (Rauswurf der Eingabedate Fahrverhalten) haben die Autoren Use- Cases für den realisierten Prototyp entworfen (siehe A).
TABELLE VII. USE CASE -WARNUNG Textuelle
Beschreibung von Use Case
Warnung
Vorbedingung Abstands-, Spurhalte- und Bremssystem bereit, Fahrzeug fahrtüchtig, Fahrer fahrfähig, Geschwindigkeit > 0 MPH
Nachbedingung im Erfolgsfall
- Übergang in „Milder Eingriff“
- Fahrer bestätigt seine Teilnahme Nachbedingung
im Misserfolg
- Fahrer bestätigt seine Teilnahme
Akteure Fahrer, Abstandsassistent, Spurhalteassistent, Bremsassistent, DSM, Fahrzeug
Auslösendes Ereignis
- Körper vom Fahrer verweilt in einer ungeeigneten Position
Ablauf 1. DSM beobachtet Fahrer Haltung (Körperhaltung) 2. Fahrer nimmt ungewöhnliche Haltung an (Körper betritt Warnbereich)
3. DSM erfasst Körper des Fahrers im Warnbereich 4. Fahrzeug alarmiert (Attention, please!), Spur- und Abstandsassistent aktiviert
5. Fahrer Reaktion erwartet (Wiedereintritt des Körpers in den normalen Fahrhaltung-Bereich) 6. DSM wartet 5 Frames per Second nach Start
„Warnung“ Übergang in „Milder Eingriff“
Alternativen 2b1. Der Fahrer richtet seinen Körper auf die gewohnte fahr Position
2b2. Der Fahrer schaut wieder auf die Straße Tabelle 7 Textueller Use Case – Warnung [Eigene Darstellung]
TABELLE VIII. USE CASE –HARTER EINGRIFF Textuelle
Beschreibung von Use Case
Harter Eingriff
Vorbedingung Abstands-, Spurhaltesystem aktiv, Bremssystem bereit, Fahrzeug fahrtüchtig, Fahrer fahrunfähig, Geschwindigkeit > 0 MPH
Nachbedingung im Erfolgsfall
- Fahrzeug Startbereit Nachbedingung
im Misserfolg
- Fahrzeug Startbereit
Akteure Fahrer, Abstandsassistent, Spurhalteassistent, Bremsassistent, DSM, Fahrzeug
Auslösendes Ereignis
- DSM wartet 3 Frames per Second nach Start
„Warnung“ Übergang in „Harter Eingriff“
Ablauf 1. Fahrzeug alarmiert (Attention, Emergency!) und Warnblicklichtanlage aktiviert
2. Bremssystem wird aktiviert bis v = 0 Tabelle 8 Textueller Use Case – Harter Eingriff [Eigene Darstellung]
F. Beschreibung der prototypischen Eskalationsstufen Verglichen mit der realitätsnahen Eskalationsstufen aus Kapitel D haben die Autoren beim Prototyp zwei Stufen gewählt. Der Fokus bestand darin eine Demonstration zur Machbarkeit eines „Sudden Sickness Detection“ Systems vorzustellen. Die Einschränkung der Hardware und der geringere Erfassungsaufwand (siehe B) machen darüber hinaus weitere Eskalationsstufen funktionell unzureichend.
In der Eskalationsstufe „Warnung“ erfasst der Prototyp bei einer Geschwindigkeit v > 0 MPH den Körper des Fahrers. In einer gewöhnlichen, Fahrzeugführenden Haltung des Fahrers erfolgt der Betrieb des Fahrzeugs gewöhnlich (der Grüne Block zwischen dem roten und blauen Block).
Abb. 7. Erfassung des Fahrers in einer fahrzeugführenden Haltung durch den Prototyp [Eigene Darstellung]
Betritt der grüne Block einen anderen Block vollständig (in diesem Beispiel den roten), reagiert der Prototyp darauf.
Abb. 8. Erfassung des Fahrers in einer nicht fahrtauglichen Haltung durch den Prototyp [Eigene Darstellung]
In diesem Zustand aktiviert der Prototyp den Alarm mit
„Attention, please!“, um den Fahrer wieder aufmerksam auf das Fahrgeschehen zu machen und es aktiviert das Spurhalte- und den Abstandshalteassistent. Der Fahrer hat je nach Geschwindigkeit 3 bis 5 Frames per Second Zeit, um auf den Alarm zu reagieren. Das System kann erkennen, wenn der Fahrer wieder eine fahrtaugliche Haltung annimmt und stellt den Alarm ein. Geschieht dies nach der festgelegten Zeit nicht, geht das System in die nächste Eskalationsstufe über.
In der Eskalationsstufe „Harter Eingriff“ wird unmittelbar der Alarm „Attention, Emergency!“ ausgegeben und das Bremssystem aktiviert. Das Bremssystem bleibt aktiv bis die Geschwindigkeit v = 0 MPH beträgt und danach deaktiviert es sich wieder. Ebenso wechselt der Alarm wieder zum
„Attention, please!“ Signal über. Damit endet die Eskalationsstufe. Der Nutzer kann den Eskalationsprozess jederzeit durch sein Eingreifen unterbrechen.
G. Durchführung/Umsetzung des Prototyps
Das Ziel des Prototyps ist es zu veranschaulichen welchen Mehrwert ein kamerabasiertes Assistenzsystem zur Detektion von plötzlichem Unvermögen leisten kann und wie die grundsätzliche Funktionalität eines solchen Systems aussehen könnte.
Abb. 9. Bildschirmausschnitt aus dem Raspberry Pi, der Prototyp (Driver State Monitoring) im Normalbetrieb (aktiviert). Fahrer in aufrechter Haltung, hohes Tempo durch Eingabe simuliert. [Eigene Darstellung]
Abb. 10. Bildschirmausschnitt aus dem Raspberry Pi, der Prototyp (Driver State Monitoring) im Eskalationsscenario (Harter Eingriff). Fahrer spielt ein plötzliches Unvermögen vor das erkannt wurde. Der Prototyp simuliert den Eingriff von Fahrerassistentzsystemen und bremmst das Fahrzeug mit aktivierter Warnblinklichtanlage ab.
Der Prototyp besteht aus einem zentralen Rechnerknoten (Raspberry Pi), Sensoren (XboX® One S Controller, Logitech USB Webcam) und Aktoren (JBL®Lautsprecher). Über einen Kamerasensor wird mittels einem vortrainierten Machine Learning Algorithmus bestimmt welche Position/Körperhaltung der Fahrzeugführer in einem Moment hat und es wird abhängig von weiteren Faktoren (in diesem Fall Geschwindigkeit des Fahrzeugs) entschieden, ob ein Eingriff erfolgen soll. Erfolgt ein Eingriff wird, abhängig von der Geschwindigkeit, beispielsweise Warnsignale gegeben, Warnblinkanlage eingeschaltet und die Geschwindigkeit gedrosselt. Es können in diesem Zuge auch weitere Assistenzsysteme hinzugenommen werden (Spurhalteassistent, Adaptiver Tempomat).
Die Powerbank versorgt den Rechnerknoten mit Strom.
Alle weiteren Elemente erhalten den Strom dann von dem Raspberry. Die USB Cam nimmt Bilder auf mit etwa 4 Frames/ Sekunde und überträgt diese an den Raspberry über eine USB-Schnittstelle. Der XboX® One S Controller nimmt die Eingaben des Nutzers entgegen und sendet diese über eine USB-Schnittstelle an den Raspberry. Aus Sicht des Rechnerknotens werden diese Signale mittels eines virtuellen CAN Buses weiterverarbeitet. Wenn man noch eine externe Anzeige hinzunehmen möchte, dann werden diese Daten per HDMI versendet. Die Daten an den Lautsprecher werden mittels AUX versendet.
H. Auswertung
Ziel des Prototyps ist es, zu veranschaulichen wie ein Fahrerassistenzsystem zur kamerabasierten Erkennung von plötzlichem Unvermögen konzipiert und gestaltet werden könnte. Dieser Prototyp hat zu Erkenntnissen geführt, die für die Entwicklung eins seriöseren Systems wichtig sein könnten:
• Verwendete Hardware
• Harte Echtzeitanforderungen
• Schnittstellen zu anderen Steuergeräten 1) Verwendete Hardware
Im Falle der Autoren wurde ein Raspberry Pi verwendet an den verschiedenste weitere Geräte angeschlossen wurden.
Dementsprechend ist es nicht sinnvoll diesen Prototypen als seriöses System zu betrachten. Die Definition und Durchführung von Testfällen erübrigten sich der Meinung der Autoren nach. Es sollte darauf geachtet werden eine ausreichende Stromversorgung des Rechnerknotens da diese Anwendung mehrere parallellaufende Prozesse erfordert und somit die Rechenlast hoch ist.
Der Prototyp verwendet eine gewöhnliche Webcam zur Detektion der Fahrerhaltung und ob der Fahrer sie einhält.
Umgesetzt wurde dies in einer gut beleuchteten Umgebung.
Für eine verbesserte Iteration des Prototyps kommt in Betracht für eine stabile und genau Aufzeichnung von Kopfposition, Augen, Mimik und Köperhaltung eine Infrarotkamera zu verwenden. Diese kann im Bereich des Tachos installiert werden, mit dem Risiko von Lenkradstellungen verdeckt zu werden. Mit minimiertem Risiko verdeckt zu werden kann die Kamera im Bereich des Rückspiegels als Weitwinkelkamera installiert werden, mit dem Vorteil alle Fahrzeug Passagiere zu überblicken.
2) Harte Echtzeitanforderungen
Kritisch für dieses System ist es, die Zeitvorgaben einzuhalten, da sonst ein negativer Nutzen (Schaden) entstehen könnte. Die Verarbeitung der Bilddaten ist Rechenintensiv. Dementsprechend kamen die Autoren mit dem Raspberry Pi nur etwa auf ein Bild pro Sekunde. Die Verzögerungen, die dadurch entstehen sind für ein solches System nicht tragbar.
Eine Grundvoraussetzung damit die Daten, welche von der Kamera aufgezeichnet werden, tatsächlich ausgewertet werden können ist ein Bilderkennungssystem auf der Softwareseite. Hierzu verwendeten die Autoren TensorFlow.
In der Anwendung identifiziert es ausschließlich Personen und ob diese sich in einem sicheren oder nicht sicheren Bereich aufhalten. Eine Weiterentwicklung des Prototyps muss nicht nur eine Person identifizieren können sondern auch ihre Bewegung und Position von Schultern, Arme, Hände und Torso anhand der X und Y-Achse bestimmen. Die Neigungen vom Kopf müssen ebenfalls bestimmt werden könne. Dazu kommt die Bestimmung von Augenöffnung, Pupillenposition und Zustand, Augenbraun und idealerweise Gesichtsfalten (bei verzerrtem Gesichtsausdruck im Schmerzensfall und Körpertemperaturmessung anhand der Gesichtsverfärbung mit Infrarot Aufnahme).
3) Schnittstellen zu anderen Steuergeräten
Die Autoren sind der Ansicht, dass dieser Prototyp ein hohes Potenzial besitzt, nicht zuletzt, weil die Ansteuerung und Kommunikation zu anderen Steuergeräten implizit ist. Es kann schnell und einfach mit anderen Steuergeräten kommuniziert, um die Systemgrenzen zu erweitern und das System zu verbessern. Dazu gehört ein mit Sensoren versehenes Lenkrad damit das Lenkverhalten ausgewertet werden kann und Hände am Lenkrad detektiert werden können. Zuletzt fehlt dem Prototyp die ADAS Funktionalitäten, die verwendet werden, damit im Eintrittsfall das Fahrzeug autonom und unfallfrei am Fahrbahnrand angehalten werden kann und Hilfe für den Fahrer sichergestellt wird (Am Fahrbahnrand zum Stopp kommen und Fahrzeugtüren entriegeln).
Zusammenfassend erfüllte der Prototyp die Erwartungshaltung und Ziele der Autoren, im Hinblick auf die prototypischen Use-Cases. In Gegenüberstellung zu den realitätsnahen Use Cases sind die Schwächen ersichtlich.
Begründet ist dies, durch die Einfachheit der verwendeten Hardware. Die gesammelten Erkenntnisse, die durch die Auswertung und Gegenüberstellung entstanden sind, werden im nächsten Kapitel vorgestellt.
VII. OFFENE FRAGESTELLUNGEN/AUSBLICK
Die Folgen eines plötzlichen Unvermögens während der freien Fahrt führen zu weitreichenden Gefahren des betroffenen Fahrers und anderer Verkehrsteilnehmer. Diese Gefahren gilt es im Interesse aller zu vermeiden. Die Euro- NCAP ist mit der Roadmap für 2025 ein weiterer Motivator für die Realisierung eines funktionsfähigen und serienmäßigen “Driver State Monitoring”-Systems mit gefahrenreduzierenden Maßnahmen. Durch Erkennen plötzlichen Unvermögens und infolgedessen die Ausführung schadensminimierender Aktionen können diese Gefahren verhindert werden. Die Umsetzung benötigt die aktuellsten
“Advanced Driver Assistance Systems” in Kombination mit dem DSM, das selbst noch in der Entwicklung ist. Die Erkennung von plötzlichen Unvermögen und die darauffolgenden Aktionen stehen Herausforderungen gegenüber, die nachfolgend von den Autoren diskutiert werden. Die Herausforderungen lassen sich in drei Themen unterteilen.
A. Visuelle erkennung
Die zuverlässige Erkennung von plötzlichen Unvermögen mit dem kamerabasierten System besaßen am vorgestellten Prototypen Verbesserungspotenziale. Durch die Bewertung des vorgestellten Prototyps haben die Autoren offene Fragen identifiziert, deren Nachforschung zu einem zielerfüllenden und stabilen DSM System führen kann.
Zu einem empfiehlt sich die Verwendung einer Infrarotkamera, die theoretisch durch geringere Abhängigkeit von Beleuchtung sich als effizienter bei der Erfassung von Körper und Gesicht herausstellt. Dies ist wichtig bei einer Umgebung, wie der Innenraum eines Fahrzeugs. Neben der Hardware bedarf es auch ein eingelerntes Erkennungssystem, welches (wie in Kapitel VI H) die vielen beschriebenen Daten zur Körperhaltung und Zustände am Gesicht erfassen kann.
Ebenfalls Thema ist die Platzierung der Kamera. Bei einer Montage nahe des Kombiinstruments ist es möglich, dass die Kamera vom Lenkrad verdeckt sein kann. Ist die Platzierung am Rückspiegel vorteilhafter? Durch eine Weitwinkel Linse
sind neben dem Fahrer auch andere Passagiere möglich zu erkennen.
B. Sensorkombinatorik und Ursachebestimmung
Weiterführende Überlegungen sind die Detektion anderer Attribute wie bspw. der Puls, durch weitere Sensoren. Mit der Implementation von Apple CarPlay und Android Auto ist die Zuhilfenahme von Smartwaches denkbar, um ohne Eingreifen in den Fahrkomfort den Puls des Fahrers zu ermitteln. Des Weiteren ist im Eskalationsfall bei der Aktivierung des automatischen Notrufs die Verwendung der Kameraaufnahme denkbar. Somit kann ein Fachexperte erste Annahme treffen und diese dem Notfallpersonal mitteilen. Die Autoren haben auch die Möglichkeiten der Identifizierung von Arten von plötzlichen Unvermögen aufgezeigt und welche zu erfassenden Daten diesen zugewiesen werden können. Bei weiterer Nachforschung können diese theoretischen Ansätze gegebenenfalls realisiert werden können.
C. Maßnahmereaktionen des Fahrzeugs
Beim Thema der zu umsetzenden Maßnahmen ist das DMS System beim Eintreten von plötzlichen Unvermögen des Fahrers limitiert. Für eine möglichst hohe Gefahrenreduzierung sollte das betroffene Fahrzeug selbstständig den Verkehr verlassen können, ohne selbst zu einer Gefahr oder Hindernis im Straßenverkehr zu werden (Auf dem eigenen Fahrstreifen anhalten, am Fahrbahnrand anhalten, an einer Autobahnraststätte oder sicheren Parkmöglichkeit anhalten). Gleichzeitig lässt sich die Frage identifizieren, wie andere Verkehrsteilnehmer informiert und motiviert werden können dem temporär autonomen Fahrzeug und den betroffenen Fahrer zu unterstützen. Aktuelle Use- Cases beschreiben Lenk- und Bremsmanöver, die eine ungewöhnliche Situation für andere Verkehrsteilnehmer schaubar machen können [17]. Besondere Signale durch die Warnblinklichtanlage seien auch Möglichkeiten, um andere Verkehrsteilnehmer zu informieren [11]. Diskutierbar ist die Verwendung des Infotainmentsystem mit visuellen und auditiven Nachrichten im Fahrzeug. Personen, die dem Fahrzeug nahe kommen könnten vom Fahrzeug informiert werden, dass der Fahrer Erste Hilfe benötigt und welchem Unvermögen dieser erliegt.
D. Zulassung/Rechtliches
Zusammenhängend mit dem Fahrzeug, welches als Maßnahme den Verkehr verlassen muss, sind rechtliche Themen. Nicht auszuschließen ist die Frage der Haftung, wenn ein Fahrzeug, dass ohne vom Fahrer geführt wird, selbstständig am Verkehr teilnimmt. Da auch die Gesundheit des Fahrers eine entscheidende Rolle spielt und die Identifikation des plötzlichen Unvermögens ein medizinisches Themengebiet ist stellt sich die Frage, ob das System als Medizingerät zugelassen werden muss. Hinzu würden weitere Anforderungen aus dem Medizinischen Bereich kommen.
Als Sonderausstattung oder Serienausstattung sind DSM Systeme bereits in aktuellen Fahrzeugen im Angebot.
Innerhalb ihrer unterschiedlichen Systemgrenzen und Anwendungsfällen funktionieren sie verschieden und erfüllen teils nicht die Euro-NCAP Anforderungen für 2025. Wird eine Synergie der bisher existierenden Lösungsansätze geschaffen, die von den Autoren vorgestellt wurden und die offenen Fragestellungen erforscht kann von einer Erfüllung der Euro- NCAP Roadmap ausgegangen werden.
VIII. REFERENCES
[1] EURO NCAP. (2017, September). Euroncap-roadmap-2025-v4.
(Vierte Auflage) [Online]. Available:
https://cdn.euroncap.com/media/30700/euroncap-roadmap-2025- v4.pdf [Zugriff am: 08.07.2021]
[2] Klein, H., Krämer, A., Pieske, B. et al. (2010). Fahreignung bei kardiovaskulären Erkrankungen. Kardiologe 4, (441–473) [Online].
Available: https://doi.org/10.1007/s12181-010-0308-9 [Zugriff am:
08.07.2021]
[3] Petch MC (on behalf of the task force, 1998) Driving and heart disease.
Eur Heart J 19:1165–1177
[4] Maisel WH (2006) Pacemaker and ICD generator reliability. JAMA 295:1929–1934
[5] „Hypoglykämien im Straßenverkehr und Verkehrsunfälle bei Diabetikern unter verschiedenen Diabetestherapien“, Wölfel, S., Universität Erlangen-Nürnberg (2013)
[6] Begutachtungsleitlinien zur Kraftfahreignung, Bundesanstalt für Straßenwesen, Bergisch Gladbach, Stand 31. Dezember 2019 [7] „Gestaltung eines Notfallassistenzsystems bei medizinisch bedingter
Fahrunfähigkeit“ Mirwaldt, P., Bartels, A., To T.-B., Pascheka P.
[8] „Fahrleistungsrelevante Parameter im Alter“ H. Ehmen, , 2010 [9] T. Gasser, C. Arzt, M. Ayoubi, A. Bartels et al., Rechtsfolgen
zunehmender Fahrzeugautomatisierung. BASt-Reihe
"Fahrzeugtechnik" BASt-F-83, Wirtschaftsverlag NW - Verlag für neue Wissenschaft GmbH, 2012
[10] P. Waldmann, N. Kaempchen, M. Ardelt, F. Homm, Der Nothalteassistent – abgesichertes Anhalten bei plötzlicher Fahrunfähigkeit des Fahrzeugführers, 2010.
[11] F. Schwarz, R. Decke, Kooperatives Verhalten bei Nothalt-Manövern:
Verhaltenswirksamkeit und Verständlichkeit von Anzeigekonzepten und Fahrmanövern, BMW Group Forschung und Technik, München, in: VDI-Berichte, S. 327–336, 2011.
[12] (2014, Oktober 8. und 9.). Datenschutz im Kraftfahrzeug – Automobilindustrie ist gefordert. [Online]. Available: Datenschutz im Kraftfahrzeug – Automobilindustrie ist gefordert (datenschutzkonferenz-online.de) [Zugriff am: 08.07.2021]
[13] (2016). Datenschutzrechtliche Aspekte bei der Nutzung vernetzter und nicht vernetzter Kraftfahrzeuge. [Online]. Available:
https://lfd.niedersachsen.de/startseite/themen/weitere_themen_von_a_
z/kfz/kfz-und-datenschutz-148981.html [Zugriff am: 08.07.2021]
[14] Kitchenham B., O. Pearl, B., Budgen, D., Turner, M., Bailey, J., Linkman, S. - Systematic literature reviews in software engineering – A systematic literature review, 2008
[15] (2021, Februar 12.). Gesetzesentwurf der Bundesregierung, Entwurf eines Gesetzes zur Änderung des Straßenverkehrsgesetzes und des Pflichtver-sicherungsgesetzes – Gesetz zum autonomen Fahren.
[Online] Available: https://dserver.bundestag.de/brd/2021/0155- 21.pdf [Zugriff am: 08.07.2021]
[16] (2005, September 6.). Toyota Enchances Pre-crash Safety System With Driver-monitoring Function. [Online]. Available: Toyota Enhances Pre-crash Safety System With Driver-monitoring Function | Toyota Motor Corporation Official Global Website [Zufriff am 14.05.2021]
[17] Emergency Assist [Online]. Available: Emergency Assist | Volkswagen Newsroom (volkswagen-newsroom.com) [Zugriff am 30.05.2021]
