Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

Autosar 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
  4. ISO 14229-1 Unified diagnostic services (UDS) Part 1: Specification and Re- quirements (v.2013)
  5. ISO 15031-5 Communication between vehicle and external equipment for emis- sions related diagnostics Part 5: Emissions related diagnostic services (2005-01- 13)
  6. ISO 15765-3 Diagnostics on controller area network (CAN) Part 3: Implementa- tion of unified diagnostic services (UDS on CAN) (2004-10-06)
  7. 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
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/

kaizen_nagoya
I'm a network designer.I work on TOPPERS SmallestSetProfile Kernel,MISRA-C, STARC RTL Design StyleGuide (Verilog-HDL),HAZOP,ISO/IEC15504(AutomotiveSPICE),ISO26262. I was an editor on ISO/IEC 15504.
https://researchmap.jp/blogs/blog_entries/view/81777/f691323917cc4ea12caf0b03b34c8ea0?frame_id=442673
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away