系统架构设计：安全机制的"组织者"
架构设计要满足什么？
ISO 26262-4:2018要求系统架构设计必须考虑以下三个方面：
| 要求 | 大白话 |
|---|---|
| ✅ 验证架构设计的能力 | "这个架构能支撑我们做测试和验证吗？" |
| ✅ 软硬件要素的技术能力 | "选的芯片和软件能实现安全功能吗？" |
| ✅ 系统集成过程中的测试能力 | "把这些零件拼起来的时候，能测吗？" |
简单说：架构不仅要"能实现功能"，还要"能验证、能测试、能集成" 。
架构设计的核心任务
根据ISO 26262-4的要求和行业实践，系统架构设计主要完成以下核心任务：
架构设计的本质：把TSR和安全机制"分配"到具体的架构要素（传感器、控制器、执行器、通信链路）上，并明确它们之间的交互关系。
核心安全机制：架构的"免疫系统"
安全架构设计说白了就三件事：冗余、监控、隔离。
1️⃣ 冗余（Redundancy）------ "多一套备份"
冗余是应对硬件随机失效最直接的手段。ISO 26262要求通过冗余设计实现故障容错。
常见的冗余形式：
| 冗余类型 | 大白话 | 示例 |
|---|---|---|
| 🔄 硬件冗余 | "两个一样的零件，坏了一个另一个顶上" | 双雷达、双MCU、双电源 |
| 🔄 信息冗余 | "多传一份数据，错了能发现" | CRC校验、ECC内存 |
| 🔄 时间冗余 | "多做一遍，确认结果一致" | 重试机制、超时重传 |
| 🔄 软件冗余 | "两套不同的算法算同一个结果" | 双路冗余算法、多数投票 |
传感器冗余采集对于ASIL C/D等级的信号尤其重要。可以是两个相同的传感器对同一信号重复采集（如踏板位置信号），也可以是不同类型的传感器对强相关的两个信号分别采集（如制动踏板位置和制动压力信息）。
实战案例：特斯拉早期FSD版本采用"双通道对称热备冗余架构"，核心是"同构并行+投票仲裁"设计，以满足ISO 26262 ASIL-D功能安全等级。
2️⃣ 监控与诊断（Monitoring & Diagnosis）------"时刻盯着，出问题马上知道"
冗余是"备胎"，但前提是你得知道主胎爆了。监控和诊断就是干这个的。
传感器信号的监控手段：
| 监控手段 | 大白话 |
|---|---|
| 📊 数值有效范围检测 | "信号在不在合理范围内？" |
| 🔄 在线监控 | "实时盯着，一有异常就报警" |
| 🧪 Test Pattern | "定期发个测试信号，看响应对不对" |
| 📊 输入对比 | "两个传感器信号对比，差异大了就有问题" |
| 🧠 相关性检测 | "这个信号和那个信号应该有关系，没关系就有问题" |
| ✅ 合理性检测 | "这个值在这个场景下合理吗？" |
控制单元的监控通常包括：看门狗定时器（监测程序是否跑飞）、程序流监控（检查代码执行顺序是否正确）、内存测试（ECC校验、BIST）等。
3️⃣ 隔离（Isolation）------"各管各的，别互相干扰"
不同ASIL等级的组件必须实现 "免于干扰（Freedom from Interference）" 。
低安全等级（QM）或较低ASIL等级的组件必须与高ASIL等级组件实现隔离。
可能导致干扰的故障类别：
| 故障类别 | 具体表现 |
|---|---|
| ⏱️ 时序与执行问题 | 阻塞、死锁、活锁 |
| 💾 内存错误 | 数据损坏、栈溢出、非法内存访问 |
| 📡 信息交换异常 | 数据重复、丢失、插入 |
隔离的实现手段：
最佳实践：在软件编译和持续集成（CI）阶段即引入自动化架构检查机制，确保不同ASIL等级的组件之间不存在非法的访问或调用关系。
两种安全架构模式：Fail-Safe vs Fail-Operational
ISO 26262-4的系统架构设计涉及两种根本不同的安全策略：
🛑 Fail-Safe（故障安全）
核心理念：出故障了就停下来。
"系统检测到故障 → 进入安全状态 → 停止工作"
适用场景：非关键功能、故障后停车不危险的场景。
示例：车身控制模块（BCM）检测到故障后，退出ACC并发出声光报警------车还能开，但智驾功能停了。
🔄 Fail-Operational（故障运行）
核心理念：出故障了还要继续跑。
"系统检测到故障 → 切换到冗余通道 → 继续工作"
适用场景：关键安全功能、故障后不能停车的场景。
示例：线控制动系统------刹车失效了不能直接"停下来"，必须切换到备用通道继续提供制动力。
💡 Fail-Operational需要大量的硬件冗余和多样化的软件设计 ，直接提高了系统成本。所以在汽车产品中一般最多只有两个独立功能链路 。最典型的是1oo2架构（1 out of 2）------两个通道，任何一个正常工作，系统就能继续运行。
典型应用：自动驾驶系统、线控转向、线控制动等L3以上自动驾驶相关的安全关键系统。
实战：ACC系统安全架构设计
把前面讲的这些概念，用到ACC系统上。
Step 1：回顾TSR（上期的产出）
| ID | 技术安全需求 | ASIL | 分配给谁 |
|---|---|---|---|
| TSR-01-01 | 选用77GHz毫米波雷达，探测距离≥200m | D | 雷达硬件 |
| TSR-01-02 | 全温度范围内测距精度±2m | D | 雷达硬件+软件 |
| TSR-01-03 | 上电时执行自检 | D | 雷达固件 |
| TSR-01-04 | 每50ms通过CAN-FD发送数据 | D | 雷达软件 |
| TSR-02-01 | 选用ASIL-D等级的MCU | D | 控制器硬件 |
| TSR-02-02 | 运行在QNX安全操作系统上 | D | 控制器软件 |
| TSR-02-03 | 使用双路冗余算法计算跟车距离 | D | 控制器软件 |
| TSR-03-01 | 制动执行器支持减速度限制功能 | D | 执行器硬件 |
| TSR-03-02 | 监控实际减速度，超限时切断指令 | D | 执行器软件 |
Step 2：设计架构拓扑
ACC系统的基本架构是标准的 "传感器→控制器→执行器" 三明治结构：
Step 3：逐层部署安全机制
🟢 传感器层------冗余+监控
| 安全机制 | 具体做法 | 对应TSR |
|---|---|---|
| 🔄 硬件冗余 | 双雷达（77GHz×2）+ 前向摄像头 | TSR-01-01 |
| 🔍 信号合理性检查 | 距离值在0-250m范围内、变化率不超过物理极限 | TSR-01-02 |
| 🔍 上电自检 | 雷达上电100ms内完成自检 | TSR-01-03 |
| 🔍 通信监控 | CAN-FD超时50ms触发报警 | TSR-01-04 |
💡 传感器输入冗余信息在控制单元中必须进行多路采集，除传感器本身提供诊断信息外，还需要对其信号有效性进行检验。
🟡 控制器层------监控+隔离
| 安全机制 | 具体做法 | 对应TSR |
|---|---|---|
| 🔄 硬件冗余 | 选用ASIL-D等级的MCU | TSR-02-01 |
| 🔒 软件隔离 | QNX操作系统，内存分区隔离 | TSR-02-02 |
| 🧠 算法冗余 | 双路独立算法计算跟车距离，结果对比 | TSR-02-03 |
| ⏱️ 超时监控 | 计算超过300ms触发报警 | TSR-02-04 |
🔴 执行器层------限幅+监控
| 安全机制 | 具体做法 | 对应TSR |
|---|---|---|
| 🛡️ 输出限幅 | 最大减速度不超过X m/s² | TSR-03-01 |
| 🔍 实际值监控 | 实时监控实际减速度，超限时100ms内切断指令 | TSR-03-02 |
Step 4：整合为系统安全架构图
这个架构体现了 Fail-Operational 的设计思想------即使主通道（雷达1→主MCU→主制动执行器）完全失效，备用通道（雷达2→监控MCU→备用制动执行器）仍然能让车辆安全减速。
行业实战案例：地平线HSD 600域控制器
2026年7月，地平线HSD 600域控制器正式通过UL Solutions的ISO 26262功能安全产品认证，达到汽车功能安全最高等级ASIL-D。
这个案例为什么值得关注？
HSD 600域控制器从设计之初即按照ASIL D目标进行开发，在电源管理、计算冗余、通信链路等方面均内置了安全机制。此次认证过程中，UL Solutions对其功能安全开发流程、系统架构设计、软硬件实现及验证确认等环节进行了全维度审核。
关键洞察 ：ASIL-D等级的达成，意味着该域控制器在随机硬件失效和系统性失效两方面均具备极高的风险控制能力。
行业影响：
目前英伟达Orin、高通Snapdragon Ride等主流智驾平台均已通过或正在推进ASIL-D级别的功能安全认证。地平线HSD 600进入这一阵营，意味着国产智驾域控在安全合规层面已与国际一线方案站在同一竞争维度。
对于采用地平线方案的车企而言，HSD 600的ASIL-D认证可以降低整车级功能安全验证的复杂度，缩短从方案定型到量产交付的时间。
架构设计中容易踩的"坑"
坑1：只有冗余，没有监控
❌ "我放了两个雷达，够安全了吧？"------但如果第一个雷达坏了你不知道，它一直发错误数据，第二个雷达也被带偏了呢？
✅ 冗余 + 监控："两个雷达+信号对比+合理性检查，发现差异立即报警"
坑2：不同ASIL等级的组件没有隔离
❌ 把ASIL-D的刹车控制和QM的空调控制放在同一个MCU上，没有做内存分区
✅ 要么用两个独立的MCU，要么通过MPU/Hypervisor做分区隔离
坑3：只有Fail-Safe，没有Fail-Operational
❌ "检测到故障就停车"------在高速上突然停车可能比继续跑更危险
✅ 关键系统需要Fail-Operational设计------出故障了还能继续安全运行一段时间
坑4：架构设计完成后就不管了
❌ 架构图画完就扔一边，后面开发全凭工程师个人理解
✅ 建立架构与代码的映射关系，通过自动化工具持续检查架构一致性