Autosar list of reference, abbreviation and term.(141-190/303): English(40a)

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

# 190 Specification of Synchronized Time-Base Manager
 AUTOSAR_SWS_SynchronizedTimeBaseManager.pdf 

##2.1 AcronymsandAbbreviations

|Abbreviation / Acronym |Description|
|:--|:--|
|(G)TD |(Global) Time Domain|
|(G)TM |(Global)Time Master|
|<Bus>TSyn |A bus specific Time Synchronization Provider module|
|AVB|Audio Video Bridging|
|BMCA |Best Master Clock Algorithm|
|CAN |Controller Area Network|
|CanTSyn |Time Synchronization Provider module for CAN|
|DET |Default Error Tracer|
|ECU |Electronic Control Unit|
|ETH |Ethernet|
|EthTSyn |Time Synchronization Provider module for Ethernet|
|FR|FlexRay|
|FRC|Free running counter|
|FrTSyn|Time Synchronization Provider module for FlexRay|
|FUP message |Follow-Up message for a Synchronized Time Base|
|GM(C)|Grand Master (Clock)|
|GTS|Global Time Synchronization|
|OFNS message|Time Synchronization message for an Offset Time Base (containing the nanosecond part of the time)|
|OFS message |Time Synchronization message for an Offset Time Base|
|PTP|Precision Time Protocol|
|StbM|Synchronized Time-Base Manager|
|SYNC message |Time Synchronization message for a Synchronized Time Base |
|TG|Time Gateway|
|Timesync |Time Synchronization|
|TS|Time Slave|
|TSD|Time Sub-domain|

##2.2 Definitions 
###2.2.1 Clock
Definition: A Clock references to a time capable hardware part of a microcontroller.
11 of 186 Document ID 421: AUTOSAR_SWS_SynchronizedTimeBaseManager
- AUTOSAR confidential -
 Specification of Synchronized Time-Base Manager AUTOSAR CP R19-11
###2.2.2 Global Time Master
Definition: A Global Time Master is the global owner and origin for a certain Time
Base and on the top of the Time Base hierarchy for that Time Base.
###2.2.3 Synchronized Time Base
Definition: A Synchronized Time Base is a Time Base existing at a processing entity (actor / processor / node of a distributed system) that is synchronized with Time Bases at different processing entities. A Synchronized Time Base can be achieved by time protocols or time agreement protocols that derive the Synchronized Time Base in a defined way from one or more physical Time Bases. Examples are the network time protocol (NTP) and FlexRay time agreement protocol.

###2.2.4 Time Base
Definition: A Time Base is a unique time entity characterized by:
 Progression of time, which denotes how time progresses, i.e. the rate (i.e. the rate is derived from a local quartz oscillator) and absolute changes of the time
value at certain point in times (e.g. effects of offset correction in FlexRay).
 Ownership, which denotes who is the owner of the time base. A distributed FlexRay Time Base e.g. has multiple owners and the progression of time with respect to rate and offset corrections is a result of involving a subset of FlexRay
nodes.
 Reference to the physical world, i.e. whether the Time Base is a relative Time
Base counting local operation time of an ECU or representing an absolute time
like UTC. A Time Base can have more than one reference, e.g. it can be a relative time which in combination with an offset value also represents an absolute time.

###2.2.5 Time Base Provider
Definition: A Time Base Provider is the role that a <Bus>TSyn module takes for a given Time Base. Therefore a <Bus>TSyn module can contain only one Time Base provider or more than one Time Base provider. Time Base providers are either of type importer or exporter, whereas an importer acts as Time Slave and an exporter acts as Time Master. A Time Gateway consists of one Time Base importer and one or more Time Base exporters for a given Time Base. In order to limit the terminology importers are denoted as slaves and exporters are denoted as masters.
###2.2.6 Time Communication Port
Definition: A Time Communication Port is a physical communication interface (in AUTOSAR coverable by the item: Physical Connector) at an ECU which is used to transport time information.
###2.2.7 Time Communication Service
Definition: A Time Communication Service is an interaction between Time Bases which is performed by Time Base providers. Time communication services are message based between a Time Master and one or more Time Slaves or between one Time Slave and his Time Master.

###2.2.8 Time Base Customer
a) Active Customer
This kind of customer autonomously calls the Synchronized Time-Base Manager either
 To read time information (arrow “2” in Figure 1) from the Synchronized Time-Base Manager or
 To update (arrow “3” in Figure 1) the Time Base maintained by the Synchronized Time-Base Manager according to application information.
b) Triggered Customer
This kind of customer is triggered by the Synchronized Time-Base Manager (arrow “1” in Figure 1). Thus, the Synchronized Time-Base Manager itself is aware of the required functionality of the customer, and uses the defined interface of the customer to access it.
This functionality is currently limited to synchronization of OS ScheduleTables.
c) Notification Customer
This kind of customer is notified by the Synchronized Time-Base Manager (arrow “4” in Figure 1), if the following Time Base related events occur:
14 of 186
 
Time Base status has changed (e.g. a timeout has occurred for a Time Base)
Time Base value has reached a given value, which has been previously
set by the customer (arrow “5” in Figure 1).

###2.2.9 Time Domain
Specification of Synchronized Time-Base Manager AUTOSAR CP R19-11
Definition: A Time Domain denotes which components (e.g. nodes, communication systems) are linked to a certain Time Base. A Time Domain can contain no or more than one Time Sub-domains. If the timing hierarchy of a Time Domain contains no Time Gateways, i.e. all nodes are connected to the same bus system, then there is no dedicated Time Sub-domain which otherwise would be equal to the Time Domain itself.
###2.2.10 Time Gateway
Definition: A Time Gateway is a set of entities where one entity is acting as Time Slave for a certain Time Base. The other (one or more) entities are acting as Time Masters which are distributing this Time Base to sets of Time Slaves. A Timesync ECU can contain multiple Time Gateways. A Time Gateway can be connected to different types of bus systems (e.g. the slave side could be connected to a FlexRay bus whereas the master side could be connected to a CAN bus system).
###2.2.11 Time Hierarchy
Definition: The Time Hierarchy describes how a certain Time Base is distributed, starting at the Global Time Master and being distributed across various Time Gateways (if present) to various Time Slaves.
###2.2.12 Time Master
Definition: A Time Master is an entity which is the master for a certain Time Base and which propagates this Time Base to a set of Time Slaves within a certain segment of a communication network, being a source for this Time Base.
If a Time Master is also the owner of the Time Base then he is the Global Time Master. A Time Gateway typically consists of one Time Slave and one or more Time Masters. When mapping time entities to real ECUs it has to be noted, that an ECU could be Time Master (or even Global Time Master) for one Time Base and Time Slave for another Time Base.
Special Case “Pure Local Time Master“:
A Pure Local Time Master is an entity which is the master of a Pure Local Time Base and which does therefore not propagate this time base to any Time Slave.
###2.2.13 Time Slave
Definition: A Time Slave is an entity which is the recipient for a certain Time Base within a certain segment of a communication network, being a consumer for this Time Base.

###2.2.14 Time Sub-domain
Definition: A Time Sub-domain denotes which components (e.g. nodes) are linked
to a certain Time Base whereas the scope is limited to one communication bus.
###2.2.15 Timesync ECU
Definition: A Timesync ECU is an ECU which is part of a Time Domain by
containing one or more Time Slaves or Time Masters.
###2.2.16 Timesync Module
Definition: Timesync Modules (<Bus>TSyn modules) are bus specific modules to receive or transmit time information on bus systems by applying bus specific mechanisms. A Timesync module can serve multiple communication buses of the same type.
###2.2.17 Virtual Local Time
Definition: The Virtual Local Time is a time which is driven by the OS counter or a hardware clock and which in turn drives a Synchronized Time Base. The associated Synchronized Time Base has an offset to the Virtual Local Time. For Time Slaves there is usually also a deviation in rate caused by different clock drifts of the HW reference clocks used by Time Master and Time Slave.
The term Virtual Local Time describes a Time Base whose time progresses monotonously without jumps.
Virtual Local Time Bases are necessary for interpolating
 local instances of Synchronized Time Bases (in either Master or Slave)
 Pure Local Time Bases
 and Offset Time Bases (in case of rate correction)
In addition, Virtual Local Time Bases can be used to measure timespans, i.e., for rate correction measurement intervals or timeouts.
Virtual Local Time Bases are based on a hardware clock and can be derived from various sources:
 OS counter
 GPT counter
 Ethernet freerunning counter (used for ingress and egress timestamping)
It is possible to use different Virtual Local Time Bases in parallel.
Although the different counter sources vary regarding tick duration and counter width, each derived Virtual Local Time Base has the same width (64 bit) and tick duration (1 ns).
To achieve this, it is necessary to count overflows of the counters and to convert counter specific tick durations if required.
###2.2.18 Time Correction
Definition: Time Correction in Time Slaves is the process of adjusting the value of the local instance of the Time Base to the value of the Global Time Base.
In Time Masters, Time Correction is the process of eliminating the deviation of an Offset Clock compared to its corresponding Synchronized Time Base.
Time Correction can be divided into Rate Correction, which corrects rate deviations and Offset Correction, which corrects absolute time deviations. Offset Correction can be furthermore divided into (Offset Correction By) Jump Correction or (Offset Correction By) Rate Adaption.

### 2.2.18a Rate Correction

Definition: Rate Correction corrects the rate-deviation of a local hardware reference clock. This correction is done by a multiplicative correction factor which is used in addition to the clock‘s preconfigured rate. Rate Correction determines the correction factor in the scope of a measurement. This correction factor is however not fixed but updated after each successful measurement.

###2.2.19 Offset Correction
Specification of Synchronized Time-Base Manager AUTOSAR CP R19-11
Definition: Offset Correction corrects absolute time deviations (offsets). Depending on the magnitude of the offset and the configuration of StbM, this correction is either performed by Jump Correction or Rate Adaption.
Offset Correction is independent from Rate Correction. It is performed each time the local instance of the Time Base is synchronized to its Global Time Base.
###2.2.20 Jump Correction
Definition: Jump Correction corrects absolute time offsets in a single step by adding the offset to the local instance of the Time Base (which is equivalent to taking over the value of the Global Time Base).
###2.2.21 Rate Adaption
Definition: Rate Adaption corrects time offsets gradually within a predefined timespan. Hereto, Rate Adaption switches the rate of the local instance of the Time Base temporarily to a different value. This rate is chosen to completely eliminate the offset within the preconfigured timespan.

## 3 Related documentation 
### 3.1 Inputdocuments
[1] Requirements on Time Synchronization AUTOSAR_RS_TimeSync.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[4] Specification of Operating System AUTOSAR_SWS_OS.pdf
[5] Specification of FlexRay Interface AUTOSAR_SWS_FlexRayInterface.pdf
[6] Specification of CAN Interface AUTOSAR_SWS_CANInterface.pdf
[7] Virtual Functional Bus AUTOSAR_EXP_VFB.pdf
[8] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[9] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[10] Specification of TimingExtensions AUTOSAR_TPS_TimingExtensions.pdf
[13] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[14] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[15] Specification of RTE AUTOSAR_SWS_RTE.pdf
[16] Complex Driver design and integration guidelineSpecification of Synchronized Time-Base Manager
AUTOSAR_EXP_CDDDesignAndIntegrationGuideline.pdf
[17] System Template
AUTOSAR_TPS_SystemTemplate
[19] Guide to BSW Distribution
AUTOSAR_EXP_BSWDistributionGuide.pdf
### 3.2 Relatedstandardsandnorms
[18] IEEE Standard 802.1ASTM- 30 of March 2011
http://standards.ieee.org/getieee802/download/802.1AS-2011.pdf


# 189 Specification of State Management
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_SWS_StateManagement.pdf

## 2 Acronyms and Abbreviations
TheglossarybelowincludesacronymsandabbreviationsrelevanttotheState Man- agement module that are not included in the AUTOSAR glossary[2].

|Terms|Description|
|:--|:--|
|State Management|The element defining modes of operation for AUTOSAR Adap- tive Platform. It allows flexible definition of functions which are active on the platform at any given time.|
|Execution Management [3]|A Functional Cluster within the Adaptive Platform Foundation|
|Platform Health Management [4]|A Functional Cluster within the Adaptive Platform Foundation|
|Communication Management[1]|A Functional Cluster within the Adaptive Platform Foundation|
|Network Management [5]|A Functional Cluster within the Adaptive Platform Services.  Part of Communication Management.|
|Adaptive Diagnostics [6]|A Functional Cluster within the Adaptive Platform Services.|
|Update And Config Management [7]|  A Functional Cluster within the Adaptive Platform Services.|
|Network Handle|   Network Handles are provided by Network Management. A handle represents a set of (partial) networks.|
|Process|A process is a loaded instance of an Executable to be executed on a Machine.|
|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.|
|Function Group State|The element of State Management that characterizes the cur- rent status of a set of (functionally coherent) user-level Appli- cations. The set of Function Groups and their Function Group States is machine specific and are configured in the Machine Manifest [8].|
|Machine State|The state of Function Group "MachineState" with some predefined states (Startup/Shutdown/Restart).|
|Execution Manifest|Manifest file to configure execution of an Adaptive Application.|
|Machine Manifest|Manifest file to configure a Machine.|
|Adaptive Application|see [2] AUTOSAR Glossary|
|Application|see [2] AUTOSAR Glossary|
|AUTOSAR Adaptive Platform|see [2] AUTOSAR Glossary|
|Adaptive Platform Foundation|see [2] AUTOSAR Glossary|
|Adaptive Platform Services|see [2] AUTOSAR Glossary|
|Manifest|see [2] AUTOSAR Glossary|
|Functional Cluster|see [2] AUTOSAR Glossary|
|Machine|see [2] AUTOSAR Glossary|
|Service|see [2] AUTOSAR Glossary|
|Service Interface|see [2] AUTOSAR Glossary|
|Service Discovery|see [2] AUTOSAR Glossary|

##3 Related documentation
### 3.1 Input documents & related standards and norms
The main documents that serve as input for the specification of the State Manage- ment are:
[1] Specification of Communication Management AUTOSAR_SWS_CommunicationManagement
[2] Glossary AUTOSAR_TR_Glossary
[3] Specification of Execution Management AUTOSAR_SWS_ExecutionManagement
[4] Specification of Platform Health Management for Adaptive Platform AUTOSAR_SWS_PlatformHealthManagement
[5] Specification for Network Management AUTOSAR_SWS_NetworkManagement
[6] Specification of Diagnostics AUTOSAR_SWS_Diagnostics
[7] Specification of Update and Configuration Management AUTOSAR_SWS_UpdateAndConfigManagement
[8] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[9] General Specification of Adaptive Platform AUTOSAR_SWS_General
[10] Requirements of State Management AUTOSAR_RS_StateManagement

# 188 Specification of Standard Types
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_StandardTypes.pdf
##2 Acronyms and abbreviations

|Acronym|Description|
|:--|:--|
|API |Application Programming Interface|
|OSEK/VDX|Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug|
|STD|Standard|
    
##3 Related documentation 
###3.1 Inputdocuments
[1] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[2] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[3]Specification of RTE Software AUTOSAR_SWS_RTE.pdf
[4]Basic Software Module Description Template,  [5]AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[6] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

###3.2  Relatedstandardsandnorms
[7] OSEK/VDX Operating System, ISO 17356-3: OS 
[8] ISO/IEC 9899:1990 Programming Language – C

# 187 Specification of SPI Handler / Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SPIHandlerDriver.pdf

## 2 Acronyms and abbreviations
Acronyms and abbreviations which have a local scope and therefore are not con- tained in the AUTOSAR glossary must appear in a local glossary.

|Acronym|Description|
|:--|:--|
|DET |Default Error Tracer – module to which errors are reported.|
|DEM|Diagnostic Event Manager – module to which production relevant errors are report- ed.|
|SPI |Serial Peripheral Interface. It is exactly defined hereafter in this document.|
|CS |Chip Select|
|MISO |Master Input Slave Output|
|MOSI|Master Output Slave Input|
|EB |Externally buffered channels. Buffers containing data to transfer are outside the SPI Handler/Driver.|
|IB |Internally buffered channels. Buffers containing data to transfer are inside the SPI Handler/Driver.|
|ID|Identification Number of an element (Channel, Job, Sequence).|

|Term|Description|
|:--|:--|
|Channel| A Channel is a software exchange medium for data that are defined with the same criteria: Config. Parameters, Number of Data elements with same size and data pointers (Source & Destination) or location.|
|Job |A Job is composed of one or several Channels with the same Chip Select (is not released during the processing of Job). A Job is considered atomic and therefore cannot be interrupted by another Job. A Job has an assigned priority.|
|Sequence|A Sequence is a number of consecutive Jobs to transmit but it can be rescheduled between Jobs using a priority mechanism. A Sequence transmission is interruptible (by another Sequence transmission) or not depending on a static configuration.|
            
##3 Related documentation 
###3.1 Inputdocuments
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] Requirements on SPI Handler/Driver AUTOSAR_SRS_SPIHandlerDriver.pdf
[7] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[8] Glossary AUTOSAR_TR_Glossary.pdf
[9] Specification of MCU Driver AUTOSAR_SWS_MCUDriver .pdf
[10] Specification of PORT Driver AUTOSAR_SWS_PORTDriver
[11] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[13] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[14] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
      
# 186 Specification on SOME/IP Transport Protocol
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SOMEIPTransportProtocol.pdf
##2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|SOME/IP| Scalable service-Oriented MiddlewarE over IP|

##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 Requirements on SOME/IP Protocol AUTOSAR_RS_SOMEIPProtocol.pdf
[5] AUTOSAR SOME/IP Protocol Specification AUTOSAR_PRS_SOMEIPProtocol.pdf
[6] AUTOSAR PDU Router AUTOSAR_SWS_PDURouter.pdf
### 3.2 Relatedstandardsandnorms
[7] IEC 7498-1 The Basic Model, IEC Norm, 1994

ERROR IEC 7498-1 -> 
 ISO/IEC 7498-1:1994 Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
https://www.iso.org/standard/20269.html

# 185 Specification of Socket Adaptor
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SocketAdaptor.pdf
## 2 Acronyms and abbreviations

