Branche · Automotive Software

Automotive Software für vernetzte Fahrzeuge und Tier-1-Lieferanten

Die Automotive Software-Wertschöpfung verschiebt sich vom Steuergerät zur Plattform. Software-Defined Vehicle, OTA-Updates, Catena-X-Datenflüsse und ein verschärfter Cybersecurity-Rahmen — UN-R155, UN-R156, ISO/SAE 21434 — treffen auf Tier-1- und Tier-2-Lieferanten, die ihren OEM-Kunden heute jeden Software-Pfad nachweisbar machen müssen. Wer in diesem Umfeld Companion Apps, Werkstatt-Tools, Diagnose-Backends oder OTA-Infrastruktur baut, baut nicht „eine App" — er baut auditierbare Automotive Software, die mit dem Fahrzeug-Lifecycle altert.

Kontakt

Branchenkontext

Stuttgart, Baden-Württemberg und Bayern bilden das dichteste Automotive Software-Cluster Europas — Mercedes-Benz Group, Porsche, Audi, BMW und ihre Lieferanten Bosch, ZF, Mahle, Continental, Schaeffler. Rund um diese Zentren sitzt ein vier- bis fünfstelliger Mittelstand aus Tier-2- und Tier-3-Lieferanten, die zunehmend selbst Software liefern müssen — vom Diagnose-Stack über Service-Apps bis zum Telemetrie-Backend für vernetzte Komponenten.

Drei Verschiebungen prägen die Branche 2026: Erstens das Software-Defined Vehicle — BMW „Neue Klasse", Mercedes-Benz MB.OS, ZF-Referenz-Architekturen, Bosch AI-Cockpit. Funktionalität wandert vom verteilten Steuergerät in zonale Compute-Knoten, ergänzt um Cloud-seitige Dienste. Zweitens die Cybersecurity-Kaskade: UN-R155 ist seit 07/2024 für sämtliche EU-Neuproduktion verpflichtend, ISO/SAE 21434:2021 ist der De-facto-Nachweispfad — beides zieht sich über CSMS-Forderungen vom OEM bis in Tier-2 und Tier-3. Drittens die Daten-Ebene: Catena-X ist mit rund 190 Mitgliedern und einer wachsenden Liste an CX-Standards (z.B. CX-0018 Dataspace Connectivity, CX-0126 Industry Core: Part Type) zum operativen Daten-Ökosystem geworden — nicht mehr Konzept, sondern Lieferbedingung.

Für Software-Lieferanten heißt das: Eine Automotive Software ohne dokumentierten ISO/SAE 21434-Prozess, ohne signierten Update-Pfad und ohne Anschlussfähigkeit an Catena-X-Datenformate fällt in OEM-Lieferantenaudits durch — unabhängig davon, wie elegant der Code geschrieben ist.

Typische Herausforderungen

Cybersecurity-Nachweis durch die Lieferkette

Tier-1-Lieferanten reichen die UN-R155-CSMS-Anforderungen ihres OEM-Kunden vertraglich an Tier-2 und Tier-3 weiter. Wer Automotive Software liefert, ohne einen ISO/SAE 21434-konformen Engineering-Prozess dokumentieren zu können — TARA, Threat Catalog, Vulnerability-Management, Secure-Development-Lifecycle —, fällt in Lieferanten-Audits durch. Der Nachweis ist nicht ein Zertifikat „nice to have", sondern Voraussetzung für den nächsten Bestell-Rahmenvertrag. Genauso eingefordert: TISAX-Assessment-Level (AL2 oder AL3, drei Jahre gültig) für die Informationssicherheit der Entwicklungs-Umgebung selbst.

OTA-Update-Infrastruktur unter UN-R156

UN-R156 verlangt ein Software Update Management System (SUMS) mit signierten Manifesten, dokumentierter Genehmigungs-Kette, Rollback-Fähigkeit und vollständigem Audit-Trail über jede ausgerollte Version. Eine OTA-Infrastruktur, die nicht von Anfang an als Append-only Eventlog mit revisionssicherer Versions-Historie konstruiert ist, lässt sich nicht nachträglich UN-R156-tauglich machen — sie muss neu gebaut werden. Das gleiche gilt für die Geräte-Seite: Bootloader, Signatur-Prüfung und A/B-Partition-Strategie sind keine Optimierung, sondern Eintrittsticket.

Companion Apps mit realer Konnektivität

