4. 系统级设计：技术安全概念、系统架构设计、安全机制分配

系统级设计，说白了就是把上一阶段定义的安全目标，落地成具体的技术方案。我个人习惯把这个阶段叫做「从需求到实现的桥梁」。你想想看，安全目标再完美，如果落不了地，那就是空中楼阁。

我在项目中遇到过不少团队，安全目标写得漂漂亮亮，一到系统设计就卡壳。为什么？因为这里需要同时考虑功能、安全、成本、性能，四个维度互相拉扯。嗯，咱们今天就把这个坎迈过去。

4.1 技术安全概念（TSC）的构建

技术安全概念，是安全需求在技术层面的具体化。它回答一个问题：系统到底怎么做，才能满足安全目标？

我建议把TSC拆成三个层次来看：

• 系统级TSC：定义系统层面的安全行为，比如故障检测、降级策略
• 硬件级TSC：具体到芯片、传感器、执行器的安全机制
• 软件级TSC：软件层面的故障响应、诊断、冗余逻辑

构建TSC时，我常用的模板包含以下要素：

要素	说明	示例
TSC ID	唯一标识，便于追溯	TSC-ACC-001
关联安全目标	指向SG编号	SG-ACC-01
功能描述	系统在正常/故障时的行为	当车速传感器故障时，ACC自动退出并提示驾驶员接管
故障检测机制	如何发现故障	传感器信号合理性检查，超时监控
故障响应时间	从故障发生到安全状态的时间	≤ 100ms
安全状态	系统进入何种安全模式	ACC禁用，转向手动控制

4.2 系统架构设计：安全视角的考量

系统架构设计，不只是画几个方框连几条线。从功能安全的角度看，架构决定了故障传播路径和安全机制的覆盖范围。

我个人的经验是，架构设计阶段要问自己三个问题：

1. 故障会不会扩散？——一个模块挂了，会不会带崩一片？
2. 安全机制能不能覆盖？——每个关键故障，有没有对应的检测和响应？
3. 独立性够不够？——安全相关功能和非安全功能之间，有没有足够的隔离？

下面这张图展示了系统级安全架构的核心逻辑：

4.3 安全机制分配

安全机制分配，就是把TSC中定义的检测和响应行为，落实到具体的硬件或软件模块上。说白了，就是谁负责检测，谁负责响应，谁负责容错。

我建议按以下步骤进行分配：

1. 列出所有故障模式——从FMEA或FTA中提取
2. 确定检测机制——用什么方法发现故障（自检、互检、监控狗等）
3. 确定响应机制——发现故障后怎么做（报警、降级、停机）
4. 分配责任人——哪个模块/软件组件负责执行
5. 验证覆盖度——每个故障是否都有机制覆盖

下面是一个安全机制分配的示例表格：

故障模式	检测机制	响应机制	分配模块	覆盖度
车速传感器信号丢失	信号超时监控	ACC退出，提示接管	ACC控制器软件	高
制动踏板位置传感器漂移	合理性检查（与主缸压力对比）	制动辅助降级，点亮警告灯	ESC控制单元	中
CAN总线通信中断	心跳监控 + 超时检测	进入安全状态，存储故障码	网关 + 各ECU	高
微处理器内核自检失败	LBIST（上电自检）	禁止启动，记录故障	硬件安全模块	高

4.4 ASIL分解与独立性要求

ASIL分解，是系统级设计中一个非常实用的技巧。说白了，就是把一个高ASIL等级的需求，拆成两个低ASIL等级的需求，前提是它们相互独立。

举个例子：一个ASIL D的需求，可以分解为：

• ASIL C（模块A）+ ASIL C（模块B），且A和B相互独立
• ASIL D（模块A）+ QM（模块B），但B不能影响A的安全功能

我在项目中用过ASIL分解来降低成本。有一次，一个ASIL D的制动需求，我们把它分解成ASIL B（硬件冗余路径）+ ASIL B（软件诊断路径），两个路径独立开发，最后通过了审核。嗯，这里的关键是独立性证明——你得拿出证据，证明两条路径不会共因失效。

4.5 系统设计评审要点

系统设计完成后，我建议做一次结构化评审。评审时重点关注：

• 完整性：每个安全目标是否都有对应的TSC？
• 一致性：TSC之间是否有冲突？（比如一个要求立即停机，另一个要求延迟降级）
• 可实现性：安全机制在当前硬件/软件平台上能否实现？
• 可验证性：每个安全机制是否都有明确的测试方法？

我曾经在一个项目中，评审时发现一个TSC要求「在10ms内检测到故障」，但实际硬件采样周期是20ms——这就是典型的可实现性问题。所以，系统设计阶段一定要拉上硬件和软件工程师一起过，别自己闷头画图。