MeeGo is out, what is in?

There has been some turmoil in the world of infotainment platforms. Intel has left Meego and have partnered with Samsung in Tizen. This just a few months after Meego 1.2 vas deemed GENIVI compliant. I have no idea if Tizen aims to be GENIVI compliant as well. But there are already some commercial platforms that are GENIVI compliant.

I have been involved in the Open Infotainment Labs, a project patially funded by VINNOVA aiming att evaluating radically different work methods compared to standard practice at most car manufacturers. We integrated the system in a car this week, 16 weeks after start of development.

AUTOSAR as open source

This might be the coolest thing I have seen so far: There exist an open source distributions of AUTOSAR!
And it's local to us here in Gothenburg, should I be embarassed for not hearing about this earlier?

Caveat: Note that if you intend to use AUTOSAR in a business setting you need to fulfill the conditions according to the AUTOSAR consortium.
After some e-mail exchange I now know that the open source AUTOSAR BSW software (ver 3.1) is available under a GPLv2-license.

Embedding Linux for an Automotive Environment

I thought this presentation was interesting enough to share, even if i have absolutely nothing to do with it: Embedding Linux for an Automotive Environment. I guess you need to have a thorough understanding of Linux to understand how the optimisations were implemented.

You can watch a videorecording of the talk as well.

Infotainment systems news

I have been more involved in development of infotainment systems this year. BMW demonstrates what they call ConnectedDrive and Ford updates their Sync system to what they call myFord Touch

Compared to the amount of information at the links above there is very little about the comparable 2010 Volvo infotainment system at the official Volvo website. Note that the BMW is just a concept vehicle, while the Volvo system in in production, and still has less information about it on the web.

When the car gets connected, it also gets exposed: Telematics and security: Protecting the connected car

Therer are some interesting news about some major players as well: Nokia announce a strategic partnership with Microsoft on 11 February. I have no idea how this will affect Meego and GENIVI. Time will tell...
On the other hand there was a lot of activity around GENIVI at the Consumer Electronics Show in Las Vegas. And GENIVI is based on Meego...

Available infotainment platforms

I have previously written about various platforms for infotainment systems. I also had a slide about it in my presentation on Lindholmen Software Development day, where my point was to say that it is possible to use either a commercial platform, such as Windows Embedded Automotive or an open source such as Meego. It is a business decisions which way an OEM wants to go, not a technical.

I have probaly missed some, but here is a list of infotainment platforms available today for an OEM to build an in-vehicle infotainment system on:

• Windows Embedded Automotive, used for example in Ford's Sync.
• QNX Aviage
• Mecel Betula Suite - Automotive Bluetooth Platform
• Meego
• GENIVI, but there is little informaiton about the techical solition on the webiste. They will most likely utilise the Meego platform.
• Harman has an infotainment platform. They recenlty acquired AHA Mobile which probably will be integrated.
• There are alot of notices on using Android for in-vehicle infotainment if one searches the web, but I have not been able to find any open source software based on Android for in-vehicle use.
• Continental's Autolinq seems to be Android-based, but is not open source in the same sense as e.g. Meego, and apps must be approved (by Continental?) to be downloaded.
• Luxoft offers LUXnet, which is also Android-based, but I cannot find any information besides a press release on their homepage.

Lindholmen software development day 2010

I held a presentation with the ambitious title The future of automotive software engineering at this years Lindholmen software development day.
The whole event was filmed so you can watch clips from me and the other presenters giving our talks when they are published (somewhere in the near future). Until then you can view my slides below, including the long list of references.

Meego

I have previously written about GENIVI and Moblin in this blog. I have to confess that I haven't followed the progress of either initiative.

GENIVI seems to be progressing, there is a new report on Marketing Requirements with a summary publicly available. But for an open source project it does not seem to be very open. It is interesting to note that they see themselves as different compared to a Linux platform, at least commercially.

Moblin seems to have been replaced by Meego as the in-vehicle Linux platform, with backin from Intel and Nokia. Meego had it's first release for In-Vehicle Infotainment in August this year. If I understand it correctly you can download it and run it as a infotainment system already now if you like, though I have not tried this...

I still believe that technically GENIVI will build on Moblin, or now Meego, but I cannot find anything about that on their homepage.

Books on programming embedded systems

