A UML Based Engineering Support System for the Developmentof Distributed Control Applications

C. Tranoris K. Thramboulidis

Elec. & Comp. Eng. Dept. University of Patras

265 00 Patras, Greecetranoris@ee.upatras.gr

Elec. & Comp. Eng. Dept. University of Patras

265 00 Patras, Greecethrambo@ee.upatras.gr

Abstract

Modern manufacturing plants are forced from the growingneed for cutting-edge products. They demand the ability toquickly respond to market requirements by designingcompetitive products and modifying existing ones. To addressthese requirements, the evolving standards IEC61499 andIEC61804 have defined a methodology and have appliedmodelling techniques of Software Engineering to the designof distributed Industrial Process Measurement and ControlSystems (IPMCSs). This status imposes the need for new IECcompliant Engineering Support Systems (ESSs). These ESSsshould support, a)the engineering phase of industrialautomation, by following modern analysis and designpractices, and b)the integration of existing fie1ld devices andfieldbuses. In this paper we present a prototype ESS tool,which follows our Object-Oriented approach for the IPMCSdevelopment that is based on UML and the function blockconcept introduced by IEC61499. To be close with the latesttrends in CASE development, our ESS tool is a merging of awell known general-purpose CASE tool and a customFunction Block design tool. The issue of portability isaddressed and implementation details are considered.

1. Introduction

Competition in the area of Industrial Process Measurementand Control Systems (IPMCSs) as well as today’s rapidlychanging market requirements imposes the need of improvingthe agility of manufacturing systems. Concepts like agile

Permission to copy without fee all or part of this material is grantedprovided that the copies are not made or distributed for direct commercialadvantage, the CSIT copyright notice and the title of the publication and itsdate appear, and notice is given that copying is by permission of theInstitute for Contemporary Education JMSUICE. To copy otherwise, or torepublish, requires a fee and/or special permission from the JMSUICE.

Proceedings of the 4th International Workshop onComputer Science and Information TechnologiesCSIT’2002Patras, Greece, 2002

manufacturing and interoperability between products,devices, utilities and vendors, are partially addressed byproprietary solutions. Even more, the most of the traditionalproducts and tools are far away from the new challengingtechnologies of Software Engineering. These technologiesmust be considered to provide the basis for the definition ofnew methodologies for the design and development of thealways-growing complexity distributed IPMCSs.

Towards this direction are the evolving standards, IEC-61499and the IEC-61804 [1][2]. These standards define the basicconcepts for the design of modular, re-usable, distributedindustrial process, measurement and control systems. Thefunction block construct is defined as the main building blockof IPMCS applications, in a format that is independent ofimplementation. The above standards define also amethodology to be used by system designers to constructdistributed control systems. It allows systems to be defined interms of logically connected function blocks that run ondifferent processing resources. Complete applications, can bebuilt from networks of function blocks, formed byinterconnecting their inputs and outputs.

New generation, function block oriented, EngineeringSupport Systems (ESS), are highly required to support thewhole life cycle of IPMCS applications. Such an ESS mustsupport the engineer, in both the analysis and design phase aswell as in the implementation phase. Using such a tool, theengineer must be able to start with the analysis of the plantdiagram so as to capture the control requirements. Then, heshould be able to define the major areas of functionality andtheir interaction with the plant. During this task, he should beable to exploit function blocks provided by intelligent fielddevices, such as smart valves, but also to assign functionalityinto physical resources such as PLCs, instruments andcontrollers. All the above should be accomplishedindependent of the underlying communication subsystem andin the extreme case, where it is an aggregation ofinterconnected independent fieldbus segments, even fromdifferent vendors.

To address the above requirements we have defined and haveunder development the CORFU framework, that is a CommonObject-oriented Real-time Framework for the Unified(CORFU) development of distributed IPMCS applications[12]. The CORFU framework is a set of collaborating classes

that embody an abstract design capable to provide solutionsfor the family of IPMCS’s related problems. It will attemptto increase reusability in both architecture and functionalityby addressing issues such as interoperability and integrateddevelopment of distributed IPMCSs.

In [9] we have introduced our approach for the design ofIPMCSs, that considers the analysis phase, as well as thetransition to the design one, since these phases are slightlyaddresses by IEC standards. We have adopted the widelyaccepted use case driven approach of Ivar Jacobson and theUML notation to capture the requirements of the IPMCSsystem. Our approach introduces the evolution of theserequirements through a set of well-defined transformationrules to produce the Function Block design diagrams. Thedefined transformation rules may lead to the automation ofthe transmission to the design phase by an EngineeringSupport System. In this paper we present such a prototypeESS tool that follows our approach. This ESS tool is amerging of a well known general-purpose CASE tool and acustom Function Block design tool. Both tools co-operate tohelp the process engineer during the engineering-phase.

