Proceedings of the 2006 Winter Simulation ConferenceL. F. Perrone, F. P. Wieland, J. Liu, B. G. Lawson, D. M. Nicol, and R. M. Fujimoto, eds.

Model Composability

Hessam S. Sarjoughain

Arizona Center for Integrative Modeling & SimulationComputer Science & Engineering Department

Arizona State University, Tempe, Arizona

ABSTRACT

Composition of models is considered essential in devel-oping heterogeneous complex systems and in particularsimulationmodels capable of expressing a system’s struc-ture and behavior. This paper describes model compos-ability concepts and approaches in terms of modelingformalisms. These composability approaches along withsome of the key capabilities and challenges they poseare presented in the context of semiconductor supplychain manufacturing systems.

1 INTRODUCTION

Many contemporary and future systems are integratedfrom a range of simple to complex sub-systems. Exam-ples are information, manufacturing, and transportationenterprises. The purposes for these systems vary signif-icantly as each system is to satisfy a set of users andsystem requirements. To understand a system’s capabil-ities and limitations, dynamical models are developed.They help to specify structural and behavioral specifi-cations that can be simulated and, thus, can be usedto evaluate analysis, design, development, and testingdecisions.

Enterprise (or distributed) systems are complex andto understand their intricate dynamics it is often ben-eficial or necessary to use different kinds of models torepresent each sub-system. Heterogeneous model typescan offer greater flexibility as opposed to homogenousmodel types. However, combining different model typesposes a variety of challenges depending on the systembeing modeled (Page and Opper 1999, Davis et al. 2000,

Kasputis and Ng 2000, Sarjoughian and Cellier 2001,Davis and Anderson 2004, Fujimoto et al. 2002). Viewsregarding the kinds of problems encountered in simula-tion composability and future advances and investmentsin the context of the Department of Defense needs aredescribed in (Davis and Anderson 2004).

Partitioning a system into layers, each of which con-sists of a set of components, is a crucial step in high-levelmodel specification. Decomposition and composition ofmodels are challenging when models are heterogeneousin terms of their formal specifications - e.g., discrete-event and optimization models have different structuraland behavioral specifications.

Given the diversity of parts and resulting complex-ity of the systems, criticality of operation, and enormousfinancial consequences, simulation is being used moreand more as the primary science and technology to aidanalysis, design, implementation, and testing. Indeed,simulation can be used across each phase of systemdevelopment as proposed in Simulation-Based Acquisi-tion (SBA 1998). For example, a suite of system-levelsimulation models may be developed to help analyzerequirements and evaluate potential architectural solu-tions far in advance of defining detailed design specifi-cations. Yet, another suite of models may be used tohelp develop detailed design specifications which can beimplemented.

Systems theory, object-orientation, and logical pro-cesses worldviews are well known approaches for describ-ing dynamic systems (Cellier 1991, Banks et al. 2004,Fishwick 1995, Fujimoto 2000, Zeigler et al. 2000).Different modeling paradigms are suitable for differentkinds of needs - for some examples of modeling ap-

Sarjoughian

proaches see (Sarjoughian and Cellier 2001, Mostermanand Vangheluwe 2002, Barros and Sarjoughian 2004).A discrete event modeling approach may be used to de-scribe manufacturing processes and their interactions asa collection of model components. Alternatively, givenhistorical data, a continuous model can be developed toshow how inventory holding varies in relation to factorythroughput. Optimization models may be developed tounderstand logistics and financial impact of satisfyingcustomer demand.

Manufacturing supply chains and military systemsof systems are two well known network systems thatare often modeled at varying levels of details and fromdifferent aspects. Depending on the system’s differenttypes of behaviors, system simulation models may bedeveloped using a monolithic modeling paradigm in oneextreme and a combination of modeling paradigms atthe other extreme. For example, a manufacturing pro-cess may be modeled using a single modeling approach(e.g., agents or Petri-net). However, to effectively de-sign, assess, and operate a manufacturing supply chainin an optimal fashion, it is useful to employ discrete-event and optimization models (Kempf 2004). Similarly,to evaluate possible system design alternatives given avariety of operational and engagement patterns amonga sensor, weapons, and command/control, and commu-nication models, discrete-event, agent, and GIS modelsare important to be used (Hall 2005).

2 MULTI-LAYER MODELING

Many real world network systems can be abstracted toconsist of two parts - one is a plant and another is a con-troller (see Figure 1). At a high level of abstractions, theplant and controller models of a network system can beconsidered as computations which exchange data (i.e.,states) and control (i.e., commands) under some well-defined constraints. The plant/controller pair can forma symbiotic relationship, where one is concerned withoperations of a network process and the other is con-cerned with the control of the network management.The plant dynamics can be described in a variety offorms - e.g., discrete, continuous, or some combinationthereof. The controller can be based on feedback con-trol, event-based, and fuzzy control. For example, aplant can have stochastic discrete-event operations tak-ing place at the present time and the controller canbe an optimization-based feedback control. The plant’soperations occur from one time instant to the next - i.e.,the dynamics of the plant can be modeled as determin-istic (or stochastic) continuous and discrete equations.The controller operations can be based on the current orfuture state of the plant as well as present and expectedinputs that can affect controller’s decision making.

Controller

Network Control

datacontrol

Plant

Network Process

Figure 1: A two-level plant and control model

The plant and controller is considered a two-layersystem - plant and controller are at lower and higherlevels of abstractions, respectively. The plant is respon-sible for carrying out low-level operations, some of whichare requested from the control. It carries out some op-erations given some inputs and generates some outputs.The controller is responsible to carry out higher leveloperations given details provided from the plant. Itsresponsibility is to constrain the operations of the plantto those that are deemed desirable or acceptable forsome finite time period in the future.

The controller itself can be viewed as plant and itsoperations sanctioned by another controller. This leadsto multi-layer plant/controller specifications. This sepa-ration offers fundamental benefits in terms of developingseparate and hybrid models and simulations (for exam-ple see (Praehofer 1991, van Beek et al. 1997, Barros2002)). It provides conceptual separation of knowledge.Plant and controller models play distinct roles whereone supplies data and the other provides control. It alsoenables supporting multiple levels of control for a plant.One (tactical) controller provides tactical commandsto the plant and another controller provides strategicplans to the tactical controller. Another advantage isthat alternative modeling choices may be used for theplant or controller. For example, the plant may bedescribed in terms of discrete and continuous modelsand the controller may be described in terms of lin-ear optimization or event-based control models. In thecase of semiconductor manufacturing supply chain, theplant is the manufacturing process and the control isoperational/logistics controller (see Figure 1).

3 PLANT AND CONTROL MODELS

In the domain of semiconductor manufacturing sup-ply chain systems, models of discrete processes, controlpolicies, and decision plans are important in handlingstochastic dynamics of individual parts of manufacturingprocesses under tactical control and strategic planning,given short- and long-term supply and customer de-

Sarjoughian

mand (Kempf 2004). These kinds of aggregated modelsplay a central role in the understanding of not onlyphysical operations of processes, but also how they aremanaged using tactical control and strategic planning.Such complex industries can gain both short-term andlong-term technical competitiveness as well as financialadvantages. Another crucial benefit of synthesizing dif-ferent kinds of models is the ability to better handlemismatches (between competing objectives arising fromoperational vs. decision aspects, for example).

A canonical manufacturing process can be modeledas a collection of inventory, factory, and transportationnodes. The inventory (and transportation) nodes store(transport) products such as raw material, semi-finishedgoods, and finished goods. The factory node processesthe products it receives from inventories and sends theprocessed products to inventory or transportation nodesafter some time period. These nodes together character-ize the state of the supply chain process at any one timeinstant. Each factory, inventory, and transportationnode can have stochastic yield and duration which inturn results in a chain of nodes that can exhibit complexdynamics.

A well known approach for controlling a supplychain is to use linear optimization (LP) (Rardin 1998).An optimization model describes a set of formulas andrelationships (constraints c1, c2, etc.). A solver canbe used to optimize the optimization model’s variablesof interests (e.g., inventory holdings) given some ob-jective functions. Some examples of decisions can behow much should be held in the Finished Goods in-ventory, how many of which products should a factoryproduce, and what transportation mode to use for ship-ping products from an inventory to customer (see Fig-ure 2). The responsibility of the controller is to optimizeexpected vs. actual demand and supply over some fu-ture time horizon given key data about manufacturingnodes (e.g., work-in-progress in a Finish node) (God-ding et al. 2004). Alternatively, it may be useful to usea combination of optimization constraints and control-theoretic feedback/feed-forward filters which is knownas Model Predictive Control (MPC) (Qin and Badgwell2003, Wang et al. 2004, Sarjoughian et al. 2005, Huanget al. 2006).

To integrate these models, requires accounting fordifferences between data types that are used in, for ex-ample, DEVS and LP models. The structure of inputand output data for DEVS models is complex as com-pared with the data for LP models. Data for DEVSmodels are specified in terms of messages each definedin terms of port and value pairs - the port is a string andthe data can be an arbitrary expression (e.g., a queueof key and value pairs). The structure of input andoutput data for LP models are simple data types which

Optimization Model

Finish

Pa PbSemi-Finished Goods

Pd Pf

PcC

3

C2

C1

C4

Semi-FinishedGoods

Assembly/Test

FinishDie/

Package

Transportation

Customer

FinishedGoods

statescommands

Manufacturing Process Model

Figure 2: A snippet of a semiconductor manufacturingprocess and optimization model

may be formed into vectors (e.g., array of reals). There-fore, for manufacturing process and optimization modelsto interact, their data types needs to be syntacticallymapped from one to the other (Godding et al. 2004,Huang et al. 2006). For example, the Finish processproduces a set of finished products Lots at output portData-Out. The number of tested products is providedas input to the LP model.

Aside from input and output exchanges and map-pings, it is also necessary for the behaviors of the man-ufacturing process and optimization models to be well-defined - data exchanges need to occur at appropriatetimes and frequency. For example, the manufacturingprocess model advances from day to day whereas theoptimization model is solved at the start of each day. Inthis scenario, a command determined by the optimiza-tion model requests n products from the Semi-FinishedGoods to be released into Finish - i.e., the Finish re-ceives a release command on port Control-In with valuen. Details of the DEVS, LP, and MPC models partiallyshown Figure 2 can be found in (Singh et al. 2004,Godding et al. 2004, Sarjoughian et al. 2005, Wanget al. 2005, Huang et al. 2006).

4 MODEL COMPOSABILITY CONCEPTSAND APPROACHES

Considering the multi-layer modeling concept, it is pos-sible to use a single modeling formalism to describe aplant and its controller. However, if a system underconsideration has parts with dynamics that are intrin-sically different, it is crucial to use multiple modeling

Sarjoughian

formalisms. The above semiconductor manufacturingsupply chain system is an example where the plant (man-ufacturing process) is suitable to be modeled as discrete-event model and the controller (logistic control) as anoptimization model. A key difference between thesemodels is that the discrete-event model describes hownodes of a manufacturing process network affect one an-other and the optimization model searches for optimaloperation of the overall manufacturing process.

4.1 Modeling Formalisms

A modeling formalism can be defined to consist of twoparts: model specification and execution algorithm (Sar-joughian and Zeigler 2000). The former is a mathemati-cal theory describing the kinds of structure and behaviorthat can be described with it. The latter specifies analgorithm that can correctly execute any model that isdescribed in accordance with the model specification.

A model A that can be specified in a modelingformalism Ψ is denoted as MA,Ψ - i.e., model A adheresto the model specification Ψ and can be executed usingits execution algorithm. A model composed of a finitenumber of disparate models (e.g., A,B, . . . ,K) specifiedin a finite number of distinct modeling formalisms (e.g.,Ψ, Φ, . . . , Ω) is denoted as M∪A,B,...,K,Ψ,Φ,...,Ω.

Approaches to model composability are classifiedinto mono, super, meta, and poly modeling formalisms.These approaches provide different kinds of capabilitiestoward model composition. The first two are groundedin the concept that in some cases principally a singleformalism is well suited for modeling different parts ofa system. In contrast, the latter two are aimed at someother cases where disparate modeling formalisms are cru-cial to describe the parts of a complex system. Despitethe differences among model composability approaches,every approach must ensure interactions among com-posed model components are structurally and behav-iorally well-defined.

Exchange of data and control, causality of input andoutput interactions, and synchronization of models’ ex-ecutions with respect to time must be well-defined. Thisrequires that not only individual model specificationsare executed correctly, but also their compositions (i.e.,the execution of multiple execution algorithms are well-defined with respect to the composition of their modelspecifications).

To help describe the above model composability ap-proaches, model specifications are shown as rectangle,rounded rectangle, oval, and hexagon icons (see Fig-ures 3 and 4). Process and control models are shown asrounded rectangles and ovals, respectively. A compos-ite model that consists of two or more models (whetherspecified in one or multiple modeling formalisms) is

shown as a rectangle. For example, Figure 3 showsthat the manufacturing and control models as well astheir composition are described in Ψ. A KnowledgeInterchange Broker model (Sarjoughian and Plummer2002) that composes multiple models specified in mul-tiple modeling formalisms is shown as a hexagon (seeFigure 4).

A modeling formalism can have several implemen-tations (i.e., software realizations) based on the choiceof programming languages – e.g., a mathematical modelcan be designed and implemented using object-orientedmodeling concepts and a programming language. Soft-ware realizations of a modeling formalism also can beaffected given the intended or expected modeling andsimulation applications (e.g., parallel/distributed sim-ulation for large-scale application domains). In addi-tion, entity relations (ER models) and the XML familyof models are also referred to as models. Here theseare not considered since (i) such models are primar-ily aimed at describing structure of data instead of asystem’s structure and the behavior and (ii) they canbe subsumed in component-based and object-orientedmodeling approaches.

Before proceeding further, it is useful to note thatmodel specifications are also described and implementedusing (high-level) programming languages. Therefore, amodel specification can be referred to as a mathematicalmodel specification or a software model specification.Here mathematical specifications are considered (e.g.,〈X, Y, S, δext, δint, δconf , λ, ta〉 (Chow 1996) is the math-ematical specification for Parallel DEVS atomic model).It is also helpful to note that different terms are usedfor execution algorithms. An algorithm which is void ofsoftware design choices and implementations is some-time referred to as an abstract simulator or solver.

4.2 Mono and super model composability

It is common to use a single modeling formalism tospecify one aspect of a system. Using a mono modelingapproach provides key advantages - decomposition (orhierarchical composition) of a model into (from) partscan be carried out systematically (e.g., (Wymore 1993)).Modeling formalisms help modelers specify dynamicalsystems given well-defined syntax and semantics. Thesyntax specifies the allowed structures for inputs, out-puts, states, and functions. This is the model spec-ification. The semantics specify the behavior of thestructural elements. This is the execution algorithm.

For example, discrete-eventmodeling is often used tospecify discrete processes. A mono modeling formalismcan also be used to specify different aspects of a system- detailed process flow dynamics with simplified event-based control. Using this modeling approach, models of

Sarjoughian

different parts of a systemadhere to a single structure andbehavior specification. That is, MA∪B,Ψ may be usedto model discrete-event process model A, event-basedcontrol model B, and their interactions using modelingformalism Ψ. For the semiconductor manufacturingsupply chain systems, the manufacturing process andcontrol models are identified as A and B (see Figure 3).For example, these models can be specified in the DEVSformalism (Zeigler, Praehofer, and Kim 2000) (shown asin Figure 3(a)). A fundamental benefit of using a monomodeling formalism is that manufacturing and controlmodels as well as their interactions are described inΨ. This approach significantly simplifies integration ofmodels and their executions.

Use of a mono modeling formalism, however, maynot be suitable if the models that are to be composed areintrinsically different—the models are best described indifferent modeling paradigms—and are not fully sup-ported. This is because a formalism is suitable to modelonly some parts of a complex, heterogeneous systemwhile all the remaining parts must either be abstractedaway or formulated within other modeling paradigms.To overcome this difficulty, a super modeling formalismmay be used as shown in Figure 3(b).

In the super modeling formalism approach, a mod-eling formalism (MB,Φ) is encapsulated within thesuper-formalism MA∪B,Ψ. Models B and B are dif-ferent and the former must be encapsulated inside thelatter. A general approach is to use multiple modelspecification abstractions and hide the details of anencapsulated lower-level model specification inside anenclosing higher-level model specification - e.g., a simpleoptimization model described in LP can be encapsulatedas an I/O System (i.e., atomic) DEVS component. Thisallows the specification of the interactions between mod-els A and B to be described within Ψ. This approach,however, has to ensure the modeling formalisms that areencapsulated within it have a well-defined relationshipwith respect to one another. That is, the super modelingformalism must assert the kinds of disparate dynamicsthat can be specified within it. Model encapsulation(e.g., enclosing B inside B) requires the encapsulatedmodel to be well-defined - the input/output structureand behavior of the encapsulation of the optimizationmodel is guaranteed by the enclosing model specifica-tion. In the semiconductor manufacturing supply chainexample, a logistic controller can be a linear optimizationmodel B in formalism Φ and B can be a discrete-eventmodel in formalism Ψ. This enables composition of theplant and the controller models to be specified with theDEVS formalism, for example.

Unlike the above scenario, it is possible for a su-per modeling formalism to support model specificationsthat are at the same level of abstractions. Super for-

(a) (b)

, A BM

, BM

, AM

, A BM

, BM

, AM

, BM

Figure 3: (a) Mono and (b) super modeling formalisms

malism can support composition of state-based modelsrather than composing a state-based model and an in-put/output model (Fishwick 1992, Zeigler et al. 2000).This is a strong form of super-formalism since it supportscomposition of different kinds ofmodel specifications andtheir composition at the level of state-based specifica-tion rather than input/output. For example, the DEVSformalism can support combined DEV&DESS model-ing (Zeigler 2006) - i.e., model transformation (and thususer-defined model encapsulation) is unnecessary. An-other approach is Ptolemy which supports modeling ofmixed signal systems (Eker et al. 2003). It formalizesinput/output interactions among actors (model compo-nents) under the control of directors.

5 Meta and poly model composability

A model can also be composed from models that are de-scribed according to two or more modeling formalisms.In the meta modeling formalism approach, differenttypes of model specifications are transformed or ab-stracted to another modeling formalism. The metamodeling formalism must be able to account for thedifferences between disparate model specifications thatcan be composed.

As depicted in Figure 4(a), MA∪B,Θ is a com-position of models with their interactions specified informalisms Θ . Here models A and B specified in Ψ andΦ are mapped to A and B. This requires Ψ → Θ andΦ → Θ. The transformation → defines structure andbehavior of formalisms Ψ and Φ to that of the formalismΘ - i.e., the interactions between models A and B arespecified in terms of A and B.

A standardized modeling approach as shown in Fig-ure 4(a) is theHighLevelArchitecture (HLA) (Dahmannet al. 1999, HLA 2000a, HLA 2000b). It provides a

Sarjoughian

suite of generalized services where different simulationmodels are mapped to. This approach is strongly aimedat handling interoperability needs with some limitedcapability for model composability as supported by theObject Model Template (HLA 2000c). The interactionof the different types of model specifications is sup-ported with the publish/subscribe technique and datamanagement service while handling of timed interactivebehavior of execution algorithms is the responsibilityof the time management service (Allen 1997, Fujimoto1998).

Another approach is to use meta-modeling andmodel transformation (Jaramillo, Vangheluwe, and Al-fonseca 2002). In this approach, meta-modeling allowsdetermining whether or not two models described indifferent modeling formalisms can be transformed com-pletely or partially described within a meta-modelingformalism. In some cases a model described in Ψ can betransformed completely into another model describedin Φ (without any loss in model dynamics) whereas inother cases some constraints must be defined and placedon models described in Ψ to be represented in Φ. For ex-ample, a discrete-time model specified in Discrete TimeSystem Specification and a discrete-event model spec-ified in Petri-nets can be completely transformed intomodels described in Discrete Event System Specification(Vangheluwe 2000).

Given the semiconductor manufacturing supplychain system, its manufacturing process and logisticcontrol can be specified in the DEVS and LP modelingformalisms (denoted as Ψ and Φ in Figure 4(a)). Thecomposition of the meta models of A and B is denotedas MA∪B,Θ. The composite (or federated) DEVS andLP models may be specified in HLA (denoted as Θ inFigure 4(a)).

The remaining approach, called poly modeling for-malism (or multi-formalism modeling), composes dis-parate models using a model (referred to as KnowledgeInterchange Broker) which handles the differences be-tween disparate modeling formalisms (Sarjoughian andPlummer 2002). The KIB formalism enables compos-ing model specifications and execution algorithms ofdisparate modeling formalisms. The concept and for-mulation of KIB was developed in the context of asimple intelligent transportation system (Sarjoughianand Plummer 2002, Sarjoughian and Huang 2005). Asshown in Figure 4(b), MA∪C∪B,Ω is the compositionof MA,Ψ and MB,Φ, using MC,Ω. The interactionsbetween models A and B are specified in Ω. The KIB ap-proach in realistic semiconductor manufacturing supplychain systems has been realized - i.e., detailed models de-scribed in the DEVS, LP, and MPC modeling formalismsare developed and composed with KIBDEV S/LP andKIBDEV S/MPC (Godding et al. 2004, Sarjoughian et al.

(a) (b)

ˆ ˆ , A BM

, A C BM

, BM

, AM

, CM

, BM

, AM

Figure 4: (a) Meta and (b) poly modeling formalisms

2005, Huang et al. 2006). These introduce modelingcapabilities to the KIB that can support discrete-eventand optimization model interactions that are essentialin modeling of discrete part manufacturing supply chainsystems.

Unlike the meta modeling formalism approach, inpoly model composability approach models are nottransformed to a set of models all of which are de-scribed in accordance to a single modeling formalism.Furthermore, poly modeling formalism is distinct fromthe strong form of super formalism as KIB can bothsupport the interactions (data and control exchanges)among different model types (e.g., discrete-event andlinear optimization) and also support different kinds ofdata transformation and control schemes that are de-scribed external to the models that are composed. Usingthe poly model composability approach, common formsof data transformation (i.e., aggregation and disaggrega-tion) is inherently supported. Furthermore, it supportsalternative forms of common control schemes (i.e., se-quential, synchronous, and asynchronous). These gen-eral data transformation and control scheme conceptsneed to be extended based on individual the applicationdomains that are may be modeled.

6 MODEL SPECIFICATION ANDEXECUTION ALGORITHM

In the previous section, the composability modeling ap-proaches were described in terms of model specifications.However, as noted earlier, a formalism is defined as apair. The separation of model specification and execu-tion algorithm enables model specification composabil-ity and execution algorithm interoperability differently

Sarjoughian

execution interoperability

Model

Specification

Execution

Algorithm

Execution

Algorithm

Model

SpecificationModel

Specification

Execution

Algorithm

model composability

Figure 5: Separation between model specification andexecution algorithm

depending on the composability approach (Sarjoughianand Plummer 2002, Godding, Sarjoughian, and Kempf2004, Sarjoughian andHuang 2005, Huang, Sarjoughian,Rivera, Godding, and Kempf 2006). As shown in Fig-ure 5, the former is concerned with composition of syn-tax and semantics of different formalisms, whereas thelatter is concerned with execution protocols and theirinteroperation.

In the mono composability approach, one execu-tion protocol is used for a set of models that are alldefined using a single model specification approach. Inthe super composability, execution algorithms of theenclosing models and those that are encapsulated areinteroperated under the super formalism’s execution al-gorithm. That is, the execution algorithm of the modelthat is encapsulated in super formalism is viewed as anatomic operation within the super formalism executionalgorithm.

The meta composability approach, in contrast tosuper composability, is primarily concerned with inter-operability. The execution algorithms of the disparatemodel specifications are cast into model constructs andoperations (i.e., a set of services as in HLA) that are in-tended for interoperating different execution algorithms.In this approach, model composability is not stronglysupported and the model specification and executionalgorithm are weakly separated from one another.

The poly composability approach, unlike the otherapproaches, is concerned with both model composabil-ity and simulation interoperability (Sarjoughian andPlummer 2002). As shown in Figure 5, not only aremodeling specifications of Ψ and Φ composed using themodel specification of Ω, but the execution algorithm isresponsible for interoperability between the executionalgorithms of Ψ and Φ.

In the domain of semiconductor manufacturing sup-ply chain systems, Ψ can be DEVS, Φ can be LP orMPC, and Ω can be KIBDEV S/LP or KIBDEV S/MPC

(Godding et al. 2004, Sarjoughian et al. 2005). In thedomain of intelligent transportation systems, Ψ can beDEVS, Φ can be RAP (Firby and Fitzgerald 1999), andΩ can be KIBDEV S/RAP (Sarjoughian and Plummer2002, Sarjoughian and Huang 2005).

This separation between model composability fromsimulation interoperability is key given different appli-cation domains (Sarjoughian and Plummer 2002). Forexample, the DEV S/LP or DEV S/MPC model com-posability approach (Godding et al. 2004, Sarjoughianet al. 2005, Huang et al. 2006) is based on the manufac-turing process (plant) and decision (control) models tointeract with one another based on a synchronous controlscheme consistent with actual operation of a semicon-ductor manufacturing supply chain system. In contrast,the DEV S/RAP model composability approach (Sar-joughian and Huang 2005) is based on asynchronousinteraction between plant and control models. The dif-ferences between control schemes defined for interactionsin the KIBs play a key role in poly model composabilityapproaches given not only different classes of modelingformalisms, but also different application domains.

With poly model composability shown in Figure 5where only two modeling formalisms are composed, an-other type of model (e.g., RAP) that is not well suited tobe specified in Ψ (e.g., DEVS) or Φ (e.g., LP) needs to becast into either Ψ or Φ. This suggests, when more thantwo modeling formalisms need to be composed, multi-ple or hierarchical KIBs are needed or alternatively acombination of super, meta, and poly formalism maybe used instead.

A key practical distinction between the meta and thepoly composability approaches is that the latter can sys-tematically support composition of syntax and semanticsof known disparate modeling formalisms - it providesmappings and rich data transformations. For example,the differences between DEVS and LP/MPC syntaxand semantics is supported with a suite of general map-pings and domain-specific data transformations. This isin contrast to the meta composability approach wheredifferences between different types of models can be par-tially accounted for in themetamodeling formalism, thusrequiring all remaining differences to be handled on acase-by-case basis. This is because models describedin different modeling formalisms need to be augmentedto handle differences that cannot be handled via metamodeling and interoperability regimes.

A common approach to overcoming differences be-tween different types of models is illustrated in Figure 6.Adapters can be used to facilitate model interactionsin the absence of super, meta, and poly formalisms.Here an adapter is needed to transform the data thatis specified in Φ but also needs to be used with modelsspecified in Ψ. For each modeling effort, this approach

Sarjoughian

control

data

, BM

, AM adapter adapter

Figure 6: Model integration with adapters

relies on uni- and bi-directional data and control in termsof software design techniques and their implementationsdeveloped. This approach requires defining data map-pings and transformations individually for every modelthat is described either usingΦorΨ. With this approach,individual adapters need to be defined separately. Theconsequence is that consistency among the definitionsof the adapters must be maintained for all models man-ually - i.e., data mappings and transformations mustbe handled for every set of models that are defined indisparate modeling formalisms on a case-by-case. Fur-thermore, the control of execution between executionalgorithms must be handled as part of the modelingeffort instead of making use of well-known sequential,synchronous, or asynchronous execution schemes.

For example, given the DEVS, RAP, LP, and MPCformalisms, the models described in them can be aug-mented with adapters written to handle the disparitiesamong them. For example, while inputs and outputs ofDEVS model specification are messages, the inputs andoutputs of MPC model specifications are primitive datatypes (e.g., integer and string arrays). This requirescustomizing DEVS and MPC models to handle datareceived for every model. This is in contrast to a mod-eling formalism that supports all models that can bedescribed in the DEVS and MPC modeling formalisms.The aggregation and disaggregation of data and alter-native control schemes can be supported at the levelof model specifications instead of using adapters or in-teroperability services. For example, data and controlinteractions between the manufacturing process (plant)and the optimization control (controller) models arehandled using modeling constructs that are given inthe KIB. With the poly model composability formalismapproach, reuse is supported at the level of modelingformalisms.

6.1 Role of domain knowledge

A general purpose modeling formalism supports describ-ing and executing a model; it is not intended to accountfor domain-specific modeling. Therefore, until now,model composability has been considered independentof the application domains to which it may be applied.However, given the central role domain knowledge playsin developing composable models, it is important toconsider it for model composability. Domain-neutralmodeling formalism is key for modeling specific systems(application domains). This is because the complexityof composite models is in part due to the application do-main that is being modeled. For example, discrete-eventmodeling can be used in the domains of manufacturing,information systems, and event-based control. The in-teractions to be modeled among disparate models neednot only to capture data transformations and executionsbetween composed models, but also be appropriate tothe system being modeled since general purpose mod-eling formalisms are void of domain knowledge. Forexample, data transformation between a discrete-eventmodel and an LP optimization model of a manufactur-ing process has to handle a list of products that arespecialized to hold Finished Goods having some defectdistribution (Godding et al. 2004, Huang et al. 2006).The frequency between the process and controller mod-els can also depend on the domain - e.g., interactionscan be sequential or synchronous.

Domain specific modeling is not only central to themono and the super model composability approaches,but also the meta and the poly model composabilityapproaches. Separating domain-neutral and domain-specific model interactions is also key for handing generalpurpose modeling concepts while extending them withspecific needs of a domain. Given the separation be-tween model specification and the execution algorithmof a modeling formalism, the model specification can beextended to support domain knowledge. In the case ofthe mono and the super formalism model composabilitywhich are based on the concept of components, gen-eral purpose model components can be specialized for agiven domain. For example, DEVS model componentsare specialized to the entities of a manufacturing processnetwork. In the case of the meta model composabil-ity and HLA, in particular, domain specific federatesare modeled using specialization supported by object-oriented concepts and methods.

In addition, data engineering (XML family of datarepresentations and ontologies) may also be used forhandling static (i.e., non-behavioral) domain-specificknowledge (Tolk and Diallo 2005). For poly modelcomposability, due to strong separation between model-ing formalisms that are composed, existing approaches

Sarjoughian

to domain-specific modeling may be used. The exis-tence of the KIB offers a basis to explicitly account forinteraction of domain knowledge.

Given the composability approaches, each modelingformalism provides a different degree of support fordescribing domain knowledge. The degree of supportfor domain-specific modeling is grounded in the kind ofmodel composability that is enabled in each approach.

6.2 Distributed execution of composable models

Another consideration for model composability is dis-tributed execution of execution algorithms and theirinteroperation. All of the composability approacheslend themselves to distributed execution. For example,HLA supports distributed execution of federates andfederations (Fujimoto 1998). These allow distributedexecution of models synthesized using any of the mono,super, meta, and poly model composability approaches.

To support distributed execution of models, it isimportant to develop software design and implemen-tation that account for efficient data exchanges andoverall execution speed. Given disparate model speci-fication and execution environments (e.g., DEVSJAVA(ACIMS 2001), Opl-Studio (ILOG 2005), and Mat-lab/SIMULINK (Mathworks 2005)), other considera-tions (e.g., scale of individual models and data ex-changes, frequency of model interactions, and lengthof experiments) that can affect execution of combinedmodels must be accounted for. This is because the sep-aration of model specification and execution algorithmcan adversely affect execution of the composed models.Nonetheless, given sound software designs and imple-mentations, models that are specified with an eye onsimple model designs and appropriate use of program-ming constructs can be executed efficiently.

7 CONCLUSIONS

A classification of model composability approaches ispresented. Formulation for each of the model compos-ability approaches is described in terms of modelingformalisms. These approaches are described from amulti-layer modeling vantage point to highlight the im-portance of using different modeling formalisms. Howdisparate modeling formalisms affect model compos-ability is described using a simplified example from thedomain of semiconductor supply chain systems. Thediscussion on separating model specifications and ex-ecution algorithms reveals the impact of model com-posability choices and in particular support for varyingdegrees of model compositions and consequently limita-tions and complexity of specifying disparate composite

models, level of support for domain-specific modeling,and degree of support for distributed execution.

ACKNOWLEDGEMENTS

The author acknowledges support of this work by Intel,Lockheed Martin, and the National Science Foundation.Thanks are due to Dongping Huang, Gary Mayer, HansMittelmann, Daniel Rivera, and Wenlin Wang of Ari-zona State University, Gary Godding, Karl Kempf, andKirk Smith of the Intel Corporation, and Steven Hallof Lockheed Martin Space Systems for stimulating dis-cussions on integrating agent, discrete-event, linear op-timization, discrete-time, and cellular automata modelsin the domains of semiconductor manufacturing supplychain systems, system of systems, and human landusestudies. Acknowledgement is due to Paul Davis of theRand Corporation for fruitful discussions on simulationcomposability and a review of an earlier version of thispaper. Special thanks to David Goldsman of GeorgiaTech for his encouragement and support of this paper.

REFERENCES

ACIMS 2001. DEVSAJVA, Arizona Center forIntegrative Modeling and Simulation. Avail-able from <http://www.acims.arizona.edu/>[cited2006].

Allen, R. 1997. A formal approach to software architec-ture. Ph. D. thesis, Computer Science Department,Carnegie Mellon University, CMU-CS-97-144.

Banks, J., J. Carson, B. Nelson, and D. Nicol. 2004.Discrete-Event System Simulation. 4th ed. PrenticeHall.

Barros, F. 2002. Modeling and Simulation of DynamicStructure Heterogeneous Flow Systems. Simulation:Transactions of the Society for Modeling and Sim-ulation International 78 (1): 18–27.

Barros, F., and H. Sarjoughian. 2004. Guest editorial:Component-based modeling and simulation. Trans-actions of The Society for Modeling and SimulationInternational 80:319–320.

Cellier, F. 1991. Continuous System Modeling. SpringerVerlag.

Chow, A. 1996. Parallel DEVS: A parallel, hierarchical,modular modeling formalism and its distributedsimulator. Simulation: Transactions of the Societyfor Modeling and Simulation International 13:55–67.

Dahmann, J., C. T. M. Salisbury, P. Barry, and P. Blem-berg. 1999. HLA and beyond: Interoperability chal-lenges. In Simulation Interoperability Workshop. Or-lando, FL, USA.

Sarjoughian

Davis, P., and R. Anderson. 2004. Improving the com-posability of DoD models and simulations. Journalof Defense Modeling and Simulation: Applications,Methodology, Technology 1 (1): 5–17.

Davis, P., C. Overstreet, P. Fishwick, and C. Pegden.2000. Model composability as a research invest-ment: Responses to the featured paper. In Proceed-ings of Winter Simulation Conference, 1585–1591.Orlando, FL.

Eker, J., J. Janneck, E. Lee, J. Liu, X. Liu, J. Lud-vig, S. Neuendorffer, S. Sachs, and Y. Xiong. 2003.Taming heterogeneity—the Ptolemy approach. Pro-ceedings of the IEEE 91 (2): 127–144.

Firby, R., and W. Fitzgerald. 1999. The RAP sys-tem language manual, version 2.0. Evanston, IL:Neodesic Corporation.

Fishwick, P. 1992. An integrated approach to systemmodelling using a synthesis of artificial intelligence,software engineering and simulation methodologies.ACM Transactions on Modeling & Computer Sim-ulation 4 (2): 307–330.

Fishwick, P. 1995. Simulation Model Design and Execu-tion: Building Digital Worlds. Prentice Hall.

Fujimoto, R. 1998. Time management in the High-LevelArchitecture. Simulation 71 (6): 388–400.

Fujimoto, R. 2000. Parallel and Distributed SimulationSystems. John Wiley and Sons, Inc.

Fujimoto, R., D. Lunceford, E. Page, and A. Uhrmacher.2002. Grand Challenges for Modeling and Simula-tion. Schloss Dagstuhl.

Godding, G., H. Sarjoughian, and K. Kempf. 2004.Multi-formalism modeling approach for semicon-ductor supply/demand networks. In Proceedings ofWinter Simulation Conference, 232–239. Washing-ton DC, USA.

Hall, S. 2005. Learning in a complex adaptive system forISR resource management. In Proceedings of SpringSimulation Conference, 5–12. San Diego, CA.

HLA 2000a. IEEE High Level Architecture Frameworkand Rules —IEEE 1516-2000. IEEE.

HLA 2000b. IEEE High Level Architecture Frameworkand Rules —IEEE 1516.1-2000. IEEE.

HLA 2000c. IEEE High Level Architecture Object andModel Template —IEEE 1516.2-2000. IEEE.

Huang, D., H. Sarjoughian, D. Rivera, G. Godding, andK. Kempf. 2006. Flexible experimentation and anal-ysis for hybrid DEVS and MPC models. In Proceed-ings of Winter Simulation Conference. Monterey,CA, USA.

ILOG 2005. OPL Studio. Available from <http://www.ilog.com/products/oplstudio/>,[cited2005].

Jaramillo, J., H. Vangheluwe, and M. Alfonseca. 2002.Usingmeta-modelling and graph grammars to create

modelling environments. Electronic Notes in Theo-retical Computer Science 72 (3).

Kasputis, S., and H. Ng. 2000. Composable simulations.In Proceedings of Winter Simulation Conference,1577–1584. Orlando, FL, USA.

Kempf, K. 2004. Control-oriented approaches to sup-ply chain management in semiconductor manufac-turing. In Proceedings of IEEE American ControlConference, 4563–4576. Boston, MA, USA.

Mathworks 2005. MATLAB/Simulink. Available from<http://www.mathworks.com>,[cited2005].

Mosterman, P., and H. Vangheluwe. 2002. Guest edito-rial. ACM Transactions on Modeling and ComputerSimulation 12 (4): 249–255.

Page, E., and J. Opper. 1999. Observations on the com-plexity of composable simulation. In Proceedings ofWinter Simulation Conference, 553–560. Orlando,FL, USA.

Praehofer, J. 1991. System theoretic formalisms for com-bined discrete-continuous system simulation. Inter-national Journal General Systems 19 (3): 219–240.

Qin, S., and T. Badgwell. 2003. A survey of industrialmodel predictive control technology. Control Engi-neering Practice 11 (7): 733–764.

Rardin, R. 1998. Optimization in Operations Research.Prentice Hall.

Sarjoughian, H., and F. Cellier. (Eds.) 2001. DiscreteEvent Modeling and Simulation Technologies: ATapestry of Systems and AI-Based Theories andMethodologies. Springer Verlag.

Sarjoughian, H., and D. Huang. 2005. A multi-formalism modeling composition framework: Agentand discrete-event models. In Proceedings of the9th IEEE International Symposium on DistributedSimulation and Real Time Applications, 249–256.Montreal, Canada.

Sarjoughian, H., D. Huang, W. Wang, D. Rivera,K. Kempf, G. Godding, and H. Mittelmann. 2005.Hybrid discrete event simulation with model predic-tive control for semiconductor supply-chain manu-facturing. In Proceedings of Winter Simulation Con-ference, 256–266. Orlando, FL, USA.

Sarjoughian, H., and J. Plummer. 2002. Design and im-plementation of a bridge between RAP and DEVS.Computer Science and Engineering, Arizona StateUniversity, Tempe, AZ. Internal Report.

Sarjoughian, H., and B. Zeigler. 2000. DEVS and HLA:Complementary paradigms for modeling and sim-ulation? Transactions of the Society for Modelingand Simulation International 17 (4): 187–197.

SBA 1998. Simulation Based Acquisition: A New Ap-proach. Defense Systems Management College. Re-port of the Military Research Fellows DSMC.

Sarjoughian

Singh, R., H. Sarjoughian, and G. Godding. 2004. De-sign of scalable simulation models for semiconductormanufacturing processes. In Proceedings of the Sum-mer Computer Simulation Conference, 235–240. SanJose, CA, USA.

Tolk, A., and S. Diallo. 2005. Model-based data engi-neering for web services. IEEE Internet Comput-ing July/August:54–59.

van Beek, D., S. Gordijn, and J. Rooda. 1997. Inte-grating continuous-time and discrete-event conceptsin modelling and simulation of manufacturing ma-chines. Simulation Practice and Theory 5:653–669.

Vangheluwe, H. 2000. DEVS as a common denomina-tor for multi-formalism hybrid systems modelling.In IEEE International Symposium Symposium onComputer-Aided Control System Design. Anchor-age, Alaska: IEEE Computer Society Press.

Wang, W., D. Rivera, and K. Kempf. 2005. A novelmodel predictive control algorithm for supply chainmanagement in semiconductor manufacturing. InAmerican Control Conference, 208–213. Portland,OR, USA.

Wang, W., D. Rivera, K. Kempf, and K. Smith. 2004. Amodel predictive control strategy for supply chainmanagement in semiconductor manufacturing un-der uncertainty. In American Control Conference.Boston, MA, USA.

Wymore, A. 1993.Model-basedSystemsEngineering: AnIntroduction to the Mathematical Theory of DiscreteSystems and to the Tricotyledon Theory of SystemDesign. Boca Raton, CRC.

Zeigler, B. 2006. Embedding DEVS&DESS in DEVS.In DEVS Integrative Modeling & Simulation Sym-posium, 125–132. Huntsville, AL, USA.

Zeigler, B., H. Praehofer, and T. Kim. 2000. Theoryof Modeling and Simulation: Integrating DiscreteEvent and Continuous Complex Dynamic Systems.2nd ed. Academic Press.

AUTHOR BIOGRAPHY

HESSAM S. SARJOUGHIAN is Assistant Pro-fessor of Computer Science and Engineering at Ari-zona State University, Tempe and Co-Director of theArizona Center for Integrative Modeling and Simula-tion. His research includes simulation modeling theoriesand methodologies with emphasis on multi-formalismmodel composability, visual component-based systemmodeling, collaborative modeling, co-design modeling,agent-based modeling, software architecture, and dis-tributed simulation. His educational activities has ledto the establishment of an Online Masters of Engineer-ing in Modeling & Simulation in the Fulton Schoolof Engineering at ASU. For more information con-

tact the author at <hss@asu.edu> or visit <http://www.eas.asu.edu/%7Ehsarjou/index.htm>