MatrikonOPC OPC Exchange


You Say SKAYda, I say SKAHda

Posted on June 14th, 2007 by Eric Murphy

Let’s not even bother with the pronunciation of SCADA, a better question is what do you mean by it?   Dale over at Digital Bond brings up the topic in a recent post, and concludes with let’s not worry about the details, and just get the ‘SCADA’ systems secure.   The same could be said for the term SCADA when dealing with OPC.   OPC is a standard, and OPC is OPC regardless of what control system it is being used on.   However, when considering the overall architecture of a system, it is important for vendors to understand the context of the SCADA system when determining which OPC server is the right choice.

Standards like OPC go a long way for setting certain expectations and rules for clients and servers to follow.   But that still doesn’t mean all OPC products are created equal, or designed for every scenario.    Think of the expectations you take for granted when considering which type of car to buy.    You expect it to have four wheels, windows, brakes, lights, etc.   You can expect to get in and out, get it running and operate it without any specialized training.   You can expect every service station to have the appropriate fuel and accessories you need at reasonable cost.  (I wouldn’t get into what is considered a reasonable fuel price these days).  Yet even with all these standard things, there are still numerous things that separate one car from another.   Manufacturer,  style, price, speed, power, comfort, cargo space, etcetera, ad infinitum ad Nausea.    Same holds true for OPC servers, and your definition of SCADA is important.

To some SCADA means any system of an HMI and a PLC.   Almost every HMI and PLC have an OPC server available for them.  But even this has important permutations.

  • Is it a reliable, plant-based environment with high up-time and bandwidth, or is it an geographically disperse telemetry system with dropping communications and restricted bandwidth?  (I talked about these differences on my last post, OPC Wireless)
  • Is it continuous process or discrete manufacturing? Is it a large set of high frequency items that are fixed and not likely to change very often, or is it multiple sets of lower frequency items that will change with each batch or product change?   How does the OPC server deal with on-the-fly item changes?
  • Is the PLC running on an assembly line, like an Allen-Bradley, or part of a safety system like a Triconex?  Same OPC, big difference in performance expectations.
  • Are the client connections a single power-user like a Historian with thousands of points in one or two client connections, or many multiple ad-hoc client connections with dynamic points?   The OPC specification handles both cases, but how does the Server deal with the underlying system?

The list goes on.   The key thing to remember is although OPC sets the standard for many things, there are still many things that ‘separate the wheat from the chaff’ among OPC products, architectures and vendors.   OPC UA goes farther than the current specifications by setting the bar for redundancy, security and other items, but it still can not cover every difference.

CD players, Universal Child Restraints and Air Bags are becoming standard in vehicles, but there are still many variables that are not.   So what’s handling the communications in your ‘SCADA’ system, a Porsche 911 or Volkswagen Rabbit?

Leave a Reply

For spam filtering purposes, please copy the number 6396 to the field below: