var vidWidth;var vidHeight;if (screen.availWidth > 400) {vidWidth = 550;vidHeight = 346;}else {vidWidth = 240;vidHeight = 151;}var _nlvq = _nlvq || [];_nlvq.push([‘api’,’p1′]);_nlvq.push([‘uid’,’TUP4HR’]);_nlvq.push([‘width’, vidWidth]);_nlvq.push([‘height’, vidHeight]);


At this year’s Mobile World Congress, Paul Mascarenas, Ford’s Chief Technical Officer, announced the  EVOS concept car and spoke about the vision of the Digital handshake for the car when he said that:

You expect websites to remember your log in, so what if every car you stepped into could read your mind, completely personalizing any car you drive? Tapping into the information you’ve stored in the cloud, a “digital handshake” would transport your personal preferences to every car you drive.

He went on further to say that:  “Imagine you drive a Mondeo in Barcelona, and you pick up a hire car in London. When you step into that car, it would know all your preferences including the way you drive and temperature you prefer.

This vision may be not so far away as we first think. The webinos project is working to make it into a reality.

In a recent demo of in vehicle APIs demonstrated by webinos –  Simon Isenberg of webinos/BWW provided some specifics on how this would work using a web based architecture.

The vehicle can be a valuable provider of data. This data source can enable us to build a complete new breed of distributed Web applications and take the Web to a new level. Despite all the new possibilities, we have to take the specific challenges of software development in the automotive domain into account. A vehicle differs from the ‘Smart phone’ in the level of complexity.  Today’s cars feature up to 80 electronic control units (ECUs), which are interconnected using different bus technologies for the respective tasks inside a vehicle.

The following diagram illustrates the different bus systems inside the vehicle. In the end, all busses are connected to each other using a central gateway. At the central gateway messages which are used car-wide are converted and routed into another bus.


If we want to provide access to the vehicle, we have to interface directly with the different buses, which raises security risks. Depending on the integration level we have to obey certain norms and laws (cf., IEC 61508, Automotive Security Levels (ASIL)).  Thus, infotainment applications should not  interfere with safety critical functions inside the vehicle.

With respect to webinos, a good entry point into the vehicle system is the in-car headunit. The headunit hosts the navigation system as well as portable media integration and connects to the CD-Player, built-in GSM modem, the rear-seat entertainment system or the user’s cell phone. So, it is to some extent  sandboxed from the highly safety-critical systems inside the vehicle like airbag ECUs or an active breaking system. But there are still soft-real time messages used in the headunit. For instance, the data from the parking distance sensors are routed into the headunit to illustrate the distance to sensed objects on the central display. To ensure that a webinos application does not interfere with other vehicle components, webinos controls access to vehicle busses via the webinos API and provide safe read access to vehicle data. To this end the webinos API is – at least for now – limited to data available in the headunit, which is able to ensure the required safety properties.

In the first release of the webinos platform the Vehicle API has a strong focus on providing read access to vehicle data and methods for interacting with the on-board navigation system. The vehicle API is designed to be in line with current W3C specifications and is based on an event model.

The Vehicle API provides read access to the following:

–        Static vehicle data (make, model, fuel type, transmission type)

–        Distance sensor data

–        Trip computer data (average speed, consumption, mileage, range)

–        Climate data (air conditioning and vents)

–        Control data (wipers and  lights status)

–        Gear data

–        Navigation data (destination reached, guidance cancelled)

So, the webinos APIs provide an avenue (or at least a starting point) to fulfill the vision of the ‘Digital handshake’ as articulated by Bill Ford.

But how far is this future according to the auto makers?

Bill Ford Junior sees an incremental timescale: “In the near term, existing vehicle tech will continue to improve; for example maps will provide better driver information; mobile communications and driver interfaces will become more intuitive with alerts to traffic jams and accidents.”

Again this is consistent with the webinos vision and APIs