Automotive-Softwareentwicklung: Worauf Sie bei der Wahl des richtigen Partners achten sollten

Die häufigsten Fehler bei der Lieferantenqualifizierung entstehen nicht durch mangelhafte Ingenieursleistung. Sie entstehen, weil Teams, die hervorragende Unternehmenssoftware entwickeln, in ein OEM-Audit gehen – und davon ausgehen, ihr bestehendes Qualitätsmanagementsystem sei direkt übertragbar. Das ist es nicht.

Die Lücke zwischen allgemeiner Softwarekompetenz und automotive-tauglicher Zertifizierungsreife ist der Punkt, an dem Projekte scheitern – still, kostspielig und meistens beim ASPICE Level 2-Assessment, wenn der Auftraggeber feststellt, dass sein Dienstleister keine nachvollziehbaren Arbeitsergebnisse vorlegen kann.

Bei der Wahl des richtigen Partners für Automotive Softwareentwicklung geht es nicht darum, Portfolios nach ansprechenden Cockpit-Screenshots zu durchsuchen oder LinkedIn-Profile nach Embedded-Engineers zu durchforsten. Es geht darum zu prüfen, ob die Prozessarchitektur eines Anbieters den dokumentarischen und verfahrenstechnischen Anforderungen standhält, die ISO 26262-ASIL-Klassifikationen und die spezifischen Audit-Rahmen deutscher und europäischer OEMs stellen.

Wer regelmäßig an Lieferantenauswahlrunden teilnimmt, erkennt das Muster schnell: Teams, die technische Interviews überzeugend bestehen, scheitern an der Vorlage von Prozessnachweisen. Die Zertifizierungsanforderungen sind 2026 weiter gestiegen – die aktualisierten ASPICE 4.0-Modellanforderungen definieren neu, wie Assessoren Softwareentwicklungspraktiken entlang der gesamten Lieferkette bewerten.

Was einen kompetenten Entwicklungspartner für Automotive Softwareentwicklung von einem qualifizierten unterscheidet, lässt sich auf einige überprüfbare Kriterien reduzieren – von denen keines in einem typischen Lastenheft auftaucht.

Die wichtigsten Erkenntnisse:
– Exzellenz in der allgemeinen Softwareentwicklung bedeutet nicht automatisch Zertifizierungsreife im Automotive-Bereich – prüfen Sie die Prozessreife gesondert.
– Fordern Sie vor der Vorauswahl eines Anbieters Nachweise über abgeschlossene ASPICE Level 2+-Assessments.
– Bewerten Sie die Traceability-Toolchain (Anforderungen → Code → Test) als K.-o.-Kriterium.
– Fragen Sie nach der Bestehensquote bei OEM-Audits – nicht nach Kundenlogos.
– Die ISO 26262-ASIL-Kompetenz muss zur sicherheitskritischen Einstufung Ihres Produkts passen – nicht jeder Anbieter deckt ASIL-C/D ab.
– Setzen Sie das ASPICE 4.0-Modell als Maßstab für Ihre Evaluierungen 2026 an – nicht mehr das veraltete Framework 3.1.

Was umfasst die Entwicklung von Automotive-Software konkret?

Die Entwicklung von Automotive-Software — auf Deutsch oft als Automotive-Softwareentwicklung oder Fahrzeugsoftware-Entwicklung bezeichnet — erstreckt sich über fünf technische Kernbereiche, die jeweils eigene Toolchains, Compliance-Anforderungen und Qualifikationsprofile mitbringen. Wer diese Bereiche pauschal zusammenfasst, scheitert beim Projektscoping — noch bevor die erste Zeile Code geschrieben wurde.

Die fünf Kernbereiche der Automotive-Softwareentwicklung

1. Embedded ECU-Software — Firmware auf elektronischen Steuergeräten, die Antrieb, Bremsen und Fahrwerk regeln. Sie basiert auf AUTOSAR Classic (für bestehende Architekturen) oder AUTOSAR Adaptive (für leistungsstarke Rechenplattformen), wird typischerweise in MISRA-konformem C/C++ geschrieben und läuft auf Echtzeit-Betriebssystemen wie QNX oder VxWorks.

