Fishwick P.A. (editor) Handbook of Dynamic System Modeling

Подождите немного. Документ загружается.

14-22 Handbook of Dynamic System Modeling

Cold

Not cold

IOFF

ION

IOFF

T

FIGURE 14.27 First-level FSM for the boiling water example.

ION

Heating Boiling

Cooling

IOFF

T

T100

FIGURE 14.28 Second-level FSM for the boiling water example.

Heating FBM Cooling FBM

100











兰兰

FIGURE 14.29 Third-level FBM for the boiling water example.

14.5.1 2D Representation

We begin the process by creating 2D representations of dynamic models for the boiling water scene based

on the scene ontology, which is speciﬁed in the previous section, as well as conditions and assumptions

above. Figure 14.27 shows the 2D representation for the highest level of FSM of the boiling water example.

There are two states, “Cold” and “Not Cold.” The input is either ON or OFF. Input can occur at any

time and will facilitate a change in state. Because the “Not Cold” state could be further generalized, we

could insert another FSM inside, as shown in Figure 14.28. To describe the continuous dynamic behaviors

inside “Heating” and “Cooling” states, we need FBMs. Therefore, we could insert two FBMs, as shown in

Figure 14.29, inside “Heating” and “Cooling” states. Figure 14.30 shows the overall 2D dynamic model

representation for the boiling water example.

14.5.2 Model Creation

14.5.2.1 Geometry and Dynamic Models

We create the corresponding geometry and dynamic models for the scene. For geometry model, a teapot

and a stove could be created within Blender Scene Editor (i.e., Blender 3D Window). And then using Model

Explorer,whichisprovidedbyBlender Interface, we create dynamic models for the scene based on the 2D

model representations. We employ a chemistry metaphor to describe the dynamic models instead of simple

primitive objects (i.e., sphere and arrows), since the RUBE library system provides predeﬁned chemistry

objects in the predeﬁned theme folder as well as corresponding MXLs and functions. To represent the“Cold”

Multimodeling 14-23

Cold

Not cold

IOFF

ION

IOFF

ION

T100

ION

IOFF

Heating Boiling

Cooling

T

T=

Heating FBM

100





兰

Cooling FBM







兰

FIGURE 14.30 Multimodel for a boiling water example.

and “Not Cold” states as well as transitions, we use chemistry holders and chemistry pipes, respectively.

And to describe the three states inside the “Not Cold” state and transitions, chemistry glasses and pipes

are employed. In the case of two functional block models, which could be inserted into “Heating” and

“Cooling” states, we use simple primitive objects (i.e., cubes and arrows).

14.5.2.2 Interaction Model

On the basis of the induced interaction model, which is discussed in Section 14.2, for the scene, we

embody the interaction model within the Blender Game Logic. In the Blender Game Logic, there are

sensors, controllers, and actuators. These are used to create“Logic Brick” graphs that drive the interaction.

The Game Engine can cover most interaction behaviors since it has well-deﬁned built-in sensors and

actuators. If a user, however, wants more complicated interactions, the user can handle the interactions

by Python scripting language. After creating a Python ﬁle, the user puts it in one of the controllers and

connects the controller with any proper actuator.

14.5.3 Code Generation

From given dynamic model components in Blender 3D Editor, using the Simulation component, which is

also provided by Blender Interface, we can generate a simulation code for a target system through the RUBE

framework. The simulation code is Python scripting language. The process for generating a simulation

code includes three steps:

1. Blender-to-MXL: First, an MXL ﬁle for a given scene dynamic model is created by gathering all

segmented MXL ﬁles from the libraries, since the library system contains Blender objects as well as

the corresponding MXLs and functions in a set of pairs.

2. MXL-to-DXL: Using XSLT, the MXL ﬁle is converted to a low-level XML language called DXL.

3. DXL-to-Python: The Python code for simulation is generated from DXL using DOM.

14-24 Handbook of Dynamic System Modeling

100





兰

Cold

Not cold

Heating







兰

Cooling

I and T

Current state

Boiling

FIGURE 14.31 DXL Multimodel for the boiling water example.

The “Heating FBM” of Figure 14.29 describes the differential equation T



(100 −T). This FBM is

composed of ﬁve blocks: one integrator, one multiplier, one subtracter, and two constants. Because

