Call us on
+44 (0) 1603 485 153

Using in-vehicle computers safely whilst driving

This is a copy of a blog article by David Hitchings, In-CarPC's General Manager.  The article was first published on 23rd September 2013.

The debate about how modern technology can be made available to a driver without negatively affecting their control of the vehicle has been going on for quite some time.  Satellite Navigation systems were probably the devices that started the debate in earnest, but I'm sure that similar concerns were raised for a lot of other in-vehicle technologies at the time of their introduction, going right back to the first analogue in-car radios.  How things have moved on – now we have devices like smartphones and in-vehicle computers that are capable of conveying all kinds of information, only some of which is actually necessary or helpful to a driver while the vehicle is moving.

One method that is often touted as a means of reducing driver distraction is to have all interaction between the driver and the computer carried out by speech.  This relies on two distinct technologies:

  • Speech recognition – the computer recognises what the driver says so that he/she does not have to take a hand off the wheel to press a button or touchscreen.  Information flows from the driver to the computer.
  • Speech synthesis – the computer "speaks" to the driver, so that the driver does not have to take their eyes off the road to look at a screen or dial to find something out.  Information flows from the computer to the driver.

I certainly think that both speech recognition and speech synthesis will become increasingly important and widespread in the future, perhaps even to the extent that one day there may be no need for input methods like buttons or touchscreens.  However, I can't ever see speech synthesis completely replacing a visual display.  While information that flows from the driver to the computer is normally infrequent and easy to convey by speech (e.g. "I accept this job" or "turn the volume up"), information that flows from the computer to the driver is often continuously varying and/or unsuitable for being conveyed by speech alone. 

Take navigation information as an example.  At complex junctions, a visual 3D representation of the road ahead, which clearly shows both the current position and the intended route, is so much more useful than a simple "bear right" voice prompt, or a string of complex verbal commands.  Then there are other continuously varying parameters such as speed, estimated time of arrival, and the distance until the next turn.  The beauty of visual information is that, even though it's there all the time, you only actually receive the information when you want to – by glancing at the screen or dial.  Audible information, on the other hand, will always be received (by your ears, at least) regardless of whether you want that information.  Imagine a computerised voice constantly spouting out information that you don't want to hear, or if such information is only provided on request, having to say "what's my speed" hundreds of times every journey.

Because some information is inherently better at being transferred visually rather than audibly, I think that some kind of driver-visible display is here to stay.  Fairly soon it will probably be common for this to take the form of a head-up display (HUD), which projects a picture into the driver's line of sight.  Only a couple of months ago Garmin announced a portable HUD for selected Smartphone apps (only Garmin ones, naturally).  If you were hoping that this would provide a feast of rich, dynamic visual information in your line of sight then think again – the picture below, from a review by Ars Technica, shows that Garmin's device uses a single-colour fixed element display rather than an LCD with individual pixels.

Garmin's HUD uses a single-colour fixed element display. (Image © Ars Technica, see link in text for source)

The fact that Garmin's device doesn't feature that new-fangled concept known as "multi-colour" shows that HUD technology is still in its infancy, although systems offered by some car manufacturers, such as BMW, do provide much better picture quality:

BMW's HUD provides a colour display, but how open is it? (Image © BMW, see link in text for source)

However, I can't see car manufacturers making it easy for aftermarket devices to access and control a factory-fitted HUD, and actually this is probably a good thing.  Although there are many safe and responsible ways in which an aftermarket device could utilise a HUD (as I describe below), there will always be some people who will want to drive and use a HUD for highly distracting things like watching a movie or checking their Facebook status.  If I were a car manufacturer I'd keep my HUD system firmly closed, thanks very much!  Sooner or later an aftermarket HUD will be made that accepts a video feed from an external device in some universal format, like HDMI, but until then discrete displays mounted somewhere in or around the dashboard will continue to be the norm for in-vehicle computers.

At this point it's probably worth explaining what can legally be displayed on a driver-visible screen.  In the UK this is covered by Section 109 of the Road Traffic (Construction and Use) regulations.   In summary, a driver-visible screen may only show information:

  • about the vehicle’s location or intended route
  • to help the driver see the road adjacent to the vehicle
  • about the state of the vehicle or its equipment

I have absolutely no legal qualifications whatsoever, so I don't pretend to have any authority on this subject.  However, I'm fairly confident in saying that the following are all examples of completely legitimate uses of a driver-visible screen:

  • Sat-nav software
  • Live footage from a vehicle-mounted camera
  • Software that shows information about any specialist equipment (e.g. the gritting equipment on a highways maintenance vehicle)

