Eclipse Summit Europe 2008: The Automotive Working Group Meeting Afterwards

I held off publishing this blog about the automotive working group meeting that was held after Eclipse Summit Europe so that discussions could continue quietly in the background. However, given that Ralph let the cat out of the bag, I thought folks might be interested in what happened at that first meeting back in November...

My day started with breakfast with Mike, Ian, Doug, and Ralph. Then we headed by train to the Bosch site where the meeting was hosted. There was quite a large turn-out for the group, 22 in all.


Mike presented first, reviewing the history that led to the creation of the Eclipse Foundation as an independent entity.


According to Evans Data, there are 4 million developers using Eclipse daily, and 6 million if you include the vendor based products built on Eclipse. In Eclipse 1.0, Eclipse was primary just a Java IDE. For 2.0, it evolved to become a generalized tools integration platform. For 3.0, with Rich Client Platform, it evolved to come a desktop application integration platform. Today, Eclipse and Microsoft are the two dominant tools platforms.

A key to the Eclipse platforms success is the uniform component model that puts all contributions on an equal footing and make it easier to add little things or big things to the application. Open APIs and a commercially friendly licenses help to lower the barrier to entry. Eclipse has established proven best-practice processes around these ideas and these can be reused by industry vertical working groups to get a jump start on getting up and running. The maturity of an organization's policy around open source tends to progress from deny, use, contribute, champion, and finally value co-creation.

Doug Gaff presented on CDT, DSDP, and the lessons learned about working collaboratively in open source.


CDT has evolved to become an extremely high quality popular C/C++ IDE. It's used for things like embedded, linux, and high performance computing. DSDP is a container project for embedded and mobile technology. There are now more than 40 committers from 11 companies. There is support for debugging of embedded devices which features things like memory rendering. as well as target management that includes a remote systems explorer and a framework for managing communication with the targets. Real-time software components, Tools for Mobile Linux, Native Application Builder, Mobile Tools for Java and a proposal for FireFly, a Mobile Web Devleopment Kit targeting iPhone and other devices, rounds off the slate. Much of this technology is very likely to be applicable in the automotive industry.


Then it was my turn to do the 20 minute modeling dog and pony show; check out the conformance to Ralph's dress code!


Next Ralph presented some background about TOPCASED, a French consortium focused on building world-class open source modeling technology.


Two mistakes they admit to making: they focused too narrowly only on the aerospace industry,
and they focused too narrowly only in France. Both limited adoption. Of course many of these people are now committers at Eclipse on projects like Ecore Tools and Papyrus.

After a coffee break we had a round table introduction and some initial position discussions. Stefan Ferber of Bosch, drove home the point that it's very important to manage diverse groups of people who are often split geographically across different countries. The tool expenses are growing out of hand and that's primarily caused by inefficiencies in the system and with shrinking budgets are no longer affordable. Something needs to be done to make the tool vendors more efficient and Bosch is highly motivated to forge a new path.

Ulrich Schopf also of Bosch talked about some of the efficiencies they've focused on in the past,
e.g., the unification of the tool chain around gas and diesel engines.

Ramy Asselin of General Motors was able to attend following an AUTOSAR meeting.


He's currently working on a master's degree. Their goal is to arrive at a single tool set and processes based on open data where both the tools and data evolve over time. They definitely intend to leverage AUTOSAR. The software in vehicles is growing in complexity faster than is the capacity growing to accommodate that.


They need to improve sharing and integration and need to manage better the impact of design changes.

Thomas Hermes of IAV talked about the tools they need being too expensive, full of features they don't need, but for which they pay, and yet missing specific features they really do need. They'd prefer to see more componentized tools into which they could contribute the things they need. They don't care about tools, only about the results they get from those tools.

Hans Kugler helps other people improve the way they manage the software process. The improvements needed by the car industry is needed across the whole ecosystem; improvements within individual organizations won't suffice for the kinds of problems we are seeing. He definitely encourages the development of a common platform as a drive toward huge cost savings measure as well as something to foster more innovation.