each block of this FBM has a synchronous input property, these blocks are translated into blocks having

synchronous inputs in the “Heating DXL” of Figure 14.31. Its arrows are translated into connectors of

the DXL. The “Cooling FBM” of Figure 14.29, which describes the differential equation T



(α −T), is

translated into the “Cooling DXL” model according to the same procedure as the “Heating FBM.”

The two FSMs of Figure 14.27 and Figure 14.28 are translated into Figure 14.31 except for the DXL

models of “Heating” and “Cooling” blocks. Our translator generates the INPUT and OUTPUT blocks to

control the FSM semantics. The right blocks next to INPUT blocks are translated transition blocks, and

the right blocks next to OUTPUT blocks are translated state blocks, such as “Cold,” “Not Cold,” “Boling,”

“Heating,”and“Cooling.”Figure 14.31 shows the translated DXL multimodel for the boiling water example

according to the MXL-to-DXL translation approach. In Figure 14.31, the output of state DXL blocks is

T (the temperature of water). And the output of transition DXL blocks is I and T. We simplify blocks

A–E because of the complexities in Figure 14.31. Figure 14.32 shows the speciﬁc descriptions of blocks

A–E which can be found in Figure 14.31. Because DXL blocks are simple, the total DXL diagram could be

complex. The simpliﬁcation from Figure 14.31 to Figure 14.32 could be used for the optimization of DXL

diagrams in our future research.

Figure 14.33 shows input and temperature trajectories. The input trajectory is displayed in a red line;

turning the knob on and off over some time period. This was chosen at random to display phase switching.

The temperature trajectory, which shows the execution results of simulation code in Python, is displayed in

a blue line. The temperature rises to T =100 in response to the step input and then it falls before reaching

the ambient temperature of T =20. The temperature levels off at T =100.

Figure 14.34 and Figure 14.35 represent the 3D boiling-water scene that contains geometry and dynamic

models. Through user interactions, we can convert a geometry model, which is shown in Figure 14.34, to

a dynamic model, which is shown in Figure 14.35 (chemistry glasses and pipes used to describe states and

transitions), and vice versa (i.e., integrative multimodeling).

Multimodeling 14-25

ION, T

ION,   T  100

ION, T 100

IOFF, T

IOFF,   T  100

IOFF, T 100

ION, T

ION, T 100

ION, T 100

IOFF, T

IOFF,   T  100

IOFF, T 100

OP1

IP1

OP1

OP2

OP1

OP2

OP1

OP2

IP1

IOFF,   T  100

ION,   T  100

ION,

T 100

IOFF,

T

ION,

T

IOFF,

T 100

IOFF,   T  100

ION,   T  100

ION,

T 100

ION,

T

IOFF,

T

IOFF,

T 100

ION,   T  100

IOFF,   T  100

IOFF,

T 100

ION,

T

ION,

T 100

IOFF,

T

ION,   T  100

IOFF,   T  100

IOFF,

T 100

ION,

T

ION,

T 100

IOFF,

T

OP1

OP3

IP1

OP1

IP1

OP1

OP2

IP1

ION,   T  100

IOFF,

T 

IOFF,   T  100

ION,

T  100

I OFF,

T 100

ION,

T 

I ON,   T  100

I OFF,

T  

I  OFF,   T  100

I ON,

T  100

I OFF,

T  100

I ON,

T  

ION,   T  100

IOFF, T  100

IOFF,   T  100

ION,

T  

IOFF,

T  

ION,

T  100

ION,   T  100

IOFF,

T  100

IOFF,   T 100

ION,

T  

IOFF,

T  

ION,

T  100

FIGURE 14.32 Descriptions of blocks A–E.

14-26 Handbook of Dynamic System Modeling

100

51015

Time

Temperature

Off

FIGURE 14.33 Simulation output.

FIGURE 14.34 Initial scene (geometry model).

FIGURE 14.35 Dynamic model.

Multimodeling 14-27

14.6 Conclusion

We have presented the approach and methodology for multimodeling. Also, we have explained and

discussed the multimodeling concepts and environments. Using the example (i.e., boiling water), we have

demonstrated how the multimodeling concepts and semantic Web technology are applied to a real-world

system. The characteristics of this approach are summarized as follows:

•

