ASPICE SYS.4关注系统要素按照既定顺序完成集成，并验证系统架构中定义的接口、信号流、时序依赖和动态交互是否正确。处理“ASPICE SYS.4系统集成验证怎么进行，ASPICE SYS.4验证结果不满足要求如何分析”时，需要从集成前提、验证措施、结果记录和问题闭环几个环节连续推进。需要特别区分，SYS.4主要验证集成后的系统是否符合【系统架构】，针对系统需求的整体系统验证则属于SYS.5。以下按正式发布的Automotive SPICE 4.0要求说明。

　　一、ASPICE SYS.4系统集成验证怎么进行

　　SYS.4不能等系统全部装好后再集中测试，而应按照系统架构确定集成顺序，每完成一个集成步骤，就执行与该阶段相匹配的验证措施。Automotive SPICE 4.0将验证措施定义、措施选择、系统集成与验证、双向追溯以及结果沟通列为SYS.4基本实践。

　　1、先确定集成顺序和准入条件

　　①根据系统架构列出ECU、传感器、执行器、通信网络及其他系统要素之间的依赖关系。

　　②确定【先集成哪些要素】【后集成哪些要素】，形成明确的集成顺序。

　　③为每个阶段定义【准入条件】，例如相关系统要素验证已经通过、接口版本已经冻结、测试环境已经可用。

　　④同时定义【准出条件】，用于判断当前集成阶段能否进入下一阶段。

　　SYS.4要求集成活动基于已定义的顺序和前提条件开展，已有系统要素也应具备相应的验证或鉴定依据。

　　2、针对系统架构定义验证措施

　　①从系统架构中找出需要验证的接口和交互。

　　②为每项验证明确【验证技术】【通过/失败准则】【准入条件】【准出条件】以及所需环境。

　　③接口验证要覆盖信号方向、信号值、接口解释是否一致。

　　④存在实时交互时，还要加入响应时间、消息顺序、超时和同步关系检查。

　　官方对SYS.4.BP1的要求明确包括系统要素之间的正确信号流、信号时效性和时序依赖，以及软硬件之间的动态交互。

　　3、根据发布范围选择实际执行的验证项

　　①确定本次集成对应的发布范围。

　　②根据需求优先级、系统架构变化和组件变化选择需要执行的验证项。

　　③发生接口或组件变更时增加【回归验证】。

　　④确认验证措施能够覆盖本次真正交付的系统范围。

　　Automotive SPICE 4.0要求为每个集成步骤记录验证措施的选择，并把回归验证需求和最终交付用途纳入选择依据。

　　4、执行集成并记录完整结果

　　①按照既定顺序逐步集成系统要素。

　　②每完成一个阶段立即执行相应验证。

　　③记录【通过/失败状态】以及测量值、日志、波形、通信记录等验证数据。

　　④将验证措施关联到对应系统架构要素，再把验证结果关联回对应验证措施。

　　SYS.4要求验证措施与系统架构、验证结果与验证措施建立双向可追溯性；只有存在链接还不够，两侧内容本身也必须保持一致。

　　二、ASPICE SYS.4验证结果不满足要求如何分析

　　出现失败结果后，先保存当时的集成状态和验证证据，再判断问题属于产品、接口、环境还是验证措施本身。SYS.4明确要求偏离预期的验证结果按照SUP.9问题解决管理处理。

　　1、先确认失败结果能否稳定复现

　　①记录失败用例编号、软件和硬件版本、测试环境以及输入条件。

　　②保持同一集成版本重新执行一次。

　　③对比预期结果、实际结果和失败发生位置。

　　④无法稳定复现时，补充总线日志、时间戳和运行环境信息后再测试。

　　SUP.9要求问题被唯一标识和记录，并保留能够支持复现与诊断的信息。

　　2、沿系统架构接口定位原因

　　①从失败验证项追溯到对应的系统架构接口。

　　②先检查接口两端的信号定义、数据类型、单位和取值范围。

　　③再检查发送周期、接收超时、初始化顺序和状态切换条件。

　　④涉及多个系统要素时，逐步减少参与节点，定位最早出现偏差的位置。

　　如果单个系统要素独立验证正常，而集成后才出现问题，应重点检查接口解释、时序关系和动态交互，这些本身就是SYS.4验证的主要关注对象。

　　3、判断失败来自产品还是验证措施

　　①重新核对当前验证步骤是否对应最新系统架构版本。

　　②检查【通过/失败准则】是否明确并可测量。

　　③确认测试环境、仿真模型和测试设备配置与计划一致。

　　④如果验证措施本身存在错误，先修正验证定义，再重新执行；如果产品行为不符合架构，则进入问题解决和变更流程。

　　SUP.9要求分析问题原因和影响并进行分类，而SYS.4同时要求验证措施与系统架构保持一致，因此测试失败不能未经分析就直接归因于产品缺陷。

　　三、验证问题修正后怎么完成闭环

　　问题修复以后，如果只把原失败用例重新跑成“通过”，仍不足以证明SYS.4活动已经完整结束。还需要确认变更有没有影响其他接口，并把新的验证结果重新纳入追溯和发布判断。

　　1、执行针对性验证和回归验证

　　①先重新执行原失败验证项，确认问题已经消除。

　　②根据修改涉及的系统架构要素进行影响分析。

　　③把受影响的相邻接口和动态交互加入【回归验证范围】。

　　④全部完成后更新验证结果和问题状态。

　　回归验证本身就是SYS.4验证措施选择需要考虑的准则，SUP.9还要求问题及相关变更持续跟踪直至关闭。

　　2、重新检查追溯和发布证据

　　①检查验证措施是否仍与当前系统架构版本对应。

　　②检查所有失败项是否已有明确处理结果。

　　③确认验证结果、问题单和相关变更能够互相追溯。

　　④汇总本次系统集成状态、剩余风险和验证结论，并通知受影响方。

　　SYS.4最终要求形成验证措施、集成顺序、验证数据、验证结果、一致性证据和沟通证据等输出，并将系统集成与验证结果传递给相关方。

　　总结

　　SYS.4做得是否扎实，关键看系统架构中的接口和交互能不能通过一套有准入、有判定、有证据的集成验证被证明出来。验证失败后，沿着【验证结果→验证措施→系统架构】追溯，再结合SUP.9分析原因和影响，比单纯重复测试更容易找到真正的问题；修复后继续完成影响分析和回归验证，才能让结果具备发布依据。如需进一步了解ASPICE SYS.4系统集成验证实施、验证失败原因分析及问题闭环方法，欢迎联系咨询。