Citation |

- Permanent Link:
- http://ufdc.ufl.edu/AA00003248/00001
## Material Information- Title:
- Heterogeneous hierarchical modeling for knowledge-based autonomous systems
- Creator:
- Miller, Victor Todd
- Publication Date:
- 1993
- Language:
- English
- Physical Description:
- v, 98 leaves : ill. ; 29 cm.
## Subjects- Subjects / Keywords:
- Induced substructures ( jstor )
Markov models ( jstor ) Model theory ( jstor ) Modeling ( jstor ) Multilevel models ( jstor ) Petri nets ( jstor ) Reasoning ( jstor ) Simulations ( jstor ) Symbolism ( jstor ) Systems theory ( jstor ) - Genre:
- bibliography ( marcgt )
theses ( marcgt ) non-fiction ( marcgt )
## Notes- Thesis:
- Thesis (Ph. D.)--University of Florida, 1993.
- Bibliography:
- Includes bibliographical references (leaves 93-97).
- General Note:
- Typescript.
- General Note:
- Vita.
- Statement of Responsibility:
- by Victor Todd Miller.
## Record Information- Source Institution:
- University of Florida
- Holding Location:
- University of Florida
- Rights Management:
- Copyright [name of dissertation author]. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
- Resource Identifier:
- 021785078 ( ALEPH )
AKB0113 ( NOTIS ) 30811418 ( OCLC )
## UFDC Membership |

Downloads |

## This item has the following downloads: |

Full Text |

HETEROGENEOUS HIERARCHICAL MODELING FOR KNOWLEDGE-BASED AUTONOMOUS SYSTEMS By VICTOR TODD MILLER A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY TABLE OF CONTENTS page ABSTRACT CHAPTERS 1 INTRODUCTION .. ........... Heterogeneous Hierarchical Modeling .. . Motivation for Research in HH Modeling .. .. ............... .. Contribution Related Work and Topics Outline . BASIC CONCEPTS .... Modeling and Simulation Concepts. . Formalism Classifications. . Hybrid Model Theory . . General System Theory . . Basic Modeling Paradigm . . Definitions Time Domains Named Sets . 3 FORMALISMS Graph Theory Finite State Mac Markov System Petri Nets ... Queuing Ne two :..nes......... ................ * S 4 9 9 4 9 5 9 5 9 9 9 9 9 S 9 9 9 9 5 9 S 9 9 S S 4 4 4 4 5 4 9 S s .* .. .. .. 9 .. 5 4 4 9 9 :hines . . s . * Control Theory .. 4 HYBRID MODEL THEORY Model Structure State Modeling ... Parallel Modeling Selective Modeling HYBRID ANALYSIS . S 9 5 9 9 4 9 * 9 5 4 5 9 5 9 * 4 4 9 4 * 9 4 5 S S S 9 9 4 4 4 4 9 9 5 4 9 4 9 5 9 9 5 S S 9 9 5 9 4 9 9 9 9 5 9 5 9 4 5 9 5 9 9 9 9 9 9 9 5 S S 9 5 5 9 5 9 9 9 9 9 9 9 9 9 9 4 5 9 9 9 5 4 5 9 5 9 9 5 9 6 CONCLUSIONS AND SUMMARY . 88 C conclusions .... 88 Sum m ary . 90 REFERENCES BIOGRAPHICAL SKETCH Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy HETEROGENEOUS HIERARCHICAL MODELING FOR KNOWLEDGE-BASED AUTONOMOUS SYSTEMS By VICTOR TODD MILLER August 1993 Chairman: Paul A. Fishwick Major Department: Computer and Information Sciences High autonomy systems generally require the use of multiple modeling formalisms and multiple levels of abstraction in order to describe their dynamic characteristics accurately and efficiently. It is often necessary to integrate several modeling formalisms if there is a need to reason about, simulate or analyze a system. Additionally, during development, the use of a hierarchical representation helps to organize the models more intelligently. Heterogeneous hierarchical modeling is a method which supports multiple representations and hierarchical development of knowledge-based autonomous system simulations. In this context, hybrid model theory is developed as a theoretical representation which provides the necessary formality to meet the requirements of heterogeneous hierarchical modeling. Hybrid model theory is an alternative approach to combined discrete-continuous multimodel theories and subsumes most of the concepts in combined discrete-continuous system simulation. Hybrid model theory supports a new concept in heterogeneous hierarchical modeling called intramndel coordination. Intramodel coordination is a method in which the components of coordination is a method in which two models can only interact through input and output. Furthermore, a hybrid model is a declarative representation of a system. By restricting the form of this representation, a hybrid model contains the data necessary information for a computer environment to perform symbolic, numerical and interpretative analysis automatically without additional effort from the user. CHAPTER 1 INTRODUCTION Heterogeneous Hierarchical Modeling An essential part of any system description is the development of a model. Ideally, the model represents the behavior of the system under investigation at some level of abstraction. In the context of simulation, the process of developing this model is generally called simulation modeling or simulation methodology. The extent of the modeling process itself varies not only from individual to individual, but also from paradigm to paradigm. This work focuses on the issues of the modeling process in computer (digital) simulation. The domain is limited to systems for traditional engineering purposes. The processes and formalisms for biological, social and self-evolving systems may or may not be applicable to this discussion. In this context, hybrid model theory is developed as a theoretical representation which provides the necessary formality to meet the requirements of heterogeneous hierarchical modeling. Hybrid model theory is an alternative approach to combined discrete-continuous multimodel theories and subsumes most of the concepts in combined discrete-continuous system simulation. Hybrid model theory supports a new concept in heterogeneous hierarchical modeling called intramodel coordination. Intramodel coordination is a method in which the components of a model can be coordinated with other models. In this manner, hybrid model theory extends the notion of intermodel coordination in combined discrete-continuous system simulation. Intermodel coordination is a method in which two models can only interact through input and output. Furthermore, a hybrid model is a declarative representation of a system. By restricting the form 2 The term modeling will be defined as a formalism and its associated methodology (if one exists). In simulation, most modeling techniques are low- to mid-level paradigms. At most, these techniques are stages in some potential methodology [Fis89b]. In the last decade, however, expanding the techniques of simulation methodology has received great attention [Cel82, Elz89, Pui89]. Additionally, new paradigms with associated methodologies have emerged and have been implemented [Nan87, Zei90]. One of the most import concepts to manifest itself from the research in simulation methodologies is the idea of a hierarchical model. Hierarchies have been used in highly abstract modeling environments [Cel92, Zei90], at the formalism level [Gor90] and at the numerical level [Syd82]. A hierarchical model is a model which has several different levels of representations and abstractions. These levels are related to each other by a hierarchy. The types of hierarchies most commonly used in simulation are structural, conceptual, and class hierarchies. A structural model decomposes the model into levels which resemble the actual system. Usually this requires that the system has well established physical attributes. A conceptual model may or may not have a decomposition similar to the system, but always has components which do not have physical counterparts in the system. These decompositions resemble the approach used in software engineering. A class model decomposition resembles the approach used in object-oriented programming. (The object-oriented class hierarchy actually originated from SIMULA 67, a language designed for discrete simulation [Bir79].) In a class hierarchy, the model is not decomposed hierarchically, but the objects used to described the model are created hierarchically. A hierarchy is used to classify objects into types. It is important to distinguish the classifying of domain models as opposed to the classification of the formalisms used to describe domain models. A hierarchy which classifies vehicles (objects like truck, car, motorcycle, Buick, Honda, etc.) organizes the domain of vehicles. A hierarchy which classifies formalisms (state, functional, 3 Another important concept which has emerged in simulation modeling is the use of multiple formalisms within one model [Pag89, Fis91 b] With the increased interest in hierarchical modeling, the need to represent efficiently each level of a knowledge-based autonomous system model (KAS model) has become important for many reasons. Some modeling formalisms capture certain aspects of system behavior better than others (developmental efficiency). Other modeling formalisms may provide the means to discern important features that are not evident in other formalisms (conceptual efficiency). The use and benefits of multiple models types has been investigated in theories such as multifaceted modeling [Zei84] and heterogeneous interlevel refinement [Fis91a]. The general concept of heterogeneous modeling draws upon research in multimodels, combined models, multifaceted models, homomorphic models, and abstract models. One of the ways of advancing the field of simulation requires improving the available modeling methods. Heterogeneous hierarchical modeling improves methods by aiding in the development, maintenance, simulation, and conceptualization of KAS models. It does this by providing a variety of succinct formalisms and the techniques for integrating them. Submodeling the process of either refining a model or specifying several alternative models for a model. Refining a model requires adding detail, for instance, refining a Petri net into a queuing model. Refinement of a model introduces subtleties of components of the model. Specifying alternatives for a model requires that only one alternative model be active at a time [Ore91]. Submodeling can require homomorphic behavior [Zei84, Sev91] between different levels of abstraction. Additionally, multiple formalisms include multiple types of simulation and integrating the taxonomy of models [Ore89b]. For example, Priihofer has integrated the representation of continuous and discrete event models in the same simulation environment [Pri91 a, Prii91b]. 4 modeling (HH modeling) allows an investigator to develop a model in a top-down fashion. The benefits of top-down design have been well established in many disciplines. The hierarchy not only aids the investigator in development and conceptualization of the model, but serves as a history of the development process itself. The history of a model's development may play an important role in the evolution or engineering of the model. In any modeling environment, the investigator must have the maximum available flexibility in development while ensuring that inconsistencies within the model do not arise. Because checking for inconsistencies in large and multiple models can be tedious and complex, it seems natural to conclude that the development of methods for automating a HH modeling process will be useful. Two of the major inconsistencies in HH modeling methodologies are compatibility between levels of the model and compatibility among different types of models. The number and type of formalisms in an HH modeling environment should provide the investigator with a sufficient range of choices (Petri nets, Markov systems, etc.). Of course, no modeling system will be perfect for every domain, but the interactions among a sufficient number of formalisms should give the investigator a flexible environment which can be applied to a very general domain. Currently, many of the hierarchical systems allow only one type of formalism, for instance, hierarchical Petri nets or state machines. Many of the multimodel systems, such as GPSS [Sch91] or SIMAN [Peg90], allow only one level of abstraction. Combining hierarchies and heterogeneous models has just recently received attention in the literature [Fis91b]. A generalized and formal theory of HH modeling has yet to be developed. The motivation for the development of HH modeling is derived from several different sources. The contribution it can make to the modeling process in general has been speculated but not confirmed. This work is a direct result of these issues. 5 increased use and availability of programs that do symbolic mathematics, it is becoming increasingly easier to automate symbolic analysis (especially of well-known modeling formalisms). Numerical techniques refer to traditional computational simulation methods and numerical approximation. Interpretation methods are those that are related to the field of artificial intelligence and knowledge engineering. These range from fuzzy or quantitative simulation [Fis91b] up to and including logic methods and semantic networks. In general, hybrid analysis (symbolic, numeric, and interpretative) requires different model specification strategies and processes for each type of analysis. This duplicates a substantial amount of effort on the part of the investigator. It also makes it impossible for information gained in one type of analysis to help or guide a technique in another type of analysis (unless the investigator transmits "by hand" this information from one modeling formalism to the other). A legitimate approach to HH modeling is to develop a new modeling formalism which is oriented toward KAS models. In order to provide insights into the complex behavior of KAS models through simulation and reasoning methods, efficient and succinct representations must be used to describe all aspects of behavior which are pertinent to the investigator. It is unlikely that one modeling formalism would provide such a representation. This assertion is based upon the pragmatics of model building. Specific modeling formalisms are used by investigators because they are convenient to use, have preferable attributes, or fulfill some pragmatic requirement [Rot90]. There are clearly two dilemmas to investigators of KAS systems. First, since pragmatic issues are dictated by the investigator's preferences and convenience, and pragmatic issues vary within different sections of large complex systems, a single modeling formalism locks the investigator into a method which is neither preferable nor convenient. The second dilemma concerns the trade-offs between convenience and generality example, queuing networks may be efficient for modeling arrival/departure behavior, but not 6 modeling formalisms. Additionally, simulation languages have traditionally lacked symbolic and interpretative analysis methods. In short, the more general a formalism becomes, the less efficient it is to use. With this in mind, an HH modeling theory which is based on coordination of existing modeling formalisms is an attractive alternative to developing an all-encompassing, completely generalized, single formalism. Since modeling formalisms such as queuing networks and finite state machines have proven to be powerful methods, but limited to specific domains, a coordination of these modeling formalisms, which keeps the representational power of each formalism intact, should foster more complete investigations of complex high autonomy systems. Furthermore, by coordinating established modeling formalisms, the learning curve needed to understand the theory is reduced. HH modeling can be accomplished by letting the investigator use an appropriate modeling formalism to describe a particular component of the system and then allowing a coordination of this formalism with models that describe other system components. The investigator may also need to reimplement subcomponents of a particular model as new information is gained during development and analysis (perhaps with a different modeling formalism). Efficiency and succinctness are supplied by the mathematical formalism whereas the coordination of several formalisms increases the generality. Motivation for Research in HH modeling There are several research issues which motivate the development of heterogeneous hierarchical modeling. Among these issues, the most basic, yet very important, is advancing the field of simulation. Oren [Ore89a, pg. 30()] writes, Since use of models is essential in simulation, advancements can be achieved hv Prnlnrin ~ nclvnnmp in marlni-hn>~ed tmnncent su.ch ns:" morleling formalisms: 7 By using multiple models, HH modeling expands the notion of a modeling formalism. Research in multiple models is not new. However, it is still in the early stages of development and requires further exploration. Combining multiple models within a complex hierarchical structure adds new problems and complicates current problems of multiple model research. The hierarchical modeling process is related to research in model-based management and modeling environments as described by Oren. The hierarchy serves to manage the development and structure of the model. The top-down approach commonly used with hierarchical models helps to prescribe management methods. Furthermore, a hierarchy describes the traversal path a modeling environment might use. Any environment which aids the investigator by allowing perusal of the model structure can use the natural structure of the hierarchy to guide the investigator. One of the most important motivations for research in HH modeling is the contribution it makes to knowledge-based simulation [Fis91 a] and qualitative simulation [Fis9lb, Kui89]. In knowledge-based simulation, information about the model is used to aid the investigator by suggesting alternative formalisms, answer questions about the model, increase semantic relationships between parts of a model, and help develop intelligent agent and goal-directed systems. HH modeling establishes formal relationships and clarifies the semantic relationships between different levels of abstractions in a model and different types of formalisms. For instance, a continuous model which has well-defined system states can be described by a state machine at the top level of a hierarchy and difference equations at the bottom level [Fis91b]. The formal relationships of HH modeling ensure correctness of the model. The hierarchy clusters information which is useful in grouping behavior, and the type of model specifies semantics about the particular level. A knowledge-based simulation and environment requires such information in 8 An important part of research in qualitative simulation is the ability to ask questions that require varying degrees of specification. An investigator may be interested in symbolic information in one question (will the ball bounce and if so, will it bounce high) or numerical information in other questions (how many times will it bounce and how long will it take to stop). These questions require different levels of abstraction and different levels of implementation. A hierarchical model provides, by its very nature, different levels of abstraction with corresponding formalisms capable of providing data appropriate for that level of abstraction. Similar to the motivation for knowledge-based simulation, HH modeling development helps to establish a foundation for qualitative simulation. Contribution The motivations in the previous section identify two general contributions. First, by developing formal and semantic relationships between different types of formalisms, HH modeling contributes to research in expert systems and knowledge-based simulation. Second, by developing the formal relationships between abstract levels in hierarchical models, HH modeling contributes to research in qualitative simulation. Although these two contributions are important, they are not direct contributions to the state-of-the-art simulation environment. HH modeling will form a solid foundation for knowledge-based simulation systems. The direct contributions HH modeling can offer to state-of-the-art simulation environments are as follows: Most simulation environments and libraries offer an investigator multiple models from which to choose. However, they do not help the investigator use them. How different models in the same simulation may interact is left up to the investigator. No facilities to check for inconsistencies among interacting formalisms are provided. 9 * Changing simulation models as new data are collected or new constraints are added can significantly alter flat models. The hierarchy of HH modeling serves to isolate independent parts of a model and therefore make them easier to maintain. * The hierarchy of formal models allows for incomplete models to be simulated. This gives the investigator feedback early in the simulation development phase. * HH modeling provides a mechanism to ask questions not only about the results of the simulation, but about the model being simulated. Additionally, the level of complexity of the question dictates the level of abstraction used in the simulation, and the level of ambiguity of the results of a simulation dictates the level of abstraction used to answer the question. * A generalized theory will make additional formalisms easier to include. * HH modeling allows formalisms to interact with each other instead of combining different formalisms into one. The complexity of modeling a large system is therefore broken up not only hierarchically but also conceptually. Related Work and Tonics There are three fields of study which are indirectly related to the work presented in this research. These fields are artificial intelligence, software engineering, and knowledge-based simulation. The exact relationship is probably a matter of philosophical debate. However, the cross-fertilization of ideas between these fields is prevalent through out the literature [Fis92]. Within AI, the work in qualitative reasoning Bob86] is directly related to HH modeling. Qualitative reasoning, in general, is any type of formalism which is an abstraction of algebraic 10 theory [For86] are used to answer a variety of questions about a model at several different levels of abstraction. States in QP theory are based on equation limits. In Kuipers's paper, a qualitative graph of data flow with constraints is used to reason about incomplete systems. Qualitative simulation (QS) [Kui86] is used as the reasoning formalism. States in QS are based on specified landmark values. Knowledge representation (KR) is loosely related to this work. Typically static relationships between objects. Frames KR focuses on Hay79], semantic nets [Fin79], inheritance [Eth83] and logic [Moo82] all play roles in reasoning about static properties. Although temporal reasoning research is done in AI, for example Allen's work [A1183, A1184], dynamic properties about system state is confined to qualitative reasoning. Reasoning and questioning are considered synonymous in this work. Therefore, when a question is posed to obtain properties of a model, reasoning is taking place. In software engineering (SE) the use of formalisms to describe operational behavior is common and is found in literature explaining SE fundamentals [Ghe91]. Object-oriented programming is also an important modeling topic in SE [Har89]. This emanates from software maintainability and reuse issues in which object hierarchies tend to assist. A good representative of the related work in SE is the new book by Rumbaugh et al. [Rum91]. Rumbaugh's methodology uses objected-oriented concepts to define static properties which are very much like semantic nets in AI. The dynamic properties of a software project are described using state and process modeling techniques. Although this methodology is not formal (theoretically or computationally), it is a thorough embodiment of process modeling. Within simulation research, any topic which uses object-oriented concepts or AI concepts is related to this work. Expert systems to analyze output, suggest models, or analyze sensitivity need to be able to ask questions (reason) about models and be assured that the answers have a sound All these areas of research have at least one thing in common: they must refer to abstract properties about complex models. Yet, the formal theory of abstract, hierarchical, or heterogeneous models is relatively unexplored. Sevinc [Sev91, pg. 1118] recognizes this when referring to model abstraction. He states, No complete theories of model abstraction exist, nor does any sufficiently general procedure. The field, with only less than a half a dozen published articles, is wide open. There is a distinction here which must be made. Sevinc refers to the simplification of a preexisting model. HH modeling is just the opposite, the refinement of a more detailed model from an abstract model. However, the theory used to describe homomorphic behavior as described by Sevinc should be independent of the development methodology. Directly relating to this work is research by Zeigler [Zei76], Wymore [Wym86 and Sevinc [Sev91]. These works consider homomorphisms, or derivations thereof, as the basis for model abstraction. In particular Zeigler's work in discrete event system (DEVS) [Zei84][Zei90] and Priihofer's continuous-discrete system [Prii91a] were considered as a starting point for this work. Three important differences should be pointed out. First, HH modeling extends this research to nondeterministic formalisms. Second, hierarchies of model formalisms dominated this work. Zeigler's and Priihofer's hierarchies center around the specific domain in question. These hierarchies are formed by coupling models together. Without the lower level models, no simulation can be preformed. In HH modeling, the goal is to simulate incomplete abstract models which generalize some, for the present, unknown behavior. Third, HH modeling allows a top- down and bottom-up approach to developing models whereas DEVS is a bottom-up approach. Almost without saying, this work is a spin-off of Fishwick's research, so much so that it would be impossible to enumerate. However, the relationship between SE, AI, and simulation 12 Outline In Chapter the underlying modeling paradigm is introduced. A basic introduction to modeling, simulation, and system theory also is given. This provides a review of the basic concepts that are used in later chapters. Also, notation and meanings of important terms are defined. General system theory (GST) will be the foundation upon which a theory of HH modeling is developed. However, the GST definition does not have sufficient structure for what is called component coordination (GST does handle model coordination and was therefore a good starting point). Also, GST does not clearly integrate with domain independent knowledge- based reasoning techniques. Therefore, in order to support HH modeling, GST has been extended by including connectivity and abstraction concepts. In Chapter 3, the formalisms chosen to represent modeling types, their use in simulation, their basic theoretical foundations, and their system description are presented. Specifically, five formalisms will be discussed: automata theory , Markov systems, Petri nets, queuing networks, and control theory. With these five formalisms, a sufficient spectrum of formalism types will be available to model a complex environment. However, these types are conceptually different enough to provide nontrivial problems in their integration within a unified framework. Chapter 4 presents the modeling paradigm developed to support HH modeling. The modeling paradigm is called hybrid model theory. This presentation includes a formal characterization. Hybrid model theory is a direct attempt to simultaneously embrace two themes which are directly related to HH modeling. First, it expands, clarifies, and establishes a solid mathematical foundation for the notion of heterogeneous refinement as introduced in Fishwick and Zeigler [Fis92]. Second, hybrid model theory furnishes a premise for hybrid analysis of a system represented by a heterogeneous refinement model. Some minor modifications of the formalisms presented in Chapter 2 are made. This allows for the coordination between formalisms. The In Chapter the benefits that HH modeling using hybrid model theory provide are demonstrated by the modeling of an automated flexible manufacturing system (AFMS). Traditional formalisms such as Petri nets, Markov systems, and block diagrams are used to create a heterogeneous hierarchical model efficiently. The symbolic and interpretative analysis methods are emphasized in this chapter. The numerical analysis is discussed briefly. A conclusion and a summary are presented in Chapter 6. This includes the problems and shortcomings of hybrid model theory. Additionally, a brief discussion on how hybrid model theory provides a foundation for hybrid analysis is presented. CHAPTER BASIC CONCEPTS Modeling and Simulation Concepts There are different definitions for many of the general terms used in modeling and simulation. The definitions presented in this section may or may not be similar to common interpretations (although most are very similar). It is particularly crucial that the scope of the definitions presented be understood. For instance, a description of a model typically implies that the model has a time base [Wym77, Zei76]. The interpretation of a time base can vary between formalisms (e.g., between Petri nets and control theory). When using different types of models together, the meaning and scope of time must be expanded to accommodate an appropriate range of usages. The most basic and most difficult term to define is model. For the purposes of discussion, a model is a representation or reproduction of a concept or physical object. The representation must have a formal description, that is, well-defined terms, entities, and operations on those entities. It may appear that representations which are only well defined unjustly restrict the numbers and types of models. However, as will be demonstrated later, a heterogeneous hierarchical model must maintain a mapping between levels of abstraction. Therefore, a representation must be well defined. Consequently, a well-defined representation is also called a formalism. Mathematically, such a lose definition of a model is unusable. Therefore, a recursive definition of a model based on a system will be given. However, only a conceptual description is given herep This definition will h& rnfinl (fi e will rlefind~ n in Chantpr 4 Civen n finiteo ot nf 1. An atomic system A structured collection of atomic systems 3. A structured collection of models. The specifications of "structured collection" are given in Chapter 4. The above definition differs from traditional model definitions in systems theory. Here, all models must be built upon a finite set of atomic models (a finite set of primitives). Note this is different from a finite set of model types or classes. As stated in the introduction, modeling will be defined as a formalism and its associated methodology. However, no commitment to either prescribed methodology (e.g., top-down or bottom-up) is adopted in the theory presented in Chapter 4. The emphasis is on a top-down methodology, but this is for exemplification purposes only. The process of development is undefined in terms of how is it performed. What is to be done in the development process is quite clear; a model is to be created. As previously implied, the ability to model hierarchically (top- down or bottom-up) provides a mechanism for a methodology, but does not force a methodology to use that mechanism in any prescribed way. The term simulation means not only the prevalent processes such as queuing networks, Markov chains, etc., but also processes such as expert systems. Conceptually, an expert system is a simulation of a thought process. Expert systems have well-defined entities and a well-defined operation (rules and an inference engine). Rothenberg discusses this issue in greater depth and in a more general sense in "Artificial Intelligence and Simulation" [Rot90]. Knowledge-based simulation (KB Simulation) will be used to refer to the simultaneous activities of analysis, simulation, and interpretation of dynamic models. This definition is generally consistent with current literature on KB simulation [Fis91a]. A diagram of the relationship among some of the terms introduced is depicted in Figure processed by either a human or a computer. The symbolic analysis of models can be aided by the computer. Likewise, techniques in AI have begun to automate the qualitative interpretation of models [Fis91b]. The problem with simultaneous analysis, simulation, and interpretation arises in the formal representation of different models. Heterogeneous hierarchical modeling is a theory in which all three types of activity are supported. Figure 2.2 shows the representation of these combined activities. modelling modelling modelling Figure modelling Figure analysis -- simulation interpretation Traditional Modeling KB Simulation 2.2 Hybrid Modeling Two important aspects of modeling which are not explicit issues of this work are validation and verification. Validating a model with a system ensures that the model represents the system's behavior to an adequate degree of accuracy. Verifying the model with the computer/human ensures that the formalisms are processed correctly. Although it is quite probable that the development of HH modeling will impact validation and verification, they are not discussed model model C 17 The relationship between system and model is further refined by establishing a conceptual view of a system (Figure 2.3). A system exists in an environment. The boundary between a system and an environment determines what is to be modeled. In simulation modeling, the environment has no representation and the system is represented by the model. The interaction between a system and the environment at the boundary is represented in a simulation modeling by input to or output from the model. Input/Output Figure 2.3 Conceptual View of a System A system may be considered to be in one of several states at any given time. Typically, this is conceived of as a set of variables with each unique set of assignments to those variables being a state. A static system does not change with time while a dynamic system changes with time. Alternatively, a static system can be viewed as a dynamic system at a particular point in time. If a system has a unique set of outputs for each set of inputs, then the system is said to be deterministic. If the output of a system cannot be precisely predicted (or is random), then the system is said to be stochastic. Simulation generally deals with dynamic systems. However, KB simulations may include static systems. An event occurs in dynamic systems when the system changes state. If the system is changing c'tntn~rr yntin^, t ioli, n',ar t a t, 3t f tt IT rrnntininim cxlti t ctnn Q ct c /hic'h rhianT nnnlu tt Environment System SBoundary A 18 Formalism Classifications There are two general classifications of formalisms that will be modeled in Chapter 4: state (operational, declarative) and functional (process, procedural). Together these general classifications cover a large number of specific formalisms. A state formalism represents states as entities. A simulation progresses as the model moves from one state to another regardless of whether time is elapsing. Figure 4 shows an example of a state model. Figure The three entities (sl-3) in Figure .4 Typica 2.4 repress State Model Diagram ent system states. An arrow represents moving from one state to another Each state is exclusive of each other (although some formalisms may allow parallelism). An example of a state model might be the states of a drilling machine: working, turned-off, or under-repair. A functional formalism is depicted in Figure 2.5. This is very similar to a data flow diagram. Each block represents a mapping (fl-4 in Figure 2.5) which transforms input to output. The state of the system is represented by the collection of internal states of each block. The arrows represent data transfers from one block to another. An example of a functional system would be an electrical circuit. Each block represents a component: resister, capacitor, etc. The data transferred is the current (electrons). It should be noted that functional systems are commonly used as parallel models; this is complementary to state systems which are commonly sequential. Hybrid Model Theory Hybrid model theory is a direct attempt to simultaneously embrace two themes which are directly related to HH modeling. First, it expands, clarifies and establishes a solid mathematical foundation for the notion of heterogeneous refinement as introduced in Fishwick and Zeigler [Fis92]. In Fishwick and Zeigler's presentation, the concept of heterogeneous refinement was described as a method which helps bridge the gap between AI and simulation models in a formal manner. However, the refinement process was carried out "by hand." Hybrid model theory expands the concept and provides a foundation that allows heterogeneous refinement to be automated. Second, and most important, hybrid model theory furnishes a premise for hybrid analysis of a system represented by a refined multimodel. The extent of hybrid model theory encompasses a single model. This is an augmentation to theories, such as general system theory, which deal with classes of models. It should be noted that hybrid model theory is a foundation which allows HH modeling to be implemented. There are certainly other approaches. However, hybrid model theory is an rnnrnorh rnnrh liltn r-nninl rr thrnir\7 All nrh(r!frlnn1inla 1'lnol'!o)p '!iIn he deccrihpd hv mrnniler 20 will use hybrid model theory as a formalism. Hybrid model theory is used to explain, mathematically, the commonalities and differences between modeling formalisms. With this foundation, the coordination of different formalisms such as Petri nets and block diagrams can be substantiated since the relationship between them has been formally established. General System Theory There are several different ways each formalism can be represented (presented in the next chapter). This produces a large permutation of coordination techniques. General system theory will be used as a starting point towards developing a common representation for the formalisms which are presented in this work. This section only introduces the mathematical foundation of systems theory for background and informational purposes. Most of the material described here is derived from Wymore's A system is a 6-tuple book [Wym77]. = (T, I, S, A, B, 8), where T is the time base, is a nonempty set called the input, S is a nonempty set called the system states, A is an admissible set of input functions f: T a set of functions f: S is a function f: Ax T -> S called the Behavior, and > B called the transition function. The time base, T, is typically the reals (91) or the integers (3). When T = 91, the system is said to be a continuous system. When T = 3, the system is said to be a discrete system. The system can be considered to be like a function invocation, when the input set A along with a time t is given. The set of system states (S) varies greatly from formalism to formalism; however, it 21 The admissible input functions represent the class of input schedules or input histories. Given a time segment t, a function in A gives the input presented to the system. This implies that the inputs to the system must be predetermined in order to analyze the system. The behavior functions (B) define the class of system sequences (discrete systems) or trajectories (continuous systems). The transition function generates a behavior function for a given input function and a time segment. Given an input function, initial conditions, and a transition function, the behavior of the system is completely deterministic. The relationships between systems theory and the simulation concepts described in the last section are fairly clear. A simulation model is a super-set of a system. Both a model and a system have inputs, states, and behavior. One can extend a system structure to include output by adding the following definitions is a nonempty set called the output and is a function f: S x T -- O called the output function. A major distinction between a simulation model and a (classical) system is that a simulation model can be nondeterministic. However, in an abstract sense, there is a close correspondence between model and system. For example, in Figure 2.4, the state model consists of states with arcs labeling transitions from state to state. ={sl, In systems theory, the model in Figure 2.4 is s2, s3} and 6 (A, t)(sl) 6 (A, t)(s2) =sl; (A, t)(s2) =s3; 6 (A, t)(s3) = s2. Similarly, in Figure stem can be derived b letting S be the cross product of the functions (H Fi) and 6 (A, T) be the set of equations. Fishwick [Fis91b] presents a similar 22 Basic Modeling Paradigm In the next chapter, the basic mathematical foundation of the formalisms used in this work is presented. Although one can find theoretical extensions of these formalisms in the modeling literature, this is nothing more than an attempt to combine formalisms (multimodels). This research uses an alternative approach. Instead of forcing a formalism to include other theoretical and semantic aspects, each formalism remains as close to its simplest or most common form, and a method is developed in which these different simple formalisms can be used together. The foundation for this approach is based on three premises. First, the formalisms in their simplest state are well understood: Why develop or extend (yet another) formalism that is not well known when two well-known formalisms already exist? Second, researchers and investigators already use these formalisms. Not only are the formalisms understood but they are used frequently. Third, and most important, combining different aspects of different formalisms increases complexity at one level of conceptualization. By keeping each formalism separate, and introducing a simple way to interconnect them, the complexity has been separated into distinct parts. Consequently, inefficiencies in implementation may exist. However, efficiency in modeling can be improved. An underlying assumption here is that human time is more valuable than computer time. The compilation of a model (implementation) can be carried out by the computer whereas (at the moment) modeling is done by humans. The distinction between a formalism and a theory is defined as a difference in generality. formalism (Petri net, state machine) has relatively clear semantics pertaining to its use and dynamic properties. A theory (system theory, computation theory) is a more generalized mathematical system which usually can describe any known formalism. Because of the generality, automated analysis is typically infeasible. Five common modeling formalisms are used as representatives of different modeling 23 model formalisms. The diagrammatic aspects of each specific modeling approach is preserved. There is no attempt to homogenize modeling or to force all models to look like either data flow diagrams or state transition networks. All model types have an equivalent graph or network representation. This is necessary in order to support knowledge-based reasoning methods (interpretation). However, this has not reduced the effectiveness of the theory presented since many modeling formalisms have graph or network equivalents. More specifically, the proposed paradigm requires that a formalism be represented by a directed graph. Arcs (edges) which lead out of a node are output arcs and arcs leading into a node are input arcs. Nodes in the graph represent either computational or storage models. As with most theories of modeling, there are two basic types of models: atomic and structured. However, in hybrid model theory a state machine, Petri net, etc., are not atomic models but structured models. In hybrid model theory, structured models are made up of at least two hierarchical levels. The first level is called a controller model. As will be shown, for a variety of formalisms only three controller models are necessary. The second level in the hierarchy is made up of atomic models called component models. This split-level approach to models is demonstrated in Figure 2.6. I I 24 As can be seen from Figure 2.6, data (or control) input and output are directed into the controller model. The component models (nodes in the graph) may or may not have data input and output. Depending on the type of controller, edges in the graph will either indicate control flow or data flow. This dual functionality has been captured in the controller model's interpretation of its components. Only under direction of the controller model is data input and output passed down to and up from the component models. This, at first, gives the impression of being very inefficient. However, when the model is compiled for numerical analysis(simulation), this inefficiency can be removed if and only if there has been no submodeling. When using interpretation techniques, this split-level method allows for more generalized knowledge. When analyzing the model symbolically, it allows combined results from different types of symbolic analysis. Chapter 4 introduces hybrid model theory in terms of numerical analysis (simulation). Chapter 5 shows by example how symbolic and interpretation analysis can be performed. Formalisms are classified based upon three attributes: 1) how they use time, 2) the type of data they use, and 3) the type of controller. Hybrid model theory supports four types of controllers: parallel, state, selective, and group. All four of these controllers contain the connectivity of the components they control (the graph). A parallel-controller model controls component models in which all components are active simultaneously. Edges between the components are interpreted by the controller as data paths. Formalisms which have this type of controller are block diagrams, confluence graphs, bond graphs, and neural networks. A state- controller model controls components in which only one component can be active. The controller, under direction of the components, keeps track of the current active component. Edges between the components are interpreted by the controller as control paths. Formalisms which have state controllers are Markov systems and state machines. The selective controller is the most complex. This controller controls two types of component models: functions and storage. A selective 25 by the controller as data flow. Formalisms which use selective controllers are Petri nets, queuing networks, and expert systems. A group controller is a parallel controller in which the components are structured models. The group controller allows hybrid model theory to encompass traditional model coordination (coupling) and will only be briefly discussed. The type of data which may be used by a formalism has two general attributes: value and time. Each of these attributes may be either continuous or discrete. This expands the typical continuous versus discrete concept of a signal in system theory. A discrete signal is too ambiguous of a categorization when combining symbolic analytical techniques and for interpretation techniques of different formalisms. It must be known whether a signal is discrete (continuous) over its values and over time. The third element which classifies a formalism is the way in which time is used. There have already been significant advances in combined discrete-event and continuous model simulation through the use of time bases [Pra91a]. This forms the foundation for hybrid model theory. However, the time description is extended to include elements necessary for symbolic and interpretation methods. This extension is called a time domain. The concept of a time base which is used in system theory becomes one of five elements used in a time domain, the most important of which is the time map function. The time map of a time domain is a function from the reals into the time base of the model. This allows coordination of all models with a common time base. Each model is responsible for mapping the common clock into local time. This concept, along with local model states, allows hybrid model theory to be easily translated into a distributed simulation when numerical analysis is required. Thus, there is no main event queue during numerical analysis (simulation). All events are stored locally in a model and coordinated by a common clock. The other elements of a time domain relate information concerning the semantics of the time 26 a change in the internal state. The delta time signifies the minimum time required for a model to change its internal state. The magnitude function maps a time from the time base into the integers. This function permits a model to specify significant magnitude changes in time. Figure 2.7 Intermodel Coordination Intermodel coordination is another term for model coupling Zei84, Wym77]. Because hybrid model theory has incorporated system theory, this type of coordination will not be extensively explained. Model coupling can be found in most system theory literature. From Figure 2.7, it should be clear that complex models of varying types can be coordinated through their data input and output. A collection of these models can then he grouped into a new model. An important advantage in hybrid model theory is that the intermodel coordination need not be static. That is, during execution or analysis, since the controller model contains the connectivity along with the functionality, the couplings can be dynamic; the controller can manipulate the connectivity of its components. This may become useful in certain types of neural network formalisms, for instance, nc txuzohtrc hlltti;wn naiirrnc nTvn henmp1 7-7r Group Controller Model state machine Petri net queuing net 27 quite different from intermodel coordination where, for instance, the output of a state machine is the input to a block diagram. In intramodel coordination, for example, a state component in a state machine controller model is replaced by a block diagram model [Fis92]. The controller model of a state machine essentially keeps track of several component models. Whether these components are simple state models which are based on conditions (input 'a', etc.) or complex models such as block diagrams is inconsequential to the controller. The only requirement is that the communication between the controller and its components be standardized in a formal protocol. The same type of argument holds true for parallel, group and selective controllers. In Chapter 4, the theoretical details of controller-component intra model coordination are presented. Definitions Before continuing into more formal concepts, a few basic definitions and their designations are introduced. The meanings are generally well known, but it is essential that the interpretation of the designations used be clear. Therefore, they are presented here instead of being put into a key of symbols. The unique symbols used are self, true, false , 0, and t. The empty set 0 and the booleans true and fails have their usual meanings. The mbol self is used to designate a symbolic reference to an entity which uses it. The symbol self is further explained in Chapter 4 where it has a special meaning in hybrid model theory. The symbol t is used to represent the notion of undefined (general math), null (programming), empty-string (automata), transient state (circuits), and bottom (programming theory). Depending on the domain, the appropriate term is used. As a standard throughout this work the following notation is used. The only notable difference is that all function invocations are designated by square brackets []. < > structured set and named set li cross product over i sets Additionally, the following special sets are defined. Z Integers u { t } Z+ nonnegative Integers Reals u {t u {t} Booleans {true, false} u Model u {t Two points are important here. First, all these sets are unioned with the undefined symbol Because these sets are usually used to specify values of variables, any variable in any model can be assigned the undefined value t. Time Domains The standard system theory notion of a time base will be used to specify the range of time values used by models in hybrid model theory. A time base is a structure consisting of a set and two operators: addition and comparison. The addition operator and the set must be an abelian group. The comparison operator and the set must form a linear order which is preserved under the addition operator. Time Base < > a linear order preserved under + Time Base Group = identity, operator t + t inverse t Linear Order t A time domain is built upon a time base. During the interpretation of a model, information about how the time is used by the model must be present. The time domain will serve this purpose. A time domain is a named set (a special kind of structure introduced shortly) which consists of five elements: time base, delta time, zero time, time map, and a magnitude function. A time domain TD is structured set Time base small time in T, .e., a significant change in time t e T such that everything < t is considered zero time mapping t -> T magnitude function T -> S such that m[zero] The use of a time domain can be exemplified by the following two examples. Although the time base is the same, there are significant differences in how time affects human and computer systems. Human Time Computer Time T= Tc T= Tq~ = identity t[] = identity = integer[r/10*zero ] = integer [r/2*zero] The zero time stipulates what times are to be considered as instantaneous. That is, in times less than zero the system cannot react to input. Note that this is different from the delta time dt. The delta time indicates what times are significant in changes in state. For instance, it is assumed that a human can sense things in 10 milliseconds but cannot react until 100 milliseconds. Likewise, in a picosecond, changes in transistors are important, but a cpu reacts only in nanoseconds (i.e., memory accesses). The time mapping is used to relate all time domains to T3 This will be further discussed in Chapter 4. The magnitude function is used to example, for a time period of 0.9 seconds, th gnify a constant state between systems. For ,e human magnitude function m[0.9] = 0 while the computer magnitude function m[0.9] = 45()x1()6 . For all practical purposes, in a time period of 0.9 seconds, a computer system can assume a human system is constant. The magnitude comparison can be used to circumscribe the system when any of the three types of analysis (symbolic, numerical, interpretation) are required. Named Sets In system theory, a convenient representation of assignment is represented by a structured set [Zei76, Zei84]. In this work, these sets are referred to as named sets. Formally, a named set is a structure , R, A> with S a set (entities) \I nrtlaraAt cat /n'r'mnnfaaro\' 31 A useful accessing function called a projection allows the values of parameters to be obtained from the named set. It is defined from the entities into the range of a value set Vi. Formally, a projection is defined as projv :S ->Ryvi As an example consider the assignment of a person's age and sex. A named structure is defined by the following = {Tom, Jane} age, sex (age, , 130]), (sex, { male, female}) A = { (Tom, (23, male) ), (Jane,(21, female)) }. A projection function on the age parameter and an application of the function is given by proj age (tom, 23) ,(Jane, 21 ) proj [ageTom] age =23. The projection function will be abbreviated in this work with the dot notation similar to typical programming languages. Tom.age represents projage age Tom] 32 considered to be a predicate, then the Prolog style predicate sex[Tom, male] and the equation Tom.sex = male can be considered equivalent. When reviewing example models which used graphical formalisms, it was found that labeling arcs and nodes with text was always performed. This is extremely valuable to humans during the development of a model. There was also a tendency to be fairly consistent with the usage of verbs and nouns on arcs and nodes. Since the interpretation of nodes and arcs in these formalisms is relatively straightforward (i.e., arcs and nodes have relatively well-defined semantics in each of the formalisms), the text is included as part of hybrid model theory by using named sets. CHAPTER FORMALISMS Graph Theory The formalisms presented in this chapter all have graphical equivalents. Since the graphs and the mathematical theory correspond to each other, the most convenient form will be used in the explication. In some of the formalisms, there is little or no distinction between graph and theory. Although graph theory is typically not used as a modeling formalism, most formalisms use graphs as pictorial representations or equivalents. In a general sense, a graph of a system is an abstraction. It shows states, components, transitions, data flow, causality, etc. In most cases it does not show computational or analytical properties. Therefore, it is a simplification of a system. Graphs are so useful as a modeling tool for humans that it would be imprudent to dismiss graph theory as a primitive theoretical modeling tool. It is assumed in this work that the structure of a graph is the defining factor for its usefulness as opposed to some physiological or psychological characteristic such as it is visual or pleasing to work with. Additionally, there are many analytical properties of graphs that are useful: spanning trees, articulation points, etc. All formalisms used in this paper use directed multigraph representations. The directed property is used to indicate transition in state formalisms or data flow in procedural formalisms. The multi property is used to represent alternative next states in state formalisms and multiple data flow in procedural formalisms. Formally, a graph is a set of vertices V and set of edges T is empty, A is{ B is a set with one element D defined as {(vl, n) : vle V and n : (v1,v)e E} }, and is &(a,t) =D for all a A, t This system starts in some nondetermined state, changes the current state nondeterministically by following some edge, and stops if it reaches a vertex with no edge leading out. The graphical representation of a procedural formalism can be described by a system, but is is so simplistic (one state and no behavior) that it would be senseless to give the definition. Most derivations of system theories (outside of AI) are structured for analytical purposes at the very lowest level of abstraction (i.e., statistics). However, the graph of a system does represent information about the system causality, and yet it is rarely represented within traditional analytical techniques. Finite Machines Automata theory will be used to describe state machines. Differences will be pointed out when they occur. The typical use of automata theory is to model computational processes or analyze grammars. Most theoretical information in this section is derived from [Hop79]. The main objects of a finite state automata (FSA) are state, input, and transition. Given a particular state and input, the transition function dictates the next state. Automata transfer state until a final state is reached. A push down automaton (PDA) uses a stack which is a last-in-first- 35 Figure 3.1 shows a typical PDA. The arc from sl to s3 with label a/x indicates a transfer from state sl to state s3 when input a is given and the element on the stack top is x. condition for a FSA or PDA is the start state. It is The initial part of the FSA or PDA's formal description. Unlike a system in system theory, an FSA or PDA has final states. This implies (and is most often the case) that the FSA or PDA will eventually stop when given valid input. However, in the most general automata, turning machines, tills can not be guaranteed. If the labels of a PDA are extend to a/ B, where 1 is a string of symbols, then the automaton is called a context finite state automata (CFSA). The context is 13. The context can be used to store a history of the prior states or input. A CFSA can essentially examine the history of itself when deciding the next state. Figure 3.1 Example PDA. An FSA is very similar to a discrete system. Only the definition is given here, but a similar definition and proof can be found in the literature [Wym76]. Given an FSA g, so, F), where Q is the set of states, is the input alphabet, Q2 is the transition function, so is the initial state, and F is the final states, an equivalent system is Z A, B, 6), where is 3, is Q, isQ, = (Q, = (T, I, 36 A system theory description of a PDA requires that the states be defined as Q x D*, where D is the stack alphabet. The next state function is similarly changed. Automata can be extend to encompass the property of nondeterminism. This is similar to but distinct from the notion of random or stochastic process. A nondeterministic FSA (NDFSA) allows for multiple transitions to be valid at the same time. Likewise, a nondeterministic PDA (NDPDA) or a CFSA (NDCFSA) allows multiple valid transitions. Although it has been shown that FSAs are equivalent to NDFSAs and CFSAs are equivalent to NDCFSAs, the nondeterministic counterparts are usually more concise descriptions and are used more often. There are many analytical properties about automata, especially FSAs and PDAs. Many of these properties analyze the class of languages that an automaton accepts. These properties are useful in the discussion of grammars, but they have not appeared in any literature relating to system theory and signals. The main interest in automata in system theory literature has been for control purposes and not for validating correct sequences of input. The stack of a PDA or the context of a CFSA allows the system to have a memory. This is a very distinct concept from any other formalism in this chapter and from classical system theory. Although the notion of memory and internal state are highly related formally, the difference in meaning can play a major role when attempting to interpret the system. Time is a notion easily integrated within automata. However, there is a difficulty when multiple formalisms are used. In a system representation of an automata, time is actually used to number or sequence the input. This works for descriptive purposes, but when integrating this with a continuous system where the time is S9, there is still no specific identifiable relationship. The notion of steady state, which is important in system theory and several of the other formalisms in this chapter, is not pertinent for any of the automata. A nonterminating automaton I 1 I. I. 37 Markov Systems A Markov system represents a stochastic process. It is a state representation. The transitions in a Markov system are stochastic. Each transition probability is based on the assumption that any past or future state is conditionally independent given the present state. Formally, a Markov system is a pair, = (S, T) where S is a finite set of states, and Tis a function f:S x S [0.0, 1.0] called the conditional probability. The conditional probability , s) represents the probability of the next state sj given the current state si. In probability theory this is T(si = p(next state current state = si). It is required of the function T that for each state si Xk T(si This stipulates that the probability of the next state transitions add up to one. Figure 3.2 shows a simple Markov system with the transition probabilities on the arcs. A sequence of states si ... sk is called a Markov chain. The initial state of a Markov chain can be given in several ways. The conditionally probability function T(si,sk) is usually represented as matrix M. An entry in row i and column k is the probability T(si , sk). It can be shown that the probability of being in state sk in the chain si ... sk is (si)(M)i,k where n is the length of the chain, M" is the nth product of M with itself and 6(si) is the initial probability of si [Cly90]. p1=1.0 p2=0.4 (1-p2) -. 38 If there exists an n such that no entry in the matrix Mn is zero, then the Markov system is called regular. In a regular Markov system it is possible to go from a state to any other state in no more than n transitions. It can be shown that the limit as n--oo will reach steady state equilibrium probabilities. If SS(si) is the steady state equilibrium and (Mn),j is the entry row and column j of the matrix Mn, then formally, for any i, Limn--4 (Mn)i,j = SS(si). In comparison to system theory, there are several apparent differences between the two types of systems. A Markov system has no input. The environment can not affect the state of a Markov system. If it could, then many of the analytical properties would be unsound. Additionally, the initial state of a Markov system is nondeterministic. In the context of other formalisms, a way to specify the initial state must developed. For instance, if a Markov system is a submodel of a state within an FSA, then when that FSA state becomes active, the Markov system must be initialized. This can be nondeterministic; however, a deterministic method could also be devised. Since a Markov system has distinct states, it can be classified as a discrete-event model. An event in a Markov system is the selection of a transition. As a separate formalism, this does not complicate a system theoretic description of the Markov system. When using several formalisms together, this does create a problem. The events of different formalisms must be related to each other in some manner. Unfortunately, there is no time associated with transitions in a Markov system. If a state in a Markov system is submodeled with a formalism which explicitly uses time, then how do the other Markov states events relate to this submodel? A Markov system does not have a transition function. It is possible to develop one similar to a Ty^ -'-1 T~W- A_ ^-* ^- L. t.. 1. 'l A- *-,^ .1 ..... .d-,^_ A / -.tn t nnn A n n-1 r- 1-.- -t-.--l *i ~* /t 39 equilibrium probabilities of a Markov system are considered to be the defining factor in describing that system. Petri Nets Petri nets are typically used to model concurrent systems in which the objects of the system must have synchronized behavior. Additionally, Petri nets can be used to model resource allocation systems. The source for the information about Petri nets in this section is derived form Peterson's book [Pet81]. There are three main objects in Petri nets: places, transitions, and tokens. Places and transitions alternate nodes in a graph (see Figure 3.3). A transition moves a token in an input place to an output place. This movement is called tiring the transition. These attributes categorize a Petri net graph as a bipartite directed multigraph. The state of a Petri net is the number of tokens in each place. There is no time associated with Petri nets. Transitions fire, nondeterministically, transferring tokens form place to place. After a transition has had a chance to fire, the Petri net is said to be in a new state. tokens place 1 trans Figure 3.3 E A Petri net is defined formally as a 4-tuple, place 2 place 3 ition sample Petri Net = (P,T, I, O) where P is a finite set of places, 40 Since P is a finite set, it is clear that P is not a set but a bag (a set which allows duplicate values). Since a transition can have multiple arcs to the same output place, multiple copies of places are allowed in the sets In(t) or Out(t). just as easy to represent a bag {a,a,b,b,b,c} as Theories of bags have been studied; however, it is (a,2), (b,3), (c,1)}. In any case, the function #(In(tj), pi) retrieves the number of arcs from place pi to transition tj and #(Out(tj), pj) retrieves the number of arcs from transition tj to place pi. A marking m:P -- 3n for a Petri net is a n-tuple where n = cardinality of P (IPI). A Petri net with 5 places and a marking m=(1,3,1,5,4) has 1 token in place 1, 3 tokens in place place 3, etc. The function m(pi) retrieves the marking for place pi (i.e., 1 token in above m(p2) Markings in Petri nets and states in systems are equivalent. Given a marked Petri net Z with marking m, a transition t in for all pi Z is said to be enabled if #(In(t), Pi) <= m(pi). A enabled transition means that the transition can get a token from each input place for each arc. For example, if there are two arcs from a place to a transition, then there must be as least two tokens in that place in order for the above condition to be met for that place. When a transition fires, the tokens are removed from the places. If two transitions require the same token from a place in order to fire, then only one will fire if there are not enough tokens for both transitions. The choice in this case is arbitrary (nondelerministic). The next state of a Petri net is defined if at least one transition can fire. Otherwise the Petri net is blocked. Given a Petri net a marking m, and a transition t, the next state f(m,t) is formally defined as 41 There are several differences between a Petri net formalism and systems theory. A Petri net has no input. When using a Petri net, an initial marking mo is given and next states are reached by firing transitions. The initial marking is a state not an input. Therefore, the environment can not effect the state of a Petri net. Since a Petri net has distinct states, it can be classified as a discrete-event formalism. An event in a Petri net is the firing of a transition. However, there is no time associated with these events. As an independent formalism, this does not complicate a system theoretic description of a Petri net. When using multiple formalisms together, this does create a problem. The events of different formalisms must be related to each other in some manner. An obvious choice would be to use time. With state machines, Markov systems, and Petri nets combined, the concept of time being related to state transitions (events) seems appropriate, but not the only possibility. The transition functions of Petri nets and systems are similar. The behavior functions of a system roughly correspond to the sequences of allowable states. Since Petri nets are nondeterministic, the requirement that the system behavior be functions must be relaxed; a system's behavior is a set of relationships. There are several important analytical characteristics which are important in Petri net theory. All of these have definitions, but only the concepts will be presented here. The reachability of a Petri net is a set of markings which are reachable from some initial marking. This set is designated as R(Z, mO). Safeness of a Petri net with a given initial marking is defined when all places have 0 or 1 token. A place is k-safe (k-bounded) if the number of tokens never exceeds k for some given initial marking. A marked Petri net which has a transition that can never fire is said to be in deadlock. The transition (or transitions) is said to be dead. Transitions which can potentially fire are called live. 42 networks are process oriented. There are three main objects in queuing networks: populations, queues, and servers. For analytical purposes queuing networks are conveniently represented by attributes of these objects. The notation is m/n/o/p/q where m is the interarrival time distribution, n is the service time distribution, o is the number of parallel servers, p is the system capacity, and q is the queue discipline. The theoretical material in this section is derived from [Ban84] and [Gra80 server 1 arrivals queue server Figure 3.4 Simple Queuing Network Figure 3.4 shows a simple queuing network. The arrivals node represents the calling population. This could represent customers at a bank, palettes in a factory, cars at a traffic light, or calls at a telephone exchange. An arrival from the population is called a customer. The arrival rate of customers depends on the population type. A finite population has a limited number of customers. Therefore, the arrival rate is influenced by the number of customers currently in the system. The arrival rate of customers for an infinite population is described by a distribution (usually the Poisson distribution). When customers arrive in the system they are queued (wait in line) until a server is available. In Figure 3.4 there are two server nodes. Each node represents 1 server. The service time for each server may be constant or random. Common random service times are represented by the exponential, gamma, and normal distributions. The queue node in Figure 3.4 appears to be a first-in-first-out (FIFO) line. This is a consequence of the graphical portrayal and not a true depiction of the queue's discipline. The 43 the queue. It is also possible for customers to leave the system if they wait to long or change queues in a multiqueue system. A queuing network with a Poisson arrival distribution has an exponential interarrival time [Gra80]. If the service time for the servers in Figure 3.4 is exponential, the arrival rate is exponential, the queue's capacity is 5, and discipline is LIFO, then the notation used to represent the system is M/M/2/5/LIFO (where M stands for an exponential distribution). However, a complex system with multiple populations, queues and servers cannot be described with this notation. Most real world models are so complex that no attempt is made to a use concise notation; instead, the graphical representation is used. There have been many analytical properties developed for simple queuing networks. Since the variety of networks is very broad, each network type has different theoretical derivations. There are, however, common properties among the different types of networks. The distributions used to describe the arrival and service times are examples. Because the analysis is so varied, only a verbal definition of the most useful properties is presented. The expected time in the system is the average time a customer spends in the system. The time a customer is in the system is comprised of the time in queues and the time being served. Although it is typical to keep the expected time in the system as small as possible, the ratio of time waiting to time in the system is more important (especially to a customer). The expected number of customers in the system is important for determining queue capacities or the number of servers required. It is undesirable to have customers balk because queues are to small or to have servers idle because there are to many servers. The expected queue length and server utilization are measurements which help in deciding the system's type as described above. The throughput of a system measures the number of customers served per unit time. Many times, the objectives of a queuing system are opposed to each other; for instance, to maximize throughput and utilization 44 most complex of which is to change the queuing discipline (as opposed to changing the number of servers or increasing the capacity of a queue). This has lead to a multitude of queue disciplines. Additionally, more realistic parameters have been introduced (balking, changing lines) or more complex networks. Because these are very difficult (if not impossible) to analyze, numerical approximations have become a norm in the analysis of complex queuing networks. The computational methods used in queuing networks are usually extensions to the above material. For example, customer attributes, resources and macro models are available in many of the commercial packages such as GPSS [Sch91] and SIMAN [Peg90]. Additionally, more sophisticated packages have animation, such as CINEMA [Kal91], or graphical entry methods, TESS [Sta87]. Despite this, the basic tenets for these system have evolved out of queuing theory. In terms of system theory, a queuing network is a discrete-event, nondeterministic process. The state of which can be described by a tuple. Each server and queue have a position in the tuple. For instance, a 2 queue, 2 server network is described by (ql are the number of customers in the queue. The servers sl and s2 ar The time base is S9 and there is no input into the system. The beha' , q2, l, s2) where qi and q2 e either idle (0) or busy (1). vior can only be described in terms of steady state. Control Theory Control theory is based on linear system theory. The types of systems modeled in control theory are continuous systems. Therefore, a direct description using the systems approach is easily obtained. The system description is not presented in this section, but can be found in many books [Wym77, Zei86, Dor86]. What is of interest is the cause-effect relationship embodied in control theory. Although classical control theory does not include these relationships directly, other methods, such as bond graphs [Tho75], have shown that the cause-effect relationship plays Vi cT* Figure Typically 3.5 (a) Low Pass Circuit (b) Block Diagram linear systems are described with the aid of block diagrams. Figure 3.5 exemplifies the cause-effect relationship of a low pass RC circuit (integrating circuit). Using Control theory, the transfer function Vo(s) / Vi(s) can be obtained. The input voltage vi(t) and the output voltage Vo(t) are = i(t)R + 1/C i(t) dt 1/C Ji(t) dt. The Laplace transforms are Vi(s) =I(s)R + 1/(Cs) I(s) and Vo(s) 1/(Cs) I(s). Solving for I(s) in the equation for Vo(s) and substituting into the equation for Vi(s), the transfer function is Vo(s)/ Vi(s)= 1/(RCs + 1). The transfer function in the form of a block diagram is shown in Figure 3.5. The block G is G = 1/(RCs) 46 output voltage becomes constant after some finite time. This is exactly what a low pass circuit does under constant voltage. The qualitative cause-effect relationship was deduced in a domain independent manner. This type of reasoning is the focus of both AI research [Bob86] and knowledge-based simulation [Fis91b]. The state of the low pass circuit in classical systems theory could be represented by the tuple (vi(t),Vo(t)). Intuitively, however, there are two states of the circuit when the input voltage is constant: the transient state (when the capacitor is charging) and the steady state. Control theory does not encompass this abstract notion of state. However, the block diagram's graph indicates indirectly the existence of these states. Although control theory has a simple description in systems theory, integrating continuous formalisms with discrete formalisms requires resolving the time base. There are only two possible resolutions: discretize the continuous system or assign time values to the discrete system. A linear system is an important concept in control theory. In Petri nets and state machines linearity is not discussed (at least not in the literature found to this date). A linear system exhibits two essential properties: superposition and homogeneity. Given a system that with input x(t) produces output y(t) and with input w(t) produces output z(t), if input x(t) + w(t) produces output y(t) + w(t), then the system has the superposition property. If input Bx(t) produces output By(t), where B is a constant, then the system has the property of homogeneity. Control theory, along with the other lbur formalisms presented in this chapter, all have a system theoretic description. In the next chapter, a theory will be introduced which provides the foundation for a consistent and cohesive mechanism to describe these formalisms and will permit them to be used in a hierarchical organization. CHAPTER 4 HYBRID MODEL THEORY Model Structure Hybrid model theory is a combination of general system theory (GST), named sets, and graph theory. The combination of GST and named sets is also used in multifaceted modeling [Zei84]. In a sense, one could argue that hybrid model theory is a derivation of GST. Mathematically, this may be correct. However, there are significant differences of which those familiar with GST should be aware. These differences arose from the requirements needed for HH modeling . First, hybrid model theory is not to be used by the investigator. It is not a modeling formalism. It is a generalized formalism that is not as conceptually efficient as formalisms such as Petri nets, queuing networks, and block diagrams. Second, although building bottom-up is possible, hybrid model theory emphasizes a top-down approach to constructing a model. The idea behind hybrid model theory is to take a model which is partially correct in describing a system's behavior and refine only those components which do not correspond with observed data or system specifications. under development. HH Third, hybrid model theory focuses on the analysis of a single system modeling and hybrid model theory are meant to provide the foundation for a computer environment which allows for the creation and investigation of system models, not the classification, identification, comparison and retrieval of already constructed and understood system models. Hybrid model theory deals with the alteration and investigation of incomplete or incorrect models. H :Component : Edge :Input : Output a22'' .> X2' -**> : State <...> t : Time Domain <(T,+,<), zero, delta, map[], magnitude[]> p : Initialize function 8: Transition function : Output Function (T,C,Q) (T,C,Q) (T,C,Q) -> 0 -> -> 1. The symbols < and > indicate the use of named sets, and elements in these sets can be accessed as described in Chapter The component set (H) of a model always has the special symbol self as a member. This symbol is used to indicate a reference to a submodel (if one exists). For most atomic models the self symbol is the only member of the component set. In structured models, the component set contains the models which are supervised by the controller model. The edge set (A) of an atomic model is empty. In structured models, between component models is identified with the edge set. An edge ao the connectivity A is a named set of the form t (undefined) , a standard data type (91, 3) or a model. Together, the components and edges describe the graph of the model and either what type of data is passed between the components or how control is transferred among the components. In Chapter a brief description of intermodel coordination (coupling) was represented in hybrid model theory. From the definition above, it can be seen that a structured model, which has components that are also structured models, represents intermodel coordination. The root model is , "1, .... > 49 coordinate the atomic models (state, parallel, and selective controllers) have a very different form and semantics from the group controller that coordinates a set of structured models. It is the distinct form of controllers that allows heterogeneous refinement. The input (X) and output ('I) also have the form or control information used by different types of models. For models in which the input has not yet been specified, the from model will be equal to t (undefined). The same definition also applies for a model's output. The only difference between inputs and outputs are that inputs are signals (functions over time) and outputs are values. The state (8) named set is used for a variety of purposes. It is very similar to local memory in computational definitions. It can contain any other type of named set (including a model). However, for analytical purposes, the state set should contain only constants or functions of time. The time domain of a model was discussed in Chapter 2. It is only noted here that the time domain of a model can be null. However, it is intended that models which do not have the notion of time in the clock sense include notions of time in the computational sense. That is, if a model is not measured in seconds, but has a definite sequence of computation, then the model should use an integer time domain. Each integer X+ 1 represents the next computational step. The last three elements of a model are functions. Typically, these are used to compute the new state and output trajectories over a time interval. Because hybrid model theory is centered around simulation concepts, these functions have been conceptually altered. It is assumed that all three functions use two times: the current time (a global variable) and an input time (given at function invocation). These times are used to calculate the state or output at the input time. The current input and state are also assumed to be part of the input to these functions. Trajectories are created by symbolic methods which take a model as input or created through numerical techniques. Additionally, it should be emphasized that these functions are declared, not 5(0 The initialization function (3) is necessary since models can be dynamic. At any time during analysis, a model can become active. This not only allows for the modeling of systems which may lie dormant, but more importantly, it models systems which have multiple descriptions over time. A piecewise continuous system is an example of a primitive multidescription system. In this work, the state oriented formalisms implement the piecewise concept. For data flow models (differential equation models), the initialization function (P) sets the initial conditions. The transition (6) function is intended to be used when a model is active. Although, as can be seen from the description, it could be used to initialize a model. The initialization and transition functions were derived so that the concept of state, transition and initialization could be separated. Again, this is necessary in symbolic and interpretation methods. If the transition function uses stochastic or nondeterministic relationships, then mathematically the term functions incorrect; however, for purposes of this discussion, the term function will be used in a similar manner to that used in programming languages. For the same reason (and tradition), the output function (X) is also kept separate from the other functions. One of the optimizations for numerical analysis is the integration of these functions so that only one call to the model produces the total behavior. This integration is possible in hybrid model theory because there are only four controller models and each type of controller has the same form of transition and output functions. Controller Model Supermodel Component Models mI wA Controller Model submodel I-I 51 There are two rules which capture the manner in which atomic components of a structured model can be coordinated with other models (intramodel coordination). This is a pseudo formal definition ofintramodel coordination in hybrid model theory. Figure 8 shows how the coordination is accomplished. The rules can be stated as follows. 1. A component (node) in a model can have its operation's output delayed or altered by another model called the submodel. The component model, when activated, initializes the submodel and waits for a signal of completion, which then deactivates the submodel. 2. A component (node) in a model can have its operation replaced by another model; however, the I/O and control of the submodel must be the same, the model is continuous over the analysis. The types of controllers which interact with when submodeling. each other dictate which of these rules applies The higher level model in submodeling is called a supermodel. Like most model formalisms, the arrows in Figure 8 signify control and data flow between model types. The rule which applies depends only on the supermodel involved. For instance, if the supermodel is a state controller, then rule 1 above applies, for a parallel supermodel only rule 2 applies and for a selection supermodel rule 1 applies. State Modeling A state controller model manages a finite set of components. The edges represent control flow between the components. The state controller model is responsible for the input and output to the 52 However, each Markov state can supply an output at any given time as described in Chapter 3. The input to a Markov state is only used by the submodel (if one exists). A state machine can be represented in the same manner as a Markov system. The only difference is in the internal state of the state models. Hence, in order to describe state formalisms, three models are needed: two atomic models and one structured model. Specifically, these are a finite state atomic model, a Markov state atomic model and the state controller structured model. The atomic models are defined first; then, the state controller is defined. A finite state atomic model is defined as H :Component :Edge : Input : Output : State |

Full Text |

HETEROGENEOUS HIERARCHICAL MODELING FOR
KNOWLEDGE-BASED AUTONOMOUS SYSTEMS By VICTOR TODD MILLER A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 1993 TABLE OF CONTENTS page ABSTRACT iv CHAPTERS 1 INTRODUCTION 1 Heterogeneous Hierarchical Modeling 1 Motivation for Research in HH Modeling 6 Contribution 7 Related Work and Topics 9 Outline 11 2 BASIC CONCEPTS 14 Modeling and Simulation Concepts 14 Formalism Classifications 18 Hybrid Model Theory 19 General System Theory 20 Basic Modeling Paradigm 22 Definitions 27 Time Domains 28 Named Sets 30 3 FORMALISMS 33 Graph Theory 33 Finite State Machines 34 Markov Systems 37 Petri Nets 39 Queuing Networks 42 Control Theory 44 4 HYBRID MODEL THEORY 47 Model Structure 47 State Modeling 51 Parallel Modeling 58 Selective Modeling 62 5 HYBRID ANALYSIS 68 KAS Modeling 68 A Heterogeneous Hierarchical Modeling 71 Hybrid Analysis 75 Symbolic Analysis 76 Interpretation 80 ii 6 CONCLUSIONS AND SUMMARY 88 Conclusions 88 Summary 90 REFERENCES 93 BIOGRAPHICAL SKETCH 98 iii Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy HETEROGENEOUS HIERARCHICAL MODELING FOR KNOWLEDGE-BASED AUTONOMOUS SYSTEMS By VICTOR TODD MILLER August 1993 Chairman: Paul A. Fishwick Major Department: Computer and Information Sciences High autonomy systems generally require the use of multiple modeling formalisms and multiple levels of abstraction in order to describe their dynamic characteristics accurately and efficiently. It is often necessary to integrate several modeling formalisms if there is a need to reason about, simulate or analyze a system. Additionally, during development, the use of a hierarchical representation helps to organize the models more intelligently. Heterogeneous hierarchical modeling is a method which supports multiple representations and hierarchical development of knowledge-based autonomous system simulations. In this context, hybrid model theory is developed as a theoretical representation which provides the necessary formality to meet the requirements of heterogeneous hierarchical modeling. Hybrid model theory is an alternative approach to combined discrete-continuous multimodel theories and subsumes most of the concepts in combined discrete-continuous system simulation. Hybrid model theory supports a new concept in heterogeneous hierarchical modeling called intramodel coordination. Intramodel coordination is a method in which the components of a model can be coordinated with other models. In this manner, hybrid model theory extends the notion of intermodel coordination in combined discrete-continuous system simulation. Intermodel IV coordination is a method in which two models can only interact through input and output. Furthermore, a hybrid model is a declarative representation of a system. By restricting the form of this representation, a hybrid model contains the data necessary information for a computer environment to perform symbolic, numerical and interpretative analysis automatically without additional effort from the user. v CHAPTER 1 INTRODUCTION Heterogeneous Hierarchical Modeling An essential part of any system description is the development of a model. Ideally, the model represents the behavior of the system under investigation at some level of abstraction. In the context of simulation, the process of developing tins model is generally called simulation modeling or simulation methodology. The extent of the modeling process itself varies not only from individual to individual, but also from paradigm to paradigm. This work focuses on the issues of the modeling process in computer (digital) simulation. The domain is limited to systems for traditional engineering purposes. The processes and formalisms for biological, social and self-evolving systems may or may not be applicable to this discussion. In this context, hybrid model theory is developed as a theoretical representation which provides the necessary formality to meet the requirements of heterogeneous hierarchical modeling. Hybrid model theory is an alternative approach to combined discrete-continuous multimodel theories and subsumes most of the concepts in combined discrete-continuous system simulation. Hybrid model theory supports a new concept in heterogeneous hierarchical modeling called intramodel coordination. Intramodel coordination is a method in which the components of a model can be coordinated with other models. In this manner, hybrid model theory extends the notion of intermodel coordination in combined discrete-continuous system simulation. Intermodel coordination is a method in which two models can only interact through input and output. Furthermore, a hybrid model is a declarative representation of a system. By restricting the form of this representation, a hybrid model contains the data necessary information for a computer environment to perform symbolic, numerical and interpretative analysis automatically without additional effort from the user. 1 2 The term modeling will be defined as a formalism and its associated methodology (if one exists). In simulation, most modeling techniques are low- to mid-level paradigms. At most, these techniques are stages in some potential methodology [Fis89b], In the last decade, however, expanding the techniques of simulation methodology has received great attention [Cel82, Elz89, Pui89], Additionally, new paradigms with associated methodologies have emerged and have been implemented [Nan87, Zei90], One of the most import concepts to manifest itself from the research in simulation methodologies is the idea of a hierarchical model. Hierarchies have been used in highly abstract modeling environments [Cel92, Zei90], at the formalism level [Gor90] and at the numerical level [Syd82]. A hierarchical model is a model which has several different levels of representations and abstractions. These levels are related to each other by a hierarchy. The types of hierarchies most commonly used in simulation are structural, conceptual, and class hierarchies. A structural model decomposes the model into levels which resemble the actual system. Usually this requires that the system has well established physical attributes. A conceptual model may or may not have a decomposition similar to the system, but always has components which do not have physical counterparts in the system. These decompositions resemble the approach used in software engineering. A class model decomposition resembles the approach used in object-oriented programming. (The object-oriented class hierarchy actually originated from SIMULA 67, a language designed for discrete simulation [Bir79].) In a class hierarchy, the model is not decomposed hierarchically, but the objects used to described the model are created hierarchically. A hierarchy is used to classify objects into types. It is important to distinguish the classifying of domain models as opposed to the classification of the formalisms used to describe domain models. A hierarchy which classifies vehicles (objects like truck, car, motorcycle, Buick, Honda, etc.) organizes the domain of vehicles. A liierarchy which classifies formalisms (state, functional, process, Petri net, control theory, semantic nets, expert system, etc.) organizes the domain of formalisms which are used to describe other domains. In this discussion, both hierarchies are used to organize concepts. 3 Another important concept which has emerged in simulation modeling is the use of multiple formalisms within one model [Pag89, Fis91 h] . With the increased interest in hierarchical modeling, the need to represent efficiently each level of a knowledge-based autonomous system model (KAS model) has become important for many reasons. Some modeling formalisms capture certain aspects of system behavior better than others (developmental efficiency). Other modeling formalisms may provide the means to discern important features that are not evident in other formalisms (conceptual efficiency). The use and benefits of multiple models types has been investigated in theories such as multifaceted modeling [Zei84] and heterogeneous interlevel refinement [Fis91a], Tire general concept of heterogeneous modeling draws upon research in multimodels, combined models, multifaceted models, homomorphic models, and abstract models. One of the ways of advancing the field of simulation requires improving the available modeling methods. Heterogeneous hierarchical modeling improves methods by aiding in the development, maintenance, simulation, and conceptualization of KAS models. It does this by providing a variety of succinct formalisms and the techniques for integrating them. Submodeling is the process of either refining a model or specifying several alternative models for a model. Refining a model requires adding detail, for instance, refining a Petri net into a queuing model. Refinement of a model introduces subtleties of components of the model. Specifying alternatives for a model requires that only one alternative model be active at a time [Ore91], Submodeling can require homomorphic behavior [Zei84, Sev91] between different levels of abstraction. Additionally, multiple formalisms include multiple types of simulation and integrating the taxonomy of models [Ore89bj. For example, Prahofer has integrated the representation of continuous and discrete event models in the same simulation environment [Pra91a, Pra91b], Heterogeneous hierarchical modeling is a modeling process which supports multiple formalisms and supports hierarchical development as described above. Model evolution and engineering [Fis89a] are natural attributes of such a process. Heterogeneous hierarchical 4 modeling (HH modeling) allows an investigator to develop a model in a top-down fashion. The benefits of top-down design have been well established in many disciplines. The hierarchy not only aids the investigator in development and conceptualization of the model, but serves as a history of the development process itself. The history of a modelâ€™s development may play an important role in the evolution or engineering of the model. In any modeling environment, the investigator must have the maximum available flexibility in development while ensuring that inconsistencies within the model do not arise. Because checking for inconsistencies in large and multiple models can be tedious and complex, it seems natural to conclude that the development of methods for automating a HH modeling process will be useful. Two of the major inconsistencies in HH modeling methodologies are compatibility between levels of the model and compatibility among different types of models. The number and type of formalisms in an HH modeling environment should provide the investigator with a sufficient range of choices (Petri nets, Markov systems, etc.). Of course, no modeling system will be perfect for every domain, but the interactions among a sufficient number of formalisms should give the investigator a flexible environment which can be applied to a very general domain. Currently, many of the hierarchical systems allow only one type of formalism, for instance, hierarchical Petri nets or state machines. Many of the multimodel systems, such as GPSS [Sch91] or SIMAN [Peg90], allow only one level of abstraction. Combining hierarchies and heterogeneous models has just recently received attention in the literature [Fis91b], A generalized and formal theory of HH modeling has yet to be developed. The motivation for the development of HH modeling is derived from several different sources. The contribution it can make to the modeling process in general has been speculated but not confirmed. This work is a direct result of these issues. A growing but still underrepresented topic in modeling research is the ability to analyze a single model using symbolic, numerical, and interpretative techniques. Symbolic techniques are mathematical procedures which involve manipulating algebraic or differential equations. With the 5 increased use and availability of programs that do symbolic mathematics, it is becoming increasingly easier to automate symbolic analysis (especially of well-known modeling formalisms). Numerical techniques refer to traditional computational simulation methods and numerical approximation. Interpretation methods are those that are related to the field of artificial intelligence and knowledge engineering. These range from fuzzy or quantitative simulation [Fis91b] up to and including logic methods and semantic networks. In general, hybrid analysis (symbolic, numeric, and interpretative) requires different model specification strategies and processes for each type of analysis. This duplicates a substantial amount of effort on the part of the investigator. It also makes it impossible for information gained in one type of analysis to help or guide a technique in another type of analysis (unless the investigator transmits "by hand" this information from one modeling formalism to the other). A legitimate approach to HH modeling is to develop a new modeling formalism which is oriented toward KAS models. In order to provide insights into the complex behavior of KAS models through simulation and reasoning methods, efficient and succinct representations must be used to describe all aspects of behavior which are pertinent to the investigator. It is unlikely that one modeling formalism would provide such a representation. This assertion is based upon the pragmatics of model building. Specific modeling formalisms are used by investigators because they are convenient to use, have preferable attributes, or fulfill some pragmatic requirement [Rot90], There are clearly two dilemmas to investigators of KAS systems. First, since pragmatic issues are dictated by the investigatorâ€™s preferences and convenience, and pragmatic issues vary within different sections of large complex systems, a single modeling formalism locks the investigator into a method which is neither preferable nor convenient. The second dilemma concerns the trade-offs between convenience and generality. For example, queuing networks may be efficient for modeling arrival/departure behavior, but not general enough for the modeling of complex KAS models. Similarly, simulation languages such as GPSS are general enough to be used for almost all types of simulation, but lack the developmental efficiency, conceptual efficiency and convenience of mathematical-based 6 modeling formalisms. Additionally, simulation languages have traditionally lacked symbolic and interpretative analysis methods. In short, the more general a formalism becomes, the less efficient it is to use. With tins in mind, an HH modeling theory which is based on coordination of existing modeling formalisms is an attractive alternative to developing an all-encompassing, completely generalized, single formalism. Since modeling formalisms such as queuing networks and finite state machines have proven to be powerful methods, but limited to specific domains, a coordination of these modeling formalisms, which keeps the representational power of each formalism intact, should foster more complete investigations of complex high autonomy systems. Furthermore, by coordinating established modeling formalisms, the learning curve needed to understand the theory is reduced. HH modeling can be accomplished by letting the investigator use an appropriate modeling formalism to describe a particular component of the system and then allowing a coordination of this formalism with models that describe other system components. The investigator may also need to reimplement subcomponents of a particular model as new information is gained during development and analysis (perhaps with a different modeling formalism). Efficiency and succinctness are supplied by the mathematical formalism whereas the coordination of several formalisms increases the generality. Motivation lor Research in HH modeling There are several research issues which motivate the development of heterogeneous hierarchical modeling. Among these issues, the most basic, yet very important, is advancing the field of simulation. Oren [Ã“re89a, pg. 30] writes. Since use of models is essential in simulation, advancements can be achieved by exploring advances in model-based concepts such as: modeling formalisms; modeling environments; model-based management; and symbolic processing of models. 7 By using multiple models, HH modeling expands the notion of a modeling formalism. Research in multiple models is not new. However, it is still in the early stages of development and requires further exploration. Combining multiple models within a complex hierarchical structure adds new problems and complicates current problems of multiple model research. The hierarchical modeling process is related to research in model-based management and modeling environments as described by Oren. The hierarchy serves to manage the development and structure of the model. The top-down approach commonly used with hierarchical models helps to prescribe management methods. Furthermore, a hierarchy describes the traversal path a modeling environment might use. Any environment which aids the investigator by allowing perusal of the model structure can use the natural structure of the hierarchy to guide the investigator. One of the most important motivations for research in HH modeling is the contribution it makes to knowledge-based simulation [Fis91 a] and qualitative simulation [Fis91b, Kui89], In knowledge-based simulation, information about the model is used to aid the investigator by suggesting alternative formalisms, answer questions about the model, increase semantic relationships between parts of a model, and help develop intelligent agent and goal-directed systems. HH modeling establishes formal relationships and clarifies the semantic relationships between different levels of abstractions in a model and different types of formalisms. For instance, a continuous model which has well-defined system states can be described by a state machine at the top level of a hierarchy and difference equations at the bottom level [Fis91b], The formal relationships of HH modeling ensure correctness of the model. The hierarchy clusters information which is useful in grouping behavior, and the type of model specifies semantics about the particular level. A knowledge-based simulation and environment requires such information in order to suggest improvements, guide semantic development, or analyze autonomous decisionÂ¬ making models. Therefore, a strong motivation for developing HH modeling is to help establish a foundation for knowledge-based simulation. s An important part of research in qualitative simulation is the ability to ask questions that require varying degrees of specification. An investigator may be interested in symbolic information in one question (will the ball bounce and if so, will it bounce high) or numerical information in other questions (how many times will it bounce and how long will it take to stop). These questions require different levels of abstraction and different levels of implementation. A hierarchical model provides, by its very nature, different levels of abstraction with corresponding formalisms capable of providing data appropriate for that level of abstraction. Similar to the motivation for knowledge-based simulation, HH modeling development helps to establish a foundation for qualitative simulation. Contribution The motivations in the previous section identify two general contributions. First, by developing formal and semantic relationships between different types of formalisms, HH modeling contributes to research in expert systems and knowledge-based simulation. Second, by developing the formal relationships between abstract levels in hierarchical models, HH modeling contributes to research in qualitative simulation. Although these two contributions are important, they are not direct contributions to the state-of-the-art simulation environment. HH modeling will form a solid foundation for knowledge-based simulation systems. The direct contributions HH modeling can oiler to state-of-the-art simulation environments are as follows: â€¢ Most simulation environments and libraries offer an investigator multiple models from which to choose . However, they do not help the investigator use them. How different models in the same simulation may interact is left up to the investigator. No facilities to check for inconsistencies among interacting formalisms are provided. â€¢ Designing simulation models is currently performed in an ad-hoc manner. HH modeling provides a structured way to create models efficiently in a top-down fashion. 9 â€¢ Changing simulation models as new data are collected or new constraints are added can significantly alter tlat models. The hierarchy of HH modeling serves to isolate independent parts of a model and therefore make them easier to maintain. â€¢ The hierarchy of formal models allows for incomplete models to be simulated. This gives the investigator feedback early in the simulation development phase. â€¢ HH modeling provides a mechanism to ask questions not only about the results of the simulation, but about the model being simulated. Additionally, the level of complexity of the question dictates the level of abstraction used in the simulation, and the level of ambiguity of the results of a simulation dictates the level of abstraction used to answer the question. â€¢ A generalized theory will make additional formalisms easier to include. â€¢ HH modeling allows formalisms to interact with each other instead of combining different formalisms into one. The complexity of modeling a large system is therefore broken up not only hierarchically but also conceptually. Related Work and Topics There are three fields of study which are indirectly related to the work presented in this research. These fields are artificial intelligence, software engineering, and knowledge-based simulation. The exact relationship is probably a matter of philosophical debate. However, the cross-fertilization of ideas between these fields is prevalent through out the literature [Fis92], Within AI, the work in qualitative reasoning [Bob8fi] is directly related to HH modeling. Qualitative reasoning, in general, is any type of formalism which is an abstraction of algebraic or difference equations. The recent work of Forbus and Falkenhainer [For90] and Kuipers [Kui89] is a good representative of the relationship between HH modeling and qualitative reasoning. In Forbusâ€™s paper, self-explanatory simulations based on qualitative process (QP) 10 theory [For86] are used to answer a variety of questions about a model at several different levels of abstraction. States in QP theory are based on equation limits. In Kuipersâ€™s paper, a qualitative graph of data flow with constraints is used to reason about incomplete systems. Qualitative simulation (QS) [Kui86] is used as the reasoning formalism. States in QS are based on specified landmark values. Knowledge representation (KR) is loosely related to this work. Typically, KR focuses on static relationships between objects. Frames [Hay79], semantic nets [Fin79], inheritance [Eth83] and logic [Moo82] all play roles in reasoning about static properties. Although temporal reasoning research is done in AI, for example Allenâ€™s work [A1183, A1184], dynamic properties about system state is confined to qualitative reasoning. Reasoning and questioning are considered synonymous in this work. Therefore, when a question is posed to obtain properties of a model, reasoning is taking place. In software engineering (SE) the use of formalisms to describe operational behavior is common and is found in literature explaining SE fundamentals [Ghe91]. Object-oriented programming is also an important modeling topic in SE [Har89], This emanates from software maintainability and reuse issues in which object hierarchies tend to assist. A good representative of the related work in SE is the new book by Rumbaugh et al. [Rum91]. Rumbaughâ€™s methodology uses objected-oriented concepts to define static properties which are very much like semantic nets in AI. The dynamic properties of a software project are described using state and process modeling techniques. Although this methodology is not formal (theoretically or computationally), it is a thorough embodiment of process modeling. Within simulation research, any topic which uses object-oriented concepts or AI concepts is related to this work. Expert systems to analyze output, suggest models, or analyze sensitivity need to be able to ask questions (reason) about models and be assured that the answers have a sound foundation. Integrated software environments which help an investigator construct models must be able to ask questions (reason) about models and be assured that the answers have a sound foundation. 11 All these areas of research have at least one thing in common: they must refer to abstract properties about complex models. Yet, the formal theory of abstract, hierarchical, or heterogeneous models is relatively unexplored. Sevinc [Sev91, pg. 1118] recognizes this when referring to model abstraction. He states, No complete theories of model abstraction exist, nor does any sufficiently general procedure. The field, with only less than a half a dozen published articles, is wide open. There is a distinction here which must be made. Sevinc refers to the simplification of a preexisting model. HH modeling is just the opposite, the refinement of a more detailed model from an abstract model. However, the theory used to describe homomorphic behavior as described by Sevinc should be independent of the development methodology. Directly relating to this work is research by Zeigler [Zei76], Wymore [Wym86], and Sevinc [Sev91 ]. These works consider homomorphisms, or derivations thereof, as the basis for model abstraction. In particular Zeiglerâ€™s work in discrete event system (DEVS) [Zei84][Zei90] and Priihoferâ€™s continuous-discrete system [Prii91a] were considered as a starting point for this work. Three important differences should be pointed out. First, HH modeling extends this research to nondeterministic formalisms. Second, hierarchies of model formalisms dominated this work. Zeiglerâ€™s and Prahoferâ€™s hierarchies center around the specific domain in question. These hierarchies are formed by coupling models together. Without the lower level models, no simulation can be preformed. In HH modeling, the goal is to simulate incomplete abstract models which generalize some, for the present, unknown behavior. Third, HH modeling allows a top- down and bottom-up approach to developing models whereas DEVS is a bottom-up approach. Almost without saying, this work is a spin-off of Fishwickâ€™s research, so much so that it would be impossible to enumerate. However, the relationship between SE, AI, and simulation [Fis89b] and heterogeneous models [Fis92] are of particular importance. 12 Outline In Chapter 2, the underlying modeling paradigm is introduced. A basic introduction to modeling, simulation, and system theory also is given. This provides a review of the basic concepts that are used in later chapters. Also, notation and meanings of important terms are defined. General system theory (GST) will be the foundation upon which a theory of HH modeling is developed. However, the GST definition does not have sufficient structure for what is called component coordination (GST does handle model coordination and was therefore a good starting point). Also, GST does not clearly integrate with domain independent knowledge- based reasoning techniques. Therefore, in order to support HH modeling, GST has been extended by including connectivity and abstraction concepts. In Chapter 3, the formalisms chosen to represent modeling types, their use in simulation, their basic theoretical foundations, and their system description are presented. Specifically, five formalisms will be discussed: automata theory, Markov systems, Petri nets, queuing networks, and control theory. With these five formalisms, a sufficient spectrum of formalism types will be available to model a complex environment. However, these types are conceptually different enough to provide nontrivial problems in their integration within a unified framework. Chapter 4 presents the modeling paradigm developed to support HH modeling. The modeling paradigm is called hybrid model theory. This presentation includes a formal characterization. Hybrid model theory is a direct attempt to simultaneously embrace two themes which are directly related to HH modeling. First, it expands, clarifies, and establishes a solid mathematical foundation for the notion of heterogeneous refinement as introduced in Fishwick and Zeigler [Fis92]. Second, hybrid model theory furnishes a premise for hybrid analysis of a system represented by a heterogeneous refinement model. Some minor modifications of the formalisms presented in Chapter 2 are made. This allows for the coordination between formalisms. The modifications will not alter the behavior of the formalisms. In some cases, however, the computational power of the formalisms may increase. 13 In Chapter 5, the benefits that HH modeling using hybrid model theory provide are demonstrated by the modeling of an automated tlexible manufacturing system (AFMS). Traditional formalisms such as Petri nets, Markov systems, and block diagrams are used to create a heterogeneous hierarchical model efficiently. The symbolic and interpretative analysis methods are emphasized in this chapter. The numerical analysis is discussed briefly. A conclusion and a summary are presented in Chapter 6. This includes the problems and shortcomings of hybrid model theory. Additionally, a brief discussion on how hybrid model theory provides a foundation for hybrid analysis is presented. CHAPTER 2 BASIC CONCEPTS Modeling and Simulation Concepts There are different definitions for many of the general terms used in modeling and simulation. The definitions presented in this section may or may not be similar to common interpretations (although most are very similar). It is particularly crucial that the scope of the definitions presented be understood. For instance, a description of a model typically implies that the model has a time base [Wym77, Zei76]. The interpretation of a time base can vary between formalisms (e.g., between Petri nets and control theory). When using different types of models together, the meaning and scope of time must be expanded to accommodate an appropriate range of usages. The most basic and most difficult term to define is model. For the purposes of discussion, a model is a representation or reproduction of a concept or physical object. The representation must have a formal description, that is, well-defined terms, entities, and operations on those entities. It may appear that representations which are only well defined unjustly restrict the numbers and types of models. However, as will be demonstrated later, a heterogeneous hierarchical model must maintain a mapping between levels of abstraction. Therefore, a representation must be well defined. Consequently, a well-defined representation is also called a formalism. Mathematically, such a lose definition of a model is unusable. Therefore, a recursive definition of a model based on a system will be given. However, only a conceptual description is given here. This definition will be refined (i.e., well defined) in Chapter 4. Given a finite set of primitive (atomic) systems, a model is defined as 14 15 1. An atomic system 2. A structured collection of atomic systems 3. A structured collection of models. The specifications of "structured collection" are given in Chapter 4. The above definition differs from traditional model definitions in systems theory. Here, all models must be built upon a finite set of atomic models (a finite set of primitives). Note this is different from a finite set of model types or classes. As stated in the introduction, modeling will be defined as a formalism and its associated methodology. However, no commitment to either prescribed methodology (e.g., top-down or bottom-up) is adopted in the theory presented in Chapter 4. The emphasis is on a top-down methodology, but this is for exemplification purposes only. The process of development is undefined in terms of how is it performed. What is to be done in the development process is quite clear; a model is to be created. As previously implied, the ability to model hierarchically (top- down or bottom-up) provides a mechanism for a methodology, but does not force a methodology to use that mechanism in any prescribed way. The term simulation means not only the prevalent processes such as queuing networks, Markov chains, etc., but also processes such as expert systems. Conceptually, an expert system is a simulation of a thought process. Expert systems have well-defined entities and a well-defined operation (rules and an inference engine). Rothenberg discusses this issue in greater depth and in a more general sense in "Artificial Intelligence and Simulation" [Rot90]. Knowledge-based simulation (KB Simulation) will be used to refer to the simultaneous activities of analysis, simulation, and interpretation of dynamic models. This definition is generally consistent with current literature on KB simulation [Fis91a], A diagram of the relationship among some of the terms introduced is depicted in Figure 2.1. This type of configuration is thoroughly discussed in Zeiglerâ€™s book [Zei76]. A system is represented by a model. The model is constructed through a modeling methodology and 16 processed by either a human or a computer. The symbolic analysis of models can be aided by the computer. Likewise, techniques in AI have begun to automate the qualitative interpretation of models [Fis91b], The problem with simultaneous analysis, simulation, and interpretation arises in the formal representation of different models. Heterogeneous hierarchical modeling is a theory in which all three types of activity are supported. Figure 2.2 shows the representation of these combined activities. modelling model A system modelling â€”* model B modelling model C analysis simulation interpretation human computer J human â€” Figure 2.1 Traditional Modeling system | modelling â€”Â» HHH model KB Simulation computer Figure 2.2 Hybrid Modeling Two important aspects of modeling which are not explicit issues of this work are validation and verification. Validating a model with a system ensures that the model represents the systemâ€™s behavior to an adequate degree of accuracy. Verifying the model with the computer/human ensures that the formalisms are processed correctly. Although it is quite probable that the development of HH modeling will impact validation and verification, they are not discussed explicitly. 17 The relationship between system and model is further refined by establishing a conceptual view of a system (Figure 2.3). A system exists in an environment. The boundary between a system and an environment determines what is to be modeled. In simulation modeling, the environment has no representation and the system is represented by the model. The interaction between a system and the environment at the boundary is represented in a simulation modeling by input to or output from the model. Environment System ^ Rnnnrlary i k Input/Output i Figure 2.3 Conceptual View of a System A system may be considered to be in one of several states at any given time. Typically, this is conceived of as a set of variables with each unique set of assignments to those variables being a state. A static system does not change with time while a dynamic system changes with time. Alternatively, a static system can be viewed as a dynamic system at a particular point in time. If a system has a unique set of outputs for each set of inputs, then the system is said to be deterministic. If the output of a system cannot be precisely predicted (or is random), then the system is said to be stochastic. Simulation generally deals with dynamic systems. However, KB simulations may include static systems. An event occurs in dynamic systems when the system changes state. If the system is changing state continuously over time, then it is a continuous system. Systems which change only at specific points in time are discrete-event systems. Similar definitions can be found in Bankâ€™s book on discrete-event simulation [Ban84J. 18 Formalism Classifications There are two general classifications of formalisms that will be modeled in Chapter 4: state (operational, declarative) and functional (process, procedural). Together these general classifications cover a large number of specific formalisms. A state formalism represents states as entities. A simulation progresses as the model moves from one state to another regardless of whether time is elapsing. Figure 2.4 shows an example of a state model. The three entities (si-3) in Figure 2.4 represent system states. An arrow represents moving from one state to another. Each state is exclusive of each other (although some formalisms may allow parallelism). An example of a state model might be the states of a drilling machine: working, turned-off, or under-repair. Figure 2.5 Typical Functional Model Diagram 19 A functional formalism is depicted in Figure 2.5. This is very similar to a data flow diagram. Each block represents a mapping (fl-4 in Figure 2.5) which transforms input to output. The state of the system is represented by the collection of internal states of each block. The arrows represent data transfers from one block to another. An example of a functional system would be an electrical circuit. Each block represents a component: resister, capacitor, etc. The data transferred is the current (electrons). It should be noted that functional systems are commonly used as parallel models; this is complementary to state systems which are commonly sequential. Hybrid Model Theory Hybrid model theory is a direct attempt to simultaneously embrace two themes which are directly related to HH modeling. First, it expands, clarities and establishes a solid mathematical foundation for the notion of heterogeneous refinement as introduced in Fishwick and Zeigler [Fis92]. In Fishwick and Zeiglerâ€™s presentation, the concept of heterogeneous refinement was described as a method which helps bridge the gap between AI and simulation models in a formal manner. However, the refinement process was carried out "by hand." Hybrid model theory expands the concept and provides a foundation that allows heterogeneous refinement to be automated. Second, and most important, hybrid model theory furnishes a premise for hybrid analysis of a system represented by a refined multimodel. The extent of hybrid model theory encompasses a single model. This is an augmentation to theories, such as general system theory, which deal with classes of models. It should be noted that hybrid model theory is a foundation which allows HH modeling to be implemented. There are certainly other approaches. However, hybrid model theory is an approach much like compiler theory. All programming languages can be described by compiler theory, yet there are many different types of programming languages which suit different purposes. The intention with hybrid model theory is similar; it is not expected that investigators 20 will use hybrid model theory as a formalism. Hybrid model theory is used to explain, mathematically, the commonalities and differences between modeling formalisms. With this foundation, the coordination of different formalisms such as Petri nets and block diagrams can be substantiated since the relationship between them has been formally established. General System Theory There are several different ways each formalism can be represented (presented in the next chapter). This produces a large permutation of coordination techniques. General system theory will be used as a starting point towards developing a common representation for the formalisms which are presented in this work. This section only introduces the mathematical foundation of systems theory for background and informational purposes. Most of the material described here is derived from Wymoreâ€™s book [Wym77], A system is a 6-tuple Z = (T, I, S, A, B, 5), where T is the time base, I is a nonempty set called the input, S is a nonempty set called the system states, A is an admissible set of input functions f: T â€”> I, B is a set of functions f: S S called the Behavior, and 8 is a function f: A x T â€”> B called the transition function. The time base, T, is typically the reals (9t) or the integers (3). When T = 9Ã, the system is said to be a continuous system. When T = 3, the system is said to be a discrete system. The system can be considered to be like a function invocation, when the input set A along with a time t is given. The set of system states (S) varies greatly from formalism to formalism; however, it usually has the structure of an n-tuple or vector. For instance, the states of a state machine are usually represented by a 1-tuple (simple set), and the states of a continuous system are typically represented by a vector space on a field (such as 9vn). 21 The admissible input functions represent the class of input schedules or input histories. Given a time segment t, a function in A gives the input presented to the system. This implies that the inputs to the system must be predetermined in order to analyze the system. The behavior functions (B) define the class of system sequences (discrete systems) or trajectories (continuous systems). The transition function generates a behavior function for a given input function and a time segment. Given an input function, initial conditions, and a transition function, the behavior of the system is completely deterministic. The relationships between systems theory and the simulation concepts described in the last section are fairly clear. A simulation model is a super-set of a system. Both a model and a system have inputs, states, and behavior. One can extend a system structure to include output by adding the following definitions O is a nonempty set called the output and X is a function f: S x T â€”> O called the output function. A major distinction between a simulation model and a (classical) system is that a simulation model can be nondeterministic. However, in an abstract sense, there is a close correspondence between model and system. For example, in Figure 2.4, the state model consists of states with arcs labeling transitions from state to state. In systems theory, the model in Figure 2.4 is S = {si, s2, s3} and 8(A, t)(sl) = s3; 8 (A, t)(s2) = si; 8 (A, t)(s2) = s3; 8(A, t)(s3) = s2. Similarly, in Figure 2.5, a system can be derived by letting S be the cross product of the functions (IT Fj) and 8 (A, T) be the set of equations. Fishwick [Fis91b] presents a similar description of simulation modeling with systems theory. 22 Basic Modeling Paradigm In the next chapter, the basic mathematical foundation of the formalisms used in this work is presented. Although one can find theoretical extensions of these formalisms in the modeling literature, this is nothing more than an attempt to combine formalisms (multimodels). This research uses an alternative approach. Instead of forcing a formalism to include other theoretical and semantic aspects, each formalism remains as close to its simplest or most common form, and a method is developed in which these different simple formalisms can be used together. The foundation for this approach is based on three premises. First, the formalisms in their simplest state are well understood: Why develop or extend (yet another) formalism that is not well known when two well-known formalisms already exist? Second, researchers and investigators already use these formalisms. Not only are the formalisms understood but they are used frequently. Third, and most important, combining different aspects of different formalisms increases complexity at one level of conceptualization. By keeping each formalism separate, and introducing a simple way to interconnect them, the complexity has been separated into distinct parts. Consequently, inefficiencies in implementation may exist. However, efficiency in modeling can be improved. An underlying assumption here is that human time is more valuable than computer time. The compilation of a model (implementation) can be carried out by the computer whereas (at the moment) modeling is done by humans. The distinction between a formalism and a theory is defined as a difference in generality. A formalism (Petri net, state machine) has relatively clear semantics pertaining to its use and dynamic properties. A theory (system theory, computation theory) is a more generalized mathematical system which usually can describe any known formalism. Because of the generality, automated analysis is typically infeasible. Five common modeling formalisms are used as representatives of different modeling techniques. These fall into the two general classes above: state models or functional models. State machines and Markov systems were chosen as examples of state model formalisms. Queuing networks, Petri nets and block diagrams (control theory) were chosen to represent functional 23 model formalisms. The diagrammatic aspects of each specific modeling approach is preserved. There is no attempt to homogenize modeling or to force all models to look like either data flow diagrams or state transition networks. All model types have an equivalent graph or network representation. This is necessary in order to support knowledge-based reasoning methods (interpretation). However, this has not reduced the effectiveness of the theory presented since many modeling formalisms have graph or network equivalents. More specifically, the proposed paradigm requires that a formalism be represented by a directed graph. Arcs (edges) which lead out of a node are output arcs and arcs leading into a node are input arcs. Nodes in the graph represent either computational or storage models. As with most theories of modeling, there are two basic types of models: atomic and structured. However, in hybrid model theory a state machine, Petri net, etc., are not atomic models but structured models. In hybrid model theory, structured models are made up of at least two hierarchical levels. The first level is called a controller model. As will be shown, for a variety of formalisms only three controller models are necessary. The second level in the hierarchy is made up of atomic models called component models. This split-level approach to models is demonstrated in Figure 2.6. Figure 2.6 Two Level Representation of a Model Formalism. 24 As can be seen from Figure 2.6, data (or control) input and output are directed into the controller model. The component models (nodes in the graph) may or may not have data input and output. Depending on the type of controller, edges in the graph will either indicate control flow or data flow. This dual functionality has been captured in the controller modelâ€™s interpretation of its components. Only under direction of the controller model is data input and output passed down to and up from the component models. This, at first, gives the impression of being very inefficient. However, when the model is compiled for numerical analysis(simulation), this inefficiency can be removed if and only if there has been no submodeling. When using interpretation techniques, this split-level method allows for more generalized knowledge. When analyzing the model symbolically, it allows combined results from different types of symbolic analysis. Chapter 4 introduces hybrid model theory in terms of numerical analysis (simulation). Chapter 5 shows by example how symbolic and interpretation analysis can be performed. Formalisms are classified based upon three attributes: 1) how they use time, 2) the type of data they use, and 3) the type of controller. Hybrid model theory supports four types of controllers: parallel, state, selective, and group. All four of these controllers contain the connectivity of the components they control (the graph). A parallel-controller model controls component models in which all components are active simultaneously. Edges between the components are interpreted by the controller as data paths. Formalisms which have this type of controller are block diagrams, confluence graphs, bond graphs, and neural networks. A state- controller model controls components in which only one component can be active. The controller, under direction of the components, keeps track of the current active component. Edges between the components are interpreted by the controller as control paths. Formalisms which have state controllers are Markov systems and state machines. The selective controller is the most complex. This controller controls two types of component models: functions and storage. A selective controller first determines which function components can be activated and then nondeterministically chooses one of them to activate. The function components may use any of the storage components for data input and output. Edges between the components are interpreted 25 by the controller as data flow. Formalisms which use selective controllers are Petri nets, queuing networks, and expert systems. A group controller is a parallel controller in which the components are structured models. The group controller allows hybrid model theory to encompass traditional model coordination (coupling) and will only be briefly discussed. The type of data which may be used by a formalism has two general attributes: value and time. Each of these attributes may be either continuous or discrete. This expands the typical continuous versus discrete concept of a signal in system theory. A discrete signal is too ambiguous of a categorization when combining symbolic analytical techniques and for interpretation techniques of different formalisms. It must be known whether a signal is discrete (continuous) over its values and over time. The third element which classifies a formalism is the way in which time is used. There have already been significant advances in combined discrete-event and continuous model simulation through the use of time bases [Pra91a], This forms the foundation for hybrid model theory. However, the time description is extended to include elements necessary for symbolic and interpretation methods. This extension is called a time domain. The concept of a time base which is used in system theory becomes one of live elements used in a time domain, the most important of which is the time map function. The time map of a time domain is a function from the reals into the time base of the model. This allows coordination of all models with a common time base. Each model is responsible for mapping the common clock into local time. This concept, along with local model states, allows hybrid model theory to be easily translated into a distributed simulation when numerical analysis is required. Thus, there is no main event queue during numerical analysis (simulation). All events are stored locally in a model and coordinated by a common clock. The other elements of a time domain relate information concerning the semantics of the time base. Currently, there are three elements: a zero point, a delta time, and a magnitude function. The zero point signifies the minimum time required for a model to change an output signal given 26 a change in the internal state. The delta time signifies the minimum time required for a model to change its internal state. The magnitude function maps a time from the time base into the integers. This function permits a model to specify significant magnitude changes in time. Group Controller Model state machine Petri net | W | * queuing net Figure 2.7 Intermodel Coordination Intermodel coordination is another term for model coupling [Zei84, Wym77], Because hybrid model theory has incorporated system theory, this type of coordination will not be extensively explained. Model coupling can be found in most system theory literature. From Figure 2.7, it should be clear that complex models of varying types can be coordinated through their data input and output. A collection of these models can then be grouped into a new model. An important advantage in hybrid model theory is that the intermodel coordination need not be static. That is, during execution or analysis, since the controller model contains the connectivity along with the functionality, the couplings can be dynamic; the controller can manipulate the connectivity of its components. This may become useful in certain types of neural network formalisms, for instance, as weights between neurons may become zero. Intramodel coordination involves the replacement of a component model with a new structured model. The model hierarchy is therefore a structural or conceptual hierarchy. This is 27 quite different from intermodel coordination where, for instance, the output of a state machine is the input to a block diagram. In intramodel coordination, for example, a state component in a state machine controller model is replaced by a block diagram model [Fis92], The controller model of a state machine essentially keeps track of several component models. Whether these components are simple state models which are based on conditions (input = â€™aâ€™, etc.) or complex models such as block diagrams is inconsequential to the controller. The only requirement is that the communication between the controller and its components be standardized in a formal protocol. The same type of argument holds true for parallel, group and selective controllers. In Chapter 4, the theoretical details of controller-component intra model coordination are presented. Definitions Before continuing into more formal concepts, a few basic definitions and their designations are introduced. The meanings are generally well known, but it is essential that the interpretation of the designations used be clear. Therefore, they are presented here instead of being put into a key of symbols. The unique symbols used are self, true, false , 0, and f. The empty set 0 and the booleans true and false have their usual meanings. The symbol self is used to designate a symbolic reference to an entity wliich uses it. The symbol self is further explained in Chapter 4 where it has a special meaning in hybrid model theory. The symbol t is used to represent the notion of undefined (general math), null (programming), empty-string (automata), transient state (circuits), and bottom (programming theory). Depending on the domain, the appropriate term is used. As a standard throughout this work the following notation is used. The only notable difference is that all function invocations are designated by square brackets []. [ ] function application f [ i ] { } general set () ordered set - sequence 28 < > structured set and named set ni cross product over i sets Additionally, the following special sets are defined. Z Integers u {t} N Z+nonnegative Integers u {t} R Reals u {t} B Booleans {true, false} u {t} M Model u {f} Two points are important here. First, all these sets are unioned with the undefined symbol {t}. Because these sets are usually used to specify values of variables, any variable in any model can be assigned the undefined value t- Time Domains The standard system theory notion of a time base will be used to specify the range of time values used by models in hybrid model theory. A time base is a structure consisting of a set and two operators: addition and comparison. The addition operator and the set must be an abelian group. The comparison operator and the set must form a linear order which is preserved under the addition operator. Time Base Typical time bases are the reals 91 and integers 3 with + and < defined appropriately. These time bases are abbreviated by Tgj and Tg. When a model or formalism has no time base, the null time base can be used. It is defined as T+. 29 Null Time Base T = {t} Group t = identity, operator f + t = t. inverse t =t"^ Linear Order t ^ t A time domain is built upon a time base. During the interpretation of a model, information about how the time is used by the model must be present. The time domain will serve this purpose. A time domain is a named set (a special kind of structure introduced shortly) which consists of live elements: time base, delta time, zero time, time map, and a magnitude function. A time domain TD is structured set T Time base dt small time in T, i.e., a significant change in time zero t e T such that everything < t is considered zero t[] time mapping 91 -> T m[] magnitude function T -> 3 such that rnfzero] = 0 The use of a time domain can be exemplified by the following two examples. Although the time base is the same, there are significant differences in how time affects human and computer systems. Human Time Computer Time T=T9Ã 7 = TTx dt = 10 millisecond dt = 1 picosecond zero = 100 milliseconds zero = 1 nanosecond 30 t[] = identity t[] = identity m[r] = integer[r/10*zero ] m[r] = integer [r/2*zero] The zero time stipulates what times are to be considered as instantaneous. That is, in times less than zero the system cannot react to input. Note that this is different from the delta time dt. The delta time indicates what times are significant in changes in state. For instance, it is assumed that a human can sense things in 10 milliseconds but cannot react until 100 milliseconds. Likewise, in a picosecond, changes in transistors are important, but a cpu reacts only in nanoseconds (i.e., memory accesses). The time mapping is used to relate all time domains to Tgj. This will be further discussed in Chapter 4. The magnitude function is used to signify a constant state between systems. For example, for a time period of 0.9 seconds, the human magnitude function m[0.9] = 0 while the computer magnitude function m[0.9] = 450x10â€. For all practical purposes, in a time period of 0.9 seconds, a computer system can assume a human system is constant. The magnitude comparison can be used to circumscribe the system when any of the three types of analysis (symbolic, numerical, interpretation) are required. Named Sets In system theory, a convenient representation of assignment is represented by a structured set [Zei76, Zei84], In this work, these sets are referred to as named sets. Formally, a named set is a structure S - a set (entities) V - ordered set (parameters) R - indexed set (V is the index) R is the range A - assignment A: S -> nÂ¡ Rv.. 31 A useful accessing function called a projection allows the values of parameters to be obtained from the named set. It is defined from the entities into the range of a value set Vi. Formally, a projection is defined as prÂ°jv.:S ->Rv, As an example consider the assignment of a personâ€™s age and sex. A named structure is defined by the following S = {Tom, Jane} V = {age, sex} R = { (age, [0, 130}), (sex,{male, female}) } A = { (Tom, (23, male)), (Jane,(21, female)) }. A projection function on the age parameter and an application of the function is given by proj = { (tom, 23), (Jane, 21 )} projage[Tom] = 21 The projection function will be abbreviated in this work with the dot notation similar to typical programming languages. Tom.age = 23 represents proja ^[Tom] = 23 The conceptual and pragmatic convenience of named sets is the basis of building a fact base for a knowledge-based system in hybrid model theory. For example, if the projection function is 32 considered to be a predicate, then the Prolog style predicate sex[Tom, male] and the equation Tom.sex = male can be considered equivalent. When reviewing example models which used graphical formalisms, it was found that labeling arcs and nodes with text was always performed. This is extremely valuable to humans during the development of a model. There was also a tendency to be fairly consistent with the usage of verbs and nouns on arcs and nodes. Since the interpretation of nodes and arcs in these formalisms is relatively straightforward (i.e., arcs and nodes have relatively well-defined semantics in each of the formalisms), the text is included as part of hybrid model theory by using named sets. CHAI TER 3 FORMALISMS Graph Theory The formalisms presented in this chapter all have graphical equivalents. Since the graphs and the mathematical theory correspond to each other, the most convenient form will be used in the explication. In some of the formalisms, there is little or no distinction between graph and theory. Although graph theory is typically not used as a modeling formalism, most formalisms use graphs as pictorial representations or equivalents. In a general sense, a graph of a system is an abstraction. It shows states, components, transitions, data flow, causality, etc. In most cases it does not show computational or analytical properties. Therefore, it is a simplification of a system. Graphs are so useful as a modeling tool for humans that it would be imprudent to dismiss graph theory as a primitive theoretical modeling tool. It is assumed in this work that the structure of a graph is the defining factor for its usefulness as opposed to some physiological or psychological characteristic such as it is visual or pleasing to work with. Additionally, there are many analytical properties of graphs that are useful: spanning trees, articulation points, etc. All formalisms used in tliis paper use directed multigraph representations. The directed property is used to indicate transition in state formalisms or data flow in procedural formalisms. The multi property is used to represent alternative next states in state formalisms and multiple data flow in procedural formalisms. Formally, a graph is a set of vertices V and set of edges EcVxV. A nondeterministic system can easily be defined for state formalisms in which V is the set of states. This is, given a graph G = (V, E) then a system Z = (T, I, S, A, B, 5), where 33 34 T is empty, I is {{}}, S is V, A is {{}}, B is a set with one element D defined as {(vl, n): vie V and n = {v : (vl,v)e E}}, and 5 is 5(a,t) = D for all a e A, t e T. This system starts in some nondetermined state, changes the current state nondeterministically by following some edge, and stops if it reaches a vertex with no edge leading out. The graphical representation of a procedural formalism can be described by a system, but is is so simplistic (one state and no behavior) that it would be senseless to give the definition. Most derivations of system theories (outside of AI) are structured for analytical purposes at the very lowest level of abstraction (i.e., statistics). However, the graph of a system does represent information about the system causality, and yet it is rarely represented within traditional analytical techniques. Finite Machines Automata theory will be used to describe state machines. Differences will be pointed out when they occur. The typical use of automata theory is to model computational processes or analyze grammars. Most theoretical information in this section is derived from [Hop79], The main objects of a finite state automata (FSA) are state, input, and transition. Given a particular state and input, the transition function dictates the next state. Automata transfer state until a final state is reached. A push down automaton (PDA) uses a stack which is a last-in-first- out storage device with unlimited capacity. A PDA transfers from state to state given the current state, current input, and the element on top of the stack. The next state includes the definition of a new stack top. 35 Figure 3.1 shows a typical PDA. The arc from si to s3 with label a/x indicates a transfer from state si to state s3 when input a is given and the element on the stack top is x. The initial condition for a FSA or PDA is the start state. It is part of the FSA or PDAâ€™s formal description. Unlike a system in system theory, an FSA or PDA has final states. This implies (and is most often the case) that the FSA or PDA will eventually stop when given valid input. However, in the most general automata, turing machines, this can not be guaranteed. If the labels of a PDA are extend to a/ B, where B is a string of symbols, then the automaton is called a context finite state automata (CFSA). The context is B. The context can be used to store a history of the prior states or input. A CFSA can essentially examine the history of itself when deciding the next state. Figure 3.1 Example PDA. An FSA is very similar to a discrete system. Only the definition is given here, but a similar definition and proof can be found in the literature [Wym76], Given an FSA = (Q, Z, s0, F), where Q is the set of states, Z is the input alphabet, Q is the transition function, s0 is the initial state, and F is the final states, an equivalent system is Z = (T, I, S, A, B, 5), where T is 3, I is I, S is Q, A is all functions in Zn, n e 3 (any sequence of symbols from Z)- B is {Q} , and 8 is 5(a,t) = Ãœ. for a e A, te 3. 36 A system theory description of a PDA requires that the states be defined as Q x D*, where D is the stack alphabet. The next state function is similarly changed. Automata can be extend to encompass the property of nondeterminism. This is similar to but distinct from the notion of random or stochastic process. A nondeterministic FSA (NDFSA) allows for multiple transitions to be valid at the same time. Likewise, a nondeterministic PDA (NDPDA) or a CFSA (NDCFSA) allows multiple valid transitions. Although it has been shown that FSAs are equivalent to NDFSAs and CFSAs are equivalent to NDCFSAs, the nondeterministic counterparts are usually more concise descriptions and are used more often. There are many analytical properties about automata, especially FSAs and PDAs. Many of these properties analyze the class of languages that an automaton accepts. These properties are useful in the discussion of grammars, but they have not appeared in any literature relating to system theory and signals. The main interest in automata in system theory literature has been for control purposes and not for validating correct sequences of input. The stack of a PDA or the context of a CFSA allows the system to have a memory. This is a very distinct concept from any other formalism in this chapter and from classical system theory. Although the notion of memory and internal state are highly related formally, the difference in meaning can play a major role when attempting to interpret the system. Time is a notion easily integrated within automata. However, there is a difficulty when multiple formalisms are used. In a system representation of an automata, time is actually used to number or sequence the input. This works for descriptive purposes, but when integrating this with a continuous system where the time is 9\, there is still no specific identifiable relationship. The notion of steady state, which is important in system theory and several of the other formalisms in this chapter, is not pertinent for any of the automata. A nonterminating automaton is undesirable. For some formalisms (to be presented later), nonterminating behavior is essential for many analytical properties. This does not involve many theoretical difficulties, but introduces disparate images of the purpose of a system constructed from multiple formalisms. 37 Markov Systems A Markov system represents a stochastic process. It is a state representation. The transitions in a Markov system are stochastic. Each transition probability is based on the assumption that any past or future state is conditionally independent given the present state. Formally, a Markov system is a pair, Z = (S, T) where S is a finite set of states, and T is a function f:S x S â€”> [0.0, 1.0] called the conditional probability. The conditional probability T(sÂ¡, Sj) represents the probability of the next state Sj given the current state sÂ¡. In probability theory this is T(sÂ¡, sp = p(next state = sÂ¡ I current state = sÂ¡). It is required of the function T that for each state sÂ¡ T(sÂ¡, s^) = 1. This stipulates that the probability of the next state transitions add up to one. Figure 3.2 shows a simple Markov system with the transition probabilities on the arcs. A sequence of states Sj... s^ is called a Markov chain. The initial state of a Markov chain can be given in several ways. The conditionally probability function Ttsps^) is usually represented as matrix M. An entry in row i and column k is the probability T(sÂ¡, s^). It can be shown that the probability of being in state s^ in the chain sÂ¡... s^ is 8(sÂ¡)(Mn)Â¡ ^ , where n is the length of the chain, Mn is the nth product of M with itself and 8(Sj) is the initial probability of Sj [Cly90], Figure 3.2 Markov System 38 If there exists an n such that no entry in the matrix Mnis zero, then the Markov system is called regular. In a regular Markov system it is possible to go from a state to any other state in no more than n transitions. It can be shown that the limit as nâ€”will reach steady state equilibrium probabilities. If SS(Sj) is the steady state equilibrium and (Mn)Â¡ j is the entry row i and column j of the matrix Mn, then formally, for any i, Lim^^ (Mn)Â¡ j = SS(Sj). In comparison to system theory, there are several apparent differences between the two types of systems. A Markov system has no input. The environment can not affect the state of a Markov system. If it could, then many of the analytical properties would be unsound. Additionally, the initial state of a Markov system is nondeterministic. In the context of other formalisms, a way to specify the initial state must developed. For instance, if a Markov system is a submodel of a state within an FSA, then when that FSA state becomes active, the Markov system must be initialized. This can be nondeterministic; however, a deterministic method could also be devised. Since a Markov system has distinct states, it can be classified as a discrete-event model. An event in a Markov system is the selection of a transition. As a separate formalism, this does not complicate a system theoretic description of the Markov system. When using several formalisms together, this does create a problem. The events of different formalisms must be related to each other in some manner. Unfortunately, there is no time associated with transitions in a Markov system. If a state in a Markov system is submodeled with a formalism which explicitly uses time, then how do the other Markov states events relate to this submodel? A Markov system does not have a transition function. It is possible to develop one similar to a NDFSA. However, a way to assign a probability to the next state based on the conditional probability instead of the input must be developed. The behavior functions of a Markov system correspond to all possible finite paths through the graph. Each of these paths has a probability associated with it. Typically, the steady state 39 equilibrium probabilities of a Markov system are considered to be the defining factor in describing that system. Petri Nets Petri nets are typically used to model concurrent systems in which the objects of the system must have synchronized behavior. Additionally, Petri nets can be used to model resource allocation systems. Tire source for the information about Petri nets in this section is derived form Petersonâ€™s book [Pet81], There are three main objects in Petri nets: places, transitions, and tokens. Places and transitions alternate nodes in a graph (see Figure 3.3). A transition moves a token in an input place to an output place. This movement is called firing the transition. TÃrese attributes categorize a Petri net graph as a bipartite directed multigraph. The state of a Petri net is the number of tokens in each place. There is no time associated wilh Petri nets. Transitions fire, nondeternrinistically, transferring tokens form place to place. Alter a transition has had a chance to fire, the Petri net is said to be in a new state. place 2 place 3 Figure 3.3 Example Petri Net A Petri net is defined formally as a 4-tuple, Z = (P,T, I, O) where P is a finite set of places, T is a finite set of transitions, In is a function T â€”Â»PÂ°Â° called the input function, and Out is a function T â€”> PÂ°Â° called the output function. 40 Since P is a finite set, it is clear that PÂ°Â° is not a set but a bag (a set which allows duplicate values). Since a transition can have multiple arcs to the same output place, multiple copies of places are allowed in the sets In(t) or Out(t). Theories of bags have been studied; however, it is just as easy to represent a bag {a,a,b,b,b,c} as the set {(a,2), (b,3), (c,l)}. In any case, the function #(In(tj), pj) retrieves the number of arcs from place pÂ¡ to transition tj and #(Out(tj), pÂ¡) retrieves the number of arcs from transition tj to place pj. A marking m:P â€”> 3n for a Petri net is a n-tuple where n = cardinality of P (IPI). A Petri net with 5 places and a marking m=(l,3,l,5,4) has 1 token in place 1, 3 tokens in place 2, 1 token in place 3, etc. The function m(pÂ¡) retrieves the marking for place pi (i.e., above m(p2) = 3). Markings in Petri nets and states in systems are equivalent. Given a marked Petri net Z with marking m, a transition t in Z is said to be enabled if for all pi #(In(t), pj) <= m(pj). A enabled transition means that the transition can get a token from each input place for each arc. For example, if there are two arcs from a place to a transition, then there must be as least two tokens in that place in order for the above condition to be met for that place. When a transition fires, the tokens are removed from the places. If two transitions require the same token from a place in order to fire, then only one will fire if there are not enough tokens for both transitions. The choice in this case is arbitrary (nondeterministic). The next state of a Petri net is defined if at least one transition can fire. Otherwise the Petri net is blocked. Given a Petri net Z, a marking m, and a transition t, the next state 5(m,t) is formally defined as 5(m,t) = mâ€™ where mâ€™(Pj) = m(pj) - #(In(t), pÂ¡) + #(Out(t), pj). 41 There are several differences between a Petri net formalism and systems theory. A Petri net has no input. When using a Petri net, an initial marking mQ is given and next states are reached by firing transitions. The initial marking is a state not an input. Therefore, the environment can not effect the state of a Petri net. Since a Petri net has distinct states, it can be classified as a discrete-event formalism. An event in a Petri net is the firing of a transition. However, there is no time associated with these events. As an independent formalism, this does not complicate a system theoretic description of a Petri net. When using multiple formalisms together, this does create a problem. The events of different formalisms must be related to each other in some manner. An obvious choice would be to use time. With state machines, Markov systems, and Petri nets combined, the concept of time being related to state transitions (events) seems appropriate, but not the only possibility. The transition functions of Petri nets and systems are similar. The behavior functions of a system roughly correspond to the sequences of allowable states. Since Petri nets are nondeterministic, the requirement that the system behavior be functions must be relaxed; a systemâ€™s behavior is a set of relationships. There are several important analytical characteristics which are important in Petri net theory. All of these have definitions, but only the concepts will be presented here. The reachability of a Petri net is a set of markings which are reachable from some initial marking. This set is designated as R(Z, mo). Safeness of a Petri net with a given initial marking is defined when all places have 0 or 1 token. A place is k-safe (k-bounded) if the number of tokens never exceeds k for some given initial marking. A marked Petri net which has a transition that can never fire is said to be in deadlock. The transition (or transitions) is said to be dead. Transitions which can potentially fire are called live. Queuing Networks One of the most common techniques used in simulation is queuing theory. It is used to model waiting lines. Banks or grocery stores are typical examples of queuing systems. Queuing 42 networks are process oriented. There are three main objects in queuing networks: populations, queues, and servers. For analytical purposes queuing networks are conveniently represented by attributes of these objects. Tire notation is m/n/o/p/q where m is the interarrival time distribution, n is the service time distribution, o is the number of parallel servers, p is the system capacity, and q is the queue discipline. Tire theoretical material in this section is derived from [Ban84] and [Gra80j. o server 1 arrivals queue o server 2 Figure 3.4 Simple Queuing Network Figure 3.4 shows a simple queuing network. Tire arrivals node represents the calling population. This could represent customers at a bank, palettes in a factory, cars at a traffic light, or calls at a telephone exchange. An arrival from the population is called a customer. Tire arrival rate of customers depends on the population type. A finite population has a limited number of customers. Therefore, the arrival rate is influenced by the number of customers currently in the system. The arrival rate of customers for an infinite population is described by a distribution (usually the Poisson distribution). When customers arrive in the system they are queued (wait in line) until a server is available. In Figure 3.4 there are two server nodes. Each node represents 1 server. The service time for each server may be constant or random. Common random service times are represented by the exponential, gamma, and normal distributions. The queue node in Figure 3.4 appears to be a first-in-first-out (FIFO) line. This is a consequence of the graphical portrayal and not a true depiction of the queueâ€™s discipline. The same graphical description may represent a FIFO, last-in-first-out (LIFO), priority (PRI), or any other queue discipline. The capacity of a queue is the space available in the queue. If the queueâ€™s capacity is exceeded, then the system balks; arriving customers leave the system without entering 43 the queue. It is also possible for customers to leave the system if they wait to long or change queues in a multiqueue system. A queuing network with a Poisson arrival distribution has an exponential interarrival time [Gra80], If the service time for the servers in Figure 3.4 is exponential, the arrival rate is exponential, the queueâ€™s capacity is 5, and discipline is LIFO, then the notation used to represent the system is M/M/2/5/LIFO (where M stands for an exponential distribution). However, a complex system with multiple populations, queues and servers cannot be described with this notation. Most real world models are so complex that no attempt is made to a use concise notation; instead, the graphical representation is used. There have been many analytical properties developed for simple queuing networks. Since the variety of networks is very broad, each network type has different theoretical derivations. There are, however, common properties among the different types of networks. The distributions used to describe the arrival and service times are examples. Because the analysis is so varied, only a verbal definition of the most useful properties is presented. The expected time in the system is the average time a customer spends in the system. The time a customer is in the system is comprised of the time in queues and the time being served. Although it is typical to keep the expected time in the system as small as possible, the ratio of time waiting to time in the system is more important (especially to a customer). The expected number of customers in the system is important for determining queue capacities or the number of servers required. It is undesirable to have customers balk because queues are to small or to have servers idle because there are to many servers. The expected queue length and server utilization are measurements which help in deciding the systemâ€™s type as described above. The throughput of a system measures the number of customers served per unit time. Many times, the objectives of a queuing system are opposed to each other; for instance, to maximize throughput and utilization while minimizing waiting and service times. When a particular queuing network fails to meet the requirements of a population (determined by one or more of the above measurements), alternative types of networks are investigated. The 44 most complex of which is to change the queuing discipline (as opposed to changing the number of servers or increasing the capacity of a queue). Tliis has lead to a multitude of queue disciplines. Additionally, more realistic parameters have been introduced (balking, changing lines) or more complex networks. Because these are very difficult (if not impossible) to analyze, numerical approximations have become a norm in the analysis of complex queuing networks. The computational methods used in queuing networks are usually extensions to the above material. For example, customer attributes, resources and macro models are available in many of the commercial packages such as GPSS [Sch91] and SIMAN [Peg90], Additionally, more sophisticated packages have animation, such as CINEMA [Kal91], or graphical entry methods, TESS [Sta87], Despite tliis, the basic tenets for these system have evolved out of queuing theory. In terms of system theory, a queuing network is a discrete-event, nondeterministic process. The state of which can be described by a tuple. Each server and queue have a position in the tuple. For instance, a 2 queue, 2 server network is described by (qj, q2, sj, S2) where qj and q2 are the number of customers in the queue. The servers sj and S2 are either idle (0) or busy (1). The time base is 9Ã and there is no input into the system. The behavior can only be described in terms of steady state. Control Theory Control theory is based on linear system theory. The types of systems modeled in control theory are continuous systems. Therefore, a direct description using the systems approach is easily obtained. The system description is not presented in this section, but can be found in many books [Wym77, Zei86, Dor86], What is of interest is the cause-effect relationship embodied in control theory. Although classical control theory does not include these relationships directly, other methods, such as bond graphs [Tho75], have shown that the cause-effect relationship plays a role in the designerâ€™s conception of the system. 45 R /V'N/ G = 1/(RCs) Vo t 1 V; (a) (b) Figure 3.5 (a) Low Pass Circuit (b) Block Diagram Typically, linear systems are described with the aid of block diagrams. Figure 3.5 exemplifies the cause-effect relationship of a low pass RC circuit (integrating circuit). Using Control theory, the transfer function V0(s) / VÂ¡(s) can be obtained. The input voltage vÂ¡(t) and the output voltage v0(t) are Vj(t) = i(t)R + 1/C | i(t) dt and v0(t) = 1/C Ji(t) dt. The Laplace transforms are Vj(s) = I(s)R + l/(Cs) I(s) and VG(s) = l/(Cs) I(s). Solving for I(s) in the equation for V0(s) and substituting into the equation for VÂ¡(s), the transfer function is V0(s)/ V j(s)= l/(RCs+ 1). The transfer function in the form of a block diagram is shown in Figure 3.5. The block G is an integrating block. The diagram indicates the qualitative functioning of the circuit. At time t, the feedback of the output voltage is subtracted with the input voltage and then integrated to yield the output voltage at time t+dt. If the input voltage is constant, then it is easily deduced that the 46 output voltage becomes constant after some finite time. This is exactly what a low pass circuit does under constant voltage. The qualitative cause-effect relationship was deduced in a domain independent manner. This type of reasoning is the focus of both AI research [Bob86] and knowledge-based simulation [Fis9lb]. The state of the low pass circuit in classical systems theory could be represented by the tuple (vi(t),v0(t)). Intuitively, however, there are two states of the circuit when the input voltage is constant: the transient state (when the capacitor is charging) and the steady state. Control theory does not encompass this abstract notion of state. However, the block diagramâ€™s graph indicates indirectly the existence of these states. Although control theory has a simple description in systems theory, integrating continuous formalisms with discrete formalisms requires resolving the time base. There are only two possible resolutions: discretize the continuous system or assign time values to the discrete system. A linear system is an important concept in control theory. In Petri nets and state machines linearity is not discussed (at least not in the literature found to this date). A linear system exhibits two essential properties: superposition and homogeneity. Given a system that with input x(t) produces output y(t) and with input w(t) produces output z(t), if input x(t) + w(t) produces output y(t) + w(t), then the system has the superposition property. If input Bx(t) produces output By(t), where B is a constant, then the system lias the property of homogeneity. Control theory, along with the other four formalisms presented in this chapter, all have a system theoretic description. In the next chapter, a theory will be introduced which provides the foundation for a consistent and cohesive mechanism to describe these formalisms and will permit them to be used in a hierarchical organization. CHAPTER 4 HYBRID MODEL THEORY Model Structure Hybrid model theory is a combination of general system theory (GST), named sets, and graph theory. The combination of GST and named sets is also used in multifaceted modeling [Zei84]. In a sense, one could argue that hybrid model theory is a derivation of GST. Mathematically, this may be correct. However, there are significant differences of which those familiar with GST should be aware. TÃrese differences arose from the requirements needed for HH modeling . First, hybrid model theory is not to be used by the investigator. It is not a modeling formalism. It is a generalized formalism that is not as conceptually efficient as formalisms such as Petri nets, queuing networks, and block diagrams. Second, although building bottom-up is possible, hybrid model theory emphasizes a top-down approach to constructing a model. The idea behind hybrid model theory is to take a model which is partially correct in describing a systemâ€™s behavior and refine only those components which do not correspond with observed data or system specifications. Third, hybrid model theory focuses on the analysis of a single system under development. HH modeling and hybrid model theory are meant to provide the foundation for a computer environment which allows for the creation and investigation of system models, not the classification, identification, comparison and retrieval of already constructed and understood system models. Hybrid model theory deals with the alteration and investigation of incomplete or incorrect models. With this in mind, the definition of a model in hybrid model theory is introduced. A model M is a named set such that M = 47 48 H :Component A : Edge Â«Xj, dj, ...> X:Input Â¥ : Output 0 : State <...> x : Time Domain <(T,+ ,<), zero, delta, map[], magnitude[]> P : Initialize function (T,C,Q) -> 0 5 : Transition function (T,C,Q) -> 0 X : Output Function (T,C,Q) -> \\i. The symbols < and > indicate the use of named sets, and elements in these sets can be accessed as described in Chapter 2. The component set (H) of a model always has the special symbol self as a member. This symbol is used to indicate a reference to a submodel (if one exists). For most atomic models the self symbol is the only member of the component set. In structured models, the component set contains the models which are supervised by the controller model. The edge set (A) of an atomic model is empty. In structured models, the connectivity between component models is identified with the edge set. An edge a e A is a named set of the form t (undefined), a standard data type (9t, 3) or a model. Together, the components and edges describe the graph of the model and either what type of data is passed between the components or how control is transferred among the components. In Chapter 2, a brief description of intermodel coordination (coupling) was represented in hybrid model theory. From the definition above, it can be seen that a structured model, which has components that are also structured models, represents intermodel coordination. The root model is a group controller model. It controls the parallel operation of structured models. In intramodel coordination, a structured model coordinates atomic models. The distinction between inter and intramodel coordination appears to be just conceptual; however, the structured models that 49 coordinate the atomic models (state, parallel, and selective controllers) have a very different form and semantics from the group controller that coordinates a set of structured models. It is the distinct form of controllers that allows heterogeneous refinement. The input (X) and output 0?) also have the form or control information used by different types of models. For models in which the input has not yet been specified, the from model will be equal to t (undefined). The same definition also applies for a modelâ€™s output. The only difference between inputs and outputs are that inputs are signals (functions over time) and outputs are values. The state (0) named set is used for a variety of purposes. It is very similar to local memory in computational definitions. It can contain any other type of named set (including a model). However, for analytical purposes, the state set should contain only constants or functions of time. The time domain of a model was discussed in Chapter 2. It is only noted here that the time domain of a model can be null. However, it is intended that models which do not have the notion of time in the clock sense include notions of time in the computational sense. That is, if a model is not measured in seconds, but has a definite sequence of computation, then the model should use an integer time domain. Each integer X+l represents the next computational step. The last three elements of a model are functions. Typically, these are used to compute the new state and output trajectories over a time interval. Because hybrid model theory is centered around simulation concepts, these functions have been conceptually altered. It is assumed that all three functions use two times: the current time (a global variable) and an input time (given at function invocation). These times are used to calculate the state or output at the input time. The current input and state are also assumed to be part of the input to these functions. Trajectories are created by symbolic methods which take a model as input or created through numerical techniques. Additionally, it should be emphasized that these functions are declared, not precompiled. When numerical analysis (simulation) is needed, the declarative model can be compiled and optimized (unless an interpretative language like LISP or an object-oriented language is used). 50 The initialization function (P) is necessary since models can be dynamic. At any time during analysis, a model can become active. This not only allows for the modeling of systems which may lie dormant, but more importantly, it models systems which have multiple descriptions over time. A piecewise continuous system is an example of a primitive multidescription system. In this work, the state oriented formalisms implement the piecewise concept. For data flow models (differential equation models), the initialization function (P) sets the initial conditions. The transition (8) function is intended to be used when a model is active. Although, as can be seen from the description, it could be used to initialize a model. The initialization and transition functions were derived so that the concept of state, transition and initialization could be separated. Again, this is necessary in symbolic and interpretation methods. If the transition function uses stochastic or nondeterministic relationships, then mathematically the term function is incorrect; however, for purposes of this discussion, the term function will be used in a similar manner to that used in programming languages. For the same reason (and tradition), the output function (A.) is also kept separate from the other functions. One of the optimizations for numerical analysis is the integration of these functions so that only one call to the model produces the total behavior. This integration is possible in hybrid model theory because there are only four controller models and each type of controller has the same form of transition and output functions. Controller Model Supermodel Component Models 1= V I I I I Component Models Ã Y â–¡ â–¡ Controller Model submodel Figure 8 Signal Flow in Intramodel Coordination 51 There are two rules which capture the manner in which atomic components of a structured model can be coordinated with other models (intramodel coordination). This is a pseudo formal definition of intramodel coordination in hybrid model theory. Figure 8 shows how the coordination is accomplished. The rules can be stated as follows. 1. A component (node) in a model can have its operationâ€™s output delayed or altered by another model called the submodel. The component model, when activated, initializes the submodel and waits for a signal of completion, which then deactivates the submodel. 2. A component (node) in a model can have its operation replaced by another model; however, the I/O and control of the submodel must be the same, the model is continuous over the analysis. The types of controllers which interact with each other dictate which of these rules applies when submodeling. The higher level model in submodeling is called a supermodel. Like most model formalisms, the arrows in Figure 8 signify control and data flow between model types. The rule which applies depends only on the supermodel involved. For instance, if the supermodel is a state controller, then rule 1 above applies, for a parallel supermodel only rule 2 applies and for a selection supermodel rule 1 applies. State Modeling A state controller model manages a finite set of components. The edges represent control flow between the components. The state controller model is responsible for the input and output to the current state model. A state model represents the individual components. For example, in a Markov system, the state controller is the controller model and the state models are the component models of the controller model. The components of a Markov system do not use input. 52 However, each Markov state can supply an output at any given time as described in Chapter 3. The input to a Markov state is only used by the submodel (if one exists). A state machine can be represented in the same manner as a Markov system. The only difference is in the internal state of the state models. Hence, in order to describe state formalisms, three models are needed: two atomic models and one structured model. Specifically, these are a finite state atomic model, a Markov state atomic model and the state controller structured model. The atomic models are defined first; then, the state controller is defined. A finite state atomic model is defined as H .'Component A : Edge 0 X:Input 0 : State |