Funktionale Sicherheit von Embedded Software Wie Continuous Compliance zum Wettbewerbsvorteil wird

Anbieter zum Thema

IAR Systems GmbH

MicroConsult Academy GmbH

emlix GmbH

CI/CD, reproduzierbare Builds und automatisierte Compliance-Workflows verändern die Embedded-Entwicklung grundlegend. Sie verkürzen Zertifizierungszeiten gemäß IEC- und ISO-Normen für funktionale Sicherheit, verbessern gleichzeitig die Softwarequalität und senken die Kosten durch Softwarefehler um 25%.

Das Muster ist bei allen Embedded-Entwicklungsteams egal welcher Branche immer wieder dasselbe: Zu Beginn eines Projekts geht alles schnell voran. Das Team ist klein, die Toolchain ist neu und die Builds sind vorhersehbar. Doch mit zunehmender Projektgröße arbeiten Entwickler an verschiedenen Standorten, an den Arbeitsplätzen werden verschiedene Tool-Versionen eingesetzt und gegen Ende des Entwicklungszyklus beginnt die Compliance-Arbeit: Dokumentationen werden nachträglich zusammengestellt, Nachweise rekonstruiert und die Zertifizierung gilt dann als letzte Hürde vor der Freigabe.

Dieser Ansatz ist nicht nur ineffizient, sondern vor allem in sicherheitskritischen Projekten strukturell anfällig. Teams, die davon abgerückt sind, sparen nicht nur Zeit – sie entwickeln zugleich zuverlässigere Produkte.

Die versteckten Kosten des Gate-Modells

Das Gate-Modell folgt einer nachvollziehbaren Logik: Zuerst wird das Produkt entwickelt und erst anschließend wird nachgewiesen, dass es den Normen entspricht. Das Problem ist jedoch, dass dieser Nachweis von einer stabilen und reproduzierbaren Entwicklungsumgebung abhängt.

Sind Builds nicht deterministisch, zum Beispiel weil unterschiedliche Compiler-Versionen, SDK-Konfigurationen oder Analyse-Einstellungen leicht unterschiedliche Ergebnisse erzeugen, dann sind die erzeugten Nachweise keine belastbaren Belege mehr, sondern lediglich nachträgliche Rekonstruktionen.

Es lohnt sich, die tatsächlichen Kosten nicht-deterministischer Builds genauer zu betrachten. So muss ein Jahr nach Markteinführung bei einem Fehler im Feldeinsatz häufig exakt die ausgelieferte Binärdatei rekonstruiert werden. Hat sich die Entwicklungsumgebung verändert, ist dies oft unmöglich. Versionsverwaltung allein reicht nicht aus, da dieselbe Codebasis mit einer leicht veränderten Toolchain andere Binärdateien erzeugt. Der Unterschied wird erst im entscheidenden Moment sichtbar.

Zertifizierungsstellen für IEC 61508, ISO 26262 und IEC 62304 wollen keine Annäherungen, sie erwarten vollständige Rückverfolgbarkeit. Identische Eingaben müssen über den gesamten Produktlebenszyklus hinweg identische Ergebnisse liefern, auch in Updates fünf oder zehn Jahre nach der Erstfreigabe.

Ist die Entwicklungsumgebung jedoch instabil, lässt sich diese Anforderung nur schwer erfüllen. Die folgenden Beispiele zeigen Bereiche, in denen Compliance-Anforderungen in einen modernen Embedded-Entwicklungsworkflow integriert sind.

Success Stories bei Embedded Systemen

Hier drei Beispiele aus der Praxis:

Ein globaler Hersteller von Aufzugs- und Hubsystemen expandierte rasch auf dem europäischen Markt und musste dabei immer strengere Anforderungen der IEC 61508 in neuen Zielmärkten erfüllen. Das bisherige Vorgehen mit manuellen Builds, Qualitätssicherung erst gegen Ende des Entwicklungszyklus und nachträglich erstellten Compliance-Nachweisen skalierte nicht mehr mit dem Wachstum des Unternehmens. Mit der Standardisierung auf eine zertifizierte Toolchain mit integrierter CI/CD-Unterstützung (Continuous Integration/Continuous Delivery/Deployment) und automatisierter statischer Codeanalyse wurden Compliance-Nachweise direkt in den regulären Entwicklungsprozess integriert. Das Ergebnis: Die Kosten für Fehler sanken um 25 Prozent, und die Zeitpläne für die Zertifizierung wurden planbar.

