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

"The Concise Handbook of Real-Time Systems"

Very long ago (1999?) I attended a conference where I got a small booklet called "The Concise Handbook of Real-Time Systems" by TimeSys Corporation.
I found the booklet to be a very usefull distillation of the most important concepts when designing real-time software. I even ordered some more copies for interested collegues. I hope more developers will be familliar with the content, it would prevent a number of problems...

I don't think the booklet can be ordered any more from the original company, but a quick googling found a later version in PDF here.

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.

The significant benefit of software architecture?

I have been convinced that it is impossible to design a perfect architecture. This is supported by a quote by P Kruchten which I have already mentioned in my blog:

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

One corollary conclusion I make from this is:

The significant benefit of a software architecture is that it exists, not that it optimally fulfills the prerequisistes.

If the purpose of an architecture is to guide and control subsequent developement the fact that it actually provides some guidance is more important than the guidance have exactly the right bearing. I have a gut feeling that this is intimately related to if the system has any conceptual integrity or not.

Could I write some kind of position paper on this? What arguments could I use? Is such a paper already published?

Project presentation

I gave a presentation of my project at the annual Volvo Industrial PhD conference:

I did get the question how my project would have looked like if I would have had a quantitative approach instead. I wished I had the Dilbert strip about numbers as a backup-slide.
Now I had to resort to a serious answer that for some research a qualitative approach will get you a better understanding than a quantitative...

More Conferences...

Some readers responded to the previous blog post about conferences. I got information about two more conferences which could be interesting:

SEI Architecture Technology User Network (SATURN) Conference
17-21 May, 2010, Minneapolis, MN, USA
Submit a proposal by November 9, 2009.

17th IEEE International Conference and Workshops on Engineering of Computer-Based Systems
22-26 March, 2010, St. Anne’s College, University of Oxford, UK
Submission of titles and abstracts 1 November, 2009
Co-located with 15th IEEE International Conference on Engineering of Complex Computer Systems and 7th IEEE International Conference and Workshops on Engineering of Autonomic and Autonomous Systems

Architecture Smell

There is an "established" term called Code Smell, which is an indicatin/symptom that the code should be re-factored (or at least be considered for re-factoring).
I am curious if there are similar Architecture Smells that are symptoms that the architecture is deteriorating. Could these be indicators to see if the system should be re-engineered to the original architecture or even if the architecture should be updated or maybe replaced.

At the WICSA conference I heard Olaf Zimmerman state that one architecture smell for a large system would be if it did not have some kind of layered structure.

For a layered architecture I would say one smell is if there are an increasing number of design dependencies between components in each layer that does not follow the layered principle (i.e. there is a strict dependency from upper to lower layer).

As a comparison one can look at the following lists of Code Smells:
Wikipedia: Code Smell
A Taxonomy for "Bad Code Smells"
Coding Horror: Code Smells