The rest of this paper is organized as follows. In section 2 webriefly consider the current status of the IPMCS’sdevelopment process and the way this process is addressed bythe IEC 61499 standard. Section 3 describes our approach forthe capturing of requirements with the UML notation andtheir evolution to Function Block design diagrams. Section 4,presents our prototype Engineering Support System, the waythe ESS interacts with a popular general-purpose CASE tool.Implementation details and its compliance with IEC 61499are also discussed. We finally conclude the paper in the lastsection.

2. Current status in the design of IPMCSs

The engineers in the industrial and control sector havealready sense the emerging needs of customers since severalyears, and they constantly try to develop standards, like theproposed IEC61499 standard.

Towards the smoothly implementation and development ofindustrial, the IEC61499 Application Development Guidelinepart, proposes an incremental and iterative process, whichassumes that an Engineering Support System (ESS) shouldsupport the whole engineering task. The core concept of thisprocess is the cycle Evaluate-Improve-Operate that isrepeated many times. For example the “Evaluate” workflowincludes the workers that participate in the system’sevaluation activity and the artifacts that they must produce.The assessment of the system versus business objectives, isone of the tasks to be performed during this workflow, inorder to identify requirements for system improvement.

However, the standard does not define a way to capture theserequirements as well as the initial system’s requirements. Itonly suggests that they may be expressed textually or in adiagram format.

Further each workflow may be specified in more details by anumber of sub-workflows. The “Improve” workflow, for

example, consists of the following sub-workflows:Documentation, Design, Validation, Installation and Testing.Each sub-workflow includes a number of activities that thecorresponding workers must carry out. The engineer mayproduce any documentation during the Improve workflow.During the “Operate” workflow the IPMCS will go inoperation. This workflow is usually preceded by installing anoperational configuration.

Lewis in his latest book [6], accepts that IPMCSs like mostcomplex software designs require at least four differentdesign views and a set of scenarios, as it is described by the4+1 View Model Architecture of P. Kruchten [7]. AlthoughKruchten has considered applying these design views in thedevelopment object oriented systems, the same views are alsoapplicable to IPMCSs. Lewis, although accepts thatIEC61499 represents an important step towards a unifieddesign architecture, states that it only provides just one of thefive design views required for distributed controlapplications.

Nowadays, the first ESSs that attempt to support theengineering phase of industrial processes by following theIEC61499 are appearing. Such a tool is the Function BlockDevelopment Kit (FBDK)[10] which is an effort of theHolonic Manufacturing Systems consortium. The tool iscapable of defining Function Block types, and designingFunction Block diagrams, resources and devices. TheseFunction Block types and Function Block diagrams areportable by means of XML as is specified in IEC61499.FBDK provides also a Java interface that lets the engineer tovisually test his diagrams, but lacks the capability ofdownloading the Function Block types and distributingFunction Blocks networks in real devices. Additionally,FBDK does not address the capture of requirements and isnot mature enough to be used for the design orimplementation of actual control systems.

3. Our approach

According to our approach, which is presented in detail in [9]and in order to enhance the requirements capturing, systemanalysis and the transition to the design phase we haveadopted the well-established UML notation [8]. We have alsodefined a set of Transformation Rules, in order to smoothlymove from the UML analysis model to the Function Blockdesign diagrams of the underlying system. Our approacheliminates the discontinuity between traditional developmentand modern IPMCS design methodologies, as well as certainunspecific and underdeveloped parts of the proposed 61499standard in the direction of a specific methodology.

In our approach we would try to clarify in more detail theIMPCS development process. The control engineer starts theprocess normally, with the workflow of capturing therequirements of the system by means of the well-knownconcept of Use Cases. The next workflow, in which systemanalysts participate, copes with the examination of thedynamic behaviour of the system. This is done by means ofInteraction Diagrams, which is a UML diagram for describingbehaviour. The Interaction or Sequence Diagrams are

considered as the first realisation of use cases. As a next step,a refinement of the internal system will give the interactiondiagrams, which shows the internal objects and the way theycollaborate to provide the required behaviour. The nextworkflow, which must be in harmonisation with the CaptureBehaviour workflow, is the one that deals with the design ofthe static view of the system in terms of class diagrams. Thesetwo workflows come in parallel and require from the analyststo go back and forward in order to specify better theunderlying system.

