Eternal Embedded Software: Towards Innovation Experiment Systems

Eternal Embedded Software: Towards Innovation Experiment Systems Jan Bosch and Ulrik Eklund Chalmers University of Technology Software Engineering Division, Dept. Computer Science & Engineering Göteborg, Sweden [email protected]

Abstract. The paper discusses the concept of innovation experiment systems in the context of long-lived embedded systems. These systems need to evolve continuously to stay competitive and provide value to the customer and end-user, especially in domains where the pace of change is increasing. Innovation experiment systems provide a natural mechanism that allows an embedded system, its architecture and underlying platform to continuously evolve in response to changes in the user requirements and system context. It uses a rapid feedback loop to evaluate the benefits of small variations to users with the intent of continuous improvements. The paper explores the architectural implications as the ability to continuously evolve and conduct experiences in the deployed product context in a safe and controlled manner must be supported by the architecture of the embedded systems. Finally, the paper illustrates these concepts using a case study concerning an infotainment system in the automotive industry. Keywords: innovation experiment system, embedded systems, software architecture, automotive software.

1

Introduction

Software has made an amazing journey since its first introduction in the middle of the 20th century. Initially considered as a handy configuration mechanism for electronic systems, it has managed to increasingly become the core of virtually any modern system supporting individuals, companies and entire societies. With the constantly expanding role of software, the lifespan of software systems has extended as well with examples existing where the lifespan of the software is longer than the entire working career of the software developers that initially developed it. This trend occurs not only in the area of information systems, but is starting to become a key challenge for embedded software as well. For the purpose in this paper, there are two main categories of “eternal” embedded software: The first is infrastructure software, which is completely pervasive today, where the deployment of new systems requires huge investment or effort and therefore T. Margaria and B. Steffen (Eds.): ISoLA 2012, Part I, LNCS 7609, pp. 19–31, 2012. c Springer-Verlag Berlin Heidelberg 2012 

20

J. Bosch and U. Eklund

occurs very seldom. Examples could be traffic lights in a city, railway signaling, public transport automated ticket systems etc. This category increases since previously “unconnected” systems are becoming software dependent, such as carto-car and car-to-infrastructure communication. The second is mass-produced embedded systems, where some domains overlap the first category. Even in the world of fast moving electronics the software platform lives significantly longer than the manufacturing of any individual product, including the microprocessor the software runs on. The extreme example here would be cars, where a single car model could be manufactured for seven years, longer than any CPU, and would have requirements of spare parts availability up to twenty years after the manufacturing has stopped. In many cases the underlying software platform providing end-user functionality evolves beyond the initial purpose, but the services of the platform also reuse existing software from previous product generations. These kind of systems need to evolve continuously to stay competitive and provide value to the customer and end-user, especially in domains where the pace of change is ever increasing. Whereas earlier this was achieved by period, e.g. yearly, new releases of software, we recognize a trend where continuous testing of new, innovative functionality in deployed systems is increasingly applied in especially on-line, software-as-a-service (SaaS) systems. In our research, however, we have studied this phenomenon and realized that this can be applied to embedded systems as well and, in fact, allows for significant improvements in the rate of innovation and the ability of systems to adjust to their continuously evolving environment. We refer to this trend as innovation experiment systems (IES) [1]. Common for SaaS software and software in connected embedded systems is that allows for an approach where instead of freezing the requirements before starting product development, the requirements constantly evolve and also affect already deployed systems that are actively used by customers. Consequently, requirements evolve in real-time based on data collected from systems in actual use with customers instead of being frozen early based on the opinions of product management about the likely customer needs 12, 18 or 24 months from now. The contribution of the paper is a discussion of the concept of innovation experiment systems in the context long-lived embedded systems. In addition, it explores the architectural implications as the ability to continuously evolve and conduct experiences in the actual real setting in a safe and controlled manner must be supported by the architecture of the embedded systems. Finally, it illustrates these concepts using a case study concerning an infotainment system in the automotive industry. The remainder of the paper is organized as follows. In the next section, we discuss contemporary and future embedded systems. Subsequently, we introduce the concept of innovation experiment systems in more detail. This is followed by a discussion of the application of innovation experiment systems in the embedded systems domain. Then, we present a case study that illustrates the discussed concepts in the context of the automotive domain. Finally, we conclude with a

Eternal Embedded Software: Towards Innovation Experiment Systems

21

discussion of the relation between innovation experiment systems and “eternal” embedded software and an outline of future work.

2

Characteristics of Current and Future Embedded Systems

It is difficult to identify a single perspective on software development among original equipment manufacturers (OEM) of products with embedded software. The view ranges from focusing on efficient manufacturing of products with the software as difficult necessity to seeing software as a key business differentiator. Software is often an enabler for new innovation in embedded systems, for example in cars [2], and marketed innovative features are often realized by software. One indicator for this is the amount of software is increasing exponentially over time in many embedded domains [4]. A common development approach for embedded systems is using a traditional stage-gate process, where the gates are driven by decisions on investment in the manufacturing of the product, i.e. driven by the hardware, towards a new periodical release. The finalization of software artifacts often correspond to process gate progression, e.g. user requirements, system requirements, software architecture, component requirements, and software implementation, i.e. a waterfall process even if the artifacts are updated as the project progresses. We define the domain of mass-produced software-intensive embedded systems by four characteristics: – Deep integration between hardware and software for significant parts of the functionality – Strong focus on manufacturing aspects of the product in the development (e.g. by development process gates) – Strong supplier involvement in the form of subcontractors – Some elements of the system realize safety-critical functionality Examples of mass-produced embedded products include cars and trucks, washing machines and other home utensils, sewing machines, printers and copying machines [4]. We will give some examples from the automotive industry since cars are arguably the most complex product of this category, both in terms of conflicting requirements and longevity of the platform in production. Over the last years, cloud computing and SaaS solutions are rapidly becoming the norm and enjoy enormously rapid growth. The key reasons for this include the lower cost for the customer, the simplicity associated with not having to own hardware and the freedom from long-term constraints associated with most licensed software solutions. Interestingly, these benefits extend in part also to software-intensive embedded systems and increasingly companies building connected embedded systems, from mobile phones to cars, are starting to exploit the advantages of frequent, post-deployment updating of software and the collection of usage and other performance data from systems in the field.

22

3

J. Bosch and U. Eklund

Concept of Innovation Experiment Systems

Innovation is lifeblood of any organization, but notoriously hard to get right in many companies. Innovation in large organization is often characterized by an enormous imbalance between the number of ideas that, informally or formally, exist in the organization and the number of concepts that are in fact tested with customers. The ratio, depending on the attention the organization puts towards idea generation by its employees, can range from one in a hundred to one in thousands. With that strict selection process and the high cost associated with testing, the importance of selecting the most promising ideas, turning these into concepts and then designing a (prototype) product to test the concept with customers becomes such that it receives significant attention by senior management and many other functions and layers in the organization. The selection process is, unavoidably, driven by the earlier experiences and beliefs of the people in the selection process. In most organizations, it is the opinions of the more senior persons in the organization that tend to weigh the heaviest. The challenge with this approach is threefold. First, opinions are a very poor substitute for real customer data and the innovation literature has many examples of successful innovations that were resisted for years inside the organization before made successful by a small “skunk works” team working under the radar. Second, even if the organization is sufficiently open minded to explore more innovative ideas and concepts, there is a natural risk avoidance that causes organizations to settle on the safe bets. Human psychology, as has been studied extensively in behavioral economics, experiences a loss much more strongly than it experiences a win, causing a selection process where losses are as much as possible avoided, resulting in mundane innovations. Finally, the demands on the system from its users as well as the overall context in which it operates evolve constantly and this requires continuous validation and experimentation to determine in which direction the system needs to evolve. The solution is, obviously, to find ways to decrease the dependence on opinions and to increase reliance on real customer or other data. Traditional metrics such as the Net Promoter Score [8] have been used for the last decade or more, but often fail to provide timely feedback during the development process as these are backward looking and focus on the entire product. To collect customer or performance data early in the innovation process, the organization needs to find mechanisms to test more ideas and concepts with customers and in the installed base in real-time and obviously at a much lower cost than earlier. This requires new behaviors at the business level, i.e. involving customers in feature and product concept validation without an, initially clear, business model. Also, it requires changes to the R&D processes as customers need to be involved much earlier and deeper in the R&D process. Finally, this requires changes to the architecture of the products and platforms to facilitate testing versions of screens, components, subsystems and entire products in order to determine customer preference and interest. The mechanisms used for achieving customer involvement and the efficient execution of experiments on the deployed product base depend heavily on the type of experiments, system, stage and purpose.

