Softwarearchitektur für die funktionale Sicherheit intelligenter Autos

01 Idee der E-GAS-Sicherheitsarchitektur

Funktionale Sicherheit im Automobilbereich zielt darauf ab, das Risiko von Personenschäden durch den Ausfall elektronischer und elektrischer Systeme in einem angemessenen Rahmen zu halten. Die folgende Abbildung ist ein allgemeines Hardware-Zusammensetzungsdiagramm für elektronische und elektrische Systeme. Zu den Komponenten eines elektronischen und elektrischen Systems gehört neben der in der Abbildung sichtbaren Hardware auch Software, die in der Abbildung nicht sichtbar ist.

Abbildung 1 Häufig verwendete elektronische und elektrische Hardwaresysteme

Ausfälle elektronischer und elektrischer Systeme umfassen sowohl Systemausfälle, die durch Software- und Hardware-Designfehler verursacht werden, als auch Ausfälle, die durch zufällige Hardwareausfälle verursacht werden. . Je nach Systemarchitektur müssen verschiedene Sicherheitsmechanismen entwickelt werden, um Funktionsausfälle zu verhindern und zu erkennen und um im Fehlerfall Schäden zu vermeiden oder zu reduzieren. Dies erfordert eine starke Softwarearchitektur für funktionale Sicherheit, um diese Sicherheitsmechanismen zu verwalten und zu steuern und die allgemeine Entwicklungsschwierigkeit der funktionalen Sicherheit zu verringern.

Derzeit ist E-GAS (Standardisiertes E-Gas-Überwachungskonzept für Benzin- und Dieselmotorsteuergeräte) zweifellos die am weitesten verbreitete Architekturlösung für Sicherheitssoftware. Obwohl E-GAS ursprünglich als Sicherheitsarchitekturlösung für Managementsysteme für Benzin-/Dieselmotoren vorgeschlagen wurde, kann es nach einfacher Anpassung auch sehr gut in Karosseriesystemen, Getriebesystemen und neuen Energie-Drei-Elektro-Systemen usw. eingesetzt werden Erweiterbar und weit verbreitet.

Das Bild unten zeigt das dreischichtige Softwarearchitekturdesign von E-GAS. Von oben nach unten ist die Software in Level 1 bis 3 unterteilt. Level 1 ist die Funktionsimplementierungsschicht (Funktionsebene). und Level2 ist die Funktionsüberwachungsebene (Funktionsüberwachungsebene), Level3 ist die Controller-Überwachungsebene. Diese Architektur bildet ein gutes mehrschichtiges Überwachungsgerüst und implementiert effektiv die Sicherheitszerlegungsstrategie von QM (ASIL X) + ASIL X (ASIL X), dh die Funktionsimplementierungssoftware (Level 1) wird entsprechend entwickelt Auf der QM-Ebene werden funktionale redundante Software oder Sicherheitsmaßnahmen (Level 2, Level 3) gemäß der höchsten Anforderungsstufe ASIL X (ASIL X) entwickelt, wodurch die Sicherheitsentwicklungskosten funktionaler Software wirksam gesenkt werden können.

Abbildung 2 Schema der E-GAS-Überwachungsarchitektur mit drei Schichten vervollständigt die Detailfunktion Implementierung, z. B. Für die Motorsteuerung wandelt diese Schicht das angeforderte Drehmoment in die Drehmomentabgabe des Motors um.

Level2-Funktionsüberwachungsschicht

Level2 ist die Funktionsüberwachungsschicht, mit der überwacht wird, ob die Level1-Funktion normal ausgeführt wird. Der Kern von Level2 besteht darin, eine Methode zu entwerfen, um festzustellen, ob Level1 normal ausgeführt wird. Obwohl die Methode zur Beurteilung, ob Level1 normal läuft, häufig mit der überwachten Funktion zusammenhängt, verfügen verschiedene überwachte Funktionen über unterschiedliche Beurteilungsmethoden, beispielsweise durch Software-Diversifizierung und Redundanz. Es gibt jedoch auch einige Beurteilungsmethoden mit breiterer Anwendung, wie beispielsweise die Rationalitätsprüfung.

