Technical Application of Hybrid Modeling Methods

Technical Application of Hybrid Modeling Methods to specify Function Block Systems Udo Enste, Ulrich Epple

Dipl.-Ing. Udo Enste Ph.D. student at the Chair of Process Control Engineering, RWTH Aachen and managing director of the LeiKon GmbH. research topics: function block technology, process control concepts adress: LeiKon GmbH, c/o Chair of Process Control Engineering, RWTH Aachen, Turmstr. 46, 52072 Aachen, Germany. e-mail: [email protected]

2

Prof. Dr.-Ing. Ulrich Epple Head of the Chair of Process Control Engineering, RWTH Aachen adress: Chair of Process Control Engineering, RWTH Aachen, Turmstr. 46, 52064 Aachen, Germany. e-mail: [email protected]

In spite of large improvements of formal modeling methods, their technical application in industrial process control implementations is still rare. Two reasons can be pointed out. First, there is still a gap between the formal modeling languages and the control languages used in industrial process control systems respectively specified in normative standards. Second, the focus of the modeling aspects is mostly on the control algorithms itself. Looking at industrial applications, these pure control algorithms yield often just 10 % or less of the behaviour and the signal flows of a control unit. All other aspects like synchronisiation or occupying mechanisms are usually unconsidered. As a consequence of these arguments, first a new framework was developed for specifying modular function block applications in a comprehensive and formal way. Second, a generic template for batch-oriented process control blocks was designed, which takes all aspects of operational handlings into account. Both models – the framework and the template – are described using graphgrammars and hybrid modeling methods. The whole approach appears usefull for normative commitees and for large vendors of process control systems who have to develop function block applications or maintain and merge big function block libraries.

at – Automatisierungstechnik 48 (2000) 0 c R. Oldenbourg Verlag

1 Introduction Complex control applications are realized with decentralized process control systems. The software inside these systems is based on a modular, object-based concept, the so called ’function block technology’. Function block models are discussed in several normative standards /1/, /2/, /3/, /4/, /5/. A function block is a software unit, describing a method and its data structure. Depending on the necessity of the data exchange between several function blocks, state variables of a block are distinguished into input data, output data and hidden state variables. Beside the principle of encapsulation, a single-level class concept is characteristic for the function block technology. The algorithm and the data structure are fixed in a ’function block type’. Using these function block types, control structures can be realized by a net of self-sufficiently, asynchronously and quasicontinuously working function blocks instances. These instances process their own data sets and a reference to their corresponding function block type. The function block technology provides an intuitive way to configure and modify process control architectures online. Depending on the dynamic characteristic of the function block types and the types of signals exchanged between the blocks purely discrete, quasi-continuous, as well as hybrid control nets can be realized.

PID-algorithm

Figure 1: Customary function block type (PID-Controller, Siemens)

1

Looking in detail at the algorithms of complex function blocks which are used in process control applications, the functionblocks themselves can be identified as hybrid systems as well. To illustrate the complexity of blocks used in industrial applications, figure 1 shows an example of a ’simple’ PID-controller used in industrial systems. No internal structure is identifiable and thus a systematic analysis is impossible. Although the function block technology is the most important way to specify process control structures no formal description is known. Beyond this, verifying the correctness of the function block type specifications often fail due to the complexity and variety of the focused functionalities. Therefore, two evolutions in process control engineering – the function block technology and the theory of formal languages – have to be merged in order to benefit from the mathematical possibilities of formal modeling methods when developing and analyzing industrial applications. One way to reduce the current gap between these evolutions is to take the normative standards or the specifications of the vendors and to try to transform these specifications directly into formal descriptions. This way is often difficult, because a lot of presumptions and interpretations must be done when transforming the specifications into well-defined formal models. In addition, often not all features can be transformed. As a result, acceptance of these generic formal descriptions is often lower than anticipated. In this approach a new formal function block modeling language is developed, which specifies modular functionblock applications in a comprehensive way. In addition to the aspects of the normative standards, this language includes more generic and more granular language elements to shrink the complexity of function block algorithms (see Fig. 2).

