Project Objectives

AUTOSAR Release 4.2.1

Document Title Project Objectives

Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 599
Document Classification Auxiliary

Document Status Final

Part of AUTOSAR Release 4.2.1

Document Change History

Release Changed by Change Description
4.2.1 AUTOSAR  Editorial changes
Release
Management
4.1.2 AUTOSAR  Editorial rework of [RS_PO_00005]
Release  Editorial changes
Management
4.1.1 AUTOSAR  Update of requirement numbering and layout of
Administration table according to the new template
4.0.3 AUTOSAR  Extracted Project Objectives (UID 599) from
Administration Main Requirements (UID 054).
 Major rework and update of all Project
Objectives to (a) reflect current results and (b)
the future focus of the project.

1 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

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.

2 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

Table of Content
1 Scope of the document ....................................................................................... 4
2 How to read this document.................................................................................. 5
2.1 Conventions used ............................................................................................... 5
3 The AUTOSAR project objectives ....................................................................... 6
3.1 [RS_PO_00001] AUTOSAR shall support the transferability of software. ........... 6
3.2 [RS_PO_00002] AUTOSAR shall support the scalability to different vehicle
and platform variants. .......................................................................................... 6
3.3 [RS_PO_00003] AUTOSAR shall support a broad variety of functional
domains. ............................................................................................................. 6
3.4 [RS_PO_00004] AUTOSAR shall define an open architecture for
automotive software. ........................................................................................... 7
3.5 [RS_PO_00005] AUTOSAR shall support the development of dependable
systems. .............................................................................................................. 7
3.6 [RS_PO_00006] AUTOSAR shall support sustainable utilization of natural
resources. ........................................................................................................... 8
3.7 [RS_PO_00007] AUTOSAR shall support the collaboration between various
partners. .............................................................................................................. 8
3.8 [RS_PO_00008] AUTOSAR shall standardize basic software functionality of
automotive ECUs. ............................................................................................... 9
3.9 [RS_PO_00009] AUTOSAR shall support applicable international
automotive standards and state-of-the-art technologies. .................................... 9
4 References ........................................................................................................ 10

3 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

1 Scope of the document

Each AUTOSAR Partner has committed to the top level project objectives (PO) of
AUTOSAR.

The project objectives are the top level requirements of the AUTOSAR standard and
get further refined in order to get broken down into the specific technical
requirements. For this purpose, the AUTOSAR Project Objectives are established as
a fundamental base to derive these specific requirements.

The term AUTOSAR is used as a synonym of the development partnership and the
technical product AUTomotive Open System ARchitecture.

4 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

2 How to read this document

Each project objective has its unique identifier starting with the prefix “RS_PO_” (for
“Requirements of Project Objectives”). For any review annotations, remarks or
questions, please refer to this unique ID rather than chapter or page numbers.
2.1 Conventions used
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.

 The representation of requirements in AUTOSAR documents follows the table

specified in [TPS_STDT_00078].
 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.)

5 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

3 The AUTOSAR project objectives

This chapter describes the project objectives of AUTOSAR. They are used as the
basis for further refinement into the AUTOSAR Main Requirements which drive the
specific technical requirements to build the AUTOSAR standard. Besides these
technical requirements, there are non-technical requirements, such as new business
model etc., which are not considered in the project objectives.
3.1 [RS_PO_00001] AUTOSAR shall support the transferability of
software.
⌈
Type: Valid
Description: AUTOSAR shall enable OEMs and suppliers to transfer software across
the vehicle network and to reuse software.
Rationale: Transferring software across the vehicle network allows overall system
scaling and optimization.
Redevelopment of software is expensive and error prone.
Use Case: Application software is reusable across different product lines and OEMs.
Scaling and optimizing of vehicle networks by transferring application
software.
Basic software is reusable across different ECUs and domains.
Dependencies: RS_PO_00003, RS_PO_00004, RS_PO_00007, RS_PO_00008
Supporting Material: --
⌋ ()

3.2 [RS_PO_00002] AUTOSAR shall support the scalability to

different vehicle and platform variants.
⌈
Type: Valid
Description: AUTOSAR shall provide mechanisms to develop systems, which can be
adapted to different vehicles, platforms and ECU hardware capabilities.
Rationale: Software functions can be used in ECUs with different hardware
characteristics.
Use Case: Integration of an application on a different or updated hardware platform
Development of an application which can be configured to be integrated
on different vehicles.
Dependencies: RS_PO_00008
Supporting Material: --
⌋ ()

3.3 [RS_PO_00003] AUTOSAR shall support a broad variety of

functional domains.
⌈
Type: Valid

6 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

Description: AUTOSAR shall support a broad variety of domains, this includes but is
not limited to:
 body/comfort,
 driver assistance systems,
 power train,
 chassis control, and
 occupant and pedestrian safety.
AUTOSAR shall support data exchange with non AUTOSAR systems.
Rationale: A common architecture across the functional domains allows the
relocation of software components across domains.
It increases the degree of freedom at generating the E/E system.
Use Case: Communication of AUTOSAR ECUs with infotainment ECUs.
Applying the same software systems to multiple domains.
Dependencies: RS_PO_00001
Supporting Material: --
⌋ ()

