Speech interfaces: UI revolution or intelligent evolution?

Speech interfaces have received a lot of attention recently, especially with the marketing blitz for Siri, the new speech interface for the iPhone.

After watching some of the TV commercials you might conclude that you can simply talk to your phone as if it were your friend, and it will figure out what you want. For example, in one scenario the actor asks the phone, “Do I need a raincoat?”, and the phone responds with weather information.

A colleague commented that if he wanted weather information he would just ask for it. As in “What is the weather going to be like in Seattle?” or “Is it going to rain in Seattle?”.

Without more conversational context, if a friend were to ask me, “Do I need a raincoat?”, I would probably respond, “I don’t know, do you?” — jokingly, of course.

Evo or revo?

Are we ready to converse
with our phones and cars?

Kidding aside, systems like Siri raise an important question: Are we about to see a paradigm shift in user interfaces?

Possibly. But I think it will be more of a UI evolution than a UI revolution. In other words, speech interfaces will play a bigger role in UI designs, but that doesn't mean you're about to start talking to your phone — or any other device — as if it’s your best friend.

Currently, speech interfaces are underutilized. The reasons for this aren't yet clear, though they seem to encompass both technical and user issues. Traditionally, speech recognition accuracy rates have been less than perfect. Poor user interface design (for instance, reprompting strategies) has contributed to the overall problem and to increased user frustration.

Also, people simply aren't used to speech interfaces. For example, many phones support voice-dialing, yet most people don't use this feature. And user interface designers seem reluctant to leverage speech interfaces, possibly because of the additional cost and complexity, lack of awareness, or some other reason.


"Relying heavily on speech can lead
to a suboptimal user experience..."
As a further complication, relying heavily on speech as an interface can lead to a suboptimal user experience. Speech interfaces pose some real challenges, including recognition accuracy rates, natural language understanding, error recovery dialogs, UI design, and testing. They aren't the flawless wonders that some marketers would lead you to believe.

Still, I believe there is a happy medium for leveraging speech interfaces as part of a multi-modal interface — one that uses speech as an interface where it makes sense. Some tasks are better suited for a speech interface, while others are not. For example, speech provides an ideal way to provide input to an application when you can capitalize on information stored in the user’s head. But it’s much less successful when dealing with large lists of unfamiliar items.

Talkin' to your ride
Other factors, besides Apple, are driving the growing role of speech interfaces — particularly in automotive. Speech interfaces can, for example, help address the issue of driver distraction. They allow drivers to keep their “eyes on the road and hands on the wheel,” to quote an oft-used phrase.

So, will we see a paradigm shift towards speech interfaces? It's unlikely. I'm hoping, though, that we'll see a UI evolution that makes better use of them.

Think of it more as a paradigm nudge than a paradigm shift.

---

Recommended reading

Situation Awareness: a Holistic Approach to the Driver Distraction Problem
Wideband Speech Communications for Automotive: the Good, the Bad, and the Ugly

 

AUTOMOBILE Pimp your ride with augmented reality — Part II

Last week, I introduced you to some cool examples of augmented reality, or AR, and stated that AR can help drivers deal with the burgeoning amount of information in the car.

Now that we’ve covered the basics, let’s look at some use-cases for both drivers and passengers. Remember, though, that these examples are just a taste — the possibilities for integrating AR into the car are virtually endless.


AR for the driver
When it comes to drivers, AR will focus on providing information while reducing distraction. Already, some vehicles use AR to overlay the vehicle trajectory onto a backup camera display, allowing the driver to gauge where the car is headed. Some luxury cars go one step further and overlay lane markings or hazards in the vehicle display.

Expect even more functionality in the future. In the case of a backup camera, the display might take advantage of 3D technology, allowing you to see, for example, that a skateboard is closer than the post you are backing towards. And then there is GM's prototype heads-up system, which, in dark or foggy conditions, can project lane edges onto the windshield or highlight people crossing the road up ahead:



AR can be extremely powerful while keeping distraction to a minimum. Take destination search, for example. You could issue the verbal command, “Take me to a Starbucks on my route. I want to see their cool AR cups”. The nav system could then overlay a subtle route guidance over the road with a small Starbucks logo that gets bigger as you approach your destination. The logo could then hover over the building when you arrive.

You'll no longer have to wonder if your destination is on the right or left, or if your nav system is correct when it says, “You have arrived at your destination.” The answer will be right in front of you.

AR for the passenger
So what about the passenger? Well, you could easily apply AR to side windows and allow passengers to learn more about the world around them, a la Wikitude. Take, for example, this recent video from Toyota, which represents one of the best examples of how AR could make long road trips less tedious and more enjoyable:

QNX acoustics technology shortlisted for 2015 embedded AWARD

Okay, first things first. I didn't get the capitalization wrong. The name of the award really is spelled that way. I thought it odd at first, but I'm getting used to it. And besides, who am I to complain? After all, I spend a good part of my life promoting a product whose name is spelled all uppercase, and... where was I? Oh yes, the award!

Every year, the folks who organize the embedded world Exhibition&Conference hold the embedded AWARDs, which honor the most innovative software, hardware, and tools for embedded developers. And this year, the competition judges selected QNX Acoustics for Active Noise Control as a finalist in the software category.

If you aren’t familiar with our ANC solution, allow me to provide an overview — which will also help explain why the embedded AWARD judges are so impressed.

Automakers need to reduce fuel consumption. And to do that, they employ techniques such as variable engine displacement and operating the engine at lower RPM. These techniques may save gas, but they also result in "boom" noise that permeates the car's interior and can lead to driver distraction. And who needs more distraction?

QNX Acoustics for Active Noise Control can integrate 

seamlessly into a vehicle's infotainment system.

To reduce this noise, automakers use ANC, which plays “anti-noise” (sound proportional but inverted to the offending engine tones) over the car's speakers. The problem is, existing ANC systems require dedicated hardware, which adds design complexity, not to mention significant Bill of Materials costs. And who needs more costs?

Enter QNX Acoustics for ANC. Rather than use dedicated hardware, QNX ANC provides a software library that can run on the existing DSP or CPU of the car's head unit or audio system. This approach not only reduces hardware costs, also enables better performance, faster development, and more design flexibility. I could go on, but I will let my colleague Tina Jeffrey provide the full skinny.

