Startseite > Embedded > Software > Funktionale Sicherheit richtig umsetzen

Prof. Dr. Peter Fromm, HS Darmstadt

Funktionale Sicherheit richtig umsetzen

14. Dezember 2023, 13:30 Uhr | Tobias Schlichtmeier

Peter Fromm, Hochschule Darmstadt: »Das Wichtigste ist neben der Kenntnis der Safety-Normen ein sehr gutes System- und Architekturverständnis.«

Embedded-Systeme werden zunehmend komplexer. Das betrifft zum Beispiel Applikationen in den Bereichen autonomes Fahren, künstliche Intelligenz und im Bahnsektor. Hierbei kommt der funktionalen Sicherheit eine immer größere Rolle zu, wie Prof. Dr. Peter Fromm von der Hochschule Darmstadt erläutert.

▶ Diesen Artikel anhören

Markt&Technik: Herr Fromm, warum gewinnt funktionale Sicherheit in Embedded-Systemen immer mehr an Bedeutung?

Peter Fromm: Ich zitiere an dieser Stelle gerne den Entwicklungsleiter eines großen Chipherstellers, der auf der embedded world Conference vor einigen Jahren sinngemäß gefragt hat: »Gibt es noch Embedded-Systeme ohne Safety?« Er schob zugleich schmunzelnd die Antwort hinter: »Ja, aber es werden weniger.«

Ein starker Treiber ist hier die steigende Leistung moderner eingebetteter Controller. Zu Beginn meiner Karriere wurde jede Variable und somit jedes Byte Speicherbedarf intensiv beäugt, ob es wirklich nötig ist. Eine ähnlich kritische Ressource war die CPU-Zeit. Das hat sich mittlerweile deutlich geändert, und heutige Embedded-Entwickler können problemlos komplexere Algorithmen realisieren, die zunehmend sicherheitsrelevante Aufgaben übernehmen. Ein prominentes Beispiel sind etwa moderne Advanced Driver-Assistance-Systems (ADAS) im Automobilbereich. Aber auch in der Medizintechnik, Landwirtschaft, Automatisierung bis hin zur Gebäudetechnik sind ähnliche Trends zu beobachten.

Wie definieren Sie funktionale Sicherheit (FuSi)?

Der Kernpunkt ist hierbei sicherlich folgender: Wenn der Betrieb eines Systems die Umwelt und insbesondere den Menschen gefährden kann, müssen an dieses System höhere Anforderungen an die Zuverlässigkeit gestellt werden.

Letztendlich geht es dabei um drei zentrale Anforderungen:

Vermeidung systematischer Fehler bei Design und Implementierung – dieses ist häufig eine Prozessanforderung.
Erkennen und Behandlung stochastischer Fehler – dieses ist primär eine Architekturanforderung.
Nachweis des Safety-Case – d. h. Erstellung einer nachvollziehbaren, technischen Argumentation, warum das System sicher ist.

Haben Sie hierfür ein konkretes Beispiel?

Aus meiner Sicht müssen wir hierbei sowohl sichere System- als auch Schutzfunktionen betrachten. Bei sicheren Systemfunktionen ersetzt man traditionelle – häufig mechanische Lösungen – durch elektronische Systeme. Ein Beispiel hierfür sind etwa »X-by-Wire«-Systeme. Hier geht es im Wesentlichen darum, mit der neuen Technologie eine mindestens so hohe Zuverlässigkeit zu realisieren wie im klassischen Ansatz.

Bei Schutzfunktionen – Beispiele sind ein Airbag, das Antiblockiersystem (ABS) oder Electronic Stability-Program (ESP) – trifft das System in kritischen Situationen eine aktive Entscheidung und entscheidet für den menschlichen Betreiber. Gefährlich hierbei ist häufig nicht der Ausfall des Systems, sondern das fehlerhafte Auslösen in einer nichtkritischen Situation. Ein trauriges Beispiel hierfür ist das Maneuvering-Characteristics-Augmentation-System (MCAS) von Boeing – die Technik übernahm aufgrund falscher Sensorwerte und gravierender Mängel in der Systemarchitektur fälschlicherweise die Steuerung des Flugzeugs und führte damit einen Unfall herbei.

Welche Normen sollten Entwickler kennen, wenn sie Code für FuSi-Applikationen erstellen möchten?

Speziell aus Sicht der Software enthalten die Safety-Normen gar nicht so viel Neues im Vergleich zu einem Capability-Maturity-Model-Integration(CMMI)- oder Spice-basierten Prozess. Letztendlich muss der Entwickler immer die Norm erfüllen, die für die entsprechende Domäne gilt. Die Grundnorm IEC 61508 ist ein guter Startpunkt, enthält jedoch in Bezug auf die Softwareentwicklung eher abstrakte Vorgaben; hier ist die ISO 26262 schon konkreter.

Welche Punkte sollten Entwickler außerdem beachten?

