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