AP AUTOSAR——诊断管理DM （R21-11）
诊断管理
诊断管理是自适应平台基础中的一个功能集群。作为功能集群，诊断管理包括一个与自适应应用程序链接的库和一个实现诊断管理活动方面的守护进程。RTA-VRTE 启动工具包提供的诊断库提供了 C++ API，用于支持自适应应用程序在运行时访问诊断管理。
实现ISO 14229-5（UDSonIP），基于ISO 14229-1（UDS）和ISO 13400-2（DoIP）。
是AUTOSAR Adaptive平台（AP）Foundation层上的功能集群（FC）。
配置基于传统AUTOSAR Classic平台（CP）的AUTOSAR Diagnostic Extract Template（DEXT）。
责任
诊断管理的主要目的是支持汽车电子/电气系统的监控，它提供了一系列功能来检测、警告和从故障中恢复。AUTOSAR 诊断管理提供的功能包括：
当前系统状态指示，例如“警告指示灯”。
系统监控自适应应用程序，以识别不良状况，并在检测到故障时，由诊断管理存储故障发生时的记录以及足够的车辆状态数据以便故障排除。
诊断事件修复 - 跨操作周期跟踪报告的故障，允许从故障条件中恢复（如果可能），以将车辆恢复到已知状态。
支持诊断客户端和服务器之间通信的统一诊断服务（UDS）协议。
软件簇（SWCL）
软件簇的管理 ：
管理原子可升级/可扩展部分。
SWCL包含与部署/更新功能/应用相关的所有部分。
为每个安装的SWCL分配独立的诊断地址。
SWCL与UCM的软件包耦合，可以被更新或者新安装。
统一诊断服务
AUTOSAR 诊断管理的核心在于接收和处理来自网络层的统一诊断服务（UDS）请求。
UDS 通信由客户端请求和诊断服务的响应组成，例如客户端向 ECU 请求启动 UDS 服务，处理后，ECU 发送回正面或负面的响应（如果响应被抑制则不响应）。
UDS 并不是特定于 AUTOSAR 的，而是一种为 ECU 环境（汽车电子领域）设计的诊断通信协议，该协议在ISO 14229-1:2013 标准中进行了标准化。
Diagnostic Session Handling
工作流程
当收到 UDS 请求时，诊断管理从传输层中提取与传输层无关的 UDS 信息，然后尝试通过将其关联到现有的 UDS 会话来处理请求：
它检查诊断请求在当前会话中是否被允许，以及安全设置（如正确的参数（长度、服务标识符（SID）、子功能、条件等））是否有效。
如果检查失败，请求会被拒绝；否则，诊断管理负责生成内部响应或将请求传递给外部应用程序处理。
UDS请求处理
接收UDS请求 ：
诊断服务器从传输层接收UDS请求，并提取与传输层无关的UDS信息。
校验请求 ：
诊断服务器校验请求的合法性，包括参数长度、服务标识符（SID）、子功能和安全设置等。
分配请求 ：
根据当前会话和安全级别将请求分配给已有诊断对话、新建诊断对话或拒绝请求。
UDS 定义了许多服务，可以用来访问 ECU 内部的信息，控制 ECU 内部的诊断功能，以及建立和控制诊断会话 。
通常，当客户端请求 UDS 服务时，服务器通常会在默认会话中启动。然后，根据 UDS 服务 DiagnosticSessionControl (0x10) 定义的会话请求类型，可以启动特定会话。这些会话在 ISO 14229-1:2013 中定义，包括：
编程会话
扩展诊断会话
安全诊断会话
诊断会话管理
诊断对话生命周期管理 ：
从接收到第一个UDS请求开始，到诊断会话取消或完成处理。
会话保活 ：
非默认会话的诊断对话进行保活，直到Session超时。
诊断故障代码详解
在AUTOSAR诊断中，诊断故障代码（DTC） 代表车辆中检测到的某些问题（通常对生产或维修很重要）。DTC由3个字节组成，并使用 DiagnosticEventToTroubleCodeUdsMappingARXML 元素映射到诊断事件，使得这些事件可以由DTC代码唯一标识。诊断管理使用DTC来唯一标识事件内存数据库中的数据。
DTC有多种解释方式，AUTOSAR诊断支持ISO 11992-4、ISO 14229-1:2013和SAE-J2012-DA。这些不同的解释仅影响诊断报告，而不影响其他功能。多个DTC可以组合成一个诊断故障代码组（DiagnosticTroubleCodeGroup），允许诊断在一次操作中处理组内所有DTC。DTC组使用一个专用的DTC值来标识，这个值在有效DTC范围之外。为了方便，诊断提供了DTC组“GroupOfAllDTCs”（分配给DTC组标识符0xFFFFFF），始终包含所有配置的DTC。
AUTOSAR 诊断摘要
RTA-VRTE Starter Kit 诊断使用 AUTOSAR Diagnostic Extract Template (DEXT) 进行配置。DEXT 是一种标准化的 AUTOSAR 交换格式，可以与系统描述（System Description）类似地使用和通信。DEXT 定义了诊断通信的所有方面（例如 UDS 服务、会话配置、安全级别配置等）和诊断事件管理（例如诊断故障代码（DTCs）、诊断事件、操作周期等）。DEXT 还支持从多个源合并信息，使诊断配置可以从最合适的源（无论是应用开发人员、集成商还是OEM）构建。
经典和自适应 AUTOSAR 中的诊断
自适应平台诊断管理的组织和责任与经典平台中的诊断栈有很多相似之处。概念上，诊断架构分为三个子组件：诊断通信管理器 (DCM)、诊断事件管理器 (DEM) 和传输协议 (DoIP)。
诊断事件管理器 (DEM)
功能 ：处理诊断事件（如应用错误或其他有趣的报告），绑定诊断故障代码 (DTCs) 与诊断事件，并更新 DTC 状态。
特点 ：诊断事件在系统范围内是唯一的，一个事件只能由单个应用报告。在自适应平台中，应用通过一个由 DiagnosticMonitorInterface 分类的端口原型访问事件，该接口具有到服务依赖项的诊断映射。
数据存储 ：在自适应平台实现中，DTC 及其相关的环境信息（称为 Freeze Frame）使用持久性功能集群存储在文件系统中的文件中。这与经典平台中在非易失性存储器中保留事件存储器的方式不同。
事件存储与处理
报告诊断事件 ：自适应应用使用rd-diag库中的API报告诊断事件。
存储事件数据 ：诊断管理器根据诊断事件更新故障代码（DTC）状态，捕获和存储环境数据（SnapshotRecords和ExtendedDataRecords）。
诊断通信管理器 (DCM)
功能 ：负责 UDS 和（在经典平台中）SAE J1979 的通信路径和诊断服务的执行。
DCM 转发来自外部诊断扫描工具的诊断请求，并负责组装响应消息（如 DTC、状态信息等），这些消息将传输到车辆内部测试仪或外部诊断工具。
实现诊断服务，类似于CP中的DCM。
支持有限的诊断服务，后续将扩展更多UDS服务。
可以在默认会话下支持客户端的全并行处理，满足现代汽车架构的需求。
传输协议 (DoIP)
功能 ：自适应平台诊断管理支持“基于IP的诊断”（DoIP）通信协议，因此任何合适的诊断 UDS 客户端都可以与 RTA-VRTE Starter Kit 诊断管理一起使用。
在经典平台中，传输协议与 DEM 和 DCM 分开处理。
RTA-VRTE Starter Kit 诊断概述
RTA-VRTE Starter Kit 诊断组件包括 诊断管理器（DM） 进程（rb-dm）和一个库（rb-diag）。
诊断管理器进程rb-dm 负责管理诊断事件、UDS 会话控制、UDS 通信等，必须由执行管理在 RTA-VRTE Starter Kit 平台启动时启动。
rb-diag 库与自适应应用程序链接，提供 ara::diag 诊断接口的 API 实现。由于该库与应用程序链接，API 在应用程序的上下文中运行。
诊断管理器的作用
诊断管理器（即 rb-dm 进程）是处理诊断通信和支持 UDS 请求的核心元素。
UDS 请求在诊断对话的上下文中处理，这代表了诊断客户端（测试仪）与诊断服务器之间的对话。
自适应应用程序使用 rd-diag 库中的 API 向诊断管理器报告诊断事件 。诊断事件报告受监控实体的状态，并在系统中唯一标识该实体。
当 rb-dm 从应用程序收到事件通知时，它会执行诊断配置中定义的任何操作，例如更改诊断故障代码（DTC）状态，或捕获和存储与该诊断事件相关的环境数据（扩展数据记录或快照记录）。因此，事件是 rb-dm 事件内存管理的输入源 。
动态配置
RTA-VRTE Starter Kit 诊断管理是完全动态配置的。它使用基于 FlatCFG 数据的配置文件部署到目标 ECU 以配置诊断提取信息（例如，当 ECU 上的软件更新时，诊断信息可能会发生变化），以及一个用于主要 TCP/DoIP 设置的二进制文件（dm_config.bin）。更多配置细节见 15.1.3 节。
初始化和依赖关系
诊断管理器（DM）守护进程 rb-dm 必须由执行管理作为 AP平台启动的一部分启动。该进程还依赖于以下平台元素，这些元素必须在 rb-dm 启动前启动：
ara::com ：用于与自适应应用程序通信。
ara::per ：用于访问自适应应用程序文件并存储非易失性数据。
ara::log ：用于日志记录和跟踪。
Platform Dependencies and Principle Interactions of Diagnostic Manager
配置文件
RTA-VRTE Starter Kit 使用FlatCFG 文件定义诊断配置 ，并使用一个 .bin 文件指定与诊断提取信息无关的设置，如主要 TCP/DoIP 设置。
诊断管理器 dm_config.bin 配置文件必须与诊断管理器可执行文件一起部署到目标 ECU。这些文件在启动时由 rb-dm 进程加载，因此必须部署到可以读取的位置。
配置文件的位置通过执行管理使用**“-c”** 命令行选项传递给诊断管理器进程。
启动命令如下：
/opt/vrte/dia-diagnostic-manager/rb-dm -c dm_config.bin依赖服务和目录
执行管理启动诊断管理器（rb-dm）进程，确保它作为RTA-VRTE平台启动的一部分被正确加载。
DM 进程在运行时依赖于 arapipcd，如果没有 arapipcd，rb-dm 将无法启动。
在执行编辑器中，rb-dm 的执行名称和进程名称必须设置为 rb_dm，否则将无法配置 ara::per。
配置示例
配置文件 dm_config.bin 是由 flatc 编译器根据 dm_config.json 和 DmConfig.fbs 文件生成的，可以根据用户需求调整 DM 配置。
rb-dm 库的位置（LD_LIBRARY_PATH）必须进行配置，默认文件夹为 /opt/vrte/dia-diagnostic-manager/lib。
启动时，运行时诊断管理进程 rb-dm 从部署的数据文件 aradiagd__
LD_LIBRARY_PATH=/lib:/usr/lib:/opt/vrte/lib:/opt/vrte/dia-diagnostic-manager/lib
ECUCFG_ENV_VAR_ROOTFOLDER=/opt/vrte/dia-diagnostic-manager/etc/ecu-cfg/加载配置文件 ：
rb-dm进程从指定位置加载dm_config.bin配置文件和其他必要的FlatCFG数据文件。
应用程序使用诊断管理
诊断应用程序 通过分类为 ara::diag 诊断接口和 rb-diag 库的 PortPrototypes 与诊断管理进行交互。交互可以提供数据访问（用于外部测试工具和 DTC 存储）、报告检测到的故障监控、更新操作周期等功能。
ISOLAR-VRTE 应用设计编辑器包括 Harmony 应用设计语言（HADL）。
HADL 是一种为创建 ARXML 清单元素（包括自适应 SWCs（第 4.3.4.5 节）、端口原型和诊断接口（第 4.3.4.8 节））而优化的领域特定语言（DSL）。
应用程序与诊断管理接口的核心概念
处理类（Handler Classes）
实例指定符（InstanceSpecifiers）
一个自适应应用程序使用诊断管理 API 类作为基类定义诊断处理类。基类提供实用方法（例如，启动和停止处理程序）、由诊断管理调用的通知回调方法，以及定义派生类中所需方法实现签名的纯虚方法。
定义诊断处理类 ：
自适应应用使用诊断管理API类作为基类定义诊断处理类。
例如，以下代码片段使用诊断管理 API GenericDataIdentifier 类作为基类定义一个新的处理类：
#include <ara/diag/generic_data_identifier.h>
class MyDID : public ara::diag::GenericDataIdentifier {
public:
MyDID( ara::core::InstanceSpecifier is );
// 定义虚方法的实现
};GenericDataIdentifier 构造函数（以及派生类的构造函数）将 InstanceSpecifier 作为参数。InstanceSpecifier 是从自适应 SWC 的 PortPrototype 的 shortName 构造的，因为这些信息是应用设计人员已知的。创建的 InstanceSpecifier 在构造派生处理类时传递给诊断管理 API。
扩展上述示例，以下代码片段实例化处理程序，并传递使用端口 shortName 创建的 InstanceSpecifier：
MyDID did( InstanceSpecifier( "portname" ) );自适应应用程序创建由不同诊断接口分类的端口，以支持各种诊断功能，包括数据访问、监控、操作周期、数据传输和诊断例程控制。
例化处理类 ：
通过传递InstanceSpecifier实例化处理类，并关联到特定的端口原型。
数据访问
诊断管理通过在响应 UDS ReadDataByIdentifier (0x22) 和 WriteDataByIdentifier (0x2E) 请求时调用自适应应用程序中定义的处理程序来支持数据访问。
通过 GenericDataIdentifier 类的实例提供对数据标识符的访问。创建的对象在构造期间通过传递给构造函数的 InstanceSpecifier 关联到相关的端口原型。
端口原型必须由**ara::diag DiagnosticDataIdentifierGenericInterface** 接口分类。
GenericDataIdentifier 类包含 Read 和 Write 纯虚方法，必须实现以提供所需的数据访问。因此，应用程序创建一个从 GenericDataIdentifier 类派生的类，在派生类中提供 Read 和 Write 的实现：
class MyDID : public ara::diag::GenericDataIdentifier
{
// 实现 Read 和 Write 方法
};派生类的实例是数据标识符的处理程序，并在响应 ReadDataByIndentifier 或 WriteDataByIdentifier 请求时由诊断管理调用。
监控
诊断管理支持自适应应用程序报告诊断事件。以这种方式报告事件的应用程序是监控应用程序。监控应用程序识别特定故障（例如，故障传感器、短路等）并使用事件报告故障。诊断事件在系统范围内是唯一的，因此事件的监控只能由单个应用程序执行。
自适应应用程序通过由 DiagnosticMonitorInterface 分类且具有诊断映射到服务依赖项的端口原型访问用于监控的事件。
监控自适应应用程序通常独立于诊断管理，并负责向诊断管理报告事件状态。诊断管理还可以使用 initMonitor 回调（在构建 Monitor 类时建立）控制监控自适应应用程序，例如暂停监控。
// 定义回调（由诊断管理调用）
auto cbk = [&]( ara::diag::InitMonitorReason ima ) { ... }
// 定义端口原型（用于诊断事件）
ara::core::InstanceSpecifier specifier( "port" );
// 定义去抖动（基于计数器，由诊断管理管理）
ara::diag::Monitor::CounterBased debounceParams = {
.failedThreshold = 3,
.passedThreshold = -3,
.failedStepsize = 1U,
.passedStepsize = 1U,
.useJumpToFailed = true,
.useJumpToPassed = true
};
// 创建用于事件报告的监控实例
ara::diag::Monitor m( specifier, cbk, debounceParams );监控应用程序使用 ReportMonitorAction API 报告诊断事件。这需要一个 MonitorAction 参数，表示要报告的事件状态：
m.ReportMonitorAction( ara::diag::MonitorAction::kPassed );监控应用程序执行自己的事件去抖动时，会报告一个合格状态（kPassed 或 kFailed），因为只有在达到应用程序自己的去抖动阈值后才会报告事件。相反，使用诊断管理内部去抖动的监控应用程序报告一个不合格状态（kPrepassed 或 kPrefailed），因为这些报告可能只是一次性的故障，不会持续存在。当诊断管理去抖动阈值被超过时，不合格状态报告可以变为合格。
诊断管理支持两种去抖动形式：
基于时间 ：不合格报告启动一个诊断管理计时器，当计时器到期时结果变为合格。计时器到期前的后续矛盾不合格报告只会重置诊断管理计时器。
基于计数器 ：诊断管理计数不合格报告，当达到一定阈值数量的相同报告后变为合格。达到阈值前收到的后续矛盾不合格报告会重置计数器。
诊断管理去抖动通过引用诊断事件和所需去抖动算法属性的 DiagnosticEventToDebounceAlgorithmMapping 元素启用。如果事件没有这样的映射，则诊断管理不应用任何去抖动算法。当事件未定义去抖动算法时，监控应用程序传递不合格状态（即 kPrepassed 或 kPrefailed）是一个错误。
基于计数器的去抖动机制：
事件报告：
kPrefailed时计数器增加，kPrepassed时计数器减少。
事件状态：
*当计数器值等于失败阈值时，事件状态设为失败。
*当计数器值等于通过阈值时，事件状态设为通过。
可配置参数：
失败阈值 (
counterFailedThreshold)： 达到该值后，计数器不再增加，事件状态设为失败。
通过阈值 (
counterPassedThreshold)： 达到该值后，计数器不再减少，事件状态设为通过。
增加步长 (
counterIncrementStepSize)： 计数器增加的步长。
减少步长 (
counterDecrementStepSize)： 计数器减少的步长。
跳跃值 (
counterJumpUpValue,counterJumpDownValue)：
*如果在 **
kPrefailed**时计数器小于counterJumpUpValue，则立即设为counterJumpUpValue。
*如果在 **
kPrepassed**时计数器大于counterJumpDownValue，则立即设为counterJumpDownValue。
跳跃标志 (
counterJumpUp,counterJumpDown)： 用于启用或禁用跳跃行为。
操作周期：
定义： 根据ISO 14229-1:2013标准，操作周期定义了监控的开始和结束条件。一个ECU（电子控制单元）可以有多个操作周期，典型的周期包括点火开/关、上电/断电等。
通知： 自适应应用通过 SetNotifier API 通知诊断管理操作周期状态的变化。或者，可以配置为在初始化/终止时由诊断管理自动启动/结束操作周期。
事件报告： 诊断事件只有在操作周期开始时才能报告，如果操作周期不活跃，则报告会被忽略。
数据传输
UDS 服务中的 RequestUpload (0x35) 和 RequestDownload (0x34) 提供了诊断客户端和服务器之间的数据传输能力。
注意： UDS 数据传输服务是通过 GenericUDSService 诊断接口支持的。目前的实现不支持 DiagnosticUploadInterface 或 DiagnosticDownloadInterface，这些诊断接口在此处文档中详细记录以求完整。
工作机制：
诊断应用被视为数据源，因此 UploadService 启动从应用到诊断客户端的数据传输。
DownloadService 则相反，启动从诊断客户端到应用的数据传输。
交互过程： 如图所示
自适应应用与诊断库进行数据传输的交互。应用通过 UploadService 或 DownloadService 类的实例来访问数据传输。创建的对象是上传/下载的处理程序，并且在构造过程中必须通过传递给构造函数的 InstanceSpecifier 关联相关端口原型。端口原型必须由 ara::diag::DiagnosticUploadInterface 或 DiagnosticDownloadInterface 接口进行分类。
class UploadApp : public ara::diag::UploadService注意事项： UploadService 和 DownloadService 类不能直接实例化，因为它们包含纯虚方法，例如请求数据传输或传递传输的数据。子类必须实现这些方法后才能实例化。
例行控制 RoutineControl
UDS 服务 RoutineControl (0x31) 允许诊断客户端启动和停止服务器中的例行程序，并请求例行程序的结果。该服务通常用于相对复杂的控制序列，如启动自检功能、清除或擦除非易失性存储器、覆盖正常诊断服务器功能等。
关键点：
启动和停止例行程序： 通过例行控制接口中的 Start、Stop 和 RequestResults 方法。
例行标识符（RID）： 每个方法都需要一个预定义的例行标识符。
实现：
GenericRoutine 类包含纯虚方法，必须实现这些方法以提供所需的例行控制。类似于 GenericDataIdentifier 类的使用，应用程序使用 GenericRoutine 类作为基类创建派生类，并在派生类中实现纯虚方法。
class MyRoutine : public ara::diag::GenericRoutine在 ISOLAR-VRTE 中，HADL 文件中应实例化 DiagnosticRoutineInterface 并提供一个端口。要在 DEXT 编辑器中将端口映射到例行程序，需要执行 DiagnosticServiceGenericMapping。
服务验证
服务验证在处理 UDS 请求期间提供了两个回调：
在 UDS 处理的早期阶段，在诊断管理器检查请求服务标识符（SID）是否受支持之前进行制造商特定检查。如果检查失败，请求会立即被合适的负响应代码（NRC）拒绝。
在诊断管理器验证 SID 并检查安全访问之后，进行供应商特定检查。如果检查失败，请求会被合适的 NRC 拒绝。
与诊断管理的合作
ISOLAR-VRTE 提供了一个 DEXT 编辑器来配置诊断服务。DEXT 格式由 AUTOSAR 标准化，因此其他符合标准的 DEXT 编辑器也可以使用。
配置新诊断元素的步骤：
应用设计： 使用 ISOLAR-VRTE 应用设计编辑器和 Harmony 应用设计语言添加所需的软件组件、端口原型和诊断接口。
诊断配置： 使用 ISOLAR-VRTE DEXT 编辑器将所需元素添加到 DEXT 诊断配置中，并将其映射到 HADL 文件中定义的端口。
清单处理： 使用 ISOLAR-VRTE 清单处理将 AUTOSAR DEXT 配置转换为 RTA-VRTE 启动工具包 FlatCFG 数据配置，以便部署到目标 ECU。
应用处理程序： 实现诊断元素的自适应应用处理程序，例如通过子类化相关的 ara::diag API 类。
AP AUTOSAR 诊断管理的工作原理和具体流程：
1. 概述
诊断管理 是自适应平台基础中的一个功能集群，负责汽车电子/电气系统的监控，通过检测、警告和恢复功能支持诊断。
2. UDS 统一诊断服务
接收与处理 ：诊断管理从网络层接收 UDS 请求并处理请求。UDS 通信由客户端请求和诊断服务响应组成，例如，客户端向 ECU 请求启动 UDS 服务。
会话管理 ：UDS 服务定义了在 ECU 内访问信息、控制诊断功能及建立和控制诊断会话。典型会话包括：
默认会话
编程会话
扩展诊断会话
安全诊断会话
3. 功能与职责
监控系统状态 ：如“警告指示灯”。
故障记录与存储 ：检测到故障时存储故障发生时的记录及车辆状态数据以便故障排除。
诊断事件修复 ：跨操作周期跟踪报告的故障，允许从故障条件中恢复（如果可能）。
UDS 通信支持 ：支持诊断客户端和服务器之间的通信。
4. 诊断服务验证
初始验证 ：
检查请求的服务标识符（SID）是否合法。
检查安全访问控制参数（例如长度、服务标识符、子功能等）是否有效。
如果任何检查失败，请求会被拒绝。
后续验证 ：
进一步验证 SID 及安全访问。
供应商特定检查，如果失败，请求会被拒绝。
5. 诊断管理交互
诊断库 ：提供 C++ API 用于运行时访问诊断管理。 守护进程 ：实现诊断管理的活动方面。
6. 自适应应用与诊断库交互
数据传输服务 ：
UploadService：从应用到诊断客户端的数据传输。
DownloadService：从诊断客户端到应用的数据传输。
例行控制 ：
RoutineControl (0x31)：启动和停止服务器中的例行程序，并请求例行程序的结果。
7. 配置流程
应用设计 ：
使用 ISOLAR-VRTE 应用设计编辑器和 Harmony 应用设计语言添加所需的软件组件、端口原型和诊断接口。
诊断配置 ：
使用 ISOLAR-VRTE DEXT 编辑器将所需元素添加到 DEXT 诊断配置中，并将其映射到 HADL 文件中定义的端口。
清单处理 ：
使用 ISOLAR-VRTE 清单处理将 AUTOSAR DEXT 配
工作原理
诊断服务器（Diagnostic Server） ：每个软件包（Software Cluster）都有自己的诊断服务器，负责管理诊断资源和处理诊断请求。
诊断客户端（Diagnostic Client） ：诊断客户端通过诊断服务器与诊断服务器进行通信，发送诊断请求并接收响应。
诊断通信（Diagnostic Communication） ：诊断通信基于Unified Diagnostic Services（UDS）和Diagnostic over Internet Protocol（DoIP）协议，用于诊断客户端和服务器之间的数据传输。
具体流程
诊断请求发送 ：诊断客户端向诊断服务器发送诊断请求，请求包含诊断目标地址和请求类型2。
诊断请求处理 ：诊断服务器接收诊断请求，并根据请求类型和目标地址进行处理2。
诊断响应生成 ：诊断服务器生成诊断响应，并将响应发送回诊断客户端2。
诊断响应接收 ：诊断客户端接收诊断响应，并进行相应的处理2。