[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

DE102018217014A1 - Dynamische Qualifizierung von Nutzdaten - Google Patents

Dynamische Qualifizierung von Nutzdaten Download PDF

Info

Publication number
DE102018217014A1
DE102018217014A1 DE102018217014.2A DE102018217014A DE102018217014A1 DE 102018217014 A1 DE102018217014 A1 DE 102018217014A1 DE 102018217014 A DE102018217014 A DE 102018217014A DE 102018217014 A1 DE102018217014 A1 DE 102018217014A1
Authority
DE
Germany
Prior art keywords
data
date
input data
qualitative
lem
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
DE102018217014.2A
Other languages
English (en)
Inventor
Roland Seeberger
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.)
Elektrobit Automotive GmbH
Original Assignee
Elektrobit Automotive GmbH
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 Elektrobit Automotive GmbH filed Critical Elektrobit Automotive GmbH
Priority to DE102018217014.2A priority Critical patent/DE102018217014A1/de
Publication of DE102018217014A1 publication Critical patent/DE102018217014A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808Diagnosing performance data
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/28Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network with correlation of data from several navigational instruments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3058Monitoring arrangements for monitoring environmental properties or parameters of the computing system or of the computing system component, e.g. monitoring of power, currents, temperature, humidity, position, vibrations
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3089Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT 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
    • B60W2556/00Input parameters relating to data
    • B60W2556/15Data age
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT 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
    • B60W2556/00Input parameters relating to data
    • B60W2556/20Data confidence level
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT 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
    • B60W2556/00Input parameters relating to data
    • B60W2556/25Data precision
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT 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/00Drive control systems specially adapted for autonomous road vehicles
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/008Registering or indicating the working of vehicles communicating information to a remotely located station

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Mathematical Physics (AREA)
  • Traffic Control Systems (AREA)

Abstract

Die Erfindung betrifft ein Verfahren, ein Computerprogramm mit Instruktionen und eine Vorrichtung zum Qualifizieren eines Nutzdatums. In einem ersten Schritt (10) werden Eingangsdaten von zwei oder mehr Quellen empfangen. Des Weiteren werden qualitative Metriken für die Eingangsdaten empfangen (11). Aus den Eingangsdaten wird ein Nutzdatum ermittelt (12) . Zusätzlich wird aus den qualitativen Metriken der Eingangsdaten zumindest eine qualitative Metrik für das Nutzdatum ermittelt (13). Die Erfindung ermöglicht eine kontinuierliche dynamische Qualifizierung von Daten aus unterschiedlichen Quellen, die eine sich fortlaufend ändernde Vertrauenswürdigkeit aufweisen.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren, ein Computerprogramm mit Instruktionen und eine Vorrichtung zum Qualifizieren eines Nutzdatums. Insbesondere betrifft die vorliegende Erfindung die Qualifizierung von Nutzdaten zur Verwendung durch hochautomatisierte Fahrfunktionen.
  • Für automatisierte und insbesondere hochautomatisierte Fahrfunktionen in Fahrzeugen werden unter anderem exakte absolute Fahrzeugpositionen benötigt, die hohen Ansprüchen in Bezug auf funktionale Sicherheit (ASIL: Automotive safety integrity level) sowie in Bezug auf SOTIF (SOTIF: Safety of the intended functionality; Sicherheit der Sollfunktion) genügen müssen. Die funktionale Sicherheit soll dabei beispielsweise ASIL-B genügen. Im Rahmen von SOTIF wird betrachtet, ob eine sicherheitsrelevante Funktion gut genug spezifiziert ist, um den möglichen Szenarien der realen Welt zu genügen. Die Bedeutung sowie die Anforderungen nach ASIL und SOTIF sind dem Fachmann bekannt. Im Rahmen der funktionalen Sicherheit wird betrachtet, ob eine sicherheitsrelevante Funktion wie vorgesehen arbeitet und rückwirkungsfrei ist. Zudem wird betrachtet, ob ein Nutzer auf das korrekte Funktionieren eines Software-Tools bzw. einer Software-Toolkette vertrauen kann. Im Rahmen der Sicherheit der vorgesehenen Funktion wird hingegen betrachtet, ob eine sicherheitsrelevante Funktion als „ausreichend gut“ für tatsächliche Anwendungsfälle spezifiziert und validiert ist.
  • Gemäß einem gegenwärtigen Ansatz erfolgt die Positionsberechnung durch Erfassung von Daten eines lokalen Umfeldmodells, nachfolgend als „LEM-Daten“ bezeichnet (LEM: Local environmental model; lokales Umfeldmodell), und deren Abgleich mit Daten eines globalen Umfeldmodells, nachfolgend als „GEM-Daten“ bezeichnet (GEM: Global environmental model; globales Umfeldmodell). Die LEM-Daten basieren hierbei auf lokalen Sensordaten mit wechselnder Verfügbarkeit und unterschiedlicher Vertrauenswürdigkeit, abhängig von den verwendeten Sensoren. Die GEM-Daten basieren hingegen auf Daten, die von einem Cloud-Service, dem „GEM-Backend“, bereitgestellt werden. Diese werden ihrerseits aus einer Vielzahl von LEM-Daten teilnehmender Fahrzeuge berechnet.
  • Erforderlich für einen solchen Ansatz ist ein Sicherheitskonzept, das eine Möglichkeit zur Qualifizierung der beteiligten LEM-Daten und GEM-Daten vorsieht.
  • Es ist eine Aufgabe der vorliegenden Erfindung, ein Konzept für eine kontinuierliche dynamische Qualifizierung von Daten aus unterschiedlichen Quellen bereitzustellen, die eine sich fortlaufend ändernde Vertrauenswürdigkeit aufweisen.
  • Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 1, durch ein Computerprogramm mit Instruktionen mit den Merkmalen des Anspruchs 9 und durch eine Vorrichtung mit den Merkmalen des Anspruchs 10 gelöst. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
  • Gemäß einem ersten Aspekt der Erfindung umfasst ein Verfahren zum Qualifizieren eines Nutzdatums die Schritte:
    • - Empfangen von Eingangsdaten von zwei oder mehr Quellen;
    • - Empfangen von qualitativen Metriken für die Eingangsdaten;
    • - Ermitteln eines Nutzdatums aus den Eingangsdaten; und
    • - Ermitteln zumindest einer qualitativen Metrik für das Nutzdatum aus den qualitativen Metriken der Eingangsdaten.
  • Gemäß einem weiteren Aspekt der Erfindung umfasst ein Computerprogramm Instruktionen, die bei Ausführung durch einen Computer den Computer zur Ausführung der folgenden Schritte zum Qualifizieren eines Nutzdatums veranlassen:
    • - Empfangen von Eingangsdaten von zwei oder mehr Quellen;
    • - Empfangen von qualitativen Metriken für die Eingangsdaten;
    • - Ermitteln eines Nutzdatums aus den Eingangsdaten; und
    • - Ermitteln zumindest einer qualitativen Metrik für das Nutzdatum aus den qualitativen Metriken der Eingangsdaten.
  • Der Begriff Computer ist dabei breit zu verstehen. Insbesondere umfasst er auch Workstations, Steuergeräte und andere prozessorbasierte Datenverarbeitungsvorrichtungen.
  • Das Computerprogramm kann beispielsweise für einen elektronischen Abruf bereitgestellt werden oder auf einem computerlesbaren Speichermedium gespeichert sein.
  • Gemäß einem weiteren Aspekt der Erfindung hat eine Vorrichtung zum Qualifizieren eines Nutzdatums:
    • - einen Eingang zum Empfangen von Eingangsdaten von zwei oder mehr Quellen und zum Empfangen von qualitativen Metriken für die Eingangsdaten; und
    • - eine Recheneinheit zum Ermitteln eines Nutzdatums aus den Eingangsdaten und zum Ermitteln zumindest einer qualitativen Metrik für das Nutzdatum aus den qualitativen Metriken der Eingangsdaten.
  • Die erfindungsgemäße Lösung beruht auf dem Ansatz, Metadaten zu verwenden, die zusätzlich zu den Eingangsdaten bzw. Nutzdaten zwischen den beteiligten Komponenten weitergereicht werden. Die Metadaten beinhalten zumindest jeweils eine qualitative Metrik. Sie daher stellen ein Maß für die Qualität der Ausgangsdaten dar, die eine Komponente liefert. Die Metadaten werden unter Einbeziehung der Metadaten aller an der Berechnung der Nutzdaten beteiligten Eingangswerte berechnet. Zusätzlich können Metadaten zu weiteren technischen Aspekten übermittelt werden, wie Präzision, Zeitstempel und Verfügbarkeit. Die erfindungsgemäße Lösung erlaubt eine kontinuierliche dynamische Qualifizierung von Daten aus unterschiedlichen Quellen mit ständig veränderlicher Vertrauenswürdigkeit. Die dynamische Qualifizierung der Daten ermöglicht es, flexibel mit qualitativ schlechten Eingangsdaten sowie mit qualitativ schlechten oder ausgefallenen Komponenten umzugehen.
  • Gemäß einem Aspekt der Erfindung umfassen die qualitativen Metriken einen Integritätswert oder einen Konfidenzwert. Vorzugsweise ist der Integritätswert ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf eine funktionale Sicherheit, während der Konfidenzwert ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf eine Nominalleistung ist. Anhand der genannten Metriken wird dem Abnehmer der Daten auf einfache und nachvollziehbare Weise eine Bewertung insbesondere der aus den Eingangsdaten abgeleiteten Nutzdaten ermöglicht, die z.B. den Anforderungen nach ASIL und SOTIF genügt.
  • Gemäß einem Aspekt der Erfindung werden auf Basis zumindest einer der qualitativen Metriken verfügbare Redundanzen für eine Datenerfassung aktiviert. Auf diese Weise ist es möglich, dynamisch durch Ausnutzung der bei der Sensorik verfügbaren Redundanzen die Qualität der Eingangsdaten auf ein gewünschtes Niveau zu steigern oder bei einem Ausfall einer Komponente zu kompensieren.
  • Gemäß einem Aspekt der Erfindung resultiert der Integritätswert des Nutzdatums aus dem niedrigsten Integritätswert der verwendeten Eingangsdaten. Entsprechend resultiert der Konfidenzwert des Nutzdatums aus dem niedrigsten Konfidenzwert der verwendeten Eingangsdaten. Auf diese Weise wird sichergestellt, dass ein Nutzdatum maximal so gut eingestuft wird, wie das am niedrigsten eingestufte Element, das zum Nutzdatum beiträgt.
  • Alternativ wird durch Dekomposition eine Erhöhung des Integritätswertes des Nutzdatums erreicht. Bei Aktivierung von diversitärer Redundanz, d.h. von gleichartigen Eingangsdaten aus verschiedenen Quellen, die voneinander hinreichend unabhängig sind und unterschiedlich implementiert wurden, kann durch Anwendung einer Dekomposition eine Erhöhung des Integritätswertes am Ausgang erreicht werden. Im Rahmen der Dekomposition werden korrelierende Eingangsdaten der verschiedenen Quellen identifiziert, miteinander verglichen und nur dann verwendet, wenn sie hinreichend gleich sind.
  • Gemäß einem Aspekt der Erfindung sind die Eingangsdaten Sensordaten, Daten eines Umfeldmodells oder Positionsdaten. Das Nutzdatum ist dabei ein Datum eines Umfeldmodells oder eine Position. Umfeldmodelle sind hilfreich für die Positionsbestimmung, z.B. für die Bestimmung einer absoluten Position eines Fahrzeugs. Die Qualität der Position ist hochgradig relevant für autonome oder hochautomatisierte Fahrfunktionen. Es ist daher vorteilhaft, wenn eine zuverlässige Qualifizierung derartiger Daten erfolgt.
  • Gemäß einem Aspekt der Erfindung wird anhand der zumindest einen qualitativen Metrik des Nutzdatums von einem Abnehmer des Nutzdatums geprüft, ob das Nutzdatum für eine vorgesehene Nutzung verwendet werden kann. Da die qualitative Metrik eine verlässliche Aussage über eine Einstufung des Nutzdatums trifft, kann anhand der qualitativen Metrik sehr einfach geprüft werden, ob das Nutzdatum die Mindestanforderungen für eine bestimmte Nutzung erfüllt.
  • Gemäß einem Aspekt der Erfindung ist die vorgesehene Nutzung eine autonome Fahrfunktion eines Fahrzeuges. Für derartige Fahrfunktionen sind Daten erforderlich, die hohen Ansprüchen in Bezug auf die funktionale Sicherheit und die Sicherheit der vorgesehenen Funktion genügen. Das vorliegend beschriebene Konzept ist daher besonders gut für diese Anwendung geeignet.
  • Weitere Merkmale der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung und den angehängten Ansprüchen in Verbindung mit den Figuren ersichtlich.
  • Figurenliste
    • 1 zeigt schematisch ein Verfahren zum Qualifizieren eines Nutzdatums;
    • 2 zeigt eine erste Ausführungsform einer Vorrichtung zum Qualifizieren eines Nutzdatums;
    • 3 zeigt eine zweite Ausführungsform einer Vorrichtung zum Qualifizieren eines Nutzdatums;
    • 4 zeigt schematisch eine Systemtopologie eines Sicherheitskonzeptes für eine Positionsberechnung;
    • 5 zeigt schematisch das Prinzip der absoluten Positionsberechnung;
    • 6 illustriert Abhängigkeiten eines Integritätswertes; und
    • 7 illustriert Abhängigkeiten eines Konfidenzwertes.
  • Figurenbeschreibung
  • Zum besseren Verständnis der Prinzipien der vorliegenden Erfindung werden nachfolgend Ausführungsformen der Erfindung anhand der Figuren detaillierter erläutert. Gleiche Bezugszeichen werden in den Figuren für gleiche oder gleichwirkende Elemente verwendet und nicht notwendigerweise zu jeder Figur erneut beschrieben. Es versteht sich, dass sich die Erfindung nicht auf die dargestellten Ausführungsformen beschränkt und dass die beschriebenen Merkmale auch kombiniert oder modifiziert werden können, ohne den Schutzbereich der Erfindung zu verlassen, wie er in den angehängten Ansprüchen definiert ist.
  • 1 zeigt schematisch ein Verfahren zum Qualifizieren eines Nutzdatums. In einem ersten Schritt 10 werden Eingangsdaten von zwei oder mehr Quellen empfangen. Des Weiteren werden qualitative Metriken für die Eingangsdaten empfangen 11. Die qualitativen Metriken können beispielsweise einen Integritätswert oder einen Konfidenzwert umfassen. Dabei kann der Integritätswert ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf eine funktionale Sicherheit sein. Der Konfidenzwert kann ein Maß für die Vertrauenswürdigkeit des Datums in Bezug auf eine Nominalleistung sein. Aus den Eingangsdaten wird ein Nutzdatum ermittelt 12. Zusätzlich wird aus den qualitativen Metriken der Eingangsdaten zumindest eine qualitative Metrik für das Nutzdatum ermittelt 13. Auf Basis zumindest einer der qualitativen Metriken können z.B. verfügbare Redundanzen für eine Datenerfassung aktiviert werden. Ebenso kann anhand der zumindest einen qualitativen Metrik des Nutzdatums geprüft werden, ob das Nutzdatum für eine vorgesehene Nutzung verwendet werden kann.
  • 2 zeigt eine vereinfachte schematische Darstellung einer ersten Ausführungsform einer Vorrichtung 20 zum Qualifizieren eines Nutzdatums. Die Vorrichtung 20 hat einen Eingang 21, über den Eingangsdaten von zwei oder mehr Quellen und qualitative Metriken für die Eingangsdaten empfangen werden können. Die qualitativen Metriken können dabei z.B. einen Integritätswert oder einen Konfidenzwert umfassen. Beispielsweise kann der Integritätswert ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf eine funktionale Sicherheit sein. Der Konfidenzwert kann ein Maß für die Vertrauenswürdigkeit des Datums in Bezug auf eine Nominalleistung sein. Eine Recheneinheit 22 ermittelt ein Nutzdatum aus den Eingangsdaten. Zudem ermittelt die Recheneinheit 22 zumindest eine qualitative Metrik für das Nutzdatum aus den qualitativen Metriken der Eingangsdaten. Auf Basis zumindest einer der qualitativen Metriken können z.B. verfügbare Redundanzen für eine Datenerfassung aktiviert werden. Ebenso kann anhand der zumindest einen qualitativen Metrik des Nutzdatums geprüft werden, ob das Nutzdatum für eine vorgesehene Nutzung verwendet werden kann.
  • Die Recheneinheit 22 kann von einer Kontrolleinheit 23 gesteuert werden. Über eine Benutzerschnittstelle 26 können gegebenenfalls Einstellungen der Recheneinheit 22 oder der Kontrolleinheit 23 geändert werden. Die in der Vorrichtung 20 anfallenden Daten können bei Bedarf in einem Speicher 24 abgelegt werden, beispielsweise für eine spätere Auswertung oder für eine Nutzung durch die Komponenten der Vorrichtung 20. Alternativ oder zusätzlich können sie über einen Ausgang 25 der Vorrichtung 20 für eine weitere Verarbeitung bereitgestellt werden. Der Eingang 21 und der Ausgang 25 können zu einer bidirektionalen Schnittstelle zusammengefasst sein. Die Recheneinheit 22 sowie die Kontrolleinheit 23 können als dedizierte Hardware realisiert sein, beispielsweise als integrierte Schaltungen. Natürlich können sie aber auch teilweise oder vollständig kombiniert oder als Software implementiert werden, die auf einem geeigneten Prozessor läuft, beispielsweise auf einer GPU oder einer CPU.
  • 3 zeigt eine vereinfachte schematische Darstellung einer zweiten Ausführungsform einer Vorrichtung 30 zum Qualifizieren eines Nutzdatums. Die Vorrichtung 30 weist einen Prozessor 32 und einen Speicher 31 auf. Beispielsweise handelt es sich bei der Vorrichtung 30 um einen Computer, eine Workstation oder ein Steuergerät. Im Speicher 31 sind Instruktionen abgelegt, die die Vorrichtung 30 bei Ausführung durch den Prozessor 32 veranlassen, die Schritte gemäß einem der beschriebenen Verfahren auszuführen. Die im Speicher 31 abgelegten Instruktionen verkörpern somit ein durch den Prozessor 32 ausführbares Programm, welches das erfindungsgemäße Verfahren realisiert. Die Vorrichtung 30 hat einen Eingang 33 zum Empfangen von Informationen. Vom Prozessor 32 generierte Daten werden über einen Ausgang 34 bereitgestellt. Darüber hinaus können sie im Speicher 31 abgelegt werden. Der Eingang 33 und der Ausgang 34 können zu einer bidirektionalen Schnittstelle zusammengefasst sein.
  • Der Prozessor 32 kann eine oder mehrere Prozessoreinheiten umfassen, beispielsweise Mikroprozessoren, digitale Signalprozessoren oder Kombinationen daraus.
  • Die Speicher 24, 31 der beschriebenen Ausführungsformen können sowohl volatile als auch nichtvolatile Speicherbereiche aufweisen und unterschiedlichste Speichergeräte und Speichermedien umfassen, beispielsweise Festplatten, optische Speichermedien oder Halbleiterspeicher.
  • Nachfolgend sollen Details einer Ausführungsform der Erfindung anhand von 4 bis 7 beschrieben werden. Dabei wird als Beispiel eine Positionsberechnung auf Basis von Daten eines lokalen Umfeldmodells und deren Abgleich mit Daten eines globalen Umfeldmodells betrachtet. Selbstverständlich ist das beschriebene Konzept auch für andere Anwendungsfälle nutzbar.
  • 4 zeigt schematisch eine Systemtopologie eines Sicherheitskonzeptes für eine Positionsberechnung. Das dargestellte System besteht im Wesentlichen aus zwei Komponenten, einem Backend 40, dem GEM-Anbieter, und einem Client 50, dem GEM-Nutzer.
  • Ein Anwendungsserver 41 stellt eine Ausführungsumgebung für das Backend 40 bereit. Das Backend 40 sammelt LEM-Daten von einer Flotte von Fahrzeugen, die zugleich auch GEM-Nutzer sein können, führt diese Daten zusammen und erzeugt daraus GEM-Daten, d.h. ein globales Umfeldmodell. Die so erzeugten GEM-Daten werden den Clients 50, d.h. den GEM-Nutzern, zur Verfügung gestellt. Zur Durchführung dieser Schritte nutzt das Backend 40 einen Eingangsprozess 42, einen Prozess 43 zur Generierung der GEM-Daten und einen Ausgangsprozess 44, die in 4 als Software-Werkzeugkette dargestellt sind.
  • Die Clients 50 bzw. GEM-Nutzer in den beteiligten Fahrzeugen generieren fortlaufend LEM-Daten und übermitteln diese an das Backend 40. Dazu berechnet der Client 50 eine ungefähre Position auf Grundlage einer groben Position, die mittels GNSS (GNSS: Global Navigation Satellite System; globales Navigationssatellitensystem) bestimmt wird, und eines Bewegungsvektors, der aus einer Bewegungsschätzung auf Basis von Bewegungssensoren des Fahrzeugs resultiert. Für diese Zwecke wird im Client 50 eine Ausführungsumgebung für einen GNSS-Prozess 51 und einen Prozess 52 zur Bewegungsschätzung bereitgestellt. Die ungefähre Position wird während des Fahrens in einer Rekalibrierungsschleife verbessert. Dazu werden durch einen Abgleichprozess 53 fortlaufend LEM-Daten, die z.B. auf Basis von 3D-Daten eines Lidars 54 generiert werden, mit den vom Backend 40 empfangenen GEM-Daten verglichen. Die daraus resultierende relative Position wird zur Kalibrierung in einem Prozess 55 für die hochgenaue Positionierung genutzt, um so eine absolute (exakte) Position des Fahrzeugs zu bestimmen. Diese wird lokalen hochautomatisierten Fahrfunktionen 56 zur Verfügung gestellt. Auch für den Abgleichprozess 53, das Lidar 54, den Prozess 55 für die hochgenaue Positionierung und die hochautomatisierten Fahrfunktionen 56 wird im Client 50 eine Ausführungsumgebung bereitgestellt.
  • Die Kommunikation zwischen dem Backend 40 und den Clients 50 erfolgt über eine mobile Datenverbindung. Das Backend 40 und die Clients 50 stellen physische Hardware dar, d.h. einen Server sowie die beteiligten Fahrzeuge, während die Ausführungsumgebung eine Software-Plattform ist, z.B. eine virtuelle Maschine oder ein Betriebssystem. Die Komponenten 53, 55 zur Berechnung der absoluten Position auf Seiten des Clients 50, die in 4 von einem gestrichelten Kasten umschlossen sind, können als SEooC (SEooC: Safety Element out of context) betrachtet werden, d.h. als Sicherheitselement, das außerhalb seines Kontexts entwickelt bzw. betrachtet wird und das als Produkt in verschiedene Systeme integriert werden kann.
  • In 4 sind zusätzlich die für die diversen Komponenten vorgesehenen ASIL-Level angegeben. Die berechnete absolute Position, d.h. die Ausgangsgröße, soll den ASIL-Level B haben. Angenommen wird, dass die Bewegungssensoren des Fahrzeugs für die hochgenaue Positionierung mindesten den ASIL-Level B haben, während der verwendete GNSS-Sensor die Einstufung QM (QM: Quality management; Qualitätsmanagement) hat, d.h. an ihn werden keine Anforderungen gestellt, die über das übliche Qualitätsmanagement des Systemherstellers hinausgehen.
  • 5 zeigt schematisch das Prinzip der absoluten Positionsberechnung. Die absolute Position wird fortlaufend durch einen Vergleich der LEM-Daten und der GEM-Daten verbessert. Das lokale Umfeldmodell wird durch einen LEM-Generator 57 aus den Daten des Lidars 54 ermittelt. Auf Basis der Position einer Übereinstimmung des lokalen Umfeldmodells und des globalen Umfeldmodells wird durch einen Block 58 eine relative Position bestimmt, die für die Kalibrierung der Position genutzt wird. Zu diesem Zweck ist im Prozess 55 für die hochgenaue Positionierung ein Block 59 zur Positionsanpassung implementiert. Die Genauigkeit der ermittelten absoluten Position nimmt vom Start eines Fahrzyklus des Fahrzeugs kontinuierlich mit der gefahrenen Distanz zu. Zu Beginn wird zumindest eine grobe Position benötigt, z.B. vom GNSS-Sensor, um den Bereich einzuschränken, in dem eine Übereinstimmung des lokalen Umfeldmodells mit dem globalen Umfeldmodell gesucht werden soll.
  • Ein Block 60 zur Qualifizierung der absoluten Position fügt der absoluten Position Metadaten hinzu. Diese ermöglichen den Abnehmern der Positionsdaten, d.h. den hochautomatisierten Fahrfunktionen 56, eine Entscheidung zu treffen, ob die Qualität der ermittelten Position ausreichend für die vorgesehene Nutzung ist.
  • Die verwendeten Metadaten werden nachfolgend am Beispiel von LEM-Daten, GEM-Daten, Positionsdaten und Sensordaten beschrieben.
  • Die Metadaten werden genutzt, um die Qualität der errechneten Umfeldmodelle und der Positionsdaten zu bewerten. Dabei sollen die Metadaten individuell für jedes Datum sein, d.h. die Vertrauenswürdigkeit und die Präzision können in Abhängigkeit von den verfügbaren Sensoren und den Umgebungsbedingungen über die Zeit variieren. Jeder Empfänger eines Umfeldmodells oder von Positionsdaten soll die Metadaten nutzen, um zu entscheiden, ob die erhaltenen Daten ausreichend vertrauenswürdig und präzise für die vorgesehene Nutzung sind.
  • Zur Qualifizierung der Vertrauenswürdigkeit der LEM-Daten, der GEM-Daten, der Positionsdaten und der Sensordaten in Bezug auf die funktionale Sicherheit (ASIL) und die Sicherheit der vorgesehenen Funktion (SOTIF) werden ein Integritätswert und ein Konfidenzwert genutzt.
  • Der Integritätswert ist ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf die funktionale Sicherheit, d.h. ein Maß für die Sicherheit bezüglich Gefährdungen, die durch Fehlfunktion eines E/E-Systems (Elektrik- und Elektronik-System) entstehen können. Er definiert einen Integritätslevel des zugehörigen Datums und betrachtet, ob alle beteiligten Hardware- und Softwarekomponenten wie spezifiziert arbeiten und rückwirkungsfrei sind. Der Integritätswert konzentriert sich auf die Erkennung und Behandlung von Fehlern aufgrund falscher oder fehlerhafter Implementierung oder des Einflusses von Störeinflüssen auf die Software und die Hardware. Entsprechend ASIL reichen die möglichen Integritätslevel von A (niedrigste Stufe) bis D (höchste Stufe) sowie QM.
  • Die Abhängigkeiten des Integritätswertes sind in 6 dargestellt. Zu sehen sind dabei die verschiedenen Datenquellen sowie die Metadaten, die jeweils von den Datenquellen zur Verfügung gestellt werden. Die Pfeile zeigen den Datenfluss der Metadaten an. Die Angabe „0..*“ bei den LEM-Daten gibt an, dass die LEM-Daten von 0-n Clients stammen. Die Angabe „1“ bei den LEM-Daten gibt an, dass die lokalen LEM-Daten ausschließlich vom Ego-Fahrzeug stammen. Die Angabe „0..1“ bei den GEM-Daten gibt an, dass entweder GEM-Daten zur Verfügung stehen („1“) oder keine GEM-Daten zur Verfügung stehen („0“), d.h. dass ein Ausfall vorliegt. Die Blöcke „LEM-Berechnung“ und „Positionsberechnung“ umfassen alle beteiligten Softwarekomponenten auf Seiten des Clients. Der Block „GEM-Berechnung“ umfasst alle beteiligten Softwarekomponenten auf Seiten des Backends. LEM-Daten und GEM-Daten werden als Kombination von Daten eines Umfeldmodells und Positionsinformationen für das Modell betrachtet. Die Positionsdaten resultieren aus einem Vergleich der LEM-Daten und der GEM-Daten sowie aus einer Bewegungsschätzung auf Basis von Bewegungssensoren des Fahrzeugs und den GNSS-Sensordaten. Die Metadaten für die Sensoren werden typischerweise nicht durch die jeweiligen Sensoren selbst bereitgestellt, sondern durch die Software seitens des Clients errechnet.
  • Die Integritätswerte werden wie folgt berechnet:
    • Der Integritätswert der LEM-Daten ergibt sich aus dem niedrigsten Integritätswert aller beteiligten Elemente:
      • - der Lidar-Sensor, der die 3D-Daten des lokalen Umfeldmodells liefert (ASIL des Sensors);
      • - die Positionsdaten, die die absolute Position des lokalen Umfeldmodells liefern (Integritätswert der Positionsdaten);
      • - die LEM-Berechnung (ASIL der beteiligten Komponenten);
      • - alle anderen beteiligten Softwarekomponenten (ASIL der beteiligten Komponenten).
  • Der Integritätswert der GEM-Daten ergibt sich aus dem niedrigsten Integritätswert aller beteiligten Elemente:
    • - alle LEM-Daten, die für die Bestimmung des globalen Umfeldmodells herangezogen wurden (Integritätswerte der LEM-Daten);
    • - die Werkzeugkette für die GEM-Berechnung (ASIL der Werkzeugkette) .
  • Der Integritätswert der Positionsdaten ergibt sich aus dem niedrigsten Integritätswert aller beteiligten Elemente:
    • - alle Sensoren, die zur Berechnung der Position beitragen (ASIL der Sensoren);
    • - die Bewegungsschätzung (ASIL der beteiligten Komponenten);
    • - die LEM-Daten, die für die Berechnung der Position genutzt werden (Integritätswerte der LEM-Daten);
    • - die GEM-Daten, die für die Berechnung der Position genutzt werden (Integritätswerte der GEM-Daten);
    • - die Positionsberechnung (ASIL der beteiligten Komponenten);
    • - alle anderen beteiligten Softwarekomponenten (ASIL der beteiligten Komponenten).
  • Der Integritätswert der Positionsdaten kann sich z.B. bei einer reduzierten Sensorverfügbarkeit verringern, d.h. wenn sich die Redundanz reduziert.
  • Der Konfidenzwert ist ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf die Nominalleistung, d.h. ein Maß für die Sicherheit bezüglich von Gefährdungen, die ohne Fehlfunktion eines E/E-Systems aufgrund unzureichender Spezifikation entstehen können. Er definiert einen Konfidenzlevel der jeweiligen Daten und betrachtet, ob alle beteiligten Hardware- und Softwarekomponenten als „ausreichend gut“ für tatsächliche Anwendungsfälle spezifiziert und validiert sind. Der Konfidenzwert konzentriert sich auf die Erkennung und Behandlung von Spezifikationslücken und den daraus resultierenden Leistungsgrenzen der Software und der Hardware. Beispielsweise kann ein in der Spezifikation nicht berücksichtigtes reales Szenario (z.B. „Tunneleinfahrt“) zu einem unvorhersehbaren Verhalten des Systems führen und damit zu einer Gefährdung. Die möglichen Konfidenzlevel reichen von 1 (niedrigste Stufe) bis X (höchste Stufe).
  • Die Abhängigkeiten des Konfidenzwertes sind in 7 dargestellt. Zu sehen sind dabei die verschiedenen Datenquellen sowie die Metadaten, die jeweils von den Datenquellen zur Verfügung gestellt werden. Die Pfeile zeigen den Datenfluss der Metadaten an. Die Angabe „0..*“ bei den LEM-Daten gibt an, dass die LEM-Daten von 0-n Clients stammen. Die Angabe „1“ bei den LEM-Daten gibt an, dass die lokalen LEM-Daten ausschließlich vom Ego-Fahrzeug stammen. Die Angabe „0..1“ bei den GEM-Daten gibt an, dass entweder GEM-Daten zur Verfügung stehen („1“) oder keine GEM-Daten zur Verfügung stehen („0“), d.h. dass ein Ausfall vorliegt. Die Blöcke „LEM-Berechnung“ und „Positionsberechnung“ umfassen alle beteiligten Softwarekomponenten auf Seiten des Clients. Der Block „GEM-Berechnung“ umfasst alle beteiligten Softwarekomponenten auf Seiten des Backends. LEM-Daten und GEM-Daten werden als Kombination von Daten eines Umfeldmodells und Positionsinformationen für das Modell betrachtet. Die Positionsdaten resultieren aus einem Vergleich der LEM-Daten und der GEM-Daten sowie aus einer Bewegungsschätzung auf Basis von Bewegungssensoren des Fahrzeugs und der GNSS-Sensoren. Die Metadaten für die Sensoren werden typischerweise nicht durch die jeweiligen Sensoren selbst bereitgestellt, sondern durch die Software seitens des Clients errechnet.
  • Die Konfidenzwerte werden wie folgt berechnet:
    • Der Konfidenzwert der LEM-Daten ergibt sich aus dem niedrigsten Konfidenzwert aller beteiligten Elemente:
      • - der Lidar-Sensor, der die 3D-Daten des lokalen Umfeldmodells liefert (SOTIF des Sensors);
      • - die Positionsdaten, die die absolute Position des lokalen Umfeldmodells liefern (Konfidenzwert der Positionsdaten);
      • - die LEM-Berechnung (SOTIF der beteiligten Komponenten);
      • - alle anderen beteiligten Softwarekomponenten (Leistung der beteiligten Komponenten).
  • Der Konfidenzwert der LEM-Daten kann sich z.B. verringern, wenn eine Sensorblindheit erkannt wird.
  • Der Konfidenzwert der GEM-Daten ergibt sich aus dem niedrigsten Konfidenzwert aller beteiligten Elemente:
    • - alle LEM-Daten, die für die Bestimmung des globalen Umfeldmodells herangezogen wurden (Konfidenzwerte der LEM-Daten);
    • - die Werkzeugkette für die GEM-Berechnung (SOTIF der Werkzeugkette) .
  • Der Konfidenzwert der GEM-Daten kann sich z.B. verringern, wenn insgesamt zu wenig lokale Umfeldmodelle verfügbar sind, wenn die Mehrheit der verfügbaren lokalen Umfeldmodelle zu alt ist, wenn die Mehrheit der verfügbaren lokalen Umfeldmodelle zu unpräzise ist oder wenn die Mehrheit der verfügbaren lokalen Umfeldmodelle zu wenig charakteristische Merkmale bzw. 3D-Informationen enthält. Für die Bewertung der lokalen Umfeldmodelle können in Form von Metadaten übermittelte Zeitstempel und Angaben zur Präzision genutzt werden.
  • Der Konfidenzwert der Positionsdaten ergibt sich aus dem niedrigsten Konfidenzwert aller beteiligten Elemente:
    • - alle Sensoren, die zur Berechnung der Position beitragen (SOTIF der Sensoren);
    • - die LEM-Daten, die für die Berechnung der Position genutzt werden (Konfidenzwerte der LEM-Daten);
    • - die GEM-Daten, die für die Berechnung der Position genutzt werden (Konfidenzwerte der GEM-Daten);
    • - die Positionsberechnung (SOTIF der beteiligten Komponenten);
    • - alle anderen beteiligten Softwarekomponenten (SOTIF der beteiligten Komponenten).
  • Der Konfidenzwert der Positionsdaten kann sich z.B. verringern, wenn kein globales Umfeldmodell verfügbar ist, wenn das globale Umfeldmodell zu alt ist, wenn das globale Umfeldmodell zu unpräzise ist, wenn es keine Übereinstimmung zwischen dem lokalen Umfeldmodell und dem globalen Umfeldmodell gibt oder die Übereinstimmung zu schlecht ist oder bei einer reduzierten Sensorverfügbarkeit, d.h. wenn sich die Redundanz reduziert. Für die Bewertung des globalen Umfeldmodells können in Form von Metadaten übermittelte Zeitstempel und Angaben zur Präzision genutzt werden.
  • Im beschriebenen Beispiel der 5 ist zusammengefasst die Nutzung der folgenden Metadaten vorgesehen:
    • Metadaten für die empfangenen Sensordaten:
      • • Integritätswert des Sensors: Integritätslevel des Sensors in Bezug auf ASIL, wie spezifiziert;
      • • Konfidenzwert des Sensors: Konfidenzlevel des Sensors in Bezug auf SOTIF, wie spezifiziert;
      • • Präzision des Sensors: Maximale Varianz der Sensordaten;
      • • Verfügbarkeit des Sensors (Blindheit, Ausfall).
  • Metadaten für das lokale Umfeldmodell:
    • • LEM-Integritätswert: Integritätslevel des berechneten lokalen Umfeldmodells in Bezug auf ASIL, wie oben beschrieben;
    • • LEM-Konfidenzwert: Konfidenzlevel des berechneten lokalen Umfeldmodells in Bezug auf SOTIF, wie oben beschrieben;
    • • LEM-Zeitstempel: Absolute Zeitangabe, wann das lokale Umfeldmodell erstellt wurde;
    • • LEM-Präzision: Maximale Varianz des lokalen Umfeldmodells.
  • Metadaten für das globale Umfeldmodell:
    • • GEM-Integritätswert: Integritätslevel des berechneten globalen Umfeldmodells in Bezug auf ASIL, wie oben beschrieben;
    • • GEM-Konfidenzwert: Konfidenzlevel des berechneten globalen Umfeldmodells in Bezug auf SOTIF, wie oben beschrieben;
    • • GEM-Zeitstempel: Absolute Zeitangabe, wann das globale Umfeldmodell erstellt wurde;
    • • GEM-Präzision: Maximale Varianz des globalen Umfeldmodells.
  • Metadaten für die Positionsdaten:
    • • Integritätswert der Position: Integritätslevel der berechneten absoluten Position in Bezug auf ASIL, wie oben beschrieben;
    • • Konfidenzwert der Position: Konfidenzlevel der berechneten absoluten Position in Bezug auf SOTIF, wie oben beschrieben;
    • • Zeitstempel der Position: Absolute Zeitangabe, wann die absolute Position berechnet wurde;
    • • Präzision der Position: Maximale Varianz der berechneten absoluten Position.
  • Bezugszeichenliste
  • 10
    Empfangen von Eingangsdaten
    11
    Empfangen von qualitativen Metriken für die Eingangsdaten
    12
    Ermitteln eines Nutzdatums aus den Eingangsdaten
    13
    Ermitteln einer qualitativen Metrik für das Nutzdatum
    20
    Vorrichtung
    21
    Eingang
    22
    Recheneinheit
    23
    Kontrolleinheit
    24
    Speicher
    25
    Ausgang
    26
    Benutzerschnittstelle
    30
    Vorrichtung
    31
    Speicher
    32
    Prozessor
    33
    Eingang
    34
    Ausgang
    40
    Backend
    41
    Anwendungsserver
    42
    Eingangsprozess
    43
    Prozess zur Generierung vom GEM-Daten
    44
    Ausgangsprozess
    50
    Client
    51
    GNSS-Prozess
    52
    Prozess zur Bewegungsschätzung
    53
    Abgleichprozess
    54
    Lidar
    55
    Prozess für die hochgenaue Positionierung
    56
    Hochautomatisierte Fahrfunktion
    57
    LEM-Generator
    58
    Abgleich LEM/GEM
    59
    Positionsanpassung
    60
    Qualifizierung der absoluten Position

