Hallo,
die Software Verifizierung und auch Validierung ist nur ein Teilprozess bei der Erstellung von Sicherheitsfunktionen, das ist erst mal sehr wichtig. Der Aufbau, Komponenten, Werkzeuge und Komplexität sind entscheidend über die Vorgehensweise.
Um diesen Teilprozess ausführen zu können muss die aus der
Risikobeurteilung kommende Anforderung der Sicherheitsfunktion vorhanden sein.
Also muss die Sicherheitsfunktion identifiziert und die Anforderungen definiert werden.
Dann muss man den PLr definieren und sucht dann die entsprechende Struktur, Kategorie, überlegt und dokumentiert wie man die Anforderungen der Kategorie einhalten kann, auch an den Teil 2 der 13849 denken.
Jetzt müssen die weiteren Parameter überlegt angegangen werden, Werte wie PFHd, MTTFd, DC ermitteln. Bei entsprechendem PL und Kategorie ist besonders wichtig, was muss ich machen um einen bestimmten DC zu erreichen. Denn dies wird ja dann oft mit der Software gemacht. Der Programmierer muss das wissen, einer der von mir am häufigsten vorgefundenen Fehler.
Die Externen Fehler müssen beherrscht werden, dies wird auch bei der Softwareerstellung verlangt, kann man aber auch hierbei schon betrachten und macht auch Sinn.
Eine Software kann keinen PL haben, hier geht es bei steigendem PL um Fehlervermeidung. Wie kann man dies machen, durch erhöhten Aufwand bei den Prüfungen und Dokumentation.
Wenn das alles Mal überlegt ist muss man die Softwarespezifikation erstellen. Bei einfachen Sicherheitsfunktionen kann man dies schon mit der Identifikation und Anwendungsdokumentation erstellen. Da können auch schon die Hardware Struktur E/A Ebene mit eingebaut werden.
Jetzt ist die Auswahl der Softwarewerkezeuge und ob man Zertifizierte Funktionen verwenden kann sehr wichtig welchen Umfang das ganze annehmen muss.
Bei einem Softwarewerkzeug welches umfangreiche Fehler zu lässt und bei dem man nicht nach Norm geführt wird werden jetzt Datenflussdiagramme und umfangreiche Dokumentationen gefordert. Bei einem System welches einfaches Nachvollziehen der Sicherheitsfunktionen zulässt kann man dies sehr einfach mit einem Ausdruck durchführen, wichtig ist das die Sicherheitsfunktion mit allen Anforderungen erkennbar ist. Also unter alle Umständen Spagetticode vermeiden.
Keine eigenen Module immer zertifizierte Funktionen, Trennung von Safety und Nonsafety Code.
Dann erstellt man einen Validierungsplan, ein Teil davon ist die Softwarevalidierung. Hier werden auch gleich die Testszenarien erstellt.
Alles Dokumentieren, dann hat es der Validierer einfacher, am besten hat sich nach meinen Erfahrungen dann ein Vieraugenprinzip bewährt. Der Ersteller erklärt anhand der Dokumentation die einzelnen Sicherheitsfunktionen.
Funktionstest sind dann auch der reale Nachweise dass die Anforderungen erfüllt sind, falls da Änderungen notwendig sind muss man an den entsprechenden Punkt zurück springen.
E/A Test wie man das von „Standard Anwendungen“ kennt sind natürlich immer notwendig.
Aber natürlich mit entsprechender Vorsicht!
Bei der Software wird man zunächst bei offenen System Testen ob es auch funktioniert dann zur Validierungsabschluss eine Blackbox Test.
Auch hier ist entscheiden wie komplex das System und/oder die Sicherheitsfunktion ist.
ACHTUNG KÖNNTE ALS WERBUNG VERSTANDEN WERDEN!!!!!!!!!!!
Zur PNOZmulti, auch hier muss man verifizieren und validieren, aber es handelt sich um ein System das einem führt und eine einfache Validierung zulässt. Vollgraphische Programmierung einfaches Nachvollziehen der Datenstruktur durch verfolgen der Verbindungslinien und Verwendung von zertifizierten Funktionsbausteine die man nur noch Parametrisieren muss. Bewerten wie sich die Logikelemente verhalten. Aber dazu gehört auch eine Erklärung der Funktionen, die auf der Anforderung beruht.
Wenn man durchgängig zertifizierte Komponenten einsetzen kann wird das dann nochmal einfacher. Geh aber nicht immer.
Bin zurzeit mit Kollegen damit beschäftigt zu diesem Thema eine Vorgehensweise bei der PNOZmulti zu erstellen dies wird dann 2014 in vielen Vorträgen in ganz Deutschland präsentiert.
