跳转至

Project Objectives

1. 文档范围

每个 AUTOSAR 合作伙伴都已承诺遵守 AUTOSAR 的顶层项目目标(PO)。

项目目标是 AUTOSAR 标准的顶层需求,会被进一步细化以分解为具体的技术需求。为此,AUTOSAR 项目目标被确立为推导这些具体需求的基础。

术语 AUTOSAR 既指开发合作伙伴关系,也指技术产品 AUTomotive Open System ARchitecture(汽车开放系统架构)。

2. 如何阅读本文档

每个项目目标都有以「RS_PO_」为前缀的唯一标识符(意为「项目目标的需求」)。任何评注意见、备注或问题,请引用该唯一 ID 而非章节号或页码。

2.1. 所用约定

在需求中,使用以下特定语义(取自互联网工程任务组 IETF 的征求意见稿 RFC 2119 [1])。

AUTOSAR 文档中需求的表述遵循 [2](AUTOSAR_FO_TPS_StandardizationTemplate)中约束 TPS_STDT_00078 规定的表格。

本文档中的关键词「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」和「OPTIONAL」应按如下方式解释。

注意,使用这些关键词的文档自身所处的需求层级会改变这些词的强制力。

  • MUST:该词,或形容词「LEGALLY REQUIRED」,表示由于法律原因,该定义是本规范的绝对要求。
  • MUST NOT:该短语,或短语「MUST NOT」,表示由于法律原因,该定义是本规范的绝对禁止。
  • SHALL:该短语,或形容词「REQUIRED」,表示该定义是本规范的绝对要求。
  • SHALL NOT:该短语表示该定义是本规范的绝对禁止。
  • SHOULD:该词,或形容词「RECOMMENDED」,表示在特定情形下可能存在充分的理由忽略某个特定条目,但在选择不同做法之前,必须理解其全部影响并仔细权衡。
  • SHOULD NOT:该短语,或短语「NOT RECOMMENDED」,表示在特定情形下,某种特定行为是可接受甚至有用的,但在实现以此标签描述的任何行为之前,应充分理解其全部影响并仔细权衡。
  • MAY:该词,或形容词「OPTIONAL」,表示某个条目是真正可选的。一家供应商可以选择包含该条目,因为特定市场需要它,或者因为该供应商认为它能增强产品;而另一家供应商可能省略同一条目。

不包含某个特定选项的实现,SHALL 准备好与包含该选项的另一实现互操作,尽管功能可能有所减少。同样,包含某个特定选项的实现,SHALL 准备好与不包含该选项的另一实现互操作(当然,该选项所提供的特性除外。)

3. AUTOSAR 项目目标

本章描述 AUTOSAR 的项目目标。它们被用作进一步细化的基础,细化为 AUTOSAR 主需求,主需求又驱动构建 AUTOSAR 标准所需的具体技术需求。除这些技术需求之外,还存在非技术性需求,例如新的商业模式等,项目目标不予考虑。

3.1. AUTOSAR 应支持软件的可移植性

AUTOSAR 应支持软件的可移植性。

描述 AUTOSAR 应使 OEM 和供应商能够在车辆网络中部署软件并复用软件。
理由 系统扩展与优化。
用例 通过迁移应用软件实现车辆网络的扩展与优化。
依赖项 §3.3、§3.5、§3.7
支撑材料 -

3.2. AUTOSAR 应支持向不同架构和硬件变体的可扩展性

AUTOSAR 应支持向不同架构和硬件变体的可扩展性。

描述 AUTOSAR 应提供用于开发系统的机制,使系统能够适配不同的车辆、平台和 ECU 硬件能力。
理由 软件功能可应用于具有不同硬件特性的 ECU。
用例 将应用集成到不同的或升级后的硬件平台上;开发可配置以集成到不同车辆上的应用。
依赖项 -
支撑材料 -

3.3. AUTOSAR 应为功能域无关

AUTOSAR 应为功能域无关。

描述 AUTOSAR 应与功能域无关。
理由 跨功能域的统一架构允许软件组件在域之间迁移。
用例 将相同的软件系统应用于多个领域。
依赖项 §3.1
支撑材料 -

3.4. AUTOSAR 应支持与非 AUTOSAR 系统的数据交换

AUTOSAR 应支持与非 AUTOSAR 系统的数据交换。

