软件异常包含内部运行故障，也包含外部输入带来的非法报文、错误数据。站在 ISO26262 角度，异常检测和故障恢复属于重要安全机制，用来规避危害事件；站在 ISO/SAE21434 角度，攻击者可以刻意注入异常数据，诱导软件进入错误状态，引发拒绝服务、逻辑跳转等风险。不少项目开发异常逻辑只考虑真实硬件故障场景，没有考虑恶意输入带来的风险，异常相关需求分散在各个文档，没有纳入统一管控。

异常处理机制落地经常出现合规短板。异常相关需求零散分布在设计文档，没有作为独立需求录入需求库，缺少 ASPICE 双向追溯。只针对硬件故障做异常处理，不考虑外部恶意异常输入，缺少报文校验、异常频次统计等防护逻辑。异常发生之后的状态留存、故障日志定义不全，分不清故障来自硬件失效还是外部攻击。验证只做正常故障注入测试，缺少恶意构造异常输入的测试场景。异常处理逻辑发生改动，没有触发安全层面的影响分析。

异常处理不是单纯的代码容错逻辑，要把整套机制纳入 ASPICE 需求、设计、验证完整研发链路，同步兼顾功能安全和网络安全两类视角。

需求阶段，梳理全部异常场景，区分内部故障与外部输入异常。从 HARA 导出故障检测、故障降级、故障恢复相关需求；从 TARA 分析补充抵御恶意异常注入的防护需求。全部异常相关需求标记 ASIL、CAL 等级，纳入统一需求库，建立双向追溯。明确异常发生后的日志记录要求，留存异常来源、发生时间等关键信息。

设计阶段，区分真实硬件故障与外部输入事件。外部总线、诊断输入增加报文校验、异常频次阈值检测，避免大量恶意异常占用系统资源。定义异常触发之后的处理链路，包含报错、限制功能、降级、重启恢复等行为。评审环节同时邀请功能安全、网络安全工程师参与，确认异常逻辑既可以处置真实故障，也可以抵御恶意诱导。

测试验证阶段，开展两类场景的测试。一类是硬件故障注入，验证功能安全故障处置逻辑；另一类构造恶意异常报文、非法输入，验证系统不会被恶意异常滥用。异常相关测试用例和对应需求做好追溯，完整归档测试报告。异常逻辑发生变更时，执行多维度影响分析，评估对安全目标、攻击面带来的改变。

内部预审环节，核查异常全套需求、设计、测试证据，确认同时覆盖故障场景与恶意输入场景，追溯链路完整。

软件异常处理是安全防护的集合，既要处理真实运行故障，也要防备人为构造的异常攻击。将异常机制完整纳入 ASPICE 研发流程，才能够同时满足 ASPICE 评估、ISO26262、ISO/SAE21434 的审核要求。