Wiederverwendbare Embedded-Security-Plattform
Ausgangssituation
In mehreren Automotive-Projekten mussten Embedded-Systeme Security-Funktionen integrieren. HSM-Anbindung, kryptografische Dienste und Security-Integrationswege wurden zu wiederkehrenden technischen Aufgaben.
Herausforderung
Wenn jedes Projekt diese Themen neu interpretiert, entstehen hoher Abstimmungsaufwand, unterschiedliche Integrationsmuster und schwer planbare technische Risiken. Die Lösung musste projektübergreifend nutzbar sein, ohne die Unterschiede einzelner Projekte zu ignorieren.
Rolle und Vorgehen
Die Arbeit bestand im Aufbau und in der Weiterentwicklung einer wiederverwendbaren Embedded-Security-Plattform. Dazu gehörten standardisierte Integrationsansätze, die Einbindung von HSM und kryptografischen Diensten sowie technische Guidance für die Nutzung der Plattformstrukturen in mehreren Projekten.
Wirkung
Der Security-Integrationsaufwand wurde in diesem Kontext um ungefähr 75 Prozent reduziert. Wichtiger als die Kennzahl war die Wirkungskette: Wiederverwendung, weniger wiederholte Abstimmung, einfachere Integration weiterer Softwaremodule, bessere Planbarkeit und langfristig effizientere Entwicklung durch einen Plattformansatz. Die Weiterentwicklung wurde über mehr als 15 Projekte pro Jahr technisch verantwortet.
Was dieses Beispiel zeigt
Platform Security ist nicht nur ein Schutzkonzept. Richtig strukturiert wird sie zu einer wiederverwendbaren technischen Plattformfähigkeit, die Architektur, Integration und Engineering Enablement verbindet.
End-to-End-Architektur für Software-Defined Vehicles
Ausgangssituation
Im Kontext eines End-to-End Software-Defined Vehicle mussten bestehende technische Lösungen und Architekturen analysiert, bewertet und in ein konsistentes Gesamtbild gebracht werden.
Herausforderung
Die Arbeit betraf kein einzelnes Softwaremodul. Bestehende Technologien und Architekturen mussten vom Gesamtfahrzeug über System-, Domänen- und Plattformebenen bis hinunter zu Embedded- und Mikrocontroller-Systemen verstanden, bewertet und in ein konsistentes Gesamtbild gebracht werden.
Rolle und Vorgehen
Ein zentraler Teil war eine technische Entscheidungshilfe für Ausführungs- und Isolationstechnologien wie Linux, Containerisierung, Sandboxing, Microkernel und Hypervisor. Die Auswahl wurde aus ASIL-Level, QM-Kontext, Security-Anforderungen, Kritikalität, System- und Softwaregrenzen, notwendiger Isolation und gegenseitiger Beeinflussung von Funktionen abgeleitet. Dazu kamen eigene Architekturkonzepte und die Adaption bestehender Technologien für die Gesamtarchitektur.
Wirkung
Die Architektur wurde mit wichtigen, konzernweit arbeitenden Architekten abgestimmt, vor technischen Entscheidungsträgern vorgestellt und führte zu zahlreichen weiterführenden technischen Diskussionen. Die Ergebnisse wurden in mehreren Artikeln eines internen Dokumentations- und Empfehlungssystems festgehalten, sodass sie organisationsweit weiterverwendet werden konnten. Aus der Architekturarbeit entstanden mehrere Erfindungsmeldungen; einige daraus hervorgegangene Erfindungen befinden sich im weiteren Patentierungsprozess.
Was dieses Beispiel zeigt
Das Beispiel zeigt Architecture Trade-off Analysis auf Systemebene: Anforderungen, Safety-/Security-Kritikalität und benötigte Isolation werden in nachvollziehbare Architekturmechanismen übersetzt. Der Wert liegt nicht im Begriff SDV, sondern in einer entscheidbaren End-to-End-Architektur.
Lokales KI-gestütztes Engineering-Wissenssystem
Ausgangssituation
Ausgangspunkt war der Weggang eines erfahrenen Experten und das Risiko, dass wichtiges Engineering-Wissen schwer auffindbar oder nicht mehr nutzbar ist. Später wurde auch eigenes Wissen so aufbereitet, dass andere es nach dem Weggang des Erstellers weiterverwenden können.
Herausforderung
Das Problem war kein allgemeines KI-Thema. Vertrauliche Dokumente, Quellcode und internes Wissen sollten das kontrollierte System nicht unkontrolliert verlassen. Gleichzeitig musste vorhandenes Wissen auffindbar, analysierbar und nachvollziehbar nutzbar werden.
Rolle und Vorgehen
Es entstand ein lokales RAG-basiertes System. Lokale Verarbeitung, Zugriffsschutz, Nachvollziehbarkeit und Security by Design waren Architekturanforderungen. KI wurde als technischer Baustein eingesetzt, um Engineering-Wissen strukturiert zugänglich zu machen.
Wirkung
Das System machte Wissen und wiederkehrende Unterstützungsleistungen teilweise verfügbar und reduzierte persönliche Abhängigkeiten. Es ersetzte keinen Mitarbeiter vollständig, sondern half, vorhandene Engineering-Erfahrung kontrolliert nutzbar zu halten.
Was dieses Beispiel zeigt
AI-Assisted Engineering ist dann belastbar, wenn es als Systems-Architecture- und Platform-Security-Aufgabe behandelt wird. KI ist dabei Werkzeug, nicht der Geschäftszweck.
Umfangreiche Security-Anforderungen entscheidbar gemacht
Ausgangssituation
Projekte hatten regelmäßig mehr als 500 detaillierte Anforderungen, darunter Security-spezifische Anforderungen, verteilt über viele Excel-Tabellen, PDFs und E-Mails. Für Projektleitung und Engineering-Teams musste klar werden, welche Anforderungen relevant, umsetzbar oder zu klären waren.
Herausforderung
Große Requirement-Mengen erzeugen schnell Scheingenauigkeit. Entscheidend ist nicht nur, Anforderungen zu sammeln, sondern ihren technischen Beitrag, offene Annahmen, Ausschlüsse, Risiken und betroffene Komponenten sichtbar zu machen.
Rolle und Vorgehen
Die beteiligten Kollegen erhielten eine technische Struktur, um die Anforderungen selbst einzuordnen: betroffene Softwarekomponenten, Plattformfähigkeiten, Aufwände, Risiken, Annahmen und Ausschlüsse. Dadurch konnten sie das Anforderungschaos für Projektleitung und Engineering-Teams transparent aufbereiten.
Wirkung
Technische Entscheidungen wurden nachvollziehbarer. Andere Gewerke konnten aus der Struktur ableiten, welche Beiträge in ihren Komponenten notwendig waren. Damit wurde Systems Architecture nicht als Greenfield-Entwurf verstanden, sondern als Klärung komplexer vorhandener Abhängigkeiten.
Was dieses Beispiel zeigt
Belastbare Architekturarbeit entsteht oft dort, wo Anforderungen, bestehende Systeme, mehrere Teams und offene Entscheidungen in ein gemeinsames technisches Lagebild gebracht werden müssen.
Engineering-Wissen in ein Einarbeitungssystem überführt
Ausgangssituation
Technisches Wissen zu Platform Security und Security Engineering lag in Projekterfahrung, wiederkehrenden Abläufen und vielen Detailentscheidungen. Neue Ingenieure mussten dieses Wissen verstehen, bevor sie selbstständig arbeiten konnten.
Herausforderung
Reine Übergaben oder punktuelle Erklärungen reichen in solchen Situationen nicht aus. Wissen muss auffindbar, verständlich und dauerhaft nutzbar werden, ohne aus Engineering Enablement eine formale Ausbildung oder ein eigenes Schulungsprodukt zu machen.
Rolle und Vorgehen
Seit 2021 wurde technisches Wissen von Beginn an in internen Wiki-Artikeln, Dokumenten und How-tos festgehalten. Wiederkehrende technische Abläufe wurden zusätzlich in erklärenden Videos dokumentiert. Zweiwöchentliche Security Engineering Insights machten Abkürzungen, Fachbegriffe, Verantwortlichkeiten, Modulrollen und Kostenfolgen für Nicht-Security-Teams nachvollziehbar. Ergänzt wurde dies durch Implementierungskonzepte, technische Guidance und Review-Strukturen.
Wirkung
Aus den einzelnen Artefakten entstand schrittweise ein Einarbeitungs- und Befähigungssystem. Über fünf Jahre hinweg wurden damit etwa 15 Ingenieure im Bereich Platform Security beziehungsweise Security Engineering ausgebildet. Das Wissen blieb dadurch nicht nur an einzelne Personen gebunden.
Was dieses Beispiel zeigt
Engineering Enablement wirkt, wenn Architekturentscheidungen, How-tos, Reviews und Wissenstransfer Teil der technischen Lösung werden. Ziel ist nicht mehr Dokumentation, sondern arbeitsfähige Teams.
Projektübergreifende technische Koordination und Aufwandstransparenz
Ausgangssituation
Zahlreiche Projekte mussten gleichzeitig unterstützt werden. Technische Fragen liefen zwischen Projektleitung, Entwicklungsteams, Security-Verantwortlichen und weiteren Fachbereichen zusammen.
Herausforderung
Projektübergreifende technische Unterstützung funktioniert nur, wenn Einschätzungen belastbar und nachvollziehbar sind. Aufwandsschätzungen müssen Scope, Annahmen, Risiken und Ausschlüsse sichtbar machen, ohne Budget- oder Personalverantwortung vorzutäuschen.
Rolle und Vorgehen
Die Arbeit bestand in technischer Abstimmung, Aufwandsschätzungen und der Aufbereitung von Entscheidungsgrundlagen. Ziel war, unterschiedliche technische Rollen auf eine gemeinsame Sicht zu bringen und offene Punkte so zu strukturieren, dass Entscheidungen möglich wurden.
Wirkung
Durch transparente, belastbare und zielorientierte Einschätzungen entstand Vertrauen in die technische Bewertung. Mit zunehmender Reputation wurden Einschätzungen als Entscheidungsgrundlage akzeptiert. Die Aussage zu mehr als 15 Projekten pro Jahr dient hier nur dazu, den projektübergreifenden Kontext einzuordnen.
Was dieses Beispiel zeigt
Technische Urteilskraft zeigt sich nicht nur im Entwurf einzelner Systeme, sondern auch darin, komplexe Projektsituationen ruhig, nachvollziehbar und entscheidbar zu strukturieren.
Eine ähnliche technische Situation?
In einem ersten Gespräch wird geklärt, welche Ausgangslage besteht, welche Entscheidung benötigt wird und ob ein Assessment, Review oder konkretes Architekturmandat sinnvoll ist.