REDISANT 提供互联网与物联网开发测试套件 #

复杂变量类型 #

在我们考虑 ModellingRules 以及子类型的工作原理之前，让我们先了解一下复杂变量类型。它们与复杂对象类型非常相似。主要区别在于它们只能将Variables用作InstanceDeclarations，而不是对象或方法。方法是为对象定义的；因此很明显它们不适合变量类型。变量始终是对象或其他节点的一部分，因此变量类型包含对象作为其一部分是没有意义的。变量类型只能公开其他变量，要么描述变量（如提供变量提供的值的工程单位），要么公开值结构的部分。例如，变量可以提供具有多个字段的复杂数据类型，子变量将公开每个字段。但也有可能变量提供由其他三个变量提供的测量值的平均值，因此这些变量成为它的子变量。通过将这些子变量作为 InstanceDeclarations 提供，VariableType 将此信息形式化，以便客户端知道变量类型的每个实例都将具有该信息。

上一节中为 InstanceDeclarations 定义的规则也适用于 VariableTypes，因为只有变量可以用作 InstanceDeclarations。

ModellingRules #

如果 TypeDefinition（即 ObjectType 或 VariableType）引用的每个实例具有 ModellingRule，则它将成为 InstanceDeclaration。ModellingRule 指定 InstanceDeclaration 相对于 ObjectType 实例会发生什么情况。有三个基本选择，也称为 ModellingRule 的 NamingRule。

• 第一个选择是使 InstanceDeclaration 成为强制性的（Mandatory），这意味着每个实例都必须具有与 InstanceDeclaration 具有相同 BrowsePath 的对应项，并且必须与 InstanceDeclaration 属于同一类型（当它是 Object 或 Variable 时）或该类型的子类型。

• 第二个选择是使其成为可选的（Optional），也就是说，每个实例都可以有这样的对应项。但并不要求每个实例都有这样的对应项。

• 第三个选择是使其成为约束（Constraint），这意味着 InstanceDeclaration 为 TypeDefinition 的实例定义了一个约束。稍后我们将详细了解可能的限制。例如，基数限制指定 TypeDefinition 的实例应引用具有与 InstanceDeclaration 相同类型的定义范围的实例。

ModellingRules 是 OPC UA 中的一个可扩展概念，即服务器或标准信息模型可以定义自己的 ModellingRules。但是，它们始终必须指定前面提到的 NamingRules 之一。

地址空间中的ModellingRules #

ModellingRules 表示为 ModellingRule 类型的对象。每个 ModellingRule 都有一个名为 NamingRule 的变量（更准确地说是特性，参见第 2.6 节）。它包含 ModellingRule 的 NamingRule。InstanceDeclarations 引用具有 ReferenceType HasModellingRule 的 ModellingRule 对象来指定其 ModellingRule。每个节点只能使用 HasModellingRule 引用一个 ModellingRule。图 1.20 左侧显示了 ModellingRules 在地址空间中的使用方式。为了简化图表，我们在本书中使用右侧所示的符号，其中 ModellingRule 作为括号中的文本添加到节点。

ModellingRules——强制（Mandatory）和可选（Optional） #

有两个标准 ModellingRules，分别称为 Optional 和 Mandatory，其名称与 NamingRule 相同。让我们看一个例子来了解这两个 ModellingRules 是如何工作的。在图 1.21 中，AddressType 具有 InstanceDeclarations Street，ModellingRule Optional，以及 City，ModellingRule Mandatory。这意味着每个实例都必须有一个 City，也可以有一个 Street。在图 1.21 中，您可以看到 Address1 既有 City，也有 Street。在这种情况下，两个实例也都有 ModellingRules。只要它们未被 TypeDefinition 引用，它们就不是 InstanceDeclarations。在这种情况下，允许对实例使用任何 ModellingRule。通常，普通实例没有 ModellingRules，如 Address2-4 中所示。Address2 省略了 Street，只提供了 City。在 Address3 和 4 中，您可以看到两者共享同一个 City。 ModellingRules Optional 和 Mandatory 未指定在创建 TypeDefinition 的新实例时服务器如何处理 InstanceDeclarations。它可以为 InstanceDeclarations 创建新的节点，也可以仅引用现有节点。TypeDefinition 的实例只需引用具有相同 BrowsePath 和相同类型（或子类型）的实例。例如，服务器还可以引用 InstanceDeclaration 节点，从而创建类似于静态类变量的东西，该变量对所有实例都具有相同的值。在运行时，只要每个类型的实例上始终有一个具有正确 BrowseName 和类型的节点，节点就可以更改。

在查看简单的 ModellingRules 之后，让我们看看变量和方法的所有权。如前所述，方法和变量必须始终由对象或对象类型使用 HasComponent 或 HasProperty 引用来引用。但由于变量和方法可以共享并属于多个对象，因此它们不属于一个对象。因此，如果删除了图 1.21 中的 Address3，则必须删除其下方的 Street[4]，因为它没有引用它的 Node，但不能删除 City，因为它仍由 Address4 使用。