Did I mention? This wouldn’t be the first time QNX Software Systems is tapped for an embedded AWARD. It has won two so far, in 2006 and 2004, for innovations in multi-core and power-management technology. It was also a finalist in 2010, for its persistent publish/subscribe messaging. Here's to making it a hat trick.

AUTOMOBILE We showed you so

QNX has been building NFC functionality into concept cars since 2015. Now, with the advent of automotive-grade tags and chips, NFC may be coming to a dashboard near you.

Paul Leroux

Why does QNX transform vehicles like the Maserati QuattroPorte GTS, Mercedes-Benz CLA45, and Bentley Continental into technology concept cars? I can think of many reasons, but three stand out. First, the cars allow us to demonstrate the inherent flexibility and customizability of QNX technology. If you could put all of the cars side by side, you would quickly see that, while they all use the same QNX platform, each has a unique feature set and a distinctive look-and-feel — no two are alike. This flexibility is of immense importance to automakers, who, for reasons of market differentiation, need to deliver a unique brand experience in each marque or vehicle line. Alf Pollex, Head of Connected Car and Infotainment at Volkswagen, says it best: “the QNX platform... enables us to offer a full range of infotainment systems, from premium level to mass volume, using a single, proven software base.”

Second, the cars explore how thoughtful integration of new technologies can make driving easier, more enjoyable, and perhaps even a little safer. Case in point: the Maserati’s obstacle awareness display, which demonstrates how ADAS systems can aggregate data from ultrasonic and LiDAR sensors to help drivers become more aware of their surroundings. This display works much like a heads-up display, but instead of providing speed, RPM, or navigation information, it offers visual cues that help the driver gauge the direction and proximity of objects around the vehicle — pedestrians, for example.

Look ma, no menus: At 2015 CES, a QNX concept car

showcased how NFC can enable single-tap Bluetooth
phone pairing. Source CrackBerry.com

Third, the cars explore solutions that address real and immediate pain points. Take, for example, the pairing of Bluetooth phones. Many consumers find this task difficult and time-consuming; automakers, for their part, see it as a source of customer dissatisfaction. So, in 2015, we started to equip some of our concept cars with near field communication (NFC) technology that enables one-touch phone pairing. This pairing is as easy it sounds: you simply touch an NFC-enabled phone to an NFC tag embedded in the car’s console, and voilà, pairing with the car’s infotainment system happens automatically.

Prime timeNFC in the car holds much promise, but when, exactly, will it be ready for prime time? Pretty soon, as it turns out. In a recent article, “NFC looks to score big in cars,” Automotive Engineering International points to several vendors, including Broadcom, NXP, Melexis, Texas Instruments and ams AG, that have either announced or shipped automotive-grade NFC solutions. NXP, for example, expects that some of its NFC tags and chips will first go into production cars around 2016.

Mind you, NFC isn’t just for phone pairing. It can, for example, enable key-fob applications that allow phones to store user preferences for seat positions and radio stations. It can also enable use cases in which multiple drivers operate the same vehicle, such as car sharing or fleet management. The important thing is, it’s moving from concept to production, marking one more step in the seamless integration of cars and smartphones.

---

Did you know…

• BMW embeds NFC tags not only in its cars, but also in print ads.

• IHS has predicted that, in 2018, global shipments of NFC-equipped cellphones will reach 1.2 billion units.

• NFC World publishes a living document that lists all of the NFC handsets available worldwide.

Report from CTIA Wireless: Apps in the Car

You wouldn’t think that CTIA Wireless, a mobile show, would be a good venue for a car guy. But automotive journalist Doug Newcomb put together a set of panels that managed to attract everyone from the automotive industry who attended the show.

I met a good number of friends from a variety of automakers, tier one suppliers, and hardware and software vendors. I also had the distinct pleasure of participating in one of Doug's panels, which was moderated by Damon Lavrinc of WIRED.

The topic was the future of apps in the car, and it generated a spirited discussion. Panel participants included Geoff Snyder from Pandora, Michelle Avary from Toyota, Henry Bzeih from Kia, and Scott Burnell from Ford — all experts on the topic.

Andy speaking on the

apps panel. Videos of all

the panels are now online.

In general, we agreed: apps are coming to the car. They have already arrived in several cases, and it’s only a matter of time before they come to mass-market vehicles. And apps are not for North American alone: it's a worldwide phenomenon.

Mind you, we engaged in lively debate on a number of questions: What role does the mobile app developer play? How to deal with the fragmentation caused by different OEM app platforms? How to deal with driver distraction? And when will the "one man app" ever make it into the car? We all had good and varied opinions on these topics, and the session was very well received by the audience.

Derek Kuhn, QNX vice president of sales and marketing, also participated in a panel session, titled "Can we all just get along… for the consumer's sake?". That panel focused on how the industry as a whole can create a more seamless experience for the consumer. Derek's co-panelists included Mark Harland from GM, Leo McCloskey from Airbiquity, Brian Radloff from Nuance, and Niall Berkery from Telenav.

Did I mention? Videos of all the panels are now on Doug Newcomb's website — check them out!
 

AUTOMOBILE Reducing driver distraction with ICTs

Inappropriate use of information and communication technologies (ICTs), especially mobile phones, is a chief culprit behind driver distraction and road accidents, and with automobile manufacturers scrambling to develop a “connected” driving experience, the ICT and automotive industries are becoming ever more closely entwined.

However, this integration of cars and ICTs need not come at the expense of driver safety, and there are strong grounds on which to argue that ICTs have great potential to enhance rather than diminish vehicle safety systems.

Under the banner of intelligent transport systems (ITS) the automotive and ICT communities are working towards a convergence of automobiles and ICTs that prioritizes drivers’ safety and broad consensus has it that international standards are the tools through which this will be achieved.

Over the past two years, as chairman of the ITU-T Focus Group on Driver Distraction, I have had the pleasure of leading a group tasked with laying the foundations for driver-distraction standardization work in ITU’s Telecommunication Standardization Sector (ITU-T).