state of the art

the motivation to specify more granular elements in a function block model is based on two cognitions. First, the application engineer normally has to follow either normative or company-specific rules to design function block types. These rules are defined in textual or semiformal specifications. Up to now, there are no other modeling elements available for the application engineer to do the transformation from the textual specification to software code in an efficient, granular and analysable manner. The second cognition is the result of an analysis of several higher sophisticated function block types in industrial process control systems. The analysis showed that a lot of functionalities inside a specific class of function blocks (blocks used for process control, blocks used for simulation,...) are encapsulatable and re-usable in a generic way. Therefore, so-called ’internal components’ and the idea of templates were introduced to the function block language. Well-structured templates shall improve the engineering activities to design function block applications. Using components, specific function block templates can be developed, which offer a specific structure and unified functionalities inside the function blocks of a specific class (see Fig. 3). In consequence, the singellevel class concept (types and instances) can be replaced by a multi-level class concept, where function block types can be derived from templates. Because of the multiplication effect when using templates and multiused components, it is useful to specify the dynamic of the encapsulated functionalities inside these templates by hybrid modeling methods.

function block components

base for

base for

base for

function block templates

function block types

function block instances

aspired modular and formal specified structure

complex hybrid function block

formal function block language

Figure 3: Concept of developping process control applications

Figure 2: Aim of the research activities

2 The function block language ’FBComposed’ Before specifying the dynamics of function blocks in a formal way, it is worthwhile to describe the internal structures of function block types by more granular elements. From an application engineer’s point of view,

2

To establish a non-ambiguous basis for checking the consistency of the developed architecture and for building prototypes, the extended function block language ’FBComposed’ /6/ was specified. The language describes function block models composed of smaller parts. Each internal component has a well-defined boundary called ’capsule’ which encapsulates the component’s implementation from its environment (see Fig. 4). Thus, the capsule can be considered as a black box view of the component. Components communicate by signals, which are exchanged along explicitly modelled connections between ports. Ports belong to the capsule of a component and mediate access to the component.

No direct manipulation of the state of a component is possible, except by communication via connections across ports. In addition, the function block model offers a hierarchical composition of components. The implementation of a component is described by composing and connecting capsules as black box views of subcomponents. The results of this intermediate component construction step are called templates. A template can be instantiated forming a component by substituting a component for each of its capsules. This mechanism can be explained by comparing the capsule with a socket where a component can be plugged in. A template is like a printed circuit board. Plugging components into all the sockets results in a new component, which can be used thenceforth. xi

a) capsule

signaltyp e

xo

c

b

xi

xi xo

xo

r

b) template

valuetype boolean float float

a

graph and vice versa. All graph manipulations are done by graph rewriting rules that are chosen to retain consistency in the framework. Additional constraints expressed by graph patterns including attribute conditions are used to point out forbidden and desired properties of the framework. These redundant constraints are also used to check the consistency of the meta model itself. The development and modification of process control applications should be supported by a software tool that ensures compliance with the specification by following graph rewriting rules. A prototype of such a tool (FBComposed engine) has been generated directly from the graph grammar specification (see Fig. 5). This tool can be used to specify several function block models. Using this tool, a formal description of such a model is guaranteed. The language also includes consistency checks of requirements, that each function block model must fulfill. With these features the language and the tool are predestinated for normative commitees and for large vendors of process control systems who need to maintain and merge their systems.

s

a

c

b

metametamodel

graph rewriting system

PROGRES environment

instance of

metamodel

xi xo

A

r

B

function block language

C

s

FBComposed engine

instance of

c) component xi

basemodel xi r

A

xo

xo s

a

instance of

C

application specific tools

instance of

c

b

typespecific model xi

d) function block type

generic function block model, design patterns

a b

xo method (transient variable: r r:=a trigger comp. A ...)

function block types

Figure 5: Modeling levels and dedicated tools

c

internal dataset (persistent variable: s)

Figure 4: Metamodel of the component based function blocks