Web-based modeling and simulation through the use of XML to represent simulation models

•

Multimodeling through ontology, MXL, DXL, and an MXL–DXL bridge

•

Flexible diagrammatic presentation in terms of the functionality for each DXL “block”

•

Port-based modeling and simulation capable of encoding documents rather than data

•

Explicit support for discrete event and continuous simulation.

Several issues remain to be researched, such as model type extension, effective means of composability,

ensuring complete mapping among models and ports, and expanding to remote distributed modeling and

simulation.

References

Berners-Lee, T., Hendler, J., and Lassila, O. 2001. The semantic web. Scientiﬁc American 284(5): 34–43.

Blender, 2006. http://www.blender3d.org/.

Carey, R. and Bell, G. 1997. The Annotated VRML 2.0 Reference Manual. Reading, MA: Addison-Wesley.

Cubert, R. M. and Fishwick, P. A. 1998. MOOSE: An object-oriented multimodeling and simulation

application framework. Simulation 70(6): 379–395.

Damkjer, K. L. 2003. Architecting RUBE worlds: A methodology for creating virtual analog devices as

metaphorical representations of formal systems. M.S. Thesis, University of Florida.

Eisenberg, D. 2002. SVG Essentials. Sebastopol, CA: O’Reilly.

Fishwick, P. A. 1992. SimPack: Getting started with simulation programming in C and C++. In Proceedings

of the 1992 Winter Simulation Conference: 154–162.

Fishwick, P. A. 1995. Simulation Model Design and Execution: Building Digital Worlds. Englewood Cliffs,

NJ: Prentice-Hall.

Fishwick, P. A. 2002. RUBE: An XML-based architecture for 3D process model fusion. In Proceedings of

Enabling Technology for Simulation Science within SPIE ’02 AeroSense Conference: 330–335.

Fishwick, P. A. 2002. Using XML for simulation modeling. In Proceedings of the 2003 Winter Simulation

Conference: 616–622.

Fishwick, P. A. 2004. Toward an integrative multimodeling interface: A human–computer interface

approach to interrelating model structures. Simulation 80(9): 421–432.

Fishwick, P. A., Lee, J., Park, M., and Shim, H. 2003. RUBE: A customized 2D and 3D modeling framework

for simulation. In Proceedings of the 2003 Winter Simulation Conference: 755–762.

Horrocks, I., Patel-Schneider, P. F., Boley, H., Tabet, S., Grosof, B., and Dean, M. 2004. SWRL: A semantic

web rule language combining OWL and ruleML. http://www.daml.org/2004/04/swrl/.

Jess, 2006. http://herzberg.ca.sandia.gov/jess/.

Kay, M. 2000. XSLT Programmer’s Reference. Birmingham, UK: Wrox Press.

Kim, T. 2002. A 3D XML-based modeling and simulation framework for dynamic models. Ph.D.

Dissertation, University of Florida.

Kim, T. and Fishwick, P. A. 2002a. A 3D XML-based customized framework for dynamic models. In

Proceedings of the Seventh International Conference on 3D Web Technology: 103–109.

Kim, T. and Fishwick, P. A. 2002b. An XML-based visualization and simulation framework for dynamic

models. In Proceedings of Enabling Technology for Simulation Science within SPIE’02 AeroSense

Conference: 336–347.

Kim, T., Lee, J., and Fishwick, P. A. 2002. A two-stage modeling and simulation process for web-based

modeling and simulation. ACM Transactions on Modelingand Computer Simulation, 12(3): 230–248.

14-28 Handbook of Dynamic System Modeling

Lacy, L. 2005. OWL: Representing Information Using the Web Ontology Language. New Bern, NC: Trafford

Publishing.

Lee, J. 2005. Architecture for a low-level functional speciﬁcation language supporting multimodeling and

simulation. Ph.D. Dissertation, University of Florida.

Lee, J. and Fishwick, P. A. 2002. A dynamics exchange language layer for rube.InProceedings of Enabling

Technologies for Simulation Science within SPIE’02 AeroSense Conference: 359–366.

McGuinness, D. L. 2002. Ontologies come of age. In D. Fensel, J. Hendler, H. Lieberman, and W. Wahlster,

Eds, Spinning the Semantic Web: Bringing the World Wide Web to Its Full Potential, 171–194.

