Du bist hier: / Verifikation

Schlagwortarchiv für: Verifikation

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

Strukturelle Source Code Überdeckung auf dem Target!

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

/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

Implizites Testen – Eine gute Idee (Teil 2)?

Im ersten Teil des Blogs habe ich den Begriff „Implizites Testen“ definiert und Ursachen dafür diskutiert.
Im zweiten Teil geht es nun um die Nachteile solcher Tests und um Lösungsansätze um möglichst diese Nachteile gar nicht erst entstehen zu lassen. Weiterlesen

/0 Kommentare/von

Implizites Testen – Eine gute Idee (Teil 1)?

In größeren sicherheitskritischen Projekten begegnet mir immer wieder mal der Ausspruch: „Naja, das Requirement A wird mit dem Test XY indirekt oder implizit nachgewiesen!“. Ist Ihnen das auch schon mal passiert? Haben Sie auch schon mal erlebt, was in späten Projektphasen passieren kann, wenn man viele Requirements indirekt getestet hat?
Der Blog definiert im Teil 1 den Begriff und er beleuchtet die Ursachen von Impliziten Testen. Weiterlesen

/1 Kommentar/von

ISO 26262 kalibrierbare Software

ISO 26262 kalibrierbare Software: Der Anhang C der ISO 26262 beschäftigt sich mit konfigurierbarer Software. Dieser Blog fasst wichtige Anforderungen der Norm an Konfigurierbare/kalibrierbare Software nach ISO26262 zusammen und zeigt praxisrelevante Herausforderungen von Software-konfigurierbaren Embedded Systemen auf.

Zunächst einmal bietet die Verwendung von Kalibrierdaten in konfigurierbaren Systemen nur Vorteile. Das funktionale Verhalten des Gesamtsystems, kann durch einfache und schnelle Änderungen in den Kalibrierdaten an das jeweils gewünschte Verhalten angepasst werden, ohne das der Source Code, bzw. dessen Struktur angepasst werden müssen. Dadurch wird eine mehrfache Wiederverwendung des Source Codes ermöglicht. Wenn es gut gemacht ist, sollten sogar die Unit Tests inklusive des Nachweises der strukturellen Source Coverage weitgehend wiederverwendbar sein. Dies sind durchaus gewichtige Vorteile. Weiterlesen

/0 Kommentare/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

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