4. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Background
Today’s automotive industry is faced with
a growing demand for technical
appliances and this requires an increased
use of ECUs which is reflected in the
complexity of the system.
Traditionally, solutions have been specific
for a certain platform or model and this
structure is more becoming unmanageable
and costly.
Instead of making specific solutions a
standardized future is the way to go.
This increased complexity could be
manageable and improved by a
standardized architecture and the
solution is AUTOSAR
4
6. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Application software that supports the AUTOSAR standard will receive
several benefits.
The following examples are the driving forces why we need AUTOSAR as
listed in :
Manage increasing E/E complexity – Associated with growth in functional scope.
Improve flexibility – More room for updates, upgrades and modifications.
Improve scalability – The system can in a more graceful manner be enlarged.
Improve quality and reliability – Proven software applications can be reused.
Detection of errors in early design phases
6
(AUTomotive Open System ARchitecture)
15. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemWhat is the AUTOSAR standard and
why is it created?
AUTOSAR is standardized software architecture developed in
cooperation between car manufacturers originally intended for the
automotive industry but is steadily gaining interest from other
industries as well.
AUTOSAR was developed with the intention of being able to handle
the increased complexity in today’s automotive industry and to
decouple software from hardware.
Also Integration of functional modules from multiple suppliers
Software updates and upgrades over vehicle lifetime
Consideration of availability and safety requirements
15
23. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Step 1: Input Descriptions
The input description step contains three descriptions:
Software Components: This description is independent
of the actual implementation of the software component.
Among the necessary data to be specified are the
interfaces and the hardware requirements.
System: The system topology (interconnections between
ECUs) need to be specified together with the available
data busses, used protocols, function clustering and
communication matrix and attributes (e.g. data rates,
timing/latency, …).
Hardware: The available hardware (processors, sensors,
actuators, …) needs to be specified together with the
signal processing methods and programming capabilities
23
Step 1: Input Descriptions
Step 2: System Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables
39. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
4 Steps 39
Functions of the car
Brake control BC
Throttle Control TC
Engine Control EH
Door locking DL
Mapping of SWC to ECU
TC Software
Components
(SWCs)
EH
Software
Components
(SWCs)
BC
Software
Components
(SWCs)
DL
Software
Components
(SWCs)
ECU Extract FilesAn extract is created for
each ECU...
Step 1: Input Descriptions
Step 2: System Configuration
Step 3: ECU-configuration
Step 4: Generation of Software
Executables
43. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Microcontroller Abstraction Layer
The Microcontroller Abstraction Layer
(MCAL) is located at the very bottom of the
BSW layer.
MCAL uses its internal software drivers to
directly communicate with the
microcontroller.
These drivers include: memory,
communication and I/O drivers. The task of
the layer is to make layers above it
microcontroller independent.
When the MCAL is implemented it is
microcontroller dependent but provides a
standardized and microcontroller
independent interface upwards in the stack
thus fulfilling its purpose
43
Source: www.autosar.org
44. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
ECU Abstraction Layer
Located on top of the MCAL is the ECU Abstraction Layer
(ECUAL).
Internally it has drivers for external devices and uses the interface
defined by the MCAL to access drivers at the lowest level.
Layers higher up in the stack can use the provided API to gain
access to devices and peripherals without having to know anything
about the hardware, for example, whether or not a device is located
internally or externally, what the microcontroller interface looks like
etc.
The ECUAL aims to make upper layers independent of how the
ECU is structured.
implementation the ECUAL is microcontroller independent
but dependent on the ECU hardware;
Upper layers interfacing the ECUAL are no longer dependent on
either of them (microcontroller and ECU Hardware).
44
45. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Complex Drivers Layer
Typically this layer is used to integrate special purpose
functionality and functionality currently being migrated from
a previous system
Since this is the layer between the microcontroller and the
RTE, drivers for devices with strict timing constraints
can benefit from being placed in the CDL as the multi-
layered parts of the BSW layer is likely to introduce
overhead due to additional layers and
standardization.
Drivers for devices not compliant with AUTOSAR can also
be put here
“How does the standard support migration from existing
solutions?”
The introduction and creation of Complex Drivers in the
AUTOSAR standard can be used to migrate existing solutions
45
48. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What the AUTOSAR Basic Software Module (BSW)
responsible for ?
AUTOSAR has defined a set of BSW modules.
They are responsible for different tasks:
Operating System
Access to non volatile memory
Communication via CAN, LIN, FlexRay and Ethernet Handling the
diagnostics
Access to I/O ports
System services like ECU state management
In addition, so-called Complex Device Drivers can be integrated into
an AUTOSAR ECU. They are used to access the features of the ECU,
which are not covered by the standard BSW of AUTOSAR
48
50. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
The AUTOSAR
communication stack for
FlexRay
Module
Name
Description
FlexRay
Interface
The purpose of the FlexRay Interface module is to provide a generally specified
interface to the communication system for the upper layer modules, e.g. PDU Router
and COM.
It extracts the number of FlexRay drivers and
manages the synchronization to global FlexRay time.
FlexRay Network
Management
This module is responsible for the FlexRay network management. It
coordinates the transition between normal operation and bus-sleep
mode of the network.
FlexRay State
Manager
The FlexRay State Manager controls and monitors the wakeup and startup of
the node in the FlexRay cluster.
FlexRay Transport
Layer
The FlexRay transport protocol segments long data packets in the transmit
direction, collects data in the receive direction and controls the data flow.
Errors such as message loss, message duplication or sequencing errors are detected.
FlexRay
Transceiver Driver
The driver for an external FlexRay transceiver is responsible for
Network diagnostics and switching a transceiver on and off.
50
51. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
The AUTOSAR
communication stack for
FlexRay
Module
Name
Description
AUTOSAR
COM
AUTOSAR COM is a module between the RTE and the PDU Router. It is responsible for
providing Signal level access to the application layer and PDU level access
to the lower layers independent of the protocol.
It packs the signals to a PDU at the transmitter and unpacks the received PDU to
provide signal level access to the application at the receiver. At the PDU level, COM is
responsible for grouping of the PDUs, starting and stopping of the PDU groups.
PDU Router
PDU Router is a module responsible for routing the PDU to the respective
Bus Specific Interface modules.
Above the PduR module all the PDUs are protocol independent, and below PduR all
the PDUs are routed to the protocol specific modules. PduR is also responsible for
PDU level gatewaying i.e. transmitting the received PDU from one Bus Specific
Interface module to other Bus Specific Interface module.
Gatewaying can also be done when a PDU is to be routed from
one controller to another over the same protocol.
51
Source: www.autosar.org
53. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is AUTOSAR Communication Stack (ComStack)?
Introduction to CAN Communication Stack
Depending on the Bus Type of the in-vehicle network
(such as CAN, LIN, Flex-Ray), implementation of the
communication stack is executed.
A generic Communication Stack in AUTOSAR layered
architecture is a set of following software modules:
AUTOSAR COM – part of the Services Layer
Bus Specific Interface Modules – part of the ECU
Abstraction Layer (For example -CanIf, LinIf, FrIf)
External Bus Drivers – part of the ECU Abstraction Layer
(For example – External drivers likeCanDrv, LinDrv,
FlexrayDrv)
Internal Bus Drivers – part of the AUTOSAR MCAL (For
example – CanDrv, LinDrv, FrDrv)
53
55. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Communication Stack
Can TP: The basic services offered by the Can TP module are segmentation of
messages which have a payload of more than 8 bytes, transmission of the
messages with flow control and reassembling the segmented messages at the
receiver.
Can Interface: CAN Interface(CanIf) is a module in the ECU Abstraction Layer
which is responsible for services like Transmit Request, Transmit
Confirmation, Reception Indication, Controller mode control and PDU
mode control.
Can State Manager (CanSM): This module shall implement the control flow for the
respective bus.
CanNm: The AUTOSAR CAN Network Management is a hardware independent
protocol tools that can only be used on CAN network.Its main purpose is to
coordinate the transition between normal operation and bus-sleep mode of
the network. The CAN Network Management (CanNm) function provides an
adaptation between network Management Interface (NmIf) and CAN Interface
(CanIf) module.
Can Driver (CanDrv): This module is a part of the MCAL layer and provides
hardware access to the upper layer services and a hardware-independent interface
to the upper layers. CanIf is the only module that can access the CAN driver.
55
59. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is the Diagnostic Communication Manager (DCM)
The DCM module is network-independent.
All network-specific functionality (the specifics
of networks like CAN, LIN, FlexRay ) is handled
outside of the DCM module. The PDU Router
(PduR) module provides a network-independent
interface to the DCM module.
The DCM module receives a diagnostic message
from the PduR module. The DCM module
processes and checks internally the diagnostic
message.
As part of processing the requested diagnostic
service, the DCM will interact with other BSW
modules or with SW-Components (through the
RTE) to obtain requested data or to execute
requested commands. This processing is very
service-specific. Typically, the DCM will
assemble the gathered information and send a
message back through the PduR module.
59
Source: www.autosar.org
61. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Memory Stack
Memory Stack (MemStack) provides basic
memory management services to the upper
Application layer and to the Basic Software
Modules (BSW) of the AUTOSAR layered
architecture.
Non-Volatile Memory Manager (NvM)
The NvM module ensures data storage and
maintenance of NV (non volatile) data
according to the individual requirements in an
automotive environment.
The NvM module manages the NV data of an
EEPROM and/or a FLASH EEPROM emulation
device.
61
62. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Memory Stack
Memory Interface (MemIf) Module:
The Memory Abstraction Interface (MemIf)
module facilitates abstraction from the
underlying FEE and EA modules. Hence MemIf
module provides upper layer (NvM) with a
virtual segmentation on a uniform linear
address space.
This ensures that the Non-Volatile Memory
Manager (NvM) is independent of the driver
interface layers of EEPROM (Eep) and Flash
interface (Fls)
62
63. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Memory Stack
EEPROM Abstraction(Ea.):
EPROM driver provides services for reading,
writing, erasing data to/from an EEPROM.
It also provides a service for comparing a
data block in the EEPROM with a data block
in the memory (e.g. RAM).
Ea module facilitates abstraction from the
addressing scheme of underlying EEPROM driver
and hence provides a uniform addressing scheme.
This ensures that the upper layer (NvM) need
not be changed if the underlying EEPROM driver
and device is replaced.
63
64. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
AUTOSAR Memory Stack
Flash EEPROM Emulation (FEE) Module:
The Flash EEPROM Emulation (FEE) abstracts from the
device, a specific addressing scheme and segmentation.
This provides the upper layers (NvM) with a virtual
addressing scheme, segmentation as well as a virtually•
unlimited number of erase cycles.
Flash Driver (Fls):
Fls Driver Initializes Flash and reads/writes to Flash
memory.
EEPROM driver (EeP):
EEPROM driver provides services for reading, writing,
erasing to/from an EEPROM.
It also provides a service for comparing a data block in
the EEPROM with a data block in the memory (e.g.
RAM).
64
67. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
System Services on BSW
67
Module Name Description
ECU State Manager EcuM
The ECU State Manager performs the initialization/de-initialization of all
basic software modules, including the RTE and the operating system
(OS). The module controls the operating state of an ECU (Sleep,
Startup, Wakeup, Shutdown, and Run) based on system events.
Communication
Manager
ComM
This module controls the state of all communication channels connected to
the ECU and provides a bus-independent interface to the SWCs (and thereby
their application) for requesting external communication.
Function Inhibition
Manager FIM
This module controls (enable/disable) functionalities of SW components based on
the conditions such as faults, signal quality, ECU and vehicle states, diagnostic
tester commands, etc.
Diagnostic Event
Manager DeM
This module implements error memory as per manufacturer-
specific documentation. A standardized interface for diagnostic monitors allow
for uniform, cross-manufacturer development of software components. The
DEMs module is responsible for administrating the Diagnostic TroubleCode
statuses, the error environment data, and for storing the data in NVRAM.
68. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
System Services on BSW
68
Module Name Description
Development
Error Tracer (Det)
This module supports error searches during software development
and provides an interface for error reporting. This interface is called
from the individual BSW modules in an error situation.
BSW Scheduler
The SCHM module calls the cyclic function for the individual BSW
modules and makes available the functions that the BSW modules
need to call at the beginning and end of critical sections. This
Module is part of RTE (Runtime Environment in R4.0)
Watchdog Interface This module provides uniform access to services of the
watchdog driver (WDG), such as mode switching and
triggering.
Watchdog
Manager
The Watchdog Manager monitors the reliability and functional assurance of the
application in an ECU. This includes monitoring the correct execution of the
SWCs and BSW modules, and the triggering of Watchdog at the required time
intervals. Where resumption of normal operation is impossible, the Watchdog
hardware performs a reset of the microcontroller.
70. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
BSW Conclusion
70
The Microcontroller Abstraction Layer contains internal drivers, which
are software modules with direct access to the micro controller and
internal peripherals.
The ECU Abstraction Layer offers uniform access to all features of an
ECU like communication, memory or I/O, no matter if these features are
part of the microcontroller or realized by peripheral components. The
drivers for such external peripheral components reside in this layer.
The Service Layer provides various types of background services such as
vehicle network communication and management services, diagnostic
services, memory management, ECU state management, mode management
and Logical and temporal program flow monitoring. The operating system is
also part of this layer.
The RTE integrates the application layer with the BSW. It implements the data
exchange and controls the integration between the application software
component (SWCs) and BSW.
The Application Layer contains the SWCs, which realize the application
functionality of the ECU.
71. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Runtime Environment
The RTE is the layer between the application layer
and the BSW layer. It provides the application
software with services from the service layer.
All communication between SWCs, either on
the same ECU or different ones, or services are
done via the RTE.
The main task of the RTE is to make the layer
above and below it completely independent of each
other.
In other words, SWCs running on an ECU have no
idea what the ECU looks like hence a SWC will be
able to run on different looking ECUs without any
modifications
Logically the RTE can be seen as two sub-parts
realizing different SWC functionality:
Communication
Scheduling
71
Source: www.autosar.org
72. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Virtual Function Bus
72
It provides generic communication services
that can be consumed by any existing
AUTOSAR software component.
Although any of these services are virtual,
they will then in a later development phase be
mapped to actual implemented methods, that
are specific for the underlying hardware
infrastructure.
In virtual speciation of the communication
topology and interaction between components
which is done via the virtual function bus,
the runtime environment provides an actual
implementation for these artifacts.
It could also be said that the runtime environment
provides an actual representation of the virtual
concepts of the VFB for one specific ECU.
73. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Example VFB to RTE mapping where the virtual communication topology is
mapped to three different ECU's
73
Source: www.autosar.org
Each ECU has its own customized RTE
implementation which is generated
during the ECU Configuration process
.
The Depending on the location of each
component, the formerly virtual interaction
can then be mapped to real interaction
implementation.
components that are mapped onto one
ECU will communicate through Intra
ECU-Mechanisms, like function calls
while Inter-ECU communication will be
realized using, e.g. a communication bus
infrastructure.
80. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Mapping of Runnable Entities and Basic Software Schedulable
Entities to tasks (informative)
The RTE-Configurator uses parts
of the ECU Configuration of
other BSW Modules, e.g. the
mapping of RunnableEntitys to
OsTasks. In this configuration
process the RTE-Configurator
expects OS objects (e.g. Tasks,
Events, Alarms...) which are used in
the generated RTE and Basic
Software Scheduler.
80
Source: www.autosar.org
84. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemRTE Implementation Example 1:
Without OsEvent
Description of the example:
RunnableEntity RE1 is activated by TimingEvent 100ms T1.
RunnableEntity RE2 is activated by TimingEvent 100ms T2.
RunnableEntity RE3 is activated by TimingEvent 100ms T3.
Execution order of the RunnableEntitys shall be R1, R2 then R3. RE2 shall be monitored.
Possible RTE configuration:
RE1/T1 is mapped to OsTask TaskA with RtePositionInTask equal to 1.
RE2/T2 is mapped to OsTask TaskB but virtually mapped to TaskA with RtePositionInTask equal to 2.
RE3/T3 is mapped to OsTask TaskA with RtePositionInTask equal to 3.
Possible RTE implementation: RTE starts cyclic OsAlarm with 100ms period. This OsAlarm is
configured to activate TaskA.
Non preemptive scheduling is configured for Task A.
TaskB priority = TaskA priority + 1
84
Source: www.autosar.org
85. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemRTE Implementation Example 2:
With OsEvent
Description of the example:
RunnableEntity RE1 is activated by DataReceivedEvent DR1.
RunnableEntity RE2 is activated by DataReceivedEvent DR2.
RunnableEntity RE3 is activated by DataReceivedEvent DR3. Evaluation order of the
RTEEvents shall be DR1, DR2 then DR3. All the runnables shall be monitored.
Possible RTE configuration:
RE1 is mapped to OsTask TaskB but virtually mapped to TaskA with a reference to OsEvent
EvtA and RtePositionInTask equal to 1.
RE2 is mapped to OsTask TaskC but virtually mapped to TaskA with a reference to OsEvent
EvtB and RtePositionInTask equal to 2.
RE3 is mapped to OsTask TaskD but virtually mapped to TaskA with a reference to OsEvent
EvtC and RtePositionInTask equal to 3.
Possible RTE implementation:
RTE set EvtA, EvtB and EvtC according to the callbacks from COM. Full preemptive
scheduling is configured for Task A.
TaskB priority = TaskC priority = TaskD priority = TaskA priority + 1
85
Source: www.autosar.org
99. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
What is Next ?
We will create a MCAL “(Microcontroller Abstraction Layer)” Drivers
For Atmega32 according to Autosar Specifications
99
MCAL (Microcontroller
Abstraction Layer)
MCAL is a software module that
directly accesses on-chip MCU
peripheral modules and external
devices that are mapped to memory,
and makes the upper software layer
independent of the MCU.
Details of the MCAL software module
are shown below.
120. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
https://www.autosar.org
Embedded Microcomputer Systems Real Time Interfacing Third
Edition Jonathan W. Valvano University of Texas at Austin.
MicroC/OS-II the real-time kernel second edition jean j.labrosse.
RTOS Concepts http://www.embeddedcraft.org.
OSEK/VDX Operating System Specification 2.2.3
AUTOSAR Layered Software Architecture
The Trampoline Handbook release 2.0
Trampoline (OSEK/VDX OS) Test Implementation -Version 1.0,
Florent PAVIN ; Jean-Luc BECHENNEC
120
122. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
Real Time Systems (RETSY)
Jean-Luc Béchennec - Jean-Luc.Bechennec@irccyn.ec-nantes.fr
Sébastien Faucou - Sebastien.Faucou@univ-nantes.fr
jeudi 12 novembre 15
AUTOSAR Specification of Operating System V5.0.0 R4.0 Rev 3
OSEK - Basics http://taisnotes.blogspot.com.eg/2016/07/osek-basic-
task-vs-extended-task.html
OSEK OS Session Speaker Deepak V.
M.S Ramaiah School of Advanced Studies - Bangalore 1
Introducción a OSEK-OS - El Sistema Operativo del CIAA-Firmware
Programación de Sistemas Embebidos
MSc. Ing. Mariano Cerdeiro
122
125. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
AUTOSAR Method, Vector Webinar 2013-04-17
https://vector.com/portal/medien/cmc/events/Webinars/2013/Vector_Web
inar_AUTOSAR_Method_20130417.pdf
AUTOSAR Configuration Process - How to handle 1000s of parameters
Vector Webinar 2013-04-19
https://vector.com/portal/medien/cmc/events/Webinars/2013/Vector_Web
inar_AUTOSAR_Configuration_Process_20130419_EN.pdf
AUTOSAR Runtime Environment and Virtual Function Bus, Nico Naumann
https://hpi.de/fileadmin/user_upload/fachgebiete/giese/Ausarbeitungen_A
UTOSAR0809/NicoNaumann_RTE_VFB.pdf
125
126. https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
The AUTOSAR Adaptive Platform for Connected and Autonomous
Vehicles, Simon Fürst, AUTOSAR Steering Committee 8th Vector
Congress 29-Nov-2016, Alte Stuttgarter Reithalle, Stuttgart,
Germany
https://vector.com/congress/files/presentations/VeCo16_06_29Nov_Re
ithalle_Fuerst_BMW.pdf
A Review of Embedded Automotive Protocols, Nicolas Navet1,
Françoise Simonot-Lion2 April 14, 2008
https://www.realtimeatwork.com/wp-
content/uploads/chapter4_CRC_2008.pdf
126