Power Up Programming with Graphical Modeling

First there was text-based programming with tools such as general editors/compilers like Basic or C, or Structured Text or Instruction List. Then graphic programming for control was adapted from Relay Ladder Diagrams, first on special programming terminals, and later on personal computers. Function block diagrams added another dimension to graphic representations of process control.

By Gary A. Mintchel, Control Engineering December 1, 2000


Machine control

PC-based control


Software and information integration

Sidebars: Programming standards for agile manufacturing Challenges and opportunities in logic control for manufacturing systems Online

First there was text-based programming with tools such as general editors/compilers like Basic or C, or Structured Text or Instruction List. Then graphic programming for control was adapted from Relay Ladder Diagrams, first on special programming terminals, and later on personal computers. Function block diagrams added another dimension to graphic representations of process control. Flowchart advocates have adapted this popular analysis tool to logic control development.

Microsoft Windows enabled programmers to take advantage of editing tools like drag-and-drop and cut-copy-paste. It also enabled movement toward common databases for logic and HMI (human-machine interface) ,as well as program libraries that could be saved and pasted into numerous programs saving much time.

The end of the millennium (or beginning of the next, depending on how one counts) brings with it advances in programming that will propel control engineering into a leading role in future manufacturing advances. Work on IEC 61499 distributed function block standards is designed to enable agile manufacturing. E-manufacturing will certainly drive manufacturers to develop ever more agile processes to stay atop the competitive mountain. Tools are on the way to assure control engineers can adapt.

This diagram shows The MathWorks model-based software design for embedded control.

From drawing to code

Schneider Electric (Raleigh, N.C.) and Intellution (Foxborough, Mass.) have built a modeling tool based on IEC S88 that compiles the model into logic for Schneider’s Concept PLC programming application. A Microsoft Access database contains the central repository for all I/O assignment information. It also works with Intellution’s iFix HMI/SCADA product, allowing easy communication of all points.

Microsoft’s Visio unit (Redmond, Wash.) integrated Windows-based tools like support for Visual Basic to allow integration of its business process diagramming and drawing tool to control and HMI software ( Control Engineering , Oct.’00, p. 12 ).

The MathWorks (Natick, Mass.) has extended its suite of mathematical modeling and simulation tools into a powerful design, modeling, simulation, and code-generating application. I-Logix developed a Unified Modeling Language (UML) package into a graphical tool that models and then generates control code for embedded control. Finished that PLC program? VIA Development (Marion, Ind.) has extended CAD into a relay ladder diagram tool for documenting programs of various PLCs.

What programming languages are popular for industrial applications? Venture Development Corp.’s (Natick, Mass.) recent study found that users select software that’s easy to learn and use, has a large installed base, demonstrates portability, and is structured. The most widely used languages were C++ for software development and Visual Basic for operator interface, although the large installed base of PLC systems was reflected by large use of relay ladder diagram programming. The study’s authors expect flowchart and other soft logic programming to grow along with growth of PC-based control.

Remember the tremendous publicity accompanying release of Java several years ago? The industrial arena seems to have let the hype go by. Almost half the users interviewed in the study either were not considering it or were unaware of it. A few programmers were considering Java for web-based applications.

Reasoning Inc. uses this ASP model for source code analyzing andevaluating to assure its customers of reliable software.

Generate code automatically

One Step Generator (OSG) from Schneider Electric with input from Intellution is a design tool for process control systems and automation tasks involving networked PLCs and supervisory workstations. It uses the S88 physical model to design system architecture, then it generates code as Function Block Diagram and the supervisory system within Intellution’s iFix. It even works with existing Modicon Quantum/Concept and Intellution iFix products.

OSG automatically generates code for the HMI and PLC. Predefined libraries of standard process objects, or Smart Control Devices, enable productivity and code standardization. The product is targeted at process industries. Designers work with OSG representations of process objects, not differentiating whether the source code generated will run on HMI or PLC. Logic concerned with process automation will run in the PLC, while HMI will serve as a window into the process and provide operators with functions required to manage the process.

Control design begins with a top-down analysis of the system. A complete description comprises the PLC equipment, supervisory (HMI) stations, and electrical and mechanical layouts. In OSG, the process is described functionally in a language all people involved can understand. OSG provides:

a method to improve quality and assist process validation;

a language describing the process for system design;

a specification for implementation and commissioning phases;

documentation for operation and maintenance; and

a procedure, which warns the user when changes have been made to the control system.

Think & Do Software’s (Ann Arbor, Mich.) approach to developing software solutions has been to leverage commercial products. It recently found a commercial platform for visual program development for control, visualization, and data management-Microsoft’s Visio. Says Think & Do’s marketing director, Andy McMillan, ‘Visio was a product we looked at right from the start. At the time, however, it wasn’t the full-featured development platform it is today.’

