
December 1996 Volume 6 Number 12
IN THE EARLY 1980s, microcomputers and programmable logic controllers (PLCs) revolutionized industry. Industrial designers used these powerful tools to develop complex control programs, yet meaningful laboratory testing for control software did not exist. Back then, neither the control engineers nor the designers of the plant could forecast how well the controls would perform; how long it would take to bring the plant into production; or how much the installation and testing would cost.
This "build and bash" technique for testing and installing control software was costly and inefficient. industry needed a method for testing control logic using software modeling instead of the real plant. In the 1990s, advanced software modeling provides the answers to the questions: How well? How long? How much?
Today, detailed software modeling&emdash;in the form of simulation and emulation&emdash;can be used to test control concepts, as well as to monitor and diagnose the actual day-to-day plant operation.
Even today, many would-be end users of software modeling confuse simulation and emulation. However, the difference between the two is distinct and important . Simulation is generally applied in the early stages of a project and uses simplifying assumptions to predict overall system performance (See Table 1).

Emulation, on the other hand, is applied during the detailed design and implementation phases of a project (See Table 2).

Why emulate?
Emulation models are very detailed. Unlike simulation, emulation
makes no simplifying assumptions about the system being modeled. The
value of emulation modeling as a test tool is strongly related to the
accuracy with which the emulation model reflects the system to be
controlled.
Every industry has horror stories of "two-week startups" that last three months. These startup delays mean lost production, plus the additional cost of salaries and expenses of the startup personnel, and in most cases, the salaries of idle production personnel. A startup delay extending into months can cost a company considerably more than the total cost of the system's controls. According to a study by Ford Motor Co., less than 40 percent of the development effort is spent on programming the control system, while the other 60 percent is spent on debugging, testing, and installation.
An emulation model provides a means to test the completed PLC software before the software is installed in the field. The process of emulation is very effective at eliminating bugs from PLC code. Testing using an emulator exercises all aspects of the control software including load movement, load tracking, throughput capability, error reporting, and error recovery. Code tested using emulation has typically been 95 to 98 percent complete and correct before it is installed in the field.
An emulation model, coupled with tested PLC code, provides a test bed on which host computer software can be tested. One approach to software performance testing is to emulate the manufacturing equipment using an emulator and run the control software as if it were in actual operation. An emulator can be connected to the programmable controllers to test the software implementation and debug the control system. The emulator can replace conveyors, storage system, guided vehicles, robots, and other physical equipment, so that the control system can be tested in real time.
Lemm Corp., a multi-million dollar chemical packaging firm in Memphis, Tenn., did just that when its designers had to design and build a fully operational facility in just 12 months. To accomplish this feat, each phase of development happened concurrently with the help of strong vendor support and advanced computer-modeling software.
The Lemm project culminated with an unprecedented three-day test, in which the entire operation was emulated in real time. In an off-site computer lab, the Lemm team set up the plant's computer system. The painstakingly detailed test involved all aspects of real-world production, complete with errors that were introduced, customer changes and customer-returned product. The plant's high-level computer system was linked directly to the PLCs to control all the terminals, emulated equipment, product movement, and storage.
During the three-day test, individual operating scenarios were created to train users on specific operations. In addition to mundane chores like ordering supplies, the scenarios also generated abnormal conditions, which helped Lemm's system operators learn the correct responses should the real system ever malfunction.
The test was not simply an exercise of control software, but the exercise of Lemm's entire operation in real time. Not only did the software modeling technique emulate and test production elements, but it also tested Lemm's inventory control, automatic order replenishment, radio-frequency order fulfillment and shipping procedures.
After the three-day test, the computer system and control software
were shipped to Lemm as the building reached completion.
Simultaneously, all of the equipment was installed and checked out,
so when the computers arrived, they were plugged into the VAX host,
and the entire plant was brought on-line at once.
Simulating discussion
While emulation is ideal for proving the validity of control
logic, simulation has a role to play, too. While simulation doesn't
test the actual code, it does help verify design concepts and
workable configurations. For instance, simulation may tell you
whether you need four aisles or five aisles in an AS/RS, but it will
never tell you whether the computer programs to control the system
are going to function the way you intend them to function.
In general, simulation models are used for virtual prototyping of proposed systems. In the warehouse environment, for instance, they are used to test system design and ensure throughput goals can be met. Without question, simulation can be a great risk-reducer in complex, multi-million dollar systems.
For example, Retrotech Inc. (Fishers, N.Y.), a system integration company specializing in updating automated warehouses, was hired to replace a complex AS/RS conveyor system at the Prairie du Chien-Wisconsin facility of 3M. The company developed the entire system in its office on a PC using real-time simulation and emulation. Retrotech was able to run the system as though the conveyors and cranes existed. In this way, they were able to test the control code and run a real-time demo for the customer before the system was shipped.
Lemm Corp. used simulation modeling in addition to emulation. In the design phase, simulation modeling incorporated all the components of the Lemm facility, which would ultimately process several tons of bulk chemicals per hour. The model showed how bulk chemicals would arrive at the plant in railcar hoppers. In precise detail, it showed exactly how the 180,000-pound loads would be unloaded into individual 200-pound drums for storage and eventual shipment to domestic and overseas customers. All of the systems in the plant, including the flow rack, conveyors, bulk handling and storage were included in the model.
To develop the model, the Lemm team used the facilities conveyor and bulk handling system layout and design drawings that described the physical conveyor system. This information was entered into the modeling software's database, and the resulting representational model included the parameters that described the distances, the motion of loads over the conveyors, the speed of the conveyors, adverse conditions that might block the flow of the load's transfer operations from one station to another, and the mechanisms to change the position of loads as they moved through the plant.
In the first month of the project, the team was able to tie the building footprint and equipment layout together. By doing this, it enabled the project's equipment vendors to work on their systems during the construction of the building.
The model enabled the vendors to know exactly how their equipment would fit into the overall project. Even before the plant's walls were raised, Lemm's equipment vendors could build their systems knowing that they would provide the functionality that Lemm needed.
In a complex system where a large number of dependent subsystems must be integrated, or where the controls are very sophisticated, a simulation will generally more than pay for itself. That's because the risk of expensive system design errors is greater, and the added extras that may be discovered during a simulation can actually help take costs out of a system.
Simulations can be a valuable tool provided that the input
accurately represents system requirements, and that the proper
modeling language, offering appropriate flexibility, is used.
However, simulation will only be as good as the data and system
parameters incorporated into the model.
The right approach
Another technique for debugging PLC ladder logic is to use two PLCs
back-to-back. One PLC runs the logic to be tested, and the other PLC
is programmed to emulate the equipment. One refinement of this
technique is to substitute a PC for the second PLC. Then ladder logic
is written on a personal computer, which is interfaced to the PLC
running the logic to be tested.
The main drawback to this approach is that although ladder logic is ideal for controlling automated equipment, it is woefully inadequate for simulating the operation of the equipment being controlled. Using ladder logic as a simulation model is like using COBOL to control automated equipment or ladder logic to generate business reports. Users of this technique have reported that it works in very simple systems, but is insufficient for complex systems. Imagine attempting to use ladder logic to program the speed and accumulation characteristics of a sortation system.
The key to avoiding these difficulties is to use real-time modeling software. Real-time software is designed to handle stimuli from external sources. And, be sure the software that you select has the multi-mode capability to allow the same model to run stand alone in simulation mode, connect to a PLC in emulation mode, and to diagnose failures in the actual system in monitor mode.
Once a system has been tested and debugged using real-time simulation and emulation techniques, the model may live on as a separate, but attached, diagnostic monitor (if the modeling software you select provides this capability). By using the existing model as a diagnostic tool, equipment failures can be prevented, maintenance can be reduced, and modifications to the system can be made to an existing facility without halting production operations&emdash;and after all, that's why you created the model in the first place.
|
Virtual Training Simulation can be a very powerful training tool for designers, management, system operators, and maintenance personnel. The simulator can offer hands-on training without the risk and expense of using the real system. In addition, a simulated system can generate numerous abnormal conditions that can help the operators and maintenance personnel respond correctly should the system actually encounter such misfortune. For instance, Accudyne Inc. (Raleigh, N.C.), a leading circuit board manufacturer, trains maintenance mechanics on the intricacies of PLC maintenance and operation without incurring any machine downtime or any disruption to its manufacturing operations using simulation training models. By using the models instead of real equipment for training, Accudyne has not lost any production time, and its technicians have learned what they need to know without tying up production equipment. Here's how the training models work: Trainees are provided with a sequence of operations and the correct I/O; then they are challenged to design the controls for the machine model that they are working on. Once control code is written, trainees see the machine run in real time on a PC. The virtual machine reacts exactly as it would in the real world. |
For more information about this article, input the number 6
in the appropriate
place on the
December
Reader Service Form