HYBRID UML COMPONENTS FOR THE DESIGN OFCOMPLEX SELF-OPTIMIZING MECHATRONIC SYSTEMS ∗

Sven Burmester† and Holger GieseSoftware Engineering Group, University of Paderborn

Warburger Str. 100, D-33098 Paderborn, Germanyburmi@upb.de, hg@upb.de

Oliver OberschelpMechatronic Laboratory Paderborn, University of Paderborn

Pohlweg 98, D-33098 Paderborn, GermanyOliver.Oberschelp@mlap.de

Keywords: Mechatronic, Self-optimization, Control, Hybrid Systems, Components, Reconfiguration, Unified ModellingLanguage (UML), Real-Time

Abstract: Complex technical systems, such as mechatronic systems, can exploit the computational power available to-day to achieve an automatic improvement of the technical system performance at run-time by means of self-optimization. To realize this vision appropriate means for the design of such systems are required. To supportself-optimization it is not enough just to permit to alter some free parameters of the controllers. Furthermore,support for the modular reconfiguration of the internal structures of the controllers is required. Thereby itmakes sense to find a representation for reconfigurable systems which includes classical, non-reconfigurableblock diagrams. We therefore propose hybrid components and a related hybrid Statechart extension for theUnified Modeling Language (UML); it is to support the design of self-optimizing mechatronic systems by al-lowing specification of the necessary flexible reconfiguration of the system as well as of its hybrid subsystemsin a modular manner.

1 INTRODUCTION

Mechatronic systems are technical systems whose be-havior is actively controlled with the help of computertechnology. The design of these systems is marked bya combination of technologies used in mechanical andelectrical engineering as well as in computer science.The focus of the development is on the technical sys-tem whose motion behavior is controlled by software.

The increasing efficiency of microelectronics, par-ticularly in embedded systems, allows the develop-ment of mechatronic systems that besides the re-quired control use computational resources to im-prove their long term performance. These forms ofself-optimization allow an automatic improvement ofa technical system during operation which increasesthe operating efficiency of the system and reduces theoperating costs.

∗This work was developed in the course of the Spe-cial Research Initiative 614 - Self-optimizing Concepts andStructures in Mechanical Engineering - University of Pader-born, and was published on its behalf and funded by theDeutsche Forschungsgemeinschaft.

†Supported by the International Graduate School of Dy-namic Intelligent Systems. University of Paderborn

A generally accepted definition of the term self-optimization is difficult to find. In our view, the corefunction of self-optimization in technical systems isgenerally an automatic improvement of the behaviorof the technical system at run-time with respect to de-fined target criteria. In a self-optimizing design, de-velopment decisions are being shifted from the designphase to the system run-time.

There are two opportunities of optimization duringruntime. The first is to optimize parameters (Li andHorowitz, 1997) the second is to optimize the struc-ture. However, alteration of the free parameters of thesystem will not lead very far because many charac-teristics, in particular those of the controller, can bealtered only in the internal structures and not just bya modification of parameters (Follinger et al., 1994;Isermann et al., 1992).

While most approaches to hybrid modeling (Hen-zinger et al., 1995; Bender et al., 2002; Alur et al.,2001) describe how the continuous behavior can bemodified when the discrete control state of the sys-tem is altered, we need an approach that allows thecontinuous behavior as well as its topology to be al-tered in a modular manner to support the design ofself-optimizing systems.

Our suggestion is to integrate methods used in me-chanical engineering and software engineering to sup-port the design of mechatronic systems with self-optimization. We therefore combine component di-agrams and state machines as proposed in the forth-coming UML 2.0 (UML, 2003) with block diagrams(Follinger et al., 1994) usually employed by controlengineers. The proposed component-based approachthus allows a decoupling of the domains: A controlengineer can develop the continuous controllers aswell as their reconfiguration and switching in form ofhybrid components. A software engineer on the otherhand can integrate these components in his design ofthe real-time coordination. As this paper focusses themodeling aspect we set simulation aside. Simulationresults can be found in (Liu-Henke et al., 2000).

In Section 2 we will examine related work. Section3 discusses problems resulting from reconfigurationby means of an application example. In Section 4,our approach to hybrid modeling with an extension ofUML components and Statecharts will be described.Thereafter we describe our model’s runtime platformin Section 5 and sum up in Section 6 with a final con-clusion and an outlook on future work.

2 RELATED WORK

A couple of modeling languages have been proposedto support the design of hybrid systems (Alur et al.,1995; Lamport, 1993; Wieting, 1996). Most of theseapproaches provide models, like linear hybrid au-tomata (Alur et al., 1995), that enable the use of ef-ficient formal analysis methods, but lack of methodsfor structured, modular design, that is indispensablein a practical application (Muller and Rake, 1999).

To overcome this limitation, hybrid automata havebeen extended to hybrid Statecharts in (Kesten andPnueli, 1992). Hybrid Statecharts reduce the visualcomplexity of a hybrid automaton through the use ofhigh-level constructs like hierarchy and parallelism,but for more complex systems further concepts formodularization are required.

The hybrid extensions HyROOM (Stauner et al.,2001), HyCharts (Grosu et al., 1998; Stauner, 2001)and Hybrid Sequence Charts (Grosu et al., 1999) ofROOM/UML-RT integrate domain specific model-ing techniques. The software’s architecture is spec-ified similar to ROOM/UML-RT and the behavioris specified by statecharts whose states are asso-ciated with systems of ordinary differential equa-tions and differential constraints (HyCharts) or Mat-lab/Simulink block diagrams (HyROOM). HyROOMmodels can be mapped to HyCharts (Stauner et al.,2001). Through adding tolerances to the continuousbehavior this interesting specification technique en-

ables automatic implementation, but support for themodular reconfiguration is not given.

In (Conrad et al., 1998) guiding principles for thedesign of hybrid systems are sketched. It describeshow to apply techniques that are used in automo-tive engineering, like the combination of statecharts,blockdiagrams and commercial tools. Following thisapproach hybrid systems need to be decoupled intodiscrete and continuous systems in the early designphases. Therefore a seamless support and a commonmodel are not provided.

Within the Fresco project the description languageMasaccio (Henzinger, 2000) which permits hierar-chical, parallelized, and serially composed discreteand continuous components has been developed. AMasaccio model can be mapped to a Giotto (Hen-zinger et al., 2003) model, that contains sufficient in-formation about tasks, frequencies, etc. to provide animplementaion. The project provides a seamless sup-port for modeling, verification and implementation,but our needs for advanced modeling techniques thatsupport dynamic reconfiguration are not addressed.

3 MODELINGRECONFIGURATION

We will use the switching between three controllerstructures as a running example to outline the result-ing modeling problems. The concrete example is anactive vehicle suspension system with its controllerwhich stems from theNeue Bahntechnik Paderborn3

research project. The project has been initiated andworked upon by several departments of the Univer-sity of Paderborn and the Heinz Nixdorf Institute. Inthe project, a modular rail system will be developed;it is to combine modern chassis technology with theadvantages of the Transrapid4 and the use of existingrail tracks. The interaction between information tech-nology and sensor/actuator technology paves the wayfor an entirely new type of mechatronic rail system.The vehicles designed apply the linear drive technol-ogy used in the Transrapid, but travel on existing railtracks. The use of existing rail tracks will eliminate anessential barrier to the proliferation of new railboundtransport systems (Luckel et al., 1999).

Figure 1 shows a schema of the physical model ofthe active vehicle suspension system. The suspen-sion system of railway vehicles is based on air springswhich can be damped actively by a displacement oftheir bases. The active spring-based displacement iseffected by hydraulic cylinders. Three vertical hy-draulic cylinders, arranged on a plane, move the bases

3http://www-nbp.upb.de/en4http://www.transrapid.de/en

A B C

prop.- valves

A / D

controller

D / A

sensors

hydr. pump

car body

hydr. actuators

air springs

to theactuators

z

y

a

Figure 1: Scheme of the suspension/tilt module

of the air springs via an intermediate frame, the sus-pension frame. This arrangement allows a damping offorces in lateral and vertical directions. In addition, itis also possible to regulate the level of the coach andadd active tilting of the coach body. Three additionalhydraulic cylinders allow a simulation of vertical andlateral rail excitation (Hestermeyer et al., 2002). Thevital task for the control system is to control the dy-namical behavior of the coach body. In our example,we will focus only on the vertical dynamic behavior ofthe coach body. The overall controller structure com-prises different feedback controllers, e.g., for control-ling the hydraulic cylinder position and the dynamicsof the car body.

reference overall

lateral acceleration

