Control Engines, Controllers, and Soft PLCs

There are a lot of alternatives for a control engine / controller:

• Manual control (no automatic control is always an alternative)
• Single loop controllers
• Special purpose controllers
• Embedded controllers: There are both Windows compatible and non Windows compatible OSs
• Traditional PLC
• Soft(ware) PLC 
• General purpose computers
• Distributed Control System (DCS)

The purpose of automation (in this case automatic control) is to make things better (higher quality), faster (higher efficiency and production rates), and cheaper than doing it manually.  Manual control should be considered as the baseline to compare the advantages of an automated system. 

There are a lot of operations that are moving to low labor rate countries that do not use automation.  Does this make sense?  If you have a very low cost and low quality product then yes, we would think it makes sense.  With high cost and high quality products we think that skilled labor and automation make more sense. 

Single loop controllers (and their cousins, the special purpose controllers) are great for when you only have one parameter / function / device you need to control.  However, we have been in control rooms where there were probably one hundred single loop controllers.  Our response was "Wow!  You must really like single loop controllers."  The biggest problem with single loop controllers is that once you start to put two or more together, PLCs and other controllers start to make sense, so that the control and monitoring across all functions are integrated. 

Even with a PLC or other controller it might be wise to use a single loop or special purpose controller.  For example, we have used special purpose / single loop controllers for boilers, heating, compressors, motion control and robotics, welders, E-stops, printers, and other special purpose applications where we wanted to reduce our risk and code development or the company has incredible knowledge and insight on how to control the particular equipment.  So don't lose sight of the fact that single loop and special purpose controllers can be integrated into larger controllers. 

We don't see traditional Programmable Logic Controllers (PLCs) going away.  They are built to withstand the factory floor, easily connect to industrial wiring, and are good at real-time control. 

There are many new devices that are hard to classify.  For example, what is the difference between a "brick" PLC and I/O with an embedded controller?  They are not meant to control large processes -- just that local group of I/O.  For larger applications they would require a higher level controller to coordinate all of the separate controllers. 

For many years, sales people for "soft" PLCs have predicting the doom of traditional PLCs.  A soft PLC is a program that runs on an ordinary computer that mimics the operation of a standard PLC.  Opponents of soft PLCs point to the "blue screen of death" and other unreliable operations of the PC as the disadvantage.  We think that both of these opinions are unfair.  Our suggestion is if you know what you are doing then try one of these soft PLCs on a non critical process first.  To make computers as stable as PLCs please see our webpage on computers. 

In the old days, large "real-time" computers were used in a lot of automation applications.  Now that the smaller computers have as much speed, large computers are no longer used. 

Today's general purpose computer controllers can be most anything from a PC running Visual Basic or C# to a workstation running proprietary code.  Coupled with ordinary networks, computers provide redundancy in that there is one computer per process but the network makes their data available to everyone. 

There are a lot of "embedded computers" based on PC/104, compact PCI, STD, and other types of computer buses to integrate different modules.  There are single task and real-time, multi-tasking operating systems available.  These controllers tend to be inexpensive and small in size. 

Distributed Control Systems (DCS) are huge mainframe like systems veiled in secrecy so that the company can charge you lots of money upfront for the system and then again every year for the support contracts.  They work good -- it's all of the extraordinary costs that make them unpopular. 

The line between what is a PLC, DCS, computer, I/O, or other controller becomes more blurred every day.  Don't get caught up in what you call something -- focus on what is best for the application and what the customer is comfortable with. 

Our Experience and Suggestion

Our experience shows that for most applications there are two components -- strategy and execution.  The strategy is the operator interface, "big picture", recipe management, data logging for later analysis, etc.  The execution is the real-time control -- banging outputs on and off.  As you move up the operations hierarchy strategy becomes more intense.  As you move down the hierarchy, strategy becomes less. 

Our preferred controllers for most applications are a (any) traditional PLC and a computer running Visual Basic or C#.  Customers are very comfortable with installing PLCs to run their processes and like the ideas of saving thousands of dollars per computer and being able to do more by using Visual Basic / C#.  We feel that this combination gives the customer a powerful platform at a reasonable cost. 

Going back to our model of the infrastructure, we prefer one PLC and one computer per process.  In complex operations this one PLC and computer per machine.  In simple operations this is one PLC and computer per department or line.  The PLC is controlling, monitoring, and integrating everything in this process and the computer allows the PLC and process to interface to the outside world -- operators, other processes, and higher level systems. 

Redundancy

For critical applications where redundancy is required there are many choices.  The main problem is what type of redundancy is used -- just the controller?  Redundant I/O?  Redundant controller and I/O?  Redundant controller, communications, and I/O.  Allen-Bradley (Rockwell),  Siemens, GE Fanuc, SoftPLC and others have truly redundant, automatic fail-over PLC systems off-the-shelf. 

Back in the 1980s we played a lot with redundancy -- but dropped it because in almost twenty years, have never had a requirement for a true redundant system.  We played a lot with Allen-Bradley PLCs in the VME rack and GE Fanuc's Genius I/O.  A-B PLCs being the most popular PLC and Genius I/O because it was the best at detecting faults and feeding that information back to the controller.  The first trick is that both controllers read the same inputs but only one controller controls the outputs.  The second trick is trying to determine why and when you switch the outputs from one controller to another. 

What everyone wants is "bumpless" transfer.  In other words, when the PLC controlling the outputs has any fault, they want the outputs to switch over to the second PLC without any outputs being in the wrong state.  In other words (again) -- they don't want the outputs going crazy while the system switches processors.  Needless to say, there are many interesting scenarios:

• A logic error, such as math overflow would fault both PLCs
• Many errors are minor errors that may or may not cause the control to switch to the other processor
• Do the CPU scans have to be synchronized in order to have "bumpless" transfer?

Centralized or Distributed

Most applications we see for redundancy are based on the never ending argument over one huge centralized controller or several smaller, distributed controllers.  The case for one huge centralized controller is that it is easier to maintain -- you only have to maintain one controller.  If there are multiple parts to the process that are all dependent on each other with no buffer (tanks, inventory, etc.) in between then it is hard to argue against one centralized controller.  Because if one controller stops -- they all have to stop.  However, for large operations where there are several independent operations, with buffers in between, it is hard to argue against several distributed controllers.  If one controller fails then just that one section of the total operation fails.  All the other areas keep on running. 

We feel that the best architecture is one that mirrors the users.  Some users have a global, centralized view and other users have an isolated view.  Therefore, both centralized and distributed controllers should be used.  One theory you might want to remember is -- keep the data, control, decision making at the lowest controller possible.  In other words, if certain items do not need to be shared amongst similar level controllers -- then don't have the data reside in a higher level controller. 

Frequently Asked Questions (FAQs)

Are other types of control engines reliable?  Most of these have been around for over a decade.  A lot can depend on the capabilities of the programmer.  Some programmers need more support and safety nets than others and would be better off using a PLC.  However, for good programmers, control engines can offer advantages over PLCs.  Our advice is to try new technology on simple and non critical processes first.  

See also

• PLCs 
• PLC tutorial 
• Industrial Networking 
• Visual Basic & C# for Automation 
• Industrial Computers & Peripherals

Links

• EG3 -- embedded systems, DSP, real-time/RTOS, board-level computing, soc and more
• EMJ Embedded Systems 
• JK Microsystems -- embedded computers

• Parallax -- Basic Stamp embedded computers

• PC Engines -- embedded computers

• SoftPLC -- combines PID, discrete and analog I/O control of PLC's with the high-performance data handling, computational and networking capabilities of computers
• Steeplechase 
• Tern -- embedded computers
• TRI -- embedded computers
• TwinCAT -- The Beckhoff TwinCAT Software System turns any compatible PC into a real-time controller with a multi-PLC system, NC axis control, programming environment and operating station
• VersaLogic -- industrial embedded computer boards
• Virgo -- softplc by  Altersys
• WinAC -- softplc by Siemens
• WinSystems 

• Z-World -- embedded computers

We try to offer a fair and balanced opinion on every page of our website.  We would appreciate more information from other users to express their opinions which we will then incorporate.  If you have questions or comments please post them on our message board (see button in left hand column) so that others can read and benefit.