Anforderungen an Software in sicherheitskritischen Systemen

Transkript

1 Anforderungen an Software in sicherheitskritischen Systemen Vorstellung der Sicherheits-Grundnorm ISO IEC Tim Fuhrmann Technische Universität Darmstadt Darmstadt, Germany ABSTRACT Diese Arbeit beschäftigt sich mit der Sicherheitsgrundnorm ISO IEC 61508, die eingesetzt wird, um die funktionale Sicherheit sicherheitsbezogener elektrischer, elektronischer und programmierbar elektronischer Systeme (E/E/PE-Systeme) zu gewährleisten. Wenn man bedenkt, dass der Anteil der sicherheitsbezogenen elektronischen Steuerungen und der Software in den Produkten in den letzten Jahren stark angestiegen ist und diese Entwicklung in Zukunft sicher nicht zu stoppen sein wird, gewinnt das Thema Sicherheit weiter an Brisanz und die Anwendung von Sicherheitsnormen ist unumgänglich. Durch diese Arbeit soll verdeutlicht werden, dass die Anwendung solcher Normen zum Erreichen eines hohen Grades an funktionaler Sicherheit technischer Systeme einerseits unumgänglich ist; andererseits jedoch stets unvermeidbare Restrisiken bleiben, die mit zunehmender Automatisation in Zukunft sicher immer schwerer kontrollierbar werden. Hauptbegriffe Dokumentation, Sicherheit, Verifikation Schlüsselwörter Funktionale Sicherheit, Risikoanalyse, Sicherheitsintegrität, ISO IEC 61508, (Software-)Sicherheitslebenszyklus 1. EINLEITUNG Meist werden die Themen Sicherheit und Risiko in der Öffentlichkeit erst wieder aufgegriffen, wenn durch menschliches Versagen oder technische Defizite Fehler in Geräten oder technischen Systemen entstanden sind, die Menschen gefährdet, verletzt oder im schlimmsten Fall sogar Menschenleben gekostet haben. Aufgrund dessen stellt die Gesellschaft hohe Erwartungen an die Sicherheit von Systemen und an die Reduzierung von Risiken. Durch die Einführung des Geräte- und Produktsicherheitsgesetzes (GPSG) erfolgte eine politische Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 20XX ACM X-XXXXX-XXX-X/XX/XXXX $ Reaktion in Bezug auf die Umsetzung von Sicherheitsanforderungen. Zur nachweisbaren Erfüllung von systemspezifischen Sicherheitsanforderungen wurden Sicherheitsnormen wie die hier vorgestellte ISO IEC entwickelt, die entsprechend der zunehmenden technischen Fortschritte stets überarbeitet und weiterentwickelt werden müssen, um dem aktuellen Stand der Technik zu entsprechen. Sicherheitsnormen geben bestimmte Arbeitsschritte bzw. Regeln vor, deren systematische Abarbeitung bzw. Einhaltung bei der Entwicklung sicherheitsbezogener Systeme von enormer Wichtigkeit sind (Sicherheitslebenszyklen). Bevor in Kapitel 3 konkret auf die oben genannte Norm, einige davon abgeleitete Normen (3.1), die Anwendungsproblematik der Grundnorm (3.1.1), auf ihre allgemeinen Anforderungen (3.2) sowie auf ihre Anforderungen an Software (3.3) eingegangen wird, soll mit der Einführung des Begriffs der funktionalen Sicherheit in Kapitel 2 zunächst eine Wissensbasis gelegt werden. Neben dieser Begriffserklärung werden anschließend zwei Kernthemen für die Einhaltung von Sicherheitsnormen behandelt die Risikoanalyse sowie die Sicherheitsintegrität (2.1). In Kapitel 4 erfolgt eine Zusammenfassung der dargelegten Aspekte. Diese Arbeit orientiert sich hauptsächlich am Buch von Löw [3]. 2. FUNKTIONALE SICHERHEIT Der Sicherheitsbegriff begegnet uns im Alltagsleben in den verschiedensten Kontexten. Funktionale Sicherheit ist im Bereich der technischen Sicherheit von System einzuordnen, welche die Aspekte Betriebs- und Angriffssicherheit umfasst. Während Betriebssicherheit (Safety) in Zusammenhang mit den Risiken und Gefahren zu sehen ist, die von einem System ausgehen, bezieht sich die Angriffssicherheit (Security) auf den Schutz vor Gefahren, die von außen auf Systeme oder Personen einwirken. Diese beiden Aspekte sind jedoch nicht isoliert voander zu betrachten. Geht man nämlich davon aus, dass beispielsweise durch mangelnde Angriffssicherheit Manipulationen an Systemen möglich sind (Missbrauch) und Systeme dadurch in gefährliche Zustände versetzt werden können, sind die Überschneidungen zwischen Betriebs- und Angriffssicherheit deutlich zu erkennen. Solche gefährlichen Situationen gilt es im Sinne der Betriebssicherheit mit dem Ziel, eine Freiheit von unvertretbaren Risiken zu erreichen, zu vermeiden. Dabei stellt die funktionale Sicherheit denjenigen Teil der Gesamtsicherheit dar, der von der korrekten Funktion des sicherheitsbezogenen Systems abhängt [3].

2 Der folgende Abschnitt beschäftigt sich mit der Risikoanalyse sowie mit den Anforderungen an die Sicherheitsintegrität zwei zentrale Arbeitsschritte bei der Entwicklung sicherheitsbezogener Systeme [2, 3, 4]. 2.1 Risikoanalyse und Sicherheitsintegrität Im letzten Abschnitt wurde der Begriff der Betriebssicherheit in Bezug auf die Vermeidung/Kontrolle von Risiken, die von einem System ausgehen, definiert. Mit der Einführung von Sicherheitsnormen wird beabsichtigt, genau diese Risiken auf ein vertretbares oder tolerierbares Maß zu senken, wobei stets ein Restrisiko bleiben wird. Ferner geht es bei der Risikominimierung hauptsächlich um die Vermeidung von Personenschäden und nur sekundär um die Reduzierung von Vermögensschäden. Sicherheitsnormen definieren ein Risiko als eine Kombination aus der Wahrscheinlichkeit, mit der ein Schaden eintritt und dem Ausmaß (Auswirkungen) dieses Schadens (siehe Abb. 1). Wahrscheinlichkeit Risiko 1 Risiko 2 Auswirkung Abbildung 1: Risiko = Wahrscheinlichkeit * Auswirkung Maßnahmen zur Risikominderung können sich entweder auf die Reduzierung der Ausfallwahrscheinlichkeit von Systemen oder auf die Verringerung des Schadensausmaßes beziehen. Während Letzteres zum Bereich der passiven Sicherheit gehört und durch externe Maßnahmen realisiert wird (z.b. Schutzhauben über Werkzeugmaschinen), dienen so genannte Sicherheitsfunktionen wie z.b. elektronische Überwachungseinrichtungen zum Erreichen der aktiven Sicherheit, um Gefahrensituationen von vornherein zu vermeiden. Diese Funktionen werden aus Sicherheitszielen abgeleitet, die im Zuge der Gefährdungs- und Risikoanalyse formuliert werden (siehe Phase 3 des Sicherheitslebenszyklus in 3.2.1). Sicherheitsfunktionen haben die Aufgabe, Fehler zu erkennen und einen sicheren Zustand für das System zu erreichen oder aufrecht zu erhalten. Soll es also darum gehen, Gefahren von vornherein zu vermeiden, versucht man im Bereich der aktiven Sicherheit durch den Einsatz oben beschriebener Sicherheitsfunktionen, eine bestimmte Sicherheitsintegrität zu erreichen. Diese ist ein Maß für die Wahrscheinlichkeit, dass ein sicherheitsbezogenes System die geforderten Sicherheitsfunktionen anforderungsgemäß ausführt. Definiert werden die Anforderungen an die Sicherheitsintegrität über so genannte Sicherheits-Integritätlevel (SIL). In der im folgenden Kapitel vorgestellten Norm sind vier dieser Level definiert (SIL 1-4). Je höher der SIL, desto größer ist die geforderte Risikominderung für ein System und somit meist auch die Anzahl der Sicherheitsfunktionen. Die notwendige Risikominderung muss immer in Abhängigkeit von den Folgen beurteilt werden, die durch einen Systemfehler oder -ausfall entstehen können. Beispielsweise kann ein System mit einer hohen Ausfallwahrscheinlichkeit bei wiederholten Ausfällen stets einen geringen Schaden verursachen, während ein System mit geringer Ausfallwahrscheinlichkeit im Falle eines (einmaligen) Fehlers zu gravierenden Folgen führen könnte (Verletzungen/Tod). Definiert ist die Ausfallwahrscheinlichkeit als die Wahrscheinlichkeit, mit der eine Funktionseinheit ihre geforderte Funktion nicht erfüllt. Dabei wird zwischen der Ausfallwahrscheinlichkeit pro Stunde (Probability of Failure per Hour, PFH) und der Ausfallwahrscheinlichkeit bei Anforderung (Probability of Failure on Demand, PFD) unterschieden. Jeder Sicherheitsfunktion kann eine bestimmte Anforderungsrate zugeordnet werden (Betriebsart). Verfügt eine Funktion über eine niedrige Rate (low demand mode), so wird sie im Durchschnitt höchstens einmal pro Jahr angefordert (z.b. Auslösung des Airbags bei KFZ-Unfall). Funktionen mit hohen Anforderungsraten (high demand/continuous mode) werden häufiger als einmal pro Jahr benötigt, was z.b. bei Lenksystemund Getriebemanagementfunktionen bei jeder Autofahrt der Fall ist. Sicherheitsfunktionen, die kontinuierlich benötigt werden (high demand), dürfen nur eine sehr geringe Ausfallwahrscheinlichkeit pro Stunde (PFH) besitzen, während selten angeforderte Funktionen eine niedrige Ausfallwahrscheinlichkeit bei ihrer Anforderung (PFD) benötigen. Sicherheitsnormen fordern die Festlegung von Ausfallgrenzwerten für Sicherheitsfunktionen und geben teilweise solche Grenzwerte für die jeweiligen SIL vor (siehe Tab. 1). Für alle Sicherheitsfunktionen werden durch die vorgegebenen Sicherheitsintegritäten und Betriebsarten die Ausfallgrenzwerte für zufällig gefahrbringende Ausfälle der Hardware ermittelt. FIT (Failure in Time) ist die Einheit, in der Ausfallraten, die ein Maß für die Anzahl der Ausfälle pro Zeiteinheit darstellen, gemessen werden (1 FIT = 1/ /h). SIL Tabelle 1: Ausfallgrenzwerte der Hardware low demand : Ausfallwahrscheinlichkeit pro Anforderung (PFD) high demand : Ausfallrate pro Stunde (PFH) 1 < 1/10 < 1/ /h = FIT 2 < 1/100 < 1/ /h = FIT 3 < 1/1.000 < 1/ /h = 100 FIT 4 < 1/ < 1/ /h = 10 FIT Basierend auf der in diesem Abschnitt gelegten Wissensgrundlage wird nun im folgenden Kapitel konkret auf die Sicherheitsgrundnorm ISO IEC eingegangen. 3. GRUNDNORM ISO IEC Die internationale Norm ISO (International Organization for Standardization) IEC (International Electrotechnical Commission) definiert als Grundnorm (Typ-A-Norm) die allgemeingültigen Anforderungen zur funktionalen Sicherheit. Sie wurde 1998 erstmals veröffentlicht, 2001 als deutsche Norm DIN (Deutsches Institut für Normung) EN (Europäische Norm) übernommen und trägt den Titel Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbar elektronischer Systeme. Die Norm besteht aus folgenden sieben Teilen:

3 DIN EN : Allgemeine Anforderungen DIN EN : Anforderungen an sicherheitsbezogene E/E/PE-Systeme DIN EN : Anforderungen an Software DIN EN : Begriffe und Abkürzungen DIN EN : Beispiele zur Ermittlung der Stufe der Sicherheitsintegrität DIN EN : Anwendungsrichtlinie für Teil 2 und 3 DIN EN : Anwendungshinweise über Verfahren und Maßnahmen Kann das System eine Gefahr für Gesundheit und Menschenleben darstellen? Prüfen Sie die Anwendbarkeit anderer Normen 3.1 Bereichsspezifische Normen Black [1] spricht in Bezug auf die Entwicklung der Grundnorm von einem allgemeinen Rahmen und betont die Wichtigkeit, auf dessen Grundlage bereichsspezifische Normen zu entwickeln. Dabei bezieht er sich auf strukturelle Unterschiede zwischen den einzelnen Sektoren, die verschiedene Bedingungen für die Anwendung von Sicherheitsnormen schaffen. Einige bereichsspezifische Normen wurden bereits als Typ-B- oder Typ- C-Norm aus der Grundnorm vom Typ A abgeleitet. Exemplarisch werden in Abb. 2 einige bereichsspezifische Normen vorgestellt: DIN IEC Kernkraftwerke DIN EN 501xx Bahn ISO/DIS Automobil Gibt es für den Anwendungsbereich eine spezifische Norm, die aus IEC abgeleitet ist? Handelt es sich bei der einzusetzenden Technologie um E/E/PES? Wenden Sie diese spezifische Norm an! Für Automotive in Zukunft ISO/DIS (siehe Abb. 2) Sie können DIN EN als Hilfestellung nutzen; z.b. für den Sicherheitslebenszyklus DIN EN Prozessindustrie DIN EN Medizingeräte IEC DIN EN Maschinen DIN EN Feuerungen DIN EN Hausgeräte Abbildung 2: Grundnorm IEC und abgeleitete Normen Anwendungsproblematik der Grundnorm Falls vorhanden, ist in der Praxis die Verwendung von bereichsspezifischen Normen zu empfehlen, da sich aufgrund der überwiegend sehr allgemein gehaltenen Inhalte der Grundnorm projektspezifisch einige Freiräume zur Interpretation bieten [1, 3]. Die Norm an verschiedene Projekte anzupassen bzw. Konkretisierungen vorzunehmen, bringt in vielen Fällen einen hohen Arbeitsaufwand mit sich. Außerdem ist zu beachten, dass bei der Entwicklung von DIN EN primär davon ausgegangen wurde, die Anwendung der Norm auf die Inbetriebnahme und Nutzung einer Anlage (z.b. Chemieanlage) zu beschränken. Bezüglich der Entwicklung von Serienprodukten (z.b. PKW), die nicht nur einmalig installiert und betrieben werden, sondern in großer Stückzahl produziert und verkauft werden, bietet die Grundnorm beispielsweise keine angemessene Art bzw. Methode der Gefährdungs- und Risikoanalyse. Bereichsspezifische (abgeleitete) Normen lösen dieses Problem, indem das Sicherheitslebenszyklus-Modell, das im weiteren Verlauf dieser Arbeit noch eine große Rolle spielen wird, modifiziert bzw. den spezifischen Anforderungen des jeweiligen Serienprodukts entsprechend angepasst wird. Abb. 3 verdeutlicht die Einschränkungen bei der Anwendung der Grundnorm bzw. die Priorität der Verwendung von bereichsspezifischen Normen. Ist das Verhalten des Systems vollständig bekannt? (einfaches sicherheitsbezogenes E/E/PES?) Nutzen Sie DIN EN und weichen Sie in begündeten Einzelfällen von den Anforderungen ab Erfüllen Sie die Ziele und Anforderungen von DIN EN Abbildung 3: Anwendbarkeit der Grundnorm DIN EN Allgemeine Anforderungen Durch die Formulierung allgemeiner Anforderungen im ersten Teil der Norm soll eine systematische, für alle Phasen anwendbare und konsistente Vorgehensweise bei Systementwicklungen erreicht werden. Neben den (vor allem frühen) Phasen des Sicherheitslebenszyklus (3.2.1) wie die Risikoanalyse oder die Spezifikation der Sicherheitsanforderungen, betreffen die allgemeinen Anforderungen auch einige phasenübergreifende Aktivitäten, die zwar im Rahmen dieser Arbeit von geringer Bedeutung sind, der Vollständigkeit halber jedoch an dieser Stelle kurz angesprochen werden sollen. Phasenübergreifende Aktivitäten beziehen sich auf das Management und die Beurteilung (Assessment) der funktionalen Sicherheit sowie auf eine genaue Dokumentation, um die Durchführung der Phasen des Sicherheitslebenszyklus wirkungsvoll zu unterstützen.