Abbildung 3 Plausibilitätsprüfung

Wie in der Abbildung oben gezeigt, berechnet Level2 zunächst die Steuerung anhand der Plausibilitätsprüfungsmethode, um festzustellen, ob die Level1-Funktion normal funktioniert Der vom Sensor eingegebene Signalausgang liegt innerhalb des zulässigen Bereichs. Anschließend wird der vom Aktuator zurückgekoppelte tatsächliche Ausgang berechnet und schließlich festgestellt, ob der tatsächliche Ausgang von Level 1 innerhalb des zulässigen angemessenen Bereichs liegt Wenn der Wert außerhalb des angemessenen Bereichs liegt, wird festgestellt, dass die Funktion der Ebene 1 abnormal ist, und es wird eine Fehlerbehandlung durchgeführt.

Level3 Controller-Überwachungsschicht

Level3 ist die Controller-Überwachungsschicht, die hauptsächlich aus drei Funktionen besteht.

Hardwarediagnose elektronischer und elektrischer Systeme: Überwachen Sie Hardwarefehler elektronischer und elektrischer Systeme, z. B. CPU-Kernfehler des Controllers, RAM-Fehler, ROM-Fehler usw.

Unabhängige Überwachung: Nach Auftreten eines Controller-bezogenen Fehlers kann der Controller die sicherheitsrelevante Logik nicht mehr zuverlässig ausführen. Um die Sicherheit zu gewährleisten, ist ein zusätzliches externes unabhängiges Überwachungsmodul erforderlich, um dies auch nach einem schwerwiegenden MCU-Ausfall sicherzustellen , Es ist immer noch möglich, in einen sicheren Zustand zu gelangen. Bei diesem zusätzlichen unabhängigen Überwachungsmodul handelt es sich in der Regel um einen Power-Management-Chip mit integriertem Watchdog.

Anwendungsflussprüfung: Überwachen Sie, ob die Überwachungsprogramme von Level1 und Level2 normal laufen. Diese Überwachungsfunktion wird durch verbindliche Programmflussprüfung und Watchdog-Einspeisung implementiert. Wenn die Überwachungsprogramme für Level1 und Level2 nicht in der festgelegten Reihenfolge oder nicht innerhalb der angegebenen Zeit ausgeführt werden, schlägt die Programmablaufprüfung fehl und der Hund kann nicht normal gefüttert werden, sodass er in den Systemsicherheitszustand übergeht. ?? Architektur, die der funktionalen Sicherheit entspricht“ „ und „Softwarearchitektur für funktionale Sicherheit“, um die Beziehung zwischen ihnen zu untersuchen.

Ersteres konzentriert sich auf die Übereinstimmung unseres Softwarearchitektur-Designprozesses mit der funktionalen Sicherheit aus Sicht der Softwareentwicklung, d. h. unser Softwarearchitektur-Designprozess muss die verschiedenen Anforderungen der ISO 26262 erfüllen, wie zum Beispiel: Markierungsmethoden , Entwurfsprinzipien, Anforderungen an Entwurfselemente, Anforderungen an die Sicherheitsanalyse, Anforderungen an Fehlererkennungsmechanismen, Fehlerbehandlungsmechanismen und Entwurfsüberprüfungsmethoden usw. Zu den gängigsten Methoden der Sicherheitsanalyse auf der Ebene der Softwarearchitektur gehören „Software-FMEA“ (Fehlermöglichkeit und -effekte). Analyse)“ und „Software DFA“ (Dependent Failure Analysis)“.

