Kabelbaumkomplexität: KI-gestützte Engineeringautomatisierung

Das echte Ausmaß des Problems

Ein modernes Serienfahrzeug enthält im Schnitt über zweieinhalb Kilometer Leitungen in hunderten von Einzelsträngen, bis zu 3.000 Steckverbindern und wiegt als Kabelbaum allein zwischen fünfzehn und dreißig Kilogramm. Bei einem OEM mit drei Baureihen, jeweils in Verbrenner-, Hybrid- und BEV-Ausführung und mehreren Ausstattungslinien, ergeben sich schnell mehrere hundert bis über tausend zulässige Kabelbaum-Konfigurationen — pro Baureihe.

Der Grund für diese Explosion liegt nicht in schlechter Planung, sondern in der Physik: Jede neue Funktion, jedes neue ADAS-Modul, jeder neue Antriebsstrang bedeutet neue Leitungswege, neue Absicherungskonzepte, neue Steckergehäuse. Der EV-Anteil verschärft das Problem — Hochvolt-Systemverkabelung, Batteriemanagement, Ladekommunikation und redundante Sicherheitsbordnetze für ASIL-D-Funktionen (Lenkung, Bremse) kommen zur bereits bestehenden Komplexität des Niedervoltnetzes hinzu, statt sie zu ersetzen.

Was das für den Entwicklungsaufwand bedeutet:

• Ein erfahrener Harness-Engineer braucht für eine neue Kabelbaum-Variante typischerweise zwei bis sechs Wochen — Geometrie-Integration, Routing, DRC, Kabelliste, Fertigungsdokumentation
• Manuelle DRC-Prüfungen identifizieren laut Cadonix-Studie Fehler im Schnitt 60–80 % später im Entwicklungsprozess als automatisierte Systeme — was Nacharbeit in der Teuerungszone erzwingt
• Über zwei Drittel aller Kabelbaumrückrufe gehen auf Designfehler zurück, nicht auf Produktionsfehler — laut Auswertung von Rückrufdaten durch Altium (2024)
• Die Vorlaufzeit vom Designfreeze bis zur lieferbaren Kabelbaum-Einheit beträgt typischerweise 23–26 Wochen — eine Zeitspanne, die jede Änderung in der Fahrzeugentwicklung direkt auf SOP-Termine durchschlagen lässt

Ein Rückruf wegen mangelhaft geroutetem Kabelbaum hat 2024 bei einem großen EV-Hersteller über 400 Fahrzeuge betroffen — verursacht durch Isolationsverschleiß an einer Getriebeverkabelung, die zu nah am Antriebswellenbereich verlegt war. Ein Fehler, den ein automatisiertes DRC-System in Sekunden erkannt hätte, bevor das Design die Fertigungsfreigabe erhielt.

Mit vs. ohne KI — ein ehrlicher Vergleich

Wichtige Einschränkung: Diese Zahlen gelten für Unternehmen, die KI-Routing auf einer konsolidierten, sauber gepflegten Designdatenbasis fahren. Wer noch keine konsistente Variantenverwaltung und keinen standardisierten KBL/VEC-Datenaustausch mit dem OEM betreibt, wird diese Verbesserungen erst nach einer Infrastrukturphase sehen — was 6–12 Monate Vorlaufarbeit bedeuten kann.

Einschätzung auf einen Blick

Zeitersparnis — sehr hoch (5/5) Das ist der dominante Vorteil: KI-gestütztes Routing reduziert die Engineering-Zeit pro Variante um 50–77 % — mit dem Benchmark-Wert aus der gemeinsamen Fallstudie von RLE INTERNATIONAL und Synera (2024). Kein anderer Anwendungsfall in der Automotive-Kategorie bietet einen vergleichbar direkten Hebel auf Entwicklungskapazität. Die Zeitersparnis ist nicht indirekt (weniger Rückfragen) oder bedingt (wenn Daten gut genug sind) — sie entsteht im Kernprozess, bei jedem Variant-Engineering-Zyklus.

Kosteneinsparung — mittel (3/5) Die Einsparung ist real, aber komplex zu isolieren: Weniger manueller Aufwand, weniger Änderungsschleifen, weniger Fertigungsfehler — all das spart Geld. Aber der direkte ROI hängt stark von der Variantenanzahl ab. Wer 500 Varianten pro Jahr bearbeitet, hat nach zwei Jahren eine klar positive Bilanz. Wer 30 Varianten hat, muss die Amortisation sehr genau durchrechnen. Im Vergleich zu Qualitätsprüfungs- oder Rückrufkosten-Einsparungen — die unter den verglichenen Anwendungsfällen deutlich direkter messbar sind — ist die Kostenwirkung hier eine Funktion des Umfangs.

