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

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

34-16 Handbook of Dynamic System Modeling

012345678

System response

Time

FIGURE 34.17 Output of the manufacturing system.

In words, machine M

should only start producing as soon as the buffer contents of the buffer in front of

it becomes 1. Therefore, we should not allow for a positive u

as soon as y

> 0, but only in case y

≥1.

When we consider the initially empty system Eq. (34.7), i.e., x(0) =0, and assume

(t) =

⎧

⎨

⎩

if y

(t) ≥ 1

i ∈{1, 2}

0 otherwise

(34.15)

the resulting system response to an input of u

=1 is shown in Figure 34.17. Note that we obtain exactly

the same response as in Figure 34.15.

While this hybrid model has an acceptable behavior when we ramp up our manufacturing system,

it stops producing at buffer level y

=1 when we ramp down. This is not what we would like to have.

Therefore, in case u

=0, machine M

should be allowed to produce until y

=0.

Under these conditions, we could also think of our model operating in different modes. For the

manufacturing system under consideration, we can distinguish the following modes:

mode 1: 0 ≤y

≤1, 0 ≤y

≤1, u

= 0, u

≥0, u

=0.

mode 2: 0 ≤y

≤1, 0 ≤y

≤1, u

≥0, u

=0, u

≥0.

mode 3: 1 ≤y

,0≤y

≤1, u

=0, u

≥0.

mode 4: 1 ≤y

,0≤y

≤1, u

≥0, u

=0.

mode 5: 0 ≤y

≤1, 1 ≤y

, u

=0, u

≥0.

mode 6: 0 ≤y

≤1, 1 ≤y

, u

≥0, u

=0.

mode 7: 1 ≤y

,1≤y

In all of these modes, the system dynamics is described by Eq. (34.7).

The hybrid model just presented is also known as a piecewise afﬁne (PWA) system (Sontag, 1981).

Other well-known descriptions are linear complementarity (LC) systems (Heemels et al., 2000; Schaft

and Schumacher, 1998) and mixed logical dynamical (MLD) systems (Bemporad and Morari, 1999). In

Bemporad et al. (2000b) and Heemels et al. (2001) it was shown that (under certain assumptions like

well-posedness) these three descriptions are equivalent. This knowledge is useful, as each modeling class

has its own advantages. Stability criteria for PWA systems were proposed in DeCarlo et al. (2000) and

Johansson and Rantzer (1998), and control and state-estimation techniques for MLD hybrid models have

been presented in Bemporad et al. (2000a, 1999) and Bemporad and Morari (1999). These results can now

be applied for controlling the hybrid systems model of our manufacturing system.

34.8 Flow Models

The ﬂuid models presented in the previous section are (still) not satisfactory. While they do not suffer

from the problem that lots come out of the system as soon as we start producing, ﬂow times are not truly

present in these models. It is not possible to determine the time it takes lots to leave once they have entered

Modeling and Analysis of Manufacturing Systems 34-17

the system. Furthermore, according to these models any throughput can be achieved by means of zero

inventory, whereas in Section 34.2 we already noticed that the nonlinear (steady-state) relations depicted

in Figure 34.2 should be incorporated in any reasonable model of manufacturing systems.

In this section, we present approximation models that do incorporate both throughput and ﬂow

time. These dynamic models are inspired by the continuum theory of highway trafﬁc. Therefore, before

presenting this dynamic model we ﬁrst present some results from trafﬁc theory.

34.8.1 Introduction to Trafﬁc Flow Theory: The LWR Model

In the mid-1950s Lighthill and Whitham (1955) and Richards (1956) proposed a ﬁrst-order ﬂuid approx-

imation of trafﬁc ﬂow dynamics. This model nowadays is known in trafﬁc ﬂow theory as the LWR

model.

Trafﬁc behavior for a single one-way road can be described using three variables that vary in time t and

space x:ﬂowu(x, t), density ρ(x, t), and speed v(x, t). Flow is the product of speed and density:

u(x, t) = ρ(x, t)v(x, t) ∀x, t (34.16)

For a highway without entrances or exits, the number of cars between any two locations x

