Autosar(19-11) list of reference, abbreviation and term.(1-47/303): English(40d)

Autosar Document

No. Number in the AUTOSAR document list

Autosar word count

https://qiita.com/kaizen_nagoya/items/0927727a94b157df2df8
Make list of reference, abbreviation and term.

term	description
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.(191-237/237): English(40)
https://qiita.com/kaizen_nagoya/items/2325b0156bc7fcf5a96d

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

Autosar list of reference, abbreviation and term.(95-140/237): English(40b)
https://qiita.com/kaizen_nagoya/items/dca9c66502dd2ae4b042

Autosar list of reference, abbreviation and term.(48-94/237): English(40c)
https://qiita.com/kaizen_nagoya/items/619a7a83cd153e31af18

47 Requirements on Security Management for Adaptive Platform

no abbreviations.

4 References

[1] Main Requirements AUTOSAR_RS_Main
[2] Explanation of Adaptive Platform Design AUTOSAR_EXP_PlatformDesign
[3] SoK: Eternal War in Memory
[4] Guidelines for the use of the C++14 language in critical and safety-related sys- tems
AUTOSAR_RS_CPP14Guidelines
[5] The SPARC Architectural Manual, Version 8 http://sparc.org/wp-content/uploads/2014/01/v8.pdf.gz
[6] OpenBSD-3.3 announcement, public release of WˆX http://www.openbsd.org/33.html
[7] Smashing The Stack For Fun And Profit http://phrack.org/issues/49/14.html
[8] The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)
[9] Jump-oriented Programming: A New Class of Code-reuse Attack
[10] On the Expressiveness of Return-into-libc Attacks
[11] Code-Pointer Integrity
[12] ARM Pointer Authentication
https://lwn.net/Articles/718888/
[13] PaX ASLR (Address Space Layout Randomization)
[14] Control-flow Integrity
[15] AMD64 Architecture Programmer’s Manual Volume 2: System Programming http://support.amd.com/TechDocs/24593.pdf
[16] PowerPC Architecture Book, Version 2.02 https://www.ibm.com/developerworks/systems/library/es-archguide-v2.html
[17] PowerPC Operating Environment Architecture Book III http://public.dhe.ibm.com/software/dw/library/es-ppcbook3.zip
[18] Linux Kernel, Summary of changes from v2.6.7 to v2.6.8 https://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.8
[19] PAX https://pax.grsecurity.net/docs/pax.txt
11 of 30 Document ID 881: AUTOSAR_RS_SecurityManagement — AUTOSAR CONFIDENTIAL —
Requirements on Security Management for Adaptive Platform AUTOSAR AP R19-11
[20] CPI LLVM on github https://github.com/cpi-llvm
[21] Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors
[22] Drammer: Deterministic Rowhammer Attacks on Mobile Platforms
[23] ANVIL: Software-Based Protection Against Next-Generation Rowhammer Attacks
[24] A seccomp overview https://lwn.net/Articles/656307/
[25] Frequently Asked Questions for FreeBSD 10.X and 11.X https://www.freebsd.org/doc/en/books/faq/security.html
[26] pledge(2) https://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2

46 Requirements on Safety Extensions

no abbreviations

##References
[1] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org
[2] Specifications of Safety Extensions AUTOSAR_TPS_SafetyExtensions
[3] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[4] Requirements on AUTOSAR Features AUTOSAR_RS_Features
[5] Methodology AUTOSAR_TR_Methodology

45

Requirements on SOME/IP Service Discovery Protocol
https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_RS_SOMEIPServiceDiscoveryProtocol.pdf

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the SOME/IP specification that are not included in the [2, AUTOSAR glossary].

Term	Description
Client	The ECU using the service instance of a server shall be called client in the context of this service instance.
Event	A uni-directional data transmission that is only invoked on changes or cyclically and is sent from the producer of data to the consumers.
Eventgroup	A logical grouping of events and notification events of fields inside a service in order to allow subscription
Field	A field does represent a status and thus has a valid value at all times on which getter, setter and notifier act upon.
Finding a service instance	Sending a SOME/IP-SD message in order to find a needed ser- vice instance.
Getter	A Request/Response call that allows read access to a field.
Method	A method, procedure, function, or subroutine that is called/in- voked.
Notification Event	An event message of the notifier of a field.
Notifier	Sends out event message with a new value on change of the value of the field.
Offering a service instance	An ECU implements an instance of a service and tells other ECUs using SOME/IP-SD that they may use it.
Server	The ECU offering a service instance shall be called server in the context of this service instance.
Service	A logical combination of zero or more methods, zero or more events, and zero or more fields.
Service Instance	Implementation of a service, which can exist more than once in the vehicle and more than once on an ECU
Setter	A Request/Response call that allows write access to a field.

Abbreviation / Acronym	Description
TTL	Time-to-Live

##5 References References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary

44 Requirements on SOME/IP Protocol

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the SOME/IP specification that are not included in the [2, AUTOSAR glossary].

Term	Description
Event	A uni-directional data transmission that is only invoked on changes or cyclically and is sent from the producer of data to the consumers.
Eventgroup	A logical grouping of events and notification events of fields inside a service in order to allow subscription
Field	A field does represent a status and thus has an valid value at all times on which getter, setter and notifier act upon.
Getter	A Request/Response call that allows read access to a field.
Method	A method, procedure, function, or subroutine that is called/in- voked.
Notification Event	An event message of the notifier of a field.
Notifier	Sends out event message with a new value on change of the value of the field.
Remote Procedure Call (RPC)	A method call from one ECU to another that is transmitted using messages
Service	A logical combination of zero or more methods, zero or more events, and zero or more fields.
Service Instance	Implementation of a service, which can exist more than once in the vehicle and more than once on an ECU
Setter	A Request/Response call that allows write access to a field.
Union	A data structure that dynamically assumes different data types.

Abbreviation / Acronym	Description
SOME/IP	Scalable service-Oriented MiddlewarE over IP.
TCP	Transmission Control Protocol.
UDP	User Datagram Protocol.

5 References References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] IEEE Standard for Floating-Point Arithmetic (IEEE Std 754-2008)

43 Requirements on Persistency

no acronyms and abbreviations

##6 References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Main Requirements AUTOSAR_RS_Main

42 Requirements on Operating System Interface

3 Acronyms and Abbreviations

Abbreviation / Acronym	Description
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.
Machine	see [2] AUTOSAR Glossary
Process	see [2] AUTOSAR Glossary
Functional Cluster	see [2] AUTOSAR Glossary

6 References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] IEEEStandardforInformationTechnology-StandardizedApplicationEnvironment Profile (AEP)-POSIX Realtime and Embedded Application Support https://standards.ieee.org/findstds/standard/1003.13-2003.html
[4] Standard for Information Technology–Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7 http://pubs.opengroup.org/onlinepubs/9699919799/
[5] Main Requirements AUTOSAR_RS_Main

41 Requirements on Methodology

1.2 Abbreviations

Abbreviation	Description
AP	Adaptive Platform
AUTOSAR	Automotive Open System Architecture
CP	Classic Platform
ECU	Electronic Control Unit
OEM	Original Equipment Manufacture
RTE	Runtime Environment
SIL	Safety Integrity Level (IEC61508 definition)
SWC	Software Component
VFB	Virtual Functional Bus

References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Main Requirements AUTOSAR_RS_Main

40 Requirements on Manifest Specification

no abbreviations

5 References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[3] Glossary AUTOSAR_TR_Glossary
[4] Main Requirements AUTOSAR_RS_Main

39 Main Requirements

no abbreviations

5 References [Glossary] Glossary,

AUTOSAR_TR_Glossary.pdf
[ISO 26262] Road vehicles — Functional safety — Part 1 to 9
[TPS_STDT] Standardization Template, AUTOSAR_TPS_StandardizationTemplate.pdf
[RS_ProjectObjectives] Project Objectives AUTOSAR_RS_ProjectObjectives.pdf

38 General Requirements specific to Adaptive Platform

file name is general but document name is specific to adaptive platform.

no acronyms and abbreviations

6 References

General Requirements specific to Adaptive Platform AUTOSAR AP R19-11
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Functional Cluster Shortnames AUTOSAR_TR_FunctionalClusterShortnames
[4] Camel case https://en.wikipedia.org/wiki/CamelCase
[5] Standard Template Library https://en.wikipedia.org/wiki/Standard_Template_Library
[6] Cpp Styleguide https://google.github.io/styleguide/cppguide.html#Type_Names
[7] C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
[8] Conservative use of noexcept in the Library http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf
[9] Guidelines for the use of the C++14 language in critical and safety-related sys- tems
AUTOSAR_RS_CPP14Guidelines
[10] Main Requirements AUTOSAR_RS_Main

37 Requirements on Debugging, Tracing and Profiling support of AUTOSAR Components

3 Acronyms and abbreviations

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

Abbreviation / Acronym	Description
ARTI	AUTOSAR Run Time Interface
OS	Operating System

6 References

[1] System Template AUTOSAR_TPS_SystemTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Main Requirements AUTOSAR_RS_Main

36 AUTOSAR Feature Model Exchange Format Requirements

no abbreviations

References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Software Process Engineering Meta-Model Specification http://www.omg.org/spec/SPEM/2.0/

35 Requirements on Execution Management

3 Acronyms and abbreviations

All technical terms used throughout this document – except the ones listed here – can be found in the official [3] AUTOSAR Glossary or [4] TPS Manifest Specification.

Term	Description
Process	A process is a loaded instance of an Executable to be executed on a Machine.
Self-terminating Process	A type of Process that self initiate termination procedure, please note that for a standard Process this procedure is initiated by Execution Management.
Execution Dependency	Dependencies between Executable instances can be config- ured to define a sequence for starting and terminating them.
Execution Management	The element of the AUTOSAR Adaptive Platform responsible for the ordered startup and shutdown of the AUTOSAR Adap- tive Platform and the Applications.
Identity and Access Management (IAM)	A Adaptive Platform Service within the AUTOSAR Adaptive Platform
State Management	The element of the Execution Management defining modes of operation for AUTOSAR Adaptive Platform. It allows flex- ible definition of functions which are active on the platform at any given time.
Function Group	A Function Group is a set of coherent Processes, which need to be controlled consistently. Depending on the state of the Function Group, Processes are started or terminated. Processes can belong to more than one Function Group State (but at exactly one Function Group). "MachineState" is a Function Group with a predefined name, which is mainly used to control Machine lifecycle and Processes of platform level Applications. Other Function Groups are sort of general purpose tools used (for example) to control Processes of user level Applications.
Function Group State	The state of a Function Group (except "MachineState"). It defines a set of active Applications for any certain situation. The set of Function Groups and their states is machine spe- cific and is deployed as part of the Machine Manifest.
Machine State	The state of Function Group "MachineState" with some predefined states (Startup/Shutdown/Restart).
Time Determinism	The results of a calculation are guaranteed to be available before a given deadline.
Data Determinism	The results of a calculation only depend on the input data and are reproducible, assuming a given initial internal state.
Full Determinism	Combination of Time and Data Determinism.
Communication Management	A Functional Cluster within the Adaptive Platform Foundation
Execution Manifest	Manifest file to configure execution of an Executable.
Machine Manifest	Manifest file to configure a Machine.
Operating System	Software responsible for managing Processes on a Machine and for providing an interface to hardware resources.
ResourceGroup	Configuration element to enable restrictions on resources uses by Adaptive Applications running in the group.
ExecutionClient	Adaptive Application interface to Execution Management.
DeterministicClient	Adaptive Application interface to Execution Management to support control of the process-internal cycle, a determin- istic worker pool, activation time stamps and random numbers.
Platform Health Management	A Functional Cluster within the Adaptive Platform Foundation
Recovery Action	Actions defined by the integrator to control Adaptive Application error recovery.
Process State	Lifecycle state of a Process
Service Instance Manifest	Manifest file to configure Service usage of an Adaptive Application.
Trusted Platform	An execution platform supporting a continuous chain of trust from boot through to application supporting authentication (that all code executed is from the claimed source) and integrity valida- tion (that prevents tampered code/data from being executed).
Adaptive Application	see [3] AUTOSAR Glossary
Application	see [3] AUTOSAR Glossary
AUTOSAR Adaptive Platform	see [3] AUTOSAR Glossary
Adaptive Platform Foundation	see [3] AUTOSAR Glossary
Manifest	see [3] AUTOSAR Glossary
Executable	see [3] AUTOSAR Glossary
Functional Cluster	see [3] AUTOSAR Glossary
Adaptive Platform Service	see [3] AUTOSAR Glossary
Machine	see [3] AUTOSAR Glossary
Service	see [3] AUTOSAR Glossary
Service Interface	see [3] AUTOSAR Glossary
Service Discovery	see [3] AUTOSAR Glossary

ABBREVIATION	Description
IAM	Identity and Access Management

6 References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Key words for use in RFCs to Indicate Requirement Levels http://www.ietf.org/rfc/rfc2119.txt
[3] Glossary AUTOSAR_TR_Glossary
[4] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[5] Requirements of State Management AUTOSAR_RS_StateManagement
[6] Main Requirements AUTOSAR_RS_Main

34 Requirements on ECU Resource Template

no abbreviations

References

[1] Specification of ECU Resource Template AUTOSAR_TPS_ECUResourceTemplate
[2] Requirements on ECU Configuration AUTOSAR_RS_ECUConfiguration
[3] System Template AUTOSAR_TPS_SystemTemplate
[4] Main Requirements AUTOSAR_RS_Main
[5] Methodology AUTOSAR_TR_Methodology
[6] Glossary AUTOSAR_TR_Glossary
[7] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[8] XML Schema Production Rules AUTOSAR_TPS_XMLSchemaProductionRules
[9] Requirements on Timing Extensions AUTOSAR_RS_TimingExtensions
[10] Requirements on AUTOSAR Features AUTOSAR_RS_Features

33 Requirements on ECU Configuration

2.3 Abbreviations

abbreviations	description
BSW	Basic Software
BSWMD	Basic Software Module Description
ECUC	ECU Configuration
SW-C	Software Component

References

[1] Methodology AUTOSAR_TR_Methodology
[2] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[4] Requirements on Runtime Environment AUTOSAR_SRS_RTE
[5] Glossary AUTOSAR_TR_Glossary
[6] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[7] XML Schema Production Rules AUTOSAR_TPS_XMLSchemaProductionRules
[8] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration
[9] Specification of ECU Configuration Parameters (XML) AUTOSAR_MOD_ECUConfigurationParameters
[10] Requirements on Standardization Template AUTOSAR_RS_StandardizationTemplate
[11] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
[12] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[13] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[14] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping

32 Requirements on E2E

3 Acronyms and Abbreviations

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

Acronym / Abbreviation	Description
E2E	End-to-End.
BER	Bit Error Rate - a rate of corrupted bits in a byte stream, e.g. 1e-5.

Term	Description
E2E Profile	A set of combined E2E measures as efficient solution for a par- ticular communication stack.

8 References

[1] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org
[2] System Template AUTOSAR_TPS_SystemTemplate
[3] Glossary AUTOSAR_TR_Glossary

31 Requirements on Diagnostics

2 Acronyms and Abbreviations

Abbreviation / Acronym	Description
CAN	Controller Area Network (communication bus)
Dem	Diagnostic Event Manager
DID	Diagnostic Identifier
DM	Diagnostic Management
DoIP	Diagnostic over IP - transport protocol for diagnostic services standardized as ISO 13400
DTC	Diagnostic Trouble Code
ECU	Electronic Control Unit
IDL	Interface Description Language
OBD	On-board Diagnostic (standardized as ISO 15031)
RTE	Runtime Environment
SA	Source Address (diagnostics address of the tester)
SID	Service Identifier (hexa number to uniquely identify UDS ser- vices)
SWC	Software Component (could refer either to Classic Platform SW- C or to Adaptive Platform SW-C)
TA	Target Address (diagnostic address of the ECU)
UDS	Unified Diagnostic Specification standardized as ISO 14229

