Survey of active vehicle dynamics systems

Prodrive is a company known for supplying advanced technology to a number of "special" vehicles such as the Ford Focus RS and the Subaru Impreza P1.
But the reason I mention them on this blog is that they have written a nice SAE paper surveying different electronic vehicle dynamics systems available when designing a vehicle, and therefore the electrical architecture in a premium vehicle may need to address.
It is possible to download a free copy of the paper at the Prodrive website.

References in paper about the Architecture Business Cycle

I submitted a paper called "A Case Study of the Architecture Business Cycle for an In-Vehicle Software Architecture". I cannot publish the paper in this blog (at least not until it has been accepted), but I can give the reference list. Many of the papers can be found on-line through Google Scholar if access is not available through the commercial portals.

AUTOSAR, 2009. AUTomotive Open System ARchitecture (AUTOSAR). Available at: http://www.autosar.org.

Bachmann, F. & Bass, L., 2001. Managing variability in software architectures. SIGSOFT Software Engineering Notes, 26(3), 126-132.

Bass, L., Clements, P. & Kazman, R., 2003. Software Architecture in Practice 2nd ed., Addison-Wesley.

Berg, B.L., 2006. Qualitative Research Methods for the Social Sciences 6th ed., Allyn & Bacon.

Broy, M., 2006. Challenges in automotive software engineering. In Proceedings of the 28th international conference on Software engineering. Shanghai, China: ACM, pp. 33-42. Available at: http://portal.acm.org/citation.cfm?id=1134285.1134292 [Accessed December 18, 2008].

Conway, M.E., 1968. How Do Committees Invent? Datamation. Available at: http://www.melconway.com/research/committees.html.

IEEE, 2000. Recommended Practice for Architectural Description of Software-Intensive Systems. Available at: http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html.

ISO - International Organization for Standardization, 2003. ISO standard 11898: Controller Area Network (CAN). Available at: http://www.iso.org/ [Accessed December 28, 2008].

Kazman, R. & Bass, L., 2005. Categorizing Business Goals for Software Architectures, Carnegie Mellon Software Engineering Institute. Available at: http://www.sei.cmu.edu/pub/documents/05.reports/pdf/05tr021.pdf.

Kazman, R. et al., 2005. The Architecture Business Cycle Revisited: A Business Goals Taxonomy to Support Architecture Design and Analysis. news@SEI. Available at: http://www.sei.cmu.edu/news-at-sei/columns/the_architect/2005/2/architect-2005-2.htm [Accessed December 18, 2008].

LIN Consortium, 2008. Local Interconnect Network (LIN). Available at: http://www.lin-subbus.org/ [Accessed December 28, 2008].

McDermid, J.A., 2000. Complexity: Concept, Causes and Control. In Proceedings. Sixth IEEE International Conference on Engineering of Complex Computer Systems, ICECCS. p. 2–9. Available at: ftp://ftp.cs.york.ac.uk/pub/hise/Complexity-Concept,Causes & Control.pdf.

Melin, K., 1998. Volvo S80: Electrical system of the future. Volvo Technology Report, 1, 3-7.

MOST Cooperation, 2008. Media Oriented Systems Transport (MOST). Available at: http://www.mostcooperation.com/ [Accessed December 28, 2008].

Noergaard, T., 2005. Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers, Newnes.

Pretschner, A. et al., 2007. Software Engineering for Automotive Systems: A Roadmap. In 2007 Future of Software Engineering. IEEE Computer Society, pp. 55-71. Available at: http://portal.acm.org/citation.cfm?id=1253532.1254710 [Accessed December 28, 2008].

Reichart, G. & Haneberg, M., 2004. Key Drivers for a Future System Architecture in Vehicles. In Proc. Convergence 2004. Detroit, MI, USA: SAE. Available at: http://www.sae.org/technical/papers/2004-21-0025 [Accessed March 9, 2009].

