Systemarchitektur (in Praxis)

In den folgenden Abschnitten werden Methoden für Systems Engineering und die Entwicklung von Systemarchitektur beschrieben.

*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.

*2) Nummern in eckigen Klammern z. B. [5] sind die Quellenangaben.

In den folgenden Abschnitten werden die Ansätze und Methoden für das System-Engineering und die Entwicklung der Systemarchitektur gezeigt.

Diese Methoden können von den idealerweise optimalen Methoden abweichen, wenn die Umgebungsbedingungen, Möglichkeiten und Ziele des Entwicklungsteams sowie letztlich des zu entwickelnden Produkts zu schnelleren und effizienteren Prozessen führen.

Die Auswertungen und Analysen sind zwar methodologisch korrekt, aber nicht vollständig und, wie das Beispiel der HARA-Auswertung zeigt, absichtlich modifiziert (hier z. B. um das Thema: Funktionale Sicherheit anzusprechen).

Die Systemarchitektur wird aus Anforderungen abgeleitet. In den folgenden Abschnitten wird die Funktion eines Fensterheber-ECU beschrieben, die theoretisch in einem Fahrzeug implementiert werden kann. Dabei beschreibt die Funktion nicht alle Anforderungen und enthält nur rudimentäre Systemelemente ohne Details wie Diagnoseinformationen, Updates etc.

Das Fensterheber-ECU (Elektronisches Steuergerät) steuert die Bewegung des Fahrzeugfensters, damit Fahrzeuginsassen das Fenster durch Drücken einer Taste heben oder senken können. Das elektronische Steuergerät überwacht die Schalter für Fahrer- oder Beifahrereingaben, treibt den Fensterhebermotor an und stoppt die Bewegung, sobald das Fenster vollständig geöffnet oder geschlossen ist oder ein anderes Kommando vom Bediener erfolgt.

Das Steuergerät muss zudem Hindernisse erkennen, beispielsweise eine Hand oder einen Fremdkörper, den Fenstermotor anhalten und das Fenster um 15 cm nach unten bewegen, um Verletzungen oder Schäden zu verhindern.

Der Abstand zwischen der Unterkante der Fensteröffnung und der Oberkante beträgt 40 cm. Die Fensterbewegungsgeschwindigkeit soll 10 cm/s betragen.

Die Fensterhebersoftware soll mittels CAN Unified Diagnostic Services (UDS) flashbar sein und Diagnosen unterstützen (dieser Aspekt ist nicht im Fokus dieses Artikels).

Außerdem benötigt ein richtiges Steuergerät die Speicherung von Daten in einem nichtflüchtigen Speicher. Solche Daten wie Parameter, interne Variablen, Fehlerzustände etc. können gespeichert werden (dieser Aspekt ist nicht im Fokus dieses Artikels).

Zusammengefasst umfasst die Fensterheber-ECU-Elektronik, den Motortreiber, Sensoren zur Fensterpositionsbestimmung (möglicherweise Hallsensoren oder Strommessungen) und Kommunikationsschnittstellen zu anderen Steuergeräten über CAN oder LIN. Die Software steuert den Fensterlauf, detektiert die Hindernisse und überwacht den Steuergerätebetrieb.

Eine Anleitung, wie die Systemanforderungen formuliert werden, findet sich in diesem Artikel finden: Anforderungsmanagement-Methode nach dem “Strict Decomposition (SDEC)”-Prinzip.

Teilweise sind die Systemanforderungen (SYS.2) bereits vorhanden.

Nachdem die Systemanforderungen weitestgehend geklärt sind, kann parallel zur weiteren Verfeinerung der Anforderungen mit der Machbarkeitsstudie gestartet werden. Entsprechend den Vorgaben werden die erforderlichen Systemkomponenten – etwa Mikrocontroller, ICs und weitere Bauteile – untersucht und aus der am Markt verfügbaren Vielfalt ausgesucht.

Um eine allgemeine Vorstellung davon zu erhalten, wie ein solches System aufgebaut sein kann, erstellen wir eine High-Level-Systemarchitektur, in der zunächst eine mögliche Realisierung skizziert wird – ohne dabei ins Detail zu gehen, was die einzelnen Systemkomponenten und Architekturentscheidungen betrifft. Diese High-Level-Systemarchitektur wird im Laufe des Projekts kontinuierlich weiterentwickelt. Im weiteren Verlauf erkläre ich, wie dies in der Praxis umgesetzt wird.

Auf dem vereinfachten Diagramm kann man die zentralen Komponenten eines theoretischen Fensterheber-ECU erkennen. Diese Darstellung ist bewusst vereinfacht und enthält noch keine detaillierte Aufteilung in verschiedene Disziplinen. So besteht der Fenstermotor aus einem Hardware- sowie einem mechanischen Anteil, während der Mikrocontroller sowohl einen Hardware- als auch einen Softwareanteil umfasst.

Des Weiteren zeigt dieses Diagramm nicht sämtliche Verbindungen und Module, sondern bietet lediglich eine vereinfachte Übersicht. Um den Rahmen dieses Artikels nicht zu sprengen, werden im Folgenden lediglich ausgewählte Komponenten und ihre Wechselwirkungen behandelt.

