2. AUTOSAR安全相关标准与规范解读
在ETAS AUTOSAR安全软件开发体系中，ISO 26262与AUTOSAR安全手册构成了两条并行的约束主线：前者定义“必须达到什么安全目标”，后者回答“在AUTOSAR软件架构中如何实现这些目标”。理解二者的分工与衔接，是后续安全机制设计、安全需求分解和验证活动的前提。
ISO 26262对软件开发的约束
ISO 26262将软件视为安全相关系统的一部分，其约束并非只落在编码阶段，而是贯穿软件安全生命周期。对软件开发最直接的影响体现在三个方面：ASIL等级决定开发严格度、安全需求必须可追溯、验证与确认活动必须与ASIL匹配。
ASIL由严重度S、暴露率E和可控性C三个参数通过查表确定，分为A、B、C、D四个等级，D级要求最严。软件层面，ASIL等级直接影响：需求分解的粒度、架构设计的独立性要求、代码静态分析规则、单元测试覆盖率目标以及工具置信度。例如，ASIL D通常要求语句覆盖、分支覆盖和MC/DC覆盖，而ASIL A仅要求语句覆盖和分支覆盖。下表给出软件层面常见的ASIL相关约束示例（示例参数，用于教学说明）：
| 活动 | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|
| 语句覆盖 | 要求 | 要求 | 要求 | 要求 |
| 分支覆盖 | 要求 | 要求 | 要求 | 要求 |
| MC/DC覆盖 | 不要求 | 不要求 | 推荐 | 要求 |
| 需求追溯 | 双向 | 双向 | 双向 | 双向+形式化 |
此外，ISO 26262-6对软件架构提出了“分区与隔离”的要求：安全相关软件与非安全相关软件应尽量分离，避免非安全软件失效传播到安全相关功能。在AUTOSAR中，这一要求通常通过内存保护、时间保护、OS-Application隔离以及BSW模块的分层部署来实现。
AUTOSAR安全手册的定位
AUTOSAR安全手册（Safety Manual）不是替代ISO 26262，而是将ISO 26262的安全要求“翻译”为AUTOSAR平台可执行的机制与假设。它主要提供三类内容：
- 安全机制清单：如E2E保护、CRC校验、看门狗、内存保护、程序流监控、时钟监控等，并说明每种机制覆盖的失效模式。
- 使用假设（Assumptions of Use, AoU）：明确BSW模块在何种配置和使用条件下才能满足安全目标，例如E2E Profile必须与SWC端配置一致。
- 安全需求分解指引：将整车或系统级安全目标逐层分配到AUTOSAR软件组件、BSW和MCU抽象层。
在ETAS工具链中，安全手册的内容通常以安全机制库、配置约束和验证用例的形式落地。例如，ETAS RTA系列BSW在配置E2E时，会要求选择Profile（如Profile 1、Profile 2、Profile 4、Profile 5、Profile 6、Profile 7、Profile 11、Profile 22），并明确Data ID、CRC类型和计数器范围。这些参数不是随意选取，而是由安全手册中对应AoU约束的。
安全机制与安全需求分解方法
安全需求分解的核心逻辑是：从安全目标出发，识别失效模式，选择安全机制，再将机制要求分配到具体的软件元素，并定义验证判据。以“防止CAN通信数据被篡改或丢失”为例，其分解路径可以概括为：
- 安全目标：确保安全相关信号在传输过程中不被静默篡改或丢失。
- 失效模式：数据损坏、数据丢失、数据重复、数据延迟、数据插入。
- 安全机制：E2E保护（CRC + 计数器 + Data ID）、超时监控、冗余传输。
- 需求分配：发送端SWC调用E2E Protect，接收端SWC调用E2E Check；BSW提供CRC和计数器支持。
- 验证判据：注入单比特错误、计数器跳变、Data ID错误，接收端必须在规定周期内检测并上报。
在具体实现中，E2E Profile 1的CRC使用8位多项式0x1D，计数器为4位，Data ID为16位。发送端每周期将计数器加1，接收端检查计数器是否在预期窗口内。若连续丢失超过阈值，则判定为通信失效。以下是一个简化的E2E检查逻辑示例（示例代码，用于说明判断过程）：
/* 示例：E2E Profile 1 接收端检查逻辑 */
status = E2E_P01Check(&Config, &State, &Data);
if (status == E2E_P01STATUS_OK) {
/* 数据有效，交给应用层 */
} else if (status == E2E_P01STATUS_WRONGCRC) {
/* CRC错误，记录故障 */
} else if (status == E2E_P01STATUS_LOST) {
/* 计数器跳变，判定丢失 */
} else if (status == E2E_P01STATUS_REPEATED) {
/* 重复数据，按策略处理 */
}
安全需求分解不是一次性活动，而是与架构设计迭代进行。每分配一条需求，都要同步定义其验证方法、通过准则和失败处理。在ETAS ISOLAR中，这些需求通常以需求ID、ASIL等级、关联的SWC/BSW模块、验证用例ID的形式记录，形成可追溯矩阵。
从图中可以看出，ISO 26262提供的是“约束边界”，AUTOSAR安全手册提供的是“机制工具箱”，而安全需求分解则是把两者连接起来的工程活动。在ETAS工具链中，这一过程通常借助ISOLAR的需求管理、RTA-BSW的配置约束和E2E库的验证用例共同完成。实际项目中，建议先建立安全目标与ASIL的对应关系，再逐条识别失效模式并选择安全手册中已定义的安全机制，最后将机制参数（如E2E Profile、CRC多项式、计数器位宽、超时阈值）固化到配置文件中，并同步生成验证用例。这样既能保证需求可追溯，也能避免安全机制被错误配置或遗漏。