汽车安全开发必读：面向真实汽车应用的安全完整性等级与基础软件约束研究

汽车电子控制单元（ECU）是由数百项独立功能、大量软件组件及多项相互依赖任务构成的复杂系统。这类系统中普遍存在所谓因果链（cause‑effect chains）结构模式。目前已有大量研究针对因果链的时序分析与优化展开，尤其聚焦于最小化数据时效与功能响应时延，但其余关键非功能属性仍研究不足。

其中，安全完整性等级（SIL）分级通过决定任务同核部署策略，对系统设计产生重大影响。不同安全等级的功能若不合理共享、任务相互交织，会损害关键功能的完整性。此外，AUTOSAR 基础软件（BSW）（如操作系统、运行时环境、通信协议栈、诊断模块等）带来的系统复杂度，会随任务特征与安全完整性等级类别产生差异。

与此同时，内存需求是另一大核心难题：内存架构类型多样，且安全完整性等级存在专属依赖关系，极大限制了任务分配方案。本文基于一款实际车用应用开展全面特征建模，分析受安全完整性等级约束的车用应用特性、基础软件带来的影响以及内存资源需求，并引入 Driverator 配置框架，用于可扩展的系统分析。 

1 引言

近年来，随着多应用集成、高级驾驶辅助功能落地，以及 ISO 26262 等功能安全标准对架构严苛性的强制要求，汽车电子控制单元（ECU）的复杂度大幅提升。

现代汽车电子控制单元内部集成数十至数百个互联软件组件（SW-C），设计过程受各类非功能需求约束，包括时序、内存，以及尤为关键的安全完整性等级（SIL）。安全完整性等级通过对功能同核部署、任务分配、内存隔离施加严格限制，直接左右架构设计决策。在异构硬件架构中，不同内核与内存区域的安全属性各不相同，若在任务整合时未合理区分安全等级，将严重破坏系统完整性，引发重大安全风险与资源低效问题。

此外，车用软件体系高度依赖行业标准，以 AUTOSAR 标准为代表，提供操作系统、运行时环境（RTE）、通信协议栈、诊断服务等基础软件组件。这类组件虽为系统提供核心底层支撑，却也客观增加了整体复杂度与资源开销。基础软件带来的性能影响随功能属性、安全完整性等级分级而变化，使得软件架构与系统性能之间形成复杂的耦合关系。

因果链是车用软件中典型设计范式，它将任务按数据流顺序串联，实现从传感器输入到执行器输出的完整链路。因果链承载核心功能通路，数据在多任务间流转，且各任务往往具备不同执行周期。因果链设计的核心是端到端时序，必须控制在预设阈值内，以满足数据时效约束、保障服务质量。数据时效约束定义了时序数据传播的最大允许时长：从链路首个任务读取输入，到末端任务输出结果的全过程需在限定时间内完成。将安全完整性等级约束与因果链设计相结合，会进一步提升整体设计复杂度，软硬件映射时需审慎规划软件组件与基础软件的部署方案。 

本文重点研究安全完整性等级分级与基础软件对汽车系统架构的影响，旨在挖掘两类核心设计要素的关联规律，并聚焦设计早期阶段开展研究。在设计初期，系统功能范围与技术规范虽已确定，但各团队通常独立负责不同功能、软件组件与基础软件模块，尚未完成向具体硬件平台的集成映射。对照文中图 1 的 V 模型，本文研究聚焦 V 模型左侧，面向设计早期具备高影响力的架构决策环节。

图1 根据高亮标注的 V 模型阶段，提取对应的应用层与基础软件特征参数。 

尽管目前针对汽车系统与因果链的研究已较为丰富，涵盖特征建模、时序分析、调度策略等方向；同时混合关键级系统领域也已有大量研究成果（如 Burns 和 Davis 的综述 [4]）用于解决任务设计不确定性问题，但仍存在明显研究空白：现有案例研究未将安全等级、基础软件、内存需求作为核心设计要素统筹考量。

本文后面还基于一款实际车用运动与驱动系统开展案例研究，量化分析安全完整性等级约束、基础软件开销与内存资源需求，通过详实统计数据填补研究空白。相关研究结论可为仿真测试系统构建提供真实参考，也为后续相关研究奠定基础。

