Can One Controller Do It All?

What kind of controller is best for your application? Is it a PLC (programmable logic controller) — or perhaps you should use a PAC (programmable automation controller), or maybe a PAD (programmable automation device)? When it comes down to it, the name is not that important. What is important is developing a clear understanding of your needs and then finding the controller that best targets them.

In the world of industrial automation, technology has evolved leading to innovations in controllers and I/O, enhanced engineering tools and entirely new system architectures. The controller we are familiar with can now take virtually any size and shape, from a traditional industrial PLC, to a PC-based controller and even a “nano-sized” brick.

On paper, an automation controller must cover a broad range of application requirements. The platform should offer standards-based openness; flexible, single-database integration for the entire system; standard IEC-61131-3 control programming and configuration languages; the ability to create preconfigured libraries of reusable code; and object-oriented design of complete system architectures.

The reality is that very few controllers can truly provide these capabilities in one package. But such solutions do exist, so it’s important to identify unique control applications and then look at what the controller should do to help you solve the application. Following is a list of six control applications: If we look at each of these, and identify some core elements that you must have, we can paint a picture of what the modern automation controller can deliver.

Performance and processing speed: In machine, factory or process control, controller performance is a key element in productivity gains. As you strive to improve the electro-mechanical performance of your application to yield higher throughputs, the performance of your automation system must keep pace. The execution time, high-speed interrupt handling and “segmentable” scan times of your controller all contribute to application performance.

Scalability: Ideally, you would have one engineering environment to configure all of your applications, which, in turn can be downloaded to the target platform meeting your requirements. This separation of program and platform allows you to focus on solving the application problem, followed by selecting the best, most cost-effective platform for your specific application.

Configurable system-wide diagnostics: You can always program diagnostics into your code, but this takes time, and often is sacrificed to meet project schedules. A controller with built-in diagnostics that can be easily enabled or configured ensures that this important aspect of your solution won’t be skipped.

Availability of multiple programming languages: Relay Ladder Logic is expected in a logic controller, but aspects of your application may be better implemented using graphical function blocks or a high-level programming language. The IEC 61131-3 standard for PLC programming languages defines five languages that range from ultra-efficient “machine code” to the graphical representation of sequences.

Potential for reusable code: For industrial automation, leveraging a library (from the supplier or defined by you) of common program elements and using these elements repeatedly reduces implementation time and improves program consistency.

Investment security: Rather than demanding new products, many users push for longer life cycles for their existing products and architectures while taking advantage of advances in technology. The result is having the “latest and greatest” without the need to “rip and replace.”

Tight integration of motion and automation: Not only is manual integration time consuming but it’s prone to errors and maintenance challenges. Ideally, motion and automation engineering would be done in the same software with the same languages.

High-speed, deterministic performance: Motion applications tend to be very fast and therefore require real-time, high-performance controllers. However, speed is nothing if it’s not repeatable. For proper operation, the controller needs to execute your defined tasks the same way every time. Optimally, you want fast, deterministic execution with very small jitter of all elements of the motion solution from controller to network to drive to the feedback mechanism.

The controller should be designed to make it easy to engineer motion applications: The ability to propagate libraries and templates throughout the application is very important to minimize rework and promote the use of standards. The use of standards-based, pre-defined, tested functions saves significant time. Access to standard algorithms (like circular interpolation and 3D movement) frees you to focus on configuring your application rather than programming base motion functionality.

Tools to optimize performance: Motion applications tend to be very fast. To optimize performance, tuning and trace tools are absolute requirements. These tools must look at the entire motion solution to perform accurate tuning.

Reliable and established networks to support the motion controller: Proprietary networks tend to limit you to only one supplier. Ideally your motion controller supports an established network standard. It is critical that the network also accommodates high-speed deterministic motion applications. The network should not introduce any limits to the performance of the motion solution — the network should be transparent.

Improved integration to achieve higher performance and lower engineering costs: Frequently, the ideal application solution may require specific hardware and custom software technology to tightly integrate with your controller. An open architecture makes it possible to embed the custom program directly with the automation control program. Additionally, you can achieve high-performance due to the ability to directly plug interface modules into the platform bus.

When an application is outside the capabilities of classical controller architecture, open architectures are essential. Connecting non-standard communication busses, PCI-bus based servo controllers, specialized vision applications and applications written in non-PLC programming languages are not easily done in a classical architecture. Automation platforms utilizing an open architecture allow the user to develop their own integration solutions that are run as part of the controller execution.

The ability to think beyond typical restrictions: How often have you wished for more memory or processing power? Traditional controller platforms limit you to specified resources – if you need more, you must purchase a different platform. Automation platforms based on an open architecture provide the flexibility to add additional memory, or even to take advantage of faster CPUs.

Leverage continuous platform innovation: Hopefully, we are all familiar with Moore’s Law. Computer processor speed directly impacts controller program performance in an open architecture controller. A traditional controller cannot offer the ability to leverage this rapid innovation.

Availability of pre-engineered solutions, templates, and extensive libraries: Process users look to leverage pre-defined objects from libraries (i.e., cascade PID) rather than “rolling their own.” This speeds up configuration and makes the resulting project more consistent and maintainable. It would be advantageous if you could also create your own library objects based on your unique control strategy.

Ability to select program execution speed: The normal reaction to controller speed is “faster is better.” However, for process applications regulatory control loops normally scan in the 100 to 500 millisecond range. In some cases, it could be detrimental to have control logic execute any faster – possibly causing excessive wear on final control elements such as valves, resulting in premature maintenance and process issues. It is important to have the ability to select program execution speed.

Emphasis on design using a top-down approach to engineering: Process users spend a lot of time on up-front design and overall program structure. This focus on upfront design minimizes costs, compresses project schedules and creates applications that can be maintained by plant personnel over the long term. Since many process applications are large and plant-wide in scope, the ability to propagate libraries and templates throughout the application is very important to minimize rework and promote the use of standards.

Ability to be installed in a hostile environment: Many process applications are in hazardous (i.e., explosive) environments. Additionally, the environment may be moist or corrosive, potentially leading to damage of critical electronics. The automation platform and associated peripherals must withstand such environments without undue installation costs or complexity.

Embedded knowledge: Technology is just part of the challenge to produce an effective automation platform for process applications. It helps tremendously if the supplier knows process control and has embedded this knowledge in their technology and the available libraries. The result is a platform designed to meet the unique requirements of process applications “out of the box.”

The use of a single controller for both standard and safety functionality: Eliminating the need for two controllers saves significant cost and reduces complexity. The optimal solution is a single controller that handles both tasks. This opens new possibilities when designing architectures such as a shared controller, shared bus system and shared I/O serving both standard automation and the safety.

One engineering platform to program standard as well as safety logic: A controller that uses the same engineering tools for standard automation and machine safety configuration not only simplifies learning the tool, but dramatically simplifies the integration of diagnostic information. The same diagnostic visualization you already use for your automation system can be used by maintenance and operations to troubleshoot safety incidents.

Safety as part of a distributed architecture, even with existing systems: Rather than putting in place a parallel, safety-only system, you should consider whether the safety controller can be used as a slave to the established automation system, handling the safety functions. Doing so has a significant impact on reducing integration time and effort.

Uninterrupted control of a process or machine: It may sound obvious, but redundancy implies a backup system – a safety net to protect your process from unexpected controller failures. Do you want controller redundancy only, or do you want to take redundancy to other levels? What about the power to the controller, or the networks you rely on, or the inputs and outputs connecting your process? Not only must you determine the depth of redundancy you require, but you need to determine how your application behaves during switchover.

Quickly resolve a failure: When you have a failure, your redundancy strategy will keep your process or machine running. But how do you know that a failure has occurred, and how do you fix the problem? This is where diagnostic notification comes into play pinpointing the problem. Once you locate the problem, it is very beneficial to be able to hot-swap the failed components.

The value of the product being manufactured and the cost of downtime: If the value of the product being manufactured is relatively low and/or downtime results in lost production but little additional cost or damage to the process, implementing redundancy may not be the best choice. If the value of the product is high and downtime not only results in lost production but potentially dangerous and damaging conditions, the nod should probably go to full redundancy. In process applications running 24/7/365, downtime is one of the gremlins you try to avoid at all cost. The more volatile the application, the more it may require a solution with lots of redundancy.

Which one is right for you?
With so much expected from a single controller platform, the engineering tools to support all the disciplines involved in a typical automation system become more important then the controller itself. A true multi-domain controller platform includes the multidisciplinary tools required to support traditional logic applications, as well as motion control, process control and all the other applications previously discussed.

A complete suite of engineering software gives you the tools to manage the entire engineering life cycle — from design on through ongoing maintenance. Capabilities you should look for include an integrated engineering environment for logic, motion, process, etc.; a single point for system-wide engineering with a project view; a modular structured approach where you can design your automation around your process; and the flexibility provided by support for the IEC 61131-3 languages.

The best controller is the one that most closely enables your automation system to meet the requirements of your manufacturing application, and allows your manufacturing process to integrate seamlessly with other manufacturing and business processes. It is important to base a controller decision on the requirements of the entire automation system … no matter what kind of TLA (three-letter acronym) is on the label.

Bob Nelson, controller-marketing manager for Siemens in the U.S., has more than 20 years experience in the automation and control industry. For questions regarding controllers in Canada, contact stefan.morgenstern@siemens.com.