Autosar TR Integrationintommthmiecu

Demonstration of Integration of AUTOSAR into a
MM/T/HMI ECU
V1.0.0
Document Title
Demonstration of Integration of
AUTOSAR into a MM/T/HMI
ECU
Document Owner
Document Responsibility
Document Identification No
Document Classification
AUTOSAR
AUTOSAR
422
Informal
Document Version
Document Status
1.0.0
Final
Document Change History

Date
23.11.2010
1 of 37
Version Changed by
1.0.0 AUTOSAR
Administration
Change Description
Initial Release
Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU
- AUTOSAR confidential -

MM/T/HMI ECU
V1.0.0
Disclaimer
This Informal Document and the material contained in it is for the purpose of
information only. It is not a specification document released by AUTOSAR.
AUTOSAR and the companies that have contributed to it shall not be liable for any
use of the Informal Document.
The material contained in this Informal Document is protected by copyright and other
types of Intellectual Property Rights. The commercial exploitation of the material
contained in this Informal Document is not licensed.. Should parts of its contents later
become part of the AUTOSAR Standard, such parts will then be licensed under the
rules applicable to the AUTOSAR Standard. For any intended commercial use (a)
before this point in time or (b) of parts not integrated in the AUTOSAR standard, the
interested user needs to solicit licenses individually from the respective rights holder.
This Informal Document may be utilized or reproduced without any modification, in
any form or by any means, for informational purposes only. For any other purpose,
no part of the Informal Document may be utilized or reproduced, in any form or by
any means, without permission in writing from the publisher.
Like the AUTOSAR specifications, this Informal Document has been developed for
automotive applications only. They have neither been developed, nor tested for nonautomotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.
Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference
models, "use cases", and/or references to exemplary technical solutions, devices,
processes or software).
Any such exemplary items are contained in the specifications for illustration purposes
only, and they themselves are not part of the AUTOSAR Standard. Neither their
presence in such specifications, nor any later documentation of AUTOSAR
conformance of products actually implementing such exemplary items, imply that
intellectual property rights covering such exemplary items are licensed under the
same rules as applicable to the AUTOSAR Standard.
.
2 of 37

MM/T/HMI ECU
V1.0.0
Table of Contents
1
Introduction and functional overview ................................................................... 5

1.1
1.2
1.3
Document Scope.......................................................................................... 5
Motivation..................................................................................................... 5
MM/T/HMI ECU Definition ............................................................................ 6
Acronyms and abbreviations ............................................................................... 7
Related documentation........................................................................................ 8
3.1
Input documents........................................................................................... 8
Integration Approaches ....................................................................................... 9

4.1
Integrating SWCs ......................................................................................... 9
4.1.1
Emulating the RTE ................................................................................ 9
4.1.1.1
SWC & BSWM Scheduling .......................................................... 10
4.1.2
Integrating the RTE ............................................................................. 10
4.1.2.1
Inter Process Communication ...................................................... 11
4.1.2.1.1 AUTOSAR SocketAdaptor ........................................................ 12
4.1.2.1.2 Mapping to Inter-Partition Communication................................ 13
4.1.2.1.3 Mapping to Intra ECU Communication ..................................... 14
4.1.2.2
Inter ECU Communication ........................................................... 15
4.1.2.2.1 AUTOSAR Supported Medium ................................................. 16
4.1.2.2.2 AUTOSAR Unsupported Medium ............................................. 16
4.1.2.3
Inter ECU via Inter Process Communication................................ 17
4.1.3
Emulating BSWMs .............................................................................. 18
4.2
Integrating BSWMs .................................................................................... 19
4.2.1
Only Emulating the BSWMs Neighborhood........................................ 19
4.2.2
Emulating the MCAL ........................................................................... 20
4.2.3
Emulator Development and Configuration Process............................. 21
Example: Integrating AUTOSAR Diagnostics.................................................... 22

5.1
Targeted MM/T/HMI ECU........................................................................... 22
5.2
Process Deployment .................................................................................. 23
5.3
AUTOSAR Modules Integration.................................................................. 24
5.3.1
DCM Integration .................................................................................. 25
5.3.1.1
DCM Configuration ...................................................................... 25
5.3.1.2
ECU State Manager Emulation .................................................... 25
5.3.1.3
ComManager Emulation .............................................................. 26
5.3.1.4
PDU Router Emulation................................................................. 27
5.3.1.5
I/O Hardware Abstraction Emulation ............................................ 29
5.3.1.6
Basic Software Mode Manager Emulation ................................... 30
5.3.1.7
NvRAM Manager Emulation......................................................... 31
5.3.1.8
RTE Emulation............................................................................. 32
5.3.1.8.1 DCM Scheduling....................................................................... 32
5.3.1.8.2 Diagnostic Request Forwarding................................................ 33
5.3.2
DEM Integration .................................................................................. 33
5.3.2.1
DEM Configuration....................................................................... 34
5.3.2.2
ECU State Manager Emulation .................................................... 34
3 of 37

MM/T/HMI ECU
V1.0.0
5.3.2.3
5.3.2.4
4 of 37
NvRAM Manager Emulation......................................................... 35

RTE Emulation............................................................................. 36

MM/T/HMI ECU
V1.0.0
1 Introduction and functional overview

In most larger ECUs developed for the domain of multimedia, telematics and human
machine interface (MM/T/HMI) applications the AUTOSAR architecture is not being
used. Still in some cases it is desirable to reuse functionality implemented for the
AUTOSAR architecture in MM/T/HMI ECUs (see section 1.2). This means that
AUTOSAR Basic Software Modules (BSWMs) and AUTOSAR Software Components
(SWCs) have to be integrated with the operating system (OS) and infrastructure
services a MM/T/HMI ECU provides.
Some of the discussed approaches are illustrated on the concrete example of
integrating AUTOSARs diagnostic functionalities. In the example an approach for
integrating the DCM and the DEM is descibed.
1.1 Document Scope

The scope of this document is to demonstrate how the integration of AUTOSAR
SWCs and BSWMs in a MM/T/HMI ECU can be realized for one concrete example.
This document does not specify an AUTOSAR MM/T/HMI architecture. It also does
not specify a process which is part of the methodology. The document is only a
demonstration of what can be done with AUTOSAR SWCs and BSWMs in MM/T/HMI
ECUs.
Chapter 4 only gives an overview of different flavors of integration and outlines some
aspects and limitations of these approaches. It is not guaranteed that these
approaches can be applied to any combination of SWCs and BSWMs.
1.2 Motivation
Todays architecture specified by AUTOSAR is not intended to support the needs of
large MM/T/HMI ECUs. It provides drivers for automotive specific technologies and
services needed by automotive applications. Services needed by MM/T/HMI
applications are not part of the AUTOSAR architecture.
MM/T/HMI applications are therefore often build on general-purpose operating
systems like WinCE, Linux or QNX. These operating systems already provide various
drivers and services needed for building multimedia applications. The drawback of
using general-purpose operating systems is that they lack automotive specific
services. For building a MM/T/HMI ECU both, MM/T/HMI services and automotive
services, are needed. Therefore, the missing automotive services have to be
implemented for the general-purpose operating system in question. At this point, it
would be desirable if existing AUTOSAR implementations of the automotive services
could be used. An obvious advantage would be that no time has to be spent on
implementing the services. Another advantage is that these implementations are
already used in various other ECUs and therefore have been tested extensively.
Using implementations of AUTOSAR communication services in MM/T/HMI ECUs
would also decrease the effort required for integrating the ECUs with the rest of the
5 of 37

MM/T/HMI ECU
V1.0.0
system. A good example for such a communication service would be the DCM, which
is the module responsible for the diagnostic communication. Using the existing DCM
in a MM/T/HMI ECU instead of re-implementing the specified protocol assures that
the ECU will react in exactly the same way to a diagnostic request as the other ECUs
in the system.
1.3 MM/T/HMI ECU Definition

The set of provided OS services and infrastructure services running on the
MM/T/HMI ECU form are referred to as the MM/T/HMIs basic software. When the
term MM/T/HMI ECU is used in this document, it rather referres to the basic software
running on an ECU than to the MM/T/HMI ECUs hardware.
The MM/T/HMI basic software usually consists of the services provided by a generalpurpose operating system with real-time capabilities like WinCE or QNX and a set of
drivers and infrastructure services. The following features are assumed to be
provided by the OS:
Support for Multi-Threading for executing more than one task at a time
A priority based scheduling algorithm (including priority-ceiling) for scheduling
threads
A high-resolution timer for fine-grained periodic scheduling
A memory protection mechanism which allows for threads to run in a protected
area (processes)
The general-purpose OSs used also support dynamic creation and configuration of
resources during runtime, virtual memory and other concepts not implemented by the
AUTOSAR architecture.
AUTOSAR modules are designed to run within the AUTOSAR architecture. They
assume the presence of certain services provided by AUTOSAR BSWMs. A
MM/T/HMI ECU might not provide these required services or they are provided via a
non-AUTOSAR interface by the installed drivers and service modules.
6 of 37

MM/T/HMI ECU
V1.0.0
2 Acronyms and abbreviations

Abbreviation /
Acronym:
Description:
BSD
BSWM
CRC
CE
DCM
DEM
ECU
IPC
I-PDU
IOC
MM/T/HMI
MCAL
NvRAM
OS
PDU
RTE
SWC
Berkly Software Distribution

Basic Software Module
Cyclic Redundancy Check
Consumer Electronics
Diagnostic Communication Manager
Diagnostic Event Manager
Electronic Control Unit
Inter Process Communication
Interaction Layer Protocol Data Unit
Inter OS-Application Communication
Multimedia / Telematics / Human Machine Interface
Micro Controller Abstraction Layer
Non-Volatile Random Access Memory
Operating System
Protocol Data Unit
Runtime Environment
Software Component
7 of 37

MM/T/HMI ECU
V1.0.0
3 Related documentation
3.1 Input documents
[1] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] Specification of PDU Router
AUTOSAR_SWS_PDURouter.pdf
[3] Specification of Operating System
AUTOSAR_SWS_OS.pdf
[4] Specification of Diagnostic Communication Manager
AUTOSAR_SWS_DiagnosticCommunicationManager.pdf
[5] Specification of Diagnostic Event Manager
AUTOSAR_SWS_DiagnosticEventManager.pdf
[6] Specification of RTE
AUTOSAR_SWS_RTE.pdf
[7] Specification of Communication Manager
AUTOSAR_SWS_COMManager.pdf
[8] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager.pdf
[9] Specification of NvRAM Manager
AUTOSAR_SWS_NVRAMManager.pdf
[10] Specification of Socket Adaptor
AUTOSAR_SWS_SocketAdaptor.pdf
[11] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
8 of 37

MM/T/HMI ECU
V1.0.0
4 Integration Approaches
Integrating a BSWM or SWC into a MM/T/HMI ECU means that the implementation
(e.g. C code) of a complete BSWM or SWC is run on that MM/T/HMI ECU. SWCs
and BSWMs are designed to run within the AUTOSAR architecture. They expect that
other BSWMs, which they depend on, are present and their functions accessible. In
order to integrate a BSWM or SWC into a MM/T/HMI ECU, the ECUs basic software
has to make the BSWMs and SWCs believe that they are running in an AUTOSAR
architecture. Missing but required functions have to be emulated by BSWM
emulators. To emulate a BSWM means implementing a software module for the
MM/T/HMI ECU, providing a complete or just a subset of the BSWMs interfaces.
BSWM emulators provide the missing functions required by the integrated SWCs and
BSWMs. Functions not required by any of the integrated SWCs and BSWMs can be
omitted. The required functions are provided in exactly the way specified in the
according AUTOSAR specifications but are realized with the means provided by the
underlying general-purpose operating system (WinCE/Linux/QNX). Emulators are the
bridge between the AUTOSAR architecture and the services provided by the
MM/T/HMI ECUs basic software.
The following sections discuss different emulation strategies for integrating SWCs
and BSWMs.
4.1 Integrating SWCs

SWCs depend on the presence of the RTE. The RTE is the only module they directly
depend on. They use the RTEs interface for communicating with other SWCs and
BSWMs. The RTE also is responsible for scheduling the SWCs. These expect the
RTE to trigger their Runnables. The integration of SWCs therefore requires that a
RTE is present on the MM/T/HMI ECU.
4.1.1 Emulating the RTE

A minimal approach for integrating SWCs is to provide a RTE emulator. The RTE
emulator provides the SWCs with the required interface and calls their Runnables as
required. Figure 4-1 shows the architecture for this approach.
Figure 4-1: Integrating a SWC by emulating the RTE

9 of 37

MM/T/HMI ECU
V1.0.0
The RTEs interface to the SWCs is generic. It does not provide a fixed set of
functions. The RTEs communication interface is generated and tailored to the needs
of the SWCs it serves. The same is true for the scheduling of the SWCs. This generic
nature of the RTE makes an emulation of the RTE hard to maintain. Any change on
the set of integrated SWCs will lead to manual adjustments on the RTE emulator.
Instead of adjusting the RTE emulator each time manually, a generator could be
implemented for the RTE emulator. This generator would work just as a normal RTE
generator except for not generating a RTE, which relies on the AUTOSAR OS
services and AUTOSAR BSWMs but which would use service calls to the MM/T/HMI
basic software.
This approach of emulating the RTE is only sufficient if the SWC integrated does not
depend on any BSWM services. Otherwise, the RTE emulator would also have to
emulate the required services or even one of the approaches described in 4.1.3 and
4.2 is needed.
4.1.1.1 SWC & BSWM Scheduling

The RTE is responsible for scheduling the SWCs and BSWMs. Within AUTOSAR
Runnables are mapped to Tasks. The Tasks will execute the Runnables when they
are triggered. The RTE triggers the Tasks on the occurrence of certain Events.
Events occur for instance on reception of data or when an Alarm expires (periodical
scheduling). The RTE uses services provided by the AUTOSAR OS to activate
timers and to trigger the Tasks. If more than one Task is triggered at the same time
the AUTOSAR OS will execute the Task with the higher priority assigned to it.
The RTE emulator will have to use the means of the MM/T/HMI OS to emulate the
scheduling behavior described above. This can usually be achieved by creating
threads, which correspond to the Tasks in AUTOSAR. This means that for each
Task, which would have been defined in the AUTOSAR OS a thread is created. The
priorities of the Tasks also have to be mapped to the threads.
A prerequisite that a mapping from Tasks to threads will lead to a correct scheduling
of the SWCs and BSWMs, is that the MM/T/HMI OS has real-time capabilities (see
1.3).
4.1.2 Integrating the RTE

Due to the generic nature of the RTE (see 4.1.1) emulating the RTE leads to a hard
to maintain system. Taking the RTE from the AUTOSAR architecture as it is and
integrating it into the MM/T/HMI ECU, too, avoids manual adjustments. The RTE can
be regenerated when the set of integrated SWCs changes.
In order to integrate the RTE into a MM/T/HMI ECU the requirements of the RTE
towards services from other BSWMs have to be met by the services provided by the
MM/T/HMI ECUs basic software.
For scheduling the SWCs the RTE depends on the services provided by the
AUTOSAR OS. The RTE uses Tasks, Alarms, Events etc. to schedule the SWCs.
The AUTOSAR OS provides an interface with functions for accessing and controlling
these objects. Other operating systems provide similar objects as the AUTOSAR OS
10 of 37

MM/T/HMI ECU
V1.0.0
but slightly different access and control functions. In order to integrate the RTE an
AUTOSAR OS emulator is required, which provides an interface with which the
objects of the non-AUTOSAR OS can be accessed and controlled (Figure 4-2).
Figure 4-2: Integrating a SWC together with the RTE
The AUTOSAR OS emulator has to provide the RTE with functions like
ActivateTask() and SetRelAlarm() which the RTE requires for scheduling the
BSWMs and SWCs. When the RTE calls these functions, the AUTOSAR OS
emulator has to react accordingly. It has to create, trigger or suspend threads and
timers using the services provided by the MM/T/HMI ECUs general-purpose OS.
As mentioned above SWCs only depend directly on the RTE, but most SWCs
depend indirectly on BSWMs. Depending indirectly means that they require some
services of the BSWMs, which they access via the interface provided by the RTE
instead of calling the service directly via the BSWMs interface.
Thus, only SWCs, which do not depend on any BSWM, can be fully integrated by this
approach. Section 4.1.3 describes how to handle the integration of SWCs, which
depend on BSWMs.
4.1.2.1 Inter Process Communication

Most of the operating systems used in MM/T/HMI ECUs support the concept of
executing software in separated, protected execution areas. These execution areas
will be referred to as processes in this document.
Each process has an assigned space of memory which it uses for executing code.
This memory space is protected. Protected means only the instances of the
applications and modules executed by that process share its space of memory. Thus,
only instances of applications and modules executed by the same process can call
each others functions directly. Any other instances will have to use the inter process
communication mechanism running on the MM/T/HMI ECU in order to access
functions or data in that memory space.
11 of 37

MM/T/HMI ECU
V1.0.0
This section deals with possible solutions for realizing inter process communication
between a SWC and other MM/T/HMI applications.
A prerequisite for realizing communication between SWCs and MM/T/HMI
applications is that a mapping between the MM/T/HMI applications native interface
(e.g. C functions) and AUTOSAR interfaces is feasible. This might not always be the
case. For instance objects or complex dynamic structures (e.g. a tree structure) can
not be mapped to an AUTOSAR type.
4.1.2.1.1 AUTOSAR SocketAdaptor
Since AUTOSAR release 4.0 the AUTOSAR architecture provides a BSWM for
sending and receiving I-PDUs over sockets the so called SocketAdaptor.
The SocketAdaptor is based on the BSD socket standard. Therefore, if the
MM/T/HMI ECUs IPC system is socket based and the MM/T/HMI ECUs basic
software provides a BSD Socket Programmierschnittstelle AUTOSARs
SocketAdaptor can be used for communicating with MM/T/HMI applications in other
processes. As Figure 4-3 illustrates this approach requires that also the AUTOSAR
COM and the PDU Router BSWMs are integrated into the MM/T/HMI ECU.
Figure 4-3: Inter Process Communication via SocketAdaptor
In order to configure the RTE correctly the following modelling steps are required:
12 of 37
An ECU with all the SWCs to integrate is created. The ECU represents the
AUTOSAR process.

MM/T/HMI ECU
V1.0.0
An ECU is created for each MM/T/HMI process containing MM/T/HMI

applications, which communicate with the SWCs in the AUTOSAR process.
A SWC is created for each MM/T/HMI application communicating with the
SWCs in the AUTOSAR process. The SWCs provide and require port
interfaces, which correspond to their MM/T/HMI applications native interface.
A corresponding port interface could be a client/server interface with
Operations, which correspond to the C-functions the MM/T/HMI application
provides. Finding such a corresponding port interface might not be possible in
all case.
The configuration of the PDU Router and the SocketAdaptor are out of the scope of
this document. For further details on how to configure these BSWMs see the
Specification of PDU Router [2] and the Specification of Socket Adaptor [10].
4.1.2.1.2 Mapping to Inter-Partition Communication
Since release 4.0 AUTOSAR also supports the concept of partitioning software into
separated, protected execution areas. Within AUTOSAR these areas are called OS
Applications. The AUTOSAR OS provides a mechanism for transferring data from
one OS-Application to another one. This mechanism is called Inter OS-Application
Communication (IOC). RTE implementations from release 4.0 upwards can be
configured to use the Inter OS-Application Communication mechanism for routing
data between two SWCs residing in different OS-Applications.
This feature can be used for realizing the communication between SWCs and
MM/T/HMI applications. Instead of modeling the AUTOSAR process and the
MM/T/HMI processes as separate ECUs they are modeled as OS-Applications. The
RTE generated for the AUTOSAR process, will then call the AUTOSAR OS services
IOC_send_XXX and IOC_receive_XXX instead of calling the AUTOSAR COM. For
integrating the RTE an AUTOSAR OS emulator is required, which will provide the
two IOC services and map those to corresponding IPC calls (e.g. write/read to/from
shared memory).
13 of 37