Letzteres konzentriert sich auf die Unterstützung der funktionalen Sicherheit auf Systemebene aus der Sicht eingebetteter Softwaresysteme. Basierend auf der Idee der E-Gas-Sicherheitsarchitektur glauben wir, dass „geschichtete Überwachungsideen“, „Sicherheitsmaßnahmen“ und „Diagnoserahmen“ den Kern der „funktionalen Sicherheitssoftwarearchitektur“ bilden und „geschichtete Überwachungsideen“ und „ Sicherheitsmaßnahmen“ sind oben aufgeführt. Wie im Artikel erwähnt, konzentriert sich der Rest dieses Abschnitts hauptsächlich auf den „Diagnoserahmen“. Unabhängig davon, ob die grundlegende Softwareentwicklungsplattform, die wir verwenden, AUTOSAR CP, AP oder Nicht-AUTOSAR ist, sind die Designideen der Softwarearchitektur für funktionale Sicherheit ähnlich und werden hier basierend auf AUTOSAR CP erläutert. 1) Technische Anforderungen des Funktionssicherheitsdiagnoserahmens tolerant Zeitintervall), um den Fehlerdiagnoseprozess zu verstehen. Der Zeitraum vom Auftreten eines Fehlers bis zum Auftreten möglicher Gefahren ist die FTTI-Zeit. In diesem Zeitraum gibt es hauptsächlich Diagnosetests, Fehlerreaktionsprozesse und die Hoffnung, in einen sicheren Zustand zu gelangen, bevor mögliche Gefahren auftreten (Abbildung 4.1-8). ). Der Diagnosetestprozess muss die Auslösung von Diagnosetests, die Fehlerbestätigung (Entprellung) usw. berücksichtigen. Der Fehlerreaktionsprozess muss die Eingabe eines angemessenen Betriebsmodus (z. B. Fail Safe, Fail Operational, Notbetrieb usw.) und Fehlerspeicherung berücksichtigen , usw. Zusammenfassend lässt sich sagen, dass das Kerndesign des „Diagnose-Frameworks“ die Abdeckung von Diagnosetests und Fehlerreaktionsprozessen berücksichtigen muss. Die wichtigsten technischen Anforderungen für den Diagnoserahmen für die funktionale Sicherheit sind:

• Einheitliches Fehlermanagement: Einheitliches Statusmanagement der von jeder Fehlerüberwachungsschicht des mehrschichtigen E-GAS-Überwachungsrahmens gemeldeten Fehler.
• Anforderungen an die Fehlerreaktionszeit: Das Fehlertoleranzzeitintervall (FTTI) muss ab dem Fehler eingehalten werden (Erkennung bis zum Eintritt in einen sicheren Zustand) Anforderungen
• Unabhängigkeitsanforderungen: Es gibt gemeinsame Ursachenprobleme zwischen On-Chip-Sicherheitsmechanismen und -funktionen, und unabhängige Überwachung (MCU-Off-Chip-Überwachung) muss unterstützt werden
• Verschiedene Anforderungen: Die Softwarearchitektur muss der Verallgemeinerung und Unterstützung des Framework-Designs entsprechen. Diversifizierte Sicherheitsstrategien (verschiedene Projekte haben unterschiedliche Anforderungen an Sicherheitsmechanismen)
• Diagnosetest-Timing: Ein- und Ausschalten, Zyklus, Bedingungsauslöser usw.
• Fehlerentprellungs-/Verzögerungsprüfung: Entprelltests der Sicherheitsmechanismen müssen unterstützt werden. Funktion, zumindest zeit- und zählbasierte Entprellalgorithmen unterstützen
• Entkopplung von Diagnoseereignissen und -funktionen: Diagnoseereignisse und -funktionen werden unabhängig verwaltet, und das ist so eine Zuordnungsbeziehung zwischen ihnen. Fehlerspeicher: Unterstützt die nichtflüchtige Speicherung von Fehlerinformationen als Referenz.
• ① Vorschlag 1: Bestimmen Sie den Zeitpunkt der Diagnosetests je nach Bedarf

