- BATSG1 Simulator v5.2021
- Learning from People
- UX Forms
- UX Address Book Form
- UX Data Element Specification
- UX Element Specification
- UX Event Form
- UX Flow In Sources and Causes
- UX Flow Out Effects
- UX GDPR Release Form
- UX Interaction Form
- UX KT Adverse Consequences
- UX KT Decision Analysis
- UX KT Potential Problem Analysis
- UX KT Problem Analysis
- UX Persona Specification
- UX TAG Worksheet
- UX Viewpoint Form
- UX WISDM Specification
- ITIL PoO
SARL Architected Futures™ 2021-10-27 02:10
- 1 Background
- 2 Overview
- 2.1 Discussion
- 2.2 Concept
- 2.3 Features
- 2.4 Options
- 2.5 Elements
- 2.6 Operational Factors
- 2.6.1 Operating Mode
- 2.6.2 System Generated Activities
- 2.6.3 Time Functions
- 2.6.4 Event Prediction
- 2.6.5 Simulation Operation 1
- 2.6.6 Simulation Operation 2
- 3 Analysis
- 3.1 Event Logic
- 3.2 Analysis Classes
- 3.2.1 Core Simulation Elements
- 188.8.131.52 Simulation Monitor
- 184.108.40.206 Run Control
- 220.127.116.11 Event Queue
- 18.104.22.168 Event
- 22.214.171.124 Activity Arc List
- 126.96.36.199 Activity (Arc)
- 188.8.131.52 Event Node List
- 184.108.40.206 Event (Node)
- 220.127.116.11 Entity List
- 18.104.22.168 Entity
- 22.214.171.124 Resource Set
- 126.96.36.199 Resource
- 188.8.131.52 Cycle Set
- 184.108.40.206 Cycle
- 220.127.116.11 Flow List
- 18.104.22.168 Flow
- 22.214.171.124 Storage List
- 126.96.36.199 Storage
- 3.2.1 Core Simulation Elements
- 4 Design
- 4.1 Architecture
- 4.2 Conceptual Solution
- 4.2.1 HLA Mapping
- 4.2.2 Process Model
- 4.2.3 Simulated System Representation
- 4.2.4 Model Execution
- 4.3 Technical Solution
- 4.3.1 Feature Sets
- 4.3.2 Operational Overview
- 4.3.3 Publish / Subscribe
- 4.3.4 Message Patterns
- 4.3.5 Simulation Client
- 4.3.6 Simulation Facility
- 4.3.7 Extension Hierarchy
- 5 System Dynamics
- 6 Modeling Platforms
- 6.1 Insight Maker
- 6.1.1 Samples
- 6.1.2 Agent-Based Modeling
- 6.1.3 Calculations
- 6.1.4 Extensions
- 6.1.5 Like this:
- 6.1 Insight Maker
Extended and enhanced from: AF EATSv4.2016.0912 Simulation Facility
12-Sep-16 EATS Simulation Facility Page 1
af_eats_simulator_2011_07_22.docx Rev: 245 Copyright © 2017 Joe Van Steen
Bugs C# 17
Single Value 27
Queue Wait 27
Cycle Events 27
Event Logic 31
Run Control 32
Event Queue 32
Event (Node) 35
Entity List 36
Resource Set 37
Cycle Set 37
Flow List 38
Storage List 40
HLA Mapping 46
Feature Sets 61
Use Case 70
The AF EATS Simulator is a trial implementation of a Monte Carlo simulation modeling facility for the Architected Futures™ Tool Suite. It is an extension of the BATSG1 simulator designed by Dr. R. C. Wentworth of Bechtel and taught in a class at Golden Gate University in 1978. The simulator provides facilities for Monte Carlo simulation of activities and flows and supports user extensible logic.
The general idea is to use the elements and relationships in an AIR repository as the foundation elements and specifications for the simulation model. The simulation model at the same time becomes a part of the design specification of the relationship of the elements, and the product of running one or more simulations becomes (a) part of the management product of the system, and (b) part of the “generated data” content within the encyclopedia – able to be harvested and used in other analyses.
One use of this facility might be to do things like traffic and design flows to judge the efficiency of an architected system. But another use might be to use the system and simulator for things like large scale socio-economic simulations.
The benefit of using the EATS Infrastructure as a platform is that it defines a distributed, object and service oriented, message-based, document-centric execution environment.
- Distributed – while it is possible to configure the system to execute on a single node as a single runtime program, the system is designed to facilitate operation over a distributed network of computers.
- Object and Service Oriented – EATS is designed to operate using a cascading concept of service provider objects which respond to standardized requests for services.
- Message Based – All requests for services are made using an asynchronous message passing protocol, and all responses to those requests are delivered in the form of a message. All messages are assumed to potentially incur some processing delay and may involve communication with a remote service provider.
- Document Centric – Information management within the system is based on a standardized, architected document format. This is true for messages passed between requesters and service providers, it is true for data persistence and for state management.
The benefit of using the AIR repository as platform
- Consistency of specifications across multiple viewpoints – the same specification objects used to document the system for other purposes are the specification objects used to drive the simulation
- Assurance that all known impacts are accounted for (even if only because they are consciously ignored)
- Ability to interface multiple models serially or dynamically (use of different models as sub- and super-systems, use of “factories,” use of model output products as input products for other models and analyses
The benefit of creating a simulation system similar to what is envisioned is the ability to perform modeling on a distributed basis similar to the analysis of radio data in the SETI search. In a normal algorithm driven environment there is a a minimal time delay and complexity associated with “linkage” from entity-function-event computation to entity-function-event computation, and minimal access time delay for access to stored data resources. However, all data needs to be on or accessible by pretty much one machine, and all entity-function-event computations happen on a single machine. With our distributed approach, there is a significant computation to computation delay incurred due to the messaging structure of the system. However, there is a reasonable maximum peak to this delay, and then it becomes an overhead constant added to the time for each computational unit. But the computational units are able to be distributed, and assuming the problem set allows, operated in parallel. Furthermore, special machine environments may be allocated to special parts of the simulation. One multi-core machine with high performance may be used for compute intensive tasks, and another machine (environment) in the network may be used for data intensive tasks, such as data mining, which may be required to determine the next operational result for another component of the model.
Current (August 2016) thinking about the EATS Simulation Facility incorporate, but extend well beyond, the implementation of a new, embedded BATSG1 simulator.
Our desire is to implement an extensible simulator that can manage simultaneous multi-technology, multi-perspective simulations at arbitrary scales. EATS is a tool-set to help architects, engineers and related stakeholders develop, manage and communicate the conceptual frameworks and information sets involved in the envisioning, documentation, analysis and maintenance of complex systems. Simulation can potentially play a role in all of these tasks. It is a tool to help understand and analyze issues, impacts, behaviors and interactions based on hypothetical design schemes when envisioning new systems or making modifications to existing systems. The AIR Repository defines the static specification for the system of interest. The simulator animates that specification and allows it to be viewed and analyzed as a dynamic entity.
A core concept of the EATS design when looking at the specification of systems is to be able to view them from multiple viewpoints and to be able to document and understand the relationships between those views. This same philosophy holds in terms of the simulation facility. Systems can be modeled using a multitude of techniques, depending on the characteristics of concern. Different technologies (e.g., discrete event models, agent-based models, system dynamics models, financial models, etc.) may be required depending on the viewpoint of the analyst or the critical characteristics of the system. We want to be able to accomplish the simultaneous evaluation of a dynamic system from the execution of a single run instance of a model using all techniques of modeling and analysis that may be appropriate for the analysis. We feel this will have enormous benefits to achieving multi-disciplinary consensus understanding of the behaviors of complex systems.
- Ability to include, or exclude, selected model components as a configuration option. For example: include (or exclude) financial accounting model as part of a process model; include (or exclude) a class of entities from the model.
- Ability to “watch” the simulation from one or more views. This may constitute multiple “clients” on different machines witnessing, or participating in, the same simulation; or it may also involve multiple “windows” (panels?) on the same machine which focus on different aspects of the simulation (overview, detail of a process, or process group, etc.).
- Ability to script, and replay, selected event sets for the simulation (action A on entity B at time C). This allows certain stable environmental inputs to see how changes in model behavior adapt to the same situation.
- What we are trying to do, seems to have a “commercial comparison” product in AnyLogic 7. Simulation is any combination of:
- System Dynamics
- Discrete Event Modeling
- Agent-based Modeling
- Simulation Modeling Facility is probably capable of being a “first user-face ‘tool-suite’ product” that can be presented as a useful tool to an analyst, who may not be a (semi-)professional programmer or systems engineer. It can be used as an application “use case” study for, presentation of, and introduction to EATS as a suite. This become a content-set for content to be published on af.net.
- How to use the modeling tools
- How to use models of various types that may be included in the AF_Content_Library
- How the infrastructure supports the application
- See Stella Professional 1. This is becoming a ‘standard’ of sorts. Concept correlation would be helpful for some stuff. (Stella Glossary)
- Node/Entity Types
- Conveyor – see Stella docs, a conveyor is a transport system that “conveys” things from “place-to-place.” Hypothetically, in our concept a conveyor would be the entity capable of underlying an activity arc which consumes time as the entities on that arc travel.
- Reservoir – The default type of stock. Think of a reservoir as a pool of water, or as an undifferentiated pile of “stuff”. A reservoir passively accumulates its inflows, minus its outflows. Any units that flow into a reservoir lose their individual identiy. Reservoirs mix together all units into an undifferentiated mass as they accumulate
- Oven – A type of stock. Think of an oven as a processor of discrete batches of stuff. The oven opens its doors, fills (either to capacity or until it is time to close the door), “bakes” its contents for a time (as defined by its outflow logic), and then unloads them in an instant. Examples of real-world ovens are bank tellers, a doctor’s office, and a car wash.
- Node/Entity Types
- When first seeing ‘oven’ my thought ran to ‘factories.’ Factories, as defined by me, are transformation entities which are capable of molding multiple items into synergistic assemblies such that the individual parts lose their discrete identity in the model and only remain discrete as component parts of the new assembly. Whether they remain discrete is discretionary. Reversing the transformation may or may not be possible. Some inputs may become lost in the process or assembly or disassembly (e.g., energy requirements).
- Interesting new modeling tool: NOVA
2/19/2012 – Running across some ideas lately, which caused me to think back a bit, and question whether or not there might also be a place (i.e., does it make sense) within the simulation and modeling environment of EATS to include some neural net processing? There seems to be some room for examination of that as a potential for expansion of the modeling processes.
- http://www.ai-junkie.com/ga/intro/gat2.html for an non-math backgrounder on genetic algorithms
- http://www.ai-junkie.com/ann/evolved/nnt1.html for a neural net tutorial
Then, see how that might integrate with a R. C. Wentworth modeling subsystem as part of EATS.
- What would neural nets add to the system
- How would they benefit from the AIR architecture and ontological model
- How would they help in explanation and prediction of systems
See C# (or Java?) Maze simulation. From AF_EATS2_YYY_MM_DD. This was not a vector based navigation problem, but rather a simple unit-of-time driven, “walled space” navigation problem, so the space navigation was different. It may or may not make sense to try to be able to do both types of navigation.
- Simulation Modeling of Space Missions Using the High Level Architecture
- Free HLA Tutorial and Software
- CMU HLA Project simulation of Wright Flyer
- http://gafferongames.com/ has an interesting set of “articles” online, including discussions of tradeoffs between techniques.
- Game Physics (including info on integration techniques)
- Game Networking
- Networked Physics
- Game of Go
- http://jmonkeyengine.org/ – open source Java game engine
Discrete Event Simulation, System Dynamics and Agent Based Simulation: Discussion and Comparison http://www.lancs.ac.uk/~maidston/Short%20Project1.pdf
- Driver Engines
- Need to review references, including new ones above, regarding “the modeling” loop. It seems we
mayneed at least two loops
- A loop based on the display cycle time – which keeps pace with the visualization element – this is probably the synchronization loop between the visual client and the internal state
- A loop based on predictive behavior – when will the next event of consequence happen
- One idea here is simply to have each “event predictor” predict its own next event. The only event of consequence to the overall model, and potentially the only event kept if the closest next event as predicted by all predictors. All others are tossed away, since all are hypothetical any of them may be impacted and changed due to other model activity before they happen (flow rates can change; other entities may change behavior, etc.).
- This would seem to be more accurate than the old Wentworth model, and dramatically change the concept and need for the future events chain. At the same time, it tremendously drives up the processing with each entity need to constantly re-predict its own next event.
- Multiple consequential events may take place between display cycles – in which case the next display cycle needs to “catch up” with the “state of the world”
- Multiple display cycles may take place without any consequential change in the predictive behavior arena – in which case normal “progressions” need to be updated for visualization (e.g., flying object need to proceed along their trajectories, flows need to proceed and storages fill or empty to new levels, etc.)
- Need to review references, including new ones above, regarding “the modeling” loop. It seems we
- Test impact for physics
- Think in terms of a large liquid flow into a storage
- What happens as the “gate” between the flow and the storage is closed, but not instantaneously. The “flow” needs to slow as it becomes harder to “push” through a smaller gate.
- In an instantaneous close, the flow still does not stop instantaneously. There is a continued “push” of new material into the flow, but it has nowhere to go. There is a pressure build up which causes a “bang” against what is now a wall, until a back-pressure reverberates through the “pipe” and eventually becomes quiet. The pressure may, or may not, become sufficient to burst the pipe, or pipe cap.
- Think in terms of a large liquid flow into a storage
Global simulation, socio-economic simulation stuff:
- See book shelf of materials, specifically:
- Technological Forecasting & Social Change, Vol 9 Number 1/2 “The Nature of a Simulation Model”
- See notes from Guido Wolf Reichert
- In a nutshell SD which was developed by Jay W. Forrester is an aggregate, continuous time-based way to build real-time simulations of coupled feedback systems (positive feedback = exponential growth, negative feedback = goal seeking)http://en.wikipedia.org/wiki/System_dynamicsIt is a great addition to the younger agent-based modeling approach but imho has greater explanatory power in that you can tell ‘why’ something happened (at least in simpler systems). It is more like a strategic model of business and rather links to the macroeconomic style of modeling in economics.It can be quite soft but essentially is mathematically hard stuff that has the same power (probably even more) than econometrics which is usually used.For some application of it take a look at Kim Warren’s site:
Depending on your background there are many roads to a degree. It is still done at MIT and you will find a distant learning programme at Worcester Polytechnic Institute (www.wpi.edu). SD is all about ‘fusing things together’ so just have a look.
- Stafford Beer who invented management cybernetics. His viable systems model (VSM)
- https://www.youtube.com/watch?v=7COX-b3HK50 – The Intelligent Organization Part 1, A conference presentation by Stafford Beer (see also related videos)
- In a nutshell SD which was developed by Jay W. Forrester is an aggregate, continuous time-based way to build real-time simulations of coupled feedback systems (positive feedback = exponential growth, negative feedback = goal seeking)http://en.wikipedia.org/wiki/System_dynamicsIt is a great addition to the younger agent-based modeling approach but imho has greater explanatory power in that you can tell ‘why’ something happened (at least in simpler systems). It is more like a strategic model of business and rather links to the macroeconomic style of modeling in economics.It can be quite soft but essentially is mathematically hard stuff that has the same power (probably even more) than econometrics which is usually used.For some application of it take a look at Kim Warren’s site:
Tortuga (http://en.wikipedia.org/wiki/Tortuga_(software) and http://code.google.com/p/tortugades/) is an open source GPL simulation framework in Java where simulations can be written as interacting processes or scheduled events. Developed at MITRE. “Each simulation entity is implemented as a separate thread.”
Deus (http://code.google.com/p/deus/) is a different form of simulation that looks interesting and appears to be an open source Eclipse package for simulating emergent (!) behavior. It defines three key elements:
- Nodes (the parts of the system that interact)
- Events (things that happen, e.g., node birth/death, interaction)
- Processes (stochastic 0 or deterministic activities that regulate the timeliness of events)
Can be configured using XML configuration script.
AfPanel is base panel for the development hierarchy. It is the baseline component control for GUI development.
AfGraphicsPanel is derived from AfPanel and is the base for user drawn graphics that occur directly on the panel as a drawing canvas.
AfGamePanel is derived from AfGraphicsPanel and is an extension designed to support game and simulation animation effects.
Game design needs to ensure separation of logic between update activity and rendering activity. Failure to separate logic can result in deadlock situations regarding game rendering resources.
There are three primary modes of activity:
- Design time activity – game is not running and game is in design mode
- Runtime activity – game is in runtime mode
- Running – runtime mode and running
- Not Running – runtime mode and not running
- Multithread can use stress testing.
- Need to continue review of multithreading and arrangement of cross-thread logic, including paint and screen generation logic.
- Terminating the application while a simulation panel exercise is running causes the application to freeze and not terminate.
- Screen colors are a bit whacked after initial code to attempt to begin to create a method for “scheme management.” This is especially evident on forms with text and label controls, and on buttons.
- Situation is improved with use of common InitializeScheme() routine in anchor which does recursive color setting on form controls. However, blindly setting all controls to the same color has a somewhat lifeless look. Next level of improvement might set different control types different colors as part of the scheme. Also, we need a way to not override font all the time.
BATSG1 (the R. C. Wentworth model from Golden gate) was primary designed as a solution to modeling oil flows. It can easily be re-conceptualized to model the flows of other gases or liquids, and can even be conceptualized as modeling flows of other physical or virtual materials (messages, data bits, gravel, sand, ore, shipping containers, manufacturing parts, etc.). The key factor is that the problem domain revolves around a flow of materials problem where there can be multiple types of materials simultaneously flowed, but the materials themselves are not converted in the process of the simulation. Fundamentally it can be used to solve throughput efficiency in a logistical positioning process.
As originally developed, the model did not provide for resource constrained modeling or scheduling. Adding that feature provides a degree of sophistication without too much added complexity.
Some interesting variations or extensions to the model include:
- An option to include transformational processes in the model
- Inclusion of simulated Six Sigma statistics as either constraints or derived results
The transformational process option would allow for the transformation of materials during the simulation process. For example, in the case of oil, the oil could be converted to gasoline so that the flows might include both crude oil and gasoline delivery, with gasoline dependent on a delivery network and a supply of crude oil that is being converted. Or, in a factory type environment, raw materials become shaped into rough parts, rough parts are machined, component parts are assembled, etc. This requires the conversion of materials into different forms along the flow line. Stores of one type of materials are consumed and stores of another type of materials are filled as the flow moves.
The overall significance of the simulation model facility to the concept of architecture is its use in evaluating the effectiveness of the architecture (flows etc.) for the stated purpose of maximizing flows, etc. It has a direct and obvious application for transportation and logistics, and the factory becomes obvious for manufacturing. Using an information concept where transformations may not destroy the original raw material, it can also show information flows that require transformations or where selected information of one type triggers another information set or a process. For example in an order processing system, where information needs to be assembled and then conveyed, prioritized, scheduled and accomplished on a deadline basis. The concepts of prioritized use of resources for different goals and things like deadline scheduling for selected elements to reach destinations would be important parts to add to the model.
Basically we have two levels of modeling:
- A simple activity model where a series of entities traverse an activity network. As they move through the activities they choose arcs based on some criteria (events, probabilities, etc.). After so many iterations or so much time, there are statistics generated and produced, or if the network is not circular, the simulation terminates when no more entities exist and no more entities can be created.
- Entities may be predefined, or may be generated and consumed. This starts to bring in additional sophistication from the original BATSG1 model and makes it move toward a feature set like GPSS, or something along the lines of a project plan simulation where you are done when all the activities have been accomplished. Under the project plan scenario, you might want to know earliest/latest start/end times, idle times for workers, etc.
- We can model going through the maze if each location in the maze is a node and the arcs define where the opening are and the choice algorithm is the direction algorithm. Other options might be a Bayesian network or a Petri network. This implies a selection option for node exit condition choice processing.
- The storage/flow model is a second, optional model which may operate. The flow model describes the movements of materials through a network of storage units. In the original design flows moved liquids and gases, but they may also move particles or other units. Storage units may be fixed or mobile. Flows of materials into or out of storage units are determined by the actions of the entities as they move through the activity network. A full BATSG1 model would involve both the activity model (1) and the flow model (2). A flow model by itself might calculate (or have parameters for) things like defect rates which feed defect flows (for repair or to waste storage).
Programming/design of the model is accomplished by design of the facilities to be modeled rather than specific process logic programming of what occurs at each step in the process. Most of the process logic is accomplished by the standardized logic of the model framework. User application programming is brought into play by means of extensions to or replacement of the automatic programming when model events occur. Certain actions can only be achieved by means of user extensions since there is no facility to direct such actions automatically. Examples include attaching and detaching flows to storages.
Default programming consists of an event queue which is processed in modeled time-driven order. Events are of the following types:
- Statistics events are driven by the cycling of the model. They occur at fixed intervals during the simulation. Their purpose is to produce statistics showing the state of the model at fixed points as the simulation evolves.
- Entity events occur as the entities moving through the activity network begin or end activities, also defined as node exit and entry events.
- Storage events occur at critical points during processing based on storage levels being achieved. For example when a storage becomes full or empty, or when a storage reaches a high or low warning level.
Examples of what might be modeled include:
- The original concept of oil and natural gas flows from field to processing through a cargo fleet of ships
- Container cargo where storages include dock facilities, cargo ships, railroad cars and trucks
- Factory and warehouse processing where low storage level is low inventory and triggers include orders to re-order from the factory
- Message flows and queues through a computer network
Design-time functions for facilities:
- Create facilities
- Assign parameter constraint values to facilities
- Attach facilities
- Assign entities to arcs with time to completion
- Assign starting volumes to storages
- Assign resources to entities
- Assign flows to storages
- Assign storages to entities
General run-time functions for user code:
- Attach and detach flows to/from storages, start and stop flows, manage rate of flow between storages.
- Choose node exit arcs.
Detail options for model modification by user code:
- Attach a flow to a storage
- Detach a flow from a storage
- Turn flow on or off
- Set flow rate to a specific value
- Equalize flows by downward adjusting flows; if inputs exceed output, adjust input to match rate of output, if output exceeds input, adjust output to match rate of input.
- Assign entity to activity arc
- Assign entity to queue arc with scheduled exit event time
- Set flow pressure
- Increment storage value
- Activate entity
- Set maximum, minimum value for flow
- Locate an entity
- Locate a flow
- Allocate resource (by type)
- Deallocate a resource
- Be able to save a model and restart from where the last execution left off, either in terms of continuing with statistics as accumulated at that point, or clear the statistics and start with the entities and position and storage states as left off.
- Flows might be able to be either continuous flow (as original model) or variable flow as per a setting made by an entity on arrival. This could be useful for modeling discrete rather than continuous flows. For example, a flow of units of goods arriving by truck at a depot rather than a flow of gas or liquid. For the truck, the flow might be equal to the number of units of goods carried by the truck.
- Storages might be able to be subdivided by type of units stored. Permanently attached flows might connect to some base type. Dynamically attached flows might need to specify what material type they wish to obtain. (The alternative is to have unique storage types for each good type. This also models a warehouse of multiple goods types since storages do not necessarily occupy space.)
- Be able to model transformations at nodes, or on activities, that depict resource conversion where inputs are transformed to become outputs. If copied, the input survives and is disposed. If converted it goes away and helps create something new.
- This can be tied to input-output models
- This can be analyzed for spontaneous creation (stat) or black hole (stat) tracking of materials flows. [Where did it come from, where did it go to?]
- Inputs arrive at beginning and are carried through activity, disappear at end. Products are created at end and flow onward.
- If done, should this be a part of the flow/storage model where storages become factories, or is this best done by a new level of model where resources are delivered to factories and factories do transformations? In a factory model, flows might still be used to bring raw materials and carry away products, but a factory rather than a storage (warehouse) is used to do the transformation.
- Ability of entities to fork or merge? This might happen with special nodes where the number of items to fork/merge is controlled and stats generated. Special versions of generator/black-hole nodes.
- Would need and/or logic for merges? Or, could always be user logic.
- Might be able to be used as a trial for Eclipse OSGi application structure
- Might be able to be used as a trial for Eclipse BIRT (Business Intelligence & Reporting Tools)
- Reporting System for web applications(?)
- Lists, charts, cross-tabs, compound reports
- Charting engine may be used stand-alone
- Might be able to be used as a trial for Eclipse EMF code generation for selected internal elements
- Might be able to be used as a trial for Eclipse GMF graphical model code generation to be able to put a model view on screen as a network diagram (or two) and to watch the model as it runs. One consideration here would be to look at the activity network of the simulation model as a subset of the elements of the process flow in the GMF book.
- Might be able to integrate addition Six Sigma factors. For example: process flow maps, process simulation, TAKT time as input or calculated statistic, defect rates, other stats as input or outputs, DOE, relationship to aspects like PUGH or FMEA (might one or m ore of these serve as schemes for management of path flows. E.g., FMEA stats/info to choose or define workflow chosen on failure).
- Be able to log actual values for selected operations and compare with values derived from simulation exercises.
- The Deus framework opens up some new thinking into behaviors that make sense and might be able to be incorporated.
- Deus nodes might be entities
- Deus processes might be represented by activity networks.
- Activity networks do not need to be put together as a single large network. Instead they may be small networks defining processes that define behaviors. Behaviors can be assigned to entities. Where they are in a network defines what behaviors they are currently exhibiting and where they are in that behavior.
- Selected behaviors might be described as interruptible or background activities. If an entity enters a wait state on a primary activity, there is an option to perform a background activity while waiting. When the primary activity resumes, the background activity is suspended.
- A different, but more complex, design might involve multi-tasking – where a single entity is able to divide time between two or more activities. This would require a multi-tasking algorithm: preemptive or percent of time split?
- One way to do multi-tasking would be to fork the entity and create two or more entities. Each entity would have an assigned percent capability, representing how much of the total entity capability is represented. This becomes a multiplier on time. A 50% capable entity takes twice as long to perform activities. When a spawned (forked/shadow) entity completes a network of tasks (reaches a defined node type) it can merge with the primary entity and the original entity regains the lost capability.
- This might also be a way to do work while sleeping in wait queues. A forked entity might start a secondary, background task. When the primary entity wakes up and is ready to do work, the forked entity is put to sleep by reducing their capability level to zero.
- Selected types of interactions can be defined between entities and described using behaviors, where the behaviors in some cases may be defined as requiring a correspondent entity with a correspondent behavior pattern.
- Entity interactions may open up a scheme for inter-entity messaging. An entity may send one or more messages to other entities and then wait on responses (or a timeout). This provides a scheme for entity dialogs and other related behaviors. This in turn might lead to a simulation of programmed stimulus-response activity. The entity on the other side of these messages can be a function of direct awareness, common activities, or geospatial proximity (see next item).
- Expanding on the Deus concept, there is an option to include an aspect of spatial simulation by having the entities travel through a spatial landscape. This might optionally be done by following a series of vectors defining some form of space. They might be roads, shipping lanes or some other framework like the specifications for a building.
Primary entities in the model:
- Run Control – defines the overall control parameters for the execution of the model.
- Events Queue – the mechanism for tracking the current state of event scheduling within the system.
- Activities – defines the pathway through a series of processes that entities perform (or that are performed on the entity) and which consume time within the model. Activities take the following forms:
- Dummy vectors which take no time but cause an entity to move to a new node with a different set of subsequent activities. Can be used to represent choices or decisions between various alternatives, or can be used to create sequencing between a series of nodes where each contains some form of queue based activity (such as sequencing a series of load operations from a series of storages).
- Processes where the amount of time it takes to do the activity is specified as a parameter on the activity.
- Processes where the amount of time it takes to do the activity is determined dynamically as a function of the activity.
- Queues where entities wait for some external event to trigger their departure.
- Activity queues were originally a mechanism to wait until there was occupancy space on the activity in order to proceed. If we introduce resource constrained activities there still may be only one queue, except now it needs to ensure both occupancy criteria and resource availability. This is an entry criteria queue.
- Storage queues represent exit criteria queues. The entity must remain at the current position until an associated storage registers a full or empty condition.
- Event Nodes – defines the start, stop and state change events that occur within processes. Nodes are the intersection/decision points where activities are joined together.
- Entities – defines the moveable subject elements that traverse the activity network, the elements that perform (or endure) the activities.
- Resources – defines resources that are acquired and released (or consumed) by entities as they traverse the network. Resources may be defined in a variety of ways:
- Permanent resources may be associated with an entity and thought of as characteristics, attributes, traits, capabilities or talents of the entity. These might exist from the beginning or might be achieved or assigned as a function of the processing in the simulation.
- Private resources may be things that can be acquired for the private use of the entity and consumed, disposed of or used for trading purposes. Some resources may be obtained in exchange for other resources. Other resources may be consumed, or burned, as a function of time (similar to fuel).
- Public resources may be things that are sharable between entities and for which there is some contention as the simulation proceeds. They may be free, and there is simply a queuing process required to obtain them, or there may be a cost associated with acquisition for a period of time (in order to complete an activity).
- Cycle Definitions – define the statistics gathering periodicity of the model execution
- Flows – defines the rate of movement of materials between storages as a steady-state flow.
- Storages – supply or consume materials from flows. Trigger events based on full, empty, part full, part empty, etc. May have zero capacity (as a mechanism to have different flow rates in and out, to manage the simulation of the valve).
- It might be useful to assign a resource type to a storage.
- Another useful automatic facility might be a way for two interconnected storages to automatically message each other and direct a flow in a JIT formation. When a storage reaches a low-water-mark this might be conceived as a re-order point which activates a flow from an upstream storage to bring in more material. This brings up the question of a discrete sized package as being requested rather than a continuous flow of indeterminate size. The concept of the flow being continuous over some time is how it moves, but the practicality is in a lot of cases that there is a discrete target size that is desired to be moved.
- Yet another concept is an inventory list of resources to be maintained at a storage. This could be in the way of a superstore, or maybe just a direct store that houses multiple material types simultaneously. Each inventory item might have its own reorder level. Some stores (factories) might be able to use one resource to create another that is delivered to customers. (For example, a school uses teachers to impart skills or knowledge.)
- Nodes are traversed instantaneously (assuming activity-on-arc).
- Activities take time to traverse. The amount of time can be determined in one of three modes:
- A deterministic value can be set for how long an activity takes
- A randomized value can be assigned based on a defined generator function
- An activity may take an indeterminate amount of time where the entity is in a wait state waiting for one or more other events or conditions to mark the completion of an activity or to satisfy the ability to start a new activity. These types of activities are defined by wait queues. Waiting consists of an arc that begins and ends on the same node. Wait queues can be programmed automatically in a number of cases:
- Activity arcs that have a maximum number of entities force the creation of wait queues in order to perform the activity. When an attempt is made to perform the activity and a maximum number of entities are already performing the activity, new entities will be placed on a wait queue. Removal from the wait queue is automatic when the number of entities on the queue is reduced below the maximum.
- Activities which require certain resources may not be performed if the required resources are not available. This forces the use of a wait queue for the required resources.
- Activities associated with filling and emptying storages force have activity times that are dependent on the full or empty storage event. In a smooth operation the activity time is a function of the flow rate. However, if the providing storage has insufficient volume to satisfy demand the filling storage may take longer to fill, which extends the fill time.
- Flows are traversed instantaneously. To simulate a pipe with a delay between putting material in one end and being able to extract it from the other end you need to coordinate two flows and an additional storage where the storage describes the volume of material in the pipe, one flow describes the material entering the pipe and the other flow describes the material exiting the pipe. Flow A is what is going in end 1, Flow B is what is coming out, and there needs to be a delay in storage between an otherwise matched flow rate of input and output.
Operating mode needs to distinguish between design-time and run-time processing. Certain API functions are designated as design-time, but not run-time. Others may be run-time but not design-time. Some may be both. Design-time only functions exist in order to support model setup, but might otherwise cause problems during model execution. These might include things like resetting storage levels to arbitrary values, changing maximum and minimum values or other constraints, etc.
The design-time system is most likely to fit well within the message-driven conceptual framework. Messages to other parts of the system (e.g., the repository) would be used to gather and define elements of the model. At some point, a runnable model specification is defined. That model specification (if it is stored under some collection identifier) can be passed, via message, to an editor and validated as a good specification. This is the first stage of putting the model into run mode, but not yet running. Running can be a background task, possible executed on a separate machine. Run mode and running would not be message driven, except to send a message to start, a message to abort, or a reply when finished. There could also be messages to query status or to report status changes back to an observer (which could be a graphical model in an editor window). Model execution would seem to be a CPU intensive, local to the runtime activity. Cycle events (of a special type) might be the trigger mechanism to report status changes to observers.
System generated activities are a feature that may be provided on an optional basis. When the system is initially moved into run mode, the configuration of the model needs to be verified as operational capable. There are two situations that need to be looked for:
- Unnecessary specifications – these are things that can never happen, resource that can never be used. These might be hard (or impossible) to find since there is no way to determine what resources might be addressed inside of user extension code. The benefit to finding such resources would be to remove them from the model up front. This would have a beneficial impact on run time performance and would eliminate extraneous materials from statistics reports.
- Potential deadlock elements. These are specifications related to the configuration which can lead to deadlock situations where entities may be unable to proceed, or some other feature may not be able to function, due to the way the model environment has been configured. For these situations, if the model is able to create an easy and obvious fix to the potential problem, and if automated fixes are allowed, the fix should be generated as part of the configuration. If a fix cannot be created or is not allowed, the situation would be a reason to potentially abort the simulation before it starts. These might include:
- Requirements for a resource for which there is no store and no entities have been provided that resource as an assigned characteristic. Fix: remove the resource requirement from the activity.
- Evaluation of the activities into and out of a node where all output activities have maximum occupancy specifications and the maximum occupancy of the output activities is less than the maximum occupancy of the input activities. Fix: if no wait queue has been defined at the node, then create a wait queue.
Automated event time scheduling can be assigned via any one of a number of functions as described below.
A single value function simply assigns a specific value to the time required to perform an activity.
A multi-value function which requires parameters defining minimum, maximum and other factors depending on type of function to be used assigns a randomized value to the time required to perform an activity. For generating functions a Poisson distribution is often used: see http://en.wikipedia.org/wiki/Poisson_distribution. Another simple formula is the PERT calculation using optimistic, pessimistic and most likely estimates of duration to define a normal distribution. See BATS notes for other formulae including uniform and exponential distributions.
Certain activities have capacity constraints, resource requirements or are associated with storage events. These activities may force entities into wait queues for the event (occupancy reduction, available resource, storage level achieved) to occur. Queue wait time in these cases is a function of the external event, not a specification of the queue.
Event prediction occurs within the simulation process when an element within the model which has events has encountered a state change and a new prediction of the time of the next event for the element needs to be calculated.
Cycle events occur on a deterministic schedule. When each event occurs the scheduled event time clock is advanced by the deterministic cycle period to compute the next cycle event occurrence. The two exceptions to this rule are:
- The initial cycle event is scheduled at a specified time when the statistics gathering process is desired, or at a program determined trigger time based on some action or other event.
- No more cycle events are scheduled when the final cycle time has arrived or after the specified maximum number of cycle events.
Storage events occur at one of four times:
- Storage becomes full after having been filling and not been full
- Storage becomes empty after having been emptying and not been empty
- Storage is filling and first reaches a high warning level
- Storage is filling and first reaches a low warning level
Only one of these events may occur at any point in time. All of these events are conditioned upon the rate of flow into and out of the storage at any point in time. Each time a flow is attached, detached or a connected flow is adjusted the rate of change for the storage is potentially changed. At those points the new rate of change for the storage is computed and a revised schedule is determined for the next storage event based on the new rate of change.
Entities spend time performing activities defined by activity arcs. There are four general types of activities:
- Processes which take some finite (deterministic or stochastic) amount of time that is determined as a function of the activity. These are the most common.
- Queues which take an indeterminate amount of time with the time determined by the results of other processes that are happening within the modeled system. Queues define wait time. Waiting may occur for a variety of reasons.
- Generator activities (birthing).
- Terminator activities (dying).
Generator and terminator activities are instantaneous and occupy no time.
Queues take an indeterminate amount of time. When an entity is released from a queue it is placed on another activity arc. The next event for the entity becomes the start event on the new activity arc.
At the start of a routine process activity a time to completion value is determined using the appropriate function as assigned to the activity. This becomes the time to completion.
It is also possible for an activity to last an indeterminate amount of time based on needing to fill/empty one or more storages attached to the entity. How does that work?
Utilities provide certain general purpose sets of functions to assist in the operation of the simulation. These include:
Units conversion is something that can be done in a single routine that can easily be programmed and easily be recognized when needed. If the units supplied by a resource is not appropriate as per the needs of a functional algorithm (but the supplied substance is correct), a simple units conversion call is made to convert to the appropriate units (e.g., barrels to gallons, feet to miles, miles to kilometers). The conversion routine is called passing a value and two units labels. The function results in a new value in the converted units. Internally the routine consists of a simple table of label pairs with an associated conversion multiplier.
Overall operational flow of the simulation takes the following form:
- Identify and remove the next event in the future events queue.
- If the next event is the last cycle event marking the end of the simulation, stop.
- If the next event is for a time in the future after the most recently processed event
- Update the model environment
- Scan all Storage units in the model and update their current volume statistics to reflect the passage of time. Review and update any associated related statistics (volume of flows, high/low levels reached, etc.)
- Update time in use for resources.
- Update time in activity or time in queue for entities.
- Update the model environment
- If the next event is a cycle event
- If user gathered statistics logic is enabled and called for on the event
- Call the appropriate user statistics logic routine
- If standard statistics are requested
- Produce the standard statistics report
- Schedule the next statistics cycle event
- If user gathered statistics logic is enabled and called for on the event
- Else if the next event is a storage event
- If user extension storage logic is requested
- Perform user extension storage logic
- Else if automatic storage logic is requested
- Perform automated storage processing
- Schedule the next event for this storage
- If user extension storage logic is requested
- Else (the next event is an entity event)
- If user extension entity logic is requested
- Perform user extension entity logic
- Else if automatic entity logic is available
- Perform automated entity processing
- Schedule the next event for this entity
- If user extension entity logic is requested
- Go to 1
The prior simulation scheme was based on the predictability of future events. That was, I believe, the scheme for BATS1. However, if we are modeling interacting intelligent agents, the further into the future events are predicted the less likely it is that they will unfold as predicted. Instead:
- We can ask for event predictions from all event producers and keep only the closest next event.
- Advance all time-based agents to the time of the next event.
- If the event is a “Cycle Event” (Statistics) gather and report the statistics and loop to 1->2 for the next event. (Avoid polling by skipping 1 and knowing the next non-cycle event from the earlier poll.)
- Process the non-cycle event.
- In an expanded model these could be lots of things, like collisions that occur between moving entities, etc.
- The more involved and sophisticated the model, and the greater the number of “moving” (thinking) parts, the greater the likelihood that predictions will NOT happen as predicted.
- Examine for and process secondary events which may occur as a function of the primary event which was scheduled. This includes processing of instantaneous messages which may be transferred between entities as a consequence of events. Process state changes and related events. Establish quiescence at the defined “moment” in simulated time.
- Loop back to #1.
A Future Events Queue may still make sense, but its use is less consequential. The downside of this is extra processing on each “event” cycle in terms of polling all dynamic parts and asking for new predictions. However, there may be some ways to save some processing power:
- If multiple screen refresh cycles are scheduled between “process events,” the process loop does not have to occur for every screen refresh cycle. Instead, “movement” would be considered a non-event and processed using a screen refresh cycle that only has to move objects that are on screen, coming on screen, or leaving screen. Major simulation events can be on a different event thread.
- Elements on screen can have screen exit events calculated based on trajectory and steering logic.
- Elements off screen can have screen entry events calculated based on trajectory and steering logic.
- Then, off screen elements can bypass movement processing until their screen intercept time
- Screen refresh cycles can simply be concerned with on-screen elements, and further limited to movement related factors.
- Meanwhile, background processing can compute the impact of the next non-movement event.
- If this were a game, rather than a simulation with all autonomous agents, the user action would become a new “event” that would have to be reconciled to “time now” and it would have the potential to trigger some other event at a time prior to the otherwise next scheduled event.
Statistics logic consists of scanning the element lists maintained by the system and dumping the associated statistics in labeled subsets at specified intervals. For selected statistics, or based on selected types of statistics events, statistic counter values may be cleared during this process.
Automated storage logic is applied at storage full and storage empty events.
- If the storage is full, create an event notice to all entities in the queue waiting for the storage full event notification.
- If the storage is not allowed to overflow, flow rates of input and output are equalized by reducing the rate of inputs. If needed, incoming flows are stopped.
- If the storage is empty, create an event notice to all entities in the queue waiting for the storage empty event notification.
- If the storage not allowed to underflow, flow rates of input and output are equalized by reducing the rate of outputs. If needed, outgoing flows are stopped.
Entity events primarily occur on a direct basis as a result of completing an activity.
On activity completion:
- Release all sharable resources currently held
- Determine next desired activity
- Removal of the entity from the activity arc causes the activity arc to attempt to activate any queued entities that are waiting to occupy the arc.
- Attempt to acquire all non-sharable resources needed for next/target activity
- Attempt to acquire sharable resources needed for next/target activity
Has overall responsibility for the operation of the simulation. Responsible for the management of the operating mode and the execution of the simulation when running.
Major game pieces:
Defines the overall control parameters for the execution of the model. May use either number of cycles or end clock as a terminator.
- Total run time
- Run start time (start clock)
- Run stop time (end clock)
- Number of cycles
The collection of scheduled events. This is the mechanism for tracking the current state of event scheduling within the system. Events are maintained in simulated time order. There may be multiple events scheduled for the same time. Within time slot events are prioritized by type:
- First scheduled are all storage events.
- Next scheduled are all entity events.
- Last scheduled are any cycle events.
New events may be added to occur any either time NOW, or at a future time.
May be viewed as All Events, or Scheduled Events, or Unscheduled Events. May also be viewed by event type.
- Is there a need for a list of “unscheduled” events? If each eventable element can only have a single “next” event scheduled, maybe we only need a list of events that have been scheduled. If we run out of events, the simulation is over since the cycle events will have been scheduled at the start and the last event allowed to be scheduled is the cycle end event.
- The list of items
- Event processing summary statistics
- First scheduled event
- Last scheduled event
- Schedule Event – given an event element reference and a time, inserts an event into the event queue to occur at a particular point in simulated time referencing the given element
- Get Next Event – determine which event is scheduled to occur next and return a reference to the event.
- Find Event – given an event specification, return a reference to the event
- Find Cycle Event
- Find Storage Event
- Find Entity Event
- Remove Event – given an element reference, removes the next event scheduled for that element.
Defines a single event scheduled to occur.
- Event Type
- Entity: Activity initiation/termination
- Storage Event
- Cycle event
- Event element reference – reference to the element having the event
- Event time
- Next event
- Prior event
The collection of activity arcs.
- The list of items
- Activity processing summary statistics
- Locate Entity – returns a reference to the activity containing the referenced entity
- Size – return the number of activity arcs in the network
Defines the allowable paths between the nodes that may be traversed by the entities. Each path defines the non-flow processes that take place within the model. Paths have direction from a start to an end. Cyclic paths are allowed. Duplicate paths are allowed. Certain resources may be required in order to accomplish the activity, or certain resources may be consumed in the process of performing the activity
- Defining paths as enabled or disabled and allowing this status to change can modify the flow through the network during the simulation. This might be useful in modeling network fragmentation and repair (or it might make more sense for that type of thing to be modeled using the flows).
- Activity Identifier
- Starting Event Node Reference
- Ending Event Node Reference
- Next Activity with same origin node
- Next activity with same destination node
- Duration Function
- Duration Function Type
- Duration Function Parameters
- Constraint: Minimum entities on arc
- Constraint: Maximum entities on arc (queue depth or activity congestion constraint)
- Statistic: Minimum entities on arc
- Statistic: Maximum entities on arc
- Statistic: Number of entities which have left arc
- Statistic: Current number of entities on arc (current + left = arrived)
- List of current entities on this arc
- List of required resources (These are resources that are required in order to perform the activity, but they are not consumed. They are either renewable, or they may be characteristics that simply exist, or not.)
- List of consumed resources (These are also resources required in order to perform the activity, but they are consumed as a result of performing that process.)
- Rate of consumption
- Queue list of entities waiting to start this activity
- Entity Count – returns the number of entities currently on the activity arc
- Engage – place an entity on the arc
- Disengage – remove the referenced entity from the arc
- Revive – re-activate the next available sleeping entity and schedule its departure from a queue
The collection of event nodes. Event nodes define the starting and/or ending point for activity arcs.
- The list of items
- Node processing summary statistics
- Size – return the number of nodes in the list
Defines the start, stop and state change events that occur within processes by marking the beginning or end of activity arcs. Defines the transition from the incoming arcs to the outgoing arcs. A simple node may have a single input and a single output (arcs have direction). Node transition logic (that determines how an arriving entity is handled in terms of selection of output) may be automatic system logic based on a prescribed formula or may be accomplished via a user provided routine. Specialized node types include:
- Sources – entity generators
- Sinks – entity consumers (black holes)
- List of activities which start here
- List of activities which end here
- List of queues at this point (start and end here)
- Node type
- Event logic flag (user versus automatic, type of automatic)
- Report level
- Statistic: number of entities that have crossed this node (This is sum of inputs = sum of outputs. There is no “current” since node transition is instantaneous.)
The collection of entity elements.
- The list of items
- Entity processing summary statistics
- Size – return the number of entities in the list
Defines the moveable elements that traverse the activity network, the elements that perform the activities. They cause events to occur when they start or terminate activities (arcs), which happens as they move through transition nodes.
- Entity type
- Current or target activity arc
- Activity arc may be a stack of alternative activities. If an entity is placed in a queue on one level, it might engage in activities at another level. When the primary activity is allowed to proceed, the alternative activity may either be suspended or dropped, depending on the nature of the relationship between the entity and the activity. For example, moving out of range for a proximity based activity may cause it to be dropped.
- Current arc type
- Current arc is either a current arc or a target arc. If the entity is in one or more queues waiting for resources to become available or an event to occur, the arc identifies the target activity to be engaged when the conditions are met.
- Next event reference in events list
- Activity count (total number of activities traversed)
- Queue count (number of times queued)
- Queue time (time spent on queues)
- Time started current activity
- Time expected to end current activity (if known)
- Next entity on same activity
- Total storages (carried)
- Storage list of carried storages
- Resource list
- Current Activity – returns a reference to the current activity for this entity
- Get Stores – return a list of references to current storages being carried by this entity
- Get Resources – return a list of current resources owned by this entity
- Get Storage Count – return the count of the number of storages owned by this entity
- Get Resource Count – return the count of the current number of resources controlled by this entity
Collection of resource elements.
- The list of items
- Resource processing summary statistics
- Size – return the number of resources in the list
Defines resources that are acquired and released (or consumed) by entities as they traverse the network. Resources define operational constraints. Entities may be required to have resources of a particular type in order to accomplish activities.
- Resource type
- Maximum number of shares
- Current (shared) entity owner list
- Queue of waiting entities.
Collection of cycle elements.
- The list of items
- Cycle processing summary statistics
- Size – return the number of cycles in the list
Elements responsible for defining and triggering the statistics gathering actions and periodicity of the model execution.
- Cycle event type
- Statistics/reporting flags
- System generated statistics (Y/N)
- User generated statistics (Y/N)
- User exit routine name
- Start time for first event, or first cycle number
- End time for last event, or last cycle number
- Total number of events
- Time increment period for next cycle
- Next event reference in event list
Collection of flow elements. Flow elements are mechanism to manage a flow of materials from one storage unit to another. Flows may be connected and disconnected from storage units during the course of the simulation. (For example a hose on a tanker truck will be connected and disconnected from a series of underground storage units as the truck delivers it contents to multiple delivery points.) Duplicate flow paths may exist (multiple flows using same origin/destination pair). Circular flows where the origin and destination are the same are not allowed. Circular flows between multiple storages are allowed.
- The list of items
- Flow processing summary statistics
- Size – return the number of flows in the list
Element that defines the rate of movement of materials between storages as a steady-state flow. Flows must have a defined origin, destination or both (missing both is not valid). Flows without an origin are inputs to the modeled system from the outside environment. Flows without a destination are outputs to the environment from the modeled system.
- Originating storage reference (emptied by flow)
- Destination storage reference (filled by flow)
- Nominal flow rate (particles per unit of time)
- Pressure valve setting (multiplier where 1.0 = nominal rate of flow, p > 1 is a pressure valve, p < 1 is a reducing valve) – multiplier to get actual flow. 0 = stopped flow but flow is still ‘running’ and valve is not closed. P < 0 is a backflow.
- Current flow speed (on/off gate * flow rate * valve pressure)
- Total flow for run
- Total flow for this cycle
- Last flow (rate) adjustment time (up/down, on/off)
- Flow since last start
- Time running total
- Time since last adjustment
- Last end time (time last turned off when not already off. Set to null when flow is started. Reset to current time when flow is turned off.
- Next flow using same originating storage
- Next flow using same destination storage
- On/off forward/reverse gate (1 = valve open and flow moves forward, 0 = valve closed and flow cannot move, -1 = valve open and flow moves backward)
- Flow type (for statistical distinctions)
- Is On – return Boolean set to value of on/off switch
- Is Running – return Boolean to determine if on and flowing
- Get Speed – return current flow speed
- Set rate – sets the flow rate
- Set pressure – sets the valve pressure
Collection of elements that supply or consume materials from flows. Storages may connect and disconnect from flows. Storages may move around (carried on entities as entities move through network).
- The list of items
- Storage processing summary statistics
- Size – return the number of storages in the list
A single storage within the storage set. Trigger events based on full, empty, part full, part empty, as determined by flow rates; or by user logic when entity events occur. May have zero capacity (as a mechanism to have different flow rates in and out, to manage the simulation of the valve). The concept of input and output flows in nominal, not actual. Input flows with backflow or input flows operated in reverse are outputs; outputs with backflow or operated in reverse are inputs when calculating changes in storage level.
- List of input (nominally filling) flows
- List of output (nominally draining) flows
- Type of storage
- Type of material stored
- Can overflow [hold more than posted capacity]? (Y/N)
- Can underflow [provide supply even when empty]? (Y/N)
- Maximum units volume allowed event trigger level
- Minimum units volume allowed event trigger level
- High volume warning event trigger level
- Low volume warning event trigger level
- User exit for event processing
- Current storage volume
- Time last storage volume change occurred
- Current net flow in/out per unit time
- Next event reference
- Next event time
- Next event volume
- Maximum volume achieved (high water mark)
- Minimum volume achieved (low water mark)
- High volume time occurred
- Low volume time occurred
- Total time at full status
- Total time at empty status
- Total time above high warning status
- Total time below low warning status
- Total volume of overflow
- Peak overflow excess
- Total volume of underflow
- Peak underflow insufficiency
- Total time with flows
- Total time without flows
- Allowed input flows
- Allowed output flows
- Allowed total flows
- Current input flows
- Current output flows
- Current total flows
- Maximum input flows
- Maximum output flows
- Maximum total flows
- Queue list of entities waiting for storage full
- Queue list of entities waiting for storage empty
- Is Empty – return Boolean where true if empty
- Is Full – return Boolean where true if full
- Is High – return Boolean where true if current storage level GE high warning
- Is Low – return Boolean where true if current storage level LE low warning
- Attach Flow
- Detach Flow
- Equalize Flows
- Adjust Level – adds or subtracts volume from current storage level without using flow
The original concept of the simulation facility was for a self-standing program where the simulation executed on a singular machine. It might include the ability to checkpoint the simulation run, but it was largely an “in memory” simulation process. This optimizes for speed with small models, but creates machine limitations on where the data must be located and on the size of the models which can be run. This was the design for the original BATSIM models.
The new design for the simulation facility is to develop the facility in a manner which utilizes the design characteristics of the EATS infrastructure to support scaling to enable the construction and execution of large, potentially federated, models. This needs to provide support for the data for the simulation to potentially exist on a distributed basis and provide for execution of the simulation to also be distributed over a series of nodes. This does not preclude all of the simulation activity from occurring on a single machine, but it does add communications and coordination overhead such that small models will run slower. However, this same ability to distribute a large model over a series of machines and have certain portions of the simulation executed in parallel also provides a capability that allows the execution of much larger models to occur, and potentially to speed the execution of some models if tasks are appropriately allocated based on resource requirements. Historical perspective indicates that this is a reasonable tradeoff since even for small models the additional communications overhead is likely to go unnoticed as faster and faster processors and communications facilities are brought into play.
There are two different protocol sets that have been established with IEEE standards relative to the development of networked simulations. Both have a base in DoD military specifications. These are:
- DIS – Distributed Interactive Simulation (circa 1991), IEEE 1278
- Simulation state information is encoded in formatted messages, known as protocol data units (PDUs) and exchanged between participating components using existing transport layer protocols, including multicast.
- There is no defined centralized “host” for the simulation.
- There is no coordinated clock to manage time within the simulation. Now is now. Things happen when they happen.
- Simulation nodes must broadcast all data of potential concern to other nodes whether actual clients exist, or not. Clients must process all published data and filter based on local needs.
- The current version (DIS 7) defines 72 different PDU types, arranged into 13 families. Frequently used PDU types are listed below for each family.
- Entity information/interaction family – Entity State, Collision, Collision-Elastic, Entity State Update, Attribute
- Warfare family – Fire, Detonation, Directed Energy Fire, Entity Damage Status
- Logistics family – Service Request, Resupply Offer, Resupply Received, Resupply Cancel, Repair Complete, Repair Response
- Simulation management family – Start/Resume, Stop/Freeze, Acknowledge
- Distributed emission regeneration family – Designator, Electromagnetic Emission, IFF/ATC/NAVAIDS, Underwater Acoustic, Supplemental Emission/Entity State (SEES)
- Radio communications family – Transmitter, Signal, Receiver, Intercom Signal, Intercom Control
- Entity management family
- Minefield family
- Synthetic environment family
- Simulation management with reliability family
- Live entity family
- Non-real time family
- Information Operations family – Information Operations Action, Information Operations Report
- When referenced in terms of gaming this scheme basically refers to the technique of global message broadcast of standardized PDU packages without the requirement for a centralized authority. PDU content may be adapted based on the game theme requirements.
- HLA – High Level Architecture (circa 1996), IEEE 1516
- An implementation of an HLA-based simulation system consists of a federation of simulation components interacting using a standardized protocol through a common runtime infrastructure.
- HLA defines the architecture specification for the interaction and not a particular implementation of that specification. The HLA standard has three parts:
- HLA Rules defining how the components within a federated simulation interact.
- The Object Model Template (OMT) defining the scheme for communications within the simulation environment. The specifications are defined as XML schemas. There are two major object models, both of which are build in conformance with the OMT:
- Federation Object Model (FOM) the definition of objects of interest within the entire federated simulation environment.
- A sub-piece of the FOM is a standard HLA Management Object Model defining a collection of classes and interactions (events) used to manage the federation.
- Simulation Object Model (SOM) the definition of objects of interest within a specific federate.
- Federation Object Model (FOM) the definition of objects of interest within the entire federated simulation environment.
- An Interface Specification divided into seven service groups:
- Federation management: Defines how federates can connect to the runtime infrastructure (RTI), create, join and manage federations, save and restore federation states and defines a system to synchronize federates to the same time.
- Declaration management: Defines how federates declare their intentions with regard to publication and subscription of classes and interactions.
- Object management: Defines how federates can utilize objects and interactions once they have ownership of them.
- Ownership management: Defines how federates divest and acquire ownership of registered objects.
- Time management: Defines how time is used in a federation and how it affects object and interaction updates, federate saves and other services.
- Data distribution management: Defines the various ways that object and interaction data is transferred from and to federates through the RTI.
- Support services: Defines various services to retrieve information about the current federation, such as classes and interactions.
- Documentation Resources
The focus of a DIS-oriented distributed simulation is standardization of the exchanged PDU packages. The focus of a HLA-oriented distributed simulation is standardization of the interface API and the scheme for time synchronization.
An overview and analysis of the two was accomplished in 1998 as part of a Master’s Thesis at the Naval Postgraduate School by Steven D. Knight. In the Executive Summary he states:
- Under DIS, models broadcast Protocol Data Units (PDUs) over an area network and received PDUs from other models. The PDUs attempted to contain sufficient information to allow various models the ability to represent entities and events within each model. Although successful in many aspects, DIS is limited by available information from models, memory and network requirements, and analytical tools available.
- HLA [an object-oriented approach to interoperability] requires models, or federates, to publish and subscribe to objects, interactions, attributes, and parameters specified in the Federation Object Model (FOM).
- Analysis is conducted differently in DIS and HLA due to the differences between broadcasting and publish/subscription requirements.
The differences in approaches to analysis was the focus of his thesis. His conclusion was that the HLA approach, with a specialized Analysis Federate, provided a better base for analysis of networked simulations.
A second simplified comparison of the two protocols can be found at StackOverflow. A more detailed discussion paper comparing the two technologies for use by the Australian military can be found here.
The standards defined above were developed by and for potentially massive simulations as accomplished by the military in exercises such as war games or complex avionics simulations. This potentially indicates significant over-kill in adopting these techniques. However, the standards can be viewed from both a conceptual perspective and as a set of technologies. While direct implementation of the technologies as specified may be over-kill, the conceptual comparison can help in defining the approach to use in the EATS simulation facility.
In our basic textbook for networked gaming, DIS is often referenced as the conceptual architectural baseline for building a networked virtual environment (NVE). While their architectural choice for gaming leans toward DIS they also identify HLA as an alternative framework for applications that require “tighter integration.”
Technically EATS should be able to implement either architectural protocol. If our objective was multi-player gaming, as is the general case for the virtual environments described in Networked Graphics, the better design approach might be DIS. The primary objective in a gaming environment would tend to be real-time interaction between the networked players and game components. Since interactions between components are not coordinated, fast components have an advantage and slow components are at a disadvantage. Real-time for the game is “real time.” This works for a gaming experience (although it may not be “fair” to the player with slower hardware or communications facilities), but it is not “helpful” to a simulation exercise where the objective is the generation of a simulated result-set based on model logic and divorced from the mechanical facilities on which it was run. For such simulation exercises an HLA-style framework makes more sense. Because an HLA-styled framework operates through a centralized manager component, the RTI (Run Time Infrastructure), the RTI is able to compensate for technical issues between components. This would not necessarily be an enjoyable experience in a gaming environment; but it is useful for simulations designed to feed analytical processes, especially those with less than real-time consequences.
The Wikipedia article on the HLA RTI identifies a number of known implementation for an RTI. These include both commercial and non-commercial implementation using C++, Java and mixtures of other languages. In the non-commercial realm there are a number of mixed Java plus C++ versions, and three implementations defined as straight Java. Core classes for these implementation are provided by IEEE as part of the IEEE 1516 standard specification:
- EODiSP – [GPL License] implementing a partial IEEE 1516 standard. In development by P&P Software GmbH for the European Space Agency to support the development of end-to-end simulators for earth-observation satellite missions.
- Open HLA – [Apache License] provides an open-source implementation of the HLA RTI spec 1.3, IEEE 1516 and IEEE 1516 Evolved. It also provides a framework to wrap the standard RTI classes and FOM to code generation to make life simpler.
- NPSNET-V XRTI – [BSD License] a discontinued implementation of the IEEE 1516 standard developed by the Naval Postgraduate School.
- Portico – [CDDL License] is an open source, cross-platform, fully supported HLA RTI implementation. Designed with modularity and flexibility in mind, Portico is a production-grade RTI for the Simulation and Training Community. Offered with RTI runtimes for Windows, Mac or Linux. Appears to be Eclipse based.
Conceptually an HLA-styled framework appears to be a good match for our desires. In fact, HLA is conceptually very similar, as a distributed federated organizational scheme, to the core architecture of EATS. Key difference come more from implementation than from design concept.
Integration with EATS involves at least two major factors:
- The use of EATS entities as the foundation for the elements of the simulation model, and the ability to correlate simulation results back to these entities when analyzed for other purposes or from other perspectives.
- The use of the EATS Infrastructure as the technical foundation for the processing of the simulation.
HLA design concepts have more to do with the second point, rather than the first. From an implementation perspective HLA prescribes a federation of interoperating units, using standard protocols (service sets) for interactions, all of which occur via the intermediation of a common runtime infrastructure. HLA, and the infrastructure, is agnostic the semantics of the system being modeled.
EATS has a similar architecture. Applications are built as federations of modules designed to operate according to a common communications standard and through a common infrastructure, where that infrastructure is agnostic to the semantic intent of the messages it processes.
Given this similarity, we can envision a potential, large scale simulation environment where model elements can interoperate with components inside and outside of an EATS framework, where the EATS components may be either primary, or supportive units, in the simulation. According to documentation from the MOVES Institute, HLA does not define a wire protocol, but rather specifies an API, using detailed interfaces specifications and a discoverable XML message format for data interchange. “The drawback to this is that a simulation running a Pitch HLA implementation will not be able to talk to a simulation running a MaK HLA implementation. … The wire format incompatibility can be mitigated via the use of gateways.”
The use of gateways is a design scheme that has been demonstrated to work effectively with the EATS architecture for both front-end and back-end interaction. EATS was designed to facilitate federated operation using the model shown in Figure 1. The primary interaction between EATS modules and/or EATS clients is via an EATS infrastructure specified “architected service” interface. However, architected elements can also interact with “non-architected” elements. These may take the form of an External Client or an External Service Provider. (Clients request services from EATS, Service Providers provide services to EATS.) Either connection can be via an “Architected Service” or an “Non-Architected Service.” The distinction between the two is the need for and use of a gateway to bridge technical infrastructure differences. If the gateway is supplied external to EATS, then the external service appears as an Architected Entity (one aware of and compliant with the EATS architecture). The other option is for EATS to incorporate the gateway mechanism, in which case EATS presents itself as compliant with the external component’s architecture.
Using this scheme a large scale simulation with components executed on HLA-compliant infrastructures could be integrated with EATS federates, or an EATS federation. This type of integration is not considered an operational requirement, but should be viewed as a desirable feature that should not be precluded by the detail design of the simulation facility.
For routine business process we tend to think about EATS message processing as a client-driven, hierarchical, cascaded process. This same logic should hold for the simulation processing, at least at a very high level. However, with a simulation, the amount of internal activity generated as a result of a client action will probably be astronomically high compared to business processes.
A simulation in EATS is driven by an EATS Simulation Engine, which is implemented as a C_AF_ResourceProvider within the EATS Infrastructure’s core framework. This facility is the EATS version of the HLA run-time infrastructure (RTI). The engine is an optional component of an EATS runtime process based on configuration. If specified, it will be loaded on demand. The base engine is extended using demand loaded C_AF_ResourceProviderExtension modules to handle various “RTI” functions. One of these extensions is responsible for providing the communications substrate that is used for all communications between the simulation components (HLA Federates). Other extensions are responsible for exposing the management components for the simulation:
- Federation Object Model (FOM)
- The FOM defines the objects (entities) that can exist in the simulation (federation run instance). It provides the specification for all exposed object attributes and all interactions (events) that may occur.
- Time Management
- The Simulation Engine is responsible for coordinating activities of the Federates based on a synchronized simulation clock. The simulation clock advances in simulated time independent of real clock time.
- Management Object Model (MOM)
- The MOM provides the mechanism to learn about, interact with, or manage the simulation (Federation). It contains execution operating information and is used to control the Simulation Engine (RTI).
Each of these extensions provide EATS “base-level” functionality, but can be extended with customized logic which is integrated through the Eclipse Plugin Infrastructure upon which EATS is built.
The Resource Provider which implements the RTI will need to implement the “game engine.” In addition, it will need to handle a number of message flow management streams:
- Internal flows between the engine and the federates, and between federates. At least two message queues will be needed, one to queue messages to be processed in the same simulation cycle as they were generated, and one to post messages to be handled in future cycles.
- External flows between clients and client proxy federates.
- External flows between federates and support service routines that are not themselves federates.
The detail scheme for management of these messages needs careful consideration.
Part of the message scheme needs to develop a message addressing scheme that is capable of dynamically creating a message table and identifying object instances associated with messages.
A federate, in HLA parlance, is one cooperating element in a federation (a related group of software components that cooperate with each other) [to achieve a simulation execution]. HLA assumes that components implementing simulation objects and the RTI are all operating as independent processes, possibly on independent machines, and using some communications protocol as specified by the RTI (e.g., HTTP) to interact with one another. Relative to this it “includes standardized APIs for the ‘RTI Ambassador’ and ‘Federate Ambassador,’ which is the interface of the federate to the RTI and vice versa.” The scheme is shown in Figure 2. The federate talks to the RTI by using the RTI manufacturer’s RTI Ambassador, which knows the protocol for talking to the RTI. If the RTI must talk to the federate it does so via the Federate Ambassador which executes a standardized “callback” in the federate. Swapping “Ambassador” components allows a federate to participate in Federations executed by different manufacturer’s RTIs.
Federates in the EATS Simulator Facility are not independent run units. They are standard EATS Architected Service Provider modules. They may be distributed and run on disparate machines, but they are unaware of this. They are encapsulated and operate using an Inversion of Control design principle. All communications are accomplished using standardized API’s. They are invoked as “event handlers” to process messages (service requests), which may represent new requests or responses to lower level requests for service. They maintain state between calls by means of “save areas” which are supported by the EATS infrastructure. All out-bound communications are accomplished via calls using standard APIs provided by the EATS infrastructure. The Ambassador concept for Federates implemented within the EATS Simulator is embedded in the simulator API.
Similar to the implementation model for the AIR Repository, the EATS Simulator Facility implements a cascaded set of standardized federates which are ultimately subclasses of the core module: C_AF_ServiceProvider. For convenience purposes a specialized extension, the abstract class C_AF_SimulationServiceProvider, is provided which accomplishes the majority of overhead code interfacing with the infrastructure. This allows extension of C_AF_ SimulationServiceProvider to focus on the primary business function of the class being simulated.
Federate structure and composition is specified in two parts:
- The static specification of the model is accomplished via elements in the EATS Repository. This includes both the conceptual elements configuring the model (which only have value as model configuration elements), and the model element entity specifications which may serve double duty as both specifications for the simulation and documentation of the entities in terms of their role within the system being modeled. The design for this is specified in Simulated System Representation below.
- The dynamics of the model element is implemented in the C_AF_SimulationServiceProvider which implements the dynamics of the entities during the simulation. These may take the form of standardized routines with simulation logic appropriate to a class of entities, or they may be specialized routines designed to simulate a particular type of element.
The “state” of any particular object within the model is maintained in the “save area” used by the C_AF_SimulationServiceProvider to service events associated with that particular object.
The HLA OMT specification identifies the following elements as the components of an HLA object model (FOM or SOM)., although, in some cases a table may be empty:
- Object model identification table: to associate important identifying information with the HLA object model
- Object class structure table: to record the namespace of all simulation/federation object classes and to describe their class-subclass relationships
- Interaction class structure table: to record the namespace of all simulation/federation interaction classes and to describe their class-subclass relationships
- Attribute table: to specify features of object attributes in a simulation/federation
- Parameter table: to specify features of interaction parameters in a simulation/federation
- Routing space table: to specify routing spaces for object attributes and interactions in a federation
- FOM/SOM lexicon: to define all of the terms used in the tables
Figure 3 below shows the high level conceptual design solution for model representation within EATS.
The box at the top of the figure depicts a generic “system” described as a series of inter-related entities and associations. This represents the hypothetical system to be modeled.
All elements within EATS are defined as EATS Entities. These include elementary components as well as composite systems. A key characteristic of EATS is that any one element is defined only one time, although that definition may be expanded on and have unique attributes associated with it that are derived from only one of a variety of views which incorporate the element as an entity. In this way a single entity has a globally unique identity and it can be recognized as the same thing when seen from multiple perspectives and used within multiple applications. This singular identify for a singular entity is part of what helps the discovery of connections between element systems and allows reconciliation between multiple models or viewpoints of similar or overlapping systems.
The simulation facility within EATS is not intended as a principal means of building distinct and separate simulation models. That is to say, EATS is not designed as a direct competitive alternative to software simulation systems. Rather it is intended as a means of providing simulated dynamism and animation to architectural models of systems that are already defined within the EATS knowledgebase. It is a facility which allows for analyzing those models under simulated operating conditions.
Returning to Figure 3 above, the rectangle at the top of the figure labeled The System defines some system to be modeled whose architecture has been documented in the EATS knowledgebase. In the lower left of the figure is a UML diagram in a box labeled Description of System Elements. The UML diagram shows, in a simplified manner, how the architectural elements are described in the knowledgebase. Each element (entity or relationship) of The System is identified as an Element in the knowledgebase with a unique identifier, and their relationships to each other are also defined. For every system specification in which the element plays a role, this same element is referenced using that same identifier. The Element is also identified as having a unique Element Type and elements of that Element Type are identified as having a set of associated Behaviors.
Using this scheme all of the elements of The System are cataloged and mapped with respect to how they relate to one another and with respect to their types and behaviors. (The System itself is an Element of the Element Type System, and each of the entities and relationships that make up The System are defined as constituent parts via other Elements which specify composition relationships.) The knowledgebase is an aggregate store of element information. It includes both the specifications about elements that represent real world elements to be tracked or modeled as well as metadata about the elements, data about data, and data about the metadata (meta-metadata).
The choice to perform a simulation concerning some subset of data in the knowledgebase requires the specification of a simulation model, which is an instance of a particular type of model. The specification for the simulation model, by reference, would specify which part or parts of the full system specification are to be simulated. This is also specified in the knowledgebase using the construct shown in the middle of the lower portion of Figure 3 identified as Model Instance.
- Model Type, Model and Model Element are all Elements within the knowledgebase.
- Model Type is an Element of type Element Type and defines the type of the Model. As a Simulation Model it defines the Model to have certain characteristics and it defines a set Behaviors for the Model, these include mechanisms for configuration and execution.
- Model is an Element of type Simulation Model. It defines the unique identity of the simulation model to be specified and executed. This is the primary element which we create when we decide to create a new simulation model.
- Model Elements define the detail elements in the model. Model Elements provide surrogates for the Elements within The System for purposes of tracking and recording their state and behavior in the operation of the simulation model. However, each Model Element also knows and identifies the Element which it represents, and adopts, or inherits, its behavior and relationships from that Element.
Instantiation of a Simulation Model is accomplished by selecting a Simulation Model Type as the type of element to be created. The Element Type (Simulation Model) defines the characteristics of what is to be instantiated and becomes the type of the new element. The configuration process, tailored for the Simulation Model Type, is then used to create the Model Elements and correlate them to the Elements of The System which they represent.
At this point we’ve created a specification for a static model.
Simulation models are dynamic. This is a characteristic or the Simulation Model Type. What this means to EATS is that a Model of the Simulation Model Type will respond to a Run action command. That Run action will then cause certain behavioral activity to occur within the run-time system. This activity, when properly specified, provides a simulation of related activity that might or would occur in an instance of the actual system in the real world.
Running a simulation model creates an Run Instance which is used to track the execution of the model. This is shown in the lower right portion of Figure 3. Multiple Run Instances may be created to show the effects of running the model under different parameter settings, or to see the effects of other changes to the model. Run Instances may also be stopped and restarted. Each separate Run Instance defines a set of Run Instance Elements which track the state and statistics for the Model Elements specific to that Run Instance. Run Instance Elements match off to Model Elements on a one-for-one basis. Population of Run Instance Elements is a mechanical process. They exist simply to keep the execution of each Run Instance separated and easy to manage. This also allows for multiple Run Instances of long running models to be executed in parallel.
What we have then is all elements of an instance of The System exist as elements within the EATS knowledgebase. In addition, all metadata about the elements in The System are also elements in the knowledgebase. When a simulation model is specified over a portion of The System, the elements created as part of the instantiation and execution of the simulation model are also created in the EATS knowledgebase as are all metadata elements defining those elements.
The UML model in Figure 3 shows the semantic navigation mapping between the simulation model and its result set, and the original elements within The System. These semantic mappings can be read in either direction. During execution of the simulation this allows the simulation process to infer actions (behaviors) of the simulation model elements based on the specifications of The System. This also allows later inquiries regarding one or more portions of The System to incorporate results of one or more simulation runs as input to analysis of The System, potentially for control or modification or other purposes. Another benefit of this integrated approach is the ability to cross-edit the simulation model elements to The System and vice-versa, and to draw attention to areas where discrepancies may occur.
The EATS Infrastructure structures application processing according to the classical three tier processing model:
- Presentation Tier – involving the interface between the client and the processing layer. The intent of the isolation of the Presentation Tier is to force processing logic, to the extent practical, to be developed independent of any particular client interaction style. This includes the ability of system processes to be able to be delivered for consumption by other applications on a client-server basis. For presentation logic delivered by EATS applications, this typically involves development using an MVC (Model, View, Controller) style where the Model is split into two parts:
- A front-end proxy portion in the visualization developed as an abstraction and caching mechanism which interfaces with
- A back-end processing portion to be delivered from a potentially remote instance of the system.
- Processing Tier – this is the processing logic tier. This is where large, complex stores of data are maintained and where potentially distributed algorithms are applied to data. This is where requests for services are managed and fulfilled. Everything that occurs in this tier is approached as a service request on some object. Complex requests are cascaded into their constituent parts here. Distributed requests are fanned out and their results are aggregated here.
- Persistence Tier – this is where both the working and long-term memory of the system is maintained. Persistence included both the recording and management of information in databases managed by the EATS applications, and in the communication of data retrieval or archival requests to external systems which may be the system-of-record for data retention.
The EATS Simulation Facility is architected principally as a Processing Tier facility. It is controlled from and visually presented in the Presentation Tier, and it maintains state using facilities of the Persistence Tier; but it primarily executes in the Processing Tier.
The initial development of Presentation Tier code for the simulation facility will occur in the form of a “perspective” executed within an EATS Workbench, an Eclipse RCP framework. The EATS Workbench provides a rich JavaFX GUI framework for the provision of human interface technology to provide both editors and visualization schemes for interacting with and visualizing the model. The key design criteria imposed here is that all simulation processing logic, and logic which interacts with the persistence tier, will be implemented through a standard EATS asynchronous message layer which communicates with processing that occurs off of the GUI interface thread. Effectively the executing simulation model and it’s “viewer” are operating on two separated execution loops which are connected by an asynchronous messaging system. This is shown graphically in Figure 4.
Technically, the processes in the Presentation Tier are not part of “the model,” although what happens here may influence and/or reflect “the model.” Management actions originated in the Presentation Tier (e.g., start, pause, resume, stop) are communicated to the simulation loop via the asynchronous requests. These requests will be directed to the management federate within the model for action. The EATS Simulation Facility also provides for the ability of a Presentation Tier client to view the model while it is executing, and the ability to engage with the model as an active agent. This is accomplished via asynchronous communications between the Presentation Tier client and a client proxy federate within the model. The client proxy federate actively engages with the model (in model synchronized time) to monitor and report on, or to engage in, model activities. If a client simply wants to view the model as it executes, the client proxy federate participates in the model as an observer. If the client wants to engage in model execution processes (e.g., control detail objects within the model), the client proxy federate engages as an active entity within the Federation Object Model. The results of such engagement are reported by to the Presentation Tier via asynchronous responses.
The animation loop in the Presentation Tier operates independently of the Simulation Loop. Part of this independence includes the “frame rate” for the visualization versus the simulation rate for the model. The client can “slow down” model execution to make it appear in slow motion, however, the client cannot speed up model execution faster than the ability of simulation loop components to accomplish their specified activities. Continuous event simulations such as system dynamics models will have a maximum speed that is specified by their step time, but they may run slower if model computations take longer than the step time to complete the computation for all model entities. With discrete event simulation the simulation loop will not obey any regular time interval and a choice must be made how to reflect that in the animation loop frame rate. A regular animation period can be “forced” by inserting regular visualization events into otherwise random event schedule.
Given this separation and the use of proxy federates it is possible for a single client to open multiple proxy federates in the same model to obtain multiple simultaneous views of model execution. This can be done to view different regions of the model space at the same time, such as a wide-area view and a zoomed in view, or a model of a factory and a zoomed in view of a facility within the factory.
It may be desirable at some later stage to implement a second set of Presentation Tier code for the simulation model which allows for delivery of the simulation modeling feature over a web-based interface. If that is desired, the Processing and Persistence Tier code should be unaffected. In fact, it would be desirable to be able to interact with the same model from multiple client environments which may include any mixture of desktop and web-based technology for the Presentation Tier. This design objective is one of the reasons for the distributed approach taken in the EATS Infrastructure design and the tiered framework.
Model processing in EATS is accomplished by software elements known as Architected Services. These elements are oblivious to presentation details. By design specification these processing elements are also oblivious to the technical details of model persistence.
The first tier of processing services are started by one of two methods:
- They are started in response to a request for the service by an element in the Presentation Tier.
- They are started in response to an automated request for a routine or periodic service.
When processing services have the need to access or otherwise interact with persisted data, for example to store new data, they accomplish that task through requests to other Architected Services which serve as Resource Providers over the persistent data in the knowledgebase.
Requests for processing services may be either transitory or they may involve the need for an ongoing communications session between the requester and the service provider.
Transitory requests (those that need a simple response and do not need an ongoing session) and the initial requests that open sessions are formed and routed the same way. Routing is accomplished using an object/method pair to address a message to make the request. If the request opens a session, follow up messages to the Architected Service processing the conversation are addressed (routed) using the conversation identifier returned as part of the initial response. Using this form of conversational processing, Model components in the Presentation Tier are able to serve as proxies for Model services which occur in the Processing Tier and, in turn, manage interaction with persistence providers in the Persistence Tier.
Figure 5 provides a generic sequence diagram showing the interaction of various simulation model code components across the three tiers. The diagram is simplified to show only how the various parts of the simulation model function are interacting and does not show how those interactions occur through EATS Infrastructure and the EATS Simulation Facility RTI components. It is also not specific to any particular function being modeled, but does depict client engagement in the model execution rather than model management activities.
In this diagram the Client Model component represents the Model portion of an MVC pattern Presentation Tier element. This element executes on the GUI thread. It provides the data behind what appears on the interface with the user. In this diagram the client interface might be either via a thick desktop client, a web delivered client, or the client could be an application connecting on a client-server basis. The Client Model portion of the code operates exclusively against the Client Proxy Federate portion of the code which is executing in a separate background thread. The responsibility of the Client Model is to cache that portion of the simulation model data that is required to support the current user interface activity, and to relay user interface information requests or change activity against the simulation model, as appropriate, to the Client Proxy Federate for execution.
The Client Proxy Federate executes in the Processing Tier and represents the whole of the simulation model functional code to the Client Model. The responsibility of the Client Proxy Federate is to coordinate the implementation of all service requests on the simulation model as needed to fulfill the needs of the client, and to communicate the results of those actions back to the client. Tasks such as:
- Adjust throttle
- Correct course
- Fire weapon
If the federate were the MOM, these would be tasks such as:
- Assemble and configure the model
- Edit model parts
- Start, pause, resume or stop the simulation execution
- Save the model
The Client Proxy Federate and the remaining elements to the right in the sequence diagram are implemented as routine EATS Architected Service routines. The labeling in the diagram indicates that all of these components are model federates, but that is not necessarily the case. When federates communicate with other federates, all communications must be routed through the RTI. But federates, as EATS architected services, can also enlist other, non-simulation specific, architected services to accomplish their function as long as all parts of the cascade can be considered to be internal to the service being provided by federate and not affecting other portions of the simulation. These interactions will also occur via architected messages but will simply be processed by the core EATS infrastructure. In this manner a “single” federate may be constructed as a set of cascaded EATS service modules. All of these elements may be configured to operate on the same node as the Client Model, or they may be configured to execute distributed on one or more remote nodes. The interfaces between these entities are accomplished through message passing. These messages may be all local, all remote, or any combination. Implementation of these Architected Service routines and the communications between them follow the standard pattern for these elements operating within the EATS Infrastructure framework.
The elements of Figure 5 that are specific to the simulation model processing that warrant special note are the operation and function of the Client Proxy Federate and Persist Proxy elements, and how they relate to both the Client Model and the remaining processing tier elements labeled Simulation Federate 1, 2 … n.
Client Proxy Federate is an abstraction and encapsulation of the simulation model from the perspective of Client Model. Each unique instance of Client Model will create a separate contextual instance of Process Model which will reflect the specific version and run instance, or run instance collection, of the model as represented in that Client Model‘s visualization. In a similar manner Persist Proxy is an abstraction and encapsulation of the information content of the simulation model as persisted in the Model Repository. It serves as an abstraction and proxy for interaction with the repository, or various repositories, in which the actual model information may be recorded. It also provides, via the conversational interface opened by Client Proxy Federate, a common view of the simulation model which can be shared and coordinated across all activities managed under the Client Model conversation with Client Proxy Federate. These include the various activities accomplished by Simulation Federate 1, 2 … n.
They key to this making this coordination work is the use of conversational messages which are tied to processing contexts that are shared between the various functional units shown in Figure 5, especially Process Comp 1, 2 … n.
All of the activity shown in Figure 5Error! Reference source not found., hypothetically, takes place under a single long running, conversational session between a particular instance of Client Model and contextual instance of Client Proxy Federate. (For this discussion, Client Model is assumed to be an in memory instance of some Client Model class. Client Proxy Federate is an Architected Service routine operating under the EATS Infrastructure whose unique information state is maintained in a unique data context associated with the conversational session established by the original client service request.) This means that all subsequent requests, after the opening request, inherit the context of the opening request and the current information state of that in-process service.
- The opening service request from Client Model to Client Proxy Federate establishes a conversational session. All subsequent messages from Client Model are directed to the same contextual conversation (session, and therefore information context) with Client Proxy Federate by virtue of using the conversational session identifier as the routing mechanism for the resolution of the messages.
- Parameters in the opening service request identify which model, if any, the client wants to interact with. This may involve a statement that a new model is to be constructed, some specific existing model or some specific run instance of a specific model is to be viewed, or it may identify the beginning of a search process that will be used to discover the specific model. These parameters will dictate the nature of the service request which Client Proxy Federate will direct to Persist Proxy to support this conversation.
- Persist Proxy provides a similar abstraction of the informational content of the simulation model for Client Proxy Federate and the remainder of the processing services as Client Proxy Federate does for Client Model and the presentation tier components. The opening service request from Client Proxy Federate to Persist Proxy establishes the conversational session through which all subsequent requests against the information model for the simulation model will be satisfied. In addition, just as Client Proxy Federate provides a facade which hides the details of the processing environment for Client Model, Persist Proxy provides a facade which hides the details of the persistence framework for the processing services.
- Once a contextual framework defining the specifics of the simulation model to be operated on has been established, the client, operating through Client Model, directs the activity of the system. As notes above, these may consist of various tasks such as editing the model, configuring the model, or running simulations.
- For those tasks which involve more than simple presentation adjustments Client Model will make service requests to Client Proxy Federate using the conversational ID that was established in the opening service request. This ensures that the correct simulation context is used to process the new request. This context retains state information about the dialog as various requests are made and processed, and it retains awareness of the conversation session ID with Persist Proxy which is to be used to deal with any actions which require persistence processing.
The Simulation Facility is divided into two primary EATS plugin features. These are optional elements for a vanilla EATS Workbench (desktop or server). If incorporated into the base configuration, or downloaded and incorporated into a functional workbench, the simulation features will become part of the workbench capabilities.
- The EATS Simulator Facility Feature (net.architectedfutures.eats.simulator.feature) implements the Processing Tier features of the simulator.
- The EATS Simulation Client Feature (net.architectedfutures.eats.simulation.client.feature) implements the default client perspective required to manage or execute a simulation from the Presentation Tier.
These two feature sets define the core of the simulation facility and a minimum feature set (with dependencies) required to run simulations. The Simulation Client Feature is automatically included in any workbench which incorporates the Simulation Facility Feature in order to insure a user capability is available for management of the Simulation Facility.
The features are discovered using standard Eclipse plugin discovery techniques and lazy loaded when first used. The simulation feature is loaded as a ResourceProvider in conformance with the net.architectedfutures.eats.core extension point net.architectedfutures.eats.extensionpoint.resource. The client feature is loaded as a Perspective in conformance with the net.architectedfutures.eats.core.ui extension point net.architectedfutures.eats.extensionpoint.toolperspective. The client feature locates the simulation facility via standard EATS services discovery. Both facilities depend on the existence of a shared AIR Repository for model configuration and content specification.
The EATS Simulator Facility (Simulator) is implemented as a Resource Provider. Standard EATS processing is event-driven based on service request messages. This means that when there are no active service requests, the component is dormant. Implementation as a Resource Provider means the Simulator runs on its own thread and is message driven asynchronously. It is free to engage thread cycles any way it wants. The Simulator is also event driven, but driving events are based on an artificial clock and/or simulation activity. The general objective of the Simulator, unless gated by a desire to match a user defined frame-rate, is to drive a simulation to achieve “the end of (simulation) time” as rapidly as possible. In a free running simulation the Simulator will attempt to consume all CPU cycles by generating one event after another and advancing its simulation clock until the simulation is complete. Completion is determined by achieving a predetermined number of cycles, a simulated time horizon, or a simulation ending terminal event.
Simulation time within the Simulator may proceed using a continuous or discrete concept of time management, based on the type of model being run. System dynamics models are based on modeling time as a continuous flow. However, even SD models are processed, ultimately, as discrete time intervals with a consistent increment occurring in each cycle.
We need to establish an “insignificance time” for the simulation run. Things that take less than the insignificance time can be considered to happen instantaneously and take no time. Things that take longer need to be processed by the Simulation Engine time management facility. This can allow the model to automatically adjust how it operates based on the engine cycle time. (Messages can be sent “same cycle” or on a deferred cycle basis. Processes can be split over multiple cycles, or all run “in an instant.”)
Locally controlled continuous time management is specified by specifying a simulation step time interval and analysis algorithm for integration. In this case the Simulation Engine will generate consistent time alerts at regular intervals as specified by the step time. Otherwise, time is managed as passing at random sized intervals based on the event alerts generated as a function of the simulation logic.
Externally managed time can be used if the simulator is to be considered a federate in a larger federation where some external RTI is responsible for time management. In that case, the external RTI must pulse the Simulator to advance the simulation clock. If externally controlled modeling is desired, the external time manager must send a message to initiate a clock cycle, and wait for a response that indicates all cycle activity has completed before beginning the next cycle. For discrete event simulations the external manager may request that the completion notice also include a notification of when the next event in the local federation is anticipated to occur.
The Simulation Engine is the driver process that runs the simulation. It is responsible for maintaining the simulated clock, generating time based events and cycling through scripted events.
The Federated Object Model (FOM) describes and defines the objects of the simulation. In the HLA the FOM is an external specification. IN EATS, the object set is externally specified as a set of Model Elements as shown in Figure 3, above, but the model composition itself, as well as the specifications concerning remaining element details, is obtained from the specification of the model and the model elements in the AIR Repository. As these specifications change the model is automatically updated to incorporate them.
Federates in the Simulator are implemented as Agents, entities that interact with the world.
- Federates are a sub-class of entities. Entities define all of the “things” (objects) in the simulation.
- Federates “own” themselves. They may also “own” other objects.
- Federates are implemented by specialized EATS Service Providers. Processing logic for a federate is generic according to Agent type. Individual federates are distinguished by their state.
- State for a federate is maintained externally in a context document, which is a subclass of an architected EATS element.
- The specification for the federate Agent type is also specified as an architected EATS entity specification in the AIR Repository.
The structure of these specifications is according to the high-level model shown in Figure 3. The consistency of following this model and the use of standardized base-level service provider modules for common high-level entity types is what allows simplified simulation models to be automatically constructed and executed for systems defined in the AIR Repository. In addition to these standardized models, more specific models may be created with specialized behaviors by extending the baseline simulation service provider modules for individual entity types.
The standard methodology for inter-federate communication in HLA is event publish/subscription via the RTI. It is important to implement this technology in order to provide for possible future integration with other HLA-based engines.
- Subscription comes first. It is the registration of a listener, an observer.
- Publication is second.
- We can handle subscriptions as a list of the subscription messages. Publication then consists of running this list and sending the current state update to all subscribers as a reply to their original subscription message.
- Unsubscribe removes the original from the list and closes the conversation.
EATS is a message-based, event driven platform and the architecture standards provide two schemes for addressing messages:
- Messages which open conversations are addressed using Object-Action addressing.
- Messages which continue conversations use the conversation ID for addressing.
Messages of type 1 are handled by the EATS infrastructure using the system’s service routing tables to locate the appropriate node and service provider to service the message. It is the option of the service provider, indicated by their response type, to either terminate the conversation with the client when the response is sent, or to retain an open conversion (to be terminated at some later time). The infrastructure monitors this option; and, if the conversation is to remain open, retains routing information associated with the conversation ID. This allows subsequent messages of type 2 to flow to the same service provider without regard to the Object-Action content specification. This is true even if multiple nodes are required to be traversed between the originating client and the service provider with whom the client has established the conversation.
The operation of the simulation facility requires the following message flow patterns:
- Clients need to converse with the Simulation Facility to configure models and to start, pause, resume and stop simulation executions; or to observe or participate in the simulation execution.
- The Simulation Engine, or the federates, needs to converse with external EATS services. This includes conversations with the AIR Repository to obtain specifications concerning models and model elements, and potentially to save and restore state for models.
- The Simulation Facility needs to converse with federates in the execution of the model. These conversations may have 3 points of origin:
- The simulation client,
- The Simulation Engine, and
- One of the federates.
Client conversation to configure a model establishes a simulation set based on a particular model. This is similar to launching an HLA RTI with a specific Federated Object Model (FOM). The result is a Run Instance of the simulation of a particular system. The parameters at the time of configuration may call for the execution to be automatically started, run for a period and stopped; or to be controlled manually (externally). The result of the configuration request will open a conversation with the client and establish a conversation ID. That ID is used as the basis for further client management actions on that simulation (e.g., start, stop, query results). If controlled externally, it is possible for the
If a client wishes to observe or participate in the simulation, then the configuration parameters should specify client directed start/stop rather than automatic. This gives the client the opportunity to request one or more client federates of the appropriate type be established to participate in the execution exercise. General statistical results can be reviewed after a simulation completes with or without client participation in the execution.
The original transaction to configure the simulation is an Object-Action addressing type message, and the client’s local EATS infrastructure will assign it to an appropriate EATS node configured with a Simulation Facility. The Simulation Facility will respond with the Run Instance GUID of the configured simulation and subsequent messages associated with this simulation will use the GUID with conversation ID addressing messages. Thus all subsequent messages will be directed to the same Simulation Facility.
Client messages to the Simulation Facility are no different for the client than any other message to any other service provider. The same send and receive mechanisms and techniques are used.
For the Simulation Facility these messages are seen as originating from an EATS service manager, and responses must be returned via the same facility. In this regard the Simulation Facility is behaving in the same manner as any other service provider. The only issue is distinguishing these conversations with “environmental actors” from the Simulation Facility’s internal message traffic.
Client participation in a simulation occurs in one of three modes:
- If the client has not assumed ownership of the clock, then client messages interface with the simulation at whatever randomized clock cycle may occur when the message appears.
- If the client has assumed ownership of the simulation clock, for example if the “client” is the RTI of a higher level simulation, then the client has control of what clock cycle the client messages occur within.
- A client proxy federate may be programmed to await the arrival of specific client messages before announcing that is has completed all of the required processing for the current cycle. In this case, the entire simulation will be suspended until the arrival of the pending message. While not valid in a multi-user gaming scenario, this can be useful in selected simulations where user directed decisions are to be incorporated into the simulation logic based on dynamic simulated environmental factors.
The first mode is typical for most simulations, and the second mode is typical for hierarchically cascaded simulations.
Conversations between the Simulation Facility, either the RTI or a federate, and external architected EATS services are handled as “instantaneous” activity within the scope of a simulation cycle. These conversations are initiated by a Simulation component making a standard EATS request for an architected service. They are terminated when the architected conversation completes. All such requests are either made by, or through, the Simulation Facility. The Simulator monitors this message traffic and holds cycle activity “open” until all such conversations have been completed.
These conversations include all communications:
- All communication from the Simulator to a federate,
- From a federate to the simulator, and/or
- From a federate to another federate.
These conversation implement the core of the execution of the simulation. The driver for this activity is the Simulation Engine within the Simulator. The Simulation Engine is an instance of an EATS Resource Provider (derived from C_AF_ResourceProvider). Resource Providers are modeled after, and partially derived from, the EATS Component Services Mediator (CSM) framework. In EATS the CSM performs architected message routing services. As such, it also provides that role in support of simulations for Client – Simulation Facility Conversations, and Simulation Facility – EATS Service Provider Conversations. These external interface messages follow the normal EATS conceptual framework of service requests. Internal Simulation messages may include this pattern, but they also include messages that are slightly different in purpose: simulated event notification/driver messages.
Federates tend to come in two forms:
- Management / Analysis Processors
- Simulation Agents
The Management / Analysis Processors are responsible for management of the simulation, or for gathering data about the simulation and reporting that data back in response to a request for information. These federates operate very similar to standard EATS service providers.
Simulation Agents are a specialized subclass. Their mission is to actually execute the simulation. They are the actors in the simulation. In the course of a simulation run, these agents may create and/or destroy other agents. These are not simply “helper services” as is the case with the creation of a normal service process to fulfill a service request. Each created Agent is a fully enabled entity in the Simulation. The Simulation Engine is responsible for managing the population of these Agents, exposing their environment to them (allows Agents to discover one another), managing their participation in the execution of the simulation as it evolves, and managing the cross-communications between Agents.
The high-level design of the Simulation Client Feature is similar to the Element Type Perspective in the AIR Tools perspective category which is used as a general editor facility for AIR Repository elements.
- On opening, the wizard provides for the selection of a Model Type as depicted in the Model Instance block of Figure 3 on page . This is based on a determination of the available types from the “local” AIR Repository. Model types are generic in nature. For example, System Dynamics Model.
- Given a Model Type, the user is asked to select from a list of defined models of the specified type. Defines models are models that have been previously created and cataloged that conform to the type specification. For example, the Forester World Model.
- Given a model, the wizard attempts to determine if a running instance of the model that can accept observers or participants already exists. If so, the user is appraised of the situation given the option to participate in that instance.
- If there is no running instance, or if the user chooses not to participate, a new instance of the model must be created with the local Simulator RTI. A conversation with the existing or new instance is instantiated using the Simulation Client Perspective ‘s context.
- Finally, the local perspective needs to be launched with a appropriate detail and navigation parts that are linked with the model in the local RTI. The messaging conversation with the RTI started by the wizard is transferred to the perspective for completion.
- The wizard needs to look for a plugin that specializes in the designated model type. Otherwise, if none is found, it needs to climb the class hierarchy for the type and search for a known class of models. If there is a specialist plugin for the model type perspective, that is the one to launch. Otherwise, we launch based on known class type.
The Simulation Client Perspective uses the Navigation Panel to expose the components of the model. The components are maintained as a collection of nested systems. Rather than being directly obtained from the AIR Repository, this collection is maintained via subscription from the Simulator.
This same scenario should also be able to subscribe to a running simulation. However, in that case, rather than setting up a new simulation, the wizard should query for running simulations that allow late join, then join rather than create.
- One or more visualization panels may be opened, depending on the nature of the simulation type. The visualization panels define the viewport canvases that paint the visualization entities exposing the activity of the simulation model. They also provide the point of interface with the user, both via operational controls (buttons, menus, etc.) and via mouse selection or action against entities in the main body of the visualization.
- Client run its own animation thread to reflect model changes on the visualization panel
- Client watches simulation by receiving collection update notices from the simulator
- Additional subscriptions can be accomplished to get histogram data, during or after the simulation execution.
The overall Simulation Facility is implemented as a Resource Provider. That means it self-configures into any EATS Node it happens to be configured into. It then advertises its presence by publishing its services in the local routing tables. These routing tables are available locally in the node, and published to other nodes which may join an EATS federation with this node.
As a Resource Provider it operates on its own thread and it manages a message queue through which it interoperates with the local Service Mediator.
- New requests for services from clients are posted to the Simulation Facility’s Resource Provider Message Queue by the Service Mediator and replies to those requests are posted directly back to the requester.
- Responses are posted to a designated response handler which is identified when the message is created. Typically the message dispatcher for a message provider is designated as the response handler. This happens “cross-thread” and avoids the need to “route” responses.
- Service requests for routine architected services are directed to the Service Mediator and responses are posted back to the simulator that made the request. If the request was made by the Simulation Facility they also appear in the Simulation Facility’s Resource Provider Message Queue.
The Simulation Facility maintains a list of active simulations within its purview. Just as the Service Mediator’s role is primarily high level message routing, the top level of the Simulation Facility is primarily concerned with managing simulators, not executing simulations. Each simulator also executes on its own thread. Simulators are created by the Simulation Facility to manage and execute simulations.
Each Simulator, once established, operates its own message queue and is responsible for its own resources. Each Simulator functions as an independent HLA RTI. Simulators tend to be implemented by simulation type. Simulators are implemented as plugin extensions to the Simulation Facility, just as the Simulation Facility is implemented as a plugin extension to the EATS node. The types of extensions made available in a node determines the type of models a Simulation Facility will advertise it is capable of handling when it advertises its presence by publishing its services in the local routing tables.
EATS Simulators are derived from an abstract simulator which implements most of the logic of how simulators interact with the EATS infrastructure and the EATS Simulation Facility. The specifics of individual simulators has to do with the nature of the types of systems they simulate (Monte Carlo simulation, System Dynamics, etc.).
- Message Handling
- Simulation Engine / Driver Logic
- Parts (Entities) management (using entity-base)
- FSM base
- Filling in model part from repository
- creating collections and assembling parts and element models
- How to handle the identification and load of federate processor modules for entity logic using extension points
- Creation and handling of variables using Expr4J
- Continuous vs discrete event modeling – can an aggregator pull these two together?
- Wentworth BATSG1 model
- Agent Based Model
- System Dynamic Stock & Flow Model
- Geographic (spatial) model – motion through space
- Baseline modules to perform standardized logic for standardized logical entities (e.g., factory, something that combines inputs to create an output)
- Module extensions for hybrid element types (e.g., gives standardized unit specific and detailed algorithms and behaviors)
Simulation elements refers to the objects that define the elements of the simulation. These are the animate and inanimate entities that make up the simulated system. They are the entities that constitute the set of items at the bottom of Model Instance box in Figure 3. They are described by items in the Description of System Elements box and have their behavior implemented by the EATS Software Element items in the lower left corner. The implementation instances of these items are defined by the contents of the Run Instance box. The Simulation Facility should programmatically own all object specifications defining all elements in a Simulation Dictionary. In addition, it should programmatically “own” all behavior modules.
- Most of these elements describe types or rules. They do not change as a result of model execution. There is no need for multiple copies.
- Even the programs can be shared. They are designed a reusable software units. State is not maintained internally in an architected service module, it is maintained externally in a service context.
All of these elements, along with contexts, messages and other critical structures and mechanisms are uniquely identified by EATS GUIDs.
A “Run Instance” is a context that defines state within a particular contextual framework. They require ownership in terms of federation in order to manage the orderly flow of execution within the simulation. The HLA API for object ownership can be used to implement this, as well as which federate may “own” a particular element at any point in time.
Model can be implemented more than once, e.g., simulated with different parameters, but shared instance data updates needs to be arbitrated. This same arbitration can also work between federates in a federation.
- Element Types and Models can be shared.
- Element simulation instances need ownership.
- Sharing federates need to subscribe to state changes.
- A job for a simulation instance wrapper over AIR Element defined state. The wrapper might also do state history to support histograms.
EATS’s plugin architecture provides for the dynamic loading of extension modules to allow extension and customization of system functionality. The current infrastructure supporting this architecture is based on Eclipse Extensions. The alternative to this is the use of OSGi Services. The choice of technology, as implemented, is largely hidden in the EATS infrastructure and not visible to the business code in the application; but it is visible to the technical structure of how applications are built. A summary article explaining the two methods can be found in A Comparison of Eclipse Extensions and OSGi Services. A diagram from the article showing the mechanics of the load process is shown in Figure 6.
The effect of this architecture is to allow modules which were compiled, linked and packaged separately from the EATS executables to be able to be dynamically integrated into EATS at runtime. This allows the Simulation Facility Feature to be dynamically added to an EATS runtime where it is lacking, rather than requiring its wholesale replacement. This is shown generically in Figure 7Error! Reference source not found.. The core infrastructure, shown as EATSv4, declares a net.architectedfutures.eats.extensionpoint.resource extension point. At runtime, available modules (those in the plugins directory) declaring and satisfying the requirements of this extension will be loaded dynamically and integrated as Resource Providers in the system. Resource Providers, or other facilities, are in turn free to declare additional extension points in a cascaded manner as shown in the diagram. The Simulation Facility is also constructed of plugin parts using this same technology. This allows simulations to similarly be extended and customized through the use of separately developed components.
The extension mechanisms for implementation and extension of the Simulation Facility on the client side, the presentation layer, is shown in Figure 8.
The Simulation Client is initiated via a perspective wizard as shown in Figure 9. The majority of the framework, shown on the left, is generic. The upper right hand portion of the diagram identifies individual perspective wizards that implement the toolsPerspective extension identified in Figure 8. In the case of the Simulation Client, in the basic package, we use C_AF_SimulationClientSelectionWizard, which implements the toolsPerspective extension and conforms to the C_AF_CascadedWizard interface by extending the C_AF_ CascadedWizard base class. It also follows the model established by the Element Type Editor perspective by extending C_AF_AirItemSelectionWizardPage for dialog pages which lead the user to make selections from element sets in the AIR Repository. The first such selection determines the simulation model type. Given a model type, the second selection determines the model of that type which is to be executed.
Once both a model type and model have been selected, the Wizard is responsible for instantiating the model, if it is not already running, and constructing the client perspective, as shown in Figure 10, through which the user will be able to interact with the model.
Figure 10 shows a generic perspective framework as implemented by a combination of Eclipse and EATS tooling hosting a simulation perspective. The responsibility of the perspective wizard is to populate the blue colored, simulation specific components. Tailoring of the components to be selected is accomplished through the modelPerspective extension identified in Figure 8. If no tailoring is identified for the model type, then generic parts will be used.
- C_AF_SimulationController is the core of the simulation perspective. It provides the interface between the client and the server components and maintains the simulation model as viewed on the client device.
- C_AF_SimulationVisualization is the base class and default implementation for the client viewport into the simulation and provides the primary mechanism for the user to interact with the simulation.
- C_AF_SimulationExplorer is the base class and default implementation for the navigator part for the simulation perspective.
- C_AF_SimulationTools is the base class and default implementation for the optional tools part window which is used to display running log data, search results and other information which is supportive of the content in the main C_AF_SimulationVisualization part area.
The mechanism for implementation and extension of the Simulation Facility on the server side, the processing layer, is shown in Figure 9.
According to http://www.coensys.com/system_dynamics.htm system dynamics models are stock/flow models.
- Stocks are represented by rectangles. They are sometimes referred to as “Levels.” Stocks (or Levels) are defined by nouns and represent the state or condition of the element within the system. Thinking in terms of “Stores” tends to reinforce the concept of Stocks and Levels in relation to quantity: Stocks as things that accumulate (increase or decrease) over time. This leads to examples of stocks including population, water, account balance, inventory, number of employees. Reading Forrester also leads to thinking about “Levels” as a condition of some element within the system, such as “on/off” or “running/not running.” Increase/decrease in this case might be “start/stop.”
- Flows are represented by lopsided “bow tie” symbols. They are also referred to as Rates. They define processes which defines the rate of change in stocks over time, where the content of a stock is moved, increased or decreased by a flow of the stock materials from the stock (store) to some other place, or by some growth or decay pattern exhibited by the Stock itself. They are defined by verbs. Examples of flows include births, deaths, add water, debit, credit, amortize, cash flow, buy, sell, ship, hire rate, etc.
- Sources and sinks define external sources or destinations for stock materials and are represented by clouds. Essentially, they define infinite capacity external stocks that are the source for the materials flowing into the system, or the sink recipient store for stocks moving out of the system.
Stocks, Flows, Sources and Sinks are very easy to reconcile with the elements of BATSIM. But they are not the only elements in a system dynamics model, as shown below in Figure 10.
System Dynamics involves the study of feedback systems. Feedback systems are systems which are influenced by their own behavior. Feedback systems involve closed loop structures such that the results of past actions are evaluated, potentially in combination with new environmental data, to determine what the operating policy of the system should be in the future.
In addition to Stocks, Flows, Sources and Sinks the model shown in Figure 10 has a number of other features which need to be described and reconciled with the design concepts for the EATS simulator. They include:
- Entities which are declared but which are not enclosed in symbols. These include elements such as GDP per capita, innovative demand, etc.
- The significance, relative to a set of visually descriptive rules for the model, of the arrows which are not specified as Flows.
Together these elements define feedback loops. A feedback loop is a closed chain of causal connections from a stock, through a set of decisions or rules or physical laws or actions that are dependent on the level of the stock, and back again through a flow to change the stock. The loops can be stabilizing (balancing feedback) or runaway (reinforcing feedback).
- Feedback loops are directed at flows. They regulate the flow, which in turn impacts the level of the stocks.
- Feedback loops always operate with delays. The amount of delay can be extremely consequential in the operating behavior of the system.
- The diagram also shows
- Variables (unboxed labels)
- “Feedback” from variables to variables
- “Feedback” which flows directly to stocks from either variables or other stocks
For assistance in this last section, see Chapter 7 of Forrester’s Principles of Systems which has some descriptions and definitions for the elements which appear on flow diagrams.
- Rich pictures
- Connection Circles
- Mind Maps
- Causal Loop Diagrams
- Dialogue Maps
- Stock and Flow Diagrams
A video introduction to the system can be found on the SystemsWiki web site. This same page includes links to a whole series of videos which introduce how to use the system to create each of the types of models described above, detailed descriptions and instructions on how to create both types of simulation models, and a full description of each of the tools used in the modeling process.
- Stock With Two Competing Balancing Loops – adapted from “Thinking in Systems.” Demonstrates use of a “converter” to do table lookups.
- Bank Deposit Money Multiplier – Test component for an economic model. Shows multiplier effect of a $100 deposit when placed in the banking system
- System Zoo Models – models adapted from Hartmut Bossel’s System Zoo books showing classical problems in terms of system dynamics models
- Z602 Population with Four Age Groups – demonstrates a population aging through four age groups where subgroups are used to define procreative segment, work-force, etc.
- Animal Foraging Model – defines two populations, one of patches of pasture and one of foraging consumers. The consumers forage in a pasture until the pasture is exhausted. They then need to search for a new pasture. After foraging completes, the pasture regenerates over time.
- Spatially Aware Disease Model – defines a single population spread over a geographic area. Disease spreads, but only to nearby neighbors. As members become infected, non-infected agents attempt to flee.
- The Classic Game of Life – defines a single population where cells transition from alive to dead, or vice-versa, based on the state of neighbor cells.
- http://www.systemswiki.org/index.php?title=Agent_Based_Modeling/Part_1 has a series of references to various papers
For system dynamics models the primary primitives (stocks, flows and variables) are supplied on the Insight Maker tool bar. For Agent-based modeling, you need to right-click on the drawing canvas in order to bring up the primitive selection pop-up in order to make the primary primitives available. Right-clicking brings up a pop-up that looks like the block to the right. This pop-up can be used to create system dynamics items, but it also opens up the ability to generate agent-based modeling primitives. These include:
- States – for the generation of state models to describe a dynamic set of conditions and states for model elements
- Actions – for the specification of model actions that should take place on every clock cycle, or based on conditions
- Agent Populations – for the descritpion of one or more sets of ‘agents’ of various configurations whose behavior may vary based on model conditions.
States and transitions take their normal form as used within state diagrams.
States define conditions or situations which are either true or false. In effect, they are on/off switches. They may be simple true/false statements, or they may be stated in terms of conditional expressions or numbers. If they are stated as conditional expressions, the evaluation of the expression defines the resulting state. If they are stated as numeric values, 0 equates to false, and all other values equate to true.
Transitions operate in a manner similar to flows. They move a ‘state’ from one state item to another under some specified model condition. Transitions are created in the model by ‘dragging’ the ‘link/flow arrow’ (when the tool bar is set to ‘Use Flows’) from one state item to another. Transitions may be triggered by timeouts, probability or conditions. A timeout transition is triggered a fixed amount of time after a state became true. A probability transition makes random selections as to whether it is true or false, based on the specified probability, for each clock cycle of the model. A condition transition works based on a supplied conditional formula.
Actions have two features: triggers and the resulting action. The trigger is optional. If not trigger condition is specified, the action will take place on every clock cycle. The action portion defines what action should be taken when the trigger condition is triggered. Actions may be used to adjust primitive values, to ‘move’ agents, to modify agent connections, etc.
Agent populations are grouping of ‘agents’ of a particular type. Agents are specified as a set of states, transitions, stocks and flows which are grouped into the scope of a ‘folder’ primitive which is assigned an “Agent’ extension type. Agent populations are created as primitives of their own type. They are then assigned a specific behavior type in their configuration by assigning them to one of the agent types defined by the ‘Agent’ folders.
Given a type, Agent populations are assigned a population size which defines how many of the assigned agent types exist within the population. They may also be assigned a ‘position’ within an agent geometry and they may be assigned a network attribute.
Agent populations have a set of Geometry properties when they are created. There are 6 attributes which can be specified.
- Dimension Units – these default to unitless, but can be changed to any desired unit. It can define distance, or some other form of dimension.
- Height – this specifies the size of one side of a two dimensional matrix defining the geometric space.
- Width – this specifies the size of the second side of the two dimensional space defining the geometric area.
- Wrap Around – Yes/No, this defines whether or not the geometry is considered flat, with edges, or continuous where leaving on the right causes re-entry on the left, etc.
- Placement Method – defines how agents are placed into the space. The options are:
- Random – the default, agents are placed randomly within the geometry defined space.
- Grid – agents are placed in a uniform grid pattern within the geometry defined space.
- Ellipse – agents are arranged around the perimeter of an ellipse within the geometry defined space.
- Custom Function
- Custom Function – provides the mechanism to define the custom function for the placement method.
In addition to the geographic (matrix) geometry a second network geometry may be defined for the agent population. This geometry is entirely defined through the specification of a custom function.
Macros can be defined using the Macros feature in the Tools section of the toolbar. This discussion item shows one method for creating a global variable that can be accessed across function calls.
Equation functions are arranged into groups according to the following categories:
- Random Numbers
These include the ability to specify most routine mathematical functions that can be found in Excel or most other systems: rounding, trig functions, logs, sums, min, max, mean, standard deviations, mod, square roots, etc. and standard math constants: pi and e
These include standard time function conversions, current time, start time, end time, step time, time length
These provide a series of functions for dealing with historical values associated with a primitive on a instance or statistical basis
These provide a series of function for the generation of random numbers under a series of different constraints or methods: uniform, Poisson distribution, triangular distribution, exponential distributions, etc.
These provide a set of function for dealing with agent populations. They include:
- FindAll([Agent Population]) returns a vector of all the agents in the specified agent population.
- FindState([Agent Population], [State]) returns a vector of all agents in the specified population that are in the specified state.
- FindNotState([Agent Population], [State]) returns a vector of all agents in the specified population that are NOT in the specified state.
- FindIndex([Agent Population], Index) returns the agent from the specified population which is positioned at the specified index. Index values start with 1.
- FindNearby([Agent Population], [Target], Distance) returns a vector of agents that are within the specified distance of a target agent.
- FindNearest([Agent Population], [Target], Count=1) returns the nearest agents to the target agent. The number of agents returned is specified by the optional Count.
- FindFurthest([Agent Population], [Target], Count=1) returns the agent farthest from the target agent. The number of agents returned is specified by the optional Count.
- Value([Agent Population], [Primitive]) returns the values of the specified primitive for each agent in the population as a vector.
- SetValue([Agent Population], [Primitive], Value) sets the value of the specified primitive for each agent in the population to the given value.
- Location([Agent]) returns the location of an agent as the vector <<x, y>>.
- Distance([Agent 1], [Agent 2]) returns the distance between two agents.
- Move([Agent], <<x, y>>) moves an agent the amount specified.
- MoveTowards([Agent], [Target], Distance) moves an agent towards a target agent the distance specified.
- Connected([Agent]) returns the agents connected in the network to an agent.
- Connect([Agent 1], [Agent 2]) connects two agents in the network. The second parameter can also be a vector of agents.
- Unconnect([Agent 1], [Agent 2]) unconnects two agents in the network. The second parameter can also be a vector of agents.
- PopulationSize([Agent Population]) returns the total number of agents in a population.
- Add([Agent Population], [Base]=Initial Agent) adds a new agent to the population. If [Base] is set, the new agent will be a clone of [Base]. Otherwise the agent will be like a newly created agent at the start of the simulation.
- Remove([Agent]) removes an agent from the population. The agent will no longer be simulated. Can be used to “Kill” an agent.
- Width([Agent Population]) returns the width of the agent population geographic region.
- Height([Agent Population]) returns the height of the agent population geographic region.
These provide a set of functions for dealing with data in vector arrays.
- Count(Vector) counts the number of elements in a vector.
- Join(Item 1, Item 2, Item N) merges items together into a combined vector.
- Flatten(Vector) flattens a vector removing and expanding all nested vectors.
- Unique(Vector) returns a vector with duplicates removed.
- Union(Vector 1, Vector 2) returns the combined elements of two vectors (with duplicates removed).
- Intersection(Vector 1, Vector 2) returns the elements that exist in both vectors.
- Difference(Vector 1, Vector 2) returns the elements that exist in only one of the two vectors.
- Sort(Vector) sorts a vector from smallest value to largest value.
- Reverse(Vector) reverses the ordering of elements in a vector.
- Select(Vector, Items) subsets a vector. Items can be a single index (starting with index 1) or a vector of true/false values of equal length to the Vector.
- Sample(Vector, Sample Size, Allow Repeats=False) takes a random sample from a vector. Allow Repeats specified if the same index can be sampled multiple time and is false by default.
- IndexOf(Vector, Needle) returns the position of the needle within the vector (starting with index 1). If the needle is not found, 0 is returned.
- Contains(Vector, Needle) returns true if the needle is in the vector. Otherwise returns false.
- Repeat(x^2, Times) creates a new vector by repeating a function a specified expression a number of times. <i>x</i> refers to the current index.
- Map(Vector, x^2+1) applies a function to each element of a vector, denoted with <i>x</i>, and returns the result.
- Filter(Vector, x>7) tests each element of a vector using a function and returns the elements which evaluate to true.
Provides the following functions which can be used for variable initialization, conditional logic, etc.
- If…Then…Else to support logical conditions
- Pulse(Time, Height, Width=0, Repeat=-1) creates a pulse input at the specified Time with the specified Height and Width. Height defaults to 1 and Width defaults to 0. Repeat is an optional element that can be used to create a ‘pulse train.’
- Step(Start, Height) creates an input that is initially set to zero. At the time Start the value is set to Height.
- Ramp(Start, Finish, Height) creates a ramp input which moves linearly from 0 to Height between the Start and Finish times. Before Start the value is 0, After Finish the value is Height.
- Stop() to be able to stop the simulation based on some logical condition.
http://www.worldwatch.org/ used as a reference by Helmut Bossel for his dashboard.
http://www.linkedin.com/groups/Finally-Economics-Even-I-Can-2639211.S.165675407 System Thinking World: Gene’s discussion “Economics even I can understand” Starts with link to http://econviz.org/ which has “dumbed down” view of the economy. I also introduced links from Mensa discussion below provided by Guido.
- Macroeconomic Dynamics – Accounting System Dynamics Approach
- Provides a general introduction to system dynamics and stock/flow methods. Explains economics and supply/demand. Explains accounting, then goes into macroeconomic systems of debt money
http://www.linkedin.com/groupItem?view=&gid=641&type=member&item=166023865 LinkedIn discussion on “How the Economy Works” from the Mensa group. Includes Guido’s references to a series of system dynamics models, plus my previous thoughts at the time (this was my discussion)
http://www.linkedin.com/groupItem?view=&gid=641&type=member&item=183068910 LinkedIn Mensa discussion: “What happens when the dollar crashes?”
- A Guide To Learning System Dynamics
- Economic Dynamics for Smarter Cities
- Khan Academy on Macroeconomics – Topics covered in a traditional college level introductory macroeconomics course
- GDP Breakdown of the US
- Bureau of Labor Statistics
- google: “global finance statistics”
- http://www.bis.org/statistics/ Bank for International Settlements has some interesting aggregate statistics showing historical figures for consolidated banking statistics by country over time. Statistics include: banking, securities, derivatives, exchange rates, foreign exchange, external debt, property prices and credit to the private sector. This data might be useful in the event we decide to do any economic modeling.
- https://www.globalfinancialdata.com/index.html contains research database of historical data: equities to 1693, fixed income to 1520, inflation to 1209, commodities to 1252, real estate to 1835, etc. Requires registration. Is supposed to be free, at least on a trial basis.
- https://www.khanacademy.org/science/macroeconomics – Khan Academy videos on macroeconomics: GDP, inflation. monetary system, foreign exchange
- Shadow Banking (Google: “value of assets in the shadow banking system”
- This seems important because to the extent that money is foundational within economics as the medium of exchange, and money is currently created by the banking system – the old notion of reserve banking used to provide a governor on the pace at which banks could do this, and provided an means by which regulators in some form could manage it. Even if the regulators might be viewed to be the bankers themselves, or their agents. However, when liabilities become securitized, what happens to the ability to manage money, and if any form and amount of risk is allowed in the securitization process, because the players are supposed to be ‘informed,’ what happens to the risk injected into the overall economic system. This seems to me to be a key issue exposed by the sub-prime mortgage crisis.
- http://en.wikipedia.org/wiki/Shadow_banking_system – wiki definition
- http://www.imf.org/external/pubs/ft/sdn/2012/sdn1212.pdf – IMF Staff Discussion Note: Shadow Banking: Economics and Policy, has an interesting overview of 2008-based depression caused by mortgage crisis with tables and financial flows.
- http://www.ny.frb.org/research/staff_reports/sr458.pdf – FRB NY staff report on Shadow Banking. Multiple flow models
- http://www.dallasfed.org/assets/documents/research/staff/staff1203.pdf – Dallas FRB Staff Report: Understanding the Risks Inherent in Shadow Banking: A Primer and Practical Lessons Learned – 2 years after the NY Fed report, looks to include some of the basic models but presented from a much more readable perspective. Appendices include very good explanations of things like securitization. CDOs, interest rate swaps, etc.
- http://www.financialstabilityboard.org/publications/r_121118c.pdf 2012 report on shadow banking at a global level
- http://www.deloitte.com/assets/Dcom-UnitedStates/Local%20Assets/Documents/CFO_Center_FT/US_FSI_The_Deloitte_Shadow_Banking_052912.pdf – provides index and analysis
- http://www.ecb.int/pub/pdf/scpops/ecbocp133.pdf – shadow banking in the Euro zone
W el lbei
Except these limits aren’t really limits. They are pursuits, assuming there is interest and reason to pursue them. Some of these are statements similar to “doesn’t do everything.” To which the answer is, what does? And, define everything!
ng Metrics Standard for Ethical Artificial Intelligence and Autonomous Systems
- 7010 – Wellbeing Metrics Standard for Ethical Artificial Intelligence and Autonomous Sy
- IEEE P7010 Working Group
- 7000 – Model Process for Addressing Ethical Concerns During System Design
- Even the AIR dictionary is an “infrastructure” tool. It is a useful tool for the system modeler, system architect, system engineer type, but not the “vanilla” social scientist type modeler. Dictionary by itself is not likely to be considered very thrilling. The SD modeler is more the user we want to support as primary. (S)he will consider the dictionary as ancillary, even though the dictionary is what will tie all of the user’s models together and allow them to act as a “dynamic design” modeling environment. ↑
- See David Deutsch – David Deutsch, an award-winning pioneer in the field of quantum computation, argues that explanations have a fundamental place in the universe. They have unlimited scope and power to cause change, and the quest to improve them is the basic regulating principle not only of science but of all successful human endeavor. This stream of ever improving explanations has infinite reach, according to Deutsch: we are subject only to the laws of physics, and they impose no upper boundary to what we can eventually understand, control, and achieve. ↑
- See http://gafferongames.com/game-physics/integration-basics/ ↑
- Eclipse was simply the development IDE, not necessarily the platform. ↑
- TAKT time is the maximum processing time per unit allowed to meet demand. Compute as time available to work per period divided by units required per period = time per unit produced. JIT (just in time) requires actual production rate to match required production rate. ↑
- A simple time delay is represented as an activity where an entity is advanced from one node to another with a deterministic or stochastic time delay, not what we are defining here as a queue. ↑
- An interesting option might be to have a project plan simulation where the entity that moves through the network is an arbitrary sprite and people are resources that the sprite grabs in order to do an activity. That way we can put time limits on how long a person does a task, grab all people for staff meetings, put skill levels on tasks and people and requires arbitrary people to do tasks, etc. Consumed resources might be used per unit of time and need to be measured in terms of volume used (funding). ↑
- Fixed times are deterministic. Randomized times are stochastic. Times that are dependent on external events are also stochastic. ↑
- External event triggers for activities should work in a similar manner as queues. Rather than having predetermined completion times, they have indeterminate completion times and wait for an external event to move them to the next event node. ↑
- User extension logic is always the first option to allow the user extension to override or extend, at its option, the automatic logic. ↑
- Alternatively, an entity might only release those resources that are not required for the next target activity. However, this is more likely to cause deadlocks (deadly embraces) within the system as well as holding resources that other may need while waiting in queues. ↑
- Cyclic paths are one or more arcs that begin and end with the same node. Queue is defined as a cyclic path at a single node. ↑
- Duplicate arcs are more than one arc with the same start and end node. ↑
- Only the first event that achieves a level triggers an event. This is to preclude a constant event for an overflowing storage. ↑
- This may or may not be useful in terms of defining things such as defects where defects are returned by reversing a flow to send the product back to the supplier. On the other hand, it may be useful to have defects follow a separate flow, so this should not be a hard modeling rule. ↑
- Networked Graphics, Building Networked Games and Virtual Environments by Anthony Steed and Manuel Fradinho Oliveira; (c) 2010; Morgan Kaufmann Publishers ↑
- Fast players would be forced to play at the speed of the slowest component, which might be less than real-time interaction. ↑
- Our HLA text book, Creating Computer Simulation Systems, An Introduction to the High Level Architecture, includes a 1999 version of the Pitch pRTI, a capacity limited edition of their product at the time the book was published. ↑
- The hierarchical, cascaded aspect is a function of EATS’s service architecture, with course services implemented via utilization of finer grained services. Client-driven is not a requirement in EATS, we can also have internally generated message traffic; but it is typical, and most applications are conceived as client (user) driven. ↑
- C_AF_ResourceProviders provide “nested” message processing frameworks within the context of the primary EATS IPC message processing framework. ↑
- Existing technical examples of this engineering include the C_AF_SqlAdapter and the C_AF_AirRepository. ↑
- See the AF EATS Design documentation for a description of this core design concept. ↑
- The long-term vision allows for interaction with other HLA Federations. In that case, Ambassadors for the other HLA would be used by gateways to support RTI-to-RTI communications with a non-EATS Architected Federation.. ↑
- Up to this point the diagram and the process are generically the same for the creation of a simulation model as it would be for the creation of any other static model laid over the specification of a system. This might include a Function Flow Model, a QFD, an AHP, etc. ↑
- For example, flows defined in The System which are not represented in the model may indicate the model is not complete. Vice-versa, relationships required or defined in the model which are not present in The System may call out a need for revalidation of both specifications. These edits are possible due to the implied congruity between the model and The System and the specification of both in a common store using a consistent meta-language. ↑
- One technique for this is to have the client proxy federate slow down the simulation cycle time of the model execution. Another technique is to allow the model to execute at regular speed, but to buffer the activity stream and play it to the GUI at a slower animation rate. The first approach is easier, but impacts the whole model. The seond approach makes more sense if multiple viewers may be watching or engaged with the same model. ↑
- Examination of the current code base seems to confirm that this logic should work for the first level dispatcher. However, if a continuation of a conversational session requires transport of the message to a remote node for processing, it is not clear that this capability is in the current code base. Given the current code structure, it should not be too hard to add, however it does not appear to be there now. ↑
- For example, federate may employ search routines or calculations or knowledge acquisition in order to achieve their purposes. These functions may be supported by external support routines which may be shared “utilities” within the simulation. ↑
- This is an over simplification. There may be a number of service requests that occur in order to perform search and discovery of the simulation model to be operated on. The opening request that establishes the specific instance of the simulation model to be operated on is the service request which establishes the conversation framework. ↑
- Criticality of the repository being shared (having identical information content) is primarily an issue regarding dynamic editing of simulation model content. If two distinct repositories are used that are not replicated images of each other the edited element specifications updated on the client will not be used in the simulation exercises. ↑
- Good citizenship would prefer that Resource Providers with high CPU spin would run as lower priority services to avoid interfering with response time of other services. ↑
- See “Demo Architecture” Figure 3 for an example of these parameters in Insight Maker. ↑
- If multiple EATS Simulation Facilities are linked into a federation, or if one or more EATS Simulation Facilities are connected into a federation with other non-EATS HLA-based RTIs, each EATS Simulation Facilities takes the role of a unified federate. This discussion relates to the scheme by which the HLA architecture is used recursively within EATS to describe and manage the internal operation of the EATS Simulator. ↑
- See Figure 3. Hypothetically, this could be a new instance or a restart of a saved execution. ↑
- This is a task somewhat analogous to an EATS processing node distinguishing between message traffic that wants to cycle locally, from traffic that originated in another node, and/or traffic that requires an external node for processing. ↑
- Communications from the client to the Simulator, or from a client to a federate are handled in two parts (1) as a conversation between the client and the Simulation Facility as per Client – Simulation Facility Conversations, and (2) as a linked conversation between the Simulator and a federate as per Internal Simulation Federate Conversations. ↑
- C_AF_ServiceMediator.java in package net.architectedfutures.eats.core.services ↑
- Local in this instance indicates the Simulator RTI that is addressed by the local routing tables. This may be local to the same EATS Node, or it may be in another node. ↑
- This is similar to the cascaded multiple thread system used by communications adapters. The multiple threads are dormant most of the time, so they do not compete for machine resources when not in use. However, this is a simpler architecture which places the burden of managing CPU contention on the operating system, rather than trying to handle that form of responsibility in the application. If multiple simulation are actually executing they will , of course, compete with each other and compete with other local process for CPU, memory, etc. ↑
- An aggregator model type HLA RTI may join multiple “independent” HLA RTIs together into a larger federation. ↑
- The Resource Provider plugin shown in Figure 7 is generic. Not all Resource Providers expose secondary extensions, although some do. The option to do that, and the nature of the extension point exposed, is specific to the nature of the Resource Provider. ↑
- Referencing Matlab documentation a pulse appears to be an input whose ‘value’ is ‘height’ which then decays to zero over ‘width’ time units. If ‘width’ is 0, the pulse would simply ‘spike’ at ‘Time.’ If width were 2, the input value would look like a saw tooth which went straight up to a value of Height, then fell off to zero over 2 time periods. Repeat would cause this pattern to recur. ↑