3 Mit den höheren Ansprüchen an Sicherheit, steigen auch die Kosten für deren Erfüllung. Dabei haben die Personalkosten einen erheblichen Anteil daran. Durch die Automatisierung der Sicherheitsbereitstellung, werden die Prozesse wirtschaftlicher und dynamischer z.B. bezüglich des Einsatzortes oder des Umfangs. Damit wächst gleichzeitig auch die Komplexität der Systeme, die zunehmend durch programmierbare, elektronische Systeme realisiert werden. Zur Gewährleistung der Sicherheit von sicherheitstechnischen Komponenten wird u.a. der IEC\footnote{International Electrotechnical Commission} 61508 Standard verwendet, der die notwendigen Schritte in jeder Phase eines Projekts beschreibt, die zur Zertifizierung notwendig sind.
5 IEC 61508 gilt als eine allgemeine Norm für die Planung, Entwicklung, Validieren, Erweiterung, Instandhaltung und Beseitigung von E/E/PE\footnote{elektrische, elektronische und programmierbar elektronische (Systeme)} Systemen mit Sicherheitsfunktion. Er wird genau dann eingesetzt, wenn kein Sektorstandard, wie z.B. IEC 61511 für die Prozessindustrie oder IEC 50129 für Bahnanwendungen, vorliegt. Eine Ausnahme sind Subsysteme, die zwar in einem Gesamtsystem einbettet sind mit geltendem Sektorstandard, jedoch als isolierte Einzelkomponenten sektorunspezifische Funktionalität realisieren. Diese werden ebenfalls nach dem IEC 61508 realisiert, sofern sie eine sicherheitskritische Funktion darstellen.
7 \section{Fehlerursachen}
8 Einfach ist sicher. Steigende Anforderungen an heutige Elektronik führt zu komplexen Entwürfen und somit zu größeren potentiellen Fehlerquellen. Es gilt das Problem in geeignet proportionierte, primitive Probleme zu zerlegen und diese durch modulare Bausteine zu lösen. Sicherheit durch Einfachheit bedeutet dabei nicht nur der modulare Aufbau eines Systems durch verlässliche Komponenten, sondern ist auch ein sozialer Prozess, der die Planung des Systems, die Wahl der Technologie, die Art der Dokumentation und des Entwicklungsprozesse betrifft.
10 Wenn man von der Komplexität einer Software spricht, unterscheidet man unter der strukturellen und kognitiven Komplexität \cite{silcalc}. Der strukturelle Aufbau lässt sich durch Metriken wie McCabe Cylomatic Complexity oder Halstead beurteilen und anhand dessen die möglichen komplexen und somit unsicheren Stellen lokalisieren und beseitigen. Zur Beurteilung der kognitiven Komplexität hingegen stehen keine Metriken zur Verfügung, diese beziehen sich auf die Verständlichkeit einer Software unter Berücksichtigung der durchschnittlichen kognitiven Fähigkeiten eines Menschen, wie z.B. der Kurzzeitgedächtnisleistung. Denn auch ein korrektes Programm ist auf lange Sicht unsicher, wenn es nicht problemlos von verschiedenen Entwicklern gewartet und angepasst werden kann.
12 Laut \cite{silcalc} entstehen ca. 44\% aller Unfälle in Verbindung mit Softwarefehler durch ungenügende Spezifizierung. Dabei kann der Begriff Fehler irreführen, denn in den meisten Fällen funktioniert die Software fehlerfrei, die Ursache liegt bereits im falschen Design. Aufgrund von unzureichendem Verständnis für die Einsatzumgebung und den Zweck der Software entstehen falsche Annahmen und Anforderungen, die bei Funktionstests nicht als Fehler erkannt werden.
14 \subsection{Techniken zur Vermeidung von Fehlern}
15 \cite{iec61508} gibt zur Vermeidung von Fehlern und falschen Entscheidungen eine Reihe von Techniken vor. Für SIL\footnote{Safety Integrity Level} 3 gibt es folgende Richtlinien für das Vermeiden von Fehlentwicklungen während der
17 Anforderungsspezifikation:
20 \item Ein korrekt ausgeführtes Projektmanagement.
21 \item Sorgfältige Dokumentation.
22 \item Zur Reduzierung der Komplexität bei der Risikobewertung sollen sicherheitstechnische von nicht sicherheitsrelevanten Funktionen isoliert betrachtet werden. Letztere werden nicht vom Standard\footnote{IEC 61508} betrachtet und benötigen keine Zertifizierung.
23 \item Die strukturierten Spezifikationsdokumente müssen zur Abnahme inspiziert werden. Hierbei reichen semi-formale Methoden aus zur Evaluierung der Korrektheit der Spezifikation.
24 \item Zur weiteren Einschränkung möglicher Fehlerquellen während der Anforderungsspezifikation stehen noch die Methoden der Checklistenführung für ausstehende/abgearbeitete Aufgaben, computergestützte Spezifizierungswerkzeuge und formale Beweise zur Wahl. Hierbei ist das Anwenden einer Methode ausreichend.
27 \section{Allgemeine Anforderungen}
29 \subsection{Dokumentenführung}
30 \cite{iec61508} beschreibt eine Reihe von Anforderungen an jede Phase eines Produktlebenszyklus. Die Wahl eines passenden Prozessmodells ist entscheidend, um später den dokumentarischen Nachweis für den erfolgreichen Abschluss einer Phase zu erbringen.
31 Ein geeignetes Prozessmodell ist das V-Modell (Abb. \ref{fig:v_modell}), welches die Spezifikation klar von der Realisierung trennt und entsprechend dokumentiert.
35 \includegraphics[width=11.5cm]{v_modell.pdf}
36 \caption{Softwaresicherheitsintegrität und die Entwicklungsphasen nach dem V-Modell (Quelle: \cite{iec61508} Teil 3 S. 27)}
41 Die Dokumente müssen versioniert sein und in einer erkennbaren Dokumentenstruktur untergebracht sein. Bei komplexen Systemen kann die Dokumentenstruktur nach Zielgruppen orientiert sein. Zu jedem Zeitpunkt in einem Projekt, muss gewährleistet werden, dass jede Zielgruppe Zugang zu entsprechenden Dokumenten erhält.
43 \subsection{Middleware und Werkzeuge}
44 Beim Einsatz von Middleware jeglicher Art, ist der Einsatz stets zu rechtfertigen. Sobald Module von dritter Hand direkt an einer Sicherheitsfunktion beteiligt sind, sind diese ebenfalls der Zertifizierung unterworfen und müssen somit bei der Verifizierung berücksichtigt werden.
46 Bei eingesetzten Compilern muss ein Nachweis der Konformität zu dem entsprechenden Standard erstellt werden. Dieser wird für die meisten Programmiersprachen durch sog. Validierung Suites, wie z.B. Plum-Hall Validierung Suite für C und C++, erbracht \cite{cert_compiler}.
48 Wird modellgetriebene Entwicklung praktiziert, müssen entsprechend eingesetzte Code-Generatoren zertifiziert sein.
50 \subsection{Personalkompetenz}
51 Involvierte Person in einer oder mehreren Aktivitäten im Entwicklungsprozess müssen entsprechendes Fachwissen, Erfahrung und Qualifikation im relevanten Tätigkeitsfeld vorweisen. Sowohl Managementfunktionen als auch technische Leistungen müssen mit entsprechend geeignetem Personal besetzt sein.
53 Die Ansprüche an das Personal steigen mit der Rigorosität des Systems und der Einstufung des Safety Integrity Levels. Mit SIL 3 ist somit wichtig Personen mit einschlägiger Erfahrung zu wählen, die sie neben hoher Kompetenz in der Softwareentwicklung mitbringen. Sie haben auch entsprechende Kenntnisse im Umgang mit den eingesetzten Werkzeugen, in Safety Engineering und auch dem regulatorischen Framework vorzuweisen.
55 \cite{personal} beschreibt ein Kompentenzmodell zur Evaluierung möglicher Kandidaten. Man allokiert für jede Sicherheitsfunktion bis zu fünfzehn zielorientierte Kompetenzen, die am wichtigsten sind für eine erfolgreiche Ausführung der sicherheitsrelevanten Funktion. Die Einteilung wird erleichtert, indem man die Kompetenzen in aufgabenspezifische und funktionsabhängige teilt. Aufgabenspezifische Fähigkeiten sind meist technischer Natur, während funktionale Kompetenzen sich auf das Verständnis und Verhalten beziehen \cite{personal}.
59 \subsection{Gefahrenanalyse (Hazard Analysis)}
60 Die Gefahrenanalyse soll - laut Standard - die Funktionen identifizieren, die zur Sicherung aller möglichen gefährlichen Ereignisse geeignet sind. Solch eine Funktion wird auch als Sicherheitsfunktion bezeichnet. Dabei ist das vorsorgliche Vermeiden des gefahrbringenden Ereignisses, durch eine Umgestaltung des Systems, keine Instanz von funktionaler Sicherheit, ist aber ebenfalls als Auflösung eines Hazards geeignet.
62 \subsubsection{Quantitative Determination des SIL}
63 \cite{basf}, \cite{iec61508} beschreiben eine Möglichkeit der Klassifizierung von Risiken durch den Einsatz einer Risikomatrix (Abb. \ref{fig:risk_class}). Die Gegenüberstellung von Schadensausmaß und Eintrittswahrscheinlichkeit eines Hazards bildet die Entscheidungsgrundlage für Maßnahmen zur Beseitigung oder Entschärfung einer Gefahr. Besteht Todesgefahr oder Gefahr für Schwerverletzte bei relativ hohen und mittleren Eintrittswahrscheinlichkeiten, so ist die Reduzierung der Gefahr durch eine Sicherheitsfunktion nach SIL 3 möglich \cite{basf}. Zuvor ist zu evaluieren, ob eine Beseitigung der Gefahr durch Verfahrens- oder Designänderung nicht tragbar ist.
64 Die Definitionsbereiche der Einstufungen sind sektorspezifisch.
68 \includegraphics[width=10cm]{risk_class.pdf}
69 \caption{Beispiel für Risikoklassifizierung von Unfällen (Quelle: \cite{iec61508} Teil 5 S. 35)}
70 \label{fig:risk_class}
74 Die Risikomatrix soll nun mit Risikoklassen belegt werden, die als Vorgabe für eine passende Lösungsstrategie dienen. Eine mögliche Konzeption der Klassen zeigt Abb. \ref{fig:risk_class2}. So sieht nach \cite{basf} eine beispielhafte Risikoklasseneinteilung, in etwas vereinfachter Form, aus:
78 Nicht tolerierbares Risiko. Verfahrens- oder Entwurfsänderung notwendig.
80 Nicht tolerierbares Risiko. Verfahrens- oder Entwurfsänderung notwendig, oder eine Schutzeinrichtung nach SIL 3.
82 Mittleres Risiko. Verfahrens- oder Entwurfsänderung notwendig oder eine Schutzeinrichtung nach SIL 2.
84 Geringes Risiko. Überwachungs-einrichtung, dokumentierte Prüfung und organisatorische Maßnahmen von guter Qualität ausreichend.
86 Tolerierbares Risiko. Keine Maßnahmen notwendig.
91 \includegraphics[width=11.5cm]{risk_class2.pdf}
92 \caption{Beispiel für Risikoklasseninterpretation (Quelle: \cite{iec61508} Teil 5 S. 35)}
93 \label{fig:risk_class2}
97 Nach der Bewertung der Gefährdungen auf dem EUC, ermittelt man die notwendigen Risikoreduktionen um ein tragbares Risiko zu erreichen. Die Maßnahmen zur Reduktion der Risiken werden im folgenden Schritt in Sicherheitsfunktionen allokiert.
99 \subsubsection{Qualitative Determination des SIL}
100 \cite{iec61508} Teil 5 beschreibt zwei Methoden zur qualitativen Bestimmung des SIL. Die Maßnahmen sind insbesondere dann anzuwenden, wenn die Ereignisfrequenz einer Gefährdung nicht quantifizierbar ist.
102 \subsection{Risikoeinstufung (Risk Assessment)}
103 Der Grad für tragbares Risiko wird durch den Standard mit Hilfe von statistischen Tabellen in vier Kategorien klassifiziert. SIL 3 bildet dabei die zweithöchste Einstufung. Vor der Spezifizierung des SIL, wird iterativ eine Risikoreduktion über das Gesamtsystem durchgeführt, unter Beachtung der Sicherheitsintegritätsallokationen der Sicherheitsfunktionen, die auf das System wirken und von äußeren Faktoren.
107 \includegraphics[width=7.5cm]{sil_low.pdf}
108 \caption{Safety Integrity Levels: Zielausfallrate for Sicherheitsfunktion in niederfrequenten Bedarfsmodus (Quelle: \cite{iec61508} Teil 1 S. 65)}
112 Bei der Zuweisung eines Sicherheitsintegritätsgrades wird statistisch zwischen zwei Typen von Sicherheitsbereitstellung unterschieden. Der sog. Low demand mode of operation (Abb. \ref{fig:sil_low}) bietet eine statistische Verteilung für Sicherheitsfunktionen, die selten und bei Bedarf aktiviert werden. Die Verteilung bezieht sich dabei auf die durchschnittliche Wahrscheinlichkeit einer Fehlfunktion bei Ausführung, für SIL 3 liegt diese bei $10^{-4}$ bis $10^{-3}$. Für Funktionen im Hochverfügbarkeitsszenario beschreibt eine weitere Tabelle die statistische Verteilung für die Wahrscheinlichkeit eines gefährlichen Ausfalls pro Stunde, für SIL 3 liegt das bei $10^{-8}$ bis $10^{-7}$ (Abb. \ref{fig:sil_high}).
113 Ein Verfahren zur einheitlichen Spezifizierung des SIL wird in \cite{unified} mit Hilfe einer zeitabhängigen Funktion vorgeschlagen.
117 \includegraphics[width=7.5cm]{sil_high.pdf}
118 \caption{Safety Integrity Levels: Zielausfallrate for Sicherheitsfunktion in Hochverfügbarkeitsmodus (Quelle: \cite{iec61508} Teil 1 S. 65)}
122 \section{Spezifikation}
123 Ziel dieser Voraussetzung ist der Entwurf eines Plans zum Bewerkstelligen der Validierung eines sicherheitsbezogenen Systems.
124 Inhalte des Plans setzen fest den Zeitpunkt der Validierung, die Verantwortlichen der Durchführung, die Operationsmodi des EUC\footnote{Equipment Under Control} im Zusammenhang mit dem sicherheitsbezogenen System, die Spezifikation der Sicherheitsfunktionen für jeden Operationsmodus des Zielsystems, die Validierungsstrategie, die Prozeduren zur Verifikation der Konformität der Sicherheitsfunktionen mit den Spezifikationen der Risikoanalyse und der Risikoeinstufung, die Anforderungen an die Testumgebung, die Erfolgs- und Misserfolgskriterien und die Prozeduren der Resultatsbewertungen.
126 Resultierende Dokumente daraus können sein der Testplan, die Spezifikation des Testdesigns, der Testfälle und Testprozeduren \cite{blackbox}.
130 Der Testplan hält die organisatorischen Faktoren fest, wie den Zeitplan, die Testumgebung und die Testaktivitäten.
132 In der Spezifikation des Testdesigns werden die Sicherheitsfunktionen festgelegt, die zu validieren sind. Die Anforderungen bieten die Grundlage der Spezifizierung welche Eigenschaften einer Funktion zu testen sind und wie ein erfolgreicher Testabschluss dafür definiert ist.
133 Zusätzlich sollen Verfahrensweisen zur Handhabung von unzutreffenden Testresultaten vereinbart werden.
135 Die Testfallspezifikation dokumentiert die Prozeduren jedes einzelnen Testdurchlaufs. Die Einstellungen des EUC, der Zustand des EUC und die Ein- und Ausgabeparameter der Sicherheitsfunktion sind in diesem Dokument erfasst. Bei automatischer Testfallgenerierung besteht die Möglichkeit dieses Dokument auch automatisiert zu erstellen.
137 Durch die Spezifikation der Testprozedur wird der Testverlauf und die eingesetzten Werkzeuge festgelegt. Im Falle einer manuellen Testfallabarbeitung muss dieses Dokument die Schrittabfolge definieren, die die ausführende Person zu tätigen hat. Ähnlich ist es bei einem automatischen Testverlauf, hierbei muss jedoch auch das zum Einsatz kommende Werkzeug und dessen Handhabung genau spezifiziert werden.
140 \section{Validierung der Softwaremodule}
141 Zur Verifikation eines Gesamtsystems oder eines Softwaremoduls nach \cite{iec61508}, ist die konforme Validierung aller Softwaremodultests vorausgesetzt. Der Standard bietet dabei Vorschläge zum Bewerkstelligen der Validierung der Softwaremodule unter Abhängigkeit des Sicherheitsintegritätslevels an. In den folgenden Kapiteln werden die Verfahren vorgestellt, die für SIL 3 als \emph{Recommended} bzw. \emph{Highly Recommended} eingestuft sind.
143 Zur Laufzeitreduzierung des Testvorgangs und der Testfallgenerierung werden verschiedene Strategien ergriffen, oft auch in Kombination miteinander. IEC 61508-3 bietet die Bildung von Äquivalenzklassen, strukturbasierte Testfälle, die Randwertanalyse und Kontrollflussanalyse als mögliche Szenarien für eine Testfallbildung an.
145 \subsection{Probalistisches Testen}
146 Stochastische Ansätze wie z.B. die Monte-Carlo-Simulation sind Möglichkeiten von konformen Validierungsmaßnahmen. Diese sind geeignet für das Testen von zustandsbasierten Systemen mit großen variablen Zustandsentwicklungen- und abhängigkeiten. Dabei bedient man sich numerischer Methoden zur Beurteilung der Testergebnisse in Abhängigkeit von der Zusammenstellung der Testfälle. Solche Methoden zeigen ihre höchste Effizienz durch das Mitwirken von Zufallszahlengeneratoren, die eine statistische Gleichverteilung ermöglichen und von Heuristiken, die durch semantikbewusste Testfallfilterung unwahrscheinliche Szenarien ausschließen.
148 Probalistisches Testen wird beim Testen von Softwaremodulen eingesetzt, wenn keine Einsicht in den Quellcode besteht.
150 Eine erfolgreiche Abnahme nach \cite{iec61508} erfordert den Nachweis der Vorbereitung der Testfälle. Hierbei ist zu zeigen, dass die probalistische Entwicklung der Testfälle eine vollständige Abdeckung aller möglichen Fehlerereignisse darstellt, nicht aber notwendigerweise die Abdeckung aller möglichen Zustände des Moduls. Die Validierungsprozedur muss vollständig dokumentiert sein, das bedeutet Testspezifikation, Testausführungsprotokoll, Testresultat und Testresultatbeurteilung. Die Reproduzierbarkeit der Validierung setzt eine deterministische Zufallszahlenerzeugung voraus.
152 \subsection{Dynamische Analyse}
153 Die dynamische Analyse wird beim Testen von Softwaremodulen mit Einsicht auf Quellcode eingesetzt.
155 \subsubsection{Randwertanalyse}
156 Bei der Randwertanalyse beschränken sich die Testfälle auf Grenzwerte, die durch die Hard- und Softwarearchitektur, die Implementierung und das Interface bestehen. Dieses Analyseverfahren ist effektiv um Fehlverhalten an den Grenzen des Gültigkeitsbereichs festzustellen. Durch die signifikante Häufigkeit solcher Fehler in Softwaremodulen, wird die Randwertanalyse obligatorisch in Verbindung mit anderen Testverfahren angewendet.
158 \subsubsection{Error Seeding}
159 Ein Verfahren, dass eine probalistischen Grad des Fehlerbefalls entwickelt, ist das sog. Error Seeding. Es besteht darin explizit künstliches Fehlverhalten in das, zu testende, Modul zu platzieren um nach der Testphase einen Wahrscheinlichkeitswert über die noch vorhandenen, nicht künstlichen, Fehler zu berechnen. Die Kalkulation bedient sich der Stochastik und bildet mit den Variablen $F_{U}$ für die Anzahl an unentdeckten Fehlern, $F_{G}$ für die Anzahl an nicht-künstlichen entdeckten Fehlern, $F_{E}$ für die Anzahl an platzierten künstlichen Fehlern und $F_{EG}$ für die Anzahl an entdeckten platzierten künstlichen Fehlern folgende Gleichung: $F_{U} = F_{G} * \frac{F_{E}}{F_{EG}}$.
160 Darüber hinaus gibt das Verfahren Aufschluss über die Qualität der Testprozeduren, indem man das Verhältnis von künstlichen Fehlern und entdeckten künstlichen Fehlern betrachtet.
162 \subsubsection{Äquivalenzklassen}
163 Durch die Permutation aller Eingabeparameter einer Sicherheitsfunktion entstehen im Regelfall Redundanzen. Reduktion der Eingangskombinationen kann durch Äquivalenzklassenbildung erfolgen. Dabei entwickelt man die Testfälle nach disjunkten Gruppen von Zustandsübergängen, die bei Vereinigung eine vollständige Abdeckung des Testszenarios bilden. Bei der Abstraktion des funktionalen Verhaltens eines Softwaremoduls können mathematische Annahmen über Wertebereiche und Wertemengen nicht immer mit den Systemeigenschaften übereinstimmen. Zur Vermeidung von Fehlschlüssen oder schlechten Fehlerabdeckungsquoten, fließt die Randwertanalyse mit in die Bildung der Äquivalenzklassen ein.
165 \subsection{Funktionales und Black-Box Testen}
166 Black-Box Testen bedeutet das Abarbeiten von Testszenarien unter vollständiger Abstraktion der Implementierungsschicht. Dabei werden Input- und Outputwerte, Fehlerbehandlungen und Performancemessungen als Faktoren der Validierung analysiert.
167 Die Testfälle können aus Konsequenzdiagrammen, Prototypen, der Randwertanalyse und der den Äquivalenzklassen hergeleitet werden \cite{iec61508}.
169 Funktionales Testen wird beim Testen von Softwaremodulen ohne Einsicht auf Quellcode angewandt und beim Integrationstesten.
170 Zur erfolgreichen Zertifizierung wird ebenfalls die vollständige Dokumentation der Vorbereitung der Tests, der Testprozeduren, der Testresultate und der Analyse der Resultate erwartet.
172 \section{Funktionale Sicherheitsbeurteilung (Functional Safety Assessment)}
173 Nach jeder Phase des Produktlebenszyklus findet die Sicherheitsbeurteilung statt. Diese hat zum Ziel die Evaluierung der tatsächlich erreichten Sicherheitsintegrität einer Sicherheitsfunktion.
174 Erst wenn der Bewertungsplan sowohl von den ausführenden Personen als auch von dem Management bewilligt ist, findet die Bewertung statt. Der Plan setzt die Verantwortlichen für die Bewertung und deren Kompetenzen, die resultierende Dokumente, die involvierten Sicherheitsobjekte und notwendigen Ressourcen fest \cite{iec61508}.
176 Weiterhin beschreibt der Plan auch den Unabhängigkeitsgrad des Bewertungspersonals. Die notwendige Unabhängigkeit wird durch den Standard reguliert. Für SIL 3 verlangt dieser -- in Abhängigkeit von einigen Faktoren -- eine unabhängige Abteilung oder eine unabhängige Gesellschaft. Ist eine strikte Trennung der Safety-Abteilung von der Entwicklungsabteilung gewährleistet, ist das Personal geeignet geschult und bringt die nötige Erfahrung in Risikobewertung und sicherheitsabhängigen Systemen mit, so kann die Safety-Abteilung die Beurteilung übernehmen. Falls das nicht gegeben ist, muss ein externer Dienstleister, der die nötigen Qualitäten mitbringt, mit der Risikobewertung beauftragt werden.
178 Zur Bestimmung des SIL einer vorhandenen Software stellt \cite{iec61508} Normen auf. Durch statistisches Testen kann man mit Hilfe der Tabellen den SIL der Software bestimmen. Es findet wieder eine Unterscheidung zwischen \emph{Low demand mode of operation} und \emph{High demand mode of operation} statt. Abb. \ref{fig:sil_conf} zeigt die Verteilung für die erste Funktionsvariante.
182 \includegraphics[width=7.5cm]{sil_conf.pdf}
183 \caption{Statistische Verteilung zur Bestimmung des SIL für Low demand mode of operation (Quelle: \cite{iec61508} Teil 7 Annex D S. 209)}
187 \section{Modellbasiertes Testen}
188 Stetig wächst das Interesse nach Vereinfachung und Beschleunigung der Softwareentwicklung aus ökonomischen Gründen.
189 Modellgetriebene Softwareentwicklung bietet eine Abstraktion von der Implementierung und Modularität an.
191 Robuste, verlässliche und sichere Module können die Bausteine von großen Softwareprojekten sein. Das erleichtern nicht nur die Entwicklung, sondern insbesondere auch die Verifikation der Sicherheitsintegrität.
192 Modelle sind einfacher strukturiert und dadurch verständlicher für den Menschen. Verständlichkeit und Einfachheit sind wichtig bei der Ermittlung der Korrektheit des Designs und machen die Funktionen anpassungsfähiger, wenn die Notwendigkeit der Entwurfsänderung eintritt, z.B. zur Reduktion eines nicht-tolerierbaren Risikos.
194 Wichtig für die Akzeptanz von solchen Entwicklungsverfahren ist neben der Wirtschaftlichkeit auch die Qualität der Werkzeuge, wie z.B. dem Code-Generator. \cite{code_gen} beschreibt den Zertifizierungsprozess des ASCET Code Generators nach \cite{iec61508}.
196 Zur Validierung eines Softwaremoduls werden bei der statischen Analyse nur noch die Modelle betrachtet, ohne sich mit den Gegebenheiten des entstandenen Quellcodes auseinander zu setzen. Das Entfallen von Implementierungsfehlern ermöglicht eine effizientere Validierungsprozedur und erhöht die Wahrscheinlichkeit der Identifikation von Fehlerquellen bei gleichem Aufwand.
199 Softwaresicherheit, Softwaretests und automatisierte Testfallerstellung sind weiterhin offene Probleme. Der Anstieg an Softwarelösungen für Sicherheitsfunktionen ist durch die wachsende Komplexität der Systeme unausweichlich. Methoden zur Vermeidung, Aufspüren und Beseitigung von Fehlern ist ein aktives Forschungsgebiet, welches durch die Notwendigkeit einer verlässlichen und allgemeingültigen Lösung getrieben wird.
201 Trotz Kritik an IEC 61508, es sei vielmehr ein Standard für Qualitätssicherung als für funktionale Sicherheit, biete keine genauen Richtlinien zur Berücksichtigung der Gesamtgröße eines Systems \cite{silcalc} und definiert keine Möglichkeit zur einheitlichen Ermittlung des SIL für SIS\footnote{Safety Instrumented System} mit variablen Bedarfsanforderungen \cite{bridge},\cite{unified}, findet dieser in immer mehr Sektoren Einsatz und dient für viele andere Standards als Basis.
203 Dieser Text soll einen Einstieg in die Problematik bieten und notwendige Vorgehensweisen zur Zertifizierung nach SIL 3 erläutern. Testfallerstellung kann in Anbetracht von Verifizierungsmaßnahmen nicht isoliert betrachtet werden, sondern als interdisziplinäres Gesamtkonzept verstanden und gelöst werden.
205 Der Einsatz von modellgetriebener Entwicklung unter Verwendung von zertifizierten Code-Generatoren oder der formale Beweis der Fehlerfreiheit, wie er zur Zeit in einer experimentellen Studie für den Microsoft Hypervisor erstellt wird, können in Zukunft die Basis zur Validierung von Sicherheitssystemen bilden. Der IEC 61508 ist jedoch weiterhin auf die Kompetenz und Erfahrung der Ingenieure angewiesen, gleiches gilt für die Normen, die auf dem IEC 61508 basieren. Die wesentlichen Maßnahmen zur Unterstützung der Personalarbeit bei der Verifikation der Sicherheitsintegrität sind gründliche Dokumentenführung, geeignete Prozessmodelle und Werkzeugunterstützung in allen Entwicklungsphasen.