2 车用应用体系

依据 AUTOSAR 汽车系统架构框架，平台架构自上而下分为：应用层、运行时环境（RTE）、基础软件层及底层微控制器。车用软件以组件化架构搭建，软件组件（SW-C）部署于应用层。

原子级软件组件需依据 ISO 26262 标准划分专属汽车安全完整性等级（ASIL）。每个软件组件包含一个或多个可运行实体，分为初始化调用型与周期调用型两类。可运行实体遵循 AUTOSAR 时序规范完成调度，以周期触发作为激活方式；实体间通过发送 - 接收通信、客户端 - 服务端调用实现交互，交互过程由运行时环境统一调度管控。

AUTOSAR 基础软件（BSW）包含服务层、ECU 抽象层、微控制器抽象层、复杂驱动层四大类别，涵盖操作系统、运行时环境、通信协议栈、诊断服务等核心功能模块。基础软件引入的系统复杂度，会随不同安全等级（ASIL）下的任务特征产生差异化表现，且每个基础软件组件均包含大量系统级可运行实体。

通常，激活模式相同的可运行实体映射至同一任务，同一系统内可存在多个同激活模式任务。任务在操作系统中按固定优先级调度，采用非抢占式执行、高优先级任务可抢占机制。所有任务主要按固定周期时间同步触发，或由特定事件随机激活。 

3 从基准抽象到 Driverator 框架的研究方法

为保护知识产权（IP），本文对车用应用基准采用抽象化建模，不披露具体功能细节与实测对应的软件资源预算精确数值。在此前提下，通过威布尔分布等统计方法推导案例规范参数，并给出与原始基准的相关系数，构建合规可用的研究案例。

本文研究聚焦开发早期的系统设计可行性，建模不依赖实测数据，基于严格边界约束采用保守时序预算；基础软件仅提供粗略设计规范，时序信息匮乏，细节将在后续实现阶段完善。针对这一痛点，本文提出抽象建模思路，基于历史开发经验预估基础软件的潜在性能影响。整体而言，应用系统的核心指标由安全完整性等级、基础软件、内存资源三大维度共同耦合决定。

本文从受知识产权约束的实际车用应用出发，经规范化抽象建模，形成第 4 章可公开使用的研究案例，整体流程如图 2 所示。团队开发了 Driverator 系统配置与生成工具，可无知识产权限制地复现案例中的应用架构。Driverator 框架支持跨平台扩展，可集成时序分析与系统优化能力。

图 2 基于实际车用应用、无知识产权约束的规范化抽象建模方法总览 

4 案例研究：实车驱动系统中的安全完整性等级、基础软件与内存需求

本章以一款开发早期的车用运动与驱动控制器为研究对象，分析其应用架构特征。

4.1 应用软件特征

表 1 汇总了软件组件（SW-C）的核心属性，包含各安全等级占比、只读内存（ROM）与随机存取内存（RAM）的取值区间，整体特征与基准模型相关系数为 0.5174。

表 1 软件组件属性

软件组件总数由功能设计与底层平台共同决定。单个软件组件内置初始化可运行实体与周期可运行实体，激活周期可相同或不同；软件组件与可运行实体强绑定、不可拆分，每个软件组件为所属全部可运行实体统一划定汽车安全完整性等级。

表 2 给出周期可运行实体的时序预算严格边界，相关系数 0.4322，包含常规运行周期、最坏执行时间（WCET）区间、占比及适配安全等级。可运行实体主要为时间同步周期触发，也可由特定事件随机激活。

表 2 应用层可运行实体特征

4.2 基于因果链的通信架构

周期可运行实体之间通过实体间通信实现交互。表 3 为通信矩阵：行代表发送端可运行实体周期、列代表接收端周期，箭头标识同周期 / 跨周期实体间通信关系，同周期实体交互频次最高（标色高亮）。可运行实体内置读写标识以实现通信交互，根据任务分配方式，抽象建模可分为任务内通信与任务间通信。 

表3可运行实体内部的通信矩阵

结合通信调度范式，系统以因果链为核心架构。关键因果链由具备一种或多种激活模式的应用层可运行实体组成，且分布于不同任务中；每条因果链包含 1~3 种激活模式，由 2~18 个不同安全等级的可运行实体构成。因果链数量由整车功能与底层平台决定，不同链路可复用公共可运行实体，表 4 为因果链配置参数。

