FROM REQUIREMENTS TO FUNCTION BLOCK DIAGRAMS:

A NEW APPROACH FOR THE DESIGN OF INDUSTRIAL CONTROLAPPLICATIONS

C. Tranoris , K. Thramboulidis

Electrical & Computer Engineering DepartmentUniversity of Patras, 265 00 Patras, Greece.e-mail:{tranoris, thrambo}@ee.upatras.gr

Keywords: IPMCS, Software process, Use Cases,UML, Function Block

Abstract

The always growing need, for innovative products,forces manufacturing plants to improve their abilityto quickly respond to market requirements bydesigning competitive products and modifyingexisting ones. However most of the traditionalmethods, products and tools are far away from thenew challenging technologies of SoftwareEngineering. Today’s systems are composed ofmonolithic applications that are almost impossibleto integrate and even to expand. Modularity,flexibility, extensibility, reusability andinteroperability are dimensions slightinglyaddressed by the most traditional proprietarymethods and engineering tools. In this paper, wedescribe our approach for the design of distributedIndustrial Process, Measurement and ControlSystems (IPMCSs). We adopt the use case drivenapproach proposed by Ivar Jacobson and the UMLnotation, to capture requirements. We have defineda process for the transformation of requirementsexpressed in the form of use cases, to IPMCSsdesign specifications, expressed in the form ofFunction Block diagrams. The whole process,which is in the context of the CORFU framework,is fully automated, so an Engineering SupportSystem can support it.

1 Introduction

Most of the Industrial Process Measurement andControl Systems (IPMCSs) have until recently,

been based either on traditional distributed controlsystems or on programmable logic controllers. Inboth cases, the systems are composed of monolithicapplications that are almost impossible to integrateand even to expand. Modularity, flexibility,extensibility, reusability and interoperability aredimensions slightingly addressed by manytraditional proprietary engineering tools andproducts. Concepts like agile manufacturing andinteroperability between products, devices, utilitiesand vendors are discouraged by proprietarysolutions. Even more, the most of the traditionalproducts and tools are far away from the newchallenging technologies of Software Engineering.

Competition as well as today’s rapidly changingmarket requirements imposes the need ofimproving the agility of manufacturing systems.New challenging technologies of SoftwareEngineering must be considered to provide thebasis for the definition of new methodologies forthe design and development of the always-growingcomplexity distributed IPMCSs.

Evolving standards, like IEC-61499 and the morerecent IEC-61804, contribute to this direction[1][2]. They define the basic concepts for thedesign of modular, re-usable, distributed industrialprocess, measurement and control systems. Thefunction block construct is defined as the mainbuilding block of IPMCS applications, in a formatthat is independent of implementation. It is anabstraction mechanism that allows industrialalgorithms to be encapsulated in a form that can bereadily understood and applied by industrialengineers who are not specialists in theimplementation of complex algorithms. A function

block may be primitive i.e. small enough to providea solution to a small problem, such as the controlof a valve, or composite, that is an aggregation offunction blocks, i.e. big enough to control a majorunit of plant. Function blocks can be used to definerobust, re-usable software components thatconstitute the distributed IPMCSs.

The above standards define also a methodology tobe used by system designers to constructdistributed control systems. It allows systems to bedefined in terms of logically connected functionblocks that run on different processing resources.Complete applications, can be built from networksof function blocks, formed by interconnecting theirinputs and outputs.

New generation, function block oriented,Engineering Support Systems (ESS), are highlyrequired to support the whole life cycle of IPMCSapplications. Such an ESS must support theengineer, in both the analysis and design phase aswell as in the implementation phase. Using such atool, the engineer must be able to start with theanalysis of the plant diagram so as to capture thecontrol requirements. Then, he should be able todefine the major areas of functionality and theirinteraction with the plant. During this task, heshould be able to exploit function blocks providedby intelligent field devices, such as smart valves,but also to assign functionality into physicalresources such as PLCs, instruments andcontrollers. All the above should be accomplishedindependent of the underlying communicationsubsystem and in the extreme case, where it is anaggregation of interconnected independent fieldbussegments, even from different vendors.

To address the above requirements we havedefined and have under development the CORFUframework, that is a Common Object-orientedReal-time Framework for the Unified (CORFU)development of distributed IPMCS applications. Inthe context of this paper we consider the analysisphase, as well as the transition to the design one,since these phases are slightly addresses by IECstandards. We adopt the widely accepted use casedriven approach of Ivar Jacobson and the UMLnotation to capture the requirements of the IPMCSsystem. We then proceed to the evolution of these

requirements through a set of well-definedtransformation rules to produce the Function Blockdesign diagrams. The defined transformation rulesmay lead to the automation of the transformationphase by an Engineering Support System.

The rest of this paper is organized as follows. Insection 2 we briefly refer to the CORFUframework. In section 3, we consider the currentstatus of the IPMCS’s development process and theway this process is addressed by the IEC 61499standard. Section 4, describes our approach for thecapturing of requirements with the UML notationand their evolution to Function Block diagrams. Insection 5, we consider the steam boiler control as acase study and we apply our approach, in thedesign of Function Block diagrams. We finallyconclude the paper in the last section.

2 The CORFU framework

In order to meet the requirements imposed bytoday’s distributed IPMCS systems, we havedefined the CORFU framework for thedevelopment of distributed IPMCS applications.Frameworks provide an important enablingtechnology for reusing both the architecture and thefunctionality of software components allowing theIPMCS engineer to ignore all the complexitiesinherent in field devices and fieldbuses and toconcentrate on the actual problem to be solved. Theproposed framework would assists process andsystem engineers in the development andconfiguration of distributed IPMCSs. The proposedframework, which is shown in fig. 1, address:

1. the IPMCS engineering process, which utilizesthe engineering workspace-to-fieldbus channeland

2. the IPMCS operational phase, which utilizes theSCADAclient-to-fieldbus channel and thefieldbus-to-fieldbus channel.

For the SCADA client-to-fieldbus channel, weadopted Internet although its role as a channel overwhich SCADA applications are built is a fairlyrecent phenomenon. However Internet’s impact hasbeen substantially greater than that of otherproprietary channels in existence for several

decades. For the same reasons we adopted Internetfor the engineering workspace-to-fieldbus channel.However, Internet in its current status is notpossible to be considered for the fieldbus-to-fieldbus channel, where alternatives such as Fastswitched-Ethernet, Gigabit Ethernet and ATM maybe successfully adopted [3].

Figure 1. High-level view of the CORFUframework.

The CORFU framework is a set of collaboratingclasses that embody an abstract design capable toprovide solutions for the family of IPMCS’srelated problems. It will attempt to increasereusability in both architecture and functionality byaddressing issues such as interoperability andintegrated development of distributed IPMCSs.The main components of our framework are theinterworking unit and the virtual fieldbus. Theinterworking unit will be the infrastructure for thedevelopment of the interoperability mechanism,while the virtual fieldbus would provide the APIsrequired by the different communication channels.

To proceed with the design and development of anESS that is required to support the design,implementation, commissioning and operation ofIPMCSs we have defined the 4-layer Architecturepresented in [4].

3. Current status in the design ofIPMCSs

Until recently, most of the IPMCSs have beenbased either on traditional distributed control

systems or on PLCs and have been developed withproprietary tools. This results in systems that arecomposed of monolithic applications, which arealmost impossible to integrate or even to expand.

The engineers in the industrial and control sectorhave already comprehend the above issues. Theyhave sense the emerging needs of customers sinceseveral years, and they constantly try to developstandards, like the proposed IEC61499 standardand the more recently proposed IEC1804.

Towards the smoothly implementation anddevelopment of industrial applications mentionedabove, the IEC61499 Application DevelopmentGuideline part, proposes an incremental anditerative process, which assumes that anEngineering Support System (ESS) should supportthe whole engineering task. The core concept ofthis process is the cycle Evaluate-Improve-Operatethat is repeated many times.

We present in figure 2 the whole process in piecescalled workflows. Each workflow is given in the“fish” notation and includes the workers thatparticipate in the activity as well as the artifactsthat are defined as deliverables of thecorresponding activity [5]. For example the“Evaluate” workflow includes the workers thatparticipate in the system’s evaluation activity andthe artifacts that they must produce. Theassessment of the system performance versusbusiness objectives, is one of the tasks to beperformed during this workflow, in order toidentify requirements for system improvement.

However, the standard does not define a way tocapture these requirements as well as the initialsystem’s requirements. It only suggests that theymay be expressed textually or in a diagram format.

Further each workflow may be specified in moredetails by a number of sub-workflows. The“Improve” workflow, for example, consists of thefollowing sub-workflows: Documentation, Design,Validation, Installation and Testing as is shown infig. 2. Each sub-workflow includes a number ofactivities that the corresponding workers mustcarry out. The engineer may produce anydocumentation during the Improve workflow.During the “Operate” workflow the IPMCS will go

in operation and is usually preceded by installingan operational configuration.

Figure 2. The “fish” notation for the developmentprocess of IPMCSs.

Lewis in his latest book[6], accepts that IPMCSslike most complex software designs require at leastfour different design views and a set of scenarios,as it is described by the 4+1 View ModelArchitecture of P. Kruchten [7]. AlthoughKruchten has considered applying these designviews to object oriented systems, the same viewsare also applicable to IPMCSs. Lewis, althoughaccepts that IEC61499 represents an important steptowards a unified design architecture, states that itonly provides just one of the five design viewsrequired for distributed control applications.

4. Our approach

In the context of our unified design architectureand in order to enhance the requirements capturing,the system analysis and the transition to the designphase we have adopted the well-established UMLnotation to proceed to Function Block baseddesigns for the development of distributedIPMCSs. This approach will eliminate thediscontinuity between traditional development andmodern design methodologies, as well as certainunspecific and underdeveloped parts of theproposed 61499 standard in the direction of aspecific methodology. It would try to clarify inmore detail the IMPCS’s development process.

Figure 3 presents the steps of our incrementalapproach. The process starts with the workflow ofcapturing the requirements of the system by meansof the well-known Use Case concept. During thisworkflow, end-users of the IPMCS, systemanalysts, software architects, control and fieldengineers participate in order to properly define thesystem, its architecture, and the way it shouldbehave with external events, devices and humans.If the system already exists and needs to beexpanded, a re-engineering phase should also takeplace and certain old parts should be considered forre-using, re-implementing or interfacing with newones.

We suggest using Use Cases and Use Casediagrams for requirement capture anddocumentation, not only for their wide acceptanceand applicability, but because they are also part ofthe UML notation. Additionally, there is a lot of

CaptureRequirements

CaptureBehavior

CaptureSystem Static View

Design FunctionBlock Diagram

Analysis Design

ProposedTransformation

Rules

Clarify through iterations

Figure 3. Overview of our approach

bibliography that undertakes Use Cases and certaintemplates have been introduced for their writing.Formally, the use case construct is used to definethe behavior of a system or other semantic entitywithout revealing the entity’s internal structure.

Each use case specifies a sequence of actions,including any variants that the entity can performinteracting with its actors [8]. As an example, wegive in Figure 4 the System startup use case, thatwe have written during the requirements captureworkflow of the Steam Boiler control application,which we have considered as a case study for ourapproach [9].

