DE102017219302A1 - Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr - Google Patents

Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr Download PDF

Info

Publication number
DE102017219302A1
DE102017219302A1 DE102017219302.6A DE102017219302A DE102017219302A1 DE 102017219302 A1 DE102017219302 A1 DE 102017219302A1 DE 102017219302 A DE102017219302 A DE 102017219302A DE 102017219302 A1 DE102017219302 A1 DE 102017219302A1
Authority
DE
Germany
Prior art keywords
data
hazard
vehicle
situation
vehicles
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102017219302.6A
Other languages
English (en)
Inventor
Young-Jae Cho
Jan-Mark Kunberger
Georg Movsisyan
Andreas Pelger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Priority to DE102017219302.6A priority Critical patent/DE102017219302A1/de
Priority to PCT/EP2018/072480 priority patent/WO2019081090A1/de
Priority to US16/650,249 priority patent/US11661079B2/en
Priority to CN201880062511.2A priority patent/CN111133486B/zh
Publication of DE102017219302A1 publication Critical patent/DE102017219302A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • B60W60/0011—Planning or execution of driving tasks involving control alternatives for a single driving scenario, e.g. planning several paths to avoid obstacles
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00—Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units, or advanced driver assistance systems for ensuring comfort, stability and safety or drive control systems for propelling or retarding the vehicle
    • B60W30/08—Active safety systems predicting or avoiding probable or impending collision or attempting to minimise its consequences
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • B60W60/0015—Planning or execution of driving tasks specially adapted for safety
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
    • G08B25/08—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium using communication transmission lines
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0125—Traffic data processing
    • G08G1/0133—Traffic data processing for classifying traffic situation
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications
    • G08G1/0145—Measuring and analyzing of parameters relative to traffic conditions for specific applications for active traffic flow control
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096708—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control
    • G08G1/096716—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control where the received information does not generate an automatic action on the vehicle control
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096708—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control
    • G08G1/096725—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control where the received information generates an automatic action on the vehicle control
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096733—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place
    • G08G1/096741—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place where the source of the transmitted information selects which information to transmit to each vehicle
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096775—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is a central station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle
    • G08G1/096805—Systems involving transmission of navigation instructions to the vehicle where the transmitted instructions are used to compute a route
    • G08G1/096811—Systems involving transmission of navigation instructions to the vehicle where the transmitted instructions are used to compute a route where the route is computed offboard
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
    • G08G1/205—Indicating the location of the monitored vehicles as destination, e.g. accidents, stolen, rental
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
    • G08B25/016—Personal emergency signalling and security systems

Abstract