Schnelle Umsetzung — sehr niedrig (1/5) Ehrlichstes 1 in dieser Kategorie. Die Integration eines KI-gestützten Routing-Systems in eine bestehende Kabelbaum-Entwicklungsumgebung dauert 12–24 Monate. Datenmigration, Tool-Integration, Training der Konstruktionsteams, Aufbau der Variantenbibliothek und OEM-Abstimmung über Datenformate sind zusammen ein Programm, kein Projekt. Wer hier mit 3 Monaten rechnet, wird enttäuscht sein. Auch NVH-Anomalieerkennung am Elektromotor-Prüfstand oder Predictive Maintenance lassen sich deutlich schneller pilotieren.

ROI-Sicherheit — mittel (3/5) Der ROI tritt ein, aber erst ab Monat 18–24. Bis dahin sind erhebliche Vorlaufkosten gebunden — Lizenzen, Integration, Schulung, Datenmigration. Wer nicht mindestens 80 aktive Harness-Varianten pro Jahr im Engineering hat, muss die Rechnung sehr konservativ aufstellen. Der ROI ist dann nicht schlecht, aber das Szenario “drei Jahre, um profitabel zu werden” ist keine Ausnahme, sondern die Regel.

Skalierbarkeit — sehr hoch (5/5) Hier ist das Gegenbild zur schwierigen Einführung: Wer einmal ein KI-fähiges Routing-System integriert hat, kann es auf alle Baureihen, alle Plattformen und alle zukünftigen Fahrzeugprojekte ausrollen. Neue Varianten kosten einen Bruchteil des Aufwands für die erste. Eine Parametrisierung des Basisdesigns erlaubt die Ableitung von Hunderten von Varianten in Tagen. Das ist eine strukturelle Skalierbarkeit — kein proportionaler Anstieg des Engineering-Aufwands mit dem Variantenvolumen mehr, sondern ein flacher Grenzkostenanstieg.

Richtwerte — stark abhängig von Variantenanzahl, OEM-Datenvorgaben, Reife der Bestandsdaten und vorhandener PLM-Infrastruktur.

Was das System konkret macht

Machine Learning-gestütztes Kabelbaum-Engineering funktioniert auf drei Ebenen, die zusammenwirken:

Ebene 1: Geometrisches Routing Das System kennt die Fahrzeuggeometrie aus dem MCAD-System (Siemens NX, CATIA, Creo) und den Verlegefreiraum aus dem Karosserie-Modell. Auf dieser Grundlage berechnet es — typischerweise mit Pathfinding-Algorithmen oder Deep Learning-Modellen — optimale Kabelwege, die Biegeradien einhalten, Kollisionen mit Strukturteilen vermeiden, EMV-Schirmungszonen respektieren und sich innerhalb vorgegebener Gewichts- und Längentoleranzen halten. Was ein Konstrukteur in zwei Wochen manuell prüft, berechnet das System in Minuten.

Ebene 2: Automatische Design-Rule-Checks (DRC) Über 200 Designregeln — Mindestabstände zu Wärmequellen, maximale Kabellängentoleranzen, Steckerbelegungsregeln, Hochspannungs-Niederspannungs-Trennabstände, ASIL-konforme Redundanztopologien — werden automatisch und konsistent auf jede Variante angewendet. Fehler werden im Designprozess gefunden, nicht in der Fertigungsübergabe. Das spart nicht nur Korrekturaufwand, sondern verhindert auch die Rückrufszenarien, die durch späte Fehlererkennung entstehen.

Ebene 3: Parametrische Variantenableitung Der stärkste Hebel: Einmal ein konsolidiertes Basisdesign angelegt, können Hunderte von Varianten (z. B. Verbrenner, Hybrid, BEV, Linkslenker, Rechtslenker, optionales Panoramadach, verschiedene Ausstattungslinien) automatisch als parametrische Ableitungen generiert werden. Änderungen am OEM-Basisentwurf propagieren automatisch in alle davon abgeleiteten Varianten. Ein Konstrukteur steuert Ausnahmen und Überschreibungen — er tippt keine Kabelwege mehr manuell ein.

Das Zusammenspiel dieser drei Ebenen erlaubt es, das Engineering von einem handwerklichen Serienprozess (jede Variante als einzelne Konstruktionsaufgabe) zu einem konfigurationsgetriebenen Prozess umzustellen: Man definiert die Regeln einmal, und das System generiert konforme Varianten.

KBL, VEC und der digitale Faden — das Datenfundament

Dieser Abschnitt existiert, weil er entscheidend ist: Ohne ein Verständnis der zugrundeliegenden Datenformate ist KI-Automatisierung im Kabelbaum-Engineering nicht möglich — und viele Projekte scheitern hier, bevor die erste Routing-Berechnung gestartet wird.

