Embedded · Feldnotizen
Die Fachgrundlage hinter der Entscheidung
Neun Dimensionen, fünf Zeichnungen gegen die Primärdokumente, die Rechtslage abseits der Straße und ein Lehrfall ohne Kunden. Hat eine Aussage eine Quelle, steht sie darunter. Hat sie keine, steht auch das dort.
Die Frage
Woran Make-or-buy wirklich hängt
Nicht am Stack. An Dimensionen, die je Baustein anders ausfallen und die jede Variante vervielfacht – und die Antwort hat drei Achsen: bauen, kaufen, und in welchem Modell.
Lizenz gegen Eigenbau
Was der zugekaufte Baustein je Steuergerät und je Programm kostet – gegen den Aufwand, ihn selbst zu bauen und selbst aktuell zu halten.
Sicherheitsnachweise
Wer die Nachweise liefert, wer sie bei jeder Änderung nachführt, und was passiert, wenn der Lieferant das Interesse verliert.
Werkzeugbindung
Wem die Konfiguration gehört, in welchem Format sie lebt, und ob ein Werkzeugwechsel eine Migration ist oder ein Neuanfang.
Lieferantenabhängigkeit
Was ein Wechsel kostet, wenn Preise, Roadmap oder Eigentümer des Anbieters sich ändern – und ob es einen zweiten Weg gibt.
Personal
Welche Kompetenz im Haus ist, welche man aufbauen müsste, und welche man auf Dauer halten kann.
Zeit bis zum Serienstart
Was der Zukauf an Monaten spart – und was die Integration davon wieder auffrisst.
Wartung über den Lebenszyklus
Zehn bis fünfzehn Jahre Pflege, Updates und Ersatz: die Kosten nach dem Serienstart sind meist größer als die davor.
Geistiges Eigentum
Was am Ende dem Unternehmen gehört – und was man nur benutzt hat.
Das Modell
Kaufen ist nicht eine Option, sondern viele: wie lizenziert wird, was geliefert wird, und wer es über die Laufzeit pflegt. Nachprüfbare Preise gibt es dazu öffentlich nicht — wer Ihnen ohne Angebot eine Lizenzrechnung aufmacht, schätzt. Welches Modell man wählt, bindet Geld, Werkzeuge und Personal verschieden.
Quellen: AUTOSAR-Partnermodell (autosar.org) und die Release Overviews R25-11. Zu den Modellen: Stackpreise der Anbieter sind durchweg unöffentlich; öffentlich nachlesbar sind allein die Partnergebühren des Konsortiums — 10.000 Euro im Jahr für kleine Firmen bis 90.000 Euro plus sechs Vollzeitstellen für die oberste Stufe (autosar.org, Abruf 31.08.2026).
Die Architektur, gezeichnet
Zwei Plattformen, wo sie sich berühren — und wer welche Schicht liefert
Es sind fünf Abbildungen, und sie stammen nicht aus derselben Quelle. Drei sind aus den AUTOSAR-Dokumenten der Fassung R25-11 gezeichnet. Aus Herstellerangaben und Schulungsmaterial zusammengetragen ist die vierte, die Liefergrenze, und sie trägt ausdrücklich die Kennzeichnung übliche Praxis, nicht Vorgabe: es gibt sie öffentlich nirgends, obwohl sie über Make-or-buy entscheidet. Die letzte stellt eine verbreitete Darstellung neben den Stand von November 2025.
Klassische Plattform
Auf oberster Abstraktionsebene unterscheidet AUTOSAR drei Software-Schichten — Anwendung, Laufzeitumgebung und Basissoftware —, die auf einem Mikrocontroller laufen. Die Basissoftware zerfällt in vier weitere: Dienste, Steuergeräte-Abstraktion, Mikrocontroller-Abstraktion und Complex Drivers.
- Application LayerAnwendungskomponenten — oberhalb der Laufzeitumgebung wechselt der Baustil von „geschichtet“ zu „Komponenten“
- Runtime Environment (RTE)je Steuergerät einzeln erzeugt; weder Anwendung noch Basissoftware
- Services LayerSystem, Speicher, Krypto, Kommunikation, Off-board-Kommunikation
- ECU Abstraction Layertrennt die Funktion von dieser Platine; hier liegt auch die I/O-Abstraktion
- Microcontroller Abstraction Layerkommt üblicherweise vom Halbleiterhersteller
- Microcontrollerdie Hardware, im offiziellen Bild der Unterbau, keine Software-Schicht
Complex Drivers — eigene Schicht, die von der Hardware bis zur Laufzeitumgebung reicht. Für alles, was AUTOSAR nicht spezifiziert, sehr harte Zeitanforderungen hat oder aus einer Migration stammt. Sie ist kein Beiwerk, sondern die einzige vorgesehene Öffnung: nicht-standardisierte Module gehen als Complex Driver hinein, und weitere Schichten dürfen nicht hinzugefügt werden. In der Landtechnik wird ISOBUS klassisch genau hier eingebunden, als Complex Driver neben der Basissoftware. Vorgeschrieben ist das nicht; es ist der Weg, den die Werkzeugwelt seit Jahren geht.
Konfiguriert über ARXML/ECUC — die Bindung an die Werkzeugkette entsteht hier, nicht im Code.
Adaptive Plattform
Adaptive Anwendungen laufen auf ARA, der Laufzeitumgebung für adaptive Anwendungen. ARA besteht aus Schnittstellen, die Functional Clusters bereitstellen — keine Module und keine weitere Schichtung.
- Adaptive Applicationsbeschränkt auf das Einprozessprofil PSE51
- ARA — Functional Clusters21 Cluster in R25-11, gruppiert in Foundation, Platform Services und weitere
- POSIX OSdas Plattform-Betriebssystem selbst muss mehrprozessfähig sein
- Machinephysisch, virtualisiert oder ein Container — AUTOSARs eigener Begriff
Communication Management (ara::com) — ein Cluster unter vielen — und trotzdem der einzige vorgesehene Weg. Architektonisch ist die Kommunikationsverwaltung ein Functional Cluster wie die anderen, keine eigene Ebene darüber. Ihr Gewicht kommt woanders her: weil das Einprozessprofil keine geräteinterne Verständigung vorsieht, ist sie laut Spezifikation die einzige ausdrückliche Schnittstelle zwischen adaptiven Anwendungen. Deshalb ist sie hier hervorgehoben und nicht herausgehoben.
Zwei offizielle Sichten auf dieselben Cluster: nach Gruppen (Foundation, Platform Services …) und nach Kategorien (Runtime, Communication, Storage, Security, Safety, Configuration, Diagnostics).
Wo die beiden Plattformen sich tatsächlich berühren
Seit R25-11 trägt auch die klassische Plattform dienstorientierte Kommunikation über DDS. Geteilt wird dabei kein Bauteil und keine Ebene, sondern ein Protokoll: die klassische Seite übernimmt das Service Discovery der adaptiven, ausdrücklich zur Verträglichkeit über beide Lösungen hinweg. Die Bausteine dafür liegen in den Stapeln, nicht darüber.
Wer liefert welche Schicht — die Zeichnung, die es öffentlich nicht gibt
Genau an dieser Linie entscheidet sich Make-or-buy, und in keinem öffentlichen Schichtbild ist sie eingezeichnet. Sie ist keine Norm, sondern übliche Praxis — und die oberste Grenze ist Verhandlungssache, nicht Technik.
- OEM oder ZuliefererAnwendungskomponenten, Integration, Nachweisführung — und je nach Modell mehr oder weniger davon
- Stack-Anbieterhardwareunabhängige Basissoftware und das Werkzeug, das die Laufzeitumgebung erzeugt
- HalbleiterherstellerMikrocontroller-Abstraktion und Betriebssystem, dazu die passenden Generatoren
Verschieblich: manche Hersteller lizenzieren die Basissoftware selbst und geben sie vorintegriert weiter, andere spezifizieren nur und überlassen Umsetzung und Integration dem Zulieferer. Grosse Zulieferer bauen ihre eigene Basissoftware und treten damit selbst als Anbieter auf.
Wie es gezeichnet wird — und was der Standard seit November 2025 vorsieht
Diese Abbildung widerspricht einer anderen. Die verbreitete Koexistenz-Darstellung zeigt die klassische Plattform am Bus, die adaptive am Ethernet, und dazwischen ein Gateway-Steuergerät, das Signale in Dienste übersetzt. Sie ist nicht falsch, nur nicht mehr vollständig. Seit R25-11 gibt es einen zweiten Weg, der ohne diesen Übersetzer auskommt. Wo Protokolle, Datenmodelle, Netze oder Sicherheitsgrenzen auseinanderlaufen, bleibt das Gateway nötig.
Klassisch gegen adaptiv
Zehn Unterschiede — und woher jeder einzelne stammt
Die verbreitete Gegenüberstellung kursiert seit Jahren in Fachbeiträgen, meist ohne Quelle. Hier steht sie mit Herkunft: geprüft heisst gegen ein AUTOSAR-Primärdokument nachgelesen, ungeprüft heisst Dienstleisterangabe ohne Beleg. Zwei von zehn Zeilen halten dieser Prüfung stand — der Rest ist plausibel und unbelegt.
- Betriebssystem
- Klassische PlattformOSEK/VDXAdaptive PlattformPOSIX, Profil PSE51
- ✓Wörtlich im AUTOSAR-Dokument zur Plattformgestaltung R25-11: „PSE51 interface, a single-process profile of POSIX standard“.
- Sprache
- Klassische PlattformCAdaptive PlattformC++
- ✓Die adaptive Codebasis liegt laut Release-Übersicht R25-11 bei mindestens C++17.
- Kommunikation
- Klassische PlattformsignalorientiertAdaptive Plattformdienstorientiert
- !Überholt seit R25-11: die klassische Plattform trägt seit November 2025 selbst dienstorientierte Kommunikation über DDS. Die Zeile stimmt für ältere Stände.
- Ausführung
- Klassische Plattformdirekt aus dem FestspeicherAdaptive Plattformladen und dann ausführen
- ?Plausibel und in der Sache unstrittig, aber in dieser Formulierung ohne Primärbeleg.
- Updates zur Laufzeit
- Klassische PlattformneinAdaptive Plattformja
- ?Als Entwurfsziel der adaptiven Plattform unstrittig; die Absolutheit des „nein“ ist nicht belegt.
- Ablaufplanung
- Klassische PlattformstatischAdaptive Plattformdynamisch
- ?Gängige Beschreibung, ohne Quellenangabe in der Ausgangsdarstellung.
- Echtzeit
- Klassische PlattformMikrosekundenAdaptive PlattformMillisekunden
- ?Zahlenangabe ohne Beleg. Die Grössenordnung hängt an Hardware und Konfiguration, nicht an der Plattform.
- Rechenleistung
- Klassische Plattformrund 1.000 DMIPsAdaptive Plattformüber 20.000 DMIPs
- ?Dienstleisterzahlen ohne Quelle. Als Entscheidungsgrundlage nicht belastbar.
- Sicherheitsanforderung
- Klassische Plattformbis ASIL DAdaptive Plattformab ASIL B
- ?Unbelegt und irreführend: die Einstufung folgt der Gefährdung im Fahrzeug, nicht der Plattformwahl.
- Funktionsumfang
- Klassische PlattformfestAdaptive Plattformflexibel
- ?Eine Charakterisierung, keine prüfbare Aussage.
| Merkmal | Klassische Plattform | Adaptive Plattform | Herkunft |
|---|---|---|---|
| Betriebssystem | OSEK/VDX | POSIX, Profil PSE51 | ✓Wörtlich im AUTOSAR-Dokument zur Plattformgestaltung R25-11: „PSE51 interface, a single-process profile of POSIX standard“. |
| Sprache | C | C++ | ✓Die adaptive Codebasis liegt laut Release-Übersicht R25-11 bei mindestens C++17. |
| Kommunikation | signalorientiert | dienstorientiert | !Überholt seit R25-11: die klassische Plattform trägt seit November 2025 selbst dienstorientierte Kommunikation über DDS. Die Zeile stimmt für ältere Stände. |
| Ausführung | direkt aus dem Festspeicher | laden und dann ausführen | ?Plausibel und in der Sache unstrittig, aber in dieser Formulierung ohne Primärbeleg. |
| Updates zur Laufzeit | nein | ja | ?Als Entwurfsziel der adaptiven Plattform unstrittig; die Absolutheit des „nein“ ist nicht belegt. |
| Ablaufplanung | statisch | dynamisch | ?Gängige Beschreibung, ohne Quellenangabe in der Ausgangsdarstellung. |
| Echtzeit | Mikrosekunden | Millisekunden | ?Zahlenangabe ohne Beleg. Die Grössenordnung hängt an Hardware und Konfiguration, nicht an der Plattform. |
| Rechenleistung | rund 1.000 DMIPs | über 20.000 DMIPs | ?Dienstleisterzahlen ohne Quelle. Als Entscheidungsgrundlage nicht belastbar. |
| Sicherheitsanforderung | bis ASIL D | ab ASIL B | ?Unbelegt und irreführend: die Einstufung folgt der Gefährdung im Fahrzeug, nicht der Plattformwahl. |
| Funktionsumfang | fest | flexibel | ?Eine Charakterisierung, keine prüfbare Aussage. |
✓gegen Primärdokument geprüft!seit R25-11 überholt?Dienstleisterangabe, unbelegt
Warum das hier steht und nicht als Merkzettel: **wer eine Plattform anhand dieser Tabelle wählt, wählt zu acht Zehnteln anhand unbelegter Angaben.** Die zwei geprüften Zeilen sind zugleich die einzigen, die eine Entscheidung tragen — Betriebssystemprofil und Sprache bestimmen, welche Werkzeugkette, welches Personal und welche Prüfmöglichkeiten überhaupt infrage kommen.
Gegenüberstellung nach einer verbreiteten Marktdarstellung (Dienstleisterbeitrag, abgerufen am 1. September 2026); Spalte „Herkunft“ gegen die AUTOSAR-Dokumente zu Plattformgestaltung und Release-Übersicht R25-11 geprüft. Keine fremde Grafik übernommen.
Wo die Rechnung kippt
Abseits der Straße gilt eine andere Arithmetik
AUTOSAR beschreibt seine Arbeit als für Automotive-Anwendungen entwickelt und öffnet sich seit 2016 ausdrücklich auch für anderes. Darunter bleibt die Rechnung trotzdem eine PKW-Rechnung: hohe Stückzahlen, über die sich Lizenzen und Werkzeugketten verteilen. Das ist meine These; AUTOSAR sagt es nirgends. Abseits der Strasse kippt sie. Kleine Serien, lange Lebensdauer, viele Varianten, und eine Regulierung, die anders schneidet. Traktoren, Anhänger und gezogene Geräte (die Klassen T, R und S) fallen nicht unter UN R155. R156 dagegen nennt sie ausdrücklich: M, N, O, R, S und T, sofern das Fahrzeug Software-Updates zulässt. Zusätzlich greift der Cyber Resilience Act, und für Land- und Forstmaschinen ist die Reihe ISO 25119 einschlägig, nicht ISO 26262. Wer die PKW-Arithmetik hierher überträgt, kauft eine Plattform, deren Stückzahl sie nie einspielt, und begründet den Kauf oft mit einer Regelung, die für diese Fahrzeuge gar nicht greift.
Quellen: UN-Regelungen R155 und R156 (UNECE); Cyber Resilience Act (EU) 2024/2847, Anwendung 11.12.2027, Meldepflichten ab 11.09.2026; Maschinenverordnung (EU) 2023/1230 Art. 2(2)(i), Anwendung ab 20.01.2027; Reihe ISO 25119; AUTOSAR R25-11 Standarddokumente (Disclaimer) und „Openness for non-Automotive Applications“ (seit 2016). Wortlaut R156, Abschnitt 1: „This Regulation applies to vehicles of Categories M, N, O, R, S and T that permit software updates.“
Wo KI hilft
KI erzeugt Evidenz. Entscheiden tut ein Mensch.
Der Engpass ist nicht das Urteil, sondern die Bestandsaufnahme: die Artefakte sind da, aber niemand liest sie in vertretbarer Zeit. Genau dort hilft KI — und nur dort.
Bestände lesen
Konfigurationen, Spezifikationen, Anforderungen und Lieferantenverträge gegen den tatsächlichen Bedarf halten – in Tagen statt Quartalen.
Die reale Variantenmatrix ziehen
Aus vorhandenen Artefakten herausziehen, welche Varianten es wirklich gibt – statt sie im Workshop zu schätzen.
Unterschrieben wird von einem Menschen. Wo ein Agent überhaupt schreiben darf und was dann zusätzlich wahr sein muss, steht als Regel im Plattform-Regelwerk (§ 4) — vier Zonen, nach Prüfbarkeit getrennt. Die Bestandsanalyse läuft als Auftrag auf Ihrer Infrastruktur; Verträge und Preise verlassen Ihr Haus nicht.
Quellen: Produktankündigungen der Werkzeughersteller 2026 (Testumgebung mit KI-Paket, 08/2026; KI-Assistent auf einer für funktionale Sicherheit zertifizierten Plattform; Integrationsautomatisierung); Konfiguration per Sprachmodell nach Veröffentlichungsstand (IEEE, ATLAS); Grenzen nach ISO 26262-8 (Vertrauensniveau von Werkzeugen) und ISO/PAS 8800 (KI im Produkt, nicht im Werkzeug).
Lücken, Chancen, KI
Wo es klemmt, und was jetzt möglich wird
Wer ein Feld führt, benennt seine Bruchstellen. Vier davon, als Haltung.
Die Werkzeugketten lassen Lücken
Bei der adaptiven Plattform ist die Komplexität von der Integration in die Verständlichkeit gewandert: Industrieforschung von 2026 beschreibt Entwickler, die das Verhalten ihres Anbieters rückwärts nachbauen. Als Reibungspunkte stehen dort die Bindung an den Anbieter und das Gewicht der Konfigurationsdateien. Wo die Kette reisst, entsteht Handarbeit — und Handarbeit skaliert nicht über Varianten.
Die Lizenzmodelle passen nicht mehr zur Architektur
Die Lizenzmodelle stammen aus einer Welt fester Steuergeräte; die Architektur ist dienstorientiert geworden. Seit dem 27. November 2025 trägt auch die klassische Plattform dienstorientierte Kommunikation über DDS. Die Trennlinie, an der viele Verträge geschnitten sind, verläuft technisch nicht mehr dort. Wer das im Vertrag nicht auflöst, bezahlt die Architektur zweimal.
Quelloffene Bausteine werden reif
Offen bauen ist protokollseitig real und plattformseitig nicht. In der Landtechnik läuft mit AgIsoStack++ ein lebendiger offener ISOBUS-Stack unter MIT-Lizenz. Für die klassische Basissoftware und die adaptive Plattform gibt es keine vollständige, serienreife und nachweislich konforme quelloffene Umsetzung. Bewegung gibt es trotzdem, und sie läuft in eine Richtung, die man erst beim zweiten Hinsehen versteht. Eclipse OpenBSW ist lebendig, darf AUTOSARs Basissoftware und Laufzeitumgebung aus Lizenzgründen aber gar nicht enthalten. Statt ara::* baut Eclipse S-CORE bewusst eine eigene Schnittstellenwelt. Und seit dem 20. August 2026 liegt mit CAPI 1.0 eine adaptive Umsetzung der fünfzehn Functional Clusters des Kerns offen auf GitHub, auf Stand der adaptiven Fassung R20-11, unter AUTOSARs eigenem Vermerk „for informational purposes only“. Einsehen darf sie jeder, verwenden nur, wer die Lizenz hat. Der Zaun steht, wo er stand; neu ist nur, dass man hindurchsehen kann. Wie weit die Lücke reicht, zeigt die grösste von der Gemeinschaft kuratierte Embedded-Liste: 9.063 Sterne, zuletzt im August 2026 gepflegt — und darin null Treffer für ISO 26262, null für MISRA, null für ASIL. Der Abschnitt „Automotive“ umfasst vier Einträge; die beiden AUTOSAR-Einträge nennen sich selbst Beispiel und Lernumgebung. Nicht jeder Baustein braucht einen Lizenzvertrag. Aber jeder braucht jemanden, der ihn verantwortet.
KI verschiebt die Make-or-buy-Grenze
Wenn KI den Eigenbauaufwand senkt, werden Bausteine wieder baubar, die gestern nur zu kaufen waren — nicht alle, und nicht überall. Das ist meine These, und ich kennzeichne sie als solche: belegt ist sie nicht, es gibt dazu nur Herstellerzahlen. Belegt ist, wofür es 2026 Produkte gibt: Test und Integration. Wie breit sie produktiv laufen, ist nicht belegt. Konfiguration per Sprachmodell ist Forschungsstand.
Quellen: Industrieforschung 2026 (Nutzfahrzeughersteller und Hochschule) zur adaptiven Plattform; AUTOSAR CP Release Overview R25-11 (DDS auf der klassischen Plattform, 27.11.2025); Eclipse OpenBSW (Lizenzhinweis zu Basissoftware und Laufzeitschicht); AgIsoStack++ (MIT), Reifegrad geprüft am 31.08.2026.
Lehrfall
Modell, kein KundenfallEine Steuergerätefamilie, vier Fragen, eine Akte
Durchgerechnet an einem Modellvorhaben: kein Unternehmen, keine Marke, keine erfundenen Preise. Vier Steuergeräteklassen, klassisch und dienstorientiert gemischt, mittlere Stückzahl, zwölf Jahre Lebensdauer, ein gewachsener Bestand. Genau die Lage, in der die Entscheidung schwer wird.
Die Architektur
Was wird gebaut, und wie ist es geschnitten?
Die vier Klassen bekommen nicht dieselbe Antwort. Wo hartes Zeitverhalten zählt, bleibt es klassisch; der Hochleistungsrechner wird dienstorientiert; dazwischen steht die Frage, ob die Verbindung ein eigener Baustein ist oder eine Eigenschaft beider Seiten. Der Schnitt entscheidet, was später eine Änderung kostet — nicht die Wahl des Anbieters.
Das Entscheidungsrecht
Wer darf das entscheiden — und wer muss überstimmen können?
Der Teil, den fast niemand aufschreibt, und der die meisten Programme kostet. Nicht jede Entscheidung gehört derselben Stelle: Der Schnitt der Architektur gehört der Architektur, die Wahl des Lieferanten dem Einkauf, die Freigabe der Sicherheit — und keine dieser Stellen darf die andere still überschreiben. Festgehalten wird deshalb je Baustein, wer entscheidet, wer zustimmen muss, wer gehört wird und wer es nur erfährt. Steht das nicht fest, entscheidet am Ende der Terminplan.
Die Altlast
Was wird migriert, was bleibt, was bekommt eine Brücke?
Ein Bestand wird nicht umgestellt, er wird überführt — in Teilen, über Jahre, während er weiterläuft. Drei Kategorien reichen: was mitgeht, was stehen bleibt bis es ausläuft, und was eine Brücke bekommt, weil es beides überleben muss. Die teuerste Antwort ist die vierte, die niemand ausspricht: alles gleichzeitig. Was der Weg kostet, sagt übrigens keine öffentliche Quelle. Jede Zahl dazu stammt aus Projekten, die niemand offenlegt; prüfbar ist sie damit nicht.
Skalieren im KI-Zeitalter
Was muss architektonisch wahr sein, damit KI hier überhaupt hilft?
KI hilft dort, wo Bestände maschinenlesbar und Entscheidungen nachvollziehbar sind — Konfiguration, Anforderungen, Verträge, Testfälle. Eine Architektur, die das nicht hergibt, wird durch KI nicht schneller, sondern nur unübersichtlicher. Die Grenze regelt § 4 des Regelwerks: geschrieben wird dort, wo eine Maschine widerlegen kann. Wer heute schneidet, schneidet für beides.
Häufige Fragen
Was gefragt wird
Zur Sache: AUTOSAR, Stand 2026
Nein – Traktoren, Anhänger und gezogene Geräte sind vom Anwendungsbereich der R155 nicht erfasst. Drei Vorbehalte gehören aber dazu: R156 für Software-Updates nennt genau diese Fahrzeugklassen ausdrücklich; der Cyber Resilience Act erfasst Landmaschinen ab dem 11. Dezember 2027 vollständig, mit Meldepflichten schon ab dem 11. September 2026; und die Branche baut mit ISO 24882 einen darauf abgestimmten Cybersicherheitsstandard für den Off-Road-Bereich: seit Oktober 2025 als Entwurf im Umlauf, die Abstimmung darüber ist im September 2026 abgeschlossen, und als Norm veröffentlicht ist er nicht. Wer heute Architektur entscheidet, entscheidet für das Regime des Cyber Resilience Act, nicht für Ruhe.
Für Land- und Forstmaschinen ist die Reihe ISO 25119 einschlägig, abgeleitet aus IEC 61508 und kompakter als ISO 26262. Gerechnet wird in AgPL von QM bis e und dem daraus abgeleiteten SRL – nicht in ASIL. ISO 26262 wird dort relevant, wo Straßenzulassung ins Spiel kommt: ein Hersteller hat seine Off-Highway-Steuergerätefamilie eigens dafür zusätzlich nach ISO 26262 zertifizieren lassen. Wer die beiden Welten verwechselt, plant den falschen Nachweis ein – und merkt es spät.
Die Spezifikationen sind einsehbar, die kommerzielle Verwertung braucht eine Lizenz – der Weg dorthin ist die Partnerschaft, ab 10.000 Euro im Jahr für kleine Firmen. Wie weit dieser Zaun reicht, zeigt das offene Basissoftware-Projekt der Eclipse Foundation: Basissoftware und Laufzeitschicht des Standards sind dort aus Lizenzgründen ausdrücklich ausgeschlossen. Einen lebendigen offenen klassischen Stack gibt es nicht. Die Lizenz verbietet Ihnen die eigene Umsetzung nicht; sie verlangt die Partnerschaft, und danach kostet sie die Arbeit. Praktisch heißt konform zum Standard deshalb fast immer kaufen, und offen bauen heißt außerhalb der Konformität bauen – zwei Entscheidungen, die oft als eine behandelt werden.
Die Koexistenz ist vorgesehen, nicht geduldet: der gemeinsame Unterbau erzwingt Interoperabilität, die Fassung vom November 2025 stärkt das Zusammenspiel beider Seiten ausdrücklich, und die dienstorientierte Kommunikation auf der klassischen Plattform übernimmt die Diensterkennung der adaptiven, damit beide zusammenpassen. Die adaptive Plattform ersetzt die klassische nicht; die klassische bleibt, wo harter Determinismus zählt. Was es nicht gibt, sind öffentlich bezifferte Migrationskosten. Wer Ihnen eine Zahl nennt, ohne die Datenbasis dazu zu öffnen, nennt eine Schätzung, die Sie nicht prüfen können.
Als Produkt nein, als Forschung ja – Stand August 2026. Lieferbar sind KI-Agenten für Test und Integration: eine Testumgebung mit KI-Paket, ein Assistent auf einer für funktionale Sicherheit zertifizierten Plattform. Dass es die Produkte gibt, ist belegt; wie breit sie laufen, nicht. Konfigurationsdateien per Sprachmodell zu erzeugen ist dagegen Veröffentlichungsstand, kein lieferbares Werkzeug. Wo ein Agent überhaupt schreiben darf, regelt § 4 des Regelwerks – nach Prüfbarkeit, nicht nach Zutrauen.
In realen Programmen bestehen beide nebeneinander. Ein separates Gateway ist dabei keine allgemeine Voraussetzung: seit R25-11 trägt auch die klassische Plattform DDS und eine auf die adaptive Plattform abgestimmte Diensterkennung. Wo Protokolle, Datenmodelle, Netze oder Sicherheitsgrenzen auseinanderlaufen, bleibt ein Gateway sinnvoll oder notwendig. Für die Make-or-buy-Frage heisst das: sie stellt sich doppelt, weil Bausteine, Lieferanten und Kompetenzen der beiden Welten sich kaum überschneiden — nicht, weil zwingend etwas dazwischen steht.
Jede Antwort dieses Abschnitts ruht auf einer datierten Primärquelle: den AUTOSAR-Dokumenten der Fassung R25-11, den UN-Regelungen R155 und R156, dem Cyber Resilience Act (EU) 2024/2847 und der Reihe ISO 25119.
Zur Zusammenarbeit
Oft ist Kaufen richtig – für die Basis fast immer. Die teuren Fehler liegen eine Ebene höher: gekauft, was das Haus dauerhaft können muss, oder selbst gebaut, was ein Anbieter für viele Kunden pflegt. Die Antwort fällt je Baustein anders aus, und sie ändert sich mit jeder Variante. Deshalb eine Matrix, keine Grundsatzentscheidung.
Sie kann große Bestände lesen: Konfigurationen, Anforderungen, Verträge – und daraus die reale Variantenmatrix und eine belegte Vorlage ziehen. Sie kann nicht entscheiden, was das Haus können muss und was es kaufen darf: das ist eine Frage von Strategie und Verantwortung, und darunter steht am Ende eine Unterschrift, keine Ausgabe.
Aus Ihrem Bestand: Verträge, Angebote, Aufwandsdaten, Personalstand. Jede Zeile der Akte zeigt auf ihr Artefakt. Wo eine Zahl geschätzt ist, steht sie als Schätzung darin – eine Akte, die Modellwerte als Messwerte ausgibt, wäre wertlos.
Nein. Ich verkaufe keinen Baustein und bekomme von keinem Anbieter etwas – deshalb kann die Akte je Baustein auch Kaufen empfehlen, und tut es oft. Was ich liefere, ist die Entscheidung zwischen den Wegen, belegt und unterschreibbar.
Nein, und das ist der Punkt. Den Stack konfigurieren Ihre Spezialisten oder der Anbieter. Bei mir liegt die Führung: die Landschaft vollständig kennen, die Entscheidung systematisieren und sie verantworten – als Chief Product Owner, Head of Engineering oder Plattformverantwortlicher auf Zeit. Die schweren Fehler in diesen Programmen sind selten Konfigurationsfehler. Es sind Entscheidungsfehler.
Nein. Zulassungen und Normprüfungen liegen bei den Prüfstellen und Ihren Fachleuten dafür; ich nenne keine Norm, für die ich keinen Nachweis führe. Was die Akte beiträgt: sie macht sichtbar, wer welchen Nachweis liefert und pflegt – das ist eine der Dimensionen der Matrix.