ISO 26262: Konfigurierbare und kalibrierbare Software - Chance oder Risiko?


Embedded Systeme, die konfigurierbare Software enthalten, bieten einige spannende Herausforderungen, die es in der Praxis zu meistern gilt. Dieser Beitrag beschreibt Anforderungen der Norm ISO 26262 mit Fokus auf den Anhang C, welcher sich mit dieser Kernthematik beschäftigt: Konfigurierbare Software.

Vorab zu sagen ist, dass die Verwendung von Kalibrierdaten in konfigurierbaren Systemen grundsätzlich nur Vorteile hat. Denn durch die einfache und schnelle Änderung dieser Daten kann das funktionale Verhalten des Gesamtsystems zu dem jeweils gewünschten Verhalten verändert werden, ohne den Source Code bzw. dessen Struktur anpassen zu müssen. Dadurch kann der Source Code mehrfach wiederverwendet werden. Teilweise besteht diese Möglichkeit dann sogar bei den Unit Tests inklusive der Nachweise für die strukturelle Source Coverage. Es handelt sich also um wichtige und vor allem zeitsparende Faktoren für den Projektverantwortlichen.

Was sind eigentlich die Besonderheiten der ISO 26262?

Zunächst unterscheidet die Norm zwischen Kalibrier- und Konfigurationsdaten.

Kalibrierdaten werden als „Data that will be applied after the software build in the development process“ (also „Nach Einbau der Software in den Entwicklungsprozess angewandte Daten.“) definiert. Unter anderem werden hierfür fahrzeugspezifische Parameter als Beispiel genannt. Konfigurationsdaten sind im Sinne der Norm „Data that is assigned during software build and that controls the software build process“ (also „Während der Softwareentwicklung zugeordnete und dessen Prozess kontrollierende Daten“). Beispielhaft dafür sind Pre-Prozessor Instruktionen. Nach diesen und weiteren Begriffsbestimmungen und -erklärungen, stoßen wir auf den für diesen Artikel relevanten Anhang C der ISO 26262-6 [Software]. Dieser definiert folgendes Vorgehen:

C.4.5 sagt aus, dass eine Kombination aus folgenden Maßnahmen die vollständige Verifikation einer konfigurierbaren Software nachweisen kann:

a) Verifikation der konfigurierbaren Software

b) Verifikation der Konfigurationsdaten

c) Verifikation der konfigurierten Software

Allerdings wird später in der Norm darauf hingewiesen, dass eine vollständige Verifikation nur durch die Kombinationen a) b) oder b) c) nachgewiesen werden kann.

Der nächsten Abschnitt, C.4.6, gibt an, was beim Spezifizieren der Kalibrierdaten berücksichtigt werden muss. Folgende Punkte werden dabei aufgeführt:

  • gültige Werte

  • beabsichtigte Nutzung

  • Datenbereiche

  • Skalierung und Einheiten der Daten

  • gegenseitige Abhängigkeiten einzelner Daten

Abschließend fordert C.4.7 bei der Verifikation den Nachweis über die Benutzung der Kalibrierdaten im definierten Datenbereich.

Die Norm sagt also aus, dass eine konfigurierte Software prinzipiell noch keine Kalibrierdaten enthält. Dies macht in dem Punkt C.4.5 angesprochenen Vorgehen aus meiner Sicht jedoch keinen Sinn, da man hier die Kalibrierdaten mit einschließen müsste. Über die Verifikation einer Software, welche Kalibrierdaten enthält, sagt die Norm leider nur sehr wenig aus.

Was erfahren wir aus der Praxis?

An den funktionalen Requirements solcher Systeme erkennt man sofort die Schwierigkeit oder sogar Unmöglichkeit, sie auch nur annähernd zu 100 Prozent zu verifizieren. Ihre Komplexität erhält die Verifikation aber nicht nur durch die Vielzahl und Varianz der Kalibrierdaten, sondern auch durch die sich daraus ergebenden unterschiedlichen Verhaltensweisen.

Die Verifikation der kalibrierbaren Software und die Validierung/Verifikation der Kalibrierdaten (wie in C.4.5 der Norm festgelegt) ist dennoch der erste richtige Schritt. Um ein ausreichendes Testergebnis zu erhalten, muss die Verifikation der kalibrierbaren Software sowohl aus Tests, als auch aus Begründungen (Äquivalenzklassen) bestehen. Voraussetzung zum Gelingen dieser Vorgehensweise sind gute Requirements und eine detaillierte Software Architektur. Der große Vorteil liegt bei dieser Herangehensweise darin, dass man die Verifikation dadurch allgemeingültig machen kann. Das heißt, dass unabhängig davon, welcher konkrete Satz von Kalibrierdaten zur Anwendung kommt, die Verifikation nicht geändert werden muss. Bei der in der Norm angegebenen Alternative (Verifikation der Konfigurations- bzw. Kalibrierdaten, sowie die Verifikation der konfigurierten/kalibrierten Software) wird nur genau ein Satz von Kalibrierdaten getestet. Somit ist sie zwar deutlich einfacher durchzuführen, aber ist auch nur für diesen einen ausgewählten Datensatz gültig.

Alles in allem kommen die oben genannten Vorteile einer konfigurierbaren oder kalibrierbaren Software also nur dann voll zur Geltung, wenn es gelingt, die Verifikation allgemeingültig zu machen. Auch bei Projekten mit höchsten Sicherheitsanforderungen wird diese Vorgehensweise erfolgreich angewandt.

#ISO26262 #KonfigurierbareSoftware #KalibrierbareSoftware #EmbeddedSysteme

Kontakt: 0431 - 888 2111 0

E-Mail: marketing@scope-engineering.de

  • YouTube
  • Twitter
  • XING
  • LinkedIn

© 2020 SCOPE Engineering GmbH

Impressum

Datenschutz

Kontakt

SCOPE Engineering Website       I       test!t     I     t(ea)talk     I     Dezentrales Arbeiten