Automotive Software, die Fahrzeugdaten live anzeigt — Service-Apps für Tier-1-Lieferanten, Werkstatt-Apps mit OBD-II/UDS-Brücke, Endkunden-Begleiter für Sensorik im Fahrzeug — muss mit BLE-Verbindungsabbrüchen, Werkstatt-WLAN-Latenz, Mobilfunk-Lücken auf der Strecke und Offline-Szenarien bei Service-Einsatz sauber umgehen. Eine Online-only-Architektur mit Hoffnung auf 4G überlebt den ersten Praxis-Tag in der Werkstatt nicht. Die robuste Variante: lokales Eventlog auf dem Gerät, Sync mit dem Backend über strukturierte Resync-Punkte, idempotente APIs.

Catena-X-Anschlussfähigkeit als Lieferbedingung

OEMs bauen ihre Lieferanten-Daten-Flüsse zunehmend über Catena-X auf — Traceability, Quality Management, Product Carbon Footprint, Demand & Capacity Management. Tier-1- und Tier-2-Lieferanten brauchen einen Eclipse Dataspace Connector (EDC, CX-0018-konform), saubere Mappings auf CX-Standards (z.B. CX-0126 Industry Core: Part Type) und eine Daten-Hoheit, die auch unter Zugriffs-Pflicht der OEMs in eigener Hand bleibt. Wer das Backend ohne dieses Anschluss-Konzept baut, lässt nachträglich einen zweiten Daten-Pfad neben das eigentliche System wachsen — und verdoppelt die Compliance-Last.

Lifecycle-Daten über 15 Jahre Fahrzeug-Betrieb

Ein Pkw bleibt im Schnitt deutlich länger als ein Jahrzehnt im Betrieb — Software-seitig bedeutet das: Update-Fähigkeit, Diagnose-Kompatibilität und Daten-Modell müssen über mehr als zehn Jahre konsistent bleiben. Eine Automotive Software-Architektur, die Schema-Migrationen nur retrograd kennt, verliert die ersten Geräte-Generationen mit dem ersten größeren Refactor. Der bewährte Pfad: ein versioniertes Lifecycle-Datenmodell mit unveränderlichem Geburts-Snapshot pro Komponente und Eventlog-basierter Service-Historie — der Refactor-Pfad bleibt offen, ohne historische Daten zu verlieren.

Regulatorischer Rahmen

UN-R155 (Cybersecurity Management System)

UN Regulation Nr. 155 verlangt für die Typgenehmigung den Nachweis eines Cybersecurity Management Systems (CSMS) und konkrete Schutzmaßnahmen gegen die in Anhang 5 aufgeführten Bedrohungen — über den gesamten Fahrzeug-Lebenszyklus. Anwendungsbereich: Fahrzeuge der Kategorien M (Personentransport), N (Güter), O (Anhänger mit ECU) sowie L (Stufe 3+ Automatisierung). Lieferantenrelevanz: OEMs reichen ihre CSMS-Pflichten vertraglich an Tier-1 weiter, die wiederum an Tier-2/Tier-3 — jede Automotive Software in der Kette wird nachweispflichtig. Supplement 3, in Kraft seit 10.01.2025, präzisiert den Geltungsbereich und Audit-Anforderungen.

Anwendbarkeit: In Kraft seit 22.01.2021 · Verpflichtend für neue Fahrzeugtypen seit 07/2022 · Für sämtliche EU-Neuproduktion seit 07/2024 · Supplement 3 seit 10.01.2025

UN-R156 (Software Update Management System)

UN Regulation Nr. 156 verlangt ein dokumentiertes Software Update Management System (SUMS) und sichere Update-Prozesse für jeden genehmigten Fahrzeugtyp. Inhaltlich: signierte Manifeste, dokumentierte Freigabe-Kette, Rollback-Fähigkeit, Information der Nutzer bei sicherheitsrelevanten Updates, vollständiger Audit-Trail. UN-R156 begleitet UN-R155 zeitlich eins zu eins — und ist Voraussetzung für jedes Over-the-Air-Update an einem genehmigten Fahrzeugtyp. Für Tier-1- und Tier-2-Lieferanten, die OTA-Backends oder Update-Komponenten liefern, ist die SUMS-Konformität ihres Pfads explizit vom OEM-Kunden zu auditieren.

Anwendbarkeit: Gleiche Zeitlinie wie UN-R155 · Pflicht für neue Typen seit 07/2022 · Für sämtliche EU-Neuproduktion seit 07/2024

ISO/SAE 21434:2021