Letztendlich geht es unabhängig von der Norm darum, die Sicherheitsfunktionen systematisch, basierend auf einer Gefährdungsanalyse, zu entwickeln. Auf Architekturebene muss der Entwickler anschließend eine Lösung finden, die die Sicherheitsfunktion mit ausreichend Zuverlässigkeit umsetzt. Die wesentlichen Parameter sind hier in fast allen Normen »Mean Time to Failure« der Einzelkomponenten, Diagnoseabdeckung sowie Hardwarearchitektur beziehungsweise Redundanz.

Das Wichtigste aus meiner Sicht ist daher neben der Kenntnis der Safety-Normen ein sehr gutes System- und Architekturverständnis sowie eine enge Zusammenarbeit von Software- und Hardware-Entwicklern.

Reicht es in der Regel aus, Software zu testen, oder schlagen Sie weitere Maßnahmen vor?

Betrachtet man die wirtschaftliche Seite eines Safety-Projektes, so erkennt man, dass ein systematischer Testprozess häufig ein vermeintlicher Haupttreiber der Kosten ist. Hierbei haben Safety-Normen keine besonders hohen Anforderungen an den Testprozess. Jedoch müssen die Entwickler systematisch dokumentieren und testen.

In der Praxis empfiehlt sich daher der Einsatz von automatisierten Processor-in-the-Loop(PIL)- oder Hardware-in-the-Loop(HIL)-Tests. Denn bei einer systematischen Testspezifikation können selbst bei kleinen Safety-Funktionen schnell einige 10.000 Testfälle zusammenkommen. Zudem müssen bei einem Re-Test alle Tests in der Regel nochmal vollständig durchlaufen werden.

Im Automotive-Bereich wird mithilfe der MISRA-Regeln versucht, Fehler schon beim Programmieren zu vermeiden. Was leisten die MISRA-Regeln und in welchen Punkten gibt es Nachholbedarf?

MISRA ist sicherlich einer der besseren Programmierstandards und reduziert den C/C++-Sprachumfang auf ein sicheres und wohldefiniertes Subset – was sich auch daran zeigt, dass diese Norm in vielen Bereichen außerhalb des Automotive-Bereichs zum Einsatz kommt und mittlerweile sogar Eingang in das Curriculum von technischen Studiengängen gefunden hat.

Gerade wenn ich als Software-Entwickler MISRA entwicklungsbegleitend einsetze, kann ich Schwächen im Code bereits vor dem Review beheben. Aber auch MISRA ist kein Königsweg. Speziell Designfehler im Code sowie andere komplexere Probleme lassen sich damit nicht finden. Somit ist das menschliche Experten-Review weiterhin nötig und wichtig. Allerdings lässt sich der Fokus im Review dann auf die »spannenden« Probleme legen.

Welche Tools empfehlen Sie Entwicklern, um Software-Code nach allen Punkten der funktionalen Sicherheit zu erstellen und zu testen?

Die Frage der Toolchain hängt sicherlich von der Komplexität des Projektes ab. Unsere Erfahrung in aktuellen Projekten zeigt, dass sich ein modellbasierter Ansatz lohnen kann. So können Entwickler den hohen Anforderungen an die Qualität, Dokumentation und Nachvollziehbarkeit gerecht werden und gleichzeitig die Software in inkrementellen beziehungsweise iterativen Zyklen agil entwickeln.

Im Rahmen eines Projektes innerhalb des zentralen Innovationsprogrammes Mittelstand (ZIM) der Bundesregierung haben wir am Fachbereich Elektrotechnik und Informationstechnik an der Hochschule Darmstadt ein holistisches, aber trotzdem leichtgewichtiges Werkzeug namens entwickelt und mittlerweile in ersten Safety-Projekten erfolgreich eingesetzt. Es unterstützt im Sinne eines modellbasierten System-Engineerings die Prozessbereiche Anforderungen, Hardware- und Software-Architektur, Code-Generierung der Laufzeitumgebung sowie Test und Traceability zwischen allen Artefakten.

Welche drei Tipps würden Sie einem Entwickler hinsichtlich Safety-Anforderungen mit auf den Weg geben?

Der wichtigste Tipp ist sicherlich: Plane ausreichend Ressourcen und Zeit ein. Aufgrund der höheren Anforderungen an die Architekturentwicklung sowie Test und Dokumentation verdoppelt sich der Aufwand in einem Safety-Projekt selbst bei den unteren Safety-Integrity-Levels schnell auf das Doppelte.

Der zweite Tipp wäre: Verstehe den technischen Sinn der Safety-Norm und probiere, diesen sinnvoll umzusetzen, statt die Norm Buchstabe für Buchstabe zu befolgen.

Und last but not least: Gerade wenn es das erste Safety-Projekt ist, ist eine externe Beratung beziehungsweise Unterstützung hilfreich.