The language FBComposed with well-defined static semantics is defined by means of the graph rewriting system PROGRES (PROgrammed GRAph REwriting System) /7/. Graph grammars describe graph languages in a way similar to the way textual languages are formalized by string grammars. The graph grammar specification includes the object model and the production rules needed to engineer a function block system. To guarantee a link to the dynamic modeling aspects, language elements of hybrid modeling methods were considered in the metamodel of the function block specification. The elements of the language FBComposed are mapped to nodes and edges of an attributed directed

At all, the language FBComposed includes many features of the normative function block languages and is similar to the object oriented modeling language for realtime systems ROOM /8/. A short overview of additional features and differences shows figure 6.

3 Favoured elements specifying the behaviour in a formal way To have more granular elements to specify complex function blocks is an essential feature to model the dynamics of function blocks in an efficient way. Furthermore the possibility to specify blocks in a generic manner using templates makes the formal specification process worthwhile. The function block model specification introduced in section 2 offers the basic architecture and the basic production rules to define what the function block concept

3

FBComposed

ROOM/ UML-RT

IEC 61499

IEC 61131-3

hierarchical decomposition

yes

yes

( yes )

no

generic modeling

yes

yes

( yes )

no

’template’ a language element

yes

no

no

no

signal oriented communication

yes

yes

yes

yes

message oriented communication

yes

no

no

no

event triggered activation

yes

yes

yes

no

cyclic activation

yes

no

yes

yes

discrete specification of behaviour possible

yes

yes

yes

yes

continuous specification of behaviour possible

yes

no

no

yes

hybrid specification of behaviour possible

yes

no

no

no

online modification of block behaviour possible

no

yes

no

no

formal metamodel

yes

(yes)

no

no

Use in process control systems

yes

no

yes

yes

code generator available

yes

yes

no

yes

Figure 6: Features of different function block languages

is in general. These specifications don’t include any dynamic aspects. It makes no sense to consider the behavioural aspects before defining the required functionality the block or a class of blocks have to perform.

generic and application independent function block model

4 Types of signals and nets

domain specific classification

domain specific templates - typical internal structure - typical interfaces - typical sequential structures - typical nets

function blocks for process control

function blocks for communication

function blocks for simulation

...

function block types

Figure 7: Domain specific classification of function block templates

Therefore, the next step is to investigate how to use templates in an adequate manner. Looking to function block applications, several classes of function blocks can be categorized (see Fig. 7). The classification results in groups of function block types which agree in similar interfaces, internal structures, related functionalities and in typical dynamic behaviours. These characteristic features can be implemented by developing a template for all function blocks of this group. Exactly these templates

4

are reasonable objects to apply the formal dynamic modeling methods to. The effort of a formal specification is justifiable because of the generic and re-usable software level. Each template shows a modular architecture. The modules (realized by ’components’) can be classified regarding their dynamic characteristics (discrete, continuous, hybrid) and their degree of unification (typespecific, generic, unified). To guarantee a practicable engineering process and an analyzable functionality it is important for the success of the dedicated dynamic validation to maximize the unified and generic components. Based on this classification suitable modeling methods to specify the defined components and templates can be applied. In the past, several approaches of hybrid modeling methods were introduced (e.g. /9/, /10/, /11/, /12/, /13/, /14/, /15/). From this huge amount of possible modeling methods, the condition/event systems (c/esystems) introduced by /12/ and the hybrid automata introduced by /11/ were chosen to describe specific aspects of standardizable components and their interaction inside a function block. Because of its modular concept, the modeling method of c/e-systems was preferred. On the one hand a specification of function blocks using more granular elements separating specific functionalities inside a block is possible. On the other hand, more generic function block specifications can be developed using the idea of templates. Because of the separation of encapsulated components inside a block one effect is that purely discrete components can be pulled out and analyzed using well known discrete modeling methods. The hybrid part shrinks to an analyzable subsystem inside a block. Considering these aspects in an engineering phase seems very important, instead of taking a complex function block design and trying to translate it into a formal language. Thus, a reduction of complexity can be performed while engineering a function block.