2. ADAS und Sensorfusion-Pipelines — Wahrnehmungssysteme, die Daten aus Lidar, Radar und Kameraanordnungen zu konkreten Fahrentsscheidungen verarbeiten. Dabei kommen ROS 2, TensorRT und CUDA-beschleunigte Inferenz zum Einsatz — mit Latenzbudgets im einstelligen Millisekundenbereich.

3. Infotainment und HMI-Systeme — Fahrerorientierte Oberflächen auf Basis von Android Automotive OS oder Qt/QML-Frameworks. Sie verbinden UX-Design, Sprachsteuerung und App-Integration — und liegen damit näher an Consumer-Software als alle anderen Bereiche dieser Liste.

4. OTA-Update-Infrastruktur — Sichere Over-the-Air-Plattformen für die Firmware-Verteilung in Fahrzeugflotten. Cloud-native Architekturen — häufig auf AWS IoT oder Azure IoT Hub — verwalten Delta-Updates, Rollback-Mechanismen und Kampagnensteuerung für Millionen von Endpunkten.

5. V2X und Telematik-Plattformen — Fahrzeug-zu-Alles-Kommunikationssysteme, die über SOME/IP, MQTT oder CAN-FD Daten zwischen Fahrzeugen, Infrastruktur und Cloud-Backends austauschen.

Die Dimension dieser Aufgabe ist beeindruckend. Laut einer McKinsey-Studie zum Software-definierten Fahrzeug aus dem Jahr 2022 umfassen moderne Fahrzeuge bereits über 100 Millionen Codezeilen — und Software soll bis 2030 rund 45 Prozent des Fahrzeugwertes ausmachen. Diese Entwicklung erklärt, warum OEMs wie Volkswagen, BMW oder Stellantis ihre gesamten Beschaffungsstrategien konsequent auf Software-Kompetenz ausrichten — und nicht mehr allein auf mechanische Fertigungstiefe.

Warum Sicherheitsklassifizierung alles verändert

Hier scheitern die meisten Partnerbewertungen: an einem einheitlichen Compliance-Blick auf alle fünf Bereiche.

Die Funktionalen Sicherheitsstufen nach ISO 26262 reichen von QM (Quality Management — ohne spezifische Sicherheitsanforderungen) bis ASIL-D, der höchsten Integritätsstufe. Sicherheitskritische ECU-Software für Bremsen oder Lenkung erfordert ASIL-B bis ASIL-D. Ein Infotainment-HMI hingegen fällt typischerweise unter QM. Wer beides vermischt, begeht zwei gleich teure Fehler: ein Mediensystem auf Sicherheitsniveau überzertifizieren — mit Zeit- und Budgetverlust — oder einen Bremsregler auf QM-Niveau unterzertifizieren — mit Haftungsrisiko und Rückrufgefahr.

ASPICE ergänzt eine Prozessreifedimension, die orthogonal zur funktionalen Sicherheit verläuft. Ein OEM, der ASPICE Level 2 fordert, interessiert sich nicht primär für die Brillanz Ihrer Entwickler — er prüft, ob Anforderungsverfolgung, Änderungsmanagement und Verifikationsprozesse dokumentiert und reproduzierbar sind. Wir kennen technisch ausgezeichnete Teams, die Lieferantenaudits nicht bestanden haben, weil ihr Git-Workflow nicht auf das Prozessreferenzmodell von ASPICE einzahlte. Sauberer Code kompensiert keine fehlende bidirektionale Traceability zwischen Anforderungen und Testfällen.

Wo Spezial-Know-how gefragt ist — und wo nicht

Wo sollten Sie bei der Partnerwahl die Grenze ziehen?

