软件架构设计的核心使命把软件安全需求SSR转化成可执行的软件结构确保系统在正常运行和故障情况下都能保持安全。ISO 26262-6对软件架构设计的核心要求根据ISO 26262 Part 6软件架构设计必须满足以下核心要求要求一架构必须可验证软件架构必须能够被验证——也就是说它必须是可测试、可分析、可审查的。如果一个架构“画出来很好看”但没法验证那它就不合格。要求二明确每个组件的“来源”ISO 26262-6:2025新增了一项重要要求必须在架构设计中明确每个软件架构元素的“来源Origin”。来源类型含义对开发的影响SEooC开发独立安全单元基于假设开发需要在集成时验证假设是否成立早期开发复用来自其他项目的成熟模块需要评估是否满足当前安全需求开源开发使用开源代码需要审查许可证和安全合规性全新开发从头开发需要最严格的开发流程和验证为什么这很重要不同来源的软件组件其可信度和验证要求完全不同。明确来源才能针对性地裁剪开发活动。要求三错误检测和错误处理机制ISO 26262-6要求软件架构必须包含错误检测和错误处理机制。ASIL等级越高要求越严格。ASIL等级软件架构的额外要求ASIL A基本错误检测机制ASIL B输入输出数据的范围检查、数据有效性检查ASIL C上述 外部监控ASIL D上述 控制流监视软件冗余设计核心一软件分层架构——“各司其职”软件架构设计首先要解决的是分层问题——把不同职责的软件模块放在不同的层级让它们各司其职、互不干扰。典型的AUTOSAR分层架构在汽车行业AUTOSAR汽车开放系统架构是软件架构的事实标准。Classic PlatformCPAUTOSAR仍是动力、底盘、车身及安全等关键域控制器的核心软件底座承载ASIL-C/D级功能安全要求。典型的AUTOSAR分层架构是这样的每一层的安全职责层级安全职责大白话应用软件层ASW实现具体的功能安全逻辑“干活的人”——负责算出跟车距离、判断是否安全运行时环境RTE安全、可靠地传递数据“送信的人”——确保消息准确送达基础软件层BSW提供安全的基础服务“后勤保障”——操作系统调度、看门狗、诊断⬛硬件层提供安全的物理基础“地基”——MCU、内存、外设核心二免于干扰FFI——“各管各的别互相捣乱”FFIFreedom from Interference免于干扰是ISO 26262软件架构设计中最核心、最关键的概念。FFI的核心思想不同ASIL等级的软件组件必须在时序、内存、信息交换三个维度上互相隔离——低安全等级的故障不能传染给高安全等级。三大干扰类别干扰类别具体表现后果⏱️时序与执行干扰阻塞、死锁、活锁、执行时间错误分配高ASIL任务被饿死错过关键时间窗口内存干扰数据损坏、栈溢出、非法内存访问高ASIL数据被篡改信息交换干扰数据重复、丢失、插入、顺序错误高ASIL收到错误指令如何实现FFI隔离手段大白话实现方式内存分区“不同模块住不同房间”编译器内存映射、MPU硬件保护️内存保护单元MPU“房间门上有锁没钥匙进不去”硬件MPU阻止跨区非法访问⏱️时序保护“轮流用CPU谁也别抢谁的”独立时间片调度、看门狗监控关键设计原则ASIL-D的代码和QM的空调代码在物理内存上被MPU彻底隔开——空调代码就算写飞了也碰不到跟车距离计算的数据。核心三E2E通信保护——“给数据上保险”E2EEnd-to-End通信保护是AUTOSAR中最核心的通信安全机制之一。E2E要解决什么问题在车载网络中数据在传输过程中可能遇到各种“意外”通信故障大白话数据损坏“数据在传输中被干扰了”数据丢失“数据包丢了”数据重复“同样的数据发了两次”数据顺序错误“先发的后到后发的先到”数据插入“收到了不该收到的数据”数据延迟“数据来晚了”E2E的目标确保数据在传输过程中的完整性避免由于噪声、干扰或软件错误导致的数据损坏或失真。E2E的四大保护机制E2E通过对通信数据增加控制字段来实现保护保护机制作用大白话Data ID识别数据属于哪个信号/消息“给每个数据包贴个标签”CRC校验检测数据是否被篡改“给数据包加个防伪码”Counter计数器检测数据是否丢失或重复“给数据包编个号”⏱️超时监控检测数据是否延迟“超过时间没到就报警”E2E在AUTOSAR架构中的位置E2E库通常实现在应用软件层ASW确保应用级的数据通信在发送和接收时的完整性。它支持CAN、LIN、SPI、FlexRay等多种总线并且可以满足最高ASIL D的安全相关通信需求。实战E2E在ACC控制器中的应用场景ACC控制器通过CAN总线接收雷达传感器的目标距离数据没有E2E保护数据在CAN总线上被电磁干扰导致位翻转控制器收到错误数据计算出错误的跟车距离车辆非预期急刹车 有E2E保护发送端数据 DataID CRC Counter接收端校验CRC → 如果不对丢弃数据检查Counter → 如果跳号触发报警控制器只使用验证通过的数据进行计算系统安全 ✅核心四程序流监控——“盯着代码别跑偏”程序流监控Program Flow Monitoring是ISO 26262 Part 6明确要求的关键错误探测安全机制。程序流监控要解决什么问题程序在运行时可能遇到各种“意外”程序流故障大白话程序跑飞“代码跳到不该去的地方了”死锁“两个任务互相等谁都动不了”活锁“两个任务互相让谁都动不了”执行阻塞“某个任务卡住了”执行时间错误“该跑10ms的任务跑了100ms”AUTOSAR看门狗管理器的三种监控机制在AUTOSAR CP架构中程序流监控由看门狗管理器WdgM统一管理监控机制大白话检测什么⏱️死线监控Deadline Monitoring“必须在规定时间内完成”任务执行超时活体监控Alive Monitoring“必须定期报到”任务是否还在运行逻辑监控Logical Monitoring“必须按正确的顺序执行”程序执行顺序是否正确关键点WdgM负责逻辑监控“程序有没有按正确的顺序执行”Wdg Driver负责硬件喂狗“程序有没有在规定时间内喂狗”。实战ACC控制器的程序流监控配置监控实体监控机制配置参数违规处理跟车距离计算任务活体监控周期50ms超时未报到 → 触发MCU复位⏱️跟车距离计算任务死线监控执行时间≤200ms超时 → 触发安全状态主控制循环逻辑监控顺序采集→计算→执行顺序错误 → 触发报警实战ACC控制器软件架构设计完整方案把以上所有内容整合起来ACC控制器的软件架构设计是这样的Step 2FFI隔离设计安全区域包含的SWCASIL等级隔离措施安全关键区雷达数据采集、跟车距离计算、安全状态管理DMPU保护独立内存分区中等安全区数据显示、报警管理B与ASIL-D区域隔离⬜非安全区音乐播放、空调控制QM与安全区域完全隔离Step 3E2E通信保护部署通信路径E2E配置保护机制雷达 → 控制器CANProfile 1DataID CRC8 Counter控制器 → 执行器CANProfile 1DataID CRC8 Counter控制器内部 SWC间通信Profile 4CRC CounterStep 4程序流监控部署监控实体监控机制超时/周期违规响应雷达数据采集任务活体监控50msMCU复位跟车距离计算任务死线监控200ms安全状态主控制循环逻辑监控—报警降级⚠️ 软件架构设计中容易踩的“坑”坑1架构图画得“很好看”但没法验证❌ 画了几个框几条箭头就说“这是功能安全架构”✅ 每个架构决策都必须可追溯、可验证——能追溯到SSR能通过测试验证坑2忘了做FFI❌ 把ASIL-D和QM的代码放在同一个内存区域✅ 不同ASIL等级的组件必须物理隔离——用MPU或独立MCU实现坑3通信没有E2E保护❌ 直接收发CAN数据不做任何校验✅ 安全相关的通信必须加E2E保护——DataID CRC Counter 超时监控坑4只有硬件看门狗没有程序流监控❌ “有硬件看门狗就够了”✅ 硬件看门狗只能检测“程序完全卡死”检测不了“程序跑偏了但还在喂狗”——程序流监控必不可少。