在聊ISO 26262的安全状态该怎么定义、切换条件该如何确定之前，有个误区需要先提一下：安全状态并不是故障后把功能关掉那么简单。车辆还在行驶的时候，转向、制动、动力输出这类功能要是忽然退出了，驾驶员不一定能马上适应过来，整车反而可能冒出新的风险。ISO 26262这个标准本来就是面向道路车辆安全相关电子电气系统的功能安全开发，其中2018版的第3部分对应的是概念阶段，里面会牵涉到项目定义、HARA这些东西，安全状态通常也得顺着危害场景往下定。

　　一、ISO 26262安全状态怎么定义

　　安全状态，可以把它理解成故障发生以后，系统进入的一种受控的处理方式；当系统发现了异常，原先的控制办法可能没法再接着用下去了，但车辆还是得尽量地保持可控，于是这种状态也许是限制一下输出，也许是把功能降一个等级来运行，再不就是提醒驾驶员来接管、把故障给锁存起来，甚至禁止下一次再启动，不同功能对应的安全状态不会全是一个模样，这一点要先分清楚。

　　1、安全状态要从危害后果往回推

　　结合【HARA危害场景】、【故障行为】和【车辆运行状态】，先判断一下故障会造成什么样的影响，再去定系统应该进到哪一种安全状态。

　　拿电动助力转向来举例，非预期助力变大和助力方向搞错，虽然都跟转向有关系，可风险的程度并不一样；前一种情况，可以考虑对助力做些限制，顺带去提醒驾驶员，后一种呢，很可能需要更快地把错误的控制给停掉，所以不能把两类故障都塞进同一种“安全模式”里，要不然后头拟定的安全目标会缺少具体的落脚的地方。

　　2、关闭功能不一定更安全

　　舒适性功能出了异常，直接让功能退出来一般还能让人接受，毕竟它主要影响的是使用的体验；但是制动、转向、动力输出就不同了，高速行驶的时候转向助力突然没了，方向盘会一下子变得很沉，动力输出要是猛地被切断，车速变化也会干扰驾驶员的判断，所以安全状态看的不是一个控制器有没有停下工作，而是整车还能不能稳稳地受控。

　　3、安全状态要有具体表现

　　对照【系统输出】、【报警提示】、【故障锁存】和【恢复条件】，说明一下系统进到安全状态之后的表现。

　　比如扭矩有没有被限制住，执行器是不是停了响应，仪表盘有没有发出报警，故障诊断码有没有被记下来，在这个驾驶循环里面许不许恢复，只要把这些表现都交代清楚了，安全状态才不会只是停留在概念上面，也就能更方便地跟后面的验证工作衔接起来。

　　二、ISO 26262安全状态切换条件怎么确定

　　等到安全状态的定义弄明白了，还要看系统到底在什么时候应该切换过去；切得太早的话，系统就会频繁地降级，切得太晚的话，故障可能已经对车辆的行为产生了影响，比较稳当的做法，是把故障的类型、确认的过程、车辆运行的状态，还有恢复的条件放在一块儿来做判断。

　　1、先区分普通异常和安全相关故障

　　短时间的信号抖动、单帧通信出错、偶尔的校验失败，不一定非得马上就去触发安全状态，因为车辆信号本来就允许有短暂的一些波动；刚看到一点异常就降到低一级的模式，系统会变得很难用，真正需要引起切换的，往往是那种持续超时、双通道对不上、关键传感器失效，或者执行器反馈异常这一类的问题，对于小异常，可以先记下来再去确认，但是明显影响到安全目标的故障，就不能老是搁在那里等着。

　　2、切换前要确认故障是否成立

　　围绕【故障检测】、【去抖时间】、【确认阈值】和【锁存策略】，去判断一下异常得持续到什么地步才能算作故障成立。

　　比方说车速信号丢了一帧，跟连续丢掉一百毫秒，这就不能当作同一种问题去处理；传感器数值短时间的跳变，也不一定就说明传感器已经坏掉了，所以需要把持续时间、采样的次数、一致性判断这些条件给写清楚，这样子误触发的情况会减少，真正的故障也不容易给放过去了。

　　3、切换时间不能只写“及时”

　　光写上一句“及时进入安全状态”，这个说法是很空泛的，不够具体；危险扭矩输出、错误的制动请求，还有错误的转向助力，这类故障发展的速度往往是比较快的，切换的动作就一点都不能拖沓，而有些故障带来的影响比较缓慢，那就可以先发个报警，接着再对功能做出限制，到最后才提醒驾驶员停车检查，不同的故障得分开去确定时间上的条件，不能全都拿一个模糊的说法来带过去。

　　4、恢复条件要提前定义

　　故障消失了之后，系统到底能不能自己恢复过来，是要重新上电之后才能恢复，还是必须要用维修工具去清除，这些都需要事先给讲清楚；有些暂时的异常等到信号稳定之后是可以恢复的，但某些关键的故障就得一直锁存到本次驾驶循环结束才行，恢复的规则要是含含糊糊，系统的行为就容易变得前后不一致。

　　三、ISO 26262安全状态和切换条件怎么校验

　　安全状态和切换条件定下来以后，还要去看它们能不能真正落实到系统的行为里头去；能够被触发，能够被观察到，能够说明风险确实被控制住了，这些可比概念上写得完不完整更要紧。

　　1、先看状态是否能够验证

　　进到降级状态之后，输出的上限被设到了多少，报警有没有被发出来，故障码是不是被记录了，执行器是不是被停掉了响应，功能有没有被禁止再次激活，这些东西最好都是能观察到的；如果安全状态没有一点能够观察到的结果，就很难去说它已经起了作用。

　　2、切换条件要能找到来源

　　对照【诊断监控项】、【故障触发条件】和【测试注入方式】，去检查每个切换的条件是不是都能对到具体的来源上头去。

　　比方说信号超时、通道对不上、反馈异常、供电异常这些，都应当能对到清楚的监控逻辑上面；只写上一句“系统检测到异常”，这个范围就显得太宽了，等到后面去实现和验证的时候，都会变得模模糊糊的。

　　3、降级后还要看整车反应

　　功能退出来或者降了级之后，风险可不一定会跟着自动消失，报警信息驾驶员能不能看得明白，车辆会不会出现明显的顿挫，执行器那里还有没有残留的输出，其他的系统会不会受到牵带，这些都要接着往下查；有些处理的办法在单个控制器层面看着还算完整，可放到整车上反而让车辆更难去驾驭，要是碰到这种情况，那样的安全状态就需要重新去调整了。

　　总结

　　整体来说，ISO 26262里安全状态的定义和切换条件的确定，关键都是要把故障发生以后车辆的处理方式给交代明白；安全状态不能随便地跟关掉功能画等号，得从危害的后果倒着往回推，切换条件则需要结合故障的类型、确认的过程、车辆的状态、切换的时间和恢复的规则一块儿来定，到最后还要去验证它能够被触发、能够被观察到，并且能够说明风险是真的被管住了。