Thesis chapter 12.1.7: Is automotive software different?

The context for the automotive industry regarding software development is not different compared to other embedded domains. This conclusion is based on the mapping study in chapter 7 over different approaches of embedded software development and the case studies performed in chapters 5 and 6.

Thesis chapter 12.1.6: Design goals

The leadtime reduction is supported by maximising the speed of the individual teams through their way-of-working, and by decouple the teams form each other through the composability of the architecture.

The ability to frequently deliver new software features is achieved both on a team level for the same reasons supporting the leadtime reduction form idea to implementation, but also through the concept of innovation experiment systems.

The decoupling of software from hardware development is achieved both by moving from centralised synchronised processes to more autonomous teams, and by providing suitable abstractions in the embedded platform underlying the application/feature software.

Thesis chapter 12.1.5: Research answer 1.4

Since more and more embedded products also are connected, it is conceivable to develop, deploy and measure usage on new software in iterations which lengths are determined by the speed of the software development teams instead of the setup of the manufacturing process, going from years to weeks. Such
an innovation experiment system (IES) would utilise feedback from real users of the embedded products in a scale comparable to the entire customer base.
The notion of continuous innovation is not new, but the concept is novel in the embedded domain.
The driver for having such an IES is that business and design decisions should be based on data, not opinions among developers, domain experts or managers. The company running the most experiments among the customer base against the lowest cost per experiment outcompetes the others by having the decision basis to engineer products with outstanding customer experience.
Chapter 11 presents three architectures to support IES for mass-produced devices with embedded software, which together with an infrastructure capable of collecting and analysing the data. Case VI implemented the thin client architecture for innovation experiments from chapter 11 and ran an experiment
collecting data from 7 users.
The conclusion is that it is technically feasible to implement an IES with the architecture defined in chapter 11, and that the measured data can support conclusions about implemented designs. The main contribution is the architecture for innovation experiment systems for embedded software. The concept of innovation experiment systems in this domain is completely new and the architecture is the first of its kind.

Thesis chapter 12.1.4: Research answer 1.3

Chapter 10 identifies 5 key activities to support an evolution of the R&D approach that would allow a transition for an OEM from a closed to an open software ecosystem:

1. Choose the ecosystem type
2. Open up the platform
3. Establish OEM as keystone organisation
4. Establish business opportunities for developers
5. Establish infrastructure for continuous deployment of software

The contribution is the five identified key activities. Since there is no widely known open software ecosystem for embedded products such as the one described in chapter 10 it is difficult to present proven industrial cases. Chapter 10 provides some insights on how an open software ecosystem could look like for the automotive domain.

Thesis chapter 12.1.3: Research answer 1.2

Chapter 9 answers RQ1.2 by identifying the following quality attributes as necessary for a platform allowing for composition of independently developed software, the platform being a precursor for an open software ecosystem:

• Composability: The software platform must fulfil a set of properties to allow the decoupling of applications and eliminate the need for development synchronisation. The architecture should allow development, integration and validation of applications independent of other applications.
• Deployability: The applications must be possible to deploy independently of each other, and the product behaviour must not depend on the order in which applications are installed. There must also be a deployment infrastructure in place which fulfils necessary integrity requirements.
• Maintainability: The platform must be sufficiently stable over time. Since the platform and application evolution is decoupled, i.e. no synchronised versioning, backwards compatibility is a key attribute.
• Configurability: The platform must support variability in the hardware configuration of sensors and actuators since individual products can vary within the product family.

In addition to these there are two more quality attributes that affect the business value for embedded products in various domains, but are not universal:

• Consistent User Interface: This is often considered important by manufacturers of embedded consumer products since much of brand recognition and willingness to stay with the product brand lies here. The other major aspect for brand distinction is the qualities provided by the hardware (precision, reliability, etc.).
• Dependability: Many embedded domains have stringent dependability requirements. These domains are probably not the first adopters of an ecosystem-based approach to software development. However, if that was the case the embedded platform would satisfy; real-time requirements for the execution of individual applications, integrity requirements, high availability, and mechanisms to eliminate undesired feature interaction if several applications interact with the same actuators.

A reference architecture was designed to enable the qualities above, consisting of 20 architectural decisions together with 4 architecture patterns for:

• Device abstraction
• Data and service provision
• Device and information composition
• Safety-critical, certified and open application access

The conclusion is that it is conceivable to develop a platform suitable for compositional development, as a precursor for an open software ecosystem. The system in case VI implements most of the design decisions from chapter 9, but not all, leaving out mostly those related to safety-critical functionality.
The contribution is the novel reference architecture for composition of independently developed embedded software applications, suitable for using in an open software ecosystem. Open software ecosystems are not new, but no reference for implementation in the embedded domain is published in literature.

Thesis chapter 12.1.2: Research answer 1.1

RQ1.1 is answered in chapter 8, which explores agile development for individual teams as a way-of working in the context of large MPES projects. Chapter 8 prescribes a set of 19 measures , and are based on a model  over the critical interactions a team doing agile software development has to the rest of the project organisation.
Each measure is either a prerequisite for agile development, e.g. must be defined in the pre-game phase of Scrum, or an activity while doing the iterations, e.g. in the game phase of Scrum.

• Requirements The requirements measures encompasses how the software requirements implemented by the agile team relate to the requirements of the finished product, they typically contain both functional requirements experienced by the end-user, but also quality attributes, such as testability. The model also includes the methods and tools for capturing and transferring requirements in this category.
• Project gates The project gate measures focuses on the interface between the software development team and the full product project. This includes the static organisation of the project including governance and reporting, as well as basic principles for driving and measuring progress.
• Validation Validation measures are concerned with the interface between agile software development and the validation of the product as a whole. The category includes activities necessary to integrate the various software and hardware parts to a whole, how this whole is verified against the requirements and the validation of the full product.
• Software delivery The delivery category describes the principles for how the finished software is delivered to the end-user. In mass-produced embedded systems the software and the hardware is delivered as a single product and this is the only possibility if the software is stored in ROM. The business model is similar in this approach as in the common practice of Rorqual organisations, and hence this interaction category is not explored.
• Internal practices These are the measures that have no direct relationship to other software development teams or the rest of the organisation, and are thus up to the agile teams. However, in our experience, these are important for successful implementation of agile development in the context of mass-produced embedded systems.

There are two contribution: first, a model for the interactions between individual development teams and the organisation as a whole, focusing on the exchange of artefacts. The model supported analysis of three separate cases of where teams did agile development in an industrial context. Second, based on the model a set of prescriptive measures supporting the teams adopting agile development methods were defined.