SYS.4 系统集成与集成验证，面向完整系统要素，包含软件、硬件、机械部件的组合，重点验证系统架构定义的外部接口、时序、电气交互。不少研发团队做完软件组件集成之后，直接复用 SWE.5 产出物当做 SYS.4 的证据，忽略真实硬件环境下的信号交互、时序冲突、电气兼容性等场景。软件集成只能验证软件模块之间的调用关系，无法覆盖 ECU 和传感器、执行器、总线网络的真实交互，如果两类集成证据混在一起，ASPICE 评估抽样取证的时候，就会发现系统集成验证存在大量场景缺失。

落地 ASPICE SYS.4 系统集成与集成验证，经常遇到几类典型问题。没有独立编写 SYS.4 系统集成策略，复用软件集成的集成顺序、准入准出条件。系统集成用例只覆盖软件内部逻辑，缺少软硬件交互、总线报文时序、真实电气工况相关场景。系统集成测试用例错误绑定系统需求，没有和 SYS.3 系统架构要素建立追溯关系。软硬件发生变更之后，回归测试策略缺失，分不清哪些系统集成用例需要重测。HIL、台架执行的系统集成原始执行记录散落工程师本地，没有纳入 ASPICE 项目基线统一归档。

ASPICE 里面 SYS.4 和 SWE.5 的核心区别，SWE.5 聚焦软件组件之间接口；SYS.4 立足于系统架构，验证跨软硬件要素的交互行为，二者的测试环境、测试依据、验证重点完全不一样，不能互相替代。

亚远景 APMS 研发过程管理平台可以独立管理 ASPICE SYS.4 全套工作产物。维护系统集成策略文档，定义系统要素组装顺序、集成各阶段准入准出准则、回归测试选择规则。SYS.4 系统集成验证用例绑定 SYS.3 系统架构要素，完成双向追溯，和软件集成用例做标记区分。每一轮系统集成的 HIL、台架测试原始结果完整归档，绑定对应系统基线。当硬件、系统架构发生变更，平台提示评估系统集成回归范围，避免跳过必要的系统集成验证。

亚远景 DPAI 垂类 AI 可以读取系统架构文档，梳理外部接口、时序交互场景，输出系统集成用例初稿，提示哪些硬件交互接口缺少对应的验证场景，用例评审确认依旧由系统测试工程师完成。

亚远景 PCAT 过程能力评估工具预置 SYS.4 专项检查点。内部预评估阶段区分核查软件集成、系统集成两套 ASPICE 证据，检查集成策略、用例追溯、原始执行记录，识别拿软件集成报告顶替系统集成证据的问题，在正式 ASPICE 评估之前完成整改。

工具负责产物归集、基线管控、风险提示，但系统集成顺序设计、硬件交互场景设计，需要系统工程师结合硬件环境完成。分清系统集成与软件集成的证据边界，完整落地 SYS.4 的各项实践，才能够满足 ASPICE 评估取证要求。