Deutsche BlogsISO26262

ISO 26262: konfigurierbare/kalibrierbare Software – Chance oder Risiko?

Der Anhang C der ISO 26262 beschäftigt sich mit konfigurierbarer Software. Dieser Blog fasst wichtige Anforderungen der Norm 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.

Anforderungen der ISO 26262-6:

Die Norm unterscheidet zunächst zwischen Kalibrierdaten und Konfigurationsdaten:
Kalibrierdaten: „Data that will be applied after the software build in the development process“
Als Beispiele werden fahrzeugspezifische Parameter genannt.
Konfigurationsdaten: „Data that is assigned during software build and that controls the software build process“ z.B. Pre-Prozessor Instruktionen.
Der Anhang C der ISO 26262-6 [Software] definiert folgendes Vorgehen:
C.4.6: Die Spezifikation der Kalibrierdaten muss folgende Punkte berücksichtigen:

  • gültige Werte
  • die beabsichtigte Nutzung
  • die Datenbereiche
  • die Skalierung und die Einheiten der Daten
  • sowie die gegenseitigen Abhängigkeiten einzelner Daten

C.4.7: Die Verifikation muss die Benutzung der Kalibierdaten im definierten Datenbereich nachweisen.
C.4.5: sagt aus, dass eine Kombination aus folgenden Maßnahmen die vollständige Verifikation einer konfigurierbaren Software nachweisen kann:

  1. Verifikation der konfigurierbaren Software
  2. Verifikation der Konfigurationsdaten
  3. Verifikation der konfigurierten Software

Im Weiteren wird in der Norm aufgeführt, dass die Kombination von 1. und 2. eine vollständige Verifikation darstellt.
Alternativ kann nur eine Kombination von 2. und 3. durchgeführt werden.
Anmerkung: Der Norm sagt aus, dass eine konfigurierte Software noch nicht die Kalibrierdaten enthält. Aus meiner Sicht, macht aber das in Punkt C.4.5 angesprochene Vorgehen nur Sinn, wenn man die Kalibrierdaten mit einschließt. Bezüglich der Verifikation einer Software welche Kalibrierdaten enthält, sagt die Norm nur sehr wenig aus.

Erfahrungen aus der Praxis:

Die Komplexität der Verifikation steckt in der Vielzahl und der Varianz der Kalibrierdaten, sowie der sich daraus ergebenden variantenreichen, unterschiedlichen funktionalen Verhaltensweisen.

An funktionalen Requirements solcher Systeme erkennt man sofort, dass es aufgrund der Vielzahl der Kalibriermöglichkeiten nicht möglich ist, die Requirements auch nur annähernd 100% zu verifizieren.
Die Verifikation der kalibrierbaren Software und die Validierung/Verifikation der Kalibrierdaten (wie in C4.5 der Norm festgelegt) ist der erste richtige Schritt. Allerdings muss die Verifikation der kalibrierbaren Software aus Tests und aus Begründungen (Äquivalenzklassen) bestehen, dass diese Tests ausreichend sind. Ideal geeignet für die Begründung ist die Software Architektur. Voraussetzung zum Gelingen dieser Vorgehensweise, sind gute Requirements und eine detaillierte Architektur. Der große Vorteil liegt darin, dass man damit die Verifikation allgemeingültig machen kann, d.h. egal welcher konkrete Satz von Kalibrierdaten zur Anwendung kommt, die Verifikation gilt und muss nicht geändert werden!
Die in der Norm angegebene Alternative (eine Verifikation der Konfigurations- bzw. Kalibrierdaten, sowie die Verifikation der konfigurierten/kalibrierten Software) ist in ihrer Durchführung sicher deutlich einfacher, da nur genau ein Satz von Kalibrierdaten getestet wird. Der große Nachteil hierbei ist, dass die Verifikation auch nur für diesen einen ausgewählten Satz von Daten gilt.

Fazit:

Die Vorteile einer konfigurierbaren/kalibrierbaren Software kommen dann voll zur Geltung, wenn es gelingt die Verifikation allgemeingültig zu machen, d.h. unabhängig von den individuellen Kalibrierdaten. Bis 2015 habe ich ein Projekt mit höchsten Sicherheitsanforderungen begleitet, bei dem diese Vorgehensweise (auf meine Initiative hin) erfolgreich zur Anwendung kam.
Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: martin.heininger[at]heicon-ulm.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

This site uses Akismet to reduce spam. Learn how your comment data is processed.