e/e-entwicklung für zukünftige ... - vector: software · seiten verschiedener autorenwerkzeuge...

01

Viele Funktionen, die vom E/E-System moderner Fahr- zeuge bereitgestellt werden, können nach wie vor den klassischen Domänen Antriebsstrang, Fahrwerk, Karos-serie oder Multi-Media zugeordnet werden (Bild 1). Durch den Einsatz neuer Technologien innerhalb und außerhalb des Fahrzeugs gewinnen Themen wie Fahrerassistenz, automatisiertes Fahren und Konnektivität (Car2x/V2x) jedoch massiv an Bedeutung.

Ein derart umfangreiches Funktions- und Steuergeräte- netzwerk lässt sich nur noch effizient beherrschen, wenn die Entwicklungsorganisation sich auf eine rechner- gestützte Entwicklungsumgebung mit einer zentralen E/E-Datenbasis stützen kann. Ohne diese Entwicklungs- umgebung steigt der Aufwand zur internen Abstimmung und zur Pflege redundanter und möglicherweise inkonsis-tenter Daten.

Die Entwicklung moderner Elektrik-/Elektronik-Architekturen (E/E) ist heute mehr denn je eine Herausforderung: Zahlreiche Entwicklungskriterien müssen berücksichtigt und die klassischen Fahrzeugdomänen mit neuen Funktionen aus den Bereichen Fahrerassistenz und autonomes Fahren verbunden werden. Dabei entstehen völlig neue Funktionen, die nicht mehr nur auf das Fahrzeug beschränkt sind, sondern auch als Dienste im „IT-Backend“ außerhalb des Fahrzeugs bereitgestellt werden. Die Einführung von serviceorientierten Architekturen und leistungsstarken Domänenrechnern, von Ethernet zur Onboard-Kommunikation, von Connectivity-Gateways und nicht zuletzt steigende Safety- und Security- Anforderungen stellen tiefgreifende Umbrüche für jede Entwicklungsorganisation dar. Um diese komplexen Entwicklungs- aufgaben erfolgreich im Team zu meistern, sind eine Entwicklungsplattform und eine E/E-Datenbank notwendig, die auf unterschiedliche Arten realisiert werden können.

E/E-Entwicklung für zukünftige Fahrzeuginnovationen:Ein integrierter, modellbasierter Ansatz

PREEvision Fachartikel

Die Folge sind hohe Kosten in der Entwicklung, erhöhter Zeitaufwand und – im schlimmsten Fall – Fehler, die erst im Feld erkannt werden.

Funktions- und Steuergerätenetzwerk im Griff behaltenDie meisten Fahrzeugfunktionen, die vom E/E-System bereitgestellt werden, sind Steuerungs-, Regelungs-, Über-wachungs- und Diagnosefunktionen. Sie interagieren mit den mechanischen Fahrzeugkomponenten über Sensoren und Aktuatoren. Da die Sensoren und Aktuatoren an ver-schiedenen geometrischen Orten im Fahrzeug installiert sind, sind E/E-Systeme natürlicherweise geometrisch verteilte Systeme. Viele Funktionen wirken innerhalb einer Domäne, aber auch über Domänengrenzen hinweg mitein-ander zusammen – in einem Funktionsnetz. Besonders die Fahrerassistenzfunktionen wirken mit den Funktionen der Antriebs-, Lenkungs- und Bremssysteme eng zusammen. Dies kann anhand von Wirkketten der notwendigen Sen-

02

E/E-Entwicklung für zukünftige Fahrzeuginnovationen / Dezember 2016

Bild 1: Steuergerätenetzwerk

soren, Steuergerätefunktionen und Aktuatoren verdeut-licht werden, die zur Implementierung einer Fahrzeugfunk-tion notwendig sind (Bild 2).

Die Definition des Funktions- und Steuergerätenetzwerks und die Verteilung der Funktionen auf das Steuergeräte- netzwerk stellen einen großen Freiheitsgrad beim Entwurf dar – und sind damit eine wichtige Architekturentschei-dung. Nahezu alle Bewertungskriterien einer Architektur wie Kosten, Gewicht, Bauraum, Buslast, Safety oder Security werden dadurch beeinflusst. Für den Serie-nentwicklungsprozess bedeutet dies, dass konsequent zwischen den beiden Ebenen Funktions- und Steuergeräte- netzwerk unterschieden werden muss. Darüber hinaus werden diese Ebenen nicht nur für eine spezielle Aufbau-variante entwickelt. Die Entwicklung deckt immer eine größere Anzahl von Fahrzeugen ab, die auf Basis dieser gemeinsamen Plattform entwickelt werden: Typischer-

weise sind viele Personen involviert und es werden mehrere Varianten – in der Regel mehr als zwanzig – gemeinsam entwickelt. Dadurch ist die Komplexität der Aufgabe enorm. Sie kann nur noch bewältigt werden, wenn eine Organisation den Gesamtüberblick über die Entwicklung-sartefakte und deren Zusammenwirken behält – durch gemeinsame Ablage der Artefakte, Visualisierung, rechnerunterstützte Auswertungen und Entwurfsautoma-tisierung.

Prozessbeherrschung bei der Partitionierung und Integration des E/E-SystemsDiese Unterscheidung zwischen Funktions- und Steuerge- rätenetzwerk stellt eine entscheidende Voraussetzung für die erfolgreiche Partitionierung und Integration des E/E-Systems und die Zusammenarbeit zwischen Fahrzeug- herstellern und Lieferanten dar. Darauf aufbauend können die Aufgaben, Rollen und Zuständigkeiten bei der Partition-

Bild 2: Funktionsnetz

03


ierung und Integration sowohl des Funktions- als auch des Steuergerätenetzwerks präzise festgelegt, geplant und verfolgt werden. Ein Überblick über den Gesamtprozess in der E/E-Entwicklung ist in Bild 3 dargestellt [1].

Der Entwicklungsprozess muss durch geeignete IT-Sys-teme unterstützt werden. Dazu werden für Entwicklungs-disziplinen wie mechanische Konstruktion, E/E-Entwicklung, Software- und Hardware-Entwicklung spezifische Werk- zeuge verwendet (Bild 4). Alle dort entstehenden Entwick-lungsergebnisse werden an ein Product Life Cycle Manage-ment System (PLM System) abgeliefert, das die an-schließenden Fertigungs- und Serviceprozesse unterstützt.

Austauschstandards als Schlüssel zum ErfolgIn der E/E-Entwicklung, insbesondere an der Schnittstelle zwischen Fahrzeugherstellern und Lieferanten, wurden die Vorteile standardisierter Austauschformate für E/E-Arte-fakte bereits seit langem erkannt. Die notwendigen Standards sind inzwischen vorhanden, konsolidiert, breit akzeptiert und seit Jahren betriebsbewährt:

> Für den Austausch von Anforderungen, Funktions- beschreibungen und Testfällen werden ReqIF oder RIF eingesetzt. > AUTOSAR stellt eine Basis-Software-Plattform für Steuergeräte zur Verfügung, die über umfassende Beschreibungsformate konfiguriert werden kann. Das wichtigste Format dazu ist die AUTOSAR System Description. Sie deckt die Bereiche Software-Architektur, Steuergerätenetzwerk und Kommunikation für CAN,

Bild 3: Prozessbeherrschung als Herausforderung in der E/E-Entwicklung [1]

Zulieferer-prozesse

Entwicklungsprozesse Fertigungs- undServiceprozesse

Integrations-prozesse

Lieferant 2

Lieferant 3

...

Lieferant n

Lieferant 1

Zulieferer-integration

Prozess-,Methoden- undWerkzeugintegration

System-integration

Funk

tion

ale

Inte

grat

ion

Geo

met

risc

he In

tegr

atio

n

Fert

igun

gste

chni

sche

Inte

grat

ion

Fahrwerk

Antriebsstrang

Fahrerassistenz

Karosserie

Multi-Media

Bild 4: IT-Unterstützung in Entwicklung, Fertigung und Service

CADUmgebung

PLM System

E/E Entwicklungs-umgebung

SoftwareEntwicklungs-umgebung

HardwareEntwicklungs-umgebung

04


> Geordnetes Änderungs- und Freigabe-Management mit integrierter Release- und Projektplanung sowie transparenter Projektverfolgung > Beherrschbarer Pflegeaufwand für die E/E-Artefakte durch Single Source Prinzip bei der Datenablage > Granulares Berechtigungs- und Reifegradkonzept für die Abbildung unterschiedlicher Rollen > Unterstützung von großen Organisationen mit vielen Anwendern, großen Datenmengen und verschiedenen Entwicklungsstandorten > Einbindung von Kunden und Lieferanten > Vertretbarer Administrations- und Betriebsaufwand inclusive Backup-Unterstützung > Zukunftssicherheit durch konsequente Weiterentwicklung der E/E-Entwicklungsumgebung und Migration der vorhandenen Daten > Offenheit durch flexible Integration in die bestehende IT-, Prozess- und Werkzeuglandschaft

Für die Realisierung einer E/E-Entwicklungsumgebung gibt es grundsätzlich verschiedene Alternativen:

1. Dokumentenbasierte Arbeitsweise:Verwendung von verschiedenen Autorenwerkzeugen und Ablage der erzeugten Dateiartefakte in einer zentralen Datenbank (Bild 5a)

Die Vorteile des Einsatzes von betriebsbewährten Autoren-werkzeugen mit entsprechendem Datenbestand werden durch den Nachteil einer nur auf den damit erzeugten Dateien verfügbaren, grob granular unterstützten Teamar-beit und Verfolgbarkeit kompensiert. Eine teamübergreif-ende enge Zusammenarbeit auf der Ebene detaillierter E/E-Artefakte nach dem Single-Source-Prinzip ist damit

LIN, FlexRay und Ethernet bezüglich der auszutausch-enden Daten zwischen Fahrzeughersteller und Steuergerätezulieferer vollständig ab. > Für den Austausch von Leitungssatz- und Geometrie-informationen ist KBL weit verbreitet. Es wird erwartet, dass dieser Standard in den kommenden Jahren durch VEC ergänzt und mittelfristig ersetzt wird.

Damit sind wesentliche Umfänge für den E/E-Daten- austausch zwischen Lieferant und Hersteller abgedeckt. Textbasierte Spezifikationsdokumente werden immer mehr durch den Austausch von „digitalen“ Spezifikationen in diesen Formaten ergänzt oder sogar ganz abgelöst.

Teamplattform für die E-/E-EntwicklungDie Erstellung und Pflege dieser E/E-Spezifikationsanteile erfolgt immer verteilt in Teams und Abteilungen, oft sogar über Unternehmensgrenzen hinweg. Diese Teamunter-stützung muss durch die eingesetzten Entwicklung-swerkzeuge ermöglicht werden. Damit stellt sich sofort die Frage nach einer geeigneten Team- und Datenbankplat-tform, an die folgende grundsätzliche Anforderungen gestellt werden:

> Mehrbenutzerbetrieb: Gleichzeitige, parallele Bearbeitung von Artefakten durch mehrere Anwender mit möglichst geringem Konfliktpotential > Verfolgbarkeit von den Anforderungen über die Implementierung bis zu den Testfällen (insbesondere bei sicherheitsrelevanten Funktionen von der ISO 26262 gefordert) > Archivierungs-, Versionierungs- und Wiederver-wendungskonzept für die entstehenden E/E-Artefakte auf granularer Ebene

Bild 5a: Dokumentenbasierte Arbeitsweise

Dateischnittstelle

DateibasiertesVersionsmanagement

Autorentool 1

Funktionen,Komponenten,Anforderungen,Testfälle,...

Autorentool 3

Schaltplan,Leitungssatz,Stecker, Pins,...

Autorentool 2

System Design,Software Design,Kommunikation,...

05


2. Modellbasierte, aber verteilte Arbeitsweise:Verwendung von verschiedenen Autorenwerkzeugen und Ablage der damit erzeugten Modellartefakte in dezentralen Datenbanken (Bild 5b)

Viele Autorenwerkzeuge bringen daher inzwischen ihre eigene Team- und Datenbankplattform mit, unterstützen aber nicht alle notwendigen Anwendungsfälle. Die Integra-tion von Insellösungen mit Autorenwerkzeugen für ver-schiedene Anwendungsfälle erscheint daher auf den ersten Blick naheliegend. Vorteilhaft ist der schnelle Einsatz betriebsbewährter Autorenwerkzeuge im Team. Nachteilig wirkt sich weiterhin die eingeschränkte Durchgängigkeit aus. Aus Betriebssicht sind mehrere Datenbanken und mehrere Autorenwerkzeuge zu warten und eventuell sogar noch zu integrieren. Es entstehen Punkt-zu-Punkt-Verbind-ungen. Integrationen sind über Standards wie OSLC mach-bar; die integrierten Artefakte werden nach dem Single Source Prinzip an einer Stelle abgelegt, sind dann aber von Seiten verschiedener Autorenwerkzeuge sichtbar und sogar editierbar. Die so entstandenen Beziehungen über Datenbankgrenzen hinweg sind aber nicht sicher version-ierbar und archivierbar.

Häufig wird daher auch eine überlappende, redundante Datenhaltung mit Stellvertreterobjekten in Kauf genom-men. Dies kann über zyklische Export-/Import- und Update-Vorgänge gewährleistet werden. Weitere Nachteile sind ein – nach wie vor – nicht vorhandenes durchgängiges Datenmodell, die – nach wie vor – spürbaren Werkzeug-grenzen, verschiedene Architekturen (z.B. Rich Client oder Web Client) sowie unterschiedliche Freigabe-, Version-ierungs-, Backup- und Migrationskonzepte. Es entsteht hoher Integrations- und Betriebsaufwand.

nicht machbar. Auch eine durchgängige Entwicklung über die einzelnen Autorenwerkzeuggrenzen hinweg ist schwi-erig und erfordert manuellen Mehraufwand.

Obwohl viele verbreitete Autorenwerkzeuge bis dato nur diese Arbeitsweise unterstützen, ist diese zwar für einen einzelnen Arbeitsplatz geeignet, erscheint für den Einsatz im Team aber nicht mehr zeitgemäß. Aus Betriebssicht sind verschiedene Autorenwerkzeuge auszurollen und eine ge-meinsame Datenbank ist zu betreiben und zu warten. Diese dateibasierte Arbeitsweise wird in der benachbarten Software Entwicklung eingesetzt und durch dateibasierte Merge-, Update-, Versionierungs- und Branch-Verfahren unterstützt.

Aber auch in dieser Disziplin sind die Grenzen erkennbar. Beispielsweise lässt sich eine Anforderung nur schwer auf eine Software-Funktion verlinken, die in einer großen Datei steht. In der E/E-Entwicklung sind die Artefakte sehr viel feingranularer wie Anforderungen, Funktionen, Signale, Steuergeräte, Busse, Pins und Stecker.

Die Beziehungen zwischen diesen Artefakten sind wichtig und – wenn sich diese Artefakte in größeren Dateien „vers-tecken“ – nur schwer nachvollziehbar. Daher ist in der E/E-Entwicklung ein modellbasierter Ansatz notwendig, bei dem die verschiedenen E/E-Artefakte und ihre Beziehu-ngen granular aufgelöst und verwaltet werden können.

Bild 5b: Modellbasierte, aber verteilte Arbeitsweise

Datenbank 1 Datenbank 2 Datenbank 3

Import/Export

Integration

Autorentool 1


Autorentool 2


Autorentool 3


06


Erst durch die inzwischen erreichte Akzeptanz der anfangs genannten Standards in der Automobilindustrie konnte ein dadurch inspiriertes, durchgängiges und vollständiges Automotive E/E-Datenmodell entworfen werden. Es bildet in PREEvision die Grundlage für eine durchgängige modell-basierte Arbeitsweise von den Anforderungen über alle Implementierungsschritte bis hin zu den Tests.

3. Modellbasierte und integrierte ArbeitsweiseVerwendung eines durchgängigen Autorenwerkzeugs und Ablage der erzeugten Modellartefakte in einer zentralen Datenbank (Bild 5c)

Die Schwachstellen einer modellbasierten, aber verteilten Arbeitsweise können durch Verwendung eines durchgängi-gen Autorenwerkzeugs und die zentrale Ablage in einer Datenbank aufgelöst werden. Dieser Ansatz löst die meis-ten der oben angesprochenen Probleme. Dort, wo die Vorteile eines durchgängigen E/E-Engineering-Daten- modells mit einer zentralen Datenablage erkannt wurden, entstanden in der Vergangenheit häufig proprietäre Eige-nentwicklungen – oft Datenbanken – als Lösung, weil eine kommerzielle Produktlösung schlicht nicht verfügbar war.

Proprietäre Lösungen – aufwändig und teuerDie Vorteile und Nachteile liegen auf der Hand: Mit einer proprietären Lösung kann ganz gezielt das Datenmodell und das Vorgehen in der Organisation unterstützt werden. Proprietäre Lösungen führen aber zu hohem Entwicklungs-, Wartungs- und Testaufwand. Ebenso ist die Benutzer-schnittstelle oft nicht auf dem Stand der Technik.

Produktlösung mit weitreichenden Konfigurations-möglichkeiten – machbar und wirtschaftlichEine Produktlösung mit weitreichenden Konfigurations-möglichkeiten ist bei entsprechender Verbreitung wirtschaftlich – genau diesem Ansatz folgt PREEvision.

