[Skip to content]

Search our Site

Adopting universal technology platforms for tolling

First publishedin ITS International
2009 July
[ Zoom ]
fingerprint
The technology for Time/Distance/Place tolling should no longer be treated as a discrete entity, says Technolution's Dave Marples. The 'who, what and where'-type information necessary would be better piggybacked onto or integrated into systems capable of supporting multiple applications.

Dave Marples of Technolution argues that the continuing development of tolling-specific onboard equipment is leading us up a blind alley. We should, he says, be looking to realise universal platforms with universal application.

The near-future automobile contains information systems of a sophistication to rival a jet airliner of only a few years ago, yet is 'piloted' by a considerably less well-trained individual of highly variable mental and physical capacity, and operated in a hostile, unpredictable and potentially badly maintained and monitored environment. These increasingly complex systems will be subject to a wide set of user demands and requirements which will change over a vehicle's lifetime. This means that they need to become much more flexible, open, upgradeable, secure and configurable. In short, the vehicle and systems' lifecycles need to be decoupled and there is an increasing demand for OnBoard Equipment (OBE) to be able to meet these criteria.

The 're-purposable' platform

For existing vehicle applications, the tendency has been to provide a separate, dedicated device which incorporates the desired functionality - SatNav, tolling and In-Car Entertainment (ICE) spring immediately to mind. Of these, only ICE has standard interfaces into the vehicle (via the ubiquitous DIN slot). For the others we are reduced to using the cigarette lighter power socket; why are we still in a world where the only standardised in-vehicle power supply is via a socket whose original purpose is nominally obsolete?

New applications and consequences

New ITS applications will increase the demand for closer connections into the vehicle in a standardised, cross-manufacturer way. A significant limitation on the take-up of applications is the availability of in-vehicle computation resource since, without it, every single application needs to carry the entire cost of the OBE. The value proposition for that application needs to be exceptionally strong, therefore.

Aside from navigation the applications under consideration can be categorised into a number of distinct groups (see Sidebar, 'Emerging applications').

The applications listed represent only a primitive set of examples, and many people will make their fortunes in this new market of extensions to vehicle functionality. We have prototyped many of these applications and found that closer physical and logical integration with the vehicle is required both for access to data essential for service operation and simply from the practical perspective of ensuring the vehicle user is not swamped with devices. A professionally installed, physically secure device allows application authors to make assumptions about the behaviour of the platform and its capabilities.

Charging and automated payment

These include tolling regimes, automatic car parking, fuel and other payments. Aside from SatNav this is the easiest category to consider and requires little further explanation.

Safety

Driver performance feedback, OnStar/eCall, upcoming speed limit and hazard warnings, speed modulation, lane maintenance, emergency braking and active cruise control as an aftermarket fit are all on their way. These can't all (yet) be integrated into existing vehicle systems, so they need to be provisioned via separate OBE.

Performance modulation

'You may drive in this city but please set your emissions/engine performance to produce less than 150g/km of CO2'; imagine a system which allowed a reduction in the performance of the automobile voluntarily, with corresponding improvements in fuel efficiency and wear. The driver might elect to do this when in slow traffic on the way to work, for example.

Upgrades

With such a plethora of software in the vehicle, and as the vehicle moves to become part of a larger network, it is unreasonable to expect that the build state in which the vehicle left the showroom will remain the same throughout its life...just think of the number of upgrades the average PC needs during its lifetime in order to remain safe and current.
Physical integration simply requires OEMs to adopt a 'standard fitment' for the processor unit which can be removed and upgraded over the vehicle's life as application demands increase and processing capacity gets cheaper; think of it as a DIN slot for applications. The benefit of such a fitment should not be underestimated by manufacturers - look at Bluetooth penetration in the new car market in just a couple of years! Access to power, in-vehicle systems and audio/video I/O should all be available and must be manufacturer-independent. As with ICE, manufacturers will offer their own preferred housing, but the adoption of a set of physical and power standards allows users to upgrade to something meeting their specific demands - different OBEs will have different capabilities and an upgrade path will be enabled.

This approach has limitations. It is reasonable to expect that there will only be a single space in the vehicle, and so multiple applications will need to share the device as multiple programs share PCs today. This is a non-trivial requirement that implies considerations of security, fair resource sharing, multiple program I/O, seamless update and real-time operation in order to maintain manufacturer differentiation. As the interface to users would remain OEM-specific, Application Programming Interfaces (APIs) would need to be developed.

This approach can, by definition, only be created by a set of OEMs working together in a vendor-neutral environment. This isn't really new: the European Union's Global System for Telematics (GST) Project set out to define such an environment, at the protocol and API, which could support multiple applications with the required security and certification components. It delivered its results in 2007, showcased many applications and unequivocally demonstrated the practicality of the concept of the open, generic application platform.

A practical system

Technolution realised the GST vision in a highly featured device which makes 3D accelerometers, real-time clocks, serial ports, generic I/O, storage, CANbus access, audio I/O, GPRS and many other facilities available to applications on a highly reliable, tamperproof, battery-backed platform with optional display capability. This versatile OBE, the MobiBoxx, has been widely employed for applications as diverse as distance-based road charging and driver performance monitoring and the utility of the shared device has been proven beyond doubt.

Insurance

A device continuously assessing a driver's performance and offering real-time feedback and a rebate at the end of the year for observing speed limits, safe driving distances and smooth operation would not only significantly improve driver behaviour but would also serve to increase the 'stickiness' of an insurance company's best customers.

Insurance has numerous other possibilities too: a device that could recognise which of a number of drivers is actually operating the vehicle opens up the possibility of driver-dependant insurance and access to expensive vehicles for young drivers who would otherwise find the cost of cover prohibitive.

Entertainment

It will be possible to tailor entertainment delivery to the use state of the vehicle (driving, parked, in stationary traffic and so on) using richer data sources than just a speed tick and individually, in a differentiated fashion, to both the driver and their passengers. Games containing a geographic element, tourist information services and 'meet me' social services will all emerge, as will collaborative entertainments which serve to keep the user aware of the environment in which they find themselves and so improve attentiveness.

Load-specific applications

Cold chain maintenance, radioactivity monitoring, vibration logging, load/route restrictions, package tracking and any number of other load-specific applications could be deployed on a platform in the vehicle rather than on bespoke equipment as is currently the case. These applications benefit from the knowledge that the monitoring equipment is permanently fitted to the vehicle and has access to a specific set of sensors.

Benefit proposition

The ramifications of the adoption of the principles of upgradeable OBEs are profound. In order for it to become a reality, each stakeholder has to be able to realise benefit from it, otherwise it will never progress from interesting academic exercise to market. The value proposition for the automotive OEMs is probably the most complex. No car manufacturer has yet been able to fully exploit the increased software content in the automobile. There are many reasons why but certainly the car industry's route to market and dealership structure are significant limitations; compare the price of an integrated SatNav and an aftermarket product - the aftermarket product is normally an order of magnitude cheaper. The auto manufacturer has also never been able to take advantage of the up-sell of new capabilities to the end user - the $10 novelty voice for that aftermarket SatNav is an example. The OBE 'slot' would allow the OEM to benefit from the economies of scale of a mass market product while not needing to compete in a software arms race with other OEMs.

The situation is much clearer for operators of the networks that will deliver content and communications to the OBE. These are typically the mobile phone and data network operators of today, and the opportunity for them is to enter whole a new market.

For application providers, the existence of the shared OBE is a dream come true. A whole new environment in which to deliver applications to a market that can easily understand the value that they offer; from simple parking guidance through to intelligent speed control, all without having to justify the hardware cost. This of course leads to the easiest benefit proposition of all - for the end user. They can, for a relatively small outlay, get applications that truly meet their requirements in an existing vehicle. If the OBE they currently have is not sufficiently powerful they can move to a more powerful model by exploiting the 'plugability' concept. In the medium term, when the applications represent a significant proportion of the utility of a specific vehicle, being able to upgrade the applications in a vehicle means that it will retain its value better.

Conclusions

In future, applications will need to be provisioned and removed from the platform during active operation and many different agencies will need to access to these platforms in a controlled, reliable, secure and mediated manner.

The technical issues in this vision are, however, the simple ones to solve. We are missing a business model support and an understanding throughout the industry that collaboration for mutual benefit is necessary. Without models which allow all participants to extract value from this brave new world of highly functional vehicle infrastructure it is difficult to see how the market can develop. In an industry used to competition and minimal collaboration, the allegiances and alliances required to enable business models based on deploying a single application across a wide range of vehicles from multiple manufacturers are difficult to engender. Some of this vision can, and is, realised by the SatNav manufacturers but they lack the physical interconnection to the vehicle with associated security, the tighter systems integration and the open access that is necessary for OBEs to progress to the next stage - being perceived as a seamless upgrade to vehicle functionality in the same way that software packages are seen as seamless extensions of PC functionality.

Companies in this article

Technolution
www.Technolution.nl

Share this page

Page Comments