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.

Exploring variation mechanisms in the automotive industry: a case study

I supervised a thesis project on run-time variability in an AUTOSAR architecture.
You can read about the project, and download the thesis report, at the student's web site: quandoo.

Competitiveness from structuring of AUTOSAR applications

AUTOSAR 4.0 was released some time ago, and in certain areas it was a major update compared to version 3.1 of the standard. Besides the changes to the Basic Software one of the things I think may have a great impact when it comes to sourcing software from suppliers are the results from the 10.x work packages that deals with application interfaces (i.e. interfaces of the software components above the RTE).

In my mind structuring the applications and standardising their interfaces pretty much defined what quality attributes ("-ilities") the software would have, especially when it comes to "Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system" to quote wikipedia. So with the OEM-supplier relationships that most vehicle manufacturers have and with the static structure standardised by AUTOSAR it would be almost impossible to compete with the "-ilities above. So how does one use AUTOSAR and "cooperate on standards, compete on implementation"?

I got the answer in a paper by Simon Fürst et al. presented at 14th International VDI Congress Electronic Systems for Vehicles 2009 in Baden-Baden.

"In general, applications are the competitive edge of an ECU. AUTOSAR is not going to standardize the functional internal behavior of an application (e.g. algorithms, optimization) but the content exchanged between applications. This clarifies the exchange of applications between the automotive community, from OEM to suppliers as well as supplier to supplier and so forth."

So competitiveness is "only" achieved by algorithm optimisation? A typical control engineer's viewpoint and not a software engineer's? This means that an OEM can only distinguish itself from the competitors by run-time qualities and not by qualities such as evolvability or testability?

Do I even need to say that this is my personal opinion based on the teaching I do in software architecture and does not necessarily reflect my colleagues' opinions or the company I work for.

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.

AUTOSAR webinar

Vector hosts a webinar on the basics of ECU development with AUTOSAR on 24 November 10:00 EST. You can register for the webinar here.

Sorry for the shameless plug for a commercial company, but at least this seems to be free. And there are few opportunities to learn more about AUTOSAR that is not hosted by a tool vendor or supplier...

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.

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.

More news and press releases

Here are some interesting news and press releases:

• Download, install and drive – the future of automotive software from ICT Results
• Mentor Graphics Strengthens Its Automotive Solutions with New Integrated AUTOSAR Design Environment
• AUTOSAR marks its series production debut - in the new BMW 7 Series
• Hansen lists top ten automotive electronic trends from John Day's Auto Electronics Blog

I finish with a quote to keep in mind when designing architectures:

"Warum soll man es einfach machen, wenn man es so schön komplizieren kann?"

which roughly translates to

"Why should we make it simple when it can be made so beautifully complicated?"

I don't know where it originally comes from though...

Seminar: Development of AUTOSAR compliant Control Units with Model-Based Design

I have just attended a joint presentation from MathWorks and Vector about model-based development of AUTOSAR Software Components. Besides the fact that I won a t-shirt (I'm still unsure if it was for the most stupid question or the first really interesting question) it was very interesting to hear both what they had to say and what others in the 80+ crowd had for questions.

Here are some spontaneous observations I wrote down while listening to the speakers (the keyword is spontaneous):

• Vector works actively with the following OEMs to implement AUTOSAR in their vehicles: Audi, BMW, Daimler, VW and Volvo Group. The first vehicles will be on the market in 2010.
• Diagnostics is usually very hardware dependent. How can this be implemented as re-allocatable software components?
• A likely scenario is to have a hierarchy of S/W-C (i.e. composite components) and not a "flat" structure as one would believe by just reading the AUTOSAR specs.
• A prerequisite for ECU modelling are the defined system signals (what we would call the signal database at Volvo Cars). But one difference to what I think is most common now is that the "signals" as seen by the S/W does not need to agree name-wise with what is defined in the signal database.
• Structure begets function! For me as an architect this is completely natural, but there seemed to others in the audience who thought that was an unnatural way to do things (i.e. structure follows function instead). But suggested common process when starting afresh was to define the ECU structure of S/W components in daVinci and the import that into Simulink to fill it with behaviour (functionality).

I also had some tool specific observations:

• The tool and process demonstration was very focused on function development. Other aspects, such as variability, redundancy and memory management (non-volatile memory), was not discussed. My guess it has to do with the background of the companies and their products, e.g. none of these aspects can be addressed in Simulink.
• Structure is not defined in the simulation tool (i.e. Simulink) but is done before algorithms are defined.
• The vector tool DaVinci Developer takes the XML output from the AUTOSAR system configuration, it is not an system design tool but an ECU design tool.
• The AUTOSAR run-time environment (RTE) can only be approximated in Simulink and not simulated. So any simulation in Simulink is not telling much of how the software behaves on an actual ECU. But this is note very different from today, even if I know of people code-generating from Simulink believes otherwise.

I think all the presentations will be available on-line, if I understood the organisers correctly.

My suggestion is that anyone who has a background in programming embedded systems should (must) look at real examples of XML-files that are the result from the AUTOSAR process and the associated .c and.h-files for S/W-C and RTE. At least for me it made the difference of understanding what AUTOSAR is really about. And it makes even more sense if one remembers that AUTOSAR allows you to build your ECU with already compiled S/W-C, i.e. where the source code is not available. For controls-people only familiar with equations and Simulink I guess the threshold of understanding is quite steep.

I would also suggest anyone who wants a short pocket summary of AUTOSAR to order the booklet "AUTOSAR Glossary" from Vector (bilingual in English and German). I probably shot my credibility as an independent researcher by suggesting this...

AUTOSAR questions

I got a comment referring to a blog from a guy working with AUTOSAR implementation at GM.

He got some questions in his blog about AUTOSAR. I don't believe I have any definitive answers, but here are some quick thoughts...

..........is the architecture migration expensive ?
This was asked from a concern that the necessary tool support for developing AUTOSAR systems would incur expensive licenings costs compared to native development. I don't think the tool costs would be any higher compared to present tools (i.e. UML code generation tools or Simulink/dSpace). The big cost in migration to AUTOSAR would be the necessary change in OEM and TIER1 development processes. The cost of an experienced programmer is wastly greater than the cost of a S/W tool.

..........is AUTOSAR ISO compliant ?
Don't know.

..........does AUTOSAR emphasize on all key areas of the Embedded system ?
No, there are several proprietary concepts used by Volvo Cars when developing embedded systems that are not within the scope of AUTOSAR. I imagine it is the same for other OEMs as well.

.........how is the current AUTOSAR classified ?
This question I don't understand...

.........scope of AUTOSAR ?
At least the german OEMs and suppliers are very serious about AUTOSAR (e.g. BMW, Bosch and Vector). They have put hundreds of man-years into developing the standard and adapting their products.

.........is AUTOSAR going to provide a "AUTOSAR Compliant Hardware System" blueprint for automotive electronic hardware manufacturing companies ?
Not to my knowledge. I think this is left to the various suppliers to solve. "Cooperate on standards. Compete on implementation". I can imagine a scenarion where hardware manufacturers like freescale would deliver an "AUTOSAR-optimised" CPU with associated H/W-abstraction layer (part of AUTOSAR BSW).

AUTOSAR course

I have just come back from the first part of the AUTOSAR course at the Royal Institute of Technology. Including the invited teachers, where I was one, we were 20 people attending, with about 2/3 being from academia and 1/3 from industry.

I think the course went well, but it was obvious that AUTOSAR is a new way of thinking about how to build ECU software compared to what people are used to. I hope that I helped not only in presenting my own stuff but also could answer the questions from the other participants.

My presentation is seen below, for material from the others some can be seen on the course homepage.

AUTOSAR lecture

I have been asked by prof. Martin Törngren if I could be a guest lecturer in a course about AUTOSAR at the Royal Institute of Technology.
Sounds really interesting, since I hope to also participate in other parts of the course besides my own lectures. But it is also challenging since the first occasion is already on 9-10 February and I have no material prepared. I need to discuss this with my supervisor before I make a commitment.

Feedback on my presentation

The two topics at in my presentation at the software architecture workshop that generated most questions (and discussions in the coffee break afterwards) were

1. The vertical versus horizontal development structure. This did not surprise me since I already knew that is an area of interest (see for example the article Software engineering for Automotive Systems: A Roadmap by A. Pretschner et al. in proceedings of ICSE 2007)
2. The handling of S/W variability, especially in an AUTOSAR context. This came as a surprise, and I certainly need to look into both what research and practical implementation have been done in this area. There has been some work on variability and AUTOSAR in the EAST-ADL2, but I am more interested in the technical implementation in the code than how to model variability.
   

BMW already uses AUTOSAR

I found an interesting article by mistake when checking if this blog would come up in a google search (no, it didn't).
The article is two years old, but I found it worthwhile to read anyway.
Anyway, the article Managing for software success is availible on the web, but unfortunately not through the Automotive Engineering International magazine's web site.

But on the I found another interesting article in the same magazine claiming that the new BMW 7-series already have two ECUs where "ECU software was developed using AUTOSAR". The article is based on an interview with well-known researcher on automotive software Dr. Manfred Broy.

Too bad that neither of these articles have gone through scientific peer review. It makes it so much easier if I wanted to have references to them in my research. But for a blog that really doesn't matter...

ABB software Architecture Workshop

I visited the yearly ABB Software Architecture Workshop in Västerås on December 16. Very interesting with a good mix of people from industry and academia. I hope I'll get invited next year again.

One of the most interesting presentation, at least for me also working in automotive, was from Scania and how they worked with product line architectures. The approach they had to working with electrical architectures was quite different from Volvo Cars even though we are both working in the automotive sector. This only shows how important the business decisions and company culture are and the necessity to adapt the architecture in order for it to be successful in a company. Since Scania already had a product line approach for the mechanical parts of a truck it was very easy for them to have a similar approach in the electrical system

I held a short presentation about standardised software architecture in the automotive industry. It generated a lot of questions and discussions among the audience which I take as a good sign that my research will be of interest to others.
Here is my presentation available through Google documents: