FROM REQUIREMENTS TO FUNCTION BLOCK DIAGRAMS:
A NEW APPROACH FOR THE DESIGN OF INDUSTRIAL CONTROL
APPLICATIONS
C. Tranoris , K. Thramboulidis
Electrical & Computer Engineering Department
University 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 ability
to quickly respond to market requirements by
designing competitive products and modifying
existing ones. However most of the traditional
methods, products and tools are far away from the
new challenging technologies of Software
Engineering. Today’s systems are composed of
monolithic applications that are almost impossible
to integrate and even to expand. Modularity,
flexibility,
extensibility,
reusability
and
interoperability
are
dimensions
slightingly
addressed by the most traditional proprietary
methods and engineering tools. In this paper, we
describe our approach for the design of distributed
Industrial Process, Measurement and Control
Systems (IPMCSs). We adopt the use case driven
approach proposed by Ivar Jacobson and the UML
notation, to capture requirements. We have defined
a process for the transformation of requirements
expressed in the form of use cases, to IPMCSs
design specifications, expressed in the form of
Function Block diagrams. The whole process,
which is in the context of the CORFU framework,
is fully automated, so an Engineering Support
System can support it.
1 Introduction
Most of the Industrial Process Measurement and
Control Systems (IPMCSs) have until recently,
been based either on traditional distributed control
systems or on programmable logic controllers. In
both cases, the systems are composed of monolithic
applications that are almost impossible to integrate
and even to expand. Modularity, flexibility,
extensibility, reusability and interoperability are
dimensions slightingly addressed by many
traditional proprietary engineering tools and
products. Concepts like agile manufacturing and
interoperability between products, devices, utilities
and vendors are discouraged by proprietary
solutions. Even more, the most of the traditional
products and tools are far away from the new
challenging technologies of Software Engineering.
Competition as well as today’s rapidly changing
market requirements imposes the need of
improving the agility of manufacturing systems.
New challenging technologies of Software
Engineering must be considered to provide the
basis for the definition of new methodologies for
the design and development of the always-growing
complexity distributed IPMCSs.
Evolving standards, like IEC-61499 and the more
recent IEC-61804, contribute to this direction
[1][2]. They define the basic concepts for the
design of modular, re-usable, distributed industrial
process, measurement and control systems. The
function block construct is defined as the main
building block of IPMCS applications, in a format
that is independent of implementation. It is an
abstraction mechanism that allows industrial
algorithms to be encapsulated in a form that can be
readily understood and applied by industrial
engineers who are not specialists in the
implementation of complex algorithms. A function
block may be primitive i.e. small enough to provide
a solution to a small problem, such as the control
of a valve, or composite, that is an aggregation of
function blocks, i.e. big enough to control a major
unit of plant. Function blocks can be used to define
robust, re-usable software components that
constitute the distributed IPMCSs.
The above standards define also a methodology to
be used by system designers to construct
distributed control systems. It allows systems to be
defined in terms of logically connected function
blocks that run on different processing resources.
Complete applications, can be built from networks
of function blocks, formed by interconnecting their
inputs and outputs.
New generation, function block oriented,
Engineering Support Systems (ESS), are highly
required to support the whole life cycle of IPMCS
applications. Such an ESS must support the
engineer, in both the analysis and design phase as
well as in the implementation phase. Using such a
tool, the engineer must be able to start with the
analysis of the plant diagram so as to capture the
control requirements. Then, he should be able to
define the major areas of functionality and their
interaction with the plant. During this task, he
should be able to exploit function blocks provided
by intelligent field devices, such as smart valves,
but also to assign functionality into physical
resources such as PLCs, instruments and
controllers. All the above should be accomplished
independent of the underlying communication
subsystem and in the extreme case, where it is an
aggregation of interconnected independent fieldbus
segments, even from different vendors.
To address the above requirements we have
defined and have under development the CORFU
framework, that is a Common Object-oriented
Real-time Framework for the Unified (CORFU)
development of distributed IPMCS applications. In
the context of this paper we consider the analysis
phase, as well as the transition to the design one,
since these phases are slightly addresses by IEC
standards. We adopt the widely accepted use case
driven approach of Ivar Jacobson and the UML
notation to capture the requirements of the IPMCS
system. We then proceed to the evolution of these
requirements through a set of well-defined
transformation rules to produce the Function Block
design diagrams. The defined transformation rules
may lead to the automation of the transformation
phase by an Engineering Support System.
The rest of this paper is organized as follows. In
section 2 we briefly refer to the CORFU
framework. In section 3, we consider the current
status of the IPMCS’s development process and the
way this process is addressed by the IEC 61499
standard. Section 4, describes our approach for the
capturing of requirements with the UML notation
and their evolution to Function Block diagrams. In
section 5, we consider the steam boiler control as a
case study and we apply our approach, in the
design of Function Block diagrams. We finally
conclude the paper in the last section.
2 The CORFU framework
In order to meet the requirements imposed by
today’s distributed IPMCS systems, we have
defined the CORFU framework for the
development of distributed IPMCS applications.
Frameworks provide an important enabling
technology for reusing both the architecture and the
functionality of software components allowing the
IPMCS engineer to ignore all the complexities
inherent in field devices and fieldbuses and to
concentrate on the actual problem to be solved. The
proposed framework would assists process and
system engineers in the development and
configuration of distributed IPMCSs. The proposed
framework, which is shown in fig. 1, address:
1. the IPMCS engineering process, which utilizes
the engineering workspace-to-fieldbus channel
and
2. the IPMCS operational phase, which utilizes the
SCADAclient-to-fieldbus channel and the
fieldbus-to-fieldbus channel.
For the SCADA client-to-fieldbus channel, we
adopted Internet although its role as a channel over
which SCADA applications are built is a fairly
recent phenomenon. However Internet’s impact has
been substantially greater than that of other
proprietary channels in existence for several
decades. For the same reasons we adopted Internet
for the engineering workspace-to-fieldbus channel.
However, Internet in its current status is not
possible to be considered for the fieldbus-tofieldbus channel, where alternatives such as Fast
switched-Ethernet, Gigabit Ethernet and ATM may
be successfully adopted [3].
systems or on PLCs and have been developed with
proprietary tools. This results in systems that are
composed of monolithic applications, which are
almost impossible to integrate or even to expand.
The engineers in the industrial and control sector
have already comprehend the above issues. They
have sense the emerging needs of customers since
several years, and they constantly try to develop
standards, like the proposed IEC61499 standard
and the more recently proposed IEC1804.
Towards the smoothly implementation and
development of industrial applications mentioned
above, the IEC61499 Application Development
Guideline part, proposes an incremental and
iterative process, which assumes that an
Engineering Support System (ESS) should support
the whole engineering task. The core concept of
this process is the cycle Evaluate-Improve-Operate
that is repeated many times.
Figure 1. High-level view of the CORFU
framework.
The CORFU framework is a set of collaborating
classes that embody an abstract design capable to
provide solutions for the family of IPMCS’s
related problems. It will attempt to increase
reusability in both architecture and functionality by
addressing issues such as interoperability and
integrated development of distributed IPMCSs.
The main components of our framework are the
interworking unit and the virtual fieldbus. The
interworking unit will be the infrastructure for the
development of the interoperability mechanism,
while the virtual fieldbus would provide the APIs
required by the different communication channels.
To proceed with the design and development of an
ESS that is required to support the design,
implementation, commissioning and operation of
IPMCSs we have defined the 4-layer Architecture
presented in [4].
3. Current status in the design of
IPMCSs
Until recently, most of the IPMCSs have been
based either on traditional distributed control
We present in figure 2 the whole process in pieces
called workflows. Each workflow is given in the
“fish” notation and includes the workers that
participate in the activity as well as the artifacts
that are defined as deliverables of the
corresponding activity [5]. For example the
“Evaluate” workflow includes the workers that
participate in the system’s evaluation activity and
the artifacts that they must produce. The
assessment of the system performance versus
business objectives, is one of the tasks to be
performed during this workflow, in order to
identify requirements for system improvement.
However, the standard does not define a way to
capture these requirements as well as the initial
system’s requirements. It only suggests that they
may be expressed textually or in a diagram format.
Further each workflow may be specified in more
details by a number of sub-workflows. The
“Improve” workflow, for example, consists of the
following sub-workflows: Documentation, Design,
Validation, Installation and Testing as is shown in
fig. 2. Each sub-workflow includes a number of
activities that the corresponding workers must
carry out. The engineer may produce any
documentation during the Improve workflow.
During the “Operate” workflow the IPMCS will go
in operation and is usually preceded by installing
an operational configuration.
Figure 2. The “fish” notation for the development
process of IPMCSs.
Lewis in his latest book[6], accepts that IPMCSs
like most complex software designs require at least
four different design views and a set of scenarios,
as it is described by the 4+1 View Model
Architecture of P. Kruchten [7]. Although
Kruchten has considered applying these design
views to object oriented systems, the same views
are also applicable to IPMCSs. Lewis, although
accepts that IEC61499 represents an important step
towards a unified design architecture, states that it
only provides just one of the five design views
required for distributed control applications.
Capture
Requirements
Capture
Behavior
4. Our approach
In the context of our unified design architecture
and in order to enhance the requirements capturing,
the system analysis and the transition to the design
phase we have adopted the well-established UML
notation to proceed to Function Block based
designs for the development of distributed
IPMCSs. This approach will eliminate the
discontinuity between traditional development and
modern design methodologies, as well as certain
unspecific and underdeveloped parts of the
proposed 61499 standard in the direction of a
specific methodology. It would try to clarify in
more detail the IMPCS’s development process.
Figure 3 presents the steps of our incremental
approach. The process starts with the workflow of
capturing the requirements of the system by means
of the well-known Use Case concept. During this
workflow, end-users of the IPMCS, system
analysts, software architects, control and field
engineers participate in order to properly define the
system, its architecture, and the way it should
behave with external events, devices and humans.
If the system already exists and needs to be
expanded, a re-engineering phase should also take
place and certain old parts should be considered for
re-using, re-implementing or interfacing with new
ones.
We suggest using Use Cases and Use Case
diagrams
for
requirement
capture
and
documentation, not only for their wide acceptance
and applicability, but because they are also part of
the UML notation. Additionally, there is a lot of
Capture
System Static View
Design Function
Block Diagram
Clarify through iterations
Analysis
Figure 3. Overview of our approach
Design
Proposed
Transformation
Rules
bibliography that undertakes Use Cases and certain
templates have been introduced for their writing.
Formally, the use case construct is used to define
the behavior of a system or other semantic entity
without revealing the entity’s internal structure.
Each use case specifies a sequence of actions,
including any variants that the entity can perform
interacting with its actors [8]. As an example, we
give in Figure 4 the System startup use case, that
we have written during the requirements capture
workflow of the Steam Boiler control application,
which we have considered as a case study for our
approach [9].
The next workflow i.e. the Capture Behavior, in
which system analysts participate, copes with the
examination of the dynamic behavior of the
system. This is done by means of Interaction
Diagrams, which is a notation for describing
behavior in UML. The Interaction or Sequence
Diagrams are considered as the first realization of
use cases. They present an Interaction, which is a
set of message exchanges between Classifiers i.e.
objects and classes participating in a Collaboration
to effect a desired operation or result. An
interaction specifies the communication between
instances performing a specific task. Each
interaction is defined in the context of the specific
collaboration.
A sequence diagram has two dimensions:
interaction diagram of Figure 6, which shows the
system’s internal objects and the way they
collaborate to provide the required behavior.
Among the system’s objects we discriminate the
interface-objects that are the interfaces of the
system to the external real world devices.
Use Case System Startup
General
This use case describes the actions performed by the system
during start-up and initialization phase.
Actor
Steam Boiler User
Precondition
The steam boiler is stopped and the system is in the Initialization
mode.
Basic Path
1.
The user presses the start button and the system sends a
message to all external physical units to check if they are
ready to start.
2.
The physical units send a message back to the system, that
they are ready to start operating.
3.
As soon as this message has been received the program
send a message to the Steam Level MU to check back
whether the quantity of steam coming out of the steam-boiler
is really zero.
4.
The system send a message to the WLMU and checks the
level of the water. If is between the limits, the system will
send continuously a signal to the physical units until it
receives a confirmation signal which must necessarily be
emitted by the physical units.
5.
As soon as the confirmation signal has been received, the
system continues to operate correctly and to control the
water level.
1. the vertical dimension, which represents time
Alternative Paths
2. the horizontal dimension, which
different objects
represents
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 the
emergency stop mode.
Normally time proceeds down. Usually only time
sequences are important. However in real-time
applications the time axis could be an actual
metric. There is no significance to the horizontal
ordering of the objects. The different kinds of
arrows used in sequence diagrams are explained in
detail in [8].
In step 3, if the quantity of water in the steam-boiler is above N 2
the program activates the valve of the steam-boiler in order to
empty it. If the quantity of water in the steam-boiler is below N 1
then the program activates a pump to fill the steam-boiler. If the
program realizes a failure of the water level detection unit it enters
the emergency stop mode.
During the first iteration, the analyst of the IPMCS
system under study can draw the collaboration
between the system and the actors of the system.
This can be drawn by means of Jacobson's
stereotypes as is shown in Figure 5. As a next step,
a refinement of the above diagram will give the
In step 4, if any physical unit is defective the system enters the
degraded mode.
In step 4, if a transmission failure happens, it puts the system into
the 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.
1: Press Start
: User
Expire :
Timer
StartButton : SteamBoilerUI
2: start
7: ready
3: Ready?
11: check
12: steam_ok
4: Ready?
6: Ready?
5: Ready?
10: ready
: PumpControl
: Initialize
: SLMU
13: check
9: ready
14: Level_Ok
8: ready
: ValveControl
: WLMU
Figure 5. Collaboration diagram for the system
startup Use Case
Initialize
Control
WLMU
WaterLeve
l Checker
SLMU
Pump
Control
: User
Start()
Start()
SBW()
Valve
Control
The next workflow i.e. the Capture System static
view is the one that deals with the design of the
static view of the system in terms of class
diagrams. Since this workflow must be in
harmonization with the Capture Behavior
workflow, the analysts must to go back and forth
in order to better specify the underlying system.
Figure 7 shows a part of the Class Diagram of
the Steam boiler control system. The diagram
shows the problem domain classes and their
dependencies. The engineer can use these
dependencies in order to extract information on
how the Function Blocks will be connected. Also
any aggregate or composite class should be
displayed on this diagram. During the design of
this diagram the analyst should have in mind that:
1. Every class is stereotyped as <<leaf>> because
FBs cannot have descendants
2. The associations in the class diagram should be
always dependencies.
PeriodTimer
ExpireTimer
SBControler
WaterLev elMU
SBW()
SBW()
SteamLev elMU
SBW()
PumpControl
Valv eControl
level(q)
CheckWaterLevel()
[q<N1] Open()
[q>N2] Open()
[N1<q<N2] WL_OK()
PUR()
PUR
()
PUR
PUR
()
PUR
PIDControler
()
PUR
()
()
EstimateLev el
PUR
Superv ision
WaterLev elChecker
()
PUR
Figure 7. Part of Steam Boiler Class diagram
4.1 Moving into Design
Figure 6. Detailed Interaction Diagram for the
system startup Use Case
As soon as the requirements model is defined and
the problem domain model in terms of class
diagrams is completed, we are ready to move into
the design phase. Our intention is to produce
designs in terms of Function Block diagrams that
are better understood by the control and field
engineers of the system.
In this phase the participation of control and field
engineers that would apply their expertise in the
proper and better design of the system is
mandatory. The proposed process is incrementally
applied and requires from the engineers to proceed
iteratively, going back and forth around the
suggested workflows, in order to clarify the
necessary artifacts for the design of the application.
1) Every class should be mapped to a Function
Block type. In detail:
In order to properly design the Function Block
diagram of the underlying system, we have
captured a set of Transformation Rules that could
be applied to smoothly pass from the analysis
model to the design one. These rules cope with the
transformation of Class Diagrams and Interaction
Diagrams to equivalent Function Block network
diagrams.
c. Public data members should be the data
input and data output variable names of
the function block type.
For the transformation of each Interaction Diagram
to the equivalent Function Block Diagram, the
following rules, have been defined:
1) Every Object participating in the Interaction
diagram should be mapped in a Function
Block. If the Object interacts with an
external object of the system, then an extra
Service Interface Function Block is added
to the function block diagram.
2) Every Object Interaction between two
objects will be mapped to an event
connection between the corresponding
function blocks.
3) The message parameters of the object
interaction will be the WITH data
parameters of the Function Block and they
will be mapped to data connections.
4) If a message has more than one recipient,
the Function Block Splitter should be
inserted. An example of such a message is
the message PUR() in figure 6.
5) When two or more events should be meet
together to proceed further the process, the
Event Rendezvous Function Block should
be used. An example of such a message is
the message SBW() in figure 6.
The following rules should be applied in order to
extract information from the class diagram and
insert it to the Function Block Diagram:
a. The class name should be the Function
Block type name.
b. Private data members should be mapped
to Internal data of the Function Block
type.
d. Public methods should be mapped to FB
events. Method parameters should be the
WITH data, except from methods that
read/write (get/set) internal variables.
e. Methods should not have a return value.
2) Every dependency of the class diagram
should be mapped to a FB connection and
must be further clarified to an event or a
data connection.
3) A further study and refinement of the class
diagram should reveal the aggregatecomposite objects that will be mapped to
Composite Function Blocks. Every
aggregate class composed of classes
running on the same resource, should be
mapped to a Composite FB type.
4) Every aggregate class composed of classes
running on different resources should be of
type Sub-application FB.
5) The class's state-chart diagram is actually
the Execution Control Chart (ECC) of the
corresponding Function Block type.
Following the above rules, the transformation is
straightforward. The process can be fully
automated by an ESS tool with CASE capabilities
and we are currently working on this direction by
developing a prototype tool.
Since we have not implemented yet the tool to
automate the above process we used the Function
Block Development Kit[11] to produce the
Function Block diagrams. Figure 8, shows the
Function Block Diagram that corresponds to the
System Startup Use Case. We can notice the Event
Splitter E_SPLIT and Event Rendezvous E_REND
Function Blocks, which are used where there is a
need for messaging more recipients and meeting
together certain events.
Figure 8. Function Block Diagram implementing
System Startup
5. The Steam Boiler Control Case Study
The steam-boiler control specification problem has
been proposed for testing the various design
formalisms with respect to their versatility and
applicability to embedded control system design.
An informal specification of the original problem is
presented in detail in [9]. The specification
concerns a control application that serves to control
the level of water within some safe range in a
steam boiler. The physical environment comprises
the following units:
•
the steam boiler: A water tank of total capacity
C in litters, which generates steam.
•
a water sensor: A device to measure the
quantity q in litters of water in the steam boiler
•
four pumps to provide the steam boiler with
water. Each pump has its capacity P in
litters/sec.
•
four devices to supervise the pumps (one
controller for each pump)
•
a steam sensor: A device to measure the
quantity õ in litters/sec of steam which comes
out of the steam boiler.
There are two normal water quantity bounds N1
and N2 in litters, within which the water quantity
should be maintained during regular operation. The
plant provides the control application with
information from various physical units and
sensors, while the control application controls the
plant based on the messages received from the
plant. The control application communicates with
the physical units i.e. the plant and the controllers
through messages transmitted via communication
channels. The time for the transmission can be
neglected. The control application follows a cycle
and a priori does not terminate. A sampling event
occurs every five seconds. When it happens, the
control application first receives messages coming
from the physical units. Then the control
application analyses the information, which have
been received and calculates the suitable pump
control value p. Finally the calculated control value
p is transmitted to the physical pump by the
controller. The water quantity q, the steam output
õ and the throughput of the pump p are continuous
functions of time. The control application uses the
corresponding sampling data.
We also assume that all messages coming from
or going to the physical units are supposed to be
received or emitted simultaneously by the program
at each cycle and there is no communication failure
during system operation.
There are two dangerous bounds for the water
quantity in the boiler: The minimum limit quantity
M1 and the maximum limit quantity M2. Below
M1 the steam boiler would be in danger after five
seconds, if the steam continued to come out at its
maximum quantity without supply of water from
the pumps. Above M2 the steam boiler would be in
danger after five seconds, if the pumps continue to
supply the steam boiler with water without
possibility to evacuate the steam
We have included in our problem the requirement
of wide distribution of the devices of the Steam
Boiler. A solution to this problem is presented in
more detail in [10]. We applied our suggested
process in the problem and we made the following
steps:
1) We first expressed the requirements of the
system by means of Use Cases. We extracted
all the requirements from [9] and we defined,
the actors of the system and the Use Cases that
the system should carry out. A few examples of
use cases are: the System set-up use case,
Monitor and Control use case and handling
transmission- failure use case, as shown in
Figure 9. We next proceed to the detail
description of each use case. Figure 10 shows
the description of the Monitor and Control Use
Case.
Steam Boiler Control
System
setup
: User
3) In parallel with the interaction diagram, we
draw 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 during
normal 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 required
information
4.
The system processes the received information and checks if
the water level is between N1 and N2
5.
The system transmits messages back to the Valve Control and
Pump Control to adjust the water level
: Pump
Monitoring
and Control
<<uses >>
Handle
WLMU
malfunction
<<uses >>
Alternative Paths
Handle
Communication
Failure
: SLMU
<<uses >>
Handle
Physical unit
malfunction
: WLMU
In step 3, if a communication failure happens, it puts the system in
emergency mode and the use case "Handle Transmission Failure" is
activated
In step 3, if a malfunction in some Physical unit happens, but the
WLMU works normally then the use case "Handle Physical Unit
malfunction" is activated
In step 3, if a malfunction happens to WLMU but the Physical Units
work normally, the use case "Handle WLMU malfunction" is activated
Handle emergency
condition
: Valve
Figure 9. Use case diagram of the Steam Boiler
Control
2) The next step was for every Use Case to
analyse the messages that the system exchanges
with external devices and humans. This was
accomplished with a simple collaboration
diagram such as the one shown in Figure 5.
With a further clarification, we identified the
system’s internal objects that should interact to
produce the required behaviour and we draw a
more detailed interaction diagram like the one
shown in Figure 6.
Figure 10. Steam Boiler Use Case for Monitor and
Control
4) Next, in order to move to the design phase, we
translated every interaction diagram to an
equivalent Function Block diagram. We made
several iterations through this process, until
coming to a satisfactory level of detail.
5) Finally, all the Function Block diagrams are
merged together. The resulting function block
diagram is shown in figure 11.We made here
all the proper connections and eliminated any
redundancy of Function Blocks among the
diagrams.
IPMCS applications with IEC 61499-compliant
software tools and devices available from a wide
selection of vendors.
Acknowledgments
We gratefully thank Peter Manesis for his
contribution in the validation of the transformation
rules.
References
Figure 11. The final Function Block diagram of the
Steam boiler control application.
Conclusions
In order to enhance the requirements capturing, the
system analysis and the transition to the design
phase of IPMCSs, we have defined a new approach
towards a unified design architecture. Our
approach adopts use cases and the UML notation to
capture requirements of the IPMCS applications. It
uses, the interaction diagrams for the first
realization of use cases and a set of well-defined
transformation rules for the subsequent evolution
of requirements to Function Block Diagrams. We
have presented the necessary workflows of our
incremental Object- Oriented approach that the
control engineer can follow in order to properly
design the IPMCS system. Our set of
transformation rules copes with the transformation
of Classes, Class Diagrams and Interaction
Diagrams to equivalent Function Block types and
Function Block network diagrams.
[1]
IEC Technical Committee TC65/WG6,
“IEC61499 Industrial-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 for factory communication”, 7th IEEE
International Conference on ETFA, 1999
[4]
K.Thramboulidis, C.Tranoris , “An
Architecture for the Development of Function
Block Oriented Engineering Support Systems”,
IEEE International Symposium on CIRA July 29 August 1, 2001, Banff, Alberta, Canada
[5] Ivar Jacobson et.al. “The Unified Software
Development Process”, 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”, IEEE Software, Nov. 1995
We have found our approach very helpful in the
development process of function block oriented
distributed IPMCSs. Our architecture promotes reusability, obtains interoperability in the fieldbus
level and favours automatic code generation. We
constructed the whole approach having in mind the
system properties of modularity, expandability,
robustness, and flexibility. Our approach helped us
to easily identify and capture requirements and
transform them into function block based design
specs.
[10] K.Thramboulidis, C Tranoris, “A Function
Block Based Approach for the Development of
Distributed IPMCS Applications”, 10th ICAR
2001, Aug.22-25, Budapest, Hungary
We hope this work will help in the direction of
simplifying the development process of distributed
[11] “Function Block Development Kit”,
Rockwell Automation, http://www.holobloc.com
[8]
OMG UML specification
March 2000
version 1.3,
[9]
J.- R. Abrial, “Steam-boiler control
specification problem”,
August 10, 1994.,
http://www.informatik.unikiel.de/~procos/dag9523