Before looking inside a function block, its interfaces must be classified. Following the suggestion of the IEC 61499 /1/ FBComposed distinguishes between the control flow and the data flow, which can be used to build a function block network (see Fig. 8). Normally, the control signals change their signal values in discrete timespans and show signal values which will be found in a digital and finite set of values. Contrary to that, the data flow signals normally have a continuous characteristic and show an analog range of values. According to the specifications of the c/e-systems the function block model devides the control flow in event signals and condition signals, including the semantic introduced in /16/ and /17/. Beside these two kinds of control flows, a new one is specified to represent a flow of messages in an adequate manner. A specific message used in process control applications is the so-called ’instruction’. This telegram includes the sender of the instruction, the type of instruction and optionally designates a parameter value (e.g.: a new set-point). To include this kind of information flow in a formal language, the telegram was mapped

to an encapsulated set of control and data flows. The validity of the values of the included signals changes synchronously in discrete timespans.

instruction (service invocation)

discrete

continuous/ quasi-continuous

control flow

control flow

data flow

data flow

instruction value range :

instruction SI

SI

digital (finite)

CT CV

=

CT SI: CT: CV: ncr:

ncr

sender ID command type command value new command received

digital (finite)

CV

analog

ncr

binary

to another node (step). From a modelling point of view, this feature requires an extension of the discrete and hybrid modeling languages. In all known languages the state information are global data, which are modified in different steps. In contrast to that, the non-ambiguous transformation of discrete models into function block nets requires additional language elements which describe transfer modes of state information. This important aspect needs to be adressed in the next future. In industrial control applications hybrid control nets are common. In this case, the function blocks are connected by both control and data flows. Figure 9c shows a typical hybrid control architecture. The control of a quasi-continuous subnet switches in discrete steps. The whole structure of the net is modified by switching the signal connections between the continuous subnet and the discrete subnet.

Figure 8: Types of signals

5 Hybrid model of batch-oriented process control blocks

Considering these types of information flows, discrete, quasi-continuous as well as hybrid control nets can be realized (see also /18/).

In the following we will present a typical hybrid template as an example for batch oriented function blocks for process control. The design is based on a hierarchical process control model introduced in /19/. In this process control model, several control units interact sufficiently and asynchronously in order to generate control values. The control architecture is organized hierarchically (see Fig. 10). Superior control units send control instructions to inferior control units. This kind of forward driven information exchange can be realized by standardized telegrams /20/. The handling of such control instructions, in particular the checking mechanisms to verify incoming instructions (syntactical and semantical checks) is a typical functionality which is worth to standardize by developing a generic component. This component considers also access rights of operators vs. automatic units.

a) Continuous Control Net (just using data signals)

b) Discrete Control Net (just using control signals) Step1

w

AI_1

PID_1

AO_1 Step 3

Step 2 y

x

Step 4

c) Hybrid Control Net (using data and control signals) Step 1

Step 2

Step 3

Step 1

Step 2

Step 3

discrete control subnet

transformation into a function block network quasi-continuous control subnet

Figure 9: Continuous, discrete and hybrid function block nets (see also /18/) control instructions actual values

To implement simple continuous control structures function blocks with continuous characteristics are exclusively connected by data flows (see Fig. 9a). In contrast to this concept, discrete control structures can be realized by connecting function blocks only by discrete control flows (see Fig. 9b). In this case each block represents a state of an automata. In addition to ordinary discrete control nets, it is possible and necessary in most cases to transmit state information from one node (step)

control function control values

design of a standardized template for hybrid process control function blocks

Figure 10: Hierarchical process control model and its transformation into a function block network

5

transaction control unit instruction input interface

typespecific signals

typespecific component of the state machine . . .

standardized signals generic component of the state machine

solidified state information

(mapping of signals)

control head function body

typespecific process control logic

typespecific process control logic

typespecific process control logic

unified or generic components

control head

function body

step 1

step 2

step 3

step 4

step

steady phase

transaction control unit

starting process

control logic

stopping process