4 3.2.1 Sicherheitslebenszyklus Die oben vorgestellte Norm definiert einen Sicherheitslebenszyklus [2, 3, 4], der alle Phasen von der Konzeptfindung bis zur Außerbetriebnahme eines Systems beschreibt. Die Zielsetzung des Zyklus ist die systematische Abhandlung aller Tätigkeiten, die zum Erreichen und Erhalten des geforderten SIL nötig sind. Bevor in Kapitel der von diesem Zyklus abgeleitete Software-Sicherheitslebenszyklus zur Softwareentwicklung vorgestellt wird, sollen an dieser Stelle kurz die einzelnen Phasen des übergeordneten Zyklus angesprochen werden. In der Konzeptphase (Phase 1) geht es darum, sich mit dem zu entwickelnden System vertraut zu machen, also die Einrichtung, die Maschine oder das Produkt zu verstehen. Die Norm bezeichnet dieses System als EUC (Equipment Under Control) [4]. Darüber hinaus werden in dieser Phase erste Überlegungen bezüglich möglicher Gefährdungsquellen, einzuhaltender Sicherheitsvorschriften und Wechselwirkungen zu anderen Systemen angestellt. Phase 2 des Zyklus definiert den genauen Anwendungsbereich des Systems. Es wird also genau festgelegt, was inner- und was außerhalb des Betrachtungsumfangs liegt. Dabei muss beispielsweise entschieden werden, ob nun der gesamte PKW oder nur das Getriebe zum konkreten Anwendungsbereich gehört. Desweiteren findet eine erste Recherche nach verschiedenen Auslösern für Unfälle statt (externe Ereignisse), deren Ergebnisse bei der Durchführung der darauf folgenden Phase benötigt werden. Die Gefährdungs- und Risikoanalyse (Phase 3) ist der wichtigste Schritt für die Durchführung aller weiteren sicherheitsbezogenen Aktivitäten, weshalb das Ergebnis dieser Phase ein zentrales Dokument darstellt. Unter anderem wird zu diesem Zeitpunkt des Zyklus der notwendige SIL bestimmt. Aufgrund der enormen Bedeutung dieser Phase wurde im ersten Teil dieser Arbeit bereits auf die Themen der Risikoanalyse sowie auf die Sicherheitsintegrität eingegangen (2.1). Die Bestimmung des SIL als geforderte Risikominderung ist abhängig von der Wahrscheinlichkeit des Eintretens gefährlicher Vorfälle unter Berücksichtigung der daraus entstehenden Schäden/Auswirkungen (Abb. 1). Es werden in dieser Phase bereits meist Sicherheitsziele formuliert, die Anforderungen an Funktionen zur Erreichung und Erhaltung der Sicherheit beinhalten. Die folgende Phase 4 benötigt als Eingangsdokumente sowohl die Beschreibung des Systems und seiner Komponenten (EUC), die als Ergebnis der Phase 1 vorliegen muss, als auch die Ergebnisse aus der voran gegangenen Phase 3 hinsichtlich der festgelegten Sicherheitsintegrität und der Sicherheitsziele. Auf dieser Grundlage erfolgt nun eine Spezifikation der gesamten Sicherheitsanforderungen. Präziser formuliert werden zum einen die Gesamtsicherheitsfunktionen beschrieben, die sich aus den festgestellten gefährlichen Vorfällen herleiten lassen. Zum anderen wird für jede Gesamtsicherheitsfunktion ein Zielwert der Sicherheitsintegrität festgelegt (SIL), der Auskunft über das tolerierbare Risiko gibt. Zusätzlich soll durch ein Attribut, das anhand der erforderlichen Risikominderung Anforderungen zur Gesamtsicherheitsintegrität stellt, das tolerierbare Risiko erreicht werden. Falls aus der Gefährdungs- und Risikoanalyse bereits Zielwerte für die Sicherheitsintegrität jeder Gesamtsicherheitsfunktion vorliegen, wird diese Phase in der Praxis übersprungen sie kann als formale Zwischenstufe gesehen werden, um später konkrete Ausfallgrenzwerte (vgl. 2.1) und den zugehörigen SIL für die durch das sicherheitsbezogene E/E/PE-System zu implementierenden Sicherheitsfunktionen bestimmen zu können. In Phase 5 des Sicherheitslebenszyklus werden die Ergebnisse der vorigen Phase (Gesamtsicherheitsfunktionen und Anforderungen zur Gesamtsicherheitsintegrität) den vorgesehenen E/E/PE- Systemen zugeordnet, bevor dann im weiteren Verlauf des Zyklus die Spezifikation der Sicherheitsanforderungen des E/E/PE- Systems erfolgt. Die Phasen der Installation, des Betriebs, der Modifikation und der Außerbetriebnahme definieren die letzten Phasen des Sicherheitslebenszyklus, also die Phasen nach der im nächsten Abschnitt folgenden Realisierung der Software (werden hier nicht ausführlicher erläutert, da es in dieser Arbeit hauptsächlich um Software-Anforderungen geht). 3.3 Anforderungen an Software Nachdem im bisherigen Verlauf der Arbeit vor allem der erste Teil der Norm (DIN EN ) im Vordergrund stand, um einen Einblick in die Thematik von Sicherheitsnormung zu bekommen, behandelt dieses Kapitel den dritten Teil der Norm die Anforderungen der Norm an Software [3]. Die Anforderungen der Norm DIN EN beziehen sich auf die Tätigkeiten und Maßnahmen zur Vermeidung und Beherrschung von Fehlern, die während des Entwurfs und der Entwicklung von sicherheitsbezogener Software angewendet werden müssen. Als Teil des sicherheitsbezogenen Systems gelten auch für die Entwicklung der Software die phasenübergreifenden Vorgaben in Bezug auf Projektmanagement (Management und Beurteilung der funktionalen Sicherheit) und Dokumentation (vgl. 3.2) Software-Sicherheitslebenszyklus Von dem im voran gegangenen Abschnitt vorgestellten Sicherheitslebenszyklus wurde der im Folgenden vorgestellte Zyklus zur Software-Entwicklung abgeleitet [3]. Dieses Kapitel beschreibt alle Schritte von der Spezifikation der Software- Sicherheitsanforderungen bis zur Validierung der Software. Der bei der Software-Entwicklung zu durchlaufene Zyklus stellt ein V- Modell dar (siehe Abb. 4). Dabei zeigen die gelben Pfeile die Abfolge der Arbeitsschritte innerhalb des Modells, während die lila gefärbten Pfeile verdeutlichen, an welchen Stellen verifiziert werden muss, d.h., wann bzw. wo ein Nachweis verlangt wird, dass Ergebnisse am jeweiligen Phasenende das zuvor spezifizierte Verhalten zeigen. Anforderungen SW-Architektur Entwurf Arbeitsprodukt SW-Sicherheits- SW-System- SW-Modul- Entwurf Codierung Modultest Validierungstest Integrationstest (PE HW & SW) Integrationstest (SW-Module) Verifikation Abbildung 4: Softwaresicherheitszyklus nach DIN EN

