Autosar list of reference, abbreviation and term.(48-94/303): English(40c)

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.
0: not detect
1: same as another

No. Number in the AUTOSAR document list
https://qiita.com/kaizen_nagoya/items/25bac8e0e14bda6067ec

This document is a series of the below
Autosar list of reference, abbreviation and term.(47/237): English(40)
https://qiita.com/kaizen_nagoya/items/2325b0156bc7fcf5a96d

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

# 94 Requirements on Vehicle-2-X communication
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_V2XCommunication.pdf

## Bibliography
[1] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[2] Glossary
AUTOSAR_TR_Glossary
[3] EN 302 665 V1.1.1: Intelligent Transport Systems (ITS); Communications Architecture
[4] TS 103 097 V1.3.1: Security Header and Certificate Formats
[5] EN 302 636-4-1 V1.3.1: Vehicular Communication; Geonetworking; Part 4 Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 1: Media-Independent Functionality
[6] Certificate Policy for Deployment and Operation of European Cooperative Intelligent Transport Systems (C-ITS), Release 1.1, June 2018
[7] Security Policy & Governance Framework for Deployment and Operation of European Cooperative Intelligent Transport Systems (C-ITS), Release 1, December
2017
[8] TS 102 894-2 V1.3.1: Intelligent Transport Systems (ITS); Users and applications
requirements; Applications and facilities layer common data dictionary
[9] EN 302 663 V1.2.1: Intelligent Transport Systems (ITS); Access layer specification
for Intelligent Transport Systems operating in the 5 GHz frequency band
[10] TS 102 792 V1.2.1: Intelligent Transport Systems (ITS); Mitigation techniques to
avoid interference between European CEN Dedicated Short Range Communication (CEN DSRC) equipment and Intelligent Transport Systems (ITS) operating in
the 5 GHz frequency range
[11] TS 102 724 V1.1.1: Intelligent Transport Systems (ITS); Harmonized Channel
Specifications for Intelligent Transport Systems operating in the 5 GHz frequency
band
[12] EN 302 636-5-1 V2.1.1: Vehicular Communication; Geonetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocols
[13] EN 302 931 V1.1.1: Vehicular Communications; Geographical Area Definition
[14] EN 302 637-2 V1.4.1: Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness
Basic Service
[15] EN 302 637-3 V1.3.1: Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service
[16] SAE J2945/1_201603: On-Board System Requirements for V2V Safety Communications
[17] C-Roads Profile V1.2: C-ITS Infrastructure Functions and Specifications
[18] TS 103 301 V1.2.1: Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services
[19] C2C-CC White Paper Decentralized Congestion Control (DCC) for Day One
[20] Requirements on AUTOSAR Features
AUTOSAR_RS_Features
[21] General Specification of Basic Software Modules
AUTOSAR_SWS_BSWGeneral

## 3 Acronyms and abbreviations
The glossary below includes acronyms and abbreviations relevant to the V2x-stack that
are not included in the AUTOSAR Glossary [2].

|Abbreviation / Acronym| Description|
|:--|:--|
|AT| Authorization Ticket|
|BSS| Basic service set|
|BTP| Basic Transport Protocol [1]|
|C2C-CC| Car to Car communications Consortium|
|CA| Cooperative awareness|
|CAM| Cooperative awareness message [2]|
|CS| Charging Spot|
|DCC| Decentralized Congestion Control|
|DENM| Decentralized event notification message [3]|
|DP| DCC profile|
|DPID| DCC profile identifier|
|DSRC| Dedicated Short Range communications|
|EDCA| Enhanced distributed channel access|
|EV| Electric Vehicle|
|GBC| GeoBroadcast|
|GLOSA| Green Light Optimized Speed Advisory|
|GN| GeoNetworking|
|GPS| Global positioning system|
|HSM| Hardware security module|
|HST| Header Sub-type|
|HT| Header Type|
|ITS| Intelligent Transport Systems|
|ITS-S| ITS Station|
|IVIM| Infrastructure to Vehicle Information Message|
|LF| Low frequency|
|LLC| Logical Link Control|
|LT| Lifetime|
|LTCA| Long-Term Certificate Authority|
|MAC| Medium Access Control|
|MAPEM| MAP (topology) Extended Message|
|MHP| Maximum Hop limit|
|NDL| Network Design limits|
|NH| Next Hop|
|PCA| Pseudonym Certificate Authority|
|PHY| Physical layer|
|PKI| Public key infrastructure|
|POI| Point of Interest|
|PTD| Probe Traffic Data|
|RLT| Road and Lane Topology|
|SCF| Store Carry Forward|
|SHB| Single Hop Broadcast|
|SPAT| Signal Phase and Timing|
|SPAT| Signal Phase And Timing|
|SPATEM| Signal Phase And Timing Extended Message|
|TAL| Trust Assurance Level|
|TC| Traffic class|
|TLM| Traffic Light Maneuver|

#93 Requirements on Time Service
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_TimeService.pdf

## 4 Acronyms, abbreviations and terms

|Term|Description|
|:--|:--|
|GPT Predef Timer|A GPT Predef Timer is a free running up counter provided by the GPT driver. Which GPT Predef Timer(s) are available depends on hardware (clock, hardware timers, prescaler, width of timer register, …) and configuration. A GPT Predef Timer has predefined physical time unit and range.|
|Time Service Predef Timer| A Time Service Predef Timer is a free running up counter with predefined physical time unit and range. The hardware timer functionality is based on the corresponding GPT Predef Timer. For each Predef Timer a set of API services is provided by the Time Service module. The user can instantiate any timers (only limited by available memory) and can use the instances completely independently of each other.|
|Timer instance |A timer instance is a data object of an API data type.|
|Reference time |The reference time is a time value stored for each timer instance.|
 
## 7 References
7.1 Deliverables of AUTOSAR
[1] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

# 92 Requirements on TTCAN
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_TTCAN.pdf

## 3 Acronyms and abbrevations

|Acronym|Description|
|:--|:--|
|CAN |Controller Area Network|
|TTCAN| Time Triggered CAN|

## 6 References
6.1 Deliverables of AUTOSAR
[1] [Ttcan] Specification of TTCAN Driver
AUTOSAR_SWS_TTCANDriver.pdf
[2] [TtcanIf] Specification of TTCAN Interface
AUTOSAR_SWS_TTCANInterface.pdf
[3] [SrsCan] Requirements on CAN
AUTOSAR_SRS_CAN.pdf
[4] [SrsGeneral] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[5] [RS_Features] Requirements on AUTOSAR Features,
AUTOSAR_RS_Features.pdf
[6] [TPS_STDT_0078] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
6.2 Related standard and norms
[7] ISO 11898-4 (2004-08-01), Road vehicles – Controller Area Network (CAN)
Part4: Time triggered communication

# 91 Requirements on SPI Handler/Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_SPIHandlerDriver.pdf

## 3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS| Chip Select|
|DIO| Digital Input Output|
|ECU| Electric Control Unit|
|DMA| Direct Memory Access|
|ICU| Input Capture Unit|
|MAL| Old name of Microcontroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL| MicroController Abstraction Layer|
|MCU| MicroController Unit|
|MISO| Master Input Slave Output|
|MMU| Memory Management Unit|
|MOSI| Master Output Slave Input|
|NMI| Non Maskable Interrupt|
|OS| Operating System|
|PLL| Phase Locked Loop|
|PWM| Pulse Width Modulation|
|RX| Reception (in the context of bus communication)|
|SPAL| The name of this working group|
|SFR| Special Function Register|
|RTE|RunTime Environment|
|STD| Standard|
|REQ| Requirement|
|UNINIT| Uninitialized (= not initialized)|

>As this is a document from professionals for professionals, all other
terms/expressions are expected to be known.

|Term /Expression|Description|
|:--|:--|
|Master| A device controlling other devices (slaves, see below)|
|Slave| A device being completely controlled by a master device|
|Channel| A Channel is a software exchange medium for data that are defined with the samecriteria: Config. Parameters, Number of Data elements with same size and data pointers (Source & Destination) or location.|
|Job| A Job is composed of one or several Channels with the same Chip Select (is not released during the processing of Job). A Job is considered atomic and therefore cannot be interrupted by another Job. A Job has an assigned priority.|
|Sequence| A Sequence is a number of consecutive Jobs to transmit but it can be rescheduled ⌋()between Jobs using a priority mechanism. A Sequence transmission is interruptible(by another Sequence transmission) or not depending on a static configuration|

## 7 Related Documentation
7.1 Deliverables of AUTOSAR
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

# 90 General Requirements on SPAL
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_SPALGeneral.pdf

##3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS| Chip Select|
|DIO| Digital Input Output|
|ECU| Electric Control Unit|
|ICU| Interrupt Capture Unit|
|MAL| Old name of Microcontroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a French term meaning ‘bad’)|
|MCAL| Microcontroller Abstraction Layer|
|MCU| Microcontroller Unit|
|MMU| Memory Management Unit|
|NMI| Non Maskable Interrupt|
|OS| Operating System|
|OCU| Output Compare Unit|
|PLL| Phase Locked Loop|
|PWM| Pulse Width Modulation|
|RX| Reception (in the context of bus communication)|
|SPAL| Standard Peripheral Abstraction Layer (The name of this working group)|
|SFR| Special Function Register|
|RTE| Runtime Environment|
|WP| Work Package|
|STD| Standard|
|REQ| Requirement|
|UNINIT| Uninitialized (= not initialized)|

|Term| Description:|
|Master| A device controlling other devices (slaves, see below)|
|Slave| A device being completely controlled by a master device|

##7 References
7.1 Deliverables of AUTOSAR
[1] Glossary
AUTOSAR_TR_Glossary.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

#89 Requirements on BSW Modules for SAE J1939
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_SAEJ1939.pdf

## 3 Acronyms and Abbreviations

|Abbreviation /Acronym|Description|
|:--|:--|
|CA| Controller Application, role of an ECU tied to one address|
|DA| J1939 Destination Address|
|J1939Tp N-PDU| PDU of J1939 Transport Layer, exchanged with CAN Interface|
|J1939Tp N-SDU| SDU of J1939 Transport Layer, exchanged with PDU Router|
|PG| Parameter Group – J1939 message|
|PGN| Parameter Group Number – J1939 message identifier|
|SA| J1939 Source Address|
|TP.CM| J1939 Transport Protocol Connection Management message|
|TP.DT| J1939 Transport Protocol Data Transfer message|

## 9 References
### 9.1 Deliverables of AUTOSAR
[J1939Tp] Specification of a Transport Layer for SAE J1939
AUTOSAR_SWS_SAEJ1939TransportLayer.pdf
[J1939Rm] Specification of a Request Manager for SAE J1939
AUTOSAR_SWS_SAEJ1939RequestManager.pdf
[J1939Nm] Specification of Network Management for SAE J1939
AUTOSAR_SWS_SAEJ1939NetworkManagement.pdf
[SRSGeneral] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[TPS_STDT_0078] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
### 9.2 Related standard and norms
9.2.1 SAE
[SAE J1939-21], Data Link Layer
[SAE J1939-81], Network Management
[SAE J1939-73], Application layer – Diagnostics

# 88 Requirements on Runtime Environment
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_RTE.pdf

## References
[1] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[2] Requirements on Standardization Template
AUTOSAR_RS_StandardizationTemplate
[3] Virtual Functional Bus
AUTOSAR_EXP_VFB
[4] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[5] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate
[6] Requirements on Mode Management
AUTOSAR_SRS_ModeManagement
[7] Specification of Memory Mapping
AUTOSAR_SWS_MemoryMapping
[8] Specification of Compiler Abstraction
AUTOSAR_SWS_CompilerAbstraction
[9] Specification of Platform Types
AUTOSAR_SWS_PlatformTypes
[10] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral
[11] Specification of Diagnostic Log and Trace
AUTOSAR_SWS_DiagnosticLogAndTrace

#87 Requirements on RAM Test
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_RAMTest.pdf

## 3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|ECU| Electric Control Unit|
|EOL| End Of Line Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|MAL| Old name of Microcontroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL| Microcontroller Abstraction Layer|
|MCU| Microcontroller Unit|
|NMI| Non maskable interrupt|
|OS| Operating System|
|SPAL| The name of this working group|
|SFR| Special Function Register|
|RTE| Runtime environment|
|WP| Work Package|
|STD| Standard|
|REQ| Requirement|
|UNINIT| Uninitialized (= not initialized)|

## 7 References
7.1 Deliverables of AUTOSAR
[1] Glossary
AUTOSAR_TR_Glossary.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
7.2 Related standards and norms
[6] CEI/IEC 61508-2:2000: Requirements for electrical/electronic/programmable
electronic safety-related systems

#86 Requirements on Port Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_PortDriver.pdf

## 3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|ADC| Analogue to Digital Converter|
|DIO| Digital Input Output|
|ICU| Input Capture Unit|
|MCAL| Microconroller Abstraction Layer|
|MCU| Microcontroller Unit|
|OS| Operating System|
|PWM| Pulse Width Modulation|
|SCI| Serial Communication Interface|
|SPAL| The name of this working group (Standard Peripheral Abstraction Layer)|
|SPI| Serial Peripheral Interface|
|WP| Work Package|
|STD| Standard|
|REQ| Requirement|
|UNINIT| Uninitialized (= not initialized)|

## 6 References
6.1 Deliverables of AUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_GLOSSARY] Glossary,
AUTOSAR_TR_Glossary.pdf
[SRS_BSW_GENERAL] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[SRS_BSW_SPAL] General Requirements on SPAL,
AUTOSAR_SRS_SPALGeneral.pdf
[TPS_STDT_0078] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

# 85 Requirements on PWM Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_PWMDriver.pdf

##4 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS| Chip Select|
|DIO| Digital Input Output|
|ECU| Electric Control Unit|
|DMA| Direct Memory Access|
|ICU| Input Capture Unit|
|MAL| Old name of Microcontroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL| Microcontroller Abstraction Layer|
|MCU| Microcontroller Unit|
|MISO| Master Input Slave Output|
|MMU| Memory Management Unit|
|MOSI| Master Output Slave Input|
|NMI| Non Maskable Interrupt|
|OS| Operating System|
|PLL| Phase Locked Loop|
|PWM| Pulse Width Modulation|
|RX| Reception (in the context of bus communication)|
|SPAL| The name of this working group|
|SFR| Special Function Register|
|RTE| RunTime Environment|
|STD| Standard|
|REQ| Requirement|
|UNINIT| Uninitialized (= not initialized)|

|Term|Description|
|:--|:--|
|Master| A device controlling other devices (slaves, see below)|
|Slave| A device being completely controlled by a master device|

## 7 Related Documentation
7.1 Deliverables of AUTOSAR
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

# 84 Requirements on Operating System
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_OS.pdf

## 2.2 Acronyms and abbreviations

|Abbreviation| Description|
|:--|:--|
|API| Application Programming Interface|
|BSW| Basic Software|
|COM| Communications|
|ECU| Electronic Control Unit|
|HW| Hardware|
|ISR| Interrupt Service Routine|
|MC| Multi-Core|
|MCU| Microcontroller Unit|
|MPU| Memory Protection Unit|
|NM| Network Management|
|OIL| OSEK Implementation Language|
|OS| Operating System|
|OSEK/VDX| Offene Systeme und deren Schnittstellen für die Elektonik im Kraftfahrzeug|
|SC| Single-Core|
|SW| Software|
|SWC| Software Component|
## 6 References
###6.1 Deliverables of AUTOSAR
[AUTOSAR_GLOSSARY] Glossary,
AUTOSAR_TR_Glossary.pdf
[DOC_LAYERED_ARCH] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[DOC_VFB] Virtual Function Bus,
AUTOSAR_EXP_VFB.pdf
[DOC_WP112_REQ] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[TPS_STDT_0078] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
###6.2 Related standards and norms
####6.2.1 OSEK
[STD_OSEK_OS] ISO 17356-3: OS
[STD_OSEK_OIL] ISO 17356-6: OIL
####6.2.2 Company Reports, Academic Work, etc
[REP_DC_PROTECTED_OS] Extensions of OSEK OS for Protected Applications,
OSEK Support Project, DC058_02, Daimler-Chrysler AG

# 83 Requirements on OCU Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_OCUDriver.pdf

##2 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Acronym |Description|
|:--|:--|
|OCU| Output Compare Unit|
|DMA| Direct memory access|
|MCAL| Microcontroller Abstraction Layer|
|MCU| Microcontroller Unit|
|SPAL| Standard Peripheral Abstraction Layer|
|STD| Standard|
|UNINIT| Uninitialized (= not initialized)|

|Term |Description|
|:--|:--|
|OCU channel| Represents a logical entity composed of a free running counter a comparison threshold and the action that is done as a result of the comparison process.|
|Compare threshold| Target value that is compared with the content of the counter each time the counter increases by one unit.|
|Free running counter| A counter that runs from a minimum to a maximum value and restarts automatically to the minimum after reaching the maximum value.|

##5 Related Documentation
5.1 AUTOSAR deliverables
[1] Glossary
AUTOSAR_TR_Glossary.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software
AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[5] List of Basic software modules
AUTOSAR_BasicSoftwareModuleList.pdf
[6] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

# 82 Requirements on Network Management
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_NetworkManagement.pdf

## 7 References
7.1 Deliverables of AUTOSAR
[1] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on Basic Software Modules
AUTOSAR_SRS_BSWGeneral.pdf
[3] Specification of the Virtual Functional Bus
AUTOSAR_EXP_VFB.pdf
[4] AUTOSAR Glossary
AUTOSAR_TR_Glossary.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf
[6] [DOC_VFB] Specification of the Virtual Functional Bus
AUTOSAR_EXP_VFB.pdf
[7] Requirements on AUTOSAR Features
AUTOSAR_RS_Features.pdf
###7.2 Related standards and norms 7.2.1 ISO 17356-5
[1] ISO 17356-5: NM Specification
 www.iso.org

#81 Requirements on Mode Management
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_ModeManagement.pdf

## 3 Terminology
### Glossary

|Term| Description|
|:--|:--|
|Active wake-up| Wake-up caused by the ECU e.g. by a sensor.|
|Alive indication| Indication that a supervised SW-C is alive – meaning active – provided from the SW-C itself to the Watchdog Manager.|
|Application| Applications are used synonymous to a SW-C. A SW-C may span several atomic SW-Cs. AUTOSAR provides the element of a“composition” to formally group several atomic SW-Cs of an application. A composition is used to structure the description and does not affect the generated code.Note: The atomic SW-Cs in a composition can still be mapped to different ECUs. Application Modes are therefore ‘local’ to an application but can be ‘global’ to several ECUs.|
|Application Mode| An Application Mode is a mode that is not controlled and standardized by the Mode Managers in the BSW. The scope of an Application Mode is a limited number of SW-Cs that belongs to a logical Application. If a mode only affects one composition, it is an Application Mode. An Application Mode may be distributed across multiple ECUs or may be local to one ECU depending on the distribution of the SW-C belonging to that application.Examples: Normal Operation, Limp Home|
|Application Mode Manager| An Application Mode Manager is a SW-C therefore a priori not standardized. It collects environmental data and Mode Requests via application-specific (non-standardized) interfaces from other SW-Cs. It can switch Application Modes (that are not controlled and standardized by the Mode Managers in the BSW). It can also request modes from other Mode Managers, specifically from Mode Managers in the BSW.|
|BSW Mode| A BSW Mode is mode, which is controlled and standardized by the Mode Manager in the BSW. A BSW Mode is always local to one ECU.Examples: EcuM Modes, ComM Modes|
|BSW Mode Manager| The BSW Mode Manager is a BSW module that collects mode requests via a standardized interface and controls functionality of other BSW modules accordingly. Examples are: LIN Schedule Table Switching, Enabling/Disabling I-PDU Groups, …|
|Communication mode| Related to a physical channel or to a user, it indicates if it is possible to send/receive, only receive, neither send nor receive.|
|Communication request| A communication request indicates a demand for communication from a given user (e.g. a runnable requiring an operational communication stack). However, it can neither be assumed that the request will be fulfilled within a certain time nor that it will be fulfilled at all. The demander itself has to make sure that communication is indeed established, by using query functions or callbacks.|
|ECU state| General term to indicate the states managed by the ECU State Manager. They represent a structured model that extends the power modes of the ECU with states and transitions to support necessary activities of software to enter/leave these power modes.|
|Inoperation| An artificial word to describe the ECU when it is not operational, i.e. not running. It comprises all meanings of off, sleeping, frozen, etc. Using this definition is beneficial since it has no predefined meaning.|
|Low-power mode| All power modes except “on” (full power).|
|Mode| A mode is a certain set of states of the various state machines that are running in the vehicle that are relevant to a particular entity, e.g. a SWC, a BSW module, an application, a whole vehicle In its lifetime, an entity changes between a set of mutually exclusive modes. These changes are triggered by environmental data, e.g. signal reception, operation invocation. Mode Declaration Group| A Mode Declaration Group is defined in the Software Component Template and implemented by the RTE. A Mode Declaration Group defines a number of mutually exclusive modes. There is no hierarchy of modes within a Mode Declaration Group. Each Mode Declaration Group describes only one aspect of the whole system. All modes of all Mode Declaration Groups on an ECU describe the abstract mode of the ECU. Similarly, all modes of all Mode Declaration Groups in a system describe the abstract mode of all ECUs in the system. (The mode is abstract because it cannot be physically accessed, it just exists conceptually). There is a standardized set of Mode Declaration Groups defined in the BSW, e.g. ComM, WdgM, EcuM. Each system designer is free to extend the number of Mode Declaration Groups and define his/her own modes in there. Only one Mode Manager is allowed to switch the mode of an instance of a Mode Declaration Group. (Limitation in VFB)|
|Mode Manager| A Mode Manager is a role that can be taken by either a BSW module (and optionally additionally by an SW-C). The Mode Manager collects requests from Mode Requesters, arbitrates them and switches the mode of its Mode Declaration Group(s) accordingly. Examples of Mode Managers are: EcuM, ComM, WdgM and BswM Note: If a SW-C Mode Manager switches modes directly, the mode arbitration in the BSW Mode Manager cannot resolve conflicts. Thus, it is recommended to use multi-level mode arbitration, of SW-C mode Manager and BSW Mode Manager|
|Mode Port| A Mode Port is port that has a Sender-Receiver Interface which contains a Mode Declaration Group. Note: This is called Mode Port in SWS RTE -> To distinguish it from Mode Request Ports, we should call it Mode Switch Port|
|Mode Request| A Mode Request is some information communicated to a Mode Manager that requests the Mode Manager to switch to a certain mode. For Mode Managers in the BSW the interface to send a Mode Request is a standardized client-server interface defined by the corresponding Mode Manager. Examples: Client-server interface ComM_UserRequest with operation RequestComMode(…). For Application Mode Managers the interface can be any clientserver or sender-receiver interface defined by the Mode Manager.|
|Mode Request Port| A Mode Request Port is a port with the special semantics of requesting a mode from a Mode Manager. It can be a Client-Server or a SenderReceiver Port. For Mode Managers in the BSW the Mode Request Port is standardized. Note: For EcuM, ComM and WdgM it is always a Provided ClientServer Port. For BswM it is a Required Sender-Receiver Ports.|
|Mode Requester| A Mode Requester is an entity that requests modes from a Mode Manager.|
|Mode Switch Port| Favored replacement of phrase Mode Port|
|Mode User| A Mode User is an entity that reacts on mode changes.|
|OFF state| ECU state. It denotes the unpowered ECU. Depending on the hardware design, the ECU can or cannot react to passive wake-up in this state (wakeability is not required in this state).|
|Passive wake-up| Wakeup initiated by another ECU and propagated (e.g. by bus or wakeup-line) to the ECU currently in focus.|
|Port Group| A Port Group is a logical group of ports that are needed to realize the same functionality in the Application. A port can be a member of multiple Port Groups. A Port Group can be used to request all associated communication resources and to inquire their state. Thereby, the Port Group also defines a mapping between Application Ports and Communication Resources. Thus, the purpose of a port group is to have an abstraction of the required communication resources of that functionality For example, an Application contains normal-operation functionality and limp-home functionality with reduced communication requirements. Then it is useful to define two Port Groups, A and B. A contains the ports that are necessary for the normal-operation functionality and B contains the ports for the limp-home functionality. Thereby, the Application can recognize the condition when the communication resources for normal operation are unavailable but are sufficient for limp home. Port Groups are defined on SW-C composition level, which means that they may be distributed on several ECUs. The requests and indications for the Port Groups shall however only affect the portion of the Port Group that is local to an ECU. If distributed control of Port Groups is needed it can be handled on “Application Mode Management” level (above the RTE) using normal communication features.|
|Power mode| Hardware power mode of the ECU. Typically: on (full power), off, sleep, standby, etc… The last two items can take several forms depending on hardware capabilities (reduced clock, peripheral standby, etc.).|
|Program flow monitoring| Technique to detect errors that cause a divergence from the valid program sequence seen during valid execution of a program.|
|RUN state| ECU state. The ECU is fully functional, all BSW modules are initialized and application software components are able to run.|
|Shutdown target| The chosen low-power state (OFF, SLEEP) for the next shutdown. If the SLEEP state supports several sleep modes, the shutdown target shall indicate the chosen sleep mode.|
|Sleep mode| The term "mode" is related to the current availability of the ECU's capabilities. “Sleep mode” is the overall abstracted term for a variety of low-power modes that could exist at different CPU's, which have in common that they currently do not perform code-execution, but are still powered.|
|SLEEP state| ECU state. It is an energy saving state: no code is executed but power is still supplied, and if configured correctly, the ECU is wakeable. The SLEEP state provides a configurable set of sleep modes which typically are a trade off between power consumption and time to restart the ECU.|
|State/communication requestor|See User.|
|Supervised Entity| A supervised entity is a software entity which is included in the monitoring of the Watchdog Manager. Each supervised entity has exactly one identifier. A supervised entity denotes a collection of checkpoints within a software component or basic software module. There may be zero, one or more supervised entities in a software component or basic software module.|
|User| Concept for requestors of the ECU State Manager and of the Communication Manager. A user may be a runnable entity, a SWC/BSW or even a group of SW-Cs/BSWs, which acts as a single unit towards the ECU State Manager and the Communication Manager.|
|Vehicle Mode| A Vehicle Mode is a mode that is not controlled and standardized by the Mode Managers in the BSW. The scope of a Vehicle Mode is the whole vehicle. If a mode affects multiple compositions, it is a Vehicle Mode. A Vehicle Mode is by definition distributed across the whole vehicle. Example: Transport Mode, Power Saving Mode, Ignition On, Ignition Off|
|Vehicle Mode Manager| A Vehicle Mode Manager is a special kind of Application Mode Manager that switches Vehicle Modes.|
|Wake-up event| A physical event which causes a wake-up. A CAN message or a toggling IO line can be wake-up events. Similarly, the internal SW representation, e.g. an interrupt, may also be called a wake-up event.|
|Wake-up reason| The wake-up event being actually the cause of the current/last wakeup.|
|Wake-up source| The peripheral or ECU component which deals with wake-up events is called a wake-up source.|

###Abbreviations
|Abbreviation| Description|
|:--|:--|
|BSW| Basic Software|
|BswM| Basic Software Mode Manager|
|ComM| Communication Manager|
|DCM| Diagnostic Communication Manager|
|DEM| Diagnostic Event Manager|
|EcuM| ECU State Manager|
|FiM| Function Inhibition Manager|
|RE| Runnable Entity|
|SW-C| Software Component|
|WdgM| Watchdog Manager|

# 80 Requirements on Memory Services
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_MemoryServices.pdf

## 3 Acronyms and abbreviations

|Acronym| Description|
|:--|:--|
|Basic Storage Object| A “Basic Storage Object” is the smallest entity of a NVRAM Block. Several “Basic Storage Objects” can be used to build a NVRAM Block. A “Basic Storage Object” can reside in different memory locations (RAM/ROM/NV memory).|
|NVRAM Block| The “NVRAM Block” is the entire structure, which is needed to administrate and to store a block of NV data.|
|NV data| The data to be stored in the Non-Volatile memory.|
|Block Management Type| Type of the NVRAM Block. It depends on the (configurable) individual composition of a NVRAM Block in chunks of different mandatory/optional Basic Storage Objects and the subsequent handling of this NVRAM block.|
|NV Block Header| Additional information included in the NV Block if the mechanism “Static Block ID” is enabled.|
|RAM Block| The “RAM Block” is a Basic Storage Object. It represents the part of a NVRAM Block, which resides in the RAM. See [SRS_LIBS_08534]|
|ROM Block| The “ROM Block” is a Basic Storage Object. It represents the part of a NVRAM Block, which resides in the ROM. The “ROM Block” is an optional part of a NVRAM Block.|
|NV Block| The “NV Block” is a Basic Storage Object. It represents the part of a NVRAM Block, which resides in the NV memory. The “NV Block” is a mandatory part of a NVRAM Block.|
|Administrative Block| The “Administrative Block” is a Basic Storage Object. It resides in RAM. The Administrative Block contains any RAM data, that are necessary to manage the NVRAM block, for being able to perform processing on it and to deliver status information. The “Administrative Block” is a mandatory part of a NVRAM Block.|

## 7 References
7.1 Deliverables of AUTOSAR
[AUTOSAR_SW_ARCH] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_BASIC_SW] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[AUTOSAR_SRS_MEMHW] Requirements on Memory Hardware Abstraction Layer
AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf
[TPS_STDT_0078]SoftwareComponentTemplate
AUTOSAR_TPS_SoftwareComponentTemplate.pdf

#79  Requirements on Memory Hardware Abstraction Layer
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_MemoryHWAbstractionLayer.pdf

## 3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Term|Description|
|:--|:--|
|(Logical) Block| Continuous area of memory that can be individually addressed by the module user (i.e. for read / write / erase / compare operations). The block size is statically configurable (pre-compile time).|
|Page| Smallest amount of memory that can be written in one pass.|
|Sector| Smallest amount of memory that can be erased in one pass.|

|Acronyms /abbreviations|Description|
|:--|:--|
|FEE| Flash EEPROM Emulation|
|EA| EEPROM Abstraction Layer|
|MemIf| Memory Abstraction Interface|

##7 References
7.1 Deliverables of AUTOSAR
[1] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL
AUTOSAR_SRS_SPALGeneral.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

#78 Requirements on MCU Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_MCUDriver.pdf

## 3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the
AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS| Chip select|
|DIO| Digital Input Output|
|ECU| Electric Control Unit|
|EOL| End Of Line Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|ICU| Interrupt Capture Unit|
|MAL| Old name of Microcontroller Abstraction Layer (replaced by MCAL because ‘MAL’ is| a french term meaning ‘bad’)|
|MCAL| Microcontroller Abstraction Layer|
|MCU |Microcontroller Unit|
|MMU| Memory Management Unit|
|NMI| Non maskable interrupt|
|OS| Operating System|
|PLL| Phase Locked Loop|
|PWM| Pulse Width Modulation|
|RX| Reception (in the context of bus communication)|
|SPAL| The name of this working group (Standard Peripheral Abstraction Layer)|
|SFR| Special Function Register|
|RTE| Runtime environment|
|WP| Work Package|
|STD| Standard|
|REQ| Requirement|
|UNINIT| Uninitialized (= not initialized)|

|Term|Description:|
|:--|:--|
|Master| A device controlling other devices (slaves, see below)|
|Slave| A device beeing completely controlled by a master device|

## 7 References
7.1 Deliverables of AUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture,
AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_GLOSSARY] Glossary,
AUTOSAR_TR_Glossary.pdf.pdf
[SRS_BSW_GENERAL] General Requirements on Basic Software Modules,
AUTOSAR_SRS_BSWGeneral.pdf
[SRS_BSW_SPAL] General Requirements on SPAL,
AUTOSAR_SRS_SPALGeneral.pdf
[TPS_STDT_0078] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

# 77 Requirements on Libraries
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_Libraries.pdf

|Library short name| Description|
|:--|:--|
|Mfx| Library of Mathematical FiXed point calculations|
|Mfl| Library of Mathematical FLoating point point calculations|
|Ifx| Library of Interpolation functions of FiXed point|
|Ifl| Library of Interpolation functions of FLoating point|
|Bfx| Library of Bit handling|
|Efx| Library of Extended functions on Fixed point|
|Crc| Library of CRC routines|
|E2E| SW-C End-to-End Communication Protection Library|

## 3 Acronyms and abbreviations
All technical terms used in this document, except the ones listed in the table below,
can be found in the official AUTOSAR glossary [].
Acronyms and abbreviations that have a local scope and therefore are not contained
in the AUTOSAR glossary, appear in the glossary below.

|Abbreviation /Acronym|Description|
|:--|:--|
|API| Application Programming Interface. Preferred term is "function".|
|AR, AR_ | Abbreviation used in place of AUTOSAR|
|BFX| Library of Bit handling|
|CRC| Cyclic Redundancy check|
|DET| Default Error Tracer|
|E2E| End to End|
|EcuM |ECU Manager|
|EFX |Extended function on Fixed point|
|IFL| Interpolation function s of FLoating point|
|IFX| Interpolation function s of FiXed point|
|MFL| Mathematical FLoating point calculation|
|MFX| Mathematical FiXed point calculation|
|OS| Operating System|

|Term|Description|
|:--|:--|
|Library| Set of APIs (i.e. functions) that may be called from any modules (BSW modules or SW-C)|

## 7 References
[1] Standardisation Template
AUTOSAR_TPS_StandardizationTemplate.pdf.

# 76 Requirements on LIN
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_LIN.pdf

## 3 Acronyms and abbreviations
>The ISO 17987 Glossary (clause 3 of each part) is kept as far as possible to make LIN knowledgably readers familiar with this document. Acronyms and abbreviations that are not found in the ISO 17987 Glossary and therefore are not contained in the AUTOSAR glossary are described here.

|Acronym|Description|
|:--|:--|
|LIN-PDU|LIN Protocol Data Unit is the LIN header and the LIN response, i.e. Break, synch, PID, Data (1-8) and checksum In the ISO 17987 specifications, this is called just frame. LIN_PDU is more precise and omits confusion.|
|LIN-SDU| LIN Service Data Unit. The data-part of the LIN response. |
|Schedule Table|A Schedule Table determines the traffic on a LIN bus (one channel). One LIN bus could have more than one Schedule Table.|
|Schedule Table Handler| The Schedule Table Handler is placed at the LIN Interface of a LIN master node. It will initiate LIN-PDU’s and confirm/indicate LIN-PDU’s. It will be called by upper layers.|
|Schedule Table Manager|Keeps track of all available schedule and processes the active schedule table in a LIN master node.|
|LIN Driver| Module name Lin. Describes the Software Driver.|
|LIN Interface| Module name LinIf. LIN Interface, describes the ISO 17987 protocol communication stack. |
|Sleep-mode| In the ISO 17987 specifications the term stand-by and sleep-mode is used in similar manner. To be consequent here only sleep-mode is used.|

 
|Abbreviation|Description|
|:--|:--|
|LIN|Local Interconnect Network|
|FF|First Frame|
|CF|Consecutive Frames|
|SF|Single Frames|
|N_PDU|Network Protocol Data Unit|
|PDUR|Protocol Data Unit Router|
|N_SDU|Network Service Data Unit|
|N_TA|Extended Addressing Mode Connection|
|UART|Universal Asynchronous Receiver Transmitter. Dear children have many names, it is also known as SCI and ESCI.|
|MRF|Master Request Frame|
|SRF|Slave Response Frame|
##4.3 References
4.3.1 Deliverables of AUTOSAR
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[4] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
4.3.2 Related standards and norms
[5] ISO 17987-1:2016 Road vehicles – Local Interconnect Network (LIN) – Part 1: General information and use case definition
[6] ISO 17987-2:2016 Road vehicles – Local Interconnect Network (LIN) – Part 2: Transport protocol and network layer services
[7] ISO 17987-3:2016 Road vehicles – Local Interconnect Network (LIN) – Part 3: Protocol specification
[8] ISO 14229-7:2015 Road vehicles – Unified diagnostic services (UDS) – Part 7: UDS on local interconnect network (UDSonLIN)
[9] ISO/TR 17987-5:2016 Road vehicles – Local Interconnect Network (LIN) – Part 5: Application programmers interface (API)
[10] ISO 17987-6:2016 Road vehicles – Local Interconnect Network (LIN) – Part 6: Protocol conformance test specification
Note: Non-ISO LIN specifications (LIN 2.2A and LIN 2.1 by LIN Consortium) are available at <https://www.lin-cia.org/standards/>, even after closure of the LIN Consortium.

# 75 Requirements on I-PDU Multiplexer
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_IPDUMultiplexer.pdf

## 3 Acronyms and abbrevations
>These are definitions made by AUTOSAR IPduM.

|Term|Description|
|:--|:--|
|contained I-PDU|I-PDU being transported inside a Container I-PDU|
|Container I-PDU|I-PDU serving as the Container collecting several I-PDUs to be transported together (e.g. in one frame)|
|dynamic part|According to the value of the selector field some parts of the I-PDU have a different layout. These parts of the I-PDU that can contain different signals are called dynamic part. The dynamic part must not necessarily be contiguous.|
|Multi-PDU-to- Container Mapping|Multi-PDU-to-Container Mapping means using the same Container I-PDU with more than one contained I-PDU. To be able to recognize each I-PDU at reception a header containing an ID and the length is placed in front of each contained I-PDU.|
|multiplexed I-PDU|I-PDU multiplexing means using the same PCI of an I-PDU with more than one unique layout of its SDU. A selector field is a part of the SDU of the multiplexed I-PDU. It is used to distinguish the different layouts of the multiplexed I-PDUs from each other|
|selector field|The selector field is part of a multiplexed I-PDU. It consists of contiguous bits. The value of the selector field selects the layout of the multiplexed part of the I-PDU.|
|static part|Some parts/signals of the I-PDU may be the same regardless of the selector field. Such a part is called static part. The static part must not necessarily be contiguous.|

|Acronym|Description|
|:--|:--|
|PCI|“Protocol Control Information” A description can be found on page 04-51 ff of (DOC_LAYERD_ARCH)|
|PDU|“Protocol Data Unit” A description can be found on page 04-51 ff of (DOC_LAYERD_ARCH).|
|PduR|Module that transfers I-PDUs from one module to another module. The I-PDU Router can be utilized for gateway operations and for internal routing purposes.|
|SDU|“Service Data Unit” A description can be found in chapter 4 of (DOC_LAYERD_ARCH).|



## 7 References
### 7.1 DeliverablesofAUTOSAR
[DOC_LAYERD_ARCH] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[DOC_SWS_COM] Specification of Communication AUTOSAR_SWS_COM.pdf
[DOC_TPS_STD] Standardization Template AUTOSAR_TPS_ StandardizationTemplate.pdf

# 74 Requirements on I/O Hardware Abstraction
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_IOHWAbstraction.pdf

##3 Acronyms and abbreviations 3.1 Expressions-general


|Expression|Description|Example|
|:--|:--|:--|
|Class|A class represents a kind of electrical connection to the ECU. It could be for example an analogue, a discrete,...|Analogue Class, Discrete Class...|
|Electrical Signal|It is the electrical signal on the pin of the ECU|Physical input voltage at an ECU- Pin|
|ECU pin|It is an hardware electrical connection of the ECU with the rest of the electronic system|
|ECU Signals|It is the software representation of an electrical signal. A signal has attributes and a symbolic name|Input voltage,Discrete Output, PWM Input ...|
|ECU Signal group|It is the software representation of a group of electrical signals from the same Class|Only for discrete Inputs and discrete Outputs|
|Attributes|Characteristics that can be Software (SW) and Hardware (HW) for each kind of Signals existing in a ECU|Range, Lifetime / delay, ...|
|Symbolic name|The symbolic name of a signal is used by the IO Hardware Abstraction module to make a link (function, pin)|

###3.2 Expressions-signalattributes
|Expression|Description|Example|
|:--|:--|:--|
|Data Type|Analogue: Datatype of the signal||
||Discrete: either bool or AUTOSAR defined type (BoolType)|(VoltageType, CurrentType, ResistanceType, BoolType) Each DataType has a given size: 16 bits or 32 bits|
|Range|This is a functional range and not an electrical range.) For analogue signals [lowerLimit...upperLimit] (Voltage, current), [0...upperLimit] (resistance) For discrete signals [0,1] For timing signals [0...upperLimit] (period), [- 100...100%] (Duty Cycle)|[-12Volts...+12Volts] (voltage)|
|Resolution| This attribute for many Classes is dependent on the range and the Data Type. Example: (upperLimit - lowerLimit) / (2datatypelength -1) For the others is known and defined.|Voltagemin = -12 Volts Voltagemax = 12 Volts Data Type : 16 bits Resolution => 24 / 65535|
|Hardware Resolution|This is the maximum possible resolution of the hardware (ADC)|ADC converter could have a 8/10/12/16 bits resolution|
|Hardware Accuracy|This is the accuracy of Hardware. It depends on hardware peripheral used for acquisition and/or generation|ADC converter could have an accuracy of +-3LSB|
|Accuracy|It depends of hardware peripheral used for acquisition and/or generation.|ADC converter could be a a 8/10/12/16 bits converter|
|Diagnosis|Diagnosis capability of the functionality|Diagnosis Not Supported (could be a static check) No valid information available Short to Power Supply Short to Ground Open Load Over Temperature Diagnosis OK|
|Synchronization|A signal could be synchronize with another signal or with an event like a trigger|If a discrete signal is “TRUE”, acquire an analogue signal|
|Access|Defines if the Signal is attached to a Get(Read) / Set(Write) feature.|
|Inversion| Inversion between the physical value and the logical value. This attribute is not visible and not configurable by users of IO Hardware Abstraction.| Physical HighState  -> (Signal=False) Physical LowState ->(Signal=True)|
|Lifetime| Only for Inputs: It is the maximum allowed age of the data (time is in microseconds). If Lifetime is 0, then the signal is directly get from the register.|Lifetime = 0 is a direct access Lifetime = 1000μs the value read is at maximum 1ms older|
|Delay|Only for Outputs: It is the maximum allowed time until an output is actually set (time is in microseconds) If Delay is 0, then the signal is set immediately|Delay = 0 is a direct access Delay = 100μs the command is set until 100μs elapse|
|Filtering / Debouncing|It defines if the Signal is provided as a raw value or if a filtering/debouncing method is included in the IO Hardware Abstraction module for this Signal.|Raw, Debounce 3 Samples, Wait 10ms,|
|Sampling Rate|Time period required to get a Signal value.|Sampling rate for a sampling windows (burst)|
|Report Changes|This attribute is only applicable to Discrete Inputs. It defines the capability (or not) of reporting level changes.|Enable or Disable|
|Pulse Test|This attribute means that the output shall be tested thanks a dedicated pulse. If this attribute is not set, diagnosis will be done while using the output.|Available or non available|
##7 References
7.1 DeliverablesofAUTOSAR
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

# 73 Requirements on ICU Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_ICUDriver.pdf

##3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Term| Description|
|:--|:--|
|Circular buffer|An area of memory used to store a continuous stream of data by starting again at the beginning of the buffer after reaching the end.|
|Duty Cycle|Percentage of High Time to Period Time (High Time / Period Time) * 100%|
|High Time|See Figure “ICU time definitions”. The standard type STD_HIGH shall be used.|
|ICU channel|Represents a logical ICU entity bound to one input signal and the hardware resources for the configured measurement mode.|
|Linear buffer|An area of memory used to store a stream of data by starting at the beginning of the buffer and stopping at the latest on reaching the end.|
|Low Time|See Figure “ICU time definitions”|
|Measurement mode|The measurement mode defines the capability for signal acquisition and evaluation. Possible modes: Signal Edge Detection / Notification  Signal Measurement  Timestamp Edge Counter |
|Measurement mode, Edge counter|Functionality of an Edge Counter, counting of external edges|
|Measurement mode, Signal Edge Detection|Notification on signal edges.|
|Measurement mode, Signal Measurement|Measurement of elapsed High Time, elapsed Low Time, elapsed Period Time and Duty Cycle of an input signal.|
|Measurement mode, Timestamp|Generation of timestamps for signal edges, see Figure “ICU time stamp”|
|Period Time|See Figure “ICU time definitions”|

|Acronym| Description|
|:--|:--|
|DIO|Digital Input Output|
|ECU|Electric Control Unit|
|ICU|Input Capture Unit|
|MAL|Old name of Microcontroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a French term meaning ‘male’)|
|MCAL|Microcontroller Abstraction Layer|
|MCU|Microcontroller Unit|
|PWD|Pulse width demodulation|
|SPAL|Standard Peripheral Abstraction Layer|
|STD|Standard|
|UNINIT| Uninitialized (= not initialized)|

## 7 References
[1] Glossary
AUTOSAR_TR_Glossary.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

#72 Requirements on Hardware Test Manager on start up and shutdown
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_HWTestManager.pdf

##3 Acronyms and abbreviations

|Abbreviation / Acronym|Description|
|:--|:--|
|ADC|Analog to Digital converter|
|BIST|Built In Self Test|
|BSW|Basic Software|
|ECU|Electronic Control Unit|
|ECUM|Electronic Control Unit Manager|
|HTMSS|Hardware Test Management startup shutdown|
|MCU|Micro Controller Unit|
|MSTP|Microcontroller Specific Test Package|

## 6 References
6.1 Deliverables of AUTOSAR
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] Technical report HTMSS TR_HWTestManagementIntegrationGuide.pdf
[3] Specification of HTMSS AUTOSAR_SWS_HTMSS.pdf
6.2 Related standards and norms
The ISO26262 part 5 chapter 8 requirements for hardware architecture metrics.

#71 Requirements on Gateway
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_Gateway.pdf

##3 Acronyms and abbrevations
The following glossary defines acronyms and terms that are not defined by the AUTOSAR glossary.

|term|Description|
|:--|:--|
|Routing Configuration|Configuration data that controls the operation of the PDU Router and Signal Gateway. The configuration data defines the destination for each PDU of the PDURouter and each Signal of the signal gateway. The routing configuration should be encapsulated in a way that allows an update.|

|Acronym|Description|
|:--|:--|
|Gw |abbreviation of signal based gateway|


## 7 References
7.1 DeliverablesofAUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[DOC_COMSTACK_TYPES] Specification of Communication Stack Types, AUTOSAR_SWS_CommunicationStackTypes.pdf
[DOC_COM_SRS] Requirements on Communication, AUTOSAR_SRS_COM.pdf
[DOC_ GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[DOC_GENERAL_SRS] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
7.2 Relatedstandardsandnorms [DOC_ISO_TP] ISO transport protocol specification,
http://www.iso.org

ISO/IEC 8073:1988 [ISO/IEC 8073:1988]
Information processing systems — Open Systems Interconnection — Connection oriented transport protocol specification

#70 Requirements on GPT Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_GPTDriver.pdf


4 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS|Chip select|
|DIO|Digital Input Output|
|ECU|Electric Control Unit|
|EOL|End Of Line Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|ICU|Input Capture Unit|
|MAL|Old name of Microconroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL|Microconroller Abstraction Layer|
|MCU|Microcontroller Unit|
|MMU|Memory Management Unit|
|NMI|Non maskable interrupt|
|OS|Operating System|
|PLL|Phase Locked Loop|
|PWM|Pulse Width Modulation|
|RX|Reception (in the context of bus communication)|
|SPAL|The name of this working group (Standard Peripheral Abstraction Layer)|
|SFR|Special Function Register|
|RTE|Runtime environment|
|WP|Work Package|
|STD|Standard|
|REQ|Requirement|
|UNINIT|Uninitialized (= not initialized)|

|term| Description|
|:--|:--|
|Master|A device controlling other devices (slaves, see below)|
|Slave|A device being completely controlled by a master device|

##7 References
7.1 Deliverables of AUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[SRS_BSW_GENERAL] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[SRS_BSW_SPAL] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

#70 Requirements on GPT Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_GPTDriver.pdf

##4 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS|Chip select|
|DIO|Digital Input Output|
|ECU|Electric Control Unit|
|EOL|End Of Line Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|ICU|Input Capture Unit|
|MAL|Old name of Microconroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL|Microconroller Abstraction Layer|
|MCU|Microcontroller Unit|
|MMU|Memory Management Unit|
|NMI|Non maskable interrupt|
|OS|Operating System|
|PLL|Phase Locked Loop|
|PWM|Pulse Width Modulation|
|RX|Reception (in the context of bus communication)|
|SPAL|The name of this working group (Standard Peripheral Abstraction Layer)|
|SFR|Special Function Register|
|RTE|Runtime environment|
|WP|Work Package|
|STD|Standard|
|REQ|Requirement|
|UNINIT|Uninitialized (= not initialized)|

|term| Description|
|:--|:--|
|Master|A device controlling other devices (slaves, see below)|
|Slave|A device being completely controlled by a master device|

##7 References
7.1 Deliverables of AUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[SRS_BSW_GENERAL] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[SRS_BSW_SPAL] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

# 69 Requirements on Function Inhibition Manager
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_FunctionInhibitionManager.pdf

## 3 Acronyms and abbreviations
      
|term| Description|
|:--|:--|
|Activity state| The activity state is the status of a software component being executed. The activity state results from the permission state as a precondition and also physical enable conditions. It is not calculated by the FIM and not available as a status variable. It could only be derived from local information within a software component.|
|Functionality|Functionality comprises User-visible and User-non-visible functional aspects of a system (AUTOSAR_Glossary.pdf [2]). In addition to that - in the FIM context - a functionality can be built up of the contents of one, several or parts of runnable entities with the same set of permission / inhibit conditions. By means of the FIM, the inhibition of these functionalities can be configured and even modified by calibration. Each functionality is represented by a unique function ID. A functionality is featured by a specific set of inhibit condition in contrast to runnable entities having specific scheduling conditions.|
|IUMPR|In Use Monitoring Performance Ratio: The In-Use-Monitor Performance Ratio (IUMPR) indicates how often the OBD system monitors, particular components, compared to the amount of the vehicle operation. It is defined as the number of times a fault could have been found (=numerator) divided by the number of times the vehicle operation has been fulfilled (=denominator) as defined in the respective OBD regulations.|
|Monitoring function| • Part of the Software Component. • Mechanism to monitor and finally to detect a fault of a certain sensor, actuator or could be a plausibility check • Reports states about events from internal processing of a SW-C or from further processing of return values of other basic software modules. • See also AUTOSAR_SWS_DEM|
|Permission state| The permission state contains the information whether a functionality, represented by its FID, can be executed or whether it shall not run. The state is controlled by the FIM based on reported events.|
|Runnable entity|A Runnable Entity is a part of an Atomic Software-Component which can be executed and scheduled independently from the other Runnable Entities of this Atomic Software-Component. It is described by a sequence of instructions that can be started by the RTE. Each runnable entity is associated with exactly one EntryPoint.|

|Abbreviation / Acronym| Description|
|:--|:--|
|API| Application Programming Interface|
|BSW| Basic Software|
|DEM| Diagnostic Event Manager|
|ECU| Electronic Control Unit|
|EOL| End Of Line|
|ESD| Electro Static Disturbance|
|ESP| Electronic Stability Program|
|FID| Function Identifier|
|FIM| Function Inhibition Manager|
|HW| Hardware|
|ID| Identification/Identifier|
|ISO| International Standardization Organization|
|MIL| Malfunction Indication Light|
|NVRAM| Non volatile Memory|
|OBD| Onboard Diagnostics|
|OEM| Original Equipment Manufacturer|
|OS| Operating System|
|RAM| Random Access Memory|
|ROM| Read-only Memory|
|RTE| Runtime Environment|
|SW-C|Software Components|
|Xxx_|Placeholder for an API provider|

##6 References 6.1 Deliverables of AUTOSAR
[1]Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3]Requirements on AUTOSAR Features AUTOSAR_RS_Features
###6.2 6.2.1 ITEA-EAST,  Related standards and norms
[10] D1.5-General Architecture; ITEA/EAST-EEA, Version 1.0; chapter 3, page 72 et seq.
[20] D2.1-Embedded Basic Software Structure Requirements; ITEA/EAST-EEA, Ver- sion 1.0 or higher
[30] D2.2-Description of existing solutions; ITEA/EAST-EEA, Version 1.0 or higher.

# 68 Requirements on Free Running Timer
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_FreeRunningTimer.pdf

##3 Acronyms and Abbreviations

|Abbreviation| Description|
|:--|:--|
|API|Application Programming Interface|
|BSW|Basic Software|
|COM|Communications|
|ECU|Electronic Control Unit|
|GPT|General Purpose Timer (SWS Module)|
|HW|Hardware|
|OS|AUTOSAR Operating System|
|SI|International System of Units (abbreviated SI from the French language name Système International d'Unités)|
|SLA|Software Layered Architecture|
|SWC|Software Component|
|SWFRT|Software extending features of HW Free running timers|


|Term| Description|
|:--|:--|
|Tick|One increment of the HW timer =HW Timer Tick; If not explicitly noted Hardware timer is meant. TickType consists of many HW-Timer Ticks; If this is meant it will be pointed out explicitly.|
|Interval of Timer|Distance in time between two measure points|
|Range of Timer|Maximum interval the timer may cover|
|Reset Timer|Timers which start on exceeding of a predefined margin with an also predefined value.|
|Resolution of Timer|Minimal time interval which may be measured|
|Test Value|Value against which the present read out is tested (e.g. compared).|
|Wrap Around|The action taken when a timer reaches the defined maximum value.|

##7 Referenced AUTOSAR documents
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] Glossary AUTOSAR_TR_Glossary.pdf
[3] Specification of GPT Driver AUTOSAR_SWS_GPTDriver.pdf
[4] Specification of Operating System AUTOSAR_SWS_OS.pdf
[5] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

#67 Requirements on FlexRay
URL ??
## 3 Acronyms and abbreviations
The following acronyms and abbreviations are being used throughout this document

|Acronym|Description|
|:--|:--|
|SW|Software|
|BSW|Basic Software|
|DEM|Diagnostic Event Manager BSW module|
|ComM|CommunicationManager BSW module|
|CC| (FlexRay) Communication Controller|
|i.e.|[lat.] id est = [eng.] that is|
|e.g.|[lat.] exempli gratia = [eng.] for example|

##7 References
7.1 DeliverablesofAUTOSAR
[GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[LSA] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[VFB] Virtual Function Bus, AUTOSAR_EXP_VFB.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
7.2 RelatedStandardsandNorms 7.2.1 FlexRay
[FR_PROT_SPEC] FlexRay Communications System Protocol Specification Version 2.1 Revision A,
http://www.FlexRay.com
[FR_EPL_SPEC] FlexRay Communications System Electrical Physical Layer Specification Version 2.1 Revision A,
http://www.FlexRay.com
7.2.2 ISO
[ISO_10681-2] ISO/DIS 10681-2 , Road vehicles – Communication on FlexRay – Part 2: Communication Layer services

#66  Requirements on Flash Test
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_FlashTest.pdf

## 3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|ECU|Electric Control Unit|
|EOL|End Of Line. Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|CRC|Cyclic Redundancy Check|
|MCAL|Microcontroller Abstraction Layer|
|MCU|Microcontroller Unit|
|NMI|Non maskable interrupt|
|OS|Operating System|
|DEM|Diagnostic Event Manager|
|SFR|Special Function Register|
|RTE|Runtime environment|
|WP|Work Package|
|ECC|Error Correction Code|
|STD |Standard|
|REQ|Requirement|
|UNINIT|Uninitialized (= not initialized)|
 
|Term|Description|
|:--|:--|
|signature|Unique calculation result of the content of a specific memory block|
|Memory scrubbing|Automatic sequential data reading to trigger detection/verification mechanisms typical ECC.|
|Invariable memory|Invariable memory can be program flash, program SRAM, locked cache and ROM|
|Background test|Background test is called periodically by a scheduler, and is interruptible. The test is split up over many scheduled tasks.|
|Foreground test|Foreground test is called via users call.|
|Test interval|Interval of a complete Flash test in background mode|

##7 References Deliverables of AUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[SRS_BSW_GENERAL] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[SRS_BSW_SPAL] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[SWS_BSW] Specification of Diagnostic Event Manager, AUTOSAR_SWS_DiagnosticEventManager.pdf
[SWS_BSW] Specification of Default Error Tracer, AUTOSAR_SWS_DefaultErrorTracer.pdf
[SWS_BSW_MCAL] Specification of RAM Test, AUTOSAR_SWS_RAMTest.pdf
[SWS_BSW] Specification of ECU state manager, AUTOSAR_SWS_ECUStateManager.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

#65 Requirements on Flash Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_FlashDriver.pdf

3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Acronym / Description| Abbreviation|
|:--|:--|
|CS| Chip select|
|DIO| Digital Input Output|
|ECU| Electric Control Unit|
|EOL| End Of Line. Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|ICU| Interrupt Capture Unit|
|MAL| Old name of Microconroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL| Microconroller Abstraction Layer|
|MCU| Microcontroller Unit|
|MMU| Memory Management Unit|
|NMI| Non maskable interrupt|
|OS| Operating System|
|PLL| Phase Locked Loop|
|PWM| Pulse Width Modulation|
|RX| Reception (in the context of bus communication)|
|SPAL| The name of this working group|
|SFR| Special Function Register|
|RTE| Runtime environment|
|WP| Work Package|
|STD| Standard|
|REQ| Requirement|
|UNINIT| Uninitialized (= not initialized)|

|Term| Abbreviation|
|:--|:--|
|Master| A device controlling other devices (slaves, see below)|
|Slave| A device beeing completely controlled by a master device|

##7 References
7.1 Deliverables of AUTOSAR
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[5] Software Standardization Template
AUTOSAR_TPS_StandardizationTemplate.pdf

#64 Requirements on Ethernet Support in AUTOSAR
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_Ethernet.pdf

## 2.1 Acronymsandabbreviations
 
|Abbreviation / Description| Acronym|
|:--|:--|
|ARP| Address Resolution Protocol|
|COTS| Commercial Of The Shelf|
|DAD| Duplicate Address Detection|
|DEM| Diagnostic Event Manager|
|DET| Default Error Tracer|
|DHCP| Dynamic Host Configuration Protocol|
|DHCPv4| Dynamic Host Configuration Protocol for Internet Protocol Version 4|
|DHCPv6| Dynamic Host Configuration Protocol for Internet Protocol Version 6|
|DoIP| Diagnostics over IP|
|HTTP| HyperText Transfer Protocol|
|IANA| Internet Assigned Numbers Authority|
|ICMP| Internet Control Message Protocol|
|ICMPv4| Internet Control Message Protocol for Internet Protocol Version 4|
|ICMPv6| Internet Control Message Protocol for Internet Protocol Version 6|
|IETF| Internet Engineering Task Force|
|IP| Internet Protocol|
|IPv4| Internet Protocol for Version 4|
|IPv6| Internet Protocol for Version 6|
|MTU| Maximum Transmission Unit|
|NDP| Neighbor Discovery Protocol|
|SoAd| AUTOSAR Socket Adaptor Module|
|TCP| Transmission Control Protocol|
|TCP/IP| A family of communication protocols used in computer networks|
|TLS| Transport Layer Security|
|UDP| User Datagram Protocol|
|UdpNm| AUTOSAR UDP Network Management Module|
|XCP| eXtended Calibration Protocol|

## 6 References
Requirements on Ethernet Support in AUTOSAR AUTOSAR CP R19-11
[1] Requirements on AUTOSAR Features AUTOSAR_RS_Features.pdf
### 6.1 DeliverablesofAUTOSAR
[2] AUTOSAR Layered Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] AUTOSAR UDP Network Management AUTOSAR_SWS_UDPNetworkManagement.pdf
[4] AUTOSAR Ethernet State Manager AUTOSAR_SWS_EthernetStateManager.pdf
[5] AUTOSAR Socket Adaptor AUTOSAR_SWS_SocketAdaptor.pdf
[6] AUTOSAR Ethernet Interface AUTOSAR_SWS_EthernetInterface.pdf
[7] SoftwareComponentTemplate AUTOSAR_TPS_SoftwareComponentTemplate.pdf
### 6.2 Relatedstandardsandnorms
[8] IEC 7498-1, “The Basic Model”, IEC Norm, 1994
[9] IEEE Std. 1003.1TM, 2004 Edition, “POSIX” http://www.opengroup.org/onlinepubs/000095399/
[10] ISO 13400-2 Diagnostic communication over Internet Protocol (DoIP) June 2012
[11] XCP, The Universal Measurement and Calibration Protocol Family, ASAM e.V., 2003
[12] IEEE Standard 802.1ASTM- 30 of March 2011
http://standards.ieee.org/getieee802/download/802.1AS-2011.pdf
[13] ISO 14229, Road vehicles — Unified diagnostic services (UDS)
### 6.2.1 IETF Requests For Comments (RFCs)
[14] IETF RFC 791 Internet Protocol - DARPA Internet Program – Protocol Specification (September 1981)
[15] IETF RFC 793 Transmission Control Protocol - DARPA Internet Program - Protocol Specification (September 1981)
[16] IETF RFC 768 User Datagram Protocol (August 1980)
[17] IETF RFC 1122 Requirements for Internet Hosts - Communication Layers (October 1989)
[18] RFC 896, "Congestion Control in IP/TCP Internetworks", (Nagle algorithm)
[19] IETF RFC 2131
[20] IETF RFC 826  Dynamic Host Configuration Protocol (March 1997) An Ethernet Address Resolution Protocol (November 1982)

Internet Control Message Protocol DARPA Internet
DHCP Options and BOOTP Vendor Extensions (March Dynamic Configuration of IPv4 Link-Local Addresses (May
Internet Protocol, Version 6 (IPv6) (December 1998) Path MTU Discovery for IP version 6 (August 1996) IP Version 6 Addressing Architecture (February 2006) Transmission of IPv6 Packets over Ethernet Networks
Default Address Selection for Internet Protocol Version 6 Handling of Overlapping IPv6 Fragments (December Deprecation of Type 0 Routing Headers in IPv6
IPv6 Stateless Address Autoconfiguration (September Optimistic Duplicate Address Detection (DAD) for IPv6
Internet Control Message Protocol (ICMPv6) (March 2006) Neighbor Discovery for IP version 6 (September 2007) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
[21] IETF RFC 792
Program - Protocol Specification (September 1981)
[22] IETF RFC 2132 1997)
[23] IETF RFC 3927 2005)
[24] IETF RFC 2460
[25] IETF RFC 1981
[26] IETF RFC 4291
[27] IETF RFC 2464
(December 1998)
[28] IETF RFC 6724 (September 2012)
[29] IETF RFC 5722 2009)
[30] IETF RFC 5095 (December 2007)
[31] IETF RFC 4862 2007)
[32] IETF RFC 4429 (April 2006)
[33] IETF RFC 4443
[34] IETF RFC 4861
[35] IETF RFC 3315
(July 2003)
The Dynamic Host Configuration Protocol for IPv6
[36] IETF RFC 4704
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (October 2006)
[37] IETF RFC 6582 The NewReno Modification to TCP's Fast Recovery Algorithm (April 2012)
[38] IETF RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (July 2010)
[39] IETF RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
[40] IETF RFC 6437 IPv6 Flow Label Specification
[41] IETF RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2
[42] IETF RFC 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
[43] IETF RFC 4279 (TLS)
Pre-Shared Key Ciphersuites for Transport Layer Security
[44] IETF RFC 4301 Security Architecture for the Internet Protocol
[45] IETF RFC 4302 IP Authentication Header
[46] IETF RFC 4303 IP Encapsulating Security Payload (ESP)
[47] IETF RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2)
 
#63 Requirements on EEPROM Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_EEPROMDriver.pdf

## 3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS|Chip select|
|DIO|Digital Input Output|
|ECU|Electric Control Unit|
|EOL|End Of Line.Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|ICU|Interrupt Capture Unit|
|MAL|Old name of Microconroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL|Microcontroller Abstraction Layer|
|MCU|Microcontroller Unit|
|MMU|Memory Management Unit|
|Master|A device controlling other devices (slaves, see below)|
|Slave|A device beeing completely controlled by a master device|
|NMI|Non maskable interrupt|
|OS|Operating System|
|PLL|Phase Locked Loop|
|PWM|Pulse Width Modulation|
|RX|Reception (in the context of bus communication)|
|SPAL|The name of this working group|
|SFR|Special Function Register|
|RTE|Runtime environment|
|WP|Work Package|
|STD|Standard|
|REQ|Requirement|
|UNINIT|Uninitialized (= not initialized)

>As this is a document from professionals for professionals, all other terms are expected to be known.

##7 References
7.1 DeliverablesofAUTOSAR
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[2] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[4] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[5] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

#62 Requirements on DIO Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_DIODriver.pdf

##3 Acronyms and abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Acronym| Description|
|:--|:--|
|CS|Chip select|
|DIO|Digital Input Output|
|ECU|Electric Control Unit|
|EOL|End Of Line.Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|ICU|Interrupt Capture Unit|
|MAL|Old name of Microconroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a french term meaning ‘bad’)|
|MCAL|Microconroller Abstraction Layer|
|MCU|Microcontroller Unit|
|MMU|Memory Management Unit|
|NMI|Non maskable interrupt|
|OS|Operating System|
|PLL|Phase Locked Loop|
|PWM|Pulse Width Modulation|
|RX|Reception (in the context of bus communication)|
|SPAL|The name of this working group|
|SFR|Special Function Register|
|RTE|Runtime environment|
|WP|Work Package|
|STD|Standard|
|REQ|Requirement|
|UNINIT|Uninitialized (= not initialized)|

|Term| Description|
|:--|:--|
|Master|A device controlling other devices (slaves, see below)|
|Slave|A device beeing completely controlled by a master device|

##7 References
7.1 Deliverables of AUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[SRS_BSW_GENERAL] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[SRS_BSW_SPAL] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

#61 Requirements on Crypto Stack
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_CryptoStack.pdf

##3 Acronyms and abbreviations
 
|Abbreviation / Acronym|Description |
|:--|:--|
|μC| Microcontroller|
|AES| Advanced Encryption Standard|
|CBC| Cipher Block Chaining|
|CDD| Complex Device Driver|
|CFB| Cipher Feedback|
|CMAC| Cipher-based Message Authentication Code|
|CPU| Central Processing Unit|
|CRYPTO /Crypto| Crypto Driver|
|CRYIF / CryIf| Crypto Interface|
|CSM / Csm| Crypto Service Manager|
|DET / Det| Default Error Tracer|
|ECB| Electronic Code Book|
|ECC| Elliptic Curve Cryptography|
|ECDH| Elliptic Curve Diffie–Hellman|
|ECDSA| Elliptic Curve Digital Signature Algorithm|
|ECU| Electronic Control Unit|
|GCM| Galois Counter Mode|
|GMAC| Galois-based Message Authentication Code|
|HMAC| Hash-based Message Authentication Code|
|HSM / Hsm| Hardware Security Module|
|HW| HardWare|
|KEM| Key Encapsulation Mechanism|
|KeyM| Key Manager|
|MAC| Message Authentication Code|
|MCAL| Micro Controller Abstraction Layer|
|OEM| Original Equipment Manufacturer|
|OFB| Output Feedback|
|PKI| Public Key Infrastructure|
|PRNG| Pseudo-Random Number Generator|
|RACE| Rapid Automatic Cryptographic Equipment|
|RAM| Random Access Memory|
|RIPEMD| RACE Integrity Primitives Evaluation Message Digest|
|RSA| Rivest-Shamir-Adleman Cryptosystem|
|RTE| Run Time Environment|
|SHA| Secure Hash Algorithm|
|SECOC / SecOc| Secure Onboard Communication|
|SW| SoftWare|
|SWC| SoftWare Component|
|SWS| SoftWare Specification|
|TRNG| True Random Number Generator|
|Vi| VendorId|
|XEX| Xor-Encrypt-Xor|
|XTS|XEX-based tweaked-codebook mode with ciphertext stealing|
## 3.1 Glossary of Terms
 
|Terms|Description|
|:--|:--|
|Crypto Driver Object|A Crypto Driver Object is an instance of a crypto module (hardware or software), which is able to perform one or more different crypto operations.|
|User|A user is a configured object with an ID and configured jobs.|
|Channel|A channel is the path from a Crypto Service Manager queue via the Crypto Interface to a specific Crypto Driver Object.|
|Job|A job is an instance of a user’s configured cryptographic primitive.|
|Primitive|A primitive is an instance of a configured cryptographic algorithm realized in a Crypto Driver Object. Among others it refers to a functionality provided by the CSM to the application, the concrete underlining 'algorithmfamily' (e.g. AES, MD5, RSA, etc.), and a 'algorithmmode' (e.g. ECB, CBC, etc).|
|Operation|An operation of a crypto primitive declares what part of the crypto primitive shall be performed. There are three different operations:|
|START|Operation indicates a new request of a crypto primitive, and it shall cancel all previous requests.|
|UPDATE|Operation indicates, that the crypto primitive expect input data.|
|FINISH|Operation indicates, that after this part all data are fed completely and the crypto primitive can finalize the calculations. It is also possible to perform more than one operation at once by concatenating the corresponding bits of the operation_mode argument.|
|Priority|The priority of a user defines the importance of it. The higher the priority (as well in value), the more immediate the user's job will be executed. The priority of a cryptographic job is part of the user’s configuration.|
|Service|A service shall be understand as defined in the TR_Glossary document: A service is a type of operation that has a published specification of interface and behavior, involving a contract between the provider of the capability and the potential clients.|

##7 References
7.1 Deliverables of AUTOSAR


[1]General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[2]Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[3]Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
[4] Specification of System Template AUTOSAR_TPS_SystemTemplate.pdf

#60 Requirements on Core Test
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_CoreTest.pdf

##3 Acronyms and Abbreviations

|Acronym|Description|
|:--|:--|
|CPU|Central Processing Unit|
|MPU|Memory Protection Unit|
|L1|1st level memory|
|L2|2nd level memory|
|MCU|Microcontroller Unit|
|BIST|Built in Self Test|
|IRQ|Interrupt Request|
|PCB|Printed Circuit Board| 

|Term|Description|
|:--|:--|
|Core|A CPU plus closely located functional resources|
|Atomic sequence/ atomic part|Sequence of software code execution which must not be interrupted at any time|
|Partial test|A partial test is defined as the test of one or more ‘hardware resources’. (A partial test is interruptible because it is executed in background mode).|
|External device|A physical external entity; e.g. a second microcontroller|
|Resource|A core internal unit which executes a unique functionality (e.g. IRQ-controller)|
|Checksum/ signature|A numerical representation of the result of a test execution or atomic sequence of a test execution.|
|Caller/calling entity|The caller/calling entity is located on a higher AUTOSAR or ISO layer. It is the user of the API call.|
|Background test|Background test is called periodically by a SW-scheduler.|
|Foreground test|Foreground test is called via users call.|
|Golden (Ref.) Value|Reference value used for comparison (e.g. Checksum/Signature)|
|Good Case|The execution finished without reporting an error|

## 7 References
7.1 DeliverablesofAUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[AUTOSAR_GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[SRS_BSW_GENERAL] General Requirements on Basic Software Modules, AUTOSAR_SRS_BSWGeneral.pdf
[SRS_BSW_SPAL] General Requirements on SPAL, AUTOSAR_SRS_SPALGeneral.pdf
[SWS_BSW_DEM] Specification of Diagnostic Event Manager, AUTOSAR_SWS_DiagnosticEventManager.pdf
[SWS_BSW_ECU] Specification of ECU state manager, AUTOSAR_SWS_ECUStateManager.pdf
[RS_Features] Requirements on AUTOSAR Features, AUTOSAR_RS_Features.pdf
[TPS_STDT_0078] Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf 7.2 Relatedstandardsandnorms
ISO DIS 26262

#59 Requirements on Communication

##2 Acronyms and Abbreviations

| term|description|
|:--|:--|
|AUTOSAR data type|See 7.1, section 6.4|
|I-PDU|Interaction Layer Protocol Data Unit (assembled and disassembled in AUTOSAR COM), consists of one or more signals (see below and [DOC_LAYER]).|
|I-PDU group|An I-PDU Group is an arbitrary collection of I-PDUs of the same direction (i.e. send or receive) in COM|
|L-PDU|Data Link Layer Protocol Data Unit (assembled and disassembled in AUTOSAR Hardware Abstraction layer, see [DOC_LAYER]).|
|signal|A signal in the AUTOSAR COM context is equal to a message in [DOC_ISO_COM]. An AUTOSAR signal is carried by one or more signals in COM. The transformation from an AUTOSAR signal to a signal in COM is carried out by the RTE. Typically the transformation preserves the syntax of the data. However, in the case of complex data types the transformation may change the syntax of the signal. Therefore a signal in AUTOSAR COM is not always the same as an AUTOSAR signal.|
|signal group|A signal group refers to a set of signals that must always be kept together in a common I-PDU.　A Signal group is used to guarantee the consistent transfer of AUTOSAR composite data types.　A signal group has the following properties:　・ A signal can belong to at most one signal group　・ A signal group can not belong to more than exactly one I-PDU　・ Signal groups do not overlap each other within an I-PDU　・ Signal groups are a contiguous set of signals which belong to this group, however it is possible to have unused bits (“holes”) within a group.　・ Signal groups may contain no signals (“may be empty”).　The grouping of signals to signal groups is assumed to be provided as an input for the COM generation process|


|Abbreviations|description|
|:--|:--|
|LOM|Listen Only Mode|


##7 References
7.1 Deliverables of AUTOSAR
[DOC_LAYER] Layered Sofware Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[DOC_COM_TYPES] Specification of Communication Stack Types AUTOSAR_SWS_CommunicationStackTypes.pdf
[DOC_VFB] Specification of the Virtual Functional Bus AUTOSAR_EXP_VFB.pdf
[DOC_ECUC] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[DOC_SWS_RTE] Specification of RTE Software AUTOSAR_SWS_RTE.pdf
[DOC_SWS_COM] Specification of Communication AUTOSAR_SWS_COM.pdf
[DOC_SWS_LDCOM]
Specification of Large Data COM AUTOSAR_SWS_LargeDataCOM.pdf
[DOC_TR_GLOS] Glossary AUTOSAR_TR_Glossary.pdf
[DOC_TPS_SWC] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[DOC_RS_Features] Requirements on AUTOSAR Features AUTOSAR_RS_Features.pdf
[TPS_STDT] Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf

###7.2 ISO
[DOC_ISO_GLOS] ISO 17356-1:2005 Road vehicles -- Open interface for embedded automotive applications -- Part 1: General structure and terms, definitions and abbreviated terms
[DOC_ISO_COM] ISO 17356-4:2005 Road vehicles -- Open interface for embedded automotive applications -- Part 4: OSEK/VDX Communication (COM)

#58 Requirements on CAN
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_CAN.pdf

##3 Acronyms and abbrevations

|Term|Description|
|:--|:--|
|CAN Communication Matrix|Describes the complete CAN network:・  Participating nodes・  Definition of all CAN PDUs (Identifier, DLC) ・  Source and Sinks for PDUs Format is defined in other AUTOSAR workpackage|
|Physical Channel|A physical channel represents an interface to the CAN Network. Different physical channels of the CAN Hardware Unit may access different networks.|
|L-PDU|CAN (Data Link Layer) Protocol Data Unit. Consists of Identifier, DLC and Data (L-SDU).|
|L-SDU|CAN (Data Link Layer) Service Data Unit. Data that is transported inside the L- PDU.|
|Hardware Object|A Hardware Object is defined as message buffer inside the CAN RAM of the CAN Hardware Unit. Also often called Message Object|
|Hardware Object Handle|The hardware object handle (HOH) is defined and provided by the CAN Driver. Typically each HOH represents a hardware object. The HOH is used as parameter by the CAN Interface Layer for transmit and read requests to the CAN Driver.|
|L-PDU Handle|The L-PDU handle is defined and placed inside the CAN Interface Layer. Typically each handle represents a L-PDU or a range of L-PDUs, and is a constant structure with information for Tx/Rx processing.|
|CAN Controller|A CAN controller serves exactly one physical channel. See Figure "Typical CAN HW Unit" in CAN Interface SWS.|
|CAN Hardware Unit|A CAN hardware unit may consist of one or multiple CAN controllers of the same type and one or multiple CAN RAM areas. The CAN hardware unit is either on- chip, or an external device. The CAN hardware unit is represented by one CAN Driver. See Figure "Typical CAN HW Unit" in CAN Interface SWS.|
|Multiplexed Transmission|Usage of three TX HW objects, which are represented as one transmit entity (Hardware Object Handle) to the upper layer. Used for Outer Priority Inversion avoidance|
|Inner Priority Inversion|Transmission of a high-priority L-PDU is prevented by the presence of a pending low-priority L-PDU in the same physical channel.|
|Outer Priority Inversion|Occurs when a time gap is between two consecutive TX L-PDU transmissions. In this case a lower priority L-PDU from another node can prevent sending the next L-PDU because the higher priority L-PDU can't participate in the running bus arbitration because it comes too late.|
|Bus|A bus represents a CAN or LIN network. A bus has a given physical behavior (e.g. CAN low-speed or high-speed). A bus may support wakeup via bus or is “always on”.|
|static configuration|Configuration, that is not changeable during runtime. This means that a configuration is typically done once during startup phase of the ECU. This concern is independent from the possibilities to introduce the configuration parameters into the ECU itself: Pre-Compile-Time, Link-Time or Post-Build-Time|

|Acronym|Description|
|:--|:--|
|N-PDU|Network Protocol Data Unit of the CAN Transport Layer|
|N-SDU|Service Data Unit of the CAN Transport Layer. Data that is transported inside the N-PDU.|
|STmin|Separation Time min|
|BS|Block Size|
|HTH|CAN hardware transmit handle|

##7 References
7.1 Deliverables of AUTOSAR
[Can] Specification of CAN Driver AUTOSAR_SWS_CANDriver.pdf
[CanIf] Specification of CAN Interface AUTOSAR_SWS_CANInterface.pdf
[CanSM] Specification of CAN State Manager AUTOSAR_SWS_CANStateManager.pdf
[CanTp] Specification of CAN Transport Layer AUTOSAR_SWS_CANTransportLayer.pdf
[CanTrcv] Specification of CAN Transceiver Driver AUTOSAR_SWS_CANTransceiverDriver.pdf
[SrsSpal] General Requirements on SPAL AUTOSAR_SRS_SPALGeneral.pdf
[SrsGeneral] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
####7.2 Relatedstandardandnorms 7.2.1 ISO
ISO 15765-2(2004-10-12), Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part2: Network layer services
ISO 15765-3(2004-10-06), Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part3: Implementation of diagnostic services
ISO 15765-4(2005-01-04), Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part4: Requirements for emissions-related systems

# 57 Requirements on Bus Mirroring
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_BusMirroring.pdf

##3 Acronyms and Abbreviations
Currently, the Bus Mirroring module does not define any acronyms, abbreviations, or terms that are not defined in the [2, AUTOSAR glossary].

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

# 56 General Requirements on Basic Software Modules

##3 Acronyms and abbreviations

|Term|Description|
|:--|:--|
|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|

|Acronym|Description|
|:--|:--|
|ISR|Interrupt Service Routine. Also used as a macro to declare in C a cat2 interrupt service routine.|
|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.|

##6 References
6.1 DeliverablesofAUTOSAR
[DOC_LAYERED_ARCH] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[DOC_MOD_LIST] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[ECU_CONF_SRS] Requirements on ECU Configuration AUTOSAR_RS_ECUConfiguration.pdf
[ECU_CONF_SWS] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[GLOSSARY] Glossary, AUTOSAR_TR_Glossary.pdf
[DOC_STDTYPE_SWS] Specification of Standard Types, AUTOSAR_SWS_StandardTypes.pdf
[DOC_MEMMAP_SWS] Specification of Memory Mapping, AUTOSAR_SWS_MemoryMapping.pdf
[DOC_BSWSCHED_SWS] Specification of BSW Scheduler, AUTOSAR_SWS_BSW_Scheduler.pdf
[ARReleaseManagement] Definition of Release Management Process, AUTOSAR_PD_ReleaseManagementProcess.pdf
[TPS_STDT_0078] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
###6.2 Relatedstandardsandnorms 6.2.1 ISO 17356
[STD_ ISO 17356-3_OS] ISO 17356-3: OS http://www.iso.org
###6.2.2 AUTOSAR Vendor ID List [VENDOR_ID_LIST] AUTOSAR Vendor ID List
https://www.autosar.org 80 of 80

# 55 Requirements on ADC Driver
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SRS_ADCDriver.pdf

##3 Acronyms and Abbreviations
Acronyms and abbreviations that have a local scope are not contained in the AUTOSAR glossary. These must appear in a local glossary.

|Acronym|Description|
|:--|:--|
|CS|Chip select|
|DIO|Digital Input Output|
|ECU|Electric Control Unit|
|EOL|End Of Line. Often used in the term ‘EOL Programming’ or ‘EOL Configuration’|
|ICU|Input Capture Unit|
|MAL|Old name of Microcontroller Abstraction Layer (replaced by MCAL because ‘MAL’ is a French term meaning ‘bad’)|
|MCAL|Microcontroller Abstraction Layer|
|MCU|Microcontroller Unit|
|MMU|Memory Management Unit|
|NMI|Non maskable interrupt|
|OS|Operating System|
|PLL|Phase Locked Loop|
|PWM|Pulse Width Modulation|
|RX|Reception (in the context of bus communication)|
|SPAL|The name of this working group|
|SFR|Special Function Register|
|RTE|Runtime environment|
|WP|Work Package|
|ADC|Analogue Digital Converter|
|FFT|Fast Fourier Transformer|
|STD|Standard|
|REQ|Requirement|
|UNINIT|Uninitialized (= not initialized)|
The following expressions are used within the ADC driver:
 
|Expression|Explanation|
|:--|:--|
|Master|A device controlling other devices (slaves, see below)|
|Slave|A device being completely controlled by a master device|
|HW Unit|Represents a microcontroller input electronic device that includes all parts necessary to perform an “analogue to digital conversion”.|
|ADC channel|Represents a logical ADC entity bound to one port pin. Multiple ADC entities can be mapped to the same port pin.|
|ADC channel group|A group of ADC channels linked to the same ADC hardware unit (e.g. one Sample&Hold and one A/D converter). The conversion of the whole group is triggered by one trigger source.|
|ADC result buffer|The user of the ADC Driver has to provide a buffer for every group. This buffer can hold multiple samples of the same channel group if streaming access mode is selected. If single access mode is selected one sample of each group channel is held in the buffer.|
|Trigger Source|Source event that starts a single conversion or a continuous series of conversions.|
|Conversion Mode|||
||One-Shot|The conversion of an ADC channel group is performed once after a trigger and the result is written to the assigned buffer. A trigger can be a software API call or a hardware event.|
|Continuous|The conversions of an ADC channel group are performed continuously after a software API call (start). The conversions themselves are running automatically (hardware/interrupt controlled). The Continuous conversions can be stopped by a software API call (stop).|
|Sampling Time|Time during which the analogue value is sampled (e.g. loading the capacitor, ...)|
|Conversion Time|Time during which the sampled analogue value is converted into digital representation.|
|Acquisition Time| Sample Time + Conversion Time.|

 As this is a document from professionals for professionals, all other terms are expected to be known.

#54 Requirements on Update and Configuration Management
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_RS_UpdateAndConfigManagement.pdf

##3 Acronyms and abbreviations
The glossary below includes acronyms and abbreviations relevant to the UCM module that are not included in the [2, AUTOSAR glossary].
Below acronyms and abbreviations relevant for this document are included in the AUTOSAR Glossary [2]. This is to avoid duplicate definition of the technical term. And to refer to the correct document.
      
|Abbreviation / Acronym|Description|
|:--|:--|
|UCM|Update and Configuration Management|

|Term|Description|
|:--|:--|
|UCM Master|UCM Master is distributing packages and coordinating an update campaign in a vehicle|
|Backend|Backend is a server hosting Software Packages|
|Platform Health Manager|The Platform Health Manager functional cluster performs health monitoring on the AUTOSAR Adaptive Platform|
|Adaptive Application|see [2] AUTOSAR Glossary|
|AUTOSAR Adaptive Platform|see [2] AUTOSAR Glossary|
|Functional Cluster|see [2] AUTOSAR Glossary|
|Service|see [2] AUTOSAR Glossary|
|Electronic Control Unit|see [2] AUTOSAR Glossary|
|Machine|see [2] AUTOSAR Glossary|
|Manifest|see [2] AUTOSAR Glossary|
|Software Package|see [2] AUTOSAR Glossary|
|Vehicle Package|see [2] AUTOSAR Glossary|

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

#53 Requirements on Timing Extensions
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_RS_TimingExtensions.pdf

No abbreviations

##References
[1] Specification of Timing Extensions AUTOSAR_TPS_TimingExtensions
[2] Main Requirements AUTOSAR_RS_Main


#52 Requirements on Time Synchronization
https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_RS_TimeSync.pdf


3 Acronyms and abbreviations
The glossary below includes acronyms and abbreviations relevant to <Document Name> that are not included in the AUTOSAR Glossary [2].

|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|(Global) Time Domain|
|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|
|TSP|Time Synchronization Provider|

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

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

#51 Requirements on System Template
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_RS_SystemTemplate.pdf

no abbreviations

## References
[1] System Template AUTOSAR_TPS_SystemTemplate
[2] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[3] Main Requirements AUTOSAR_RS_Main

# 50 Requirements of State Management
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_RS_StateManagement.pdf

##2 Acronyms and Abbreviations
TheglossarybelowincludesacronymsandabbreviationsrelevanttotheState Man- agement module that are not included in the AUTOSAR glossary[2].

|Terms|Description|
|:--|:--|
|Process|A process is a loaded instance of an Executable to be executed on a Machine.|
|Execution Management|The element of the Adaptive Platform Foundation re- sponsible for the ordered startup and shutdown of the AUTOSAR Adaptive Platform and the Applications.|
|State Management|The element defining modes of operation for AUTOSAR Adap- tive Platform. It allows flexible definition of functions which are active on the platform at any given time.|
|Function Group|A Function Group is a set of coherent Processes, which need to be controlled consistently. Depending on the state of the Function Group, Processes are started or terminated.|
|Function Group State|The element of State Management that characterizes the cur- rent status of a set of (functionally coherent) user-level Appli- cations. The set of Function Groups and their Function Group States is machine specific and are configured in the Machine Manifest [3].|
|Machine State|The element of the State Management. See Function Group State.|
|Network Management|A Functional Cluster within the Adaptive Platform Services. Part of Communication Management.|
|Adaptive Application|see [2] AUTOSAR Glossary|
|Application|see [2] AUTOSAR Glossary|
|AUTOSAR Adaptive Platform|see [2] AUTOSAR Glossary|
|Executable|see [2] AUTOSAR Glossary|
|Functional Cluster|see [2] AUTOSAR Glossary|
|Machine|see [2] AUTOSAR Glossary|
|Manifest|see [2] AUTOSAR Glossary|
|Adaptive Platform Foundation|see [2] AUTOSAR Glossary|
|Adaptive Platform Services|see [2] AUTOSAR Glossary|

##5 References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Specification of Manifest AUTOSAR_TPS_ManifestSpecification
[4] Specification of Diagnostics AUTOSAR_SWS_Diagnostics
[5] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Re- lease 2013-03)
http://www.iso.org
[6] Main Requirements AUTOSAR_RS_Main

#49 Requirements on Standardization Template
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_RS_StandardizationTemplate.pdf

## 1.2 Guidelines

|Terms| Definitions|
|:--|:--|
| Redundancy|Requirements shall not be repeated within one requirement or in other require- ments.|
| Clearness|All requirements shall allow one possibility of interpretation only. Used technical terms that are not in the glossary must be defined.|
| Atomicity|Each Requirement shall only contain one requirement. A Requirement is atomic if it cannot be split up in further requirements.|
| Testability| Requirements shall be testable by analysis, review or test.|
| Traceability|The source and status of a requirement shall be visible at all times.|
## References
[1] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[2] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[3] Requirements on AUTOSAR Features AUTOSAR_RS_Features
[4] Main Requirements AUTOSAR_RS_Main
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration
[6] Specification of Platform Types AUTOSAR_SWS_PlatformTypes
[7] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[8] XML Specification of Application Interfaces AUTOSAR_MOD_AISpecification
[9] SW-C and System Modeling Guide AUTOSAR_TR_SWCModelingGuide

#48 Requirements on Software Component Template

no abbreviations

References
[1] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[2] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[3] Main Requirements AUTOSAR_RS_Main
[4] Requirements on AUTOSAR Features AUTOSAR_RS_Features
[5] Feature Definition AUTOSAR_FeatureDefinition.pdf
[6] Specification of SW-C End-to-End Communication Protection Library AUTOSAR_SWS_E2ELibrary

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

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

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

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