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

Autosar Document
https://www.autosar.org/nc/document-search/

No. Number in the AUTOSAR document list

https://qiita.com/kaizen_nagoya/items/25bac8e0e14bda6067ec

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

no abbreviations

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

# 28 Requirements on Communication Management
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_RS_CommunicationManagement.pdf


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

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

4 4.1
Definition of terms and acronyms Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|(G)TD|(Global) Time Domain|
|(G)TM|(Global)Time Master|
|<Bus>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
https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf

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

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

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

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

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

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

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


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

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

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

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

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

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

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

|Abbreviation / Acronym|Description|
|:--|:--|
|FM| failure mode  |  


no reference

# 8 Complex Driver design and integration guideline
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_EXP_CDDDesignAndIntegrationGuideline.pdf

## 2 Acronyms and abbreviations
Acronyms and abbreviations, which have a local scope and therefore are not contained in the AUTOSAR glossary, must appear in a local glossary.
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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_EXP_BSWDistributionGuide.pdf

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

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

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
https://www.autosar.org/fileadmin/user_upload/standards/tests/1-2/AUTOSAR_EXP_AcceptanceTestsOverview.pdf

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

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

## 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
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_TPS_FeatureModelExchangeFormat.pdf
## References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Software Process Engineering Meta-Model Specification http://www.omg.org/spec/SPEM/2.0/

### 最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

#### Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.