3.4 [RS_PO_00004] AUTOSAR shall define an open architecture

for automotive software.
⌈
Type: Valid
Description: AUTOSAR shall define an open architecture for automotive software
which can be maintained, adapted and extended.
Rationale: Findings from the application of AUTOSAR require maintaining
AUTOSAR.
Future requirements will increase the necessity to further evolve
AUTOSAR.
Only common functionality will be standardized by AUTOSAR. Therefore
the architecture shall allow individual extensions.
Use Case: Adaption to new technologies from silicon industry.
Integration of drivers for specific hardware.
Dependencies: RS_PO_00001, RS_PO_00005
Supporting Material: --
⌋ ()

3.5 [RS_PO_00005] AUTOSAR shall support the development of

dependable systems.
⌈
Type: Valid
Description: Dependable systems are characterized by the following attributes:
 Availability: readiness for correct service
 Reliability: continuity of correct service
 Safety: absence of unreasonable risk
 Integrity: mechanisms to inhibit improper system alteration
 Maintainability: ability to undergo modifications and repairs
 Security: protecting automotive software systems from
unauthorized access, use, disclosure, disruption, modification,
perusal, inspection, recording or destruction
which shall be supported by AUTOSAR.

7 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

Rationale: Numerous functions in the automotive domain have requirements on

functional safety and/or availability.
Automotive systems are characterized by long product life cycles and
short reaction times when the need for updates and upgrades comes up.
Most of the systems in the chassis and powertrain domain are safety
related.
Use Case: Support x-by-wire systems which have requirements on availability.
Software updates and upgrades.
Exchange of hardware platforms.
Dependencies: RS_PO_00004
Supporting Material: ISO 26262,
http://en.wikipedia.org/wiki/Dependability,
http://en.wikipedia.org/wiki/Information_security
⌋ ()

3.6 [RS_PO_00006] AUTOSAR shall support sustainable

utilization of natural resources.
⌈
Type: Valid
Description: AUTOSAR shall support technologies for sustainable utilization of natural
resources. This includes but is not limited to support of
 energy efficiency technologies, and
 renewable energy solutions.
Rationale: The demand on support for sustainable utilization of natural resources in
vehicles is continuously increasing.
Use Case: This includes but is not limited to
 Support of partial or full shut down of ECUs and/ or networks to
reduce electrical power consumption.
 Support for sensors and actors to measure and control e.g.
energy consumption and exhaust cleaning.
 Support of e-mobility to reduce carbon dioxide emission.
 Support to build systems to use and handle new energy sources.
Dependencies: --
Supporting Material: http://en.wikipedia.org/wiki/Sustainable_energy
⌋ ()

3.7 [RS_PO_00007] AUTOSAR shall support the collaboration

between various partners.
⌈
Type: Valid
Description: AUTOSAR shall support the collaboration between various partners by
standardized data exchange formats and support the integration of basic
software and application software from various partners on a single ECU
via a middleware and across the vehicle network.
Rationale: The automotive domain is characterized by collaborations between
various partners.
Coordination of e.g. interface and parameter definitions is an ongoing
challenge in distributed development projects.
In many ECUs software from different suppliers has to be integrated.
Use Case: Collaborations between OEMs, 1st tiers, software suppliers, tool and
service providers and semiconductor vendors.
Tier 1 provides the basic software stack and integrates the application
software from the OEM.
8 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives
- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

Dependencies: RS_PO_00001
Supporting Material: --
⌋ ()

3.8 [RS_PO_00008] AUTOSAR shall standardize basic software

functionality of automotive ECUs.
⌈
Type: Valid
Description: The basic software functionality shall be standardized by AUTOSAR. This
includes but is not limited to access to NVRAM, diagnostics,
communication management, ECU state management and OS.
Rationale: The basic software functionality is similar across different domains.
The basic software functionality is similar across different OEMs and
suppliers.
Use Case: Reuse of basic software and application software.
Basic software functionality can be provided as a product.
Dependencies: RS_PO_00001, RS_PO_00002, RS_PO_00009
Supporting Material: --
⌋ ()

3.9 [RS_PO_00009] AUTOSAR shall support applicable

international automotive standards and state-of-the-art
technologies.
⌈
Type: Valid
Description: AUTOSAR results shall be compliant to existing and applicable
international automotive standards and state-of-the-art technologies.
Rationale: Enable AUTOSAR to be used in todays and future systems.
Support is required to ensure interoperability with existing systems.
Use Case: Support of existing and future bus systems (CAN, FlexRay, etc.)
Dependencies: RS_PO_00008
Supporting Material: ISO15765, ISO11898, ISO14229, ISO27145, SAEJ1939
⌋ ()

9 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -
 Project Objectives
AUTOSAR Release 4.2.1

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

10 of 10 Document ID 599: AUTOSAR_RS_ProjectObjectives

- AUTOSAR confidential -