描述 AUTOSAR 应支持与非 AUTOSAR 系统的数据交换。
理由 这提高了生成 E/E 系统时的自由度。
用例 AUTOSAR ECU 与信息娱乐 ECU 之间的通信。
依赖项 §3.1
支撑材料 -

3.5. AUTOSAR 应定义面向汽车软件的开放架构

AUTOSAR 应定义面向汽车软件的开放架构。

描述 AUTOSAR 应定义一个可维护、可适配、可扩展的面向汽车软件的开放架构。
理由 AUTOSAR 应用中的经验要求维护 AUTOSAR。未来需求将增加进一步演进 AUTOSAR 的必要性。AUTOSAR 仅标准化通用功能。因此,架构应可扩展,同时不损害架构的基本原则。
用例 适配来自硅工业和软件工业等的新技术;集成特定硬件的驱动程序。
依赖项 §3.1、§3.6
支撑材料 -

3.6. AUTOSAR 应支持可信赖系统的开发

AUTOSAR 应支持可信赖系统的开发。

描述 可信赖系统具有以下属性:
* 可用性(Availability):正确服务的就绪性
* 可靠性(Reliability):正确服务的连续性
* 安全性(Safety):无不合理风险
* 完整性(Integrity):抑制对系统不当更改的机制
* 可维护性(Maintainability):进行修改和维修的能力
* 信息安全(Security):保护汽车软件系统免受未经授权的访问、使用、披露、中断、修改、翻阅、检查、记录或破坏,AUTOSAR 应对此提供支持。
理由 汽车领域中的大量功能对功能安全和/或可用性有要求。汽车系统的特点是产品生命周期长,并且在需要更新和升级时反应时间短。
用例 软件更新与升级。硬件平台的更换。
依赖项 §3.5
支撑材料 ISO 26262 [3]、SOTIF ISO-PAS 21448 [4]、SAE J3061、ISO/SAE 21434 [5]、UN/ECE/TRANS/WP-29

3.7. AUTOSAR 应支持合作伙伴之间的协作

AUTOSAR 应支持合作伙伴之间的协作。

描述 AUTOSAR 应通过标准化的数据交换格式支持合作伙伴之间的协作,并经由中间件支持将来自不同合作伙伴的基础软件和应用软件集成到单个 ECU 上以及跨车辆网络集成。
理由 汽车领域的特点是各合作伙伴之间的协作。在分布式开发项目中,接口和参数定义等的协调是一项持续的挑战。许多 ECU 中必须集成来自不同供应商的软件。
用例 合作伙伴之间的协作(例如 OEM、系统、软件、硬件和工具供应商)。
依赖项 §3.1
支撑材料 -

3.8. AUTOSAR 应支持适用的国际汽车标准和先进技术

AUTOSAR 应支持适用的国际汽车标准和先进技术。

描述 AUTOSAR 的成果应符合现有且适用的国际汽车标准和先进技术。
理由 需要该支持以确保与现有标准的互操作性。
用例 支持相关的 ISO/SAE/IEC 标准以及 UN-ECE。
依赖项 -
支撑材料 -

4. 参考文献

[1] Key words for use in RFCs to Indicate Requirement Levels

http://www.ietf.org/rfc/rfc2119.txt

[2] Standardization Template

AUTOSAR_FO_TPS_StandardizationTemplate

[3] ISO 26262(所有部分)——道路车辆——功能安全

https://www.iso.org

[4] ISO/PAS 21448:2019——道路车辆——预期功能安全

https://www.iso.org

[5] ISO 21434:2021——道路车辆——网络安全工程

https://www.iso.org

5. 变更历史

请注意,本章中的列表还包括在后续版本中已从规范中移除的需求项。这些需求项在文档中不作为超链接出现。

5.1. 本文档依据 AUTOSAR 版本 R23-11 的变更历史

5.1.1. R23-11 中新增的需求

表5.1:R23-11 中新增的需求

标题
AUTOSAR 应支持软件的可移植性。
AUTOSAR 应支持向不同架构和硬件变体的可扩展性。
AUTOSAR 应为功能域无关。
AUTOSAR 应支持与非 AUTOSAR 系统的数据交换。
AUTOSAR 应定义面向汽车软件的开放架构。
AUTOSAR 应支持可信赖系统的开发。
AUTOSAR 应支持合作伙伴之间的协作。
AUTOSAR 应支持适用的国际汽车标准和先进技术。

5.1.2. R23-11 中变更的需求

无

5.1.3. R23-11 中删除的需求

无