MATLAB: OPC Toolbox Sizing and Limitations

opcopc toolboxplcsimulink

I am wondering if there is any additional sizing and limitation information available for the OPC Toolbox.
The example application is using Simulink to run pseudo real-time simulation of machines in an industrial automation setting. Using OPC Read and Write commands, the application communicates to multiple Programmable Logic Controllers (PLCs) through a single OPC Topic. This tests the control strategies of the processor with simulated hardware. The OPC server in this example is local to the instance of MATLAB, but it may be advantageous to run it remotely in the future.
I have so far used these documents as resources:
This is the information I understand so far and have applied to reduce computational overhead:
  • Asynchronous read/write operations are better than synchronous ones
  • Longer read/write time intervals are better than shorter ones
  • Acceleration modes helps marginally – however, I did not use them as some subsystems did not work when acceleration modes were enabled
  • No Scope blocks
  • Used a fixed-step solver (preferred anyways)
  • Longer solver step times are better than shorter ones
  • Set the pseudo real-time violations in the OPC Config Real-Time block to None
  • Closed nearly all other applications on the virtual machine and ensured enough resources were allocated for MATLAB/Simulink
Here are some of my questions regarding sizing and limitations. If there is additional information available that was not asked for, that would be greatly appreciated.
  • Given a fixed amount of data per item (assume most are 4-byte tags), is there a way to calculate how much "bandwidth" is consumed for each tag, given its communication settings (sync/async, read/write time interval, etc.)?
  • Why does increasing the model solver step time improve the OPC pseudo real-time performance? I would have assumed that evaluating the model and sending/receiving data through DCOM are mutually exclusive.
  • Why does navigating the model subsystems (clicking in and out of them) negatively impact pseudo real-time performance? I assume the reason is similar to why Scope blocks negatively impact model performance more broadly.
  • Per the second article: How does the guidance on multiple groups apply to Simulink? By "group", does that mean number of items configured inside an OPC Read or OPC Write block? If so, the article mentions having 100 items per group versus 1000. Is there any recommendation for the maximum number of items in a group?
  • Are the resources available for the OPC Toolbox fixed, or may they be expanded through running of additional services, multithreading, etc?
  • Not particularly about sizing, but is it possible to programatically enter the OPC shortcut for each Item ID in an OPC Read/Write block as opposed to manual entry?

Best Answer

Reposting the answer to the question I received via email:
Hi Roger,
Here are some answers to your questions:
  • Given a fixed amount of data per item (assume most are 4-byte tags), is there a way to calculate how much "bandwidth" is consumed for each tag, given its communication settings (sync/async, read/write time interval, etc.)?
No. This is typically not material either; the processing time is related to the server needing to manage large amounts of data, how it manages that data (one group is slower than many groups) and networking bandwidth is typically sufficient all but massive data transfers.
  • Why does increasing the model solver step time improve the OPC pseudo real-time performance? I would have assumed that evaluating the model and sending/receiving data through DCOM are mutually exclusive.
OPC reads and writes happen in MATLAB, so they block the simulation even in instances where asynchronous read/write operations move the data from the server to the OPC Toolbox client. Increasing the model solver step time simply gives the OPC Toolbox blocks more time to fetch the data from the local OPC client and translate that to Simulink data.
  • Why does navigating the model subsystems (clicking in and out of them) negatively impact pseudo real-time performance? I assume the reason is similar to why Scope blocks negatively impact model performance more broadly.
OPC blocks execute in MATLAB. Navigating still blocks the MATLAB execution thread, just like Scope blocks do.
  • Per the second article: How does the guidance on multiple groups apply to Simulink? By "group", does that mean number of items configured inside an OPC Read or OPC Write block? If so, the article mentions having 100 items per group versus 1000. Is there any recommendation for the maximum number of items in a group?
Each OPC Read or OPC Write block is a separate group. So yes, to the second question in this bullet. There is no general guidance for the number of items per group. It is too dependent on the rest of the simulation to provide any form of guidance except that one OPC Read for 100 items is less efficient than breaking that into multiple groups with fewer items.
  • Are the resources available for the OPC Toolbox fixed, or may they be expanded through running of additional services, multithreading, etc?
Since OPC client operates through the MATLAB single thread, the only way to extend this is to split the simulation across multiple MATLAB sessions.
  • Not particularly about sizing, but is it possible to programatically enter the OPC shortcut for each Item ID in an OPC Read/Write block as opposed to manual entry?
Yes, you can use
>> set_param(blockPath, ‘itemIDs’, csvListOfItems)
Where csvListOfItems is a comma-separated list of ItemIDs. Here’s an example showing how to set two items for the OPC Read block of the OPCBlksTutorial model from the examples:
>> set_param("OPCBlksTutorial/OPC Read","itemIDs","Bucket Brigade.Real8, Random.Real4")
Related Question