MM/T/HMI ECU
V1.0.0
Figure 4-4: Inter Process Communication via IOC
In order to configure the RTE correctly the following modelling steps are required:
An OS-Application with all the SWCs to integrate is created. The OSApplication represents the AUTOSAR process.
An OS-Application is created for each MM/T/HMI process containing
MM/T/HMI applications, which communicate with the SWCs in the AUTOSAR
process.
A SWC is created for each MM/T/HMI application communicating with the
SWCs in the AUTOSAR process. The SWCs provide and require port
interfaces, which correspond to their MM/T/HMI applications native interface.
A corresponding port interface could be a client/server interface with
Operations, which correspond to the C-functions the MM/T/HMI application
provides. Finding such a corresponding port interface might not be possible in
any case.
4.1.2.1.3 Mapping to Intra ECU Communication
Until release 3.1 of AUTOSAR no concept for separated, protected execution areas
was supported. Mapping AUTOSARs inter partition communication mechanism to
the concrete IPC provided by the MM/T/HMI ECUs basic software is not possible.
Thus, when working with a RTE implementation based on AUTOSAR release 3.1 or
earlier a different approach is required.
By providing a module in the RTEs process, which proxies the MM/T/HMI
applications located outside of the process, the RTEs job can be reduced to intra
process communication. The RTE only has to forward data from the SWCs to the
proxy and vice versa. The proxy realizes the access to the MM/T/HMI ECUs IPC
system. It translates dispatches and routes data from and to the actual MM/T/HMI
14 of 37

MM/T/HMI ECU
V1.0.0
applications, located in other processes. Figure 4-5 shows how a SWC
communicates via the RTE and a proxy with a MM/T/HMI application located in
another process.
Figure 4-5: Inter Process Communication via Proxy
In order to configure the RTE corresponding to behave as described the following

steps are required in the templates:
An ECU with all the SWCs to integrate is created. The ECU represents the
AUTOSAR process.
An extra SWC for the proxy has to be added to the ECU representing the
AUTOSAR process. The SWC provides and requires port interfaces, which
correspond to the MM/T/HMI applications native interface. A corresponding
port interface could be a client/server interface with Operations, which
correspond to the C-functions the MM/T/HMI application provides. Finding
such a corresponding port interface might not be possible in any case.
4.1.2.2 Inter ECU Communication

Besides scheduling the SWCs the RTE is also responsible for dispatching their
communication calls. For realizing local communication the RTE does not depend on
any other BSWM. Therefore integrating SWCs which only communicate locally is
possible.
The integration of SWCs which need to communicate with other SWCs located on a
different ECU requires some extra steps in order to enable the RTE to realize remote
communication on the MM/T/HMI ECU. The necessary steps involved in enabling
15 of 37

MM/T/HMI ECU
V1.0.0
remote communication via the RTE depend on the provided communication stack
and if it resides in the same process as the RTE or not.
For enabling remote communication the following three cases can be distinguished.
4.1.2.2.1 AUTOSAR Supported Medium
If the RTE and the communication stack reside in the same process and the physical
communication medium is supported by AUTOSAR the MCAL emulation approach
can be used (see 4.2.2). The AUTOSAR communication stack can be integrated
enabling the RTE access to the communicate medium.
4.1.2.2.2 AUTOSAR Unsupported Medium
If the RTE and the communication stack reside in the same process but the
communication medium is not supported by AUTOSAR a similar approach as in
4.1.2.1.3 is required.
A module for accessing the communication stack is required, which acts as a proxy
for all remote communication partners of the SWCs serviced by the RTE. It provides
the ports of the communication partners to the SWCs. This way the communication
between the SWCs and their remote communication partners appears to the RTE
like intra ECU communication between the SWCs and the proxy. The proxy does the
actual work of translating, dispatching and routing the messages. The evaluation of
update-bits also has to be realized in the proxy unless it is already realized by the
gateway (see Figure 4-6).
16 of 37

MM/T/HMI ECU
V1.0.0
Figure 4-6: Inter ECU communication via Proxy
When converting inter ECU communication to intra ECU communication, the

behavior of the RTE changes slightly. The RTE will not return errors to the SWC,
which result from inter ECU communication via the AUTOSAR COM module. The
following errors will not be returned:
RTE_E_COM_STOPPED
RTE_E_MAX_AGE_EXCEEDED
RTE_E_TRANSMIT_ACK
RTE_E_LOST_DATA
Will not be returned if the data loss is based on communication errors.
RTE_E_TIMEOUT
Will not be returned if the client and server are in the same Task (only returned
for Inter Task communication).
If the implementation of a SWC depends on any of the above listed error values a
COM module emulation is required which will provide these errors.
4.1.2.3 Inter ECU via Inter Process Communication

If the SWC and the RTE reside in the same process and the communication stack
resides in another process, the RTE has to access the provided inter process
communication mechanism (see 4.1.2.1) in order to transfer data to/from SWCs
17 of 37

MM/T/HMI ECU
V1.0.0
located on other ECUs. Figure 4-7 shows the architecture if the inter ECU
communication was realized with the proxy approach described in 4.1.2.1.3.
Figure 4-7: Inter ECU communication via Inter Process Proxy
The behavior of the RTE is slightly changed by this approach (see 4.1.2.2.2).
4.1.3 Emulating BSWMs

Most SWCs depend on functions provided by BSWMs. For integrating these SWCs
the functions of the BSWMs they depend on have to be emulated or have also to be
integrated into the MM/T/HMI ECU.
Emulating a BSWM makes sense if only very few and simple services of a BSWM
are required. Otherwise integrating the BSWM is in most cases more appropriate
(see 4.2). Figure 4-8 shows an architecture where the BSWMs required by the SWC
are only emulated.
18 of 37

MM/T/HMI ECU
V1.0.0
Figure 4-8: Emulating BSWMs for integrating a SWC
4.2 Integrating BSWMs

BSWMs depend on the the RTE. The RTE schedules their main functions and
provides a communication interface for calling SWCs.
Besides depending on the RTE most BSWMs also depend on the presence of other
BSWMs. For integrating a BSWM the required functions provided by other BSWMs
have to be made available on the MM/T/HMI ECU. This can be achieved by
emulating the required functions or by also integrating the BSWMs providing the
functions. Integrating the BSWMs will provide the required functions but will also
introduce new dependencies to further BSWMs which they need themselves.
The main question when integrating functionality from the AUTOSAR architecture is
where to draw the emulation line? This means deciding which of the BSWMs shall be
integrated and which shall be emulated. The next two sections will present two
radical approaches emulating all required BSWMs and integrating all required
BSWMs. If one of those two approaches or some approach in between has to be
chosen depends on the concrete use case. It depends on the functionality, which is
to be integrated and the basic software on the MM/T/HMI ECU.
4.2.1 Only Emulating the BSWMs Neighborhood

