Open Source in der funktionalen Sicherheit

Open Source in der funktionalen Sicherheit

| klss777 / stock.adobe.com & Yaruniv-Studio / stock.adobe.com
17.03.2025 Fachinformation

Open Source und funktionale Sicherheit: Meilensteine und Zukunftsperspektiven

Im dritten Teil des Interviews beleuchtete Philipp Ahmann, wie moderne QM-Ansätze und agile Methoden die Softwareentwicklung prägen. Auch die Rolle von Standards wie der ISO 26262 und des ISO PAS 8926 wurde hervorgehoben, um die Qualität und Sicherheit komplexer Systeme zu gewährleisten.

Im abschließenden vierten Teil richten wir den Blick in die Zukunft: Welche Meilensteine stehen für Open Source in der funktionalen Sicherheit an? Welche Chancen und Herausforderungen ergeben sich für Unternehmen, die sich in diesem Bereich engagieren? 

Philipp Ahmann liefert Antworten und gibt spannende Einblicke in die Entwicklungen, die die Branche in den nächsten Jahren prägen werden.

Kontakt
Sascha Man-Son Lee
Zuständiges Gremium
Verwandte VDE Themen

Das erwartet Sie in diesem Artikel:

  • Wie kann ein neuer QM-Ansatz in der Softwareentwicklung aussehen?
  • Warum sollten sich Unternehmen aktiv in die Open-Source-Community einbringen?
  • Wo liegen die nächsten Meilensteine für Open Source im Bereich der funktionalen Sicherheit?

Interview mit Philipp Ahmann – Teil 4

DKE: Sie haben im dritten Teil unseres Interviews erwähnt, dass ein neuer Ansatz für das Qualitätsmanagement in der Softwareentwicklung erforderlich ist. Wie könnte ein solcher Ansatz konkret aussehen?

Ahmann: Ein moderner Ansatz für das Qualitätsmanagement muss sich stark an den aktuellen Praktiken der Softwareentwicklung orientieren, insbesondere an agilen Methoden und Konzepten wie Continuous Integration und Continuous Deployment. Diese Prozesse haben ein hohes Maß an Automatisierung und Qualitätssicherung ermöglicht, das mit traditionellen Modellen wie dem Wasserfallmodell und manuellen Qualitätskontrollen und Dokumentation kaum vergleichbar ist. 

Aus der Praxis wissen wir, dass Anforderungen sich während der Entwicklung ändern oder nachspezifiziert werden müssen. Softwareentwicklung ist heute weniger linear, sondern ein iterativer Prozess, bei dem verschiedene Artefakte in Abhängigkeit zueinander entstehen. Anstatt starre Modelle zu verwenden, könnten wir Best Practices aus erfolgreichen Projekten – insbesondere aus der Open-Source-Welt – in einen modernen Qualitätsstandard integrieren.

Von starrem Regelwerk zur automatisierten Exzellenz – Wie moderne Standards agile Softwareentwicklung neu definieren können

DKE: Was unterscheidet diesen neuen Ansatz von klassischen Standards wie ISO 9001?

Ahmann: Klassische Standards wie ISO 9001 basieren auf strikten Prozessen und Checklisten, die häufig spezifisch für ein Unternehmen angepasst werden. Diese starren Modelle lassen wenig Raum für die Flexibilität, die moderne Softwareentwicklung erfordert. Wobei die ISO 9001 sogar noch ein sehr „OSS-freundlicher“ Standard ist. ASPICE oder CMMI sind dort deutlich starrer. 

Ein moderner Ansatz sollte bestehende Best Practices aus der Industrie und dem Open-Source-Bereich aufgreifen. Viele dieser Methoden – wie automatisierte Code-Qualitätsprüfungen oder Tests – sind in der Praxis längst etabliert, aber oft nicht dokumentiert. Dadurch, dass die Prüfungen automatisiert erfolgen, die Ausführung voll nachvollziehbar ist und sogar der Code der Automatisierung zur Prüfung nachgeschaut werden kann, wird auf weitere Dokumentation verzichtet. Ziel ist es jetzt, diese Methoden zu systematisieren und sie als Grundlage für einen neuen Qualitätsstandard zu nutzen. So könnte ein Standard entstehen, der sowohl für Open Source als auch für Industrieprojekte geeignet ist.

DKE: Wie kann dieser neue Qualitätsstandard etabliert werden?

