Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

2.18 全章回顾——从HARA到安全档案的完整论证链

场景：一张HARA表格开始的安全之旅

2023年1月。你坐在会议室里，面前的白板上贴满了便签。这是刚启动的电动助力转向（EPS）功能安全项目。项目代号：EPS-R5。平台：某纯电轿车。你的第一个任务：为EPS系统定义HARA（危害分析与风险评估）。

操作场景编号OSE-042：车辆以62km/h在高速匝道右转，弯道半径约120米，道路摩擦系数μ≈0.7。驾驶员正在通过方向盘施加约4.8Nm的转向扭矩指令。

假设发生一个故障：转向助力功能在驾驶员请求转向扭矩时意外丧失。

这个场景下的危害分析：

  • 危害：车辆失去预期的转向助力，转向力需求突增：驾驶员必须以约4.4倍的力矩（从4.8Nm增加到约21.3Nm）来完成同样的转向操作。
  • 暴露度（Exposure, E）：E4（高概率）。高速公路匝道转向是日常操作场景，每天每千台车发生数十万次。
  • 可控性（Controllability, C）：C3（小于90%的驾驶员可以在典型条件下避免伤害）。在62km/h车速、弯道半径为120米的匝道上，突然失去转向助力：超过90%的普通驾驶员无法在避免伤害的时间内（通常2-3秒）安全控车。
  • 严重度（Severity, S）：S3（致命伤害可能）。失去转向控制导致车辆冲出匝道或与护栏碰撞，后果可能是致命的。
  • ASIL等级：E4 + C3 + S3 → ASIL D。

于是，安全目标SG-001 诞生了：

“The steering assistance system shall not fail to provide steering torque assistance when commanded by the driver under normal driving conditions.” （转向助力系统在正常驾驶条件下，不应在驾驶员请求转向扭矩时无法提供转向助力。） ASIL D。 FTTI = 200ms。安全状态 = 提供至少50%的名义助力扭矩 + 报警灯点亮。

这不是一个被写在纸上的无害句子。这个句子将在接下来的两年零四个月里，驱动所有工程团队的工作。

现在，让我们完整地走一遍：从SG-001出发，一条完整的论证链如何穿透V模型的每一个层次，最终在安全档案中变成一条不可辩驳的双向审计线索。

HARA → 安全目标 → 功能安全概念（FSC）

SG-001定义了顶层安全目标：任何导致无法提供转向助力的故障，必须在200ms内被检测并在FTTI内进入安全状态。但SG-001并没有说清楚：“哪些故障会导致无法提供转向助力？“这个问题的答案来自FMEA（失效模式与影响分析）和FTA（故障树分析）。

在你的系统FMEA中，团队识别出了以下关键失效模式：

  1. 扭矩传感器主信号丢失（开路/短路/SPI超时）：直接导致EPS无法感知驾驶员意图；
  2. 电机相电流传感器故障：致使电机无法正确输出目标扭矩；
  3. MCU时钟不稳定：导致控制算法时序错乱；
  4. 电源管理IC故障：导致安全相关供电轨（如3.3V模拟域）断电。

FSR（功能安全要求）被从SG-001派生出来：

  • FSR-031：系统应检测扭矩传感器信号的完整性，在任何信号丢失、超出有效范围或通信超时发生时，在≤200ms内进入安全状态。
  • FSR-032：系统应检测电机电流传感器的完整性……（类似结构）。
  • FSR-033：系统应检测MCU时钟有效性的丧失……
  • FSR-034：系统应检测安全相关供电轨的欠压……

每一项FSR都继承了SG-001的ASIL D和FTTI，并添加了具体的技术边界。这个继承关系被记录在追溯矩阵的第一层中：SG-001 → FSR-031, FSR-032, FSR-033, FSR-034。

功能安全概念（FSC）汇总了所有FSR，并开始架构层面的思考：这些FSR如何被分配到系统的不同元素？哪些元素承担安全相关功能，哪些是QM（只需要符合质量管理标准即可）？

技术安全概念（TSC）——从“做什么“到“怎么做“

FSR告诉你“必须检测什么“：TSR（技术安全要求）告诉你“用什么技术手段检测“。

