Example on how to use the Device Integration Model Opc.Ua.Di?|OPC UA Implementation: Stacks, Tools, and Samples|Forum|OPC Foundation

Hi Hauke,

I didn’t find any example so far. Currently going ahead relying on the specification and using the type implementation given in Opc.Ua.Di.NodeSet2.xml.

When one wants to model a single device, the specification is relatively compact. Basically Section 5 of the DI Specification is relevant (and for a first implementation only part of that section is interesting, except you want to serve a UI and documentation etc..).

So, I’m basically deriving a new type from DeviceType and use the FunctionalGroup Type (a FolderType) to organize what my device offers.

Open questions at the moment:

1) Not sure where to best attach Variables/Objects as children (FunctionalGroup refers to them using an ‘Organizes’ reference and not as children). I think the specification doesn’t mention that since it just specifies that FunctionalGroups can organize other nodes (1 node can appear in multiple FunctionalGroups). So, does one still use a folder hierarchy besides the FunctionalGroup hierarchy(ies) to hold Variables/Objects with a ‘HasComponen’t reference? Or leave it just flat below the Device (not very nice..).

2) The FunctionalGroup structuring can only be done on an instance (my understanding). Thus, this means you cannot define a FunctionalGroup structure on your Device. Page 10 of the spec “The Organizes References may be present only at the instance, not the type”. This seems a bit strange. Why shouldn’t I define the structure of my device as part of its type?

Cheers,

Jonas

Hi Karl-Heinz, All

Thanks for the reply and the link to the analyzer devices specification. Very helpful as an example for using the device integration specification. Looking at this specification (and a few others), I believe I could clarify a couple of things:

1) Regarding “where to attach variables in a DI model with ‘HasComponent’?” (Point 1) in my previous post): Page 9, Table 5 in the Device Integration specification defines that the ParameterSet has a ‘HasComponent’ reference to a list of Variables. So, it is suitable to be the parent of Variable nodes (as opposed to FunctionalGroups which just reference Variable nodes with an ‘organizes’ reference).

2) Regarding “how to model the structure of my device at type level?” (Point 2) in my previous post): it seems, the device integration model really does not support this. The analyzer devices specification shows this: see for example the definition of the AnalyserChannelType given in Section 5.2.2.3 in https://opcfoundation.org/deve…..vices-adi/ AnalyserChannelType is derived from TopologycalElementType and thus has components ParameterSet and MethodSet. But AnalyserChannelType also has Variable nodes, for example ‘ChannelId’, which it needs to keep as components. Now, these nodes are not modeled in the type definition of an AnalyzerChannel (Table 17). They are ‘loosely’ listed in Table 18 as Variables which shall go into ParameterSet and shall be referenced by the ‘Configuration’ functional group when an AnalyzerChannelType is instantiated.

3) Since I’m interested in modelling devices which have a CNC controller, I’m also looking at the specification “OPC UA for CNC Systems” https://opcfoundation.org/deve…..c-systems/ . In contrast to the analyzer specification, this specification does not make use of the device integration specification. For example, it models its CncChannelType by deriving basically from BaseObjectType (via CncComponentType). See Sect. 6.6.2, Table 12.

Thus, given 1) and 2), the question remains: if we have a sophisticated type system in UA, isn’t it undesirable to keep the definition of a device’s ‘member-variables’ in a written specification only and rely on the implementation to create instances with the correct variables? Having to do that means i) variables which the device offers have to be looked-up in a specification document and cannot be modelled in its type, and ii) since the type does not describe the necessary (and often mandatory) ‘member variables’, an OPC-UA server implementation has to explicitly attach these variables for each instance it creates of such a type. This sounds wrong (but of course I’m happy to learn why this is the right way…).

Given this observation, and considering that there are specifications from important domains which don’t follow the device integration model (CNC System Specification mentioned in point 3), it is difficult to evaluate the value gained from implementing the device integration model. (Written from the perspective of a OPC-UA server implementor).

Any preferred solution/approach recommended by the OPC-Foundation? Any thoughts, practical experiences?

Ok, thank you for sharing this feedback. I can see that there are situations where such flexibility for an object instance might be required. Although, I would suspect, the situation where one wants to model the structure of a device directly in the type system is more common (and simpler for designers and developers).

Also, I have the feeling it would not be that hard to extend the DI specification to allow for that. How do you handle this at the foundation, is there somewhere like a change/feature request backlog where people/members can contribute proposals?

[At the moment, given the above listed points and the fact that I’m not aware of any client in our vicinity requesting or benefiting directly from a DI implementation (at this time), I will most probably favor a server implementation which does not implement the Device Integration model. Or, put differently, will first focus on an implementation which models the structure of the device in the type system (since it wouldn’t be that complicated to add DI-compliance later if really needed).]