a multi-paradigm approach supporting the modular execution

Mathematisch-Naturwissenschaftliche Fakultät

Holger Giese | Stefan Henkler | Martin Hirsch

A multi-paradigm approach supporting the modular execution of reconfigurable hybrid systems

Postprint archived at the Institutional Repository of the Potsdam University in:Postprints der Universität PotsdamMathematisch-Naturwissenschaftliche Reihe ; 410ISSN 1866-8372http://nbn-resolving.de/urn:nbn:de:kobv:517-opus4-402896

Suggested citation referring to the original publication:Simulation : transactions of the Society for Modeling and Simulation International 87 (2011), pp. 775-808DOI http://dx.doi.org/10.1177/0037549710366824 ISSN (online) 1741-3133 ISSN (print) 0037-5497

Simulation

A multi-paradigm approach supportingthe modular execution of reconfigurablehybrid systems

Holger Giese1, Stefan Henkler2 and Martin Hirsch2

Abstract

Advanced mechatronic systems have to integrate existing technologies from mechanical, electrical and software engi-

neering. They must be able to adapt their structure and behavior at runtime by reconfiguration to react flexibly to

changes in the environment. Therefore, a tight integration of structural and behavioral models of the different domains is

required. This integration results in complex reconfigurable hybrid systems, the execution logic of which cannot be

addressed directly with existing standard modeling, simulation, and code-generation techniques. We present in this paper

how our component-based approach for reconfigurable mechatronic systems, MECHATRONIC UML, efficiently handles the

complex interplay of discrete behavior and continuous behavior in a modular manner. In addition, its extension to even

more flexible reconfiguration cases is presented.

Keywords

code generation, hybrid systems, reconfigurable systems, simulation

1. Introduction

When developing advanced mechatronic systems we donot only have to combine technologies from mechani-cal, electrical, and software engineering, we also have todevelop systems which can react flexibly to changes inthe system itself or the environment. Therefore,advanced mechatronic systems have to be able toadapt their structure and behavior at runtime (reconfi-guration). In addition, mechatronic systems usuallyhave real-time requirements and often show hybridbehavior, which requires the integration of the differentmodeling paradigms in the form of a hybrid system.Owing to the increasing complexity, such integrationhas to cover advanced specification techniques fromthe involved disciplines as well as their tools.

The design of complex mechatronic systems hasbecome so intricate that it can only be done by meansof computer-aided modeling.1 The models comprisemodules and hierarchies that are derived from the phys-ical–topological structure of the system. For subse-quent symbolic and numerical processing, the modelsare transformed into a format appropriate for process-ing which takes their modular–hierarchical structureinto account.2

Hierarchical block (HB) diagrams are the usualmethod to model technical or reactive systems. Theyare used in different domains, e.g. in mechanical andelectrical engineering, software or systems engineering.This common notation has its origin in control engi-neering. The blocks describe the behavior of the system.Modularization and hierarchical structuring are impor-tant aids for the solution of the complexity problem intechnical systems. Modularizing the function helps todecompose it into isolated subproblems which can beaddressed by different working teams and different sup-pliers. In software engineering, component-based speci-fication techniques that emphasize in addition the

1System Analysis and Modeling Group, Hasso Plattner Institute at the

University Potsdam, Prof.-Dr.-Helmert-Strasse 2–3, D-14482 Potsdam,

Germany.2Software Engineering Group, University of Paderborn, Warburger

Strasse 100, D-33098 Paderborn, Germany.

Corresponding author:

Stefan Henkler, Software Engineering Group, University of Paderborn,

Warburger Strasse 100, D-33098 Paderborn, Germany

Email: [email protected]

Simulation: Transactions of the Society for

Modeling and Simulation International

87(9) 775–808

! The Author(s) 2010

Reprints and permissions:

sagepub.co.uk/journalsPermissions.nav

DOI: 10.1177/0037549710366824

sim.sagepub.com

component type and interface typing rather than clas-sical block diagrams are used to model the requiredhierarchical decomposition.

In addition, only a single paradigm, such as contin-uous systems from the control engineering domain, isnot sufficient to address advanced mechatronic systems.Instead, multiple paradigms from the involved domainshave to be supported. Mosterman and Vangheluwe3

have identified three orthogonal dimensions for multi-paradigm development approaches, which are(i) models of different abstractions, (ii) different formal-isms, and (iii) meta-modeling. For the reconfigurationwithin advanced mechatronic systems as targeted bythis article, in particular, the integration of differentformalisms matter.

1.1. Advanced mechatronic system example

A typical example of an advanced mechatronic systemis the RailCab4 research project at the University ofPaderborn. In this project, autonomous shuttles aredeveloped which operate individually and make inde-pendent and decentralized operational decisions.

The modular railway system combines sophisticatedundercarriages with the advantages of new actuationtechniques as employed in Transrapid5 to increase pas-senger comfort while still enabling high-speed transpor-tation. In contrast to Transrapid, the existing railwaytracks will be reused.4

Figure 1 shows a schema of the physical model of theactive vehicle suspension system and the body control-ler. The suspension system of railway vehicles is basedon air springs which are damped actively by a displace-ment of their bases and three vertical hydraulic cylin-ders which move the bases of the air springs via anintermediate frame: the suspension frame. The vital

task of the system is to provide the passengers withhigh comfort and to guarantee safety and stabilitywhen controlling the shuttle’s coach body. In order toachieve this goal, multiple feedback controllers areapplicable with different capabilities in matters ofsafety and comfort. The right-hand side of the figureshows the controller model of the suspension module.

As a concrete example, we later look into the controlsystem of a testbed of a magnetic-levitation train(Figure 2(a)). The testbed allows control of the bodymass only in the vertical direction. It consists essentiallyof a supporting frame, two vertical guides for the bodyand carriage mass, sensors to obtain the position of thebody and the carriage mass, two voice-coil actuatorsfor the simulation of disturbances as well as the levita-tion motor and the body and carriage mass connectedby a mechanical spring. On the basis of this testbed weshow the modeling and code synthesis of a switchablecontrol.

Another detailed example considered later is thecontrol of shuttle convoys (Figure 2(b)). The particularproblem is to reduce the energy consumption due to airresistance by coordinating the autonomously operatingshuttles in such a way that they build convoys wheneverpossible. Such convoys are built on-demand andrequire a small distance between the different shuttlessuch that a high reduction of energy consumption isachieved. Coordination between speed control unitsof the shuttles becomes a safety-critical aspect andresults in a number of hard real-time constraints,which have to be addressed when building the controlsoftware of the shuttles. In addition, different control-lers are used to control the speed of a shuttle as well asthe distance between the shuttles. The controllers haveto be integrated with the aforementioned real-timecoordination.

A B

C

Prop.- valves

A / D

Controller

D / A

Sensors

Hydr. pump

Car body

Hydr. actuators

Air springs

to theactuators

z

y

Controller model(CAMeL-view)

x_rel_mod

springActive

x_z_ist_a

x_z_soll_a

x_z_soll_b

x_z_soll_c

L0_Acalc_Cyl_ref

calc_F_aktiv

Calc_F_aktivClass

GlobalControllerHcsType

L0_B

L0_C

x_z_ist_b

x_z_ist_c

yLFLRel_ist

zLFLRel_ist

yLFRRel_ist

zLFRRel_istsum_F_mod

Sum_F_modClass

c

x = f (x u t)

x = f (x u t)

x = f (x u t)y = g (x u t)

y = g (x u t)

y = g (x u t)

SpringActiveClass

damperActive

DamperActiveClass

Figure 1. Suspension module with controller.

776 Simulation: Transactions of the Society for Modeling and Simulation International 87(9)

1.2. Problem statement

Advanced mechatronic systems such as the outlinedRailCab system require solutions which incorporatemulti-paradigm models and exhibit flexible reconfigura-tion where the effects of reconfiguration can propagateacross module boundaries as we exemplify in more detaillater on. For such flexible reconfigurable hybrid sys-tems specified by multi-paradigm models, an efficientevaluation scheme is required which excludes deadlockscaused by the evaluation of the continuous parts of thehybrid system. However, existing approaches fall shortin providing the required efficient solution. White-boxapproaches require too many global evaluationschemes and thus too much memory for reconfigurablehybrid systems. Black-box approaches in contrastresult either in deadlocks during evaluation or requireiterative evaluation schemes which are not appropriatefor real-time processing. Schemes relying on the data-flow are usually inefficient and runtime failures cannotbe excluded. Existing modular techniques6–11 consider a(restricted) kind of reconfiguration but neither do theyconsider the required propagation across moduleboundaries nor a flexible kind of reconfiguration.Furthermore, these approaches do not support an inte-gration of proper analysis techniques in order to ensurethe correct real-time behavior.

1.3. Contribution

In order to apply component-based models for the spe-cification of advancedmechatronic systems with reconfi-guration, we have inventedMECHATRONICUML12,13 asdomain-specific refinement and extension of the UnifiedModeling Language (UML).14,15 Among others,MECHATRONIC UML defines hybrid componentsa and

hybrid reconfiguration charts16 which permit the inte-grated modeling of discrete behavior specified by thehybrid reconfiguration charts in the form of extendedtimed automata models with continuous components(e.g. feedback controllers) that are specified by block dia-gramsor differential equations. In former paperswehavealso described in detail the techniques to ensure the cor-rectness of the reconfiguration with respect to given real-time constraints16,17 and the available tool support forthe approach.18 In Table 1 the basic paradigm formal-isms used in mechatronic systems that are covered byMECHATRONIC UML are presented.19

As identified in the problem statement, complexreconfigurable hybrid systems as resulting fromMECHATRONIC UML models cannot always be directlyaddressed with existing simulation and code-generationtechniques. The focus of this article is therefore themodular execution scheme for reconfigurable hybridsystems which result from the combination of the dif-ferent paradigms that overcome this problem by oper-ating with rather restricted memory while stillremaining efficient. We outline its capabilities anddescribe in detail which analytic information is requiredto be able to synthesize the modular execution logic.

Our solution for handling the required complex inter-play between discrete behavior and continuous behaviorwith a modular hierarchical execution scheme is

(a)

Uppervoice-coil actuator

Lowervoice-coil actuator

Bodyposition sensor

Body springBody mass

Carriage mass

Carriageposition sensor

(b)

Figure 2. Testbed for the active vehicle suspension system (a) and convoy building shuttles (b).

Table 1. Paradigms used in MECHATRONIC UML

Paradigm

Continuous Event-based

Dynamic

structural

adaptation

Formalism Block diagrams Automata Story pattern

Semantics Differential

equations

Timed

automata

Graph

transformation

systems

aMECHATRONIC UML supports different component types. Weexplicitly name them except for general software components whichwe refer to as components.

Giese et al. 777

described in this paper in detail. The ideas for thisscheme have been published previously.16,20–22 In thispaper we integrate these ideas with the formal semanticsof the models, provide the complete details required toemploy the modular evaluation scheme, describe thestatic analysis and runtime checking techniques to safe-guard the development and report about the concretetool integration efforts and the available simulationcapabilities. In addition to our previous work, weextend the former results to also cover more generalforms of reconfiguration without losing the benefits ofthe developed modular scheme where possible.

The approach has been realized for the integrationof the UML tool Fujaba23 and the CAE (ComputerAided Engineering) tool CAMeL-View24 for the simu-lation environment IPANEMA.25 The modular execu-tion scheme effectively enables the integration ofmodels of both tools by enabling a shared notion of ahybrid component using the modular execution capa-bilities. Finally, we also present the simulation andvisualization for validation purposes for a reconfigur-able hybrid model within the CAMeL-View tool.

1.4. Outline

The paper is structured as follows. We first discuss thestate of the art in Section 2. Then, we sketch theMECHATRONIC UML approach for modeling reconfi-gurable hybrid systems in Section 3 with the focus onthe underlying integration of different paradigms usingthe introduced example. Then, we look into the prob-lem of ordering the evaluation of reconfigurable con-tinuous models in Section 4. We present in detail howthe required characteristics for a modular executionscheme can be derived from the models and employedto resolve this problem. An overview about support forthe correct development with models employing themodular scheme by static analysis and runtime checksis sketched in Section 5 and the underlying integrationof the two involved tools is presented in Section 6 refer-ring also to the example. The paper closes with a con-clusion and an outlook on future work.

2. State of the art

The considered state-of-the-art approaches are chosenon the basis of their capabilities of modeling hybridsystems (see Section 2.1) and their capability of gener-ating code for continuous and hybrid systems (seeSection 2.2).

2.1. Modeling of hybrid systems

MATLAB/Simulink and Stateflow26 are the de factoindustry standard for the modeling of technical

systems. Reconfiguration can be modeled by condition-ally executed subsystems which are triggered by controlsignals. Another approach for the modeling of reconfi-guration is the integration of discrete blocks (Stateflowmodels) into block diagrams. The alternative controlleroutputs are fed into a discrete block whose behavior isdescribed by a Stateflow model. Dependent on theStateflow models’ current discrete state, the corre-sponding continuous signals are blind out or directedto the block’s output. This enables switching betweenthe output signals of different controllers. Thus, aStateflow model can be used to only trigger the requiredelements of the currently active configuration instead ofblinding out the results of those that are not required.This approach allows modeling of reconfiguration butit has the disadvantage that systems will become verycomplex.

Hybrid bond graphs27 introduce so-called controlledjunctions to model reconfiguration. A finite-statemachine (FSM) is associated with each controlled junc-tion. Each state of the FSM is of the type on or off,indicating if the controlled junction acts like a normaljunction or as a 0 value source. Therefore, state changesturn parts of the model on or off. Modeling reconfi-guration with hybrid bond graphs has the same draw-back as conditionally executed subsystems, as graphsconsist of all active and inactive configurations.

Other approaches combining components andhybrid automata concepts such as CHARON28 (andits extension R-CHARON29), HyROOM,30,31

HyChart,32,33 HybridUML,34 and Ptomely II35 providehierarchical automata models for the specification ofbehavior and hierarchical architectural models. InUMLh,36 the architecture is specified by extendedUML class diagrams that distinguish between discrete,continuous, and hybrid classes. Also, the OMG effortto integrate models from the software engineeringdomain with models from the control engineeringdomain falls into this category. The SystemsModeling Language (SysML)37 is a first proposal tostandardize system engineering, which could be inte-grated with a possible UML 2.0 successor.38

