5.4.2 IOControl
本章描述了诊断服务InputOutput Control (0x2F) 的建模。 此服务的目的是为诊断仪提供覆盖与 AUTOSAR 硬件抽象交换数值的能力。
DiagnosticIOControl 属性的含义
属性 freezeCurrentState、resetToDefault 和 shortTermAdjustment 表示服务器的能力而不是具体的请求消息。
把控制返回给ECU的能力
根据 [TPS_DEXT_01015] 的声明，没有提供正式的方法来配置执行 returnControlToEcu 的能力。 这种缺少配置是有意为之，因为该功能始终可用且无论如何都无法撤销。
DiagnosticIOControl.dataIdentifier 的含义
DiagnosticIOControl.dataIdentifier 用于指定服务的有效负载。
但是，在某些情况下，dataIdentifier 对请求消息的负载建模（DiagnosticIOControl.shortTermAdjustment 设置为 true），在某些情况下，它表示响应消息的负载。
需要注意，引用的 dataIdentifier 本身可能会聚合多个 DiagnosticDataElement。
在运行时，只有一些 DiagnosticDataElements 可能与服务 InputOutput Control 的特定执行相关。 为此，诊断消息包含所谓的 ControlEnableMaskRecord（有关更多信息，请参阅 [SWS_DCM_00581]）。
定义 DiagnosticIOControl 的标识符
DiagnosticIOControl 的标识符由属性 定义。
这表示“I/O 控制”诊断服务的一个实例。
该元类包含“IO 控制”诊断服务的所有实例共享的属性。
InputOutput Control 没有定义任何子功能
诊断服务 InputOutput Control 没有定义任何子功能，因此不需要限制 DiagnosticIOControl.category 的值。
DiagnosticServiceSwMapping 与数据 ID 的一致性
对于每个引用一个 DiagnosticIoControlNeeds 和一个 DiagnosticIOControl 的 DiagnosticServiceSwMapping，DiagnosticIoControlNeeds.didNumber 的值应被忽略，而应采用 的值。
5.4.3 EcuReset
本章描述了诊断服务EcuReset（0x11）的建模。
这表示“ECU 复位”诊断服务的一个实例。
该元类包含“Ecu 复位”诊断服务的所有实例共享的属性。
请注意（如第 5.4 节所述）该服务的子功能是通过类别属性建模的。
DiagnosticEcuReset.category 的适用值
属性 DiagnosticEcuReset.category 的以下值由 AUTOSAR 标准化：
• HARD_RESET
• KEY_OFF_ON_RESET
• SOFT_RESET
• ENABLE_RAPID_POWER_SHUT_DOWN
• DISABLE_RAPID_POWER_SHUT_DOWN
这些值的含义在适用的 ISO 文件 [15] 中有所描述。
类别值与 ISO 14229-1 中提到的数值的对应关系
ISO 14229-1 [15] 标准文档定义了诊断服务 EcuReset 子功能的特定数值。
根据 [TPS_DEXT_01056] 的数值与类别的预定义值的对应关系非常明显，因为 [TPS_DEXT_01056] 中定义的值的定义直接受到 ISO 14229-1 [15] 标准文档的启发。
服务 EcuReset 子功能的制造商特定值
ISO 14229-1 [15] 标准文档，除了子功能的标准化数值之外，还保留了子功能标识符的数字范围供制造商或供应商特定使用。
在这种情况下，可以为类别定义更多值，前提是使用自定义前缀以避免与 AUTOSAR 标准的进一步扩展（即 [TPS_DEXT_01056]）发生潜在的名称冲突。
DiagnosticEcuReset.customSubFunctionNumber 的语义
已引入属性 DiagnosticEcuReset.customSubFunctionNumber 以允许指定制造商或供应商特定值以表示诊断通信中的自定义子功能。
由属性 DiagnosticEcuReset.category 和 DiagnosticEcuReset.customSubFunctionNumber 的值创建的元组完全指定了制造商或供应商特定子功能的标识。
存在 DiagnosticEcuReset.customSubFunctionNumber
属性 DiagnosticEcuReset.customSubFunctionNumber 仅在 DiagnosticEcuReset.category 的值超出 [TPS_DEXT_01056] 定义的标准化值集时才存在。
DiagnosticEcuReset.customSubfunctionNumber 的值范围
DiagnosticEcuReset.customSubfunctionNumber 的允许值应始终在闭区间 0x40 .. 0x7E 内。
5.4.4 清除诊断信息
本章描述了诊断服务ClearDiagnosticInformation（0x14）的建模。 顾名思义，该服务的目的是清除 AUTOSAR 诊断堆栈中的诊断信息。
请注意，除了是否存在之外，没有什么可以为 DiagnosticClearDiagnosticInformation 配置。
这表示“清除诊断信息”诊断服务的一个实例。
此元类包含“清除诊断信息”诊断服务的所有实例共享的属性。
ClearDiagnosticInformation 没有定义任何子功能
诊断服务 ClearDiagnosticInformation 没有定义任何子功能，因此不需要限制 DiagnosticClearDiagnosticInformation.category 的值。
5.4.5 MemoryByAddress
本章描述了内存访问（0x23、0x3D、0x34-0x37）诊断服务的建模。 这些服务的目的是根据测试人员的请求访问诊断堆栈上的内存。
小结备注：原文中的03D应该是写错了。
出于诊断目的访问内存的服务描述由抽象元类 DiagnosticMemoryByAddress 建模。它应该提供与内存访问相关的所有模型属性。
内存访问的描述在某种程度上需要考虑内存段的正式描述。 为此，在角色 memoryRange 中的 DiagnosticMemoryByAddress 处引入并聚合了元类 DiagnosticMemoryIdentifier。
这种建模的目的不是提供通用的内存模型，而是允许就诊断而言对内存属性进行规范。
DiagnosticMemoryByAddress 处的 DiagnosticMemoryIdentifier 聚合可能与 OEM 相关，也可能不相关。 但是，肯定有一个用例可以将此信息添加到从一级供应商返回给 OEM 的 DiagnosticExtract，作为诊断配置的文档。
小结与疑问：到了这里，居然依然是03D！
由于 DiagnosticMemoryByAddress 表示所有类型的诊断内存访问的通用基类，因此还需要对特定子类进行建模，以解决诊断内存访问的特定用例。
这些子类在概念上与 DiagnosticServiceInstance 的其他子类处于同一级别。
换句话说，内存访问的情况偏离了其他诊断服务的建模，因此涉及一个进一步的抽象基类。
DiagnosticMemoryIdentifier.memoryLowAddress 和 DiagnosticMemoryIdentifier.memoryHighAddress 的存在
如果在角色 memoryRange 中引用的 DiagnosticMemoryIdentifier 被 DiagnosticRequestDownload 或 DiagnosticRequestUpload 引用，则属性 DiagnosticMemoryIdentifier.memoryLowAddress 和 DiagnosticMemoryIdentifier.memoryHighAddress 不应存在。
这表示处理按地址访问内存的诊断服务的抽象基类。
这个主要是抽象掉基类。
这个元类代表了从诊断的角度定义内存属性的能力。
这表示“按地址写入内存”诊断服务的一个实例。
此元类包含“按地址写入内存”诊断服务的所有实例共享的属性。
小结：这里，终于第一次看到把这个服务ID写对了。
这次的梳理暂且到此，主要看了IO控制、ECU复位、清除诊断信息以及部分根据存储进行诊断的功能。最后一部分的内容比较多，暂且没有看完，后面会继续梳理。
