Log In
03/09/2015
Offline
Hi,
I’m currently working on an OPC UA interface for a machine and I have a question about parameter consistency. The machine needs about 20 setting parameters (speed, force limits, etc.) that have to be configured before it can be started. These are exposed as normal OPC UA Variables and the client writes them before triggering the start.
What I’m worried about is the following situation: The client updates the parameters one by one (or even in a multi-node Write), but something goes wrong halfway through — maybe the client disconnects, crashes, or a write fails. In that case, the machine could end up with a mix of old and new parameter values.
And if someone then starts the machine in that state, it could run for up to 20 minutes with an inconsistent parameter set, which is obviously not what we want.
So I’m wondering:
- Is there a recommended way to model this in OPC UA?
- Do people usually handle this with a “commit/apply” step?
- Is it better to use a Method instead of writing individual variables?
- Are OPC UA Programs or Job/Recipe models from Companion Specs meant for this kind of use case?
I’d really appreciate any advice or pointers to common practice.
Thanks a lot!
05/30/2017
Offline
Strategies to implement with atomic write/transaction based write operations:
Bulk Update: This approach involves creating a custom DataType that contains all your variables and using a single Update Method call to write them all at once. This is best for simple data models where the serialized size is small and you can provide every value in every call.
Transactions: This approach adds StartChanges, CancelChanges, and ApplyChanges methods to lock the variable set. This is best for complex models that require partial updates, allowing you to change specific parameters without providing the entire dataset every time.
If your configuration is potentially large, you should use a FileType object to handle the upload.
OPC UA Part 12 provides several design patterns for this:
TrustListType: A FileType object used to update Trust Lists in a single operation.
https://reference.opcfoundatio.....cs/7.8.2.1
ApplicationConfigurationDataType: A DataType for bulk server configuration updates.
https://reference.opcfoundatio.....cs/7.10.19
ApplicationConfigurationFileType: A FileType used to upload the configuration data.
https://reference.opcfoundatio.....cs/7.10.20
You can reuse the Part 12 model by inheriting from BaseConfigurationDataType and ConfigurationFileType. While Part 12 supports transactions that trigger automatically on the first update, this is often more complex than you need. For most use cases, a single ConfigurationFileType subtype is sufficient. The Part 12 model would have done it this way if it was re-written today. The need to keep backward compatibility lead to the implicit transaction model.
https://reference.opcfoundatio.....cs/7.8.5.4
https://reference.opcfoundatio.....cs/7.8.5.1
If you are dealing with a simple set of roughly 20 fields, a single Update Method call with a simple DataType is the most efficient choice. However, if you expect your requirements to grow or need to support very large datasets in the future, the ConfigurationFileType model is the better long-term architectural choice.
1 Guest(s)
Usage Policy