Verifikation und Validierung sicherheitskritischer Systeme

Nach der Idee, Sicherheitsfunktionen auf eine Steuerung zu verlagern und damit mehr Flexibilität anbieten zu können, kommt bei der Umsetzung schnell die Frage nach den Auswirkungen auf den Entwicklungsprozess. Viele Firmen haben Qualitätsmanagementsysteme etabliert und sind ISO9001-zertifiziert. Oft ist dabei eine Überarbeitung der Entwicklungsabläufe notwendig gewesen. Bei der Entwicklung sicherheitsbezogener Systeme sind aber die Anforderungen der entsprechenden Sicherheitsnormen zu erfüllen. Welche Norm anzuwenden ist, wird u.a. durch die Branche bestimmt, in der das System zum Einsatz kommt. So wird beispielsweise in der Maschinenindustrie nach der ISO13849 oder der IEC62061 gearbeitet, in der Prozessindustrie ist es die IEC61511. Diese Normen orientieren sich stark an der Grundnorm für funktionale Sicherheit, der IEC61508, und/oder präzisieren diese. Da die Sicherheitsnormen einen Entwicklungsprozess nach V-Modell und Qualitätssicherungsmaßnahmen wie Konfigurationsmanagement oder Änderungsmanagement fordern, sind die Anpassungen am geringsten, wenn der eigene Entwicklungsprozess schon am V-Modell ausgerichtet und ein Qualitätsmanagement eingeführt ist. Die wesentlichen Erweiterungen bestehen in folgenden Punkten: – Definition eines Sicherheitslebenszyklus – Vorgaben zur Dokumentation, um die Nachvollziehbarkeit der Entwicklung zu gewährleisten – Anforderungen zur Risikobetrachtung – Vorgaben zu Verifikation und Validierung – Anforderungen zu Ausfallanalysen – Anforderungen zur Beurteilung Einen höheren Aufwand erfordern auch die technischen Planungstätigkeiten, welche in verschiedenen Plänen dokumentiert werden müssen. Die Sicherheitsnormen geben dabei keine feste Dokumentenstruktur vor, sondern legen nur fest, was wann zu planen ist. Die Erstellung dieser Pläne wird häufig als lästiges Übel gesehen, bestimmt aber im Projektverlauf wesentlich die Aufwände für die einzelnen Tätigkeiten. Sicherheitsplan als Basis Der Sicherheitsplan wird oft als übergeordnetes Planungsdokument angelegt. Er enthält die Projektstruktur, die Beteiligten und deren Verantwortlichkeiten und den Schulungsplan und er beschreibt die Phasen des Sicherheitslebenszyklus bezogen auf das Projekt. Er beinhaltet häufig Verweise auf die weiterführenden projektspezifischen Planungsdokumente sowie die firmenspezifischen Prozessbeschreibungen. Der Sicherheitsplan sollte bei der Konzeptbeurteilung vorliegen, da auf dieser Basis schon Korrekturen für den weiteren Projektverlauf vorgenommen werden können. Der Projektplan legt Arbeitspakete und Termine fest und ordnet sie den Beteiligten zu. Im Qualitätsmanagementplan werden z.B. Dokumentstruktur und -ablage sowie das Konfigurationsmanagement und das Änderungsmanagement beschrieben. Die Tätigkeiten zur Verifikation und Validierung werden in einem Dokument, dem Verifikations- und Validierungsplan zusammengefasst. Begriffsbestimmung Unter Verifikation verstehen die Sicherheitsnormen Tätigkeiten zur Überprüfung der Ergebnisse in jeder Phase des Entwicklungsprozesses hinsichtlich der Anforderungen inklusive der Sicherheitsanforderungen. Bei der Verifikation werden die Ausgangsdokumente einer Phase gegen deren Eingangsdokumente geprüft. Beispiel: die Architekturspezifikation eines Systems wird auf Basis der Systemanforderungen oder die Modultestspezifikation auf Basis der Modulspezifikation geprüft. Mit dem Begriff \’Validierung\‘ werden die Tätigkeiten zum Nachweis der Erfüllung der Sicherheitsanforderungen bezeichnet. Voraussetzung für eine effiziente Validierung ist die Anforderungsverfolgung durch den gesamten Entwicklungsprozess. Das Testen gehört sowohl zur Verifikation als auch zur Validierung. Im Verifikations- und Validierungsplan wird meist nur das grundsätzliche Vorgehen beim Testen innerhalb des gesamten Projekts beschrieben und auf die Testpläne verwiesen. Einen Testplan erstellt man häufig für eine Komponente oder ein Teilsystem. Dieser legt fest, welche Tests durchgeführt und wie sie dokumentiert werden. Die detaillierte Beschreibung der Tests inklusive Aufbau, Testumgebung, Testprogramme, Ablauf sowie erwartetes Ergebnis stellt man in den Testspezifikationen dar. Diese baut man z.B. so auf, dass sie bei der Testdurchführung als Template für das Testprotokoll verwendet werden kann. Die einzelnen Pläne sollten kurz gehalten und eine inhaltliche Überlappung vermieden werden. Zu viele Planungsdokumente erhöhen den Verwaltungsaufwand, dagegen behindert eine zu starke Zusammenfassung das Arbeiten mehrerer Beteiligter. Das richtige Maß hängt im Wesentlichen vom Umfang des Projekts ab. Neben der Planung sind alle Verifikations- und Validierungstätigkeiten zu dokumentieren und die Ergebnisse zu bewerten. Anforderungsphase In der Anforderungsphase wird jede Anforderung mit einem eindeutigen Identifikator versehen. Dies kann manuell bei dateibasierter oder automatisch bei datenbankbasierter Projektdokumentation geschehen und ist der erste Schritt für die Validierung. Zum Anforderungsmanagement stehen komfortable Werkzeuge wie der Team Foundation Server (MS), Doors (IBM) oder Requisite Pro (IBM) am Markt zur Verfügung. Die Verifikationstätigkeiten bestehen in dieser Phase größtenteils aus Reviews. Während der Planung sollten Vorlagen für Reviewprotokolle erstellt werden, die den Ablauf und die Dokumentation festlegen. Damit die Reviewaufgabe klar ist, erhalten die Prüfer anhand von Checklisten die Schwerpunktthemen ihrer Prüfung. Das Reviewprotokoll sollte sowohl die Anmerkungen als auch die Überarbeitungskommentare enthalten. Für die Reviewergebnisse lassen sich Kategorien wie z.B. \’Mängelbehebung und Reviewwiederholung\‘ oder \’Freigabe für nächste Phase\‘ definieren. Entwurfsphase In der Entwurfsphase besteht der nächste Schritt der Validierung in der Zuordnung der Anforderungen zu den Komponenten und Funktionen. Bei der Nutzung von Werkzeugen wird das durch die grafische Benutzeroberfläche unterstützt. Bei dateibasierter Arbeitsweise legt man Zuordnungstabellen in den Dokumenten an. Zu den Verifikationstätigkeiten im Entwurf gehören Reviews der Architektur und Designspezifikationen. Um die Maßnahmen in der Architektur zur Fehlervermeidung oder -beherrschung zu bewerten, eignen sich FMEDAs (Failure Mode, Effects and Diagnostic Analysis). Beginnend mit der System-FMEDA werden die Analysen für Schaltpläne oder Softwaremodule fortgesetzt. Implementierung In der Implementierungsphase erfolgt die Zuordnung der Anforderungen über die Komponenten und Module der Entwurfs­dokumente, somit ist eine Verfolgung der Sicherheitsanforderungen bis in den Code möglich. Eine weitere Validierungsaufgabe ist der Nachweis der Eignung der eingesetzten Codegeneratoren und Compiler. Hier besteht die Möglichkeit, durch Analysen die Betriebsbewährtheit zu zeigen, ein zertifiziertes Werkzeug zu kaufen oder durch die Kombination von geeigneten Sprachumfang und Test selbst eine Validierung vorzunehmen. Für die Implementierung der Software werden aus obigem Grund Maßnahmen wie die Einschränkungen des Sprachumfangs und Codierrichtlinien definiert. Zu den Verifikationstätigkeiten in dieser Phase gehört die Überprüfung der Umsetzung dieser Maßnahmen. Dazu können verschiedene am Markt verfügbare Werkzeuge wie z.B. PC-Lint (Gimpel Software), FxCop (MS) oder Astree (Absint) verwendet werden. Die Reports, welche mit diesen Werkzeugen generiert werden, sind zu bewerten. Diese Bewertung kann z.B. in die Protokolle der Codereviews aufgenommen werden. Modul- und Komponententests In der Phase des Modul- und Komponententests werden meist die ersten Validierungstests in Form von Funktions- und Leistungstests durchgeführt. Da die Anforderungen bis in den Code verfolgt werden können, ist eine Zuordnung der Testfälle zu den Anforderungen möglich. Auf der Ebene der Softwaremodule lässt sich eine hohe Testautomatisierung und dadurch eine gute Testabdeckung erreichen. Werkzeuge hierfür sind z.B. CUnit (GNU), Cantata++(IPL) oder Tessy (Hitex). Oft ist in Werkzeugen zur Testautomatisierung auch die Funktionalität zur Messung der Testabdeckung integriert. Die generierten Testreports sind ebenfalls z.B. im Testprotokoll zu bewerten. Insbesondere nicht vollständig getestete Codebereiche sind zu begründen. Integrations- und Systemtest In der Integrationstestphase gehören zu den Validierungstätigkeiten ausfallorientierte Tests, um die Fehler­reaktion zu prüfen. Hierfür wird oft speziell präparierte Hardware zur Fehlerinjektion verwendet. Um eine Reproduzierbarkeit zur gewährleisten, ist der genauen Kennzeichnung der Probanden und der Ablaufbeschreibung in der Testspezifikation erhöhte Aufmerksamkeit zu schenken. Die Sicherheitsgesamtvalidierung ist Teil des Systemtests. Sie umfasst u.a. Funktionstests in verschiedenen Betriebsmodi und unter verschiedenen Umgebungsbedingungen. Durch die Anforderungsverfolgung ist die Erfüllung der Sicherheitsanforderungen auch im Systemtestprotokoll klar nachvollziehbar. Der Validierungsbericht basiert auf den Testprotokollen der verschiedenen Testphasen und dokumentiert die Erfüllung der Sicherheitsanforderungen. Bei Abweichungen der Testergebnisse zu den erwarteten Ergebnissen erfolgt die Überarbeitung oder es werden Nutzungseinschränkungen formuliert. Um bei Regressionstests schneller Ergebnisse zu erhalten, ist auch für den Systemtest eine Testautomatisierung, z.B. mittels Labview (NI), zu empfehlen. Dienstleister in jeder Projektphase infoteam als Softwaredienstleister unterstützt seine Kunden bei Verifikations- und Validierungsaufgaben und bietet das notwendige Know-how bei der Nutzung verschiedener Testwerkzeuge, sodass die Erfüllung von Sicherheitsanforderungen effizient nachgewiesen werden kann. SPS/IPC/Drives: Halle 7A Stand 130