FIBEX XML format and AUTOSAR development

FIBEX

The FIBEX standard (see Figure 1, FIBEX Version 3.0) describes a multi-protocol-capable format for the exchange of data in message-oriented communications systems, e.g. in-vehicle networks. The FIBEX format can be used to export on-board network databases, and for import into different types of tool during development of vehicle networks. At present, it supports the network protocols FlexRay, CAN, MOST and LIN. From the design of complete clusters to their definition on bit level, all information relevant to the description of vehicle networks can be defined using the FIBEX format.

Figure 1: FIBEX Version 3.0. For higher resolution, click here

FIBEX is a freely available, cross-company standard that is defined " and can thus be verified " through XML schema files. Files that do not conform to the XML schemes are therefore easy to detect. Because of the standards defined by the ASAM (Association for Standardisation of Automation and Measuring Systems) it is assured right from the start that conversion and data exchange between different tools will be made uniform, and thus greatly simplified in comparison with the incompatibilities prevailed in the past.

A FIBEX file (FIBEX Version 3.0.0) is divided into several areas. Topology contains information on the respective clusters and electronic control units (ECUs), and on how the ECUs are interconnected via channels. All global FlexRay parameters are stored in the cluster. Further, a Gateway element can be used to determine the routing behaviour between different bus systems. This provides the capability to define the mapping behaviour of frames, PDUs and signals. The communications objects, such as frames and PDUs, and their timing behaviour are defined in the Communication area. In FIBEX, a PDU is stored as an Interaction Layer Protocol Data Unit. Signals are grouped together in the PDU. From the point of view of the protocol, a frame under FIBEX is a Data Link Layer Protocol Data Unit. One or more PDUs with additional information, such as the update bit, are specified in a frame. The timing behaviour of the communications objects is described in the timing parameters for Absolutely-Scheduled Timing, Event-Controlled Timing, Cyclic Timing and Request-Controlled Timing. FlexRay uses Absolutely-Scheduled Timing, among others, to describe the slot and cycle in which a given communications object is transmitted. Further areas are Function and Signal.

Under Harmonized Data Objects, physical units and the coding of the signals are stored. For a signal or group of signals, the coding defines the type of transfer, for instance the bit length, the offset and the scaling factor. This specifies the way in which raw data are to be converted to physical, i.e., displayable values. Requirements for PDUs, functions, signal groups and other requirements can be described in the Requirement area. Network-management and transport-layer information can be defined under Higher Protocols.

AUTOSAR

The idea behind AUTOSAR is "Cooperation on standards " competition in implementation." The ideas taken into account in the implementation of AUTOSAR were: standardisation of system functions, scalability, relocatability of functions, integration and exchangeability of software from different manufacturers, maintainability over the entire product life-cycle.

Figure 2: AUTOSAR Software architecture. For higher resolution, click here