0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

Last updated at Posted at 2020-02-04

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.

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?