Die Gefährdung, die von einer funktionierenden Maschine ausgeht, wird heute üblicherweise auf verschiedene Arten minimiert – zum Beispiel durch Schutzzäune, über Zutrittsysteme oder auch ergänzend mittels Arbeitsanweisungen. Wenn solche Maßnahmen versagen, muss in letzter Instanz die Elektronik selbst den Unfall im Falle eines gefährlichen Versagens der Maschine abwenden. Hier kommen die IEC 62061 und mit ihr die IEC 61508 ins Spiel.

Die Basisnorm IEC 62061 (Sicherheit von Maschinen – Funktionale Sicherheit sicherheitsbezogener elektrischer und elektronischer und programmierbarer elektronischer Steuerungssysteme) ist applikations- und technologieunabhängig. Sie beschreibt Aufgaben und Verantwortung von Anlagen- und Maschinenbetreibern und leitet dabei Anforderungen für die Entwicklung durch den Komponentenhersteller ab. Die Norm bietet weiterhin Hilfestellung zu Entwicklungsmethoden bei der Hard- und Embedded-Software-Entwicklung, um systematische Fehler zu vermeiden und zufällige sowie verbliebende Fehler zu beherrschen.

Auf der nichttechnischen Seite ergänzt die IEC 61508 (Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme) die organisatorischen Anforderungen der Qualitätsmanagement-Norm ISO 9001. Denn nicht nur der Maschinenbetreiber, sondern auch der Komponentenhersteller muss ein Management der funktionalen Sicherheit in seiner Organisation etablieren und nachweisbar leben, damit er die Beweislastumkehr im Schadensfall vor Gericht anwenden kann. Mit anderen Worten: Funktionale Sicherheit verlangt für die SIL-Entwicklung qualifiziertes Personal und geplantes sowie methodisches Vorgehen. Sinnvolle Projektschritte in diesem Zusammenhang sind:

Safety Workshop (technisch, produktbezogen)
Functional-Safety-Grundlagenseminar (normbezogen, Management mit ins Boot nehmen)
Safety und Design Requirements
Safety-Plan, V&V-Plan
Technisches Safety-Konzept (HW/SW)
Safety-Manual-Konzept
Concept Approval
sichere Hard- und Software-Entwicklung nach dem V-Modell
Zertifizierung
Safety Workshop

In einem Safety Workshop lassen sich zunächst die übergeordneten Anforderungen des Produktmanagements entlang der Produktvision sammeln und Produktschnittstellen definieren. Die sicheren Funktionen, deren Reaktionszeiten und der sichere Zustand gemäß der Zielapplikation werden beschrieben und für das zu entwickelnde Produkt abgeleitet. Auf dieser Grundlage ist dann die Sicherheitsarchitektur der Elektronik erstellbar. Unterzieht man diese einer System-Konzept-FMEA (Failure Mode and Effect Analysis auf Konzeptebene), können die technischen Sicherheitsintegritätsmaßnahmen weitgehend ermittelt werden.

Bei komplexen Projekten ist es ratsam, bereits zu diesem Zeitpunkt eine unabhängige, benannte Stelle (z.B. TÜV, IFA) für eine technische Vorkonzeptbesprechung einzubeziehen, um effizienter zur Konzeptfreigabe zu gelangen. Diese überprüft den Erfüllungsgrad der normativen Anforderungen und erkennt bei entsprechender Vorbereitung schnell Zertifizierungsrisiken. Soll die gesamte Organisation in Richtung der funktionalen Sicherheit weiterentwickelt werden, kann die Stelle zudem beim Aufbau und der Bewertung der benötigten Prozesse behilflich sein.

Häufiges Problem: der Tunnelblick

Oft findet sich in Organisationen die Problemstellung des Tunnelblicks. Der Produktmanager sieht nur sein Produkt, die Entwickler sehen nur die ihnen zugewiesenen Aufgaben und das Management ist sich der Implikationen der funktionalen Sicherheit auf die gesamte Firma mit ihren Prozessen und Abläufen nicht bewusst. Hilfreich kann in diesen Fällen ein Grundlagenseminar sein, wie es von diversen Institutionen angeboten wird. Hier wird entlang des zukünftigen Produktes das Thema funktionale Sicherheit für alle Ebenen erklärt. Als mögliche Folge kann das Qualitätsmanagementsystem mit seinen Prozessen um die Anforderungen entsprechend IEC 61508‑1 erweitert werden.

Der anschließend aufzustellende Produktsicherheitsplan beschreibt das angedachte Projektvorgehen: Auf welcher Grundlage das Produkt sicher sein wird, die Prozesse, die Verantwortungen sowie die Qualifikationen der beteiligten Mitarbeiter. Er bietet als produktzentrischer Plan ebenso die Schnittstellen zu ISO-9001-Prozessen des Komponentenherstellers, wie zum Beispiel

Sicherheitspolitik des Unternehmens
Organisationsstruktur der Produktentwicklung innerhalb der Firma
Personal, Verantwortungen, bisherige Erfahrung
Prozessbeschreibungen
Standards und Vorlagen
Referenzen zum Qualitätshandbuch
Tooling/Tool-Validierung
Maßnahmen zur Fehlervermeidung und -beherrschung

Im Verification & Validation Plan (V&V-Plan) ist zu benennen, wie, wann, von wem, was verifiziert und am Ende validiert wird. Spätestens hier werden konkrete Mitarbeiternamen zu den Projekt­rollen genannt. Zudem lassen sich hier auch Dokumentenplanung, Versionierung und das Änderungsmanagement beschreiben.

Safety Requirements und Safety Integrity Requirements nach IEC 61508-2 und IEC 61508-3 sind systematisch (bei mittleren und großen Projekten mit einem datenbankbasierten Werkzeug) zu erfassen. Damit sind die normativ geforderten System Design Requirements, Hardware Safety Requirements und Software Safety Requirements erfüllt. Die Dokumente werden von den Verantwortlichen inspiziert mit dem Ziel der Vollständigkeit, Konsistenz, Korrektheit und Verständlichkeit und dann zur Konzeptprüfung freigegeben.

Die Konzeptprüfung

Im Rahmen der Konzeptprüfung findet eine Bewertung der Safety Requirements, der Diagnosemaßnahmen, der Sicherheitsarchitektur, des techischen Safety Concept (wie wird die sichere Funktion im Produktdesign umgesetzt) sowie des Managements der funktionalen Sicherheit gemäß Safety Plan und V&V-Plan statt. Die maßgebliche Frage lautet dabei: Ist diese Elektronikentwicklung nach den Kriterien der IEC 61508 durchführbar? Das Ergebnis ist ein Statusbericht mit einer entsprechenden Liste der Befunde, welche entsprechend dem Änderungsprozess zu beheben sind. Nach der Konzeptprüfung und Freigabe kann die eigentliche Entwicklung nach dem V-Modell beginnen.

Bild 1. V-Modell: Systemtests verifizieren die Requirements, Integrationstests das Design. Beide Testarten werden nicht vom Entwickler, sondern von einem unabhängigen Tester durchgeführt. Weitere Verifikationsmaßnahmen sind Phasen-Output-Reviews.

© Mesco

Parallel zu allen Phasen läuft der Assessment-Prozess mit geplanten Reviews und Berichten an. Während aller Entwicklungsphasen muss das Vier-Augen-Prinzip gelten (geplante, protokollierte Reviews mit Freigabe durch benannte Personen). Wichtig dabei ist, dass ein Autor nicht selbst sein Werk verifizieren darf. Eigenschaften und Änderungen müssen nachvollziehbar sein (Traceability), im einfachsten Fall mit einer Traceability-Matrix.

Nun kann das Design beginnen: Für das Software-Design mag die Verwendung eines UML-fähigen CASE Tool mit möglicher Anbindung an die Requirements-Datenbank hilfreich sein. Dadurch werden weitere Fehler vermieden und die Nachvollziehbarkeit (Traceability) sichergestellt. Nützlich ist hier zudem die Umsetzung eines klaren Schichtenmodells mit entsprechenden Abstraktionsebenen. Das fertige Software-Design kann bei Bedarf einer Software-Kritikalitätsanalyse (SWCA) unterzogen werden, in deren Rahmen alle Operationen in Bezug auf ihren Einfluss auf sicherheitskritische Funktionalität klassifiziert werden. Das Ergebnis sind Maßnahmen zur Fehlervermeidung oder -beherrschung, die im Design nachträglich einzubringen sind.

Auch beim Hardware-Design kommen Tools für Worst-Case-Berechnungen und Simulation zum Einsatz. Nach Erstellung des Hardware-Schemas sollte eine FMEDA auf Bauteilebene durchgeführt werden, um die erreichte PFH/PFD und andere Sicherheitskennzahlen für jede Sicherheitsfunktion zu bestimmen. Das Design ist jetzt abgeschlossen.