Term	Description
SID 0x22	for Read Data by Identifier service
SID 0x2E	for Write to Non-Volatile memory service

6 References

[1] Main Requirements AUTOSAR_RS_Main

6.1 Deliverables of AUTOSAR

1.General Requirements of Basic Software Modules: AUTOSAR_SRS_BSWGeneral.pdf
2.Specification of the Virtual Functional Bus : AUTOSAR_EXP_VFB.pdf
3.Software Standardization Template : AUTOSAR_TPS_StandardizationTemplate.pdf
###6.2 Related standards and norms
####6.2.1 ITEA-EAST

1. D1.5-General Architecture; ITEAEAST-EEA, Version 1.0; chapter 3, page 72 et seq.
2. D2.1-Embedded Basic Software Structure Requirements; ITEAEAST-EEA, Ver- sion 1.0 or higher
3. D2.2-Description of existing solutions; ITEA/EAST-EEA, Version 1.0 or higher.
   73 of 74 Document ID 4: AUTOSAR_RS_Diagnostics — AUTOSAR CONFIDENTIAL —

6.2.2 ISO

1. ISO 14229-1 Unified diagnostic services (UDS) Part 1: Specification and Re- quirements (v.2013)
2. ISO 15031-5 Communication between vehicle and external equipment for emis- sions related diagnostics Part 5: Emissions related diagnostic services (2005-01- 13)
3. ISO 15765-3 Diagnostics on controller area network (CAN) Part 3: Implementa- tion of unified diagnostic services (UDS on CAN) (2004-10-06)
4. ISO 15765-4 Diagnostics on controller area network (CAN) Part 4: Requirements for emissions-related systems (2005-01-04)

30 Requirements on Diagnostic Extract Template

no abbreviations

References

Requirements on Diagnostic Extract Template AUTOSAR CP R19-11
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Re- lease 2006-12)
http://www.iso.org
[3] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager
[4] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager
[5] Motor Vehicle Pollution Control Devices http://www.iso.org
[6] Specification of Function Inhibition Manager AUTOSAR_SWS_FunctionInhibitionManager
[7] Road vehicles – Communication between vehicle and external equipment for emission-related diagnostic – Part 5: Emission-related diagnostic services. http://www.iso.org

ISO 14229-1 UDS
ISO 29464:2017 Cleaning of air and other gases — Terminology
ISO 15031 Communication between vehicle and external equipment for emission-related diagnostic

29 Requirements on Cryptography

no abbreviations

##5 References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Requirements on AUTOSAR Features AUTOSAR_RS_Features

28 Requirements on Communication Management

3 Acronyms and abbreviations

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

Terms	Description
Fully qualified service ID	A fully qualified name of a service used as a system-wide unique identifier, e.g. ’com.someOEM.adas.collisionwarner’.
Data ID	A unique identifier of an instance of data transmitted. In case of events, this maps to a specific instance of an event.

6 References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Key words for use in RFCs to Indicate Requirement Levels http://www.ietf.org/rfc/rfc2119.txt
[3] Glossary AUTOSAR_TR_Glossary
[4] Requirements on E2E AUTOSAR_RS_E2E
[5] REST: Architectural Styles and the Design of Network-based Software Architec- tures
[6] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax
[7] RFC 6455, The WebSocket Protocol
[8] RFC 2616, Hypertext Transfer Protocol – HTTP/1.1
[9] RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format
[10] Main Requirements AUTOSAR_RS_Main

27 Guidelines for the use of the C++14 language in critical and

safety-related systems

no abbreviations.

7 References Bibliography

Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 19-03
ISO/IEC 14882:2003, The C++ Standard Incorporating Technical Corrigendum 1, International Organization for Standardization, 2003.
ISO/IEC 14882:2011, ISO International Standard ISO/IEC 14882:2011(E) - Programming Language C++, International Organization of Standardization, 2011.
ISO/IEC 14882:2014, ISO International Standard ISO/IEC 14882:2014(E) - Programming Language C++, International Organization for Standardization, 2016.
ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.
ISO 26262-6, Road vehicles - Functional safety - Part 6: Product development at the software level, International Organization for Standardization, 2011.
ISO 26262-8, Road vehicles - Functional safety - Part 8: Supporting processes, International Organization for Standardization, 2011.
MISRA C++:2008 Guidelines for the use of the C++ language in critical systems, The Motor Industry Software Reliability Association, 2008.
Joint Strike Fighter Air Vehicle C++ Coding Standards for the System Development and Demonstration Program, Document Number 2RDU00001 Rev C, Lockheed Martin Corporation, 2005.
High Integrity C++ Coding Standard Version 4.0, Programming Research Ltd, 2013.
Software Engineering Institute CERT C++ Coding Standard, Software Engineering Institute Division at Carnegie Mellon University, 2016.
Bjarne Stroustrup, Herb Sutter, C++ Core Guidelines, 2017.
Google C++ Style Guide, Google, 2017.
Scott Meyers, Effective Modern C++, ISBN: 978-1-491-90399-5, O’Reilly, 2015.
Bjarne Stroustrup, The C++ Programming Language, Fourth Edition, ISBN: 978- 0-321-56384-2, Addison-Wesley, 2013.
Joshua Bloch, Effective Java, Second Edition, ISBN: 978-0321356680, Addison- Wesley, 2008
cppreference.com, online reference for the C and C++ languages and standard libraries, 2017
stackoverflow.com, community of programmers, 2017
open-std.org, site holding a number of web pages for groups producing open standards, 2017
383 of 510 Document ID 839: AUTOSAR_RS_CPP14Guidelines — AUTOSAR CONFIDENTIAL —
Guidelines for the use of the C++14 language in critical and safety-related systems AUTOSAR AP Release 19-03
IEC 61508-3, Functional safety of electrical/electronic/programmable electronic safety-related systems – Annex C, Overview of techniques and measures for achieving software safety integrity, International Electrotechnical Commission, 2010.

26 Requirements on Basic Software Module Description Template

2.3 Abbreviations

abbreviations	description
BSW	Basic Software
BSWMD	Basic Software Module Description
BSWMD-T	Basic Software Module Description Template
ECUC	ECU Configuration Values [11]
ECUC-T	ECU Configuration Template [11]
ICS	Implementation Conformance Statement
StMD	Standardized Module Definition [11]
SWC	Software Component Description
SWC-T	Software Component Template
VSMD	Vendor-Specific Module Definition [11]

term	description
ECUC Parameter Definition	ECU Configuration Parameter Definition [11]

References

[1] Methodology AUTOSAR_TR_Methodology
[2] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[3] Meta Model-generated XML Schema AUTOSAR_MMOD_XMLSchema
[4] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[5] XML Schema Production Rules AUTOSAR_TPS_XMLSchemaProductionRules
[6] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[7] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[8] Requirements on ECU Configuration AUTOSAR_RS_ECUConfiguration
[9] Requirements on Runtime Environment AUTOSAR_SRS_RTE
[10] Glossary AUTOSAR_TR_Glossary
[11] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration
[12] Requirements on Standardization Template AUTOSAR_RS_StandardizationTemplate
[13] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping
[14] Requirements on Software Component Template AUTOSAR_RS_SoftwareComponentTemplate
[15] Specification of RTE Software AUTOSAR_SWS_RTE

25 Time Synchronization Protocol Specification

4 4.1
Definition of terms and acronyms Acronyms and abbreviations

