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?

Automotive Open System Architecture (AUTOSAR) is currently becoming more and more established in the traditional vehicle electronics domains. After the major German vehicle manufacturers (OEMs) introduced AUTOSAR in central areas of their E/E-architectures, they are now extending its use into further domains. With the AUTOSAR 4.x standard, most other OEMs are also investigating or working on a migration to AUTOSAR and the first use cases outside of the automotive domain are under development.

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 [2] into the AUTOSAR standard [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:

1. 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.

2. In the second scenario the communication of two AUTOSAR applications according to the AUTOSAR standard is tunnelled 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.

Figure 1: AUTOSAR Basic Software Architecture for MOST.

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 (figure 1):
???MOST Driver: the MOST Driver module is part of the lowest layer of AUTOSAR (called Micro Controller Abstraction Layer C 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.

In this use-case, an infotainment gateway links AUTOSAR systems communicating over vehicle network systems using AUTOSAR mechanisms C called AUTOSAR network for short in the remainder of this paper C 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.

1???2?Next Page?Last Page

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