GE Fanuc DataViews (Northampton, Mass.) also works with Visio. Its product, DataViews HMI-GO, allows users to add data-driven dynamics to Visio drawings to bring them to life with real-time information.

Explains Kevin Lisota, Microsoft Visio product manager, ‘The core design idea is more than a collection of clip-art shapes. People had always thought Visio was a drawing tool, but from the beginning the idea was to provide custom properties for shape and describe how they behave with Visual Basic for Applications (VBA). This made it easy for outside vendors to create custom applications. The core design idea, then, is the Shape Sheet. The user highlights a shape and chooses it. An Excel-type spreadsheet pops up. The user then fills in the properties, such as specific values, formulas, links to other cells, etc. The shape sheets and each of the properties are accessible programmatically through VBA.’

Adds fellow product manager, Curtis Lee, ‘Visio is a modeling tool. It has been mostly used for business process design and flowcharting. But UML and database modeling are inherent within it. The user can create, visualize, and manipulate a database through Visio and VBA programs accessing it.’

‘The MathWorks offers an integrated toolset for model-based design and programming,’ states Richard Dinkins, director of marketing. ‘The latest releases of MATLAB, Simulink, Stateflow, and Real-Time Workshop include several components for building and testing control systems in a simulated environment, using models to validate and optimize designs before committing to writing code or building prototypes.

‘When a system model has been simulated, optimized, and validated, it can serve as the basis for documentation, code generation, and test generation, all from a single, tested model. Engineers can generate code for rapid prototyping and hardware-in-the-loop simulation of models, then generate code as optimized, embeddable ANSI C for use on multiple target operating systems and hardware platforms.

‘The code generated by model-based design tools has continued to improve in quality in terms of RAM size, ROM size, and execution speed over the last several years. Recently, improvements in code efficiency have been made. Many customers now will consider the code ready for use in pilot projects and will insert it into their code validation processes.’

Unified Modeling Language

I-Logix’ Rhapsody enables software engineers to graphically design and develop real-time embedded software using object-oriented techniques. Rhapsody is the first such tool to comply with the Unified Modeling Language (UML). Combining an iterative design methodology, which validates behavior in iterative steps, with associativity between the graphical model and the code, Rhapsody ensures that the design document and the implementation are always in sync. At any time during the process, Rhapsody can generate production-quality code in C, C++, and Java.

Developers use UML diagrams for describing the software architecture, behavior and collaboration. At any point in the development process, the developer can automatically generate a code for the host development platform or the embedded target and debug that code at the design-level in the UML diagrams and at the source code view.

In addition, with Rhapsody’s unique model/code associativity, developers are free to work at either the graphical design level or within the implementation language. Changes made in either view are automatically reflected in the other.

Many automation projects involve numerous controllers and hundreds, even thousands, of I/O points. MNovation (Minneapolis, Minn.) has developed OverView for handling project management and verification within National Instruments (Austin, Tex.) LabView programming environment.

This application provides project documentation and a comprehensive status report for each member of the project team, analyzes code complexities with a Kiviat diagram for rapid analysis of selected categories against user-defined limits, regression analysis, and project testing and simulation.

Another part of automation projects involves finishing control drawings after programming is complete. VIA Development’s ECDS is a controls design package that runs in AutoCAD environment. By using the same configuration and parts database, engineers can standardize controls drawings. This makes it easier for an electrician to use the prints. ECDS has I/O module libraries for many PLCs, including Allen-Bradley, General Electric, Mitsubishi, Modicon, Omron, and Siemens, to name a few.

Application Service Provider (ASP) is an up-and-coming method of distributing products and services over the Internet. In this model, the user ‘borrows or rents’ the application software which resides on the provider’s server. Reasoning (Mountain View, Calif.) uses the ASP model to provide software quality and reliability services. The company receives software from client companies and performs an automated analysis. Capable of analyzing C, C++, and COBOL code, the software tests and analyzes 100% of the code, then provides a report of real and potential problems. Java support is coming soon.

Tools are rapidly appearing to help programmers write better control code more quickly. In these days of fewer control engineers doing more work, this is certainly good news.

Programming standards for agile manufacturing

IEC 61499 committee is developing a function block standard designed toenable agile manufacturing combining DCS and PLC functionality.

The International Electrotechnical Commission (IEC) is a driving force for standards striving for interoperable tools. IEC 61131 defines standards for programming and communication for programmable controllers (Control Engineering, Dec.’98, p. 42). Section 3 defines four standard ‘programming languages’ (relay ladder diagram, function block, instruction list, and structured text) and an organizing method (sequential function chart).

IEC 61158 defines ‘fieldbuses.’ Rather than adopt a single international fieldbus, the committee decided to accept several standards. IEC 61804 defines distributed control. All standards define software modules called function blocks.