Abbreviation / Acronym	Description
(G)TD	(Global) Time Domain
(G)TM	(Global)Time Master
TSyn	A bus specific Time Synchronization module
AVB	Audio Video Bridging
BMCA	Best Master Clock Algorithm
CID	Company ID (IEEE)
CRC	Cyclic Redundancy Checksum
ETH	Ethernet
EthTSyn	Time Synchronization Provider module for Ethernet
GM(C)	Grand Master (Clock)
OFS	Offset synchronization
Pdelay	Propagation / path delay as given in IEEE 802.1AS
Pdelay_Req	Propagation / path delay request message
Pdelay_Resp	Propagation / path delay response message
Pdelay_Resp_Follow_Up	Propagation / path delay Follow-Up message
PDU	Protocol Data Unit
PTP	Precision Time Protocol
StbM	Synchronized Time-Base Manager
Timesync	Time Synchronization
Sync	Time synchronization message (Sync)
TG	Time Gateway
TLV	Type, Length, Value field (acc. to IEEE 802.1AS)
TS	Time Slave
TSD	Time Sub-domain
VLAN	Virtual Local Area Network

Term	Description
Debounce Time	Minimum gap between two Tx messages with the same PDU.
Follow_Up	Time transport message (Follow-Up)

8 References References

Time Synchronization Protocol Specification AUTOSAR FO R19-11
[1] IEEE Standard 802.1AS-30 http://standards.ieee.org/getieee802/download/802.1AS-2011.pdf
[2] IEEE 802.1Q-2011 - IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks

24 SOME/IP Service Discovery Protocol Specification

3 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the SOME/IP specification that are not included in the [1, AUTOSAR glossary].

Abbreviation / Acronym	Description
RPC	Remote Procedure Call

term	Description
Method	a method, procedure, function, or subroutine that is called/invoked.
Parameters	input, output, or input/output arguments of a method or an event
Remote Procedure Call (RPC)	a method call from one ECU to another that is transmitted using messages
Request	a message of the client to the server invoking a method
Response	a message of the server to the client transporting results of a method invocation
Request/Response communication	a RPC that consists of request and response
Fire & Forget communication	a RPC call that consists only of a request message
Field	a field does represent a status and thus has a valid value at all times on which getter, setter and notfier act upon.
Getter	a Request/Response call that allows read access to a field.
Setter	a Request/Response call that allows write access to a field.
Notifier	sends out event message with a new value on change of the value of the field.
Service	a logical combination of zero or more methods, zero or more events, and zero or more fields (empty service is allowed, e.g. for announcing non-SOME/IP services in SOME/IP-SD)
Eventgroup	a logical grouping of events and notification events of fields inside a service in order to allow subscription
Service Interface	the formal specification of the service including its methods, events, and fields
Service Instance	software implementation of the service interface, which can exist more than once in the vehicle and more than once on an ECU
Server	The ECU offering a service instance shall be called server in the context of this service instance.
Client	The ECU using the service instance of a server shall be called client in the context of this service instance.
Union or Variant	a data structure that dynamically assumes different data types.
Offering a service instance	that one ECU implements an instance of a service and tells other ECUs using SOME/IP-SD that they may use it.
Finding a service instance	to send a SOME/IP-SD message in order to find a needed service instance.
Event	A uni-directional data transmission that is only invoked on changes or cyclically and is sent from the producer of data to the consumers. One event could even be both sent cyclically and spontaneously on change. This is completely in the responsibility of the sending application because the receiver has no means at all to distinguish between those two.
Notification Event	an event message the notifier of a field sends. The message of such a notifier cannot be distinguished from the event message; therefore, when refering to the message of an event, this shall also be true for the messages of notifiers of fields.
Requiring a service instance	to send a SOME/IP-SD message to the ECU implementing the required service instance with the meaning that this service in- stance is needed by the other ECU. This may be also sent if the service instance is not running; thus, was not offered yet.
Releasing a service instance	to sent a SOME/IP-SD message to the ECU hosting this service instances with the meaning that the service instance is no longer needed.
Server-Service-Instance-Entry	The configuration and required data of a service instance the local ECU offers, is called Server-Service-Instance-Entry at the ECU offering this service (Server).
Client-Service-Instance-Entry	The configuration and required data of a service instance another ECU offers, is called Client-Service-Instance-Entry at the ECU using this service (Client)
Publishing an eventgroup	to offer an eventgroup of a service instance to other ECUs using a SOME/IP-SD message
Subscribing an eventgroup	to require an eventgroup of a service instance using a SOME/IP- SD message

7 References References

[1] Glossary AUTOSAR_TR_Glossary
[2] SOME/IP Protocol Specification AUTOSAR_PRS_SOMEIPProtocol

23 Requirements on SOME/IP Protocol

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the SOME/IP specification that are not included in the [2, AUTOSAR glossary].

Term	Description
Event	A uni-directional data transmission that is only invoked on changes or cyclically and is sent from the producer of data to the consumers.
Eventgroup	A logical grouping of events and notification events of fields inside a service in order to allow subscription
Field	A field does represent a status and thus has an valid value at all times on which getter, setter and notifier act upon.
Getter	A Request/Response call that allows read access to a field.
Method	A method, procedure, function, or subroutine that is called/invoked.
Notification Event	An event message of the notifier of a field.
Notifier	Sends out event message with a new value on change of the value of the field.
Remote Procedure Call (RPC)	A method call from one ECU to another that is transmitted using messages
Service	A logical combination of zero or more methods, zero or more events, and zero or more fields.
Service Instance	Implementation of a service, which can exist more than once in the vehicle and more than once on an ECU
Setter	A Request/Response call that allows write access to a field.
SOME/IP	calable service-Oriented MiddlewarE over IP.
Union	A data structure that dynamically assumes different data types.

Abbreviation / Acronym	Description
RPC	Remote Procedure Call
TCP	Transmission Control Protocol.
UDP	User Datagram Protocol.

References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] IEEE Standard for Floating-Point Arithmetic (IEEE Std 754-2008)

22 Requirements on AUTOSAR Network Management

3 Acronyms and abbreviations

Abbreviation / Acronym	Description
EIRA	External and Internal Requests Aggregated
ERA	External Requests Aggregated
NM	Network Management
PN	Partial Network
PNI	Partial Network Information

Term	Description
NM Message	Refers to the payload transmitted on the bus. It contains the User Data as well as the Control Bit Vector and may contain the Source Node Identifier.
NM Node	A ECU (electornic controll unit) which is connected to one or more NM clusters
NM cluster	Set of NM nodes coordinated with the use of the NM algorithm.
NM instance	A NM instance represents the current status of one NM cluster in- side one NM node

6 References

[1] System Template AUTOSAR_TPS_SystemTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture

21 Requirements on Log and Trace

3 Acronyms and abbreviations

ECU ID ECU ID is the name of each ECU.

Term	Description
Log and trace message	A log and trace message contains all data and options to specify a log and trace event in a software.
User	The user of LT is the programmer of the software, which uses the LT API to generate log and trace messages.
Log	The user generates log messages on demand. Each time the user wants to show some information about state changes or value changes, he adds an API call to LT.
Trace	Trace messages can be generated by instrumentation of the code (e.g. VFB traces). The instrumented code calls the API of LT.
Session ID	Session ID is the identification number of a log or trace session. If an Application is instantiated several times the log sessions get a new Session ID. A Application can have several log or trace sessions. A BSW module uses the module-number as Session ID.
Application ID	Application ID is a short name of the Application/BSW module. It identifies the Application/BSW module in the log and trace message.
Context ID	Context ID is a user defined ID to group log and trace messages produced by an Application/BSW module to distinguish functionality. Each Application ID can own several Context IDs. Context ID’s are grouped by Application ID’s. Context IDs shall be unique within an Application ID. The identification of the source of a log and trace message is done with a pair of Application ID and Context ID.
Message ID	Messaged ID is the ID to characterize the information, which is transported by the message itself. A Message ID identifies a log or trace message uniquely. It can be used for identifying the source (in source code) of a message and it can be used for characterizing the payload of a message.
Log and trace level	A log level defines a classification for the severity grade of a log message. The trace status provides information if a trace message should be send.
Time	Each log and trace message may contain a time attribute. The time attribute is a free defined time-value. It is the time since the start of the ECU.
External client	An external client is a tool, which can be run on a PC or another ECU, which is connected to LT over DCM or over the LT communication module.

