诊断系统承担故障探测、DTC 故障码存储、状态读取、例程控制等能力。从功能安全角度，ECU 检测到安全相关故障，需要通过诊断记录故障信息，触发对应的降级安全机制。从网络安全角度，外部通过诊断接口可以读写内存、执行例程、修改标定参数，一旦接口防护失效，会带来篡改、越权访问风险。不少项目开发时，功能安全团队输出故障处理需求，网络安全团队输出鉴权防护需求，诊断开发团队单独编写诊断需求，几套需求相互独立，没有建立关联。

诊断开发场景下容易出现几类合规短板。安全相关故障的检测逻辑、DTC 存储需求没有继承上层功能安全目标，故障发生之后诊断上报逻辑和安全降级机制不同步。诊断的会话、安全访问需求没有和 TARA 分析识别出来的攻击场景对应，部分高危诊断例程缺少权限管控。诊断需求没有纳入统一需求库，存放在单独的诊断规范文档，和系统、软件需求缺少追溯链路。诊断相关测试只验证报文交互，缺少故障注入场景、越权访问场景的验证。诊断需求发生变更，不会触发功能安全、网络安全影响复核。

诊断不是普通附加功能，它同时承载功能安全与网络安全职责，相关需求必须纳入 ASPICE SYS.2、SWE.1 需求工程过程统一管理。

项目需求阶段，把诊断相关条目全部纳入统一需求库。从功能安全目标向下推导，明确安全相关故障对应的 DTC 定义、故障存储、故障冻结帧、故障触发后的降级行为，保证诊断故障处理逻辑承接 HARA 输出的安全目标。基于 TARA 威胁分析结果，定义诊断会话、安全访问、例程权限、报文校验类网络安全需求，明确哪些诊断服务属于高危操作，需要增加鉴权、时间锁、访问次数限制。每一条诊断需求标注对应的 ASIL 等级或者网络安全风险等级，建立和上层安全需求的双向追溯。

设计开发阶段，保证故障检测逻辑、降级策略、诊断存储逻辑相互协同。安全相关故障触发时，既要执行功能安全降级，也要完成 DTC 记录。高危诊断服务严格执行鉴权校验，防止外部未经授权调用。诊断发生需求变更时，触发安全影响分析，评估改动会不会改变故障处理逻辑或者攻击面。

测试阶段除常规报文交互测试之外，补充两类专项验证。开展故障注入测试，验证安全故障发生时，DTC 记录、降级行为符合安全需求；开展网络安全测试，验证越权访问、非法会话切换会被正确拦截。诊断测试用例和对应的诊断、安全需求建立追溯，测试报告统一归档。

内部预审环节，核查诊断需求和安全需求之间的追溯关系，检查安全故障处理、高危诊断服务防护相关的测试记录。

诊断接口是 ECU 对外重要交互入口，串联起功能安全故障处置与网络安全访问防护。将诊断需求纳入整体需求体系，打通安全与诊断之间的链路，才可以同时满足 ASPICE、ISO26262、ISO/SAE21434 的审核要求。