开展ISO 26262的接口分析，不能仅仅把它当成是对一张通信信号表格的整理。这里所说的接口，其范围要宽泛得多，它既包括了系统与外部车辆环境、传感器、执行器之间的那些连接，也涵盖了系统内部，也就是硬件、软件以及各个不同安全要素相互之间的数据交互、控制指令、电源供给以及时序上的配合关系。ISO 26262对于产品开发的要求，是贯穿了系统、硬件和软件这几个层面的，并且要通过安全导向的分析、配置管理以及变更管理，来形成一个能够闭合的环路。

　　一、ISO 26262接口分析怎么开展

　　进行接口分析的时候，应该从系统的边界和整体的架构开始，然后一层一层地向下，具体落实到硬件和软件上面。如果只是对照着已有的信号列表去检查，就很容易把电源、唤醒、复位、诊断以及降级这些接口给漏掉。一种比较稳妥的做法，是先设法建立起一个接口的全集，然后再去逐一分析这些接口一旦出现异常，会对安全功能造成什么样的影响。

　　1、先确定接口范围

　　应当围绕【Item边界】【系统架构】【技术安全需求】这几个方面，把所有的输入方、输出方以及存在依赖关系的相关方，都给识别出来。

　　对于外部的接口，需要把传感器、执行器、车载网络、电源、接地、时钟、诊断设备，还有其他的控制器，都覆盖进去；对于内部，则还要去检查硬件与软件之间、各个软件组件相互之间，以及安全机制和它所监控的对象之间的那些接口。对于每一个接口，都应该清楚地写明它的来源、去向、方向，还有它所归属的功能，不能只是简单地记录下一个信号的名称。

　　2、补全接口属性

　　在【接口控制文档】或者【接口分析矩阵】里面，需要把数据的类型、单位、有效的范围、刷新的周期、超时的条件、初始值，还有在失效时用来替代的值，这些信息都记录清楚。

　　如果是数字接口，还要进一步说明它的端序、缩放系数、计数器、校验方式以及哪些是有效位；如果是控制类的接口，则需要关注调用的先后顺序、执行需要满足的条件，以及并发访问的关系；如果是电气接口，那么电压范围、开路和短路的检测，还有上电下电的行为，就都需要考虑进去。接口的定义越是模糊，后面进行安全需求的分配和验证的时候，就越是难以落实。

　　3、分析接口失效表现

　　接口分析不能停留在确认“有没有这个信号”的层面，还要进一步去检查，像没有收到数据、收到了错误的数据、数据冻结不再更新、出现延迟、顺序发生错乱、重复发送，以及非预期的激活这些异常的情况。对于那些和安全相关的接口，要判断这些异常是不是会违反既定的安全目标，而现有的超时监控、合理性的检查、冗余的比较，还有故障降级这些机制，是不是能够及时地把风险控制住。在系统层面所制定的技术安全概念，还有架构的设计、硬件的设计以及软件架构的设计，都需要能够承接住这些安全方面的要求。

　　二、ISO 26262接口分析发现遗漏项怎么处理

　　发现存在遗漏的项目之后，是不能只在表格的末尾简单地新增一行就了事的。首先要做的，是去确认清楚这个遗漏是发生在哪一个层面上的，到底是文档里面没有写进去，是设计当中就没有去实现，还是安全需求没有被正确地分配下去。这三种情况，它们需要投入的处理力度是各不相同的，并且，如果涉及到了已经发布出去的基线，那么还需要进入正式的变更管理流程。

　　1、判断遗漏项性质

　　首先要把遗漏的项目分成几类，一类是接口记录的遗漏，一类是接口定义本身就不完整，还有一类则是实际设计上的真正遗漏。如果是记录的遗漏，通常可以通过补充文档并且复核其一致性来解决；如果是定义不完整，就需要重新去确认它的范围、时序以及异常行为；而如果是实际设计上的遗漏，那么可能会对架构、代码、硬件的电路，还有测试方案都产生影响，这就不可以按照普通的文档问题去关闭了。

　　2、开展安全影响分析

　　要沿着【遗漏接口】→【安全需求】→【架构要素】→【验证用例】这样一条路径，进行追溯分析。

　　需要检查这个接口是不是承载了和安全相关的数据，是不是会对现有的安全机制产生影响，是不是会改变故障反应所需的时间，以及上下游的各个要素是不是都依赖于它。如果这个遗漏会影响到技术的安全需求、硬件的安全需求或者是软件的安全需求，那么就需要同步地去修订需求的分配、架构的设计还有验证的计划，而不仅仅是去更新接口表格本身。

　　3、更新关联工作产品

　　在接口发生了变更之后，要同步地去检查需求的规格、架构图、通信的矩阵、硬件的设计、软件的设计、诊断的设计，还有相关的测试用例。如果涉及到供应商的接口发生了变化，还要去确认双方手里的文档版本以及责任的边界是一致的，要避免出现整车厂这一方已经更新了要求，而供应商还在按照旧的定义进行开发这种情况。

　　三、接口遗漏修正后怎么完成闭环

　　遗漏的项目被修改完成，并不代表着这个问题就可以被关闭了。还需要去证明，新增的或者是修订过的这些接口要求，已经在实际当中被正确地实现了，并且，没有对其他的接口和原有的安全机制，造成什么新的不利影响。

　　1、重新执行一致性检查

　　需要对照着接口的矩阵、架构和需求，去检查名称、方向、单位、周期、范围还有故障处理的措施，是不是都保持了一致。要重点关注的是，同一个信号，在系统的文档、软件的文档和测试的文档当中，是不是被使用了不同的命名，或者采用了不同的单位，这类问题，是很容易拖到集成的阶段才会暴露出来的。

　　2、补充接口验证

　　对于接口的验证，应该要能够覆盖到正常的数值、边界上的数值、无效的数值、超时的情况、数据冻结的情况、数值跳变的情况，还有故障后恢复的过程。如果是涉及到了网络通信，还要去检查报文丢失、重复、延迟以及计数错误这些情况；如果是涉及到了硬件的接口，那么就需要补充开路、短路，还有供电出现异常这些场景的测试。

　　3、纳入变更和回归范围

　　接口的遗漏通常会对多个模块都产生影响，修正完成以后，不能只是重新测试新增的那些接口。要根据之前所做的影响分析，来确定回归测试的范围，去检查调用方、接收方、安全机制，还有降级的逻辑，是不是仍然能够成立。同时，评审的记录、测试的结果，还有问题关闭的证据，都需要一并保存下来。

　　总结

　　ISO 26262接口分析怎么开展ISO 26262接口分析发现遗漏项怎么处理，这里面的关键，是要从系统的边界出发，把接口的对象、属性、时序，还有失效的行为，一层一层地具体落实到硬件和软件上面。在发现了遗漏之后，应该先判断清楚，它到底是文档的遗漏、定义的不完整，还是实际设计上的缺失，然后再沿着安全需求、架构要素和验证用例这条线索，去开展影响分析。只有等到相关的工作产品都完成了同步的更新，并且也完成了一致性的检查、接口的验证，还有回归的测试之后，这个接口的遗漏项，才算是真正地完成了闭环。