Funktionale Sicherheit in der Softwareentwicklung

Die Software übernimmt Funktionen, welche an Komplexität und Genialität der Hardware kaum das Wasser reichen kann. Funktionale Sicherheit in der Softwareentwicklung ist wichtiger denn je. Leider ist das Verständnis der Softwareentwickler für dieses Thema kaum vorhanden oder es ist wenig Interesse vorhanden, da FuSi assoziiert wird mit Dokumentation, der Auseinandersetzung mit fragwürdigen Fragestellungen und scheinbar nicht agil ist. Oft wird Funktionale Sicherheit in der Softwareentwicklung als “alt”, als “innovationsbehindernd” oder einfach nur “lästig” wahrgenommen und IMMER im Aufwand und geistigen Anspruch unterschätzt. Die folgenden Ausführungen sind dem 3. Teil der IEC 61508 entnommen und zeigen die Ziele der FuSi für die Software auf. Für mehr Verständnis.

Realisierungsphase für sicherheitsbezogene Software

Der Umgang mit sicherheitsbezogener Software stellt an das Management eine Reihe von Anforderungen, welche sich von denen der Systementwicklung und der Hardwareentwicklung unterscheiden. Dabei wird oft von dem Software-Sicherheitslebenszyklus (SW-SLC) gesprochen, welcher i.d.R. nach V-Modell umgesetzt wird, wie in der IEC 61508 Teil 3 erwähnt. Funktionale Sicherheit und Softwareentwicklung sind historisch zusammengewachsen. Ursprünglich wurden Sicherheitsfunktionen hardwarelastig realisiert, da die Softwareentwicklung noch unbekannt war.

Der Normteil “3” zur Funktionalen Sicherheit nach IEC DIN EN 61508 ist im Beuth-Verlag hier verfügbar.

Die funktionsorientierte Entwicklung findet mehr und mehr in PE-Systemen in der Softwareebene statt. Dabei ist insbesondere das Konfigurationsmanagement bedeutend mit folgenden Aspekten:

  • Kontrollmechanismen eines typischen Änderungsmanagements zur technischen Verwaltung von Modifikationen im SW-SLC
  • Tätigkeiten zum Erhalt der systematischen Eignung
  • Konfigurationsmerkmale zum Erreichen und Erhalt der Sicherheitsintegrität:
    • Sicherheitsanalysen
    • Sicherheitsanforderungen
    • Spezifikation und Architekturentwurf
    • Softwaremodule in Programmiersprache / Source-Code
    • Testplan und Testauswertungen
    • die zu integrierenden Softwarepakete und existierende Softwareelemente mit passender systematischer Eignung
    • Entwicklungsumgebung
    • Werkzeuge wie Prog.-interface/Debuger/Testinterface
  • Änderungskontrolle im Sinne eines Change Request Managements mit den Ziel:
    • nicht autorisierte Modifikationen verhindern
    • die Modifikationsanforderungen dokumentieren
    • leicht verständliche Einflussanalysen durchführen zu können, um Änderungsanforderungen entscheiden zu können
    • der Dokumentation der genehmigten Modifikationen (verantwortliche Personen, Aufgaben, betroffene Dateien/Dokumente usw…)
    • der Dokumentation von Zeitpunkt der Konfiguration und Umfang neuer Integrationstests
    • des Konsistenzerhalts aller Anforderungen an die Software
  • Methoden zum Laden gültiger Daten und gültiger Softwareelemente in das Laufzeitsystem, insbesondere ist die Trennung von Firmware und Applikationsebene zu beachten.
  • Informationen für das Audit zur Funktionalen Sicherheit:
    • Konfigurationsstatus und Version
    • Ergebnisse der Einflussanalyse
    • Modifikationsdaten (Genehmigung und Änderungen)
  • Freigabe-Bericht
  • Software, Versionen der verwendeten Daten, Dokumentation und die Softwarekopien zwecks Wartbarkeit während der Betriebslebensdauer der freigegebenen Softwareversion

Das V-Modell-artige bzw. Wasserfall-Vorgehen, also das Planen, Verifizieren, Analysieren, Dokumentieren und Ausführen der Tätigkeiten steht in Konflikt mit den agilen Vorgehensmodellen. Hybride Vorgehensmodelle sind möglich, erfordern jedoch kommunikationsintensive Synchronisierungspunkte und erzeugen mehr Verifikationsarbeiten, welches im Sinne der Gesamteffektivität schädlich ist.

Das agile Manifest stellt die Menschen und das Handeln über Prozesse, Werkzeuge, Verträge und Planung während die Fehlerhypothesen der Funktionalen Sicherheit u.a. den Menschen als Fehlerquelle benennen und diese Fehler vermieden werden sollen mit Maßnahmen gegen systematische Fehler und strukturierten sowie dokumentierten und gelebten Prozessen.

Die Ziele und Anforderungen der verwendeten Norm zur Funktionalen Sicherheit sind auf andere Vorgehensmodelle übertragbar, jedoch ist der Nachweis zu führen, dass alle Ziele, welche durch das V-Modell erfüllt sind, auch durch das Agile- bzw. Hybrid-Modell erfüllt wird. Dies ist beisweilen in Teilaspekten unmöglich, birgt Risiken und gefährdet den Zertifizierungserfolg. Wenn man die IEC 61508 ganzheitlich betrachtet, dann ist auf der Idealseite scheinbar keine Iteration notwendig. Man plant und führt aus. Der Entwurf in der Entwicklungs- und Entwurfsphase ist jedoch als iterativer Prozess explizit gefordert. Weiterhin fordert die Norm Analysen und folglich sind neue Erkenntnisse aus Analysen in die Top-Level-Spezifikation zurückzuführen. Erfahrungen in neueren Normen wie im Automobilbereich (ISO 26262) zeigen, dass das V-Modell mit Iterationen und mit schlanken Änderungsmanagementprozessen auch etwas dynamischer sein kann. Ein dynamisches Tracking der Ziele und Anforderungen der FuSi in einer integrierten Entwicklungsumgebung mit agilen Vorgehen wäre ein interessanter Ansatz.

SCRUM-Hardliner bewerten diese Versuche als  “nur iteratives V-Modell” und lehnen dies ab. Es sind verschiedene Konzepte einer hybriden Prozessstruktur oder auch die Trennung möglich. Als dies führt aus meiner Erfahrung im Endeffekt nur dazu, dass sich die Projektkosten signifikant erhöhen, Young-High-Potentials teils nur im agilen Arbeitsumfeld verbleiben wollen und die Nachweisführung aufwendiger und damit letzendlich die Beurteilung zur Funktionalen Sicherheit sowie der Zertifizierungserfolg gefährdet ist. Weiterhin ist die Technologie und der SIL entscheidend für die Aufwände und damit für die Projektkosten und Prozessaufwände.

Ein effektives und schlankes V-Modell ist wirtschaftlicher als rein agile Vorgehensweisen mit einem Safety-Schattenprozess zu ummanteln. Wenn Funktionale Sicherheit in der Softwareentwicklung agil sein soll, dann empfehle ich die Gesamtsicherheitsebene nach V-Model, ein 3 Ebenenkonzept mit Funktionsebene, Überwachungsebene und Sicherheitsebene, wobei die Funktionsentwicklung agil erfolgen kann und Verifikations- sowie die Gesamtintegration wiederum nach V-Modell auf Gesamtsicherheitsebene erfolgt. Kostengünstig ist nur der vollständig integrierte V-Modell-Ansatz bevorzugt auch mit formalen Methoden, wenn der SIL höher als 2 ist. Hierbei ist die Unternehmenkultur oft mit Konflikten konfrontiert.

Übrigens, es geht im Endeffekt um das Risiko und Verantwortung, um Menschenleben, um Produkthaftung, Zivilhaftung und um Umsatzverluste durch erfolglose Zertifizierung oder Imageschäden. Spaß am Entwickeln muss nicht nur durch agile Methoden entstehen, sondern kann auch durch ein effektives und schlankes V-Modell entstehen. Wer sicherheitsbezogene E/E/PE-Systeme entwickeln möchte, der spielt nicht sondern entwickelt verantwortungsvoll durch Struktur, Disziplin, Wisssen und einer gelebten Sicherheits- und Fehlerkultur.

Der Software-Sicherheitslebenszyklus

Die Norm gibt als Beispiel das V-Modell vor, um die folgenden Phasen und Tätigkeiten für PE-Systeme zu strukturieren:

  • Sicherheitsanforderungsspezifikation (Funktion, systematische Eignung (SC), SIL-Attribut, Implementierung)
  • Validierungsplan
  • System-Softwareentwurf (Architektur, HW-SW-Interface und deren Wechselbeziehungen)
  • System-Softwareentwicklung (z.B. IDE, Sprache, Compiler, Laufzeitschnittstelle, Datenformate, Anwenderschnittstelle, Darstellung z.B. in UML, um V&V, Beurteilung und Modifikation leicht zu ermöglichen)
  • Modul-/Code-Entwicklung (analysierbar, prüfbar, modifizierbar)
  • Modultest (Verifikation, ob erforderliche Funktion und systematische Eignung erreicht wurde und frei von unerwünschten Funktionalitäten ist und dabei PE-Systemkonfiguration beachten)
  • Software-Integrationstest (Verifikation wie Modul-Verifikation nun im Interaktionszusammenhang, dabei PE-Systemkonfiguration beachten)
  • HW-SW-Integrationstest (Zielhardware-Integration mit Verträglichkeitsprüfung)
  • Betriebs- und SW-Modifikationsverfahren (Erhalt der erreichten Integrität sicherstellen, z.B. Schreibschutz sowie deren Genehmigungsprozesse)
  • Software-Validierung für Sicherheitsaspekte

Die Phasen sind durch Verifikation auf Konsistenz zu prüfen und in einem Bericht zu dokumentieren. Weiterhin sind Modifikationen und dadurch mögliche Iterationen der Phasenabschnitte koordiniert, begründet und strukturiert zu planen und auszuführen.

Bei der Planung der Aktivitäten auf SW-Ebene, sind angemessene Verfahren/Maßnahmen nach den Tabellen in den Anhängen A und B in Teil 3 der IEC 61508 auszuwählen. Ziel dabei ist, die notwendigen Eigenschaften zum Erreichen der systematischen Eignung in der Entwicklungsmethodik sicherzustellen. Dabei sollten folgende Faktoren berücksichtigt werden: wenig Toolbrüche, sich ergänzende Eigenschaften, Verständlichkeit/Qualifikation der Nutzer sowie die Anpassbarkeit bei Prozessinkonsistenzen. Die Faktoren werden wiederum durch die Architektur und damit durch die Technologie bestimmt. Die Verantwortlichkeiten in der SW-Ebene und dem SW-Sicherheitslebenszyklus müssen durch das Funktionale Sicherheitsmanagement festgelegt werden. Es müssen Vorgehensmodelle gewählt werden, welche den Grundsätzen wie z.B. der Planbarkeit, Kapselung(Phasen/Aktivitäten), Zuordnung von Verantwortlichkeit, Dokumentierbarkeit, Chronologie und V&V entsprechen.

Der Software-Sicherheitslebenszyklus im Modifikationsfall

Funktionale Sicherheit in der Softwareentwicklung bedeutet erst Planung und dann Entwicklung. Modifikationen treten regelmäßig in der Integrationsphase, der Betriebsphase bzw. auf Gesamtsystemebene im Sinne von Installation und Inbetriebnahme auf. Daher sind Modifikationen nicht selten und oft Quelle systematischer Fehler. Daher ist die Modifikation, wie die Instandhaltung auf PE-Systemebene, ordnungsgemäß durch ausgewählte Verfahren zu spezifizieren und auszuführen.

Nur eine sichere Modifikation – mit bekannten Verfahren wie Auswirkungsanalyse, Planung erforderlicher Aktivitäten im Sicherheitslebenszyklus, Autorisierung und deren Dokumentation – kann effektiv den Erhalt der systematischen Eignung der Software gewährleisten.

Es ist also für die Funktionale Sicherheit in der Softwareentwicklung notwendig, dass die Modifikationsverfahren frühzeitig geplant und vorgehalten werden. Die systematische Eignung der Software hängt an vielen Faktoren wie z.B. Merkmale der Architektur, Werkzeuge und den V&V-Aktivitäten. Eine unbefugte Code-Änderung wäre gleichbedeutend mit dem Verlust der systematischen Sicherheitsintegrität! Daher müssen starke organisatorische und technische Strukturen vorhanden sein. I.d.R. beginnt alles mit Auffälligkeiten, welche grob in zwei Klassen geteilt werden können, zum einen Auffälligkeiten im Sicherheitslebenszyklus wie z.B. die späte Identifikation systematischer Fehler oder ein FuSi-Audit und zum anderen Umwelt-Faktoren wie Änderung des EUC oder der Gesetzgebung.

Die Planung und Autorisierung muss auf Grundlage folgender Informationen beruhen:

  • Modifikationsvorschlag und dessen Bezug zu potenziellen Gefährdungen (Modifikationsgrund und Auffälligkeit)
  • Einfluss- bzw. Impactanalyse auf:
    • G&R (Worst-Case-Fall für das Projekt: ein erhöhter SIL)
    • Identifikation notwendiger erneuter Ausführungen von Aktivitäten im Sicherheitslebenszyklus ggf. auf allen Ebenen

Daraus ist ein Sicherheitsplan abzuleiten durch das FSM, wie nach Teil 1 Abschnitt 6 gefordert, mit Nennung der Verantwortlichen und qualifizierten Personen, die genaue Spezifikationsänderung und die daraus resultierenden V&V-Aktivitäten. Es handelt sich quasi um eine partielle Iteration im Sicherheitslebenszyklus, welche nachweislich im Bezug zur Modifikation stehen muss (Kapselung und Nachvollziehbarkeit der Modifikation). Dabei sind folgende Einzelheiten zu dokumentieren:

  • Der Modifikationsgrund und die Einflussanalyse
  • Begründete Entscheidungen, welche die Beurteilung zum Erhalt der FuSi und der erforderlichen systematischen Eignung als Grundlage haben
  • Berücksichtigung des SW-Konfigurationsmanagements
  • Abweichungen der Betriebsbedingungen (z.B. erwartete Umgebung hat sich verändert)
  • alle sonstigen dokumentierten Informationen

Die Softwareverifikation

Die IEC 61508 gibt klare Vorgaben an den Sicherheitslebenszyklus. Er muss strukturiert sein und deutlich abgrenzbare Phasen aufweisen. Die Verifikationstätigkeit selbst tritt auch als Phase im V-Modell rechte Seite auf (SW-Modultest und die Integrationsstufen), ist aber im eigentlichen Sinn ein Verfahren zur Überprüfung der Ausgaben einer Phase bezogen auf die Konsistenz und Korrektheit der Eingaben dieser Phase. Eine gemeinsame Planung mit der Validierung ist oft sinnvoll im Rahmen einer ganzheitlichen Projekt-V&V-Planung unter Berücksichtigung der erforderlichen Sicherheitsintegrität, dem Unabhängigkeitsgrad, den Verifikationsstrategien/-Verfahren sowie die Werkzeugauswahl, die Bewertung der Verifikationsergebnisse und notwendigen Berichtigungsprozeduren. In der Maschinenanwendernorm ISO 13849 sind bereits einige Entscheidungen zum Thema Verifikation zu Gunsten einer “pragmatischen Kochrezeptlösung” gefallen, welche dem Anwendungsbereich ausreichend ist. Neue Technologien mit hoher Komplexität und hohen Neuheitsgrad und vielen Beteiligten erfordern oft eine feingliedrigere Verifikationsstrategie als die bekannten Entwurfsverfahren im Maschinenbau nach Art der Regallösung (man nehme eine Safety-SPS und konfiguriere ….) für einfache Funktionen und deren Absicherung.

Die Dokumentation der Verifikation muss die verifizierten Aspekte/Themen/Anteile/Objekte enthalten sowie die relevante Information, welche verifiziert werden soll und deren evtl. vorhandenen Abweichungen.

Die nach einer Phase entstandenen Arbeitsprodukte, welche in der nächsten Phase Verwendung finden, müssen wie folgt vorhanden und verifiziert sein in:

  • der Angemessenheit bezogen auf
    • die Funktionalität in der Spezifikation, Entwurf (Architektur) oder Code
    • die Sicherheitsintegrität, die Leistungsfähigkeit, Planbarkeit und systematische Eignung
    • sichere Modifikation
    • Lesbarkeit für Entwickler
    • Prüfbarkeit
  • der angemessenen Planung im Hinblick auf die Validierung, um den Entwurf spezifizieren zu können.
  • Unverträglichkeiten zwischen Test und Vorgängerphasen-Test sowie Informationen innerhalb der Phase (z.B. widersprüchliche Dokumente)

Die IEC 61508 gibt für das V-Modell einige Verifikationstätigkeiten der Linken Seite vor wie die folgenden:

  • SW-Sicherheitsanforderungspezifikation vor Entwurf&Entwicklungsphase:
    • Erfüllungsgrad der SW-Sicherheitsanforderungsspezifikation zur Systemspezifikation nach Teil 2 (erfüllt Funktion, Sicherheitsintegrität, Leistungsfähigkeit usw…)
    • Erfüllungsgrad des SW-Validierungplans zur SW-Sicherheitsanforderungspezifikation
    • Unverträglichkeitsprüfung der SW-Sicherheitsanforderungspezifikation gegen Systemspezifikation sowie den Validierungsplan
  • SW-Architektur nach ihren Entwurf:
    • Erfüllungsgrad der SW-Architektur zur SW-Sicherheitsanforderungspezifikation
    • Angemessenheit der SW-Integrationstestspezifikation zur SW-Architektur
    • Angemessenheit der Hauptkomponenten- und Teilsystem-Eigenschaften (Durchführbarkeit der sicherheitstechnischen Leistungsfähigkeit, Testbarkeit, Lesbarkeit, Modifizierbarkeit für RTOS, Diaganose usw…)
    • Unverträglichkeitsprüfung zwischen der SW-Architektur und der SW-Sicherheitsanforderungspezifikation sowie der Integrationstestspezifikation
    • Unverträglichkeitsprüfung zwischen der Integrationstestspezifikation und dem SW-Validierungsplan
  • SW-Feinarchitektur nach ihren Entwurf:
    • Erfüllungsgrad zw. SW-Architektur-Feinentwurf und SW-Architektur
    • Erfüllungsgrad zw. SW-SW-Integrationstestspezifikation und dem SW-Architektur-Feinentwurf
    • Angemessenheit der Elemente-Eigenschaften (Durchführbarkeit der sicherheitstechnischen Leistungsfähigkeit, Testbarkeit, Lesbarkeit, Modifizierbarkeit usw…)
    • Unverträglichkeitsprüfung zwischen der SW-Architektur-Feinentwurf-Spezifikation und der SW-Architektur sowie der SW-Integrationstestspezifikation
    • Unverträglichkeitsprüfung zwischen den Testspezifikationen der beiden SW-Architekturebenen (SW-Architektur und SW-Feinarchitektur)
  • SW-Modul-Entwurf:
    • Erfüllungsgrad zw. der SW-Modulspezifikation und SW-Feinarchitektur
    • Angemessenheit der SW-Modul-Testspezifikation und der SW-Modulspezifikation
    • Angemessenheit der SW-Modul-Eigenschaften (Durchführbarkeit der sicherheitstechnischen Leistungsfähigkeit, Testbarkeit, Lesbarkeit, Modifizierbarkeit usw…)
    • Unverträglichkeitsprüfung zwischen der SW-Modulspezifikation und der SW-Feinarchitektur sowie der SW-Modul-Testspezifikation
    • Unverträglichkeitsprüfung zwischen der SW-Modulspezifikation und der SW-Modul-Testspezifikation (je Modul, um Überschneidungen oder fehlende Tests zu identifizieren)
    • und Unverträglichkeitsprüfung zwischen der SW-Modul-Testspezifikation und der SW-Integrationsspezifikation
  • Verifikation:
    • der Codes mittels statischer Methoden mit dem Ziel der Übereinstimmung mit den Modulebenen (SW-Modulspezifikation, Programmierrichtlinien, SW-Validierungsplan)
    • der verwendeten Daten (Strukturen, Anwendungdaten, Betriebsparameter, Schnittstellen (Detektionsvermögen, Fehlertoleranz, Schutz und Validierung))
    • des zeitlichen Leistungsverhaltens (WCET usw…) mit “endlicher Zeit kleiner als Fehlertoleranzzeit”

