You need to see DPS gear in action. Get a live demo with our engineers.
Download our free SCADA tutorial.
An introduction to SCADA from your own perspective.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.Reserve Your Seat Today
Supervisory Control And Data Acquisition (SCADA) and Distributed Control System (DCS) started as separate systems but have grown together. Bandwidth today is so broad that decisions aren't required to be localized at every node. This article is meant to serve as a DCS and SCADA comparison.
SCADA and DCS: you've probably heard these terms if you're involved in managing an enterprise-level network. This article will clear up the differences between the two technologies. Note that we won't define every mentioned concept; it is assumed you already have some experience in working with SCADA/DCS systems. Our focus is on SCADA and DCS differences.
There is considerable confusion today about the difference between DCS ("Distributed Control Systems") and SCADA ("Site Control And Data Acquisition") systems. As you can tell from expanded acronyms above, SCADA includes "Data Acquisition" in addition to "Control". DCS solutions, on the other hand, contains only "Control".
Many years ago, computer networks either did not yet exist or had very low bandwidth. Back then, a SCADA system was the top-level controller for many lower-level intelligent agents. It was simply impractical to have a single system controlling every minute aspect of a system. In this technical environment, DCS devices did most of the detail work and simply reported to (and took high-level orders from) the SCADA system.
Today, computer networks have become fast. They're so fast that there's no practical reason for SCADA and DCS to be separate. That's why they have blurred together into a single monitoring and control system. The choice of name - SCADA vs. DCS - is largely a regional thing
Now that you know the diminishing significance of the DCS vs. SCADA debate in modern times, it's worthwhile to know some of the fading distinctions. First and foremost, SCADA is the preferred technology for monitoring processes and events that are spread out across a large geographic area.
That's mostly due to the second key distinction: SCADA has distributed intelligence. This allows monitoring and control to continue when communication to the central hub has been lost. Conversely, a traditional DCS system would not be able to operate in a geo-diverse scenario like this one. It is too heavily focused on local events and has no ability to temporary endure communication outages.
SCADA has grown to encompass the traditional DCS role of distributed intelligent devices. There are many RTUs to choose from. I prefer to use an RTU with a good blend of common functions. That kind of RTU would be a good option in many different SCADA projects.
With that in mind, let's take a look at the SCADA-Guardian RTU. As I explained above, half of the job of a SCADA system is to monitor remote events and report them back to you. For that task, the SCADA-Guardian has a few different technologies available.
First (and the simplest technologically), are discrete alarm inputs. These are binary inputs that detect the presence or absence of a small current. They are wired into contact closure outputs from remote gear to detect conditions at your remote locations that need your attention. The SCADA-Guardian has 8 of them, which makes it a small-to-medium RTU when measured based on discrete alarm inputs.
It's actually a larger RTU than this capacity implies, however. It simply has more of its inputs used for other, more advanced technologies.
The SCADA-Guardian also has 8 traditional industry-standard analog inputs. These measure either voltage or current input on a continuum.
As you can see, these inputs allow for infinitely more granularity than the "yes/no" information that discrete inputs deliver. Instead of "above tolerance", you'll know that the temperature at a key location is "98 degrees Fahrenheit".
Since analog inputs are so powerful (especially in production, telecom, water treatment, and energy applications), this particular RTU model also has a second method of accommodating an extra 16 analog sensors. This set of 16 uses a technology that has been rapidly growing in the SCADA and broader remote monitoring industries. That new tech is: power and communication for remote sensors over a single wire.
Known as "D-Wire" on DPS Telecom remotes, these sensors can be daisy-chained from one to the other. This is helpful when your SCADA system's sensors must be located a good distance from the central RTU. Daisy-chaining drastically reduces the amount of wire that's required. Each sensor is joined to the previous sensor in the chain (for both data and power).
Finally, don't forget that monitoring temperature is a very common task in SCADA / DCS environments. Well-built RTUs like the SCADA-Guardian will include an ambient temperature sensor built into the RTU itself. This is an easy feature to add that won't add any size outside the RTU chassis. It's not quite as accurate as an external probe, but it's much better than having nothing at all.
There are other factors to consider when choosing an RTU for your SCADA/DCS system. These include looking for a strong, industrial-grade chassis. A powder-coated metal housing is always a good choice.
You also need to ensure that you RTU will be able to withstand any hot and cold temperatures within your operations. An RTU with an industrial temperature range is equipped to handle a span of sometimes hundreds of degrees Fahrenheit. Lesser RTU's must be run in temperature-controlled rooms (similar to a PC workstation's requirements). This limits your flexibility during planning.
Make sure that the SCADA / DCS gear vendor you choose puts its RTUs through rigorous in-house testing. Third-party testing is good, but it's possible for a company to pass through trial and error without really "knowing their stuff." In-house testing permits quick revision cycles and top-notch hardware.
What if you need a minor hardware modification for a special project? Your vendor will know how to make the change without disrupting the device's durability. They can also test the new design quickly without enduring an independent lab's multi-month wait times.
This in-house testing requirement applies to both temperature range and EMI (electromagnetic interference). To test temperature, just an industrial temperature chamber is required. Testing EMI requires a larger anechoic chamber with carbon-construction cones. It ensures that your SCADA/DCS RTU will not output disruptive interference and can tolerate interference from other devices.
Specific Equipment for SCADA/DCS:
See SCADA RTUs with localized intelligence (no programming required)
See Central Masters that govern your entire network