KBL (Kabelbaum-Beschreibungsliste, VDA 4964) ist seit 2005 das Standard-Austauschformat der deutschen Automobilindustrie — entwickelt vom VDA, basierend auf ISO STEP AP212. Sie beschreibt den Kabelbaum als Datenstruktur: Topologie, Komponenten, Verbindungen, Längen. Wenn ein OEM sagt “wir erwarten KBL-Daten vom Tier-1”, meint er dieses Format. Ohne KBL-Exportfähigkeit ist ein Tier-1-Engineering-System bei deutschen OEMs faktisch nicht lieferfähig.

VEC (Vehicle Electric Container, VDA 4968) ist die Weiterentwicklung, seit 2011 unter Federführung der prostep ivip Association entwickelt. VEC beschreibt nicht nur den physischen Kabelbaum, sondern das gesamte elektrische Fahrzeugnetzwerk — Topologie, Geometrie, Logik. Es erlaubt eine vollständige Digitalisierung der Prozesskette: kein separates 2D-Zeichnungspaket mehr nötig. Für Projekte mit digitalem Zwilling ist VEC Voraussetzung, kein Nice-to-have.

Was das für die KI-Einführung bedeutet: Ein KI-Routing-System, das keine saubere KBL- oder VEC-Datenbasis verarbeiten kann, ist wertlos im OEM-Kontext. Das bedeutet: Wer mit veralteten, proprietären Formaten (z. B. ältere Mentor-Versionen ohne KBL-Export, gescannte Nagelbrett-Zeichnungen) arbeitet, muss erst einen Formatmigrationsschritt einplanen, bevor KI-Automatisierung greifen kann. In der Praxis ist dieser Schritt oft unterschätzt und kostet 3–9 Monate extra.

Die gute Nachricht: Siemens Capital, Zuken E3.series und alle anderen OEM-nahen Kabelbaum-Tools unterstützen KBL und VEC als native Export-Formate. Wer mit diesen Systemen arbeitet, hat das Datenfundament bereits gelegt.

Was das System nicht kann — und was das bedeutet

Zwei Grenzen sind wichtig zu kennen:

Geometrische Einschränkungen: Das KI-Routing arbeitet auf dem Bauraum, den das MCAD-System liefert. Wenn die 3D-Fahrzeuggeometrie unvollständig ist, fehlerhafte Kollisionsgeometrien hat oder noch nicht die finale Rohbautoleranzen einschließt, produziert das System falsch positionierte Kabelbäume. Garbage in, garbage out — auch mit KI.

Sicherheitskritische Entscheidungen: Das System schlägt ASIL-konforme Redundanztopologien vor und prüft sie gegen Regeln. Aber die Entscheidung, welche Funktion auf ASIL-D gesetzt wird, welcher Abschaltzustand bei Kabelbruch zulässig ist und wie ein Versagensmodus bewertet wird, bleibt beim Functional Safety Engineer. KI kann die Implementierung einer Sicherheitsanforderung beschleunigen, nicht ersetzen.

ISO 26262 und der Kabelbaum: Was die KI dokumentieren muss

ISO 26262 ist der Funktionale-Sicherheits-Standard für Automobil-E/E-Systeme. Für sicherheitskritische Kabelbaumfunktionen (Lenkung ASIL-D, Bremse ASIL-D, Airbag ASIL-C) hat er direkte Auswirkungen auf das Routing-Engineering — und damit auf die Anforderungen an ein KI-gestütztes System.

Was ISO 26262 konkret fordert:

• Jede Designentscheidung muss rückverfolgbar sein — von der Systemanforderung über das Teilsystemdesign bis zum Kabelweg und Bauteil (Traceability-Pflicht)
• Änderungen an ASIL-relevanten Leitungsabschnitten müssen eine Auswirkungsanalyse auslösen und genehmigt werden
• Die DRC-Ergebnisse für sicherheitskritische Abschnitte müssen dokumentiert und archiviert werden

Was das für KI-gestütztes Routing bedeutet: Ein KI-System, das eine Routing-Entscheidung für einen ASIL-D-Abschnitt trifft, muss diese Entscheidung in einem Audit-Trail festhalten — inklusive der angewendeten Regeln, der überprüften Alternativen und der Genehmigung durch den zuständigen Engineer. Ein “Das System hat es so vorgeschlagen” reicht beim TÜV-Assessment nicht. Alle gängigen OEM-nahen Tools (Capital, E3.series) generieren diese Audit-Trails als integralen Bestandteil des DRC-Workflows — für Drittanbieter-KI-Tools (Synera, Dessia) muss dieser Nachweis explizit konfiguriert werden.

Die praktische Konsequenz: Für sicherheitsneutrale Abschnitte (Komfort-Elektronik, Infotainment, Klimaanlage) kann das KI-Routing weitgehend unbeaufsichtigt laufen. Für ASIL-klassifizierte Abschnitte gilt: Human-in-the-Loop ist Pflicht, nicht Option. Plane das in deiner Workflow-Architektur ein — und nicht erst, wenn der erste TÜV-Assessor fragt.

