Startseite > Automotive > Von der 2D-Zeichnung zum digitalen Zwilling

Bordnetzentwicklung

Von der 2D-Zeichnung zum digitalen Zwilling

9. Oktober 2018, 13:30 Uhr | Von Reinhold Blank

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

KBL erfordert verbindliche Vorgaben für Attribute

Eine andere Hürde auf dem Weg zur vollständigen Digitalisierung des Bordnetzes ist nach wie vor das Thema »Daten-Content und -Qualität«. Es »hapert« manchmal an kleinen Dingen, die eine praktische Nutzung oft unnötig erschweren. So bietet das heute meist praktizierte Datenformat KBL zwar viele Konstrukte und Datenfelder, um die Details eines Kabelsatzes zu beschreiben.
Was man bei der Etablierung des Standards aber teilweise versäumt hat, war die Festlegung von verbindlichen Vorgaben für bestimmte Attribute. Beispielsweise kann das Feld »Farbe« mit jedem beliebigen Text beschrieben werden. Der erste schreibt »BL«, der zweite »Blue«, der dritte »Blau«, der vierte »34«.

Will man nun in der digitalen Visualisierung z. B. eine Leitung farblich darstellen, so steht man vor einem echten Problem, welches man nur durch designabhängige Mapping-Tabellen lösen kann. Eine einheitliche, feste Vorgabe eines Bezugs – z. B. RAL »5003« – oder der RGB-Hexwert »0000FF« innerhalb des maschinengeschriebenen Datenformates würde es allen prozessbeteiligten Tools ermöglichen, diese digitalen Daten in die gewünschte farbliche Visualisierung umzusetzen.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Ähnliche Defizite gibt es bezüglich fehlender Klassifizierung von bestimmten Objekten innerhalb der Kabelsatz-Datensätze. Als Beispiele seien in diesem Zusammenhang fehlende standardisierte Schlüssel für Leitungstypen, für Bandierungen oder auch für Verarbeitungskriterien wie Verdrillungen genannt. Richtig »weh« tun aber fehlenden Klassifizierungen von Komponenten-Steckern, Trennstellen-Steckern, Kabelschuhen und Schweißverbindern – all diese Objekte werden unter der Struktur »Stecker« abgebildet! Will man nun auf Basis dieses KBL-Datenmodells maschinell einen gut lesbaren Schaltplan erzeugen, so landet man zwangsläufig wieder bei Mapping- bzw. Konfigurationstabellen, die über ein Dekompilieren der Namenskonvention auf die erforderliche Klassifizierung Rückschlüsse ziehen. Beispielsweise fangen Kabelschuhe mit »W« an, Trennstellen beginnen mit »X« und haben am Ende ein »-B« oder »-S« (Bild 3).

Dieser sehr mühsame Prozess könnte massiv vereinfacht werden, wenn die Klassifizierung aus dem Autorensystem (denn dort war diese ja sicher vorhanden) über das Datenformat durch standardisierte »Enums« (alphanumerische Kennzeichnungen) transportiert würden – z. B. »1« klassifiziert einen Komponentenstecker, »2« einen Trennstellenstecker, »„3« einen Kabelschuh und so weiter. Wichtig wäre zudem ein verbindliches Durchsetzen dieser Klassifizierung, denn die teilweise vorhandenen Empfehlungen haben es in der Praxis nicht zu einem Durchbruch geschafft.

Eine derartige Festlegung von Klassifizierungs-Standards ist völlig unabhängig vom verwendeten Datenformat, sie wäre für einen Datenaustausch auf Basis von Excel genauso hilfreich wie bei der Nutzung von KBL heute und VEC morgen. Denn bei einem wirklich neutralen und voll digitalen Austausch von Produktdaten ist es nicht nur wichtig, ein standardisiertes Datenformat zu benutzen, sondern es muss auch klare Definitionen für die Interpretation der Daten geben. Nur dann gelingt es intelligenten Visualisierungstools, diese Daten als zielgerichtete Informationen für die Anwender aufzubereiten.

Brauchen wir also eine Erweiterung des Standards VEC?

Das eben genannte Plädoyer für die Einführung von Klassifizierungen sollte nicht missverstanden werden als Aussage »Wir brauchen keinen erweiterten Standard VEC«. Natürlich macht es Sinn, die in der produktiven Nutzung des KBL-Formats erkannten Schwächen durch einen neuen Standard zu beheben und dabei gleichzeitig den Fokus neu zu setzen – auf die ganzheitliche Abbildung des physikalischen Bordnetzes anstelle des einzelnen Kabelsatzes.

Allerdings lassen sich auch viele dieser Aspekte mit minimalen Workarounds bzw. durch Intelligenz des Analyse-/Visualisierungswerkzeuges auch heute schon elegant lösen. So erlaubt es die von Zuken entwickelte Anwendung E3.HarnessAnalyzer auch heute schon, die verschiedenen Kabelsätze eines Fahrzeuges als einzelne KBL-Dateien einzulesen, aus denen das Tool automatisch ein Gesamt-Bordnetz generiert. Der Anwender kann somit systemweit die Konnektivität als Schaltplan über Trennstellen hinweg darstellen oder sich auch ein Gesamtmodell des Bordnetzes in 3D generieren lassen (Bild 4). Dies sei nur als Beispiel dafür genannt, wie intelligente Systemfunktionalität schon heute trotz KBL-Grenzen für den Nutzer die gewünschte Datenaufbereitung realisieren kann.

