Made by

Eng. Mahmoud Helmy

• RTE (Run-Time Environment): an intermediary
between the application software and the lower
layers of the communication stack. It provides a
standardized interface for communication between
software components (runnable entities) running on
different ECUs.
• COM module: Packs signals from application into
PDUs
• PduR module: Routes PDUs to different
communication protocols
• CanTp module: Performs segmentation of large PDUs.
• CanIf module: Maps PDUs to their corresponding
specific Can IDs
• Can module: Access microcontroller registers to send
actual Can frame on physical bus.
2
Packet Data Unit (PDU)
• ECU sends messages over different networks (CAN , LIN , FlexRay ... ) these messages
called PDUs (Packet Data Unit).
• Every PDU has a unique identifier associated with it(PDU ID)

PDU = PCI + SDU

• Service Data Unit (SDU)
• It contains the data that needs to be transmitted from the sender ECU to the receiver ECU.
• The SDU represents the information being exchanged between the software components within
the ECUs.

• Protocol Control Information (PCI)

• PCI contains the information which indicates the next destination of the SDU. It contains the
source and destination of the SDU. The source and destination in this case is the next layer to 3

which the PDU needs to be passed.

• While transmission, SDU is passed from upper layers to lower layers along with PCI.
• While reception, SDU is the data extracted from below layers and passed on to upper
layers.
• The PDUs are named as:
▪ I-PDU (Interaction Layer PDU): Whenever the PDU is in layers above Communication
Hardware Abstraction layer then it is called I-PDU.
▪ N-PDU (Network Layer PDU): Whenever the PDU is in layers below PDUR and above
Communication Drivers layer then its called N-PDU.
▪ L-PDU (Data Link Layer PDU): Whenever the PDU is below Communication Hardware
Abstraction then it is called L-PDU.

4
• Signal
• Signals are the smallest entities for the exchange of information, they
carry a single data value, such as a temperature reading, speed
measurement, or status information.
• Each PDU consists of different signals.

• Signal Groups
• When two or more signals must be transmitted with time coherent values
these signals shall be defined in one signal group.

5
• Configuration and configuration parameters
Configuration parameters
• the variability of the generic part(s) of an implementation of a module.
• The configuration of parameters can be achieved at different times during the software process: before
compile time, before link time or after build time (post build).

Variants
• describe sets of configuration parameters.
• E.g., variant 1: only pre-compile time configuration parameters; variant 2: mix of pre-compile- and post build
time configuration parameters.
• In one variant a parameter can only be of one configuration class.

6
• Configuration and configuration parameters
Containers
• structure the set of configuration parameters. This means:
• all configuration parameters are kept in containers.
• sub-containers can reference sub-containers.
• It is possible to assign a multiplicity to these references. The multiplicity then defines the possible number of
instances of the contained parameters.

7
Service Layer

ECU Abstraction Layer

MCAL

8
• Abstract Microcontroller registers.
• A transceiver is responsible for voltage regulation of the physical can
pins.
• The <Bus Trcv> component is responsible for controlling the
transceiver hardware.
• The <Bus Trcv> component provides an abstraction layer that enables
software components (SWCs) to control and configure the
transceiver's behavior.
• The CAN Hardware Unit combines one or several CAN controllers,
which may be located on-chip or as external standalone devices of
the same type, with common or separate Hardware Objects.

9
• The Can module provides services to control the state of the CAN controllers. Bus-off and Wake-up events are
notified by means of callback functions.
• The Can module shall implement the interrupt service routines for all CAN Hardware Unit interrupts that are
needed.
• The Can module shall disable all unused interrupts in the CAN controller.
• Each CAN controller must then be started separately by calling the function Can_SetControllerMode(CAN_T_START).
• The ECU State Manager module shall call Can_Init at most once during runtime.
• There are two possibilities for triggering state changes by external events:
a. Bus-off event
b. HW wakeup event
• These events are indicated either by an interrupt or by a status bit that is polled in the
Can_MainFunction_BusOff or Can_MainFunction_Wakeup.
10
• Define how many CAN Controllers to use ,Baud rate, Filter Masks, HW objects.
• Filter Masks: used to specify the acceptance criteria for incoming messages. They determine which
messages are received and processed by the ECU.
• The bus driver configuration also includes defining the hardware objects (BasicCAN or a FullCAN)
reception method/ transmission method of the referenced reception unit and to indicate a received L-
PDU to a target upper layer module.
• It includes defining the number of channels supported by the transceiver and how they are controlled.
• The configuration may specify whether the transceiver is controlled through digital input/output (DIO)
pins or controlled via a serial peripheral interface (SPI) or other communication protocols.

