Softwareentwicklung nach ISO 26262

Die Softwareentwicklung nach ISO 26262 Teil 6 ist nach dem V-Modell orientiert (s. ISO 26262 Teil 6, Bild 2). Insofern ist das Thema Agile schnell erledigt. Agile Methoden sind in der Funktionalen Sicherheit generell ungeeignet, da deren Kerngedanke den normativen Anforderungen widerspricht. Meine Ausführungen zu agiler Entwicklung sind auf den Seiten zur Grundsicherheitsnorm (IEC 61508 Teil 3) enthalten. Im Wesentlichen sind die Spezifikation der Software-Sicherheitsanforderungen (SW-S-Req), die Softwarearchitektur, das Software-Unit-Design und deren Implementierung sowie das Testen und die Integration der Software als Phasen zu nennen. Analog zu Teil 5 ist auch eine Verifikation der SW-S-Req durchzuführen.

Planung der Softwareentwicklung nach ISO 26262

Im Rahmen der heutigen Entwicklungsumgebungen ist es normativ gefordert, die Design- und Codingguidelines für Modellierungssprachen und Programmiersprachen heranzuziehen und anzuwenden. Gleichzeitig ist es ratsam sich bereits auf Systemebene mit dem Thema Toolchain und Qualificationkits zu beschäftigen. Oft findet sich auf Softwareebene ein eingekauftes Real-Time-OS (RTOS). Dabei ist bei der Wahl des RTOS auf eine Zertifizierung nach IEC 61508 oder ISO 26262 zu achten. Berücksichtigen Sie bei ASIL D auch die Fähigkeit einer formalen Nachweisführung in der Modellierungssprache, wenn Sie modellbasiert Entwickeln. Stimmen Sie bei der Planung die Methoden, Programmiersprachen und Werkzeuge auf Ihr Vorgehen, Ihre Prozesse und den normativen Randbedingungen frühzeitig ab. Syntax, Abstraktionsfähigkeit, Modularität, strukturierter Aufbau müssen berücksichtigt werden. Ebenso sollte jeden Beteiligten in der Entwicklung klar sein, womit er arbeitet und wie geplant vorgegangen werden soll.

Die folgenden Phasen im V-Modell für die Softwareentwicklung nach ISO 26262 sind zu planen:

• Die SW-Sicherheitsanforderungsspezifikation und dessen Verifikation
• Der Entwurf der Software Architektur und des Designs
• SW-Unit-Design und deren Implementierung
• Die Tests der SW-Units
• Die Integration und die Integrationstests

Spezifikation von SW-Sicherheitsanforderungen nach ISO 26262

Bei der Spezifikation von Software-Sicherheitsanforderungen ist die Traceability – die Vor- und Rückverfolgbarkeit – ein wichtiges Merkmal. Leiten Sie von der Systemebene insbesondere aus dem TSC die Anforderungen ab. Es fallen i.d.R. keine Anforderungen aus dem Nichts in die Spezifikation.

Die Software-Sicherheitsanforderungsspezifikation sollte folgende Aspekte berücksichtigen:

• die Spezifikation mit dem Management von Sicherheitsanforderungen nach ISO 26262 Teil 8-6
• die Spezifikation der System- und Hardwareebene (z.B. Taktteiler, PI-Regelparameter usw…)
• die Hardware-Software-Interface-Spezifikation (HSI)
• ggf. spezielle Hardwaredesignspezifikationen
• Zeitvorgaben der Systemebene, welche Ausführungszeit und Reaktionszeit betreffen (Scheduler vs. FTTI)
• externe Interfaces (HMI/UI, COM)
• alle Betriebszustände (inkl. Ausfall und Initialisierung) des Fahrzeugs, des Systems und Hardware, welche die Software beeinflussen

Weiterhin sind zur Sicherheitsintegrität eine Reihe an Funktionen zu spezifizieren:

• zum Erreichen und Erhalt des sicheren Zustandes
• zur Detektion, Indikation und Fehlerhandling von sicherheitsrelevanten Hardware-Elementen
• zur Selbstkontrolle des RTOS sowie applikationsspezifisch zur Vermeidung und Beherrschung systematischer Fehler
• für Onboard und Offboard Tests
• welche in Leistungs- oder zeitkritischen Zuständen ausgeführt werden
• zur Modifikation der Software im Sicherheitslebenszyklus nach der Entwicklung

