| <!-- |
| This document is provided as a template along with some guidance for creating |
| your project proposal. This is just a template. Feel free to change it as |
| you see fit (add sections, remove section). We feel, however, that the |
| suggestions represented in this document represent the reasonable minimum |
| amount of information to move forward. |
| |
| Please keep the formatting in this document simple. Please do not edit |
| this document in Microsoft Word as it adds huge piles of markup that make |
| it difficult to restyle. |
| |
| More information is available here: |
| |
| http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase |
| |
| Direct any questions about this template to emo@eclipse.org |
| --> |
| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> |
| <html> |
| <head> |
| <!-- |
| Include the title here. We will parse it out of here and include it on the |
| rendered webpage. Do not duplicate the title within the text of your page. |
| --> |
| <title>Mbeddr</title> |
| <style type="text/css"> |
| dt { |
| display: list-item; |
| list-style-position: outside; |
| list-style-image: |
| url(/eclipse.org-common/themes/Phoenix/images/arrow.gif); |
| margin-left: 16px; |
| } |
| |
| dd { |
| margin-left: 25px; |
| margin-bottom: 5px; |
| } |
| </style> |
| </head> |
| <!-- |
| We make use of the 'classic' HTML Definition List (dl) tag to specify |
| committers. I know... you haven't seen this tag in a long while... |
| --> |
| <body> |
| <p> |
| The mbeddr project is a proposed open source project under the <a |
| href="http://www.eclipse.org/projects/project_summary.php?projectid=technology">Technology |
| Top-Level Project</a>. |
| </p> |
| <!-- |
| The communication channel must be specified. Typically, this is the |
| "Proposals" forum. In general, you don't need to change this. |
| --> |
| <p> |
| 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 <a |
| href="http://www.eclipse.org/forums/eclipse.proposals">Eclipse |
| Proposals</a> Forum. |
| </p> |
| <h2>Background</h2> |
| <p>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.</p> |
| <p> |
| Current approaches for embedded software development can roughly be |
| distinguished into programming and modeling. The <em>programming</em> |
| 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 <em>modeling</em> |
| 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 <a |
| href="http://www.etas.com">ASCET-SD</a> or <a |
| href="http://www.mathworks.com/products/simulink">Simulink</a>. 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, <em>domain |
| specific</em> 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.<br> 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. |
| </p> |
| <p align="center"> |
| <img width="480" src="figures/ide.png" |
| alt="Screenshot of the current mbeddr development environment in JetBrains MPS."> |
| </p> |
| <p> |
| 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 <em>legacy |
| code</em> can be easily integrated, reused, and evolved, and the need for |
| <em>efficient code</em> 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 <em>productivity</em> |
| via more concise programs, it helps improve <em>quality</em> in a |
| constructive way by avoiding low-level implementation errors up-front, |
| and leads to system implementations that are more amenable to <em>analysis</em> |
| -- 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. |
| </p> |
| <h2>Scope</h2> |
| <p>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:</p> |
| <ul> |
| <li>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)</li> |
| <li>Statemachines</li> |
| <li>Components</li> |
| <li>Requirements</li> |
| <li>Documentation</li> |
| <li>Product-Line Support</li> |
| <li>A build language</li> |
| <li>Integration with various formal analyses tools (e.g. CBMC, |
| NuSMV, yices)</li> |
| </ul> |
| <p>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.</p> |
| <h2>Description</h2> |
| <p>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.</p> |
| <p align="center"> |
| <img width="480" src="figures/mbeddr-stack.png" |
| alt="mbeddr is organized into three concerns and five layers. The concerns address C-based implementation, formal analysis as well as process. The five layers are the MPS platform, the mbeddr core facilities, default extensions as well as the ability for users to create their own extensions. Finally, a number of backend tools (primarily C compilers and verification tools) are integrated."> |
| </p> |
| <h3>Implementation Concern</h3> |
| <p> |
| 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 |
| <code>gcc</code> |
| , the debugger relies on |
| <code>gdb</code> |
| debugger and the <a href="www.eclipse.org/cdt">Eclipse CDT</a> for |
| analyzing and importing textual C code. However, all of these can be |
| changed. |
| </p> |
| <h3>Analysis Concern</h3> |
| <p>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.</p> |
| <h3>Process concern</h3> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p> |
| Visualization provides a facility to render diagrams. The facility |
| relies on <a href="http://plantuml.sourceforge.net/">PlantUML</a> 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. |
| </p> |
| <p>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.</p> |
| <h3>Underlying Technology</h3> |
| <p> |
| mbeddr relies on the JetBrains MPS language workbench. The <a |
| href="http://jetbrains.com/mps">JetBrains Meta Programming System</a> |
| is a projectional language workbench available as open source software |
| under the Apache 2.0 license. The term <a |
| href="http://martinfowler.com/articles/languageWorkbench.html">Language |
| Workbench</a> 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. |
| </p> |
| <p> |
| One of the most important statement in this definition is <em>languages |
| which are fully integrated with each other</em>. 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. |
| </p> |
| <p> |
| MPS' Projectional editing does not rely on parsers. As a user edits a |
| program, the AST is modified <em>directly</em>. 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 |
| <code>uml.Class</code> |
| 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. |
| </p> |
| <p> |
| 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 <em>in an |
| integrated fashion</em>, 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. |
| </p> |
| <h3>Relationship to other Eclipse projects</h3> |
| <ul> |
| <li><b>Eclipse Platform:</b> 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</li> |
| <li><b>CDT:</b> 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.</li> |
| <li><b>EMF:</b> 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</li> |
| <li><b>Xtext:</b> 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.</li> |
| </ul> |
| <h2>Why Eclipse?</h2> |
| <ul> |
| <li>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.</li> |
| <li>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.</li> |
| <li>Fundamentally, mbeddr is a DSL-based modeling and programming |
| environment. Since Eclipse already has a strong focus on modeling, it |
| is a good fit.</li> |
| </ul> |
| <h2>Initial Contribution</h2> |
| <p> |
| 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 <em>not</em> include MPS itself, which is |
| open source under the Apache 2.0 license.<br> The code is hosted |
| at github: <a href="https://github.com/mbeddr/mbeddr.core/">https://github.com/mbeddr/mbeddr.core/</a>.<br> |
| The project website is at <a href="http://mbeddr.com">http://mbeddr.com</a>. |
| </p> |
| <h2>Legal Issues</h2> |
| <p>There are no known legal issues.</p> |
| <ul> |
| <li>mbeddr has a required dependency to <a |
| href="http://www.jetbrains.com/mps/download/license.html">MPS</a> |
| (Apache 2.0 licensed) |
| </li> |
| <li>mbeddr has a works-with dependency to <a |
| href="http://plantuml.sourceforge.net/faq.html">PlantUML</a> as well |
| <a href="http://www.graphviz.org/License.php">Graphviz</a> (EPL 1.0 |
| licensed) |
| </li> |
| <li>mbeddr has a works-with dependency to <a |
| href="http://nusmv.fbk.eu/open_nusmv/flier.html">NuSMV</a> (LGPL 2.1 |
| licensed) |
| </li> |
| <li>mbeddr has a works-with dependency to <a |
| href="http://www.cprover.org/cbmc/LICENSE">CBMC</a> (BSD-style |
| License) |
| </li> |
| <li>mbeddr has a works-with dependency to <a |
| href="http://yices.csl.sri.com/yices-newlicense.shtml">yices</a> |
| (proprietary license) |
| </li> |
| </ul> |
| <h2>Committers</h2> |
| <!-- |
| List any initial committers that should be provisioned along with the |
| new project. Include affiliation, but do not include email addresses at |
| this point. |
| --> |
| <p>The following individuals are proposed as initial committers to |
| the project:</p> |
| <dl> |
| <dt>Bernd Kolb (itemis AG) Project lead</dt> |
| <dt>Markus Voelter (independent/itemis)</dt> |
| <dt>Dan Ratiu (fortiss)</dt> |
| <dt>Domenik Pavletic (itemis)</dt> |
| <dt>Kolja Dummann (itemis)</dt> |
| </dl> |
| <p>We welcome additional committers and contributions.</p> |
| <!-- |
| Describe any initial contributions of code that will be brought to the |
| project. If there is no existing code, just remove this section. |
| --> |
| <h2>Mentors</h2> |
| <!-- |
| New Eclipse projects require a minimum of two mentors from the Architecture |
| Council. You need to identify two mentors before the project is created. The |
| proposal can be posted before this section is filled in (it's a little easier |
| to find a mentor when the proposal itself is public). |
| --> |
| <p>The following Architecture Council members will mentor this |
| project:</p> |
| <ul> |
| <li>Benjamin Cabé</li> |
| <li>Doug Schaefer</li> |
| </ul> |
| <h2>Interested Parties</h2> |
| <!-- |
| Provide a list of individuals, organisations, companies, and other Eclipse |
| projects that are interested in this project. This list will provide some |
| insight into who your project's community will ultimately include. Where |
| possible, include affiliations. Do not include email addresses. |
| --> |
| <p>The following individuals, organisations, companies and projects |
| have expressed interest in this project:</p> |
| |
| <ul> |
| <li>Sierra Wireless</li> |
| <li>Continental</li> |
| <li>Siemens/LMS</li> |
| <li>Sioux</li> |
| <li>BMW-CarIT</li> |
| <li>Rohde & Schwarz</li> |
| <li>Method Park</li> |
| <li>Robert Bosch GmbH</li> |
| </ul> |
| |
| <h2>Project Scheduling</h2> |
| <!-- |
| Describe, in rough terms, what the basic scheduling of the project will |
| be. You might, for example, include an indication of when an initial contribution |
| should be expected, when your first build will be ready, etc. Exact |
| dates are not required. |
| --> |
| <h2>Changes to this Document</h2> |
| <!-- |
| List any changes that have occurred in the document here. |
| You only need to document changes that have occurred after the document |
| has been posted live for the community to view and comment. |
| --> |
| <table> |
| <tr> |
| <td>25-November-2013</td> |
| <td>Added interested parties</td> |
| </tr> |
| <tr> |
| <td>4-November-2013</td> |
| <td>Added interested parties</td> |
| </tr> |
| <tr> |
| <td>07-October-2013</td> |
| <td>Document created</td> |
| </tr> |
| <tr> |
| <td>25-October-2013</td> |
| <td>Incorporated feedback</td> |
| </tr> |
| </table> |
| </body> |
| </html> |