Automotive embedded systems part7 v1

https://www.facebook.com/groups/embedded.system.KS/
Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Automotive Embedded
Systems part7
(Automotive Protocol “CAN”).
ENG.KEROLES SHENOUDA
1

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Overview
#Learn In Depth
it's time to wake up 
Learn In Depth 
2

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Overview
 CAN (Controller Area Network) is the most widely used in-vehicle
network. It is a serial communications protocol developed by Robert
 Controller Area Network is a fast serial bus designed to provide an efficient,
reliable and very economical link between sensors and actuators
 CAN connects the vehicle's electronic equipment
 In CAN communication, all partners are equal and are able to communicate at
any time. In case of conflicts (two speaking at the same time), arbitration is
used to ensure messages are understood.
 All nodes can send a message at any time, when two nodes are accessing the bus
together, arbitration decides who will continue
3

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Overview
 CAN has several mechanisms for error detection:
 checked that the CRC transmitted in the frame is identical to the CRC computed at the
receiver end.
 the structure of the frame is valid and that no bit-stung error occurred
 Each ECU which detects an error sends an "error flag“ that allows all the ECUs on the
bus to be aware of the transmission error.
4

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Overview
 The CAN communication protocol is a carrier-sense multiple-access
protocol with collision detection and arbitration on message priority
(CSMA/CD+AMP).
 CSMA means that each node on a bus must wait for a prescribed
period of inactivity before attempting to send a message
 CD+AMP means that collisions are resolved through a bit-wise
arbitration, based upon a preprogrammed priority of each message in
the identifier field of a message. The higher priority identifier always
wins bus access.
5

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Standard CAN or Extended CAN
 The first version of the CAN standards listed in Table 1, ISO 11519 (Low-Speed CAN)
is for applications up to 125 kbps with a standard 11-bit identifier.
 The second version, ISO 11898 (1993), also with 11-bit identifiers provides for
signaling rates from 125 kbps to 1 Mbps (Standard CAN Version 2.0A,)
 The more recent ISO 11898 (1995) introduces the extended 29-bit identifier (CAN
Version 2.0B)
 Note: The Standard CAN 11-bit identifier field provides for 2^11, or 2048 different
message identifiers
 while the Extended CAN 29-bit identifier provides for 229, or 537 million identifiers.
6

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Network
 ISO11898 describes the physical-layer implementation of CAN. This
specification describes a
 twisted-wire pair bus with 120-Ω line impedance, and differential signaling
at a rate up to 1 Mbps on a 40-meter bus with multipoint topology. Longer
bus lengths are expected to have slower.
7

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN BUS
 the transmission medium (CAN bus) consists
of two lines: CAN high line (CANH) and CAN
low line (CANL).
Twisting of the two lines reduces the
magnetic field effect(noise).
 termination resistors (simulation of the
electrical properties of the transmission
medium) prevents reflections in a high-speed
CAN network.
8

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Bus Levels
9

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Physical Layer
 What is the advantage of the two wire CAN communication?
 When twisted pair is used it has advantage for electromagnetic
emissions (EME)
10
Note: Low speed CAN not Covered here in this session

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Bit Rate / Bus Length
 1M bit/sec 40 meters (131 feet)
 500K bit/sec 100 meters (328 feet)
11
Bus lines
assumed to be
an electrical
medium
(e.g. twisted pair)
40 100 1000 10,000
CAN Bus Length [m]
0 10 200
1000
500
10
5
Bit Rate
[kbps]
20
50
200
100

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Bus arbitration
 If two messages are simultaneously
sent over the CAN bus, the bus
takes the “logical AND” of the
signal
 Hence, the messages identifiers
with the lowest binary number
gets the highest priority
 Every device listens on the channel
and backs off as and when it
notices a mismatch between the
bus’s bit and its identifier’s bit
12

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Bus arbitration
13

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Conclusion
14

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN (Controller Area Network)
 Multi-master protocol
 Broadcasting
 Asynchronous communication (Event Triggered)
 Serial communication technology
 Priority-based bit-wise arbitration
 Variable message priority based on 11-bit
(or extended 29 bit) packet identifier
 Originally developed by Robert Bosch for
automobile in-vehicle network in the 1980s
 For reliable data exchange between ECUs
 Robust in noisy environments
 Cost effective
 Automatic error detection
15

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Characteristics
 All messages are broadcast
 Any node is allowed to broadcast a message
 Each message contains an ID that identifies the source or content of
a message
 Each receiver decides to process or ignore each message
16

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Data Flow in CAN
Transmitting Node
MCU Firmware
Identifier [id_n]
Data [values_x]
CAN Peripheral
Tx Mail Box [id_n]
Data [values_x]
Rx Mail Box [id_c]
Rx Mail Box [id_b]
CAN Transceiver
Node Configured to
receive identifier
MCU Firmware
Identifier [id_n]
Data [values_x]
CAN Peripheral
Data [values_x]
CAN Transceiver
Rx Mail Box [id_c]
Rx Mail Box [id_b]
Rx Mail Box [id_n]
Node not Configured to
receive identifier
MCU Firmware
CAN Peripheral
CAN Transceiver
Rx Mail Box [id_d]
Rx Mail Box [id_b]
Rx Mail Box [id_c]
Rx Mail Box [id_a]
Data Frame is broadcast to the bus ][value ]id n_[ x_
17

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN and the 7-layer model
1. Physical Layer
2. Data Link Layer
3. Network Layer
4. Transport Layer
5. Session Layer
6. Presentation Layer
7. Application Layer
Standard CAN
implementation
Partially
implemented by
higher-level CAN
protocols
(CANOpen)
ISA/OSI Reference Model
Managed in
Hardware.
Dramatic Real-time
advantage to
System Design
18

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
1. Physical Layer
2. Data Link Layer
3. Network Layer
4. Transport Layer
5. Session Layer
Standard CAN
implementation
Partially
implemented by
higher-level CAN
protocols
(CANOpen)
Managed in
Hardware.
Dramatic Real-time
advantage to
System Design
19
Having the Data Link Layer
managed in hardware allows
for more CPU cycles available
for application management
and better real-time control
since time does not need to be
allotted for simple message
monitoring.

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
1. Physical Layer
2. Data Link Layer
3. Network Layer
4. Transport Layer
5. Session Layer
Standard CAN
implementation
Partially
implemented by
higher-level CAN
protocols
(CANOpen)
Managed in
Hardware.
Dramatic Real-time
advantage to
System Design
20
The standard CAN
implementation bypasses the
connection between the Data
Link layer and the Application
layer. The layers above the
Data Link Layer are
implemented in software
which as per definition are
called the Higher Layer
Protocol

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Communication Principle
 It operates at transfer rates up to 1 Megabit/sec (1 Mbps) in CAN 2.0B. This speed provides sufficient data-
communication bandwidth for many real-time control systems.
 The CAN protocol allows each CAN data frame to carry from zero to as many as eight bytes of user data per message, thus
accommodating a wide span of signaling requirements. If necessary, more data can be transmitted per message using a higher-layer segmentation protocol.
 Each node on a CAN network can have several buffers or message mailboxes.
On initialization, each mailbox is assigned an identifier that is either unique or is shared with certain other
nodes. Also, each node is individually configured as a transmitter or receiver. This approach offers considerable
flexibility in system design.
 messages are labeled by an identifier (ID) assigned one or more nodes on the network. All nodes receive the message and perform a filtering operation. That is,
each node executes an acceptance test on the identifier to determine if the message — and thus its content —
is relevant to that particular node.
Only the node(s) for which the message is relevant will process it. All others ignore the message.
The identifier has two more functions, as well. It contains data that specifies the priority of the message and it allows the
hardware to arbitrate for the bus.
 Every node on the bus validates every message. Corrupted messages aren’t validated, of course, and that
situation triggers automatic re-transmissions.
21

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Communication Principle 22

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Frame Types
 A data frame can transport a
maximum payload of eight bytes
 the generator ECU of relevant
information takes the initiative in
sending data frames, there also is
the remote frame
 a remote frame has the same structure
as a data frame.
 The error frame is available to
indicate errors detected during
communication
 Overload Frame
 – Sent by a node to request a delay in
transmission
23

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Standard data frame
24

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 Start of Frame – 1-bit
 Arbitration Field – 11-bits/29-bits
 Control Field – 6 bits (2 reserved, 4 representing number of
Data Field bytes)
 Data Field – 0 to 8 BYTES
 CRC – 15-bits
 ACK Field – 1-bit/variable
 End of Frame – 7-bits (recessive)
Data Frame
S
O
F
1
Identifier
11/29
IDextend
1
RemReq
1
E
O
F
7+
Data
(Bytes)
0-8 bytes
C
R
C
15
A
C
K
1
Control
4
25

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Start Of Frame [SOF]
 SOF: CAN has a multi-master capability, meaning any node on the bus
can initiate communication to any node configured to receive. This is
done with a Start of Frame. A single dominant bit while the bus is idle
indicates a transmitting node is starting a frame.
All nodes on the bus will synchronize their bit timing to the leading
edge of SOF.
26

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Arbitration Field: ID, or identifier of
CAN 2.0B
 may be 11 or 29 bits long This is determined by FW at
initialization by setting the ID-extension bit (and then configuring
each can mailbox with a long ID instead of a standard). Extended
ID is less common but you need extended ID in case you have
more than 2032 IDs to differentiate.
 CAN has a multi-master capability meaning any node on the bus
can initiate communication to any other node. This is where the
Arbitration Field comes in...
27

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
28
• SRR—The substitute remote request (SRR) bit replaces the RTR bit in the standard
message location as a placeholder in the extended format.
• IDE—A recessive bit in the identifier extension (IDE) indicates that there are more identifier
bits to follow. The 18-bit extension follows IDE.
• r1—Following the RTR and r0 bits, an additional reserve bit has been included ahead of the
DLC bit.
Extended CAN
Standard CAN

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Arbitration Field: ID, or identifier of
CAN 2.0B
 identifier (ID) sets the priority of
the data frame, and together with
the acceptance filtering it provides
for sender-receiver relations in the
CAN network that are defined in the
communication matrix.
 RTR bit (Remote Transmission
Request). It is used by the sender to
inform receivers of the frame type
(data frame or remote frame)
 The IDE bit (Identifier Extension
bit) which follows serves to seprate
between standard format and
extended format.
29

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Control Field
 The Control Field consists of six bits
 - 1 are reserved
 - 4 are the Data Length Code which indicates number of data bytes in
the data field [0-8 bytes being valid sizes]
- DLC codes not shown in the figure are reserved
30

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Data
 This field carries the actual payload of the can-bus communication. It
may be 0 to 8 bytes long, as defined by the Data Length Code in the
Control Field. The most significant bit is transmitted first within each
byte.
31

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CRC “ checksum using a cyclic
redundancy check (CRC)”
 The CRC Field is sent by the transmitter and verified by all receivers. Each receiver
generates a CRC on the observed data frame and compares it with the transmitted CRC
check value. If it is they match, a dominant bit is put into the ACK slot. If the result is a
mismatch, nothing is transmitted by that node; instead, a ‘no’ vote is sent AFTER the
upcoming ACK delimiter, that is at End of Frame.
 .
32

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
each receiver steers
the acknowledgement,
independent of any
acceptance filtering
33

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
End Of Frame
 The ACK FIELD is two bits long and contains the ACK slot and the ACK delimiter. In the
ACK slot the transmitting station sends two recessive bits. Every receiver which has
received a valid message correctly, reports this to the transmitting node with a ’dominant’
bit during the ACK slot. Any node that disagrees, votes no after the delimiter by sending an
error flag.
 This is the last of the fields of the data frame. The End of Frame field provides the
necessary portion of idle between messages, for example for the transmitter to detect if a
node decided to send an error frame, which is allowed anytime.
 The End of Frame field consists of seven recessive bits.
34

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Can Framing
35

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Bus Traffic
36

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Remote Frame
37

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Remote Frame
 a frame type used to request data, i.e. data frames, from any CAN
node.
 Remote frames may be defined for all existing data frames in the
CAN network. It is only necessary to ensure that the identifiers of
the remote frames match those of the associated data frames. The
ECU responsible for generating the desired data frame responds to a
remote frame by sending it.
 In the case of a CAN controller with object storage, the CAN
controller automatically responds to a remote frame. CAN controllers
without object storage must let the host know about the remote
frame so that it can initiate a response.
38

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemThe CAN Tranceivers
CAN_Txd
CAN_Rxd
CAN
Controller
Differential
Transceiver
CAN_Txd
CAN_Rxd
Physical CAN Bus
(Differential, e.g Twisted Pair)
Physical CAN Bus
(Differential, e.g Twisted Pair)
39
• The role of the transceiver is
simply to drive and detect data
to and from the bus.
• It converts the single-ended logic
used by the controller to the
differential signal transmitted over
the bus. It
also determines the bus logic state
from the differential voltage, rejects
the common-mode
noise, and outputs a single-ended
logic signal to the controller

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Data Protection
40

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Error Detection
 Bit Monitoring
 Sender Task
 Compares every bit placed on the CAN bus with the actual bus level
 Discrepancy indicates a bit monitoring error and results in error handling
41

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Error Detection
 Stuff Check
 Receiver Task
 Compares arriving bit stream for a sequence of six homogeneous bits.
 Detection of a sixth homogeneous bit indicates bit stuffing error and results in
error handling
42

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 From Check
 Receiver Task
 Comparison of the arriving bit stream with the message format
 Detection of a dominant delimiter bit (CRC delimiter, ACK delimiter) or a
dominant bit within EOF indicates a format error and results in error
handling
43

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 Cyclic Redundancy Check
 Receiver Task
 Utilizes the arriving bit stream and generator polynomial for the Cyclic
Redundancy Check defined in ISO 11898-1
 Detection of a CRC error results in error handling
44

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
 ACK Check
 Sender Task
 Acknowledge error (ACK error) is detected if the recessive level placed by
the sender is not overwritten
 Detection of an ACK error results in error handling
45

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN Communication Stack
46

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CAN communication
stack
 The purpose of the CAN
communication stack is to
accommodate a complete CAN
communication interface for the
Application Layer. This means
that SWC’s need to pay no
regard to identifiers, data
lengths, bit timing and so on,
this is all handled by the
communication stack.
47

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Protocol Data Unit
 Protocol Data Unit (PDU) is a term which
describes the data of a specific communication
protocol.
 Signals sent in a CAN communication stack are
grouped in CAN PDUs which in turn are mapped
to CAN frames
 These signal paths of the PDUs are routed
between different modules of he CAN
communication stack
 The signal paths are routed from the COM
module, through the PDU router, to the CAN
interface, providing the COM module
48

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
COM
 The COM module is placed at the top of the CAN communication stack.
The COM module handles all of the signals going to and from the RTE,
as sender and receiver signals.
49

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
CANIF
 It abstracts the interface regardless
Location of the driver (internal/external).
 CANTP:
 - Segment and reassemble data
 Longer than 8 bytes.
 CAN Driver:
 Abstraction for the CAN controller hardware.
 CANSM:
 Change communication mode as requested.
 CANTRCV:
 Control external CAN transceiver hardware, It observe the bus and provide
physical network diagnostics.
50

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Seat heating system Example
51

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
SWC
 SeatHeatingController - This component is an application
SWC and the main component in the model. All decision-
making is performed by this component based on input
from the SeatSensor0, SeatSensor1 and HeatRegulator0.
Output is sent to the SeatHeater0 which changes the
heating element accordingly.
 SeatHeater - The SeatHeater SWC is controlling the
seat heating element. It is controlled by the
SeatHeatingController if the heating of the seat shall be
changed (Off, Low or High).
 SeatSensor - This component has the purpose of
detecting whether or not someone is sitting on the seat.
The status of the seat is sent to the
SeatHeatingController.
 HeatRegulator - The HeatRegulator component is keeping
track of the position of the physical seat heating
regulator dial. This position is used by the
SeatHeatingController in order to know if the heat should
be decreased, increased or remain the same..
52

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
All the Runnables contained by the
SWCs used in the system
53
Topology cases
Groups of SWCs

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Let us divided SWCs to the ECUs
54

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_systemCase 1 – All SWCs on the same
node
 In this case, all the available SWCs are mapped to
the same node. No communication with other nodes
means that only intra communication will be present
55

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Case 2 – One SeatSensor SWC
mapped to an additional node
56

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Case 3 – All groups separated
57

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Summary of cases
58

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Implementation of CAN modules
59

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
Prepare your self for the next session
(CAN-FD & TTCAN A&LIN)
#LEARN_IN_DEPTH 
60

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
61

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Trampoline:an open platform for (small) embedded systems based on
OSEK/VDX and AUTOSAR
http://trampoline.rts-software.org/
Jean-Luc Béchennec1;2, Sébastien Faucou1;3
1IRCCyN (Institute of Research in Communications and Cybernetics of Nantes)
2CNRS (National Center for Scientific Research) / 3University of Nantes
10th Libre Software Meeting
62

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
63

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Introduction to AUTOSAR, Stephen Waldron, Vector webinar
Wednesday 7th May 2014
https://vector.com/portal/medien/cmc/events/Webinars/2014/Vector_
Webinar_AUTOSAR_Introduction_20140507_EN.pdf
 Introduction to AUTOSAR, Stephen Waldron, Vector webinar
Tuesday 5th May 2015
https://vector.com/portal/medien/cmc/events/Webinars/2015/Vector_
Webinar_AUTOSAR_Introduction_20150505_EN.pdf
64

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Automatic Generation of AUTOSAR Software Component Descriptions
Study Thesis in Computer Sciences by Christopher Mutschler
https://www2.informatik.uni-
erlangen.de/EN/teaching/thesis/download/i2S00428.pdf
 AutoSAR Overview FESA Workshop at KTH 2010‐04‐12
 Prof. Jakob Axelsson
 http://www.artist-
embedded.org/docs/Events/2010/FESA/slides/3_Autosar_Axelsson.pdf
65

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 AUTOSAR – An open standardized software architecture for the
automotive industry Simon Fürst, BMW 1st AUTOSAR Open
Conference & 8th AUTOSAR Premium Member Conference October
23rd, 2008, Cobo Center, Detroit, MI, USA
 http://st.inf.tu-
dresden.de/files/teaching/ws08/ase/03_AUTOSAR_Tutorial.pdf
 Institutionen för systemteknik Department of Electrical Engineering
Examensarbete Implementation of CAN Communication Stack in
AUTOSAR Examensarbete utfört i Datorteknik
vid Tekniska högskolan vid Linköpings universitet Av Johan Alexandersson
och Olle Nordin
http://liu.diva-portal.org/smash/get/diva2:822343/FULLTEXT01.pdf
66

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 Applying AUTOSAR in Practice Available Development Tools and
Migration Paths Master Thesis, Computer Science Authors: Jesper
Melin
http://www.idt.mdh.se/utbildning/exjobb/files/TR1171.pdf
Freescale AUTOSAR Software Overview.pdf
 Introduction to the Controller Area Network (CAN)
 CAN Learning From Vector
 https://elearning.vector.com/index.php?&wbt_ls_seite_id=490352&root=3
78422&seite=vl_can_introduction_en
67

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
68

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
69

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 AUTOSAR Adaptive Platform
https://vector.com/conference_india/files/presentations/Day1/3_AUTO
SAR%20Adaptive%20Platform.pdf
 CAN Bus Protocol
 By Abhinaw Tiwari CSE-12010330
 Basics of In-Vehicle Networking (IVN) Protocols
70

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
References
 http://www.autosar.org/about/technical-overview/ecu-software-
architecture/autosar-basic-software/
 http://www.autosar.org/standards/classic-platform/
 https://automotivetechis.files.wordpress.com/2012/05/communicationsta
ck_gosda.pdf
 https://automotivetechis.files.wordpress.com/2012/05/autosar_ppt.pdf
 https://automotivetechis.wordpress.com/autosar-concepts/
 https://automotivetechis.files.wordpress.com/2012/05/autosar_exp_laye
redsoftwarearchitecture.pdf
 http://www.slideshare.net/FarzadSadeghi1/autosar-software-component
 https://www.renesas.com/en-
us/solutions/automotive/technology/autosar/autosar-mcal.html
 https://github.com/parai/OpenSAR/blob/master/include/Std_Types.h
71

Follow us
Press
here
#LEARN_IN DEPTH
#Be_professional_in
embedded_system
72

Automotive embedded systems part7 v1

In this document

More Related Content

What's hot

Similar to Automotive embedded systems part7 v1

More from Keroles karam khalil

Recently uploaded

Automotive embedded systems part7 v1