tag:blogger.com,1999:blog-56440533434157812702024-02-19T08:19:43.309+01:00Managing Automotive Software ArchitecturesA blog related to my research about software architecture and the applications for the automotive industry.<br>
I am doing my PhD in the Software Engineering Division at <a href="http://www.chalmers.se/cse/EN/">the department of Computer Science & Engineering at Chalmers University of Technology</a> in Sweden, while still being employed by <a href="http://www.volvocars.com">Volvo Car Corporation</a>.<br>
<br>
<i>Ulrik Eklund</i>Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.comBlogger205125tag:blogger.com,1999:blog-5644053343415781270.post-5650508050749012232013-03-29T10:28:00.000+01:002013-03-30T10:29:29.554+01:00PhD defence passedThe thesis defence went well and I passed all requirements for a <a href="http://www.chalmers.se/cse/EN/education/graduate-education">PhD in computer science & engineering</a>.<br />
Th final report of the research project will be sent to <a href="http://www.vinnova.se/en/ffi/FFI---Fordonsutveckling/">VINNOVA </a>on 30 April, with parts of it published in this blog. After that I will close this blog for further updates.<br />
<br />
I will probably continue blogging after that in a new blog about software R&D and technology transformation in the embedded world, but with less focus on the automotive industry.<br />
<br />
<div style="text-align: right;">
<i>Ulrik </i></div>
Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com3tag:blogger.com,1999:blog-5644053343415781270.post-76185873066828665932013-03-28T10:00:00.000+01:002013-03-28T10:00:09.196+01:00PhD presentation material<a href="http://prezi.com/fpximdqvys_c/phd-presentation/?kw=view-fpximdqvys_c&rc=ref-34772651">Prezi presentation of my research</a><br />
<br />
<a href="https://docs.google.com/document/d/1qRKnT3a5V8r4IWYeWwHuH7B3l1k2izAd09CzirblcRI/edit?usp=sharing">Errata sheet for the printed thesis</a>Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com2tag:blogger.com,1999:blog-5644053343415781270.post-67097258894709903322013-03-05T09:47:00.000+01:002013-03-05T09:47:34.125+01:00Public thesis defence<div style="text-align: center;">
Engineering software for mass-produced embedded systems</div>
<div style="text-align: center;">
Ways-of-working, architecture and ecosystems for innovation</div>
<div style="text-align: center;">
</div>
<div style="text-align: center;">
ULRIK EKLUND</div>
<div style="text-align: center;">
</div>
<div style="text-align: center;">
Thesis to be defended in public on 28 march 10:00 at </div>
<div style="text-align: center;">
Room EA, Hörsalsvägen 11, Chalmers, Göteborg </div>
<div style="text-align: center;">
for the Degree of Doctor of Philosophy.
</div>
<div style="text-align: center;">
</div>
<div style="text-align: center;">
The thesis will be defended in English</div>
<div style="text-align: center;">
The faculty opponent: Prof. Pasi Tyrväinen, University of Jyväskylä, Finland.</div>
<div style="text-align: center;">
</div>
<div style="text-align: center;">
<a href="http://publications.lib.chalmers.se/publication/173642">http://publications.lib.chalmers.se/publication/173642</a></div>
<div style="text-align: center;">
</div>
<div style="text-align: center;">
Department of Computer Science and Engineering</div>
<div style="text-align: center;">
CHALMERS UNIVERSITY OF TECHNOLOGY and UNIVERSITY OF GOTHENBURG<br />CHALMERS TEKNISKA HÖGSKOLA och GÖTEBORGS UNIVERSITET<br />SE-412 96 Göteborg, Sweden<br />Phone 031-772 1000</div>
Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-20277335275001040252013-01-31T10:29:00.000+01:002013-03-30T10:31:57.330+01:00Future 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.<br />
<ul>
<li><a href="http://www.oliverwyman.com/pdf_files/CarInnovation2015_engl.pdf">A comprehensive study on innovation in the automotive industry.</a> Note that the report is from 2007 and much of what they predict to 2015 is still far away... </li>
<li><a href="http://www.forbes.com/sites/joannmuller/2012/12/24/think-how-much-smarter-your-car-will-be-in-a-few-years/">Think How Much Smarter Your Car Will Be In A Few Years</a>. Some insight into cutting edge car technology.</li>
</ul>
Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-84717722497294767902013-01-19T09:00:00.000+01:002013-01-19T09:00:04.579+01:00Thesis chapter 12.3: Future workSuggestions for future work are:<br />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.<br />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.<br />More studies with industrial validation of innovation experiment systems for embedded systems are needed.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com3tag:blogger.com,1999:blog-5644053343415781270.post-44793138262652859142013-01-18T09:00:00.000+01:002013-01-18T09:00:08.944+01:00Thesis chapter 12.2: Summary of contributionsThe thesis provides the following contributions:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
The artefacts developed above are all tried and evaluated in an industrial context, i.e. in a “real” project setting with professional practitioners.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com4tag:blogger.com,1999:blog-5644053343415781270.post-23331847998752846712013-01-17T09:00:00.000+01:002013-01-17T09:00:01.069+01:00Thesis 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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-87936497404634621422013-01-16T09:00:00.000+01:002013-01-16T09:00:20.818+01:00Thesis chapter 12.1.6: Design goalsThe 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.<br /><br />
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.<br />
<br />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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-65295934639152930672013-01-15T09:00:00.000+01:002013-01-15T09:00:01.246+01:00Thesis chapter 12.1.5: Research answer 1.4Since 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<br />an innovation experiment system (IES) would utilise feedback from real users of the embedded products in a scale comparable to the entire customer base.<br />
The notion of continuous innovation is not new, but the concept is novel in the embedded domain.<br />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.<br />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<br />collecting data from 7 users.<br />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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-87260922832739745092013-01-14T09:00:00.000+01:002013-01-14T09:00:01.378+01:00Thesis chapter 12.1.4: Research answer 1.3Chapter 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:<br />
<ol>
<li>Choose the ecosystem type</li>
<li>Open up the platform</li>
<li>Establish OEM as keystone organisation</li>
<li>Establish business opportunities for developers</li>
<li>Establish infrastructure for continuous deployment of software</li>
</ol>
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com3tag:blogger.com,1999:blog-5644053343415781270.post-64666542845696483842013-01-13T09:00:00.000+01:002013-01-13T09:00:03.740+01:00Thesis chapter 12.1.3: Research answer 1.2Chapter 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:<br />
<ul>
<li><b>Composability: </b>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.</li>
<li><b>Deployability: </b>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.</li>
<li><b>Maintainability:</b> 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.</li>
<li><b>Configurability:</b> The platform must support variability in the hardware configuration of sensors and actuators since individual products can vary within the product family.</li>
</ul>
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:<br />
<ul>
<li><b>Consistent User Interface:</b> 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.).</li>
<li><b>Dependability:</b> 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.</li>
</ul>
A reference architecture was designed to enable the qualities above, consisting of 20 architectural decisions together with 4 architecture patterns for:<br />
<ul>
<li>Device abstraction</li>
<li>Data and service provision</li>
<li>Device and information composition</li>
<li>Safety-critical, certified and open application access</li>
</ul>
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.<br />
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-47125085495808118402013-01-12T09:00:00.000+01:002013-01-12T09:00:12.253+01:00Thesis chapter 12.1.2: Research answer 1.1RQ1.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.<br />
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.<br />
<ul>
<li><b>Requirements </b>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.</li>
<li><b>Project gates</b> 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.</li>
<li><b>Validation </b>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.</li>
<li><b>Software delivery</b> 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.</li>
<li><b>Internal practices</b> 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.</li>
</ul>
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-39862802136736120342013-01-11T09:00:00.000+01:002013-01-11T09:00:15.266+01:00Thesis chapter 12.1.1: Research answer 1RQ1 is answered in chapter 7. Based on a mapping survey 5 archetypical approaches of embedded software development were identified:<br />
<ul>
<li><b>Approach E: Rorqual organisations</b> 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.</li>
<li><b>Approach D: Autonomous Teams</b> 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.</li>
<li><b>Approach C: Adaptive processes</b> 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.</li>
<li><b>Approach B: Architecture for composition</b> 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.</li>
<li><b>Approach A: Marlin Organisations</b> 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.</li>
</ul>
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.<br />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.<br />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.<br />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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-44653677536608349092013-01-10T09:00:00.000+01:002013-01-10T09:00:12.547+01:00Thesis chapter 12.1: Research and design goalsThe thesis project identified three goals for an original equipment manufacturer aspiring to be world leading in software development:<br />
<ul>
<li><b>G1:</b> Minimise leadtime from idea to delivery of new software features.</li>
<li><b>G2:</b> The ability to frequently deliver new software features to end customers</li>
<li><b>G3:</b> Decoupling of software development from hardware and mechanical development, both in time and by the design dependencies</li>
</ul>
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:<br />
<ul>
<li><b>RQ1: </b>What are the archetypical approaches for software development in the embedded domain?</li>
<li><b>RQ1.1:</b> What ways-of-working in an R&D organisation for mass-produced embedded systems can create new options for business?</li>
<li><b>RQ1.2:</b> What are the key properties of architectures for mass-produced embedded systems to create business options?</li>
<li><b>RQ1.3:</b> How can an OEM evolve the R&D process to support a transition from a closed to an open software ecosystem?</li>
<li><b>RQ1.4:</b> How can an embedded architecture support innovation and delivery of new features of value to the customer?</li>
</ul>
Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-45483490062892821512013-01-09T09:00:00.000+01:002013-01-09T09:00:04.090+01:00Thesis chapter 12: ConclusionsThis 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<br />embedded systems, while at the same time mitigate some of the problem presentably common in the domain.<br />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):<br />
<ul>
<li>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.</li>
<li>Chapter 7 identifies and models 5 approaches to develop embedded software, based on a mapping study of 23 papers.</li>
<li>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.</li>
<li>Chapter 9 designs a compositional architecture for embedded software as precursor for open software ecosystems.</li>
<li>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.</li>
<li>Chapter 11 describes innovation experiment systems for embedded products and defines a reference architecture supporting such an R&D approach.</li>
</ul>
Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-9427429012221467942013-01-08T09:00:00.000+01:002013-01-08T09:00:11.128+01:00Thesis chapter 11: Architecture for Large-Scale Innovation Experiment Systems<br />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.<br />A shorter version of this chapter is previously published as<br />
<blockquote class="tr_bq">
<a href="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6337728&isnumber=6337707">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.</a></blockquote>
<h3>
Abstract</h3>
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.<br />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.<br />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 whereUlrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-28925758403923668532013-01-07T09:00:00.000+01:002013-01-07T09:00:01.174+01:00Thesis chapter 10: Introducing open software ecosystems for embedded systemsThis 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.<br />A shorter version of this chapter is previously published as<br />
<blockquote class="tr_bq">
<a href="http://dx.doi.org/10.1007/978-3-642-30746-1_20">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.</a></blockquote>
<h3>
Abstract</h3>
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-15930947182871267062013-01-06T09:00:00.000+01:002013-01-06T09:00:08.786+01:00Thesis chapter 9: Compositional architecture for embedded platformsThis 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.<br />
This chapter was submitted as an article to <a href="http://www.journals.elsevier.com/journal-of-systems-and-software/">Journal of Systems and Software</a> in 2012.<br />
<h3>
Abstract</h3>
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.<br />
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.<br />
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.<br />
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-76871121336802004042013-01-05T09:00:00.000+01:002013-01-05T09:00:10.067+01:00Thesis chapter 8: Applying Agile Development in Embedded SystemsMost 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<br />chapter 7, with the aim to facilitate agile development for individual teams in the context of large MPES projects.<br />The chapter is previously published as<br />
<blockquote class="tr_bq">
<a href="http://www.springerlink.com/content/%20n90815g481713091/">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.</a></blockquote>
<h3>
Abstract</h3>
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.<br />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.<br />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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-19255528868779286912013-01-04T09:00:00.000+01:002013-01-04T09:00:02.252+01:00Thesis chapter 7: Fast software development and slow embedded projectsThis chapter identifies and models <a href="http://www.brainyquote.com/quotes/quotes/g/georgespa130444.html">various approaches</a> to develop embedded software, and relates them to two different business models.<br />This chapter was submitted as an article to <a href="http://onlinelibrary.wiley.com/journal/10.1002/%28ISSN%292047-7481">Journal of Software: Evolution and Process</a> in 2012.<br />
<h3>
Abstract</h3>
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.<br />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.<br />The model was evaluated and elucidated by three empirical cases from a Swedish company.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-78128072869495650012013-01-03T09:00:00.000+01:002013-01-03T10:51:26.756+01:00Thesis chapter 6: Architecting automotive product lines: Industrial practiceThis chapter is previously published as<br />
<blockquote class="tr_bq">
<a href="http://dx.doi.org/10.1016/j.scico.2012.06.008">U. Eklund and H. Gustavsson. Architecting Automotive Product Lines: Industrial Practice. Science of Computer Programming (2012). doi: 10.1016/j.scico.2012.06.008</a></blockquote>
<h3>
Abstract</h3>
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-41059379425133428882013-01-02T09:00:00.000+01:002013-01-03T10:53:06.214+01:00Thesis chapter 5: The architecture business cycle for an in-vehicle software architecture<i>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 <a href="http://scholar.google.com/">Google scholar</a> you might find copies of the paper which can be accessed without being a registered user at IEEE, Springer; ACM, etc...</i><br />
<br />
This section is previously published as<br />
<blockquote class="tr_bq">
<a href="http://ieeexplore.ieee.org.proxy.lib.chalmers.se/stamp/stamp.jsp?tp=&arnumber=5290795&isnumber=5290660">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.</a></blockquote>
<h3>
Abstract</h3>
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.<br />
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-76495682521668498952013-01-01T09:00:00.000+01:002013-01-01T09:00:13.676+01:00Thesis chapter 4.1: Personal contributionsIn 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.<br />
<br />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.<br />
<br />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.<br />
<br />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.<br />
<br />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<br />and comparison of the existing platforms was done by me with input from the co-author.<br />
<br />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.<br /><br />
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<br />actual implementation in the case was done by an external team.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0tag:blogger.com,1999:blog-5644053343415781270.post-78528633833924071882012-12-31T09:00:00.000+01:002012-12-31T10:38:52.395+01:00Thesis chapter 4: Structure of the thesis<a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter1-software-in-mass.html">Chapter 1</a> gives a general introduction to mass-produced embedded systems and what characterises them.<br />
<a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-2-research-motivation.html">Chapter 2</a> 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.<br />
<a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-3-research-design-and.html">Chapter 3</a> outlines the research process, used epistemology, lists the cases studied and discusses issues with doing research as native in the organisation studied.<br />
Chapter 4 outlines all chapters in the thesis and describes my individual contribution in chapters 5 to 11.<br />
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.<br />
Chapter 7 identifies and models various approaches to develop embedded software, and relates them to two different businesses. The model was based on a <a href="http://www.dur.ac.uk/ebse/guidelines.php">mapping study</a> 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 <a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-26-research-questions.html">RQ1</a>. Of special interest was how these approaches relate to used architectural styles, which supports further investigation of <a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-26-research-questions.html">RQ1.2</a>.<br />
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 <a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-26-research-questions.html">RQ1.1</a>.<br />
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 <a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-26-research-questions.html">RQ1.3</a>.<br />
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.<br />
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 <a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-26-research-questions.html">RQ1.2</a> and <a href="http://automotive-sw-architecture.blogspot.se/2012/12/thesis-chapter-26-research-questions.html">RQ1.4</a>.<br />
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.Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com1tag:blogger.com,1999:blog-5644053343415781270.post-34911786382757655722012-12-30T09:00:00.000+01:002012-12-30T09:00:09.379+01:00Thesis chapter 3.3: Insider issuesI was a PhD student in Software Engineering while being employed by large company, Volvo Car Corporation, where I have worked for 9 years prior to the start of the PhD education. The company has a program for about 25 PhD students in various areas. The agreement between the company and the university states that 80% of my full-time employment should be spent towards obtaining a PhD while 20\% of my time still working in industrial projects.<br />
<br />
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.<br />
<br />
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. <a href="http://books.google.se/books/about/Making_Software_Process_Improvement_Happ.html?id=gG2DNAAACAAJ&redir_esc=y">Börjesson </a>is the only other industrial PhD student I have found mentioning the dual roles in her thesis.<br />
<br />
The dual roles have been called different things by different authors; `<a href="http://books.google.se/books/about/Case_Study_Research.html?hl=sv&id=BWea_9ZGQMwC">`participant-observer</a>'', ``insider'' (<a href="http://csde.washington.edu/~scurran/files/readings/590QM/Week%202/Bartunek%20Article.pdf">link</a>, <a href="http://orm.sagepub.com/cgi/content/abstract/10/1/59">link </a>and <a href="http://www.google.com/books?id=e6sLW0prjpYC&lpg=PA117&ots=bGRM2vheEQ&lr=&hl=sv&pg=PP1#v=onepage&q=&f=false">link</a>) and ``<a href="http://orm.sagepub.com/cgi/content/abstract/10/1/59">native</a>'', 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 <i>going </i>native for the purpose of research but <i>being</i> 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.<br />
<br />
I address the issues of the dual roles in this thesis based on four papers (<a href="http://books.google.se/books/about/Making_Software_Process_Improvement_Happ.html?id=gG2DNAAACAAJ&redir_esc=y">link</a>, <a href="http://www.viktoria.se/nulden/Publ/PDF/IP-1012L.pdf">link</a>, <a href="http://www.springerlink.com/content/t22r8l65q7h31636/">link</a>, and <a href="http://books.google.se/books/about/Case_Study_Research.html?hl=sv&id=BWea_9ZGQMwC">link</a>). 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.<br />
<h3>
Ethics</h3>
A 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.<br />
<br />
The only mentioning of ethics I found specifically for software engineering research is <a href="http://www.springerlink.com/content/t22r8l65q7h31636/">Runeson & Höst</a> , a general overview of science and ethics can be found by <a href="http://pss.sagepub.com/content/5/3/127.short">Rosenthal</a>. 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 <a href="http://www.vinnova.se/en/FFI---Strategic-Vehicle-Research-and-Innovation/Vehicle-Development/">VINNOVA</a>, are clearly stated and it is difficult to imagine any ulterior motives beyond satisfying these goals.<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<h3>
Observer versus participant</h3>
<a href="http://www.nova.edu/ssss/QR/QR3-2/tellis1.html">Tellis </a>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.<br />
<br />
<a href="http://www.nova.edu/ssss/QR/QR3-2/tellis1.html">Tellis</a> 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 <a href="http://books.google.se/books/about/Case_Study_Research.html?hl=sv&id=BWea_9ZGQMwC">Yin </a>says where he mentions four major problems for a participating observer:<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
I have not found any recipes to mitigate this risk, and have tried to judiciously balance this during the project. <br />
<br />
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.<br />
<br />
<a href="http://orm.sagepub.com/cgi/content/abstract/10/1/59">Brannick & Coghlan</a> 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.<br />
<br />
<a href="http://orm.sagepub.com/cgi/content/abstract/10/1/59">Brannick & Coghlan</a> 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.<br />
<h3>
Benefits</h3>
There are a number of benefits of being a industrial PhD student as well. Without much elaboration some benefits I have experienced are:<br />
<ul>
<li>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.</li>
<li>Interpretation - The industrial PhD student has a superior possibility to use an interpretative approach to qualitative research.</li>
<li>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 <a href="http://bible.cc/luke/4-24.htm">more acceptable to implement</a>, but the argument that the researcher does not ``understand'' issues specific to the organisation is absent.</li>
</ul>
Ulrikhttp://www.blogger.com/profile/15831528373591728862noreply@blogger.com0