4. 技术安全概念(TSC)：技术安全需求导出、系统架构设计、冗余与多样性策略、故障检测与响应机制、安全机制详细设计

各位工程师，大家好。今天我们进入转向系统功能安全设计的核心环节——技术安全概念（TSC）。

说实话，很多刚入行的朋友容易把TSC和系统安全概念搞混。我个人习惯这么区分：系统安全概念（SSC）回答“要做什么”，而技术安全概念（TSC）回答“怎么做”。说白了，TSC就是把安全需求翻译成具体的技术方案。

4.1 技术安全需求的导出

技术安全需求（TSR）从哪里来？从功能安全需求（FSR）来。但这不是简单的“复制粘贴”。

举个例子：FSR说“系统必须在100ms内检测到转向扭矩传感器故障”。到了TSR层面，你得明确：

• 用什么检测方法？是自检还是交叉校验？
• 检测覆盖率要达到多少？
• 检测到故障后，系统进入什么状态？

我在项目中遇到过这样一个坑：FSR写得挺漂亮，但导出TSR时忽略了传感器供电的监控。结果呢？传感器本身自检通过，但供电电压跌到4.5V时，输出已经漂移了。嗯，这其实是个很典型的“漏监控”案例。

导出TSR时，我建议遵循以下步骤：

1. 分解FSR：把每个功能安全需求拆解到具体硬件/软件组件
2. 分配ASIL等级：每个TSR继承其来源FSR的ASIL等级
3. 定义安全状态：明确故障发生后的目标状态
4. 设定容错时间间隔（FTTI）：从故障发生到进入安全状态的最大允许时间

4.2 系统架构设计

架构设计是TSC的骨架。转向系统的架构设计，我个人倾向于采用分层+模块化的思路。

为什么会这样？因为转向系统涉及传感器、控制器、执行器三个域，每个域的故障模式不同，需要不同的安全机制。

下面这张图是我常用的TSC架构框架，它展示了从传感器输入到执行器输出的完整安全链路：

这张图里，我特意把安全状态放在了最下面。你想想看，不管上面怎么折腾，最终都要落到“系统怎么安全地停下来”这个问题上。

4.3 冗余与多样性策略

冗余不是简单的“多放一套”。我见过不少设计，两个通道用完全一样的芯片、一样的软件、一样的供电。这其实很危险——共因失效（CCF）会同时干掉两个通道。

所以，我强调多样性（Diversity）。具体来说：

冗余类型	实现方式	对抗的故障模式
硬件冗余	双MCU、双传感器、双电机绕组	单点故障、随机硬件失效
软件多样性	主控用C语言，监控用不同算法	软件设计错误、编译器bug
时序多样性	主通道和监控通道不同步采样	时序相关的共因失效
供电多样性	主通道用KL30，冗余通道用独立LDO	电源纹波、电压跌落

4.4 故障检测与响应机制

故障检测是TSC的“眼睛”。没有可靠的检测，再好的冗余也是摆设。

我通常把故障检测分为三个层次：

• 层级一：自检——上电自检、周期自检。比如RAM的MBIST、ROM的CRC校验。
• 层级二：交叉比较——主通道和冗余通道的结果互相比对。偏差超过阈值就报故障。
• 层级三：合理性检查——信号是否在物理可行范围内。比如方向盘转角不可能1ms内转720度。

故障响应机制，说白了就是“检测到故障后怎么办”。我习惯用状态机来管理：

// 故障响应状态机伪代码
typedef enum {
    SAFE_NORMAL,        // 正常模式
    SAFE_DEGRADED,      // 降级模式（使用冗余通道）
    SAFE_LIMP_HOME,     // 跛行回家模式（限制助力）
    SAFE_SHUTDOWN       // 安全关断
} SafetyState;

SafetyState FaultResponse(FaultCode fault) {
    switch(fault) {
        case FAULT_SENSOR_PRIMARY:
            // 切换到冗余传感器
            return SAFE_DEGRADED;
        case FAULT_MOTOR_OVERCURRENT:
            // 限制助力输出
            return SAFE_LIMP_HOME;
        case FAULT_MCU_CORE:
            // 立即关断
            return SAFE_SHUTDOWN;
        default:
            return SAFE_NORMAL;
    }
}

4.5 安全机制详细设计

安全机制是TSC的“肌肉”。每个安全机制都要回答三个问题：

1. 检测什么？——故障模式
2. 怎么检测？——检测方法
3. 检测到后怎么办？——响应动作

我以转向系统中最常见的“扭矩传感器故障”为例，展示安全机制的详细设计：

安全机制ID	SM_TORQUE_001
关联TSR	TSR_TORQUE_01：主/冗余扭矩传感器偏差检测
故障模式	主传感器输出漂移、冗余传感器输出卡滞
检测方法	每个控制周期（1ms）比较主/冗余传感器输出值，偏差超过5%则触发故障
检测覆盖率	≥99%（基于FMEDA分析）
响应时间	从故障发生到检测到：≤2ms
响应动作	1. 记录故障码 2. 切换至冗余传感器 3. 点亮仪表盘警告灯 4. 限制助力至50%
安全状态	降级助力模式（驾驶员可正常转向，但助力减小）
验证方法	故障注入测试：在传感器输出上叠加偏移量，验证系统响应

嗯，这里要注意：安全机制的详细设计一定要和FMEDA（失效模式、影响与诊断分析）联动。每个安全机制的检测覆盖率，最终要反馈到FMEDA中，计算系统的残余风险是否满足ASIL等级要求。

我个人习惯在安全机制设计完成后，做一次“安全机制覆盖率检查”。说白了就是：把所有可能的故障模式列出来，逐个确认是否有对应的安全机制覆盖。没覆盖到的，要么加机制，要么接受风险（但要有充分理由）。

好了，技术安全概念的内容就讲到这里。记住一句话：TSC不是写文档，而是设计一个能真正保护驾驶员和乘客的安全系统。每个决策都要有依据，每个机制都要可验证。