整车厂把控制器开发交给供应商时，往往会在技术要求里写清楚控制器要做什么。到了集成阶段，仍可能碰到这样的情况：供应商已经在台架上验证了故障响应，整车厂却拿不到报告对应的软件版本，也不清楚台架上采用的供电和通信条件。开发接口协议就是用来约定这类交接的。它把双方要做的安全活动、要交换的资料，以及接收后由谁评审写进同一份协议。

　　一、ISO 26262开发接口协议是什么

　　开发接口协议简称DIA，英文为Development Interface Agreement。ISO 26262-8:2018第5条把它放在分布式开发的接口管理中。参与开发的客户和供应商通过DIA明确各自的安全职责，并约定怎样交换信息和工作成果。

　　1、先写清协议覆盖的开发范围

　　DIA的范围可以具体到一个控制器、一个软件组件，或双方约定的其他交付对象。范围写得太宽，后面就容易把控制器内部的验证和整车集成后的验证混在一起。

　　①在【开发范围】中填写交付对象、适用车型或平台，以及本次交付包含的硬件、软件和配置。

　　②在【双方安全负责人】中登记客户和供应商各自任命的安全经理及联系渠道。

　　③对照双方的【安全计划】，列出适用的安全活动，并记录双方商定的裁剪内容。

　　2、把每项活动的交接要求写完整

　　①在【安全活动清单】中记录执行方、参与方和计划完成时间。

　　②在【工作成果清单】中写明交付物、接收方、交付节点和评审安排。对用于安全论证的资料，注明需要交换哪些内容。

　　③对【确认措施】单独明确分工。按适用要求安排确认评审、功能安全审核和功能安全评估，并核对所需的独立性。

　　④在【安全确认】中写清由哪一方执行、在哪个层级开展，以及另一方需要提供什么输入和支持。

　　写交付物时，单列一项“测试报告”往往不够。接收方还要知道报告覆盖了哪些安全需求，对应什么版本，在哪些条件下测试，有没有尚未关闭的问题。把这些内容写进交付约定，收到文件后才有办法判断它能否用于集成和安全论证。

　　二、ISO 26262开发接口协议怎么划分职责

　　以整车厂委托供应商开发控制器为例，整车厂掌握整车架构和使用场景，供应商掌握控制器内部的设计与实现。下面是一种分工示例，实际责任以开发范围、安全计划和双方协议为准。

　　1、按验证对象分配工作

　　同一项安全需求可能在两边都要验证。比如控制器检测到通信超时后要进入规定状态，供应商可以在台架上核对控制器的响应，整车厂则可以在集成后检查其他控制器和整车功能是否按预期处理这一状态。

　　①在【需求分配】中写明整车厂提供的安全需求、接口条件和验收依据，并记录供应商负责实现和验证的部分。

　　②在【控制器验证】中列出供应商应交付的测试结果，注明覆盖的需求、测试配置和交付版本。

　　③在【整车集成验证】中明确实际网络和供电条件下的测试由谁执行，以及供应商需要提供哪些工具、接口说明或故障注入支持。

　　2、把跨边界的使用假设交给能够核实的一方

　　①将供应商提出的【使用假设】逐条登记，例如供电范围、故障信号接收方式或外部诊断条件。

　　②给每项假设填写【核实责任人】、【验证方法】和【证据位置】。需要在整车上核实的条件，可以由掌握整车设计和试验资源的一方负责。

　　③在【未满足假设】中记录发现的问题、受影响的需求和处理决定，明确由哪一方调整设计或补充验证。

　　例如供应商的台架测试只证明控制器能在规定时间内发出故障信号，而系统要求还包括其他控制器收到信号后的响应。后一段需要有对应的责任人和验证证据。即便两边各自的测试都通过，只要中间的信号接收条件没有核实，整条响应链就仍有一段缺少证据。

　　3、给双方共同完成的事项指定牵头方

　　①在【联合活动】中写清谁发起评审、谁提供资料、谁记录结论，以及由谁跟踪遗留问题。

　　②对涉及硬件安全分析的交接，在【硬件安全分析输入】中约定双方交换的资料、假设和适用配置。

　　③在【沟通与升级】中记录安全问题的通知对象、响应时限，以及双方意见不一致时的处理方式。

　　三、开发接口协议签订后怎么跟踪执行

　　协议签订以后，容易发生变化的是实际交付版本和验证安排。样件换版、诊断策略调整，或者某项试验延期，都可能让原先约定的证据无法覆盖当前交付。集成前可以拿实际收到的资料逐项对照。

　　1、在集成前核对证据对应的版本

　　①打开【交付清单】，核对软件版本、硬件版本和配置标识，确认它们与计划上车的样件对应。

　　②在【验证报告】中检查测试对象、需求版本和未通过项。报告覆盖旧版本时，将受影响的验证列入待办。

　　③在【评审记录】中写明接收结论、待补资料及负责人。对尚未关闭的问题，注明它影响哪个集成或发布节点。

　　2、用一次变更检查责任是否接得上

　　例如供应商调整了故障信号的发送周期，改动看似只在控制器内，接收端原先设定的超时阈值也可能受到影响。

　　①在【变更请求】中登记改动内容、涉及的接口和预计生效版本，并通知接收方。

　　②由双方完成各自范围内的【影响分析】，明确需要更新的需求、接口说明和验证证据。

　　③在【变更评审记录】中写清补测安排和关闭条件。若交付范围、双方职责或评审节点发生变化，同步更新【DIA】和相关安全计划。

　　总结

　　一份DIA写得是否到位，可以用一个具体故障场景来检验。拿着同一份协议，整车厂能找到供应商应提供的证据，供应商也知道哪些使用条件会在整车上核实。遇到版本变更时，双方还能看出谁负责判断旧报告能否沿用。把这些问题在开发早期谈清楚，后续即使换人接手，安全活动也有据可查。