Bild 5c: Modellbasierte und integrierte Arbeitsweise

Autorentool

Datenbank

Bild 6: Die Abstraktionsebenen im PREEvision Datenmodell

Systems-Engineering-Prinzipien

PREEvision Ebenen

Anforderungen

LogischeFunktionsarchitektur

Software-/Service-Architektur

Kom

mun

ikat

ion

Hardware-Architektur

Leitungssatz

Automotive-Standards undImport-/Export-Schnittstellen

PREEvision Datenmodell

RIF

Req IF

AUTO-SAR

KBL

Abstraktion

Wiederverwendung

Dekomposition

07


Alle notwendigen Aspekte einer E/E-Architektur werden in einem integralen Ansatz modelliert:

> Funktionen, Merkmale und Anforderungen > Netzwerkaspekte und Funktionsverteilung > Software- und Kommunikationsaspekte > Hardware-, Leitungssatz- und Geometrieaspekte

Dabei folgt PREEvision den drei bewährten Systems- Engineering-Prinzipien Abstraktion, Dekomposition und Wiederverwendung – und unterstützt die Modellierung von Produktlinien und Produktvarianten mit verschiedenen Modellebenen (Bild 6).

In vertikaler Richtung sind die Abstraktionsebenen von der Geometrieebene mit Einbauorten und Verlegewegen über die Leitungssatzebene, die elektrologische Ebene bis zur Steuergerätenetzwerk-Ebene dargestellt. Parallel dazu werden die Software- und Kommunikationsdetails model-liert. Hardware- und Software-Aspekte werden abstrakt in der Ebene der logischen Funktionsarchitektur beschrieben.

Ein noch größerer Abstraktionsgrad erfolgt auf den Ebenen für Anforderungen und Kundenfunktionen (Merkmalen). Die horizontale Richtung des PREEvision Modells unter-stützt die Dekomposition: In jeder Ebene stehen Hierar-chiekonzepte zur Verfügung, welche „bottom up“ oder „top down“ verwendet werden können. Die dritte Richtung ist orthogonal zu den beiden anderen angelegt und ermöglicht Wiederverwendungs- und Variantenkonzepte auf jeder Modellebene und Hierarchiestufe.

Ein zusätzlicher Nutzen entsteht durch die logische Funk-tionsarchitektur, die von der Implementierung in Hardware und Software abstrahiert. Hier können die Wirkketten für Fahrzeugfunktionen beschrieben werden – diese sind häu-fig über viele Jahre stabil, während sich die Hardware-, Software- oder Kommunikationstechnologien für deren Implementierung von Fahrzeuggeneration zu Fahrzeug-generation ändern. Dies gilt sowohl für Funktionen mit steuerungs- und regelungstechnischem Charakter in den Domänen Antriebsstrang, Fahrwerk, Fahrerassistenz und Karosserie als auch für die Funktionen der Multi-Media-

Bild 7: Architektur der PREEvision Kollaborationsplattform

...

Including: MiddlewareLicense Server

Collaboration Platform

HTTP/HTTPSe.g. Port 8080

Database Server

Subversion Server

TCP/IPe.g. Port 1521

HTTP/HTTPSe.g. Port 8080

Application Server

Client Client Client Client

Optional: Separate License Server

RMIe.g. Port 1099

License Server

08


Systeme. Alle diese Ebenen sind über so genannte „Map-pings“ miteinander verbunden. Die Ablage von Dateien, die beispielsweise durch Werkzeuge für die Verhaltensmodel-lierung von Funktionen, für die Simulation, das Rapid Prototyping und die Codegenerierung erzeugt werden, ist in diesem Modellkontext an vielen Stellen möglich.

Import- und Exportschnittstellen zur Erzeugung und Verar-beitung der Spezifikationsformate RIF, ReqIF, AUTOSAR und KBL stehen zur Verfügung. Das PREEvision Daten-modell fasst die damit auszutauschenden Daten zu leicht verständlichen, einfach bearbeitbaren und wiederverwend-baren Engineering-Artefakten wie Steuergeräten, Steckern, Pins, Softwarekomponenten, Signalen oder Botschaften zusammen und bietet die notwendigen Bezie-hungen dazwischen an. Leistungsfähige Engineer-ing-Werkzeuge, graphische Diagramme und tabellen-basierte Editoren ermöglichen eine einfache Bearbeitung. Safety-Aspekte werden durch Sicherheitsanalysen wie die Gefahren- und Risikoanalyse, FMEA oder Fehlerbaum- analyse unterstützt, die auf den bestehenden Produk-tliniendaten durchgeführt werden.