以FSR-031（扭矩传感器信号完整性检测）为例。你的系统架构团队决定采用以下安全机制：

  • TSR-042：EPS控制器的ADC模块必须以≥1kHz的采样率持续采集扭矩传感器的差分输出信号。任何时刻，若ADC采样值超出4.5V至0.5V的有效量程（与传感器实际输出范围0.5V至4.5V对应），或SPI通信CRC校验连续3帧失败，EPS应在FTTI（200ms）内通过以下方式进入安全状态：将电机控制模式切换至“安全降级模式“：以50%的名义助力比例维持基本助力：并点亮仪表盘EPS故障灯。

  • TSR-043：ECU应配备独立的硬件看门狗（Window Watchdog，服务窗口为50ms-80ms），若MCU未能在窗口内喂狗，看门狗必须在10ms内触发MCU复位。复位后应执行ASIL D安全启动序列（包括全部RAM/Flash完整性检查），起始助力模式为“安全降级模式“。

  • TSR-044：安全关键电源域3.3V应配备独立的欠压监控电路（阈值2.97V±1%），触发后必须在50μs内复位所有受该电源域供电的安全功能，并在≤5ms内进入安全状态。

每一个TSR都是一个工程规格：可以分配给硬件工程师（TSR-044的欠压电路设计）、软件工程师（TSR-042的ADC采集与阈值判断逻辑）、或系统和测试工程师（TSR-043的看门狗时序定义与验证）。

追溯矩阵的第二层建立：FSR-031 → TSR-042, TSR-043, TSR-044……

硬件架构——SPFM, LFM, PMHF

TSR-042、043、044被分解为硬件需求和软件需求。硬件团队开始进行硬件安全分析。

硬件架构度量（Part 5, Clause 8、9）：

ASIL D的硬件架构必须满足：

  • SPFM（单点故障度量）≥ 99%：所有单点故障中，被安全机制覆盖的比例必须≥99%。
  • LFM（潜在故障度量）≥ 90%：所有潜伏故障中，被安全机制检测或预防的比例≥90%。
  • PMHF（硬件随机失效概率度量）< 10 FIT（10⁻⁸/hour）：所有硬件随机失效导致的违反安全目标的总体概率必须低于每10⁸小时1次。

硬件团队对EPS控制器的所有安全相关硬件元件进行了FMEDA（失效模式、影响和诊断分析）。以扭矩传感器接口电路为例：

  • MOSFET开关故障：单点故障→安全机制（ADC通道诊断，连续3次超出量程标记故障）→覆盖率99.5%；
  • ADC参考电压漂移：潜伏故障→安全机制（周期性参考电压交叉校验，每100ms与独立的带隙基准电压比对）→潜伏故障覆盖率98%；
  • PCB走线开路：单点故障→安全机制（信号超量程检测）→覆盖率99.8%。

经过对所有安全相关硬件元件的汇总计算，硬件团队得出：

  • SPFM = 99.4%（目标99%，通过）
  • LFM = 92.1%（目标90%，通过）
  • PMHF = 7.3 FIT（目标<10 FIT，通过，设计安全裕度约27%）

这些数值被记录在硬件安全分析报告中，该报告的“引用依据“一栏指向了具体的TSR编号（如TSR-042），而TSR再向上追溯至FSR-031，最终归属于SG-001。

至此，追溯矩阵的第三层建立：TSR-042 → 硬件安全分析报告中“扭矩传感器接口电路安全机制覆盖率报告“。

软件架构——FFI与自由度分析

与此同时，软件团队在做一件同样重要的事：FFI（免于干扰，Freedom from Interference）分析。

FFI的核心问题是：在同一个MCU上运行的ASIL D安全功能和QM级非安全功能之间，是否存在资源干扰？队列效应（Queuing Effects）、死锁、共享资源的隐性耦合。这些都在FFI的审视范围之内。

在EPS-R5项目中，软件架构设计涉及FFI分析的关键点：

  • 内存保护：ASIL D的扭矩计算函数（cal_TorqueCompute）和QM级的蓝牙日志传输模块共享同一块SRAM。必须通过MPU（内存保护单元）确保QM代码无法写入ASIL D的数据区域。MPU配置本身必须在安全启动序列中被校验（CRC-32）。
  • 时序保护：ASIL D的200ms安全环路执行时间可能被QM任务占用CPU而导致超时。解决方案：采用时间分区（Time Partitioning）：ASIL D任务在专用Slot中运行，QM任务不能在ASIL D的时间预算内抢占CPU。
  • 信息交换保护：ASIL D任务传递给QM任务的状态数据（如电机温度用于诊断日志）必须通过端到端（E2E）保护协议：加入CRC-16和序列计数器，确保QM接收到的数据不会因通信链路错误而被误解为安全信息。

FFI分析结果写入软件安全分析报告，每个保护措施对应到一个TSR（如“时间分区“对应TSR-042的“200ms内响应“要求），向上追溯至FSR-031和SG-001。

软件单元设计与MC/DC测试

TSR-042要求“扭矩信号超出4.5V-0.5V量程即判定故障“。软件团队将这个TSR细化为具体的软件单元需求：

  • SWR-042-01：函数Sensor_ValidateTorque()应读取ADC的原始值(adcVal)，如果adcVal > ADC_MAX_VALID或adcVal < ADC_MIN_VALID，应连续3次（各次间隔1ms）确认超量程，然后返回SENSOR_STATUS_FAULT。

这个函数包含一个条件判定：if ((adcVal > ADC_MAX) || (adcVal < ADC_MIN))：有两个条件（adcVal > ADC_MAX和adcVal < ADC_MIN），组成了OR逻辑。MC/DC（条件/判定覆盖率） 要求：

ASIL D的软件必须满足MC/DC覆盖。对于上述判定，需要以下测试用例：

用例adcVal > ADC_MAXadcVal < ADC_MIN判定结果
TC-01TrueFalseTrue
TC-02FalseTrueTrue
TC-03FalseFalseFalse

这3个测试用例共同证明了：每一个条件都独立地影响到判定的结果（TC-01证明条件1单独能让判定变True，TC-02证明条件2单独能让判定变True，TC-03作为对照）。

这个测试用例（TC-01/02/03）在软件单元测试报告中被记录为覆盖SWR-042-01。而SWR-042-01在追溯矩阵中指向TSR-042，TSR-042指向FSR-031，FSR-031指向SG-001。

你们同时验证了函数的分支覆盖率（Branch Coverage） 和语句覆盖率（Statement Coverage） 都达到100%。对于ASIL D，这是强制要求。

至此，追溯矩阵的第四层建立：SWR-042-01 → 单元测试TC-01/02/03（MC/DC覆盖证据）。

集成测试——软硬件合拢之后

软件单元测试只验证了单个函数的逻辑正确性。当这个函数被嵌入完整的EPS控制器的软件调度框架中：和任务调度、中断处理、DMA传输、看门狗喂狗这些运行时元素相互作用时。它仍然正确吗？

软件集成测试（Part 6, Clause 10） 验证这一点。对于TSR-042，你们设计了一个完整的集成测试场景：

  • 在HIL台上运行完整的EPS控制器软件（含FreeRTOS调度器、CAN通信栈、诊断栈、NVM管理器……所有的运行时元素）。
  • 通过故障注入单元（FIU）在扭矩传感器输出上注入一个模拟开路故障：信号瞬间从2.5V降到0V。
  • 监控EPS的CAN输出报文。验证：
    • 在故障注入后的≤200ms内，EPS控制器发送的诊断报文指示“扭矩传感器故障“（CAN ID 0x1A2的第4字节bit2置1）。
    • 在≤200ms内，EPS控制器进入“安全降级模式“：电机扭矩输出下降至名义值的50%（扭矩传感器的CAN输出中，目标力矩值从4.8Nm降至2.4Nm）。
    • 在≤200ms内，仪表盘EPS故障灯点亮（CAN ID 0x4B0的第1字节bit6置1）。
    • 连续3次间隔0.5s重复测试，时序满足200ms FTTI要求。

这些测试结果被记录在软件集成测试报告中，引用的TSR为TSR-042。追溯矩阵的第五层建立。

系统集成与整车验证——路试场上见真章

软件集成测试在HIL台上通过了。硬件FMEDA的SPFM/LFM/PMHF数字也满足了目标。现在只剩一个问题：整车。