Angenommen, das Bedienfeld für die Fensteransteuerungstasten sowie der Fenstermotor inklusive Getriebe werden von einem anderen Lieferanten entwickelt, so verbleibt für uns die Steuerelektronik.

Aufteilung in Untersysteme

Es erscheint sinnvoll, das gesamte System in zwei Untersysteme aufzuteilen, aus folgenden Gründen:

• Mehr Flexibilität in Abmessungen:
  • Mehr Flexibilität hinsichtlich der Abmessungen:
    In einer Fahrzeugtür herrscht meist Platzknappheit, weshalb zwei kleinere Gehäuse einfacher unterzubringen sind als ein großes.
• Modularität:
  • Das Haupt-PCB (H_PCB) gewährleistet einen reibungslosen Ablauf von Diagnosefunktionen und der Kommunikation mit dem Fahrzeug, während das Fenstermotorsteuerungs-PCB (FMS_PCB) die DC-Motorsteuerung übernimmt.
• Wartbarkeit und Wiederverwendbarkeit:
  • Während die DC-Motorsteuerung über einen langen Zeitraum ihre Funktionalität beibehält, können sich die Anforderungen an die Fahrzeugarchitektur häufiger ändern. Das FMS_PCB bleibt jedoch konstant, was Entwicklungs- und Testaufwände reduziert.

Die zwei Untersysteme können folgendermaßen aussehen: ein Haupt-PCB (H_PCB) und ein Fenstermotor-PCB (FMS_PCB).

Im weiteren Verlauf werden wir uns mit dem FMS_PCB auseinandersetzen.

Wir gehen nun zur Auswahl der Systemkomponenten. In diesem Schritt werden gemäß den Anforderungen die Hardware-Komponenten ausgesucht. Hier finden sich Systemkomponenten, welche speziell für FSM_PCB bestimmt sind.

In der folgenden Liste sind die Komponenten aufgeführt, die aus technischer Sicht geeignet wären, um das FMS_PCB sowie den DC-Motor zu realisieren:

Hier ist ersichtlich, dass der PWM-Motor-Treiber TLE7182EM während der Recherche aus der Liste ausgeschlossen wurde, da der Mikrocontroller TLE9879QXA40 bereits über einen integrierten H‑Brücken‑Treiber verfügt.

Außerdem wird kein externer Watchdog mehr benötigt, da der Mikrocontroller über einen Hardware‑Watchdog verfügt, der mit einer separaten Taktung ausgestattet ist (siehe [10], Kapitel 5.4).

Die Schnittstellen des ECU bestimmen die Betriebsumgebung und damit den Betriebskontext, in dem das ECU betrieben werden soll. Das Fensterheber-ECU wird über eine 12-V-Batterie mit Strom versorgt. Die auf dem Mikrocontroller laufende Software tauscht die Statusinformationen, Fensterposition, das aktuelle Kommando sowie weitere Signale über das CAN-Netzwerk mit anderen ECUs aus.

Die beiden Subsysteme (H_PCB und FMS_PCB) tauschen Informationen mittels einer LIN-Verbindung aus.

Schnittstellen nach außen:

CAN-Signale:

• CAN_WindState
  • Aktueller Status des Fahrzeugfensters an das BCM ECU
• Stromversorgung: 12 V-Batterie

Schnittstellen zwischen PCBs:

LIN-Signale:

• Nachricht: H_PCB_ComReq, Signal: UsrCmd
  • Kommando vom Bedienfeld
    • Sender: H_PCB; Empfänger: FMS_PCB
• Nachricht: FMS_PCB_Response, Signal: WindState
  • Aktueller Status vom Fahrzeugfenster
    • Sender: FMS_PCB; Empfänger: H_PCB

Die SICI-Bus-Kommunikation wird für die Kommunikation zwischen dem Mikrocontroller und dem Stromsensor TLI4971 verwendet.

Ein wichtiger Bestandteil der Systementwicklung und Systemarchitektur ist die funktionale Dekomposition, basiert auf den Systemanforderungen. Nachdem die Anforderungen umfassend analysiert sind, werden die funktionalen Gruppen in Software, Hardware und Mechanik gebildet. In diesem Beispiel wird die Mechanik nicht berücksichtigt, da sie nicht im Fokus dieses Dokumentes steht.

In unserem Beispiel vom Fensterheber-ECU können wir folgende Funktionen auf Systemebene bündeln:

• UserSignCtrl:
  • Funktion für die Verarbeitung von Benutzersignalen wie Schalter und Tasten.
• WindowCtrl:
  • Funktion für die Steuerung des Fenstermotors.
• AntiPinchCtrl:
  • Funktion zum Einklemmschutz.
• DiagCtrl:
  • Fehlerbehandlung (aber nicht die Reaktion) und Diagnose.
• CANCntrl:
  • Funktion zur CAN-Kommunikation.
• LINCntrl:
  • Funktion zur LIN-Kommunikation.

Die untenstehende Tabelle zeigt die Systemfunktionen und dazugehörigen Software- und Hardwarefunktionen mit kurzer Beschreibung.

