31 December 2012
Chapter 2 gives some examples of problems in current R&D approaches, defines goals for an R&D organisation, and defines the research questions investigated further in the thesis.
Chapter 3 outlines the research process, used epistemology, lists the cases studied and discusses issues with doing research as native in the organisation studied.
Chapter 4 outlines all chapters in the thesis and describes my individual contribution in chapters 5 to 11.
Chapters 5 and 6 describe three detailed cases of how architectures 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 various approaches to develop embedded software, and relates them to two different businesses. The model was based on a mapping study to identify what broad approaches to embedded software development are used in industry. The study aimed to better understand, and potentially point at an answer to RQ1. Of special interest was how these approaches relate to used architectural styles, which supports further investigation of RQ1.2.
Chapter 8 aims to facilitate 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. This provides an answer to RQ1.1.
Chapter 9 designs a compositional architecture for embedded software as precursor for open software ecosystems. The study aimed to answer RQ1.2 and detail the architecture-related issues of RQ1.3.
Chapter 10 explores open software ecosystems as possible approach to development of embedded software as an asnwer to RQ1.3. 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. The study aimed to an answer RQ1.2 and RQ1.4.
Chapter 12 summarises the answers to the research questions and design goals in terms of developed artefacts. It also lists the key contributions of the thesis.
30 December 2012
There is also an expectation locally that the research should be relevant for the EESE department where I am employed. Synergy is expected between the industrial project and the conducted research, and at best the research results should be directly beneficial for the company.
Industrial PhD students are often expected to have dual roles and act as neutral or unbiased researchers by the scientific community, and act as practitioners in the area they are researching by the company where they are employed. Furthermore they have a personal goal of pursuing a research education. These factors drives both the focus of the research (e.g. the formulation of research questions) and affects how the research is conducted. It is not impossible to conduct research under these conditions but there are some concerns which are not relevant for a researcher employed by a university or similar. Börjesson is the only other industrial PhD student I have found mentioning the dual roles in her thesis.
The dual roles have been called different things by different authors; ``participant-observer'', ``insider'' (link, link and link) and ``native'', with the last article focuses on ``how complete members may undertake academic research in their own organizations while retaining the choice of remaining a member within a desired career path when the research is completed'', i.e. not going native for the purpose of research but being native before, during and after. But they all consider the role of a researcher being part of the group that is being researched, with the ``insider'' term mostly used in the context of action research. The insider issues relevant for this thesis are mostly related to qualitative research in general and case study research in particular.
I address the issues of the dual roles in this thesis based on four papers (link, link, link, and link). These papers describe some issues which are particular to a industrial PhD student which are not that relevant to a researcher employed by a university or similar institution.
EthicsA researcher funded by the industry may be questioned if there are some ulterior motives to performing the research or of the funding agency have any influence over the results, or what results are published or withheld. Extreme cases could be tobacco industry funding research about the dangers of smoking or oil industries funding research about climate change due to use of fossilised fuels.
The only mentioning of ethics I found specifically for software engineering research is Runeson & Höst , a general overview of science and ethics can be found by Rosenthal. Both of these focus on the ethics towards any persons being studied and not the ethical issue of having questionable motives for performing the research. In this research project the motives from the funding agencies, Volvo Car Corporation and VINNOVA, are clearly stated and it is difficult to imagine any ulterior motives beyond satisfying these goals.
All case studies in table follows the spirit of the Ethical Considerations by Runeson & Höst even if the exact implementation may differ to their examples (Case I was even conducted before the publication of this article).
In all case studies in table the participants were informed about my dual roles as participant and observer, and that my participation would lead to published research, such as this thesis, and to internal reports in respective company. The latter was possibly more sensitive, and perhaps restrained the answers since the interviewees' managers would be in the audience. However I feel that this only had a minor influence. This pre-information also included a brief overview of the research process.
Unfortunately the consent to participate was not written, just verbal (although recorded in some interviews when the equipment was working as planned), contrary to the guidelines by Runeson & Höst, and the pre-information was also only verbal.
The participants were anonymised as much as possible, but in those cases where I deemed it would be possible for another insider to determine who participated in the study they were informed of this prior to their participation.
In cases II, III and V the participants had the opportunity to review the transcribed data as it was captured before it was used or reported outside of the group participating in the study. One interviewee in case V declined to have the interview recorded, but note-taking was ok, which was obliged by me.
It may be more difficult for someone to decline to participate in a case study in a industrial company than in a general social setting, due to the fact that the observer may have management buy-in to perform the study. However my general impression is contrary, all interview participants saw the interviews as an opportunity for retrospection.
Volvo Cars has a process of reviewing articles by industrial PhD students before publishing. My experience is that this process becomes less strict the more experienced the student becomes in writing about sensitive company information.
Observer versus participantTellis defines this issue as ``participant-observation makes the researcher into an active participant in the events being studied''. This is not unique for the industrial PhD student, but it is almost unavoidable. At Volvo cars it is expected since the PhD program targets to ``reinforce a scientific approach within product development'', and PhD students are expected to participate in the activities of the company.
Tellis continues with ``the technique (of participant-observation) provides some unusual opportunities for collecting data, but could face some major problems as well. The researcher could well alter the course of events as part of the group, which may not be helpful to the study''. This is in essence what Yin says where he mentions four major problems for a participating observer:
The first problem is that a participant sometimes must assume roles that could be contrary to good scientific practice. For me as a participant in an engineering company this seem to be a small risk since there is a common view that good engineering is based on science. Therefore the claim that I am doing research is usually a valid rationale for a certain role or behaviour.
The second is that the observer may become a supporter of the unit or group studied. If this is a real concern for an industrial PhD student then there is a real problem with such a role doing research since it is expected of the PhD student to be a supporter of his or her company. I also don't think the rest of the scientific community would expect otherwise if it clearly stated when presenting the research as being made by an insider.
Third, the balance between participating and observing may be skewed. This is a real concern for both me and other PhD colleagues I have spoken to at my company.
I have not found any recipes to mitigate this risk, and have tried to judiciously balance this during the project.
The fourth problem Yin mentions is if the studied organisation is ``physically dispersed'', then it may be ``difficult to be at the right pace at the right time; either to participate in or to observe important events''. The last problem is not unique to researchers with dual roles, but is relevant for anybody doing observations. In such a large organisation as Volvo Cars it is impossible to always be ``at the right place at the right time'', but at least all in-house development is done at a single site, Torslanda, Göteborg, Sweden.
Brannick & Coghlan have a more multifaceted view of doing research as a native. They for example state that native researchers have automatic primary access, while secondary access to documents or people may be harder for a native researcher since the organisation may not distinguish between the roles of a researcher and a practitioner, with the practitioner having free access to certain information while still being restricted to other information on a need-to-know principle. I have not experienced this as a problem at all at Volvo Cars.
Brannick & Coghlan continue to discuss the preunderstanding that a native researcher may put him ``too close'' to the data, but concludes that the research challenges "do not invalidate any of the outlined research traditions" (Their article mentions positivism, interpretative/hermeneutic and critical realism/action research). I assume that ``too close'' means not being able to evaluate the data objectively, which may be risk also in this thesis.
BenefitsThere are a number of benefits of being a industrial PhD student as well. Without much elaboration some benefits I have experienced are:
- Access - The industrial PhD student is by almost default an ``insider'', especially if he is already is working at the company before starting his studies, so primary access is granted by default.
- Interpretation - The industrial PhD student has a superior possibility to use an interpretative approach to qualitative research.
- Acceptance - Research results may have a better chance of being seen as ``true'' since the results are coming from one of their own. This is not the same as researcher suggestions are more acceptable to implement, but the argument that the researcher does not ``understand'' issues specific to the organisation is absent.
29 December 2012
Qualitative research can be performed in many traditions, Walsham mentions three types of epistomologies: Positivism, Interpretative (or Non-positivism) and Normativism. This thesis uses the interpretative approach when collecting and analysing data for three reasons: First, I prioritised insight into the cases over reliability for other researchers to reproduce the studies. Second, I judged it impossible to disregard any pre-conceptions I had based on more than ten years of of professional experience of designing and developing software-intensive embedded systems. Third, most of the descriptions of the case studies are based on interview data which already are the interviewees' interpretation of the actual events/facts/situations/...
|Case||Company||Description||Data sources||Author role||Chapter(s)|
|I||VCC||Forces shaping the distributed in-vehicle EE architecture in P2 platform||Interviews with 20 developers + design documents||Insider observer||5, 7, 10|
|II||VCC||Comparative case study on architecting process on existing platforms||Interviews with 6 architects + design documents + personal notes||Insider observer||6, 7, 10|
|III||Scania||Comparative case study on architecting process on existing platforms||Interviews with 5 architects + design documents + personal notes||Observer||6|
|IV||VCC||Case study on architecture decisions for new platform||Observed decisions during 3 months||Participant / insider observer|
|V||VCC||Post mortem analysis of Sensus infotainment development||Interviews with 6 key developers + design documents||Insider observer||7, 10|
|VI||VCC||Proof-of-concept development of android-based infotainment system||All project & design documents of both product owner and Scrum team + personal notes||Participant / insider observer||9, 10, 11|
|VII||VCC||Agile development of climate control software||Official meeting notes and presentations + personal notes||Insider observer||7, 10|
|VIII||VCC||Agile development of next generation infotainment system||Official meeting notes and presentations + personal notes||Insider observer||10|
The selection of interviewees were in cases I, II, III and V done as purposive samples in order to cover a comprehensive variety of roles and teams at the studied organisations.
* A case study being ``an empirical study that investigates a contemporary phenomena in depth and within its real-life context, especially when the boundaries between the phenomenon and the context are not clearly evident''
28 December 2012
The design process was scoped by the four stages of the DRM, seen in figure below, although the actual artefacts were developed in a nonlinear fashion. All four stages contributed to new learning, which is included in the respective chapters of the thesis.
|The four stages of the Design Research Methodology by Blessing|
CriteriaThe first stage in the design process defined the overall context, research questions and design goals based on cases~I-V in together with selected problems form published literature, described in detail in chapter 2. Chapters 5 and 6 provides a rich insight into the industrial context of mass-produced embedded systems.
Descriptive Study IThe second stage investigated existing literature to further understand the problems, elaborated on evaluation criteria and guided to possible solutions, this is described in chapter 7. The aim of this investigation is to answer RQ1 and guide towards answers of answer RQ1.1 and RQ1.2.
Prescriptive StudyThe third stage, the Prescriptive Study, investigated specific artefacts related to RQ1.1, RQ1.2, RQ1.3 and RQ1.4.
This resulted in a set of artefacts to achieve the goals and alleviate problems identified in the previous two stages. The artefacts fall into several categories of ways-of-working, model and architectures:
- Chapter 7 describes a model of how individual teams interact with large projects, and based on this a method to facilitate a transition to agile development for individual teams.
- Chapters 9 and 11 describe two architectures, for compositional architectures and embedded architecture for innovation experiment systems respectively.
- Chapter 10 describes 5 activities to establish an open software ecosystem for MPES.
Descriptive Study IIThe fourth stage evaluated the resulting artefacts, methods and ways-of-working in cases VI-VIII from the previous stage (also the focus of chapters 7, 9, 10 and 11).
LimitationsThe artefacts were evaluated mainly through observational, analytical and descriptive methods as categorised by Hevner et al:
- Observation through case studies
- Architectural analysis of designed artefacts
- Informed argument based on insider knowledge to show the artefact's utility
- Scenarios describing the use of the artefact in the context
The DRM process assumes an iteration of the last two phases to optimise the design of the artefacts against the design goals, in this project only one cycle was performed.
The set of artefacts is not sufficient for an organisation to evolve its R&D process, in practice there are numerous other factors affecting the efficiency of an R&D process at an OEM. Factors from almost every area of research, ranging from management theory via economics to semiconductor technology. The set of artefacts developed is thus shown to mitigate the investigated problems, but not necessarily solve them, at least not on their own.
27 December 2012
This thesis is in essence a design project; developing artefacts, processes and methods to create opportunities for business for embedded software in mass-produced systems in general, and automotive software in particular. Therefore design research was chosen as the research methodology.
26 December 2012
RQ1: What are the archetypical approaches for software development in the embedded domain?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.
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 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?
25 December 2012
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:
- Minimise leadtime from idea to implementation of new software features.
- The ability to frequently deliver new software features to end customers
- Decoupling of software development from hardware and mechanical development, both in time and by the design dependencies
24 December 2012
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.
23 December 2012
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.
22 December 2012
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.
21 December 2012
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.
|Software in Mbytes downloaded in a vehicle at production at VCC over the years.|
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
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.
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.
20 December 2012
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.Another example scenario would be
He got Spotify, but I didn't.
Do I feel ``cheated''?
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.
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.