系统集成测试（Part 4, Clause 7 & Part 5, Clause 11） 和整车验证（Part 4, Clause 8） 是安全论证的最终环节，也是最接近真实的环节。

你们把完整的EPS控制器（含全部生产标定参数）装到一台骡车上，跑两轮验证：

  • 系统HIL测试：在dSPACE仿真平台上连接完整的EPS机械系统（转向机、电机、扭矩传感器、转角传感器均为真实硬件），通过CAN总线连接车辆动力学模型（Carsim实时仿真车辆动态：车身侧倾、载荷转移、轮胎刚度变化）。在这个集成环境中，注入“扭矩传感器通信超时“故障。验证EPS在FTTI内进入安全状态，同时验证车辆动力学模型在安全降级模式下（50%助力）仍然保持可控：驾驶员在2秒内能把方向修正过来，车身侧向偏移不超过0.5米（车道宽度一般3.5米）。

  • 整车道路测试：在实际测试场的高速环形道上（半径150米，设计车速80km/h），以62km/h车速重现场景OSE-042。在传感器分支上临时接入一个程控开关。在驾驶员不知情的条件下（但副驾驶位有安全员，且车辆加装了防滚架），通过远程指令在62km/h车速、弯道120m半径时断开扭矩传感器信号。记录数据：

    • EPS从故障发生到进入安全降级模式：148ms（<200ms FTTI，通过）
    • 驾驶员感受到方向盘力矩突增并成功修正轨迹：时间约2.1秒（在50%助力下）
    • 车辆最大横向偏移：0.37米（在车道内，通过）
    • 无碰撞、无失控、驾驶员事后未报告惊恐反应（试验后问卷调查得分为1.2/5，其中1为“完全可控“）。

整车验证的结果写入整车验证报告，引用TSR-042和相关FSR。追溯矩阵的第六层建立：整车道路测试-场景OSE-042-故障注入 → TSR-042 → FSR-031 → SG-001。

安全档案——把所有链收拢

经过两年零四个月，你手上有：

  • HARA报告（SG-001诞生地）
  • FSC（FSR-031等从SG-001派生）
  • TSC（TSR-042等从FSR派生）
  • 硬件安全分析报告（SPFM 99.4%, LFM 92.1%, PMHF 7.3 FIT ： 引用了TSR-042）
  • 软件安全分析报告（FFI ： 时间分区保护、内存MPU保护、E2E保护：引用了TSR-042）
  • 软件单元测试报告（MC/DC覆盖SWR-042-01：引用了TSR-042）
  • 软件集成测试报告（HIL台故障注入验证：引用了TSR-042）
  • 系统集成测试报告与整车验证报告（真实车辆故障注入：引用了TSR-042）
  • EOL测试规格（产线验证扭矩传感器通路 ： 引用了TSR-042）
  • 现场监控流程定义（扭矩传感器相关DTC的72小时上报机制）

所有这些工作产品，通过追溯矩阵互相连接，形成一条完整的审计链：

HARA #17 (OSE-042, ASIL D) → SG-001 → FSR-031 → TSR-042 → SWR-042-01 / 硬件安全机制 → 单元测试证 MC/DC / 硬件SPFM计算→ 集成测试报告（HIL）→ 整车验证报告（道路测试）→ EOL测试规格 → 现场监控定义 → 安全档案综述《EPS转向助力安全论证报告》

当TÜV评估员在2025年6月再次打开你的安全档案，现在他可以：

  1. 从HARA #17出发，点击追溯链向前走：经过SG-001、FSR-031、TSR-042、SWR-042-01，直到MC/DC测试报告的第42行：验证每一项下游工作产品都是完整和正确的；
  2. 从MC/DC测试报告反向走：经过SWR-042-01、TSR-042、FSR-031、SG-001，直到HARA #17：验证没有遗漏的追溯链接；
  3. 在任何中间节点停下来，检查该工作产品的评审签名、版本号、发布日期：确保整个过程在流程上是合规的。

他看到了。他签了字。

免疫隐喻：从病原体识别到免疫记忆的全通路