Es sind also Angemessenheit/Erfüllungsgrad und Verträglichkeit in der Verifikation zu bewerten durch Betrachtung der Arbeitsprodukte gegen das Verifikationsobjekt. Der Umfang dieser Tätigkeiten/Methoden/Verfahren skaliert mit dem SIL.

Die V&V-Planung ist nicht zu unterschätzen! Mehrere “geschachtelte V-Modelle” sind linksseitig Einzelfäden, welche rechtsseitig zusammenfließen. Hier besteht Potenzial für unverhältnismäßige Testüberdeckungen und Testunterdeckung bei falscher Planung und schlecht strukturierter linker Seite. Die Verifikation hat daher zum Ziel, durch Ermittlung der Erfüllungsgrade und Bewertung wie Angemessenheit von Eigenschaften und der Unverträglichkeitsprüfung zwischen den Spezifikationen, eine Konsistenz sowie Testabdeckung zwischen den Ebenen nachzuweisen. Codeverfikation und SW-Modultest sollen sicherstellen, dass der Code die Spezifikation vollständig abbildet, während die Integration und die Integrationstests die Verträglichkeit der ausführbaren Codes-Teile auf dem Weg zum integrierten System sicherstellen sollen. Beides sind Verifikationstätigkeiten, welche ihren “Grenzübergang” im SW-Modul haben.

Die Software-Sicherheitsanforderungsspezifikation

Funktionale Sicherheit in der Softwareentwicklung bedeutet Sicherheitsanforderungen und Anforderungen zum Erhalt und/oder Erreichen der systematischen Integrität vor der Umsetzung zu spezifizieren. Jedes sicherheitsbezogene E/E/PE-System, welches eine Sicherheitsfunktion ausführt, muss vollständig spezifiziert werden. Jedem sicherheitsbezogenen E/E/PE-System, welches eine oder mehrere Sicherheitsfunktion(en) mit ein Sicherheitsintegritätslevel (SIL) ausführen soll, muss mit ein oder mehreren Software-Elementen mit passender systematischen Eignung spezifiziert werden. D.h. eine SIL zu SC Beziehung für SW-Elemente ist herzustellen.

Die Anforderungsspezifikation auf Software-Ebene richtet sich nach dem Sicherheitskonzept auf Systemebene. D.h. es können Merkmale der Systemarchitektur und der Hardware wesentlichen Einfluss haben auf die Struktur der Software-Anforderungsspezifikation. Sind Funktion und Sicherheitsfunktionen wechselwirkungsfrei abzubilden und dies evtl. im Sinne einer Partition ? Die notwendige Trennung der Firmware und Anwendungssoftware gibt z.B. auch Spezifikationsattribute vor. Eine rein funktionale Anforderung kann sich von einer Sicherheitsanforderung z.B. im Namen (z.B. F-REQ und S-REQ) und einem Attribut (SIL) unterscheiden. Oft sind Softwarearchitekturen von der verwendeten Technologie und dem Sektor bzw. der Branche geprägt. Die Erfahrung des Systemarchitekten, die Technologie und die interdisziplinäre Zusammenarbeit sowie die Präsenz eine Softwarearchitekten sind wichtige Erfolgsfaktoren, um Funktionale Sicherheit in der Softwareentwicklung schlank und effektiv umzusetzen. Ein hardware naher Programmierer oder ein Modulentwickler kann komplexe Softwarearchitekturen nicht überblicken. D.h. dass die Sicherheitsanforderungsspezifikation von der Funktionalen Sicherheit zusammen in einem interdisziplinären Team entwickelt werden sollte.

Wie für jede Sicherheitsanforderungsspezifikation auf den anderen Ebenen (Gesamtsystem, Hardware) gilt auch hier:

  • Vollständigkeit
  • Korrekheit
  • Verständlichkeit
  • Eindeutigkeit und Fehlerfreiheit
  • Wechselwirkungsfreiheit
  • Testbarkeit (V&V-Fähigkeit)

Die Softwareanforderungsspezifikation muss von der E/E/PE-Systemebene zwecks Vor- und Rückverfolgbarkeit (Traceability) abgeleitet werden. Die Wechselbeziehung zwischen Hardware und Software führt i.d.R. zu Iterationen und gegenseitiger Beeinflussung der Anforderungsspezifikationen von Hardware und Software. Oft ist besonders der Übergang von der physikalischen Welt in die Welt der Software von missverständnissen geprägt, welche potenziell Quellen systematischer Fehler sind. Im Rahmen von funktionsorientierter Entwicklung ist eine Verarbeitungskette mit Wert, Konvertierung, Reskalierung, Normierung, Genauigkeit und Toleranz angefangen vom Sensor/Aktor bis hin zur/von der Software sinnvoll über die Ebenen abzuleiten. Die ISO 26262 fordert z.B. explizit eine Hardware-Software-Interface (HSI) Spezifikation.

Oft werden Teilfunktionen bereits auf Systemebene auf Grundlage von bereits entwickelten bzw. existierenden Software-Elementen in die Softwareanforderungsspezifikation bzw. den Softwareentwurf eingebracht. Die systematische Eignung in der gesamten Softwarearchitektur muss erhalten beleiben. Wenn z.B. ein sicherheitsrelevanter Com-Stack als zertifiziertes Softwarelement nach Pfad S3 in eine Gesamt-Softwarearchitektur nach Pfad S1 integriert werden würde, so ist bei der Verifikation der Softwaresicherheitsanforderungsspezifikation für diesen Aspekt ein erhöhter Aufwand notwendig.

Um die erforderliche Sicherheitsintegrität zur erreichen und eine Beurteilung zu ermöglichen, ist der Umfang bzw. Grad an Details in der Spezifikation abhängig von der Systemkomplexität. Multi-Core-Umgebungen oder Mehrkanalige Systeme mit mehreren Zeitquellen, welche verteilte Redundanz sowie replika-deterministische Strukturen bilden, müssen umfangreich und deteilreich in der Spezifikation behandelt werden. Funktion, Zeitverhalten, Genauigkeit, Kapazität, Überlastungstoleranz (z.B. INT-Burst oder COM-Buffer), Robustheit sowie technolgiespezifische Merkmale sind zu berücksichtigen.

Dort wo Wechselwirkungsfreiheit und Koexistenz von Funktionen mit sowie ohne sicherheitsbezug gefordert ist, sind Analysen gemeinsamer Ursache durchzuführen und ggf. die Spezifikation um Maßnahmen (z.B. Partitionierung, Priorisierung) gemäß der Analyseergebnisse zu ergänzen. Bei der Analyse gemeinsamer Ursachen sind oft räumliche und zeitliche Faktoren sowie Kopplungsmechanismen zu identifizieren. Ist auf Systemebene ein 3 Ebenenkonzept vorgesehen, so wird sich dies bereits in der Softwareanforderungsspezifikation niederschlagen und ggf. den Analyseumfang reduzieren. Wenn z.B. ein zertifiziertes Betriebssystem verwendet werden soll, welches für die 2 Ebenen (Funktion und Überwachung/Diagnose) eine Unabhängigkeit in der Ausführung bereitstellt z.B. durch einen passenden Scheduler/Taskmanager und die Inter-Task-Kommunikation mit einer Art End-to-End-Com-Layer abgesichert wird, so wird die Beachtung der Anforderungen im Sicherheitshandbuch für dieses zertifiziertes System die Analysetätigkeit für diese Aspekte überschaubar werden lassen.

Die Analyse gemeinsamer Ursachen des Software-Architekturentwurfs muss folgende Aspekte berücksichtigen und dabei Begründungen zu liefern, warum diese Aspekte die Unabhängigkeit nicht verletzen können:

  • gemeinsam genutze Ressourcen (z.B. CPU, RAM, I/O)
  • Task-Kommunikation:
    • intern oder auf mehrere Rechner verteilt
    • Semaphore oder Nachricht
    • Priorität und Wahrung der End-to-End-Priorität
    • Synchronisierung (Synchron/Asynchron -> Blockade)
  • Folgeversagen (Element A hat Fehlereignis wie Pointer-Fehler, Überlauf, Div NULL und Element B verwendet diese Fehlinformationen)

Sie können viel Zeit für die Analyse und Entwicklung von Sicherheitsmechanismen aufwenden. Denken Sie allein an einen Task-Kontext-Wechsel und den Erhalt der Taskkontextinformationen. Es empfiehlt sich für die Applikation ein passendes IEC 61508 zertiifiziertes RTOS zu verwenden. Generell wird gerne von dem Entwicklungsteam aufkommende Komplexität und deren Herausforderungen mit komplexen Lösungen begegnet. Es sollte durch Modularisierung, lose Kopplung und der funktionsorientierten Entwicklung, die Komplexität auf niedrigem Niveau gehalten werden. Die Analysedimensionen wie Zeit, Raum und Zustand sind klein zu halten. Beispielsweise sind viele Betriebsarten und Zustände im System nicht wünschenswert.

