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: EN50128
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 Durchführung einer Daten- und Kontrollflussanalyse wird in fast allen funktionalen Sicherheitsstandards gefordert. Im Vergleich zu anderen Methoden und Maßnahmen, fristet die Daten- und Kontrollflussanalyse aber eher ein Schattendasein. Der Grund liegt vor allem auch darin, dass bisher die technologischen Fähigkeiten zur Durchführung einer solchen Analyse gefehlt haben.
Die non-intrusive Systembeobachtungstechnologie der Firma Accemic (www.accemic.de) bietet nun die Möglichkeit die Daten- und Kontrollflüsse durch Tests nachzuweisen. Dadurch wiederum wird es möglich die funktionale Vollständigkeit der Requirements systematisch zu überprüfen. Weiterlesen
Die Messung der strukturellen Source Code Coverage ist heutzutage in vielen Funktionalen Sicherheitsstandards als ein wichtiges Verfahren definiert. Die Non-intrusive Messung der strukturellen Coverage bietet hier zukünftig ganz neue Möglichkeiten. Lange Zeit war es industrieweiter Konsense dass die strukturelle Coverage nur in sogenannten White-Box-Tests ermittelt werden sollte und konnte. In vielen Lehrbüchern wird die Messung der strukturellen Source Code Coverage sogar als eigenständige Testmethode angepriesen. Im nachfolgenden Blogbeitrag wird aufgezeigt, warum sich hier zukünftig einiges ändern dürfte. Weiterlesen
Der Compiler ist DAS zentrales „Tool“, welches man in jeden Software Produktentwicklung benötigt. Er bildet das Bindeglied zwischen der vom Menschen gut lesbaren Hochsprache (z.B. C und C++) und dem für den Hardwareprozessor interpretierbaren Maschinencode. Für die Entwicklung sicherheitsrelevanter Software nach entsprechenden Funktionalen Sicherheitsstandards wie ISO26262 (Auto), EN50128 (Bahn), IEC61508 (Automatisierung, Allgemein) oder DO178C (Luftfahrt) gelten für die während der Entwicklung verwendete Tools besondere Anforderungen (siehe Blogbeiträge zur Toolqualifikation aus 2016: Blog 1; Blog 2). Der Compiler spielt hier eine Sonderrolle. Einerseits ist er das zentrale Tool jeder Entwicklung, andererseits sind die in den Normen vorgeschlagenen Maßnahmen in der Praxis für Ihn nur bedingt anwendbar. Der Blog zeigt einen Prozess aus der Luftfahrt für die Compilerverifikation/-validation auf, der auch für andere Industrien sehr zu empfehlen ist. Weiterlesen
Im letzten Blogbeitrag (Juni 2017) habe ich das Prinzip der Rückwirkungsfreiheit erklärt. Das verwendete Beispiel bezog sich dabei auf die Automobilbranche und die ISO26262.
Nun möchte ich das Thema branchenübergreifend (Bahn, Luftfahrt, Automobil) betrachten und meine Erfahrungen aus der Projektpraxis mit Ihnen teilen. Weiterlesen
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
IEC 61508, ISO26262, DO 178C, ISO 25119: Sind Ihnen diese Kürzel schon mal in Ihrem beruflichen Alltag begegnet? Falls ja, dann ist die Wahrscheinlichkeit hoch, dass Sie Funktionale Sicherheitsprojekte bereits in Ihrem Unternehmen durchführen oder dass Sie in näherer Zukunft in diesen Markt einsteigen werden.
Vielleicht haben Sie auch schon selbst die Erfahrung gemacht, bzw. zumindest davon gehört, dass insbesondere Software Projekte im Umfeld der Funktionalen Sicherheit nur mit sehr hohem Dokumentations- / Testaufwand durchführbar sind. Noch dazu sind solche Projekte sehr starr, ineffizient und unflexibel.
Kommt Ihnen eine solche Argumentation oder Erfahrung bekannt vor?
Insbesondere für Sie, aber auch für alle Anderen, möchte ich in diesem Blog aufzeigen das dies nicht so sein muss. Im Gegenteil, ich möchte Sie ermuntern dass Sie sinnlose Dinge aus Ihrem Entwicklungsprozess streichen und dafür eine für in sich schlüssige, auf Ingenieursprinzipien beruhende Vorgehensweise wählen. Weiterlesen
Die Wichtigkeit der Toolqualifikation habe ich im ersten Teil (Link) grundsätzlich erklärt. Ebenso habe ich bereits einen Überblick über die 4 am häufigsten angewendeten Maßnahmen gegeben.
In diesem Beitrag möchte ich nun jede dieser 4 Maßnahmen genauer vorstellen und die jeweiligen Vor- und Nachteile benennen. Weiterlesen
