If you are looking at PACs for your application, here are some pointers
By Kelly Downey and Jean Femia
Modern industrial applications are becoming more complex. They now require the integration of multiple systems; they require process, discrete, and motion control; and they require realtime communication with company databases. That is where programmable automation controllers (PACs) come in.
In the new age of automation, the goal behind PACs is to meet the complex demands of today’s applications by combining features of more traditional automation technologies: programmable logic controllers (PLCs), distributed control systems (DCSs), remote terminal units (RTUs), and personal computers (PCs).
PACs on the market today have varying capabilities. When you are choosing a PAC for an application, there are considerations to keep in mind from a hardware and software perspective.
For a new system, a PAC can monitor, control, and offer data acquisition capabilities plus Ethernet connections with company computers. In addition, a PAC provides full analog and digital control, motion control, the ability to interface with serial devices, and remote monitoring.
A PAC can also reduce network hardware expenditures by providing features such as extra built-in network interfaces.
For an existing installation, a PAC can consolidate separate systems and link them with company computers, so you can exchange control, production, and monitoring data, as needed.
Verify that new PACs are compatible with all legacy systems you need to consolidate, including all networks and protocols.
PACs can combine distributed control with remote communication options, so they can handle extensive systems with remote installations.
Choose PACs to suit the size of your system. A PAC that mounts on the I/O rack is probably more suited to cell control, RTU-type installations, or smaller systems. You will need more powerful, standalone PACs for more extensive systems.
For the most efficient PAC-based system, choose one that utilizes distributed intelligence, not just a distributed architecture. Distributed intelligence offloads many control functions to remote processors co-located with distributed I/O. Distributed intelligence shortens wiring runs, reduces network traffic, maintains critical control should communications fail, and frees up the central controller for supervisory tasks.
As it is with any system, choose a PAC that has all the networking and communication options you need, or think you will need down the road, already built in. Networks may include among others, wired or wireless Ethernet and serial.
Communication options might include OPC, Modbus or Modbus/TCP, Profibus, Allen-Bradley DF1, and other standards on the control side. For communication with computer networks, you may also need protocols such as TCP/IP, SMTP for e-mail, SNMP for network management, and FTP for file transfer.
In contrast to a PC, part of the appeal to a PAC is they are industrially hardened and built to withstand normal industrial use. Check the PAC’s specs for temperature and humidity tolerances.
If your application involves extreme temperatures, vibration, dampness, dust, electrical noise, or other exceptional conditions, you should look at necessary enclosures and protection just as you would for a traditional control system.
Signal requirements for inputs and outputs vary widely. Look for systems offering reliable I/O with the signals you need. These signals may include temperature, rate, RMS, pH/ORP, load cell, and others, in addition to voltage and current. The PAC should be able to communicate with all signal types, rather than requiring signal conditioners.
Where there is limited cabinet space, high-density I/O is a good choice. Software-configurable I/O—for example, an input module configurable as any of several thermocouple types—offers flexibility and reduces the number of spares you need to have on hand.
For advanced control, make sure you can satisfy requirements for high-speed digital control, motion control, PID loop control, and mathematically complex logic without expensive add-ons.
Because a PAC is similar to a PC, the integrated software that comes with it includes advanced programming features such as subroutines, string handling, complex conditions, and floating-point math. In addition, a PAC can often be programmed in C or other standard programming languages.
When it comes to the operator interface, check out the PAC-based system’s human-machine interface (HMI) options. The integrated software development environment should use a single tagname database, so once you define variables and I/O in the control software, you can immediately use them in the HMI software.
A PAC should also offer communication with third-party HMIs using OPC. And other options, such as a touchscreen terminal, may be available as well.
For data acquisition applications, choose a PAC system with two strengths: First, substantial memory for acquiring and storing data; and second, the ability to share data directly with corporate databases over an Ethernet network.
If control networks and computer networks need separation, consider how you will accomplish this. One way is to segment networks using independent Ethernet network interfaces on the PAC itself.
When it comes to hardware, you do need to plan for the future. When your needs change, the same PAC should handle additional distributed I/O, as well as process, discrete, and motion control..
All of these types of control should be programmable in the same software as part of the same system, and most changes should require no middleware or add-ons.
A PAC is able to reach facets of the manufacturing process.
Software is a key part of a PAC’s system capabilities. According to the ARC Advisory Group, among a PAC's defining characteristics are three elements directly related to software:
- Tightly integrated controller hardware and software. The software used with a PAC is designed specifically for the PAC.
- A single development platform, using common tagging and a single database for development tasks across a range of disciplines.
- Programmability using software tools capable of designing control programs to support a process that “flows” across several machines or units.
When hardware and software are designed together, systems become easier and faster to build. It is easier just for the simple fact it does not require drivers, which means parts of the system naturally work together; it is not necessary to debug driver problems or fix incompatibilities.
The software built for a PAC not only integrates with the hardware it runs on, it also integrates internally. It provides not only an integrated development environment (IDE) for programming but also a suite of related programs for HMI development and other purposes.
The IDE is a single software program that handles everything related to control programming, such as editing, compiling, and debugging. A software suite, made up of two or more software applications, offers a similar look and feel in all of them, so familiarity with one helps you use the others more easily.
The software applications in the suite work together behind the scenes in ways that significantly reduce development time.
Common tagging means names and definitions you set up in one of the suite’s applications are also used in the others. If you define a string variable in the control development software, that same definition will be used in the HMI development software. If you name a digital I/O point in the control software, that name will automatically appear when you're configuring OPC data communications.
Because all these common tags you define remain in a single database with all the applications in the software suite use, you don't have to reenter tags or maintain and reconcile lists of them. As a result, development tasks can wrap up quickly and easily.
Because a key defining characteristic of PACs is that the same hardware can see use in multiple domains, including logic, motion, drives, and process control, it follows that the software must be capable of programming all control and monitoring tasks that must occur in multiple domains.
That means the PAC software must handle discrete control, process control, motion control, remote monitoring, and data acquisition. And the software must let the developer mix and incorporate these as needed into control programs, so these programs can “flow” as the requirements of the application dictate.
For example, suppose your company is a microbrewery. Here are just some of the requirements for producing your end product:
- Water is piped in from a spring a couple of miles away, so you need to monitor the pressure and flow of that water as well as security at the spring (remote monitoring using analog and digital devices).
- You measure water quality as it enters your facility, track this data over time, and store it in your company database (data acquisition, database connectivity).
- You make more than one microbrew, so recipes, temperatures, and processing must vary (batch process control, PID loop control, distributed control).
- Operator interfaces mimic the process, providing secure interactive controls for technicians and operators.
- Quality control is essential to your reputation, so you test all products at several stages. You keep quality data as required by government health authorities (monitoring, more data acquisition and database connectivity).
- In another building, the bottling line requires discrete control. As bottles come off the line, they are boxed and identified with radio-frequency identification (RFID) tags, then sent on to shipping.
- In the separate shipping area, boxed stock automatically moves via conveyors (discrete control) based on RFID tags (serial device connectivity).
- Temperatures in the storage area remain controlled and monitored. The company monitors energy usage and systems remain controlled throughout all buildings (remote I/O, distributed intelligence).
- Production and inventory data go directly from machines and barcode readers to company computers; customer and shipping data flows in the opposite direction (database connectivity).
This microbrewery is an example of how several different types of control in several different domains are required by a modern industrial automation application. Because the application requires processes that flow into each other over space and time, the PAC software accommodates that flow and integrates these multiple domains into one system.
ABOUT THE AUTHORS
Kelly Downey, M.S.E.E. is a project engineer, and Jean Femia, M.A. is a technical writer at Opto 22.
It is easier to understand and evaluate a new technology if you can see how its capabilities compare with known technologies. The chart compares features of a PAC with common features of PCs, PLCs, DCSs, and RTUs.
Return to Previous Page