In the last couple of months, I was quite busy with the development of the next version of Damos. This new version will bring many new features. In this post I will introduce the most interesting ones, which are:
- System Interfaces and Subsystems
- System Fragments
- Units of Measurement
- Specifying Block Behavior with Mscript
System Interfaces and Subsystems
The classic way to structure large models is by dividing the system into subsystems. In contrast to other tools, subsystems are described in Damos solely through their provided system interface. On the one hand, this allows for using different subsystem implementations for a single subsystem. On the other hand, it enables the decoupling of the model that uses the subsystem and the model that realizes the subsystem (i.e. there is no model reference from the using model to the realizing model).
A system interface specifies the system inputs and outputs—so called inlets and outlets—and their data types. When adding a new subsystem to a model, the user must specify the system interface that is provided by the new subsystem. Newly added subsystems do not specify its realizing model—that is, the realizing model must be specified explicitly later on. Subsystems without a realization specification are visualized in the block diagram with a dashed border.
In order to simulate the model or to generate code, the realizing models for all subsystems must be specified. This is done by defining a subsystem realization for each subsystem, which binds the subsystem to a realizing model. When using system fragments (see next section), it is even possible to override previously defined subsystem realizations with a subsystem realization on a child fragment. Realized subsystems are visualized in the block diagram with a solid border and a triangle to the left of the subsystem name. In the case of an overridden subsystem realization, an opaque green triangle is used instead.
The model of the realizing system must contain a corresponding inport and outport for each inlet and outlet of the system interface, respectively. These inports and outports represent the interface of a system from the implementation point of view.
System Fragments
When modeling data flow-oriented systems, it is often desired to incorporate blocks that are used for simulation purposes only (e.g. step function blocks and scopes). These blocks are not related to the functional concern (i.e. core concern) of the model, but represent an unrelated concern that cross-cuts the model’s functional concern. In aspect-oriented programming (AOP) terminology, such cross-cutting concerns are called aspects.
Mixing cross-cutting concerns and functional concerns on the same model leads to undesired effects. For instance, imagine you need to design a process model which will later be included as a subsystem in a control loop model to simulate the behavior of a digital controller design. However, during the design of the process model you often need to add simulation-specific blocks to verify the correctness of the process model itself. Now, if you include the process model—keeping the simulation-specific blocks—as a subsystem in your digital controller design, the simulation-specific blocks on the process subsystem will likely interfere with the simulation of the overall system.
The problem is even more significant if you add simulation-specific blocks to a model which is later used to generate code from. In this case, the code generator will either generate invalid code or fail altogether because it does not know how to handle simulation-only model elements.
It becomes clear that we need a means to separate the various aspects of a system model. In Damos this can be accomplished with the concept of system fragments. System fragments are basically a grouping mechanism for blocks. For instance, if your model contains simulation-specific blocks in addition to the functional blocks, you would extract those blocks to a separate fragment.
System fragments are hierarchically structured, which is orthogonal to the subsystem hierarchy. A system model consists of exactly one root fragment and any number of child fragments (including none at all). In the example above, the functional fragment would be the root fragment and the simulation fragment its child. Since system fragments can have any number of children, different aspects of a system model can be defined in this way.
The set of system fragments which form a concrete system model is defined by the context fragment. The context fragment—which can be any fragment in the fragment hierarchy—and all its parent fragments up to the root fragment determine the set of blocks of a concrete system model. Therefore, if you need to specify a system model for simulation or code generation purposes, or when specifying the realizing system model of a subsystem, you must specify the context fragment.
As mentioned earlier, subsystem realizations, which bind subsystems to concrete implementations, are also located on system fragments. Due to the fact that they do not need to be located on the same fragment as the realized subsystem, but can be located on any child fragment, multiple realizations for a single subsystem can be defined. In this way, it is even possible to override existing subsystem realizations on parent fragments.
Units of Measurement
During model editing, Damos constantly validates the compatibility of the input and output data types of connected blocks. If the data types do not match, error markers are attached to the corresponding blocks. Because data flow-oriented modeling is often used to model physical systems, quantitative values can be specified. That is, any numeric value has a unit attached to it. If no unit is specified, a dimensionless value is assumed (i.e. unit is 1). Based on the block type, Damos can then validate the compatibility of the input data types and evaluate the resulting output data types with respect to its units. The output data types are then checked against the input data types of the next block.
Specifying Block Behavior with Mscript
In the new version of Damos, block behavior can be specified declaratively in the block type definition using the scripting language Mscript. That is, it is not necessary anymore to provide code templates and Java code for each block. This increases the accuracy of the simulation result versus the generated code, allows for defining new block types directly within a Damos project, and eliminates the necessity to recreate all code templates to support a new programming language.
Mscript is a declarative programming language where you define the relationship between the inputs and outputs of a function using a set of equations. In contrast to a functional language, Mscript functions can be stateful. Consequently, such functions must be instantiated (function objects). Stateful function equations can reference previous input and output values, which enable the specification of difference equations (not to be confused with differential equations). Difference equations are widely used to specify discrete transfer functions, for instance in the field of digital signal processing (e.g. FIR and IIR filters). The Mscript example below shows the difference equation of a discrete derivative.
Installing Damos 0.2
If you want to experiment with a preview version of Damos 0.2, you can checkout the source code from our project site, or install Damos from our Eclipse update site. I will also provide a step-by-step tutorial on block diagram editing, model simulation, and code generation in one of my next posts.
