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
Das Buch „User Stories“ von Mike Cohn (ISBN 978-3-8266-5898-3) hat mich inspiriert, einmal mehr über den Bezug zwischen User Stories und Requirements nachzudenken. In der Software Entwicklung werden agile Methoden in den letzten Jahren oft bevorzugt eingesetzt. Die klassischen Vorgehensweisen, insbesondere das Wasserfallmodell und auch das V-Modell, scheinen etwas aus der „Mode“ zu kommen.
Konsequenter Weise werden damit User Stories gegenüber den „klassischen“ Requirements auch bevorzugt eingesetzt. Helfen die User Stories aber wirklich, bessere Software Qualität abzuliefern? Gibt es nicht auch viele Aspekte, bei denen es gar keine Unterschiede gibt? 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
Strukturelle Source Code Coverage: Wenn Sie neu in dem Bereich der Funktionalen Sicherheit tätig sind, dann werden Ihnen die Begriffe strukturelle Source Code Coverage und Requirements ziemlich schnell begegnen. Die Spezifikation von technischen Systemen mittels Requirements ist natürlich auch im nicht sicherheitskritischen Bereich sehr verbreitet. Dagegen spielt das Thema strukturelle Source Code Coverage außerhalb der Sicherheitstechnik praktisch keine Rolle.
In diesem Blog möchte ich mich mit diesen beiden Begriffen und den dahinter stehenden Prozesse beschäftigen. Insbesondere die Frage nach der gegenseitigen Abhängigkeit ist spannend. 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
Die ISO 26262 definiert als eine Test Methode jeweils auf System- Integrations- und Unit-Test Ebene den Fault Injection Test (ISO 26262-4 [System] Tabellen 5, 8, 10, 13, 15, 18; ISO 26262-5 [Hardware] Tabelle 11; ISO 26262-6 [Software] Tabellen 10, 13).
Diese Methode hat ganz sicher einen großen Anteil bei der Implementierung eines möglichst fehlerfreien und damit sicheren Systems. Mir geht es nachfolgend um eine möglichst effiziente Implementierung dieser Test Methode in der Praxis. Dabei möchte ich insbesondere die Vorgehensweisen in der Luftfahrt mit denen in der Automobilbranche vergleichen. Weiterlesen
Die Qualitätssicherung überprüft die Qualität des Produktes. Dies ist zunächst einmal eine geradezu triviale Feststellung. Je nach Definition des Begriffes „Produkt“ unterscheiden sich aber die Aufgaben deutlich. Geht es um die Überwachung eines Produktionsprozesses oder reden wir von der Sicherung der Qualität in einer Software und Elektronikentwicklung? Der nachfolgende Blog beschäftigt sich mit der Qualitätssicherung in der Entwicklung von Software und elektronischer Hardware. Es soll herausgearbeitet werden, wo der Unterschied bei der Qualitätssicherung von FuSi- und Nicht-FuSi-Projekten liegt. Weiterlesen
Im Beitrag Re-Use Szenarien in ISO 26262 (Teil 1) habe ich die Vielfalt von verschiedenen Re-Use Szenarien dargestellt. Im folgenden Beitrag gehe ich auf konkreten Maßnahmen ein, die den Re-Use von Software erfolgreich machen. Weiterlesen
Warum ist die Wiederverwendung von Software, Hardware oder kompletten Steuergeräten ein zentrales Thema? Zwei wesentliche Aspekte sind hier ausschlaggebend:
Die Entwicklungskosten können deutliche reduziert werden, d.h. die Wiederverwendung von Komponenten ist unter wirtschaftlichen Gesichtspunkten sehr attraktiv.
Aber auch aus Sicherheitsgründen, kann die Wiederverwendung von Komponenten deutliche Vorteile bieten. Ein Steuergerät, welches bereits seit Jahren im Feld eingesetzt wird und keine sicherheitsrelevanten Ausfälle zeigt, kann im Vergleich zu einer Neuentwicklung mit deutlich reduziertem Risiko eingesetzt werden.
Um aber diese Vorteile wirklich zur Geltung zu bringen, muss man sich der vielfältigen Re-Use-Szenarien insbesondere in der Automobilbranche bewusst sein. Als zweiten Schritt, muss man die Besonderheiten des zur Diskussion stehenden Wiederverwendungsszenarios identifizieren und entsprechende Maßnahmen ergreifen.
Der Blog teilt sich dabei in zwei Teile. Im ersten Teil geht es um Vielfalt möglicher Wiederverwendungsszenarien sowie die entsprechenden Anforderungen die sich aus der ISO 26262 ergeben. Im zweiten Teil des Blogs werden konkrete Maßnahmen für ausgewählte Re-Use-Szenarien diskutiert. Weiterlesen
HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi
Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60
Email: info[at]heicon-ulm.de
