Download System Entity Structure and Model Base: Organizing Models for Simulation and Design and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!
SYSTEM ENTITY STRUCTURE IN DEVS
Simulation-based systems design employs a plan-generate-evaluate process. The plan phase organizes all the models of design alternatives within the chosen system boundary and design objectives. The generate phase synthesizes a candidate design model intended to meet the set of design objectives. Finally, the evaluate phase evaluates behavior and/or performance of the generated model through simulation using an appropriate experimental frame derived from the design objectives. The overall design cycle repeats the generation and evaluation phases until an acceptable design is found. How can we organize a family of models from which a candidate model can be selected, generated and evaluated? This chapter presents the systems entity structure/model base (SES/MB) framework for such an organization. The idea is as follows. Let us first extract the hierarchical composition structures of hierarchical, modular models from their implementations. Then we save the structures and the implementations separately in organized libraries. shows the basic idea in which libraries for model structures and model implementations are called system entity structure base and model base , respectively. Our goal is to be able to synthesize a simulation model by traversing a model hierarchical structure, retrieving component implementations and coupling them together. As will be seen later in this chapter, a system entity structure represents not a single model structure, but a family of model structures, from which a candidate structure called a pruned entity structure can be selected. Thus, the system-entity-structure/model-base framework supports the plan-generate-evaluate process in systems design. ENTITY STRUCTURE BASE MODEL BASE ABC AB C C1 C AB A B A B C1 C ABC AB C Specification Synthesis structure components
C C
B A < X ,Y,S ext,^ int,^ ,^ ta > structure components Separate Figure 1 System Entity Structure/Model Base Concept
Model Base Management By System Entity Structure
A model base is an organized library of models that may be either atomic or coupled. Models can be saved in the model base for later retrieval. Models so retrieved may be reused to create more complex models. Thus, the model base approach will improve the productivity of the modeling subtask in the overall systems design process. Figure 1 shows an approach to model base management that relies on the concept of system entity structure to be explained in the next section. The behaviors of primitive components of a real world system are specified by atomic models and saved in the model base (Figure 1 (a)). The structural knowledge of the system is represented as a system entity structure (Figure 1 (b)) by means of an operation called entity
structuring. The entity structure, here, serves as a compact representation for organizing all possible hierarchical composition structures of the system. This separation of model composition structures from their behaviors may reduce the modeling complexity of real world systems. Moreover, such separation allows designers to easily construct candidate models with different structures while using the same components. To construct a desired simulation model to meet design objectives, the pruning operation is used to reduce the SES to a pruned entity structure, PES (Figure 1 (c)). This pruned entity structure can be transformed into a composition tree ( (d)), and eventually synthesized into a simulation model ( (e)) by combining it with models in the model base. Such models are evaluated via simulation to determine superior solutions to the design objectives.
System Entity Structure
The system entity structure formalism is a structural knowledge representation scheme that systematically organizes a family of possible structures of a system. Such a family characterizes decomposition, coupling, and taxonomic relationships among entities. An entity represents a real world object. The decomposition of an entity concerns how it may be broken down into sub-entities. As discussed earlier. coupling specifications tell how sub-entities may be coupled together to reconstitute the entity. The taxonomic relationship concerns admissible variants of an entity. As shown in Figure 3, an SES is represented as a labeled tree with attached attributes that satisfies the following axioms: (1.) alternating entity/aspect or entity/specialization : Each node has a mode that is either entity/aspect or entity/specialization such that a node and its successors are always opposite modes; the mode of the root is entity. (2.) uniformity : Any two nodes with the same names have identical attached variable types and isomorphic sub-trees. (3.) strict hierarchy : No label appears more than once down any path of the tree. (4.) valid brothers : No two brothers have the same label. (5.) attached variables : No two variable types attached to the same item have the same name. There are three types of nodes in the tree. An entity node, e.g., A in Figure 3, represents a real world object. There are two types of entity, namely composite entity and atomic entity. A composite entity is defined in terms of other entities (which may be either atomic or composite), while an atomic entity can not broken down into sub-entities. Each entity may have attached variables. It may also have several aspects and/or specializations. An aspect node, like A-dec in Figure 3, is connected by a single vertical line from a composite entity. It represents one decomposition of the entity. The children of the aspect are entities, distinct components of the decomposition. Associated with each aspect is a coupling specification. A specialization node, e.g., B-spec in , is connected by a double vertical line from an entity. It defines the taxonomy of the entity, and represents the way in which the entity can be categorized into specialized entities. Selection rules may be associated with each specialization, and guide the way in which a specialized entity is selected in the pruning process. A selection constraint , depicted as dotted arrow from an entity to other entities in Figure 3, means that not all entities may be selected independently. Once a specialized entity is chosen from a specialization, some specialized entities in other specializations associated with the specialization are also selected. The dotted arrows from B1 to D1 and G1 in enforces the following selection constraints: “if entity B1 is selected from specialization B-spec then select entity D from specialization D-spec and entity G1 from specialization G-spec .”
Figure 3 A System Entity Structure
System Entity-Structure/Model-Base (SES/MB) Framework
As we explained in a previous section, the SES/MB framework is a powerful means to support the plan- generate-evaluate paradigm in systems design. Within the framework, entity structures organize models in model base. Thus, modeling activity within the framework consists of three sub-activities: specification of model composition structure, specification of model behavior, and synthesis of a simulation model. shows a modeling and simulation methodology based on the framework in the process of iterative systems design. In the figure, the generation phase consists of two sub-phases: pruning and model synthesis. The structure specification and/or the behavior specification may already exist in the entity structure base and/or model base. However, if the structure specification is not in the entity structure base, we need to specify it by building a System Entity Structure which represents a family of possible model structures. Likewise, if the desired model components are not in the model base, we need to develop them and store them in the model base for later use.. In the pruning phase, we select a sub-structure by pruning the SES with respect to design objectives. A simulation model is automatically synthesized from such a pruned entity structure. Simulation experiments may require changes of structure and/or behavior of the design model. The pruning-synthesis-evaluation process is repeated until a desired design is found. Once simulation experiments are completed, the designer can save structure and behavior specifications in the system entity structure base and the model base, respectively for later use. Start Design model structure in Entity Structure? Design model behavior in Specify all^ Model Base? models structure Pruning by design objectives Completed? Specify all models behavior Completed? Design evaluation by simulation Design model synthesis no yes no no no yes yes yes Find desired design? Structure change Behavior change yes End Figure 4 Design Methodology Using SES/MB Framework
Example: Design of a transaction processing system
Let us exemplify SES/MB framework with the design of a transaction processing system. As outlined in , the transaction manager, TM assigns transactions requested by users to transaction processes. Each transaction process, TP model represents a particular way of processing a transaction. Once assigned a transaction, it works on it until the transaction is completed or aborted. CPU and DISKS are resources that
Figure 6 SES for TPS and its experimental frame.
Model Base
As shown in Figure 6a), the model base is an organized library for component models in modular form. Such component models can be either atomic or coupled models specified in the DEVS formalism. Since the entity structure of manages the component models in the model base, there is a correspondence between entity names and model names. A simple correspondence is that names of node entities are identical to names of the corresponding models in the model base. In this case, names of atomic models in the model base are labels of leaf nodes of type entity in the SES. Care must be taken with coupled models, if any, in the model base, since they represent already pruned structures. Thus, the name of a coupled model also labels a corresponding entity in the SES that has children nodes of aspect type but there is no specialization type on any path from the node down to the leaves.
Pruning and model synthesis
Once the TPS_EXP entity structure has been constructed, a designer can explore alternative transaction processing architectures using the pruning operation. Many alternatives may be extracted from the SES. Among the alternatives, the most interesting ones arise from the CC and TP specializations. Consider the following design objective: “Find an optimal number of transaction processes and a best concurrency control algorithm which give both high throughput and low response time.” The design objective requires us to construct several kind of simulation models: each with different algorithm for concurrency control and with different number of transaction processes. The number of transaction processes puts a limit on the number of transactions allowed to be active at any time. Table 1
shows an example of the pruning choices consistent with the design objective. It selects the TP8 for the TP specialization, the Lock for the CC specialization, and so on. Entity Selection Input TP tp-spec? TP CC cc-spec? Lock Proc proc-spec? Hproc Buff buff-spec? FIFO DISKS aspect? disks-dec GENR genr-spec? HGENR Table 1 Pruning Specification A configuration expert who constructed the TPS entity structure may also provide some facilities to help users generate good alternatives by constraining the pruning process as mentioned earlier. Figure 7 shows an example pruned entity structure. A simulation model can be synthesized by retrieving component models from the model base, which correspond to entities in the PES from the model base. Figure 8 shows the synthesized model TPS_EXP from PES of Figure 7. Figure 7 TPS Pruned Entity Structure.
N1 (^) Number of alternatives Multi NCounters Counter N2 = S1 + S2 + S N E-dec S1 S2 S Entity E E1 (^) E2 E E2-Spec Figure 9 Enumerating SES Prunings Recall that an SES is built recursively with alternating specializations and decompositions. Likewise, the number of alternative prunings can be enumerated and generated recursively. An nCounter is used to iterate through the number of alternatives (n) at each specialization. A multicounter, which is a serial composition (Chapter 5) of nCounters, iterates through all alternatives under a decomposition by stepping its component nCounters through these alternatives one at a time. The number of alternatives under a decomposition is the product of the alternatives under its entities. For example, there are nCounters for each of the subtrees under E1, E2 and E3 under E-dec in Figure 9. The multicounter under E-dec cycles through a total of N1N2N3 alternatives. The number of alternatives under a specialization is the sum of those under its entities. For example, the number under E2-spec in Figure 9 is S1+S2+S3. This recursion stops when leaf entities are encountered. The number of alternatives represented by a leaf entity is just 1 (itself). Finally, the number of prunings of the SES is the number of alternatives under the root node. Exercise. Recall the design the nCounter as a parameterized atomic model. Design the multicounter as parameterized coupled model with nCounter components. Write the formal algorithm that assigns nCounters and multicounters to nodes in the SES. Design an iteration control that steps the root nCounter through its cycle thereby stepping each of the