Dadurch, dass das Gesamtsystem Fensterheber-ECU in zwei Untersysteme unterteilt ist, müssen die einzelnen Funktionen auch den jeweiligen Teilsystemen zugeordnet werden. Als Beispiel kann man Funktionen: UserSignCtrl und AntiPinchCtrl nehmen. Die Funktion UserSignCtrl wird sowohl auf dem Haupt-PCB (H_PCB) als auch auf dem Fenstermotorsteuerung-PCB (FMS_PCB) (siehe Diagramm: Fensterheber ECU) ausgeführt.

Die Funktion AntiPinchCtrl wird hingegen ausschließlich auf dem FMS_PCB ausgeführt. Somit ergeben sich folgende Funktionen:

Auf dem Blockdiagramm unten sind die Systemkomponenten den entsprechenden Funktionen zugeordnet. Das unterstützt den weiteren Entwicklungsvorlauf, indem sichergestellt wird, dass die Funktionen exakt an den vorgesehenen Stellen umgesetzt werden.

Darüber hinaus erleichtert die Übersicht der Systemarchitektur die präzise Beschreibung der Funktionen.

Aktuell liegt das FMS_PCB im Fokus der Dokumentation unten. Wir betrachten das FMS_PCB als ein eigenständiges System.

In den folgenden zwei Absätzen werden Beispiele für statische und dynamische Aspekte aus ASPICE: “SYS.3 System Architectural Design” sowie die entsprechenden Anforderungen für ein System gemäß ISO 26262 dargestellt.

Im unten stehenden Diagramm ist die statische Ansicht der FMS_PCB-Systemarchitektur dargestellt. Alle Hardware- und Softwaresystemkomponenten sowie ihre Schnittstellen sind hier ersichtlich. Der Softwareanteil (Software-Funktionen) ist dem Mikrocontroller TLE9879QXA40 zugeordnet.

Damit sind zwar die Anforderungen für statische Aspekte aus ASPICE nicht vollständig abgedeckt, lässt sich jedoch relativ leicht aus den oben dargestellten Daten und diesem Diagramm ableiten.

Das Diagramm berücksichtigt jedoch nicht die Aspekte der funktionalen Sicherheit und Cybersecurity; dazu wird später noch mehr erläutert.

Um das dynamische Verhalten in der FMS_PCB-Systemarchitektur vollständig abzudecken, wird der Umfang dieses Dokumentes definitiv nicht ausreichen. Hier konzentrieren wir uns auf die Funktion zur “Hinderniserkennung”. Obwohl die Hinderniserkennungsfunktion sich hauptsächlich aus Untersuchung der HARA (Hazard and Risk Analysis), siehe unten: ISO 26262 Funktionale Sicherheit – HARA (Hazard and Risk Analysis) [2] ergibt, möchte ich diese Funktion hier beschreiben, weil sie eine der wichtigsten Funktionen im Steuergerät hinsichtlich der Funktionalen Sicherheit ist.

In diesem Diagramm gibt es keine Beschreibung für Power-States des FMS_PCB, daher wird hier angenommen, dass FMS_PCB schon mit Strom versorgt, aktiviert (wach) ist und sich im “normal mode” befindet. Das “normal mode” ist ein Zustand, bei dem:

• eine LIN-Kommunikation möglich ist,
• Kommandos vom Benutzer erkannt und umgesetzt werden,
• keine Fehler am FMS_PCB vorhanden,
• alle sonstigen Funktionen sind voll funktionsfähig.

Die Kommunikation zwischen den Systemelementen verläuft asynchron, während synchrone Vorgänge nur innerhalb einer Komponente stattfinden.

Die Diagnosekopplungen (z. B. aktueller Zustand des H-Bridge) für das Auslesen der Elementenzustände sind hier nicht berücksichtigt.

Im Prinzip gibt es drei unterschiedliche Interaktionsarten im System:

• mittels Software-Signalen (z. B. LIN, HSI-Ansteuerung etc.)
• mittels elektrischer Signale (z. B. PWM-Ansteuerung vom DC-Motor)
• mittels mechanischer Kräfte (z. B. Getriebeübersetzung vom DC-Motor)

Die hier kurz angesprochenen statischen und dynamischen Aspekte des Systems-Engineerings sind zwar nicht vollständig. Auf Basis dieser Informationen kann jedoch relativ leicht jede Funktion umgesetzt werden. Es gibt allerdings noch einige Themen, die hier vollständig ausgelassen wurden, aber für das Systems-Engineering wesentlich sind.

Hier sind einige Punkte, welche zum System-Engineering gehören:

• Performance-Anforderungen (max. RAM, max. ROM, max. CPU-Load)
• Anforderungen für die Umgebungsbedienung während des Produktlebenszyklus, für Produktion, Wartung und Stilllegung
• Anforderungen für die Wiederverwendbarkeit im Produkt
  • “proven-in-concept”
  • “make-or-buy”
  • Vor- und/oder Nachteile von diesen Ansätzen