Internationaler Standard für Cybersecurity-Engineering von elektrisch/elektronischen Systemen in Straßenfahrzeugen. Veröffentlicht am 31.08.2021. Definiert einen Engineering-Prozess über den gesamten Lebenszyklus — Konzept, Produktentwicklung, Produktion, Betrieb, Wartung, Stilllegung. Anwendung beginnt für Systeme, deren Entwicklung oder Modifikation nach 2021 startet. Ergänzt ISO 26262 (funktionale Sicherheit), adressiert aber explizit Cybersecurity-Risiken — TARA (Threat Analysis and Risk Assessment), Asset-Identifikation, Risiko-Behandlung. Praktische Bedeutung: ISO/SAE 21434 ist der De-facto-Pfad, um die UN-R155-CSMS-Forderung des OEMs nachvollziehbar zu erfüllen.

Anwendbarkeit: Veröffentlicht 31.08.2021 · 1. Edition gültig

ISO 26262 (Funktionale Sicherheit)

Internationaler Standard für funktionale Sicherheit elektrischer/elektronischer Systeme im Straßenfahrzeug. 1. Auflage 2011, aktuelle 2. Auflage 2018 mit erweitertem Geltungsbereich auf alle Straßenfahrzeuge außer Mopeds. Klassifiziert Risiken nach ASIL (A bis D, ASIL D mit den höchsten Anforderungen). Bei sicherheits-relevanter Automotive Software muss der ASIL-Pfad nachvollziehbar dokumentiert sein — von Anforderung über Architektur und Implementierung bis Validierung und Konfiguration. Komplementär zu ISO/SAE 21434: Funktionale Sicherheit und Cybersecurity sind zwei getrennte Engineering-Prozesse mit überlappenden Artefakten.

Anwendbarkeit: 1. Auflage 2011 · 2. Auflage 2018 (aktuelle Edition)

TISAX (VDA Information Security Assessment)

Audit- und Austausch-Mechanismus, gemeinsam von VDA und ENX entwickelt, basierend auf dem VDA-ISA-Katalog. TISAX prüft die Informationssicherheit der Entwicklungs- und Lieferanten-Umgebung. Drei Assessment Levels: AL1 (Self-Assessment), AL2 (Self-Assessment plus Remote-Plausibilitäts-Prüfung), AL3 (vollständige Vor-Ort-Prüfung). Zertifikate sind drei Jahre gültig. OEMs und Tier-1-Lieferanten verlangen TISAX in der Regel als Voraussetzung für jeden Lieferanten, der Prototypen-Daten, Konstruktions-Unterlagen oder personenbezogene Daten verarbeitet — Automotive Software-Lieferanten ohne TISAX-Status werden in vielen Bestell-Prozessen erst gar nicht eingeladen.

Anwendbarkeit: Verpflichtend in OEM-Lieferanten-Onboarding · Zertifikat 3 Jahre gültig

EU Cyber Resilience Act (CRA)

Verordnung (EU) 2024/2847 fordert Cybersecurity-by-Design für Produkte mit digitalen Elementen am EU-Markt: Schwachstellen-Management, Sicherheits-Updates, Konformitätsbewertung, Vorfall-Meldepflicht. Für die Automotive-Branche ist die Abgrenzung präzise: Typgenehmigte Fahrzeug-Komponenten, die unter UN-R155/EU 2019/2144 fallen, sind aus dem CRA-Geltungsbereich ausgenommen. Im CRA bleiben: Aftermarket-Software, Retrofit-Module, Ladeinfrastruktur, Begleit-Apps, Drittanbieter-Software auf Infotainment-Seite, Nutzfahrzeuge ausserhalb des UN-R155-Scopes (Bau-, Land-, Forst-Maschinen). Wer dort Automotive Software liefert, braucht eine CE-Kennzeichnung.

Anwendbarkeit: In Kraft seit 10.12.2024 · Meldepflichten ab 11.09.2026 · Volle Anwendbarkeit ab 11.12.2027

EU Data Act

Glossar →

Verordnung (EU) 2023/2854 gibt Nutzern vernetzter Produkte ein Recht auf Zugang zu, Nutzung und Weitergabe der durch ihre Nutzung erzeugten Daten — Anwendung auch auf vernetzte Fahrzeug-Daten und After-Sales-Telemetrie. Hersteller und ihre Software-Lieferanten müssen die zugehörigen Dienste so gestalten, dass dieser Zugriff technisch möglich ist — strukturierter Datenexport, klare API-Schicht, Trennung zwischen Hersteller-internen und nutzer-zugänglichen Daten. Für Service-Apps und Werkstatt-Backends: das Datenmodell muss Datenkategorien und Zugriffs-Rechte explizit kennen, nicht implizit annehmen.

