Continental hat mit Unterstützung von Microsoft und NTT DATA ein KI-basiertes Analysewerkzeug entwickelt, das Lastenhefte automatisiert analysiert, strukturiert und auf Konsistenz prüft. Ziel ist es, das bislang stark manuelle Requirements Engineering effizienter und skalierbarer zu gestalten. Im Interview erläutern Dr. Jörg Dietrich, Head of AI for R&D (Bild links) und Michael Sicker, Program Management Automotive R&D Transformation von Continental die Hintergründe und das Potenzial für die Automotive-Entwicklung.
AEEmobility: Sie haben mit Microsoft und der IT-Beratung NTT DATA ein neues Analysewerkzeug entwickelt, das KI-basierte Methoden nutzt, um Anforderungen automatisiert zu strukturieren, zu prüfen und auszuwerten. Was war eigentlich der Auslöser für dieses Projekt? Gab es einen konkreten Anlass oder war das schon länger geplant?
Dr. Jörg Dietrich: Der Impuls kam im Rahmen eines größeren Transformationsprojekts, das wir 2023 gestartet haben. Das Projekt hatte zum Ziel, unsere Entwicklungsprozesse systematisch zu analysieren und effizienter zu gestalten. Dabei wurde deutlich: Unsere Entwicklungsarbeit ist grundsätzlich auf einem guten Niveau, was die Effizienz betrifft. Allerdings waren viele Aufgaben noch manuell und wiederholend – insbesondere im Umgang mit den zahlreichen technischen und regulatorischen Anforderungen, die in Form von Dokumenten auf uns zukommen.
Gerade im Kontext kürzerer Entwicklungszyklen – wir sprechen von maximal zwei Jahren vom ersten Konzept bis zur industrialisierten Hardware – wurde klar: Wir müssen früher und klarer wissen, was der Kunde möchte. Denn solange die Anforderungen nicht eindeutig sind, können weder Software- noch Hardwareentwicklung richtig starten.
Michael Sicker: Wir haben festgestellt, dass allein für die Analyse und Aufbereitung der Anforderungen in der Vergangenheit bis zu 40.000 Stunden pro Projekt aufgewendet wurden. Diese Zeit wollten wir drastisch reduzieren. Das neue Tool soll genau dabei helfen – damit unsere Entwickler möglichst früh mit der eigentlichen Produktentwicklung beginnen können.
Diese 40.000 Stunden pro Projekt beziehen sich auf komplexere Entwicklungsprojekte – bei weniger komplexen liegt der Aufwand natürlich darunter. Man darf dabei nicht vergessen: In den wenigsten Fällen erhalten wir mit der ersten Übermittlung des Lastenhefts ein vollständig finalisiertes Dokument. Es ist nicht so, dass wir am Tag 1 schon alle Informationen haben, um das gesamte Programm bis zum Produktlaunch durchzuplanen.
In der Realität kommen im Projektverlauf zahlreiche Änderungen hinzu – und jede einzelne muss bewertet und nachvollzogen werden. Genau hier bringt unser Tool einen weiteren entscheidenden Vorteil: Wir können die Änderungen wesentlich schneller und gezielter analysieren, zum Beispiel indem wir den Anforderungsstand von Januar mit dem von Dezember intelligent vergleichen. Das beschleunigt das gesamte Change-Management erheblich und sorgt dafür, dass wir frühzeitig wissen, wo sich Anforderungen verändern – und was das konkret für Architektur, Software und Hardware bedeutet.
Welche zusätzlichen Funktionalitäten sind seit der letzten Pressemitteilung im März hinzugekommen?
Dr. Jörg Dietrich: Da hat sich tatsächlich einiges getan. Ein zentrales neues Feature ist die Möglichkeit, Kundenlastenhefte, die als PDF vorliegen, automatisiert zu extrahieren und in ein Format zu überführen, das mit unserem internen Requirements-Management-Tool kompatibel ist. Dabei erkennen wir strukturelle Elemente wie Überschriften, funktionale und nicht-funktionale Anforderungen, Sicherheitsaspekte oder spezifische Zuordnungen – beispielsweise zu Hardware, Software, System, Quality oder Test. Diese Informationen lassen sich dann automatisiert den jeweils zuständigen Disziplinverantwortlichen zuweisen.
Dr. Jörg Dietrich, Head of AI for R&D bei Continental: „Wir müssen früher und klarer wissen, was der Kunde möchte. Denn solange die Anforderungen nicht eindeutig sind, können weder Software- noch Hardwareentwicklung richtig starten.“ (© Continental)
Neu ist auch das sogenannte Feature-Mapping. Unsere Produkte haben jeweils einen definierten Feature-Satz, und wir können nun Anforderungen aus den Lastenheften direkt zu einem bestimmten Feature unseres Portfolios zuordnen – etwa Feature 1, 2, 3 oder 4.
Ein weiterer Fortschritt ist unser intelligenter Versionsvergleich: Wenn wir aktualisierte Versionen eines Lastenheftes erhalten, hilft uns unsere KI beim Vergleich. Dabei geht es nicht nur um formale Unterschiede – wie sie ein einfacher Word-Vergleich erkennen würde – sondern um inhaltlich-intelligente Vergleiche, auch wenn sich die Struktur des Dokuments grundlegend verändert hat.
Und schließlich haben wir ein Übersetzungsmodul integriert. Viele Lastenhefte, insbesondere aus dem asiatischen Raum, kommen auf Chinesisch, Japanisch oder Koreanisch. Unser Tool übersetzt diese Dokumente zuverlässig in unsere Arbeitssprachen – primär Deutsch und Englisch. Das ist essenziell, weil wir international entwickeln. Wir arbeiten mit Teams in Osteuropa, Asien und anderen Regionen zusammen – viele unserer Entwickler sprechen kein Deutsch. Daher müssen wir auch deutschsprachige Lastenhefte in eine einheitliche, englischsprachige Fassung überführen, um eine effiziente Weiterverarbeitung sicherzustellen.
Wie weit sind die Kunden mit eingebunden? Müssen die ein ähnliches Tool nutzen oder geben die weiterhin Word- oder PDF-Dokumente ab?
Michael Sicker: In der Praxis ist es so, dass viele unserer Kunden ihre Lastenhefte nach wie vor als PDF schicken. Das ist der aktuelle Standard, auch wenn es für die Weiterverarbeitung nicht ideal ist. Genau deshalb ist die PDF-Extraktion für uns ein wesentlicher Effizienzgewinn. Sie ermöglicht es, Anforderungen automatisiert aus den Dokumenten zu extrahieren und strukturiert weiterzuverarbeiten. Es gibt allerdings auch einige wenige Kunden, die bereits ein strukturiertes Austauschformat nutzen – also Daten, wie sie in klassischen Requirements-Management-Tools erzeugt werden. Das ist natürlich deutlich effizienter. Wir haben das auch in Gesprächen mit einzelnen Kunden aktiv angesprochen. Die Rückmeldungen waren grundsätzlich positiv, und man erkennt den Vorteil. Aber realistisch betrachtet wird es noch etwas dauern, bis sich das flächendeckend durchsetzt.
Michael Sicker, Program Management Automotive R&D Transformation bei Continental: „Die PDF-Extraktion ist für uns ein wesentlicher Effizienzgewinn. Sie ermöglicht es, Anforderungen automatisiert aus den Dokumenten zu extrahieren und strukturiert weiterzuverarbeiten.“ (© Continental)
Deshalb sehen wir auch langfristig einen klaren Nutzen für unsere Lösung – insbesondere im Bereich der PDF-Extraktion. Das automatisierte Ausleiten von Anforderungen aus Dokumenten egal ob kundenseitig oder auch aus sogenannten “Legal Technical Regulations” bleibt ein zentraler Anwendungsfall. Und das ist eben etwas, was herkömmliche Tools so noch nicht leisten.
Das Tool nutzt KI zur Analyse von Lastenheften – vereinfacht gesagt. Können Sie erläutern, welche konkreten Modelle oder Verfahren dabei zum Einsatz kommen?
Dr. Jörg Dietrich: Da kommen ganz unterschiedliche Verfahren zum Einsatz, je nach Modul und Funktionalität innerhalb der Lösung. Die Module, die ich eingangs erwähnt habe, greifen auf verschiedene KI-Modelle zurück. Wir nutzen selbstverständlich auch große Sprachmodelle der bekannten Anbieter – das ist die Grundlage vieler Funktionen.
Es handelt sich dabei aber nicht nur um eine einfache Integration bestehender KI, sondern um eine echte Co-Entwicklung, unter anderem gemeinsam mit Microsoft und NTT Data. Im Rahmen dieser Zusammenarbeit greifen wir auch auf die Sprachmodelle zu, die Microsoft über seine Azure-Cloud-Plattform bereitstellt. Ein wesentlicher Unterschied und zugleich eine besondere Stärke unserer Lösung liegt allerdings darin, dass wir Sprachmodelle zusätzlich auf unsere spezifischen Daten bei Continental angepasst haben. In der KI-Fachsprache spricht man hier von Finetuning. Das bedeutet: Wir starten nicht bei null, wie man es bei einem kompletten LLM-Training mit Milliarden von Tokens machen müsste, sondern wir verfeinern ein bereits vortrainiertes Modell mit unseren eigenen, domänenspezifischen Daten – also mit Anforderungen, Begrifflichkeiten und Zusammenhängen, wie sie speziell in der Automobilentwicklung vorkommen. Durch dieses gezielte Finetuning mit Automotive-nahen Daten erzielen wir eine deutlich höhere Qualität bei der Analyse und Verarbeitung von Lastenheften – insbesondere im Vergleich zu generischen KI-Modellen, die nicht auf den Kontext eines Automobilzulieferers abgestimmt sind.
Sie haben eingangs erwähnt, dass Sie auch Safety- und Security-Requirements mit dem Tool bearbeiten. Wie stellen Sie sicher, dass solche kritischen Anforderungen zuverlässig erkannt, korrekt interpretiert und richtig zugeordnet werden? Gibt es da eine Art Rückkopplungsschleife – etwa durch menschliche Kontrolle?
Michael Sicker: Ja, gerade bei Themen wie Safety und Security ist das ganz klar geregelt: Da schauen unsere Entwickler oder Fachexperten in jedem Fall nochmal drüber. Das Tool ist grundsätzlich so ausgelegt, dass es unsere Teams unterstützt – es handelt sich also nicht um eine vollautomatische Analyse, bei der das Lastenheft komplett ohne menschliches Zutun verarbeitet wird. Es ist immer ein Review durch qualifiziertes Personal vorgesehen.
Trotz dieser manuellen Absicherung bringt das System aber einen erheblichen Effizienzgewinn, weil es die Dokumente vorstrukturiert, Anforderungen klassifiziert und auch inhaltlich vorbewertet. Dabei spielt der Confidence-Score, den das KI-Modell für jede Klassifikation mitliefert, eine zentrale Rolle: Dort, wo das Modell eine hohe Sicherheit angibt, kann man mit geringem Aufwand validieren. Bei niedrigerem Score wird gezielt nachgeschärft. Das heißt: Das System erkennt nicht nur Anforderungen, sondern bewertet auch, wie sicher es sich bei der Einordnung ist. Damit haben unsere Ingenieure eine fundierte Entscheidungsgrundlage, wo ein genauer Blick nötig ist. Vor allem bei komplexen oder sicherheitsrelevanten Anforderungen ist das eine sinnvolle Kombination aus KI-Effizienz und menschlicher Expertise.
Sie haben die Effizienzsteigerung durch das Tool angesprochen. Gibt es dazu belastbare Benchmarks oder konkrete Messgrößen? Wie wurde das getestet?
Dr. Jörg Dietrich: Ja, wir haben das sehr systematisch untersucht – und zwar im Rahmen einer umfassenden Analyse unserer Entwicklungsaktivitäten. Dabei haben wir bewusst alle relevanten Disziplinen einbezogen: klassischerweise IMS-Engineering, Software-Engineering, Hardware-Engineering. Gemeinsam mit Kolleginnen und Kollegen aus diesen Bereichen haben wir reale Projektbeispiele ausgewählt und analysiert.
Ein konkretes Beispiel war ein Lastenheft mit rund 170 Seiten. Dieses Dokument wurde zunächst ganz klassisch, also ohne KI-Unterstützung, manuell analysiert – und zwar von mehreren Personen. Wichtig war uns dabei, nicht nur eine Einzelperson oder ein einzelnes Dokument zu betrachten, sondern mit mehreren Fachkräften, aus unterschiedlichen Projekten und auch aus verschiedenen kulturellen Hintergründen zu arbeiten. So konnten wir eine möglichst breite Datenbasis schaffen.
Im Anschluss wurde denselben Teams das KI-gestützte Tool zur Verfügung gestellt. Damit konnten sie dann die gleiche Analyse erneut durchführen – dieses Mal eben unterstützt durch die automatisierte Klassifikation, Extraktion und Zuordnung der Anforderungen. Der direkte Vorher-Nachher-Vergleich ermöglichte uns eine präzise Bewertung der Effizienzgewinne, aber auch der Nutzerakzeptanz und der Qualität der Ergebnisse. Das gesammelte Feedback wurde iterativ in die Weiterentwicklung des Tools integriert – mit dem Ziel, die Unterstützung möglichst praxisnah und an den tatsächlichen Anforderungen unserer Engineering-Teams auszurichten.
Wie hoch war denn der Schulungsaufwand für die Entwickler, und wie wurde das Tool in der Organisation angenommen?
Michael Sicker: Wir haben bewusst einen Ansatz gewählt, der auf Akzeptanz und Praxistauglichkeit ausgelegt war – und das hat sich als essenziell erwiesen. Konkret haben wir unsere Requirements Manager und Ingenieure ganz bewusst ins Zentrum der Entwicklung gestellt. Das heißt: Die Lösung wurde nicht zentral in einem Elfenbeinturm entwickelt, sondern von Anfang an gemeinsam mit den Key Usern erarbeitet, die später auch damit arbeiten sollen. Diese Kolleginnen und Kollegen waren in allen agilen Entwicklungszyklen, also in den Zeremonien, Reviews und Sprint-Planungen, aktiv beteiligt. Sie hatten echten Einfluss auf die Toolgestaltung und konnten ihre Anforderungen direkt einbringen. Dadurch haben wir nicht nur ein funktional passendes System gebaut, sondern auch eine sehr hohe Identifikation mit dem Tool geschaffen.
Diese Key User fungieren heute als Multiplikatoren: Wenn jemand aus dem eigenen Team das Tool erklärt und dabei auf echte, eigene Erfahrung zurückgreifen kann, ist die Vertrauensbasis eine ganz andere, als wenn jemand extern das Tool vorstellt. Gerade in der Kommunikation beim Rollout – in Meetings, in regelmäßigen Formaten – ist es entscheidend, dass jemand präsent ist, den die Zielgruppe kennt und respektiert.
Der Schulungsaufwand selbst war dadurch vergleichsweise gering, weil das Wissen organisch in die Teams getragen wurde. Die Anwender hatten durch ihre Einbindung schon vor der eigentlichen Einführung ein gutes Verständnis dafür, wie das Tool funktioniert und welchen Nutzen es bringt. Und genau dieser Hebel – „entwickelt mit euch, für euch“ – hat ganz wesentlich dazu beigetragen, dass die Akzeptanz durchweg hoch war. Widerstände im klassischen Sinn gab es kaum – eher im Gegenteil: Es entstand eine gewisse Neugier und Aufgeschlossenheit gegenüber dem System.
Die verarbeiteten Daten werden ja auf Servern gespeichert – vermutlich in der Cloud. Wie wird in diesem Zusammenhang mit Datenschutz und Vertraulichkeit umgegangen? Besonders im Hinblick auf Kundenanforderungen, die häufig unter NDA stehen?
Dr. Jörg Dietrich: Das Thema Datenschutz und Vertraulichkeit hat bei uns oberste Priorität – insbesondere, da es sich bei den verarbeiteten Lastenheften um vertrauliche Kundendaten handelt, die unter strengen Geheimhaltungsverpflichtungen stehen.
Zunächst einmal: Die Daten verbleiben in Europa. Die von uns genutzte Cloud-Infrastruktur – in diesem Fall von Microsoft – ermöglicht es, Regionen eindeutig festzulegen. Wir haben bewusst sichergestellt, dass keine Daten in Drittstaaten wie die USA übertragen werden. Das Hosting erfolgt in europäischen Rechenzentren, die den geltenden Datenschutzstandards entsprechen, insbesondere der DSGVO.
Darüber hinaus wurde die gesamte Lösung durch unsere unternehmensinterne Cybersecurity- und Rechtsabteilung geprüft und freigegeben. Dabei wurde sichergestellt, dass sowohl unsere internen Informationssicherheitsstandards eingehalten werden als auch alle vertraglichen Verpflichtungen gegenüber unseren Kunden. Die eingesetzten Cloud-Umgebungen sind dediziert abgesichert und für genau diesen Zweck konzipiert worden. Wir können also mit gutem Gewissen sagen: Datenschutz, Vertraulichkeit und Informationssicherheit sind vollständig gewährleistet – sowohl technisch als auch organisatorisch.
Lastenhefte sind je nach Kunde oder Zulieferer sehr unterschiedlich aufgebaut. Spielt diese Heterogenität für Ihr System noch eine Rolle? Oder kann das Tool unabhängig von Struktur und Format arbeiten? Gibt es bestimmte Anforderungen an den Aufbau der Dokumente?
Dr. Jörg Dietrich: Das ist ein sehr wichtiger Punkt – und tatsächlich hat sich an dieser Ausgangssituation nicht viel geändert. Lastenhefte kommen nach wie vor in ganz unterschiedlichen Qualitäten und Strukturen bei uns an, je nach Kunde, Region oder Fachbereich. Und wir gehen auch nicht davon aus, dass sich das in absehbarer Zeit grundlegend ändern wird. Es ist schlicht nicht realistisch, Kunden dazu zu bringen, ihre Anforderungen entlang eines Continental-Standards zu übermitteln. Dafür sind die Abläufe auf Kundenseite zu unterschiedlich.
Genau deshalb war es für uns ein zentrales Entwicklungsziel, dass unser Tool mit jeder Form von Lastenheft umgehen kann – egal ob klar strukturiert oder unstrukturiert. Das System soll nicht nur bei „guten“ Lastenheften funktionieren, sondern eben auch dann, wenn die Inhalte unübersichtlich, inkonsistent oder sprachlich uneindeutig sind. Die Qualität des Ergebnisses – also der extrahierten, analysierten und klassifizierten Anforderungen – muss immer auf dem höchsten Niveau sein, unabhängig vom Inputformat.
Natürlich gibt es Unterschiede: Ein Lastenheft mit klarer Kapitelstruktur und sauberer Nummerierung ist für die Analyse leichter zu handhaben. Aber das Tool ist so konzipiert, dass es auch mit schwierigen Dokumenten arbeiten kann, z. B. mit redundanten, verschachtelten oder nicht eindeutig formulierten Anforderungen. Und genau darin liegt ein großer Mehrwert: Die gesamte Bandbreite an Kundenformaten kann abgedeckt werden, ohne dass auf Kundenseite etwas umgestellt werden muss.
Lässt sich das Tool auch auf andere Engineering-Prozesse übertragen? Gibt es weitere Projekte oder Anwendungsfelder im Bereich des V-Modells?
Michael Sicker: Ja, absolut. Unsere übergeordnete Vision ist es, entlang des gesamten V-Modells KI-Unterstützung in den Entwicklungsprozess zu integrieren. Wir haben mit dem Einstieg bei den Requirements bewusst am linken oberen Ende begonnen – dort, wo die Spezifikation entsteht und viele Informationen unstrukturiert oder semi-strukturiert vorliegen. Aber es gibt auch Initiativen im Bereich Code- und Testfallgenerierung und Script-Erstellung. Auch dort laufen bereits Aktivitäten mit dem Ziel, wiederkehrende Aufgaben durch KI zu automatisieren oder zu beschleunigen.
Langfristig wollen wir diese punktuellen Lösungen zu einer durchgängigen KI-gestützten Toolchain entlang des gesamten V-Prozesses weiterentwickeln – vom präzisen Anforderungs- und Systemdesign über die strukturierte Entwicklung und Implementierung bis hin zu nahtloser Integration sowie Verifikation und Validierung zu einem serienreifen Gesamtprodukt. Noch haben wir dafür keine vollständigen Tools in allen Bereichen, aber wir arbeiten daran und nutzen die vorhandene KI-Kompetenz im Haus, um hier gezielt Kompetenz- und Wettbewerbsvorsprung aufzubauen.
Die Grundlage dafür ist geschaffen – sowohl technologisch als auch organisatorisch. Jetzt geht es darum, weitere Anwendungsfelder systematisch zu identifizieren und prototypisch umzusetzen, um dann schrittweise zu skalieren.
Vielen Dank für das Gespräch!
(Das Interview führte Klaus Oertel, Chefredakteur der AEEmobility)