A very use case specific approach for integrating a BSWM is to emulate all the
BSWMs the BSWM directly depends on. These BSWMs are called the BSWMs
neighborhood. Figure 4-9 illustrates the integration of a Service Module, which
depends on two other BSWMs (one Service Module and one Interface Module). Both
modules are emulated.
19 of 37

MM/T/HMI ECU
V1.0.0
Figure 4-9: Emulating the direct neighbours for integrating a BSWM
Emulating a BSWM makes sense only if very few and simple functions are required
from it. Otherwise integrating that BSWM, too, is the better solution.
Unfortunately, integrating a BSWM is not always possible. Adjustments and
extensions to the BSWM might be needed due to the services provided by the
MM/T/HMI ECUs software srchitecture. In such a case the BSWM has to be
emulated. An example would be the usage of the ComManager on a MM/T/HMI
ECU, which uses the MOST bus-system for communication. The AUTOSAR
ComManager does not support MOST. Therefore, integrating an existing
implementation of the ComManager will not work on this specific MM/T/HMI ECU. A
ComManager emulator is required, which will take the status of the MOST bussystem into account.
4.2.2 Emulating the MCAL

The approach described in 4.2.1 is very use case specific. The solution is customized
to the exact needs of the BSWM, which is to be integrated. A more general and
therefore generic approach would be to emulate the functions provided by the
BSWMs of the Microcontroller Abstraction Layer. This would allow the integration of
any BSWM from the ECU Abstraction and the Services Layer. The architecture of
this approach is shown in Figure 4-10.
20 of 37

MM/T/HMI ECU
V1.0.0
Figure 4-10: MCAL Emulation
As already mentioned in the previous section (4.2.1) the feasibility of a BSWM

integration heavily depends on the MM/T/HMI ECU into which the BSWM is to be
integrated. BSWMs might have to be adjusted or extended in order to work properly
on the given MM/T/HMI ECU.
4.2.3 Emulator Development and Configuration Process

The specification of a development and configuration process for the emulators is not
in the scope of this document. No assumptions are made about this process. The
emulators could be implemented manually, could be partially generated or could be
completely generated. Therefore, this document will not describe any approaches on
how configuration parameters from the BSWM, affecting the behavior of the
emulators, are to be provided to them. This is an implementation detail and depends
on the emulators development and configuration process.
21 of 37

MM/T/HMI ECU
V1.0.0
5 Example: Integrating AUTOSAR Diagnostics

In this chapter, a use case for integrating functionality from the AUTOSAR
architecture is described. The selected functionality to integrate is AUTOSARs
diagnostic functionality. The following modules are to be integrated into the
MM/T/HMI ECU.
Diagnostic Communication Manager (DCM)
The DCM implements the UDS and the OBD protocols, which are needed for
the communication between the ECU and the diagnostic tools.
Diagnostic Event Manager (DEM)
The DEM provides a service for handling errors. SWCs and BSWMs can pass
errors to the DEM. It will persistently store those errors in a standardized
format.
The approach chosen in this example for integrating the BSWMs (DCM and DEM) is
to emulate their direct neighborhood (see 4.2.1).
5.1 Targeted MM/T/HMI ECU

The MM/T/HMI ECU into which the diagnostic modules are to be integrated runs a
general-purpose OS with the capabilities described in 1.3. In order to avoid the
example of becoming too OS-specific no concrete OS (WinCE, QNX etc.) is
referenced. The most important aspect for the example is that the OS runs in a
protected space (Kernel Space) and four other processes are provided (Figure 5-1).
22 of 37

MM/T/HMI ECU
V1.0.0
Figure 5-1: The initial MM/T/HMI ECUs software architecture
The roles of the processes are as follows.
Communication Process
This process runs the communication stack of the ECU providing access to
the physical medium via which the ECU is connected to the rest of the vehicle.
The physical medium shall not be specified in more detail. It could be CAN,
Flexray, MOST, Firewire or any other physical medium.
CE Infrastructure Process
Consumer electronic specific services, which are required for implementing
MM/T/HMI applications are provided by this process.
Application Processes A & B

These two processes run the MM/T/HMI applications.
The processes communicate with each other using inter process communication. It is
assumed that some inter process communication other than BSD sockets is provided
by the MM/T/HMI ECUs basic software. This could be shared memory or some other
mechanism provided by the OS.
5.2 Process Deployment

23 of 37

MM/T/HMI ECU
V1.0.0
All the AUTOSAR modules and the required emulators are deployed into an extra
process as shown in Figure 5-2.
Figure 5-2: Architecture of the AUTOSAR Process for the DCM & DEM Integration
This is a very simple approach, which has some advantages making the integration
easier. One advantage of keeping all the AUTOSAR software in one process is that
unnecessary, time consuming process changes are avoided. Some of the BSWMs
highly depend on each other meaning that they call each others services very
frequently. Spreading the BSWMs across many processes would lead to numerous
process switches.
BSWMs are designed to call functions of other BSWMs directly not via the RTE. This
is of course only possible if the BSWMs reside in the same process. If they would be
scattered across various processes the function calls between the BSWMs would
have to be mapped to inter process communication calls. Therefore, an additional
emulator is required. By keeping the BSWMs together in one process the
implementation of additional emulation code can be avoided.
Keeping the AUTOSAR software separated from the CE services also makes the
integration easier. Integrating the BSWMs into an existing process with numerous
other CE services is far more complicated than simply adding an extra process
(AUTOSAR Process) to the system.
5.3 AUTOSAR Modules Integration
24 of 37

MM/T/HMI ECU
V1.0.0
This section discusses the components involved in the integration of the DCM and
the DEM into the previously described MM/T/HMI ECU (5.1). Figure 5-2 shows the
architecture of the AUTOSAR Process in more detail. In the following subsections the
emulators and the interfaces, which they emulate are described in more detail.
5.3.1 DCM Integration

The DCM implements the UDS and the OBD protocols, which are used for
communicating with the diagnostic tools. The DCM has numerous dependencies to
other BSWMs. Most of these interfaces have to be provided by emulators. Figure 5-3
depicts the DCM and the interfaces it depends on.
Figure 5-3: DCMs interfaces to other components
Besides the dependencies to the emulated interfaces the DCM also has a
dependency to functions provided by the DEM as shown in Figure 5-3.
5.3.1.1 DCM Configuration

In this scenario, the DCM is configured to only support the UDS protocol. A detailed
listing and discussion on the concrete settings of the DCMs configuration parameters
is not in the scope of this document.
5.3.1.2 ECU State Manager Emulation

25 of 37

