AUTOSAR Classic oder Adaptive: welche Plattform zu eurem Steuergerät passt
Die eine bindet alles beim Integrieren, die andere erst beim Ausführen. Aus diesem einen Unterschied folgt fast alles andere, von der Hardware bis zum Entwicklungsablauf.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Frage wird als Nachfolge gestellt, ist aber keine
Die verbreitetste Fehlannahme lautet, die Adaptive Platform löse die Classic Platform ab. Das tut sie nicht. Beide Standards werden im selben Rhythmus weiterentwickelt und in derselben Freigabe veröffentlicht, zuletzt als Release R25-11 vom 27. November 2025, und in dieser Freigabe hat ausgerechnet die Classic Platform beim Kommunikationsprotokoll DDS nachgelegt, das viele weiterhin der Adaptive-Seite zuordnen: Die Verwaltungsfunktionen für Ereignisse, Methoden und Felder laufen dort jetzt auch über DDS, während das Protokoll selbst der Classic Platform schon seit R22-11 zur Verfügung steht. Wer die Frage als Generationswechsel behandelt, plant an der Architektur vorbei.
Teuer wird die Entscheidung in beide Richtungen. Wer eine Funktion mit harten Fristen und wenigen Kilobyte Speicher auf die Adaptive Platform legt, kämpft gegen eine Plattform, die für andere Zwecke entworfen wurde: Prozesse, dynamisches Binden und ein POSIX-Betriebssystem sind für eine Regelung im Millisekundenraster kein Gewinn, sondern Ballast. Wer umgekehrt eine Funktion, die im Feld einzeln aktualisiert werden soll, in die Classic Platform legt, hat sich für die gesamte Laufzeit des Fahrzeugs auf ein Update des kompletten Images festgelegt.
Die eigentliche Frage ist deshalb nicht, welche Plattform moderner ist, sondern: Welche Fristen muss diese Funktion einhalten, welche Rechenleistung und welche Anbindung braucht sie, wie oft und wie fein muss sie im Feld verändert werden können, und welchen Nachweis verlangt eure Sicherheitsabteilung dafür? Aus diesen vier Antworten ergibt sich die Zuordnung, und sie fällt pro Steuergerät und nicht pro Fahrzeug.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Beide Plattformen an denselben Kriterien
Beide sind Teil desselben Standards und werden gemeinsam freigegeben, ergänzt um den Foundation-Standard, der die Gemeinsamkeiten zwischen ihnen festhält. Verglichen wird deshalb nicht alt gegen neu, sondern zwei Entwürfe für unterschiedliche Aufgaben.
Classic Platform
Anwendung, Laufzeitumgebung und Basissoftware auf einem Mikrocontroller, vollständig zur Integrationszeit konfiguriert
Adaptive Platform
Anwendungen als eigene Prozesse auf einem POSIX-Betriebssystem, Dienste werden zur Laufzeit gebunden
| Entscheidungsfrage | Classic Platform | Adaptive Platform |
|---|---|---|
| Wie vorhersagbar ist das Zeitverhalten? | Stärke Tasks laufen bis zum Ende durch, ihre Anzahl und Priorität stehen zur Übersetzungszeit fest, und es gibt keine dynamische Speicheranforderung im Betrieb. Für eine Regelung, eine Zündung oder eine Bremsfunktion ist das die Eigenschaft, auf die es ankommt, und sie lässt sich gegenüber einer Prüfstelle auch belegen. | Kommt darauf an Ein POSIX-Betriebssystem mit mehreren Prozessen bringt Scheduler, Speicherverwaltung und Interprozesskommunikation mit, und damit Schwankungen, die es in der Classic-Welt nicht gibt. Der Standard sieht ausdrücklich vor, dass der Integrator die dynamischen Anteile über die Manifeste begrenzt, damit eine Sicherheitsqualifizierung möglich bleibt. |
| Wann wird festgelegt, wer mit wem spricht? | Kommt darauf an Alles wird beim Integrieren gebunden. Aus den Beschreibungsdateien erzeugen Generatoren die Laufzeitumgebung und die Konfiguration der Basissoftware, danach steht die Verschaltung fest. Das macht den Nachweis einfach und jede spätere Änderung zu einem neuen Bau des gesamten Images. | Stärke Ein Client sucht seinen Dienst zur Laufzeit und wird dynamisch mit ihm verbunden. Das erlaubt es, Funktionen einzeln nachzuladen und Steuergeräte im Netz auszutauschen, ohne alle anderen neu zu bauen, und verlagert dafür Testaufwand von der Integration in den Betrieb. |
| Welche Hardware setzt die Plattform voraus? | Stärke Ein Mikrocontroller genügt, in vielen Fällen mit wenigen hundert Kilobyte Flash. Das hält die Stückkosten niedrig, erlaubt kurze Kaltstartzeiten und ist der Grund, warum die überwiegende Zahl der Steuergeräte in einem Fahrzeug so gebaut ist. | Schwäche Es braucht einen Prozessor mit Speicherverwaltungseinheit, ein mehrprozessfähiges POSIX-Betriebssystem, deutlich mehr Arbeitsspeicher und in der Regel eine Ethernet-Anbindung. Das ist für ein zentrales Rechenmodul richtig dimensioniert und für ein Türsteuergerät weit daneben. |
| Wie gut lässt sich die Funktion im Feld aktualisieren? | Schwäche Aktualisiert wird das gesamte Image des Steuergeräts, meistens über die Diagnoseschnittstelle und mit einem definierten Fahrzeugzustand. Für eine Fehlerbehebung reicht das aus, für Funktionen, die sich über die Fahrzeuglebensdauer weiterentwickeln sollen, ist es eine schwere Fessel. | Stärke Einzelne Anwendungen lassen sich nachladen, ersetzen und wieder entfernen, und der Standard sieht dafür eine eigene Verwaltung vor. Genau das brauchen Funktionen, die im Feld weiterentwickelt werden, und genau darauf zielen auch die Anforderungen an ein Software-Update-Managementsystem aus der Fahrzeugregulierung. |
| Wie kommunizieren Komponenten miteinander? | Kommt darauf an Über den virtuellen Funktionsbus und die Laufzeitumgebung, die Ports auf Signale abbildet und dabei nicht unterscheidet, ob der Empfänger auf demselben Steuergerät oder am anderen Ende von CAN, LIN oder FlexRay sitzt. DDS steht der Classic Platform bereits seit dem Release R22-11 zur Verfügung, und seit R25-11 laufen auch die Verwaltungsfunktionen für Ereignisse, Methoden und Felder darüber. | Stärke Dienstorientiert über die Kommunikationsverwaltung der Laufzeitumgebung, mit SOME/IP samt Dienstsuche, mit DDS und mit einer kopierfreien Interprozesskommunikation auf demselben Rechner. Für Diagnose stehen DoIP nach ISO 13400-2, UDS nach ISO 14229-1 und SOVD bereit. |
| Welche Sprache und welches Regelwerk gelten? | Stärke C, mit MISRA C als etabliertem Regelwerk, qualifizierten Compilern für die verbreiteten Mikrocontroller-Architekturen und einer breiten Erfahrungsbasis bei Zulieferern und Prüfstellen. Wer Personal sucht, sucht in einem eingespielten Markt. | Kommt darauf an C++, mit den C++ Core Guidelines als Bezugspunkt der Standardisierung; die früheren AUTOSAR-C++14-Richtlinien sind inzwischen in MISRA C++:2023 aufgegangen. Der Kreis der Leute, die C++ und Fahrzeugtechnik gleichzeitig mitbringen, ist deutlich kleiner als auf der C-Seite. |
Wie vorhersagbar ist das Zeitverhalten?
Tasks laufen bis zum Ende durch, ihre Anzahl und Priorität stehen zur Übersetzungszeit fest, und es gibt keine dynamische Speicheranforderung im Betrieb. Für eine Regelung, eine Zündung oder eine Bremsfunktion ist das die Eigenschaft, auf die es ankommt, und sie lässt sich gegenüber einer Prüfstelle auch belegen.
Ein POSIX-Betriebssystem mit mehreren Prozessen bringt Scheduler, Speicherverwaltung und Interprozesskommunikation mit, und damit Schwankungen, die es in der Classic-Welt nicht gibt. Der Standard sieht ausdrücklich vor, dass der Integrator die dynamischen Anteile über die Manifeste begrenzt, damit eine Sicherheitsqualifizierung möglich bleibt.
Wann wird festgelegt, wer mit wem spricht?
Alles wird beim Integrieren gebunden. Aus den Beschreibungsdateien erzeugen Generatoren die Laufzeitumgebung und die Konfiguration der Basissoftware, danach steht die Verschaltung fest. Das macht den Nachweis einfach und jede spätere Änderung zu einem neuen Bau des gesamten Images.
Ein Client sucht seinen Dienst zur Laufzeit und wird dynamisch mit ihm verbunden. Das erlaubt es, Funktionen einzeln nachzuladen und Steuergeräte im Netz auszutauschen, ohne alle anderen neu zu bauen, und verlagert dafür Testaufwand von der Integration in den Betrieb.
Welche Hardware setzt die Plattform voraus?
Ein Mikrocontroller genügt, in vielen Fällen mit wenigen hundert Kilobyte Flash. Das hält die Stückkosten niedrig, erlaubt kurze Kaltstartzeiten und ist der Grund, warum die überwiegende Zahl der Steuergeräte in einem Fahrzeug so gebaut ist.
Es braucht einen Prozessor mit Speicherverwaltungseinheit, ein mehrprozessfähiges POSIX-Betriebssystem, deutlich mehr Arbeitsspeicher und in der Regel eine Ethernet-Anbindung. Das ist für ein zentrales Rechenmodul richtig dimensioniert und für ein Türsteuergerät weit daneben.
Wie gut lässt sich die Funktion im Feld aktualisieren?
Aktualisiert wird das gesamte Image des Steuergeräts, meistens über die Diagnoseschnittstelle und mit einem definierten Fahrzeugzustand. Für eine Fehlerbehebung reicht das aus, für Funktionen, die sich über die Fahrzeuglebensdauer weiterentwickeln sollen, ist es eine schwere Fessel.
Einzelne Anwendungen lassen sich nachladen, ersetzen und wieder entfernen, und der Standard sieht dafür eine eigene Verwaltung vor. Genau das brauchen Funktionen, die im Feld weiterentwickelt werden, und genau darauf zielen auch die Anforderungen an ein Software-Update-Managementsystem aus der Fahrzeugregulierung.
Wie kommunizieren Komponenten miteinander?
Über den virtuellen Funktionsbus und die Laufzeitumgebung, die Ports auf Signale abbildet und dabei nicht unterscheidet, ob der Empfänger auf demselben Steuergerät oder am anderen Ende von CAN, LIN oder FlexRay sitzt. DDS steht der Classic Platform bereits seit dem Release R22-11 zur Verfügung, und seit R25-11 laufen auch die Verwaltungsfunktionen für Ereignisse, Methoden und Felder darüber.
Dienstorientiert über die Kommunikationsverwaltung der Laufzeitumgebung, mit SOME/IP samt Dienstsuche, mit DDS und mit einer kopierfreien Interprozesskommunikation auf demselben Rechner. Für Diagnose stehen DoIP nach ISO 13400-2, UDS nach ISO 14229-1 und SOVD bereit.
Welche Sprache und welches Regelwerk gelten?
C, mit MISRA C als etabliertem Regelwerk, qualifizierten Compilern für die verbreiteten Mikrocontroller-Architekturen und einer breiten Erfahrungsbasis bei Zulieferern und Prüfstellen. Wer Personal sucht, sucht in einem eingespielten Markt.
C++, mit den C++ Core Guidelines als Bezugspunkt der Standardisierung; die früheren AUTOSAR-C++14-Richtlinien sind inzwischen in MISRA C++:2023 aufgegangen. Der Kreis der Leute, die C++ und Fahrzeugtechnik gleichzeitig mitbringen, ist deutlich kleiner als auf der C-Seite.
Was passt wann
- Wenn die Funktion harte Fristen einhalten muss, auf einem Mikrocontroller läuft und über CAN oder LIN angebunden ist
- bleibt bei der Classic Platform und steckt den Aufwand in die Konfiguration und in die Nachweisführung, nicht in einen Plattformwechsel.
- Wenn die Funktion viel Rechenleistung braucht, über Ethernet spricht und im Feld einzeln aktualisiert werden soll
- nehmt die Adaptive Platform und plant den Aufbau von C++- und POSIX-Wissen als eigenen Posten ein, statt ihn nebenher zu hoffen.
- Wenn beides zutrifft, weil das Steuergerät sowohl eine Regelung als auch eine vernetzte Funktion enthält
- trennt die Aufgaben auf zwei Ausführungsumgebungen und definiert die Schnittstelle dazwischen früh, statt eine Plattform gegen ihren Entwurf zu benutzen.
Fünf Fragen, und die Plattform steht
- 01 Welche Frist muss die Funktion einhalten und wie eng ist die Schwankung erlaubt?
- 02 Steht ein Mikrocontroller oder ein Prozessor mit Speicherverwaltungseinheit zur Verfügung?
- 03 Muss diese Funktion im Feld einzeln nachgeladen werden können?
- 04 Kommuniziert sie signalbasiert über CAN oder dienstbasiert über Ethernet?
- 05 Wer schreibt den Code, ein C-Team mit MISRA-Erfahrung oder ein C++-Team?
Was danach begründbar auf dem Tisch liegt
Die Zuordnung folgt sechs Prüfungen, die sich am Lastenheft, am Datenblatt der Zielhardware und an der Update-Strategie beantworten lassen. Sie ersetzen die Diskussion darüber, welche Plattform zukunftsfähiger sei.
Das Ausführungsmodell auseinanderhalten
Du kannst benennen, warum die Classic Platform mit Tasks arbeitet, die bis zum Ende durchlaufen, und die Adaptive Platform mit Prozessen, die ein Betriebssystem verwaltet, und was daraus für die Vorhersagbarkeit folgt.
Erkennen, wann etwas gebunden wird
In der Classic Platform legt der Integrationsschritt fest, wer mit wem spricht; in der Adaptive Platform findet ein Client seinen Dienst zur Laufzeit. Dieser Unterschied entscheidet über Werkzeugkette, Testaufwand und Nachweisführung.
Die Hardwareanforderung ehrlich ableiten
Du weißt, warum die Adaptive Platform einen Prozessor mit Speicherverwaltungseinheit und ein mehrprozessfähiges Betriebssystem voraussetzt, und was das für Stückkosten, Verlustleistung und Kaltstartzeit bedeutet.
Die Updatefrage nach vorne ziehen
Ob eine Funktion im Feld einzeln nachgeladen werden muss, entscheidet die Plattformwahl mit, und diese Anforderung kommt nicht nur aus dem Produktmanagement, sondern inzwischen auch aus der Regulierung.
Sprache und Regelwerk mitdenken
Die Classic Platform ist eine C-Welt mit MISRA C, die Adaptive Platform eine C++-Welt mit C++ Core Guidelines und MISRA C++. Das ist kein Detail am Rand, sondern die Frage, wer den Code später schreibt und prüft.
Den Übergang zwischen beiden planen
Beide Plattformen sprechen über gemeinsame Protokolle miteinander. Du weißt, welche das sind und an welcher Stelle im Fahrzeugnetz die Grenze verläuft.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was die Classic Platform tatsächlich ist
Die Architektur unterscheidet auf oberster Ebene drei Schichten, die auf einem Mikrocontroller laufen: die Anwendungsschicht, die Laufzeitumgebung und die Basissoftware. Die Anwendungsschicht ist weitgehend hardwareunabhängig. Die Basissoftware ist wiederum dreigeteilt in Dienste, Steuergeräte-Abstraktion und Mikrocontroller-Abstraktion, dazu kommen die komplexen Treiber für alles, was sich in dieses Raster nicht fügt. Die Dienste gliedern sich weiter in System-, Speicher- und Kommunikationsdienste. Diese Aufteilung ist kein Selbstzweck: Sie ist der Grund, warum sich eine Anwendungskomponente ohne Kenntnis der verbauten Hardware entwickeln und später auf ein anderes Steuergerät verschieben lässt.
Der zweite tragende Gedanke ist der virtuelle Funktionsbus. Anwendungskomponenten kommunizieren über Ports und wissen nicht, ob der Kommunikationspartner auf demselben Steuergerät sitzt oder am anderen Ende eines Busses. Die Laufzeitumgebung ist die Umsetzung dieses Bildes für ein konkretes Gerät, und sie wird nicht von Hand geschrieben, sondern erzeugt. Ausgangspunkt sind Beschreibungsdateien im AUTOSAR-Austauschformat, aus denen Werkzeuge die Laufzeitumgebung und die Konfiguration der Basissoftware ableiten.
Daraus folgt die entscheidende Eigenschaft: Zum Zeitpunkt des Bauens steht alles fest. Wie viele Tasks es gibt, welche Priorität sie haben, welches Signal auf welchem Bus liegt, wie groß jeder Puffer ist. Es gibt keine dynamische Speicheranforderung im Betrieb und keine Überraschung zur Laufzeit. Genau deshalb ist diese Plattform für sicherheitsgerichtete Funktionen die naheliegende Wahl, und genau deshalb ist jede spätere Änderung ein neuer Bau des ganzen Images.
Was die Adaptive Platform anders macht
Die Adaptive Platform stellt die Laufzeitumgebung für adaptive Anwendungen bereit, kurz ARA. Sie besteht aus funktionalen Clustern, die entweder als Dienste im Fahrzeugnetz verteilt sein können oder als Basis mindestens einmal je Maschine vorhanden sein müssen. Anwendungen sind hier keine übersetzten Quelldateien in einem gemeinsamen Image, sondern eigenständige Prozesse mit einem oder mehreren Threads, deren Start, Zustand und Ende von einer eigenen Ausführungsverwaltung gesteuert werden.
Am Betriebssystem hängt der zweite große Unterschied. Adaptive Anwendungen sind auf die PSE51-Schnittstelle festgelegt, ein Einzelprozessprofil des POSIX-Standards, das der Portierbarkeit dient und dafür sorgt, dass Anwendungen sich nicht gegenseitig stören. Die C++-Standardbibliothek gehört zur Laufzeitumgebung dazu; der Standard weist ausdrücklich darauf hin, dass ihre Threading-Schnittstelle und die native PSE51-Schnittstelle besser nicht vermischt werden. Das darunterliegende Betriebssystem selbst muss mehrere Prozesse verwalten können, was der wesentliche Grund für die höhere Hardwareanforderung ist.
Konfiguriert wird nicht beim Übersetzen, sondern über Manifeste, die zum ausführbaren Code gehören. Das Ausführungsmanifest legt fest, wie eine Anwendung gestartet wird und in welchen Grenzen sie sich bewegen darf; das Dienst-Instanz-Manifest beschreibt, welche Dienste sie anbietet und sucht; das Maschinenmanifest beschreibt die Zielumgebung. Der Standard bezeichnet das als geplante Dynamik: Nachladen und Umverdrahten sind vorgesehen, aber der Integrator schränkt die zulässigen Freiheitsgrade so weit ein, dass eine Sicherheitsqualifizierung möglich bleibt. Wer die Adaptive Platform für eine völlig offene Anwendungsplattform hält, hat diesen Punkt überlesen.
Die Frage ist selten ein Entweder-oder
In einem heutigen Fahrzeug stehen beide Plattformen nebeneinander, und die Grenze verläuft entlang der Rechenarchitektur. Zentrale Rechenmodule und Domänenrechner für Fahrerassistenz, Konnektivität oder Infotainment tragen die Adaptive Platform; die Steuergeräte in den Zonen und an den Aktoren tragen die Classic Platform. Der Foundation-Standard sorgt dafür, dass beide Seiten dieselben Protokolle und dieselben gemeinsamen Anforderungen verwenden, und die Methodik ist inzwischen für beide Plattformen zusammengeführt.
Das gemeinsame Protokoll ist SOME/IP samt Dienstsuche, das auf beiden Seiten unterstützt wird. Auf der Classic Platform ist mit dem Release R25-11 zusätzlich DDS hinzugekommen, sodass die Verwaltungsfunktionen für Ereignisse, Methoden und Felder dort nicht mehr nur über SOME/IP laufen. Für die Zeitsynchronisierung dient in beiden Welten das Verfahren nach IEEE 802.1AS, das AUTOSAR um ein eigenes Profil ergänzt. Die Plattformen wachsen an den Rändern also aufeinander zu, ohne dass eine die andere ersetzt.
Praktisch heißt das für die Planung: Die Zuordnung fällt je Funktion, nicht je Fahrzeugprojekt, und sie fällt früh, weil sie die Hardwareauswahl bestimmt. Eine Funktion nachträglich von der einen auf die andere Plattform zu ziehen bedeutet nicht, Code zu portieren, sondern ihn neu zu schreiben, in einer anderen Sprache, gegen andere Schnittstellen und mit einem anderen Nachweis.
Sicherheit, Zulassung und was die Regulierung verlangt
Für die funktionale Sicherheit gilt in beiden Welten ISO 26262 in der Fassung von 2018, die in zwölf Teile gegliedert ist. Teil 6 behandelt die Entwicklung der Software, Teil 8 die unterstützenden Prozesse und darin die Qualifizierung eingesetzter Werkzeuge. Die Einstufung einer Funktion erfolgt über eine Gefährdungs- und Risikoanalyse und mündet in eine der Stufen von A bis D. Die Stufe entscheidet darüber, welche Nachweise ihr für Methodik, Werkzeuge und Prüftiefe erbringen müsst, und sie ist der Grund, warum die statische Konfiguration der Classic Platform im sicherheitsgerichteten Bereich so beliebt ist: Was zur Integrationszeit feststeht, muss zur Laufzeit nicht nachgewiesen werden.
Die zweite Anforderung kommt aus der Fahrzeugzulassung. Die UN-Regelungen R155 und R156 verlangen für die Typgenehmigung ein zertifiziertes Managementsystem für Cybersicherheit und eines für Software-Updates. Die technische Umsetzung der Sicherheitsanforderungen wird üblicherweise über ISO/SAE 21434 geführt. Für die Plattformwahl ist vor allem R156 relevant: Wenn ein Fahrzeug über die Lebensdauer aktualisiert werden soll, braucht es dafür einen belegbaren Prozess, und eine Plattform, die das Nachladen einzelner Anwendungen vorsieht, macht diesen Nachweis einfacher als eine, bei der jedes Update ein vollständiges Image ist.
Beide Anforderungen zusammen erklären, warum die Architekturdiskussion in den letzten Jahren so stark in Richtung zentraler Rechenmodule gegangen ist. Es geht nicht in erster Linie um Rechenleistung, sondern darum, an wie vielen Stellen im Fahrzeug ihr die Software über zehn Jahre hinweg noch verändern könnt, ohne jedes Mal alles anzufassen.
Was der Umstieg das Team kostet
Der offensichtliche Posten ist die Sprache. Von C nach C++ ist kein Syntaxwechsel, sondern ein Wechsel der Denkweise: Ressourcen an Objektlebensdauern binden, Fehler über Rückgabetypen führen statt über globale Zustandsvariablen, Templates und Bibliotheken einsetzen statt alles selbst zu schreiben. Rechnet für Leute, die aus der Classic-Welt kommen, mit mehreren Wochen echter Arbeit, bis sie im Stil des Projekts schreiben, und plant mindestens zwei Personen gleichzeitig ein, damit das Wissen nicht an einer einzigen Person hängt.
Der zweite Posten wird regelmäßig unterschätzt: das Betriebssystem. Wer bisher mit einer statischen Taskliste gearbeitet hat, trifft nun auf Prozesse, Dateisysteme, Signale, Interprozesskommunikation, Zugriffsrechte und einen Scheduler, den man konfigurieren muss statt zu erzeugen. Dazu kommt die Fehlersuche in einem Netz: Wenn ein Client seinen Dienst nicht findet, liegt die Ursache in der Dienstsuche, in einer Firewall-Regel, in einem falschen Manifest oder in der Zeitsynchronisierung, und keines dieser Bilder kennt man aus der CAN-Welt.
Der dritte Posten ist die Werkzeugkette. Auf der Classic-Seite kauft ihr einen Basissoftware-Stack samt Konfigurationswerkzeug bei einem Zulieferer und arbeitet in dessen Ablauf. Auf der Adaptive-Seite kommen ein Betriebssystem, eine Umsetzung der Laufzeitumgebung, ein Build-Werkzeug für C++, eine Verwaltung der Manifeste und die Werkzeuge zur Beobachtung im Betrieb zusammen, oft von verschiedenen Anbietern. Diese Auswahl ist eine eigene Projektphase, und sie sollte abgeschlossen sein, bevor die erste Funktion entsteht.
Dazu passende Kurse
Wer die Zuordnung nicht am Papier, sondern an Architektur und Werkzeugkette treffen will, findet dafür die AUTOSAR-Schulungen zu beiden Plattformen .
Für Teams, die von der Classic- auf die Adaptive-Seite wechseln, ist der Sprung von C nach C++ der erste echte Aufwand, und dafür gibt es Kurse zu C und C++, wenn erst die Sprachbasis stehen muss .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Löst die Adaptive Platform die Classic Platform ab?
Können wir vorhandenen Classic-Code auf die Adaptive Platform übernehmen?
Braucht die Adaptive Platform zwingend Ethernet?
Welche Sicherheitsstufe erreicht die Adaptive Platform?
Womit fängt jemand an, der beides noch nicht kennt?
Passt thematisch dazu
Der Umstieg kostet vor allem Einarbeitung, und wer abschätzen will, wie viel davon zusammenkommt, findet im Berufsbereich eine Aufstellung dazu, welches Wissen die Arbeit an Steuergeräten voraussetzt .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Plattformfrage mit Leuten klären, die beide Seiten kennen
Ob Architekturüberblick, Classic-Konfiguration oder der Einstieg in die Adaptive Platform: Bei cmt gehst du die Entscheidung an einem Aufbau durch, der eurem Fahrzeugprojekt ähnelt, statt an einem Beispiel aus der Spezifikation.