6 References

[1] Requirements on AUTOSAR Features AUTOSAR_RS_Features.pdf
[2] Specification of RTE, AUTOSAR_SWS_RTE.pdf
[3] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf.pdf
[4] Specification of Development Error Trace, AUTOSAR_SWS_DevelopmentErrorTracer.pdf
[5] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

20 E2E Protocol Specification

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the Communica- tion Management that are not included in the [1, AUTOSAR glossary].

Abbreviation / Acronym	Description
Data ID	An identifier that uniquely identifies the message / data element / data.
Repetition	The same message was received more than once
Loss	A message was not received
Delay	A message was received later than expected
Insertion	Unexpected information or an extra message was inserted
Masquerade	non-authentic information is accepted as authentic information by a receiver.
Incorrect addressing	information is accepted from an incorrect sender or by an incor- rect receiver.
Corruption	A communication fault, which changes information
Asymmetric information	Receivers do receive different information from the same sender
Subset	Information from a sender received by only a subset of the re- ceivers
Blocking	Blocking access to a communication channel

3 Related documentation 3.1 Input documents & related standards and norms

[1] Glossary AUTOSAR_TR_Glossary
[2] Specification of CRC Routines AUTOSAR_SWS_CRCLibrary
[3]Specification of SW-C End-to-End Communication Protection Library AUTOSAR_SWS_E2ELibrary

3.2 Related specification

1. SAE-J1850 8-bit CRC CCITT-FALSE 16-bit CRC. Refer to:
2. ITU-T Recommendation X.25 (1096) (Previously „CCITT Recommendation”) SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATION
   Public data networks - Interfaces
   Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit
   Section 2.2.7.4 „Frame Check Sequence (FCS) field” and Appendix I „Examples of data link layer transmitted bit patterns by the DCE and the DTE” http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X. 25-199610-I!!PDF-E&type=items
3. IEEE 802.3 Ethernet 32-bit CRC
4. 32-Bit Cyclic Redundancy Codes for Internet Applications [Koopman 2002]
5. Collection and evaluation of CRC polynomials by Philip Koopman, Carnegie Mellon University https://users.ece.cmu.edu/~koopman/crc/

19 Explanation of Sensor Interfaces

2 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the explanation of ara::adi.

Abbreviation / Acronym	Description
AD	Automated Driving
ADI	Automated Driving Interfaces
AEB	Autonomous Emergency Braking
HiL	Hardware in the Loop
ISO	International Organization for Standardization
LIDAR	LIght Detection And Ranging
MiL	Model in the Loop
OEM	Original Equipment Manufacturer
OSI	Open Simulation Interface
RADAR	RAdio Detection And Ranging
SAE	Society of Automotive Engineers
USS	UltraSonic Sensor
XiL	...(X) in the Loop, such as HIL, SIL

Terms	Description
Car2X	Car-to-X-Communication is the generic term for various commu- nication technologies in automotive, including car-to-car (C2C) and car-to-infrastructure (C2I) communication. The information is either transmitted directly between vehicles via IEEE 802.11p, between car and roadside infrastructure or by using existing mo- bile networks.
Fusion Unit	A fusion unit within ADI specification is an application executed on an AP processor which combines different sensor information into one environmental model. This includes sensor time syn- chronization, object tracking, false alarm reduction and accuracy improvement.
Smart Sensor	A Smart Sensor within ADI specification is a sensor which inter- prets the raw / received data into object descriptions by internal processing. This includes both: sensors which perform process- ing over time (tracking / object list) and sensors which only pro- vide single timeframe data (discrete / detection list).

no references

p.6
https://github.com/OpenSimulationInterface/open-simulation-interface

p.7
The Open Simulation Interface and the Autosar ADI will support the ISO 23150.

18 Safety Use Case Example

7 Abbreviation/Glossary

Abbreviation	Translation (German)	Explanation/Comment
ADC		Analog-Digital Converter
ASIL		Automotive Safety Integrity Level
BCU		Body Control Unit
BSW		Basic Software Components
CAN		Controller Area Network
DRL	German “Tagfahrlicht”	Daytime Running Light
DIO		Digital Input/Output
ECU		Electronic Control Unit
FLM		Front Light Management
FS		Functional Safety
FSC		Functional Safety Concept
FTT	German “Fehlertoleranzzeit"	Fault Tolerance Time
HWA		Hardware Abstraction
HW		Hardware
LB	German “Abblendlicht”	The Function Low Beam
LS		Light Switch
oc/sc		Open circuit/ Short circuit
OEM		Original Equipment Manufacturer
OS		Operating System
QM		Quality Management
RTE		Runtime Environment
SPI		Serial Peripheral Interface
SWC		Software Component
VFB		Virtual Function Bus
L&R	left and right

Term	Translation (German)	Explanation/Comment
Head Light	German “Scheinwerfer”	The physical part of head lights
High Beam		German “Aufblendlicht/Fernlicht”The Function High Beam

8 References

[1] ISO26262 International Standard, First edition 2011-11-15 [2] Layered Software Architecture
[3] Overview of Functional Safety Measures in AUTOSAR
[4] Guide to BSW Distribution

17 Explanation of Adaptive Platform Design

no abbreviations

19 References

[1] Glossary, AUTOSAR_TR_Glossary.pdf.
[2] Main Requirement, AUTOSAR_RS_Main.pdf.
[3] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology.pdf.
[4] FCDesign IAM, AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf.
[5] Design guidelines for using parallel processing technologies on Adaptive Platform, AUTOSAR_EXP_ParallelProcessingGuidelines.pdf.
[6] P. Kruchten, “Architectural Blueprints—The “4+ 1” View Model of Software Architecture,” IEEE Software, vol. 12, no. 6, pp. 42-50, November 1995.

16 Design guidelines for using parallel processing technologies on Adaptive Platform

Abbreviation / Acronym	Description
AA	Adaptive Application
ADAS	Autonomous Driving and Assistance System AP AUTOSAR Adaptive Platform
ARA	AUTOSAR Run-time for Applications
SOA	Service-Oriented Architecture
DFP	Data-Flow Processor
GPU	Graphical Processing Unit
FPGA	Field Programmable Gate Array)
GPGPU	General Purpose GPU
DFP	Data Flow Processor),
TLP	Task Level Parallelism
DLP	Data Level Parallelism
PLP	Pipeline Level Parallelism
SIMD	Single Instruction Multiple Data
MIMD	Multiple Instruction Multiple Data
VLIW	Very Long Instruction Word
MTAPI	multicore API
HLS	High Level Synthesis
AMP	Accelerated Massive Parallelism

3

programming language like OpenCL , and even various message passing APIs like
MPI4

1 http://www.openmp.org/
2 https://www.threadingbuildingblocks.org/
3 https://jp.khronos.org/opencl
4 http://www.mcs.anl.gov/research/projects/mpi/
5 MTAPI The Multicore Association http://www.multicore-association.org/workgroup/mtapi.php
6 HLS,High Level Synthesis
7 OpenCV http://opencv.org/
8OpenVX https://www.khronos.org/openvx/
9 AMP http://download.microsoft.com/download/4/0/E/40EA02D8-23A7-4BD2-AD3A- 0BFFFB640F28/CppAMPLanguageAndProgrammingModel.pdf
10 SYCL https://www.khronos.org/sycl

5 References

Design guidelines for using parallel processing technologies on Adaptive Platform AUTOSAR AP R19-11
[1] Glossary, AUTOSAR_TR_Glossary.pdf.
[2] Main Requirement, AUTOSAR_RS_Main.pdf.
[3] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology.pdf.
[4] Explanations of Adaptive Platform Design, AUTOSAR_EXP_PlatformDesign.pdf.
[5] Specification of Execution Management, AUTOSAR_SWS_ExecutionManagement.pdf.

15 NV Data Handling Guideline

2 Acronyms and abbreviations

Term	Description
NVRAM Block	The NVRAM Block is the entire structure, which is needed to administrate and to store a block of NV data.
NV Block	The NV Block is a Basic Storage Object. It represents the part of a “NVRAM Block” which resides in the NV memory
RAM Block	The RAM Block is a Basic Storage Object. It represents the part of a “NVRAM Block” which resides in the RAM.
RAM Mirror	RAM mirrors are NvM internal buffer used for operations that read and write the RAM block of NVRAM blocks with NvMBlockUseSyncMechanism set TRUE.
ROM Block	The ROM Block is a Basic Storage Object. It represents the part of a “NVRAM Block” which resides in the ROM.

Abbreviation / Acronym	Description
NvM	NVRAM Manager
NV	Non-volatile
NVRAM	Non-volatile Random Access Memory
ROM	Read-Only Memory
RTE	Runtime Environment
SW-C	Software Component

3 Related documentation 3.1 Inputdocuments

[1] AUTOSAR Specification for Runtime Environment AUTOSAR_SWS_RTE.pdf
[2] AUTOSAR Template Specification of Software Component AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[3] AUTOSAR Specification for NVRAM Manager AUTOSAR_SWS_NVRAMManager.pdf
[4] AUTOSAR Guide on Mode Management AUTOSAR_EXP_ModeManagementGuide.pdf

14 Guide to Mode Management

5.1 Technical Terms

All technical terms used throughout this document – except the ones listed here – can be found in the official AUTOSAR glossary [6] or the Software Component Template Specification [1].

Term	Description
mode	A Mode is a certain set of states of the various state machines (not only of the ECU State Manager) that are running in the ve- hicle and are relevant to a particular entity, an application or the whole vehicle
state	States are internal to their respective BSW component and thus not visible to the application. So they are only used by the BSW’s internal state machine. The States inside the ECU State Man- ager build the phases and therefore handle the modes.
phase	A logical or temporal assembly of ECU Manager’s actions and events, e.g. STARTUP, UP, SHUTDOWN, SLEEP, etc. Phases can consist of Sub-Phases which are often called Sequences if they above all exist to group sequences of executed actions into logical units. Phases in this context are not the phases of the AUTOSAR Methodology.
mode switch port	The port for receiving (or sending) a mode switch notification. For this purpose, a mode switch portis typed by a Mod- eSwitchInterface.
mode request interface	A AUTOSAR SenderReceiverInterfaces, which carries the requested mode in a VariableDataPrototype..
mode user	An AUTOSAR SW-C or AUTOSAR Basic Software Module that depends on modes by ModeDisablingDependency, SwcModeSwitchEvent, BswModeSwitchEvent, or simply by reading the current state of a mode is called a mode user. A mode user is defined by having a require mode switch port or a requiredModeGroup ModeDeclarationGroupProto- type. See also section 2.
mode manager	Entering and leaving modes is initiated by a mode manager. A mode manager is defined by having a provide mode switch port or a providedModeGroup ModeDeclarationGroup- Prototype. A mode manager might be either an appli- cation mode manager or a Basic Software Module that provides a service including mode switches, like the ECU State Manager. See also section 2.2.
application mode manager	An application mode manager is a AUTOSAR software- component that provides the service of switching modes. The modes of a application mode manager do not have to be standardized.
mode request	The communication of a mode request from the mode user to the mode manager using either the SenderReceiverInter- face is called a mode request.
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 ModeDec- larationGroupPrototype is called mode switch noti- fication.
mode machine instance	The instances of mode machines or ModeDeclarationGroups are defined by the ModeDeclarationGroupPrototypes of the mode manager Since a mode switch is not executed instantaneously, the RTE or Basic Software Scheduler has to maintain it’s own states. For each mode managers ModeDeclarationGroupPrototype, RTE or Basic Software Scheduler has one state machine. This state machine is called mode machine instance. For all mode users of the same mode managers ModeDeclara- tionGroupPrototype RTE and Basic Software Scheduler uses the same mode machine instance. See also section 2.2.
common mode machine instance	A “common mode machine instance” is a special “mode machine instance” shared by BSW Modules and SW-Cs: The RTE Gener- atorcreatesonlyonemode machine instanceifaModeDec- larationGroupPrototype instantiated in a port of a software- component is synchronized synchronizedModeGroup of a
Mode Disabling Dependency	An RTEEvent and BswEvent that starts a RunnableEntity respectively a Basic Software Schedulable Entity can contain a disabledMode or disabledInMode association which references a ModeDeclaration. This association is called ModeDisablingDependency in this document.
mode disabling dependent ExecutableEntity	A mode disabling dependent RunnableEntity or a Ba- sic Software Schedulable Entity is triggered by an RTEEvent respectively a BswEvent with a ModeDis- ablingDependency. RTE and Basic Software Scheduler pre- vent the start of those RunnableEntity or Basic Software Schedulable Entity by the RTEEvent / BswEvent, when the corresponding mode disabling is active. See also section 2.2.
mode disabling	When a ‘mode disabling’ is active, RTE and Basic Software Scheduler disables the start of mode 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 2.2.
OnEntry ExecutableEntity	A Runnable Entity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchEvent respec- tively a BswModeSwitchEvent with ModeActivationKind ‘entry’ is triggered on entering the mode. It is called OnEntry ExecutableEntity. See also section 2.2.
OnExit ExecutableEntity	A RunnableEntity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchEvent respec- tively a BswModeSwitchEvent with ModeActivationKind ‘exit’ is triggered on exiting the mode. It is called OnExit Exe- cutableEntity. See also section 2.2.
OnTransition ExecutableEntity	A RunnableEntity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchEvent respec- tively a BswModeSwitchEvent with ModeActivationKind ‘transition’ is triggered on a transition between the two specified modes. It is called OnTransition ExecutableEntity. See also section 2.2.
mode switch acknowledge Exe- cutableEntity	A RunnableEntity or a Basic Software Schedulable Entity that is triggered by a SwcModeSwitchedAckEvent re- spectively a BswModeSwitchedAckEvent connected to the mode manager’s ModeDeclarationGroupPrototype. It is called mode switch acknowledge ExecutableEntity. See also section 2.2.
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.
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 acti- vated, when the timer expires, and for a data received event, the runnable is activated when the data is received by the RTE.
Basic Software Schedulable En- tity activation	The activation of a Basic Software Schedulable Entity is defined as the activation of the task that contains the Basic Software Schedulable Entity and eventually in- cludes setting a flag that tells the glue code in the task which Basic Software Schedulable Entity is to be executed.
Runnable start	A runnable is started by the calling the C-function that imple- ments the runnable from within a started task.
Basic Software Schedulable Entity start	A Basic Software Schedulable Entity is started by the calling the C-function that implements the Basic Software Schedulable Entity from within a started task.
Trigger Source	A Trigger Source administrate the particular Trigger and informsthe RTE or Basic Software Scheduler if the Trig-ger is raised. A Trigger Source has dedicated provide trigger ports or / and releasedTrigger Triggers to communicate to the Trigger Sinks.
Trigger Sink	A Trigger Sink relies on the activation of Runnable Entitiesor Basic Software Schedulable Entitiesifapar- ticular Trigger is raised. A Trigger Sink has a dedicated re- quire trigger ports or / and requiredTrigger Triggers to communicate to the Trigger Sources.
Trigger port	A PortPrototype which is typed by an TriggerInterface
triggered ExecutableEntity	A Runnable Entity or a Basic Software Schedulable Entity that is triggered at least by one ExternalTrigger Occurred Event / Bsw External Trigger Occurred Event or Internal Trigger Occurred Event / Bsw Internal Trigger Occurred Event. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE or Basic Software Scheduler as a directfunction call of the triggered Executable Entitybythe triggering ExecutableEntity.
triggered runnable	A Runnable Entity that is triggered at least by one External Trigger Occurred Event or Internal Trigger Occurred Event. In particular cases, the Trigger Event Communication or the Inter Runnable Triggering is implemented by RTE as a direct function call of the triggered runnable by the triggering runnable.
triggered Basic Software Schedulable Entity	A Basic Software Schedulable Entity that is triggered at least by one BswExternalTriggerOccurredEvent or BswInternalTriggerOccurredEvent. In particular cases, The Trigger Event Communication or the Inter Basic Software Schedulable Entity Triggering is implemented by Basic Software Scheduler as a direct functioncallofthetriggered Executable Entity by the triggering Executable Entity.
execution-instance	An execution-instance of a ExecutableEntity is one instance or call context of an ExecutableEntity with respect to con- current execution.
inter-ECU communication	The communication between ECUs, typically using COM is called inter-ECUcommunication in this document.
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 typically involves 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.
intra-partition 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.
intra-ECU communication	The communication within one ECU is called intra-ECU communication in this document. It is a super set of inter-parti- tion communication and intra-partition communication.

