Du bist hier: / FuSI

Schlagwortarchiv für: FuSI

Compiler für sicherheitsrelevante Software – Was ist zu tun?

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

/0 Kommentare/von

Rückwirkungsfreiheit – Die gelebte Praxis!

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

/0 Kommentare/von

Guter Safety Software Entwicklungsprozess – Was ist das?

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

/0 Kommentare/von

Wichtigkeit der Toolqualifikation in der FuSi (Teil2)!

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

/2 Kommentare/von

Wieviele Requirements Ebenen sind sinnvoll?

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

/1 Kommentar/von

Fault Injection Test in ISO 26262 – Braucht man den wirklich?

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

/2 Kommentare/von

Funktionale Sicherheit – Was ist das?

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

/1 Kommentar/von

Kontakt

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

IMPRESSUM  |  DATENSCHUTZ