1            MODELING AND SIMULATION FRAMEWORK 

This article briefly reviews the  Modeling and Simulation Framework   as presented in Chapters 1 and 2 of Theory of Modeling and Simulation (Zeigler et al. 2018), hereafter TMS 2018.

1.1           System concepts

The Modeling and Simulation Framework (MSF),  reviewed here, includes  “system” as one of the four basic entities along with “experimental frame”, “model” and “simulator”.  We start with some basic concepts about systems that are briefly outlined here.

1.2           System Specification Hierarchy Levels of System Specification 

The MSF sets forth the fundamental entities and relationships in the M&S enterprise. To describe these items we employ the systems specification hierarchy as the basis for the MSF.  Table 1 identifies five basic levels of system specification forming a Systems Specification Hierarchy. The fourth column gives an example of a system specification at each level applied to a person in a conversation. Later we will formulate a conversation, itself, as system composed of two interacting persons.  At each level we know some important things about a system that we didn’t know at lower levels. At the lowest level, the source level identifies a portion of the real world that we wish to model and the means by which we are going to observe it. As the next level, the data level is a data base of measurements and observations made for the source system. When we get to Level 2, we have the ability to recreate this data using a more compact representation, such as a formula. Since typically, there are many formulas or other means to generate the same data, the generative level, or particular means or formula we have settled on, constitutes knowledge we didn’t have at the data system level. When people talk about models in the context of simulation studies they are usually referring to the concepts identified at this level. That is, to them a model means a program to generate data. At the last level, the structure level, we have a very specific kind of generative system. In other words, we know how to generate the data observed at Level 1 in a more specific manner in terms of component systems that are interconnected together and whose interaction accounts for the observations made. When people talk about systems, they are often referring to this level of knowledge. They think of reality as being made up of interacting parts so that the whole is the sum (or a sometimes claimed, more, or less, than the sum) of its parts. Although some people use the term ‘subsystems’ for these parts, we call them component systems (and reserve the term subsystem for another meaning).

 The System Specification Hierarchy is a useful starting point since it provides a unified perspective on what are usually considered to be distinct concepts. From this perspective, there are only three basic kinds of problems dealing with systems and they involve moving between the levels of system knowledge.  In systems analysis, we are trying to understand the behavior of an existing or hypothetical system based on its known structure. Systems inference is done when we don’t know what this structure is – so we try to guess this structure from observations that we can make. Finally, in systems design, we are investigating the alternative structures for a completely new system or the redesign of an existing one.

Table 1 Levels of System Specification.

1.3           The Entities and Relations of the Modeling and Simulation Framework

As illustrated in Figure 1, the basic entities of the framework are: source system, model, simulator and experimental frame. The basic inter-relationships among entities are the modeling and the simulation relationships. The entities are defined in Table 2 which also characterizes the level of system specification that typically describes the entities. The level of specification is an important feature for distinguishing between the entities, which is often confounded in the literature. You can return to Figure 1 and Table 2 to keep an overall view of the framework as we describe each of the components in the following presentation.

Figure 1.  Fundamental Entities and Relationships in the M&S Framework.

1.3.1   Source System

The source system (we will omit the ‘source’ qualifier, when the context is clear) is the real or virtual environment that we are interested in modeling. It is viewed as a source of observable data, in the form of time-indexed trajectories of variables. The data that has been gathered from observing or otherwise experimenting with a system is called the system behavior database. As indicated in Table 2 2, this concept of system is a specification at level 0 and its database is a specification at level 1. This data is viewed or acquired through experimental frames of interest to the modeler.

Table 2 Defining the Basic Entities  in M&S and their usual Levels of Specification 

1.3.2   Experimental Frame

