Startseite > Automotive > Von der Anforderung zur fertigen Safety-Software-Architektur

Theorie in die Praxis umsetzen

Von der Anforderung zur fertigen Safety-Software-Architektur

13. Juli 2016, 13:45 Uhr | Von Dietmar Kinalzyk

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Hella-Software-Produktplattform im Überblick

Die Hella-Software-Produktplattform unterstützt die Integritätsprüfungen des Level 3 mit ASIL B. Es besteht die Anforderung, dass die Integration unter den Bedingungen der funktionalen Sicherheit im Projekt erfolgen muss, die im Integrations-Manual festgelegt sind. Es muss ein Review der Konfiguration des Generators (ARXML) ausgeführt werden.

Hier sind folgende Module vorhanden:

RAM- und ROM-Check: Dieser führt einen Adresstest aus, da durch die Mikrocontroller-eigene ECC-Hardware nicht abgedeckt.
ECC-Detection: Der Inhalt der RAM- und ROM-Zellen wird im Hintergrund von der Mikrocontroller-Hardware automatisch geprüft. Hier ist die Prüfung der Funktion der ECC-Hardware gemeint. Falls Fehler auftreten, wird ein Exception Handling und Refresh durchgeführt.
MCU Protection Register: Bei Anwendung werden Register zur Konfiguration der Hardware geschützt.
MPU Data, Calls: Die Memory Protection Unit schützt vor unerlaubtem Schreiben von Daten und unerlaubten Funktionsaufrufen, zum Beispiel Funktionen mit Standard-Qualität in ASIL-x-Daten.
ADC-Input (Treiber, Handler): Die Daten vom Analog-Digital-Umsetzer werden für viele sicherheitsrelevante Eingangssignale genutzt.
Core-Test: Der Mikrocontroller-Kern wird zyklisch getestet.
Sichere Kommunikation E2E: End-to-End-Kommunikation von Signalen über den CAN-Bus
Watchdog-Manager: Dieser kommt im Zusammenhang mit dem externen Watchdog und Program Flow Monitoring zum Einsatz.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Funktionszuordnung Bremslicht in AUTOSAR

In Bild 4 ist die oberste Ebene der Software-Architektur (AUTOSAR und Projekt) mit der Zuordnung der E-Gas-Level und Signalpfaden dargestellt.
Bei der Bremslichtanforderung erfolgt die Aktivierung der Signale und Module in folgenden Schritten:

Einlesen der Hardware-Klemme 54 Bremslicht über digitalen Ein- und Ausgang Dio (Digital I/O)
Weiterleitung zum Digital Input Handler DinH, der zyklisch läuft. Dieser bereitet die Messungen vor und liefert das Ergebnis an die RTE.
Das Signal geht weiter zur Software-Komponente Input Monitor SwcInM.
Über die RTE Kl. 54 geht es zur Software-Applikation Bremslicht SwcBrakeLi. Diese entscheidet über die Einschaltung des Bremslichts. Dabei wird auch die Einschaltanforderung vom CAN-Bus mit E2E-Überwachung berücksichtigt.
Über das BrakeLightCommand in der RTE wird der LightChannelManager zum Einschalten aufgefordert. Dieser entscheidet über die Konfiguration, welche Bremslichter eingeschaltet werden sollen.
Der LightChannelManager erhält auch das LightChannelFeedback und prüft, ob nach Anforderung eingeschaltet wurde. Bei fehlendem Bremslicht wird eine Fehlerreaktion ausgelöst.
Das LightChannelCommand veranlasst die Ausgangssteuerung SwcOutCtrl, die physikalische Ansteuerung des Bremslichtkanals.
Der PortOutputHandler steuert dann den SpocHandler (Pulsweitenmodulation) an, um die Anforderung über die serielle Kommunikation zum Lichttreiber zu geben.
Die Lichtansteuerung wird im Lichttreiber gemessen und über den ADC-Treiber und Analog-Input-Handler ADinH zur Überprüfung im LightChannelManager weitergegeben.

Durch die vorgegebene AUTOSAR-Architektur mit mehreren Schichten und die geforderte flexible Lichtsteuerung für jeden Kanal ist diese umfangreiche Lösung entstanden. Der LCM LightChannelManager nimmt eine zentrale Rolle ein, um Verletzungen der Sicherheitsziele durch Interference mit Hilfe von Software mit Standard-Qualität inklusive FTT festzustellen. Dazu zählen

Ansteuern des Bremslichts gemäß Anforderung
Rückmeldung über die erfolgte Ansteuerung
Rücklesung des Ansteuerstroms und Bewertung
Auswerten der Fehlerstati, wie Short Gnd, Open, Short Vbat der Ausgänge und interne Diagnosen
Reaktion entsprechend der Fehlerstati im BLEM BasicLayerErrorManager

