Mbeddr
The mbeddr project is a proposed open source project under the Technology Top-Level 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
The amount of software embedded in devices is growing. At the same time, embedded software development is challenging. In addition to functional requirements, strict operational requirements have to be fulfilled as well, including reliability, safety, efficiency or real-time constraints. Addressing these challenges requires any of the following approaches: abstraction techniques should not lead to excessive runtime overhead; programs should be analyzable for faults before deployment; and various kinds of annotations, for example for describing and type checking physical units, must be integrated into the code. Process issues such as requirements traceability and consistent documentation have to be addressed, and developers face a high degree of variability, since embedded systems are often developed in the context of product lines.
Current approaches for embedded software development can roughly be
distinguished into programming and modeling. The programming
approach mostly relies on C, sometimes C++ and Ada in rare cases.
However, because of C's limited support for defining custom
abstractions, this can lead to software that is hard to understand,
maintain and extend. Furthermore, C's ability to work with very
low-level abstractions such as pointers, makes C code very expensive
to analyze statically. The alternative approach uses modeling
tools with automatic code generation. The modeling tools provide
predefined, higher-level abstractions such as state machines or data
flow block diagrams. Example tools include ASCET-SD or Simulink. Using
higher-level abstractions leads to more concise programs and
simplified fault detection using static analysis and model checking
(for example using the Simulink Design Verifier). Increasingly, domain
specific languages (DSLs) are used for embedded software, and studies
show that domain-specific languages substantially increase
productivity in embedded software development. However, most
real-world systems cannot be described completely and adequately with
a single modeling tool or DSL, and the integration effort between
manually written C code and possibly several modeling tools and DSLs
becomes a significant problem.
A promising solution to this
dilemma lies in a much tighter integration between low-level C code
and higher-level abstractions specific to embedded software. The
mbeddr project, described in this proposal, implements this approach.
mbeddr supports embedded software development based on an extensible version of the C programming language, and a corresponding IDE (see image above). The advantages of C can be maintained: existing legacy code can be easily integrated, reused, and evolved, and the need for efficient code is immediately addressed by relying on C's low-level programming concepts. At the same time, domain-specific extensions such as state machines, components or data types with physical units can be made available as C extensions. This improves productivity via more concise programs, it helps improve quality in a constructive way by avoiding low-level implementation errors up-front, and leads to system implementations that are more amenable to analysis -- also supported by mbeddr. By directly embedding the extensions into C, the mismatch and integration challenge between domain specific models and general purpose code can be removed. mbeddr's industry-strength implementation of this approach also includes IDE support for C and the extensions: syntax highlighting, code completion, error checking, refactoring and debugging.
Scope
The project addresses the development and evolution of mbeddr language extensions (standalone DSLs and C extensions), their IDE, debuggers, and the integration of formal verification tools. mbeddr languages and extensions include:
- C99 (C99 is an informal name for ISO/IEC 9899:1999, a past version of the C programming language standard which is supported by most embedded compilers)
- Statemachines
- Components
- Requirements
- Documentation
- Product-Line Support
- A build language
- Integration with various formal analyses tools (e.g. CBMC, NuSMV, yices)
As well as additional base languages (e.g. C++ or Ada), and additional higher level languages extensions (e.g. tracing, logging, data flow, protocol description). In addition the project provides example languages and language modules which illustrate the integration into existing environments. The project does not include development and evolution of MPS, the verification tools themselves or actual C compilers or debuggers.
Description
mbeddr provides a fully featured IDE for C, arbitrary extensions of C and any other language developed in mbeddr. The system is structured into layers and concerns.
Implementation Concern
The implementation concern addresses the development of applications
based on C. On the core level, mbeddr comes with an implementation of
C in MPS (MPS is discussed below). There are a few minor differences
to C99, and the preprocessor is not exposed to the user. On the
default extensions layer, the implementation concern comes with C
extensions for interfaces and components, state machines and physical
units, among others. The user extensions layer is by definition empty;
users can easily extend the C core as well as any of the default
extensions. The implementation concern also ships with an extensible
debugger that is able to debug on the level of the extensions, so the
abstractions do not break down when debugging becomes necessary. In
the future, mbeddr will also support importing existing header and
implementation files, to support interoperability with legacy
libraries or implementation code. At the foundation layer, the
implementation concern relies on a C compiler, a C debugger and tools
for importing existing C code into mbeddr. By default, mbeddr generate
make files that call
gcc
, the debugger relies on
gdb
debugger and the Eclipse CDT for
analyzing and importing textual C code. However, all of these can be
changed.
Analysis Concern
This concern adds static analyses to some of the default extensions provided by the implementation concern. The analysis itself is performed by different existing external tools. However, mbeddr integrates the tools tightly by (a) providing language abstractions to conveniently describe behavior that can be analyzed, (b) translating this description to the input of the analysis tool, (c) running the tool, and (d) lifting the output of the tool back to the original abstraction level, to make it easier to understand for the user. The integrated analyses are based on symbolic model checking, SMT solving and C-level model-checking.
Process concern
The process concern includes cross-cutting facilities that are useful to integrate mbeddr into the development process. They are generic in the sense that they can be integrated with arbitrary other languages, such as all the default and user-defined C extensions. mbeddr supports requirements engineering, product-line variability and documentation.
The requirements engineering support provides a language for describing requirements. Each requirement has an ID, a short description, an optional longer prose, a priority and any number of additional attributes. Requirements can also be nested and express relationships to other requirements. Requirements traces can be attached to any program element expressed in any language, supporting ubiquitous traceability. The requirements facility also supports reverse-tracing, so users can find out which parts of implementation artifacts depend on any particular requirement. Importantly, the requirements tooling is extensible; arbitrary additional data, expressed in any language, can be added to a requirement. This way, support for use cases, collaborations and scenarios has been added in a modular way.
mbeddr's support for product-line engineering can be split into two parts. First, there is a formalism for defining feature models and configurations based on these feature models. This represents a purely conceptual description of variability, independent of any particular implementation. The second part maps the variability expressed in feature models to arbitrary implementation artifacts by using presence conditions. These are Boolean expressions over features that determine how the program element they are attached to depends on the features selected for a given variant. If the expression evaluates to false, the element they are attached to is removed during generation. As a consequence of MPS' projectional editor, the presence conditions can also be evaluated in the editor. This allows program variants to be viewed and edited. While presence conditions are static and work for any language, there is also C-specific support to evaluate variability at runtime.
Visualization provides a facility to render diagrams. The facility relies on PlantUML as the backend, which supports most of UML's diagrams. The diagrams are shown directly inside the mbeddr IDE; by clicking on a node in the diagram, the respective source node in the MPS editor is selected, supporting navigability between diagram and code. Any program element can contribute visualizations, making the facility generically usable.
The documentation aspect supports writing prose documents as part of an mbeddr project, exportable as HTML or LaTeX. What makes this aspect worthwhile is that it supports close integration with program elements: program elements can be referenced (with real references that are renamed if the element itself is renamed) and program code can be embedded as text or as an image. The embedded code is updated whenever the document is regenerated, avoiding manual synchronization of the documentation. In the same way visualizations (as described in the previous paragraph) can be embedded, also updated whenever the document is re-rendered to LaTeX or HTML.
Underlying Technology
mbeddr relies on the JetBrains MPS language workbench. The JetBrains Meta Programming System is a projectional language workbench available as open source software under the Apache 2.0 license. The term Language Workbench was coined by Martin Fowler. He defines a language workbench as a tool with the following characteristics, all of which MPS exhibits: (1) Users can freely define languages which are fully integrated with each other. (2) The primary source of information is a persistent abstract representation. (3) A DSL is defined in three main parts: schema, editor(s), and generator(s). (4) Language users manipulate a DSL through a projectional editor. (5) A language workbench can persist incomplete or contradictory information.
One of the most important statement in this definition is languages which are fully integrated with each other. It is not enough for a language workbench to address the definition of a single language. It must be possible to define sets of languages, and, while each of them should be a well-defined module, it is also essential to be able to define how these languages integrate. MPS is particularly good at this.
MPS' Projectional editing does not rely on parsers. As a user edits a
program, the AST is modified directly. A projection engine
then creates some representation of the AST with which the user
interacts, and which reflects the resulting changes. This approach is
well-known from graphical editors: when editing a UML diagram, users
do not draw pixels onto a canvas, and a "pixel parser" then creates
the AST. Rather, the editor creates an instance of
uml.Class
as a user drags a class from the palette onto the canvas. A projection
engine renders the diagram by drawing a rectangle for the class.
Programs are stored using a generic tree persistence format (such as
XML). This approach can be generalized to work with any notation,
including textual.
What makes projectional editing interesting for language workbenches in general, and for mbeddr in particular, are the following two characteristics. First, the approach can deal with arbitrary syntactic forms including textual, symbolic/mathematical, tabular and graphical. This means that much richer notations can be used in an integrated fashion, improving the usability to the end user. An example from mbeddr is the decision table shown in the picture above. Traditionally the tools for building textual and tabular/symbolic/graphical editors were very different in terms of their architecture and user experience, and integrating them seamlessly was a lot of work, and sometimes impossible. Second, if independently developed languages are composed, the resulting composite program is never syntactically ambiguous.
Relationship to other Eclipse projects
- Eclipse Platform: mbeddr currently does not run on top of the Eclipse platform. Instead it runs on MPS. If MPS allows the generation of Eclipse plugins in the future, mbeddr will directly benefit from that
- CDT: As mentioned above, mbeddr uses the CDT Debug bridge to enable its debugging capabilities. Although and better offers the capability to edit regular C code, this is not the main purpose of mbeddr. Mbeddr's advantage is the strong integration of multiple implementation paradigms, its strong focus on formal verification techniques as well as the integration with other development process concerns.
- EMF: There is no direct relationship to EMF, however, conceptionally the MPS's storage format as well as the low level APIs are similar to what EMF offers. Thus, in the future it might be possible import / export models to / from mbeddr. A general integration with EMF is however out of scope for this project as this will be done by MPS
- Xtext: Again, there is no direct relationship to Xtext. Mbeddr uses MPS as the underlying Technology platform. MPS is, similar to Xtext, a language workbench but with a very different focus. While Xtext persists its models in plain ASCII files, MPS stores its models in a proprietary binary or text format. A user in MPS does not edit the text but works directly on the AST. Thus no parsing technology is necessary. In addition this enables the usage of different notations (text, tables, graphics), different projections for the same code as well as partial projections or partial views on a model.
Why Eclipse?
- The target domain of mbeddr is embedded software and the Internet of Things (it is currently used in energy/metering systems and automotive software, among others). Eclipse has a strong community in this space, so this is a good fit as well.
- Eclipse provides a well-defined governance structure and development process. The mbeddr project will benefit from this structure and this way, additional contributors can be phased in more easily.
- Fundamentally, mbeddr is a DSL-based modeling and programming environment. Since Eclipse already has a strong focus on modeling, it is a good fit.
Initial Contribution
The initial contribution consists of sources, tests, build, and
documentation. It comprises the complete mbeddr system including all
above-mentioned languages and C extensions and their IDE support. In
addition, it will provide a development environment for Arduino
Hardware. The project does not include MPS itself, which is
open source under the Apache 2.0 license.
The code is hosted
at github: https://github.com/mbeddr/mbeddr.core/.
The project website is at http://mbeddr.com.
Legal Issues
There are no known legal issues.
- mbeddr has a required dependency to MPS (Apache 2.0 licensed)
- mbeddr has a works-with dependency to PlantUML as well Graphviz (EPL 1.0 licensed)
- mbeddr has a works-with dependency to NuSMV (LGPL 2.1 licensed)
- mbeddr has a works-with dependency to CBMC (BSD-style License)
- mbeddr has a works-with dependency to yices (proprietary license)
Committers
The following individuals are proposed as initial committers to the project:
- Bernd Kolb (itemis AG) Project lead
- Markus Voelter (independent/itemis)
- Dan Ratiu (fortiss)
- Domenik Pavletic (itemis)
- Kolja Dummann (itemis)
We welcome additional committers and contributions.
Mentors
The following Architecture Council members will mentor this project:
- Benjamin Cabé
- Doug Schaefer
Interested Parties
The following individuals, organisations, companies and projects have expressed interest in this project:
- Sierra Wireless
- Continental
- Siemens/LMS
- Sioux
- BMW-CarIT
- Rohde & Schwarz
- Method Park
- Robert Bosch GmbH
Project Scheduling
Changes to this Document
| 25-November-2013 | Added interested parties |
| 4-November-2013 | Added interested parties |
| 07-October-2013 | Document created |
| 25-October-2013 | Incorporated feedback |