I created an own ObjectType with UaModeler that contains some DataVariables and want to add historizing capabilities for some of these according to the tutorial of the SDK but horribly failed.
As first step i enabled the historizing checkbox of the corresponding DataVariables and changed the access rights, that had 50% success, the access rights were changed, checking the checkbox doesn't change anything in the generated code.
As second step i tried to create one HistoricalDataConfiguration object that should be shared across all instances of my objects, the only way to model this was to add one HistoricalDataConfiguration object to my ObjectType with a HasComponent reference, thats not like in the tutorial but i could live with that. Then i tried to make the references of the type HasHistoricalConfiguration from the DataVariables to that object, but as soon as i confirmed with the OK-Button the reference was simply gone.
According to the book "OPC Unified Architecture" recommended on your website it is a good idea to use a HasModelParent reference for that HistoricalDataConfiguration object, because i want to use only this one object of the ObjectType node instead creating one for each instance, but this type of reference is not selectable in UaModeler.
Now my current solution is to manually edit the generated code, remove the unwanted HasComponent reference, remove the creation of the HistoricalDataConfiguration object in the instances, add all missing references and enable historizing on the DataVariables. This is not really a solution, it works for now as long as this project is more or less just a test, but as soon as we are going to use this more productive this is going to be a tedious and error prone work.
Are the issues going to be fixed soon? Or are these features instead of bugs? How can i use UaModeler to enable historizing in the data model?
UaModeler and historizing
Moderator: uamodeler
-
Support Team
- Hero Member
- Posts: 3072
- Joined: 18 Mar 2011, 15:09
Re: UaModeler and historizing
Hi,
We are still discussing the best solution for the mentioned issues but we want to inform you about the current status of the discussion.
There are three different, independent issues
(1) Creation of HistoricalDataConfigurationType as child of a variable
The ObjectType HistoricalDataConfigurationType and the ReferenceType HasHistoricalConfiguration are very special because they are used to add an Object as child of a Variable. With the HasComponent reference this is would not be allowed.
The list of Children in the UaModeler enforces these rules by just allowing Variables as children of Variables. Allowing HistoricalDataConfigurationType with the reference HasHistoricalConfiguration would be also a valid child but we need to find a simple way to allow this special use case without confusing users for the common use cases.
(2) Share one instance of HistoricalDataConfigurationType across different variables
You are right that there was a HasModelParent reference defined in OPC UA that would helpful for the solution of this issue. But this reference was deleted from the OPC UA specification since there was no use case in a real server. Therefore it cannot be selected as reference in the UaModeler.
Since the information provided through HasModelParent is useful for modelling tools, the OPC UA specification kept this capability as part of the UaNodeset XML schema that is also used in the UaModeler. But it is only used internally at the moment and is not exposed to the user of UaModler.
We will come up with a solution to solve (1) and (2) but need to do some more prototyping and evaluation to find the best solution.
(3) Setting of Historical Access specific attribute values
Setting of historical access specific flags in attribute values like AccessLevel and Historizing must be reflected in the generated code. This is an issue in the template code for the C++ SDK in the UaModeler that will be fixed with the next release.
Best Regards,
Unified Automation Support Team
We are still discussing the best solution for the mentioned issues but we want to inform you about the current status of the discussion.
There are three different, independent issues
(1) Creation of HistoricalDataConfigurationType as child of a variable
The ObjectType HistoricalDataConfigurationType and the ReferenceType HasHistoricalConfiguration are very special because they are used to add an Object as child of a Variable. With the HasComponent reference this is would not be allowed.
The list of Children in the UaModeler enforces these rules by just allowing Variables as children of Variables. Allowing HistoricalDataConfigurationType with the reference HasHistoricalConfiguration would be also a valid child but we need to find a simple way to allow this special use case without confusing users for the common use cases.
(2) Share one instance of HistoricalDataConfigurationType across different variables
You are right that there was a HasModelParent reference defined in OPC UA that would helpful for the solution of this issue. But this reference was deleted from the OPC UA specification since there was no use case in a real server. Therefore it cannot be selected as reference in the UaModeler.
Since the information provided through HasModelParent is useful for modelling tools, the OPC UA specification kept this capability as part of the UaNodeset XML schema that is also used in the UaModeler. But it is only used internally at the moment and is not exposed to the user of UaModler.
We will come up with a solution to solve (1) and (2) but need to do some more prototyping and evaluation to find the best solution.
(3) Setting of Historical Access specific attribute values
Setting of historical access specific flags in attribute values like AccessLevel and Historizing must be reflected in the generated code. This is an issue in the template code for the C++ SDK in the UaModeler that will be fixed with the next release.
Best Regards,
Unified Automation Support Team