If you jump to the end of this post, you’ll find a list of use cases being targeted by this effort. For now, let’s look at Use Case 2, Scenario A (arbitration of external message), which illustrates how we are working towards a comprehensive framework for managing distraction and workload.
Keeping priorities straight
In this user scenario, a navigation maneuver is given priority over a social media status update message. The blue call-out boxes indicate where the ITU-T recommendations under development can enable safe interaction between the driver and applications. For instance, ITU-T recommendation G.SAM will define mechanisms for prioritizing navigation, while G.V2A will define the communications interface between the app and the driver-vehicle interface (DVI), and P.UIA will recommend characteristics of the auditory social media message.
Remember that the focus here isn't on how to implement social media in the car, but rather, on how best to manage workload and distraction.
Giving a navigation maneuver priority over a social media status update message
Often, I am asked how this effort differs from the MirrorLink standard being developed by the Car Connectivity Consortium. The simple answer is that MirrorLink addresses only some of the use cases listed below. For instance, the scope of MirrorLink is limited to applications and services running on nomadic devices. Furthermore, adaptation of the driver-vehicle interface and external applications and services in the current MirrorLink solution uses a simple two-state approach, driving or not driving, which limits the ability of the vehicle to control the timing and modality of communications with the driver. Also, MirrorLink doesn’t adequately address arbitration or integration of communications with all external applications and services.
In for the long haul
At QNX Software Systems, our aim is to:
- Work with the relevant parties to identify solutions to the problem of technology-related driver distraction and workload. These parties include automotive, telecommunications, and consumer electronics organizations; standards development groups; academia; and government agencies.
- Determine which aspects of the solution should be standardized, then help drive this standardization.
- Align QNX product roadmaps as solutions develop.
The end of the beginning
The first major milestone in this effort was achieved at the closing plenary of the ITU-T Study Group 12 meeting, held on March 28 in Geneva. Here, the final report and 4 deliverables of the ITU-T Focus Group on Driver Distraction were approved. There was also approval of a liaison statement communicating these results to a large list of organizations working on this topic.
This marks the end of the focus group, but is really just the beginning for QNX and ITU-T efforts in this area. In future posts, I will explore various aspects of this comprehensive strategy.
Use cases and user scenarios targeted by ITU-T recommendations
Use Case 1: Interaction with external application/service
a) Application on nomadic device
b) Application on cloud-based server
c) Downloaded Application
d) Broadcast of roadway information
e) Tethering
Use Case 2: Arbitration and integration of external message
a) Arbitration of messages
b) Integration of messages
c) Both arbitration and integration of messages
d) E-call
Use Case 3: Negotiation of network Quality of Service (QoS)
a) Application selects network
b) Application suspends interaction
c) Application availability due to roaming
Use Case 4: Management of multiple dialogues
a) Opening/closing an application
b) Switching between applications
c) Interaction with background application
Use Case 5: Adaptation of DVI (driver-vehicle interface) and external applications/services to driver abilities
a) Driver with disability
b) Dynamically changing driver capabilities
c) Detection of impaired driver state
Use Case 6: Adaptation of DVI and external applications/services to roadway situation
a) Driver busy notification
b) Delay of message delivery in demanding driving situation
c) Change message format based on road conditions
d) Interruption of driver interaction
Use Case 7: Adaptation of DVI and external applications/services to vehicle status
a) Vehicle enters safe operating condition (e.g., park gear, < 5 m.p.h., etc.)
b) Driver adjusts vehicle controls (e.g., climate control, etc.)
c) Suppression of hazard alert due to safe speed
Use Case 8: Adaptation of DVI and external applications/services to local regulations
a) Application blocked
b) Application suspended
c) Interface modality disabled
d) Age restriction
e) Content restriction
For details on these use cases, download the FG Distraction Use Cases report.
