Is it time for a new automation architecture?

  • July 22, 2013
  • Feature

By Bill Lydon, Editor

Is it time for a new automation architecture instead of debating over existing ones? I started to wonder about this after reviewing more than 100 comments in our LinkedIn Discussion about my article titled, PLC vs. DCS - Competing Process Control Philosophy.

What is system architecture?

System architecture is the framework that defines the structure and functions of an automation system. The industry started with closed architectures out of necessity and has evolved to some level of open architecture.

What is the goal?

Every vendor has their view about the best automation system, but what is the goal of automation? I suggest that the high level goal is to improve quality, uptime, efficiency, and drive out labor cost of production. Other goals include:

  • Reduce Application Engineering Time
  • Reduce Process Control Configuration
  • Simplify Network, I/O, and Other Interfaces
  • Simplify Enterprise Software Interfaces (SAP, Oracle, etc.)
  • Native Legacy System Interfaces

My Wish List

This is my wish list and I invite other to provide their wish list items in our LinkedIn Discussion:

Native Interfaces

I believe we should be able to eliminate gateways, proxies, and other bridging devices. Because you cannot replace all the equipment at once, having native industrial network interfaces (for DeviceNet, Profibus, EtherNet/IP, PROFINET, EtherCAT, SERCOS, etc.) on controllers is much simpler to configure and maintain. There are a number of suppliers today that support this concept but other suppliers are staunch supporters of their “flagship” protocols and they force users to add gateways and bridging devices that require special configuration steps.

Single Device Profiles

To achieve true “plug ‘n play,” we need a single industry standard profile to add devices to automation systems regardless of native protocol. This is a reality in the computer industry today where adding devices such as printers, scanners, cameras, and external drives has become a “no brainer.” Why can’t we do the same with automation systems?

Controllers

Controllers should be powerful distributed computing engines and incorporate embedded historians, analytics, alarm management, equipment diagnostics, advanced control optimization, and rules engines.  This would simplify the automation architecture and the controllers could perform meaningful data refinement at the information source on the plant floor. The incorporation of higher level functions directly into these new controllers eliminates the need for Level 2, 3 and 4 computers, thereby improving system performance, eliminating bottlenecks, eliminating duplicate databases, simplifying configuration control, and lowering software maintain costs.

Total Production Optimization

The present system architectures are basically “islands” of control that take a great deal of application engineering to build into coordinated plant controllers. Ideally it would be much easier to configure holistic control based on real-time business management goals.

Software Programming & Configuration

An integrated “do it once” environment for functional configuration would tie everything together including alarm logic, HMI, history, version control and other functions. This functional configuration would allow application engineers to deal with production subsystems without having to program basic logic.

Automation Apps Standard

User should be able to use and create application modules that are portable to run on any vendor’s platform. Many vendors have libraries built from their software programming environment but they cannot be shared across multiple vendors systems and controllers. The automation industry should have an Automation App standard allowing users to share applications that run on multiple vendor platforms achieving the portability and open source nature of Android Apps.

Unified Industrial Architecture

The Internet and enterprise computing are driven by open standards. Industrial automation is really a use case of computing that has not matured enough to embrace these concepts. Look at the World Wide Web Consortium (W3C) web site to get an idea of the scope of standards in the computing industry. 

It can’t be done!

I can hear the comments already from vendors saying, “It can’t be done!” Throughout history people protested that new things could not be done. These are some of them:

  • The first successful cast-iron plow invented in the United States in 1797 was rejected by New Jersey farmers under the theory that cast iron poisoned the land and stimulated the growth of weeds.
  • Those who loaned Robert Fulton money for his steamboat project stipulated that their names be withheld for fear of ridicule were it known that they supported such a thing so “foolhardy.”
  • Joshua Coppersmith was arrested in Boston for trying to sell stock in the telephone. “All well informed people know that it is impossible to transmit the human voice over a wire.”
  • Scientist Simon Newcomb said in 1906 just as success for the airplane was in the offing, “The demonstration that no combination of known substances, known forms of machinery, and known forms of force can be united in a practical machine by which men shall fly, deems to the writer as complete as it is possible for the demonstration of any physical act to be.”

What is your wish list?

Please share your wish list items in our LinkedIn Discussion Group and we will publish a follow-up article based on your feedback.


Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..

Subscribe