3. 系统级安全概念：安全目标定义、功能安全概念、技术安全概念、系统架构设计

好，咱们进入系统级安全概念这一块。说实话，这是整个功能安全落地的核心环节。很多工程师觉得安全就是写文档，其实不是。安全概念定义得好不好，直接决定了后续开发是顺风顺水，还是到处填坑。

我个人习惯把系统级安全概念分成四个递进的层次：安全目标 → 功能安全概念 → 技术安全概念 → 系统架构设计。一层层往下细化，就像剥洋葱一样。

3.1 安全目标定义

安全目标是什么？说白了，就是「这辆车绝对不能出现什么情况」。它来源于危害分析和风险评估（HARA），是顶层安全要求。

举个例子，我参与过一个L3级高速领航项目。HARA分析下来，有一个典型危害：「车辆在高速行驶时，自动紧急制动系统误触发」。这个危害的ASIL等级是C级。对应的安全目标就是：「避免非预期的自动紧急制动」，ASIL C。

定义安全目标时，有几个坑要注意：

• 目标要可验证：不能写「系统要足够安全」，要写「系统在xx条件下，误触发概率低于xx」。
• ASIL等级要准确：我见过有人把ASIL B的误判成ASIL D，结果后面设计冗余度太高，成本翻倍。
• 每个安全目标只对应一个危害：别把多个危害揉到一个目标里，后面追溯会乱。

3.2 功能安全概念

安全目标定好了，接下来要回答一个问题：「系统怎么实现这些安全目标？」 这就是功能安全概念（FSC）要做的事。

功能安全概念是系统层面的安全措施。它不涉及具体硬件或软件实现，只描述「什么功能」来保证安全。

我习惯把功能安全概念拆成三块：

1. 故障检测机制：比如「监控模块每10ms检查一次制动指令是否异常」。
2. 故障响应机制：比如「检测到异常后，系统在100ms内切换到降级模式」。
3. 故障容错机制：比如「主控制器失效时，备份控制器接管」。

嗯，这里要注意。功能安全概念要分配到系统元素上。比如，安全目标SG-001「避免非预期的纵向加速」，对应的功能安全概念可能是：

• 「感知模块输出车速和障碍物信息」
• 「决策模块根据安全距离计算目标加速度」
• 「执行模块对加速度指令进行合理性校验」

每个元素都要明确它的安全职责。我曾经在一个项目中，因为功能安全概念写得不够细，导致感知团队和决策团队互相推诿——「这个安全机制到底谁负责？」 后来我们花了整整两周才理清楚。

3.3 技术安全概念

功能安全概念是「做什么」，技术安全概念（TSC）就是「怎么做」。它把功能安全概念细化到具体的技术实现上。

举个例子，功能安全概念说「对加速度指令进行合理性校验」，技术安全概念就要写清楚：

• 校验的阈值是多少？（比如加速度变化率不超过5m/s³）
• 校验的周期是多少？（每10ms校验一次）
• 校验失败后怎么处理？（触发安全状态，进入跛行模式）
• 用什么硬件/软件来实现？（MCU的看门狗+软件监控）

技术安全概念通常包含以下内容：

元素	说明	示例
安全机制	具体的技术手段	双通道比较、ECC校验、超时监控
安全状态	故障后的系统状态	降级模式、紧急停车、系统关闭
故障容错时间间隔	从故障发生到进入安全状态的最大时间	100ms
安全机制覆盖率	能检测到的故障比例	≥99%

我记得有一次，技术安全概念里写了一个「双通道比较」机制，但没写清楚比较的粒度。结果硬件团队做了字节级比较，软件团队做了帧级比较，两边对不上。后来我要求所有技术安全概念必须明确「比较什么、怎么比、比不过怎么办」。

3.4 系统架构设计

最后一步，把技术安全概念落实到系统架构里。系统架构设计要回答：「系统的模块怎么划分？模块之间怎么通信？安全机制怎么嵌入？」

我一般把系统架构分成三个层面：

• 感知层：摄像头、雷达、激光雷达。安全关注点：数据完整性、传感器故障检测。
• 决策层：主控制器、备份控制器。安全关注点：计算正确性、时序监控、看门狗。
• 执行层：制动系统、转向系统、动力系统。安全关注点：指令校验、执行器反馈。

架构设计时，有几个原则要记住：

1. 独立性：安全关键功能和非安全功能要隔离。别让一个娱乐系统的bug影响到制动系统。
2. 冗余性：ASIL D的功能通常需要冗余设计。比如双控制器、双传感器。
3. 可诊断性：每个安全机制都要能自检。你想想看，如果安全机制本身坏了，系统还不知道，那多危险。

举个例子，一个典型的L3自动驾驶系统架构：

┌─────────────────────────────────────────┐
│              感知层                      │
│  ┌──────┐  ┌──────┐  ┌──────┐         │
│  │Camera│  │ Radar│  │ LiDAR│         │
│  └──┬───┘  └──┬───┘  └──┬───┘         │
│     │         │         │              │
│     └─────────┼─────────┘              │
│               │ 数据融合                │
├───────────────┼─────────────────────────┤
│               │ 决策层                  │
│  ┌────────────┴────────────┐           │
│  │     主控制器 (ASIL B)    │           │
│  │  - 路径规划              │           │
│  │  - 行为决策              │           │
│  │  - 安全监控              │           │
│  └────────────┬────────────┘           │
│               │                        │
│  ┌────────────┴────────────┐           │
│  │     备份控制器 (ASIL D)  │           │
│  │  - 安全校验              │           │
│  │  - 降级控制              │           │
│  └────────────┬────────────┘           │
├───────────────┼─────────────────────────┤
│               │ 执行层                  │
│  ┌────────────┴────────────┐           │
│  │     制动/转向/动力       │           │
│  │  - 指令校验              │           │
│  │  - 执行器反馈            │           │
│  └─────────────────────────┘           │
└─────────────────────────────────────────┘

这个架构里，主控制器负责常规功能，备份控制器专门做安全监控。一旦主控制器输出异常，备份控制器可以在100ms内接管，让车辆进入安全状态。

嗯，最后说一句。系统架构设计不是一蹴而就的。我通常会在架构设计阶段做几次「安全评审」，拉上硬件、软件、系统、测试团队一起过。每个人从自己的角度提问题，往往能发现很多隐藏的风险。

好了，系统级安全概念就讲到这里。下一章我们聊聊「硬件安全需求与硬件架构设计」，到时候见。