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
ref. Reference
abbre. Abbreviation
238 Requirements on Log and Trace
3 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| Log and trace message | A log and trace message contains all data and options to specify a log and trace event in a software. |
| User | The user of LT is the programmer of the software, which uses the LT API to generate log and trace messages. |
| Log | The user generates log messages on demand. Each time the user wants to show some information about state changes or value changes, he adds an API call to LT. |
| Trace | Trace messages can be generated by instrumentation of the code (e.g. VFB traces). The instrumented code calls the API of LT. |
| ECU ID | ECU ID is the name of each ECU. |
| Session ID | Session ID is the identification number of a log or trace session. If an Application is instantiated several times the log sessions get a new Session ID. A Application can have several log or trace sessions. A BSW module uses the module-number as Session ID. |
| Application ID | Application ID is a short name of the Application/BSW module. It identifies the Application/BSW module in the log and trace message. |
| Context ID | Context ID is a user defined ID to group log and trace messages produced by an Application/BSW module to distinguish functionality. Each Application ID can own several Context IDs. Context ID’s are grouped by Application ID’s. Context IDs shall be unique within an Application ID. The identification of the source of a log and trace message is done with a pair of Application ID and Context ID. |
| Message ID | Messaged ID is the ID to characterize the information, which is transported by the message itself. A Message ID identifies a log or trace message uniquely. It can be used for identifying the source (in source code) of a message and it can be used for characterizing the payload of a message. |
| Log and trace level | A log level defines a classification for the severity grade of a log message. The trace status provides information if a trace message should be send. |
| Time | Each log and trace message may contain a time attribute. The time attribute is a free defined time-value. It is the time since the start of the ECU. |
| External client | An external client is a tool, which can be run on a PC or another ECU, which is connected to LT over DCM or over the LT communication module. |
6 References
[1] Requirements on AUTOSAR Features AUTOSAR_RS_Features.pdf
[2] Specification of RTE, AUTOSAR_SWS_RTE.pdf
[3] Layered Software Architecture, AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf.pdf
[4] Specification of Development Error Trace, AUTOSAR_SWS_DevelopmentErrorTracer.pdf
[5] Software Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
239 Requirements on Methodology
1.2 Abbreviations
| Abbreviation | Description |
|---|---|
| AP | Adaptive Platform |
| AUTOSAR | Automotive Open System Architecture |
| CP | Classic Platform |
| ECU | Electronic Control Unit |
| OEM | Original Equipment Manufacture |
| RTE | Runtime Environment |
| SIL | Safety Integrity Level (IEC61508 definition) |
| SWC | Software Component |
| VFB | Virtual Functional Bus |
References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Main Requirements AUTOSAR_RS_Main
240 Requirements on Health Monitoring
Abbreviation
| Abbreviation | Description |
|---|---|
| CM | AUTOSAR Adaptive Communication Management |
| DM | AUTOSAR Adaptive Diagnostic Management |
| PHM | Platform Health Management |
| SE | Supervised Entity |
Description
| Acronym | Description |
|---|---|
| Alive Counter | An independent data resource in context of a Checkpoint to track and handle its amount of Alive Indications. |
| Alive Indication | An indication of a Supervised Entity to signal its aliveness by calling a checkpoint used for Alive Supervision. |
| Alive Supervision | Mechanism to check the timing constraints of cyclic Supervised Entitys to be within the configured min and max limits. |
| Checkpoint | A point in the control flow of a Supervised Entity where the activity is reported. |
| Deadline End Checkpoint | A Checkpoint for which Deadline Supervision is configured and which is a ending point for a particular Transition. It is possible that a Checkpoint is both a Deadline Start Checkpoint and Deadline End Checkpoint - if Deadline Supervision is chained. |
| Deadline Start Checkpoint | A Checkpoint for which Deadline Supervision is configured and which is a starting point for a particular Transition. |
| Deadline Supervision | Mechanism to check that the timing constraints for execution of the transition from a Deadline Start Checkpoint to a cor- respondingDeadline End Checkpointarewithintheconfig- ured min and max limits. |
| Expired Supervision Cycle | ASupervisionCyclewheretheAlive Supervisionhasfailed its two escalation steps (Alive Counter fails the expected amount of Alive Indications (including tolerances) more often than the al- lowed amount of failed reference cycles). |
| Failed Supervision Reference Cycle | A Supervision Reference Cycle that ends with a detected devi- ation (including tolerances) between the Alive Counter and the expected amount of Alive Indications. |
| Global Supervision Status | Status that summarizes the Local Supervision Status of all Su- pervised Entities of a software subsystem. |
| Graph | A set of Checkpoints connected through Transitions, where at least one of Checkpoints is an Initial Checkpoint and there is a path (through Transitions) between any two Checkpoints of the Graph. |
| Health Channel | Channel providing information about the health status of a (sub)system. This might be the Global Supervision Status of an application, the result any test routine or the status reported by a (sub)system (e.g. voltage monitoring, OS kernel, ECU status, ...). |
| Health Channel Supervision | Kind of supervision that checks if the health indicators registered by the supervised software are within the tolerances/limits. |
| Health Monitoring | Supervision of the software behaviour for correct timing and se- quence. |
| Health Status | A set of states that are relevant to the supervised software (e.g. the Global Supervision Status of an application, a Voltage State, an application state, the result of a RAM monitoring algorithm). |
| Logical Supervision | Kind of online supervision of software that checks if the soft- ware (Supervised Entity or set of Supervised Entities) is executed in the sequence defined by the programmer (by the developed code). |
| Local Supervision Status | Status that represents the current result of Alive Supervision, Deadline Supervision and Logical Supervision of a single Super- vised Entity. |
| Platform Health Management | Health Monitoring for the Adaptive Platform |
| Supervised Entity | A software entity which is included in the supervision. A Super- vised Entity denotes a collection of Checkpoints within an appli- cation. There may be zero, one or more Supervised Entities in a Software Component. A Supervised Entity may be instantiated multiple times, in which case each instance is independently su- pervised. |
| Supervised Entity Identifier | An Identifier that identifies uniquely a Supervised Entity within an Application. |
| Supervision Counter | An independent data resource in context of a Supervised En- tity which is updated during each supervision cycle and which is used by the Alive Supervision algorithm to perform the check against counted Alive Indications. |
| Supervision Cycle | ThetimeperiodinwhichthecyclicAlive Supervisionisper- formed. |
| Supervision Mode | An overall state of a microcontroller or virtual machine. Modes are mutually exclusive and all Supervised Entities are in the same Supervision Mode. A mode can be e.g. Startup, Shutdown, Low power. |
| Supervision Reference Cycle | The amount of Supervision Cycles to be used as reference by theAlive SupervisiontoperformthecheckofcountedAlive Indications (individually for each Supervised Entity). |
7 References
[1] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org
[2] Specification of Health Monitoring AUTOSAR_SWS_HealthMonitoring
[3] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[4] Glossary AUTOSAR_TR_Glossary
[5] Main Requirements AUTOSAR_RS_Main
241 Specification of Health Monitoring
2 Acronyms and abbreviations
| Abbreviation /Acronym | Description |
|---|---|
| Alive Indication | An indication of a Supervised Entity to signal its aliveness by calling a checkpoint used for Alive Supervision. |
| Alive Supervision | Kind of supervision that checks if a Supervised Entity executed in a correct frequency. |
| Checkpoint | A point in the control flow of a Supervised Entity where the activity is reported. |
| Deadline Supervision | Kind of supervision that checks if the execution time between two Checkpoints is within minimum/maximum time limit. |
| Final Checkpoint | The ending Checkpoint of a Graph. There can be zero or more Final Checkpoints for each Graph. |
| Global Supervision Status | Status that summarizes the Local Supervision Status of all Su- pervised Entities. |
| Graph | A set of Checkpoints connected through Transitions, where at least one of Checkpoints is an Initial Checkpoint. There is a path (through Transitions) between any two Checkpoints of the Graph. |
| Health Channel | Channel providing information about the health status of a (sub)system. This might be the Global Supervision Status of an application, the result any test routine or the status reported by a (sub)system (e.g. voltage monitoring, OS kernel, ECU status, ...). |
| Health Channel Supervision | Kind of supervision that checks if the health indicators registered by the supervised software are within the tolerances/limits. |
| Health Monitoring | Supervision of the software behaviour for correct timing and se- quence. |
| Health Status | A set of states that are relevant to the supervised software (e.g. a Voltage State, an application state, the result of a RAM moni- toring algorithm). |
| Health Status Supervision | Check if the health indicators registered by the supervised soft- ware are within the tolerances/limits. |
| Initial Checkpoint | The starting Checkpoint of a Graph. There can be one or more Initial Checkpoints for each Graph. |
| Logical Supervision | Kind of online supervision of software that checks if the soft- ware (Supervised Entity or set of Supervised Entities) is executed in the sequence defined by the programmer (by the developed code). |
| Local Supervision Status | Status that represents the current result of Alive Supervision, Deadline Supervision and Logical Supervision of a single Super- vised Entity. |
| Machine | see [3] AUTOSAR Glossary |
| Platform Health Management | Health Monitoring for the Adaptive Platform |
| Supervised Entity | A software entity which is included in the supervision. A Super- vised Entity denotes a collection of Checkpoints within a software component. There may be zero, one or more Supervised Entities in a Software Component. A Supervised Entity may be instanti- ated multiple times, in which case each instance is independently supervised. |
| Supervision Mode | An overall state of a microcontroller or virtual machine. Modes are mutually exclusive and all Supervised Entities are in the same Supervision Mode. A mode can be e.g. Startup, Shutdown, Low power. |
| SE | Supervised Entity. |
3 Related documentation References
[1] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org
[2] Requirements on Health Monitoring AUTOSAR_RS_HealthMonitoring
[3] Glossary AUTOSAR_TR_Glossary
242 Requirements on IPsec Protocol
3 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| AH | Authentication Header |
| DB | Database |
| ESP | Encapsulating Security Payload |
| ICV | Integrity Check Value |
| IKE | Internet Key Exchange |
| IKEv2 | Internet Key Exchange version 2 |
| IP | Internet Protocol |
| IPsec | Internet Protocol Security |
| PAD | Peer Authorization Database |
| PKI | Public Key Infrastructure |
| PSK | Pre-Shared Keys |
| RAM | Random Access Memory |
| SA | Security Association |
| SAD | Security Association Database |
| SPD | Security Policy Database |
| TCP/IP | Transmission Control Protocol / Internet Protocol |
| V2X | Vehicle to everything |
6 References
[1] System Template AUTOSAR_TPS_SystemTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Explanation of IPsec Implementation Guidelines AUTOSAR_EXP_IPsecImplementationGuidelines
[4] strongSwan website https://www.strongswan.org
[5] RFC 4301, Security Architecture for the Internet Protocol
[6] RFC 4302, IP Authentication Header
[7] RFC 4303, IP Encapsulating Security Payload (ESP)
[8] RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2)
[9] RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association
[10] RFC 8221, Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
[11] RFC 4478, Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
[12] RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
[13] RFC 7427, Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
[14] RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
[15] RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec
[16] RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Se- curity Payload (ESP)
[17] RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
[18] RFC 6379, Suite B Cryptographic Suites for IPsec
[19] RFC 8247, Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)
[20] Requirements on AUTOSAR Features AUTOSAR_RS_Features
243 Specification of Secure Hardware Extensions
2.1 Definition of terms and acronyms Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| HIS | Hersteller Initiative Software |
| SHE | Security Hardware Extension |
| AES | Advanced Encryption Standard |
| TPM | Trusted Platform Module |
| CBC | Cipher Block Chaining |
| ECB | Electronic Code Book |
| MAC | Message Authentication Code |
| CMAC | Cipher-based Message Authentication Code |
| IV | Initialization Vector |
| UID | Unique IDentification item |
| TRNG | True Random Number Generator |
| PRNG | Pseudo Random Number Generator |
3.1 Input documents & related standards and norms
References
[1] NIST: Announcing the Advanced Encryption Standard (AES) http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[2] NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
[3] NIST Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
[4] NIST: Updated CMAC Examples http://csrc.nist.gov/publications/nistpubs/800-38B/Updated_CMAC_Examples.pdf
[5] Handbook of Applied Cryptography http://www.cacr.math.uwaterloo.ca/hac/
[6] NIST Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions http://csrc.nist.gov/publications/drafts/800-108/Draft_SP-800-108_April-2008.pdf
[7] BSI: A proposal for: Functionality classes and evaluation methodology for true (physical)random number generators, Version 3.1 http://www.bsi.bund.de/zertifiz/zert/interpr/trngk31e.pdf
[8] BSI: Application Notes and Interpretation of the Scheme (AIS) http://www.bsi.bund.de/zertifiz/zert/interpr/ais20e.pdf
[9] Trusted Computing Group https://www.trustedcomputinggroup.org/
#244 List of known Issues of Secure Hardware Extensions
no abbreviations and no references
245 Project Objectives
no abbreviations
4 References
[Glossary] AUTOSAR Glossary, AUTOSAR_TR_Glossary.pdf
[IEEEElecEng] The Electrical Engineering Handbook, Editor R. C. Dorf, CRC Press
[ISO 11898] Road vehicles — Controller area network (CAN)
[ISO 14229] Road vehicles — Unified diagnostic services (UDS)
[ISO 15765] Road vehicles -- Diagnostic communication over Controller Area Network (DoCAN)
[ISO 26262] Road vehicles — Functional safety
[ISO 27145] Road vehicles — Implementation of WWH-OBD communication requirements
[SAE J1939] Recommended Practice for a Serial Control and Communications Vehicle Network
[TPS_STDT] AUTOSAR Standardization Template, AUTOSAR_TPS_StandardizationTemplate.pdf
246 Requirements on Platform Health Management for Adaptive Platform
3 Acronyms and abbreviations
| Abbreviation | Description |
|---|---|
| CM | AUTOSAR Adaptive Communication Management |
| DM | AUTOSAR Adaptive Diagnostic Management |
| PHM | Platform Health Management |
| SE | Supervised Entity |
| Acronym | Description |
|---|---|
| Alive Supervision | Mechanism to check the timing constraints of cyclic Supervised Entityes to be within the configured min and max limits. |
| Application | see [2] AUTOSAR Glossary |
| ara::com | Communication middleware for the AUTOSAR Adaptive Platform |
| AUTOSAR Adaptive Platform | see [2] AUTOSAR Glossary |
| Checkpoint | A point in the control flow of a Supervised Entity where the activity is reported. |
| Daisy chaining | Chaining multiple instances of Health Monitoring |
| Deadline End Checkpoint | A Checkpoint for which Deadline Supervision is configured and which is a ending point for a particular Transition. It is possible that a Checkpoint is both a Deadline Start Checkpoint and Deadline End Checkpoint - if Deadline Supervision is chained. |
| Deadline Start Checkpoint | A Checkpoint for which Deadline Supervision is configured and which is a starting point for a particular Transition. |
| Deadline Supervision | Mechanism to check that the timing constraints for execution of the transition from a Deadline Start Checkpoint to a cor- respondingDeadline End Checkpointarewithintheconfig- ured min and max limits. |
| Executable | see [2] AUTOSAR Glossary |
| Execution Management | The element of the Adaptive Platform responsible for the ordered startup and shutdown of the Adaptive Platform and the Applica- tion. |
| 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 deployed as part of the Machine Manifest. |
| Functional Cluster | see [2] AUTOSAR Glossary |
| Global Supervision Status | Status that summarizes the Local Supervision Status of all Su- pervised Entities of a software subsystem. |
| Health Channel | Channel providing information about the health status of a (sub)system. This might be the Global Supervision Status of an application, the result any test routine or the status reported by a (sub)system (e.g. voltage monitoring, OS kernel, ECU status, ...). |
| Health Monitoring | Supervision of the software behaviour for correct timing and se- quence. |
| Health Status | A set of states that are relevant to the supervised software (e.g. the Global Supervision Status of an application, a Voltage State, an application state, the result of a RAM monitoring algorithm). |
| Logical Supervision | Kind of online supervision of software that checks if the soft- ware (Supervised Entity or set of Supervised Entities) is executed in the sequence defined by the programmer (by the developed code). |
| Machine Manifest | Manifest file to configure a Machine. |
| Machine | see [2] AUTOSAR Glossary |
| Machine State | The element of the State Management which characterize the current status of the machine. It defines a set of active Ap- plications for any certain situation. The set of Machine States is machine specific and it will be deployed in the Ma- chine Manifest. Machine States are mainly used to con- trol machine lifecycle (startup/shut-down/restart) and platform- level processes. |
| Manifest | see [2] AUTOSAR Glossary |
| Platform Health Management | Health Monitoring for the Adaptive Platform |
| Process | A process is a loaded instance of an Executable to be executed on a Machine. |
| State Management | The element of the Execution Management defining modes of operation for AUTOSAR Adaptive Platform. It allows flex- ible definition of functions which are active on the platform at any given time. |
| Supervised Entity | A software entity which is included in the supervision. A Super- vised Entity denotes a collection of Checkpoints within a software component. There may be zero, one or more Supervised Entities in a Software Component. A Supervised Entity may be instanti- ated multiple times, in which case each instance is independently supervised. |
| Supervision Mode | An overall state of a microcontroller or virtual machine. Modes are mutually exclusive and all Supervised Entities are in the same Supervision Mode. A mode can be e.g. Startup, Shutdown, Low power. |
| Table 3.1: Acronyms |
##6 References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Requirements on Health Monitoring UTOSAR_RS_HealthMonitoring
#247 Specification of Identity and Access Management
##2 Acronyms and Abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| PDP | Policy Decision Point |
| PEP | Policy Enforcement Point |
| IPC | Inter-Process Communication |
3.1 Related documentation
[1] Glossary AUTOSAR_TR_Glossary
[2] Requirements on Identity and Access Management AUTOSAR_RS_IdentityAndAccessManagement
248 Specification of RESTful communication
2 Acronyms and Abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| REST | Representational State Transfer |
| HTTP | Hypertext Transfer Protocol |
| TLS | Transport Layer Security |
| MIME | Multipurpose Internet Mail Extensions |
| ##3.1 Input documents | |
| [1] Specification of Communication Management AUTOSAR_SWS_CommunicationManagement | |
| [2] REST: Architectural Styles and the Design of Network-based Software Architec- tures | |
| [3] Glossary AUTOSAR_TR_Glossary | |
| [4] Requirements on Communication Management AUTOSAR_RS_CommunicationManagement | |
| [5] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax | |
| [6] SOME/IP Protocol Specification AUTOSAR_PRS_SOMEIPProtocol | |
| [7] Specification of Core Types for Adaptive Platform AUTOSAR_SWS_CoreTypes | |
| [8] RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace | |
| [9] RFC 2616, Hypertext Transfer Protocol – HTTP/1.1 | |
| [10] RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format | |
| [11] RFC 1951, DEFLATE Compressed Data Format Specification version 1.3 | |
| [12] RFC 1952, GZIP file format specification version 4.3 |
249 Specification of Core Types for Adaptive Platform
2 Acronyms and Abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| UUID | Universally Unique Identifier, a 128-bit number used to identify information in computer systems |
3.1 Input documents & related standards and norms
[1] Glossary AUTOSAR_TR_Glossary
[2] Specification of Operating System Interface AUTOSAR_SWS_OperatingSystemInterface
[3] ValueOrError and ValueOrNone types http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0786r1.pdf
[4] Explanation of ara::com API AUTOSAR_EXP_ARAComAPI
[5] ISO/IEC 14882:2011, Information technology – Programming languages – C++ http://www.iso.org
[6] N4659: Working Draft, Standard for ProgrammingLanguage C++ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf
[7] N4820: Working Draft, Standard for Programming Language C++ http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2019/n4820.pdf
[8] N3857: Improvements to std::future and Related APIs https://isocpp.org/files/papers/N3857.pdf
250 Requirements on Identity and Access Management
2 Acronyms and abbreviations
| Term | Description |
|---|---|
| IAM | identity and Access Management |
| PDP | Policy Decision Point |
| PEP | Policy Enforcement Point |
| Identity and Access Manage- ment (IAM) | IAM is about managing access rights of an Adaptive Appli- cation to interfaces and resources of the Adaptive Platform Foundation and Services. |
| Policy Decision Point (PDP) | The PDP represents the logic in which the access control deci- sion is made. It determines if the application is allowed to perform the requested task. |
| Policy Enforcement Point (PEP) | The PEP represents the logic in which the Access Control Deci- sion is enforced. It communicates directly with the corresponding PDP to receive the Access Control Decision. |
| Access control Policy | Access Control Policies are bound to the targets of calls (i.e. Ser- vice interfaces) and are used to express what Identity Information are necessary to access those interfaces. |
| Access Control Decision | The Access Control Decision is a Boolean value indicating if the requested operation is permitted or not. It is based on the identity of the caller and the Access Control Policy. |
| Identity | Identity represents properties of an Adaptive Application the access control is decided / enforced upon. |
| AUTOSAR Resource | The term AUTOSAR Resource covers interfaces that are under the scope of IAM, i.e. Service Interfaces. |
| Application ID | Application ID is a unique identifier of an Adaptive Applica- tion. In the meta-model an Adaptive Application is rep- resented by Process. |
| Capability | A capability is a property of an Adaptive Application. Ac- cess to an AUTOSAR resource is granted if a requesting AA possesses all capabilities that are necessary for that specific AUTOSAR Resource. Capabilities are assigned to Adaptive Applications within their Application Manifest by means of ComSpecs (e.g. ClientComSpec) and GrantDesigns (e.g. ComFieldGrantDesign). |
| Grant | The integrator acknowledges an Adaptive Application’s capabilities by transferring GrantDesigns to a Grant in deploy- ment. Grant elements may be processed into access control lists for the PDP implementation. |
| Table 2.1: Acronyms and Abbreviations |
6 References
[1] Glossary AUTOSAR_TR_Glossary
[2] Main Requirements AUTOSAR_RS_Main
[3] Requirements on Security Management for Adaptive Platform AUTOSAR_RS_SecurityManagement
251 Specification of Time Synchronization for Adaptive Platform
##2.1 Acronyms and Abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| StbM | Synchronized Time Base Manager |
| TS | Time Synchronization |
| TBR | Time Base Resource |
| NTP | Network Time Protocol |
| PTP | Precision Time Protocol |
| gPTP | Generalized Precision Time Protocol |
| Timesync | Time Synchronization (Refers to the action of Synchronizing the Time by means of a time synchronization protocol/bus/mes- sages) |
| TSP | A bus specific Time Synchronization Provider |
| UTC | Coordinated Universal Time |
| OS | Operating System |
| DLS | Day Light Saving, also know as Daylight Saving Time (abbre- viated DST), is the practice of advancing clocks during summer months so that evening daylight lasts longer, while sacrificing nor- mal sunrise times. Typically, regions that use daylight saving time adjust clocks forward one hour close to the start of spring and ad- just them backward in the autumn to standard time |
2.2 Definitions
| Term | Definition |
|---|---|
| 2.2.1 Clock | Definition: A Clock refers to the unit conformed by the combination of a Time Base (either synchronized against an external source or not) and a hardware capable of changing cyclically the electric state of its output (e.g. toggling between two different voltage levels). The frequency of such electric state changes can be adjustable. This hardware could be e.g. part of a microcontroller, or an external electronic component. Likewise the Synchronized Time Base information can be acquired from an external source like a RTC, GPS, Ethernet, etc. Therefore when talking about a Clock we may refer to either its quality (e.g. rate, accuracy, etc.) or to the Time Base it holds (e.g. time information relative to the Global Position, daylight, etc.) depending on the context that holds the term. |
| 2.2.2 Global Time Master | Definition: A Global Time Master is the global owner and origin for a certain Time Base and on the top of the Time Base hierarchy for that Time Base. |
| 2.2.3 Time Base | Definition: A Time Base is a unique time entity characterized by: • Progression of time, which denotes how time progresses, i.e. the rate (which for instance, might be derived from a local quartz oscillator) and absolute changes of the time value at certain point in times (e.g. effects of offset correction in NTP). • Ownership, which denotes who is the owner of the Time Base. A distributed NTP Time Base e.g. has multiple owners and the progression of time with respect to rate and offset corrections is a result of involving a subset of NTP nodes. • Reference to the physical world, i.e. whether the Time Base is a relative Time Base counting local operation time of an ECU or representing an absolute time like UTC. A Time Base can have more than one reference, e.g. it can be a relative time which, in combination with an offset value, also represents an absolute time. Examples of Time Bases in vehicles are: • Absolute, which is based on a GPS based time. • Relative, which represents the accumulated overall operating time of a vehicle, i.e. this Time Base does not start with a value of zero whenever the vehicle starts operating. • Relative, starting at zero when the ECU begins its operation. A Time Base implies the availability of a Clock. Special case "Pure Local Time Base": A Pure Local Time Base is a Time Base with a local scope as it is neither propagated to other nodes nor received from other nodes. A Pure Local Time Base will only locally be set and read. It is therefore possible to have multiple Pure Local Time Bases with the same Time Domain number in various nodes in parallel. A Pure Local Time Base behaves like a Synchronized Time Base since it progresses in time, however it is not synchronized via TSP modules. Pure Local Time Bases behaving like an Offset Time Bases are not supported. |
| 2.2.4 Synchronized Time Base | Definition: A Synchronized Time Base is a Time Base existing at a processing entity (actor / processor / node of a distributed system) that is synchronized with Time Bases at different processing entities. A Synchronized Time Base can be achieved by time protocols or time agreement protocols that derive the Synchronized Time Base in a de- fined way from one or more physical Time Bases (e.g. Network Time Protocol (NTP)). The synchronization will apply to the clock rate and optionally also to the Time Base absolute value. A Synchronized Time Base allows synchronized action of the processing units. Syn- chronized Time Bases are often called "Global Time". More than one Synchronized Time Base can exist at one processing unit, e.g. a NTP node will have the Synchronized Time Base retrieved from NTP in the network cluster but might also have a Synchronized Time Base derived from the time provided by a UTC time server (which is based on a set of atomic clocks). Both Synchronized Time Bases will probably have slightly different rates, and there is no relationship defined between their absolute values. |
| 2.2.5 Offset Time Base | Definition: An Offset Time Base is a Time Base existing at a processing entity (actor / processor / node of a distributed system). An Offset Time Base depends on one particular Synchronized Time Base, therefore it is synchronized with the same Time Base Source as its underlying TBR. An Offset Time Base holds an offset value relative to the Time Base of its underlying Synchronized TBR. Therefore, it provides to the Application a time base with a value of its underlying Synchronized TBR plus the Offset value it holds. Since an Offset Time Base receives its time value from the same TSP as its underlying Synchronized TBR, it will present the same rate deviation and correction properties. |
| 2.2.6 Time Base Provider | Definition: A Time Base Provider is the role that a TSP module takes for a given Time Base. Therefore a TSP module can contain one or more Time Base providers. Time Base providers are either of type importer or exporter, whereas an importer acts as Time Slave and an exporter acts as Time Master. A Time Gateway consists of one Time Base importer and one or more Time Base exporters for a given Time Base. In order to limit the terminology, importers are denoted as slaves and exporters are denoted as masters. |
| 2.2.7 Time Communication Port | Definition: A Time Communication Port is a physical communication interface (in Clas- sic Platform coverable by the item: Physical Connector) at an ECU which is used to transport time information. |
| 2.2.8 Time Communication Service | Definition: A Time Communication Service is an interaction between Time Bases which is performed by Time Base providers. Time communication services are mes- sage based between a Time Master and one or more Time Slaves or between one Time Slave and his Time Master. The following figure shows a network topology example and the related terminology. |
| 2.2.9 Time Base Application | |
| 1. Active Application | This kind of Application autonomously calls the TS either: • To read time information from the TBRs • To update the Time Base maintained by a TBR, according to application information. |
| 2. Triggered Application | This feature will be provided at a later release/version of the TS. |
| 3. Notification Application | This feature will be provided at a later release/version of the TS. |
| 2.2.10 Time Domain | Definition: A Time Domain denotes which components (e.g. nodes, communication systems) are linked to a certain Time Base. A Time Domain can contain zero or more Time Sub-Domains. If the timing hierarchy of a Time Domain contains no Time Gate- ways, i.e. all nodes are connected to the same bus system, then there is no dedicated Time Sub-Domain which otherwise would be equal to the Time Domain itself. |
| 2.2.11 Time Gateway | Definition: A Time Gateway is a set of entities where one entity is acting as Time Slave for a certain Time Base. The other (one or more) entities are acting as Time Masters which are distributing this Time Base to sets of Time Slaves. A Timesync ECU can contain multiple Time Gateways. |
| 2.2.12 Time Hierarchy | Definition: The Time Hierarchy describes how a certain Time Base is distributed, starting at the Global Time Master and being distributed across various Time Gateways (if present) to various Time Slaves. |
| 2.2.13 Time Master | Definition: A Time Master is an entity which is the master for a certain Time Base and which propagates this Time Base to a set of Time Slaves within a certain segment of a communication network, being a source for this Time Base. If a Time Master is also the owner of the Time Base then he is the Global Time Master. A Time Gateway typically consists of one Time Slave and one or more Time Masters. When mapping time entities to real ECUs it has to be noted, that an ECU could be Time Master (or even Global Time Master) for one Time Base and Time Slave for another Time Base. Special case "Pure Local Time Master": A Pure Local Time Master is an entity which is the master of a Pure Local Time Base and which therefore does not propagate this Time Base to any Time Slave. |
| 2.2.14 Time Slave | Definition: A Time Slave is an entity, which is the recipient for a certain Time Base within a certain segment of a communication network, being a consumer for this Time Base. |
| 2.2.15 Time Sub-domain | Definition: A Time Sub-Domain denotes which components (e.g. nodes) are linked to a certain Time Base, whereas the scope is limited to one communication bus. |
| 2.2.16 Timesync ECU | Definition: A Timesync ECU is an ECU which is part of a Time Domain by containing one or more Time Slaves or Time Masters. |
| 2.2.17 TSP Module | Definition: TSP modules are bus specific modules to receive or transmit time infor- mation on bus systems by applying bus specific mechanisms. A Timesync module can serve multiple communication buses of the same type. |
3.1 Input documents & related standards and norms
[1] Protocol Requirements on Time Synchronization for Adaptive Platform AUTOSAR_PRS_TimeSync
[2] Specification of Synchronized Time-Base Manager AUTOSAR_SWS_SynchronizedTimeBaseManager
[3] Glossary AUTOSAR_TR_Glossary
[4] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[5] Functional Cluster Shortnames AUTOSAR_TR_FunctionalClusterShortnames
[6] Requirements on Time Synchronization for Adaptive Platform AUTOSAR_RS_TimeSync
[7] ISO/IEC 14882:2011, Information technology – Programming languages – C++ http://www.iso.org
[8] Standard for Information Technology–Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7 http://pubs.opengroup.org/onlinepubs/9699919799/
[9] Specification of Time Synchronization over Ethernet AUTOSAR_SWS_TimeSyncOverEthernet
[10] Specification of Communication Management AUTOSAR_SWS_CommunicationManagement
###3.2 Related specification
AUTOSAR provides a General Specification on Basic Software modules [4, SWS BSW General], which is also valid for TS.
Thus, the specification SWS BSW General shall be considered as additional and re- quired specification for TS.
252 Explanation of Safety Overview
A Abbreviations
| Abbreviation | Description |
|---|---|
| 1oo2 | one out of two |
| 2oo2 | two out of two |
| 2oo3 | two out of three |
| AP | AUTOSAR Adaptive Platform |
| AD | Automated Driving |
| ADS | Automated Driving Systems |
| ADAS | Advanced Driver Assistance System |
| ARA | AUTOSAR Runtime for Adaptive Applications |
| ASIL | Automotive Safety Integrity Level |
| BSW | Basic Software (CP) |
| CAN | Controller Area Network |
| CAN-FD | Controller Area Network with Flexible Data-Rate |
| CCA | Common Cause Failure Analysis |
| CM | Communication (AP functional cluster) |
| CP | AUTOSAR Classic Platform |
| DFA | Dependent Failure Analysis |
| DIN | Deutsches Institut für Normung |
| DMR | Dual Modular Redundancy AUTOSAR Foundation |
| FO | AUTOSAR Foundation |
| FSM | Functional Safety Management |
| FSM Review | Functional Safety Milestone Review |
| E2E | End-to-End |
| ECC | Error Correction Code |
| ECU | Electronic Control Unit |
| EEPROM | Electrically Erasable Programmable Read-Only Memory |
| EM | Execution Management (AP functional cluster) |
| FIT | Failures In Time |
| FTTI | Fault Tolerant Time Interval |
| FSC | Function Safety Concept |
| FSR | Functional Safety Requirement |
| HA | Hazard |
| HAD | Highly Automated Driving |
| HSM | Hardware Security Module |
| HW | Hardware |
| IAM | Identity and Access Management (AP functional cluster) |
| IC | Integrated Circuit |
| IDef | Item Definition |
| ISO | International Standardization Organization |
| MAL | Malfunction |
| MM | Methods and Methodology (AP) |
| MMU | Memory Management Unit |
| MTBF | Meant Time Between Failure |
| MTTF | Mean Time To Failure |
| NvM | Non-volatile Memory |
| OS | Operating System |
| Probability density function | |
| PER | Persistency (AP functional cluster) |
| PHM | Platform Health Management (AP functional cluster) |
| PMIC | Power Management Integrated Circuit |
| QM | Quality Management |
| RAM | Random-Access Memory |
| REST | Representational State Transfer |
| ROM | Read-Only Memory |
| SG | Safety Goal |
| SoC | System on a Chip |
| SOME/IP | Service Oriented Middleware Over Ethernet / Internet Protocol |
| SOP | Start of Production |
| SRS | Safety Requirement Specification + Design Description |
| STL | Self-Test Library |
| SW | Software |
| TMR | Triple Modular Redundancy |
| TPM | Trusted Platform Module |
| TSC | Technical Safety Concept |
| TSR | Technical Safety Requirement |
| uC | Microcontroller (μC) |
| uP | Microprocessor (μP) or Application-Processor |
| UCM | Update and Configuration Management (AP functional cluster) |
| vECU | virtual ECU |
| VFB | Virtual Functional Bus (AUTOSAR Classic Platform) |
| VM | Virtual Machine |
| VMM | Virtual Machine Monitor |
| Wdg | Watchdog |
Table A.1: List of Abbreviations
References
[1] ISO 26262 (all parts) – Road vehicles – Functional Safety http://www.iso.org
[2] Utilization of Crypto Services AUTOSAR_EXP_UtilizationOfCryptoServices
[3] Glossary AUTOSAR_TR_Glossary
[4] Virtual Functional Bus AUTOSAR_EXP_VFB
[5] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
[6] AUTOSAR Introduction https://www.autosar.org/fileadmin/ABOUT/AUTOSAR_Introduction.pdf
[7] Explanation of Adaptive Platform Design AUTOSAR_EXP_PlatformDesign
[8] Specification of Operating System Interface AUTOSAR_SWS_OperatingSystemInterface
[9] Specification of Execution Management AUTOSAR_SWS_ExecutionManagement
[10] Design guidelines for using parallel processing technologies on Adaptive Platform AUTOSAR_EXP_ParallelProcessingGuidelines
[11] Mapping mixed-criticality applications on multi-core architectures https://doi.org/10.7873/DATE.2014.111
[12] IEEEStandardforInformationTechnology-StandardizedApplicationEnvironment Profile (AEP)-POSIX Realtime and Embedded Application Support https://standards.ieee.org/findstds/standard/1003.13-2003.html
[13] API standards for Open Systems http://www.opengroup.org/austin/papers/wp-apis.txt
[14] Functional Cluster Shortnames AUTOSAR_TR_FunctionalClusterShortnames
[15] Specification of Platform Types AUTOSAR_SWS_PlatformTypes
[16] Explanation of ara::com API AUTOSAR_EXP_ARAComAPI
[17] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager
[18] Specification of Persistency AUTOSAR_SWS_Persistency
[19] Specification of Platform Health Management for Adaptive Platform AUTOSAR_SWS_PlatformHealthManagement
[20] Specification of Identity and Access Management AUTOSAR_SWS_IdentityAndAccessManagement
[21] Specification of RESTful communication AUTOSAR_SWS_REST
[22] Specification of Time Synchronization for Adaptive Platform AUTOSAR_SWS_TimeSync
[23] Specification of Diagnostic Log and Trace AUTOSAR_SWS_DiagnosticLogAndTrace
[24] Specification of Crypto Interface AUTOSAR_SWS_CryptoInterface
[25] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager
[26] Specification of Network Management Interface AUTOSAR_SWS_NetworkManagementInterface
[27] Specification of Update and Configuration Management AUTOSAR_SWS_UpdateAndConfigManagement
[28] Key words for use in RFCs to Indicate Requirement Levels http://www.ietf.org/rfc/rfc2119.txt
[29] Data Integrity Pattern http://en.wikipedia.org/wiki/Data_integrity
253 Specification of Network Management
##2 Acronyms and Abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| API | Application Programming Interface |
| CBV | Control Bit Vector |
| CM | Communication Management |
| CWU | Car Wakeup |
| EM | Execution Management |
| IP | Internet Protocol |
| MTU | Maximum Transmission Unit |
| NM | Network Management |
| NM Node | A node that supports network management. Please note that network node, node and NM node are used with the same meaning througout the document. |
| PN | Partial Network |
| PNI | Partial Network Information |
| UDP | User Datagram Protocol |
| Terms | Description |
|---|---|
| Bus communication | Communication on the physical medium |
| Logical Network | A network in which devices can be addressed independent from the actual network technology. |
| NM cluster | Set of NM nodes coordinated with the use of the NM algorithm. |
| NM message | Refers to the payload transmitted in a packet. It contains the NM User Data, Partial Network Information as well as the Control Bit Vector and the Source Node Identifier. |
| NM packet | Refers to an Ethernet Frame containing an IP as well as an UDP header in addition to a NM message. Please note that adaptive network management is currently only supported for Ethernet. |
| PN communication | Communication during partial network operation |
| Physical channel | A channel enabling communication using physical devices, such as I/O ports and cables. |
| Repeat Message Request Bit Indication | Repeat Message Bit set in the Control Bit Vector of a received NM message. |
| Internally Requested | At least one field NetworkRequestedState associated to that channel/network/PNC/VLAN is set to true. |
| Exernally Requested | A Network Management Message associated to that chan- nel/network/PNC/VLAN has been received. In case of PNC as- sociated means the bit corresponding to this PNC had the value 1. |
| FULL_COM | Communication over the network is possible/allowed, the network is up. |
| NO_COM | Communication over the network is impossible/disabled, the net- work is down. |
3 Related documentation 3.1 Input documents
[1] Glossary AUTOSAR_TR_Glossary
[2] General Requirements specific to Adaptive Platform AUTOSAR_RS_General
[3] Specification of the AUTOSAR Network Management Protocol AUTOSAR_PRS_NetworkManagementProtocol
[4] Requirements on AUTOSAR Network Management AUTOSAR_RS_NetworkManagement
[5] Specification of State Management AUTOSAR_SWS_StateManagement
#254 Requirements on Firmware Over-The-Air
3 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| FOTA | (AUTOSAR) Firmware Over-The-Air |
6 References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Explanation of Firmware Over-The-Air AUTOSAR_EXP_FirmwareOverTheAir
[3] Glossary AUTOSAR_TR_Glossary
[4] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager
[5] NV Data Handling Guideline AUTOSAR_EXP_NVDataHandling
[6] Requirements on Memory Services AUTOSAR_SRS_MemoryServices
[7] Requirements on AUTOSAR Features AUTOSAR_RS_Features
255 Explanation of Firmware Over-The-Air
3.1 Acronyms and Abbreviations
| Abbreviation/Acronym | Description |
|---|---|
| BSW | Basic Software (See LayeredSWArchitecture slide collection in AUTOSAR releases) |
| ECU | Electronic control unit |
| DCM | Diagnostic Communication Manager (AUTOSAR BSW Module, Classic Platform)(Surprisingly not yet listed!) |
| FOTA | Firmware Over-The-Air |
| HSM | Hardware Security Module (cryptographic features realized in HW)(Should actually come from a different doc, e.g. safety or security) |
| NvM | Non-Volatile Memory, BSW Module, sometimes referred to as NV Memory(Surprisingly not yet listed!) |
| OTA | Over-The-Air technologies in general, regardless of AUTOSAR |
| UCM | Update And Configuration Management (Functional Cluster in the Adaptive Platform, AUTOSAR Workgroup) |
| UDS | Unified diagnostic services (see ISO-14229) (Surprisingly not yet listed!) |
References
[1] Specification of Update and Configuration Management AUTOSAR_SWS_UpdateAndConfigManagement
[2] Requirements on Update and Configuration Management AUTOSAR_RS_UpdateAndConfigManagement
[3] Requirements on Firmware Over-The-Air AUTOSAR_RS_FirmwareOverTheAir
[4] Specification of Bulk NvData Manager AUTOSAR_SWS_BulkNvDataManager
[5] Glossary AUTOSAR_TR_Glossary
[6] Unified diagnostic services (UDS) – Part 1: Specification and requirements (Re- lease 2013-03)
http://www.iso.org -> 2020 version are exists.
[7] Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager
[8] Specification of Diagnostic Communication Manager AUTOSAR_SWS_DiagnosticCommunicationManager
256 Specification of AUTOSAR Run-Time Interface
2 Acronyms and Abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| ORTI | "OSEK Run Time Interface", an OSEK specification (in its version 2.2) that defines how debuggers can access OSEK OS internal information. |
| Terms | Description |
|---|---|
| Debugging | "Debugging" refers to halting a system, either as a whole or in parts, for the purpose of • inspecting the contents of the system in a frozen state • single stepping, setting breakpoints, starting and stopping in C or Assembly code |
| Tracing | "Tracing" refers to collecting run-time information over a certain period of time • either as a pure software solution, or with hardware assis- tance • may include processor instruction trace, OS scheduling trace, and/or pure data trace • including time-stamping for further timing analysis |
| Timing Measurement | "Timing Measurement" refers to capturing of timing information • by instrumentation, e.g. via Pre-/PostTaskHooks or other hooks or callouts or • by dedicated hardware support, e.g. hardware perfor- mance counters • does not stop execution |
| Profiling | "Profiling" refers to the process of gaining timing parameters/timing statistics • of functions, tasks, runnables, modules etc. • possibly with minimum/maximum/average statistics • possibly with worst case analysis • possibly calculated out of trace data, repeated snapshots or Timing Measurement |
3.1 Input documents & related standards and norms
[1] Glossary AUTOSAR_TR_Glossary
257 Explanatory Document for usage of AUTOSAR RunTimeInterface
no abbreviations
7.1.1 Input documents & related standards and norms
[1] Specification of AUTOSAR Run-Time Interface AUTOSAR_SWS_ClassicPlatformARTI
[2] Specification of Operating System AUTOSAR_SWS_OS
[3] Specification of RTE Software AUTOSAR_SWS_RTE
258 Requirements on Debugging, Tracing and Profiling support of AUTOSAR Components
3 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| ARTI | AUTOSAR Run Time Interface |
| OS | Operating System |
| SWC | Software Component |
6 References
[1] System Template AUTOSAR_TPS_SystemTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Main Requirements AUTOSAR_RS_Main
259 ARXML Serialization Rules
no abbreviations
References
[1] XML Schema Production Rules AUTOSAR_TPS_XMLSchemaProductionRules
[2] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[3] System Template AUTOSAR_TPS_SystemTemplate
[4] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration
[5] Meta Model AUTOSAR_MMOD_MetaModel
[6] Meta Model-generated XML Schema AUTOSAR_MMOD_XMLSchema
[7] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[8] Extensible Markup Language (XML), v1.0 http://www.w3.org/TR/REC-xml/
[9] XML Schema 1.0 http://www.w3.org/TR/xmlschema-1
[10] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[11] Unified Modeling Language: Superstructure, Version 2.0, OMG Available Specifi- cation, ptc/05-07-04
http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04
[12] Software Process Engineering Meta-Model Specification http://www.omg.org/spec/SPEM/2.0/
260 Integration of Franca IDL Software Component Descriptions
no abbreviations
References
[1] Franca User Guide https://code.google.com/a/eclipselabs.org/p/franca/downloads/ detail?name=FrancaUserGuide-0.3.0.pdf
[2] Virtual Functional Bus AUTOSAR_EXP_VFB
[3] Specification of RTE Software AUTOSAR_SWS_RTE
[4] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[5] Methodology AUTOSAR_TR_Methodology
[6] IPC CommonAPI C++ http://projects.genivi.org/commonapi/
[7] Specification of Platform Types AUTOSAR_SWS_PlatformTypes
261 Methodology
no abbreviations
References
[1] Requirements on Methodology AUTOSAR_RS_Methodology
[2] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[3] Software Process Engineering Meta-Model Specification http://www.omg.org/spec/SPEM/2.0/
[4] Integration of Franca IDL Software Component Descriptions AUTOSAR_TR_FrancaIntegration
[5] Virtual Functional Bus AUTOSAR_EXP_VFB
[6] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[7] System Template AUTOSAR_TPS_SystemTemplate
[8] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[9] General Specification on Transformers AUTOSAR_ASWS_TransformerGeneral
[10] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate
[11] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration
[12] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping
[13] Specification of Compiler Abstraction AUTOSAR_SWS_CompilerAbstraction
[14] Specification of Module E2E Transformer AUTOSAR_SWS_E2ETransformer
[15] Diagnostic Extract Template AUTOSAR_TPS_DiagnosticExtractTemplate
[16] Specification of RTE Software AUTOSAR_SWS_RTE
[17] Specifications of Safety Extensions AUTOSAR_TPS_SafetyExtensions
[18] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition http://www.iso.org
[19] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[20] Specification of ECU Resource Template AUTOSAR_TPS_ECUResourceTemplate
262 Specification of Large Data COM
2 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| DEM | Diagnostic Event Manager |
| DET | Default Error Tracer |
3.1 Inputdocuments
[1] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[4] Specification of RTE AUTOSAR_SWS_RTE.pdf
[5] Specification of PDU Router AUTOSAR_SWS_PDURouter.pdf
[6] Specification of System Template AUTOSAR_RS_SystemTemplate.pdf
263 Specification of COM Based Transformer
No specific terms
References
[1] Glossary AUTOSAR_TR_Glossary
[2] General Specification on Transformers AUTOSAR_ASWS_TransformerGeneral
[3] Specification of RTE Software AUTOSAR_SWS_RTE
[4] Specification of Communication AUTOSAR_SWS_COM
[5] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[6] Requirements on Transformer AUTOSAR_SRS_Transformer
[7] System Template AUTOSAR_TPS_SystemTemplate
[8] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
#264 Specification of Secure Onboard Communication
2.1 Acronymsandabbreviations
| Abbreviation / Acronym | Description |
|---|---|
| CSM | The AUTOSAR Crypto Service Manager |
| SecOC | Secure Onboard Communication |
| MAC | Message Authentication Code |
| FV | Freshness Value |
| FM | Freshness Manager |
2.2 Definitions
| Term | Description |
|---|---|
| Authentic I-PDU | An Authentic I-PDU is an arbitrary AUTOSAR I-PDU the content of which is secured during network transmission by means of the Secured I-PDU. The secured content comprises the complete I-PDU or a part of the I- PDU. |
| Authentication | Authentication is a service related to identification. This function applies to both entities and information itself. Two parties entering into a communication should identify each other. Information delivered over a channel should be authenticated as to origin, date of origin, data content, time sent, etc. For these reasons, this aspect of cryptography is usually subdivided into two major classes: entity authentication and data origin authentication. Data origin authentication implicitly provides data integrity (for if a message is modified, the source has changed). |
| Authentication Information | The Authentication Information consists of a Freshness Value (or a part thereof) and an Authenticator (or a part thereof). Authentication Information are the additional pieces of information that are added by SecOC to realize the Secured I-PDU |
| Authenticator | Authenticator is data that is used to provide message authentication. In general, the term Message Authentication Code (MAC) is used for symmetric approaches while the term Signature or Digital Signature refers to asymmetric approaches having different properties and constraints. |
| Data integrity | Data integrity is the property whereby data has not been altered in an unauthorized manner since the time it was created, transmitted, or stored by an authorized source. To assure data integrity, one should have the ability to detect data manipulation by unauthorized parties. Data manipulation includes such things as insertion, deletion, and substitution. |
| Data origin authentication | Data origin authentication is a type of authentication whereby a party is corroborated as the (original) source of specified data created at some (typically unspecified) time in the past. By definition, data origin authentication includes data integrity. |
| Distinction unilateral/ bilateral authentication | In unilateral authentication, one side proves identity. The requesting side is not even authenticated to the extent of proving that it is allowed to request authentication. In bilateral authentication, the requester is also authenticated at least (see below) to prove the privilege of requesting. There is an efficient and more secure way to authenticate both endpoints, based on the bilateral authentication described above. Along with the authentication (in the second message) requested initially by the receiver (in the first message), the sender also requests an authentication. The receiver sends a third message providing the authentication requested by the sender. This is only three messages (in contrast to four with two unilateral messages). |
| Entity authentication | Entity authentication is the process whereby one party is assured (through acquisition of corroborative evidence) of the identity of a second party involved in a protocol, and that the second has actually participated (i.e., is active at, or immediately prior to, the time the evidence is acquired).Note: Entity authentication means to prove presence and operational readiness of a communication endpoint. This is for example often done by proving access to a cryptographic key and knowledge of a secret.It is necessary to do this without disclosing either key or secret.Entity authentication can be used to prevent record-and-replay attacks. Freshness of messages only complicates them by the need to record a lifetime and corrupt either senders or receivers (real-time) clock.Entity authentication is triggered by the receiver, i.e. the one to be convinced, while the sender has to react by convincing. Record and replay attacks on entity authentication are usually prevented by allowing the receiver some control over the authentication process.In order to prevent the receiver from using this control for steering the sender to malicious purposes or from determining a key or a secret ("oracle attack"), the sender can add more randomness.If not only access to a key (implying membership to a privileged group) but also individuality is to be proven, the sender additionally adds and authenticates its unique identification. |
| Message authentication | Message authentication is a term used analogously with data origin authentication. It provides data origin authentication with respect to the original message source (and data integrity, but no uniqueness and timeliness guarantees). |
| Secured I-PDU | A Secured I-PDU is an AUTOSAR I-PDU that contains Payload of an Authentic I-PDU supplemented by additional Authentication Information. |
| Transaction authentication | Transaction authentication denotes message authentication augmented to additionally provide uniqueness and timeliness guarantees on data (thus preventing undetectable message replay). |
3 Related documentation 3.1 Inputdocuments
[1] AUTOSAR Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[2] AUTOSAR General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf
[3] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[4] Specification of Communication
AUTOSAR_SWS_COM - Specification of Communication
[5] AUTOSAR SecOC Software Requirements Specification AUTOSAR_SRS_SecureOnboardCommunication.pdf
[6] Specification of I-PDU Multiplexer AUTOSAR_SWS_I-PDUMultiplexer.pdf
[7] Specification of PDU Router AUTOSAR_SWS_PduRouter.pdf
[8] Specification of Crypt Service Manager AUTOSAR_SWS_CryptoServiceManager.pdf
[9] System Template,
https://svn3.autosar.org/repos2/work/24_Sources/branches/R4.0/TPS_SystemTe mplate_063/AUTOSAR_TPS_SystemTemplate.pdf
[10] Software Component Template,
https://svn3.autosar.org/repos2/work/24_Sources/branches/R4.0/TPS_SoftwareC omponentTemplate_062/AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[11] Koscher et al: Experimental Security Analysis of a Modern Automobile, 2010 IEEE Symposium on Security and Privacy
[12] Checkoway et al: Comprehensive Experimental Analyses of Automotive Attack Surfaces, USENIX Security 2011
[13] Auguste Kerckhoffs, ‘La cryptographie militaire’, Journal des sciences militaires, vol. IX, pp. 5–38, Jan. 1883, pp. 161–191, Feb. 1883.
[14] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone. Handbook of Applied Cryptography. CRC Press, 1996.
[15] Danny Dolev and Andrew C. Yao: On the security of public key protocols, In Foundations of Computer Science, SFCS 1981
[16] M. Dworkin: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, U.S. Department of Commerce, Information Technology Laboratory (ITL), National Institute of Standards and Technology (NIST), Gaithersburg, MD, USA, NIST Special Publication 800-38B, 2005
3.2 Relatedstandardsandnorms
[17] IEC 7498-1 The Basic Model, IEC Norm, 1994 -> ISO/IEC
[18] National Institute of Standards and Technology (NIST): FIPS-180-4, Secure
Hash Standard (SHS), March 2012, available electronically at http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
[19] FIPS Pub 197: Advanced Encryption Standard (AES), U.S. Department of Commerce, Information Technology Laboratory (ITL), National Institute of Standards and Technology (NIST), Gaithersburg, MD, USA, Federal Information Processing Standards Publication, 2001, electronically available at http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
265 Specification of Ethernet Switch Driver
2 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| DEM | Diagnostic Event Manager module |
| EcuM | ECU State Manager module |
| Eth | Ethernet Controller Driver (AUTOSAR BSW module) |
| EthIf | Ethernet Interface (AUTOSAR BSW module) |
| EthTrcv | Ethernet Transceiver Driver (AUTOSAR BSW module) |
| MII | Media Independent Interface (standardized interface provided by Ethernet controllers to access Ethernet transceivers) |
| MDIO | Management Data Input/Output |
3.1 Input documents & related standards and norms
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
[2] Specification of Ethernet Interface AUTOSAR_SWS_EthernetInterface
[3] Specification of Ethernet Transceiver Driver AUTOSAR_SWS_EthernetTransceiverDriver
[4] Specification of Ethernet Driver AUTOSAR_SWS_EthernetDriver
[5] Specification of SPI Handler/Driver AUTOSAR_SWS_SPIHandlerDriver
[6] Glossary AUTOSAR_TR_Glossary
[7] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[8] Requirements on Ethernet Support in AUTOSAR AUTOSAR_SRS_Ethernet
[9] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[10] IEEE 802.1Q-2011 - IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks
[11] Specification of Time Synchronization over Ethernet AUTOSAR_SWS_TimeSyncOverEthernet
[12] Specification of NVRAM Manager AUTOSAR_SWS_NVRAMManager
266 Requirements
no acronyms and abbreviations
References
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[2] Glossary AUTOSAR_TR_Glossary
[3] Requirements on AUTOSAR Features AUTOSAR_RS_Features
[4] System Template AUTOSAR_TPS_SystemTemplate
[5] Specification of Communication AUTOSAR_SWS_COM
267 Specification of SOME/IP Transformer
2 Acronyms and Abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| Client-Service-Instance-Entry | The configuration and required data of a service instance another ECU offers shall be called Client-Service-Instance-Entry at the ECU using this service (Client). |
| Field | a field represents a status and thus has a valid value at all times on which getter, setter and notfier act upon. |
| Finding a service instance | to send a SOME/IP-SD message in order to find a needed ser- vice instance. |
| Getter | a Request/Response call that allows read access to a field. |
| Method | a method, procedure, function, or subroutine that is called/in- voked |
| Notifier | sends out event message with a new value on change of the value of the field. |
| Request | a message of the client to the server invoking a method |
| Response | a message of the server to the client transporting results of a method invocation |
| Service | a logical combination of zero or more methods, zero or more events, and zero or more fields (empty service is allowed, e.g. for announcing non-SOME/IP services in SOME/IP-SD) |
| Service Instance | software implementation of the service interface, which can exist more than once in the vehicle and more than once on an ECU |
| Service Interface | the formal specification of the service including its methods, events, and fields |
| Setter | a Request/Response call that allows write access to a field. |
| SD | Service Discovery (see[2]) |
| SOME/IP | Scalable service-Oriented MiddlewarE over IP |
References
[1] Glossary AUTOSAR_TR_Glossary
[2] Specification of Service Discovery AUTOSAR_SWS_ServiceDiscovery
[3] General Specification on Transformers AUTOSAR_ASWS_TransformerGeneral
[4] Specification of Socket Adaptor AUTOSAR_SWS_SocketAdaptor
[5] Specification of RTE Software AUTOSAR_SWS_RTE
[6] Requirements on AUTOSAR Features AUTOSAR_RS_Features
[7] Specification of Platform Types AUTOSAR_SWS_PlatformTypes
[8] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[9] System Template AUTOSAR_TPS_SystemTemplate
[10] Requirements on Transformer AUTOSAR_SRS_Transformer
[11] UTF-8, a transformation format of ISO 10646 http://www.ietf.org/rfc/rfc3629.txt
[12] UTF-16, an encoding of ISO 10646 http://www.ietf.org/rfc/rfc2781.txt
[13] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[14] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
268 Requirements on Secure Onboard Communication
3 Acronyms and abbreviations
| Acronym | Description |
|---|---|
| MAC | Message Authentication Code |
| SecOC | Secure Onboard Communication |
| NVM | Non volatile memory |
| Authentic I-PDU | An Authentic I-PDU is an arbitrary AUTOSAR I-PDU that is completely secured during network transmission by means of the Secured I-PDU |
| Secured I-PDU | A Secured I-PDU is an AUTOSAR I-PDU that contains Payload of an Authentic I- PDU supplemented by additional Authentication Information. |
269 General Specification of Transformers
no acronyms and abbreviations
References
[1] Glossary AUTOSAR_TR_Glossary
[2] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
[3] System Template AUTOSAR_TPS_SystemTemplate
[4] Specification of SOME/IP Transformer AUTOSAR_SWS_SOMEIPTransformer
[5] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral
[6] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
270 Overview of Functional Safety Measures in AUTOSAR
5.1 Acronyms and abbreviations
| ID | ISO26262 Reference |
|---|---|
| 015 | Part 5: [D.2.5.1] RAM Pattern test |
| 016 | Part 5: [D.2.5.3] RAM March test |
| 012 | Part 5: [Table D.6] Volatile Memory |
| 013 | Part 5: [Table D.1] General semiconductor elements – Volatile Memory |
| Abbreviation / Acronym | Description |
|---|---|
| HARA | Hazard Analysis |
| HAZOP | Hazard & Operability Analysis |
| SEooC | Safety Element out of Context |
| HTM | Hardware Test Manager |
| HTMSS | Hardware Test Manager on Startup and Shutdown |
| ASIL | Automotive Safety Integrity Level |
| DMA | Direct Memory Access |
| EMC | Electromagnetic Compatibility |
| IOC | Inter-OS-Application Communicator |
| CRC | Cyclic Redundancy Check |
| TP | Transport Protocol |
| BIST | Built In Self Test |
| FTTI | Fault Tolerant Time Interval |
| MSTP | Microcontroller Specific Test Package |
5.2 Related Documents
[1] ISO26262 International Standard, First edition 2011-11-15
[2] Specification of Operating System
[3] Requirements on AUTOSAR Features
[4] Layered Software Architecture
[5] Specification of Watchdog Manager
[6] Specification of SW-C End-to-End Communication Protection Library
[7] Specification of Module E2E Transformer
[8] General Specification on Transformers
[9] Specification of ECU State Manager
[10]Specification of ECU State Manager with fixed state machine Functional
[11]Safety analysis of an exemplary system using AUTOSAR
[12] Specifications of Safety Extensions
[13]Specification of ECU Configuration
[14]Technical Safety Concept Status Report
[15]Explanation of Error Handling on Application Level
[16]Specification of Core Test
[17]Requirements on Core Test
[18]Specification of RAM Test
[19]Requirements on RAM Test
[20]Specification of Synchronized Time-Base Manager
271 Specification of Hardware Test Manager on start up and shutdown
2 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| ADC | Analog to Digital converter |
| BIST | Built In Self Test |
| BSW | Basic Software |
| DET | Default error tracer |
| ECU | Electronic Control Unit |
| ECUM | Electronic Control Unit Manager |
| HTMSS | Hardware Test Management startup shutdown |
| MCU | Micro Controller Unit |
| MSTP | Microcontroller Specific Test Package |
| RTE | Run Time Environment |
3.1 Inputdocuments
[1] List of Basic Software Modules AUTOSAR_BasicSoftwareModules.pdf
[2] AUTOSAR Layered Software Architecture AUTOSAR_LayeredSoftwareArchitecture.pdf
[3] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[4] Specification of Memory Mapping AUTOSAR_SWS_MemoryMapping.pdf
[5] Specification of RTE AUTOSAR_SWS_RTE.pdf
[6] Specification of ECU state manager AUTOSAR_SWS_ECUStateManager.pdf
[7] Requirements on HTMSS AUTOSAR_SRS_HTMSS.pdf
[8] Technical Report on HTMSS AUTOSAR_TR_HWTestManagementIntegrationGuide.pdf
3.2 Relatedstandardsandnorms
[5] IEC 7498-1 The Basic Model, IEC Norm, 1994 -> ISO/IEC
272 Specification of I/O Hardware Abstraction
2 Acronyms and abbreviations
| Abbreviation / Acronym | Description |
|---|---|
| AUTOSAR | AUTomotive Open System ARchitecture |
| API | Application Programming Interface |
| BSW | Basic SoftWare |
| BSWMD | Basic SoftWare Module Description |
| C/S | Client/Server |
| DET | Default Error Tracer |
| ECU | Electronic Control Unit |
| HW | HardWare |
| IoHwAb | Input/Output Hardware Abstraction |
| ISR | Interrupt Service Routine |
| MCAL | MicroController Abstraction Layer |
| OS | Operating System |
| RTE | RunTime Environment |
| S/R | Sender/Receiver |
| SW | SoftWare |
| SWC | SoftWare Component (see [8] for further information) |
| XML | eXtensible Markup Language |
Expressions used in this document
|Expression|DescriptionExample|
|:--|:--|:--|
|Callback|Within this document, the term ‘callback’ is used for API services, which are intended for notifications to other BSW modules.| |
|Callout|Callouts are function stubs, which can be filled at configuration time, with the purpose to add functionality to the module that provides the callout.| |
|Class|A class represents a set of signals that has similar electrical characteristics.|Analogue class, Discrete class, ...|
|Client / Server communication|This definition is an extract from [9]:Client-server communication involves two entities, the client which is the requirer (or user) of a service and the server that provides the service. The client initiates the communication, requesting that the server performs a service, transferring a parameter set if necessary. The server, in the form of the RTE, waits for incoming communication requests from a client, performs the requested service and dispatches a response to the client's request. So, the direction of initiation is used to categorize whether an AUTOSAR Software Component is a client or a server.| |
|Electrical Signal|An electrical signal is the physical signal on the pin of the ECU.|Physical input voltage at an ECU-Pin |
|ECU pin|An ECU pin is an electrical hardware connection of the ECU with the rest of the electronic system.| |
|ECU Signal|An ECU Signal is the software representation of an electrical signal. An ECU signal has attributes and a symbolic name |Input voltage ,Discrete Output, PWM Input|
|ECU Signal Group|An ECU Signal Group is the software representation of a group of electrical signals.||
| Attributes| Characteristics that can be Software (SW) and Hardware (HW) for each kind of ECU signals existing in an ECU. Some of the Attributes are fixed by the port definitions, others can be configured in the I/O Hardware Abstraction.|Range, Lifetime / delay|
|Sender-receiver communication|This definition is an extract from [9]:Sender-receiver communication involves the transmission and reception of signals consisting of atomic data elements that are sent by one component and received by one or more components. A sender- receiver interface can contain multiple data elements. Sender-receiver communication is one-way - any reply sent by the receiver is sent as a separate sender- receiver communication. A port of a component that requires an AUTOSAR sender-receiver interface can read the data elements described in the interface and a port that provides the interface can write the data elements.| |
| Symbolic name| The symbolic name of a ECU signal is used by the I/O Hardware Abstraction to make a link (function, pin)| |
ECU signal attributes
| Expression | Description | Example |
|---|---|---|
| Range | This is a functional range and not an electrical range. All the range is used either for functional needs or for diagnosis detections. For analogue ECU signals [lowerLimit...upperLimit] (Voltage, current). For the particular case of a resistance signal and a timing signal (period), the lowerLimit value can not be negative. | [-12Volts...+12Volts] (voltage) [0,1] (discrete signals) [0...upperLimit] (period timing signal) [-100...100%] (Duty Cycle based timing signal) |
| Resolution | This attribute is for many Classes dependent on the range and the Data Type. Example: (upperLimit - lowerLimit) / (2datatypelength -1) For the others classes, it is known and defined. | [-12 Volts...+12Volts] Data Type : 16 bits Resolution => 24 / 65535 |
| Accuracy | It depends of hardware peripheral used for acquisition and/or generation. | ADC converter could be a 8/10/12/16 bits converter |
| Inversion | Inversion between the physical value and the logical value. This attribute is not visible but done by I/O Hardware Abstraction to deliver expected values to users. | Physical HighState -> (signal=False) Physical LowState->(signal=True) |
| Sampling rate | Time period required to get a signal value. | Sampling rate for a sampling windows (burst) |
3 Related documentation 3.1 Inputdocuments
[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] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[5] Glossary AUTOSAR_TR_Glossary.pdf
[6] General Requirements on SPA AUTOSAR_SRS_SPALGeneral.pdf
[7] Requirements on I/O Hardware Abstraction AUTOSAR_SRS_IOHWAbstraction.pdf
[8] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[9] Specification of RTE Software AUTOSAR_SWS_RTE.pdf
[10] Specification of ECU State Manager AUTOSAR_SWS_ECUStateManager.pdf
[11] Specification of ECU Resource Template AUTOSAR_TPS_ECUResourceTemplate.pdf
[12] Specification of ADC Driver AUTOSAR_SWS_ADCDriver.pdf
[13] Specification of DIO Driver AUTOSAR_SWS_DIODriver.pdf
[14] Specification of ICU Driver AUTOSAR_SWS_ICUDriver.pdf
[15] Specification of PWM Driver AUTOSAR_SWS_PWMDriver.pdf
[16] Specification of PORT Driver AUTOSAR_SWS_PORTDriver.pdf
[17] Specification of GPT Driver AUTOSAR_SWS_GPTDriver.pdf
[18] Specification of SPI Handler/Driver AUTOSAR_SWS_SPIHandlerDriver.pdf
[19] Basic Software Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[20] Specification of Standard Types AUTOSAR_SWS_StandardTypes.pdf
[21] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[22] Specification of OCU Driver AUTOSAR_SWS_OCUDriver.doc
273 Modeling Guidelines of Basic Software EA UML Model
| Abbreviation / Acronym | Description |
|---|---|
| Ma | Module Abbreviation |
References
[1] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
[2] List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[3] Glossary AUTOSAR_TR_Glossary
[4] Specification of Standard Types AUTOSAR_SWS_StandardTypes
[5] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
[6] Standardized M1 Models used for the Definition of AUTOSAR AUTOSAR_MOD_GeneralDefinitions
274 Virtual Functional Bus
no abbreviations
13 References
[1] Methodology AUTOSAR_TR_Methodology.pdf
[2] Glossary AUTOSAR_TR_Glossary.pdf
[3] Main Requirements AUTOSAR_RS_Main.pdf
[4] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf
[5] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
[6] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[7] Specification of RTE AUTOSAR_SWS_RTE.pdf
[8] Specification of Timing Extensions AUTOSAR_TPS_TimingExtensions.pdf
[9]Explanation of Application Interfaces of the Body and Comfort Domain AUTOSAR_EXP_AIBodyAndComfort.pdf
[10] Explanation of Application Interfaces of the Powertrain Domain AUTOSAR_EXP_AIPowertrain.pdf
[11] Explanation of Application Interfaces of the Chassis Domain AUTOSAR_EXP_AIChassis.pdf
[12] Explanation of Application Interfaces of Occupant and Pedestrian Safety Systems Domain AUTOSAR_EXP_AIOccupantAndPedestrianSafety.pdf
[13]Explanation of Application Interfaces of the HMI, Multimedia and Telematics Domain
AUTOSAR_EXP_AIHMIMultimediaAndTelematics.pdf
[14] Application Interfaces User Guide AUTOSAR_EXP_AIUserGuide.pdf
[15] ISO 17356-4
OSEK/VDX Communication (COM) www.iso.org
275 Utilization of Crypto Services
2 Acronyms and Abbreviations
| Acronym | Description |
|---|---|
| BSW | Basic Software |
| CDD | Complex Device Driver |
| CRYIF | Crypto Interface |
| CRYPTO | Crypto Driver |
| CSM | Crypto Service Manager |
| HSM | Hardware Security Module |
| NvM | NVRAM Manager |
| RTE | Runtime Environment |
| SHE | Security Hardware Extension |
| SWC | Software Component |
2.1 Glossary of Terms
| Terminology | Description |
|---|---|
| Crypto Driver Object | A Crypto Driver implements one or more Crypto Driver Objects. The Crypto Driver Object can offer different crypto primitives in hardware or software. The Crypto Driver Objects of one Crypto Driver are independent of each other. There is only one workspace for each Crypto Driver Object (i.e. only one crypto primitive can be performed at the same time). |
| Crypto Primitive | A crypto primitive is an instance of a configured cryptographic algorithm realized in a Crypto Driver Object. |
| Job | A job is a configured crypto primitive together with a referenced key. |
| Key | A key can be referenced by a job or by a key management function in the CSM. In the Crypto Driver, the key refers a specific key type. |
| Key Element | Key elements are used to store data. This data can be, e.g., key material or the IV needed for AES encryption. It can also be used to configure the behavior of the key management functions. |
| Key Type | A key type consists of references to key elements. The key types are typically pre-configured by the vendor of the Crypto Driver. |
| Processing | Indicates the kind of job processing. |
| Asynchronous | The job is not processed immediately when calling a corresponding function. Usually, the caller is informed via a callback function when the job has been finished. |
| Synchronous | The job is processed immediately when calling a corresponding function. When the function returns, a result will be available. |
3 Related Documentation 3.1 InputDocuments
[1] Specification of Crypto Driver AUTOSAR_SWS_CryptoDriver.pdf
[2] Specification of Crypto Interface AUTOSAR_SWS_CryptoInterface.pdf
[3] Specification of Crypto Service Manager AUTOSAR_SWS_CryptoServiceManager.pdf
[4] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
276 Requirements on AUTOSAR Features
no abbreviations
6 References
[GLOSSARY]AUTOSAR Glossary, AUTOSAR_TR_Glossary.pdf
[ISO 10681] Road vehicles -- Communication on FlexRay
[ISO 11898] Road vehicles -- Controller area network (CAN)
[ISO 13400] Road vehicles -- Diagnostic communication over Internet Protocol (DoIP)
[ISO 14229] Road vehicles -- Unified diagnostic services (UDS)
[ISO 15031] Road vehicles -- Communication between vehicle and external equipment for emissions-related diagnostics
[ISO 15765] Road vehicles -- Diagnostic communication over Controller Area Network (DoCAN, UDS on CAN)
[ISO 17356] Road vehicles -- Part 3: OSEK/VDX Operating System (OS)
[ISO 17987] Road vehicles -- Local Interconnect Network (LIN)
[ISO 26262] Road vehicles -- Functional safety
[ISO 27145] Road vehicles -- Implementation of WWH-OBD communication requirements
[RS_MAIN] AUTOSAR Main Requirements, AUTOSAR_RS_Main.pdf
[SAE J1939] Serial Control and Communications Heavy Duty Vehicle Network
[TPS_STDT] AUTOSAR Standardization Template, AUTOSAR_TPS_StandardizationTemplate.pdf
277 Specification of Bulk NvData Manager
no abbreviations
3.1 Input documents & related standards and norms
[1] Glossary AUTOSAR_TR_Glossary
[2] General Specification of Basic Software Modules AUTOSAR_SWS_BSWGeneral
278 Predefined Names in AUTOSAR
2 [VirtualModules] Virtual Modules
| shortName | abbrName | longName | Classification, Description |
|---|---|---|---|
| Arti | Arti | AUTOSAR Run-Time Interface | ModuleDesignator. Arti is a pseudo module which defines parameters holding run-time information of the application for debugging and tracing. |
| AISpecification | AISpecification | XML Specification of Application Interfaces | AUTOSAR-Document, Module Designator. This represents the Appplication Interfaces. |
| EcuC | EcuC | Ecu Configuration | ModuleDesignator. EcuC is a pseudo module which defines parameters applicable to all other BSW modules. |
| GeneralBlueprints | GenBlpr | General Blueprints | ModuleDesignator. Collection of blueprints for AUTOSAR M1 models. |
| GeneralDefinitions | GenDef | General Definitions | ModuleDesignator. This represents general elements that can be applied for both, basic (BSW) and application software (ASW), but for which no explicit AUTOSAR Document is maintained. Example for objects in this virtual module are elements such as life cycle definitions, role definitions etc. |
| V2X | V2X | Vehicle-2-X | ModuleDesignator. V2X is used as a cluster abbreviation by all cross module types used by the Vehicle-2-X communication modules. |
Table 2.1: Virtual Modules
3 [InformationCategories] AUTOSAR Information Categories
| shortName | abbrName | longName | Classification, Description |
|---|---|---|---|
| ASWS | ASWS | Abstract SWS Software Specification | DocumentCategory, TraceCategory. General Specification of AUTOSAR Basic Software Modules |
| ATR | ATR | Acceptance Test Requirement | DocumentCategory, TraceCategory. Specification of requirements for acceptance tests |
| ATS | ATS | Acceptance Test Specification | DocumentCategory, TraceCategory. Test specification and scripts for the execution of acceptance tests |
| CONC | CONC | Concept Document | DocumentCategory, TraceCategory |
| CTCF | CTCF | Configuration Settings | DocumentCategory, TraceCategory. Configuration settings for the execution of conformance Tests |
| CTSP | CTSP | Conformance Test Specification | DocumentCategory, TraceCategory. Test specification and scripts for the execution of conformance tests |
| EXP | EXP | Explanation | DocumentCategory, TraceCategory. Explanatory material discussiong contents already shown in other documents |
| MMOD | MMOD | MetaModel | DocumentCategory, TraceCategory. |
| MOD | MOD | Model | DocumentCategory, TraceCategory. Modeled contents (a model or generated from a model) on meta level 1 (Model) |
| PD | PD | Process Description | DocumentCategory, TraceCategory. Description of process applied within AUTOSAR standardization activities |
| PDEP | PDEP | Profile of Data Exchange Point | DocumentCategory, TraceCategory. Contains models that tailor AUTOSAR specifications and templates for specific data exchange points |
| PRS | PRS | Protocol Specification | DocumentCategory, TraceCategory. Specification of Protocols standardized by AUTOSAR |
| RS | RS | Requirement Specification | DocumentCategory, TraceCategory. Specification of requirements other than for software specifications |
| SRS | SRS | Software Requirement Specification | DocumentCategory, TraceCategory. Specification of requirements for software specifications |
| SWS | SWS | Software Specification | DocumentCategory, TraceCategory Specification of AUTOSAR Software |
| TMPL | TMPL | Template | InternalDocumentCategory Predefined documentation templates |
| TPS | TPS | Template Specification | DocumentCategory, TraceCategory. Specification of AUTOSAR Templates, containing Meta model information, constraints etc. |
| TR | TR | Technical Report | DocumentCategory, TraceCategory A general technical report describing arbitrary AUTOSAR related topics |
| UC | UC | Use Case Specification | TraceCategory. |
| ZAUX | ZAUX | Auxilary material | InternalDocumentCategory. Auxillary files used internally for the creation of the standard. May be merged with ZSUPP. |
| ZGEN | ZGEN | Generated intermediate material | Internal Document Category. Generated intermediate products which are maintained in the SCM system of AUTOSAR and used internally for the creation of the standard |
| ZSUPP | ZSUPP | Supplemental material | Internal Document Category. Supplementary material used internally for the creation of the standard |
| Table 3.1: AUTOSAR Information Categories |
4 [DocumentAbbreviations] AUTOSAR Document Abbreviations for Trace Prefixes
| shortName | abbrName | longName | Classification, Description |
|---|---|---|---|
| ARTI | ARTI | AUTOSAR Run-Time Interface | DocumentAbbreviation. This document explains Interfaces for the "AUTOSAR Run-Time Interface" |
| AIBodyAndComfort | AIBC | Application Interfaces "Body and Comfort" | DocumentAbbreviation. This document explains Application Interfaces for "Body and Comfort". |
| AIChassis | AICS | Application Interfaces "Chassis" | DocumentAbbreviation. This document explains Application Interfaces for "Chassis". |
| AIDesignPattern Catalogue | AIDPC | Application Interface Design Pattern Catalogue | DocumentAbbreviation. This document contains Application Interface Design Pattern Catalogue. |
| AIHMIMultimediaAnd Telematics | AIHMI | Application Interfaces "HMI Multimedia and Telematics" | DocumentAbbreviation. This document explains Application Interfaces for "HMI Multimedia And Telematics". |
| AIOccupantAnd PedestrianSafety | AIOPS | Application Interfaces "Occupant and pedestrian Safety" | DocumentAbbreviation. This document explains Application Interfaces for "Application Interface Occupant and pedestrian Safety". |
| AIPowertrain | AIPT | Application Interfaces "Powertrain" | DocumentAbbreviation. This document document explains Application Interfaces for "Powertrain". |
| AISpecification Examples | AISE | XML Examples of Application Interfaces | DocumentAbbreviation. This represents XML Examples of Appplication Interfaces. |
| AIUserGuide | AIUG | Application Interfaces User Guide | DocumentAbbreviation. This document aims at explaining all relevant details about the AI Table. |
| ApplicationLevelError Handling | ALEH | Application Level Error Handling | DocumentAbbreviation. This document explains the Application Level Error Handling. |
| AdaptiveNetwork Management | ANM | Adaptive Network Management | DocumentAbbreviation. Adaptive Platform - to be filled correclty |
| AdaptivePlatformTypes | ASR | ARXML Serialization Rules | DocumentAbbreviation. This document explains how to serialize AUTOSAR models into ARXML files and vice versa. |
| AutosarModel Constraints | ArModC | Autosar Model Constraints | DocumentAbbreviation. This document explains Autosar Model Constraints. |
| ARXMLSerialization Rules | ASR | ARXML Serialization Rules | DocumentAbbreviation. This document explains how to serialize AUTOSAR models into ARXML files and vice versa. |
| ATBM | ATBM | Interaction with Behavioral Models | DocumentAbbreviation. This document describes interaction with behavioral models. |
| BSWAndRTEFeatures | BRF | AUTOSAR BSW and RTE Features | DocumentAbbreviation. This document specifies the features of the BSW Architecture and the RTE. |
| BSW | BSW | Basic Software | DocumentAbbreviation. This abbreviation represents the superset of all BSW software requirement specifications. This means that this abbreviation is used throughout all Basic Software Specifications. |
| BSWModuleDescription Template | BSWMDT | Basic Software Module Description Template | DocumentAbbreviation. This document specifies how to describe a Basic Software |
| BSWModuleList | BSWML | Basic Software Module List | DocumentAbbreviation. This document lists the BSW modules. |
| BSWUMLModel ModelingGuide | BSWUMG | BSW UML Model Modeling Guide | DocumentAbbreviation. This guideline describes the BSW UML Model modeling. |
| BSWUML | BSWUML | Basic Software UML model | DocumentAbbreviation. This abbreviation represents the BSW UML model. This means that this abbreviation is used throughout all elements maintained in the BSW UML model. |
| BWCStatement | BWC | BWC Statement | DocumentAbbreviation. This document describes the backward compatibility statement. |
| CDDDesignAnd IntegrationGuideline | CDDG | CDD Design And Integration Guideline | DocumentAbbreviation. This guideline describes the Design and the Integration of CDD. |
| CommunicationCan | COMCAN | Communication on Can | DocumentAbbreviation. Relevant for communication on CAN. |
| CommunicationFlexray | COMFR | Communication on Flexray | DocumentAbbreviation. Relevant for communication on Flexray. |
| CommunicationLin | COMLIN | Communication on Lin | DocumentAbbreviation. Relevant for communication on LIN. |
| Communication Management | COMMGMT | Communication Management | DocumentAbbreviation. Relevant for communication management. |
| CommunicationViaBus | COMVB | Communication via a bus | DocumentAbbreviation. Relevant for communication via a bus. |
| Diagnostic | DIAG | Requirements on Diagnostic | DocumentAbbreviation. The goal of AUTOSAR WP Diagnostics and this document is to define to what extent elements of the diagnostic basic software have to be configurable and what preliminaries they shall comply with to meet the tailoring requirements. The handling of the legislated OBD and enhanced Diagnostics shall also be achieved. |
| AdaptiveDiagnostics | DM | Adaptive Diagnostics | DocumentAbbreviation. Adaptive Platform - to be filled correclty |
| ECUConfiguration | ECUC | Specification of ECU Configuration | DocumentAbbreviation. This document specifies the technical details of the ECU configuration |
| ECUConfiguration Parameters | ECUCP | ECU Configuration Parameters | DocumentAbbreviation. This document describes ECU Configuration Parameters. |
| EcuModeManagement | ECUMGMT | ECU Mode Management | DocumentAbbreviation. Relevant for ECU mode management. |
| ECUResourceTemplate | ECUR | Specification of ECU Resource Template | DocumentAbbreviation. This specifies how to describe Resources of an ECU |
| ErrorDescription | ED | Error Description | DocumentAbbreviation. This document explains the Error Description. |
| ExecutionManagement | EM | Execution Management | DocumentAbbreviation. Adaptive Platform - to be filled correclty |
| ErrataSheet | ERSH | Errata Sheet | DocumentAbbreviation. This document explains the Errata Sheet. |
| FrancaIntegration | FCAINT | Franca Integration | DocumentAbbreviation. This document describes the Franca Integration. |
| Features | Feature | Feature Specification Acceptance Tests | DocumentAbbreviation. Feature Specification of the acceptance tests. |
| FeatureModelExchange Format | FMDT | Specification of Feature Model Exchange Format | DocumentAbbreviation. This specifies how to describe the Feature Model Exchange Format. |
| FreeRunningTimer | FRT | Free Running Timer | DocumentAbbreviation. This document describes the Free Running Timer. |
| Glossary | GLOS | Glossary | DocumentAbbreviation. This document lists all Glossary items. |
| GenericStructure Template | GST | Generic Structure Template | DocumentAbbreviation. This specifies common aspects applicable to all templates. |
| Gateway | GTW | Gateway | DocumentAbbreviation. This document explains the Gateway. |
| HealthManagement | HM | Health Management | DocumentAbbreviation. Adaptive Platform - to be filled correclty |
| InteroperabilityOf AutosarTools | IOAT | Interoperability of AUTOSAR Tools | DocumentAbbreviation. This document describes various aspects of interoperability of AUTOSAR tools. |
| InteroperabilityOf AutosarTools Supplement | IOATS | Interoperability of AUTOSAR Tools Supplement | DocumentAbbreviation. This document contains baseline profiles of data exchange points and examples. |
| IOHWAbstraction | IOHWAB | IO Hardware Abstraction | DocumentAbbreviation. This document describes the IO Hardware Abstraction. |
| InterruptHandling Explanation | IRH | Interrupt Handling Explanation | DocumentAbbreviation. This document explains the Interrupt Handling. |
| SRSLibraries | LIBS | Requirements on Libraries | DocumentAbbreviation. This document specifies requirements on the AUTOSAR Libraries. |
| AdaptiveLogAndTrace | LOG | Adaptive Log and Trace | DocumentAbbreviation. Adaptive Platform - to be filled correclty |
| LayeredSoftware Architecture | LSA | Layered Software Architecture | DocumentAbbreviation. This document describes the Layered Software Architecture. |
| MainRequirements | Main | AUTOSAR Main Requirements | DocumentAbbreviation. This document specifies the AUTOSAR main requirements. |
| AIMeasurement CalibrationDiagnostics | MCAI | Unique Names for Documentation, Measurement and Calibration: Modeling and Naming Aspects including Automatic Generation | DocumentAbbreviation. This document discusses how to automatically generate display names for measurement, calibration and diagnostic tools (MCD). |
| AIMeasurement CalibrationDiagnostics_ Assumptions | MCA | Assumptions in Unique Names for Documentation, Measurement and Calibration: Modeling and Naming Aspects including Automatic Generation | DocumentAbbreviation. This keyword reflects the assumptions how to automatically generate display names for measurement, calibration and diagnostic tools (MCD). The keyword is used for document internal tracing |
| AIMeasurement CalibrationDiagnostics_ GenerationRules | MCG | Generation Rules in Unique Names for Documentation, Measurement and Calibration: Modeling and Naming Aspects including Automatic Generation | DocumentAbbreviation. This keyword reflects the generation rules how to automatically generate display names for measurement, calibration and diagnostic tools (MCD). The keyword is used for document internal tracing. |
| AIMeasurement CalibrationDiagnostics_ ModelingRules | MCM | Modeling Rules in Unique Names for Documentation, Measurement and Calibration: Modeling and Naming Aspects including Automatic Generation | DocumentAbbreviation. This keyword reflects the modeling rules of how to automatically generate display names for measurement, calibration and diagnostic tools (MCD). The keyword is used for document internal tracing. |
| AIMeasurement CalibrationDiagnostics_ Requirements | MCR | Requirements in Unique Names for Documentation, Measurement and Calibration: Modeling and Naming Aspects including Automatic Generation | DocumentAbbreviation. This keyword reflects the requirments of how to automatically generate display names for measurement, calibration and diagnostic tools (MCD). The keyword is used for document internal tracing. |
| MemoryServices | MEM | Requirements on Memory Services | DocumentAbbreviation. This document specifies requirements on Basic Software Modules of the memory services. |
| Methodology | METH | AUTOSAR Methodology | DocumentAbbreviation. This describes the AUTOSAR Methodolgy. |
| MethodologyModel Rules | MethModR | Methodology Model Rules | DocumentAbbreviation. This document describes the Methodology Model Rules. |
| MiscSupport | MICS | Miscellaneous Support | DocumentAbbreviation. This document contains miscellaneous support items. |
| MetaModel | MM | Meta Model | DocumentAbbreviation. This document describes the Meta Model. |
| MemoryHWAbstraction Layer | MMHWABLY | Memory Hardware Abstraction Layer | DocumentAbbreviation. This document describes the Memory Hardware Abstraction Layer. |
| ModeManagement Guide | MMG | Mode Management Guide | DocumentAbbreviation. This guideline describes the Mode Management. |
| ModeMgm | ModeMgm | Mode Management | DocumentAbbreviation. This document specifies Mode Management in AUTOSAR. |
| MultiCoreGuide | MTCG | Multi Core Guide | DocumentAbbreviation. This guideline describes Multi Core. |
| MethodologyAnd TemplatesGeneral | MTG | General Requirements on Methodology and Templates | DocumentAbbreviation. This document has the purpose to collect requirements on Methodology and Templates which are relevant for more than one document. |
| OperatingSystem Interface | OSI | Operating System Interface | DocumentAbbreviation |
| Pesistency | PER | Persistency | DocumentAbbreviation. Adaptive Platform - to be filled correclty |
| PredefinedNames | PDN | AUTOSAR PredefinedNames | DocumentAbbreviation. This document describes various predefined names used in AUTOSAR. |
| ProjectObjectives | PO | AUTOSAR Project Objectives | DocumentAbbreviation. This document specifies the AUTOSAR Project Objectives. |
| ReferenceBase | RefBase | Reference Base | DocumentAbbreviation. This document contains Reference Base items. |
| Requirements | Requirement | Requirements Acceptance Tests | DocumentAbbreviation |
| ReleaseOverviewAnd RevHistory | RORH | Release Overview And Rev History | DocumentAbbreviation. This document provides a Release Overview and Rev History. |
| RTE | RTE | Runtime Environment | DocumentAbbreviation. This document specifies the AUTOSAR Runtime Environment. |
| SAE | SAE | Society of Automotive Engineers | DocumentAbbreviation. This document describes the network standard developed by the Society of Automotive Engineers. |
| SafetyExtensions | SAFEX | Specifcation of Safety Extensions | DocumentAbbreviation. This document specifes how to describe the safety relevant properties and requirements of an AUTOSAR System. |
| XMLSchema Supplement | SchemaSupp | XML Schema Supplement | DocumentAbbreviation. This document explains the XML Schema. |
| SomeIpExample | SIPEX | SomeIp Example | DocumentAbbreviation. This document contains SomeIp Examples. |
| SPAL | SPAL | Standard Peripheral Abstraction Layer | DocumentAbbreviation. This document describes the Standard Peripheral Abstraction Layer. |
| SafetyUseCase | SUC | Safety Use Case | DocumentAbbreviation. This document explains the Safety Use Cases. |
| SWCModeling | SWCM | Software Component Modeling | DocumentAbbreviation. This document describes the modeling of Software Components. |
| SoftwareComponent Template | SWCT | Software Component Template | DocumentAbbreviation. This document specifies how to describe Software Components. |
| SWCModelingGuide | SWMG | SW-C and System Modeling Guide | DocumentAbbreviation. This document gives guidelines and conventions on using the AUTOSAR model elements in order to build AUTOSAR systems. |
| SWCModelingGuide_ NamingRules | SWNR | Naming Rules in SW-C and System Modeling Guide | DocumentAbbreviation. This document gives guidelines and conventions, in particular the naming rules on using the AUTOSAR model elements in order to build AUTOSAR systems. |
| Standardization Template | STDT | Standardization Template | DocumentAbbreviation. This specifies how AUTOSAR Standardization is represented as ARXML file. |
| SystemTemplate | SYST | System Template | DocumentAbbreviation. This document specifies how to describe AUTOSAR Systems. |
| TimingAnalysis | TIMAY | Specification of Timing Analysis | DocumentAbbreviation. This document explains the Timing Analysis. |
| TimingExtensions | TIMEX | Specification of Timing Extensions | DocumentAbbreviation. This document specifies how to describe the timing of an AUTOSAR System. |
| TTCAN | TTCAN | Requirements on TTCAN | DocumentAbbreviation. This document specifies the additional TTCAN requirements for the CAN BSW stack. |
| UtilizationOfCrypto Services | UOC | Utilization Of Crypto Services | DocumentAbbreviation. This document explains the Utilization of Crypto Services. |
| VirtualFunctionalBus | VFB | Virtual Functional Bus | DocumentAbbreviation. This document describes the Virtual Functional Bus. |
| XMLSchema | XMLS | XML Schema | DocumentAbbreviation. This document describes the XML Schema. |
| XMLSchemaProduction Rules | XMLSPR | XML Schema Production Rules | DocumentAbbreviation. This document describes how a W3C XML schema specification compliant XML schema can be compiled out of the AUTOSAR meta-model. |
| Table 4.1: AUTOSAR Document Abbreviations for Trace Prefixes |
5 [NamespaceAbbreviations] AUTOSAR Name Spaces
| shortName | abbrName | longName | Classification, Description |
|---|---|---|---|
| com | com | Communication Management | NamespaceAbbreviation To be filled. |
| exec | exec | Execution Management | NamespaceAbbreviation To be filled. |
| not_available | not_available | Operating System | NamespaceAbbreviation To be filled. |
| per | per | Persistency | NamespaceAbbreviation To be filled. |
| diag | diag | Diagnostics | NamespaceAbbreviation To be filled. |
| log | log | Log and Trace | NamespaceAbbreviation To be filled. |
| time | time | Time Synchronisation | NamespaceAbbreviation To be filled. |
| rest | rest | REpresentational State Transfer | NamespaceAbbreviation To be filled. |
| ara | ara | Autosar API (in combination with a cluster name ex: ara::rest) | NamespaceAbbreviation To be filled. |
Table 5.1: AUTOSAR Name Spaces
References
[1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList
[2] XML Specification of Application Interfaces AUTOSAR_MOD_AISpecification
[3] Specification of ECU Configuration Parameters (XML) AUTOSAR_MOD_ECUConfigurationParameters
[4] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[5] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate
279 Application Interfaces User Guide
Abbreviations List
| Abbreviation | Meaning |
|---|---|
| .arxml | Autosar Extensible Markup Language File |
| AI Table | Application Interface Table |
| Bugzilla | Tool for change request management |
| CPU | Central Processing Unit |
| ECU | Electronic Control Unit |
| Excel | Microsoft spreadsheet-application |
| MS | Milestone |
| RTE | Run-Time Environment |
| SPEM | Software Process Engineering meta-model |
| SVN | Subversion (version control system) |
| SW-C | SoftwareComponent |
| SWC | SoftwareComponent |
| SW | Software |
| VB | Visual Basic |
| VFB | Virtual Function Bus |
| WP | Work package |
| XML | Extensible Markup Language |
| XSD | XML Schema Definition |
| HMI | Human Machine Interface |
10.1Standard documents
[1] Software Component Template
[2] Standardization Template
[3] AUTOSAR XML schema
[4] Generic Structure Template
[5] Model Persistence Rules for XML
[6] AI Specification
###10.2Auxiliary documents
[7]AUTOSAR Metamodel
[8]Application Interface table (AI Table)
[9]SW-C and System Modeling Guide
[10]AUTOSAR Methodology
[11]AUTOSAR domain explanation Body and Comfort
[12]AUTOSAR domain explanation Powertrain
[13]AUTOSAR domain explanation Chassis
[14]AUTOSAR domain explanation Occupant and Pedestrian Safety
[15]AUTOSAR domain explanation Multimedia, Telematics, Human Machine Interface.
[16]Unique Names for Documentation, Measurement and Calibration
[17]AUTOSAR Glossary
280 Explanation of Application Interfaces of the Chassis Do- main
2.2 Definitions
2.2.1 Methodology for Optimization of Interface Definition in the Chassis Domain
| term | definition |
|---|---|
| 2.2.1.1 Intended optimization | Harmonize the use of keywords in names & descriptions for: indication, state, request, mode, consolidate, target, confirmation, demand, command, information, .. and how to differentiate 'fault', 'failure', 'error', ' state' and 'mode‘ |
| 2.2.1.2 Overview of realization possibilities for „flow“ and “state” | |
| 2.2.1.2.1 Control Flow versus Signal Flow | Figure 1: Overview of Control Flow v. Signal flow (Chassis Domain) |
| 2.2.1.3 Definitions / Explanations | |
| 2.2.1.3.1 State | The present status of a system or entity: State (physics) (list of 8 definitions), particularly in thermodynamics, statistical physics, and dynamical systems and chaos theory. State (computer science), a unique configuration of information in a program or machine |
| 2.2.1.3.2 Modus | a “working mode“, set by commutation via diagnosis, driver or other Example : suspension => Comfort or Sport Modes. an adjustment of a procedure : can be sometimes considered as re- quest. Example: reset of TPMS function => it‘s more a request than a mode |
| 2.2.1.3.3 Mode | Kind, manner of s.th. 2.2.1.3.4 Indication. A signal that informs external systems of a relevant state of the sys- tem providing the signal. In general, the final destination of the sig- nal is expected to be the driver or other operator. |
| 2.2.1.3.5 Target | Set point, set value that an automatic control system, will aim to reach |
| 2.2.1.3.6 Request | Default wording for the target value of a controller 2.2.1.3.7 Meaningof“active“: it is on => leave as “active“ 2.2.1.3.8 Meaningof“intervention“: active intervention at the moment => changed to “intervention“ (to be used when a function can be on, but not intervening) Keyword: Intv |
| 2.2.1.3.9 Fault: | cause / reason. ISO/WD 26262-1: A fault is the cause of an error; it can either be systematic or random. NOTE Do not use: defect, mistake. |
| 2.2.1.3.10 Failure: | means doesn‘t work, but is not necessarily the reason. ISO/WD 26262-1: A failure is the inability (of a component or system) to perform a required function. |
| 2.2.1.3.11 Error: | temporary / permanent, same as failure. ISO/WD 26262-1: An error is the discrepancy between a computed, observed or measured value or condition and the specified correct value.. Decision: Use failure or fault instead of error based on the definition above Differentiation from State? => Failure is a state! |
The Object list for ACC is defined in the following table.
| Record Type Name | Long Name | Description |
|---|---|---|
| ObjData1 | ObjectData | Cluster of object attributes detected by surroundings sensors. This infor- mation is used e.g. for Adaptive Cruise Control (ACC), but is not limited to this use case only |
| ObjDataRlvForFolwCtrl1 | ObjDataRelevantForFollowControl | Cluster of relevant object attributes for Follow Control. |
ObjData1
| Name | Comment |
|---|---|
| DplLgt | Distance between the sensor and the object. |
| DplLat | Lateral distance between the center of the sensor and the object. |
| SpdLgtRel | Longitudinal speed difference between the ego vehicle and the object. |
| DynPpty | Status which indicates the dynamic property of the object (e.g. station- ary,moving, etc). Standing: has never been detected moving. Stopped: has been detect- ed moving, but is stationary now. Moving: object has absolute speed in any direction. The definition is made according to the earth-fixed axis system as defined in ISO 8855. |
| StOfObjMeasd | Status which indicates whether the object was measured in current cycle, or only tracked. |
| ObjId | Unique number for each object which has been tracked. The object keeps the same ID as long as it is output in the list. When an object dies, the ID can be reused for a new object. When a new object ap- pears, for one cycle the attribute "object is new" is set. ID=0 is reserved for "no object". |
| SpdLatRel | Lateral speed difference between the ego vehicle and the object. |
| ALgtRel | Longitudinal acceleration difference between the ego vehicle and the object. |
| ALatRel | Lateral acceleration difference between the ego vehicle and the object. |
| Width | Lateral length of the object. |
| Hei | Vertical length of the object from the ground. |
| Len | Longitudinal length of the object. |
| Orntn | Yaw angle of the object. Coordinate system according to ISO 8855. |
| ObjClassn | Class which indicates vehicle types (e.g. truck, passenger car, etc.) |
| DataQly | Quality of object data. This value decreases if the quality is poor (e.g. because of weather condi- tion, object reflectivity). Scaling will be dependent on type of sensor and signal processing algorithm, therefore requires application of parameters on re- ceiving function side. |
ObjDataRlvForFolwCtrl1
| Name | Comment |
|---|---|
| DplLgt | Distance between front edge of the ego vehi- cle and the object. |
| SpdLgtRel | Longitudinal speed difference between the ego vehicle and the object. |
| DynPpty | Status which indi- cates the dynamic property of the object (e.g. station- ary, moving, etc). Standing: has never been detected moving. Stopped: has been detect- ed moving, but is stationary now. Moving: object has abso- lute speed in any direction. The definition is made according to the earth-fixed axis system as defined in ISO 8855. |
| ObjId | Unique number for each object which has been tracked. The object keeps the same ID as long as it is output in the list. When an object dies, the ID can be reused for a new object. When a new object ap- pears, for one cycle the attribute "object is new" is set. ID=0 is reserved for "no object". |
| DplLat | Lateral distance between the center of the ego vehicle and the object. |
| SpdLatRel | Lateral speed differ- ence between the ego vehicle and the object. |
| ALgtRel | Longitudinal accel- eration difference between the ego vehicle and the object. |
| StOfObjMeasd | Status which indi- cates whether the object was measured in current cycle, or only tracked. |
| ObstrcnProblty | Probability that obstacle can not be over- run, or can not be driven over it. |
| LaneProblty | Probability of the potential target object to be located in the driving corri- dor, or predicted vehicle course.CutInProblty |
| CutInProblty | Probability of the potential target object for cutting in the driving corri- dor, or predicted vehicle course. |
| ObjRlvc | Measure of the plausibility as target object for Adaptive Cruise Control (ACC), which means that this measure increases if LaneProbability keeps high. |
| ObjRlvcUpprLim | Upper limit of Object Relevance. Above this limit the object becomes target object for Adaptive Cruise Control (ACC). |
| ObjRlvcLowrLim | Lower limit of Object Relevance. Below this limit the object is not the target object for Adaptive Cruise Control (ACC). |
| DstMaxForFolwCtrl | Maximum distance for the relevant object to become the target object for Follow Control. |
2.3 Glossary
| Abb. | Description |
|---|---|
| ABS | Antilock Braking System |
| ACC | Adaptive Cruise Control |
| BAS | Brake Assist |
| BRWS | Basic Rear Wheel Steering |
| BSTS | Basic Steering Torque Superposition |
| BSAS | Basic Steering Angle Superposition |
| CBC | Cornering Brake Control |
| CoG | Centre of Gravity |
| DAS | Driver Assistance System |
| DTC | Regulation of the Drag Torque |
| EBD | Electronic Brake Force Distribution |
| ECU | Electronic Control Unit |
| EPB | Electronic Parking Brake |
| ESC | Electronic Stability Control |
| FA | Front Axle |
| HDC | Hill Decent Control |
| HHC | Hill Hold Control |
| HMI | Human Machine Interface |
| HW | Hardware |
| NVH | Noise, Vibration, Harshness |
| OEM | Original Equipment Manufacturer |
| RA | Rear Axle |
| RSC | Roll Stability Control |
| SR | Situation Recognition |
| SSM | Stand Still Manager/Management |
| SW | Software |
| SW-C | Software Component |
| TCS | Traction Control System |
| VFB | Virtual Function Bus |
| VGR | Variable Gear Ratio |
| VLC | Vehicle Longitudinal Control |
| VM | Vehicle Model |
| YRC | Yaw Rate Control |
2.4 References
[1] Virtual Functional Bus AUTOSAR_EXP_VFB.pdf
[2] AUTOSAR_SoftwareComponentTemplate.pdf AUTOSAR_TPS_SoftwareComponentTemplate
[3] Table of Application Interfaces AUTOSAR_MOD_AITable.pdf
281 Explanation of Application Interfaces of the Powertrain En- gine Domain
3.2 Terminology–Torque within the Powertrain Domain
| Terms | Description |
|---|---|
| Sign definition for torque at clutch / torque at wheels | Positive value means that torque is transmitted from the engine to the drivetrain / from the powertrain to the wheels. Negative value means that torque is transmitted from the drivetrain to the engine / from the wheels to the powertrain. Zero means that no torque is transmitted between engine and drivetrain / between wheels and powertrain. |
| Ancillary torque losses | Ancillary torque losses are losses with influence on “torque at crankshaft reduced by ancillary losses” and “Torque at clutch” caused by e.g. alternator, airconditioning, power steering. |
| Consideration of the inertia in torque signals | Torque influence of inertia is not considered, viz. Torque effect caused by the inertia is not permitted to be considered additionally on engine side, viz. for an increasing engine speed, the indicated torque is not permitted to be in- creased by the torque which is necessary for the positive speed gradient, respectively for a decreasing engine speed, the indicated torque is not permitted to be de- creased by the torque which is necessary for the negative speed gradient. |
| Engine Clutch | For Hybrid Systems an additional clutch can be present between combustion engine and electric machine. |
2 References
[1] SW-C and System Modeling Guide AUTOSAR_TR_SW-CModelingGuide
[3] XML Specification of Application Interfaces AUTOSAR_MOD_AISpecification
[3b] Application Interfaces Examples AUTOSAR_MOD_AISpecificationExamples
[4] Explanation of Application Interfaces of the Chassis Domain AUTOSAR_EXP_AIChassisExplanation
[5] Unique Names for Documentation, Measurement and Calibration: Modeling and
Naming Aspects including Automatic Generation
AUTOSAR_TR_AIMeasurementCalibrationDiagnostics
[6] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[7] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[8] ANTLR parser generator V3 http://www.antlr.org
[9] Virtual Function Bus AUTOSAR_EXP_VFB
[10] Glossary AUTOSAR_TR_Glossary
[11] AIDesignPatternCatalogue AUTOSAR_TR_AIDesignPatternCatalogue
282 Application Design Patterns Catalogue
no abbreviations
References
[1] ANTLR parser generator V3
[2] Standardization Template AUTOSAR_TPS_StandardizationTemplate
[3] SW-C and System Modeling Guide AUTOSAR_TR_SWCModelingGuide
[4] XML Specification of Application Interfaces AUTOSAR_MOD_AISpecification
[5] Main Requirements AUTOSAR_RS_Main
[6] Architectural Pattern http://en.wikipedia.org/wiki/Architectural_pattern
[7] Software Design Pattern http://en.wikipedia.org/wiki/Software_design_pattern
[8] Design Pattern http://en.wikipedia.org/wiki/Design_Pattern
[9] Anti Pattern http://en.wikipedia.org/wiki/Anti-pattern
[10] Software Design Pattern Template http://c2.com/cgi/wiki?DesignPatternTemplate
[11] Secure Design Patterns http://www.sei.cmu.edu/reports/09tr010.pdf
[12] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate
[13] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture
283 Explanation of Application Interfaces of the HMI, Multimedia and Telematics Domain
2 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| HMI | Human Machine Interface |
| LED | Light Emitting Diode |
| MM/T/HMI | Multimedia / Telematics / Human Machine Interface |
| PDC | Park Distance Control |
| SWC | Software Component |
| UI | User Interface |
7 References
[1] Explanation of Application Interfaces of the Body and Comfort Domain AUTOSAR_EXP_AIBodyAndComfort.pdf
284 Explanation of Application Interfaces of the Body and Comfort Domain
2.2 Abbreviations
| Abb. | Meanning |
|---|---|
| ATWS | Anti-Theft Warning System |
| BBS | Battery Backed Sensor |
| CAN | Controller Area Network |
| CHLH | Coming Home/Leaving Home |
| CL | Central Locking |
| ECM | Engine Control Module |
| GBS | Glass Brake Sensor |
| HMI | Human Machine Interface |
| ID | Identity |
| IMMO | Immobilizer |
| INCL | Inclination sensor |
| ISC | Interior Scanner |
| LED | Light-Emitting Diode |
| LHFD | Left Hand Front Door |
| LHRD | Left Hand Rear Door |
| OEM | Original Equipment Manufacturer |
| PASE | Passive Entry |
| PATS | Passive Alarm Theft Sensor |
| RF | Radio Frequency |
| RHFD | Right Hand Front Door |
| RHRD | Right Hand Rear Door |
| RKE | Remote Keyless Entry |
| HVAC | Heating, Ventilation and Air Conditioning |
| DC | Defrost Control |
| SC | Seat Climatization |
| SA | Seat Adjustment |
| SW-C | Software Component |
285 Requirements on SW-C and System Modeling
3 Acronyms and Abbreviations
| Abb. | Meanning |
|---|---|
| AR | AUTOSAR |
| ECU | Electronic Control Unit |
| HMI | Human Machine Interface |
| MISRA | Motor Industry Software Reliability Association |
| RTE | Real Time Environment |
| SW-C | Software Component |
| WP | Work Package |
1.1 Terminology
| term | description |
|---|---|
| Identifiable | any model element that can have a set of attributes. Please refer to the AUTOSAR Meta Model for further and detailed explanation of this term (“Instances of this class can be referred to by their identifier (while adhering to namespace borders))”. Use this term instead of “element” , “data name”, etc. unless a requirement is applicable to a specific Meta Model Identifiable such as Port, Data Type, etc.. |
| ARElement | As defined into AUTOSAR Meta Model: “An element that can be defined stand-alone, i.e. without being part of another element (except for packages of course). Opposed to packages, the elements are closed sets, i.e. that in a file based description, one ARElement needs to be described completely and cannot be extended or completed by another file”. |
| ARPackage | As defined into AUTOSAR Meta Model: “AUTOSAR package, allowing to create top level packages to structure the contained ARElements. ARPackages are open sets, which means that in a file based description system, multiple files can be used to partially describe the contents of a package. This is an extended version of MSR's SW-SYSTEM”. |
286 Unique Names for Documentation, Measurement and Cali- bration: Modeling and Naming Aspects including Automatic Generation
3.3 AcronymsandAbbreviations
| Abb. | Explanation |
|---|---|
| AI | Application interfaces |
| component | components are the SwComponentPrototypes of a Composi- tionSwComponentType |
| cp-path | SwComponentPrototype-Path, see chapter 6.3 |
| dataElement or data element | Element of a port interface of type AutosarDataPrototype, dataElements are VariableDataPrototypes of a PortInterface |
| data prototype | An AutosarDataPrototype like VariableDataPrototype or Pa- rameterDataPrototype etc. |
| Descriptor | Descriptor: Short form for “ShortName FlatIn- stanceDesriptor in a FlatMap of target element x of element type X” |
| Element | Element might be a prototype element like SwComponentPro- totype, AutosarDataPrototype etc. or an ARElement |
| MCD | Measurement, Calibration and Diagnostic |
| name | Used as short form for ShortName if not mentioned otherwise |
| parameter | Element of a ParameterInterface of type ParameterDataProto- type, parameters are the ParameterDataPrototypes of a Port- Interface |
| pb-path | PortPrototypeBlueprint-Path, see chapter 6.3 |
| P/L-list | List with abbreviations for physical and logical types. See chapter 17 |
| port | port prototype or port prototype blueprint – depending on con- text |
| SW | Software |
| SW-C | Software Component |
| virtual name space | In this document we use the term “virtual name space for {el- ement} or {prototype}” to denote that the names of the corresponding elements are unique within the corresponding ARPackage, recursively. See chapter 6.6 |
References
[1]SW-C and System Modeling Guide AUTOSAR_TR_SWCModelingGuide.pdf
[2]Table of Application Interfaces AUTOSAR_MOD_AITable.zip
[3]XML Specification of Application Interfaces AUTOSAR_MOD_AISpecification.zip
[4]System Template AUTOSAR_TPS_SystemTemplate.pdf
[5]Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[6]Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
[7]Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate.pdf
[8]Specification of BSW Module Description Template AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
[9]Specification of RTE AUTOSAR_SWS_RTE.pdf
[10] ASAM MCD-2 MC (ASAP2)
www.asam.net
[11] Explanation of Application Interfaces of the Powertrain Domain AUTOSAR_EXP_AIPowertrain.pdf
[12] AUTOSAR Predefined Names AUTOSAR_TR_PredefinedNames.pdf
287 Explanation of Application Interfaces of Occupant and Pe- destrian Safety Systems Do- main
1.1 References
[1] AUTOSAR Table of Application Interface AUTOSAR_MOD_AITable
[2] AUTOSAR_TPS_GenericStructureTemplate.pdf chapter 12
2 Description of Terms and Concepts 2.1 Listoftermsandabbreviations
| Term | Description |
|---|---|
| AB | Airbag |
| AI | Application Interface |
| COOP | Critical Out of Position |
| eCall | Emergency Call |
| HMI | Human Machine Interface |
| IF | Interface |
| OD | Occupant Detection |
| OOP | Out Of Position |
| OPS | Occupant and Pedestrian Safety |
| OPSS | OPS Systems |
| ORA | Occupant Restraint Activation |
| PCD | Pedestrian Crash Detection |
| PPA | Pedestrian Protection Actuator Activation |
| SBR | Seat Belt Reminder |
| SRS | Safety Restraint System |
| SWC | Software Component |
| SWCo | Software Composition |
| VCD | Vehicle Crash Detection |
| ROD | Rollover Crash Detection |
| POD | Pitchover Crash Detection |
| Antisubmarine | Term used in restraint systems for automotive applications related to an AB that upon deployment prevents a front row passenger from diving below the dashboard by lifting the person’s lower body. Thus, the person is brougth into a better position relative to the main Front AB |
| VH | Variant Handling concept |
| SP | Sensor Pool |
| AP | Actuator Pool |
| CS | Crash Status |
| ACC | Adaptive Cruise Controll |
| RSM | Restraint System Monitoring |
| VCP | Vehicle Crash Prediction |
| PCP | Pedestrian Crash Prediction |
| OPC | Occupant Pre Conditioning |
| RSP | Restraint System Pre conditioning |
| PPP | Pedestrian Protection system Pre conditioning |
| PCI | Post Crash Information |
288 SW-C and System Modeling Guide
##3.2 Acronyms and Abbreviations
| Term | Description |
|---|---|
| API | Application Programming Interface |
| AR | AUTOSAR |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| HMI | Human Machine Interface |
| MISRA | Motor Industry Software Reliability Association |
| RTE | Real Time Environment |
| SW-C | Software Component |
| WP | Work Package |
| XML | eXtensible Markup Language |
1 References
[1] Template UML Profile and Modeling Guide AUTOSAR_TemplateModelingGuide.pdf
[2] Specification of RTE Software AUTOSAR_SWS_RTE.pdf
[3] Software Component Template AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[4] AUTOSAR Model Persistence Rules for XML AUTOSAR_TR_XMLPersistenceRules.pdf
[5] MISRA-C: 2004. Guidelines for the use of the C language in critical systems.
[6] Autosar Methodology AUTOSAR_TR_Methodology.pdf
[7] Generic Structure Template AUTOSAR_TPS_GenericStructureTemplate.pdf
[8] Requirements on Runtime Environment AUTOSAR_SRS_RTE.pdf
[9] Standardization Template AUTOSAR_TPS_StandardizationTemplate.pdf
[10] Requirements for Software Component Modeling AUTOSAR_RS_SWCModeling.pdf
[11] AUTOSAR System Template AUTOSAR_TPS_SystemTemplate.pdf
289 Testability Protocol and Service Primitives
2 Acronyms and Abbreviations
| Abb. | Description |
|---|---|
| IUT | Implementation Under Test that is located inside the DUT |
| SP | Service Primitive (for triggering actions or observations on the IUT) |
| UT | Upper Tester (Part of TS that contains the SPs located within the DUT on top of the IUT) |
| TSB | Test Stub (same as UT) |
| TM | Testability Module (same a UT) |
| LT | Lower Tester (Part of TS located outside the DUT on bottom of the IUT) |
| UC | Upper Test Channel (channel between UT and IUT within the DUT) |
| LC | Lower Test Channel (channel between LT and IUT that can be accessed from outside the DUT) |
| CC | Control Channel (The channel between TS and UP used to call SPs that can be accessed from outside the DUT) |
| TS | Test System (The system that contains the test cases and control for UT and LT) |
| EVB | Event Bit (Protocol field that is set in case of an event) |
| GID | Group Identifier (Protocol field: determines a group of services) |
| PID | Service Primitive Identifier (Protocol field: determines a service) |
| TID | Type Identifier (Protocol field: to determine the message type) |
| RID | Result Identifier (Protocol field: similar to a Return Error Code) |
| DUT | Device Under Test (contains the UT and IUT that is tested) |
3.1 Input documents
[1] AUTOSAR SOME/IP Protocol Specification AUTOSAR_PRS_SomeIPProtocol.pdf
[2] AUTOSAR Standard Datatypes AUTOSAR_SWS_StandardTypes.pdf
3.2 RelatedStandardsandNorms
[3] IETF RFC 793 “TRANSMISSION CONTROL PROTOCOL”
290 Acceptance Test Specification of Communication via bus
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| NM | Network Management |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| RfC | Request for Change |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
| LdCom | Large Data COM |
291 Acceptance Test Specification of Communication on FlexRay bus
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| NM | Network Management |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| RfC | Request for Change |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
2.1 Inputdocuments
[1] Specification of Module Efficient COM for Large Data AUTOSAR_SWS_LargeDataCOM.pdf
[2] Specification of RTE AUTOSAR_SWS_RTE.pdf
[3] Specification of FlexRay ISO Transport Layer AUTOSAR_SWS_FlexRayISOTransportLayer.pdf
[4] Specification of FlexRay Interface AUTOSAR_SWS_FlexRayInterface.pdf
[5] Requirements on Runtime Environment AUTOSAR_SRS_RTE.pdf
[6] Requirements on Communication AUTOSAR_SRS_COM.pdf
[7] System Template AUTOSAR_TPS_SystemTemplate.pdf
[8] Requirements on Acceptance Tests AUTOSAR_ATR_Requirements.pdf
[9] Requirements on AUTOSAR Features AUTOSAR_RS_Features.pdf
292 Acceptance Test Specification of IPv4 communication
1Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| ECU | Electronic Control Unit |
| IUT | Implementation Under Test |
| LT | Lower Tester |
| PDU | Protocol Data Unit |
| SP | Service Primitive |
| TS | Test System |
| UDP | User Datagram Protocol (according to IETF RFC 768) |
| UT | Upper Tester |
| IPv4 | Internet Protocol version 4 |
| ICMP | Internet Control Message Protocol |
| TTL | Time To Live |
| TOS | Type Of Service |
| MTU | Maximum Transmission Unit |
| EMTU_S | Effective MTU for sending – This is the maximum IP datagram size that may be sent, |
| ＜LTIface-m＞ | m-th Interface of LT |
| ＜IUTIface-n＞ | n-th Interface of IUT |
| ＜IUTIface-n-IP＞ | IP address of n-th Interface of IUT |
| ＜LTIface-m-IP＞ | IP address of m-th Interface of LT |
2.1 Inputdocuments
[1] AUTOSAR Specification of TCP/IP Stack AUTOSAR_SWS_TcpIp.pdf
[2] AUTOSAR System Template AUTOSAR_TPS_SystemTemplate.pdf
[3] AUTOSAR SRS Ethernet AUTOSAR_SRS_Ethernet.pdf
[4] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] Requirements on Acceptance Tests AUTOSAR_ATR_Requirements_Eth.doc
2.2 Relatedstandardsandnorms
[7] IETF RFC 791
http://tools.ietf.org/html/rfc791
[8] IETF RFC 1122
http://tools.ietf.org/html/rfc1122
2.3 Testabilityprotocoldocument
[9] Testability Protocol and Service Primitives AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives.pdf
Acceptance Test Specification of IPv4 communication AUTOSAR TC Release 1.2.0
293 Acceptance Test Specification of Communication on CAN bus
1 Acronyms and Abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| NM | Network Management |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| RfC | Request for Change |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
2.1 Inputdocuments
[1] Specification of Module Efficient COM for Large Data AUTOSAR_SWS_LargeDataCOM.pdf
[2] Specification of RTE AUTOSAR_SWS_RTE.pdf
[3] Specification of CAN Transport Layer AUTOSAR_SWS_CANTransportLayer.pdf
[4] Requirements on Runtime Environment AUTOSAR_SRS_RTE.pdf
[5] Requirements on Communication AUTOSAR_SRS_COM.pdf
[6] System Template AUTOSAR_TPS_SystemTemplate.pdf
[7] Requirements on Acceptance Tests AUTOSAR_ATR_Requirements.pdf
294 Acceptance Test Specification of Communication on LIN bus
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT1 | Acceptance Test |
| ECU | Electronic Control Unit |
| LIN | Local Interconnect Network |
| LT | Lower Tester |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
295 Acceptance Test Specification of Diagnostic Services
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| ICC1 | Implementation Conformance Class 1 (whole BSW & RTE) |
| ICC2 | Implementation Conformance Class 2 (functional cluster of BSW) |
| ICC3 | Implementation Conformance Class 3 (individual BSW modules) |
| IUT | Implementation under test |
| LT | Lower Tester |
| NM | Network Management |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| RfC | Request for Change |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
296 Acceptance Test Specification of Ecu Mode Management
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| NM | Network Management |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| RfC | Request for Change |
| Rx | Reception |
| SUT | System Under Test |
| DUT | Device Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
297 Acceptance Test Specification of UDP communication
1 Acronyms and Abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| ECU | Electronic Control Unit |
| IUT | Implementation Under Test |
| LT | Lower Tester |
| PDU | Protocol Data Unit |
| SP | Service Primitive |
| TS | Test System |
| UDP | User Datagram Protocol (according to IETF RFC 768) |
| UT | Upper Tester |
| IP | Internet Protocol |
| ICMP | Internet Control Message Protocol |
| TTL | Time To Live |
| TOS | Type Of Service |
| MTU | Maximum Transmission Unit |
| ＜LTIface-m＞ | m-th Interface of LT |
| ＜IUTIface-n＞ | n-th Interface of IUT |
| ＜IUTIface-n-IP＞ | IP address of n-th Interface of IUT |
| ＜LTIface-m-IP＞ | IP address of m-th Interface of LT |
| SCG | Static Configuration Groups |
| allSystemMCastA ddr | Refers to the multicast address of All Systems on a Subnet |
| BroadCastAddr | Refers to the broadcast address of a EthIfCtrl |
2
###Related Documentation Input documents
[1] AUTOSAR Specification of TCP/IP Stack AUTOSAR_SWS_TcpIp.pdf
[2] AUTOSAR System Template AUTOSAR_TPS_SystemTemplate.pdf
[3] AUTOSAR SRS Ethernet AUTOSAR_SRS_Ethernet.pdf
[4] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] Requirements on AUTOSAR Features AUTOSAR_RS_Features.pdf
###Related standards and norms
[7] IETF RFC 768
http://tools.ietf.org/html/rfc768
[8] IETF RFC 1122
http://tools.ietf.org/html/rfc1122
Testability Protocol and Service Primitives
[9] Testability Protocol and Service Primitives AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives.pdf
298 Acceptance Test Specification of Memory Stack
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| API | Application Programming Interface |
| AT | Acceptance Test |
| BSW | Basic Software |
| CAN | Controller Area Network |
| DCM | Diagnostic Communication Manager |
| DEM | Diagnostic Event Manager |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| NM | Network Management |
| NvM | Nonvolatile RAM Manager |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| PIM | Per-Instance Memory |
| RfC | Request for Change |
| RAM | Random Access Memory |
| ROM | Read-only Memory |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
299 Acceptance Test Specification of RTE
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| NM | Network Management |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| RfC | Request for Change |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
300 Acceptance Test Specification of Communication Management
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| NM | Network Management |
| PCO | Point of Control and Observation |
| PDU | Protocol Data Unit |
| RfC | Request for Change |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
301 Acceptance Test Specification of TCP communication
Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| ECU | Electronic Control Unit |
| IUT | Implementation Under Test |
| LT | Lower Tester |
| PDU | Protocol Data Unit |
| SP | Service Primitive |
| TS | Test System |
| UDP | User Datagram Protocol (according to IETF RFC 768) |
| TCP | Transmission Control Protocol |
| UT | Upper Tester |
| IP | Internet Protocol |
| ICMP | Internet Control Message Protocol |
| TTL | Time To Live |
| TOS | Type Of Service |
| MTU | Maximum Transmission Unit |
| URG | Flag Urgent Pointer field significant in TCP Header |
| ACK | Flag Acknowledgment field significant in TCP Header |
| PSH | Flag Push Function in TCP Header |
| RST | Flag Reset the connection in TCP Header |
| SYN | Flag Synchronize sequence numbers in TCP Header |
| FIN | Flag No more data from sender in TCP Header |
| TCB | Transmission Control Block |
| MSL | Maximum Segment Lifetime |
| ＜LTIface-m＞ | m-th Interface of LT |
| ＜IUTIface-n＞ | n-th Interface of IUT |
| ＜IUTIface-n-IP＞ | IP address of n-th Interface of IUT |
| ＜LTIface-m-IP＞ | IP address of m-th Interface of LT |
1.1 Inputdocuments
[1] AUTOSAR Specification of TCP/IP Stack AUTOSAR_SWS_TcpIp.pdf
[2] AUTOSAR System Template AUTOSAR_TPS_SystemTemplate.pdf
[3] AUTOSAR SRS Ethernet AUTOSAR_SRS_Ethernet.pdf
[4] AUTOSAR General Specification for Basic Software Modules AUTOSAR_SWS_BSWGeneral.pdf
[5] Specification of ECU Configuration AUTOSAR_TPS_ECUConfiguration.pdf
[6] Feature Specification of the Acceptance Tests AUTOSAR_ATR_Features_Eth.doc
1.2 Relatedstandardsandnorms
[7] IETF RFC 793
http://tools.ietf.org/html/rfc793
[8] IETF RFC 1122
http://tools.ietf.org/html/rfc1122
1.3 TestabilityProtocolandServicePrimitives
[9] Testability Protocol and Service Primitives AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives.pdf
302 Acceptance Test Specification of Communication CANFD
1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| ECU | Electronic Control Unit |
| IUT | Implementation Under Test |
| LT | Lower Tester |
| PDU | Protocol Data Unit |
| TS | Test System |
| UT | Upper Tester |
| CAN | Controller Area Network |
| NM | Network Management |
| PCO | Point of Control and Observation |
| Tx | Transmission |
| Rx | Reception |
| SWC | Software Component |
| SUT | System Under Test |
| CANFD | CAN with Flexible Data Rate |
| DUT | Device Under Test |
| SUT | System Under Test |
303 Acceptance Test Specification of Global Time Synchronization
##1 Acronyms and abbreviations
| Abb. | Description |
|---|---|
| AT | Acceptance Test |
| CAN | Controller Area Network |
| ECU | Electronic Control Unit |
| LT | Lower Tester |
| PCO | Point of Control and Observation |
| Rx | Reception |
| SUT | System Under Test |
| SWC | Software Component |
| TCP | Test Coordination Procedures |
| Tx | Transmission |
| UT | Upper Tester |
2 Related Documentation 2.1 Inputdocuments
[1] Specification of Synchronized Time-Base Manager AUTOSAR_SWS_SynchronizedTimeBaseManager.pdf
[2] Specification of Time Synchronization over CAN AUTOSAR_SWS_TimeSyncOverCAN.pdf
[3] Specification of Time Synchronization over FlexRay AUTOSAR_SWS_TimeSyncOverFlexRay.pdf
[4] Specification of Operating System AUTOSAR_SWS_OS.pdf
[5] Specification of Basic Software Mode Manager AUTOSAR_SWS_BSWModeManager.pdf
[6] Specification of CAN Interface AUTOSAR_SWS_CANInterface.pdf
[7] Specification of FlexRay Interface AUTOSAR_SWS_FlexRayInterface.pdf
[8] Specification of RTE AUTOSAR_SWS_RTE.pdf
[9] Requirements on Synchronized Time-Base Manager AUTOSAR_SRS_SynchronizedTimeBaseManager.pdf
[10] Requirements on Acceptance Tests AUTOSAR_ATR_Requirements.pdf
[11] Requirements on AUTOSAR Features AUTOSAR_RS_Features.pdf
[12] System Template AUTOSAR_TPS_SystemTemplate.pdf
関連資料
' @kazuo_reve 私が効果を確認した「小川メソッド」
https://qiita.com/kazuo_reve/items/a3ea1d9171deeccc04da
' @kazuo_reve 新人の方によく展開している有益な情報
https://qiita.com/kazuo_reve/items/d1a3f0ee48e24bba38f1
' @kazuo_reve Vモデルについて勘違いしていたと思ったこと
https://qiita.com/kazuo_reve/items/46fddb094563bd9b2e1e
自己記事一覧
Qiitaで逆リンクを表示しなくなったような気がする。時々、スマフォで表示するとあらわっることがあり、完全に削除したのではなさそう。
４月以降、せっせとリンクリストを作り、統計を取って確率を説明しようとしている。
2025年２月末を目標にしている。
Qiitaの記事に３段階または５段階で到達するための方法
https://qiita.com/kaizen_nagoya/items/6e9298296852325adc5e
プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945
逆も真：社会人が最初に確かめるとよいこと。OSEK(69)、Ethernet(59)
https://qiita.com/kaizen_nagoya/items/39afe4a728a31b903ddc
「何を」よりも「誰を」。１０年後のために今見習いたい人たち
https://qiita.com/kaizen_nagoya/items/8045978b16eb49d572b2
物理記事 上位100
https://qiita.com/kaizen_nagoya/items/66e90fe31fbe3facc6ff
量子(0) 計算機, 量子力学
https://qiita.com/kaizen_nagoya/items/1cd954cb0eed92879fd4
数学関連記事１００
https://qiita.com/kaizen_nagoya/items/d8dadb49a6397e854c6d
図(0) state, sequence and timing. UML and お絵描き
https://qiita.com/kaizen_nagoya/items/60440a882146aeee9e8f
品質一覧
https://qiita.com/kaizen_nagoya/items/2b99b8e9db6d94b2e971
言語・文学記事 １００
https://qiita.com/kaizen_nagoya/items/42d58d5ef7fb53c407d6
医工連携関連記事一覧
https://qiita.com/kaizen_nagoya/items/6ab51c12ba51bc260a82
自動車 記事 １００
https://qiita.com/kaizen_nagoya/items/f7f0b9ab36569ad409c5
通信記事１００
https://qiita.com/kaizen_nagoya/items/1d67de5e1cd207b05ef7
日本語（０）一欄
https://qiita.com/kaizen_nagoya/items/7498dcfa3a9ba7fd1e68
英語(0) 一覧
https://qiita.com/kaizen_nagoya/items/680e3f5cbf9430486c7d
転職(0)一覧
https://qiita.com/kaizen_nagoya/items/f77520d378d33451d6fe
仮説（0）一覧（目標100現在40）
https://qiita.com/kaizen_nagoya/items/f000506fe1837b3590df
音楽 一覧(0)
https://qiita.com/kaizen_nagoya/items/b6e5f42bbfe3bbe40f5d
「@kazuo_reve 新人の方によく展開している有益な情報」確認一覧
https://qiita.com/kaizen_nagoya/items/b9380888d1e5a042646b
Qiita(0)Qiita関連記事一覧（自分）
https://qiita.com/kaizen_nagoya/items/58db5fbf036b28e9dfa6
鉄道（０）鉄道のシステム考察はてっちゃんがてつだってくれる
https://qiita.com/kaizen_nagoya/items/26bda595f341a27901a0
安全（0）安全工学シンポジウムに向けて: 21
https://qiita.com/kaizen_nagoya/items/c5d78f3def8195cb2409
一覧の一覧( The directory of directories of mine.) Qiita(100)
https://qiita.com/kaizen_nagoya/items/7eb0e006543886138f39
Ethernet 記事一覧 Ethernet(0)
https://qiita.com/kaizen_nagoya/items/88d35e99f74aefc98794
Wireshark 一覧 wireshark(0)、Ethernet(48)
https://qiita.com/kaizen_nagoya/items/fbed841f61875c4731d0
線網（Wi-Fi）空中線(antenna)(0) 記事一覧(118/300目標)
https://qiita.com/kaizen_nagoya/items/5e5464ac2b24bd4cd001
OSEK OS設計の基礎 OSEK(100)
https://qiita.com/kaizen_nagoya/items/7528a22a14242d2d58a3
Error一覧 error(0)
https://qiita.com/kaizen_nagoya/items/48b6cbc8d68eae2c42b8
C++ Support(0)
https://qiita.com/kaizen_nagoya/items/8720d26f762369a80514
Coding(0) Rules, C, Secure, MISRA and so on
https://qiita.com/kaizen_nagoya/items/400725644a8a0e90fbb0
coding (101) 一覧を作成し始めた。omake:最近のQiitaで表示しない5つの事象
https://qiita.com/kaizen_nagoya/items/20667f09f19598aedb68
プログラマによる、プログラマのための、統計(0)と確率のプログラミングとその後
https://qiita.com/kaizen_nagoya/items/6e9897eb641268766909
なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2
言語処理100本ノックをdockerで。python覚えるのに最適。:10+12
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4
プログラムちょい替え（0）一覧:4件
https://qiita.com/kaizen_nagoya/items/296d87ef4bfd516bc394
Python(0)記事をまとめたい。
https://qiita.com/kaizen_nagoya/items/088c57d70ab6904ebb53
官公庁・学校・公的団体（NPOを含む）システムの課題、官（０）
https://qiita.com/kaizen_nagoya/items/04ee6eaf7ec13d3af4c3
「はじめての」シリーズ ベクタージャパン
https://qiita.com/kaizen_nagoya/items/2e41634f6e21a3cf74eb
AUTOSAR(0)Qiita記事一覧, OSEK(75)
https://qiita.com/kaizen_nagoya/items/89c07961b59a8754c869
プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945
LaTeX(0) 一覧
https://qiita.com/kaizen_nagoya/items/e3f7dafacab58c499792
自動制御、制御工学一覧（０）
https://qiita.com/kaizen_nagoya/items/7767a4e19a6ae1479e6b
Rust(0) 一覧
https://qiita.com/kaizen_nagoya/items/5e8bb080ba6ca0281927
100以上いいねをいただいた記事16選
https://qiita.com/kaizen_nagoya/items/f8d958d9084ffbd15d2a
小川清最終講義、最終講義（再）計画, Ethernet(100) 英語(100) 安全(100)
https://qiita.com/kaizen_nagoya/items/e2df642e3951e35e6a53
参考資料
物理記事 上位100
https://qiita.com/kaizen_nagoya/items/66e90fe31fbe3facc6ff
数学関連記事１００
https://qiita.com/kaizen_nagoya/items/d8dadb49a6397e854c6d
言語・文学記事 １００
https://qiita.com/kaizen_nagoya/items/42d58d5ef7fb53c407d6
医工連携関連記事一覧
https://qiita.com/kaizen_nagoya/items/6ab51c12ba51bc260a82
通信記事１００
https://qiita.com/kaizen_nagoya/items/1d67de5e1cd207b05ef7
自動車 記事 １００
https://qiita.com/kaizen_nagoya/items/f7f0b9ab36569ad409c5
OSEK 記事で views 100,000を目指して OSEK(8)
https://qiita.com/kaizen_nagoya/items/ff45ee55566eeff5f62e
無線網（Wi-Fi）空中線(antenna)(0) 記事https://qiita.com/kaizen_nagoya/items/5e5464ac2b24bd4cd001
なぜdockerで機械学習するか 書籍・ソース一覧作成中
https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2
仮説（0）一覧
https://qiita.com/kaizen_nagoya/items/f000506fe1837b3590df
安全（0）安全工学シンポジウムに向けて: 21
https://qiita.com/kaizen_nagoya/items/c5d78f3def8195cb2409
日本語（０）一欄
https://qiita.com/kaizen_nagoya/items/7498dcfa3a9ba7fd1e68
英語(0) 一覧
https://qiita.com/kaizen_nagoya/items/680e3f5cbf9430486c7d
転職(0)一覧
https://qiita.com/kaizen_nagoya/items/f77520d378d33451d6fe
一覧の一覧( The directory of directories of mine.) Qiita(100)
https://qiita.com/kaizen_nagoya/items/7eb0e006543886138f39
プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945
LaTeX(0) 一覧
https://qiita.com/kaizen_nagoya/items/e3f7dafacab58c499792
自動制御、制御工学一覧（０）
https://qiita.com/kaizen_nagoya/items/7767a4e19a6ae1479e6b
Rust(0) 一覧
https://qiita.com/kaizen_nagoya/items/5e8bb080ba6ca0281927
小川清最終講義、小川清最終講義（再）計画, Ethernet(100) 英語(100) 安全(100)
https://qiita.com/kaizen_nagoya/items/e2df642e3951e35e6a53
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on the individual's experience. It has nothing to do with the organization or business to which I currently belong.