功能安全做到架构设计这一层最明显的感受是前面那些在会议纪要里拍板的概念到这里必须全部变成能画进结构图、能写进接口定义、能拿来评审的东西。这个系列写到第六篇默认你已经看过了HARA、ASIL等级、安全目标推导这些基础内容这篇专门看技术安全架构TSC也就是安全目标怎么落到ECU内外的硬件结构和软件结构上。这个阶段做得扎实后面的软件安全机制、硬件故障注入测试、安全案例论证都会顺手很多做不扎实后面每一步都是在给前面补漏。我见过不少项目把架构设计当成概念阶段的大饼画两张框图画完了事真正的问题几乎都集中在安全目标和技术需求之间缺了一条可追踪的链路。今天这篇不聊概念聊我实际画图、出文档、被评审专家怼过之后总结出来的一套做法。1. 技术安全架构到底在架构什么从FSC到TSC的输入与边界1.1 架构师手里必须有的输入清单很多刚接触功能安全的人以为架构设计是从零开始的创造实际恰恰相反真正的架构设计是在一系列已经确定的约束条件里做决策。到了技术安全架构这一步你手里至少要有一份完整的输入清单项目定义Item Definition边界、功能、运行场景、车辆级别的外部接口安全目标Safety Goal带ASIL等级、带安全状态Safe State的基本要求功能安全概念FSC功能层面的安全措施和降级策略初步的软硬件技术方案传感器、控制器、执行器、通信链路的可用元素外部措施External Measures比如维修保养、驾驶员提示能否作为安全措施的一部分。我踩过的坑是项目把安全目标写得挺清晰比如车辆不得发生非预期加速但安全状态的时间约束完全没写也就是在多长时间内必须进入安全状态。结果架构设计时所有安全机制的响应时间都是我自己猜的评审时根本站不住脚。所以每次架构启动前我第一件事就是先填一张输入检查表把缺失的信息列出来缺一项就在方案里明确一项假设并让项目经理推动补齐。1.2 功能安全概念到技术安全需求的那条转换链路FSC回答的是功能层面要做什么TSC回答的是用什么样的电气、电子和软件结构来实现。这条转换不是简单的翻译而是要做一次真正的需求细化。我习惯用一张映射表把这条链路锁住保证每个安全目标都能往下钻到具体的架构元素。安全目标功能安全概念技术安全需求TSR涉及架构元素典型安全机制防止转向系统非预期输出扭矩检测到扭矩异常后进入降级转向模式1. 扭矩传感器信号在50ms内完成合理性检查2. 检测出异常后在FTTI内切断助力并点亮提示转向控制器、扭矩传感器、助力电机、主继电器、CAN通信传感器交叉校验、E2E保护、看门狗、安全关断路径防止电池过充引发热失控电压和温度超限时降低充电电流1. 采样电路失效应被探测2. 电流限制指令应在100ms内生效BMS控制器、电流传感器、接触器、充电机诊断覆盖率、失效探测、冗余梯度限制这张表做出来之后技术安全需求不是一个人拍脑袋生成的而是从每个安全目标逐条走下来的。架构评审时你要能指着某一条TSR说它对应哪个安全目标、由哪个元素承担、靠什么机制实现这一条线打通了后面所有的工作都只是在这条线上添枝加叶。1.3 别小看中间层系统、硬件、软件三个视角怎么对齐技术安全架构说起来是一个词实际至少分三个视角系统架构ECU和传感器执行器之间的拓扑、软件架构任务的划分、模块之间的接口、运行调度、硬件架构主控、外设、电源、通信物理层。很多项目就把系统拓扑画一画软件和硬件架构直接甩给软硬件团队结果就是接口处经常断裂。软硬件接口HSI就是用来堵这个窟窿的核心文档我后面专门用一节讲它。这里先说一个原则做架构设计时三个视角必须统一到同一套技术安全需求上。比如TSR要求主控必须能在20ms内检测到看门狗超时那在系统架构里要看到看门狗所在的位置在软件架构里要看到定时任务和中断的分配在硬件架构里要看到看门狗的中断连接和供电关系。任何一条TSR如果在这三个视角里找不到完整的落点就是架构还没设计完。2. 安全机制分配的底层逻辑探测、控制、规避与降级2.1 架构上放安全机制不是越多越好安全机制到了架构层我会先按功能分成四类再决定往哪儿放类别作用典型实现故障探测发现故障的存在传感器合理性检查、E2E CRC、硬件自检MBIST、电压/时钟/温度监测、看门狗故障控制让系统进入或维持安全状态切断输出、切换到冗余通道、限制扭矩、进入跛行模式故障规避降低故障发生概率或影响加大器件降额、散热设计、冗余独立供电、物理隔离故障报告对外给出可观测的状态故障码DTC、故障指示灯、健康状态信号最难的是决定控制类机制放在哪一层。比如切断助力这条机制你可以让应用层软件发指令也可以让硬件安全监控芯片直接切断主继电器。架构设计的核心决策就是故障探测和控制最好不在同一个执行链路上。我在EPS项目里做过一次评审机制设计得看起来非常完善但仔细一查探测到故障的软件和安全关断的执行软件跑在同一个任务里一旦这个任务跑飞探测和执行同时失效。最后我们把硬件看门狗独立成一个安全路径通过HSI直接关断功率级才算把这条链路做稳。2.2 FTTI和故障假设如何反过来塑造架构FTTIFault Tolerant Time Interval故障容错时间间隔是架构设计里最能体现架构服务于安全需求的参数。它定义的是从故障发生到系统进入安全状态所允许的最大时间。这个时间一旦定死架构就必须反过来计算故障探测需要多长时间安全机制响应需要多长时间安全状态建立需要多长时间这三段时间相加不允许超过FTTI。举一个简单的例子假设一个安全目标要求电机堵转时1秒内切断输出而FTTI给的是200ms那探测器就不能依赖一个周期100ms的任务去采样因为探测要花100ms加上仲裁、执行、继电器动作铁定超时。这时架构上通常会把采样和判断放到ISR或者更高优先级的周期任务里把执行路径从应用层简化成硬件直连。架构评审时我几乎必问每条安全目标的FTTI是多少对应安全机制的探测时间响应时间安全状态建立时间是多少时序预算表要一张一张算出来不然架构只是画了个布局根本证明不了安全目标可实现。2.3 ASIL分解的架构前提独立性不是免责声明ASIL分解是架构设计里最容易被误用的一招。很多人把ASIL D拆成这个模块ASIL B那个模块ASIL B好像标注一下就完事了。但ISO 26262里ASIL分解必须满足一个硬前提分解后的各个元素要足够独立否则两个元素同时失效的风险依然把整体等级拉回原始级别。常见合法的分解方式里有D拆成C(D)A(D)、B(D)B(DC拆成B(C)A(C这种结构。括注里那个(D)表示这个ASIL等级是从D分解来的评审时一眼就能看出来源。我在架构里做ASIL分解时一定会同时画一份独立性分析并记录分解依据供电独立吗时钟独立吗内存和总线是否共享故障会不会从一方串扰到另一方早年间一个项目两个控制通道一个用模拟电源一个用DCDC电源看起来是独立了DFA一查发现两个电源共有一个输入滤波器一个浪涌可能同时打掉两个通道。那这个ASIL DM分解就是不成立的。所以架构设计里独立性不是一个形容词是要用具体结构和分析报告去证明的设计约束。3. HSI与软硬件协同安全机制最容易在这里断头3.1 HSI文档里必须写清的五类信息HSIHardware Software Interface是技术安全架构和软硬件详细设计之间的桥梁。很多团队把它当成一张寄存器地址表这是远远不够的。我一般要求HSI至少包含这五类信息软件元素与硬件元素的映射关系哪个软件模块跑在哪个MCU核上访问哪些外设资源依赖内存地址范围、中断号、DMA通道、定时器、IO引脚时序和带宽约束中断响应时间、通信周期、CPU占用预算、总线负荷限额配置约束和假设硬件寄存器的访问权限、初始化顺序、看门狗窗口参数安全相关接口语义哪条命令是安全关断指令哪个状态位是故障状态由谁读、谁写。其中最容易漏的是第四类。有一次我们的安全机制软件需要一个硬件看门狗提供刷新窗口软件工程师就按自己理解写了一个30ms窗口的刷新逻辑结果硬件实际只支持15ms窗口两条链路各说各话。后来每次架构评审我都要专门查HSI里安全机制相关的参数是否完整、有没有歧义。3.2 软件组件鉴定报告复用的边界和架构的责任现在越来越多项目开始复用经过认证的软件组件比如经鉴定的操作系统、安全通信栈、诊断协议栈。复用本身没问题但架构设计必须承接一个关键输入ISO 26262软件组件鉴定报告Software Component Qualification Report。我理解这份鉴定报告不是这个软件随便用就安全的通行证它本质上附带一整套使用条件和使用假设Assumptions of UseAoU。架构设计要做的第一件事是把AoU逐条映射到当前项目的技术安全需求上。举个例子某个经鉴定的实时操作系统鉴定报告里假设支持的调度策略限定为固定优先级抢占式调度最大任务数不超过64个不支持动态内存分配。而你的架构里偏偏想用一个内存池动态创建任务那这个软件组件鉴定报告的覆盖范围就断掉了。要么改架构匹配AoU要么重新做补充验证信息安全的活儿不能后续甩给软件团队去猜边界。架构图上每一个复用组件都应该标注它的鉴定等级、覆盖版本和AoU引用这是评审时最常见的追问点。3.3 一个典型的电源管理安全机制分配实例拿整车控制器一个常见的安全机制来串一遍关断对外输出。先说需求安全目标要求检测到主控异常时必须切断对外高边输出。架构分解下来有三个元素主控软件负责故障判断硬件安全监控芯片负责独立监测和决策高边驱动器作为最终执行器。此时的架构会在HSI里定义主控通过SPI向监控芯片写入刷新码如果监控芯片在100ms内没有收到有效刷新码就直接拉低高边驱动器的使能引脚同时主控采集这个使能状态用于故障报告。这套机制真正的架构价值在于独立监控芯片的供电和参考电压与主控分开刷新码路径和应用输出路径分离监控芯片的动作不需要主控参与。如果架构只是简单地在软件里加一个if判断去关输出一旦主控跑飞整个判断都不可靠。所以每次设计安全关断路径我都会问一句这条路径上最底层的兜底者是谁它是否需要依赖那个可能已经出问题的元素4. 免干扰FFI不是概念是架构设计约束4.1 四类FFI隔离手段及其取舍FFIFreedom From Interference是我在架构评审里见过最多嘴上说了、图上没做的一项。它要求一个元素失效时不会影响另一个元素的安全功能。落到架构层主要就是四类隔离隔离维度常用手段典型适用场景空间隔离MPU/MMU内存保护、独立核分配、虚拟化分区ASIL不同等级的软件共用一个CPU时间隔离固定周期调度、预算监控、中断优先级隔离高ASIL任务不被低ASIL任务挤占时间带宽和资源隔离通信带宽限流、DMA通道分离、环形缓冲区防阻塞通信栈和诊断服务共存的总线拓扑隔离独立供电、独立时钟、独立通信链路双通道冗余架构实际项目里最常出现的是高ASIL和低ASIL的软件模块共享同一个全局变量或者共享同一个DMA缓冲区。硬件上MMU能挡住非法内存访问但挡不住模块自己写坏了共享数据。所以架构设计阶段就要规定清楚哪些内存区域归属于哪个隔离域域之间的所有数据交换只能通过受控的安全接口。4.2 架构评审阶段怎么提前证明FFI很多团队把FFI的验证拖到软件集成测试阶段这是最贵的做法。架构阶段能做很多推演我常用的是两条线第一条线叫共享资源清单。把所有ASIL分解元素和不同ASIL的软件元素开列出来逐一列出它们共享的硬件资源总线、内存、中断、时钟、电源、DMA、调试接口。然后针对每个共享项做失效影响判断这个资源坏了会不会影响安全元素第二条线是时序预算。时间隔离不是说任务优先级高就够了要证明高优先级任务的最坏执行时间加上中断阻塞时间依然满足FTTI。架构评审时我会拿一张表让团队把所有任务的周期、最坏执行时间、最大阻塞时间填出来做一次可调度性初算。这道工序在架构阶段就能暴露出大量问题不用等代码写完再去panic。4.3 常见的FFI架构缺陷清单这些坑我基本每个项目都遇到过至少一个调试接口没有隔离JTAG口直接挂在ASIL D的核上调试工具故障或误操作就可能干扰时序看门狗被低ASIL任务共享低ASIL任务卡死时它不仅饿死高ASIL任务还把看门狗刷新一起弄崩中断服务函数里做了过多计算高优先级中断把安全任务的时间挤占FTTI预算直接破掉通信协议没有设计故障检测CAN节点静默了接收方要等超时才发现架构上没有快速故障通告通道。我通常把这些写进架构评审检查单每一条都要有明确的责任人去落实。FFI不是测试阶段靠几个测试用例能覆盖干净的它是架构设计初期就要逐条推演出来的结构性决策。5. 架构评估与安全论据从架构图到安全案例5.1 架构层的DFA和FTA用分析提前验证决策到了架构评估环节我常用的两个工具不是画图而是DFADependent Failure Analysis相依失效分析和FTAFault Tree Analysis故障树分析。FTA在架构层的作用是从每个安全目标出发把可能导致安全目标失效的故障组合一层层展开到架构元素。比如非预期转向输出这个顶事件往下会有信号错误、执行器卡滞、控制算法异常、电源失效等分支。FTA能帮架构师看清楚哪些底层故障必须靠架构冗余来覆盖哪些靠安全机制就足够。DFA则更关注元素之间的依赖性共因失效、级联失效。我的经验是DFA不用做到极致穷尽先把ASIL分解出来的各条独立路径拿出来找它们之间的共享点和耦合点逐个分析。某次评审一条冗余通信链路看起来是两条CAN总线很独立但DFA发现两个CAN控制器用了同一个中断控制器一个中断控制器故障直接同时干掉两条路。这个发现直接改掉了硬件方案。5.2 安全论据怎么写才不是抄标准安全案例Safety Case现在越来越被重视但很多项目把安全案例写成了我们遵守了ISO 26262哪些条款的清单这没有任何说服力。架构阶段就应该开始沉淀安全论据核心是声明支撑证据的结构架构声明包括所有安全目标都已经分配到架构元素、ASIL分解的各元素之间独立性已实现、所有安全机制的响应时间满足FTTI。我在项目里会为每条关键声明写一个小的论据片段里面注明支撑证据指向哪些文档和哪些分析记录。比如独立性已实现这个声明支撑它的是共享资源清单、DFA报告、HSI里的隔离配置。证据如果暂时缺位我会把它标记为开放项并给截止日期而不是留在评审时嘴上说一句后面补。5.3 变更影响分析架构设计是持续工作架构不是一张静态图开发过程中经常会变更换一个传感器型号、改一个通信周期、增加一个诊断功能。每次变更都要做影响分析范围不能只看这个模块改成什么样要看变化会不会触及安全目标和技术安全需求。我的做法是维护一张安全目标-TSR-架构元素-安全机制的完整追踪矩阵变更请求一进来先在这个矩阵上跑一遍影响范围。有一次只是把电源管理芯片换成了pin-to-pin兼容的型号看起来完全匹配但新芯片的诊断输出极性反了HSI里配置错误安全监控机制直接失效。这种问题靠相当然根本防不住只有靠矩阵式追踪和架构级影响分析才能兜住。6. 架构评审清单每次过架构我都带着这张表最后分享一张我每次做技术安全架构评审都会过一遍的检查单不一定能覆盖所有场景但能帮团队把最常见的问题拦在集成之前。检查项判断标准安全目标覆盖每个安全目标都能在架构上找到至少一条完整的实现链TSR可追踪每条TSR都能追溯到FSC和安全目标并能落到具体元素FTTI预算探测响应安全状态建立时间之和有明确证据证明小于FTTIASIL分解独立性每个ASIL分解都伴随独立性分析和DFA结论HSI完整性安全相关接口的时序、配置、语义均已闭环FFI证据共享资源清单、内存隔离配置、调度预算表格可查可审软件组件复用边界鉴定报告覆盖范围与项目实际使用条件完全匹配安全关机路径存在不依赖已失效元素的最底层兜底机制功能安全架构设计做到最后其实拼的是闭环两个字需求到结构有闭环机制到证据有闭环分析到追踪有闭环。每张架构图背后都要跟得上一套能支撑它的分析和数据否则图再好看评审专家、认证审核员那边也过不去。第六篇就先写到这下一篇我计划专门展开软件架构层里的安全机制时序设计把调度和FTTI怎么算账的事情讲透。
功能安全技术安全架构设计：从安全目标到落地的关键实践
功能安全做到架构设计这一层最明显的感受是前面那些在会议纪要里拍板的概念到这里必须全部变成能画进结构图、能写进接口定义、能拿来评审的东西。这个系列写到第六篇默认你已经看过了HARA、ASIL等级、安全目标推导这些基础内容这篇专门看技术安全架构TSC也就是安全目标怎么落到ECU内外的硬件结构和软件结构上。这个阶段做得扎实后面的软件安全机制、硬件故障注入测试、安全案例论证都会顺手很多做不扎实后面每一步都是在给前面补漏。我见过不少项目把架构设计当成概念阶段的大饼画两张框图画完了事真正的问题几乎都集中在安全目标和技术需求之间缺了一条可追踪的链路。今天这篇不聊概念聊我实际画图、出文档、被评审专家怼过之后总结出来的一套做法。1. 技术安全架构到底在架构什么从FSC到TSC的输入与边界1.1 架构师手里必须有的输入清单很多刚接触功能安全的人以为架构设计是从零开始的创造实际恰恰相反真正的架构设计是在一系列已经确定的约束条件里做决策。到了技术安全架构这一步你手里至少要有一份完整的输入清单项目定义Item Definition边界、功能、运行场景、车辆级别的外部接口安全目标Safety Goal带ASIL等级、带安全状态Safe State的基本要求功能安全概念FSC功能层面的安全措施和降级策略初步的软硬件技术方案传感器、控制器、执行器、通信链路的可用元素外部措施External Measures比如维修保养、驾驶员提示能否作为安全措施的一部分。我踩过的坑是项目把安全目标写得挺清晰比如车辆不得发生非预期加速但安全状态的时间约束完全没写也就是在多长时间内必须进入安全状态。结果架构设计时所有安全机制的响应时间都是我自己猜的评审时根本站不住脚。所以每次架构启动前我第一件事就是先填一张输入检查表把缺失的信息列出来缺一项就在方案里明确一项假设并让项目经理推动补齐。1.2 功能安全概念到技术安全需求的那条转换链路FSC回答的是功能层面要做什么TSC回答的是用什么样的电气、电子和软件结构来实现。这条转换不是简单的翻译而是要做一次真正的需求细化。我习惯用一张映射表把这条链路锁住保证每个安全目标都能往下钻到具体的架构元素。安全目标功能安全概念技术安全需求TSR涉及架构元素典型安全机制防止转向系统非预期输出扭矩检测到扭矩异常后进入降级转向模式1. 扭矩传感器信号在50ms内完成合理性检查2. 检测出异常后在FTTI内切断助力并点亮提示转向控制器、扭矩传感器、助力电机、主继电器、CAN通信传感器交叉校验、E2E保护、看门狗、安全关断路径防止电池过充引发热失控电压和温度超限时降低充电电流1. 采样电路失效应被探测2. 电流限制指令应在100ms内生效BMS控制器、电流传感器、接触器、充电机诊断覆盖率、失效探测、冗余梯度限制这张表做出来之后技术安全需求不是一个人拍脑袋生成的而是从每个安全目标逐条走下来的。架构评审时你要能指着某一条TSR说它对应哪个安全目标、由哪个元素承担、靠什么机制实现这一条线打通了后面所有的工作都只是在这条线上添枝加叶。1.3 别小看中间层系统、硬件、软件三个视角怎么对齐技术安全架构说起来是一个词实际至少分三个视角系统架构ECU和传感器执行器之间的拓扑、软件架构任务的划分、模块之间的接口、运行调度、硬件架构主控、外设、电源、通信物理层。很多项目就把系统拓扑画一画软件和硬件架构直接甩给软硬件团队结果就是接口处经常断裂。软硬件接口HSI就是用来堵这个窟窿的核心文档我后面专门用一节讲它。这里先说一个原则做架构设计时三个视角必须统一到同一套技术安全需求上。比如TSR要求主控必须能在20ms内检测到看门狗超时那在系统架构里要看到看门狗所在的位置在软件架构里要看到定时任务和中断的分配在硬件架构里要看到看门狗的中断连接和供电关系。任何一条TSR如果在这三个视角里找不到完整的落点就是架构还没设计完。2. 安全机制分配的底层逻辑探测、控制、规避与降级2.1 架构上放安全机制不是越多越好安全机制到了架构层我会先按功能分成四类再决定往哪儿放类别作用典型实现故障探测发现故障的存在传感器合理性检查、E2E CRC、硬件自检MBIST、电压/时钟/温度监测、看门狗故障控制让系统进入或维持安全状态切断输出、切换到冗余通道、限制扭矩、进入跛行模式故障规避降低故障发生概率或影响加大器件降额、散热设计、冗余独立供电、物理隔离故障报告对外给出可观测的状态故障码DTC、故障指示灯、健康状态信号最难的是决定控制类机制放在哪一层。比如切断助力这条机制你可以让应用层软件发指令也可以让硬件安全监控芯片直接切断主继电器。架构设计的核心决策就是故障探测和控制最好不在同一个执行链路上。我在EPS项目里做过一次评审机制设计得看起来非常完善但仔细一查探测到故障的软件和安全关断的执行软件跑在同一个任务里一旦这个任务跑飞探测和执行同时失效。最后我们把硬件看门狗独立成一个安全路径通过HSI直接关断功率级才算把这条链路做稳。2.2 FTTI和故障假设如何反过来塑造架构FTTIFault Tolerant Time Interval故障容错时间间隔是架构设计里最能体现架构服务于安全需求的参数。它定义的是从故障发生到系统进入安全状态所允许的最大时间。这个时间一旦定死架构就必须反过来计算故障探测需要多长时间安全机制响应需要多长时间安全状态建立需要多长时间这三段时间相加不允许超过FTTI。举一个简单的例子假设一个安全目标要求电机堵转时1秒内切断输出而FTTI给的是200ms那探测器就不能依赖一个周期100ms的任务去采样因为探测要花100ms加上仲裁、执行、继电器动作铁定超时。这时架构上通常会把采样和判断放到ISR或者更高优先级的周期任务里把执行路径从应用层简化成硬件直连。架构评审时我几乎必问每条安全目标的FTTI是多少对应安全机制的探测时间响应时间安全状态建立时间是多少时序预算表要一张一张算出来不然架构只是画了个布局根本证明不了安全目标可实现。2.3 ASIL分解的架构前提独立性不是免责声明ASIL分解是架构设计里最容易被误用的一招。很多人把ASIL D拆成这个模块ASIL B那个模块ASIL B好像标注一下就完事了。但ISO 26262里ASIL分解必须满足一个硬前提分解后的各个元素要足够独立否则两个元素同时失效的风险依然把整体等级拉回原始级别。常见合法的分解方式里有D拆成C(D)A(D)、B(D)B(DC拆成B(C)A(C这种结构。括注里那个(D)表示这个ASIL等级是从D分解来的评审时一眼就能看出来源。我在架构里做ASIL分解时一定会同时画一份独立性分析并记录分解依据供电独立吗时钟独立吗内存和总线是否共享故障会不会从一方串扰到另一方早年间一个项目两个控制通道一个用模拟电源一个用DCDC电源看起来是独立了DFA一查发现两个电源共有一个输入滤波器一个浪涌可能同时打掉两个通道。那这个ASIL DM分解就是不成立的。所以架构设计里独立性不是一个形容词是要用具体结构和分析报告去证明的设计约束。3. HSI与软硬件协同安全机制最容易在这里断头3.1 HSI文档里必须写清的五类信息HSIHardware Software Interface是技术安全架构和软硬件详细设计之间的桥梁。很多团队把它当成一张寄存器地址表这是远远不够的。我一般要求HSI至少包含这五类信息软件元素与硬件元素的映射关系哪个软件模块跑在哪个MCU核上访问哪些外设资源依赖内存地址范围、中断号、DMA通道、定时器、IO引脚时序和带宽约束中断响应时间、通信周期、CPU占用预算、总线负荷限额配置约束和假设硬件寄存器的访问权限、初始化顺序、看门狗窗口参数安全相关接口语义哪条命令是安全关断指令哪个状态位是故障状态由谁读、谁写。其中最容易漏的是第四类。有一次我们的安全机制软件需要一个硬件看门狗提供刷新窗口软件工程师就按自己理解写了一个30ms窗口的刷新逻辑结果硬件实际只支持15ms窗口两条链路各说各话。后来每次架构评审我都要专门查HSI里安全机制相关的参数是否完整、有没有歧义。3.2 软件组件鉴定报告复用的边界和架构的责任现在越来越多项目开始复用经过认证的软件组件比如经鉴定的操作系统、安全通信栈、诊断协议栈。复用本身没问题但架构设计必须承接一个关键输入ISO 26262软件组件鉴定报告Software Component Qualification Report。我理解这份鉴定报告不是这个软件随便用就安全的通行证它本质上附带一整套使用条件和使用假设Assumptions of UseAoU。架构设计要做的第一件事是把AoU逐条映射到当前项目的技术安全需求上。举个例子某个经鉴定的实时操作系统鉴定报告里假设支持的调度策略限定为固定优先级抢占式调度最大任务数不超过64个不支持动态内存分配。而你的架构里偏偏想用一个内存池动态创建任务那这个软件组件鉴定报告的覆盖范围就断掉了。要么改架构匹配AoU要么重新做补充验证信息安全的活儿不能后续甩给软件团队去猜边界。架构图上每一个复用组件都应该标注它的鉴定等级、覆盖版本和AoU引用这是评审时最常见的追问点。3.3 一个典型的电源管理安全机制分配实例拿整车控制器一个常见的安全机制来串一遍关断对外输出。先说需求安全目标要求检测到主控异常时必须切断对外高边输出。架构分解下来有三个元素主控软件负责故障判断硬件安全监控芯片负责独立监测和决策高边驱动器作为最终执行器。此时的架构会在HSI里定义主控通过SPI向监控芯片写入刷新码如果监控芯片在100ms内没有收到有效刷新码就直接拉低高边驱动器的使能引脚同时主控采集这个使能状态用于故障报告。这套机制真正的架构价值在于独立监控芯片的供电和参考电压与主控分开刷新码路径和应用输出路径分离监控芯片的动作不需要主控参与。如果架构只是简单地在软件里加一个if判断去关输出一旦主控跑飞整个判断都不可靠。所以每次设计安全关断路径我都会问一句这条路径上最底层的兜底者是谁它是否需要依赖那个可能已经出问题的元素4. 免干扰FFI不是概念是架构设计约束4.1 四类FFI隔离手段及其取舍FFIFreedom From Interference是我在架构评审里见过最多嘴上说了、图上没做的一项。它要求一个元素失效时不会影响另一个元素的安全功能。落到架构层主要就是四类隔离隔离维度常用手段典型适用场景空间隔离MPU/MMU内存保护、独立核分配、虚拟化分区ASIL不同等级的软件共用一个CPU时间隔离固定周期调度、预算监控、中断优先级隔离高ASIL任务不被低ASIL任务挤占时间带宽和资源隔离通信带宽限流、DMA通道分离、环形缓冲区防阻塞通信栈和诊断服务共存的总线拓扑隔离独立供电、独立时钟、独立通信链路双通道冗余架构实际项目里最常出现的是高ASIL和低ASIL的软件模块共享同一个全局变量或者共享同一个DMA缓冲区。硬件上MMU能挡住非法内存访问但挡不住模块自己写坏了共享数据。所以架构设计阶段就要规定清楚哪些内存区域归属于哪个隔离域域之间的所有数据交换只能通过受控的安全接口。4.2 架构评审阶段怎么提前证明FFI很多团队把FFI的验证拖到软件集成测试阶段这是最贵的做法。架构阶段能做很多推演我常用的是两条线第一条线叫共享资源清单。把所有ASIL分解元素和不同ASIL的软件元素开列出来逐一列出它们共享的硬件资源总线、内存、中断、时钟、电源、DMA、调试接口。然后针对每个共享项做失效影响判断这个资源坏了会不会影响安全元素第二条线是时序预算。时间隔离不是说任务优先级高就够了要证明高优先级任务的最坏执行时间加上中断阻塞时间依然满足FTTI。架构评审时我会拿一张表让团队把所有任务的周期、最坏执行时间、最大阻塞时间填出来做一次可调度性初算。这道工序在架构阶段就能暴露出大量问题不用等代码写完再去panic。4.3 常见的FFI架构缺陷清单这些坑我基本每个项目都遇到过至少一个调试接口没有隔离JTAG口直接挂在ASIL D的核上调试工具故障或误操作就可能干扰时序看门狗被低ASIL任务共享低ASIL任务卡死时它不仅饿死高ASIL任务还把看门狗刷新一起弄崩中断服务函数里做了过多计算高优先级中断把安全任务的时间挤占FTTI预算直接破掉通信协议没有设计故障检测CAN节点静默了接收方要等超时才发现架构上没有快速故障通告通道。我通常把这些写进架构评审检查单每一条都要有明确的责任人去落实。FFI不是测试阶段靠几个测试用例能覆盖干净的它是架构设计初期就要逐条推演出来的结构性决策。5. 架构评估与安全论据从架构图到安全案例5.1 架构层的DFA和FTA用分析提前验证决策到了架构评估环节我常用的两个工具不是画图而是DFADependent Failure Analysis相依失效分析和FTAFault Tree Analysis故障树分析。FTA在架构层的作用是从每个安全目标出发把可能导致安全目标失效的故障组合一层层展开到架构元素。比如非预期转向输出这个顶事件往下会有信号错误、执行器卡滞、控制算法异常、电源失效等分支。FTA能帮架构师看清楚哪些底层故障必须靠架构冗余来覆盖哪些靠安全机制就足够。DFA则更关注元素之间的依赖性共因失效、级联失效。我的经验是DFA不用做到极致穷尽先把ASIL分解出来的各条独立路径拿出来找它们之间的共享点和耦合点逐个分析。某次评审一条冗余通信链路看起来是两条CAN总线很独立但DFA发现两个CAN控制器用了同一个中断控制器一个中断控制器故障直接同时干掉两条路。这个发现直接改掉了硬件方案。5.2 安全论据怎么写才不是抄标准安全案例Safety Case现在越来越被重视但很多项目把安全案例写成了我们遵守了ISO 26262哪些条款的清单这没有任何说服力。架构阶段就应该开始沉淀安全论据核心是声明支撑证据的结构架构声明包括所有安全目标都已经分配到架构元素、ASIL分解的各元素之间独立性已实现、所有安全机制的响应时间满足FTTI。我在项目里会为每条关键声明写一个小的论据片段里面注明支撑证据指向哪些文档和哪些分析记录。比如独立性已实现这个声明支撑它的是共享资源清单、DFA报告、HSI里的隔离配置。证据如果暂时缺位我会把它标记为开放项并给截止日期而不是留在评审时嘴上说一句后面补。5.3 变更影响分析架构设计是持续工作架构不是一张静态图开发过程中经常会变更换一个传感器型号、改一个通信周期、增加一个诊断功能。每次变更都要做影响分析范围不能只看这个模块改成什么样要看变化会不会触及安全目标和技术安全需求。我的做法是维护一张安全目标-TSR-架构元素-安全机制的完整追踪矩阵变更请求一进来先在这个矩阵上跑一遍影响范围。有一次只是把电源管理芯片换成了pin-to-pin兼容的型号看起来完全匹配但新芯片的诊断输出极性反了HSI里配置错误安全监控机制直接失效。这种问题靠相当然根本防不住只有靠矩阵式追踪和架构级影响分析才能兜住。6. 架构评审清单每次过架构我都带着这张表最后分享一张我每次做技术安全架构评审都会过一遍的检查单不一定能覆盖所有场景但能帮团队把最常见的问题拦在集成之前。检查项判断标准安全目标覆盖每个安全目标都能在架构上找到至少一条完整的实现链TSR可追踪每条TSR都能追溯到FSC和安全目标并能落到具体元素FTTI预算探测响应安全状态建立时间之和有明确证据证明小于FTTIASIL分解独立性每个ASIL分解都伴随独立性分析和DFA结论HSI完整性安全相关接口的时序、配置、语义均已闭环FFI证据共享资源清单、内存隔离配置、调度预算表格可查可审软件组件复用边界鉴定报告覆盖范围与项目实际使用条件完全匹配安全关机路径存在不依赖已失效元素的最底层兜底机制功能安全架构设计做到最后其实拼的是闭环两个字需求到结构有闭环机制到证据有闭环分析到追踪有闭环。每张架构图背后都要跟得上一套能支撑它的分析和数据否则图再好看评审专家、认证审核员那边也过不去。第六篇就先写到这下一篇我计划专门展开软件架构层里的安全机制时序设计把调度和FTTI怎么算账的事情讲透。
