Engineering logo

Bosch logo

Intland logo

RCP logo

BMW logo

Sigsdatacom logo

BSI logo

Microsoft logo

CAS logo

Andrena logo

bsi logo

OSBF logo

Open Source logo

Bredex logo

sopera logo

Microdoc logo

O'Reilly logo

Soyatec logo

compeople logo

itemis logo

dpunkt logo

Sontatype logo

Eclipsesource logo

sap logo

Xored logo

Oracle logo

Vogel logo

Actuate logo

The adventure of building an Eclipse-based IDE for embedded automotive software developers

Lars Geyer-Blaumeiser

Embedded · Long
Thursday, 10:30, 55 minutes | Seminarräume 1-3


The adventure of building an Eclipse-based IDE for embedded automotive software developers

The complexity of development tools for automotive ECU software developers has various sources:

  • Handling the complexity of the car IT infrastructure.
    • Several control units for different tasks communicate constantly over different network technologies.
    • The correponsing architecture has to be mastered and maintained over a long period of time.
  • Support for the developers handling complex methodologies like Autosar.
  • Support the complexity of processes with several roles interacting with each other, thereby ensuring the quality of the final product. Each role has specific requirements on the tools.
  • Distribution of thousands of developers on multiple sites all over the world. The developers need to cooperate using a common component base and distributed development processes.
  • Optimization to the tasks needed. Typically, the average developer is not interested to have a cool tool, instead he expects to have a tool which supports him in performing his process steps in an optimal way.

Bosch started several years ago with the development of an Eclipse based IDE which helps mastering the complexity of the domain. Over the years Eclipse RCP based tools emerged which are in use today. These tools are currently unified into one common IDE to be used by all developers of the business unit with most software developers. In the near future, this system will be the root of Eclipse based IDEs in other business units as well as the core of the Bosch wide unified Autosar tooling environment.

The architecure of the IDE has a metadata model at its core. Development data, i.e., Autosar metadata and MSR metadata are held in EMF based models (Artop, resp. a Bosch internal MSR model called BDOM) which are used for editing and validation. Internally developed editors and validations together with necessary infrastructure (workspace management, validation and editing frameworks) build the core of the development environment. The CDT is used as C development environment, enhanced with functionality that bring together the EMF models and C code editing. Parts of the software is genereated using XPand and Perl scripts. Connectors to the Bosch specific SCM system have been invented as well. All in all, the distribution has a size of 750 MB on the clients disc.

The advantages we see in using Eclipse:
  • A big amount of stable, industrial strength functionality easily applicable in our context.
  • The great extensibility which allows us to easily add functionality we need proprietarily to our IDE.
  • The community of experts which can be recruited for specific tasks.
  • The modeling projects which allow to easily handle and maintain large complex data structures.

Nonetheless we faced quite some challenges when applying Eclipse:

  • Scalability of technologies, the model for one ECU project can reach the limits imposed by the JVM.
  • Difficulty of model technologies (Modeling right to support all use cases).
  • Internal complexity when appying the Eclipse builder mechanism.
  • Content types as a constant performance thread.
  • Historical dependencies within Eclipse creating bulkiness.
  • Breaking exiting functionality with P2.
  • Eclipse is good at adding something but removing...
  • Including a simple and small XML editor.
  • CDT has shortcomings for embedded software development:
    • Highly variant c code (#if) is not supported by CDT but most developers need to see the whole code, not only the current configuration.
    • Integration with the rest of Eclipse is not optimal, e.g., EMF models for internal data structures (offering better integration with other models like Artop).
    • Difficult inclusion of compilers and debuggers for embedded controler, also code quality tools like qac.
    • Extensibility and documentation is limited.

In summary, Eclipse is a great vehicle for the development of a domain specific IDE. But still a lot of technological issues are unsolved and need attention. Some of them even threatening the success of the effort.

Lars Geyer-Blaumeiser works within Robert Bosch GmbH as a team lead for the development of Eclipse based IDEs for different business units. His team is responsible for the integration and distribution of the different components to one IDE, the development of a platform build from Eclipse projects, the development of the core components including big EMF based models, the architecture of Eclipse based systems, and the strategic architecture of business unit related development environments. Lars made his PhD at the University of Kaiserlautern on variant handling in product lines. After an intermezzo on this topic in the Bosch research unit, he moved to the tools department to get involved in the Eclipse strategies of Bosch three years ago.