All of the presented tools and techniques for hybridcomponents support the specification of a system’sarchitecture or structure by a notion of classes or com-ponent diagrams. All approaches support modulararchitecture and interface descriptions of the modules.Nearly all approaches embed the continuous models inthe discrete state machines using the hybrid automataconcept in order to model reconfiguration of the con-tinuous behavior within one module. Specifying recon-figuration with SysML should be possible with theactivity diagrams, but concrete examples for this issuedo not exist. Nevertheless, the approaches do notrespect that a module can change its interface due to


reconfiguration which can lead to incorrect configura-tions and further the approaches do not permit thatreconfiguration takes place across module/blockboundaries.

CHARON, Masaccio, HybridUML with HL3,UMLh, HyROOM, and HyCharts have a formallydefined semantics, but due to the assumption of zero-execution times or zero-reaction times, most of themare not implementable, as it is not realizable to performa state change infinitely fast on real physical machines.CHARON is the only approach providing an imple-mentable semantics. HyCharts are implementableafter defining relaxations to the temporal specifications.They respect that idealized continuous behavior is notimplementable on discrete computer systems. Further,CHARON provides a semantic definition of refinementwhich enables model checking in principle. Ptolemy IIeven provides multiple semantics and supports theirintegration.

2.2. Composition and evaluation order

Given a continuous system, to evaluate the differentialequation the different parts of the equation system haveto be executed. For a correct execution the overall eval-uation order has to be respected in order to prevent adeadlock during computation or invalid results.39 Theconnections of subsystems has a direct impact on themethod of the so-called model integration, i.e. embed-ding of subsystems into the simulation platform. In theprocess one has to distinguish between different kindsof integration: in a black-box integration, communica-tion can disregard the inner structure of the subsystemwhile in a white-box integration the communicationroutines are implemented purposefully into the evalua-tion functions of the subsystems. A dataflow integrationis the third alternative. Finally, we discuss mixedapproaches, which use the benefits of the aforemen-tioned approaches.

The most simple solution to determine the evalua-tion order is to use white-box integration. To this end,the overall evaluation graph is built and the evaluationis done in an intertwined manner such that the nodes ofdifferent blocks have to be evaluated separately. Sincethe sequence of the evaluation can be computed onlyfor the entire system, this integration approach is inher-ently non-modular and only permits us to derive opti-mizations concerning the granularity of the executionlogic for the whole system.

White-box integration thus solves the problems con-cerning the evaluation order for a whole system if wehave a static structure and do not require modular exe-cution. In the formal semantics defined in AppendixA.2.2, we simply flattened the hierarchal structure andcomposed the directed acyclic evaluation graphs when

composing continuous blocks and thus effectivelyemployed white-box integration as this is the state-of-the-art approach by control engineers. However, whiletheoretically sound such a solution does not fit to ourneeds for the execution logic of reconfigurable hybridsystems (high number of evaluation orders due to theexponential).

A Java and a C/Cþþ export to support simulationof hybrid bond graphs has been outlined previously.40

The evaluation order has to be derived for every globalstate (the cross product of FSMs of all controlled junc-tions). In our approach, we exploit the hierarchicalcomponent structure to build a tree structure, whichavoids getting a number of evaluation orders that isexponential in the number of states. Further, a switchof a discrete state in a FSM can trigger transitions inother FSMs. Therefore, no upper bound is given,describing the number of transitions, which fire beforethe system reaches a consistent, stable state and contin-uous evaluation can proceed. In our approach the dis-crete and the continuous evaluation are decoupled andthe upper bound of firing transitions is set by thehierarchy.

An alternative for determining the evaluation orderwhich allows the use of a more coarse-grained structur-ing of the execution logic is black-box integration. Inour approach, only the input/output interfaces of thesubmodels are considered. Their inner structureremains hidden. Therefore, communication occursonly vectorially at certain, precisely defined momentsin the program run.39

In order to reduce dependencies, the equations canbe sorted according to the categories non-direct link(ND), direct link (D), and state equations (S). Thesecategories serve to classify the input/output variables41

for _x the state vector, y the output vector, u the inputvector, p the parameter vector, and t the time asfollows.

Non-direct links. All output variables that do notdepend directly on input values are non-direct linksand can thus be computed directly: yN (t)¼ f (x, p, t)(see y1 of Figure 3(a)).

Direct links. This category comprises all input vari-ables that have an immediate effect on at least oneoutput variable: yD (t)¼ f (x, u, p, t) (see y2 or y4 ofFigure 3(a)).

State variables. Input variables that apply only tostate equations fall into this category: _x ¼ f x,u,p,t

� �

(see _x of Figure 3(a)).However, in principle, the problem of a communica-

tion deadlock due to a cycle in the evaluation graphwhich results from the composition of two continuous

Giese et al. 779

blocks cannot be fully solved just by introducing theND-, D-, and S-blocks. A deadlock can occur, if thecouplings between direct-link blocks make up a cycle.The model cannot be evaluated at the chosen granular-ity level any more because the subsystems required tocompute the data are waiting for the data of the othersubsystems. These cyclic waiting dependencies can thusresult in a conceptual deadlock (Figure 3(b)).

The deadlock can be dissolved by employing itera-tions or by white-box approaches. Descriptor methodsbased on differential-algebraic equations (DAEs) are anapproach for supporting modular simulation based oniterations. One drawback of these methods is that theycannot be used in real-time contexts because of the iter-ative parts of the necessary solvers. There are severalCAE tools that are also based on DAEs, such asADAMS42 or SIMPACK43, which allow multi-bodymodeling and simulation yet have the same drawbacksin real-time evaluation as do all DAE-based tools.44

Another feasible solution is the use of filters.However, they alter the model and thus the systembehavior, which is in most cases unacceptable.7,8

Another option is dataflow integration which main-tains no precomputed evaluation orders but use theflow of data via the expressions and connections tocontrol the evaluation. While conceptually elegantand even applicable for any imagined reconfiguration,this solution results in two serious problems.

At first, deadlocks in the evaluation order are notdetected during the compilation and composition of the

system but rather at runtime.45 This is a rather unsafesituation which is often not acceptable for manymechatronic systems as oftentimes critical functionalityis realized and thus runtime failures which cannot beresolved easily at runtime also have to be excluded.Furthermore, reconfiguration across module bound-aries is not supported.45

Second, evaluating each single equation related tothe nodes of the evaluation graph of the system as asingle unit results in an extremely slow execution logic.In between each single assignment the potentially com-plex processing of the dataflow and the availability ofall inputs of an equation happens.

Therefore, this alternative is in fact no real optionfor an industrial strength solution for reconfigurablehybrid systems unless the models executed under thisregime are rather small. However, we look for a solu-tion for large, complex mechatronic systems.

It is also possible to avoid such runtime checks andrely on computing a fixpoint at runtime.46,47 However,this fixpoint may contain undefined values, whichmeans such code cannot be used in safety-critical,hard real-time applications.

The last solutions are approaches that mix the dif-ferent other approaches. Approaches for modular codegeneration of synchronous languages, such asMATLAB/Simulink and LUSTRE48 or Esterel,49,have been presented previously.6,10,11 Modular codegeneration is mandatory for synchronous languagesto find adequate variables which lead to deadlock-freeand efficient code. These approaches abstract eachblock in a way which enables modular code generation.For example, a set of interface functions of each blockand a set of dependencies between these interfaces canbe generated.10,11 The finer the abstraction, the moreinformation about the input and output dependencies ispreserved, which enables the block to be more reusable.This is similar to our gray-box approach for the evalu-ation of block diagrams (see Section 4), but theseapproaches did not consider reconfiguration acrossmodule boundaries as well as no flexible reconfigura-tion as required in our problem statement (seeSection 1.2).

Previous studies7–9 have considered synchronouslanguages with dynamic reconfiguration. The authorspresent a conservative extension of LUSTRE with hier-archical state automata, based on a translation seman-tics into a clocked dataflow kernel. The authorsadvocate that such a translation not only gives thesemantics of the whole language, but is an effectiveway to implement the compiler (code generation) inthe sense that the generated code is efficient and ofsmall size. In this approach cyclic dependencies areavoided by requiring that every feedback loop isbroken by a unit-delay block at every level of the

Figure 3. Correct (3(a)) and deadlocked (3(b)) black-box

integration with ND–D–S decomposition.


hierarchy. This is a major modeling restriction, as mostdiagrams in practice exhibit feedback loops with nosuch delays at higher levels of the hierarchy.

2.3. Comparison

In summary, the existing approaches fall short when itcomes to reconfiguration that is not restricted to effectswithin a single module. In addition, existing evaluationschemes are not able to cope with the complexity whenevaluating reconfigurable hierarchical hybrid systems.The presented solution for MECHATRONIC UML over-comes these limitations providing modeling capabilitiesas well as an efficient evaluation scheme for the result-ing complex models.

3. Multi-paradigm modeling

In this section, we consider how the different modelingparadigms for the control and software engineeringdomain are integrated into the MECHATRONIC UMLapproach (see Table 2). We especially focus onthe resulting support for reconfigurable hybrid sys-tems.b We introduce here only the supportednotation. A detailed formalization of the conceptsincluding the basic syntax and semantics is presentedin Appendix A.2.

3.1. Continuous models

As stated in Section 1, a common technique for thespecification of controllers that is widely used in differ-ent tools is the notion of HB diagrams.

Block diagrams generally consist of basic blocks(BBs), specifying behavior, and HBs that group basicand other HBs to reduce the visual complexity. Eachblock has input and output signals. The unidirectionalinterconnections between the blocks describe the

transfer of information. For example, the outputsignal of a BB is fed as an input signal into a HB.

Figure 4 displays the three controllers that areapplied in our example. In Figure 4 the Comfort con-troller, providing the passengers the most comfort, isshown. It consists of two PIDT1 controllersc: one forcontrolling the undercarriage, the other for controllingthe coach body. For inputs, PIDT1,body obtains thedesired and the actual positions of the coach body.The first is provided by a user input, the latter by asensor. The output yields the position of the undercar-riage and serves as an input for PIDT1,carriage. The otherinput, the current position of the undercarriage, is alsoprovided by a sensor.

If, however, a user input does not exist, this value isset to a constant value as displayed in Figure 4(b). Incase the xbodycurrent sensor should fail, this controller struc-ture could lead to an instability. Then the system needsto be reconfigured as shown in Figure 4(c). Therequired position of the undercarriage is set to a con-stant value. This controller provides less comfort, butguarantees stability. To ensure stability, fault tolerancepatterns are applied in such a way that the signalxcarriagecurrent is computed redundantly such that we canrely on xcarriagecurrent even in the case on sensor data fails.

A single block is characterized by input, output, andauxiliary variables and a set of expressions with a left-hand side variable and a right-hand side expressionwith references to other variables (see Figure 5).

If the set of equations is well-formed (see AppendixA.2.1), it can be represented by a corresponding direc-ted acyclic evaluation graph. Each left-hand side vari-able is represented by a node and all occurrences ofvariables in the right-hand side as an edge from thenode of the referenced variable to the node of thedefined variable. Following this outline, we can derivean acyclic evaluation graph G¼ (N, E) with node set Nand edge set E�N�N. For each n2N and the relatedexpression v :¼ . . .v0. . . holds that for each variable v0

the expression refers to an edge (n0, n)2E with n0 isrelated to v0. In addition, we have for each evaluationgraph Nstate�N denoting the subset of nodes which

Table 2. Paradigms and Tools in the Mechatronic UML

Paradigm

Continuous Continuous þ event-based Dynamic structural adaptation

Formalism Block diagrams Hybrid reconfiguration charts þ hybrid components Story pattern þ hybrid components

Semantics Differential equations Hybrid reconfiguration automata Hybrid graph transformation systems

Tool CAMeL Fujaba Fujaba

bNote that in addition to providing a solution to the multi-paradigmmodeling problem, in practice rather than simply a new languagesupport for the different established domain-specific notation andtools is needed. The Fujaba Real-Time Tool Suite presented inSection 6 therefore realizes the MECHATRONIC UML approach byintegrating an existing CAE tool. cPIDT denotes proportional–integral–derivative–time controller.

Giese et al. 781

represent the internal state of the block. In the case of awell-formed composition of two continuous blocks, wecan derive the resulting directed acyclic evaluationgraph by simply combining the graphs of both blocksat the connected inputs and outputs. In the case of asingle block as well as a composition, a simple check ofthe evaluation graph at compile-time is sufficient toexclude problems with the evaluation at runtime.

3.2. Reconfigurable hierarchical hybrid models

The architecture of the system is based on distributed,interconnected components. The components are basedon UML 2.0 components but we distinguish betweendifferent types of components (see Figure 28). We dis-tinguish between (discrete) components, hybrid compo-nents, and continuous components (block diagrams).As required in the introduction of Section 3, compo-nents can embed other components. In addition, we candistinguish between component types and componentinstances.

Figure 6 shows an instance view of the componentstructure of the suspension system. There it is shownthat a hybrid Monitor component embeds continuousSensor and Storage components and, moreover, a

hybrid BodyControl component, which embeds threedifferent controllers (not shown in the figure). Based onthe availability of the information of the Storage,which stores track information of other shuttles,which are communicated from the registry and theSensor of the BodyControl can switch between differ-ent controllers based on the available information. Inaddition to the shown embedding of the different par-adigms, a more abstract view in the form of patterns is

(a)

(b)

(c)

Figure 4. (a) Comfort controller; (b) semi-comfort controller; and (c) robust controller.

Inputs: U1, U2, U3, U4Outputs: Y1, Y2, Y3, Y4States: X=0;Auxilars: a, b, c, d

a := U1 + U2;b := U3;c := U4;d := 1;X' := X + c;Y1 := a;Y2 := b;Y3 := b;Y4 := d*x;

Figure 5. A basic continuous block.


also supported as shown in the figure. A pattern inour case consists of port roles (MonitorRole,RegistryRole) and a connection between the roles.In addition to the structure, a pattern also consists ofa behavioral description.17