• Anforderungen für die Laufzeiten von CPU und Bussystemen
• Bewertung von alternativen Ansätzen
• Produktionsdaten (Teilenummer, Firmware-Update, Kalibrierung, Parametrierung, Authentifizierung)
• auch möglich: Fertigungsprozesse wie Bestückungsrichtlinien, Lötverfahren, Prüfpunkte
• Prozessunterstützung für Produktionsanlagen: automatisierter Flashprozess, Testsysteme, Inbetriebnahme, Zusammenbau

Ein wichtiger Punkt sind auch die ausgelassenen Einschränkungen, die aus Umweltbedingungen resultieren. Z. B. sollte experimentell ermittelt werden, welchen Einfluss Temperatur und Alterung auf die Gummidichtung des Fensters haben. Es kann sein, dass die Parametrierung (oder Kalibrierung) des Steuergeräts diese Temperatureinflüsse und Alterungseffekte berücksichtigen muss.

Das Hardware-Software-Interface (HSI) dient als Schnittstellendefinition zwischen Software und Hardware. Es stellt ein zentrales Element der Softwarearchitektur dar. Ein Beispiel hierfür wäre ein analog-digitaler Pin am Mikrocontroller und die Softwarefunktion (oder das Signal), welches diesen Pin steuert oder ausliest.

Folgende Attribute können an der Stelle berücksichtigt werden:

• Req-ID: einzigartige Objekt-ID
• Signalname: Name eines Signals
• µC-Pin: Markierung eines Pins am Mikrocontroller
• SW-Sig: Name eines SW-Signals
• Funktion: Name der zugeordneten Funktion
• Port_Typ: Typ des Ports: GPIO, ADC, LIN
• Sig_Richt: Signalrichtung: Input, Output
• Status: draft, in_progress, done, approved
• ASIL: QM, ASIL B
• WB: Wertebereich: z. B. 0..120
• Timing: Update-Zeit
• etc.

Die Tabelle enthält nicht die Beschreibung für die LIN- und SICI-Kommunikationsmatrix. Des Weiteren fehlt die Beschreibung des Start-Up- und Go-to-Sleep-Verhaltens sowie andere Leistungsmodi.

Der Standard ASPICE fordert eine gründliche Dokumentation von Anforderungen, Designelementen, Verifikationsaktivitäten und eine kontinuierliche Prozessverbesserung. Der Standard ISO 26262 verlangt von der Entwicklung, die funktionale Sicherheit systematisch zu durchdenken und umzusetzen. Das Ziel von ISO 26262 ist es, Verletzungen von Personen sowie Sachschäden zu verhindern, indem Mechanismen geschaffen werden, die Situationen vermeiden, in denen Hardware- oder Softwarefehler zu gefährlichen Personenverletzungen oder größeren Sachschäden führen können.

Im Fall des Fensterheber-ECU kann ein Fenster menschliche Körperteile einklemmen und somit zu Verletzungen führen.

Nachdem die Systemanalyse durchgeführt und die Systemgrenzen definiert wurden, erstellen die Safety Engineers zusammen mit dem Entwicklungsteam eine HARA (Hazard Analysis & Risk Assessment)-Dokumentation. Danach wird ein bestimmtes ASIL (Automotive Safety Integrity Level) für das Steuergerät zugeordnet. Es werden die FSRs (Functional Safety Requirements) definiert und abschließend das TSC (Technical Safety Concept)-Dokument erstellt.

An dieser Stelle möchte ich einen Teil der HARA-Analyse erläutern, und zwar das Hazard Identification (Identifikation der Gefährdungen). Das Hazard Identification ist der wichtigste Bestandteil der HARA-Analyse, aus der die Safety Goals sowie die Functional Safety Requirements (FSRs) abgeleitet werden. Die HARA-Analyse spielt eine zentrale Rolle während der Entwicklung der Systemarchitektur.

Auf der Tabelle unten sind die Teilergebnisse der HARA aufgeführt.

Hier sind die Gefährdungen zusammengefasst, welche potenzielle theoretische Risiken darstellen können. Anhand der aktuellen Systemarchitektur haben wir entschieden, dass die Anti-Pinch-Funktion komplett autark auf dem FMS_PCB-Mikrocontroller implementiert wird. Die Gefährdungen (G2), (G3) und (G4) sind als nicht relevant einzustufen, da das Fehlverhalten dort nicht zu einer Verletzung führen kann.

Sie werden jedoch in der HARA-Auswertung erwähnt, da ISO 26262 die vollständige Analyse der Gefährdungen verlangt und in der Anfangsphase des Konzepts nicht abschließend geklärt ist, ob diese Gefährdungen möglicherweise doch relevant sind. Mit der vollständigen Liste soll außerdem demonstriert werden, dass alle möglichen Gefährdungen analysiert wurden.

Die QM-eingestuften Gefährdungen erhalten keine Einstufung in der Kontrollierbarkeit (C); der Schweregrad (S) wird auf 0 gesetzt, da das Fehlverhalten nicht zu einer Verletzung führen kann. In diesem Fall spielt auch die Exposition (E) logischerweise keine Rolle.

Entsprechend dem Standard ISO 26262 soll aus einer Gefährdung ein Sicherheitsziel (Safety Goal) und die entsprechende funktionale Sicherheitsanforderung ausgearbeitet werden:

In der Tabelle: HARA-Gefährdungsmatrix sehen wir, dass kein Sicherheitsziel verletzt wird, wenn ein Fehler in den LIN-Signalen auftritt. Damit jedoch die LIN-Funktion (G2) und (G4) als QM eingestuft werden kann, muss Freedom From Interference (FFI) nachgewiesen werden. Streng genommen kann kein Nachweis für FFI erbracht werden, da dieser Mikrocontroller über keine MPU-Einheit verfügt.

Ein alternativer Einsatz wäre, die Akzeptanz für ASIL B nachzuweisen, wenn die Software-Entwicklung folgende Maßnahmen umsetzt:

• Statische Trennung von Speicherbereichen durch Linker-Skript
• Task-Überwachung, Watchdog-Überwachung
• Datenintegritätsprüfung

Das Gleiche gilt auch für die Überwachung der Stromversorgung (G3).

Die Systementwicklung soll als Basis die HARA-Auswertung heranziehen.

Auf dem unten dargestellten Diagramm ist das FMS_PCB zusammen mit sämtlichen Kommunikationsverbindungen zwischen den Systemkomponenten ersichtlich.

Sobald die Sicherheitsanforderungen ausgearbeitet wurden, kann man aus systemischer Perspektive die “kritischen Pfade” markieren, die für die Aufrechterhaltung sicherheitskritischer Funktionen verantwortlich sind.

Die Mikrocontroller-Interfaces sind in Hardware-Software-Interface (HSI) definiert. Für die Funktionsschnittstellen werden “interne” Signale definiert. Nachfolgend finden Sie die Liste von internen Signalen:

• HBRG_CURR_STATE: Status von Strommessungen von H-Brücke (bzw. DC-Motor); wird für Hinderniserkennung benötigt
• UCNTR_F: Update-Frequenz vom Hall-Sensor; wird für Hinderniserkennung benötigt
• OBST_DET: Hinderniserkennungssignal, welches für Fenstersteuerung benötigt wird
• DIAG_ERR: Signal für Safe-State, es signalisiert, dass für die Funktionssicherheit relevante Signale einen Fehler aufweisen
• WND_MOT_CTRL: Signal für Fensterbewegungssteuerung vom Benutzer (vom H_PCB)
• WIND_STATE: Fensterstatus Signal, welches an H_PCB gesendet wird

Die Funktionen können zu diesem Zeitpunkt nicht zu 100 % dem spezifischen ASIL zugeordnet werden, da bisher nicht bekannt ist, ob und wie auf der Ebene der Softwarearchitektur Maßnahmen wie Dekomposition oder Koexistenz umgesetzt werden.

Das Functional Safety Concept (FSC) hat folgende Ziele:

• Definition von Degradierungsfunktion (Degradation)
• Zeitliche Detektierung von FS-relevanten Fehlern (Berücksichtigung des FTTI)
• Definition von FS-Anforderungen
• Definition von Safe State(s)
• Erstellung eines Validierungsplans

Wir konzentrieren uns hier auf die Erstellung von FSC-Anforderungen für SG1. Hier werden wir nur die Anforderungen ohne zugehörige Attribute und Rückverfolgbarkeit definieren, wie es im Artikel Anforderungsmanagement beschrieben ist. Es ist zu beachten, dass die Anforderungen auf einer höheren Abstraktionsebene definiert werden und keine Implementierungsdetails enthalten.

• FMS_PCB soll eine Hinderniserkennungsfunktion für Fensterbewegung nach oben implementieren.
• Wenn FMS_PCB ein Hindernis erkennt, soll FMS_PCB die Fensterbewegung nach oben stoppen und eine Umkehrbewegung 15 cm nach unten ausführen.
• Operation Mode: “normal mode”
• FTTI: 100 ms
• Safe State (Sicherer Zustand): SS1 (Safe State: 1 – Fensterbewegung stoppt)

• Redundancy (Redundanz): 2 Sensoren für die Fensterbewegungsauswertung (Stromsensor und Hall-Sensor)
• Fault Avoidance (Fehlervermeidung):
  • FMS_PCB soll für Hinderniserkennung zwei unabhängige Sensor-Werte benutzen.
  • FMS_PCB soll für die Strommessung einen Stromsensor benutzen.
  • FMS_PCB soll für die Fensterpositionsbestimmung und Fenstergeschwindigkeitsbestimmung einen Hall-Sensor benutzen.
• Fault Detection (Fehlerdetektierung):
  • FMS_PCB soll die Fensterbewegung nach oben stoppen, wenn ein Fehler am Stromsensor oder Hall-Sensor detektiert wird. FMS_PCB soll in SS1 übergehen.
  • FMS_PCB soll die Fensterbewegung nach oben stoppen, wenn ein FS-relevanter Fehler auftritt, und FMS_PCB soll in SS1 übergehen.
• Degradation Function (Degradationsfunktion):
  • Wenn FMS_PCB ein sicherheitsrelevanter Fehler detektiert, soll FMS_PCB die Fensterbewegung nach oben nur im “manual mode” mit einer maximalen Geschwindigkeit von 3 cm/s durchführen.
  • Wenn FMS_PCB Fehler bei beiden Sensoren: Strom- und Hall-Sensor detektiert, soll FMS_PCB keine Fensterbewegung nach oben mehr ausführen und in SS1 übergehen.