Verifikation der SW-Sicherheitsanforderungsspezifikation

Die Planung der Verifikation der Software-Sicherheitsanforderungen sowie HSI sollte in einem interdisziplinären Team erfolgen. Die Verifikation selbst sollte nach ISO 26262 Teil 8-6 und 8-9 erfolgen. Ziel ist Konsistenz zwischen den System- und Software-Sicherheitsanforderungen zu erhalten. Weiterhin ist das Systemdesign und das HSI gegen die SW-Sicherheitsanforderungspezifikation zu verifizieren.

Die eigentliche Verifikation nach ISO 26262 Teil 6-11 findet nach der vollständigen Integration der Software zur embedded Software in der Zielumgebung statt. Dabei sind Testmethoden nach ISO 26262 Teil 6-11, Tabelle 16 auszuwählen. I.d.R. ist ein Fahrzeugtest durchzuführen. Dabei können bereits die Testfälle aus der HW-SW-Integrationsphase auch im Fahrzeugtest verwendet werden. Pass-Fail-Kriterien sind wesentliches Merkmal der Verifikationsplanung.

Entwurf der Softwarearchitektur nach ISO 26262

Die Softwarearchitektur bzw. das Software-Architekturdesign stellt alle Software-Elemente in einer hierarchischen Struktur dar. Diese Darstellung bildet die Grundlage zur Bechreibung der Interaktion dieser SW-Elemente. Dazu sind statische und dynamische Aspekte zu Beschreiben. Dafür bieten sich Modellierungssprachen wie UML oder SysML an, welche auch die mit steigendem ASIL normativ geforderte Semi-Formale-Notation unterstützen. Weiterhin bieten diese Darstellungssprachen auch ganzheitliche Betrachtungen unabhängig von der Ebene (Intersystem-, Intrasystem-, Inter-Modulinteraktion) und physikalischen Struktur (z.B. Steuegeräte). Komplexe Funktionen, welche über mehrere Steuergeräte verteilt ausgeführt werden, sind dann auch als vollständige Architektur leicht erfassbar und damit analysierbar (z.B. verteilte und temporäre Redundanzen).

Achten Sie bereits im Entwurf der SW-Architektur und deren Untereinheiten (SW-Units) auf Granularität, Modularität und Einfachheit. Ziel ist es, die Verifikationsfähigkeit durch Nachverfolgbarkeit der SW-Sicherheitsanforderungen bis zum Code zu gewährleisten. Konfigurierbarkeit, Wartungsfreundlichkeit und Testbarkeit sind weitere Merkmale, welche zu erfüllen sind. Statische Design-Aspekte wie die Datentypen, externe Interfaces oder logische Abfolgen müssen beschrieben sein. Auch dynamische Design-Aspekte wie die Datenflusskontrolle oder die Konkurrenz der Prozesse sowie zeitliche Beschränkungen (z.B. Time-slice, Interrupts & Timeout) müssen weiter detailliert werden. Auch Inter-task-Kommunikation (z.B. Semaphoren) sind zu beschreiben.

Wechselwirkungsfreiheit

Haben Sie z.B. ein Steuergerät mit verschiedenen sicherheitskritischen SW-Elementen mit unterschiedlichen ASIL, sogenannte Mixed-ASIL-Architekturen, so müssen Sie über ein intelligentes Sicherheitskonzept die Wechselwirkungs- bzw. die Rückwirkungsfreiheit (Freedom from Interference) gewährleisten. Dies ist besonders bei AUTOSAR-Plattformen oder Multi-Core-Umgebungen noch eine Herausforderung. Es ist möglich mit Partitionen zu arbeiten, dessen Implementierung jedoch nach dem höchsten ASIL erfolgen muss (s. ISO 26262 Teil 6, Annex D). Es müssen z.B. Speicherbereiche abgesichert sein und der Programmfluss wechselwirkungsfrei gewährleistet sein. Dabei kann es besonders bei gemeinsam verwendeten Ressourcen (z.B. E/A bzw. I/O) zu Kopplungseffekten kommen.

SW-Elemente & Konformitätspfade nach ISO 26262