Nicht jede Automotive- und Mobilitätssoftware erfordert ein Team mit tiefem Fachwissen in funktionaler Sicherheit. Eine erfahrene Full-Stack-Agentur bewältigt API-Integrationen, Fleet-Management-Dashboards, Connected-Car-Cloud-Backends und mobile Begleit-Apps — also die IT-nahe Schicht oberhalb der eingebetteten Fahrzeugsysteme.

Was echtes Domänenwissen verlangt: MISRA-C/C++-Konformität, Echtzeit-OS-Scheduling mit deterministischen Zeitgarantien, Hardware-in-the-Loop-Testinfrastruktur (HiL) sowie Hardware-Software-Co-Design, bei dem Firmware und Silizium im Gleichschritt entwickelt werden.

Diese ehrliche Einschätzung zählt mehr als jede Marketingaussage. Liegt Ihr Projekt in der Cloud-to-Cabin-Pipeline — Telematik-Dashboards, OTA-Orchestrierung, Begleit-Apps — bringt ein Full-Stack-Partner mit Automotive-Kontext Sie schneller in die Produktion als ein reiner Embedded-Spezialist. Geht es um Bremsregler-Firmware, benötigen Sie einen zertifizierten Tier-1-Zulieferer. Ohne Kompromiss.

Was Sie vor der Beauftragung eines Partners für Automotive Softwareentwicklung prüfen sollten

Bevor Sie einen Dienstleister für Automotive Softwareentwicklung beauftragen, sollten Sie fünf unverzichtbare Qualifikationen prüfen: eine ASPICE Level 2+ Bewertung durch einen unabhängigen Assessor, einen dokumentierten ISO 26262 Safety Case aus einem abgeschlossenen Projekt, einen namentlich benannten Functional Safety Manager im Lieferteam, praktische Erfahrung mit AUTOSAR-Toolchains (Vector CANoe, ETAS INCA oder dSPACE) sowie eine definierte Methodik nach ISO/SAE 21434 für Cybersicherheit.

Fehlt auch nur eines dieser Kriterien, riskieren Sie eine fehlgeschlagene Lieferantenqualifizierung — oder schlimmer: einen Safety Case, der unter OEM-Prüfbedingungen nicht standhält.

Die SWE.2-Falle

In zahlreichen Lieferantenqualifizierungen haben wir dasselbe Muster beobachtet. Anbieter mit starkem Enterprise- oder Web-Portfolio scheitern regelmäßig am ASPICE-Prozessbereich SWE.2 (Software Architectural Design). Der Grund: Ihre Prozessdokumentation basiert auf agilen Sprint-Backlogs und Jira-Tickets — nicht auf den formalen bidirektionalen Traceability-Matrizen, die OEM-Auditoren zwischen Anforderungen, Architekturelementen und Testfällen erwarten.

Dieses Muster ist kein Zufall. Enterprise-Teams optimieren für Liefergeschwindigkeit; ASPICE optimiert für Prozessnachweise. Beide Ansätze erzeugen grundlegend unterschiedliche Artefakte.

Die Nachbesserung ist aufwändig. Nachträgliche Erstellung SWE.2-konformer Architekturdokumentation in einem laufenden Projekt kostet typischerweise 8 bis 14 Wochen und bindet Senior-Architekten, die eigentlich an Features arbeiten sollten. In den Qualifizierungsprojekten, die wir begleitet haben, trieb dieser Mehraufwand die Budgets regelmäßig in den sechsstelligen Bereich — noch vor SOP-Freigabe. Für Programme mit Markteinführung 2026 bedeutet diese Verzögerung verpasste OEM-Meilensteine und gefährdet das Vertrauen des Einkaufs, bevor auch nur ein Release ausgeliefert wird.

Fünf-Punkte-Checkliste zur Compliance-Prüfung