The behavior of this hybrid BC component is speci-fied by a simple hybrid statechart (see Figure 7) whichis an extension of a real-time statechart.50 It consists ofthree different control modes (discrete states) associ-ated with the three configurations from Figure 4.

The configurations consist of PIDT1,carriage,PIDT1,body, and the P blocks. For switching betweentwo controllers, we can distinguish between atomicswitching and cross-fading. If the switching betweentwo blocks can take place between two computationsteps, atomic switching is used and otherwise we usecross-fading. The cross-fading itself is specified by a

fading function and an additional parameter whichdetermines the duration of the cross-fading. Boldarrows indicate that output cross-fading, which con-sumes time, has to be applied when there is a switchbetween two states. The deadline intervals di specify theminimum and maximum fading time allowed. In con-trast, thin arrows indicate that a switch is performedwithout time-consuming fading.

When using this component in advanced contexts(e.g. embedding the component in another configura-tion), usually an abstract view of the component with-out the implementation details is sufficient. This view isgiven by the hybrid interface statechart (see AppendixA.2) of the component (see Figure 8). It consists of theexternally relevant real-time information (discretestates, their continuous inputs and outputs, possible

MonitorRole

:Sensor

:Registry

RegistryRole

:Monitor

storage : Storage

:BC

Monitor−Registration

Figure 6. Structural description of the suspension system.

Figure 7. Behavior of the BodyControl component.

Figure 8. Interface statechart of the Body Control

component.

Giese et al. 783

state changes, their durations, signals to initiate transi-tions, and signal flow information).51 They abstractfrom the embedded components and from the fadingfunctions. Ports that are required in each of the threeinterfaces are filled in black, those that are only used ina subset of the states are filled in white.

In this example, each discrete state of the componenthas a different continuous interface, a fact that leads toan interface statechart which consists of as many dis-crete states as does the detailed hybrid statechart.Usually, not every internal reconfiguration will resultin a different external state, which leads to furtherreduction of complexity in the interface statechart.The external view of the monitor component (seeFigure 10) does not change at runtime although it con-sists of four discrete states. Therefore, its interface sta-techart consists of just one state.

As displayed in Figure 9, the BC component isstructurally embedded into the Monitor component.Figure 10 shows the behavior of the monitor embed-ding and coordinating the behavior of BC and the otherembedded components as described previously.16,21 Forthis embedding the notation from the interface state-chart (see Figure 8) is used.

The hybrid statechart in Figure 10 consists offour states representing that (i) a user input existsas well as the sensor providing xbodycurrent (stateAllAvailable), (ii) both of these signals are not avail-able (state NoneAvailable) and (see (iii) and (iv))exactly one of these signals is available (statesBodyAvailable and UIAvailable). Note againthat the sensor providing xcarriagecurrent is laid out as faulttolerant.

Every state is associated with a configuration. Thus,a switch from NoneAvailable to BodyAvailable

results in a reconfiguration and a switch of the embed-ded BC component from state Robust to SemiComfort.The states UIAvailable and NoneAvailable arerequired to keep track of the available signals, yet aswitch between them will not lead to a reconfigurationor further state switches.

Transitions, visualized by bold arrows, are associ-ated with deadlines because they are time consuming.They are triggered by events, raised from the xBody

Sensor or UserInput component.

s1:Sensor

:UserInput

s2:Sensor

:Actuator:BC

Monitor

Figure 9. Structure of the controlling system.

(a)

(b)

Figure 10. (a) Behavior and (b) interface statechart of the Monitor component.


3.3. Flexible reconfigurable hierarchicalhybrid models

The approach presented so far can effectively beapplied when the required reconfiguration is local.Usually, all possible configurations are well known atthe design time and their number is small. However,specifying more flexible reconfiguration which resultsfrom the need to coordinate ad hoc groups cannot beaddressed.

When shuttles build a convoy and a leader shuttledetermines the reference positions for all of the follow-ing shuttles, the control of these reference positionsdepends on the length of the convoy and on the partic-ipating shuttle types and characteristics. For example, aheavy load shuttle has to hold a larger distance withinthe convoy. The leader shuttle of a convoy can respectsuch individual properties or requirements only whenindividual components or feedback controllers areapplied to determine the reference positions. Using ourapproach presented so far would thus be impractical as alarge number of possible configurations (in principle,even infinitely many) have to be specified explicitly.

In the given example, the different shuttle types arenot known a priori at design time (recall how manydifferent types of automobiles exist). Thus, each shuttlesends the component, which the leader shuttle has toapply, to the leader shuttle when it joins the convoy atruntime. We therefore suggest to specify the requiredflexible structural reconfiguration by means of reconfi-guration rules where control elements can be deter-mined by parameters which are based on a storypattern.52 Story patterns are based on the theory ofgraph transformations systems which are usuallyapplied for model transformations. We exemplify thatthey are an appropriate visual, model-based description

technique for the specification of reconfiguration atruntime.

A cut-out of the behavior of the shuttles for coordi-nating convoys is depicted in Figure 11. We previouslydescribed how to ensure a safe building of convoys.17

The hybrid reconfiguration chart consists of threestates: ConvoyLeader represents that the shuttle is theleader shuttle, ConvoyFollower represents that theshuttle is part of a convoy but not the leader shuttle,and NoConvoy represents that the shuttle is not in aconvoy at all.

Residing in state ConvoyFollower, the shuttleapplies a position controller that delivers the currentacceleration a dependent on its reference position srefand its current position scurrent. It periodically receivesthe event receiveRefPos with parameter pos[] andstores the new reference position pos[id] as a sideeffect in sref. In state NoConvoy, the shuttle applies avelocity controller, requiring a reference and the cur-rent velocity as input. The latter is used to determinethe current position pos[id]. When a new shuttle joinsthe convoy, it sends an event enterConvoy with thefollowing parameters: its identifier id, the componentC to be used to determine the shuttle’s reference posi-tion, and the IDs pre and suc of the shuttles which letthe new shuttle in.

The reconfiguration rule of the transition (visualizedwith a dashed border) adds the component C to theshuttle’s control structure: an instance of a componentChar is created that provides the characteristics of theleader shuttle such as length or maximal brake acceler-ation. These characteristics and the current position ofthe leader shuttle are fed into C which determines thereference position pos[id] as the output. A simpleimplementation of component C would just add thelength of the preceding shuttle and an individual

Figure 11. Shuttle behavior to control convoys.

Giese et al. 785

safety margin to the current position of the precedingshuttle. Port c[id] provides the characteristics of thenew shuttle.

Residing in state ConvoyLeader, the shuttle sendsperiodically with a period p2 [plow; pup] the referencepositions pos[] to the according shuttles. If a furthershuttle joins the convoy, its component is inserted intothe structure between the components of prev and suc.Reconfiguration rules for the special cases when a shut-tle joins at the end or at the beginning of the convoy orfor the case when a shuttle leaves the convoy are omit-ted in Figure 11. Owing to a lack of space, we alsoomitted transitions which model that shuttles leavethe convoy. If we specified a transition, leading fromConvoyLeader to NoConvoy, the current configuration(eventually consisting of multiple components) wouldbe discarded and the configuration of NoConvoy wouldbe applied.

The example points out that modeling flexible recon-figuration with reconfiguration rules leads to an enor-mous reduction of the visual complexity, as not everypossible configuration has to be specified explicitly.

4. Modular execution

In the following, we present in detail our concept forthe modular execution of reconfigurable hybrid systemsfor the reconfigurable models sketched in the formersection. First, we discuss our solution for modular hier-archical continuous systems and then extend it toreconfigurable hierarchial hybrid systems. Finally, oursolution for the continuous dataflow part of flexiblereconfigurable hierarchical hybrid systems is presented.For completeness, the syntactic and semantic founda-tions are presented in Appendix A.2.

4.1. Modular composition and evaluation order

For providing a feasible evaluation scheme for the hier-archical reconfigurable hybrid systems presented in thelast section, we require as a crucial prerequisite a mod-ular composition scheme which is less restrictive andmore efficient than black-box integration.10 Our pro-posed approach20,22 outlined in the following combinesthe advantages of both the white-box and the black-boxapproach and is thus named gray-box integration (asoriginally coined by Oberschelp et al.53 for the dynamiccomputation of the evaluation order at runtime).

With a gray-box method one tries to combine theadvantages of the white box with those of the blackbox. The sequence of evaluation for gray-box integra-tion is determined in two stages. The first stage definesthe local sequence of evaluation of each BB indepen-dently of an external coupling. For a HB, the couplinginformation on its children and the resulting reduced

evaluation graph will be determined and furtheremployed. This implies an independent derivation ofthe execution logic for every block; thus, a model canbe generated from independent modules. At the secondstage the external coupling information yielded by theHBs is taken into account for determining the entiresequence of evaluation and making up the evaluationgraph. This presupposes a well-defined module inter-face. The information required for this step wereobtained in the preceding stage so that this procedurecan be completed during initialization of theapplication.

When proceeding in this way we are able to hide theinternal logic of a module. This is especially importantif one wants to exchange models and integrate themeven though their content is to be kept secret. Thegray-box method solves the problem of the direct-linkfeedback coupling by further decomposing the equa-tions in the direct-link block into independent partialblocks. Appurtenance of the equations to a partialblock is defined by their dependence on one or severalinput and output variables, with an input or an outputvariable being allocated definitely to just one partialblock in the direct-link block.

In order to derive the required information to embedthe acyclic evaluation graph in an arbitrary context, wehave to partition it into separate evaluation blocks (seeFigure 12, right). For the optional decomposition intosuch evaluation blocks, it must hold that when the orig-inal evaluation graph G¼ (N, E) can be safely embed-ded in a given context that also the evaluation blockscondensed evaluation graph can be embedded safely.

The partitioning problem for a given acyclicexpression graph G¼ (N, E) of a continuous block isthus to determine a minimal number of partitions

Inputs: U1, U2, U3, U4Outputs: Y1, Y2, Y3, Y4States: X=0;Auxilars: a, b, c, d

a := U1 + U2;b := U3;c := U4;d := 1;X' := X + c;Y1 := a;Y2 := b;Y3 := b;Y4 := d*x;

ND-Blockd := 1;

ND

D1

D2

S

Y4 := d*x;

D-Blocks

a := U1 + U2;Y1 := a;

Y2 := b;b := U3;

Y3 := b;

S-Blockc := U4;X' := X + c;

Figure 12. Partitioning of the evaluation graph.


N1, . . . ,Nn�N such that:

1. N¼N1[ � � � [Nn and for all i 6¼ j, Ni\Nj¼;,2. the derived graph Gp¼ (Np,Ep) with Np¼

{N1, . . . ,Nn} and Ep¼ {(Ni,Nj)|i 6¼ j6i, j¼ 1, . . . ,n6 9n0 2Ni 6 n00 2Nj : (n

0, n00)2E} is acyclic, and3. for any context graph G0 ¼ (N0,E0) with

(N\N0)� (Nin[Nout) and G00 ¼ (N00,E00) withN00 ¼N[N0 and E00 ¼E[E0 an acyclic graph holdsthat the related derived graph for the partitioningbuilt by N1, . . . ,Nn and each node of N0 �N is alsoan acyclic graph.

Condition (1) ensures that the partition setsNi cover thefull node set N. The partitioning preserves the acyclicnature (see condition (2)). Finally, condition (3) infor-mally states that the chosen partitioning when embed-ded into an arbitrary context only results in a cycle whenalso the original graph would also result in a cycle.

For a given acyclic graph G¼ (N, E), we can com-pute the required maximal partitioning of such a graphin several phases.

First, we compute the set Din of all inputs the nodedepends on in a forward topological traversal of thegraph. Then, we perform a backward traversal to com-pute all influenced outputs Iout for all input nodes.Based on Din and Iout we can then determine thenodes of the S-block and ND-block. The remainingnodes are finally partitioned by propagating the depen-dencies L. Two nodes n and n0 are then assigned to thesame partition (NL[n]) iff L[n]¼L[n0]. The resultingalgorithm is presented in Figure 13.

4.2. Hierarchical composition andevaluation order

The presented scheme is sufficient to handle the com-position of a number of continuous blocks. However,systems in practice are structured by hierarchiesdescribing the coupling between blocks and betweenhierarchies (Figure 14).

Figure 15 depicts our decomposition approachwhich enables us to structure mechatronic systemsusing only BBs and HBs. To achieve such a decompo-sition in a modular fashion we have to determinewhether it is possible to find a partitioning of the eval-uation code and interface definition for modules suchthat the internal evaluation order of the modules can beadapted to any possible external coupling.

To extend our scheme also to hierarchical systems,we suggest to compute an abstraction in the form of areduced evaluation graph which serves as an interfacefor the execution logic and evaluation.

To derive the reduced evaluation graph which relatesto the computed optimal partitioning (see Figure 16,

right), we can use the computed dependencies capturedby L. The algorithm performing this task is presented inFigure 17.

Using the evaluation blocks as evaluation steps, itbecomes possible to execute an entire system in a mod-ular manner using the following three cases.

1. Local partitioning and local execution order. For anon-hierarchical gray-box component we can com-pute a minimum partitioning by means of the algo-rithm outlined. Condition (3) then ensures that forany possible context, a correct evaluation order ofthe blocks can always be identified if it can be foundin the white-box scenario. The subgraphs of the acy-clic expression graph related to each block are alsoacyclic and correspond to a partial order of theexpression evaluations. The partial order can berefined into a total order which can then be usedto sequentially evaluate the expressions within thecode for those blocks.

2. Hierarchical partitioning and local execution order.The block partitioning algorithm outlined can alsobe used to derive the required partitioning informa-tion in a hierarchical manner. The evaluation graphwhich results from the reduced evaluation graphs ofall embedded components is sufficient to derive againa minimal set of hierarchical evaluation blocks (seeFigure 18). In contrast to the non-HBs, these blocksconsist of the blocks of the embedded componentsand the coupling. If no block partitioning can befound, a logical flaw in the component structureexists which would also prevent execution in thewhite-box scenario. If a block partitioning has beenfound, we also know that the original is acyclic. Thesubgraphs of the dependency graph which is assignedto each block will thus always be acyclic too, and canbe used to derive the required internal order of thesubordinated blocks, couplings, or expressionevaluations.

3. Global execution order. When the top hierarchicallevel has been reached, the only remaining inputsandoutputs are sensors or actuators.We can thereforebe sure that the resulting evaluation graphs are acyclicand we can derive the main execution logic followingthe scheme outlined for the hierarchical case.

To summarize, we can derive the execution logic foreach component in a modular manner by:

(a) deriving the blocks, their local execution logic, anda reduced evaluation graph for all BBs;

(b) deriving the blocks, their local execution logic, anda reduced evaluation graph for all HBs consideringonly the internal coupling and the reduced evalua-tion graph of all embedded blocks; and

Giese et al. 787

(c) using a simple execution logic for the top-levelblock which only triggers the evaluation of itsubblocks.

In the case of a static hierarchical continuous systemthis modular procedure has a higher overhead pro-duced by the granularity of the partitioned blocksthan a monolithic solution. However, in the following

section we show that the presented scheme is requiredto have a feasible scheme to evaluate reconfigurablehybrid systems.

4.3. Reconfigurable hierarchical hybrid systems

In addition to the hierarchy, if we consider that theswitching between different states of a hybrid

Figure 13. Block partitioning algorithm.


reconfiguration chart results in a reconfiguration, wehave to further extend our evaluation scheme. In con-trast to the static case the local state changes result in adifferent configuration of embedded components andtheir wiring which must be executed (see Figure 19).

For such a reconfigurable hierarchical hybridsystem, a white-box integration is not feasible as werequire one global evaluation order for potentiallyexponential many configurations. The modularscheme outlined before is, however, still applicableand can be used to realize the execution logic withlow effort.

For reconfigurable hybrid systems we haveextended the modular evaluation scheme presentedso far as follows. Owing to the additional discretepart, we have to locally determine the ordering andselection of evaluated subblocks depending on a localstate for each HB leading to a modular scheme forhierarchical hybrid systems. Therefore, we have toderive for every discrete state the blocks, their localexecution logic, and a reduced evaluation graph takingonly the internal coupling and the reduced evaluationgraph of all embedded blocks in the embedded modeinto account.

Only function /mathematics /behavior

Only couplings

BB BB

HE

HE

BB HE

BB

BB BB

HE

BB

HE-hierachical elementBB-basic block

basic block basic block

basic block

basic block

basic block

hierarchyhierarchy

hierarchy


hierarchy

Figure 14. Hierarchical block diagrams.


basic block

basic block

basic block

hierarchyhierarchy

hierarchy

Representative

Submodel A

Submodel B


hierarchy

Figure 15. Decomposition of block diagrams.

Giese et al. 789

To explain the resulting overall modular executionscheme, we outline here the details for our initialtestbed. When the Monitor component is evaluated, itwill trigger the evaluation of its embedded components.

As not every embedded component belongs to everyconfiguration, it depends on the current discrete stateof the Monitor which of the embedded components areevaluated. Then, the triggered components will them-selves trigger their embedded components (dependenton their discrete states).

Thus, there is one evaluation order per discrete globalstate. Enhancing the top-level monitor component withthis information is usually not feasible as the number ofglobal states grows exponentially with the number ofcomponents. Therefore, we compose the whole systemas a tree structure consisting of modular hybridcomponents.

Each hybrid component is partitioned into multiplediscrete and continuous evaluation nodes using theformer outlined hierarchical partitioning. The continu-ous evaluation nodes compute continuous states andoutputs of the feedback controllers similarly to theblocks discussed before. The discrete evaluation nodesswitch the discrete states of the components and recon-figure subordinated hybrid components. As the appli-cation of certain continuous evaluation nodes dependson the actual configuration and thus on the actual dis-crete state, safety can only be guaranteed if one

Figure 17. Algorithm to compute the reduced evaluation

graph.

ND-Blockd := 1;

ND U1

U2

U3

U4

Y1

Y2

Y3

Y4

D1

D1

D2

S ND

D2

S

Y4 := d*x;

D-Blocksa := U1 + U2;

b := U3;Y2 := b;Y3 := b;

YI := a;

S-Blockc := U4;X' := X + c;

Figure 16. Derive the reduced evaluation graph for a basic

block.

Basic block

Basic block

Basic block

Basic block

hierarchy hierarchy

hierarchy

Interchange,reconfiguration

A

B

Figure 19. Decomposition of hierarchical hybrid component

diagrams.

Figure 18. Evaluation graph of a hierarchy.


continuous evaluation cycle is not preempted by theevaluation of a discrete node which switches theactual discrete state. Therefore, we separate the evalu-ation of the discrete nodes from the evaluation of thecontinuous nodes in time.

4.3.1. Basic continuous components. We have todetermine the evaluation order of the continuousnodes dependent of their external couplings. Inorder to minimize computational effort, we partitionmultiple single evaluation nodes of subordinated com-ponents into evaluation nodes of the superordinatedcomponent. The order within such a superordinatedevaluation node is static and thus does not change.We apply the partitioning algorithm outlined in thelast section.

The output of the algorithm is called the reducedevaluation graph of the configuration. It shows theinterface of the component, the partitioned evaluationnodes, and their input–output dependencies.

Figure 20(a) shows ad P and a PIDT1 controller. Eachnode represents a set of expressions (e.g. mathematicalexpressions) and the arrows indicate the dependencies.The reduced evaluation graphs, which are obtained fromthe application of the partitioning algorithm, are shownin Figure 20(b). The P controller consists of one (directlink) node nd0, the PIDT1 controller consists of one(direct link) node nd0 and a (state) node ns0.

In order to evaluate the nodes in a different order,each basic continuous component is implemented as aclass, providing an evalCont(int nodeId) method.According to the parameter of the method, the corre-sponding node is evaluated (see Figure 21). The possi-ble nodeIds nd0 or nd0, and ns0 respectively correlate tothe nodes which have been determined by the partition-ing algorithm (see Figure 20(b)), the internals(auxiliars[0]¼. . .) are the expressions of the compo-nents (see Figure 20(a)).

4.3.2. Basic discrete components. Discrete evalua-tion nodes do not need to be partitioned, becauseevery discrete component consists of exactly one dis-crete node. Dependent of the current discrete state,transitions are checked for activation and, as the casemay be, are fired in this evaluation node.

Similar to the implementation of a basic continuouscomponent, a discrete component consists of a methodevalDiscrete(). It has no nodeId parameter as it con-sists of exactly one evaluation node. Furthermore, itconsists of an attribute current indicating the currentdiscrete state.e Inside the evalDiscrete() method,

there is a check, in dependent on the current discretestate, if transitions are triggered. In case of some trig-gered transitions, one is selected, its side effects are exe-cuted and the discrete state is changed. This applicationflow is displayed in Figure 22.

4.3.3. Hybrid hierarchical components. When thecontroller is embedded into a well-known configuration(that defines the external coupling of the single control-lers), the algorithm is applied again to partition theconfiguration. The algorithm does not consider thesingle algebraic expressions, but just the nodes fromthe reduced evaluation graphs of the single component.

Figure 23(a) shows the configuration of theSemiComfort state from Figure 7 (see Figure 4(b)).The partitioning results in the reduced evaluationgraph of Figure 23(b). Partitioning of the other config-urations of Figure 7 (see Figures 4(a) and (c)) is per-formed similarly. Thus, each of the three discrete statesof the BC component is associated with another reducedevaluation graph.

As shown in Figure 10, the configuration that isassociated with a discrete state does not have to consistexclusively of continuous components, but may alsoconsist of hybrid components. These hybrid compo-nents are in a specific discrete state in this configura-tion. Then the partitioning algorithm works on the

(a)

(b)

Figure 20. (a) Evaluation node structure and (b) reduced eval-

uation graph of a P and a PIDT1 controller.

Figure 21. Activity diagram of the evalCont(int nodeId)

method of a P and a PIDT1 controller.

dP denotes proportional controller.eIn the case of a flat automata model, current is usually a simpledata type, such as int. In a statechart model with hierarchical andorthogonal states it is of a more complex type.

Giese et al. 791

reduced evaluation graphs of the appropriate discretestates.

When evaluating the discrete evaluation nodes ofhierarchical components, we have to make sure that achange at the top-level component affects the subordi-nated components within the same execution cycle.Therefore, the discrete nodes of the components at ahigher hierarchy level must be evaluated prior to thoseat the lower hierarchy levels.

An implementation of the hybrid hierarchical com-ponents, such as BC, consists of the methodsevalCont(int nodeId) and evalDiscrete(). Thesemethods call the corresponding methods of the embed-ded components. Therefore, the hierarchical compo-nent needs to have references to these components.Figure 24 displays this structure using a UML objectdiagram for the BC component.

The implementation of the evalCont(int nodeId)

method of a hybrid hierarchical component differsfrom that of a basic continuous component. It doesnot contain the direct code but sequences of functioncalls to evaluate the continuous nodes of the embedded(basic continuous or hybrid hierarchical) components.These lists are dependent on the current discrete state.Figure 25 shows the content of the evalCont(int

nodeId) method of BC as an activity diagram.Independent of the current discrete state, each node(nd1 and ns1) consists of a different list of evaluationnodes of embedded components. If, for example, thecomponent is in state SemiComfort, the node nd1 willconsist of three sequential calls of the nodes nd0 from Pcontroller p1, block nd0 from PIDT1 controller body2,and block nd0 from PIDT1 controller car2. As thenumber of states and nodes is finite (also in a concrete

situation during runtime), the list of evaluation nodes isfinite and, therefore, the algorithm terminates.

Note that the evaluation nodes of the embeddedcomponents, which are executed when nd1 or ns1 is eval-uated, are determined by the partitioning algorithm asshown in Figure 23. These nodes of the subordinatedcomponents are the nodes from their correspondingreduced evaluation graphs. Thus, no knowledge aboutthe internal node structure of the embedded compo-nents is required inside BC.

The discrete evaluation node of BC is the node pre-sented in Figure 22. As BC embeds only basic continu-ous components, no other discrete nodes have to beevaluated.

Figure 26 shows the implementation of theevalCont(int nodeId) method of the Monitor com-ponent in the form of an activity diagram. Owing to alack of space we do not show that a Monitor instancereferences the embedded sensor and actuator compo-nents and the BC component (similar to Figure 24).Because Monitor is a self-contained component, it con-sists of exactly one continuous evaluation node nd2.This node is periodically evaluated at runtime.

4.4. Flexible reconfigurable hierarchicalhybrid systems

For the flexible reconfiguration behavior the earlieroutlined dataflow integration can be used. At runtimethe evaluation graphs are computed (as distinguishedfrom the static approach in the last section). The eval-uation graphs are traversed to determine the next pos-sible node to evaluate. While this results in a rather badperformance, as long as only small parts of the systemare executed under this regime the performance draw-back can be more than compensated for by the gainedflexibility. The cause is that flexibility is the key enablerfor self-* properties (such as self-adaption or self-optimization).

To also extend our modular evaluation scheme toflexible reconfiguration scenarios where we cannotencapsulate the externally relevant evaluation blocksupfront, we have to combine our scheme with the data-flow integration concept. For such a combination, inaddition to the local execution logic, we have to distin-guish whether the component (controller) is embeddedinto another reconfigurable component which is flexibleor not.

1. Combine flexible reconfigurable components. If a flex-ible reconfigurable component is embedded byanother flexible reconfigurable component, wesimply have to arrange for that dataflow propaga-tion to also happen across the componentboundaries.

BC::evalDiscrete() : void

[current == SemiComfort]

[current == Robust]

[current == Comfort]

...

if (queue.isAvailable(eventZRefOk)) {...}...

if (queue.isAvailable(eventZAbsOk)) {...}...

if (queue.isAvailable(eventZAbsFailure)) {...}[else]

[else]

[else]

Figure 22. Activity diagram of the evalDiscrete() method

of BC.


2. Embedding a component with interface statechart. Inthe case that a non-flexible reconfigurable compo-nent is embedded by a flexible reconfigurable com-ponent, we simply have to consider the evaluationblocks provided by the embedded component inits interface as nodes in the dataflow propagation.This results in an at runtime-computed evaluationorder which respects what the embedded componentoffers. It should be noted that the efficiency ofthe modular execution of the embedded componentis not affected at all by the less-efficient processingof the embedding component. Therefore, unlesslarge parts of the system follow the flexible schemewe do not observe any relevant performanceproblems.

3. Embedded by a non-flexible reconfigurable compo-nent. If we in contrast have the case that a non-flexible reconfigurable component embeds a flexiblereconfigurable component, we have to face the

problem that the non-flexible reconfigurable compo-nent requires information about the evaluation ofthe embedded component which cannot be providedoffline. One option is to simply use a predefinedinterface for the flexible reconfigurable componentwhich can then be used by the non-flexible reconfi-gurable component to follow the usual modular exe-cution scheme. This, however, requires that allflexible reconfiguration steps within the flexiblereconfigurable component respect the constraint pre-sent due to the interface. Therefore, after each con-figuration step this crucial constraint has to bechecked at runtime. Alternatively, the non-flexiblereconfigurable component can be switched to con-trol the evaluation in the dataflow manner.However, the interface of the non-flexible reconfi-gurable component then requires that for thewhole set of components employing together a data-flow evaluation scheme after each configuration stepthe constraint implied by the interface has to bechecked at runtime.

5. Prevent critical runtime failures

As outlined in more detail by Giese and Hirsch,54, wecan support the correct development of reconfigurablehybrid systems based on the introduced modular exe-cution scheme. This support at first has to exclude acy-clic global evaluation graphs to ensure the propermodular execution of the continuous parts. In addition,the correct real-time behavior of the discrete reconfi-guration steps has to be ensured. In addition, we dis-cuss means to also cover flexible reconfiguration usingruntime checks.

(a)

(b)

Figure 23. Configuration and reduced evaluation graph of the semi-comfort controller.

embedsembeds embeds embeds

embeds

bc:BC

current : State

evalCont(int nodeId) : voidevalDiscrete() : void

embeds embeds

p2:Pp1:P

fader:Fader

embeds

car1:PIDT1

body2:PIDT1

body1:PIDT1

car3:PIDT1

car2:PIDT1

Figure 24. Object structure at runtime (cut-out).

Giese et al. 793

5.1. Static analysis for reconfiguration

In this section we present two ways to prove that thereconfiguration behavior, specified for a hierarchicalparallel composed component, is a refinement of thenon-composed component. First, we present a syntacticcheck which is applicable in many cases (see AppendixA.3 for a detailed formalization). If this check is notapplicable, we apply model checking to prove therefinement.

5.1.1. Syntactic checks. Checking the refinementrelation simply requires answering the following threequestions:

1. Are the implied state changes possible, i.e. does thereexist a transition from the source state of the subor-dinated component to the target state?

2. Do the temporal requirements of this transition con-tradict the temporal requirements of the superordi-nated component?

Figure 25. Activity diagram of the evalCont(int nodeId) method of BC.

Figure 26. Activity diagram of the evalCont(int nodeId) method of Monitor.


3. Can the transition of the subordinated componentbecome triggered simply by raising events?

The answer to question (3) determines whether thesyntactic checks are applicable: if the transition of thesubordinated component is simply associated with asignal and if the guard and the time guard are true,the reconfiguration is simply executed by raising theappropriate signal. Otherwise, a complex analysis isrequired to determine whether raising the signal willlead to a correct reconfiguration in all cases. This anal-ysis is done by model checking as presented in thefollowing.

Obviously, the first question is answered posi-tively if the third question is answered positively.In order to prove that the temporal specificationsare not contradictory, the deadlines simply need tobe regarded: the deadline interval dsub of the subordi-nated component needs to be a subset of the deadlineinterval dsup of the superordinated component,dsub� dsup.

5.1.2. Model checking. The model checking hasto prove whether a parallel composition of the compo-nents may lead to an undefined state combination. Aswe first apply the syntactic checks where possible, modelchecking just needs to be applied if complex analysis isrequired to obtain the information if a transition of asubordinated component can be triggered just by rais-ing the corresponding signal.

As the interface state charts are regarded on thislevel of abstraction instead of the detailed behavior,specified by the corresponding hybrid reconfigurationchart, the complexity of this verification step is signifi-cantly reduced as the approach requires not do verifythe complete system at all.

5.2. Runtime checking for flexible reconfiguration

As presented in Section 4.4, we can differ betweenthree scenarios for the flexible reconfiguration: (1) com-bine flexible reconfigurable components, (2) embeddinga component with an interface statechart, (3) embeddedby a non-flexible reconfigurable component. Whilecases (1) and (2) are straightforward, the embeddingof a flexible component in an inflexible solutionis problematic. In this case the coverage of offlinetechniques such as static analysis are rather limited.If the flexible reconfiguration rules only result in afeasible finite number of reachable configurations,we can map the resulting state space on our knowntechniques which enumerate the configurations andemploy the related offline analysis techniques.However, when the resulting number of configurations

is too large or even unbounded, only runtime checkingcan be used.

Depending on the case of combination for the flex-ible and non-flexible reconfigurable components andsize of the system which follows the dataflow schemedifferent schemes for the runtime checking becomeappropriate:

1. If we have a small part which is executed using thedataflow scheme, it is feasible to check the requiredconstraints when a flexible reconfiguration hasoccurred. Using a double buffering for the configu-ration management, the detection can then be usedto rollback the configuration and continue to executethe known well-formed configuration (see theshadow configuration of Alimi et al.55). Thisscheme, of course, requires that the initial configu-ration is well formed which can be checked offline.

2. In the case of larger parts which are executed usingthe dataflow scheme, it is often not feasible to checkthe required constraints when a flexible reconfigura-tion has happened. Instead, we can use known tech-niques to detect the problem during dataflowexecuting (see Section 2). However, this solutionobviously can result in a rather late detectionwhere no compensation is possible without losingat least one continuous evaluation cycle. If losingone cycle can be tolerated, a rollback to the formerconfiguration can resolve the problem. However,when no such degraded performance can be toler-ated, the application of the flexible dataflow schemeis simply not appropriate as we cannot exclude flex-ible reconfiguration steps leading to not well-formedcontinuous models.

We can summarize that the flexible reconfigurationscheme can only be used if either the real-time con-straints are rather relaxed or when due to the smallsize of the configurations the runtime checks can beperformed before activating a configuration.

6. Tool support

In order to outline the achieved tool integration we firstdiscuss its realization and then outline the resultingcapabilities using the convoy building example. Wemainly focus on the hybrid aspects and not on the flex-ible reconfiguration as this shows well the completeapproach from modeling via code generation to simu-lation. The flexible reconfiguration, as mentioned inSection 3, would especially help to support the flexibleevolution of the system in cases where we cannot stat-ically model all possible reconfigurations of the systemupfront.

Giese et al. 795

6.1. Tool integration

The presented seamless approach is realized by theFujaba Real-Time Tool Suite. We integrate theFujaba Real-Time Tool Suite with the CAE ToolCAMeL-View and, therefore, use the ability ofCAMeL-View to generate code. As shown inFigure 27 both tools export hybrid components,which are integrated into a hierarchical model as aninput for the binding tool. The export of the toolsincludes already the transformations of the model for-malism to a code formalism, such as Cþþ. Afterward,the binding tool combines the inputs and, therefore,combines both formalisms.

The core of the tool is our MECHATRONIC UMLapproach. The specific characteristic is that all above-mentioned formalisms are combined by only one meta-model which becomes possible by a well-defined unionof all formalisms.

In Figure 28 a cut-out of the MECHATRONIC UMLmeta-model is depicted. Both the time-continuousbehavior and structure as well as the continuous con-trol behavior and structure are integrated into onemeta-model. This is reflected in the figure byContinuousComponent and DiscreteComponent.Furthermore, the hybrid class (HybridComponent andthe port classes ContinuousPort and DiscretePort.

HybridRoconfigurationChart

Component

HybridComponent

ContinuousComponent

evalCont (phase : integer, t:ReaI, h:ReaI, nodelD:lnteger): Void

evalCont (phase : integer, t:ReaI, h:ReaI, nodelD:lnteger): VoidevalDiscrete () : Void

portID : Integer

ContinuousPort

DiscretePort

sendEvent (event : Event) : Void

evalCont (phase : integer, t:ReaI, h:ReaI, nodelD:lnteger): Void

index : integer

evalDiscrete () : Void

Figure 28. Cut-out of MECHATRONIC UML meta-model.

Figure 27. Tool integration overview.56


The MECHATRONIC UML approach applies model-driven development to develop software systems at ahigh level of abstraction to enable analysis approachessuch as model checking57 as shown in Section 5.Therefore, ideally, we start with platform-independentmodels as shown in Section 3 to enable the composi-tional formal verification. Afterwards, the platform-independent model must be enhanced withplatform-specific information to enable code genera-tion. The required platform-specific information isbased on a platform model, which specifies theplatform-specific worst-case execution times.Furthermore, we add platform-specific informationsuch as priorities, periods, and deadlines to themodels. After specifying the platform-specific informa-tion we can generate code from the models by consid-ering the modular execution approach as presented inSection 4. We therefore apply three different models ofabstraction, such as the Model-Driven Architecture(MDA), with conformable transformations.

6.2. Structural modeling

We use the Fujaba Real-Time Tool Suite for modelingthe architecture. Figures 29 and 30 show a cutout of theinternal structure of Shuttle. Similar to the Shuttlecomponent, which is composed of multiple other com-ponent instances, the types of the subordinated

instances are defined by further compositions. Thisleads to an architectural description of Shuttle, con-sisting of multiple layers.

6.3. Behavioral modeling

After modeling the structure of the shuttle convoyexample, we specify the behavior of each component.We first show the specified discrete real-time behavior,on the level of the real-time coordination patterns andthe individual discrete components which are modeledby the Fujaba Real-Time Tool Suite. The Shuttle’s sta-techart realizes the discrete real-time coordination andit embeds, among other things, an instance of thehybrid component DriveTrain. The coordinationleads to state changes, indicating whether the shuttleis part of the convoy and whether it is the leading shut-tle of the convoy. Each of these states is associated witha different configuration where the DriveTrain

instance is in different states. Therefore, a statechange of shuttle implies a state change ofDriveTrain which implies a state change ofAccelerationControl. This models reconfigurationvia multiple hierarchical levels.

Figure 31 shows a hybrid reconfiguration chart thatdescribes the behavior of the AccelerationControl

component. It consists of three discrete states: thestates VelocityControl, PositionControl, orPositionControlWithPilotControl are associated

Figure 29. Structure of Shuttle.

Giese et al. 797

Figure 30. Structure of DriveTrain.

Figure 31. Hybrid reconfiguration chart of AccelerationControl with fading transitions.


with the continuous controller component configura-tions which have been sketched previously.

6.4. Simulation and runtime

As a prerequisite for simulation we require the exclu-sion of deadlock caused by reconfiguration. In mostcases the required refinement relation can be guaran-teed following outlined static analysis (see Section 5). Inseveral more complex cases, model checking for timedautomata can be used54,58 to check the refinement.f

After having checked the prerequisite, we generateCþþ code from our model as described in Section 6.1for a PC platform. After code generation and compila-tion, we show the behavior of the system using a

simulation environment of the CAE Tool CAMeL-View. Figure 32 (simple convoy) shows two shuttlesin a convoy (bottom-right window). In the upper-left-hand plot the acceleration of the first and second shut-tle is shown. In the upper-right-hand plot the positionsof the shuttles are shown. In the bottom-left plot thereference values for the second shuttle are shown.

7. Conclusion and future work

The presented modular execution approach enables themodular execution of reconfigurable hybrid compo-nents. This is achieved by an expressive interface con-cept which ensures the proper handling of theembedded components using their reduced evaluationgraph. The approach combines the advantage of thewhite-box scenario that works for any model withoutalgebraic loops while avoiding its disadvantages such asmonolithic execution logic and exponentially manyevaluation orders in the case of large hybrid systems.Moreover, we have presented how even more flexible

Figure 32. Simulation environment.

fIf a complex interplay exists between the continuous and discretebehavior this would require the reachability analysis for the generalform of hybrid systems which is undecidable.59 Thus, we cannotexpect to find an automatic solution for the general problem.However, the developed techniques cover most relevant cases forMECHATRONIC UML.

Giese et al. 799

rule-based reconfiguration can be combined with thescheme.

We have also presented how this modular executionscheme for reconfigurable hybrid systems could be fur-ther supported. We have presented static analysis andverification techniques which guarantee that the recon-figuration itself does not result in undesired effects suchas blocked or delayed reconfiguration steps. In addi-tion, we have presented the tool integration betweenFujaba and CAMeL-View which is based on the pre-sented modular execution schemes effectively integratedmodels of both tools via a shared notion of a hybridcomponent with modular execution capabilities. Wehave finally presented how the resulting reconfigurablehybrid models can be simulated and visualized withinthe CAMeL-View tool for validation purposes. Thisapproach is currently evaluated by an industrial appli-cation (as a first step, the approach is implemented inan industrial tool).

The flexible methods for reconfiguration were verysuccessful when applied in first evaluations by studentsin the form of master theses and other student projectsusing the RailCab project.60 We have also presented61

an appropriate worst-case execution approach for flex-ible reconfigurations. The formal verification of flexiblereconfigurations is taken into account by Hirsch andco-workers.62,63

In the future, we plan to further develop more sup-port in particular for the flexible methods for reconfi-guration. Also, the handling of the intertwinedexecution of the continuous and discrete parts can befurther improved. The discrete statecharts often permitlonger reaction times and require longer executiontimes than the continuous evaluation nodes.Therefore, the discrete parts do not have to be evalu-ated in every cycle and we might be able to optimize theoverall performance by means of a clever schedule.

Acknowledgments

The authors wish to thank all of the students who worked onthe project. In particular, we thank Sven Burmester for his

substantial contributions and Tobias Eckardt for proof-read-ing. We further thank the reviewers for their detailed and help-ful comments that helped to improve the paper considerably.

This work was developed in the course of the Special

Research Initiative 614—Self-optimizing Concepts andStructures in Mechanical Engineering—University ofPaderborn, and was published on its behalf and funded by

the Deutsche Forschungsgemeinschaft.

References

1. Heimann B, Gerth W, and Popp K. Mechatronik:

Komponenten, Methoden, Beispiele. Munchen/Wien:

Fachbuchverlag Leipzig im Carl Hanser Verlag, 2001.

2. Zanella MC, Stolpe R. Distributed HIL simulation of

mechatronic systems applied to an agricultural machine.

DIPES ’98: Proceedings of the IFIP WG10.3/WG10.5

International Workshop on Distributed and Parallel

Embedded Systems. Norwell, MA: Kluwer Academic,

1999, p.107–116.3. Mosterman PJ, Vangheluwe H. Computer automated

multi-paradigm modeling: an introduction. Journal on

Simulation 2004; 80: 433–450.

4. RailCab. The ‘‘Rail Technology’’ challenge. RailCab

Project Homepage 2004. http://nbp-www.upb.de/en/

concept/challenge.php5. Transrapid. http://www.transrapid.de/en/index.html6. Biernacki D, Colaco JL, Hamon G, and Pouzet M.

Clock-directed modular code generation for synchronous

data-flow languages. SIGPLAN Notices 2008; 43:

121–130.7. Colaco JL, Girault A, Hamon G, and Pouzet M.

Towards a higher-order synchronous data-flow language.

In: EMSOFT ’04: Proceedings of the 4th ACM

International Conference on Embedded Software, Pisa,

Italy. New York. ACM Press, 2004, p.230–239.

8. Colaco JL, Pagano B, and Pouzet M. A conserva-

tive extension of synchronous data-flow with

state machines. In: EMSOFT ’05: Proceedings of the

5th ACM International Conference on Embedded

Software, Jersey City, NJ. New York. ACM Press,

2005, p.173–182.9. Delaval G, Girault A, and Pouzet M. A type system for

the automatic distribution of higher-order synchronous

dataflow programs. In: LCTES ’08: Proceedings of the

2008 ACM SIGPLAN-SIGBED Conference on

Languages, Compilers, and Tools for Embedded Systems,

Tucson, AZ. New York. ACM Press, 2008, p.101–110.10. Lublinerman R, Szegedy C, and Tripakis S. Modular

code generation from synchronous block diagrams:

Modularity vs. code size. In: POPL ’09: Proceedings of

the 36th Annual ACM SIGPLAN-SIGACT Symposium on

Principles of Programming Languages. Savannah, GA.

New York: ACM Press, 2009, p.78–89.11. Lublinerman R, Tripakis S. Modularity vs. reusability:

Code generation from synchronous block diagrams.

In: DATE ’08: Proceedings of the Conference on Design,

Automation and Test in Europe, Munich, Germany. New

York. ACM Press, 2008, p.1504–1509.12. Burmester S, Giese H, and Tichy M. Model-driven devel-

opment of reconfigurable mechatronic systems with

mechatronic uml. In: Assmann U, Rensink A, and

Aksit M (eds) Model Driven Architecture: Foundations

and Applications Lecture Notes in Computer Science.

Vol. 3599, Berlin: Springer, 2005, p.47–61.13. Giese H, Henkler S, Hirsch M, Roubin V, and Tichy M.

Modeling techniques for software-intensive systems.

In: Tiako DPF (ed.) Designing Software-Intensive

Systems: Methods and Principles. Langston University,

2008, p.21–58.

14. Object Management Group (2003) UML 2.0

Infrastructure Specification. Document ptc/03-09-15,

Object Management Group


15. Object Management Group (2003) UML 2.0

Superstructure Specification. Document ptc/03-08-02,

Object Management Group

16. Giese H, Burmester S, Schafer W, and Oberschelp O.

Modular design and verification of component-based

mechatronic systems with online-reconfiguration. In:

Proceedings of 12th ACM SIGSOFT Foundations of

Software Engineering 2004 (FSE 2004). Newport

Beach. New York: ACM Press, 2004, p.179–188.

17. Giese H, Tichy M, Burmester S, Schafer W, and Flake S.

Towards the compositional verification of real-time uml

designs. In: Proceedings of the 9th European Software

Engineering Conference held jointly with 11th ACM

SIGSOFT International Symposium on Foundations of

Software Engineering (ESEC/FSE-11), Helsinki,

Finland. New York. ACM Press, 2003, p.38–47.18. Burmester S, Giese H, Munch E, Oberschelp O, Klein F,

and Scheideler P. Tool support for the design of self-

optimizing mechatronic multi-agent aystems. Int J

Softw Tools Technol Transf 2008; 10: 207–222.19. Henkler S, Hirsch M. A multi-paradigm modeling

approach for reconfigurable mechatronic systems.

In: Proceedings of the International Workshop on Multi-

Paradigm Modeling: Concepts and Tools (MPM06),

Satellite Event of the 9th International Conference on

Model-Driven Engineering Languages and Systems

MoDELS/UML2006, Genova, Italy (BME-DAAI

Technical Report Series. Vol. 2006/1, Budapest

University of Technology and Economics, 2006, p.15–25.20. Burmester S, Giese H, Gambuzza A, and Oberschelp O.

Partitioning and modular code synthesis for reconfigur-

able mechatronic software components. In: Bobeanu C

(ed.) Proceedings of European Simulation and Modelling

Conference (ESMc’2004), Paris, France. EOROSIS

Publications, 2004, p.66–73.21. Burmester S, Giese H, and Oberschelp O. Hybrid UML

components for the design of complex self-optimizing

mechatronic systems. In: Araujo H, Vieira A, Braz J,

Encarnacao B, and Carvalho M (eds) Proceedings of 1st

International Conference on Informatics in Control,

Automation and Robotics (ICINCO 2004), Setubal,

Portugal. INSTICC Press, 2004, p.222–229.22. Oberschelp O, Gambuzza A, Burmester S, and Giese H.

Modular generation and simulation of mechatronic sys-

tems. In: Callaos N, Lesso W, and Sanchez B (eds)

Proceedings of the 8th World Multi-Conference on

Systemics, Cybernetics and Informatics (SCI), Orlando,

FL. International Institute of Informatics and Systemics

(IIIS), 2004, p.1–6.

23. Fujaba. http://www.fujaba.de24. CAMeL-View. http://www.ixtronics.com25. Burmester S, Giese H, Henkler S, Hirsch M, Tichy M,

Gambuzza A, et al. Tool support for developing

advanced mechatronic systems: Integrating the Fujaba

Real-Time Tool Suite with CAMeL-View.

In: Proceedings of the 29th International Conference on

Software Engineering (ICSE), Minneapolis, MN. Los

Alamitos, CA. IEEE Computer Society Press, 2007,

p.801–804.

26. MATLAB/Simulink and Stateflow. http://www.mathworks.com

27. Mosterman PJ, Biswas G. Modeling discontinuous beha-

vior with hybrid bond graphs. In: Proceedings of theInternational Conference on Qualitative Reasoning,Amsterdam, the Netherlands. 1995, p.139–147.

28. Alur R, Dang T, Esposito JM, et al. Hierarchical

hybrid modeling of embedded systems. EMSOFT ’01:Proceedings of the First International Workshop onEmbedded Software. London: Springer, 2001, p.14–31.

29. Kratz F, Sokolsky O, Pappas GJ, and Lee I. R-charon, amodeling language for reconfigurable hybrid systems. In:Hybrid Systems: Computation and Control (Lecture Notes

in Computer Science, Vol. 3927). Berlin: Springer, 2006,p.392–406.

30. Bender K, Broy M, Peter I, Pretschner A, and Stauner T.

Model based development of hybrid systems. Modelling,Analysis, and Design of Hybrid Systems (Lecture Notes onControl and Information Sciences, Vol. 279). Berlin:Springer, 2002, p.37–52.

31. Stauner T, Pretschner A, and Peter I. Approaching adiscrete-continuous UML: Tool support and formaliza-tion. In: Proceedings UML’2001 Workshop on Practical

UML-Based Rigorous Development Methods—Counteringor Integrating the eXtremists. Toronto, Canada: 2001,p.242–257.

32. Grosu R, Stauner T, and Broy M. A modular visualmodel for hybrid systems. In: FTRTFT ’98: Proceedingsof the 5th International Symposium on Formal Techniquesin Real-Time and Fault-Tolerant Systems. London:

Springer, 1998, p.75–91.33. Stauner T. Systematic Development of Hybrid Systems.

PhD thesis. Germany: Technische Universitat Munchen,

2001.34. Berkenkotter K, Bisanz S, Hannemann U, and Peleska J.

Executable hybrid UML and its application to train con-

trol systems. In: Ehrig H, Damm W, Desel J, et al. (eds)Integration of Software Specification Techniques forApplications in Engineering (Lecture Notes in Computer

Science, Vol. 3147). Berlin: Springer, 2004, p.145–173.35. Liu X, Xiong Y, and Lee EA. The Ptolemy II framework

for visual languages. In: Proceedings of the IEEE 2001Symposia on Human Centric Computing Languages and

Environments (HCC’01). Stresa, Italy: 2001, p.50–51.36. Friesen V, Nordwig A, and Weber M. Object-oriented

specification of hybrid systems using UMLH and

Zimoo. In: Proceedings of the 11th InternationalConference of Z Users on the Z Formal SpecificationNotation, Berlin, Germany (Lecture Notes in Computer

Science,, Vol. 1493), Berlin. Springer, 1998, p.328–346.37. Object Management Group (2005) Systems Modeling

Language (SysML) Specification, Object ManagementGroup

38. Kobryn C. Expertr’s voice: UML 3.0 and the future ofmodeling. Software and Systems Modeling 2004; 3: 4–8.

39. Honekamp U. IPANEMA—Verteilte Echtzeit-

Informationsverarbeitung in mechatronischen Systemen.PhD thesis. Germany: University of Paderborn, 1998.

40. Mosterman P. Hybrsim—a modeling and simulation

environment for hybrid bond graphs. Journal of

Giese et al. 801

Systems and Control Engineering—Part I 2002; 216:

35–46.

41. Homburg C. Entwurf und implementierung einer standar-

disierten beschreibungsform mechatronischer systeme.

Master’s thesis. Germany: University of Paderborn, 1993.42. ADAMS. http://www.adams.com43. SIMPACK. http://www.simpack.com

44. Hahn M. OMD—Ein Objektmodell fur den

Mechatronikentwurf. Anwendung in der objektorientierten

Modellbildung mechatronischer Systeme unter

Verwendung von Mehrkorpersystemformalismen

(Fortschritt-Berichte VDI, Reihe 20, Nr. 299).

Dusseldorf: VDI Verlag, 1999.45. Malik S. Analysis of cyclic combinational circuits.

In: ICCAD ’93: Proceedings of the 1993 IEEE/ACM

International Conference on Computer-aided Design,

Santa Clara, CA,. Los Alamitos, CA. IEEE Computer

Society Press, 1993, p.618–625.

46. Edwards SA, Lee EA. The semantics and execution of a

synchronous block-diagram language. Sci Comput

Program 2003; 48: 21–42.47. Lee EA, Zheng H. Leveraging synchronous language

principles for heterogeneous modeling and design of

embedded systems. In: EMSOFT ’07: Proceedings of the

7th ACM & IEEE international Conference on Embedded

Software, Salzburg, Austria. New York. ACM Press,

2007, p.114–123.48. Caspi P, Pilaud D, Halbwachs N, and Plaice JA. Lustre:

A declarative language for real-time programming.

POPL ’87: Proceedings of the 14th ACM SIGACT-

SIGPLAN Symposium on Principles of Programming

Languages. Munich, West Germany. New York: ACM

Press, 1987, p.178–188.

49. Berry G, Cosserat L. The Esterel Synchronous

Programming Language and its mathematical semantics.

In: Seminar on Concurrency. Carnegie-Mellon University,

London: Springer, 1985, p.389–448.50. Burmester S, Giese H. The Fujaba real-time statechart

plugin. In: Giese H, Zundorf A (eds) Proceedings of the

First International Fujaba Days 2003. Kassel, Germany:

(Technical Report TR-RI-04-247) University of

Paderborn, 2003, p.1–8.

51. Oberschelp O, Gambuzza A, Burmester S, and Giese H.

Modular generation and simulation of mechatronic sys-

tems. In: Callaos N, Lesso W, and Sanchez B (eds)

Proceedings of the 8th World Multi-Conference on

Systemics, Cybernetics and Informatics (SCI), Orlando,

FL. International Institute of Informatics and Systemics

(IIIS), 2004, p.1–6.52. Kohler HJ, Nickel UA, Niere J, and Zundorf A.

Integrating UML diagrams for production control sys-

tems. In: Proceedings of the 22nd International

Conference on Software Engineering (ICSE), Limerick,

Ireland. New York. ACM Press, 2000, p.241–251.53. Oberschelp O, Homburg C, Deppe M, Gambuzza A, and

Seuss J. Verarbeitungsorientierte darstellung verteilter

hybrider systeme der mechatronik. In: 5. Magdeburger

Maschinenbautage. Magdeburg: Otto-von-Guericke-

Universitat, 2001, p.22–34.

54. Giese H, Hirsch M. Checking and automatic abstraction

for timed and hybrid refinement in mechtronic UML.

Technical Report TR-RI-03-266, Software Engineering

Group. Paderborn, Germany: University of Paderborn,

2005.55. Alimi R, Wang Y, and Yang YR. Shadow configuration

as a network management primitive. In: SIGCOMM ’08:

Proceedings of the ACM SIGCOMM 2008 Conference on

Data Communication, Seattle, WA. New York. ACM

Press, 2008, p.111–122.56. Burmester S, Giese H, and Klein F. Design and simula-

tion of self-optimizing mechatronic systems with fujaba

and CAMeL. In: Schurr A, Zundorf A (eds) Proceedings

of the 2nd International Fujaba Days 2004. Darmstadt,

Germany: University of Paderborn, 2004, p.19–22

(Technical Report TR-RI-04-253).57. Burmester S, Giese H, and Schafer W. Model-

driven architecture for hard real-time systems: From

platform independent models to code. In: Proceedings

of the European Conference on Model Driven

Architecture—Foundations and Applications (ECMDA-

FA’05), Nurnberg, Germany (Lecture Notes in Computer

Science, Vol. 3748), Berlin. Springer, 2005, p.25–40.58. Giese H, Hirsch M. Modular verification of safe online-

reconfiguration for proactive components in mechatronic

UML. In: Satellite Events at the MoDELS 2005

Conference (Lecture Notes in Computer Science,

Vol. 3844), Berlin. Springer, 2006, p.67–78.

59. Henzinger TA, Kopke PW, Puri A, and Varaiya P.

What’s decidable about hybrid automata?. Journal of

Computer and System Sciences 1998; 57: 94–124.

60. Henkler S, Breit M, Brink C, et al. fritsCab: Fujaba

re-engineering tool suite for mechatronic systems.

In: Gorp PV (ed.) Proceedings of the 7th International

Fujaba Days. Eindhoven University of Technology,

2009, p.25–29.61. Henkler S, Oberthur S, Giese H, and Seibel A. Model-

driven runtime resource predictions for advanced mecha-

tronic systems with dynamic data structures. In:

Proceedings of 13th International Symposium on Object/

Component/Service-oriented Real-time Distributed

Computing (ISORC). Los Alamitos, CA: IEEE

Computer Society Press, 2010, p.202–209.

62. Hirsch M, Henkler S, and Giese H. Modeling collabora-

tions with dynamic structural adaptation in mechatronic

UML. In: SEAMS ’08: Proceedings of the 2008

International Workshop on Software Engineering for

Adaptive and Self-managing Systems. New York: ACM

Press, 2008, p.33–40.

63. Henkler S, Hirsch M, Priesterjahn C, and Schafer W.

Modeling and verifying dynamic communication struc-

tures based on graph transformations. In: Proceedings

of the Software Engineering 2010 Conference,

Paderborn, Germany. 2010.64. Lynch N, Segala R, and Vaandrager F. Hybrid I/O auto-

mata revisited. In: Benedetto MDD, Sangiovanni-

Vincentelli A (eds) Proceedings of Hybrid Systems:

Computation and Control, Fourth International

Workshop (HSCC’01), Rome, Italy, (Lecture Notes in


Computer Science, Vol. 2034). Berlin: Springer, 2001,p.403–417.

65. Burmester S, Giese H, and Oberschelp O. Hybrid UML

components for the correct design of self-optimizing mecha-tronic systems. Technical Report TR-RI-03-246, SoftwareEngineering Group. Paderborn, Germany: University ofPaderborn, 2004.

66. Henzinger TA, Ho P-H, and Wong-Toi H. Hytech: Thenext generation. In: Proceedings of the 16th IEEE Real-Time Symposium. Los Alamitos, CA: IEEE Computer

Society Press, 1995, p.56–65.67. Burmester S, Giese H, and Hirsch M. Syntax and seman-

tics of hybrid components. Technical Report TR-RI-05-

264, Software Engineering Group. Paderborn, Germany:University of Paderborn, 2005.

A. Syntax and semantics

A.1. Prerequisites

First, we have to define the employed basic mathema-tical notation.

We use R to denote the set of the real numbers, N0 todenote the natural numbers including 0, [a, b] with a,b2A and a� b to denote the interval of all elementsc2A with a� c� b, +(A) to denote the power set of A,and [A!B] and [A*B] to denote the set of totalresponse partial functions from A to B. EQ(Vl,Vr)denotes the set of all equations of the formvl ¼ f iðv1r , . . . ,vnr Þ with operations f i of arity n and left-and right-hand side variables of the equationvl 2Vl, v

1r , . . . ,vnr 2Vr. COND(V) denotes the set of all

conditions over variables of V. The set of possibleoperations and constants is named OP.

As a special case we assume a set of operations {oi}which do not explicitly define for an equationvl ¼ ?iðv

1r , . . . ,vnr Þ any specific restrictions on the rela-

tion between the input and output trajectories. The setof all of these operations is denoted by OPo. The set ofonly fully deterministic input/output operations aredenoted by OPdet.

Other than the vector equations usually used by con-trol engineers, we use a set of variables V to denote eachsingle value and describe the mapping by a function[V!R]. All values of a vector of the length n can berepresented in a similar fashion as [[0, n]!R].

Here f� g further denotes the composition of thetwo functions f : A1!B1 and g : A2!B2 with disjointdefinition sets A1\A2¼; defined by (f� g)(x) equalsf(x) for x2A1 and g(x) for x2A2. The combination oftwo updates a1� a2 further denotes the compositionof the two functionals a1 : ½A1! B1 ! ½A

01! B01

and a2 : ½A2! B2 ! ½A02! B02 with disjoint

sets A1\A2¼; and A01 \ A02 ¼ ; defined by

(a1� a2)(x� y) :¼ a1(x)� a2(y).A directed graph is defined as a pair (N, E) with N a

finite set of vertices and E�N�N. We write n! n0 if

(n, n0)2E and extend this to sequences of transitionssuch that n!* n

0 if exists k 0 and n0, . . . , nk2N suchthat n0¼ n, nk¼ n0, and for all 0� i� k� 1 holdsni! niþ1. If!* is irreflexive (`nwithn!* n) the direc-ted graph is acyclic. For a graph G¼ (N, E) we have thefollowing additional defined terms: dout(n) :¼ j{n0 2N |

(n, n0)2E}j is the out-degree of node n, din(n) :¼ j{n0 2N|

(n0, n)2E}j is the in-degree of node n, Nout�N is thesubset of output nodes with 8n2Nout holds dout(n)¼ 0,and Nin�N is the subset of input nodes with 8n2Nout

holds din(n)¼ 0.

A.2. Integrated modeling

In this section, we consider the syntax and semantics ofthe different modeling approaches for the control andsoftware engineering domain and especially focus on anintegrated approach supporting reconfigurable hybridsystems. Further, we consider a flexible reconfigurationapproach which is required due to the evolution of thesystem.

A.2.1. Continuous modelsSyntax A continuous block provides a sufficient syn-tactical structure for the used concept of differentialequations. Its syntax is defined by Definition 1.

Definition 1. A continuous block M is described by a7-tuple (Vx, Vu, Vy, F, G, C, X0) with Vx the state vari-ables, Vu the input variables, and Vy the output variables.For the implicitly defined state flow variables V _x andauxiliary variables Va

¼Vy\Vu, the set of equations

F � EQðV _x [ Va,Vx [ Vu [ VaÞ describes the flow ofthe state variables, the set of equationsG�EQ(Vy

[Va, Vx[Vu

[Va) determines the outputvariables, and X0

� [Vx!R] is the set of initial states.

The invariant C with C2COND(Vx) is further used todetermine the set of valid states.

A blockM is only well formed when for the system ofdifferential equations F[G it holds that there are nocyclic dependencies, no double assignments, all unde-fined referenced variables are contained in Vu

�Vy, anda value is assigned to all state variables (V _x) and outputvariables (Vy).

We can compose two continuous models if theirvariable sets are not overlapping and the resulting setsof equations are well formed as follows.

Definition 2. The composition of two continuousmodels M1 ¼ ðV

x1,V

u1,V

y1,F1,G1,C1,X

01Þ and M2 ¼

ðVx2,V

u2,V

y2,F2,G2,C2,X

02Þ denoted by M1 k M2 is again a

continuous model M¼ (Vx, Vu, Vy, F, G, C, X0) withVx :¼ Vx

1 [ Vx2, Vu :¼ Vu

1 [ Vu2, Vy :¼ V

y1 [ V

y2, F :¼

F1[F2, G :¼G1[G2, C is derived from C1 and C2

as C¼ {(x1�x2) | x12C16 x22C2}, and the set

Giese et al. 803

of initial states is X0 ¼ fððl1, l2Þ, ðx1 � x2ÞÞjðl1, x1Þ 2X0

1 ^ ðl2, x2Þ 2X02g.

Here M1kM2 is well formed iff Vx1 \ V

x2 ¼ ;,

Vu1 \ V

u2 ¼ ;, V

y1 \ V

y2 ¼ ;, and F[G are well

formed. A composition is consistent if the resulting con-tinuous model is well formed.

Semantics The state space of a continuous behavioris X¼ [Vx

!R] which describes all possible assign-ments for the state variables. A trajectory �u:[0,1]! [Vx

!R] for the set of differential equationsF and input u : [0,1]! [Vu

!R] with �u(0)¼ x for thecurrent continuous state x2X and �u(t)2C for allt2 [0, 1] describes a valid behavior of the continuoussystem. The output variables Vy are determined by yu :[0, 1]! [Vy

!R] using G analogously. The semanticsfor a continuous modelM is given by all possible triplesof environment and system trajectories (u, �u, yu)denoted by [[M]].

A.2.2. Reconfigurable hierarchical hybridsystems. Before defining the syntax and semantics ofa hybrid reconfiguration automaton which can capturehybrid statecharts and interface statecharts, we definethe syntax and semantics of a standard hybrid automa-ton with static interfaces similar to hybrid I/Oautomata.64

Syntax The syntax of a hybrid automaton is definedby Definition 3.

Definition 3. A hybrid automaton is described by a6-tuple (L, D, I, O, T, S0) with L a finite set of locations,D a function over L which assigns to each l2L a con-tinuous model D(l)¼ (Vx, Vu, Vy, F(l), G(l), C(l), X0(l))(see Definition 1) with identical variable sets, I a finiteset of input signals, O a finite set of output signals, T afinite set of transitions, and a set of initial statesS0� {(l, x) | l2L6 x2X0(l)}. For any transition (l, g,

g0, a, l0)2T it holds that l2L is the source location,g2COND(Vx

[Vu) the continuous guard, g0 2+(I[O)the I/O guard, a2 [[Vx

!R]! [Vx!R]] the continuous

update, and l0 2L the target location. For every l2L werequire that D(l) is well formed.

Definition 4. The interface I(M) of a hybrid automatonM is defined as the external visible event sets and inputand output variables (I�O, O� I, Vu

�Vy, Vy�Vu).

Note that the presented definition of a hybrid auto-maton easily permits us to still employ the concepts ofreal-time statecharts such as clocks. We simply have todefine clock variables vi whose values are determined byequations _vi ¼ 1 in F to encode this feature into ahybrid automaton.

The parallel composition of two hybrid automata isdefined as follows.

Definition 5. For two hybrid automata M1 and M2

the parallel composition (M1kM2) results in a hybridautomaton M¼ (L, D, I, O, T, S0) with L¼L1�L2,D(l, l0)¼D1(l)kD2(l

0), I¼ I1[ I2, O¼O1[O2. Theresulting transition relation is T ¼ fððl1, l2Þ, g1^g2, g

i1 [ g

i2, ða1 � a2Þ, ðl

01, l02ÞÞ j ðl1, g1, g

i1, u1, l

01Þ 2T1^

ðl2,g2, gi2, u2, l

02Þ 2T2 ^ gi1 \ ðI2 [O2Þ ¼ gi2 \ ðI1 [O1Þg[

fððl1, l2Þ, g1, gi1, u1, ðl

01, l2ÞÞ j ðl1, g1, g

i1, u1, l

01Þ 2 T1 ^ gi1\

ðI2[O2Þ¼;g [ fððl1,l2Þ,g2,gi2,u2,ðl1,l

02ÞÞj ðl2,g2,u2,l

02Þ2

T2^gi2\ðI1[O1Þ¼;g. Here S0 is defined as S0

1�S02.

The automaton M is only well defined when for allreachable (l, l0)2L it holds that D((l, l0)) is well formedand the internal signal sets are disjoint((O1\I1)\(O2\I2)¼;). The composition of hybridautomata is only consistent when the resulting automa-ton is well defined.

If the set of equations is well formed for everylocation, it can be similar to the case of a continuousblock represented by a corresponding directedacyclic evaluation graph. In the case of compositionof two hybrid automata, we can derive the resultingdirected acyclic evaluation graphs for every combina-tion of locations by simply combining the graphs ofboth locations at the connected inputs and outputs. Ifthe composition is well formed, the resulting combinedgraphs are all acyclic. It should be noted that thenumber of considered evaluation graphs growsexponentially.

In order to abstract from signals, e.g. signals that areexchanged between automata, we define the hiding ofsignals as in Definition 6 which is taken from Burmesteret al.65

Definition 6. For a hybrid automaton M¼ (L, D, I, O,T, S0), the hiding of some signals A� I[O denoted byMnA is defined as the hybrid automaton M0 ¼ (L, D, I0,O0, T0, S0) with I0 ¼ I�A, O0 ¼O�A, and T0 ¼ {((l, g,gi�A, u, l)) | (l, g, gi, u, l))2T}.

Semantics For X¼ [Vx*R], the set of possible con-tinuous state variable bindings, the inner state of ahybrid automaton can be described by a pair (l,x)2L�X. There are two possible ways of state mod-ifications: either by firing an instantaneous transitiont2T changing the location as well as the state variablesor by residing in the current location which consumestime and alters just the control variables.

When staying in state (l, x), firing an instantaneoustransition t¼ (l 0, g, gi, a, l 00) is done iff:

. the transition’s source location equals the currentlocation, l¼ l 0;


. the continuous guard is fulfilled, g(x� u)¼ true foru2 [Vu

!R] the current input variable binding;. the I/O-guard is true for the chosen input and output

signal sets i� I and o�O, i[ o¼ gi; and. the continuous update still fulfills the invariant of

the target location a(x)2C(l 00).

The resulting state will be (l 00, a(x)) and we denote thisfiring by (l, x) !(i[o) (l

00, a(x)).Iff no instantaneous transition can fire, the hybrid

automaton resides in the current location l for anon-negative and non-zero time delay �> 0. Let �u:[0, �]! [Vx

!R] be a trajectory for the differentialequations F(l) and the external input u:[0, �]! [Vu

�Vy!R] with �u(0)¼ x. The state for all

t2 [0, �] will be (l, �u(t)). The output variables Vy�Vu

and internal variables Vy\Vu are determined by yu:

[0, �]! [Vy!R] using G(l) analogously. We addition-

ally require that for all t2 [0, �] holds that �u(t)2C(l).The trace semantics is thus given by all possible infi-

nite execution sequences ðu0, l0, �0u0, �0u0 , �0Þ !e0

ðu1, l1, �1u1, �1u1 ,�1Þ . . . denoted by [[M]]t where all

ðli, �iuið�iÞÞ !ei ðliþ1, �

iþ1uiþ1ð0ÞÞ are valid instantaneous

transition executions.Other aspects of hybrid behavior, such as

Zeno behavior and the distinction between urgentand non-urgent transitions, are omitted here. Asuitable formalization can be found, e.g., inHenzinger et al.66

A.2.3. Hybrid reconfiguration automata. In the fol-lowing, we describe the syntax and semantics ofhybrid reconfiguration automata that supports the flex-ible reconfiguration across module boundaries isdefined formally.

Syntax We define the syntax of hybrid reconfigura-tion charts as in Definition 7.

Definition 7. A hybrid reconfiguration automaton isdescribed by a 6-tuple (L, D, I, O, T, S0) with L afinite set of locations, D a function over L which assignsto each l2L a continuous model, D(l)¼ (Vx(l), Vu(l),Vy(l), F(l), G(l), C(l), X0(l)) (see Definition 1), I afinite set of input signals, O a finite set of output signals,T a finite set of transitions, and S0

� {(l, x) | l2L 6x2X(l)} the set of initial states. For any transition (l,g, gi, a, l0)2T it holds that l2L is the source location,g2COND(Vx(l)[Vu(l)) the continuous guard,gi2+(I[O) the I/O guard, a2 [[Vx(l)!R]![Vx(l0)!R]] the continuous update, and l0 2L thetarget location. For every l2L we require that D(l) iswell formed.

The automaton additionally allows that each loca-tion has its own variable sets. We use Vx to denote the

union of all Vx(l). Vu and Vy are derived analogously.We further use Vx(F(l)) to denote the state variable set.All assigned output variables are analogously namedprovided output variable set (Vy(F(l)[G(l))) and all ofthe input variables used are named the required inputvariable set (Vu(F(l)[G(l))).

Definition 8. The (static) interface I(M) of a hybridreconfiguration automaton M is defined as the externalvisible event sets and input and output variables (I�O,O� I, Vu

�Vy, Vy�Vu).

The parallel composition of two hybrid reconfigura-tion automata can be defined as follows.

Definition 9. For two hybrid reconfiguration automataM1 and M2 the parallel composition (M1kM2) results ina hybrid reconfiguration automaton M¼ (L, D, I, O, T,S 0) with L¼L1�L2, D(l, l0)¼D1(l)kD2(l

0), I¼ I1[ I2,O ¼ O1[O2. T ¼ fððl1, l2Þ, g, g

0, ða1 � a2Þ, ðl01, l02ÞÞj

ðl1, g1, g01, u1, l

01Þ 2T1 ^ ðl2, g2, g

02, u2, l

02Þ 2T2g [ fððl1, l2Þ,

g01, u1, ðl01, l2ÞÞjðl1, g1, u1, l

01Þ 2T1g [fððl1, l2Þ, g

02, u2, ðl1, l

02ÞÞj

ðl2, g2, u2, l02Þ 2T2g is the resulting transition relation

where g(x, u, i, o)¼ g1(x, u, i, o) 6 g2(x, u, i, o),g01ðx, u, i, oÞ ¼ g1ðx, u, i, oÞ ^ o \ I2 ¼ ; ^ i \O2 ¼ ;,and g02ðx, u, i, oÞ ¼ g2ðx, u, i,oÞ ^ o \ I1 ¼ ; ^ i \O1 ¼ ;.

The automaton M is only defined when for allreachable (l, l0)2L it holds that D((l, l0)) is defined andthe internal signal sets are disjoint ((O1\ I1)\(O2\ I2)¼;).

The parallel composition also follows directly fromthe non-reconfigurable case. In the case ofhybrid reconfiguration automata, a correct parallelcomposition has to ensure that for all reachable(l, l0)2L it holds that D((l, l0)) does not contain cyclicdependencies.

Further, we define the terms fading location and reg-ular location in Definition 10 and passive location inDefinition 11 similar to those presented by Burmesteret al.65 The fading locations are inspired by the idea ofLynch et al.64 and represent fading transitions as timeconsuming intermediate states.

Definition 10. For a hybrid reconfiguration automatonM¼ (L, D, I, O, T, S0) a location lf2L withD(lf)¼ (Vx(lf), V

u(lf), Vy(lf), F(lf), G(lf), C(lf), X

0(lf)) isa fading location iff:

. the invariant consists of just one inequality withrespect to the variable v and an upper bound dmax,C(lf)� (v� dmax);

. v is a clock, 9v2Vx(lf) with ð _v ¼ 1Þ 2Fðlf Þ;

. v is reset to zero when entering lf, for all (l, g, g0, a,lf)2T it holds that (v¼ 0)2 a;

. exactly one transition exists leaving lf, j{(lf, g, g0, a, l0)|

(lf, g, g0, a, l0)2T}j ¼ 1; and

Giese et al. 805

. for this transition it holds that g� dmin� v� dmax,g0 ¼ true, and a¼ Id.

All non-fading locations are regular locations.

Definition 11. For a hybrid reconfiguration automatonM¼ (L, D, I, O, T, S 0), a regular location lp2L is apassive location iff the location and all transitions leav-ing it have no continuous constraints.

As in the case of the hybrid automata, it holds that ifthe set of equations is well formed for every location, wehave a corresponding directed acyclic evaluation graph.In the case of composition of two hybrid reconfigurationautomata, we can derive the resulting directed acyclicevaluation graphs for every combination of locationsby simply combining the graphs of both locations atthe connected location-specific inputs and outputs.

Semantics The semantics can be derived from thehybrid automata semantics (see Section A.2.2) byalways taking into account the location-dependentnotion Vx(l) instead of the location independent Vx.

A.2.4. Flexible reconfigurable hierarchical hybridsystemsSyntax While the graph transformation systemspermit us to model complex discrete models, we haveto also support continuous behavior and thus in addi-tion consider the following extensions for hybrid graphtransformation systems (HGTSs): we assign types to allnodes and edges, provide node-type-specific attributesa2V, and node-type-specific continuous behavior forthe attributes of that node type. The state of a HGTStherefore consists of a graph G as well as an assignmentX which provides for each node n and related attributea the current value as X(n, a).

Graph patterns are accordingly extended such thatthey can also contain Boolean constraints over the nodeattributes. In addition, for the right-hand side graphpattern we also allow updates to be employed whichdetermine the new attribute values as a function ofnode attributes of the left-hand side.

By permitting differential equations that define howthe future state of a variable of node n can depend onthe variables of all its neighbors, the HGTS can modelin addition to its structure every possible evaluationgraph. A well-formed HGTS state therefore requiresthat the evaluation graph is acyclic.

Semantics Owing to the additional continuous beha-vior, we have, similarly to hybrid automata, two stepsfor HGTS:

1. First, the classical GTS step results in a discretechange of the graph which takes place in zero time.

In addition, the application of a rule requires thatthe additional Boolean constraints are fulfilled andmay also change some of the attribute values of thenodes denotes by related attribute updates in theright-hand side of the rule.

2. Second, a time-consuming continuous step thatresults for a current state (G, X), a time step �> 0,and trajectories � : [0, �]! [V!R] with �(0)(a)¼X(n, a) for each node n2G and attribute a2Vwhich conforms to the continuous behavior specifi-cation of the type of n results in a state (G, X�) fortime � with identical graph G and the continuousstate X� defined by X�(n, a) :¼ �(�)(a).

Using this concept, we can, for example, describe thevelocity of a vehicle given as a node n using differentialequations or real-time behavior by means of clock vari-ables with a constant derivative 1.

Using a rule labeling alphabet A and a correspond-ing labelling for all rules �: R!A we furtherwrite G a!G0 instead of G !r G0 if �(r)¼ a andG �ð�Þ

!G0 for a continuous step. Here G w!�G0 is

accordingly defined as the finite sequence of stepsGi

ai!Giþ1 with w the concatenation of the labelsa1;. . .; an with �(�1);�(�2) is reduced tog �(�1þ �2). Ifmore appropriate we may also omit the labeling andwrite G!G0 and G!* G

0.The composition S�T of two HGTSs S and T is

defined by simply joining the rule sets. We can in addi-tion define the parallel composition SkT of two labeledHGTSs S and T by synchronizing always two rules ofboth HGTSs with the same label. We further requirethat to build a parallel composition, the combined rulesare always identical with respect to shared elementtypes. For the parallel composition holds that S aswell as T simulate SkT (see below).

A.3. Static analysis for reconfiguration

To exclude runtime failures in the case of reconfigura-tion, static analysis can be performed using the refine-ment notion related to the interface statecharts andchecked carefully to ensure a correct embedding.

A.3.1. Refinement and abstraction. To studywhat a correct relation between the realizationof a component and its interface automaton is,we write for a possible execution sequence of statesand transitions of a hybrid automaton M¼ (L, D, I,O, T, S0) with ðu0, l0, �

0u0, �0u0 , �0Þ !e0 ðu1, l1, �

1u1, �1u1 ,�1Þ

2 ½½Mt simply ðl0, �0u0ð0ÞÞ !ðu0,�0u0 ,�

0u0, �0Þ ðl0, �

0u0ð�0ÞÞ !e0

gWe ignore here the problem of Zeno behavior which might resultfrom an infinite sequence of classical steps or an non-convergentsequence of time steps (

P�i91).


ðl1, �1u1ð0ÞÞ !ðu1,l1,�1u1 ,�

1u1, �1Þ ðl1, �

1u1ð�1ÞÞ to represent

the state changes in a more uniform manner.We thus have the concept of a hybridpath � ¼ ðu0, �

0u0, �0Þ; e0; . . . ; ðun, ln, �

1un, �nÞ; en such

that we write ðl0,�0u0ð0ÞÞ !� ðln,�

nunð�nÞÞ iff it

holds that ðl0,�0u0ð0ÞÞ!ðu0,�0u0 ,�

0u0,�0Þ ðl0,�

0u0ð�0ÞÞ!e0 . . .

ðln,�nunð0ÞÞ! ðun,ln,�nun ,�

nun,�nÞðln,�

nunð�nÞÞ.

For e0i ¼ ei � ðO \ IÞ the externally relevant eventsand �iui ¼ �

iuijVyðliÞ�VuðliÞ the output minus the internal

variables, we have an abstract path�0 ¼ ðu0,�

0u0,�0Þ; e

00; . . . ; ðun,�

1un,�nÞ; en; . . . and we write

ðl0,�0u0ð0ÞÞ )�0 ðln,�

nunð�nÞÞ. Note that w; e; w0 with e¼;

is collapsed to w; w0 as no externally relevant events arereceived or emitted. The offered discrete as well as con-tinuous interactions for a state (l, x) are further denotedby the set offer(M, (l, x)) which is defined as {e | 9(l, x))e (l

0, x)}[ {(du/dt)(0) | 9(l, x) )(u,yu,�) (l, x0)}.

An appropriate notion of hybrid refinement for theinterface is then defined as follows.

Definition 12. For two hybrid reconfigurationautomata MI and MR it holds that MR is arefinement of MI denoted by MRYMI iff a relation�� (LR�XR)� (LI�XI) exists, so that for everyc2 (LR�XR) a c00 2 (LI�XI) exists such that (c, c00)2�and for all (c, c00)2� it holds that

8c)� c0 9c00 )� c

000 : ðc0, c000Þ 2� and ð1Þ

offerðMR, cÞ offerðMI, c00Þ and ð2Þ

8 ððlR, xRÞ,ðlI, xIÞÞ 2�: DeðDRðlRÞÞ � DeðDLðlIÞÞ:

ð3Þ

We denote dependencies between input and outputvariables using D(M)�Vu

�Vy. The external visibledependencies De(M) are accordingly defined asDe(M) :¼D(M)\ ((Vu

�Vy)� (Vy�Vu)). Note that

these dependencies essentially capture what has beenformalized with the reduced evaluation graphs. Whatis not required for the considerations here is the accu-mulation of multiple inputs and outputs into separateevaluation blocks. Here, we are only interested in cor-rectness and do not require this information which isessential for an efficient modular evaluation scheme.

A.3.2. Correct embedding. Owing to the fact thathierarchical composition in contrast to the general par-allel composition restricts a potential overlapping oflocations, the previous subsection introduced refine-ment can be checked in many cases with static analysiswithout consideration of the full state space of themodel. In these checks, fading transitions and theirdurations play an important role. Formalizing theirsemantics leads to simple interface automata.65

Definition 13. An interface automaton M¼ (L, D, I, O,T, S0) is simple if it contains only passive and fadinglocations and two fading locations are never connecteddirectly.

We then can define the set H of possibly reachablestate combinations of a reconfigurable hybrid compo-nent and its embedded occurrences as follows.

Definition 14. Let C¼ (S, M, P, prop) be a reconfigur-able hybrid component with M¼ (L, D, I, O, T, S0),S(l)¼ (I(l), B(l), E(l), map(l)), and E(l)¼ {(N1, (M1,I1, P1, prop1), l1), . . . , (Nn, (Mn, In, Pn, propn), ln)}.The set of possibly reachable states is H¼ {(l,(l1, . . . , ln))| l2L}. We call MkH (M1k. . .kMn) :¼behavior(C)k(M1k. . . kMn) the hierarchical parallelcomposition of M and M1k. . . kMn.

The following theorem describes a simplesyntactical rule which is sufficient to prove forthe restricted case sketched above that a hierarchicalparallel product does not have any timing errors.The basic idea is that the timing interval of a hybridreconfiguration chart’s fading transitions has to con-form with one of its embedded simple interface statecharts.

Theorem 1 (see Burmester et al.65). For the hierarchicalparallel composition M1kH M2 of two hybrid automataM1 and M2 it holds that M1kH M2YM1nI2[O2

if the

following hold.

1. We have I(M1 kH M2)¼ I(M1nI2[O2).

2. All initial states are also contained in H:ðfðl1,l2Þjðl1,xÞ 2S

01 ^ ðl2,yÞ 2S

02g � HÞ.

3. M2 is a simple interface state chart (seeDefinition 13).

4. For all (l1, l2)2H and transition t1 ¼ðl1, g1, g

i1, a1, l

01Þ 2T1 the following hold.

(a) If l01 is not a fading location, then for allt2 ¼ ðl2, g2, g

i2, u2, l

02Þ 2T2 with gi1 \ ðI2 [O2Þ ¼

gi2 the following must hold:(i) g2¼ true;(ii) l02 is a passive location (see Definition 11); and(iii) ðl01, l

02Þ 2H.

In addition at least one such transition in M2 mustexist.

(b) If l01 is a fading location we can conclude thatexactly one transition t01 ¼ ðl

01, g01, g

i10, a01, l

001Þ 2T1

with g01 � d1min � v � d1max and gi0

1 ¼ ; exists(see Definition 10). For any t2 ¼ðl2, g2, g

i2, a2, l

02Þ 2T2 with gi1 \ ðI2 [O2Þ ¼ gi2 the

following must hold:(i) g2¼ true;(ii) l02 is a fading location; and

Giese et al. 807

(iii) ðl01,l02Þ 2H.

For the uniquely determined successor transitiont02 ¼ ðl

02,g02,g

i20,a02,l

002Þ2T2 with g02 � d2min � v� d2

max

the following must hold:(iv) l002 is a passive location (see Definition 11);(v) ðl001, l

002Þ 2H; and

(vi) ½d 2min, d

2max � ½d

1min,d

1jmax must be satisfied.

Again, at least one such pair of transitions in M2 mustexist.

Theorem 1 can be extended to the general case ofMSkH (M1k. . . kMn) by induction. Owing to the syntac-tical check of Theorem 1, the hierarchical compositionby means of the underlying hybrid control softwarecannot invalidate the timing properties ensured by theembedding hybrid statechart of the monitor (seeBurmester et al.67 for details of the proof).


a multi-paradigm approach supporting the modular execution

Documents