Sie werden sicherlich nicht alles neu erfinden. Technologien von µC, DSPs und FPGAs und Kommunikationsprotokolle haben sich stark verändert. Dies zeigt sich mehr und mehr in den SW-Architekturen. Es sind mehr Hardware-Sicherheitsmechnismen zu konfigurieren und weniger große Sicherheitsbibliotheken einzubinden. Sicherheitsrelevante Kommunikationsstacks sind zertifiziert erhältlich. I.d.R. wird das RTOS und der Com-Stack bereits zertifiziert eingekauft. Die Qualifikation von Softwarekomponenten nach ISO 26262 Teil 8-12 ist aufwendig und muss für einige dieser SW-Elemente durchgeführt werden.

Jedes SW-Element muss einen der drei Konformitätspfade zugeordnet sein:

• neu entwickelt
• wiederverwendet mit Modifikation
• wiederverwendet ohne Modifikation

Auswirkungen der Dekomposition auf die Softwareentwicklung nach ISO 26262

In dieser Phase zeigt sich die Qualität des technischen Sicherheitskonzepts (TSC) sehr deutlich. Eine zunehmende Dekompositionsaktivität verschiebt oft die Probleme in Richtung der Software. Folglich führt dies zu einen signifikaten Anstieg der SW-S-Req und zu einer verminderten Systemperformance. Nutzen Sie z.B. Hardware-Sicherheitsfunktionen oder Architekturen wie z.B. Lock-Step so haben Sie weniger Overhead für die Prozessabsicherung der sicherheitskritischen Funktionen. Auch hier ist Erfahrung von Vorteil.

Eine Analyse von abhängigen Fehlern nach Teil 9-7 ist notwendig, wenn Zweifel an einer Wechselwirkungsfreiheit bestehen bzw. eine SW-Sicherheitsanforderung die Unabhängigkeit fordert.

Nachdem nun die Softwarearchitektur beschrieben ist, muss ggf. eine Sicherheitsanalyse auf Softwarearchitekturlevel nach Teil 9-8 durchgeführt werden. Dabei kann es notwendig werden Sicherheitsmechanismen (SM) wie Range-Checks oder Plausibility-Checks zu spezifizieren. Weiterhin kann bei Forderung durch das TSC der Einsatz von diversitären SW-Elementen notwendig sein, z.B. eine SW-Unit, die mit Fließkommaarithmetik und eine die mit Festkommaarithmetik arbeitet. Auch Fehlerbehandlungsmechanismen für „Fail Operational“-Charakteristik wie ECC können als SM notwendig werden.

Nun ist noch eine Ressourcenabschätzung durchzuführen. Dazu sei insbesonders auf den Stack bzw. Flash verwiesen. Es bietet sich dazu ein Software in the Loop (SIL) Testverfahren an.

Verifikation der SW-Architektur

Nachdem nun die Software-Sicherheitsanforderungen und die Softwarearchitektur bis auf SW-Unit-Ebene heruntergebrochen beschrieben ist und das Design mittels Sicherheitsanalysen verifiziert wurde, sind nun Methoden zur Verifikation festzulegen und anzuwenden. Nach ISO 26262 Teil 8-9 wäre z.B. eine Kontroll- und Datenflussnalyse angebracht. Die Konsistenz der Architektur zu den Software-Sicherheitsanforderungen und der Zielhardware sowie die Einhaltung von Designrichtlinien sind zu prüfen.

Software-Unit-Design

Nachdem das Große und Ganze beschrieben wurde, sind nun die Moduln der Software, SW-Units nochmals iterativ in einem kleinem V-Modell jeweils zu entwickeln und zu implementieren.

Eine SW-Unit-Spezifikation, die Implementierung als Quellcode und eine statische Verifikation bilden die Kernaktivitäten dieser Ebene. Dabei soll die Spezifikation das funktionale Verhalten und das modul-interne Design beschreiben. In ISO 26262 Teil 6-8, Tabelle 8 sind Designprinzipien enthalten. Wenn Sie bereits in der Planphase z.B. den Coding-Standard MISRA C gewählt und in der Entwicklung auch angewandt haben, ist ein Großteil dieser Forderungen bereits abgedeckt.

Folgende Eigenschaften müssen die spezifizierten Moduln aufweisen:

• korrekter Aufruf von internen Funktionen und Unterprogrammen
• Interface-Konsistenz zwischen den Moduln
• Korrekter Daten- und Kontrollfluss zwischen den Moduln
• Einfachheit, Lesbarkeit, Nachvollziehbarkeit