1. Fordern Sie einen unabhängig ausgestellten ASPICE-Bewertungsbericht an — Eigenauskünfte bestehen keine OEM-Audits. Der Assessor muss intacs-zertifiziert sein.
2. Verlangen Sie HARA-Ergebnisse aus einem abgeschlossenen Projekt. Kann der Anbieter keine Hazard Analysis and Risk Assessment vorweisen, bleibt seine ISO 26262-Kompetenz rein theoretisch.
3. Prüfen Sie Tool-Qualifizierungsnachweise für jede sicherheitskritische Toolchain des vorgeschlagenen Stacks. Nicht qualifizierte Tools entwerten Sicherheitsargumentationen vollständig.
4. Belegen Sie TARA-Erfahrung nach ISO/SAE 21434 anhand eines konkreten Projektbeispiels — keine Folienpräsentation. Cybersicherheitsreife ist in den meisten Automotive- und Mobilitätsprogrammen heute ein verbindliches Gate.
5. Prüfen Sie, ob ein Development Interface Agreement bei früheren OEM-Projekten eingesetzt wurde. Fehlt dieses Dokument, hat der Anbieter die Koordination in Mehrparteien-Entwicklungsprojekten noch nicht ernsthaft durchlaufen — eine Lücke, die mit steigender technologischer Komplexität wächst.

Scheiden Sie jeden Anbieter aus, der die Punkte eins bis drei nicht erfüllt — das sind Ausschlusskriterien, keine Verhandlungspositionen. Die Punkte vier und fünf trennen dann echte Kompetenzträger von Anbietern, deren Prozesslücken erst mitten im Programm sichtbar werden und Ihren Zeitplan gefährden.

Automotive Software Entwicklung: Spezialisierte Anbieter vs. Allgemeine Softwareagenturen – Ein technischer Vergleich

Die Unterschiede zwischen einer allgemeinen Softwareagentur und einem qualifizierten Anbieter für automotive Software Entwicklung sind keine Frage des Grades – sie sind struktureller Natur. Verschiedene Toolchains, verschiedene Prozessmodelle, verschiedene Teamzusammensetzungen. Wer diese Unterschiede unterschätzt, riskiert sechs bis zwölf Monate Nacharbeit – typischerweise beim ersten OEM-Lieferantenaudit entdeckt.

Vier Dimensionen, die beide Welten trennen

Diese Tabelle ist keine Theorie. Tier-1-Zulieferer wie Bosch und ZF fordern vertraglich ASPICE Level 2+ von jedem Softwaredienstleister in ihrer Lieferkette. Wer als Partner die Prozesskonformität von SWE.1 bis SWE.6 nicht nachweisen kann, scheitert an der Lieferantenqualifikation – unabhängig von der Codequalität.

Warum dieser Markt höhere Preise rechtfertigt

Laut einer Marktanalyse von Statista wurde der globale Automotive-Software-Markt 2023 auf 22,6 Milliarden US-Dollar geschätzt und soll bis 2030 auf über 43 Milliarden US-Dollar anwachsen. Dieses Wachstum erklärt sich nicht allein durch Volumen – es spiegelt die regulatorische und technische Komplexität wider, die diese Domäne von allgemeiner Unternehmenssoftware abhebt. Spezialisierte Anbieter erzielen Preisaufschläge von 30–50 % gegenüber Generalisten. OEMs zahlen diese Aufschläge, weil die Alternative – gescheiterte Audits, verzögerte SOP-Termine, Sicherheitsrückrufe – um ein Vielfaches teurer kommt.

Wenn Sprints auf Gate-Reviews treffen

Das häufigste Scheitermuster, das wir beobachten, wenn allgemeine Agenturen automotive Software Projekte übernehmen: Sie wenden ihren gewohnten zweiwöchigen Sprint-Rhythmus auf ein V-Modell-Projekt an.

Das Konstrukt bricht innerhalb des ersten Quartals zusammen.

