CD1102_CloudControl

Cloud Control

Feb. 8, 2011
The Shared Resources of Cloud Computing Could--and Should--Change the Way Automation Specialists Use the Tools They Call on Daily, Avoiding the Need to License Each Vendor’s Software Solution Separately.
By Jeremy Pollard, CET

Definite-purpose devices have populated our software and hardware toolboxes for decades. These devices perform invaluable services for us at just the right time. Ask a guy about stuff in his garage, and he'll say, "I might need it someday."

In the automation business we have many tools we call on daily, such as HMI and PLC development environments, spreadsheet and document-processing software, and various utilities to get our work done.

We've been nailed with multi-purpose devices in our world. PLCs, PACs, safety PLCs and HMIs can talk to anything, and OPC interfaces allow that to happen. I wonder when that might change. The past is a good place to look, since we tend to rely on the path we just traveled, and thus lack the interest to innovate, but maybe this time is different.

The cloud might change it all. Business models could adjust how we work. Program features and functions could determine how we use some of these tools.

I remember having a conversation with Rich Ryan from Rockwell Software some 15 years ago. We discussed where automation companies were headed. He was adamant about automation companies becoming I/O vendors, and the computational side would become a commodity business. We also talked about the software component of the business.

I worked for a PLC software developer, so I knew that biz, as well as the troubles of support, costs, etc., it brought with it. I also have a tie to the education world. Then, of course, there are the costs that come into play, in addition to learning curves for everybody that uses these tools.

I asked Ryan how feasible it was to have a component-based programming product. For instance, you pay $1,000 for the platform, then $100 for feature packs such as PID or analog control, and extra for sequencer control monitoring. So, if you didn't need something, then you didn't pay for it.

He talked of having a feature-based purchase system, similar to the good ol' days of third-party software developers. Remember when online and offline licenses were separate? It might have gone a bit deeper than that, however, such as having documentation database tools as an add-on feature.

Then I thought about the software being a bit smarter than that, so it "knew" the features it needed, based on the PLC program. That would have been tough back then. But now? Not so much. Think of it as an à la carte menu.

If your program uses standard instructions, the software will know this and request the proper licensing from the vendor's website. The software you use at that particular point is definite-purpose software, yes?

Today you might use a Rockwell SLC processor program, and tomorrow an Omron version. You need the development software for both, but they don't have to be local. Maybe there will be a common software platform that will interface with all devices. Sorry, I digress.

This innovation can remove the multi-purpose moniker of our development software, and create a definite-purpose platform for everyone. Maybe it's just for the troubleshooting and monitoring part. You could think of it as an option page that gets checked based on how you use the software. If you don't use the offline functionality, then you don't rent it. If you need the forcing functions, then you rent that option for as long as you need it.

It's the cloud that allows this to happen and software costs for the users would drop. OEMs would not have to have everyone's software product licensed, as well as support agreements.

When a user connects to a vendor's processor, he would connect to the cloud and fire up the development/online/troubleshooting software in real time, and not worry about much.

You might think this far-fetched, but I believe it can and will happen in some form. Look how long it took to have the program documentation resident in the device itself. But it happened.

This should happen, too. And it should be browser-based.

Jeremy Pollard has been writing about technology and software issues for many years. Publisher of The Software User Online, he has been involved in control system programming and training for more than 25 years.