DE102021202935A1 - Verfahren und Vorrichtung zum Steuern einer Fahrfunktion - Google Patents

Verfahren und Vorrichtung zum Steuern einer Fahrfunktion Download PDF

Info

Publication number
DE102021202935A1
DE102021202935A1 DE102021202935.3A DE102021202935A DE102021202935A1 DE 102021202935 A1 DE102021202935 A1 DE 102021202935A1 DE 102021202935 A DE102021202935 A DE 102021202935A DE 102021202935 A1 DE102021202935 A1 DE 102021202935A1
Authority
DE
Germany
Prior art keywords
comparison
data
output data
pod
input data
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
DE102021202935.3A
Other languages
English (en)
Inventor
Hans-Leo Ross
Jan Wiese
Charles Kalleppally
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch 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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102021202935.3A priority Critical patent/DE102021202935A1/de
Priority to US17/697,200 priority patent/US20220308539A1/en
Priority to CN202210294878.5A priority patent/CN115129110A/zh
Publication of DE102021202935A1 publication Critical patent/DE102021202935A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/12—Synchronisation of different clock signals provided by a plurality of clock generators
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/0098—Details of control systems ensuring comfort, safety or stability not otherwise provided for
    • 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/023—Avoiding failures by using redundant parts
    • 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/029—Adapting to failures or work around with other constraints, e.g. circumvention by avoiding use of failed parts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/524—Deadlock detection or avoidance
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0004—In digital systems, e.g. discrete-time systems involving sampling
    • B60W2050/0006—Digital architecture hierarchy
    • 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
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle
    • 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
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2637—Vehicle, car, auto, wheelchair
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Transportation (AREA)
  • Human Computer Interaction (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Hardware Redundancy (AREA)

Abstract

Verfahren (10) zum Steuern einer Fahrfunktion, gekennzeichnet durch folgende Merkmale:
- für die Fahrfunktion relevante Eingangsdaten (11) werden einem Rechnerverbund (26) zugeführt (13),
- durch eine redundante Verarbeitung (14) der Eingangsdaten (11) auf mindestens einer ersten Recheneinheit (41) und einer zweiten Recheneinheit (42) im Rechnerverbund (26) werden jeweils Ausgangsdaten (15) erzeugt,
- von jeder Recheneinheit (41, 42) werden die jeweiligen Ausgangsdaten (15) um Kontrollfelder ergänzt (16),
- die Ausgangsdaten (15) der Recheneinheiten (41, 42) werden einem Vergleich zugeführt (17) und ein Ergebnis (24) des Vergleiches ermittelt (18) und
- abhängig vom Ergebnis (24) werden die Ausgangsdaten (15) fallweise mitsamt der jeweiligen Kontrollfelder für die Fahrfunktion herangezogen (19), falls die Ausgangsdaten (15) und Kontrollfelder dem Vergleich standhalten, oder als fehlerhaft markiert (20), falls die Ausgangsdaten (15) oder Kontrollfelder abweichen.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Steuern einer Fahrfunktion. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
  • Stand der Technik
  • In US2019047579A1 werden Verfahren und Vorrichtungen beschrieben, die sich auf die Bereitstellung einer hohen funktionalen Sicherheit beziehen. In einer Ausführungsform führt ein Master-Kern, der mit einem Slave-Kern gewissermaßen „im Gleichschritt“ (lockstep) gekoppelt ist, eine oder mehrere Operationen aus, um Fahrerassistenzsysteme oder autonomes Fahren zu unterstützen. Der Master-Kern und der Slave-Kern empfangen das gleiche Eingangssignal, und die eng gekoppelte Kernlogik bewirkt die Erzeugung eines Signals als Reaktion auf den Vergleich eines ersten Ausgangs des Master-Kernes und eines zweiten Ausgangs des Slave-Kernes. Das erzeugte Signal verursacht eine Unterbrechung der einen oder mehreren Operationen als Reaktion auf eine Nichtübereinstimmung zwischen dem ersten Ausgang und dem zweiten Ausgang. Andere Ausführungsformen werden ebenfalls offenbart und beansprucht.
  • In einem selbstfahrenden autonomen Fahrzeug gemäß US2018370540A1 umfasst eine Steuerungsarchitektur mehrere Prozessoren in derselben Box. Jeder Prozessor überwacht die anderen und ergreift bei Bedarf geeignete sichere Maßnahmen. Einige Prozessoren führen möglicherweise ruhende oder redundante Funktionen mit niedriger Priorität aus, die aktiv werden, wenn festgestellt wird, dass ein anderer Prozessor ausgefallen ist. Die Prozessoren werden unabhängig voneinander mit Strom versorgt und führen unabhängig voneinander redundante Algorithmen von der Sensordatenverarbeitung bis zu Betätigungsbefehlen mit unterschiedlichen Hardwarefunktionen aus. Hardware- und Software-Diversität verbessert die Fehlertoleranz.
  • Eine autonome Fahrsteuerung nach US2019334706A1 umfasst mehrere parallele Prozessoren, die mit gemeinsamen Eingangsdaten arbeiten, die von mehreren autonomen Fahrsensoren empfangen werden. Jeder der mehreren Parallelprozessoren umfasst Kommunikationsschaltungen, einen allgemeinen Prozessor, ein Sicherheitsprozessorsubsystem (SCS) und ein Sicherheitssubsystem (SMS). Die Kommunikationsschaltung unterstützt die Kommunikation zwischen den Parallelprozessoren, einschließlich der Kommunikation zwischen den allgemeinen Prozessoren der Parallelprozessoren, der Kommunikation zwischen den Sicherheitsprozessorsubsystemen der Parallelprozessoren unter Verwendung von SCS-Kryptographie und der Kommunikation zwischen den Sicherheitssubsystemen der Parallelprozessoren unter Verwendung von SMS-Kryptographie, wobei sich die SMS-Kryptographie von der SCS-Kryptographie unterscheidet. SCS und SMS können jeweils dedizierte Hardware und insbesondere Speicher enthalten, um die Kommunikation zu unterstützen.
  • Offenbarung der Erfindung
  • Die Erfindung stellt ein Verfahren zum Steuern einer Fahrfunktion, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
  • Der erfindungsgemäße Ansatz fußt auf der Einsicht, dass die typischen Sicherheitsmechanismen für eine sichere Recheneinheit auch in der Cloud implementiert werden müssen, um Daten auch hier funktional sicher verarbeiten zu können. Eine typische Lösung für die zufälligen Hardware-Fehler in der LogikEinheit bzw. zur Verarbeitung der logischen Befehlssätze ist die homogene parallel redundante Verarbeitung durch homogen redundante Recheneinheiten in einem getakteten Rechner. Diese Recheneinheiten werden von einer unabhängigen Einheit verglichen. In der Cloud sind die Speicher volatil aber auch nicht volatile Speicher (RAM, ROM, CACHE etc.) und die gesamte Datensteuerung (Handler, Multiplex, etc.) für den Nutzer nicht transparent und zugänglich, daher können diese genauso wie die Hardware selber nicht direkt überwacht werden. Daher müssen die Daten in die Speicher und aus den Speicher heraus, verschlüsselt versendet werden. Diese E2E-Absicherung ist in der Cloud bereits aus Security-Gründen üblich. Um diese sicherheitstechnisch zu nutzen, müssen diese E2E-Maßnahmen auch zur Laufzeit kontinuierlich überwacht werden. Dadurch kann auch die Unabhängigkeit der Daten zueinander sichergestellt werden, so dass der sogenannte Common Cause (also die abhängigen Fehler der beiden zu vergleichenden Kanäle) überwacht werden kann.
  • Um einen positiven Vergleich zu erreichen, müssen auch die Eingangsdaten synchronisiert und verglichen werden. Dies gilt ebenso für die Ausgangsdaten, die zeitsynchron für die weitere Verarbeitung synchronisiert und verglichen werden. Eine solche getaktete redundante Steuereinheit wird allgemein als Lockstep-Controller bezeichnet. In der Cloud wird dann auch die E2E-Absicherung in dem jeweiligen Lockstep-Vergleich ebenfalls geprüft werden.
  • In erster Linie dient der Lockstep dazu, dass sporadische und zufällige Fehler in der Recheneinheit (ALU, Arithmetic Logic Unit) überwacht werden können. Dadurch, dass man unterschiedliche Semantik und Codierung nutzen kann und dem Lockstep zugeführt werden und diese in die E2E Überwachung einbringen kann, werden auch sporadische systematische Fehler während der Laufzeit detektierbar. Durch die Semantik und die Codierung erreicht man auch eine Diagnose, die auf die Fehlerursache schließen lassen kann. Somit kann man selektiv mit den fehlerhaften Informationen und Datenpakten umgegangen werden und auch „graceful Degradation“, also bedingte Degradationen durchführen.
  • Herkömmliche Lockstep-Controller sind wegen der Zeitsynchronisierung langsamer als normale Single-Core-Rechner. Des Weiteren haben sie im Allgemeinen den Nachteil, dass durch den Vergleich nur eine etwaige Abweichung der Information voneinander festgestellt werden kann, aber nicht, welcher der redundanten Rechner fehlerhaft ist. In Reaktion auf einen negativen Vergleich der Ausgangsdaten zweier Recheneinheiten werden daher üblicherweise beide Recheneinheiten abgeschaltet. Somit ist die Einheit weniger verfügbar. Ferner werden meist alle Ergebnisse einer Operation in den Vergleich einbezogen.
  • Eine weitere Laufzeit-Optimierung und Verfügbarkeits-Optimierung zu erreichen, kann der Lockstep-Vergleicher auch als Voter ausgebildet werden. Hier können dann 3 Quellen verglichen werden, wobei dann 2 korrekte gleiche Informationen bereits ausreichend sind um relevante Fehler identifizieren zu können. Somit können die als erstes gleichen Paare als „sichere Information“ für die Verarbeitung weitergereicht werden. Damit können Fehler im dritten Kanal toleriert werden oder auch zur Diagnose zur System-Performanz und zur Optimierung genutzt werden.
  • Ein Vorzug der vorgeschlagenen Lösung liegt vor diesem Hintergrund darin, dass nur sicherheitsrelevante Daten verglichen und dem Vergleicher vorzugsweise durchgängig (end to end, E2E) abgesichert zugeführt werden. Somit kann auch die Quelle von Fehlern identifiziert werden. Einschlägige Kontrollfelder und Sicherheitsmechanismen stellt etwa der AUTOSAR-Standard zur Verfügung.
  • Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass auch die Eingangsdaten mit Kontrollfeldern versehen sind und bei deren Inkonsistenz verworfen werden. Eine entsprechende Ausgestaltung trägt dem Umstand Rechnung, dass in einem Cloud-Rechner zusätzlich das Risiko besteht, dass externe Hacker und fremde Datenströme eine solche Recheneinheit erreichen könnten. Somit müssen nicht nur die Datenströme zwischen der Recheneinheit und dem Vergleicher hinreichend auf Unabhängigkeit in jedem Schritt (step) überwacht, sondern auch die Eingangsdaten gegen äußere Einwirkungen abgeschirmt werden.
  • Sämtliche Daten zur Berechnung der Grundfunktion (alle Modelle zur Verkehrssteuerung, Diagnosedaten etc.) können normal in der Cloud mit der maximalen Performanz berechnet werden. Alle sicherheits-relevante Daten können parallel verschlüsselt aus dem Prozess abgegriffen werden und verglichen. Die Grunddaten können dann auch umgehend an die weiterverarbeitende Einheit weitergeleitet werden, und erst nach erfolgreichem Lockstep-Vergleich wird das relevante Sicherheitsattribut, durch den Vergleicher für die Weiterverarbeitung aktiviert. Somit erhöht sich die Verfügbarkeit der Information und der Nachteil des Lockstep-Vergleichs gegenüber einem Single-Core bezüglich Zeit kompensiert.
  • Figurenliste
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
    • 1 den Basisaufbau des Locksteps.
    • 2 drei Server mit Eingangs- und Ausgangsdatenstrom.
    • 3 ein mehrstufiges Lockstep-Prinzip für Daten auf unterschiedlicher fahrzeugtechnischer Sicherheitsanforderungsstufe (automotive safety integrity level, ASIL).
    • 4 die Umsetzung des Lockstep-Prinzips in einem Kubernetes-Cluster.
    • 5 das UML-Sequenzdiagramm einer logischen Lockstep-Funktion.
    • 6 den Datenaustausch mit E2E-Absicherung zwischen Replikaten (replicas).
    • 7 ein Beispiel für eine hochverfügbare Lockstep-Anwendung in unabhängigen, besonders abgesicherten Containern.
  • Ausführungsformen der Erfindung
  • 1 illustriert einen Rechnerverbund (cluster) mit erfindungsgemäßen Funktionen. Die Grundfunktionen werden auf zwei verschiedenen Servern (31, 32) homogen redundant ausgeführt, deren Ergebnisse von einem unabhängigen Vergleicher (25; nachfolgend auch: „Komparator“) verglichen werden. Um die Verfügbarkeit des Locksteps weiter zu erhöhen, lässt sich der Rechnerverbund um einen dritten homogen redundanten Server (33) zu einem fehlertoleranten Regelsystem mit „2oo3“-Architektur gemäß IEC 61508 ergänzen. Stimmen in einer solchen Architektur zwei Ergebnisse überein, dann wird die übereinstimmende Information weitergeleitet.
  • Ein Steuerprogramm (task scheduler, 23) stellt die Verarbeitungsschritte ein. Weichen die Ergebnisse voneinander ab, so könnten diese Daten nach einem herkömmlichen Verfahren nur verworfen werden; oft werden beide Rechenkerne in diesem Fall durch einen sogenannten Watchdog abgeschaltet. Das erfindungsgemäße Verfahren hingegen verfolgt das Ziel, die fehlerhaften Daten als solche zu markieren und damit den Datenstrom aufrechtzuerhalten. Ferner sollen die zu vergleichenden Daten auf wesentliche Sicherheitsinformation reduziert werden.
  • Wie 2 verdeutlicht, werden allen drei Servern (31, 32, 33) die gleichen Eingangsdaten (11) zugeführt. Zur Erreichung größtmöglicher Unabhängigkeit sollten alle externen und Server-internen Datenströme durchgängig abgesichert werden. Im ersten Verarbeitungsschritt ist sicherzustellen, dass die Eingangsdaten (11) sämtlicher Server (31, 32, 33) zum selben Zeitpunkt erfasst werden, damit der Vergleich auf einem einheitlichen Datenstand beruht.
  • Auf diese Synchronisierung der Eingangsdaten (11) folgt die eigentliche Logikdatenverarbeitung, bevor die Ausgangsdaten (15) zur Versendung aufbereitet werden. Herkömmlicherweise laufen diese drei Verarbeitungsschritte taktsynchron ab, was die Laufzeit eines Lockstep-Systems gegenüber einem Single-Core-System maßgeblich verlängert.
  • Durch die erfindungsgemäße E2E-Absicherung wird auch den besonderen Herausforderungen einer verteilten Verarbeitung in der Cloud Rechnung getragen, indem alle relevanten Einflüsse auf das Lockstep-System zu einer Inkonsistenz zwischen Nutzdaten und E2E-Kontrollfeldern führen und beispielsweise im Rahmen einer zyklischen Redundanz- oder anderweitigen Sicherheitsüberprüfung detektiert werden können. Solange die Ausgangsdaten (15) der Server (31, 32, 33) gleich sind, können diese auch an nachfolgende Berechnungseinheiten oder Fahrzeuge übertragen werden. Selbst im Falle von Laufzeitschwankungen oder Datenverlust im Rahmen der Kommunikation kann das erste ankommende Paket bereits für eine sichere Fahrfunktion herangezogen werden.
  • Grundsätzlich kann wie auf einem lokalen Server auch in der Cloud eine Trennung virtueller Recheneinheiten durch Containervirtualisierung etwa mittels Docker erreicht werden. Jeder Anwendungscontainer dient in diesem Fall als unabhängige Recheneinheit. Üblicherweise sind nicht alle Daten und Funktionen einer solchen Recheneinheit sicherheitsrelevant; somit kann die Menge der zu verarbeitenden Eingangsdaten (11) durch eine Beschränkung auf sicherheitsrelevante Daten reduziert werden.
  • 3 zeigt einen Server (31) mit mehreren derartigen Anwendungscontainern (41, 42, 51, 52), deren Ausgangsdaten (15 - 2) im Lockstep verglichen werden. Im Beispiel werden alle Daten durch die Container (41, 42, 51, 52) homogen redundant verarbeitet. Alle für die Funktionssicherheit (safety) relevanten Daten werden besonders abgesicherten Containern (51, 52) zugeführt. Letztere dienen zusätzlich als Vergleicher (25 - 1) für die beiden regulären Anwendungscontainer (41, 42). Innerhalb der besonders abgesicherten Container (51, 52) können Security-Enklaven angelegt werden, um die Datenvergleiche auch gegen Hackerangriffe bestmöglich zu schützen. Die nicht sicherheitsrelevanten Ausgangsdaten (15 - 2) der regulären Container (41, 42) hingegen können vorteilhafterweise unmittelbar weitergeleitet und für Fahrfunktionen herangezogen werden. Wahlweise können die Daten für weniger kritische Funktionen - etwa der Stufen ASIL B oder SIL 2 - nach dem positiven Vergleich in einem der Safety-Container (51, 52) für die weitere Verarbeitung freigeschaltet werden.
  • 4 beleuchtet ein Implementierungsbeispiel für ein Kubernetes-Cluster (26) aus mehreren sogenannten Pods (61, 62, 63), die jeweils einen oder mehrere Anwendungscontainer umfassen können. Die beiden Pods (61, 62), welche die als Recheneinheiten dienenden Container (41, 42) aufnehmen, sowie der Komparator (43) sind hierbei jeweils über einen eigenen Dienst (service) des Clusters (26) erreichbar; diese Dienste (71, 72, 73) werden von einem gemeinsamen Eingangspunkt (27) auf einem Arbeitsknoten (worker node, 31) des Clusters (26) synchronisiert.
  • Das Verhalten des Clusters (26) folgt der Sequenz gemäß 5. Vor der Verarbeitung werden die Eingangsdaten (11) vom Eingangspunkt (27) mit einer übereinstimmenden Kennung versehen, anhand welcher sie durch den Komparator (63) einander zugeordnet werden können (28). In der Zwischenzeit werden die dem Komparator (63) zuerst vorliegenden Ausgangsdaten (15 - 2) in einem - vorzugsweise von mehreren Instanzen gemeinsam genutzten - Zwischenspeicher (cache) abgelegt (29), der nach dem Vergleich wieder freigegeben werden kann (35). Gemäß dem Leitbild einer dienstorientierten Architektur (service-oriented architecture, SOA) bleiben die Anfragen (requests) bis zur Rückmeldung des jeweiligen Ergebnisses (24) anhängig.
  • Aus der logischen Lockstep-Funktion ergibt sich das Gesamtbild der 6. Redundante Replikate der Pods (61, 62, 63) sollten dabei auf unterschiedlichen Arbeitsknoten (31, 32, 33, 34) laufen, sodass beim Ausfall eines einzelnen Knotens (31, 32, 33, 34) die Systemfunktion des Locksteps gewährleistet bleibt. Die Kubernetes-Lastverteilung (load balancing) kann solche Ausfälle automatisch kompensieren.
  • Neben der Portierung des Lockstep-Prinzips in die Cloud-Umgebung stellen die Mechanismen der Fehlerbeherrschung einen wesentlichen Aspekt des vorgeschlagenen Verfahrens dar. Sinnvoll ist es, den Lockstep parallel zur beabsichtigten Funktion operieren zu lassen, sodass der Datenstrom nur nach den erfolgreichen Prüfungen für die weitere Verarbeitung freigeschaltet werden kann.
  • Durch die E2E-Absicherung werden die Quellen etwaiger Fehler erkennbar gemacht. Dabei werden Fehler durch äußere Einflüsse bereits durch eine Verletzung des E2E-Schutzes angezeigt.
  • Auch die Abhängigkeiten der einzelnen Funktionselemente im Kubernetes-Cluster (26) werden durch Verletzungen der E2E-Sicherheit angezeigt. Insbesondere die Wege von einem Rechner außerhalb des Verbundes zum spezifischen Kubernetes-Cluster (26) werden durch die E2E-Architektur gegen alle Einflüsse abgesichert.
  • Sämtliche Ein- und Ausgangsdaten des Lockstep werden ebenfalls durch die Verletzung des E2E-Vergleichs identifiziert. Somit kann bei kleinen Mengen an Sicherheitsdaten und schnell zu verarbeitenden Echtzeitdaten auf diese beiden Lockstep-Schritte (Eingangsdaten- und Ausgangsdatenvergleich) verzichtet werden.
  • Durch den zeitnahen Vergleich im Lockstep müssen erfindungsgemäß nur Fehler einer Recheneinheit betrachtet, die sich aus Fehlern an deren Befehlssatz ergeben. Eine logische Funktion wie Dividieren, Addieren oder Logarithmieren lässt sich schnell vergleichen und die Menge an Daten, die tatsächlich taktsynchron verglichen werden müssen, signifikant reduzieren. Alternativ kommt eine kodierte Verarbeitung (coded processing) gemäß IEC 61508 in Betracht, im Zuge derer nur die Kodierungen im Lockstep-Verfahren verglichen und die als korrekt bewerteten Daten ohne Verzögerung weitergeleitet werden.
  • 7 zeigt eine mögliche Variante des Verfahrens (10). Insbesondere bei den Ausgängen könnte der Vergleicher (25 - 1) auch zusätzlich die Zeitstempel und somit den Zeitpunkt vergleichen, an dem ihm die Ausgangsdaten (15) zugeführt (17) werden. An dieser Stelle könnte im Falle eines Echtzeitsystems zudem geprüft werden, ob die Daten dem Komparator (25 - 1) rechtzeitig zugeführt (17) werden. Erweisen sich die Daten und deren Kontrollfelder oder Signaturen im Vergleich als inkorrekt, könnte diese verspätete Erkenntnis trotzdem an eine weitere Verrechnungseinheit weitergeleitet und mit einer eindeutigen Signatur versehen (20) werden, die das Ergebnis (24 - 1) als verspätet, aber nicht inhaltlich falsch kennzeichnet. Dieser Hinweis führt in einschlägigen Systemen oftmals zu Degradationen. In Soft-Realtime-Anwendungen könnte ein solches Ergebnis (24 - 1) auch toleriert werden.
  • Die Komparatoren (25 - 1) können auch asynchron sämtliche Merkmale prüfen; so könnten etwa Vergleiche von Daten, Signaturen und Zeitstempeln logisch unterschiedlich abgestuft geprüft werden, sodass erst nach Durchführung aller Vergleiche und Prüfungen das endgültige Ergebnis (24 - 1) auf der höchsten Sicherheitsstufe zeitversetzt versendet wird.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 2019047579 A1 [0002]
    • US 2018370540 A1 [0003]
    • US 2019334706 A1 [0004]

Claims (10)

  1. Verfahren (10) zum Steuern einer Fahrfunktion, gekennzeichnet durch folgende Merkmale: - für die Fahrfunktion relevante Eingangsdaten (11) werden einem Rechnerverbund (26) zugeführt (13), - durch eine redundante Verarbeitung (14) der Eingangsdaten (11) auf mindestens einer ersten Recheneinheit (41) und einer zweiten Recheneinheit (42) im Rechnerverbund (26) werden jeweils Ausgangsdaten (15) erzeugt, - von jeder Recheneinheit (41, 42) werden die jeweiligen Ausgangsdaten (15) um Kontrollfelder ergänzt (16), - die Ausgangsdaten (15) der Recheneinheiten (41, 42) werden einem Vergleich zugeführt (17) und ein Ergebnis (24) des Vergleiches ermittelt (18) und - abhängig vom Ergebnis (24) werden die Ausgangsdaten (15) fallweise mitsamt der jeweiligen Kontrollfelder für die Fahrfunktion herangezogen (19), falls die Ausgangsdaten (15) und Kontrollfelder dem Vergleich standhalten, oder als fehlerhaft markiert (20), falls die Ausgangsdaten (15) oder Kontrollfelder abweichen.
  2. Verfahren (10) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - auch die Eingangsdaten (11) sind mit Kontrollfeldern versehen und - sind die Eingangsdaten (11) und die Kontrollfelder inkonsistent, so werden die Eingangsdaten (11) vor der Verarbeitung (14) verworfen (12).
  3. Verfahren (10) nach Anspruch 1 oder 2, gekennzeichnet durch folgende Merkmale: - auf Anfrage (22) werden die Eingangsdaten (11) durch ein Steuerprogramm (23) auf mehrere Server (31, 32, 33) des Rechnerverbundes (26) verteilt, - jede Recheneinheit (41, 42) wird auf einem der Server (31, 32, 33) betrieben und - das Ergebnis (24) oder ein Fehlschlag des Vergleiches werden dem Steuerprogramm (23) zurückgemeldet.
  4. Verfahren (10) nach Anspruch 3, gekennzeichnet durch folgende Merkmale: - die Recheneinheiten (41, 42) sind Anwendungscontainer (41, 42, 51, 52), - die Verarbeitung (14) der für die Fahrfunktion sicherheitsrelevanten Eingangsdaten (11) und der Vergleich der Ausgangsdaten (15) erfolgen in besonders abgesicherten Containern (51, 52) unter den Anwendungscontainern (41, 42, 51, 52) und - die für die Fahrfunktion nicht sicherheitsrelevanten Ausgangsdaten (15) werden unmittelbar weitergeleitet (21).
  5. Verfahren (10) nach Anspruch 3 oder 4, gekennzeichnet durch folgende Merkmale: - der Rechnerverbund (26) ist ein Kubernetes-Cluster (26), - die Server (31, 32, 33) sind Arbeitsknoten (31, 32, 33, 34) im Cluster (26) mit paarweise replizierten Pods (61, 62, 63), - die erste Recheneinheit (41) ist ein über einen ersten Dienst (71) des Clusters (26) erreichbarer erster Pod (61) unter den Pods (61, 62, 63), - die zweite Recheneinheit (42) ist ein über einen zweiten Dienst (72) des Clusters (26) erreichbarer zweiter Pod (62) unter den Pods (61, 62, 63), - der Vergleich erfolgt auf einem über einen dritten Dienst (73) des Clusters (26) erreichbaren dritten Pod (63) unter den Pods (61, 62, 63) und - die Dienste (71, 72, 73) werden von einem gemeinsamen Eingangspunkt (27) auf einem der Arbeitsknoten (31, 32, 33, 34) synchronisiert.
  6. Verfahren (10) nach Anspruch 5, gekennzeichnet durch folgende Merkmale: - vor der Verarbeitung (14) auf dem ersten Pod (61) und zweiten Pod (62) werden die Eingangsdaten (11) vom Eingangspunkt (27) mit einer übereinstimmenden Kennung versehen (28) und - die dem dritten Pod (63) für den Vergleich zuerst vorliegenden Ausgangsdaten (15) werden in einem Zwischenspeicher abgelegt, bis die zu vergleichenden Ausgangsdaten (15) einander anhand der Kennung zugeordnet werden (29).
  7. Verfahren (10) nach Anspruch 6, gekennzeichnet durch folgende Merkmale: - das Zwischenspeichern der für den Vergleich zuerst vorliegenden Ausgangsdaten (15) wird vom dritten Pod (63) bestätigt (30), - nach dem Vergleich wird der Zwischenspeicher vom dritten Pod freigegeben (35) und - die Anfrage (22) bleibt bis zum Zurückmelden des Ergebnisses (24) durch den dritten Pod (63) anhängig (36).
  8. Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.
  9. Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 8 gespeichert ist.
  10. Vorrichtung (31, 32, 33, 34), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.
DE102021202935.3A 2021-03-25 2021-03-25 Verfahren und Vorrichtung zum Steuern einer Fahrfunktion Pending DE102021202935A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102021202935.3A DE102021202935A1 (de) 2021-03-25 2021-03-25 Verfahren und Vorrichtung zum Steuern einer Fahrfunktion
US17/697,200 US20220308539A1 (en) 2021-03-25 2022-03-17 Method and device for controlling a driving function
CN202210294878.5A CN115129110A (zh) 2021-03-25 2022-03-24 用于控制驾驶功能的方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102021202935.3A DE102021202935A1 (de) 2021-03-25 2021-03-25 Verfahren und Vorrichtung zum Steuern einer Fahrfunktion

Publications (1)

Publication Number Publication Date
DE102021202935A1 true DE102021202935A1 (de) 2022-09-29

Family

ID=83192612

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021202935.3A Pending DE102021202935A1 (de) 2021-03-25 2021-03-25 Verfahren und Vorrichtung zum Steuern einer Fahrfunktion

Country Status (3)

Country Link
US (1) US20220308539A1 (de)
CN (1) CN115129110A (de)
DE (1) DE102021202935A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021211908A1 (de) 2021-10-21 2023-04-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Verarbeiten von Daten

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180370540A1 (en) 2017-06-23 2018-12-27 Nvidia Corporation Method of using a single controller (ecu) for a fault-tolerant/fail-operational self-driving system
US20190047579A1 (en) 2018-03-31 2019-02-14 Intel Corporation Core tightly coupled lockstep for high functional safety
US20190334706A1 (en) 2018-04-27 2019-10-31 Tesla, Inc. Autonomous driving controller encrypted communications

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210302799A1 (en) * 2017-04-26 2021-09-30 View, Inc. Remote management of a facility
US20230113718A1 (en) * 2017-04-26 2023-04-13 View, Inc. Self orchestrating network
US11379254B1 (en) * 2018-11-18 2022-07-05 Pure Storage, Inc. Dynamic configuration of a cloud-based storage system
EP3983894A4 (de) * 2019-06-12 2023-06-21 Arigato Machine, Inc., dba Manifold Prädiktive autoskalierung und ressourcenoptimierung
WO2021194590A1 (en) * 2020-03-25 2021-09-30 Intel Corporation Dynamic contextual road occupancy map perception for vulnerable road user safety in intelligent transportation systems
US20220237414A1 (en) * 2021-01-26 2022-07-28 Nvidia Corporation Confidence generation using a neural network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180370540A1 (en) 2017-06-23 2018-12-27 Nvidia Corporation Method of using a single controller (ecu) for a fault-tolerant/fail-operational self-driving system
US20190047579A1 (en) 2018-03-31 2019-02-14 Intel Corporation Core tightly coupled lockstep for high functional safety
US20190334706A1 (en) 2018-04-27 2019-10-31 Tesla, Inc. Autonomous driving controller encrypted communications

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021211908A1 (de) 2021-10-21 2023-04-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Verarbeiten von Daten

Also Published As

Publication number Publication date
CN115129110A (zh) 2022-09-30
US20220308539A1 (en) 2022-09-29

Similar Documents

Publication Publication Date Title
EP2641176B1 (de) Mikroprozessorsystem mit fehlertoleranter architektur
EP2513796B1 (de) Verfahren zum betreiben einer recheneinheit
DE102014201682A1 (de) Verfahren zur Koexistenz von Software mit verschiedenen Sicherheitsstufen in einem Multicore-Prozessorsystem
EP3211533A1 (de) Fehlertolerante systemarchitektur zur steuerung einer physikalischen anlage, insbesondere einer maschine oder eines kraftfahrzeugs
DE102016206630A1 (de) Verfahren und Vorrichtung zur Vermeidung von Manipulation einer Datenübertragung
EP1401690A1 (de) Verfahren zur ansteuerung einer komponente eines verteilten sicherheitsrelevanten systems
EP1043641A2 (de) Fehlersicheres Automatisierungssystem mit Standard-CPU und Verfahren für ein fehlersicheres Automatisierungssystem
EP1358554A1 (de) Automatische inbetriebnahme eines clustersystems nach einem heilbaren fehler
DE102021202935A1 (de) Verfahren und Vorrichtung zum Steuern einer Fahrfunktion
DE102021211908A1 (de) Verfahren zum Verarbeiten von Daten
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
EP1640869A2 (de) Verfahren zur Durchführung eines Votings von redundanten Informationen
DE102015218898A1 (de) Verfahren zur redundanten Verarbeitung von Daten
DE102015218890A1 (de) Verfahren und Vorrichtung zum Generieren eines Ausgangsdatenstroms
WO2022084176A1 (de) Datenverarbeitungsnetzwerk zur datenverarbeitung
DE102004051966A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
DE102015218882A1 (de) Verfahren und Vorrichtung zum Prüfen von Berechnungsergebnissen in einem System mit mehreren Recheneinheiten
DE102021208459A1 (de) Verfahren zur authentischen Datenübertragung zwischen Steuergeräten eines Fahrzeugs, Anordnung mit Steuergeräten, Computerprogramm und Fahrzeug
DE102013202961A1 (de) Verfahren zum Überwachen eines Stackspeichers in einem Betriebssystem eines Steuergeräts eines Kraftfahrzeuges
DE69911255T2 (de) Mikroprozessormodul mit abstimmungseinrichtung zur rückstellung und verfahren dazu
WO2002071223A1 (de) Fehlertolerante rechneranordnung und verfahren zum betrieb einer derartigen anordnung
DE102021127310B4 (de) System und Verfahren zur Datenübertragung
DE102013202482A1 (de) Fehlersignalbehandlungseinheit, Gerät und Methode zur Ausgabe eines Fehlerzustandssignals
DE102022210020A1 (de) Sicherheitsdatenverarbeitungseinheit für eine Recheneinheit
DE102021209038A1 (de) Verfahren zum automatischen Erkennen und Korrigieren von Speicherfehlern in einem sicheren mehrkanaligen Rechner