Ein Angebot von /

FIBEX und AUTOSAR – Unterschiede und Gemeinsamkeiten

| Autor / Redakteur: Thomas Bachmann * / Thomas Kuther

FIBEX und AUTOSAR basieren auf den gleichen Grundlagen. Worin aber unterscheiden sich die beiden Standards im Einzelnen, welche Gemeinsamkeiten haben sie und wie lässt sich eine aktuelle FIBEX-Toolkette an AUTOSAR anpassen?
FIBEX und AUTOSAR basieren auf den gleichen Grundlagen. Worin aber unterscheiden sich die beiden Standards im Einzelnen, welche Gemeinsamkeiten haben sie und wie lässt sich eine aktuelle FIBEX-Toolkette an AUTOSAR anpassen? (Bild: Eberspaecher)

FIBEX und AUTOSAR basieren auf den gleichen Grundlagen. Worin aber unterscheiden sich die beiden Standards im Einzelnen, welche Gemeinsamkeiten haben sie und wie lässt sich eine aktuelle FIBEX-Toolkette an AUTOSAR anpassen?

FIBEX (Field Bus Exchange Format) ist ein XML-Format zur Beschreibung komplexer, nachrichtenorientierter Kommunikationssysteme. Der FIBEX-Standard (Bild 1) beschreibt ein multiprotokollfähiges Format zum Austausch von Daten in nachrichtenorientierten Kommunikationssystemen z.B. in Fahrzeugnetzwerken. Das FIBEX-Format kann für den Export von Bordnetzdatenbanken und für den Import in die unterschiedlichsten Tools bei der Entwicklung von Fahrzeugnetzwerken verwendet werden. Es unterstützt derzeit die Netzwerkprotokolle FlexRay, CAN, MOST und LIN. Von der Auslegung kompletter Cluster bis hin zur Definition auf Bit-Ebene können alle relevanten Informationen für die Beschreibung von Fahrzeugnetzwerken mit dem FIBEX-Format definiert werden.

Anhand von XML-Schemadateien definierter Standard

FIBEX ist ein frei verfügbarer firmenübergreifender Standard, der anhand von XML-Schemadateien definiert ist und damit auch validiert werden kann. Nicht den XML-Schemata entsprechende Dateien können damit leicht erkannt werden. Aufgrund des durch die ASAM (Association for Standardisation of Automation and Measuring Systems) definierten Standards ist von vorneherein sichergestellt, dass die Konvertierung und der Datenaustausch zwischen verschiedenen Tools vereinheitlicht und somit im Gegensatz zu den in der Vergangenheit oft auftretenden Inkompatibilitäten wesentlich vereinfacht wird.

Festlegen des Mapping-Verhaltens von Frames, PDUs und Signalen

Eine FIBEX-Datei (Version 3.0.0) ist in verschiedene Bereiche aufgeteilt. Unter Topology finden sich Informationen zu den jeweiligen Clustern, Steuergeräten (ECUs) und wie die ECUs über Kanäle (Channels) miteinander verbunden sind. Im Cluster werden u. a. alle globalen FlexRay-Parameter hinterlegt. Des Weiteren kann über ein Gateway-Element das Routing-Verhalten zwischen verschiedenen Bussystemen bestimmt werden. Dabei besteht die Möglichkeit das Mapping-Verhalten von Frames, PDUs und Signalen festzulegen. Im Communication-Bereich werden die Kommunikationsobjekte wie z.B. Frames und PDUs und deren Zeitverhalten definiert.

In der PDU werden Signale miteinander gruppiert

In FIBEX ist eine PDU als Interaction Layer Protocol Data Unit hinterlegt. In der PDU werden Signale miteinander gruppiert. Aus der Protokollsicht ist ein Frame unter FIBEX eine Data Link Layer Protocol Data Unit. In einem Frame werden ein oder mehrere PDUs mit Zusatzinformationen wie Update-Bit spezifiziert. Das Zeitverhalten der Kommunikationsobjekte wird über die Timingparameter für Absolutely-Scheduled-Timing, Event-Controlled-Timing, Cyclic-Timing und Request-Controlled-Timing beschrieben. Für FlexRay wird unter anderem das Absolutely-Scheduled-Timing verwendet, um zu beschreiben in welchem Slot und Cycle ein bestimmtes Kommunikationsobjekt gesendet wird. Weitere Bereiche sind Function und Signal.

