Autosar Document
https://www.autosar.org/nc/document-search/

Autosar word count
https://qiita.com/kaizen_nagoya/items/0927727a94b157df2df8

Make list of reference, abbreviation and term.
0: not detect
1: same as another

No. Number in the AUTOSAR document list
https://qiita.com/kaizen_nagoya/items/25bac8e0e14bda6067ec

This document is a series of the below
Autosar list of reference, abbreviation and term.(47/237): English(40)
https://qiita.com/kaizen_nagoya/items/2325b0156bc7fcf5a96d

Autosar list of reference, abbreviation and term.(48-96/237): English(40a)
https://qiita.com/kaizen_nagoya/items/3161832363290ee75800

140 Specification of Flash EEPROM Emulation

2 Acronyms and abbreviations

Acronyms and abbreviations which have a local scope and therefore are not contained in the AUTOSAR glossary must appear in a local glossary.

Abbreviation / Acronym	Description
EA	EEPROM Abstraction
EEPROM	Electrically Erasable and Programmable ROM (Read Only Memory)
FEE	Flash EEPROM Emulation
LSB	Least significant bit / byte (depending on context). Here, “bit” is meant.
MemIf	Memory Abstraction Interface
MSB	Most significant bit / byte (depending on context). Here, “bit” is meant.
NvM	NVRAM Manager
NVRAM	Non-volatile RAM (Random Access Memory)

term	Description
NVRAM block	Management unit as seen by the NVRAM Manager
(Logical) block	Smallest writable / erasable unit as seen by the modules user. Consists of one or more virtual pages.
Virtual page	May consist of one or several physical pages to ease handling of logical blocks and address calculation.
Internal residue	Unused space at the end of the last virtual page if the configured block size isn’t an integer multiple of the virtual page size (see Figure 3)).
Virtual address	Consisting of 16 bit block number and 16 bit offset inside the logical block.
Physical address	Address information in device specific format (depending on the underlying EEPROM driver and device) that is used to access a logical block.
Dataset	Concept of the NVRAM manager: A user addressable array of blocks of the same size.E.g. could be used to provide different configuration settings for the CAN driver (CAN IDs, filter settings, ...) to an ECU which has otherwise identical application software (e.g. door module).
Redundant copy	Concept of the NVRAM manager:Storing the same information twice to enhance reliability of data storage.

3 Related documentation 3.1 Inputdocuments

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture..pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[5] Requirements on Memory Hardware Abstraction Layer AUTOSAR_SRS_MemoryHWAbstractionLayer.doc
[6] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[7] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[8] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[9] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[10] AUTOSAR Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager.doc
[11] Specification of Memory Abstraction Interface AUTOSAR_SWS_MemoryAbstractionInterface.pdf
[12] Specification of EEPROM Abstraction AUTOSAR_SWS_EEPROMAbstraction.pdf

139 Specification of Flash Driver

2 Acronyms and abbreviations

Further definitions of terms used throughout this document

Abbreviation / Acronym	Description
DET	Default Error Tracer – module to which development errors are reported.
DEM	Diagnostic Event Manager – module to which production relevant errors are reported.
Fls, FLS	Official AUTOSAR abbreviation for the module flash driver (different writing depending on the context, same meaning).
AC	(Flash) access code – abbreviation introduced to keep the names of the configuration parameters reasonably short.

Term	Definition
Flash sector	A flash sector is the smallest amount of flash memory that can be erased in one pass. The size of the flash sector depends upon the flash technology and is therefore hardware dependent.
Flash page	A flash page is the smallest amount of flash memory that can be programmed in one pass. The size of the flash page depends upon the flash technology and is therefore hardware dependent.
Flash access code	Internal flash driver routines called by the main function (job processing function) to erase or write the flash hardware.

3 Related documentation 3.1 AUTOSARdeliverables

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[5] Requirements on Flash Driver AUTOSAR_SRS_FlashDriver.pdf
[6] Requirements on Memory Hardware Abstraction Layer AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf
[7] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[8] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[9] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

138 Specification of Execution Management

2 Acronyms and abbreviations

All technical terms used throughout this document – except the ones listed here – can be found in the official [3] AUTOSAR Glossary or [4] TPS Manifest Specification.
Certain requirements necessitate the specification of mandatory whitespace. This is indicated by ‘ ’ in the requirement text.

Term	Description
Application	An implementation that resolves a set of coherent functional re- quirements and is the result of functional development. An Ap- plication is the unit of delivery for Machine specific configu- ration and integration.
Executable	Part of an Application. It consists of executable code (with exactly one entry point) created at integation time that can be deployed and installed on a Machine. An Application may consist of one or more Executables, each of which can be de- ployed to different Machines.
Process	A Process is an instance of an Executable to be executed on a Machine and has a 1:1 association with the ARXML/Meta- Model element with the same name. This document also uses the term process (without a capital "P") to refer to the OS con- cept of a running process.
Attention: Process != process. Hence each Process has at some time a related process but a process may not always have a related Process.
Reporting Process	A type of Process with an associated Executable where re- portingBehavior is omitted ([TPS_MANI_01279]) or set to reportsExecutionState. Such a Process is expected to report its Execution State to Execution Management.
Non-reporting Process	A type of Process with an associated Executable where re- portingBehavior set to doesNotReportExecutionState. Such a Process is not expected to report its Execution State to Execution Management.
Self-terminating Process	A type of Process that self initiate termination procedure, please note that for a standard Process this procedure is initiated by Execution Management.
Execution Dependency	Dependencies between Executable instances can be config- ured to define a sequence for starting and terminating them.
Execution Management	The element of the AUTOSAR Adaptive Platform responsi- blefortheorderedstartupandshutdownoftheAUTOSAR Adap- tive Platform and the Applications.
State Management	The element of AUTOSAR Adaptive Platform defining modes of operation. It allows flexible definition of functions which are active on the platform at any given time.
Function Group	A Function Group is a set of coherent Processes, which need to be controlled consistently. Depending on the state of the Function Group, Processes are started or terminated. Processes can belong to more than one Function Group State (but at exactly one Function Group). "MachineState" is a Function Group with a predefined name, which is mainly used to control Machine lifecycle and Processes of platform level Applications. Other Function Groups are sort of general purpose tools used (for example) to control Processes of user level Applications.
Function Group State	The state of a Function Group (except "MachineState"). It defines a set of active Applications for any certain situation. The set of Function Groups and their states is machine spe- cific and is deployed as part of the Machine Manifest.
Machine State	The state of Function Group "MachineState" with some predefined states (Startup/Shutdown/Restart).
Time Determinism	The results of a calculation are guaranteed to be available before a given deadline.
Data Determinism	The results of a calculation only depend on the input data and are reproducible, assuming a given initial internal state.
Full Determinism	Combination of Time and Data Determinism.
Communication Management	A Functional Cluster within the Adaptive Platform Foundation
Execution Manifest	Manifest file to configure execution of an Adaptive Appli- cation. An Execution Manifest is created at integration time and deployed onto a Machine together with the Exe- cutable to which it is attached. It supports the integration of the Executable code and describes the configuration properties (startup parameters, resource group assignment etc.) of each Process, i.e. started instance of that Executable.
Machine Manifest	Manifest file to configure a Machine. The Machine Man- ifest holds all configuration information which cannot be as- signed to a specific Executable or Process.
Operating System	Software responsible for managing Processes on a Machine and for providing an interface to hardware resources.
ResourceGroup	Configuration element to enable restrictions on resources uses by Adaptive Applications running in the group.
ExecutionClient	Adaptive Application interface to Execution Manage- ment.
DeterministicClient	Adaptive Application interface to Execution Manage- ment to support control of the process-internal cycle, a determin- istic worker pool, activation time stamps and random numbers.
StateClient	State Management interface to Execution Management to support Function Group State and Machine State man- agement.
Platform Health Management	A Functional Cluster within the Adaptive Platform Foundation
Recovery Action	Actions defined by the integrator to control Adaptive Appli- cation error recovery.
Process State	Lifecycle state of a Process
Service Instance Manifest	Manifest file to configure Service usage of an Adaptive Application.
Adaptive Application	see [3] AUTOSAR Glossary
Application	see [3] AUTOSAR Glossary
AUTOSAR Adaptive Platform	see [3] AUTOSAR Glossary
Adaptive Platform Foundation	see [3] AUTOSAR Glossary
Adaptive Platform Services	see [3] AUTOSAR Glossary
Manifest	see [3] AUTOSAR Glossary
Executable	see [3] AUTOSAR Glossary
Functional Cluster	see [3] AUTOSAR Glossary
Machine	see [3] AUTOSAR Glossary
Service	see [3] AUTOSAR Glossary
Service Interface	see [3] AUTOSAR Glossary
Service Discovery	see [3] AUTOSAR Glossary

3 Related documentation

3.1 Input documents & related standards and norms
ThemaindocumentsthatserveasinputforthespecificationoftheExecution Man- agement are:
[1] Key words for use in RFCs to Indicate Requirement Levels http://www.ietf.org/rfc/rfc2119.txt
[2] Specification of Communication Management AUTOSAR_SWS_CommunicationManagement
[3] Glossary AUTOSAR_TR_Glossary
[4] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[5] General Specification of Adaptive Platform AUTOSAR_SWS_General
[6] Requirements on Execution Management AUTOSAR_RS_ExecutionManagement
[7] Specification of Operating System Interface AUTOSAR_SWS_OperatingSystemInterface
[8] Specification of Persistency AUTOSAR_SWS_Persistency
[9] Specification of Platform Health Management for Adaptive Platform AUTOSAR_SWS_PlatformHealthManagement
[10] Methodology for Adaptive Platform AUTOSAR_TR_AdaptiveMethodology
[11] Specification of State Management AUTOSAR_SWS_StateManagement
[12] Guidelines for using Adaptive Platform interfaces AUTOSAR_EXP_AdaptivePlatformInterfacesGuidelines
[13] Standard for Information Technology–Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7 http://pubs.opengroup.org/onlinepubs/9699919799/
[14] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, ’Basic Concepts and Taxonomy of Dependable and Secure Computing’, IEEE Transac- tions on Dependable and Secure Computing, Vol. 1, No. 1, January-March 2004
[15] Explanation of Adaptive Platform Design AUTOSAR_EXP_PlatformDesign

137 Specification of Ethernet Transceiver Driver

2 Acronyms and abbreviations

Abbreviation / Acronym	Description
EC	Ethernet controller
ET	Ethernet transceiver
Eth	Ethernet Controller Driver (AUTOSAR BSW module)
EthIf	Ethernet Interface (AUTOSAR BSW module)
EthTrcv	Ethernet Transceiver Driver (AUTOSAR BSW module)
MCG	Module Configuration Generator
MII	Media Independent Interface (standardized Interface provided by Ethernet controllers to access Ethernet transceivers, see [21])

3 Related documentation 3.1 Input documents

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of Communication AUTOSAR_SWS_COM.pdf
[5] Requirements on Ethernet Support in AUTOSAR AUTOSAR_SRS_Ethernet.pdf
[6] Specification of Ethernet Interface AUTOSAR_SWS_EthernetInterface.pdf
[7] Specification of Ethernet State Manager AUTOSAR_SWS_EthernetStateManager.pdf
[8] Specification of Ethernet Interface AUTOSAR_SWS_EthernetInterface.pdf
[9] Specification of Socket Adapter AUTOSAR_SWS_SocketAdapter.pdf
[10] Specification of UDP Network Management AUTOSAR_SWS_UDPNetworkManagement.pdf
[11] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[12] BSW Scheduler Specification AUTOSAR_SWS_Scheduler.pdf
[13] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[14] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[15] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[16] Specification of Default Error Tracer AUTOSAR_SWS_ DefaultErrorTracer.pdf
[17] Specification of Diagnostics Event Manager AUTOSAR_SWS_DiagnosticEventManager
[18] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[19] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

3.2 Related standards and norms

[20] IEC 7498-1 The Basic Model, IEC Norm, 1994 [21] IEEE 802.3-2006

136 Specification of Ethernet State Manager

2 Acronyms and abbreviations

Abbreviation / Acronym	Description
API	Application Program Interface
BSW	Basic Software
BswM	Basic Software Mode Manager
ComM	Communication Manager
DEM	Diagnostic Event Manager
DET	Default Error Tracer
EcuM	ECU State Manager
Eth	Ethernet Controller
EthTrcv	Ethernet Transceiver
EthSM	Ethernet State Manager
EthIf	Ethernet Interface
SchM	BSW Scheduler
SoAd	Socket Adapter

3 Related documentation 3.1 Inputdocuments

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of AUTOSAR COM AUTOSAR_SWS_COM.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[7] Specification of Communication Manager AUTOSAR_SWS_ComManager.pdf
[8] Requirements on Mode Management AUTOSAR_SRS_ModeManagement.pdf
[9] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[10] Specification of the Ethernet Interface AUTOSAR_SWS_EthernetInterface.pdf
[11] Requirements on Ethernet in AUTOSAR AUTOSAR_SRS_Ethernet.pdf
[12] Specification of Standard Types AUTOSAR_SWS_StandardTypes
[13] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[14] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[15] Specification of Basic Software Mode Manager
AUTOSAR_SWS_BSWModeManager.pdf
[16] Specification of Basic Software Mode Manager AUTOSAR_SWS_SocketAdapter.pdf
[17] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[18] Specification of TcpIp module AUTOSAR_SWS_TcpIp.pdf

135 Specification of Ethernet Interface

2 Acronyms and abbreviations

Abbreviation / Acronym	Description
CBR	Channel Busy Ratio
CIT	Channel Idle Time
Eth	Ethernet Controller Driver (AUTOSAR BSW module)
EthIf	Ethernet Interface (AUTOSAR BSW module)
EthSM	Ethernet State Manager (AUTOSAR BSW module)
EthTrcv	Ethernet Transceiver Driver (AUTOSAR BSW module)
IP	Internet Protocol
MCG	Module Configuration Generator
MII	Media Independent Interface (standardized Interface provided by Ethernet controllers to access Ethernet transceivers)
RSSI	Received Signal Strength Indicator
TCP	Transmission Control Protocol
TCP/IP Stack	Ethernet communication stack
VLAN	Virtual Local Area Network
WEth	Wireless Ethernet Driver
WEthTrcv	Wireless Ethernet Transceiver Driver

3 Related documentation 3.1 Input documents

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Requirements on Ethernet Support in AUTOSAR AUTOSAR_SRS_Ethernet.pdf
[5] Specification of Ethernet Driver AUTOSAR_SWS_EthernetDriver.pdf
[6] Specification of Ethernet State Manager AUTOSAR_SWS_EthernetStateManager.pdf
[7] Specification of Ethernet Transceiver Driver AUTOSAR_SWS_EthernetTransceiver.pdf
[8] Specification of TCP/IP AUTOSAR_SWS_TcpIp.pdf
[9] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[10] BSW Scheduler Specification AUTOSAR_SWS_Scheduler.pdf
[11] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[12] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[13] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[14] Specification of Default Error Tracer AUTOSAR_SWS_DefaulttErrorTracer.pdf
[15] Specification of Diagnostics Event Manager AUTOSAR_SWS_DiagnosticEventManager
[16] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[17] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[18] AUTOSAR Specification of Global Time Synchronization over Ethernet AUTOSAR_SWS_TimeSyncOverEthernet.pdf
[19] AUTOSAR Specification of Ethernet Switch Driver AUTOSAR_SWS_EthernetSwitchDriver.pdf
[20] Wireless Ethernet Driver AUTOSAR_SWS_WirelessEthernetDriver.pdf
[21] Wireless Ethernet Transceiver Driver AUTOSAR_SWS_WirelessEthernetTransceiverDriver.pdf
3.2 Related standards and norms
[22] IEC 7498-1 The Basic Model, IEC Norm, 1994
[23] IEEE 802.3-2006
[24] IEEE 802.1Q-2011

134 Specification of Ethernet Driver

2 Acronyms and abbreviations

Abbreviation / Acronym	Description
EC	Ethernet controller
Eth	Ethernet Driver (AUTOSAR BSW module)
EthIf	Ethernet Interface (AUTOSAR BSW module)
EthTrcv	Ethernet Transceiver Driver (AUTOSAR BSW module)
ISR	Interrupt Service Routine
MCG	Module Configuration Generator
MII	Media Independent Interface (standardized Interface provided by Ethernet controllers to access Ethernet transceivers)
TCP	Transmission Control Protocol
UDP	User Datagram Protocol

3 Related documentation 3.1 Inputdocuments

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of Communication AUTOSAR_SWS_COM.pdf
[5] Requirements on Ethernet Support in AUTOSAR AUTOSAR_SRS_Ethernet.pdf
[6] Specification of Ethernet Interface AUTOSAR_SWS_EthernetInterface.pdf
[7] Specification of Ethernet State Manager AUTOSAR_SWS_EthernetStateManager.pdf
[8] Specification of Ethernet Transceiver Driver AUTOSAR_SWS_EthernetTransceiver.pdf
[9] Specification of Socket Adapter AUTOSAR_SWS_SocketAdapter.pdf
[10] Specification of UDP Network Management AUTOSAR_SWS_UDPNetworkManagement.pdf
[11] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[12] BSW Scheduler Specification AUTOSAR_SWS_Scheduler.pdf
[13] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[14] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[15] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[16] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[17] Specification of Diagnostics Event Manager AUTOSAR_SWS_DiagnosticEventManager
[18] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[19] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

3.2 Relatedstandardsandnorms

[20] IEEE 802.3-2006
[21] IEC 7498-1 The Basic Model, IEC Norm, 1994
[22] IETF RFC 2819
[23] IEEE Standard 802.1ASTM- 30 of March 2011
http://standards.ieee.org/getieee802/download/802.1AS-2011.pdf