Im nächsten Schritt werden Testfälle mit Referenz auf die betroffenen Anforderungen (Requirements) spezifiziert. Dabei kann es sinnvoll sein, zuerst Black-Box-Tests zu definieren, um die Gerätefunktionen sicherzustellen. Dabei werden Requirements übrig bleiben, die weitere Testfälle erfordern. Erfolgt die Spezifikation aller Tests ebenfalls Datenbank-basiert, lässt sich die Testabdeckung zum Teil automatisiert gewährleisten. Den Abschluss bildet schließlich ein Review der Phasenergebnisse durch dafür qualifizierte Personen.

Layout, Musterbau und Code-Generierung

Es folgt die Phase, in der das Layout erarbeitet wird sowie Prototypen hergestellt und diese in Betrieb genommen werden. In der Software wird gemäß der Designspezifikation ein kompilierbarer Code entworfen. Zur Qualitätssicherung sind statische Codeanalysen (zum Beispiel gegen MISRA-C), der Einsatz von Software-Metriken, Unit Testing (auf Operationsebene, automatisiert) und Code Coverage Tests unerlässlich. Die Methode der defensiven Programmierung (Überprüfen von Voraussetzungen, bevor eine C-Operation ihren eigentlichen Zweck erfüllt) sollte angestrebt werden und ist teils normativ gefordert.

Bild 2. Ein Testingenieur verifiziert die Elektronik nach Inbetriebnahme im Rahmen von Integrationstests – eine Verifikation des HW-Designs.

© Mesco

Fertiggestellte Prototypen/Funktionsmuster werden mit einer Test-Software in Betrieb genommen, um Schnittstellentests durchzuführen. Die Integration ist beendet, wenn die Hardware beweisbar funktioniert. Das spart Zeit bei der Fehlersuche. Erst jetzt erfolgt die komponentenweise Integration der entwickelten sicheren Software auf der neuen Hardware. Am Ende dieser Phase steht ein Muster mit lauffähiger Software zur Verfügung.

Nach der Integration wird zum einen die Hardware verifiziert (Integrationstests). White-Box Tests im Bereich Hardware an ein bis zwei Mustern (Signalpegel und -form, Ströme, Temperaturverhalten) verifizieren das Design. White-Box Tests im Bereich Software (Timings, Interrupts, Belastung, Teil-Funktionalität) verifizieren auch hier funktionale Blöcke. Fault Insertion Tests in Hardware und Error Seeding in der Software dienen der Beweisführung, dass zufällige und systematische Fehler auch wirklich funktional sicher beherrscht werden. Zum anderen werden alle SW-Funktionen gemäß den Requirements verifiziert und auf der Hardware validiert.

Was jetzt noch fehlt, sind Black-Box Tests auf Systemebene. Sie sind für alle Systemfunktionen durchzuführen, die sich auf externe Schnittstellen auswirken. Dazu gehören Funktionstests unter Normalbedingungen, Temperaturtests wie auch EMV-Tests und Umwelttests gemäß den anzuwendenden Normen. Die Testergebnisse werden in separaten Berichten – nicht in der Testspezifikation – so dokumentiert, dass jeder Test reproduzierbar ist. Daraus folgt, dass automatisierte Tests in jedem Fall zu bevorzugen sind. Alle Berichte sind aufzubewahren und Mängel gemäß dem definierten Änderungsprozess zu bewerten und zu beseitigen.

Funktioniert das Produkt nach allen Spezifikationen korrekt, so kann das Produkt zur Zertifizierung eingereicht werden. In diesem Rahmen erfolgt eine Begutachtung der gesamten Entwicklungsdokumentation und es wird nachvollzogen, inwieweit der oder die Entwickler die Anforderungen der IEC 61508 eingehalten haben (Abhaken von Normen-Checklisten). Stichprobenartig untersucht dabei der Prüfer der benannten Stelle alles auf Konformität zur Sicherheitsnorm: von der Organisation über Review-Berichte bis auf Einzelbauteilebene (Hardware) und Codezeile (Software). Nach Schließen aller offenen Punkte wird der Assessment-Bericht abgeschlossen und der zuständigen Stelle vorgelegt, die schlussendlich das angestrebte Zertifikat erteilt.

Autor: Andreas Keller leitet als TÜV Functional Safety Engineer die Technikgruppe „Funktionale Sicherheit“ bei Mesco, Lörrach.