Strukturelle Source Code Überdeckung: Sie arbeiten in Software Projekten in denen das Thema Funktionale Sicherheit immer wichtiger wird? Die Anwendung von IEC 61508, ISO 26262 oder einer vergleichbaren Norm steht vor der Tür oder Sie befinden sich bereits mitten in so einem Projekt? In diesen Fällen ist Ihnen vermutlich der Begriff Strukturelle Source Code Coverage auch schon begegnet. Viele setzen die Erreichung der strukturellen Coverage oft gleich mit sehr hohem Testaufwand und sie bezweifeln, ob bei diesem Thema Kosten und Nutzen in einem angemessenen Verhältnis stehen. Weiterlesen
Schlagwortarchiv für: EN50657
Requirement- und Test Traceability: Standen Sie auch schon mal vor folgender Situation: Ihr sicherheitsgerichtetes Projekt steht kurz vor dem Abschluss, und Sie haben nahezu alle Teilprodukte untereinander in Beziehung gesetzt („verlinkt“). Es wurde erheblicher Aufwand in die Traceability gesteckt!
In einem Audit (z.B. interne QS, Kunde, Behörde) sollen Sie aufzeigen, welche Software Requirements sich aus welchen System Requirements herleiten. Jedes Software Requirement ist auf eines oder mehrere System Requirements verlinkt und auch jedes System Requirement ist auf ein oder mehrere Software- oder Hardware Requirements verlinkt. Weiterlesen
Das Kapitel 6.7 der EN 50128 und EN 50657 Unterstützende Werkzeuge und Sprachen definiert Anforderungen an Software Werkzeuge, welche in einem Sicherheits-relevanten Entwicklungsprozess eingesetzt werden. Projektmitarbeiter in Sicherheitsprojekten diskutieren immer wieder den Inhalt und die Bedeutung dieses Kapitels. Der nachfolgende Beitrag fasst die wesentlichen Anforderungen zusammen und leitet eine Praxisleitfaden für die Anwendung im Projekt ab. Was die EN 50128 und EN 50657 Unterstützende Werkzeuge nennt, wird oft auch als Tool Qualifikation bezeichnet.
Weitere Blogbeiträge zu verwandten Themen sind:
Die 100%ige strukturelle Source Code Überdeckung wird ja inzwischen von fast allen Normen (IEC61508, ISO26262, DO 178C etc.) der Funktionalen Sicherheit eindeutig gefordert. Unterschieden wird in den einzelnen SIL/ASIL Leveln nur noch die Art der Source Code Coverage. Weiterlesen
In meinen täglichen Projekten in der Automobilbranche und der Automatisierungstechnik treffe ich immer wieder auf die Frage, wie viele Requirement Ebenen denn nun geschrieben werden müssen. Das ist eine spannende Frage, insbesondere wenn man viel Erfahrung mit Luftfahrtprojekten hat.
Daher möchte ich in diesem Blogbeitrag dieses Thema einmal etwas näher beleuchten. Zunächst möchte ich die Vorgaben der FuSi-Standards IEC 61508, ISO 26262 und DO 178B/C vergleichen. Abschließend gebe ich noch Projekterfahrungshinweise, die auf meiner mehr als 15 jährigen Erfahrung beruhen.
Aus meiner Sicht unterteilt sich eine gute Software Spezifikation in zwei wesentliche Teile: Architektur/Design und textuelle Requirements.
Die Architektur beschreibt, meist überwiegend in grafischer Form, die Struktur und den Aufbau der Software. Insbesondere werden auch Daten- und Kontrollflüsse dargestellt. Der Schwerpunkt von textuellen Requirements wiederum liegt auf der Beschreibung der Funktionalität, sowie den zeitlichen Anforderungen an das System.
Die Ausgangsfrage dieses Blogs bezieht sich auf die Anzahl der Ebenen von textuellen Requirements. Nicht mitgezählt wird hier die Ebene der System-Requirements, welche immer vorhanden sein muss.
Weiterlesen
