You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OPC has spent many years listening to the requirements of industrial users working in many different domains with many different requirements and OPC UA incorporates this feedback. The result today is a large specification which many find overwhelming.
For this reason I see value in developing a simplified API that would address the needs of specific use cases, however, the set of uses cases that this API is designed for needs to be clearly defined and more importantly, the use cases that will not be addressed by this API need to be mentioned.
If this effort is simply an effort to rewrite OPC UA then you will end up with something that is just as complex after many years of effort and the users will be much worse off.
And look what needs to be stripped out to meet the desire for simplification. For example:
Remove DiagnosticsInfo
Map UA DataTypes to JSON primitives or JSON schema references;
Replace Create/ActiveSession with HTTPS sessions.
Replace GetEndpoints with something more suited for cloud based operation.
Anything else that the WG would like to see removed.
The approach of starting with the OPC UA architecture and removing stuff that is not needed means WG benefits from all of the knowledge and experience that is captured in the OPC UA specification. I feel this would allow the WG to reach a solution faster than they would if they wanted to rebuild everything from scratch.
The text was updated successfully, but these errors were encountered:
OPC has spent many years listening to the requirements of industrial users working in many different domains with many different requirements and OPC UA incorporates this feedback. The result today is a large specification which many find overwhelming.
For this reason I see value in developing a simplified API that would address the needs of specific use cases, however, the set of uses cases that this API is designed for needs to be clearly defined and more importantly, the use cases that will not be addressed by this API need to be mentioned.
If this effort is simply an effort to rewrite OPC UA then you will end up with something that is just as complex after many years of effort and the users will be much worse off.
One proposal I think is worth exploring is to start with OpenAPI definitions of OPC UA:
https://webapi.opcfoundation.org/swagger
And look what needs to be stripped out to meet the desire for simplification. For example:
The approach of starting with the OPC UA architecture and removing stuff that is not needed means WG benefits from all of the knowledge and experience that is captured in the OPC UA specification. I feel this would allow the WG to reach a solution faster than they would if they wanted to rebuild everything from scratch.
The text was updated successfully, but these errors were encountered: