1、概述
DCM：Diagnostic Communication Manager 诊断通信管理。Dcm模块负责诊断数据流的保障和诊断状态的管理，特别是诊断会话和安全状态的管理。此外，Dcm模块根据诊断状态检查是否支持诊断服务请求，以及是否可以在当前会话中执行该服务。
Dcm模块为诊断服务提供通用API。Dcm模块的功能在开发、制造或服务期间由外部诊断工具使用。 
DCM在AUTOSAR里面位于服务层
2、DCM功能
2.1、功能划分
DCM功能主要分为三个部分
1. Diagnostic Session Layer (DSL)
确保有关诊断请求和响应的数据流， 监督和保证诊断协议定时并管理诊断状态（特别是诊断会话和安全） 。
2. Diagnostic Service Dispatcher (DSD)
通过网络接收新的诊断请求并将其转发到数据处理模块。
通过网络传输诊断响应。Dispatcher：调度
3. Diagnostic Service Processing (DSP)
处理实际的诊断服务。Processing：流程
下图给出了子模块之间的接口概述:
注意:这些子模块的实现和它们之间的接口不是强制性的。引入它们只是为了提高规范的可读性。
DCM在整个AUTOSAR架构里面执行数据流的顺序如下
根据上图可以看出，当ECU接收到诊断报文时，经过CANTp模块进行网络层解析（15765-2），在根据报文的归属判断，由PDUR模块转发置DCM模块。当DCM收到诊断报文时，DCM模块就开始运行了。
2.1.1、DSL功能：诊断服务层
Diagnostic Service Layer：确定诊断数据请求和响应的数据流；监控和确保诊断请求和响应的时序，管理诊断状态（特别是诊断会话和安全状态）
2.1.1.1、请求处理
• PduR来的数据传递到DSP主要通过调用接收和Copy数据的函数实现
• 与Tester保持Alive。和 ISO14229-1的”keep alive logic” 涵义一样，ECU接收到对应的报文（SID： 0x3E Sub： 0x80），ECU对该报文不会发到DSP。
当收到诊断请求时，PDUR调用Dcm_StartOfReception()和Dcm_CopyRxData()函数将收到的诊断请求数据放置在DCM模块的Buffer中，然后PDUR调用Dcm_TpTxConfirmation()函数通知Dcm模块接收到了新的诊断请求。
PDUR会将数据诊断请求数据从下层的Buffer中Copy到诊断的接收Buffer中，DSD会从此Buffer中取出数据进行处理。
2.1.1.2、响应处理
• 将响应从 DSP 子模块转发到 PduR 模块，接收DSP的数据，调用发送触发PduR的数据发送；
• 保证对测试人员的响应时间
支持周期性传输
对应的服务ReadDataByPeriodicIdentifier (0x2A)，UDS提供的“ReadDataByPeriodicIdentifier (0x2A)”服务，用于向由一个或多个periodicDataIdentifiers标识的ECU请求定期传输数据记录值。
支持ResponseOnEvent (ROE) 传输
对应的UDS服务ResponseOnEvent (0x86), 通过UDS Service ResponseOnEvent (0x86)，测试人员可以请求ECU启动或停止传输由指定事件发起的响应。当注册一个事件进行传输时，测试者也指定相应的服务来响应(例如:UDS service ReadDataByIdentifier 0x22)。
支持分段响应
在某些情况下，例如在例程执行的情况下，应用程序需要立即请求一个NRC 0x78(响应等待)，该请求应立即发送，而不是仅仅在到达响应时间之前(P2ServerMax分别为P2*ServerMax)。
当Dcm模块调用一个操作并得到一个错误状态DCM_E_FORCE_RCRRP时，DSL子模块将触发NRC 0x78(响应等待)的负响应传输。这个响应需要从一个单独的缓冲区发送，以避免覆盖正在进行的请求处理。
• 支持由应用程序触发的 ResponsePending 响应
当需要响应诊断请求时，DSL模块通过调用PduR_DcmTransimit()和Dcm_CopyTxData()将数据传递至PDUR模块，其中PduR_DcmTransimit()函数只是传递长度信息、地址信息，数据是通过Dcm_CopyTxData()函数传递至PDUR模块，当数据传输成功后，PDUR模块通过Dcm_TpTxConfirmation()函数告知DCM数据接收成功。
PDUR会将数据诊断请求数据从上层的Buffer中Copy到诊断的接收Buffer中，DSD会从此Buffer中取出数据进行处理。
2.1.1.3、安全级别处理
• 管理安全级别
• 处理Key和Seed
DSL提供Dcm_GetSecurityLevel()、DslInternal_SetSecurityLevel()两个函数分别用于获取当前的安全等级和设置安全等级。
对于配置层面而言，DSL菜单主要是配置诊断帧，包括物理寻址和功能寻址，单次通信的最大Buffer，以及时间参数，包括回复0x78的时间和为了防止诊断服务异常，允许0x78的最大次数等。
2.1.1.4、会话状态处理
• 管理会话状态处理当前激活的Session以及设置新的Sesstion
• 管理权限状态分为权限模式和默认的模式
• 跟踪活动的非默认会话
• 允许修改时间。
会话：session，一般有三种，缺省会话（0x00, Default session）、编程会话（0x01, Programming session）、扩展会话（0x02Extended session）。每种会话下可以进行的诊断服务不同，根据实际需求由OEM自己定义。一般来说诊断（UDS）刷写功能需要在编程会话下进行，涉及到NVM关键存储数据的写功能需要在扩展会话下进行。根据实际需求可以自己定义会话，比如定义0x60（EOL session）专门用于EOL工厂下线处理。
2.1.1.5、诊断协议处理
·处理不同的诊断协议
·处理设置诊断协议服务Table， 根据UDS或者OBD链接到不同的诊断协议
·设置不同服务协议的优先级
·支持优先级抢占机制
·并行处理OBD和UDS协议， 可以忽略优先级和抢占机制
管理资源
给服务分配对应的Buffer，
1）在Dcm模块中只允许使用和分配一个诊断缓冲区，这个缓冲区随后用于处理诊断请求和响应
2）NRC 0x78 (Response pending)响应的输出是通过一个单独的缓冲区完成的
3）支持分页缓冲处理
2.1.1.6、通信模式处理
DCM模块和ComM模块的交互由DSL子模块完成。ComM模块把每个通信通道（channel）的当前通信状态（No-com, Full-com, Silent-com）通知给Dcm模块。Dcm模块的诊断功能将会调用ComM模块的接口功能可能会阻止Ecu进入shutdown模式（ActiveDiagnostic ==’DCM_COMM_ACTIVE’时ECU必须保持唤醒状态，也就是不允许 进入shutdown/sleep）。
应用程序可以调用Xxx_SetActiveDiagnostic()接口通知Dcm模块ActiveDiagnostic的当前状态
• 处理通信要求（Full/Silent/No）
ComM会通知DCM当前的通道， DCM会进行模式的请求， 避免通信进入Sleep；在Silent和NO下， DCM禁止通信
No Communication：
ComM模块调用 Dcm_ComM_NoComModeEntered接口通知Dcm模块通信关闭。Dcm模块收到通知后就会Disable所有的诊断接收/传输。
Silent Communication:
ComM模块调用 Dcm_ComM_SilentComModeEntered接口通知Dcm模块通信静默。Dcm模块收到通知后就会Disable所有的诊断传输。
Full Communication:
ComM模块调用 Dcm_ComM_FullComModeEntered接口通知Dcm模块通信静默。Dcm模块收到通知后就会Enable所有的诊断接收/传输。
• 指示活动/非活动诊断
• 启用/禁用所有类型的诊断传输
在DSL里面可以配置多路诊断通道，假设诊断ID有2个以上，通过DcmDslProtocolRows容器实现。
2.1.1.7、使用小记
0x78让上位机等待
上位机发送诊断请求后会要求ECU在一个最大响应时间（一般是50ms）内发出响应报文，但是对于一些请求的处理，ECU内部会耗时比较长（比如0x2E写NVM的请求），来不及在规定时间发出响应。这个时候ECU可以发送0x78（Pending）的否定响应吗来通知上位机ECU内部繁忙（Busy），需要上位机等待（Pending，一版Pending时间可以设置为1秒）。上位机收到0x78（Pending）的否定响应码后就会等待，直到ECU发出积极响应或者Pending时间超时。这个发送Bussy响应来保证诊断时序的功能由DSL模块实现。
2.1.2、DSD功能：诊断调度服务
Diagnostic Service Dispatcher：接收到的诊断请求转发给数据处理器；当数据处理器触发时，通过PDUR传输诊断响应。
主要功能
• DCM模块负责检查诊断请求的有效性（诊断会话、安全访问级别、应用程序权限的验证），并跟踪服务请求执行的进度。
• 保证服务请求的执行
• 主要使用：
接收请求消息并发送肯定响应消息
接收请求消息并抑制肯定响应
接收请求消息并抑制否定响应
接收请求消息并发送否定响应消息
发送没有相应请求的肯定响应消息
分段响应
主要功能 -检查诊断服务标识和适配诊断消息
• DSD接收来自DSL的数据， 根据具体的配置参数决定接收到的信号是否在DCM中进行处理
• 基于ID进行识别
• 可以选择诊断的ID Table
• 对于不支持的ID进行Negative 响应
当DSL接收到新的诊断请求，DSL通过内部接口通知DSD，如下图所示。DSD调用Dcm_GetSesCtrlType()、Dcm_GetSecurityLevel()获取当前的Session和安全等级，DSD模块会在当前Session的“Service Identifier Table”检查诊断请求SID是否在其中，如果不在table中，DSD会发送NRC 0x7F，如果诊断服务支持，但当前Session不支持该子服务，DSD会发送NRC 0x7E；然后检查当前安全等级是否满足条件，如果当前安全等级不支持该诊断请求，DSD会发送NRC 0x33。最后检查数据的长度。
当DSP模块完成诊断请求处理后，DSD负责将整理响应数据。并发送至DSL。
DSD模块将服务标识符(SID)(如果是负反馈，则为0x7F)和响应的数据流添加至“Dcm_MsgContextType”。然后DSD将其传送至缓冲区，并在缓冲区的第一个字节添加SID。
对于配置而言，DSD主要是配置所需要实现的服务，以及服务所支持的session以及服执行的安全等级。
主要功能 –验证
• 服务权限（0x29服务可以改变权限）
• 诊断的Session（0x10服务实现不同的Session）
• Security Access Level（0x27）
• 服务的关联和依赖
主要功能 –Check服务格式以及子功能
• 在请求开始前进行
• 工厂测试APP执行环境以许可
• 供应商APP执行环境以及许可
主要功能 –响应
• Positive的响应
• Negative的响应
• 抑制响应
0x11 (Service not supported), 0x12
(SubFunction not supported), 0x31
(Request out of range),
0x7E (Subfunction not supported in active session),
0x7F (Service not supported in active session)
2.1.3、DSP功能：诊断服务处理
Diagnostic Service Processing：处理实际的诊断请求。
当接收到来自DSD子模块的函数调用要求DSP子模块处理诊断服务请求时， DSP始终执行以下基
本处理步骤：
• 分析收到的请求消息
• 检查格式以及是否支持寻址的子功能
• 在 DEM、 SW-C 或其他 BSW 模块上获取数据或执行所需的函数调用
• 服务响应
诊断文件到APP
两个诊断服务
功能交互
DID配置
单独的 DID 配置
每个 DID 的配置数据元素需要一个连接（通过端口或C功能）来访问数据（读取、写入和控制）在这种情况下,每个 DID 都应该使用 DataServices接口。
DID 范围配置
采用一个单独的Port连接在APP中处理一组共享相同行为的 DID。 在这种情况下应该使用接口应该包含DID的范围信息。 使用此配置允许接口优化。 DcmDspDidRangeIdentifierLowerLimit 和
DcmDspDidRangeIdentifierUpperLimit配置选型决定DID的范围
DCM通信数据流
2.2、DCM主要关联模块
RTE： 接收诊断相关的数据处理诊断相关的通信服务，Dcm模块在完成诊断功能的时候需要通过RTE接口来读写/函数调用其他SWC的数据/服务。
如果Dcm模块无法直接处理诊断数据请求时，Dcm会把通过以下方式来转发请求并获得结果数据：
·通过SW-C的port-interface。
·通过直接调用BSW模块函数。
BswM：接收DCM的状态变化进行模式模式管理，如果Dcm的初始化是从引导加载程序跳转的结果，则Dcm通知BswM应用程序已被更新（UDS的0x11服务）。Dcm还向BswM表示通信模式的改变（UDS的0x28服务）。
SchM： 提供调度
PduR： 提供收发诊断数据的路由
ComM：处理诊断相关的通信请求，ComM模块提供了一些功能，如Dcm模块可以指示“活动”和“非活动”状态，以便进行诊断通信。Dcm模块提供了处理“Full-/ Silent-/ No-Communication”通信需求的功能。此外，如果ComM模块要求，Dcm模块提供启用和禁用诊断通信的功能。（UDS的0x28服务）
NvM： 存储诊断数据
DEM： 处理诊断事件，DEM模块提供检索与故障内存相关的所有信息的功能，以便Dcm模块能够通过从故障内存中读取数据来响应测试者的请求。通俗的讲就是Dcm能够读取Dem记录的DTC信息
EcuM： 诊断相关的唤醒以及模式切换
PDUR：PduR模块提供诊断数据的发送和接收功能。PduR模块接收和发送诊断数据。PduR为Dcm模块提供一个与具体通信协议无关的接口。
诊断服务在ISO七层架构里面如下图：
从网络分层角度看，DCM模块属于上层模块，主要为应用层提供服务。主要包括5-7层，包括会话层服务及应用层等，会话层包括服务定时及服务分配等，应用层为具体的服务功能实现。