Umrechnung der Rohdaten in physikalische oder darzustellende Werte

Unter Harmonized Data Objects werden physikalische Einheiten und Kodierungen der Signale hinterlegt. Die Kodierung definiert für ein Signal beziehungsweise eine Gruppe von Signalen die Art der Übertragung, also zum Beispiel die Bitlänge, den Offset und den Skalierungsfaktor. Damit wird festgelegt, wie Rohdaten in physikalische oder darzustellende Werte umgerechnet werden. Im Requirement-Bereich können Anforderungen u. a. für PDUs, Funktionen und Signalgruppen beschrieben werden. Unter Higher Protocols können Network-Management- und Transport-Layer-Informationen definiert werden.

Offener Standard für Softwarearchitekturen im Automobil

Der Grundgedanke von AUTOSAR lautet „Zusammenarbeit bei Standards – Wettbewerb bei der Umsetzung“. Folgende Ideen wurden bei der Realisierung von AUTOSAR berücksichtigt: Standardisierung von Systemfunktionen, Skalierbarkeit, Verschiebbarkeit von Funktionen, Integration und Austauschbarkeit von Software von verschiedenen Herstellern, Wartbarkeit über den gesamten Produktlebenszyklus.

AUTOSAR (Automotive Open System Architecture) ist ein Verbund mit dem Ziel, einen offenen Standard für Softwarearchitekturen in Fahrzeugen zu etablieren. In AUTOSAR bestehen Applikationen aus AUTOSAR-Softwarekomponenten (SW-C). Anwendungen werden in SW-Cs unterteilt, die miteinander kommunizieren (Bild 2).

Die Kommunikation wird unter AUTOSAR auf einem sehr abstrahierten Level abgebildet. Dies wird unter dem Begriff „Virtual Function Bus“ (VFB) zusammengefasst. Die SW-Cs kommunizieren dabei über sogenannte Ports ohne Kenntnis des Signalpfades. In einem späteren Entwicklungsschritt werden die SW-Cs dann auf Steuergeräte (ECUs) verteilt. Die AUTOSAR Runtime Environment (RTE) implementiert den VFB auf der jeweiligen ECU. Die RTE stellt eine bussystemunabhänge Schnittstelle zur Verfügung und leitet dabei die Befehle an die „Basic Software“ der jeweiligen ECU weiter. Die Basic Software greift dann direkt auf die Hardware zu.

AUTOSAR setzt auf XML als Austauschformat

AUTOSAR definiert eine Reihe von Schritten zur Erstellung einer ausführbaren ECU-Komponente (Bild 3). Als Austauschformat wird auf XML gesetzt. Diese XML-Dateien basieren auf einer Schemadatei, die von dem AUTOSAR UML Modell abgeleitet wurde. Die Schemadatei kann grob in vier Teilbereiche eingeteilt werden. Software Component Template zur Definition einzelner Softwarekomponenten. Basis Software Module Description Template zur Beschreibung aller Informationen einer Basis Software Komponente. ECU Configuration Template zur Definition von Architektur und Schnittstellen einer ECU. Das System Template dient zur Definition des Gesamtsystems. Im System Template sind u.a. Informationen über die Bussysteme, die Signale, das Mapping und die Topologie hinterlegt. Dieses Template hat sehr viele Gemeinsamkeiten mit dem FIBEX-Standard. Ab FIBEX 3.0 wurde sogar noch das PDU-Konzept aus AUTOSAR übernommen, um eine weitere Harmonisierung zwischen beiden Standards zu erreichen.

So kommt man von FIBEX nach AUTOSAR

Aufbauend auf den langjährigen FIBEX Erfahrungen bei Eberspächer Electronics sind Machbarkeitsstudien durchgeführt worden, die die Migration der FIBEX Toolkette auf AUTOSAR untersuchen sollten. Grundlage für diese Machbarkeitsstudien war ein Konverter von FIBEX nach AUTOSAR. Für diesen FIBEXtoAUTOSAR-Konverter wurden zuerst die Unterschiede zwischen FIBEX 3.0 und dem AUTOSAR-System-Template betrachtet. Im Weiteren wird näher auf die Unterschiede zwischen FIBEX und AUTOSAR eingegangen.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45094481 / Bus-Systeme)