Moving from Models to Control Code

Like knights on a quest for the Holy Grail, automation engineers are in hot pursuit of better models of control behavior. For some, however, the quest goes beyond just looking for efficient architectures. It includes a faster way to generate the code.

For automation professionals, the Holy Grail is an object that will help them to tighten their control over their products and give their companies a competitive advantage. Thomas Debes and his colleagues at manroland AG seem to have found this elusive object in a technique. They have found that modeling the controls on the printing presses that their Augsburg, Germany-based employer has been building for 160 years makes it much easier to test and optimize control algorithms.

“We can quickly change the structure of the controller and immediately see the results,” explains Debes, lead software engineer at the press builder.“The ability to perform rapid iterations enabled us to optimize quality and functionality while greatly reducing development cycle time.”

He and his colleagues represent a small but growing group of automation engineers who are exploiting tools and guidelines developed by suppliers and standards committees for modeling control behavior. The purpose of these models is to aid control developers as they design and program their machines or process controls. Besides helping them to develop and validate efficient system architectures, some of these tools can even generate code automatically.

Although the idea of building a model and using it to simulate control behavior and generate code is not a novel idea, it is new to many industries using programmable logic controllers (PLCs). Part of the reason is that automation programmers often think that they are already doing design. “Programming IDEs [integrated development environments] like RSLogix or Step 7 are not really system design tools,” explains Tony Lennon, industry marketing manager for industrial automation and machinery at MathWorks, a Natick, Mass-based software supplier. “They’re programming tools, and they don’t let engineers simulate the behavior of the control system.”

Comparing the modeling tools that his company offers to computer-aided design (CAD) software, Lennon refers to the model as a kind of prototype. Using CAD software, a designer produces a computer model of a part or assembly. After constructing the model, the designer can put it through various kinds of computer analyses and even use it to generate a physical prototype. If the computer model fails a stress analysis, or if a prototype made from it fits together poorly, the designer goes back to the CAD model to figure out why.

“And, you can generate code from your 3D CAD model for a CNC (computer numerical control) machine tool to use,” he says. “If you find a mistake [in the part] while you’re machining a part, you correct the model. You don’t go into the G code on the CNC machine.” At least, that is sound practice.

The control-system model serves a similar purpose. Model-based design, as MathWorks calls it, allows a systems designer or controls engineer to develop a model of the control scheme and to use the model for programming control algorithms in C code or another language. “You can test your control algorithm first with desktop simulation and then run the code on a real-time test system connected to the real machine,” says Lennon. “If you find mistakes or don’t like the way the machine is handling under certain conditions, you go back to your model in your design environment to figure out why the problem is happening. You make changes to the model and generate new code.”

Pretty picture

At manroland, the objective was to use this form of prototyping to tighten the precision of its printing presses, thereby improving image clarity and placement on the page. One project, for example, entailed improving the accuracy of the cut registers on a press, which align the printed material beneath roller blades before cutting it into pages. High-quality magazines require the cuts to be within 0.3 millimeters (mm). Because the material travels through the press at 15 meters per second, the control algorithm has just 10 milliseconds to execute the task.

To provide its engineers with a better way to develop production-ready controls for the cut registers, management bought some tools from MathWork’s Simulink line of products. Using them, the engineers developed models of the press and of a control scheme based on a proportional integral derivative (PID) controller. After conducting open-loop tests to find the optimal control strategy and running closed-loop simulations to validate the controller, the engineers used a product called Real-Time Workshop to generate C code from the models.

They then ran real-time simulations with another product called xPC Target. Among the scenarios simulated were various abnormal behaviors that are difficult to reconstruct on real hardware. “We were able to test the controller under many error conditions that we would not otherwise have been able to test,” says Debes. Based on the collected data, the engineers optimized performance by fine-tuning the controller model, which worked as designed in production.

Another benefit of adopting model-based design was that it cut development time by a little more than half. According to Debes, developing the controller took 10 months, which was about a year shorter than was typical before the adoption of model-based design. One of the reasons is that the method permitted generating code in about 10 minutes after each design iteration of the complex model, rather than the weeks required in the past. A bonus to building the model is that manroland’s service-and-support staff can use it to troubleshoot problems for their customers before going into the field.

