Development of an Extensible Engineering Support Tool for IEC 61499 Considering WYSIWYG GUI Building as Example

Oliver Hummer, Ivanka Krezic, Alois Zoitl Automation and Control Institute Vienna University of Technology

Gußhausstr. 27-29 / 376 1040 Wien, Austria

{hummer,krezic,zoitl}@acin.tuwien.ac.at

Thomas Strasser PROFACTOR Research

Im Stadtgut A2 4407 Steyr-Gleink, Austria

thomas.strasser@profactor.at

Abstract

In today’s production and assembly processes, con-ventional PLC-based architectures are State-of-the-Art for control engineering and application design. These kinds of architectures cause high costs for engineering and maintenance, especially adaptation of applications and hardware modifications create intolerable over-head. Distributed automation systems built of mecha-tronic components help coping with the demands of modern markets. The paper presents a new architec-ture for integrated modeling of such systems, introduc-ing different views for domain experts. A modular en-gineering support tool based on an open tool integra-tion platform is developed, using IEC 61499 as com-mon data model.

1. Introduction

Today’s production and assembly processes are en-gineered and controlled using conventional program-mable logical controller (PLC) based architectures that are State-of-the-Art. They represent proven technology and allow controlling even large systems when com-bined with suitable communication media, such as field busses.

Roughly PLCs have carried industrial automation since the 1970s, but requirements in the production and manufacturing domain are now changing rapidly due to different market conditions. The trend from mass pro-duction to mass customization provides serious chal-lenges to modern automation systems and their engi-neers. For two reasons the existing technology reaches its limitations:

First of all, centralized architectures are very static and therefore inappropriate to coping with the new market demands like

• shortened model life cycles and • increasing product variety whilst • batch / lot sizes are shrinking.

Apparently PLC based architectures show a severe lack of flexibility: Adapting centralized automation

systems to changed hardware usually implicates enor-mous costs due to reengineering of the complete cen-tralized control application. Distributed automation systems, that offer better support for reconfiguration, are discussed in chapter 2.

Secondly, development of applications for PLC con-trolled automation systems is also restricted by certain shortcomings, which finally leads to suboptimal im-plementations. In modern industrial control three dif-ferent types of applications are common:

• the control application itself, • human-machine-interaction applications and • applications for diagnostic purposes.

Separate design of these applications naturally in-creases complexity of the interfaces between them. That is why many control hardware suppliers offer specialized software tools for each application type as support to control system engineers. Nevertheless dif-ferent tools for different tasks force a design methodol-ogy that is rather sequential. In addition most of these specialized tools are proprietary solutions and therefore bound to the hardware of a specific supplier.

On the contrary for the design of standard software so-called Integrated Development Environments (IDEs) have been applied successfully. The key fea-tures of these platforms are: means of fully abstract and structured modeling (e.g. based on the unified model-ing language UML). Thereby object-oriented source code (Java, C++ …) is generated automatically accord-ing to the model. The support for libraries containing prefabricated software modules reduces development effort and increases stability of implementations via re-use of such proven software fragments. Finally drag-and-drop design of graphical user interfaces (GUIs) is enabled by special GUI component libraries together with a GUI plug-in for the IDE.

Adapting these concepts for automation systems could noticeable improve engineering of industrial con-trol system applications. Such a prototype engineering support system (ESS) is the CORFU ESS [1], devel-oped at the university of Patras, Greece. CORFU stands for Common Object-oriented Real-time Frame-work for the Unified development of industrial process

0-7803-9402-X/05/$20.00 © 2005 IEEE

measurement and control systems (IPMCS) applica-tions. It uses a general-purpose Computer Aided Soft-ware Engineering (CASE) tool for modeling a system’s use cases in UML diagrams, which then are trans-formed into IEC 61499 [4] function block diagrams by the Transformation Facility Manager (TFM). So the main focus of the CORFU ESS is to support the engi-neering phase of IPMCS.

But UML diagrams are just one view of a system among many others. This paper envisions an engineer-ing support tool (EST) that lets the engineer switch between different views of a system, subject to which view is best suited to model a certain aspect. Therefore chapter 2 discusses integrated modeling of modern distributed IPMCS and gives a basic architecture for the EST. Chapter 3 summarizes the benefits of inte-grating the EST into an open tool integration platform. Finally chapter 4 provides a test implementation in form of a WYSIWIG GUI builder.

2. Modeling distributed IPMCS

In modern industrial automation there is a clear trend to mechatronic components combining sensors, actuators, control software and communication inter-faces into one device. This increases the flexibility of production equipment whilst engineering costs are re-duced. Thus intelligence becomes distributed, which leads to distributed automation systems requiring new system design methodologies. Since system modeling is done in software, a suitable software representation of these components is needed at first. In the ideal case this representation encapsulates all relevant informa-tion about the component and is delivered with it.

2.1. Virtual mechatronic components According to [2], the abstraction and encapsulation

of mechatronic components into software modules is denoted as Virtual Mechatronic Component (VMC). Each VMC not only contains information about the usage of the corresponding hardware component but also represents different views for

• mechanical properties, • electrical properties, • component control, • documentation, • simulation and • interaction semantic.

VMCs therefore are a compound of the different en-gineering views of the associated mechatronic compo-nents. The information of all different views is encap-sulated within the VMC, for interaction with other VMCs only the necessary interfaces are provided. Such components, when containing embedded control de-vices and software, are further referred to as Automa-tion Objects [3] (see figure 1). [2] further envisions that in the future many different vendors will provide and

maintain their VMCs at virtual market places using a common technology. Hence VMCs represent the basic element for the engineering of Reconfigurable Manu-facturing Systems (RMS).

Figure 1: An automation object

In order to benefit from the VMC concept a design methodology is needed that supports usage of all dif-ferent views mentioned above. To allow easy handling of the variety of views support through a sophisticated engineering support tool, similar to the IDEs men-tioned above, will be crucial.

2.2. Integrated modeling Within the scope of this paper a modeling technique

that allows design in different views of the model, each of them reflecting the current state of the model, will be called integrated modeling.

As starting point a distributed IPMCS is considered. Typically such a system consists of a set of automation objects connected by some sort of communication net-work. Each single object itself provides different views to distinct domain experts, subject to its properties (e.g. there is no point in providing a mechanical view for pure electric components).

When modeling a whole system it can be useful to apply a certain view not only on a special component, but on the whole system. It is an important fact that all different views help modeling different aspects of dis-tributed IPMCS, but nevertheless they are just different representations of the same system.

It is therefore feasible to store the configuration of the given system and all related information within a common data model, instead of creating a separate model for each view. Doing so enables applying the integrated modeling approach on whole systems.

Requirements for the data model. Specification of the data model is a very sensitive step, because it de-termines the abilities of the aspired engineering method lastingly:

Distribution: A clearly structured description of distributed IPMCS is the primary claim on the common data model.

Openness: Data should be stored in a standardized format in order to ease application of available engi-neering tools on them.

Interfaces: Since the data model contains all infor-mation about the system it must provide suitable inter-faces to exchange data with the different views.

Solution. To reduce complexity for the first approach the focus is set to the views which are of interest for control system designers: control and HMI. Additional views (e.g. mechanical or hydraulic, rather suited for device manufacturers) may follow later.

A suitable data model for these issues of distributed IPMCS is already available*: In January 2005 the In-ternational Electrotechnical Commission (IEC) has finally adopted the standard IEC 61499 [4] as reference model for designing distributed IPMCS. It can be con-sidered as an extension of the well accepted PLC pro-gramming language standard IEC 61131-3 [5] to dis-tributed automation systems. In IEC 61499 software modules are represented by function blocks, similar to those known from IEC 61131-3. The innovation is that the execution of IEC 61499 function blocks is com-pletely event-driven, thus each function block has two types of I/O connectors: event connectors and data connectors. IEC 61499 applications are specified as function block networks (that is the interconnection of various function blocks, similar to electronic circuits). IEC 61499 further uses the eXtensible Markup Lan-guage (XML) as standardized format for storing and exchanging information. As design methodology Ap-plication Centered Engineering (ACE) is pushed, which means that whole applications are designed ab-stractly before considering distribution of the underly-ing hardware. Thus, and due to its modular, open and generic approach, IEC 61499 is well suited as common data model for engineering tools aiming at distributed IPMCS. Integration. Out of these considerations a possible and simple architecture for the engineering tool can be de-rived: it will proof advantageous to select a modular approach, where specialized tools for the different views are organized around the common IEC 61499 data model.

The achievement of this new attempt is that finally the resulting structure will be encapsulated in a com-mon engineering tool as shown in figure 2, so that

• any view allows changing its associated ele-ments of the data model whilst

*Chapter 4 describes modelling HMIs by means of IEC 61499.

• all other views, if affected by the modifica-tions, incur all changes via the shared data model and update themselves.

The engineering tool can further be improved by adopting features known from IDEs for development of object-oriented software, like

• automatic code generation, • automatic code completion, • automatic syntax check, • libraries for modules / components and • support for plug-ins to keep the architecture

flexible and extendable.

3. Development of the engineering support tool

Development of a whole engineering tool starting from scratch is considered a waste of time [6]: Such tools have to provide lots of basic functions like a graphical user interface, editors for various file types, mecha-nisms for import and export of data and so on. Despite different implementations these tools hence share a considerable amount of common functionality.

3.1. Open tool integration platforms For the easy and flexible development of engineer-

ing tools so-called Open Tool Integration Platforms (OTIPs) have emerged. At the moment there are com-mercial solutions present (e.g. Niagara Framework from Tridium [7]), as well as open-source projects (the most popular members are NetBeans [8] from Sun Mi-crosystems and Eclipse [9] powered by the Eclipse Foundation).

The core of an OTIP forms the development infra-structure, presentation functions including windowing, file handling and exploration, actions as well as infor-mation processing. A set of open Application Program Interfaces (APIs) allows extending the core by plug-ins providing additional functionality.

So-called Plug-in Development Environments (PDEs) provide a set of tools that assist the developer in developing, testing, debugging, building, and de-ploying plug-ins. Generally an OTIP is the sum of its

Figure 2: General architecture of the engi-neering tool

constituent plug-ins, where each plug-in contributes functionality to the platform and is activated each time the functionality it provides is needed. Cooperation between different plug-ins is specified by the intercon-nection model: a plug-in declares any number of named extension points, and any number of extensions to one or more extension points in other plug-ins. An exten-sion point may have a corresponding API interface. A plug-in’s extension points can be extended by other plug-ins, too. A plug-in may also include a source code library and other resource files it needs, such as icons, properties files, etc. The interconnection model, to-gether with a set of basic properties (indicating which types of features are provided, where these features are implemented, and what special option settings should be used when installing these features into the IDE), is also stored for each plug-in.

3.2. Integration of the engineering support tool Figure 3 sketches how the engineering support tool

can be integrated into an OTIP. Thereby the OTIP’s core offers all basic functionality, whereas specific features of the EST are encapsulated in plug-ins. In order to save license fees open-source platforms are preferred.

Figure 3: Development of the engineer-ing support tool as plug-ins for open-source tool integration platforms

The leftmost plug-in (see figure 3) is responsible for data exchange between the OTIP’s core and the IEC 61499 data model. For this reason it is mandatory, since all other plug-ins are worthless without access to the common data model (cf. figure 2).

Support for the Control Modeling Language (CML) of IEC 61499 (that is function blocks and function block networks respectively) is enabled by another plug-in. Any other possible view of a distributed IPMCS is implemented likewise.

3.3. Support for WYSIWYG design Wherever graphical representations of software

modules are available (e.g. function blocks), design in a graphical What You See Is What You Get (WYSIWYG) manner is usually faster and more intui-tive than other methods.

OTIPs usually contain visual design tools (e.g. NetBeans’ Form Editor), which can be adopted for use with new developed plug-ins.

In IEC 61499 any software module is represented by an associated function block. Building applications by connecting function blocks in a graphical editor can inherently be considered as a kind of WYSIWYG de-sign. On the other hand there are function blocks that produce some output, e.g. graphical components used for Human – Machine – Interfaces (HMIs)*. In this case the function block network does not tell too much about how the actual output on the screen will look like, design basically consists of “trial and error”. It would be much more intuitive and productive to design a HMI in some sort of graphical editor out of prefabri-cated components whilst the associated function block network is generated automatically.

In a typical industrial application different kinds of function blocks will be used in parallel. Some of them may contain graphical HMI content whilst others just provide parts of the control logic. For a WYSIWYG HMI design tool it is therefore necessary to distinct, whether a function block found in an application is of HMI type, or not. HMI function blocks are part of the HMI tool’s view on the common data model, all others shall be ignored completely in order not to affect con-trol logic or diagnostic tasks.

