835_AUTOSAR_TPS_DiagnosticExtractTemplate13_AUTOSAR支持的诊断服务5

       全部学习汇总： GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!

       继续学习AUTOSAR，看一下官方的文档。

       5.4.12 RoutineControl

       本章描述了诊断服务 RoutineControl（0x31）的建模。

       此诊断服务的目的是应诊断仪的请求在诊断堆栈上执行一段代码，即诊断程序。

       诊断程序最多包含三个可能的组件：

       • 启动程序

       • 停止程序

       • 请求程序结果

       此架构的影响没有元模型由 [TPS_DEXT_01077] 描述：

       诊断程序的建模

       从元建模的角度来看，DiagnosticRoutine 的语义是通过聚合三个进一步的元类来创建的：

       • DiagnosticStartRoutine

       • DiagnosticStopRoutine

       • DiagnosticRequestRoutineResults

       Id的语义

       属性DiagnosticRoutine.id 表示所谓的DiagnosticRoutine 标识符。

       无法使用属性类别来识别诊断服务 RoutineControl 的子功能

       在 DiagnosticRoutine 的情况下，不能使用属性类别来识别子功能。

       子功能实际上具有不同的属性，即诊断程序的参数，为此需要专门的建模。

       对诊断程序的参数建模

       DiagnosticRoutine 的参数通过在以下角色中聚合的 DiagnosticParameter 建模：

       • DiagnosticStartRoutine.request

       • DiagnosticStartRoutine.response

       • DiagnosticStopRoutine.request

       • DiagnosticStopRoutine.response

       • DiagnosticRequestRoutineResults.response

       反过来，DiagnosticParameter 聚合了角色 dataElement 中的 DiagnosticDataElement（参见第 4.2 节）。

       诊断程序需要启动

       ISO 14229-1 [15] 没有预见到已经在启动时执行的诊断程序的存在。因此，需要在某个时间点启动诊断程序才能理解它。

       DiagnosticRoutine.start 的存在

       在完整的 DiagnosticExtract 中，对于任何给定的 DiagnosticRoutine，属性 DiagnosticRoutine.start 应始终存在。

       DiagnosticRoutine.stop 和 DiagnosticRoutine.requestResult 的存在

       与 DiagnosticRoutine.start（由 [constr_1339] 阐明）相反，DiagnosticRoutine.stop 和 DiagnosticRoutine.requestResult 的存在确实是可选的。

       DiagnosticServiceSwMapping 与同步调用的 DiagnosticRoutines 的一致性

       引用仅在角色开始中聚合 DiagnosticStartRoutine 的 DiagnosticServiceSwMapping 的每个 DiagnosticServiceSwMapping 应仅引用 SwcServiceDependency 或 BswServiceDependency，后者依次聚合具有属性 diagRoutineType 设置为 DiagnosticRoutineTypeEnum.synchronous 的 DiagnosticRoutineNeeds。

       DiagnosticServiceSwMapping 与异步调用的 DiagnosticRoutine 的一致性

       每个DiagnosticServiceSwMapping 引用一个DiagnosticRoutineControl，该DiagnosticRoutineControl 在角色停止响应中聚合一个DiagnosticStopRoutine 和/或DiagnosticRequestRoutineResults。  requestResults 应仅引用 SwcServiceDependency 或 BswServiceDependency，它们依次聚合具有属性 diagRoutineType 设置为 DiagnosticRoutineTypeEnum.asynchronous 的 DiagnosticRoutineNeeds。

       DiagnosticServiceSwMapping 与例程 ID 的一致性

     对于每个引用一个 DiagnosticRoutineNeeds 和一个 DiagnosticRoutineControl 的 DiagnosticServiceSwMapping，DiagnosticRoutineNeeds.ridNumber 的值应被忽略，而应采用 DiagnosticRoutineControl.routine.id 的值。

       这个元类代表定义诊断程序的能力。

       这代表启动诊断程序的能力。

       这代表停止诊断程序的能力。

       该元类表示定义诊断例程执行结果的能力。

       这表示“例行控制”诊断服务的一个实例。

       5.4.13 SecurityAccess

       本章描述了诊断服务SecurityAccess（0x27）的建模。

       图 5.21：诊断服务 SecurityAccess (0x27) 的建模

       DiagnosticSecurityAccess.securityLevel的存在性

       在角色 DiagnosticSecurityAccess.securityLevel 中的引用存在之前，给定的 DiagnosticSecurityAccess 的配置被认为是不完整的。

       [TPS_DEXT_01053] 的含义是在配置工作流的中间步骤中可能缺少引用。 但是在从 DiagnosticExtract 生成 ECU 配置的时间点，需要参考才能理解给定 DiagnosticSecurityAccess 的模型。

       请注意（如第 5.4 节所述）该服务的子功能是通过类别属性建模的。

       为了响应许多其他诊断服务和 SecurityAccess 之间的概念差异，诊断服务 SecurityAccess 的适用子功能没有通过属性 DiagnosticSecurityAccess.category 定义。

       执行诊断服务 SecurityAccess 的工作流

       执行诊断服务 SecurityAccess 的工作流程基本上归结为诊断仪发送请求以从诊断堆栈中获取种子，然后将密钥发送回堆栈。

       因此，子函数一般可以描述为 requestSeed 和 sendKey，这正是 ISO 14229-1 [15] 所做的。

       按照这个逻辑，requestSeed 可以得到一个特定的编号来识别子功能，然后 sendKey 子功能会被分配 requestSeed 子函数的编号 + 1。同样，这完全符合 ISO  142291 [15]。

       但是，还有进一步的维度需要考虑，即DiagnosticSecurityLevel。 根据 ISO 14229-1 [15]，不同的安全级别为子功能标识符制定不同的编号。

       DiagnosticSecurityAccess.requestSeedId 的语义

       属性 DiagnosticSecurityAccess.requestSeedId 用于根据预期的安全级别定义诊断服务 SecurityAccess 的子功能的编号。

       DiagnosticSecurityAccess.requestSeedId 的可能值

       属性 DiagnosticSecurityAccess.requestSeedId 的值只能设置为奇数。

       支持的值范围包括以下列表：

       • 闭合区间 0x01 .. 0x41 中的所有奇数

       • 0x5F（这对应于符合 ISO 26021-2 [  16])

       • 闭区间 0x61 .. 0x7E 中的所有奇数

       与诊断服务 SessionControl（参见第 5.4.14 节）中的类似情况相比，没有真正的证据表明在创建引用 DiagnosticSecurityAccess 之前总是存在 DiagnosticSecurityLevel，以便在角色 DiagnosticSecurityAccess.securityLevel 中正确建立引用。

       制作参考 DiagnosticSecurityAccess.securityLevel 《atpSplitable》 的动机

       引用 DiagnosticSecurityAccess.securityLevel 需要使用构造型 atpSplitable 进行修饰，以便宣传在实际创建给定的 DiagnosticSecurityAccess 之后的某个时间（可能在不同的工件中）创建对相应 DiagnosticSecurityLevel 的引用的想法。

       当然，如果DiagnosticSecurityLevel 在定义DiagnosticSecurityAccess 之前确实存在，则可以直接将引用插入到模型中。

       这表示“安全访问”诊断服务的一个实例。

       5.4.14 SessionControl

       本章描述了诊断服务SessionControl（0x10）的建模。该服务的明显目标是支持从一个诊断会话切换到另一个诊断会话。

       DiagnosticSessionControl 的建模

       为了提供一种方法来指定从一个诊断会话到另一个诊断会话的切换，DiagnosticSessionControl 指的是角色diagnosticSession 中的一个DiagnosticSession。

       根据 ISO 14229-1 [15]，诊断服务 SessionControl 定义了子功能。

       识别DiagnosticSessionControl的子功能

       在 DiagnosticSessionControl 的情况下，通过属性 DiagnosticSessionControl.category 对适用的子功能进行编码并不是一个好主意。

       实际上，可能的子功能与诊断会话的概念密切相关，由元类 DiagnosticSession 表示。