Claims (10)

  1. Verfahren zum Qualifizieren eines Nutzdatums, mit den Schritten: - Empfangen (10) von Eingangsdaten von zwei oder mehr Quellen; - Empfangen (11) von qualitativen Metriken für die Eingangsdaten; - Ermitteln (12) eines Nutzdatums aus den Eingangsdaten; und - Ermitteln (13) zumindest einer qualitativen Metrik für das Nutzdatum aus den qualitativen Metriken der Eingangsdaten.
  2. Verfahren gemäß Anspruch 1, wobei die qualitativen Metriken einen Integritätswert oder einen Konfidenzwert umfassen.
  3. Verfahren gemäß Anspruch 2, wobei der Integritätswert ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf eine funktionale Sicherheit ist und der Konfidenzwert ein Maß für die Vertrauenswürdigkeit eines Datums in Bezug auf eine Nominalleistung ist.
  4. Verfahren gemäß Anspruch 2 oder 3, wobei auf Basis zumindest einer der qualitativen Metriken verfügbare Redundanzen für eine Datenerfassung aktiviert werden.
  5. Verfahren gemäß einem der vorherigen Ansprüche, wobei der Integritätswert des Nutzdatums aus dem niedrigsten Integritätswert der verwendeten Eingangsdaten resultiert oder der Konfidenzwert des Nutzdatums aus dem niedrigsten Konfidenzwert der verwendeten Eingangsdaten resultiert, oder wobei durch Dekomposition eine Erhöhung des Integritätswertes des Nutzdatums erreicht wird.
  6. Verfahren gemäß einem der vorherigen Ansprüche, wobei die Eingangsdaten Sensordaten, Daten eines Umfeldmodells oder Positionsdaten sind und das Nutzdatum ein Datum eines Umfeldmodells oder eine Position ist.
  7. Verfahren gemäß einem der vorherigen Ansprüche, wobei anhand der zumindest einen qualitativen Metrik des Nutzdatums von einem Abnehmer des Nutzdatums geprüft wird, ob das Nutzdatum für eine vorgesehene Nutzung verwendet werden kann.
  8. Verfahren gemäß Anspruch 7, wobei die vorgesehene Nutzung eine autonome Fahrfunktion eines Fahrzeuges ist.
  9. Computerprogramm mit Instruktionen, die bei Ausführung durch einen Computer den Computer zur Ausführung der Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 8 zum Qualifizieren eines Nutzdatums veranlassen.
  10. Vorrichtung (20) zum Qualifizieren eines Nutzdatums, mit: - einem Eingang (21) zum Empfangen (10) von Eingangsdaten von zwei oder mehr Quellen und zum Empfangen (11) von qualitativen Metriken für die Eingangsdaten; und - einer Recheneinheit (22) zum Ermitteln (12) eines Nutzdatums aus den Eingangsdaten und zum Ermitteln (13) zumindest einer qualitativen Metrik für das Nutzdatum aus den qualitativen Metriken der Eingangsdaten.