Obviously there are many applications that in-vehicle computers are used for which result in information being shown on-screen that is not suitable for the driver to view while driving.  But the in-vehicle computer will often have been installed specifically to give the driver access to this information at the appropriate time (i.e. when stationary), so what can be done to make sure that the system is completely safe and legal?

The most simple and obvious solution is to install the screen such that it can't be viewed by the driver.  This is perfect for situations where the computer is operated by a passenger, but more often than not the system will need to be used by the driver for at least some of the time. 

The next best thing would be the old-fashioned approach of turning the display off as soon as the vehicle starts moving.  The installer simply needs to find a live feed or a ground that is only active when the vehicle is stationery (the parking brake warning light circuit being the classic example), and use this to either power the screen directly if appropriate, or switch a relay if the circuit cannot provide enough current for the display.  Or, if the only motion-dependent feed that can be found is live only when the vehicle moves, a change-over relay can "reverse" its behaviour.  Finding such feeds is getting increasingly difficult in modern vehicles, but fortunately there are numerous CAN-bus adapters on the market that connect to the CAN network and provide the required feed.  Alternatively a similar result can be achieved using a software solution that blanks the screen when it detects movement – normally either via the PC's built-in GPS receiver or its connection with the vehicle's CAN network.

But what if the screen is showing content that needs to be visible even when moving, such as navigation information?   Of course, as long as the on-screen content is allowable under Regulation 109 then all the driver has to do is make sure that this content fills the screen before they start driving.  This may well be sufficient for many fleets, but it does rely on the drivers adhering to common sense and not doing anything dangerous – an assumption that can't always be taken for granted, even though it would be the driver (not the employer, vehicle owner, installer or supplier) who would be breaking the law.  Organisations may therefore wish to go a step further, and take steps to actively manage the content of the driver's screen.

One option would be to prevent the PC from being controlled while the vehicle is moving by disabling the touchscreen.  We implemented a hardware solution like this some years ago by manufacturing a "USB disconnection box" which was connected in line with the touchscreen's USB cable, and effectively unplugged the USB cable in response to a 12V feed.

Some years ago we produced this USB Disconnection Box to prevent the driver's touchscreen from being used while driving, but software can now achieve the same thing.

Again, there is now software that can do the same thing, triggered either by GPS movement or CAN-bus information, but even so this is a fairly unsophisticated approach, as it prevents the computer from being used to run legitimate driver-visible software that may require occasional interaction while the vehicle is moving.

There are now much better software solutions available, which enforce various policies when movement is detected, and actively manage what applications can be displayed on-screen.  One solution that I've come across is from Blank-IT, and comprises both a small piece of hardware (a USB dongle which detects movement) and software.  The software allows a list of nominated programs to be created, to which access is allowed while the vehicle is moving, but access to other programs is blocked.  For web-based applications the Blank-IT browser can be used, which only allows access to nominated websites.  Blank-IT keeps a log which can be used to confirm the state of the screen at any given time – potentially very useful in the event of an accident.

The Blank-IT software can be configured to allow only specific applications to be used. (Image © Expedio)

Unlike some other anti-distraction software solutions, Blank-IT determines whether or not the vehicle is moving via a supplied USB dongle (pictured below) which contains a motion sensor.  This means that the solution does not depend on the PC having built-in GPS or a CAN-bus interface.  Blank-IT argue that this is a better approach than relying on GPS data, as GPS signals can be distorted or jammed.  I'm not overly convinced by this – the GPS modules we use include anti-jamming and optional dead-reckoning technologies, and if the GPS antenna is roof-mounted it's not exactly trivial for a rogue driver to deliberately disable it.  The vast majority of the PCs we build include GPS modules anyway, so I do think it's a shame that an extra piece of hardware is needed in order to utilise Blank-IT's software when the facility to detect movement via GPS could, I'm sure, have been included very easily.

The Blank-IT solution requires the use of a USB dongle containing a motion sensor. (Image © Expedio)

Even so, Blank-IT's solution strikes me as the best one I've come across.  I'm always keen to hear what other people think – does this look like a good solution for your customers or fleet?  Or maybe there's an even better solution that I haven't come across.  Feel free to drop me an email or phone on the number above.  If there's interest then we'll probably look at stocking the Blank-IT solution and offering the USB dongle mounted securely inside the PC chassis, for the sake of neatness and robustness, and to prevent it from being removed.

Update: We now offer the Blank-IT solution, which does now support motion detection via GPS.