![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/userdefault.png)
06/13/2017
![sp_UserOfflineSmall](https://opcfoundation.org/wp-content/sp-resources/forum-themes/reboot/images/darkpack/sp_UserOfflineSmall.png)
All,
I would like to model an address space which implements the OPC-UA Device Integration (DI) information model. To get a better understanding how to do that, I'm looking for an example model which adheres to this specification (link to the spec.).
I've found that the OPC Foundation published the node set of this specification here: -> Opc.Ua.Di.NodeSet2.xml
Also, I can load this NodeSet in some graphical modelers (e.g. Softing or Unified Automation UaModeler), but what I would find very helpful is a concrete example using this NodeSet to define an address space which correctly implements the DI model.
Any hints, links and explanations are much appreciated.
Best regards,
Jonas
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/userdefault.png)
06/13/2017
![sp_UserOfflineSmall](https://opcfoundation.org/wp-content/sp-resources/forum-themes/reboot/images/darkpack/sp_UserOfflineSmall.png)
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
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/guestdefault.png)
You will find that DeviceType is a sub-type of TopologyElementType. This type defines a ParameterSet to hold Variables (Parameters) and a MethodSet to hold Methods. FunctionalGroups are then used to organize these flat lists. For example, you could have a FunctionalGroup Diagnostics and another one called Maintenance. There are no constraints.
Any sub-type can certainly add additional components, like Objects. ADI (https://opcfoundation.org/deve.....vices-adi/), for instance, defines quite complex devices.
I agree that the spec should also allow FunctionalGroup structuring in the type. The spec should say "may only be done on an instance".
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/userdefault.png)
06/13/2017
![sp_UserOfflineSmall](https://opcfoundation.org/wp-content/sp-resources/forum-themes/reboot/images/darkpack/sp_UserOfflineSmall.png)
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?
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/guestdefault.png)
I agree with your statements. Devices where the parameters and their grouping is known should already expose it in the type system.
The original DI specification was written to allow EDD based devices (EDD = Electronic Device Description) to be represented and we were told that the grouping for these devices is dynamic.
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/userdefault.png)
06/13/2017
![sp_UserOfflineSmall](https://opcfoundation.org/wp-content/sp-resources/forum-themes/reboot/images/darkpack/sp_UserOfflineSmall.png)
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).]
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/guestdefault.png)
I already wanted to suggest this. The OPC Foundation has a tracking system (https://opcfoundation.org/reso.....-tracking/) which can be used to enter feature requests. You will find a number of projects, one of them is OPC for Devices.
1 Guest(s)