Future car trends?

Here are some external links that might be of interest. I cannot vouch for the accuracy of the trend predictions (lets say they don't fulfill the criteria for scientific papers), but they give input to forming personal opinions.

• A comprehensive study on innovation in the automotive industry. Note that the report is from 2007 and much of what they predict to 2015 is still far away...
• Think How Much Smarter Your Car Will Be In A Few Years. Some insight into cutting edge car technology.

Thesis chapter 12.3: Future work

Suggestions for future work are:
A successful transition to more autonomous development on a team level seem to depend on dedication and enthusiasm among developers, strong domain knowledge in the team(s), stable interfaces to other systems, and a good systems engineering foundation (in the form of a systems design or architecture). Further studies of sufficient prerequisites should be of great interest to practitioners and researchers alike.
Further research on how to mitigate issues with synchronisation and integration of many teams in large projects, where scaling of agile practices is just a special case. Of special interest is if the responsibility can be completely moved from the process to the architecture, creating a completely composable system where successful integration is assured just by following the architecture.
More studies with industrial validation of innovation experiment systems for embedded systems are needed.

Thesis chapter 12.2: Summary of contributions

The thesis provides the following contributions:

First, it presents a rich insight in the industrial development of embedded software through a number of industrial cases. The deep description is valuable both for researchers to better understand the relevance of potential research problems, and for professional practitioners to relate the context they are working in with other organisations.

Second, it presents a model of 5 approaches of industrial development of embedded software, ranging from integration-centric development focusing on. This model describes the approaches in more than one dimension, highlighting that differences between R&D approaches is not seen in e.g. just the process dimension, which is new.

Third, it defines a model for the interaction between individual development teams and the organisation as a whole, and based on this model a set of prescriptive measures supporting individual teams adopting agile development methods.

Fourth, it defines a 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 is published in literature.

Fifth, it defines an 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.

The artefacts developed above are all tried and evaluated in an industrial context, i.e. in a “real” project setting with professional practitioners.

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.

Thesis chapter 12.1.1: Research answer 1

RQ1 is answered in chapter 7. Based on a mapping survey 5 archetypical approaches of embedded software development were identified:

• Approach E: Rorqual organisations The business goal is to minimise risks associated with technology investments. The architecture optimises qualities observable at run-time for the user/customer. Stage-gate or V process based on calendar time with gate progression corresponding to design artefacts. The organisation is functionally structured with a central systems engineering team responsible for the complete product properties which interacts with all the development teams.
• Approach D: Autonomous Teams The business focus is on physical delivery of a product (or thousands of products) to the customer and minimising technical risks. The architecture is still tailored towards satisfying product qualities, requiring a lot of effort spent on defining, verifying and maintaining interfaces, as well as integration of subsystems throughout the project. Development is done in short iterations on the module/team level (figure 7.4), but the deliveries are still planned towards scheduled integration points. The organisations consist of self-directed teams, who usually want to adopt practices such as XP or Scrum. The teams are more or less autonomous in their approach with respect to other teams they are interacting with.
• Approach C: Adaptive processes The business is focused on technology and technological innovation while still preserving key product quality attributes common in the domain. The architecture of the product is still tailored towards satisfying product qualities. The process adaptation adjusts the schedule to the size and scope of what is being developed with no fixed integration times, the teams practice continuous integration. As a result the software and hardware development processes are usually decoupled. The teams are self-directed, both in their ways-of-working and also in defining the deployment date for their deliverables.
• Approach B: Architecture for composition The architecture, processes and organisation is adapted to fast development in short iterations, but the product management and business model is still “traditional”, focusing on delivering and getting paid for each product. The architecture supports qualities affecting the speed, effort and cost for the developing organisation which are weighted against product qualities discernible at run-time and cost of ownership. The organisation as a whole develop software in short iterations and likely to apply e.g. continuous integration of software. Teams are self-directed with responsibility for end-customer value.
• Approach A: Marlin Organisations One of the major business drivers is to minimise the risk associated with offering the wrong product or developing undesirable features. Software is a major differentiator in the ability to attract and maintain customers, and therefore short leadtimes to launch is needed to stay competitive. The architectures optimise the ability to develop products and features with the shortest possible leadtime. Typical properties are modularity and composability of software from different teams. The process is highly iterative aiming to take small development steps and validate these in each evolution, in some cases with real customer feedback. The organisation consists of self-directed and self-organised teams containing cross-functional competences of product management, architecture, design & implementation and testing, capable of invention and launch of new features autonomously.

The first key observation is that the Rorqual (E) approach is the most common way to develop embedded software and can be considered the common practice1. The second most common approach is having autonomous teams (D) using e.g. agile development on the team level.
The second key observation is that the evolution of an organisation goes from E to A, with the most common just being going from E to D. In no case there was a description of an movement in the opposite direction, and my conclusion is that evolution through the model is always uni-directional.
These two observations together suggests an order in which organisation may adapt new practices and is therefore suggested as a prescription of process and architecture changes.
The scientific contribution is the multidimensional model of R&D approaches. In contrast to one-dimensional models this one describes the approaches in the four dimensions of business, architecture, process and organisation, highlighting that differences between R&D approaches may not be seen when observing e.g. just the process dimension.

Thesis chapter 12.1: Research and design goals

The thesis project identified three goals for an original equipment manufacturer aspiring to be world leading in software development:

• G1: Minimise leadtime from idea to delivery of new software features.
• G2: The ability to frequently deliver new software features to end customers
• G3: Decoupling of software development from hardware and mechanical development, both in time and by the design dependencies

These goals led to the need to study, and at least partly solve, problems with software development of mass-produced embedded systems. Based on this following research questions was defined:

• 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?

Thesis chapter 12: Conclusions

This thesis described how an R&D organisation can create new business opportunities by selecting appropriate ways-of-working, new architectures, and possibly support new ecosystems. These ways-of-working and new architectures could enable new business models for OEMs delivering mass-produced
embedded systems, while at the same time mitigate some of the problem presentably common in the domain.
The main contributions of the thesis, described in chapters 5-11, are based on 7 papers (5 already being published and 2 submitted to peer-reviewed journals):

• Chapters 5 and 6 describe three detailed cases of how architectures presently are developed and maintained for automotive embedded systems. The rich description provides a background of current practice of software development of mass-produced embedded systems.
• Chapter 7 identifies and models 5 approaches to develop embedded software, based on a mapping study of 23 papers.
• Chapter 8 describes agile development for individual teams in the context of large MPES projects. This would allow the length of iterations from idea to implementation to be determined by the potential speed of the individual development teams and not the overall product development project.
• Chapter 9 designs a compositional architecture for embedded software as precursor for open software ecosystems.
• Chapter 10 explores open software ecosystems as possible approach to development of embedded software. This would extend the base of innovators beyond what is presently hierarchically directed by the OEM to support delivery of innovative features with value for the customer.
• Chapter 11 describes innovation experiment systems for embedded products and defines a reference architecture supporting such an R&D approach.

Thesis chapter 11: Architecture for Large-Scale Innovation Experiment Systems

This chapter explores architectures when innovation experiment systems is used as a development approach to embedded software, i.e. when an organisation operates at approach A from chapter 7.
A shorter version of this chapter is previously published as

U. Eklund and J. Bosch. “Architecture for Large-Scale Innovation Experiment Systems”. Proceedings of the WICSA/ECSA. Helsinki, Finland: IEEE Computer Society, 2012, pp. 244–248. isbn: 978-0-7695-4827-2. doi: 10.1109/WICSA-ECSA.212.38.

Abstract

Business and design decisions regarding software development should be based on data, not opinions among developers, domain experts or managers. The company running the most and fastest experiments among the customer base against the lowest cost per experiment outcompetes others by having the data to engineer products with outstanding qualities such as power consumption and user experience.
Innovation experiment systems for mass-produced devices with embedded software is an evolution of current R&D practices, going from where innovations are internally evaluated by the original equipment manufacturer to where they are tried by real users in a scale relevant to the full customer base. The turnaround time from developing and deploying an embedded product to getting customer feedback is decreased to weeks, the limit being the speed of the software development teams.
The paper presents an embedded architecture for realising such a novel innovation experiment system based on a set of scenarios of what to evaluate in the experiments. A case is presented implementing an architecture in a prototype in-vehicle infotainment system where

Thesis chapter 10: Introducing open software ecosystems for embedded systems

This chapter investigates a possible way for an an organisation to move from approach B to A, and explores open software ecosystems as possible approach to development of embedded software.
A shorter version of this chapter is previously published as

U. Eklund and J. Bosch. “Introducing Software Ecosystems for Mass-Produced Embedded Systems”. Proceedings of the International Conference on Software Business. Lecture Notes in Business Information Processing. Cambridge, MA, USA: Springer, 2012, pp. 248–254. isbn: 978-3-642-30745-4. doi: 10.1007/978-3-642-30746-1_20.

Abstract

Embedded systems are today predominantly developed with an integration-centric approach. The paper identifies the need to remove fullscale integration and process synchronisation of involved development teams. The paper presents software ecosystem as an alternative approach to develop embedded software and identifies a set of key activities for how an original equipment manufacturer can introduce an ecosystem. An example of a software ecosystem is presented for the car industry together a case which implemented some of the ecosystem platform properties.

Thesis chapter 9: Compositional architecture for embedded platforms

This chapter explores composition architectures for embedded software as precursor for open software ecosystems, i.e. architectures suitable for approach B: Architecture for Composition from chapter 7.
This chapter was submitted as an article to Journal of Systems and Software in 2012.

Abstract

Open software ecosystem are proposed as a sustainable approach to develop software for embedded systems, and the paper elaborates on the necessary properties of an embedded platform and design an architecture to facilitate a successful establishment and growth of ecosystems for embedded software.
The paper defines a set of qualities for an embedded ecosystem platform that are necessary in addition to domain-specific qualities. Based on these 20 key architecture decisions are defined, together with the rationale why they are critical for an open ecosystem platform for embedded systems in general and automotive systems in particular. The decisions constitute together with four architectural patterns a reference for embedded open software ecosystems.
An industrial case of the prototypically implemented architecture, satisfying some of the identified quality attributes, is presented to provide a deeper understanding of how the architecture could be realised in the automotive domain.
Four potential existing platforms, all targeted at the embedded domain (Android, OKL4, AUTOSAR and Robocop), are evaluated against the identified quality attributes to see how they could serve as a basis for an open ecosystem platform with the conclusion that while none of them is a perfect fit they all have fundamental mechanisms necessary for an ecosystem approach.

Thesis chapter 8: Applying Agile Development in Embedded Systems

Most research tend to focus on what is troublesome when introducing new ways-of-working in “traditional” organisations.. This chapter investigates how an organisation moves from approach E to D in the model of
chapter 7, with the aim to facilitate agile development for individual teams in the context of large MPES projects.
The chapter is previously published as

U. Eklund and J. Bosch. “Applying Agile Development in Mass- Produced Embedded Systems”. Agile Processes in Software Engineering and Extreme Programming. Vol. 111. Lecture Notes in Business Information Processing. Malmö, Sweden: Springer, 2012, pp. 31–46. isbn: 978-3-642-30349-4. doi: 10.1007/978-3-642- 30350- 0_3.

Abstract

The paper presents a method to manage critical interactions to manage when introducing agile software development in mass-produced embedded systems. The method consists of a context model together with a set of measures, and is validated by empirical evidence from three cases.
From an industrial perspective, the paper provides a prescription on how to implement agile software development outside the typical domains for agile, in this case for mass-produced products with embedded software governed by a stage-gate process for mechanics and hardware.
From a research perspective, the paper provides an analysis of the software development cycle for products with embedded software, especially where product development as a whole is driven by a plan-driven process. The main contribution is a method for introducing agile in areas where by necessity the full R&D process cannot be agile.

Thesis chapter 7: Fast software development and slow embedded projects

This chapter identifies and models various approaches to develop embedded software, and relates them to two different business models.
This chapter was submitted as an article to Journal of Software: Evolution and Process in 2012.

Abstract

This paper provides an overview of the problem context of software development of manufacturing-intensive embedded systems, with distinguishing factors such as the co-design of software and hardware, strong focus on manufacturing aspects, supplier involvement and safety-critical functionality.
A mapping study over existing industrial cases in literature is presented, and a model consisting of five distinct approaches to embedded software development was identified based on the study. The approaches range from "traditional" stage-gate projects foucisng on product qualities and large integration efforts, to fast development in short loops by autonomous teams based on a composable software platform.
The model was evaluated and elucidated by three empirical cases from a Swedish company.

Thesis chapter 6: Architecting automotive product lines: Industrial practice

This chapter is previously published as

U. Eklund and H. Gustavsson. Architecting Automotive Product Lines: Industrial Practice. Science of Computer Programming (2012). doi: 10.1016/j.scico.2012.06.008

Abstract

This paper presents an in-depth view of how architects work with maintaining product line architectures at two internationally well-known automotive companies. The case study shows several interesting results: The process of managing architectural changes as well as the information the architects maintain and update is surprisingly similar between the two companies, despite that one has a strong line organization and the other a strong project organization. The architecting process found does not differ from what can be seen in other business domains. What does differ is that the architects studied see themselves interacting much more with other stakeholders than architects in general. The actual architectures are based on similar technology, e.g. CAN, but network topology, S/W deployment and interfaces are totally different. The results indicate how the company’s different core values influence the architects when defining and maintaining the architectures over time. One company maintains four similar architectures in parallel, each at a different stage in respective life-cycle, while the other has a single architecture for all products since 2002. The organizational belonging of the architects in the former company has been turbulent in contrast to the latter and there is some speculation if this is correlated.

Thesis chapter 5: The architecture business cycle for an in-vehicle software architecture

Due to copyright transfer to various publishers I am unable to publish full articles in the blog. I'll provide links to the official pages and the abstract of the papers. If you use Google scholar you might find copies of the paper which can be accessed without being a registered user at IEEE, Springer; ACM, etc...

This section is previously published as

U. Eklund and C. M. Olsson. “A Case Study of the Architecture Business Cycle for an In-Vehicle Software Architecture”. Proceedings of the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture. Cambridge, UK: IEEE, 2009, pp. 93–100. isbn: 978-1-4244-5295-8.

Abstract

This paper presents the theoretical and practical benefits from a case study using a the 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.

Thesis chapter 4.1: Personal contributions

In the case study in chapter 5 I designed the study, selected the theoretical framework used (Architecture business cycle), chose the architecture scenarios and made the purposeful sample of interviewees. My co-author contributed with choice of the interpretative research approach and the design of the interview process. The interview questions, the interviews and the transcriptions were performed by 3 students as part of their thesis project, which I supervised together with the co-author. The final analysis in the paper was mainly done by me with input from the co-author based on the material of the students.

In the comparative case study in chapter 6 the co-author designed the interview study. We jointly performed the interviews, collected the data, made the analysis and wrote the original conference paper  I made most of the extensions of that paper to the present journal article with input from the co-author.

I performed the mapping study in chapter 7: Defined the search criteria, identified the relevant cases and extracted relevant categories of development approaches and architectures from the chosen papers. Based on the results from the mapping study I defined the initial model of 5 approaches which was iterated with the co-author to the present form.

The model of the context of individual teams in chapter 8 was developed jointly with the co-author. The last four case studies were preformed by by me. The measures were developed in cooperation with engineers at Volvo cars.

The architecture in chapter 9 was developed by me with input from the co-author. The case study was performed by me, but the actual implementation in the case was done by an external team. The evaluation
and comparison of the existing platforms was done by me with input from the co-author.

The five key activities in chapter 10 were elaborated by me based on the theoretical foundation of the co-author. The case study was performed by me, but the actual implementation in the case was done by an external team.

The architectures and the infrastructure in chapter 11 were developed by me with input from the co-author, and was based on a theoretical foundation of the co-author. The case study was performed by me, but the
actual implementation in the case was done by an external team.