In the past, programmable logic controllers (PLCs) were programmed with proprietary software in relay ladder logic. Screen navigation was with function keys. Almost no way existed to reuse the program from one machine to the next. For some issues from a user's viewpoint see the sidebar from General Motors Power Train.
KEY WORDS
Machine control
Programming
Microsoft Windows
Software for control
Programmable logic controllers (PLCs)
Sidebars: IEC 61131-3 Definitions GM Power Train reveals software vision
In the past, programmable logic controllers (PLCs) were programmed with proprietary software in relay ladder logic. Screen navigation was with function keys. Almost no way existed to reuse the program from one machine to the next. For some issues from a user’s viewpoint see the sidebar from General Motors Power Train.
Programming software looks and acts much different today. Most engineers and technicians are at least familiar with, if not trained in, Microsoft Windows. 32-bit tools such as “drag-and-drop,” “cut-copy-paste,” dialog boxes, and wizards are commonly known. Visual Basic, Microsoft Visual Basic for Applications, and even C and Visual C++ are also well known.
Open systems demanded
Users are becoming more demanding—wanting the ability to choose the best product for the current application. If another product is a better fit on the next application, then users want to be able to switch without the penalty of extensive retraining. Also desired is the ability of programming software to work on more than one hardware platform. Open systems allow users to make these decisions rather than default to one supplier. (For example, see related articles in Control Engineering September 1998, pp. 156-163, and October 1998, pp. 92-100.)
One way to make open strategies work is to have product standards—such as data types and structures, interfaces, platforms, etc. An example of such a standard is IEC 61131. This international standard consists of five parts, the third of which covers programming languages. (IEC added the “6” to the nomenclature this year; vendors still commonly use “1131-3.”) While not a standard, the Windows interface with DLLs, APIs, and common dialog boxes is widely used and known to most controls engineers worldwide.
The programming language standard—IEC 61131-3—includes two parts: common elements and programming languages. Common elements include data typing, variables, configuration, resources, tasks, program organization units, and sequential function charts. Although user-defined types are allowed, defining common elements provides for common organization of programs reducing the chance of errors. A sequential function chart is often thought of as one of the five standard “languages” but in reality is a method of logically organizing a program. It is organized in actions and transitions with an action processed until the transition becomes true, at which time that action is turned off and the next is activated.
The other four languages of the standard are defined under the programming languages section. Two of the languages are text-based, and two are graphical. The text languages are instruction list , which is similar to assembler, and structured text , which is similar to Pascal. The graphical languages are ladder diagram , certainly the most widely used in the United States, and function block diagram . The standard allows for user-defined function blocks which can contain custom routines written in C, ladder diagrams, structured text, or instruction list. These blocks can be saved and reused in other programs, obviously a very powerful tool.
There is a “sixth” language which is not part of the standard—flowchart. Several companies are promoting this language as an addition to IEC 61131-3. Since there are different varieties of flowcharting in the market, the benefits of standardization would also apply to this language.
More information regarding the standard and its benefits may be obtained by contacting PLCopen (Bloomingdale, Ill., USA; Zaltbommel, The Netherlands; Tokyo, Japan), an organization promoting the standard internationally.
Programming distributed systems
A problem with the IEC 61131-3 standard according to James Christensen, Rockwell Automation senior principal engineer, IEC 61131 editor, and project leader of IEC 61499, is that it only addresses what happens within one PLC or PC. Control systems even in discrete manufacturing are leaning toward distributed control models. IEC 61499 is a group working with the ISA fieldbus model on distributed control, a concept necessary for today’s agile manufacturing. The definition of a function block is different than in 61131 although both groups are part of the same technical committee. Work is now progressing toward broader definitions to provide improved methods for programmers. The standards are still evolving.
Adoption of standardized programming tools is further along in Europe. Klopper & Wiege Software GmbH (Lemgo, Germany) provides all five languages in a Windows environment. According to Bernd Pelzer, “Today, the IEC-61131 standard is internationally accepted as the programming interface for soft logic PLC systems. It eases the software task and reduces development cycles. Such 32-bit environments include productive features like wizards for very fast application development or automatically updated cross references during editing and online debug. Current 32-bit technologies like DCOM and ActiveX give both openness and integration.”
Manfred Werner of 3S (Kempten, Germany) thinks work should focus on standards for I/O drivers, data exchange, and common databases. He adds, “I see two main benefits to the standard. There is now a software market for programming tools. Tools are made by professional software companies. Training people is simpler. Once IEC programming is understood, a person can easily switch tools.”
Achim Liebl, R&D manager of Softing GmbH (Munich, Germany) points out several new software technologies useful in programming packages: dynamic “tool tips” activated with the cursor provide helpful hints, standard OPC (OLE for Process Control) drivers provide interface to HMI and I/O systems, function blocks that load HMI information are Web browser enabled, and Softing’s software accepts Java code as well as other standard languages.
The ability to implement diagnostics is an important attribute in programming tools according to Mark Knebusch, Interbus group director at Phoenix Contact (Harrisburg, Pa.). Phoenix Contact’s programming software takes advantage of the diagnostic ability of Interbus networks to pinpoint fault location saving maintenance time.
“Hardware-independent programming is one of the biggest benefits of standard tools,” says Robert Lyons, executive vice president and managing director of TranSys (Gilbert, Ariz.), a sister company of CJ International (Seyssins, France). “A change in the program is not required when changing hardware platforms. Only the I/O configuration must be modified.” Flowchart has been added as a sixth language to the IsaGraf package showing the increasing popularity of that tool, especially in the United States.
Lucian Fogoros, applications engineer at ASAP (Chagrin Falls, O.) notes that the C/C++ function block editor adds programming flexibility. “Communication to the I/O modules of at least 20 manufacturers from one programming environment plus the ability to talk directly to HMI further increases flexibility.”
Portability and scalability
Bruce Buscher, business development manager for Intellution (Norwood, Mass.), notes, “The number of companies that have joined PLCopen both in the U.S. and Europe testify to the growing strength of IEC 61131-3. Another factor is the number of software companies and PLC manufacturers supporting this standard today.” Adds Bill Medved, Intellution softlogic & embedded controls director, “The scalability of our 61131-3 product is an important benefit of standards. The software can run on Windows NT with real-time kernel; Windows NT; and Windows CE running on Intel, Hitachi SH3, and MIPS chips. The C language is also a good tool for portability and scalability of platforms.”
Schneider Automation (North Andover, Mass.) also supports IEC 61131-3 languages. Programmers can build a library of user-defined function blocks for reuse in other programs. Unlocated variables allocate memory like the RAM in a commercial PC, eliminating the requirement for a browser to know register numbers to find data.
To Scott Kiser, Wonderware (Irvine, Calif.) product marketing manager, the key is flexibility. ActiveX components, which can be incorporated into Wonderware’s IEC-compliant programming languages, open the world with software objects. Customers have written ActiveX controls for such things as sortation, PID, and interface with vision, drives, and I/O devices. C, Visual Basic, or Java can be used to program objects giving needed flexibility to the programmer. It is even possible to download ActiveX components from the Web.”
Siemens Energy & Automation (Alpharetta, Ga.) also supports some of the IEC languages with configuration software to make I/O point assignments easier than current ladder diagrams.
A colorblind engineer pointed out the need for conventions beyond just color differentiation in programming tools. VMIC (Huntsville, Ala.) designed in a way for colorblind engineers to work through the logic. A useful tool emphasized by sales & marketing assistant vice president Wayne McGee is the ease of use for setting breakpoints and stepping through the program during debug. OPC and DDE are standard communication tools used.
Rockwell Software (Mayfield Heights, O.) supports three of the five IEC languages: ladder diagram, structured text, and sequential function chart in its programming tools. Rockwell has an installed base of PLCs with non-IEC software, but the new Logix strategy (see this month’s Technology Update) includes the adoption of standards into programming software.
Jeff Wilson, Manager, GE Fanuc Automation (Charlottesville, Va.) points out other benefits from combining standard IEC-compliant languages. “Ladder diagram, structured text, and sequential function chart editors exploit Windows technology for easy program creation and maintenance. The integration of structured text into sequential function chart provides a useful way to combine sequential control with continuous control. Multiple SFC programs within one application provides program flow and execution flexibility.”
Mitsubishi Electric Automation (Vernon Hills, Ill.) offers three choices of control programming. Monty Fox, senior product marketing engineer, says that most current customers still like the traditional ladder diagrams with the Mitsubishi instruction set. OEMs shipping to Europe prefer the IEC-compliant version. “The flowchart program,” he adds, “makes it easier to troubleshoot when time has elapsed after installation since each element in the program is labelled. It is easier to trace logic enabling operators to do basic troubleshooting. Applications are divided into individual processes instead of one big piece of code. This modular approach allows for machine expansion over time.”
Flowcharts offer advantages
As Tim Wallaert, vice president product management of Nematron (Ann Arbor, Mich.), observes, “Almost every electrical engineer or programmer graduating from college these days has learned how to do a flowchart.” Flowcharts are almost self documenting and easy to follow when troubleshooting. Mr. Wallaert adds, “Each block is a subprogram. In a complex project with programmers geographically dispersed it is easy to assign tasks among the programmers with greater assurance that the program will work when assembled.” Nematron’s package uses IEC-compliant data types and variables.
Jeffrey Fisher, director of product marketing at Steeplechase Software (Ann Arbor, Mich.), notes, “Flowcharts consist of squares (action elements) that do things and diamonds (decision elements) that check if things are done or moved. Adding a few basic tools reduces debugging. Flowcharting has two major advantages. First is diagnostics—every decision becomes a possible placeholder for automatic diagnostics. The other major benefit is modular, reusable, generic subroutines developed as libraries and samples.”
Cutler-Hammer Automation (Westerville, O.) adds a Windows Explorer-like interface to its flowchart programming package for easier navigation and troubleshooting. A library of configurations make it easy to program many routines.
“Flowcharts are extensible,” says Gary Marchuk, sales and marketing manager for Think & Do Software (Ann Arbor, Mich.). “Flowcharts allow for ‘action’ blocks within the program. Using extensibility adds functions such as PID loop control, serial communications, motion control, and string handling. A programmer can interact with control devices within a common programming environment with a common database.”
Opto 22’s (Temecula, Calif.) flowchart tools include real-time multitasking where each chart is a task and up to 31 charts can run at one time. Bob Sheffres, vice president of sales, adds, “Logic can flow any way the user requires without strict adherence to a numbering structure. Flowcharts can execute on a PC or in a variety of hardened controllers. There is direct connectivity to Microsoft SQL Server and Access from the control database for information handling. Support for intelligent I/O devices allows programming for actions executed at the I/O level, including PID, high-speed counting, event reactions, etc.”
Pick a tool, any tool
Evolution of Microsoft Windows as a widely used industrial platform has spawned a number of independent software developers who are finding ways to enhance the power of programming software. This competition has spurred others to innovate. The result is software that is more powerful and easier to use than ever before.
IEC 61131-3 Definitions
The third section of the IEC 61131 standard defines five standard programming languages.
Sequential function charts —actually more than a language, it is also a graphical method of organizing control programs.
Instruction list —a text-based language similar to assembler.
Structured text —a text-based language similar to Pascal.
Ladder diagram —most used in North America, it graphically represents rungs of contacts, coils, and special instruction blocks.
Function block diagram —a graphical language corresponding to a circuit diagram.
GM Power Train reveals software vision
General Motors Power Train (GMPT) has tasked expert teams to define a future vision, requirements, and migration plan for engineering, design, documentation, and programming of manufacturing automation controls.Competitive pressures to introduce better-quality new products to global markets faster, at lower cost are driving the need for GM to improve the controls engineering processes, standards, and tools in a globally common manner. Subgoals affecting operation include reduction of downtime and quality-loss. Subgoals affecting engineering costs include reuse of assets such as software components.
GM faces many challenges. Lead-time reduction forces overlap in product engineering, manufacturing process engineering, and controls engineering, requiring running changes to machine/process control programs. Additional differences in the controls in production stem from differences in plant-replication timings around the globe, application characteristics, regional regulations, conventions, standards and skill-base constraints. Rapid technological obsolescence forces upgrades to platform components and tools before a product-program is completely implemented. Due to their short lifecycle relative to manufacturing equipment, computer technologies have to be upgraded many times over the life of the equipment. As a result, many versions of platform components and tools are in use in production, increasing maintenance difficulty and refresher training costs.
To meet these challenges, the GMPT commonization effort will assemble best practices and lessons learned from around the world into a common global specification. Key technical concepts include: (1) use of mainstream technologies, (2) a modular component-based architecture that maximizes software reuse and minimizes cost of changes in requirements, technology, execution platforms and presentation forms, (3) unified engineering and programming tools and environment, and (4) harmonization of international standards.
Use of mainstream technologies
As far as possible, the solutions should leverage computing and communication/networking hardware, platform software, tools, and software components used in mainstream high volume applications. It is uneconomical to create and maintain equivalent functionality in a manner specific to the manufacturing automation industry. Interfaces should be common to the mainstream of computing and networking, e.g., web tools, communication services, and operating system services, when such mainstream services meet the requirements of the application in a reliable, maintainable manner.
Modular component-based architecture
Control logic software should be modular, portable, and composed of reusable library components and language elements having public, supplier-neutral interfaces, standardized across respective application domains and users. The user organization, in its manufacturing operations, should be able to reuse these libraries and administer version and configuration control, distribution, and maintenance, to assure consistency across the whole program.
Application class library components may be sourced from suppliers of the controller, the programming tools, the machine tool, the hardware component supplier, the control integrator, or a third-party software component supplier. A control logic sequence, modeled as a state transition network, is composed from functions of instances of these classes. Repetitive patterns of control cycles in a particular application domain are reusable as library classes. The overall machine control logic program is composed of reusable library components described above, specialized or instantiated as required. In this manner, machine-specific programming is minimized. Reuse of class libraries also helps preserve a consistent structure and reduces follow on training time.
All library components and their assemblies into state-transition networks (including the whole program) should be available and accessible in a view-independent database through a set of defined software interfaces. This struc-
ture allows the flexibility to integrate pre-existing library components implemented in a computer programming language such as C/C++, an IEC 61131 presentation language, or through flowcharting.
Programming tools and environment
Unnecessary variety of engineering tools and programming languages should be eliminated. For example, a unified programming environment is needed for all functionality to be programmed in a given work cell. Context-sensitive help and documentation should be available as further assistance. Troubleshooting should not require study of the original control logic program.
Where a typical high-productivity manufacturing workstation integrates a variety of processing and supporting functions, the user organization faces the burden of acquiring, maintaining, and integrating multiple programming environments, languages, and skills. It should be possible to specify a variety of interacting, intermingled processes in the same programming environment.
Harmonization of standards needed
Unfortunately, there are separate standards for programming languages for “different” types of manufacturing automation, e.g., ISO 6983 or EIA RS 274 for numerical control, DMIS for dimensional measurement and inspection, IEC 61131 for discrete logic control, ISO 9506 for communication. These differences have become institutionalized in standardization committee structures, e.g., ISO TC 184 (technical committee for manufacturing automation). The vocabulary of each language is limited in its expressivity to its traditional narrow focus. There is significant nonvalue adding overlap in their functionality. They have unnecessarily confusing differences in semantics for the same concept.
Harmonization of these standards is needed to facilitate the needed efficiency improvement and integration. However, ongoing standards efforts continue to be uncoordinated.
To control software life-cycle cost of application programs and tools, we need very efficient transformation of a higher level process plan into a finer granularity process plan up to the final transformation into a program that controls a manufacturing machine tool or cell. The simpler and more direct the transformation (mapping) the better it would be. Therefore, the equivalent of the process plan or sequence of operations should be decomposable and mappable into the controller APIs as directly as possible. However, there is no concerted effort to coordinate development of specifications for language architecture and controller architecture. As an initial integration step, standardization efforts should seek semantic equivalence of different forms of expression.
Current standards do not assure portability of application software, nor interchangeability and interoperability of multisourced components. Much additional effort is needed in developing the necessary standards, conformance tests, and competent certification facilities.
Work together
Improvement opportunities exist in manufacturing operations through automated control, monitoring, and diagnostics. As a first step to tackle the problem, we urge major users to work together towards a common set of requirements for the future, following the success model used in electronic hardware design.
