52 KiB
AUTOSAR 系统模板需求
AUTOSAR CP Release 4.4.0
原文:Requirements on System Template(文档 ID 213)
翻译状态:已完成 v1(封面+前言+目录+章节 1-3 完整翻译;所有需求表格已汉化)
对应原文 PDF:
MethodologyAndTemplates/AUTOSAR_RS_SystemTemplate.pdf翻译日期:Step 3 - P0 批量翻译
文档标识
| 字段 | 值 |
|---|---|
| 文档标题(Document Title) | 系统模板需求(Requirements on System Template) |
| 文档所有者(Document Owner) | AUTOSAR |
| 文档责任人(Document Responsibility) | AUTOSAR |
| 文档标识号(Document Identification No) | 213 |
| 文档状态(Document Status) | 正式版(Final) |
| 所属 AUTOSAR 标准 | Classic Platform(经典平台) |
| 所属标准版本 | 4.4.0 |
原文版权:© AUTOSAR — 机密文件 本中文译文仅供学习参考。
免责声明(Disclaimer)
本作品(规范和/或软件实现)及其包含的材料由 AUTOSAR 发布,仅供信息参考。AUTOSAR 及为其做出贡献的公司不对作品的任何使用承担责任。
本作品中包含的材料受版权及其他类型知识产权保护。对本作品所含材料的商业利用需要获得这些知识产权的许可。
本作品可在不作任何修改的情况下、以任何形式或任何手段用于纯信息性目的。任何其他目的,未经出版者书面许可,作品的任何部分不得被利用或复制。
本作品仅为汽车应用而开发。它既未为非汽车应用而开发,也未为非汽车应用而进行测试。
"AUTOSAR" 一词和 AUTOSAR 标志是注册商标。
文档变更历史(Document Change History)
| 日期 | 版本 | 变更人 | 变更说明 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 细微修正/澄清/编辑性变更;详情请参考 ChangeDocumentation |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性变更 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 细微修正/澄清/编辑性变更;详情请参考 ChangeDocumentation |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 细微修正/澄清/编辑性变更;详情请参考 ChangeDocumentation |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 新增需求 [RS_SYST_00049]、[RS_SYST_00050]、[RS_SYST_00051]、[RS_SYST_00052]、[RS_SYST_00053]、[RS_SYST_00054]、[RS_SYST_00055]、[RS_SYST_00056] |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 排版更新 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 新增需求 [RS_SYST_00043]、[RS_SYST_00044]、[RS_SYST_00045]、[RS_SYST_00046]、[RS_SYST_00047]、[RS_SYST_00048] |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 新增需求 [RS_SYST_00042] |
| 2009-12-18 | 4.0.1 | AUTOSAR Administration | 新增需求 [RS_SYST_00027]、[RS_SYST_00028]、[RS_SYST_00029]、[RS_SYST_00030]、[RS_SYST_00031]、[RS_SYST_00037]、[RS_SYST_00038]、[RS_SYST_00039]、[RS_SYST_00041];使用 SYSCT32、SYSCT33、SYSCT34、SYSCT35、SYSCT36 细化需求 SYSCT0004;使用 [RS_SYST_00037] 和 [RS_SYST_00040] 细化需求 SYSCT0005;细化需求 [RS_SYST_00007]、[RS_SYST_00001]、[RS_SYST_00035];修订法律免责声明 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 修订法律免责声明 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 新增需求 [RS_SYST_00025] 和 [RS_SYST_00026];将需求 [RS_SYST_00023] 置为 "postponed"(延期);扩展文档元信息;进行小幅度排版调整 |
| 2006-11-28 | 2.1 | AUTOSAR Administration | 作为独立文档发布。《System Template Specification V1.0.0》在 Release 2.1 中被拆分为若干独立文档;修订法律免责声明;新增发布说明;修订"用户建议";新增"修订信息" |
| 2005-05-31 | 1.0 | AUTOSAR Administration | 作为《System Template Specification V1.0.0》的一部分首次发布 |
目录
- 本文档范围(Scope of this Document)
- 需求(Requirements)
- 2.1 类别:主要需求(Main Requirements)
- 2.1.1 AUTOSAR 模板之间的兼容性
- 2.2 类别:系统模板需求(System Template Requirements)
- 2.2.1 遗留系统(Legacy systems)
- 2.2.2 基础软件和 RTE 资源
- 2.2.3 迭代开发(Iterative Development)
- 2.2.4 软件组件到 ECU 的映射
- 2.2.5 软件组件到 ECU 的映射:聚类(Clustering)
- 2.2.6 软件组件到 ECU 的映射:分离(Separation)
- 2.2.7 拓扑描述(Topology Description)
- 2.2.8 数据分段(Data Segmentation)
- 2.2.9 总线带宽(Bus bandwidth)
- 2.2.10 专用物理连接(Dedicated physical connections)
- 2.2.11 信号到同一物理线路的映射
- 2.2.12 信号到不同物理线路的映射
- 2.2.13 信号到特定物理线路的映射
- 2.2.14 将信号从特定物理线路排除
- 2.2.15 ECU 通过 CAN 通信
- 2.2.16 ECU 通过 LIN 通信
- 2.2.17 ECU 通过 MOST 通信
- 2.2.18 ECU 通过 FlexRay 通信
- 2.2.19 从系统模板推导 COM 栈配置参数
- 2.2.20 ASAM FIBEX 兼容性
- 2.2.21 ECU Extract 生成规则
- 2.2.22 IPdu 端到端通信保护支持
- 2.2.23 动态长度信号(Dynamic length signals)
- 2.2.24 动态长度 IPdu(Dynamic length IPdus)
- 2.2.25 应用和车辆模式请求的分发
- 2.2.26 拓扑变体(Topology variants)
- 2.2.27 软件到 ECU 映射变体
- 2.2.28 时序变体(Timing Variants)
- 2.2.29 数据映射变体(Data mapping variants)
- 2.2.30 通信变体(Communication variants)
- 2.2.31 时序属性(Timing properties)
- 2.2.32 支持 SAE J1939 协议特性
- 2.2.33 ECU 通过 Ethernet 通信
- 2.2.34 时序约束(Timing constraints)
- 2.2.35 ECU Extract 中的变体
- 2.2.36 支持部分联网(Partial Networking)
- 2.2.37 通过 Complex Drivers 通信
- 2.2.38 自定义总线系统的描述
- 2.2.39 同一模型中共存的系统工件
- 2.2.40 系统 SWC 结构的不同视图
- 2.2.41 信号层级的网络和物理表示
- 2.2.42 CAN with Flexible Data-Rate
- 2.2.43 支持用于大数据配置的 Efficient COM
- 2.2.44 ECU 间通信的数据转换
- 2.2.45 支持基于 COM 的数据转换
- 2.2.46 命名约定(Naming conventions)
- 2.2.47 支持 Secured Pdus
- 2.2.48 支持 Container Pdus
- 2.2.49 E2E 保护通信
- 2.2.50 将通信图分配给特定的 RTE Implementation Plug-Ins
- 2.2.51 可选元素(Optional Elements)
- 2.1 类别:主要需求(Main Requirements)
- 变更历史(Change History)
- 3.1 AUTOSAR 4.0.1 相对于 3.1.5 的变更历史
- 3.2 AUTOSAR 4.0.2 相对于 4.0.1 的变更历史
- 3.3 AUTOSAR 4.0.3 相对于 4.0.2 的变更历史
- 3.4 AUTOSAR 4.1.1 相对于 4.0.3 的变更历史
- 3.5 AUTOSAR 4.1.1 相对于 4.1.2 的变更历史
- 3.6 AUTOSAR 4.1.2 相对于 4.2.1 的变更历史
- 3.7 AUTOSAR 4.2.1 相对于 4.2.2 的变更历史
- 3.8 AUTOSAR 4.2.2 相对于 4.3.0 的变更历史
- 3.9 AUTOSAR 4.3.0 相对于 4.3.1 的变更历史
- 3.10 AUTOSAR 4.3.1 相对于 4.4.0 的变更历史
参考文献(References)
- [1] System Template,AUTOSAR_TPS_SystemTemplate
- [2] Standardization Template,AUTOSAR_TPS_StandardizationTemplate
- [3] Main Requirements,AUTOSAR_RS_Main
1 本文档范围(Scope of this Document)
本文档收集对系统模板(System Template,简称 SYS-T)的需求。系统模板的主要目标是定义纯软件视图的系统与由网络化 ECU 组成的物理系统架构之间的关系。
系统模板涵盖以下方面:
- 系统拓扑(System topology):在系统拓扑中,描述系统的逻辑布局。即记录哪些 ECU 连接到哪些 cluster 或 channel。
- 通信属性(Communication properties):通信系统的中心目的是以某些属性交换帧。
- 映射(Mapping):映射涵盖软件组件到 ECU 的分配,以及待交换的、位于软件组件之间的数据元素到信号和帧的映射。
本文档中收集的需求将由系统模板规范 [1] 满足。该文档实现了此处陈述的大部分需求。
1.1 文档约定(Document Conventions)
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中规定的表格,详见《Standardization Template》[2] 的"Support for Traceability"一章。
用于表达义务的动词形式应遵循 [TPS_STDT_00053] 的规定,用以表示需求,详见《Standardization Template》[2] 的"Support for Traceability"一章。
1.2 需求追溯(Requirements Tracing)
下表引用 [3] 中规定的需求,并将其与本文档对它们的实现联系起来。
| 需求 | 描述 | 满足者 |
|---|---|---|
| [RS_Main_00010] | AUTOSAR 应支持安全相关系统的开发 | [RS_SYST_00028] [RS_SYST_00056] |
| [RS_Main_00026] | AUTOSAR 应支持所执行软件之间的高速和高带宽通信 | [RS_SYST_00048] [RS_SYST_00049] [RS_SYST_00050] [RS_SYST_00055] |
| [RS_Main_00030] | AUTOSAR 应支持安全相关系统的开发过程 | [RS_SYST_00003] [RS_SYST_00008] [RS_SYST_00009] [RS_SYST_00016] [RS_SYST_00017] [RS_SYST_00018] [RS_SYST_00019] [RS_SYST_00020] |
| [RS_Main_00060] | AUTOSAR 应为应用之间的通信提供标准化的软件接口 | [RS_SYST_00031] [RS_SYST_00057] |
| [RS_Main_00100] | AUTOSAR 应提供标准化的基础软件 | [RS_SYST_00002] [RS_SYST_00025] |
| [RS_Main_00140] | AUTOSAR 应为应用提供与网络无关的通信机制 | [RS_SYST_00014] [RS_SYST_00049] [RS_SYST_00050] [RS_SYST_00051] |
| [RS_Main_00150] | AUTOSAR 应支持 AUTOSAR 应用软件的部署和重分配 | [RS_SYST_00002] [RS_SYST_00007] [RS_SYST_00008] [RS_SYST_00009] [RS_SYST_00016] [RS_SYST_00017] [RS_SYST_00018] [RS_SYST_00019] [RS_SYST_00020] |
| [RS_Main_00161] | AUTOSAR 应提供统一的方式描述部署到 Adaptive 和/或 Classic 平台的软件系统 | [RS_SYST_00045] [RS_SYST_00046] |
| [RS_Main_00180] | AUTOSAR 应提供在共享开发过程中保护知识产权的机制 | [RS_SYST_00027] |
| [RS_Main_00190] | AUTOSAR 应支持与非 AUTOSAR 软件的标准化互操作 | [RS_SYST_00001] |
| [RS_Main_00210] | 无描述 | [RS_SYST_00001] [RS_SYST_00015] |
| [RS_Main_00230] | AUTOSAR 应支持包含网关的网络拓扑 | [RS_SYST_00013] [RS_SYST_00044] [RS_SYST_00052] |
| [RS_Main_00280] | AUTOSAR 应支持标准化的汽车通信协议 | [RS_SYST_00058] |
| [RS_Main_00300] | AUTOSAR 应提供数据交换格式,以支持大型跨公司及公司内部开发组之间的分工 | [RS_SYST_00006] [RS_SYST_00027] |
| [RS_Main_00320] | AUTOSAR 应提供指定系统开发各阶段的格式 | [RS_SYST_00007] [RS_SYST_00013] [RS_SYST_00045] [RS_SYST_00047] |
| [RS_Main_00340] | AUTOSAR 应支持连续的时序需求分析 | [RS_SYST_00037] [RS_SYST_00040] |
| [RS_Main_00360] | AUTOSAR 应支持变体管理 | [RS_SYST_00032] [RS_SYST_00033] [RS_SYST_00034] [RS_SYST_00035] [RS_SYST_00036] [RS_SYST_00041] |
| [RS_Main_00400] | AUTOSAR 应提供分层式软件架构 | [RS_SYST_00043] |
| [RS_Main_00420] | AUTOSAR 应使用已建立的软件标准并整合事实上的基础软件功能标准 | [RS_SYST_00026] |
| [RS_Main_00430] | AUTOSAR 应支持已建立的汽车通信标准 | [RS_SYST_00015] [RS_SYST_00021] [RS_SYST_00022] [RS_SYST_00023] [RS_SYST_00024] [RS_SYST_00025] [RS_SYST_00029] [RS_SYST_00030] [RS_SYST_00038] [RS_SYST_00039] [RS_SYST_00052] |
| [RS_Main_00460] | AUTOSAR 应在应用、ECU 和系统层面标准化组织模式管理的方法 | [RS_SYST_00042] |
| [RS_Main_00500] | AUTOSAR 应提供命名约定 | [RS_SYST_00053] |
| [RS_Main_00510] | AUTOSAR 应支持安全的板载通信 | [RS_SYST_00054] |
| [RS_Main_01003] | AUTOSAR 应支持面向数据的通信 | [RS_SYST_00051] |
表 1.1:需求追溯(RequirementsTracing)
2 需求(Requirements)
2.1 类别:主要需求(Main Requirements)
2.1.1 AUTOSAR 模板之间的兼容性
⌈[RS_SYST_00006] AUTOSAR 模板之间的兼容性⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | AUTOSAR 模板之间的兼容性必须得到保证。在此语境下,兼容性意味着每个 AUTOSAR 模板都可以引用另一个 AUTOSAR 模板的元素。 |
| 理由 | 确保 AUTOSAR 模板之间的连贯性和互操作性。 |
| 依赖 | 未识别。 |
| 用例 | 使用同一工具链开发车内电子架构(软件建模、硬件建模和映射约束建模)。 |
| 支撑材料 | – |
⌊(RS_Main_00300)
2.2 类别:系统模板需求(System Template Requirements)
2.2.1 遗留系统(Legacy systems)
⌈[RS_SYST_00001] 混合系统(AUTOSAR/NON-AUTOSAR)⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 因使用混合系统而产生的系统约束必须由系统模板加以处理。 |
| 理由 | 从非 AUTOSAR 系统向完全 AUTOSAR 系统的过渡只能逐步实现。此外,必须确保与遗留解决方案的互操作性。因此,必须能够在同一系统中同时存在 AUTOSAR 和非 AUTOSAR 的 ECU("混合"系统)。 |
| 依赖 | 未识别。 |
| 用例 | 在现有架构中逐步引入 AUTOSAR,例如应能处理并非源自 AUTOSAR 软件组件的信号。 |
| 支撑材料 | – |
⌊(RS_Main_00190, RS_Main_00210)
2.2.2 基础软件和 RTE 资源
⌈[RS_SYST_00002] 基础软件资源和 RTE 资源⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖基础软件和 RTE 的资源请求。 |
| 理由 | ECU 的资源本身是有限的(RAM、ROM、CPU 时间等)。这些限制在映射过程中起到约束作用。 |
| 依赖 | 未识别。 |
| 用例 | 在小型 ECU 上分配 AUTOSAR 服务和功能时考虑内存限制。 |
| 支撑材料 | – |
⌊(RS_Main_00150, RS_Main_00100)
2.2.3 迭代开发(Iterative Development)
⌈[RS_SYST_00003] 迭代开发⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须支持迭代式的系统开发。 |
| 理由 | 在 AUTOSAR 系统开发过程中,前一阶段系统设计步骤中所找到的解决方案,本身就是下一阶段系统生成的约束。 |
| 依赖 | 未识别。 |
| 用例 | 若在开发后期向车辆项目中添加新功能,则当前的映射将自身成为与该新功能相关联的新软件组件映射的约束。 |
| 支撑材料 | – |
⌊(RS_Main_00030)
2.2.4 软件组件到 ECU 的映射
⌈[RS_SYST_00007] 软件组件到 ECU 的映射⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须描述软件组件到 ECU 的映射。还应支持将软件组件可选地映射到位于同一 ECU 中的各处理单元。 |
| 理由 | – |
| 依赖 | 未识别。 |
| 用例 | 出于安全原因(或仅凭经验),某些特定的软件组件只能运行在某些特定的 ECU 上。这种"预映射"是实际映射过程的约束。 |
| 支撑材料 | – |
⌊(RS_Main_00320, RS_Main_00150)
2.2.5 软件组件到 ECU 的映射:聚类(Clustering)
⌈[RS_SYST_00008] SWC 聚类⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统约束描述必须涵盖 SW 组件的聚类。SW 组件聚类意味着两个 SW 组件不可分割,必须被映射到同一 ECU。 |
| 理由 | 由于性能要求、安全通信要求或仅凭经验,某些通信路径必须避免被映射到外部总线上。涉及的 SW 组件应一起映射到同一 ECU 上。 |
| 依赖 | 未识别。 |
| 用例 | 不能通过通信总线承载的安全通信,或非常严格的时序要求。 |
| 支撑材料 | – |
⌊(RS_Main_00030, RS_Main_00150)
2.2.6 软件组件到 ECU 的映射:分离(Separation)
⌈[RS_SYST_00009] SWC 分离⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统约束描述必须涵盖 SW 组件的分离。SW 组件分离意味着两个 SW 组件不能位于同一 ECU 上。 |
| 理由 | 增强冗余 SWC 之间的独立性。 |
| 依赖 | 未识别。 |
| 用例 | 实现安全关键功能的两个冗余软件组件不会由于安全要求而被一起映射到同一 ECU 上(当然,冗余并不总是意味着 SWC 分离)。 |
| 支撑材料 | – |
⌊(RS_Main_00030, RS_Main_00150)
2.2.7 拓扑描述(Topology Description)
⌈[RS_SYST_00013] 拓扑⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须描述 EE 系统的拓扑。 |
| 理由 | 可用的通信路径限制了将 SW 组件分配到某些 ECU 的可能性。 |
| 依赖 | 未识别。 |
| 用例 | 映射在功能上紧密耦合的 SW 组件:此时必须了解拓扑,以避免过长的数据路径。 |
| 支撑材料 | – |
⌊(RS_Main_00320, RS_Main_00230)
2.2.8 数据分段(Data Segmentation)
⌈[RS_SYST_00014] 数据分段⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须提供可用于将(应用)数据分段到多个帧中的信息。 |
| 理由 | 底层总线技术的数据长度限制。 |
| 依赖 | 未识别。 |
| 用例 | 诊断数据的传输,其长度通常超过特定总线的最大帧大小。 |
| 支撑材料 | – |
⌊(RS_Main_00140)
2.2.9 总线带宽(Bus bandwidth)
⌈[RS_SYST_00015] 总线带宽⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持将带宽计算作为定义 Communication Matrix 的约束。 |
| 理由 | 带宽是有限的资源,在定义 Communication Matrix 时起到约束作用。 |
| 依赖 | 未识别。 |
| 用例 | 当为混合系统(AUTOSAR 和非 AUTOSAR ECU)定义 Communication Matrix 时,Communication Matrix 的一部分只能使用 AUTOSAR 流程进行自由配置。也就是说,AUTOSAR 系统生成器可用的带宽受非 AUTOSAR 部分 Communication Matrix 的限制。 |
| 支撑材料 | – |
⌊(RS_Main_00210, RS_Main_00430)
2.2.10 专用物理连接(Dedicated physical connections)
⌈[RS_SYST_00016] 专用物理连接⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统约束描述应能描述信号必须通过专用线路发送,该线路仅由两个 SW 组件(发送方和接收方)使用。 |
| 理由 | 此技术在当前的安全概念中被普遍使用。 |
| 依赖 | 未识别。 |
| 用例 | 与安全气囊模块的通信。 |
| 支撑材料 | – |
⌊(RS_Main_00150, RS_Main_00030)
2.2.11 信号到同一物理线路的映射
⌈[RS_SYST_00017] 信号到同一物理线路的映射⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统约束描述应能描述一组信号必须通过同一物理线路发送。 |
| 理由 | – |
| 依赖 | 未识别。 |
| 用例 | – |
| 支撑材料 | – |
⌊(RS_Main_00150, RS_Main_00030)
2.2.12 信号到不同物理线路的映射
⌈[RS_SYST_00018] 信号到不同物理线路的映射⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统约束描述应能描述在需要时,ECU 之间的信号通过不同物理线路发送。 |
| 理由 | 支持硬件和信息冗余(作为支持故障检测和故障处理的手段)。 |
| 依赖 | 未识别。 |
| 用例 | 保障极安全关键数据传输的一种方法是将冗余副本强制发送到不同的物理线路上。 |
| 支撑材料 | – |
⌊(RS_Main_00150, RS_Main_00030)
2.2.13 信号到特定物理线路的映射
⌈[RS_SYST_00019] 信号到特定物理线路的映射⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统约束描述应能描述信号必须映射到特定物理线路。 |
| 理由 | 出于特殊的性能和/或安全需要,某些信号必须映射到特定的物理线路。 |
| 依赖 | 未识别。 |
| 用例 | 动力总成信号由于其时序要求必须映射到高速总线。 |
| 支撑材料 | – |
⌊(RS_Main_00150, RS_Main_00030)
2.2.14 将信号从特定物理线路排除
⌈[RS_SYST_00020] 将信号从特定物理线路排除⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统约束描述应能描述信号不得映射到特定物理线路。 |
| 理由 | 某些物理线路可能不适合(过慢、不安全的通信协议等)传输某些特定信号。 |
| 依赖 | 未识别。 |
| 用例 | 由于时序要求,大多数动力总成信号不能映射到低速 CAN 总线。 |
| 支撑材料 | – |
⌊(RS_Main_00150, RS_Main_00030)
2.2.15 ECU 通过 CAN 通信
⌈[RS_SYST_00021] ECU 通过 CAN 通信⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖通过 CAN 总线的系统通信。 |
| 理由 | CAN 在汽车系统中被广泛使用。 |
| 依赖 | 未识别。 |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00430)
2.2.16 ECU 通过 LIN 通信
⌈[RS_SYST_00022] ECU 通过 LIN 通信⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖通过 LIN 的系统通信。 |
| 理由 | LIN 在汽车系统中被广泛使用。 |
| 依赖 | 未识别。 |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00430)
2.2.17 ECU 通过 MOST 通信
⌈[RS_SYST_00023] ECU 通过 MOST 通信⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖通过 MOST 的系统通信。 |
| 理由 | MOST 即将成为汽车行业的标准通信协议。 |
| 依赖 | 未识别。 |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00430)
2.2.18 ECU 通过 FlexRay 通信
⌈[RS_SYST_00024] ECU 通过 FlexRay 通信⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖通过 FlexRay 的系统通信。 |
| 理由 | FlexRay 即将成为汽车行业的标准通信协议。 |
| 依赖 | 未识别。 |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00430)
2.2.19 从系统模板推导 COM 栈配置参数
⌈[RS_SYST_00025] 从系统模板推导 COM 栈配置参数⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持 ECU 的 Com 栈配置。它处理描述 ECU 间通信所需的那些参数。ECU 本地的配置参数不在系统模板的范围之内。 |
| 理由 | 连接在同一通信 cluster 中的所有 ECU 需要以一致的方式进行配置。 |
| 依赖 | 未识别。 |
| 用例 | 从 ECU Extract 生成基础 ECU 配置(Base ECU Configuration)。 |
| 支撑材料 | – |
⌊(RS_Main_00430, RS_Main_00100)
2.2.20 ASAM FIBEX 兼容性
⌈[RS_SYST_00026] FIBEX 兼容性⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 当系统模板与 ASAM FIBEX 标准之间存在相当大的重叠时,系统模板应采用 ASAM FIBEX 标准的结构。 |
| 理由 | 系统模板将受益于 FIBEX 作为已建立的成熟标准。 |
| 依赖 | 未识别。 |
| 用例 | 便于将系统模板纳入处理 FIBEX 标准的现有工具中。 |
| 支撑材料 | ASAM FIBEX |
⌊(RS_Main_00420)
2.2.21 ECU Extract 生成规则
⌈[RS_SYST_00027] ECU Extract 生成规则⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | ECU Extract 由系统描述派生而来。生成 ECU Extract 的规范应足够详细,以支持对该工件进行语义无歧义的生成。 |
| 理由 | 工具互操作性要求对 ECU Extract 进行无歧义的描述。 |
| 依赖 | 未识别。 |
| 用例 | 从 ECU Extract 生成基础 ECU 配置(Base ECU Configuration)。 |
| 支撑材料 | – |
⌊(RS_Main_00180, RS_Main_00300)
2.2.22 IPdu 端到端通信保护支持
⌈[RS_SYST_00028] IPdu 端到端通信保护支持⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持为 IPdu 选择 E2E 保护设置。 |
| 理由 | 保护 COM 模块之间的通信。 |
| 依赖 | 未识别。 |
| 用例 | 在无冗余的单通道上传输安全相关数据。 |
| 支撑材料 | – |
⌊(RS_Main_00010)
2.2.23 动态长度信号(Dynamic length signals)
⌈[RS_SYST_00029] 动态长度信号⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持动态长度信号的定义。一个信号应具有静态长度,或其长度可在静态定义的最大值范围内变化。具有最大长度的信号称为动态长度信号。 |
| 理由 | 动态长度信号可在运行时改变大小。 |
| 依赖 | 未识别。 |
| 用例 | – |
| 支撑材料 | OSEK COM |
⌊(RS_Main_00430)
2.2.24 动态长度 IPdu(Dynamic length IPdus)
⌈[RS_SYST_00030] 动态长度 IPdu⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持包含动态长度信号的 IPdu 的定义。 |
| 理由 | 动态长度 IPdu 可在运行时改变大小。 |
| 依赖 | [RS_SYST_00029] |
| 用例 | 网络层和数据链路层能够按照 Interaction Layer 的决定传输和接收固定与动态长度的 I-Pdu。 |
| 支撑材料 | OSEK COM |
⌊(RS_Main_00430)
2.2.25 应用和车辆模式请求的分发
⌈[RS_SYST_00031] 应用和车辆模式请求的分发⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持将应用和车辆模式请求分发给所有受影响的 ECU。 |
| 理由 | 模式请求者(Mode Requester)是通过带模式请求接口的端口发送数据、向模式管理器(Mode Manager)请求模式的实体。模式管理器接收传入信息,对请求进行仲裁,并决定所产生的结果模式。 |
| 依赖 | 未识别。 |
| 用例 | 根据车辆和应用模式,BSW 模式可能改变,例如应用对通信的需求可能导致某通信网络的 BSW 模式发生变化。 |
| 支撑材料 | – |
⌊(RS_Main_00060)
2.2.26 拓扑变体(Topology variants)
⌈[RS_SYST_00032] 拓扑变体⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述拓扑变体的手段,包括可选/可替换的 ECU 和通信 cluster。 |
| 理由 | 在产品线方法中,不同的产品变体可以通过具有少量变化拓扑节点的共同核心拓扑实现。 |
| 依赖 | 未识别。 |
| 用例 | 在产品线中,两个不同的产品变体 HIGH 和 LOW 使用相同的核心拓扑,区别在于变体 HIGH 额外需要一个 ECU。 |
| 支撑材料 | – |
⌊(RS_Main_00360)
2.2.27 软件到 ECU 映射变体
⌈[RS_SYST_00033] 软件到 ECU 映射变体⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述软件组件到 ECU 的可替换映射的手段。 |
| 理由 | 为了使产品线中各产品的整体系统达到不同的特定特性,可使用不同的软件组件映射。 |
| 依赖 | [RS_SYST_00007], [RS_SYST_00008], [RS_SYST_00009], [RS_SYST_00013] |
| 用例 | 在产品线中,两个不同的产品变体 HIGH 和 LOW 使用相同的通用软件架构,但对网络拓扑的映射不同。 |
| 支撑材料 | – |
⌊(RS_Main_00360)
2.2.28 时序变体(Timing Variants)
⌈[RS_SYST_00034] 时序变体⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述可替换的时序属性(例如触发类型、周期、优先级)和时序约束(例如延迟、时效)的手段。 |
| 理由 | 由于软件到 ECU 映射的不同,信号传输的时序属性和约束可能会有所不同。 |
| 依赖 | 未识别。 |
| 用例 | 一个 PDU 在两个不同的产品变体 HIGH 和 LOW 中以循环方式传输:变体 HIGH 周期为 10ms,变体 LOW 周期为 20ms。 |
| 支撑材料 | – |
⌊(RS_Main_00360)
2.2.29 数据映射变体(Data mapping variants)
⌈[RS_SYST_00035] 数据映射变体⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述数据映射变体的手段。 |
| 理由 | 软件组件描述中的变体会影响系统模板中所描述的数据映射。 |
| 依赖 | 未识别。 |
| 用例 | 某 DataElement 仅在产品变体 HIGH 中存在。 |
| 支撑材料 | – |
⌊(RS_Main_00360)
2.2.30 通信变体(Communication variants)
⌈[RS_SYST_00036] 通信变体⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述通信变体的手段,例如可替换的 signal-to-PDU 映射、可替换的通信路径,以及可替换的信号和 PDU 属性(如数据类型、数据长度)。 |
| 理由 | 为使用相同网络拓扑的不同产品变体优化通信矩阵,系统模板中的通信变体描述是必要的前提。 |
| 依赖 | [RS_SYST_00032], [RS_SYST_00035] |
| 用例 | 某信号在两个不同的产品变体 HIGH 和 LOW 中传输:变体 HIGH 使用 LittleEndian 字节序,变体 LOW 使用 BigEndian 字节序。 |
| 支撑材料 | – |
⌊(RS_Main_00360)
2.2.31 时序属性(Timing properties)
⌈[RS_SYST_00037] 时序属性⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述系统动态的时序属性的手段,该动态由计算、通信及其他硬件资源的消耗决定。 |
| 理由 | 系统模板中时序属性的描述是分析和验证系统时序行为或在流程早期对其进行预测的必要前提。 |
| 依赖 | 未识别。 |
| 用例 | 时序行为的分析和验证、对修改影响的早期预测、支持硬件规模设计、系统配置优化。 |
| 支撑材料 | – |
⌊(RS_Main_00340)
2.2.32 支持 SAE J1939 协议特性
⌈[RS_SYST_00038] 支持 SAE J1939 协议特性⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖通过 SAE J1939 的系统通信。 |
| 理由 | SAE J1939 协议是汽车系统中使用的行业标准。 |
| 依赖 | 未识别。 |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00430)
2.2.33 ECU 通过 Ethernet 通信
⌈[RS_SYST_00039] ECU 通过 Ethernet 通信⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖通过 Ethernet 的系统通信。 |
| 理由 | Ethernet 即将成为汽车行业的标准通信协议。 |
| 依赖 | 未识别。 |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00430)
⌈[RS_SYST_00052] Ethernet 交换机配置⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | Ethernet 交换机配置应提供标准化的工件,用于描述出口端口的结构、端口调度机制以及交换机内部的转发过程。可以在初始化阶段写入交换机的公共参数需要集成到系统描述中。 |
| 理由 | 交换机内消息的时序行为取决于交换机的配置。因此,需要对交换机的行为进行描述。 |
| 依赖 | – |
| 用例 | 提供包含交换机模型及其行为的 Ethernet 拓扑描述。 |
| 支撑材料 | – |
⌊(RS_Main_00430, RS_Main_00230)
2.2.34 时序约束(Timing constraints)
⌈[RS_SYST_00040] 时序约束⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述系统动态的时序约束的手段,该动态由计算、通信及其他硬件资源的消耗决定。 |
| 理由 | 系统模板中时序约束的描述是分析和验证系统时序行为或在流程早期对其进行预测的必要前提。 |
| 依赖 | 未识别。 |
| 用例 | 时序行为的分析和验证、对修改影响的早期预测、支持硬件规模设计、系统配置优化。 |
| 支撑材料 | – |
⌊(RS_Main_00340)
2.2.35 ECU Extract 中的变体
⌈[RS_SYST_00041] ECU Extract 中的变体⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | ECU Extract 应支持从系统描述转换过程中所获取或派生的元素的可变性。 |
| 理由 | 数据映射和通信变体(见 [RS_SYST_00035]、[RS_SYST_00036])可能需要在由系统描述生成的工件(例如 ECU-Extract)中保留,如果绑定时间处于流程的较后阶段。 |
| 依赖 | 未识别。 |
| 用例 | Pdu 布局在 ECU 配置期间可在 postbuild 时配置;这种可变性需要在构建时可见。 |
| 支撑材料 | – |
⌊(RS_Main_00360)
2.2.36 支持部分联网(Partial Networking)
⌈[RS_SYST_00042] 支持部分联网⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持部分网络 cluster 的定义、虚拟功能 cluster 到部分网络 cluster 的映射,以及各 ECU 的唤醒信息。 |
| 理由 | 系统模板应包含配置部分网络所需的全部系统相关参数。 |
| 依赖 | 未识别。 |
| 用例 | 描述系统级部分网络 cluster 向量的大小和位置。 |
| 支撑材料 | – |
⌊(RS_Main_00460)
2.2.37 通过 Complex Drivers 通信
⌈[RS_SYST_00043] 通过 Complex Drivers 通信⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持通过 Complex Drivers 进行基于 Pdu 的通信。 |
| 理由 | 应能描述通过网络传输的 Complex Driver Pdu。 |
| 依赖 | 未识别。 |
| 用例 | 在 PduR 之上使用新的 BSW 模块,例如诊断服务。 |
| 支撑材料 | – |
⌊(RS_Main_00400)
2.2.38 自定义总线系统的描述
⌈[RS_SYST_00044] 自定义总线系统的描述⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持在拓扑层面对自定义总线系统进行集成。 |
| 理由 | 应能通过系统描述描述车辆的完整网络拓扑。 |
| 依赖 | 未识别。 |
| 用例 | 将替代性通信技术(如 I2C、USB、serial line)集成为 Complex Drivers。 |
| 支撑材料 | – |
⌊(RS_Main_00230)
2.2.39 同一模型中共存的系统工件
⌈[RS_SYST_00045] 同一模型中共存的系统工件⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述不同 System Extract 的手段,使其能在同一模型中与完整系统描述以及其他 System Extract 共存。 |
| 理由 | – |
| 依赖 | 未识别。 |
| 用例 | OEM 将一份 system extract 交给供应商,作为正式的"需求"规范。供应商对该 system extract 进行扩展和重构。在下一开发周期,OEM 将更新后的 system extract 移交给供应商。供应商根据 OEM 的更新来更新其 system extract。 |
| 支撑材料 | [RS_METH_00077] |
⌊(RS_Main_00320, RS_Main_00161)
2.2.40 系统 SWC 结构的不同视图
⌈[RS_SYST_00046] 系统 SWC 结构的不同视图⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述 SWC 结构的不同视图及其元素之间映射的手段。 |
| 理由 | – |
| 依赖 | 未识别。 |
| 用例 | OEM 对 SWC 结构的不同视图:功能视图(独立于 ECU)和 ECU 拓扑视图。 |
| 支撑材料 | [RS_METH_00078], [RS_METH_00079] |
⌊(RS_Main_00161)
2.2.41 信号层级的网络和物理表示
⌈[RS_SYST_00047] 信号层级的网络和物理表示⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述信号物理表示和网络表示的手段。 |
| 理由 | – |
| 依赖 | 未识别。 |
| 用例 | – |
| 支撑材料 | – |
⌊(RS_Main_00320)
2.2.42 CAN with Flexible Data-Rate
⌈[RS_SYST_00048] CAN with Flexible Data-Rate⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持 CAN FD 协议。 |
| 理由 | CAN FD 增加了 CAN 网络的带宽,并允许大于 8 字节的有效负载。 |
| 依赖 | 未识别。 |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00026)
2.2.43 支持用于大数据配置的 Efficient COM
⌈[RS_SYST_00049] 支持用于大数据配置的 Efficient COM⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持通过 Efficient COM for large data 配置通信。 |
| 理由 | Efficient COM for large data 提供了一种精简机制,用于处理 RTE 与 Communication Stack 之间的交互。然而,若要通过 Efficient COM for large data 完成此交互,则需满足一些前提条件。系统模板应定义这些前提条件。 |
| 依赖 | – |
| 用例 | 仅包含一个信号且未定义特殊传输模式的 IPdu 可由 Efficient COM for large data 处理。 |
| 支撑材料 | – |
⌊(RS_Main_00140, RS_Main_00026)
2.2.44 ECU 间通信的数据转换
⌈[RS_SYST_00050] ECU 间通信的数据转换⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供描述 ECU 间通信的数据转换的手段。 |
| 理由 | 如果需要转换 ECU 间通信的数据,则必须在系统内对其进行配置,以便发送和接收 ECU 执行数据转换。 |
| 依赖 | 未识别。 |
| 用例 | 应当将大型复合数据一次性映射到总线通信中,以避免对复合数据的每个原子元素进行单独映射。 |
| 支撑材料 | – |
⌊(RS_Main_00026, RS_Main_00140)
2.2.45 支持基于 COM 的数据转换
⌈[RS_SYST_00051] 支持基于 COM 的数据转换⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供定义 uint8 数组 API 用法的手段,以将复合数据的序列化表示传递给 COM 模块。 |
| 理由 | AUTOSAR transformer chain 提供了将复合数据序列化为 uint8 数组表示的方法。该序列化的 uint8 数组应作为一个整体传递给 COM。 |
| 依赖 | – |
| 用例 | 与运行 AUTOSAR R4.1 及更早版本的 ECU 通信时,将 transformer 与基于 COM 的序列化以及 Com Interaction 结合使用。 |
| 支撑材料 | – |
⌊(RS_Main_01003, RS_Main_00140)
2.2.46 命名约定(Naming conventions)
⌈[RS_SYST_00053] 系统模板应提供为公共符号定义命名约定的能力⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应提供为公共符号定义命名约定的能力。这尤其包括需求 ID、模块缩写、发布文档中使用的元数据和配置符号。 |
| 理由 | 避免规范内部的歧义和名称冲突;向规范读者提供一致、统一的元数据呈现。 |
| 用例 | 允许自动处理规范元素。 |
| 依赖 | – |
| 支撑材料 | – |
⌊(RS_Main_00500)
请注意:系统模板本身并不定义具体的命名约定。
2.2.47 支持 Secured Pdus
⌈[RS_SYST_00054] 支持 Secured Pdus⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持 Secured Pdu 的定义。 |
| 理由 | 应能定义一个附加了额外身份验证信息(Authentication Information)的 Pdu。 |
| 依赖 | – |
| 用例 | 防止 Pdu 受到未授权的篡改和重放攻击。 |
| 支撑材料 | – |
⌊(RS_Main_00510)
2.2.48 支持 Container Pdus
⌈[RS_SYST_00055] 支持 Container Pdus⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板应支持 Container Pdu 的定义。 |
| 理由 | 应能定义一个 Container Pdu,用于传输多个被包含的 Pdu。 |
| 依赖 | – |
| 用例 | 将 Pdu 从一个网络路由到具有更高有效负载能力的网络(例如从 CAN 路由到 CAN FD 或 Ethernet)。 |
| 支撑材料 | – |
⌊(RS_Main_00026)
2.2.49 E2E 保护通信
⌈[RS_SYST_00056] E2E 保护通信⌋
| 属性 | 值 |
|---|---|
| 类型 | 有效(valid) |
| 描述 | 系统模板必须涵盖通过 E2E 的通信保护。 |
| 理由 | 支持在非安全相关通信总线上进行安全相关通信。 |
| 依赖 | – |
| 用例 | 开发一个完整的多网络车内电子架构。 |
| 支撑材料 | – |
⌊(RS_Main_00010)
2.2.50 将通信图分配给特定的 RTE Implementation Plug-Ins
⌈[RS_SYST_00057] 将通信图分配给特定的 RTE Implementation Plug-Ins⌋
| 属性 | 值 |
|---|---|
| 类型 | 草案(draft) |
| 描述 | 系统模板应支持将软件组件的通信图分配给特定的 RTE Implementation Plug-Ins。 |
| 理由 | ECU 的 RTE 是通过 RTE Implementation Plug-Ins 模块化构建的。每个通信图由特定的 RTE Implementation Plug-In 处理。 |
| 依赖 | – |
| 用例 | – |
| 支撑材料 | – |
⌊(RS_Main_00060)
2.2.51 可选元素(Optional Elements)
⌈[RS_SYST_00058] 系统模板应支持在 SOME/IP 消息中使用 TLV 编码⌋
| 属性 | 值 |
|---|---|
| 类型 | 草案(draft) |
| 描述 | 系统模板应提供配置 SOME/IP transformer 的手段,使其根据系统模型考虑 TLV 编码。 |
| 理由 | 复合数据结构中可选元素的存在,在语义上不同于接收方在接收信息不包含复合数据结构的相应子元素时简单地取初始值。接收方应主动确认某些信息缺失这一事实,并仍能以有意义的方式应对这一情况。 |
| 用例 | 在 VFB 上定义并使用符合 TLV 编码条件的复合数据结构进行通信。配置用于该复合数据结构的 SOME/IP transformer 需要考虑 TLV 编码规范。 |
| 依赖 | – |
| 支撑材料 | – |
⌊(RS_Main_00280)
3 变更历史(Change History)
3.1 AUTOSAR 4.0.1 相对于 3.1.5 的变更历史
3.1.1 已移除的 SRS 条目
| 编号 | 标题 |
|---|---|
| [RS_SYST_00004] | Variant Handling(变体处理) |
| [RS_SYST_00005] | Timing Requirements(时序需求) |
表 3.1:4.0.1 中已移除的规范条目
3.1.2 已变更的 SRS 条目
| 编号 | 标题 |
|---|---|
| [RS_SYST_00001] | Mixed Systems (AUTOSAR/NON-AUTOSAR)(混合系统) |
| [RS_SYST_00007] | Mapping of Software Components to ECUs(软件组件到 ECU 的映射) |
表 3.2:4.0.1 中已变更的规范条目
3.1.3 已新增的 SRS 条目
| 编号 | 标题 |
|---|---|
| [RS_SYST_00027] | ECU Extract generation rules(ECU Extract 生成规则) |
| [RS_SYST_00028] | IPdu End-to-End Communication Protection support(IPdu 端到端通信保护支持) |
| [RS_SYST_00029] | Dynamic length signals(动态长度信号) |
| [RS_SYST_00030] | Dynamic length IPdus(动态长度 IPdu) |
| [RS_SYST_00031] | Distribution of Application and Vehicle Mode Requests(应用和车辆模式请求的分发) |
| [RS_SYST_00032] | Topology variants(拓扑变体) |
| [RS_SYST_00033] | Software-to-ECU mapping variants(软件到 ECU 映射变体) |
| [RS_SYST_00034] | Timing variants(时序变体) |
| [RS_SYST_00035] | Data mapping variants(数据映射变体) |
| [RS_SYST_00036] | Communication variants(通信变体) |
| [RS_SYST_00037] | Timing properties(时序属性) |
| [RS_SYST_00038] | Support of SAE J1939 Protocol Features(支持 SAE J1939 协议特性) |
| [RS_SYST_00039] | ECU Communication via Ethernet(ECU 通过 Ethernet 通信) |
| [RS_SYST_00040] | Timing constraints(时序约束) |
| [RS_SYST_00041] | Variants in ECU Extract(ECU Extract 中的变体) |
表 3.3:4.0.1 中已新增的规范条目
3.2 AUTOSAR 4.0.2 相对于 4.0.1 的变更历史
3.2.1 已移除的 SRS 条目
N/A
3.2.2 已变更的 SRS 条目
N/A
3.2.3 已新增的 SRS 条目
N/A
3.3 AUTOSAR 4.0.3 相对于 4.0.2 的变更历史
3.3.1 已移除的 SRS 条目
N/A
3.3.2 已变更的 SRS 条目
N/A
3.3.3 已新增的 SRS 条目
| 编号 | 标题 |
|---|---|
| [RS_SYST_00042] | Support for Partial Networking(支持部分联网) |
表 3.4:4.0.3 中已新增的规范条目
3.4 AUTOSAR 4.1.1 相对于 4.0.3 的变更历史
3.4.1 已移除的 SRS 条目
N/A
3.4.2 已变更的 SRS 条目
N/A
3.4.3 已新增的 SRS 条目
3.4.4 已新增的 SRS 条目
| 编号 | 标题 |
|---|---|
| [RS_SYST_00043] | Communication via Complex Device Drivers(通过 Complex Device Drivers 通信) |
| [RS_SYST_00044] | Description of custom bus systems(自定义总线系统的描述) |
| [RS_SYST_00045] | Co-existing System artifacts in the same model(同一模型中共存的系统工件) |
| [RS_SYST_00046] | Different views on the system's SWC-structure(系统 SWC 结构的不同视图) |
| [RS_SYST_00047] | Network and physical representation on signal level(信号层级的网络和物理表示) |
| [RS_SYST_00048] | CAN with Flexible Data-Rate(支持 CAN FD) |
表 3.5:4.1.1 中已新增的规范条目
3.5 AUTOSAR 4.1.1 相对于 4.1.2 的变更历史
3.5.1 已移除的 SRS 条目
N/A
3.5.2 已变更的 SRS 条目
N/A
3.5.3 已新增的 SRS 条目
N/A
3.6 AUTOSAR 4.1.2 相对于 4.2.1 的变更历史
3.6.1 已移除的 SRS 条目
N/A
3.6.2 已变更的 SRS 条目
| 编号 | 标题 |
|---|---|
| [RS_SYST_00014] | Data Segmentation(数据分段) |
表 3.6:4.2.1 中已变更的规范条目
3.6.3 已新增的 SRS 条目
| 编号 | 标题 |
|---|---|
| [RS_SYST_00049] | Support of Efficient COM for large data configuration(支持用于大数据配置的 Efficient COM) |
| [RS_SYST_00050] | Data transformation of inter-ECU communication(ECU 间通信的数据转换) |
| [RS_SYST_00051] | Support of COM Based Data Transformation(支持基于 COM 的数据转换) |
| [RS_SYST_00052] | Ethernet Switch Configuration(Ethernet 交换机配置) |
| [RS_SYST_00053] | Naming conventions(命名约定) |
| [RS_SYST_00054] | Support of Secured Pdus(支持 Secured Pdus) |
| [RS_SYST_00055] | Support of Container Pdus(支持 Container Pdus) |
| [RS_SYST_00056] | E2E-protected communication(E2E 保护通信) |
表 3.7:4.2.1 中已新增的规范条目
3.7 AUTOSAR 4.2.1 相对于 4.2.2 的变更历史
3.7.1 已移除的 SRS 条目
N/A
3.7.2 已变更的 SRS 条目
N/A
3.7.3 已新增的 SRS 条目
N/A
3.8 AUTOSAR 4.2.2 相对于 4.3.0 的变更历史
3.8.1 4.3.0 中已新增的可追溯项
无
3.8.2 4.3.0 中已变更的可追溯项
无
3.8.3 4.3.0 中已删除的可追溯项
| 编号 | 标题 |
|---|---|
| [RS_SYST_00010] | Exclusive Mapping of SWCs(SWC 排他性映射) |
| [RS_SYST_00011] | Dedicated Mapping of SWCs(SWC 专用映射) |
表 3.8:4.3.0 中已删除的可追溯项
3.9 AUTOSAR 4.3.0 相对于 4.3.1 的变更历史
3.9.1 4.3.1 中已新增的可追溯项
无
3.9.2 4.3.1 中已变更的可追溯项
无
3.9.3 4.3.1 中已删除的可追溯项
无
3.10 AUTOSAR 4.3.1 相对于 4.4.0 的变更历史
3.10.1 4.4.0 中已新增的可追溯项
| 编号 | 标题 |
|---|---|
| [RS_SYST_00057] | Assigning communication graphs to particular RTE Implementation Plug-Ins(将通信图分配给特定的 RTE Implementation Plug-Ins) |
| [RS_SYST_00058] | The System Template shall support the usage of the TLV encoding in SOME/IP messages(系统模板应支持在 SOME/IP 消息中使用 TLV 编码) |
表 3.9:4.4.0 中已新增的可追溯项
3.10.2 4.4.0 中已变更的可追溯项
无
3.10.3 4.4.0 中已删除的可追溯项
无
翻译说明
- 本文档为 AUTOSAR 系统模板需求(RS_SYST)的完整中文翻译,包含全部 51 条系统模板需求条目(RS_SYST_00001 至 RS_SYST_00058,其中部分为预留编号)。
- AUTOSAR 方框符
⌈⌋用于标识需求块的起止。 - 需求 ID(如
RS_SYST_00006、RS_Main_00010)保持英文。 - 通信协议名(CAN、LIN、MOST、FlexRay、Ethernet、CAN FD、I2C、USB、SAE J1939、SOME/IP 等)保持英文。
- 关键术语(ECU Extract、Communication Matrix、FIBEX、E2E、TLS、TLV、Complex Drivers、Partial Networking、Secure Onboard Communication、OEM、BSW、RTE、IPdu、IPDU、E2E、IPdu End-to-End、End-to-End、System Extract、Variant、postbuild、LittleEndian、BigEndian、OEM、Transformer、Transformer Chain、Serial Line 等)保持英文。
- 文档间交叉引用(如 [RS_Main_00010]、[RS_METH_00077] 等)保持英文原样。
- 文档变更历史完整翻译并按版本号倒序排列。