车企存量车型迭代过程中，出于成本考虑，不少 ECU 不会更换硬件，直接在原有硬件基础上修改软件，修复缺陷或者新增部分功能。这类遗留 ECU 普遍存在硬件算力、存储资源紧张，缺少硬件安全模块，早期开发留存的需求、设计、测试文档残缺不全等现实情况。项目既要完成功能迭代，又要满足新版的 ASPICE、ISO26262、ISO/SAE21434 的审核要求，给研发和质量团队带来不小挑战。

遗留 ECU 改造项目很容易陷入两类误区。一类直接沿用十几年前的开发习惯，只关注新增功能实现，忽略过程证据、安全分析，等到客户审核时发现大量缺失项。另一类直接照搬全新开发项目的全套标准流程，完整复刻全套 HARA、TARA、追溯文档，受限于硬件资源，很多安全机制无法部署，出现标准要求和硬件现实条件互相矛盾。

三套标准在遗留 ECU 改造项目中，不能完全套用全新开发的执行逻辑，需要结合硬件固有约束做风险导向的实施策略。

项目启动阶段，开展现状摸底与边界界定。梳理原有 ECU 硬件能力限制，确认硬件是否支持安全相关机制部署，整理已有历史文档，标记文档缺失部分。明确本次改造的变更边界，区分哪些是新增修改逻辑，哪些完全沿用旧版本代码。基于变更范围重新开展 HARA 危害分析与 TARA 威胁分析，重点评估本次软件改动会不会引入新的失效场景与攻击路径，原有硬件固有的安全局限也需要完整记录在风险报告中，给出对应的缓解措施，而不是强行要求实现硬件不支持的防护手段。

需求与设计环节，区分复用部分和变更部分开展管控。完全复用不改动的旧代码，不需要重复全套重新开发，但是要完成复用部件的评估，确认原有部件在当前变更场景下风险可接受。发生修改的代码部分，完整执行 ASPICE 需求、架构、详细设计流程，更新对应的安全需求，标注 ASIL 等级与网络安全风险属性。亚远景APMS 平台可以将新旧工作产物统一纳入管理，补齐缺失的追溯链路，改动部分的需求、设计、缺陷、测试形成完整闭环，未改动的遗留模块保留原有归档记录，实现新旧内容的分区管理。

测试与风险处置阶段，聚焦变更影响域开展验证。不需要对整个 ECU 执行全量回归测试，围绕变更影响范围设计测试用例，同时补充安全相关验证项。对于硬件短板带来的残余风险，通过系统层面的机制、外部 ECU 协同、诊断监控等方式做风险缓解，残余风险需要经过评审确认并完整归档。亚远景DPAI 可以辅助逆向解析部分遗留代码，补充缺失的设计文档初稿，减少手工补写文档的巨大工作量。

版本发布前，利用 亚远景PCAT 开展内部多标准联合预审。对照 ASPICE 过程检查项、功能安全与网络安全检查清单，核查变更证据、风险分析、残余风险处置记录，识别流程缺口。所有评估证据线上留存，作为客户或者第三方审核的材料。

遗留 ECU 改造的核心逻辑不是把旧项目硬改成新项目，而是以变更影响域为核心，风险导向补齐过程与安全证据。尊重硬件现实约束，把资源集中在改动带来的新增风险点上，在成本、硬件限制和行业合规之间找到可行平衡点。