Thesis chapter 2: Research motivation

Embedded software is becoming increasingly complex. Ebert & Jones show that the size and complexity of software in an embedded product increases exponentially over time. Numbers from Volvo Cars show a similar exponential evolution (seen in figure the figure below), not only for the infotainment software, which resembles mobile phone features, but also for "traditional" vehicle functionality.

Software in Mbytes downloaded in a vehicle at production at VCC over the years.

Ebert & Jones mention factors contributing to the complexity in their survey of the present state of embedded software development: ``combined software/hardware systems equipped with distributed software, computers, sensors, and actuators'' which points to the integration aspects of these systems. They list "high demands on availability, safety, information security, and interoperability" as typical quality attributes.

Ronkainen & Abrahamsson also emphasise that embedded systems are characterised by the concurrent co-design of hardware and software. They stress that the `"dynamics of co-design - i.e. the way it effects the concurrent software development processes, has to be understood in order to enable the use of agile software development methods."

Manhart & Schneider describe agile development of software in buses at Daimler-Chrysler. They mention for example that "equipment, functions, or parameter sets are implemented by integrating different proportions of third party- and OEM manufactured components" indicating supplier involvement. In their paper they also point out that software realises "complex electric or electronic functions", e.g. the integration between hardware and software.

The domain of large industrial development of mass-produced embedded systems can thus be defined by five characteristics:

• Deep integration between hardware and software for significant parts of the functionality 
• Strong focus on manufacturing aspects of the product during development (e.g. by project gates) 
• Strong supplier involvement providing a majority of the parts, and associated value, of the finished product 
• Some parts of the software and hardware realise safety-critical functionality 
• Long production life-time, sometimes spanning years for a single product model

These types of systems can be categorised as mass-produced embedded systems (MPES).

Broy states some challenges that automotive software is experiencing: "The high intensity of software in cars puts the car industry under stress and a high change pressure." He continues that the trend is not close to an end, and is driven by e.g: "High demand of new innovative or improved functionality'', "shorter time-to-market'' and "increased individualization".

In addition to these challenges the development of MPES exhibit some inherent problems for the R&D organisation, amplified by the present ecosystem of specialised suppliers and OEMs acting as system integrators:

• Heavy reliance on external developers and subcontractors complicates coordination through process because each of them use their own processes.
• Outsourcing of significant parts of development to suppliers causes expensive communication and coordination delays during integration. The cause of this is each issue found must be resolved through an OEM-supplier roundtrip with the OEM identifying the issue, discuss with the supplier(s) who resolves it, and the OEM re-integrating the "fixed" parts.
• The exponentially growing feature content severely complicates "big-bang" integration because used architectures requires all parts to be present for the system to work and therefore testable.

This research project started with the ambition to create opportunities provided by an R&D organisation in terms of new ways-of-working, new architectures, and possibly supporting new ecosystems. These opportunities could enable new business models for OEMs delivering mass-produced embedded systems, while at the same time mitigate some of the problems described above.

The choice of focusing on ways-of-working, architectures and ecosystems was done for three subjective reasons: In my experience it is easier to change these aspects than e.g. culture, knowledge management, or organizational structures. My engineering background made it easier for me to analyse and develop artefacts in these areas. This is a thesis in software engineering, and all these three areas are well within this field of research.

Thesis chapter1: Software in mass-produced embedded systems

Software is prevalent in many products manufactured today; cars, washing machines, mobile phones, airplanes and satellites (link to paper), the embedded software controls the behaviour of the product and is often critical for the success of the product.

Typically these products are developed in large, and sometimes very complex, industrial projects where the manufacturing and delivery of the product in general is a heavier investment than the software budget. In the automotive domain the purchasing and manufacturing cost of the physical parts for each product is typically an order of magnitude higher than the R&D cost split over the number of products built.
This in turn tends to drive the entire R&D process, and software follows the process logic of the mechanical development and manufacturing setup.

Software differs compared to its mechanical and electronic counterparts; once the software is developed there is no additional cost if one increases the number of products produced.
Likewise, the cost of updating or replacing software in an already built product is orders of magnitude cheaper compared to replacing hardware.

The common business model is to sell the manufactured system as a product, the original equipment manufacturer (OEM) gets paid an agreed amount for each system delivered. From a customer perspective there are some issues with this present business model when it comes to features purely relying on software. An example scenario in the automotive domain could be:

My neighbour bought a new Volvo four months after I did.
He got Spotify, but I didn't.
Do I feel ``cheated''?

Another example scenario would be

Google music turns out to be the next hot thing. It takes Volvo 30 months to include this feature according to the present stage gate process. Is the feature still ``fresh'' when delivered?

A future scenario could be that Spotify is deployed to customers independently of when the car is built in the factory, i.e. after the customer has received the vehicle.

With more and more vehicles becoming connected it is conceivable to have continuous updates with new software features to customers on a scale and to a cost that is impossible would the updates require hardware modifications. This would build trust in the brand to maintain a useful product and extend the value for the customer after the purchase.

The team developing Google music could deploy it after 3 months of development, making it ``almost competitive'' with smartphones. More and more services are used regardless if one is using the phone or driving in a car, and from a customer perspective it is difficult to understand why services in one context is cannot be delivered in another.

The topic of investigation in this thesis is efficient and sustainable development of software for mass-produced embedded systems (MPES), and the implications a chosen way-of-working and software architecture have on R&D, and indirectly on the business.

Thesis: Preface

I promised to post my thesis in a previous post. I hoped to have done so already last week, but things don’t always go according to plan. Here is at least the preface.

I don’t know if I should post a new chapter every day during Christmas, if I want to attract readers interested in development of software for embedded systems I guess this it’s not the best period.

This thesis is the result of my conviction that there was an untapped potential of improving present software development in the automotive domain, based on 10 years of industrial experience at Volvo Car Corporation.

The research project described in this thesis started with a goal of improving the architecture process and the management of software architectures in the automotive domain.
The goal evolved as the project progressed to use the right architecture as a means to improve the overall software development process in order to enable shorter leadtimes and to develop and release new features at a sustainable pace indefinitely.

I started the research project with the assumption that one of the main reasons for the automotive domain of not adopting best practices from other domains is that this domain has very different prerequisites compared to other domains, in the form of business practices, architectures and product properties. An assumption that I have completely reversed since I could find nothing in my empirical data supporting it when I compared with published cases form other domains.
The only reasons left that could explain this is a culture of “not invented here” in the automotive domain when we are looking at how software businesses, architectures, processes and teams play out in other domains.
Hopefully this thesis could be a step towards a better understanding that the automotive domain has more in common with other domains of software-intensive systems, than differences.

Hiatus

The blog has not been updated at all in the last few months. This has many reasons, with the main being me trying to finish my thesis.
I hope to have a coherent draft ready in just a few weeks and plan to post the chapters of the summary as blog posts in December. Comments are appreciated (if there still are any readers out there).

Is software engineering research relevant?

I try do be a software engineering researcher. If I scrutinise myself I am as much an engineer as a researcher, and a systems engineer on top of that (but with a clear focus on software-intensive systems).

While trying to finish my thesis I often question if I investigate relevant problems from an industrial perspective, which I believe is the only valid perspective in software engineering, everything else is just playing around. Since software development is a completely artificial activity there are not natural phenomena to study, everything is the result of human activity (and ingenuity).

After attending my latest conference, which had a mix of industrial presenters (probably not peer reviewed) and academic presenters (peer-reviewed, of which I was one) I discussed with a colleague. The conclusion we reached was that the academic researchers had a lot of substance in their presentations, but lacked relevance, while the industry presenters had relevant topics, but lacked substance. The latter seemed in many cases more like a sales pitch.
I have also heard in panel debates at other conferences that software research are diverging from industry needs. This is serious! But what is the problem? Are researchers really addressing the wrong thing (I have already complained about formal methods research)? Or is the step from a published research paper to implement it beyond a simplified academic setting too large for practitioners to take? Or are there so many conflicting research "results" that it is impossible to draw any conclusions as a practitioner beyond personal heuristics? In structural mechanics there are the laws of physics that constrain what is working or not, in software there is no clear boundary like that.
Personally I believe it is the gap, it is just not possible for practitioners to grasp how the results are relevant in their context since research is trying to be as general as possible, i.e. trying to cover as many contexts as possible and in the end not being relevant for any context. Resarch results only valid in a specific context (e.g. a deep case study) are considered second-rate by the research community and often does not pass through the eye of the needle.
There are many different views on the relevance, for example read this report on the future of software engineering research.

What can be copyrighted?

Since taking the course on Ethics and Intellectual Property at Chalmers I have become increasinlgy interested in how copyright and patent laws affect software development. United States of America have different patent laws compared to western Europe, usually more obliging of what can be patented, but the legal rulings in the former concern also software used in the latter.
Just a few days ago the verdict in the case of Oracle v. Google regarding copyright infringement on Java API was determined with the concölusion that it is not possible to copyrigth an API, but certainly the implementation of it. A summary of the verdict was written by the judge, William H. Alsup, and is most interesting to read. I think it shows a great understanding of the context of software development from a legal perspective.

Watch an interesting film about the american patent system and software patents: Patent absurdity.