Cambridge, MA: MIT Press.

McGuinness, D. L. and Harmelen, F. 2003. OWL web ontology language overview. http://www.w3.org/

TR/owl-features.

Park, M. 2005. Ontology-based customizable 3D modeling for simulation. Ph.D. Dissertation, University

of Florida.

Park, M. and Fishwick, P. A. 2002. SimPackJ/S: A web-oriented toolkit for discrete event simulation. In

Proceedings of Enabling Technology for Simulation Science within SPIE ’02 AeroSense Conference:

348–358.

Park, M. and Fishwick, P. A. 2004a. An Integrated Environment Blending Dynamic and Geometry Models.

Lecture Notes in Computer Science Series, Volume 3397: 574–584. Berlin: Springer.

Park, M. and Fishwick, P. A. 2004b. A methodology for integrative multimodeling: Connecting dynamic

and geometry models. In Proceedings of Enabling Technology for Simulation Science within SPIE’04

AeroSense Conference: 9–17.

The Protégé Ontology Editor and Knowledge Acquisition System, 2006. http://protege.stanford.edu/.

RACER, 2006. http://www.sts.tu-harburg.de/∼r.f.moeller/racer/.

Roosendaal, T. and Selleri, S. 2004. Blender 2.3 Guide. Amsterdam, The Netherlands: Blender Foundation.

Roosendaal, T. and Wartmann,C. 2002. The Ofﬁcial Blender Gamekit: Interactive 3D for Artists. Amsterdam,

The Netherlands: Blender Foundation.

Sodipodi, 2006. http://sodipodi.sourceforge.net/.

X3D, 2006. http://www.web3d.org/x3d/.

Hybrid Dynamic Systems:

Modeling and Execution

Pieter J. Mosterman

The MathWorks, Inc.

15.1 Introduction .................................................................15-1

15.2 Hybrid Dynamic Systems ............................................15-3

Why Hybrid Dynamic Systems?

•

What Is a Hybrid

Dynamic System

•

How Are Hybrid Dynamic System

Models Designed?

15.3 Hybrid Dynamic System Behaviors.............................15-9

An Operational Structure

•

Continuous-Time Behavior

•

Handling Mode Transitions

•

Reinitialization of

State Variables

15.4 An Implementation ......................................................15-12

Classes of Events

•

Classes of Temporal Behavior

•

Time-Driven Execution

•

Event-Driven Execution

•

Combining the Execution Types

15.5 Advanced Topics in Hybrid Dynamic

System Simulation ....................................................... 15-17

Zero-Crossing Detection

•

Mode Changes

15.6 Pathological Behavior Classes .....................................15-22

15.7 Conclusions ..................................................................15-23

15.1 Introduction

To remain competitive, organizations throughout industry are increasingly adopting Model-Based Design.

Computational models take a central position in Model-Based Design as illustrated in Figure 15.1. The

use of models throughout the design of engineered systems has a number of advantages. In Figure 15.1,

four of these are shown:

•

Early evaluation ensures the appropriateness, consistency, rigor, and unambiguity of requirements.

•

Simulation allows quick design iterations while the use of models makes it possible to search a very

large design space efﬁciently.

•

Automatic code generation eliminates the expensive manual coding, which is labor-intensive and

error-prone.

•

Test vector sets can be composed in the early designstages, based on a system model, thus eliminating

much of the lead time needed in traditional testing, which requires the real system to be available.

Veriﬁcation of completeness and parsimony of the design can be done before implementation.

Overall, from a business perspective, Model-Based Design allows a shorter design cycle so engineers can

develop better products at a lower cost.

The models that are used throughout the product design have to address many different aspects. For

example, structuring requirements may be best done by modeling scenarios and in an axiomatic manner,

15-1

15-2 Handbook of Dynamic System Modeling

Executable specifications

from models

Continuous

test and

verification

Design with

simulation

Simulink

models

Implementation with

automatic code generation

FIGURE 15.1 Model-based design.

FIGURE 15.2 A power window.

while the numerical models with an intensive data processing aspect are often best represented in a

declarative manner. Meanwhile, execution models typically are best captured in an imperative manner.

Similarly, certain modeling tasks are best addressed by continuous-time models, while other tasks may