133 Specification of Extended Fixed Point Routines

2 Acronyms and abbreviations

Acronyms and abbreviations, which have a local scope and therefore are not contained in the AUTOSAR glossary, must appear in a local glossary.

Abbreviation / Description	Acronym
Arcsin	Inverse Sine
Arccos	Inverse Cosine
BSW	Basic Software
Cos	Cosine
DET	Default Error Tracer
EFX	Extended Mathematical library – Fixed point
Hypot	Hypotenuse
HpFilter	High pass filter
LpFilterFac1	Low pass filter with a factor of 1 (included in [0, 1])
LpFilter	Low pass filter
Mn	Mnemonic
Lib	Library
Sqrt	Square root
Sin	Sine
SWS	Software Specification
SRS	Software Requirement Specification
u8	Mnemonic for the uint8, specified in AUTOSAR_SWS_PlatformTypes
u16	Mnemonic for the uint16, specified in AUTOSAR_SWS_PlatformTypes
u32	Mnemonic for the uint32, specified in AUTOSAR_SWS_PlatformTypes
s8	Mnemonic for the sint8, specified in AUTOSAR_SWS_PlatformTypes
s16	Mnemonic for the sint16, specified in AUTOSAR_SWS_PlatformTypes
s32	Mnemonic for the sint32, specified in AUTOSAR_SWS_PlatformTypes
s64	Mnemonic for the sint64, specified in AUTOSAR_SWS_PlatformTypes
u64	Mnemonic for the uint64, specified in AUTOSAR_SWS_PlatformTypes

3 Specification of Extended Fixed Point Routines AUTOSAR CP R19-11

Related documentation 3.1 Inputdocuments
[1] List of Basic Software Modules, AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[5] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[6] Specification of Platform Types, AUTOSAR_SWS_PlatformTypes.pdf
[7] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[8] Requirement on Libraries, AUTOSAR_SRS_Libraries.pdf
[9] Specification of Memory Mapping, AUTOSAR_SWS_MemoryMapping.pdf
3.2 Relatedstandardsandnorms
[10] ISO/IEC 9899:1990 Programming Language – C

132 Specification of EEPROM Driver

2 Acronyms and abbreviations

Acronym	Description
Data block	A data block may contain 1..n bytes and is used within the API of the EEPROM driver. Data blocks are passed with, Address offset in EEPROM, Pointer to memory location, Length to the EEPROM driver.
Data unit	The smallest data entity in EEPROM. The entities may differ for read/write/erase operation.
Example 1(EEPROM Data unit)	Motorola STAR12 Read: 1 byte, Write: 2 bytes,Erase: 4 bytes
Example 2(EEPROM Data unit)	external SPI EEPROM device Read/Write/Erase: 1 byte
Normal mode Burst mode	Some external SPI EEPROM devices provide the possibility of different access modes:
Normal mode	The data exchange with the EEPROM device via SPI is performed byte wise. This allows for cooperative SPI usage together with other SPI devices like I/O ASICs, external watchdogs etc.
Burst mode	The data exchange with the EEPROM device via SPI is performed block wise. The block size depends on the EEPROM properties, an example is 64 bytes. Because large blocks are transferred, the SPI is blocked by the EEPROM access in burst mode. This mode is used during ECU start-up and shut-down phases where fast reading/writing of data is required.
EEPROM cell	Smallest physical unit of an EEPROM device that holds the data. Usually 1 byte.

Abbreviation	Description
EEPROM	Electrically Erasable and Programmable Read Only Memory
NVRAM	Non Volatile Random Access Memory
NvM	Module name of NVRAM Manager
EcuM	Module name of ECU State Manager
DEM	Module name of Diagnostic Event Manager
DET	Module name of Default Error Tracer

3 Related documentation 3.1 Inputdocuments

[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] Specification of Memory Abstraction Interface AUTOSAR_SWS_MemoryAbstractionInterface.pdf
[4] Specification of SPI Handler/Driver AUTOSAR_SWS_SPIHandlerDriver.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] Requirements on EEPROM Driver AUTOSAR_SRS_EEPROMDriver.pdf
[7] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[8] Specification of Diagnostics Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[9] AUTOSAR Glossary AUTOSAR_TR_Glossary.pdf
[10] Specification of MCU Driver AUTOSAR_SWS_MCUDriver.pdf
[11] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[13] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

131 Specification of EEPROM Abstraction

2 Acronyms and abbreviations

Acronyms and abbreviations which have a local scope and therefore are not contained in the AUTOSAR glossary must appear in a local glossary.
Specification of EEPROM Abstraction AUTOSAR CP R19-11

Abbreviation / Acronym	Description
EA	EEPROM Abstraction
EEPROM	Electrically Erasable and Programmable ROM (Read Only Memory)
FEE	Flash EEPROM Emulation
LSB	Least significant bit / byte (depending on context). Here it’s bit.
MemIf	Memory Abstraction Interface
MSB	Most significant bit / byte (depending on context). Here it’s bit.
NvM	NVRAM Manager
NVRAM	Non-volatile RAM (Random Access Memory)

Term	Description
NVRAM block	Management unit as seen by the NVRAM Manager
(Logical) block	Smallest writable / erasable unit as seen by the modules user. Consists of one or more virtual pages.
Virtual page	May consist of one or several physical pages to ease handling of logical blocks and address calculation.
Internal residue	Unused space at the end of the last virtual page if the configured block size isn’t an integer multiple of the virtual page size (see Figure 2).
Virtual address	Consisting of 16 bit block number and 16 bit offset inside the logical block.
Physical address	Address information in device specific format (depending on the underlying EEPROM driver and device) that is used to access a logical block.
Dataset	Concept of the NVRAM manager: A user addressable array of blocks of the same size.E.g. could be used to provide different configuration settings for the CAN driver (CAN IDs, filter settings, ...) to an ECU which has otherwise identical application software (e.g. door module).
Redundant copy	Concept of the NVRAM manager: Storing the same information twice to enhance reliability of data storage.

3 Related documentation 3.1 Inputdocuments

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[5] Requirements on Memory Hardware Abstraction Layer AUTOSAR_SRS_MemoryHWAbstractionLayer.doc
[6] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[7] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[8] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pd
[9] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

3.2 Relatedstandardsandnorms

[7] Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager.doc
[8] Specification of Memory Abstraction Interface AUTOSAR_SWS_MemoryAbstractionInterface.pdf
[9] Specification of Flash EEPROM Emulation AUTOSAR_SWS_FlashEEPROMEmulation.pdf

130 Specification of ECU State Manager

2 Definitions and Acronyms

This section defines terms that are of special significance to the ECU Manager and the acronyms of related modules.

Term	Description
Callback	Refer to the Glossary [7]
Callout	‘Callouts’ are function stubs that the system designer can replace with code, usually at configuration time, to add functionality to the ECU Manager module. Callouts are separated into two classes. One class provides mandatory ECU Manager module functionality and serves as a hardware abstraction layer. The other class provides optional functionality.
Integration Code	Refer to the Glossary [7]
Mode	A Mode is a certain set of states of the various state machines (not only of the ECU Manager) that are running in the vehicle and are relevant to a particular entity, an application or the whole vehicle
Passive Wakeup	A wakeup caused from an attached bus rather than an internal event like a timer or sensor activity.
Phase	A logical or temporal assembly of ECU Manager’s actions and events, e.g. STARTUP, UP, SHUTDOWN, SLEEP, ...Phases can consist of Sub-Phases which are often called Sequences if they above all exist to group sequences of executed actions into logical units. Phases in this context are not the phases of the AUTOSAR Methodology.
Shutdown Target	The ECU must be shut down before it is put to sleep, before it is powered off or before it is reset. SLEEP, OFF, and RESET are therefore valid shutdown targets. By selecting a shutdown target, an application can communicate its wishes for the ECU behavior after the next shutdown to the ECU Manager module.
State	States are internal to their respective BSW component and thus not visible to the application. So they are only used by the BSW’s internal state machine. The States inside the ECU Manager build the phases and therefore handle the modes.
Wakeup Event	A physical event which causes a wakeup. A CAN message or a toggling IO line can be wakeup events.Similarly, the internal SW representation, e.g. an interrupt, may also be called a wakeup event.
Wakeup Reason	The wakeup reason is the wakeup event that is the actual cause of the last wakeup.
Wakeup Source	The peripheral or ECU component which deals with wakeup events is called a wakeup source.

Acronym	Description
BswM	Basic Software Mode Manager
DEM	Diagnostic Event Manager
DET	Default Error Tracer
EcuM	ECU Manager
GPT	General Purpose Timer
ICU	Input Capture Unit
ISR	Interrupt Service Routine
MCU	Microcontroller Unit
NVRAM	Non-volatile random access memory
OS	Operating System
RTE	Runtime Environment
VFB	Virtual Function Bus

3 Related documentation

3.1 Inputdocuments
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[4] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[5] Requirements on Mode Management AUTOSAR_SRS_ModeManagement.pdf
[6] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf

3.2 Relatedstandardsandnorms

None

3.3 RelatedAUTOSARSoftwareSpecifications

[7] Glossary AUTOSAR_TR_Glossary.pdf
[8] Specification of Communication Manager AUTOSAR_SWS_COMManager.pdf
[9] Specification of Watchdog Manager AUTOSAR_SWS_WatchdogManager.pdf
[10] Specification of MCU Driver AUTOSAR_SWS_MCUDriver.pdf
[11]Specification of SPI Handler/Driver AUTOSAR_SWS_SPIHandlerDriver.pdf
[12] Specification of EEPROM Interface AUTOSAR_SWS_EEPROMDriver.pdf
[13] Specification of Flash Interface AUTOSAR_SWS_FlashDriver.pdf
[14] Specification of Operating System AUTOSAR_SWS_OS.pdf
[15] Specification of RTE AUTOSAR_SWS_RTE.pdf
[16] Specification of the Virtual Function Bus AUTOSAR_EXP_VFB.pdf
[17] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[18] Specification of Default Error Tracer AUTOSAR_SWS_ DefaultErrorTracer.pdf
[19] Specification of CAN Transceiver Driver AUTOSAR_SWS_CANTransceiverDriver.pdf
[20] Specification of C Implementation Rules AUTOSAR_TR_CImplementationRules.pdf
[21] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[22] Specification of BSW Mode Manager AUTOSAR_SWS_BSWModeManager.pdf
[23] Guide to Mode Management AUTOSAR_Guide_ModeManagement.pdf

129 Specification of Module E2E Transformer

2 Acronyms and abbreviations

See AUTOSAR glossary.

3 Related documentation 3.1 Inputdocuments

[1] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[4] AUTOSAR Specification of SW-C End-to-End Communication Protection Library AUTOSAR_SWS_E2ELibrary.pdf
[5] AUTOSAR Specification of RTE AUTOSAR_SWS_RTE.pdf
[6] AUTOSAR Requirements on E2E AUTOSAR_RS_E2E.pdf
[7] System Template AUTOSAR_TPS_SystemTemplate.pdf
[8] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[9] General Specification of Transformers AUTOSAR_ASWS_TransformerGeneral.pdf
[10] AUTOSAR Glossary AUTOSAR_TR_Glossary.pdf
[11] SoftwareComponent Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
3.2 Relatedstandardsandnorms
[12] ISO 26262:2011
www.iso.org

128 Specification of SW-C End-to- End Communication Protection Library

2 Acronyms and abbreviations

All technical terms used in this document, except the ones listed in the table below, can be found in the official AUTOSAR glossary [10].
Acronyms and abbreviations that have a local scope and therefore are not contained in the AUTOSAR glossary appear in the glossary below.

Abbreviation / Acronym	Description
E2E Library	Short name for the End-to-End Communication Protection Library

term	description
Data ID	An identifier that uniquely identifies the message / data element / data.
Repetition	Repetition of information (see4.3.3.1)
Loss	Loss of information (see 4.3.3.2)
Delay	Delay of information (see4.3.3.3)
Insertion	Insertion of information (see4.3.3.4)
Masquerade	Masquerade (see 4.3.3.5)
Incorrect addressing	Incorrect addressing of information (see4.3.3.6).
Incorrect sequence	Incorrect sequence of information (see4.3.3.7).
Corruption	Corruption of information (see4.3.3.8).
Asymmetric information	Asymmetric information sent from a sender to multiple receivers (see 4.3.3.9)
Subset	Information from a sender received by only a subset of the receivers (see 4.3.3.10)
Blocking	Blocking access to a communication channel (see 4.3.3.11)
XX notation	In the whole document, there are many requirements that apply to all E2E Profiles at the same time. Such requirements are defined as one requirement that applies to all profiles at the same time. In case some names are profile dependent, then XX notation is used: if in a requirement appears the string containing XX, then it is developed to two strings with 01,02, 04, 05, 06 respectively instead of XX. For example, E2E_PXXCheck() develops to the following two E2E_P01Check(),E2E_P02Check().

3 Related documentation 3.1 Inputdocuments

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of COM AUTOSAR_SWS_COM.pdf
[5] Specification of BSW Scheduler AUTOSAR_SWS_Scheduler.pdf
[6] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[7] Specification of CRC Routines AUTOSAR_SWS_CRCLibrary.pdf
[8] Specification of Platform Types AUTOSAR_SWS_PlatformTypes.pdf
[9] Requirements on Libraries AUTOSAR_SRS_Libraries.pdf
[10] AUTOSAR Glossary AUTOSAR_TR_Glossary.pdf
[11] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[12] System Template AUTOSAR_TPS_SystemTemplate.pdf
[13] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration

3.2 Relatedstandardsandnorms

[14] ISO 26262:2011 http://www.iso.org/

127 Specification of Diagnostics

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the DM module that are not included in the [3, AUTOSAR glossary].

Abbreviation / Acronym	Description
AA	AUTOSAR Adaptive Application
AP	AUTOSAR Adaptive Platform
CP	AUTOSAR Classic Platform
DEXT	AUTOSAR Diagnostic Extract[2], describing diagnostic configu- ration of an ECU
DM	AUTOSAR Adaptive Diagnostic Management
DTC	Diagnostic Trouble Code according to ISO 14229-1[1]
DID	Data Identified according to ISO 14229-1[1]. This 16 bit value uniquely defines one ore more data elements (parameters) that can are used in diagnostics to read, write or control data.
ECU	Electronic control unit
FDC	Fault Detection Counter according to 14229-1[1]
GID	Group identifier as used in DoIP
NRC	Negative Response Code used by UDS in the diagnostic re- sponse to indicate the tester that a certain failure has occurred and the diagnostic request was not processed.
SA	SourceAddress of a UDS request
SID	Service Identifier, identifying a diagnostic service according to UDS, such as 0x14 ClearDiagnosticInformation
TA	TargetAddress of a UDS request
UDS	Unified Diagnostic Services
VIN	Vehicle Identification Number according to ISO-3779
Dcm	Diagnostic Communication Manager (Module of the AUTOSAR Classic Platform)
DoIP	Diagnostics over Internet Protocol (Communication protocol of automotive electronics according to ISO-13400[4])