Das Technical Safety Concept verfolgt die Ziele:

• Spezifizierung von technischen Anforderungen für:
  • Relevante Anforderungen für Funktionale Sicherheit,
  • Einschränkungen,
  • Eigenschaften von Systemelementen und
  • Schnittstellen von Systemelementen
• Definition der Sicherheitsmechanismen,
• Festlegung der Sicherheitsanforderungen für Betrieb, Produktion und Aufrechterhaltung,
• Überprüfung, ob die Anforderungen die Funktonale Sicherheit erfüllen,
• etc.

Es gibt zahlreiche Anforderungen an den TSC gemäß ISO 26262-4, Kapitel 6. Hier werden wir nur eine kleine Untermenge dieser Anforderungen kurz ansprechen. Obwohl alle Zielpunkte des TSC für das Konzept wichtig sind, möchte ich einige Punkte hervorheben. Meiner Meinung nach verdienen insbesondere die Sicherheitsmechanismen und die Kriterien für die Koexistenz einen tieferen Einblick.

Als Grundlage für die Definition von Sicherheitsmechanismen dienen die HARA, das Functional Safety Concept (FSC) und die Systemarchitektur. Auf dem Diagramm „Systemarchitektur: Fenstermotorsteuerung FMS_PCB und kritische Pfade“ sind die Signalpfade des Stromsensors „CURR_MON“ und des Hall-Sensors „USHHS“ gekennzeichnet.

Wir gehen davon aus, dass die Hardware-Analyse bereits durchgeführt wurde. Sowohl die “Evaluation of the hardware architectural metrics” als auch die “Evaluation of safety goal violations due to random hardware failures” sind erfolgt. Daraus abgeleitete Maßnahmen wurden mit dem TSC synchronisiert.

Es ist zu beachten, dass die LIN-Funktion aufgrund der Koexistenzregelung (nach ISO 26262) eine Wrapper-Schicht benötigt.

Dazu sollen folgende Software-Sicherheitsmechanismen (gemäß [ISO 26262-4, 6.4.2.1]) definiert werden:

• – Detektierung von Fehlern, Indikation und Fehler-Handling
• – Mechanismen für das Erreichen von Safe-State (Sicherer Zustand)

definiert und umgesetzt werden:

• Fehlerdetektion am Hall-Sensor (TSC-Anforderungen):
  • Wenn FMS_PCB SW ein Kurzschluss- oder Open-Load-Fehler vom Hall-Sensor detektiert, soll FMS_PCB SW in SS1 übergehen.

Die TSC-Anforderungen können auf der SW-Ebene weiter detailliert werden:

• Fehlerdetektierung am Hall-Sensor (SW-Anforderungen):
  • Das FMS_PCB SW soll Kurzschlussfehler am Hall-Sensor detektieren.
    • Wenn FMS_PCB SW ein Kurzschlussfehler detektiert, soll ein Fehlereintrag “Hall-Sensor Fehler: Kurzschluss” im NvM gespeichert werden.
    • Wenn FMS_PCB SW ein Kurzschlussfehler detektiert, soll ein FMS_PCB SW ins SS1 übergehen.
  • Das FMS_PCB SW soll Open-Load-Fehler am Hall-Sensor detektieren.
    • Wenn FMS_PCB SW ein Open-Load-Fehler detektiert, soll ein Fehlereintrag “Hall-Sensor Fehler: Open-Load” im NvM gespeichert werden.
    • Wenn FMS_PCB SW ein Open-Load-Fehler detektiert, soll ein FMS_PCB SW ins SS1 übergehen.

Die TSC-Anforderungen vom Stromsensor beschreiben mehr Diagnosemöglichkeiten als die Diagnose von Hall-Sensor. Hier wird davon angenommen, dass alle diese Maßnahmen aus entsprechenden Analysen für ASIL B-Erfüllung notwendig sind.

• Fehlerdetektierung am Stromsensor (TSC-Anforderungen):
  • Wenn FMS_PCB SW während des Selbst-Tests vom Stromsensor beim Start-up, oder Stromsensortemperaturmessung oder Stromsensor-EEPROM-Datenüberprüfung ein Fehler detektiert, soll FMS_PCB SW in SS1 übergehen.