be better performed with discrete-time or untimed models. For example, consider the power window in

Figure 15.2 (Mosterman et al., 2004). Modeling the behavior of the window sliding up and down is often

easiest using continuous-time differential equations, employing laws of physics such as Newton’s Second

Law of Motion that the acceleration, a, of a mass, m, is determined by the force, F, applied to it, F =m ·a,

where the acceleration is the time-derivative of velocity, v, a =

In contrast, the desired behavior to start moving the window when the user presses a button is often

best viewed as discrete in nature. An event windowUp then causes a state change from neutral to moveUp.

At certain stages during the design, such an untimed model may be sufﬁcient and even desired, as it leaves

any implementation choices on how to achieve such control still open.

Hybrid Dynamic Systems: Modeling and Execution 15-3

To implement the control of the power window, an electronic control unit that operates at a certain

sample rate can be selected. In this implementation, the untimed events can be modeled to occur at points

in time. During the ﬁxed intervals of time in between, no changes of the variable values in the model

occur. This leads to a discrete time but periodic model.

Yet another task may consist of modeling the network that transmits the user command to move

the window up to the controller that effects this command. In automobiles, these commands may be

transmitted over a controller area network (CAN) (CAN speciﬁcation, 1991), that is also used to transmit

other commands such as moving the headlights up and down, adjusting the outside mirrors, and opening

the sunroof. At a certain level, the network trafﬁc can be thought of as discrete time but nonperiodic, since

commands may be initiated with very different intervals of time in between.

When the integration of different parts of a system is studied, it becomes necessary to employ the

different models in concert (Mosterman et al., 2005). This can be done in a number of ways. For example,

the different types of models can be combined, integrated, and translated. Whichever approach is chosen,

the result is likely to include both continuous-time and discrete-event behavior, and the overall system

isoftenreferredtoasahybrid dynamic system,orhybrid system for short.

It is important to stress, at

this point, that an engineered system is not inherently a “hybrid system.” A hybrid system is a term for a

mathematical representation not a physical system. Whether an engineered system is modeled as a hybrid

system depends on the problem that needs to be solved, the level of abstraction chosen, the phenomena

the system embodies, and the background of the model designer (Mosterman and Vangheluwe, 2004).

This chapter intends to provide a bird’s eye view of the modeling and execution of hybrid systems.

Some of the uses of hybrid systems will be presented, and the different ways of simulating them and

their idiosyncrasies will be investigated. In Section 15.2, hybrid dynamic systems are presented: what they

are, how they come about, and what different modeling perspectives exist. In Section 15.3, the behavioral

perspectiveis discussed and the different behavioralaspects are introduced. In Section 15.4, the two possible

implementations of an execution engine, time- and event-driven implementation, and combinations

are introduced. Section 15.5 then presents advanced topics with regards to numerical simulation. In

Section 15.6 a number of pathological behaviors that may arise in simulation are discussed. Section 15.7

presents the conclusions of this work.

15.2 Hybrid Dynamic Systems

This section illustrates where the need for hybrid dynamic systems emerges from in embedded control

systems design, what the mathematical notions are that hybrid dynamic systems involve, and the modeling

concepts that require these notions.

15.2.1 Why Hybrid Dynamic Systems?

A power window will serve to illustrate the application of hybrid dynamic systems in the design of

engineered systems. This example has been studied in more detail in other work (Mosterman et al., 2004;

Mosterman and Vangheluwe, 2004) and is part of the Simulink

(Simulink, 2004) automotive demos.

The elements of interest in this context are illustrated on the left-hand side in Figure 15.3, along with

exemplary data as used in the design and analysis on the right-hand side. In the center near the top is the

window lift mechanism. A dc motor translates the electrical signals that reﬂect the controller commands

into movement in the mechanical domain. A current sensor is used to measure the current drawn by the

dc motor, which is used by the controller to determine whether the top or bottom of the window frame is

reached. Behavior of these components is often modeled as continuous in time.

The controller is often modeled as operating at a periodic sample rate and it may receive the user input

over a CAN. This network provides communication between the electronic control units (ECUs) in an

Note that omitting the adjective “dynamic” may lead to confusion with hybrid systems such as mixed neural

network/fuzzy logic systems and combined electrical/mechanical drivetrains.