Anwendbarkeit: Anwendbar seit 12.09.2025

Architektur-Muster für B2B-Apps

Fahrzeug-/Komponenten-Schnittstelle
BLE 5+ · WiFi-Direct · UDS-on-IP · CAN-FD-Gateway · OBD-II · MQTT 5 (TLS, Client-Cert)

Mehrere Konnektivitätspfade parallel — App-zu-Fahrzeug, App-zu-Diagnose-Gateway, Komponente-zu-Backend. Geräte-Authentifizierung über X.509-Zertifikate aus einer eigenen Public-Key-Infrastruktur, niemals über statische Pre-Shared-Keys im Code. Robustheit gegen Verbindungsabbrüche ist Pflicht, nicht Optimierung.

Mobile App-Schicht (Companion / Werkstatt)
Cross-Platform-App (z. B. Flutter) für 80–90 % der Logik · native Brücken für sicherheitskritische Pfade · Offline-First-Datenmodell · lokales Eventlog

Cross-Platform für die Masse der Funktionalität, native Brücken für sicherheitskritische oder hardwarenahe Operationen (UDS-Stack, Bootloader-Kommunikation). Das App-Datenmodell ist offline-first: jede Aktion wird lokal als Event geschrieben, Sync mit dem Backend über strukturierte Resync-Punkte und idempotente APIs.

Telemetrie-Ingestion & Eventlog
MQTT-Broker · Stream-Plattform (z. B. Kafka, NATS JetStream) · typisierte Ingestion-API · TimescaleDB · Append-only Eventlog

Hochdurchsatz-Eingang von Geräte-Daten, klar getrennt von der Anwendungs-API. Jedes Telemetrie-Event landet zusätzlich in einem Append-only Eventlog — die Grundlage für UN-R155-Vorfall-Analysen, ISO/SAE 21434-Audits und revisionssichere Service-Historie. Time-Series-Aggregation in TimescaleDB, Roh-Events bleiben unverändert.

Sicherer OTA-Update-Pfad (UN-R156)
S3-kompatibler Object-Store · Signaturen aus HSM · A/B-Partition · Rollback · Manifest-Registry · Approval-Workflow

Update-Artefakte (Firmware, App-Bundle, Konfiguration) liegen in einem S3-kompatiblen Object-Store, Manifeste sind aus einem Hardware Security Module signiert, Freigabe durchläuft einen dokumentierten Approval-Workflow mit Vier-Augen-Prinzip. Geräteseitig: A/B-Partition mit automatischem Rollback bei fehlgeschlagener Signatur-Prüfung. Jede Aktion landet im Audit-Trail — Voraussetzung für SUMS-Konformität.

Catena-X-Anschluss & Daten-Hoheit
Eclipse Dataspace Connector (EDC, CX-0018) · CX-Standard-Mappings (CX-0126 u.a.) · Policy-Engine · OEM-Portal-SSO via OIDC

Daten werden Catena-X-anschlussfähig modelliert — über den Eclipse Dataspace Connector mit Policy-basiertem Zugriff. Das Backend behält die Roh-Daten in eigener Hand; Catena-X ist Verteil-, nicht Speicher-Schicht. SSO zum OEM-Lieferantenportal über OIDC, getrennt von der Endkunden-Auth.

Identity, Schlüssel & Audit
OIDC-Identity-Provider (z. B. Authentik, Keycloak, Auth0) · Mutual TLS · HSM für Signatur-Schlüssel · Code-Signing-Pipeline · Plattform-Observability

Trennung der Identitäts-Domänen: Werkstatt-Mitarbeiter und OEM-Kontakte über OIDC, Endkunden über einen getrennten Auth-Provider. Alle Signatur-Schlüssel im Hardware Security Module, niemals im Code. Plattformweites Error-Tracking und Metriken — Voraussetzung für nachvollziehbare UN-R155-Vorfall-Analysen.

Wie wir den Stack wählen

Der konkrete Stack wird pro Projekt entschieden — abhängig von Datenmenge, Compliance-Anforderungen, Bestandssystemen und Team-Skills. Diese Tabelle zeigt unsere typischen Werkzeuge je Fähigkeit, mit jeweils zwei bis drei Beispielen, die wir produktiv eingesetzt haben.

Fähigkeit Womit wir das umsetzen
Cross-Platform-App mit hardware-nahem Pfad