Eternal Embedded Software: Towards Innovation Experiment Systems

23

Connected, software-intensive embedded systems offer a particularly wellsuited context for building an innovation experiment system. Connected systems allow for the rapid and low-cost deployment of new functionality. In addition, the collection of customer feedback as well as usage and other performance metrics is simple and the connection to business goals is virtually real-time. In Figure 1, we present the concept of innovation experiment systems in R&D graphically. The loop between deploying new functionality, measuring usage and other performance metrics and subsequently using the collected data to drive development is the main process. The goal of an innovative product is to maximize the number of iterations that can be executed per time unit, e.g. per quarter. The rationale is that the faster the organization learns about the customer and the real world operation of the system, the more value it will provide and consequently the more successful it will be compared to its competitors.

  


 

  
  

     



 
 
  

Fig. 1. Overview of the Innovation Experiment System with the iteration of experiments

When embedded systems are network connected and the development teams have adapted to rapid development and deployment i short cycles, allows the manufacturers to have the ability to conduct innovation experiments with the deployed embedded systems on a scale comparable to the full customer base. A perhaps less obvious but very important advantage of connected products is that the cost of collecting active and passive information from and about the customer is much lower. Active customer feedback is concerned with surveys and other mechanisms where the customer is aware that he or she is providing feedback. Passive feedback and usage data is collected while the customer is using the system. Examples include the amount of time a user spends using a feature, the relative frequency of feature selections, the path that the user takes through the product functionality, etc. The low cost and ease of data collection leads to the next major difference between IES-based and traditional software. In connected, embedded systems, in addition to usage data, several kinds of other performance data can be collected. For example, connected cars can collect fuel consumption data whereas telecom equipment can collect real-time bandwidth data. In many systems, this data is already collected for operational management purposes, but hardly used in evolution of already deployed systems.

24

J. Bosch and U. Eklund

An automotive OEM gains a significant competitive advantage from building products as innovation experiment systems compared to present practices of customer clinics and consumer surveys1 ; with the former being labor-intensive even for a very small sample size and the latter has a very long cycle time from development to survey results. The second advantage is for the customers, who continuously will get a vehicle with new or improved features, and a better retained second-hand value when selling to the 2nd and 3rd customers. Due to the approach that companies like Google have taking concerning “perpetual beta”, customers expect a continuous evolution of product functionality. Customers are becoming increasingly accustomed to frequent, trouble-free updates that provide relevant additional value and consequently this is increasingly an expectation also for traditional embedded products.

4

Applying Innovation Experiment Systems to Modern/Future Embedded Systems

4.1

Overall Implications on R&D Process

Innovative ideas for embedded products are typically collected and prioritized during the roadmapping and requirement management process as part of the yearly release cycle, which usually is determined by manufacturing concerns of the hardware. Feedbacks on innovations from real customers are collected only on new product models, if collected at all. For a car there is a long innovation cycle for the mechanical parts, involving heavy investment in the manufacturing plants, typically 7-10 years. The electronics have a much shorter innovation cycle owing to the life-cycle of semiconductors, typically 1-3 years. Oddly enough the cycle of software is longer than for electronics, with a common feature being updated maybe once as a mid-cycle action on a car model. Since more and more embedded products also are connected [5], it is conceivable to develop, deploy and measure usage on new software in iterations which length is 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 would utilize feedback from real customers in a scale comparable to the entire customer base and would require a product architecture embedded in each product together with an infrastructure capable of collecting and analyzing the data. The driver for having such an innovation experiment system 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. 1

http://autos.jdpower.com/

Eternal Embedded Software: Towards Innovation Experiment Systems

25

Developing software in an innovation experiment system is different from development approaches for traditional embedded software. First, it frequently deploys new versions focusing on continuously evolving the embedded software in short cycles of 2-4 weeks, as seen in Figure 1. Second, the design decisions are based on customers and customer usage data throughout the entire development process. Third, the goal of the development process is to test as many innovations as possible with customers to enhance customer satisfaction and, consequently, revenue growth. Last, it allows for software updates to the customer during the entire life-span of the product thereby counteracting declining customer value as the products becomes older. 4.2

Business Model Implications

One of the main trends affecting several embedded systems industries is the transition from products to services. Whereas companies such as telecom equipment manufacturers, automotive companies as well as others earlier were selling products that were static after leaving the factory, more and more customers are requesting the product to be offered as a service. This means that the company remains the owner of the product and offers the use of the product to its customers. As the switching cost for customers typically is much lower and the company is interested in minimizing total cost of ownership, it is important to exploit the postdeployment evolution of the software in the embedded system. This allows for constantly offering (and hopefully monetizing) new functionality as well as maximizing the useful life of products in the field through new software. The capability significantly broadens the set of business models available to an organization. In addition to traditional products sales, pure service contracts, hybrid contracts combining product acquisition with service contracts, as well as usage-based pricing become feasible and all of these are exploited by different companies in the embedded systems industry. 4.3

Architecture Implications

The embedded devices are only one part of the innovation experiment system, the other two being the development environment and the experiment infrastructure, as seen in Figure 2. The experiment infrastructure allows developers to deploy new software and collect data how it behaves in a real-world settings being used by actual users. The infrastructure support deployment of software experiments and collection of data over-the-air on a scale comparable to the entire customer base, for an automotive developer this means devices in the order of 105 . To lessen the burden on the development teams on experimental design with automated randomization and factorial designs [7], it is supported by the infrastructure, sufficient to draw statistical conclusions from the experimental scenarios. The architecture on the embedded device must support composability of the applications to be experimented upon. It must be easy to add or exchange applications when running new experiments with minimal impact on the rest of the

26

J. Bosch and U. Eklund


  

  

  

   

      
    

    

   

     




 

  



 

 



 
 
  


     

Fig. 2. The infrastructure enabling the innovation experiment system

embedded software. This goes against the current trend for cars which tends to integrate more and more functions [3]. The applications included in an experiment must be possible to activate independently of each other, and the product behavior must not depend on the order in which experiments are carried out. In order to remove the burdensome control and synchronization of development teams, and allow independent updates of software experiments, there are three dimensions where decoupling between development parties/teams must take place, and which should be supported by the platform and infrastructure: 1. Decoupling between applications, this would otherwise require all experiments to be synchronized and make future feature growth impossible at some point. 2. Decoupling in time, i.e. all software must not be integrated with the product at the time of manufacturing. 3. Decoupling of applications from the underlying hardware, both from choice of e.g. CPUs and by using suitable sensor/actuator abstractions. The simplest architecture for the embedded device involved in an IES is seen in Figure 3. This architecture is suitable when the memory and processing footprint of the experimental software needs to be kept to a minimum, or when it is desirable to keep the on-board software as simple as possible, at expense of having a more complicated infrastructure.

Eternal Embedded Software: Towards Innovation Experiment Systems

   

27




    

   


  

 



  

 

  

Fig. 3. The architecture for running a thin experiment client on an embedded device with scarce resources or when ease of implementation is desired

The software part under experimentation is usually a small part of embedded software, and all other software parts are kept invariant. If multiple experiments are to be performed in parallel a suitable experiment design has to be used in determining the number of different configurations of the deployed software and how many variants needs to be deployed. Measurement is done on-board, but analysis is done off-board. This collects more data and requires better connection with the infrastructure, but allows exploration of unforeseen behavior from users and allows for posing additional questions after the application is deployed since more raw data is available. This architecture can even be combined with a continuous connection: No data is actually stored on the device, all measurement are uploaded as soon as they are made. This may be the only solution if persistent memory is scarce. When the device has no connection all measurements are lost. Since the management of which experiments are run where and when is done off-board to the devices, this architecture demands the infrastructure to keep track of the individual devices and which software is downloaded to each of them. If A/B testing is performed it is the infrastructure that keeps track of which order to do the tests. If needed to revert to a non-experimental version it must be done by re-deploying a previous unit of software. If the infrastructure does not permit the user to do this it can be detrimental to the user experience. Many embedded domains have stringent dependability requirements. More specifically this means the architecture of the embedded device must 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. If the experiment should run out-of bounds of what is considered safe it must immediately be disabled and a fallback, safe, version of the software application runs instead.