Ein führender Anbieter von industriellem Brand- und Gasdetektionssystemen stand vor einem ähnlichen Problem: Jede Softwarefreigabe machte eine vollständige Revalidierung der eingesetzten Tools erforderlich. Aufgrund der Vielzahl unterschiedlicher Anbieter, uneinheitlicher Tool-Versionen und räumlich getrennter Entwicklungsteams verbrachten die Programmierer mehr Zeit mit der Validierung ihrer Werkzeuge als mit der Entwicklung sichererer Produkte. Nach der Standardisierung der Toolchain über alle Teams hinweg und der direkten Integration der Analyse in die Build-Pipeline liefen die Analysen in der Linux-basierten CI/CD-Umgebung 3,5-mal schneller ab. Noch wichtiger war jedoch, dass Compliance nicht länger ein separater Schritt zwischen Entwicklung und Freigabe war. Sie wurde zu einem kontinuierlichen Bestandteil jedes einzelnen Builds.

Ein Medizintechnikunternehmen, das tragbare Geräte zur Herzüberwachung entwickelt, wollte CI/CD-Workflows einführen und seine Testprozesse automatisieren. Gleichzeitig musste jedoch jede Änderung die Anforderungen der FDA und der ISO 13485 erfüllen. Rückverfolgbarkeit, Dokumentation und validierte Toolchains waren dabei unverzichtbar. Durch die automatische Erstellung von Compliance-Nachweisen innerhalb einer einheitlichen Build-Pipeline erreichte das Unternehmen eine lückenlose Rückverfolgbarkeit über alle Builds und Branches hinweg, ohne die Iterationsgeschwindigkeit zu beeinträchtigen. Die Markteinführungszeit verkürzte sich, und das Vertrauen der Zulassungsbehörden in den Entwicklungsprozess stieg.

Die Gemeinsamkeit aller dieser Beispiele ist nicht ein bestimmtes Werkzeug oder ein spezieller Workflow. Entscheidend ist vielmehr die Erkenntnis, Compliance nicht als nachgelagerte Phase der Entwicklung zu betrachten, sondern als kontinuierlichen Bestandteil des gesamten Entwicklungsprozesses.

Die langfristigen Vorteile

Auf kurze Sicht sprechen viele Gründe für diesen Ansatz: schnellere Builds, weniger Überraschungen bei Audits und ein geringerer Nachbearbeitungsaufwand. Entscheidend sind aber die langfristigen Vorteile.

Denn Embedded-Systeme in der Automobilindustrie sowie in Industrie- und Medizintechnikanwendungen sind häufig 10 bis 20 Jahre im Einsatz. Muss fünf Jahre nach der Markteinführung eine Softwareänderung vorgenommen werden, muss sich die Entwicklungsumgebung, mit der die ursprünglich zertifizierte Software erstellt wurde, exakt reproduzieren lassen. Bei manuell verwalteten Toolchains und nachgelagerten Compliance-Prozessen ist eine solche langfristige Reproduzierbarkeit jedoch nur sehr schwer sicherzustellen.

Hier helfen containerisierte Build-Umgebungen: Sind Toolchain, Analysekonfiguration und Build-Infrastruktur vollständig versionskontrolliert und in einem reproduzierbaren Container-Image zusammengefasst, das von allen Entwicklern, CI-Pipelines und Build-Systemen identisch verwendet wird, bleibt die Entwicklungsumgebung dauerhaft nachvollziehbar.

Das ist eine grundlegende Voraussetzung für sicherheitskritische Produkte mit langen Lebenszyklen.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Ein lohnender Schritt

Für die meisten Embedded-Entwicklungsteams erfordert der Einstieg in Continuous Compliance keine grundlegende Neugestaltung ihrer Entwicklungsprozesse. Sinnvoll ist vielmehr ein schrittweises Vorgehen: Zunächst wird die Build-Umgebung für ein einzelnes Projekt containerisiert, anschließend werden identische Ergebnisse validiert, die Lösung in die bestehende CI-Pipeline integriert und danach schrittweise auf weitere Projekte ausgeweitet.

Entscheidend ist dabei die grundsätzliche Erkenntnis, dass Compliance nicht erst am Ende des Entwicklungszyklus vorbereitet wird, sondern als kontinuierliches Ergebnis im Entwicklungsprozess entsteht.

Teams, die diesen Schritt bereits gemacht haben, berichten übereinstimmend von demselben Ergebnis: Die Zertifizierung ist nicht länger der Engpass im Entwicklungsprozess, sondern der Nachweis dafür, dass der Prozess zuverlässig funktioniert.

Genau für diese Anforderungen wurde die Embedded-Entwicklungsplattform von IAR entwickelt. Sie vereint zertifizierte Toolchains, containerisierte Build-Werkzeuge, statische und Laufzeitanalyse sowie die Integration in CI/CD-Workflows auf einer gemeinsamen Plattform.  (sg)

* Shawn Prestridge ist US Field Applications Engineering Manager bei IAR Systems

(ID:50914977)