The "80-20" Rule During the following three decades since their introduction, PLCs have evolved to incorporate analog I/O, communication over networks, and new programming standards such as IEC 61131-3. However, engineers create 80 percent of industrial applications with digital I/O, a few analog I/O points, and simple programming techniques. Experts from ARC, Venture Development Corporation (VDC), and the online PLC training source PLCS.net estimate that: ï 77 percent of PLCs are used in small applications (less than 128 I/O) ï 72 percent of PLC I/O is digital ï 80 percent of PLC application challenges are solved with a set of 20 ladder-logic instructions

Since 80 percent of industrial applications are solved with traditional tools, there is strong demand for simple low-cost PLCs. This has spurred the growth of low cost micro PLCs with digital I/O that use ladder logic. It has also created a discontinuity in controller technology, where 80 percent of applications require simple, low cost controllers and 20 percent relentlessly push the capabilities of the control systems. These 20 percent applications are built by engineers who require higher loop rates, advanced control algorithms, more analog capabilities, and better integration with the enterprise network.

In the 80s and 90s, these "20 percenters" evaluated PCs for industrial control. The PC provided the software capabilities to perform advanced tasks, offered a graphical rich programming and user environment, and utilized COTS components allowing control engineers to employ technologies developed for other applications. They now could use Intel floating point processors; high speed I/O busses, such as PCI and Ethernet; non-volatile data storage; and graphical development software tools. The PC also provided unparalleled flexibility, highly productive software, and advanced low-cost hardware.

However, PC-based control was not perfect so while many engineers used the PC when incorporating advanced functionality, like analog control and simulation, database connectivity, web based functionality, and communication with third party devices, the PLC was still king for control. The main problem with PC-based control was that standard PCs are not designed for rugged environments.

The PC suffered from three main problems: 1. Stability: Often, the PC's general-purpose operating system was not stable enough for control. PC controlled installations were forced to handle system crashes and unplanned rebooting. 2. Reliability: With rotating magnetic hard drives and non-industrially hardened components, such as power supplies, PCs were more prone to failure. 3. Unfamiliar Programming Environment: Plant operators needed the capability to override a system for maintenance or troubleshooting. Using ladder logic, they knew how to manually force a coil and patch code to quickly override a system. But with PC systems, operators needed to learn new tools.

Although some engineers use special industrial computers with hardened hardware and special operating systems, most engineers avoided PCs for control because of problems with PC reliability. In addition, the devices used within a PC for different automation tasks, such as I/O, communications, or motion, may have different development environments.

So the "twenty percenters" either lived without functionality not easily accomplished with a PLC or cobbled together a system that included a PLC for the control portion of the code and a PC for the more advanced functionality. This is the reason many factory floors today have PLCs used in conjunction with PCs for data logging, connecting to bar code scanners, inserting information into databases, and publishing data to the Web. The big problem with this type of setup is that these systems are often difficult to construct, troubleshoot and maintain. The system engineer often is left with the unenviable task of incorporating hardware and software from multiple vendors, which poses a problem since the equipment is not designed to work together.

Building a Better Controller
With no clear PC or PLC solution, engineers with complex applications worked closely with control vendors to develop new products. They requested the ability to combine the advanced software capabilities of the PC with the reliability of the PLC. These lead users helped guide product development for PLC and PC control companies.

The software capabilities required not only software advancements, but also an increase in the hardware capabilities of the controllers. With the decline in world-wide demand for PC components, many semiconductor vendors began to redesign their products for industrial applications. Control vendors today are incorporating industrial versions of floating point processors, DRAM, non-spinning memory storage such as CompactFlash, and fast Ethernet chipsets into industrial control products. The enables vendors to develop more powerful software with the flexibility and usability of PC based control systems that can run under real-time operating systems for reliability.

The resulting new controllers, designed to address the "20 percent" applications, combine the best PLC features with the best PC features. Industry analysts at ARC named these devices programmable automation controllers, or PACs. In their "Programmable Logic Controllers Worldwide Outlook" study, ARC identified five main PAC characteristics. These criteria characterize the functionality of the controller by defining the software capabilities:

ï "Multi-domain functionality, At least 2 of logic, motion, PID control, drives, and process on a single platform." Except for some variations in I/O to address specific protocols like SERCOS, logic, motion, process, and PID are simply a difference in software. For instance, motion control is a software control loop which reads digital inputs from a quadrature encoder, performs analog control loops, and outputs an analog signal to control a drive.

ï "Single multi-discipline development platform incorporating common tagging and a single database for access to all parameters and functions." Because PACs are designed for more advanced applications such as multi-domain designs, they require more advanced software. In order to make system design efficient this software must be one integrated software package instead of disparate software tools which are not engineered to work together.

ï "Software tools that allow the design by process flow across several machines or process units, together with IEC61131-3, user guidance, and data management." Another component that simplifies system design is high level graphical development tools that make it easy to translate an engineer's thoughts about the process into code to control the machine.

ï "Open, modular architectures that mirror industry applications from machine layouts in factories to unit operations in process plants." Because all industrial applications are customized, the hardware needs to be modular so the engineer can pick and choose the appropriate components. The software must enable the engineer to add and remove modules to design the required system.

ï "Employ de-facto standards for network interfaces, languages, etc., such as TCPIP, OPC & XML, and SQL queries." Communication with enterprise networks is critical for modern control systems. Although PACs include an Ethernet port, the software for communication is the key to trouble-free integration with the rest of the plant.

Two Approaches to Software While software is the key difference between PACs and PLCs, vendors vary in their approach to providing the advanced software. Vendors start with their existing control software and work to add the functionality, reliability, and ease-of-use required to program PACs. Generally, this creates two camps of PAC software, either software provided by vendors with a background creating PLC control or vendors with a background creating PC control. Software taken from the PLC
Traditional PLC software vendors begin with a reliable and easy to use scanning architecture and work to add new functionality. PLC software follows a general model of scanning inputs, running control code, updating outputs, and performing housekeeping functions. A control engineer only designs the control code because the input cycles, output cycles, and housekeeping cycles are all hidden. With much of the work done by the vendor, this strict control architecture makes it easier and faster to create control systems. The rigidity of these systems also negates the need for the control engineer to completely understand the low level operation of the PLC to create reliable programs. However, the strength of the PLC architecture, the rigid scanning architecture, can also make it inflexible. Most PLC vendors who create PAC software work to insert new functionality, such as Ethernet communication, motion control, and advanced algorithms, into the existing scanner architecture while maintaining the familiar look and feel of PLC programming and the strengths in logic and control. The result is PAC software generally designed to fit specific types of applications such as logic, motion, and PID, but less flexible for custom applications such as communication, data logging, or custom control algorithms.

Software founded from the PC Traditional PC software vendors begin with a very flexible general purpose programming language, which provides in-depth access to the inner workings of the hardware and works to incorporate reliability, determinism, and default control architectures. Although engineers can create the scanner structure normally provided to the PLC programmer, they are not inherent in PC control software. This makes the PC software extremely flexible and well suited for complex applications that require advanced structures, programming techniques, or system level control but more difficult for simple applications.

The first step for these vendors is to provide reliability and determinism, which are often not available in a general purpose operating system such as Windows. This action is accomplished by using a real-time operating system (RTOS) such as Phar Lap from Venturcom or VxWorks from Wind River. These RTOSs provide the capability to control all aspects of the control system, from the I/O read and write rates to the priority of individual threads spawned on the controller. Next, these vendors add abstractions and I/O read/write structures to make it simpler for engineers to build reliable control applications. The result is flexible software suited for custom control, data logging, and communication but lacking the familiar PLC programming architectures, making application development more demanding. National Instruments manufactures a family of PAC deployment platforms that run LabVIEW software. LabVIEW is the defacto standard for test and measurement software. Its intuitive graphical programming style, similar to flow-charting, provides the functionality of a full programming language with an easy-to-use interface. With LabVIEW Real-Time and LabVIEW FPGA, we combined LabVIEW with a real-time operating system and the ability to directly target FPGAs (Field Programmable Gate Arrays) to provide reliability and determinism.

Vision and Measurements in PACs With a background in measurements, National Instruments is extending PAC beyond simple I/O by incorporating higher speed measurements and vision. Many industrial applications collect high speed measurements for vibration or power quality applications. This data is used to monitor the condition of rotating machinery, determine maintenance schedules, identify motor wear, and adjust control algorithms. The data is normally collected using specialized data acquisition systems or stand alone instrumentation and is incorporated into a control system using a communication bus. National Instruments PACs can directly take high accuracy measurements at hundreds of thousands or millions of samples per second, allowing engineers to pull data directly into their control systems.

Engineers also can incorporate vision into their control systems. Vision is an area of automation that has gained a lot of momentum in the last decade. In a manufacturing environment, there are many flaws or mistakes that can be caught through visual inspection that are difficult to detect using traditional measurement techniques. Common applications include part inspection for manufacturing or assembly verification, such as checking for correct component placement on a circuit board, optical character recognition (OCR) to examine date codes or to sort products, and optical measurements to find flaws in products or for sorting by quality. Many plants currently use stand-alone smart cameras that need to communicate to the manufacturing process controller. National Instruments PACs incorporate vision or high speed measurements with logic, and motion control eliminate the need for engineers to integrate dissimilar hardware and software platforms.

PACs eliminate the need for custom hardware Although PACs represent the cutting edge of programmable controllers, the future for PACs is the incorporation of embedded technology. One example is the ability to use software to define hardware. Field Programmable Gate Arrays (FPGAs) are electronic components commonly used by electronics manufacturers to create custom chips, allowing intelligence to be placed in new devices. These devices consist of configurable logic blocks that can perform a variety of functions, programmable interconnects that act as switches to connect the function blocks together, and I/O blocks that pass data into and out of the chip. By defining the functionality of the configurable logic blocks and the way they are connected to each other and to the I/O, electronics designers can create custom chips without the expense of producing a custom ASIC. FPGAs are like having a computer that literally rewires its internal circuitry to run your application.

Normally FPGA technology has only been available to hardware designers who were proficient in low level programming languages like VHDL; however, controls engineers today can use LabVIEW FPGA to create custom control algorithms that are downloaded onto FPGA chips. This advancement enables engineers to incorporate extremely time-critical functions to hardware such as limit and proximity sensor detection and sensor health monitoring. Because the control code runs directly in silicon it is possible for engineers to quickly create applications that incorporate custom communication protocols or high speed control loops, up to 1 MHz digital control loops and 200 kHz analog control loops. National Instruments PACs
Because of the capabilities of LabVIEW and the ease-of-use of graphical programming, LabVIEW based PACs are well suited for applications that require:

graphics, measurements (high-speed data acquisition, vision, and motion) and processing capabilities. In some applications, you need specialized control algorithms, advanced signal processing, or data logging. Using LabVIEW, you can incorporate custom control code built using NI or third-party tools, implement signal processing such as JTFA, or log data locally or remotely.

It's also well-suited for a variety of platforms including a PC, embedded controller, FPGA chip, or handheld PDA, as well as for communication. LabVIEW makes it easy for you to pass data up to the enterprise with tools like databases connectivity, OPC, and operator interfaces via a web browser

National Instruments offers five LabVIEW based PAC platforms. PXI is a multi-vendor industry standard PAC based on the CompactPCI architecture that offers a modular, compact, and rugged industrial system. A PXI system is controlled by an embedded controller with a high "performance multi-GHz processor. You can choose modules from National Instruments or third-party PXI and CompactPCI vendors. PXI offers the widest range of I/O including 1000 V isolated analog input, high-density digital I/O, analog and digital frame grabbers for machine vision, and coordinated multi-axis motion. It provides easy access to cabling with connectors on the front of PXI modules. The PXI platform offers a broad range of measurement modules, and connectivity to field devices using CAN, DeviceNET, RS-232, RS-485, Modbus, and Foundation Fieldbus.

The Compact FieldPoint product line consists of hot-swappable analog and digital I/O modules and controllers with Ethernet and serial interfaces. I/O modules provide direct connectivity with thermocouples, RTDs, strain gauges, 4-20 mA sensors, and 5-30 VDC and 0-250 VAC signals. Compact FieldPoint network communication interfaces automatically publish measurements through an Ethernet network. You can access I/O points nearby or miles away on the network using the same simple read/write software framework. With a simple software interface, Compact FieldPoint is quick to setup and program, but provides enough power to perform complex control, data logging, and communications.

The Compact Vision System combines a high performance Intel processor with an FPGA, digital I/O and three 1394 ports. This PAC is designed to incorporate vision into control applications through the use of FireWire (IEEE 1394) technology, compatible with more than 80 industrial cameras. With a reconfigurable FPGA and digital I/O lines on the CVS, you also get low-channel digital and stepper motor control. When programmed with LabVIEW, the system can be configured for both high performance vision and high speed digital control and stepper motor control.

CompactRIO is an FPGA based reconfigurable control and acquisition system designed for applications that require a high degree of customization and high speed control. The architecture combines a real-time embedded processor for complex algorithms and custom calculations with a reconfigurable I/O (RIO) FPGA core. The CompactRIO platform will accommodate up to eight analog or digital I/O modules manufactured by either National Instruments or other companies. The CompactRIO platform is ideal for complex and high speed applications such as machine control and with FPGA is a good option for applications that would normally require custom hardware development.

Todd Walter is a Product Manager at National Instruments of Austin, Texas.