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
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 TSyn module takes for a given Time Base. Therefore a 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 (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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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