GENIVI assesses driver distraction and builds on location data

At the 2014 Automotive Linux Summit (ALS) in Tokyo, the GENIVI Alliance showcased several new open-source software projects that are slated to make their way into future in-vehicle systems. They included a framework for tracking driver attention (and, consequently, distraction level) and several new location-based services. For those who do not pay close attention to the automotive software field, these new efforts represent some of the first efforts that push open-source software past the existing, relatively predictable confines of navigation or entertainment—and into more experimental territory.

Driver workload management

Yusuke Nakamura from Denso Corporation presented a session about Driver Workload Assessor (DWA), GENIVI's new open-source framework to track the attention of a driver and adjust the behavior of the in-vehicle infotainment (IVI) system accordingly. The need for such a system is well-known, he said; the vehicle is an increasingly complex environment, and society is more and more concerned that driver distraction will result in accidents. He pointed to several studies about the increase in distraction-related crashes, noting that there is a rising trend of distractions from integrated devices—which, as opposed to accidents involving cell phones and other portable devices, is something GENIVI can address directly.

On the flip side, he pointed out, drivers expect and even demand continual access to their information systems; consequently GENIVI's challenge is to not simply keep information away from the driver, but to design a human-machine interface (HMI) system that lets drivers focus on driving when it requires high attention, but adapts to not dissatisfy them on the straight, low-traffic stretches of road when the attention level required drops.

The "smart" solution is to monitor and manage the driver's "workload"—roughly defined as the number and intensity of physical, visual, and cognitive tasks the driver is engaged in. This is a broader definition than "driver distraction," he said; "distraction" is what happens when the workload exceeds the driver's capacity. Even so, some distractions are unhelpful (such as text messages), while other are beneficial (such as alerts and warnings).

The naive approach to managing driver workload, Nakamura said, is to consider only two states: stopped and in-motion. Such an IVI system might simply disable all user input and notifications while in motion, and allow everything when stopped. But this ignores the fact that driver workload goes up and down according to the driving task. DWA defines some middle states in between the naive "all" and "nothing" options; the current version essentially has three in-between states, for "low," "medium," and "high" levels of driver workload.

The plan is that the IVI system would respond to the current workload level by allowing or suppressing input and output. Either individual applications could monitor the current workload level, or a management process could broker API requests, restricting or delaying them when the driver is overly occupied. GENIVI's current approach is to have a "workload manager" process handle the brokering of other applications.

The trick, in either case, is that "driver workload" is fundamentally a cognitive concept. As a result, Nakamura said, software cannot measure it directly. But it can be at least partially inferred from car and environmental conditions. DWA tracks a number of vehicle system states to approximate how busy the driver is: whether the speed is constant, accelerating, or braking, whether the steering wheel is turned, whether the windshield wipers are engaged, and so on. Changes in each of these conditions increment or decrement the current driver workload level—if the driver brakes suddenly and turns the steering wheel, then clearly driving requires more attention at the moment. If a notification comes in at just such a time—for example, an incoming call on the phone paired via Bluetooth—then the workload manager might suppress the phone ringer until the steering wheel straightens out and speed returns to a constant.

Such basic vehicle states are already measured by most modern cars' diagnostic buses. Nakamura demonstrated DWA with a dummy app, in which he could change the simulated vehicle speed and change the steering angle, and DWA would suppress output messages from the dummy app in response. But there are other factors that could also be used to contribute to the driver-workload estimate in the future, he said, including rain sensors, other environmental factors, and even messages from nearby vehicles or infrastructure. There is clearly a lot more to be done, but the benefits are an IVI system that is considerably more responsive to changing conditions than the simplistic all-on/all-off design in use today.

Location-based services

Philippe Colliot of Peugeot Citroën presented the recent work of GENIVI's Location-based services (LBS) expert group, which includes developing several API standards and a demonstration app for GENIVI-compliant IVI systems. The APIs represent the next level up from generic geolocation information, and are intended to let application developers create more complex services. The demo app is called Fuel Stop Advisor, and it represents one example use case: it builds on geolocation, point-of-interest (POI) data, and vehicle status to recommend the best times to stop and refuel.

The LBS group is working on a set of APIs that work in conjunction with the W3C Geolocation API. At present there are four. The Navigation Core API [PDF] (currently at version 3.0) provides a way requesting routing between destinations, including multiple transportation types, breaking the route into segments, and getting "guidance" instructions that can be used as turn-by-turn directions. The Positioning API [PDF] provides dead reckoning, taking gyroscope and compass sensor readings and establishing the vehicle's orientation and motion—so that its position can be tracked on a map even when GPS lock is lost. It is currently at version 2.0.

The Point-of-Interest (POI) Service API [PDF] is designed to serve as a bridge between a POI database and any of several applications that might request POI information. For example, a map application might simply need to display all of the POIs in a rectangular region, while a search application might request all of the POIs in some category (e.g., restaurants) within a given radius of the current position or some other specified location. The POI Service API was recently declared 1.0.

The fourth API is a traffic information API. Colliot explained that GENIVI was attempting to "not reinvent the wheel" where possible, which led to the Traffic API being developed jointly with the European Transport Protocol Experts Group (TPEG), an existing standardization project. Colliot said that the Traffic API had also recently been declared 1.0, although it does not seem to be published on the LBS Git repository.

There are still other areas where the LBS is working on additional specifications, Colliot said, including a Log Replayer API that will allow for easier application testing by playing back position and sensor data. But the group is also working on submitting its APIs to the W3C in the hopes of getting them approved as standards. The Navigation Core API has been submitted, he said, and there are already pending changes in the works based on feedback from navigation services.

Apart from writing specifications, the LBS group has also developed its first open-source app, Fuel Stop Advisor (FSA), "to show people that it is fun to write GENIVI apps." FSA uses the Navit routing engine and Open Street Map (OSM) data. It requires that the car have an active navigation route, and calculates whether or not the current fuel level is enough to get to the destination without stopping. If there is not enough, it recommends alternate routes to stop and refuel along the way.

Colliot showed a demonstration of FSA on his laptop. The user interface is "proof of concept"-level, he said, so it does not look like a finished product. But work continues; the next steps are to port the interface to Qt 5, port the graphics to use GENIVI's Layer Manager (which allows it to be composited with other running applications), and to add the ability to search for refueling stations from additional POI providers.

FSA represents new ground for GENIVI in the sense that it is an end-user application, rather than a base layer. As Colliot indicated in his talk, GENIVI is not changing its mandate—it still targets a middleware layer of software that carmakers do not want to individually reimplement. But it is progress to see that the middleware has gotten to a point where usable applications can be developed.

GENIVI's community manager Jeremiah Foster also gave a talk, in which he pointed to other projects that are reaching the point where application developers can use them. There is an IVI radio service, for example, that can handle AM, FM, and a variety of digital broadcast standards, and a speech output framework that can be used for anything from turn-by-turn directions to reading text alerts out loud.

The Media Manager project, on which GENIVI is collaborating with Automotive Grade Linux, should have a release ready by October. The goal is an API for connecting to consumer electronics devices for media playback; Foster noted that the team started with the Media Player Remote Interfacing Specification (MPRIS) and has worked with developers from several existing open source projects (like VLC) to make sure that Media Manager meets their needs as well.

Foster ended his session by asking the audience to get involved in the effort; GENIVI wants to know "what is currently missing." As the other GENIVI talks suggested, the project is reaching the point where several of the low-level tasks it has been focusing on are essentially complete, an attention now turns to more user-visible software.

[The author would like to thank The Linux Foundation for travel assistance to attend ALS 2014.]