Eine Codebasis für iOS und Android, robuste BLE- und Bluetooth-Integration, schnelle Iteration im OEM-, Tier-1- und Werkstatt-Kontext. Typische Wahl: Flutter mit nativen Brücken für sicherheits-kritische Pfade; rein nativ (Swift/Kotlin) wo der UDS- oder Bootloader-Stack es verlangt.
Typisiertes Backend für regulierte Plattformen

Strukturierte Architektur mit klarer Modul-Separation für Compliance-Audits, performante HTTP-, WebSocket- und MQTT-Schicht für Live-Telemetrie. Wir setzen TypeScript (NestJS, Fastify) als Standard ein, Go oder Rust bei sehr hohen Durchsatz-Anforderungen.
Hybrid relational + time-series Datenhaltung

Relationale Integrität für Lifecycle- und Service-Historie, Time-Series-Erweiterung für Telemetrie. PostgreSQL + TimescaleDB als Default; ClickHouse oder Influx wenn das Telemetrie-Volumen es verlangt. Append-only Eventlog im selben Schema — kein Multi-DB-Klempnerwerk.
Event-getriebene Telemetrie unter Last

Eventgetriebene Ingestion mit Replay-Fähigkeit. Kafka wo ein bestehender Confluent-/Strimzi-Stack greift; NATS JetStream für leichtgewichtigeren Selbst-Betrieb; reine MQTT-Pipelines für niedrigere Volumen-Klassen.
Signierter, content-addressed OTA-Artefakt-Store

OTA-Artefakte (Firmware, Bundles, Konfiguration) versioniert und content-addressed in einem S3-kompatiblen Store, signiert aus einem HSM. Provider je nach Datensouveränität: EU-managed Storage, MinIO/Garage in eigener Cloud oder ein Hyperscaler — die Anbindung bleibt austauschbar.
OIDC-Identity in eigener Hand

Trennung von OEM-/Werkstatt- und Endkunden-Identitäten über OIDC-Provider. Self-hosted Optionen (z. B. Authentik, Keycloak) wo Datenresidenz oder Audit-Anforderungen es verlangen; Managed-Provider (z. B. Auth0) wo Time-to-Market und Team-Skills es nahelegen.
Catena-X-Anschluss über Eclipse Dataspace Connector

Catena-X-Anschluss über die CX-0018-konforme Tractus-X-EDC-Referenz-Implementierung. Policy-basierter, souveräner Daten-Austausch mit OEMs und Tier-1-Partnern, ohne dass Roh-Daten das eigene Backend verlassen — der Standard ist obligatorisch, der konkrete Build (Tractus-X, FraunhoferAISEC, Sovity) wählbar.
Plattform-Observability für UN-R155-Vorfall-Analysen

Error-Tracking, Metriken und Distributed Tracing als Datengrundlage für UN-R155-Vorfall-Analysen und ISO/SAE 21434-Monitoring. Wir setzen je nach Setup auf OpenTelemetry mit Sentry, Grafana-Stack (Loki, Tempo, Prometheus) oder Datadog — kein Vendor-Lock auf einen einzelnen Telemetrie-Anbieter.

Quellen

Stand: 2026-05-01

Weiter lesen

Andere Branchen

Industrie 4.0

Industrie 4.0 Plattform-Entwicklung & Software für die vernetzte Produktion: Asset Administration Shell, OPC UA, EU Data Act und Cyber Resilience Act — für den DACH-Mittelstand.

IoT & Vernetzte Produkte

IoT-Plattform-Entwicklung, B2B-Apps und Backend-Software für vernetzte Geräte — vom BLE-Sensor bis zur EU Data Act-konformen Telemetrie-Plattform.

Maschinenbau

Maschinenbau-Software, Service-Apps, MES-Anbindung und OPC-UA-Integration für den DACH-Mittelstand — VDMA-umati-kompatibel.

Facility Management

Facility Management Software & Plattformen für CAFM, Smart Building und EU-Energieeffizienz-Compliance — GEFMA 444/445-orientiert.

Handwerk & Bau

Individuelle Handwerker App und Bausoftware für DACH-Mittelstandsbetriebe — Mobile-First, offline-fähig, von Aufmaß und Bautagebuch über E-Rechnung (ZUGFeRD/X-Rechnung) bis BIM-Anbindung.

Konkretes Vorhaben in dieser Branche?

Wir entwickeln Software, die zu den regulatorischen, technischen und organisatorischen Realitäten Ihrer Branche passt — ohne überflüssige Komplexität.

E-Mail schreiben