11
BasicCAN and FullCAN Reception
• A CAN mailbox (hardware object) for FullCAN operation only enables transmission or reception of single
CanIds.
• BasicCAN enables to transmit or receive a range of CanIds.

12
13
14
Abstract drivers’ access
▪ abstracts the low-level driver operations, allowing SWCs to access and control the hardware
drivers through a standardized interface.
Transmission Buffering
▪ It manages the transmission queue, ensuring that messages are sent in the correct order and
timing as per the bus protocol requirements.
▪ The component provides APIs to enqueue messages for transmission and handles the necessary
processing to transmit the buffered data when the bus resources are available.

15
Reception Indication
▪ provides mechanisms for handling reception indications or notifications of
incoming messages or data from the bus.
▪ It detects incoming messages and triggers appropriate actions to inform SWCs
about the received data. These indications can be in the form of callbacks or
events that notify SWCs about the availability of new data for processing.
Provide APIs for controller modes
▪ allow software components to switch between different controller modes such as
NORMAL operation mode, SLEEP mode, INIT mode..etc
Software filtering
select and process only specific messages of interest.
16
Data length check
▪ verifies the length of the transmitted or received data against the defined constraints or
requirements to ensure that the transmitted or received data matches the expected length
specified by the bus protocol or application.
▪ CAN up to 8 bytes per message.
▪ The CanIf shall provide a ControllerId, which abstracts from the different Controllers of the different
CanDrv instances. The range of the ControllerIds within the CanIf shall start with ‘0’. It shall be
configurable via CANIF_CTRL_ID and same methodology for CAN Transceiver.

17
• During the notification process the CanIf maps the original CAN controller or CAN transceiver parameter
from the Driver module to the CanSm. This mapping is done as the referenced CAN controller or CAN
transceiver parameters are configured with the abstracted CanIf parameters ControllerId or TransceiverId.

• the CanIf supports multiple physical CAN channels,

These must be distinguished by the CanSm for
network control. The CanIf API provides request and
read control for multiple underlying physical CAN
channels.

18
▪ Hardware Object term is used in relation to CAN bus.

▪ Hardware Object is a space in CAN controller RAM where

the PDU will sit.

▪ When the PDU is situated in CAN controller’s RAM it is called as

Hardware Object.

19
• Define Messages to be sent and received , their IDs , upper
layer, HW object reference
• The CanIf shall use two types of HOHs to enable access to
the CanDrv:
a. Hardware Transmit Handle (HTH)
b. Hardware Receive Handle (HRH)
• Hardware object handles (HOH) for transmission (HTH) and
for reception (HRH) represent an abstract reference to CAN
mailbox structure, that contains CAN related parameters
such as CanId, DLC and data. Based on the CAN hardware
buffer abstraction each hardware object is referenced in the
CanIf independent of the CAN hardware buffer layout.
20
• The HOH is used as a parameter in the calls of the CanDrv's
interface services and is provided by the CanDrv's
configuration and used by the CanDrv as identifier for
communication buffers of the CAN mailbox.
• The CanIf acts only as user of the Hardware object handle
but does not interpret it based on hardware specific
information.
• The CanIf therefore remains independent of hardware
• Each CanRxPduId shall be assigned to one or more HRH.

21
Transmit Request
• The CanIf’s transmit request function
CanIf_Transmit() is a common interface for
upper layers to transmit PDUs on the CAN
network.
• The upper communication layer modules initiate
the transmission only via the CAN Interface
module's services without direct access to the
CanDrv.

CanIf_Transmit():
• Check initialization status of the CanIf
• Identify CanDrv (only if multiple CanDrvs are used)
22
• Determine HTH for access to the CAN hardware transmit object
• Call Can_Write() of the CanDrv
Transmit Request
• The transmission is successfully completed,
if the transmit request service
CanIf_Transmit() returns E_OK

