More news and press releases

Here are some interesting news and press releases:

• Download, install and drive – the future of automotive software from ICT Results
• Mentor Graphics Strengthens Its Automotive Solutions with New Integrated AUTOSAR Design Environment
• AUTOSAR marks its series production debut - in the new BMW 7 Series
• Hansen lists top ten automotive electronic trends from John Day's Auto Electronics Blog

I finish with a quote to keep in mind when designing architectures:

"Warum soll man es einfach machen, wenn man es so schön komplizieren kann?"

which roughly translates to

"Why should we make it simple when it can be made so beautifully complicated?"

I don't know where it originally comes from though...

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