4. Test example: GUI building in IEC 61499

This chapter gives an example how integrated mod-eling can be implemented into an open tool integration platform via plug-ins. As illustrative sample the devel-opment of Graphical User Interfaces (GUIs) is se-lected. Thereby a GUI consists of one or more HMI(s), which use(s) some sort of (touch-)screen for the visu-alization of their connection to an IPMCS.

4.1. GUI Components According to chapter 2, modern distributed IPMCS

are modeled as cooperation of automation objects. These objects represent self contained intelligent de-vices, which are well-defined through their interface and its specification. In IEC 61499 the component’s control interfaces are represented by function blocks, while the inner life of an object usually remains nonde-script. Control applications are defined as function block networks.

To avoid friction losses, the structural design of the GUI building process should be quite equal: Like com-plex systems are split into small modules, complex GUIs can be split into small components, like buttons or drawing primitives (circles, rectangles, lines …). These components are then encapsulated into IEC 61499 function blocks. Now a whole GUI can be designed as function block network, so the structural * But there are also HMIs that are not graphical or even not using a

screen at all, e.g. buttons, key panels or consoles.

design is the same as for the control application, see figure 5. To avoid a “trial and error” design strategy a WYSIWYG GUI building tool is needed, as stated in section 3.3.

4.2. Requirement analysis for a WYSIWYG GUI building tool

As demanded before, the tool shall be implemented as plug-in for an open tool integration platform. Be-sides 6 main functions such a GUI building tool has to offer can be identified:

• A graphical editor, in which the actual design is done. GUI components can be added per drag-and-drop. The common data model is automatically updated upon any modification (the associated function block network can be generated by another plug-in based on the changes in the data model).

• A palette, where prefabricated GUI compo-nents are stored for further use. It certainly makes sense that in the palette the graphical representation of a function block is presented to the user rather than the function block it-self.

• The possibility to develop new GUI compo-nents.

• Import of existing third party GUI-components into the palette.

• A mechanism for composition of full featured GUIs for the use in IEC 61499-compliant GUI devices based on existing GUI-components, like buttons, sliders, and tanks.

• Export of new designed or composite GUI components for further distribution.

4.3. Test implementation for feasibility demonstra-tion

For the feasibility demonstration the NetBeans tool integration platform is selected. Its core provides the following functions:

• User interface management (“Look and Feel”),

• loading and saving of data files, • Mechanisms for application data management, • interaction between modules.

Execution of IEC 61499 applications (given as func-tion block networks) requires an IEC 61499 runtime environment. In this example the Function Block Run-time Environment (FBRT) from Rockwell Automation provided for free by Holobloc Inc. [10] is selected.

For loading and saving IEC 61499 data files an ex-tension module for the XML support of the platform is integrated into NetBeans. The NetBeans Form Editor module functions as graphical editor for GUI building.

By utilizing the JavaBeans technology (Java Beans are self-contained, reusable software components writ-ten in the Java programming language, which can be installed and run independent from the platform) IEC 61499 GUI-components from the FBRT are added to the Form Editor’s palette.

As mentioned in section 3.3, in typical industrial IEC 61499 applications HMI function blocks are used in cooperation with control logic function blocks. In order to provide only the right information for the Form Editor module it is restricted to IEC 61499 GUI components provided as Java Bean. All other compo-nents in an application are ignored, since they are of no interest for the GUI design.

For a full featured GUI-Building Tool the loading of existing IEC 61499 files has to be supported. All IEC 61499 file types (.fb, .res, .dev, .sys) rely on XML. NetBeans has already built-in support for XML-files. Therefore only an extension is necessary that the IEC 61499 XML nodes are recognized by NetBeans. This can be achieved by writing a file loading module that annotates the XML-nodes loaded by NetBeans.

Extending this architecture by an XML editor mod-ule and a tree viewer module leads to the implementa-tion shown in figure 4. Thereby the Model Conversion module is needed for converting the Form file, which is generated in the Form Editor, into an IEC 61499 com-pliant XML file.

Figure 4: Implementation of the GUI de-sign plug-in for feasibility demonstration

The “Look and Feel” of the new developed GUI de-sign plug-in implemented in the NetBeans tool integra-tion platform is shown in figure 6: The Palette window (top right, contains GUI components), the Inspector window (middle right, lists all GUI components already integrated into the GUI) and the Properties window (bottom right, showing the properties of the selected component) are organized besides the Form editor.

