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

Transcription

1 Development of an Extensible Engineering Support Tool for IEC Considering WYSIWYG GUI Building as Example Oliver Hummer, Ivanka Krezic, Alois Zoitl Automation and Control Institute Vienna University of Technology Gußhausstr / Wien, Austria {hummer,krezic,zoitl}@acin.tuwien.ac.at Abstract In today s production and assembly processes, conventional 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 overhead. Distributed automation systems built of mechatronic components help coping with the demands of modern markets. The paper presents a new architecture for integrated modeling of such systems, introducing different views for domain experts. A modular engineering support tool based on an open tool integration platform is developed, using IEC as common data model. 1. Introduction Today s production and assembly processes are engineered and controlled using conventional programmable logical controller (PLC) based architectures that are State-of-the-Art. They represent proven technology and allow controlling even large systems when combined 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 production to mass customization provides serious challenges to modern automation systems and their engineers. 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 Thomas Strasser PROFACTOR Research Im Stadtgut A Steyr-Gleink, Austria thomas.strasser@profactor.at systems to changed hardware usually implicates enormous costs due to reengineering of the complete centralized control application. Distributed automation systems, that offer better support for reconfiguration, are discussed in chapter 2. Secondly, development of applications for PLC controlled automation systems is also restricted by certain shortcomings, which finally leads to suboptimal implementations. In modern industrial control three different types of applications are common: the control application itself, human-machine-interaction applications and applications for diagnostic purposes. Separate design of these applications naturally increases 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 different tools for different tasks force a design methodology 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 features of these platforms are: means of fully abstract and structured modeling (e.g. based on the unified modeling language UML). Thereby object-oriented source code (Java, C++ ) is generated automatically according to the model. The support for libraries containing prefabricated software modules reduces development effort and increases stability of implementations via reuse of such proven software fragments. Finally dragand-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 control system applications. Such a prototype engineering support system (ESS) is the CORFU ESS [1], developed at the university of Patras, Greece. CORFU stands for Common Object-oriented Real-time Framework for the Unified development of industrial process X/05/$ IEEE

2 measurement and control systems (IPMCS) applications. It uses a general-purpose Computer Aided Software Engineering (CASE) tool for modeling a system s use cases in UML diagrams, which then are transformed into IEC [4] function block diagrams by the Transformation Facility Manager (TFM). So the main focus of the CORFU ESS is to support the engineering phase of IPMCS. But UML diagrams are just one view of a system among many others. This paper envisions an engineering 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 integrating 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 interfaces into one device. This increases the flexibility of production equipment whilst engineering costs are reduced. 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 information about the component and is delivered with it 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 engineering views of the associated mechatronic components. The information of all different views is encapsulated within the VMC, for interaction with other VMCs only the necessary interfaces are provided. Such components, when containing embedded control devices and software, are further referred to as Automation 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 Manufacturing 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 different views mentioned above. To allow easy handling of the variety of views support through a sophisticated engineering support tool, similar to the IDEs mentioned above, will be crucial 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 network. 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 distributed 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 determines the abilities of the aspired engineering method lastingly:

3 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 engineering tools on them. Interfaces: Since the data model contains all information about the system it must provide suitable interfaces 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 International Electrotechnical Commission (IEC) has finally adopted the standard IEC [4] as reference model for designing distributed IPMCS. It can be considered as an extension of the well accepted PLC programming language standard IEC [5] to distributed automation systems. In IEC software modules are represented by function blocks, similar to those known from IEC The innovation is that the execution of IEC function blocks is completely event-driven, thus each function block has two types of I/O connectors: event connectors and data connectors. IEC applications are specified as function block networks (that is the interconnection of various function blocks, similar to electronic circuits). IEC further uses the extensible Markup Language (XML) as standardized format for storing and exchanging information. As design methodology Application Centered Engineering (ACE) is pushed, which means that whole applications are designed abstractly before considering distribution of the underlying hardware. Thus, and due to its modular, open and generic approach, IEC 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 derived: it will proof advantageous to select a modular approach, where specialized tools for the different views are organized around the common IEC data model. The achievement of this new attempt is that finally the resulting structure will be encapsulated in a common engineering tool as shown in figure 2, so that any view allows changing its associated elements of the data model whilst * Chapter 4 describes modelling HMIs by means of IEC Figure 2: General architecture of the engineering tool all other views, if affected by the modifications, 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, mechanisms for import and export of data and so on. Despite different implementations these tools hence share a considerable amount of common functionality Open tool integration platforms For the easy and flexible development of engineering tools so-called Open Tool Integration Platforms (OTIPs) have emerged. At the moment there are commercial solutions present (e.g. Niagara Framework from Tridium [7]), as well as open-source projects (the most popular members are NetBeans [8] from Sun Microsystems and Eclipse [9] powered by the Eclipse Foundation). The core of an OTIP forms the development infrastructure, presentation functions including windowing, file handling and exploration, actions as well as information 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 deploying plug-ins. Generally an OTIP is the sum of its