The next workflow i.e. the Capture Behavior, inwhich system analysts participate, copes with theexamination of the dynamic behavior of thesystem. This is done by means of InteractionDiagrams, which is a notation for describingbehavior in UML. The Interaction or SequenceDiagrams are considered as the first realization ofuse cases. They present an Interaction, which is aset of message exchanges between Classifiers i.e.objects and classes participating in a Collaborationto effect a desired operation or result. Aninteraction specifies the communication betweeninstances performing a specific task. Eachinteraction is defined in the context of the specificcollaboration.

A sequence diagram has two dimensions:

1. the vertical dimension, which represents time

2. the horizontal dimension, which representsdifferent objects

Normally time proceeds down. Usually only timesequences are important. However in real-timeapplications the time axis could be an actualmetric. There is no significance to the horizontalordering of the objects. The different kinds ofarrows used in sequence diagrams are explained indetail in [8].

During the first iteration, the analyst of the IPMCSsystem under study can draw the collaborationbetween the system and the actors of the system.This can be drawn by means of Jacobson'sstereotypes as is shown in Figure 5. As a next step,a refinement of the above diagram will give the

interaction diagram of Figure 6, which shows thesystem’s internal objects and the way theycollaborate to provide the required behavior.Among the system’s objects we discriminate theinterface-objects that are the interfaces of thesystem to the external real world devices.

Use Case System Startup

General

This use case describes the actions performed by the systemduring start-up and initialization phase.

Actor

Steam Boiler User

Precondition

The steam boiler is stopped and the system is in the Initializationmode.

Basic Path

1. The user presses the start button and the system sends amessage to all external physical units to check if they areready to start.

2. The physical units send a message back to the system, thatthey are ready to start operating.

3. As soon as this message has been received the programsend a message to the Steam Level MU to check backwhether the quantity of steam coming out of the steam­boileris really zero.

4. The system send a message to the WLMU and checks thelevel of the water. If is between the limits, the system willsend continuously a signal to the physical units until itreceives a confirmation signal which must necessarily beemitted by the physical units.

5. As soon as the confirmation signal has been received, thesystem continues to operate correctly and to control thewater level.

Alternative Paths

In step 2, if the unit for detection of the level of steam is defective---that is, when v is not equal to zero---the system enters theemergency stop mode.

In step 3, if the quantity of water in the steam­boiler is above N 2the program activates the valve of the steam­boiler in order toempty it. If the quantity of water in the steam­boiler is below N 1then the program activates a pump to fill the steam­boiler. If theprogram realizes a failure of the water level detection unit it entersthe emergency stop mode.

In step 4, if any physical unit is defective the system enters thedegraded mode.

In step 4, if a transmission failure happens, it puts the system intothe mode emergency stop mode.

PostCondition

The steam boiler is started and the system is in the Normal mode.

Figure 4: The system startup use case.

Figure 5. Collaboration diagram for the systemstartup Use Case

Figure 6. Detailed Interaction Diagram for thesystem startup Use Case

The next workflow i.e. the Capture System staticview is the one that deals with the design of thestatic view of the system in terms of classdiagrams. Since this workflow must be inharmonization with the Capture Behaviorworkflow, the analysts must to go back and forthin order to better specify the underlying system.

Figure 7 shows a part of the Class Diagram ofthe Steam boiler control system. The diagramshows the problem domain classes and theirdependencies. The engineer can use thesedependencies in order to extract information onhow the Function Blocks will be connected. Alsoany aggregate or composite class should bedisplayed on this diagram. During the design of

this diagram the analyst should have in mind that:

1. Every class is stereotyped as <<leaf>> becauseFBs cannot have descendants

2. The associations in the class diagram should bealways dependencies.

Figure 7. Part of Steam Boiler Class diagram

4.1 Moving into Design

As soon as the requirements model is defined andthe problem domain model in terms of classdiagrams is completed, we are ready to move intothe design phase. Our intention is to producedesigns in terms of Function Block diagrams thatare better understood by the control and fieldengineers of the system.

: User StartButton : SteamBoilerUI

: Initialize : PumpControl