复杂 TypeDefinitions 的实例可以再次用作 InstanceDeclarations。在图 1.22 中，您可以看到 Address 被用作 InstanceDeclaration。因此，基于 InstanceDeclarations City 和 Street 的实例也成为 InstanceDeclarations。这意味着存在有关 ModellingRules 的规则。ModellingRules 可能会更改；但是，NamingRule 必须保持不变。唯一的例外是 Optional，它可以被 Mandatory 替换。通常，只有在约束条件收紧而不是放松的情况下，才可以替换 ModellingRules。在图 1.22 中，Street 的 ModellingRule 从 Optional 更改为 Mandatory。因此，有效实例是同时具有两者的 Employee1。不允许 Employee2 不提供 Street，虽然 AddressType 不需要它。

在图 1.22 中，揭示了另一条有关 ModellingRules 的规则。Address 对象具有 ModellingRule Optional，并且位于通往 Street 和 City 的唯一路径上。这意味着，当未提供 Address 时，Street 和 City 不必提供，正如您在有效的 Employee3 对象中看到的那样。

在我们了解如何使用 NamingRule Constraint 以及如何创建我们自己的 ModellingRules 之前，让我们先考虑一些更复杂的例子。首先，让我们看看如果从 TypeDefinition 到 InstanceDeclaration 有多个 BrowsePath 会发生什么。图 1.23 给出了一个例子。TemperatureSensorType 具有 EngineeringUnit 变量（组织在Folder Configuration之下）和 Temperature 变量（组织在Measurement之下）。Temperature 变量使用 EngineeringUnit 变量来公开其工程单位。

有两种特殊情况；第一种情况是，两个不同的引用将相同的源与相同的目标连接起来。在图 1.23 中，您可以看到 Measurement 引用了 Temperature 两次。在这种情况下，在每个实例上，Measurement 的实例必须通过这两个引用引用相同的节点；不允许指向两个不同的节点。

第二种情况是存在两条不同的间接路径。在图 1.23 中，EngineeringUnit 由两条不同的路径引用。在这种情况下，允许来自 Configuration 中的一个节点和 Temperature 中的一个不同的节点的引用。在这个例子中，这可能没有意义，但在其他用例中，这是一种合理的方法，例如，当使用共享（静态）类变量时。

现在让我们看看如果我们在 InstanceDeclarations 之间添加非层次引用会发生什么。在图 1.24 中，您可以看到一个 DeviceType 在两个子设备之间具有非层次引用。实例可能会或可能不会提供这种非层次引用。此行为是特定于服务器的，适用于由 OPC UA 定义的 ModellingRules。但是，您可以定义自己的 ModellingRule，指定如何处理 InstanceDeclarations 之间的非层次引用。

ModellingRules——约束（Constraints） #

在了解了强制和可选InstanceDeclarations之后，让我们来看看用于定义约束的InstanceDeclarations，因此它们的 ModellingRule 中具有NamingRule Constraint。我们首先来看看当前 OPC UA 规范定义的唯一一个定义Constraint的 ModellingRule。这个 ModellingRule 称为 ExposesItsArray，可用于具有数组作为数据类型的VariableTypes。语义是数组的每个条目也作为子变量公开。图 1.25 对此进行了举例说明。TeamType 包含一个字符串数组和一个使用 ModellingRule ExposesItsArray 的ConstraintVariable。该类型的实例必须为数组的每个条目都有一个子变量，正如您在图 1.25 中的 UABookTeam 变量中所见。公开子变量允许引用数组的单个条目，因为它们作为地址空间中的节点公开。请注意，无需暴露数组即可访问数组的单个条目（订阅、读取或写入它们）。这可以通过 OPC UA 服务直接通过寻址数组的部分来完成（参见第 5 章）。

ExposesItsArray 只是 Constraint ModellingRules 的一个示例。您可以定义自己的 ModellingRules，以便在模型中定义约束。建模中的典型约束是基数限制。一种类型的实例应引用另一种类型的 n 和 m 个实例。这种约束可以通过 Constraint ModellingRule 公开。具有这种 ModellingRule 的 InstanceDeclaration 可用作包含最小值和最大值的两个 TypeDefinitions 之间的代理对象（参见第 3.3.8 节），并引用寻址的 ReferenceType。这种 ModellingRule 可能会集成到 OPC UA 的第二版中。因此，我们不会公开这种 ModellingRule 的任何细节，因为我们对其进行的建模可能与规范中略有不同。

最后，让我们讨论一下为什么 OPC UA 定义的 ModellingRules 不涵盖所有方面，例如非层次结构引用的情况或如何基于 InstanceDeclarations 创建实例。OPC UA 工作组开始定义所有这些内容。但事实证明，处理这个问题的方法和用例各不相同，其中一种或另一种可能性更为合适。指定所有这些可能性将导致相对较多的 ModellingRules，这将变得难以理解。此外，这些额外信息有多大用处也值得怀疑。在针对类型进行编程的情况下，您只需要知道目标节点的层次路径，并且必须知道该节点是可选的还是必需的。所有这些都由定义的 ModellingRules 提供。在基于类型创建实例时，服务器负责确保所有 InstanceDeclarations 的对应项都基于 ModellingRules 而存在。是否创建新节点或共享节点由服务器负责，不一定必须向客户端公开。因此，OPC UA 提供的 ModellingRules 是一个很好的基础，可以通过其他 ModellingRules 进行扩展，尤其是那些与约束相关的 ModellingRules。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：https://blog.redisant.cn