5.1 The template The internal structure of this template can be outlined as follows (see Fig. 11 and /21/): the transaction control unit is the interface to the tasking of the function block system. Activating this module means starting the algorithm of this function block. The transaction control represents a centralized control module inside a function block. It coordinates the control flow between all components inside the block. The checking mechanisms and verification of the acceptance of incoming control instructions are treated by a checking unit. Based on its result and on information about the operating conditions fed in by typespecific signals, a generic state machine will be activated. The link between the typespecific signals and the generic state machine is handled by a typespecific component (specified inside the template as a capsule), where the typespecific signals must be mapped to the standardized signals of the generic component with predetermined semantics. The signals may prohibit the execution of an incoming instruction. The state vector of the generic state machine causes at least the activation of one of several capsulated process control logics inside the function body.

step 1

step 2

entry:

valve_2: pump_1:

’open’ ’on’

do:

heating_H17:

y = f(t)

exit:

pump_1:

’off’

step 1

step 2

step 3

Figure 12: Internal structure of the function body including hybrid sequential function charts

languages. Without going into detail, two components are presented as examples. First the ’instruction input interface’ and second the ’transaction control unit’, both modeled by c/e-systems. All the generic or unified components show mainly a discrete dynamic. Except time conditions must be considered. Therefore, clocks were used, which were introduced in /23/. A more complex hybrid structure will occur when the typespecific components must be integrated. 5.2 The Instruction Input Interface The ’instruction input interface’ represents a typical generic hybrid component. Regarding figure 13, the upper part of the component is specified in a unified manner and the lower part represents the generic functionality which can be extended by a number of states ’start x’ which represent each a specific control logic inside the function body.

typespecific components (capsules)

instruction input interface activate

Figure 11: Template for batch-oriented process control units

Occupier

sender ID

automatic

requested

automatic (locked)

command type occupier

Time-control

To specify the process control logic, an underlying structure is proposed. A control logic has to be implemented into one of three hybrid function charts (see Fig. 12). These hybrid function charts respectively represent the starting, the steady and the take-off phase of a function unit. The hybrid feature of the function body is established by the specification of the steps inside the function charts. Each step is separated into three sections: the ’entry’, ’do’ and ’exit’ operations (similar to /22/). From the hybrid modeling point of view it is important to distinguish between the control actions (specified as ’entry’ and ’exit’ operations) and the control activities (specified as ’do’ operations). Actions are switching procedures with negligible time requirements, whereas activities are continuous operations. All unified or generic components of the template and their interaction were specified using hybrid modeling

6

local

T>=T_Occu

new command received

manual free Semantical Check of Command Type (feasibility check) take out of operation

start_2

valid command

reset stop take into operation

switch of control logic

start_1

Figure 13: The instruction input interface

The unified part includes a standardized occupying mechanism and a time-based supervisory mechanism. The occupying mechanism garuantees that in one control phase just one superior unit (operator, a specific automatic unit or a local operator in the field) is allowed to

send instructions to this control unit. Thus the ID of the sender of an instruction must match the actual occupying state, except the state is ’free’. Because the control units can be used in distributed control systems, a clock supervises the timespan between incoming instructions. The aim is to detect failures in communication. Therefore, each superior control unit which has occupied an inferior unit, has to send at least occupying instructions periodically to prove its existence. Finally, a semantical check of the incoming instruction has to be modelled. Therefore each instruction input interface includes a generic state diagram, which contains possible instruction types and possible sequences of instructions. At all, this component signals the actual occupier, the actual valid instruction and an event which normally initiates a switch of the controllers functionality.

6 An industrial application To test new production possibilities of coated steel materials, a test plant was developped at RWTH Aachen. The plant works in a semi-batch mode, where plates are plunged into melted high-graded steel (see Fig. 15). While the plunging is a typical discontinuous activity, the following rolling procedure must be controlled in a continuous way.

plant units

hydraulic lifting system

roller

5.3 The Internal Transaction Control Unit A second example of the dynamic specification of a generic component is the ’internal transaction control unit’(see Fig. 14). The generic aspect is realized, offering a hierarchical state machine to specify the control flow between the components of a block.

heating system

melting pot

hydraulic system

