In AUTOSAR, applications consist of AUTOSAR software components (SW-C). Applications are divided into SW-Cs that communicate with each other. See also Figure 2 AUTOSAR Software architecture. The communication is mapped at a very abstract level under AUTOSAR. This is summarised by the term "Virtual Function Bus" (VFB).
The SW-Cs communicate via so-called ports, with no knowledge of the signal path. In a later stage of development, the SW-Cs are then distributed to control units (ECUs). The AUTOSAR Runtime Environment (RTE) implements the VFB on the respective ECU. The RTE provides a bus-system-independent interface, and passes on the commands to the "basic software" of this ECU. The basic software then accesses the hardware directly.
AUTOSAR defines a series of steps to create an executable ECU component (see Figure 3 Software creation). XML is relied upon as the interchange format. These XML files are based on a schema file derived from the AUTOSAR UML model. The schema file can be roughly divided into four parts: Software Component Template for definition of individual software components; Basis Software Module Description Template for description of all information about a Basis Software Component; and ECU Configuration Template for definition of architecture and interfaces of an ECU. The System Template serves to define the overall system. The System Template stores, among other things, information about the bus systems, the signals, the mapping and the topology. This template has a lot in common with the FIBEX standard. As of FIBEX 3.0, even the PDU concept has been taken over from AUTOSAR, in order to achieve further harmonisation between the two standards.
Figure 3: Software creation.
From FIBEX to AUTOSAR
On the basis of the years of experience with FIBEX at Eberspaecher Electronics, feasibility studies have been carried out to investigate the migration of the FIBEX tool chain to AUTOSAR. The starting point for these feasibility studies was a converter from FIBEX to AUTOSAR. For this FIBEXtoAUTOSAR converter, the first considerations centred on the differences between FIBEX 3.0 and the AUTOSAR System Template. The differences between FIBEX and AUTOSAR will be dealt with in more detail below.
There is a significant difference in the structure of the schema files. In AUTOSAR, all information for all bus systems is stored in one schema file. This file, named autosar.xsd, includes information on the structure of a FlexRay, CAN or LIN cluster. In FIBEX there are several schema files. There is a central schema file named fibex.xsd. If different bus systems are described with one FIBEX file, schema file fibex4multiplatform.xsd must be used. In this file, besides the central schema file, additional schema files for CAN, LIN, FlexRay, Byteflight, TTCAN and MOST are integrated via import instructions.
A further difference is to be found in the representation of signals. In contrast to FIBEX, with one standard signal, AUTOSAR distinguishes between an I-Signal and a System Signal. A System Signal has a great similarity to a FIBEX signal. A System Signal includes information about the signal length and the coding of the signal. In an I-Signal, reference is then made to a System Signal. Similarly to FIBEX, in which signals are grouped into PDUs, the I-Signals in AUTOSAR are grouped into Signal-I-PDUs.
In addition to the differences in the signals, there is also a different XML structure. In FIBEX, the root area of the XML structure for the elements is fixed. Starting with ELEMENTS, elements for CLUSTER, CHANNELS, ECUS, etc. can be entered in a specific sequence. In AUTOSAR, the structure starts with the root element TOP-LEVEL-PACKAGES. Under this element, any number of AR-PACKAGE elements can be entered. An AR-PACKAGE consists of an ELEMENTS or a SUB-PACKAGES element. As in FIBEX, elements for clusters, ECUs, etc. can be entered under ELEMENTS. Under SUB-PACKAGES, any number of AR-PACKAGE elements can be entered. In AUTOSAR, one AR-PACKAGE is usually created for each element type.
Figure 4: Fibex (top) and Autosar XML