*Move TCP/IP from abbreviation to term.

|Abbreviation / Acronym|Description|
|:--|:--|
|ARP |Address Resolution Protocol|
|DEM|Diagnostic Event Manager|
|DET |Default Error Tracer|
|DHCPv4 |Dynamic Host Configuration Protocol|
|DHCPv6 |Dynamic Host Configuration Protocol for Internet Protocol Version 6 |
|DoIP |Diagnostics over IP|
|HTTP |HyperText Transfer Protocol|
|IANA |Internet Assigned Numbers Authority|
|ICMPv4 |Internet Control Message Protocol|
|ICMPv6 |Internet Control Message Protocol for Internet Protocol Version 6|
|IETF|Internet Engineering Task Force|
|IP|Internet Protocol|
|IPv4 |Internet Protocol version 4|
|IPv6 |Internet Protocol version 6|
|NDP |Neighbor Discovery Protocol|
|Sd |Service Discovery|
|TCP |Transmission Control Protocol|
|TLS | Transport Layer Security|
|TP |Transport Protocol|
|UDP |User Datagram Protocol|
|UdpNm|AUTOSAR UDP Network Management|
                                            
|Term|Description:|
|:--|:--|
|TCP/IP |A family of communication protocols used in computer networks|
|AUTOSAR Connector|The SoAd serves as a (De)Multiplexer between different PDU sources/suppliers and the TCP/IP stack as well as between the TCP/IP stack and different PDU sinks/consumers. The term AUTOSAR connector refers to a source/supplier or sink/consumer of a PDU.|
|TCP socket connection|A socket connection which uses TCP as transport protocol (choice container SoAdSocketProtocol contains a SoAdSocketTcp subcontainer).|
|UDP socket connection|A socket connection which uses UDP as transport protocol (choice container SoAdSocketProtocol contains a SoAdSocketUdp subcontainer).|
|IF-PDU|An IF-PDU is a PDU which is sent/received via the IF-API of the SoAd|
|TP-PDU|An TP-PDU is a PDU which is send/received via the TP-API of the SoAd|
        
##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 ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf

[5]Specification of BSW Scheduler AUTOSAR_SWS_BSW_Scheduler.pdf

[6] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf

[7]Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[8]Specification of UDP Network Management AUTOSAR_SWS_UDPNetworkManagement.pdf
[9]  Requirements on Ethernet AUTOSAR_SRS_Ethernet.pdf
[10]List of Basic Software Modules AUTOSAR_TR_BSWModuleList Specification of Service Discovery AUTOSAR_SWS_ServiceDiscovery.pdf
[11]Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
 [12]Specification of TCP/IP Stack AUTOSAR_SWS_TCPIP.pdf
 [13] Specification of Module XCP AUTOSAR_SWS_XCP.pdf
[14]Specification of Diagnostics over IP AUTOSAR_SWS_DoIP.pdf
 [15]Specification of Socket Adaptor AUTOSAR CP R19-11
[16] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 Relatedstandardsandnorms
[1] IETF RFC 4702
http://tools.ietf.org/html/rfc4702
[2] IETF RFC 4704
http://tools.ietf.org/html/rfc4704

# 184 Specification of Service Discovery
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_ServiceDiscovery.pdf
## 2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|BswM|Basis software manager   |
|ECU|Electronic Control Unit |
|DEM|Diagnostic Event Manager|
|DET|Default Error Tracer|
|SD|Service Discovery|
|Sd|  Service Discovery Module in AUTOSAR|
|SoAd | Socket Adaptor|
SOME/IP |Scalable service-Oriented MiddlwarE over IP|
SOME/IP-SD|SOME/IP Service Discovery|
    
##3 Related documentation 
###3.1 Inputdocuments
[1] AUTOSAR Layered Software Architecture: AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR Basis Software Mode Manager: AUTOSAR_SWS_BSWModeManager.pdf
[3] AUTOSAR Socket Adaptor: AUTOSAR_SWS_SocketAdaptor.pdf
[4] AUTOSAR SRS BSW General AUTOSAR_SRS_BSWGeneral.pdf
[5] AUTOSAR PRS SOME/IP Service Discovery Protocol AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf
[6] AUTOSAR RS SOME/IP Service Discovery Protocol AUTOSAR_RS_SOMEIPServiceDiscoveryProtocol.pdf
 
# 183 Specification of a Transport Layer for SAE J1939
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SAEJ1939TransportLayer.pdf

2 Glossary, Acronyms, and Abbreviations
The following table presents a glossary of J1939 specific terms. For all other terms, please check the AUTOSAR Glossary.
|Glossary Term|Explanation|
|:--|:--|
|Address Claiming|Address Claiming forms the network management of SAE J1939 defined in the standard document SAE J1939/81. Address claiming assigns a temporary 8-bit identifier to each ECU connected to one J1939 network. Within this network, the 8-bit identifier is unique. The 8- bit identifier is used as source and target address of parameter groups (messages) transferred via the J1939 network. The address claiming procedure is based on the exchange of AddressClaimed messages (PGN 00EE00).|
|J1939 Diagnostics|The SAE J1939 diagnostic layer is defined in the standard document SAE J1939/73. The J1939 diagnostics is functionally similar to the UDS diagnostics, and has recently been extended to support OBD for emission relevant values.|
|Parameter |A parameter is a signal of the SAE J1939 application layer. Parameters are uniquely identified by the SPN.|
|Parameter Group|A parameter group is a message of the SAE J1939 application layer. Each parameter group contains several parameters (signals), and is uniquely identified by the PGN.|
|Transport Protocol|The SAE J1939 transport protocol is used for the segmented transmission of messages with more than 8 bytes of data. The transport protocol is defined in the network layer standard document (SAE J1939/21).|

|Acronym / Abbreviation|Description|
|:--|:--|
|BAM |Broadcast Announce Message, broadcast variant of SAE J1939 transport protocol|
|CMDT |Connection Mode Data Transfer, peer-to-peer variant of SAE J1939 transport protocol|
|DA|Destination Address, part of the 29 bit identifier of SAE J1939 messages|
|DET |Default Error Tracer, supports development and runtime error reporting |
|DMx |Diagnostic messages of the SAE J1939 diagnostics layer|
|NAME|Unique 64 bit identifier of each ECU connected to an SAE J1939 network|
|PDUF|PDU Format, part of the 29 bit identifier of SAE J1939 messages which identifies the message and determines the layout of the 29 bit identifier 
|PDUS|PDU Specific, part of the 29 bit identifier of SAE J1939 messages which identifies broadcast messages which do not have a destination address |
|PG|Parameter Group, SAE J1939 term for a specific message layout, corresponds to an N-SDU of J1939Tp|
|PGN|Parameter Group Number, unique identifier of an SAE J1939 parameter group|
|SA SPN|Source Address, part of the 29 bit identifier of SAE J1939 messages Suspect Parameter Number, unique identifier of an SAE J1939 parameter|
|TP.CM |Connection Management message (PGN 00EC00) used by SAE J1939 transport protocol, corresponds to an N-PDU of J1939Tp|
|TP.CM_BAM |Broadcast Announce Message, variant of TP.CM that initiates a BAM transmission|
|TP.CM_CTS|Connection Mode Clear To Send, variant of TP.CM that is used for handshake during CMDT transmission|
|TP.CM_EndOfMsgAck |End Of Message Acknowledge, variant of TP.CM that acknowledges correct reception of a CMDT transmission|
|TP.CM_RTS|Connection Mode Request To Send, variant of TP.CM that initiates a CMDT transmission|
|TP.Conn_Abort |Connection Abort, variant of TP.CM that terminates a CMDT transmission|
|TP.DT|Data Transfer message (PGN 00EB00) used by SAE J1939 transport protocol, corresponds to an N-PDU of J1939Tp|
                                      

## 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 COM AUTOSAR_SWS_COM.pdf
[5] Requirements on CAN AUTOSAR_SRS_CAN.pdf
[6] Specification of CAN Interface AUTOSAR_SWS_CANInterface.pdf
[7] Requirements on a Transport Layer for SAE J1939 AUTOSAR_SRS_SAEJ1939TransportLayer.pdf
[8] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[9] Specification of BSW Scheduler AUTOSAR_SWS_Scheduler.pdf
[10] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[11] Basic Software Module Description Template AUTOSAR_SRS_BSWGeneral.pdf
[12] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[13] Specification of System Template AUTOSAR_TPS_SystemTemplate.pdf
[14] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[15] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

###3.2 RelatedStandardDocuments
[16] SAE J1939-21(2006-12), Data Link Layer
[17] SAE J1939-7x(2006-xx), Application Layer

# 182 Specification of a Request Manager for SAE J1939
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SAEJ1939RequestManager.pdf

## 2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|AC|J1939 AddressClaimed PG (PGN = 0x0EE00)|
|ACK| J1939 Acknowledgement PG (ACKM) with control byte set to 0|
|ACKM| J1939 Acknowledgement PG (PGN = 0x0E800)|
|BSW| Basic Software (module)|
|CA |Controller Application, role of an ECU tied to one address|
|DET| Default Error Tracer, supports development and runtime error reporting DP Data Page, the most significant bit (MSB) of the 18 bit PGN|
|EDP| Extended Data Page, the second bit (after MSB) of the 18 bit PGN NACK J1939 Acknowledgement PG (ACKM) with control byte set to 1|
|PDUF| PDU Format, the middle byte of the 18 bit PGN|
|PDUS| PDU Specific, the lower byte of the 18 bit PGN|
|PG| Parameter Group|
|PGN| Parameter Group Number (18 bits, contains EDP, DP, PDUF, PDUS) RQST J1939 Request PG (PGN = 0x0EA00)|
|RQST2| J1939 Request2 PG (PGN = 0x0C900)|
|RTE| AUTOSAR Runtime Environment|
|SW-C| AUTOSAR Software Component (of the Application)|
|XFER| J1939 Transfer PG (PGN = 0x0CA00)|

                                    
## 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 Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[5] Requirements on BSW Modules for SAE J1939 AUTOSAR_SRS_J1939.pdf
[6] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[7] System Template AUTOSAR_TPS_SystemTemplate.pdf
[8] Specification of CAN Interface AUTOSAR_SWS_CANInterface.pdf
[9] Specification of a Transport Layer for SAE J1939 AUTOSAR_SWS_SAEJ1939TransportLayer.pdf
[10] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[11] Specification of Communication AUTOSAR_SWS_COM.pdf
[12] Specification of Network Management for SAE J1939 AUTOSAR_SWS_SAEJ1939NetworkManagement.pdf
[13] Specification of a Diagnostic Communication Manager for SAE J1939 AUTOSAR_SWS_SAEJ1939DiagnosticCommunicationManager.pdf
[14] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[15] Specification of BSW Scheduler AUTOSAR_SWS_BSWScheduler.pdf
[16] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[17] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
### 3.2 Relatedstandardsandnorms
[18] J1939-21 MAR2016, Data Link Layer

# 181 Specification of Network Management for SAE J1939
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SAEJ1939NetworkManagement.pdf
## 2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|AC|J1939 AddressClaimed PG (PGN = 0x0EE00)|
|BSW| Basic Software (module)|
|DET| Default Error Tracer, supports development and runtime error reporting Node J1939 node – can be attached to more than one channel NodeChannel The connection of a node to one channel|
|PG| Parameter Group|
|PGN| Parameter Group Number|
|RQST| J1939 Request PG (PGN = 0x0EA00)|
                
## 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 Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[5] Requirements on BSW Modules for SAE J1939 AUTOSAR_SRS_J1939.pdf
[6] Requirements on Network Management AUTOSAR_SRS_J1939.pdf
[7] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[8] System Template AUTOSAR_TPS_SystemTemplate.pdf
[9] Specification of CAN Interface AUTOSAR_SWS_CANInterface.pdf
[10] Specification of Network Management Interface AUTOSAR_SWS_NetworkManagementInterface.pdf
[11] Specification of Basic Software Mode Manager AUTOSAR_SWS_BSWModeManager.pdf
[12] Specification of a Request Manager for SAE J1939 AUTOSAR_SWS_SAEJ1939RequestManager.pdf
[13] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[14] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[15] Specification of BSW Scheduler AUTOSAR_SWS_BSWScheduler.pdf
[16] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[17] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
### 3.2 Relatedstandardsandnorms
[18] J1939-81 JUN2011, Network Management

# 180 Specification of a Diagnostic Communication Manager for SAE J1939
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SAEJ1939DiagnosticCommunicationManager.pdf

## 2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|ACKM |Acknowledgement Message, J1939 PGN 0E80016 |
|DEM |Diagnostic Event Manager|
|DET |Default Error Tracer|
|DM |Diagnostic messages|
|PGN |Parameter Group Number|
|SAE |Society of Automotive Engineers (in charge of J1939 specification) |
|SPN|Suspect Parameter Number|              
## 3 Related documentation 



### 3.1 Inputdocuments
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
Specification of a Diagnostic Communication Manager for SAE J1939 AUTOSAR CP R19-11
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[5] Requirements on Diagnostics AUTOSAR_RS_Diagnostics.pdf
[6] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[7] System Template AUTOSAR_TPS_SystemTemplate.pdf
[8] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[9] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[10] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[11] Specification of a Request Manager for SAE J1939 AUTOSAR_SWS_SAEJ1939RequestManager.pdf
[12] Specification of Network Management for SAE J1939 AUTOSAR_SWS_SAEJ1939NetworkManagement.pdf
[13] Specification of BSW Scheduler AUTOSAR_SWS_BSWScheduler.pdf
[14] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[15] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[16] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 Relatedstandardsandnorms
[17] J1939-73 FEB2010, Application Layer – Diagnostics

# 179  Specification of RTE Software

https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_RTE.pdf

No abbreviation without the list.

## References
[1] Virtual Functional Bus AUTOSAR_EXP_VFB
[2] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[3] Specification of Communication AUTOSAR_SWS_COM
[4] Specification of Operating System AUTOSAR_SWS_OS
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration
[6] Methodology AUTOSAR_TR_Methodology
[7] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager
[8] System Template AUTOSAR_TPS_SystemTemplate
[9] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[10] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[11] Glossary AUTOSAR_TR_Glossary
[12] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[13] Requirements on Runtime Environment AUTOSAR_SRS_RTE
[14] Specification of Timing Extensions AUTOSAR_TPS_TimingExtensions
[15] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
[16] Specification of ECU Resource Template AUTOSAR_TPS_ECUResourceTemplate
[17] Specification of I/O Hardware Abstraction AUTOSAR_SWS_IOHardwareAbstraction
25 of 1313 Document ID 84: AUTOSAR_SWS_RTE — AUTOSAR CONFIDENTIAL —
[18] Requirements on Operating System AUTOSAR_SRS_OS
[19] Requirements on Communication AUTOSAR_SRS_COM
[20] ASAM MCD 2MC ASAP2 Interface Specification http://www.asam.net
ASAP2-V1.51.pdf
[21] Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager
[22] Collection of blueprints for AUTOSAR M1 models AUTOSAR_MOD_GeneralBlueprints
[23] Specification of COM Based Transformer AUTOSAR_SWS_COMBasedTransformer
[24] Guide to BSW Distribution AUTOSAR_EXP_BSWDistributionGuide
[25] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer
[26] General Specification on Transformers AUTOSAR_ASWS_TransformerGeneral
[27] Guidelines for the use of the C language in critical systems, ISBN 978-1-906400- 10-1
MISRA_C_2012.pdf
[28] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping
[29] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[30] Specification of Compiler Abstraction AUTOSAR_SWS_CompilerAbstraction
[31] Specification of Standard Types AUTOSAR_SWS_StandardTypes
[32] Specification of Bit Handling Routines AUTOSAR_SWS_BFXLibrary
[33] Collection of constraints on AUTOSAR M1 models AUTOSAR_TR_AutosarModelConstraints

###1.4 Technical Terms
All technical terms used throughout this document – except the ones listed here – can be found in the official AUTOSAR glossary [11] or the Software Component Template Specification [2].

