Automotive-Software
Automotive-Software-Entwicklung heißt bei uns: die Backend- und Cloud-Plattformen bauen. Über sie fließen Diagnoseinhalte, Softwarestände und Serviceinformationen zwischen Werk, Remote-Software-Update-Services und Aftersales. Von Olching bei München aus entwickeln wir Diagnoseplattformen, Software-Update-Prozesse und Aftersales-Software für Fachbereiche bei Fahrzeugherstellern, von der Zielarchitektur über das Sicherheitskonzept bis zum Betrieb. Diagnosetester für Werkstätten bauen wir nicht.
Kurz gesagt
Automotive-Software-Entwicklung bei Amperbytes AI umfasst Backend- und Cloud-Plattformen für Fahrzeugdiagnose, Software-Update-Prozesse, produktionsnahe Software und Aftersales, nicht die Software im Steuergerät. Wir bauen diese Systeme für OEM-Teams, also Fachbereiche und Produktverantwortliche bei Fahrzeugherstellern, und nicht für Werkstätten, die ein Diagnosegerät suchen. Die Erfahrung dahinter stammt aus der Praxis unseres Gründers mit einem Diagnose-Service für Werke, Remote-Update-Services und Aftersales.
Für wen
Aus der Praxis unseres Gründers: Bei einem Premium-Automobilhersteller verantwortet er seit 2022 als Product Owner und Solution Architect einen microservice-basierten Diagnose-Service auf Google Cloud. Über 15.000 Nutzer pro Monat arbeiten damit in Werken, Remote-Software-Update-Services und Aftersales. Dazu gehören ein KI-Assistent mit Retrieval, ein ML-Empfehlungssystem und der Umzug des Vorgängersystems in die Cloud (Shift-to-Cloud).
Die Kennzahlen stammen aus Projekten, die unser Gründer in verantwortlicher Rolle bei Herstellern und Zulieferern umgesetzt hat, nicht im Auftrag von Amperbytes AI.
Leistungen im Detail
Microservice-Plattformen, die Diagnoseinhalte, Prüfabläufe und Ergebnisse an Nutzer in Werk, Remote-Services und Aftersales ausliefern. Dazu gehören Rollen und Berechtigungen je Nutzergruppe, Mandantentrennung, lückenlose Protokollierung und Schnittstellen zu bestehenden Systemen. Die Plattform ist so geschnitten, dass einzelne Dienste unabhängig ausgerollt und skaliert werden können, mit dem Ziel, dass Nutzer im Schichtbetrieb davon möglichst nichts merken.
Backends, die Softwarestände verwalten, Freigaben abbilden und Updates in Stufen an definierte Zielgruppen verteilen. Rückmeldungen aus dem Update-Vorgang laufen zurück, damit jederzeit ein Soll-Ist-Vergleich der Softwarestände möglich ist. Remote-Diagnose heißt dabei: Diagnosedaten werden erfasst und ausgewertet, ohne dass das Fahrzeug in einer bestimmten Halle stehen muss. Wir bauen die Prozess- und Cloud-Seite, nicht den Update-Client im Fahrzeug.
Cloud-Dienste, die am Band die richtigen Softwarestände für das Flashen bereitstellen, Prüfergebnisse erfassen und jedem Produkt zuordnen. Flashen bezeichnet das Aufspielen von Software auf ein Steuergerät. Entscheidend sind hier Taktzeit, Verfügbarkeit und ein Plan für Netzstörungen, denn ein Linienstillstand wiegt schwerer als eine fehlende Softwarefunktion. Ergebnisse stehen danach für Rückverfolgung und Auswertung bereit.
Anwendungen für Hotline, technischen Support und Serviceorganisation: Fallbearbeitung, Suche in Serviceinformationen, Eskalation an Fachexperten und strukturierte Rückmeldung von Feldfällen an die Entwicklung. Ziel ist, dass ein bekanntes Fehlerbild nicht jedes Mal neu recherchiert wird und dass wiederkehrende Probleme früh als Muster sichtbar werden, statt in einzelnen Tickets zu verschwinden.
Assistenten mit Retrieval (sie suchen zuerst die passenden Diagnose- und Serviceinhalte und antworten nur auf deren Basis), die Antworten mit Quellenangabe liefern, und Empfehlungssysteme, die auf Basis historischer Fälle den nächsten sinnvollen Prüfschritt vorschlagen. Beides bringen wir erst mit einer vorher vereinbarten Qualitätsdefinition in Produktion und messen es danach laufend mit Kennzahlen. Ohne diese Messung bleibt jede KI-Funktion ein Prototyp.
Gewachsene Diagnosesysteme überführen wir schrittweise in eine Cloud-Plattform, mit Parallelbetrieb, Rückfallweg und Pipelines für automatisierte Deployments. Ziel ist, dass Werk und Aftersales währenddessen weiterarbeiten. Vor der ersten migrierten Komponente steht eine Zielarchitektur, damit aus dem Altsystem keine Kopie in der Cloud wird, sondern eine Plattform, die sich weiterentwickeln lässt.
Ratgeber
Ein typischer Architekturfehler bei Diagnoseplattformen ist, alle Nutzer über einen Kamm zu scheren. Werk, Remote-Update-Services und Aftersales greifen oft auf dieselben Inhalte zu, brauchen aber sehr Unterschiedliches:
| Kriterium | Werk (Bandende, Nacharbeit) | Remote-Diagnose und Updates | Aftersales und Support |
|---|---|---|---|
| Wichtigste Größe | Taktzeit und Verfügbarkeit | Nachvollziehbarkeit bei vielen Vorgängen | Schnell die richtige Information finden |
| Typischer Engpass | Netzstörung stoppt die Linie | Unklarer Soll-Stand je Variante | Wissen steckt in Köpfen und Tickets |
| Sinnvolle Maßnahme | Lokaler Puffer, definierter Notbetrieb | Stufen-Rollout mit Rückmeldung | Suche und Assistent mit Quellenangabe |
| Messgröße | Ausfallzeit, Antwortzeit je Vorgang | Erfolgsquote je Rollout-Stufe | Lösungszeit, Anteil gelöster Erstanfragen |
Legen Sie diese Anforderungen je Gruppe fest, bevor Sie über Technik sprechen. Daraus ergibt sich, welche Dienste getrennt betrieben, getrennt skaliert und getrennt ausgerollt werden müssen.
Varianten unterschätzt. Der richtige Softwarestand hängt selten nur vom Modell ab, sondern von Ausstattung, Steuergeräte-Hardware und Vorgängerstand. Wer diese Abhängigkeiten nicht als Daten modelliert, pflegt sie später in Tabellen neben dem System.
Freigabe außerhalb des Systems. Kommen Freigaben per E-Mail oder als Haken in einer Tabelle, ist die Kette vom Stand bis zum Fahrzeug nicht mehr belegbar. Freigaben gehören als eigener Schritt mit Verantwortlichem in die Plattform.
Kein Rückkanal. Ein Update gilt erst als erledigt, wenn das Ergebnis zurückgemeldet ist. Ohne Rückmeldung kennen Sie nur den Soll-Stand, nicht den Ist-Stand.
Rollout ohne Abbruchkriterium. Legen Sie vor jeder Stufe fest, ab welcher Fehlerquote gestoppt wird, und wer das entscheidet. Mitten im Rollout wird diese Frage sonst unter Zeitdruck verhandelt.
Wie sich Software am Band zuverlässig aufspielen lässt, zeigt ein früheres Projekt unseres Gründers bei einem Hausgerätehersteller: eine Cloud-Plattform für Produktionssteuerung und Firmware-Flashing, die in 8 Werken von über 1.000 Nutzern täglich verwendet wurde.
KI lohnt sich, wo Menschen in großen, gut gepflegten Inhalten suchen oder aus vielen ähnlichen Fällen den nächsten Schritt ableiten. Sie hilft wenig, wenn die Inhalte selbst veraltet oder widersprüchlich sind: Ein Assistent findet dann schneller die falsche Stelle. Prüfen Sie deshalb zuerst, wer die Diagnose- und Serviceinhalte pflegt und wie aktuell sie sind. Zweitens braucht jede KI-Funktion eine Definition von Qualität, bevor sie ausgerollt wird. Wie man die Antwortqualität eines Retrieval-Assistenten misst, haben wir im Beitrag RAG-Antwortqualität messen beschrieben.
Für Fahrzeuge regelt die Typgenehmigung nach Verordnung (EU) 2019/2144 auch Cybersicherheit und Software-Updates. Sie verweist dafür auf die UN-Regelung Nr. 155 (Cybersecurity-Managementsystem) und die UN-Regelung Nr. 156 (Software-Update-Managementsystem, kurz SUMS). Der Cyber Resilience Act (CRA) der EU gilt nach Art. 2 Abs. 2 Buchst. c nicht für Produkte mit digitalen Elementen, für die diese Typgenehmigungsverordnung gilt. Für andere vernetzbare Hardware und Software gelten nach Angaben der EU-Kommission die Meldepflichten des CRA seit dem 11. September 2026 und die Hauptpflichten ab dem 11. Dezember 2027. Für eine Update-Plattform laufen beide Regelwerke technisch auf ähnliche Grundlagen hinaus: ein belastbares Verzeichnis der ausgelieferten Softwarestände und ein nachvollziehbarer, abgesicherter Verteilweg. Welche Regeln für Ihr Produkt gelten, ist eine rechtliche Einzelfallfrage, die Sie mit Ihrer Rechtsabteilung klären. Rechtsstand: 29.09.2026, dieser Abschnitt ist allgemeine Information und keine Rechtsberatung.
Beginnen Sie nicht mit der größten Nutzergruppe, sondern mit dem Prozess, dessen Engpass am klarsten messbar ist. Ein gut abgegrenzter Pilot, etwa eine Rollout-Stufe oder ein Serviceprozess, liefert Kennzahlen, mit denen sich die nächsten Schritte begründen lassen. Steht ein gewachsenes Diagnosesystem im Weg, hilft ein Software-Architektur-Review als erster Schritt, bevor Sie über Neubau oder Migration entscheiden. Die Kriterien dafür beschreibt unser Beitrag Software modernisieren oder neu entwickeln.
Qualität
Vorgehen
Welche Daten fließen zwischen Entwicklung, Werk und Aftersales, wer braucht sie wann, und wo hakt es heute.
2 bis 3 Wochen
Plattformschnitt, Schnittstellen, Rollen- und Freigabemodell, Betriebskonzept und ein priorisierter Backlog.
2 bis 4 Wochen
Ein nutzbarer Ausschnitt, getestet mit echten Anwendern, zum Beispiel an einem Standort oder in einem Serviceprozess.
nach Umfang
Weitere Standorte und Nutzergruppen nacheinander, jeweils mit Kennzahlen und Rückweg.
nach Umfang
Monitoring, Releases über Pipelines und Weiterentwicklung auf Basis gemessener Nutzung.
laufend
Vor Ort
Diagnose- und Update-Prozesse versteht man am besten dort, wo sie ablaufen: am Bandende, an dem Software aufgespielt und geprüft wird, oder am Arbeitsplatz im technischen Support, an dem ein schwieriger Fall eskaliert. Deshalb schauen wir uns die Abläufe zu Beginn nach Absprache gern vor Ort an und sprechen mit den Menschen, die täglich mit dem System arbeiten. Von unserem Sitz in Olching sind Standorte in München und im Umland gut erreichbar. Architektur, Entwicklung und Betrieb laufen danach überwiegend remote, abgestimmt auf die Sicherheitsvorgaben Ihres Hauses.
Software und KI im Landkreis FürstenfeldbruckIhr Nutzen
Technologien und Methoden
Praxisbeispiele
Die Kennzahlen stammen aus Projekten, die unser Gründer in verantwortlicher Rolle bei Herstellern und Zulieferern umgesetzt hat, nicht im Auftrag von Amperbytes AI.
KI · Automotive
LLM-Assistent mit Retrieval (RAG) für einen Diagnose-Service auf Google Cloud, Antwortqualität per KPIs gemessen. Praxisbeispiel unseres Gründers.
KI · Automotive
ML-Empfehlungssystem für die Fahrzeugdiagnose, mit dem Fachbereich identifiziert, produktiv gesetzt, per KPIs gemessen. Praxisbeispiel unseres Gründers.
Cloud · Automotive
Legacy-Diagnosesystem in eine Microservice-Plattform auf Google Cloud überführt, mit CI/CD, Containern und Terraform. Praxisbeispiel unseres Gründers.
MES · Hausgerätefertigung
Cloud-Plattform auf Google Cloud und Firebase für Produktionssteuerung und Firmware-Flashing in der Fertigungslinie. Praxisbeispiel unseres Gründers.
Wissen
KI · 9 Min. Lesezeit
RAG-Evaluation in der Praxis: welche Metriken zählen, wie Sie ein Test-Set aus echten Fragen bauen und Halluzinationen im KI-Chatbot erkennen und senken.
Software · 9 Min. Lesezeit
Software modernisieren oder neu entwickeln? Die 7R, Lift and Shift vs. Refactoring und das Strangler-Fig-Muster, mit Entscheidungstabelle.
Häufige Fragen
Wir entwickeln die Backend-, Cloud- und Prozesssysteme rund um das Fahrzeug: Diagnoseplattformen, Software-Update-Prozesse, produktionsnahe Software für Flashing und Prüfung sowie Aftersales-Software. Dazu kommen KI-Funktionen wie Assistenten mit Retrieval und Empfehlungssysteme. Software, die im Fahrzeug oder im Steuergerät läuft, entwickeln wir nicht.
Nein. Wir bauen Backend- und Cloud-Plattformen für OEM-Teams, also für Fachbereiche und Produktverantwortliche bei Fahrzeugherstellern, keine Diagnosegeräte oder Tester-Software für einzelne Werkstätten. Wenn Sie als Werkstatt ein Diagnosegerät suchen, sind spezialisierte Gerätehersteller und der Werkstattfachhandel die richtige Adresse.
Ja. In Diagnose- und Update-Vorhaben geht es nicht ohne diese Zusammenarbeit. Die Embedded-Teams verantworten die Software im Steuergerät, wir die Plattform, die Softwarestände verwaltet, Diagnosedaten verarbeitet und Prozesse abbildet. An der Schnittstelle klären wir früh Datenformate, Freigabewege und Verantwortlichkeiten.
Jeder Softwarestand bekommt eine eindeutige Identität, jede Freigabe einen Verantwortlichen und einen Zeitpunkt, und jeder Update-Vorgang meldet sein Ergebnis zurück. Rollouts laufen in Stufen mit vorher festgelegten Abbruchkriterien. So lässt sich für jedes Fahrzeug oder Bauteil beantworten, welcher Stand wann aufgespielt wurde und wer ihn freigegeben hat.
Ein Assistent mit Retrieval antwortet auf Basis der gefundenen Diagnose- und Serviceinhalte und nennt seine Quellen, statt aus dem Modellgedächtnis zu formulieren. Vor dem Rollout legen wir mit dem Fachbereich fest, was eine gute Antwort ist, und messen das im Betrieb. Wie ein solcher Assistent aufgebaut wird, zeigt unser Leistungsangebot für KI-Chatbots.
Ja. Wir migrieren schrittweise mit Parallelbetrieb, damit Werk und Aftersales während der Umstellung weiterarbeiten können. Grundlage sind eine Zielarchitektur, automatisierte Pipelines und ein Rückfallweg für jede Etappe. Das Vorgehen im Detail beschreibt unsere Leistung zur Legacy-Modernisierung.
Ja. Für Diagnose-, Update- und Aftersales-Vorhaben übernehmen wir die Rolle des Product Owners oder Solution Architects in Ihrem Team, etwa für den Aufbau einer Plattform oder eine Übergangsphase. Wir arbeiten dabei mit Ihren Entwicklungsteams und Dienstleistern zusammen.
Die größten Kostentreiber sind die Zahl der angebundenen Systeme, die Menge an Fahrzeug- und Steuergerätevarianten, die Anforderungen an Verfügbarkeit und Nachvollziehbarkeit sowie die internen Freigabe- und Sicherheitsprozesse. Auch der Zustand eines abzulösenden Altsystems spielt eine große Rolle. Eine belastbare Schätzung geben wir nach der Prozess- und Systemanalyse.
Direkter Kontakt
Sie sprechen direkt mit unserem Gründer
Gründer und Solution Architect: iSAQB CPSA · Certified ScrumMaster · M.Sc. Wirtschaftsingenieurwesen. Olching bei München, Termine vor Ort nach Absprache.
Passende Leistungen
Gewachsene Systeme Schritt für Schritt modernisieren und in die Cloud überführen, während sie weiterlaufen: Zielarchitektur, automatisierte Pipelines, Container und reproduzierbare Umgebungen.
Ein interner Wissensassistent, der Fragen aus Ihren eigenen Dokumenten beantwortet, jede Antwort mit Quelle belegt und nur zeigt, was der Nutzer sehen darf.
Externer Solution Architect oder Interim Product Owner für Ihr Softwarevorhaben: Zielarchitektur, Roadmap, Backlog und fachliche Führung des Teams, auf Zeit und mit geplanter Übergabe.
Beschreiben Sie uns kurz, welche Nutzergruppen beteiligt sind und woran es heute hakt. Im Erstgespräch klären wir, ob wir zu Ihrem Vorhaben passen und womit Sie sinnvoll beginnen.