Skip to main content

Damos

Damos

The Damos project is a proposed open source project under the Tools project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the Eclipse community. Please send all feedback to the Eclipse Proposals Forum.

Background

In the field of science and engineering, a data flow-oriented approach is commonly used for analyzing and designing systems. On the one hand it allows scientists and engineers to focus on the data processing aspects of a system, and on the other hand it provides a means to specify the dynamics of the mechanical components and the physical environment of the system to facilitate close-to-real-world system simulation.

Since many scientists and engineers already use Eclipse for software development, it would be beneficial to perform system design, simulation, and code generation in Eclipse rather than using an external tool like MATLAB/Simulink, Scicos, or LabVIEW.

Scope

The scope of this project is to provide an integrated development environment for developing data flow-oriented systems using block diagrams.

This will include:

  • Metamodel for data flow-oriented system models
  • Graphical and textual editors
  • A simulation environment for simulating continuous, synchronous and asynchronous systems
  • Code generators to transform system models into source code
  • A declarative programming language for defining block behavior
  • A Block library containing commonly used blocks
  • Support for customizing and extending various aspects of the environment, such as simulation engine, code generators, and block libraries
  • Support to derive custom data flow-oriented languages based on the structural and diagram editing components of this project

Note that this project is unrelated to process flow and work flow modeling. A description of the conceptual differences is given in the next section.

Description

This project will provide a development environment for analyzing and designing systems using a data flow-oriented approach. Such systems are specified using block diagrams, which contain the software components (e.g. control algorithm) that will later be executed on a target device (e.g. digital controller) and the mechanical components as well as the physical environment to allow for system simulation. The mechanical and physical components of the system can be represented as a dynamical system, which is specified by providing the transfer function of the corresponding linear time-invariant (LTI) system.

Even though data flow-oriented design is not bound to a specific domain, it is most commonly used in control systems engineering and digital signal processing.

Relationship to Process Flow and Work Flow Modeling

Process flow and work flow models specify the high-level activities of a system. In other words, they do not specify a concrete implementation of the activities of such systems. For instance, business process models may specify that when receiving an order, the order must be checked and then an invoice must be created before the ordered parts can be shipped. However, the concrete implementation (e.g. software components) of these activities is not specified. Because of the missing implementation and since process flow and work flow models tend to contain prose text, executing process models for simulation purposes is challenging. Thus, process flow and work flow models can be seen as top-level architectural models.

Damos models, on the other hand, specify the concrete implementation of the software components and optionally the physical/mechatronical environment (for simulation purposes) using a data flow-oriented approach. Data flow-oriented modeling focuses on the data passing the system, rather than the state of the system. Since the structure and behavior (i.e. implementation) of the components are formally specified, such models can be simulated and transformed into executable code (e.g. C code). Thus, Damos can be considered as a graphical, data flow-oriented, declarative programming language.

An important concept of data flow-oriented modeling is that components within such systems can only access the input values and their own state variables to compute the output values (i.e. components cannot access the global state of a system or the state of other components). This results in the fact that data flow-oriented systems inherently parallelizable.

Deriving Custom Data Flow-Oriented Languages

Damos models contain structural and behavioral information. The structural information specifies how systems are composed (i.e. system hierarchy) and how system components are interconnected. The behavioral information specifies how the data that passes the system is transformed by the system components. Damos provides a set of features that facilitate the definition of the system behavior. These features include a type system and a declarative programming language.

Sometimes the provided behavioral concepts of Damos cannot be directly applied to a certain application. Yet the structural concepts of Damos may fit very well. In these cases, a new language can be derived from the structural features (e.g. structural metamodel and graphical editor) of Damos, and then implementing the custom behavioral features.

Why Eclipse?

Currently, Eclipse does not provide tool support for designing data flow-oriented systems. Engineers and scientists are required to use tools which do not integrate very well with other Eclipse technologies. Furthermore, due to the closed source nature of commercial tools, it is difficult to customize and extend these tools for better integration with other Eclipse technologies.

This project will benefit from being hosted at Eclipse due to the broader visibility, and better integration and coordination with other Eclipse-based technologies such as EMF, RMF, CDT, RTSC, TCF, and other tools like Papyrus, eTrice, and Koneki. Because of the perceived higher reliability in terms of long-term support, it is expected to attract more interest and participation from other parties. This will lead to greater market penetration, while improving quality and reducing development costs.

The following diagram shows how Damos can be integrated into a development workflow using other Eclipse-based technologies. The green boxes represent the Damos-related activities and artifacts, whereas the blue boxes denote existing Eclipse-based tools and frameworks.

Initial Contribution

The initial contribution consists of sources found in the current Damos repository at EclipseLabs, which include:

  • GMF-based block diagram editor
  • Simulator
  • C code generator
  • Basic block library
  • Declarative scripting language Mscript

Architecture

