继续学习AUTOSAR，看一下官方的文档。
WriteMemoryByAddress 没有定义任何子功能
诊断服务 WriteMemoryByAddress 没有定义任何子功能，因此不需要限制 DiagnosticWriteMemoryByAddress.category 的值。
上面的表格，表达的是一个实例。
此元类包含“按地址读取内存”诊断服务的所有实例共享的属性。
相关的建模流程
ReadMemoryByAddress 没有定义任何子功能
诊断服务 ReadMemoryByAddress 没有定义任何子功能，因此不需要限制 DiagnosticReadMemoryByAddress.category 的值。
这表示“Transfer Exit”诊断服务的一个实例。
小结：跨度有点大，怎么突然间蹦到了另一个服务了？
该元类包含“Transfer Exit”诊断服务的所有实例共享的属性。
TransferExit 没有定义任何子功能
诊断服务 TransferExit 没有定义任何子功能，因此不需要限制 DiagnosticTransferExit.category 的值。
这表示“数据传输”诊断服务的一个实例。
该元类包含“数据传输”诊断服务的所有实例共享的属性。
图 5.11：诊断服务 DataTransfer (0x36) 的建模
DataTransfer 没有定义任何子功能
诊断服务DataTransfer 没有定义任何子功能，因此不需要限制DiagnosticDataTransfer.category 的值。
表格表示“请求下载”诊断服务的一个实例。
这个元类包含“请求下载”诊断服务的所有实例共享的属性。
图 5.12：诊断服务 RequestDownload (0x34) 的建模
RequestDownload 没有定义任何子功能
诊断服务RequestDownload 没有定义任何子功能，因此不需要限制DiagnosticRequestDownload.category 的值。
这表示“请求上传”诊断服务的一个实例。
该元类包含“请求上传”诊断服务的所有实例共享的属性。
图 5.13：诊断服务 RequestDownload (0x35) 的建模
RequestUpload 没有定义任何子功能
诊断服务RequestUpload没有定义任何子功能，因此不需要对DiagnosticRequestUpload.category的值进行约束。
5.4.6 通信控制
本章描述了诊断服务CommunicationControl（0x28）的建模。 此诊断服务的目的是启用或禁用 ISignalIPduGroups。
但是，启用或禁用的实际实现显然不是直接在诊断堆栈内执行的。 它需要与 BswM 进行一些交互，BswM 反过来实现启用算法。
因此，为此建模的元类不需要引用 ISignalIPduGroups 而是实现对 BswM 的模式请求。
图 5.14：诊断服务 CommunicationControl (0x28) 的建模
DiagnosticComControl.category 的允许值
诊断服务 CommunicationControl 的子功能通过属性 DiagnosticComControl.category 标识。 DiagnosticComControl.category 的标准化值是：
• ENABLE_RX_AND_TX
• DISABLE_RX_AND_TX
• ENABLE_RX_AND_DISABLE_TX
• DISABLE_RX_AND_ENABLE_TX
• ENABLE_RX_AND_DISABLE_TX_WITH_ENHANCED_ADDRESS_INFORMATION
• ENABLE_RX_AND_TX_WITH
文档中描述的这些值的含义是[ISOESS_INTHADDRESS_INFORMATION 的含义]。
类别值与 ISO 14229-1 中提到的数值的对应关系
ISO 14229-1 [15] 标准文档定义了诊断服务 CommunicationControl 子功能的特定数值。
根据 [TPS_DEXT_01057] 的数值与类别的预定义值的对应关系非常明显，因为 [TPS_DEXT_01057] 中定义的值的定义直接受到 ISO 14229-1 [15] 标准文档的启发。
服务通信控制子功能的制造商特定值
ISO 14229-1 [15] 标准文档，除了子功能的标准化数值之外，还保留了子功能标识符的数字范围供制造商特定使用。
在这种情况下，可以为类别定义更多值，前提是使用自定义前缀以避免与 AUTOSAR 标准的进一步扩展（即 [TPS_DEXT_01057]）发生潜在的名称冲突。
DiagnosticComControl.customSubFunctionNumber 的语义
已引入属性 DiagnosticComControl.customSubFunctionNumber 以允许指定制造商或供应商特定值以表示诊断通信中的自定义子功能。
由属性 DiagnosticComControl.category 和 DiagnosticComControl.customSubFunctionNumber 的值创建的元组完全指定了制造商或供应商特定子功能的标识。
存在 DiagnosticComControl.customSubFunctionNumber
属性 DiagnosticComControl.customSubFunctionNumber 仅在 DiagnosticComControl.category 的值超出 [TPS_DEXT_01057] 定义的标准化值集时才存在。
DiagnosticComControl.customSubFunctionNumber 的可能值
鉴于 [constr_1334] 的实现，给定的 DiagnosticComControl.customSubFunctionNumber 的值应始终在闭区间 0x40 .. 0x5F（对于制造商特定子功能）或闭区间 0x60 .. 0x7E（对于供应商特定子函数）内 -职能）。
DiagnosticComControlClass 对 CommunicationClusters 状态管理的影响
DiagnosticComControlClass 对 CommunicationClusters 状态管理的影响可能有两种替代结果：
• 所有 CommunicationClusters 都会受到影响。 为此，属性 allChannels 能够识别适用的 CommunicationClusters。
当预期的语义实际上是定义对所有通信集群的影响时，要求引用所有适用的通信集群似乎有悖常理。
但是，可能存在不参与诊断工作流的私有 CommunicationClusters：这些需要保持在范围之外，因此明确标识适用的 CommunicationClusters 是有意义的。
• 选定数量的通信集群受到影响。 这在概念上与其他用例不同，因为它需要一个附加属性来保留通常由 OEM 角色分配的子网编号。
DiagnosticComControlSpecificChannel.subnetNumber 的适用值范围
属性 DiagnosticComControlSpecificChannel.subnetNumber 的值应在闭区间 1 .. 14 内。
请注意，[constr_1336] 隐含的规定并不是随意引入的，而是从 ISO 14229-1 [15] 标准文档中获得其概念背景。
显然，名为 CommunicationControl 的诊断服务将对封闭 ECU 的模式管理产生影响。 然而，这种影响不是由任何进一步的属性或引用定义的，DiagnosticComControl 就是影响。
通过定义一个 DiagnosticComControl 并将类别设置为适用的值之一（例如 ENABLE_RX_AND_TX），可以充分表达预期的语义。
属性 DiagnosticComControlSubNodeChannel.subNodeNumber 的允许值范围
属性 DiagnosticComControlSubNodeChannel.subNodeNumber 的值不得超过闭区间 0 .. 65535。
属性 DiagnosticComControl.specificChannel 和 DiagnosticComControl.subNodeChannel 之间的区别
属性DiagnosticComControl.specificChannel 和DiagnosticComControl.subNodeChannel 之间的语义差异在于DiagnosticComControl.specificChannel 实际上指的是CommunicationCluster，而DiagnosticComControl.subNodeChannel 基本上指的是具有给定标识号的节点所连接到的CommunicationCluster。
这表示“通信控制”诊断服务的一个实例。
这表示能够向受诊断服务“通信控制”约束的特定通道的定义添加更多属性。
该元类包含由“通信控制”诊断服务的所有实例共享的属性。
这表示能够向受诊断服务“通信控制”约束的特定子节点通道的定义添加更多属性。
上面看完了根据地址访问存储的剩余部分，之后又看了通信控制部分。前者的行为比较单一，后者其实是存在很多自定义的情况的，因此，如果是看别人的软件实现的时候应该也会看到一些没有实际的标准可参考的情况。
