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.
02/22/2022
Offline
Randy Armstrong said
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.
So you say that most of reference.opcfoundation.org regarding the companion specifications is outdated? E.g. the machinery job-management online documenation and the coresponding PDF (release-date initial released 2024-02-16, bug-fix 2024-05-04) still includes the profiles.
Or does this “only” apply to the OPC core specifications (documents everything below 10000-100)?
Something to keep in mind within your strategy:
- public accessable
- reference.opcfoundation.org
- the nodesets at https://github.com/OPCFoundati…..UA-Nodeset
- profiles.opcfoundation.org
- does limit informations depending on the login state (if not logged in, a user sees only the core topics – differ this also regarding the member-state?)
- is not up to date – e.g. machinery job management is not available, but was released twice within a year.
- DB-entries release-state differs from the nodeset release-state -> everything of machinery BB is marked as RC, on the other side the documents are official released.
Machinery result-transfer contains only drafts, process-values is empty – both of them are more than one year official released. - so from that what I can see this is more than one year behind the other sources an/or has contradictory content
- nodesets are the core – every tool builds up on this nodesets or has some direct links to the github. there are no “co-files-features” for modeling tools, SDKs, code generators or PLC-IDEs.
And based on your answer to this topic https://opcfoundation.org/foru…..generator/ even the documentation is some sort of auto-generated from the nodesets. - From the PO/project-leader/buyer perspective I would define server/client requirements based on the given profiles from a companion specification – this is the only way to get a “conform to xy” so that the clients and servers can mostly rely on this. A companion specification working group defines this “contracts” so they could be placed inside the nodeset.
This could be different for the core set – but even there I would define a range of functions in the form of profiles. If I expect PubSub or alarms/conditions as a client for all machines on my store floor, then this would be included in a functional specification accordingly.
That’s was the documentation https://reference.opcfoundatio…..5/docs/4.5 defines.
From the user experience perspective I would recomment not to separate things, that belongs together and aim to a single-source-of-truth (filtering out is mutch easier than crawling and aggregating).
My experience in creating a Companion specification tends to involve a lot of manual work, various individual documents and correspondingly many sources of error / or contradictory content.
05/30/2017
Offline
To clarify: many CS make sure the current profiles are in the released specification and are not changed between releases.
I will take the suggestion to add the profile sets to the nodeset to the WG, however, it still would be a distinct schema.
Moderators-Specifications
Moderators-Companion
Moderators-Implementation
Moderators-Certification
Moderators-COM
02/24/2014
Offline
If you have a companion specification that is out of date in the profile database, please raise the issue with the Companion Standard chair/working group. It is each working groups responsibility to ensure that Profile/ConformanceUnits in the database are current.
Note: they may differ from what is published in a specification if they are newer.
Nodeset are tied to a specification version, which are not updated that frequently, profiles are intend to be updated more frequently (when an issue is discovered or a new use case requires something different or a security patch is released.)
ConformanceUnits can also be reused and grouped into new Facets and Profiles – so I would be cautious about adding Facet/Profile t a Nodeset. We already linked functionality to ConformanceUnits in the Specification.
Paul Hunkar - DSInteroperability
1 Guest(s)
Usage Policy