Centralized controls: Smart software, networks trump smart hardware

Machine architectures require many field devices. For easier system design, engineers should select a core control platform that minimizes complexity, with a unified software platform and network. More streamlined hardware and networking architectures are easier to implement, support, and maintain.
By Daymon Thompson June 3, 2014

Machine design is easier with integrated PLC, safety, motion, robotics/kinematics, and communications functionality in software, with fewer auxiliary points of control (hardware), and software-based devices replacing hardware functions.

When determining the controls architecture of a machine, there are many important factors to consider and many different types of devices that will be included in the system. Some of those devices have built-in intelligence ("smart devices") while others are more basic, using a central controller to process and react to the data. When taking system reliability and maintainability into account, simplicity and flexibility are the most significant keys to success.

Figure 1: Removing network switches from the fieldbus system enables EtherCAT to deliver deterministic data from remote devices to the central controller. This brings with it the possibility to process the control algorithms in a central CPU, eliminating

Naturally, machine builders (original equipment manufacturers, OEMs) prefer that the automation and controls architecture help decrease the time and effort required to build and commission a system. Therefore, it is important for engineers to reuse as much preexisting engineering work as possible. This helps reduce configuration time for individual devices and systems. At the same time, the equipment end user needs the machine architecture to promote good overall equipment effectiveness (OEE) and minimize the impact on production when an unexpected failure or maintenance requirement occurs. The most efficient and reliable way to accomplish these goals is by increasing the use of smart software in the areas previously occupied by dedicated, special-purpose hardware.

Simplified controller architecture means that the core of the machine (or machines) is built around one controller and one network, which is all configured and programmed using one software platform that in itself has one primary development environment. Within one platform it is possible to integrate programmable logic controller (PLC), safety, motion, robotics/kinematics, and communications functions largely in software, while reducing the amount of auxiliary points of control (hardware), and replacing "smart" hardware devices in favor of "software" devices. Data from the field is gathered by standard I/O equipment for the centralized controller running smart software to process. This reduces the amount of "black box" hardware on machinery and the configuration that goes along with that hardware. This can lead to significant cost savings and fewer potential points of failure for simpler system commissioning and maintenance.

PC control is fast

Historically, cycle times of 10-20 ms were common in systems that relied upon multiple black box devices for special functionality. Usually, the communication to these devices is asynchronous and results in corresponding inaccuracies because of the lack of determinism associated with the system responses. However, technological advances in high-performance PC controllers have enabled reductions in cycle times easily in the 1-2 ms range, with the possibility to run as fast as 50 μs. This is a decrease in cycle times by a factor 10. As a result, control loops and time-sensitive algorithms can be moved from distributed hardware (smart devices) into the central machine controller, resulting in further cost savings and greater design flexibility within the application.

Centralized control technology can be particularly advantageous if the system can run faster and more powerful control algorithms than would be possible with many distributed small controllers that all require complex communication and handshaking. Modern industrial PCs (IPCs) typically offer significantly higher processing power and memory at lower cost than the sum of even a large number of small distributed controllers. 

Efficient engineering, flexible networks, software

This equation goes beyond hardware versus software; there are network factors to consider. For most controls engineers, complexity creeps into projects from the beginning, perhaps even starting with the first managed switch and subnet. This is followed by adding "smart" devices to TCP/IP based networks. Complexity quickly increases with each device added to the network as well as the required configuration time and effort for devices and networks.

Figure 2: Utilizing “core isolation” makes individual cores “invisible” to the operating system (OS), enabling them to be used exclusively by real-time automation and controls tasks. Resources on those isolated cores are then 100% available for use by Twi

By contrast, when implementing a true industrial Ethernet system, such as EtherCAT, users immediately simplify the system by eliminating the need for managed switches between the controller and the (remote) I/O. Removing network switches from the fieldbus system enables EtherCAT to deliver deterministic data from remote devices to the central controller. This brings with it the possibility to process the control algorithms in a central CPU, removing the need for a wide range of smart devices. 

Unified programming

Figure 3: Using a PC-based control system such as Beckhoff’s TwinCAT 3 (The Windows Control Automation Technology) is the catalyst to leverage the full power of modern multicore processors to simplify the control architecture and process algorithms centraBack to the software side, using a unified PC-based control system is the catalyst to leverage the full power of modern multicore processors to simplify the control architecture and process algorithms centrally. With such software, real-time tasks can be distributed to different processor cores. For example, the PLC run time can run on one core, while motion control and HMI, respectively, run in a second and third core. Tasks are individually assigned to a core, and utilization ratios of those cores can be specified individually. Using this "core isolation" makes individual cores "invisible" to the operating system (OS), enabling them to be used exclusively by real-time automation and controls tasks. Resources on those isolated cores are then fully available for the control software to use for algorithm processing, motion control, communications, or other functions. The OS only can use the core(s) assigned to it and, therefore, the isolated core(s) can be used by the unified software without influence from the OS. Multicore utilization and isolation is quickly configured from within the programming environment.

Faster setup

Optimum utilization of PC processing power can be achieved with a motion control toolset. Repetitious and laborious programming of individual drives has been an optional activity for several years. Available software makes it possible to program and parameterize all drives on a machine on the central controller as far back as in the 90s. With more recent advancements, the capacity of a standard PC CPU enables the position control loop to be calculated on the central controller, rather than in a separate motion control CPU or motion card. In this case, servo drives or stepper drives only need the ability to close the current and torque loop, while closing the position loop in the programming software. This makes it possible to use more cost-effective drives that have a smaller footprint, as well as facilitating easier gearing of an axis or the ability to electronically cam axes together. This can eliminate costly mechanical devices and makes the system far more flexible than is possible with mechanical cams. This power and flexibility make it possible to position many axes simultaneously, add robot kinematics, and execute interpolated motion based on G-code, all concurrently on one PC-based controller. These motion tasks can run on the same controller, either on separate CPU cores or on the same CPU core, all executed in real time. This eliminates the need for separate motion control hardware and logic control hardware. In addition to previously mentioned methods, these can be programmed using a wide range of available software tools, including the typical PLC programming languages, PLC Open function blocks, C++, and more.

Condition monitoring

Another example where central control reduces the amount of required hardware is in the area of condition monitoring. Among other tasks, these systems can record vibrations of motor bearings, shafts, or other mechanical parts of the machine. This data is analyzed to detect wear and damage to machine operations or hardware before a breakdown occurs. Traditionally, condition monitoring is also accomplished using specialized black box hardware that processes the signals with a typically limited feature set. If more functionality is needed, additional hardware modules often must be added to the system, complicating matters in the ways discussed previously. Alternatively, by using more standard signal input devices, additional functionality or processing algorithms can be added in software rather than in highly specialized hardware. It’s possible to gather condition monitoring data via I/O terminals that have the same physical format, network, and software environment as "regular" analog and digital I/O. 

Outsmarting dedicated "smart" devices

Powerful centralized controllers combined with smart software and a deterministic network such as EtherCAT enable engineers to add other kinds of devices to the primary network that were perhaps more difficult to integrate in the past, such as temperature controllers. Temperature control is another example of a solution traditionally implemented using stand-alone black box hardware that is connected to a thermocouple as an input and has an output to control the heater/cooler. This piece of hardware typically has only a few navigation buttons, but many parameters that must be set to work optimally for the application. Often, these settings are set in the controller by the machinery OEM and the documentation of these settings can be difficult to properly manage and use in the long run when it’s needed most. Selecting an EtherCAT master in software and using standard EtherCAT I/O hardware in this temperature control example will give access to hardware device parameters from within the same development environment used for the overall automation and controls programming.

This also facilitates access to the slave devices’ parameter "start-up lists." Once an EtherCAT slave device is configured, those parameters can then be moved into the start-up list. This list of parameters, and their values, will be automatically loaded into the device as the EtherCAT network is initialized. This will happen either on power up of the controller or upon manual reactivation. Replacement of an EtherCAT device is as simple as powering down the equipment and installing the new device. Once the machine is powered up, the parameters will be restored to the new device, greatly reducing equipment downtime.

Additionally, by bringing the parameterization of the hardware as well as the control logic into a powerful, software-based platform, other useful benefits become available to the OEM and end user. For example, programming software can integrate seamlessly with revision control software such as Microsoft Team Foundation Server, GIT, or subversion software. This means that once parameter values have been decided on and stored in the start-up list, the device settings can be archived and revisions controlled along with other project elements such as the PLC program, safety configuration, or even servo drive settings. This archive of the parameters can be imported and applied to future projects using that device type. This extends the strategy of code reuse further than PLC function blocks, all the way down to device configuration, which enables much more efficient use of engineering time.

Streamlined architecture

Machine architectures will always require a wide range of different field devices. At the beginning of system design, however, engineers should select a core control platform that minimizes complexity. It is most efficient to program as much system functionality for as many devices as possible in as few software platforms as possible-ideally, just one. It is also critical to leverage one system-wide network that does not require managed switches and routers, which is driven by one software platform on one hardware controller. Specifying the devices to be used on that network should always allow the reuse of parameterizations and enable automatic re-parameterization upon hardware replacement, while sending the data back to a central controller for processing. Following these points during system design will improve the odds of success and competitive advantages through enhanced architecture simplicity. More streamlined hardware and networking architectures are inherently easier to implement, support, and maintain.

– Daymon Thompson is TwinCAT 3 product specialist, Beckhoff Automation. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, mhoske@cfemedia.com.

Key concepts

  • PC-based control, using a unified programming software, simplifies system design of machine architecture.
  • Use one system-wide network that doesn’t require managed switches and routers.
  • Reusing device parameters helps with enhancements, maintenance, and upgrades.

Consider this

When was the last time you reexamined machine architecture? Is it enabling or disabling your goals?

ONLINE extra

This article online includes more information, an added graphic, and related links. For more information: