AUTOSAR Integration for the MOST Network
Therefore, it is increasingly important that the infotainment domain of a vehicle is able to support AUTOSAR, at least where an interaction with other domains of its electric/electronics systems is necessary. The goal of this project was to investigate how to integrate MOST into AUTOSAR in such a way that AUTOSAR systems and conventional MOST systems work together in a vehicle network seamlessly and that the AUTOSAR methodology and architecture are followed as much as possible. This paper describes the results of the concept work investigating the integration of support for the MOST network (see [2]) into the AUTOSAR standard (see [3]) for the MOST Cooperation. Details are available in the project report [1].
Two scenarios for the integration with AUTOSAR were prioritized, together with the Working Group Device Architecture of the MOST Cooperation, as the basis of the subsequent concept development:
- One scenario is to provide a gateway between vehicle networks running AUTOSAR and a MOST network. The use case for this scenario is to transmit messages between AUTOSAR devices on a network using AUTOSAR and native MOST devices in a MOST network connected via an AUTOSAR/MOST gateway; for example, in order to access the current speed of the vehicle from an ECU in the MOST network.
- In the second scenario the communication of two AUTOSAR applications according to the AUTOSAR standard is tunneled through a MOST network. This scenario is mainly intended to (re-)use AUTOSAR modules in a MOST network, for example a stack for diagnostic protocols.
AUTOSAR Architecture
This section will briefly describe the necessary extensions to the AUTOSAR architecture for these two main scenarios. One major challenge was to bring together the dynamic configuration and communication mechanism of a MOST network and the static configuration-oriented characteristics of the AUTOSAR stack. For example: in AUTOSAR, many network settings may be defined pre-compile time and are hard-coded into the code using code generation.
(C) ETAS
According to the concept of ETAS, the following components will have to be introduced in the AUTOSAR Basic Software (BSW) for the integration of support for the MOST network (see figure 1):
- MOST Driver: the MOST Driver module is part of the lowest layer of AUTOSAR (called Micro Controller Abstraction Layer – MCAL) and performs the hardware access, offering a hardware independent API to the upper layers. Basically, in this case, it is a wrapper for the MOST NetServices (see [4]).
- MOST Interface (MostIf): in the layered architecture of the AUTOSAR Communication Stack (ComStack), the MOST Interface module is located between the low level MOST Driver and the upper communication service layers (see below). It provides all the necessary interfaces to manage the MOST network interface.
- MOST Transport Layer (MostTp): for sending and receiving MOST messages, the MostTp Module will implement the MOST Application Message Service (AMS) functionality of the NetServices for the segmentation and de-segmentation of control messages. For the configured FBlocks (e.g., an FBlock AUTOSAR) the MostTp will provide the mapping between the MOST AMS messages and the respective bus independent Packet Data Units (PDUs) that are exchanged through the AUTOSAR PDU Router (PduR). (See next section.)
- MOST Network Management (MostNm): the purpose of the MOST Network Management module is to keep track of the network and configuration status on MOST. It also implements the MOST NetBlock in AUTOSAR ECUs. Additionally, the MostNm will implement a small AUTOSAR/MOST network management in order to be able to determine the address and instance identifier of a communication partner, dynamically.
- MOST State Manager (MostSM): the AUTOSAR BSW stack specifies for each communication bus a bus specific state manager, which handles the availability of the bus.
MOST/AUTOSAR Gateway
In this use-case, an infotainment gateway links AUTOSAR systems communicating over vehicle network systems using AUTOSAR mechanisms – called AUTOSAR network for short in the remainder of this paper – with a MOST network. Routing messages from an AUTOSAR network can be achieved on two layers of the AUTOSAR ComStack: by the PduR or by the Communication Manager (COM). When routing PDUs via the PduR, PDUs received from an AUTOSAR network will be transmitted completely as an AMS message on MOST and vice versa. For example, in the case of CAN, this means that CAN frames are transmitted as single AMS messages.
Figure 2: MOST/AUTOSAR Gateway – Signal Routing © ETAS
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 (see 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.
Tunneling of AUTOSAR Communication
The second scenario is that the communication of two AUTOSAR applications according to the AUTOSAR standard is tunneled through a MOST network. Here again there are two sub cases. First, the tunneling can be done through the MOST Control Channel. Additionally, there is the possibility of tunneling AUTOSAR communication over the MOST Ethernet Channel if it is supported by the respective devices.
Figure 3: Tunneling of AUTOSAR Communication over the MOST Control Channel © ETAS
Tunneling 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 (see figure 3). For the tunneling 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 tunneling). 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 – mainly for the handling of streaming channels for audio and video – 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).
Conclusion
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.
References
[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 (www.mostcooperation.com).
[3] AUTOSAR: Release 4.2 Overview and Revision History,
URL: https://www.autosar.org/fileadmin/files/releases/4-2/AUTOSAR_TR_ 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.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
