INDUSTRIAL PC VS. PLC This article is a joined effort from the Control & Information Group of Rockwell Automation CHOICES: Perspectives on the Future of Automation Control
"With all the controller choices available, making an informed decision requires you to look beyond the box and into how the core functions solve your application." INTRODUCTION
s we look at different visions of the future, the directions people are taking and the technologies that are emerging, we find a common theme throughout - CHOICES. There are no absolutes. What works for you may not work for your peers, and the right solution in one application may be completely wrong in another. Instead, there is an exciting array of choices at every level of the manufacturing enterprise. It's certainly the case with controllers, the subject of this installment in the Rockwell Automation CHOICES white paper series. In Part One, we presented an overview of the key drivers for the future of manufacturing. We then took these key drivers and drew conclusions about how these drivers translate into trends affecting control systems. If you haven't read Part One, we urge you to do so, as it provides a good foundation for subsequent installments. In this installment, we'll tie those trends specifically to the choices available in controllers, and we'll outline factors for you to consider when searching for a solution that meets your unique requirements. Other installments in this series will deal with networking, I/O, sensors and actuators, power devices and other core automation technologies. When you're through with this paper, we hope you'll have a clearer understanding of where we think controller technology and applications are going. We won't make a heavy-handed push for a single solution, and we'll admit that there are some pieces to this puzzle that we can't or won't supply. We'll help you identify the options, and let you make an informed choice. And we want your feedback. If you like what you hear, tell us. If you don't, tell us that too. If you have an idea, we want to know. We'll listen and we'll respond. A industrial controller systems at an incredibly fast rate. It took decades from the time the integrated circuit was introduced to the time when the programmable controller came on the market. Fuzzy logic technology, which originated only a few short years ago, is now being used to help maintain consistency in plastic injection molding controllers. The CAN (controller area network) technology originally developed for automobiles is now used by controllers for better networking with factory floor devices. Pentium® chips, introduced only a few years ago, are now the standard for personal computer-based control systems. With this new technology comes a risk. Historically, longer adoption cycles helped to make sure that technologies applied in controllers were proven to work and work reliably. Now, new technologies find their way into the control system much faster, requiring you, as a purchaser, to make an extra effort to evaluate the relative risk you can afford to take. Take, for instance, PCMCIA (Personal Computer Memory Card International Association) technology. Developed in 1991 for personal computers, PCMCIA cards are now a common add-on feature for many control systems. While the cards are convenient, easy to use and widely available, there are still questions about the reliability and robustness of the technology and the hardware. That doesn't mean they shouldn't be applied - what it means is that their use in an industrial environment brings with it some degree of risk, and a willingness to assume more risk in terms of reliability in exchange for PCMCIA's flexibility benefits. Granular Architectures
In a sense, controller technology has come full circle with respect to architecture. Relays provided nearly a one-to-one I/O ratio, but control requirements and features drove the industry toward more centralized programmable controllers (PLCs) and distributed control systems (DCS). A pyramid emerged as the primary model for control - with multiple functions being controlled by a large central computer or control system. Now the pendulum is swinging back the other way. As manufacturers found a need to tightly control specific elements of the process, and as technology allowed for cost-effective distribution, the centralized control model was broken up into more logical, granular components. In the past where a single, large programmable controller was responsible for all functions in a manufacturing cell, there now reside multiple small, or even "micro-" controllers networked together. These multiple systems are often linked to other types of con- Automation Trends Have Impact on Controllers
In Part One of the CHOICES series, we outlined five major trends impacting the automation system: faster adoption of new technology, increased granularity of the control system, the emerging role of "open" systems, more application-specific control solutions and the changing role of the factory worker. Not surprisingly, these major trends continue to have an impact on controller evolution. New Technology Introduction
New technologies - often developed in government and commercial sectors - are finding their way into
16 Real-Time Magazine 97-4 INDUSTRIAL PC VS. PLC Figure 1a. Relay Logic Control Figure 1b. Relay Logic Concepts trollers as well - motion control systems, personal computers, single loop controllers, miniature DCS systems, etc. Open Systems
The word "open" has joined politics and religion as a topic sure to generate a lot of debate and even argument. No two definitions are alike, and it doesn't look like any resolution is in sight. For that reason, we believe that instead of viewing open systems as a place in time or a specific end, we have to look at it as a continuum - and a multi-dimensional one at that. Openness has appeared in nearly all aspects of the controller - programming methods, operating systems, operator interface (OI) schemes, hardware platforms, networking and I/O. This means that control system purchasers must evaluate levels and degrees of controller openness based on achieving some more tangible goal - lower costs, higher quality, faster changeovers, increased reliability, easier use, etc. On its own, "open" is just another meaningless word - and choosing openness for openness' sake can be a costly, time-consuming proposition. troller no longer just handles I/O, but also sends critical data to operators via plant floor workstations and displays, and to other parts of the enterprise via manufacturing execution (MES) systems and even outside the factory via the Internet or Intranet. TRADITIONAL DEFINITIONS FOR CONTROL
Depending on whom you talk to, the term controller can have a lot of different meanings. For a garage door OEM, the controller could be a small bank of relays. For an injection molding machine maker, it could be a custom-built "black box" controller. For a potato chip manufacturer it could be a programmable controller. For a nuclear reactor it could be a DCS, and for a distribution warehouse it might even be a personal computer. Up until now, control has been defined by the "box" that performed it. For purposes of review, we'll spend a little bit of time going over some of the basic types of controllers - relays, SBCs, programmable controllers, motion controllers and DCS. Application - Specific Solutions
Controllers have become more application-specific in nature as well, moving from a "controlling a process" function to controlling information. Through the 1980s, you could basically identify six different types of controllers - black box (or embedded), relay, single-board computer (SBC), programmable controller, computer numerical controller (CNC) and DCS. Now, through the use of custom application software and firmware, these six basic systems have been "morphed" to produce a wide range of application-specific products injection mold controllers, loop controllers, batch controllers, motion controllers and many more. And many customers have most or all of these within the same installation. Relay-based Control
Prior to the development of electronic control solutions, electromechanical relays (and their pneumatic and hydraulic cousins) were the standard means of control. Relays essentially serve as switching, timing and multiplying mechanisms for input devices, such as push buttons, selector switches and photoelectric sensors (see figure 1a and 1b). Relays tend to operate intuitively; however, as mechanical devices, they do not offer the same programming and troubleshooting flexibility found in modern programmable control systems. Relays are also known for taking up considerable amounts of space, requiring extensive wiring, and need regular maintenance (see figure 2). Still, while we originally thought that relays would disappear with the advent of solid-state forms of control, they've instead shown incredible resilience. Many factories are using the same relays they did 20 years ago, and are perfectly comfortable with their performance. In addition, many control applications use relays in conjunction with more sophisticated forms of control for isolation and other specialized electrical Role of the Factory Worker
Finally, the changing role of the factory worker has had an impact on the controller evolution as well. Factory floor workers are more skilled and more involved in maintaining and improving the manufacturing operation than ever before. That involvement requires more meaningful decision-making information. The con- Real-Time Magazine 97-4 17 INDUSTRIAL PC VS. PLC
Some Improvement was needed
Relatively highr installation cost - numerous components, high labor content Difficult to troubleshoot - no diagnostic for control system or process Difficult to modify or expand - more writing !! Limited operator interface - perhaps a lamp or mimic panel Limited functionality - analog ? math ? communications ? Figure 2. Some improvement was needed Figure 4. Relay Ladder Logic functions. A future installment of the CHOICES series will cover the choices in electromechanical devices in more detail. cannot be achieved using standard, off-the-shelf control products. Programmable Controllers
The first programmable controller, introduced in 1970, was developed in response to a demand from General Motors for a solid-state system that had the flexibility of a computer, yet could be programmed and maintained by plant engineers and technicians. These early programmable controllers took up less space than the relays, counters, timers and other control components they replaced, and they offered much greater flexibility in terms of their re-programming capability (see figure 3). The initial programming language, based on the ladder diagrams and electrical symbols commonly used by electricians, was key to industry acceptance of the programmable controller (see figure 4). Because programmable controllers can be programmed in relay ladder logic, it is relatively simple to convert electrical diagrams to the programmable controller program. This process involves defining the rules of operation for each control point, converting these rules to ladder logic, and identifying and labeling Single-Board Controllers
The first electronic controls on circuit boards -- or SBCs - appeared in the early 1960s. These "logic modules" were created by piling discrete components, such as transistors, capacitors and resistors onto boards. These solid-state systems were inherently more reliable than relays because there were no moving parts to wear out. In addition, there are numerous costs associated with installing, operating and maintaining SBCs above and beyond the initial hardware cost. Because they are not typically available off-the-shelf, costs for SBCs involve securing the services of an electrical engineer to design the board and test for viability. Still, even today, many original equipment manufacturers choose to design and develop single-board controllers for their own unique machine applications. An SBC is usually very specific to a machine and can be cost effective initially. This is perfectly appropriate when the specific capabilities required by the machine Figure 3. Basic PLC Components 18 Real-Time Magazine 97-4 INDUSTRIAL PC VS. PLC
outputs (addressing). Today's engineering force has a mix of engineers - so of who have been around for a while and are familiar with ladder logic as well as newer engineers more comfortable with Windows NT based programming and control. This calls for a mix of programming technology that are applied based on user background and application need. There are two major types of programmable controllers - fixed and modular. Fixed programmable controllers come as self-contained units with a processor, power supply and a predetermined number of discrete and analog inputs and outputs. A fixed programmable controller may have separate, interconnectable components for expansion, and is smaller, cheaper and easier to install. However, modular controllers are more flexible, offering options for I/O capacity, processor memory size, input voltage and communication type and quantity. Originally, programmable controllers were used in control applications where I/O was digital. They were ideal for applications that were more sequential and more discrete than continuous in nature. Over time, analog and process capabilities were added such that the programmable controller became a viable solution for batch and process control applications. The evolution of programmable control has transformed controllers into an attractive option for control systems that have traditionally relied on alternative technologies. Until the introduction of the micro-PLC in the middle 1980s, relays and SBCs offered the most common means to increase automation on simple machines and less complex processes. Even though the functionality of the traditional programmable controller often benefited an application, the cost could not always be justified. If cost was not an issue, size often was. Sometimes even small programmable controllers were simply too large to fit in the space allocated for electrical controls. It wasn't until micro-PLCs were introduced that programmable controllers could economically meet the demands of smaller machines in a more efficient manApplication Characteristic Relay ner than relays and SBCs. These fixed I/O controllers are generally designed to handle 10 to 32 I/O in a package that costs less than $300 U.S., making them viable replacements for even very small panels of relays. In addition, this low-cost controller option has opened the door for many small machine OEMs to apply automated control in places where it wasn't feasible in the past - for instance, one manufacturer uses a micro-PLC as the control source in lottery ticket counting machines. Although there are many factors that need to be taken into consideration before determining whether a relay, SBC, micro-PLC or full-size programmable controller is appropriate for the application, the following chart shows how each of the four meet some of the basic application requirements (see figure 5). The "Soft" Controller
When a technology such as a programmable controller has been on the market for more than 25 years (notwithstanding the myriad of upgrades, technology advancements and variations introduced since then), the natural question that arises is "What will replace it?" We asked the same question about relays 25 years ago, and relays are still alive and kicking. A more appropriate question may be "What else is needed?" There has been some push to promote PC-based programmable control - or "soft control" - as the replacement for the programmable controller. In essence, soft control is the act of replacing traditional controllers with software that allows you to perform programmable controller functions on a personal computer. Simply put, it's a "PLC" in a PC box. Soft control is an important development for individuals who have control applications with a high degree of information processing content; but it's important to look upon soft control as a variation of the traditional programmable controller, not unlike the micro-PLCs. Soft control, however, is only part of a larger trend - that of "PC-based control". PC-based control is the concept of applying control functions normally embedded in hardware or software to the control platforms. This encompasses not just Micro-PLC SBC Full-size Programmable Controller 32 - 1,000s Yes Yes Yes Yes Yes Yes Variable Meg Inputs/outputs Timers Up/down counters High-speed capabilities Data calculations Data acquisition Communications Operator interfaces Memory Size 1 per relay Yes Yes No No No No Primitive N/A Up to 32 Yes Yes Yes Yes Yes Limited Variable 1-10K Varies Yes Yes Yes Yes Yes Yes Variable 8K-256M up to 2 Figure 5. Evaluation of Control Methods for the Application Real-Time Magazine 97-4 19 INDUSTRIAL PC VS. PLC
method, called function block programming, allows a developer to program the system by mimicking the actual process and data flow. DCSs allow for reliable communication and control within a process; the DCS takes a hierarchical approach to control, with the majority of the intelligence housed in a centralized computer. This larger system is also a relatively higher priced choice for control. A good analogy for the DCS is the mainframe computer and desktop computers. Not long ago it would be unheard of for companies to base their corporate computing on anything but a mainframe computer. With the explosive growth in hardware and software capability in recent years, many companies are now basing their corporate computing on networking numerous powerful desktop computers. They have more power than yesterday's mainframes in a flexible, user-friendly network environment at a fraction of associated mainframe costs. Likewise, today's DCS systems are more distributed than in the past. DCSs are generally used in applications where the proportion of analog to digital is higher than a 60:40 ratio, and the control functions performed are more sophisticated. DCSs are ideal for industries where the process is continuous, has a high analog content and throughput, is distributed across a large geographical region and where down time is very expensive, such as the pulp and paper, refining industries and chemical industries. A DCS is the model solution when the end user is focused on a specific application, such as load shedding. But if the end user has a load shedding application, along with 50 ancillary tanks that feed into the process, the end user must make a decision of whether to use a programmable controller or a DCS. The load shedding application can be controlled bet- Figure 6. Key Attributes of the PC versus the PLC the control engine, but all aspects of the control system, including programming, operator interface (OI), operating system, communication application programming interfaces (API), networking and I/O. Distributed Control Systems
Distributed Control Systems (DCS) are the evolutionary product of the process control industry. The DCS was developed in the mid 1970s as a replacement for the single-loop digital and analog controllers as well as central computer systems. A DCS typically consists of unit controllers which can handle multiple loops, multiplexer units to handle large amount of I/O, operator and engineering interface workstations, a historian, foreign device gateways and an advanced control function in a system "box," or computer. All these are fully integrated and usually connected via a communication network. DCS suppliers have traditionally taken the approach of melding technology together with application expertise to solve a specific problem. Even the programming DCS Core Competency: Process industry applications Single-loop control replacement Complex analog I/O High resolution I/O Function block programming Centralized control Integrated OI Windows NT or Unix operating system Limited third-party device support Case tools for configuration Specialized vendor application expertise PLC Core Competency Discrete manufacturing control Relay replacement Digital and moderate analog I/O Medium resolution I/O Ladder logic programming Decentralized and centralized control OI as peripheral/add-on Proprietary operating system Wide range of third party device Case tools for configuration General-purpose and specialized vendor application expertise Loop closure (100ms) 20 Real-Time Magazine 97-4 Ad Real-Time Consult INDUSTRIAL PC VS. PLC
ter by a DCS, but PLCs can control the 50 tanks better. End users have the option of using both, but that can significantly increase the cost of the process and forces the end user to become familiar with and maintain two different types of control. Figure 7 shows the basic historical core competencies of the two systems. It is not meant to be a comparison, nor is it meant to indicate absolutes. The lines between the two are blurring, as they are within most of the control models. functions (see figure 8). All controllers require a programming method, control logic engine, OI, communication interfaces to I/O and the programming systems, an operating system and a hardware platform/package. Understanding the choices available for each of these functions will help users make a more informed decision about the proper control for their applications. To make an informed decision on which controller is Programming Control Engine Operating System Hardware Platform Networks and I/O Devices
Figure 8. Choices for a Soft Control Solution A Case for New Definitions of Control
As stated before, we tend to define control not so much by its function, but instead by the "box" that's performing it. That method served us well in the past, but if we continue to use these methods to define control in the future, the confusion will continue to pile up. If you populate a printed circuit board with electronic relays, is it relay-based control or single-board control? Programmable controllers use printed circuit boards in an array, so are they programmable controllers or single-board controls? A soft controller uses the same programming language, I/O interfaces and OI as the traditional programmable controller, so is it PC-based control or simply a variation of a PLC? PLCs now can be programmed with function blocks and have the capability to handle analog I/O. So, if they're used in a process application, such as batch control, are they programmable controllers or simply variations of a DCS? Likewise, you can now run function block programming and analog I/O on commercial personal computers. Does that mean it's a PC or is it now a DCS? DCS suppliers are moving away from the Unix operating system and building their next products on Microsoft Windows NT - so are these vendors getting out of the DCS business and into PC-based process control? The answer, from the end user's perspective, should be "WHO CARES?" Instead of defining control by the box performing it, we need to start defining control by virtue of the problems it solves. In Part One of the CHOICES series, we identified the emergence of more application-specific control systems as a major trend affecting manufacturing. We need to look at what the system does instead of focusing in on which solution is typically used. In order to do that, we need to break the controller down into its finite elements, and identify the choices available at each of these levels. MMI best for your situation; you need to first understand the concept of the responsibility/risk continuum. On the left side of the continuum are the choices that involve a high degree of vendor responsibility - in the form of quality, testing for specific environments, tight integration and built-in support. Of course, along with this high vendor responsibility comes a higher initial price tag, but the overall risk and costs assumed by the customer is less as well (see figure 9). On the right side of the continuum are choices that reflect multiple vendor options, and as a result, these choices require a higher degree of risk by the user. That's not all bad, especially if the user is confident enough in his or her own experience and skills to perform a majority of the integration, customization and support functions internally or via third parties. They're willing to assume the risk in exchange for having the flexibility of a multi-vendor environment. This responsibility/risk continuum can be applied to all functions of the controller - including programming, control engine, OI, I/O communications interfaces, operating system and hardware/packaging. Incidentally, the continuum can also be applied to other less-tangible attributes, such as type of support, level of supplier contact, degree of "openness" and even methods for receiving information on new technologies. CHOICES AT ALL LEVELS
Today's solid-state control consists of a set of base Hardware Platforms/Packaging
This is a logical place to start, since most of the other Figure 9. The Responsibility/Risk Continuum 22 Real-Time Magazine 97-4 INDUSTRIAL PC VS. PLC Figure 10. The Extended Risk/Responsibility Continuum components can be discussed within the context of the hardware it's running on. However, we're quickly moving toward a time when the software - and not the hardware - will drive the controller choice. You can parallel it to the commercial computer industry. You used to make a decision to buy an IBM-compatible machine or a Macintosh. Now, you determine what software you want to run, and choose the hardware platform accordingly. On the far left side of the responsibility/risk continuum are relays and SBCs. In both cases, the vendor takes nearly full responsibility for the reliability, maintainability and integration (after all, you can't get more fully integrated than a relay). Little or no work is required to make either of these products work specifically for their applications - it's simply install and go. Slightly to the right of those systems are a myriad of programmable controllers. They all feature vendor-specific packaging and usually have custom ASICs and firmware that are the result of years of research and experience. Again, the vendor has taken most of the responsibility for design of the controller, but has given the user more flexibility in terms of programming and application in the destination facility. Slightly to the right is controller hardware that uses commercial-grade ASICs and processors as opposed to vendor-specific hardware. However, these systems typically still use the same packaging as the programmable controllers, in order to take advantage of the robust I/O and design for more rugged manufacturing environments. A good example is the open controller from Rockwell Automation/Allen-Bradley. It looks like a programmable controller, but has the same processor technology found in most of today's personal computers. In cases where users apply these types of systems, the vendor has taken responsibility for the hardware design, packaging and reliability, but the user has assumed responsibility for not just the programming, but also the operating system and application software choices. Open bus systems in which multiple vendors supply modules provide more choices for the users and less vendor responsibility. Examples include VME, Multibus, PCI and PC-104. A little further to the right is the blended approach, which provides the benefits of both open and dedicated systems. In this kind of solution, a PLC is responsible for direct control of the process while an industrial PC handles the HMI, PLC programming, data logging and communications functions. This solution is ideal for critical applications that require operators to input a lot of process production variables and log large amounts of data. In a purely open system, the industrial computer serves as the brain of the system, handling not only the HMI tasks, data handling and communication, but also controlling the actual application. Ideal for applications that require maximum flexibility due to frequent changes in the manufacturing process, an open control system can be easily upgraded. For example, end-users can upgrade to new con- Figure 11. The Hardware Responsibility/Risk Continuum Real-Time Magazine 97-4 23 INDUSTRIAL PC VS. PLC
trol software, add extra PC memory or upgrade the PC by adding an expansion chassis to accommodate any additional communication option cards. On the far right of the responsibility/risk continuum are "white box" personal computers. They of course use commercial-grade chips (like the Intel® Pentium®) and likewise almost always have a commercial operating system such as Microsoft® Windows® NT or Windows 95. In this control scenario, the end-user can mix and match components from a variety of vendors. However, this choice means that either the end-user or a capable systems integrator is taking responsibility for the control system as a whole. Applying a commercial grade computer as a controller requires the user to take a higher degree of responsibility for the overall system and reliability because he or she made the choice to use off-the-shelf components and take care of the integration and customization internally. While the initial cost of investing in a white box PC may be quite a bit less than an industrial PC, the long-term maintenance and support of a white box PC can be very expensive in terms of downtime and replacements. Furthermore, such extras as climate-controlled enclosures are expensive to purchase and costly to maintain. Over the life cycle of the PC, these additional hidden enclosure costs can more than offset the cost savings of purchasing a white box PC. And failure of a PC-based control solution not appropriately matched for an application is more than just a financial issue it is a safety issue, as well. The vendor however, can minimize risk for users by prepackaging the technologies they offer as in the hardened PC platform (see figure 11). firmware, and is specific to that vendor only. Today's programmable controller operating systems, like the hardware platform, are the result of more than 25 years of evolution to provide the determinism, industry-hardened design, repeatability and reliability required on the plant floor. In the past, achieving these objectives meant choosing a vendor-specific operating system and choosing that vendor's entire control solution as well. This can be a benefit if risk is to be avoided, but can be a detriment if a high degree of inhouse customization and integration is needed (see figure 12). If you choose a hardware platform that falls further to the right on the continuum, your options for operating systems broaden. A commercial-grade Pentium-class chip allows you to then choose between what's often called a real-time operating system (RTOS), such as Quix or Vertex, and a commercial-grade operating system, such as Microsoft Windows NT. An RTOS is an operating system that was developed specifically for high-reliability applications such as those found in manufacturing or telecommunications industries. It has been successful in situations where the user is concerned about the reliability of the system, but not so concerned as to sacrifice flexibility and cost benefits associated with commercially available hardware. Real-time operating systems typically come with a base set of programming tools specific to that vendors' offering, and the communication drivers to other third-party peripherals either have to be customwritten or purchased as add-ons. Some vendors have been successful by taking an RTOS, developing a set of add-on configuration tools and drivers, and offering them as development environments optimized for specific industries. This is quite common among suppliers to the telecommunications industry, and also is done in automation controls industry by companies like Controlware and QNX. The typical purchaser of these offerings is the OEM who wants to run control on a commercial hardware platform, but has some specific control system expertise that requires more reliability and security. It's not uncommon for someone who has made the choice to purchase commercial grade controller hardware in programmable controller packaging to then choose an industry-optimized RTOS to run on it, since the core Choices in Operating Systems
Closely linked to the hardware/packaging choice is the operating system. A debate similar to the old "Windows vs. Macintosh in the office" debate is taking place in regard to controllers for the manufacturing enterprise. The operating system, put simply, is software that defines how the information flows between the processor chip, the memory and any peripheral devices. The operating systems for programmable controllers and distributed computer systems are usually developed by the vendor, optimizing the company's particular product offering and applications. In these cases, the operating system is embedded in Figure 12. Degrees of Operating System Interoperability 24 Real-Time Magazine 97-4 Ad Radisys INDUSTRIAL PC VS. PLC
requirements are the same. Commercial-grade operating systems like Microsoft Windows NT have quickly come on the scene as viable choices for control on Intel-based hardware platforms. Earlier versions of Windows were deemed not to be robust enough for control applications. However, with the introduction of Windows NT, more control vendors are advocating this commercial operating system as a viable choice for users with information-intensive control applications. In addition, an industry standard operating system allows the user access to a wide range of development tools from multiple vendors, all working in a common environment. Even so, there is debate about the robustness of NT and its appropriateness for real-time control. In these debates, the term real-time is often relative. A few companies have developed what are known as real-time extensions (RTXs) for NT that claim to improve NT's real-time capabilities. The degree to which these extensions improve performance and the degree to which they affect NT's data handling and integration capabilities is still up for debate. For more information on the use of NT for control, please refer to the Rockwell Automation White Paper, "Windows NT for Soft Real-Time Control - Separating the Fact from the Fiction." for the most part configured using function block programming, but some DCSs also offer ladder-programming options. Many DCS vendors are riding the popularity of the Windows NT and 95 environments to allow function block programming in more familiar industry standard environments. Finally, some users may, if they are particularly adept at programming, choose to use a standard commercial development package such as Visual Basic to design their own programs. Some controllers may even be programmed using a combination of methods. For instance, if the application is primarily discrete, there's a good chance the user could program the application in ladder logic. However, for a small portion of the application that is process-oriented - the user could embed function blocks where appropriate. In fact, some companies now offer a variety of editors (ladder, SFC, function block, etc.) that program a variety of open and dedicated platforms. How do you choose? Again, it depends on your application, but if you view your programming method on the responsibility/risk continuum, your choice may become clearer. If you're most concerned that the programming method you choose is optimized for your particular controller, then you might want to choose a method on the left side of the continuum. If, however, you're looking for a more "generic" programming method, and are comfortable enough in your own abilities to modify it for your situation, you may choose a method more on the right side of the continuum (see figure 13). Programming Methods
Programming methods were, at one time, directly defined by the "box" being programmed. Relays require no "software" programming - the logic is hardwired. SBCs typically have no external programming by the end user, so that one's easy. Programmable controllers always used ladder logic programming packages designed for specific vendor programmable controllers. In other words, you couldn't use an AllenBradley programming package on a GE/Fanuc controller (or vice versa). DCS systems used function block programming specific to vendor, while personal computer users typically used higher-level languages such as Microsoft Basic or Perl and today, C/C++, Java or Visual Basic. Now there's a good deal of crossover. In addition to ladder logic, many programmable controllers can be configured using flow chart (SFC), function block or structured text programming methods. DCSs are still Logic Engines
The logic engine itself can be a basic choice - not just "controller, DCS, or PC," but really "open or proprietary." A user should determine how the logic engine would integrate with the rest of the control system. Does the user want an on-line editor, or off-line? Does he or she want fixed function and data structure, or would an engine with user-defined function and structure be preferred? Will the user benefit more from compiled data, versus interpreted? The logic engine's available functions will determine the level of integration with other control system components and, ultimately, the level of openness at which Figure 13. The Programming Responsibility/Risk Continuum 26 Real-Time Magazine 97-4 INDUSTRIAL PC VS. PLC
it operates. Users needing higher integration and increased access to data may want a more open logic engine choice. Speed
The applicability of general-purpose commercial products for machine and process control platforms also generates no small debates. The term "real-time" is used very freely in the control system market. Realtime means that a transaction or event is processed as quickly and predictably as possible without it being saved to a file for batch processing at some later time. Thus it is the application that determines how quickly real-time processing must be. Real-time for an Automated Teller Machine (ATM), for example, can be measured in seconds while users of motion control systems require real-time response in fractions of milliseconds. This broad range of performance requirements is one of the first areas to examine when talking about controllers within an operating environment. How fast must the controller be? How repeatable must it be? When a controller or DCS is dissected, it is discovered that they are built around a hardware platform and an operating system as well. Substantially more proprietary than the hardware and software of the personal computer, industrial control platform operating systems are also far more focused than those supporting commercial operating systems are. While similar to commercial products in many ways, an operating system for controllers also has some very distinguishing features. It's important to determine what speed means within the context of your own control application - and not to get involved in an exercise of evaluating specifications for specifications' sake. Human-Machine Interface
This paper will not spend a great deal of time on the choices for human-machine interface, because it's a topic that is so broad that it will require a paper on its own. Suffice it to say that even the simplest controller needs some sort of operator interface device, whether it be a simple push button panel or a highly sophisticated software package running on a personal computer. There is a wide range of choices in-between, and each can be evaluated based on the degree of responsibility/risk that the user is willing to take on, as well as the capability and training of the operator. KEY CONSIDERATIONS: MAKING AN INFORMED CHOICE
So, we've established that there are choices available not just for controllers, but for the functions within the controller as well. As you determine which options are right for you, there are a number of factors to consider: Openness
As discussed in the first CHOICES white paper, there are degrees of openness within a control system. You can have an open programming method on a vendorspecific controller, as defined by IEC 1131.3. You can run your application on commercial hardware but use an RTOS. You can use a white-box (Micros: wide range of white box PCs) personal computer or an industrial computer running Windows NT, but then choose to use a vendor's proprietary control software and I/O system. Choosing an "open" controller shouldn't be the goal. Instead, choose the controller that meets your requirements for interoperability, reliability, application flexibility, support and cost. A question to ask when considering a PC-based engine is, "Do I want to run other software - aside from control - on the machine?" Evaluate openness in the context of these criteria, as opposed to an end unto itself. Reliability/Environmental Operation
Industrial automation systems traditionally have substantially longer life cycles that do not require continuous increases in system performance and software enhancement. In many cases the only requirement will be replacement of spare parts for the lifetime of the system. Commercial environments, on the other hand, force migration at least every 24 months, with new commercial developments and upgrades. This raises a number of hardware issues. Can the hardware you've chosen withstand the rigors of your manufacturing environment, or are you looking at having to shut down every six months to upgrade computers? If your environment is clean, dust-free and lownoise, is it worth it to purchase something that's really designed for rugged manufacturing? Many vendors support the idea that an ordinary office or "white box" PC can be used in a PC-based control system, leading end-users to believe that all PCs provide the same "service". That statement isn't necessarily true; very few "white box" PCs are robust enough to handle the industrial factory floor environment. Demands put on a shop floor PC require that it exceed standard operational requirements for speed, reliability, flexibility, agility, ease of system upgrades and rugged operation. The industrial computer is designed to withstand the assault of airborne contaminants, vibration, shock and extreme temperatures-all of which can become factors
Real-Time Magazine 97-4 System Integrity
An operating system is at the heart of all open architecture solutions. And talking about operating systems can inspire emotional responses. A fundamental set of requirements - speed, scale, packaging, reliability, and peripherals -must be satisfied before successfully applying any control system technology to control systems. Some of these requirements will be specific to industry segments (process, motion or discrete) while others will be broadly applicable to all aspects of industrial control. The vast majority of the requirements for operator interface and program development has been satisfactorily met by the existing commercial operating systems products and has broad market acceptance. It is also a foregone conclusion that Windows-based solutions will be desired and accepted for these functions for the foreseeable future. 27 INDUSTRIAL PC VS. PLC
on the shop floor. Many industrial PCs feature TFT flat panel displays, shock-mounted hard drives, solid-state flash hard drives with no moving parts, filtered ballbearing cooling fans, internal temperature sensors, uninterruptible power supplies, redundant hard drives and system control monitor cards. Additionally, many industrial PCs with integrated CRT displays are designed with a high degree of EMI (electromagnetic interference) shielding to prevent electrical interference from causing display problems. These continuing improvements are designed to bring the robustness of dedicated PLC-based control systems to PC-based control systems. Sometimes the argument can be made that some applications do not require an industrially hardened computer. For example, a computer working in a control booth away from the factory floor or on the factory floor in a climate-controlled enclosure may seem to have little need to be robust. Can an office-grade PC run an industrial process? The answer is almost always yes. But is it necessarily an appropriate solution? From the standpoint of reliability and robustness, probably not. With the choices available now in hardware and packaging, you'll be able to more closely match the solution to your application. But don't assume reliability and environmental operation are hardware-only issues. From the standpoint of the operating system, it brings into question a number of practices that must be evaluated. It is a common practice for commercial operating systems to be upgraded every 18 months. It is also quite common to not be able to get a fix until the next release. Can the control solution live with this level of support? If so, you may want to use it. If not, then maybe an alternative is more appropriate. It must be viewed as a requirement, jointly shared by hardware and software vendors, to assure compatibility for the life cycle of open architecture systems. If, as an industry, we are willing to accept system and software upgrades every 18 - 24 months, then commercial products can satisfactorily be employed. This is the heart of the operating system decision. While it would be ideal to utilize a commercial operating system for all control applications, we must not forget the critical application requirements it must serve. The control operating system is not limited in scope to interaction with operators, but instead it must also deal with continuous, real-time response to electrical and mechanical conditions. into a wide array of process applications. In addition, the emergence of specialty I/O modules allow controllers to manage process functions such as temperature control, weigh scale load cells, plastic injection molding, and high-speed analog to digital/digital to analog conversions. Emergence of controller-compatible process function libraries, expanded OI capabilities (both hardware and software) and the debut of more capable networks also have increased the controller's prominence in process applications. While programmable controllers have reached maturity in a few applications, such as packaging and material handling, they are in a growth pattern for a number of others. Micro-PLCs, for instance, are expanding rapidly into the commercial markets and industrial applications because their compact size and low cost make them ideal for OEM and end-user applications. Programmable controllers, in general, are also being applied to a broader range of applications, especially process control and SCADA telemetry-type applications, such as food and chemical processing, water/wastewater, and oil and gas pipelines. This transition has been made possible because controllers now offer a complete process tool kit and the communication capabilities required by telemetry-type applications. The evolution of the high-end and low-end controllers will be quite different. Many process manufacturers especially in SCADA applications (water/wastewater, oil extraction, etc.) are looking to replace their dedicated Remote Terminal Units (RTUs -small, relatively inexpensive SBCs) with small programmable controllers for cost, reliability and ease-of-use reasons. This has only been possible in recent years as networking capabilities of these systems improved. On the high end, larger PCs and programmable controllers with more memory and I/O capabilities are becoming commonplace in small batch operations, places where the DCS was the system of choice in the past. DCS systems, on the other hand, have evolved as well by adding more sequential capabilities. In addition, there are more opportunities to productively combine different functions in one control system. In effect, the lines have blurred between the DCS and the programmable controller. Installation/Integration
The footprint of controllers has been reduced over the past few years by several hundred percent. Customers have less panel space and, more importantly, are less inclined to pay for excess functionality. If they want the controller to solve a given problem, they want the controller optimized to solve that problem, not problems primarily found in other applications. In other words, you don't want to buy a scientific calculator if you only want to do four-function math. Another key factor impacting the size of the controller has been the emergence of more distributed and "granular" I/O solutions. The physical packaging of a given function is changing, which helps simplify the integration process. For instance, an I/O chassi