Figure 15: Steel coating plant external execution request internal execution request

internal transaction control activate send connections

activation

Tmax failure working state

timespan

timeout

method inactive

ret_get connection ret_component n

...

ret_component n+1

...

ret_send connection

ret_component n

...

out of operation

execution request

activate get connections aktivate component n

component n+1 component n

ret_component n+1

.. .

component 1

The task of process control engineering was to realize a control structure which deals with the hybrid process dynamic and offers a maximum size of reusable and analyzable control units. The realized control architecture shows figure 16. It is based on three key concepts: 1. The control concept fulfills the hierarchical process control model 2. All control logics and algorithms are encapsulated in function blocks 3. All function blocks are derived from the template of hybrid batch-oriented process control blocks.

Figure 14: The transaction control unit feeedback of group control units

If the block is activated by the tasking system and an internal or external execution request is valid, first all input ports are updated by activating the dedicated signal connections. Then the state to handle the function block method is activated. This state is extendable in a hierarchical way to define specific function block templates or function block types. Each transition to a new state initiates a signal to activate the corresponding component of the function block method. After treating the last component, all output connections of the block are activated which have to send data actively to other function blocks. To guarantee real time features of the whole function block system, each block is responsible to supervise its process time. Therefore, a clock is used which indicates a timeout. This leads to an interruption of the operating activities of the block. The block enters an inactive state and generates a failure event signal.

plunging without rolling

feeedback of group control units

dynamic control units (loadable by operator)

commissioning hydraulic system

plunging with rolling feeedback of group control units

instructions manual

manual

static control structure of roller manual

function unit roller drive one way drive control unit converter

manual

group control unit roller

force controlled/ thickness controlled

group control unit roller hydr. system

function unit roller hydraulic system

pos

group control unit lifting system

static control structure of lifting system

controller controller

controller

controller servo valve control unit

servo valve control unit

gate valve control unit

servo valve control unit

M

Figure 16: Part of the control architecture

Using the template of batch-oriented process control blocks, all important functionalities of operational handlings of control units were solved. A correct logic between mode switches of manual or automatic control,

7

the supervisory of realtime requirements and e.g. the correct treatment of conflicts of concurrent setpoint demands were guaranteed by using the validated components inside the template. The specific plant-oriented control steps were implemented using hybrid sequential function charts.

7 Conclusion The application of formal modeling languages to describe process control structures leads to well-defined and analyzable control functionalities. However, each formal description is more expensive and up to now more unfamiliar than traditional control languages. Therefore using formal modeling languages needs an investigation which subsystems of a process control application are worthwhile to specify in a analyzable way. Beyond doubt, two kinds of control structures are worthwhile: safeguard control logics and multi-used control algorithms. The presented research activities deal with the second group of control structures. In advance, big efforts had to be done to reduce the expected complexity of the control applications by introducing more modular and more generic specification elements in a function block language. The presented approach extends the engineeringmeans to develop function blocks. All conceptual ideas were described formally using a graph rewriting system. The new function block language includes hybrid modeling aspects to shrink the gap between the function block technology and the hybrid modeling methods. As a first application one modular template for function blocks in batch-oriented process control was specified in detail. Concerning the multiplication effect using templates, it is worthwhile to specify the dynamic of the unified and generic capsulated functionalities inside these templates in a formal way. To specify the behaviour, c/e-systems were used. The template was applied to several industrial control applications. One application is discussed in this paper in more detail. Danksagung This research project was supported by the German Research Foundation (DFG) within the ’KONDISK’ Priority Research Program under reference Ep 33/2-1.

References [1] IEC TC65 WG6: Function Blocks for industrial-process measurement and control systems. Committee Draft IEC 61499-1, 1999. [2] IEC SC 65C WG7: Function Blocks for Process Control, Committe Draft IEC 61804-1, 1999. [3] IEC 61131-3: Programming Language for Programmable Controllers, Genava 1992. [4] Foundation Specification, Device Description Language Specification, Fieldbus Foundation, Austin Texas, 1996. [5] PROFIBUS-PA Profile for Process Control Devices, Revision 3.0, PNO, Karlsruhe, 1999. [6] Enste, U., Kneissl, M.: Modelling of Software Structures in Process Control Systems - Avoiding Bugs by Using Graph