Durch die zyklische Verarbeitung der Signale – mehrfach innerhalb der FTT – werden Auswirkungen durch transiente Fehler, sogenannte Soft Errrors (Bitflips), weitgehend vermieden. Die Auswirkungen von Bitflips in RAM- und ROM-Zellen werden durch die ECC des Prozessors korrigiert (1-bit-Fehler). Es gibt jedoch noch andere potenzielle Fehlerquellen für Bitflips, zum Beispiel InOut, Core, Adress- oder Datenleitungen. Hier gilt die zyklische Verarbeitung als beste Methode für Robustheit und Sicherheit.

Funktionszuordnung der Software-Architektur Zentralverriegelung

Die Funktionszuordnung der Safety-Software-Architektur Zentralverriegelung ist in Bild 5 dargestellt. Hier gab es die Herausforderung, vorhandene Software, die nach Anforderungen von Funktionen mit Standard-Qualität entwickelt wurde, wiederzuverwenden. Es war nicht möglich, durch eine Software-Kritikalitätsanalyse die Rückwirkungsfreiheit von Software, die nach Standard-Qualität entwickelt wurde, auf die Sicherheitsfunktion „Safen“ (Double-Lock) nachzuweisen. Gewachsene Software, Software-Design und Schnittstellen waren für eine vollständige Untersuchung zu komplex. Deshalb wurde hier die Klammerfunktion „Wrapper“ eingesetzt, die nur die kritische Funktion „Safen“ zulässt, wenn alle Bedingungen als plausibel und gültig eingestuft werden.

Eine Prüfung des Konzepts und die Bestätigung der Anforderungen an die funktionale Sicherheit durch Test sind hier für ASIL A als ausreichend anzusehen. Für ASIL B müssten weitere Analysen und Bestätigungsmaßnahmen geplant werden.

Lessons learned

Der Aufwand für funktionale Sicherheit wurde zunächst niedriger eingeschätzt, als er tatsächlich war. Auch die Erstellung des Funktionale-Sicherheit-Konzepts gemeinsam mit dem Kunden sowie die Umsetzung des technischen Sicherheitskonzepts und weitere Detaillierung in der Hard- und Software wurden unterschätzt. Weil der Safety-Prozess das erste Mal durchlebt wurde, gab es noch wenig Erfahrung in der Organisation und der technischen Umsetzung. Überschwinger im Aufwand sowie Auslassen von Maßnahmen mussten korrigiert werden.

Funktionale Sicherheit sollte mit Projektbeginn genau wie Qualitätsmanagement einbezogen werden. Der Safety Manager sollte von der Angebotsphase an mit dabei sein und die Kostenschätzungen für Hardware sowie die Qualifikation von Software- und Hardware-Komponenten kritisch betrachten.

Darüber hinaus ließ sich feststellen, dass die Safety-Kultur mit dem Verständnis in der Organisation über alle Domänen wächst. Auch ist der Top-Down-Ansatz besser als ein einziger Safety-Manager im Unternehmen, der alles im Blick haben muss.

Der notwendige Erfüllungsgrad der Sicherheitsanforderungen war nicht immer klar. Hier helfen Beispiele in Form von Patterns oder Guidelines.

Mit einer strikten Trennung von QM-Funktionen und -Konzentration sowie der Reduzierung auf erforderliche Sicherheitsfunktionen und -diagnosen lässt sich der Aufwand für Safety-Funktionen erheblich minimieren.

Zudem sind Potenziale zur Standardisierung von Safety für AUTOSAR und der Software-Produktplattform vorhanden. Hier sollte die zukünftige Entwicklung ansetzen, um möglichst viele Software-Komponenten mindestens in ASIL-B-Qualität bereitzustellen. Für die Wiederverwendbarkeit sollten die Komponenten durch vertikale, also von der Applikation bis zur Hardware-Treiber-Software, prototypische Umsetzung geprüft werden.

Der Autor

Dipl.-Ing. Dietmar Kinalzyk
studierte Informatik an der Technischen Hochschule Wismar. Nach seinem Studium trat er als Entwicklungsingenieur Hardware und Software bei AEG Zähler ein. Nach Stationen bei Schlumberger Zähler und Systeme, Actaris Zähler und Systeme, Lenze sowie Siemens VDO Automotive AG bzw. Continental Automotive trat Kinalzyk Ende 2008 als Safety Manager & Senior Project Manager in den Hella-Konzern ein. Seit März 2013 ist er im Konzern als Safety Manager & Safety-Assessor beschäftigt.

Dipl.-Ing. Dietmar Kinalzyk

studierte Informatik an der Technischen Hochschule Wismar. Nach seinem Studium trat er als Entwicklungsingenieur Hardware und Software bei AEG Zähler ein. Nach Stationen bei Schlumberger Zähler und Systeme, Actaris Zähler und Systeme, Lenze sowie Siemens VDO Automotive AG bzw. Continental Automotive trat Kinalzyk Ende 2008 als Safety Manager & Senior Project Manager in den Hella-Konzern ein. Seit März 2013 ist er im Konzern als Safety Manager & Safety-Assessor beschäftigt.

dietmar.kinalzyk@hella.com