Smallbone Tizard, D., Wallmark, J. & Warrby, T., 2007. Architecture and Change: A Case Study Using the Architecture Business Cycle for Assessing an Organisation Facing a Major Architectural Change, Göteborg, Sweden: IT University of Göteborg.

Walsham, G., 1995. Interpretive case studies in IS research: nature and method. European Journal of Information Systems , 4, 74-81.

Yin, R.K., 2003. Case Study Research: Design and Methods 3rd ed., Sage Publications.

Unconscious Competence

I have in the last year or so found it difficult to immediately explain why I perceive a certain system design is flawed (at least from an architectural viewpoint), while my gut feeling strongly tells me it is. It seems I'm most sensible to conceptual integrity, or rather lack thereof.
Usually I can do a some logical reasoning to support my initial conclusion, but it seems backwards that I reach the conclusion first and find the arguments to support it afterwards.
I stumbled upon the concept of code smell, and from there upon unconscious competence, which pretty much sums my experience. I had never heard of unconscious competence before, but I'm relieved that others have recognised it as a "level of competence".

Now it could just be that I am totally delusional about architecture, and is actually unconsciously incompetent instead. It seems nobody outside programmers recognise that you could be unconsciously competent in such a highly cognitive area...

Note: I wasn't finding the definitions in wikipedia, but here, but I thought the wikipedia definitions were more understandable. A google search found these pages on the subject as well (I filtered all pages by personnel development companies and about athletic coaching):

• Conscious competence learning model from businessballs.com
• Small Biz Thoughts by Karl Palachuk: Unconscious Competence 4: Unconscious Competence
• 10,000 HOURS

The Non-Coding Architect

I read a blog post about "anti-teams", not that I found the blog highly related to my work or research, but this particular post gave some food for thought. In particular I started to wonder if I fall into the category of the "Non-coding Architect".

It is true that I don't write any code for the projects I'm involved in presently at Volvo. This mainly due to two reasons:
First; the provisional architecture is usually settled very early in the project, often before the majority of developers have started working (why this is so is almost the subject of an entire thesis and will not be covered in this blog post. For now just accept that it is not a decision of the architect).
Second; most of the code is written not by the OEM (the manufacturer for you who are not familiar automotive terminology) but by suppliers. This is also a decision made way above the head of me as architect. It is part of a general business strategy on high management level, which I don't really feel I'm involved in.

To my defence I am one of the few developers at the EESE department at Volvo Cars that actually has hand-written code in C (and just a few lines of assembler) that is included in cars delivered to customers (and not just pushed the auto-coding button in Simulink). But as I said in the beginning, it is very seldom I do any actual coding in the platforms I'm architecting. It is very seldom I do any coding at all these days. I need to ponder this more...

Another automotive software workshop

I stumbled across a call for paper to the 7. Workshop Automotive Software Engineering taking place in August 2009 in Hamburg. Unfortunately it seems to be conducted entirely in German. Too bad, since it would have been a good opportunity to see what the German manufacturers and suppliers think is most interesting in automotive software right now.

There are very few opportunities to see "what's cooking" in the industry, mostly it is academics presenting, but this workshop seems to have a program committee with a majority from industry. This is one of the few I've heard of besides the biannual Baden-Baden conference.

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

Two articles on Volvo electrical architecture

There are two articles that give an introduction to the electrical system of the first Volvo S80 (really the architecture to be precise). Even if that particular car is 10 years old the architecture in present Volvo vehicles are still of the same family, but two generations later.

• Volvo S80: Electrical system of the future by Kent Melin. This is an overview of some of the more important architectural decisions for the Volvo architecture.
• Volcano - a revolution in on-board communications by Lennart Casparsson et al. This describes the mathematics for Volvo's signal scheduling on CAN to ensure that all signals are received within their designated deadlines, and a brief description on the processes and tools to administrate the signal database.

Unfortunately neither article is available on-line where it was originally published, the Volvo Technology Report.