28

J. Bosch and U. Eklund

The safety mechanisms should probably be developed and run independently of the experiment software; otherwise it would inherit the necessary safety integrity level causing unnecessary development effort.

5

Case Study

The case implementing an architecture for an IES was a development project of a prototype to establish a proof-of-concept for some radically different development strategies compared to current software development in the automotive industry. The system was an infotainment system based on an open platform, Android. The project was executed in an industrial setting, but the resulting embedded system was not intended to go into mass production and be sold to customers. The primary goal of the project was to establish whether it was possible to do feature development with extremely short lead-times from decision to implementation compared to present industrial projects, from a nominal lead-time of 1-3 years to 4-12 weeks. The short lead-times were accomplished by a small development team using Scrum from a consultancy firm with automotive software experience, which had a supplier relationship to Volvo car Corporation as product owner. Working software was continuously validated in “real” environments, i.e. the infotainment system was installed in both a driving simulator and real test cars and users evaluated the system during the project. 5.1

Experimentation

A user story in the first sprint covered measurement / logging how the user uses the system with the purpose to provide input to the product backlog and future sprints, in terms of tuning of current features and new ideas. In a subsequent sprint an A/B experiment was defined evaluating two layouts of the start screen of the infotainment system, implemented as two different launchers in Android. The system was mounted in a vehicle and two set of test drivers were requested to perform some common task with the intent to measure which launcher “worked best”. Even though the test sample was too small to draw any conclusions, 7 drivers in total, the test drives showed that the on-board innovation experiment system worked as intended and collected the required data, which was then analyzed off-board. 5.2

Architecture

The system implemented the experiment architecture with a logger from Section 4.3. Architecture for more advanced experiments in future generations of the systems is in the design phase, but is not yet implemented. The system used a logger in the same layer as the observed application, in this case launcher of the android system, seen in Figure 4. The data from the logger was stored in a

Eternal Embedded Software: Towards Innovation Experiment Systems

29

text-file with a batch upload of the data pulled by the developers. The logger kept track of the user’s actions by storing different strings in the text-file, describing the actions that the user has performed, such as adding widgets to the workspace or starting an application. The logger was initiated from within the Android launcher by creating the logger variable and call the constructor of the generic logger-class developed and provided in the platform.









   

  


   

  

Fig. 4. The launcher, which was deployed in two versions, and the logger were both implemented as Android applications, which minimize changes to the platform and utilizes how easy it is to update Android applications

6

Conclusion

Since its first introduction in the middle of the 20th century, software has evolved from a handy configuration mechanism for electronic systems to the core of virtually any modern system supporting individuals, companies and entire societies. This has causes a significant expansion of the lifespan of software systems to the point that it is measured in decades rather than years. This trend is starting to become a key challenge for embedded software as well. In the context of connected embedded systems, this results in two main categories of “eternal” embedded software, i.e. infrastructure software and mass-produced embedded systems. Examples of embedded infrastructure software include traffic lights, railway signalling, public transport automated ticket systems etc. Systems previously “unconnected” are becomening more and more software dependent, such as carto-car and car-to-infrastructure communication, which increses this category of software ssystems. The investments necessary in infrastructure software makes deployment of new systesm a rare occasion. Mass-produced embedded systems are usually built on a software platform that outlives the hardware platform, e.g. the microprocessor the software runs on. The software platform evolves beyond its initial purpose, and reuse of software is common between product generations. Cars are a typical example of this, where

30

J. Bosch and U. Eklund