Der integrierte, modellbasierte Ansatz unterstützt das Sin-gle Source Prinzip. Das Modell kann mit konfigurierbaren Validierungen auf Konsistenz und Vollständigkeit geprüft werden. Mit dem Merkmalsmodell nach FODA in der Kundenfunktionsebene kann eine gültige Selektion von Merkmalen für eine Fahrzeugvariante definiert werden [2].

Die Merkmale sind mit den entsprechenden Artefakten al-ler anderen Ebenen verbunden. Damit wird es möglich, eine E/E-Architektur für ausgewählte Varianten abzuleiten, zu bearbeiten, zu prüfen und zu exportieren.

Teamarbeit unterstützt PREEvision mit einer Kollabora-tionsplattform in 3-Tier Architektur (Bild 7). Ein Team von Anwendern kann parallel in einer Produktlinie arbeiten; alle E/E-Artefakte unterliegen einer feingranularen Versions-verwaltung und werden für koordinierte Änderungs- und Freigabeprozesse mit Tickets verbunden.

Zum ausgereiften, betriebsbewährten und offengelegten Datenmodell sowie vielen Entwicklungswerkzeugen im Produktumfang kommen umfangreiche Konfigurations-möglichkeiten hinzu: Rollen und Rechte, zusätzliche anwendungsspezifische Attribute, Reifegrade, Berichte, Tabelleneditoren und -ansichten, Skripte, Validierungen und spezifische, auch automatisierbare Import- und Exportschnittstellen.

Damit können die besonderen Bedürfnisse der jeweiligen En-twicklungsorganisation flexibel abgebildet und PREEvision in die bestehende Prozess- und Werkzeuglandschaft integri-ert werden. Außerdem kann durch so genannte Perspektiven mit Filter- und Editorvoreinstellungen eine benutzerfreundli-che Bedienoberfläche für dedizierte Anwendungsfälle ein-gerichtet werden (Bild 8).

Bild 8: Perspektiven unterstützen dedizierte Anwendungsfälle

Datenbank

Autorentool




Perspektive 1 Perspektive 2 Perspektive 3

09


Literaturhinweise

[1] Hans-Georg Frischkorn, Herbert Negele, Johannes Meisenzahl, BMW Group, München: The Need for Systems Engineering. An Automotive Project Perspective. Key Note at the 2nd European Systems Engineering Conference (EuSEC 2000), München, 13. September 2000.

[2] Kang, Kyo c. et al: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report CMU/SEI-90-TR-21 ESD-90-TR-222, Software Engineering Insti-tute, Carnegie Mellon University, Pittsburg, Pennsylvania, USA, November 1990. www.sei.cmu.edu/reports/90tr021.pdf

Autoren Dr. Thomas Beck Vector Informatik GmbH Geschäftsführer

Dr.-Ing. Clemens Reichmann Vector Informatik GmbH Technischer Direktor PREEvision

Dipl.-Ing. Jörg Schäuffele Vector Informatik GmbH Produktmanager PREEvision

Ursprünglich erschienen in ATZ elektronik Ausgabe 06 – Dezember 2016

Zusammenfassung und AusblickNicht zuletzt wird die Zukunftsfähigkeit durch die intensive Weiterentwicklung von PREEvision gewährleistet, um mit den rasanten Innovationen in der Automobilindustrie Schritt halten zu können. Ein Migrationskonzept für die Bestandsdaten in der Datenbank ist verfügbar; es er-möglicht die Weiterentwicklung des Datenmodells und den Umstieg auf neue PREEvision Versionen mit vertretbarem Aufwand – eine anspruchsvolle Aufgabe, deren Bedeutung bei einer Eigenentwicklung oft erst erkannt wird, wenn sie akut ist.

Der PREEvision-Ansatz hat sich seit Jahren im produktiven Einsatz bewährt und unterstützt durchgängig, modell-basiert und zukunftssicher die gesamte E/E-Entwicklung vom Anforderungsmanagement über Architekturentwurf, funktionsorientierte System- und Komponentenentwick-lung, Software- und Kommunikationsdesign, Leitungssatz-entwicklung bis hin zum Test und zur Serienfreigabe.

e/e-entwicklung für zukünftige ... - vector: software · seiten verschiedener autorenwerkzeuge...

Documents