8

Grammars. IMACS Symposium on MATHEMATICAL MODELLING, ARGESIM Report No. 15: Proceedings Vol.1, Vienna, pp. 381-384, 2000. [7] Schuerr, A.: Logic Based Structure Rewriting Systems. In: Ehrig, H.; Kreowski, H.-J. (Hrsg.): Lecture Notes in Computer Science 776, Springer, pp. 341-357, 1994. [8] Selic, B.; Gullekson, G.; Ward, P.: Real-Time Object-Oriented Modeling, John Wiley and Sons, 1994. [9] Sifakis, J.; Nicollin, X.; Olivero, A.; Yovine S.: An approach to the description and analysis of hybrid systems. Lecture Notes in Computer Science 736, 1993. [10] Tittus, M.; Egardt, B.; Lennartson, B.: Hybrid systems in process control. In Proc. of 33rd IEEE Conference on Decision and Control, pp. 3587-3595, 1994. [11] Lynch, N.; Segala, R.; Vaandrager, F.; Weinberg, H.B.: Hybrid I/O Automata, in: Hybrid Systems III, LNCS, Springer Verlag, 1996. [12] Krogh, B.H.: Condition/event signal interfaces for block diagram modeling and analysis of hybrid systems. Proc. 8th Int. Symp. on Intelligent Control Systems, pp. 180-185, 1993. [13] Alur, R.; Coucoubetis, C.; Henzinger, T.A.; Ho, P.H.: Hybrid Automata: An Algorithm Approach to the Specification and Verification of Hybrid Systems. Bd. 736 LNCS, Berlin, Heidelberg. Springer Verlag, 1995. [14] Chouikha, M.; Schnieder, E.: Modelling of Continuous-discrete Systems with hybrid Petri Nets. In: Borne, P.; KSOURI, M.; Kamel, A.E.; (ed.): IEEE: Computational Engineering in Systems Applications, CESA, pp. 606-612, 1998. [15] Nenninger, G.; Krebs, V.: Analysis of Hybrid Systems using Hybrid Dynamical Models. In: Zaytoon, J. (ed.), Hybrid Dynamical Systems: 3rd International Conference on Automation of Mixed Processes, ADPM, Reims, pp. 428-431, 1998. [16] Sreenivas, R.S.: Towards a System Theory for Interconnected Condition/Event Systems. Ph.D. thesis, Carnegie Mellon University, Pittsburgh, USA, 1990. [17] Sreenivas, R.S.; Krogh, B.H.: On Condition/Event Systems with Discrete State Realization. Discrete Event Dynamic Systems: Theory and Applications 1, pp. 209-236, 1991. [18] Enste, U.; Epple U.: Hybrid structures in process control. American control conference, pp. 4482-4485, San Diego, 1999. [19] Epple, U.: Operational Control of Process Plants. In Polke, M.(ed.): Process Control Engineering. VCHVerlagsgesellschaft, Weinheim, 1994. [20] Enste, U.; Fedai, M.: Flexible process control structures in multi-product and redundant-routing-plants, Proc. 9th IFAC Symposium on Automation in Mining, Mineral and Metal Processing, Duesseldorf, pp. 211-214, 1998. [21] Enste, U.; Epple, U.: Standardisierte Prozessfuehrungsbausteine - die Basis fuer Applikationsmodelle zur operativen Fuehrung von verfahrenstechnischen Produktionsanlagen. VDI Bericht 1397, S. 505-512, 1998. [22] Rumbaugh, J.: Object-Oriented Modeling and Design. PrenticeHall Inc., New Jersey, 1991. [23] Kowalewski, S.: Modulare diskrete Modellierung verfahrenstechnischer Anlagen zum systematischen Steuerungsentwurf. Dissertation, Fachbereich Chemietechnik, Dortmund, 1996. receiving of paper: 24th October 2000