: ValveControl

: WLMU

Expire : Timer

: SLMU

1: Press Start

2: start

3: Ready? 7: ready

4: Ready?

8: ready

5: Ready?

9: ready

13: check

14: Level_Ok

6: Ready?

10: ready

11: check12: steam_ok

: User

InitializeControl

WLMU WaterLevel Checker

SLMU PumpControl

ValveControl

Start()Start()SBW()

SBW()SBW()

SBW()

level(q)

CheckWaterLevel()[q<N1] Open()

[q>N2] Open()[N1<q<N2] WL_OK()

PUR()PUR ()

PUR ()PUR ()PUR ()

PUR ()PUR ()

PUR

ExpireTimerPeriodTimer

SteamLev elMU

WaterLev elMU

SBControler

EstimateLev el WaterLev elChecker

PIDControler

Valv eControlPumpControl

Superv ision

In this phase the participation of control and fieldengineers that would apply their expertise in theproper and better design of the system ismandatory. The proposed process is incrementallyapplied and requires from the engineers to proceediteratively, going back and forth around thesuggested workflows, in order to clarify thenecessary artifacts for the design of the application.

In order to properly design the Function Blockdiagram of the underlying system, we havecaptured a set of Transformation Rules that couldbe applied to smoothly pass from the analysismodel to the design one. These rules cope with thetransformation of Class Diagrams and InteractionDiagrams to equivalent Function Block networkdiagrams.

For the transformation of each Interaction Diagramto the equivalent Function Block Diagram, thefollowing rules, have been defined:

1) Every Object participating in the Interactiondiagram should be mapped in a FunctionBlock. If the Object interacts with anexternal object of the system, then an extraService Interface Function Block is addedto the function block diagram.

2) Every Object Interaction between twoobjects will be mapped to an eventconnection between the correspondingfunction blocks.

3) The message parameters of the objectinteraction will be the WITH dataparameters of the Function Block and theywill be mapped to data connections.

4) If a message has more than one recipient,the Function Block Splitter should beinserted. An example of such a message isthe message PUR() in figure 6.

5) When two or more events should be meettogether to proceed further the process, theEvent Rendezvous Function Block shouldbe used. An example of such a message isthe message SBW() in figure 6.

The following rules should be applied in order toextract information from the class diagram andinsert it to the Function Block Diagram:

1) Every class should be mapped to a FunctionBlock type. In detail:

a. The class name should be the FunctionBlock type name.

b. Private data members should be mappedto Internal data of the Function Blocktype.

c. Public data members should be the datainput and data output variable names ofthe function block type.

d. Public methods should be mapped to FBevents. Method parameters should be theWITH data, except from methods thatread/write (get/set) internal variables.

e. Methods should not have a return value.

2) Every dependency of the class diagramshould be mapped to a FB connection andmust be further clarified to an event or adata connection.

3) A further study and refinement of the classdiagram should reveal the aggregate-composite objects that will be mapped toComposite Function Blocks. Everyaggregate class composed of classesrunning on the same resource, should bemapped to a Composite FB type.

4) Every aggregate class composed of classesrunning on different resources should be oftype Sub-application FB.

5) The class's state-chart diagram is actuallythe Execution Control Chart (ECC) of thecorresponding Function Block type.

Following the above rules, the transformation isstraightforward. The process can be fullyautomated by an ESS tool with CASE capabilitiesand we are currently working on this direction bydeveloping a prototype tool.

Since we have not implemented yet the tool toautomate the above process we used the FunctionBlock Development Kit[11] to produce theFunction Block diagrams. Figure 8, shows theFunction Block Diagram that corresponds to theSystem Startup Use Case. We can notice the Event

Splitter E_SPLIT and Event Rendezvous E_RENDFunction Blocks, which are used where there is aneed for messaging more recipients and meetingtogether certain events.

Figure 8. Function Block Diagram implementingSystem Startup

