Introducing Software Ecosystems for Mass-Produced Embedded Systems

Introducing Software Ecosystems for Mass-Produced Embedded Systems Ulrik Eklund and Jan Bosch Chalmers University of Technology Software Engineering Division, Dept. of Computer Science & Engineering Göteborg, Sweden ulrik.eklund@chalmers.se,jan.bosch@chalmers.se Summary. Embedded systems are today predominantly developed with an integration-centric approach. The paper identifies the need to remove full-scale 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. Key words: embedded software, software architecture, software ecosystem, case study 1Introduction The approach of developing software in an ecosystem instead of as an integrator towards the customer could provide some advantages also in the embedded domain, such as alleviating the complexity of synchronising large-scale development projects and extending the innovation base. Software ecosystems have been studied by several researchers [1, 2, 3]. Jansen et al. [4] presents a set of research challenges and this paper responds to the first challenge of characterisation and modelling of ecosystems for the domain of software-intensive embedded systems. The main contribution of this paper is a method for establishing an ecosystem for mass-produced software-intensive embedded products. The method consists of a set of key activities for the original equipment manufacturer (OEM) to introduce the ecosystem and facilitate the interaction between development parties. 2ContextandProblemStatement Many companies developing mass-produced embedded systems view software as a necessary evil rather than as a strategic opportunity and business differentiator. One reason for this is that they have extensive supplier and subcontractor relationships and the cost, effort and unpredictability of the deliverables from these external partners is experienced as a major problem. The mass-produced embedded systems are typically developed with an integration-centric approach

2 U. Eklund, J. Bosch where the OEM needs to be in full control of the development of all software and synchronise the development of the involved parties. Examples of mass-produced embedded products include vehicles, washing machines and other home utensils, and printers. We will give general examples from the automotive industry since cars are arguably the most complex product of this category, both in terms of conflicting requirements and subcontractor relationships. We define the domain of mass-produced software-intensive embedded systems by four characteristics: Deepintegrationbetweenhardwareandsoftwareforsignificantpartsofthe functionality Strongfocusonmanufacturingaspectsoftheproductinthedevelopment(e.g. by development process gates) Strongsupplierinvolvementintheformofsubcontractors Someelementsofthesystemrealisesafety-criticalfunctionality There are four main reasons why the integration-centric approach, is a dead end for many embedded domains, especially in the case of significant outsourcing: First, it is not possible to rely on control through processes and synchronisation of processes because external developers might not use the same process. Second, when the release cycle is imposed on software from hardware manufacturing concerns it results in old software applications since the leadtime of mechanical/hardware development and its industrialisation is longer than competitively desired for software. Third, feature content is growing exponentially [5], especially in the automotive domain [6]. Since this adds interdependencies if not managed the integration phase actually gets shorter since all software parts have to be finished before integration can take place. Last, heavy outsourcing of software development, often globally, goes against the need for efficient inter-team communication in integration-centric development.[7] The conclusion is that it is necessary to move away from integration-centric development. The most sustainable alternative is the open ecosystem [7] and it will thus be further elaborated in this paper. The research question investigated is thus: What are the key activities to establish a software ecosystem for massproduced embedded systems? 3IntroductionofaSoftwareEcosystem The ecosystem would focus on a product or family of products of embedded devices with an open software platform. The hardware technology would be very domain specific, e.g. sensors and actuators for cars or printers. To facilitate new business opportunities and remove the burdensome synchronisation of subcontracted development teams there are two dimensions where decoupling between development parties/teams must take place and which should be supported by the ecosystem and the platform: 1) Decoupling between applications, this would otherwise make future feature growth impossible at some point. 2) Decoupling in time, i.e. all software must not join at manufacturing of the product. Amodeldefiningthetransitionfromanintegration-centricsoftwaredevelopment to the establishment of a software ecosystem includes the following key activities for the OEM:

Introducing Software Ecosystems for Embedded Systems 3 3.1 Choose the Ecosystem Type There are three types of software ecosystems according to the second author [2]: Operating System-centric, application-centric, and end-user programming. Typical products with embedded software exhibit many characteristics of where an application-centric software ecosystem starts; with a domain-specific application(s) deeply embedded in the product which is sold to the end customer. 3.2 Open up the Platform The software platform supporting the ecosystem and the applications must be deployed to each product. The platform would include an operating system, domain-specific middleware and key domain applications, sufficient to use the product and fulfil any legal and safety requirements. Many embedded products exhibit real-time behaviour so application execution must be supported by realtime mechanisms, depending on the domain. Since the software can be deployed at any time the platform and its architecture should allow development, integration and validation of feature applications independent of other applications. Each application executes in an isolated environment, with critical applications executing on dedicated hardware, and dependencies between applications are only established at run-time, for example realised by process virtualisation [8]. 3.3 Establish OEM as Keystone Organisation The OEM would have a crucial role in the ecosystem as a keystone organisation [9] since it manufactures the product that software applications will run on. The OEM is responsible for developing the ecosystem platform, at least initially. The keystone organisation should provide the stability of the ecosystem for niche developers to establish themselves by producing the systems with the embedded platform for a sufficiently long time. 3.4 Establish Business Opportunities for Developers The reason for the customer to buy the product is the capabilities provided by domain-specific software applications utilising the hardware of the product, i.e. sensors and actuators manufacture by the OEM. The applications are provided by the OEM and by 3rd parties directly to the end customer, enabling for business opportunities not possible when all software is directed by the OEM. Technical end customers can even develop their own applications if sufficient IDE support for the platform is available. The incentive for the OEM to migrate towards an ecosystem would be to share total cost of development between parties in the ecosystem and open up the innovation base. In return the OEM provides the stability necessary for other parties. 3.5 Establish Infrastructure for Continuous Deployment of Software The development teams deploy their applications independent of each other and independent from the platform and hardware. This is enabled by an automated infrastructure that can distribute software application to thousands of devices, each with its own software configuration. This contrasts with continuously checking in software to a central repository and build system for e.g. web applications. The infrastructure must both allow customers to enhance their product with new applications as well as allow developers to push updates of

4 U. Eklund, J. Bosch already deployed applications. To facilitate business opportunities for the external developers the infrastructure would have a marketplace for them towards the end customer. This can be provided by the keystone organisation or by already established mechanisms. The infrastructure also support necessary certification processes before deploying software to customers, processes that are demanded by legal, safety-critical or security reasons. 4AnEcosystemintheCarDomain Since there is no widely known software ecosystem such as the one described above it is difficult to present proven industrial cases, but we present an instantiation of the software ecosystem for the automotive domain. Amoderncarisarguablythemostcomplexmass-producedembeddedsystem developed in terms of conflicting requirements and subcontractor structure. Software development follows the process logic of the mechanical development and the deployment of software to the customer follows the physical delivery of the product. In a software ecosystem, where software can be deployed to the product also after delivery, the platform would include vehicle software necessary to fulfil legal and safety requirements, e.g. displaying vehicle speed in a cluster display and ESP. This would make the car usable at delivery to the end-customer without further actions. All other software applications could be deployed on the vehicle en route to the customer or after delivery; it could either be the sales organisation that acquired additional software components from the OEM or 3rd parties, or the end customer. For vehicle fleets it would be possible to acquire or replace application software catering to fleet-specific needs, e.g. car-share pools or large taxi firms. Suppliers could focus on providing domain specific actuators, e.g. brakes or door locks, with middleware conforming to the platform, leaving the vehicle-level development to other parties, e.g. the OEM, or also offer those as well. Firms providing after-market solutions, including the OEM, would have unprecedented opportunities to integrate their solutions seamlessly with the OEM platform, providing better customer value than what is possible today. 4.1 Open Infotainment Labs The Open Infotainment Labs was a prototype of an in-vehicle infotainment system developed in cooperation between Volvo Car Corporation and EIS by Semcon, but was not intended to go into mass-production and be sold to customers. The project had two goals: First, feature development with extremely short lead-times from decision to implementation compared to present automotive industry standard, from a nominal lead-time of 1-3 years to 4-12 weeks. Second, to investigate application-based architecture open to 3rd party feature development, i.e. development not sourced or ordered by Volvo Cars, and as such form the basis for a software ecosystem around in-vehicle infotainment systems. The software platform was based on Android, which already had some desired architectural properties, such as run-time isolation of applications and an established infrastructure for continuous deployment. In addition to this the following architectural mechanisms were investigated: PossibleappmarketsolutionsfortheOEM SecuregatewaybetweenAndroidappsandvehicle-criticalmicro-controllers