I'm looking for a good text an programming embedded systems (for example an automotive ECU) but I can't find any that suits the bill. I was hoping to suggest something to students that avoids the trial and error learning methodology I had to endure.

A quick search on Amazon shows some which could be relevant:

• Programming Embedded Systems: With C and GNU Development Tools by Michael Barr and Anthony Massa
• An Embedded Software Primer by David E. Simon
• Embedded C by Michael J Pont
• Embedded Software Development with C by Kai Qian, David Den Haring and Li Cao

Especially the latter sounds interesting since I like the software architecture book from the same author.

I was thinking of writing a book myself on the subject. But it would mostly haven been a collection of data one can find on the internet with some detective work. Subjects to include would be:

• Introduction to C, since embedded systems are programmed in C. Period....
  I like K&R, but you can choose any book that suits the bill.
• Good coding practices in C, for example MISRA C rules.
  Read some example of MISRA C-rules here, here and here.
• RTOS basics, since this is what is used on most embedded systems.
  Read chapter 1 in the User & reference manual of rt:kernel from rt:labs for a good introduction. But personally I prefer the "run-to-completion" type of tasks which don't wait for external events for predictability.
• Interrupts, stacks, and memory handling - ISR, RAM, NVRAM, ROM, Flash and every other acronym you can think of...
• Development environments, and compilers for embedded development
  My experience is that this is pretty much decided by the OS you are using. I have experienced very mysterious bugs just by not having the correct compiler version, so I can' imagine what could happen when having a compiler from a different vendor... IAR graciously provides all of their manuals free of charge and their IDE and compilers on 30-day on a 30-day free trial.
• Various hardware on a typical embedded controller - Details on how to access hardware with code examples.
  You can see examples of typical hardware devices in the Freescale MC9S12XS256 Reference Manual, a typical automotive processor, especially chapter 10-19. Mind you that this manual is 738 pages long, so it's pedagogical value is limited.
• Debugging - Too much to cover for this blog post. This is the real dark arts...
• Architecture of embedded systems
  Almost all embedded systems are layered, but why? And how do you know which layers to have in your system? And how do you identify the tasks you should have when schedule the system?

On variants...

During my research I gained some inside information into how various automotive manufacturers work. One very interesting observation is to see how different companies approach variants.

I know of two high-end companies having as a general architectural strategy not to have variants of systems or ECUs. Note that the electrical system as a whole may me different due to e.g. feature content, but if the system has a body control module there only exist one variant of that module both in development and manufacturing. To my understanding they are only using the optional variant in F. Bachmann and L. Bass, "Managing variability in software architectures," SIGSOFT Software Engineering Notes, vol. 26, 2001, pp. 126-132, and not any of the other types.

Personally I think that this is very beneficial for a company, both from an engineering and from a manufacturing perspective, even if it seems wasteful not to cost-optimise an ECU.

But this strategy is probably not for everyone. There are some common characteristics between these two companies:

• The are both high-end brands and have customers that can afford to buy the best.
• They are not mass producers, only in the order of 100k vehicles per year. This means that development costs are not negligible to article cost, even if they are smaller.
• Tailoring to the customer needs is an important business strategy.
• The have unusually high ROI compared to the average for the automotive industry. Being successful is another way of describing it.

And no, Volvo Cars is not one of the two companies...

The question is how you "dare" to go for such an architectural strategy if you are not already doing it? I think developing a business case to show that you would earn more $$$ with such a strategy would be extremely difficult.

Presentation on lean product development

I got a link from a colleague with a presentation on Lean development at Jaguar and Land Rover by Baback Yazdani. The interesting part starts after 14 minutes.

See the presentation, it is one of the best I've heard that focuses on lean product development (instead of lean manufacturing), and acknowldges the fact that not all value created by PD can be measured in money (for example the ability to do rapid development is a product of doing development). He also states that the critical issue of lean in PD is about reducing lead time.

One of the key things I think everybody should remember from the presentation is that you should not (cannot) utilise a development organisation more than 70-80% if you want to go lean. If you do that there will not be enough "thinking time" to identify potential improvements.

Ford's new infotainment

It should come as no surprise that Ford is one of the leading automotive companies when it comes to infotainment systems and vehicle connectivity. Read an in-depth interview with Alan Mulally on the topic.

