4. 技术安全概念（TSC）：技术安全需求分解、系统架构设计、冗余与诊断机制、安全状态定义

好，咱们进入技术安全概念（TSC）这个环节。说实话，这是整个功能安全落地过程中最“硬核”的部分之一。前面我们搞定了危害分析和安全目标，也把功能安全需求（FSR）梳理清楚了。但FSR说到底还是“要做什么”，而TSC要回答的是“怎么做”。

我个人习惯把TSC比作一张建筑蓝图。你光说“这栋楼要抗震8级”没用，你得画出梁柱怎么布置、钢筋怎么扎、混凝土标号多少。TSC就是BMS的这张施工图。

4.1 技术安全需求分解：从“要什么”到“怎么做”

技术安全需求（TSR）是从功能安全需求（FSR）分解下来的。怎么分解？说白了就是一句话：把抽象的功能描述，变成具体的技术指标和实现方案。

举个例子：FSR里有一条——“当检测到电池过压时，系统必须在100ms内切断充电回路”。

这条FSR分解成TSR，可能变成这样：

FSR编号 FSR内容 TSR编号 TSR内容 ASIL等级
FSR-01 检测到过压时，100ms内切断充电回路 TSR-01-01 电压采样电路精度需达到±5mV，采样周期≤10ms ASIL C
TSR-01-02 主控芯片需在收到过压信号后50ms内输出切断指令 ASIL C
TSR-01-03 接触器驱动电路需在40ms内完成断开动作 ASIL C
TSR-01-04 诊断覆盖率需≥99%（针对采样和驱动路径） ASIL C

你看，一条FSR拆成了四条TSR，每条都对应具体的硬件或软件模块。我在项目中遇到过最头疼的情况，就是FSR写得挺好，但分解TSR时漏掉了某个路径。比如只分解了采样和驱动，忘了考虑通信延迟。结果实测时发现，从采样到执行的总时间超了20ms。嗯，这种坑踩过一次就记住了。

我的小技巧：分解TSR时，建议画一张“安全机制时序图”。把从传感器→控制器→执行器的每个环节都标出来，算清楚每一步的延迟预算。这样不容易漏项。

4.2 系统架构设计：冗余、隔离与分层

架构设计是TSC的骨架。对于BMS来说，常见的架构模式有这么几种：

  • 集中式架构：一个主控芯片干所有事。成本低，但单点故障风险高。适合ASIL B以下的系统。
  • 分布式架构：多个从控采集数据，主控做决策。灵活性好，但通信链路是薄弱环节。
  • 冗余架构：关键路径有备份。比如双MCU、双采样通道。成本高，但能覆盖ASIL D。

我个人比较推荐的是“主控+监控”的双芯片架构。主控负责正常功能，监控芯片独立做安全监控。两个芯片互相看门狗，一旦主控“死机”或输出异常，监控芯片直接接管并让系统进入安全状态。

为什么会这样设计？你想想看，如果主控芯片本身出了故障（比如程序跑飞），它自己都救不了自己。必须有一个独立的“裁判”在旁边盯着。我在一个项目中就遇到过，主控芯片因为电源纹波过大导致逻辑混乱，幸好监控芯片及时检测到了看门狗超时，切断了主继电器。不然后果不堪设想。

架构设计时还要注意隔离。高压和低压之间必须有物理隔离，采样通道之间也要考虑共因失效。我记得有一次评审，专家问：“你的两个采样芯片用的是同一个LDO供电，如果LDO短路了怎么办？” 嗯，这个问题问得好。从那以后，我在关键路径上都会做电源隔离。

4.3 冗余与诊断机制：让系统学会“自检”

冗余和诊断是TSC里最“技术”的部分。说白了，冗余是“坏了还有备份”，诊断是“坏了能发现”。两者缺一不可。

常见的冗余机制：

  • 硬件冗余：双采样通道、双MCU、双接触器驱动。注意，冗余不是简单复制，要避免共因失效。比如两个采样芯片不能共用同一个参考电压源。
  • 软件冗余：比如用两种不同的算法计算SOC，互相校验。我在一个项目中用过“安时积分法+卡尔曼滤波法”做冗余，虽然计算量大，但确实能发现传感器漂移的问题。
  • 信息冗余：比如CRC校验、ECC内存。这些是“低成本高回报”的机制，建议能加就加。

