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.