• Fehlerdetektierung am Stromsensor (SWE-Anforderungen):
  • Das FMS_PCB SW soll Selbstdiagnose vom Stromsensor während Start-up initiieren.
    • Wenn FMS_PCB SW während Selbstdiagnose vom Stromsensor einen Fehler detektiert, soll ein Fehlereintrag “Stromsensor Fehler: Selbstdiagnose Fehler” im NvM gespeichert werden.
    • Wenn FMS_PCB SW während der Selbstdiagnose vom Stromsensor einen Fehler detektiert, soll FMS_PCB SW in SS1 übergehen.
  • Das FMS_PCB SW soll Stromsensortemperatur lesen.
    • Wenn FMS_PCB SW die Übertemperatur am Stromsensor detektiert, soll FMS_PCB SW einen Fehlereintrag “Stromsensor Fehler: Übertemperatur” im NvM speichern.
    • Wenn FMS_PCB SW die Übertemperatur am Stromsensor detektiert, soll FMS_PCB SW in SS1 übergehen.
  • Das FMS_PCB SW soll die Stromsensor-EEPROM lesen und auf die Gültigkeit und Konsistenz von dort gespeicherten Daten mit CRC-Berechnung überprüfen.
    • Wenn FMS_PCB_SW nach dem Auslesen von Stromsensor-EEPROM-Daten feststellt, dass der CRC-Wert von EEPROM-Daten nicht mit dem berechneten CRC-Wert übereinstimmt, soll FMS_PCB SW einen Fehlereintrag “Stromsensor Fehler: EEPROM CRC Fehler” im NvM speichern.
    • Wenn FMS_PCB_SW nach dem Auslesen von Stromsensor-EEPROM-Daten feststellt, dass der CRC-Wert von EEPROM-Daten nicht mit dem berechneten Wert übereinstimmt, soll FMS_PCB SW in SS1 übergehen.

Ergänzend zu diesen Anforderungen könnte man noch Anforderungen für die Plausibilisierung von Benutzereingabe-, sowie den Hall-Sensor und Stromsensor-Daten und Motorspannung schreiben. Des Weiteren empfiehlt es sich, die Registerbelegung für die Peripheriekonfiguration zur Laufzeit zu überprüfen. Für die spätere Softwareumsetzung soll erwähnt werden, dass ASIL B-SW-Funktionen (Stromsensormessung und Hall-Sensor-Pulsmessung) im ASIL B-SW-Speicherbereich abgespeichert werden müssen (getrennt von QM-SW-Funktionen). Die ASIL B-SW-Funktionen sollen in priorisierten ASIL B-Tasks mit zeitlicher Ausführungsprüfung ausgeführt werden (Deadline Monitoring) etc.

Da wir uns in diesem Dokument mehr auf die technischen Details konzentrieren, möchte ich hier nicht alle Anforderungen aus dem Standard ISO/SAE 21434 im Detail betrachten, sondern nur die technische Seite, die für die technische Umsetzung relevant ist.

Ergänzende Information aus ISO/SAE 21434 befindet sich in dem Artikel: ISO/SAE 21434 – Road Vehicles – Cybersecurity Engineering.

Im Standard ISO/SAE 21434 spielt die Threat Analysis und Risk Assessment (TARA) eine zentrale Rolle. In diesem Dokument werden die einzelnen Systemkomponenten betrachtet und auf die möglichen Angriffe analysiert. Ganz am Anfang ist es wichtig, eine Item-Definition entsprechend dem Kapitel: 9.3 durchzuführen. Dabei wird genau festgestellt, um welche Systemkomponente oder System es sich bei der Analyse handelt. Des Weiteren werden auch die Umgebungsbeteiligten, die zur Cyber-Sicherheit beitragen können, identifiziert. Als Ergebnis soll eine vorläufige Architektur erstellt werden, die für die Erfüllung dieser Aufgaben notwendig ist.

Auf dem Diagramm unten sieht man eine Preliminary Architecture (Vorläufige Architektur), die für die TARA-Analyse hilfreich sein kann.

Aus diesem Diagramm ist ersichtlich, dass das FMS_PCB bei der Analyse eine zentrale Rolle spielt. Die aus TARA ergebenden Maßnahmen, welche später erläutert werden, orientieren sich an dem FMS_PCB. Die Angriffspfade zeigen mögliche Angriffswege (mit Funktionsbeschreibung), welche für die potenziellen Angriffe benutzt werden können.

Die TARA-Analyse dient als Grundlage für die Implementierung von Cybersecurity-Maßnahmen in Hardware und Software während der Systemarchitekturentwicklung.

Zur Auswertung gehört auch eine Beschreibung der Operativer Umgebung. Hier sind die Punkte aus der Beschreibung:

Aus dem Diagramm: “Fensterheber ECU – Elementdefinition und Elementgrenzen für TARA” ergeben sich folgende Angriffsmöglichkeiten:

• Angriff durch Benutzung von Debugger-Schnittstelle (SWD) zum Flashen von gefälschter Firmware
• Simulation des Benutzertastenfelds (Verantwortung liegt bei H_PCB), um die Fensterbewegung zu beeinflussen
• Angriff über den LIN-Bus, in dem die LIN-Signale vorgetäuscht werden, um die Fensterbewegung zu beeinflussen
• Simulation eines Diagnosetesters über den LIN-Bus, um die sicherheitskritischen Funktionen zu beeinflussen oder Diagnosedienste zu missbrauchen
• Angriff über OBD, um die Firmware zu aktualisieren oder Verhalten vom Fensterheber zu beeinflussen

Aus zeitlichen Gründen wurden in der TARA nicht alle Angriffspfade analysiert. Hier wird nur ein Asset (Wert) berücksichtigt:

• Datenkommunikation (LIN-Leitungstrennung zwischen H_PCB und FMS_PCB und Datenmanipulation durch verfälschte LIN-Nachrichten)

