3、安全设计概述：功能安全（ISO 26262）、预期功能安全（SOTIF）与网络安全（ISO 21434）在制动系统中的综合应用
现代制动控制系统已从纯液压/气动机械结构演变为高度电子化、软件密集型的线控系统（Brake-by-Wire）。制动系统直接关系到车辆乘员及道路使用者的生命财产安全，其安全设计必须覆盖三个既相互独立又深度耦合的维度：功能安全（Functional Safety, FuSa）关注系统因电子电气故障导致的失效风险；预期功能安全（SOTIF）关注系统在无故障条件下，因功能不足、性能局限或环境干扰引发的非预期行为；网络安全（Cybersecurity）则关注外部恶意攻击对系统完整性、可用性和机密性的破坏。三者共同构成了制动系统安全设计的“铁三角”。本章将系统阐述这三者在制动系统开发中的综合应用框架、核心方法及工程实践要点。
上图展示了制动系统安全设计的整体框架。功能安全、预期功能安全与网络安全并非三个孤立的流程，而是需要在系统架构层面进行统一规划、协同设计、联合验证的有机整体。例如，一个用于功能安全监控的软件模块（如看门狗），同样可以被网络安全用于检测异常指令流；而SOTIF中定义的恶劣天气场景，也可能同时是网络攻击的物理触发条件。因此，综合应用的核心在于建立统一的安全目标库和安全机制库，实现安全需求的追溯与复用。
3.1 功能安全（ISO 26262）在制动系统中的核心原理与实施
3.1.1 核心原理：从危害分析到ASIL等级
ISO 26262 针对的是电子电气系统的功能异常行为，其核心逻辑是：首先通过危害分析与风险评估（HARA）识别系统在故障状态下可能引发的危害事件，然后根据严重度（S）、暴露概率（E）和可控性（C）三个参数确定每个安全目标的汽车安全完整性等级（ASIL）。对于制动系统，典型的危害事件如“非预期制动”或“制动功能丧失”，通常会被评定为ASIL D——最高安全等级，要求系统失效率低于 10-8/h，且必须具备极高的系统性安全措施。
| 危害事件示例 | S（严重度） | E（暴露率） | C（可控性） | ASIL等级 | 安全目标示例 |
|---|---|---|---|---|---|
| 高速行驶中制动功能完全丧失 | S3（生命危险） | E4（频繁） | C3（难以控制） | ASIL D | 确保在任何单一故障下，制动力矩不低于需求的50% |
| 车辆静止时意外溜车 | S2（严重伤害） | E3（常见） | C2（一般可控） | ASIL B | 驻车制动应具备防误释放逻辑 |
| 低速蠕行时轻微制动抖动 | S1（轻伤） | E4（频繁） | C1（完全可控） | ASIL A | 制动压力波动应限制在舒适性阈值内 |
3.1.2 判断方法与操作流程：安全机制的设计与验证
在确定ASIL等级后，工程团队需要设计相应的安全机制。对于制动系统，常见的安全机制包括：
- 冗余架构：采用双通道ECU、双电源轨、双传感器（如主/从轮速传感器）实现硬件冗余。
- 自诊断：周期性执行内存测试（如CRC校验）、CPU寄存器测试、传感器合理性检查。
- 安全状态控制：当检测到不可恢复故障时，系统应进入安全状态，例如降级为液压备份模式或切断助力输出。
- 时间/逻辑监控：使用独立看门狗（Window Watchdog）监控主程序执行时序。
操作流程上，需遵循 V模型 开发流程：从安全概念到技术安全需求，再到硬件/软件设计，每一层都有对应的验证活动。例如，在软件层面，ASIL D 要求使用形式化方法或增强的单元测试覆盖率（如MC/DC 100%）。
3.1.3 案例拆解：线控制动（EHB）系统功能安全设计实例
背景与约束：某车型采用电子液压制动（EHB）系统，要求满足ASIL D。系统由主ECU、踏板模拟器、液压控制单元（HCU）、四个轮缸压力传感器、电机泵及电磁阀组成。初始设计仅采用单ECU和单压力传感器。
初始现象与目标：在HARA分析中发现，若主ECU失效，则制动助力完全丧失，驾驶员需用远超法规要求的力踩踏板，判定为ASIL D风险。目标是将该风险降低至可接受水平。
分析判断过程：团队进行了FTA（故障树分析），发现单点故障（ECU失效）是导致顶层事件（制动助力丧失）的主要贡献因素。同时，FMEA显示压力传感器漂移会导致制动力分配错误。
实际操作步骤：
- 增加一个独立的备份ECU（低性能但足以驱动液压泵），与主ECU构成1oo2架构。
- 每个轮缸增加一个冗余压力传感器，主传感器信号用于闭环控制，备份传感器信号用于合理性校验。
- 设计降级策略：当主ECU失效时，备份ECU接管，仅提供基础制动力（约0.4g减速度），同时点亮警告灯。
- 在软件中增加传感器漂移自学习功能，在每次上电时对比四个传感器读数，若偏差超过阈值则标记故障。
结果对比：实施后，单点故障覆盖率从约60%提升至99%以上，FTA计算出的系统失效率满足ASIL D要求。代价是硬件成本增加约15%，但换来了安全等级的达标。
风险与代价：备份ECU与主ECU之间的切换逻辑本身可能成为新的故障点，因此切换逻辑需经过严格的时序验证。复盘经验：功能安全设计必须在架构阶段就介入，后期打补丁会极大增加验证成本。
3.1.4 常见误区与总结
误区2：忽略软件随机失效。虽然ISO 26262主要针对硬件随机失效，但软件系统性失效（如指针越界）同样会导致安全目标被违反，需通过过程控制来预防。
误区3：安全机制本身不进行安全分析。例如，看门狗电路如果设计不当，可能在正常工作时误复位ECU，反而引发新的风险。
3.2 预期功能安全（SOTIF）在制动系统中的核心原理与实施
3.2.1 核心原理：从“无故障”到“无合理可预见误用”
SOTIF（ISO 21448）关注的是系统在无故障条件下，由于功能不足（如算法对极端工况处理不完善）、性能局限（如传感器探测距离有限）或环境干扰（如电磁干扰、恶劣天气）导致的非预期行为。对于制动系统，典型的SOTIF风险包括：在冰雪路面上ABS（防抱死制动系统）误判为车轮抱死而过度降低制动力，导致制动距离显著增加；或AEB（自动紧急制动）在隧道出口强光下漏检行人。
SOTIF的核心方法论是场景分析与触发条件识别。它将运行场景分为四类：已知安全场景、已知不安全场景、未知不安全场景、未知安全场景。安全设计的任务就是通过仿真和测试，将“未知不安全”转化为“已知不安全”并加以消除，同时扩大“已知安全”的覆盖范围。
3.2.2 判断方法与操作流程：SOTIF的V&V策略
SOTIF的验证与确认（V&V）策略强调基于场景的测试，而非仅依赖里程积累。操作流程如下：
- 场景定义与参数化：建立包含道路几何、路面附着系数、天气、光照、交通参与者行为等参数的场景库。
- 触发条件分析：使用STPA（系统理论过程分析）或头脑风暴法，识别可能导致系统误判的边界条件。例如，路面附着系数从0.8突降至0.2的瞬间，ABS算法可能来不及调整。
- 仿真迭代：在SiL（软件在环）/HiL（硬件在环）环境中进行大规模参数扫描，寻找系统失效边界。
- 实车确认：针对仿真发现的临界场景，设计实车测试用例进行确认。
| 场景类别 | 制动系统示例 | 应对策略 |
|---|---|---|
| 已知安全场景 | 干燥沥青路面直线制动 | 无需额外处理，回归测试即可 |
| 已知不安全场景 | 对开路面（左侧冰、右侧沥青）紧急制动 | 优化ABS控制逻辑，增加横摆力矩补偿 |
| 未知不安全场景 | 涉水后制动盘湿态效能下降 | 通过仿真探索发现，增加制动盘干燥功能 |
| 未知安全场景 | 极端低温下液压油粘度变化 | 持续监控，通过OTA更新优化 |
3.2.3 案例拆解：AEB系统在雨天场景下的SOTIF优化
背景与约束：某AEB系统在雨天高速公路上出现误触发（无碰撞风险时紧急制动），导致后方车辆追尾。系统本身无故障，传感器（毫米波雷达+摄像头）工作正常。
初始现象与目标：误触发率约为每万公里0.3次，虽低于法规要求，但用户投诉率高。目标是将误触发率降至每万公里0.05次以下，同时不降低对真实碰撞的检出率。
关键输入数据：通过数据采集，发现误触发均发生在雨量中等、路面有积水、且前方有大型卡车溅起水雾的场景。雷达信号被水雾反射产生虚假目标。
分析判断过程：团队使用STPA分析，识别出触发条件为“雷达反射截面积（RCS）异常增大且目标速度与自车速度差小于阈值”。进一步仿真发现，水雾的RCS特征与真实金属物体存在差异（如多普勒频移谱展宽）。
实际操作步骤：
- 在雷达信号处理链中增加水雾/雨滴分类器，利用多普勒频谱的展宽特征区分真实目标与雨雾。
- 融合摄像头数据，当摄像头未检测到对应视觉目标时，降低雷达目标的置信度。
- 调整AEB触发逻辑，增加“目标置信度”门槛，仅在置信度超过90%时允许触发紧急制动。
- 在HiL环境中模拟1000种雨天场景，验证优化后的算法。
结果对比：优化后，误触发率降至每万公里0.02次，真实碰撞检出率保持100%。代价是算法复杂度增加，需要更高算力的MCU，且开发周期延长了3个月。
复盘经验：SOTIF问题往往源于传感器物理特性的局限性，而非算法逻辑错误。因此，SOTIF设计必须与传感器选型、信号处理算法协同进行。
3.2.4 常见误区与总结
误区2：过度依赖实车路试。SOTIF要求的是“场景覆盖度”而非“里程数”，100万公里常规路试可能无法覆盖1万个临界场景。
误区3：忽略系统边界条件。例如，制动系统在海拔4000米以上时，真空助力器效率下降，这属于SOTIF范畴，需在标定中考虑。
3.3 网络安全（ISO 21434）在制动系统中的核心原理与实施
3.3.1 核心原理：从“功能安全”到“防攻击安全”
ISO 21434 针对的是恶意攻击对系统造成的威胁。制动系统作为车辆安全关键部件，一旦被攻击者远程控制，后果不堪设想。网络安全的核心目标是保障完整性（制动指令未被篡改）、可用性（攻击者无法使制动系统瘫痪）和机密性（防止制动参数被窃取用于逆向工程）。
其核心方法论是TARA（威胁分析与风险评估），通过识别资产、分析威胁场景、评估攻击可行性与影响，确定网络安全等级（CAL），并据此设计安全机制。
3.3.2 判断方法与操作流程：制动系统网络安全实施要点
制动系统的网络安全设计需贯穿整个生命周期：
- 概念阶段：进行TARA分析，识别关键资产（如制动控制指令、标定参数、安全日志）。
- 开发阶段：实施安全编码规范（如MISRA C）、代码静态分析、渗透测试。
- 生产阶段：确保安全密钥的安全注入与存储。
- 运维阶段：建立安全事件响应机制，支持OTA安全更新。
具体技术措施包括：
- 安全通信：在CAN/CAN FD或以太网上使用SecOC（安全车载通信）机制，对制动相关报文进行认证和新鲜度校验。
- 硬件安全模块（HSM）：在ECU中集成HSM，用于密钥存储和加密运算，防止物理攻击提取密钥。
- 入侵检测系统（IDS）：监控制动总线上的异常报文频率或异常数据模式。
3.3.3 案例拆解：针对制动ECU的CAN总线重放攻击防御
背景与约束：某车型制动系统通过CAN总线接收来自ADAS控制器的自动制动指令。安全团队在渗透测试中发现，攻击者可以通过OBD-II接口接入CAN总线，重放之前捕获的“自动制动”报文，从而在任意时刻触发非预期制动。
初始现象与目标：重放攻击成功率为100%，且无法被驾驶员取消。目标是通过引入SecOC机制，使重放报文在5ms内被识别并丢弃。
关键输入数据：原始制动指令报文ID为0x0C1，周期为20ms，数据长度为8字节，无任何认证字段。
分析判断过程：团队分析认为，仅增加CRC校验不够，因为攻击者可以同时重放CRC。必须引入新鲜度值（Freshness Value），且该值需由收发双方共享的密钥和计数器生成。
实际操作步骤：
- 在制动ECU和ADAS控制器中分别集成HSM，用于存储128位AES密钥。
- 在发送端，将32位消息计数器（MAC）与报文数据一起计算CMAC（Cipher-based Message Authentication Code），并将CMAC截断为32位附加在报文尾部。
- 在接收端，使用相同密钥和本地计数器验证CMAC，若验证失败或计数器值小于等于上次接收值，则丢弃报文。
- 设置降级策略：若连续3次认证失败，则判定为潜在攻击，制动系统切换至“安全模式”，仅允许驾驶员通过物理踏板直接控制液压单元，禁用ADAS自动制动功能。
结果对比：实施后，重放攻击报文在接收端被100%丢弃，且由于降级策略的存在，即使攻击者持续发送伪造报文，驾驶员仍能通过机械/液压备份完成制动。代价是报文长度增加4字节，且ECU唤醒时间增加约10ms（用于密钥协商）。
复盘经验：网络安全设计不能只考虑“防住攻击”，还要考虑“攻击发生时的安全状态”。上述案例中，降级策略的设计借鉴了功能安全中的“安全状态”概念，体现了综合安全设计的价值。
3.3.4 常见误区与总结
误区2：过度加密导致实时性恶化。例如，对每条20ms周期的制动报文进行非对称加密是不现实的，应使用对称加密（如AES-CMAC）并合理截断。
误区3：忽略供应链安全。制动ECU的底层固件可能由第三方提供，若第三方开发环境被入侵，恶意代码可能被植入底层驱动，绕过所有上层安全机制。
3.4 三安融合：综合安全设计方法论与工程实践
3.4.1 统一安全目标分解与安全机制复用
在制动系统开发中，功能安全、SOTIF与网络安全并非线性叠加，而是需要统一规划。例如，功能安全要求“制动压力传感器故障时，应在10ms内检测并降级”，而网络安全要求“防止传感器数据被篡改”。这两个需求可以合并为一个安全机制：传感器数据合理性校验——既检查物理范围（功能安全），又检查报文认证码（网络安全），同时通过冗余传感器交叉验证（同时覆盖功能安全和SOTIF）。
| 安全域 | 典型安全目标 | 可复用安全机制 | 协同设计要点 |
|---|---|---|---|
| 功能安全 | 单点故障下保持50%制动力 | 双通道冗余、看门狗、内存ECC | 冗余通道的切换逻辑需考虑网络安全攻击场景 |
| SOTIF | 低附着路面不误触发ABS | 多传感器融合、场景识别 | 传感器融合算法需对恶意注入的虚假数据鲁棒 |
| 网络安全 | 防止制动指令被篡改 | SecOC、HSM、IDS | SecOC认证失败后的降级策略需满足功能安全ASIL等级 |
3.4.2 综合安全验证与确认策略
综合验证需要在传统的功能安全测试（故障注入、耐久测试）基础上，增加SOTIF场景测试和网络安全渗透测试。建议采用“安全用例矩阵”方法：将每个安全目标分解为可测试的用例，并标注其覆盖的安全域。例如：
- 用例FS-01（功能安全）：注入轮速传感器信号丢失故障，验证ABS在100ms内退出并点亮警告灯。
- 用例SO-01（SOTIF）：在仿真中设置路面附着系数0.1，验证ABS控制频率和压力梯度是否在合理范围。
- 用例CS-01（网络安全）：通过CANoe模拟攻击者发送伪造的制动压力报文，验证SecOC机制在5ms内丢弃报文。
- 用例CM-01（综合）：同时注入传感器故障和网络攻击，验证系统降级策略是否优先保障基础制动功能。
3.4.3 组织与流程保障
综合安全设计需要打破传统部门墙。建议成立跨职能安全团队，由系统架构师牵头，功能安全经理、SOTIF工程师、网络安全工程师共同参与。在开发流程中，应设立联合安全评审点，例如在架构设计评审时，三方共同审查安全机制的兼容性。此外，建立统一的安全需求管理工具（如DOORS或Jama），确保每个安全需求可追溯至具体的架构组件和测试用例。
3.4.4 总结与展望
制动控制系统的安全设计已进入“三安融合”的新阶段。功能安全确保系统“不因自身故障而失效”，SOTIF确保系统“在复杂环境中不产生非预期行为”，网络安全确保系统“不因外部攻击而失控”。三者的综合应用，要求工程师具备系统思维，从架构层面统一规划安全机制，在验证阶段联合测试，在运维阶段持续监控。未来，随着线控制动和自动驾驶的普及，SOTIF和网络安全的权重将进一步提升，而功能安全作为基础保障的地位不会改变。建议企业在实际项目中，以ISO 26262的V模型为骨架，将SOTIF的场景分析和网络安全的TARA活动嵌入到V模型的各个阶段，形成一套统一的安全开发流程，从而在保证安全性的同时，提升开发效率，降低综合成本。