表 4 因果链配置

每条因果链内部，可运行实体与所属任务按预设顺序调度执行，必须满足端到端时延约束。数据时效区间由链路超周期的1.8~4.9倍系数界定。任务主要随周期时间同步激活，也可由特殊事件触发，支持抢占式与协作式两种调度模式。

4.3 基础软件的影响分析

整车功能持续扩容，使得应用软件与 AUTOSAR 基础软件的交互频次显著提升。基础软件的资源开销涵盖运行时环境、通信协议栈、操作系统、诊断服务等模块。研究表明，安全与非安全软件并行占比提升会带来运行时开销与复杂度上升，可通过基础软件分区部署优化缓解该问题。

表 5 含基础软件扩展的任务属性

设计早期暂无基础软件实测参数，因此本文基于应用任务结构，采用统计方法拟合基础软件开销。表 5 展示不同可运行实体数量对应的任务基础软件占比，整体相关系数 0.5042。规律表明：单个任务内聚合的周期可运行实体越多，基础软件交互开销越低。基础软件扩展比例可量化额外最坏执行时间开销，开销大小取决于同安全等级下任务内可运行实体最坏执行时间的累加规模，最终需核算扩展执行时长以评估系统利用率。

表 6 基础软件任务时序预算属性

为支撑基础软件核心业务，系统按离散安全等级配置专属基础软件任务，分为周期调用与随机调用两类。表 6 为周期型基础软件任务特征，相关系数 0.4189。应用任务集集成的基础软件扩展模块越多，通信等业务所需独立基础软件任务越少。

现代多核微控制器中，整套基础软件包含约 6000 个系统级可运行实体，单个基础软件任务最多可承载 200 个系统可运行实体。对比十年前发动机控制器仅 1500 个可运行实体的规模，可见车载系统架构复杂度大幅提升。此外，基础软件只读内存资源按锁步内核统计，单内核占用区间为 634~1258KB，会挤占硬件可用内存容量。

5 设计挑战

汽车软件开发在早期设计阶段面临多重难题：

1. 初期仅能获取无实测值的非功能规范，只能采用保守时序预算建模，尽可能贴近后期实测边界；

2. 基础软件规范处于设计初稿阶段，缺乏详细参数与实测数据，难以在早期评估其时序与内存开销；

3. 为满足功能安全标准 [7]，可运行实体向任务映射时需严格保障时空无干扰隔离；

4. 任务设计需同时满足各可运行实体、因果链的时序要求，且任务自身调度约束不可违背，形成多核架构下的架构设计两难问题。

需满足的核心设计约束如下：

1.       R1 每个可运行实体唯一绑定至带隐式截止时间的周期任务，单个任务可容纳多个可运行实体；任务采用分区固定优先级调度。

2.       R2 任务聚合与合并需保持安全等级隔离、保留因果链上下文，并严格遵循数据时效约束（后续建模为联合时延约束）。

3.       R3 同一软件组件的所有可运行实体必须部署于同一内核，且不得超出单内核只读内存 / 随机内存容量上限。

4.       R4 基础软件开销建模分为两类：任务本地扩展开销、带单内核内存阈值的全局基础软件任务开销。

此外，车用实时系统软件开发仍存在若干值得深入研究的方向：

1. 建立设计早期预算边界与后期实测最坏执行时间的精准映射模型；

2. 面向端到端时延约束，设计承载上百个系统可运行实体的专属基础软件因果链；

3. 精准分析锁步 / 非锁步异构硬件平台，对多核系统中受安全等级约束因果链的影响规律。

6 结论

本文研究表明：在设计早期阶段主动纳入安全完整性等级、基础软件、内存资源三类约束，可显著提升系统架构的合理性与鲁棒性。同时，本文提出车用应用基准的抽象建模方法，构建 Driverator 基准框架，支持多系统配置下的可扩展分析。

通过实车案例研究，本文给出了基于安全与时序约束的任务分配、内存部署优化思路，论证了在开发全生命周期早期，将非功能约束作为核心设计要素统筹考量的重要价值。