在功能安全开发中，降级策略要怎样去设计，和它配套的那些验证场景又要怎么去覆盖，这两块内容是比较容易被写得发虚的。降级策略不能只是轻飘飘的一句“故障后进入降级模式”，而是要交代清楚故障发生之后，系统用什么办法去限制风险，哪些功能还得继续保留，哪些功能必须完全退出，驾驶员在什么时候应该接手，以及后面靠哪些测试来证明这套办法确实有用。只有把设计、验证和证据这几个环节串在一块儿，降级策略才算真正地落了地。

　　一、ISO 26262降级策略怎么设计

　　开始设计降级策略的时候，不能一上来就从故障码动笔，得先去看HARA、安全目标，还有ASIL这些前期分析得到的结果。项目先要弄明白功能一旦失效究竟会带来什么样的危险，再回过头来去判断系统是采用受限运行，还是转成应急运行，又或者直接就进到安全状态。只有这个先后顺序理清了，后面去写需求、搭架构和做测试，才算有了一个牢靠的根底。

　　1、明确降级目标

　　降级的目标一定要写得具体，不能只丢下一句“进入降级模式”就交代完事。拿辅助驾驶功能来举例，假如感知部分出了偏差，那是只把横向控制退掉，还是连着纵向控制也一块儿退出；是立刻就把控制权交回给驾驶员，还是先稳住车身一小段时间再去提醒他接管；警告方式上，是只亮一个故障灯，还是声音和文字的提示都要跟着推出来。这些内容统统要转成能够拿去评判的、明明白白的要求，一点都不能含糊。

　　2、划分降级状态

　　设计时可以围绕【正常运行】→【受限运行】→【安全退出】→【安全状态】梳理状态变化关系，并分别说明进入条件和退出条件。

　　因为这几种状态之间是一种往前推进的关系，用箭头来串会比较直观。实际去写需求的时候，不同状态需要分得清清楚楚，比方说遇到轻微的传感器信号波动，也许只把功能限制一下就足够了；可要是关键的执行器失效了，那很可能就得把控制完全退干净；如果碰上严重的供电异常，说不定就要直接切进安全状态。

　　3、确定故障检测来源

　　故障检测的来源，需要把传感器诊断、通信监控、执行器反馈、电源监控，还有软件任务的监控这些都覆盖进去，只不过它们彼此之间是并列关系，不要硬拿箭头去串。项目还要讲清楚，每一类故障是靠哪一种检测机制被发现的，怎样才算是故障确认成立，确认之后又会触发哪一类降级反应。这些关系理通了，后面实现的时候逻辑才不容易乱套。

　　二、ISO 26262降级策略验证场景怎么覆盖

　　至于降级策略的验证场景要怎么去覆盖，它的重点倒并不在于去证明系统能进一次降级状态，而是要去证明在不同的故障、不同的运行工况，还有不同的边界条件底下，系统全都可以照着设计的要求去反应。实际上有不少问题，并不是出在常规的故障注入上面，而是出在故障间歇性地往外冒、状态来回地切换，或者是驾驶员接管的时候提示不够清楚这一类细节当中。

　　1、覆盖故障类型

　　测试人员应根据【故障清单】选择故障注入点，再把故障形式、持续时间和预期降级反应写进用例。

　　测试用例不能笼统地只写一个“传感器故障”，而要再往下细分，比如是断线、卡死、信号漂移、噪声变大，还是更新周期不正常。通信故障也是一样的道理，要分开报文丢失、超时、CRC校验出错、计数器不对，还有数据不合理这些情形。只有这样拆细了，才能看得出来降级逻辑里面还有没有遗漏的地方。

　　2、覆盖运行工况

　　验证的场景，需把车辆静止、低速、中高速、转弯、制动、加速、坡道，还有湿滑路面这些工况都包含进去。同一个故障，在低速泊车的时候发生，跟它在高速巡航的时候发生，带来的风险表现常常是两样的；低速下可能要多留意误退出和功能还能不能用的问题，高速下则要多去关心接管的时间、告警的强度，还有控制权是怎么样撒手出去的。

　　3、覆盖状态切换

　　围绕【正常状态】→【降级状态】→【恢复状态】检查状态切换条件，重点看间歇故障、重复故障和恢复失败时系统是否稳定。

　　这几种状态同样存在递进关系，用箭头去表示很明了。比如故障信号一会儿正常一会儿又不正常了，系统可不能跟着一块儿来回地恢复又降级，这中间需要有故障确认时间、降级保持时间，还要有一个恢复的门槛来兜底，这样系统才能稳得住。

　　三、ISO 26262降级策略证据怎么整理

　　等降级策略真正落地以后，相关的证据也还要整理成一个闭环。评审的时候，大家一般也不会只盯住策略本身写得完不完整，还会一直往下追，看它能不能回溯到安全目标上头去，有没有被分配到系统和软件的需求里面，以及测试出来的结果经不经得起复查。

　　1、建立需求追溯

　　从【Safety Goal】→【技术安全需求】→【系统设计】→【测试用例】建立追溯关系，确认每条降级动作都有来源，也有验证手段。

　　这就是一条很典型的追溯链路，用箭头来表示是很贴切的。拿避免非预期加速来举例，降级策略里面可能会放进去扭矩限制、执行器监控、驾驶员提示，还有故障记录这些内容，当中的每一项，都得能够追溯到对应的需求和测试证据上面才说得过去。

　　2、保留测试记录

　　测试报告不要只简简单单写个“通过”就算了，比较有用的证据得把故障注入的手段、输入设定的条件、系统实打实的反应、时间测量的结果，还有日志、报文、波形以及故障码的记录都囊括进来。关键是要能看得出来，故障是在哪个时间点被注入的，什么时候被检测到的，什么时刻触发了降级，又是什么时候进到了目标状态，这条时间线必须明明白白。

　　3、单独确认恢复逻辑

　　恢复的逻辑不适合捎带在别的验证项上头，得结合故障消失的条件、恢复过程的延时、需不需要人工去复位，还有经过一次点火循环后状态还能不能保持得住，来单独做检查。恢复的条件要是设得太宽，系统就容易来来回回地跳变；要是设得太窄太严，功能又有可能很长时间都恢复不起来，所以恢复逻辑也应当形成一份独立的证据。

　　总结

　　总的说起来，降级策略的设计和验证场景的覆盖，关键并不在于把“降级模式”几个字写进文件就了事，而是要拿安全目标、故障检测办法、状态切换的路径、具体的时间要求、驾驶员交互、恢复逻辑，还有测试证据，全串成一条完整的链子。设计阶段要讲清楚为什么要选这样一种降级方式，验证阶段要能拿出证据来表明在不同的故障和工况底下系统都可以按预期去执行，证据整理阶段还要做到每一环都能够被追溯、被复查。这样整个闭环形成了，降级策略才算真正地扎进了工程实现当中。