Konkrete Werkzeuge — was wann passt

Der Markt für KI-gestütztes Kabelbaum-Engineering teilt sich in zwei Segmente: integrierte OEM-nahe Platforms und spezialisierte KI-Automatisierungstools, die in bestehende Umgebungen eingebettet werden.

Siemens Capital — wenn du im OEM/Tier-1-Ökosystem bist Capital (früher Mentor Capital) ist der Industriestandard bei deutschen Premium-OEMs und deren direkten Tier-1-Lieferanten. Capital X bringt KI-gestützte generative Design-Funktionen für Routing und Variantengenerierung. DRC, KBL/VEC-Export und ISO 26262-Traceability sind vollständig integriert. Kein billiges System — Einstieg für Tier-1/Tier-2 mit Capital Essentials im Bereich 3.000–6.000 EUR/Nutzer/Jahr, vollständige OEM-Edition deutlich darüber. Wer die OEM-Vorgabe “Capital-kompatible Daten” erhält, hat de facto keine Alternative.

Zuken E3.series mit E3.AI Assistant — wenn du DACH-seitig tief integriert bist Zuken ist die ernste Alternative zu Capital im DACH-Markt — mit dem 2024 eingeführten E3.AI Assistant bekommt das Werkzeug KI-gestützte Routing-Vorschläge und natürlichsprachige Komponentensuche. Vollausbau (E3.cable, E3.formboard, E3.schematic) rund 5.000–6.000 EUR/Nutzer/Jahr. Sehr stark für Multi-User-Engineering und objektorientiertes Datenmodell. Deutsche Niederlassung in Paderborn, DSGVO-saubere Datenhaltung. Für Tier-2-Zulieferer, die nicht zwingend im Capital-Ökosystem sind, oft die wirtschaftlichere Wahl.

Synera — wenn du KI-Automatisierung in dein bestehendes CAD einbetten willst Synera ist keine Harness-Designplattform, sondern ein Automatisierungs-Layer, der sich in bestehende MCAD- und ECAD-Umgebungen einbettet und Routing-Algorithmen, Variantengenerierung und Datenexport automatisiert. Die Casestudy mit RLE INTERNATIONAL zeigt 77 % Beschleunigung im Routing-Workflow. Für Unternehmen, die nicht die gesamte CAD-Umgebung wechseln wollen, sondern bestehende Tools mit KI-Routing nachrüsten, ist Synera eine ernsthafte Option. Lizenzmodell auf Anfrage (kein öffentlicher Preis).

EPLAN Electric P8 — wenn der Schwerpunkt Schaltplanung und Schaltschrank ist, nicht Kabelbaum EPLAN ist der DACH-Standard für elektrische Schaltplanung im Maschinenbau — aber für automotive Kabelbaum-Engineering mit OEM-Anbindung und KBL/VEC-Anforderungen ist Capital oder Zuken E3.series die richtigere Wahl. EPLAN hat eingeschränkte native Harness-Tiefe im Automotive-Kontext.

Zusammenfassung: Wann welcher Ansatz

• OEM-Vorgabe Capital → Siemens Capital
• DACH-Tier-1/2 ohne OEM-Bindung → Zuken E3.series
• KI-Nachrüstung bestehender CAD-Umgebung → Synera
• Reiner Maschinenbau-Schaltplan (ohne OEM-Kabelbaum) → EPLAN Electric P8

Datenschutz und Datenhaltung

Kabelbaumdesign-Daten sind im Automotive-Kontext keine DSGVO-relevanten Personendaten — es geht um technische Konstruktionsdaten. Dennoch gibt es drei datenschutzrelevante Aspekte:

Geistiges Eigentum und NDA-Schutz: Kabelbaum-Designs enthalten hochsensible Fahrzeuginnovationen — neue ADAS-Topologien, Batteriemanagementsystemverkabelungen, proprietäre Komponentenauswahlen. Diese Daten dürfen nicht in externe Systeme fließen, die für das Modelltraining genutzt werden. Das gilt insbesondere für Cloud-KI-Dienste ohne expliziten NDA und Datenschutzvertrag. Alle genannten OEM-nahen Tools (Capital, Zuken) arbeiten standardmäßig on-premise oder in privaten Cloud-Regionen — kein Training mit Kundendaten.

Lieferantengeheimnis im Multi-Tier-Betrieb: Wenn OEM-Daten (logische Netzwerktopologie im VEC-Format) an einen Tier-1 weitergegeben werden und der Tier-1 KI-Tools nutzt, muss vertraglich geregelt sein, wer Zugriff auf diese Daten hat und wie sie verarbeitet werden. OEM-Werkzeugketten (Capital) haben hier oft vordefinierte Access-Control-Mechanismen. Drittanbieter-Tools müssen explizit geprüft werden.

Technische Daten im EU-AI-Act-Kontext: Kabelbaum-Engineering-Systeme fallen nicht in die Hochrisiko-Kategorien des EU AI Act (Biometrie, kritische Infrastruktur). Dennoch: Wer KI-Routing-Entscheidungen für sicherheitskritische Kabelbaumabschnitte (ASIL-D) nutzt, ist gut beraten, eine interne Risikoklassifizierung und Dokumentationsmatrix aufzubauen — nicht als gesetzliche Pflicht, sondern als Qualitätssicherungsmaßnahme und als Vorbereitung auf künftige Regulierung.

Empfehlung: Für OEM- und Tier-1-Umgebungen immer on-premise oder private-cloud mit EU-Hosting. AVV mit Toolanbietern prüfen, besonders für KI-Automation-Layer wie Synera. Bei Drittanbieter-KI-APIs (z. B. LLM-basierte Komponentensuche in E3.AI Assistant) klären, welche Datenpunkte extern übermittelt werden.

Was es kostet — realistisch gerechnet

Das Kostenmodell für KI-gestützte Kabelbaum-Automatisierung ist komplex, weil es aus drei Schichten besteht: Tool-Lizenzen, Integration und laufende Betriebskosten.

Tool-Lizenzen (laufend)

• Siemens Capital mit KI-Komponenten (Capital X): 3.000–6.000 EUR/Nutzer/Jahr (Capital Essentials, Tier-1/2); OEM-Vollausbau deutlich höher — nur auf Anfrage
• Zuken E3.series Vollausbau: 5.000–6.000 EUR/Nutzer/Jahr; E3.AI Assistant ist im Modul-Paket enthalten
• Synera Automatisierungs-Layer: auf Anfrage (keine öffentliche Preisliste, Enterprise-Modell)

Einmalige Integrationskosten

• PLM-Integration (Teamcenter, Windchill), MCAD-Anbindung und KBL/VEC-Datenmigration: typisch 80.000–250.000 EUR für ein Tier-1-Unternehmen mit 5–10 Konstrukteursarbeitsplätzen
• Externe Projektkosten für Tool-Rollout, Datenmigration und Schulung: 3–9 Monate Laufzeit mit internen und externen Ressourcen
• Aufbau der parametrischen Variantenbibliothek (Grundlage für KI-Routing): 6–12 Monate interner Aufwand, parallel zum Tool-Rollout

Laufende Betriebskosten

• Datenbankpflege und Variantenbibliothek-Updates: ca. 0,2–0,5 FTE intern
• Tool-Wartung und Lizenzverlängerungen: typisch 18–22 % der Lizenzkosten jährlich bei perpetual-Modellen

Wie du den ROI misst Der direkteste Messwert ist die mittlere Engineering-Zeit pro freigegebener Kabelbaum-Variante — vorher und nachher. Wenn ein Team von 8 Konstrukteuren pro Monat von 80 auf 200 Varianten kommt, ist das quantifizierbar. Als zweites: Fertigungsfehler-Rate in der Kabelbaum-Übergabe (DRC-Mängel, die in Fertigung aufschlagen). Beide KPIs sollten vor dem Projekt-Start als Baseline gemessen werden — sonst gibt es keinen Beweis für den ROI, auch wenn er eintritt.

Konservatives Szenario für ein Tier-1-Unternehmen mit 8 Kabelbaum-Konstrukteuren, 300 aktiven Varianten/Jahr und einem mittleren Bruttostundensatz von 65 EUR:

• Ohne KI: 300 Varianten × 10 Tage × 8 Stunden × 65 EUR = rund 1.560.000 EUR Engineering-Aufwand/Jahr
• Mit KI (50 % Reduktion): ca. 780.000 EUR — Einsparung 780.000 EUR/Jahr
• Vorlaufkosten (Lizenzen + Integration + Schulung, 2 Jahre): ca. 600.000–900.000 EUR
• ROI-Zeitpunkt: typisch Monat 18–24

Das ist eine grobe Rechnung — sie setzt voraus, dass die freigewordene Kapazität produktiv genutzt wird (mehr Varianten, frühere SOP-Termine, weniger Überstunden). Wer die Rechnung mit 20 % Nutzungsrate und 30 % Einsparung ansetzt, kommt auf ROI in Monat 36–48 — das muss dann offen mit der Geschäftsführung diskutiert werden.

Drei typische Einstiegsfehler

1. Mit dem KI-Tool starten, bevor das Datenfundament steht Der häufigste Fehler: Ein Unternehmen kauft ein KI-fähiges Routing-System, weil es beeindruckende Demo-Videos gesehen hat — und stellt dann fest, dass die eigenen Bestandsdaten (ältere CAD-Formate, halb dokumentierte Variantenbibliotheken, keine KBL-konformen Exporte) das System faktisch blockieren. Das Tool ist installiert, aber die Daten sind nicht kompatibel. Lösung: Zuerst einen Datenmigrations-Workshop durchführen — Datenformate, Variantenstruktur, PLM-Anbindung klären, bevor die Tool-Evaluierung beginnt.

2. Den ISO 26262-Traceability-Bedarf unterschätzen Teams, die KI-Routing für sicherheitskritische Abschnitte (Lenkung, Bremse) einführen, ohne vorher den Traceability-Workflow zu definieren, stoßen beim ersten TÜV-Assessment auf massive Nacharbeitskosten. Ein automatisch generierter Routing-Vorschlag für einen ASIL-D-Abschnitt, der nicht durch einen genehmigten Freigabeworkflow läuft und keinen Audit-Trail hat, ist sicherheitsrechtlich wertlos — und muss nachgenehmigt werden. Lösung: Den Safety-Case und die Traceability-Anforderungen vor dem Tool-Rollout mit dem Functional Safety Manager und dem TÜV-Assessor abstimmen.

3. Das System wird eingeführt — und die Variantenbibliothek danach nicht gepflegt Ein KI-Routing-System ist so gut wie die parametrische Regelbasis, auf der es operiert. Wenn nach zwei Jahren neue Fahrzeugplattformen, neue Stecker-Standards oder neue OEM-Designregeln hinzukommen, ohne dass die Bibliothek aktualisiert wird, generiert das System Varianten, die technisch falsch sind — aber korrekt aussehen. Dieser Fehler ist gefährlicher als kein KI-System, weil er mit falscher Zuversicht produziert. Lösung: Ein Bibliotheks-Owner benennen (namentlich, nicht “das Team”), klare Review-Zyklen bei Plattformwechseln und neue OEM-Vorgaben als Library-Update-Trigger definieren.

Was mit der Einführung wirklich passiert — und was nicht

Die technische Seite dieser Einführung ist lösbar — schwierig, aber lösbar. Die organisatorische Seite überrascht die meisten Unternehmen mehr.

Erfahrene Konstrukteure werden ambivalent reagieren. Wer zehn Jahre lang Kabelbaum-Routing als handwerkliche Expertise aufgebaut hat, sieht in der Automatisierung zunächst eine Entwertung seiner Fähigkeiten. Das ist ein legitimes Gefühl, das ernst genommen werden muss. Was tatsächlich passiert: Die Expertise der erfahrenen Konstrukteure wird wertvoller, nicht weniger wert — das System generiert Vorschläge, aber es braucht jemanden mit tiefem Domänenwissen, um zu erkennen, welche Vorschläge gut sind und welche einen subtilen Fehler in der Regelbasis abbilden. Wer das früh und ehrlich kommuniziert, vermeidet das schlimmste Widerstandsmuster.

Das OEM wird nicht automatisch mitspielen. KI-Routing verbessert die interne Produktivität beim Tier-1 — aber die Erwartungshaltung des OEM (Änderungsanfragen in kürzeren Zyklen, weil “ihr ja jetzt KI habt”) kann den gewonnenen Spielraum schnell wieder aufzehren. Wer diese Produktivitätsverbesserung intern behält — als Kapazitätspuffer, als Fehler-Reduktionshebel, als SOP-Sicherheitsnetz — hat mehr davon als wer sie dem OEM als Versprechen kommuniziert, bevor sie stabil ist.

Der erste reale Fehler des Systems wird das Vertrauen nachhaltig erschüttern. Irgendwann — typisch in Monat 3–6 nach Produktivstart — wird das System eine Routing-Empfehlung ausgeben, die subtil falsch ist. Biegeradien knapp übertreten, ein Stecker in einem Bauraum-Engpass nicht erkannt, eine Gewichtstoleranz um zwei Gramm überschritten. Wenn das Team nicht vorbereitet ist, wird dieser Fehler zur Systemkrise. Wenn das Team vorbereitet ist (weiß, dass das System Vorschläge generiert, keine Freigaben), ist es eine Korrekturschleife wie jede andere. Welches Szenario eintritt, entscheidet die Einführungsschulung — nicht das System selbst.

Realistischer Zeitplan mit Risikohinweisen

Hinweis: Phasen überlappen sich bewusst. Wer die PLM-Integration abwarten will, bevor die parametrische Bibliothek aufgebaut wird, verliert sechs bis neun Monate. Beide Stränge laufen parallel, koordiniert durch einen dedizierten Projektleiter.

Häufige Einwände — und was dahintersteckt

„Das macht unser CAD-Tool doch schon von Haus aus.” Stimmt für Basis-DRC-Prüfungen. Stimmt nicht für parametrische Variantenableitung mit hundert Varianten in einem Lauf, und stimmt nicht für KI-gestütztes Routing, das Geometriealternativen generiert statt nur Regeln zu prüfen. Der Unterschied zwischen einem Werkzeug, das Fehler meldet, und einem Werkzeug, das regelkonforme Routing-Vorschläge generiert, ist substanziell — und der letztere Schritt ist der, der Engineering-Zeit massiv reduziert.

„Wir haben zu wenige Varianten, damit sich das lohnt.” Diese Frage ist beantwortbar — einfach die aktuelle Engineering-Zeit pro Variante multiplizieren, gegen die Investitionskosten rechnen. Aber das Argument verdient eine Umkehr: Wer heute zu wenige Varianten hat, wird in drei Jahren mehr haben — EV-Plattformen, neue Ausstattungsoptionen, Marktanpassungen für andere Regionen. Wer die Infrastruktur dann aufbaut, zahlt zum zweiten Mal die Integrationskosten. Wer sie heute aufbaut, profitiert früher und hat die Kurve abgeflacht.

„Wir haben Bedenken wegen ISO 26262-Compliance.” Das ist der richtige Einwand — aber er ist kein Ausschlusskriterium, sondern ein Designprinzip. Die Antwort ist: KI-Routing für sicherheitskritische Abschnitte läuft immer Human-in-the-Loop, mit Audit-Trail, mit genehmigtem Freigabeworkflow. Das System generiert Vorschläge, nicht Freigaben. Wer das so konfiguriert und dokumentiert, hat einen belastbaren Safety-Case. Die eigentliche Compliance-Gefahr liegt woanders: in manuellen DRC-Prozessen, die auf menschlicher Konsistenz und Tagesverfassung beruhen — und die bei hohem Variantenvolumen unvermeidlich Fehler produzieren.

Multi-Tier-Handoff: OEM, Tier-1 und der Datenverlust dazwischen

Das vielleicht größte unterschätzte Problem in der Kabelbaum-Entwicklung ist nicht die Automatisierung innerhalb eines Unternehmens — es ist der Datenverlust zwischen den Unternehmen.

Die typische Prozesskette:

1. OEM definiert das logische Bordnetz-Konzept (elektrische Topologie, Funktion, ASIL-Klassen)
2. Tier-1 erhält logische Vorgaben und entwickelt den physischen Kabelbaum (Routing, Komponenten, Längen)
3. Tier-1 übergibt Fertigungsdaten an Sub-Supplier (Nagelbrettplan, Kabelliste)
4. Sub-Supplier produziert und liefert zurück an OEM-Montagewerk

An jedem Übergabepunkt — OEM → Tier-1, Tier-1 → Sub-Supplier — gehen Daten verloren oder werden manuell reinterpretiert. OEM übergibt VEC-Datei, Tier-1 liest sie in sein System ein und muss 20 % der Daten manuell ergänzen, weil das Geometriemodell nicht vollständig übertragen wurde. Tier-1 übergibt DXF-Nagelbrettplan, Sub-Supplier pflegt diesen manuell in sein eigenes Produktionssystem ein.

Was KI-Automatisierung hier leisten kann — und was nicht: Ein KI-Routing-System beim Tier-1 verbessert die interne Effizienz massiv. Es löst aber nicht das strukturelle Problem der Datenverluste an den Übergabepunkten. Dafür braucht es:

• Standardisierte Formate (KBL, VEC) als vertragliche OEM-Anforderung an beide Seiten
• Tool-kompatible Übergabeprozesse (beide Tier-Stufen nutzen Tools, die native KBL/VEC lesen/schreiben)
• Digitale Kontinuität: Eine Änderung am OEM-Basisdesign, die am Freitag freigegeben wird, muss Montag automatisch beim Tier-1 als Änderungsauftrag ankommen — nicht als E-Mail-Anhang, den jemand manuell einpflegt

Unternehmen, die das Handoff-Problem nicht lösen, bauen eine KI-Insellösung — sehr effizient intern, aber immer noch durch manuelle Übergaben begrenzt. Die Praxis zeigt: Der größte Teil des realisierbaren Zeitgewinns liegt nicht im Routing selbst, sondern in der Beseitigung manueller Schnittstellen an den Übergabepunkten.

Woran du merkst, dass das zu dir passt

Signale, die für diesen Anwendungsfall sprechen:

• Dein Unternehmen entwickelt Kabelbäume für mindestens 80–100 Fahrzeugvarianten pro Jahr aktiv
• Du hast mindestens 5 dedizierte Harness-Konstrukteure in der Entwicklung
• OEM-Änderungsanfragen verursachen aktuell Wellenbewegungen durch den ganzen Variantenbestand — jede Änderung bedeutet manuelle Nacharbeit an Dutzenden Varianten
• Dein Team kämpft damit, DRC-Freigaben termingerecht zu liefern, weil die manuelle Prüfung den Zeitplan dominiert
• Du arbeitest mit einem OEM, der KBL- oder VEC-Daten fordert und möglicherweise eine Capital-kompatible Toolchain vorgibt

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als 5 aktive Harness-Konstrukteure. Die Integrationskosten (Lizenzen, Migration, Schulung) amortisieren sich bei kleinen Teams nicht innerhalb sinnvoller Zeiträume. Unter dieser Schwelle ist das richtige Investment die Qualität der Designwerkzeuge und die Datenstruktur, nicht KI-Routing.

