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为了支持并行处理，有如下措施：
- 支持并行处理的诊断对话的数量是可配置的
- 并行模式是可选的:
- 虚假并行：当所有的诊断对话都是默认会话时，是一个真的并行。当有一个诊断对话进行非默认会话时，除了新建立一个优先级较高的诊断对话时，其他诊断对话都会被拒绝。虚假的关键就是，Session这个属性并不是私有的，而是所有诊断对话共享
- 完全并行：类似于传统IT界的CS模型，Client之间是互不影响的，由于Server需要大量的资源，所以传统ECU(CP)和ISO14229都未提供这种实现，但AP一般不再有资源上的限制，可以实现这种模式。在完全并行模式下，同一时刻可以有N个诊断对话，都可以进入非默认会话。
NOTE:并不是所有的UDS请求都是互不影响的，有一些请求是全局的。
诊断对话的生命周期
诊断对话的生命周期从接收到第一个uds请求开始，到取消诊断会话，或满足以下条件(&&关系)：
- UDS请求处理完成（完成有很多条件，一般就是处理完成，发送响应或抑制响应）
- UDS在默认会话
不在默认会话的诊断对话会进行保活(keep-alive)，直到Session超时
诊断对话服务接口(Service Interface)
略，9章有详细描述
把一个UDS请求分配给诊断对话
当收到一个UDS请求，有三种选择，都有标准流程进行处理：
- 把这个请求分配给已经存在的诊断对话
- 新建一个诊断对话，并分配给它
- 拒绝这个请求
处理流程，文档中图7.2
优先级化
当诊断Server资源不足以开启新的诊断对话时，需要对新的诊断对话和已经存在的进行优先级对比，虚假并行下，有时(即切换非默认会话等)也需要进行这项工作。
- IndicateMessage会附带一个优先级信息，这就是诊断对话的优先级
- 0代表最高优先级，255最低(uint8_t)
- 虚假模式下的优先级化：会和非默认会话的优先级进行比较，优先级高的会替换优先级低的，将uds request分配给它
- 所有诊断对话的优先级顺序：
- 优先级高的会替换优先级低的
- 同样优先级的，非默认会话的隐形优先级高于默认会话
优先级类型
诊断对话的替换和初始值
- 发生诊断对话的替换时，取消旧的对话，建立新的对话
- 初始值：
- Session:Default Session
- 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
非默认会话的跟踪
UDS的服务处理
诊断Server提供DiagnosticServiceClass引申出诊断服务的处理器(diagnostic service processors)
内部服务：DM内部自己就能处理这个服务
外部服务：需要外部提供接口进行处理
内部&外部：部分内部可以处理，部分外部提供接口
- AP中的UDS服务的地址和长度信息都被拓展到uint64类型，不管真实的地址总线宽度(与CP不同)
每个服务详情略过...大多数全部是UDS的范畴，很多AP的实现细节和CP不同
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
