降级行为是车载 ECU 保障安全的重要机制，一旦检测到硬件故障、信号异常，系统关闭部分非必要功能，维持安全状态。从功能安全角度，降级策略来源于 HARA 分析，用来规避危害事件。但从网络安全视角，如果攻击者可以通过报文、诊断接口人为触发降级，会刻意把车辆带入受限状态，影响用户使用，甚至衍生出新的安全风险。

降级策略落地常见合规短板。降级相关需求只来源于功能安全 HARA 分析，没有结合 TARA 分析考虑恶意触发的场景。降级触发条件缺少鉴权防护，外部异常报文可以轻易诱导系统进入降级模式。降级之后的状态缺少审计日志，无法区分是真实硬件故障还是外部攻击导致。验证只做真实故障注入测试，缺少模拟恶意攻击诱导降级的测试场景。降级相关的需求、设计、测试没有建立完整追溯链路。

降级逻辑不能只作为功能安全专属逻辑，需要同时纳入网络安全分析，依托 ASPICE 需求、设计、验证过程完成完整管控。

需求阶段，除 HARA 导出的故障降级需求之外，开展 TARA 分析，识别攻击者诱导非预期降级的威胁场景，补充对应的网络安全防护需求。明确什么条件属于合法故障触发，什么情况属于可疑异常访问，定义审计记录要求。所有降级相关需求标记 ASIL 与 CAL 等级，建立双向追溯。

设计阶段，区分真实硬件故障信号和外部输入信号。对于来自总线、诊断的外部触发源，增加鉴权、报文校验、异常频次检测，避免恶意报文随意触发降级。设计降级之后的日志记录，记录触发原因、时间、触发源。评审环节同时邀请功能安全和网络安全工程师参与，确认降级逻辑既满足故障处置，又能够抵御恶意诱导。

测试验证阶段，分为两类场景开展测试。一类是真实硬件故障注入，验证功能安全降级逻辑可以正确生效；另一类构造恶意报文、异常诊断请求，验证系统不会被恶意触发非预期降级。降级相关测试用例和对应的安全需求建立追溯，完整归档测试报告。如果降级行为会改变原有安全机制，需要重新评估残余风险。

内部预审的时候，核查降级相关全套证据，确认同时覆盖功能安全故障场景和网络安全威胁场景，追溯链路完整。

软件降级是安全机制的集合，功能安全关注故障下如何保护车辆，网络安全关注如何防止被恶意滥用这套机制。将两方面分析结合，需求、设计、验证同步覆盖两类场景，才能同时满足 ASPICE、ISO26262、ISO/SAE21434 的审核要求。