This a guest post by Chris Wild, CTO of Altran Praxis, a specialist systems and software house which delivers engineering, technology and innovation for the world’s embedded and critical systems. Chris has 28 years of experience in the software industry and has worked in the aerospace, automotive, telecoms and mobility sectors. His technical background covers mathematical algorithms, real-time and embedded systems delivery, AI, HMI and architecture.
The App Store, in one form or another, is now an established, and even standard, feature of any smartphone worthy of the name. Consumers are able (and expect) to update their devices with applications and services in a manner which is robust, secure and with a well understood cost. Whether by web page or device specific clients, App Stores provide for secure purchase, download and installation of new apps in an easy and controlled process. Importantly, consumer confidence in the apps available on an App Store is maintained through pre-qualification by the App Store operator.
This approach has brought many benefits to the smartphone market, notably allowing an army of creative developers to provide content in a volume and speed-to-market which would have been impossible in a centrally integrated or commissioned development model.
In-car infotainment systems are currently seen as another market which could benefit from an App Store approach. Potentially, a number of issues associated with infotainment systems and their delivery could be solved using the same central App Store concept as smart phones.
Infotainment systems today are closed, either through policy or through technology limitations. There are good reasons for this situation; software running on an infotainment system will be used primarily by a driver. Any interface to the driver needs to take into account that the driver is occupied with the critical task of driving. Design and ergonomy are of vital importance in this context. In addition, the automotive original equipment manufacturers (OEMs) use the design and ergonomy as part of their brand identity. The constraints on safety and brand identity result in design and ergonomy being tightly controlled by the OEMs.
Besides the ergonomy and design aspects, OEMs insist on high quality standards for software, partly to support the brand image, but also for another aspect of safety and security. A driver distracted by unexpected behaviour from a system becomes a threat to himself and to other road users.
Until recently, these issues had traditionally been addressed by developing closed infotainment systems – you buy a system with a look-and-feel and a pre-packaged set of functions with no possibility for user-driven updates.
Today, the OEMs are under pressure to provide systems which support integration with consumer devices, work with connected telematics, and which will match the end-user expectations derived from the smartphone market. This can be summed up by saying ‘everybody wants a smartphone and everybody wants to use it in their car’. The underlying issue here is that the closed in-car system development cycle is typically 2-4 years while devices, services and smartphone applications can appear and evolve in the market in a timeframe of months.
It seems apparent that the OEMs have to sacrifice the closed system approach if they wish to respond to these pressures. The key technical point is that in-car systems will need to support the delivery and integration of software after the basic system has been built, tested and sold. In addition, the OEMs do not have the resources to develop all the required applications themselves, they will be forced to rely on third parties.
The App Store concept may go some way to solving this issue in a way that the OEMs can live with. The combination of providing technology support through development, Software Development Kits (SDKs), a controlled test and release process to the App Store and a flexible and transparent business model should allow the OEMs, and potentially third parties, to obtain and release software more quickly, while still protecting brand and quality. The key thing that the App Store gives is a process to support independent development (hence an army of developers) in conjunction with a centralised quality control gate at the point of acceptance into the App Store.
Enabling this approach also requires that the technology base for the in-car system evolves to support dynamic integration of applications, something which is being seen in current announcements such as GENIVI, Hughes Telematics and Ford.
Of course the whole story depends on a number of factors aligning to drive the market. First and foremost, the end users need to be motivated to buy the applications for their in-car system. This will occur where the applications are relevant, ergonomic, safe and correctly priced.
Ergonomics will be largely decided by the criteria developed by the OEMs and perhaps enforced in their SDKs. Safety will be determined by the OEMs and perhaps by legislation.
Relevance will be the factor which exercises the creativity of the application developers. It should not be expected that App Stores targeting in-car platforms will have the number of applications seen at Apple for instance – drivers will not be playing games as they drive. So naturally the question will arise as to what will be the relevant and successful applications and services delivered to in-car systems. Current thinking is that the first wave of successful applications will be those which extend the possibilities of capabilities already in the car in a manner which is non-intrusive. One obvious example is to allow an end-user of the in-car media system to purchase music playing on a radio station and have it automatically billed and transferred to his device, all with one button press.
As described above, the App Store approach may seem to benefit everybody in the chain, but there are some non-technical issues for the OEMs if they wish to move to this model. App Stores will require a number of activities, application development, service provision, communications management and platform support. The OEMs will become one player in the value chain – perhaps the key player, but then again perhaps not. Any revenue stream will be shared between the application developers, service suppliers, the communications operators and the OEMs. It is also not obvious that the OEMs will run the App Store as a business operation, managing the servers and the billing; the OEMs may turn this over to third parties or even run into competition from a number of other players, notably the Telcos.
It seems likely that App Stores will appear in your car in the near future. The market pull is there and the technology support exists, what is not yet known is whose App Stores they will be.