Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
Connected Car | Entwicklungswerkzeuge 22 Elektronik automotive 02 2020 ein Hypervisor als Host für verschiedene virtuelle Maschinen und einen virtuellen Switch zum Einsatz Auf jeder virtuellen Maschine kann ein unterschiedliches Betriebssystem zum Einsatz kommen etwa AUTOSAR Adaptive und Android Auf dem Mikrocontroller wird AUTOSAR Classic verwendet Feature-Modell für die Fahrzeugfunktionen einer Produktlinie Die E E-Architektur bildet den Rahmen für die Ausgestaltung der Fahrzeugfunktionen Dabei erfolgt die Entwicklung wie bisher in einem Produktlinienansatz Entwicklungsgegenstand ist nicht ein System oder eine Funktion für ein bestimmtes Fahrzeug sondern für eine ganze Fahrzeugfamilie mit vielen verschiedenen Antriebs-Aufbauund Ausstattungsoptionen Startpunkt für die Systemund Funktionsentwicklung ist die Festlegung der zu entwickelnden Fahrzeug-Features für diese Produktlinie sowie das Erfassen der notwendigen Varianten Das kann in einer Liste oder besser in einem FeatureModell erfolgen Bild 3 In AUTOSAR sind vier verschiedene logische Dekompositions-Beziehungen zwischen einem Kompositions-Feature und seinen Teil-Features festgelegt ➔ mandatory Must Use ➔ alternative Requires Xor ➔ multiple Requires Or und ➔ optional Optional Darüber hinaus können zwischen beliebigen Features im Kompositionsbaum die logischen Relationsbeziehungen excludes und requires verwendet werden Zuständig für die Festlegung des Feature-Modells ist die strategische Produktplanung die dadurch wesentliche Vorgaben an die E E-Architektur macht Funktionsentwicklung für verteilte und vernetzte Systeme Im vorgegebenen Rahmen von Feature-Modell und E E-Architektur für eine Fahrzeugproduktlinie erfolgt die Systemund Funktionsentwicklung In den letzten Jahren hat ergänzend zur anforderungsbasierten Systemspezifikation die modellbasierte Spezifikation der funktionalen Zusammenhänge große Akzeptanz erfahren Dabei wird die Kundenfunktionalität vom Anfang bis zum Ende also von den beteiligten Sensoren über die eigentlichen Funktionen bis hin zu den notwendigen Aktuatoren betrachtet Die Beschreibung erfolgt mit Blockdiagrammen auf abstrakter logischer Ebene weitgehend unabhängig von der späteren ImpleBild 3 Feature-Modell nach AUTOSAR in PREEvision Bild Vector Informatik Bild 4 Logische Architektur zweier Fahrzeugfunktionen in PREEvision Bild Vector Informatik mentierung in Software und Hardware Während die Implementierung in Hardware und Software Änderungszyklen von Fahrzeuggeneration zu Fahrzeuggeneration unterworfen ist bleibt diese logische Architektur für viele Funktionen über mehrere Generationen hinweg nahezu stabil Viele dieser Funktionen werden im Steuergerätenetzwerk verteilt implementiert Das hat verschiedene Gründe und bietet viele Vorteile Um nur einige Aspekte zu nennen ➔ Verwendung derselben Sensoren oder Aktuatoren für mehrere Funktionen ➔ Funktionale Sicherheit durch Redundanz in der Hardware ➔ Örtlich weit auseinander liegende geometrische Positionen der Sensoren und Aktuatoren im Fahrzeug und durch verteilte Implementierung mögliche Reduzierung des Leitungssatzaufwandes Betrachtet man ein einfaches Beispiel für die logische Architektur von zwei Fahrzeug-Features Xund Y Bild 4 Feature Xwird durch die Wirkkette der drei Blöcke Sensorfunktion 1 Funktion 1 und Aktuatorfunktion 1 umgesetzt Feature Ydurch 9 Blöcke Zwischen beiden Features gibt es Schnittmengen Die Blöcke sind organisatorisch eindeutig den beiden Systemen Aund Bzugeordnet Um die spätere Durchgängigkeit von der logischen Architektur in die Softwareimplementierung zu gewährleisten orientiert sich die Spezifikation der Schnittstellen der logischen Funktionen an AUTOSAR Neben AUTOSAR Classic kommt dafür auch AUTOSAR Adaptive als Plattform für die Implementierung zum Einsatz Weiterhin sind auch Funktionsanteile die offboard also