Ahmann: Die Idee entstand in unserer Community, insbesondere in Projekten wie ELISA (Enabling Linux in Safety Applications). Der Ansatz ist, Best Practices moderner Softwareentwicklung – die sich vielfach in Open Source bewährt haben – zu identifizieren und zu dokumentieren. Dabei geht es nicht nur um Open Source, sondern um Softwareentwicklung im Allgemeinen. Ein Beispiel sind Tools, die heute viele Prozesse automatisieren. Während, wie bereits erwähnt, früher Checklisten notwendig waren, um sicherzustellen, dass bestimmte Aufgaben erledigt wurden, erzwingen moderne Werkzeuge diese Schritte automatisch. 

Dokumentation wird nicht länger in Form von pdf-Dateien geliefert, sondern als „Doc-as-Code“ mit strikter Versionskontrolle und vollständiger Instrumentalisierung und Automatisierung. Es ermöglicht uns mit Dokumentation ähnlich zu verfahren wie mit Source Code und Compilern, Variablen, Binärprodukten (statische Dokumente). Entwickler können nicht ‚herumtricksen‘, da das System die Einhaltung der Vorgaben sicherstellt und jeder Schritt sichtbar wird. Diese Verankerung von Werkzeugen und Prozessen ist ein zentraler Bestandteil eines modernen Qualitätsstandards. Im Idealfall ist so der Weg vorbereitet für eine kontinuierliche Sicherheitszertifizierung.


DKE Tagung Funktionale Sicherheit 2025

DKE Tagung Funktionale Sicherheit 2025

| VDE

DKE Tagung Funktionale Sicherheit: 13.05.2025 bis 14.05.2025 in Erfurt

Neue Technologien und Lösungen erobern die Welt – aber wie kann funktionale Sicherheit dabei Schritt halten? Eine berechtigte Frage, die wir diskutieren wollen und müssen! Und wo wäre das besser möglich als in Erfurt? Die "Erfurter Tage" haben sich mittlerweile als fester Begriff und Branchentreff etabliert. Alle zwei Jahren kommen Expertinnen und Experten im Kaisersaal zusammen und tauschen sich aus. Seien auch Sie dabei und freuen Sie sich auf zwei intensive Konferenztage!

Jetzt anmelden!

Brücken bauen zwischen Industrie und Open Source – Gemeinsam Standards gestalten und sichere Systeme entwickeln

DKE: Wie kann die Industrie dabei eingebunden werden?

Ahmann: Wir suchen gezielt nach Unternehmen, die ihre Erfahrungen und ihr Wissen einbringen möchten. Die Idee ist, gemeinsam einen Standard zu entwickeln, der aktuelle Entwicklungsmethoden berücksichtigt und anwendbar ist – nicht nur für Open Source, sondern auch für proprietäre Software. Durch die Zusammenarbeit können wir sicherstellen, dass dieser Standard praxisnah ist und die Anforderungen verschiedener Branchen erfüllt. Die Methoden, die wir dabei betrachten, sind vielfach aus Open-Source-Projekten hervorgegangen, haben sich aber längst auch in der Industrie etabliert. 

In der Praxis sehen wir weitere Initiativen, die versuchen, Industrie und Open Source in der Prozesswelt zu vereinen. Als Beispiele sind neben dem ELISA-Projekt auch die Eclipse SDV Automotive Process SIG und das Eclipse Safe Open Vehicle Core Projekt zu nennen.

DKE: Welche zentralen Botschaften möchten Sie Unternehmen mitgeben, die auf Open Source in sicherheitskritischen Systemen setzen möchten?

Ahmann: Der wichtigste Punkt ist, dass Unternehmen sich aktiv in die Open-Source-Community einbringen müssen, wenn sie diese Lösungen erfolgreich nutzen möchten. Open-Source-Projekte sind offen für neue Mitglieder und Ideen, aber ein reines Beobachten reicht nicht aus. Nur wer aktiv teilnimmt, lernt die Prozesse, Anforderungen und Mechanismen wirklich kennen. 

Ein guter Einstieg ist, sich zunächst mit den Communities vertraut zu machen und kleinere Beiträge zu leisten. Das kann durch Bugfixes, Dokumentation oder die Einbringung von Anforderungen geschehen. Für Unternehmen ist das eine Chance, tiefere Einblicke in die Arbeitsweise der Zulieferer und Entwickler zu erhalten und ein Technologieverständnis zu entwickeln, welches bessere Entscheidungsfähigkeit erzeugt. Besonders bei Zulieferern, die selbst Open Source einsetzen, kann die Teilnahme an den entsprechenden Communities wertvolle Informationen über deren Entwicklungsansätze liefern.

Von der Beobachtung zur Beteiligung – Wie Unternehmen durch aktiven Open-Source-Austausch ihre sicherheitskritischen Systeme stärken

DKE: Was bedeutet das konkret für Unternehmen, die sicherheitskritische Systeme entwickeln?

Ahmann: Unternehmen müssen verstehen, dass Open Source nicht immer sofort perfekt auf ihre Bedürfnisse zugeschnitten ist. Aber sie können von der Expertise und den Erfahrungen der Community profitieren – sei es durch Austausch oder durch direkte Übernahme von Best Practices in den eigenen Entwicklungsprozess. Es geht auch nicht zwangsläufig darum, Open-Source-Software direkt in ein sicherheitskritisches System einzubinden. Unternehmen können auch aus Teilbereichen der Projekte lernen, etwa durch den Einsatz kleinerer Softwaremodule oder durch Inspiration für ihre eigenen Prozesse. Wichtig ist, dass sie ihre Anforderungen und Erwartungen klar kommunizieren. 

Ein oft unterschätzter Aspekt ist der Austausch über Standards. Viele Unternehmen haben Zugang zu Normen wie der IEC 61508 oder ISO 26262, die für die Open-Source-Community oft schwer zugänglich sind. Unternehmen können durch den Austausch und Diskussionen über Anforderungen und Use Cases dazu beitragen, dass Open-Source-Projekte diese besser verstehen und berücksichtigen. Dieser Dialog ist nicht nur für die Normkonformität wichtig, sondern schafft auch Vertrauen und Akzeptanz in der Community. Der einfachste Weg, um einen guten Überblick zu bekommen und ein erstes Gefühl für Open-Source-Communities zu erhalten, sind übrigens Open-Source-Konferenzen, die sich weltweit finden lassen und verschiedenste Schwerpunkte bedienen. 

DKE: Wie können Unternehmen langfristig von dieser Zusammenarbeit profitieren?

Ahmann: Langfristig profitieren Unternehmen, indem sie die Entwicklung von Open-Source-Projekten aktiv mitgestalten. Sie können sicherstellen, dass die Projekte ihre spezifischen Anforderungen erfüllen und gleichzeitig die Weiterentwicklung der Software fördern. Ein Beitrag zur Community muss dabei nicht immer in Form von Quellcode erfolgen. Die Community ist offen für die Nennung spezifischer Anforderungen. Unternehmen, die sich engagieren, werden schnell akzeptiert und integriert. Außerdem benötigen viele Projekte zusätzliche finanzielle Unterstützung, um beispielsweise Maintainer oder CI- und Testinfrastruktur zu finanzieren. 

Das kann gerade dort eine Lösung sein, wo es für Unternehmen einfacher ist Geld als Ressourcen in Open Source zu investieren. Die zugrunde liegende Idee ist, dass unabhängig davon, ob mit Geld oder Ressourcen beigetragen wird, die Zulieferer nicht auszunehmen. Dies dient der langfristigen Risikoreduzierung und der Sicherstellung der Lieferfähigkeit.


DKE Newsletter-Seitenbild
sdx15 / stock.adobe.com

Mit unserem DKE Newsletter sind Sie immer top informiert! Monatlich ...

  • fassen wir die wichtigsten Entwicklungen in der Normung kurz zusammen
  • berichten wir über aktuelle Arbeitsergebnisse, Publikationen und Entwürfe
  • informieren wir Sie bereits frühzeitig über zukünftige Veranstaltungen
Ich möchte den DKE Newsletter erhalten!

Sicherheitszertifizierung im Wandel: Von proprietären Ansätzen zu communitygetriebenen Open-Source-Lösungen

DKE: Wo sehen Sie den nächsten Meilenstein für Open Source im Bereich der funktionalen Sicherheit?

Ahmann: Open Source hat bereits Einzug in funktionale Sicherheitsstandards gehalten, und ich denke, der nächste große Meilenstein wird die Verfügbarkeit der ersten sicherheitszertifizierten Systeme sein. Was wir heute schon verstärkt im Bereich Automotive sehen, sind gemischt-kritische Systeme, bei denen auch gerne von „Safe Linux“ gesprochen wird.

Bei genauem Betrachten stellt man allerdings fest, dass hier ein klassisches Linux ohne explizite Sicherheitsanforderung überwacht wird. Im Gegensatz dazu stehen Open-Source-Komponenten, die von einzelnen Unternehmen entwickelt und nach den Anforderungen funktionaler Sicherheit zertifiziert wurden. Diese Initiativen sind jedoch oft firmengetrieben, das heißt, die Unternehmen haben die Kontrolle über den gesamten Entwicklungs- und Zertifizierungsprozess. 

In den kommenden Jahren wird sich das weiterentwickeln, hin zu ersten Community-zentrischen Projekten. Besonders für Linux erwarte ich, dass immer mehr Bibliotheken zertifiziert werden und wir Argumentationen sehen, wie Linux in funktional sicheren Bereichen eingesetzt werden kann – sei es mit gemischter Kritikalität oder in speziell abgesicherten Konfigurationen. Es muss dabei nicht immer ein komplettes System auf Safety-Integrity-Level-Niveau zertifiziert werden, sondern es können auch Teilbereiche oder einzelne Komponenten qualifiziert werden 