and x

< x

)

needs to be conserved at any time t, i.e., the change in the number of cars between x

and x

is equal to

the ﬂow entering via x

minus the ﬂow leaving via x

∂

∂t



ρ(x, t)dx = u(x

, t) −u(x

, t) (34.17a)

or in differential form:

∂ρ

∂t

(x, t) +

∂u

∂x

(x, t) = 0 (34.17b)

The two relations Eq. (34.16) and Eq. (34.17) are basic relations that any model must satisfy. As we have

three variables of interest, a third relation is needed. For this third relation, several choices can be made.

The LWR model assumes in addition to the relations Eq. (34.16) and Eq. (34.17) that the relation between

ﬂow and density observed under steady-state conditions also holds when ﬂow and density vary with x

and/or t; i.e., for a homogeneous highway:

u(x, t) = S(ρ(x, t)) (34.18)

The model given by Eqs. (34.16)–(34.18) can predict some trafﬁc phenomena rather well. To overcome

some of the deﬁciencies of the LWR model, in the early 1970s higher order theories have been proposed

where Eq. (34.18) has been replaced by another partial differential equation, containing diffusion or

viscosity terms. Unfortunately, these extended models experience some undesirable properties, as made

clear in (Daganzo, 1995). The most annoying of these properties is the fact that in these second-order

models cars can travel backward. Second-order models that do not suffer from this deﬁciency have been

presented in Jiang et al. (2002) and Zhang (2002).

34.8.2 A Trafﬁc Flow Model for Manufacturing Flow

In the previous subsection, we introduced the LWR model from trafﬁc ﬂow theory. This model describes

the dynamic behavior of cars along the highway at a macroscopic level and contains information both

about the number of cars passing a certain point and about the time it takes cars to go from one point to

the other. The LWR model can not only be used for describing the ﬂow of cars along the highway, but also

for describing the ﬂow of products through a manufacturing line.

Consider, instead of a homogeneous highway, a homogeneous manufacturing line, i.e., a manufacturing

line that consistsof a lot of identical machines. Let t denote the time and x the position in the manufacturing

line. The behavior of lots ﬂowing through the manufacturing line can also be described by three variables

34-18 Handbook of Dynamic System Modeling

that vary with time and position: ﬂow u(x, t) measured in unit lots per unit time, density ρ(x, t) measured

in unit lots per unit machine, and speed v(x, t) measured in unit machines per unit time. Now we can

relate these three variables by means of Eqs. (34.16)–(34.18), where in Eq. (34.18) the function S describes

the relation between ﬂow and density observed under steady-state conditions.

To make this last statement more explicit, consider a manufacturing line consisting of m machines with

exponentially distributed process times and an average capacity of µ lots per unit time. Furthermore,

consider a Poisson arrival process where lots arrive at the ﬁrst machine with a rate of λ lots per unit time

(λ<µ), and assume that buffers have inﬁnite capacity. Then we know from queueing theory (Kleinrock,

1975) that the average number of lots N in each workstation (consisting of a buffer and a machine) in

steady-state is given by

N =

1 −

µ −λ

(34.19)

In words, in steady-state we have ρ(x, t) is constant and

ρ(x, t) =

u(x, t)

µ −u(x, t)

(34.20)

from which we can conclude that in steady-state

u(x, t) =

µρ(x, t)

m +ρ(x, t)

(34.21)

For this example, this is the mentioned function S(ρ).

With this information, we can conclude that the dynamics of this manufacturing line might be described

by means of the partial differential equation

∂ρ

∂t

+µ

∂

∂x



m +ρ



= 0 (34.22a)

Together with the relations

u =

µρ

m +ρ

and v =

or v =

m +ρ

(34.22b)

this completes our model.

Note that contrary to the ﬂuid models presented in the previous section, the dynamic model of

Eq. (34.22) is able to incorporate the stochasticity as experienced in manufacturing lines. If the man-

ufacturing line would be in steady-state, the throughput and ﬂow time as predicted by the model of

Eq. (34.22) is exactly the same as those predicted by queueing theory. However, contrary to queueing