In der unten stehenden Tabelle ist eine tabellarische TARA-Analyse für den oben genannten Angriffspfad dargestellt.

Nachfolgend einige Erläuterungen zu einzelnen Punkten der Tabelle:

• Cybersecurity Property: Es werden nur Integrität und Verfügbarkeit sind ausgewählt.
• Impact Category: Funktionale Sicherheit sowie finanzieller Aspekt wurden nicht in Betracht genommen.
• WoO – Window of Opportunity: Es wurde ein Zwischenwert zwischen Moderate und Difficult gewählt, da für einen Angriff nicht nur ein Zugang zum Fahrzeug, sondern auch mechanische Manipulationen erforderlich sind.
• Risk value determination: O:2 ist zwar als niedrig eingestuft, entscheidet man trotzdem, eine Risikoreduzierung durchzuführen.
• Cybersecurity-Goal: kann eventuell weniger detailliert beschrieben werden.

Später sollen aus dem Cybersecurity-Goal die Anforderungen abgeleitet werden.

• Wenn innerhalb von 100 ms die LIN-Nachricht (ID: 0xE2) empfangen wird, aber die Authentifizierungssignatur von dem H_PCB nicht mit der vom FMS_PCB berechneten Signatur übereinstimmt, soll das FMS_PCB in den Safe State SS1 übergehen und dort zeitlich inkrementell verbleiben, wenn die Fehlversuche nacheinander erfolgen:
  • 1. Fehlversuch: 1 Sekunde
  • 2. Fehlversuch: 4 Sekunden
  • 3. Fehlversuch: 9 Sekunden
  • 4. Fehlversuch: 15 Sekunden
  • 5. Fehlversuch: 25 Sekunden
  • 6. Fehlversuch: 30 Sekunden
• Wenn nach dem 6. Fehlversuch 30 Sekunden ablaufen, soll ein Reset des FMS_PCB-Mikrocontrollers durchgeführt werden.

Obwohl die Methodik für das System-Engineering und die Systemarchitektur in den oberen Kapiteln nicht bis ins Detail behandelt wurde, sollte sie es ermöglichen, die prinzipielle Vorgehensweise an eigene Projekte anzupassen und zu integrieren.

Ein zusammenhängender Artikel, den ich empfehle, ist: Softwarearchitektur (Fensterheber-ECU), in dem die Methodik für die Erstellung der Softwarearchitektur erläutert wird.

Für jedes dieser Kapitel können Fragen entstehen. Daher bitte ich meine Leser, diese Fragen zu stellen. Ich werde versuchen, diese Fragen möglichst sachlich zu beantworten und hier zu veröffentlichen.

Abschließend werden hier die Punkte aufgeführt, die in einem realen Projekt eine wichtige Rolle spielen, in diesem Dokument jedoch ausgelassen sind.

Sicherheitskonzept: Das Sicherheitskonzept dient als Grundlage für die weitere Entwicklung des Produkts. Aus diesem Grund sollte man dem Sicherheitskonzept im Projekt besondere Aufmerksamkeit widmen.

Degradierungskonzept: Neben dem Sicherheitskonzept spielt das Degradierungskonzept ebenfalls eine wichtige Rolle.

Netzwerkkommunikation: Die für die LIN-Kommunikation (oder andere Kommunikationsarten) benötigten Daten sollten möglichst schnell geklärt werden.

Diagnose- (UDS-Dienste): In diesem Dokument werden sie komplett ausgelassen, sind jedoch für reale Projekte wichtig. Das Diagnoselastenheft sollte möglichst früh in den Anforderungen berücksichtigt werden.

Mechanik: In so einem Projekt, wie Fensterheber-ECU, spielt Mechanik eine große Rolle bei der Implementierung in allen Disziplinen (Software, Hardware und Mechanik). Hier sollten Faktoren wie die Alterung von Werkstoffen, Verformungen, Temperaturen usw. berücksichtigt werden. Durch Messungen, Versuche und Experimente wird bestimmt, wie der Fensterhebermotor abhängig von den Umgebungsbedingungen angesteuert werden soll.

Kalibrierung und Parametrierung: Für das System und die Software ist es wichtig, bereits zu Beginn eines Projekts zu wissen, welche Kalibrierungs- und Parametrierungsartefakten benötigt werden.

Produktionsdaten: Diese Daten sind ebenfalls wichtig und sollten frühzeitig geplant und abgestimmt werden.

Powermodi: Eine besondere Rolle spielen die Powermodi in einem modernen Projekt. Die Anforderungen an ein Steuergerät bezüglich des Stromkonsums und des Steuergerätverhaltens beim Start-Up bzw. Power-Down muss ebenfalls geklärt werden.

Fehlerdetektierung und Fehlermanagement: Das Fehlermanagement betrifft beide Disziplinen Software und Hardware und ist wichtig für die Erfüllung der ISO 26262-Anforderungen.

Sicherlich gibt es viel mehr Punkte, welche hier nicht aufgeführt sind, die in einem realen Projekt jedoch eine wichtige Rolle spielen. Wenn Sie eine Beratung und/oder eine Unterstützung in Ihrem Projekt im Bereich Systems Engineering benötigen: