诊断管理的主要内容是故障管理。系统运行期间，功能自诊断因为随机失效会产生相当数量的故障指示，不加处理容易造成虚警；对于正常的故障诊断，故障信息存储也容易受到非易失性存储资源的限制。故障管理将处理本地所有功能自诊断的故障指示，根据故障特性进行“识别-确认-退出”的过程管理；存在多个故障时进行类似堆栈的处理，保证高优先级故障信息的存储；根据诊断协议的指令输出或清空故障信息。

　　5.3诊断通信

　　区别于总线的在线通信，诊断通信被称为离线通信，盖因其非常在线特点。其服务层为诊断功能提供国际通用和自定义两种诊断服务支持。诊断服务层为上层屏蔽具体通信特征，使其只考虑功能应用方面。每条诊断服务作为控制器功能的触发条件或入口点。诊断服务层提供诊断服务(service)的软件实施效率是保证控制器能够及时响应外部诊断诊断请求的重要因素之一。其会话层控制器与诊断工具之间的通信使能，打开或断开双方的通信。当诊断工具与控制器间的应用服务无法维持时关闭这些服务。将所有服务功能分布到合适session中，满足诊断功能分级是该设计目的。其传输层设计实现块数据的传递功能，为大数据量的传递提供通信通道。此外还需定义传输层与上、下层之间的软件接口，优化匹配参数。除诊断数据外，应用功能也存在块数据传输需求(例如曲目名称)，因此传输层也面向应用软件。其物理层将定义其相应的具体总线协议的初始化，如诊断数据帧标识符ID分配，还包括一些特殊硬件操作，如诊断工具接入步骤。

　　5.4 配置系统(图10)

　　基于市场、工程等多方面需要，整车网络存在大量的通过诊断进行的信息配置。以中级车为例，整车配置信息多达上百条、数十千比特。在项目的不同阶段，对上述配置进行正确无误的快速处理是配置系统的主要功能。

六、集成测试(图11)

　　不同于零部件实施的测试，集成测试关注的是系统层面的测试验证。

　6.1基础测试

　　基础测试针对系统中总线、诊断等系统功能：控制器是否能够及时地通过总线将采集到的传感器信号传递给其他控制器，是否能够及时响应其他控制器通过总线传递的指令并驱动执行机构；网关实现的功能是否正确(满足设计要求)；所有控制器是否能按规定进入／退出睡眠模式(网络管理策略是否满足设计规范)；控制器网络的电流消耗是否在规定的范围之内；总线负载是否符合设计要求；在线诊断功能是否符合设计要求。

　　6.2功能测试

　　根据系统架构、功能需求等设计规范，结合测试平台结构和测试环境特点生成测试规范。测试规范详细定义了测试要求和步骤，包括点火开关状态、功能实现的条件、功能结果、具体描述及注意事项等。同时对误用滥用也要进行详尽分析，生成相应的测试文档。

　　根据上述测试规范进行详细的功能测试，以确认集成效果是否满足设计规范。测试解决方案建立在标准系统框架基础上，通过开放式接口提供完整的模型设计、测试设计、诊断和标定设计，虚拟试验环境、实时仿真模型、试验和试验参数可在不同设计阶段和项目中得以复用。

　　七、总结

　　本文对整车网络开发和系统开发工作进行了详细描述，结合嵌入式理论介绍了基于功能面向需求的架构设计方法以及总线、诊断、集成测试的工作重点。