Future car trends?

Here are some external links that might be of interest. I cannot vouch for the accuracy of the trend predictions (lets say they don't fulfill the criteria for scientific papers), but they give input to forming personal opinions.

• A comprehensive study on innovation in the automotive industry. Note that the report is from 2007 and much of what they predict to 2015 is still far away...
• Think How Much Smarter Your Car Will Be In A Few Years. Some insight into cutting edge car technology.

Thesis chapter 12.1.7: Is automotive software different?

The context for the automotive industry regarding software development is not different compared to other embedded domains. This conclusion is based on the mapping study in chapter 7 over different approaches of embedded software development and the case studies performed in chapters 5 and 6.

Thesis chapter 2: Research motivation

Embedded software is becoming increasingly complex. Ebert & Jones show that the size and complexity of software in an embedded product increases exponentially over time. Numbers from Volvo Cars show a similar exponential evolution (seen in figure the figure below), not only for the infotainment software, which resembles mobile phone features, but also for "traditional" vehicle functionality.

Software in Mbytes downloaded in a vehicle at production at VCC over the years.

Ebert & Jones mention factors contributing to the complexity in their survey of the present state of embedded software development: ``combined software/hardware systems equipped with distributed software, computers, sensors, and actuators'' which points to the integration aspects of these systems. They list "high demands on availability, safety, information security, and interoperability" as typical quality attributes.

Ronkainen & Abrahamsson also emphasise that embedded systems are characterised by the concurrent co-design of hardware and software. They stress that the `"dynamics of co-design - i.e. the way it effects the concurrent software development processes, has to be understood in order to enable the use of agile software development methods."

Manhart & Schneider describe agile development of software in buses at Daimler-Chrysler. They mention for example that "equipment, functions, or parameter sets are implemented by integrating different proportions of third party- and OEM manufactured components" indicating supplier involvement. In their paper they also point out that software realises "complex electric or electronic functions", e.g. the integration between hardware and software.

The domain of large industrial development of mass-produced embedded systems can thus be defined by five characteristics:

• Deep integration between hardware and software for significant parts of the functionality 
• Strong focus on manufacturing aspects of the product during development (e.g. by project gates) 
• Strong supplier involvement providing a majority of the parts, and associated value, of the finished product 
• Some parts of the software and hardware realise safety-critical functionality 
• Long production life-time, sometimes spanning years for a single product model

These types of systems can be categorised as mass-produced embedded systems (MPES).

Broy states some challenges that automotive software is experiencing: "The high intensity of software in cars puts the car industry under stress and a high change pressure." He continues that the trend is not close to an end, and is driven by e.g: "High demand of new innovative or improved functionality'', "shorter time-to-market'' and "increased individualization".

In addition to these challenges the development of MPES exhibit some inherent problems for the R&D organisation, amplified by the present ecosystem of specialised suppliers and OEMs acting as system integrators:

• Heavy reliance on external developers and subcontractors complicates coordination through process because each of them use their own processes.
• Outsourcing of significant parts of development to suppliers causes expensive communication and coordination delays during integration. The cause of this is each issue found must be resolved through an OEM-supplier roundtrip with the OEM identifying the issue, discuss with the supplier(s) who resolves it, and the OEM re-integrating the "fixed" parts.
• The exponentially growing feature content severely complicates "big-bang" integration because used architectures requires all parts to be present for the system to work and therefore testable.

This research project started with the ambition to create opportunities provided by an R&D organisation in terms of new ways-of-working, new architectures, and possibly supporting new ecosystems. These opportunities could enable new business models for OEMs delivering mass-produced embedded systems, while at the same time mitigate some of the problems described above.

The choice of focusing on ways-of-working, architectures and ecosystems was done for three subjective reasons: In my experience it is easier to change these aspects than e.g. culture, knowledge management, or organizational structures. My engineering background made it easier for me to analyse and develop artefacts in these areas. This is a thesis in software engineering, and all these three areas are well within this field of research.

Thesis chapter1: Software in mass-produced embedded systems

Software is prevalent in many products manufactured today; cars, washing machines, mobile phones, airplanes and satellites (link to paper), the embedded software controls the behaviour of the product and is often critical for the success of the product.

Typically these products are developed in large, and sometimes very complex, industrial projects where the manufacturing and delivery of the product in general is a heavier investment than the software budget. In the automotive domain the purchasing and manufacturing cost of the physical parts for each product is typically an order of magnitude higher than the R&D cost split over the number of products built.
This in turn tends to drive the entire R&D process, and software follows the process logic of the mechanical development and manufacturing setup.

Software differs compared to its mechanical and electronic counterparts; once the software is developed there is no additional cost if one increases the number of products produced.
Likewise, the cost of updating or replacing software in an already built product is orders of magnitude cheaper compared to replacing hardware.

The common business model is to sell the manufactured system as a product, the original equipment manufacturer (OEM) gets paid an agreed amount for each system delivered. From a customer perspective there are some issues with this present business model when it comes to features purely relying on software. An example scenario in the automotive domain could be:

My neighbour bought a new Volvo four months after I did.
He got Spotify, but I didn't.
Do I feel ``cheated''?

Another example scenario would be

Google music turns out to be the next hot thing. It takes Volvo 30 months to include this feature according to the present stage gate process. Is the feature still ``fresh'' when delivered?

A future scenario could be that Spotify is deployed to customers independently of when the car is built in the factory, i.e. after the customer has received the vehicle.

With more and more vehicles becoming connected it is conceivable to have continuous updates with new software features to customers on a scale and to a cost that is impossible would the updates require hardware modifications. This would build trust in the brand to maintain a useful product and extend the value for the customer after the purchase.

The team developing Google music could deploy it after 3 months of development, making it ``almost competitive'' with smartphones. More and more services are used regardless if one is using the phone or driving in a car, and from a customer perspective it is difficult to understand why services in one context is cannot be delivered in another.

The topic of investigation in this thesis is efficient and sustainable development of software for mass-produced embedded systems (MPES), and the implications a chosen way-of-working and software architecture have on R&D, and indirectly on the business.

Thesis: Preface

I promised to post my thesis in a previous post. I hoped to have done so already last week, but things don’t always go according to plan. Here is at least the preface.

I don’t know if I should post a new chapter every day during Christmas, if I want to attract readers interested in development of software for embedded systems I guess this it’s not the best period.

This thesis is the result of my conviction that there was an untapped potential of improving present software development in the automotive domain, based on 10 years of industrial experience at Volvo Car Corporation.

The research project described in this thesis started with a goal of improving the architecture process and the management of software architectures in the automotive domain.
The goal evolved as the project progressed to use the right architecture as a means to improve the overall software development process in order to enable shorter leadtimes and to develop and release new features at a sustainable pace indefinitely.

I started the research project with the assumption that one of the main reasons for the automotive domain of not adopting best practices from other domains is that this domain has very different prerequisites compared to other domains, in the form of business practices, architectures and product properties. An assumption that I have completely reversed since I could find nothing in my empirical data supporting it when I compared with published cases form other domains.
The only reasons left that could explain this is a culture of “not invented here” in the automotive domain when we are looking at how software businesses, architectures, processes and teams play out in other domains.
Hopefully this thesis could be a step towards a better understanding that the automotive domain has more in common with other domains of software-intensive systems, than differences.

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.