The new Ford My Touch just confirms this position. As an architect I am impressed by how they manage to coordinate suppliers as Gracenote, Nuance, Sony and Verizon into what appears as a seamless system based on Microsoft Auto, a system that can directly use services from Inrix, Pandora, Stitcher, Telenav and Twitter.
One side effect of connecting the vehicle with everyting else is the security of the information stored in the car, as described in this blog by Steve Cypher

Read what other blogs have to say about Ford My Touch.

EAST-ADL2 and AUTOSAR

EAST-ADL2 is an automotive architecture description language "with improved means for capturing the requirements, characteristics and configurations of cooperative systems and the related analysis and V&V."
I was involved in the first ATESST project on how to align the ADL with the AUTOSAR meta-model.

There is a webinar presenting the latest results from the ATESST 2 project on EAST-ADL2 and AUTOSAR. More information about the results and registration for the webinar can be found in the ATESST2 newsletter.

Object-oriented programming in C

In the automotive industry C is the totally dominating programming language. I guess this is because of the limited resources in automotive-specific CPUs but also because of tradition among programmers, if you have a program that is proven by use you don't rewrite that just because there is some new language around.
And to be honest, it still is hard to beat C if you want real-time properties and a garbage collection that don't risk overflowing memory.

But if you want to keep C but write programs in a more object-oriented style how do you do? It is not as hard as one would think.
Here are some web pages which give some useful tips. Note that they are not always compatible!

• Phil's guide to object-oriented ANSI C
• Object-oriented programming in C by Paul Field
• Object-oriented programming in ANSI- C by Axel-Tobias Schreiner

I have reviewed code for several ECUs used in Volvo cars, and none have used an object-oriented style. The reason I bring up object-oriented programming in C in this blog is that it simplifies the implementation of many patterns, the subject is not really new...

"Inspiration Day" on Vehicle Information and Communication Technology

I attended an "inspiration day" on Vehicle Information and Communication Technology (VICT) last week, arranged by Lindholmen Science Park and VINNOVA.
The purpose of the day was to display current Swedish research in the area and hopefully give ideas to new research projects. It was attended by a mix of people from industry, academia and government.

All presentations are available online here. Some in English and most in Swedish, not much I can do about that...

Lack of process view of automotive software

When discussing an architectural problem with my colleagues we identified that an initialisation/activation mechanism could be defined either as a method used between logical components or as an initialisation between run-time processes. But we could not propose the second mechanism since it would be impossible to communicate to the developers.

The reason for this is that we are not using a process view at Volvo (or at any other OEM that I have worked with either). With process view I mean the view as defined in the 4+1 paper by P. Kruchten. And I have not seen any other viewpoint used here that would fulfil a similar purpose.
This has some interesting implications:

• The deployment of functionality is in Kruchten's paper done by assigning logical components to processes and the deploying the processes onto the physical view. Among OEMs the deployment relationship is directly between static logical components and the hardware (i.e. ECUs). So there is no possibility to express concepts as "concurrency", "precedes" or "is activated by".
• It must be the responsibility of the ECU suppliers to define the process view of their ECU. And to be honest I have no idea if they do since this is not requested nor followed up by OEMs...
• The fundamental building block in AUTOSAR is the software component (SW-C), which can be called a static logical component if one is not too much of perfectionist with meta-models. The SW-C contains runnable entities which is the entity that is scheduled. But also in AUTOSAR it is the SW-C and not the runnable entities that are deployed to ECUs. I think this is driven by the first item above...
• Since it is the static SW-C that has the explicit relationship to other ECUs through the defined port and interface mechanisms in AUTOSAR there is no possibility to define a "dynamic" mechanism to "activate", "run simultaneously" or something similar usually defined in a process view (or process architecture).

I was thinking of writing a short paper elaborating on this and relating it to some research papers, but I probably will not. First it is not directly in line with the subject of my thesis. Second there are more pressing things to do. So if anybody else wants to pursue this I would be glad to be a co-author, discussion partner ot at least get mentioned in the acknowledgements.

Presentation on the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture

Here are the slides I used at my presentation at the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture in Cambridge 2009.

The presentation went well, but the questions showed that the audience was more interested in how the organisation perceived the role of it's own software architecture rather than the methodology and scientific conclusions. And the role of architecture was one thing that was not possible to generalise to other organisations...

Yet another article on Ethernet, Firewire and MOST...

Yet another article on what communication technology will be used in future infotainment systems. Read it fast since the articles in Automotive Engineering tends to be removed from the on-line edition after a while...

ETHERNET and 1394 spar with MOST for infotainment openings

Most interesting to read that Toyota starts using MOST now in two vehicles (new Prius and Lexus RX). I have the impression that they would not "commit" to such a change in technology if they did not belive it would stay.

Review of the vehicle’s electrical and electronic architecture

Just being back from my summer vacation hiatus I found a good summary of present challenges for a vehicle’s electrical and electronic architecture from just-auto. I haven't figured out if the news archive is available forever so read it fast if you are interested...

A second interesting article was about the use of firewire (1394) in automotive applications: 1394 Automotive network enables powerful, cost-efficient in-vehicle networks for infotainment, navigation, cameras from Automotive DesignLine.

Some blog posts

Some blog posts which I think are interesting from an automotive software architecture viewpoint:

• Riversimple to Unveil Open Source Car in London This Month
• Genivi's Open Source Car Infotainment Efforts Ramping Up
• Video: Open Source for Car Infotainment
• GENIVI no threat to Microsoft in near term
• What TomTom suit may really be about

What are OEMs doing in the field of software architecture?

A colleague from Ford in Dearborn asked me if I had any information on activities at other OEMs and Tier 1 suppliers in the area of software architecture. I did a quick search in my Zotero database and arrived at the following list. Some are available on-line, use Google Scholar to find.

1. F. Fabbrini, M. Fusani, G. Lami, and E. Sivera, “Software Engineering in the European Automotive Industry: Achievements and Challenges,” Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International, 2008, pp. 1039-1044
   Paper from Fiat


2. P. Giusto, S. Kanajan, C. Pinello, and M. Chiodo, “A Conceptual Data Model for the Architecture Exploration of Automotive Distributed Embedded Architectures,” Information Reuse and Integration, 2007. IRI 2007. IEEE International Conference on, 2007, pp. 582-587.
   Paper from General Motors


3. K. Grimm, “Software technology in an automotive company: major challenges,” Proceedings of the 25th International Conference on Software Engineering, Portland, Oregon: IEEE Computer Society, 2003, pp. 498-503.
   Paper from Daimler


4. Hans Grönniger, Jochen Hartmann, Holger Krahn, Stefan Kriebel, Lutz Rothhardt, and Bernhard Rumpe, “View-Centric Modeling of Automotive Logical Architectures,” TU Braunschweig, 2008.
   Paper from BMW


5. G. Reichart and M. Haneberg, “Key Drivers for a Future System Architecture in Vehicles,” Proc. Convergence 2004, Detroit, MI, USA: SAE, 2004.
   Paper from BMW


6. C. Tischer, A. Muller, M. Ketterer, and L. Geyer, “Why does it take that long? Establishing Product Lines in the Automotive Domain,” Software Product Line Conference, 2007. SPLC 2007. 11th International, 2007, pp. 269-274.
   Experience paper from Bosch engine management systems


7. S. Voget, “Future Trends in Software Architectures for Automotive Systems,” Advanced Microsystems for Automotive Applications 2003, Springer, 2003, pp. 457-469.
   Paper from Bosch


8. K. Nishikawa and K. Kajio, “TOYOTA Electronic Architecture and AUTOSAR Pilot,” Proc. SAE World Congress, Detroit, MI, USA: SAE, 2007.
   Paper from Toyota


9. D. Selin et al., “A Reference Architecture for Infotainment Systems,” Proc. Convergence 2004, Detroit, MI, USA: SAE, 2006, Document Number: 2006-21-0013
   Experience paper from Volvo Car Corporation


10. R. McGee, “Managing Vehicle Control System Architecture is a Key Enabler for Strategic Reuse,” National Workshop On High Confidence Automotive Cyber-Physical Systems, April 3-4, 2008, Troy, Michigan (USA)
    Position paper from Ford Motor Company

The list is not very long. I have some reasons why:

• Most research articles on automotive software architecture are written by researchers, not car manufacturers.
• Strategic decisions on software architecture can be seen as a business advantages and are therefore not published.
• I have a a quite long backlog of articles in the area of automotive software architecture which I have not read yet, there may be more among those.

I have also some news flashes in previous post in this blog which might be of interest. Search the label of Automotive software.