Introducing Software Ecosystems for Embedded Systems 5 Domain-specific API available for Android app developers with over 50 different vehicle attributes Mechanisms to sign OEM-approved applications with privileges to allow interaction with critical vehicle sensors and actuators Modelsfordifferentcategoriesofapplications,forexampletopreventapplications to start when driving the vehicle e.g. to minimise driver distraction Domain-specificresourcemanagement,inacaraudiowarningshavehigher priority than a phone call The prototype system was implemented in an actual car and tested by persons outside of the two development partners. It was possible for the users to tailor the system according to their individual wishes by e.g. installing their favourite web radio application from an external marketplace while in the car. 4.2 AUTOSAR AUTOSAR is a project to establish an open industry standard for the automotive software architecture between suppliers and manufacturers. [10] The standardised architecture exhibits some of the properties in Section 3.2, such as mechanisms to allow multiple different functions, in the form of software components, to be deployed to the same micro-controller independently from the supplier of either part, and a large set of standardised application interfaces. [10] However the prescribed methodology assumes that all integration of software components is done by the OEM [11], i.e. falls into the integration-centric development category, there are no mechanisms to support independent software deployment. Even if there is no business model prescribed by the AUTOSAR standard, it can be assumed that the closed supplier-oem business relationship seen in the automotive domain today is preserved. 5RelatedWork Jansen et al. [1] provides two cases of software ecosystem together with a definition of ecosystem characteristics. The activities in Section 3 fall into their external scope in terms of market, technology, platform and firms. Rohrbeck et al. [12] describes how Deutsche Telekom created an open innovation ecosystem and identifies 11 open innovation instruments. The resulting innovations range from features added to what the suppliers offer to those developed entirely at Deutsche Telekom. The focus on the paper is on innovation schemes and thus complements the activities in Section 3. Viljainen and Kauppinen [3] describe a set of management practices for software ecosystems, together with a case from the telecom industry. They focus on the platform integrator which plays the role of keystone organisation. The activities in Section 3 can be categorised within their practice of orchestration, but for mass-produced embedded systems. The second author et al. [7] provides three cases of ecosystems, one of them being a company developing embedded products. The paper defines five approaches to software development from integration-centric development to software ecosystems, with criteria for when each should be successful, which provided the rationale for the ecosystem presented in this paper.

6 U. Eklund, J. Bosch 6Conclusions We conclude that an integration-centric development of embedded software may not be a sustainable development approach based on four reasons: Feature growth and the resulting complexity, decoupling of the software deployment cycle from manufacturing concerns, alleviate OEM integration efforts, and managing heavy outsourcing to subcontractors. Based on this we proposed a set of five key activities for the OEM to establish the software ecosystem. The ecosystem platform and its architecture are key factors to successfully allow continuous deployment of software directly from the development teams to the customer without requiring big-bang integration from the OEM. Finally we presented how a software ecosystem could look like for the car industry, and presented a case which had implemented some of the platform properties. We reviewed an automotive software architecture standard, AUTOSAR, in terms of its viability as an embedded platform for a software ecosystem in the automotive industry. Acknowledgements.This work has been financially supported by the Swedish Agency for Innovation Systems (VINNOVA) and Volvo Car Corporation. References 1. Jansen, S., Brinkkemper, S., Finkelstein, A.: Business network management as a survival strategy: A tale of two software ecosystems. In: Proceedings of the First Workshop on Software Ecosystems. (2009) 34 48 2. Bosch, J.: From software product lines to software ecosystems. In: Proceedings of the 13th International Software Product Line Conference, ACM (2009) 3. Viljainen, M., Kauppinen, M.: Software ecosystems: A set of management practices for platform integrators in the telecom industry. In: Proceedings of the International Conference on Software Business. Volume 80 of Lecture Notes in Business Information Processing., Springer (2011) 32 43 4. Jansen, S., Finkelstein, A., Brinkkemper, S.: A sense of community: A research agenda for software ecosystems. In: Proceedings of the International Conference on Software Engineering - Companion Volume, IEEE (2009) 187 190 5. Ebert, C., Jones, C.: Embedded software: Facts, figures, and future. Computer 42(4) (2009) 42 52 6. Broy, M.: Challenges in automotive software engineering. In: Proceedings of the International Conference on Software Engineering, ACM (2006) 33 42 7. Bosch, J., Bosch-Sijtsema, P.: From integration to composition: On the impact of software product lines, global development and ecosystems. Journal of Systems and Software 83(1) (2010) 67 76 8. Smith, J.E., Nair, R.: The architecture of virtual machines. Computer 38(5) (may 2005) 32 38 9. Iansiti, M., Levien, R.: Strategy as ecology. Harvard Business Review 82(3) (2004) 68 78 PMID: 15029791. 10. Fürst, S., Mössinger, J., Bunzel, S., Weber, T., Kirschke-Biller, F., Heitkämper, P., Kinkelin, G., Nishikawa, K., Lange, K.: AUTOSAR - a worldwide standard is on the road. In: International VDI Congress Electronic Systems for Vehicles, Baden-Baden, Germany (2009) 11. AUTOSAR: AUTOSAR technical overview v2.2.2 (aug 2008) 12. Rohrbeck, R., Hölzle, K., Gemünden, H.G.: Opening up for competitive advantage -howdeutschetelekomcreatesanopeninnovationecosystem.r&dmanagement 39(4) (sep 2009) 420 430