Control engineers have long seen the value of re-using software programs running control operations. That value has increased dramatically in the past few years as companies demand that engineering staffs shorten project times to save costs and get products to market faster. Some would argue that control engineers are not programmers and shouldn't have to become so involved with the intricacies...
AT A GLANCE
Economics of portability
Generic code application
Expanding beyond IEC 61131
Cross-platform information architecture
Product lifecycle effect
Sidebars: Programming architecture
Control engineers have long seen the value of re-using software programs running control operations. That value has increased dramatically in the past few years as companies demand that engineering staffs shorten project times to save costs and get products to market faster.
Some would argue that control engineers are not programmers and shouldn’t have to become so involved with the intricacies of code crunching. But software is too ingrained in the automation process to surrender the powerful functionality inherent in programming to anyone who does not fully comprehend the automation that software controls. That’s why control engineers should become nearly as familiar with today’s programming tools as they are with loop tuning. Fortunately, advances in multi-platform programming languages are making it easier for engineers to give up less of their engineering identity yet still become more IT proficient.
Software programming languages most used by control engineers are addressed by the IEC 61131-3 standard. The standard includes the definition of the sequential function chart language, instruction list, ladder diagram, function block diagram and structured text (see Back to Basics, Control Engineering , July 2003, for more information). The standard sets structures for the various languages, increasing their re-usability, reducing errors, and increasing programming and user efficiency.
Despite advances made by IEC 61131-3 to standardize those languages and broaden their use, a large rift still exists between vendors that use proprietary versions of these languages and how languages are used in North America and in Europe.
“There’s a huge difference between North America and Europe with regard to IEC,” says Wolfgang Langer, Schneider Electric’s software product manager. “About 70 to 80% of engineers use IEC languages in Europe. In North America, it’s almost the opposite.”
Peter Durand, president of Entivity, explains, “You’ve got the IEC languages as well as people programming in C, Visual Basic, and even some Java, although that hasn’t made a play in controls yet. But what we’re starting to see is that customers are more receptive to pursuing something that’s more intuitive. Something that one person can write and everyone else can understand.”
The biggest challenge multi-platform programming languages face in the control market is adoption in the installed base. “Engineering management doesn’t always want to change the programming language even if it’s the right thing to do, because they’ve got 50 people trained on relay ladder logic, they don’t want to retrain them, and the engineers often don’t want to be retrained,” says Durand.
Retraining, however, is likely inevitable.
“I used to work in a controls department where there were 10 engineers,” says Durand. “Now there are two, but there’s still the same amount of work.”
Real world
Mark Ollander is the vice president of control technology at The Conair Group, a plastics auxiliary machinery manufacturer based in Pittsburgh, Pa., that makes use of both PLC and embedded real-time programming environments.
“Some of the legacy designs of our control platforms [used in PLCs for loading control and conveying of resins materials] were developed in such a way that each program and each control evolution was designed and built uniquely for that control application,” says Ollander. “So there was no cross control application use of the code, no reusable code, no structured memory.”
The newer designs Conair has been rolling out over the last year and a half have been designed in a “generic sense” from the memory architecture side for a variety of applications, such as permutations in the material-conveying controller, says Ollander.
Conair reached this point of generic design to enable programs to be written once and then reused for the varied application requirements by observing the unique control solutions fielded at their customer plants. Observation showed many recurring themes. As a result, Conair directed a complete redesign of the code structure so that it would maximize reusability and take on a generic structure.
“The result became an exercise in parameterization through the operator interface at the job site to get each application configured,” says Ollander, “rather than requiring a PC with special software and configuring the application using the development environment.”
Conair predominantly uses Rockwell Automation’s Logix platform as well as the S7 platform from Siemens Energy & Automation.
“Our whole idea for the screenware and the PLC control code is to have the logic, algorithms, and memory allocations organized in such a way that we don’t hard code anything to specific devices or mandate devices must reside at a physical I/O location,” Ollander says. “We’re doing as much as we can through indirect addressing, which allows us virtually infinite scalability from the very simple applications to the very complex, using exactly the same code, and using screenware parameterization to configure the type of devices we’re hanging off the physical hardware.”
Because Conair is using Ethernet and structured memory mapping, data can be communicated from the PLC to the operator interface, through the supervisory layer, and even up to the corporate level. The result is direct connectivity across the enterprise.
“The software architecture we have in place is designed not just to be reusable, but generic in its interconnectivity so it adds little burden in terms of engineering and installation time for integrated applications,” Ollander says. “This keeps our project time down because we develop an application solution once and the rest of the time it’s ROI.”
Getting into the game
Program reusability is a great concept gaining wider traction, as shown by what companies like Conair have achieved. But since each vendor’s implementation is often slightly different, and controls implementations have often been in place for years, the ability to completely reuse code across different suppliers’ platforms or systems is very rare. “In most cases it will be necessary to rewrite some percentage of the code,” says Kim Fenrich, systems marketing manager, Industrial IT systems marketing, ABB.
The portability of IEC 61131 languages can effect the entire production process.
Fenrich says that although the 61131 standard was developed to facilitate this type of reuse across platforms, and ABB has embraced and endorsed this standard, some vendors still do not. Therefore reuse of code between compliant and non-compliant platforms/systems may not be possible. “In some cases, based upon vendor implementation, compliance with 61131 does not guarantee complete reuse,” Fenrich says.
“At the moment, our customers are seeing the greatest benefit of 61131 not to be cross-platform compatibility, but the ability to have multiple engineering disciplines use a specific control environment with which they are comfortable, all in the same system. For instance, ABB’s Industrial IT supports all five 61131 languages, allowing engineers with a PLC background to program in ladder, while those with a DCS background can use function block.”
Despite the advantages of 61131 and its support by numerous vendors, the languages involved in the standard don’t completely address the needs of control engineers.
Ron Bliss, Logix/NetLinx marketing manager for Rockwell Automation, says, “The problem with IEC 61131 is that it only goes so far. It gives you the basic level instruction, such as add, subtract, multiply, divide. It provides a standard environment for creating the applications, but then it stops when you have to do the work. You have to write your own PID instruction, for example.”
With economic factors continually impacting manufacturing first and hardest, the pressure on engineers to find the kinds of efficiencies provided by reusable code will likely keep the issue of program portability alive and well.
That being said, if you’re just starting to look at this issue, the first things to consider are the two types of software platforms an engineer would use: configuration-based and a full-fledged programming environment.
According to Jennifer Dieterle, product manager for LabView, National Instruments, configuration-based platforms are defined by vendors through a given a set of functions the platform can execute. Other codes cannot be imported. For example, in ladder logic a set of functions is provided; to go beyond that is very difficult. In a full-fledged programming environment like LabView or C or Visual Basic, pieces of code are written in other languages, (such as dynamic link libraries in Microsoft Windows), so you can package code and use it in other environments.
“If you can get all the functionality needed within a configuration-based program, that’s going to be fastest, because most of the programming has been done,” says Dieterle. “However, it’s very rare that type of environment can survive for many years.”
Making sense of it all
Faced with various options and claims touted by vendors, it’s little wonder that the manufacturing market sticks close to what it knows works, and lets those on the bleeding edge prove out the more viable advances before moving ahead with wide-scale adoption. However, changes in the business of manufacturing are requiring engineers to heed the call for multi-platform software.
Colin Masson, research director at AMR Research for CPG (consumer packaged goods), life sciences and process industries, says more pressure on new product introductions and compressed lifecycles are driving manufacturing as a whole toward more of a product lifecycle management approach.
“This requires the control engineer to communicate with the business in a more timely and structured manner, because many more changes now have to be implemented. The impact on the control engineer now is that regardless of where he needs to execute a control strategy, he’s going to have to deal with a specification or recipe management system providing him with frequent changes. He can’t work in isolation at the hardware level any longer. As a result, I don’t think there are many engineers today working with proprietary implementations of ladder logic from a particular vendor,” Masson says.
Much of the drastic change engineers will face when it comes to combining software programming and engineering will be faced by a new crop of engineers.
“In the case of IEC software, younger engineers who are familiar with computers and Microsoft software are most likely to recognize the benefits of this new programming approach and adopt it,” says Schneider’s Langer. “The graphical support is a natural environment for today’s young engineers.
Comments? E-mail [email protected]
Programming architecture
In a typical factory setting you can have sequential applications (such as materials handling), motion applications, and process solutions. These different disciplines have to merge to create a synergistic manufacturing operation capable of delivering to today’s business requirements. Such a combination requires a programming environment that supports the needs of those different disciplines.
“In the past, a DCS ran the batching operations, a motion controller from a different vendor ran the motion side of things, and a PLC ran the conveyor,” says Ron Bliss, Logix/NetLinx marketing manager for Rockwell Automation. “People want to get away from having to learn how to use all these different controllers and all the interlocking and handshaking that has to take place in this kind of setup.”
Beyond the controller programming architecture lies the area of plant-wide connectivity. Invensys is looking to make a major push in this area with Archestra, an industrial automation and information architecture that it claims will work with any other vendor’s hardware or software.
“It [Archestra] is at a level above the Microsoft platform,” says Mark Davidson, vice president of marketing for Archestra. “You’re not opening up Visual Studio.NET and starting to program. It’s an application infrastructure that’s built for plant engineers and system integrators. Under the covers it’s all Microsoft and .NET, and people can extend this with Visual Studio, but you don’t have to have programming knowledge to work with the system as designed.”
Invensys claims Archestra provides the common integration functions that most industrial applications need (such as alarming, security, historization, data communications, and configuration). Built-in software management, including those to handle global changes, can then be deployed remotely across networks to manage the application wherever it is being used. This enables Archestra’s grandest claim—to write and reuse code as extensively as desired with none of the hardware/software linkage issues inherent in the 61131 languages.
Key to Archestra’s ability to deliver on its promises is its ability to link existing legacy systems as advertised. “We have more than 1,000 communication interfaces that have been developed over the last decade to link all kinds of older systems in plants,” says Davidson. “All those drivers and interfaces are part of Archestra and can be linked via a proxy object.”
