Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Networks

Grasp AUTOSAR integration for MOST network

Posted: 12 Jun 2015 ?? ?Print Version ?Bookmark and Share

Keywords:AUTOSAR? MOST? network? Ethernet? ECUs?

The routing on the PDU level has a number of limitations with regards to communication using regular MOST AMS messages. An infotainment gateway will usually require signal routing, where signals of the AUTOSAR network are flexibly assigned to the parameters of a MOST message. This can be achieved by using the AUTOSAR COM module (figure 2). The AUTOSAR COM can be configured to transmit a received signal into another signal. Through this mechanism, signals received in a PDU from an AUTOSAR network can be mapped to a parameter of a MOST message (handled as signals in the AUTOSAR COM). It can also be defined how these signals are combined into a PDU. Thus, it is also possible to map different signals, even from different PDUs, into one MOST AMS message (represented as a PDU in the AUTOSAR COM). By setting the transfer property of a signal to "triggered on change without repetition", the COM can be configured to send a message on MOST only when the data of a signal transmitted cyclically on an AUTOSAR network has changed. Similarly, if an AUTOSAR message is configured to be sent cyclically and a MOST AMS message is received that is configured to be transmitted via this AUTOSAR message, the new value as described in the MOST AMS message will be transmitted cyclically.

Figure 2: MOST/AUTOSAR GatewaySignal Routing.

Tunnelling of AUTOSAR communication
The second scenario is that the communication of two AUTOSAR applications according to the AUTOSAR standard is tunnelled through a MOST network. Here again there are two sub cases. First, the tunnelling can be done through the MOST Control Channel. Additionally, there is the possibility of tunnelling AUTOSAR communication over the MOST Ethernet Channel if it is supported by the respective devices.

Figure 3: Tunnelling of AUTOSAR Communication over the MOST Control Channel.

Tunnelling via the MOST Ethernet Channel is very similar as using Ethernet in the AUTOSAR Standard and will not be discussed here (for details see [1]). In both cases, there are two different aspects to be considered. On a gateway device, AUTOSAR messages have to be routed; on a device with an AUTOSAR application, messages have to be sent or received (figure 3). For the tunnelling of AUTOSAR messages on the MOST Control Channel, a specific method "PDU" in the FBlock "AUTOSAR" is defined. To avoid having to do a mapping to FktIDs manually, the PduId is in this case included as a parameter in the MOST AMS message. This method has the identifier of the PDU (PduId) and the data of the PDU as two parameters. Usually, the data of the PDU is further structured into different signals through the AUTOSAR mechanisms. The MostTp is responsible for the conversion of MOST AMS messages into AUTOSAR PDUs and vice versa.

Full integration of MOST in AUTOSAR
In the previous sections, only a partial support for the MOST network was defined according to use case (gateway or tunnelling). In this section, the full integration of a MOST network and its features into the AUTOSAR standard is discussed briefly. This would enable an AUTOSAR device with a MOST interface to communicate with MOST slave devices directly. Because this scenario has not been considered to be of highest priority, the concepts were not discussed in detail in the project that is the basis of this paper.

First, support for further mechanisms of the MOST standard that were not required for the previous scenarios need to be defined. These include the MOST network management, the method and notification handling, and more complex function classes, such as arrays or records. Usually, these mechanisms require more far-reaching extensions to the AUTOSAR standard. Some mechanisms that have been added recently for the support of Ethernet could be reused. More important, in the current version of the AUTOSAR standard, there is no specific support for the infotainment domain. Therefore, some aspects C mainly for the handling of streaming channels for audio and video C are missing that are not specific to MOST but would be of general use for supporting AUTOSAR-based infotainment systems. Support for these services could be added as another stack in the AUTOSAR Basic Software, for example called "Media Streaming Services", handling the connection management in a similar way to the MOST Connection Manager, the management of codecs for audio and video, and the hardware access to streaming related hardware (e.g., a DSP).

This paper described the mechanisms and software modules that have to be added to the AUTOSAR standard to support the MOST network for two defined scenarios while trying to find a solution best fitting to the AUTOSAR methodology. Both scenarios provide for a partial integration of a MOST network into the AUTOSAR standard. In the solution introduced by ETAS, existing SWCs of the AUTOSAR stack as well as the configuration mechanisms provided by AUTOSAR and the corresponding tools may be reused as far as possible. With some extensions, for example for handling the dynamic MOST network management, the integration of MOST mechanisms into the AUTOSAR standard can be done in a quite straight-forward manner. Only an overview of what would have to be done for a full support of a MOST network with all of its features in the AUTOSAR standard has been given. This integration also seems feasible for slave ECUs of an infotainment system and the gateway CPU of an infotainment HU. However, for the head-unit of an infotainment system, a more dynamic OS would currently be a better choice.

[1] AUTOSAR Integration for MOST, Project Report, Status: Final, Version: 1.0, Date: 2014-10-06.
[2] MOST Cooperation: MOST Specification, Version: 3V0E2, Date: 07/2010, Specification of MOST Cooperation (
[3] AUTOSAR: Release 4.2 Overview and Revision History, URL: ReleaseOverviewAndRevHistory.pdf, Version: 4.2.1, Date: 2014-10-31, Specification.
[4] Microchip: MOST NetServices V3.2.x Documentation, Version: V3.2.2.0 (Beta.1), Date: 2014-02-11, Documentation.

About the authors
Alexander Leonhardi is the manager of ETAS Embedded Software and Safety Consulting in Germany and is responsible for the area of Systems Engineering.

Nijumohan Rathnalayam is an embedded software specialist of ETAS Embedded Software and Safety Consulting and is an expert on the AUTOSAR communication stack.

?First Page?Previous Page 1???2

Article Comments - Grasp AUTOSAR integration for MOST n...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top