2. Kein strukturiertes Variantenmanagement — keine 150%-Stückliste, kein Variantenschlüssel, keine konsolidierte Bauteilbibliothek. KI-Routing braucht als Eingabe eine sauber definierte Variantenstruktur. Wenn Varianten heute als individuelle manuelle Designdateien ohne gemeinsame Datenbasis existieren, ist der erste Schritt die Aufräumarbeit — kein KI-System.

3. Konstruktionsdaten liegen nur als Papierdokumente, gescannte Zeichnungen oder proprietären Legacy-Formaten vor, die keine native KBL/VEC-Konvertierung unterstützen. Die Formatmigration in einen automationsfähigen Stand ist ein eigenständiges Projekt, das 6–12 Monate dauern kann — und das gehört in den Projektplan, bevor KI-Automation auf der Agenda steht.

Das kannst du heute noch tun

Bevor du einen Anbieter anrufst: Führe in deiner Engineering-Abteilung eine schnelle Messung durch. Wähle fünf der zuletzt abgearbeiteten Kabelbaum-Varianten aus und erfasse für jede:

• Wie viele Tage hat das Engineering von Rohentwurf bis DRC-Freigabe gedauert?
• Wie viele DRC-Fehler wurden gefunden — und wie viele davon hätten durch automatisierte Regeln früher erkannt werden können?
• Wie viel Aufwand ist in die Anpassung von Varianten nach OEM-Änderungsanfragen geflossen?

Diese Zahlen sind der einzig ehrliche Ausgangspunkt für eine ROI-Diskussion. Ohne sie kaufst du ein System, ohne zu wissen, ob es sich lohnt.

Der nachfolgende Prompt hilft dir dabei, die Ergebnisse zu strukturieren und eine erste Entscheidungsgrundlage zu erstellen:

Quellen & Methodik

• Synera/RLE INTERNATIONAL Casestudy (2024) — 77 % Beschleunigung: Synera GmbH, Extended Case Study „Accelerate Wiring Harness Design with Automated Routing Algorithms” mit RLE INTERNATIONAL. Roland Proschka, Technical Unit Leader Electric Electronics bei RLE INTERNATIONAL. synera.io/extended-case-studies

• Daimler Truck Innovation Center, SAE-Paper 2025-28-0311: Rishi Kumaar N et al., „Integrating AI in Wiring Harness Design for Enhanced Efficiency”. Daimler Truck Innovation Center. SAE Mobilus, 2025. saemobilus.sae.org

• DRC-Effizienzdaten (60–80 % weniger Zeit, 40–60 % weniger Fertigungsfehler): Cadonix, „How Design Rule Checks Improve Quality in Wire Harness Design”. cadonix.com

• Rückrufstatistik (über zwei Drittel durch Designfehler) und EV-Recall-Beispiel: Altium Resources, „Wire Harness Failures: The Hidden Costs and Real-World Recalls That Could Have Been Prevented” (2024). resources.altium.com

• KBL (VDA 4964) und VEC (VDA 4968) Datenaustauschstandards: VDA, „Harness Description List (KBL) 4964”; prostep ivip Association, VEC-Standard VDA 4968. Hintergrundanalyse: ECAD WIKI, „KBL vs. VEC” ecad-wiki.prostep.org

• Vorlaufzeit Design bis Lieferung (23–26 Wochen) und OEM-Routing-Herausforderungen: Wiring Harness News, „Wiring Harness Design Validation”. wiringharnessnews.com

• NRE-Kosten pro Kabelbaum-Variante (1.100–5.800 EUR Richtwert): Wiringo, „Kabelbaum Kosten 2026: Was kostet ein kundenspezifischer Kabelbaum?”. wiringgerman.com

• Zuken E3.series Preisangaben und E3.AI Assistant: Zuken GmbH, Paderborn, Produktdatenblatt E3.series (Stand Mai 2026). Eigene Tool-Seite: ki-syndikat.de/tools/zuken-e3-series/

• ISO 26262 ASIL-Klassifizierung und Traceability-Anforderungen: ISO 26262:2018, Road vehicles — Functional safety. Synthese aus TÜV SÜD, NI und Synopsys-Übersichtsquellen.

• Siemens Capital Essentials (typisch 3.000–6.000 EUR/Nutzer/Jahr): Siemens Digital Industries Software, Capital Essentials Produktseite siemens.com/products/capital/offerings/essentials; Angaben aus Branchenvergleichen (Stand Mai 2026).

Du willst wissen, ob dein Unternehmen die Voraussetzungen für KI-gestützte Kabelbaum-Automatisierung erfüllt — oder was zuerst getan werden muss? Meld dich — das klären wir in einem Gespräch.