Adaptive AUTOSAR-诊断管理-Diagnostic Server概述和诊断通信

Diagnostic Server

对于AUTOSAR adaptive平台，不用重新刷写整个ECU即可添加新的软件包，各个软件包描述为SoftwareClusters，每个SoftwareClusters拥有自己的诊断地址和Server。

所用的Diagnostic Server共享同一个传输层，每个Server管理自己的资源。

• DM根据每个SoftwareClusters所配置的DEXT来实例化独立的Server，配置元素不赘述

诊断通信管理

用于诊断通信的关键元素是Diagnostic Conversation(诊断对话)，UDS请求就是在诊断对话中处理，一个Server可以并行处理多个诊断对话，和Classic AUTOSAR不同，AP提供完全并行或虚假并行的能力(CP有并行能力吗？虚假的并行能力)

Diagnostic Conversations

诊断对话描述的是诊断Server和诊断Client之间的对话，Server和Client之间的连接，CP完全静态配置，AP是Server运行时创建的。

• Server通过TP层回调时提供的id和SA来识别Client
• 每个诊断对话都有自己的Session和Security-Level(假如一个Server拥有多个诊断对话，可以并行处理不同Session和安全等级的请求)

并行处理

AP为了支持并行处理，有如下措施：

1. 支持并行处理的诊断对话的数量是可配置的
2. 并行模式是可选的:
   1. 虚假并行：当所有的诊断对话都是默认会话时，是一个真的并行。当有一个诊断对话进行非默认会话时，除了新建立一个优先级较高的诊断对话时，其他诊断对话都会被拒绝。虚假的关键就是，Session这个属性并不是私有的，而是所有诊断对话共享
   2. 完全并行：类似于传统IT界的CS模型，Client之间是互不影响的，由于Server需要大量的资源，所以传统ECU(CP)和ISO14229都未提供这种实现，但AP一般不再有资源上的限制，可以实现这种模式。在完全并行模式下，同一时刻可以有N个诊断对话，都可以进入非默认会话。

NOTE:并不是所有的UDS请求都是互不影响的，有一些请求是全局的。

诊断对话的生命周期

诊断对话的生命周期从接收到第一个uds请求开始，到取消诊断会话，或满足以下条件(&&关系)：

1. UDS请求处理完成（完成有很多条件，一般就是处理完成，发送响应或抑制响应）
2. UDS在默认会话

不在默认会话的诊断对话会进行保活(keep-alive)，直到Session超时

诊断对话服务接口(Service Interface)

略，9章有详细描述

把一个UDS请求分配给诊断对话

当收到一个UDS请求，有三种选择，都有标准流程进行处理：

1. 把这个请求分配给已经存在的诊断对话
2. 新建一个诊断对话，并分配给它
3. 拒绝这个请求

处理流程，文档中图7.2

优先级化

当诊断Server资源不足以开启新的诊断对话时，需要对新的诊断对话和已经存在的进行优先级对比，虚假并行下，有时(即切换非默认会话等)也需要进行这项工作。

• IndicateMessage会附带一个优先级信息，这就是诊断对话的优先级
• 0代表最高优先级，255最低(uint8_t)
• 虚假模式下的优先级化：会和非默认会话的优先级进行比较，优先级高的会替换优先级低的，将uds request分配给它
• 所有诊断对话的优先级顺序：

1. 优先级高的会替换优先级低的
2. 同样优先级的，非默认会话的隐形优先级高于默认会话

优先级类型

诊断对话的替换和初始值

• 发生诊断对话的替换时，取消旧的对话，建立新的对话
• 初始值：

1. Session:Default Session
2. Security Level:Locked

UDS请求的拒绝

• 当UDS请求分配给一个还没处理完上一个请求的诊断对话，这次请求会被忽略
• 如果优先级化要求拒绝UDS请求，并且 DiagnosticCommonProps.responseOn-SecondDeclinedRequest配置为TRUE，Server会接受这个请求，但不做更多处理，返回NRC 0x21
• 如果优先级化要求拒绝UDS请求，并且DiagnosticCommonProps.responseOn-SecondDeclinedRequest配置为FALSE，Server会忽略这个请求

UDS请求验证

Diagnostic Server会校验请求的以下方面：

• 是否检测到制造商指定的错误？
• 支持SDI吗？
• 当前会话支持SID吗？
• 安全校验支持当前SID吗？
• 是否检测到供应商指定的错误？

具体每个校验细节略过，文档有详细描述，对于使用者根据NRC可以很轻易推出报错原因。

UDS响应处理

正常的正/负响应

• 外部服务处理者不引发ApApplicationError，Server返回正响应
• 外部服务处理者引发 UDSNegativeResponseCodeRegular中的ApApplicationError，Server返回负响应，错误代码就是ApApplicationError的数值

响应的抑制

• 抑制正响应指示位会抑制正响应
• 功能寻址时，部分负响应会被抑制：

发送busy响应

如同CP一样，AP也可以返回NRC 0x78来表示pending，并且发送NRC 0x78的数量也可以配置，达到这个数量，还不能正常处理请求，返回NRC 0x10

非默认会话的跟踪

• DM支持S3Server 超时，时间固定5s

UDS的服务处理

诊断Server提供DiagnosticServiceClass引申出诊断服务的处理器(diagnostic service processors)

• 支持的服务

内部服务：DM内部自己就能处理这个服务

外部服务：需要外部提供接口进行处理

内部&外部：部分内部可以处理，部分外部提供接口

• AP中的UDS服务的地址和长度信息都被拓展到uint64类型，不管真实的地址总线宽度(与CP不同)

每个服务详情略过...大多数全部是UDS的范畴，很多AP的实现细节和CP不同