Bordnetzprozess 4.0
Zeit für einen Paradigmenwechsel
Fortsetzung des Artikels von Teil 2
Lösungsansätze aus der Software-Industrie
Angesichts der beschriebenen, immer größeren Herausforderungen für die Bordnetzentwicklung sind neue Lösungsansätze gefragt. Hier kann der Blick auf andere Branchen hilfreich sein, beispielsweise auf die Software-Industrie. Für das Versionsmanagement etwa gibt es dort etablierte Lösungen wie GIT, Subversion oder Perforce, die Funktionen bereitstellen, die auch für den Bereich Bordnetz-Entwicklung von Interesse sind. Das Bilden von „Branches“ (Abzweigungen) und späteres „Mergen“ (Zusammenführen) oder „Reverten“ (Rückgängig machen) gehört dazu, denn auch im Bereich der Bordnetz-Entwicklung will man Änderungen parallel statt seriell durchführen und ggf. später auch wieder Änderungs-Äste verwerfen.
Ein anderer interessanter Aspekt ist das Vererbungsprinzip – eine Standardmethodik in aktuellen Programmierumgebungen. Diese Methodik ist speziell im Zusammenhang mit der Verwendung von baureihenübergreifenden Lösungsbausteinen interessant, denn hier stellt das Instanziieren als Kopie eine große Herausforderung bzw. Einschränkung dar: Hat man beispielsweise den o.g. Fensterheber bzw. seine skalierte Ableitung als Lösungsbaustein in 30 verschiedenen Modellen verwendet und stellt nun einen Änderungsbedarf fest, so ist bei Anwendung des „Copy & Paste“-Prinzips die Änderung in allen 30 Einzeldesigns manuell einzubringen. Vererbung im Sinne der Software-Entwicklung könnte hier eine ideale Lösung bieten – denn Vererbung bedeutet, dass man den Lösungsbaustein in einer Modell-Variante instanziiert und dort beliebig überschreiben kann. Alle nicht überschriebenen Attribute und Informationen bleiben jedoch mit dem Ursprung verknüpft. Dieser Ansatz sei mit dem Beispiel im Kasten kurz verdeutlicht.
Wenn neue Methoden erlauben, Funktionsmodule analog zur Software zu modellieren, dann erbt im o.g. Beispiel die Funktion „WindowLifter_high“ alle Informationen vom Lösungsbaustein „WindowLifter“ und nur das Attribut Wire2.CSA wird überschrieben. Bei einer allgemeinen Änderung im Lösungsbaustein (z.B. die Teilenummer des Steckers ändert sich von „4711“ auf „0815“) wird sich diese Änderung direkt auch auf die abgeleiteten Funktionsmodule auswirken: keine händische Änderung mehr, kein Vergessen der Änderung bei bestimmten Modellen etc.
Auch wenn diese Vorgehenswei- se heute bei der Bordnetzentwicklung noch keine Rolle spielt, lohnt es sich, die Methoden der Software-Industrie weiter zu analysieren und daraus Lösungsansätze für die Bordnetzentwicklung zu generieren. Denn der Sprung zum Bordnetzprozess 4.0 gelingt nur mit neuen Ideen und Konzepten.
Die Autoren
Jobangebote+ passend zum Thema
| Dipl.-Ing. (FH) Reinhold Blank |
|---|
| studierte Feinwerktechnik an der FH Nürnberg. Seit 1990 ist er im Bereich ECAD tätig, u.a. als CAD-Leiter weltweit für den Bereich Bordnetzentwicklung oder als IT-Leiter mit Verantwortung für die Tool-Entwicklung. Seit 2014 ist Blank als Business Director Automotive bei der Zuken E3 GmbH verantwortlich für die Entwicklung spezifischer Lösungen für Automobile, Sonderfahrzeuge und andere Verkehrsmittel. |
- Zeit für einen Paradigmenwechsel
- Die Grenzen von KBL und VEC
- Lösungsansätze aus der Software-Industrie
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Optimierung des Bordnetzes
Das Ende des Kabelsalats
Wechsel zu agilen Prozessmodellen
Qualität und Effizienz erhöhen
Standpunkt
Warum wir den VEC-Standard brauchen
System-Software für Assistenzsysteme
Die fünf wichtigsten Regeln