theory, the model of Eq. (34.22) is not a steady-state model, but also incorporates dynamics. Therefore,

the model Eq. (34.22) is a dynamic model that incorporates both throughput and ﬂow time. Furthermore,

given the experience in the ﬁeld of ﬂuid dynamics, the model is computationally feasible as well. For more

on these ﬂow models, the interested reader is referred to Armbruster et al. (2004, 2005) and Armbruster

and Ringhofer (2005).

34.9 Conclusions

In this chapter, we presented some of the models used in the modeling, analysis, and control of manufactur-

ing systems. In Section 34.3 some analytical modeling techniques and methods for analyzing steady-state

behavior of manufacturing systems have been introduced. To get a more detailed insight in the dynamics of

a manufacturing system discrete-event models, as introduced in Section 34.4 can be used. A disadvantage

Modeling and Analysis of Manufacturing Systems 34-19

of discrete-event models is their complexity. To reduce the complexity of discrete-event models, EPTs have

been introduced in Section 34.5. This enables the modeling of a manufacturing system as a large queueing

network.

Once the dynamics of manufacturing systems can be well described by a relatively simple discrete-

event model, the problem of controlling the dynamics of manufacturing systems becomes of interest.

In Section 34.6 a control framework has been presented. A crucial role in this framework is played

by approximation models of manufacturing systems. In Section 34.7 the most common approximation

models, ﬂuid models, have been introduced, together with some extensions of these models. These ﬂuid

models mainly focus on throughput and do not contain information on ﬂow times. Finally, in Section 34.8,

ﬂow models have been presented that do incorporate both throughput and ﬂow time information.

References

Armbruster, D., P. Degond, and C. Ringhofer (2005). Continuum models for interacting machines. In

D. Armbruster, K. Kaneko, and A. Mikhailov (Eds.), Networks of Interacting Machines: Produc-

tion Organization in Complex Industrial Systems and Biological Cells. Singapore: World Scientiﬁc

Publishing.

Armbruster, D., D. Marthaler, and C. Ringhofer (2004). Kinetic and ﬂuid model hierarchies for supply

chains. SIAM Journal on Multiscale Modeling and Simulation 2(1), 43–61.

Armbruster, D. and C. Ringhofer (2005). Thermalized kinetic and ﬂuid models for re-entrant supply

chains. SIAM Journal on Multiscale Modeling and Simulation 3(4), 782–800.

Baker Jr., G. A. (1965).The theory and application of the Pade approximant method. In K. A. Brueckner

(Ed.), Advances in Theoretical Physics, Volume 1, pp. 1–58. New York: Academic Press.

Bemporad, A., F. Borrelli, and M. Morari (2000a, June). Piecewise linear optimal controllers for hybrid

systems. In Proceedings of the 2000 American Control Conference, Chicago, IL, pp. 1190–1194.

Bemporad, A., G. Ferrari-Trecate, and M. Morari (2000b, October). Observability and controllability of

piecewise afﬁne and hybrid systems. IEEE Transactions on Automatic Control 45(10), 1864–1876.

Bemporad, A., D. Mignone, and M. Morari (1999, June). Moving horizon estimation for hybrid sys-

tems and fault detection. In Proceedings of the 1999 American Control Conference, San Diego, CA,

pp. 2471–2475.

Bemporad, A. and M. Morari (1999). Control of systems integrating logic, dynamics, and constraints.

Automatica 35, 407–427.

Curtain, R. F. and H. Zwart (1995). An Introduction to Inﬁnite-Dimensional Linear Systems Theory. Berlin,

Germany: Springer.

Daganzo, C. F. (1995). Requiem for second-order ﬂuid approximations of trafﬁc ﬂow. Transportation

Research Part B 29(4), 277–286.

DeCarlo, R. A., M. Branicky, S. Petterson, and B. Lennartson (2000). Perspectives and results on the

stability and stabilizability of hybrid systems. Proceedings of the IEEE 88(7), 1069–1082.

Forrester, J. W. (1961). Industrial Dynamics. Cambridge, MA: MIT Press.

