NetworkIdentifier is missing in generated Model Design for DI model

[eoursel]

Describe the bug

Looks like the generated DI model is missing some nodes.

To Reproduce

asp and using model compiler on the generated ASP

Expected behavior

<ObjectType SymbolicName="Prefix3:ConnectionPointType" Category="DI ConnectionPoint" BaseType="Prefix3:TopologyElementType" IsAbstract="true">
    <Description>Represents the interface (interface card) of a Device to a Network.</Description>
    <Children>
      <Object SymbolicName="Prefix3:NetworkAddress" TypeDefinition="Prefix3:FunctionalGroupType" ModellingRule="Mandatory">
        <Description>The address of the device on this network.</Description>
      </Object>
      <Object SymbolicName="Prefix3:ProfileIdentifier" TypeDefinition="Prefix3:ProtocolType" ModellingRule="MandatoryPlaceholder">
        <BrowseName>&lt;ProfileIdentifier&gt;</BrowseName>
      </Object>
    </Children>
    <References>
      <Reference>
        <ReferenceType>Prefix3:ConnectsTo</ReferenceType>
        <TargetId>Prefix3:NetworkIdentifier</TargetId>
      </Reference>
    </References>
    <ClassName />
  </ObjectType>

There is a reference on Prefix3:NetworkIdentifier but no definition of NetworkIdentifier.

NetworkIdentifier is defined in the source NodeSet file as

  <UAObject NodeId="ns=1;i=6599" BrowseName="1:&lt;NetworkIdentifier&gt;" SymbolicName="NetworkIdentifier" ParentNodeId="ns=1;i=6308">
    <DisplayName>&lt;NetworkIdentifier&gt;</DisplayName>
    <References>
      <Reference ReferenceType="HasTypeDefinition">ns=1;i=6247</Reference>
      <Reference ReferenceType="HasModellingRule">i=11508</Reference>
      <Reference ReferenceType="ns=1;i=6030" IsForward="false">ns=1;i=6308</Reference>
    </References>
  </UAObject>

Screenshots

[mpostol]

In the UANodeSet file

  <UAObjectType NodeId="ns=1;i=6308" BrowseName="1:ConnectionPointType" IsAbstract="true">
    <DisplayName>ConnectionPointType</DisplayName>
    <Description>Represents the interface (interface card) of a Device to a Network.</Description>
    <Category>DI ConnectionPoint</Category>
    <Documentation>https://reference.opcfoundation.org/v104/DI/v103/docs/5.4</Documentation>
    <References>
      <Reference ReferenceType="HasComponent">ns=1;i=6354</Reference>
      <Reference ReferenceType="HasComponent">ns=1;i=6499</Reference>
      <Reference ReferenceType="ns=1;i=6030">ns=1;i=6599</Reference>
      <Reference ReferenceType="HasSubtype" IsForward="false">ns=1;i=1001</Reference>
    </References>
  </UAObjectType>

the reference to NetworkIdentifier (i.e. ns=1;i=6599)

  <UAObject NodeId="ns=1;i=6599" BrowseName="1:&lt;NetworkIdentifier&gt;" SymbolicName="NetworkIdentifier" ParentNodeId="ns=1;i=6308">
    <DisplayName>&lt;NetworkIdentifier&gt;</DisplayName>
    <References>
      <Reference ReferenceType="HasTypeDefinition">ns=1;i=6247</Reference>
      <Reference ReferenceType="HasModellingRule">i=11508</Reference>
      <Reference ReferenceType="ns=1;i=6030" IsForward="false">ns=1;i=6308</Reference>
    </References>
  </UAObject>

is of custom type ns=1;i=6030

  <UAReferenceType NodeId="ns=1;i=6030" BrowseName="1:ConnectsTo" Symmetric="true">
    <DisplayName>ConnectsTo</DisplayName>
    <Description>Used to indicate that source and target Node have a topological connection.</Description>
    <Category>DI ConnectsTo</Category>
    <Documentation>https://reference.opcfoundation.org/v104/DI/v103/docs/5.5</Documentation>
    <References>
      <Reference ReferenceType="HasSubtype" IsForward="false">i=33</Reference>
    </References>
  </UAReferenceType>

that derives from i=33

  <UAReferenceType NodeId="i=33" BrowseName="HierarchicalReferences" IsAbstract="true">
    <DisplayName>HierarchicalReferences</DisplayName>
    <Documentation>https://reference.opcfoundation.org/v104/Core/docs/Part5/11.2</Documentation>
    <References>
      <Reference ReferenceType="HasSubtype" IsForward="false">i=31</Reference>
    </References>
    <InverseName>HierarchicalReferences</InverseName>
  </UAReferenceType>

but children in UAModelDesign group only references: inheriting from HasProperty or HasComponent - it is not the case in this example.

Anyway, the node shall be added to References that groups all other references and it is true and the node definition shall be added to the generated document and it is false.

We should consider two problems:

