Sponsored Content from Software Toolbox
I have multiple brands of devices, do I need multiple OPC Servers?
Maybe. It really depends on the device types and whether they are using the same device level protocol or, if different protocols, using protocols that are available in a single OPC server product. For example, if you have multiple flow meters that all use Modbus or can support Enron Modbus, then you could use a single OPC server. If you are using PLCs from different vendors, and maybe a flow metering package from another vendor, you likely will be dealing with different device level protocols. However, you may be able to obtain an OPC server that has plug-in drivers that may be licensed separately, but actually run in the same OPC server application. Implementations of this nature are common.
My OPC server doesn’t support UA yet but my OPC client does, what do I do?
We also hear the question reversed as “My OPC client supports OPC DA only but it needs to talk to an OPC UA server”. The solution to both scenarios is the same. You need an OPC gateway applicationthat can convert from OPC DA to UA at both the client and the server level.
Some people also call this an OPC wrapper or OPC UA wrapper, or OPC DA wrapper. They key is that you need a solution that is fast, easily configured, and supports the necessary OPC UA security features that you plan to use.
I need to share data between a control system and a metering package or between 2 different control systems that have OPC servers
What you need in this case is an OPC Bridge application. An OPC Bridge application is a product that is an OPC client, and thus can talk to OPC DA and OPC UA servers, and has functionality to allow you to:
- Create mappings between tags in each control system through a visual user interface
- Define whether data flows one direction or both directions between the systems
- Define changes such as scaling to be applied to the data values if required
- Bridge to non-OPC data sources or destinations, if required, for your application
- Bridge between different OPC data sources, including OPC UA to OPC DA and vice versa
Where should my OPC servers be placed in my network security model?
First, remember that when we say OPC servers, we’re talking about the software, not necessarily the hardware on which they are running. Often those “hardware” servers are virtual these days, and the choice of location of those servers needs to involve a discussion with your IT department, OT team, and cybersecurity team.
The answer to the question is really “it depends”, and there are too many possible combinations of factors and scenarios to discuss here in a responsible fashion so, instead, we’ll point out some of what you should consider, and provide a couple of examples.
Factors to consider include:
- Who needs the data from the OPC servers and where are those applications running? Are they on the public internet? Are they in a business layer? A DMZ layer in the network? Or are they in a totally isolated Automation layer?
- Do different data sets have different user needs and, thus, access is needed at multiple layers?
- How often do they need the data?
- Is some of the data read only and some read/write?
- How critical is the security of the data?
- What are your corporate IT standards?
To be sure, there are more factors, but most conversations we have start there. More and more we are seeing the need to be able to share data securely, rapidly, with more and more parties, which presents a cybersecurity challenge. There are unique tools available to share data without having to open inbound firewall ports, and without significantly sacrificing performance.
Probably the most common scenario we see is to place the OPC servers in the Automation Layer of a network, as close to the data source as possible, to insure performance and to make data available rapidly to other applications that reside in the Automation layer. Then, using tools for tunneling, including OPC UA, the data is taken to a DMZ layer and then up to the business layer, with the DMZ providing the necessary filtering and isolation.
We also are asked this question in the context of the Perdue enterprise reference architecture and the layers 0 to 4. We sometimes also are asked the question in the context of the Perdue ICS model. The answer unfortunately is still “it depends”. Typically, we see the OPC servers residing at Level 2 or Level 3 in the Perdue Enterprise model and, in the Security Cell/Area Zone, level 1 or level 2, in the Perdue security model. What matters most is that you involve all the relevant stakeholders and their needs in your decision.
I need redundancy in my OPC system, how do I do that?
This is another deep topic, with lots of questions before there are answers. First, you must define what you mean by redundancy as, taken to deep extremes, it can apply to every component of the system that touches the OPC server or that the OPC server depends upon. We’ve written about this topic at length, so we suggest you read about the OPC redundancy considerations you need to keep in mind when defining what redundancy means to you.
The most common scenario we hear about is people wanting to have redundant OPC servers, specifically OPC UA servers with the growing adoption of OPC UA. Some HMI/SCADA client applications will have redundancy switching and monitoring of OPC data source health built into the product, so first check there. If they don’t, then you’ll need an OPC redundancy switching tool. This is another area we’ve written about in more detail that you can read about on the Software Toolbox website.
Do you still have questions about OPC?
If you haven’t read our original FAQ article, do that first, and then if you have further questions, contact us by submitting your question to us online.