5. The Steam Boiler Control Case Study

The steam-boiler control specification problem hasbeen proposed for testing the various designformalisms with respect to their versatility andapplicability to embedded control system design.An informal specification of the original problem ispresented in detail in [9]. The specificationconcerns a control application that serves to controlthe level of water within some safe range in asteam boiler. The physical environment comprisesthe following units:

• the steam boiler: A water tank of total capacityC in litters, which generates steam.

• a water sensor: A device to measure thequantity q in litters of water in the steam boiler

• four pumps to provide the steam boiler withwater. Each pump has its capacity P inlitters/sec.

• four devices to supervise the pumps (onecontroller for each pump)

• a steam sensor: A device to measure thequantity õ in litters/sec of steam which comesout of the steam boiler.

There are two normal water quantity bounds N1and N2 in litters, within which the water quantityshould be maintained during regular operation. Theplant provides the control application withinformation from various physical units andsensors, while the control application controls theplant based on the messages received from theplant. The control application communicates withthe physical units i.e. the plant and the controllersthrough messages transmitted via communicationchannels. The time for the transmission can beneglected. The control application follows a cycleand a priori does not terminate. A sampling eventoccurs every five seconds. When it happens, thecontrol application first receives messages comingfrom the physical units. Then the controlapplication analyses the information, which havebeen received and calculates the suitable pumpcontrol value p. Finally the calculated control valuep is transmitted to the physical pump by thecontroller. The water quantity q, the steam outputõ and the throughput of the pump p are continuousfunctions of time. The control application uses thecorresponding sampling data.

We also assume that all messages coming fromor going to the physical units are supposed to bereceived or emitted simultaneously by the programat each cycle and there is no communication failureduring system operation.

There are two dangerous bounds for the waterquantity in the boiler: The minimum limit quantityM1 and the maximum limit quantity M2. BelowM1 the steam boiler would be in danger after fiveseconds, if the steam continued to come out at itsmaximum quantity without supply of water fromthe pumps. Above M2 the steam boiler would be indanger after five seconds, if the pumps continue tosupply the steam boiler with water withoutpossibility to evacuate the steam

We have included in our problem the requirementof wide distribution of the devices of the SteamBoiler. A solution to this problem is presented inmore detail in [10]. We applied our suggested

process in the problem and we made the followingsteps:

1) We first expressed the requirements of thesystem by means of Use Cases. We extractedall the requirements from [9] and we defined,the actors of the system and the Use Cases thatthe system should carry out. A few examples ofuse cases are: the System set-up use case,Monitor and Control use case and handlingtransmission- failure use case, as shown inFigure 9. We next proceed to the detaildescription of each use case. Figure 10 showsthe description of the Monitor and Control UseCase.

Figure 9. Use case diagram of the Steam BoilerControl

2) The next step was for every Use Case toanalyse the messages that the system exchangeswith external devices and humans. This wasaccomplished with a simple collaborationdiagram such as the one shown in Figure 5.With a further clarification, we identified thesystem’s internal objects that should interact toproduce the required behaviour and we draw amore detailed interaction diagram like the oneshown in Figure 6.

3) In parallel with the interaction diagram, wedraw the problem domain class diagram,identifying operations and associations.

Use Case Monitor and Control

General

This use case describes the actions performed by the system duringnormal operation phase.

Actor

System Timer

Precondition

Basic Path

1. The timer triggers the system, to start the cycle of control

2. The system sends data requests to the physical units

3. The physical units respond to the system with the requiredinformation

4. The system processes the received information and checks ifthe water level is between N1 and N2

5. The system transmits messages back to the Valve Control andPump Control to adjust the water level

Alternative Paths

In step 3, if a communication failure happens, it puts the system inemergency mode and the use case "Handle Transmission Failure" isactivated

In step 3, if a malfunction in some Physical unit happens, but theWLMU works normally then the use case "Handle Physical Unitmalfunction" is activated