a new car model may reuse software from previous generation, and where the manufacturing life-cycle of a car model, typically seven years, is usually longer than the production of a single micro-controller. The long life-cycle of these kind of systems demand that they evolve in order to prvide continuous value to the customer, especially if the competition drives an increasing pace of change. The typicla approach to this was to have period releases, e.g. yalry modle changes, but connected embedded systems allow continuous testing of new, innovative functionality to be deployed. This allows for significant improvements in the rate of innovation and the ability to systems to adjust to their continuously evolving environment. We refer to this trend as innovation experiment systems. In practice, this offers product producers the ability to conduct innovation experiments with the deployed systems. The contribution of the paper is that it discussed the concept of innovation experiment systems in the context of long-lived embedded systems. In addition, it explored the architectural implications as the ability to continuously evolve and conduct experiences in the deployed product context in a safe and controlled manner must be supported by the architecture of the embedded systems. Finally, it illustrates these concepts using a case study concerning an infotainment system in the automotive industry. Not all embedded systems are suitable for innovation experiment systems, we can identify at least three categories of systems where an IES may be of limited use. The first category are systems which have long lead-times due to heavy verification & validation, such as safety-critical systems and other systems requiring certification before deployment, e.g. nuclear power plants, medical devices etc. Second are embedded domains where the rate of innovation is secondary to other concerns, i.e. very mature domains, from a business or technical perspective.. Third, embedded domains where the product is viewed as a product, i.e. an item which can be bought and owned. The customer is less concerned with the services the product can supply. The trend towards “eternal” embedded software is strong and is starting to affect many aspects of traditional product development in the industry. Our notion of innovation experiment systems provides a natural mechanism that allows an embedded system, its architecture and its underlying platform to continuously evolve in response to changes in the user requirements and system context. It uses a rapid feedback loop to evaluate the benefits of small variations to users of the product with the intent of continuously improving the system. 6.1

Future Work

In future work, we intend to significantly expand the number of examples in which we study the application of innovation experiment systems to real industrial contexts, to further develop the conceptual framework and to report on our findings. Further validation of IES for software in connected embedded systems would focus on: Investigations of further technical challenges of the embedded platform, beyond what was briefly described in the case in Section 5. Increase the number of involved devices to identify the challenges involved in large scale IES.

Eternal Embedded Software: Towards Innovation Experiment Systems

31

Studying the implications for development teams involved in short cycle development and deployment. And finally, investigate the business implications of IES in various embedded domains. These would probably require other methodological approaches besides case studies. Since the management of which experiments are run where and when is done off-board to the devices, the infrastructure needs to keep track of the individual devices and which software units are downloaded to each of them. This could pose security and specifically privacy issues, which could be an obstacle in widespread acceptance among users, and is thus also some thing that needs to be investigated further. Future work on IES need to address these privacy issues, some possible solutions could be: Adapting present practices, e.g. a modern vehicle has it’s software configuration stored in an in an off-device database [6]. Tracking software configurations of connected devices as part of the business model, e.g. as in Apple App Store or Google Play (formerly Android Market). A third option could be getting consent through an opt-in scheme, common in many desktop programs collecting anonymous data. In all of these care must be taken in sufficiently anonymize usage data from the device, and person, identification. Acknowledgments. The case was financially supported by the Swedish Agency for Innovation Systems (VINNOVA), EIS by Semcon and Volvo Car Corporation within the partnership for Strategic Vehicle Research and Innovation (FFI).

References 1. Bosch, J.: Building Products as Innovation Experiment Systems. In: Cusumano, M.A., Iyer, B., Venkatraman, N. (eds.) ICSOB 2012. LNBIP, vol. 114, pp. 27–39. Springer, Heidelberg (2012) 2. Broy, M.: Challenges in automotive software engineering. In: Proceedings of the International Conference on Software Engineering, pp. 33–42. ACM, Shanghai (2006), http://portal.acm.org/citation.cfm?id=1134285.1134292 3. Di Natale, M., Sangiovanni-Vincentelli, A.L.: Moving from federated to integrated architectures in automotive: The role of standards, methods and tools. Proceedings of the IEEE 98(4), 603–620 (2010), http://dx.doi.org/10.1109/JPROC.2009.2039550 4. Ebert, C., Jones, C.: Embedded software: Facts, figures, and future. Computer 42(4), 42–52 (2009), http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber= 5054871&isnumber=5054856 5. Koslowski, T.: Your connected vehicle is arriving. Technology Review (January 2012), http://www.technologyreview.com/business/39407/ 6. Melin, K.: Volvo s80: Electrical system of the future. Volvo Technology Report 1, 3–7 (1998), http://www.artes.uu.se/mobility/industri/volvo04/elsystem.pdf 7. Montgomery, D.C.: Design and Analysis of Experiments, 3rd edn. Wiley (1991) 8. Reichheld, F.F.: The one number you need to grow. Harvard Business Review 81(12), 46–54 (2003), http://hbr.org/2003/12/the-one-number-you-need-to-grow/ar/1