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
Schlagwortarchiv für: RTCA DO178
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
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
Funktionale Sicherheit : In den letzten Jahren hat in viele Entwicklungsabteilungen der Begriff Funktionale Sicherheit Einzug gehalten. Dies geht einher mit der zunehmenden Verbreitung von elektronischen Systemen.
Für mechanische Geräte und Systeme gibt es Jahrzehnte an Erfahrungen, wie diese zu konstruieren und zu bauen sind, damit von Ihnen und Ihrer Funktion keine Gefahren für den Benutzer und dessen Umwelt ausgehen. Es gibt z.B. Vorschriften, welche mechanischen Schutzeinrichtungen angebracht werden müssen, damit ein Bediener einer Säge nicht mit den Fingern in das Sägeblatt gelangen kann. Weiterlesen