让我们用免疫隐喻来总结这个完整的论证链：

  • HARA ≈ 病原体目录。你的免疫系统需要知道哪些病原体（危害/失效模式）可能导致疾病（事故）。HARA就是这份目录：按严重程度分类（ASIL等级），记录每种病原体的特征（暴露场景、可控性、严重度）。

  • 安全目标（SG） ≈ 免疫应答目标。“对这个病原体，必须产生中和抗体”：对应的就是“对这个危害事件，必须实现ASIL D的安全完整性“。

  • FSR ≈ 免疫应答策略的宏观定义。“需要在呼吸道黏膜表面产生IgA抗体”：对应的就是“需要在扭矩传感器接口实现信号完整性检测“。

  • TSR ≈ 免疫应答的分子机制。“B细胞的VDJ重排产生特定抗体可变区，补体系统通过C3b标记病原体”：对应的就是“ADC以1kHz采样率采集信号，3次超量程判定故障，FTTI内软硬件协同进入安全状态“。

  • 硬件架构SPFM/LFM/PMHF ≈ 先天免疫系统的效能度量。中性粒细胞到达感染灶的速度、巨噬细胞对病原体的吞噬率、补体系统的膜攻击复合物形成效率。这些就是“硬件随机失效覆盖率“在生物世界中的映射。SPFM 99%意味着：100个单点故障中，99个会被安全机制“识别并消灭“。

  • 软件MC/DC测试 ≈ 单克隆抗体的体外验证。“实验室确认该抗体在1:1000稀释度下仍能中和SARS-CoV-2病毒”：对应的就是“MC/DC测试验证SWR-042-01的每一个条件都能独立影响判定结果“。

  • 软件集成测试 ≈ 器官水平的免疫应答验证。“在小鼠模型的肺部组织切片中确认抗体与病毒结合”：对应的就是“HIL台故障注入后验证EPS在FTTI内发出正确的CAN诊断报文“。

  • 整车验证 ≈ 人体临床试验。“在III期临床试验中对30000名受试者接种疫苗，验证有效性和安全性”：对应的就是“在测试车62km/h匝道工况下通过故障注入验证EPS的安全降级响应“。

  • 安全档案 ≈ 国际旅行健康证明（附每次入境的检疫更新记录）。你出国的每一趟航班，目的国可能要求你提供：基础疫苗记录、近期传染病筛查、出入境检疫章——这些证据不是一次签发就终身有效的，它们随着你的旅行史持续更新。安全档案也是一份持续演进的活文档：初始版本在SOP前完成，但每一次OTA升级、每一批售后故障分析、每一次零部件的BOM变更，都会在档案中留下新的记录。它不是一份“写完就交差“的审批文档，而是一份从SOP到车辆报废都在持续更新的健康护照。

本书的边界

ISO 26262:2018的覆盖范围到此为止。但汽车电子的安全挑战不止于此。

本章不展开讨论预期功能安全（SOTIF，ISO 21448）——它处理的是“功能本身不足导致的失效“，而非“系统故障导致的失效“。例如摄像头在逆光条件下丢失车道线、激光雷达在大雨中误识别、深度神经网络在训练集分布之外的场景中做出错误推理。这些不是“故障“，是“功能不够好“。SOTIF涉及的感知系统失效模式和场景覆盖率分析与本书讨论的传统底盘安全机制有根本不同的方法框架，适合单独成书讨论。

本篇小结

  1. Part 2-6, Part 9：定义了安全论证的实体层，从危害分析到软硬件设计的每一个工程步骤
  2. Part 7：把安全论证的时间轴从SOP延伸到车辆报废
  3. Part 8：为实体层提供了结构层：配置管理、变更管理、文档管理、工具鉴定、安全档案
  4. Part 1 & Part 10：通过词汇定义和解释性指南确保方法论的正确应用
  5. 功能安全不是“学习规则“，是学会构建论证：标准中的每一条要求都在问你——你做了什么来降低风险？你怎么知道你做的确实降低了风险？你能证明给独立第三方看吗？

【下集预告】： ISO 26262的18个章节你已经完整走过一遍。第2章讲的是“标准怎么要求“，第3章讲的是“硬件具体怎么做“——看门狗怎么配、锁步核怎么工作、ECC怎么纠错、MPU怎么隔离。从标准条款到寄存器级实现，这一章把每一个安全机制拆开来看。