Established in February 2015, the Focus Group reached the end of its study period in March 2015 and has been instrumental in raising awareness around ITU-T activity on driver distraction and the scale of this workload, as well as in providing clear direction to ITU-T’s driver-distraction work plan. The group has also been successful in opening lines of communication with key organizations and drawing new expertise into the ITU-T standardization process.

The Focus Group’s final deliverables take the form of five technical reports that describe:

• use cases and user interface requirements for automotive applications 
• system capabilities for improving the safety of driver interaction with applications and services (situational awareness management) 
• approaches that enable external applications to communicate with a vehicle

The reports are freely available here.

The conclusions put forward by the reports are being taken up by the two groups leading ITU-T’s standardization work on driver distraction, Study Group 12 (Performance, QoS and QoE) and Study Group 16 (Multimedia). New related work items calling for external coordination and collaboration may also be addressed by the Collaboration on ITS Communication Standards, a forum working to create an internationally harmonized set of ITS communication standards to enable the deployment of fully interoperable ITS products and services in the global marketplace.

Safe interaction with applications and services
The Focus Group’s work is just the beginning of an international standards effort to help drivers interact safely with applications and services — and not just apps on phones, but apps running in the cloud, in roadside infrastructure systems, and in the car itself, to name just a few locations.

The Focus Group’s Use Cases report details the use cases and user scenarios being targeted by this standards effort, but for now let’s look at Use Case 2, Scenario A (arbitration of external message), which illustrates how ITU-T is 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, 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 is not 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

In for the long haul
Speaking from our perspective at QNX Software Systems, a subsidiary of BlackBerry, the work of the Focus Group marks the beginning of a long road ahead. Within ITU-T, QNX will continue to:

1. 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.
2. Determine which aspects of the solution should be standardized, and help drive this standardization.
3. Align QNX product roadmaps as solutions develop.

Certainly this is a long-term strategy that will take years to realize, factoring in the rigour of ITU-T’s standards process as well as the significant amount of time needed to deploy technologies in vehicles on a meaningful scale.

Join the discussion
A workshop hosted by ITU and UNECE at ITU headquarters in Geneva, 27 June 2015, will address “Intelligent transport systems in emerging markets – drivers for safe and sustainable growth” with a view to analyzing recent advances in ITS with emphasis on improving road safety in developing countries.

This workshop includes a session dedicated to driver distraction in which I will present the outcomes outlined by the Focus Group’s technical reports to spur discussion on the likely course of corresponding ITU-T standardization work.

The workshop is free of charge and open to all interested parties, including non-members of ITU, and online ‘remote participation’ will be available to all those unable to travel to Geneva. Please join us for what will certainly be a richly informative and interactive event!

This post originally appeared on the ITU Blog.

AUTOMOBILE More QNX-powered cars and infotainment systems from 2015 CES

The second installment in our CES Cars of Fame series. Today, we look at several systems from the 2015 CES event, starting with this week's inductee, a BMW Z4.

Paul Leroux

I've led you astray — sort of. Last week I stated that the LTE Connected Car, the first QNX-powered technology concept car, appeared at 2015 CES. But I didn't mention that QNX technology was at the core of several other innovative vehicles and infotainment systems at CES that year.

So let me set the record straight. And the best place to start is the QNX booth at 2015 CES, where a BMW Z4 roadster was the front-and-center attraction.

BMW Z4 Roadster with ConnectedDrive
The Z4 wasn't a technology concept car, but a true production car straight off the dealer lot. It was equipped with the QNX-based BMW ConnectedDrive system, which offers real-time traffic information, automatic emergency calling, and a text-to-speech feature that can read aloud emails, appointments, text messages, and other information from Bluetooth smartphones. It's a cool system right at home in this equally cool cockpit:



Heck, the whole car was cool, from the wheels up:



Audi A8 with Google Earth
Mind you, the coolness didn't stop at the QNX booth. Just down the hall, Audi showcased an A8 sedan equipped with the QNX-based 3G MMI infotainment system, featuring Google Earth. This same model drove home with the 2015 Edmunds Breakthrough Technology award a short while later.

I don't have any photos of the Audi from the CES show floor, but if you head over to the On Q blog, you can see some snaps from an automotive event that QNX hosted in Stuttgart two months earlier. The photos highlight the A8's innovative touchpad, which lets you input destination names by tracing them with your finger.

Toyota Entune infotainment system
And now to another award-winning QNX-based system. Toyota Entune embraces a simple, yet hard-to-achieve concept: help drivers interact with mobile content and applications in a non-distracting, handsfree fashion. For instance, if you are searching for a nearby restaurant, Entune lets you ask for it in a conversational fashion; no need for specific voice commands.

You could tell the judges for the CNET Best of CES awards were impressed, because they awarded Entune first prize, in the Car Tech category — the first of three QNX-powered systems to do. QNX Software Systems went on to win in 2015 for its QNX CAR Platform and then Chevy won in 2015 for its MyLink system. Not too shabby.

A cluster of clusters
We've looked at just three of the many QNX-based automotive systems showcased at 2015 CES. For instance, QNX also demonstrated digital instrument clusters built by Visteon for the Land Rover Range Rover and for the Jaguar XJ sedan, below:



Freescale, NVIDIA, TeleNav, and Texas Instruments also got into the act, demonstrating QNX systems in their booths and meeting areas.

Do you have any memories of 2015 CES? I'd love to hear them.

New to 26262? Have I got a primer for you

Driver error is the #1 problem on our roads — and has been since 1869. In August of that year, a scientist named Mary Ward became the first person to die in an automobile accident, after being thrown from a steam-powered car. Driver error was a factor in Mary’s death and, 145 years later, it remains a problem, contributing to roughly 90% of motor vehicle crashes.

Can ADAS systems mitigate driver error and reduce traffic deaths? The evidence suggests that, yes, they help prevent accidents. That said, ADAS systems can themselves cause harm, if they malfunction. Imagine, for example, an adaptive cruise control system that underestimates the distance of a car up ahead. Which raises the question: how can you trust the safety claims for an ADAS system? And how do you establish that the evidence for those claims is sufficient?

Enter ISO 26262. This standard, introduced in 2015, provides a comprehensive framework for validating the functional safety claims of ADAS systems, digital instrument clusters, and other electrical or electronic systems in production passenger vehicles.