a Beim Einschalten: Hier ist eine Erklärung basierend auf einer typischen Anwendungsanforderung. Der Sicherheitsmechanismus und die entsprechenden Funktionen bilden einen Doppelpunkt. Um die Ausfallrate latenter Mehrpunktfehler zu reduzieren, muss der Sicherheitsmechanismus im Allgemeinen während der Systemstartphase (beim Einschalten) eine Selbstprüfung durchführen. Darüber hinaus müssen in Multiprozessorsystemen Probleme mit der Synchronisierung von Diagnosetests berücksichtigt werden. b. Laufzeit: Im Allgemeinen unterteilt in periodische Diagnosetests und bedingte Diagnosetests. Bei der Definition des Diagnosezyklus müssen die Einschränkungen von FDTI (Fehlererkennungszeitintervall) berücksichtigt werden, und bedingte Diagnosetests sind im Allgemeinen Diagnosen einer Funktion, wenn ein Zustandsübergang auftritt oder bevor eine Funktion aktiviert wird.

c Beim Ausschalten: Sie können einige zeitaufwändige Tests durchführen und die Testergebnisse werden im Allgemeinen beim nächsten Start verarbeitet.

② Empfehlung 2: Gruppendiagnosetests durchführen

Um das Diagnosemanagement (einschließlich Diagnoseauslösung und Fehlerreaktion usw.) zu erleichtern, gruppieren Sie sie nach kritischen Fehlern/nicht kritischen Fehlern, Diagnosetestzeitpunkt usw andere Faktoren. Wenn beim Einschalten ein kritischer Fehler erkannt wird, z. B. ein Kernfehler, ein Ram-Testfehler usw., kann die Fehlerreaktion in einem stillen Zustand verarbeitet werden (z. B.: MCU befindet sich im kontinuierlichen Reset-Zustand).

Abbildung 6 „Functional Safety Diagnosis Framework“ und „Functional Safety Diagnosis Control Flow“

Dreischichtiges E-Gas-Überwachungsframework Level1 (Funktionsebene) und Level2 (Funktionsüberwachungsebene). ) befindet sich auf der ASW-Ebene (Anwendungssoftware, d. h. SWC in Abbildung 4.1-9), und Level3 (Controller-Überwachungsebene) befindet sich auf der BSW-Ebene (Basissoftware). Das „Diagnostic Framework“ befindet sich ebenfalls auf der BSW-Ebene und deckt hauptsächlich Diagnosetests und Fehlerreaktionsprozesse ab. Seine Zusammensetzung und sein Arbeitsablauf werden im Folgenden vorgestellt:

• BswM und EcuM sind hauptsächlich für das Ein- und Ausschaltmanagement verantwortlich und führen Diagnosetests während des Einschaltens, der Laufzeit und des Ausschaltens in den Phasen STARTUP, UP und SHUTDOWN durch
• Die Eingabe-/Ausgabediagnose der Abdeckungsfunktion ASW-Level1 (E-Gas Level1); TestLib (E-GasLevel3) überwacht Hardwarefehler auf der ECU- und MCU-Ebene (es wird empfohlen, sich auf ISO26262(2018)-Teil5 Anhang D und das MCU-Sicherheitshandbuch zu beziehen) und deckt die Diagnose von Level1- und Level2-Fehlern mit gemeinsamer Ursache sowie die Implementierung ab Frage- und Antwort-Watchdog-Mechanismus für logik- und zeitunabhängige Diagnose mit dem „Überwachungscontroller“
• TestManager ist für das Auslösen von Diagnosetests des TestLib-Sicherheitsmechanismus und das Sammeln entsprechender Testergebnisse verantwortlich
• DEM sammelt Testergebnisse von E- Gas Level1/2/3, entprellt Diagnoseereignisse, markiert Fehlercodes und stellt Fehlerinformationen über NvM-Speicher bereit. FiM markiert die konfigurierten Funktionen basierend auf den DEM-Diagnosetestergebnissen (nach der Entprellung), und die Funktionssoftware (ASW-Level1) bestimmt die Unterdrückung der Funktionen basierend auf den Markierungen.

Das obige ist der detaillierte Inhalt vonSoftwarearchitektur für die funktionale Sicherheit intelligenter Autos. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!