|Term|Description|
|:--|:--|
|application mode manager|An application mode manager is an AUTOSAR software- component that provides the service of switching modes. The modes of an application mode manager do not have to be standardized.|
|associated RTE Implementation Plug-In|The RTE Implementation Plug-In which is assigned to a communication graph, ExclusiveArea, mode machine instanceordistributed shared mode groupandthere- fore handles all accesses via RTE APIs, SchM APIs or RTE in- ternal code.|
|AutosarDataPrototype implementation|Definitions and declarations for non automatic1 memory objects which are allocated by the RTE and implementing AutosarDat- aPrototypes or their belonging status handling.|
|BswSchedulableEntity activation|The activation of a BswSchedulableEntity is defined as the activation of the task/ISR2 that contains the BswSchedula- bleEntity and eventually includes setting a flag that tells the glue code in the task/ISR2 which BswSchedulableEntity is to be executed.| client|
|BswSchedulableEntity start|A BswSchedulableEntity is started by the calling the C- function that implements the BswSchedulableEntity from within a started task/ISR2.|
|’C’ typed PerInstanceMemory|’C’ typed PerInstanceMemory is defined with the class PerIn- stanceMemory. The type of the memory is defined with a ’C’ typedef in the attribute typeDefinition.|
|client|A client is defined as one ClientServerOperation in one RPortPrototype of one Software Component instance. For the definition of the client neither the number of ServerCallPoints nor RunnableEntity accesses to the ServerCallPoint are relevant. A Software Component instance can appear as sev- eral clients to the same server if it defines ServerCallPoints for several PortPrototypes of the same PortInterface’s ClientServerOperation.|
|CodeGenerationTime variability|Variability defined with an VariationPoint or Attribute- ValueVariationPoint with latest bindingTime CodeGenera- tionTime.|
| coherency group|A set of implicit read accesses and implicit write accesses for which the RTE cares for data coherency. Please note that in the context of this specification the definition of co- herency includes that • readdatavaluesofdifferentVariableDataPrototypes have to be from the same age, except the values are changed by implicit write accesses belonging to the coherency group • written data values of different VariableDataProto- types are communicated to readers NOT belonging to the coherency group after the last implicit write access belonging to the coherency group.
|coherent implicit data access|An implicit read access or an implicit write ac- cess which belongs to coherency group. Therefore it is referenced by a RteVariableReadAccessRef or RteVari- ableWriteAccessRef belonging to a RteImplicitCommu- nication container which RteCoherentAccess parameter is set to true.|
|coherent implicit read access|An implicit read access which belongs to coherency group. Therefore it is referenced by a RteVariableReadAc- cessRef belonging to a RteImplicitCommunication con- tainer which RteCoherentAccess parameter is set to true.|
|coherent implicit write access|An implicit write access which belongs to coherency group. Therefore it is referenced by a RteVariableReadAc- cessRef or RteVariableWriteAccessRef belonging to a RteImplicitCommunication container which RteCo- herentAccess parameter is set to true.|
|common mode machine in- stance|A ‘common mode machine instance’ is a special ‘mode machine instance’ shared by BSW Modules and SW-Cs:|
|The RTE Generator creates only one mode machine in- stance if a ModeDeclarationGroupPrototype instantiated in a port of a software-component is synchronized (synchronized- ModeGroup of a SwcBswMapping) with a providedModeGroup ModeDeclarationGroupPrototype of a Basic Software Module in- stance. The related mode machine instance is called com- mon mode machine instance.|
|Communication Graph|The sum of all AbstractAccessPoints to elements of Port- Interfaces instantiated in PortPrototypes which are con- nected to each other, or the sum of all accesses from BswMod- uleEntitys to interface elements in a BswModuleDescrip- tions connected to each other.|
|Data Communication Graph|The sum of all VariableAccesses to DataPrototypes in- stantiated in PortPrototypes which are connected to each other, or the sum of all VariableAccesses to DataProto- types in the InternalBehavior, or the sum of all BswVari- ableAccesses to DataPrototypes in BswModuleDescrip- tions connected to each other.|
|Client Server Communication Graph|The sum of all ServerCallPoints to operations instantiated in PortPrototypes which are connected to each other inclu- sive the belonging server runnable.|
|Trigger Communication Graph|The sum of all ExternalTriggeringPoints for triggers instantiated in PortPrototypes which are connected to each other inclusive the belonging triggered runnable.|
|copy semantic|Copy semantic means, that the accessing entities are able to read or write the "copied" data from their execution context in a non concurrent and non preempting manner. If all accessing en- tities are in the same preemption area this might not require a real physical data copy.|
|core local mode user group|In the case that mode users belong to different partitions which in turn are scheduled on different micro controller cores the over- all mode machine instance needs to be distributed cross core. Thereby some restrictions are only applicable between the mode users executed on the same micro controller core.|
|All mode users of the same mode manager which belong to EcucPartition which in turn belong to OsApplications re- ferring to the same EcucCoreDefinition are belonging to the same core local mode user group.|
|data semantic|When data is distributed, the last received value is of interest (last-is-best semantics). Therefore the software implementation policy, stated in the swImplPolicy attribute of the SwDataDef- Props, shouldn’t be ’queued’.|
|event semantic|When events are distributed the whole history of received events is of interest, hence they must be queued on receiver side. There- fore the software implementation policy, stated in the swIm- plPolicy attribute of the SwDataDefProps, will have the value ’queued’(corresponding to event distribution with a queue).|
|execution-instance|An execution-instance of an ExecutableEntity is one in- stance or call context of an ExecutableEntity with respect to concurrent execution, see section 4.2.3.|
|implicit read access|VariableAccess aggregated in the role dataReadAccess to a VariableDataPrototype|
|implicit write access|VariableAccess aggregated in the role dataWriteAccess to a VariableDataPrototype|
|incoherent implicit data access|An implicit read access or an implicit write ac- cesswhichdoesnotbelongtoacoherency group.Therefore it is NOT referenced by any RteVariableReadAccessRef or RteVariableWriteAccessRef belonging to a RteImplic- itCommunication container which RteCoherentAccess pa- rameter is set to true.|
|incoherent implicit read access|An implicit read access which does not belong to a co- herency group. Therefore it is NOT referenced by any Rte- VariableReadAccessRef belonging to a RteImplicitCom- munication container which RteCoherentAccess parameter is set to true.|
|incoherent implicit write access|An implicit write access which does not belong to a coherency group. Therefore it is NOT referenced by any RteVariableWriteAccessRef belonging to a RteImplic- itCommunication container which RteCoherentAccess pa- rameter is set to true.|
|inter-ECU communication|The communication between ECUs, typically using COM is called inter-ECU communication in this document.|
|intra-partition communication|The communication within one ECU is called intra-ECU com- munication in this document. It is a super set of inter-parti- tion communication and intra-partition communication.|
|intra-ECU communication|The communication within one partition of one ECU is called intra-partition communication. In this case, RTE can make use of internal buffers and queues for communication.|
|inter-partition communication|The communication within one ECU but between different par- titions, represented by different OS applications, is called in- ter-partition communication in this document. It may in- volve the use of OS mechanisms like IOC or trusted function calls. The partitions can be located on different cores or use different memory sections of the ECU.|
|invalidateable|Invalidateable VariableDataPrototypes are Variable- DataPrototypes that have an invalidValue.|
|LinkTime variability|Variability defined with an VariationPoint or AttributeValue- VariationPoint with latest bindingTime LinkTime.|
|mode disabling|When a ‘mode disabling’ is active, RTE and Basic Software Schedulerdisablestheactivationofmode disabling depen- dent ExecutableEntitys. The ‘mode disabling’ is active during the mode that is referenced in the mode disabling depen- dency and during the transitions that enter and leave this mode. See also section 4.4.1.|
|mode disabling dependency|A RTEEvent (respectively a BswEvent) that starts a RunnableEntity (respectively a BswSchedulableEntity) can contain a disabledMode (respectively disabledInMode) as- sociation which references a ModeDeclaration. This association is called mode disabling dependency in this document.|
|mode disabling dependent ExecutableEntity|A mode disabling dependent RunnableEntity or a BswSchedulableEntity is triggered by an RTEEvent re- spectivelyaBswEventwithamode disabling dependency. RTE and Basic Software Scheduler prevent the activation of those RunnableEntity or BswSchedulableEntity by the RTEEvent / BswEvent, when the corresponding mode dis- abling is active. See also section 4.4.1.|
|mode machine instance|The instances of mode machines or ModeDeclarationGroups are defined by the ModeDeclarationGroupPrototypes of the mode managers.|
|Since a mode switch is not executed instantaneously, The RTE or Basic Software Scheduler has to maintain it’s own states. For each mode manager’s ModeDeclarationGroupPrototype, RTE or Basic Software Scheduler has one state machine. This state machine is called mode machine instance. For all mode users ofthesamemode manager’sModeDeclarationGroupPrototype, RTE and Basic Software Scheduler uses the same mode ma- chine instance. See also section 4.4.2.|
|mode manager|Entering and leaving modes is initiated by a mode manager. A mode manager is either a software component that provides a p-port typed by a ModeSwitchInterface or a BSW module which defines in its BswModuleDescription a ModeDeclara- tionGroupPrototype in the role providedModeGroup. See also section 4.4.2.|
|ModeSwitchAck ExecutableEntity|A RunnableEntity or a BswSchedulableEntity that is trig- gered by a ModeSwitchedAckEvent respectively a BswMod- eSwitchedAckEventconnectedtothemode manager’sMod- eDeclarationGroupPrototype. It is called ModeSwitchAck ExecutableEntity. See also section 4.4.1.|
|mode switch notification|The communication of a mode switch from the mode manager to the mode user using either the ModeSwitchInterface or providedModeGroup and requiredModeGroup ModeDeclara- tionGroupPrototypes is called mode switch notification.|
|mode switch port|The port for receiving (or sending) a mode switch notification. For this purpose, a mode switch port is typed by a ModeSwitchIn- terface.|
|mode user|An AUTOSAR SW-C or AUTOSAR Basic Software Module that depends on modes is called a mode user. The depen- dency can occur through a SwcModeSwitchEvent/BswMod- eSwitchEvent, a ModeAccessPoint for a provided/required mode switch port, or a accessedModeGroup for a providedModeGroup/requiredModeGroup ModeDeclara- tionGroupPrototype. See also section 4.4.1.|
|NvBlockSwComponent|NvBlockSwComponent is a SwComponentPrototype typed an NvBlockSwComponentType.|
|on-entry ExecutableEntity|A RunnableEntity or a BswSchedulableEntity that is trig- gered by a SwcModeSwitchEvent respectively a BswMod- eSwitchEvent with ModeActivationKind ‘entry’ is triggered on entering the mode. It is called on-entry ExecutableEntity. See also section 4.4.1.|
|on-exit ExecutableEntity|A RunnableEntity or a BswSchedulableEntity that is trig- gered by a SwcModeSwitchEvent respectively a BswMod- eSwitchEvent with ModeActivationKind ‘exit’ is triggered on exiting the mode. It is called on-exit ExecutableEntity. See also section 4.4.1.|
|on-transition ExecutableEntity|A RunnableEntity or a BswSchedulableEntity that is trig- gered by a SwcModeSwitchEvent respectively a BswMod- eSwitchEvent with ModeActivationKind ‘transition’ is triggered on a transition between the two specified modes. It is called on- transition ExecutableEntity. See also section 4.4.1.|
|post-build variability|Variability defined with an VariationPoint having an post- BuildVariantCriterion|
|pre-build variability|Variability defined with an VariationPoint or AttributeValue- VariationPoint with latest bindingTime SystemDesignTime, CodeGenerationTime, PreCompileTime or LinkTime.|
|PreCompileTime variability|Variability defined with an VariationPoint or AttributeValue- VariationPoint with latest bindingTime PreCompileTime.|
|preemption area|A preemption area defines a set of tasks which are scheduled cooperatively. Therefore tasks of one preemption area are pre- empting each other only at dedicated schedule points. A sched- ule point is not allowed to occur during the execution of a RunnableEntity.|
|primitive data type|Primitive data types are the types implemented by a boolean, integer (up to 32 bits), floating point, or opaque type (up to 32 bits).|
|RIPS FlatInstanceDescriptor hline RP enabler flag|FlatInstanceDescriptor with rtePluginProps referenc- ing a Communication Graph.A Boolean flag to permit run-time enabling/disabling bypass.|
|RP event id|Identifier for bypassed event; passed as parameter to RP ser- vice function.|
|RP global buffer|A buffer read/written by RP. The RP global buffer is con- ceptually separated from the RTE managed buffer holding the variable data prototype value.|
|RP global measurement buffer|A buffer used by RP to store the original variable data prototype value for subsequent measurement purposes before replace- ment by the RP generated value.|
|RP runnable disabler flag|A Boolean flag to permit conditional RunnableEntity execu- tion. When conditional execution is configured the runnable is executed if the flag is FALSE.|
|RP service component|An AUTOSAR or vendor specific BSW module providing an RP service, e.g. “XCP on CAN” or “XCP on Ethernet”.|
|RP service profile|A definition of a service combining the symbol of the function providing the service and the permitted range of RP service point ids.|
|RP service function|An invocation of a function provided by a RP service compo- nent where data is sampled and/or stimulated.|
|RP service point|A location where one or more RP service functions pro- vided by a RP service component are invoked.|
|RP service point id|Integer identifier for RP service point.|
|RP service invocation wrapper|A “wrapper” function created by the RTE that is responsible for in- voking the RP RP service function(s). The indirection thus introduced enables a post-build tool to replace the invocation of the RTE generated function with arbitrary functionality.|
|RP stimulation enabler flag|A Boolean flag to permit conditional RP stimulation.|
|RTE event identifier|Integer identifier used by RP to identify RTE event associated with an RP service point.|
|RTE Implementation Plug-In|A RTE Implementation Plug-InisapartoftheoverallRTE implementation which is not provided by the RTE Generator but from an additional source (e.g. a Plug-In Generator or a manually implemented source code).|
|RTE Implementation Plug-In Service|A RTE Implementation Plug-In Serviceisasingleentry pointintotheRTE Implementation Plug-Inimplementinga low level service for the RTE. For instance access to a specific buffer.|
|RIPS|The acronym RIPS stands for RTE Implementation Plug-In Service and the related API infix Rips is de- rived from this.|
|RIPS FlatInstanceDescriptor|A FlatInstanceDescriptor which assigns the communica- tion graph with an RTE Implementation Plug-In|
|runnable activation|The activation of a runnable is linked to the RTEEvent that leads to the execution of the runnable. It is defined as the incident that is referred to by the RTEEvent. E.g., for a timing event, the corresponding runnable is activated, when the timer expires, and for a data received event, the runnable is activated when the data is received by the RTE.|
|runnable start|A runnable is started by the calling the C-function that imple- ments the runnable from within a started task/ISR2.|
|server|A server is defined as one RunnableEntity which is the target of an OperationInvokedEvent. Call serialization is on activa- tion of RunnableEntity.|
|server ExecutableEntity|A server that is triggered either by an OperationInvokedE- vent or by an BswOperationInvokedEvent. In certain situa- tions, RTE can implement the client server communication as a simple function call.|
|server runnable|A server that is triggered by an OperationInvokedEvent. It has a mixed behavior between a runnable and a function call. In certain situations, RTE can implement the client server commu- nication as a simple function call.|
|SystemDesignTime variability|Variability defined with an VariationPoint or AttributeValue- VariationPoint with latest bindingTime SystemDesignTime.|
|trigger emitter|A trigger emitter has the ability to release triggers which in turn are activating triggered ExecutableEntitys. trigger emit- ter are described by the meta model with provide trigger ports, Trigger in role releasedTrigger, InternalTrig- geringPoints and BswInternalTriggeringPoints.|
|trigger port|A PortPrototype which is typed by an TriggerInterface|
|trigger sink|A trigger sink relies on the activation of Runnable Entities or Ba- sic Software Schedulable Entities if a particular Trigger is raised. A trigger sink has a dedicated require trigger port(s) or / and requiredTrigger Trigger(s) to communicate to the trigger source(s).|
|trigger source|A trigger source administrate the particular Trigger and informs the RTE or Basic Software Scheduler if the Trigger is raised. A trigger source has dedicated provide trigger port(s) or / and releasedTrigger Trigger(s) to communicate to the trigger sink(s).|
|triggered BswSchedulableEntity|A BswSchedulableEntity that is triggered at least by one BswExternalTriggerOccurredEvent or BswInternal- TriggerOccurredEvent. In particular cases, the Trigger Event Communication or the Inter Basic Software Schedulable Entity Triggering is implemented by Basic Software Scheduler as a direct or trusted function call of the triggered ExecutableEntity by the triggering ExecutableEntity.|
|triggered ExecutableEntity|A Runnable Entity or a Basic Software Schedulable Entity that is triggered at least by one ExternalTriggerOccurredE- vent / BswExternalTriggerOccurredEvent or Internal- TriggerOccurredEvent / BswInternalTriggerOccurre- dEvent. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE or Basic Software Scheduler as a direct or trusted function call of the trig- gered ExecutableEntity by the triggering ExecutableEntity.|
|triggered runnable|A Runnable Entity that is triggered at least by one External- TriggerOccurredEvent or InternalTriggerOccurredE- vent. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE as a direct or trusted function call of the triggered runnable by the triggering runnable.|
|unconnected port|An unconnected port is a RPortPrototype or PPortProto- type referenced by no AssemblySwConnectors and/or Dele- gationSwConnectors, or with at least no DataMapping of any of the elements in the port interface. Hint: PRPortPrototypes are always treated as connected ports. (See [SWS_Rte_06030])|
|direct function call|A direct function call is a function call that is not performed via other means than pure RTE code. Typically, this is a C function call in an OsTask, OsIsr or RTE API (see 5.6).|
|trusted function call|A trusted function call is a function call that is performed via the CallTrustedFunction() API of the OS. This is usually nec- essary to achieve a direct function call like behavior when cross- ing partition boundaries.|

# 178 Specification of RAM Test
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_RAMTest.pdf

|TEST FUNCTION APIs|DEFINITION|
|:--|:--|
|RamTst_Init|Prepare resources for testing as necessary. Initialize the test execution state as necessary. Proceed to “test stopped” state after initialization is complete.|
|RamTst_DeInit |Reset all used registers to reset values, and release all used resources.|
|RamTst_Allow|Permit the RamTst_MainFunction() to perform testing at its next scheduled call.|
|RamTst_Stop|Prohibit the RamTst_MainFunction() from performing tests at its next scheduled call. When RamTst_Stop is called, testing stops after the current atomic sequence. Test status is retained, but test parameters (block number, loop count, etc.) are discarded.|
|RamTst_Suspend|Temporarily prohibit the RamTst_MainFunction() from performing tests at its next scheduled call. When RamTst_Suspend is called, testing stops after the current atomic sequence. Test status and test parameters are retained.|
|RamTst_Resume|Permits the RamTst_MainFunction() to continue testing at the point where it was suspended, at its next scheduled call. Testing continues according to the saved test parameters.|
|RamTst_RunFullTest Test the entire RAM space without interruption. RamTst_Stop must be called prior to calling this API.|
|RamTst_RunPartialTest|Test the portion of the RAM defined by the API. RamTst_Stop or RamTst_Suspend must be called prior to calling this API.|

## 2 Acronyms and Abbreviations
Specification of RAM Test AUTOSAR CP R19-11

|Abbreviation / Acronym|Description|
|:--|:--|
|API|Application Programming Interface|
|CRC| Cyclic Redundancy Check |
|DEM| Diagnostic Event Manager| 
|DET| Default Error Tracer|
|DMA| Direct Memory Access|
| ECC| Error Correction Code |
|NMI| Non Maskable Interrupt|
| RAM |Random Access Memory|

##3 Related Documentation
###3.1 InputDocuments
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleLis.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 RAM Test AUTOSAR_SRS_RAMTest.pdf
[6] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[7] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 RelatedStandardsandNorms
[8] D1.5-General Architecture; ITEA/EAST-EEA, Version 1.0; chapter 3, page 72 et seq.
[9] D2.1-Embedded Basic Software Structure Requirements; ITEA/EAST-EEA, Version 1.0 or higher.
[10] D2.2-Description of existing solutions; ITEA/EAST-EEA, Version 1.0 or higher.
[11] ISO 26262-5:2011: Road vehicles – Functional safety – Part 5: Product development at the hardware level.