Fehlt die oben angesprochene Klassifizierung, ist die Business-Logik allerdings hilflos und es müssen zwangsläufig aufwendige und zum Teil designspezifische Mappings praktiziert werden. Daher wäre es eine Überlegung wert, mit welchen Prioritäten man die Weiterentwicklung des Formates (KBL/VEC) einerseits und die Standardisierung der Klassifizierung andererseits vorantreibt.

Der dafür erforderliche Aufwand ist mit Sicherheit gut investiert, wenn man sich die künftigen Nutzungsmöglichkeiten einer anwendungsneutralen digitalen Kabelsatzbeschreibung vor Augen führt: Vor allem ist n diesem Zusammenhang ein Technologietrend zu nennen, der sich in den nächsten Jahren massiv verbreiten wird. Die Rede ist von Virtual-Reality-Anwendungen, die kurz davor stehen, auch die »normalen« Arbeitsplätze in den Unternehmen zu erreichen. Es wird in den nächsten Jahren Design-Anwendungen geben, bei denen ein Teil der Produktanwendung im virtuellen Raum – sprich in einer VR-Anwendung – stattfindet. Darüber hinaus wird es viele Aufgaben im Bereich der Validierung, Reviews und Freigabe geben, die mit VR-Anwendungen besser unterstützt werden können.

Ein möglicher Lösungsansatz: der »begehbare« Kabelsatz

Selbstverständlich wird sich das Bordnetz von dem erwähnten Trend nicht ausnehmen, zumal es sich aufgrund seiner Struktur ganz besonders für diese Art von Anwendung eignet. Eine prototypische Implementierung einer VR-tauglichen Weiterentwicklung von E3.HarnessAnalyzer hat die sich ergebenden neuen Möglichkeiten bereits eindrucksvoll unter Beweis gestellt. Viele Test-Anwender waren begeistert von der völlig neuen Art der Visualisierung eines Kabelsatzes oder eines Gesamt-Bordnetzes im Fahrzeug.

So ein »begehbarer Kabelsatz« vermittelt virtuell den Eindruck, man ist »mitten drin« statt nur »vor dem Monitor«. Außerdem wird die hochwertige geometrische Darstellung dann zusätzlich kombiniert mit elektrospezifischen Visualisierungsfunktionen wie Bündel- oder Konnektivitätsanalyse (Bild 5).

So unterschiedlich das Anwendungserlebnis in einer VR-Anwendung auch ist – eines ist identisch mit den konventionellen Desktop-Applikationen: die Notwendigkeit von »vernünftigen« digitalen Daten als Basis.

Datenqualität hat Vorrang

Alle bereits angestellten Überlegungen bezüglich Datenformat und -qualität sowie der Probleme fehlender Klassifizierung treffen auch voll zu, wenn es darum geht, Bordnetz-Daten in einem virtuellen Raum zu visualisieren. Man kann sogar sagen, dass die Anforderungen an die Datenqualität sogar noch etwas höher sein werden. Denn es kommen noch Ungenauigkeiten z. B. in der Orientierung eines Steckers viel stärker zum Vorschein, wenn man diesen direkt im VR-Modell – und nicht als aus der Ferne am Monitor – betrachtet.

Zusammenfassend bleibt das Plädoyer, dass alle Prozessbeteiligten in Zukunft mehr Priorität auf die Datenqualität und Interpretations-Standards legen sollten als auf das Format als solches. Dies wird zusammen mit intelligenten Datenaufbereitungs-Werkzeugen die Basis für die Durchsetzung des zu 100 Prozent digitalen Kabelsatzes bilden. Die daraus entstehenden Vorteile werden für alle Prozessbeteiligten lohnenswert sein und sind in den heute praktizierten Prozessen bei weitem noch nicht ausgeschöpft.

Der Autor

Reinhold Blank

Jahrgang 1960, studierte Feinwerktechnik an der FH Nürnberg (heute TH Nürnberg). Seit 1990 ist er im Bereich ECAD tätig; anfangs als Vertriebsbeauftragter, dann als Leiter Support und Product Management bei Firmen wie ABB Cade, HP Cade, CIE Süssen und TCS. 1997 wechselte er zu Leoni als CAD-Leiter weltweit für den Bereich Bordnetzentwicklung. 2001 übernahm er die IT-Leitung bei der Leoni-Tochter Intedis, wo er für die toolseitige Unterstützung von rund 100 Projekten für OEMs weltweit im Bereich Bordnetzarchitektur zuständig war. Seit Mai 2014 ist Reinhold Blank als Business Director Automotive bei Zuken E3 verantwortlich für die weitere Entwicklung spezifischer Lösungen für Automobile, Sonderfahrzeuge und andere Verkehrsmittel.