Thursday, March 26, 2009

Another automotive software workshop

I stumbled across a call for paper to the 7. Workshop Automotive Software Engineering taking place in August 2009 in Hamburg. Unfortunately it seems to be conducted entirely in German. Too bad, since it would have been a good opportunity to see what the German manufacturers and suppliers think is most interesting in automotive software right now.

There are very few opportunities to see "what's cooking" in the industry, mostly it is academics presenting, but this workshop seems to have a program committee with a majority from industry. This is one of the few I've heard of besides the biannual Baden-Baden conference.

Wednesday, March 18, 2009

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...

Saturday, March 14, 2009

Two articles on Volvo electrical architecture

There are two articles that give an introduction to the electrical system of the first Volvo S80 (really the architecture to be precise). Even if that particular car is 10 years old the architecture in present Volvo vehicles are still of the same family, but two generations later.
  • Volvo S80: Electrical system of the future by Kent Melin. This is an overview of some of the more important architectural decisions for the Volvo architecture.
  • Volcano - a revolution in on-board communications by Lennart Casparsson et al. This describes the mathematics for Volvo's signal scheduling on CAN to ensure that all signals are received within their designated deadlines, and a brief description on the processes and tools to administrate the signal database.
Unfortunately neither article is available on-line where it was originally published, the Volvo Technology Report.

Wednesday, March 11, 2009

Microsoft automotive platform

Since I have written som blog posts about open source software for in-vehicle infotainment I think I should mention Microsoft's platform as well, used for exmple in Ford's Sync. Here are some information I found:

Software architecture resources on the web

I found some resources on the web which I think are useful for people concerned with automotive software architecture, either as some kind of tutorial or as reference material. Some are more generally about software architecture while others are targeted to automotive software.

Tuesday, March 10, 2009

GENIVI and moblin?

I still have not found any solid technical description about the GENIVI platform, but some internet detective work directed me towards the homepage which has a community directed to LINUX use for in-vehicle-infotainment.
Seeing that both initiatives are open source based on Linux, that there are common members between GENIVI and moblin (i.e. Intel and Wind River) and the goals of the projects are very similar I assume the technical solution will also be similar. The moblin architecture is described here...

Monday, March 9, 2009

Industrial research in student projects

I was asked to talk about my research in the course Research Methods and Technical Writing, at the IT University, together with a number of other researchers here at ITU.

My first thought was talking about case study research in the industry, but another speaker would talk about case studies so I dropped that idea. In the end I decided just to talk about doing students project in industry in general. I have supervised 5 thesis projects so I think I have som knowledge on the subject by now...

I have just finished the lecture and I'm not very satisfied with the outcome. I got very few questions and found it very hard to find any enthusiasm among the students. The original plan was that I would give the lecture a month ago, but various problems with finding a slot in my calendar postponed the lecture several times, so when I finally held the lecture most of the students had already selected topics for their projects.

I made a test of using LaTeX for making slides. Unfortunately I haven't figured out how to share the resulting PDF in this blog. Suggestions are welcome...

Thursday, March 5, 2009

GENIVI

Genivi is a brand new alliance to promote open source software for in-vehicle infotainment (official start March 2009). The founders include BMW, Wind River and Intel among others.
I have not heard about about the initiative before, but a quick google search revealed some introductory articles:
Unfortunately there is not yet any technical information on the GENIVI homepage, but I will certainly follow up on this...

Narcissism

This blog post will contain some heavy narcissism on my part...

I wrote an article named Experience of introducing reference architectures in the development of automotive electronic systems together with some colleagues. I also gave an appreciated talk at the second international workshop on Software engineering for automotive systems, which was one of the workshops at the 27th International Conference on Software Engineering in St. Louis, MO, USA (ICSE 2005).

ICSE is one of the most prestigious conferences on software engineering (the most prestigious according to some rankings) so the paper should have some academic merit. But it is almost impossible to find my paper in any academic database. The paper is not included in INSPEC, which is the biggest general database about engineering and science, event though INSPEC has articles from ICSE 2005. It is not found in IEEE Explore. The only databases I could find it is in ACM portal, besides Google Scholar.
So it is unlikely my paper will be referenced since nobody knows it exists...

You can find a full-text version of my paper here, courtesy the Mälardalen Research and Technology Centre at Mälardalen University.

Note: INSPEC is not free to use, the other databases should allow you to search, but not download material unless you have a subscription. But Google scholar is usually very good at finding a PDF somewhere on the net if you have the title and author of an article.

Monday, March 2, 2009

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).