An experimental frame is a specification of the conditions under which the system is observed or experimented with. As such an experimental frame is the operational formulation of the objectives that motivate a modeling and simulation project. For example, out of the multitude of variables that relate to a forest, the set {lightning, rain, wind, smoke} represents one particular choice. Such an experimental frame is motivated by the interest in modeling the way lightning ignites a forest fire. A more refined experimental frame would add the moisture content of the vegetation and the amount of unburned material as variables. Thus, many experimental frames can be formulated for the same system (both source system and model) and the same experimental frame may apply to many systems. Why would we want to define many frames for the same system? Or apply the same frame to many systems?  For the same reason that we might have different objectives in modeling the same system, or have the same objective in modeling different systems. More of this in a moment.

 There are two equally valid views of an experimental frame. One, views a frame as a definition of the type of data elements that will go into the database. The second views a frame as a system that interacts with the system of interest to obtain the data of interest under specified conditions. In this view, the frame is characterized by its implementation as a measurement system or observer.  In this implementation, a frame typically has three types of components (as shown in Figure 2): generator that generates input segments to the system; acceptor that monitors an experiment to see the desired experimental conditions are met; and transducer that observes and analyzes the system output segments. 

Figure 2 Experimental Frame and its Components.

1.3.3   Objectives and Experimental Frames

Objectives for modeling relate to the role of the model in systems design, management or control. The statement of objectives serves to focus model construction on particular issues. See TMS2018 Chapter 2 for discussion  of a process for transforming objectives into experimental frames. 

1.3.4   Example: Two Person Interaction

The conversation example for the System Specification Hierarchy of Table 1 actually assumes an underlying experimental frame that was not completely specified.  We can specify the objective of trying to characterize when a two person interaction is a valid conversation, i.e., when the participants exchange words that make sense to an observer.  We restrict the interaction to an exchange of greetings of two people passing by each other. There are relatively few pairs of words that make sense such as “Hello, Hi” as a greeting by one person and a response of the other, whereas most other pairs of words do not. Such pairs are in effect a description at the I/O Behavior level for the interaction of two persons. An experimental frame in this case centers on collecting such I/O pairs in both a real two-person encounter and a simulation model of it. The acceptor component of such a frame can monitor the interaction for pairs judged to be indicative of a valid conversation.

1.3.5   Model  

In its most general guise, a model is a system specification at any of the levels of the System Specification Hierarchy. However, in the traditional context of M&S, the system specification is usually done at levels 3 and 4.  Thus the most common concept of a simulation model is that it is a set of instructions, rules, equations, or constraints for generating I/O behavior. In other words, we write a model with a state transition and output generation mechanisms (level 3) to accept input trajectories and generate output trajectories depending on its initial state setting.  Such models form the basic components in more complex models that are constructed by coupling them together to form a level 4 specification.

1.3.6   Example (Continued): Two Person Interaction

An example of a conversation between two persons can be modeled as agents interacting through exchange of messages carried by discrete events. This constitutes a coupled model with atomic model components. Each component alternates between speaking and listening phases. If moreover, the components adhere to the discipline that only one is in the speaking phase at any time, then the result represents a valid conversation. If at any time, both components are in the same phase (speaking or listening) then the experimental frame acceptor just discussed will stop the simulation and declare this as an invalid conversation.

 There are many meanings that are ascribed to the word “model”.  For example, a model is conceived as any physical, mathematical, or logical representation of a system, entity, phenomenon, or process. The definition in terms of system specifications has the advantages that it has a sound mathematical foundation and is has a definite semantics that everyone can understand in unambiguous fashion. Like other formal definitions, it cannot capture all meanings in the dictionary.  However, it is intended to capture the most useful concepts in the M&S context. 

1.3.7   Simulator

As a set of instructions, a model needs some agent capable of actually obeying the instructions and generating behavior. We call such an agent a simulator.  Thus, a simulator is any computation system (such as a single processor, a processor network, the human mind, or more abstractly an algorithm), capable of executing a model to generate its behavior.  A simulator is typically specified at a high level since it is a system that we design intentionally to be synthesized from components that are off-the-shelf and wellunderstood. Separating the model and simulator concepts provides a number of benefits for the framework:

• The same model, expressed in a formalism, may be executed by different simulators thus opening the way for portability and interoperability at a high level of abstraction.
• Simulator algorithms for the various formalisms may be formulated and their correctness rigorously established.
• The resources required to correctly simulate a model afford a measure of its complexity.

1.3.8   Example Continued: Two Person Interaction

The two-person discrete event model just mentioned can be formulated within the Discrete Event System Specification (DEVS) formalism as illustrated in Chapter 10 of  TMS 2018. This then allows the model behavior to be generated by a DEVS simulator, i.e., a simulation program implementing the rules of the Abstract DEVS simulation protocol that guarantees correct simulation of any DEVS model.

Table 3 Primary Relationships among Entities.

2            PRIMARY RELATIONS AMONG ENTITIES

The entities - system, experimental frame, model, and simulator – become truly significant only when properly related to each other.  For example, we build a model of a particular system for some objective - only some models, and not others, are suitable. Thus, it is critical to the success of a simulation modeling effort that certain relationships hold. The two most fundamental are the modeling and the simulation relations (Table 3) 

2.1           Modeling Relation: Validity

The basic modeling relation, validity, refers to the relation between a model, a system and an experimental frame. Validity is often thought of as the degree to which a model faithfully represents its system counterpart. However, it makes much more practical sense to require that the model faithfully captures the system behavior only to the extent demanded by the objectives of the simulation study. In the MSF, the concept of validity answers the question of whether it is impossible to distinguish the model and system in the experimental frame of interest. The most basic concept, replicative validity, is affirmed if, for all the experiments possible within the experimental frame, the behavior of the model and system agree within acceptable tolerance. Thus replicative validity requires that the model and system agree at the I/O relation level 1 of the system specification hierarchy.  

Stronger forms of validity are predictive validity and structural validity. In predictive validity we require not only replicative validity, but also the ability to predict as yet unseen system behavior. To do this the model needs to be set in a state corresponding to that of the system. Thus predictive validity requires agreement at the next level of the system hierarchy, that of the I/O function level 2. Finally, structural validity requires agreement at level 3 (state transition) or higher (coupled component). This means that the model not only is capable of replicating the data observed from the system but also mimics in step-by-step, component-by-component fashion, the way that the system does its transitions. 

The term accuracy is often used in place of validity. Another term fidelity, is often used for a combination of both validity and detail. Thus, a high fidelity model may refer to a model that is both high in detail and in validity (in some understood experimental frame).  However when used this way, beware that there may be a tacit  assumption that high detail alone is needed for high fidelity, as if validity is a necessary consequence of high detail. In fact, it is possible to have a very detailed model that is nevertheless very much in error, simply because some of the highly resolved components function in a different manner than their real system counterparts. 

2.2           Simulation Relation: Simulator Correctness

The basic simulation relation, simulator correctness, is a relation between a simulator and a model. A simulator correctly simulates a model if it is guaranteed to faithfully generate the model’s output trajectory given its initial state and its input trajectory. Thus, simulator correctness requires agreement at the I/O function level 2.  In practice, simulators are constructed to execute not just one model but a family of possible models. This flexibility is necessary if the simulator is to be applicable to a range of applications. In such cases, we must establish that a simulator will correctly execute a particular class of models. Since the structures of both the simulator and the model are at hand, it may be possible to prove correctness by showing that a homomorphism relation holds. Here a homomorphism is a correspondence between simulator and model states that is preserved under transitions and outputs.

2.3           Modeling as Valid Simplification

The inescapable fact about modeling is that it is severely constrained by complexity limitations. Complexity, is at heart, an intuitive concept  the feeling of frustration or awe that we all sense when things get too numerous, diverse, or intricately related to discern a pattern, to see all at once  in a word, to comprehend.  Generalizing from the boggled human mind to the overstressed simulator suggests that the complexity of model can be measured by the resources required by a particular simulator to correctly interpret it. As such, complexity is measured relative to a particular simulator, or class of simulators. However, properties intrinsic to the model are often strongly correlated with complexity independently of the underlying simulator. Successful modeling can then be seen as valid simplification. We need to simplify, or reduce the complexity, to enable our models to be executed on our resource-limited simulators. But the simplified model must also be valid, at some level, and within some experimental frame of interest.  Note tat there is always a pair of models involved, call them the base and lumped models. Here, the base model is typically “more capable” and requires more resources for interpretation than the lumped model. By the term “more capable”, we mean that the base model is valid within a larger set of experimental frames (with respect to a real system) than the lumped model. However, the important point is that within a particular frame of interest the lumped model might be just as valid as the base model.  The concept of morphism affords criteria for judging the equivalence of base and lumped models with respect to an experimental frame.