References

[1] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[2] Meta Model AUTOSAR_MMOD_MetaModel
[3] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[4] Specification of Basic Software Mode Manager AUTOSAR_SWS_BSWModeManager
[5] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager
[6] Glossary AUTOSAR_TR_Glossary

13 Macro Encapsulation of Interpolation Calls

1 Acronyms and abbreviations

Abbreviation / Acronym	Description
DEM	Diagnostic Event Manager
DET	Default Error Tracer

2 Related documentation 2.1 Input documents

[1] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[4] AUTOSAR Methodology AUTOSAR_TR_Methodology.pdf
[5] Requirements on Software Component Template AUTOSAR_RS_SoftwareComponentTemplate.pdf
2.2 Related specification
[1] Specification of Fixed Point Interpolation Routines AUTOSAR_SWS_IFXLibrary.pdf
[2] Specification of Floating Point Interpolation Routines AUTOSAR_SWS_IFLLibrary.pdf
[3] Specification of Run Time Environment AUTOSAR_SWS_RTE.pdf

12 Layered Software Architecture

These are presentations, are not text documents.

Term	description
SDU	SDU is the abbreviation of “Service Data Unit”. It is the data passed by an upper layer, with the request to transmit the data. It is as well the data which is extracted after reception by the lower layer and passed to the upper layer. A SDU is part of a PDU.
PCI	PCI is the abbreviation of “Protocol Control Information”. This Information is needed to pass a SDU from one instance of a specific protocol layer to another instance. E.g. it contains source and target information. The PCI is added by a protocol layer on the transmission side and is removed again on the receiving side.
PDU	PDU is the abbreviation of “Protocol Data Unit”. The PDU contains SDU and PCI. On the transmission side the PDU is passed from the upper layer to the lower layer, which interprets this PDU as its SDU.

abbreviations	description
SDU	Service Data Unit
PCI	Protocol Control Information
PDU	Protocol Data Unit

11 Explanation of Interrupt Handling within AUTOSAR

##2 Acronyms and abbreviations

Acronym	Description
ISR	Interrupt Service Routine. Also used as a macro to declare in C a cat2 interrupt service routine.
RETI	Return from Interrupt
GCE	Generic Configuration Editor
Cat2	Category 2. Cat2 ISRs are supported by the OS and can make OS calls.
Cat1	Category 1. Cat1 interrupts are not supported by the OS and are only allowed to make a very small selection of OS calls to enable and disable all interrupts.

Terminology	Description
Interrupt Handler	In the case of a Cat2 interrupts, the ISR is synonymous with Interrupt Handler. In the case of Cat1 interrupt the Interrupt handler is the function called by the hardware interrupt vector. In both cases the Interrupt handler is the user code that is normally a part of the BSW module.
So we consider the Interrupt Handler to be a user level piece of code. However, in the case of Cat2 interrupts are initially handled in the OS’s interrupt handler before the user’s interrupt handler is called.
Interrupt Logic	This is the MCU logic that controls all interrupts for all devices. This is normally controlled by the OS.
Device	A hardware I/O device that, for the purposes of this document, can also cause interrupts.
Device Interrupt Enable Bit	This is the bit/bits within one hardware device, that is controlled by the device driver, to enable/disable the interrupt source for that device only.
Interrupt Frame	An interrupt frame is the code which is generated by the compiler, or the assembler code, for prefix and postfix of interrupt routines. This code is microcontroller specific
Definition Ref	A reference from one part of the XML to another. In particular, the XML for a BSW module may refer to another BSW module’s XML for certain information. This prevents the same information appearing in multiple places in the XML.
Code Generator	A BSW module is delivered in two parts: code and a Code Generator. The Code Generator consumes complete and correctly formed XML for the BSW module and generates code and data that configures the module.

no references

10 Explanation of IPsec Implementation Guidelines

8 Related documentation

[1 ] AUTOSAR Specifications in general [2 ] RFC 4301
[3 ] RFC 4302
[4 ] RFC 4303
[5 ] RFC 4304 [6 ] RFC 4543 [7 ] RFC 4494 [8 ] RFC 4106 [9 ] RFC 4309
[10 ] RFC 6379
[11 ] RFC 7296
[12 ] RFC 7427
[13 ] RFC 3602
[14 ] RFC 4868
[15 ] RFC 5903
[16 ] Specification of Manifest

9 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the explanation of IPsec implementation in AUTOSAR Adaptive Platform.

Abbreviation / Acronym	Description
AH	Autenticating Header protocol
DB	Database
ECU	Electronic Control Unit
ESP	Encapsulating Security Payload protocol
IKE	Internet Key Exchange protocol
IP	Internet protocol
IPsec	Internet Protocol Security protocol
SA	Security Association

9 Description of the AUTOSAR standard errors

Abbreviation / Acronym	Description
FM	failure mode

no reference

8 Complex Driver design and integration guideline

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.
CDD CDD used to be the acronym for Complex Device Driver or Complex Driver, but is not limited to drivers.

4 Related documentation

4.1 Inputdocuments
General inputs:
[1] AUTOSAR Glossary AUTOSAR_TR_Glossary.pdf
[2] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[3] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[4] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[5] General Specification on BSW modules AUTOSAR_SWS_BSWGeneral.pdf
[6] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[7] Specification of Platform Types AUTOSAR_SWS_PlatformTypes.pdf
[8] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
Templates specification documents:
[9] Specification of BSW Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[10] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
Module reference documents
[11] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[12] Specification of Watchdog Manager AUTOSAR_SWS_Watchdog Manager.pdf
[13] Specification of Operating System AUTOSAR_SWS_OS.pdf
[14] Specification of Default Error Tracer AUTOSAR_SWS_DefaultErrorTracer.pdf
[15] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager
[16] Description of the AUTOSAR standard errors AUTOSAR_EXP_ErrorDescription.pdf
[17] Specification of Rte AUTOSAR_SWS_RTE.pdf
[18] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[19] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[20] Specification of Communication AUTOSAR_SWS_COM.pdf
[21] Specification of Communication Manager AUTOSAR_SWS_COMManager.pdf
[22] Specification of Network Management Interface AUTOSAR_SWS_NetworkManagementInterface.pdf
[23] Specification of TCP/IP Stack AUTOSAR_SWS_TcpIp.pdf
[24] Specification of Synchronized Time Base Manager AUTOSAR_SWS_SynchronizedTimeBaseManager.pdf

7 Guide to BSW Distribution

5 Glossary

All technical terms used throughout this document - except the ones listed here - can be found in the official AUTOSAR glossary [2] or the Software Component Template Specification [3].

5.1 Acronymsandabbreviations

Abbreviation	Explanation
ASIL	Automotive Safety Integrity Level
QM	Quality Managed (i.e. not developed according to ASIL
requirements)
IOC	Inter OS-Application communicator, part of OS
MCU	microcontroller unit, μC
MCAL	microcontroller abstraction layer

5.2 TechnicalTerms

