SysMod is a proposed language for dynamic systems modeling that will extend the capabilities of languages such as STELLA. SysMod will support the basic dynamic flow techniques (e.g., causal loops) of STELLA, but additionally provide means for both white box and black box analysis (process/functional decomposition) and system composition or integration. SysMod will also make a finer distinction between types of flows that allow built-in enforcement of conservation principles for energy and matter. Process and transfer functions will be supplied by the user as in STELLA.
Another goal in developing SysMod is that it will support system evolution simulation. That is, system objects can be modeled as internally unorganized aggregates of parts that will evolve under flowthroughs of energy and a set of component interaction rules. In this way transfer and process functions can emerge system environment (the set of sources and sinks) can act to select more fit versions. Nonlinear interaction rules will be supported so that non-stationary process behavior can be modelled.
Current languages such as DYNAMO and STELLA allow the depiction of flows of matter from sources through reservoirs to sinks. They provide for means of regulating rates of flow and informational feedback that may modulate such flows. Clearly many systems models can be represented with this approach. But, in this approach, the flow of energy is implied in the flow of material. Potential energy is implied in the reservoirs. The approach in SysMod is to separate the energy/matter flows so that a finer analysis of systems thermodynamics can be done. This is motivated by attempts to model alternative energy systems infrastructure for sustainability. Figure 1 shows a simplified model in which total free energy is analyzed.
Figure 1. A systems model of sustainable alternate energy production. In this model, free energy flow is explicitly separate from material flow. Energy flow is depicted by open arrows while material flow is represented as filled arrows. The round-edged rectangles represent processes (which contain stocks or reservoirs - see below) that transform material and energy inputs into product outputs by performing work internally. Additionally, waste heat and material is accounted for in this model. Not shown are sources and sinks for the inputs and wastes, respectively.
The difficulty in constructing this model in STELLA is that one has to convert energy flows to material-equivalent energy flows, even though no matter transfers. While not an impossible task it is confusing. Currently I am supervising a student in the development of a STELLA model to analyze the system shown in Figure 1. Given the limitations of representing various processes and flows as stocks and single typed flow graphs has given rise to considerable complexity. Figure 2 shows a partial representation of a standard systems dynamic model as it would be represented in STELLA.
Figure 2. The model depicted in Figure 1, partially converted to a standard systems dynamic representation. This version only models the top two levels in this multi-level energy budget.
One very clear difference between these two representations is that the various rates and transformations that are encapsulated in process blocks in Figure 1 need to be made explicit in Figure 2. In SysMod, the system object is not just a "stock" but is an encapsulated process. It contains all of the conversion/transformation functions and, hence, the flow rates (see below). This approach is related to the object-oriented paradigm in computer programming languages. Object orientation encourages encapsulation and information hiding as a means of managing complexity. SysMod adopts this same principle.
Figure 3 shows a schematic diagram of the components of a typical system model using SysMod. These components will be described below.
Figure 3. Components of the SysMod modeling language.
A system object, as represented in Figure 1, is a focus of analysis. It is comprised of several generic internal components (at this stage of analysis). These components define the behavior of the object as well as provide for the connection of the object to its environment.
Receivers
Receivers are couplings for the flows of energy, material or messages from sources to the system object. Internally these contain the address of the source, the expected rate of receipt and other data that feed into the process component. There are three types of receivers, specialized by the flow types. Each receiver is contained in a list of that type so that an object may receive more than one flow of a given type from multiple source entities. Receivers are the data stores for computations done in the process component. They store both the new input value as well as the old (previous time step) value. The latter is used in current time step computations.
Process
A process component contains the computational equations for transfer functions. These are the user defined transformations of inputs into outputs. Transfer functions are subject to the constraints of conservation principles for matter and energy. While no such conservation principle applies, strictly speaking, to message flows, the output messages are ultimately constrained (in terms of bit rate) by available free energy input. Transfer functions describe the work that is accomplished in each time step. Enforcement of the conservation of energy requires that every work process generates some amount of entropic heat (waste heat) according to user-supplied efficiency constants. Every work process is required to generate some waste heat, even if it is just the production of outgoing messages.
Every process is updated with each time step designated by a specific clock. The SysMod engine supports a set of timers that can be used to set up different temporal resolutions for process that occur at different spatial resolutions. For example, when decomposing a system object into internal subsystems it is possible for these to be updated more frequently than the overall (parent) system. This is not only more computationally efficient for large systems with subsystems at different scales, but also helps preserve accuracy. In effect, subsystems become integrators within the system. This will be further described below.
Transfer functions are discrete time descriptions of output values given input values.
They take the form:
VOutt = VOutt-1 +
F(VInEt,
VInMt, VInDt)
where: t is the current time step
t-1 is the prior time step
VOut is the output value
VIn is the value of the input of type E, M, or D
Energy, Matter, or Data (messages), respectively,
and
F is the user supplied function relating these input quantaties to the output increment
or decrement.
Reservoirs
Reservoirs are buffers that help a process internally synchronize its inputs and outputs. These are explicitly designated by the user or may be supplied during runtime if the model contains inherent, but unrecognized, asynchronous flows. The latter can be used in debugging and/or to identify inconsistencies in the model. Energy reservoirs are generically called "batteries" regardless of the type of energy involved. Material reservoirs are called "inventories" and messge reservoirs are called "data", short for database. A special case for reservoirs is the growth of an active process. Growth refers to accumulation of matter associated with stored free energy (e.g., chemical bonds; Gibbs free energy). The user will designate an internal rate of accumulation of matter and free energy explicitly in the transfer functions.
Flows of material, energy and messages are what define the dynamic behavior of a system. These include flows into the system, flows out of the system and, in the case of complex composed systems, internal flows with possible feedback (causal loops). In SysMod energy, material, and messages (data and information) are explicitly segregated. This is a major difference between the current approach and previous system dynamics modeling approaches where energy flow was implicit in the flow of material. The advantage of the current approach is that work processes that do not involve mass transport can be modeled. Additionally models of energy budgets and control systems (information feedback) can be explicitly modeled.
Energy flow rates, or currents, and material flow rates, or mass transitions, are identified seperately. This allows explicit identification of energy sources separate from material sources, thus more concretely modeling real systems. Message flows are unique to SysMod. Messages can be quantified in information rates, bits per second, for example. Receivers for messages measure the real-time bit rate and compare that with the expected bit rate, generating an information level that feeds into work processes.
Sources and sinks are identified, but undefined entities in Figure 3. Each source/sink entity has a unique identifier and one or more type of output/input. At the top-level of a model (with a single SystemObj entity) sources and sinks define the environment of interest. Sources get their data either from a data base (historical or previously generated time-series data) or from an internal (user-supplied) generation function of time. For example, a model of a solar energy system would include a source (called the Sun!) that produces insolation. The values for each time step in this model could be generated by a general insolation model [Mobus, 1981] or from actual site data.
Top-level sinks are the data collection ports for output of the model. Sinks can be affiliated with specific columns in a data collection table in the data base. Each record would be one time step of the model and the resulting data base is a multi-variate time series from which analysis can be done. Of course this is not the only data that is collected in SysMod. State data from any of the lower-level SystemObj entities may be collected as well. But the output sinks will represent the major output from the model.
There are several options for building a model. The same basic rules for identifying the main entities, flows, and causal loops that are used in dynamic systems modeling (with DYNAMO, for example) apply in SysMod. Start with pencil and paper diagrams to work out the main components.
SysMod supports both top-down decomposition and bottom-up compostion processes for model building. Since entities are not just stocks, but also processes, it is possible to think of each entity as being composed of sub-systems. If one starts at a top level and identifies a set of transfer/transformation functions but later decides to decompose those functions SysMod supports white-box analysis and remapping the processes at a lower (more detailed) level as a set of interacting sub-systems (see Figure 4 below).
Conversely, one could have developed a more detailed model, as in Figure 4, and then designate an encapsulation of this model into a top level model (without losing the details). This approach allows for several useful features. Encapsulation allows the model to be run at a longer time constant or in summary mode, looking only at the final sink outputs. Or the higher level model can be composed with one or more other such models to form a more complex model (for example by developing models of the top-level sources and sinks independently and then combining these with the original SystemObj entity to form a larger scaled model.
Figure 4. A more complex system comprised of several subsystems and internal flows. This system may have been developed by decomposition of a single parent system, or results from composition (matching flows) based on converting some sources and sinks into system objects.
Entities in SysMod are not just stocks of some quantity. Rather these entities are process that convert inputs into outputs. The general framework is that a process receives material input along with free energy (energy available to do useful work) and information. The process does work on the material(s) using the free energy and under guidence of internal rules plus real-time information provided from the environment.
Figure 5. A hierarchical control system demonstrates the advisability of separating material, energy and information flows. This kind of model also demonstrates the need for multiple time scales in the model. The operational level operates in real-model-time whereas the tactical/logistic controller operates over a much longer time scale. The strategic level operates over a longer time scale still.
Figure 6. SysMod Architecture. The SysMod simulation engine accepts an intermediate language program from the source code module. Human-readable XML format is compiled into the IL. A graphical user frontend will allow users to build models using drag and drop objects. An expander can take IL code and make it usable in either the XML format or in the graphical frontend. Data and simulation state can be saved in a database. Additionally, source data (from empirical sources) can be read in from the database. The simulator will output data which may be stored, or sent to the graphing viewer. Alternatively (or in its own window) the data can be viewed in the form of an animated simulation - showing the original model undergoing flows.