后者又具有一个属性 id，它直接对应于 DiagnosticSessionControl 的适用子功能的编号。

       换句话说，DiagnosticSessionControl 的子功能通过参考DiagnosticSessionControl.diagnosticSession 来标识。

       DiagnosticSessionControl.diagnosticSession 的存在

       通过参考DiagnosticSessionControl.diagnosticSession 对DiagnosticSessionControl 的子功能进行建模的想法意味着适用的DiagnosticSession 在创建给定的DiagnosticSessionControl 时已经存在。

       假设情况总是如此，因为 DiagnosticSessions 的定义是为诊断通信奠定基础的一部分。

       很难预见在工作流的最后定义诊断会话的场景，从而导致完整的诊断提取。

       表格表示“会话控制”诊断服务的一个实例。

       5.4.15 RequestFileTransfer

       本章描述了诊断服务RequestFileTransfer (0x38) 的建模。该服务的目的是触发从 AUTOSAR 诊断堆栈传输文件或向 AUTOSAR 诊断堆栈传输文件。

       请注意，除了它的存在之外，没有什么可以为 DiagnosticRequestFileTransfer 配置的。

       诊断服务 RequestFileTransfer 没有定义任何子功能

       诊断服务 RequestFileTransfer 没有定义任何子功能。 因此，属性类别的使用不受元类 DiagnosticRequestFileTransfer 的限制。

       小结：首先，文件传输的概念这个在ECU的应用中就比较新了。其次，这个传输看上去居然是两个ECU之间的传输，这个跟我之前预想的不同。之前的预想还考虑过这个是否会跟BootLoader有关，现在看起来不是一个概念。

       该诊断服务实例实现了 UDS 服务 0x38。

       该元类包含“请求文件传输”诊断服务的所有实例共享的属性。

       这样，AUTOSAR支持的诊断服务内容基本上就看完了，关于这一次的一些小结在前文中做了简单的标注。主要的内容还是安全访问、对话的切换以及文件传输。最后一个占的信息很少，但是的确是一个比较新的概念。