Complete applications, can be built from networks of function ... analysis of the plant diagram so as to capture the ..... draw the problem domain class diagram,.
Proceedings of the 10th Mediterranean Conference on Control and Automation - MED2002 Lisbon, Portugal, July 9-12, 2002.
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 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() [qN2] Open()
[N1
