System Template Requirements
参考文献¶
AUTOSAR_CP_TPS_SystemTemplate
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_RS_Main
[4] IEEE Standard 1722-2016 - IEEE Standard for a Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks
https://standards.ieee.org/ieee/1722/4279/
1. 文档范围¶
本文档收集对系统模板（System Template，SYS-T）的需求。系统模板的主要目标是定义系统的纯软件视图与带有联网 ECU 的物理系统架构之间的关系。
系统模板涵盖以下领域：
- 系统拓扑：在系统拓扑中描述系统的逻辑布局。也就是说，记录哪个 ECU 连接到哪个簇（cluster）或信道（channel）。
- 通信属性：通信系统的中心目的是交换具有特定属性的帧。
- 映射：映射涵盖软件组件到 ECU 的分配，以及要在软件组件之间交换的数据元素到信号和帧的映射。
本文档中收集的需求将由系统模板规范 [1] 满足。该文档实现了本文所述的大部分需求。
1.1. 文档约定¶
AUTOSAR 文档中需求的表示遵循 TPS_STDT_00078 所规定的表格，参见标准模板（Standardization Template）的「追溯支持」（Support for Traceability）一章（[2]）。
应使用 TPS_STDT_00053 中规定的用于表达义务的助动词形式来表示需求，参见标准模板（Standardization Template）的「追溯支持」（Support for Traceability）一章（[2]）。
2. 需求¶
2.1. 类别：主要需求¶
2.1.1. AUTOSAR 模板之间的兼容性¶
兼容性（Compatibility between the AUTOSAR Templates）
| 描述 | 必须保证 AUTOSAR 各模板之间的兼容性。在此语境下，兼容性意味着每个 AUTOSAR 模板都可以包含对另一个 AUTOSAR 模板元素的引用。 |
|---|---|
| 理由 | 确保 AUTOSAR 各模板之间的连贯性和互操作性。 |
| 依赖项 | 未识别到。 |
| 用例 | 使用同一工具链开发车载电子架构（软件建模、硬件建模和映射约束建模）。 |
| 支撑材料 | - |
2.2. 类别：系统模板需求¶
2.2.1. 传统系统¶
混合系统（AUTOSAR/非 AUTOSAR）（Mixed Systems (AUTOSAR/NON-AUTOSAR)）
| 描述 | 因使用混合系统而产生的系统约束，必须由系统模板处理。 |
|---|---|
| 理由 | 从非 AUTOSAR 系统到全 AUTOSAR 系统的过渡只能逐步实现。此外，必须确保与传统解决方案的互操作性。因此，必须允许 AUTOSAR ECU 和非 AUTOSAR ECU 同时存在于同一系统（「混合」系统）中。 |
| 依赖项 | 未识别到。 |
| 用例 | 在既有架构中逐步引入 AUTOSAR，例如，应可以处理并非源自 AUTOSAR 软件组件的信号。 |
| 支撑材料 | - |
2.2.2. 基础软件与 RTE 资源¶
基础软件资源与 RTE 资源（Basic Software Resources and RTE Resources）
| 描述 | 系统模板必须涵盖基础软件和 RTE 的资源请求。 |
|---|---|
| 理由 | ECU 的资源就其自身定义而言是有限的（RAM、ROM、CPU 时间等）。这些限制在映射过程中充当约束。 |
| 依赖项 | 未识别到。 |
| 用例 | 在小型 ECU 上分配 AUTOSAR 服务和特性时考虑存储器限制。 |
| 支撑材料 | - |
2.2.3. 迭代式开发¶
迭代式开发（Iterative Development）
| 描述 | 系统模板必须支持迭代的系统开发。 |
|---|---|
| 理由 | 在 AUTOSAR 系统的开发过程中，系统设计过程前几个步骤中找到的解决方案本身会成为后续系统生成步骤的系统约束。 |
| 依赖项 | 未识别到。 |
| 用例 | 如果在开发的后期阶段向车辆项目添加新功能，当前的映射本身会成为与新功能相关的新软件组件映射的约束。 |
| 支撑材料 | - |
2.2.4. 软件组件到 ECU 的映射¶
软件组件到 ECU 的映射（Mapping of Software Components to ECUs）
| 描述 | 系统模板必须描述软件组件到 ECU 的映射。还应可以可选地将软件组件映射到一个 ECU 内的各个处理单元。 |
|---|---|
| 理由 | - |
| 依赖项 | 未识别到。 |
| 用例 | 出于安全原因（或仅仅凭经验），某些特定的软件组件只能运行在特定的 ECU 上。这种「预映射」是实际映射过程的约束。 |
| 支撑材料 | - |
2.2.5. 软件组件到 ECU 的映射：聚簇¶
SWC 簇（SWC Cluster）
| 描述 | 系统约束描述必须涵盖软件组件的聚簇。软件组件聚簇意味着两个软件组件不可拆分，必须映射到同一个 ECU。 |
|---|---|
| 理由 | 由于性能需求、安全通信需求或仅仅凭经验，必须防止某些通信路径被映射到外部总线上。此时涉及的软件组件应一起映射到同一个 ECU。 |
| 依赖项 | 未识别到。 |
| 用例 | 不能经由通信总线进行的安全通信，或非常严格的时序要求。 |
| 支撑材料 | - |
2.2.6. 软件组件到 ECU 的映射：分离¶
SWC 分离（SWC Separation）
| 描述 | 系统约束描述必须涵盖软件组件的分离。软件组件分离意味着两个软件组件不能位于同一个 ECU 上。 |
|---|---|
| 理由 | 增强冗余 SWC 的独立性。 |
| 依赖项 | 未识别到。 |
| 用例 | 出于安全需求，实现安全关键功能的两个冗余软件组件不会一起映射到同一个 ECU 上（当然，冗余并不总是意味着 SWC 分离）。 |
| 支撑材料 | - |
2.2.7. 拓扑描述¶
拓扑（Topology）
| 描述 | 系统模板必须描述 EE 系统的拓扑。 |
|---|---|
| 理由 | 可用的通信路径限制了软件组件到某些 ECU 的可能分布。 |
| 依赖项 | 未识别到。 |
| 用例 | 从功能角度紧密关联的软件组件的映射：此时必须了解拓扑，以避免过长的数据路径。 |
| 支撑材料 | - |
2.2.8. 数据分段¶
数据分段（Data Segmentation）
| 描述 | 系统模板必须提供可用于将（应用）数据分段到多于 1 个帧的信息。 |
|---|---|
| 理由 | 底层总线技术的数据长度限制。 |
| 依赖项 | 未识别到。 |
| 用例 | 诊断数据的传输，其长度通常超过特定总线的最大帧大小。 |
| 支撑材料 | - |
2.2.9. 总线带宽¶
总线带宽（Bus bandwidth）
| 描述 | 系统模板应支持带宽计算，作为通信矩阵（Communication Matrix）定义的约束。 |
|---|---|
| 理由 | 带宽是有限资源，在通信矩阵的定义过程中充当约束。 |
| 依赖项 | 未识别到。 |
| 用例 | 为混合系统（AUTOSAR 和非 AUTOSAR ECU）定义通信矩阵时，只有通信矩阵的一部分可以通过 AUTOSAR 流程自由配置。这意味着 AUTOSAR 系统生成器的可用带宽受通信矩阵中非 AUTOSAR 部分的限制。 |
| 支撑材料 | - |
2.2.10. 专用物理连接¶
专用物理连接（Dedicated physical connections）
| 描述 | 系统约束描述应能够描述信号必须经由一条专用线路发送的情况，该线路仅由两个软件组件（发送方和接收方）使用。 |
|---|---|
| 理由 | 该技术当前的安全概念中被普遍使用。 |
| 依赖项 | 未识别到。 |
| 用例 | 与安全气囊模块的通信。 |
| 支撑材料 | - |
2.2.11. 将信号映射到同一物理线路¶
将信号映射到同一物理线路（Mapping of signals to the same physical line）
| 描述 | 系统约束描述应能够描述一组信号必须经由同一物理线路发送。 |
|---|---|
| 理由 | - |
| 依赖项 | 未识别到。 |
| 用例 | - |
| 支撑材料 | - |
2.2.12. 将信号映射到不同物理线路¶
将信号映射到不同物理线路（Mapping of signals to different physical lines）
| 描述 | 系统约束描述应能够在需要时描述 ECU 之间的信号经由不同的物理线路发送。 |
|---|---|
| 理由 | 支持硬件和信息冗余（作为支持故障检测和故障处理的手段）。 |
| 依赖项 | 未识别到。 |
| 用例 | 保证非常关键安全数据传输的一种手段，是强制将冗余副本发送到不同的物理线路上。 |
| 支撑材料 | - |
2.2.13. 将信号映射到特定物理线路¶
将信号映射到特定物理线路（Mapping of signals to a specific physical line）
| 描述 | 系统约束描述应能够描述信号必须映射到特定的物理线路。 |
|---|---|
| 理由 | 由于特殊的性能和/或安全需求，某些信号必须映射到特定的物理线路。 |
| 依赖项 | 未识别到。 |
| 用例 | 动力总成信号由于其时序要求，必须映射到高速总线。 |
| 支撑材料 | - |
2.2.14. 将信号排除在特定物理线路之外¶
将信号排除在特定物理线路之外（Exclusion of signals from a specific physical line）
| 描述 | 系统约束描述应能够描述信号不得映射到特定的物理线路。 |
|---|---|
| 理由 | 某些物理线路可能不适合（太慢、通信协议不安全等）传输某些特定信号。 |
| 依赖项 | 未识别到。 |
| 用例 | 由于时序要求，大多数动力总成信号不能映射到低速 CAN 总线。 |
| 支撑材料 | - |
2.2.15. 经由 CAN 的 ECU 通信¶
经由 CAN 的 ECU 通信（ECU Communication via CAN）
| 描述 | 系统模板必须涵盖经由 CAN 总线的系统通信。 |
|---|---|
| 理由 | CAN 在汽车系统中被广泛使用。 |
| 依赖项 | 未识别到。 |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
2.2.16. 经由 LIN 的 ECU 通信¶
经由 LIN 的 ECU 通信（ECU Communication via LIN）
| 描述 | 系统模板必须涵盖经由 LIN 的系统通信。 |
|---|---|
| 理由 | LIN 在汽车系统中被广泛使用。 |
| 依赖项 | 未识别到。 |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
2.2.17. 经由 MOST 的 ECU 通信¶
经由 MOST 的 ECU 通信（ECU Communication via MOST）
| 描述 | 系统模板必须涵盖经由 MOST 的系统通信。 |
|---|---|
| 理由 | MOST 正在成为汽车行业的标准通信协议。 |
| 依赖项 | 未识别到。 |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
2.2.18. 经由 FlexRay 的 ECU 通信¶
经由 FlexRay 的 ECU 通信（ECU Communication via FlexRay）
| 描述 | 系统模板必须涵盖经由 FlexRay 的系统通信。 |
|---|---|
| 理由 | FlexRay 正在成为汽车行业的标准通信协议。 |
| 依赖项 | 未识别到。 |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
2.2.19. 从系统模板推导 COM 栈配置参数¶
从系统模板推导 COM 栈配置参数（Derivation of COM Stack Configuration Parameters from the System Template）
| 描述 | 系统模板应支持配置 ECU 的 Com 栈。它处理描述 ECU 间通信所必需的那些参数。ECU 本地的配置参数不在系统模板的范围之内。 |
|---|---|
| 理由 | 连接在一个通信簇中的所有 ECU 需要一致地配置。 |
| 依赖项 | 未识别到。 |
| 用例 | 从 ECU 提取（ECU Extract）生成基础 ECU 配置。 |
| 支撑材料 | - |
2.2.20. ASAM FIBEX 兼容性¶
FIBEX 兼容性（Fibex compatibility）
| 描述 | 每当系统模板与 ASAM FIBEX 标准存在显著重叠时，系统模板应采用 ASAM FIBEX 标准的结构。 |
|---|---|
| 理由 | FIBEX 作为一个已被验证的成熟标准，系统模板将从中受益。 |
| 依赖项 | 未识别到。 |
| 用例 | 便于将系统模板引入处理 FIBEX 标准的现有工具中。 |
| 支撑材料 | ASAM FIBEX |
2.2.21. ECU 提取生成规则¶
ECU 提取生成规则（ECU Extract generation rules）
| 描述 | ECU 提取从系统描述推导得出。生成 ECU 提取的规范应足够详细，以支持对该产物进行语义上无歧义的生成。 |
|---|---|
| 理由 | 工具互操作性要求对 ECU 提取的无歧义描述。 |
| 依赖项 | 未识别到。 |
| 用例 | 从 ECU 提取生成基础 ECU 配置。 |
| 支撑材料 | - |
2.2.22. IPdu 端到端通信保护支持¶
IPdu 端到端通信保护支持（IPdu End-to-End Communication Protection support）
| 描述 | 系统模板应支持为 IPdu 选择 E2E 保护设置。 |
|---|---|
| 理由 | 保护 COM 模块之间的通信。 |
| 依赖项 | 未识别到。 |
| 用例 | 在无冗余的单个信道上传输安全相关数据。 |
| 支撑材料 | - |
2.2.23. 动态长度信号¶
动态长度信号（Dynamic length signals）
| 描述 | 系统模板应支持动态长度信号的定义。信号应具有静态长度，或其长度应在某个静态定义的最大值内变化。具有最大长度的信号称为动态长度信号。 |
|---|---|
| 理由 | 动态长度信号可以在运行期间改变大小。 |
| 依赖项 | 未识别到。 |
| 用例 | - |
| 支撑材料 | OSEK COM |
2.2.24. 动态长度 IPdu¶
动态长度 IPdu（Dynamic length IPdus）
| 描述 | 系统模板应支持包含动态长度信号的 IPdu 的定义。 |
|---|---|
| 理由 | 动态长度 IPdu 可以在运行期间改变大小。 |
| 依赖项 | §2.2.23.1 |
| 用例 | 网络层和数据链路层能够按照交互层（Interaction Layer）的决定收发固定长度和动态长度的 I-Pdu。 |
| 支撑材料 | OSEK COM |
2.2.25. 应用模式请求与整车模式请求的分发¶
应用模式请求与整车模式请求的分发（Distribution of Application and Vehicle Mode Requests）
| 描述 | 系统模板应支持将应用模式请求和整车模式请求分发到所有受影响的 ECU。 |
|---|---|
| 理由 | 模式请求者（Mode Requester）是通过带有模式请求接口（Mode Request interface）的端口发送某些数据、从而向模式管理器（Mode Manager）请求模式的实体。模式管理器接收传入的信息，对请求进行仲裁，并决定最终的模式。 |
| 依赖项 | 未识别到。 |
| 用例 | 根据整车模式和应用模式，BSW 模式可能发生变化，例如某个应用的通信需求可能导致通信网络的 BSW 模式发生变化。 |
| 支撑材料 | - |
2.2.26. 拓扑变体¶
拓扑变体（Topology variants）
| 描述 | 系统模板应提供描述拓扑变体的方法，包括可选/备选的 ECU 和通信簇。 |
|---|---|
| 理由 | 在产品线方法中，不同的产品变体可以通过一个共同的核心拓扑实现，只有少量拓扑节点不同。 |
| 依赖项 | 未识别到。 |
| 用例 | 在一条产品线中，两个不同的产品变体 HIGH 和 LOW 使用相同的核心拓扑，区别在于产品变体 HIGH 需要一个额外的 ECU。 |
| 支撑材料 | - |
2.2.27. 软件到 ECU 映射变体¶
软件到 ECU 映射变体（Software-to-ECU mapping variants）
| 描述 | 系统模板应提供描述软件组件到 ECU 的备选映射的方法。 |
|---|---|
| 理由 | 为了使产品线中的产品获得整体系统的不同特定特性，需要使用不同的软件组件映射。 |
| 依赖项 | §2.2.4.1、§2.2.5.1、§2.2.6.1、§2.2.7.1 |
| 用例 | 在一条产品线中，两个不同的产品变体 HIGH 和 LOW 使用相同的软件架构，但定义了不同的网络拓扑映射。 |
| 支撑材料 | - |
2.2.28. 时序变体¶
时序变体（Timing Variants）
| 描述 | 系统模板应提供描述备选时序属性（例如触发类型、周期、优先级）和时序约束（例如延迟、数据龄期）的方法。 |
|---|---|
| 理由 | 由于软件到 ECU 映射的不同，信号传输的时序属性和约束可能不同。 |
| 依赖项 | 未识别到。 |
| 用例 | 某个 PDU 在两个不同的产品变体 HIGH 和 LOW 中周期传输，变体 HIGH 的周期为 10ms，变体 LOW 的周期为 20ms。 |
| 支撑材料 | - |
2.2.29. 数据映射变体¶
数据映射变体（Data mapping variants）
| 描述 | 系统模板应提供描述数据映射变体的方法。 |
|---|---|
| 理由 | 软件组件描述中的变体会影响系统模板中所描述的数据映射。 |
| 依赖项 | 未识别到。 |
| 用例 | 某个数据元素仅存在于产品变体 HIGH 中。 |
| 支撑材料 | - |
2.2.30. 通信变体¶
通信变体（Communication variants）
| 描述 | 系统模板应提供描述通信变体的方法，例如备选的信号到 PDU 映射、备选的通信路径，以及备选的信号和 PDU 属性（例如数据类型、数据长度）。 |
|---|---|
| 理由 | 为了针对使用同一网络拓扑的不同产品变体优化通信矩阵，在系统模板中描述通信变体是一个必不可少的前提。 |
| 依赖项 | §2.2.26.1、§2.2.29.1 |
| 用例 | 某个信号在两个不同的产品变体 HIGH 和 LOW 中传输，变体 HIGH 使用字节序 LittleEndian，变体 LOW 使用字节序 BidEndian。 |
| 支撑材料 | - |
2.2.31. 时序属性¶
时序属性（Timing properties）
| 描述 | 系统模板应提供描述系统动态时序属性的方法，这些属性由计算、通信和其他硬件资源的消耗决定。 |
|---|---|
| 理由 | 在系统模板中描述时序属性，是在流程早期分析和验证系统时序行为或对其进行预测的必不可少的前提。 |
| 依赖项 | 未识别到。 |
| 用例 | 时序行为的分析与验证、修改影响的早期预测、硬件规格（dimensioning）支持、系统配置优化。 |
| 支撑材料 | - |
2.2.32. 支持 SAE J1939 协议特性¶
支持 SAE J1939 协议特性（Support of SAE J1939 Protocol Features）
| 描述 | 系统模板必须涵盖经由 SAE J1939 的系统通信。 |
|---|---|
| 理由 | SAE J1939 协议是汽车系统中使用的行业标准。 |
| 依赖项 | 未识别到。 |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
2.2.33. 经由以太网的 ECU 通信¶
经由以太网的 ECU 通信（ECU Communication via Ethernet）
| 描述 | 系统模板必须涵盖经由以太网的系统通信。 |
|---|---|
| 理由 | 以太网正在成为汽车行业的标准通信协议。 |
| 依赖项 | 未识别到。 |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
以太网交换机配置（Ethernet Switch Configuration）
| 描述 | 以太网交换机配置应提供标准化的产物，用于描述出端口（egress port）的结构、端口调度机制以及交换机内部的转发过程。可以写入交换机的公共参数（例如在初始化阶段）需要集成到系统描述中。 |
|---|---|
| 理由 | 交换机内部消息的时序行为取决于交换机的配置。因此，需要描述交换机的行为。 |
| 依赖项 | - |
| 用例 | 提供以太网拓扑的描述，包括交换机及其行为的模型。 |
| 支撑材料 | - |
2.2.34. 时序约束¶
时序约束（Timing constraints）
| 描述 | 系统模板应提供描述系统动态时序约束的方法，这些约束由计算、通信和其他硬件资源的消耗决定。 |
|---|---|
| 理由 | 在系统模板中描述时序约束，是在流程早期分析和验证系统时序行为或对其进行预测的必不可少的前提。 |
| 依赖项 | 未识别到。 |
| 用例 | 时序行为的分析与验证、修改影响的早期预测、硬件规格支持、系统配置优化。 |
| 支撑材料 | - |
2.2.35. ECU 提取中的变体¶
ECU 提取中的变体（Variants in ECU Extract）
| 描述 | ECU 提取应支持从系统描述转换时引入或推导的元素的可变性。 |
|---|---|
| 理由 | 数据映射和通信变体（见 §2.2.29.1、§2.2.30.1）可能必须保留在从系统描述生成的产物（例如 ECU 提取）中，如果绑定时间位于流程的较后阶段。 |
| 依赖项 | 未识别到。 |
| 用例 | Pdu 布局在 ECU 配置期间是 post-build 可配置的，可变性需要在构建时可见。 |
| 支撑材料 | - |
2.2.36. 支持局部网络¶
支持局部网络（Support for Partial Networking）
| 描述 | 系统模板应支持局部网络簇（partial network cluster）的定义、虚拟功能簇到局部网络簇的映射以及各个 ECU 的唤醒信息。系统模板应定义关于局部网络拓扑设计的约束。应明确定义受支持和不受支持的局部网络拓扑，以确保正确的 PNC 处理。 |
|---|---|
| 理由 | 系统模板应包含配置局部网络所需的全部系统相关参数。 |
| 依赖项 | 未识别到。 |
| 用例 | 描述系统级局部网络簇向量的大小和位置。对多个顶层 PNC 协调器的存在建模。对所选信道上 PNC 的协调建模。 |
| 支撑材料 | - |
2.2.37. 经由复杂驱动程序的通信¶
经由复杂驱动程序的通信（Communication via Complex Drivers）
| 描述 | 系统模板应支持经由复杂驱动程序（Complex Driver）的基于 Pdu 的通信。 |
|---|---|
| 理由 | 应可以描述通过网络传输的复杂驱动程序 Pdu。 |
| 依赖项 | 未识别到。 |
| 用例 | 在 PduR 之上使用一个新的 BSW 模块，例如诊断服务。 |
| 支撑材料 | - |
2.2.38. 自定义总线系统的描述¶
自定义总线系统的描述（Description of custom bus systems）
| 描述 | 系统模板应支持在拓扑层面集成自定义总线系统。 |
|---|---|
| 理由 | 应可以通过一份系统描述描述车辆的完整网络拓扑。 |
| 依赖项 | 未识别到。 |
| 用例 | 备选的通信技术（例如 I2C、USB、串行线路）作为复杂驱动程序集成。 |
| 支撑材料 | - |
2.2.39. 同一模型中共存的系统产物¶
同一模型中共存的系统产物（Co-existing System artifacts in the same model）
| 描述 | 系统模板应提供描述不同系统提取（System Extract）的方法，这些系统提取可以与完整的系统描述以及彼此在同一模型中共存。 |
|---|---|
| 理由 | - |
| 依赖项 | 未识别到。 |
| 用例 | OEM 将一个系统提取作为正式的「需求」规范交给供应商。供应商对该系统提取进行扩展和重构。在下一个开发周期中，OEM 将更新后的系统提取交给供应商。供应商根据 OEM 的更新来更新自己的系统提取。 |
| 支撑材料 | RS_METH_00077 |
2.2.40. 系统 SWC 结构的不同视图¶
系统 SWC 结构的不同视图（Different views on the system's SWC-structure）
| 描述 | 系统模板应提供描述 SWC 结构的不同视图及其元素之间映射的方法。 |
|---|---|
| 理由 | - |
| 依赖项 | 未识别到。 |
| 用例 | OEM 处对 SWC 结构的不同视图：功能视图（独立于 ECU）和 ECU 拓扑视图。 |
| 支撑材料 | RS_METH_00078、RS_METH_00079 |
2.2.41. 信号层面的网络表示与物理表示¶
信号层面的网络表示与物理表示（Network and physical representation on signal level）
| 描述 | 系统模板应提供描述信号的物理表示和网络表示的方法。 |
|---|---|
| 理由 | - |
| 依赖项 | 未识别到。 |
| 用例 | - |
| 支撑材料 | - |
2.2.42. 具有可变数据速率的 CAN¶
具有可变数据速率的 CAN（CAN with Flexible Data-Rate）
| 描述 | 系统模板应支持 CAN FD 协议。 |
|---|---|
| 理由 | CAN FD 提高了 CAN 网络的带宽，并允许大于 8 字节的有效载荷。 |
| 依赖项 | 未识别到。 |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
2.2.43. 支持大数据配置的高效 COM¶
支持大数据配置的高效 COM（Support of Efficient COM for large data configuration）
| 描述 | 系统模板应支持通过面向大数据的高效 COM（Efficient COM for large data）进行通信的配置。 |
|---|---|
| 理由 | 面向大数据的高效 COM 提供了一种精简的机制来处理 RTE 与通信栈的交互。但如果要通过面向大数据的高效 COM 进行这种交互，需要满足一些前提条件。系统模板应定义这些前提条件。 |
| 依赖项 | - |
| 用例 | 只包含一个信号且未定义特殊传输模式的 IPdu 可以由面向大数据的高效 COM 处理。 |
| 支撑材料 | - |
2.2.44. ECU 间通信的数据转换¶
ECU 间通信的数据转换（Data transformation of inter-ECU communication）
| 描述 | 系统模板应提供描述 ECU 间通信数据转换的方法。 |
|---|---|
| 理由 | 如果要对 ECU 间通信的数据进行转换，必须在系统内对其进行配置，以使发送和接收 ECU 能够执行该数据转换。 |
| 依赖项 | 未识别到。 |
| 用例 | 大型复合数据应一次性映射到总线通信，以避免对复合数据的每个原子元素分别映射。 |
| 支撑材料 | - |
2.2.45. 支持基于 COM 的数据转换¶
支持基于 COM 的数据转换（Support of COM Based Data Transformation）
| 描述 | 系统模板应提供规定使用 uint8 数组 API 将复合数据的序列化表示传递给 COM 模块的方法。 |
|---|---|
| 理由 | AUTOSAR 转换器链提供了将复合数据序列化为 uint8 数组表示的方法。该序列化的 uint8 数组应一次性传递给 COM。 |
| 依赖项 | - |
| 用例 | 使用带 COM 序列化的转换器和 Com 交互，以支持与运行 AUTOSAR R4.1 及更早版本的 ECU 通信。 |
| 支撑材料 | - |
2.2.46. 基于信号的通信与面向服务的通信之间的转换¶
系统模板应支持基于信号的通信与面向服务的通信之间的转换。（The System Template shall support the translation between signal-based and service-oriented communication.）
| 描述 | 系统模板应支持基于信号的通信与面向服务的通信之间的转换。 |
|---|---|
| 理由 | 自适应平台（Adaptive Platform）将通信限制为面向服务的通信，而车辆的其他部分仍使用基于信号的通信方式——因此必须对这两种方式进行转换。 |
| 依赖项 | 作为备选方案，该转换也可以在自适应平台上实现。 |
| 用例 | 在 CAN ECU 上产生的数据需要以安全且保密的方式在自适应机器上使用。该转换可以在经典平台的网关 ECU 上实现。 |
| 支撑材料 | - |
2.2.47. 命名约定¶
系统模板应提供定义公共符号命名约定的能力（The System Template shall provide the ability to define naming conventions for public symbols）
| 描述 | 系统模板应提供定义公共符号命名约定的能力。这尤其包括发布版文档中使用的需求 ID、模块缩写、元数据和配置符号。 |
|---|---|
| 理由 | 避免规范内部的歧义和命名冲突。向规范的读者提供一致、统一的元数据呈现。允许对规范元素进行自动处理。 |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
请注意，系统模板并不定义具体的命名约定。
2.2.48. 支持受保护的 Pdu¶
支持受保护的 Pdu（Support of Secured Pdus）
| 描述 | 系统模板应支持受保护 Pdu（Secured Pdu）的定义。 |
|---|---|
| 理由 | 应可以定义一个补充了附加认证信息（Authentication Information）的 Pdu。 |
| 依赖项 | - |
| 用例 | 保护 Pdu 免遭未授权篡改和重放攻击。 |
| 支撑材料 | - |
2.2.49. 支持容器 Pdu¶
支持容器 Pdu（Support of Container Pdus）
| 描述 | 系统模板应支持容器 Pdu（Container Pdu）的定义。 |
|---|---|
| 理由 | 应可以定义一个容器 Pdu 承载多个被包含的 Pdu。 |
| 依赖项 | - |
| 用例 | 将 Pdu 从一个网络路由到具有更高有效载荷能力的网络（例如从 CAN 到 CanFD 或以太网）。 |
| 支撑材料 | - |
2.2.50. E2E 保护的通信¶
E2E 保护的通信（E2E-protected communication）
| 描述 | 系统模板必须涵盖经由 E2E 的通信保护。 |
|---|---|
| 理由 | 支持在非安全相关的通信总线上进行安全相关的通信。 |
| 依赖项 | - |
| 用例 | 开发完整的多网络车载电子架构。 |
| 支撑材料 | - |
2.2.51. 将通信图分配给特定的 RTE 实现插件¶
将通信图分配给特定的 RTE 实现插件（Assigning communication graphs to particular RTE Implementation Plug-Ins）
| 描述 | 系统模板应支持将软件组件的通信图（communication graph）分配给特定的 RTE 实现插件（RTE Implementation Plug-In）。 |
|---|---|
| 理由 | ECU 的 RTE 以模块化方式使用 RTE 实现插件构建。每个通信图由一个特定的 RTE 实现插件处理。 |
| 依赖项 | - |
| 用例 | - |
| 支撑材料 | - |
2.2.52. 可选元素¶
系统模板应支持在 SOME/IP 消息中使用 TLV 编码（The System Template shall support the usage of the TLV encoding in SOME/IP messages）
| 描述 | 系统模板应提供配置 SOME/IP 转换器以按照系统模型考虑 TLV 编码的方法。 |
|---|---|
| 理由 | 复合数据结构中可选元素的存在，在语义上不同于「接收方在收到的信息不包含复合数据结构的相应子元素时简单地采用初始值」。接收方应主动确认某些信息缺失这一事实，并仍能有意义地处理这种情况。 |
| 依赖项 | - |
| 用例 | 定义一个符合 TLV 编码条件的复合数据结构并将其用于 VFB 上的通信。为该复合数据结构配置的 SOME/IP 转换器需要考虑 TLV 编码的规范。 |
| 支撑材料 | - |
2.2.53. 软件簇¶
系统模板应支持软件簇的建模（The System Template shall support the modeling of Software Clusters）
| 描述 | 系统模板应提供定义由 AUTOSAR 软件组件和基础软件模块组成的软件簇（Software Cluster）的方法。 |
|---|---|
| 理由 | 复杂的 ECU 可以在结构上分解为软件簇。每个软件簇的开发、集成和构建都独立于所属 ECU 的外围宿主系统。 |
| 依赖项 | - |
| 用例 | 不同的开发合作伙伴负责特定的软件簇。每个开发合作伙伴都能够独立地将其软件簇部署到 ECU 上，并保持该 ECU 上其余软件不变。 |
| 支撑材料 | - |
2.2.54. 软件簇与环境的交互¶
系统模板应提供描述软件簇二进制对象接口的方法（The System Template shall provide means to describe the interface of the Software Clusters binary object）
| 描述 | 系统模板应提供描述软件簇二进制对象接口的方法。 |
|---|---|
| 理由 | 访问软件簇内部所定义资源所需的信息应在接口描述中定义。 |
| 依赖项 | - |
| 用例 | 建立软件簇之间的连接。 |
| 支撑材料 | - |
2.2.55. 软件簇资源¶
系统模板应支持软件簇资源的建模（The System Template shall support the modeling of Software Cluster Resources）
| 描述 | 系统模板应支持软件簇资源（Software Cluster Resource）的建模。 |
|---|---|
| 理由 | 软件簇能够提供可被其他软件簇访问的资源，并能够使用其他软件簇的资源。 |
| 依赖项 | - |
| 用例 | - |
| 支撑材料 | - |
2.2.56. 以太网 IEEE1722Tp 流支持¶
以太网 IEEE1722Tp 流支持（Ethernet IEEE1722Tp Stream support）
| 描述 | 系统模板应支持按照 IEEE Std 1722-2016 [4] 对流（stream）进行建模。 |
|---|---|
| 理由 | 对流、流的提供者和流的消费者进行配置。 |
| 依赖项 | - |
| 用例 | 定义 IEEE1722Tp 流的存在以及谁在产生和消费这些流。提供关于每个流内容的信息，以支持带宽计算。 |
| 支撑材料 | - |
2.2.57. 以太网交换机过滤与管制¶
以太网交换机过滤与管制（Ethernet Switch Filtering and Policing）
| 描述 | 系统模板应支持以太网交换机过滤（Filtering）与管制（Policing）。 |
|---|---|
| 理由 | 这些机制可用于避免突发流量、限制「胡言乱语者」（babbling idiots）并防止拒绝服务攻击。 |
| 依赖项 | - |
| 用例 | 确保关键应用的带宽。 |
| 支撑材料 | IEEE Std 802.1Q-2018, section Qci 8.6 |
3. 变更历史¶
3.1. AUTOSAR 4.0.1 相对于 3.1.5 的变更历史¶
3.1.1. 移除的 SRS 项¶
表3.1：4.0.1 中移除的规范项
| 标题 |
|---|
| 变体处理 |
| 时序需求 |
3.1.2. 变更的 SRS 项¶
表3.2：4.0.1 中变更的规范项
| 标题 |
|---|
| 混合系统（AUTOSAR/非 AUTOSAR） |
| 软件组件到 ECU 的映射 |
3.1.3. 新增的 SRS 项¶
表3.3：4.0.1 中新增的规范项
| 标题 |
|---|
| ECU 提取生成规则 |
| IPdu 端到端通信保护支持 |
| 动态长度信号 |
| 动态长度 IPdu |
| 应用模式请求与整车模式请求的分发 |
| 拓扑变体 |
| 软件到 ECU 映射变体 |
| 时序变体 |
| 数据映射变体 |
| 通信变体 |
| 时序属性 |
| 支持 SAE J1939 协议特性 |
| 经由以太网的 ECU 通信 |
| 时序约束 |
| ECU 提取中的变体 |
3.2. AUTOSAR 4.0.2 相对于 4.0.1 的变更历史¶
3.2.1. 移除的 SRS 项¶
无
3.2.2. 变更的 SRS 项¶
无
3.2.3. 新增的 SRS 项¶
无
3.3. AUTOSAR 4.0.3 相对于 4.0.2 的变更历史¶
3.3.1. 移除的 SRS 项¶
无
3.3.2. 变更的 SRS 项¶
无
3.3.3. 新增的 SRS 项¶
表3.4：4.0.3 中新增的规范项
| 标题 |
|---|
| 支持局部网络 |
3.4. AUTOSAR 4.1.1 相对于 4.0.3 的变更历史¶
3.4.1. 移除的 SRS 项¶
无
3.4.2. 变更的 SRS 项¶
无
3.4.3. 新增的 SRS 项¶
表3.5：4.1.1 中新增的规范项
| 标题 |
|---|
| 经由复杂设备驱动程序的通信 |
| 自定义总线系统的描述 |
| 同一模型中共存的系统产物 |
| 系统 SWC 结构的不同视图 |
| 信号层面的网络表示与物理表示 |
| 具有可变数据速率的 CAN |
3.5. AUTOSAR 4.1.1 相对于 4.1.2 的变更历史¶
3.5.1. 移除的 SRS 项¶
无
3.5.2. 变更的 SRS 项¶
无
3.5.3. 新增的 SRS 项¶
无
3.6. AUTOSAR 4.1.2 相对于 4.2.1 的变更历史¶
3.6.1. 移除的 SRS 项¶
无
3.6.2. 变更的 SRS 项¶
表3.6：4.2.1 中变更的规范项
| 标题 |
|---|
| 数据分段 |
3.6.3. 新增的 SRS 项¶
表3.7：4.2.1 中新增的规范项
| 标题 |
|---|
| 支持大数据配置的高效 COM |
| ECU 间通信的数据转换 |
| 支持基于 COM 的数据转换 |
| 以太网交换机配置 |
| 命名约定 |
| 支持受保护的 Pdu |
| 支持容器 Pdu |
| E2E 保护的通信 |
3.7. AUTOSAR 4.2.1 相对于 4.2.2 的变更历史¶
3.7.1. 移除的 SRS 项¶
无
3.7.2. 变更的 SRS 项¶
无
3.7.3. 新增的 SRS 项¶
无
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 中删除的需求¶
表3.8：4.3.0 中删除的可追溯项
| 标题 |
|---|
| SWC 的独占映射 |
| SWC 的专用映射 |
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 中新增的需求¶
表3.9：4.4.0 中新增的需求
| 标题 |
|---|
| 将通信图分配给特定的 RTE 实现插件 |
| 系统模板应支持在 SOME/IP 消息中使用 TLV 编码 |
3.10.2. 4.4.0 中变更的需求¶
无
3.10.3. 4.4.0 中删除的需求¶
无
3.11. AUTOSAR 4.4.0 相对于 19-11 的变更历史¶
3.11.1. 19-11 中新增的需求¶
表3.10：19-11 中新增的需求
| 标题 |
|---|
| 系统模板应支持基于信号的通信与面向服务的通信之间的转换。 |
3.11.2. 19-11 中变更的需求¶
无
3.11.3. 19-11 中删除的需求¶
无
3.12. AUTOSAR R19-11 相对于 R20-11 的变更历史¶
3.12.1. R20-11 中新增的需求¶
表3.11：R20-11 中新增的需求
| 标题 |
|---|
| 系统模板应支持软件簇的建模 |
| 系统模板应提供描述软件簇二进制对象接口的方法 |
| 系统模板应支持软件簇资源的建模 |
3.12.2. R20-11 中变更的需求¶
无
3.12.3. R20-11 中删除的需求¶
无
3.13. AUTOSAR R20-11 相对于 R21-11 的变更历史¶
3.13.1. R21-11 中新增的需求¶
无
3.13.2. R21-11 中变更的需求¶
无
3.13.3. R21-11 中删除的需求¶
无
3.14. AUTOSAR R21-11 相对于 R22-11 的变更历史¶
3.14.1. R22-11 中新增的需求¶
无
3.14.2. R22-11 中变更的需求¶
表3.12：R22-11 中变更的需求
| 标题 |
|---|
| 支持局部网络 |
3.14.3. R22-11 中删除的需求¶
无
3.15. AUTOSAR R22-11 相对于 R23-11 的变更历史¶
3.15.1. R23-11 中新增的需求¶
表3.13：R23-11 中新增的需求
| 标题 |
|---|
| 以太网 IEEE1722Tp 流支持 |
| 以太网交换机过滤与管制 |
3.15.2. R23-11 中变更的需求¶
无
3.15.3. R23-11 中删除的需求¶
无