Thesis chapter 2.6: Research questions

To study the identified problems with software development of mass-produced embedded systems,  and at least partly solve, and to achieve the goals above a set of research questions was identified:

RQ1: What are the archetypical approaches for software development in the embedded domain?
RQ1.1 What ways-of-working in an R&D organisation for mass-produced embedded systems can create new options for business?
RQ1.2: What are the key properties of architectures for mass-produced embedded systems to create  business options?
RQ1.3: How can an OEM evolve the R&D process to support a transition from a closed to an open software ecosystem?
RQ1.4: How can an embedded architecture support innovation and delivery of new features of value to the customer?

The investigation of RQ1.1 support research goal G1 of leadtime reduction. The investigation of RQ1.2 and RQ1.4 support research goals G1, G2 and G3.

The project uses automotive software as a concrete example of mass-produced embedded systems. A question which might be answered during the project is if the context for the automotive industry regarding software development is so different it demands other ways-of-working and architectures compared to other business domains?

Thesis chapter 2.5: Project goals

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.

This lead to three goals for an original equipment manufacturer aspiring to be world leading in software development:

1. Minimise leadtime from idea to implementation of new software features.
2. The ability to frequently deliver new software features to end customers
3. Decoupling of software development from hardware and mechanical development, both in time and by the design dependencies

Thesis chapter 2.4: Innovation

Innovative ideas for embedded products are typically collected and prioritized during the roadmapping and requirement management process as part of the yearly release cycle. This cycle is usually determined by manufacturing concerns of the hardware. Feedbacks on innovations from real customers are collected only on new product models, if collected at all.

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 (link to Ries, link to Bosch}, 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.

The innovation experiment system focuses on incremental innovation according to the framework by Henderson and Clark. The short iterations of experiments are primarily aimed to refine and extend established designs. Improvement occurs in individual software parts, but the underlying design concept remain mostly unchanged, even if there is nothing that prohibits the evaluation of e.g. architectural innovations as well.

Thesis chapter 2.3: Software ecosystem

Software ecosystems are characterised by a network of developers rather than a single organisation providing the final product to the customer. An example would be the app markets for Android and iPhone users, where 3rd party developers deliver applications directly to the end user based on a provided platform and through an established infrastructure and marketplace.

The strategic approach of developing software in an open ecosystem instead of as an integrator towards the customer is new in the domain of mass-produced embedded systems, but could provide some advantages also here, for example by extending the innovation base and sharing development risks.
The OEM would still play a vital role as keystone organisation in an open software ecosystem since it manufactures the product and delivers the platform underlying the ecosystem.

Thesis chapter 2.2: Architecture

Architecture is defined as "the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."
The architecture is an enabler to achieve certain system qualities, or non-functional properties, and many organisation view their architecture as a strategic technology asset.

An important part in designing an architecture is to identify the organisation or structure of the software and systems parts necessary for the desired qualities. If a certain design or style is used consistent throughout the design of the system it can be considered an architectural pattern. However there are reports that quality attributes are of less importance to users or customers, and this suggest that identifying and delivering competitive features may be more critical to business competitiveness.

Many systems are built on available platforms or frameworks, such as .NET for Microsoft Windows applications, Android for mobile phones or AUTOSAR\footnote for automotive software. The choice of platform constraints the design choices, but also decreases the development effort, at least in theory, and allows software to conform to explicit or implicit domain standards. The challenge for the OEM is to tailor the applications built on top of these platforms to a competitive product. In a sense these types of platforms constitute a reference architecture for a specific product or system architecture.

In this thesis a reference architecture (RA) captures the design ideas and patterns that permeates the architecture with a focus on the design decisions that have great impact on the product family as a whole, i.e. the reference architecture is a template for a specific product or system architecture
This definition of an RA is what is categorised as a ``non-structured reference architecture'' according to Angelov et al., and thus falls outside of their five types of structured RA.

An RA and a product architecture differs, among many other aspects, in that the reference architecture dictates the patterns and principles to implement, i.e. what the design should be,  while the product architecture instead captures the instance of the reference architecture with deviations meeting various constraints, i.e. what the design is. Another difference between an RA and a product architecture is that the latter gives a coherent view of the product(s) in a project, possible to track the status of.

Thesis chapter 2.1: Ways-of-working

An OEM manufacturing and selling complex embedded systems also use a more or less elaborate R&D process to arrive at the finished design of the product. Ways-of-working refer to the both this overall process used by the organisation as a whole and to the methods and practices that teams and individual developers use within this process.

One of the most common ways to describe the overall R&D process is through a V-model or a waterfall model, with requirements elicitation, design, implementation, testing and maintenance occurring as successive activities.

A more iterative R&D process would follow a spiral model where the successive activities would be iterated, ``spiralling in'' towards the final product via a number of prototypes before delivery.

Agile processes are pushing the concept of fast iterations even further, aiming at having working software after each cycle, which typically last 2-6 weeks. There exist a number of specific agile processes, with XP and Scrum being the two most common. XP prescribes a set of practices even for the individual developers such as pair programming and continuous unit testing. Scrum focuses on the process for the team, e.g. how to prioritise and track what is being implemented.

One of the present challenges is how to scale agile from single teams to large organisations, Spotify being one example. The challenge is how to enable an entire R&D organisation to work with very short iterations when multiple teams work on the same product or systems where some customer features are realised by multiple sub-systems working together.

The most common approach to develop complex embedded systems is with an integration-centric approach, as defined by Bosch & Bosch-Sijstsema: Early in the development cycle requirements are allocated to components. The development teams implement the requirements allocated to their component. After the finalisation of the components the integration phase starts where all components are integrated to form the complete systems and system level testing takes place, where most integration problems are found and resolved.

A common way to manage a development project for MPES is to follow a stage-gate process, where the gates are driven by decisions and investment in the manufacturing of the product, i.e. driven by the hardware.
The  gate progression of the development process often correspond to finalisation of software artefacts, e.g. user requirements, system requirements, software architecture, component requirements, and software implementation, i.e. a waterfall process even if the artefacts are updated as the project progresses.