Abbildung 0_Aufmacher

(Bild: EDAG BFFT Electronics)

Den „BuildMyCar“-Button drücken und fertig ist die E/E-Architektur. So einfach ist es in der Realität natürlich nicht. Dennoch generiert der nachfolgend beschriebene Prozess ähnlich einem Fahrzeug-Konfigurator aus mehr als tausend Features eine erste Fahrzeugdefinition. Verschiedene Elemente einer internen Datenbank lassen sich hierbei nämlich zu einer initialen E/E-Architektur zusammenschmieden. Dank einer durchgängigen Tool-Unterstützung ist eine Ausleitung von Spezifikationen und technischen Lieferantenanfrage-Unterlagen zu jedem Zeitpunkt der Entwicklung möglich. Dies gibt den Entwicklern eine hilfreiche Toolkette an die Hand.

Historie der E/E-Architekturentwicklung

Eckdaten

Während immer mehr Elektronik in die Fahrzeuge einzieht, erfolgt die Entwicklung der dafür benötigten E/E-Architekturen immer noch mit klassischem Excel-Engineering. Ein durchgängiger, toolgestützter E/E-Architekturentwicklungsprozess könnte dies in Zukunft ändern. Der von EDAG BFFT Electronics entwickelte Prozess soll Unternehmen von der ersten Fahrzeugdefinition bis zur Komponentenspezifikation unterstützen. Bordnetze sollen auf Basis generischer Datenbankinhalte quasi auf dem weißen Blatt Papier initial entwickelt werden. Die Weiterverarbeitung der generischen Datensätze sowie die Detaillierung der Bordnetze erfolgt konsistent, das heißt, Änderungen zum Beispiel am elektrischen Bordnetz erfolgen automatisch auch in anderen zugehörigen Dateien.

In den letzten Jahren hat die Komplexität der Elektronik stetig zugenommen. Vor der Einführung von Bussystemen bestand das Bordnetz im Wesentlichen aus dem Leitungssatz, der die elektrischen Komponenten miteinander verband. Die Einführung von CAN erforderte die Entwicklung einer Kommunikationsmatrix. Zu dem elektrischen Bordnetz kam jetzt noch ein elektronisches Bordnetz hinzu. Features gewannen immer mehr an Bedeutung und ein immer höherer Softwareanteil erlaubte es, diese auf verschiedenen Steuergeräten zu verorten. Seit geraumer Zeit erhöhen die Themen funktionale Sicherheit und Cyber Security zusätzlich den Komplexitätsgrad der Bordnetze, was nunmehr eine gesamtheitliche E/E-Architekturentwicklung erfordert, um alle Anforderungen gleichermaßen zu berücksichtigen.

Parallel entwickelte sich über den selben Zeitraum die Toolkette zur Unterstützung der Entwicklung nur sehr langsam fort. Anfangs schrieben die Entwickler die Spezifikationen von Steuergeräten und Software zumeist in MS Word, mittlerweile sind immerhin spezielle Tools für das Anforderungsmanagement verfügbar. Die Pflege der Stückliste mit den benötigten elektrischen und elektronischen Komponenten erfolgte zu Beginn in MS Excel, seit geraumer Zeit in PDM-Systemen (Produktdatenmanagement, PDM). Alle diese Dokumente sind aber unabhängig voneinander, das heißt Änderungen an einem Dokument sind in allen anderen Dokumenten händisch nachzuziehen. Da Änderungen während der Entwicklung aber die Regel sind, bedeutet dies einen hohen Zeitaufwand, verbunden mit einer hohen Fehleranfälligkeit.

E/E-Architekturentwicklung 4.0

Mit der Einführung von Preevision ist nun eine durchgängige und konsistente Entwicklung auf einer gemeinsamen Datenbank möglich. Neben der einheitlichen Datenbank lässt sich das Tool an Kundenbedürfnisse anpassen. EDAG BFFT Electronics will das nutzen, um über eigene Metriken und eigene Tools einen durchgängigen E/E-Architekturentwicklungsprozess zu etablieren. Bei den wesentlichen Erweiterungen handelt es sich einerseits um „Eddna“ für die Fahrzeugdefinition und Pflege der Feature-Datenbank und andererseits um „Edbom“ für die Pflege der Bauteil-Datenbank. Außerdem kommen Import-Metriken zur Eingabe von Features, Requirements und Bordnetzdaten sowie Report-Metriken zum Erzeugen der Fahrzeugspezifikation und Anfrageunterlagen zum Einsatz.

Die wesentlichen gewerblichen Schutzrechte des E/E-Prozesses liegen aber in der intelligenten Verlinkung von Requirements, Features, Bauteilen, Signalen, SW-Modellen, Diagrammen, Bordnetzelementen und Aktivitäten. Möchte der Architekt beispielsweise das Feature „Sitzheizung“ vom Klimasteuergerät auf ein Sitzsteuergerät verorten, ändern sich automatisch die Features in den beiden Komponentenspezifikationen. Aber nicht nur das Feature-Mapping ändert sich: Feature-Requirements und andere Daten (zum Beispiel CAN-Signale oder Leitungspotentiale) werden auch direkt an das neue Mapping angepasst.

Bild 1: Der Traum vieler Fahrzeughersteller: Einfach den "BuildMyCar"-Button drücken und das fertig konzipierte Fahrzeug einfach nachbauen.

Bild 1: Der Traum vieler Fahrzeughersteller: Einfach den Build-My-Car-Button drücken und das fertig konzipierte Fahrzeug nachbauen. EDAG BFFT Electronics

Der Traum des Build-My-Car-Buttons kommt damit der Realität ein Stück weit näher (Bild 1). Auf Knopfdruck soll es dann möglich, anhand der Feature-Definition Bausteine, die bei der Realisierung der Fahrzeugspezifikation hilfreich sind, in ein neues Fahrzeugprojekt zu kopieren. Diese setzen sich wie Puzzleteile zu einer neuen E/E-Architektur zusammen und beschreiben eine initiale Fahrzeugspezifikation. Das legt die Basis für die weitere Entwicklung. Startups, die erstmalig ein Fahrzeug entwickeln möchten, beginnen damit nicht mehr auf dem weißen Blatt Papier, sondern können auf umfangreiche, generische Dokumente und Datensätze zurückgreifen. Zu den Puzzleteilen gehört auch eine Spielwiese möglicher Komponenten, die die Architekten bewerten und im Anschluss in eine initiale Stückliste (Bill of materials, BoM) exportieren. Durch die verknüpften Informationen sind neben der Anzahl der benötigten Sensoren, Steuergeräten und Aktuatoren auch initiale Angaben zu Fahrzeuggewicht und Fahrzeugkosten möglich. Das erlaubt bereits vor der Anfrage der Bauteillieferanten erste Aussagen, ob die Kosten- und Gewichtsziele erreichbar sind.

Bausteine der E/E-Architekturentwicklung

Bild 2: Verschiedene Bausteine des durchgängigen E/E-Architekturentwicklungsprozesses sind über eine eigens definierte Logik miteinander verbunden.

Bild 2: Verschiedene Bausteine des durchgängigen E/E-Architekturentwicklungsprozesses sind über eine eigens definierte Logik miteinander verbunden. EDAG BFFT Electronics

Abbildung 2 zeigt die verschiedenen Bausteine des durchgängigen E/E-Architekturentwicklungsprozesses. Sie sind untereinander mit einer eigens definierten Logik verbunden, sodass sich daraus Mehrwerte durch die Verkettung von entsprechenden Elementen generieren lassen. Neben dem Prozess pflegt EDAG BFFT Electronics auch die zugehörigen Datenbanken, aus deren Informationen die Entwickler neue Bordnetze realisieren oder bestehende Bordnetze erweitern können. Dies ist besonders interessant für Startups, die keinen Zugang zu den für die Fahrzeugentwicklung benötigten Architekturen haben. Diese Firmen haben die Vision und den Business-Case für ein neues Fahrzeugkonzept, benötigen aber auch Spezifikationen, Requirements, Komponenteninformationen und ein Lieferantennetzwerk. Die verfügbaren Datenbankinformationen, die generische Architekturen beschreiben, reduzieren den Zeitaufwand drastisch. Das erlaubt bereits zu Beginn der Fahrzeugentwicklung die Anfrage von Lieferanten mit High-Level-Spezifikationen.

Das Tool Eddna (Bild 3), welches aus einem Server-Backend und einer Frontend-GUI (Graphical User Interface, GUI, (Über PC oder iPad)) besteht, erleichtert die Pflege der Benchmark- und Feature-Daten. Der wesentliche Vorteil liegt aber darin, gemeinsam mit dem Startup-Kunden das Zielfahrzeug (plus Derivate oder einer ganzen Plattform) mit der zugehörigen S&O-Definition (Standard und Optionsliste) initial beschreiben zu können. So entsteht aus der Kundenvision sehr schnell eine erste Fahrzeugdefinition. Um das Fahrzeug im Mitbewerberumfeld zu platzieren, helfen Benchmark-Daten ausgewählter Fahrzeuge oder Umfrageergebnisse für noch nicht am Markt verfügbare Features. Ebenso zeigt Eddna, ob ein Feature gesetzeskonform ist beziehungsweise ob es Punkte bei der Definition der NCAP-Sterne erbringt. Zum Schluss lässt sich das Resultat in Preevision importieren und über den Build-My-Car-Button ein neues Projekt mit den verfügbaren Architekturbausteinen anlegen.

Bild 3: Das Eddna-Tool besteht aus einem server-backend und einer Frontend-GUI und erleichtert die Pflege der Benchmark- und Feature-Daten.

Bild 3: Das Eddna-Tool besteht aus einem Server-Backend und einer Frontend-GUI und erleichtert die Pflege der Benchmark- und Feature-Daten. EDAG BFFT Electronics