Better batch control

Designers of printing presses, packaging machines and other automated machinery are not the only automation professionals who can benefit from modeling. Engineers in the process industries can too. For this reason, vendors have been quick to build their products around the universal model that the International Society of Automation (ISA), in Research Triangle Park, N.C., has specified in its ISA88 batch control standard.

For example, Milwaukee-based supplier Rockwell Automation Inc. based its FactoryTalk Batch software on the batch standard, embedded the ISA88 model in its Logix controllers with its PhaseManager, and developed solutions for its PlantPAx process system that also support the standard. One is a procedural sequence management engine called PlantPAx Logix Batch and Sequence Manager, which permits users to configure their sequences and formulas in the controller without having to change any code. Consequently, programming becomes more of a configuration task than a coding project, according to Andy Stump, segment manager of batch, information and APC for Rockwell’s process business.

One company that took advantage of these services is Patheon Inc., a contract manufacturer serving the pharmaceutical and biotechnology industries from its headquarters in Research Triangle Park, N.C., and various plants around the world. Building control models around industry standards was not a consideration when its Cincinnati plant initially asked Rockwell Automation for help in migrating to the vendor’s PlantPAx process automation system. The consultants, however, convinced the automation team there of the wisdom of developing standard control models.

Because the plant does contract work, the challenge was to design the control models to apply to all jobs. Not only does the plant have a large inventory of disparate equipment for its various contracts, but it also continues to acquire new equipment as new and existing jobs require. “Every piece of equipment is a little different,” notes Julie Robinson, one of three automation engineers at Patheon’s Cincinnati plant.

One of these differences is that the newer equipment tends to be more complex, usually coming with more instrumentation. Hence, it was fortuitous that the migration would begin with the new granulation suite and four coating pans that management wanted put into production as soon as possible. The models developed at this phase would describe the more complex cases.

Another complication for the first phases of both the migration and model development was the variety in the ways that customers want things done. This multiplies the number of parameters used for control. “In the coating pan, for example, you can control off inlet or outlet temperature,” offers Robinson. In other unit operations, some customers will specify a particular time to end a batch, but others will rely on temperature or even operator judgment.

Variation—not a problem

Rockwell’s consultants and Patheon’s automation team built those and other variations into the models. “So when you’re building a recipe for a product, you can customize it for that product,” says Robinson. “Then, our recipes and phases could become much more reusable.” New control models have the flexibility built into them to accommodate both the different control schemes required by customers and the differences among the multiple generations of equipment in the plant.

Although Robinson was able to use some of Rockwell Automation’s pre-programmed modules, she and the rest of Patheon’s team did most of the programming themselves manually, line by line. They never considered outsourcing the task or looking for tools to automate it, for two reasons. First was the amount of customization needed by the disparate processes and equipment. Second, “we wanted to maintain the expertise on site,” she explains. “We’re the ones who are called in the middle of the night when something goes wrong, so we wanted to make sure that we knew exactly how all the programs were coded.”

Before loading the code into any equipment and doing any field wiring, Patheon’s automation team tested its programs on real-time computers. The company’s client-server architecture allowed the team to run programs on one of the clients using Rockwell’s simulation functions. “It looks like you’re running a real batch, but you’re just not opening valves or any of the field I/O (input/output),” notes Robinson.

Constructing the control models from class-based modules both simplifies this testing and the stringent change documentation required of pharmaceutical companies by the U.S. Food and Drug Administration. “By establishing these models and class-based control modules, you test each one time,” says Robinson. “It has helped to streamline our testing, especially with the number of new pieces of equipment that are coming in.” It’s just a better way from moving models to control code.

Related Feature - Factoring Safety into Factory Controls
To read the feature article relating to this story, go to http://www.automationworld.com/feature-8235.

Subscribe to Automation World's RSS Feeds for Feature Articles

More in Home