首页 >> 大全

831_AUTOSAR_TPS_DiagnosticExtractTemplat

2023-12-26 大全 29 作者:考证青年

全部学习汇总: - /: , aha, very hard!

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

5.3.2 访问权限的优先级

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

支持的访问权限定义场景

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

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

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

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

如果 ss.dity 设置为值 ,则此方案适用。

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

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

如果 ss.dity 设置为值 ,则此方案适用。

• 明确允许定义ss. 和tance.。

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

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

同时,这个场景节省了一些文件占用空间,因为(考虑到 ss. 的存在)没有必要定义单独的 tance.,除非有专门的需求。

如果 ss.dity 设置为值 ,则此方案适用。

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

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

该元类提供了如何在 tance 和 ss 之间解析 的设置。

不完整模型中存在 ss.dity

如果属性 ss.dity 不存在,则应假定配置不完整。

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

完整模型中存在 ss.dity

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

属性 tance. 的存在

关于属性tance. 的存在,以下规则适用:

• 如果属性tance. 或ss. 都不存在,则假定配置不完整,因为未定义访问权限。

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

5.4 支持的诊断服务

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

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

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

通过属性 tance. 指定子功能

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

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

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

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

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

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

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

831_AUTOSAR_TPS_DiagnosticExtractTemplat__831_AUTOSAR_TPS_DiagnosticExtractTemplat

5.4.1

本章描述了诊断服务(0x22)和r(0x2E)的建模。

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

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

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

存在 .

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

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

在运行时读取多个 DID 的能力是通过属性 . 控制的,因此(在配置时)将属性 的多样性限制为 1 就足够了。

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

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

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

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

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

为此,引入了专用服务类 。

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

需要注意,可以从不同的 创建对具体 fier 的引用。

与数据 ID 的一致性

对于每个引用一个 和一个 的 ,. 的值应被忽略,而应采用 ..id 的值。

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

关于我们

最火推荐

小编推荐

联系我们


版权声明:本站内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 88@qq.com 举报,一经查实,本站将立刻删除。备案号:桂ICP备2021009421号
Powered By Z-BlogPHP.
复制成功
微信号:
我知道了