Verifikation der SW-Moduln / SW-Units

Die Verifikation erfolgt nach ISO 26262 Teil 8-9 unter Auswahl der Methoden nach Teil 6-8, Tabelle 9. Ziel ist es, Konsistenz zwischne den Moduln und dem HSI sowie den Software-Sicherheitsanforderungen sicherzustellen. Dabei ist auch auf die Designspezifikation (z.B. Zähler für die Programmablaufkontrolle) und die Coding-Richtlinien beim Quellcode-Walkthrough zu achten. Weiterhin ist die Hardware-Kompatibilität zu prüfen.

Software-Unit Tests

Nach der Realisierung kommt der Test und die Integration. Ziel ist es, die Moduln auf ihre spezifizierten Funktionen hin zu testen und die Abwesenheit von unerwünschten Funktionalitäten sicherzustellen. Die Tests sind nach ISO 26262 Teil 8-9 zu testen. Dazu sind Testfall-Spezifikationsmethoden nach ISO 26262 Teil 6-9, Tabelle 11 wie z.B. Anforderungsanalyse, Äquivalenzklassenbildung, oder Fehlervorschlag durch Expertenempfehlung anzuwenden. Die Testmethoden sind nach ISO 26262 Teil 6-9, Tabelle 10 auszuwählen und anzuwenden wie z.B. anforderungsbasierter Test, Interfacetest und Fehlerinjektionstests.

Weiterhin ist aufzuzeigen, dass die Spezifikation zum HSI erfüllt ist. Die Robustheit der Moduln steht im Mittelpunkt. Damit ist die Abwesenheit von z.B. toten bzw. unereichbaren Code und die Effektivität von Fehlerbehandlungs- und Erkennungsmaßnahmen gemeint. Weiterhin sind auch Ressourcen-Tests erforderlich. Vollständige Testabdeckung (Metriken zur Codeüberdeckung der Testfälle) komplexer Architekturen kann nur mit statischen Analysewerkzeugen gesammelt werden. Dazu sind in ISO 26262 Teil 6-9 Tabelle 12 einige Metriken aufgeführt. Für ASIL C ist z.B. ein Branch Coverage angemessen. Die Test können als Stub im SIL bzw, hardwarenahe Units auf der Zielhardware (HIL) oder passenden und zertifizierten Emulator getestet werden. Auch eine Inspektionsmethode durch ausgewiesenen Experten kann für nicht abgedeckten Code angwandt werden.

Software-Integration und Test

Wenn die Moduln zu einer ganzen embedded Software zusammengesetzt werden, so wird die Softwarearchitektur vollständig umgesetzt sein. Diese Integration muss die funktionalen Abhängigkeiten und alle Integrationstufen mit dem initialen ASIL berücksichtigen. Der Test und Integrationsplan bildet das Kerndokument dieser Phase. Grob lassen sich zwei Integrationsphasen einteilen. Die SW-SW-Integration und die HW-SW-Integration. Die Methoden zur Integration sind in ISO 26262 Teil 6-10, Tabelle 13 enthalten. Dazu zählen i.d.R. Fault-Injection-Tests abgeleitet durch Analyse der Anforderungen. Auch Ressourcentests sind durchzuführen. Ziel aller Aktivitäten ist die Konsistenz der Anforderungen und des HSI mit der embedded Software nachzuweisen. Auch auf Architekturebene soll die strukturelle Codeüberdeckung durch Metriken nachgewiesen werden und unzureichende Abdeckung mit Begründung dokumentiert werden. Die Testumgebung ist i.d.R. die Zielumgebung.

Am Ende steht ein Integrations- und Freigabebericht, welcher in die Produktfreigabe nach ISO 26262 Teil 4-11 inkludiert werden muss. Es dürfen nur spezifizierte Funktionen enthalten sein, und wenn nicht spezifizierte Funktionen enthalten sind, so dürfen diese keinen Einfluss auf die Sicherheitsziele haben.

Verifikation der embedded Software

Es liegt eine vollständig integrierte embeddes Software im Zielsystem vor. Die Verifikation erfolgt nach dem Verifikationsplan, welcher zeitgleich mit der Software-Sicherheitsanforderungspezifikation erstellt wurde.