Heemels, W. P. M. H., J. M. Schumacher, and S. Weiland (2000). Linear complementarity systems. SIAM

Journal on Applied Mathematics 60(4), 1234–1269.

Heemels, W. P. M. H., B. d. Schutter, and A. Bemporad (2001). Equivalence of hybrid dynamical models.

Automatica 37(7), 1085–1091.

Hopp, W. J. and M. L. Spearman (2000). Factory Physics, second ed. New York: Irwin/McGraw-Hill.

Jacobs, J. H., P. P. v. Bakel, L. F. P. Etman, and J. E. Rooda (2006). Quantifying variability of batching

equipment using effective process times. IEEE Transactions on Semiconductor Manufacturing 19(2),

269–275.

Jacobs, J. H., L. F. P. Etman, E. J. J. v. Campen, and J. E. Rooda (2003). Characterization of the operational

time variability using effective processing times. IEEE Transactions on Semiconductor Manufacturing

16(3), 511–520.

34-20 Handbook of Dynamic System Modeling

Jiang, R., Q. S. Wu, and Z. J. Zhu (2002). A new continuum model for trafﬁc ﬂow and numerical tests.

Transportation Research. Part B, Methodological 36, 405–419.

Johansson, M. and A. Rantzer (1998). Computation of piece-wise quadratic Lyapunov functions for hybrid

systems. IEEE Transactions on Automatic Control 43(4), 555–559.

Kingman, J. F. C. (1961). The single server queue in heavy trafﬁc. Proceedings of the Cambridge Philosophical

Society 57, 902–904.

Kleinrock, L. (1975). Queueing Systems, Volume I: Theory. New York: Wiley.

Kuehn, P. J. (1979). Approximate analysis of general queueing networks by decomposition. IEEE

Transactions on Communication 27, 113–126.

Lighthill, M. J. and J. B. Whitham (1955). On kinematic waves. I: Flow movement in long rivers. II:

A theory of trafﬁc ﬂow on long crowded roads. Proceedings of the Royal Society A 229, 281–345.

Little, J. D. C. (1961). A proof of the queueing formula l =λw. Operations Research 9, 383–387.

Richards, P. I. (1956). Shockwaves on the highway. Operations Research 4, 42–51.

Sattler, L. (1996, November). Using queueing curve approximations in a fab to determine productivity

improvements. In Proceedings of the 1996 IEEE/SEMI Advanced Semiconductor Manufacturing

Conference and Workshop. Cambridge, MA, pp. 140–145.

Schaft, A. J. v. d. and J. M. Schumacher (1998). Complementarity modelling of hybrid systems. IEEE

Transactions on Automatic Control 43, 483–490.

Sontag, E. D. (1981). Nonlinear regulation: the piecewise linear approach. IEEE Transactions on Automatic

Control 26(2), 346–358.

Zhang, H. M. (2002). A non-equilibrium trafﬁc model devoidof gas-like behavior. Transportation Research.

Part B, Methodological 36, 275–290.

Sensor Network

Component-Based

Simulator

Boleslaw K. Szymanski

Rensselaer Polytechnic Institute

Gilbert Gang Chen

Rensselaer Polytechnic Institute

35.1 The Need for a New Sensor Network Simulator ........35-1

Why a New Simulator

•

Features of SENSE

•

Currently

Available Components and Simulation Engines

35.2 Component Simulation Toolkit ..................................35-3

Motivation:FromObjecttoComponent

•

Functor

•

Inport and Outport Class

•

Simulation Time and

Port Index

•

Timer

35.3 Wireless Sensor Network Simulation ..........................35-7

Running the Simulation

35.4 Conclusions ..................................................................35-15

35.1 The Need for a New Sensor Network Simulator

The emergence of wireless sensor networks brought many open issues to network designers. Traditionally,

the three main techniques for analyzing the performance of wired and wireless networks are analytical

methods, computer simulation, and physical measurement. However, because of many constraints imposed

on sensor networks, such as energy limitation, decentralized collaboration, and fault tolerance, algorithms

for sensor networks tend to be quite complex and usually defy analytical methods that have been proved

to be fairly effective for traditional networks. Furthermore, few sensor networks have come into existence,

for there are still many unsolved research problems, so measurement is virtually impossible. It appears

that simulation is the only feasible approach to the quantitative analysis of sensor networks.

35.1.1 Why a New Simulator

A good simulator possesses two essential features. First, it must support reusable models. A model written

for one simulation should be amenable to effortless embedding into other simulations that require the same

kind of a model. Second, the model should be easy to be built from scratch. Interestingly, we observe that

most existing simulators do not possess these two features simultaneously. Most commercial simulators

provide a reusable model library, often coming with a friendly graphical user interface, but adding new

models to the library is always a painful task. However, most freely available simulators follow a bottom-up

approach; writing models from scratch is straightforward, but the reusability is severely limited.

ns2 (ns2, 1990), perhaps the most widely used network simulator, has been extended to include some

basic facilities to simulate sensor networks. However, one of the problemsof ns2 is its object-oriented design

that introduces much unnecessary interdependency between modules. Such interdependency sometimes

makes the addition of new protocol models extremely difﬁcult, only mastered by those who have intimate

35-1

35-2 Handbook of Dynamic System Modeling

familiarity with the simulator. Being difﬁcult to extend is not a major problem for simulators targeted at

traditional networks, for there, the set of popular protocols is relatively small. For example, Ethernet is

widely used for wired LAN, IEEE 802.11 for wireless LAN, and TCP for reliable transmission over unreliable

media. For sensor networks, however, the situation is quite different. There are no such dominant protocols

or algorithms and there will unlikely be any, because a sensor network is often tailored for a particular

application with speciﬁc features, and it is unlikely that a single algorithm can always be the optimal one

under various circumstances.

Many other publicly available network simulators, such as JavaSim (Javasim, 2004), SSFNet (ssfnet,

2000), Glomosim (GloMoSim, 2004), and its descendant Qualnet (Qualnet, 2004), attempted to address

problems that were left unsolved by ns2. Among them, JavaSim developers realized the drawback of object-

oriented design and tried to attack this problem by building a component-oriented architecture. However,

they chose Java as the simulation language, inevitably sacriﬁcing the efﬁciency of the simulation. Moreover,

C++ with Standard Template Library (Musser and Saini, 1996) can easily achieve high efﬁciency while

maintaining a high level of code reuse, which matched our design goal better than Java. SSFNet and

Glomosim designers were more concerned about parallel simulation, with the latter more focused on

wireless networks. They are not superior to ns2 in terms of design and extensibility.

35.1.2 Features of SENSE

SENSE is designed to be an efﬁcient and powerful sensor network simulator that is also easy to use. We

identify three most critical factors as

•

Extensibility: The enabling force behind the fully extensibility network simulation architecture is

our progress on component-based simulation. We introduced a component-port model that frees

simulation models from interdependency usually found in an object-oriented architecture, and

then proposed a simulation component classiﬁcation that naturally solves the problem of handling

simulated time. The component-port model makes simulation models extensible: a new component

can replace an old one if they have compatible interfaces, and inheritance is not required. The

simulation component classiﬁcation makes simulation engines extensible: advanced users have the

freedom to develop new simulation engines that meet their needs.

•

Reusability: The removal of interdependency between models also promotes reusability. A compo-

nent developed for one simulation can be used in another if it satisﬁes the latter’s requirements on

the interface and semantics. There is another level of reusability made possible by the extensive use

of C++template: a component is usually declared as a template class so that it can handle different

types of data.

•

Scalability: Unlike many parallel network simulators, especially SSFNet and Glomosim, paralleliza-

tion is providedas an option to the users of SENSE. This reﬂects our belief that completely automated

parallelization of sequential discrete-event models, however tempting it may seem, is impossible,

just as automated parallelization of sequential programs. Even if it is possible, it is doomed to be

inefﬁcient. Therefore, parallelizable models require larger effort than sequential models do, but a

good portion of users are not interested in parallel simulation at all. In SENSE, a parallel simulation

engine can only execute components of compatible components. If a user is content with the default

sequential simulation engine, then every component in the model repository can be reused.