# 177  Specification of Port Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_PortDriver.pdf

##2 Acronyms and abbreviations
The following table summarizes the expressions used within the PORT driver.

|Abbreviation|Description|            
|:--|:--|
|DEM|Diagnostic Event Manager|
|DET|Default Error Tracer|
|MCU|MicroController Unit|
|Port Pin|Represents a single configurable input or output pin on an MCU device. |
|Port|Represents a whole configurable port on an MCU device.|
|Physical Level (Input) |Two states are possible: LOW/HIGH 
Physical Level (Output)|Two states are possible: LOW/HIGH|

##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 Default Error Tracer, AUTOSAR_SWS_DefaultErrorTracer.pdf
[5] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[6] Specification of Diagnostic Event Manager, AUTOSAR_SWS_DiagnosticEventManager.pdf
[7] Specification of ECU State Manager, AUTOSAR_SWS_ECUStateManager.pdf
[8] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[9] Requirements on PORT driver, AUTOSAR_SRS_PORTDriver.pdf
 [10] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[11] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[13] EC 7498-1 The Basic Model, IEC Norm, 1994

Errotta EC 7498-1 -> ISO/IEC 7498-1:1994 Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
https://www.iso.org/standard/20269.html

# 176 Specification of Platform Types
## 2 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Abbreviation|Description|            
|:--|:--|        
|Rollover mechanism|The following example sequence is called ‘rollover’: An unsigned char has the value of 255. It is incremented by 1. The result is 0.|
|SDU|Service Data Unit (payload) |
|int|Integer|

##3 Related documentation 3.1 Inputdocuments
[1] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[2] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[3] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[4] Cosmic C Cross Compiler User’s Guide for Motorola MC68HC12, V4.5
[5] ARM ADS compiler manual
[6] Greenhills MULTI for V850 V4.0.5:
Building Applications for Embedded V800, V4.0, 30.1.2004
[7] 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
[8] 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
[9] TASKING for TriCore TC1796 V2.1R1:
TriCore v2.0 C Cross-Compiler, Assembler, Linker User's Guide, V1.2
[10] 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
[11] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[12] ISO/IEC 9899:1990 Programming Language – C

# 175 Specification of Platform Health Management for Adaptive Platform

##2 Acronyms and abbreviations
The glossary below includes acronyms and abbreviations relevant to the specification orimplementationofHealth Monitoringthatarenotincludedinthe[6,AUTOSAR glossary].
      
|Abbreviation|Description|
|:--|:--|
|CM|AUTOSAR Adaptive Communication Management|
|DM|AUTOSAR Adaptive Diagnostic Management|
|E2E|AUTOSAR End to End communication protection mechanism|
|PHM|Platform Health Management|
|SE|Supervised Entity|

|Abbreviation|Description|
|:--|:--|
|Alive Supervision|Mechanism to check the timing constraints of cyclic Supervised Entitys to be within the configured min and max limits.|
|Application Recovery Action|Callback for notifying applications of detected failures.|
|ara::com|Communication middleware for the AUTOSAR Adaptive Platform|
|AUTOSAR Adaptive Platform|see [6] AUTOSAR Glossary|
|Checkpoint|A point in the control flow of a Supervised Entity where the activity is reported.|
|Daisy chaining|Chaining multiple instances of Health Monitoring|
|Deadline Supervision|Mechanism to check that the timing constraints for execution of the transition from a Deadline Start Checkpoint to a cor- responding Deadline End Checkpoint are within the config- ured min and max limits.|
|Global Supervision Status|Status that summarizes the Local Supervision Status of all Supervised Entitys of a software subsystem.|
|Graph|A set of Checkpoints connected through Transitions, where at least one of Checkpoints is an Initial Checkpoint and there is a path (through Transitions) between any two Checkpoints of the Graph.|
|Health Channel|Channel providing information about the health status of a (sub)system. This might be the Global Supervision Sta- tus of an application, the result any test routine or the status reported by a (sub)system (e.g. voltage monitoring, OS kernel, ECU status, ...).|
|Health Monitoring|Supervision of the software behaviour for correct timing and sequence.|
|Health Status|A set of states that are relevant to the supervised software (e.g. the Global Supervision Status of an application, a Volt- age State, an application state, the result of a RAM monitoring algorithm).|
|Logical Supervision|Kind of online supervision of software that checks if the software ( Supervised EntityorsetofSupervisedEntities)isexecuted in the sequence defined by the programmer (by the developed code).|
|Local Supervision Status|Status that represents the current result of Alive Supervi- sion,Deadline SupervisionandLogical Supervision of a single Supervised Entity.|
|Platform Health Management|Health Monitoring for the Adaptive Platform|
|Supervised Entity|A software entity which is included in the supervision. A Super- vised Entity denotes a collection of Checkpoints within a soft- ware component. There may be zero, one or more Supervised EntitiesinaSoftwareComponent.ASupervised Entitymay be instantiated multiple times, in which case each instance is in- dependently supervised.|

##3 Related documentation
###3.1 Input documents & related standards and norms
[1] Explanation of Adaptive Platform Design AUTOSAR_EXP_PlatformDesign
[2] Requirements on Platform Health Management for Adaptive Platform AUTOSAR_RS_PlatformHealthManagement
[3] Requirements on Health Monitoring AUTOSAR_RS_HealthMonitoring
[4] Specification of Health Monitoring AUTOSAR_SWS_HealthMonitoring
[5] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org
[6] Glossary AUTOSAR_TR_Glossary
[7] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[8] Specification of Execution Management AUTOSAR_SWS_ExecutionManagement
[9] Specification of Core Types for Adaptive Platform AUTOSAR_SWS_CoreTypes
[10] Guidelines for using Adaptive Platform interfaces AUTOSAR_EXP_AdaptivePlatformInterfacesGuidelines
[11] Guidelines for the use of the C++14 language in critical and safety-related systems
AUTOSAR_RS_CPP14Guidelines

#174 Specification of Persistency
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_SWS_Persistency.pdf



##2 Acronyms and Abbreviations
The glossary below includes acronyms and abbreviations relevant to the Persis- tency that are not included in the [1, AUTOSAR glossary].
      
|Abbreviation / Acronym|Description|
|:--|:--|
|KVS|Key-Value Storage|

|Terms|Description|
|:--|:--|
|File Storage|A set of files that are stored persistently.|
|Key-Value Pair|A key with an associated value, to be stored in a Key-Value Storage together with the type of the value.|
|Key-Value Storage|A set of key-value pairs that are stored persistently.|
|Persistency|The functional cluster described in this document, which han- dles persistent data of AUTOSAR Adaptive Applica- tions and other functional clusters in File Storages and Key-Value Storages.|
|Persistent Data|Data that is stored in the persistent memory that can be accessed by one Process.Persistency supports different mechanisms to access data in persistent memory. Concurrent access to the data by several Processes is not supported as the data is owned exclusively by one Process.|

##3 Related documentation
###3.1 Input documents & related standards and norms
[1] Glossary AUTOSAR_TR_Glossary
[2] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[3] Requirements on Persistency AUTOSAR_RS_Persistency
[4] General Requirements specific to Adaptive Platform AUTOSAR_RS_General
[5] Requirements on Update and Configuration Management AUTOSAR_RS_UpdateAndConfigManagement
[6] Specification of Update and Configuration Management AUTOSAR_SWS_UpdateAndConfigManagement
[7] Specification of Platform Types for Adaptive Platform AUTOSAR_SWS_AdaptivePlatformTypes
[8] Specification of Core Types for Adaptive Platform AUTOSAR_SWS_CoreTypes

# 173 Specification of PWM Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_PWMDriver.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|
|:--|:--|
|PWM Channel |Numeric identifier linked to a hardware PWM.|
|PWM Output State|Defines the output state for a PWM signal. It could be: High. Low.|
|PWM Idle State|The idle state represents the output state of the PWM channel after the call of Pwm_SetOutputToIdle or Pwm_DeInit|
|PWM Polarity |Defines the starting output state of each PWM channel|
|PWM Duty cycle|Defines a percentage of the starting level (could be high or low) related to the period.|
|PWM period|Defines the period of the PWM signal.|
|PWM |Pulse Width Modulation. |
|DEM |Diagnostic Event Manager. |
|DET |Default Error Tracer. |
|MCU |Microcontroller Unit.|
|PLL |Phase Locked Loop. |
|ISR|Interrupt Service Routine.|            


##3 Related documentation 3.1 Inputdocuments
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[5] Specification of MCU Driver AUTOSAR_SWS_MCUDriver.pdf
[6] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[7] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[8] List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[9] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

#172 Specification of PDU Router
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_PDURouter.pdf

##2 Acronyms and abbreviations
The following acronyms and abbreviations have a local scope and are therefore not contained in the AUTOSAR glossary.

|Acronym|Description:|
|:--|:--|
|Upper Layer Modules (Up)|Modules above the PDU Router. This layer usually includes COM and Diagnostic Communication Manager (DCM). The upper layer modules are configured in the configuration.|
|Lower Layer Modules (Lo)|Modules below the PDU Router. This layer may include CAN, LIN, FlexRay, Ethernet communication interface modules and the respective TP modules. Modules used are configured in the configuration|
|PDU Router|Module that transfers I-PDUs from one module to another module. The PDU Router module can be utilized for gateway operations and for internal routing purposes.|
|gatewaying-on- the-fly|Gateway capability; routing between two TP modules where forwarding of data is started (when a specified threshold is reached) before all data have been received. If larger amount of data is transported between two interfaces it is desirable to be able to start the transmission on the destination network before receiving all data from the source network. This saves memory and time.|
|multicast operation|Simultaneous transmission of PDUs to a group of receivers, i.e. 1:n routing.|
|data provision|Provision of data to interface modules.(a) direct data provision: data to be transmitted are provided directly at the transmit request. The destination communication interface may behave in two ways, either copy the data directly or defer the copy to a trigger transmit.(b) trigger transmit data provision: data to be transmitted are not provided at the transmit request, but will be retrieved by the interface module via a callback function|
|last-is-best buffering|Buffering strategy where the latest value overwrites the last value.|
|FIFO buffering|Buffer concept, which uses first in first out strategy.|


|Abbreviation|Description|
|:--|:--|
|I-PDU ID|PDU Identifier|
|I-PDU|Interaction Layer PDU. An I-PDU consists of data (buffer), length and I-PDU ID. The PDU router will mainly route I-PDUs (exception is routing-on-the-fly)|
|N-PDU|Network Layer PDU. Used by transport protocol modules to fragment an I-PDU|
|L-PDU|Data Link Layer PDU. One or more I-PDUs are packed into one L-PDU. The L-PDU is bus specific, e.g. CAN frame.|
|SF|Single Frame, Transport Protocol term|
|FF|First Frame, Transport Protocol term|
|CF|Consecutive Frame, Transport Protocol term|
|PDU|Protocol Data Unit|
|BSW|Basic Software|
|\<SrcLo\>|Lower layer communication interface module acting as a source of the I-PDU. The SrcLo is always one.|
|\<DstLo\>|Lower layer communication interface module acting as a destination of the I-PDU. The DstLo may by one to many.|
|\<SrcLoTp\>|Lower layer transport protocol module acting as a source of the I-PDU. The SrcLoTp is always one.|
|\<DstLoTp\>|Lower layer transport protocol module acting as a destination of the I-PDU. The DstLoTp may by one to many.|
|\<Lo\>|Lower layer communication interface module|
|\<Up\>|Upper layer module|
|\<LoTp\>|Lower layer transport protocol module|
|\<module\>|Any type of module <...>|

##3 Related documentation 3.1 Input documents
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf,
[2] Requirements on Gateway, AUTOSAR_SRS_Gateway.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[5] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[6] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[7] Specification of I-PDU Multiplexer AUTOSAR_SWS_IPDUMultiplexer.pdf
[8] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[9] List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[10] [11]
3.2
General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
Guide to BSW Distribution AUTOSAR_EXP_BSWDistributionGuide.pdf

# 171 Specification of Operating System Interface

2 Acronyms and Abbreviations
The glossary below includes acronyms and abbreviations relevant to the Operating System Interface that are not included in the [2] AUTOSAR Glossary.
      
|Abbreviation / Acronym|Description|
|:--|:--|
|OSI|Operating System Interface|
|Operating System Interface|A Functional Cluster within the Adaptive Platform Foundation|
|AUTOSAR Adaptive Platform|see [2] AUTOSAR Glossary|
|Adaptive Platform Foundation|see [2] AUTOSAR Glossary|
|Adaptive Application|see [2] AUTOSAR Glossary|
|Execution Management|A Functional Cluster within the Adaptive Platform Foundation|
|Application|see [2] AUTOSAR Glossary|
|Operating System|Software responsible for managing Processes on a Machine and for providing an interface to hardware resources.|
|Process|see [2] AUTOSAR Glossary|
|Initial Process|A process with management rights, e.g. to determine exit status, for all processes within the AUTOSAR Adaptive Platform.|
|Foundation|see [2] AUTOSAR Glossary|
|Machine|see [2] AUTOSAR Glossary|
|Process|see [2] AUTOSAR Glossary|
|Executable|see [2] AUTOSAR Glossary|
|Functional Cluster|see [2] AUTOSAR Glossary|

## 3  Related Documentation
### 3.1 Input Documents & Related Standards and Norms
[1] IEEEStandardforInformationTechnology-StandardizedApplicationEnvironment Profile (AEP)-POSIX Realtime and Embedded Application Support https://standards.ieee.org/findstds/standard/1003.13-2003.html
[2] Glossary AUTOSAR_TR_Glossary
[3] General Specification of Adaptive Platform AUTOSAR_SWS_General
[4] Requirements on Operating System Interface AUTOSAR_RS_OperatingSystemInterface


# 170 Specification of Operating System
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_OS.pdf

##2 Acronyms and abbreviations
 
|Abbreviation| Description|
|:--|:--|
|API| Application Programming Interface|
|AR| AUTOSAR|
|BSW| Basic Software|
|BSWMD| Basic Software Module Description|
|CDD |Complex Driver|
|COM |Communication|
|ECC |Extended Conformance Class|
|ECU| Electronic Control Unit|
|HW| Hardware|
|ID| Identifier|
|IOC| Inter OS-Application communicator|
|ISR| Interrupt Service Routine|
|LE| A locatable entity is a distinct piece of software that has the same effect regardless of which core it is located.|
|MC| Multi-Core|
|MCU| Microcontroller Unit|
|ME| Mutual exclusion|
|MPU| Memory Protection Unit|
|NMI| Mutual exclusion|
|OIL| OSEK Implementation Language|
|OS| Operating System|
|OSEK/VDX| Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug|
|RTE| Run-Time Environment|
|RTOS| Real Time Operating System|
|SC| Single-Core|
|SLA| Software Layered Architecture|
|SW| Software|
|SWC| Software Component|
|SWFRT| Software FreeRunningTimer|
 
### 2.1 GlossaryofTerms
  
