Software Programming Gets More Complex

The 'Internet of Things' Lags in Getting to the Process Industries, Especially to Users Trying to Program and Control Small Applications

By Steven Braun

When software programming took off in control and automation in the early 1980s, the idea was that we soon wouldn't need system integrators because control systems would be smart enough to take care of themselves.

Well, the desktops, laptops, smartphones and tablet PCs all got smart and intuitive. But I'm now looking at the latest PLCs and software, and they're still mind-bogglingly complicated to set up and program. And who can afford $4,000+ just for programming software? Hardware costs have come down, but they're often dwarfed by the costs of software and programming. In one of my typical applications, it's not unusual to spend $10,000 or less on hardware and $70,000+ on software and revisions — and those costs don't seem to end.

Consequently, if I go to a small, public water utility to develop a SCADA system that can be accessed anywhere by its one operator, I can't link to it with iPad without blowing that utility's budget. Instead, I still have to use the same tools that I've used for 35–40 years to turn on a pump. The basic engineering process of setting up I/O points, configuring ladder logic, building the HMI, and developing the project is the same as it was in the 1970s. So where are the mainstream, IT-based tools for networking and control?

For instance, I've been working with Black Creek Hydro in Bellevue, Wash., to overhaul its little, 4 MW hydroelectric plant that's halfway up Mount Si in North Bend, about 20 miles east of Seattle. The upgrade included mechanical changes, such as adding restrictors to the nozzles that go to the Pelton wheel. We also retained the plant's original GE Series 90-70 controller, but threw out its old PLC programming code, and replaced its serial communications with a TCP/IP module and Phoenix Contact's Ethernet switches and an mGuard firewall.

The old GE LogicMaster DOS-based control software was replaced with GE Proficy Machine 7.0 software, and we installed a 12 in. GE View panel. We also added a high-speed DSL line, so the powerhouse could communicate via Ethernet with the plant's intake 1.5 miles away. This allows the intake's GE Series 90-30 PLC to look like a remote I/O device on the new network.

However, I noticed that, though Proficy looks nicer and generates better reports, it's still time-consuming to program and troubleshoot. If a software or graphics routine doesn't work, it still takes hours to figure out what's wrong, reprogram, reload, and get it going again. Nothing's really changed. It's the same way we did it 30 years ago. I think we could be just as productive now with our old LogicMaster software because it had so much less overhead and the PC didn't crash as often.

This is why I've been trying to develop the iPad to allow operators to connect to their field RTUs, so they don't need a $1,000 HMI at each field station. But I still haven't been able to make an iPad into a client that can be networked to reach their servers. Tablet PCs put all kinds of windows and apps into your hands, but they still can't connect to databases, PLCs, HMIs or other servers without spending a boatload of money.

Likewise, GE View panels publish web pages, but they use Flash and Javascript, which can't be used on iPads yet. GE Intelligent Platforms says its Cimplicity and iFix software have one-click access to web pages published on PCs, but on a recent project using Allen-Bradley RSView32, we found it would take $35,000 to convert the graphics to Cimplicity. And Red Lion has HTML pages that work great on the iPad, but its single server means all users are forced to look at the same display. We want to build graphics and create web pages without coding in HTML, PHP or anything else. We want to do it once for the SCADA master, and use iPads in the field for access. No one offers it yet.

There are more than 400 small, public water utilities in Washington State alone, and they all need more capable networking to reach servers and control databases, but they can't afford thousands of extra dollars for HMIs and graphics. Unfortunately, big suppliers seem to want only big customers, and aren't interested in talking to small towns. So, sure, there's an "Internet of Things," but it's totally lagging in getting to the process industries, especially for users trying to program and control small applications. Luckily, there are some other ways to network and move data and functions to where people can use them. Stay tuned for Part 2 in the Q1 2013 issue.