Terms	Description:
Execution Management	Functional cluster Execution Management
MetaInfo	Meta-Information in the form of a key-value map, which is given from DM to external service processors.
PowerMode	Vehicle basic status information retrieval of DoIP
Channel	An abstraction of a network specific communication channel. In CAN networks a Channel can be identified via CAN identifier. In Ethernet networks a Channel might be defined by the quadruple Src-IP, Src-Port, Target-IP, Target-Port.
Aging	Unlearning/deleting of a no longer failed event/DTC after a de- fined number of operation cycles from event memory.
Associated ServiceInterface	Describes the association of a ServiceInterface to a Diag- nosticServiceSwMapping by means of a referenced Swc- ServiceDependency, see section 7.2.4.2.1.
Diagnostic Client	A Diagnostic Client is a diagnostic service requester, i.e. sends a UDS request to the Diagnostic Server. Usually the Diagnostic Client is an external tester equipment but can also be another vehicle internal ECU.
Diagnostic Communication Management	Diagnostic Communication Management is the part of the Diag- nostic Management which belongs to tester communication and the processing of UDS services.
Diagnostic Conversation	Diagnostic Conversation represents a conversation between Di- agnostic Client (Tester) and Diagnostic Server.
Diagnostic Event Management	Diagnostic Event Management is the part of the Diagnostic Management which belongs to processing and storing of diag- nostic events and associated data.
Diagnostic Management	Diagnostic Management is a placeholder for the complete func- tionality of diagnostic communication and event handling.
Diagnostic Server instance	Diagnostic Server (DM) is intended to support an own Diagnostic Server instance per installed SoftwareCluster, see section 7.2 for a detailed description. Each of those Server instances has and manages its own resources and is responsible for dispatching and processing of diagnostic services.
Diagnostic Service instance	A diagnostic service instance implements a concrete use of a di- agnostic service in a given context. It refers to a DiagnosticSer- viceClass and the DiagnosticAccessPermission , see 7.2.1.3.3 for a detailed description.
DTC group	Uniquely identifies a set of DTCs. A DTC group is mapped to the range of valid DTCs. By providing a group of DTCs it is ex- pressed that a certain operation is requested on all DTCs of that group. The DTC group definition is provided by ISO 14229-1[1] and OEM/supplier-specific.
Enable Conditions	The criteria / conditions under which the test results from the monitors in the AA’s are valid and shall be processed by DM. Configuration is done per event.
Extended Data Records	Contains statistical data for a DTC. Extended data records are assigned to DTCs and maintained and stored by the DM.
Event	An event (also diagnostic event) uniquely identifies a fault path of the system. An application monitors the system and reports events to the DM.
Event memory	The DM stores information about events in the event memory. There can be multiple event memories, each keeping information independently from each other. Examples of the event memory is the UDS primary event memory or the up to 256 user-defined event memories.
GroupOfAllDTCs	Identifies a special DTC group that contains all DTCs. This DTC group is identified by the DTC value 0xFFFFFF in 14229-1[1] and contains by default all DTCs of a fault memory. It is present by default in the DM and requires no configuration.
Internal, External	Classifies if a DiagnosticDataElement is either managed in- ternally inside DM or by an external adaptive applications, see 7.2.4.1 for the precise definition.
Internally, Externally	Definition of the support type of a SID by the DM. Internally means processing is done by DM itself, Externally means an ex- ternal service processor is used.
Monitor	A monitor (also diagnostic monitor ) is a piece of software running within an application, monitoring the correct functionality of a cer- tain system part. The result of such a function check is reported to the DM in form of an diagnostic event.
Operation cycle	An operation cycle is the execution of monitor within an applica- tion, from a start point to a defined end point inside the application run.
Primary event memory	The primary event memory is used to store events and event related data. It is typically used by OEMs for after sales purposes, containing information to repair the vehicle.
Snapshot Record	Set of measurement values stored in the fault memory at a cer- tain point of time during fault detection. It is used to gain environ- mental data information for occurred faults.
SoftwareCluster	A SoftwareCluster groups all AUTOSAR artifacts which are rele- vant to deploy software on a machine. This includes the defini- tion of applications, i.e. their executables, application manifests, communication and diagnostics. In the context of diagnostics a SoftwareCluster can be addressed individually by its own set of diagnostic addresses.
SourceAddress	A Source Address is used to encode client and server identifiers. In a UDS request the source address encodes the Diagnos- tic Client whereas the source address in a UDS response encodes the Diagnostic Server.
TargetAddress	A Target Address is used to encode client and server identifiers. In a UDS request the target address encodes the Diagnostic Server whereas the target address in a UDS response encodes the Diagnostic Client.
Transport Protocol Handler	A subcomponent of DM implementing a particular Transport Pro- tocol (either DoIP or any other proprietary UDS Transport Layer).
Transport Protocol Manager	Link between UDS Transport Layer and Application Layer.
UDS service	A diagnostic service as defined in ISO 14229-1[1].
UDS DTC status bit	UDS DTC status bit as defined in ISO 14229-1[1] Annex D.2; Each single bit position represents and documents a certain sta- tus information for the connected diagnostic event or DTC. The following eight bits are defined:, Nr: Definition:, 0 testFailed, 1 testFailedThisOperationCycle, 2 pendingDTC, 3 confirmedDTC, 4 testNotCompletedSinceLastClear, 5 testFailedSinceLastClear, 6 testNotCompletedThisOperationCycle, 7 warningIndicatorRequested. All eight bits constitute the UDS DTC status byte.
UDS DTC status byte	Bit-packed DTC status information byte as defined in ISO 14229- 1[1], based on DTC level. Contains the UDS DTC status bits.
User-defined event memory	The user-defined event memory is used by the UDS service 0x19 with subfunctions 0x17, 0x18 and 0x19. It behaves as the pri- mary event memory but contains data independent from the pri- mary fault memory. It is used to store information that are rele- vant for different purposes such as warranty or development.
Non-volatile Memory	In the context of DM, Non-volatile Memory refers to the persistent information over the shutdown of the DM process. This does not depend on HW details.

3 Related documentation

3 .1 Input documents & related standards and norms

[1] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Re- lease 2013-03)
http://www.iso.org
[2] Diagnostic Extract Template AUTOSAR_TPS_DiagnosticExtractTemplate
[3] Glossary AUTOSAR_TR_Glossary
[4] Road vehicles – Diagnostic communication over Internet Protocol (DoIP) http://www.iso.org
[5] General Specification of Adaptive Platform AUTOSAR_SWS_General
[6] Specification of Execution Management AUTOSAR_SWS_ExecutionManagement
[7] Specification of Log and Trace AUTOSAR_SWS_LogAndTrace
[8] Specification of Persistency AUTOSAR_SWS_Persistency
[9] Requirements on Diagnostics AUTOSAR_RS_Diagnostics
[10] Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2: Network layer services
[11] Road vehicles – Diagnostic communication over Internet Protocol (DoIP) – Part 2: Network and transport layer requirements and services
http://www.iso.org
[12] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[13] Unified diagnostic services (UDS) - Part 2: Session layer services (Release 2013- 03)
http://www.iso.org
[14] Specification of Core Types for Adaptive Platform AUTOSAR_SWS_CoreTypes

126 Specification of Diagnostic over IP

2 Acronyms and abbreviations

Abbreviation / Acronym	Description
ARP	Address Resolution Protocol
DHCP	Diagnostic Host Configuration Protocol
EID	Entity identifier
GID	Group identifier
ICMP	Internet Control Message Protocol
IP	Internet Protocol
IPv4	Internet Protocol version 4
IPv6	Internet Protocol version 6
TCP	Transmission Control Protocol
TCP/IP	A family of communication protocols used in computer networks
VIN	Vehicle Identification Number
UDP	User Datagram Protocol

3 Related documentation 3.1 Inputdocuments

[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[4] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] Specification of RTE AUTOSAR_SWS_RTE.pdf
[7] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[8] Specification of BSW Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[9] Requirements on Ethernet Support in AUTOSAR AUTOSAR_SRS_Ethernet.pdf
[10] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[11] Specification of Socket Adaptor AUTOSAR_SWS_SocketAdaptor.pdf
[12] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[13] Specification of TCP/IP Stack AUTOSAR_SWS_TCPIP.pdf
[14] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

3.2 Relatedstandardsandnorms

[15] ISO 13400-2, Road vehicles – Diagnostic communication over Internet Protocol (DoIP) – Part 2: Transport protocol and network layer services

125 Specification of Diagnostic Log and Trace

2 Acronyms and abbreviations

Abbreviation / Acronym	Description
APID	Application ID
CTID	Context ID
Dlt	Diagnostic Log and Trace
MCNT	Message Counter
MSBF	Most Significant Byte First
MSBI	Message Bus Info
MSCI	Message Control Info
MSLI	Message Log Info
MSTP	Message Type
MSTI	Message Trace Info
NOAR	Number of Arguments
STMS	Timestamp
UEH	Use Extended Header
VERB	Verbose
VERS	Version Number
WEID	With ECU ID
WSID	With Session ID
WTMS	With Timestamp

2.1 Term and definition

Term	Description
Log and trace message	A log and trace message contains all data and options to describe a log and trace event in a software. A log and trace message consists of a header and payload.
Dlt User	A Dlt User represents the source of a generated Dlt message. The possible users are SW-Cs, RTE (for VFB traces), DEM, or DET.
Log Message	A Log Message contains debug information like state changes or value changes.
Trace Message	A Trace messages contains information, which has passed via the VFB.
ECU ID	ECU ID is the name of an ECU, composed by four 8-bit ASCII characters (e.g., ABS0 or COMB).
Session	A session is a logical entity of source of log or trace messages. If an application / SW-C is instantiated several times, each instance gets a globally unique session ID with respect to the application / context ID. It is possible for an application / SWC to have several simultaneous log or trace sessions, if it has several ports opened to Dlt. Since Session ID is not specified in AUTOSAR for SW-Cs, the port defined argument values shall be used for this number.
Session ID	Session ID is the identification number of a log or trace session.
Application ID	Application ID is an abbreviation of an application / SW-C. It identifies the application / SW-C a log and trace message originates from. The Application ID is composed by four 8-bit ASCII characters.
Context ID	Context ID is a user defined identifier to group Log and Trace Messages generated by an application / SW-C. The following rules apply: Each ApplicationID can own several Context IDs. Context IDs are grouped by Application IDs. Context IDs shall be unique within an Application ID. The source of a log and trace message is identified using the tuple “ApplicationID” and “ContextId”. Four 8-bit ASCII characters compose the ContextId.
Message ID	Messaged ID is the identifier to characterize the information, which is transported by the message itself. A Message ID identifies a kind of log or trace message uniquely. It can be used for identifying the source (in source code) of a message and it can be used for characterizing the payload of a message. A Message ID is statically fixed at development or configuration time.
Log level	A log level defines a classification for the severity grade of a Log Message.
Trace status	The trace status provides information, if a trace message should be send.
Log Channel	A physical communication bus, which is used to transmit Dlt messages.
External client	The external client is a tool to control, monitor, and store log / trace messages provided by ECUs using the Dlt module.

3 Related documentation 3.1 Inputdocuments

[1] DLT Protocol Specification PRS_DLTProtocol.pdf
[2] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] AUTOSAR Specification of RTE AUTOSAR_SWS_RTE.pdf
[5] AUTOSAR Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[6] AUTOSAR Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager.pdf
[7] AUTOSAR Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[8] AUTOSAR Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf [9] AUTOSAR Specification of GPT Driver AUTOSAR_SWS_GPTDriver.pdf

3.2 Relatedstandardsandnorms

IEC 7498-1 The Basic Model, IEC Norm, 1994

124 Specification of Diagnostic Event Manager

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the Dem module that are not included in the [4, AUTOSAR glossary].

2.1 Acronyms

Acronym	Description
Activation Mode 1	Absence of malfunction - The MIL shall blink for one flash.
Activation Mode 2	"on-demand-MI" - The MIL shall show blink for two flashes if the OBD system would command an on-demand-MI according to the discriminatory display strategy.
Activation Mode 3	"short-MI" - The MIL shall blink for three flashes if the OBD sys- tem would command a short-MI according to the discriminatory display strategy.
Activation Mode 4	"continuous-MI" - The MIL shall remain continuously ON ("continuous-MI") if the OBD system would command a continuous-MI according to the discriminatory display strategy.
Aging	Unlearning/deleting of a no longer failed event/DTC after a de- fined number of operation cycles from event memory.
Aging Counter	The "Aging Counter" or "Aging Cycle Counter" or "DTC Aging Counter" specifies the counter which is used to perform Aging. It counts the number of operation cycles until an event/DTC is removed from event memory.
Class B1 counter	Number of engine hours during which a Class B1 malfunction has been Confirmed and TestFailed.
Combined DTC	Normal DTC, but referenced by multiple events reported by sev- eral monitors (e.g. ECU Defect, consisting of different HW de- fects).
Continuous-MI counter	Hours run by the engine while a continuous MI is commanded.
Cumulative Continuous-MI counter	Number of engine hours during which MI has been continuously commanded to be on during its lifetime.
Debounce counter	Internal counter for counter-based debouncing algorithm(s).
DemComponent / Monitored Component	A monitored component is a part of the system, which is checked for proper operation by one or several monitorings. (see chapter 7.5)
Dem-internal data value	Some data values (e.g. the occurrence counter) are calculated by the Dem module itself internally.
Denominator	The denominator of a specific monitor m (Denominatorm) is a counter indicating the number of vehicle driving events, taking into account conditions specific to that specific monitor.
Dependent / Secondary ECUs	Dependent / Secondary (or dep. / sec. ) ECUs are always related to a Master or a Primary ECU.
Directed acyclic graph	Dependency graph without circular dependencies.
Displacement	Replacing the the most insignificant event memory entry by a more significant event memory entry which needs to be stored.
DTC group	Uniquely identifies an set of DTCs. A DTC group is mapped into the range of valid DTCs. By providing a group of DTCs it is ex- pressed that a certain operation is requested on all DTCs of that group. The DTC group definition is provided by ISO 14229-1[2] and OEM/supplier specific.
DtcGroupAllDtcs	Grouping of all configured DTCS (representation is 0xFFFFFF).
Event combination	Event combination is a method to merge several events to one specific combined DTC. It is used to adapt different monitor re- sults to one significant fault, which is clearly evaluable in a service station.
Event debouncing	Debouncing is a specific mechanism (e.g. counter-based) to evaluate, if the diagnostic event gets qualified. This works on top of potential signal debouncing and can be done within the SW-C or inside the Dem.
Event confirmation	A diagnostic event is confirmed in case of repeated detection of qualified events over cycles or time evaluated by means of fault confirmation counters. Therefore, also the UDS status bit 3 (Con- firmedDTC) is set.
Event memory	An event memory (e.g. Primary memory) consists of several event memory entries.
Event memory entry	The event memory entry is a single storage container for an event and its event related data. The event memory entry is dynami- cally assigned to specific events.
Event memory overflow indica- tion	The event memory overflow indication indicates, if this specific event memory is full and the next event occurs to be stored in this event memory.
Event qualification	A diagnostic event is qualified in case of a passed or a failed result is set (Dem-internal or reported from another BSW module or SW-C).
Event related data	Event related data is additional data, e.g. sensor values or time stamp/mileage, which is stored with an event in an event mem- ory. ISO defines two types of event related data: freeze frames (snapshot records) and extended data.
Event status byte	Status byte as defined in ISO 14229-1 [1], based on event level.
Extended data record	An extended data record is a record to store specific information assigned to a fault.
Failure counter	The Failure counter represents the Trip Counter according to ISO14229-1 [2]. The Trip Counter counts the number of oper- ation cycles (driving cycles) where a malfunction occurred. If the counter reaches the threshold (e.g., 2 driving cycles) the con- firmed bit changes from 0 to 1.
Fault Detection Counter	sint8 value as used in ISO and FDC-APIs.
Freeze frame	Freeze frame is defined as a record of data (DIDs/PIDs). Freeze frames are the same as SnapShotRecords in ISO-14229-1[2].
General Denominator	The general denominator is a counter indicating the number of times a vehicle has been operated, taking into account general conditions.
Healing	Switching off the warning indicator including the handling of re- ported passed results over a period of time / several operation cycles
In-Use performance ratio	The in-use performance ratio (IUPR) of a specific monitor m of the OBD system is: IUPRm = Numeratorm / Denominatorm
Master ECU	As a primary ECU a Master ECU stores “it’s own” and “reported errors” of related dep. / sec ECUs in it’s event memory. Beside this a Master has to fulfill special Master tasks as MIL Master or provision of “general nominator” information.
Monitor	A diagnostic monitor is a routine entity determining the proper functionality of a component. Alternatively the term “diagnostic function” can be used.
Numerator	The numerator of a specific monitor m (Numeratorm) is a counter indicating the number of times a vehicle has been operated such that all monitoring conditions necessary for that specific monitor to detect a malfunction have been encountered.
NvM is marked for NvM_WriteAll	The Dem has called NvM_SetRamBlockStatus() to set the ac- cording NvM Block to be written by NvM_WriteAll()
Operating cycle	An ‘operation cycle’ is the base of the event qualifying and also Dem scheduling (e.g. ignition key off-on cycles, driving cycles, etc.)
OBD	On-Board Diagnostics, or OBD is a generic term referring to a vehicle’s self-diagnostic and reporting capability. OBD systems give the vehicle owner or a repair technician access to state of health information for various vehicle sub-systems.
OBD ECUs	"In a vehicle there can be 3 different types of OBD ECUs:• Master ECU (one per vehicle) • Primary ECUprimary ECUs (several per vehicle) • Dependent / Secondary ECUs (several per vehicle)
Positive Callback from NvM	The Dem module shall use the APIs NvM_WriteBlock and NvM_GetErrorStatus of the NVRAMManager [5], if there is the necessity to store data between Dem_Init and Dem_Shutdown. Furthermore the API NvM_GetErrorStatus shall wait for positive response if writing of block completed successfully.
PossibleErrors	PossibleErrors means the ApplicationErrors as defined in meta model
Primary ECU	A primary ECU stores “it’s own” and "reported errors" of related dep. / sec ECUs in it’s event memory
Readiness	The readiness refers to the tested bits TestNotCompletedSince- LastClear (bit 4) and TestNotCompleteThisOperationCycle (bit 6) of the UDS status byte.
Triggered to NvM	The Dem module shall use the API NvM_WriteBlock of the NVRAMManager [5], if there is the necessity to trigger the stor- age of data between Dem_Init and Dem_Shutdown. Fur- thermore the Dem module shall wait for positive response of NvM_WriteBlock if request has been accepted.
UDS status bit 0	testFailed bit of the UDS status byte. Indicates the result of the most recently performed test.
UDS status bit 1	testFailedThisOperationCycle bit of the UDS status byte. Indi- cates whether or not a diagnostic test has reported a testFailed result at any time during the current operation cycle.
UDS status bit 2	pendingDTC bit of the UDS status byte. Indicates whether or not a diagnostic test has reported a testFailed result at any time during the current or last completed operation cycle.
UDS status bit 3	confirmedDTC bit of the UDS status byte. Indicates whether a malfunction was detected enough times to warrant that the DTC is desired to be stored in long-term memory.
UDS status bit 4	testNotCompletedSinceLastClear bit of the UDS status byte. In- dicates whether a DTC test has ever run and completed since the last time a call was made to ClearDiagnosticInformation.
UDS status bit 5	testFailedSinceLastClear bit of the UDS status byte. Indicates whether a DTC test has completed with a failed result since the last time a call was made to ClearDiagnosticInformation.
UDS status bit 6	testNotCompletedThisOperationCycle bit of the UDS status byte. Indicates whether a DTC test has ever run and completed during the current operation cycle.
UDS status bit 7	warningIndicatorRequested bit of the UDS status byte. Report the status of any warning indicators associated with a particular DTC.
UDS status byte	Status byte as defined in ISO 14229-1 [1], based on DTC level.

2.2 Abbreviations

Abbreviation	Description
API	Application Programming Interface
BSW	Basic Software
CDD	Complex Device Driver
CRC	Cyclic Redundancy Check
Dcm	Diagnostic Communication Manager
Dem	Diagnostic Event Manager
Det	Default Error Tracer
DID	Data Identifier
DTC	Diagnostic Trouble Code
DTR	Diagnostic Test Result
DYC	OBD Term: Driving Cycle (OBD Term)
ECU	Electronic Control Unit
EcuM	Electronic Control Unit Manager
FDC	Fault Detection Counter
Fim	Function Inhibition Manager
FMI	Failure Mode Indicator (SAE J1939)
FTB	Failure Type Byte
HW	Hardware
ID	Identification/Identifier
ISO	International Standardization Organization
IUMPR	In Use Monitoring Performance Ratio (OBD Term)
J1939Dcm	SAEJ1939 Diagnostic Communication Manager
MIL	Malfunction Indicator Light (SAE J1979) or Lamp (SAE J1939)
NVRAM	Non volatile RAM
OBD	On-Board-Diagnostics
OC	Occurrence Count (SAE J1939)
OEM	Original Equipment Manufacturer (Automotive Manufacturer)
OS	Operating System
P-Code	Power train code
PFC cycle	Permanent fault code - driving cycle (OBD Term)
RBM cycle	OBD Term: General Nominator / Rate-based monitoring - driving cycle (OBD Term)
PID	Parameter Identification (SAE J1587 or SAE J1979)
PTO	Power Take Off
RAM	Random Access Memory
ROM	Read-only Memory
RTE	Runtime Environment
SPN	Suspect Parameter Number (SAE J1939)
SSCP	synchronous server call point
SW	Software
SW-C	Software Component
UDS	Unified Diagnostic Services
VOBD	Vehicle On-Board-Diagnostic
WUC	OBD Term: Warm up cycle (OBD Term)
WIR	Warning Indicator Request
WWH-OBD	World Wide Harmonized On-Board-Diagnostic

3 Related documentation

3.1 Input documents & related standards and norms
References
[1] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Re- lease 2006-12)
http://www.iso.org
[2] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Re- lease 2013-03)
http://www.iso.org
[3] Road vehicles – Implementation of World-Wide Harmonized On-Board Diagnos- tics (WWH-OBD) communication requirements – Part 1: General information and use case definition
http://www.iso.org
[4] Glossary AUTOSAR_TR_Glossary
[5] Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager
[6] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[7] Specification of a Diagnostic Communication Manager for SAE J1939 AUTOSAR_SWS_SAEJ1939DiagnosticCommunicationManager
[8] Requirements on Function Inhibition Manager AUTOSAR_SRS_FunctionInhibitionManager
[9] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager
[10] Requirements on Diagnostics AUTOSAR_RS_Diagnostics
[11] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[12] Road vehicles – Communication between vehicle and external equipment for emission-related diagnostic – Part 5: Emission-related diagnostic services. http://www.iso.org
[13] SAE J2012-DA Digital
[14] SAE J1939-73 Application Layer – Diagnostics
[15] Road vehicles – Interchange of digital information on electrical connections be- tween towing and towed vehicles – Part 4: Diagnostic communication http://www.iso.org
[16] ISO 17356-3: Road vehicles – Open interface for embedded automotive applica- tions – Part 3: OSEK/VDX Operating System (OS)
[17] SAE J1979
[18] SAE J1979-DA Digital Annex of E/E Diagnostic Test Modes
[19] Title 13, California Code Regulations, Section 1971.1, On-Board Diagnostic Sys- tem Requirements for 2013 and Subsequent Model-Year Heavy-Duty Engines (HD OBD)
[20] Title 13, California Code Regulations, Section 1968.2, Malfunction and Diagnos- tic System Requirements for 2004 and Subsequent Model-Year Passenger Cars, Light-Duty Trucks, and Medium-Duty Vehicles and Engines (OBD II) (Biennial Re- view MY08-11)
http://www.arb.ca.gov/regact/obdii06/19682clean.pdf
[21] Road vehicles – Implementation of World-Wide Harmonized On-Board Diagnos- tics (WWH-OBD) communication requirements – Part 3: Common message dic- tionary
http://www.iso.org
[22] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[23] Diagnostic Extract Template AUTOSAR_TPS_DiagnosticExtractTemplate

123 Specification of Diagnostic Communication Manager

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the module that are not included in the [6, AUTOSAR glossary].

Abbreviation / Acronym	Description
Application Layer	The Application Layer is placed above the RTE. Within the Appli- cation Layer the AUTOSAR Software-Components are placed.
Atomic Sender/Receiver inter- face	An atomic sender-receiver interface can be used to group DID data elements into one record data element prototype. All data elements can be read or write having a single read or write oper- ation.
Channel	A link at which a data transfer can take place. If there is more than one Channel, there is normally some kind of ID assigned to the Channel.
Diagnostic Channel	A link at which a data transfer between a diagnostic tool and an ECU can take place. Example: An ECU is connected via CAN and the diagnostic channel has an assigned CAN-ID. Diag- nostic channels connected to other bus-systems such as MOST, FlexRay, LIN, etc. are also possible.
External Diagnostic Tool	A device which is NOT permanently connected to the vehicle communication network. This External Diagnostic Tool can be connected to the vehicle for various purposes, as e.g. for: • development • manufacturing • service (in a garage) Example External Diagnostic Tools are: • a diagnostic tester • an OBD scan tool. The External Diagnostic Tool is to be connected by a mechanic to gather information from ”inside” the car.
Freeze Frame	A set of the vehicle/system operation conditions at a specific time.
Functional Addressing	The diagnostic communication model where a group or all nodes of a specific communication network receive a message from one sending node (1-n communication). This model is also referred to as ’broadcast’ or ’multicast’. OBD communication will always be done in the Functional Addressing mode.
Internal Diagnostic Tool	A device/ECU which is connected to the vehicle communication network. The Internal Diagnostic Tool can be used for: • advanced event tracking • advanced analysis • for service. The behavior of the Internal Diagnostic Tool can be the same as of an External Diagnostic Tool. The notion of ”Internal Diagnos- tic Tool” does not imply that it is included in each ECU as an AUTOSAR Software-Component.
Physical Addressing	The diagnostic communication model where a node of a specific communication network receives a message from one sending node (1-1 communication). This model is also referred to as ’uni- cast’.
UDS Service	this refers to a UDS Service as defined in ISO14229-1 [1].
OBD Service	This refers to an OBD Service as defined in ISO15031-5 [2].
AddressAndLengthFormat Identifier	Defines the number of bytes used for the memoryAddress and memorySize parameter in the request messages.
OBD Scan tool	See definition External Diagnostic Tool.
periodic transmission rate	Time interval value that defines the time between two calls of a periodic data identifier transmission. The value is configuration specific and there are separate values for fast, medium and slow periodic data transmission. The configured value is always an integer multiple of the Dcm main task time.

Terms	Description
API	Application Programming Interface
CAN	Controller Area Network
CEMR	ControlEnableMaskRecord
Dcm	Diagnostic Communication Manager
Dem	Diagnostic Event Manager
Det	Default Error Tracer
DID	Data Identifier
DSD	Diagnostic Service Dispatcher (submodule of the Dcm module)
DSL	Diagnostic Session Layer (submodule of the Dcm module)
DSP	Diagnostic Service Processing (submodule of the Dcm module)
DTC	Diagnostic Trouble Codes
ID	Identifier
LIN	Local Interconnect Network
MCU	Micro-Controller Unit
MOST0	Media Orientated System Transport
NRC	Negative Response Code
OBD	On-Board Diagnosis
OSI	Open Systems Interconnection
PDID	Periodic Data Identifier, periodically send by the Dcm after a re- quest of ReadDataByPeriodicIndentifer
PDU	Protocol Data Unit
PID	Parameter Identifier
RCRRP	Response correctly received - response pending
RID	Routine Identifier
ROE	ResponseOnEvent
RTE	Runtime Environment
SAP	Service Access Point
SDU	Service Data Unit
SID	Service Identifier
SW-C	Software-Component
TP	Transport Protocol
UDS	Unified Diagnostic Services
Xxx_	Placeholder for an API provider
SPRMIB	suppressPosRspMsgIndicationBit

2.1 Typographical Conventions

This document uses the following typographical conventions:
• see configuration parameter myConfigurationParameter: this is a reference to a configuration parameter which can be found in Chapter 10.
• myFunction(): this is a function provided or required by the module as defined in Chapter 8

3 Related documentation

3.1 Input documents & related standards and norms

[1] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Re- lease 2013-03)
http://www.iso.org
[2] Road vehicles – Communication between vehicle and external equipment for emission-related diagnostic – Part 5: Emission-related diagnostic services. http://www.iso.org
[3] SAE J1979
[4] Diagnostics on controller area network (CAN) – Part 3: Implementation of unified diagnostic services (UDS on CAN) (Release 2004 10-06)
[5] Diagnostics on controller area network (CAN) – Part 4: Requirements for emission-related systems (Release 2005 01-04)
[6] Glossary AUTOSAR_TR_Glossary
[7] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[8] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[9] ISO 17356-3: Road vehicles – Open interface for embedded automotive applica- tions – Part 3: OSEK/VDX Operating System (OS)
[10] Specification of PDU Router AUTOSAR_SWS_PDURouter
[11] Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2: Network layer services
[12] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager
[13] Road vehicles – Communication between vehicle and external equipment for emission-related diagnostic – Part 6: Diagnostic trouble code definitions http://www.iso.org
[14] Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager
[15] Specification of Crypto Service Manager AUTOSAR_SWS_CryptoServiceManager
[16] Specification of Key Manager AUTOSAR_SWS_KeyManager
[17] Specification of I/O Hardware Abstraction AUTOSAR_SWS_IOHardwareAbstraction

122 Specification of Default Error Tracer

2 Acronyms and abbreviations

acronym	description
DET	Default Error Tracer

3 Related documentation 3.1 Inputdocuments

[1] List of Basic Software Modules, AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[4] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[5] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[6] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[7] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

121 Specification of DIO Driver

2 Acronyms and abbreviations

Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

Term	Description
DIO channel:	Represents a single general-purpose digital input/output pin
DIO port:	Represents several DIO channels that are grouped by hardware (typically controlled by one hardware register). Example: Port A (8 bit) of Freescale HC08
DIO channel group:	Represents several adjoining DIO channels represented by a logical group. A DIO channel group shall belong to one DIO port. Example: Port pins 2..6 of an 8 bit port addressing a multiplexer
Physical Level (Input):	Two states possible: LOW/HIGH. A bit value '0' represents a LOW, a bit value '1' represents a HIGH.
Physical Level (Output):	Two states possible: LOW/HIGH. A bit value '0' represents a LOW, a bit value '1' represents a HIGH.

Abbreviation / Acronym	Description
LSB	Least Significant Bit
MSB	Most Significant Bit
DIO	Digital Input Output
ID	Identifier
ADC	Analog to Digital Converter
SPI	Serial Peripheral Interface
PWM	Pulse Width Modulation
ICU	Input Capture Unit
DET	Default Error Tracer
DEM	Diagnostic Event Manager

3 Related documentation 3.1 DeliverablesofAUTOSAR

[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[3] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[4] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[5] Specification of PORT Driver, AUTOSAR_SWS_PortDriver.pdf
[6] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[6] AUTOSAR Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[7] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

120 Specification of Cryptography for Adaptive Platform

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the Crypto Stack module that are not included in the AUTOSAR glossary [1, AUTOSAR glossary].

Abbreviation / Acronym	Description
COUID	Cryptographic Object Unique Identifier
CRL	Certificate Revocation Lists
CSR	Certificate Signing Request
DER	Distinguished Encoding Rules
DH	Diffie-Hellman (key exchange method)
ECC	Elliptic Curve Cryptography
HSM	Hardware Security Module
IPC	Inter-Process Communication
IV	Initialization Vector
MAC	Message Authentication Code
OCSP	On-line Certificate Status Protocol
PEM	Privacy-Enhanced Mail
PKI	Public Key Infrastructure
TPM	Trusted Platform Module
UID	Unique Identifier

3 Related documentation

3.1 Input documents & related standards and norms
[1] Glossary AUTOSAR_TR_Glossary
[2] Requirements on Security Management for Adaptive Platform AUTOSAR_RS_SecurityManagement

119 Specification of Crypto Service Manager

2 Acronyms and Abbreviations

Acronyms and abbreviations, which have a local scope and therefore are not contained in the AUTOSAR glossary [13], are listed in this chapter.

Abbreviation / Acronym	Description
AEAD	Authenticated Encryption with Associated Data
CDD	Complex Device Driver
CSM	Crypto Service Manager
CRYIF	Crypto Interface
CRYPTO	Crypto Driver
DET	Default Error Tracer
HSM	Hardware Security Module
HW	Hardware
SHE	Security Hardware Extension
SW	Software

2.1 Glossary of Terms

Terms	Description
Crypto Driver Object	A Crypto Driver implements one or more Crypto Driver Objects. The Crypto Driver Object can offer different crypto primitives in hardware or software. The Crypto Driver Objects of one Crypto Driver are independent of each other. There is only one workspace for each Crypto Driver Object (i.e. only one crypto primitive can be performed at the same time)
Key	A Key can be referenced by a job in the Csm. In the Crypto Driver, the key refers a specific key type.
Key Type	A key type consists of refers to key elements. The key types are typically pre-configured by the vendor of the Crypto Driver.
Key Element	Key elements are used to store data. This data can be e.g. key material or the IV needed for AES encryption. It can also be used to configure the behaviour oft he key management functions.
Job	A Job is a configured 'CsmJob'. Among others, it refers to a key, a cryptographic primitive and a reference channel.
Channel	A channel is the path from a Crypto Service Manager queue via the Crypto Interface to a specific Crypto Driver Object.
Primitive	A primitive is an instance of a configured cryptographic algorithm realized in a Crypto Driver Object. Among others it refers to a functionality provided by the CSM to the application, the concrete underlining 'algorithmfamily' (e.g. AES, MD5, RSA, etc.), and a 'algorithmmode' (e.g. ECB, CBC, etc).
Operation	An operation of a crypto primitive declares what part of the crypto primitive shall be performed. There are three different operations:
START	Operation indicates a new request of a crypto primitive, it shall cancel all previous requests perform necessary initializations and checks if the crypto primitive can be processed.
UPDATE	Operation indicates, that the crypto primitive expect input data. An update operation may provide intermediate results.
FINISH	Operation indicates, that after this part all data are fed completely and the crypto primitive can finalize the calculations. A finish operation may provide final results. It is also possible to perform more than one operation at once by concatenating the corresponding bits of the operation_mode argument.
Priority	The priority of a job defines the importance of it. The higher the priority (as well in value), the more immediate the job will be executed. The priority of a cryptographic job is part of the configuration.
Processing	Indicates the kind of job processing.
Asynchro nous	The job is not processed immediately when calling a corresponding function. Usually, the caller is informed via a callback function when the job has been finished.
Synchron ous	The job is processed immediately when calling a corresponding function. When the function returns, a result will be available.
Service	A service shall be understand as defined in the TR_Glossary document: A service is a type of operation that has a published specification of interface and behavior, involving a contract between the provider of the capability and the potential clients.

3 Related documentation 3.1 InputDocuments

[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of RTE Software AUTOSAR_SWS_RTE.pdf
[5] Specification of BSW Scheduler AUTOSAR_SWS_Scheduler.pdf
[6] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[7] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[8] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.doc.pdf
[9] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[10] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[11] Specification of C Implementation Rules AUTOSAR_TR_CImplementationRules.pdf
[12] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[13] AUTOSAR Glossary AUTOSAR_TR_Glossary.pdf
[14] Requirements on the Crypto Stack AUTOSAR_SRS_CryptoStack.pdf
[15] Specification of the Crypto Interface AUTOSAR_SWS_CryptoInterface.pdf
[16] Specification of the Crypto Driver AUTOSAR_SWS_CryptoDriver.pdf
[17] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

3.2 Relatedstandardsandnorms

[18] IEC 7498-1 The Basic Model, IEC Norm, 1994
[19] IETF RFC5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, 2010
[20] IETF RFC6637 Elliptic Curve Cryptography (ECC) in OpenPGP, 2012

118 Specification of Crypto Interface

2 Acronyms and abbreviations

The glossary below includes acronyms and abbreviations relevant to the Crypto Interface module that are not included in the AUTOSAR glossary [7].

Abbreviation / Acronym	Description
CDD	Complex Device Driver
CSM	Crypto Service Manager
CRYIF	Crypto Interface
CRYPTO	Crypto Driver
DET	Default Error Tracer
HSM	Hardware Security Module
HW	Hardware
SHE	Security Hardware Extension
SW	Software

2.1 Glossary of Terms

Terms	Description
Crypto Driver Object	A Crypto Driver Object is an instance of a crypto module (hardware or software), which is able to perform one or more different crypto operations.
Key	A Key can be referenced by a job in the Csm. In the Crypto Driver, the key references a specific key type.
Key Type	A key type consists of references to key elements. The key types are typically pre-configured by the vendor of the Crypto Driver.
Key Element	Key elements are used to store data. This data can be e.g. key material or the IV needed for AES encryption. It can also be used to configure the behavior of the key management functions.
Channel	A channel is the path from a Crypto Service Manager queue via the Crypto Interface to a specific Crypto Driver Object.
Job	A 'Job' is a configured 'CsmJob'. Among others, it refers to a key, a cryptographic primitive and a reference channel.
Crypto Primitive	A crypto primitive is an instance of a configured cryptographic algorithm.
Operation	An operation of a crypto primitive declares what part of the crypto primitive shall be performed. There are three different operations:
START	Operation indicates a new request of a crypto primitive, and it shall cancel all previous requests.
UPDATE	Operation indicates, that the crypto primitive expect input data.
FINISH	Operation indicates, that after this part all data are fed completely and the crypto primitive can finalize the calculations. It is also possible to perform more than one operation at once by concatenating the corresponding bits of the operation mode argument.
Primitive	A 'Primitive' is an instance of a configured cryptographic algorithm realized in a Crypto Driver Object. Among others it refers to a functionality provided by the CSM to the application, the concrete underlining 'algorithm family' (e.g. AES, MD5, RSA, ...), and a 'algorithmmode' (e.g. ECB, CBC, ...).
Priority	The priority of a job defines the importance of it. The higher the priority (as well in value), the more immediate the job will be executed. The priority of a cryptographic job is part of the configuration.
Processing	Indicates the kind of job processing.
Asynchro nous	The job is not processed immediately when calling a corresponding function. Usually, the caller is informed via a callback function when the job has been finished.
Synchron ous	The job is processed immediately when calling a corresponding function. When the function returns, a result will be available.
Service	A 'Service' shall be understood as defined in the TR_Glossary document: A service is a type of operation that has a published specification of interface and behavior, involving a contract between the provider of the capability and the potential clients.

3 Related documentation 3.1 Inputdocuments

[1] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[4] AUTOSAR Specification of Crypto Driver AUTOSAR_SWS_CryptoDriver.pdf
[5] AUTOSAR Specification of Crypto Service Manager AUTOSAR_SWS_CryptoServiceManager.pdf
[6] AUTOSAR Requirements on Crypto Modules AUTOSAR_SRS_CryptoStack.pdf
[7] Glossary AUTOSAR_TR_Glossary
3.2 Relatedstandardsandnorms
[8] IEC 7498-1 The Basic Model, IEC Norm, 1994

117 Specification of Crypto Driver

2 Acronyms and abbreviations

Abbreviation /Acronym	Description
CDD	Complex Device Driver
CSM	Crypto Service Manager
CRYIF	Crypto Interface
CRYPTO	Crypto Driver
DET	Default Error Tracer
HSM	Hardware Security Module
HW	Hardware
SHE	Security Hardware Extension
SW	Software

2.1 Glossary of Terms

Terms	Description
Crypto Driver Object	A Crypto Driver implements one or more Crypto Driver Objects.The Crypto Driver Object can offer different crypto primitives in hardware or software. The Crypto Driver Objects of one Crypto Driver are independent of each other. There is only one workspace for each Crypto Driver Object (i.e. only one crypto primitive can be performed at the same time)
Key	A Key can be referenced by a job in the Csm. In the Crypto Driver, the key references a specific key type.
Key Type	A key type consists of references to key elements. The key types are typically pre-configured by the vendor of the Crypto Driver.
Key Element	Key elements are used to store data. This data can be e.g. key material or the IV needed for AES encryption. It can also be used to configure the behaviour of the key management functions.
Channel	A channel is the path from a Crypto Service Manager queue via the Crypto Interface to a specific Crypto Driver Object.
Job	A 'Job' is a configured 'CsmJob'. Among others, it refers to a key, a cryptographic primitive and a reference channel.
Crypto Primitive	'Primitive' is an instance of a configured cryptographic algorithm realized in a Crypto Driver Object. Among others it refers to a functionality provided by the CSM to the application, the concrete underlining 'algorithmfamily' (e.g. AES, MD5, RSA, ...), and a 'algorithmmode' (e.g. ECB, CBC, ...).
Operation	An operation of a crypto primitive declares what part of the crypto primitive shall be performed. There are three different operation modes: It is also possible to perform more than one operation at once by concatenating the corresponding bits of the operation mode argument.
START	Operation mode indicates a new request of a crypto primitive, and it shall cancel all previous requests of the same job and primitive.
UPDATE	Operation mode indicates, that the crypto primitive expects input data.
FINISH	Operation mode indicates, that after this part all data are fed completely and the crypto primitive can finalize the calculations.
Priority	The priority of a job defines the importance of it. The higher the priority (as well in value), the more immediate the job will be executed. The priority of a cryptographic job is part of the configuration.
Service	A 'Service' shall be understood as defined in the TR_Glossary
document	A service is a type of operation that has a published specification of interface and behavior, involving a contract between the provider of the capability and the potential clients.

3 Related documentation

3.1 Input documents

[1] AUTOSAR Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[3] AUTOSAR General Specification for Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf
[4] AUTOSAR Specification of Crypto Interface
AUTOSAR_SWS_CryptoInterface.pdf
[5] AUTOSAR Specification of Crypto Service Manager
AUTOSAR_SWS_CryptoServiceManager.pdf
[6] AUTOSAR Requirements on Crypto Modules
AUTOSAR_SRS_CryptoStack.pdf
[7] Glossary
AUTOSAR_TR_Glossary

3.2 Related standards and norms

[8] IEC 7498-1 The Basic Model, IEC Norm, 1994

116 Specification of Core Test

2 Acronyms and Abbreviations

Abbreviation /Acronym	Description
MCAL	Microcomputer Abstraction Layer
DEM	Diagnostic Event Manager
DET	Default Error Tracer
CPU	Central Processing Unit
MPU	Memory Protection Unit
L1	1st level memory
L2	2nd level memory
MCU	Microcontroller Unit
BIST	Built in Self Test
IRQ	Interrupt Request
CSUM Checksum

Term	Description
CSUM/Checksum/signature	A numerical representation of the result of a test execution.
Core	A CPU plus closely located functional resources
Background test	Background test is called periodically by a SW-scheduler/RTOS.
Foreground test	A foreground test is a synchronous test and shall not be interrupted. It is called via user application calls. ‘Golden (Ref.)
Value’	Reference value used for comparison (e.g. Checksum/Signature) to a previously computed test result value.
‘Good Case’	The execution finished without reporting an error
Atomic sequence/atomic piece	An atomic sequence is a piece of test which shall not be interrupted.
External device	A physical external entity; e.g. a second microcontroller
Resource	A ‘hardware resource’ is the smallest unit (instance) that can be selected by a CORETest driver user. It can be tested in one or several atomic sequences. It is a core internal unit which executes a unique functionality (e.g. IRQ-controller).
Partial test	(orange block in Figure3) A partial test is defined as the test of one or more ‘hardware resources’. (A partial test is interruptible because it is executed in background mode).
Entity/unit	Hardware functionality inside the core (e.g. CPU, MMU etc.)
Caller/calling entity	The caller/calling entity is located on a higher AUTOSAR or ISO layer. It is the user of the API call.
test interval CoreTest test Interval	the sum of all the partial tests (executed in background mode) on the hardware resources that are configured to make one complete Core test.
Test Interval Id	Identifier of a test interval, which shall be incremented by each start of a new test interval. As this is a document from professionals for professionals, all other terms are expected to be known.

3 Related documentation

3.1 Input documents

[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of BSW Scheduler
AUTOSAR_SWS_BSW_Scheduler.pdf
[5] ECU Configuration Specification
AUTOSAR_SWS_ECUStateManager.pdf
[6] Specification of Memory Mapping
AUTOSAR_SWS_MemoryMapping.pdf
[7] Requirement on Core Test
AUTOSAR_SRS_CoreTest.pdf
[8] AUTOSAR Basic Software Module Description Template
AUTOSAR_RS_BSWModuleDescriptionTemplate.pdf
[9] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

3.2 Related standards and norms

[10] ISO DIS 26262, www.iso.org

115 Specification of Compiler Abstraction

2 Acronyms and abbreviations

Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

Acronym

Description

Large

huge Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using extended/paged addressing. Some compilers are using the term ‘huge’ instead of ‘far’.

Tiny

small Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using normal addressing. Only data and code within the addressing range of the platform’s architecture is reachable (e.g. 64k on a 16 bit architecture). far Compiler keyword for extended/paged addressing scheme (for data and code that may be outside the normal addressing scheme of the platform’s architecture). near Compiler keyword for normal addressing scheme (for data and code that is within the addressing range of the platform’s architecture).

3 Related documentation

3.1 Input documents

[1] List of Basic Software Modules,
AUTOSAR_TR_BSWModuleList.pdf
[2] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[3] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[4] Specification of ECU Configuration,
AUTOSAR_TPS_ECUConfiguration.pdf
[5] Cosmic C Cross Compiler User’s Guide for Motorola MC68HC12,V4.5
[6] ARM ADS compiler manual
[7] GreenHills MULTI for V850 V4.0.5:
Building Applications for Embedded V800, V4.0, 30.1.2004
[8] TASKING for ST10 V8.5:
C166/ST10 v8.5 C Cross-Compiler User's Manual, V5.16
C166/ST10 v8.5 C Cross-Assembler, Linker/Locator, Utilities User's Manual,
V5.16
[9] Wind River (Diab Data) for PowerPC Version 5.2.1:
Wind River Compiler for Power PC - Getting Started, Edition 2, 8.5.2004
Wind River Compiler for Power PC - User's Guide, Edition 2, 11.5.2004
[10] TASKING for TriCore TC1796 V2.0R1:
TriCore v2.0 C Cross-Compiler, Assembler, Linker User's Guide, V1.2
[11] Metrowerks CodeWarrior 4.0 for Freescale HC9S12X/XGATE (V5.0.25):
Motorola HC12 Assembler, 2.6.2004
Motorola HC12 Compiler, 2.6.2004
Smart Linker, 2.4.2004
[12] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf
[13] Specification of Memory Mapping
AUTOSAR_SWS_MemoryMapping.pdf

114 Specification of Communication Stack Types

2 Acronyms and abbreviations

Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

Acronym	Description
API	Application Programming Interface
DCM	Diagnostic Communication Manager
I-PDU	Interaction Layer PDU. In AUTOSAR the Interaction Layer is equivalent to the Communication Services Layer.
L-PDU	Data Link Layer PDU. In AUTOSAR the Data Link Layer is equivalent to the Communication Hardware Abstraction and Microcontroller Abstraction Layer.
N-PDU	Network Layer PDU. In AUTOSAR the Network Layer is equivalent to the Transport Protocol.
OSEK/VDX	In May 1993 OSEK has been founded as a joint project in the German automotive industry aiming at an industry standard for an open-ended architecture for distributed control units in vehicles. OSEK is an abbreviation for the German term "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug" (English: Open Systems and the Corresponding Interfaces for Automotive Electronics). Initial project partners were BMW, Bosch, DaimlerChrysler, Opel, Siemens, VW and the IIIT of the University of Karlsruhe as co-ordinator. The French car manufacturers PSA and Renault joined OSEK in 1994 introducing their VDX-approach (Vehicle Distributed eXecutive) which is a similar project within the French automotive industry. At the first workshop on October 1995 the OSEK/VDX group presented the results of the harmonised specification between OSEK and VDX. After the 2nd international OSEK/VDX Workshop in October 1997 the 2nd versions of the specifications were published.
PDU	Protocol Data Unit
SDU	Service Data Unit - Payload of PDU
TP	Transport Protocol
Com	Communication
EcuC	ECU Configuration
e.g.	[lat.] exempli gratia = [eng.] for example
i.e.	[lat.] it est = [eng.] that is

3 Related documentation

3.1 Input documents

[1] [GeneralSRS] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[2] [SRSSPAL] General Requirements on
SPAL AUTOSAR_SRS_SPALGeneral.pdf
[3] [StdTypes] Specification of Standard Types
AUTOSAR_SWS_Std_Types.pdf
[4] [PltfTypes] Specification of Platform Types
AUTOSAR_SWS_Platform_Types.pdf
[5] [CompTypes] Specification of Compiler Abstraction
AUTOSAR_SWS_CompilerAbstraction.pdf
[6] [CANTP] Specification of CAN Transport Layer
AUTOSAR_SWS_CANTransportLayer.pdf
[7] [FlexRayTP] Specification of FlexRay Transport Layer
AUTOSAR_SWS_FlexRayTransportLayer.pdf
[8] [CANTRCV] Specification of CAN Transceiver Driver
AUTOSAR_SWS_CANTransceiverDriver.pdf
[9] [FRTRCV] Specification of FlexRay Transceiver Driver
AUTOSAR_SWS_FlexRayTransceiverDriver.pdf
[10] [BSMDT]Basic Software Module Description Template,
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[11] [BSWModule]List of Basic Software Modules
AUTOSAR_TR_BSWModuleList
[12] [BSWGeneral]General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

3.2 Related standards and norms

[CProgLang] ISO/IEC 9899:1990 Programming Language – C
[ISONM] ISO/IEC 15765-2; 2003 Diagnostics on Controller Area Networks (CAN) –
Network layer services

113 Specification of Communication Management

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the Communication Management that are not included in the AUTOSAR glossary [2].

Abbreviation / Acronym	Description
CM	Communication Management
IP	Internet Protocol
SOME/IP	Scalable service-Oriented MiddlewarE over IP
TCP	Transmission Control Protocol
UDP	User Datagram Protocol
E2E	End-to-end communication protection
SoC	Service-Oriented Communication
SecOC	Secure Onboard Communication
DTLS	Datagram Transport Layer Security
DDS	Data Distribution Service
RTPS	Real Time Publish Subscribe Protocol
TTL	Time To Live
TLV	Tag-Length-Value
RPC	Remote Procedure Call
QoS	Quality of Service
BOM	Byte Order Mark

Term	Description:
Callable	In the context of C++ a Callable is defined as: A Callable type is a type for which the INVOKE operation (used by, e.g., std::function, std::bind, and std::thread::thread) is applicable. This operation may be performed explicitly using the library function std::invoke. (since C++17) serializedSample A serializedSample is the serialization of a C++ object to an array and consists of the header that is part of e2e protection and the serialized data.
Service	Binding Act of connecting a Service Requester to a concrete Service Instance of a Service Provider.
Multi-Binding	Multi-Binding describes setups having multiple connections implemented by different technical transport layers and protocol between different instances of a single proxy or skeleton class, e.g.: • A proxy class uses different transport/IPC to communicate with different skeleton instances. • Different proxy instances for the same skeleton instance uses different transport/IPC to communicate with this instance: The skeleton instance supports multiple transport mechanisms to get contacted.

3 Related documentation

3.1 Input documents & related standards and norms

[1] Explanation of ara::com API
AUTOSAR_EXP_ARAComAPI
[2] Glossary
AUTOSAR_TR_Glossary
[3] General Requirements specific to Adaptive Platform
AUTOSAR_RS_General
[4] SOME/IP Protocol Specification
AUTOSAR_PRS_SOMEIPProtocol
[5] Specification of Manifest
AUTOSAR_TPS_ManifestSpecification
[6] Requirements on E2E
AUTOSAR_RS_E2E
[7] E2E Protocol Specification
AUTOSAR_PRS_E2EProtocol
[8] Requirements on Communication Management
AUTOSAR_RS_CommunicationManagement
[9] Middleware for Real-time and Embedded Systems
http://doi.acm.org/10.1145/508448.508472
[10] Patterns, Frameworks, and Middleware: Their Synergistic Relationships
http://dl.acm.org/citation.cfm?id=776816.776917
[11] Reference Model for Service Oriented Architecture 1.0
https://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf
[12] SOME/IP Service Discovery Protocol Specification
AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol
[13] Specification of Platform Types
AUTOSAR_SWS_PlatformTypes
[14] UTF-8, a transformation format of ISO 10646
http://www.ietf.org/rfc/rfc3629.txt
[15] UTF-16, an encoding of ISO 10646
http://www.ietf.org/rfc/rfc2781.txt
[16] Specification of Core Types for Adaptive Platform
AUTOSAR_SWS_CoreTypes
[17] Specification of Socket Adaptor
AUTOSAR_SWS_SocketAdaptor
[18] Data Distribution Service (DDS), Version 1.4
http://www.omg.org/spec/DDS/1.4
[19] DDS Interoperability Wire Protocol, Version 2.2
http://www.omg.org/spec/DDSI-RTPS/2.2
[20] Extensible and Dynamic Topic Types for DDS, Version 1.2
https://www.omg.org/spec/DDS-XTypes/1.2
[21] RPC over DDS, Version 1.0
https://www.omg.org/spec/DDS-RPC/1.0
[22] ISO/IEC C++ 2003 Language DDS PSM, Version 1.0
https://www.omg.org/spec/DDS-PSM-Cxx/1.0
[23] Interface Definition Language (IDL), Version 4.2
https://www.omg.org/spec/IDL/4.2
[24] DDS Security, Version 1.1
https://www.omg.org/spec/DDS-SECURITY/1.1
[25] Methodology for Adaptive Platform
AUTOSAR_TR_AdaptiveMethodology
[26] General Specification of Adaptive Platform
AUTOSAR_SWS_General
[27] ISO/IEC 14882:2011, Information technology – Programming languages – C++
http://www.iso.org
[28] N4659: Working Draft, Standard for ProgrammingLanguage C++
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf
[29] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate

112 Specification of CRC Routines

2 Acronyms and abbreviations

Acronyms and abbreviations, which have a local scope and therefore are not contained in the AUTOSAR glossary, must appear in a local glossary.

Abbreviation /Acronym	Description:
CRC	Cyclic Redundancy Check
ALU	Arithmetic Logic Unit

3 Related documentation

3.1 Input documents

[1] List of Basic Software Modules,
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[4] Requirements on Libraries,
AUTOSAR_SRS_Libraries.pdf
[5] Specification of ECU Configuration,
AUTOSAR_TPS_ECUConfiguration.pdf
[6] A Painless Guide To CRC Error Detection Algorithms, Ross N. Williams
[7] Basic Software Module Description Template,
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[8] Specification of Platform Types,
AUTOSAR_SWS_PlatformTypes.pdf
[9] Specification of Standard Types,
AUTOSAR_SWS_StandardTypes.pdf
[10] Specification of C Implementation Rules,
AUTOSAR_TR_CImplementationRules.pdf

3.2 Related standards and norms

[11] SAE-J1850 8-bit CRC
[12] CCITT-FALSE 16-bit CRC. Refer to:
ITU-T Recommendation X.25 (10/96) (Previously “CCITT Recommendation”)
SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATION
Public data networks – Interfaces
Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit Section 2.2.7.4 "Frame Check Sequence (FCS) field" and Appendix I "Examples of
data link layer transmitted bit patterns by the DCE and the DTE"
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.25-199610-I!!PDFE&type=items
[13] IEEE 802.3 Ethernet 32-bit CRC
[14] “32-Bit Cyclic Redundancy Codes for Internet Applications” [Koopman 2002]
[15] Wikipedia.org – listing of CRCs, including CRC-64-ECMA
https://en.wikipedia.org/wiki/Cyclic_redundancy_check

111 Specification of Communication Manager

2 Acronyms and definitions

Abbreviation /Acronym	Description
BSW	Basic Software
BswM	Basic Software Mode Manager
ComM	Communication Manager
DCM	Diagnostic Communication Manager
Det	Default Error Tracer
EcuM	ECU State Manager module
I-PDU	Information Protocol Data Unit
NM	Network Management
PDU	Protocol Data Unit
SW-C	Software Component
VMM	Vehicle Message Matrix

Term	Description
DCM_ActiveDiagnostic indication	The DCM module indicates an active diagnostic session. DCM need “full communication” = COMM_FULL_COMMUNICATION for diagnostic purpose
Active wake-up	Wake-up caused by the hosting ECU e.g. by a sensor.
Application signal scheduling	Sending of application signals according to the VMM. Scheduling of CAN application signals is performed by the Communication Module, scheduling of LIN application I-PDUs (a PDU containing signals) is performed by the LIN interface and scheduling of FlexRay application PDUs is performed by the FlexRay Interface module.
Bus sleep	No activity required on the communication bus (e.g. CAN bus sleep).
Bus communication messages	Bus communication messages are all messages that are sent on the communication bus. This can be either a diagnostic message or an application message.
COM Inhibition status	Defines whether full communication, silent communication or wakeup is allowed or not.
Communication Channel	The medium used to convey information from a sender (or transmitter) to a receiver.
Communication Mode	Mode determining which kind of communication are allowed: “full communication” = COMM_FULL_COMMUNICATION “no communication” = COMM_NO_COMMUNICATION “silent communication” = COMM_SILENT_COMMUNICATION Note: COMM_SILENT_COMMUNICATION can not be requested by a user. Internal mode for synchronizing network at shutdown
Diagnostic PDU scheduling	Sending of diagnostic PDUs. Scheduling of CAN diagnostic PDUs is performed by the diagnostic module, scheduling of LIN diagnostic PDUs is performed by the diagnostic module and the LIN interface and scheduling of FlexRay diagnostic PDUs is performed by the diagnostic module and the FlexRay Interface module.
ECU shut down	See ECU State Manager specification [6].
Fan-out	Same message/indication are sent to multiple destinations/receivers
Independent software component	A separately developed software component performing a coherent set of functions with a minimum amount of interfaces to other software applications on an ECU. This can be e.g. a basic software component or an application software component.
Passive wake-up	Wake-up by another ECU and propagated (e.g. by bus or wake-upline) to the ECU currently in focus.
System User	An administration functionality (a specific "user", which is generated within the internal context of the ComM) for making a default request and for overriding the user requests.
User	Concept for requestors of the ECU State Manager module and of the Communication Manager Module. A user may be the BswM, a runnable entity, a SW-C or a group of SW-Cs, which act as a single unit towards the ECU State Manager module and the Communication
Manager Module.	User Request A User can request different Communication Modes from ComM
Managed channel	A ComM channel that references another ComM channel by ECUC parameter ComMManageReference (see ECUC_ComM_00893).
Managing channel	A ComM channel that is referenced from at least one other channels by ECUC parameter ComMManageReference (see ECUC_ComM_00893).

3 Related documentation

3.1 Input documents

[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Requirements on Mode Management
AUTOSAR_SRS_ModeManagement.pdf
[5] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[6] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager.pdf
[7] Specification of NVRAM Manager
AUTOSAR_SWS_NVRAMManager.pdf
[8] Specification of RTE Software
AUTOSAR_SWS_RTE.pdf
[9] Specification of Generic Network Management Interface
AUTOSAR_SWS_NetworkManagementInterface.pdf
[10] Specification of Communication
AUTOSAR_SWS_COM.pdf
[11] Specification of Diagnostic Communication Manager
AUTOSAR_SWS_DiagnosticCommunicationManager.pdf
[12] Specification of LIN Interface
AUTOSAR_SWS_LINInterface.pdf
[13] Specification of FlexRay Interface
AUTOSAR_SWS_FlexRayInterface.pdf
[14] Specification of Default Error Tracer
AUTOSAR_SWS_DefaultErrorTracer.pdf
[16] Specification of CAN Transceiver Driver
AUTOSAR_SWS_CANTransceiverDriver.pdf
[17] Specification of CAN Interface
AUTOSAR_SWS_CANInterface.pdf
[18] Specification of FlexRay Transceiver Driver
AUTOSAR_SWS_FlexRayTransceiver.pdf
[19] Specification of PDU Router
AUTOSAR_SWS_PDURouter.pdf
[20] Requirements on IPDU Multiplexer
AUTOSAR_SWS_IPDUM.pdf
[21] Specification of System Services Mode Management
AUTOSAR_SystemServices_ModeManagement.pdf
[22] Specification of C Implementation Rules
AUTOSAR_Tr_CImplementationRules.pdf
[23] Specification of LIN State Manager
AUTOSAR_SWS_LINStateManager.pdf
[24] Specification of CAN State Manager
AUTOSAR_SWS_CANStateManager.pdf
[25] Specification of FlexRay State Manager
AUTOSAR_SWS_FlexRayStateManager.pdf
[26] Basic Software Module Description Template,
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[27] Glossary,
AUTOSAR_TR_Glossary.pdf
[28] Specification of Ethernet State Manager
AUTOSAR_SWS_EthernetStateManager.pdf
[29] Specification of Basic Software Mode Manager
AUTOSAR_SWS_BSWModeManager.pdf
[30] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf
[31] Specification of System Template
AUTOSAR_TPS_SystemTemplate
[32] Specification of Guide to BSW Distribution
AUTOSAR_EXP_BSWDistributionGuide

110 Specification of Communication

2 Acronyms, Abbreviations and Definitions

2.1 Acronyms and Abbreviations

Acronym	Description
DM	Deadline Monitoring, for details see Chapter 7.3.6
I-PDU	Interaction Layer Protocol Data Unit An I-PDU carries signals. It is defined in [17].
L-PDU	Data Link Layer Protocol Data Unit. In AUTOSAR, the Data Link Layer is equivalent to the Communication Hardware Abstraction and Microcontroller Abstraction Layer.
MDT	A detailed description of the Minimum Delay Timer (MDT) can be found in [17]. See also Chapter 7.3.5.5.
PDU Router	The PDU Router is a module transferring I-PDUs from one module to another module. The PDU Router can be utilized for gateway operations and for internal routing purposes.
SDU	Service Data Unit For a description see [1] Chapter 4.
TM	Transmission Mode
TMC	Transmission Mode Condition, see Chapter 7.3.3.2
TMS	Transmission Mode Selector, see Chapter 7.3.3.2

2.2 Definitions

Term	Description:
AUTOSAR COM	The AUTOSAR COM module is derived from [17]. For details, see Chapter 7.2.1.
Confirmation	With a Confirmation, the PDU Router reports that a request by the AUTOSAR COM module has been completed successfully. It is a reaction to a request of COM. E.g. when a PDU has been successfully transmitted.
Data Invalid Value	Value sent by the AUTOSAR COM module to indicate that the sender side AUTOSAR Software Component is not able to provide a valid value.
Dynamic Length Signal	A dynamic length signal is a signal which length can vary at run-time.
Dynamic Length I-PDU	A dynamic length I-PDU is an I-PDU containing a dynamic length signal. It length varies depending on the length of the included dynamic length signal.
Group signal	A group signal is a signal that is contained in a signal group.
Indication	An Indication is asynchronous information from PDU Router to COM, e.g. to acknowledge that something has been received.
Init Value	I-PDUs and signals are set to the Init Value by the AUTOSAR COM module after start-up. This value is used until it is overwritten.
I-PDU group	An I-PDU Group is an arbitrary collection of I-PDUs of the same direction (i.e. send or receive) in the COM module.
Inter-ECU–communication	Communication between two or more ECUs for example via a CAN network
Intra-ECU–communication	Communication between Software components that reside on the same ECU
Large Signal	A large signal is a signal that is too large to fit into a single L-PDU of the underlying communication protocol.
Large I-PDU	Large I-PDUs are I-Signal-I-PDUs which do not fit into a single L-PDU of the underlying communication protocol. Large I-PDUs will be handled like other Specification of Communication I-PDUs by COM, but are transmitted/received via the TP API. Please note that large I-PDUs can also be handled in a more efficient way by LargeDataCOM if they contain just one signal, or if the signals can be (de-)serialized by the RTE. But if the signals have to be treated separately or have to be routed, the large I-PDUs have to be handled by COM.
Message	[17] uses always the synonym message. In AUTOSAR, message is replaced by signal but with the same meaning.
Metadata	For some I-PDUs, e.g. J1939 I-PDUs, the payload is extended with additional metadata containing for example the CAN-ID.
Notification	Information by the AUTOSAR COM module to RTE, e.g. when new data is available, an error occurred.
Signal	A signal in the AUTOSAR COM module’s context is equal to a message in [17]; see also [7].
Signal group	In AUTOSAR, so called complex data types are used. Inside a complex data type, there are one or more data elements (primitive data types), like in a C struct. The data consistency of such complex data types must be ensured. The RTE decomposes the complex data type in single signals and sends them to the AUTOSAR COM module. As these signals altogether need to be treated consistently, they are called signal group. See also [7].
Update-bit	A mechanism supported by the AUTOSAR COM module with that the receiver of a signal/ signal group could identify whether the sender has updated the data in this signal/ signal group before sending. See Chapter 7.9.

3 Related Documentation

3.1 Deliverables of AUTOSAR

[1] AUTOSAR Layered Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] Specification of Communication Stack Types
AUTOSAR_SWS_CommunicationStackTypes.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Basic Software UML Model
AUTOSAR_MOD_BSWUMLModel.eap
[5] Specification of Standard Types
AUTOSAR_SWS_StandardTypes.pdf
[6] Specification of the Virtual Functional Bus
AUTOSAR_EXP_VFB.pdf
[7] Requirements on Communication
AUTOSAR_SRS_COM.pdf
[8] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[9] Requirements on Gateway
AUTOSAR_SRS_Gateway.pdf
[10] Specification of PDU Router
AUTOSAR_SWS_PDURouter.pdf
[11] Specification of Operating System
AUTOSAR_SWS_OS.pdf
[12] System Template
AUTOSAR_TPS_SystemTemplate.pdf
[13] Specification of RTE Software
AUTOSAR_SWS_RTE.pdf
[14] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[15] Specification of Communication Manager
AUTOSAR_SWS_COMManager.pdf
[16] AUTOSAR Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[19] Specification of CAN Transport Layer
AUTOSAR_SWS_CANTransportLayer.pdf
[20] Specification of FlexRay Transport Layer
AUTOSAR_SWS_FlexRayTransportLayer.pdf
[21] List of Basic Software Modules,
AUTOSAR_TR_BSWModuleList.pdf
[22] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate.pdf
[23] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf
3.2 Related Standards and Norms
[17] ISO 17356-4:2005 Road vehicles -- Open interface for embedded automotive
applications -- Part 4: OSEK/VDX Communication (COM)
[18] ISO 17356-6:2006 Road vehicles -- Open interface for embedded automotive
applications -- Part 6: OSEK/VDX Implementation Language (OIL)

109 Specification of CAN Transport Layer

2 Acronyms and abbreviations

The prefix notation used in this document, is as follows:

Prefix	Description
I-	Relative to AUTOSAR COM Interaction Layer
L-	Relative to the CAN Interface module which is equivalent to the Logical Link Control (the upper part of the Data Link Layer – the lower part is called Media Access Control)
N-	Relative to the CAN Transport Layer which is equivalent to the OSI Network Layer.

All acronyms and abbreviations, which are specific to the CAN Transport Layer andvare therefore not contained in the AUTOSAR glossary, are described in the following:

Acronym	Description
CAN L-SDU	This is the SDU of the CAN Interface module. It is similar to CAN N-PDU but from the CAN Interface module point of view.
CAN LSduId	This is the unique identifier of a SDU within the CAN Interface. It is used for referencing L-SDU’s routing properties. Consequently, in order to interact with the CAN Interface through its API, an upper layer uses CAN LSduId to refer to a CAN L-SDU Info Structure.
CAN N-PDU	This is the PDU of the CAN Transport Layer. It contains a unique identifier, data length and data (protocol control information plus the whole N-SDU or a part of it).
CAN N-SDU	This is the SDU of the CAN Transport Layer. In the AUTOSAR architecture, it is a set of data coming from the PDU Router.
CAN N-SDU Info Structure	This is a CAN Transport Layer internal constant structure that contains specific CAN Transport Layer information to process transmission, reception, segmentation and reassembly of the related CAN N-SDU.
CAN NSduId	Unique SDU identifier within the CAN Transport Layer. It is used to reference NSDU’s routing properties. Consequently, to interact with the CAN Transport Layer via its API, an upper layer uses CAN NSduId to refer to a CAN N-SDU Info Structure.
I-PDU	This is the PDU of the AUTOSAR COM module.
PDU	In layered systems, it refers to a data unit that is specified in the protocol of a given layer. This contains user data of that layer (SDU) plus possible protocol control information. Furthermore, the PDU of layer X is the SDU of its lower layer X-1 (i.e. (X)-PDU = (X-1)-SDU).
PduInfoType	This type refers to a structure used to store basic information to process the transmission\reception of a PDU (or a SDU), namely a pointer to its payload in RAM and the corresponding length (in bytes).
SDU	In layered systems, this refers to a set of data that is sent by a user of the services of a given layer, and is transmitted to a peer service user, whilst remaining semantically unchanged.

Abbreviation	Description
BS	Block Size
Can	CAN Driver module
CAN CF	CAN Consecutive Frame N-PDU
CAN FC	CAN Flow Control N-PDU
CAN FF	CAN First Frame N-PDU
CAN SF	CAN Single Frame N-PDU
CanIf	CAN Interface
CanTp	CAN Transport Layer
CanTrcv	CAN Transceiver module
CF	See “CAN CF”
Com	AUTOSAR COM module
Dcm	Diagnostic Communication Manager module
DEM	Diagnostic Event Manager
DET	Default Error Tracer
DLC	Data Length Code (part of CAN PDU that describes the SDU length)
FC	See “CAN FC”
FF	See “CAN FF”
FIM	Function Inhibition Manager
Mtype	Message Type (possible value: diagnostics, remote diagnostics)
N_AI	Network Address Information (see ISO 15765-2).
N_Ar	Time for transmission of the CAN frame (any N-PDU) on the receiver side (see ISO 15765-2).
N_As	Time for transmission of the CAN frame (any N-PDU) on the sender side (see ISO 15765-2).
N_Br	Time until transmission of the next flow control N-PDU (see ISO 15765-2).
N_Bs	Time until reception of the next flow control N-PDU (see ISO 15765-2).
N_Cr	Time until reception of the next consecutive frame N-PDU (see ISO 15765-2).
N_Cs	Time until transmission of the next consecutive frame N-PDU (see ISO 15765-2).
N_Data	Data information of the transport layer
N_PCI	Protocol Control Information of the transport layer
N_SA	Network Source Address (see ISO 15765-2).
N_TA	Network Target Address (see ISO 15765-2). It might already contain the N_TAtype(physical/function) in case of ExtendedAddressing.
N_TAtype	Network Target Address type (see ISO 15765-2).
OBD	On-Board Diagnostic
PDU	Protocol Data Unit
PduR	PDU Router
SDU	Service Data Unit
FS	Flow Status
CAN FD	CAN flexible data rate
CAN_DL	CAN frame data length
TX_DL	Transmit data link layer data length
RX_DL	Received data link layer data length
SF_DL	SingleFrame data length in bytes

Definitions	Description:
Default Error Tracer	The Default Error Tracer is merely a support to SW development and integration and is not contained in the production code. The API is defined, but the functionality can be chosen and implemented by the developer according to his specific needs.
Diagnostic Event Manager	The Diagnostic Event Manager is a standard AUTOSAR module which is available in the production code and whose functionality is specified in the AUTOSAR project.
Extended addressing format	A unique CAN identifier is assigned to each combination of N_SA and Mtype. A unique address is filed to each combination of N_TA and N_TAtype in the first data byte of the CAN frame data field. N_PCI and N_Data are filed in the remaining bytes of the CAN frame data field.
Function Inhibition Manager	The Function Inhibition Manager (FIM) stands for the evaluation and assignment of events to the required actions for Software Components (e.g. inhibition of specific “monitoring functions”). The DEM informs and updates the Function Inhibition Manager (FIM) upon changes of the event status in order to stop or release functional entities according to assigned dependencies. An interface to the functional entities is defined and supported by the Mode Manager. The FIM is not part of the DEM.
Functional addressing	In the transport layer, functional addressing refers to N-SDU, of which parameter N_TAtype (which is an extension to the N_TA parameter [14] used to encode the communication model) has the value functional.This means the N-SDU is used in 1 to n communications. Thus with the CAN protocol, functional addressing will only be supported for Single Frame communication. In terms of application, functional addressing is used by the external (or internal) tester if it does not know the physical address of an ECU that should respond to a service request or if the functionality of the ECU is implemented as a distributed server over several ECUs. When functional addressing is used, the communication is a communication broadcast from the external tester to one or more ECUs (1 to n communication). Use cases are (for example) broadcasting messages, such as “ECUReset” or “CommunicationControl” OBD communication will always be performed as part of functional addressing.
Mixed addressing format	A unique CAN identifier is assigned to each combination of N_SA, N_TA, N_TAtype. N_AE is placed in the first data byte of the CAN frame data field. N_PCI and N_Data are placed in the remaining bytes of the CAN frame data field.
Multiple connection	The CAN Transport Layer should manage several transport protocol communication sessions at a time.
Normal addressing format	A unique CAN identifier is assigned to each combination of N_SA, N_TA, N_TAtype and Mtype. N_PCI and N_Data are filed in the CAN frame data field.
Physical addressing	In the transport layer, physical addressing refers to N-SDU, of which parameter N_TAtype (which is an extension of the N_TA parameter [14] used to encode the communication model) has the value physical. This means the N-SDU is used in 1 to 1 communication, thus physical addressing will be supported for all types of network layer messages. In terms of application, physical addressing is used by the external (or internal) tester if it knows the physical address of an ECU that should respond to a service request. When physical addressing is used, a point to point communication takes place (1 to 1 communication). Use cases are (for example) messages, such as “ReadDataByIdentifier” or “InputOutputControlByIdentifier”
Single connection	The CAN Transport Layer will only manage one transport protocol communication session at a time.
Connection channel	The CAN Transport Layer is handling resources used by multiple connections in order to save RAM. When a connection becames active, the channel that is used by this connection will be unavailable for other connections.
Connection	A transport protocol session, either is a transmission or a reception session on a NSDU.

3 Related documentation

3.1 Input documents

[1] List of Basic Software Modules,
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of ECU Configuration,
AUTOSAR_TPS_ECUConfiguration.pdf
[5] Glossary
AUTOSAR_TR_Glossary.pdf
[6] Requirements on CAN
AUTOSAR_SRS_CAN.pdf
[7] Specification of CAN Interface
AUTOSAR_SWS_CANInterface.pdf
[8] API Specification of Default Error Tracer
AUTOSAR_SWS_DefaultErrorTracer.pdf
[9] Specification of Function Inhibition Manager
AUTOSAR_SWS_FunctionInhibitionManager.pdf
[10] Specification of PDU Router
AUTOSAR_SWS_PDURouter.pdf
[11] Specification of Diagnostic Event Manager
AUTOSAR_SWS_DiagnosticEventManager.pdf
[12] Basic Software Module Description Template,
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[13] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

3.2 Related standards and norms

[14] ISO 15765-2 (2016-04-01), Road vehicles — Diagnostic communication over
Controller Area Networks (DoCAN) — Part 2: Transport protocol and network
layer services
[15] ISO 15765-3 (2004-10-06), Road vehicles — Diagnostics on Controller Area
Networks (CAN) — Part3: Implementation of diagnostic services
[16] ISO 15765-4 (2016-04-01), Road vehicles — Diagnostic communication over
Controller Area Network (DoCAN) — Part 4: Requirements for emissionsrelated systems
[17] ISO 11898-1 (2015-12-15), Road vehicles — Controller area network (CAN)
— Part 1: Data link layer and physical signalling

108 Specification of CAN Transceiver Driver

2 Acronyms and abbreviations

Abbreviation	Description
API	Application Programming Interface
ComM	Communication Manager
DEM	Diagnostic Event Manager
DET	Default Error Tracer
DIO	Digital Input Output (SPAL module)
EB	Externally Buffered channels. Buffers containing data to transfer are outside the SPI Handler/Driver.
EcuM	ECU State Manager
IB	Internally Buffered channels. Buffers containing data to transfer are inside the SPI Handler/Driver.
ISR	Interrupt Service Routine
MCAL	Micro Controller Abstraction Layer
n/a	Not Applicable
SBC	System Basis Chip; a device, which integrates e.g. CAN and/or LIN transceiver, watchdog and power control.
SPAL	Standard Peripheral Abstraction Layer

Term	Description
Port	Port module (SPAL module)
SBC	System Basis Chip; a device, which integrates e.g. CAN and/or LIN transceiver, watchdog and power control.
SPI Channel	A channel is a software exchange medium for data that are defined with the same criteria: configuration parameters, number of data elements with same size and data pointers (source & destination) or location. See specification of SPI driver for more details.
SPI Job	A job is composed of one or several channels with the same chip select. A job is considered to be atomic and therefore cannot be interrupted. A job has also an assigned priority. See specification of SPI driver for more details.
SPI Sequence	A sequence is a number of consecutive jobs to be transmitted. A sequence depends on a static configuration. See specification of SPI driver for more details.
CAN Channel	A physical channel which is connected to a CAN network from a CAN controller through a CAN transceiver.

3 Related documentation

3.1 Input documents
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[4] General Requirements on Basic Software
AUTOSAR_SRS_BSWGeneral.pdf
[5] Specification of Specification of CAN Interface
AUTOSAR_SWS_CANInterface.pdf
[6] Basic Software Module Description Template,
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[7] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf
3.2 Related standards and norms
[8] ISO11898 – Road vehicles - Controller area network (CAN)

107 Specification of CAN State Manager

2 Acronyms and abbreviations

Abbreviation /Acronym	Description
API	Application Program Interface
BSW	Basic Software
CAN	Controller Area Network
CanIf	CAN Interface
CanSM	CAN State Manager
ComM	Communication Manager
DEM	Diagnostic Event Manager
DET	Default Error Tracer
EcuM	ECU State Manager
PDU	Protocol Data Unit
RX	Receive
TX	Transmit
SchM	BSW Scheduler
SWC	Software Component
BswM	Basic Software Mode Manager

3 Related documentation

3.1 Input documents
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[5] Specification of Standard Types
AUTOSAR_SWS_StandardTypes.pdf
[6] Specification of Communication Stack Types
AUTOSAR_SWS_CommunicationStackTypes.pdf
[7] Requirements on CAN
AUTOSAR_SRS_CAN.pdf
[8] Requirements on Mode Management
AUTOSAR_SRS_ModeManagement.pdf
[9] Specification of CAN Transceiver Driver
AUTOSAR_SWS_CANTransceiverDriver.pdf
[10] Specification of Communication Manager
AUTOSAR_SWS_COMManager.pdf
[11] Specification of ECU State Manager
Specification of CAN State Manager
AUTOSAR CP R19-11
12 of 211 Document ID 253: AUTOSAR_SWS_CANStateManager

AUTOSAR confidential -
AUTOSAR_SWS_ECUStateManager.pdf
[12] Specification of Diagnostics Event Manager
AUTOSAR_SWS_DiagnosticEventManager.pdf
[13] Specification of CAN Interface
AUTOSAR_SWS_CANInterface.pdf
[14] Specification of BSW Scheduler
AUTOSAR_SWS_BSW_Scheduler.pdf
[15] Specification of Default Error Tracer
AUTOSAR_SWS_DefaultErrorTracer.pdf
[16] Debugging Concept (internal)
[17] Vehicle and Application Mode Management Concept (internal)
[18] Specification of Basic Software Mode Manager
AUTOSAR_SWS_BSWModeManager.pdf
[19] Specification of CAN Network Management, AUTOSAR_SWS_Can_NM.pdf
[20] Specification of Diagnostic Communication Manager
AUTOSAR_SWS_DiagnosticCommunicationManager.pdf
[21] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

106 Specification of CAN Network Management

2 Acronyms and abbreviations

The glossary below includes acronyms and abbreviations relevant to the CanNm
module that are not included in the AUTOSAR glossary.

Acronym/abbreviation	Description
CanIf	Abbreviation for the CAN Interface
CanNm	Abbreviation for CAN Network Management
CBV	Control Bit Vector
CWU	Car Wakeup
ERA	External Request Array
EIRA	External and Internal Request Array
NM	Network Management
PNC	Partial Network Cluster
PNI	Partial Network Information

Term	Description
PDU transmission ability is disabled	This means that the Network Management PDU transmission has been disabled by the service CanNm_DisableCommunication.
Repeat Message Request Bit Indication	CanNm_RxIndication finds the RptMsgRequest set in the Control Bit Vector of a received Network Management PDU.
PN filter mask	Vector of filter mask bytes defined by configuration container(s) CanNmPnFilterMaskByte

3 Related documentation

3.1 Input documents

[1] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[2] Requirements on Network Management
AUTOSAR_SRS_NetworkManagement.pdf
[3] Specification of CAN Interface
AUTOSAR_SWS_CANInterface.pdf
[4] Specification of Communication Stack Types
AUTOSAR_SWS_CommunicationStackTypes.pdf
[5] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[6] Specification of Generic Network Management Interface
AUTOSAR_SWS_NetworkManagementInterface.pdf
[7] Specification of Communication Manager
AUTOSAR_SWS_ComManager.pdf
[8] Specification of Standard Types
AUTOSAR_SWS_StandardTypes.pdf
[9] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

105 Specification of CAN Interface

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the CAN Interface
module that are not included in the [8, AUTOSAR glossary].

Abbreviation / Acronym	Description
CAN L-PDU	CAN Protocol Data Unit. Consists of an identifier, Data Length and data (SDU) Visible to the CAN driver.
CAN L-SDU	CAN Service Data Unit. Data that are transported inside the CAN L-PDU. Visible to the upper layers of the CAN interface (e.g. PDU Router).
CanDrv	CAN Driver module
CAN FD	CAN with Flexible Data-Rate
CanId	CAN Identifier
CanIf	CAN Interface module
CanNm	CAN Network Management module
CanSm	CAN State Manager module
CanTp	CAN Transport Layer module
CanTrcv	CAN Transceiver Driver module
CanTSyn	Global Time Synchronization over CAN
ComM	Communication Manager module
DCM	Diagnostic Communication Manager module
EcuM	ECU State Manager module
HOH	CAN hardware object handle
HRH	CAN hardware receive handle
HTH	CAN hardware transmit handle
J1939Nm	J1939 Network Management module
J1939Tp	J1939 Transport Layer module
PduR	PDU Router module
PN	Partial Networking
SchM	Scheduler Module

Term	Description
Buffer	Fixed sized memory area for a single data unit (e.g. CAN ID, Data Length, SDU, etc.) is stored at a dedicated memory address in RAM.
CAN communication matrix	Describes the complete CAN network: • Participating nodes • Definition of all CAN PDUs (Identifier, Data Length) • Source and Sinks for PDUs
CAN Controller	A CAN Controller is a CPU on-chip or external standalone hardware device. One CAN Controller is connected to one physical channel.
CAN Device Driver	Generic term of CAN Driver and CAN Transceiver Driver.
CAN Hardware Unit	A CAN Hardware Unit may consist of one or multiple CAN Controllers of the same type and one, two or multiple CAN RAM areas. The CAN Hardware Unit is located on-chip or as external device. The CAN hardware unit is represented by one CAN Driver.
CanIf Controller mode state machine	This is not really a state machine, which may be influenced by transmission requests. This is an image of the current abstracted state of an appropriate CAN Controller. The state transitions can only be realized by upper layer modules like the CanSm or by external events like e.g. if a BusOff occurred.
CanIf Receive L-PDU / CanIf Rx	L-PDU L-PDU of which the direction is set to "lower to upper layer".
CanIf Receive L-PDU buffer /CanIfRxBuffer	Single element RAM buffer located in the CAN Interface module to store whole receive L-PDUs.
CanIf Transmit L-PDU / CanIf Tx	L-PDU L-PDU of which the direction is set to "upper to lower layer".
CanIf Transmit L-PDU buffer /CanIfTxBuffer	Single CanIfTxBuffer element located in the CanIf to store one or multiple CanIf Tx L-PDUs. If the buffersize of a single CanIfTxBuffer element is set to 0, a CanIfTxBuffer element is only used to refer a HTH.
Hardware object / HW object	A CAN hardware object is defined as a PDU buffer inside the CAN RAM of the CAN Hardware Unit / CAN Controller.
Hardware Receive Handle(HRH)	The Hardware Receive Handle (HRH) is defined and provided by the CAN Driver. Each HRH typically represents just one hardware object. The HRH is used as a parameter by the CAN Interface Layer for i.e. software filtering.
Hardware Transmit Handle(HTH)	The Hardware Transmit Handle (HTH) is defined and provided by the CAN Driver. Each HTH typically represents just one or multiple CAN hardware objects that are configured as CAN hardware transmit buffer pool.
Inner priority inversion	Transmission of a high-priority L-PDU is prevented by the presence of a pending low-priority L-PDU in the same transmit hardware object.
Integration Code	Code that the Integrator needs to add to an AUTOSAR System, to adapt non-standardized functionalities. Examples are Callouts of the ECU State Manager and Callbacks of various other BSW modules. The I/O Hardware Abstraction is called Integration Code, too.
Lowest In - First Out / LOFO	This is a data storage procedure, whereas always the elements with the lowest values will be extracted.
L-PDU channel group	Group of CAN L-PDUs, which belong to just one underlying network. Usually they are handled by one upper layer module.
Outer priority inversion	A time gap occurs between two consecutive transmit L-PDUs. In this case a lower priority L-PDU from another node can prevent sending the own higher priority L-PDU. Here the higher priority LPDU cannot participate in arbitration during network access because the lower priority L-PDU already won the arbitration.
Physical channel	A physical channel represents an interface from a CAN Controller to the CAN Network. Different physical channels of the CAN Hardware Unit may access different networks.
Tx request	Transmit request to the CAN Interface module from a upper layer module of the CanIf

3 Related documentation

3.1 Input documents & related standards and norms

References
[1] Specification of CAN Driver
AUTOSAR_SWS_CANDriver
[2] Specification of CAN Transceiver Driver
AUTOSAR_SWS_CANTransceiverDriver
[3] Specification of CAN State Manager
AUTOSAR_SWS_CANStateManager
[4] Specification of CAN Network Management
AUTOSAR_SWS_CANNetworkManagement
[5] Specification of CAN Transport Layer
AUTOSAR_SWS_CANTransportLayer
[6] Specification of PDU Router
AUTOSAR_SWS_PDURouter
[7] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[8] Glossary
AUTOSAR_TR_Glossary
[9] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral
[10] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral
[11] Requirements on CAN
AUTOSAR_SRS_CAN
[12] ISO 11898-1:2015 – Road vehicles – Controller area network (CAN)
[13] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager
[14] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration

104 Specification of CAN Driver

2 Acronyms and abbreviations

Abbreviation /Acronym	Description
DLC	Data Length Code (part of CAN message describes the SDU length)
HRH	Hardware Receive Handle
HTH	Hardware Transmit Handle
ISR	Interrupt Service Routine
MCAL	Microcontroller Abstraction Layer
SFR	Special Function Register. Hardware register that controls the controller behavior.
SPAL	Standard Peripheral Abstraction Layer
ICOM	Intelligent Communication Controller

Term	Description
CAN controller	A CAN controller serves exactly one physical channel.
CAN Hardware Unit	A CAN Hardware Unit may consists of one or multiple CAN controllers of the same type and one or multiple CAN RAM areas. The CAN Hardware Unit is either on-chip, or an external device. The CAN Hardware Unit is represented by one CAN driver.
CAN L-PDU Data Link Layer Protocol Data Unit. Consists of Identifier, Data Length and Data (SDU). (see[18])
CAN L-SDU Data Link Layer Service Data Unit. Data that is transported inside the LPDU. (see[18])
Hardware Object	A CAN hardware object is defined as a PDU buffer inside the CAN RAM of the CAN hardware unit / CAN controller. A Hardware Object is defined as L-PDU buffer inside the CAN RAM of the CAN Hardware Unit.
Hardware Receive Handle(HRH)	The Hardware Receive Handle (HRH) is defined and provided by the CAN Driver. Each HRH typically represents just one hardware object. The HRH can be used to optimize software filtering.
Hardware Transmit Handle (HTH)	The Hardware Transmit Handle (HTH) is defined and provided by the CAN Driver. Each HTH typically represents just one or multiple hardware objects that are configured as hardware transmit buffer pool.
Inner Priority Inversion	Transmission of a high-priority L-PDU is prevented by the presence of a pending low-priority L-PDU in the same transmit hardware object.
L-PDU Handle	The L-PDU handle is defined and placed inside the CanIf module layer.
Typically each handle represents an L-PDU, which is a constant structure with information for Tx/Rx processing.
Outer Priority Inversion	A time gap occurs between two consecutive transmit L-PDUs. In this case a lower priority L-PDU from another node can prevent sending the own higher priority L-PDU. Here the higher priority L-PDU cannot participate in arbitration during network access because the lower priority L-PDU already won the arbitration.
Physical Channel A physical channel represents an interface from a CAN controller to the CAN Network. Different physical channels of the CAN hardware unit may access different networks.
Priority	The Priority of a CAN L-PDU is represented by the CAN Identifier. The lower the numerical value of the identifier, the higher the priority.

3 Related documentation

3.1 Input documents

[1] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[3] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[4] Requirements on CAN
AUTOSAR_SRS_CAN.pdf
[5] Specification of CAN Interface
AUTOSAR_SWS_CANInterface.pdf
[6] Specification of Default Error Tracer
AUTOSAR_SWS_DefaultErrorTracer.pdf
[7] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager.pdf
[8] Specification of MCU Driver
AUTOSAR_SWS_MCUDriver.pdf
[9] Specification of Operating System
AUTOSAR_SWS_OS.pdf
[10] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[11] Specification of SPI Handler/Driver
AUTOSAR_SWS_SPIHandlerDriver.doc.pdf
[12] Specification of Memory Mapping
AUTOSAR_SWS_MemoryMapping.pdf
[13] Specification of BSW Scheduler
AUTOSAR_SWS_BSW_Scheduler.pdf
[14] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[15] List of Basis Software Modules
AUTOSAR_TR_BSWModuleList.pdf
Specification of CAN Driver
AUTOSAR CP R19-11
19 of 118 Document ID 11: AUTOSAR_SWS_CANDriver

AUTOSAR confidential -
[16] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf
3.2 Related standards and norms
[17] ISO11898 – Road vehicles - Controller area network (CAN)
[18] ISO/IEC 7498-1 – OSI Basic Reference Model
[19] CiA601-2 Node and system design Part 2: CAN controller interface specification
https://www.can-cia.org/can-knowledge/can/cia601/

103 Specification of Bus Mirroring

2 Acronyms and Abbreviations

Currently, the Bus Mirroring module does not define any acronyms, abbreviations, or terms that are not defined in the [1, AUTOSAR glossary].

3 Related Documentation

3.1 Input Documents & Related Standards and Norms
[1] Glossary
AUTOSAR_TR_Glossary
[2] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral
[3] Requirements on Bus Mirroring
AUTOSAR_SRS_BusMirroring
[4] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral

102 Specification of Basic Software Multicore Library

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the Bmc module that are not included in the [1, AUTOSAR glossary].

Abbreviation/Acronym	Description
Bmc	Basic Software Multicore Library
DET	Default Error Tracer
s16	Mnemonic for sint16, specified in AUTOSAR_SWS_PlatformTypes
s32	Mnemonic for sint32, specified in AUTOSAR_SWS_PlatformTypes
s64	Mnemonic forsint64, specified in AUTOSAR_SWS_PlatformTypes
s8	Mnemonic for sint8, specified in AUTOSAR_SWS_PlatformTypes
u16	Mnemonic for uint16, specified in AUTOSAR_SWS_PlatformTypes
u32	Mnemonic for uint32, specified in AUTOSAR_SWS_PlatformTypes
u64	Mnemonic for uint64, specified in AUTOSAR_SWS_PlatformTypes
u8	Mnemonic for uint8, specified in AUTOSAR_SWS_PlatformTypes

3 Related documentation

3.1 Input documents & related standards and norms
[1] Glossary
AUTOSAR_TR_Glossary
[2] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral
[4] Requirements on Libraries
AUTOSAR_SRS_Libraries
[5] Specification of Platform Types
AUTOSAR_SWS_PlatformTypes
[6] ISO/IEC 9899:2011
http://www.iso.org

101 Specification of Basic Software Mode Manager

2 Acronyms and abbreviations

Abbreviation /Acronym	Description
BSW	Basic Software
BswM	BSW Mode Manager
BSWMD	Basic Software Module Description
CDD	Complex Driver
Dem	Diagnostic Event Manager
Det	Default Error Tracer
ECU	Electronic Control Unit
ICOM	Intelligent Communication Controller
RTE	Real Time Environment
SWC/SW-C	Software Component
SWCD	Software Component Description

3 Related documentation

3.1 Input documents
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Requirements on Mode Management
AUTOSAR_SRS_ModeManagement.pdf
[5] Specification of Communication
AUTOSAR_SWS_COM.pdf
[6] Specification of FlexRay State Manager
AUTOSAR_SWS_FlexRayStateManager.pdf
[7] Specification of PDU Router
AUTOSAR_SWS_PDURouter.pdf
[8] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[9] Specification of Default Error Tracer
AUTOSAR_SWS_DefaultErrorTracer.pdf
[10] Specification of RTE Software
AUTOSAR_SWS_RTE.pdf
[11] Specification of Diagnostic Communication Manager
AUTOSAR_SWS_DiagnosticCommunicationManager.pdf
[12] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager.pdf
[13] Specification of LIN State Manager
AUTOSAR_SWS_LINStateManager.pdf
[14] Specification of CAN State Manager
AUTOSAR_SWS_CANStateManager.pdf
[15] Specification of Generic Network Management Interface
AUTOSAR_SWS_NetworkManagementInterface.pdf
[16] Specification of Communication Manager
AUTOSAR_SWS_COMManager.pdf
[17] Specification of Ethernet State Manager
AUTOSAR_SWS_EthernetStateManager.pdf
[18] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

100 General Specification of Basic Software Modules

2 Acronyms and abbreviations

Abbreviation /Acronym	Description
<Ie>	Implementation specific file name extension, see SWS_BSW_00103.
<Ma>	Module abbreviation, see SWS_BSW_00101.
<MA>	Capitalized module abbreviation. The Capitalized module abbreviation <MA> is the Module abbreviation <Ma> (see bsw_constr_001) completely written in upper case.
MCAL	The MCAL, Microcontroller Abstraction Layer, is defined in AUTOSAR Layered Software Architecture [2]
<Mip>	Module implementation prefix, see SWS_BSW_00102. <MIP> Capitalized module implementation prefix. The Capitalized module implementation prefix <MI\P> is the Module implementation prefix <Mip> (SWS_BSW_00102) completely written in upper case.
WCET	Worst case execution time.
BSWMD	Basic Software Module Description
SWCD	Software Component Description

Term	Description
BSW driver	For a list of BSW drivers see the List of Basic Software Modules [1],column “AUTOSAR SW layer”.
Camel case	This document does not aim to specify rules for the camel case notation. Definition of CamelCase according to Wikipedia (see chapter 3.1) “camelCase (…) is the practice of writing compound words or phrases in which the elements are joined without spaces, with each element's initial letter capitalized within the compound and the first letter either upper or lower case (…).” Example: GetVersionInfo
Module implementation prefix	Module implementation prefix, see SWS_BSW_00102.
Module abbreviation	Module abbreviation, see SWS_BSW_00101.

3 Related documentation

3.1 Input documents

[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] AUTOSAR Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] AUTOSAR General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] AUTOSAR Specification of BSW Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[5] AUTOSAR Specification of RTE
AUTOSAR_SWS_RTE.pdf
[6] AUTOSAR Specification of Memory Mapping
AUTOSAR_SWS_MemoryMapping.pdf
[7] AUTOSAR Glossary
AUTOSAR_TR_Glossary.pdf
[8] AUTOSAR Specification of Operating System
AUTOSAR_SWS_OS.pdf
[9] AUTOSAR Specification of Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[10] AUTOSAR Specification of Diagnostic Event Manager
AUTOSAR_SWS_DiagnosticEventManager.pdf
[11] AUTOSAR Methodology
AUTOSAR_TR_Methodology.pdf
[12] AUTOSAR Specification of Standard Types
AUTOSAR_SWS_PlatformTypes.pdf
[13] AUTOSAR Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
[14] AUTOSAR Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration.pdf
[15] AUTOSAR Specification of Default Error Tracer
AUTOSAR_SWS_ DefaultErrorTracer.pdf
[16] CamelCase – Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/CamelCase

3.2 Related standards and norms

[17] MISRA C 2012 Standard
Homepage: http://www.misra.org.uk/
[18] IEC 7498-1 The Basic Model, IEC Norm, 1994

99 Specification of Bit Handling Routines

2 Acronyms and abbreviations
Acronyms and abbreviations, which have a local scope and therefore are not contained in the AUTOSAR glossary, must appear in a local glossary.

Abbreviation /Acronym	Description
Bfx	Short name for Bitfield functions for fixed point
u8	Short name for uint8, specified in AUTOSAR_SWS_PlatformTypes
u16	Short name for uint16, specified in AUTOSAR_SWS_PlatformTypes
u32	Short name for uint32, specified in AUTOSAR_SWS_PlatformTypes
s8	Short name for sint8, specified in AUTOSAR_SWS_PlatformTypes
s16	Short name for sint16, specified in AUTOSAR_SWS_PlatformTypes
s32	Short name for sint32, specified in AUTOSAR_SWS_PlatformTypes
DET	Default Error Tracer

Term	Description
boolean	Boolean data type, specified in AUTOSAR_SWS_PlatformTypes

3 Related documentation

3.1 Input documents
[1] List of Basic Software Modules,
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of ECU Configuration,
AUTOSAR_TPS_ECUConfiguration.pdf
[5] AUTOSAR Basic Software Module Description Template,
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[6] Specification of Platform Types,
AUTOSAR_SWS_PlatformTypes.pdf
[7] Specification of Standard Types,
AUTOSAR_SWS_StandardTypes.pdf
[8] Requirement on Libraries,
AUTOSAR_SRS_Libraries.pdf
[9] Specification of Memory Mapping,
AUTOSAR_SWS_MemoryMapping
[10] Software Component Template,
AUTOSAR_TPS_SoftwareComponentTemplateSoftware
[11] Specification of C Implementation Rules,
AUTOSAR_TR_CImplementationRules.pdf
3.2 Related standards and norms
[10] ISO/IEC 9899:1990 Programming Language – C

98 Specification of Platform Types for Adaptive Platform

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations used in this document that are not included in the [2, AUTOSAR glossary].

Terms	Description
2’s complement	method of signed number representation.

3 Related documentation

3.1 Input documents & related standards and norms

[1] Specification of Manifest
AUTOSAR_TPS_ManifestSpecification
[2] Glossary
AUTOSAR_TR_Glossary
[3] Specification of Communication Management
AUTOSAR_SWS_CommunicationManagement
[4] General Requirements specific to Adaptive Platform
AUTOSAR_RS_General
[5] ISO/IEC 14882:2011, Information technology – Programming languages – C++
http://www.iso.org
[6] Guidelines for the use of the C++14 language in critical and safety-related systems
AUTOSAR_RS_CPP14Guidelines
[7] Specification of Core Types for Adaptive Platform
AUTOSAR_SWS_CoreTypes

97 Specification of ADC Driver

2 Acronyms and abbreviations

Abbreviation /Acronym	Description
DEM	Diagnostic Event Manager
DET	Default Error Tracer
ADC	Analogue Digital Converter
MCU	Microcontroller Unit
API	Application Programming Interface
HW	Hardware
SW	Software

term	Description
ADC HW Unit	Represents a microcontroller input electronic device that includes all parts necessary to perform an “analogue to digital conversion”.
ADC Module	ADC Basic Software module ADC Driver, abbreviated also with ADC Driver
ADC Channel	Represents a logical ADC entity bound to one port pin. Multiple ADC entities can be mapped to the same port pin.
ADC Channel Group	A group of ADC channels linked to the same ADC hardware unit (e.g. one Sample&Hold and one A/D converter). The conversion of the whole group is triggered by one trigger source.
ADC Result Buffer(ADC Streaming Buffer, ADC Stream Buffer)	The user of the ADC Driver has to provide a buffer for every group. This buffer can hold multiple samples of the same group channel if streaming access mode is selected. If single access mode is selected one sample of each group channel is held in the buffer.
Software Trigger	Software API call that starts the conversion of one ADC channel group or a continuous series of ADC channel group conversions.
Hardware Trigger	ADC internal trigger signal that starts one conversion of an ADC channel group.
ADC hardware trigger are generated internally in the ADC hardware, e.g. based on an ADC timer or a trigger edge signal. The trigger hardware is tightly coupled or integrated in the ADC hardware. No software is required to start the ADC channel group conversion after the hardware trigger is detected. Note: If the ADC hardware does not support hardware trigger, a similar behavior can be realized with software trigger in combination with the GPT/ICU driver. E.g. in a GPT timer notification function a software triggered ADC channel group conversion can be started.
Conversion Mode One-Shot	The conversion of an ADC channel group is performed once after a trigger and the results are written to the assigned result buffer. A trigger can be a software API call or a hardware event.
Conversion Mode Continuous	The conversions of an ADC channel group are performed continuously after a software API call (start) and the results are written to the assigned result buffer. The conversions themselves are running automatically (hardware/interrupt controlled). The Continuous conversions can be stopped by a software API call (stop).
Sampling Time, Sample Time	Time during which the analogue value is sampled (e.g. loading the capacitor, …)
Conversion Time	Time during which the sampled analogue value is converted into digital representation.
Acquisition Time	Sample Time + Conversion Time.

3 Related documentation

3.1 Input documents
[1] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[2] General Requirements on SPAL,
AUTOSAR_SRS_SPALGeneral.pdf
[3] Specification of Standard Types,
AUTOSAR_SWS_StandardTypes.pdf
[4] List of Basic Software Modules,
AUTOSAR_TR_BSWModuleList.pdf
[5] Specification of Diagnostic Event Manager,
AUTOSAR_SWS_DiagnosticEventManager.pdf
[6] Specification of Default Error Tracer,
AUTOSAR_SWS_DefaultErrorTracer.pdf
[7] Requirements on ADC Driver,
AUTOSAR_SRS_ADCDriver.pdf
[8] Specification of ECU Configuration,
AUTOSAR_TPS_ECUConfiguration.pdf
[9] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[10] Specification of ECU State Manager,
AUTOSAR_SWS_ECUStateManager.pdf
[11] Specification of I/O Hardware Abstraction,
AUTOSAR_SWS_IOHardwareAbstraction.pdf
[12] Basic Software Module Description Template,
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[13] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

96 Specification of Module XCP

2 Acronyms and abbreviations

Acronym	Description
AUTOSAR	AUTomotive Open System ARchitecture
A2L	File Extension for an ASAM 2MC Language File
ASAM	Association for Standardization of Automation and Measuring Systems
BSW	Basic Software
CAN	Controller Area Network
CanIf	CAN Interface
CTO	Command Transfer Object
DAQ	Data AcQuisition, Data AcQuisition Packet
DTO	Data Transfer Object
ECU	Electronic Control Unit
FrIf	FlexRay Interface
LPDU	Data Link Layer PDU
MCD	Measurement Calibration and Diagnostics
MISRA	Motor Industry Software Reliability Association
ODT	Object Descriptor Table
PDU	Protocol Data Unit
RAM	Random Access Memory
ROM	Read Only Memory
SchM	Schedule Manager
SVN	Subversion
SRS	Software Requirements Specification
STIM	Data Stimulation packet
SW	Software
SWS	Software Specification
TCP/IP	Transfer Control Protocol / Internet Protocol
TS	Time Stamp
UDP/IP	User Datagram Protocol / Internet Protocol
URL	Uniform Resource Locator
XCP	Universal Calibration Protocol
XML	Extensible Markup Language
ISR	Interrupt Service Routine
DET	Default Error Tracer (AUTOSAR BSW module)

3 Related documentation

3.1 Input documents

[0] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] AUTOSAR Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of RTE (BSW Scheduler)
AUTOSAR_SWS_RTE.pdf
[5] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration
[6] Specification of Memory Mapping
AUTOSAR_SWS_MemoryMapping.pdf
[7] Specification of FlexRay Interface
AUTOSAR_SWS_FlexRayInterface.pdf
[8] Specification of CAN Interface
AUTOSAR_SWS_CANInterface
[9] Specification of Socket Adaptor
AUTOSAR_SWS_SocketAdaptor
[10] Requirements on XCP Module
AUTOSAR_SRS_XCP.pdf
[11] AUTOSAR OS Specification
AUTOSAR_SWS_OS
[12] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf
3.1.1 Related standards and norms
[13] ASAM XCP – The Universal Measurement and Calibration Protocol:
ASAM_XCP_Part1-Overview - Version 1.1
[14] ASAM XCP – Transport Layer Specification XCP on CAN:
ASAM_XCP_Part3 Transport-Layer-Specification_XCPonCAN - Version 1.2
[15] ASAM XCP – Transport Layer Specification XCP on Ethernet:
ASAM_XCP_Part3-Transport-Layer-Specification_XCPonEthernet
(TCP_IP&UDP_IP) – Version 1.1
[16] ASAM XCP – Transport Layer Specification XCP on FlexRay:
ASAM_XCP_Part3-Transport-Layer-Specification_XCPonFlexRay-Version 1.1