vertical acceleration

decoupling tuningforces

coupling

DT

DT

DT

XZ, A

XZ, B

XZ, C

Yairsp

Zairsp, L

Z airsp, R

Y

a

Z

Z.

Y.

a

.

F lift

M tilt

F lat. XZ, A, ref.

XZ, B, ref.

XZ, C, ref.

Yref.Z ref.

a ref.

reference valuesto cylinder A, B, C(local controller)

}

x..

abs.

z..

abs.

M tilt tilt torque

F lift lift force

Flat. lateral force Y, aZ, body coordinates

airspL R,Y, Z , Z airspring positions

XZ, A, B, C cylinder positions

Figure 2: Reference controller

The schema of the reference controller for the over-all body controller is depicted in Figure 2. The sub-ordinated controller is not displayed here for reasonsof clarity. The controller essentially consists of theblocksdecoupling, tuning forces, andcoupling. In theblock decoupling the kinematics of the cylinders isconverted into Cartesian coordinates for the descrip-tion of the body motion. The actual control algorithmis in the blocktuning forces. Here the forces are com-puted which are to affect the mechanical structure.In the blockcoupling the forces and torques are con-verted again into reference values for the subordinatedcylinder controller (Liu-Henke et al., 2000).

A common representation for the modeling ofmechatronic systems which have been employed hereare hierarchical block diagrams. This kind of repre-sentation has its seeds in control engineering, whereit is used to represent mathematic transfer functionsgraphically. It is widely-used in different CAE-tools. Block diagrams consist generally of functionblocks, specifying function resp. behavior and hier-archy blocks grouping function and hierarchy blocks.This allows a structured draft and reduces the over-all complexity of a block diagram. Between singleblocks exists connections or couplings, which canhave the shape of directed or non-directed links. Withdirected links data is exchanged whereas non-directedones often describe functional relations or physicallinks, such as a link between mass and spring in multi-body system representation. While parameter opti-mization can be described using simply an additionalconnection for the parameter, the static structure ofblock diagrams does not permit to model structuralmodifications (Isermann et al., 1992).

We can, however, use special switches or fadingblocks to describe the required behavior. The con-troller in our example has two normal modes:Ref-erence andabsolute. The controllerreference uses agiven trajectory that describes the motion of the coachbody zref = f(x) and the absolute velocity of thecoach bodyzabs (derived fromzabs). The zref tra-jectory is given for each single track section. A tracksection’s registry communicates this reference trajec-tory to the vehicle. In case a reference trajectory isnot available, another controller which requires onlythe absolute velocity of the coach bodyzabs for thedamping of the coach-body motion has to be used.

Besides the regular modes another controllernamedrobust is required for an emergency; it must beable to operate even if neither the reference trajectorynor the measurement of the coach-body accelerationare available (see Figure 3).

z..z

Zref.

abs.

XZ, A, ref.

XZ, B, ref.

XZ, C, ref.

normal

“reference”

“absolute”

failure

“robust”

body control

commoninputs

t0 tend

1

0

f (t)Switch

1-f (t)Switch

blending curves

Figure 3: Fading between different control modes

For a switching between two controllers one mustdistinguish between two different cases:atomicswitchingand cross fading.5 In the case of atomic

5The structure and type of cross fading depends on the

switching the change can take place between twocomputation steps. To start the new controller up, itis often necessary to initialize its states on the basisof the states of the old controller. In our example, theswitching from the normal block to the failure block(see Figure 3) can be processed atomically becausethe robust controller actually has no state. Differenttheoretical works deal with the verification of stabil-ity in systems with any desired switching processes(Lygeros et al., 2003). In the simple case of a switchto a robust controller, stability can be maintained withthe help of condition monitoring (Deppe and Ober-schelp, 2000).

If, however, the operating points of the controllersare not identical it will be necessary to cross-fade be-tween the two controllers. This handling is required inthe normal block depicted in Figure 3, where a transi-tion between the reference and the absolute controlleris realized. The cross fading itself is specified by afading functionfswitch(t) and an additional parame-ter which determines the duration of the cross fading.

While the outlined modeling style allows to de-scribe the required behavior, the result is inadequatebecause of the following two problems: (1) the differ-ent operation modes and the possible transitions be-tween them are more appropriately modeled using atechniques for finite state systems rather than a setof blocks scattered all around in the block diagramsand (2) this style of modeling would require to exe-cute all alternative controllers in parallel even thougha straight forward analysis of the state space of the re-sulting finite state system would permit to run only theblocks which realize the currently active controllers.