In early 1990, IEC Technical Committee 65 received a New Work Proposal to standardize function blocks for distributed measurement and control and assigned project 61499 to a working group.

The major challenges in evolving the application of function blocks from classical PLCs to distributed measurement and control is that function blocks are considered to be elements of programs in a centralized controller and elements of distributed applications in a decentralized control system.

In an IEC 61131-3 configuration the execution of a program is triggered by a periodic or non-periodic task. Upon triggering, the function block instances in the program are executed in a predetermined order. Similarly, execution of function block instances in a distributed system may be performed according to a predetermined cyclic schedule. However, IEC 61499 must support a more general model in which a centralized mechanism for enforcing execution schedules may or may not exist.

In the IEC 61131-3 model communication and I/O functions are only loosely coupled to variables used in programs through the ‘access path’ and ‘global and directly represented variable’ mechanisms. Also, within programs a fixed order of function block execution can be determined such that new values of variables are available before beginning the execution of a function block that uses them.

In all control systems, control cannot be maintained unless constraints are satisfied through changes in input variables, corrective actions, and resulting output variables. In a centralized control system as in the 61131-3 model, these constraints are usually met by assuring that input and output sampling and program execution are always faster than necessary; or by careful fine-grained partitioning and scheduling of I/O sampling and program execution. In a distributed system, similar criteria must be met without necessarily having the luxury of a centralized scheduling mechanism. In addition, the IEC 61499 model must accommodate enhanced performance from priority-based communications, as in CAN networks, or by using unscheduled high-speed links such as Ethernet.

A generic function block model should accommodate the existence of multiple alternative algorithms within a single function block body, selectable depending on some external event or condition, such as, initialization algorithms, normal operation algorithms or fault processing/recovery algorithms.

High-speed, event-driven state machine control is essential to many modern machine control applications, in contrast with slower execution time requirements typical of many process control applications. A general function block model for distributed industrial process measurement and control systems (IPMCSs) must accommodate both sets of requirements.

Encapsulation and reuse of control algorithms by end-users, equipment suppliers, and system integrators is much more widespread in manufacturing operations typically addressed by IEC 61131-3 programming languages than in process control operations.

Future industrial processes will exhibit much higher degrees of physical reconfigurability to accommodate frequent changes in product mix and volume, as well as frequent introduction of new product types and manufacturing technologies. In addition, rapid reconfiguration of the industrial process will be used much more frequently to recover from machine and process faults with minimal loss of production. In all these cases, the control system must be reconfigured quickly and, for the most part, automatically to not limit agility. In fact, in the not-too-distant future, control systems for autonomous, intelligent manufacturing units (‘holons’) will be required to be intelligently self-reconfiguring to accomplish task assignments negotiated with other holons. This will further increase requirements for software encapsulation and reuse.

Drafts of IEC 61499 are out for National Committee comments. These drafts will most likely provide a trial implementation period for pending standards.

For more information, see

Challenges and opportunities in logic control for manufacturing systems

Discrete part manufacturing systems typically consist of numerous machines working together in a coordinated and sequential fashion. Systems with hundreds or thousands of inputs and outputs, many of them simple on/off switches, are not uncommon. The logic controller, implemented on a PLC, must handle not only the normal operation sequence and synchronization of the machines, but also the operator interface and error handling and recovery routines.

In current industrial practice, PLCs are programmed using a low-level language, such as ladder logic, resulting in large and unwieldy programs. The overall design is experience-based, and verification is typically done only through experimentation or simulation. Theoretical foundations (such as Petri nets and finite-state machines) have been developed to model and control such discrete-event systems. However, despite significant research advances in recent years, these formal techniques have not been widely employed in industry.

To create an understanding of the gaps that exist between the theory of discrete-event systems and its implementation in industrial manufacturing systems, 50 participants were brought together for a workshop at the University of Michigan in June 2000.

Expressed industry needs included more effective fault detection and diagnostics, clear and precise specifications, open architecture controllers, better standards, and more user-friendly software tools. Workshop participants also cited a need for better education in logic control. One of the most significant barriers to implementing research results in practice is the development of commercial products. Most logic control programmers learn about new technologies from their vendors, not from reading technical journals. In addition, much of the academic work on logic control has only considered the automatic or normal operation cycle of a manufacturing system, whereas up to 90% of the control code may deal with alternate control modes and fault handling/diagnostics. Also, many manufacturing companies focus their limited research resources on product development, rather than on manufacturing processes.

Future research topics identified at the workshop include improving logic control software design and implementation through integrated diagnostics, better human-machine interfaces, validation, and automatic code generation. As distributed control becomes more popular in implementations, effective compositional methods for distributed control systems will be needed. Modular control design is also increasingly important–the key research issues are at the interfaces or interlocks between different control modules.

For further information, visit


Please see this article online at