|Term|Definition|
|:--|:--|
|Access Right|An indication that an object (e.g. Task, ISR, hook function) of an OS-Application has the permission of access or manipulation with respect to memory, OS services or (set of) OS objects.|
|Cardinality|The number of items in a set.|
|Counter|An operating system object that registers a count in ticks. There are two types of counters:|
|Hardware Counter|A counter that is advanced by hardware (e.g. timer). The count value is maintained by the peripheral “in hardware”.|
|Software Counter|A counter which is incremented by making the IncrementCounter() API call (see SWS_Os_00399). The count value is maintained by the operating system “in software”.|
|Deadline|The time at which a Task/Category 2 ISR must reach a certain point during its execution defined by system design relative to the stimulus that triggered activation. See Figure 2.1|
|Delay|The number of ticks between two adjacent expiry points on a schedule table.A pair of expiry points X and Y are said to be adjacent when: There is no expiry point Z such that X.Offset < Z.Offset < Y.Offset. In this case the Delay = Y.Offset-X.Offset. X and Y are the Final Expiry Point and the Initial Expiry Point respectively. In this case Delay = (Duration-X.Offset)+Y.Offset. When used in the text, Delay is a relative number of ticks measured from a specified expiry point. For example: X.Delay is the delay from X to the next expiry point.|
|Deviation|The minimum number of ticks between the current position on an explicitly synchronized schedule table and the value of the synchronization count modulo the duration of the schedule table.|
|Duration|The number of ticks from a notional zero at which a schedule table wraps.|
|Execution Time|TASK, ISRs. Execution time includes the time spent in the error, pretask and posttask hooks and the time spent making OS service calls.|
|Tasks(Execution Time)|The net time a task spends in the RUNNING state without entering the SUSPENDED or WAITING state excluding all preemptions due to ISRs which preempt the task. An extended task executing the WaitEvent() API call to wait on an event which is already set notionally enters the WAITING state. For multiple activated basic tasks the net time is per activation of a task.|
|ISRs(Execution Time)|The net time from the first to the last instruction of the user provided Category 2 interrupt handler excluding all preemptions due to higher priority ISRs executing in preference.|
|    Execution Budget|    Maximum permitted execution time for a Task/ISR.|
|    Expiry Point|       The offset on a Schedule Table, measured from zero, at which the OS activates tasks and/or sets events.|
|     Initial Expiry Point|   The expiry point with the smallest offset|
|     Final Expiry Point|      The expiry point with the largest offset|
|    Hook Function|     A Hook function is implemented by the user and invoked by the operating system in the case of certain incidents. In order to react to these on system or application level, there are two kinds of hook functions|
|     Application-specific|      Hook functions within the scope of an individual OS- Application.|
|    System-specific|   Hook functions within the scope of the complete system (in general provided by the integrator).|
|    Initial Offset|     The smallest expiry point offset on a schedule table. This can be zero.|
|    Interarrival Time|See Figure 2.1.|
|   Basic Tasks(Interarrival Time)|The time between successively entering the READY state from the SUSPENDED state. Activation of a task always represents a new arrival. This applies in the case of multiple activations, even if an existing instance of the task is in the RUNNING or READY state.|
|Extended Tasks(Interarrival Time)|The time between successively entering the READY state from the SUSPENDED or WAITING states. Setting an event for a task in the WAITING state represents a new arrival if the task is waiting on the event. Waiting for an event in the RUNNING state which is already set represents a new arrival.|
|ISRs(Interarrival Time)|The time between successive occurrences of an interrupt.|
|   Interrupt Lock Time|   The time for which a Task/ISR executes with Category 1 interrupts disabled/suspended and/or Category 2 interrupts disabled/suspended .|
|    Interrupt Source Enable|     The switch which enables a specific interrupt source in the hardware.|
|    Interrupt Vector Table| Conceptually, the interrupt vector table contains the mapping from hardware interrupt requests to (software) interrupt service routines. The real content of the Interrupt Vector Table is very hardware specific, e.g. it can contain the start addresses of the interrupt service routines.|
|    Final Delay|   The difference between the Final Expiry Point offset and the duration on a schedule table in ticks. This value defines the delay from the Final Expiry Point to the logical end of the schedule table for single-shot and “nexted” schedule tables.|
|    Forced OS- Application Termination| The operating system frees all system objects, e.g. forcibly terminates Tasks, disables interrupts, etc., which are associated to the OS-Application. OS- Application and internal variables are potentially left in an undefined state.|
|    Forced Termination|     The OS terminates the Task/Category 2 ISR and does ”unlock” it’s held resources. For details see SWS_Os_00108 and SWS_Os_00109.|
|      Linker File| File containing linking settings for the linker. The syntax of the linker file depends on the specific linker and, consequently, definitions are stored “linker-specific” in the linker file.|
|    Lock Budget|   Maximum permitted Interrupt Lock Time or Resource Lock Time.|
|    Master core|     A master core is a core from which the AUTOSAR system is bootstrapped.|
|    Memory Protection Unit| A Memory Protection Unit (MPU) enables memory partitioning with individual protection attributes. This is distinct from a Memory Management Unit (MMU) that provides a mapping between virtual addresses and physical memory locations at runtime. Note that some devices may realize the functionality of an MPU in an MMU.|
|   Mode|         Describes the permissions available on a processor.|
|       Privileged| In general, in »privileged mode« unrestricted access is available to memory as well as the underlying hardware.|
|     Non-privileged|      In »non-privileged mode« access is restricted.|
|      Modulus|   The number of ticks required to complete a full wrap of an OSEK counter. This is equal to OsCounterMaxAllowedValue +1 ticks of the counter.|
| OS-Application|        A collection of OS objects|
|       Trusted| An OS-Application that may be executed in privileged mode and may have unrestricted access to the API and hardware resources. Only trusted applications can provide trusted functions.|
|     Non-trusted|      An OS-Application that is executed in non-privileged mode has restricted access to the API and hardware resources.|
|      OS object| Object that belongs to a single OS-Application: Task, ISR, Alarm, Event, Schedule Table, Resource, Trusted Function, Counter, Applicaton-specific hook.|
|    OS Service|     OS services are the API of the operating system.|
| Protection Error|            Systematic error in the software of an OS-Application.|
|       Memory access violation| A protection error caused by access to an address in a manner for which no access right exists.|
|     Timing fault|      A protection error that violates the timing protection.|
|    Illegal service| A protection error that violates the service protection, e.g. unauthorized call to OS service.|
|     Hardware exception|      division by zero, illegal instruction etc.|
|      Resource Lock Time|   The time an OSEK resource is held by a Task/ISR (excluding the preemptions of the Task/ISR by higher prior Tasks/ISRs).|
|    Response Time|   The time between a Task/ISR being made ready to execute and generating a specified response. The time includes all preemptions. See Figure 2.1|
|    Restart an OS-Application|   An OS-Application can be restarted after self-termination or being forcibly terminated because of a protection error. When an OS-Application is restarted, the OS activates the configured OsRestartTask.|
|Scalability Class|The features of the OS (e.g. Memory Protection or Timing Protection), described by this document, can be grouped together to customize the operating system to the needs of the application. There are 4 defined groups of features which are named scalability classes. For details see Chapter 7.11|
|Schedule Table|Encapsulation of a statically defined set of expiry points.|
|Section|Part of an object file in which instructions or data are combined to form a unit (contiguous address space in memory allocated for data or code). A section in an object file (object file format) has a name and a size. From the linker perspective, two different sides can be distinguished:|
|Input section|memory section in an input object file of the linker.|
|Output section|memory section in an output object file of the linker.|
|Set (of OS objects)|This document uses the term set, indicating a collection of the same type of OS objects, in the strict mathematical sense, i.e.: - a set contains zero or more OS objects (this means a set can be empty) - the OS objects in the set are unique (this means there cannot be duplicate OS objects in the set)|
|Spinlock|A spinlock is a locking mechanism where the TASK waits in a loop ("spins") repeatedly checking for a shared variable to become a certain value.|
|The value indicates whether the lock is free or not. In Multi-Core systems the comparison and changing of the variable typically requires an atomic operation. As the TASK remains active but is not doing anything useful, a spinlock is a busy waiting mechanism|
|Spinlock variable|A spinlock variable is a shared variable used by a spinlock to indicate whether a spinlock is free or occupied.|
|Symbol|Address label that can be imported/used by software modules and resolved by the linker. The precise syntax of the labels is linker-specific. Here, these address labels are used to identify the start and end of memory sections.|
|Start symbol|Tags the start of a memory section|
|End symbol|Tags the end of a memory section|
|Synchronization of schedule tables with a synchronization counter|Synchronization with a synchronization counter is achieved, if the expiry points of the schedule table are processed within an absolute deviation from the synchronization counter that is smaller than or equal to a precision threshold.|
|Synchronization Counter|The “Synchronization Counter”, distinct from an OS counter object, is an external counter, external to the OS, against which expiry points of a schedule table are synchronized|
|Task|A Task is the object which executes (user) code and which is managed by the OS. E.g. the OS switches between different Tasks (“schedules”). There are 2 types of Tasks; for more details see [15].|
|Basic Task|A Task which cannot block by itself. This means that it cannot wait for (OS) event(s).|
|Extended Task|A Task which can block by itself and wait for (OS) event(s).|
|Time Frame|The minimum inter-arrival time for a Task/ISR.|
|Trusted Function|A service provided by a trusted OS-Application that can be used by other OS- Applications (trusted or non-trusted).|
|Worst case execution time (WCET)|The longest possible execution time.|
|Write access|Storing a value in a register or memory location. All memory accesses that have the consequence of writing (e.g. reads that have the side effect of writing to a memory location) are treated as write accesses.|

##3 Related documentation 3.1 Inputdocuments
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] Requirements on Operating System AUTOSAR_SRS_OS.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of the Virtual Functional Bus AUTOSAR_EXP_VFB.pdf
[5] Requirements on Software FreeRunningTimer AUTOSAR_SRS_FreeRunningTimer.pdf
[6] Specification of GPT Driver AUTOSAR_SWS_GPTDriver.pdf
[7] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[8] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[9] Specification of RTE AUTOSAR_SWS_RTE.pdf
[10] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[11] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[13] Specification of RTE AUTOSAR_SWS_RTE.pdf
[14] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

## 3.2 Relatedstandardsandnorms 3.2.1 ISO 17356
The ISO 17356 (“Road vehicles -- Open interface for embedded automotive applications”) is a standard which was previously published by the OSEK/VDX organization.
[15] ISO 17356-3: 2005: Road vehicles -- Open interface for embedded automotive applications -- Part 3: OSEK/VDX Operating System (OS)
[16] ISO 17356-6:2006: Road vehicles -- Open interface for embedded automotive applications -- Part 6: OSEK/VDX Implementation Language (OIL)
###3.3 CompanyReports,AcademicWork,etc.
[17] Extensions of OSEK OS for Protected Applications OSEK Support Project DC058_02
DaimlerChrysler AG

# 169 Specification of OCU Driver

## 2 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope appear in the glossary below. Those that have a global scope are contained in the AUTOSAR glossary.

|Acronym/Abbreviation|Description|
|:--|:--|
|OCU|Output Compare Unit|
|DMA|Direct Memory Access|
|MCAL|Microcontroller Abstraction Layer|
|MCU|Microcontroller Unit|
|DEM|Diagnostic Event Manager.|
|DET|Default Error Tracer.|
|SPAL|Standard Peripheral Abstraction Layer|
|MCU|Microcontroller Unit.|
|ISR|Interrupt Service Routine.|
Term definition:
 
|Term|Description|
 |:--|:--|
|OCU channel|Represents a logical entity composed of a free running counter a comparison threshold and the action that is done as a result of the comparison process.|
|Compare threshold.|Target value that is compared with the content of the counter each time the counter is increased by one unit.|
|Free running counter|A counter that runs from a minimum (respectively a maxium) to a maximum (respectively a minimum) value and restarts automatically from the minimum (respectively a maximum) after reaching the maximum (respectively the minimum) value.|
|Reference Interval|Interval (in ticks) given by the caller of the Ocu_SetAbsolutThreshold API, and used as base to compute the return information.|

##3 Related documentation 3.1 Inputdocuments
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[5] Specification of MCU Driver AUTOSAR_SWS_MCUDriver.pdf
[6] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[7] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[8] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf

#168 Specification of Network Management Interface
2 Acronyms and Abbreviations
The glossary below includes acronyms and abbreviations and terms relevant to the Network Management Interface module that are not included in the [1, AUTOSAR glos- sary].
      
|Abbreviation / Acronym|Description|
|:--|:--|
|CanIf|CAN Interface module|
|CanNm|CAN Network Management module|
|CC|Communication controller|
|ComM|Communication Manager module|
|EcuM|ECU State Manager module|
|DEM|Diagnostic Event Manager module|
|Nm|Generic Network Management Interface module, this ist the abre- viation used for this module throughout this specification|
|NM|Network Management|
|OEM|Original Equipment Manufacturer|
|CBV|Control Bit Vector in NM-message|

|Terms|Definition|
|:--|:--|
|Bus-Sleep Mode|Network mode where all interconnected communication con- trollers are in the sleep mode.|
|NM-Channel|Logical channel associated with the NM-cluster|
|NM-Cluster|Set of NM nodes coordinated with the use of the NM algorithm.|
|NM-Coordinator|A functionality of the Nm which allows coordination of network sleep for multiple NM Channels.|
|NM-Message|Packet of information exchanged for purposes of the NM algo- rithm.|
|NM-Timeout|Timeout in the NM algorithm that initiates transition into Bus- Sleep Mode.|
|NM User Data|Supplementary application specific piece of data that is attached to every NM message sent on the bus.|
|Node Identifier|Node address information exchanged for purposes of the NM al- gorithm.|
|Node Identifier List|List of Node Identifiers recognized by the NM algorithm.|
|Bus|Physical communication medium to which a NM node/ecu is con- nected to.|
|network|Entity of all NM nodes/ecus which are connected to the same bus.|
|channel|Logical bus to which the NM node/ecu is connected to.|
|Coordinated shutdown|Shutdown of two or more busses in a way that their shutdown is finished coinciding.|
|Coordination algorithm|Initiation of coordinated shutdown in case all conditions are met.|

##3 Related documentation 3.1 Input documents
[1] Glossary AUTOSAR_TR_Glossary
[2] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[3] Specification of CAN Network Management AUTOSAR_SWS_CANNetworkManagement
[4] Specification of FlexRay Network Management AUTOSAR_SWS_FlexRayNetworkManagement
[5] Specification of UDP Network Management AUTOSAR_SWS_UDPNetworkManagement
[6] Specification of Network Management for SAE J1939 AUTOSAR_SWS_SAEJ1939NetworkManagement
[7] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[8] Requirements on Network Management AUTOSAR_SRS_NetworkManagement
[9] Specification of Communication Manager AUTOSAR_SWS_COMManager
[10] Guide to BSW Distribution AUTOSAR_EXP_BSWDistributionGuide

#167 Specification of NVRAM Manager

##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|
|:--|:--|
|Basic Storage Object|A “Basic Storage Object” is the smallest entity of a “NVRAM block”. Several “Basic Storage Objects” can be used to build a NVRAM Block. A “Basic Storage Object“ can reside in different memory locations (RAM/ROM/NV memory).|
|NVRAM Block|The “NVRAM Block” is the entire structure, which is needed to administrate and to store a block of NV data.|
|NV data|The data to be stored in Non-Volatile memory.|
|Block Management Type|Type of the NVRAM Block. It depends on the (configurable) individual composition of a NVRAM Block in chunks of different mandatory/optional Basic Storage Objects and the subsequent handling of this NVRAM block.|
|RAM Block|The „RAM Block“ is a „Basic Storage Object“. It represents the part of a „NVRAM Block“ which resides in the RAM. See [SWS_NvM_00126]|
|ROM Block|The „ROM Block“ is a „Basic Storage Object“. It represents the part of a „NVRAM Block“ which resides in the ROM. The „ROM Block“ is an optional part of a „NVRAM Block“.[SWS_NvM_00020]|
|NV Block|The „NV Block“ is a „Basic Storage Object“. It represents the part of a „NVRAM Block“ which resides in the NV memory. The „NV Block“ is a mandatory part of a „NVRAM Block“. [SWS_NvM_00125]|
|NV Block Header|Additional information included in the NV Block if the mechanism “Static Block ID” is enabled.|
|Administrative Block|The “Administrative Block” is a “Basic Storage Object”. It resides in RAM. The “Administrative Block” is a mandatory part of a “NVRAM Block”. [SWS_NvM_00135]|
|DET|Default Error Tracer – module to which development errors are reported.|
|DEM|Diagnostic Event Manager – module to which production relevant errors are reported|
|NV|Non volatile|
|FEE|Flash EEPROM Emulation|
|EA|EEPROM Abstraction|
|FCFS|First come first served|

##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] Requirements on Memory Services AUTOSAR_SRS_MemoryServices.pdf
[5] Specification of EEPROM Abstraction AUTOSAR_SWS_EEPROMAbstraction
[6] Specification of Flash EEPROM Emulation AUTOSAR_SWS_FlashEEPROMEmulation
[7] Specification of Memory Abstraction Interface AUTOSAR_SWS_MemoryAbstractionInterface
[8] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping
[9] Virtual Functional Bus AUTOSAR_EXP_VFB.pdf
[10] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[11] Specification of RTE Software AUTOSAR_SWS_RTE.pdf
[12] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[13] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[14] Specification of CRC Routines AUTOSAR_SWS_CRCLibrary
[15] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral.pdf

#  166 Specification of Memory Mapping
  
## 2 Acronyms and Abbreviations
The glossary below includes acronyms and abbreviations relevant to the Memory Map- ping specification that are not included in the [1, AUTOSAR glossary].
Table 2.1: Abbreviations and Acronyms

|Abbreviation / Acronym|Description|
|:--|:--|
|BSW|Basic Software|
|ISR|Interrupt Service Routine|
|NVRAM|Non-Volatile RAM|

##3 Related documentation
3.1 Input documents
References
[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] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[5] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[6] Methodology AUTOSAR_TR_Methodology
[7] Specification of RTE Software AUTOSAR_SWS_RTE
[8] Cosmic C Cross Compiler User’s Guide for Motorola MC68HC12, V4.5
[9] ARM ADS compiler manual
[10] GreenHills MULTI for V850 V4.0.5
Building Applications for Embedded V800, V4.0, 30.1.2004
[11] TASKING for ST10 V8.5
C166/ST10 v8.5 C Cross-Compiler User’s Manual, V5.16
[12] TASKING for ST10 V8.5
C166/ST10 v8.5 C Cross-Assembler, Linker/Locator, Utilities User’s Manual, V5.16

# 165 Specification of Memory Abstraction Interface

## 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 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)|
|Fast Mode|E.g. during startup / shutdown the underlying driver may be switched into fast mode in order to allow for fast reading / writing in those phases.|
|Note: Whether this is possible depends on the implementation of the driver and the capabilities of the underlying device. Whether it is done depends on the configuration of the NVRAM manager and thus on the needs of a specific project.|
|Slow Mode|During normal operation the underlying driver may be used in slow mode in order to reduce the resource usage in terms of runtime or blocking time of the underlying device / communication media. Note: Whether this is possible depends on the implementation of the driver and the capabilities of the underlying device. Whether it is done depends on the configuration of the NVRAM manager and thus on the needs of a specific project.|
|Vendor specific library|A vendor specific library is an ICC-2 implementation of the FEE/FLS and EA/EEP modules respectively. It provides the same upper layer interface (API) and functionality as the corresponding ICC-3 implementation.|

##3 Related documentation 3.1 Inputdocuments
[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] 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] 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 Flash EEPROM Emulation AUTOSAR_SWS_FlashEEPROMEmulation.pdf
[9] Specification of EEPROM Abstraction AUTOSAR_SWS_EEPROMAbstraction.pdf

#164 Specification of Fixed Point Math Routines

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

|Abbreviation / Description| Acronym|
|:--|:--|
|Abs| Absolute value|
|AbsDiff| Absolute value of a difference|
|Add| Addition|
|AR| Autosar|
|BSW| Basic Software|
|DET| Default Error Tracer|
|Div| Division|
|DivShLeft| Combination of division and shift left|
|ECU| Electronic Control Unit|
|Limit| Limitation routine|
|Max| Maximum|
|MFX/Mfx| Math – Fixed Point library|
|Min| Minimum|
|Minmax| Limitation with only one value for min and max|
|Mod| Modulo routine|
|Mul| Multiplication|
|MulDiv| Combination of multiplication and division|
|MulShRight| Combination of multiplication and shift right|
|s16| Mnemonic for the sint16, specified in AUTOSAR_SWS_PlatformTypes|
|s32| Mnemonic for the sint32, specified in AUTOSAR_SWS_PlatformTypes|
|s8| Mnemonic for the sint8, specified in AUTOSAR_SWS_PlatformTypes|
|Sub| Subtraction|
|SWS| Software Specification|
|u16| Mnemonic for the uint16, specified in AUTOSAR_SWS_PlatformTypes|
|u32| Mnemonic for the uint32, specified in AUTOSAR_SWS_PlatformTypes|
|u8| Mnemonic for the uint8, specified in AUTOSAR_SWS_PlatformTypes|
 
 ##3Related 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] AUTOSAR Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[6] Specification of Platform Types, AUTOSAR_SWS_PlatformTypes.pdf
[7] Requirement on Libraries, AUTOSAR_SRS_Libraries.pdf
[8] Specification of C Implementation Rules, AUTOSAR_TR_CImplementationRules.pdf
[9] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
3.2 Relatedstandardsandnorms
[10] ISO/IEC 9899:1990 Programming Language – C

# 163 Specification of Floating Point Math Routines

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

|Abbreviation / Acronym|Description|
|:--|:--|
|abs|Absolute value|
|Lib|Library|
|DET|Default Error Tracer|
|f32|Mnemonic for the float32, specified in AUTOSAR_SWS_PlatformTypes|
|Limit|Limitation routine|
|max|Maximum|
|MFL|Mathematical Floating point Library|
|min|Minimum|
|Mn|Mnemonic|
|s16|Mnemonic for the sint16, specified in AUTOSAR_SWS_PlatformTypes|
|s32|Mnemonic for the sint32, specified in AUTOSAR_SWS_PlatformTypes|
|s8|Mnemonic for the sint8, 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|
|u8|Mnemonic for the uint8, specified in AUTOSAR_SWS_PlatformTypes|
|boolean| Boolean data type, specified in AUTOSAR_SWS_PlatformTypes|

##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 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] Requirement on Libraries, AUTOSAR_SRS_Libraries.pdf
[8] Memory mapping mechanism, AUTOSAR_SRS_MemoryMapping.pdf
3.2 Relatedstandardsandnorms
[10] ISO/IEC 9899:1990 Programming Language – C

#162  Specification of MCU Driver

##2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|uC|Microcontroller|
|MCU|Micro Controller Unit|
|SFR|Special Function Register (MCU register)|
|DEM|Diagnostic Event Manager|
|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] Specification of Default Error Tracer, AUTOSAR_SWS_DefaultErrorTracer.pdf
[5] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[6] Specification of Diagnostic Event Manager, AUTOSAR_SWS_ DiagnosticEventManager.pdf
[7] Specification of ECU State Manager, AUTOSAR_SWS_ECUStateManager.pdf
[8] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[9] Requirements on MCU driver, AUTOSAR_SRS_MCUDriver.pdf
[10] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[11] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

#161 Specification of Log and Trace

## 2 Acronyms and Abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|Log and Trace|The official Functional Cluster name that manages the logging|
|L&T|Acronym for Log and Trace|
|LT protocol|Original name of the protocol itself (Log and Trace), specified in the PRS document [1]|
|Logging API|The main logging interface towards user applications as a library|
|Logging back-end|Implementation of the LT protocol, e.g. DLT|
|Logging Client|AnexternaltoolwhichcanremotelyinteractwiththeLogging frame- work|
|Logging framework|Implementation of the software solution used for logging purposes|
|Logging instance|The class that enables the logging functionality and handles a single logging context|
|Log message|Log message, including message header(s)|
|Log severity level|Meta information about the severity of a passed logging information|
|DLT|Diagnostics Log and Trace - a GENIVI Log and Trace daemon imple- mentation of the LT protocol|
|Application process        |An executable instance (process) that is running on a Machine|
|Adaptive Application|see [2] AUTOSAR Glossary|
|Application|see [2] AUTOSAR Glossary|
|AUTOSAR Adaptive Platform|see [2] AUTOSAR Glossary|
|Adaptive Platform Foundation|see [2] AUTOSAR Glossary|
|Manifest|see [2] AUTOSAR Glossary|
|Executable|see [2] AUTOSAR Glossary|
|Functional Cluster|see [2] AUTOSAR Glossary|
|Adaptive Platform Service|see [2] AUTOSAR Glossary|
|Machine|see [2] AUTOSAR Glossary|
|Service|see [2] AUTOSAR Glossary|
|Service Interface|see [2] AUTOSAR Glossary|
|Service Discovery|see [2] AUTOSAR Glossary|

##3 Related documentation 3.1 Input documents
[1] Log and Trace Protocol Specification AUTOSAR_PRS_LogAndTraceProtocol
[2] Glossary AUTOSAR_TR_Glossary
[3] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[4] Requirements on Log and Trace AUTOSAR_RS_LogAndTrace
[5] Specification of Time Synchronization for Adaptive Platform AUTOSAR_SWS_TimeSync

#160 Specification of LIN Transceiver Driver

## 2 Acronyms and abbreviations

|Abbreviation|Description|
|:--|:--|
|API|Application Program Interface|
|Channel|A channel is a software exchange medium for data that are defined with the same criteria.|
|ComM|Communication Manager|
|Det|Default Error Tracer|
|Dio/DIO |Digital input output, one of the SPAL SW modules|
|EcuM|ECU State Manager|
|ECU|Electronic Control Unit|
|Frt|Free Running Timer|
|Gpt|General purpose Timer|
|ICU|Interrupt Control Unit|
|ISR|Interrupt Service Routine|
|LinTrcv|Lin Transceiver Driver|
|MCAL|Micro Controller Abstraction Layer|
|n/a|Not applicable|
|PDU|Protocol Data Unit|
|SBC|System Basis Chip; a device, which integrates e.g. LIN and/or LIN transceiver, watchdog and power control.|
|SPAL|Standard Peripheral Abstraction Layer|
|SW|Software|
|SPI|Serial Peripheral Interface|
|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.|

##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] Requirements on LIN AUTOSAR_SRS_LIN.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[7] Specification of LIN Driver AUTOSAR_SWS_LINDriver.pdf
[8] Specification of LIN Interface AUTOSAR_SWS_LINInterface.pdf
[9] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[10] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[11] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[12] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf

# 159 Specification of LIN State Manager

##2Acronyms and abbreviations
Acronyms and abbreviations used in this document. Additional abbreviations can be found in the ISO 17987 specification [14].
Specification of LIN State Manager AUTOSAR CP R19-11
 
|Abbreviation / Description| Acronym|
|:--|:--|
|API| Application Program Interface|
|AUTOSAR| Automotive Open System Architecture|
|BSW| Basic Software|
|BswM| BSW Mode Manager|
|ComM| Communication Manager|
|DCM| Diagnostic Communication Manager|
|DEM| Diagnostic Event Manager|
|DET| Default Error Tracer|
|ECU| Electric Control Unit|
|ID| Identifier|
|ISR| Interrupt Service Routine|
|Jitter| Difference between longest delay and shortest delay (e.g. Worst case execution time – Best case execution time)|
|LIN| Local Interconnect Network|
|LinIf| LIN Interface|
|LinSM| LIN State Manager (the subject of this document)|
|MCAL| Microcontroller Abstraction Layer|
|PDU| Protocol Data Unit|
|RAM| Random Access memory|
|RTE| Run Time Environment|
|RX| Receive|
|SPAL| Standard Peripheral Abstraction Layer|
|SRS| Software Requirement Specification|
|SW| Software|
|SWS| Software Design Specification|
|TP| Transport Protocol|
|TX| Transmit|
|UART| Universal Asynchronous Receiver Transmitter|
|UML| Universal Modelling Language|
|URL| Uniform Resource Locator|
|WPII| Work Package in AUTOSAR phase 2|
|XML| Extensible Markup Language|
 
## 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 Standard Types AUTOSAR_SWS_StandardTypes.pdf
[5] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[6] Requirements on LIN AUTOSAR_SRS_LIN.pdf
[7] Specification of LIN Interface AUTOSAR_SWS_LINInterface.pdf
[8] Specification of Diagnostic Event Manager AUTOSAR_SWS_ DiagnosticEventManager.pdf
[9] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[10] Specification of LIN Driver AUTOSAR_SWS_LINDriver.pdf
[11] Specification of Communication Manager AUTOSAR_SWS_COMManager.pdf
[12] Specification of Basic Software Mode Manager AUTOSAR_SWS_BSWModeManager.pdf
[13] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[14] ISO 17987:2016 (all parts), Road vehicles -- Local Interconnect Network (LIN)
 
#158 Specification of LIN Interface

2 Acronyms and abbreviations
In addition to the acronyms and abbreviations found in the ISO 17987 LIN specifications [19], the following acronyms and abbreviations are used throughout this document. Some terms already defined in the ISO 17987 specifications have also been defined here in order to provide more clarification, especially for terms used very often in this document.
Specification of LIN Interface AUTOSAR CP R19-11

|Abbreviation / Acronym|Description|
|:--|:--|
|CF|Continuous Frame in LIN TP|
|FF|First Frame in LIN TP|
|ID|Identifier|
|LDF|LIN Description File|
|LIN TP|LIN Transport Protocol (Part of the LIN Interface)|
|MRF|Master Request Frame|
|NAD|Node Address. Each slave in LIN must have a unique NAD.|
|NC|Node Configuration|
|N_As|Time for transmission of the LIN frame (any N-PDU) on the sender side (see ISO 17987-2 [19]).|
|N_Cr|Time until reception of the next consecutive frame N-PDU (see ISO 17987-2 [19]).|
|N_Cs|Time until transmission of the next consecutive frame N-PDU (see ISO 17987-2 [19]).|
|P2|Time between reception of the last frame of a diagnostic request on the LIN bus and the slave node being able to provide data for a response.|
|P2*|Time between sending a response pending frame (0x78) and the LIN-slave being able to provide data for a response.|
|PID|Protected ID|
|RX|Reception|
|SID|Service Identifier (of node configuration service)|
|SF|Single Frame in LIN TP|
|SRF|Slave Response Frame|
|SRS|Software Requirement Specification|
|TX|Transmission|

|Term:|Description|
|:--|:--|
|Slot Delay|The time between start of frames in a schedule table. The unit is in number of time-bases for the specific cluster.|
|Jitter|Difference between longest delay and shortest delay (e.g. Worst case execution time – Best case execution time)|
|Maximum frame length|The maximum frame length is the TFRAME_MAX as defined in the ISO 17987-3 [19] (i.e. The nominal frame length plus 40 %).|
|Schedule entry is due|This means that the LIN Interface has arrived at a new entry in the schedule table and a frame (received or transmitted) will be initiated.|
|Slave-to-slave|From a LIN master node’s point of view, there exist 3 different directions of frames on the LIN bus: Response transmitted by the master, Response received by the master and Response transmitted by one slave and received by another slave. The slave-to-slave is describing the last one. This is not described explicitly in the ISO 17987 specifications, but mentioned in Figure 14 in ISO 17987-3: Three unconditional frame transfers.|
|Irrelevant frame|From a LIN slave node point of view, there exist 3 different directions of frames on the LIN bus: Response transmitted by the slave, Response received by the slave and Response that is ignored by the slave (i.e. communication between master and another slave or between two other slaves). These ignored frames are named irrelevant frames in this specification. This is not described explicitly in the ISO17987 specifications.|
|Relevant frame|From a LIN slave node point of view, a frame that is transmitted or received by the slave. Opposite of irrelevant frame.|
|Sporadic frame|This is one of the unconditional frames that are attached to a sporadic slot.|
|Sporadic slot|This is a placeholder for the sporadic frames. The reason to name it slot is that it has no LIN frame ID.|
|Tick|The tick is the smallest time entity to handle the communication on all channels.|
|Bus idle timeout|Lapse of time duration with no bus activity|

##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 Standard Types AUTOSAR_SWS_StandardTypes.pdf
[5] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[6] Requirements on LIN AUTOSAR_SRS_LIN.pdf
[7] Specification of LIN Driver AUTOSAR_SWS_LINDriver.pdf
[8] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[9] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[10] Specification of LIN State Manager AUTOSAR_SWS_LINStateManager.pdf
[11] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12]Specification of LIN Transceiver Driver AUTOSAR_SWS_LINTransceiverDriver.pdf
[13]Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[14] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[15] Specification of Basic Software Mode Manager AUTOSAR_SWS_BSWModeManager.pdf
[16] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 Relatedstandardsandnorms
[17] LIN Specification Package Revision 2.1, November 24, 2006 http://www.lin-subbus.org/
[18] SAE J2602-1 (2012-11), LIN Network for Vehicle Applications
[19] ISO 17987:2016 (all parts), Road vehicles – Local Interconnect Network (LIN)

# 157 Specification of LIN Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_LINDriver.pdf

##2 Acronyms, abbreviations and glossary 2.1 Acronymsandabbreviations
Acronyms, abbreviations and definitions that have a local scope for the LIN driver and therefore are not contained in the AUTOSAR glossary must appear here.

|Acronym| Description|
|:--|:--|
|AUTOSAR| Automotive Open System Architecture|
|COM| Communication|
|ECU| Electronic Control Unit|
|EcuM| ECU Manager|
|DEM| Diagnostic Event Manager|
|DET| Default Error Tracer|
|ISR| Interrupt Service Routine|
|LIN| Local Interconnect Network (as defined by [16])|
|MCAL| MicroController Abstraction Layer|
|MCU| Micro Controller Unit|
|OS| Operating System|
|PDU| Protocol Data Unit. Consists of Identifier, data length and Data (SDU)|
|PID| Protected ID (as defined by [16])|
|PLL| Phase-Locked Loop|
|RAM| Random Access Memory|
|RX| Reception|
|SCI| Serial Communication Interface|
|SDU| Service Data Unit. Data that is transported inside the PDU|
|SFR| Special Function Register|
|SPAL| Standard Peripheral Abstraction Layer|
|SRS| Software Requirement Specification|
|SW| Software|
|SWS| Software Specification|
|TP| Transport Layer|
|TX| Transmission|
|UART| Universal Asynchronous Receiver Transmitter|
|XML| Extensible Markup Language|
|Id| Identifier|


###2.2 Glossary
Besides AUTOSAR terminology this document also uses terms defined in the ISO 17987 specifications [16], e.g. LIN frame, header and message.
 
 
|Glossary|Description|
|:--|:--|
|enumeration|This can be in “C” programming language an enum or a #define.|
|LIN channel|The LIN channel entity interlinks the ECUs of a LIN cluster physically: An ECU is part of a LIN cluster if it contains one LIN controller that is connected to one LIN channel of the LIN cluster. An ECU is allowed to connect to a particular LIN cluster through one channel only.|
|LIN cluster|As defined by [16]: “A cluster is the LIN bus wire plus all the nodes.”|
|LIN controller|A dedicated LIN hardware with a build Frame processing state machine. A hardware which is capable to connect to several LIN clusters is treated as several LIN controllers.|
|LIN frame|As defined by [16]: “All information is sent packed as frames; a frame consist of the header and a response.”|
|LIN frame processor|Frame processing implies the complete LIN frame handling. Implementation could be achieved as software emulated solution or with a dedicated LIN controller.|
|LIN hardware unit|A LIN hardware unit may drive one or multiple LIN channels to control one or multiple LIN clusters.|
|LIN header|As defined by [16]: “A header is the first part of a frame; it is always sent by the master.”|
|LIN node|As defined by [16]: “Loosely speaking, a node is an ECU. However, a single ECU may be connected to multiple LIN clusters.”|
|LIN response|As defined by [16]: “A LIN frame consists of a header and a response. Also called a Frame response.”|

## 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 Standard Types AUTOSAR_SWS_StandardTypes.pdf
[5] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[6] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[7] Requirements on LIN AUTOSAR_SRS_LIN.pdf
[8] Specification of LIN Interface AUTOSAR_SWS_LINInterface.pdf
[9] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[10] Specification of MCU driver AUTOSAR_SWS_MCUDriver.pdf
[11] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager.pdf
[12] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[13] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[14] Specification of LIN Transceiver Driver, AUTOSAR_SWS_LINTransceiverDriver.pdf
[15] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 Related standards and norms
[16] ISO 17987:2016 (all parts), Road vehicles – Local Interconnect Network (LIN)

# 156 Specification of Key Manager
## 2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|KeyM|Key Manager|
|PKI|Public Key Infrastructure|
|CSR|Certificate Signing Request|
|CSM|Crypto Service Manager|
|CRL|Certificate Revocation List|
|CA|Certificate Authority|
|OID|Object Identifier. A byte array that identifies a certificate element or group or list of certificate elements.|

## 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 Service Manager AUTOSAR_SWS_CryptoServiceManager.pdf
[5] AUTOSAR Requirements on Crypto Stack AUTOSAR_SRS_CryptoStack.pdf
3.2 Relatedstandardsandnorms
[6] IEC 7498-1 The Basic Model, IEC Norm, 1994
[7] IETF 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
[8] SHE – Secure Hardware Extension, Functional Specification, V1.1

#155 Specification of I-PDU Multiplexer

##2 Acronyms and abbreviations

|Abbreviation / Acronym| Description|
|:--|:--|
|COM I-PDU|I-PDU assembled in the COM module out of COM Signals|
|contained I-PDU|I-PDU assembled into or extracted from a Container PDU|
|Container PDU|PDU containing I-PDUs and headers|
|dynamic part|see [4]|
|instance of an I-PDU|IpduM I-PDU with one specific layout and content|
|Instances of a Container|Instances of the same Container PDU|
|IpduM|I-PDU Multiplexer|
|IpduM I-PDU|I-PDU assembled in the IpduM module out of two COM I-PDUs|
|multiplexed I-PDU|see IpduM I-PDU|
|segment|The static or dynamic part may consist of more than one piece. These pieces are called segments. See also Chapter 7.2.1 and Figure 2.|
|selector field|see [4]|
|signal|see [5]|
|signal group|see [5]|
|static part|see [4]|

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 RTE AUTOSAR_SWS_RTE.pdf
[4] Requirements on I-PDU Multiplexer AUTOSAR_SRS_IPDUMultiplexer.pdf
[5] Specification of Communication AUTOSAR_SWS_COM.pdf
[6] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

#154 Specification of Fixed Point In- terpolation Routines

##2
Specification of Fixed Point Interpolation Routines AUTOSAR CP R19-11
Acronyms and abbreviations
Acronyms and abbreviations, which have a local scope and therefore are not con- tained in the AUTOSAR glossary, must appear in a local glossary.