ISO 26262 isn’t for the faint of heart. It’s a rigorous, 10-part standard that recommends tools, techniques, and methodologies for the entire development cycle, from specification to decommissioning. In fact, to develop a deep understanding of 26262 you must first become versed in another standard, IEC 61508, which forms the basis of 26262.

ISO 26262 starts from the premise that no system is 100% safe. Consequently, the system designer must perform a hazard and risk analysis to identify the safety requirements and residual risks of the system being developed. The outcome of that analysis determines the Automotive Safety Integrity Level (ASIL) of the system, as defined by 26262. ASILs range from A to D, where A represents the lowest degree of hazard and D, the highest. The higher the ASIL, the greater the degree of rigor that must be applied to assure the system avoids residual risk.

Having determined the risks (and the ASIL) , the system designer selects an appropriate architecture. The designer must also validate that architecture, using tools and techniques that 26262 either recommends or highly recommends. If the designer believes that a recommended tool or technique isn’t appropriate to the project, he or she must provide a solid rationale for the decision, and must justify why the technique actually used is as good or better than that recommended by 26262.

The designer must also prepare a safety case. True to its name, this document presents the case that the system is sufficiently safe for its intended application and environment. It comprises three main components: 1) a clear statement of what is claimed about the system, 2) the argument that the claim has been met, and 3) the evidence that supports the argument. The safety case should convince not only the 26262 auditor, but also the entire development team, the company’s executives, and, of course, the customer. Of course, no system is safe unless it is deployed and used correctly, so the system designer must also produce a safety manual that sets the constraints within which the product must be deployed.

Achieving 26262 compliance is a major undertaking. That said, any conscientious team working on a safety-critical project would probably apply most of the recommended techniques. The standard was created to ensure that safety isn’t treated as an afterthought during final testing, but as a matter of due diligence in every stage of development.

If you’re a system designer or implementer, where do you start? I would suggest “A Developer’s View of ISO 26262”, an article recently authored by my colleague Chris Hobbs and published in EE Times Automotive Europe. The article provides an introduction to the standard, based on experience of certifying software to ISO 26262, and covers key topics such as ASILs, recommended verification tools and techniques, the safety case, and confidence from use.

I also have two whitepapers that may prove useful: Architectures for ISO 26262 systems with multiple ASIL requirements, written by my colleague Yi Zheng, and Protecting software components from interference in an ISO 26262 system, written by Chris Hobbs and Yi Zheng.

AUTOMOBILE C3 recap: The future of the connected car

UPDATE: CE Week has uploaded audio and video of the C3 panels that Derek covers in this post. To hear what experts from companies like AT&T, BMW, Delphi, GM, and QNX see on the horizon for the connected car, visit the Connected Car Conference website — Ed.

Derek Kuhn

“Automotive has always been a wellspring of technology and innovation.” Those ten words, spoken by Doug Newcomb, car technology consultant and conference chair — and occasional QNX blog contributor — brought the Connected Car Conference (C3) to a successful close. The conference, co-located with CEA’s CE Week in New York City, featured panels on issues and trends for the connected car: big data, the future of radio, driver distraction, and more.

I was honored to sit on a panel that included executives from General Motors, AT&T Emerging Devices, and Audiovox, and that tackled the question on the minds of everyone in the industry: how can cars keep pace with consumer electronics? Traditionally, the speed of car development has trailed consumer devices, but with consumers looking at their cars as another connected gadget, the industry is working to bring technology into the car faster, while still providing a safe, reliable experience. As GM’s Tim Nixon put it, “we want to make the car better from the day you drive it off the lot.”

Striking a balance
Tim’s comment touches on something we frequently discuss — the significance of over-the-air (OTA) updates in ensuring that a car always has the latest technology. In fact, my colleague, Tina Jeffrey, just wrote a blog post on the topic; it's worth a read. Another point that came up is the need to balance security with consumers’ desire for cutting-edge technology. As I pointed out, not all infotainment systems are created equal — security shouldn’t be an afterthought in the pursuit of the latest and greatest tech. Rather, it should be deeply engrained in each step of the software development process. At the same time, consumer choice also has to be balanced with what OEMs are comfortable with.

Driving big data

John Quain of the NYT hosts the big data panel.
Photo: Doug Newcomb

John Quain of the New York Times hosted a panel on big data, which was full of insights on how data is being used to connect drivers and their cars. In response to the question, “how can big data in automotive save lives?” Delphi’s Doug Welk commented that, while data on crashes was abundant and readily available, data on near misses — which is even more important to understanding how to prevent accidents — is scant. Telenav’s Niall Berkey pointed out something that my colleague Andrew Poliak often discusses: the importance of the car as a sensor. For instance, by using information on how a driver is behaving, a car could activate assisted-driving technologies to reduce the likelihood of an accident.

Dealing with distraction
During the “Dealing with Driver Distraction” panel, representatives from the Auto Alliance of Automobile Manufacturers, Nuance, NVIDIA, and Pioneer spoke on how the industry is working to curb distraction. Gloria Bergquist of the Auto Alliance stated that the concern is nothing new; when car radios were first introduced in the middle of the last century, industry watchers claimed that drivers’ attention would be diverted by the novelty.

Gloria also drew from her organization’s recent report, which showed that most drivers overestimate how well they can handle distractions and think that it’s other drivers who can’t cope. Erik Clauson of Nuance discussed how voice recognition technologies — like the QNX intent framework — can play a large role in decreasing the cognitive load of drivers. Dave Anderson of NVIDIA defended skeumorphism — a design aesthetic that has received much criticism as of late — as a way to increase the intuitiveness of user interfaces and therefore decrease distraction. For example, digital instrument clusters that look like conventional (and familiar) analog instruments can enhance the driving experience.

Continuing the conversation
The day ended with a networking reception — a unique opportunity to pick the brains of the some of the industry’s thought leaders and observers. While I got to spend only a short time in New York for the event, I am look forward to next year when we can continue this conversation on the industry’s challenges and innovations.

AUTOMOBILE When will I get apps in my car?

I read the other day that Samsung’s TV application store has surpassed 10 million app downloads. That got me thinking: When will the 10 millionth app download occur in the auto industry as a whole? (Let’s not even consider 10 million apps for a single automaker.)

There’s been much talk about the car as the fourth screen in a person’s connected life, behind the TV, computer, and smartphone. The car rates so high because of the large amount of time people spend in it. While driving to work, you may want to listen to your personal flavor of news, listen to critical email through a safe, text-to-speech email reader, or get up to speed on your daily schedule. When returning home, you likely want to unwind by tapping into your favorite online music service. Given the current norm of using apps to access online content (even if the apps are a thin disguise for a web browser), this begs the question — when can I get apps in my car?

Entune takes a hands-free
approach to accessing apps.

A few automotive examples exist today, such as GM MyLink, Ford Sync, and Toyota Entune. But app deployment to vehicles is still in its infancy. What conditions, then, must exist for apps to flourish in cars? A few stand out:

Cars need to be upgradeable to accept new applications — This is a no-brainer. However, recognizing that the lifespan of a car is 10+ years, it would seem that a thin client application strategy is appropriate.

Established rules and best practices to reduce driver distraction — These must be made available to, and understood by, the development community. Remember that people drive cars at high speeds and cannot fiddle with unintuitive, hard-to-manipulate controls. Apps that consumers can use while driving will become the most popular. Apps that can be used only when the car is stopped will hold little appeal.

A large, unfragmented platform to attract a development community — Developers are more willing to create apps for a platform when they don't have to create multiple variants. That's why Apple maintains a consistent development environment and Google/Android tries to prevent fragmentation. Problem is, fragmentation could occur almost overnight in the automotive industry — imagine 10 different automakers with 10 different brands, each wanting a branded experience. To combat this, a common set of technologies for connected automotive application development (think web technologies) is essential. Current efforts to bring applications into cars all rely on proprietary SDKs, ensuring fragmentation.

Other barriers undoubtedly exist, but these are the most obvious.

By the way, don’t ask me for my prediction of when the 10 millionth app will ship in auto. There’s lots of work to be done first.

MirrorLink misunderstood: 8 myths that need busting

If you're new to MirrorLink, it's a technology that bridges the mobile phone and the car. It allows specially written apps running on the phone to be displayed on the car's head unit, where the user can interact with them.

MirrorLink is intended to extend the life of in-vehicle systems by allowing them to interact with mobile content and to support new features that didn’t exist when the car rolled off the assembly line.

Here's an illustration of how it works:


MirrorLink in-car communication. The protocol between the head unit and the phone can run over several transports, including USB, Bluetooth, or Wi-Fi. This example assumes Bluetooth for the audio back-channel.

When I talk to people in the automotive and mobile industries, I find they share a number of common misconceptions about MirrorLink, which I’d like to clear up. So let's get started, shall we?

1. MirrorLink is an Android technology. In fact, MirrorLink works with multiple mobile platforms. Phones using Android can support it, but so can phones from any other phone maker that supports the standard. Even Apple phones could support it, though Apple has currently chosen to go their own route with Apple-specific solutions.
   
   
2. MirrorLink allows any mobile app to run in the car. This is incorrect. A MirrorLink app can run in the car only if the car maker grants “trust” to that app. Each car maker has a different concept of what brands to promote, what features are safe, or what works well with each car. So, in reality, each app will be enabled depending on the individual make — or even model — of car.
   
   
3. MirrorLink promotes “driver distracting” apps. Also incorrect. MirrorLink is an enabling technology that doesn’t promote any type of app in particular. In fact, because the car maker must grant trust to an app, the app developer can't control what apps run in the car. That responsibility remains the domain of car makers, who tend to avoid anything that will cause distraction when displayed on a front-seat screen.
   
   
4. MirrorLink is the only way to connect an app to the car. There are in fact two others: iPod Out and HTML5. Apple supports iPod Out for Apple devices, which allows selected applications to output analog video to the head unit. (Note that the new iPhone 5 doesn’t support iPod Out.) HTML5 also allows mobile apps to run in the head unit, though its use in car-to-phone bridging is still in the early stages. QNX Software Systems has demonstrated concept vehicles that use BlackBerry Bridge (an HTML5-based technology) to connect an HTML5 app on a BlackBerry phone to the car’s head unit.
   
   
5. Mobile app makers will benefit most from MirrorLink. In fact, car makers may end up taking best advantage of the technology. That’s because they can use MirrorLink to customize and create apps, and to refresh those apps as a way of delivering fresh, new functions to their customers. MirrorLink gives them the ability to do this using a standardized protocol supported by most mobile platforms. Car makers could use MirrorLink very effectively, even if they never allowed any third party apps into their cars.
   
   
6. HTML5 and MirrorLink are incompatible. Not necessarily true. Current versions of MirrorLink use the VNC protocol to exchange graphical data. None of the advantages of HTML5 would be incompatible with a future version of MirrorLink; in fact, some members of the Connected Car Consortium (CCC), including QNX Software Systems, would likely be interested in merging these two standards. That would result in a new version of MirrorLink that uses HTML5 as the underlying communication protocol. (The MirrorLink specification is controlled by the Car Connectivity Consortium, of which QNX is a member.)
   
   Even if MirrorLink does go to HTML5, the industry would still need a VNC-based form of MirrorLink. VNC has much lighter requirements on the head-unit side, so it makes more sense than HTML5 if the car doesn’t have a high-powered CPU or lots of memory. The broadest possible option would be to have phone apps support multiple versions of MirrorLink (today's version with VNC plus a future version with HTML5) and to use whichever one makes sense, depending on what the car supports.
   
   
7. MirrorLink obviates the need for car-downloadable apps. Yes, MirrorLink capability is somewhat similar in purpose to downloading apps into the car; they both extend the functionality of the car after it leaves the factory. Because the customer’s phone will almost certainly be newer than the car’s electronics, it will have a faster CPU, giving the raw speed advantage to a MirrorLink app on the mobile. The MirrorLink app will also have guaranteed data access since the hosting phone will always have a data pipe — something that isn't certain on the car side of the equation.
   
   On the other hand, MirrorLink doesn’t give an app access to car features that would available to a car-downloaded app — features such as vehicle bus access, telematics features, or the navigation system. Also, a car-downloaded app would likely have a faster HMI than any off-board app, even if the mobile had a faster CPU, because of latencies inherent to screen replication. The car-downloaded app would also have better visual integration, as it could take full advantage of the car features, instead of appearing as a bolt-on product. Other factors, based on automaker control, compatibility, or product roadmaps could also favor an in-car solution. Even if you could address some of these issues, there would still be enough reasons for MirrorLink and an auto app store to live side-by-side.
   
   
8. MirrorLink apps can be built today. This is technically true. But, in their enthusiasm, new converts can sometimes forget that cars need to support MirrorLink for anything to actually work. Currently, only aftermarket car stereos support MirrorLink; no production vehicles support it. So if you’re a mobile app developer, the market for MirrorLink apps today is negligible. But expect this situation to improve dramatically over the next two to three years as production vehicles start to ship with this capability built-in.

Autonomous cars? Suddenly, I’m not so skeptical

Guest post from Emil Dautovic, European automotive business development manager for QNX Software Systems

As a driving enthusiast, I have always felt a bit skeptical about the notion of autonomous cars. The reason is simple: I actually enjoy driving and don’t want someone else to do it for me, in this case the car itself.

Recently, however, my skepticism has begun to soften. I am fascinated, for example, by the SARTRE road train project, where a lead vehicle takes responsibility for a platoon of semi-autonomous cars. Also, recent research from the U.S. Highway Loss Data Institute suggests that, when it comes to some driving tasks, ADAS systems can already put many human drivers to shame.

Autonomous drive will become especially important when today’s “always on” generation starts to buy cars in earnest. They will, no doubt, want to consume multimedia and interact through social media even while on the road, and automakers will need to accommodate them.

HMIs with more (and less) distraction
What would this mean for car makers? Among other things, the infotainment system in a self-driving car could offer an HMI mode that gives the driver more freedom to pay attention to non-driving activities. When the car subsequently needs a human driver (for instance, it becomes disconnected from a road train), the infotainment system could disable these features and immediately go back to a less distracting user interface.

Also, driver assist systems — such as those for detecting animals and pedestrians — would need to be integrated with the road train system to decide how to react when, say, a rabbit runs in front of the car. For instance, should the car brake and warn other cars of the fact, or would it be safer to simply keep driving? It will be interesting to follow this initiative and see how the technical and business aspects evolve, and how, for example, the owner of the lead vehicle will be paid.

For another interesting example of research into autonomous drive, check out the BRAiVE project led by the VisLab team at the University of Parma. The BRAiVE project uses a variety of sensors, with a focus on low-cost alternatives that could realistically integrated into in production cars.

Bells and whistles
So what kind of impact could all this have on a company providing automotive software platforms?

There will, I believe, be an increased demand for a platform that could run all of these applications, enabling the advanced use cases while ensuring that critical functions always have enough processor power. And, of course, the platform will have to be reliable. If this same platform could offer all the bells and whistles available in consumer electronics and demanded by younger drivers, the self-driving future might prove to be a bit closer than we think.

By the way, if you’re unfamiliar with the SARTRE road train project, check out this video:

---

More about Emil
Emil Dautovic is an automotive business development manager at QNX Software Systems, where he is responsible for the European automotive market. Prior to joining QNX, he worked as a business area manager for The Astonishing Tribe (TAT), where he built TAT's automotive business from scratch and helped transform the company into an important player in the automotive HMI field with leading automotive OEMs and tier ones. He has also worked at AU-System (later Teleca and Obigo), where he served as a consultant on GSM base station development and as a sales representative serving mobile phone OEMs and ODMs worldwide. Emil holds an M.Sc. in Electronic Engineering from Lunds Tekniska Högskola.

Distracted driving — the stats are alarming

I was driving to work the other day when I heard something on the radio that almost made me drop my smartphone. The Ontario Provincial Police (OPP) announced that, for the first time, deaths attributable to driver distraction outnumber those caused by impaired driving. So far this year, on roads patrolled by the OPP, distraction has led to 47 deaths, while impaired driving has led to 32.

This stat drives home the need for dramatically better head-unit integration of services that drivers would otherwise use their phones to access. This isn't anything new to QNX. We've been working with our partners to provide all the necessary elements to enable this integration through technologies such as HTML5, Qt, iPod out, MirrorLink, and Bluetooth. All these technologies can help create systems that minimize driver distraction but they represent only part of the solution. Pushing buttons on your head unit, combined with smart HMI design, does help, but it's not a panacea.

To truly help drivers keep their eyes on the road we have to minimize the time they spend looking at the infotainment display. Multi-modal HMIs built from the ground up with the assumption that high-quality speech recognition and text-to-speech are available will drastically change the way drivers interact with their infotainment systems. For instance, such HMIs could read your texts and emails aloud to you; they could even let you dictate responses at the appropriate time. But really, the possibilities are endless. And on the topic of talking to your car, we're constantly working with our partners to enrich the speech capabilities of the QNX CAR Platform. But more on that in an upcoming post.

By the way, I wasn't really using my smartphone while I was driving. That's illegal here. Not to mention incredibly dumb.

AUTOMOBILE Pimp your ride with augmented reality — Part I

The use of electronics is exploding in automotive. Just last week, Intel proclaimed that the connected car “is the third-fastest growing technological device, following smartphones and tablets.”

Ten years ago, you’d be hard-pressed to find a 32-bit processor in your car. Now, some cars have 4 or more 32 bitters: one in the radio, another in the telematics module, yet another in the center display, and still another in the rear-seat system.

Heck, in newer cars, you’ll even find one in the digital instrument cluster — the QNX-powered cluster in the Range Rover, for example. Expect to see a similar demand for more compute power in engine control units, drive-by-wire systems, and heads-up displays.


The Range Rover cluster displays virtual speedometers and gauges, as well as warnings, suspension settings, and other info, all on a dynamically configurable display.

What do most of these systems have in common? The need to process tons of information, from both inside and outside of the vehicle, and to present key elements of that data in a safe, contextually relevant, and easy-to-digest fashion.

The next generation of these systems will be built on the following principles:

• Fully integrated cockpits — Vehicle manufacturers see system consolidation as a way to cut costs and reduce complexity, as well as to share information between vehicle systems. For instance, your heads-up display could discreetly let you know who is calling you, without forcing you to take your eyes off of the road. And it could do this even if the smarts integrating your phone and your car reside in another cockpit component — the telematics module, say.
   
• Augmented reality — With all of the data being generated from phones, cloud content services and, perhaps more importantly, the vehicle itself, presenting the right information at the right time in a safe way will become a major challenge. This is where augmented reality comes in.

Augmented reality is a cool use of cameras, GPS, and data to create smart applications that overlay a virtual world on top of the real world. Here are some of my favorite examples:

AR Starbucks cups — Use your phone to make your coffee cup come alive:



AR Starwars — Blast the rebel alliance squirrels!



AR postage stamp — Add a new dimension (literally) to an everyday object:



And here are a couple more for good measure:

AR ray gun — Blast aliens around the house!

Wikitude AR web browser — Explore the world around you while overlaying social networks, images, video, reviews, statistics, etc.

Stay tuned for my next post, where I will explore how AR could enhance the driving experience for both drivers and passengers — Andrew.

AUTOMOBILE Crossing the boundaries: Cooperation across industries will fuel the connected car

A guest post by Brian Salisbury of Telecommunication Systems (TCS)

Connected car – these two words appear together more and more these days. Consider, for example, two events that took place in February: The Connected Car Executive Lunch organized by Fierce Wireless and held during the Mobile World Congress in Barcelona, and the Telecom Council’s Mobile Forum: Connected Car meeting hosted by Marvell Semiconductor in Silicon Valley.

Speakers at these events came from mobile operators (AT&T Mobility, Orange, Sprint, Verizon), auto manufacturers (Ford, Hyundai, Nissan, Toyota), and platform and solution providers (Nokia, Pioneer, QNX Software Systems, TCS). No doubt about it, the car is now connecting industries.

Although these two events were held on different continents, the topics on the minds of attendees were very similar:

• Who “owns” the customer?
• Will the connection be part of the car, or brought to the car by its driver?
• How can the “wild west” of the Internet be safely incorporated into the car?
• What is the business model for such a multi-part solution?
• What will be the “killer app” for connected car, or is there no such thing?

The presentations and discussions were diverse, as each group sought to define their role in terms that extend logically from their own past experience, and that could provide them with some control over the outcome. Thankfully, every group shared the common goal of making sure that connected cars are safe cars, and that the introduction of new connected services doesn’t create driver distraction problems.

We are clearly on the verge of a new generation of services being extended into the car that can enhance many aspects of owning, operating, and riding in tomorrow’s vehicles. Those of us fortunate enough to be part of one of these groups will have some amazing opportunities to bring the best of our respective industries into this new space, and to build new relationships across industry boundaries.

For an example of how TCS is helping to enable the connected car, check out this post on the VW Polo that was showcased at Mobile World Congress — Ed.

---

Here’s a little more about Brian and TCS:

Brian Salisbury is director of business development at TeleCommunication Systems, Inc. (TCS), where he is responsible for developing new business with OEMs, platform providers, and developers in the LBS ecosystem. Brian has worked in the mobile industry for more than 25 years, with most of that experience being in mobile data and location-based services, and within semiconductor, device manufacturer, and network operator companies.

TCS (NASDAQ: TSYS) is a world leader in highly reliable and secure mobile communication technology. TCS infrastructure forms the foundation for market leading solutions in E9-1-1, text messaging, commercial location and deployable wireless communications. TCS is at the forefront of new mobile cloud computing services providing wireless applications for navigation, hyper-local search, asset tracking, social applications and telematics.

AUTOMOBILE Find me a Starbucks! QNX concept car showcases power of WATSON speech engine

Yes, you can talk to the QNX concept car and tell it what to do.

Recently, our friends at AT&T invited us to bring the concept car to their "Living the Networked Life" event in New York. We said yes, of course! After all, what could be cooler than riding the streets of Gotham City in a digitally pimped-out Porsche 911?

Kidding aside, the event provided an excellent opportunity to demonstrate how the car takes advantage of WATSON, AT&T's natural-language speech engine. To get an idea of what WATSON can do, check out this video from Terrence O'Brien of Engadget:



For the full Engadget article, click here. And stay tuned for more updates from the Living the Networked Life event.

For safety’s sake, why don’t cars just disable phones?

With all the focus on driver distraction, this is a question that I get asked occasionally. It’s a simple question, with a less than simple answer.

Using technology to control inappropriate phone use has been a topic at some of the driver distraction meetings I've attended. One proposed solution involves a technique called micro location — using ultrasonic waves to identify where in the cabin the phone is located. There are other ways to triangulate the phone's position, but they all require coordination between the phone and car. Knowing where the phone resides in the car is a requirement, as most passengers wouldn’t be happy to have their phone automatically disabled, just because they’re in the car. And the solution can’t be based only on the GPS speed of the phone, or you’d have lots of irate bus, taxi, train, or subway riders.

The fact is, unless all phone makers and car makers agree on the same standard, there's no incentive for either side to build half of a feature. You’d need to deploy potentially expensive technology that wouldn’t work unless you pair exactly the right phone with the right car. This likely won't happen unless companies are legislated to do so.

Given the speed of automotive development, it’s impossible for the car guys to build a technology that the phone guys won't leave in the dust, unless some guarantees are put in place. The adoption of Bluetooth is a good example. It took years before Bluetooth became widespread in phones, but its adoption had more to do with Bluetooth earpieces, not connections to cars. Car makers took a long time to roll out Bluetooth support as a standard feature because too many phones either didn't have it or had an implementation that wasn't fully compatible. Eventually, the two markets synchronized, but it took several years.

One argument against a technology-mandated disable is that not all jurisdictions agree on what is, or isn’t, allowable. In the US, 45 out of 50 states have some form of prohibition against using phones in cars. But what is disallowed varies widely by state — some don't allow any use of the phone (even hands-free), some prohibit teenagers but no other age groups, some disallow texting but not hands-free, some disallow use for commercial vehicles but not private vehicles, and some allow everything.

Another argument against a technological solution is that people can be educated to assume responsibility for their behavior. For example, why don't all cars have a blood alcohol level blow-tester hooked up to the ignition? Technically it's possible, but it's very expensive to do it from the car maker's standpoint. One could argue that it is worth it to have cars protect us from ourselves. But as a society, we've decided that, in the case of drunk driving, we are willing to give people back the responsibility. Rather than control the problem with technology, we socialize and educate people that driving intoxicated is an undesirable behavior.

We could, of course, decide to do the same with mobile technology, by educating personally instead of solving technically. This approach may make more sense than a technology-based prohibition: technology always moves at light speed compared to legislative mechanisms of control.
 

AUTOMOBILE Am I crazy for talking to my car?

Earlier this afternoon, I participated in a connected car panel at SpeechTEK 2015, hosted by our friend Mazin Gilbert from AT&T. The other panelists included Greg Bielby of VoltDelta, Thomas Schalk of Agero, and Hakan Kostepen of Panasonic.

Even though Mazin did a fantastic job, not every panelist had a chance to answer every question. I was itching to answer some, so here are my responses to the questions that I didn't get to answer, or where I feel I could have provided a more complete response.

Have speech technologies matured to the point where they can be used robustly in the car? The general answer to this question from the panel was yes, but I think the real answer is a qualified yes. The technologies exist, but often aren't applied or may need auto-specific adaptations to handle in-cabin noise or other issues. Natural language recognition was an oft-stated driving technology, but a missing piece to the puzzle is hybrid recognition. I don't mean pushing recognition wholesale to the cloud, like Siri does. I mean a true split of the recognition effort, where each part does what it’s best at. Put the front half of acoustic processing in the vehicle to clean up the audio and convert the waveform to frequency-domain data, then send the data to the cloud-based server. The cloud server can then parse and interpret the data, and send back the result.

Hybrid speech rec solves three problems at once: better audio signals (the car can improve audio specific to the in-cabin environment), better cost (frequency data is far more compressed than raw audio, so you pay less for data transfer), and better responsiveness (hybrid rec gives the server time to start working on the response while it's coming in instead of waiting for the whole utterance to finish before starting).

Is driver distraction a major business driver, or is it the "Siri effect"? Currently, the car industry seems to use driver distraction as a reason to push a lot of features into speech. Many of those uses are gimmicky. Personally, I don't care if I can set my climate control system with voice — why would I when I can simply turn a dial? I once had someone ask me about the feasibility of adding voice recognition commands for rolling down the windows. I asked him, "Yes, but wouldn't people just push the window button?"

We shouldn’t implement speech commands just because we can. They may have contributed to excitement in the early adopter crowd, but we're beyond that now. Mind you, there are some seriously useful ways to use voice. For instance, any time you need to pick from a huge number of choices, voice recognition is the natural way to go. Calling contacts ("Call Sarah Potter"), entering destinations ("Go to 3121 South Park Street"), or picking music ("Play Audioslave") are all much easier than using an HMI to enter the same information, and safer to boot. It just has to work consistently and accurately.

Will car makers see more speech moving to the cloud, or will it be a hybrid of cloud and embedded? I disagree with the majority of the panel on this one, and, I think, the majority of people in the industry. Most auto people believe a hybrid between embedded and cloud allows the best of both worlds — good recognition and updatability when connected, and consistent reliability when not. My colleague Andrew Poliak also champions this view with a memorable catch phrase: Zombie Apocalypse. That is, you still want the system to work, albeit partially, when the infrastructure isn't available.

But if you ask me, everyone is missing the point — theirs is a technology-centric point of view. Everyday customer acceptance of a particular technology is notoriously harsh: if it doesn't work well, it gets rejected out of hand. Good cloud solutions beat an embedded solution hands-down; they just need some improvements (see my hybrid bullet above). Once a customer experiences a good solution, they will become frustrated with one that performs poorly. In my opinion, it's better not to offer the service at all, than to try a graceful degradation of capability, because most customers won't understand or care. Spend the effort instead on making sure you always have an acceptable cloud connection — either through multiple redundant mechanisms or a car-based powerful antenna — and you'll be better off. Even when the car knows some data that the cloud doesn't (like a mobile's contact list or music selection), there's no need to handle that on the embedded side. The cloud recognition server is powerful enough to not require the data set a priori. And I think we can predict an eventual migration of phone data to cloud-based data (or cloud-synchronized data) that makes the car's knowledge either easily transferrable or less relevant.

Who makes money, and how, from voice-enabled agents or voice services? This was one of the best questions of the panel, because nobody really knows the exact model, but everybody agreed that customer tolerance is very low. The most likely candidate is ad-based revenue. This doesn't mean reading ads aloud to the driver, but rather, positively influencing search results for either active or temporary situation-based points of interest (POIs). Depending on how valuable the service is to the driver, there will still be an option for service-based payments and high-value apps.

Standards and building mobile apps — will it come? You need standards if you want to build an app platform that will promote application creation and adoption. That's what we're doing with the QNX CAR 2 application platform — creating a way for someone other than the car companies to join the ecosystem and to deploy their apps to the car in a controlled way. But don't forget, you need a standard way to deploy apps for the cloud half of the recognition, too.

To close, let me share two photos. One was taken outside the Marriott Marquis, the hotel hosting the conference just off of Times Square in NYC. The other is from our PR agency, Breakaway Communications. What do they have in common? Wooden water towers. Sorry, I couldn't help myself; I just love those things. They just look so quaint in a city full of glass and brick.

Enabling drivers to interact safely with applications and services

Since February 2015, QNX Software Systems has been leading an international standards effort to help drivers interact safely with applications and services. And not just apps on phones, but apps running in the cloud, in roadside infrastructure systems, in the car itself, and other locations.

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:

1. 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.
2. Determine which aspects of the solution should be standardized, then help drive this standardization.
3. Align QNX product roadmaps as solutions develop.

To be clear, this is a longer term strategy that will take years to realize. Both the standardization process and the time it takes to deploy technology in vehicles must be factored in. Therefore, we are also pursuing shorter term solutions, some of which I hope to cover in future posts.

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.