23
Transmit Confirmation
• If a previous transmit request is completed successfully, the CanDrv notifies it to the CanIf by the call of
CanIf_TxConfirmation()

24
Reception Indication
• In case of a new reception of an L-PDU the CanDrv calls CanIf_RxIndication() of the CanIf.
• The access to the L-PDU specific data is organized by these parameters:
a. Hardware Receive Handle (HRH)
b. Received CAN Identifier (CanId)
c. Received Data Length Code (DLC)
d. Reference to the received L-SDU
• CanIf performs the following steps at a call of CanIf_RxIndication():
a. Software Filtering (only BasicCAN), if configured
b. DLC check, if configured
c. buffer received L-PDU if configured
d. call upper layer receive indication callback service, if configured
25
Reception Indication

26
• The CanTp module offers services for segmentation of long messages – Tx ,
transmission with flow control, and reassembly of segmented messages – Rx.
• Its main purpose is to transmit and receive messages that may or may not fit
into a single CAN frame.
• Messages that do not fit into a single CAN frame are segmented into multiple
parts, such that each can be transmitted in a single CAN frame.

• Concurrent connection The CAN Transport Layer can manage several connections
simultaneously (e.g. a UDS and an OBD request can be received at the same time).
• PDU Padding: adding additional data to the transmitted PDUs to align them with specific
requirements, such as fixed PDU lengths or alignment rules imposed by higher-layer protocols.

27
28
• The CanTp module shall have two internal states,
CANTP_OFF and CANTP_ON.
• The CanTp module shall change to the internal state
CANTP_ON when the CanTp has been successfully
initialized with CanTp_Init().
• CanTp_Init() initialize all global variables of the module
and sets all transport protocol connections in a sub-
state of CANTP_ON in which neither segmented
transmission nor segmented reception are in progress
(Rx thread in state CANTP_RX_WAIT and Tx thread in
state CANTP_TX_WAIT).

29
• The following figure provides an example, to summarize the process of sending a frame, with a length of 50 bytes.

1: The PduR asks for the transmission of 50 data bytes.

2: The CanTp asks the PduR for the data by requesting
the buffer containing the payload data and the
CanTp send the First Frame.
3: The CanTp send the rest of payload data as
sequences of Consecutive Frames, 6 or 7 payload
data bytes are copied by the upper layer on each
CF.
4: The CanTp confirms transmission of the payload
data. 30
 31

Tx and Rx data flow

• All the necessary information (Channel number, Timing parameter …) is configured inside the CAN
Transport Layer module.
• Each N-SDU is statically linked to one connection channel. This connection channel represents an
internal path, for the transmission or receiving of the N-SDU. A connection channel is attached to one or
more N-SDU.
• Each connection channel is independent of the other connection channels. This means that a
connection channel uses its own resources, such as internal buffer, timer, or state machine.
• The CanTp module shall route the N-SDU through the correctly configured connection channel.
• The number of connection channels is not directly configurable. It will be determined by the
configuration tools during the configuration process, by analyzing the N-SDU/Channel routing table.

32
CanTp Channel
• A CanTp channel represents a logical connection between the transmitting and receiving entities.
• The main configurations for a CanTp channel include:
a. Channel ID: Each CanTp channel is identified by a unique ID.
b. Communication Type: Specifies whether the channel is used for transmitting (Tx) or receiving (Rx) data.
c. Addressing Format: Defines the addressing scheme used for identifying the N-SDU within the CanTp
channel.
d. Flow Control Type: Determines the flow control mechanism for managing the transmission of N-PDUs.
e. Segmentation Type: Specifies the segmentation strategy used to split large N-SDUs into smaller N-PDUs
during transmission.
f. Block Size and Block Separation Time: Parameters defining the maximum number of consecutive N-PDUs
and the time gap between blocks during segmented transmission.

33
Timing Parameters
• Timing parameters are crucial for proper synchronization and timing control in the CanTp layer.
• Some common timing parameters for CAN TP include:
a. N_Cs (Separation Time): Used in segmented transmission to define the time gap between
consecutive blocks.
b. N_As (Assemble Time): Specifies the maximum time allowed for the CanTp layer to reassemble
received N-PDUs into the complete N-SDU.
c. N_Bs (Block Size Time): Determines the time allowed for the receiver to process each block of
segmented N-PDUs.
d. N_Ar (Acknowledge Time): Defines the maximum time allowed for the sender to receive an
acknowledgment (ACK) from the receiver after sending a block.
34
• The PDU Router module is an I-PDU transfer unit placed above
interface modules and transport protocol modules (lower layer
modules) and below COM and DCM (upper layer modules).
• Beside the PDU Router module is the I-PDU Multiplexer (IpduM)
module that provides support for multiplexed I-PDUs.

35
• From the ECU point of view, the PDU Router module can perform three different classes of operations:
1. PDU Reception to local module(s): receive I-PDUs from lower layer modules and forward them to
upper layer modules.
2. PDU Transmission from local module(s): transmit I-PDUs to lower layer modules on request of
upper layer modules.
3. PDU Gateway: PDU gatewaying in the PduR refers to the conversion or routing of PDUs between
different communication interfaces or protocols. It enables interoperability between different
modules or systems that may use different protocols or data formats.
• receive I-PDUs from an interface module and transmit the I-PDUs immediately via the same or
other communication interface module(s)
• receive I-PDUs from a transport protocol module and transmit the I-PDUs via the same or other
transport protocol module(s).
36
The COM module calls PduR_ComTransmit (here the
PDU Router module will list the I-PDU ID), the PDU Router
module will call CanIf_Transmit (here the CanIf
module configuration will list the I-PDU ID), the CanIf
will call PduR_CanIfTxConfirmation (here the PDU
Router module configuration will list the IPDU ID), and
PDU Router module will call Com_TxConfirmation
(here the COM module configuration will list the I-PDU
ID).

37
• The PDU Router module shall identify routing path uniquely by the combination of source
module I-PDU ID (located in the PDU Router configuration) and destination I-PDU IDs (located in
the called destination module configurations).
• Multicast
Multicast of I-PDU has the following restrictions:
• No update-bits can be used
• No sequence counters can be used
• If deadline monitoring is used, then all destinations must provide transmit confirmations.

38
• the source module and destination module for each PDU. This ensures that the PDUs are correctly routed
from the source module to the intended destination module.
• The configuration defines the mapping between the PDUs and the corresponding modules within the
communication stack.

39
IPduM is responsible for managing the transmission and reception of I-PDUs (Inter-Protocol Data Units) in a
communication system.

• The IpduM has to be considered as an upper layer module when it calls the PDU Router module to transmit
multiplexed IPDUs or when it is called by the PDU Router module for the reception or transmit confirmation
of multiplexed I-PDUs or to provide data via trigger transmit.
• The IpduM has to be considered as Lower layer module when it calls the PDU Router module to forward a
transmit confirmation or a receive indication to an upper layer (e.g. COM) or when it is called by the PDU
Router module to update an I-PDU belonging to a multiplexed I-PDU

40
▪ A multiplexed I-PDU consists of a static part and a dynamic part,
where the static part consists of zero or more signals or signal
groups. The dynamic part consists of the selector field and one or
more signals or signal groups.
▪ The dynamic part of an I-PDU is comparable with a union in “C”
▪ The selector field of one I-PDU shall have a configurable size between
one and eight contiguous bits.
▪ no other modules depend on it and that it is be possible to build a
system without the IpduM module if it is not needed.

41
42
• AUTOSAR COM is a module between the RTE and the PDU Router.
• AUTOSAR COM module provides functionalities such as:
• Packing signals given by upper layer via RTE to I-PDUs and providing them to the lower
layer for transition
• Unpacking received I-PDUs from lower layer and providing unpacked signals to upper
layer.
• Gateways received I-PDUs from lower layer and immediately sends them to the same or
another lower layer module(e.g. CAN-->CAN, CAN-->LIN)

43
Interfacing with RTE
• The Com Module interfaces with the Run-Time Environment (RTE) of the system.
• The RTE acts as an intermediary between the application software and the communication stack.
• The Com Module interacts with the RTE to exchange data and control information, enabling
seamless communication between the application layer and the lower layers of the communication
stack.

Packing/Unpacking of Signals
• The Com Module is responsible for the packing (serialization) and unpacking (deserialization) of
signals into/from Protocol Data Units (PDUs) for communication.
• It ensures that the signals from the application layer are properly formatted and encoded into PDUs
for transmission.
• On the receiving side, it extracts the signals from the received PDUs and delivers them to the
44
application layer.
Communication Protection for Rx and Tx (Replicated PDUs)
• The Com Module provides communication protection mechanisms for both receiving (Rx)
and transmitting (Tx) PDUs. These mechanisms include measures such as error detection,
error correction codes, or checksums to ensure data integrity.
• Replicated PDUs refer to the transmission of duplicate PDUs to increase the likelihood of
successful reception, thereby improving the reliability of communication.

Control transmission modes

• The Com Module supports different transmission modes that dictate the timing and behavior
of data transmission. Examples of transmission modes include cyclic, sporadic, event-
triggered, or request-response modes.
• Each mode specifies when and how data should be transmitted, allowing for optimized and
45
efficient communication based on the specific requirements of the system.
Deadline monitors

• Deadline monitors within the Com Module track and enforce the timing requirements for

data transmission.

• They ensure that PDUs are transmitted within their specified deadlines.

• If a deadline is missed, appropriate actions can be taken, such as error handling or reporting,

to maintain the timeliness of communication.

46
1. Transfer Property
a. TRIGGERED: In this transfer property, the I-PDU (Inter-Protocol Data Unit) is immediately

transmitted upon a trigger event, except if periodic transmission is defined for this I-PDU. This means

that whenever a trigger event occurs, the I-PDU is sent right away. For example, when a button is

pressed, a signal indicating the button press can be set to have a triggered transfer property,

causing immediate transmission of the corresponding I-PDU.

TRIGGERED assigned to an I-PDU with ComTxModeMode DIRECT or MIXED, the AUTOSAR COM module

shall immediately (within the next main function at the latest) initiate

ComTxModeNumberOfRepetitions plus one transmission of the assigned I-PDU.

47
1. Transfer Property
b. TRIGGERED ON CHANGE: This transfer property is like the triggered property, but it only triggers the
transmission of the I-PDU if there is a change in the signal value. For instance, if a temperature
sensor provides continuous temperature readings, the I-PDU associated with the temperature signal
can be set to have triggered-on-change transfer property, ensuring that the I-PDU is transmitted only
when the temperature value changes.
c. PENDING: With the pending transfer property, the transmission of the I-PDU is not triggered
immediately. It remains pending until explicitly triggered. This can be useful in scenarios where
multiple signals need to be collected and processed together before transmitting the corresponding
I-PDU. For example, in a vehicle's CAN bus system, multiple sensor readings may be collected and
processed before sending a comprehensive status report.

48
2. Transmission mode
Direct: In direct transmission mode, the I-PDU is

transmitted in the next main function after a trigger

event occurs. When signals received from RTE are stored

in I-PDU, DIRECT/N-Times method immediately sends

signals, as many as the number of transmission set, to the

lower modules. In this mode, upper modules can send

current signals in I-PDU at desired time. The following use

case is an example that COM sends three I-PDUs when

49
signals received from RTE.(Direct/N-Times = 3).
2. Transmission mode

50
2. Transmission mode
Periodic: In periodic transmission mode, the I-PDU is transmitted cyclically with a specified cycle time.

This mode ensures that the I-PDU is sent at regular intervals. For instance, in a real-time monitoring

system, a sensor's readings may need to be transmitted periodically with a defined cycle time, such as

every 100 milliseconds.

The following use case is an example to send I-PDU in periodic intervals(Tc time)

51
2. Transmission mode
Mixed: is a combination of DIRECT/N-Times and PERIODIC. In this mode, AUTOSAR COM module is

sending I-PDU periodically to the lower layer. But also, transmissions can be triggered at desired time.

The following use case is an example to send three I-PDUs when requested while AUTOSAR COM module

is sending I-PDU periodically(Periodic + Direct/N-Times = 3).

52
2. Transmission mode

None: the transmission of the I-PDU is triggered by lower layers in the communication stack.

The lower layers determine when and how the I-PDU should be transmitted. An example

would be when the lower layers handle the timing and synchronization of communication,

such as in a synchronized network protocol.

53
Signal Indication on reception (Unpacking of I-PDUs)

• In order to support both interrupt-driven and polled systems, it can be configured when the signal
indication takes place.
• There are two configurable signal indication modes IMMEDIATE and DEFERRED configurable via
ComIPduSignalProcessing.
▪ IMMEDIATE: AUTOSAR COM module immediately notifies RTE via configured ComNotifications for
the signals and signal groups included within the Com_RxIndication, or Com_TpRxIndication
function respectively, which are called by PduR(PDU Router, lower layer module) as an indication
of a reception of signals.
▪ DEFFERED: AUTOSAR COM module first copies the I-PDUs data given by PduR into COM, then
invokes the configured ComNotifications for the included signals and signal groups
asynchronously in the next call of Com_MainFunctionRx. 54
Signal Indication on reception (Unpacking of I-PDUs)

Immediate Unpacking

Deferred Unpacking

55
Minimum Delay Timer (MDT)
• The AUTOSAR COM module inherits the minimum delay timer mechanism and When an I-PDU is started, the

MDT eventually is re-initialized, depending on the Initialize parameter of Com_IpduGroupControl, Therefore,

the MDT can be violated by stopping and starting I-PDUs rapidly. The behavior of the transmission deadline

monitoring timer is not affected by any transmission delay caused by the minimum delay time supervision.

• No minimum delay time monitoring shall take place, if ComMinimumDelayTime is omitted or configured to 0

56
Signal Gatewaying
• the process of transferring and converting signals between different
communication protocols or interfaces within the module itself.
• The signal gateway is an integrated part of the AUTOSAR COM module.
• Any external modules, except the cyclic task call, cannot access the signal
gateway.
• The AUTOSAR COM module’s signal gateway works with (group) signals and
signal groups.
• The AUTOSAR COM module’s signal gateway supports only static routing for the
ComGwMapping configuration container.
• The COM module acts as a gateway or mediator to facilitate communication
between various components or systems that may use different protocols or
57
interfaces.
Update-bits

• By configuration on sender- and receiver-side, it is possible to add separately for each signal and/or

separately for each signal group at most one update-bit.

• The position of the update-bit is configurable by configuration parameter ComUpdateBitPosition.

• The value of Update-bit = 0(cleared) means the data has NOT been updated.

• The value of Update-bit = 1(set) means the data has been updated.

❑ Update bits on sender side

• When the RTE updates the value of signal or signal group with Com_SendSignal and Com_Send_SignalGroup

respectively, AUTOSAR COM module sets the update-bit of this signal or signal group.
58
Update-bits

• The timing of clearance of Update-bits can be configured to be either

▪ After the I-PDU was sent out via PduR_ComTransmit and PduR_ComTransmit returned E_OK.

▪ After the I-PDU was sent out via PduR_ComTransmit, PduR_ComTransmit returned E_OK and the

I-PDU was successfully confirmed.

▪ After the contents of this I-PDU was successfully requested by Com_TriggerTransmit.

❑ Update bits on receiver side

• If a signal or signal group with an update bit is received, the AUTOSAR COM module only processes

this signal(e.g. filter, notification, signal based gateway, byte swapping), if the signal’s update bit is
59
set, otherwise, it discards the signal or signal group.
❑ Initialization of COM

▪ AUTOSAR COM module initializes each I-PDU during execution of Com_Init.

▪ Com_Init initializes all internal data that is not yet initialized by the start-up code (e.g. C-structs).

▪ During initialization, AUTOSAR COM module fills unused areas within I-PDU with a value configured in

ComTxIPduUnusedAreasDefault (e.g. 0xFF) and initializes each signals on sender and receiver side with a

value configured in ComSignalInitValue.

▪ During an initialization, update-bits are to be cleared.

▪ Com_Deinit function makes no communication via the AUTOSAR COM module possible, and all started I-PDU

groups stopped.
60
❑ Filtering of received signals and PDUs

Filter can be chosen from below filters for ComFilterAlgorithms :

▪ ALWAYS: No filter is performed so that the message always passes

▪ NEVER: The filter removes messages all the time

▪ MASKED_NEW_EQUALS_X: Pass messages whose masked value is equal to a specific value.

▪ MASKED_NEW_DIFFERS_X: Pass messages whose masked value is not equal to a specific value

▪ MASKED_NEW_DIFFERS_MASKED_OLD: Pass messages where the masked value has changed.

▪ NEW_IS_WITHIN: Pass a message if its value is within a predefined boundary.

▪ NEW_IS_OUTSIDE: Pass a message if its value is outside a predefined boundary.

61
▪ ONE_EVERY_N: Pass a message once in every N message occurrences
▪ The state machine within the "<Bus>SM" module handles the control and management of the CAN
controller and transceiver based on the requested mode of operation.
▪ Here are the different modes commonly associated with Can communication:
✓ Full Communication Mode: In this mode, the CAN controller and transceiver are configured for
normal operation, allowing the transmission and reception of CAN messages. The state machine
ensures that the necessary configurations and settings are applied to enable full communication
on the CAN bus.
✓ No Communication Mode: This mode disables the transmission and reception of CAN messages.
This mode is useful in scenarios where temporary suspension of CAN communication is required.
✓ Silent Communication Mode: In this mode, the CAN controller and transceiver remain active on
the CAN bus but do not actively transmit CAN messages. However, they can still receive and
process incoming CAN messages. 62
▪ The CanSM module is responsible for the control flow abstraction of CAN networks.
▪ It changes the communication modes of the configured CAN networks depending on the mode
requests from the ComM module.
▪ CanSM module uses the API of the CanIf module.
▪ The CanIf module is responsible for the control flow abstraction of the configured CAN Controllers
and CAN Transceivers (the data flow abstraction of the CanIf module is not relevant for the CanSM
module).
▪ Any change of the CAN Controller modes and CAN Transceiver modes will be notified by the CanIf
module to the CanSM module.
▪ Depending on this notifications and state of the CAN network state machine, which the CanSM
module shall implement for each configured CAN network, the CanSM module notifies the ComM
and the BswM. 63
64
▪ ComM module simplifies the resource management for the users, whereat users may be
runnable entities, SW-Cs, the BswM (e.g. SW-C request via BswM) or DCM (communication
needed to diagnostic purpose).
▪ The ComM module acts as a central coordinator, ensuring proper communication between different
nodes or ECUs (Electronic Control Units) in the system.
▪ A user should not have any knowledge about the hardware (e.g., on which channel to communicate).
▪ A user simply requests a "Communication Mode."
➔ Controlling of more than one communication bus channel of an ECU by implementing a channel
state machine for every channel
➔ A SWC can only request FULL_COM and NO_COM , SILENT_COM is internal to the ComM
➔ In FULL_COM , ComM shall allow transmission and reception on a requested physical channel, The
opposite in the NO_COM. 65
▪ The ComM shall provide three different Communication Modes. The highest Communication

Mode shall be COMM_FULL_COMMUNICATION. The lowest Communication Mode shall be

COMM_NO_COMMUNICATION.

▪ The Communication Mode COMM_SILENT_COMMUNICATION shall only be used for network

synchronization.

66
67
• The CAN Hardware Unit combines one or several CAN controllers, which may be located on-chip or as
external standalone devices of the same type, with common or separate Hardware Objects.
• A few CAN hardware units support the possibility to combine several CAN controllers by using the CAN
RAM, to extend the number of message objects for one CAN controller. These combined CAN
controllers are handled as one controller by the Can module.
• The Can module provides services to control the state of the CAN controllers. Bus-off and Wake-up
events are notified by means of callback functions.
• The Can module shall implement the interrupt service routines for all CAN Hardware Unit interrupts
that are needed.
• The Can module shall disable all unused interrupts in the CAN controller.
• The Can module shall reset the interrupt flag at the end of the ISR (if not done automatically by
hardware). 68
• Each CAN controller must then be started separately by calling the function
Can_SetControllerMode(CAN_T_START).
• The ECU State Manager module shall call Can_Init at most once during runtime.
• There are two possibilities for triggering state changes by external events:
▪ Bus-off event
▪ HW wakeup event
• These events are indicated either by an interrupt or by a status bit that is polled in the
Can_MainFunction_BusOff or Can_MainFunction_Wakeup.

69