In order to facilitate customization, Damos is split into a set of top-level components (i.e. Eclipse features). There are two main groups of components. The first group contains components providing the structural semantics and the diagram editing features (orange). The second group provides simulation and code generation components as well as the standard block library (green). This enables other projects to build their own data flow-oriented languages by reusing the structural semantics and the diagram editing components, without being required to include unnecessary components.

Main Components

Models

EMF-based models are used to specify the semantics of data flow-oriented systems. This enables users to perform model analysis and transformation using well-known Eclipse modeling technologies.

System models are comprised of models describing the mechanical components and the physical environment of a device, and the software model that later will be executed on the device. These models are specified using block diagrams.

When performing model simulation or code generation, an execution flow is first derived from the system model. The execution flow can be seen as the imperative representation of the system model. For instance, it describes the execution order of the components so that components that drive other components are executed first. This information is later used by the simulator and the code generator to execute and to generate the components in the right order, respectively.

Simulation and code generation can be configured using a Damos-specific configuration language. Such configurations contain global properties and properties for individual Damos model elements (using an annotation mechanism). Configurations can extend and/or override other configurations, so that, for instance, properties that are common to simulation and code generation can be extracted to a base configuration.

To configure computation-related aspects (e.g. fixed-point arithmetic operations), computation models can be specified in the configuration for individual model elements (e.g.components and subsystems). Since Damos models only utilize high-level numeric data types (e.g. real and integer), computation models are used to map high-level data types to machine data types (e.g. double and int32). The computation models are incorporated by both the simulation environment and the code generators to ensure that the simulation results match the behavior of the generated code.

Damos provides a GMF-based graphical block diagram editor for the system model. For all other models, textual model editors based on Xtext are provided.

Block Diagram Editor

The graphical block diagram editor is used for editing system models. It can also be used to visualize real-time simulation results using virtual instruments. Virtual instruments display simulation results in real-time, or provide a means to interact with the running simulation (e.g. using buttons and sliders).

Block diagram files contain two model types: the semantic model of the system and the notation model containing the graphical information of the block diagram. When processing block diagrams (i.e. simulation and code generation), the notation model is ignored.

While editing block diagrams, the model is continuously validated. Validation errors are shown as annotations on invalid model elements. For instance, when using units of measurement for numeric values, the compatibility of block inputs and outputs are checked based of their corresponding units.

Mscript

This project will include the declarative programming language Mscript. Mscript can be used to specify the block behavior within the block type definitions. The simulation engine and the code generators will then derive the simulation behavior and the source code from the specified Mscript functions, respectively. This ensures that the simulation behavior and the generated code match as closely as possible. Furthermore, when adding new code generators, those block types do not need to be adapted to the new code generators.

With Mscript, the user defines the relationship between the inputs and outputs of a function using a set of equations. In contrast to functional languages, Mscript functions can be stateful. Consequently, such functions must be instantiated (function objects). Stateful function equations can reference input and output values from previous computation steps, which enable the specification of difference 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). In future versions, differential equations may be supported as well to allow for specifying the behavior of time-continuous blocks.

Simulator

The simulator utilizes adaptive and fixed step size solvers to simulate time-continuous, synchronous, and asynchronous systems. Solvers encapsulate the numerical integration algorithm to solve the differential equations that represent the system.

When real-time simulation is performed, simulation results can be displayed in real-time using virtual instrument blocks. The simulation engine incorporates a target-specific computation model, so that—for instance—overflows can be detected when using fixed-point arithmetic. Simulation aspects (e.g. solver configuration) can be configured using a simulation configuration model.

Code Generator

The code generation tooling initially includes a C code generator. Other languages may be added in the future. Each system component can provide its own code generator. When using Mscript to describe the block behavior, an Mscript-specific code generator is used that transforms the Mscript functions into C code. The code generators incorporate a target-specific computation model containing information on how arithmetic operations should be handled. The code generation process can be configured using a generator configuration model (e.g. target directories).

Block Library

The standard block library contains commonly used blocks. If required, the user can create his/her own block libraries. The block behavior can be specified using the declarative programming language Mscript, which is part of this project.

Extensibility

The Eclipse extension mechanism can be used to customize and extend various aspects of the tooling, e.g:

  • Registering block libraries
  • Contributing the visual representation (i.e. symbols) of blocks
  • Providing simulation behavior
  • Providing additional solvers
  • Providing code generators

Legal Issues

All contributions will be distributed under the Eclipse Public License.

Committers

The following individuals are proposed as initial committers to the project:

Andreas Unger, itemis (Project Lead)
Michael Krauter, itemis
Benjamin Schwertfeger, itemis

We welcome additional committers and contributions.

Mentors

The following Architecture Council members will mentor this project:

Interested Parties

The following individuals, organisations, companies and projects have expressed interest in this project:

Project Scheduling

Initial contribution is expected in the third quarter of 2012.

Changes to this Document

Date Change
22-08-2012 Added Joseph Carroll and Anthony Ford as interested parties.
01-05-2012 Document created

Back to the top