95 Specification of Watchdog Driver

2 Acronyms and abbreviations

Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

Abbreviation /Acronym	Description
DIP	Digital Input/Output
DET	Default Error Tracer
DEM	Diagnostic Event Manager – module to handle diagnostic relevant events.
SPI	Serial Peripheral Interface
WDG	Watchdog (module specific prefix)

Definition	Description
Off-Mode	The watchdog hardware is disabled / shut down. This might be necessary in order to shut down the complete ECU and not get cyclic resets from a still running external watchdog. This mode might not be allowed for safety critical systems. In this case, the Wdg module has to be configured to prevent switching to this mode.
Slow-Mode	Triggering the watchdog hardware can be done with a long timeout period. This mode can e.g. be used during system startup / initialization phase. E.g. the watchdog hardware is configured for toggle mode (no constraints on the point in time at which the triggering is done) and a timeout period of 20 milliseconds.
Fast-Mode	Triggering the watchdog hardware has to be done with a short timeout period. This mode can e.g. be used during normal operations of the ECU. E.g. the watchdog hardware is configured for window mode (triggering the watchdog has to occur within certain minimum / maximum boundaries within the timeout period) and a timeout period of 5 milliseconds

3 Related documentation

3.1 Input documents
[1] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[3] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[4] Requirements on Watchdog Driver
AUTOSAR_SRS_WatchdogDriver.pdf
[5] Specification of Watchdog Interface
AUTOSAR_SWS_WatchdogInterface.pdf
[6] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[7] Specification of RTE Software Specification of Watchdog Driver
AUTOSAR_SWS_RTE.pdf
[8] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList
[9] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.