AUTOSAR Basic Software for CAN-MOST Gateways
Networking in modern vehicles is based on several different bus systems. CAN, LIN and FlexRay are used in the body and power train areas. Multimedia and infotainment ECUs are networked primarily over the MOST bus. The exchange of information between networks is the task of gateway ECUs. They exist in various forms – ranging from relatively simple gateways that only exchange minimal information between buses of the same kind to central gateways that interface to several buses of different types.
AUTOSAR offers ECU developers a solid software basis for interfacing their ECUs to CAN, LIN, FlexRay and Ethernet buses. Gateway tasks are handled by various software modules of the AUTOSAR architecture (Figure 1), depending on the specific functionality that is required.
Figure 1: Rough architecture of an AUTOSAR ECU
Routing Mechanisms in AUTOSAR
Per AUTOSAR specification, three mechanisms are available for routing data, each of which covers different use cases:
- PDU routing
- Signal routing
- Transport protocol routing, e.g. for diagnostic data
The PDU gateway is part of the PDU router (PDUR), and it routes entire data packets, the Protocol Data Units (PDUs), from one network to another. This type of routing assumes that the PDUs are defined in the same way on both the source and target networks, which means that the length and content of the PDUs must match. However, it should be noted that PDU routing is spontaneous routing: A PDU is routed as soon as it is received. Therefore, it is not possible to change the cycle time or send type. However, in some cases such conversions are necessary. Then routing must be performed over a signal gateway.
Signal routing is used when only certain signals of a PDU are transmitted to another network, because only these signals are needed on the target bus. Another reason may be the different layouts of the source and target PDUs, in which the signal might be located at different positions within the PDU. In signal routing, the received PDUs are first disassembled into the individual signals, so that they can then be transferred to one or more target PDUs. Besides handling any changes in the PDU layout, the send type and cycle time may also be changed.
Routing of transport protocol data is another task of the PDUR. This routing mechanism might be used to transmit diagnostic data from an ECU on one network to another, for example. In this case, the data is received and sent by the transport protocol (TP). Here, routing is performed above Layer 4 of the ISO/OSI Reference Model, and allows conversion to different addressing methods and bus systems.
Properties of the MOST Bus
An ECU's software is interfaced to MOST over the so-called Network Services. Network Services is a protocol stack standardized by the MOST specification.
On the MOST bus, data is transmitted over the synchronous and asynchronous channels, as well as the control channel. The synchronous channel is used to transmit video and audio data. Larger packet data whose transmission is not periodic, e.g. Ethernet tunneling or navigation data, is transmitted over the asynchronous channel. The control channel, whose bandwidth is vastly reduced, compared to the two other channels generally transports commands and status data.
The choice of the mechanism used to convert data from other networks to MOST depends on the data itself. Functional data (sensor data, states, etc.) is usually just a few bytes long; on the MOST bus, it is generally sent on the control channel. In the case of diagnostic data, which is also transmitted in larger blocks on CAN, it is advisable to send it on MOST using the MOST High Protocol (MHP). The MHP operates on the asynchronous channel, which has greater bandwidth than the control channel, which enables faster provision of the data packets to a specific receiver.
CAN-MOST Gateway as Hybrid Solution
A CAN-MOST gateway can be realized as a hybrid solution. In this context, a hybrid solution is a gateway architecture that uses a dedicated communication stack for each bus and implements the actual gateway by additional software layers. In this case, the specific gateway code must be contained in the application (Figure 2). Often, existing gateway software modules cannot be used in this approach, since interfacing to the other communication stacks is not supported.
Figure 2: The CAN-MOST gateway can be implemented as a hybrid solution.
To interface the different communications stacks, hybrid solutions frequently also require wrapper software, which leads to greater propagation time. Another disadvantage is the different configuration tools that need to be used for the communication stacks. Usually, the stacks can only be configured separately, so routing rules cannot be considered. This results in additional work effort whenever the communication descriptions are changed.
CAN-MOST Gateway by Complex Device Driver
The Complex Device Driver (CDD) described in AUTOSAR represents a software module that allows direct access to the Basic Software Modules (BSW) and the microcontroller hardware. It also makes it possible to integrate microcontroller interfaces that are not defined in AUTOSAR. Implementation of a CAN-MOST gateway as a CDD (Figure 3), simplifies interfacing between the gateway and the drivers for CAN and MOST. As in the hybrid solution, any changes to routing rules must be handled afterwards at great effort. Another disadvantage of these two approaches is the redundant implementation of gateway functionality in the ECU and the additional memory required for this. Essentially, the CDD approach is comparable to the hybrid solution.
CAN-MOST Gateway with AUTOSAR Architecture
In its software architecture, AUTOSAR has solved the described problems in creating multibus gateways. So, it is natural to want to use this approach to develop a CAN-MOST gateway in the same way as a CAN-LIN or CAN-FlexRay gateway. To accomplish this, it is necessary to extend the AUTOSAR stack by adding a MOST bus interface.
According to the AUTOSAR specification, the higher communication layers are interfaced via two BSW modules. The first is the hardware-specific driver, which controls accesses to the specific communication controller, and the second is an interface module, whose task it is to route the data of the underlying driver, independent of hardware, up to the higher layers. For example, in the CAN bus, these are the two BSW modules CAN Driver (CANDRV) and CAN Interface (CANIF). A similar driver and interface architecture is also used on the LIN bus and FlexRay bus. Above the interface layer, the bus systems are abstracted to the extent that the PDUR and COM modules can implement gateway functionalities hardware-independently.
Vector has chosen this architecture implementation as the best approach. Interfacing the AUTOSAR stack to the MOST bus requires a MOST Interface (MOSTIF) and a MOST Driver. Instead of implementing a MOST driver, existing MOST Network Services were accessed, similar to the way AUTOSAR 4.x provides for the Ethernet interface. No MOSTTP module was used, since this functionality is already included in MOST Network Services. In the context of a project, Vector developed the MOSTIF module, which is part of the MICROSAR-MOST package. The MOSTIF module is placed over the MOST Network Services (Figure 4). The PDUR from Vector was extended to interface to the MOSTIF in addition to interfaces for CAN, LIN and FlexRay. The COM module – responsible for signal routing – was adopted without changes.
Figure 4: By implementing the MOST connection with AUTOSAR functions, the PDUR and COM modules handle routing exactly as defined in AUTOSAR.
The architecture presented here allows the application to access MOST Network Services, so that existing MOST software modules can continue to be used. The Vector AUTOSAR stack has long supported the CAN, LIN and FlexRay bus systems and more recently Ethernet as well. The gateway mechanisms available for this are re-used for the MOST bus. It is very easy, for example, to implement sending of data by the MOST notification mechanism in the AUTOSAR environment via the trigger-transmit interfaces. TP data received through the CAN bus can be sent on MOST over the MHP or over the control channel. The specific mechanism is selected at the time of configuration. Dynamic management of the TP buffers is handled by the PDUR.
The AUTOSAR BSW is configured with tool support, and the configuration data – e.g. the communication description of the ECU – is saved in an ECU-specific ECU Configuration (ECUC) description file. In the case of a gateway, the routing relationships are also included in this file. Additional MOST-specific attributes are saved in extensions to the ECUC file. Describing the gateway configuration in a single file prevents errors to be introduced by any format conversions or even manual merging of parameters.
Advantages of Implementation by AUTOSAR Architecture
The AUTOSAR architecture makes is possible to develop universal gateways to interconnect CAN, LIN, FlexRay, Ethernet and MOST buses. When a MOST interface is integrated in the AUTOSAR architecture, wrapper layers are unnecessary, and this results in better propagation time and lower memory usage. The presented architecture also has a central routing unit (PDUR and COM), which does not require any additional routing code in the application. This central routing unit enables consistent configuration of all routing relationships with one tool, and the configuration data is saved within a single description file.
Testing of CAN-MOST Gateways
Vector's multibus tool CANoe is well-suited for testing, simulation, diagnostics and analysis of CAN-MOST gateways (Figure 5). It includes the Test Feature Set for easy and automated execution of tests: Besides using predefined test cases, test engineers may also program their own test sequences and have them run as part of an automated test. Hardware interfaces available for CAN and MOST make it convenient to test CAN-MOST gateways. It is also possible to generate certain bus errors in tests, in order to check the behavior when errors occur.
Figure 5: CANoe.MOST is well-suited for testing, simulation, diagnostics and analysis of CAN-MOST gateways.
The focal point of the implementation of a CAN-MOST gateway with an AUTOSAR architecture as described here, lies in routing messages of uniform length, as it is on the CAN bus. One can think of implementation of further extensions of the MOST stack in the future to add additional functionalities. This includes routing data of variable size – e.g. a list with different numbers of telephone book entries. Similarly, MOST network management tasks could be handled by AUTOSAR modules.
With the Ethernet interfacing available in AUTOSAR, it will be possible to develop very powerful gateways with a MOST connection and thereby utilize the advantages of the AUTOSAR architecture.
About the Author: Patrick Markl is Senior Software Development Engineer responsible for concept development in the Embedded Software product line at Vector Informatik GmbH, Stuttgart, Germany. He can be contacted via firstname.lastname@example.org.
All figures: Vector Informatik GmbH
 Grzemba, A.: MOST - Das Multimedia Bussystem für den Einsatz im Automobil (“MOST - The Multimedia Bus System for Use in the Automobile”)
- No news
- Jaguar docks on to Intel for next-gen infotainment systems
- Interface integrates e-vehicles into smart grid
- Kvaser proposes backward-compatible, high-bandwidth CAN version
- Women demand different connectivity functions in the car
- Smart cars offer "once in a generation chance" to UK industry, experts say
- Get your digital copy of EETimes Europe
- EV market is much more than passenger cars - and it's booming
- Emergency Steer Assistant can avoid collisions
- MOST 150 Star topology interconnects driver assistant systems
- Faurecia, Magneti Marelli jointly integrate tablets and smartphones into cars
- Field test fathoms out economic potential for electric mobility
- Researchers significantly improve lithium-air batteries
- Volvo starts large test with robot cars on public roads
- Automotive drives new processor architectures
- Haptic feedback touchpad contributes to driving safety