AUTOSAR_RS_Main
Disclaimer
This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification.
The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights.
This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only.
For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher.
The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.
Advice for users
AUTOSAR specifications may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary technical solutions, devices, processes or software).
Any such exemplary items are contained in the specifications for illustration purposes only, and they themselves are not part of the AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance of products actually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under the same rules as applicable to the AUTOSAR Standard.
Table of Content
1Scope of the document (5)
2How to read this document (6)
2.1Conventions used (6)
2.2Acronyms and Abbreviations (6)
3Requirements Tracing (7)
4Requirements Specification (8)
4.1Architecture (8)
4.2Basic Software and Runtime Environment (11)
4.3Methodology (15)
4.4Non-functional Requirements (20)
4.5Acceptance Testing (22)
4.6Processes (23)
5References (25)
1 Scope of the document
Each partner has committed to the overall project objectives (PO) of AUTOSAR. The objectives are listed in the AUTOSAR Standard Info Pack V3.3 or in subsequent documents. AUTOSAR Standard Info Pack is an official communication paper of development partnership.
These objectives are not directly usable and have to be refined in order to generate the specific technical requirements. For this purpose, the AUTOSAR Main Requirements are established as a fundamental base to derive these specific requirements.
The goal of this document is to define the main requirements of AUTOSAR including its link to the AUTOSAR objectives.
The term AUTOSAR is used as a synonym of the development partnership and the technical product AUTomotive Open System ARchitecture.
2 How to read this document
Each req uirement has its unique identifier starting with the prefix “RS_Main_” (for “Main Requirement”). For any review annotations, remarks or questions, please refer to this unique ID rather than chapter or page numbers!
2.1 Conventions used
?The representation of requirements in AUTOSAR documents follows the table specified in [TPS_STDT_00078]. In requirements, the following specific semantics are used (taken from Request for Comment RFC 2119 from the Internet Engineering Task Force IETF)
?The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Note that the requirement level of the document in which they are used modifies the force of these words.
?MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
?MUST NOT: This phrase, or the phrase …SHALL NOT“, means that the definition is an absolute prohibition of the specification.
?SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
?SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
?MAY: This word, or the adjective …OPTIONAL“, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation, which does not include a particular option, MUST be prepared to interoperate with another implementation, which does include the option, though perhaps with reduced functionality. In the same vein an implementation, which does include a particular option, MUST be prepared to interoperate with another implementation, which does not include the option (except, of course, for the feature the option provides.)
2.2 Acronyms and Abbreviations
All acronyms and abbreviations used throughout this document are included in the official AUTOSAR glossary [Glossary]. For respective explanation please see there.
3 Requirements Tracing
The following table references the requirements specified in [RS_ProjectObjectives] and links to the fulfilments of these.
4 Requirements Specification
4.1 Architecture
4.1.1 [RS_Main_00400] AUTOSAR shall provide a layered software
architecture
?
?(RS_PO_00001, RS_PO_00002)
4.1.2 [RS_Main_00130] AUTOSAR shall provide an abstraction from
hardware
?
?(RS_PO_00001, RS_PO_00002)
4.1.3 [RS_Main_00150] AUTOSAR shall support the reallocation of Software
Components
?
?(RS_PO_00001, RS_PO_00002)
4.1.4 [RS_Main_00060] AUTOSAR shall provide a standardized software
interface for communication between Software Components
?
?(RS_PO_00001, RS_PO_00002, RS_PO_00007)
4.1.5 [RS_Main_00140] AUTOSAR shall provide network independent
communication mechanisms for applications
?
?(RS_PO_00001, RS_PO_00002)
4.1.6 [RS_Main_00410] AUTOSAR shall provide specifications for routines
commonly used by Software Components to support sharing and
optimization
?
?(RS_PO_00001, RS_PO_00003, RS_PO_00004)
4.1.7 [RS_Main_00190] AUTOSAR shall support interoperability with non-
AUTOSAR software on the same ECU
?
?(RS_PO_00003)
4.1.8 [RS_Main_00210] AUTOSAR shall support interoperability with non-
AUTOSAR ECUs in a network
?
?(RS_PO_00003)
4.1.9 [RS_Main_00330] AUTOSAR shall support the principle of information
hiding
?
?(RS_PO_00007)
4.1.10 [RS_Main_00230] AUTOSAR shall support network topologies
including gateways
?
?(RS_PO_00002)
4.2 Basic Software and Runtime Environment
4.2.1 [RS_Main_00100] AUTOSAR shall provide standardized basic software ?
?(RS_PO_00001, RS_PO_00007)
4.2.2 [RS_Main_00420] AUTOSAR shall use established software standards
and consolidate de-facto standards for basic software functionality ?
?(RS_PO_00007,RS_PO_00009)
4.2.3 [RS_Main_00430] AUTOSAR shall support established automotive
communication standards
?
?(RS_PO_00004,RS_PO_00009)
4.2.4 [RS_Main_00435] AUTOSAR shall support automotive
microcontrollers
?
?(RS_PO_00004)
4.2.5 [RS_Main_00440] AUTOSAR shall standardize access to non-volatile
memory
?
?(RS_PO_00001, RS_PO_00004)
4.2.6 [RS_Main_00450] AUTOSAR shall standardize access to general
purpose I/O
?
?(RS_PO_00001, RS_PO_00004)
4.2.7 [RS_Main_00460] AUTOSAR shall standardize methods to organize
mode management on SWC, ECU and system level
?
?(RS_PO_00001, RS_PO_00004)
4.2.8 [RS_Main_00170] AUTOSAR shall provide secure access to ECU
?
?(RS_PO_00004, RS_PO_00005, RS_PO_00009)
4.2.9 [RS_Main_00510] AUTOSAR shall support secure onboard
communication
?
?(RS_PO_00004, RS_PO_00005, RS_PO_00008)
4.2.10 [RS_Main_00260] AUTOSAR shall provide diagnostics means during
runtime, for production and services purposes
?
?(RS_PO_00004, RS_PO_00005, RS_PO_00009)
4.2.11 [RS_Main_00280] AUTOSAR shall provide a communication interface
to the infotainment systems
?
?(RS_PO_00003, RS_PO_00004, RS_PO_00008)
Dependability
4.2.12 [RS_Main_00010] AUTOSAR shall provide a software platform to
support the development of safety related systems.
?
?(RS_PO_00005, RS_PO_00009)
4.2.13 [RS_Main_00011] AUTOSAR shall support the development of reliable
systems
?
?(RS_PO_00005, RS_PO_00009)
4.3 Methodology
4.3.1 [RS_Main_00160] AUTOSAR shall provide means to describe
interfaces of the entire system.
?
?(RS_PO_00007)
4.3.2 [RS_Main_00180] AUTOSAR shall provide mechanisms to protect
intellectual property in a shared development process
?
?(RS_PO_00007)
4.3.3 [RS_Main_00300] AUTOSAR shall provide data exchange formats to
support work-share in large inter and intra company development
groups
?
?(RS_PO_00007)
4.3.4 [RS_Main_00080] AUTOSAR shall provide means to describe a
component model for application software
?
?(RS_PO_00004, RS_PO_00007)
4.3.5 [RS_Main_00310] AUTOSAR shall support hierarchical design
methods
?
?(RS_PO_00001, RS_PO_00002, RS_PO_00007)
4.3.6 [RS_Main_00320] AUTOSAR shall provide formats to specify all
aspects necessary to integrate a Software Component on an ECU ?
?(RS_PO_00004, RS_PO_00007)
4.3.7 [RS_Main_00340] AUTOSAR shall support the observance of timing
requirements
?
?(RS_PO_00005)
4.3.8 [RS_Main_00360] AUTOSAR shall support management of vehicle
diversity
?
?(RS_PO_00002)
4.3.9 [RS_Main_00250]AUTOSAR process shall provide a predefinition of
typical roles and activities in work-share model
?
?(RS_PO_00007)
4.3.10 [RS_Main_00251] AUTOSAR process shall support roles and rights in
a work-share model
?
?(RS_PO_00007)
4.4 Non-functional Requirements
4.4.1 [RS_Main_00200] AUTOSAR specifications shall allow resource
efficient implementations
?
?(RS_PO_00006)
4.4.2 [RS_Main_00220] The functional interfaces of AUTOSAR shall be
specified in C90
?
?(RS_PO_00004)
4.4.3 [RS_Main_00270] AUTOSAR shall provide mitigation strategies
towards new releases
?