Users say it’s time for new automation architecture

More than 140 opinions and comments were shared in our LinkedIn discussion

In an article titled Is it time for a new automation architecture? I posed a question that stemmed from a number of discussions with users who believe our industry is stagnant. Many of those users are frustrated with debates about which existing, but outdated, architecture(s) is better. Many believe it’s time for a NEW architecture.

Every automation vendor has their own view about which system is best. They should be asking themselves, “What is the goal of automation?” In my original article, I suggested that the fundamental goals are to improve quality, uptime and efficiency; and drive out the labor costs of production. System improvements should reduce application engineering time, reduce control configuration, and simplify configuration of networks and I/O.

After publication, we posted my original article on Automation.com’s LinkedIn Discussion Group. It sparked a great deal of activity – more than 140 comments from a wide range of industry professionals. Based on the comments, there is a general impression that manufacturing systems have not applied new technology at the rate of commercial or business systems. As a result, they can’t deliver the value that engineers need. Other indicators that change is afoot are the new industry initiatives, including Industry 4.0, Smart Factory, and Industrial Internet.

In the original article, I suggested system architecture is the framework that defines the structure and functions of an automation system. In the beginning, industrial automation systems started with closed architectures out of necessity. Many have evolved to some level of open architecture. I posed my own wish list to our readers:

Native Interfaces

Eliminate gateways, proxies, and other bridging devices. Users can’t replace all the equipment at once. By incorporating native industrial network interfaces (DeviceNet, Profibus, EtherNet/IP, PROFINET, EtherCAT, SERCOS, etc.) on controllers, users can more easily configure and maintain systems. A number of suppliers today support this concept. However, some are staunch supporters of their own “flagship” protocols. To interface with other protocols, they require gateways or bridging devices. In turn, these devices require special configuration steps and create more engineering labor and maintenance.

Single Device Profiles

A single industry standard device profile, regardless of native protocol, would accomplish “plug-n-play” device connectivity. This would allow users to easily add devices to systems and simplifying engineering and configuration. This plug-n-play connectivity is a reality in the computer industry. The addition of 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. They would simplify the automation architecture by incorporating embedded historians, analytics, alarm management, equipment diagnostics, advanced control optimization, and rules engines. These engines would 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. The results would be improved system performance, elimination of bottlenecks and duplicate databases, simplification of control configuration, and lower software maintenance costs.

Total Production Optimization

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

Software Programming & Configuration

We should have an integrated “do it once” environment for functional configuration that ties everything together, including alarm logic, HMI, history, version control and other functions. A functional configuration would allow application engineers to deal with production subsystems without having to program basic logic. In addition, we should have one programing software standard to create, simulate, debug, communicate, download and upload for all types of controllers.

Automation Apps Standard

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

Unified Industrial Architecture

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

Comments from Industry Professionals

The comments from the LinkedIn group provided many other perspectives thoughts and ideas. The following is a summary of some of those comments. All the comments can be viewed on the LinkedIn group discussion. I invite you to share your own thoughts.

Open Hardware Platform

One large user built their automation system using CompactPCI open controller hardware. It provides a 100% open controller hardware architecture and vendors can provide compatible I/O cards. This would be a radical change for the automation industry. However, standard board systems have been used in the military and other applications as COTS (commercial off-the-shelf) alternatives to proprietary hardware for years.

As drives, sensors, motor controls, and other devices include industrial network connections, there may no longer be a need for rack I/O. Industrial computers will take the place of PLC and DCS controllers.

Plug-n-Play

A major user described how they have been using fieldbus process instruments for about ten years. A big time consuming problem is getting the device description for system configuration. He suggested putting device descriptions inside sensors and instruments so the systems can be plug-n-play.

A single electronic data format for configuration of devices and networks would really simplify and streamline configuration, commissioning, and servicing. There is some limited activity for a standard by five major automation foundations, including the FDT Group, Fieldbus Foundation, HART Communication Foundation, PROFIBUS & PROFINET International, and the OPC Foundation. A single common solution for Field Device Integration (FDI) is a great start.

Open Source

Many comments were about the desire for an open-source, interoperable architecture, much like everyone enjoys in the computer industry. Many users believe that open source architecture may need to be driven by customers because vendors are reluctant to conform to open standards. This is illustrated by how many years it has taken to adopt industrial network standards and the number of competing standards groups. For example, multiple industrial Ethernet networks claim to be open, but they do not communicate with each other without gateways and proxies. Within these networks’ standards are vendor-unique components of protocols. These unique components don’t allow products that theoretically “conform” to the same standard to be interchangeable in the field. If the computer industry was still built on these closed models, it would not be possible to browse the Internet with PCs, phones, and tablets using different browsers.

One contributor described the situation:

My definition of “architecture” is "do the same thing the same way, always" and "use the same parts to build everything." All homes are built with the same parts, yet meet all kinds of requirements. All electronic devices use the same parts, but provide all kinds of competitive functionality. So why doesn't this phenomena exist in control systems? Why can't the User Application Programs be shared across products and vendors? Simple answer: NO architecture. I agree with standards. They help converge vendors to help customers. But at some point you need to look at requirements versus available solutions and then create a new architecture to fill in the holes. If there are no holes, then life is good.

Cloud

Some commenters observe the development of a wide range of new technologies, including sensor networks, wireless communications, cloud computing, IPV6, 6lowPAN, smart-phones and tablets. They believe the future is highly decentralized architectures where data and most applications will be hosted in a cloud. The automation clouds will provide many services, including standard applications like historian, tuning, alarm management, analytics, and optimization. This will be a great incentive for standardizing the interfaces between various equipment and the IP based architecture with "common interface protocols and dialogs."

Highly Distributed Architecture

Many comments relate to moving functions to end devices in highly distributed architectures. This would result in more computing throughout the systems and achieve greater responsiveness and resiliency. In addition, it would leverage cloud computing for higher level functions. This would enable a strong ecosystem by federating local and cloud services applications.

Such an architecture would be similar to an integrated "hive mind” or group mind (link to http://en.wikipedia.org/wiki/Hive_mind) concept. Centralized functions would be distributed and redundant much like the "mesh network" architecture. Each component would be a node and all nodes work together in a self-healing, dynamic network.

The field I/O interfaces, like A/D conversion, should be as close to the field sensors as possible for highest accuracy and fidelity. Ideally A/D conversion should be in the transmitter itself. We should have real-time digital communication instead of analog signals all the way from the transmitters to the control system, and from the controllers to the valve positioners and associated I/O points.

Digital networking all the way to sensors and actuators in the field would dramatically reduce the wiring required. Especially when considering that devices on average have 3 signals, not one. Digital communication eliminates 3 pairs of wires per device, 3 I/O channels per device, and 3 safety barriers per device, as well as the associated marshalling cabinets.

Control Software

The proprietary nature of software for building applications is a recurring theme from discussion contributors. There is a desire for an integrated design environment where applications can be developed, simulated, and debugged for multiple brands of controllers.

Integrated Systems

Integration should be performed through a single platform. With a single platform, control room personnel will not need to open, check, monitor 5 different screens and generate printouts or shift-end log sheets. All subsystems should be integrated into a single platform with one interface, and include PLC, DCS, LIMS, flow computers, building automation, fire safety, and security systems.

Robots for Hazardous Area

We should eliminate the need for humans in hazardous field areas. The application of robots would prove to be of high value and maintain safety, health and environment as per governing rules.

Foundation Fieldbus

There are many comments about Foundation Fieldbus meeting the needs for highly distributed control. Parts of the oil & gas industry use the distributed control capabilities that Foundation Fieldbus Control in the Field (CIF) offers. This has been a user driven demand in these markets.

Unfortunately, vendors have not embraced Foundation Fieldbus Control in the Field (CIF) as their flagship architecture. As a result, CIF has not built up production volume, which subsequently would drive down costs to make it practical for broader application.

Wireless

Wireless is certainly on the mind of users. They hope it will become more cost effective, reliable and cyber secure.

Innovation

Many discussion contributors addressed innovation. Below are some of their comments.

When HMIs came out, we said, "No way will Windows be reliable enough." When Ethernet came on the scene, we said, "No way will a statistical network work on the plant floor." These products didn't win their respective market shares by being "more reliable" or "more feature driven" or whatever. They won because they were "good enough" and the companies promoting them did the right things. My point is the market drove the ultimate selection process. As this discussion clearly shows, the new automation infrastructure is evolving as we speak; and it will continue to evolve. To me, there are two main intertwined concepts: The EcoSystem and The Business.

1) The Ecosystem needs to be AND IS Standardized to some degree. We would simply NOT be where we are without the Internet, etc. Nonetheless, this EcoSystem standardization needs to solidify while continuing to evolve. Mobile has figured out how to continuously evolve their infrastructure. We need to do the same for MES and automation. MES and automation need to be addressed together because the process operators’ responsibilities go well beyond the automation layers. Security dictates that automation functionality inside the control domain be minimized and secured along the lines of ISA 99 and its ISO equivalent. That means that the operator’s environment needs to include all three domains: ERP, MES, and automation/control. So, the EcoSystem needs to provide for that on mobile, etc.

2) The Business is a separable issue, since it changes continuously. Operating companies (OCs) need to recognize that their IT Systems contain their competitive advantage. 80% of the OC’s entire IT environment needs to meet best practices. The other 20% contains their uniqueness AND leading business processes. No single IT vendor should control the OC’s entire IT functionality. If an OC uses a single vendor, then that OC is totally dependent on that vendor’s development cycle. That means that the OC is accepting a laggard position in their market. The OC needs to be agile and push for open specification interoperability!

Since the majority (60-80%) of the cost and delays to respond to business needs is caused by incompatibility of different systems, we need to change how we manage those systems. We need to recognize that for any given site, there is a common set of business objectives. By using systems engineering principles to design and create an agile EcoSystem we can continuously adapt in shorter and shorter time frames.

Contribute Your Ideas

This discussion group has participants from a number of countries and disciplines. One commonality is they are all automation professionals and are willing to voice their thoughts and ideas in an open forum. Please consider adding your thoughts and ideas about what you think would improve automation systems.