Thesis chapter 12.1.3: Research answer 1.2

Chapter 9 answers RQ1.2 by identifying the following quality attributes as necessary for a platform allowing for composition of independently developed software, the platform being a precursor for an open software ecosystem:

• Composability: The software platform must fulfil a set of properties to allow the decoupling of applications and eliminate the need for development synchronisation. The architecture should allow development, integration and validation of applications independent of other applications.
• Deployability: The applications must be possible to deploy independently of each other, and the product behaviour must not depend on the order in which applications are installed. There must also be a deployment infrastructure in place which fulfils necessary integrity requirements.
• Maintainability: The platform must be sufficiently stable over time. Since the platform and application evolution is decoupled, i.e. no synchronised versioning, backwards compatibility is a key attribute.
• Configurability: The platform must support variability in the hardware configuration of sensors and actuators since individual products can vary within the product family.

In addition to these there are two more quality attributes that affect the business value for embedded products in various domains, but are not universal:

• Consistent User Interface: This is often considered important by manufacturers of embedded consumer products since much of brand recognition and willingness to stay with the product brand lies here. The other major aspect for brand distinction is the qualities provided by the hardware (precision, reliability, etc.).
• Dependability: Many embedded domains have stringent dependability requirements. These domains are probably not the first adopters of an ecosystem-based approach to software development. However, if that was the case the embedded platform would satisfy; real-time requirements for the execution of individual applications, integrity requirements, high availability, and mechanisms to eliminate undesired feature interaction if several applications interact with the same actuators.

A reference architecture was designed to enable the qualities above, consisting of 20 architectural decisions together with 4 architecture patterns for:

• Device abstraction
• Data and service provision
• Device and information composition
• Safety-critical, certified and open application access

The conclusion is that it is conceivable to develop a platform suitable for compositional development, as a precursor for an open software ecosystem. The system in case VI implements most of the design decisions from chapter 9, but not all, leaving out mostly those related to safety-critical functionality.
The contribution is the novel reference architecture for composition of independently developed embedded software applications, suitable for using in an open software ecosystem. Open software ecosystems are not new, but no reference for implementation in the embedded domain is published in literature.

Thesis chapter 9: Compositional architecture for embedded platforms

This chapter explores composition architectures for embedded software as precursor for open software ecosystems, i.e. architectures suitable for approach B: Architecture for Composition from chapter 7.
This chapter was submitted as an article to Journal of Systems and Software in 2012.

Abstract

Open software ecosystem are proposed as a sustainable approach to develop software for embedded systems, and the paper elaborates on the necessary properties of an embedded platform and design an architecture to facilitate a successful establishment and growth of ecosystems for embedded software.
The paper defines a set of qualities for an embedded ecosystem platform that are necessary in addition to domain-specific qualities. Based on these 20 key architecture decisions are defined, together with the rationale why they are critical for an open ecosystem platform for embedded systems in general and automotive systems in particular. The decisions constitute together with four architectural patterns a reference for embedded open software ecosystems.
An industrial case of the prototypically implemented architecture, satisfying some of the identified quality attributes, is presented to provide a deeper understanding of how the architecture could be realised in the automotive domain.
Four potential existing platforms, all targeted at the embedded domain (Android, OKL4, AUTOSAR and Robocop), are evaluated against the identified quality attributes to see how they could serve as a basis for an open ecosystem platform with the conclusion that while none of them is a perfect fit they all have fundamental mechanisms necessary for an ecosystem approach.

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.

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.

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

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

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:

• http://www.genivi.org
• http://www.linux-magazine.com/online/news/bmw_in_drive_conversation_with_open_source
• http://www.linuxpromagazine.com/online/news/cebit_2009_bmw_and_partners_found_genivi_open_source_platform
• http://blogs.zdnet.com/open-source/?p=3663

Unfortunately there is not yet any technical information on the GENIVI homepage, but I will certainly follow up on this...