Autosar list of reference, abbreviation and term.(95-140/303): English(40b)

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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_FlashEEPROMEmulation.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_EthernetInterface.pdf

## 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 <MOD- ULE_NAME> 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CryptoDriver.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CoreTest.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CompilerAbstraction.pdf

## 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
 https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CommunicationStackTypes.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_SWS_CommunicationManagement.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CRCLibrary.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_COMManager.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_COM.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CANTransportLayer.pdf
 
## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CANTransceiverDriver.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CANStateManager.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CANNetworkManagement.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CANInterface.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_CANDriver.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_BusMirroring.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_BSWMulticoreLibrary.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_BSWModeManager.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_BSWGeneral.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_BFXLibrary.pdf

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
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_SWS_AdaptivePlatformTypes.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_ADCDriver.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_XCP.pdf

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_WatchdogDriver.pdf

## 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.