Das Tool Edbom ermöglicht die Pflege der Hardwarebibliothek, die sich regelmäßig mit Preevision synchronisiert. Über das GUI pflegen Ingenieure für die einzelnen Bauteile Eigenschaften wie Abmessungen, Verbauort, Ströme (Ruhestrom, Betriebsstrom, Maximalstrom) aber auch Gewicht und Kosten. All diese Daten sind als generischer Datensatz vorhanden, um bereits vor dem ersten Lieferantenkontakt Analysen bezüglich Energieverbrauch, Fahrzeuggewicht und Fahrzeugkosten zu erhalten.

Potenzielle Lieferanten für die generischen Bauteile ergänzen die Liste, damit Startup-Kunden schnell Kontakt zu weltweit verteilten Lieferanten finden. Die Verantwortlichen erweitern die Datenbank zudem regelmäßig um schutzrechtefreie Komponenten. Dies sind Komponenten, die Off-The-Shelf verfügbar sind und für neue Fahrzeugprojekte zur Verfügung stehen. Lieferanten weltweit sind aufgerufen, sich mit ihren Komponenten in dieser Datenbank zu registrieren und sich damit für Startup-Kunden attraktiver machen.

Bordnetzentwickler können zudem frühzeitig die Leitungssatzentwicklung starten, weil für die Komponenten bereits elektrische Bordnetzinformationen wie Stecker, Pins und Leitungsdaten angelegt sind. Eine eigenentwickelte Metrik erlaubt den Export der jeweiligen Arbeitsstände in eine Prototypen-BOM. Für die generischen Bauteile beziehungsweise die schutzrechtefreien Komponenten lassen sich mit der initialen Stückliste bereits Bauraumreservierungen in 3D-Systemen vornehmen und im Anschluss Verlegewege für das elektrische Bordnetz definieren.

Spezielle Reportformate können über eigene Metriken verschiedene Spezifikationen in handelsübliche Formate (MS Word, PDF) exportieren. Dies reicht von Fahrzeugspezifikationen mit einer Gesamtfahrzeugbeschreibung über Lieferantenanfrage-Unterlagen auf System- oder Komponentenebene bis hin zu Lastenheften sowie Testspezifikationen.

Der E/E-Architekturentwicklungsprozess verwaltet neben der Technik aber auch Aktivitäten und Aufwände. So enthält der Prozess einen generischen PEP (Produkt-Entstehungs-Prozess) mit Projektphasen, Meilensteinen und Aktivitäten inklusive benötigter Mitarbeiterrollen sowie geschätzter Aufwände. Durch eine geschickte Verlinkung exportiert eine Metrik, basierend auf der Stückliste, die notwendigen Aktivitäten für jedes Bauteil. Handelsübliche Projektmanagement-Tools mit agilen Methoden wie Sprints erlauben es im Anschluss, diese Aktivitäten detaillierter auszugestalten und nachzuverfolgen.

Alles Inklusive

Bild 4: Grobübersicht über den E/E-Architekturentwicklungsprozess mit Eingangsquellen und Tools.

Bild 4: Grobübersicht über den E/E-Architekturentwicklungsprozess mit Eingangsquellen und Tools. EDAG BFFT Electronics

Bild 4 zeigt den E/E-Architekturentwicklungsprozess als Grobübersicht mit Eingangsquellen und Tools. Innerhalb des Prozesses erfolgt eine konsistente Datenverarbeitung, in dem alle für die Entwicklung benötigten Elemente verlinkt sind. Intelligente Metriken verarbeiten im Anschluss die Elemente dann weiter. Am Ende der durchgängigen Prozesskette stehen Spezifikation sowie Anfrageunterlagen, welche die Architekturentwicklung in Zukunft deutlich verbessern und die Entwicklungszeit reduzieren können.

Durch die Kombination von Datenkonsistenz, kundenspezifischer Schnittstellen beziehungsweise Metriken, Erweiterung durch Tools wie Eddna, Edbom sowie branchenübliche Tools (3D, PDM, MS Office) und einem übergeordneten Prozess ist nunmehr eine durchgängige und toolgestützte E/E-Architekturentwicklung möglich, die auch den neuen Trends und der voranschreitenden Digitalisierung Rechnung trägt. Neben den klassischen Architekturen sind damit auch neue Ansätze wie die service-orientierte Architektur und die Zonenarchitektur umsetzbar. Diese Entwicklung trägt dazu bei, dass sich die Lücke zwischen hochmodernen Funktionen im Fahrzeug und dem traditionellen Excel-Engineering nach und nach schließt.

Dipl.-Ing (FH) Mario Maul

(Bild: EDAG BFFT Electronics)

ist Projektleiter Vehicle Electrics / Electronics bei EDAG BFFT Electronics in Fulda

Dipl.-Ing (FH) Gerhard Becker

(Bild: EDAG BFFT Electronics)

ist Abteilungsleiter Vehicle Electrics / Electronics bei EDAG BFFT Electronics in Fulda

(aok)

Sie möchten gerne weiterlesen?

Unternehmen

EDAG Engineering GmbH

Reesbergstraße 1
36039 Fulda
Germany