Eine System-FMEA lässt sich nicht in einem einzigen Sprint abschließen. Ein formales Safety-Analysis-Review erfordert die Freigabe durch Sicherheitsingenieure, Systemarchitekten und das Safety-Team des OEM – allein diese Abstimmung dauert Wochen. Die Pflege von Traceability-Matrizen zwischen Anforderungen, Design, Implementierung und Testartefakten ist keine Aufgabe für das Sprint-Planning. Sie ist eine kontinuierliche Prozessverpflichtung nach ASPICE SWE.4 und SWE.5.

Was dann passiert, ist vorhersehbar: Safety-Reviews werden auf den „nächsten Sprint” vertagt, Compliance-Dokumentation häuft sich als technische Schuld an, und der OEM-Review-Zeitplan – von Anfang an fest terminiert – beginnt zu rutschen. Wenn das Team erkennt, dass Gate-Reviews nicht im Sprint-Takt abgearbeitet werden können, sind bereits drei bis vier Monate Budget für Ergebnisse verbrannt, die keinem Audit standhalten werden. Für Teams, die diese Spannung zwischen agilen und strukturierten Prozessmodellen navigieren, ist das Verständnis beider Ansätze vor Projektstart keine Option, sondern Voraussetzung.

Die Lücke zwischen Design und Engineering

Kann ein einziger Partner sowohl sicherheitskritische Embedded-Expertise als auch modernes Produktdesign liefern? In unserer Erfahrung: fast nie – und das ist das Beschaffungsproblem, über das 2026 kaum jemand offen spricht.

Die meisten Anbieter für automotive Software Entwicklung sind in einer dieser Domänen stark. Entweder finden Sie Embedded-Spezialisten mit tiefem AUTOSAR- und ISO-26262-Know-how, die funktionale, aber optisch veraltete HMIs liefern. Oder Sie finden Produktdesign-Agenturen, die beeindruckende Oberflächen bauen – ohne Vorstellung davon, wie diese über CAN-Bus-Daten integriert oder nach den Ablenkungsrichtlinien der ECE R10 und relevanter EU-Normen zertifiziert werden.

Der kritische Schnittpunkt – wo Infotainment-HMI-Design auf cloud-verbundene Servicearchitektur trifft – ist genau dort, wo diese Lücke zum echten Projektrisiko wird. Vernetzte Fahrzeugplattformen brauchen beides: eine durchdachte UI auf Basis echter Nutzerforschung und Backend-Services, die mit Fahrzeugdiagnose, OTA-Update-Managern und Telematik-Gateways kommunizieren.

MyPlanet Design – Interne Teams für UI/UX-intensive Produktschichten und technisch anspruchsvolle Backend-Integrationen, ausgerichtet auf automotive Projekte, die HMI-Design mit cloud-verbundener Servicearchitektur kombinieren.

Die Lehre aus diesen wiederkehrenden Situationen: Schließen Sie nicht von der Portfolio-Ausrichtung eines Anbieters auf seine tatsächlichen Fähigkeiten. Fragen Sie nach der konkreten Teamzusammensetzung für Ihr Projekt. Wenn Sicherheitsingenieur und UX-Designer noch nie gemeinsam an einer Lieferung gearbeitet haben, sind Sie der Integrationstest – ein Risiko, das in einer Domäne, in der Zertifizierungszeitpläne keine Puffer kennen, niemand eingehen sollte.

Warum Automotive-Softwareprojekte scheitern – und welche Warnsignale das ankündigen

Die meisten Projekte im Bereich der Automotive-Softwareentwicklung scheitern nicht an schlechtem Engineering. Sie scheitern, weil Safety Engineering als nachgelagertes Thema behandelt wurde – eingeplant erst nach abgeschlossenen Architekturentscheidungen, budgetiert als wäre Compliance eine Nebensache.

Das Budgetproblem, das niemand vorab erwähnt

In mehr als fünf Automotive-Projekten ab ASIL-C haben wir ein gleichbleibendes Muster beobachtet: Die Safety-Dokumentation – Sicherheitsplan, HARA, FMEA, FTA, Safety Case und Nachweismethoden – hat 35–45 % des Gesamtbudgets verschlungen. Jedes Mal waren unsere Kunden überrascht. Der jeweilige Dienstleister hatte ausschließlich Entwicklungsstunden kalkuliert und die Safety-Artefakte als geringen Zusatzaufwand behandelt.