Im Rahmen der Zeitvorgaben wie der Fehlertoleranzzeit (FTZ) ist deterministisches Verhalten notwendig. Erlaubt die Kernanwendung eine deterministische Prozessordnung ? Wie sieht die Prozessverwaltung des Betriebssystems aus ? Zeitgesteuerte Architekturen (time triggered) oder strikte priorisierte Zeitsteuerung auf die Betriebsmittel wie die CPU ? Verwenden Sie evtl. eine asymmetrische Prozessorarchitektur (Kernfunktion und Regelfunktion) ? I.d.R. ist das Betriebssystem ein RTOS , welches Souverän ist gegenüber der Anwendung und damit meisst preemptiv ist, deterministisch und damit statisch-offline schedult. Wie werden die Peripherien verwaltet ? Konsistenz in Zeit und Raum um Unabhängigkeit und damit eine einfache Nachweisführung zu erlangen, ist wünschenswert.

Die Grenze zwischen strikter/harter Echtzeit und starker Echtzeit sind von der Anwendung und der Charakteristik (Fail-Safe / Operational) abhängig. Off muss die Anwendung Zeitgarantien sicherstellen, da das Umfeld (z.B. Betriebssystem) dies nicht immer sicherstellt. In mehrkanaligen redundanten Strukturen ist replika-deterministisches Verhalten eine Voraussetzung. Auch einkanalige Strukturen mit teilsweiser funktional diversitären Systemteilen müssen im Bereich der Fusion zumindest deterministisch sein, woebei die Werte-Unschärfe noch problematischer ist. Ein Airbag-System benötigt strikte Echtzeit, eine sicherheitsbezogene Maschinensteuerung kann auch mit starker Echtzeit ausreichend sein.

Die SW-Sicherheitsanforderungsspezifikation muss folgende berücksichtigen:

  • Sicherheitsfunktion(en)
  • Einschränkungen bezüglich HW und SW (z.B. Wann ist die Integrität der SW nicht mehr gegeben und muss dann die HW den sicheren Zustand herstellen ? Kann die SW das HW-Modul nach erfolgloser Plausibilisierung noch verwenden ? Die Einschränkungen beziehen sich auf Fehlertoleranz und Fehlerisolationseigenschaften, um eine ungehemte Fehlerausbreitung im System zu vermeiden)
  • Systemarchitektur (z.B. Kommunikation, externer Speicher usw…)
  • systematische Eignung der SW-Elemente
  • Systemkonfiguration (Bsp.: Ist der Safety-Controller im Lock-Step zu betreiben ?)
  • Leistung und Reaktionszeit (Mhz/MIPS/Interrupt-Kapazitäten/COM-Buffer/Jitter/Regelkreisfrequenz)
  • Hardwaresicherheitsintegrität (Verwendung von hardwarebasierenden Speicher-, Sicherungs-, Diagnose- und Schutzmechanismen wie z.B. ECC, MPU oder Sensor-BIST oder Aktor-Ansteuerung)
  • HMI, andere existierende Anwendungen im Umfeld, Einrichtungen, welche zur Fehlanwendung verwendet werden können (z.B. Reset-Button)
  • Überwachung/Diagnose und Testbarkeit:
    • SW-Selbstüberwachung
    • HW-Überwachung
    • Testintervalle von Tests der Sicherheitsfunktion im Betrieb
    • Möglichkeit der Testung der Sicherheitsfunktion im EUC-Betrieb
    • Softwaretestfunktionen für Wiederholungsprüfung (Low-Demand) und Diagnosetests
  • Kommunikationsmerkmale aus Systemkommunikationsfunktionen (s. Teil 2 Abschnitt 7.4.11)
    • Datenkonsistenz (z.B. ext. Datentyp -> System-Datentyp-> SW-Datentyp sowie deren Bezeichnung/Bedeutung)
    • Gültigkeit in Wert und Zeit
    • Durchsatz, Maximaldurchsatz/Auslastung und Reaktionszeit
    • Ausführungszeiten (Worst-/Best-Case) und Verklemmungen (z.B. COM-Dead-Lock)
    • Buffer-Überlauf oder unterschreiten (z.B. Leerlaufen des COM-Buffers bzw. Ablauf (Datum))

Es empfiehlt sich, die Betriebsarten der verschiedenen Systeme (z.B. EUC) mit denen des sicherheitsbezogenen PE-Systems abzustimmen und dies in der Software-Sicherheitsanforderungsspezifikation abzubilden. Wenn z.B. ein sicherheitsrelevantes PE-System i.d.R. vor dem Start des EUC einige Tests am Abschaltpfad (z.B. POST) durchführt und aufgrund einer Speicherzugriffsverletzung  im Betrieb das EUC in den sicheren Zustand bringt, jedoch durch eine Reset-Schleife den Erhalt des sicheren Zustandes gefährdet (z.B. oszillierendes Ventil), dann ist die Spezifikation unvollständig.

Die systematische Eignung von Software und Software-Elementen

Der Begriff “systematisch geeignet” beschreibt im Grunde eine Menge an Funktionen zur Softwaresicherheit, welche mit passendem Sicherheitsintegritätslevel (Verfahren und Maßnahmen zur Vermeidung systematischer Fehler) und unter dem Aspekt der Unabhängigkeit entwickelt und/oder vorhanden sind bzw. Schnittstellen zu solchen Funktionen vorhanden sind. Diese Funktionen zur Softwaresicherheit sind:

  • Detektion, Diagnose, Anzeige und Behandlung von HW-Fehlern (Sensor, Logik, Aktor) und SW-Fehlern
  • Online-Testing der Sicherheitsfunktionen
  • Offline-Testing der Sicherheitsfunktionen
  • Transition zum Erreichen und Erhalt des sicheren Zustandes
  • sichere Modifikation
  • Interface-Funktionen wie Schnittstellen zu Nicht-Sicherheitsfunktionen
  • Kommunikationsfunktionen zwischen sicherheitsrelevanten Elementen / Teilsystemen (s. Kapitel zur Kommunikation in Teil 2)
  • Interface-Funktionen zwischen der Software und dem PE-System (On- und Offline-Programmierwerkzeuge)

Die Funktionen müssen im Hinblick auf Leistung und Reaktionszeit ausreichen und aufeinander abgestimmt sein, um die Sicherheitsziele innerhalb der Fehlertoleranzzeit einhalten zu können.

Wenn z.B. ein SW-Element mit SC 2 eine Online-Testfunktion mit SC 1 verwendet, so wird die systematische Eignung der Software ohne weitere Maßnahmen an der Struktur nicht erreicht.

Je nachdem im welchen Umfeld/Bereich/Sektor die Software eingesetzt werden soll, wird diese Software Abstraktionsschichten enthalten. Meisst wird zwischen sicherheitsbezogener Anwendersoftware und sicherheitsbezogener Firmware/embedded Software unterschieden. Die Anwendersoftware wird je nach Komplexitätsgrad von dem Applikateur/Entwickler/Konfigurator mit Daten Konfiguriert. Dabei wird datengesteuert (Konfigurationsdaten) die Sicherheitsfunktion an die anwendungsspezifischen Gegebenheiten angepasst. Die ISO 13849 z.B. nennt hier die SRESW und die SRASW. Die EN 62061 stuft etwas feiner ab und die IEC 61508 zeigt in Teil 3, Anhang G sechs Systemarten und gibt in dieser Leitlinie die Möglichkeit den Sicherheitslebenszyklus anzupassen (SLC-Tailoring). Je nach Freiheitsgrad und Konfigurierbarkeit der Anwendung kann zwischen nicht änderbarer Systemfunktion bis zur vollständigen Änderung der Systemfunktion unterschieden werden. Es ist bekannt, dass ein Kontaktplan einer Sicherheits-SPS ohne Zugang zum Systemkern der Sicherheits-SPS die Sicherheitsintegrität durch systematische Fehler während der Konfiguration weniger gefährdet als ein System mit offenen und vollkonfigurierbaren System, dessen Anwender und Systemteil dem Anwender/Integrator/Konfigurator voll zugänglich sind.

Komplexe Systeme und Funktionale Sicherheit in der Softwareentwicklung erfordern i.d.R. eine Validierung nach der Installation durch kompetente Applikateure des Herstellers, welcher den Sicherheitslebenszyklus vollständig verwaltet. Wenn eine Sicherheitsfunktion in einem sicherheitsbezogenen PE-System per datengesteuerte Applikation im Sine eines Konfigurationsdatensatzes realisiert wird, so müssen die Sicherheitsanforderungen konsistent, mit passendem Ausdruck im erlaubten Bereich mit den gültigen Betriebsparametern kompatibel sein. Auch die Ausführungsreihenfolge, Datenstrukturen und Laufzeit muss bedacht werden.

Das User-Interface

Die Software muss funktionieren. Welche Komplexität dabei in der Software entsteht bzw. enstehen kann, ist für den Bediener irrelevant. Eine sichere Interaktion zwischen Mensch und Maschine kann nur durch eine intuitive Bedienung stattfinden. Dabei sind Betriebsparameter zu schützen, wenn Sie nicht in der Betriebsart benötigt werden oder diese den sicheren Umgang gefährden können. Je nach Bedienpersonal und dem Gesamtsicherheitskonzept, kann es notwendig sein, bestimme Betriebsparameter für bestimmte Personengruppen zugänglich zu gestalten. Dabei müssen Fehlerquellen wie Verfälschung, unbefugte Änderung oder ungültige Betriebsparameter in Wert, Zeit und Modifikationszeitpunkt in der Software-Sicherheitsanforderungsspezifikation berücksichtigt werden. Ein klares und eindeutiges, nicht zu tief geschachteltes Menü soll dem Bediener ein sicheres Bewusstsein der Auswirkungen seiner Handlungen am Maschieneninterface ermöglichen.

Die Validierung der Software

Wie bereits von der Systemebene bekannt, wird quasi während der Spezifikation die Validierungsplanung ausgeführt. Die Validierung der Software kann nur im integrierten System stattfinden. Daher ist die Planung der Validierung primär von der Systemebene ausgehend und basierend auf den allgemeinen Validierungsgrundlagen aus IEC 61508 Teil 1, Abschnitt 7.8. Der Software-Validierungsplan soll nur die sicherheitstechnischen Aspekte der Software berücksichtigen, welche zur Systemsicherheit beitragen. Die normativ geforderten Aspekte gliedern sich wie folgt:

  • Wann soll validiert werden (z.B. nach einem x.0 Release)
  • Wer ist Validierer
  • Die 4 Hauptklassen der EUC-Betriebsarten und deren Bezug zum Validierungssubjekt (Software bzw. Teilfunktion):
    • Vorbereitung (Einrichtbetrieb, Justage)
    • Hauptbetrieb (Start, Einlernen, Auto, Manuell, Halb-Automatik und Dauerbetrieb)
    • Unterbrechung (Instandhaltung, Rücksetzen, Abschaltung)
    • Abnormalitäten (vorhersehbare Fehlbedienung und Zustände (z.B. mechanisches Versagen verschleißbehafteter Teile)
  • Validierungsvorgehensweise (z.B. statistisch, analytisch, formal) mit dem Ziel, aufzuzeigen, dass:
    • die Sicherheitsfunkion und
    • die systematische Eignung der Software mit der Anforderungsspezifikation übereinstimmen
  • Validierungssetting bzw. Validierungsumgebungsbedingungen (z.B. kalibriertes Testwerkzeug)
  • Pass/Fail-Kriteria mit den
    • erforderlichen Eingangssignalen in Abfolge und Werten
    • erwarteten Ausgangssignalen in Abfolge und Werten bzw. deren Toleranzen sowie ggf. verwendete Kapazitäten wie z.B. Speicherbelegung
  • Auswerteprozeduren und Verfahren, um Abweichungen (Versagen) zu bewerten

Bei der Planung der Vorgehensweise sind statische/dynamische bzw. analytische/statistische Verfahren im manuellen und/oder automatisierten Verfahrensprozess auszuwählen. Ein besonderes Augenmerk liegt auf den Akzeptanzkriterien, welche objektiven Faktoren darstellen sollen und/oder durch Expertenurteil ausgewählt werden. Je nach Sicherheitsintegritätslevel ist nach IEC 61508 Teil 1, Abschnitt 8 eine Abstimmung mit der unabhängigen, beurteilenden Person im Hinblick auf den Umfang und Inhalt des Validierungsplanes für die Softwareaspekte der Systemsicherheit gefordert. Dabei ist auch eine Abstimmung bezüglich einer Anwesenheit der beurteilenden Person bei Tests erforderlich. Die Verwendung von qualifizierten Software-Werkzeugen im Rahmen der Validierung ist gemäß Tool-Landschaft/Werkzeug-Analyse und Klasse T2/T3 notwendig.

Sie können die Planung der Validierung für sicherheitsrelevante Softwareaspekte vollständig auf Systemebene der Validierung nach Teil 2 Abschnitt 7.7 führen.

Die Ausführung der Validierung der Software kann nur im integrierten Umfeld erfolgen. Daher ist die Phase der Validierung nach der Integration, als letzte Phase der Softwareentwicklung angeordnet unter Verwendung der folgenden Eingangsvorraussetzungen:

  • integriertes System liegt vor
  • Validierungsplanung liegt vor
  • definierten Verfahrensanweisung zum Erhalt der Sicherheitsintegrität für Modifikation und Pflege im Betrieb liegt vor

Die Validierung muss hauptsächlich durch Testen ausgeführt werden. Dabei kann mit Simulation der Eingangssignale oder erwarteten Ergebnissen und Anregeungen zum Erzwingen unerwünschter Systemreaktionen validiert werden.

Die Validierung erfolgt für jede Sicherheitsfunktion separat und dokumentiert mit folgenden Merkmalen:

  • Nachvollzieh- bzw. Rückverfolgbarkeit der Validierung im Bericht mit Chronologie der VAL-Tätigkeiten, gestützt durch Beschreibung und aussagekräftige Daten im passendem Zusammenhang fokusiert auf das Ziel der Validierung (Negativbeispiel: unverständliche Testdatensammlung oder Dokumentensammlung).
  • Bezug zur Version des Validierungsplanes gem. projektspezifischen Dokumenten-/Versionsmanagement
  • Testsetting (Kalibrierdaten, Werkzeuge/Betriebsmittel)
  • Validierungstätigkeiten mit Ergebnissen sowie Abweichungen von den Erwartungswerten

Bei Abweichungen müssen nachvollziehbare Analysen und notwendige Schritte (z.B. Modifikation, Reverifikation und Revalidierung) im SW-Sicherheitslebenszyklus geplant und ausgeführt werden.

Die Ausgabe der Phase zur Validierung von Aspekten der SW-Sicherheit sollte sein, dass anhand er Tests nachgewiesen wurde, dass die SW-Sicherheitsanforderungen erfüllt sind und die Abwesenheit von unbestimmten/ungewollten Funktionen angenommen werden kann. Weiterhin müssen die Testfälle, deren Ergebnisse und die Dokumentation selbiger für unabhängige dritte Personen/Parteien analysierbar und als Grundlage zur Beurteilung der Funktionalen Sicherheit nützlich sein.

Je nach Entwicklungslandschaft sind durch unterschiedliche Kapselungen der Entwicklungsaktivitäten und insbesondere unterschiedlicher Konformitätspfade, die Konsistenz der Validierungsaktivitäten potenztiell gefährdet. Daher sollte der Systementwickler die Gesamtvalidierung der Software sorgfältig planen und die erforderlichen Dokumente der SW-Lieferanten im Projekt einfordern.

Die Validierung folgt auch dem Grundsatz “zeige die selbstkritische Auseinandersetzung in deiner Organisation”. Oft scheitert die Validierung in komplexen Systemen an der Fähigkeit, die Komplexität in allen Phasen nachvollziehbar, chronologisch und übersichtlich darzustellen. Auch wenn der Assessor technisch gebildet ist, können z.B. ungenügend dokumentierte SW-Fehler-Injektionsverfahren eine Beurteilung zur Funktionalen Sicherheit unmöglich machen.

Entwurf und Entwicklung von sicherheitsrelevanter Software

Der Entwurf einer Software-Architektur, welche den geforderten SIL entspricht, kann nur durch eine vollständige Analyse der Sicherheitsanforderungsspezifikation erfolgen. Dabei sind insbesondere Merkmale der HW-Architektur zu berücksichtigen im Hinblick auf Wechselwirkungen. Die Entwicklung muss die Ziele und Maßnahmen zur Vermeidung systematischer Fehler im Sicherheitslebenszyklus unterstützen, wie z.B. die Validierung oder eine Berurteilung sowie Modifikation und Verifikation ermöglichen. Dabei sind folgende Aspekte zu bedenken:

  • Programmiersprache (vollständiger oder eingeschränkter Sprachumfang ?)
  • Compiler (hier insbesondere der Umgang mit “Schalten(Attribute)” und Meldungen)
  • Datenformate und deren Darstellungen (z.B. Little bzw. Big Endian; 32-Bit Festkomma….?)
  • Laufzeitsystem-Interface (z.B. Test- und Debugging im Multi-Core ?)
  • Anwender-Schnittstellen (z.B. Konfigurationssoftware mit USB Interface und paralell konfigurierbaren COM Stack ? )
  • Beständigkeit und Vertrauen der Entwicklungs- und Testumgebung (z.B. Update oder Packages aus Git-Hub vertrauensvoll ? usw…)

Die Software soll sicher modifizierbar sein. D.h. mal eben mit dem Editor eine *.c Datei anpassen oder im Flash-Speicher Teilbereiche wild überschreiben sollte nicht ohne weiteres möglich und keine Gewohnheit sein. Das sichere Modifizieren und Verifizieren sowie das Analysieren ist dem Integritätslevel entsprechend sicherzustellen. Würden Sie der Compileroptimierung immer trauen oder setzen Sie das Vertrauen 100% in Ihr Testteam und deren Methoden und Maßnahmen ?

Letzendlich muss der Software-Entwurf den Anforderungen entsprechen, d.h. die Verifikation der spezifizierten Sicherheitsfunktion und der systematischen Eignung muss erfolgreich sein. Falls Teile der Software die systematische Eignung mittels Konfigurationsdaten im PE-System (z.B. typisch bei Sicherheits-SPSen) bereitstellen, so sind auch diese Daten zu verifizieren.

Mehrere Zeitquellen, Funktionen und deren bereits festgelegte Allokation von der Systemebene können die Entwicklung einer unbrauchbaren Softwarearchitektur begünstigen. Hierzu zählen z.B. diametrale Eigenschaften von Teilfunktionen oder Diversität sowie Redundanz mit falscher Fusionsebene (Zeitpunkt und Wertebereich). Die Hardwarearchitektur ist bestimmend bezüglich der Güte/Qualität der Eingangssignale. Oft werden in Software ressourcenintensive Modelle zur Kompensation von HW-Architekturfehlern entwickelt. Daher ist es notwendig frühzeitig die HW und die SW-Architektur mit “Pflöcken” zu verknüpfen an den kritischen Stellen.

Ein erfahrender Systemarchitekt ist immer Gold wert bei komplexen Technologien.

Je nach System und technischen Sicherheitskonzept, kann die Verantwortlichkeit z.B. beim Lieferanten und/oder beim Anwender liegen. Hierzu gilt es, die allgemeinen Anforderungen und Ziele nach IEC 61508 Teil 3 Abschnitt 7.4. zu verteilen und sicherzustellen. Dabei muss die Entwurfsmethode folgende Eigenschaften aufweisen:

  • Komplexitätsbegrenzung (z.B. durch Abstraktion und Modularität)
  • Beschreibung und Darstellung von der Funktionalität
  • Kommentare
  • Informationsfluss zw. den Elementen
  • Reihenfolge und zeitliches Zusammenwirken, darunter auch Gleichzeitigkeit
  • Zugriff auf gemeinsame Ressourcen
  • Synchronisierung
  • Datenstrukturen und Eigenschaften selbiger
  • Voraussetzungen und Abhängigkeiten im Entwurf
  • Ausnahmebehandlung
  • Voraussetzungen für den Entwurf (Varianten/Invarianten, Vor- und Nachbedingungen)
  • Unterschiedliche Perspektiven (Verhalten, Struktur, Funktion usw…)
  • Verständlichkeit für die Gruppe der Rezipienten
  • V&V = Verifikation und Validierung

Bei der Implementierung des Entwurfs darf die Testbarkeit und die Möglichkeit der sicheren Modifikation nicht verloren gehen. Dies kann durch Modularität mit Geheimnisprinzip und Kapselung erreicht werden. Der Entwurf muss entsprechend dem SIL eine Kontroll- und Datenflussüberwachung mit geeigneter Erkennung und Behandlung enthalten. Dabei ist generell auf Einfachheit zu achten. Die Darstellung muss in eindeutiger Aufzeichnungsart und mit eindeutigen Eigenschaften erfolgen. Wenn eine geforderte Wechselwirkungsfreiheit zu Nichtsicherheitsfunktionen nicht umsetzbar ist oder gewährleistet werden kann, dann muss die gesamte Software inkl. nicht-sicherheitsbezogenen Funktionen nach dem höchsten SIL entwickelt werden. Wenn unterschiedliche Funktionen mit unterschiedlichem SIL ohne ausreichende Unabhängigkeit in einem Zielsystem umgesetzt werden sollen, so ist die gesamte Software als sicherheitsbezogene Software nach dem höchsten SIL zu entwickeln. Es ist auch möglich mit tragfähiger Begründung auf eine Überwachung zur Verletzung der Unabhängigkeit mit Beherrschung dieser zu setzen als auf Unabhängigkeit in Raum & Zeit.

Verfahren zur Unabhängigkeit in Raum und Zeit sind aufwendig und nur empfehlenwert, wenn die Zielhardware und das RTOS dies auch unterstützt.

Wenn Elemente mit niedriger systematischen Eignung (SC < SIL) verwendet werden, dann muss die Architektur durch Anordnung weiterer Elemente bis zur gesamten systematischen Eignung (SC = SIL) sicherheitstechnisch ertüchtigt werden. In Teil 2 wurde bereits die Synthese durch Kombination und Anordnung (seriell/parallel) systematisch geeigneter Elemente erwähnt. Zwei unterschiedliche Elemente, z.B. eine Kernfunktion und eine diversitäre Überwachung können in Kombination den geforderten SIL erreichen, obwohl jedes Element nur ein SC (SIL -1) aufweist.

Die Wiederverwendung von Software-Elementen mit Bezug zur Sicherheitsfunktion darf nur erfolgen, wenn die systematische Sicherheitsintegrität nach einem der Konformitätspfade (1s, 2s, 3s) erreicht wurde und somit ein Sicherheitshandbuch vorhanden ist, welches die Begutachtung der Integrität ermöglicht.

Wenn Sie sich bei der Realisierung der Sicherheitsfunktion auf ein bereits entwickeltes PE-System wie z.B. eine Safety-SPS oder auf ein hochgradig anwendungsspezifisches PE-System mit reinen Konfigurationsdaten setzen, so müssen Sie nach IEC 61508 Teil 3 Abschnitt 7.4.2.14 im Umgang mit diesen Konfigurationsdaten folgendes beachten:

  • die Komplexität der Anwendung muss dem Ziel-PE-System gleichwertig sein,
  • es müssen Verfahren zur Vermeidung von Fehlern verfügbar sein während:
    • Entwurf
    • Produktion
    • Ladevorgang
    • Modifikation
  • Die Spezifikation der Datenstrukturen muss
    • Konsistent sein
    • vollständig sein
    • widerspruchsfrei
    • Schutz bieten gegen Verfälschung und Änderungen
  • Konfigurationsvorgänge müssen dokumentierbar sein.

Dieser Weg reduziert den SW-Entwurf auf eine vollständige funktionale Beschreibung in der PE-Zielsystemsprache. Diese Beschreibung kann z.B. als ST-Sprache(strukturierter Text) für SPSen durch “CoDeSys Safety” (IEC 61131-3 Programmierumgebung mit speziellen Sicherheitskomponenten im Programmier- und Laufzeitsystem) umgesetzt sein. Hoch komplexe Systeme lassen sich damit nicht realisieren, da der PE-Systemlieferant die Architektur vorgibt. Einfache Sicherheitsfunktionen bis SIL3 sind realisierbar. Ein Tailoring bzw. eine Anpassung des Sicherheitslebenszyklus nach Anhang G für solche datengesteuerten Systeme ist generell möglich.

Die Modifizierbarkeit ist die Eigenschaft der Software auf Softwareebene, welche vergleichbar auf der Systemebene die Eigenschaft der Instandhaltung ist. Damit ist dieses Eigenschaft ein Merkmal zur Beherrschung systematischer Fehler. Fehler in der Software müssen sicher korrigiert werden können. Modulare Software lässt sich einfacher modifizieren als historisch gewachsene monolithische Strukturen.

Funktionale Sicherheit in der Softwareentwicklung – Architektur der Software

Wie im Bauwesen mit den Architekten und Statikern ist Funktionale Sicherheit in der Softwareentwicklung ähnlich. Der Architekt entwickelt und der Techniker soll aus all den Sonderwünschen ein tragfähiges PE-System entwickeln. Nicht immer leicht, aber realistisch. Pragmatisch gesehen, müssen eigentlich nur eine Reihe von Merkmalen als “Pattern” in die Architektur und in die Entwurfsmethodik eingebracht werden, um die systematische Eignung (SC) der Software zu gewährleisten. Der Umfang skaliert wie bereits auf Systemebene beschrieben mit dem SIL und heißt hier SC. Um das notwendige Vertrauen in die Software zu erlangen, muss die Software und die Entwurfsmethodik durch Maßnahmen und Verfahren systematisch und passend für die Technologie/Anwendung ergänzt werden. Die Planung dieser Verfahren und Maßnahmen muss in die Planung des SW-Sicherheitslebenszykluses einfließen.

Bei der Auswahl der Verfahren bzw. Maßnahmen zur Vermeidung systematischer Fehler sollten folgende Eigenschaften der Architektur berücksichtigt werden:

  • Vollständigkeit und Korrektheit im Hinblick auf die Sicherheitsanforderungsspezifikation
  • Einfachheit & Verständlichkeit
  • Entwurfsfehlerfreiheit
  • Prüf- und Testbarkeit des Entwurfs für V&V-Aktivitäten
  • Fehlertoleranz
  • CCF-Toleranz / Schutz gegen externe Einflüsse (z.B. EMV oder Netzwerk-Kommunikation)
  • Vorhersagbares Verhalten

Die Entwicklungsmethoden und die Architektur des Systems bzw. der Software müssen unsichere Ausfälle vermeiden bzw. diese begrenzen in ihren Auswirkungen. Es sind keine konkreten Einschränkungen vorgegeben wie es z.B. in der Hardware-Sicherheitsintegrität durch die HFT. Die Auswahl der Verfahren/Methoden und die Gestaltung der Architektur folgt im Wesentlichen durch die Rechtfertigung (Argumentation), dass bestimmte Eigenschaften streng oder weniger streng erfüllt sein müssen. Diese Eigenschaften sind i.d.R. durch viele Methoden/Verfahren/Prozesse und Architekturen unterschiedlich umsetzbar. Die Norm setzt klare Grenzen, wie “streng” diese Eigenschaften umzusetzen sind.

Bei der Auswahl der Verfahren bzw. Maßnahmen zur Vermeidung systematischer Fehler sollten folgende Eigenschaften der Werkzeuge berücksichtigt werden:

  • Umfang und Unterstützungsmöglichkeiten (Funktionsvielfalt vs. reale Nutzung)
  • Usability (Übersichtlichkeit im Hinblick auf Bedienung und Funktionalität)
  • Möglichkeiten der Wiederholung und Korrektheit der Ergebnisse

Beim Entwurf gibt die ausgewählte Technologie oft Randbedingungen an die Architektur und Entwurf vor. Die normativ geforderten Kerneigenschaften, welche die Methoden und Verfahren unterschiedlich Wirksam umsetzen, müssen jedoch im Rahmen einer Sicherheitsstrategie in die Architektur und die Entwurfsmethodik je nach “strenge” bzw. SC bzw. SIL eingebracht werden. Die Verantwortung dieser Sicherheitsstrategie muss im Rahmen der Sicherheitsplanung durch das Funktionale Sicherheitsmanagement (FSM) festgelegt werden und liegt i.d.R. beim Softwarearchitekten. Im Software-Architekturentwurf entstehen oft Konflikte durch die Anforderungen von bzw. an die Hardware oder der Systemebene. Daher ist ein dokumentierter “System-Austausch” immer sinnvoll, um eine Konsistenz der Spezifikation zu wahren. Auch das ist Funktionale Sicherheit in der Softwareentwicklung.

Der SW-Architekturentwurf muss folgende Eigenschaften ausweisen:

  • SW-Sicherheitsanforderungsspezifikation erfüllen, durch Auswahl eines passendem Satzes der Verfahren und Maßnahmen nach IEC 61508 Teil 3 Anhang A und Anhang B gemäß SIL & SC im Hinblick auf
    • Fehlertoleranz
    • Fehlervermeidung
    • Redundanz
    • Diversität
  • aus Elementen und Teilsystemen bestehen (z.B. (RT)OS, HAL, DB/Libs, EUC-E/A bzw I/O, COM-Stack, Anwendung, Prog- und DIAG) welche folgende Attribute aufweisen:
    • Status und Bedingung der Verifikation
    • sicherheitsbezogen oder nicht
    • systematische Eignung (SC)
  • HW-SW-Wechselwirkungen festlegen und bewerten wenn nicht auf Systemebene bereits erfolgt und vorgegeben
  • Eindeutige Methode der Darstellung
  • Datenintegrität (Sicherstellen, dass Daten (Datenbanken, Ein- und Ausgangsdaten des EUC, COM-DATA und HMI-DATA) im Entwurf sicher verwendet werden und sicher bleiben)
  • Inregrationstests mit angemessen Umfang gemäß SIL

Funktionale Sicherheit in der Softwareentwicklung – Feinentwurf der Architektur

Funktionale Sicherheit im Feinentwurf der Softwareentwicklung bedeutet abermals Verantwortlichkeiten festzulegen im Sicherheitsplan durch das FSM. Diese Phase hat als Eingangsvoraussetzung die SW-Sicherheitsanforderungspezifikation, den SW-Architekturentwurf sowie den Validierungsplan für sicherheitsbezogene Aspekte. Um kein “Monolith” zu erschaffen, muss der Entwurf ein modulares, prüfbares und sicher modifizierbares Gebilde sein. Im Wesentlichen ist der Feinentwurf wieder ein kleines V-Modell bis runter zur Modul/Unitebene mit Spezifikation und Verifikation (Test/Analyse). Die Integration muss dem SIL entsprechend der SW-Sicherheitsanforderungspezifikation angemessen sein. D.h. u.a. bis hinunter auf Codeebene ist eine Verfolgbarkeit der Anforderungen in beide Richtungen zu gewährleisten.

Die Codeimplementierung muss folglich einige Eigenschaften aufweisen wie:

  • Verständlich sein (lesbar und prüfbar)
  • Architekturvorgaben erfüllen
  • Konformität zu den Programierrichtlinien aufweisen
  • Konformität zu dem Konformitätspfad (1s,2s,3s) aufweisen

Der Code muss überprüft werden im Sinne einer Verifikation. Der Aufwand richtet sich nach dem erforderlichen SIL und reicht von der Inspektion mit Reviewprotokoll bis zum vollständigen formalen Nachweis. Je nach Konformitätspfad und Entwurfsmethodik kann die Verifikation auf andere Ebenen verschoben sein. Wenn Sie im Werkzeug-Qualifizierungsprozess festgestellt haben, dass bestimmte Aktivitäten zur Vermeidung systematischer Fehler auf Unitebene notwendig sind, so wäre dies bei der Verifikation zu berücksichtigen. Neben der Überprüfung des Codes muss auch ein Modultest als Teil der Verifikation durchgeführt werden. Dabei ist die Ableitung von Testfällen von der Unit-/Modul-Spezifikation vor der Codeimplementierung wichtig. Hier lässt sich Zeit sparen. Der Programmierer beginnt mit der Kodierung, während die Testspezifikation geschrieben wird. Dabei muss die Testabdeckung, Korrektheit des Testes und dessen Wiederholbarkeit sowie eine konsistente Testkonfiguration sichergestellt werden.

Wie umfangreich die Tests sein sollen, hängt von der Gesamtteststrategie und der Entwurfsmethodik und damit von dem SIL ab. Ein Test aller E/A-Kombinationen ist zu aufwendig, während eine systematische SW-Modul-Teststrategie mit Grenzwert- und Kontrollflussanalyse den Testaufwand enorm reduzieren kann. Ein Beispiel, wie in der Funktionalen Sicherheit “Pragmatismus durch Testen” aussehen kann.

Ziel der Verifikation ist dokumentiert nachzuweisen, dass neben der Konsistenz von Spezifikation und Code auch ausschließlich bestimmungsgemäße Funktionen enthalten sind. Dabei müssen Testdokumentation und Korrekturverfahren vorhanden sein.

Bedenken Sie, dass die Analysen auf Grenzwert und Kontrollfluss für “lesbaren Code” eine Alternative zu teuren und voll integrierten formalen Testwerkzeugen sein können. Hier ist die Kostenfrage, ob ein teures Werkzeug gekauft wird, dieses und die Mitarbeiter qualifiziert werden müssen und dafür Checklisten erstellt werden bzw. neue Prozessdefinitionen entstehen müssen, oder ob Sie Mitarbeiter wie “SMARTE TESTER” im Hause haben, welche den Testumfang und die Komplexität gut beherrschen. Statt aufwendige Analysen, ist es ratsam im Sinne des Pragmatismus einen Full-Test durchzuführen, wenn die Module einfach gehalten sind und der erforderliche SIL nicht zu hoch ist.

Jedoch sind bei höheren SIL und/oder komplexen Technologien hier Grenzen gesetzt und eine formale Entwicklungsmethodik kann dann notwendig sein. Die Natur der formalen Methoden bedingt i.d.R. weniger Testfälle.

Weiterhin ist es aufgrund der geforderten niedrigen Ausfallwahrscheinlichkeiten insbesondere im High-Demand-Mode einer Sicherheitsfunktion ausgeführt durch ein sicherheitsbezogenes PE-System NICHT ratsam für verifikationsfähige SW-Module einen statistischen Nachweis zu führen. Bei SIL 2 sind nach Teil 7 Anhang D mindestens 3×10^8 h Betriebsstunden erforderlich mit mindestens 95% Signifikanzniveau. Daher die Empfehlung: einfach die SW-Module testen und qualitativ hochwertigen Code erzeugen.

Funktionale Sicherheit in der Softwareentwicklung – Software-Integrationstest

Nach dem Entwurf und der Code-Entwicklung zeigt sich, ob die SW-Module verträglich untereinander sind und das Zusammenfügen keine systematischen Fehler aufweist. Diese Phase ist also eine Verifikation, welche aufzeigt, ob ordnungsgemäß integriert wurde und ob das Gebilde durch das Zusammenwirken der SW-Module keine unbestimmten/ungewollten Funktionen erzeugt. Wie bereits erwähnt, wurde in der Architekturentwurf-Phase auch die SW-Integrationstestspezifikation erstellt.

Die SW-Integrationstestspezifikation enthält:

  • die Testeinheiten
  • die Testfälle
  • die Testdaten
  • Testarten
  • Testsetting (Testumgebung, Testkonfiguration, Testprogramme und Testwerkzeuge)
  • Kriterien zur Beurteilung der Testvollständigkeit
  • Korrekturverfahren für Testversagensfälle

Bei der Integration kommen ähnliche, dem SIL entsprechend, Testarten zum Einsatz wie im SW-Modultest. Alle Testergebnisse, Testkriterien und erreichten Ziele müssen auch hier dokumentiert werden. Auch hier kann durch Grenzwertanalyse und Kontrollflussanalyse für die Integrationseinheiten der Testumfang in Grenzen gehalten werden. Während im SW-Modultest bei Testversagen im Code bzw. in dessen Spezifikation der Fehler liegt, so ist ein Testversagen im Integrationstest umfangreicher zu analysieren und zu dokumentieren. Sind die Testziele erreicht worden und sind die Testkriterien geeignet ? Wurde beim Testversagen eine Einflussanalyse durchgeführt und sind alle SW-Module, welche modifiziert werden müssten, ermittelt ? Sind die erforderlichen Tätigkeiten (Neu-Entwurf und Verifikation) im SW-Sicherheitslebenszyklus zur Modifikation identifiziert und geplant worden ?

Funktionale Sicherheit in der Softwareentwicklung – Hardware-Software-Integrationstest

Nun ist es Ziel, das bestimmungsgemäße Zusammenspiel der Software mit der Hardware zu testen. Die HW-SW-Integrationstestspezifikation entsteht in interdisziplinärer Zusammenarbeit in der Entwurfsphase. Dabei müssen die folgenden Aspekte berücksichtigt werden:

  • Integrationsstufen
  • Test- Fälle, -Arten, und -Daten
  • das Testsetting
  • Testerfolgskriterien (z.B. System in Standby zeigt Bereitschaft durch ….)
  • Testort (im Betrieb oder im Feld)

Auch auf dieser Integrationsebene müssen Auffälligkeiten und Abweichungen (Versagensgründe) in einer dokumentierten Einflussanalyse analysiert und die erforderlichen Tätigkeiten des Software-Sicherheitslebenszyklus geplant werden. Im Rahmen der Nachweisführung und der späteren Beurteilung zur Funktionalen Sicherheit sind die Testfälle und Testergebnise, Testkriterien und erreichte Ziele sowie Versagensfälle und deren Bewertung und notwendige Modifikationen in der Einflussnalyse zu dokumentieren. Der Assessor achtet neben der typischen Dokumentation insbesondere darauf, dass keine Änderungen im “Integrationsfluss” by-the-way und unüberlegt stattfanden bzw. auftreten und ob die Versagensgründe der Integrationsebene entsprechend ausreichend beleuchtet wurden.

Die Integration kann bei übersichtlicher Komplexität und Entwicklungsstruktur (alles in einer Firma) grob in 2 Teile gegliedert und zusammengefasst werden. Die Software mit SW-Modul- und SW-Integrationsspezifikation sowie die HW-SW-Integrationsspezifikation. Hardwarenahe SW-Module können entweder im Emulator getestet werden oder z.B. durch ein “Stub” auf HW-SW-Integrationsebene. Die Grenze der Integration zwischen der Software und dem System sind mit der Integration der Software in die Ziellogik erreicht. Sensoren, Aktoren und die Integration in die Zielanwendung mit dem EUC sind auf Systemebene bzw. Gesamtsystemebene in einer Gesamtintegrationsspezifikation zu behandeln und liegen i.d.R. nicht im Verantwortungsbereich der Software-Domäne.

Ein Integrationsbericht pro Integrationsebene oder ein iteratives Dokument als “Gesamtintegrationsbericht” ist i.d.R. eine effektive Ausgabe der Integrationsphasen. Funktionale Sicherheit ist durch die typischen Eigenschaften in der sicherheitsgerichteten Softwareentwicklung zu erkennen: Planen, Ausführen, Verifizieren/Schlussfolgern, Handeln und Dokumentieren. Kommt Ihnen das bekannt vor ? Das ist typisches Qualitätsmanagement nach ISO 9001, ein PDCA-Zyklus.

Funktionale Sicherheit in der Softwareentwicklung – Werkzeuge der Entwicklung

Haben Sie mal versucht, eine weiche Schraube mit einer Zange zu entfernen, nachdem der Schraubendreher den Schraubenkopf bereits zerstört hat ? Falsches Werkzeug in unqualifizierten Händen kann mehr Schaden anrichten als Nutzen bringen. Ähnlich ist es im Hinblick auf Funktionale Sicherheit in der Softwareentwicklung und der Qualität der Werkzeuge. In der Softwareentwicklung wird Software durch Software entwickelt. Die systematische Eignung der zu entwerfenden Software ist also nicht ganz unabhängig von der Umgebung in der diese entstanden ist. Fehler, Bugs, falsche Compilereinstellungen, neue Versionen der Werkzeuge oder falsche Konfigurationsdaten und Fehlbedienung durch unübersichtliche Menüführung sind oft eine Fehlerquelle für systematische Fehler. Toolbrüche und selbstgebastelte Scripting-Brücken oder Excel-Sheets entstehen schnell als Hilfsmittel im Prozess durch fleißige Mitarbeiter. Auch diese sind potenzielle Fehlerquellen. Wie in den Phasen zuvor, muss dass Sicherheitsmanagement bei der Sicherheitsplanung die Verantwortlichkeiten auf ein oder mehrere Beiteiligte festlegen.

Die IEC 61508 unterscheidet zwischen Online-SW-Werkzeugen, welche zur Laufzeit Einfluss nehmen können auf das sicherheitsbezogene E/E/PE-System und Offline-SW-Werkzeugen, welche oft Teil des Entwicklungsprozesses sind. Diese Offline-SW-Werkzeuge sind in unterschiedliche Klassen aufgeteilt, je nach Einfluss auf die zu entwickelnde Software:

  • T1: Werkzeug erzeugt keine Ausgaben, welche im sicherheitsbezogenen System verwendet werden (Texteditor ohne automatische Code-Generierung)
  • T2: Werkzeug zur Fehlererkennung (Verifikationstool, Codeanalyse-Tool)
  • T3: Werkzeug erzeugt Ausgaben mit Einfluss auf den Code des sicherheitsbezogenen Systems (Compiler, Linker)

Bedenken Sie, dass in der Softwarearchitektur diverse SW-Elemente vorhanden sind und oft auf unterschiedlichen Konformitätspfäden entwickelt wird. Durch funktionale Wechselwirkungen wird auch in der Verwendung der Werkzeuge der ein oder andere Berührpunkt zwischen den Pfaden entstehen, welche im Sinne der Vermeidung systematischer Fehler berücksichtigt werden muss. Beispiel ist die Integration einer COM-Stack-Lib in das RTOS mit Verbindung zum HAL.

Nützliche Werkzeuge sind nicht immer brauchbare Werkzeuge

Oft sind die Werkzeugketten technologiebedingt oder durch historisch gewachsene Firmenstukturen und vorhandene Kompetenz vorgegeben. Funktionale Sicherheit in der Softwareentwicklung kann aus wirtschaftlichen Gründen nicht auf Wahlfreiheit bei der Wahl der Werkzeuge bestehen. Die IEC 61508 fordert eine begründete Auswahl der Werkzeuge d.h. eine Toolanalyse muss vor der Realisierung und Implementierung durchgeführt werden. Diese Analyse sollte nach dem ersten tragfähigen SW-Architekturentwurf erfolgen. Selbstverständlich ist eine vorhandene Tool-Kompetenz und Tool-Erfahrung von Vorteil. Jedoch zeigt erst eine genauere Analyse, die genauen Fehlerpotenziale. Haben Sie schon immer eine Entwicklungsumgebung (IDE) verwendet und Fehler im Produkt erst im Feld bemerkt, welche ihren Ursprung z.B. im falsch verwendeten Compiler-Attribut (Schalter zu Optimierungsstrategie) haben ? Wenn jetzt ein Notizzettel am Monitor des Entwicklers hängt, dann ist das kritisch. Wenn jedoch eine Tool-spezifische Checkliste erstellt durch das Qualitätsmanagement vorhanden ist, welche explizit diesen kritischen Punkt abfragt, so ist dies eine vorbildliche Sicherheitskultur und im Sinne der Norm.

Wenn Sie neue Technologien und deren Werkzeuge einsetzen, dann sollten Sie gemäß Teil 1 die Qualifikation der Nutzer sicherstellen und das Tool qualifizieren. Dazu gibt es bei Safety-Serien von ASIC/DSP/SOC/µC-Herstellern spezielle “Qualification-Packages”, welche erwerbar sind und einiges an Ressourcen (Mann-Monate) verschlingen kann.

Ofllinewerkzeuge der Klasse T2 und T3 müssen vollständig beschrieben sein im Sinne der Bedienung, des Verhaltens und vorhandenen Einschränkungen (z.B. Compiler/Linker gibt bei Optimierungsattribut xyz keine konsistente Reihenfolge aus, gerade wenn Libs eingebunden werden). Weiterhin müssen diese Werkzeuge nach Ihrem Vertrauensgrad und Ausfallmechanismen untersucht und ggf. qualifiziert werden. Dabei sind im SLC passende Gegenmaßnahmen zu planen wie z.B. spezielle Verifikationsprotokolle zu den Ausgaben des Programmes.

T3 Werkzeuge sind kritische Faktoren

Für T3 Werkzeuge müssen Nachweise für Konsistenz der Dokumentation mit der Programmversion vorhanden sein. Langjährige dokumentierte Erfahrung (Versionshistorie mit Fehlerberichten) im Umgang in der Organisation bzw. eine Validation sind ein gültiger Nachweis zum Vertrauensgrad. Die Validation muss folgende dokumentierte Ergebnisse liefern, um eine Beurteilung zu ermöglichen:

  • Chronologie der Validierungsaktivitäten
  • Validierte Werkzeugfunktionen
  • Verwendete Validierungswerkzeuge und Einrichtungen
  • Handbuch-Version des Werkzeuge
  • Ergebnisse der Validierungsaktivitäten und abgeleitete Aktionen/Folgerungen
  • Testfälle und Ergebnisse
  • ggf. Abweichungen zu den Erwartungen

Sie müssen aufzeigen, dass Sie die erforderliche systematische Sicherheitsintegrität erfüllen. Dies bedeutet, dass Sie entweder Vertrauen in die Werkzeuge setzen und dies nachweisen oder erforderliche Maßnahmen in den Prozess sowie ggf. in die Software des sicherheitsbezogenen Systems einbringen (z.B. Diversität auf Codebene). Die Werkzeugauswahl in der Entwurfsphase ist ein kritischer Punkt zur systematischen Sicherheitsintegrität. Sie werden öfters hybride Wege gehen müssen.

Repräsentation und Abstraktion

Funktionale Sicherheit in der Softwareentwicklung fordert in IEC 61508 Teil 3 Abschnitt 7.4.4.10 für die “Repräsentation des Entwurfs” (Software und Sprache) eine Reihe von Eigenschaften, welche sehr Abstrakt sind. Generell wie bereits beschrieben wird ein qualifizierter Sprach-Übersetzer (Klasse T3 mit Dokumentation/Beurteilung/Validation/Tauglichkeitsnachweis) vorhanden sein müssen, um mit Vertrauen die Abstraktion und die Transformation zwischen Abstraktionsebenen leisten zu können in einem definierten Sprachraum. Nicht jede Technologie und deren Entwurfsmethodik ist gleich. Können Sie Assembler bzw. VHDL leicht verstehen ? Wenn nicht, dann fällt Ihnen das Erkennen von Programmierfehlern und Entwurfsfehlern sicherlich nicht leicht. Spezifische Maschinensprachen sind für den Menschen i.d.R. unlesbar. Daher muss die ganzheitliche “Repräsentation des Entwurfs” für den erforderlichen Sicherheitsintegritätslevel (SIL) geeignet sein. Für höhere SILs ist der Vertrauensgrad des Menschen ungenügend und es sind i.d.R. formale Sprachen anzuwenden. Die “Repräsentation des Entwurfs” führt dann die mathematischen Prüfungen automatisiert formal vollständig aus.

Für die Softwaresicherheit ist eine Programmierrichtline für die Programmiersprache erforderlich, welche in sicherheitsbezogenen PE-Systemen verwendet wird. Dabei sind z.B. folgende Inhalte sinnvoll:

  • Programmiertechniken wie z.B. defensive Programmierung
  • unsichere Sprachmerkmale (falsche Struktur oder undefinierte Bereiche/Objekte/Befehle usw…)
  • Maßnahmen, um die Verständlichkeit einheitlich zu gewährleisten
  • Verifikation und Unittest
  • Source-Code-Dokumentationsverfahren bestehend aus:
    • Source-Code
    • Angaben zur juristischen Person (Firma, Autor usw..)
    • Beschreibung
    • Ein- und Ausgabe
    • Vorgeschichte (s. Konfigurations- und Änderungsmanagement)

Funktionale Sicherheit in der Softwareentwicklung bedeutet neben dem Entwerfen auch Befolgen von Programmierrichtlinien bzw. zusätzlich oder alternativ die Auswahl automatisierter Werkzeuge mit positiver Berurteilung zur Eignung im Projekt. Um das Kernziel des Konfigurationsmanagements (Wiederherstellbarkeit der Basiskonfiguration) zu ermöglichen, müssen eine Reihe von Informationen aus den Konfigurationswerkzeugen der Klasse T2, T3 aufgezeichnet werden wie z.B. Werkzeugname und Version, Bezug zwischen Werkzeugversion und Basiskonfigurationsdaten und die Art der Werkzeugverwendung (Optionen/Skripte/Parameter). Weiterhin muss das Konfigurationsmanagement den Einsatz geeigneter Versionen der Werkzeuge sowie deren Verträglichkeit sicherstellen. Wechselbeziehungen zur Hardware sind zu berücksichtigen (SW-Emulatoren müssen mit der HW-Konfiguration übereinstimmen). Änderungen der Versionen der Software-Werkzeuge sind recht kritisch zu bewerten und müssen vorher durch Qualifizierung durch das Konfigurationsmanagement bewertet und nach Beurteilung freigegeben werden.