Log In
Home
02/22/2022
Offline
Hi all
We currently facing some issues with NodeSets and the ModelCompiler.
1) By implementing some companion specification, they introduce a lot of datatypes to the adress-space (e.g. DI adds >400Nodes). In most cases not all of them are used within the server-context. For example if we don’t implement the SoftwareUpdateType, we also don’t need SoftwareLoadingType, ConfirmatonStateMachine…. or if we don’t have PubSub, all of the associated elements are unused.
This bloatware increases only code generation time (Modelcompiler, Build-Pipelines…) and and places increased demands on hardware resources. At the end the user will be faced with longer loading/startup time of the server.
The open62541 project introduces a reduced and aminimal nodeset to solve this problem. Is this in general allowed for all nodesets? And if something is not implemented, the data types, variables, objects, events… still appear in the address space under “Types”? Does this not introduce any problems to the client if servers implement different conformance units and expose the optimized adress space with its types within the same namespaceURI (e.g. DI).
2) Is there any machine readable definition about profiles and conformance units available? From this starting point it would be possible to automate the “nodeSet” filtering/transformation, or if modeling-tools are used the user can select the desired conformance-unit so this tool could “add” the needed elements directly. Or in the other way “deselecting” the START-Method from ISA95-JobControl would automatically warn the user that his is no longer comply to “ISA-95 Job Order Receiver Server V2 Facet”.
I was surprised that there is nothing about Part 7 in Part 6 Annex F. This is despite the fact that OPC UA always advertises automation and “machine-readability – generability”. It looks as if everything currently has to be done by hand – which is very error-prone.
Best regards
Patrick
05/30/2017
Offline
The point of adding the CUs to the NodeSets is to allow filtering.
Some work needs to be done to get this to work properly.
02/22/2022
Offline
Randy Armstrong said
Some work needs to be done to get this to work properly.
The goal to allow filtering is clear. But from a user perspective I would select/define the conformance regarding facets. Because a given facet will define the required conformance units.
So the first step would be to add this information (available in the reference documentation and profiles reporting) to the nodeset. Currently this step must be done by hand – if the information is availabel in the nodesets, tools or even the profiles reporting webpage could consume this (single point of trueth). And this should not be a breaking change within the XML-NodeSet definitions.
05/30/2017
Offline
The plan is this:
When the spec is released a XML file similar to a NodeSet with be published with all of the Profiles and CUs.
Applications can load this file and build an interactive list of profiles to pick. It would then generate a list of CUs needed for the selected Profiles.
Given this list of CUs it would now be possible to filter the NodeSets based on the CUs that are already in the NodeSet.
The main work is the algorithm needed to pull in dependencies.
02/22/2022
Offline
Why split up this things? Especially because the information (profiles, facettes, conformance units, node-definitions…)in the PDF release documents of any part or companion specification and on reference.opcfoundation.org are together.
From the user experience it would be easier if the profiles/faccets (with mandatory/optional information) are located within the nodeset:
- A user would be able to select some needed profiles before he begin with the modeling tasks
- NodeSets could directly transformed/reduced within a build pipeline to a vendor specific subset without any thirdparty definition (except of course the definition of the reduction/filter) – something like the open62541 project was done by hand.
- For a server-developer, he will be able to reduce the Import-task and therefore server startup time (e.g. by a pre-processor task).
- …
Most of the workflows and tools are aranged around the NodeSets, so adding some new tags (e.g. profiles/profile, facettes/facette) shouldn’t be a big deal and increase the value of this nodesets.
Test-Case and Test-Definitions are an other topic (currently not in my scope).
05/30/2017
Offline
The profiles are not in the PDFs anymore. The are in the profile DB: https://profiles.opcfoundation.org/
The ProfileSet is an export file for the profile DB.
We are thinking of publishing a export file along side each release of the specification.
Profiles are constructed based on the needs of the applications. i.e. the FX working group creates new profiles that add together different feature sets than the application profiles in the core set.
So you can’t have ‘all profiles in the nodeset’. You can only have CUs.
You do not technically need the profile set export file as long as you have a way to produce a list of CUs.
1 Guest(s)
Usage Policy