Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

DPS is here to help.


Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

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

A Smart RTU: Your Alternative to Programming Logic Controllers

By Andrew Erickson

August 1, 2022


If you're at all involved in the SCADA world (especially if you're new), you probably spend time thinking about the time and/or expense required to program PLCs.

Some companies choose to maintain in-house experts who know exactly how a PLC works and how to program it. Others outsource the process entirely, which tends to consume your budget quickly.

In either case, you're devoting resources to PLC management that might not actually be necessary. What if there was a more efficient way to think about your input and output devices? You'll probably still need at least some PLCs, but you can eliminate the need for many of them by seeking an alternative.

A modular PLC requires programming

PLCs are also known by their full name: Programmable Logic Controllers. As that name implies, the job of programming logic controllers is a necessary step in any deployment.

That's required because SCADA systems are often built from the ground up with custom programming. The PLC is just an input and output device. The PLC programming language, whether ladder logic or something else, is where the "thinking" actually takes place to accomplish your industrial process goals.

Compare this to something like a personal computer. There's a chance you might know how to program, but the average PC user hasn't. That's because there's enough of an interface (built into the OS and any installed applications) that you don't have to write actual code yourself.

The comparison between a PLC and a PC is a good starting point toward understanding another important fact:

RTUs don't require programming, only configuring pre-installed functions

Unlike the PLC requirement to program the logic controller, an RTU ships with factory-installed functions. At DPS, for example, we build everything into a web interface. This is very similar to the interface you've used if you've ever set up a network router or printer or similar device.

Sure, there will be some work to do. You'll have to name what each contact-closure input is, for example. You'll need to write simple if-then formulas if you want to set up an automatic response to an input.

The difference is that you won't have to program the fundamentals of your industrial control system yourself. The basic, obvious stuff will be taken care of for you. You won't have to build ladder diagrams, etc.

Know which tool to choose for different situations

Although I manufacture and sell RTUs, I fully admit that they're not the optimal choice for every scenario. If you're working on very custom elements of your process control system, you actually should prefer to use plc systems to meet that need.

What's important in this scenario is that you're actually getting a benefit when you write custom code (using a language like IEC 61131-3, etc.) and store program instructions inside a PLC.

Just don't forget that, for "customized but not one-off" applications, you're likely better off with an RTU-based controller instead.

Choose web interfaces to gain independence from specific operating systems and IT headaches

About 20 years ago, we (and many other manufacturers) were pretty heavily standardized on Windows-based applications for RTU configuration. That was true because "the web" was still pretty young, and the low-powered RTU processors of the day really couldn't handle it. There were also plenty of RTUs that were not yet LAN-enabled.

Now, of course, web interfaces are everywhere. Nearly every wired-LAN or Wifi-enabled device has some kind of interface you can use for configuration. Smartphone apps are also common.

This has the convenient advantage in a B2B context: You don't have to fight your corporate IT department and/or firewall security team to install and use a piece of software.

That's why, at DPS, we've built absolutely everything associated with the configuration and use of our equipment into the web interface. You log into the "Edit Mode" to set up the labels, options, and logic. You log into the "Monitor Mode" to see what's happening. Of course, you're more likely to send data to an HMI in a SCADA context where you also have PLCs deployed.

No matter what you decide for PLC vs. RTU, choose reliable hardware

Some things are true of all electronic devices: you want to choose something that will withstand a bit of real-world chaos. When choosing an RTU or PLC or anything else, there are a few key items to look for.

First, choose devices with a wide-range power supply. Sure, you might think that you don't need it if you run entirely on 110 VAC or -48 VDC or some similar standard. It never hurts to have some extra leeway during an overvoltage or undervoltage incident.

Double-check with your vendor/manufacturer before deciding or buying anything. As an example, many of our NetGuardian RTUs at DPS were rated for "-48 VDC" nominal voltage for years.

After additional review and testing, we were confidently able to certify those same devices to also work on -24 VDC nominal voltage. This wasn't a hardware change at all. We simply engineered enough resilience that our 48-volt design also ends up working on 24 volts.

Second, look for an industrial temperature rating from your equipment manufacturer. When you consider the industrial process that has you tasked with (maybe) programming logic controllers, there are liable to be some hot (or maybe cold) temperatures that must be survived. An industrial temperature rating at DPS tends to have an effect on device price of less than 5%. That's usually something you can justify if it prevents even one failure every few device-years.

Choose the right I/O size option for your RTU

In my years of working with people who start a project in a traditional SCADA frame of mind, I've learned that I/O capacity is something to focus on. It's not obvious at first, but this isn't something you think about as much when choosing and programming PLCs.

The reason for the distinction is that most PLCs are fairly small. A PLC design with one contact-closure input and one relay output is fairly common. Some have a few. Instead of choosing larger PLCs and benefitting from an economy of scale, you're more likely to just install lots of them.

When you make the move to RTUs, you suddenly have a lot more latitude when choosing capacity. As a reference, we have RTUs at DPS that have just 4 discrete inputs. Others have 64 or more. Because of this, we'll always ask you what you're trying to accomplish so that we guide you to the right model.

Give me a call to discuss your PLC plan

I certainly don't mean to discourage you from ordering PLCs. They are absolutely the correct option for many projects.

I only want you to be aware that, in some cases, you might find an RTU to be a superior solution. You just need to know how to recognize each situation.

I'm happy to go over your project and help you apply some of the principles I've written here. We can review your project goals and determine which device type you should install to accomplish each goal.

To get started, just give me a call at 559-454-1600 or email me at sales@dpstele.com. (Don't worry. Our salespeople are smarter than most people's engineers.)

Andrew Erickson

Andrew Erickson

Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...