TechnicalReference_Coms
MICROSAR COM
Technical Reference
CFG5
Version 5.05.00
Authors
Dominik Biber, Safiulla Shakir, Gunnar Meiss, Heiko
Hübler, Markus Bart, Anant Gupta, Büsra Bayrak
Status
Released
Technical Reference MICROSAR COM
Document Information
History
Author
Date
Version
Remarks
Safiulla Shakir
2012-02-21
1.00.00
> Adapted to Cfg5
Dominik Biber
Dominik Biber
2012-07-19
2.00.00
> Adapted to AUTOSAR 4.0.3
(ESCAN00058304)
Dominik Biber
2012-12-11
2.01.00
> Added new feature descriptions
> Invalidation Mechanism
(ESCAN00061795)
> Signal Reception Filtering
(ESCAN00061805)
> Signal Status Information
(ESCAN00061799)
Gunnar Meiss
2013-04-04
2.02.00
> AR4-325: Post-Build Loadable
(ESCAN00064360)
Dominik Biber
2013-04-12
2.02.00
> Added new feature Signal Gateway
(ESCAN00064081)
Adapted
> Critical Sections (ESCAN00065327)
Dominik Biber
2013-06-20
3.00.00
> Changed prototype description of
Callout Functions (ESCAN00068096)
Dominik Biber
2013-09-03
3.00.00
> Transmission Deadline Monitoring
(ESCAN00070185)
> Clarified transmission context of signals
and signal groups (ESCAN00070200)
> Updated limitations of Callout Functions
(ESCAN00067146)
> Support (ESCAN00070186)
> Added support for 0-Bit signals
(ESCAN00069728)
Heiko Hübler
2013-09-23
3.00.00
> Added following API descriptions
(ESCAN00070449):
> Com_TpTxConfirmation
> Com_CopyTxData
> Com_TpRxIndication
> Com_StartOfReception
> Com_CopyRxData
> Com_SendDynSignal
> Com_ReceiveDynSignal
Heiko Hübler
2013-10-02
3.00.00
> Added Chapter Large I-PDUs and
Dynamic length signals
© 2017 Vector Informatik GmbH
Version 5.05.00
2
based on template version 5.6.0
Technical Reference MICROSAR COM
(ESCAN00070449)
Heiko Hübler
2014-03-25
3.01.00
> Updated Com_ StartOfReception API
according to ASR4.1.2
(ESCAN00071922)
Heiko Hübler
2014-04-16
3.01.00
> ESCAN00075083: AR4-710: Support
IPDUGroup relevant API like as ASR3
API
> Com_IpduGroupStart
> Com_IpduGroupStop
> Com_EnableReceptionDM
> Com_DisableReceptionDM
Heiko Hübler
2014-04-25
3.01.00
> Added Chapter: Autosar 3 based I-Pdu
Group handling
Markus Bart
2014-06-18
3.01.00
> AR4-601: Support RfC #59936
(Request Handling)
Heiko Hübler
2014-06-27
3.01.00
> Added chapter 3.1.2 Signal Processing
Heiko Hübler
2014-06-27
3.01.01
> ESCAN00076544: The type of the
parameter "Result" of the APIs
Com_TpRxIndication and
Com_TpTxConfirmation mismatches
between TechRef and source
Heiko Hübler
2014-11-05
3.02.00
> ESCAN00079371: AR4-698: Post-Build
Selectable (Identity Manager)
Heiko Hübler
2015-05-11
3.03.00
> ESCAN00082938: FEAT-1047:
Gateway Rx signal timeout handling
without update bits [AR4-894]
Heiko Hübler
2015-05-20
3.03.01
> ESCAN00083061: The figure on page
11 is labelled twice.
Anant Gupta
2015-07-15
4.01.00
> ESCAN00084005: FEAT-77: COM
Based Transformer for
CONC_601_SenderReceiverSerializatio
n incl. E2EXf [AR4-829]
Anant Gupta
2015-12-07
5.00.00
> ESCAN00085557: FEAT-1436
Gateway: Optimization for COM.
> ESCAN00087097: FEAT-1442
Gateway: Routing timeout behaviour
Gunnar Meiss
2016-02-25
5.01.00
> ESCAN00088555: FEAT-1631: Trigger
Transmit API with SduLength In/Out
according to ASR4.2.2
Gunnar Meiss
2016-06-05
5.02.00
> ESCAN00090302: FEAT-1688:
Anant Gupta
SafeBSW Step 4
Büsra Bayrak
2016-07-13
5.03.00
> ESCAN00090995: FEAT-1818:
ComEnableMDTForCyclicTransmission
Anant Gupta
2016-07-13
5.03.00
> ESCAN00091008: FEAT-1640:
© 2017 Vector Informatik GmbH
Version 5.05.00
3
based on template version 5.6.0
Technical Reference MICROSAR COM
> Notification caching and ISR Lock
Thresholds
Anant Gupta
2016-07-26
5.03.00
> ESCAN00091171: Missing description
of Com_Cot.h
Anant Gupta
2016-08-10
5.03.01
> ESCAN00091398: Update API
description.
Büsra Bayrak
2016-09-28
5.04.00
> ESCAN00092101: FEAT-2002: Support
64 Bit Signal Types for COM according
to ASR 4.2.2
Anant Gupta
2016-10-26
5.04.00
> ESCAN00092539: FEAT-1890:
Extension of gateway description
routing with shifted copy and update bit
support.
Heiko Hübler
2016-11-07
5.04.00
> ESCAN00092684: Tx Timeout for Cyclic
Messages misses in "Not Supported
AUTOSAR Standard Conform Features"
chapter
Büsra Bayrak
2016-12-09
5.05.00
> FEATC-793: FEAT-2231 Support
ComTxRepetitionCnt according to ASR
4.2.2
Anant Gupta
2017-01-17
5.05.00
> FEATC-797: FEAT-2333: Support Tx
Timeout for cyclic messages
Reference Documents
No.
Source
Title
Version
[1] AUTOSAR
AUTOSAR_SWS_COM.pdf
4.2.0
[2] AUTOSAR
AUTOSAR_SWS_DevelopmentErrorTracer.pdf
3.2.0
[3] AUTOSAR
AUTOSAR_TR_BSWModuleList.pdf
1.6.0
[4] Vector
TechnicalReference_Asr_Rte.pdf
3.90.00
[5] Vector
TechnicalReference_PostBuildLoadable.pdf
1.0.0
Caution
We have configured the programs in accordance with your specifications in the
questionnaire. Whereas the programs do support other configurations than the one
specified in your questionnaire, Vector´s release of the programs delivered to your
company is expressly restricted to the configuration you have specified in the
questionnaire.
© 2017 Vector Informatik GmbH
Version 5.05.00
4
based on template version 5.6.0
Technical Reference MICROSAR COM
Contents
1
Component History .................................................................................................... 11
2
Introduction................................................................................................................. 12
2.1
Architecture Overview ...................................................................................... 13
3
Functional Description ............................................................................................... 15
3.1
Features .......................................................................................................... 15
3.1.1
Signal Types .................................................................................... 16
3.1.2
Signal Processing ............................................................................ 17
3.1.3
Transmission of a Signal .................................................................. 17
3.1.4
Transmission of a Signal Group ....................................................... 19
3.1.5
Transmission Mode Selector ............................................................ 21
3.1.6
Explicit Transmission Mode State Switch ......................................... 21
3.1.7
Transmit Signal Filters ...................................................................... 22
3.1.8
Minimum Send Distance of an I-PDU ............................................... 23
3.1.9
Minimum Send Distance only for Direct Send Triggers ..................... 23
3.1.10
Transmission Deadline Monitoring ................................................... 24
3.1.11
Replication of Signal Transmission Requests ................................... 26
3.1.12
Reception of a Signal ....................................................................... 28
3.1.13
Reception of a Signal Group ............................................................ 28
3.1.14
Array-based access of SignalGroups ............................................... 29
3.1.15
Dynamic DLC ................................................................................... 30
3.1.16
Reception Deadline Monitoring ........................................................ 30
3.1.17
Invalidation Mechanism .................................................................... 31
3.1.18
Signal Reception Filtering ................................................................ 31
3.1.19
Signal Status Information ................................................................. 31
3.1.20
Signal Gateway ................................................................................ 32
3.1.20.1
Signal routing requirements ........................................... 32
3.1.20.2
Routing of signal groups ................................................ 32
3.1.20.3
Routing latency for normal Signal Gateway ................... 33
3.1.20.4
Gateway routing timeout ................................................ 33
3.1.21
Gateway Description Routing ........................................................... 33
3.1.22
Large I-PDUs ................................................................................... 34
3.1.23
Dynamic length signals .................................................................... 35
3.1.24
Com Optimizations ........................................................................... 35
3.1.24.1
Critical section threshold loop strategy ........................... 35
3.1.24.2
Rx Notification caching .................................................. 37
3.1.24.3
Deferred Event Caching ................................................. 37
© 2017 Vector Informatik GmbH
Version 5.05.00
5
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.24.4
Main Function Timing Domains ...................................... 38
3.1.24.4.1 Timebase for Rx-deadline monitoring
handling ..................................................... 39
3.1.24.4.2 Timebase for Tx-deadline monitoring
handling ..................................................... 39
3.1.24.4.3 Timebase for Tx-cyclic operations .............. 39
3.1.24.5
Handle ID ....................................................................... 39
3.1.24.6
Autosar 3 based I-Pdu Group handling .......................... 40
3.2
Initialization ...................................................................................................... 40
3.3
States .............................................................................................................. 41
3.3.1
Module States .................................................................................. 41
3.3.2
I-PDU States .................................................................................... 42
3.3.3
Reception Deadline Monitoring States ............................................. 43
3.4
Main Functions ................................................................................................ 44
3.5
Error Handling .................................................................................................. 45
3.5.1
Development Error Reporting ........................................................... 45
3.5.2
Production Code Error Reporting ..................................................... 46
4
Integration ................................................................................................................... 47
4.1
Scope of Delivery ............................................................................................. 47
4.1.1
Static Files ....................................................................................... 47
4.1.2
Dynamic Files .................................................................................. 47
4.2
Critical Sections ............................................................................................... 49
5
API Description ........................................................................................................... 51
5.1
Type Definitions ............................................................................................... 51
5.2
Services provided by COM .............................................................................. 52
5.2.1
Com_Init .......................................................................................... 52
5.2.2
Com_InitMemory .............................................................................. 52
5.2.3
Com_DeInit ...................................................................................... 53
5.2.4
Com_IpduGroupControl ................................................................... 53
5.2.5
Com_ReceptionDMControl .............................................................. 54
5.2.6
Com_IpduGroupStart ....................................................................... 54
5.2.7
Com_IpduGroupStop ....................................................................... 55
5.2.8
Com_EnableReceptionDM ............................................................... 56
5.2.9
Com_DisableReceptionDM .............................................................. 56
5.2.10
Com_GetConfigurationId ................................................................. 57
5.2.11
Com_GetStatus ............................................................................... 57
5.2.12
Com_GetVersionInfo ........................................................................ 58
5.2.13
Com_TriggerIPDUSend ................................................................... 58
5.2.14
Com_TriggerIPDUSendWithMetaData ............................................. 59
5.2.15
Com_ClearIpduGroupVector ............................................................ 59
© 2017 Vector Informatik GmbH
Version 5.05.00
6
based on template version 5.6.0
Technical Reference MICROSAR COM
5.2.16
Com_SetIpduGroup ......................................................................... 60
5.2.17
Com_ReceiveDynSignal .................................................................. 60
5.2.18
Com_ReceiveSignalGroup ............................................................... 61
5.2.19
Com_ReceiveSignalGroupArray ...................................................... 62
5.2.20
Com_InvalidateSignal ...................................................................... 62
5.2.21
Com_InvalidateSignalGroup ............................................................ 63
5.2.22
Com_SwitchIpduTxMode ................................................................. 63
5.2.23
Com_SendDynSignal ....................................................................... 64
5.2.24
Com_SendSignal ............................................................................. 64
5.2.25
Com_SendSignalGroup ................................................................... 65
5.2.26
Com_SendSignalGroupArray ........................................................... 66
5.2.27
Com_MainFunctionRx ...................................................................... 66
5.2.28
Com_MainFunctionTx ...................................................................... 67
5.2.29
Com_MainFunctionRouteSignals ..................................................... 67
5.2.30
Com_ReceiveSignal......................................................................... 68
5.2.31
Com_ReceiveShadowSignal ............................................................ 68
5.2.32
Com_UpdateShadowSignal ............................................................. 69
5.2.33
Com_InvalidateShadowSignal ......................................................... 69
5.3
Services used by COM .................................................................................... 70
5.4
Callback Functions ........................................................................................... 70
5.4.1
Com_RxIndication ............................................................................ 70
5.4.2
Com_TxConfirmation ....................................................................... 71
5.4.3
Com_TriggerTransmit ...................................................................... 71
5.4.4
Com_TpTxConfirmation ................................................................... 72
5.4.5
Com_CopyTxData ........................................................................... 73
5.4.6
Com_TpRxIndication ........................................................................ 73
5.4.7
Com_StartOfReception .................................................................... 74
5.4.8
Com_CopyRxData ........................................................................... 75
5.5
Configurable Interfaces .................................................................................... 75
5.5.1
Notifications ..................................................................................... 75
5.5.1.1
Indication Notification ..................................................... 75
5.5.1.2
Confirmation Notification ................................................ 76
5.5.1.3
Rx Timeout Notification .................................................. 76
5.5.1.4
Tx Timeout Notification .................................................. 77
5.5.1.5
Error Notification ............................................................ 77
5.5.1.6
Invalid Notification .......................................................... 78
5.5.2
Callout Functions ............................................................................. 78
5.5.2.1
Rx I-Pdu callout function ................................................ 78
5.5.2.2
Tx I-Pdu callout function ................................................ 80
6
Configuration .............................................................................................................. 82
© 2017 Vector Informatik GmbH
Version 5.05.00
7
based on template version 5.6.0
Technical Reference MICROSAR COM
6.1
Configuration of Post-Build .............................................................................. 82
7
AUTOSAR Standard Compliance............................................................................... 83
7.1
Limitations........................................................................................................ 83
8
Glossary and Abbreviations ...................................................................................... 84
8.1
Glossary .......................................................................................................... 84
8.2
Abbreviations ................................................................................................... 84
9
Contact ........................................................................................................................ 85
© 2017 Vector Informatik GmbH
Version 5.05.00
8
based on template version 5.6.0
Technical Reference MICROSAR COM
Illustrations
Figure 2-1
AUTOSAR 4.x Architecture Overview ....................................................... 13
Figure 2-2
Interfaces to adjacent modules of the COM .............................................. 14
Figure 3-1
Periodic Transmission Mode ..................................................................... 18
Figure 3-2
Direct Transmission Mode ........................................................................ 18
Figure 3-3
Minimum Delay Time ................................................................................ 23
Figure 3-4
Minimum Delay Time with ComEnableMDTForCyclicTransmission ==
false .......................................................................................................... 24
Figure 3-5
Transmission Deadline Monitoring – Normal Mode ................................... 25
Figure 3-6
Transmission Deadline Monitoring – None Mode ...................................... 25
Figure 3-7
Replication of Signal Transmission Requests for n = 2 repetitions ............ 26
Figure 3-8
Reception of a periodic signal ................................................................... 28
Figure 3-9
Signal routing allows routing of individual signals ..................................... 32
Figure 3-10
Main Function Timing Domains ................................................................. 38
Figure 3-11
Module State Machine .............................................................................. 41
Figure 3-12
I-PDU State Machine ................................................................................ 42
Figure 3-13
Reception Deadline Monitoring State Machine ......................................... 43
Tables
Table 1-1
Component history.................................................................................... 11
Table 3-1
Supported AUTOSAR standard conform features ..................................... 15
Table 3-2
Not supported AUTOSAR standard conform features ............................... 16
Table 3-3
Gateway mapping processing context ...................................................... 34
Table 3-4
Configurable Thresholds ........................................................................... 37
Table 3-5
Main functions that have to be called cyclically ......................................... 44
Table 3-6
Service IDs ............................................................................................... 46
Table 3-7
Errors reported to DET ............................................................................. 46
Table 4-1
Static files ................................................................................................. 47
Table 4-2
Generated files ......................................................................................... 48
Table 4-3
Overview of used Exclusive Area per Com API ......................................... 50
Table 5-1
Type definitions ......................................................................................... 51
Table 5-2
Com_Init ................................................................................................... 52
Table 5-3
Com_InitMemory ...................................................................................... 53
Table 5-4
Com_DeInit .............................................................................................. 53
Table 5-5
Com_IpduGroupControl ............................................................................ 54
Table 5-6
Com_ReceptionDMControl ....................................................................... 54
Table 5-7
Com_IpduGroupStart ................................................................................ 55
Table 5-8
Com_IpduGroupStop ................................................................................ 55
Table 5-9
Com_EnableReceptionDM ....................................................................... 56
Table 5-10
Com_DisableReceptionDM ....................................................................... 57
Table 5-11
Com_GetConfigurationId .......................................................................... 57
Table 5-12
Com_GetStatus ........................................................................................ 58
Table 5-13
Com_GetVersionInfo ................................................................................ 58
Table 5-14
Com_TriggerIPDUSend ............................................................................ 59
Table 5-15
Com_TriggerIPDUSendWithMetaData ...................................................... 59
Table 5-16
Com_ClearIpduGroupVector ..................................................................... 60
Table 5-17
Com_SetIpduGroup .................................................................................. 60
Table 5-18
Com_ReceiveDynSignal ........................................................................... 61
Table 5-19
Com_ReceiveSignalGroup ....................................................................... 62
Table 5-20
Com_ReceiveSignalGroupArray ............................................................... 62
Table 5-21
Com_InvalidateSignal ............................................................................... 63
© 2017 Vector Informatik GmbH
Version 5.05.00
9
based on template version 5.6.0
Technical Reference MICROSAR COM
Table 5-22
Com_InvalidateSignalGroup ..................................................................... 63
Table 5-23
Com_SwitchIpduTxMode .......................................................................... 64
Table 5-24
Com_SendDynSignal ............................................................................... 64
Table 5-25
Com_SendSignal ...................................................................................... 65
Table 5-26
Com_SendSignalGroup ............................................................................ 65
Table 5-27
Com_SendSignalGroupArray ................................................................... 66
Table 5-28
Com_MainFunctionRx .............................................................................. 67
Table 5-29
Com_MainFunctionTx ............................................................................... 67
Table 5-30
Com_MainFunctionRouteSignals .............................................................. 68
Table 5-31
Com_ReceiveSignal ................................................................................. 68
Table 5-32
Com_ReceiveShadowSignal .................................................................... 69
Table 5-33
Com_UpdateShadowSignal ...................................................................... 69
Table 5-34
Com_InvalidateShadowSignal .................................................................. 70
Table 5-35
Services used by the COM ....................................................................... 70
Table 5-36
Com_RxIndication .................................................................................... 71
Table 5-37
Com_TxConfirmation ................................................................................ 71
Table 5-38
Com_TriggerTransmit ............................................................................... 72
Table 5-39
Com_TpTxConfirmation ............................................................................ 72
Table 5-40
Com_CopyTxData .................................................................................... 73
Table 5-41
Com_TpRxIndication ................................................................................ 74
Table 5-42
Com_StartOfReception ............................................................................. 74
Table 5-43
Com_CopyRxData .................................................................................... 75
Table 5-44
Indication Notification ................................................................................ 76
Table 5-45
Confirmation Notification ........................................................................... 76
Table 5-46
Rx Timeout Notification ............................................................................. 77
Table 5-47
Tx Timeout Notification ............................................................................. 77
Table 5-48
Error Notification ....................................................................................... 78
Table 5-49
Invalid Notification .................................................................................... 78
Table 5-50
Rx I-PDU Callout with PduInfo pointer ...................................................... 79
Table 5-51
Rx I-PDU Callout with data pointer ........................................................... 79
Table 5-52
Tx I-PDU Callout with PduInfo pointer ...................................................... 80
Table 5-53
Tx I-PDU Callout with data pointer ............................................................ 81
Table 8-1
Glossary ................................................................................................... 84
Table 8-2
Abbreviations ............................................................................................ 84
© 2017 Vector Informatik GmbH
Version 5.05.00
10
based on template version 5.6.0
Technical Reference MICROSAR COM
1 Component History
The component history gives an overview over the important milestones that are
supported in the different versions of the component.
Component Version New Features
1.00
> Signal and Signal Group Access
> Notifications
> I-PDU Callout
> I-PDU Groups
> Transmission Modes
> Deferred and Immediate Signal Processing
2.00
> AUTOSAR 4.0.3 support
> Rx Deadline Monitoring
2.01
> Signal Invalidation Mechanism
> Signal Status Information (update bits)
> Signal Reception Filtering
2.02
> Post-Build Loadable
> Signal Gateway
3.00
> Tx Deadline Monitoring
> Dynamic DLC support
> Large (TP) Pdu support
> Dynamic Length Signal support
4.00
> Post-Build Selectable
7.00
> Signal Group Array Access
8.00
> Mainfunction Timing Domains
> Deferred Event Caching
> Description Routing
> Gateway Routing Timeout
9.00
> Safe BSW
10.00
> ComEnableMDTForCyclicTransmission
> Com Rx Indication Callouts
11.00
> Support Update Bits for Gateway Description Routing
> Support copying of unaligned bits from source to destination
description buffer.
> Support 64 Bit SignalType.
Table 1-1 Component history
© 2017 Vector Informatik GmbH
Version 5.05.00
11
based on template version 5.6.0
Technical Reference MICROSAR COM
2 Introduction
This document describes the functionality, API and configuration of the AUTOSAR BSW
module COM as specified in [1].
Supported AUTOSAR Release*:
4
Supported Configuration Variants:
PRE-COMPILE [SELECTABLE]
POST-BUILD-LOADABLE [SELECTABLE]
Vendor ID:
COM_VENDOR_ID
30 decimal
(= Vector-Informatik,
according to HIS)
Module ID:
COM_MODULE_ID
50 decimal
(according to ref. [3])
* For the precise AUTOSAR Release 4.x please see the release specific documentation.
The main purpose of the AUTOSAR BSW module Com is to provide a signal-based
interface to the upper layer. In an AUTOSAR based system it is the RTE. In a non-
AUTOSAR system it is the application.
It is possible to use the Com layer with different underlying bus systems since they are
encapsulated by the PDU Router. Architecture Overview shows how the component is
embedded in the AUTOSAR layered architecture.
The main features of the Com component are:
Provision of interface for signed and unsigned signals to the upper layer
Packing and unpacking of signals in I-PDUs
Handling of transmission modes
Minimum delay between I-PDUs transmissions
Communication control by starting and stopping of I-PDU groups
Rx deadline monitoring
Tx deadline monitoring
Notification mechanisms
Initial value support
Signal Gateway
The implementation is based on the AUTOSAR Com specification [1]. It is assumed that
the reader is familiar with this document and other related AUTOSAR specifications.
© 2017 Vector Informatik GmbH
Version 5.05.00
12
based on template version 5.6.0
Technical Reference MICROSAR COM
2.1
Architecture Overview
The following figure shows where the COM is located in the AUTOSAR architecture.
Figure 2-1 AUTOSAR 4.x Architecture Overview
© 2017 Vector Informatik GmbH
Version 5.05.00
13
based on template version 5.6.0
Technical Reference MICROSAR COM
The next figure shows the interfaces to adjacent modules of the COM. These interfaces
are described in chapter 5.
cmp Com Context View
«module»
Rte::Rte
«use»
«module»
«module»
«use»
Dem::Dem
ComM::ComM
Com
Rte_ComCbk
«use»
«realize»
«realize»
«mandatory»
«realize»
«module»
Com_Init
Dem_ReportErrorStatus
Com
«realize»
«optional»
Det_ReportError
Com_IpduGroup
«mandatory»
«realize»
A
«realize»
PduR_<User:Up>Transmit
Com_Cbk
«optional»
«realize»
«optional»
«module»
«module»
«module»
Det::Det
PduR::PduR
Bsw M::Bsw M
Figure 2-2 Interfaces to adjacent modules of the COM
Applications do not access the services of the BSW modules directly. They use the service
ports provided by the BSW modules via the RTE.
© 2017 Vector Informatik GmbH
Version 5.05.00
14
based on template version 5.6.0
Technical Reference MICROSAR COM
3 Functional Description
3.1
Features
The features listed in the following tables cover the complete functionality specified for the
COM.
The AUTOSAR standard functionality is specified in [1], the corresponding features are
listed in the tables
Table 3-1 Supported AUTOSAR standard conform features
Table 3-2 Not supported AUTOSAR standard conform features
The following features specified in [1] are supported:
Supported AUTOSAR Standard Conform Features
General functionality
Unpacking and packing of Signals and Signal Groups
Endianness conversion
Sign extension
Initialization and De-Initialization services
Signal invalidation mechanism
Signal status information (update bits)
Signal reception filtering
Signal Gateway
Large data types
Dynamic length signals
Communication Modes
Signal Transfer Property
I-PDU Transmission Mode
Selection of the Transmission Mode for one specific I-PDU
Replication of Signal Transmission Requests
Handling of I-PDUs
Starting and stopping of I-PDU groups
Minimum Delay Timer
Deadline Monitoring
Reception Deadline Monitoring
Transmission Deadline Monitoring
Callouts
I-PDU Callout
Table 3-1 Supported AUTOSAR standard conform features
© 2017 Vector Informatik GmbH
Version 5.05.00
15
based on template version 5.6.0
Technical Reference MICROSAR COM
The following features specified in [1] are not supported:
Not Supported AUTOSAR Standard Conform Features
General functionality
Float data types
Data sequence control
Communication protection
Table 3-2 Not supported AUTOSAR standard conform features
3.1.1
Signal Types
The following signal types are supported:
boolean
uint8
uint16
uint32
uint64
sint8
sint16
sint32
sint64
uint8[n]
For signed and unsigned integers an endianness conversion is supplied depending on the
endianness of the signal and the target system.
The support of signed signals is based on the B-complement.
The data type opaque is interpreted as an unsigned integer and no endianness conversion
is performed. The target system specific byte order is applied.
Caution
Only unsigned and signed integer values are supported. Float and the scaling
factors (as adjustable in the database) are not supported and have to be
interpreted by the application.
© 2017 Vector Informatik GmbH
Version 5.05.00
16
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.2
Signal Processing
Each Pdu has the parameter ComIPduSignalProcessing, this parameter can have the
value IMMEDIATE or DEFERRED.
> IMMEDIATE signal processing means that notification functions are called within
the functions Com_TxConfirmation() or Com_RxIndication().
o The transmission of a triggered signal with signal processing IMMEDIATE will
be triggered within the next call of the Com_MainFunctionTx().
> DEFERRED signal processing means that notification functions are called on task
level
during
the
next
call
cycle
of
Com_MainFunctionRx()
or
Com_MainFunctionTx().
o Values of signals contained in an I-PDU with signal processing DEFERRED
will be updated on task level in the Com_MainFunctionRx().
3.1.3
Transmission of a Signal
To request the transmission of a signal, the upper layer uses the API Com_SendSignal.
After performing optional parameter checks COM updates the I-PDU with the new signal
value and checks if the transfer property of the signal requires a direct transmission. If yes,
a flag is set which is evaluated later in the cyclic main function of the COM layer’s transmit
part.
Transmission modes of the I-PDU are handled in the Com_MainFunctionTx. This means
that the actual transmit request to the underlying layer is always decoupled from the upper
layer. In the transmission mode handler cyclic transmissions and direct transmissions are
processed.
In the following figure the transmission procedure is shown for I-PDUs with direct and
periodic transmission mode.
© 2017 Vector Informatik GmbH
Version 5.05.00
17
based on template version 5.6.0
Technical Reference MICROSAR COM
Periodic Transmission Mode
RTE
C
o
m
_
S
e
n
asynchronous
d
S
writing
ignal (5)
COM
Com_MainFunctionTx
t
Com_MainFunctionTx
Com_MainFunctionTx
IP
Com_MainFunctionTx
IP
D
Com_MainFunctionTx
Com_MainFunctionTx
Com_MainFunctionTx
D
U
U
(5)
PDU Router
COM_TRANSMISSION_
MODE_TIME_PERIOD
Figure 3-1 Periodic Transmission Mode
Direct Transmission Mode
RTE
C
C
C
o
o
o
m
m
m
_
_
_
S
lo
S
S
e
s
e
e
n
n
n
d
t
d
d
S
s
S
S
ig
i
i
g
g
ig
n
n
n
n
a
a
a
l
a
_
l_
l_
(
l
a
(b
(a
)
Com_MainFunctionTx
)
)
Com_MainFunctionTx
COM
t
Com_MainFunctionTx
Com_MainFunctionTx
Com_MainFunctionTx
Com_MainFunctionTx
IP
I
Com_MainFunctionTx
P
D
D
U
U
(
(
a
a
)
)
PDU Router
COM_IPDU_MINIMUM_DELAY_TIME
Figure 3-2 Direct Transmission Mode
The mixed transmission mode provides a combination of periodic and direct transmission
mode.
© 2017 Vector Informatik GmbH
Version 5.05.00
18
based on template version 5.6.0
Technical Reference MICROSAR COM
Note
Signal values are not queued by COM. If the upper layer updates signals with a higher
rate as the I-PDU of the signal is transmitted, only the most recent signal value is sent.
3.1.4
Transmission of a Signal Group
AUTOSAR COM provides signal groups to send several signals consistently. Signals
mapped to a signal group are called group signals and should be in relationship with each
other. To ensure the consistency of the group signal values, a shadow buffer is provided
for each signal group.
To request the transmission of a signal group with several group signals, following
sequence of API calls must be followed:
Example
/* Update the group signal values in the shadow buffer */
Com_SendSignal(GroupSignal1, &SigBuffer1);
Com_SendSignal(GroupSignal2, &SigBuffer2);
/* Copy the shadow buffer to the Tx buffer */
Com_SendSignalGroup(SignalGroupA);
For the transmission modes DIRECT or MIXED the evaluation of the transfer property is
handled as follows
ComSignalGroup.ComTransferProperty equals TRIGGERED
and all ComGroupSignal.ComTransferProperty equals PENDING
Com_SendSignal(ComGroupSignal) ->
Com_SendSignalGroup(ComSignalGroup) will trigger a transmission of the Tx
I-Pdu regardless of the group signal value.
ComSignalGroup.ComTransferProperty equals TRIGGERED_ON_CHANGE
and all ComGroupSignal.ComTransferProperty equals PENDING
Com_SendSignal(ComGroupSignal) ->
Com_SendSignalGroup(ComSignalGroup) will trigger a transmission of the Tx
I-Pdu if at least one group signal value has changed.
ComSignalGroup.ComTransferProperty equals PENDING
ComGroupSignal.ComTransferProperty equals TRIGGERED
© 2017 Vector Informatik GmbH
Version 5.05.00
19
based on template version 5.6.0
Technical Reference MICROSAR COM
Com_SendSignal(ComGroupSignal) ->
Com_SendSignalGroup(ComSignalGroup) will trigger a transmission of the Tx
I-Pdu regardless of the group signal value.
ComGroupSignal.ComTransferProperty equals TRIGGERED_ON_CHANGE
Com_SendSignal(ComGroupSignal) ->
Com_SendSignalGroup(ComSignalGroup) will trigger a transmission of the
Tx I-Pdu if the group signal value has changed.
ComGroupSignal.ComTransferProperty equals PENDING
Com_SendSignal(ComGroupSignal) ->
Com_SendSignalGroup(ComSignalGroup) will not trigger a transmission of
the Tx I-Pdu.
Caution
To guarantee data consistency of the whole signal group the complete transmission of
a signal group (consecutive calls of 'Com_SendSignal' and 'Com_SendSignalGroup')
must not be interrupted by another transmission request for the same signal group or
by a call of 'Com_InvalidateSignalGroup'.
© 2017 Vector Informatik GmbH
Version 5.05.00
20
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.5
Transmission Mode Selector
AUTOSAR COM allows configuring two different transmission modes for each I-PDU
(ComTxModeTrue and ComTxModeFalse). The transmission mode of an I-PDU that is
valid at a specific point in time is selected using only the filter states of the signals that are
mapped to this I-PDU.
If a filter of any signal mapped to a specific I-PDU evaluates to TRUE, this I-PDU is
transmitted with transmission mode TRUE. The transmission mode FALSE is used for an I-
PDU when the filters of all signals mapped to this I-PDU evaluate to FALSE.
If all signals mapped to a specific I-PDU have no filter assigned, the transmission mode
evaluates to TRUE and does never change.
The transmission mode is changed as a result of a call of Com_SendSignal or
Com_SendSignalGroup. The value of the signal or group signal that caused the change
is already transmitted with the new transmission mode.
By a transmission mode switch to the Direct/N-times transmission mode a direct/ n-times
transmission to the underlying layer, respecting the minimum delay time, will be initiated,
even if the transmission mode switch was triggered by a signal with PENDING transfer
property.
By a transmission mode switch to the Cyclic or Mixed transmission mode the new cycle
will start with a transmission request to the underlying layers respecting the minimum
delay time.
If the current transmission mode is configured to NONE, the COM will never initiate a
transmission to the underlying layer.
3.1.6
Explicit Transmission Mode State Switch
By calling the Com_SwitchIpduTxMode API the configured transmission modes can be
switched explicitly (TRUE/FALSE) per Tx I-PDU.
If the requested transmission mode is different to the currently active mode, the new
transmission mode is immediately active.
For a new transmission mode PERIODIC or MIXED, the transmission cycle starts with
a transmission request, respecting the minimum delay time, and the timer for the cycle
time is restarted.
For a new transmission mode DIRECT or NONE, no transmission of the Tx I-PDU is
triggered by the API call.
If the requested TMS is already active, the function call will silently be ignored.
By mixing the signal based TMS switch and explicit TMS switch by
Com_SwitchIpduTxMode for the same I-PDU, the signal based TMS switches the
manual set mode back, during a call to Com_SendSignal or Com_SendSignalGroup for
this Tx I-PDU.
© 2017 Vector Informatik GmbH
Version 5.05.00
21
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.7
Transmit Signal Filters
A signal filter can be optionally assigned to each transmit signal. The filter of a transmit
signal is only used for transmission mode selection but the value of a transmit signal is
never filtered out.
The following filters are supported:
F_Always (TRUE)
F_Never (FALSE)
F_MaskedNewDiffersMaskedOld ((new_value&mask) != (old_value&mask))
F_MaskedNewEqualsX ((new_value&mask) == x)
F_MaskedNewDiffersX ((new_value&mask) != x)
F_MaskedNewIsOutside ((new_value<min) || (max<new_value))
F_MaskedNewIsWithin ((min<=new_value) && (new_value<=max))
The values for mask, x, min and max can be configured for each filter.
© 2017 Vector Informatik GmbH
Version 5.05.00
22
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.8
Minimum Send Distance of an I-PDU
In the COM specification an optional mechanism is defined to achieve a delimitation of the
bus load, by introducing a minimum send distance for an I-PDU. This concept is also
handled in the Tx main function.
In the following figure an example for the mixed transmission mode is shown. Note that
due to the minimum send distance, cyclic transmissions can be delayed, however the base
cycle is not modified. Direct transmissions are drawn by solid red arrows.
Minimu
Min
m
imu
Delay Time
RTE
Co
m
_
S
e
n
d
Cycli
Cy
c se
cli
nd
S
ig
requ
req est
n
a
l()
COM
Com
Co _Mainfunctio
cti nTx()
P
Co
P
Co
P
Co
d
d
d
u
m
u
m
u
m
R
R
R
_
_
_
_
_
T
_
_
_
T
_
C
T
T
T
C
x
C
x
x
C
x
x
o
Co
o
Co
o
Co
m
m
m
T
n
T
n
T
n
ra
fir
ra
f
ir
ir
ra
fir
n
m
m
n
n
n
m
n
s
a
s
a
s
m
a
a
a
m
ti
m
ti
m
ti
it
o
o
it
it
it
o
it
()
n
()
n
()
n
()
()
()
()
()
PDU
PDU Route
Ro
r
ute
COM_
COM IPDU_
DU MINIMUM
INIMU _DEL
DE AY_TIME
Figure 3-3 Minimum Delay Time
The handling of the minimum send distance is based on the evaluation of the confirmation
by the underlying layer.
3.1.9
Minimum Send Distance only for Direct Send Triggers
If the parameter ComEnableMDTForCyclicTransmission is set to false, the Minimum Delay
Time will only be considered for event based transmissions, which can be initiated by
Com_InvalidateSignal(), Com_InvalidateSignalGroup(),
Com_SendSignal(), Com_SendSignalGroup(), Com_SendSignalGroupArray()
or Com_TriggerIPDUSend().
Figure 3-4 shows that cyclic transmissions do not wind up the Minimum Delay Time. An
event based transmission is directly triggered after a cyclic transmission although the
minimum delay has not elapsed. Right after, in comparison a second event based
transmission request is delayed by the configured Minimum Delay Time as the first event
based transmission has reloaded the delay counter.
© 2017 Vector Informatik GmbH
Version 5.05.00
23
based on template version 5.6.0
Technical Reference MICROSAR COM
Figure 3-4 Minimum Delay Time with ComEnableMDTForCyclicTransmission == false
3.1.10 Transmission Deadline Monitoring
For Tx I-PDUs a deadline monitoring mechanism is provided to detect failures in the
transmission mechanism of the lower layers.
Two different variants are supported:
Normal Mode: If the COM triggers the transmission of the I-PDU, the time between the
send request for the I-PDU and the next Tx confirmation (Com_TxConfirmation())
is observed. A send request for example is given by Com_SendSignal(),
Com_TriggerIPduSend() or cyclic triggers.
None Mode: For I-PDUs triggered by a schedule table of a bus interface (e.g. LIN
schedule table), the time between two consecutive Tx confirmations
(Com_TxConfirmation()) is observed. The “None Mode” is applied for Tx I-PDU
with both transmission modes configured to NONE. The timer is started whenever the
corresponding I-PDU Group of the I-PDU is started and reloaded on a transmission
confirmation. However, a trigger event for example given by Com_TriggerIPduSend()
also start’s the timer, if it’s not already running.
The transmission deadline monitoring for the “Normal Mode”, is illustrated in Figure 3-5.
Each time a signal or signal group is written, the timeout timer is started if it is not yet
running. If the timeout time (configuration parameter ComTimeout) is expired before the
next Tx confirmation is received, all configured timeout notification functions of the I-PDU
are called.
© 2017 Vector Informatik GmbH
Version 5.05.00
24
based on template version 5.6.0
Technical Reference MICROSAR COM
Figure 3-5 Transmission Deadline Monitoring – Normal Mode
In the “None Mode” the timeout timers are initially started by the start of the corresponding
I-PDU group and are restarted each time a Tx confirmation is received. Figure 3-6
illustrates this behavior.
Figure 3-6 Transmission Deadline Monitoring – None Mode
© 2017 Vector Informatik GmbH
Version 5.05.00
25
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.11 Replication of Signal Transmission Requests
The AUTOSAR COM provides an optional feature to replicate transmission requests to the
lower layer for one send request by an upper layer.
If the attribute ComTxModeNumberOfRepetitions is configured to a value ‘n’ greater than
‘0’ for a transmission mode DIRECT or MIXED, the COM triggers the transmission of the
Tx I-PDU cyclically with a configurable ComTxModeRepetitionPeriodFactor as long as ‘n
+ 1’ confirmations for this I-PDU are invoked after a send request by an upper layer.
Figure 3-7 illustrates this behavior exemplarily for ‘n = 2’ replications with a repetition
period factor ‘td’ configured to ‘2’.
Note
Under certain conditions, if the confirmation is invoked late, the number of messages
send out on the bus can differ from the configured number of repetition, as the
confirmations and not the transmission requests are counted.
Figure 3-7 Replication of Signal Transmission Requests for n = 2 repetitions
As the replications are an attribute of a Tx I-PDU, each send request of a mapped signal
or signal group with a transfer property ‘TRIGGERED’ or ‘TRIGGERED_ON_CHANGE’
provokes the replications of the Tx I-PDU.
To enable replication control per signal following transfer properties were introduced
‘TRIGGERED_WITHOUT_REPETITION’
‘TRIGGERED_ON_CHANGE_WITHOUT_REPETITION’
© 2017 Vector Informatik GmbH
Version 5.05.00
26
based on template version 5.6.0
Technical Reference MICROSAR COM
A send request for signals with these transfer properties does only initiate one single
transmission requests to the lower layer even if replications are configured for the
current transmission mode.
Note
> If a *-WITHOUT-REPETITION signal and a normal triggered signal are written at the
same time, the repetitions are triggered.
> If a *-WITHOUT-REPETITION signal is written while repetitions of a former send
request are processed, the outstanding transmission repetitions are not canceled
and an additional transmission is triggered.
© 2017 Vector Informatik GmbH
Version 5.05.00
27
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.12 Reception of a Signal
To receive a signal the upper layer uses the API Com_ReceiveSignal. This service
delivers the signal value which is contained in the latest I-PDU of the signal.
As the signal processing context depends on the configuration of the corresponding Rx I-
PDU, the latest signal value might not be available until the next call to
Com_MainfunctionRx.
The reception procedure of the signal is usually asynchronous to the reception of the I-
PDU. It is however possible to call Com_ReceiveSignal in the reception notification
callback.
Reception of a periodic signal
RTE
C
o
m
_
R
e
c
e
iv
asynchronous
e
S
reading
ignal (5)
COM
t
Com_MainFunctionRx
IP
Com_MainFunctionRx
IP
Com_MainFunctionRx
D
Com_MainFunctionRx
D
U
Com_MainFunctionRx
U
(5)
Com_MainFunctionRx
Com_MainFunctionRx
PDU Router
Figure 3-8 Reception of a periodic signal
A call to Com_ReceiveSignal always returns the last received signal value or the initial
value if a timeout occurred and the Rx Data Timeout Action is set to REPLACE, even if the
corresponding I-PDU group is stopped.
3.1.13 Reception of a Signal Group
AUTOSAR COM provides signal groups to receive several signals consistently. Signals
mapped to a signal group are called group signals and should be in relationship with each
other. To ensure the consistency of the group signal values a shadow buffer is provided for
each signal group.
As the signal processing context depends on the configuration of the corresponding Rx I-
PDU, the latest signal group value might not be available until the next call to
Com_MainfunctionRx.
To receive the values of a signal group with several group signals, following sequence of
API calls must be followed:
© 2017 Vector Informatik GmbH
Version 5.05.00
28
based on template version 5.6.0
Technical Reference MICROSAR COM
Example
/* Copy the Rx buffer to the shadow buffer */
Com_ReceiveSignalGroup(SignalGroupA);
/* Get the group signal values from the shadow buffer */
Com_ReceiveSignal(GroupSignal1, &SigBuffer1);
Com_ReceiveSignal(GroupSignal2, &SigBuffer2);
Caution
To guarantee data consistency of the whole signal group the complete reception of a
signal group (consecutive calls of 'Com_ReceiveSignalGroup' and
'Com_ReceiveSignal') must not be interrupted by another reception request for the
same signal group.
3.1.14 Array-based access of SignalGroups
An array-based access of SignalGroups represents an alternative to the aforementioned
approaches in 3.1.4 and 3.1.13 to access SignalGroups. Instead of treating all
GroupSignals individually, SignalGroups are accessed as serialized composite data. The
APIs Com_ReceiveSignalGroupArray and Com_SendSignalGroupArray are used to send
and receive the uint8-array based representation of the SignalGroup. Using this feature,
the overhead for packing and unpacking the GroupSignals individually vanishes and
further processing of the SignalGroup is left to the caller of the API. However, to permit fast
processing, following preconditions have to be fulfilled:
- Only fix-sized data types are supported.
- The SignalGroup must be byte-aligned within the containing I-PDU.
- All GroupSignals must be aligned consecutively within SignalGroup without leaving
gaps.
- Only ALWAYS and NEVER filters are supported for TMS.
To activate this feature, the global COM configuration switch
ComEnableSignalGroupArrayApi must be enabled. Further, only SignalGroups with
ComSignalGroupArrayAccess being activated are permitted for the array-based access.
© 2017 Vector Informatik GmbH
Version 5.05.00
29
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.15 Dynamic DLC
The COM evaluates the actual received DLC of the SDU given from the lower layer
interface to support the reception of Rx I-PDUs with a variable length.
Two cases are distinguished:
Actual received DLC is greater than or equal to the statically configured
Only the SDU payload data with the statically configured PDU length is processed.
Normal signal processing.
Actual received DLC is smaller than the statically configured
Only the SDU payload data with the actual received PDU length is processed.
Only completely received signals or signal groups are processed.
This affects:
Rx indication notifications
Rx Filter
Rx Invalidation
Signal routing
If a configured update-bit is not contained in the actual received payload, the signal is
processed as if the update-bit were set.
Note
If a signal or signal group is completely received depends on the following parameters:
> Bit position and length
> Endianness
> The position of all group signals of a signal group
3.1.16 Reception Deadline Monitoring
For Rx signals and signal groups, a deadline monitoring mechanism is provided to detect
failures of other ECUs.
The timeout time can be configured per signal and signal group, but only signals and
signal groups with a configured update-bit can be monitored separately. For signals and
signal group without a configured update-bit, an I-PDU based timeout is applied.
If a timeout occurs, it’s configurable whether the COM shall call a timeout notification and
additionally replaces the signal value with the configured initial value. If the Rx Timeout
value should differ the initial value, the parameter “Rx Data Timeout Substitution Value”
can be used to configure a Rx timeout substitution value.
The start of the timeout monitoring can be deferred by using the first timeout time to avoid
timeout events in the startup time of a network.
© 2017 Vector Informatik GmbH
Version 5.05.00
30
based on template version 5.6.0
Technical Reference MICROSAR COM
If no first timeout time is configured, the deadline monitoring is not started until the first
reception of the Rx I-PDU or a set update-bit. After the first reception, the normal timeout
time is monitored.
3.1.17 Invalidation Mechanism
On sender side an invalid value can be configured per signal and group signal which is set
by the COM invalidation APIs to indicate than no valid signal value can be provided by the
application.
For signal groups all group signals should be invalided at once, because the group signals
are related in a consistent manner. Thus, if one group signal is invalid, the whole signal
group is invalid.
On receiver side the COM checks the value of received signals and group signals against
the configured invalid value. If an invalid value is detected, the COM offers the following
actions:
The invalid value is replaced by the initial value of the signal and normal signal
processing takes place
A configured invalid notification is called and the invalid value is not stored in the
internal COM buffer
For signal groups, all group signals are checked against their invalid value. If at least
one group signal is invalid, the invalid action is performed for all group signals of the
signal group.
3.1.18 Signal Reception Filtering
A filter algorithm can be configured for Rx signals and group signals to filter out specific
signal values. If the filter algorithm is evaluated to FALSE, the complete signal processing
is inhibited. Thus the signal data is not stored in the internal COM buffer and a configured
notification function is not called.
For signal groups the signal processing is performed, if at least one configured filter
algorithm of any of the contained group signals is evaluated to TRUE. The signal group is
only filtered out, if all filter algorithms are evaluated to FALSE.
3.1.19 Signal Status Information
For signals and signal groups update-bits can be configured to indicate whether the signal
value has been updated by the application since the last transmission of the signal on the
bus.
On sender side the update-bit is set in the context of Com_SendSignal or
Com_SendSignalGroup. As the update-bit shall only be present on the BUS once after the
value is updated, the update-bit has to be cleared dependent on the send behavior of the
lower layer. As the COM shall be aware of the lower layer, the clear context of the update-
bit is configurable per Tx I-PDU.
If the lower layer copies the I-PDU payload in the transmit context, the update-bits shall be
cleared directly after the COM triggers the transmission of the I-PDU. In case the lower
layer requests the I-PDU payload decoupled by a call to Com_TriggerTransmit, the
update-bits shall be cleared in this context.
© 2017 Vector Informatik GmbH
Version 5.05.00
31
based on template version 5.6.0
Technical Reference MICROSAR COM
The receiving ECU checks the state of an update-bit associated to a signal or signal group
and inhibits the complete signal processing, if the update-bit is not set. In a well-functional
network, the update-bit should always be set if the signal value has changed. Otherwise
the sending ECU is defect.
3.1.20 Signal Gateway
The signal gateway allows routing of signals and signal groups from an Rx I-PDU to one or
several Tx I-PDU(s). To reduce interrupt runtime, signal routing is executed on task level
within Com_MainFunctionRouteSignals().
As signals can be accessed individually by COM, it is possible to change the signal layout
of I-PDUs while routing. Furthermore it is possible to change the byte alignment of the
routed signals and to specify any available transmission property for the Tx signal and I-
PDU.
Figure 3-9 Signal routing allows routing of individual signals
3.1.20.1 Signal routing requirements
In order to allow routing between two signals several requirements must be fulfilled
regarding the compatibility of the Rx and the Tx signal:
Application data type must be equal
Rx signal bit count must not be larger as the Tx signal bit count
When routing byte arrays (application data type is uint[8]) the byte count must be
equal
If a Tx signal is used in multiple routing relations (n(Rx):1(Tx) routing) the routing
relations must be exclusive at runtime to ensure data consistency.
3.1.20.2 Routing of signal groups
Signal groups are routed consistently from the Rx I-PDU to the Tx I-PDU. In order to allow
data consistency of the signals, it is required that all signals of the Tx signal group are
filled with signals of one Rx signal group. If this is not given, the signal group routing is not
possible.
It is not required that all signals of an Rx signal group are routed to a Tx signal group. This
allows routing an Rx signal group to a Tx signal group with less group signals.
© 2017 Vector Informatik GmbH
Version 5.05.00
32
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.20.3 Routing latency for normal Signal Gateway
The maximum routing latency is influenced by several factors and cannot be guaranteed
by COM. When estimating the routing latency, the following factors have to be taken into
account:
the cycle times of COM (main) functions
the minimum delay time of the Tx I-PDU
the Tx I-PDU transmission mode and cycle time
the Tx signal transfer mode and filter settings
delays caused by lower layers (such as bus access delay times)
other factors such as interrupt events that can delay routing execution
Example
Eliminating all these factors to the fastest possible configuration (minimum delay
time is zero, Tx I-PDU send mode is DIRECT, Tx signal transfer property is
‘TRIGGERED’, signal processing is immediate …) the maximum routing latency
is the sum of the following cycle times:
Call cycle of Com_MainFunctionRx(): If the signal processing of the Rx I-PDU
is configured to deferred, the routing event flag is evaluated deferred by this
main-function. For immediate signal processing the flag is evaluated in context of
Com_RxIndication().
Call cycle of Com_MainFunctionRouteSignals(): This task polls the routing
event flag. If the flag is set the signal is copied to the destination I-PDU and the
transmission request flag of the Tx I-PDU is set.
Call cycle of Com_MainFunctionTx(): This function is used to control the
transmission of I-PDUs. The function polls the transmission request flags and
triggers the I-PDU transmission by calling PduR_ComTransmit() of the related Tx
I-PDU.
3.1.20.4 Gateway routing timeout
The Tx-I-PDU based gateway routing timeout describes the maximum time between two
routing events that refer the same Tx-I-PDU, before a timeout occurs. If a routing timeout
occurs, the cyclic transmission of a Tx-I-PDU is stopped. The cyclic transmission of the
PDU is reinitiated if any gateway mapping event occurs for the Tx-I-PDU.
3.1.21 Gateway Description Routing
Description routing represents a basic routing mode, in which a portion of an incoming Rx-
I-PDU is copied to 1…n destination Tx-I-PDUs without any further interpretation and
processing of the content. In this mode, the normal signal processing path is bypassed
allowing a reduction of the routing event latency.
A minimal set up of a gateway mapping consists of one source and one destination
description. A source description is at least defined by a source I-PDU reference, start bit
position, bit size and endianness. The bit size defines the amount of bits that should be
copied starting from the start bit position. On the other hand, a destination description is
© 2017 Vector Informatik GmbH
Version 5.05.00
33
based on template version 5.6.0
Technical Reference MICROSAR COM
defined by a destination I-PDU, a start bit position and endianness. Additionally, a transfer
property can be configured.
The usage of this gateway mode requires several preconditions to be fulfilled:
- Source and destination description of a gateway mapping share the same
endianness.
- Sign extension, endianness conversion and filtering are not supported.
The call context and the point of time, when a gateway mapping is processed after
reception, are defined through the source and destination I-PDU signal processing
property:
Destination I-PDU
Immediate
Deferred
Immediate Rx and Tx: Com_RxIndication()
Rx: Com_RxIndication()
Tx: Com_MainFunctionTx()
rce
u
DU
o
P
S
-I Deferred
Rx and Tx:
Rx: Com_MainFunctionRouteSignals()
Com_MainFunctionRouteSignals()
Tx: Com_MainFunctionTx()
Table 3-3 Gateway mapping processing context
A gateway mapping in which source and destination descriptions refer I-PDUs with an
immediate signal processing property, have the least routing latency. In this case, copying
the referred bits from Rx- to Tx-I-PDU buffer and transmit initiation take place in the
context of Com_RxIndication().
A further optimization for reducing the routing latency is the possibility to generate gateway
routing functions and therefore reduce the latency which is introduced by ROM access
operations. In this case, the generated embedded code is used instead of the static code.
This
optimization
strategy
can
be
enabled
by
activating
the
ComDescriptionRoutingCodeGeneration switch and is only available for a PRE-COMPILE
implementation variant.
Note
If multiple source I-PDUs have a deferred signal processing property, then the received
I-PDUs are processed in reverse order.
3.1.22 Large I-PDUs
A large I-PDU is a PDU that is too large to fit into a single L-PDU of the underlying
communication protocol.
A large I-PDU must have the ComIPduType configured to TP and will be
transmitted/received by a transport protocol.
On Receiver side the COM holds for always a valid value of the signals contained in a
large I-PDU.
© 2017 Vector Informatik GmbH
Version 5.05.00
34
based on template version 5.6.0
Technical Reference MICROSAR COM
On Transmission side the COM will return COM_BUSY, by a call of the APIs:
Com_SendSignal, Com_SendSignalGroup and Com_SendDynSignal when a large I-PDU
transmission is in progress.
Note
For large I-PDUs the ComTxIPduClearUpdateBit context can only be configured to
Confirmation.
3.1.23 Dynamic length signals
Dynamic length signals are ComSignals or ComGroupSignals with a ComSignalType
configured to UINT8_DYN. The range of the length of a dynamic length signal is 0 to the
configured ComSignalLength.
Dynamic length signals must be contained in an I-PDU with the ComIPduType configured
to TP and dynamic length signals must be placed at the end of the I-PDU.
It is allowed to configure an update-bit for a dynamic length signal. In this case, the
update-bit must be located in front of the dynamic length signal.
Use the API Com_ReceiveDynSignal to receive a dynamic length signal and use the API
Com_SendDynSignal to send a dynamic length signal.
Dynamic length signal must be placed to byte boundaries and must have the signal
endianness OPAQUE.
Only the ComFilterAlgorithm ALWAYS and NEVER are supported for dynamic length
signals.
Note
The initial length of a dynamic length signal is 0.The configured ComSignalInitValue is
not required for the generation.
3.1.24 Com Optimizations
3.1.24.1 Critical section threshold loop strategy
Critical sections as described in chapter 4.2 are used to avoid concurrency/ data
consistency problems when shared ressources are used. However, switching the state of
critical sections might be an expensive operation. To optimize the relation between runtime
with locked interrupts and the cost introduced by entering and exiting an exclusive area a
threshold strategy is applied when multiple elements are processed in a loop.
This strategy locks the desired exclusive area before entering loop and exits it after all
elements have been processed. Further, at the end of each iteration step a counter is
incremented and compared with configured threshold value. If the counter exceeds the
threshold the exclusive area will be temporarily be opened to allow rescheduling of waiting
tasks as shown in following example.
© 2017 Vector Informatik GmbH
Version 5.05.00
35
based on template version 5.6.0
Technical Reference MICROSAR COM
Example
Com_EnterExclusiveArea();
for(; idx < tableSize; idx++)
{
exclusiveAreaCounter++;
/* Do processing */
if(exclusiveAreaCounter >= exclusiveAreaThreshold)
{
exclusiveAreaCounter = 0;
Com_ExitExclusiveArea();
Com_EnterExclusiveArea();
}
}
Com_ExitExclusiveArea();
Following thresholds can be configured:
Threshold
Description
(Affected Exclusive Area)
ComGatewayDescriptionProcessingISRLockThreshold Strategy is applied on gateway description processing, where
the source description is deferred.
(COM_EXCLUSIVE_AREA_BOTH)
ComGatewayProcessingISRLockThreshold
Strategy is applied in context of
Com_MainFunctionRouteSignals, where gateway signal
(COM_EXCLUSIVE_AREA_BOTH)
routing elements are being processed.
ComIPduGroupISRLockThreshold
Strategy is applied in context of Com_IpduGroupControl or
Com_IpduGroupStart / -Stop respectively. Threshold describes
(COM_EXCLUSIVE_AREA_RX/
the max. number of Rx or Tx I-PDU’s which are being started
COM_EXCLUSIVE_AREA_TX)
or stopped before ISR Locks will temporarily be opened.
ComRxDeadlineMonitoringISRLockThreshold
Threshold describes the max. number of monitored Rx items (I-
PDU based or Signal/SignalGroup based), which are being
(COM_EXCLUSIVE_AREA_RX)
processed under locked interrupts in context of
Com_MainFunctionRx.
Note: Threshold might be released temporarily if a timeout
notification callback has to be called.
ComRxDeferredProcessingISRLockThreshold
Threshold describes the max. number of Rx I-PDUs which are
being processed after reception in context of
(COM_EXCLUSIVE_AREA_RX)
Com_MainFunctionRx.
Note: Threshold might be released temporarily if a notification/
or invalid notification has to be called, whenever the deferred
notification cache is full (see section 0).
ComTxCyclicProcessingISRLockThreshold
Threshold describes the maximum number of Tx I-PDUs
whose cyclic parameters are processed under locked interrupts
(COM_EXCLUSIVE_AREA_TX)
© 2017 Vector Informatik GmbH
Version 5.05.00
36
based on template version 5.6.0
Technical Reference MICROSAR COM
before the interrupt lock will be opened temporarily.
ComTxDeadlineMonitoringISRLockThreshold
Threshold describes the max. number of monitored Tx I-PDUs,
which are being processed under locked interrupts in context of
(COM_EXCLUSIVE_AREA_TX)
Com_MainFunctionTx.
Note: Threshold might be released temporarily if a timeout
notification callback has to be called.
ComTxProcessingISRLockThreshold
Threshold describes the max. number of Tx I-PDUs which are
processed for transmission under locked interrupts in context of
(COM_EXCLUSIVE_AREA_TX)
Com_MainFunctionTx.
Table 3-4 Configurable Thresholds
3.1.24.2 Rx Notification caching
A RTE/ application callback must always be called with open interrupt locks, therefore it
might be required to temporarily exit an previously entered exclusive area. To reduce the
cost of switching the state of an exclusive area, notification callbacks and invalid
notification callbacks are cached in a configurable notification cache while signals and
signal groups are being unpacked after reception. The idea behind this strategy is, instead
of exiting and reentering the Rx exclusive area multiple times, to call all cached
notifications afterwards at once, after all received signals/ signal groups have been
processed. However caching requires some amount of memory, therefore the user can
configure the cache size. Whenever, the cache is full, the exclusive area will be
temporarily exited and all cached notifications and invalid notifications callbacks will be
called.
Depending on the configured signal processing property of the I-PDU, the callbacks will be
either be called in immediate or deferred notification cache:
- Immediate notification cache: Callbacks will be cached in the context of
Com_RxIndication. Cache is reserved on the stack whenever an immediate I-PDU
is being received. Therefore the cache has a local scope for each received
immediate I-PDU.
- Deferred notification cache: Callbacks will be cached in the task context of
Com_MainFunctionRx. One shared cache is reserved on the heap and therefore
has a global scope for all deferred I-PDUs. Signal/ signal group callbacks of all
deferred I-PDUs will be cached before the callbacks will be called.
Note
User has to ensure that the configured stack size complies with the configured
immediate notification cache and reception rate of immediate I-PDUs.
3.1.24.3 Deferred Event Caching
This feature describes one optimization strategy for reducing the processing time of
deferred I-PDUs. The main idea behind this feature is to cache the ID of received Rx-I-
PDUs that should be processed in deferred manner and therefore avoid the handling of all
configured deferred I-PDUs. The optional parameter ComRxDeferredEventCacheSize
describes a cache size for storing the amount of deferred I-PDUs. The maximum size of
the cache is limited to the number of configured I-PDUs. If the number of deferred events
© 2017 Vector Informatik GmbH
Version 5.05.00
37
based on template version 5.6.0
Technical Reference MICROSAR COM
exceeds the cache size, the deferred I-PDUs will be processed in normal fashion and
every configured I-PDU has to be checked if a new event has occurred. This feature can
be activated by enabling the ComDeferredEventCacheSupport switch.
Note
If the deferred event caching strategy applies, received I-PDUs are processed in
reverse order.
3.1.24.4 Main Function Timing Domains
In general, a timebase for reception and transmission of COM I-PDUs can be configured.
These timebases should meet the call cycle periods of Com_MainFunctionRx() and
Com_MainFunctionTx(), respectively. All timing operations are derived from the resolution
of these timebases.
In order to reduce the computational overhead at runtime, separate timing domains can be
configured for Rx-/ Tx-deadline monitoring and Tx-cyclic operations. The resolutions of
these timebases are limited to the resolution of the two basic timelines.
The configured resolution of a timeline defines the granularity, how precisely a timing event
is measured. Figure 3-10 Main Function Timing Domains gives an example for the usage
of timing domains.
Top most, a basic Rx-Timebase with a resolution of tres = 1ms is shown. In this example,
the reception of a signal should be monitored with a configured timeout of 3ms. In Figure
3-10 a) an Rx-Event occurs right before t = 3ms. Afterwards, the timeout counter is
decreased and checked every single tick of the Rx-Timebase until the timeout notification
function is called. In Figure 3-10 b) a separate timing domain for deadline monitoring is
configured. This domain has a resolution of tres = 3ms; therefore the timeout counter is
decreased and checked less frequently until the timeout notification function is called. If
many signals should be monitored, the usage of a separate timing domain can relieve the
computational unit.
However, a coarse resolution can lead to a timeline fuzziness, which is shown in Figure
3-10 c). Here, the timeline is configured similar to Figure 3-10 b), but this time the signal is
received right after one clock cycle of the deadline monitoring timeline. The timeout
counter is not decreased until the next tick, which leads to a worst-case inaccuracy of
tfuzz = tres.
Figure 3-10 Main Function Timing Domains
To activate this feature, the ComMainfunctionTimingDomainSupport switch must be
enabled.
© 2017 Vector Informatik GmbH
Version 5.05.00
38
based on template version 5.6.0
Technical Reference MICROSAR COM
3.1.24.4.1 Timebase for Rx-deadline monitoring handling
If a Rx-deadline monitoring timebase is configured, all Rx-deadline monitoring operations
will rely on the resolution of this timing domain. Therefore, the configured timeout and first
timeout parameters must be a multiple of this resolution. If no Rx-deadline monitoring
timebase is specified, all deadline monitoring operations are derived from the basic
reception timeline.
3.1.24.4.2 Timebase for Tx-deadline monitoring handling
If a Tx-deadline monitoring timebase is configured, all Tx-deadline monitoring operations
will rely on the resolution of this timing domain. Therefore, the configured timeout
parameter must be a multiple of this resolution. If no Tx-deadline monitoring timebase is
specified, all deadline monitoring operation will rely on the basic transmission timeline.
Additionally, if the gateway functionality is configured, the I-PDU-based gateway routing
timeout is also configured within the Tx-deadline monitoring timebase. Hence, the gateway
routing timeout parameter must meet the above mentioned requirements.
3.1.24.4.3 Timebase for Tx-cyclic operations
If a timebase for Tx-cyclic operations is configured, following operations will rely on the
resolution of this timing domain and therefore have to be a multiple of the configured
timebase resolution:
- Tx Mode Repetition Period
- Tx Mode Time Offset
- Tx Mode Time Period
- Minimum Delay Time
3.1.24.5 Handle ID
All data unit elements (Signal, SignalGroup, GroupSignal, I-PDU, I-PDU Group) contain a
numerical ID which is unique for the type of the data unit. This Handle ID is required to
access these elements via respective API calls.
However, Signals, SignalGroups and GroupSignals can be defined without being accessed
from outside. In this case, the assignment of a Handle ID is obsolete and can be removed
to reduce the computational overhead and code size. Though these unit elements cannot
be accessed, they are considered for the calculation of the initial values of their containing
I-PDU. The allocation of the Handle ID is coupled to the values of parameters
ComSignalAccess and ComSignalGroupAccess. These parameters determine whether the
Handle ID is required or not:
ComSignalAccess/
Description
Handle ID
ComSignalGroupAccess
ACCESS_NEEDED_BY_SWC_OR_COM
A data or a gateway mapping is
x
present.
ACCESS_NEEDED_BY_OTHER
A Handle ID is required by user or
x
any other module.
© 2017 Vector Informatik GmbH
Version 5.05.00
39
based on template version 5.6.0
Technical Reference MICROSAR COM
ACCESS_UNCLEAR
It is unclear, if the data unit element
x
needs to be accessed.
ACCESS_NOT_NEEDED
Handle ID is not needed, as neither
a data nor a gateway mapping could
be found.
It should be noted, if the Handle ID of a GroupSignal is required, the containing
SignalGroup must have a Handle ID as well. Further, for an array-based access of
SignalGroups, a Handle ID for the SignalGroup and all GroupSignals is essential.
3.1.24.6 Autosar 3 based I-Pdu Group handling
If the switch ComGeneral.ComOptimizedIPduGroupHandling is enabled the APIs
Com_IpduGroupControl and Com_ReceptionDMControl are replaced by the Autosar 3
APIs: Com_IpduGroupStart, Com_IpduGroupStop, Com_EnableReceptionDM and
Com_DisableReceptionDM. These APIs use directly the I-PduGroup Handle Id and are
faster when one I-Pdu Group is switched at once.
3.2
Initialization
Before the COM layer can be used it has to be initialized by Com_Init(). This function
performs the basic initialization but does not enable the transmission or reception of
signals and I-PDUs.
Initialization, starting and stopping of the layer and its I-PDU groups is normally driven by
the Communication Manager. If this software component is not available a similar
component has to be provided by the integrator.
If variables exist, which cannot be initialized by the startup code, the function
Com_InitMemory() has to be called.
© 2017 Vector Informatik GmbH
Version 5.05.00
40
based on template version 5.6.0
Technical Reference MICROSAR COM
3.3
States
3.3.1
Module States
The COM module has the following module states
COM_UNINIT
The module is not initialized or not usable.
COM_INIT
The module is initialized and usable.
and the possible state changes are shown in Figure 3-11.
stm StateManager
Com_Init()
Module
Module
PowerOn
COM_UNINIT
COM_INIT
Module
Initial
Com_DeInit()
Figure 3-11 Module State Machine
The current state of the COM can be accessed by the API ‘Com_GetStatus()’.
© 2017 Vector Informatik GmbH
Version 5.05.00
41
based on template version 5.6.0
Technical Reference MICROSAR COM
3.3.2
I-PDU States
Each I-PDU has the following states
Activated
Deactivated
An I-PDU is active if and only if at least one I-PDU group is active it belongs to. Thus an I-
PDU must belong to at least one I-PDU group in order to be able to get activated.
The possible state changes are shown in Figure 3-12.
stm IPduGroupHandling
Com_IpduGroupControl(RequestedActivationState == activated)
I-PDU
I-PDU
Com_Init()
deactiv ated
activ ated
I-PDU
Initial
Com_IpduGroupControl(RequestedActivationState == deactivated),
Com_DeInit()
Figure 3-12 I-PDU State Machine
© 2017 Vector Informatik GmbH
Version 5.05.00
42
based on template version 5.6.0
Technical Reference MICROSAR COM
3.3.3
Reception Deadline Monitoring States
The reception deadline monitoring of an I-PDU is enabled if and only if it is contained in an
I-PDU group that has reception deadline monitoring enabled. Otherwise, the reception
deadline monitoring of the I-PDU is disabled.
The possible state changes are shown in Figure 3-13.
stm ReceptionDeadlineMonitoring
Com_IpduGroupControl(RequestedActivationState == activated) [CurrentActiveState == deactivated],
Com_ReceptionDMControl(RequestedActivationState == enabled), Com_EnableIPduReceptionDM()
I-PDU DM
I-PDU DM
Com_Init()
disabled
enabled
I-PDU DM
Initial
Com_IpduGroupControl(RequestedActivationState == deactivated) [CurrentActiveState == activated],
Com_ReceptionDMControl(RequestedActivationState == disabled), Com_DisableIPduReceptionDM()
Figure 3-13 Reception Deadline Monitoring State Machine
© 2017 Vector Informatik GmbH
Version 5.05.00
43
based on template version 5.6.0
Technical Reference MICROSAR COM
3.4
Main Functions
COM provides following functions listed in Table 3-5 that have to be called cyclically by the
Basic Software Scheduler or a similar component.
Main Function
Description
Com_MainFunctionRx()
This function performs the following reception
processings
> Reception deadline monitoring
> Deferred signal processing
This function must be called cyclically with a
cycle time identical to the configured Rx Time
Base.
Com_MainFunctionTx()
This function performs the following
transmission processings
> Transmission of I-PDUs
> Transmission deadline monitoring
> Deferred transmission notification
This function must be called cyclically with a
cycle time identical to the configured Tx Time
Base.
Com_MainFunctionRouteSignals()
This function performs the signal gateway
functionality.
Note that the transmission of Tx I-PDUs is
never triggered by this function directly. Thus
the Com_MainFunctionTx() is necessary for a
complete signal routing.
This function must be called cyclically with a
cycle time identical to the configured Gw Time
Base.
Table 3-5 Main functions that have to be called cyclically
Note
To reduce the signal gateway latency, the order of the main function calls should be as
follows
> Com_MainFunctionRx()
> Com_MainFunctionRouteSignals()
> Com_MainFunctionTx()
© 2017 Vector Informatik GmbH
Version 5.05.00
44
based on template version 5.6.0
Technical Reference MICROSAR COM
3.5
Error Handling
3.5.1
Development Error Reporting
By default, development errors are reported to the DET using the service
Det_ReportError() as specified in [2], if development error reporting is enabled (i.e.
pre-compile parameter COM_DEV_ERROR_DETECT==STD_ON).
If another module is used for development error reporting, the function prototype for
reporting the error can be configured by the integrator, but must have the same signature
as the service Det_ReportError().
The reported COM ID is 50.
The reported service IDs identify the services which are described in 0. The following table
presents the service IDs and the related services:
Service ID
Service
COMServiceId_Init
Com_Init
COMServiceId_DeInit
Com_DeInit
COMServiceId_IpduGroupControl
Com_IpduGroupControl
COMServiceId_ReceptionDMControl
Com_ReceptionDMControl
COMServiceId_GetStatus
Com_GetStatus
COMServiceId_GetConfigurationId
Com_GetConfigurationId
COMServiceId_GetVersionInfo
Com_GetVersionInfo
COMServiceId_SendSignal
Com_SendSignal
COMServiceId_ReceiveSignal
Com_ReceiveSignal
COMServiceId_UpdateShadowSignal
Com_UpdateShadowSignal
COMServiceId_SendSignalGroup
Com_SendSignalGroup
COMServiceId_ReceiveSignalGroup
Com_ReceiveSignalGroup
COMServiceId_ReceiveShadowSignal
Com_ReceiveShadowSignal
COMServiceId_InvalidateSignal
Com_InvalidateSignal
COMServiceId_InvalidateShadowSignal
Com_InvalidateShadowSignal
COMServiceId_TriggerIPDUSend
Com_TriggerIPDUSend
COMServiceId_MainFunctionRx
Com_MainFunctionRx
COMServiceId_MainFunctionTx
Com_MainFunctionTx
COMServiceId_MainFunctionRouteSignals
Com_MainFunctionRouteSignals
COMServiceId_InvalidateSignalGroup
Com_InvalidateSignalGroup
COMServiceId_ClearIpduGroupVector
Com_ClearIpduGroupVector
COMServiceId_SetIpduGroup
Com_SetIpduGroup
COMServiceId_SendDynSignal
Com_SendDynSignal
COMServiceId_ReceiveDynSignal
Com_ReceiveDynSignal
COMServiceId_SendSignalGroupArray
Com_SendSignalGroupArray
COMServiceId_ReceiveSignalGroupArray
Com_ReceiveSignalGroupArray
COMServiceId_SwitchIpduTxMode
Com_SwitchIpduTxMode
© 2017 Vector Informatik GmbH
Version 5.05.00
45
based on template version 5.6.0
Technical Reference MICROSAR COM
Service ID
Service
COMServiceId_TriggerIPDUSendWithMetaD Com_TriggerIPDUSendWithMetaData
ata
COMServiceId_TxConfirmation
Com_TxConfirmation
COMServiceId_TriggerTransmit
Com_TriggerTransmit
COMServiceId_RxIndication
Com_RxIndication
COMServiceId_CopyTxData
Com_CopyTxData
COMServiceId_CopyRxData
Com_CopyRxData
COMServiceId_TpRxIndication
Com_TpRxIndication
COMServiceId_StartOfReception
Com_StartOfReception
COMServiceId_TpTxConfirmation
Com_TpTxConfirmation
Table 3-6 Service IDs
The errors reported to DET are described in the following table:
Error Code
Description
COM_E_PARAM
The API service has been with a wrong parameter.
COM_E_UNINIT
The API service has been called before COM was initialized with
Com_Init() or after a call to Com_DeInit()
COM_E_PARAM_POINTER
The API service has been called with a not expected NULL
pointer.
COM_E_INIT_FAILED
The API service has been called with a not expected NULL
pointer
Table 3-7 Errors reported to DET
3.5.2
Production Code Error Reporting
No production error codes are currently defined for COM.
© 2017 Vector Informatik GmbH
Version 5.05.00
46
based on template version 5.6.0
Technical Reference MICROSAR COM
4 Integration
This chapter gives necessary information for the integration of the MICROSAR COM into
an application environment of an ECU.
4.1
Scope of Delivery
The delivery of the COM contains the files which are described in the chapters 4.1.1 and
4.1.2.
4.1.1
Static Files
File Name
Description
Com.c
This is the source file of the COM
Com.h
This is the header file of COM
Table 4-1 Static files
4.1.2
Dynamic Files
The dynamic files are generated by the configuration tool DaVinci Configurator.
File Name
Description
Com_Cfg.h
This file contains:
> global constant macros
> global function macros
> global data types and structures
> global data prototypes
> global function prototypes
of CONFIG-CLASS PRE-COMPILE data.
Com_Cbk.h
This is the generated header file of COM containing prototypes for lower layers.
Com_Cfg.c
This file contains:
> local constant macros
> local function macros
> local data types and structures
> local data prototypes
> local data
> global data
of CONFIG-CLASS PRE-COMPILE data.
Com_Cot.h
This file contains the prototypes of:
> I-Pdu Callouts
> I-Pdu Trigger Transmit Callouts
This file is included by Com_Cbk.h.
Com_Lcfg.h
This file contains:
> global constant macros
© 2017 Vector Informatik GmbH
Version 5.05.00
47
based on template version 5.6.0
Technical Reference MICROSAR COM
File Name
Description
> global function macros
> global data types and structures
> global data prototypes
> global function prototypes
of CONFIG-CLASS LINK data.
Com_Lcfg.c
This file contains:
> local constant macros
> local function macros
> local data types and structures
> local data prototypes
> local data
> global data
of CONFIG-CLASS LINK data.
Com_PBcfg.h This file contains:
> global constant macros
> global function macros
> global data types and structures
> global data prototypes
> global function prototypes
of CONFIG-CLASS POST-BUILD data.
Com_PBcfg.c This file contains:
> local constant macros
> local function macros
> local data types and structures
> local data prototypes
> local data
> global data
of CONFIG-CLASS POST-BUILD data.
Com_Types.h This file contains the static type definitions.
Table 4-2 Generated files
© 2017 Vector Informatik GmbH
Version 5.05.00
48
based on template version 5.6.0
Technical Reference MICROSAR COM
4.2
Critical Sections
The handling of entering and leaving critical sections is provided by the RTE. The Vector
MICROSAR COM offers several groups of critical sections to optimize the runtime
consumption.
For a more detailed description of the possible exclusive area implementation variant
please refer to [4].
Following critical sections are offered
COM_EXCLUSIVE_AREA_BOTH
This critical section protects Rx and Tx ressources that are being accessed in context of
Com_MainFunctionRouteSignals for signal gateway routings or description routings with
configured deferred description source. Therefore the critical section enclosed with
COM_EXCLUSIVE_AREA_BOTH should never be interrupted by any Com API which
accesses Tx or Rx ressources likewise mentioned in the second and third column of
Table 4-3 .
COM_EXCLUSIVE_AREA_TX
This critical section protects Tx ressources that can be accessed from various
contexts. Therefore the critical section enclosed with COM_EXCLUSIVE_AREA_TX
should never be interrupted by any Com API which accesses Tx ressources likewise
mentioned in the first and second column of Table 4-3 .
COM_EXCLUSIVE_AREA_RX
This critical section protects Rx ressources that can be accessed from various
contexts. Therefore the critical section enclosed with COM_EXCLUSIVE_AREA_RX
should never be interrupted by any Com API which accesses Rx ressources likewise
mentioned in the first and second column of Table 4-3 .
COM_EXCLUSIVE_AREA_BOTH
COM_EXCLUSIVE_AREA_TX
COM_EXCLUSIVE_AREA_RX
Com_MainFunctionRouteSignals
Com_Deinit
Com_DeInit
Com_Init
Com_Init
Com_InvalidateSignal
Com_IPduGroupControl
Com_InvalidateSignalGroup
Com_IPduGroupStart
Com_IpduGroupControl
Com_IPduGroupStop
Com_IpduGroupStart
Com_MainFunctionRx
Com_IpduGroupStop
Com_ReceiveDynSignal
Com_MainFunctionTx
Com_ReceiveSignal
Com_RxIndication (UseCase:
Com_ReceiveSignalGroup
Description routing with immediate
source description)
Com_SendDynSignal
Com_ReceiveSignalGroupArray
Com_SendSignal
Com_RxIndication
Com_SendSignalGroup
Com_TpRxindication
© 2017 Vector Informatik GmbH
Version 5.05.00
49
based on template version 5.6.0
Technical Reference MICROSAR COM
Com_SendSignalGroupArray
Com_TpRxIndication
Com_TpTxConfirmation (UseCase:
Description routing with immediate
source description)
Com_TxConfirmation
Table 4-3 Overview of used Exclusive Area per Com API
© 2017 Vector Informatik GmbH
Version 5.05.00
50
based on template version 5.6.0
Technical Reference MICROSAR COM
5 API Description
For an interfaces overview please see Figure 2-2.
5.1
Type Definitions
The types defined by the COM are described in this chapter.
Type Name
C-Type Description
Value Range
Com_StatusType
enum
This is a status value
COM_UNINIT
returned by the API
The AUTOSAR COM module is not
service
initialized or not usable
Com_GetStatus().
COM_INIT
The AUTOSAR COM Module is
initialized and usable.
Com_SignalIdType
c-type AUTOSAR COM signal
0..<SignalIdmax>
object identifier.
Zero-based integer number
Com_SignalGroupIdTy c-type
AUTOSAR COM signal
0..<SignalGroupIdmax>
pe
group object identifier.
Zero-based integer number
Com_IpduGroupIdTyp c-type
AUTOSAR COM I-PDU
0..<IpduGroupIdmax>
e
group object identifier.
Zero-based integer number
Com_IpduGroupVector byte
This type stores a flag
uint8[(ComSupportedIPduGroups -
array
(bit) for each I-PDU
1)/8 + 1]
group
Com_SerciveIdType
enum
Unique identifier of an
See in Table 3-6
AUTOSAR COM service.
Table 5-1 Type definitions
© 2017 Vector Informatik GmbH
Version 5.05.00
51
based on template version 5.6.0
Technical Reference MICROSAR COM
5.2
Services provided by COM
5.2.1
Com_Init
Prototype
void Com_Init (const Com_ConfigType *config)
Parameter
config
NULL_PTR if COM_USE_INIT_POINTER is STD_OFF Pointer to the Com
configuration data if COM_USE_INIT_POINTER is STD_ON
Return code
void
none
Functional Description
This service initializes internal and external interfaces and variables of the AUTOSAR COM layer for the
further processing. After calling this function the inter-ECU communication is still disabled.
Particularities and Limitations
> Com_InitMemory() has to be executed previously, if the startup code does not initialize variables.Com is
not in initialized state.
Caution
Com_Init shall not pre-empt any COM function. The rest of the system must guarantee that
Com_Init is not called in such a way.
Call context
> The function must be called on task level and must not be interrupted by other administrative function
calls.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-2 Com_Init
5.2.2
Com_InitMemory
Prototype
void Com_InitMemory (void)
Parameter
void
none
Return code
void
none
Functional Description
The function initializes variables, which cannot be initialized with the startup code.
Particularities and Limitations
Com_Init() is not called yet.
Call context
> The function must be called on task level.
© 2017 Vector Informatik GmbH
Version 5.05.00
52
based on template version 5.6.0
Technical Reference MICROSAR COM
Table 5-3 Com_InitMemory
5.2.3
Com_DeInit
Prototype
void Com_DeInit (void)
Parameter
void
none
Return code
void
none
Functional Description
This service stops the inter-ECU communication. All started I-PDU groups are stopped and have to be
started again, if needed, after Com_Init is called. By a call to ComDeInit COM is put into an not initialized
state.
Particularities and Limitations
-
Caution
Com_DeInit shall not pre-empt any COM function. The rest of the system must guarantee that
Com_DeInit is not called in such a way.
Call context
> The function must be called on task level and must not be interrupted by other administrative function
calls.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-4 Com_DeInit
5.2.4
Com_IpduGroupControl
Prototype
void Com_IpduGroupControl (Com_IpduGroupVector ipduGroupVector, boolean
initialize)
Parameter
ipduGroupVector
I-PDU group vector containing the activation state (stopped = 0/ started = 1)
for all I-PDU groups.
initialize
flag to request initialization of the I-PDUs which are newly started
Return code
void
none
Functional Description
This service starts I-PDU groups.
© 2017 Vector Informatik GmbH
Version 5.05.00
53
based on template version 5.6.0
Technical Reference MICROSAR COM
Particularities and Limitations
-
Call context
> The function must be called on task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-5 Com_IpduGroupControl
5.2.5
Com_ReceptionDMControl
Prototype
void Com_ReceptionDMControl (Com_IpduGroupVector ipduGroupVector)
Parameter
ipduGroupVector
I-PDU group vector containing the requested deadline monitoring state
(disabled = 0/ enabled = 1) for all I-PDU groups.
Return code
void
none
Functional Description
This service enables or disables I-PDU group Deadline Monitoring.
Particularities and Limitations
-
Call context
> The function must be called on task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-6 Com_ReceptionDMControl
5.2.6
Com_IpduGroupStart
Prototype
void Com_IpduGroupStart (Com_IpduGroupIdType IpduGroupId, boolean Initialize)
Parameter
IpduGroupId
ID of I-PDU group to be started
Initialize
Flag to request initialization of the data in the I-PDUs of this I-PDU group
Return code
void
none
Functional Description
Starts a preconfigured I-PDU group. For example, cyclic I-PDUs will be sent out cyclically after the call of
© 2017 Vector Informatik GmbH
Version 5.05.00
54
based on template version 5.6.0
Technical Reference MICROSAR COM
Com_IpduGroupStart(). If Initialize is true all I-PDUs of the I-PDU group shall be (re-)initialized before the I-
PDU group is started. That means they shall behave like after a start-up of COM, for example the old_value
of the filter objects and shadow buffers of signal groups have to be (re-)initialized.
Particularities and Limitations
-
Caution
A call to Com_IpduGroupStart shall not be interrupted by another call to Com_IpduGroupStart,
Com_EnableReceptionDM, Com_DisableReceptionDM or a call to Com_IpduGroupStop.
Call context
> The function must be called on task level and must not be interrupted by other Com_IpduGroupStart and
Com_IpduGroupStop calls.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-7 Com_IpduGroupStart
5.2.7
Com_IpduGroupStop
Prototype
void Com_IpduGroupStop (Com_IpduGroupIdType IpduGroupId)
Parameter
IpduGroupId
ID of I-PDU group to be stopped
Return code
void
none
Functional Description
Stops a preconfigured I-PDU group. For example, cyclic I-PDUs will be stopped after the call of
Com_IpduGroupStop().
Particularities and Limitations
-
Caution
A call to Com_IpduGroupStop shall not be interrupted by another call to Com_IpduGroupStop,
Com_EnableReceptionDM, Com_DisableReceptionDM or a call to Com_IpduGroupStart.
Call context
> The function must be called on task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-8 Com_IpduGroupStop
© 2017 Vector Informatik GmbH
Version 5.05.00
55
based on template version 5.6.0
Technical Reference MICROSAR COM
5.2.8
Com_EnableReceptionDM
Prototype
void Com_EnableReceptionDM (Com_IpduGroupIdType IpduGroupId)
Parameter
IpduGroupId
ID of I-PDU group where reception DM shall be enabled.
Return code
void
none
Functional Description
Enables the reception deadline monitoring for the I-PDUs within the given I-PDU group.
Particularities and Limitations
-
Caution
A call to Com_EnableReceptionDM shall not be interrupted by another call to
Com_EnableReceptionDM, Com_IpduGroupStop, Com_DisableReceptionDM or a call to
Com_IpduGroupStart.
Call context
> The function must be called on task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-9 Com_EnableReceptionDM
5.2.9
Com_DisableReceptionDM
Prototype
void Com_DisableReceptionDM (Com_IpduGroupIdType IpduGroupId)
Parameter
IpduGroupId
ID of I-PDU group where reception DM shall be disabled.
Return code
void
none
Functional Description
Disables the reception deadline monitoring for the I-PDUs within the given I-PDU group.
Particularities and Limitations
-
Caution
A call to Com_DisableReceptionDM shall not be interrupted by another call to
Com_DisableReceptionDM, Com_IpduGroupStop, Com_EnableReceptionDM or a call to
Com_IpduGroupStart.
Call context
> The function must be called on task level.
© 2017 Vector Informatik GmbH
Version 5.05.00
56
based on template version 5.6.0
Technical Reference MICROSAR COM
> This function is Synchronous
> This function is Non-Reentrant
Table 5-10 Com_DisableReceptionDM
5.2.10 Com_GetConfigurationId
Prototype
uint32 Com_GetConfigurationId (void)
Parameter
void
none
Return code
uint32
none
none
uint32 Configured ConfigurationID
Functional Description
This function shall perform the processing of the AUTOSAR COM receive processing that are not directly
initiated by the calls from the RTE and PDU-R. A call to Com_MainFunctionRx returns simply if COM was
not previously initialized with a call to Com_Init.
Particularities and Limitations
> - CREQ-103161 This function shall perform the processing of the transmission activities that are not
directly initiated by the calls from the RTE and PDU-R. A call to Com_MainFunctionTx returns simply if
COM was not previously initialized with a call to Com_Init.- CREQ-103168 Provides the unique identifier
of the configuration.-
Call context
> The function must be called on task level.
> The function must be called on task level.
> The function can be called on interrupt and task level. CREQ-107420
Table 5-11 Com_GetConfigurationId
5.2.11 Com_GetStatus
Prototype
Com_StatusType Com_GetStatus (void)
Parameter
void
none
Return code
Com_StatusType
Com_StatusType
Functional Description
Returns the status of the AUTOSAR COM module.
© 2017 Vector Informatik GmbH
Version 5.05.00
57
based on template version 5.6.0
Technical Reference MICROSAR COM
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level. CREQ-107163
> This function is Synchronous
> This function is Reentrant
Table 5-12 Com_GetStatus
5.2.12 Com_GetVersionInfo
Prototype
void Com_GetVersionInfo (Std_VersionInfoType *versioninfo)
Parameter
versioninfo
Pointer to where to store the version information of this module.
Return code
void
none
Functional Description
Returns the version information of this module.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Reentrant
Table 5-13 Com_GetVersionInfo
5.2.13 Com_TriggerIPDUSend
Prototype
void Com_TriggerIPDUSend (PduIdType PduId)
Parameter
PduId
ID of Tx I-PDU.
Return code
void
void
Functional Description
By a call to Com_TriggerIPDUSend the I-PDU with the given ID is triggered for transmission.
© 2017 Vector Informatik GmbH
Version 5.05.00
58
based on template version 5.6.0
Technical Reference MICROSAR COM
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-14 Com_TriggerIPDUSend
5.2.14 Com_TriggerIPDUSendWithMetaData
Prototype
void Com_TriggerIPDUSendWithMetaData (PduIdType PduId, const uint8 *MetaData)
Parameter
PduId
ID of Tx I-PDU.
MetaData
The Meta data that shall be added to the I-PDU before sending.
Return code
void
void
Functional Description
By a call to Com_TriggerIPDUSendWithMetaData the given meta data is appended to the I-PDU and the I-
PDU with the given ID is triggered for transmission.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-15 Com_TriggerIPDUSendWithMetaData
5.2.15 Com_ClearIpduGroupVector
Prototype
void Com_ClearIpduGroupVector (Com_IpduGroupVector ipduGroupVector)
Parameter
ipduGroupVector
I-PDU group vector to be cleared
Return code
void
none
Functional Description
This service sets all bits of the given Com_IpduGroupVector to 0.
© 2017 Vector Informatik GmbH
Version 5.05.00
59
based on template version 5.6.0
Technical Reference MICROSAR COM
Particularities and Limitations
-
Call context
> The function must be called on task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-16 Com_ClearIpduGroupVector
5.2.16 Com_SetIpduGroup
Prototype
void Com_SetIpduGroup (Com_IpduGroupVector ipduGroupVector, Com_IpduGroupIdType
ipduGroupId, boolean bitval)
Parameter
ipduGroupVector
I-PDU group vector to be modified
ipduGroupId
ID used to identify the corresponding bit in the I-PDU group vector
bitval
New value of the corresponding bit
Return code
void
none
Functional Description
This service sets the value of a bit in an I-PDU group vector.
Particularities and Limitations
-
Call context
> The function must be called on task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-17 Com_SetIpduGroup
5.2.17 Com_ReceiveDynSignal
Prototype
uint8 Com_ReceiveDynSignal (Com_SignalIdType SignalId, void *SignalDataPtr,
uint16 *Length)
Parameter
SignalId
Id of signal or group signal to be received.
SignalDataPtr
Reference to the signal data in which to store the received data.
Length
in: maximum length that could be received out: length of the dynamic length
signal
© 2017 Vector Informatik GmbH
Version 5.05.00
60
based on template version 5.6.0
Technical Reference MICROSAR COM
Return code
uint8
uint8 E_OK service has been accepted E_NOT_OK in case the Length (as in-
parameter) is smaller than the received length of the dynamic length signal
COM_SERVICE_NOT_AVAILABLE corresponding I-PDU group was stopped
(or service failed due to development error) COM_BUSY in case the TP-Buffer
is locked
Functional Description
The service Com_ReceiveDynSignal updates the signal data referenced by SignalDataPtr with the data in
the signal object identified by SignalId. The Length parameter indicates as "in parameter" the maximum
length that can be received and as "out parameter" the length of the written dynamic length signal or group
signal. If the signal processing of the corresponding I-Pdu is configured to DEFERRED the last received
signal value is available not until the next call to Com_MainfunctionRx. If a group signal is read, the data in
the shadow buffer should be updated before the call by a call of the service Com_ReceiveSignalGroup.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Reentrant
Table 5-18 Com_ReceiveDynSignal
5.2.18 Com_ReceiveSignalGroup
Prototype
uint8 Com_ReceiveSignalGroup (Com_SignalGroupIdType SignalGroupId)
Parameter
SignalGroupId
Id of signal group to be received.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error)
Functional Description
The service Com_ReceiveSignalGroup copies the received signal group to the shadow buffer. After this
call, the group signals could be copied from the shadow buffer to the upper layer by a call of
Com_ReceiveShadowSignal.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level. To guarantee data consistency of the whole signal
group the complete reception of a signal group (consecutive calls of 'Com_ReceiveSignalGroup' and
'Com_ReceiveSignal') must not be interrupted by another reception request for the same signal group.
> This function is Synchronous
> This function is Reentrant
© 2017 Vector Informatik GmbH
Version 5.05.00
61
based on template version 5.6.0
Technical Reference MICROSAR COM
Table 5-19 Com_ReceiveSignalGroup
5.2.19 Com_ReceiveSignalGroupArray
Prototype
uint8 Com_ReceiveSignalGroupArray (Com_SignalGroupIdType SignalGroupId, uint8
*SignalGroupArrayPtr)
Parameter
SignalGroupId
Id of signal group to be received.
SignalGroupArrayPtr
reference to the location where the received signal group array shall be stored
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error) COM_BUSY in case the TP-Buffer is locked for large data types
handling
Functional Description
The service Com_ReceiveSignalGroupArray copies the received signal group array representation from the
PDU to the location designated by SignalGroupArrayPtr.
Particularities and Limitations
The configuration switch ComEnableSignalGroupArrayApi has to be enabled.
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Reentrant
Table 5-20 Com_ReceiveSignalGroupArray
5.2.20 Com_InvalidateSignal
Prototype
uint8 Com_InvalidateSignal (Com_SignalIdType SignalId)
Parameter
SignalId
ID of signal or group signal to be invalidated.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error)
Functional Description
This function invalidates the signal or group signal by calling Com_SendSignal with the configured invalid
value. If this function is used to invalidate a group signal, a call to Com_SendSignalGroup is needed to
update the signal group data.
Particularities and Limitations
-
© 2017 Vector Informatik GmbH
Version 5.05.00
62
based on template version 5.6.0
Technical Reference MICROSAR COM
Call context
> The function can be called on interrupt and task level and has not to be interrupted by other
Com_SendSignal and Com_InvalidateSignal calls for the same SignalId.
> This function is Reentrant
Table 5-21 Com_InvalidateSignal
5.2.21 Com_InvalidateSignalGroup
Prototype
uint8 Com_InvalidateSignalGroup (Com_SignalGroupIdType SignalGroupId)
Parameter
SignalGroupId
ID of signal group to be invalidated.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error)
Functional Description
This function invalidates the whole signal group by calling Com_SendSignal with the configured invalid
value for all group signals of the signal group. After invalidation of the current signal group data
Com_SendSignalGroup is performed internally.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level and has not to be interrupted by other
Com_InvalidateSignalGroup calls for the same SignalGroupId and by Com_SendSignal calls for a
SignalId which is contained in the same signal group.
> This function is Reentrant
Table 5-22 Com_InvalidateSignalGroup
5.2.22 Com_SwitchIpduTxMode
Prototype
void Com_SwitchIpduTxMode (PduIdType PduId, boolean Mode)
Parameter
PduId
ID of Tx I-PDU.
Mode
TX mode of the I-PDU (TRUE/FALSE)
Return code
void
none
Functional Description
This method sets the TX Mode of the I-PDU referenced by PduId to Mode. In case the TX Mode changes
the new mode is immediately effective. In case the requested transmission mode was already active for this
© 2017 Vector Informatik GmbH
Version 5.05.00
63
based on template version 5.6.0
Technical Reference MICROSAR COM
I-PDU, the call will have no effect.
Particularities and Limitations
Call context
> The function can be called on interrupt and task level
> This function is Synchronous
> This function is Reentrant
Table 5-23 Com_SwitchIpduTxMode
5.2.23 Com_SendDynSignal
Prototype
uint8 Com_SendDynSignal (Com_SignalIdType SignalId, const void *SignalDataPtr,
uint16 Length)
Parameter
SignalId
ID of signal or group signal to be sent.
SignalDataPtr
Reference to the signal data to be transmitted.
Length
Length of the dynamic length signal.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error) COM_BUSY in case the TP-Buffer is locked for large data types
handling
Functional Description
The service Com_SendDynSignal updates the signal or group signal object identified by SignalId with the
signal data referenced by the SignalDataPtr parameter. The Length parameter is evaluated for dynamic
length signals.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level and has not to be interrupted by other
Com_SendSignal and Com_InvalidateSignal calls for the same SignalId.
> This function is Reentrant
Table 5-24 Com_SendDynSignal
5.2.24 Com_SendSignal
Prototype
uint8 Com_SendSignal (Com_SignalIdType SignalId, const void *SignalDataPtr)
Parameter
SignalId
ID of signal or group signal to be sent.
© 2017 Vector Informatik GmbH
Version 5.05.00
64
based on template version 5.6.0
Technical Reference MICROSAR COM
SignalDataPtr
Reference to the signal data to be transmitted.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error) COM_BUSY in case the TP-Buffer is locked for large data types
handling
Functional Description
The service Com_SendSignal updates the signal or group signal object identified by SignalId with the signal
data referenced by the SignalDataPtr parameter.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level and has not to be interrupted by other
Com_SendSignal and Com_InvalidateSignal calls for the same SignalId.
> This function is Reentrant
Table 5-25 Com_SendSignal
5.2.25 Com_SendSignalGroup
Prototype
uint8 Com_SendSignalGroup (Com_SignalGroupIdType SignalGroupId)
Parameter
SignalGroupId
ID of signal group to be send.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error)
Functional Description
The service Com_SendSignalGroup copies the content of the associated shadow buffer to the associated I-
PDU buffer. Prior to this call, all group signals should be updated in the shadow buffer by the call of
Com_SendSignal.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level and has not to be interrupted by other
Com_SendSignalGroup calls for the same SignalGroupId. To guarantee data consistency of the whole
signal group the complete transmission of a signal group (consecutive calls of 'Com_SendSignal' and
'Com_SendSignalGroup') must not be interrupted by another transmission request for the same signal
group or by a call of 'Com_InvalidateSignalGroup'.
> This function is Reentrant
Table 5-26 Com_SendSignalGroup
© 2017 Vector Informatik GmbH
Version 5.05.00
65
based on template version 5.6.0
Technical Reference MICROSAR COM
5.2.26 Com_SendSignalGroupArray
Prototype
uint8 Com_SendSignalGroupArray (Com_SignalGroupIdType SignalGroupId, const
uint8 *SignalGroupArrayPtr)
Parameter
SignalGroupId
Id of signal group to be sent.
SignalGroupArrayPtr
Reference to the signal group array.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error) COM_BUSY in case the TP-Buffer is locked for large data types
handling
Functional Description
The service Com_SendSignalGroupArray copies the content of the provided SignalGroupArrayPtr to the
associated I-PDU. The provided data shall correspond to the array representation of the signal group.
Particularities and Limitations
The configuration switch ComEnableSignalGroupArrayApi has to be enabled.
Call context
> The function can be called on interrupt and task level.
> This function is Reentrant
Table 5-27 Com_SendSignalGroupArray
5.2.27 Com_MainFunctionRx
Prototype
void Com_MainFunctionRx (void)
Parameter
void
none
Return code
void
none
Functional Description
This function shall perform the processing of the AUTOSAR COM receive processing that are not directly
initiated by the calls from the RTE and PDU-R. A call to Com_MainFunctionRx returns simply if COM was
not previously initialized with a call to Com_Init.
Particularities and Limitations
- CREQ-103161
Call context
© 2017 Vector Informatik GmbH
Version 5.05.00
66
based on template version 5.6.0
Technical Reference MICROSAR COM
> The function must be called on task level.
Table 5-28 Com_MainFunctionRx
5.2.28 Com_MainFunctionTx
Prototype
void Com_MainFunctionTx (void)
Parameter
void
none
Return code
void
none
Functional Description
This function shall perform the processing of the transmission activities that are not directly initiated by the
calls from the RTE and PDU-R. A call to Com_MainFunctionTx returns simply if COM was not previously
initialized with a call to Com_Init.
Particularities and Limitations
- CREQ-103168
Call context
> The function must be called on task level.
Table 5-29 Com_MainFunctionTx
5.2.29 Com_MainFunctionRouteSignals
Prototype
void Com_MainFunctionRouteSignals (void)
Parameter
void
none
Return code
void
None
Functional Description
Calls the signal gateway part of COM to forward received signals to be routed. The insertion of this call is
necessary for decoupling receive interrupts and signal gateway tasks. A call to
Com_MainFunctionRouteSignals returns simply if COM was not previously initialized with a call to
Com_Init.
Particularities and Limitations
-
Caution
The time between to consecutive calls (perhaps the related task/thread cycle) affects directly the
signal gateway latency. CREQ-103192
© 2017 Vector Informatik GmbH
Version 5.05.00
67
based on template version 5.6.0
Technical Reference MICROSAR COM
Call context
> The function must be called on task level.
Table 5-30 Com_MainFunctionRouteSignals
5.2.30 Com_ReceiveSignal
Prototype
uint8 Com_ReceiveSignal (Com_SignalIdType SignalId, void *SignalDataPtr)
Parameter
SignalId
Id of signal or group signal to be received.
SignalDataPtr
Reference to the signal data in which to store the received data.
Return code
uint8
uint8 E_OK service has been accepted COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development
error)
Functional Description
The service Com_ReceiveSignal updates the signal data referenced by SignalDataPtr with the data in the
signal object identified by SignalId. If the signal processing of the corresponding I-Pdu is configured to
DEFERRED the last received signal value is available not until the next call to Com_MainfunctionRx. If a
group signal is read, the data in the shadow buffer should be updated before the call by a call of the service
Com_ReceiveSignalGroup.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Reentrant
Table 5-31 Com_ReceiveSignal
5.2.31 Com_ReceiveShadowSignal
Prototype
uint8 Com_ReceiveShadowSignal (Com_SignalIdType SignalId, void *SignalDataPtr)
Parameter
SignalId
Id of group signal to be received.
SignalDataPtr
Reference to the group signal data in which to store the received data.
Return code
uint8
void
© 2017 Vector Informatik GmbH
Version 5.05.00
68
based on template version 5.6.0
Technical Reference MICROSAR COM
Functional Description
The service Com_ReceiveShadowSignal updates the group signal data referenced by SignalDataPtr with
the data in the shadow buffer. The data in the shadow buffer should be updated before the call of
Com_ReceiveShadowSignal by a call of the service Com_ReceiveSignalGroup.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Reentrant
Table 5-32 Com_ReceiveShadowSignal
5.2.32 Com_UpdateShadowSignal
Prototype
uint8 Com_UpdateShadowSignal (Com_SignalIdType SignalId, const void
*SignalDataPtr)
Parameter
SignalId
ID of group signal to be updated.
SignalDataPtr
Reference to the group signal data to be updated.
Return code
uint8
void
Functional Description
The service Com_UpdateShadowSignal updates a group signal with the data, referenced by SignalDataPtr.
The update of the group signal data is done in the shadow buffer, not in the I-PDU. To send out the shadow
buffer, Com_SendSignalGroup has to be called.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level.
> This function is Synchronous
> This function is Non-Reentrant
Table 5-33 Com_UpdateShadowSignal
5.2.33 Com_InvalidateShadowSignal
Prototype
uint8 Com_InvalidateShadowSignal (Com_SignalIdType SignalId)
Parameter
SignalId
ID of group signal to be invalidated.
© 2017 Vector Informatik GmbH
Version 5.05.00
69
based on template version 5.6.0
Technical Reference MICROSAR COM
Return code
uint8
void
Functional Description
This function invalidates the group signal by calling Com_SendSignal with the configured invalid value. An
additional call to Com_SendSignalGroup is needed to update the signal group data.
Particularities and Limitations
-
Call context
> The function can be called on interrupt and task level and has not to be interrupted by other
Com_SendSignal and Com_InvalidateSignal calls for the same SignalId.
> This function is Synchronous
> This function is Reentrant
Table 5-34 Com_InvalidateShadowSignal
5.3
Services used by COM
In the following table services provided by other components, which are used by the COM
are listed. For details about prototype and functionality refer to the documentation of the
providing component.
Component
API
PDUR
PduR_ComTransmit
DET
Det_ReportError
Application
I-PDU Callout
RTE/Application
Signal and ComSignalGroup configurable
callback/notification functions
EcuM
EcuM_BswErrorHook
Table 5-35 Services used by the COM
5.4
Callback Functions
This chapter describes the callback functions that are implemented by the COM and can
be invoked by other modules. The prototypes of the callback functions are provided in the
header file Com_Cbk.h by the COM.
5.4.1
Com_RxIndication
Prototype
void Com_RxIndication (PduIdType RxPduId, const PduInfoType*
PduInfoPtr)
Parameter
RxPduId
ID of AUTOSAR COM I-PDU that has been received. Identifies the data that
has been received. Range: 0..(maximum number of I-PDU IDs received by
AUTOSAR COM) - 1
© 2017 Vector Informatik GmbH
Version 5.05.00
70
based on template version 5.6.0
Technical Reference MICROSAR COM
PduInfoPtr
PduInfoPtr Payload information of the received I-PDU (pointer to data and
data length).
Return code
void
none
Functional Description
This function is called by the lower layer after an I-PDU has been received.
Particularities and Limitations
The function is called by the lower layer.
Call Context
The function can be called on interrupt and task level. It is not allowed to use CAT1 interrupts with Rte
(BSW00326]). Due to this, the interrupt context shall be configured to a CAT2 interrupt if an Rte is used.
Table 5-36 Com_RxIndication
5.4.2
Com_TxConfirmation
Prototype
void Com_TxConfirmation (PduIdType TxPduId)
Parameter
TxPduId
ID of AUTOSAR COM I-PDU that has been transmitted. Range: 0..(maximum
number of I-PDU IDs transmitted by AUTOSAR COM) - 1
Return code
void
none
Functional Description
This function is called by the lower layer after the PDU has been transmitted on the network. A confirmation
that is received for an I-PDU that does not require a confirmation is silently discarded.
Particularities and Limitations
The function is called by the lower layer.
Call Context
The function can be called on interrupt and task level. It is not allowed to use CAT1 interrupts with Rte
(BSW00326]). Due to this, the interrupt context shall be configured to a CAT2 interrupt if an Rte is used.
Table 5-37 Com_TxConfirmation
5.4.3
Com_TriggerTransmit
Prototype
Std_ReturnType Com_TriggerTransmit (PduIdType TxPduId, PduInfoType
*PduInfoPtr)
Parameter
TxPduId
ID of AUTOSAR COM I-PDU that is requested to be transmitted by AUTOSAR
COM.
© 2017 Vector Informatik GmbH
Version 5.05.00
71
based on template version 5.6.0
Technical Reference MICROSAR COM
PduInfoPtr
Contains a pointer to a buffer (SduDataPtr) where the SDU data shall be
copied to, and the available buffer size in SduLengh. On return, the service
will indicate the length of the copied SDU data in SduLength.
Return code
Std_ReturnType
E_OK: SDU has been copied and SduLength indicates the number of copied
bytes.
E_NOT_OK: No data has been copied, because Com is not initialized or
TxPduId is not valid or PduInfoPtr is NULL_PTR or SduDataPtr is NULL_PTR
or SduLength is too small.
Functional Description
This function is called by the lower layer when an AUTOSAR COM I-PDU shall be transmitted. Within this
function, AUTOSAR COM shall copy the contents of its I-PDU transmit buffer to the L-PDU buffer given by
SduPtr. Use case: This function is used e.g. by the LIN Master for sending out a LIN frame. In this case, the
trigger transmit can be initiated by the Master schedule table itself or a received LIN header. This function
is also used by the FlexRay Interface for requesting PDUs to be sent in static part (synchronous to the
FlexRay global time). Once the I-PDU has been successfully sent by the lower layer (PDU-Router), the
lower layer must call Com_TxConfirmation().
Particularities and Limitations
The function is called by the lower layer.
Call Context
The function can be called on interrupt and task level. It is not allowed to use CAT1 interrupts with Rte
(BSW00326]). Due to this, the interrupt context shall be configured to a CAT2 interrupt if an Rte is used.
Table 5-38 Com_TriggerTransmit
5.4.4
Com_TpTxConfirmation
Prototype
void Com_TpTxConfirmation (PduIdType PduId, Std_ReturnType Result)
Parameter
PduId
ID of the I-PDU that has been transmitted.
Result
Result of the transmission of the I-PDU
Return Code
void
None.
Functional Description
This function is called by the PduR after a large I-PDU has been transmitted via the transport protocol on
its network.
Particularities and Limitations
The function is called by the lower layer.
Pre-Conditions
Call Context
The function can be called on interrupt and task level.
Table 5-39 Com_TpTxConfirmation
© 2017 Vector Informatik GmbH
Version 5.05.00
72
based on template version 5.6.0
Technical Reference MICROSAR COM
5.4.5
Com_CopyTxData
Prototype
BufReq_ReturnType Com_CopyTxData (PduIdType PduId, PduInfoType
*PduInfoPtr, RetryInfoType *RetryInfoPtr, PduLengthType *TxDataCntPtr)
Parameter
PduId
ID of Com TP I-PDU to be transmitted.
PduInfoPt
Pointer to a PduInfoType, which indicates the number of bytes to be copied
(SduLength) and the location where the data have to be copied to
(SduDataPtr). An SduLength of 0 is possible in order to poll the available
transmit data count. In this case no data are to be copied and SduDataPtr
might be invalid.
RetryInfoPtr
The COM module ignores the value of this pointer, since it always keeps the
complete buffer until the transmission of a large I-PDU is either confirmed or
aborted.
TxDataCntPtr
Out parameter: Remaining Tx data after completion of this call.
Return Code
BufReq_ReturnType
BufReq_ReturnType BUFREQ_OK: Data has been copied to the transmit
buffer completely as requested. BUFREQ_E_BUSY: The transmission buffer
is actually not available (implementation specific). BUFREQ_E_NOT_OK:
Data has not been copied. Request failed, in case the corresponding I-PDU
was stopped.
Functional Description
This function is called by the lower layer to copy Data from the Com TP buffer to the lower layer TP buffer.
Particularities and Limitations
The function is called by the lower layer.
Pre-Conditions
Call Context
The function can be called on interrupt and task level.
Table 5-40 Com_CopyTxData
5.4.6
Com_TpRxIndication
Prototype
void Com_TpRxIndication (PduIdType PduId, Std_ReturnType Result)
Parameter
PduId
ID of AUTOSAR COM I-PDU that has been received. Identifies the data that
has been received. Range: 0..(maximum number of I-PDU IDs received by
AUTOSAR COM) - 1
Result
Indicates whether the Message was received successfully.
© 2017 Vector Informatik GmbH
Version 5.05.00
73
based on template version 5.6.0
Technical Reference MICROSAR COM
Return Code
void
none
Functional Description
This function is called by the lower layer after a TP I-PDU has been received.
Particularities and Limitations
The function is called by the lower layer.
Pre-Conditions
Call Context
The function can be called on interrupt and task level. It is not allowed to use CAT1 interrupts with Rte
(BSW00326]). Due to this, the interrupt context shall be configured to a CAT2 interrupt if an Rte is used.
Table 5-41 Com_TpRxIndication
5.4.7
Com_StartOfReception
Prototype
BufReq_ReturnType Com_StartOfReception (PduIdType ComRxPduId,
PduInfoType* TpSduInfoPtr, PduLengthType TpSduLength, PduLengthType
*RxBufferSizePtr)
Parameter
ComRxPduId
ID of AUTOSAR COM I-PDU that has been received. Identifies the data that
has been received.
TpSduInfoPtr
Is currently not used by COM.
TpSduLength
complete length of the TP I-PDU to be received.
RxBufferSizePtr
The Com returns in this value the remaining TP buffer size to the lower layer.
Return Code
BufReq_ReturnType
BufReq_ReturnType BUFREQ_OK: Connection has been accepted.
RxBufferSizePtr indicates the available receive buffer. BUFREQ_E_NOT_OK:
Connection has been rejected. RxBufferSizePtr remains unchanged.
BUFREQ_E_OVFL: In case the configured buffer size as specified via
ComPduIdRef.PduLength is smaller than TpSduLength. BUFREQ_E_BUSY:
In case the reception buffer is actually not available for a new reception
(implementation specific).
Functional Description
This function is called by the lower layer to indicate the start of a incomming TP connection.
Particularities and Limitations
The function is called by the lower layer.
Pre-Conditions
Call Context
The function can be called on interrupt and task level.
Table 5-42 Com_StartOfReception
© 2017 Vector Informatik GmbH
Version 5.05.00
74
based on template version 5.6.0
Technical Reference MICROSAR COM
5.4.8
Com_CopyRxData
Prototype
BufReq_ReturnType Com_CopyRxData (PduIdType PduId, const PduInfoType
*PduInfoPointer, PduLengthType *RxBufferSizePtr)
Parameter
PduId
ID of AUTOSAR COM I-PDU that has been received. Identifies the data that
has been received.
PduInfoPointer
Payload information of the received TP segment (pointer to data and data
length).
RxBufferSizePtr
The Com returns in this value the remaining TP buffer size to the lower layer.
Return Code
BufReq_ReturnType
BufReq_ReturnType BUFREQ_OK: Connection has been accepted.
RxBufferSizePtr indicates the available receive buffer. BUFREQ_E_NOT_OK:
Connection has been rejected. RxBufferSizePtr remains unchanged.
BUFREQ_E_OVFL: In case the configured buffer size as specified via
ComPduIdRef.PduLength is smaller than TpSduLength. BUFREQ_E_BUSY:
In case the reception buffer is actually not available for a new reception
(implementation specific).
Functional Description
This function is called by the lower layer to hand a received TP segment to Com. The Com copies the
received segment in his internal tp buffer.
Particularities and Limitations
The function is called by the lower layer.
Pre-Conditions
Call Context
The function can be called on interrupt and task level.
Table 5-43 Com_CopyRxData
5.5
Configurable Interfaces
5.5.1
Notifications
At its configurable interfaces the COM defines notifications that can be mapped to callback
functions provided by other modules. The mapping is not statically defined by the COM but
can be performed at configuration time. The function prototypes that can be used for the
configuration have to match the appropriate function prototype signatures, which are
described in the following sub-chapters.
5.5.1.1
Indication Notification
Prototype
void [Indication Notification Name] ( void )
Parameter
void
none
© 2017 Vector Informatik GmbH
Version 5.05.00
75
based on template version 5.6.0
Technical Reference MICROSAR COM
Return code
void
none
Functional Description
The notification function is called after the message has been received successfully. The function can be
configured for signals and signal groups with a configurable function name.
Particularities and Limitations
> none
Call Context
> The call context depends on the configuration of the parameter ComIPduSignalProcessing for
the I-PDU.
Table 5-44 Indication Notification
5.5.1.2
Confirmation Notification
Prototype
void [Confirmation Notification Name] ( void )
Parameter
void
none
Return code
void
none
Functional Description
The notification function is called after successful transmission of the I-PDU containing the message. The
function can be configured for signals and signal groups with a configurable function name.
Particularities and Limitations
> none
Call Context
> The call context depends on the configuration of the parameter ComIPduSignalProcessing for
the I-PDU.
Table 5-45 Confirmation Notification
5.5.1.3
Rx Timeout Notification
Prototype
void [Rx Timeout Notification Name] ( void )
Parameter
void
none
Return code
void
none
© 2017 Vector Informatik GmbH
Version 5.05.00
76
based on template version 5.6.0
Technical Reference MICROSAR COM
Functional Description
It is called immediately after a message reception error has been detected by the deadline monitoring
mechanism. The function can be configured for signals with a configurable function name.
Particularities and Limitations
> none
Call Context
> The function is called on task level.
Table 5-46 Rx Timeout Notification
5.5.1.4
Tx Timeout Notification
Prototype
void [Tx Timeout Notification Name] ( void )
Parameter
void
none
Return code
void
none
Functional Description
It is called immediately after a message transmission error has been detected by the deadline monitoring
mechanism. The function can be configured for signals and signal groups with a configurable function
name.
Particularities and Limitations
> none
Call Context
> The function is called on task level.
Table 5-47 Tx Timeout Notification
5.5.1.5
Error Notification
Prototype
void [Error Notification Name] ( void )
Parameter
void
none
Return code
void
none
Functional Description
It is called immediately for outstanding, not confirmed transmitted signals that are contained in I-PDUs
that get stopped by a call to Com_IpduGroupControl.
Particularities and Limitations
> none
© 2017 Vector Informatik GmbH
Version 5.05.00
77
based on template version 5.6.0
Technical Reference MICROSAR COM
Call Context
> The function is in the context of Com_IpduGroupControl.
Table 5-48 Error Notification
5.5.1.6
Invalid Notification
Prototype
void [Invalid Notification Name] ( void )
Parameter
void
none
Return code
void
none
Functional Description
This notification is called, if an invalid value is received and the invalid action is configured to ‘NOTIFY’.
Particularities and Limitations
> none
Call Context
> The call context depends on the configuration of the parameter ComIPduSignalProcessing for
the I-PDU.
Table 5-49 Invalid Notification
5.5.2
Callout Functions
At its configurable interfaces the COM defines callout functions. The declarations of the
callout functions are provided by the BSW module, i.e. the COM. It is the integrator's task
to provide the corresponding function definitions. The definitions of the callouts can be
adjusted to the system's needs. The COM callout function declarations are described in
the following tables:
5.5.2.1
Rx I-Pdu callout function
If /MICROSAR/Com/ComGeneral/ComAdvancedIPduCallouts is configured to TRUE,
the Rx I-PDU callouts are implemented as specified by AUTOSAR 4.1.1
Prototype
boolean <IPDU_CalloutName> (PduIdType PduId, const PduInfoType*
PduInfoPtr)
Parameter
PduId
ID of AUTOSAR COM I-PDU that has been received. Identifies the data that
has been received.
Range: 0..(maximum number of I-PDU IDs received by AUTOSAR COM) - 1
PduInfoPtr
Contains the length (SduLength) of the received I-PDU and a pointer to a
buffer (SduDataPtr) containing the I-PDU.
© 2017 Vector Informatik GmbH
Version 5.05.00
78
based on template version 5.6.0
Technical Reference MICROSAR COM
Return code
boolean
The return value indicates whether the processing of this I-PDU shall continue
(TRUE) or abandon (FALSE) after the callout returns.
Functional Description
For each I-PDU a callout function can be configured and the implementation has to be provided by the
application. It can be used to extend the COM functionality with application related functions (e.g. CRC or
sequence counter calculation).
Particularities and Limitations
> In this context, the signal access APIs could not be used to read the signal values, as the
internal buffer is not updated yet and the old values are returned.
Call Context
> Rx I-PDU Callouts are called by COM directly after Com_RxIndication on task or interrupt
level. The call context depends on the configuration of the Driver.
Table 5-50 Rx I-PDU Callout with PduInfo pointer
If /MICROSAR/Com/ComGeneral/ComAdvancedIPduCallouts is configured to
FALSE, the Rx I-PDU callouts are implemented as specified by AUTOSAR 4.0.3
Prototype
boolean <IPDU_CalloutName> (PduIdType Id, const uint8* IpduData)
Parameter
PduId
ID of AUTOSAR COM I-PDU that has been received. Identifies the data that
has been received.
Range: 0..(maximum number of I-PDU IDs received by AUTOSAR COM) - 1
IpduData
A pointer to the data of the received I-PDU.
Return code
boolean
The return value indicates whether the processing of this I-PDU shall continue
(TRUE) or abandon (FALSE) after the callout returns.
Functional Description
For each I-PDU a callout function can be configured and the implementation has to be provided by the
application. It can be used to extend the COM functionality with application related functions (e.g. CRC or
sequence counter calculation).
Particularities and Limitations
> In this context, the signal access APIs could not be used to read the signal values, as the
internal buffer is not updated yet and the old values are returned.
Call Context
> Rx I-PDU Callouts are called by COM directly after Com_RxIndication on task or interrupt
level. The call context depends on the configuration of the Driver.
Table 5-51 Rx I-PDU Callout with data pointer
© 2017 Vector Informatik GmbH
Version 5.05.00
79
based on template version 5.6.0
Technical Reference MICROSAR COM
Caution
If /MICROSAR/Com/ComGeneral/ComAdvancedIPduCallouts is configured to FALSE,
the current length of the PDU payload cannot be evaluated within the configured
callout.
5.5.2.2
Tx I-Pdu callout function
If /MICROSAR/Com/ComGeneral/ComAdvancedIPduCallouts is configured to TRUE, the
Tx I-PDU callouts are implemented as specified by AUTOSAR 4.1.1
Prototype
boolean <IPDU_CalloutName> (PduIdType PduId, PduInfoType*
PduInfoPtr)
Parameter
PduId
ID of AUTOSAR COM I-PDU that should be transmitted. Identifies the data
that should be transmitted.
Range: 0..(maximum number of I-PDU IDs transmitted by AUTOSAR COM) -
1
PduInfoPtr
Contains the length (SduLength) of the I-PDU to be transmitted and a pointer
to a buffer (SduDataPtr) containing the I-PDU.
Return code
boolean
The return value indicates whether the processing of this I-PDU shall continue
(TRUE) or abandon (FALSE) after the callout returns.
Functional Description
For each I-PDU a callout function can be configured and the implementation has to be provided by the
application. It can be used to extend the COM functionality with application related functions (e.g. CRC or
sequence counter calculation).
Particularities and Limitations
> In this context the signal access APIs can be used to update the signal values, as these APIs
directly updates the internal buffer. If a triggered event is caused by such a call, no additional
transmission of the I-PDU is triggered.
Call Context
> Tx I-PDU Callouts are called by COM directly before the call of PduR_ComTransmit on task
level.
> Tx I-PDU Trigger Transmit Callouts are called by COM in the function Com_TriggerTransmit.
The call context depends on the configuration of the lower layer.
Table 5-52 Tx I-PDU Callout with PduInfo pointer
If /MICROSAR/Com/ComGeneral/ComAdvancedIPduCallouts is configured to FALSE, the
Tx I-PDU callouts are implemented as specified by AUTOSAR 4.0.3
Prototype
boolean <IPDU_CalloutName> (PduIdType Id, uint8* IpduData)
© 2017 Vector Informatik GmbH
Version 5.05.00
80
based on template version 5.6.0
Technical Reference MICROSAR COM
Parameter
Id
ID of AUTOSAR COM I-PDU that should be transmitted. Identifies the data
that should be transmitted.
Range: 0..(maximum number of I-PDU IDs transmitted by AUTOSAR COM) -
1
IpduData
A pointer to the data of the received I-PDU.
Return code
boolean
The return value indicates whether the processing of this I-PDU shall continue
(TRUE) or abandon (FALSE) after the callout returns.
Functional Description
For each I-PDU a callout function can be configured and the implementation has to be provided by the
application. It can be used to extend the COM functionality with application related functions (e.g. CRC or
sequence counter calculation).
Particularities and Limitations
> In this context the signal access APIs can be used to update the signal values, as these APIs
directly updates the internal buffer. If a triggered event is caused by such a call, no additional
transmission of the I-PDU is triggered.
Call Context
> Tx I-PDU Callouts are called by COM directly before the call of PduR_ComTransmit on task
level.
> Tx I-PDU Trigger Transmit Callouts are called by COM in the function Com_TriggerTransmit.
The call context depends on the configuration of the lower layer.
Table 5-53 Tx I-PDU Callout with data pointer
© 2017 Vector Informatik GmbH
Version 5.05.00
81
based on template version 5.6.0
Technical Reference MICROSAR COM
6 Configuration
6.1
Configuration of Post-Build
The configuration of post-build loadable is described in [5].
© 2017 Vector Informatik GmbH
Version 5.05.00
82
based on template version 5.6.0
Technical Reference MICROSAR COM
7 AUTOSAR Standard Compliance
7.1
Limitations
Component Limitations
TRUE must be defined to (boolean) 1
FALSE must be defined to (boolean) 0
NULL_PTR must be defined to ((void *)0)
Since 8-bit micro controllers are out of scope in AUTOSAR, COM has been optimized for
the usage on 16- and 32-bit controllers. Therefore the target system must be able to
provide atomic read and write accesses to 16-bit variables.
© 2017 Vector Informatik GmbH
Version 5.05.00
83
based on template version 5.6.0
Technical Reference MICROSAR COM
8 Glossary and Abbreviations
8.1
Glossary
Term
Description
CFG5
DaVinci Configurator
Table 8-1 Glossary
8.2
Abbreviations
Abbreviation
Description
API
Application Programming Interface
AUTOSAR
Automotive Open System Architecture
BSW
Basis Software
DEM
Diagnostic Event Manager
DET
Development Error Tracer
EAD
Embedded Architecture Designer
ECU
Electronic Control Unit
HIS
Hersteller Initiative Software
ISR
Interrupt Service Routine
MICROSAR
Microcontroller Open System Architecture (the Vector AUTOSAR
solution)
RTE
Runtime Environment
SRS
Software Requirement Specification
SWC
Software Component
SWS
Software Specification
Table 8-2 Abbreviations
© 2017 Vector Informatik GmbH
Version 5.05.00
84
based on template version 5.6.0
Technical Reference MICROSAR COM
9 Contact
Visit our website for more information on
News
Products
Demo software
Support
Training data
Addresses
www.vector.com
© 2017 Vector Informatik GmbH
Version 5.05.00
85
based on template version 5.6.0
Document Outline
- 1 Component History
- 2 Introduction
- 3 Functional Description
- 3.1 Features
- 3.1.1 Signal Types
- 3.1.2 Signal Processing
- 3.1.3 Transmission of a Signal
- 3.1.4 Transmission of a Signal Group
- 3.1.5 Transmission Mode Selector
- 3.1.6 Explicit Transmission Mode State Switch
- 3.1.7 Transmit Signal Filters
- 3.1.8 Minimum Send Distance of an I-PDU
- 3.1.9 Minimum Send Distance only for Direct Send Triggers
- 3.1.10 Transmission Deadline Monitoring
- 3.1.11 Replication of Signal Transmission Requests
- 3.1.12 Reception of a Signal
- 3.1.13 Reception of a Signal Group
- 3.1.14 Array-based access of SignalGroups
- 3.1.15 Dynamic DLC
- 3.1.16 Reception Deadline Monitoring
- 3.1.17 Invalidation Mechanism
- 3.1.18 Signal Reception Filtering
- 3.1.19 Signal Status Information
- 3.1.20 Signal Gateway
- 3.1.21 Gateway Description Routing
- 3.1.22 Large I-PDUs
- 3.1.23 Dynamic length signals
- 3.1.24 Com Optimizations
- 3.2 Initialization
- 3.3 States
- 3.4 Main Functions
- 3.5 Error Handling
- 3.1 Features
- 4 Integration
- 5 API Description
- 5.1 Type Definitions
- 5.2 Services provided by COM
- 5.2.1 Com_Init
- 5.2.2 Com_InitMemory
- 5.2.3 Com_DeInit
- 5.2.4 Com_IpduGroupControl
- 5.2.5 Com_ReceptionDMControl
- 5.2.6 Com_IpduGroupStart
- 5.2.7 Com_IpduGroupStop
- 5.2.8 Com_EnableReceptionDM
- 5.2.9 Com_DisableReceptionDM
- 5.2.10 Com_GetConfigurationId
- 5.2.11 Com_GetStatus
- 5.2.12 Com_GetVersionInfo
- 5.2.13 Com_TriggerIPDUSend
- 5.2.14 Com_TriggerIPDUSendWithMetaData
- 5.2.15 Com_ClearIpduGroupVector
- 5.2.16 Com_SetIpduGroup
- 5.2.17 Com_ReceiveDynSignal
- 5.2.18 Com_ReceiveSignalGroup
- 5.2.19 Com_ReceiveSignalGroupArray
- 5.2.20 Com_InvalidateSignal
- 5.2.21 Com_InvalidateSignalGroup
- 5.2.22 Com_SwitchIpduTxMode
- 5.2.23 Com_SendDynSignal
- 5.2.24 Com_SendSignal
- 5.2.25 Com_SendSignalGroup
- 5.2.26 Com_SendSignalGroupArray
- 5.2.27 Com_MainFunctionRx
- 5.2.28 Com_MainFunctionTx
- 5.2.29 Com_MainFunctionRouteSignals
- 5.2.30 Com_ReceiveSignal
- 5.2.31 Com_ReceiveShadowSignal
- 5.2.32 Com_UpdateShadowSignal
- 5.2.33 Com_InvalidateShadowSignal
- 5.3 Services used by COM
- 5.4 Callback Functions
- 5.5 Configurable Interfaces
- 6 Configuration
- 7 AUTOSAR Standard Compliance
- 8 Glossary and Abbreviations
- 9 Contact