ECSA 2010 pt2

I did not find this year's conference as inspiring as last year's in Cambridge. I don't know why. I think both the quality of the presentation and the gap on what was presented to industrial application varied more.
There are some papers which I plan to re-read, for example

• Lightweight and Continuous Architecture Software Quality Assurance using the aSQA Technique, on how to to architecture analysis in agile-type development.
• Experiences in Making Architectural Decisions during the Development of a New Base Station Platform
• Unifying Software Architecture with its Implementation, on the need to include architectural documentation in what actually gets maintained, i.e. the code
• Structuring Very Large Domain Models, if you think you have big models see what was studied here...
• Towards a Process Maturity Model for Evolutionary Architecting of Embedded System Product Lines, interesting but also similar to Knowit's Architecture Capability Evaluation.

The last three papers were all from the industry track (which also included the presentation by myself), which I thought was as interesting as the rest of the conference together. For some reason the industry track papers was not published by Springer in their LNCS series, but I was told they would be available at the ACM digital library.

ECSA 2010 pt1

I'm at the 4th European Conference on Software Architecture in Copenhagen. The presentations varies, both in presentation skills, scientific rigour and relevance (at least to me).

Jan Bosch stressed 3 key take-aways in his keynote last morning, he might post the presentation on his homepage:

1. An increase in speed trumps any increase in efficiency
2. Software engineering is moving from integration to composition
3. Software architecture is the key to delightful products in software eco-systems

I'm not convinced that all of his conclusions are valid outside of pure software business domains. But I guiess there are som things to learn even if one makes software for systems like cars, communication satellites etc.

Now I'm of to listen to Philippe Kruchten.

Geely owns Volvo Cars

Volvo Car Corporation is now fully owned by Geely. The deal was closed yesterday.
You can read the full story at Reuters or Gasgoo Auto News. New CEO will be Stefan Jacoby, formerly of VW North America.

Exploring variation mechanisms in the automotive industry: a case study

I supervised a thesis project on run-time variability in an AUTOSAR architecture.
You can read about the project, and download the thesis report, at the student's web site: quandoo.

Books on programming embedded systems

I'm looking for a good text an programming embedded systems (for example an automotive ECU) but I can't find any that suits the bill. I was hoping to suggest something to students that avoids the trial and error learning methodology I had to endure.

A quick search on Amazon shows some which could be relevant:

• Programming Embedded Systems: With C and GNU Development Tools by Michael Barr and Anthony Massa
• An Embedded Software Primer by David E. Simon
• Embedded C by Michael J Pont
• Embedded Software Development with C by Kai Qian, David Den Haring and Li Cao

Especially the latter sounds interesting since I like the software architecture book from the same author.

I was thinking of writing a book myself on the subject. But it would mostly haven been a collection of data one can find on the internet with some detective work. Subjects to include would be:

• Introduction to C, since embedded systems are programmed in C. Period....
  I like K&R, but you can choose any book that suits the bill.
• Good coding practices in C, for example MISRA C rules.
  Read some example of MISRA C-rules here, here and here.
• RTOS basics, since this is what is used on most embedded systems.
  Read chapter 1 in the User & reference manual of rt:kernel from rt:labs for a good introduction. But personally I prefer the "run-to-completion" type of tasks which don't wait for external events for predictability.
• Interrupts, stacks, and memory handling - ISR, RAM, NVRAM, ROM, Flash and every other acronym you can think of...
• Development environments, and compilers for embedded development
  My experience is that this is pretty much decided by the OS you are using. I have experienced very mysterious bugs just by not having the correct compiler version, so I can' imagine what could happen when having a compiler from a different vendor... IAR graciously provides all of their manuals free of charge and their IDE and compilers on 30-day on a 30-day free trial.
• Various hardware on a typical embedded controller - Details on how to access hardware with code examples.
  You can see examples of typical hardware devices in the Freescale MC9S12XS256 Reference Manual, a typical automotive processor, especially chapter 10-19. Mind you that this manual is 738 pages long, so it's pedagogical value is limited.
• Debugging - Too much to cover for this blog post. This is the real dark arts...
• Architecture of embedded systems
  Almost all embedded systems are layered, but why? And how do you know which layers to have in your system? And how do you identify the tasks you should have when schedule the system?

Competitiveness from structuring of AUTOSAR applications

AUTOSAR 4.0 was released some time ago, and in certain areas it was a major update compared to version 3.1 of the standard. Besides the changes to the Basic Software one of the things I think may have a great impact when it comes to sourcing software from suppliers are the results from the 10.x work packages that deals with application interfaces (i.e. interfaces of the software components above the RTE).

In my mind structuring the applications and standardising their interfaces pretty much defined what quality attributes ("-ilities") the software would have, especially when it comes to "Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system" to quote wikipedia. So with the OEM-supplier relationships that most vehicle manufacturers have and with the static structure standardised by AUTOSAR it would be almost impossible to compete with the "-ilities above. So how does one use AUTOSAR and "cooperate on standards, compete on implementation"?

I got the answer in a paper by Simon Fürst et al. presented at 14th International VDI Congress Electronic Systems for Vehicles 2009 in Baden-Baden.

"In general, applications are the competitive edge of an ECU. AUTOSAR is not going to standardize the functional internal behavior of an application (e.g. algorithms, optimization) but the content exchanged between applications. This clarifies the exchange of applications between the automotive community, from OEM to suppliers as well as supplier to supplier and so forth."

So competitiveness is "only" achieved by algorithm optimisation? A typical control engineer's viewpoint and not a software engineer's? This means that an OEM can only distinguish itself from the competitors by run-time qualities and not by qualities such as evolvability or testability?

Do I even need to say that this is my personal opinion based on the teaching I do in software architecture and does not necessarily reflect my colleagues' opinions or the company I work for.

Blogs

I follow two "professional" blogs:

• Heartbeat Development by a former colleague of mine, Johan Segertoft
• SEI Architecture Technology User Network Blog

The latter had in a recent post some links to other blogs which also deals with architecture.