DKE: Welche Entwicklungen erwarten Sie in naher Zukunft?

Ahmann: Ein großer Schritt wird die nächste Edition sowohl der IEC 61508 als auch der ISO 26262 sein. Beide Standards könnten neue Ansätze bieten, um mit der Komplexität moderner Software umzugehen. Ein weiteres spannendes Thema ist die Koexistenz von sicherheitskritischer und nicht-sicherheitskritischer Software innerhalb eines Systems – also gemischte Kritikalität. Projekte wie Linux, Zephyr und Xen erfahren aktuell starken Zuspruch und dürften in den nächsten Jahren erhebliche Fortschritte bei der Entwicklung funktional sicherer Varianten erzielen.

Dieses Momentum könnte innovative Lösungen und Argumentationen für Open Source in der funktionalen Sicherheit hervorbringen und zu neuen Standards führen. Ich bin deshalb optimistisch, dass wir bald funktional sichere Open-Source-Produkte auf dem Markt sehen werden, die den Stand der Technik der Branchen neu definieren.

DKE: Herzlichen Dank, Herr Ahmann, für Ihre Zeit und Expertise.

--- Ende von Teil 4 dieses Interviews ---

Hier endet die letzte Gesprächsrunde mit Philipp Ahmann zur Anwendung von Open Source in sicherheitskritischen Systemen.

Der erste Teil dieses Interviews thematisiert den Grundgedanken von Open Source, aktuelle Projekte und die normative Berücksichtigung in der IEC 61508.

Der zweite Teil dieses Interviews geht unter anderem auf die Anforderungen an den Linux-Kernel ein sowie die Bedeutung und Rolle der Software Maintainer bei der Entwicklung von sicherheitskritischen Systemen.

Der dritte Teil dieses Interviews thematisiert unter anderem die Fortschritte bei der Anwendung von Open Source in der Cybersicherheit im Vergleich zur funktionalen Sicherheit.

Wir bedanken uns für dieses Interview bei

Portraitfoto Philipp Ahmann

Philipp Ahmann

Senior OSS Community Manager, ETAS GmbH

Portraitfoto Philipp Ahmann

Senior OSS Community Manager, ETAS GmbH

Philipp Ahmann ist Senior Open Source Community Manager bei der ETAS GmbH, einem Unternehmen der Bosch-Gruppe. Mit über 15 Jahren Erfahrung in Linux-basierten Softwareplattformen für die Automobilindustrie bringt der Diplomingenieur und Master of Science für Elektrotechnik fundiertes Fachwissen in die Entwicklung sicherheitskritischer Anwendungen ein.

In seiner Rolle als Vorsitzender des technischen Steuerkreises des ELISA-Projekts (Enabling Linux in Safety Applications) der Linux Foundation leitet Ahmann die strategische Ausrichtung und die Systems-Arbeitsgruppe, um Linux in sicherheitskritischen Umgebungen zu etablieren. In der Eclipse Software Defined Vehicle Working Group unterstützt er die Entwicklung von Automotive Open Source Prozessen und die Erstellung eines sicheren Open-Source-basierten Middleware-Stacks. Darüber hinaus ist er Mitglied des Advisory Boards der Linux Foundation Europe, wo er die Weiterentwicklung von Open-Source-Initiativen unterstützt.


DKE Tagung Funktionale Sicherheit 2025: Keynotes, Fachdiskussionen, Community

Sie möchten vom 13. bis 14. Mai 2025 an der Veranstaltung in Erfurt teilnehmen? Wir freuen uns auf Sie!

Jetzt anmelden!

Interessiert an weiteren Inhalten zu Core Safety?

Fokusbild Core Safety & Information Technologies

Core Safety & Information Technologies umschließt alle Aspekte der Sicherheit: grundlegende  Sicherheitsanforderungen, funktionale Sicherheit, Informationssicherheit sowie deren Wechselwirkungen. Außerdem befasst sich Core Safety mit wichtigen Querschnittsthemen und definiert grundlegende Anforderungen die allgemein einzuhalten sind – zum Beispiel für Elektromagnetische Verträglichkeit, Umwelt- und Ressourceneffizienz, Schadstoffe, Größen, Einheiten und Kennzeichnungen. Weitere Inhalte zu diesem Fachgebiet finden Sie im

DKE Arbeitsfeld Core Safety & Information Technologies

Relevante News und Hinweise zu Normen