Volvo Cars will become Chinese...

It is now official that Ford will sell Volvo Car Corporation to the Chinese auto manufacturer Geely. To be more precise this is what Stephen Odell (Volvo CEO) wrote:

"Later today, Ford will confirm that all substantive commercial terms relating to the sale of Volvo Cars have been settled between Ford and Geely.
...while some work still remains to be completed before signing – including final documentation, financing and government approvals – Ford and Geely anticipate that a definitive sale agreement will be signed in the first quarter of 2010, with closing of the sale likely to occur in the second quarter, subject to appropriate regulatory approvals."

The information was sent out to us employees by e-mail in the afternoon before Christmas Eve, the biggest holiday in Sweden, so most people had already gone on vacation and probably first saw the announcement in the newspapers. Personally I think the timing should have been better for informing all the people working at Volvo Cars.

I have not found a lot of information in English speaking newspapers, but here is a short notice in Detroit News.

On a personal level I don't think this will affect my research project or my PhD studies at all.

Documenting and Presenting Architectures

Some interesting blog posts (and other links) about documenting and presenting architectures:

Architecture Documentation: Courage to Fly in the Face of Convention
Top Ten Tips for Presenting Architecture Information
All about IEEE 1471

A notice that puts my blog on a Swedish geographical blog map: Jag har placerat min blogg på Lindholmen på bloggkartan.se!

Organisational changes

There will be some changes to my research group. I don't know how this will affect me in detail, but in general I think it will strengthen software research in Göteborg.

In short there wil be a new software research center (at Lindholmen?) which will be a merger with software resarchers from the departments of Applied IT and of Computer Science and Engineering. Software engineering will organisationally belong to the latter department, so I will change department.
The two masters' programs Software Engineering & Management and Software Engineering & Technology will be one, which makes sense since they have a lot in common (e.g. course in software achitecture). It does not seem efficient to give two different master level programs in the same area.

On-line lectures on software architecture

It is surprising what you can find with some searching, for example full-length lectures about software architecture:

• Usability and Software Architecture: The Forgotten Problems
• O'Reilly Webcast: 10 Things Every Software Architect Should Know
• Agile Architecture Is Not Fragile Architecture
• Handling architecture in the agile world
  
• How to Effectively Evaluate Software Architecture and Identify Risks
• The Method Framework for Engineering System Architectures
• Service-Oriented Architecture (SOA) (an introduction)
• Transforming Software Architecture with Web as Platform
• Reliability Estimation During Architectural Design
• A Secret to Understanding Complexity_ A Temporal Approach to Engineering Software
• On Snowflakes and Architecture
• Winning the DARPA Grand Challenge [Robotics]
• Big ball of Mud

Note that I have not watched all of them (they are about 1 hour each) so I cannot vouch for any content and that the recording quality can be quite low.

Concise writing

I was involved in the software archtiecture course this year, more than the last few years, not surprising since I developed the coruse in 2006. One of the things I did was to evaluate the hand-ins of several assignments, which was disappointing in more ways than one. But the thing I want to bring up in the blog is the lack of concise writing.
I think that one of the most important abilities for an architect (even more so than for other developer roles) is to present the "fundamental ideas" in clear, concise and short manner.

In the hand-ins, a lot of answers covered two pages when a paragraph with less than ten lines would have been sufficient. With a good picture maybe even less.
I don't know if this is beacuse the students were not comfortable with terminology (if you use a model-view-controller pattern, how much more do you need to say about it?). Or if they think verbosity is the same thing as showing understanding? Or if they did not have the time to strip away the "fluff"...
Next year I will propose a maximum number of pages in the hand-ins and deduct points if they write more than that. Obviously they still need to fulfill the task...

It is an art and craft, to write as short as possible, but it helps getting the message across! An architect should hone this skill.

Matt Deacon's talking architects

I stumbled upon a channel with an interview series with various software architects. I must confess I haven't seen any of the interviews yet, but nevertheless I thought somebody else also might be interested:

Talking Architects
Matt Deacon, an Architect in Microsoft UK, talks to other architects about their experiences, their issues and challenges they face in the ever changing industry of IT.

Who is the customer?

Very often I hear one should have a customer perspective when developing software. Some agile methods propose working close with the customer.

But who is the customer? Is it the person paying for the development?

The end-customer is usually not difficult to identify for consumer products, which is what I work with since I'm in the car business. But even for such a closely related product as heavy trucks it is not obvious who is the customer. Is it the user of the truck (e.g. the driver) or the company buying the truck?

And looking inside the developing organisation it gets even more unclear. I work with developing architectures. Who is the customer of an architecture? Is it the end-customer? I think he could not care less if the car has an architecture or not, as long as it has the features and properties he wants.

Sven Grahn, former scientific director of the Swedish Space Corporation stated the best "test" of identifying the customer I have heard so far (freely translated from Swedish and maybe so distorted by memory Sven does not recognise it):

The customer is the person, or group, that when you remove them the activity (or product) becomes meaningless.

