★ FEATURED ARTICLE 1. 为什么汽车嵌入式开发绕不开功能安全做汽车电子这行的朋友大概都有过这样的经历你写了一段逻辑完全正确的代码单元测试全绿集成测试也没问题但评审会上还是被安全经理打回来理由只有一句——“这不满足功能安全要求”。你心里可能犯嘀咕代码能跑、功能正常为什么还要折腾一套看起来又重又繁琐的流程这就是功能安全要回答的问题。它关心的不是“系统能不能实现预期功能”而是“当系统出现故障时会不会对人造成不可接受的伤害”。一辆车在高速上跑刹车控制、转向助力、电池管理这些系统一旦失效后果不是死机重启那么简单。功能安全要做的就是把这些风险压到一个可接受的范围内。汽车嵌入式系统的功能安全开发与测试核心就是围绕这套逻辑展开的先识别危害再定义安全目标然后设计安全机制最后用测试证明这些机制真的有效。它覆盖从需求、架构、编码、集成到验证的完整链路涉及硬件、软件、系统三个层面。适合谁来参考如果你是从消费电子、工业控制转过来的嵌入式工程师或者刚进入汽车行业做ECU开发、测试、质量管理的同学这套东西你迟早要啃。哪怕你暂时不做认证项目理解它的思路也能让你的代码在可靠性上高一个档次。我个人的感受是功能安全最容易被误解成“一堆文档”。实际上文档只是载体真正值钱的是它逼着你在设计早期就把失效模式想清楚。很多项目后期返工根子都在早期没做危害分析。下面我按实际开发顺序把整套流程拆开讲尽量说人话也把踩过的坑一并交代。2. 功能安全开发整体思路与方案选型2.1 从危害分析到安全目标的推导逻辑功能安全开发不是从写代码开始的而是从“这东西坏了会怎样”开始的。行业里通用的做法是先做危害分析与风险评估英文叫HARA。它的输出直接决定了你后面所有工作的严格程度。具体怎么推拿一个电子助力转向系统举例。你先列出它的功能根据方向盘扭矩和车速输出助力扭矩。然后想失效模式助力突然反向、助力突然消失、助力卡在最大值。接着评估每种失效在什么驾驶场景下发生、严重度多高、暴露概率多大、可控性如何。这三个维度组合起来得出一个汽车安全完整性等级也就是常说的ASIL从A到DD最严。这里有个关键点很多人会忽略ASIL等级是分配给“安全目标”的不是分配给整个系统的。同一个系统里不同安全目标可能有不同等级。比如“防止助力反向”可能是ASIL D“防止助力轻微抖动”可能只到ASIL A。这个区分直接决定了你后面在软件上要花多少精力做冗余、做监控。注意HARA不是一个人拍脑袋完成的需要系统、软件、硬件、测试甚至整车的人一起评审。我见过太多项目由一个人闭门造车写完HARA结果架构设计时发现安全目标根本没法落地只能推倒重来。2.2 安全机制选型冗余、监控与降级的取舍安全目标定下来之后下一步是选安全机制。常见的手段就那么几类冗余、监控、降级、限制。但怎么选背后是成本和风险的平衡。冗余分好几种。硬件冗余最直接比如双核锁步、双传感器但成本和功耗上去了。软件冗余便宜比如关键变量算两遍比对但会吃掉CPU时间而且共因失效的风险要单独分析。监控是更轻量的做法用一个独立的看门狗或监控芯片盯着主控发现异常就复位或切安全状态。降级则是承认“我做不到全功能了但至少保证安全”比如助力失效后保留基础转向能力。我个人的经验是优先考虑监控和降级因为它们对现有架构改动小、验证成本低。只有在监控覆盖不了、失效后果又极其严重的地方才上冗余。举个例子扭矩传感器的信号可以用监控加合理性检查覆盖大部分故障但如果传感器本身是单点失效且直接导致危险那就得考虑冗余传感器或者冗余信号通道。选型时还要考虑诊断覆盖率。你设计了一个监控机制但它能覆盖多少比例的故障这个数字直接影响你能否达到目标ASIL。很多团队在这里翻车机制设计了但没做诊断覆盖率分析认证时拿不出证据。2.3 软硬件接口的一致性设计功能安全里有个特别容易被低估的环节软硬件接口也就是HSI。它定义的是软件和硬件之间那些“约定”比如寄存器怎么读写、故障信号怎么传递、安全机制怎么触发。为什么它重要因为软件和硬件往往是两拨人做的如果接口定义不清就会出现软件以为硬件会报错、硬件以为软件会处理的情况结果故障被漏掉。HSI文档要写清楚每个安全相关信号的来源、去向、时序、有效电平、故障时的默认状态。我踩过的一个坑某个安全机制依赖硬件比较器的输出软件轮询读取。但HSI里没写清楚比较器上电后的初始状态是不确定的软件在初始化阶段就误判成故障导致系统反复复位。后来在HSI里补充了“上电后前100ms忽略该信号”的约定才解决。这种细节不写进接口文档测试阶段根本查不出来。3. 核心细节解析与实操要点3.1 需求阶段安全需求如何写得可验证安全需求是整个开发的源头但很多团队写出来的需求根本没法验证。什么叫可验证就是你能设计出一个测试用例明确地判定它通过还是失败。反面例子“系统应保证转向助力安全。”这句话没法测。正面例子“当扭矩传感器信号超出有效范围超过20ms时系统应在50ms内将助力扭矩降为0并点亮故障指示灯。”这个就能测注入一个超范围信号计时看输出和指示灯。写安全需求时我习惯用“触发条件响应时间约束安全状态”这个模板。触发条件要具体到信号和阈值响应要明确动作时间约束给出上下限安全状态说明最终进入什么模式。这样写出来的需求测试工程师直接就能转成用例。还有一点安全需求要能追溯到安全目标。每个安全目标下面挂若干安全需求每条需求都要有唯一编号。认证审核时审核员会顺着这条链查断了一环就是不符合项。3.2 架构设计安全机制在软件架构中的落位架构设计阶段核心任务是把安全需求分配到具体的软件组件和硬件资源上同时设计安全机制的实现方式。一个典型的做法是分层底层做硬件诊断和信号采集中间层做安全监控和逻辑判断上层做功能输出。安全机制尽量放在独立的监控层不要和功能逻辑混在一起。为什么因为功能逻辑本身可能有缺陷如果监控逻辑和它共享代码或数据共因失效的风险就高了。比如功能层算出一个助力扭矩值监控层要独立地再算一遍或者用不同方法校验。两层用不同的算法、不同的数据源才能形成有效监控。如果两层调用同一个函数那这个函数出问题两层一起错监控就形同虚设。架构设计还要考虑时间。安全机制的反应时间必须满足安全需求里的时间约束。这就需要在设计阶段做时间分析看看最坏情况下从故障发生到进入安全状态需要多久。这个分析要基于实际的CPU负载、任务调度、中断延迟来算不能拍脑袋。3.3 编码规范与安全机制实现细节到了编码阶段功能安全对代码的要求可以概括为可预测、可分析、可测试。行业里通常参考MISRA C或者类似的编码规范限制一些容易出问题的语言特性比如动态内存分配、递归、复杂的指针运算。但光遵守编码规范不够安全机制的代码实现有几个细节要特别注意。第一安全相关变量的初始化。所有安全机制用到的变量上电时必须显式初始化到确定状态不能依赖默认值。我见过因为一个标志位没初始化导致安全机制在启动阶段误触发的情况。第二故障注入的接口要预留。测试阶段需要人为制造故障来验证安全机制如果代码里没有预留注入点测试就只能靠改代码既危险又不可重复。好的做法是在设计时就定义好故障注入的接口通过标定或调试口控制。第三安全机制的代码要有独立的执行周期和优先级。如果它和普通任务混在一起被高优先级任务阻塞反应时间就没法保证。通常会把关键监控放在高优先级中断或独立的任务里。提示编码阶段就要开始积累安全分析文档比如每个安全机制的实现说明、诊断覆盖率估算。等到测试阶段再补很多细节已经记不清了。3.4 测试策略从单元到系统的验证链条功能安全的测试不是单一活动而是一条链单元测试、集成测试、系统测试、整车测试。每一层验证不同的东西缺一不可。单元测试验证安全机制的函数级正确性比如监控算法在各种输入下的输出是否符合预期。集成测试验证组件之间的接口和时序比如故障信号从硬件传到软件监控层再到执行器整条链路是否按设计工作。系统测试在台架上模拟各种故障场景验证系统级的安全响应。整车测试则是在真实环境里确认没有遗漏。测试方法上除了常规的功能测试还要做故障注入测试。这是功能安全测试的核心。故障注入可以是硬件的比如断开传感器信号、短接线路也可以是软件的比如强制某个变量为错误值。目的是验证安全机制真的能检测到故障并正确响应。测试用例的设计要覆盖安全需求的每一条同时要考虑边界条件和故障组合。比如传感器信号在有效范围边缘抖动、两个故障同时发生、故障发生在系统启动过程中。这些场景最容易暴露问题。4. 实操过程与核心环节实现4.1 危害分析与风险评估实操记录假设我们做一个电池管理系统负责监控电池电压、温度和电流控制充放电。第一步做HARA。先列功能监控单体电压、监控温度、监控电流、控制继电器、估算荷电状态。然后对每个功能想失效模式。以“监控单体电压”为例失效模式有电压读数偏高、偏低、不更新、卡在固定值。接着评估。电压读数偏高可能导致过充判断失效严重度很高因为过充可能引发热失控。暴露概率取决于这个功能在行车和充电时都在用算高。可控性方面驾驶员很难察觉算低。综合下来这个安全目标大概率是ASIL C或D。评估完所有失效模式整理成表格每个失效模式对应一个安全目标每个安全目标有ASIL等级。这张表就是后续所有工作的纲领。实操中要注意评估严重度、暴露概率、可控性时要有明确的依据不能凭感觉。行业标准里有参考表格但具体项目要结合自己的使用场景调整。比如同样是过充如果电池化学体系本身有保护严重度可能降一级。这些判断要记录理由认证时要查。4.2 安全需求分解与追溯矩阵建立HARA完成后把安全目标分解成安全需求。还是电池管理系统的例子。安全目标“防止因电压监控失效导致的电池过充。”ASIL C。分解出的安全需求可能包括当任一单体电压超过4.25V时系统应在100ms内断开充电继电器。电压采样通道应具备开路和短路诊断诊断周期不超过10ms。电压采样值应进行合理性检查与相邻单体电压偏差超过500mV时判定为故障。电压监控软件应独立于充放电控制软件运行。每条需求编号比如SG01-SR01、SG01-SR02。然后建立追溯矩阵安全目标→安全需求→架构组件→测试用例。这个矩阵是认证的核心证据证明你没有遗漏任何一条需求也没有做多余的工作。追溯矩阵建议用表格管理每完成一个阶段就更新。我见过用Excel手工维护的也见过用专业需求管理工具的。工具不是关键关键是每次变更都要同步更新否则矩阵很快就失效了。4.3 故障注入测试的完整流程故障注入测试是验证安全机制有效性的关键手段。完整流程分几步。第一步确定注入点。根据安全需求和架构设计列出所有需要验证的安全机制每个机制对应一个或多个注入点。比如电压采样通道的诊断注入点就是采样信号线。第二步设计注入方法。硬件注入可以用继电器切换、电阻分压、信号发生器替代。软件注入可以通过调试接口修改内存变量、强制函数返回值。选择方法时要考虑对系统其他部分的影响尽量做到只影响目标信号。第三步定义预期结果。每个注入用例都要明确注入什么故障、持续多久、系统应该在多长时间内做出什么响应、响应后处于什么状态。这些预期结果直接来自安全需求。第四步执行并记录。测试时记录注入前后的信号、系统响应时间、最终状态。如果响应不符合预期要分析是安全机制设计问题还是实现问题。第五步回归。修复问题后重新执行相关用例确保问题解决且没有引入新问题。注意故障注入测试要在安全的环境下进行尤其是涉及高压、高电流的系统。台架测试要有人监护急停按钮要随手可及。软件注入要确保不会误触发真实的安全机制导致危险。4.4 诊断覆盖率分析与计算诊断覆盖率是衡量安全机制有效性的量化指标。它定义为被安全机制检测到的故障率占总故障率的比例。这个数字直接影响你能否达到目标ASIL。计算诊断覆盖率先要列出所有可能的故障模式。对于每个故障模式判断你的安全机制能否检测到。能检测到的算入覆盖检测不到的算入未覆盖。然后按故障率加权。举个例子某个电阻有开路和漂移两种故障模式。开路故障率占70%漂移占30%。你的诊断能检测开路检测不了漂移。那么诊断覆盖率就是70%。实际项目中故障率数据来自硬件厂商的失效率手册或者行业数据库。没有数据时可以用标准里的参考值但要说明来源。诊断覆盖率不是越高越好因为提高覆盖率意味着增加诊断机制成本和复杂度都上升。目标是在满足ASIL要求的前提下用最经济的方案达到必要的覆盖率。通常ASIL D要求单点故障覆盖率90%以上ASIL C要求80%以上具体看标准要求。5. 常见问题与排查技巧实录5.1 安全机制误触发与漏触发排查安全机制最怕两种问题误触发和漏触发。误触发是没故障时报警漏触发是有故障时不报警。两者都会导致系统不可用或不安全。误触发常见原因信号抖动、阈值设置过紧、初始化阶段状态不确定、电磁干扰。排查时先看信号质量用示波器抓原始信号确认是否有毛刺。然后检查阈值和滤波参数看是否留了足够裕量。初始化阶段的问题重点查上电时序和变量初始化。漏触发常见原因诊断逻辑有漏洞、故障注入没覆盖到、共因失效、诊断周期太长。排查时先确认故障是否真的能被检测到用故障注入复现。如果注入能检测到但实际场景漏了可能是故障模式没分析全。共因失效要单独分析比如监控和功能共享电源电源挂了两个一起挂。我遇到过一个典型案例某个监控机制在实验室怎么测都正常装车后偶发漏报。后来发现是整车电磁环境导致信号上叠加了高频噪声监控的采样窗口刚好采到噪声被滤掉的部分。解决办法是在监控前加一级硬件滤波同时调整采样时机。这种问题不在真实环境跑很难发现。5.2 认证审核中的高频不符合项功能安全认证审核时审核员会顺着开发流程查证据。根据我的经验高频不符合项集中在几个地方。需求追溯断裂。安全需求没有全部追溯到测试用例或者测试用例没有追溯到需求。审核员随机抽一条需求如果找不到对应的测试记录就是不符合项。安全分析不完整。HARA里遗漏了某些失效模式或者诊断覆盖率计算没有依据。审核员会问“这个故障模式你分析了吗”“这个覆盖率数字怎么来的”答不上来就麻烦。变更管理缺失。开发过程中需求或设计变更了但没有走变更流程没有重新做影响分析。审核员查变更记录发现变更前后的文档对不上直接开不符合项。测试证据不足。测试做了但没有记录或者记录不完整缺少时间、环境、结果、判定。审核员要的是可追溯的证据不是“我们测过了”这句话。避免这些问题的办法很简单把功能安全工作当成日常每个阶段该产出的文档及时产出变更及时记录。不要等到认证前突击补补出来的东西经不起查。5.3 工具链选型与置信度评估功能安全开发会用到各种工具需求管理、建模、静态分析、测试、覆盖率分析。这些工具本身也可能出错所以标准里要求对工具做置信度评估。评估的逻辑是如果工具出错会导致安全相关的问题那就要么用高置信度的工具要么对工具的输出做额外验证。比如你用静态分析工具检查代码如果它漏报了一个关键缺陷可能导致安全问题那就要评估这个工具的置信度必要时人工复核。实操中不是所有工具都要做完整评估。可以根据工具的使用场景和影响程度分级。影响安全目标实现的工具评估要严只影响效率不影响安全的工具可以简化。工具链选型时优先选行业里用得多的、有认证支持的工具。但不要迷信工具工具只是辅助关键还是人的分析和判断。我见过团队花大价钱买了认证工具但没人会用最后工具闲置还是手工做分析。5.4 常见问题速查表问题现象可能原因排查方向解决思路安全机制频繁误报信号抖动、阈值过紧、初始化问题抓原始信号、检查阈值和滤波、查上电时序增加滤波、放宽阈值、显式初始化故障注入无响应注入点错误、诊断未使能、响应被阻塞确认注入生效、检查诊断配置、查任务调度修正注入点、使能诊断、调整优先级诊断覆盖率不达标故障模式遗漏、诊断逻辑不覆盖重新分析故障模式、审查诊断逻辑补充诊断机制、优化覆盖范围认证审核追溯断裂需求变更未同步、文档缺失检查追溯矩阵、核对变更记录补全追溯、完善变更管理测试结果不可复现环境不一致、参数未记录、随机因素核对测试环境、检查参数记录标准化测试流程、记录完整参数这张表是我自己项目里积累的不一定覆盖所有情况但大部分常见问题都能对上号。遇到新问题先按这个思路排查往往能少走弯路。6. 从开发到测试的衔接与个人体会功能安全开发和测试不是两个割裂的阶段而是互相咬合的。测试用例在设计阶段就应该开始构思因为测试的可行性会反过来影响设计决策。比如你设计了一个安全机制但发现没法注入故障来验证它那这个机制的可信度就要打问号可能需要调整设计让它可测。我在实际项目里最深的体会是功能安全最难的从来不是某个具体技术点而是让整个团队对“安全”有统一的理解和一致的执行。系统工程师觉得安全是软件的事软件工程师觉得安全是测试的事测试工程师觉得安全是设计的事最后谁都没兜住。真正做得好的项目是每个角色都清楚自己的安全责任并且在接口处主动交接。另一个体会是不要等到项目后期才引入功能安全。早期多花一周做HARA和架构安全分析后期可能省下一个月返工。这个账做过项目的人都算得过来。最后分享一个小技巧把安全需求和安全机制做成检查清单每次代码提交或设计评审时过一遍。清单不用长十条以内但要坚持用。时间长了它会变成团队的本能反应。这比任何文档都管用。
阅读完成 · 觉得有帮助？