Term	Explanation
BSW functional cluster	A coherent group of BSW modules. The technique is proposed in this document, but a real allocation of modules to clusters is currently not standardized. A BSW functional cluster may be similar to what usually is called a "stack", but it would also be possible to combine several stacks into a cluster or to distribute a stack across several clusters. A BSW functional cluster includes the superset of modules, which can be part of the functional cluster, but not all modules need to be available in a specific implementation. In case the real allocation of BSW modules to BSW functional clusters is standardized in future, they probably will be named “Standardized BSW functional clusters”. BSW functional clusters can be allocated to different partitions, and clusters of the same type can be available in several partitions (either on the same or on different cores). Different functional clusters can be allocated to the same partition. Note: Contrary to ICC2 clustering, the internal structure and the interfaces between the modules within the functional cluster are not affected by the BSW multi-core support in AUTOSAR 4.1.1.
AUTOSAR BSW Cluster Interface	Interfaces between BSW functional clusters resulting from a vendor/project specific definition of BSW functional clusters. The technique is proposed in this document in a vendor/project specific way. But the allocation of modules to BSW functional clusters and thus the resulting interfaces are not standardized yet (if possible at all). This term may be defined in an upcoming release of AUTOSAR as “Standardized AUTOSAR BSW Cluster Interface” after standardization. Contrary to the standardized AUTOSAR interfaces, AUTOSAR BSW Cluster Interfaces shall not be connected to SW-Cs or BSW modules on other MCUs.
Master	Part of a distributed BSW module that coordinates requests by satellites and can filter or monitor incoming satellite requests. The master may work properly even if the satellites are not available. In future versions of AUTOSAR, where case partitioning may be used to enhance safety, it may be recommended or mandatory to locate the master in a partition with a high trust level, e.g. in a trusted partition.
Satellite	Part of a distributed BSW module. The distribution of work between master and satellite is implementation specific. One possibility is that the satellite only provides the interfaces to the other modules and routes all requests to the master and answers back to the other modules. In a different scenario, the satellite can provide the full functionality locally and only synchronizes its internal states with the master if necessary. Intermediate forms between these two scenarios are possible, but the satellites in general cannot work without the master.

6 References

[1] Requirements on Basic Software Module Description Template
[2] AUTOSAR_RS_BSWModuleDescriptionTemplate
[3]Glossary AUTOSAR_TR_Glossary
[4] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
Concept Enhanced BSW Allocation AUTOSAR_CONC_EnhancedBSWAllocation
[5] Specification of Basic Software Mode Manager AUTOSAR_SWS_BSWModeManager

6 Explanation of Error Handling on Application Level

no abbreviations

3 References

Explanation of Error Handling on Application Level AUTOSAR CP R19-11
[1] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[2] SpecificationofRTE AUTOSAR_SWS_RTE
[3] SpecificationofOperatingSystem AUTOSAR_SWS_OS
[4] SpecificationofCommunication AUTOSAR_SWS_COM
[5] SpecificationofCommunicationManager AUTOSAR_SWS_COMManager
[6] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager
[7] SpecificationofECUStateManager AUTOSAR_SWS_ECUStateManager
[8] SpecificationofFunctionInhibitionManager AUTOSAR_SWS_FunctionInhibitionManager
[9] Specification of Diagnostic Event Manager AUTOSAR_SWS_DiagnosticEventManager
[10]Specification of Watchdog Manager AUTOSAR_SWS_WatchdogManager
[11]Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager
[12]Specification of CRC Routines AUTOSAR_SWS_CRCLibrary
[13]Specification of Crypto Service Manager AUTOSAR_SWS_CryptoServiceManager
[14]Specification of Basic Software Mode Manager AUTOSAR_SWS_BSWModeManager
[15]General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[16] Glossary AUTOSAR_TR_Glossary
[17]Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
[18]Specification of SW-C End-to-End Communication Protection Library AUTOSAR_SWS_E2ELibrary
[19]Specification of Module Core Test Driver AUTOSAR_SWS_CoreTest
[20]Specification of Flash Test AUTOSAR_SWS_FlashTest
[21]Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on Dependable and Secure Computing, Vol. 1, No. 1, January- March 2004
[22]Jim Gray, “Why Do Computers Stop and What Can We Do About It”, Technical Report TR 85.5, Tandem, 1985.
[23]ISO CD 26262-1 Road vehicles – Functional Safety – Part 1: Glossary [24]EASIS Deliverable D1.2-8, “Fault management framework”
http://www.easis-online.org/

5 Guidelines for using Adaptive Platform interfaces

no abbreviations

7 References

[1] Explanations of Adaptive Platform Design, AUTOSAR_EXP_PlatformDesign.pdf.
[2] Specification of Execution Management, AUTOSAR_SWS_StateManagement.pdf.
[3] Specification of Platform Health Management, AUTOSAR_SWS_PlatformHealthManagement.pdf.
[4] Explanation of ara::com API, AUTOSAR_EXP_ARAComAPI.pdf.

4 Overview of Acceptance Tests

Abbreviations

The following table contains a list of abbreviations used in the scope of AUTOSAR Acceptance Tests along with the spelled-out meaning of each of the abbreviations.

Abbreviation	Meaning
ATS	Acceptance Test Specification
IUT	Implementation Under Test (see ISO/IEC 9646-1)
PCO	Point of Control and Observation (see ISO/IEC 9646-1)
SUT	System Under Test (see ISO/IEC 9646-1)

no references

3 Explanation of ara::com API

3 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the explanation of ara::com API.

Abbreviation / Acronym	Description
ctor	C++ constructor
dtor	C++ destructor
IPC	Inter Process Communication
RT	Realtime
SI	Service Interface
WET	Worst Case Execution Time

Terms	Description
Binding	This typically describes the realization of some abstract concept with a specific implementation or technology. In AUTOSAR, for instance, we have an abstract data type and interface model described in the methodology. Mapping it to a concrete programming language is called lan- guage binding. In the AUTOSAR Adaptive Platform for instance we do have a C++ language binding. In this explanatory document we typically use the tech term bind- ing to refer to the implementation of the abstract (technology in- dependent) ara::com API to a concrete communication transport technology like for instance sockets, pipes, shared memory, ...
Callable	In the context of C++ a Callable is defined as: A Callable type is a type for which the INVOKE operation (used by, e.g., std::function, std::bind, and std::thread::thread) is applicable. This operation may be performed explicitly using the library function std::invoke. (since C++17)

References

[1] Specification of RTE Software AUTOSAR_SWS_RTE
[2] Middleware for Real-time and Embedded Systems http://doi.acm.org/10.1145/508448.508472
[3] Patterns, Frameworks, and Middleware: Their Synergistic Relationships http://dl.acm.org/citation.cfm?id=776816.776917
[4] Specification of Core Types for Adaptive Platform AUTOSAR_SWS_CoreTypes
[5] Guidelines for the use of the C++14 language in critical and safety-related sys- tems
AUTOSAR_RS_CPP14Guidelines
[6] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[7] SOME/IP Protocol Specification AUTOSAR_PRS_SOMEIPProtocol
[8] Serialization and Unserialization https://isocpp.org/wiki/faq/serialization
[9] Copying and Comparing: Problems and Solutions http://dx.doi.org/10.1007/3-540-45102-1_11
[10] SOME/IP Service Discovery Protocol Specification AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

2 Requirements on Acceptance Tests

no abbreviations

5 References

5.1 Deliverables of AUTOSAR
[1] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
[2] Glossary AUTOSAR_TR_Glossary.pdf

1 Feature Specification of the Acceptance Tests

3 Acronyms and Abbreviations

Except for the acronyms and abbreviations below, all acronyms and abbreviations used throughout this document are included in the official AUTOSAR glossary [Glossary]. For respective explanation please see there.

Acronym	Description
SUT	System Under Test

238 Modeling Guidelines of Basic Software EA UML Model

References

[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
[2] List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[3] Glossary AUTOSAR_TR_Glossary
[4] Specification of Standard Types AUTOSAR_SWS_StandardTypes
[5] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[6] Standardized M1 Models used for the Definition of AUTOSAR AUTOSAR_MOD_GeneralDefinitions

239 AUTOSAR Feature Model Exchange Format

References

[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Software Process Engineering Meta-Model Specification http://www.omg.org/spec/SPEM/2.0/