4. 技术安全概念(TSC)设计：技术安全需求导出、系统架构设计、软硬件接口定义、冗余与容错设计

好，我们进入技术安全概念设计。这是功能安全开发中最「硬核」的环节之一。前面我们完成了功能安全概念，明确了「系统要做什么来保证安全」。现在，我们要回答的是——「具体怎么做」。

说白了，技术安全概念就是把功能安全需求翻译成工程师能直接落地的技术方案。我个人习惯把这一步称为「从需求到实现的桥梁」。你想想看，如果这一步没做好，后面的开发和测试都会跑偏。

4.1 技术安全需求的导出

技术安全需求（TSR）是从功能安全需求（FSR）细化而来的。怎么细化？我总结了一个三步法：

1. 分解：把FSR拆解到系统、硬件、软件层面
2. 量化：给每个需求加上具体的指标（时间、精度、覆盖率）
3. 分配：明确每个需求由哪个组件负责实现

举个例子。FSR有一条：「当自车速度超过120km/h时，系统应发出警告」。对应的TSR可能是：

• TSR-001：车速传感器模块每10ms上报一次车速值，精度±1km/h
• TSR-002：当车速≥120km/h持续超过2秒，HMI模块在200ms内点亮红色警告图标
• TSR-003：警告逻辑的软件实现，其故障覆盖率需达到99%（根据ISO 26262-6）

我在项目中遇到过一件事。有个同事写了一条TSR：「系统应可靠地检测前方障碍物」。我问：「什么叫可靠？检测距离多少？响应时间多少？」他答不上来。后来我们花了三天重新梳理，把这条需求拆成了12条可量化的TSR。嗯，从那以后，团队里再没人敢写模糊的需求了。

4.2 系统架构设计

技术安全需求有了，接下来就是设计系统架构。这里我强调一个原则：架构要为安全服务，而不是反过来。

自动驾驶系统的典型架构，我习惯分成三层：

层级	职责	安全关注点
感知层	环境感知、目标检测	传感器故障、数据延迟、误检/漏检
决策层	路径规划、行为决策	算法错误、计算超时、死锁
执行层	转向、制动、加速控制	执行器卡滞、响应超时、指令错误

每一层都要考虑安全机制。比如感知层，我通常会设计传感器数据一致性校验——如果摄像头说前面有车，但毫米波雷达说没有，系统必须进入降级模式。

4.3 软硬件接口定义

软硬件接口（HSI）是技术安全概念里最容易出问题的地方。为什么？因为软件团队和硬件团队经常「各说各话」。

我曾经在一个项目里，软件团队说「我只需要一个中断信号」，硬件团队说「我给你留了GPIO」。结果联调时发现，中断响应时间差了50ms——因为GPIO的驱动层有额外的延迟。嗯，这就是接口定义不清晰的典型后果。

所以，HSI定义必须包含以下内容：

• 信号类型：数字/模拟、电平/边沿触发
• 时序要求：最大延迟、最小脉冲宽度、采样窗口
• 故障行为：信号丢失时，软件应如何检测和处理
• 诊断接口：硬件自检结果如何传递给软件

举个例子，制动系统的HSI定义：

// 制动指令接口定义
// 信号名：brake_cmd
// 类型：PWM，频率100Hz，占空比0-100%
// 安全要求：
//   - 占空比<5%视为无效指令，系统应进入安全状态
//   - 连续3个周期无有效信号，触发看门狗复位
//   - 硬件自检结果通过SPI接口上报，每100ms一次

4.4 冗余与容错设计

冗余和容错，是自动驾驶安全设计的「最后一道防线」。说白了，就是当某个组件挂了，系统还能安全地撑住。

常见的冗余策略有：

• 硬件冗余：双传感器、双控制器、双执行器
• 信息冗余：多源数据融合，比如视觉+雷达+激光雷达
• 时间冗余：任务重试、超时重算
• 软件冗余：不同算法实现同一功能，交叉验证

但要注意，冗余不是越多越好。我见过一个团队，为了追求「绝对安全」，在感知层用了5个不同类型的传感器。结果呢？数据融合算法复杂到跑不动，系统延迟反而增加了。你想想看，这反而降低了安全性。

容错设计的关键是故障响应策略。我一般会定义三个等级：

等级	故障类型	响应策略
L1	轻微故障（如单个传感器噪声增大）	降级运行，限制车速，提示驾驶员接管
L2	中等故障（如主控制器失效）	切换至冗余控制器，执行最小风险策略
L3	严重故障（如制动系统完全失效）	立即进入安全状态，紧急停车

最后，我想说一句。技术安全概念设计，本质上是一个「权衡」的过程。你要在安全、成本、性能之间找到平衡点。没有完美的方案，只有最适合你项目的方案。嗯，这就是我做了这么多年功能安全，最深的一点体会。