35.1.3 Currently Available Components and Simulation Engines

•

Battery Model: Linear Battery, Discharge Rate Dependent and Relaxation Battery

•

Application Layer : Random Neighbor; Constant Bit Rate

•

Network Layer: Simple Flooding; a simpliﬁed version of ADOV without route repairing, a simpliﬁed

version of DSR without route repairing

•

MAC Layer: NullMAC; IEEE 802.11 with DCF

Sensor Network Component-Based Simulator 35-3

•

Physical Layer: Duplex Transceiver; Wireless Channel

•

Simulation Engine: CostSimEng (sequential)

35.2 Component Simulation Toolkit

Component-oriented simulation toolkit (COST) is a general-purpose discrete-event simulator (Chen and

Szymanski, 2001). The main design purpose of COST is to maximize the reusability of simulation models

without losing efﬁciency. To achieve this goal, COST adopts a component-based simulation worldview

based on a component-port model. A simulation is built by conﬁguring and connecting a number of

components, either off the shelf or fully customized. Components interact with each other only via input

and output ports, thus the development of a component becomes completely independent of others.

The component-port model of COST makes it easy to construct simulation components from scratch.

Implemented in C++, COST also features a wide use of templates to facilitate language-level reuse.

COST is a library of several classes that facilitates the development of discrete-event simulation using

CompC++, a component-oriented extension to C++. It differs from many other tools in the simulation

worldview it adopts. There are primarily two worldviews that are widely used in the discrete-event simula-

tion community: event scheduling and process interaction. Both have their strengths and weaknesses. The

event scheduling is much more efﬁcient, but it is hard to program. Process interaction technique requires

less programming effort. However, it is difﬁcult to implement using imperative programming languages

and many implementations based on special simulation languages are not efﬁcient.

COST adopts a component-oriented worldview, which is a variation of the event scheduling worldview.

Using this technique, a discrete-event simulation is viewed as a collection of components that interact with

each other by exchanging messages through communication ports. Besides components, the simulation

contains a simulation engine that is responsible for synchronizing components. An event-oriented view

is adopted to model individual components, i.e., the component has one or more event handlers each of

which performs corresponding actions upon the arrival of a certain type event. Events are divided into

two categories. Synchronous events are the messages arriving at the input ports, which are sent by its

neighboring components. Asynchronous events are associated with timers, a special kind of ports lying

between the components and the simulation engine. Components receive and schedule asynchronous events

through timers.

COST takes advantage of component-oriented features that are only available in CompC++.

35.2.1 Motivation: From Object to Component

Convenient and powerful as object-oriented programming is, it has its limits. One of these is that it often

imposes unnecessary interobject dependence on the deployment of objects that prevents objects from

being reusable. As a small example, in Figure 35.1, an object A calls a method g() of another object B.

Object A must keep a pointer (or a reference) to object B to make such a method call. Let us assume that

these two objects have been set up correctly in one program. The difﬁculty arises when A is to be reused

B*pb;

Object A

void f()

{

...

pb⫺⬎g();

...

}

Object B

void q()

{

...

}

FIGURE 35.1 Object dependencies in object-oriented languages.

35-4 Handbook of Dynamic System Modeling

Component A

Outport void h();---

void f()

{

...

h();

...

}

Component B

–––Inport void g()

{

...

}

FIGURE 35.2 Component dependencies in component-oriented simulation.

in another program. Obviously, in such a case, either B must also be moved over to the new program, or

there is another object that is derived from B available for A to access. If it is the former, things will become

worse if some of B’s methods are dependent on another object C. As a result, any object that A depends

upon, either directly or indirectly, must be available in the new program.

Yet we only need, in the above example, a method that provides the same functionality as B.g() does. We

should not be concerned with which object can provide such a functionality, whether it be B or a different,

completely unrelated object D. In object-oriented programming, once you make an interobject method

call, you not only introduce explicit interobject dependence manifested by the method call (represented

by the solid arrow in the Figure 35.1), but also implicit dependence that is hard to trace and maintain

(represented by the dashed arrow).

The solution is to introduce inports and outports. The use of inports and outports has been introduced

in DEVS formalism (Zeigler et al., 1997; DEVS, 2004); however, in our approach their role have expanded

to become, next to component themselves, an integral part of composing simulations. An inport deﬁnes

what functionality an object (now it is becoming a component) provides, and an outport deﬁnes what

functionality it needs. In Figure 35.2, it is apparent that the implicit dependence has been removed.

Another beneﬁt of having inports and outports is that any interaction a component may have with other

components can be deduced only from its interface (which is composed of declarations of inports and

outports). In contrast, for an object, the same information is clear only after scanning through the entire

source code.

The central idea of CompC++is to add inports and outports to objects to make them look and function

like components. The extension to the standard C++ language is minimal: only four new keywords

(component, inport, outport, and connect) and four new syntactic rules are needed. The addition of these,

nevertheless, opens up a whole new programming paradigm, which is referred to as component-oriented

programming.

35.2.1.1 Implementation of COST

The ﬁrst issue of implementing the aforementioned simulation component model is the choice of the

implementing language. Discrete-event simulators can be roughly divided into two groups: those based

on a special simulation language, such as GPSS and SIMSCRIPT (Law and Kelton, 1982), and those based

on a general programming language, such as SIMPACK (Fishwick, 1992) and SIMKIT (Gomes et al.,

1995) Simulation languages contain abundant semantics designed for simulation, but requires a steep

learning curve. General programming languages are more familiar to programmers, but lack the essential

simulation constructs.

We chose C++as the implementation language for two reasons. First, general programming languages

always have good compiler support, and thus their execution speed is generally faster after optimization.

Second, language-level reusability is a factor as important as component-level reusability, and C++is one

of the few languages that support code reuse well. With STL (Austern, 1999; Musser and Saini, 1996), C++

programs can easily achieve high efﬁciency while maintaining a high level of code reuse, which matches

our design goal.

Sensor Network Component-Based Simulator 35-5

However, with C++we ran into a problem. As mentioned in the last section, input ports are equivalent to

functions, so it is natural to deﬁne them as member functions of the component. But how can we represent

output ports? C++ language standard requires that the address of an object must be provided when

the member function is being called. This conﬂicts with the requirement that component development

should be completely independent. The classical solution for such a problem is a functor, which is the

generalization of the function pointer.

35.2.2 Functor

A functor, or a function object, is an object“that can be called in the same way that a function is” (Austern,

1999; Musser and Saini, 1996). A functor class overloads the operator () so that it appears as a function

pointer. For instance, the following is declaration of a functor class that takes one function argument.

template <class T> class functor {

public:

typedef funct_t bool (*f)(T );

functor (funct_t _f): f(_f) {}

virtual bool operator (T t) { return f(t); }

private:

funct_t f;

};

The class functor is a helper class that wraps a function pointer of type funct_t. Upon invocation, it calls

the actual function pointer and returns the result. The syntax of using the functor is exactly the same as

that of a function pointer.

The same idea can be applied to member functions as well. In C++, a member function of a class always

takes an implicit parameter this, which is a pointer to the object upon which the member function will

be invoked. As a result, two member functions that belong to different classes but take the same explicit

parameters are treated as functions of different types. In the component level, however, they should be

viewed as interchangeable. A mem_functor declared below can hide the class type as well as the implicit

parameter this.

template <class C, class T>

class mem_functor : public functor {

public:

typedef funct_t

bool (C::*f)(T);

mem_functor (C* _c, funct_t _f)

: c(_c), f(_f) {}

virtual bool operator(T t){return c->f(t);}

private:

C* c;

funct_t f;

};

With these two classes, functor and mem_functor, it is now straightforward to implement input and

output ports. An input port could be simply an instantiation of the mem_functor class. Since an output

port does not know the component(s) to which it will be connected, it could be represented as a pointer

to a functor. When connecting an input port to an output port implemented in this way, the address of the

mem_functor object corresponding to the input port is assigned to the functor pointer corresponding to

the output port, because the class mem_functor is derived from the functor class. When the output port is

invoked, the operator () of the mem_functor class is called, because it is declared as virtual.