Axel Schultze of IAV talked about how everywhere they go they run into customers with customized processes. It's very inefficient for them to have so little commonality of tool reuse across their customer base. Lack of tools around the system architecture of a car it painful as well. He mentioned their involvement in AUTOSAR which he sees as a good start, but perhaps not sufficient. License costs have become prohibitive because as much as 15% of a developer's cost is attributed to the cost of the tools.

Nest Wolfgang Neuhaus of itemis talked about his interests in this space. Itemis is heavily involved in providing help to develop domain specific languages in the embedded space. He asserts that an open tool platform will inevitably exist, so it's primarily a question of what form will it take, and who will get involved to drive the direction. Itemis recognized this inevitable end result as evidenced by they fact that it has open sourcing all its tools and technologies.

Martin Thomas of Bosch mentioned the gas and diesel tool chain unification as an example of the kind of cost savings that are needed. He considers Artop too closed in its current form. AUTOSAR is very important and he wants to see an open source project around this. The current effort is far too closed and will not produce the type of open ecosystem that's needed. He repeated my think big but start small, which I'd earlier termed as start small but aim high.

Markus Utz of Bosch reiterated some of the themes about how the current cost structure is stifling innovation. He too wants to work together with others.

Martin Richter of IAV talked again about the plethora of OEM development environments. It's just too painful and wasteful.

Peter Horn of Intel talked about why they are doing tools. Primarily they want to ensure that there is a good tool set available for people to exploit Intel's chips and hence improve the uptake.
They have good compilers, for example, that typically have 20% performance improvements over gcc. Faster code makes their chips seem faster. They want there to be a full tool chain that best exploits the silicon and are interested in the automotive industry's specific requirements.

Joerg Zimmer of BMW is interest in seeing a solid tool chain. Lutz Rothhardt also of BMW talked about how to manage all the different controllers in a vehicle. Their mirror, for example, has 5 or 6 inputs to decide whether to heat the mirror. It's gotten to be too complex to manage the dependencies between all the components for the purposes of change impact analysis. Even gathering the data within their organization is far too complex. The costs of a mistake in a shipped vehicle is extremely high. They want to see vendors competing so they don't become complacent but rather continue to focus on quality and innovation to maintain their position.

Michael Rudorfer of ARTOP talked about their development efforts around AUTOSAR.


They see a need for a common AUTOSAR model upon which to build tools to foster better interoperability. AUTOSAR's license restricts disclosure of the specification to members only, which effectively blocks the ability to turn it into an open source project. So they're trying to be open, but can only be open within the membership. The theme here is much like that I described earlier, i.e., building a common model and then encouraging tool vendors to compete in providing the best tools around that model, and to add specialized complimentary add-ons to any tool. They are currently working to build an EMF-based model, which was the topic of some conversations I had yesterday that ESE.

Minoru Okada of Dendso talked about his role in process development which is made more difficult by the lack of a coherent tool chain. It's often far too difficult to chain tools properly. He pointed out that the Japanese automotive software industry is many years behind and is simply not familiar with Eclipse.

Martin Beckel is from Continental, which was big in things like tires, but they've grown by acquisition and have ended up with a diverse set of tools; this type of diversity is not the good kind! They need to unify this. Exchanging software components is way too big a task, so they badly need something to integrate easily the various software components they reply upon. They're also involved in TOPCASED and Artop, so they're well aware of the benefits of collaboration. Even when there are good commercial tools, those often don't integrate with Eclipse nor with each other.

Nils Nilson of Johnson Controls repeated the concern about islands of tools; there really need to be bridges. Collectively there are a huge number of people with good ideas so doing work collectively will be a huge improvement.

Ralph summarized some of the issues and then Mike talked about some steps we could take to build an ecosystem on a well defined platform.


The first step might be to define an Eclipse package that assembles some of the key pieces of Eclipse that are expected to be of ubiquitous use, e.g., CDT, parts of DSDP, and EMF. This would establish a straw man base line. It would certainly start sending the right signals; tool vendors and the AUTOSAR folks are likely to take note. This starts to create an ecosystem with empty niches just waiting to be filled. Surprising players will turn up and do surprising things; that's what innovation is all about. It's important to define a roadmap, spell out the requirements wishlist, and sketch a viable business and governance model around all this.