In step 3, if a malfunction happens to WLMU but the Physical Unitswork normally, the use case "Handle WLMU malfunction" is activated

Figure 10. Steam Boiler Use Case for Monitor andControl

4) Next, in order to move to the design phase, wetranslated every interaction diagram to anequivalent Function Block diagram. We madeseveral iterations through this process, untilcoming to a satisfactory level of detail.

5) Finally, all the Function Block diagrams aremerged together. The resulting function blockdiagram is shown in figure 11.We made hereall the proper connections and eliminated anyredundancy of Function Blocks among thediagrams.

: User

Steam Boiler Control

: Pump

: SLMU

: WLMU

: Valve

Systemsetup

Monitoringand Control

Handle emergencycondition

HandleWLMU

malfunction<<uses >>

<<uses >><<uses >> HandleCommunication

Failure

HandlePhysical unitmalfunction

Figure 11. The final Function Block diagram of theSteam boiler control application.

Conclusions

In order to enhance the requirements capturing, thesystem analysis and the transition to the designphase of IPMCSs, we have defined a new approachtowards a unified design architecture. Ourapproach adopts use cases and the UML notation tocapture requirements of the IPMCS applications. Ituses, the interaction diagrams for the firstrealization of use cases and a set of well-definedtransformation rules for the subsequent evolutionof requirements to Function Block Diagrams. Wehave presented the necessary workflows of ourincremental Object- Oriented approach that thecontrol engineer can follow in order to properlydesign the IPMCS system. Our set oftransformation rules copes with the transformationof Classes, Class Diagrams and InteractionDiagrams to equivalent Function Block types andFunction Block network diagrams.

We have found our approach very helpful in thedevelopment process of function block orienteddistributed IPMCSs. Our architecture promotes re-usability, obtains interoperability in the fieldbuslevel and favours automatic code generation. Weconstructed the whole approach having in mind thesystem properties of modularity, expandability,robustness, and flexibility. Our approach helped usto easily identify and capture requirements andtransform them into function block based designspecs.

We hope this work will help in the direction ofsimplifying the development process of distributed

IPMCS applications with IEC 61499-compliantsoftware tools and devices available from a wideselection of vendors.

Acknowledgments

We gratefully thank Peter Manesis for hiscontribution in the validation of the transformationrules.

References

[1] IEC Technical Committee TC65/WG6,“IEC61499 Industrial-Process Measurement andControl – Specification”, IEC Draft 2000

[2] IEC sub committee no. 65c: digitalcommunications, working group 7: function blocksfor process control, “IEC1804 GeneralRequirements”, IEC Draft 1999

[3] C.Cseh, M.Jansen, J.Jasperneite, “ATMnetworks for factory communication”, 7th IEEEInternational Conference on ETFA, 1999

[4] K.Thramboulidis, C.Tranoris , “AnArchitecture for the Development of FunctionBlock Oriented Engineering Support Systems”,IEEE International Symposium on CIRA July 29 -August 1, 2001, Banff, Alberta, Canada

[5] Ivar Jacobson et.al. “The Unified SoftwareDevelopment Process”, Addison, Wesley 2000Ch.2 p.26

[6] R. Lewis, Modelling control systems usingIEC 61499, IEE 2001

[7] Kruchten P.: “The 4+1 view model ofarchitecture”, IEEE Software, Nov. 1995

[8] OMG UML specification version 1.3,March 2000

[9] J.- R. Abrial, “Steam-boiler controlspecification problem”, August 10, 1994.,http://www.informatik.unikiel.de/~procos/dag9523

[10] K.Thramboulidis, C Tranoris, “A FunctionBlock Based Approach for the Development ofDistributed IPMCS Applications”, 10th ICAR2001, Aug.22-25, Budapest, Hungary

[11] “Function Block Development Kit”,Rockwell Automation, http://www.holobloc.com