软件功能安全 ASIL D(Software Functional Safety)

功能安全L7别名 软件安全 · ASIL D 软件 · software safety · MC/DC 覆盖率 · Tessy · LDRA · AUTOSAR Classic · AUTOSAR Adaptive · 软件 traceability · Coding guideline MISRA

本质 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)。

Mermaid diagram

关键认知:软件没有"安全数字" —— assessor 看的是"你怎么证明这段代码不会出系统性 bug"。证据 = 流程合规记录 + 测试覆盖率 + 工具 qualification 报告 + 评审记录。


2. ISO 26262-6 的 V&V 4 层结构

ISO 26262-6 把软件开发拆成 4 个层次,每层对应一组要求。和 ASPICE 的 SWE.1 ~ SWE.6 几乎一一对应:

Mermaid diagram
26262-6 章节ASPICEASIL D 必做
SW requirements§6SWE.1requirements traceable to TSR + complete + non-ambiguous
SW architecture§7SWE.2layered + partitioned + freedom from interference
SW unit design + impl§8SWE.3coding guideline(MISRA)+ ≤ N cyclomatic complexity
SW unit test§9SWE.4MC/DC ≥ 90% + boundary + error guess
SW integration test§10SWE.5interface coverage + functional + non-functional
SW qualification test§11SWE.6requirements coverage 100% + back-to-back vs sim

少一层等于安全 case 缺一块论证 —— 单元测得再好,集成阶段没测接口仍可能漏 systematic bug。


3. 代码覆盖率 —— statement vs branch vs MC/DC

代码覆盖率是 ISO 26262-6 §9 单元测试的核心指标,ASIL 等级越高要求越严:

覆盖率含义ASIL AASIL BASIL CASIL 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 用例,要靠工具:

工具厂商角色
TessyRazorcat单元测试自动生成 + MC/DC 测量
LDRALDRA静态分析 + MC/DC + MISRA check 一体
VectorCASTVector同 Tessy + 集成测试
PolyspaceMathWorks形式化静态分析 + 运行时错误证明

这些工具本身必须 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 在期望时序内完成它的活:

Mermaid diagram

WdgM 的 checkpoint 有 alive / deadline / logical 三种监控,组合用能盖住"task 卡死 / 提前完成 / 顺序错"。


5. AUTOSAR Adaptive 的不同

Adaptive(用于域控制器 / HPC,POSIX based)和 Classic 在安全论证上有两个本质差异:

维度ClassicAdaptive
OSOSEK / 静态调度POSIX(Linux PREEMPT_RT)
资源静态分配,编译期决定动态进程 + 容器
安全成熟度✓ ASIL D 量产成熟△ 仅部分 ASIL B/C 量产
安全 stackWdgM / E2E / SecOCAdaptive 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 3fault 影响小或一定能被后续检测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 软件干扰。三类干扰要分别防:

干扰类型防护
MemoryMPU / MMU 隔离地址空间
Timing时间触发调度 + 严格 budget + WdgM
ResourceRTOS 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/DCASIL 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 DPOSIX 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

Cross-references