EAST-ADL2 and AUTOSAR 2010-02-05

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.

Is an archtiecture description always necessary?

I wrote in an earlier post about the importance of being able to write in a concise manner, based on the assumption that key issue for an architecture description is to convey an common understanding of the architecture (more on the validity of that assumption later in the blog).

What would happen if that line of thought is taken to it's extreme, i.e. nothing is written down about the architecture? How would one reach a degree of understanding among the team members? And especially a common understanding? Does it even need to be common?

Answering these questions could easily expand to an entire literature review of organisational learning and I'll try to avoid that. But an architecture description is a way to convert the tacit or internal knowledge (of the architects?) to explicit knowledge which in turn other stakeholders can internalise again. The question is of this transfer of knowledge can be spread through the organisation by other means?
I certainly think so, the same way I learned about electrical system in vehicles "on the job" rather than learning from books, but this requires working side by side on a recurring (daily?) basis. Feasible if the team is co-located in the same room, but it does not really scale if the desks are to far apart. One architect and 15 other developers is not a problem. One architect and 200 other developers is a problem.
I have a gut feel that this is related to how well agile practices scale to big projects...

After reading this post I realised I made an assumption that the architect is the main person having the knowledge about the architecture. Of course this must not always be the case. One alternative is the committe architectures I wrote about earlier, but there of course must exist other alternatives...

Committe architectures 2010-01-27

I have observed that sometimes an architecture tends to get defined by a
committee of all stakeholders (or representatives for them) rather than an architecture team. This in itself may not be bad but there are some things that seems to happen when this is the case:
First the architecture tends to be defined by a set of separate decisions that solves separate problems the stakeholders have. There is no overall vision of what the architecture should be. A lack of what Frederick P. Brooks call conceptual integrity.
Second the balancing of quality attributes seem to be an average of everything. The architecture is not really good on anything (maintainability comes to mind). On the other hand no quality attribute seems to be totally forgotten or neglected.
Third the description of the architecture is done at low level, e.g. a design or implementation level because this is what a majority of stakeholders are used to in doing their usual work.

"The other" car manufacturer...

"The other" car manufacturer has a new owner after General Motors. Good for them! We need the local competition to stay alert. Read the news here.

Publications in the pipeline 2010-01-20

The blog originally had the intention to cover topics I'm intersted to research. So here is a short status update of what I am doing right now in my research project.

Together with a fellow researcher I made an extensive interview series with architects at two major automotive companies. So far the data from these interviews is used for 3 papers which will be submitted this spring:

1. A compararative case study on how two similar companies work with maintaining architctures.
2. A short paper describing how archtiects view themselves in terms of skills, experience, attitudes, etc.
3. Another paper which I'm not authoring

Last year I made extensive observations of architectural decisions for the architecture of the next generation electrical system at Volvo Cars. So far the data from these observed decisions will be used for 2 papers:

1. A new classification scheme for archtiecture decsions, based on empirical data
2. A case study of the 80 decisions observed at Volvo Cars

I also have an idea about an interesting AUTOSAR-paper which partly will use information from a student thesis project I will supervise later this spring.

Object-oriented programming in C 2010-01-08

In the automotive industry C is the totally dominating programming language. I guess this is because of the limited resources in automotive-specific CPUs but also because of tradition among programmers, if you have a program that is proven by use you don't rewrite that just because there is some new language around.
And to be honest, it still is hard to beat C if you want real-time properties and a garbage collection that don't risk overflowing memory.

But if you want to keep C but write programs in a more object-oriented style how do you do? It is not as hard as one would think.
Here are some web pages which give some useful tips. Note that they are not always compatible!

• Phil's guide to object-oriented ANSI C
• Object-oriented programming in C by Paul Field
• Object-oriented programming in ANSI- C by Axel-Tobias Schreiner

I have reviewed code for several ECUs used in Volvo cars, and none have used an object-oriented style. The reason I bring up object-oriented programming in C in this blog is that it simplifies the implementation of many patterns, the subject is not really new...