在讲ISO 26262的故障容错时间怎么去定，还有它的依据又要怎么去解释之前，有个地方得先想明白：这件事不是只写上一个毫秒级的数字就算是做完了。FTTI更像是一段留给安全机制去反应的时间窗口，从故障发生的那一刻算起，一直到车辆或者系统快要迈入危险状态的前夕，安全机制得靠着这段时间把问题处理掉。它和危险事件长什么样子、车辆跑在哪种运行场景里面、故障往前传导的速度快慢，还有诊断以及降级的能力都扭在一起，所以不能简简单单把它跟软件的任务周期画上等号。

　　一、ISO 26262故障容错时间怎么确定

　　要去确定故障容错时间，先要搞清楚故障究竟会引出哪些危险的后果，再去看这些危险的后果大概要花多长时间才能聚拢成形。同一种故障，搁在车速很低的场景里和搁在车速很高的场景里，能腾给系统用的处理时间常常是两样的，所以不要拿一个固定的经验数字去套所有的情形，那是不牢靠的。

　　1、确认危险事件

　　可以先对照【HARA结果】确认危险事件，例如非预期加速、制动不足、转向偏移或动力中断。

　　这一步的重点，是要把故障和危险的后果一条一条扣到一起去，不能随随便便写上“信号异常”“控制异常”这种粗枝大叶的讲法。FTTI是围着危险的后果来定下的，不是围着故障的名字自个儿单独拍脑袋的。

　　2、梳理故障传播过程

　　故障从刚刚冒出来，一直到它对车辆的行为产生作用，中间很可能会穿过信号处理、控制算法、通信传输，还有执行器的动作，也说不定因为执行器卡住了，直接就冲撞到车辆的状态上去。传播的路径越是短，危险形成得就可能越是快，反过来讲，路径要是绕得比较复杂，就得把它一层一层拆开，看清每一个环节各自要耗掉多少时间。

　　3、按不利工况取值

　　在敲定时间边界的时候，得把高速行驶、附着系数很低的路面，还有驾驶员反应受到局限、系统的负载拉得比较满这些糟糕的情形都拢到一块儿来想。普通工况下看着好像还挂着一些余量，那可不表示到了边界工况底下还能站得住，所以FTTI一般都要照着危险形成偏快的、又显得合理的场景来取值，才够安全。

　　二、ISO 26262故障容错时间依据怎么说明

　　到了要去说明故障容错时间依据的时候，重点并不是简简单单丢出一句“FTTI等于100毫秒”，反倒是要把为什么可以取这个时间值给交代清楚。评审这一头，更在意的是这个数字究竟有没有来路，能不能和危险分析、车辆行为、安全机制，还有测试出来的证据相互扣合。

　　1、说明危险分析依据

　　故障容错时间，得要落到明确的安全目标和运行场景上面去。比方说转向的故障，可以解释清楚车辆从错误的转向输出冒出来，到它偏离安全的区域为止，大致上需要多长的时间；制动上的故障，也可以说明制动力不够一路发展到碰撞风险往上爬升之间，那个时间窗口到底有多宽。用这样子的写法，FTTI才不至于成了一个孤零零挂在纸面上的数字。

　　2、说明车辆行为依据

　　可以结合【仿真结果】说明车辆状态变化过程，例如横向位移、减速度变化、扭矩建立或制动压力建立。

　　不同的系统，盯住的方向本来就不全一样，动力系统主要是去关心里面的扭矩和加速度，制动系统更多的在看减速度够不够，转向系统则要把眼光放在车辆会不会跑偏上头。拿仿真、台架或者整车的实际数据来做支撑，比起光秃秃写一句“依着经验判断”，要稳当得多。

　　3、说明安全机制依据

　　另外还得讲清楚诊断的周期是多长，需不需要连续确认几回，确认完了之后再隔多久才去拉动降级，执行器又要花多少时间才能落到限制状态里面。诊断周期比FTTI短，不一定就能代表它已经安全了，因为确认环节、调度环节、通信环节，还有执行器自身的动作，每一个都会啃掉一小截时间，把这些都加在一起看才全面。

　　三、故障容错时间在项目中怎么落地

　　FTTI被摆进安全分析以后，还要接着往下沉，沉到需求、设计和测试这些层面里面去。好多项目里的毛病，倒不是不会写下那个时间的毫秒数，而是前头明明写了100毫秒，后头软件诊断、确认策略再叠上执行器的响应时间，统统合在一块儿，已经紧巴巴地贴到了时间边界上面，这个样子是很难把闭环收拢的。

　　1、写进安全需求

　　把故障检测、故障确认、故障响应和进入安全状态的时间要求写入【技术安全需求】中。

　　这样一来，FTTI才能接着去约束住系统的设计、软件任务的编排，还有测试用例的写法，而不是只放在安全分析的文档里搁着不动弹。

　　2、核对实际响应

　　做项目的时候，要去仔细检查软件任务的周期、通信的周期、故障确认的次数，还有执行器的响应时间，要是总处理的时间已经快要摸到FTTI的边缘了，那就要回过头去重新掂量一下安全的裕量还够不够，如果不太够，就要考虑把诊断的周期缩一缩，或者把降级的策略调一调。

　　3、用测试闭环

　　通过【故障注入测试】记录故障注入、检测、响应和安全状态达到的时刻。

　　测试出来的结果，要能证明系统确实是在规定的时间里头把整套动作给走完了，而不是单单能证明系统会报警就算数，这样才能让故障容错时间在分析、设计还有验证上，从头到尾都有一条完整的依据链连下来。

　　总结

　　总的说起来，故障容错时间该怎样去确定，它的依据又要怎样去解释，这里头最要紧的地方，就是要把它时间的源头、一层层分解下去的逻辑，还有验证碰到的一堆证据，全都讲得清清楚楚。确定FTTI的时候，要去照顾到危险事件、运行场景，还有故障传播的整个过程；说明依据的时候，则要把HARA、车辆行为、安全机制，连同测试的结果串成一条连贯的线索。只有这样，故障容错时间才不会是文件里面一颗孤零零的数值，而是能实实在在撑起功能安全论证的那份工程依据。