5. Conclusion

Today any company must be able to quickly design and create new forms of advanced automated produc-tion in order to keep pace with the demands of ever changing markets. Distributed automation systems built of automation objects provide the required flexi-bility of hardware. The standard IEC 61499 assists modeling such advanced distributed automation sys-tems and their control applications, thus providing the required flexibility of software. Furthermore this ap-proach helps device manufacturers to protect their in-tellectual property, since automation objects (which in IEC 61499 are represented by function blocks) are used via their interface without detailed knowledge of their internals.

As support for the creation of new IEC 61499 appli-cations beneficial tools exist from all over the world. The deployment spreads in many different directions from modeling function blocks to verification and vali-dation, and therewith to diverse tool environments ac-cording to IEC 61499. To enhance reusability and adaptability an extensible engineering platform is a good starting point for future IEC 61499 tool develop-ments. Tool developers should be convinced of coop-eration with all other developers to support an univer-sal, extensible engineering system. The vendors and also the end-users should be able to self-decide which IEC 61499 tools they plug into such a platform.

This is similar to including special features (syntax checking, resource monitoring) into operating systems.

Utilizing open tool integration platforms as base for an extensible IEC 61499 engineering platform saves a lot of time and effort. Besides it is possible for domain experts to add new plug-ins supporting their field of activity. Instead of many standalone applications spreading in different directions a variety of different plug-ins for a common platform is envisioned. So any engineer will be able to select those plug-ins that are best suited to solve a particular automation problem.

This paper has highlighted a possible architecture how this can be done by organizing various plug-ins of an OTIP around a common IEC 61499 data model (cf. figure 2). Thereby data exchange between the data model and the OTIP’s core is also assigned to a plug-in, which is then required by all others (cf. figure 3). Beyond it has been demonstrated how WYSIWYG design can be implemented for development of GUIs parallel to the function block view. Here the full strengths of the integrated modeling concept become visible.

Finally it can be assumed that the availability of open and extensible engineering tools can noticeable improve and speed up the acceptance of a new stan-dard, such as IEC 61499, in practice. To further accel-erate the development of an extensible engineering tool it is imaginable to make it an open-source project. That way the whole IEC 61499 community could participate in the work.

Figure 5: Integrated control and HMI modeling

References

[1] C. Tranoris, K. Thramboulidis, “An IEC-compliant Engineering Tool for Distributed Control Applica-tions”, 11th Mediterranean Conference on Control and Automation MED'03, Rhodes, Greece, June18-20, 2003

[2] T. Strasser, K. Fessl, A. Hämmerle, M. Ankerl, “Rapid Reconfiguration of Machine-Tools for Holonic Manu-facturing Systems”, to appear in the proceedings of the 16th IFAC World Congress, Prague, 2005

[3] V. Vyatkin, “Intelligent Mechatronic Components: Control System Engineering using an Open Distributed Architecture”, Martin Luther University of Halle-Wittenberg, 2003

[4] IEC, the International Electrotechnical Commission, “IEC 61499: Function blocks for industrial-process measurement and control systems”, international stan-dard, Geneva, January 2005

[5] IEC, the International Electrotechnical Commission, “IEC 61131-3: Programmable controllers - Part 3: Programming languages”, international standard, Ge-neva, January 2003

[6] J. Gottwald, “HMI Tool integration in an open exten-

sible Engineering Platform for IEC 61499 based dis-tributed Automation Systems”, Master’s thesis, Vienna University of Technology, 2004

[7] Tridium Software Ltd., “Niagara FrameworkTM”, Web page, access date 2005-03-30

http://www.tridium.com/products/niagara.asp [8] The NetBeans Community, “NetBeans IDE”, Web

page, access date 2005-03-30 http://www.netbeans.org/products/ide/ [9] The Eclipse Foundation, “the eclipse project home-

page”, Web page, access date 2005-03-30 http://www.eclipse.org/eclipse/ [10] HMSC, the Holonic Manufacturing Systems Consor-

tium, “Function Block-Based, Open Holonic Systems Technology”, Web page, access date 2005-03-30

http://www.holobloc.com

Figure 6: The WYSIWIG GUI design tool as NetBeans plug-in