Genau das passiert, wenn die Sicherheitsplanung über die Konzeptphase hinaus aufgeschoben wird. Architekturentscheidungen ohne Safety-Constraints erzwingen später strukturelle Nacharbeiten, die sich durch nachträgliche Korrekturen nicht mehr beheben lassen. Wenn ein Lieferant erkennt, dass der Sicherheitsplan mit der bestehenden Architektur kollidiert, ist das Projekt bereits mehrere Monate im Rückstand.

Die wirtschaftlichen Konsequenzen sind erheblich. Laut Statistik des Kraftfahrt-Bundesamts (KBA) ist der Anteil softwarebedingter Fahrzeugrückrufe in Deutschland innerhalb eines Jahrzehnts stark gestiegen – ein Trend, der sich europaweit bestätigt. Wer bei der Automotive-Softwareentwicklung auf unqualifizierte Dienstleister setzt, trägt nicht nur ein Projektrisiko, sondern direkte Haftung für Rückrufkosten.

Drei Warnsignale in Anbieterangeboten

Wie erkennt man solche Probleme, bevor sie eintreten? Prüfen Sie jedes Angebot auf diese drei Warnsignale:

1. Kein namentlich benannter Functional Safety Manager – ISO 26262 definiert diese Rolle als verbindliche Prozessrolle, nicht als nachträglich vergebenen Titel. Fehlt sie im Teamplan, ist der Anbieter nicht auf Safety ausgerichtet.
2. ISO 26262 nur als „Erfahrung” angegeben – ohne dokumentierte Safety Cases mit konkreten ASIL-Zuweisungen aus abgeschlossenen Projekten heißt das: man kennt die Norm, hat sie aber noch nie unter realen Auditbedingungen angewendet.
3. Keine beschriebene HARA-Methodik – die Hazard Analysis and Risk Assessment bildet die Grundlage jedes Safety Cases. Fehlt sie im Angebot, reicht die Planung nicht über eine Demo hinaus.

Die Prototypen-Falle

Hier explodieren die Budgets. Anbieter liefern funktionsfähige Demonstratoren – optisch überzeugend, präsentationsreif – ohne MISRA-C-Konformität, AUTOSAR-Integration oder Echtzeit-Betriebssystemanforderungen. Dieser Code lässt sich nicht sicherheitszertifizieren.

Die nachträgliche Herstellung von ASIL-Konformität kostet typischerweise das Drei- bis Fünffache des ursprünglichen Entwicklungsaufwands – ein Verhältnis, das in veröffentlichten Fallstudien aus der Automotive-Technologie konsistent belegt ist. Wir haben Teams erlebt, die sechs Monate damit verbrachten, neu zu entwickeln, was in zwei Monaten demonstriert wurde. Der Prototyp sah nach Fortschritt aus. Es war technische Schuld – fest ans Lenkrad geschraubt.

Praktische Checkliste zur Bewertung von Angeboten für Automotive Software Entwicklung

Jedes Lieferantenangebot sollte sieben binäre Prüfkriterien bestehen, bevor es auf Ihre Shortlist kommt. Jedes Kriterium lässt sich anhand von Projektdokumenten verifizieren — Bestehen oder Nichtbestehen, keine Zwischenstufen, kein “Das klären wir beim Onboarding.” Wer diese Nachweise bereits in der Angebotsphase nicht vorlegen kann, wird sie unter Lieferdruck erst recht nicht erbringen.

1. ISO 26262-Fallstudien, die ein konkretes ASIL-Level und einen Projekttyp benennen und auf Anfrage verfügbar sind
2. ASPICE-Assessmentbericht eines unabhängigen Dritten — keine Eigenerklärung
3. Namentlich genannter Functional Safety Manager, im Angebot mit vollem Namen aufgeführt, nicht als “TBD”
4. Werkzeugqualifizierungsplan, dokumentiert für jedes sicherheitskritische Toolchain-Element
5. ISO/SAE 21434-TARA-Prozess, belegt durch ein konkretes, abgeschlossenes Referenzprojekt
6. AUTOSAR Classic oder Adaptive Erfahrung, nachgewiesen durch eine namentlich genannte Projektreferenz
7. DIA-Vorlage, die vor Vertragsunterzeichnung übermittelt wird

Bewertungsschwelle

Drei oder mehr Nichtbestehen disqualifizieren einen Anbieter — unabhängig von Portfolioqualität oder Preisposition. Diese Grenze ist nicht willkürlich gesetzt. Laut McKinsey-Analysen zu Automotive-Software-Programmen verursachen unzureichende Lieferantenqualifikationen über 60 Prozent aller Projektkostenüberschreitungen (McKinsey & Company, 2024). Wir haben Anbieter erlebt, die jeden kaufmännischen Checkpoint bestanden — und beim ersten Gate-Review scheiterten, weil niemand vorab ein DIA angefordert hatte. Die im vorigen Abschnitt beschriebenen OEM-Audit-Muster lassen sich direkt auf diese technischen Gates zurückführen.

Die Einstufung eines Anbieters auf dieser Checkliste korreliert mit dem jeweiligen Engagement-Level:

Die leistungsstärksten Dienstleister für Automotive Software Entwicklung verbinden strukturierte Funktionale-Sicherheits-Methodik mit moderner Produktentwicklungstiefe. Wer beide Fähigkeiten bereits bei der Anbieterauswahl prüft, vermeidet das nachträgliche Compliance-Retrofit — der häufigste Grund, warum Automotive-Engagements scheitern.

Die Wahl des richtigen Partners für automotive Softwareentwicklung entscheidet sich an Fakten, nicht Versprechen

Der Unterschied zwischen einem erfolgreichen Projekt im Bereich automotive Softwareentwicklung und einem zwölf Monate langen Korrekturzyklus ist fast immer vor Vertragsunterzeichnung erkennbar. Anbieter, die ASPICE-Assessmentberichte vorlegen, ihren Functional Safety Manager benennen und Sie durch ein abgeschlossenes Safety Case eines früheren ASIL-C-Projekts führen können, verstecken sich nicht hinter NDAs — sie liefern Belege.

Softwareentwicklung im Automotive-Bereich erfordert ein anderes Betriebsmodell als klassische Enterprise-Projekte. Die Toolchains sind spezialisiert, die Compliance-Anforderungen müssen früh im Prozess erfüllt werden, und die Sicherheitsdokumentation verschlingt — ob geplant oder nicht — ein Drittel oder mehr des Budgets.

Wer diese Realität bereits bei der Anbieterauswahl akzeptiert und nicht erst beim ersten OEM-Audit, der trennt erfolgreiche Programme von solchen, die ins Stocken geraten. Gerade im DACH-Raum, wo OEMs wie BMW, Mercedes-Benz oder Bosch strenge Lieferantenanforderungen stellen, ist diese Weichenstellung entscheidend.

Prüfen Sie jedes Angebot anhand der sieben Kriterien. Verifizieren Sie Referenzen und Zertifikate eigenständig. Und wenn Ihre aktuelle Auswahlliste keine Partner mit nachgewiesener AUTOSAR- und ISO-26262-Erfahrung enthält, sind spezialisierte Teams wie ein maßgeschneidertes Tool ein Gespräch wert.

Verfasst von Nazar Verhun, CEO & Lead Designer bei MyPlanet Design.

Mit über 7 Jahren Erfahrung in UX/UI-Design, Produktdesign und digitaler Strategie leitet Nazar Verhun MyPlanet Design. Sein forschungsbasierter Ansatz verbindet fundierte Nutzerforschung mit unternehmerischer Strategie — für Startups ebenso wie für Fortune-500-Unternehmen.