To overcome these problems, hybrid modeling ap-proaches such as hybrid automata (Henzinger et al.,1995) can be employed. When modeling the fadingand switching between the different controllers in ourexample according to Figure 3, a hybrid automatonwith at least three discrete states – one for each of thecontrollers– might be used. These are the locationsRobust, Absolute and Reference in Figure 4. Thelocations’ continuous behavior is represented by theassociated controllers. Contrary to the white-filledarrows, black-filled ones denote the common inputswhich are always available and required by all con-trollers.

When the automaton resides in the start locationRobust and for instance thezabs signal becomes avail-able (as indicated by the discretezAbsOK signal),the location and the controller change to the absolutemode. As this change requires cross fading an addi-tional location (FadeRobAbs) is introduced in whichthe cross fading is comprised. To specify a fading du-ration d1 = [d1

low, d1up] an additional state variable

controller types and could lead to complex structures. Inour example we use only output fading.

<RefAbs>

<RobAbs>

Robust

<Rob>

Absolute

FadeRobAbs

<Abs>

zAbsOK

<AbsRef>

<RobRef>

zRefFailure

Reference

zRefOK

zRefOK

<Ref>

FadeAbsRef

zAbsFailurezAbsFailure

zAbsFailure

zAbsFailure

zRefFailure

zAbsFailure

FadeRobRef

FadeRefAbs

zAbsFailurezAbsOK

special input common output

common inputLegend:

zabs

zref

zabs

zref

zabs

zabs

d1

low ≤ tc ≤ d1

up

tc = 0

tc ≤ d3

up

tc = 0

d4

low ≤ tc ≤ d4

up

tc = 0

tc ≤ d2

uptc = 0

zref

zabs

tc ≤ d4

up

d2

low ≤ tc ≤ d2

up

d3

low ≤ tc ≤ d3

up

tc ≤ d1

up

zref

zabs

Figure 4: Hybrid body control with fading locations

tc with tc = 1 is introduced. The reset when en-tering the fading locationFadeRobAbs, its invarianttc ≤ d1

up and the transition’s guardd1low ≤ tc ≤ d1

up

guarantee that the fading will taked1low at a minimum

andd1up at a maximum. After completing the fading,

the target locationAbsolute is entered. The durationof the other fading transitions is specified similarly. Ifthe zabs signal is lost during fading or during the useof the absolute-controller, the default location with itsrobust control is entered immediately (cf. Figure 4).

In an appropriate self-optimizing design the aimmust be to use the most comfortable controller whilestill maintaining the shuttle’s safety. If, for instance,the absolute controller is in use and the related sensorfails, the controller may become instable. Thus thereis need for a discrete control monitor which ensuresthat only safe configurations are allowed. The moni-tor which controls the correct transition between thediscrete controller modes must also be coordinatedwith the overall real-time processing. In our example,the reference controller can only be employed whenthe data about the track characteristics has been re-ceived in time by the real-time shuttle control soft-ware. Trying to also integrate these additional dis-crete state elements into our hybrid description of thebody control would obviously result in a overly com-plex description by means of a single hybrid State-chart which lacks modularity.

4 THE APPROACH

To support the design of complex mechatronic sys-tems and to overcome the problems of the availablemodeling techniques as outlined in the preceding sec-tion, we introduce in the following informally our ap-

proach for modeling with the UML in Section 4.1,our notion for hybrid Statecharts in Section 4.2, ournotion for hybrid components in Section 4.3, and themodular reconfiguration in Section 4.4. The exact for-malization is presented in (Giese et al., 2004).

4.1 Hybrid UML Model

In Figure 5c the overall structural view of our exam-ple is presented by means of a UML component di-agram. TheMonitor component, that embeds threecomponents, communicates with theRegistry compo-nent through ports and a communication channel. TheShuttle-Registration pattern specifies the communica-tion protocol betweenMonitor andRegistry. The be-havior of the track section registry which is frequentlycontacted by the monitor to obtain the requiredzref

is depicted in Figure 5b. In Figure 5a the sensor’s be-havior is described by a Statechart.

:Registry

:Monitor

storage : Storage

:BC

:Sensor RegistrationShuttle−

Pattern

c) Component diagrama) Sensor

On Off/ monitor.ok

/ monitor.failure

b) Registry

Default Proceed

shuttle.requestInfo /

Vector zRef)/ shuttle.sendInfo(

Figure 5: Monitor and its environment (incl. behavior)

The embedded components communicate continu-ous signals through so calledcontinuous ports, de-picted by framed triangles whose orientation indicatesthe direction of the signal flow, and discrete eventsthrough discrete, non-filled ports.

4.2 Hybrid Statecharts

A look at the hybrid automaton from Figure 4 re-veals that the explicit fading locations considerablyincrease the number of visible locations of the au-tomaton and make it unnecessarily difficult to under-stand.

Therefore we propose an extension of UML State-charts towards Hybrid Statecharts that provide ashort-form to describe the fading. The short-formcontains the following parameters: A source- and atarget-location, a guard and an event trigger, informa-tion on whether or not it is an atomic switch, and,in the latter case, a fading strategy (here cross fad-ing is used for allfading transitions), a fading func-tion (ffade) and the required fading duration intervald = [dlow, dup] specifying the minimum and maxi-mum duration of the fading. This short-form is dis-played in Figure 6. The fading-transitions are visual-

zAbsFailure

zAbsOK

Robust

Reference

Absolute

zRefOK

zAbsFailure

zAbsOK

zRefFailure

<Abs>

<Ref>

<Rob>

d4

d2

ffade2

ffade1

zabs

zabs

zrefd1

d3

ffade3

ffade4

Figure 6: Behavior of the body control component

ized by thick arrows while atomic switches have theshape of regular arrows.

An atomic transition, leaving the source or the tar-get state of a currently active fading transition, inter-rupts the execution of the fading transition. In caseof conflicting atomic transitions of the source and tar-get state, the source state’s transitions have priority bydefault.

4.3 Hybrid Components

One serious limitation of today’s approaches for hy-brid systems is due to the fact that the continuous partof each location has to have the same set of requiredinput and provided output variables (continuous in-terface). To foster the reconfiguration we propose todescribe the different externally relevant continuousinterfaces as well as the transition between them us-ing hybrid interface Statecharts.

zRefOK

zAbsFailure

zAbsOK

zRefFailure

zAbsOK

[Robust]

[Absolute]

zAbsFailure

[Reference]

d2

d3

d1

d4

zabs

zref

zabs

Figure 7: Interface Statechart of theBC component

The related interface Statechart of the body controlcomponent of Figure 6 is displayed in Figure 7. Itshows that the body control component has three pos-sible different interfaces. The (continous) ports thatare required in each of the three interfaces are filledblack, the ones that are only used in a subset of thestates are filled white. For all possible state changes,

only the externally relevant information, such as du-rations and the signals to initiate and to break the tran-sitions, are present.

Interface Statecharts can be employed to ab-stract from realization details of a component. Acomponent in our approach can thus be describedas a UML component – with ports with distinctquasi-continuous and discrete signals and events– by• a hybrid interface Statechart which is a correct

abstraction of the component behavior (cf. (Gieseet al., 2004)) which determines what signals areused in what state,

• the dependency relation between the outputand input signals of a component per state ofthe interface Statechart in order to ensure onlyacyclic dependencies between the components, and

• the behavior of the component usually describedby a single Hybrid Statechart and its embeddedsubcomponents (see Section 4.4).In our example, theBC component is described by

its hybrid interface Statechart presented in Figure 7,the additionally required information on which de-pendencies between output and input variables existwhich is not displayed in Figure 7, and its behaviordescribed by the Hybrid Statechart of Figure 6 wherethe required quasi-continuous behavior is specified bycontrollers.

4.4 Modular Reconfiguration

The hybrid statechart from Figure 6, which supportsstate-dependent continuous interfaces, does still notinclude the case that the employed controllers showhybrid behavior themselves. Instead, complete sep-aration of discrete and continuous behavior like in(Alur et al., 2001; Bender et al., 2002; Henzingeret al., 1995; Kuhl et al., 2002) is still present.

basic block

basic block

basic block

interchange,reconfiguration

basic block

hierarchyhierarchy

hierarchy

A

B

Figure 8: Reconfigurable block diagram

To overcome this limitation, we propose to assignthe required configuration of embedded subcompo-nents (not only quasi-continuous blocks) to each state

of a Hybrid Statechart by means of UML instance di-agrams. This idea is motivated by the observationthat the topology of hierarchical block diagrams couldbe seen as a tree. With the leafs of this tree repre-senting the behavior whereas the inner nodes describethe structure of the system. This distinction betweenstructure (hierarchy) and function (block) can be usedfor the required modular reconfigurable systems. Inour context, a reconfiguration can be understood as achange in the structure resp. substructure of a blockdiagram. It alters the topology of the system; func-tions are added and/or interlinked anew. Thus to real-ize modular reconfiguration we only have to providea solution to alter the hierarchical elements (cf. Fig.8). In this manner the required coordination of aggre-gated components can be described using a modularHybrid statechart which alter the configurations of itshybrid subcomponents (see Figure 9).

:Sensor[Off]:BC[Robust]

storage:Storage

:Sensor[On]:BC[Reference] :Sensor[On]:BC[Absolute]

:BC[Robust] :Sensor[Off]

when(nextSegment)noData? /

when(nextSegment)data(Vector zRef)?

when(!storage.isEmpty())/ data(Vector zRef)!

after(20)/ registry.requestInfo

RefNonAvailable

/ noData!registry.sendInfo(zRef) / storage.add(zRef)

RefAvailable

when(storage.isEmpty())

when(nextSegment)data(Vector zRef)? /

sensor.ok

RefAvailable NoneAvailable

sensor.failure

sensor.ok

data(Vector zRef)?

noData?

AbsAvailableAllAvailable

sensor.failure

when(nextSegment)data(Vector zRef)? /

db

dd da

dc

Figure 9: Monitor behavior with modular reconfigurationof the subcomponentBC

Figure 9 specifies the behavior of the control mon-itor software. The upper AND-state consists of fourlocations indicating which of the two signalszabs andzref are available. Some transitions can fire imme-diately, others are associated with a deadline intervald = [dlow, dup] specifying how much time a transi-tion may take minimal and maximal. These transi-tions are thicker and marked with an arrow and theintervals (da, . . . , dd). The lower branch of the mod-ular Hybrid statechart communicates with the tracksection registry (Figure 5c), frequently requests thezref function, and puts it in the storage.

In the Hybrid Statechart, every discrete state hasbeen associated with a configuration of the subcom-ponents (BC, Sensor, Storage). In the design of these

associations, only the interface description of the em-bedded componentBC (see Figure 7) is relevant andthe inner structure can be neglected. Therefore, asshown in Figure 9, we can assign to each location ofthe upper AND-state of the statechart theBC compo-nent in the appropriate state. E.g., theBC componentinstance in stateReference has been (via a visual em-bedding) assigned to the locationAllAvailable of themonitor wherezref as well aszabs are available. Therequired structure is specified by instances of theSen-sor and theStorage component and the communica-tion links.

The Hybrid Statechart of Figure 9 defines a map-ping of states to required configurations of the sub-components. The required synchronization betweenthe components is accomplished through explicit rais-ing of the discrete signals defined in Figure 7.

5 RUN-TIME ARCHITECTURE

In order to reach interoperability for mechatronic sys-tems, which are only alterable within certain limits,one can use appropriate middleware solutions likeIPANEMA (Honekamp, 1998), which allows abstrac-tion from hardware details. IPANEMA is a plat-form concept for distributed real-time execution andsimulation to support rapid prototyping. It allowsa modular-hierarchical organization of tasks or pro-cesses on distributed hardware.

In order to make interoperability possible also forhybrid components, which contain the kinds of alter-ation capability described above, the support of alter-ation capability by the middleware must be consider-ably extended. First it is necessary to generate themodels in accordance to their modular-hierarchicalstructure. This is the basis for a reconfiguration.

In each discrete location of the system the equa-tions, that implement the currently active controllers,have to be employed to compute the correct continu-ous behavior. Thus in every location of this kind onlythe relevant equations have to be evaluated. To reachthis aim, the architecture provides means for everycomponent to adjust the set of active equation blocksin such a way that the required reconfiguration of thecomponent system is efficiently managed.

In the modular execution framework outlined, therequired execution order results from the local eval-uation dependencies within each component as wellas from their interconnection. It must thus be deter-mined at deployment-time or run-time.

The continuous nonlinear differential equations aresolved by applying suitable numeric solvers. Com-putation is time-discrete. Incrementation depends onthe solver and the dynamics of the continuous system.A time-accurate detection of a continuous condition

is not possible if the controller is coupled with a realtechnical system. Thus, we restrict the urgent reactionto continuous conditions in the hybrid statecharts to adetection within the desired time slot (cf. (Henzingeret al., 2003; Stauner, 2002)).

6 CONCLUSION AND FUTUREWORK

Complex mechatronic systems with self-optimizationare hybrid systems which reconfigure themselves atrun-time. As outlined in the paper, their modelingcan hardly be done by the approaches currently avail-able. Therefore, we propose an extension of UMLcomponents and Statecharts towards reconfigurablehybrid systems which supports the modular hierarchi-cal modeling of reconfigurable systems with hybridcomponents and hybrid Statecharts.

The presented approach permits that the neededdiscrete coordination can be designed by a softwareengineer with extended Statecharts. In parallel, a con-trol engineer can construct the advanced controllercomponent which offers the technical feasible recon-figuration steps. These two views can then be inte-grated using only the component interface of the con-troller component.

It is planned to support the presented concepts byboth the CAE tool CAMeL (Richert, 1996) and theCASE tool Fujaba (Giese et al., 2003). With bothtools, the result of every design activity will be a hy-brid component. Each of these hybrid components it-self can integrate hybrid components. The integrationonly requires the information given by the componentinterface. Additional automatic and modular codegeneration for the hybrid models and run-time sup-port for the reconfiguration will thus result in supportfor the modular and component-based development ofself-optimizing mechatronic systems from the modellevel down to the final code.

REFERENCES

(2003).UML 2.0 Superstructure Specification. Object Man-agement Group. Document ptc/03-08-02.

Alur, R., Courcoubetis, C., Halbwachs, N., Henzinger, T.,Ho, P.-H., Nicollin, X., Olivero, A., Sifakis, J., andYovine, S. (1995). The algorithmic analysis of hybridsystems.Theoretical Computer Science, 138(3-34).

Alur, R., Dang, T., Esposito, J., Fierro, R., Hur, Y., Ivan-cic, F., Kumar, V., Lee, I., Mishra, P., Pappas, G., andSokolsky, O. (2001). Hierarchical Hybrid Modeling ofEmbedded Systems. InFirst Workshop on EmbeddedSoftware.

Bender, K., Broy, M., Peter, I., Pretschner, A., and Stauner,T. (2002). Model based development of hybrid sys-tems. InModelling, Analysis, and Design of HybridSystems, volume 279 ofLecture Notes on Control andInformation Sciences, pages 37–52. Springer Verlag.

Conrad, M., Weber, M., and Mueller, O. (1998). Towardsa methodology for the design of hybrid systems inautomotive electronics. InProc. of the InternationalSymposium on Automotive Technology and Automa-tion (ISATA’98).

Deppe, M. and Oberschelp, O. (2000). Real-Time Sup-port For Online Controller Supervision And Optimi-sation. InProc. of DIPES 2000. Workshop on Dis-tributed and Parallel Embedded Systems, Mechatron-ics Laboratory Paderborn, University of Paderborn.

Follinger, O., Dorscheid, F., and Klittich, M. (1994).Regelungstechnik - Einfuhrung in die Methoden undihre Anwendung. Huthig.

Giese, H., Burmester, S., Schafer, W., and Oberschelp,O. (2004). Modular Design and Verification ofComponent-Based Mechatronic Systems with Online-Reconfiguration. InProc. of 12th ACM SIGSOFTFoundations of Software Engineering 2004 (FSE2004), Newport Beach, USA. ACM. (accepted).

Giese, H., Tichy, M., Burmester, S., Schafer, W., and Flake,S. (2003). Towards the Compositional Verification ofReal-Time UML Designs. InProc. of the EuropeanSoftware Engineering Conference (ESEC), Helsinki,Finland. Copyright 2003 by ACM, Inc.

Grosu, R., Krueger, I., and Stauner, T. (1999). Hybrid se-quence charts. Technical Report TUM-I9914, Techni-cal University Munich, Munich.

Grosu, R., Stauner, T., and Broy, M. (1998). A modularvisual model for hybrid systems. InProc. of FormalTechniques in Real-Time and Fault-Tolerant Systems(FTRTFT’98), LNCS 1486. Springer-Verlag.

Henzinger, T. A. (2000). Masaccio: A Formal Model forEmbedded Components. InProceedings of the FirstIFIP International Conference on Theoretical Com-puter Science (TCS), Lecture Notes in Computer Sci-ence 1872, Springer-Verlag, 2000, pp. 549-563.

Henzinger, T. A., Ho, P.-H., and Wong-Toi, H. (1995).HyTech: The Next Generation. InProc. of the 16thIEEE Real-Time Symposium. IEEE Computer Press.

Henzinger, T. A., Kirsch, C. M., Sanvido, M. A., and Pree,W. (2003). From Control Models to Real-Time CodeUsing Giotto. In IEEE Control Systems Magazine23(1):50-64, 2003.

Hestermeyer, T., Schlautmann, P., and Ettingshausen,C. (2002). Active suspension system for railwayvehicles-system design and kinematics. InProc. ofthe 2nd IFAC - Confecence on mechatronic systems,Berkeley, California, USA.

Honekamp, U. (1998). IPANEMA - Verteilte Echtzeit-Informationsverarbeitung in mechatronischen Syste-men. PhD thesis, Universitat Paderborn, Dusseldorf.

Isermann, R., Lachmann, K.-H., and Matko, D. (1992).Adaptive Control Systems. Prentice Hall, Herford-shire.

Kesten, Y. and Pnueli, A. (1992). Timed and hybridstatecharts and their textual representation. InProc.Formal Techniques in Real-Time and Fault-TolerantSystems, 2nd International Symposium, LNCS 571.Springer-Verlag.

Kuhl, M., Reichmann, C., Protel, I., and Muller-Glaser,K. D. (2002). From object-oriented modeling tocode generation for rapid prototyping of embeddedelectronic systems. InProc. of the 13th IEEE In-ternational Workshop on Rapid System Prototyping(RSP’02), Darmstadt, Germany.

Lamport, L. (1993). Hybrid systems in tla+. Springer.

Luckel, J., Grotstollen, H., Jaker, K.-P., Henke, M., andLiu, X. (1999). Mechatronic design of a modular rail-way carriage. InProc. of the 1999 IEEE/ASME Inter-national Conference on Advanced Intelligent Mecha-tronics (AIM99), Atlanta, GA, USA.

Li, P. Y. and Horowitz, R. (1997). Self-optimizing control.In Proc. of the 36th IEEE Conference on Decision andControl (CDC), pages 1228–1233, San Diego, USA.

Liu-Henke, X., Luckel, J., and Jaker, K.-P. (2000). De-velopment of an Active Suspension/Tilt System fora Mechatronic Railway Carriage. InProc. of the 1stIFAC-Conference on Mechatronics Systems (Mecha-tronics 2000), Darmstadt, Germany.

Lygeros, J., Johansson, K. H., Simic´, S. N., Zhang, J., andSastry, S. S. (2003). Dynamical Properties of Hy-brid Automata. InIEEE TRANSACTIONS ON AUTO-MATIC CONTROL, VOL. 48, NO. 1, JANUARY 2003,volume 48.

Muller, C. and Rake, H. (1999). Automatische Synthese vonSteuerungskorrekturen. InKONDISK-Kolloquium,Berlin.

Richert, J. (1996). Integration of mechatronic design toolswith camel, exemplified by vehicle convoy control de-sign. InProc. of the IEEE International Symposiumon Computer Aided Control System Design, Dearborn,Michigan, USA.

Stauner, T. (2001).Systematic Development of Hybrid Sys-tems. PhD thesis, Technical University Munich.

Stauner, T. (2002). Discrete-time refinement of hybridautomata. In Tomlin, C. and Greenstreet, M., edi-tors, Proceedings of the 5th International Workshopon Hybrid Systems: Computation and Control (HSCC2002), volume 2289 ofLecture Notes in ComputerScience, page 407ff, Stanford, CA, USA.

Stauner, T., Pretschner, A., and Peter, I. (2001). Ap-proaching a Discrete-Continuous UML: Tool Supportand Formalization. InProc. UML’2001 workshop onPractical UML-Based Rigorous Development Meth-ods – Countering or Integrating the eXtremists, pages242–257, Toronto, Canada.

Wieting, R. (1996). Hybrid high-level nets. InProceedingsof the 1996 Winter Simulation Conference, pages 848–855, Coronado, CA, USA.