5 Bevor mit der Software-Entwicklung begonnen werden kann, müssen die Spezifikation der E/E/PE-Entwurfsanforderungen, die Entwicklung der E/E/PE-Architektur sowie der programmierbaren Elektronik für die Hardware- und Software-Integrationstests abgeschlossen sein (Ergebnisse der E/E/PE-Realisierungsphase). In Bezug auf die Spezifikation der Sicherheitsanforderungen (Phase 1) ist darauf zu achten, dass diese verständlich, präzise, eindeutig, nachprüfbar, testbar, pflegbar, ausführbar und rückführbar zur Eingangsdokumentation sind. Zudem muss durch die Spezifikation gewährleistet sein, dass die Anforderungen angemessen hinsichtlich der Systemarchitektur und dem geforderten SIL sind sowie die Software-Entwickler in jeder Phase des Zyklus unterstützen. Um Fehler und Inkonsistenzen zu vermeiden, wird empfohlen, rechnergestützte Spezifikationswerkzeuge (z.b. Datenbanken) zu verwenden, die eine automatisierte Überprüfung der Spezifikationen auf Konsistenz und Vollständigkeit erlauben. Die Phasen 2-7 des Zyklus decken den Softwareentwurf sowie die -entwicklung ab. Zunächst erfolgt eine Festlegung der wesentlichen Softwareteilsysteme sowie deren Beziehungen untereinander. Für jedes Teilsystem ist eine Funktionsbeschreibung und der geforderte SIL zu spezifizieren. Außerdem muss zwischen sicherheitsbezogenen und nicht sicherheitsbezogenen Anteilen für jedes Teilsystem abgegrenzt werden. Sollte ein System beide Anteile enthalten, so ist es als rein sicherheitsbezogen zu behandeln, es sei denn, diese sind genügend unabhängig voander. Bereits existierende Softwareelemente dürfen nur wiederholt eingesetzt werden, wenn ein Sicherheitshandbuch für diese Elemente vorliegt. Desweiteren muss festgelegt sein, wie die Softwarearchitektur ausreichend getestet werden kann, um prüfen zu können, ob die geforderten Sicherheitsanforderungen erreicht wurden (z.b. Fehlertoleranz oder Wechselwirkungen mit dem Systemumfeld). An dieser Stelle erfolgt jedoch nur die Testspezifikation die Durchführung der Tests erfolgt erst in der Phase der Integration (PE HW & SW). Nach Abschluss der Entwicklung der Softwarearchitektur wird eine Modularisierung durchgeführt, bei der die Teilsysteme in Softwaremodule aufgeteilt/zerlegt werden. Damit wird beabsichtigt, die Komplexität und somit die Fehleranfälligkeit zu reduzieren, indem beispielsweise jedes Modul lediglich eine einzige Funktion enthält. In der darauf folgenden Phase findet die Umsetzung der Modulentwürfe in den Quellcode statt (Codierung). Bei der Implementierung ist zu empfehlen, defensive Programmierung anzuwenden. Auf diese Weise können Fehler oder Abweichungen bereits während der Programmausführung erkannt, behoben oder wenigstens kontrolliert werden, so dass es zu keiner fehlerhaften Verarbeitung von sicherheitsbezogenen Daten kommt. Außerdem sollte unabhängig vom SIL stets eine strukturierte Programmierung erfolgen, um die Programme leichter analysierbar und somit nachvollziehbarer und verständlicher zu machen. Zwar zieht eine Verringerung der Komplexität oft auch Effizienzverluste nach sich. Sollte die Effizienz jedoch nicht explizit Teil der Sicherheitsanforderungen sein, liegt die Priorität auf der Seite der funktionalen Sicherheit und ein höherer Speicherplatzbedarf sowie längere Durchlaufzeiten werden in Kauf genommen. Es folgen nun verschiedene Testphasen innerhalb des Software- Sicherheitslebenszyklus. Zunächst sorgen Modultests dafür, die während der Codierungsphase fertiggestellten Module entsprechend der oben erwähnten Spezifikationen zu testen, um am Ende dieser Phase nachgewiesen zu haben, dass die Module ihre bestimmungsgemäße Funktion ausführen bzw. den gestellten Anforderungen gerecht werden. Im Anschluss soll in der Phase Integrationstest (SW-Module) die Zusammenführung der einzelnen Module Aufschluss darüber geben, ob die Teilsysteme vorschriftsmäßig zusammen wirken und somit ihre Funktionen gemäß der Spezifikation ausführen. Dabei ist zu beachten, dass in dieser Phase korrigierte Module erneut dem voran gegangenen Modultest zu unterziehen sind, bevor sie einem weiteren Integrationstest unterzogen werden. Der in der Folgephase durchgeführte Integrationstest (PE HW & SW) prüft die Verträglichkeit von Soft- und Hardware, indem Software und programmierbare Elektronik (PE) zusammen geführt wird. Ein erfolgreicher Test zeigt, dass der angestrebte SIL erreicht wurde. Im letzten Schritt des Software-Sicherheitszyklus erfolgt die Validierung. Es wird getestet, ob die Software tatsächlich der Spezifikation der Sicherheitsanfoderungen genügt. Dies ist dann der Fall, wenn im gesamten Entwicklungsprozess die dem SIL entsprechenden Maßnahmen umgesetzt wurden. 4. FAZIT Zusammenfassend kann festgestellt werden, dass die Anwendbarkeit der Sicherheits-Grundnorm DIN EN eingeschränkt ist. Sie ist dann geeignet, wenn es darum geht, die funktionale Sicherheit bei der Entwicklung größerer Anlagen zu gewährleisten (einmalige Inbetriebnahme und Nutzung), die durch elektrische/elektronische oder programmierbar elektronische Systeme gesteuert werden. Für die Entwicklung von Serienprodukten erweist sich die Norm aufgrund ihrer überwiegend allgemein gehaltenen Sicherheitsanforderungen als zu wenig konkret und wird somit den spezifischen Anforderungen bestimmter Projekte oft nicht gerecht. Falls vorhanden, ist in diesem Fall der Einsatz abgeleiteter Normen zu empfehlen. Während der Abarbeitung des (Software)-Sicherheitslebenszyklus wird versucht, durch Gefährdungs- und Risikoanalysen, durch Festlegung/Einhaltung von Sicherheitsintegritäten und mit Hilfe geeigneter Sicherheitsfunktionen ein hohes Maß an funktionaler Sicherheit zu ermöglichen. Gerade im Bereich der Software- Entwicklung und speziell bei der Programmierung (Codierung) wird das Ziel verfolgt, durch eine detaillierte und präzise durchdachte Vorgehensweise Fehler und Gefahren zu erkennen und zu beheben/kontrollieren, bevor überhaupt die Auswirkungen spürbar werden (z.b. defensive Programmierung). Es bleibt jedoch immer ein Restrisiko, das zwar tolerierbar, jedoch trotz allem vorhanden ist; und mit Ausblick in die Zukunft, die von zunehmender Automatisation und somit auch vom weiterhin steigenden Einsatz technischer Systeme geprägt sein wird (z.b. zwecks Komfortsteigerung), stellt sich die Frage, ob dann noch eine ausreichende Risikominderung durch Sicherheitsnormen erfolgen kann oder ob der Mensch in vielen Lebenslagen irgendwann nicht mehr kalkulierbaren Risiken ausgesetzt ist. 5. LITERATUR [1] Black, W. S., IEC what it doesn t tell you. In Computing & Control Engineering Journal (February 2000). DOI= [2] Brown, Simon, Overview of IEC 61508: Design of electrical/electronic/programmable electronic safety-related systems. In Computing & Control Engineering Journal (February 2000). DOI= [3] Löw, Peter Funktionale Sicherheit in der Praxis (1.Auflage). Heidelberg, dpunkt-verlag. DOI= [4] Redmill, Felix, Principles and use in the management of safety. In Computing & Control Engineering Journal (October 1998). DOI=