Six key control applications: Is there one controller that can do it all?

What kind of controller is best for your application? Is it a PLC (Programmable Logic Controller)? Perhaps you should use a PAC (Programmable Automation Controller)? Maybe a PAD (Programmable Automation Device) would be best? 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/Os, 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 ‘soft’ PC-based controller and even a nano-sized brick.

Industrial automation, as we think of it today, began with the development of the PLC 40 years ago, but by 2002, the evolution of the PLC was so dramatic that Craig Resnick, Director of Research at technology consulting firm ARC Advisory Group, proposed changing the name of the PLC. “The label ‘PLC’ simply understates the capability of current automation systems,” wrote Resnick. He proposed a new name: Programmable Automation Controller, or PAC.

Regardless of the three-letter acronym used, Resnick’s bottom-line recommendation was that “end users should let their application be their guide” in choosing control solutions.

What should you expect of an automation controller? One thing is clear: the modern automation controller can do more than its original developers ever imagined. A single controller can now do the job of multiple dedicated controllers of the past. Considering the advances in technology, a user has every reason to expect that a single controller should deliver value through:

• Providing cost-effective and best-of-breed performance across all desired control applications;
• Employing open standards to allow full integration in a heterogeneous, multi-vendor control environment;
• Offering upgrade and maintenance paths to ensure long-term flexibility, protection against obsolescence and a favourable total cost of ownership.

Six key control applications

Following is a list of six unique control applications:

• Logic control
• Motion control
• Flexible architecture
• Process control
• Safety
• Redundancy

If we look at each of these independently, and identify some core elements that you must have, we can start to paint a picture of what the modern automation controller must deliver.

Logic control

Performance/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 the performance of your application.

One program across a variety of platforms (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.

Configurable system-wide diagnostics

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

The idea to create, test, and reuse common functions is embraced by programmers in all industries. The goal is to be more efficient and to improve program quality. 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, maintainability and quality.

Motion control

Tight integration of motion and automation

The reality of machine control is that both motion control and automation must work in tandem. Manual integration is time consuming and 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 in all elements of the motion solution, from controller to network to drive to the feedback mechanism.

Standards-based algorithms and templates

The ability to propagate libraries and templates throughout the application is very important to minimise rework and promote the use of standards. The use of standards-based, pre-defined, tested functions saves significant time. Access to standard algorithms frees you to focus on configuring your application rather than programming base motion functionality.

Tools to optimise performance

Motion applications tend to be very fast. To optimise performance, tuning and trace tools are absolute requirements. These tools must look at the entire motion solution to perform accurate tuning. Beyond visualisation, the tuning tools may provide wizards to guide you to the best dynamic parameters.

Reliable and established networks to support the motion controller

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.

Flexible architecture

Improved integration

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.

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, specialised vision applications, and applications written in non-PLC programming languages is not easily done in a classical architecture.

Another example is when the output of a machine is so customised that it must change frequently (possibly for each product produced). For this, it is not realistic to rely on human intervention to change the parameters or to load a new recipe. In this instance, a direct connection to a database is preferred. A controller using an open architecture allows for direct connections to the database, possibly even on the same platform.

The ability to think beyond typical restrictions

How often have you wished for more memory or processing power? Automation platforms based on an open architecture provide the flexibility to add additional memory, or even to take advantage of faster CPUs.

Process control

Availability of pre-engineered solutions, templates, and libraries

Process users look to leverage pre-defined objects from libraries 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 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 minimises 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 minimise rework and promote the use of standards.

Ability to be installed in a hostile environment

Many process applications are in hazardous 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.

Safety

The use of a single controller for both standard and safety functionality

When your application requires both standard automation and machine safety, eliminating the need for two controllers saves significant cost and reduces complexity. The optimal solution is a single controller that handles both tasks.

One engineering platform to program standard as well as safety logic

Learning engineering environments takes time you may not have. 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 visualisation 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

Implementing programmable safety on top of an established automation system is a challenge. 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.

Redundancy

Uninterrupted control of a process or machine

Redundancy implies a backup system. 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.

Minimise engineering complexity

Implementing redundancy should be a simple task. If you take on the challenge of designing your own redundancy solution, you must make sure you’ve considered all modes of failure and how the system responds. You also need to consider keeping the primary and backup controllers synchronised. A better approach may be to take advantage of redundancy from the supplier, whether embedded in the operating system of the controller or implemented in software (for less critical applications).

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. If the failed component happens to contain a program, is the program automatically loaded, or does this require manual action from you?

The value of the product and the cost of downtime

Consider the value of your product and the true 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 (either in raw material cost or market value) and downtime not only results in lost production but potentially dangerous and damaging conditions, the nod should probably go to full redundancy.

Moving beyond hardware

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 than 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 through to 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;
• The flexibility provided by support for the IEC 61131-3 languages.

Today’s best-of-class engineering software includes programming and configuration, advanced diagnostics, simulation, remote maintenance and plant documentation — for the controller and other system components like HMI and drives. It also allows for the development of interfaces to non-standard or industry-specific devices.

Which controller is right for you?

Manufacturers and machinery builders need to know how the automation controller can solve their specific needs while adapting to future requirements. 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 three-letter acronym is on the label.

Siemens Ltd
www.siemens.com.au