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.

ICSE 2011

The International Conference of Software Enginering is on Hawaii in 2011. Deadline for the main research track is Friday 20 August 2010. Time to hurry if I want to submit something...

Swedsoft meeting

Last week I attended a meeting between DICE and ABB with additional participants from Volvo Cars and Ericsson as well as some from academia. The meeting was arranged by Swedsoft.

I know nothing of the game industry so it was especially interesting to listen to the presenters from DICE, who all worked with the development of their game engine Frostbite. Some things were of particular interest:

• There is a fairly strong architecture for the Frostbite engine. Both for the runtime architecture (client-server) and even more important for the development architecture where the runtime architecture is just a "small" part besides e.g. the FrostEd editor for game objects and the build database(s).
  
• They use extensive knowledge about the game (domain knowledge) to minimise necessary information sent to/from the server and the clients (the latter being the software you buy at a gaming store and run on your Xbox360/PS3/PC).
• The run-time architecture uses parallel processing in multiple cores and distributes "jobs" between the cores dynamically.
  
• They use continuous builds, i.e. as soon as a programmer checks in new code it is built into a working program. This for the game developers always to have something to run.
• They only do positive testing, e.g. the program shall have this feature. No test on the program shall not...
• The Frostbite team consists of 19 developers and they update and maintain 1.5 MLOC for all 3 platforms (Xbox 360, PS3 and Windows). It is like we would maintain the entire in-vehicle software with 20 people.

I hope I didn't misunderstood anything...

Lindholmen Software Development Day 2010

Lindholmen Software Development Day is a yearly free get-together for local "software developers, managers, project managers and business developers" here at the north river shore in Göteborg. The theme for this year is

• Perspectives on and analyses of the changing market situation
• Software development philosophies supporting the changed situation
• Discipline Integration challenges and solutions, e.g., in H/W-S/W codesign
• Processes, Methods or tools to improve speed, efficiency, or quality
• Experience reports from new ways of working

I was asked by some people at Volvo Cars to present something relevant to us, and after some thought the topic of my talk would be "The future of automotive software engineering". Not pretentious at all...
Here is the outline I proposed. Any acceptance notification will come in August.

• General briefing on current and future trends in automotive software engineering
• Exponential increase in size, complexity, innovations, …
• Cycle times are dictated by what?
• Industry-wide ways to cope
• Standardisation
• Model-based development
• Architecture
• Soft issues
• Knowledge and maturity in the industry
• How to earn money?
• Some examples (from Sweden)

Concurrent architecture

To continue my thoughts about the programming language Erlang and especially how an architecture for a system implemented in Erlang would look like...

Joe Armstrong's PhD Thesis provides a very good understanding of the basic principles of Erlang. I think that some of the mechanism in the language makes several pattens in Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects unnecessary.

I think it would be quite useful to describe the architecture in views. I think the "standard" 4+1 views could be used quite easy for a system implemented in Erlang as well.
However it may not be the logical view that the other views are derived from, rather I would think that the process view would be the basic view. Kruchten has an underlying assumption that the logical view is object-oriented. This is obviously not relevant for a system implemented in Erlang so a different notion of the logical view is necessary.

Joe Armstrong strongly suggest a hierarchy of processes. A problem domain model could be a good way to identify the top-level processes, e.g. the PDM classes could be the initial processes and the asynchronous interaction will be implemented as messages, since reality is asynchronous. I need to try this in practice though...

Architecture reconstruction pt. 3

These are some random notes the students took while doing the intial reconstruction (I translated some notes in Swedish to English).
I don't know if they will finish, since the semester has ended.

Why does the camera know about the state of the Robot?
The camera, having a relative angle could not properly determine the angle of an identified object when the vehicle is, for example turning.

The event handler gets information from the wheels and sends to the camera. Now there is both idle and turn. But the camera runs the same function regardless of the message it gets, why does then turn exist?

Conclusions:
Different ways to send states thorughut the system, some are event driven and some are conditional.
Naming standard and file structure are not the same throughout the system.
The protocol files were located in different places.
The fact that the different modules use different architectures is OK since the circumstances for them are very different.
The name OS of one of the applications on the Arduino Mega is not very suitable since it is situated at the top of the hierarchy.

"Trust is good, control is better" - a quote from a former architect colleague of mine which the students liked enough to write down

Erlang

I don't do enough programming!

It has been years since I actually was allowed (asked?) to write any production code that goes into any of Volvo vehicle, since we buy a majority of our in-vehicle software from suppliers. Besides that, most of the in-house code we do nowadays are auto-generated from Simulink and Stateflow models.
Mostly I have reviewed what others have put in our vehicles, which is not nearly as rewarding. And this usually only happens when there is a problem, usually not a bug fix but rather more complicated, like real-time scheduling or improper use or configuration of the basic (or platform) software.

Since I will take a more active part in the a project course at the IT University which uses Erlang I think I will look into that. Erlang has some features which appeals to me personally:

• Support for asynchronous parallel processing, ideal for multi-core processors
• Functional paradigm, in contrast to the dominating OO paradigm, so I need to brush up old knowledge of things I haven't used since graduating in 1993.
• Freeware from the erlang website
• Access to some experts on the language

Confession: I'm not really that skilled OO programmer either, I could probably not write a Java program if my life depended on it. I'm too old school, almost all professional programming I've done have been in C and Fortran, with some Assembler and IDL.

Architecture reconstruction pt. 2

The students wanted to have some tool support in identifying the relationships between various functions (i..e. who called who). This was simpler in theory than in practice.

A not-so-quick search on the internet listed some potential candidates:
Code Visualizer
Crystal FLOW for C
Code Visual to Flowchart
http://www.EtherPad.com
http://www.metamill.com/
http://rigi.uvic.ca/
http://www.informatik.uni-stuttgart.de/ifi/ps/bauhaus/index-english.html

However none of these were very easy to use, or could not handle C as a programming language.
They also tried Rhapsody since they had a student license form another course and Enterprise Architect since it was possible to download a time-limited demo and these programs had no problems importing the code and identifying modules and functions, but they did not identity the calling relationships.

The students did not want to spend to many hours fiddling with tools so in the end they settled for manually inspecting the C code and identify what files included what other files. Since it was a distributed embedded system with 4 microprocessors and about 30 kLOC it was a doable task. Let's say that the 7 development teams had
quite different "strategies" for decomposing their code.

My personal observation is that even such a "simple" thing as decomposing you C program into files actually needs structuring principles if several development teams (or developers) work in a project, otherwise maintenance will be very difficult.

I still haven't decided if I should publish the more "awkward" ways to do it as examples to learn form, I don't want to point fingers at any particular students.