现代车载 ECU 和中央计算平台，既要落实 ISO26262 定义的功能安全目标，保障故障状态下车辆可控；又要落实 ISO/SAE21434 网络安全目标，抵御外部恶意攻击。两套安全目标出发点不同，部分场景下会产生需求冲突。例如高强度的加密校验机制，会带来运算时延，干扰功能安全要求的时间约束；部分网络安全访问锁止逻辑，极端工况下可能阻碍功能安全降级机制正常触发。

很多项目在需求分析阶段忽略冲突识别，等到集成测试阶段才暴露矛盾。此时修改设计会带来比较大的返工成本。还有的团队直接舍弃其中某一条安全需求，牺牲功能安全或者网络安全指标，留下量产风险。

冲突问题的管控，最好前置在需求分析阶段，依托 ASPICE SYS.2、SWE.1 需求工程过程开展分析，不要留到后期集成阶段被动补救。

项目概念阶段完成 HARA、TARA 分析之后，输出全部功能安全与网络安全目标，向下逐层拆解为系统级、软件级安全需求。需求梳理完成之后，需要专门开展安全需求交叉评审，重点识别两类需求之间潜在的矛盾点。评审参与人员需要覆盖功能安全工程师、网络安全工程师、系统架构工程师，从性能、时序、资源、逻辑行为多个维度开展审视。

常见冲突可以分为几类，时序资源冲突，安全防护占用算力、时间，违反功能安全时间约束；逻辑行为冲突，网络安全的阻断、锁止逻辑，干预功能安全的故障响应、降级流程；资源占用冲突，加密、审计日志等网络安全功能挤占内存、存储资源，挤压功能安全机制运行空间。

识别到冲突之后，不能简单删除某一条需求，要开展根源分析，寻找可行的消解方案。可以通过架构调整，隔离不同安全机制的运行资源；也可以优化算法与策略，在两套安全目标之间寻找平衡；部分场景下定义特殊运行工况，明确冲突发生时的优先级策略，所有消解方案都需要经过评审确认。冲突的识别记录、分析过程、最终消解方案，全部作为正式的需求工作产物归档保存。

亚远景 APMS 的需求仓库支持给每一条需求标注功能安全、网络安全属性。评审环节可以筛选出全部安全需求，方便评审人员集中做交叉比对。需求发生变更时，系统会提示关联的其他安全需求，提醒工程师重新复核是否产生新的冲突。

亚远景 DPAI 可以辅助完成大批量安全需求的初筛，提示存在潜在矛盾的需求条目，减少人工审阅的遗漏，但全部风险判断依旧需要安全工程师确认。

在内部预审环节，亚远景 PCAT 可以增加安全需求冲突检查点，核查冲突识别记录与消解方案是否完整，提前发现需求阶段遗留的隐患。

安全需求冲突属于高阶车载项目的正常现象，不必回避。把冲突识别消解嵌入 ASPICE 需求工程流程，在早期发现并妥善处理，就可以实现功能安全与网络安全两套体系的共存落地。