https://opcfoundation.org/wp-c.....ise-EN.pdf

Role and Permissions are as flexible as the could possible be.

Permissions are set on a per Node basis:

https://reference.opcfoundatio.....5/docs/5.2

See Role definitions:

https://reference.opcfoundatio.....v105/docs/

I’ve been working with OPC UA for a while now and have had a positive experience with its flexibility and broad support across different industries. However, I’d like to suggest a few enhancements to the security features that could help increase confidence and ease of use for developers and end-users alike.

Firstly, while OPC UA offers encryption and authentication, I feel that integrating more modern and customizable multi-factor authentication options could make a significant difference, especially in environments with high-security demands. Having support for biometric or hardware-based authentication methods as part of the standard would make the system more robust.

Additionally, I think the management of user roles and permissions could be made more flexible. It would be helpful to have finer control over what specific data points a user can access, along with auditing capabilities that provide clear logs of who sap sacaccessed what and when. A more granular control mechanism would be useful in critical industrial and financial applications where data sensitivity is paramount.

Lastly, I would like to see more comprehensive documentation and best practices around security configurations. Though the available resources are helpful, a clear, step-by-step guide on how to implement the highest security standards with OPC UA could save time and prevent common mistakes, especially for those new to the protocol.

Thank you for considering these suggestions. I look forward to hearing your thoughts on these ideas.

thank you for your feedback and suggestions for improvements. We are already in the process of updating the product catalog which will bring a lot enhancements. As much as I know all your suggestions are already part of our improvements list and therefore are being take care of. But I will double check just in case.

Some of the information you are looking for are already part of a product description. But the important thing here is that the product description is open to the vendor itself. So it is the vendor who decides about the detail level being provided. Nevertheless, the certification information of course is being provided by the OPC Foundation. If a product is or has been certified you'll find its information including the supported profiles (e.g. Historian), the specification version (indicated by the CTT Version) and other details.

I hope this helps for now.
Regards,
Alexander Allmendinger

Improve the search function with this additional information.

Suggested info: OPC Classic, OPC UA, specification version, certified/not certified, historian functionality, ...

This allows customers to select easily the right tool based on real requirements.

The member list has been removed entirely.

We are looking at automatically assigning a non-email profile name on sign up.

It won't change existing accounts.

It the profile editor will be fixed as soon as possible.

The member list should be removed entirely.

Forcing users to specify a username at signup would have significant side effects for the main website.

I want to point out two things concerning privacy:

• Using mail-adresses as usernames in this forum is one topic that has been adressed as problematic before. However the solution that was proposed doesn't work anymore.
• The fact that everyone can view all members of this forum is problematic as well. Since everyone seems to get a forum account by default when signing up, you can compile a list of everyone who has ever downloaded OPC specifications - even if they have never posted here.

My suggestions would be the following:

1. Fix the "Edit Profile" function
2. Hide the list of members that is currently exposed to the public.
3. Force choosing a username at signup and use this as in the forum after user opts in to participate here.

Let's have a discussion about this.

Cheers

Arno

Alarms are different from data even if they are related. Many applications are dedicated alarm clients and they want the alarms and not the data. Other clients only care about the data. Furthermore, alarms are are complex when data can be simple. This means the subscription/monitoring parameters are usually different so it makes no sense for both sets of information the same subscription. What does make sense is metadata that makes it easy to correlate an alarm with a data point when there is a relationship (not all alarms are tied to a single data point). The SourceNode/SourceName should do this.

HA allows clients to request data ordered in the way they want. This is especially important when clients want processed data. Clients do not care how it is persisted but it does mean the server has to be able to sort the data. This is not an issue for the majority of HA server implementations which uses a DB for persistence but I can see it could be a challenge for a server with a simple file based log of data acquired from another system. However, I don't see the value of an API optimized for a subset of possible server implementations especially if this API would then require clients to do more work sorting data that could be easily sorted by most servers.

Thank you for the reply.

I worked with you before and I know that you were having issues on my first point. You were using the reserved bits for status code.

The data structure if I may suggest would be data instance with alarm instance attached (referenced), and for alarms they will have acknowledgements attached (referenced). But for serving data purpose, client should have the parameter to tell server if all the attachments should be instantiated so all the information will served through one package.

On my second point, when a client is subscribing data to get live data, I meant it should get data with its alarm at same time. Not a second read or subscription. Yes I know there are ways to do it but it is awkward. 

On my last data point, by real-time world I mean live data feed 24/7 with potential out of order data. All I'm asking is that client should not care whether it's out of order or not. Server should care and that's internal implementation from client. I should have just one API function to call for persistence, without knowing whether it's backward data or not. In simple words, it should be transparent.

Regards,

Brian

For example, you indicate a desire for a vendor specific status that travels with the DataValue. This can be achieved in OPC UA by creating a structure that contains the value and the vendor specific status. Complex variables can also be created that allow clients to subscribe to raw value if that is all they need while providing the value-status structure.

It is also not clear what you think the alternative to the UA approach would be be? custom JSON objects? why is that different from a UA structure designed to meet your requirements?

You also indicate that you need to connect the alarm to the current value an associated process variable. This should be easy to do with the 'SourceNode' field of the alarm. It is not clear why this field does not let you do what you want.

Your comment about forward or backward data is puzzling. The HA APIs allow the client to chose how it wants to get the data no matter how the server persists. So hiding how the server persists the data is a feature rather than a limitation. I really do not see the problem that you want to solve.

Lastly, what are you calling the 'real time world'? Deterministic networks? If you simply mean SCADA/HMI collecting live process data then your statement does not make much sense since OPC is widely used today in that domain. OPC UA builds on that large installed base.

• Data point status cannot have industry (like oil and gas)custom alarm status. OPC UA status code is pretty generic but industry need to have its own status on top of OPC UA status. For example, level alarm and watchdog alarm status. This kind of status should travel with data value and its timestamp
• Client has to subscribe alarm/data separately and will have difficulty to nail them back together (data with proper alarm status). This is an issue derived from above mentioned issue. We really do not need different subscriptions for live/real-time data and its alarms. For simple alarms (which is only related to single tag. Composite alarms are different matter), they should reside with data. Without it it's hard to implement one simple task - display live data on chart with proper color coding for its alarm status.
• Yes OPC UA has specs for real-time write and historical write for persistence. But why bother? The server implementation for persistence should know whether it's forward or backward data and should persist accordingly. Client should have no knowledge of which API to choose, because server has the knowledge. This is a fundamental mistake for OPC UA spec.

Without these issues addressed, OPC UA will never be prevailing in real-time world.

1. Click "Profile" in the upper-right corner of the forum
2. A series of buttons will be shown, like "tabs"; click "Profile" (displayed horizontally along the top)
3. Click "Edit Profile" (displayed vertically, down the left)
4. Edit your "Display Name" and then click "Update Profile".

Once complete, your display name will be shown. The corresponding hyperlink is Javascript based and does not include your email address, so your email will remain confidential.