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

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

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

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

##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)

##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

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

##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

84 Requirements on Operating System

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

##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

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
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

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
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

77 Requirements on Libraries

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

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

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

##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

##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

69 Requirements on Function Inhibition Manager

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

##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

#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

##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

##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
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 that are not included in the AUTOSAR Glossary [2].

Abbreviation / Acronym	Description
(G)TD	(Global) Time Domain
(G)TM	(Global)Time Master
TSyn	A bus specific Time Synchronization module
AVB	Audio Video Bridging
BMCA	Best Master Clock Algorithm
CID	Company ID (IEEE)
CRC	Cyclic Redundancy Checksum
ETH	Ethernet
EthTSyn	Time Synchronization Provider module for Ethernet
GM(C)	Grand Master (Clock)
OFS	Offset synchronization
Pdelay	Propagation / path delay as given in IEEE 802.1AS
Pdelay_Req	Propagation / path delay request message
Pdelay_Resp	Propagation / path delay response message
Pdelay_Resp_Follow_Up	Propagation / path delay Follow-Up message
PDU	Protocol Data Unit
PTP	Precision Time Protocol
StbM	(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

##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.

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

94 Requirements on Vehicle-2-X communication

Bibliography

3 Acronyms and abbreviations

4 Acronyms, abbreviations and terms

7 References

92 Requirements on TTCAN

3 Acronyms and abbrevations

6 References

91 Requirements on SPI Handler/Driver

3 Acronyms and abbreviations

7 Related Documentation

90 General Requirements on SPAL

3 Acronyms and Abbreviations

9 References

9.1 Deliverables of AUTOSAR

9.2 Related standard and norms

88 Requirements on Runtime Environment

References

3 Acronyms and abbreviations

7 References

3 Acronyms and abbreviations

6 References

85 Requirements on PWM Driver

7 Related Documentation

84 Requirements on Operating System

2.2 Acronyms and abbreviations

6 References

83 Requirements on OCU Driver

82 Requirements on Network Management

7 References

3 Terminology

Glossary

80 Requirements on Memory Services

3 Acronyms and abbreviations

7 References

3 Acronyms and abbreviations

3 Acronyms and abbreviations

7 References

77 Requirements on Libraries

3 Acronyms and abbreviations

7 References

76 Requirements on LIN

3 Acronyms and abbreviations

75 Requirements on I-PDU Multiplexer

3 Acronyms and abbrevations

7 References

7.1 DeliverablesofAUTOSAR

74 Requirements on I/O Hardware Abstraction

73 Requirements on ICU Driver

7 References

6 References

7 References

69 Requirements on Function Inhibition Manager

3 Acronyms and abbreviations

68 Requirements on Free Running Timer

3 Acronyms and abbreviations

3 Acronyms and abbreviations

2.1 Acronymsandabbreviations

6 References

6.1 DeliverablesofAUTOSAR

6.2 Relatedstandardsandnorms

6.2.1 IETF Requests For Comments (RFCs)

3 Acronyms and abbreviations

3.1 Glossary of Terms

7 References

57 Requirements on Bus Mirroring

56 General Requirements on Basic Software Modules

55 Requirements on ADC Driver

8 References

References

50 Requirements of State Management

1.2 Guidelines

References

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

Thank you very much for reading to the last sentence.