常见的诊断机制：

  • 电压诊断：用两个ADC同时采样同一节电池，差值超过阈值就报故障。
  • 电流诊断：霍尔传感器和分流器做交叉校验。我曾经遇到过霍尔传感器因为温度漂移导致测量偏差，幸好有分流器做参考，才没让系统误动作。
  • 温度诊断：NTC热敏电阻的短路/开路检测。这个比较简单，但容易被忽略。
  • 通信诊断：CAN总线用CRC+超时检测。我建议在每条CAN报文里都加上“滚动计数器”，防止报文被“卡住”或“重放”。
关键点：诊断覆盖率（DC）是衡量诊断机制好坏的核心指标。ISO 26262里对不同ASIL等级有明确的DC要求。比如ASIL C要求DC≥97%，ASIL D要求DC≥99%。达不到？那就得加冗余。

这里给一段简单的诊断代码示例，展示如何做ADC自检：

// ADC自检函数：注入已知电压，检查采样结果
bool ADC_SelfTest(void) {
    uint16_t adc_value;
    float measured_voltage;
    
    // 切换到内部参考电压通道
    ADC_SelectChannel(ADC_CH_INTERNAL_REF);
    adc_value = ADC_Read();
    measured_voltage = (adc_value * 3.3) / 4095.0;
    
    // 内部参考电压应为1.2V ± 2%
    if (measured_voltage < 1.176 || measured_voltage > 1.224) {
        return false;  // ADC故障
    }
    return true;
}

这段代码虽然简单，但很实用。每次上电时跑一遍，能发现ADC的“硬故障”。当然，这只是最基础的诊断，更高级的还有“在线自检”和“潜行故障检测”。

4.4 安全状态定义：系统“出事”了该怎么办

安全状态，就是系统在检测到故障后，要进入的“保命模式”。对于BMS来说，常见的安全状态有：

  • 断开高压：切断主正、主负接触器。这是最常用的安全状态。
  • 限制功率：比如降功率运行，只允许放电不允许充电。
  • 报警+维持：对于非严重故障，只报警不动作，让驾驶员有时间处理。
  • 完全关闭：系统下电，所有功能停止。

定义安全状态时，要考虑几个问题：

  1. 故障的严重程度：过压、过温这种“要命”的故障，必须立即断开高压。而SOC不准这种“慢性病”，可以只报警。
  2. 安全状态的“可达性”：如果接触器本身已经粘连了，你还能断开高压吗？所以安全状态的定义要包含“备用路径”。比如主接触器断不开，就断预充接触器或熔断器。
  3. 退出条件：安全状态不是“永久监禁”。要定义清楚什么条件下可以退出。比如故障消失后，经过一段“冷却时间”才能重新上电。
我曾经踩过的坑：在一个项目中，我们把安全状态定义为“断开高压+系统休眠”。结果发现，系统休眠后，故障记录还没来得及写入EEPROM就断电了。下次上电时，根本不知道之前发生了什么故障。后来我们改成了“先写故障记录，再进入安全状态”。这个顺序很重要，千万别搞反了。

最后，安全状态的定义一定要文档化，并且和系统架构、诊断机制对应起来。我习惯用一张“故障-安全状态映射表”来管理：

故障类型 诊断机制 安全状态 退出条件 响应时间
单体过压 双ADC采样校验 断开充电接触器 电压恢复正常后30s 100ms
单体欠压 双ADC采样校验 断开放电接触器 电压恢复正常后30s 100ms
过温 NTC开路/短路检测 降功率50% 温度降低到阈值以下 500ms
通信丢失 CAN超时检测 断开高压 通信恢复后10s 200ms

好了，技术安全概念这部分就聊到这儿。说白了，TSC就是要把“安全目标”变成“可执行的技术方案”。分解需求、设计架构、加冗余和诊断、定义安全状态——每一步都要扎扎实实。我在做项目评审时，最怕看到那种“TSC写得像散文”的文档。记住，TSC不是写给人看的，是写给硬件和软件工程师去实现的。越具体越好，越可量化越好。

← 上一章 📖 返回目录 下一章 →