MM/T/HMI ECU
V1.0.0
The ECU State Manager is responsible for initializing the BSWMs. Within the
AUTOSAR architecture, the DCM would expect the ECU State Manager to initialize it
during the startup phase of the ECU.
The DCM provides a function for initializing it. It expects the ECU State Manager to
call this function.
void Dcm_Init()
// Initialize the DCM
Listing 5-1: DCMs initialization function
The ECU State Manager emulator is the entry point for the AUTOSAR process. It
contains the process main() function which will be called by the MM/T/HMI OS
when starting the process. The main() function will call the initialization functions of
the BSWMs integrated in the AUTOSAR process. This behavior corresponds to the
behavior of the EcuM_Init() function specified in the Specification of ECU State
Manager document [8].
The ECU State Manager emulator does not have to support mode ports, as the DCM
does not use this feature.
5.3.1.3 ComManager Emulation

The DCM expects to be informed by the ComManager into which communication mode it has to
switch. Three modes are supported (see
Listing 5-2).
void Dcm_ComM_NoComModeEntered() // Switch the DCM to NoCom mode

void Dcm_ComM_SilentComModeEntered() // Switch the DCM to SilentCom mode
void Dcm_ComM_FullComModeEntered() // Switch the DCM to FullCom mode
Listing 5-2: DCMs mode switching functions
The activation of the different communication modes depends on the communication

policy for the targeted MM/T/HMI ECU. The behavior of the emulator concerning the
communication mode switching is therefore highly ECU specific and cannot be
generalized.
The DCM notifies the ComManager when diagnostic communication is started and
when it ends. This way the ComManager knows that the DCM requires the
FullCommunication mode. The DCM does this by calling the functions listed in
Listing 5-3.
26 of 37

MM/T/HMI ECU
V1.0.0
/**
* Notification from the DCM to the ComManager that diagnostic is active
*/
void ComM_DCM_ActiveDiagnostic(NetworkId)
/**
* Notification from the DCM to the ComManager that diagnostic is inactive
*/
void ComM_DCM_InactiveDiagnostic(NetworkId)
Listing 5-3: DCMs diagnostic state notification functions
The ComManager emulator has to provide these two functions and forward the
request for full communication to the communication management component of the
MM/T/HMI ECUs basic software. The ComManager emulator also has to forward the
notification to the RTE emulator for activating and deactivating the scheduling of the
DCMs main function. For more details on this issue, please see 5.3.1.8.
5.3.1.4 PDU Router Emulation

The PDU Router handles the traffic of diagnostic messages from and to the DCM. It
notifies the DCM about received diagnostic requests and passes diagnostic
responses from the DCM to the lower communication layers.
The PDU Router emulator has to provide the incoming diagnostic requests to the
DCM. The DCM expects the PDU Router to do so by initially asking it if it is ready to
accept a request. If the DCM allows the reception, the PDU Router is expected to fill
the DCMs request buffer with the incoming request segments. After completely filling
the buffer with the diagnostic request, the DCM expects to be notified that the
diagnostic request is now ready for processing.
In addition, the DCM also expects a function for canceling the current reception
process, which the PDU Router emulator has to provide.
The functions, listed below, describe the reception interface the PDU Router
emulator has to implement.
/**
* Ask DCM if ready for reception
*/
BufReq_ReturnType Dcm_StartOfReception(PduIdType,
27 of 37

MM/T/HMI ECU
V1.0.0
PduLengthType,
PduInfoType**)
/**
* Copy request segments into reception buffer
*/
BufReq_ReturnType Dcm_CopyRxData(PduIdType,
PduLengthType,
PduInfoType**)
/**
* Notify DCM about completion of reception process
*/
void Dcm_RxIndication(PduIdType, NotifResultType)
/**
* DCM requests the cancelation of the current reception
*/
void PduR_CancelReceiveRequest (PduR_CancelReasonType, PduIdType)
Listing 5-4: Reception Interface between DCM and PDU Router
After processing a diagnostic message, the DCM will ask the PDU Router to transmit
the corresponding response. The PDU Router emulator then has to retrieve the data
to transmit from the DCM, which provides a callback for that reason. Just as for the
reception, the DCM will expect to be informed by the PDU Router emulator as soon
as the response has been transmitted. As for the reception process the DCM
requires a cancelation function, which the PDU Router emulator has to implement.
The listing below lists all the functions the PDU Router emulator has to implement in
order to satisfy the transmission interface between the DCM and the PDU Router.
/**
* Ask the PDU Router to transmit a diagnostic response
*/
Std_ReturnType PduR_DcmTransmit(PduIdType, const PduInfoType*)
/**
* Copy data to transmit from the DCM to the PDU Router
28 of 37

MM/T/HMI ECU
V1.0.0
*/
BufReq_ReturnType Dcm_CopyTxData(PduIdType,
PduInfoType**,
PduLengthType)
/**
* Notify the DCM that the diagnostic response has been sent
*/
void Dcm_TxConfirmation(PduIdType, NotifResultType)
/**
* DCM requests the cancelation of the current transmission
*/
void PduR_CancelTransmitRequest(PduR_CancelReasonType, PduIdType)
Listing 5-5: Transmission Interface between DCM and PDU Router
The PDU Router emulator is directly connected to the IPC system and listens for
incoming diagnostic messages. Depending on the IPC mechanism used, the PDU
Router emulator needs to explicitly register for the diagnostic messages or filter them
out. On reception of a diagnostic message, it needs to convert the diagnostic
message from the IPC format into the format expected by the DCM. When asked to
transmit a message for the DCM it would need to convert the diagnostic message to
the corresponding IPC format and pass it to the Communication Process via the IPC
mechanism.
5.3.1.5 I/O Hardware Abstraction Emulation

The
DCM
handles
the
services
ReadDataByIdentifier
and
InputOutputControlByIdentifier. The ReadDataByIdentifier service provides read
access to data memory but also to sensor values. The InputOutputControlByIdentifier
service provides the tester with the possibility to adjust or reset values of sensors and
actuators.
Therefore, the DCM requires access to the I/O Hardware Abstraction for handling
requests to those two services.
An I/O Hardware Abstraction emulator is needed, which has to implement the two functions in
Listing 5-6.
/**
* For reading a signal
*/
IoHwAb_Dcm_Read<EcuSignalName>()
/**
29 of 37

MM/T/HMI ECU
V1.0.0
* For adjusting a signal
*/
IoHwAb_Dcm_<EcuSignalName>()
Listing 5-6: DCMs ECU signal access functions
The I/O Hardware Abstraction emulator has to map calls to these functions to system
calls, which the MM/T/HMI ECUs basic software provides for accessing the
corresponding signals of the sensors and actuators.
5.3.1.6 Basic Software Mode Manager Emulation

The DCM handles CommunicationControl, DiagnosticSessionControl and ECUReset
requests. All three requests ask the ECU to switch into a certain operation mode. For
handling these requests, the DCM depends on the presence of the Basic Software
Mode Manager. The listing below lists the functions the DCM expects from the Basic
Software Mode Manager for realizing the requested mode switches.
/**
* Request for switching to another communication mode
*/
BswM_Dcm_RequestCommunicationMode(NetworkHandleType,
DcmCommunicationModeType)
/**
* Request for switching into another Diagnostic Session
*/
BswM_Dcm_RequestSessionMode(Dcm_SesCtrlType)
/**
* Request for resetting the ECU
*/
BswM_Dcm_RequestResetMode(Dcm_ResetModeType)
Listing 5-7: DCMs mode switch request functions
In the case of CommunicationControl and ECUReset the Basic Software Mode

Manager emulator has to forward these requests to components of the MM/T/HMI
ECUs basic software, which are in charge of allowing and managing the change of
operation modes (e.g. limited communication, ECU reset etc.). For the
DiagnosticSessionControl request, the Basic Software Mode Manager emulator will
have to track the current session as well as manage and control switches to
diagnostic sessions. This will probably require querying some components of the
MM/T/HMI ECUs basic software, which are in charge of managing the ECUs state.
30 of 37

MM/T/HMI ECU
V1.0.0
In all cases, the DCM expects to get feedback from the BSW Mode Manager
emulator. The DCM determines if a positive or negative response is to be returned to
the tester by comparing the requested mode to the mode the ECU switches to. For
this purpose, it provides notification functions. The DCM expects the Basic Software
Mode Manager emulator to use these for indicating which mode has been entered.
Listing 5-8 lists the callback functions.
/**
* Indicates that the mode <ModeName> has been entered.
*/
Dcm_<ModeName>ModeEntry()
Listing 5-8: DCMs mode entry notification functions
5.3.1.7 NvRAM Manager Emulation

The DCM handles incoming UDS requests for ReadDataByIdentifier and
WriteDataByIdentifier. Therefore, the DCM requires access to non-volatile memory.
Within the AUTOSAR architecture, the NvRAM Manager provides the DCM with an
interface for this occasion. The DCM requires a function for reading, locking and
writing a memory block in order to handle the ReadDataByIdentifier and
WriteDataByIdentifier services.
Listing 5-9 lists the concrete function signatures the DCM expects from the NvRam
emulator.
/**
* For reading non-volatile data
* (ReadDataByIdentifier)
*/
Std_ReturnType NvM_ReadBlock(NvM_BlockIdType, uint8*)
/**
* Locking non-volatile data for exclusive access
* (WriteDataByIdentifier)
31 of 37

MM/T/HMI ECU
V1.0.0
*/
Std_ReturnType NvM_SetBlockLockStatus(NvM_BlockIdType,
uint8*)
/**
* For changing non-volatile data
* (WriteDataByIdentifier)
*/
Std_ReturnType NvM_WriteBlock(NvM_BlockIdType, const uint8*)
Listing 5-9: DCMs non-volatile data access functions
The operating systems used in MM/T/HMI ECUs usually provide a file system.
Persistent data is accessed based on files. The NvRAM Manager emulator needs to
convert block identifiers to files. It could create a file for each block setting the file
name to the block identifier. Another possibility could be to create one file and store
the data together with the block identifier as a key in that one file.
The NVRam Manager is not simply an abstract interface to accessing non-volatile
memory. It provides a rich set of mechanisms for ensuring data storage and
maintenance of non-volatile data. Among these mechanisms, there are redundant
data storage, CRC checksums, error recovery and others. Depending on the
requirements towards the system, the NVRam Manager emulator will have to
implement these mechanisms, too. If a significant number of the NVRam Managers
mechanisms are required, an integration of the NVRam Manager might be a better,
less expensive solution.
5.3.1.8 RTE Emulation

The RTE emulator has to implement two functionalities in order for the DCM to work
properly. The first functionality is the scheduling of the DCM (see also 4.1.1.1) and
the second is the forwarding of application-specific diagnostic requests
(StartRoutineByIdentifier) to the applications.
5.3.1.8.1 DCM Scheduling
The DCM expects its main function Dcm_MainFunction() to be triggered

periodically. The Dcm_MainFunction() requires to be called periodically for the
following reasons:
32 of 37
Detect timeouts when receiving and processing (ResponsePending)

diagnostic requests
Detect the absence of a TesterAlive message when a non-default diagnostic
session is active

MM/T/HMI ECU
V1.0.0
Sending
data
records
periodically
ReadDataByPeriodicIdentifier request
Sending diagnostic responses on event
as
response
to
In order to keep the jitter for the timeouts low the period for triggering the
Dcm_MainFunction() function is usually rather small (e.g. 10ms). In this example
the AUTOSAR components run in a separate process (see 5.2), which implies that a
small period for the Dcm_MainFunction() function would result in a high frequency
of process switches between the application process and the AUTOSAR process. It
is recommended to avoid unnecessary process switches, as they are rather
expensive.
Most of the time the Dcm_MainFunction() does not have to be triggered
periodically. The DCM only requires periodic triggering when processing a diagnostic
request, a non-default diagnostic session is active or responses have to be send
periodically or on event. This can be realized by using the notification calls
(ComM_DCM_ActiveDiagnostic()
& ComM_DCM_InactiveDiagnostic())
from the DCM to the ComManager emulator as triggers for starting and suspending
the DCM thread. Therefore, it is required that the ComManager emulator will forward
the notification calls to the RTE emulator (see 5.3.1.3) which is responsible for
scheduling the DCM.
This approach of using the notification functions as scheduling triggers will not work
for the ResponseOnEvent if it is resumed. This means ResponseOnEvent is
activated by settings loaded on ECU startup. In this case the DCM will not notify the
ComManager. If this functionality is being used the DCM will have to be triggered
periodically all the time.
5.3.1.8.2 Diagnostic Request Forwarding
The DCM does not handle all diagnostic requests. Some diagnostic requests, like the
UDS request StartRoutineByIdentifier, have to be handled by the Applications. In a
full-fledged AUTOSAR architecture, the DCM passes these requests to the RTE,
which routes them to the SWCs. In this integration example there are no SWCs. The
diagnostic routines are provided by the applications, which reside in another process
(see Figure 5-2). Thus, the job of the RTE emulator is to forward the applicationspecific diagnostic requests to the applications via the MM/T/HMI ECUs IPC.
5.3.2 DEM Integration
The DEM provides a service for handling errors. SWCs and BSWMs can pass errors
to the DEM. It will persistently store those errors in a standardized format.
Two emulators are needed to integrate the DEM into a MM/T/HMI ECU. The first
emulator needed is the ECU State Manager emulator, which has to call the DEMs
lifecycle functions. It initializes the DEM and shuts it down. The second emulator is
the NvRAM Manager emulator. It has to provide functions to the DEM for storing
errors in a persistent manner.
Figure 5-4 shows a more detailed view on the architecture of the AUTOSAR Process.
The interfaces between the DEM and the other components are depicted.
33 of 37

MM/T/HMI ECU
V1.0.0
Figure 5-4: DEMs interfaces to other components
5.3.2.1 DEM Configuration

In this scenario, the DEM is configured to store errors in a persistent manner. A
detailed listing and discussion on the concrete settings of the DEMs configuration
parameters is not in the scope of this document.
5.3.2.2 ECU State Manager Emulation

The ECU State Manager is responsible for initializing the BSWMs. Within the
AUTOSAR architecture, the DEM would expect the ECU State Manager to initialize it
during the startup phase of the ECU.
34 of 37

MM/T/HMI ECU
V1.0.0
The DEM provides the functions below for initializing and shutting it done. It expects
these functions to be called by the ECU State Manager.
void Dem_PreInit()
void Dem_Init()
void Dem_Shutdown()
// Initialization of DEM phase I

// Initialization of DEM phase II
// Shutting the DEM down
Listing 5-10: DEMs lifecycle functions
The ECU State Manager emulator contains the main() function of the process
which will call the DEM initialization functions (see 5.3.1.2).
The DEM expects to be initialized in a two-phased way. After the Dem_PreInit()
function is called the DEM will enter the first of two initialization phases. From this
time on the DEM will accept event notifications from SWCs and BSWMs. The events
received during phase I will not be stored in a persistent manner. The DEM will do so
after entering initialization phase II. The Dem_Init() function is to be called as soon
as the NvRAM Manager has finished initializing and access to the persistent memory
of the ECU is available.
This two-phased approach to initialize the DEM has been specified in order to track
errors, which occur before the persistent memory access of the ECU has been
initialized. Within a MM/T/HMI ECU, the DEM is not an integral part of the operating
system. It is started as part of the AUTOSAR process. This process is started after
the services of the operating system, which include the file system (persistent
memory access). Therefore, there is no need for starting the DEM in two steps. The
ECU State Manager emulator can simply call the Dem_PreInit() and the
Dem_Init() functions consecutively as soon as the AUTOSAR Process is started.
The ECU State Manager emulator does not have to support mode ports, as the DEM
does not use this feature.
5.3.2.3 NvRAM Manager Emulation

The DEMs job is it to store errors passed to it by SWCs and BSWMs in a persistent
manner. It therefore relies on the services of the NvRAM Manager for accessing the
ECUs persistent memory.
The NvRAM Manager provides access to the persistent memory of the ECU, which the DEM
needs to store events. The DEM does not only need write access to the persistent memory but
also read access for returning the errors to the DCM which will send them to the diagnostic
tool. The functions in
Listing 5-11 are required by the DEM for storing and loading error entries.
35 of 37

MM/T/HMI ECU
V1.0.0
/**
* For explicitly loading error entries
*/
Std_ReturnType NvM_ReadBlock( NvM_BlockIdType,
uint8*)
/**
* For explicitly storing error entries
*/
Std_ReturnType NvM_WriteBlock(NvM_BlockIdType,
const uint8*)
/**
* For marking error entries to be stored
*/
void NvM_SetRamBlockStatus(NvM_BlockIdType,
Boolean)
/**
* For checking an error entries status
*/
void NvM_GetErrorStatus(NvM_BlockIdType,
NvM_RequestResultType)
Listing 5-11: DEMs persistent error storage functions
The NvRAM Manager emulation has already been described in 5.3.1.7.
5.3.2.4 RTE Emulation

The RTE emulator has two implement two functionalities in order for the DEM to work
properly. The first functionality is the scheduling of the DEM (see also 4.1.1.1) and
the second is providing the DEM services to the applications via the MM/T/HMI
ECUs IPC.
DEM Scheduling
The DEM expects its main function Dem_Main() to be triggered periodically. The
Dem_Main() function processes diagnostic events.
As for the DCM the periodic triggering of the Dem_Main() function leads to
expensive process switches, which is to be avoided if possible (see 5.3.1.8).
The BSW Scheduler of the RTE has to be configured via the BSWM Description
Template so that it will only trigger the Dem_Main() function periodically when a
diagnostic event is reported and being processed. For detailed information how to
configure such a behavior please refer to the Specification of the BSW Module
Description Template (see [11]).
Providing DEM Service
36 of 37

MM/T/HMI ECU
V1.0.0
In the AUTOSAR architecture, SWCs can report diagnostic events to the DEM via
service ports provided by the RTE. In this integration example instead of SWCs
applications, residing in another process, are the clients to the DEM services. The
RTE emulator therefore has to take the role of a proxy which provides the DEM
services to the applications via the MM/T/HMI ECUs IPC and forwards the requests
to the DEM.
37 of 37

Autosar TR Integrationintommthmiecu

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autosar TR Integrationintommthmiecu

Uploaded by

Copyright:

Available Formats

Demonstration of Integration of AUTOSAR into a

Document Change History

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

Advice for users

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

Introduction and functional overview ................................................................... 5

Acronyms and abbreviations ............................................................................... 7

Integration Approaches ....................................................................................... 9

Example: Integrating AUTOSAR Diagnostics.................................................... 22

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

NvRAM Manager Emulation......................................................... 35

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

1 Introduction and functional overview

1.1 Document Scope

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

1.3 MM/T/HMI ECU Definition

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

2 Acronyms and abbreviations

Berkly Software Distribution

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

4.1 Integrating SWCs

4.1.1 Emulating the RTE

Figure 4-1: Integrating a SWC by emulating the RTE

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

4.1.1.1 SWC & BSWM Scheduling

4.1.2 Integrating the RTE

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

Figure 4-2: Integrating a SWC together with the RTE

4.1.2.1 Inter Process Communication

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

4.1.2.1.1 AUTOSAR SocketAdaptor

Figure 4-3: Inter Process Communication via SocketAdaptor

Demonstration of Integration of AUTOSAR into a

An ECU is created for each MM/T/HMI process containing MM/T/HMI

4.1.2.1.2 Mapping to Inter-Partition Communication

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

Figure 4-4: Inter Process Communication via IOC

4.1.2.1.3 Mapping to Intra ECU Communication

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

Figure 4-5: Inter Process Communication via Proxy

In order to configure the RTE corresponding to behave as described the following

4.1.2.2 Inter ECU Communication

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

4.1.2.2.1 AUTOSAR Supported Medium

4.1.2.2.2 AUTOSAR Unsupported Medium

Document ID 422: AUTOSAR_TR_IntegrationintoMMTHMIECU

Demonstration of Integration of AUTOSAR into a

Figure 4-6: Inter ECU communication via Proxy