A few days ago I posted a comment on Jim Whitehurst’s article, stating my opinion that his request to make mission critical application software of the ECUs is unrealistic. So does that mean that open source software has no future in automotive? Of course not. The software of an automotive company could be divided into the following categories:

• Business Software (e.g. SAP, Oracle, Web Servers)
• Development Tools (everything for the product lifecycle, i.e. requirements, design, implementation)
• Basic Software for ECUs (i.e. the “Operating System”)
• Application Software

Obviously, for the Business Software, the automotive industry is not too different from other industries. Open source alternatives exists and are in use (like Apache Web servers etc.) to some degree.

The development tools are experiencing an increase of open source software through the use of Eclipse. A number of OEMs, suppliers and tool vendors are using Eclipse as a platform for standard and company specific tool development. GMF, EMF, Xtext and others are widely accepted. The commercially reliable license of Eclipse is a strong factor for the adoption of the platform. And the commitment to Eclipse starts to pour back to the open source community: The new Sphinx project proposal is based on a code base that was developed by the Artop members.

Basic Software has not played a major role in open source yet. One factor being, that there was not a widely accepted standard before AUTOSAR (yes, there was OSEK, but AUTOSAR might bring more attention). Right now, there is no established open source code base for AUTOSAR, but with everything being standardized, this might start with simple modules.

Application Software (your driving assistance, dynamics, enginge control) etc. will still be considered an important setting and not be easily migrated to an open source model.

However, open sourcing application software would probably have a small effect on quality only. Improving the development tool chain is going to yield better results. And open source offers a lot for the tool chain.

Red Hat CEO Jim Whitehurst voices his opinion that open sourcing the embedded software in automobiles would significantly increase quality in an article published in business weekly. Being an advocate of open source myself, I still think Mr. Whitehurst hasn’t done the open source community a service, because he superficially claims that open sourcing software would solve problems, without addressing any of the issues that arise:

• The business model: The user functions that differentiate one car from another largely depend on software. Especially in the premium segment, introducing new functionality is one of the key factors. If you introduce a new function, like night vision, you do not want to give away your investments. This is one of the core parts of the business. Mr. Whitehurst does not show explain how a new business model for the industry could look like.
• Knowledge: Software functions in automotive are extremely complex and not only require know-how in physics, engineering but also in international requlations. How big is the community that could really understand these systems and contribute?
• Testing: Mr. Whitehurst cites successful examples of open source: Firefox, php, and others. But here’s the catch: Those systems can be build and tested by anyone with a PC. Embedded software is inherently different. ECUs usually have specific hardware (different sensors) etc. To really test a system, you need a lot of hardware (including sensors and actors), you have to go to Norway in winter for cold weather testing and Dubai in summer for hot weather testing.  HIL testing is necessary. This greatly reduces the target audience.
  In addition, no OEM can allow you to reprogram your car and drive it on public streets.
• MBSE: Physical functions are often designed with tools like Mathlab / Simulink or Ascet / SD. Open Sourcing the generated code from those tools is next to useless. So you’d have to  open source the models, which require tools with expensive licenses to work with.
• Safety: Non of the quoted open source software is safety-relevant (how many people die if your Firefox browser crashes and is not available for 3 seconds?).  Safety relevant software has to be carefully designed, for moral and for legal reasons. So where are the references to successful open source projects with SIL (safety-integrity-levels) requirements?
• Supplier: Requesting that “Toyota should open source its software” neglects the situation of IP rights. Software is usually only written in small parts by the car manufacturers (OEM) but largely by suppliers of ECUs (e.g. Bosch, Denso).
• Kaizen and Open Source: Whitehurst implies that Kaizen for software means Open Source and that Toyota should transfer its principles of Kaizen to software. If that is so, where can we download the specifications of Toyota motors, constructions plans etc.? Kaizen obvioulsy does not mean open sourcing anything.

The article quotes “Toyota acknowledged that a software glitch was to blame for braking problems in 2010 Prius vehicles, and the company changed its braking system software in January to address the problem.” However, if you read this article by CNN, you will see that the braking problem relates to the software for hybrid systems, which are considerably different from traditional braking. There is no proof, that this problem could have been avoided by open source.