|Abbreviation / Description| Acronym|
|:--|:--|
|Cur| Curve for Interpolation|
|DET| Default Error Tracer|
|DPSearch| Data point search|
|DPResult| Data point result|
|Ifx| Interpolation Fixed point|
|IpoCur| Interpolation of curve used for distributed search and interpolation|
|LkUpCur| Curve look-up used for distributed search and interpolation|
|IpoMap| Interpolation of map used for distributed search and interpolation|
|LkUpMap| Map look-up used for distributed search and interpolation|
|IntIpoCur| Integrated interpolation of curve|
|IntLkUpCur| Integrated curve look-up|
|IntIpoFixCur| Integrated interpolation of fixed curve|
|IntLkUpFixCur| Integrated fixed curve look-up|
|IntIpoFixICur| Integrated interpolation of fixed interval curve|
|IntLkUpFixICur| Integrated fixed interval curve look-up|
|IntIpoMap| Integrated interpolation of map|
|IntLkUpMap| Integrated map look-up|
|IntIpoFixMap| Integrated interpolation of fixed map|
|IntLkUpFixMap| Integrated fixed map look-up|
|IntIpoFixIMap| Integrated interpolation of fixed interval map|
|IntLkUpFixIMap| Integrated fixed interval map look-up|
|Lib| Library|
|Map| Map for Interpolation|
|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|
|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|

## 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 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] Memory mapping mechanism, AUTOSAR_SWS_MemoryMapping.pdf
[10] Software Component Template, AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[11] Specification of C Implementation Rules, AUTOSAR_TR_CImplementationRules.pdf
[12] IFX_RecordLayout_Blueprint, AUTOSAR_MOD_IFX_RecordLayout_Blueprint.arxml
###3.2 Relatedstandardsandnorms
[13] ISO/IEC 9899:1990 Programming Language – C
[14] ASAM MCD-2MC Version 1.6 : Association for Standardisation of Automation and Measuring Systems.

#153 Specification of Floating Point Interpolation Routines

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

|Abbreviation / Acronym|Description|
|:--|:--|
|DET|Default Error Tracer|
|ROM|Read only memory|
|hex|Hexadecimal|
|Rev|Revision|
|f32|Mnemonic for the float32, specified in AUTOSAR_SWS_PlatformTypes|
|IFL|Interpolation Floating point Library|
|Mn|Mnemonic|
|Lib|Library|
|s16|Mnemonic for the sint16, specified in AUTOSAR_SWS_PlatformTypes|
|s32|Mnemonic for the sint32, specified in AUTOSAR_SWS_PlatformTypes|
|s8|Mnemonic for the sint8, 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|
|u8|Mnemonic for the uint8, specified in AUTOSAR_SWS_PlatformTypes|

## 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 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
[10] IFL_RecordLayout_Blueprint, AUTOSAR_MOD_IFL_RecordLayout_Blueprint.arxml
3.2 Relatedstandardsandnorms
[11] ISO/IEC 9899:1990 Programming Language – C

# 152 Specification of ICU Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_ICUDriver.pdf

##2 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|Active Time|This depends on the starting edge of the signal to be captured.  Start edge = falling edge => Active Time = Low Time. Start edge = rising edge => Active Time = High Time. Start edge = both edges => Active Time = High Time (if rising edge occurs initially)  Start edge = both edges => Active Time = Low Time (if falling edge occurs initially)|
|DEM|Diagnostic Event Manager|
|DET|Default Error Tracer|
|EcuM|ECU State Manager|
|Enumeration|This can be in “C” programming language an enum or a #define.|
|ICU|Input Capture Unit (not Intensive Care Unit)|
|ICU Channel|Represents a logical ICU entity bound to one input signal and the hardware resources for the configured measurement mode.|
|ICU State|Logical input state of an ICU Channel. It can be ICU_ACTIVE or ICU_IDLE.|
|ICU_ACTIVE|Input state of an ICU Channel, an activation edge has been detected.|
|ICU_IDLE|Input state of an ICU Channel, no activation edge has been detected since the last call of Icu_GetInputState() or Icu_Init().|
|Symbolic name for a channel|A symbolic name is a substitution of a handle with a name. With this handle each channel and its related properties can be found within the configuration structure. In “C” programming language this can be realized e.g. by #defines and enums.|
|Wakeup event|A wakeup event is understood as a pattern of edges, which will lead to the wake up of this driver. Nevertheless the decision whether a pattern is valid or not isn’t done by this driver. This shall be done by an upper layer.|
 
## 3 Related documentation 3.1 Inputdocuments
[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 Diagnostics Event Manager (DEM), AUTOSAR_SWS_DiagnosticEventManager.pdf
[6] Specification of Default Error Tracer, AUTOSAR_SWS_DefaultErrorTracer.pdf
[7] Requirements on ICU Driver, AUTOSAR_SRS_ICUDriver.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] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[13] IEC 7498-1 The Basic Model, IEC Norm, 1994

#151 General Specification of Adaptive Platform
There are no acronyms 
##5 References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] General Requirements specific to Adaptive Platform AUTOSAR_RS_General

#150 Specification of GPT Driver
##2 Acronyms, abbreviations and terms
Only a few acronyms and abbreviations are listed here which are helpful to understand this document or which have a local scope. Further information can be found in the official AUTOSAR glossary [13].

|Acronym / Abbreviation|Description|
|:--|:--|
|BSW|Basic Software|
|DET|Default Error Tracer|
|ECU|Electronic Control Unit|
|GPT|General Purpose Timer|
|ICU|Input Capture Unit|
|MCU|Micro Controller Unit|
|NOP, nop|Null Operation|
|OS|Operating System|

###The terms 
defined in the table below have a local scope within this document.
 

|Term|Description|
|:--|:--|
|Timer channel|Represents a logical timer entity assigned to a timer hardware|
|Target time|Time, something shall occur, when the value is reached. The behavior depends on the configuration and the enabled functionality.|
|Tick|Defines the timer resolution, the duration of a timer increment|
|GPT Predef Timer|A GPT Predef Timer is a free running up counter provided by the GPT driver. Which GPT Predef Timer(s) are available depends on hardware (clock, hardware timers, prescaler, width of timer register, ...) and configuration. A GPT Predef Timer has predefined physical time unit and range.|

## 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 Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[5] Specification of Default Error Tracer, AUTOSAR_SWS_DefaultErrorTracer.pdf
[6] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[7] Specification of Diagnostic Event Manager, AUTOSAR_SWS_DiagnosticEventManager.pdf
[8] Specification of ECU State Manager, AUTOSAR_SWS_ECUStateManager.pdf
[9] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[10] RequirementsonGPTDriver, AUTOSAR_SRS_GPTDriver.pdf
[11] SpecificationofICUDriver, AUTOSAR_SWS_ICUDriver.pdf
[12] Specification of MCU Driver, AUTOSAR_SWS_MCUDriver.pdf
[13] Glossary, AUTOSAR_TR_Glossary.pdf
[14] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[15] General Specification of Basic Software Modules, AUTOSAR_SWS_BSWGeneral.pdf
###3.2 Relatedstandardsandnorms
[16] IEC 7498-1 The Basic Model, IEC Norm, 1994

# 149 Specification of Function Inhibition Manager

##2 Acronyms and abbreviations
      
|Abbreviation / Acronym| Description|
|:--|:--|
|Activity state| The activity state is the status of a software component being executed. The activity state results from the permission state as a precondition and physical enable condition, too. It is not calculated by the FiM and not available as a status variable. It can only be derived from local information within a software component. For further details, see chapter 7.2.1.6.|
|Functionality|Functionality comprises User-visible and User-non-visible functional aspects of a system (AUTOSAR_Glossary.pdf [2]). In addition to that - in the FiM context - a functionality can be built up of the contents of one, several or parts of runnable entities with the same set of permission / inhibit conditions. By means of the FiM, the inhibition of these functionalities can be configured and even modified by calibration. Each functionality is represented by a unique FunctionId. A functionality is characterized by a specific set of inhibit condition in contrast to runnable entities having specific scheduling conditions.|
|Inhibition Condition| The relation between one FID, an inhibition mask and the status of a Dem event/component. (see FiMInhibitionConfiguration)|
|Monitoring function| • Part of the Software Component. • Mechanism to monitor and finally to detect a fault of a certain sensor, actuator or could be a plausibility check • Reports states about events from internal processing of a SW-C or from further processing of return values of other basic software modules. • See also AUTOSAR_SWS_DiagnosticEventManager [3]|
|Permission state| The permission state contains the information whether a functionality, represented by its FID, can be executed or whether it shall not run. The state is controlled by the FiM based on reported events. For further details, see chapter 7.2.1.6.|


|Abbreviation / Acronym| Description|
|:--|:--|
|API| Application Programming Interface|
|BSW| Basic Software|
|Dem| Diagnostic Event Manager|
|ECU| Electronic Control Unit|
|FID| Function Identifier|
|FiM| Function Inhibition Manager|
|HW| Hardware|
|ID| Identification/Identifier|
|ISO| International Standardization Organization|
|MIL| Malfunction Indication Light|
|NVRAM| Non volatile Memory|
|OBD| On-board Diagnostics|
|OBDII| Emission-related On-board Diagnostics|
|OEM| Original Equipment Manufacturer|
|OS| Operating System|
|RAM| Random Access Memory|
|ROM| Read-only Memory|
|RTE| Runtime Environment|
|SW-C| Software Component|
|UDS| Unified Diagnostic Services|

##3 Related documentation 3.1 Input documents
[1] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[2] Glossary AUTOSAR_TR_Glossary
[3] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager
[4] Requirements on Function Inhibition Manager AUTOSAR_SRS_FunctionInhibitionManager
[5] Virtual Functional Bus AUTOSAR_EXP_VFB
[6] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate

#148 Specification of FlexRay Transceiver Driver

##2 Acronyms and abbreviations
 
|Abbreviation / Description| Acronym|
|:--|:--|
|μC| Microcontroller|
|API| Application Programming Interface|
|AUTOSAR| Automotive Open System Architecture|
|BD| Bus Driver|
|BSW| Basic Software|
|CC| Communication Controller|
|ComM| Communication Manager, See [8] for details|
|DEM/Dem| Diagnostic Event Manager|
|DET/Det| Default Error Tracer|
|DIO/Dio| Digital input output, one of the SPAL SW modules|
|EB| Externally buffered channel. Buffers containing data to transfer are outside the SPI Handler/Driver.|
|ECU| Electronic Control Unit|
|EcuM| ECU State Manager, see [7] for details|
|EPL| Electrical Physical Layer|
|ERRN| ERRor output signal, Negated i.e. active LOW|
|FlexRay| Node A logical entity connected to the FlexRay Network that is capable of sending and/or receiving frames.|
|FrIf| FlexRay Interface|
|FrTrcv| FlexRay Transceiver|
|GPIO| General Purpose Input Output|
|I/O| Input/Output|
|IB| Internally buffered channel. Buffers containing data to transfer are inside the SPI Handler/Driver.|
|ID/Id| Identifier|
|ISR| Interrupt Service Routine|
|MCAL| Micro controller Abstraction Layer|
|MCG|Module Configuration Generator|
|MISRA|Motor Industry Software Reliability Association|
|n/a|Not applicable|
|OS|Operating System|
|Port|Port, one of the SPAL SW modules|
|RAM|Random Access Memory|
|RxD|Receive Data|
|RxEN|Receive Enable|
|SBC|System Basis Chip; A device, which integrates e.g. CAN and/or FlexRay and/or LIN transceiver, watchdog and power control.|
|SchM|Schedule Manager|
|SPAL|Standard Peripheral Abstraction Layer|
|SPI/Spi|Serial Peripheral Interface.|
|SRS|Software Requirement Specification|
|SW|Software|
|SW-C|Software-Component|
|SWS|Software Specification|
|XML|eXtended Markup Language|



|Term|Description|
|:--|:--|
|Active Star (Network)|Star topology networks consist of one ore more active central nodes which rebroadcast(s) all transmissions received from a branch to all other branches on the network. All peripheral nodes may thus communicate with all others by transmitting to, and receiving from, the central node(s) if they are located on another branch. On detection of the failure of a branch the active star will isolate its peripheral nodes from all other branches resulting in fault confinement|
|Branch| Element of an active star network topology sharing (i.e. electrically connected to) the same transmitter and receiver circuit on the physical layer. The failure of a branch will result in the isolation of its peripheral nodes by the active star from all other branches resulting in fault confinement.|
|SPI/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/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/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.|

## 3Related documentation 3.1 Inputdocuments
[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] FlexRay_ EPL-Specification_ V2.1_Rev_D2_N010
http://www.flexray.com/
FlexRay_ EPL-Specification_ V2.1_Rev_D2_N010.pdf
FlexRay_ EPL-Application Notes_ V2.1_Rev_D_N009
http://www.flexray.com/
FlexRay_ EPL-Application Notes_ V2.1_Rev_D_N009.pdf
###3.2 Relatedstandardsandnorms
Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
Specification of Communication Manager AUTOSAR_SWS_COMManager.pdf
Specification of DIO Driver AUTOSAR_SWS_DIODriver.pdf
Specification of SPI Handler/Driver AUTOSAR_SWS_SPIHandlerDriver.pdf
Requirements on FlexRay AUTOSAR_SRS_FlexRay.pdf
Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
Specification of Basic Software Scheduler AUTOSAR_SWS_BSW_Scheduler.pdf
 Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
Specification of FlexRay Transceiver Driver AUTOSAR CP R19-11
Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf

#147 Specification of FlexRay State Manager
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_FlexRayStateManager.pdf

##2 Acronyms and abbreviations
 
|Acronym/ Description| Abbrevation|
|:--|:--|
|API| Application Program Interface|
|AUTOSAR| Automotive Open System Architecture|
|BSW| Basic Software|
|CC| Communication Controller|
|CHI| Controller Host Interface|
|ComM| AUTOSAR Communication Manager|
|DCM| Diagnostic Communication Manager|
|Dem/DEM| Diagnostic Event Manager|
|Det/DET| Default Error Tracer|
|e.g.| [lat.] exempli gratia = [eng.] for example|
|ECU| Electronic Control Unit|
|EcuM| ECU State Manager|
|Fr| FlexRay Driver|
|FrIf| FlexRay Interface (AUTOSAR BSW module)|
|FrSM| FlexRay State Manager|
|FrTrcv| FlexRay Transceiver Driver|
|i.e.| [lat.] id est = [eng.] that is|
|Id/ID| Identifier|
|N/A| Not applicable|
|NM| Network Management|
|PDU| Protocol Data Unit|
|POC| Protocol Operation Control|
|RTE| Runtime Environment|
|RX| Reception|
|SchM| Schedule Manager|
|SW| Software|
|TX| Transmission|
|UML| Unified Modeling Language|
|WUP| Wake-Up Pattern|
|XML| Extensible markup language|


|Term|Description|
|:--|:--|
|POCState| Actual CC internal state of the POC. This state might differ from vPOC!State in certain cases, e.g. after FREEZE command invocation (see [11] for details).|
|vPOC| Data structure provided from the CC to the host at the CHI, which contains the actual POC status of the CC.|
|vPOC!Freeze| vPOC!Freeze denotes the Freeze bit that is part of the vPOC data structure. The Freeze bit is used by the CC to indicate that the HALT state has been entered due to an error condition.|
|vPOC!SlotMode| vPOC!SlotMode denotes the SlotMode field that is part of the vPOC data structure.|
|Active wake-up|Wake-up caused by the ECU e.g. by a sensor.|
|Passive wake-up|Wakeup caused by another ECU and propagated (e.g. by bus or wakeup-line) to the ECU currently in focus.|
|Remote wake-up|A passive wake-up received by the FlexRay bus or wakeup-line.|
 
A passive wake-up received by the FlexRay bus or wakeup-line.
 ##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 ECU Configuration UTOSAR_TPS_ECUConfiguration.pdf
[5] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[6] RequirementsonFlexRay AUTOSAR_SRS_FlexRay.pdf
[7] Specification of FlexRay Interface AUTOSAR_SWS_FlexRayInterface.pdf
[8] Specification of FlexRay Driver AUTOSAR_SWS_FlexRayDriver.pdf
[9] Specification of Communication Manager AUTOSAR_SWS_ComManager.pdf
[10] Requirements on Mode Management AUTOSAR_SRS_ModeManagement.pdf
[11] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
### 3.2 Relatedstandardsandnorms
[13] FlexRay Communications System Protocol Specification Version 2.1 Rev A

#146 Specification of FlexRay Network Management
##2 Acronyms, abbreviations, and glossary

|Acronym|Description|
|:--|:--|
|CC|Communication Controller|
|NM|Network Management|
|WCET|Worst Case Execution Time|
|DET|Default Error Tracer. AUTOSAR Module for detection and reporting of errors during development.|
|SRS|Software requirements specification|
|SWS|Software working specification|
|API|Application program interface|
|Com|Communication module|
|OS|Operating system|
|SchM|Schedule Manager|
|PDU|Protocol data unit|
|CPU|Central processing unit|
|FrIf|Abbreviation for the FlexRay Interface|
|FrNm|Abbreviation for the Network Management on FlexRay|
|NmIf|Abbreviation for the generic Network Management|
|ECU|Electronic control unit|
|ComM|Communication manager|
|FrSm|FlexRay State Manager|
|HW|Hardware |