4 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 interconnection 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 extension 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, together 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 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 engineering support tool as plug-ins for opensource tool integration platforms The leftmost plug-in (see figure 3) is responsible for data exchange between the OTIP s core and the IEC 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 (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 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 intuitive 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 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 design. 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 prefabricated 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 control logic or diagnostic tasks. 4. Test example: GUI building in IEC This chapter gives an example how integrated modeling can be implemented into an open tool integration platform via plug-ins. As illustrative sample the development of Graphical User Interfaces (GUIs) is selected. Thereby a GUI consists of one or more HMI(s), which use(s) some sort of (touch-)screen for the visualization of their connection to an IPMCS GUI Components According to chapter 2, modern distributed IPMCS are modeled as cooperation of automation objects. These objects represent self contained intelligent devices, which are well-defined through their interface and its specification. In IEC the component s control interfaces are represented by function blocks, while the inner life of an object usually remains nondescript. 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 complex 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 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.

5 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 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. Besides 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 components 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 itself. The possibility to develop new GUI components. Import of existing third party GUIcomponents into the palette. A mechanism for composition of full featured GUIs for the use in IEC compliant GUI devices based on existing GUI-components, like buttons, sliders, and tanks. Export of new designed or composite GUI components for further distribution Test implementation for feasibility demonstration 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 applications (given as function block networks) requires an IEC runtime environment. In this example the Function Block Runtime Environment (FBRT) from Rockwell Automation provided for free by Holobloc Inc. [10] is selected. For loading and saving IEC data files an extension 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 written in the Java programming language, which can be installed and run independent from the platform) IEC GUI-components from the FBRT are added to the Form Editor s palette. As mentioned in section 3.3, in typical industrial IEC 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 GUI components provided as Java Bean. All other components 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 files has to be supported. All IEC 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 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 module and a tree viewer module leads to the implementation 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 compliant XML file. Figure 4: Implementation of the GUI design plug-in for feasibility demonstration The Look and Feel of the new developed GUI design plug-in implemented in the NetBeans tool integration 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.

6 Figure 5: Integrated control and HMI modeling 5. Conclusion Today any company must be able to quickly design and create new forms of advanced automated production in order to keep pace with the demands of ever changing markets. Distributed automation systems built of automation objects provide the required flexibility of hardware. The standard IEC assists modeling such advanced distributed automation systems and their control applications, thus providing the required flexibility of software. Furthermore this approach helps device manufacturers to protect their intellectual property, since automation objects (which in IEC are represented by function blocks) are used via their interface without detailed knowledge of their internals. As support for the creation of new IEC applications beneficial tools exist from all over the world. The deployment spreads in many different directions from modeling function blocks to verification and validation, and therewith to diverse tool environments according to IEC To enhance reusability and adaptability an extensible engineering platform is a good starting point for future IEC tool developments. Tool developers should be convinced of cooperation with all other developers to support an universal, extensible engineering system. The vendors and also the end-users should be able to self-decide which IEC 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 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 data model (cf. figure 2). Thereby data exchange between the data model and the OTIP s core is also assigned to a plugin, 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 standard, such as IEC 61499, in practice. To further accelerate the development of an extensible engineering tool it is imaginable to make it an open-source project. That way the whole IEC community could participate in the work.

7 Figure 6: The WYSIWIG GUI design tool as NetBeans plug-in References [1] C. Tranoris, K. Thramboulidis, An IEC-compliant Engineering Tool for Distributed Control Applications, 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 Manufacturing Systems, to appear in the proceedings of the 16 th 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 standard, Geneva, January 2005 [5] IEC, the International Electrotechnical Commission, IEC : Programmable controllers - Part 3: Programming languages, international standard, Geneva, January 2003 [6] J. Gottwald, HMI Tool integration in an open extensible Engineering Platform for IEC based distributed Automation Systems, Master s thesis, Vienna University of Technology, 2004 [7] Tridium Software Ltd., Niagara Framework TM, Web page, access date [8] The NetBeans Community, NetBeans IDE, Web page, access date [9] The Eclipse Foundation, the eclipse project homepage, Web page, access date [10] HMSC, the Holonic Manufacturing Systems Consortium, Function Block-Based, Open Holonic Systems Technology, Web page, access date

8