As soon as the requirements model is defined and theproblem domain model in terms of UML class diagrams iscompleted [5], we are ready to move into the design phase.Our intention is to produce designs in terms of FunctionBlock diagrams that are better understood by the control andfield engineers of the system. In order to smoothly move fromthe UML analysis models to the Function Block diagrams ofthe underlying system, we have defined a set ofTransformation Rules [9]. These rules cope with thetransformation of the Analysis model diagrams to equivalentFunction Block diagrams. In detail, the transformation ofeach Interaction Diagram to the equivalent Function BlockDiagram follows a set of rules, which define how objects andmessages will be transformed to Function Blocks and dataand event connections respectively. Additionally from theclass diagrams we extract detail information on how classeswill be transformed to equivalent Function Block types.

4. A prototype ESS tool

For the purpose of verifying our approach, we had to examinethe construction of a prototype ESS tool. This should enableus to examine the possibility of applying our approach as wellas automating the transformation task. At this phase we hadtwo practices to follow: either to build the tool from scratch,or to extend an existing tool. Building the tool from scratch,would require from us to embed additional functionality, suchas requirements capturing, class diagram design, etc, thusmaking the development of our tool, much more complicatedand loosing our focus from the actual problem of automatingthe process. Since most software engineers use CASE toolsfor the requirements capture, analysis and design of modernsystems, we had to find a solution for using such CASE toolswith the Function Block concept.

Figure 1. Control Engineer Interacting with the ESS

The initial idea was that our tool should integrate and interactwith a general purpose CASE tool in order to ease the processof designing the Function Block diagrams. This would enablethe potential engineer to analyse his industrial application,write requirements and draw scenarios and class diagramswith the CASE tool. In a subsequent step, he could obtainautomatically the diagrams of the CASE tool to our prototypetool, and proceed with the design of his application withFunction Blocks, which are closer to the finalimplementation. Figure 1 show this concept, where theengineer interacts with the general purpose CASE tool andthe ESS extension tool during the process of engineering hisIPMCS application.

4.1 Selecting a general purpose CASE tool

As we presented above, our implementation needed a CASEtool that could interact with our FB design tool, thus it shouldhave at least one extension mechanism. We examined severalCASE tools and fortunately Rational's Rose, one of the mostpopular CASE tools, has several extension mechanisms, andcomes with a suite of specific tools for software engineering,to cover the needs from requirements capture through thefinal implementation. Rose supports two mechanisms and canbe extended either with its custom scripting language, or canbe used as a COM automation server [11] through a typelibrary provided by Rational. At this stage, we consideredthese two possible available solutions for the integration:either to extent Rose through its scripting language with a setof new menu commands, toolbar buttons, etc, or to use anexternal custom developed tool for the management of theFunction Block diagrams by means of the automationmechanism of the CASE tool. We chose the second option,since it was simpler and much more manageable to use theautomation interface and additionally we could implementmore rapidly the Function Block prototype tool. Theautomation interfaces makes possible to externally browse theinternal object model of Rose, i.e. its classes, properties anddiagrams. Additionally, it lets the programmer to manage(create, edit, delete) externally, classes and diagrams, thusgiving the possibility to enable in our extension tool round-trip engineering capabilities.

4.2 Our prototype tool: Implementation details

Figure 2, shows a screenshot from our prototype FB designtool, which we developed with Borland's Delphi IDE. Roseallows us to use it as a COM server, through its type libraryas mentioned. Type libraries provide a way to get more typeinformation about an object than can be determined from anobject’s interface. The type information contained in typelibraries provides needed information about objects and theirinterfaces, such as what interfaces exist on what objects, whatmember functions exist on each interface, and whatarguments those functions require.

FB design toolCASE tool

Engineer

ESS tool

So, the first step was to import the type library in Delphi andhave access to the interface of Rose automation. Delphiprovides a type library editor and a tool that translates thetype library file to Delphi constructs and creates theequivalent dispatch interfaces. Dispatch interface declarationsare used to describe the methods and properties a COMAutomation object implements through its IDispatchinterface.

Figure 2. Our prototype FB design tool

After importing the type library, we have full access throughour programming language to all the interfaces and Rose 'sobject model.

Figure 3. Rose running on the background

The first step is actually to create the application, so weinvoke a certain call to class factory's CreateInstance method,

which (through windows API) creates the instance of theCoClass and thus the application. An example is thefollowing extract from the code (in Delphi):

fRoseApp:= CoRoseApplication.Create;

where

fRoseApp variable is an instance of the IRoseApplicationinterface and is used as the interface to Rose.

Then we can load our model with

theModel:=fRoseApp.OpenModel('C:\test\class_diagram_01.mdl');

and get for example from the diagram categories, theScenario Diagrams with

theRC := theModel.RootCategory ;

theSD := theRC.ScenarioDiagrams;

where theRC is type of IRoseCategory

and theSD is type of IroseScenarioDiagram Collection

Other useful interfaces are IRoseObjectInstance whichprovides access to all object instances on a diagram,IRoseMessageCollection which provides access to thecollection of messages in a scenario diagram and theIRoseMessage which provides access to individual messages.Figure 3 shows Rose with our project opened, which normallyis active and hidden in the background.

Figure 4 shows on the left-hand side the class ValveControlwith some methods like check(), ProgramReady() andOpenValve() as it appears in the CASE tool. The right–handside, shows the equivalent Function Block that is createdfrom the FB prototype tool when it applies our proposedtransformation rules. The event inputs and outputs of theFunction Block, have been designed automatically. Forexample the output events SBW() and PUR() on the FunctionBlock, are extracted from the message exchange of theobjects on an interaction diagram while a use case is realized.

Figure 4. Class to Function Block

4.3 Portability in ESSs

We decided for our tool to comply with the portabilityagreement proposed in IEC 61499 Industry TechnicalAgreement. So our tool should be capable of:

• producing library elements like data types, function blocktypes, resource types, device types, function blockdiagrams, system configurations, etc using the syntax andthe semantics defined in Annex A of IEC 61499-2

ValveControl

check()ProgramReady ()openValv e()

• correctly parsing and interpreting all elements in theXML DTDs, which are defined in Annex A of IEC61499-2

• utilizing files for the exchange of library elements. Forexample the tool should support certain file types forelement exchange like .fbt for Function Block types, .devfor Device types, e.t.c.

The above requirements, guided us to include in our toolXML parsing and streaming capabilities. With the aboveprovided interfaces, the tool is capable to browse in thediagrams and in their objects and apply the rules. In order tocheck the portability of our tool, we have managed toexchange library elements such us Function Block types anddiagrams, with the FBDK tool mentioned previously.Additionally, FBDK gives us the ability to test via the Javalibrary that it provides, our Function Block design diagrams.

5. Conclusions

In order to enhance the requirements capturing, the systemanalysis and the transition to the design phase of IPMCSs, wehave defined a new approach towards a unified designmethodology. Our approach adopts use cases and the UMLnotation to capture requirements of the IPMCS applications.It uses, the interaction diagrams for the first realization of usecases and a set of well-defined transformation rules for thesubsequent evolution of requirements to Function BlockDiagrams.

In this paper we have presented such a prototype FB designtool and additionally its interaction with a popular general-purpose CASE tool. Our FB tool is capable of communicatingwith the CASE tool and it can follow specific transformationrules, for mapping interaction and class diagrams toequivalent function block diagrams. Through our process theengineer designs his diagrams on the CASE tool and exportsthem to our prototype FB design tool and vice-versa. Then heproceeds with the design of his application with FunctionBlocks, which are closer to the final implementation. Wehave presented also implementation details of our tool andhow it complies with the IEC 61499 Industry TechnicalAgreement.

In our prototype tool still some missing functionality existand further improvement is needed. The tool needs:

• the capability of distributing the Function Blocks in fielddevices over interconnected networks

• the ability to download the Function Block types andFunction Blocks networks to the interworking units of thenetworks and create all the Function Block data andevent connections

• a more sophisticated user interface for the engineer todesign the Function Block diagrams

• further operations that will help the engineer towards theround-trip process.

References

1. IEC Technical Committee TC65/WG6, “IEC61499Industrial-Process Measurement and Control –Specification”, IEC Draft 2000

2. IEC sub committee no. 65c: digital communications,working group 7: function blocks for process control,“IEC1804 General Requirements”, IEC Draft 1999

3. C.Cseh, M.Jansen, J.Jasperneite, “ATM networks forfactory communication”, 7th IEEE InternationalConference on ETFA, 1999

4. K.Thramboulidis, C.Tranoris , “An Architecture for theDevelopment of Function Block Oriented EngineeringSupport Systems”, IEEE International Symposium onCIRA July 29 - August 1, 2001, Banff, Alberta, Canada

5. Ivar Jacobson et.al. “The Unified Software DevelopmentProcess”, Addison, Wesley 2000 Ch.2 p.26

6. R. Lewis, Modelling control systems using IEC 61499,IEE 2001

7. Kruchten P.: “The 4+1 view model of architecture”, IEEESoftware, Nov. 1995

8. OMG UML specification version 1.3, March 2000

9. C. Tranoris, K. Thramboulidis, "From Requirements toFunction Block Diagrams: A new Approach for theDesign of Industrial Applications", 10th MediterraneanConference on Control and Automation, 9-12 July, 2002

10. “Function Block Development Kit”, RockwellAutomation, http://www.holobloc.com

11. http://www.microsoft.com/com/tech/dcom.asp

12. K. Thramboulidis, “Development of Distributed IndustrialControl Applications: The CORFU Framework”, 4thIEEE International Workshop onFactory Communication Systems, Sweden, August 2002