|Term:Definition|
|:--|:--|
|Bus-Sleep Mode|Network mode where all interconnected communication controllers are in the sleep mode.|
|NM-Network|Instance of the FlexRay NM to handle one physical FlexRay Bus. Caution: The FlexRay Bus contains two FlexRay channels which cannot be handled independent of the other. Therefore the NM-Network covers both FlexRay bus channels. This is equivalent to one NM-Cluster|
|Network requested|NM network is requested if FrNm_NetworkRequest has been called and neither the network has been released nor Bus Sleep Mode has been entered afterwards|
|Network released|NM network is released if FrNm_NetworkRelease has been called and network has not been requested afterwards|
|Repeat Message Request active|A Repeat Message Request is active if FrNm_RepeatMessageRequest has been called or a NM PDU with Repeat Message Request bit set has been received in Network Mode. It is not active anymore if Repeat Message State is left or Bus Sleep Mode is entered.|
|NM Data Cycle|Number of FlexRay cycles necessary for all nodes to be able to send NM Data at least once.|
|    NM Message|   Packet of information exchanged for purposes of the NM algorithm.|
|    NM Repetition Cycle| Number of FlexRay cycles where no change of voting behavior is possible. Value has to be a multiple of the NM Voting Cycle. Used to improve the reliability of the voting.|
|    NM Slot|   Slot reserved for purposes of network management.|
|    NM Timeout|     Timeout in the NM algorithm that initiates transition into Bus-Sleep Mode.|
|    NM User Data| Supplementary application specific data that is sent independent of the NM Vote on the bus.|
|    NM Voting Cycle|     Number of FlexRay cycles necessary for all nodes to vote at least once.|
|    NM-Vote|   Information transmitted using the FlexRay Bus indicating the vote of a ECU to keep the bus awake|
|    NM-Vector| FlexRay NM Vector is the aggregated data available when the FlexRay CC optional NM Hardware Vector Service is used.|
|    NM-Data|   Data related to NM transmitted using the FlexRay Bus.|
|    NM-Cluster|   Obsolete, equivalent to NM-Network|
|    CBV|     Control bit vector|
|    ClusterAwakeV ote|  At least one Node other than itself votes for keeping the cluster awake.|
|    Positive NM- Vote in static segment|NM-Vote PDU reception or transmission with Voting Bit set to '1'|
|    Positive NM- Vote in dynamic segment|   NM-Vote PDU received or transmitted|
|    Negative NM- Vote in static segment|   NM-Vote PDU reception or transmission with Voting Bit set '0'|
|    Negative NM- Vote|    In dynamic segment: NM-Vote PDU is neither received nor transmitted|

## 3 Related documenation 3.1 Inputdocuments
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Sofware Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Requirements on Network Management AUTOSAR_SRS_NetworkManagement.pdf
[5] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[6] FlexRay Communications System Specifications, V2.1
### 3.3 RelatedAUTOSARdocuments
[7] AUTOSAR Specification of Communication Manager AUTOSAR_SWS_COMManager.pdf
[8] Specification of Generic Network Management Interface AUTOSAR_SWS_NetworkManagement.pdf
[9] Specification of FlexRay Interface AUTOSAR_SWS _FlexRayInterface.pdf
[10] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[11] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[12] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[13] Specification of Platform Types AUTOSAR_SWS_PlatformTypes.pdf
[14] Specification of Compiler Abstraction AUTOSAR_SWS_CompilerAbstraction.pdf
[15] Specification of Operating System AUTOSAR_SWS_OS.pdf
[16] Specification of FlexRay State Manager AUTOSAR_SWS_FlexRayStateManager.pdf

#145 Specification of FlexRay Interface
##2.2 AcronymsandAbbreviations
The following acronyms and abbreviations are used throughout this document:
Specification of FlexRay Interface AUTOSAR CP R19-11

|Acronym|Description|
|:--|:--|
|BSW|(AUTOSAR) Basic Software|
|CAS|Collision Avoidance Symbol|
|CC|(FlexRay) Communication Controller|
|CDD|Complex Driver|
|CHI|Controller Host Interface of a FlexRay CC|
|COM|Communication (AUTOSAR BSW module)|
|ComM|Communication Manager (AUTOSAR BSW module)|
|DEM|Diagnostic Event Manager (AUTOSAR BSW module)|
|DET|Default Error Tracer (AUTOSAR BSW module)|
|FrIf|FlexRay Interface (AUTOSAR BSW module)|
|FrNm|FlexRay Network Management (AUTOSAR BSW module)|
|FrTp|FlexRay Transport Layer (AUTOSAR BSW module)|
|ISR|Interrupt Service Routine|
|MCG|Module Configuration Generator|
|PduR|PDU Router (AUTOSAR BSW module)|
|POC|Protocol Operation Control|
|WUDOP|Wake-Up During Operation|
|WUP|Wake-Up Pattern|
|WUS|Wake-Up Symbol|
|System Designer|The person responsible for the configuration of all system parameters that do not influence the executable code itself (i.e. the sequence of instructions executed during runtime), but the data used to configure which operations this executable code performs on which data and at which points in time.|
|i.e.|[lat.] id est = [eng.] that is|
|e.g.|[lat.] exempli gratia = [eng.] for example|
|N/A|not applicable|


## 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] Input for API Specification of AUTOSAR COM Stack
[5] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[6] Requirements on FlexRay AUTOSAR_SRS_FlexRay.pdf
[7] Specification of FlexRay Driver AUTOSAR_SWS_FlexRay.pdf
[8] Specification of FlexRay State Manager AUTOSAR_SWS_FlexRayStateManager.pdf
[9] Specification of FlexRay Transceiver Driver AUTOSAR_SWS_FlexRayTransceiverDriver.pdf
[10] Specification of FlexRay Transport Layer AUTOSAR_SWS_FlexRayTransportLayer.pdf
[11] Specification of FlexRay Network Management AUTOSAR_SWS_FlexRayNetworkManagement.pdf
[12] Specification of PDU Router AUTOSAR_SWS_PDURouter
[13] Specification of BSW Scheduler AUTOSAR_SWS_BSW_Scheduler
[14] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration
[15] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping
[16] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 RelatedStandardsandNorms
[17] FlexRay Communications System Protocol Specification Version 2.1 Revision A
[18] FlexRay Communications System Electrical Physical Layer Specification Version 2.1 Revision A
[19] FlexRay Communications System Protocol Specification Version 3.0
[20] Flexray Communications System Electrical Physical Layer Specification 3.0

#144 Specification of FlexRay ISO Transport Layer
##2 Acronyms and abbreviations
The prefix notation used in this document, is as follows:
All acronyms and abbreviations, which are specific to the FlexRay Transport Layer and are therefore not contained in the AUTOSAR glossary are described in the following:

|Prefix|Description|
|:--|:--|
|I-|Relative to upper AUTOSAR Layer (e.g. COM, DCM etc.)|
|L-|Relative to the FlexRay Interface module.|
|N-| Relative to the FlexRay Transport Protocol Layer.|

|Acronym|Description|
|:--|:--|
|Fr L-SDU|This is the SDU of the FlexRay Interface module. It is similar to Fr N-PDU but from the FlexRay Interface module point of view.|
|Fr L-SduId|This is the unique identifier of a Fr-L-SDU within the FlexRay Interface. It is used for referencing L-SDU’s routing properties.|
|Fr N-PDU|This is the PDU of the FlexRay Transport Layer. It contains address information, protocol control information and data (the whole Fr N-SDU or a part of it).|
|Fr N-SDU|This is the SDU of the FlexRay Transport Layer. In the AUTOSAR architecture, it is a set of data coming from the PDU Router.|
|Fr N-SduId|Unique N-SDU identifier within the FlexRay Transport Layer. It is used to reference N- SDU’s routing properties.|
|I-PDU|This is the PDU of the upper AUTOSAR Layers modules (e.g. COM, DCM etc.). If data transfer via FlexRay Transport Protocol is configured, I-PDU is similar to an FrTp N-SDU.|
|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).|
|Channel|A channel is a resource of the FrTp module to handle communication links to other communication nodes from FrTp’s point of view (transferring Fr N-PDUs).|
|Connection|A connection specifies a communication link between different communication nodes from FrTp’s point of view. A connection defines the sender / receiver relation of communication nodes|
|PCI|Protocol Control Information|
|e.g.|lat. ‘exempli gratia’ – engl. for example|
|i.e.|lat. 'id est' – engl. that is|
|CanTp|CAN Transport Protocol|
|LinTp|LIN Transport Protocol|
|CF|Consecutive Frame Fr N-PDU|
|COM|AUTOSAR Communications module|
|DCM|Diagnostic Communication Manager module|
|DET|Default Error Tracer|
|FC|Flow Control Fr N-PDU|
|Fr|FlexRay Driver module|
|FrIf|FlexRay Interface module|
|FrTp|FlexRay Transport Protocol Layer|
|PduR|PDU Router|
|SF|Start Frame Fr N-PDU|
|LF|Last Frame Fr N-PDU|
|TP|Transport Protocol Layer|
|    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.|
|    AUTOSAR|   Automotive Open System Architecture|
|    SWS|   Software Specification|
|    MISRA|   Motor Industry Software Reliability Association|
|    ISO|  International Standard Organisation|
|    ID|   Identifier|
|    OS|   Operating System|
|    MCAL|   Microcontroller Abstraction Layer|
|    CPU|   Central Processing Unit|
|    ROM|   Read Only Memory|
|    RAM|     Random Access Memory|
|    STF| Start Frame (please refer to ISO 10681-2)|
|    AF|   Acknowledge Frame (please refer to ISO 10681-2)|
|    SN|     Sequence Number (please refer to ISO 10681-2)|
|    FrTp_As|   Timer Parameter for a sender. Time for transmission of the FlexRay frame (any N_PDU) on the sender side. (please refer to ISO 10681-2)|
|    FrTp_Ar| Timer Parameter for a receiver. Time for transmission of the FlexRay frame (any N_PDU) on the receiver side (please refer to ISO 10681-2)|
|    FrTp_BS|   Timer Parameter for a sender. Time until reception of the next FlowControl N_PDU. (please refer to ISO 10681-2)|
|    FrTp_Br|     Timer Parameter for a receiver. Time until transmission of the next FlowControl N_PDU. (please refer to ISO 10681-2)|
|    FrTp_Cs| Timer Parameter for a sender. Time until transmission of the next ConsecutiveFrame N_PDU/LastFrame N_PDU. (please refer to ISO 10681-2)|
|   FrTp_Cr|   Timer Parameter for a receiver. Time until reception of the next ConsecutiveFrame N_PDU (please refer to ISO 10681-2)|


## 3 Related documentation 3.1 Inputdocuments
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf.pdf
[3] General Requirements of Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Requirements on FlexRay AUTOSAR_SRS_FlexRay.pdf
[5] Specification of FlexRay Interface AUTOSAR_SWS_FlexRayInterface.pdf
[6] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[7] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[8] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[9] Specification of Platform Types AUTOSAR_SWS_PlatformTypes.pdf
[10] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[11] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[12] Specification of Diagnostic Event Manager, AUTOSAR_SWS_DiagnosticEventManager.pdf
[13] Specification of Default Error Tracer, AUTOSAR_SWS_DefaultErrorTracer.pdf
[14] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 Relatedstandardsandnorms
[15] FlexRay Communications System Protocol Specification Version 2.1
[16] ISO10681-2, Road vehicles – Communication on FlexRay – Part 2: Communication Layer services

#143 Specification of FlexRay Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_FlexRayDriver.pdf
##2 Acronyms and abbreviations
###2.1 Glossary of terms

|Abbreviation|Description|
|:--|:--|
|API |Application Programming Interface |
|AUTOSAR |Automotove Open Systems Architecture |
|BSW |Basic Software|
|DEM/Dem |Autosar Module: Diagnostic Event Manager |
|DET/Det |Autosar Module: Default Error Tracer |
|ECU|Electronic Control Unit|
|MCG|Module Configuration Generator |
|CC|Communication Controller |
|CHI|Controller Host Interface|
|FIFO|First In First Out buffer|
|Fr|Autosar Module: FlexRay Driver|
|FrIf|Autosar Module: FlexRay Interface|
|FrTp |Autosar Module: FlexRay Transport Protocol|
|FrTrcv |Autosar Module: FlexRay Transceiver Driver|
|ID/Id|Identifier|
|ISR|Interrupt Service Routine|
|LPdu |Datalink layer Protocol Datagram Unit|
|MCAL |Microcontroller Abstraction Layer|
|MCU |Microcontroller Unit|
|MISRA |Motor Industry Software Reliability Association|
|NIT|FlexRay Network Idle Time|
|n/a|Not Applicable|
|OS|Operating System|
|PLL|Phase Locked Loop|
|POC |Protocol Operation Control (see [13] for details)|
|POCState|Actual CC internal state of the POC. This state might differ from vPOC!State in certain cases, e.g., after FREEZE command invocation (see [13] for details). |
|SchM |Autosar Module: Schedule Manager|
|SRS |System Requirements Specification|
|SW |SoftWare|
|SW-C |SoftWare Component|
|vPOC|Data structure provided from the CC to the host at the CHI, which contains the actual POC status of the CC (see [13] for details).|
|XML|Extensible Markup Language|

|Term:Definition:|
|:--|:--|
|absolute timer|An absolute timer is set to and triggered by an absolute global time of a FlexRay cluster. The FlexRay global time consists of a cycle and a macrotick offset|
|buffer|A buffer in the context of the Fr SWS describes a hardware transmit/receive resource, part of the FlexRay controller that is mapped to a FlexRay slot, channel, cycle for transmission or reception.|
|cluster|A communication system of multiple nodes connected to each other.|
|Macrotick|The macrotick represents the smallest unit of the global synchronized time of a FlexRay cluster.|
|Synchronized|A FlexRay CC is considered synchronized, to the FlexRay cluster connected to, as long as the following condition holds true: ((!vPOC!Freeze) && (vPOC!State == NORMAL_ACTIVE) || (vPOC!State == NORMAL_PASSIVE))|

## 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 ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[5] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[6] Specification of Platform Types, AUTOSAR_SWS_PlatformTypes.pdf
[7] Specification of FlexRay Interface, AUTOSAR_SWS_FlexRayInterface.pdf
[8] Specification of FlexRay Transceiver Driver, AUTOSAR_SWS_FlexRayTransceiver.pdf
[9] Specification of BSW Scheduler, AUTOSAR_SWS_BSW_Scheduler.pdf
[10] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[11] AUTOSAR Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[12] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
3.2 Relatedstandardsandnorms
[13] ISO 17458-2:2013, Road vehicles -- FlexRay communications system -- Part 2: Data link layer specification, 2013-01-21
[14] 2005, FlexRay Consortium, FlexRay Communication Systems Protocol Specification, Version 2.1 Revision A.

# 142 Specification of FlexRay AUTOSAR Transport Layer
##2 Acronyms and abbreviations
Following acronyms and abbreviations have a local scope only and therefore are not contained in the AUTOSAR glossary.

|Acronym|Description|
|:--|:--|
|Channel|A channel hosts a group of connections sharing the properties configurable by the parameters in section 10.2.|
|Connection|Communication path between two nodes (1:1) or one node and the network (1:n), characterized by the parameters in section 10.2.|
|Frame|Synonymous for N-PDU or L-SDU.|
|I-PDU|PDU of the AUTOSAR COM module; corresponds to an N-SDU of the FlexRay Transport Layer.|
|L-SDU|This is the SDU of the FlexRay Interface. It represents the same entity as the N- PDU, but from the FlexRay Interface’s point of view.|
|L-SDU ID|Unique identifier of an L-SDU; used by upper layers such as the FlexRay AUTOSAR Transport Layer module to interact with the FlexRay Interface.|
|Message|Synonymous for N-SDU or I-PDU.|
|N-PDU|This is a PDU of the FlexRay AUTOSAR Transport Layer, which is given to the FlexRay Interface for Sending. It consists of address information, protocol control information and the payload (N-SDU).|
|N-SDU|This is the SDU of the FlexRay AUTOSAR Transport Layer. In the AUTOSAR architecture, it is a set of data exchanged with the PDU Router.|
|N-SDU ID|Unique identifier of an SDU; used by upper layers such as the PDU Router to interact with the FlexRay Transport Layer.|
|PDU pool|Set of FlexRay N-PDUs that share the same size and same addressing type.|

|Abbreviation|Description|
|:--|:--|
|AF|Acknowledgement Frame|
|CF|Consecutive Frame|
|COM|AUTOSAR COM module|
|FC|Flow Control|
|FF|First Frame|
|Fr|FlexRay|
|PCI|Protocol Control Information|
|FrIf|FlexRay Interface|
|FrArTp|FlexRay AUTOSAR Transport Layer (derived from ISO 15765-2)|
|FrIsoTp|FlexRay ISO Transport Layer (ISO 10681-2)|
|FrTp|FlexRay Transport Layer|
|NM|Network Management|
|PDU|Protocol Data Unit|
|PduR|PDU Router|
|SDU|Service Data Unit|
|SF|Single Frame|
|XCP|Universal Calibration 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] General Requirements of Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Requirements on FlexRay AUTOSAR_SRS_FlexRay.pdf
[5] Specification of FlexRay Interface AUTOSAR_SWS_FlexRayInterface.pdf
[6] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[7] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[8] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[9] Specification of Platform Types AUTOSAR_SWS_PlatformTypes.pdf
[10] AUTOSAR Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[11] Specification of FlexRay ISO Transport Layer AUTOSAR_SWS_FlexRayISOTransportLayer.pdf
[12] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
###3.2 Relatedstandardsandnorms
[13] [14] 12 of 97
ISO 15765-2(2003-11-11), Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part2: Network layer services
ISO 10681-2, Road vehicles — Communication on FlexRay — Part2: Communication Layer Services
[15] FlexRay Communications System Protocol Specification Version 2.1

#141 Specification of Flash Test

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

|Acronym| Description|
|:--|:--|
|BSW|BasicSoftWare|
|PC|PreCompile|
|PB|PostBuild|
|DEM|Diagnostic Event Manager.|
|DET|Default Error Tracer.|
|MCU|Micro Controller Unit.|
|PLL|Phase Locked Loop.|
|ISR|Interrupt Service Routine.|

|Term|Description:|
|:--|:--|
|Background test|Background test is called periodically by a scheduler, and is interruptible. The test is split up over many scheduled tasks.|
|Foreground test|Foreground test is called via users call.|
|Flash cell|Smallest entity to be addressed, in this case bytes shall be used|
|Invariable memory|Invariable memory can be program flash, program SRAM, locked cache and ROM|
|Test block|Defined memory area to be tested in foreground and background mode.|
|Test interval|Interval of a complete Flash test in background mode|
|Test time|Time for partial test defined within one scheduled task.|
|Signature|Unique calculation result of the content of a specific memory block|
|Memory block|Defined memory area|
|Partial test|Test to be executed in one scheduler interval|
|Test Interval Id|Identifier of a test interval, which shall be incremented by each start of a new test interval|

## 3 Related documentation 3.1 Inputdocuments
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[5] Specification of MCU Driver AUTOSAR_SWS_MCUDriver.pdf
[6] Specification of ECU Configuration, AUTOSAR_TPS_ECUConfiguration.pdf
[7] Basic Software Module Description Template, AUTOSAR_TPS_BSWModuleDescriptionTemplate.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.