DE102018217014.2A 2018-10-04 2018-10-04 Dynamische Qualifizierung von Nutzdaten Pending DE102018217014A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102018217014.2A DE102018217014A1 (de) 2018-10-04 2018-10-04 Dynamische Qualifizierung von Nutzdaten

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018217014.2A DE102018217014A1 (de) 2018-10-04 2018-10-04 Dynamische Qualifizierung von Nutzdaten

Publications (1)

Publication Number Publication Date
DE102018217014A1 true DE102018217014A1 (de) 2020-04-09

Family

ID=69886250

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018217014.2A Pending DE102018217014A1 (de) 2018-10-04 2018-10-04 Dynamische Qualifizierung von Nutzdaten

Country Status (1)

Country Link
DE (1) DE102018217014A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019134766A1 (de) * 2019-12-17 2021-06-17 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Verarbeitung von Sensordaten in einem Fahrzeug

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014212703A1 (de) * 2014-07-01 2016-01-07 Continental Teves Ag & Co. Ohg M2XPro-Überwachung durch Integritätsmaßspeicherung
US20160358088A1 (en) * 2015-06-05 2016-12-08 Southwest Research Institute Sensor data confidence estimation based on statistical analysis
DE102016212326A1 (de) * 2016-07-06 2018-01-11 Robert Bosch Gmbh Verfahren zur Verarbeitung von Sensordaten für eine Position und/oder Orientierung eines Fahrzeugs

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014212703A1 (de) * 2014-07-01 2016-01-07 Continental Teves Ag & Co. Ohg M2XPro-Überwachung durch Integritätsmaßspeicherung
US20160358088A1 (en) * 2015-06-05 2016-12-08 Southwest Research Institute Sensor data confidence estimation based on statistical analysis
DE102016212326A1 (de) * 2016-07-06 2018-01-11 Robert Bosch Gmbh Verfahren zur Verarbeitung von Sensordaten für eine Position und/oder Orientierung eines Fahrzeugs

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019134766A1 (de) * 2019-12-17 2021-06-17 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Verarbeitung von Sensordaten in einem Fahrzeug

Similar Documents

Publication Publication Date Title
EP2442248B1 (de) Kopplungsmethodik für nicht-iterative Co-Simulation
DE102018128289A1 (de) Verfahren und vorrichtung für eine autonome systemleistung und zur einstufung
DE112017007656T5 (de) Verschobene aktualisierung von datenbank-hashcode in einer blockchain
DE112020003050T5 (de) Fehlerkompensation in analogen neuronalen netzen
EP2897011A1 (de) Verfahren und Simulationsanordnung zur Simulation einer automatisierten Industrieanlage
DE102017204745A1 (de) Architektur und Vorrichtung für eine fortschrittliche Arbitration in integrierten Steuerungen
DE112019003929T5 (de) Elektronische steuervorrichtung und aktualisierungssystem eines neuronalen netzes
DE102017213510A1 (de) Verfahren und Vorrichtung zum Erzeugen eines maschinellen Lernsystems, und virtuelle Sensorvorrichtung
DE102018217014A1 (de) Dynamische Qualifizierung von Nutzdaten
DE102013206292A1 (de) Verfahren und Vorrichtung zum Erstellen eines datenbasierten Funktionsmodells
DE102009012887B4 (de) Verfahren zum Prüfen einer nicht korrekten Installation von Fahrzeugsensoren
EP3901713A1 (de) Verfahren und system zum betrieb einer technischen anlage mit einem optimalen modell
WO2015172905A1 (de) Anordnung und verfahren zur sensorfusion
DE102019217015A1 (de) Kommunikationsvorrichtung
WO2021254672A1 (de) Verfahren, vorrichtung, computerprogramm und computerlesbares speichermedium zum ermitteln eines neuronalen netzes und zum betreiben eines fahrzeuges
DE102021200575A1 (de) Anomalieerkennungsvorrichtung, Anomalieerkennungsverfahren und Programm
WO2021047970A1 (de) Software-komponenten für eine software-architektur
DE102019209536A1 (de) Verfahren und Vorrichtung zur Bewertung und Auswahl von Signal-Vergleichsmetriken
DE102019130484A1 (de) Verfahren und Vorrichtung zum Anlernen eines Ensembles von neuronalen Netzen
DE102019219730A1 (de) Verfahren und Vorrichtung zur modellbasierten Analyse
EP3698103A1 (de) Abschätzen der messgenauigkeit unterschiedlicher sensoren für dieselbe messgrösse
EP4199553A1 (de) Verfahren und testeinheit zur testausführung virtueller tests
DE102022208087A1 (de) Verfahren zum Überprüfen einer Verarbeitung von Nutzdaten
DE102017216749A1 (de) Verfahren zur Bereitstellung eines Steuersignals
DE102010014720A1 (de) Verfahren zum Verifizieren eines aus einem Quellmodell generierten Zielprogramms

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0019000000

Ipc: G16Z0099000000

R016 Response to examination communication