831

831

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

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

       5.3.2 访问权限的优先级

       访问权限本身的定义可以在不同的层次上进行。 因此，有必要定义如何解释这些不同级别上访问权限的存在。

       支持的访问权限定义场景

       访问权限的定义可能有以下场景：

       • 访问权限是在 DiagnosticServiceClass 级别上定义的。

       在这种情况下，预期的语义是此配置绑定到从 DiagnosticServiceClass 派生的所有 DiagnosticServiceInstance。

       DiagnosticServiceInstance.accessPermission 的配置被视为错误并应相应报告。

       如果 DiagnosticServiceClass.accessPermissionValidity 设置为值 accessPermissionServiceClass，则此方案适用。

       • 访问权限是在单个DiagnosticServiceInstance 级别定义的。 在这种情况下，预期的语义是 DiagnosticServiceClass 不应对适用的访问权限的定义做出任何假设。

       DiagnosticServiceClass.accessPermission 的配置被视为错误并应相应报告。

     如果 DiagnosticServiceClass.accessPermissionValidity 设置为值 accessPermissionServiceInstance，则此方案适用。

       • 明确允许定义DiagnosticServiceClass.accessPermission 和DiagnosticServiceInstance.accessPermission。

       在这种情况下，预期的语义是，如果 DiagnosticServiceClass.accessPermission 存在，则不需要各个 DiagnosticServiceInstance 定义 DiagnosticServiceInstance.accessPermission，但如果它们这样做，则 DiagnosticServiceInstance.accessPermission 的优先级高于 DiagnosticServiceClass.accessPermission 的定义。

       这基本上归结为通过在 DiagnosticServiceInstance 级别上的设置来覆盖在 DiagnosticServiceClass 级别上进行的访问权限设置的能力。

       同时，这个场景节省了一些文件占用空间，因为（考虑到 DiagnosticServiceClass.accessPermission 的存在）没有必要定义单独的 DiagnosticServiceInstance.accessPermission，除非有专门的需求。

       如果 DiagnosticServiceClass.accessPermissionValidity 设置为值 accessPermissionInstanceOverridesClass，则此方案适用。

       小结：这部分是彻头彻尾的工具设计的要求了。

       [TPS_DEXT_01061] 定义的场景需要建模支持，以允许用户精确表达模型在访问权限方面的预期语义。为此，可以使用属性 DiagnosticServiceClass.accessPermissionValidity。

     该元类提供了如何在 DiagnosticServiceInstance 和 DiagnosticServiceClass 之间解析 accessPermission 的设置。

       不完整模型中存在 DiagnosticServiceClass.accessPermissionValidity

       如果属性 DiagnosticServiceClass.accessPermissionValidity 不存在，则应假定配置不完整。

       请注意，[TPS_DEXT_01062] 中描述的模型状态仍然是允许的，因为可能只有在模型生命周期的后期才能决定属性的值。

       完整模型中存在 DiagnosticServiceClass.accessPermissionValidity

       当模型的生命周期接近模型被认为是完整的点时，属性 DiagnosticServiceClass.accessPermissionValidity 应该存在，以便能够正确地找出预期的模型语义。

       属性 DiagnosticServiceInstance.accessPermission 的存在

       关于属性DiagnosticServiceInstance.accessPermission 的存在，以下规则适用：

       • 如果属性DiagnosticServiceInstance.accessPermission 或DiagnosticServiceClass.accessPermission 都不存在，则假定配置不完整，因为未定义访问权限。

       • 如果属性DiagnosticServiceInstance.accessPermission 或DiagnosticServiceClass.accessPermission 存在但没有进一步引用DiagnosticSession 或DiagnosticSecurityLevel，则这意味着可以在任何诊断会话或安全级别中执行受影响的诊断服务。 换句话说，没有任何限制。

       5.4 AUTOSAR 支持的诊断服务

       以下小节描述了 ISO 14229-1 [15] 中定义的相关诊断服务集合的建模。 这意味着 AUTOSAR DiagnosticExtract 的定义不明确支持 [15] 定义的诊断服务的总集合。

       本文档中编译的一些诊断服务定义了所谓的子功能，需要识别这些子功能以完全指定相应诊断服务的性质。

       小结：这是所支持的所有的服务，从这里面看，BootLoader所需要的相关的服务的确是支持的。之前，在接触ETAS的软件的时候最初可能有一个错误的认识，最初我以为AUTOSAR的UDS服务对于BootLoader的支持可能并不完善，现在看起来应该问题不大。

       通过属性 DiagnosticServiceInstance.category 指定子功能

       在诊断服务根据 ISO 142291 [15] 定义子功能的所有情况下，DiagnosticServiceInstance 的适用子类的属性类别的值可用于将适用的子功能指定为文本标记。

       定义约束以阐明给定子功能的属性类别的标准化值的存在。 这意味着给定的 DiagnosticServiceInstance 子类的实例一次只有一个子函数。

       诊断服务的类别属性的可能值

       AUTOSAR 声称有权对给定诊断服务的属性类别的可能值进行标准化。

       如果适用，AUTOSAR 允许使用非标准化值的属性类别值。

       然而，在这种情况下，属性类别的专有值应以公司特定的名称片段作为前缀，以避免在扩展 AUTOSAR 标准本身声明的可能值列表时或时可能发生的冲突。

       给出的例子信息比较容易提取，看起来是针对硬件复位做出的一个要求。

       5.4.1 DataByIdentifier

       本章描述了诊断服务ReadDataByIdentifier（0x22）和WriteDataByIdentifier（0x2E）的建模。

       此诊断服务的目的是使诊断仪能够从 AUTOSAR 诊断堆栈中请求数据记录的值。 数据记录由正式建模的 DiagnosticDataIdentifier 标识。

       此诊断服务的建模包括两个元类 DiagnosticReadDataByIdentifier 和 DiagnosticWriteDataByIdentifier。 这些元类都需要指定 DiagnosticDataIdentifiers 集以及适用的 DiagnosticAccessPermissions 集。

       由于这些属性在 DiagnosticReadDataByIdentifier 和 DiagnosticWriteDataByIdentifier 的实例之间共享，因此创建了一个名为 DiagnosticDataByIdentifier 的抽象基类，它提供对 DiagnosticDataIdentifier 和 DiagnosticAccessPermission 的实际引用。

       存在 DiagnosticDataByIdentifier.dataIdentifier

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

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

       在运行时读取多个 DID 的能力是通过属性 DiagnosticReadDataByIdentifier.maxDidToRead 控制的，因此（在配置时）将属性 dataIdentifier 的多样性限制为 1 就足够了。

       表格表示“按标识符读取数据”诊断服务的一个实例。

       这表示“按标识符写入数据”诊断服务的一个实例。

       此元类包含“按标识符写入数据”诊断服务的所有实例共享的属性。

       这表示所有通过标识符访问数据的诊断服务的抽象基类。

       DiagnosticDataByIdentifier 的建模表示 DiagnosticExtract 中诊断服务的具体实例。 但是，存在在 DiagnosticReadDataByIdentifier 的所有实例之间共享的属性。

       为此，引入了专用服务类 DiagnosticReadDataByIdentifierClass。

       该元类包含“按标识符读取数据”诊断服务的所有实例共享的属性。

       需要注意，可以从不同的 DiagnosticServiceInstances 创建对具体 DiagnosticDataIdentifier 的引用。

       DiagnosticServiceSwMapping 与数据 ID 的一致性

       对于每个引用一个 DiagnosticValueNeeds 和一个 DiagnosticDataByIdentifier 的 DiagnosticServiceSwMapping，DiagnosticValueNeeds.didNumber 的值应被忽略，而应采用 DiagnosticDataByIdentifier.dataIdentifier.id 的值。

       这部分主要讲解了诊断访问权限优先级的问题以及AUTOSAR支持的诊断服务，针对读写DID进行了较为详细的描述。