So for an in-vehicle architecture the primary customer of the architecture are the developers. If there would be no developers who who look at the architecture? (The end customer is also a customer, if he's not there what is the point of developing the car in the first place?)

Can I use this test to identify who is the customer of research? In most cases it is not the ones who sponsor it (e.g. government, foundations. etc).

Confidence in an architecture

How do you get confidence in an architecture? Lot's of extensive verification?
(This raises the quesiton on how to verify an archtiecture when you have not yet built a system based on the archtiecture. More on this at a later time...)

I think that you get confidence in an architecture by throwing things at it when various stakeholders gets involved and see how well it can handle them (all prerequisistes are never known in the beginning).
If the architecture can absorb a particular issue, scenario or feature, without deviations from the fundamental cornerstones or adding extra elements each time, the architecture gets stronger for each thing you throw at it. And your confidence in the architecture increases.
On the other hand, if you need to modify the architecture for each thing you throw at it and after enough times it is not recognisable when compared to the initial draft the architecture gets weaker and after some time there is little confidence left. And you should re-evaluate if it is the right architecture.

An architect must be able to have this "outsider" perspective and kill his/her darlings when necessary.

Google wave

I read about Google Wave in Ny Teknik (Sweden's biggest technology newspaper) and this was the first hands on description I had about how it could work, even though I had read about it before.

My immediate idea was that this could be used in science. Researchers could include data and/or hypotheses in a wave and other researchers could contribute to this wave with further data, analysis or conclusions. It could be very useful for collaboration between reserchers which are not co-located.

Remember where you read it first, in this blog!

Now I'm just waiting for an invitation from Google...

The difference between Academia and Business

From xkcd.com

What is a project...

I'm taking a course in project management and leadership for PhD students. Quite interesting...

One of my immediate observations is the discrepancy between the academic definition of a project and what we call a project in the car industry. According to our Swedish textbook a project is an activity with

• a well defined goal
• during a well defined time period
• with pre-defined resources
• under particular work model

A vehicle project, for example a model year update, certainly fulfills the first three, but the work model is/should be the same as the one we use for a model year update of another vehicle (not including any kaizen).
There is not something unique working with a particular vehicle model that warrants creating a project, it is just another task. A huge task, but nevertheless...
A research project is a different thing, for example developing the architecture for a new generation of electrical systems. There most work and deliverables are new and have not been done before or at least not in the last 10 years...

The other thing that I noticed as major difference is that the textbook states it is (or should be) impossible to participate in more than one, or at most two, projects simultaneously. An engineer at an EESE department usually works in more projects than that...

This post is in a response to an email I got about my previous post on more personal observations...

Comments

I got an e-mail that it is imposible to comment this blog. I tried myself and I agree. Annoying since I have blogged for more than a year now.

I have tried to fix this in the blog settings, but I find it strange that the default settings from Blogger made it impossible to leave a comment...

Focus of the blog?

I have a former colleague who started blogging after he became a technology management consultant (the blog is called Heartbeat Development). He has a lot more personal observations than I have in my blog, which I think is very interesting to read.

The question is if I should also have a more personal touch in my blog? I'm not sure, since I wanted to focus my blog on issues that relates to my research and factors that influence working with software architecture in the automotive industry. I will ponder this some more...

"Inspiration Day" on Vehicle Information and Communication Technology

I attended an "inspiration day" on Vehicle Information and Communication Technology (VICT) last week, arranged by Lindholmen Science Park and VINNOVA.
The purpose of the day was to display current Swedish research in the area and hopefully give ideas to new research projects. It was attended by a mix of people from industry, academia and government.

All presentations are available online here. Some in English and most in Swedish, not much I can do about that...

AUTOSAR webinar

Vector hosts a webinar on the basics of ECU development with AUTOSAR on 24 November 10:00 EST. You can register for the webinar here.

Sorry for the shameless plug for a commercial company, but at least this seems to be free. And there are few opportunities to learn more about AUTOSAR that is not hosted by a tool vendor or supplier...

"The Concise Handbook of Real-Time Systems"

Very long ago (1999?) I attended a conference where I got a small booklet called "The Concise Handbook of Real-Time Systems" by TimeSys Corporation.
I found the booklet to be a very usefull distillation of the most important concepts when designing real-time software. I even ordered some more copies for interested collegues. I hope more developers will be familliar with the content, it would prevent a number of problems...

I don't think the booklet can be ordered any more from the original company, but a quick googling found a later version in PDF here.

Lack of process view of automotive software

When discussing an architectural problem with my colleagues we identified that an initialisation/activation mechanism could be defined either as a method used between logical components or as an initialisation between run-time processes. But we could not propose the second mechanism since it would be impossible to communicate to the developers.

The reason for this is that we are not using a process view at Volvo (or at any other OEM that I have worked with either). With process view I mean the view as defined in the 4+1 paper by P. Kruchten. And I have not seen any other viewpoint used here that would fulfil a similar purpose.
This has some interesting implications:

• The deployment of functionality is in Kruchten's paper done by assigning logical components to processes and the deploying the processes onto the physical view. Among OEMs the deployment relationship is directly between static logical components and the hardware (i.e. ECUs). So there is no possibility to express concepts as "concurrency", "precedes" or "is activated by".
• It must be the responsibility of the ECU suppliers to define the process view of their ECU. And to be honest I have no idea if they do since this is not requested nor followed up by OEMs...
• The fundamental building block in AUTOSAR is the software component (SW-C), which can be called a static logical component if one is not too much of perfectionist with meta-models. The SW-C contains runnable entities which is the entity that is scheduled. But also in AUTOSAR it is the SW-C and not the runnable entities that are deployed to ECUs. I think this is driven by the first item above...
• Since it is the static SW-C that has the explicit relationship to other ECUs through the defined port and interface mechanisms in AUTOSAR there is no possibility to define a "dynamic" mechanism to "activate", "run simultaneously" or something similar usually defined in a process view (or process architecture).

I was thinking of writing a short paper elaborating on this and relating it to some research papers, but I probably will not. First it is not directly in line with the subject of my thesis. Second there are more pressing things to do. So if anybody else wants to pursue this I would be glad to be a co-author, discussion partner ot at least get mentioned in the acknowledgements.

The significant benefit of software architecture?

I have been convinced that it is impossible to design a perfect architecture. This is supported by a quote by P Kruchten which I have already mentioned in my blog:

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

One corollary conclusion I make from this is:

The significant benefit of a software architecture is that it exists, not that it optimally fulfills the prerequisistes.

If the purpose of an architecture is to guide and control subsequent developement the fact that it actually provides some guidance is more important than the guidance have exactly the right bearing. I have a gut feeling that this is intimately related to if the system has any conceptual integrity or not.

Could I write some kind of position paper on this? What arguments could I use? Is such a paper already published?

Project presentation

I gave a presentation of my project at the annual Volvo Industrial PhD conference:

I did get the question how my project would have looked like if I would have had a quantitative approach instead. I wished I had the Dilbert strip about numbers as a backup-slide.
Now I had to resort to a serious answer that for some research a qualitative approach will get you a better understanding than a quantitative...

More Conferences...

Some readers responded to the previous blog post about conferences. I got information about two more conferences which could be interesting:

SEI Architecture Technology User Network (SATURN) Conference
17-21 May, 2010, Minneapolis, MN, USA
Submit a proposal by November 9, 2009.

17th IEEE International Conference and Workshops on Engineering of Computer-Based Systems
22-26 March, 2010, St. Anne’s College, University of Oxford, UK
Submission of titles and abstracts 1 November, 2009
Co-located with 15th IEEE International Conference on Engineering of Complex Computer Systems and 7th IEEE International Conference and Workshops on Engineering of Autonomic and Autonomous Systems

Architecture Smell

There is an "established" term called Code Smell, which is an indicatin/symptom that the code should be re-factored (or at least be considered for re-factoring).
I am curious if there are similar Architecture Smells that are symptoms that the architecture is deteriorating. Could these be indicators to see if the system should be re-engineered to the original architecture or even if the architecture should be updated or maybe replaced.

At the WICSA conference I heard Olaf Zimmerman state that one architecture smell for a large system would be if it did not have some kind of layered structure.

For a layered architecture I would say one smell is if there are an increasing number of design dependencies between components in each layer that does not follow the layered principle (i.e. there is a strict dependency from upper to lower layer).

As a comparison one can look at the following lists of Code Smells:
Wikipedia: Code Smell
A Taxonomy for "Bad Code Smells"
Coding Horror: Code Smells

Software Architecture conferences 2010

International Conference on Software Engineering (ICSE) 2010, 2-8 May in Cape Town. Paper submission was 6 September 2009.
Previous conferences had for example workshops on Automotive Software Engineering, Sharing and Reusing Architectural Knowledge and Leadership and Management in Software Architecture .
Workshop program is not yet published but preliminary deadline for workshop submissions are January 2010.

International Conference Series on the Quality of Software Architectures (QoSA), June 23-25, 2010, Prague, Czech Republic
Paper submission in February, I guess...

European Conference on Software Architecture (ECSA), IT-University Copenhagen, 23-26 August 2010
Submission deadline March 15, 2010

Anybody knows of other conferences on software architecture or on automotive software engineering?

Agile and Architecture

I have read and heard several "observations" on how to incorporate a guiding architecture in the current trend of having agile S/W development. There seem to be a lot of smoke but not so much substance, but I will try to summarise a few points which I have concluded through the smoke.

Caveat: My background is in automotive software, and there seems to be no business domain which is less agile than automotive...

Architecture is up-front design, so if no upfront design is important in you agile practice, then I claim the architecture will rather be manifested by your code than the result of making concious decisions between architectural alternatives. The question is if you could have a light architecture so that you avoid a big upfront design (BUD) and allow the architecture to evolve in parallel with the software while it still guides and controls the software development.

Most agile practices focus on delivering the functional behaviour (use cases, user stories, or whatever), which drives the software. Contrary to this architecture focuses on satisfying the non-functional properties as well, i.e. quality attributes which usually are system-wide. I think deciding between these two focuses is really a business decision on how you want the team to work. If the former is more important then you don't have the same need of someone preforming the role of an architect. If the latter is important it will be difficult to succeed if you don't empower them.
I have heard studies of agile practitioners that claim that non-functional properties are solved in re-factoring (for example one study by M.A. Babar at the experience track at the WICSA 2009 conference). I claim that some properties cannot be solved by re-factoring, for example in the development of safety-critical systems. But agile practices should perhaps never be used for development of those?

There seem to be a trend to use agile synonymous with no or little documentation. I don't mind having small architecture descriptions (AD). A possible problem: If the rationale is omitted to make the AD smaller, I think the value of the AD will be significantly less.

If I read the Agile Manifesto there is nothing that says you should de-emphasise a guiding architecture...

Some texts, blogs and presentations can be found with a little googling:
Software Architecture and Agile Software Development —An Oxymoron? by P Kruchten
Agile Architecture: Strategies for Scaling Agile Development by Scott W Ambler
Software Architecture-Centric Methods and Agile Development by Nord and Tomayko
The Formal Goodness of Agile Software Architecture, part 1 and part 2 by Dave Langer
Architecture Meets Agility by Hakan Erdogmus in IEEE Software

There is also a forthcoming book with the title "Lean Software Architecture" by Coplien and Bjørnvig, forthcoming in May 2010. They have some interesting links and excerpts on their website.

Software architecture book reviews

Some comments on textbooks on software architecture:

• Software Architecture in Practice by Bass, Clements and Kazman
• A Software Architecture Primer by Reekie and McAdam
• The Process of Software Architecting by Eeles and Cripps

I would say SAiP is the standard textbook on the subject in the sense it covers the what is commonly accepted as the main core of the subject of software architecture. It probably also is the most widely used text...
As a student text I think the main strengths is it's treatment of terminology and concepts, which also makes it useful as a reference.
A potential problem with this text is that the examples are vey high level. You need experience based in actual programming projects to see the connection between the examples in the book and actual implementations. It is also comparably weak in teaching how to design a top-level desing as part of an architecture. I would say this book is suitable for students at the end of their education.

A Software Architecture Primer is targeted directly to a student audience. I would say it is better if the knowledge in an architecture course should be used in later courses, e.g. a larger project course with co-operating teams, since it is more pragmatic and hands-on in defining a top-level design. Likewise I would guess it could suit a professinal who wants to start creating "simple architectures".

The Process of Software Architecting is the best (and may be the only one) that actually defines the process elements and tasks of architecting and how they would fit in a larger software development process. I would say this book is the best one for the professional architect that wants to more formally define or improve what they do; what inputs to use, what tasks to perform and what should be delivered. It may be suitable for students, but the process focus may make it harder to relate to, e.g. it would give very little help as a preparation for a student project course.

I like all three books and they all have their (different) purpose. Which book to get depends on who you are and what you intend to do or to learn. For a student in the first course on architecture I would suggest the Primer. As a S/W professional who wants to understand what an architect is talking about and why, go with SAiP. For a working architect who wants inspiration for improvement, go with the Process book.

Background: I got the opportunity to take a sabbatical semester from Volvo to teach an undergraduate course on software architecture and design of complex systems at the IT University in 2006. For various reasons I redesigned the entire course from scratch, with a few constraints; the teaching methodology should be a light version of problem-based learning (PBL) already established at the IT University, and the course book was already ordered by the university bookstore "Software Architecture in Practice" by Bass, Clements and Kazman.
I had no real problem with the choice of textbook, and it suited my intended course content quite well. I also thought the PBL methodology fitted very well with the topic of software archtiecture after the course.
I think the course was a success, it received praise form the students as one of the most interesting courses they had taken during their program, and I was very satisifed with the level of knowledge the students showed on the final exam.

Presentation on the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture

Here are the slides I used at my presentation at the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture in Cambridge 2009.

The presentation went well, but the questions showed that the audience was more interested in how the organisation perceived the role of it's own software architecture rather than the methodology and scientific conclusions. And the role of architecture was one thing that was not possible to generalise to other organisations...

Accurate numbers

I am going to present my paper at the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture on Wednesday. If I get a question where somebody wants me to quantify my qualitative research I need to refrain from doing this...

Yet another article on Ethernet, Firewire and MOST...

Yet another article on what communication technology will be used in future infotainment systems. Read it fast since the articles in Automotive Engineering tends to be removed from the on-line edition after a while...

ETHERNET and 1394 spar with MOST for infotainment openings

Most interesting to read that Toyota starts using MOST now in two vehicles (new Prius and Lexus RX). I have the impression that they would not "commit" to such a change in technology if they did not belive it would stay.

Review of the vehicle’s electrical and electronic architecture

Just being back from my summer vacation hiatus I found a good summary of present challenges for a vehicle’s electrical and electronic architecture from just-auto. I haven't figured out if the news archive is available forever so read it fast if you are interested...

A second interesting article was about the use of firewire (1394) in automotive applications: 1394 Automotive network enables powerful, cost-efficient in-vehicle networks for infotainment, navigation, cameras from Automotive DesignLine.

Some blog posts

Some blog posts which I think are interesting from an automotive software architecture viewpoint:

• Riversimple to Unveil Open Source Car in London This Month
• Genivi's Open Source Car Infotainment Efforts Ramping Up
• Video: Open Source for Car Infotainment
• GENIVI no threat to Microsoft in near term
• What TomTom suit may really be about

Paper accepted

Yes!!!

Dear Ulrik and Carl,

We are pleased to inform you that your research paper,

"A Case Study of the Architecture Business Cycle for an In-Vehicle Software Architecture",

has been accepted for inclusion in the program of the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture 2009 (WICSA/ECSA 2009), which will be held on September 14-17 in Cambridge, UK.

As with previous WICSA & ECSA conferences, we anticipate a lively gathering, drawing both academics and practitioners, and featuring paper presentations, keynotes, working group sessions, tutorials, and workshops.

Of the initial 112 submissions (of which 84 research papers), the program committee accepted 23 high-quality research papers. Congratulations on being included in this select group.

In preparing your paper for publication in the IEEE conference proceedings please keep in mind the following:
1. In order for us to include the paper in the proceedings, at least one of the authors must register for and attend the conference. If this is going to be impossible please let us know as soon as possible so we can adjust the conference program.
2. To the extent possible, your final version of the paper should reflect the reviewers' comments and suggestions for improvement.
3. The paper must be formatted according to IEEE proceedings guidelines and the final length is strictly limited to 10 printed pages. Further details may be found in the "Submission of Camera-ready Copy" section of the WICSA/ECSA 2009 web site at http://www.wicsa.net.
4. To accommodate publication schedules, final camera-ready copies must be submitted by June 30, 2009.

Once again, congratulations on having your paper accepted. We look forward to receiving your final revised paper, and to seeing you in September in Cambridge, UK.

Yours sincerely,

Flavio Oquendo, Eltjo Poort, Judith Stafford
Program Chairs, IEEE/IFIP WICSA/ECSA 2009

The paper has the following abstract

A Case Study of the Architecture Business Cycle
for an In-Vehicle Software Architecture
This paper presents the theoretical and practical benefits
from a case study using Architecture Business Cycle to
understand the management of software architecture at an
automotive manufacturer. The study was done to prepare for
architectural changes driven by new technology and in the
automotive business environment.
Our results show that the architecture business cycle
worked well in defining the theoretical context for the study
after some modifications; the architecture had to be precisely
defined in the interview situation to gain more useful data
rather than broad generalisations. Further contributions
of the study were a deeper understanding of role of the
architecture and it’s position among other artefacts in the
organisation, and an increased focus on architectural issues
in management meetings. The study also indirectly affected
a subsequent re-organisation.

What are OEMs doing in the field of software architecture?

A colleague from Ford in Dearborn asked me if I had any information on activities at other OEMs and Tier 1 suppliers in the area of software architecture. I did a quick search in my Zotero database and arrived at the following list. Some are available on-line, use Google Scholar to find.

1. F. Fabbrini, M. Fusani, G. Lami, and E. Sivera, “Software Engineering in the European Automotive Industry: Achievements and Challenges,” Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International, 2008, pp. 1039-1044
   Paper from Fiat


2. P. Giusto, S. Kanajan, C. Pinello, and M. Chiodo, “A Conceptual Data Model for the Architecture Exploration of Automotive Distributed Embedded Architectures,” Information Reuse and Integration, 2007. IRI 2007. IEEE International Conference on, 2007, pp. 582-587.
   Paper from General Motors


3. K. Grimm, “Software technology in an automotive company: major challenges,” Proceedings of the 25th International Conference on Software Engineering, Portland, Oregon: IEEE Computer Society, 2003, pp. 498-503.
   Paper from Daimler


4. Hans Grönniger, Jochen Hartmann, Holger Krahn, Stefan Kriebel, Lutz Rothhardt, and Bernhard Rumpe, “View-Centric Modeling of Automotive Logical Architectures,” TU Braunschweig, 2008.
   Paper from BMW


5. G. Reichart and M. Haneberg, “Key Drivers for a Future System Architecture in Vehicles,” Proc. Convergence 2004, Detroit, MI, USA: SAE, 2004.
   Paper from BMW


6. C. Tischer, A. Muller, M. Ketterer, and L. Geyer, “Why does it take that long? Establishing Product Lines in the Automotive Domain,” Software Product Line Conference, 2007. SPLC 2007. 11th International, 2007, pp. 269-274.
   Experience paper from Bosch engine management systems


7. S. Voget, “Future Trends in Software Architectures for Automotive Systems,” Advanced Microsystems for Automotive Applications 2003, Springer, 2003, pp. 457-469.
   Paper from Bosch


8. K. Nishikawa and K. Kajio, “TOYOTA Electronic Architecture and AUTOSAR Pilot,” Proc. SAE World Congress, Detroit, MI, USA: SAE, 2007.
   Paper from Toyota


9. D. Selin et al., “A Reference Architecture for Infotainment Systems,” Proc. Convergence 2004, Detroit, MI, USA: SAE, 2006, Document Number: 2006-21-0013
   Experience paper from Volvo Car Corporation


10. R. McGee, “Managing Vehicle Control System Architecture is a Key Enabler for Strategic Reuse,” National Workshop On High Confidence Automotive Cyber-Physical Systems, April 3-4, 2008, Troy, Michigan (USA)
    Position paper from Ford Motor Company

The list is not very long. I have some reasons why:

• Most research articles on automotive software architecture are written by researchers, not car manufacturers.
• Strategic decisions on software architecture can be seen as a business advantages and are therefore not published.
• I have a a quite long backlog of articles in the area of automotive software architecture which I have not read yet, there may be more among those.

I have also some news flashes in previous post in this blog which might be of interest. Search the label of Automotive software.

Interviews with Volvo EESE managers

I got a link to a web clip with an interview with my manager Hans Alminger on automotive software modelling from the Electronica Automotive Conference 2008. A bit late, but anyway...

A very recent interview with Hans' (and therefore also my) boss Lennart Lundh can be read in the latest issue of Automotive Engineer on integrating functionality in fewer and bigger ECUs. It does not get hotter of the presses than this...

Student Presentation on Software Architecture

This post is the next episode in the series of "Software Architecture Basics".

I found the following presentation made by some of the students of the Software Engineering & Management at the IT University. I'm impressed that they managed to boil down almost a full course to a single presentation with a rather light touch (yes, there are some technical details that could be discussed, but nevertheless).
I wish I could take credit for being their teacher, but I only gave a single lecture in their architecture course.

Software Architecture Presentation

The architecture of Lego

Some years ago I was asked to explain the concept of a product line architecture for some students that had not heard of the concept before. They were not very familiar with terminology used in the field of software architecture either so I had to do it on a basic level.

I decided to use an example outside of the software domain, namely the Danish toy system of Lego, since everybody in Sweden played with Lego as a kid. I guess the example looses it's pedagogical value if the audience has not seen Lego.

I did some revere engineering to identify architectural strategies and quality attributes. Pictures in the presentation are stolen from unknown internet sites...

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

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.

Microsoft automotive platform

Since I have written som blog posts about open source software for in-vehicle infotainment I think I should mention Microsoft's platform as well, used for exmple in Ford's Sync. Here are some information I found:

• Microsoft Auto
• Open source vs. Microsoft: Automotive battlefield
• Peter Wengert - Inside Microsoft Automotive (TV show)
• Engineering TV: Introducing Microsoft's Automotive Division (another TV show)

Software architecture resources on the web

I found some resources on the web which I think are useful for people concerned with automotive software architecture, either as some kind of tutorial or as reference material. Some are more generally about software architecture while others are targeted to automotive software.

• Patterns & practices Application Architecture Guide 2.0
• Automotive Software Workshop, San Diego
• JASPAR (but you need to know japanese to get the technical details)
• Software Architecture Views and Perspectives from Brad Appleton's ACME Blog
• Software Architecture Quality Attributes also from Brad Appleton's ACME Blog

GENIVI and moblin?

I still have not found any solid technical description about the GENIVI platform, but some internet detective work directed me towards the moblin homepage which has a community directed to LINUX use for in-vehicle-infotainment.
Seeing that both initiatives are open source based on Linux, that there are common members between GENIVI and moblin (i.e. Intel and Wind River) and the goals of the projects are very similar I assume the technical solution will also be similar. The moblin architecture is described here...

Industrial research in student projects

I was asked to talk about my research in the course Research Methods and Technical Writing, at the IT University, together with a number of other researchers here at ITU.

My first thought was talking about case study research in the industry, but another speaker would talk about case studies so I dropped that idea. In the end I decided just to talk about doing students project in industry in general. I have supervised 5 thesis projects so I think I have som knowledge on the subject by now...

I have just finished the lecture and I'm not very satisfied with the outcome. I got very few questions and found it very hard to find any enthusiasm among the students. The original plan was that I would give the lecture a month ago, but various problems with finding a slot in my calendar postponed the lecture several times, so when I finally held the lecture most of the students had already selected topics for their projects.

I made a test of using LaTeX for making slides. Unfortunately I haven't figured out how to share the resulting PDF in this blog. Suggestions are welcome...

GENIVI

Genivi is a brand new alliance to promote open source software for in-vehicle infotainment (official start March 2009). The founders include BMW, Wind River and Intel among others.
I have not heard about about the initiative before, but a quick google search revealed some introductory articles:

• http://www.genivi.org
• http://www.linux-magazine.com/online/news/bmw_in_drive_conversation_with_open_source
• http://www.linuxpromagazine.com/online/news/cebit_2009_bmw_and_partners_found_genivi_open_source_platform
• http://blogs.zdnet.com/open-source/?p=3663

Unfortunately there is not yet any technical information on the GENIVI homepage, but I will certainly follow up on this...

Narcissism

This blog post will contain some heavy narcissism on my part...

I wrote an article named Experience of introducing reference architectures in the development of automotive electronic systems together with some colleagues. I also gave an appreciated talk at the second international workshop on Software engineering for automotive systems, which was one of the workshops at the 27th International Conference on Software Engineering in St. Louis, MO, USA (ICSE 2005).

ICSE is one of the most prestigious conferences on software engineering (the most prestigious according to some rankings) so the paper should have some academic merit. But it is almost impossible to find my paper in any academic database. The paper is not included in INSPEC, which is the biggest general database about engineering and science, event though INSPEC has articles from ICSE 2005. It is not found in IEEE Explore. The only databases I could find it is in ACM portal, besides Google Scholar.
So it is unlikely my paper will be referenced since nobody knows it exists...

You can find a full-text version of my paper here, courtesy the Mälardalen Research and Technology Centre at Mälardalen University.

Note: INSPEC is not free to use, the other databases should allow you to search, but not download material unless you have a subscription. But Google scholar is usually very good at finding a PDF somewhere on the net if you have the title and author of an article.

AUTOSAR questions

I got a comment referring to a blog from a guy working with AUTOSAR implementation at GM.

He got some questions in his blog about AUTOSAR. I don't believe I have any definitive answers, but here are some quick thoughts...

..........is the architecture migration expensive ?
This was asked from a concern that the necessary tool support for developing AUTOSAR systems would incur expensive licenings costs compared to native development. I don't think the tool costs would be any higher compared to present tools (i.e. UML code generation tools or Simulink/dSpace). The big cost in migration to AUTOSAR would be the necessary change in OEM and TIER1 development processes. The cost of an experienced programmer is wastly greater than the cost of a S/W tool.

..........is AUTOSAR ISO compliant ?
Don't know.

..........does AUTOSAR emphasize on all key areas of the Embedded system ?
No, there are several proprietary concepts used by Volvo Cars when developing embedded systems that are not within the scope of AUTOSAR. I imagine it is the same for other OEMs as well.

.........how is the current AUTOSAR classified ?
This question I don't understand...

.........scope of AUTOSAR ?
At least the german OEMs and suppliers are very serious about AUTOSAR (e.g. BMW, Bosch and Vector). They have put hundreds of man-years into developing the standard and adapting their products.

.........is AUTOSAR going to provide a "AUTOSAR Compliant Hardware System" blueprint for automotive electronic hardware manufacturing companies ?
Not to my knowledge. I think this is left to the various suppliers to solve. "Cooperate on standards. Compete on implementation". I can imagine a scenarion where hardware manufacturers like freescale would deliver an "AUTOSAR-optimised" CPU with associated H/W-abstraction layer (part of AUTOSAR BSW).

Some websites about software engineering and programming

I found some more interesting websites. I don't expect to have time to explore all of them, but some should give a break me when I have lost inspiration on writing research papers...

Software Engineering Radio
Software Architecture, Architects and Architecting
Teach Yourself Programming in Ten Years by Peter Norvig (very short and interesting of why everything worth knowing takes time)
Next Dawn Programming Tutorials (mostly C and C++)

Recent relevant architectural knowledge...

I was asked by a former colleague if I could help him with some more recent relevant architectural knowledge. Coming from anther person I would have just given a standard answer (see for example this blog post), but since this request came from the person from I have learned almost everything I know about software architecture I felt I needed to give it a little more thought than that...

Some quick thoughts about the present status of software architecture (quick as in not thoroughly researched):

Software architecture is accepted as being useful in it's own right. The role of the software architect is being acknowledged as a separate role from other software practitioners having a different skill set.

The most common view is that architecture are components and their relationships (often explicitly defined interfaces), described in multiple views (like Kruchten's 4+1), just as in IEEE std 1471.

It seems to be commonly accepted that architecture design is driven by quality attributes, see the SEI web site for lots of information about this.

There are numerous architecture description languages (e.g. EAST-ADL2 or AADL) but none seem to emerge as a industry standard beyond UML 2.0. And I have not heard of too many examples of where ADLs are commercially used on a wider scale.

Nobody argues about the importance of patterns, but the reference is still Pattern-Oriented Software Architecture (POSA).

Some claim Service-Oriented-Architecture is dead, while others don't.

Standardised architectures seem to more and more common, AUTOSAR is one, Integrated Modular Avionics (IMA) is another. I'm sure there are more in other business domains I'm not aware of. Standardised architectures always seem to generate interest at workshops and meetings.

There are several on-line resources with solid material, some are directed to, or by, practitioners, like

• Grady Booch's blog
• patterns & practices Application Architecture Guide 2.0
• Resources for software architects from Bredemeyer Consulting
• Software Architecture web site at the SEI

Others are more directed to research, like

• Jan Bosch's website

One important recent trend is the emphasis on capturing architectural decisions and architectural knowledge, which several known researchers have thought been lacking and believe is one cause of failure for software projects. Read for example Jan Bosch's paper Software Architecture: The Next Step or Tyree and Akerman's Architecture Decisions: Demystifying Architecture.
This emphasis leads to merging the research disciplines of knowledge management with software architecture.

Mary Shaw and Paul Clements wrote a survey article The Golden Age of Software Architecture: A Comprehensive Survey about how the subject of software architecture has developed in the last 20 years, Kruchten et al. wrote a similar paper The Past, Present, and Future of Software Architecture.

Finally I like the article The Art and Science of Software Architecture by Brown and McDermid because they have a "unbiased" take on the present and future of the field.

AUTOSAR course

I have just come back from the first part of the AUTOSAR course at the Royal Institute of Technology. Including the invited teachers, where I was one, we were 20 people attending, with about 2/3 being from academia and 1/3 from industry.

I think the course went well, but it was obvious that AUTOSAR is a new way of thinking about how to build ECU software compared to what people are used to. I hope that I helped not only in presenting my own stuff but also could answer the questions from the other participants.

My presentation is seen below, for material from the others some can be seen on the course homepage.

Automotive software companies in India and some blogs

I found a blog post on automotive software companies in India. There are quite a few, and it seems many established TIER1s already have an office there.

I also found a number of blogs that has some relationship to my own blog:
Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal (it isn't me who made up the title...)
Martin Fowler's Bliki (he wrote the excellent book UML Distilled)
Grady Booch's blog on software architecture

AUTOSAR lecture

I have been asked by prof. Martin Törngren if I could be a guest lecturer in a course about AUTOSAR at the Royal Institute of Technology.
Sounds really interesting, since I hope to also participate in other parts of the course besides my own lectures. But it is also challenging since the first occasion is already on 9-10 February and I have no material prepared. I need to discuss this with my supervisor before I make a commitment.

Architecting Systems with UML 2.0

The best (and shortest) introduction to UML 2.0 from an architect's viewpoint is an article called Architecting Systems with UML 2.0 by Morgan Björkander and Cris Kobryn.
Obviously you need to know the basics of UML 1.0...

Case study of the Architecture Business Cycle

I'm writing a paper with the working title "A Case Study of the Architecture Business Cycle for a Vehicle Software Architecture" together with a co-author.
We have tried to identify how the Architecture Business Cycle (ABC) looks like for the software architecture in a modern vehicle with software deployed to 30-70 electronic control units (ECUs) connected by a number of multiplexed buses, such as CAN, MOST and LIN.

The main results we present are the benefits the Electronic & Electric Systems Engineering (EESE) department at Volvo Car Corporation has gained from participating in identifying the ABC. Of course there are some benefits also from a research viewpoint as well, for example how well we thought the ABC model worked for such a case study.
The data comes from in-depth interviews performed with 20 persons working at the EESE department.

Yet another conference

My supervisor, prof. Thomas Arts, have found another conference he thought might interest me: International Conference Series on the Quality of Software Architectures (QoSA).
Some of the topics listed in the call for papers are directly related to my research, e.g:

• design decisions and their influence on the quality of software architecture
• architectural standards and reference architectures
• coordination of business architecture, business processes, and software architecture
• traceability of software architecture to requirements and implementation

Unfortunately the deadline for submissions are already 8 February 2009 and it will be impossible for me to submit the paper I'm presently working on till then. Hopefully they might add a work-in-progress or a student session. I could go to the conference anyway, but it is always more productive if I have something to present.

Thomas also proposed I should think about giving an AUTOSAR tutorial on the WICSA conference. He thinks it would not be too much of work for me, but I think he is not aware how ambitious I usually am when it comes to teaching...

Quote

The best quote I have found this week about architecting a system, especially true for future car platforms:

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

From a presentation by Philippe Kruchten 22 June 2007: Who are the Software Architects and What Do They Do? There is an alternative download available here.
I think the slides were quite good as material for introspection. I would have loved to hear the presentation.

Software development takes over

I stumbled upon a news notice about how software development takes over the traditional product development in traditional Swedish industries such as Ericsson and Scania. Unfortunately it is in Swedish.
The article is published on E24, who claim they are the biggest business site in Scandinavia.

Much of what is stated in the article are things that I have discussed with colleagues and other researchers. But I think it is nice to have an "independent" source to refer to when I make a general statement about what type of business we are doing at Volvo Cars as a vehicle developer.

Feedback on my presentation

The two topics at in my presentation at the software architecture workshop that generated most questions (and discussions in the coffee break afterwards) were

1. The vertical versus horizontal development structure. This did not surprise me since I already knew that is an area of interest (see for example the article Software engineering for Automotive Systems: A Roadmap by A. Pretschner et al. in proceedings of ICSE 2007)
2. The handling of S/W variability, especially in an AUTOSAR context. This came as a surprise, and I certainly need to look into both what research and practical implementation have been done in this area. There has been some work on variability and AUTOSAR in the EAST-ADL2, but I am more interested in the technical implementation in the code than how to model variability.