1. if the NetworkIdentifier reference should be added to Children element - depends on the ModelDesign language, but my answer is no. If yes, we must define different criteria related to the aggregation of the Children element.
2. All types of references must cause that the target nodes are added to the generated document - confirmed.

[mpostol]

From Part 3 we get to know:

The semantic of HierarchicalReferences is to denote that References of HierarchicalReferences span a hierarchy. It means that it may be useful to present Nodes related with References of this type in a hierarchical-like way. HierarchicalReferences does not forbid loops. For example, starting from Node “A” and following HierarchicalReferences it may be possible to browse to Node “A”, again.

Does the hierarchy mean layering? In layered architecture circular references are forbidden!! In the case of loops in the hierarchy which node is above and which one is below?

In the case of loops, the same node may be added many times. The same is in case we have many to one references hierarchy.

BTW my spellchecker complains about typos in the mentioned text.

[eoursel]

Good morning @mpostol

Just to mention that for the DI we have already the ModelDesign file as published by OPC Foundation. In the case of ConnectionPointType the generated type should be

  <ObjectType SymbolicName="DI:ConnectionPointType" BaseType="DI:TopologyElementType" IsAbstract="true">
    <Description>Represents the interface (interface card) of a Device to a Network.</Description>
    <Children>
      <Object SymbolicName="DI:NetworkAddress" TypeDefinition="DI:FunctionalGroupType" ModellingRule="Mandatory">
        <Description>The address of the device on this network.</Description>
      </Object>
      <Object SymbolicName="DI:ProfileIdentifier" TypeDefinition="DI:ProtocolType" ModellingRule="MandatoryPlaceholder">
        <BrowseName>&lt;ProfileIdentifier&gt;</BrowseName>
      </Object>
      <Object SymbolicName="DI:NetworkIdentifier" TypeDefinition="DI:NetworkType" ModellingRule="OptionalPlaceholder">
        <BrowseName>&lt;NetworkIdentifier&gt;</BrowseName>
        <ReferenceType>DI:ConnectsTo</ReferenceType>
      </Object>
    </Children>
  </ObjectType>

Looks like NetworkIdenfier is used as a child even if the reference type is not hierarchical. I remember a very old discussion some years ago about the Children definition which is not in the specification. I know that Randy has an explanation.

[mpostol]

@eoursel I agree, it is true in the DI definition recently modified by @randy-armstrong

Revision: 496d5233f4c07a6a48d6ce72785c3a59ed9f29d3
Author: Randy Armstrong <randy@s...>
Date: 11.04.2021 00:35:29
Message:
DI-1.03.0-2021-03-09

I have started a new discussion about the HierarchicalReferences semantics to have something written (I also remember the discussion and explanation provided by @randy-armstrong). I just guess that keeping the ModelDesign undefined is a goal but not a side effect. Recovering model definition using ModelDesign language without definition of this language looks like mission impossible - let me stress recent modification of the DI model is dated 11.04.2021so it looks like a "race condition".

Anyway,

• I have defined a new issue related directly to the code responsible to recover the ModelDesign definition (NetworkIdentifier is missing in generated Model Design for DI model OPC-UA-OOI#629)
• I will prepare a Unit Test to gather more experience with this issue
• after that, we will try to assess any impact on the existing solution

My point is that model must not be used to recover the language definition (meaning of the Children in this case), we must also consider a mistake in the model. In this case, it must be reported during the regeneration ModelDesign if possible (it is rather a semantic error that requires a more detailed definition of the HierarchicalReferences in the spec to be implemented).

Waiting for @randy-armstrong feedback.

I will keep you informed about the progress, but it depends on the explanations I will be able to gather.

[mpostol]

@eoursel I hope you are well, I haven't got any response yet but together with my student @mertyusaatag, we continue working on ModelDesign recovery from UANodeSet2. Let me know if you are still willing helper to review the outcome and advise in case of problems. Do you know if there is anyone interested to continue this work?

[eoursel]

hi @mpostol. Yes i am well. Yes I am still interested by ModelDesign recovery from UANodeSet2 since this is the standard to generate C# code for the OPC Foundation SDK.

What is the current status for the generation of ModelDesign formats from the nodesets published by OPC Foundation?

A nice to have would be a Docker version of the asp tool to deploy it on a docker engine for fast testing. But it is nice to have. Anyway I am not sure that the modelCompiler Docker version is updated and usable.

I have seen that the modelCompiler was updated recently but i didn't have time to test it.

Have a nice day

[mpostol]

@eoursel

Docker version

I have just commenced research aimed at finding the next student to address this as a final thesis. In other words, I have added it to the roadmap 😊.

current status

1. in this repository we have and will add (it is in progress) a ModelDesign folder containing script `DoRecoverModelDesign.cmd; e.g. for DI is here responsible to execute asp
2. In the ModelDesign folder you can find outcomes generated by this tool
3. I will continue working on asp improvement

[mpostol]

Analyze the hierarchy against Organizes references.