SmartDeviceLink (SDL) is mobile-auto interaction technology which was originally devised by Ford (as an evolution of Applink) but is currently being developed under the auspices of the GENIVI alliance. This is a very interesting technology in the mobile-auto interaction space and we decided to check it out in Carmesh.
While details relating to the technology itself are somewhat in flux and the subject of the discussions within the GENIVI alliance, the basic ideas are reasonably clear. Essentially, SDL comprises of a set of standardized messages which can enable the car and the mobile to exchange state and control information. For example, it’s possible for the mobile to display specific text or images on the car dashboard, control audio playout on the car’s sound system and receive notifications when buttons on the steering wheel are pressed; in future, it should be possible to send specific Points Of Interest from the phone to the car’s navigation system amongst other things.
What is perhaps more interesting than the message exchange itself is the larger context within which they fit. Although there is no canonical view of the system architecture, the system is biased towards one in which most of the UI components are provided by the car (with the possible exception of voice) and the mobile provides the application ‘brains’.
Delving a bit deeper, questions about the nature of the UI on the dashboard arise – where is this controlled? In the current incarnation of SDL, there is provision for a number of different templates for applications; an application can run on the phone and choose one of these templates (eg a media player application or a navigation application). The mobile application can then control the visual aspects of the UI on the dashboard with knowledge of the template. This makes it easier for the mobile application developer to design attractive UIs without requiring full control of content rendering in the car.
Of course, it’s possible to implement mechanisms in which the mobile can build the UI on the dashboard dynamically (eg define layout indicating what text and visual components go where), but this is not reflected in the current version. While it is somehow on the roadmap, it has been deferred for a later version.
Clearly, the conversation between the auto developers and the mobile sector is only beginning and having a limited number of such templates makes sense at the start. Over time, these templates will evolve and the mobile application will also get more control of the car UI components, thus enabling automotive application developers to have more flexibility in the experience they deliver to their users. In carmesh we will continue to explore this interesting technology by building some basic services on top of it.