软件功能安全 ASIL D(Software Functional Safety)
本质 wiki 里硬件安全(电流/电压/位置/温度/驱动诊断)讲了 80%,但 inverter 项目的另一半 ASIL D 软件几乎没专门写过。软件安全和硬件 SM 的逻辑完全不同——软件没有"随机失效率",所有 fault 都是 systematic(代码 bug + 流程缺陷),所以 ISO 26262-6 用 预防 + 检测 + 工具链合规 三层来论证软件 ASIL D。本页讲清:why 软件安全是"全过程合规"而非"算个数字"、ASIL D 软件 V&V 的 4 层结构(单元/集成/SW Q/系统)、MC/DC 覆盖率为什么是 ASIL D 必备、AUTOSAR Classic vs Adaptive 的安全 stack 差异、工具链 Tessy/LDRA 的 qualification 角色、coding guideline(MISRA C 2023)的强制项。
学习目标
读完本页后,你应该能够:
- 解释为什么"软件没有 FIT 数字" + ASIL D 软件靠"全过程合规"论证
- 说出 ISO 26262-6 的软件 V&V 4 层结构(SWE.1~SWE.6 对应)
- 区分 statement / branch / MC/DC 三种代码覆盖率,以及 ASIL A/B/C/D 各要求哪种
- 说出 AUTOSAR Classic 安全 stack 的 5 个核心模块(WdgM / E2E / SecOC / FCcore / Stack monitor)
- 区分 AUTOSAR Adaptive 和 Classic 在 ASIL 论证上的不同
- 解释工具链 qualification(TCL1/2/3)的判据,以及 Tessy/LDRA 为什么必须 qualified
- 列出 MISRA C 2023 的 8 个 ASIL D 必须遵守的 critical rule
- 识别软件安全 5 个反模式
1. 为什么软件安全和硬件完全不是一回事
硬件 ASIL D 的核心问题是 管随机失效率 —— FIT × DC 加权算 SPFM/LFM/PMHF。软件没有 FIT —— 一段代码要么有 bug 要么没有,bug 不会"以 100 FIT 概率出现",它要么 100% 在某条件下触发要么 0%。所以软件 ASIL D 的论证逻辑完全反过来——靠预防 bug 的产生(流程 + 工具)+ 检测残留 bug(测试 + 静态分析)+ 运行时兜底(WdgM / Stack monitor / Memory protection)。
关键认知:软件没有"安全数字" —— assessor 看的是"你怎么证明这段代码不会出系统性 bug"。证据 = 流程合规记录 + 测试覆盖率 + 工具 qualification 报告 + 评审记录。
2. ISO 26262-6 的 V&V 4 层结构
ISO 26262-6 把软件开发拆成 4 个层次,每层对应一组要求。和 ASPICE 的 SWE.1 ~ SWE.6 几乎一一对应:
| 层 | 26262-6 章节 | ASPICE | ASIL D 必做 |
|---|---|---|---|
| SW requirements | §6 | SWE.1 | requirements traceable to TSR + complete + non-ambiguous |
| SW architecture | §7 | SWE.2 | layered + partitioned + freedom from interference |
| SW unit design + impl | §8 | SWE.3 | coding guideline(MISRA)+ ≤ N cyclomatic complexity |
| SW unit test | §9 | SWE.4 | MC/DC ≥ 90% + boundary + error guess |
| SW integration test | §10 | SWE.5 | interface coverage + functional + non-functional |
| SW qualification test | §11 | SWE.6 | requirements coverage 100% + back-to-back vs sim |
少一层等于安全 case 缺一块论证 —— 单元测得再好,集成阶段没测接口仍可能漏 systematic bug。
3. 代码覆盖率 —— statement vs branch vs MC/DC
代码覆盖率是 ISO 26262-6 §9 单元测试的核心指标,ASIL 等级越高要求越严:
| 覆盖率 | 含义 | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|---|
| Statement | 每行代码至少跑过 | ✓ 推荐 | ✓ 强烈推荐 | - | - |
| Branch | 每个 if/else 两个分支都跑 | - | ✓ 推荐 | ✓ 强烈推荐 | - |
| MC/DC | 每个布尔条件独立影响结果至少一次 | - | - | ✓ 推荐 | ✓ 必须 ≥ 90% |
3.1 MC/DC 为什么是 ASIL D 的红线
考虑这段代码:
if (a && b && c) { do_x(); }
- Statement:跑一次 a=b=c=true 即覆盖
- Branch:跑 (true,true,true) + (false,,) 即覆盖两个分支
- MC/DC:必须证明每个变量(a/b/c)独立影响结果——至少 4 个测试用例:
- (T,T,T) → x
- (F,T,T) → not x(证明 a 影响)
- (T,F,T) → not x(证明 b 影响)
- (T,T,F) → not x(证明 c 影响)
MC/DC 抓的是"逻辑表达式有 bug 但其它条件掩盖了" —— 比如 a && b 写成 a || b,statement / branch 可能仍 100% 但功能错。ASIL D 必须 ≥ 90% MC/DC。
3.2 Tessy / LDRA 工具
工业上不可能手算 MC/DC 用例,要靠工具:
| 工具 | 厂商 | 角色 |
|---|---|---|
| Tessy | Razorcat | 单元测试自动生成 + MC/DC 测量 |
| LDRA | LDRA | 静态分析 + MC/DC + MISRA check 一体 |
| VectorCAST | Vector | 同 Tessy + 集成测试 |
| Polyspace | MathWorks | 形式化静态分析 + 运行时错误证明 |
这些工具本身必须 qualified —— 见 §6。
4. AUTOSAR Classic 安全 stack
AUTOSAR Classic 的 BSW 层提供了一组安全相关 module,ASIL D 项目几乎都用。下面 5 个是核心:
| Module | 功能 |
|---|---|
| WdgM(Watchdog Manager) | 软件层监控 task 执行,定时喂 SBC 硬件 watchdog |
| E2E(End-to-End Library) | 通信消息保护 — 详见 E2E + SecOC |
| SecOC(Secure Onboard Communication) | 通信加密 + 重放防护 |
| FCcore(Functional Cluster Core,即 OS) | 时间触发任务调度 + memory protection + interrupt isolation |
| Stack monitor + Memory monitor | 检测 stack overflow / memory corruption |
详见 安全机制目录 §6 通信级 SM。
4.1 WdgM 的 alive supervision
WdgM 监控的不是"task 还在跑没",而是 task 在期望时序内完成它的活:
WdgM 的 checkpoint 有 alive / deadline / logical 三种监控,组合用能盖住"task 卡死 / 提前完成 / 顺序错"。
5. AUTOSAR Adaptive 的不同
Adaptive(用于域控制器 / HPC,POSIX based)和 Classic 在安全论证上有两个本质差异:
| 维度 | Classic | Adaptive |
|---|---|---|
| OS | OSEK / 静态调度 | POSIX(Linux PREEMPT_RT) |
| 资源 | 静态分配,编译期决定 | 动态进程 + 容器 |
| 安全成熟度 | ✓ ASIL D 量产成熟 | △ 仅部分 ASIL B/C 量产 |
| 安全 stack | WdgM / E2E / SecOC | Adaptive Platform Health Mgmt + ara::com SecOC |
Adaptive 的 ASIL D 论证目前是个开放问题 —— POSIX Linux 内核本身没有 ASIL D 评估,通常做法是把 ASIL D 部分留在 Classic 上,Adaptive 只跑 ASIL B/QM 任务,通过 Mixed Criticality + virtualization 隔离两者。详见 整车 E/E 架构。
6. 工具链 Qualification —— TCL 1/2/3
ISO 26262-8 §11 要求"开发工具如果可能引入 fault 到 safety-related 软件,必须 qualified"。Tool Confidence Level(TCL):
| TCL | 含义 | 例 |
|---|---|---|
| TCL 1 | 工具 fault 可能导致软件 bug,且不容易被后续步骤检测到 | 编译器 (GCC), 静态分析工具 (LDRA) |
| TCL 2 | 同 TCL 1 但有部分检测兜底 | code review tool |
| TCL 3 | fault 影响小或一定能被后续检测 | text editor, version control |
ASIL D 项目的编译器 + 静态分析 + MC/DC tool 必须 TCL 1 qualified。商用工具(Tessy / LDRA / 认证版 GCC)厂商提供 qualification kit + safety manual,告诉你怎么使用 = 合规。自研 / 开源工具要自己做 qualification(很贵)。
7. MISRA C 2023 —— ASIL D 必守 critical rules
MISRA C 是 C 语言的安全编码 guideline,2023 版有 230+ rule(分 mandatory / required / advisory)。ASIL D 项目通常要求 mandatory + required 100% 合规(advisory 项目自定)。
下面 8 条是最常见的 critical(违反极易出 systematic bug):
| Rule | 内容 | 风险 |
|---|---|---|
| Dir 4.1 | 禁止运行时未定义行为(UB) | 整数 overflow / 移位负数 / 解引空指针 |
| R 8.13 | 指针参数 non-modifying 加 const | 防误改 |
| R 9.3 | 数组元素全初始化 | 未初始化数据 |
| R 11.3 | 禁止把对象指针 cast 到不同对齐的类型 | 未对齐访问 crash |
| R 13.1 | 初始化器表达式不应有副作用 | 求值顺序未定 |
| R 17.2 | 禁止递归 | stack overflow |
| R 17.7 | 函数返回值不可弃 | 错误码丢失 |
| R 21.6 | 不用 stdio.h(printf 等) | 安全等级 OS 不允许 |
LDRA / Tessy / Coverity 可以自动 check MISRA 合规,但项目通常还需要 deviation process —— 实在违反的某条要写 justification 让 safety officer 批。
8. Freedom from Interference(FFI)
ASIL D 软件不能被同一颗 MCU 上的 ASIL B/QM 软件干扰。三类干扰要分别防:
| 干扰类型 | 防护 |
|---|---|
| Memory | MPU / MMU 隔离地址空间 |
| Timing | 时间触发调度 + 严格 budget + WdgM |
| Resource | RTOS task priority 严格分级 + mutex 保护 |
举例:VCU 的 ASIL D 扭矩 monitor 和 ASIL QM 信息娱乐功能跑同一颗 MCU,必须 MPU 隔离两者地址空间 —— 否则 QM 任务的野指针写到 ASIL D 的 buffer 就违反 FFI。详见 汽车 MCU 的 lockstep 双核 + MPU。
9. Traceability —— 需求到测试的链
ASIL D 的硬性合规要求:每条 SW requirement 必须双向追踪到 TSR(系统需求)和 SW unit test。Tracebility matrix(IBM DOORS / Polarion / Codebeamer 维护):
TSR-001
└─ SR-XXX-1 → unit_test_xxx_1.c (passed)
└─ SR-XXX-2 → unit_test_xxx_2.c (passed)
└─ SR-XXX-3 → unit_test_xxx_3.c (passed)
任何 TSR 没下挂 SR,或 SR 没对应测试 = traceability gap = audit 失败。这就是为什么 ASPICE Level 2 的 work products 这么多——99% 都在维护这条 trace 链。
详见 ASPICE。
10. 安全反模式(5 个常见错)
| 反模式 | 表现 | 修法 |
|---|---|---|
| MC/DC 用 statement coverage 凑数 | "我们覆盖率 95%"——其实是 statement 不是 MC/DC | ASIL D 必须 MC/DC,不能用其它代替 |
| GCC 没 qualified 直接用 | 编译器 bug 引入 systematic 错,assessor 第一个打回 | 用 qualified compiler(认证版 GCC / IAR safety) |
| WdgM 只配 alive 监控 | task 卡 5ms 才触发,实际 ASIL D FTTI 只允许 2ms | 加 deadline + logical supervision |
| MISRA deviation 没 justification | 违反规则但没记录原因,审计直接 NCR | 每条 deviation 必须 safety officer 签字 |
| Adaptive 直接跑 ASIL D | POSIX Linux 内核未 qualified,论证失败 | ASIL D 留 Classic,Adaptive 仅跑 ASIL B 以下 |
核心要点
- 软件没有"安全数字" —— ASIL D 论证靠流程合规 + V&V 覆盖 + 工具 qualified 三件套
- ISO 26262-6 V&V 4 层(SWE.1 → SWE.6),每层都有 ASIL D 必做项,缺一审计败
- MC/DC ≥ 90% 是 ASIL D 红线 —— statement / branch 都不能替代,要 Tessy / LDRA 自动算
- AUTOSAR Classic 安全 stack 5 件套:WdgM + E2E + SecOC + FCcore + Stack/Memory monitor
- Adaptive 的 ASIL D 是开放问题 —— 通常 ASIL D 留 Classic,Adaptive 跑 B 以下,Mixed Criticality 隔离
- 工具 qualification(TCL 1)是硬要求 —— 编译器 / 静态分析 / MC/DC 工具必须商用 qualified 或自做(贵)
- MISRA C 2023 mandatory + required 100% 合规 + deviation 需 safety officer 签字
- Freedom from Interference:同 MCU 不同 ASIL 软件必须 MPU 隔离 + 时间隔离 + 资源隔离
- Traceability TSR → SR → unit test 双向链是 ASPICE Level 2 + ISO 26262-6 共同要求
- 5 反模式戒除:MC/DC 凑数 / GCC 没 qualify / WdgM 只 alive / MISRA 没 justification / Adaptive 跑 ASIL D