Die vorliegende Erfindung umfasst ein Verfahren zur Reduzierung des Gefahrenpotentials einer Vielzahl von Fahrzeugen mit heterogenen Antrieben. Das Verfahren umfasst ein Empfangen, an einem Backend-Server, von Gefahrendaten der Fahrzeuge, wobei die Gefahrendaten aktuelle Füllzustandsdaten zumindest eines Energiespeichers sowie eine aktuellen Position der jeweiligen Fahrzeuge. Das Verfahren umfasst zudem ein Erfassen, am Backend-Server, von Gefahrensituationsdaten umfassend eine Position sowie eine Art einer Gefahrensituation. Das Verfahren umfasst ein Auswerten, durch den Backend-Server, der Gefahrendaten der Fahrzeuge mit Bezug auf die Gefahrensituationsdaten; und ein automatisches Einleiten zumindest einer Schutzmaßnahme entsprechend den ausgewerteten Gefahrendaten.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr.
  • Fahrzeuge mit verschiedenen Antriebskonzepten sind bekannt. Neben Fahrzeugen mit Verbrennungsmotoren, z.B. Otto- und Dieselmotoren, sind Elektrofahrzeuge, beispielsweise elektrisch betriebene Zweiräder und Roller, insbesondere aber auch Elektroautos mit zumindest unterstützendem Elektroantrieb bekannt. So sind Mikro- Mild- und Vollhybridfahrzeuge bekannt, die parallele, leistungsverzweigte, serielle Hybridantriebskonzepte realisieren. Insbesondere sind Plug-in-Hybride bekannt, bei denen die elektrischen Energiespeicher - wie bei rein elektrischen Antriebskonzepten - über das Stromnetz aufgeladen werden können, wobei diese in der Regel zudem zumindest einen Verbrennungsmotor aufweisen. Auch bekannt sind Fahrzeuge, die einen Druckbehälter zur Speicherung eines Brennstoffs im Fahrzeug umfassen. Der Brennstoff kann beispielsweise komprimiertes oder verflüssigtes Erdgas oder Wasserstoff sein. Die zunehmende Anzahl an Fahrzeugen sowie die Heterogenität der Antriebskonzepte dieser bergen über Verkehrsunfälle an sich hinaus weitere Gefahren in sich. Beispiele für solche weitere Gefahren sind z.B. im Zusammenhang mit einem oder mehreren brennenden Fahrzeugen, Massenkarambolage, (terroristischen) Anschlägen, etc. Insbesondere verhalten sich Fahrzeuge je nach Antriebskonzepten unterschiedlich bei z.B. hohen Temperaturen, etc. Insbesondere für Rettungs- und/oder Einsatzkräfte ist es schwierig bis unmöglich, das Gefahrenpotential einhergehend mit Fahrzeugen, die sich an bzw. um eine solche Gefahrensituation hin befinden, bezüglich des individuellen Gefahrenpotentials einzuschätzen und/oder entsprechende Sicherheitsmaßnahmen zu ergreifen.
  • Die Aufgabe der Erfindung besteht darin, eine Lösung aufzuzeigen, die das Gefahrenpotential im Straßenverkehr ausgehend durch heterogene Antriebskonzepte in Fahrzeugen reduziert.
  • Diese Aufgabe wird erfindungsgemäß durch die Merkmale des unabhängigen Anspruchs gelöst. Bevorzugte Ausführungsformen sind Gegenstand der abhängigen Ansprüche.
  • Die vorstehend genannte Aufgabe wird durch ein Verfahren zur Reduzierung des Gefahrenpotentials einer Vielzahl von Fahrzeugen mit heterogenen Antrieben gelöst, umfassend:
    • Empfangen, an einem Backend-Server, von Gefahrendaten der Fahrzeuge, wobei die Gefahrendaten aktuelle Füllzustandsdaten zumindest eines Energiespeichers sowie eine aktuellen Position der jeweiligen Fahrzeuge umfasst;
    • Erfassen, am Backend-Server, von Gefahrensituationsdaten umfassend eine Position sowie eine Art einer Gefahrensituation;
    • Auswerten, durch den Backend-Server, der Gefahrendaten der Fahrzeuge mit Bezug auf die Gefahrensituationsdaten; und
    • automatisches Einleiten zumindest einer Schutzmaßnahme entsprechend den ausgewerteten Gefahrendaten.
  • Unter den Begriff Fahrzeug fallen insbesondere Personenkraftwagen (PKW), Lastkraftwagen (LKW), Busse, Wohnmobile, Krafträder, etc.
  • Der Backend-Server ist ein zentraler Datenpool und kann eine Recheneinrichtung, sowie eine Speichereinrichtung, z.B. eine Datenbank, umfassen, in der Daten zentral bzw. zentral gesteuert und fahrzeugextern abgelegt, verwaltet und verarbeitet werden können. Es kann erforderlich sein, dass der Nutzer jedes Fahrzeugs zunächst am Backend-Server (oder einer anderen geeignete Recheneinrichtung, die einen entsprechenden Dienst bereitstellt) eine einmalige Registrierung des Fahrzeugs durchzuführen (z.B. einen geeigneten Account einzurichten). Die Einmalige Registrierung kann die Hinterlegung des bzw. der Antriebskonzepte des Fahrzeugs als Antriebsdaten sowie einer geeigneten Fahrzeug-Identifikationsnummer (ID) umfassen. Die Antriebsdaten umfassen Daten hinsichtlich des bzw. der Antriebe des jeweiligen Fahrzeugs, z.B. ausschließlicher Verbrennungsmotor, Plug-in-Hybrid, reines Elektrofahrzeug, (zusätzlicher) Druckbehälter zur Speicherung von Erdgas oder Wasserstoff (z.B. kyrogener Druckbehälter zur Speicherung von Wasserstoff, Hochdruckgasbehälter zur Speicherung von Wasserstoff, Druckbehälter zur Speicherung von komprimiertem oder verflüssigtem Erdgas, etc.). Weitere gängige und/oder künftige Antriebsarten sind denkbar. So können Daten, die nachfolgend vom jeweiligen Fahrzeug an den Backend-Server gesendet werden, dem Fahrzeug sowie dem (den) Antriebskonzept(en) eindeutig zugeordnet werden. Der Nutzer des Fahrzeugs kann beispielsweise dessen Besitzer, Verwalter, Fahrer, etc. sein.
  • Der Backend-Server ist eingerichtet, Gefahrendaten von den (vorher registrierten) Fahrzeugen zu empfangen. Beispielsweise kann jedes Fahrzeug eingerichtet sein, die Gefahrendaten in vordefinierbaren bzw. vordefinierten zeitlichen Abständen, z.B. jede Minute, alle 2, 5, 10 oder 20 Minuten zu übermitteln. Darüber hinaus oder alternativ dazu kann jedes Fahrzeug eingerichtet sein, die Gefahrendaten zu vordefinierten Ereignissen zu übermitteln, z.B. bei jedem Fahrtantritt, bei jedem Halten, bei jedem Parken, nach einem vordefinierbaren bzw. vordefinierten Energieverbrauch, bei Verfügbarkeit von Datenübertragungsanforderungen (z.B. erforderlicher Mobilfunkstandard wie LTE, 3G, ...), etc.
  • Die Gefahrendaten umfassen aktuelle Füllzustandsdaten zumindest eines Energiespeichers des Fahrzeugs. Je nach Antriebskonzept kommen verschiedene Energiespeicher zum Einsatz, die bei der einmaligen Registrierung des Fahrzeugs am Backend-Server erfasst werden können, z.B. Kraftstofftank beim Verbrennungsmotor, (Elektro-)Batterie beim Elektroantrieb, Wasserstofftank bei Wasserstoffantrieb, etc. Bei Hybridantrieben werden die jeweiligen Antriebe im Fahrzeug durch unterschiedliche Energiespeicher gespeist. Bei der Kombination aus Elektro- und Verbrennungsmotor beispielsweise kommen als Energiespeicher Elektrobatterie und Kraftstofftank zum Einsatz. Das jeweilige Fahrzeug kann den Füllzustand des (bzw. der) Energiespeicher(s) beispielsweise über eine Steuereinheit ermitteln bzw. auslesen. Diese entsprechen den Füllzustandsdaten. Mit anderen Worten umfassen die Füllzustandsdaten zumindest die aktuell gespeicherte Energiemenge und Energieart des Fahrzeugs. Diese werden an den Backend-Server übertragen. Im Falle eines Drucktanks können die Füllzustandsdaten zudem dessen Expansionsenergie im jeweiligen Zustand umfassen. Bei chemischen Energiespeichern bzw. bei der chemischen Speicherung der Energie können die Füllzustandsdaten zudem Angaben über das gespeicherte Medium (Wasserstoff, Erdgas etc.) umfassen. Bei Batterien können die Füllzustandsdaten zudem Daten hinsichtlich der verbauten bzw. verwendeten Zellen umfassen, z.B. deren chemische Zusammensetzung, Baugröße und/oder Bauform.
  • Vorteilhafter Weise ermöglichen die Füllzustandsdaten, dass das Gefahrenpotenzial des jeweiligen Fahrzeugs, aber auch dass dieses Gefahrenpotential in Kombination mit verschiedenen Ereignissen bewertet werden kann.
  • In einem anderen Beispiel können auch nur die Sensordaten an den Backend-Server übermittelt werden, wobei die Füllzustandsdaten und - falls Anwendbar - die Expansionsenergie für die Drucktanks durch den Backend-Server auf aus dem Stand der Technik bekannte Weise bestimmt werden.
  • Werden relevante Änderungen am Fahrzeug wie z.B. eine Umrüstung, eine Tankvergrößerung, eine Erweiterung der Batteriespeicher etc. vorgenommen, können sich die Gefahrendaten ändern. Werden am Fahrzeug Änderungen durchgeführt die zu einer Änderungen der Gefahrendaten durchführen, müssen die Gefahrendaten am Backend-Server aktualisiert werden. Hierzu kann im Rahmen der Änderung ein „Trigger“ gesetzt werden, der dazu führt, dass die Gefahrendaten manuell, z.B. durch den Nutzer des Fahrzeugs, oder automatisch aktualisiert werden.
  • Die Gefahrendaten umfassen zudem eine aktuelle Position des jeweiligen Fahrzeugs. Die aktuelle Position bzw. aktuelle Positionsdaten des Fahrzeugs können mithilfe eines Navigationssatellitensystems ermittelt werden. Bei dem Navigationssatellitensystem kann es sich um jedes gängige sowie künftige globale Navigationssatellitensystem bzw. Global Navigation Satellite System (GNSS) zur Positionsbestimmung und Navigation durch den Empfang der Signale von Navigationssatelliten und/oder Pseudoliten handeln. Beispielsweise kann es sich dabei handeln um das Global Positioning System (GPS), GLObal NAvigation Satellite System (GLONASS), Galileo, positioning system, und/oder BeiDou Navigation Satellite System, handeln. Beispielsweise kann das Fahrzeug ein Modul umfassen, welches geeignet ist, im jeweiligen System eine Position des Fahrzeugs zu erfassen. Im Beispiel von GPS kann das Fahrzeug eine Positionsermittlungseinheit umfassend ein GPS-Modul umfassen, das ausgebildet ist, die aktuelle GPS-Position des Fahrzeugs zu ermitteln.
  • Die Gefahrendaten - umfassend die Füllzustandsdaten und die aktuelle Position des Fahrzeugs - werden schließlich an den Backend-Server gesendet. Jedes Fahrzeug kann ein Kommunikationsmodul umfassen. Das Kommunikationsmodul kann ein im Fahrzeug angeordnetes Kommunikationsmodul sein, welches in der Lage ist, eine Kommunikationsverbindung mit anderen Kommunikationsteilnehmern, beispielsweise mit dem Backend-Server, aufzubauen. Das Kommunikationsmodul kann ein Teilnehmeridentitätsmodul bzw. ein Subscriber Identity Module bzw. eine SIM-Karte umfassen, welche(s) dazu dient, eine Kommunikationsverbindung über ein Mobilfunksystem aufzubauen. Das Teilnehmeridentitätsmodul identifiziert dabei das Kommunikationsmodul eindeutig im Mobilfunknetz. Bei der Kommunikationsverbindung kann es sich um eine Datenverbindung (z.B. Paketvermittlung) und/oder um eine leitungsgebundene Kommunikationsverbindung (z.B. Leitungsvermittlung) handeln. Jede Kommunikation zwischen dem Fahrzeug und anderen Kommunikationsteilnehmern kann über das Kommunikationsmodul erfolgen.
  • Der Backend-Server ist zudem eingerichtet, Gefahrensituationsdaten zu erfassen. Die Gefahrensituationsdaten umfassen zumindest eine Position bzw. Positionsdaten (siehe oben, z.B. GPS-Positionsdaten) sowie eine Art einer Gefahrensituation. Eine Gefahrensituation kann beispielsweise ein Fahrzeugbrand, ein Hausbrand, ein (Gift)-Gasaustritt aus einer Industrieanlage, ein (terroristischer) Anschlag, eine Massenkarambolage, ein Tumult, ein Falschfahrer, ein fehlerhaftes autonom fahrendes Fahrzeug, ein Bombenfund, etc. sein. Auch sämtliche weitere Gefahrensituationen sind möglich.
  • Beispielsweise können die Gefahrensituationsdaten von einem intelligenten Objekt übermittelt und am Backend-Server empfangen werden. Das intelligente Objekt kann beispielsweise ein System einer Notrufzentrale sein, welches bei Eintreten einer Gefahrensituation automatisch einen Datensatz umfassend die Gefahrensituationsdaten an den Backend-Server übermittelt. In einem anderen Beispiel kann der Backend-Server eingerichtet sein, Gefahrensituationsdaten in regelmäßigen zeitlichen Abständen von einem zentralen Gefahrendatenpool, z.B. einer zentralen Notrufleitstelle, abfragen bzw. abrufen (Polling). Beispielsweise können Gefahrensituationsdaten von einer intelligenten Ampel übertragen werden, die das Überfahren dieser bei Rot erkennt und automatisch an den Backend-Server übermittelt. Darüber hinaus oder alternativ dazu können Gefahrensituationsdaten von einer intelligenten Autobahnauffahrt, die einen Falschfahrer erkennt, automatisch an den Backend-Server übermittelt werden.
  • Der Backend-Server kann eingerichtet sein, zunächst relevante Gefahrendaten zu identifizieren. Beispielsweise kann in der Speichereinheit des Backend-Servers zunächst zu jeder Gefahrensituation ein Bereich, ein Radius, etc. um die Position der Gefahrensituation definiert sein, der durch die bzw. von der Gefahrensituation betroffen ist bzw. einer Gefährdung unterliegt. In diesem Beispiel kann der Backend-Server lediglich Gefahrendaten von Fahrzeugen berücksichtigen, deren aktuelle bzw. letzte Position (z.B. GPS-Position) innerhalb dieses vordefinierten Bereichs bzw. Gebiets, Radius, etc. liegt. Dabei werden die Gefahrendaten mit berücksichtigt.
  • Der Backend-Server ist eingerichtet, die (relevanten) Gefahrendaten der Fahrzeuge mit Bezug auf die Gefahrensituationsdaten auszuwerten. Dazu können bekannte Techniken der Datenverarbeitung angewandt werden. Beispielsweise kann der Backend-Server eine Datenanalyse zu den gespeicherten Daten mit Bezug auf die Gefahrensituationsdaten (z. B. maschinelle Lernanalyse, Datenmodellierung, Mustererkennung, Vorhersageanalyse, Korrelationsanalyse usw.) durchführen, um implizite Beziehungen oder Schlussfolgerungen für die gespeicherten Daten mit Bezug auf das Gefahrenpotential vorherzusagen, zu berechnen oder zu identifizieren. Dazu kommt eine Vielzahl von Datenlernalgorithmen und Klassifizierungstechniken wie z.B. die Partial-Least-Square-Regression (PLS-Regression), Random-Forest und/oder Hauptkomponentenanalyse (PCA) in Betracht.
  • Der Backend-Server ist eingerichtet, entsprechend den ausgewerteten Gefahrendaten zumindest eine Schutzmaßnahme einzuleiten.
  • Vorzugsweise umfasst das Auswerten der Gefahrendaten zudem ein Auswerten von Umgebungsdaten mit Bezug auf die Position der Gefahrensituation.
  • Der Backend-Server kann eingerichtet sein, Umgebungsdaten beispielsweise betreffend einen vordefinierten Bereich und/oder Radius die Position der Gefahrensituation (z.B. digitale Straßenkarten) über ein geeignetes Netzwerk, z.B. das Internet, von entsprechenden Dienstanbietern bzw. Service Providern abzurufen.
  • Darüber hinaus oder alternativ dazu kann der Backend-Server eingerichtet sein, die Umgebungsdaten über so genanntes Crowd-Sourcing zu erfassen. Beim Crowd-Sourcing können über die Gefahrendaten hinaus verschiedenste Daten von den Fahrzeugen sowie weiterer teilnehmender intelligenter Objekte an den zentralen Backend-Server übermittelt und zentral verwaltet werden. Bei den zusätzlichen Daten der Fahrzeuge kann es sich beispielsweise handeln um:
    • - Wetterdaten, die z.B. von ein oder mehreren Regen- und/oder Sonnen- und/oder Temperatursensoren im Fahrzeug erfasst werden;
    • - aktuelle Umgebungsinformationen, die z.B. durch im oder am Fahrzeug angebrachte Kameras erfasst werden;
    • - weitere aktuelle Umgebungsdaten, die z.B. durch eine oder mehrere Digitalkameras, Radar- und/oder Lidar- und/oder Sonarsensoren des Fahrzeugs angebracht werden.
  • Die Fahrzeuge können die Daten zu vordefinierten Ereignissen erfassen und an den Backend-Server übermitteln. Dies kann beispielsweise in regelmäßigen zeitlichen Abständen, zu vordefinierten Zeitpunkten und/oder Ereignissen geschehen. Darüber hinaus oder alternativ dazu kann der Backend-Server nach erfasster Gefahrensituation Fahrzeuge, die sich in einem vordefinierten Gebiet oder Radius um die Gefahrensituation befinden, auffordern, ein oder mehrere der vorgenannten Daten über die entsprechenden, im Fahrzeug befindlichen Sensoren zu erfassen und an den Backend-Server zu übermitteln. In diesem Beispiel kann bei der einmaligen Registrierung der Fahrzeuge jeweils hinterlegt werden, welche Sensoren am und/oder im Fahrzeug verbaut sind.
  • Intelligente Objekte sind in der Lage, mithilfe eines Kommunikationsmoduls (analog zum Kommunikationsmodul im Fahrzeug, siehe oben) eine Kommunikationsverbindung mit anderen Kommunikationsteilnehmern, z.B. dem Backend-Server, aufzubauen, um so Daten an den Backend-Server zu übermitteln. Diese Daten können weitere Gefahrendaten, Verkehrsinformationen, Änderungen in der Straßenführung, etc. umfassen. Aus diesen Daten kann der zumindest eine zentrale Backend-Server eine hochaktuelle digitale Umgebungskarte generieren. Weitere Beispiele für intelligente Objekte sind vernetzte (Straßen-) Infrastruktursystem, die jeweils mit entsprechende Sensoren - analog zu Fahrzeugen - Ihre Umgebung erfassen können und diese an den Backend-Server übermitteln können. Intelligente Objekte können intelligente Verkehrszeichen und/oder intelligente Ampeln umfassen, die in der Lage sind, verkehrsgefährdende Verstöße zu erkennen und als Gefahrendaten an den Backend-Server übermitteln. Intelligente Objekte können darüber hinaus oder alternativ dazu Tankstellen bzw. Tankeinrichtungen umfassen, die einen End-of-Life Status eines Druckbehälters erkennen und diesen daher nicht betanken können.
  • Ergebnis des Auswertens der Gefahrendaten kann ein Gefahrenpotential sein.
  • Vorzugsweise umfassen die Umgebungsdaten:
    • - eine Bevölkerungsdichte;
    • - eine Verkehrsdichte zum Zeitpunkt der Gefahrensituation;
    • - Hauptverkehrsstraßen in einem vordefinierten Radius um die Position der Gefahrensituation;
    • - aktuelle Wetterdaten;
    • - ein Umgebungsmodell eines Fahrzeugs umfassend einen vollautonomen Fahrmodus; und/oder
    • - sonstige Gefahrendaten umfassend die den vordefinierten Radius um die Position der Gefahrensituation.
  • Vorzugsweise umfasst die Schutzmaßnahme ein Benachrichtigen von Rettungs- und/oder Einsatzkräften über ein Gefahrenpotential entsprechend den ausgewerteten Gefahrendaten.
  • Der Backend-Server kann eingerichtet sein, ein Gefahrenpotential, welches Ergebnis des Auswertens der Gefahrendaten sein kann, an Rettungs- und/oder Einsatzkräfte zu übermitteln.
  • Vorteilhafter Weise können sich Rettungs- und/oder Einsatzkräfte auf die Gefahrensituation besser vorbereiten, wodurch das Gefahrenpotential mit Bezug auf die Gefahrensituation reduziert wird.
  • Vorzugsweise umfasst die Schutzmaßnahme eine Einteilung eines vordefinierten Bereichs um die Position der Gefahrensituation in Gefahrenzonen entsprechend den ausgewerteten Gefahrendaten.
  • Der Backend-Server kann eingerichtet sein, entsprechend den ausgewerteten Gefahrendaten einen vordefinierten Bereich um die Position der Gefahrensituation herum in Gefahrenzonen einzuteilen. Auch die Einteilung in Gefahrenzonen kann beispielsweise an Rettungs- und/oder Einsatzkräfte übermittelt werden. Vorteilhafter Weise können sich Rettungs- und/oder Einsatzkräfte so besser auf die Gefahrensituation vorbereiten, wodurch das Gefahrenpotential mit Bezug auf die Gefahrensituation reduziert wird.
  • Vorzugsweise umfasst die Schutzmaßnahme eine Empfehlung zur Räumung von Gebäuden und/oder Plätzen.
  • Vorzugsweise umfasst die Schutzmaßnahme eine Aktivierung zumindest einer Funktion einer Sicherheitseinrichtung.
  • Sicherheitseinrichtungen können intelligente Sicherheitsobjekte sein, z.B. intelligente Lüftungssysteme in Gebäuden, Fahrzeugen, etc.; intelligente Sprinklersysteme in Gebäuden, Fahrzeugen, intelligente Infrastruktursysteme, etc. Funktionen der Sicherheitseinrichtungen können ein Ein - oder Ausschalten der Lüftung, ein Ein- oder Ausschalten des Sprinklersystems, etc. sein. Die Aktivierung der zumindest einen Funktion einer Sicherheitseinrichtung erfolgt mit Bezug auf die ausgewerteten Gefahrendaten.
  • Beispielsweise kann eine Gefahrensituation ein brennendes Gebäude sein. Der Backend-Server kann eine Nachricht an ein intelligentes Sprinklersystem im Gebäude senden, die Sprinkleranlage zu aktivieren. Darüber hinaus oder alternativ dazu kann der Backend-Server eine Nachricht an intelligente Ampelanlagen in einem vordefinierten Bereich bzw. Gebiet um das qualmende Gebäude herum übermitteln, so dass diese ihre Signale derart einstellen, dass keine Fahrzeuge mehr in diesen Bereich einfahren, sondern nur ausfahren können.
  • Vorzugsweise umfasst zumindest ein Fahrzeug einen vollautonomen Fahrmodus; wobei die Schutzmaßnahme ein Auffordern des Fahrzeugs umfassend den vollautonomen Fahrmodus zum autonomen Verlassen eines vordefinierbaren Bereichs um die Position der Gefahrensituation umfasst.
  • Fahrzeuge, die einen vollautonomen bzw. automatischen Fahrmodus umfassen, sind bekannt. Solche Fahrzeuge können sich autonom mittels einer Fahrerassistenzeinrichtung bzw. einem Autopilot im Straßenverkehr bewegen. Somit kann das Führen des Fahrzeugs unabhängig von einem Nutzer bzw. Fahrer des Fahrzeugs erfolgen, so dass bei aktiviertem vollautonomen Fahrmodus kein Fahrer im Fahrzeug zu sein braucht. Während der vollautonome Fahrmodus aktiv ist, verarbeitet die Fahrerassistenzeinrichtung fortlaufend aktuelle Umgebungsdaten. Dazu ist eine Vielzahl unterschiedlicher Sensoren im bzw. am Fahrzeug angebracht, um Umgebungsdaten zu erfassen. Bei den Sensoren kann es sich beispielsweise um Ultraschallsensoren, Lidar-Sensoren, Radarsensoren, Kameras, etc. handeln. Die erfassten Sensordaten werden dann in der Steuereinrichtung verarbeitet, um ein Umgebungsmodell des Fahrzeugs zu ermitteln. Auf Grundlage des Umgebungsmodells wird der vollautonome Fahrmodus ausgeführt.
  • Beispielsweise kann der Backend-Server eingerichtet sein, eine entsprechende Nachricht an die Kommunikationseinheit des Fahrzeugs zu übermitteln. Die Nachricht kann eine Aufforderung zum Verlassen eines vordefinierten Bereichs um die Gefahrensituation umfassen. Die Nachricht kann eine Darstellung des vordefinierten Bereichs auf einer digitalen Karte umfassen. Alternativ dazu kann die Nachricht die Aufforderung zum Verlassen des vordefinierten Bereichs sowie eine Position auf der digitalen Karte umfassen, an die sich das Fahrzeug hin bewegen soll. Die Position befindet sich außerhalb des vordefinierten bzw. vordefinierbaren Bereichs um die Position der Gefahrensituation. Eine Recheneinheit kann die Nachricht verarbeiten und ein Steuermodul im Fahrzeug kann das Fahrzeug derart steuern, dass dieses autonom den vordefinierten Bereich verlässt bzw. sich an die empfangene Position außerhalb der Gefahrensituation bewegt. Das Fahrzeug kann ein Navigationsmodul umfassen, in dem die entsprechende digitale Straßenkarte lokal im Fahrzeug hinterlegt ist. Vorteilhafter Weise können sich so parkende Fahrzeuge umfassend einen autonomen Fahrmodus von der Gefahrensituation wegbewegen, wodurch das Gefahrenpotential um die Gefahrensituation weiter reduziert wird.
  • Vorzugsweise umfasst die Schutzmaßnahme eine Warnung anderer Verkehrsteilnehmer.
  • Beispielsweise kann der Backend-Server eingerichtet sein, eine entsprechende Nachricht an die Kommunikationseinheiten von Fahrzeugen anderer Verkehrsteilnehmer senden, die von der Gefahrensituation betroffen sind. Die Nachricht kann eine Warnung umfassen, welche über eine geeignete Ausgabeeinheit der jeweiligen Fahrzeuge ausgegeben werden kann.
  • Vorzugsweise umfasst die Schutzmaßnahme einen aktiven Eingriff in die Fahrdynamik und/oder Trajektorienplanung anderer Verkehrsteilnehmer.
  • Der Backend-Server kann beispielsweise eine geeignete Nachricht an die Kommunikationseinheit von Fahrzeugen, die hochautomatisiertes Fahren (HAF) bzw. vollautomatisiertes Fahren (VAF) unterstützen, übermitteln. Die Nachricht kann entsprechende Daten umfassen, die geeignet sind, dass Fahrzeuge, die von der Gefahrensituation betroffen sind, aktiv in die Fahrdynamik und/oder Trajektorienplanung einzugreifen.
  • Diese und andere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden aus dem Studium der folgenden detaillierten Beschreibung bevorzugter Ausführungsformen und der beiliegenden Figuren verdeutlicht. Es ist ersichtlich, dass - obwohl Ausführungsformen separat beschrieben werden - einzelne Merkmale daraus zu zusätzlichen Ausführungsformen kombiniert werden können.
    • 1 zeigt ein schematisches System, das geeignet ist, ein Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr durchgeführt werden kann;
    • 2 zeigt ein Flussdiagramm, das ein Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr veranschaulicht;
    • 3 zeigt ein beispielhaftes Szenario, in dem das Gefahrenpotential im Straßenverkehr durch ein entsprechendes Verfahren reduziert wird.
  • 1 zeigt schematisches System 100, auf dem ein Verfahren 200 zur Reduzierung des Gefahrenpotentials im Straßenverkehr durchgeführt werden kann. Das Verfahren 200 wird weiter unten mit Bezug auf 2 und 3 beispielhaft näher erläutert.
  • Das System 100 umfasst zumindest einen Backend-Server 120. Der Backend-Server 120 ist ein zentraler Datenpool und kann eine Recheneinheit 124, sowie eine Speichereinheit 125, z.B. eine Datenbank 125, umfassen. In der Speichereinheit 120 können Daten zentral bzw. zentral gesteuert und fahrzeugextern abgelegt, verwaltet und verarbeitet werden. Es kann erforderlich sein, dass der Nutzer jedes Fahrzeugs 110 zunächst am Backend-Server 120 (oder einer anderen geeignete Recheneinrichtung, die einen entsprechenden Dienst bereitstellt) eine einmalige Registrierung durchführt (z.B. einen geeigneten Account einzurichten) um das Fahrzeug 110 einmalig zu registrieren. In einem anderen Beispiel kann die einmalige Registrierung im Sinne einer Erstregistrierung vom Hersteller durchgeführt werden. Die Einmalige Registrierung kann die Hinterlegung des bzw. der Antriebskonzepte des Fahrzeugs als Antriebsdaten sowie einer geeigneten Fahrzeug-Identifikationsnummer (ID) umfassen. Die Antriebsdaten umfassen Daten hinsichtlich des bzw. der Antriebe des jeweiligen Fahrzeugs, z.B. ausschließlicher Verbrennungsmotor, Plug-in-Hybrid, reines Elektrofahrzeug, (zusätzlicher) Druckbehälter zur Speicherung von Erdgas oder Wasserstoff (z.B. kyrogener Druckbehälter zur Speicherung von Wasserstoff, Hochdruckgasbehälter zur Speicherung von Wasserstoff, Druckbehälter zur Speicherung von komprimiertem oder verflüssigtem Erdgas, etc.). Weitere gängige und/oder künftige Antriebsarten sind denkbar. So können Daten, die nachfolgend vom jeweiligen Fahrzeug 110 an den Backend-Server gesendet werden, dem Fahrzeug sowie dem (den) Antriebskonzept(en) eindeutig zugeordnet werden. Der Nutzer des Fahrzeugs 110 kann beispielsweise dessen Besitzer, (Flotten-)-Verwalter, Mieter, etc. sein. Werden relevante Änderungen am Fahrzeug 110 - wie z.B. eine Umrüstung mit Bezug auf einen oder mehrere Antriebsarten, eine Tankvergrößerung, eine Erweiterung der Batteriespeicher etc. - vorgenommen, können sich die Gefahrendaten mit Bezug auf das Fahrzeug 110 ändern.
  • Werden am Fahrzeug 110 Änderungen durchgeführt die zu einer Änderungen der Gefahrendaten führen, müssen diese Daten am Backend-Server 120 bzw. in der Speichereinheit 125 aktualisiert werden. Hierzu kann im Rahmen der Änderung ein „Trigger“ gesetzt werden, über den die Daten manuell, z.B. durch den Nutzer des Fahrzeugs 110, oder automatisch aktualisiert werden. Um eine Änderung der Gefahrendaten am Backend-Server 120 sicherzustellen, kann beispielsweise der Trigger durch ein Steuergerät (nicht gezeigt) eines in der geänderten Fahrzeugkomponente verbauten Sensors realisiert werden. Dieses Steuergerät ist fest (nicht demontierbar) mit der geänderten Komponente (z.B. Drucktank) verbunden. Beim Startup sendet das Steuergerät eine Komponenten-Identifikationsnummer (ID) an ein zentrales Fahrzeugsteuergerät. Das zentrale Fahrzeugsteuergerät gleicht die empfangene Komponenten-ID mit in der Speichereinheit 125 hinterlegten (freigegebenen) Komponenten-IDs ab. Ist die Komponenten-ID nicht in der Speichereinheit 125 hinterlegt, kann das Fahrzeug in einen sicheren Zustand übergehen (z.B. kein Betrieb möglich).
  • Der Backend-Server 120 ist eingerichtet, Gefahrendaten von einer Vielzahl von (registrierten) Fahrzeugen 110 zu empfangen. Jedes Fahrzeug 110 kann ein Kommunikationsmodul 112 umfassen. Das Kommunikationsmodul 112 kann im Fahrzeug 110 angeordnet sein, und ist in der Lage, eine Kommunikationsverbindung mit anderen Kommunikationsteilnehmern, beispielsweise mit dem Backend-Server 120, aufzubauen. Das Kommunikationsmodul 112 kann ein Teilnehmeridentitätsmodul bzw. ein Subscriber Identity Module bzw. eine SIM-Karte (nicht gezeigt) umfassen, welche(s) dazu dient, eine Kommunikationsverbindung über ein Mobilfunksystem aufzubauen. Das Teilnehmeridentitätsmodul identifiziert dabei das Kommunikationsmodul eindeutig im Mobilfunknetz. Bei der Kommunikationsverbindung kann es sich um eine Datenverbindung (z.B. Paketvermittlung) und/oder um eine leitungsgebundene Kommunikationsverbindung (z.B. Leitungsvermittlung) handeln. Jede Kommunikation zwischen dem Fahrzeug 110 und anderen Kommunikationsteilnehmern kann über das Kommunikationsmodul 112 erfolgen.
  • Beispielsweise kann jedes Fahrzeug 110 eingerichtet sein, die Gefahrendaten in vordefinierbaren bzw. vordefinierten zeitlichen Abständen, z.B. jede Minute, alle 2, 5, 10 oder 20 Minuten an den Backend-Server 120 zu übermitteln bzw. senden. Darüber hinaus oder alternativ dazu kann jedes Fahrzeug 110 eingerichtet sein, die Gefahrendaten zu vordefinierten Ereignissen zu übermitteln, z.B. bei jedem Fahrtantritt, bei jedem Halten, bei jedem Parken, nach einem vordefinierbaren bzw. vordefinierten Energieverbrauch, bei Verfügbarkeit von Datenübertragungsanforderungen (z.B. erforderlicher Mobilfunkstandard wie LTE, 3G, ...), etc.
  • Die Gefahrendaten umfassen aktuelle Füllzustandsdaten bzw. zumindest eines Energiespeichers (nicht gezeigt) des entsprechenden Fahrzeugs 110. Je nach Antriebskonzept kommen verschiedene Energiespeicher zum Einsatz, z.B. Kraftstofftank beim Verbrennungsmotor, (Elektro-)Batterie beim Elektroantrieb, Wasserstofftank bei Wasserstoffantrieb, etc. Bei Hybridantrieben werden die jeweiligen Antriebe im Fahrzeug durch unterschiedliche Energiespeicher gespeist. Bei der Kombination aus Elektro- und Verbrennungsmotor beispielsweise kommen als Energiespeicher Elektrobatterie und Kraftstofftank zum Einsatz. Das jeweilige Fahrzeug 110 kann den Füllzustand des (bzw. der) Energiespeicher(s) beispielsweise über eine Steuereinheit 115 ermitteln bzw. auslesen.
  • Die Gefahrendaten umfassen zudem eine aktuelle Position des jeweiligen Fahrzeugs 110. Aktuelle Positionsdaten des Fahrzeugs 110 können mithilfe eines Navigationssatellitensystems ermittelt werden. Im Beispiel von GPS kann das Fahrzeug 110 eine Positionsermittlungseinheit (nicht gezeigt) umfassend ein GPS-Modul umfassen, das ausgebildet ist, die aktuelle GPS-Position des Fahrzeugs 110 zu ermitteln. Mit anderen Worten umfassen die Füllzustandsdaten zumindest die aktuell gespeicherte Energiemenge und Energieart des Fahrzeugs 110. Diese werden an den Backend-Server 120 übertragen. Im Falle eines Drucktanks können die Füllzustandsdaten zudem dessen Expansionsenergie im jeweiligen Zustand umfassen. Bei chemischen Energiespeichern bzw. bei der chemischen Speicherung der Energie können die Füllzustandsdaten zudem Angaben über das gespeicherte Medium (Wasserstoff, Erdgas etc.) umfassen. Bei Batterien können die Füllzustandsdaten zudem Daten hinsichtlich der verbauten bzw. verwendeten Zellen umfassen, z.B. deren chemische Zusammensetzung, Baugröße und/oder Bauform.
  • Vorteilhafter Weise ermöglichen die Füllzustandsdaten, dass das Gefahrenpotenzial des jeweiligen Fahrzeugs 110, aber auch dass dieses Gefahrenpotential in Kombination mit verschiedenen Ereignissen bewertet werden kann.
  • In einem anderen Beispiel können auch nur die Sensordaten an den Backend-Server 120 übermittelt werden, wobei die Füllzustandsdaten und - falls Anwendbar - die Expansionsenergie für die Drucktanks durch den Backend-Server 120 auf aus dem Stand der Technik bekannte Weise bestimmt werden.
  • Werden relevante Änderungen am Fahrzeug 110 - wie z.B. eine Umrüstung, eine Tankvergrößerung, eine Erweiterung der Batteriespeicher etc. - vorgenommen, können sich die Gefahrendaten ändern. Werden am Fahrzeug 110 Änderungen durchgeführt die zu einer Änderungen der Gefahrendaten führen, müssen die Gefahrendaten am Backend-Server 120 aktualisiert werden. Hierzu kann im Rahmen der Änderung ein „Trigger“ gesetzt werden, über den die Daten manuell, z.B. durch den Nutzer des Fahrzeugs 110, oder automatisch aktualisiert werden.
  • Der Backend-Server 120 ist zudem eingerichtet, Gefahrensituationsdaten zu erfassen. Die Gefahrensituationsdaten umfassen zumindest eine Position bzw. Positionsdaten (siehe oben, z.B. GPS-Positionsdaten) sowie eine Art einer Gefahrensituation. Eine Art einer Gefahrensituation ist beispielsweise ein Fahrzeugbrand, ein Hausbrand, ein (Gift)-Gasaustritt aus einer Industrieanlage, ein (terroristischer) Anschlag, eine Massenkarambolage, ein Tumult, ein Falschfahrer, eine fehlerhafte autonome Fahrzeugfunktion, ein Bombenfund, etc.
  • Beispielsweise können die Gefahrensituationsdaten von einem intelligenten Objekt 130A ... 130N empfangen werden. Intelligente Objekte 130A ... 130N sind in der Lage, mithilfe eines Kommunikationsmoduls 130A ... 130N (analog zum Kommunikationsmodul 112 im Fahrzeug 110, siehe oben) eine Kommunikationsverbindung mit dem Backend-Server 120 sowie weiteren Kommunikationsteilnehmern aufzubauen, um so Daten an den Backend-Server 120 zu übermitteln und/oder zu empfangen. Die intelligenten Objekte 130A ... 130N können zudem ein Positionsermittlungsmodul umfassen. Beispiele für intelligente Objekte sind vernetzte (Straßen-) Infrastruktursystem, die jeweils mit entsprechende Sensoren - analog zu Fahrzeugen - ihre Umgebung erfassen können und diese an den Backend-Server übermitteln können. Das intelligente Objekt 130A ... 130N kann beispielsweise ein System einer Notrufzentrale sein, welches bei Eintreten einer Gefahrensituation automatisch einen Datensatz umfassend die Gefahrensituationsdaten an den Backend-Server 120 übermittelt. In einem anderen Beispiel kann der Backend-Server 120 eingerichtet sein, Gefahrensituationsdaten in regelmäßigen zeitlichen Abständen von einem zentralen Gefahrendatenpool, z.B. einer zentralen Notrufleitstelle, abfragen bzw. abrufen (Polling). Beispielsweise können Gefahrensituationsdaten von einer intelligenten Ampel 130A ... 130N übertragen werden, die das Überfahren dieser bei Rot erkennt und automatisch an den Backend-Server 120 übermittelt. Darüber hinaus oder alternativ dazu können Gefahrensituationsdaten von einer intelligenten Autobahnauffahrt 130A ... 130N, die einen Falschfahrer erkennt, automatisch an den Backend-Server 120 übermittelt werden. Als entsprechende Gegenmaßnahme kann der Backend-Server 120 beispielsweise folgende Schutzaktionen auslösen bzw. initiieren:
    • - Verhinderung einer Trajektorie des Fahrzeugs, welches die intelligente Ampel 130A ... 130N bei Rot überfahren hat (z.B. durch Abbremsen des vorgenannten Fahrzeugs und/oder Ausweichen); und/oder
    • - Berücksichtigung, durch den Backend-Server 120, der Trajektorie des vorgenannten Fahrzeugs (Rotüberfahrts-Trajektorie) in der Fahrstrategie andere Verkehrsteilnehmer (sichere Reaktion auf Rotüberfahrtrajektorie).
  • Der Backend-Server 120 ist eingerichtet, die (relevanten) Gefahrendaten der Fahrzeuge 110 mit Bezug auf die Gefahrensituationsdaten auszuwerten. Der Backend-Server 120 kann eingerichtet sein, zunächst relevante Gefahrendaten zu identifizieren. Beispielsweise kann in der Speichereinheit 125 des Backend-Servers 120 zunächst zu jeder Gefahrensituation ein Bereich, ein Radius, etc. um die Position (z.B. GPS-Position) der Gefahrensituation hinterlegt, der durch die bzw. von der Gefahrensituation betroffen ist. In diesem Beispiel kann der Backend-Server 120 lediglich Gefahrendaten von Fahrzeugen 110 berücksichtigen, deren aktuelle bzw. letzte Position innerhalb dieses Bereichs bzw. Gebiets, Radius, etc. liegt.
  • Dazu können bekannte Techniken der Datenverarbeitung angewandt werden. Beispielsweise kann der Backend-Server 120 eine Datenanalyse zu den gespeicherten Daten mit Bezug auf die Gefahrensituationsdaten (z. B. maschinelle Lernanalyse, Datenmodellierung, Mustererkennung, Vorhersageanalyse, Korrelationsanalyse usw.) durchführen, um implizite Beziehungen oder Schlussfolgerungen für die gespeicherten Daten mit Bezug auf das Gefahrenpotential vorherzusagen, zu berechnen oder zu identifizieren. Dazu kommt eine Vielzahl von Datenlernalgorithmen und Klassifizierungstechniken wie z.B. die Partial-Least-Square-Regression (PLS-Regression), Random-Forest und/oder Hauptkomponentenanalyse (PCA) in Betracht.
  • Das Auswerten der Gefahrendaten kann zudem ein Auswerten von Umgebungsdaten mit Bezug auf die Position der Gefahrensituation umfassen. Die Umgebungsdaten können vor dem Erfassen einer Gefahrensituation periodisch am Backend-Server 120 empfangen werden.
  • Darüber hinaus oder alternativ dazu kann der Backend-Server 120 nach Erfassen der Gefahrensituation mit Bezug auf die Gefahrensituation abrufen.
  • Der Backend-Server 120 kann eingerichtet sein, Umgebungsdaten beispielsweise betreffend einen vordefinierten Bereich und/oder Radius um die Position der Gefahrensituation (z.B. digitale Straßenkarten) über ein geeignetes Netzwerk, z.B. das Internet, von entsprechenden Dienstanbietern bzw. Service Providern abzurufen.
  • Beispielsweise kann der Backend-Server eingerichtet sein, die Umgebungsdaten über so genanntes Crowd-Sourcing zu erfassen. Beim Crowd-Sourcing können über die Gefahrendaten hinaus verschiedenste Daten von den Fahrzeugen 110 sowie weiterer teilnehmender intelligenter Objekte 130A ... 130N an den Backend-Server 120 übermittelt und zentral verwaltet werden. Bei den zusätzlichen Daten der Fahrzeuge 110 kann es sich beispielsweise handeln um:
    • - Wetterdaten, die z.B. von ein oder mehreren Regen- und/oder Sonnen- und/oder Temperatursensoren 118 im Fahrzeug 110 erfasst werden;
    • - Aktuelle Umgebungsinformationen, die z.B. durch im oder am Fahrzeug 110 angebrachte Kameras 118 erfasst werden;
    • - Weitere aktuelle Umgebungsdaten, die z.B. durch Radar- und/oder Lidar- und/oder Sonarsensoren 118 des Fahrzeugs 110 angebracht werden.
  • Eine gefährliche Verkehrssituation kann sich auch durch einen erkannten unaufmerksamen Fahrer in Kombination mit einem aktiven Fahrerassistenzsystem ergeben. Wird beispielsweise ein unaufmerksamer Fahrer durch ein aktives Fahrerassistenzsystem erkannt, kann das betroffene Fahrzeug 110 in einen sicheren Zustand übergehen (z.B. Fahrzeug 110 bewegt sich mit aktivierter Warnblinkanlage an den Straßenrand). Ist die Rückfallebene der Fahrer, kann die Gefahrensituation durch Warnung anderer betroffener Verkehrsteilnehmer (z.B. durch den Backend-Server 120) bzw. bei autonom fahrenden Fahrzeugen 110 einen aktiven Eingriff in die Fahrzeugdynamik entschärft werden.
  • Die Fahrzeuge 110 können die Daten zu vordefinierten Ereignissen erfassen und an den Backend-Server 120 übermitteln. Dies kann beispielsweise in regelmäßigen zeitlichen Abständen, zu vordefinierten Zeitpunkten und/oder Ereignissen geschehen. Darüber hinaus oder alternativ dazu kann der Backend-Server 120 nach erfasster Gefahrensituation Fahrzeuge 110, die sich in einem vordefinierten Bereich, Radius, etc. um die Position der Gefahrensituation befinden, auffordern, ein oder mehrere der vorgenannten Daten über die entsprechenden, im Fahrzeug 110 befindlichen Sensoren 118 zu erfassen und an den Backend-Server 120 zu übermitteln. In diesem Beispiel kann bei der einmaligen Registrierung der Fahrzeuge 110 am Backend-Server 120 jeweils hinterlegt werden, welche Sensoren 118 am und/oder im Fahrzeug 110 verbaut sind.
  • Die intelligenten Objekte 130A ... 130N können z.B. mithilfe entsprechender Sensoren (nicht gezeigt) ebenfalls Umgebungsdaten (analog zum Fahrzeug 110, siehe oben) erfassen und an den Backend-Server 120 übermitteln bzw. von diesem abgerufen werden. Aus diesen Daten kann der Backend-Server 120 eine hochaktuelle digitale Umgebungskarte mit Bezug auf die Gefahrensituation generieren. Die digitale Umgebungskarte um die Gefahrensituation herum kann beispielsweise an Rettungskräfte bzw. Einsatzkräfte zur besseren Vorbereitung auf die Rettung bzw. den Einsatz übermittelt werden.
  • Darüber hinaus oder alternativ dazu kann der Backend-Server 120 eingerichtet sein, Umgebungsdaten beispielsweise von entsprechenden Service Providern abzurufen (vgl. Schritt 211 und/oder 225 in 2).
  • Insbesondere können Umgebungsdaten beispielsweise umfassen:
    • - eine Bevölkerungsdichte;
    • - eine Verkehrsdichte zum Zeitpunkt der Gefahrensituation;
    • - Hauptverkehrsstraßen in einem vordefinierten Radius um die Position der Gefahrensituation;
    • - aktuelle Wetterdaten;
    • - ein Umgebungsmodell eines Fahrzeugs umfassend einen vollautonomen Fahrmodus; und/oder
    • - sonstige Gefahrendaten umfassend die den vordefinierten Radius um die Position der Gefahrensituation.
  • Ergebnis des Auswertens der Gefahrendaten kann ein Gefahrenpotential sein. Das Gefahrenpotential kann die hochaktuelle digitale Karte umfassen.
  • Es folgt ein beispielhaftes Gefahrenpotential. In diesem Beispiel ist die Gefahrensituation ein Brand im Parkhaus. Das Auswerten dieses Brandes als Gefahrensituation in Kombination der gespeicherten Energiemenge, Energieart, chemischer Zusammensetzung, Bauform, Baugröße etc. von in der Nähe befindlicher Fahrzeuge (Umgebungsmodell) ermöglicht die Bewertung bzw. Ermittlung des Gefahrenpotentials. Auf Grundlage des bewerteten bzw. ermittelten Gefahrenpotentials können Maßnahmen getroffen werden unter Berücksichtigung des Umgebungsmodells, von Vorhersageanalysen und/oder Vorhersageszenarien. Im Regelfall können mehrere Maßnahmen ergriffen werden. Der Backend-Server 120 kann auf Grundlagen des Umgebungsmodells, das sich aus den Umgebungsdaten ergibt, unter Berücksichtigung von festgelegten bzw. festlegbaren Priorisierungen von Kriterien ein oder mehrere Maßnahmen ermitteln, die zum geringsten Schaden führen und/oder den wenigsten Verletzten führen. Der Backend-Server 120 kann in einem Beispiel die selbst ermittelten ein oder mehreren Maßnahmen initiieren. In einem anderen Beispiel kann der Backend-Server 120 mehrere alternative Maßnahmen mit einer Beurteilung des jeweils damit einhergehenden Schadensausmaßes aufzeigen. Eine (oder mehrere) mit der Entscheidung der durchzuführenden Maßnahmen betraute Person bestimmt dann, welche Maßnahme(n) durchgeführt werden.
  • Somit ist Backend-Server 120 eingerichtet, entsprechend den ausgewerteten Gefahrendaten zumindest eine Schutzmaßnahme einzuleiten.
  • Die Schutzmaßnahme kann ein Benachrichtigen von Rettungs- und/oder Einsatzkräften über ein Gefahrenpotential entsprechend den ausgewerteten Gefahrendaten umfassen.
  • Der Backend-Server 120 kann eingerichtet sein, ein Gefahrenpotential, welches Ergebnis des Auswertens der Gefahrendaten ist und die hochaktuelle digitale Karte umfassen kann, an Rettungs- und/oder Einsatzkräfte zu übermitteln. Vorteilhafter Weise können die Rettungs- und/oder Einsatzkräfte sich so optimal auf die Gefahrensituation vorbereiten, wodurch das Gefahrenpotential mit Bezug auf die Gefahrensituation reduziert wird.
  • Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme eine Einteilung eines vordefinierten Bereichs um die Position der Gefahrensituation in Gefahrenzonen entsprechend den ausgewerteten Gefahrendaten umfassen.
  • Der Backend-Server 120 kann eingerichtet sein, entsprechend den ausgewerteten Gefahrendaten einen vordefinierten Bereich um die Position der Gefahrensituation herum in Gefahrenzonen einzuteilen. Auch die Einteilung in Gefahrenzonen kann beispielsweise an Rettungs- und/oder Einsatzkräfte übermittelt werden. Vorteilhafter Weise können die Rettungs- und/oder Einsatzkräfte so ihre Aktionen den Gefahrenzonen anpassen, wodurch das Gefahrenpotential mit Bezug auf die Gefahrensituation reduziert wird.
  • Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme eine Empfehlung zur Räumung von Gebäuden und/oder Plätzen umfassen. Diese Empfehlung kann auch an Rettungs- und Einsatzkräfte übermittelt werden, so dass diese schneller eine Entscheidung treffen können, so dass die Gefahr potentiell verletzter Personen mit Bezug auf die Gefahrensituation verringert wird.
  • Der Backend-Server 120 kann eingerichtet sein, Rückmeldungen zu den durchgeführten bzw. eingeleiteten Maßnahmen zu empfangen (z.B. von Bergungs- und/oder Rettungskräften) und die Rückmeldungen zur Optimierung verwenden (z.B. unter Verwendung geeigneter Deep-Learning-Algorithmen) um Maßnahmen für künftige Gefahrensituationen kontinuierlich zu optimieren.
  • Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme eine Aktivierung zumindest einer Funktion einer Sicherheitseinrichtung umfassen. Sicherheitseinrichtungen können intelligente Objekte 130A ... 130N sein, z.B. intelligente Lüftungssysteme in Gebäuden, Fahrzeugen, etc.; intelligente Sprinklersysteme in Gebäuden, Fahrzeugen, intelligente Infrastruktursysteme, etc. Funktionen der Sicherheitseinrichtungen können ein Ein - oder Ausschalten der Lüftung, ein Ein- oder Ausschalten des Sprinklersystems, etc. sein. Die Aktivierung der zumindest einen Funktion einer Sicherheitseinrichtung erfolgt mit Bezug auf die ausgewerteten Gefahrendaten.
  • Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme eine Warnung anderer Verkehrsteilnehmer umfassen. Beispielsweise kann der Backend-Server 120 eingerichtet sein, eine entsprechende Nachricht an die Kommunikationseinheiten von Fahrzeugen anderer Verkehrsteilnehmer senden, die von der Gefahrensituation betroffen sind. Die Nachricht kann eine Warnung umfassen, welche über eine geeignete Ausgabeeinheit der jeweiligen Fahrzeuge ausgegeben werden kann.
  • Darüber hinaus oder alternativ dazu umfasst die Schutzmaßnahme einen aktiven Eingriff in die Fahrdynamik und/oder Trajektorienplanung anderer Verkehrsteilnehmer. Der Backend-Server 120 kann beispielsweise eine geeignete Nachricht an die Kommunikationseinheit von Fahrzeugen, die hochautomatisiertes Fahren (HAF) bzw. vollautomatisiertes Fahren (VAF) unterstützen, übermitteln. Die Nachricht kann entsprechende Daten umfassen, die geeignet sind, dass Fahrzeuge, die von der Gefahrensituation betroffen sind, aktiv in die Fahrdynamik und/oder Trajektorienplanung einzugreifen.
  • Beispielsweise kann eine Gefahrensituation ein brennendes Gebäude sein. Der Backend-Server 120 kann nach dem Auswerten der Gefahrendaten eine Nachricht an ein intelligentes Sprinklersystem im Gebäude senden, die Sprinkleranlage zu aktivieren. Darüber hinaus oder alternativ dazu kann der Backend-Server 120 ein Nachricht an intelligente Ampelanlagen in einem vordefinierten Bereich bzw. Gebiet um das brennende Gebäude herum übermitteln, so dass ihre die Signale derart einstellen, dass keine Fahrzeuge mehr in diesen Bereich einfahren, sondern lediglich aus dem Bereich ausfahren können.
  • Zumindest ein Fahrzeug 110 kann einen vollautonomen Fahrmodus aufweisen. In diesem Fall kann die Schutzmaßnahme darüber hinaus oder alternativ dazu ein Auffordern des Fahrzeugs 110 umfassend den vollautonomen Fahrmodus zum autonomen Verlassen eines vordefinierbaren bzw. vordefinierten Bereichs um die Position der Gefahrensituation umfassen.
  • Beispielsweise kann der Backend-Server 120 eingerichtet sein, eine entsprechende Nachricht an das Kommunikationsmodul 112 des Fahrzeugs 110 zu übermitteln. Die Nachricht kann eine Aufforderung zum Verlassen eines vordefinierten Bereichs sowie den vordefinierten Bereich einer digitalen Karte um die Position der Gefahrensituation hinweg umfassen. Alternativ dazu kann die Nachricht die Aufforderung zum Verlassen des vordefinierten Bereichs sowie eine Position auf der digitalen Karte umfassen, an die sich das Fahrzeug 110 hin bewegen soll. Die Position befindet sich außerhalb des vordefinierten bzw. vordefinierbaren Bereichs um die Position der Gefahrensituation. Eine Recheneinheit 114 kann die Nachricht verarbeiten und ein Steuermodul 115 kann das Fahrzeug 110 derart steuern, dass dieses autonom den vordefinierten Bereich verlässt. Das Fahrzeug 110 kann ein Navigationsmodul umfassen, in dem eine digitale Straßenkarte lokal im Fahrzeug 110 hinterlegt ist. Vorteilhafter Weise können sich so parkende Fahrzeuge umfassend einen autonomen Fahrmodus von der Gefahrensituation wegbewegen, wodurch sich das Gefahrenpotential weiter minimiert.
  • 2 zeigt ein Flussdiagramm, das ein Verfahren 200 zur Reduzierung des Gefahrenpotentials im Straßenverkehr wie weiter oben mit Bezug auf 1 beschrieben, veranschaulicht.
  • Das Verfahren 200 umfasst ein Empfangen 210, an einem Backend-Server 120, von Gefahrendaten der Fahrzeuge 110, wobei die Gefahrendaten aktuelle Füllzustandsdaten zumindest eines Energiespeichers sowie eine aktuellen Position des jeweiligen Fahrzeugs 110 umfassen.
  • Das Verfahren 200 kann zudem ein Empfangen 211, am Backend-Server 120, von Umgebungsdaten mit Bezug auf die Gefahrensituation umfassen. Die Umgebungsdaten können umfassen:
    • - eine Bevölkerungsdichte;
    • - eine Verkehrsdichte zum Zeitpunkt der Gefahrensituation;
    • - ein Gefahrenpotential von umliegenden Gebäuden, Arealen, Hallen, etc.;
    • - Hauptverkehrsstraßen in einem vordefinierbaren Bereich um die Position der Gefahrensituation;
    • - einen unaufmerksamen Fahrer;
    • - fehlerhafte Fahrerassistenzsysteme bei hochautomatisiertem Fahren (HAF) bzw. vollautomatisiertem Fahren (VAF);
    • - fehlerhafte Trajektorienplanung bei HAF bzw. VAF; und/oder
    • - sonstige Gefahrendaten umfassend die den vordefinierbaren Bereich um die Position der Gefahrensituation.
  • Das Empfangen 211 der Umgebungsdaten mit Bezug auf die Gefahrensituation kann beispielsweise periodisch erfolgen. Ein periodisches Empfangen 211 von Umgebungsdaten kann vorteilhafter Weise bei der Erfassung einer Gefahrensituation behilflich sein.
  • Zudem umfasst das Verfahren 200 ein Erfassen 220, am Backend-Server 120, von Gefahrensituationsdaten umfassend zumindest eine Position sowie eine Art einer Gefahrensituation. Wird eine Gefahrensituation erfasst 220, findet in einem nächsten Schritt ein Auswerten 230, durch den Backend-Server 120, der Gefahrendaten der Fahrzeuge 110, 110A ... 110N mit Bezug auf die Gefahrensituationsdaten statt. Das Auswerten 230 der Gefahrendaten kann zudem ein Auswerten der Umgebungsdaten mit Bezug auf die Position der Gefahrensituation umfassen. Die Umgebungsdaten können vor der Erfassung 220 der Gefahrensituation periodisch abgerufen bzw. empfangen werden (Schritt 211).
  • Darüber hinaus oder alternativ dazu können eventuell erweiterte, detailliertere, aktuellere etc. Umgebungsdaten mit Bezug auf die Gefahrensituation nach Erfassung 220 der Gefahrensituation 225 abgerufen werden (Schritt 225). Dies kann beispielsweise durch Polling von durch die Gefahrensituation betroffenen Fahrzeugen, intelligenten Objekten, etc. erfolgen.
  • Das Verfahren umfasst zudem ein automatisches Einleiten 240 zumindest einer Schutzmaßnahme entsprechend den ausgewerteten Gefahrendaten. Die Schutzmaßnahme kann ein Benachrichtigen von Rettungskräften über ein Gefahrenpotential entsprechend den Gefahrendaten der Fahrzeuge 110, deren aktuelle Position in einem vordefinierbaren Bereich um die Position der Gefahrensituation liegt, umfassen. Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme eine Einteilung eines vordefinierbaren Bereichs um die Position der Gefahrensituation in Gefahrenzonen entsprechend den ausgewerteten Gefahrendaten umfassen. Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme eine Empfehlung zur Räumung von Gebäuden und/oder Plätzen umfassen. Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme die Aktivierung von Sicherheitseinrichtungen umfassen. Darüber hinaus oder alternativ dazu kann die Schutzmaßnahme die Warnung anderer Verkehrsteilnehmer oder (z.B. bei hochautomatisiertem Fahren (HAF) bzw. vollautomatisiertem Fahren (VAF) ein aktiver Eingriff in die Fahrdynamik und/oder Trajektorienplanung anderer Verkehrsteilnehmer umfassen.
  • Zumindest ein Fahrzeug 110 kann einen vollautonomen Fahrmodus umfassen und sich in einem vordefinierbaren bzw. vordefinierten Bereich, Umkreis, etc. um die Position der Gefahrensituation befinden. In diesem Fall kann die Schutzmaßnahme darüber hinaus oder alternativ dazu ein Auffordern des Fahrzeugs 110, durch den Backend-Server 120, zum autonomen Verlassen eines vordefinierbaren Bereichs um die Position der Gefahrensituation oder zum Bewegen zu einer Position außerhalb des vordefinierten Bereichs umfassen.
  • 3 veranschaulicht ein beispielhaftes Szenario 300, in dem das Gefahrenpotential im Straßenverkehr durch das mit Bezug auf 1 und 2 erläuterte Verfahren reduziert wird.
  • Schematisch wird ein beispielhaftes erstes Fahrzeug 110_1 gezeigt. Das Fahrzeug 110_1 ist ein Fahrzeug 110 wie weiter oben mit Bezug auf 1 beschrieben. Bei dem beispielhaften Fahrzeug 110_1 handelt es sich insbesondere um ein zumindest teilweise elektrisch betriebenes Fahrzeug 110_1 und es weist einen entsprechenden Energiespeicher 116, beispielsweise einen Hochvolt-Batteriespeicher 116, auf.
  • Darüber hinaus wird schematisch ein zweites beispielhaftes Fahrzeug 110_2 gezeigt. Bei diesem Fahrzeug 110_2 handelt es sich um ein zumindest teilweise wasserstoffbetriebenes Fahrzeug 110_2 und es weist einen entsprechenden Energiespeicher 117, ein Druckbehältersystem 117, auf. Das Druckbehältersystem 117 dient zur Speicherung von unter Umgebungsbedingungen gasförmigen Brennstoff. Das Druckbehältersystem 117 kann beispielsweise in einem Kraftfahrzeug 110 eingesetzt werden, das mit Wasserstoff betrieben wird.
  • Ein solches Druckbehältersystem 117 umfasst mindestens einen Druckbehälter, insbesondere einem composite overwrapped pressure vessel (=COPV). Der Druckbehälter kann beispielsweise ein kryogener Druckbehälter (= CcH2 oder COP) oder ein Hochdruckgasbehälter (= CGH2) sein.
  • Hochdruckgasbehälter sind ausgebildet, bei Umgebungstemperaturen Brennstoff dauerhaft bei einem nominalen Betriebsdruck (auch nominal working pressure oder NWP genannt) von ca. 350 barü (= Überdruck gegenüber dem Atmosphärendruck), ferner bevorzugt von ca. 700 barü oder mehr zu speichern. Ein kryogener Druckbehälter ist geeignet, den Brennstoff bei den vorgenannten Betriebsdrücken auch bei Temperaturen zu speichern, die deutlich unter der Betriebstemperatur des Kraftfahrzeuges liegen.
  • In diesem Szenario fängt der Hochvoltbatteriespeicher 116 Feuer. Dadurch steigt die Umgebungstemperatur des zweiten Fahrzeugs 110_2 stark an. Die steigende Umgebungstemperatur führt zu einer Strukturschwächung des Hochdruckgasbehälters 117. Aufgrund des Feuers besteht die Gefahr eines Tankbrechens.
  • Beide Fahrzeuge 110_1 und 110_2 wurden von einem Nutzer am Backend-Server 110 registriert, wobei die Art des jeweiligen Energiespeichers 116, 117 hinterlegt wurde. Darüber hinaus senden die Fahrzeuge im Fahrzustand periodisch, ansonsten bei Ereignissen wie Motorstopp und Verlassen des jeweiligen Fahrzeugs 110_1 und 110_2 Gefahrendaten an den Backend-Server 120. Fahrzeug 110_1 erkennt, dass der Energiespeicher 116 Feuer gefangen hat und sendet Gefahrensituationsdaten umfassend die eigene Position sowie die Art der Gefahrensituation, d.h. Energiespeicher 116 brennt, an den Backend-Server 120. Der Backend-Server 120 wertet die Gefahrendaten von Fahrzeugen mit Bezug auf die Gefahrensituation aus. Dies umfasse ein auslesen, aus der Speichereinheit 125, eines Gefahrenradius für die Gefahrensituation „brennender Hochvoltbatteriespeicher“. Das Auswerten ergibt, dass sich Fahrzeug 120_2 umfassend den vollen Hochdruckgasbehälter 117 in einem akuten Gefahrenumkreis zu Fahrzeug 110_1 befindet. Der Backend-Server 120 leitet nun eine Schutzmaßnahme ein. Die Schutzmaßnahme kann ein Informieren einer zentralen Rettungsleitstelle über die Gefahrensituation sowie die Antriebsspeicher 116, 117 beider Fahrzeuge 110_1 und 110_2 umfassen. Vorteilhafter Weise haben die Rettungskräfte so die notwendige Information über die Antriebskonzepte des betroffenen Fahrzeugs 110_2. In diesem Beispiel weist Fahrzeug 120_2 einen vollautonomen Fahrmodus auf. Das Einleiten 240 der Schutzmaßnahme umfasst in diesem Fall das Auffordern des Fahrzeugs 110_2 zum Verlassen des Gefahrenradius 310 (hier durch einen gestrichelten Teil des Gefahrenradius 310 dargestellt) für die Gefahrensituation „brennender Hochvoltbatteriespeicher“ von Fahrzeug 110_1 ausgehend. Vorteilhafter Weise wird dadurch die Gefahr des Tankbrechens vermieden.

Claims (10)

  1. Verfahren (200) zur Reduzierung des Gefahrenpotentials einer Vielzahl von Fahrzeugen (110) mit heterogenen Antrieben, umfassend: Empfangen (210), an einem Backend-Server (120), von Gefahrendaten der Fahrzeuge (110 A ... 110N), wobei die Gefahrendaten aktuelle Füllzustandsdaten zumindest eines Energiespeichers sowie eine aktuellen Position des jeweiligen Fahrzeugs umfasst (110 A ... 110N); Erfassen (220), am Backend-Server (120), von Gefahrensituationsdaten umfassend zumindest eine Position sowie eine Art einer Gefahrensituation; Auswerten (230), durch den Backend-Server (120), der Gefahrendaten der Fahrzeuge (110, 110A ... 110N) mit Bezug auf die Gefahrensituationsdaten; und Einleiten (240) zumindest einer Schutzmaßnahme entsprechend den ausgewerteten Gefahrendaten.
  2. Verfahren (200) gemäß Anspruch 1, wobei das Auswerten (230) der Gefahrendaten zudem ein Auswerten von Umgebungsdaten mit Bezug auf die Position der Gefahrensituation umfasst.
  3. Verfahren (200) gemäß Anspruch 2, wobei die Umgebungsdaten umfassen: - eine Bevölkerungsdichte; - eine Verkehrsdichte zum Zeitpunkt der Gefahrensituation; - ein Gefahrenpotential von umliegenden Gebäuden, Arealen, Hallen, etc.; - Hauptverkehrsstraßen in einem vordefinierbaren Bereich um die Position der Gefahrensituation; - einen unaufmerksamen Fahrer; - fehlerhafte Fahrerassistenzsysteme bei hochautomatisiertem Fahren, HAF, bzw. vollautomatisiertem Fahren, VAF; - fehlerhafte Trajektorienplanung bei HAF bzw. VAF; und/oder - sonstige Gefahrendaten umfassend die den vordefinierbaren Bereich um die Position der Gefahrensituation.
  4. Verfahren (200) gemäß einem der vorangehenden Ansprüche, wobei die Schutzmaßnahme ein Benachrichtigen von Rettungskräften über ein Gefahrenpotential entsprechend den ausgewerteten Gefahrendaten umfasst.
  5. Verfahren (200) gemäß einem der vorangehenden Ansprüche, wobei die Schutzmaßnahme eine Einteilung eines vordefinierbaren Bereichs um die Position der Gefahrensituation in Gefahrenzonen entsprechend den ausgewerteten Gefahrendaten umfasst.
  6. Verfahren (200) gemäß einem der vorangehenden Ansprüche, wobei die Schutzmaßnahme eine Empfehlung zur Räumung von Gebäuden und/oder Plätzen umfasst.
  7. Verfahren (200) gemäß einem der vorangehenden Ansprüche, wobei die Schutzmaßnahme die Aktivierung zumindest einer Funktion einer Sicherheitseinrichtung umfasst.
  8. Verfahren (200) gemäß einem der vorangehenden Ansprüche, wobei zumindest ein Fahrzeug (110) einen vollautonomen Fahrmodus umfasst; wobei die Schutzmaßnahme ein Auffordern des Fahrzeugs (110) umfassend den vollautonomen Fahrmodus zum autonomen Verlassen eines vordefinierbaren Bereichs um die Position der Gefahrensituation umfasst.
  9. Verfahren (200) gemäß einem der vorangehenden Ansprüche, wobei die Schutzmaßnahme eine Warnung anderer Verkehrsteilnehmer umfasst.
  10. Verfahren (200) gemäß einem der vorangehenden Ansprüche, wobei die Schutzmaßnahme einen aktiven Eingriff in die Fahrdynamik oder Trajektorienplanung anderer Verkehrsteilnehmer umfasst.
DE102017219302.6A 2017-10-27 2017-10-27 Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr Pending DE102017219302A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE102017219302.6A DE102017219302A1 (de) 2017-10-27 2017-10-27 Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr
PCT/EP2018/072480 WO2019081090A1 (de) 2017-10-27 2018-08-21 Verfahren zur reduzierung des gefahrenpotentials im strassenverkehr
US16/650,249 US11661079B2 (en) 2017-10-27 2018-08-21 Method for reducing the potential hazard in road traffic
CN201880062511.2A CN111133486B (zh) 2017-10-27 2018-08-21 用于减少道路交通中的潜在危险的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102017219302.6A DE102017219302A1 (de) 2017-10-27 2017-10-27 Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr

Publications (1)

Publication Number Publication Date
DE102017219302A1 true DE102017219302A1 (de) 2019-05-02

Family

ID=63350538

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017219302.6A Pending DE102017219302A1 (de) 2017-10-27 2017-10-27 Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr

Country Status (4)

Country Link
US (1) US11661079B2 (de)
CN (1) CN111133486B (de)
DE (1) DE102017219302A1 (de)
WO (1) WO2019081090A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020200133A1 (de) * 2020-01-08 2021-07-08 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben eines automatisierten Fahrzeugs
DE102021201130A1 (de) 2021-02-08 2022-08-11 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum infrastrukturgestützten Assistieren mehrerer Kraftfahrzeuge
DE102022121322A1 (de) 2022-08-23 2024-02-29 Bayerische Motoren Werke Aktiengesellschaft Vorrichtung und Verfahren zur Erhöhung der Verkehrssicherheit

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11585672B1 (en) * 2018-04-11 2023-02-21 Palantir Technologies Inc. Three-dimensional representations of routes
DE102019200345A1 (de) * 2019-01-14 2020-07-16 Continental Automotive Gmbh Cloudbasierte Erkennung und Warnung von Gefahrenstellen
DE102019214484A1 (de) * 2019-09-23 2021-03-25 Robert Bosch Gmbh Verfahren zum sicheren Ermitteln von Infrastrukturdaten
EP3809390B1 (de) * 2019-10-16 2023-08-16 Zenuity AB Verfahren, system und fahrzeug zur steuerung eines fahrzeugsystems
DE102019128865A1 (de) * 2019-10-25 2021-04-29 Fogtec Brandschutz Gmbh Parkrauminformationssystem

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006057741A1 (de) * 2006-12-07 2007-09-06 Siemens Restraint Systems Gmbh System und Verfahren zum Bereitstellen von sicherheitsrelevanten Informationen
DE102011119544B3 (de) * 2011-11-26 2013-05-16 Volkswagen Aktiengesellschaft Verfahren zum Warnen eines Fahrers vor einer Gefahrenstelle
DE102012208000A1 (de) * 2012-05-14 2013-11-14 Robert Bosch Gmbh Verfahren und Vorrichtung zum Erkennen eines Brandes oder eines unmittelbar bevorstehenden Brandes eines Kraftfahrzeugs
DE102013220430A1 (de) * 2013-10-10 2015-04-16 Continental Teves Ag & Co. Ohg Verfahren und System zur Identifizierung einer Gefahrensituation sowie Verwendung des Systems

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3843043A1 (de) * 1988-12-21 1990-06-28 Messerschmitt Boelkow Blohm Leitverfahren und einrichtung fuer den katastrophen- und umweltschutz
JP2008522328A (ja) 2004-12-02 2008-06-26 フォード モーター カンパニー 水素自動車を監視するためのコンピュータ・システム及び方法
EP2271522B1 (de) 2008-04-14 2018-11-07 Continental Teves AG & Co. OHG Ortungssignal für einsatzkräfte
US9070243B1 (en) * 2009-08-19 2015-06-30 Allstate Insurance Company Assistance on the go
EP2471051B1 (de) * 2009-08-26 2018-03-28 Continental Automotive GmbH Systeme und verfahren zur notfallsaktivierung eines netzzugangsgeräts
WO2011110227A1 (en) * 2010-03-12 2011-09-15 Telefonaktiebolaget Lm Ericsson (Publ) Cellular network based assistant for vehicles
EP2442291B1 (de) * 2010-10-13 2013-04-24 Harman Becker Automotive Systems GmbH Verkehrsereignisüberwachung
US8749350B2 (en) * 2010-12-10 2014-06-10 General Motors Llc Method of processing vehicle crash data
US9549061B2 (en) * 2012-06-14 2017-01-17 General Motors Llc Call center based zoned microphone control in a vehicle
DE102012014457A1 (de) * 2012-07-21 2014-01-23 Audi Ag Verfahren zum Betreiben eines Kraftfahrzeugs und Kraftfahrzeug
DE102012215064A1 (de) * 2012-08-24 2014-02-27 Robert Bosch Gmbh Verfahren und Vorrichtung zum Ermitteln einer Gefahrenquelle einer Fahrstrecke
US9363646B2 (en) * 2013-01-24 2016-06-07 General Motors Llc Receiving a service in a vehicle based on location data of a mobile device within the vehicle
US20140302774A1 (en) 2013-04-04 2014-10-09 General Motors Llc Methods systems and apparatus for sharing information among a group of vehicles
WO2015008290A2 (en) * 2013-07-18 2015-01-22 Secure4Drive Communication Ltd. Method and device for assisting in safe driving of a vehicle
US10692370B2 (en) * 2014-03-03 2020-06-23 Inrix, Inc. Traffic obstruction detection
CN104077819B (zh) * 2014-06-17 2015-03-18 深圳前向启创数码技术有限公司 基于行车安全的远程监控方法及系统
DE102014214594A1 (de) * 2014-07-24 2016-01-28 Robert Bosch Gmbh Verfahren zum Betreiben eines Assistenzsystems eines Fahrzeugs mit mindestens einem elektrischen Energiespeicher
WO2016049812A1 (en) * 2014-09-29 2016-04-07 Bayerische Motoren Werke Aktiengesellschaft Automatic parking warning system
DE102015206211A1 (de) * 2015-04-08 2016-10-13 Bayerische Motoren Werke Aktiengesellschaft Warneinheit in einem Fahrzeug zum Warnen des Fahrers bei einer drohenden Gefahr
DE102015208053A1 (de) 2015-04-30 2016-11-03 Robert Bosch Gmbh Verfahren und Vorrichtung zum Verringern einer Gefährdung für ein und/oder durch ein sich auf einem Parkplatz befindendes Fahrzeug
US9759574B2 (en) * 2015-07-14 2017-09-12 Ford Global Technologes, Llc Vehicle emergency broadcast and relay
DE112016004574B4 (de) * 2015-10-06 2020-04-23 Patricia Morgan Fahrzeugverfolgungswarnsystem
US9513134B1 (en) 2015-12-16 2016-12-06 International Business Machines Corporation Management of evacuation with mobile objects
CN107082071A (zh) 2016-02-15 2017-08-22 宝马股份公司 用于防止意外离开行车道的方法和辅助装置
CN106128140B (zh) * 2016-08-11 2017-12-05 江苏大学 车联网环境下行车服务主动感知系统及方法
US9905133B1 (en) * 2016-09-30 2018-02-27 Allstate Insurance Company Controlling autonomous vehicles to provide automated emergency response functions
CN106292461B (zh) * 2016-10-09 2019-02-15 江苏蓝鑫电子科技有限公司 一种冷链运输安全远程监管系统
CN106828501A (zh) * 2017-01-06 2017-06-13 汽-大众汽车有限公司 一种车辆辅助驾驶方法、装置及车辆
US10288439B2 (en) * 2017-02-22 2019-05-14 Robert D. Pedersen Systems and methods using artificial intelligence for routing electric vehicles

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006057741A1 (de) * 2006-12-07 2007-09-06 Siemens Restraint Systems Gmbh System und Verfahren zum Bereitstellen von sicherheitsrelevanten Informationen
DE102011119544B3 (de) * 2011-11-26 2013-05-16 Volkswagen Aktiengesellschaft Verfahren zum Warnen eines Fahrers vor einer Gefahrenstelle
DE102012208000A1 (de) * 2012-05-14 2013-11-14 Robert Bosch Gmbh Verfahren und Vorrichtung zum Erkennen eines Brandes oder eines unmittelbar bevorstehenden Brandes eines Kraftfahrzeugs
DE102013220430A1 (de) * 2013-10-10 2015-04-16 Continental Teves Ag & Co. Ohg Verfahren und System zur Identifizierung einer Gefahrensituation sowie Verwendung des Systems

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020200133A1 (de) * 2020-01-08 2021-07-08 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Betreiben eines automatisierten Fahrzeugs
US11919544B2 (en) 2020-01-08 2024-03-05 Robert Bosch Gmbh Method and device for operating an automated vehicle
DE102021201130A1 (de) 2021-02-08 2022-08-11 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum infrastrukturgestützten Assistieren mehrerer Kraftfahrzeuge
DE102022121322A1 (de) 2022-08-23 2024-02-29 Bayerische Motoren Werke Aktiengesellschaft Vorrichtung und Verfahren zur Erhöhung der Verkehrssicherheit

Also Published As

Publication number Publication date
CN111133486B (zh) 2022-08-12
US11661079B2 (en) 2023-05-30
WO2019081090A1 (de) 2019-05-02
US20200269872A1 (en) 2020-08-27
CN111133486A (zh) 2020-05-08

Similar Documents

Publication Publication Date Title
DE102017219302A1 (de) Verfahren zur Reduzierung des Gefahrenpotentials im Straßenverkehr
DE102013107959B4 (de) Verfahren zur Unterstützung des Parkens von Fahrzeugen auf einer Parkfläche, Parkflächenmanagementsystem, fahrzeugseitiges System und Computerprogramm dafür
DE102020106951A1 (de) Vollständige ladestation für elektrische fahrzeuge und verfahren zum betrieb desselben
DE112017007797T5 (de) Fahrzeugsicherheitssysteme und -verfahren
DE102018107755A1 (de) Fahrzeugereigniserkennung und -klassifizierung mithilfe von kontextbezogenen fahrzeugdaten
DE102017217444B4 (de) Verfahren und System zum Aktualisieren eines Steuerungsmodells für eine automatische Steuerung zumindest einer mobilen Einheit
DE102012224149A1 (de) System zur Parkzeitverwaltung
DE102012223152A1 (de) System zur Übermittlung von Sendungen
DE102020122757A1 (de) Systeme und verfahren für mitfahrgelegenheiten unter verwendung von blockchain
DE102012223304A1 (de) System zum selektiven Öffnen eines Fahrzeuges
DE102017219301A1 (de) Verfahren zur Erhöhung der Sicherheit bei Gefahrensituationen betreffend den Straßenverkehr
DE102010037467A1 (de) Motorfahrzeug
DE112017007173T5 (de) Kraftstoffabgabe an ein fahrzeug
DE102014008429A1 (de) Verfahren und Vorrichtung zur Ermittlung freier Abstellplätze auf LKW-Parkplätzen und Mitteilung an LKW-Fahrer
WO2018036824A1 (de) System und verfahren zum abrufbaren bereitstellen und aktualisieren von klassifikationsdaten zu parkplätzen
DE112015004135T5 (de) Fahrzeugsteuerungsvorrichtung
WO2020207716A1 (de) Technik zum abgleich von fahrten von kraftfahrzeugen
DE102020104555A1 (de) Planung und ausführung einer bordeigenen diagnostischen überwachung
WO2019233766A1 (de) Kraftfahrzeug und verfahren eines kraftfahrzeugs zum durchführen eines autonomen umparkvorgangs
DE112017007144T5 (de) Kraftstofflieferung an ein fahrzeug
DE102022003359A1 (de) Fahrzeugseitige Frühwarnvorrichtung, Frühwarnsystem, Frühwarnverfahren, Programmprodukt und Fahrzeug
DE102017219292A1 (de) Verfahren und vorrichtung zum erfassen von ereignisbezogenen daten bezüglich eines fahrzeugs
DE102020102191A1 (de) Fortbewegungsmittel, Vorrichtung und Verfahren zum automatischen Ausgeben eines Notsignals in Abhängigkeit einer Umgebungsgefährdung durch ein abgestelltes Fortbewegungsmittel
WO2010070398A1 (de) Elektronische vorrichtung, kfz oder fahrrad, welches die elektronische vorrichtung verwendet, verkehrsleitsystem oder verkehrsüberwachungssystem und verfahren zum ändern einer verkehrsteilnehmerentität
DE102018218845A1 (de) Kraftfahrzeug

Legal Events

Date Code Title Description
R083 Amendment of/additions to inventor(s)
R163 Identified publications notified