QNX and the W3C: setting a new standard

For almost two years, you’ve heard us talk about HTML5 in the car, particularly as it applies to the QNX CAR Platform for Infotainment. And now, we're taking the next step: working with the entire automotive community to develop a standard set of JavaScript APIs for accessing vehicle sensor information.

Andy Gryc (that’s me of course) and Adam Abramski (from Intel and representing GENIVI) are co-chairs in the World Wide Web Consortium (W3C) Automotive and Web Platform Business Group. Yes, our group name is a mouthful. But the translation is that Adam and I are working with W3C group members to create a standard that everyone can agree on.

Between GENIVI, Tizen, Webinos, and QNX, four different APIs are in use today. So what’s the process? All of these APIs have been submitted to the W3C group members as contributions. Those contributions form the groundwork, creating a baseline for where we need to go. Collectively as a group, we need to merge these four APIs — figure out the commonalities and harmonize the differences to create a new standard that takes the best features of all the proposals.

This effort takes some time, but the group intends to complete a first draft by December this year. Either Tina Jeffrey (my colleague, who’s doing some of the heavy lifting) or myself will be posting our progress here, so keep an eye out for our updates!

From Hollerith to HTML5: the inevitable rise of the programmable car

Paul Leroux

Some people are crazy good at predicting the future. Case in point: Nicola Tesla. In 1909 he proclaimed that "everyone in the world" would one day communicate with wireless handheld devices. At the time, people must have thought he was, well, crazy. But look around you: when's the last time you weren't surrounded by people using wireless handhelds?

Over the years, the auto industry has produced many technology visionaries who share this talent for prognostication. Mind you, visionary is probably the wrong word. Many of these people didn’t simply envision the future; they tried to build it. All too often, however, the technology needed to make their ideas work was still in its infancy — or simply didn't exist yet.

For evidence, consider the ITER AVTO. Introduced in 1930, this dash-mounted navigation system used maps printed on rolls of paper. These maps were connected by a cable to the speedometer and would scroll forward in proportion to the car’s speed. It was all pretty cool, provided you didn’t make a turn — otherwise, quick, change rolls! Basically, a great idea hampered by the tech of its time:


Source: Dieselpunks

For another example, consider these “alarming” glasses, which made their debut at the Frankfurt Motor Show in 1951. The concept was simple: monitor eye movements to determine whether the driver is falling asleep; if so, sound an alarm. Just one problem: to detect eye movement, the glasses used a thin steel wire pressed against the driver’s eyelids. It was another great idea that needed yet-to-be invented technology — in this case, inexpensive (and non-invasive) eye-tracking cameras — to work.


Source: Modern Mechanix blog

And then there’s the 1969 Buick Century Cruiser, an autonomous concept car that used punch cards to program the car’s destination. The driver would insert a card encoded with a destination, and an electronic highway center (whatever that was) would then take over and guide the car to where it was programmed to go.


Source: Car Styling 2.0 

The car was never intended to be sold, of course. To be commercially viable, it would have required technologies that simply weren't available in 1969.

But you know what? I think the Century Cruiser represents a watershed concept: that you can use software to control or enhance a car's behavior. The Century Cruiser may have used Hollerith cards, but it presaged vehicles that, in a few short years, would use programming languages like C to control ECUs and anti-lock brakes. From there, it was only a matter of time before cars would use software technologies like HTML5 to deliver everything from weather reports to smartphone integration. The software path was set, even if no one realized it yet.

Controlled openness

Paul Leroux

The title of this post sounds like a contradiction in terms. But you know what? It captures the predicament faced by every automaker today.

On the one hand, automakers need to convince mobile developers that it's worthwhile to create apps for the car. They also need to make the process of creating and monetizing car apps as easy and open as possible. Otherwise, why would a developer spend time developing a car app when a phone app could reach many more customers? (About 60 million cars shipped in 2012, compared to more than 545 million smartphones — and most of those cars can't host apps.)

On the other hand, apps can't run willy-nilly in the car. For safety's sake, automakers must impose control on when specific apps can be used, and the apps themselves must be designed or modified to minimize distraction, possibly in accordance with government-mandated rules and guidelines. That may sound like an imposition on developers, but not really. After all, developers want to create apps that will prove popular with consumers, and consumers will be far more interested in apps that can be used while the car is moving — apps that, for safety reasons, can be used only when the car is stopped will hold less appeal.

But enough from me. Recently, my colleague Andy Gryc caught up with Thilo Koslowski, VP Distinguished Analyst at Gartner, and they discussed the notion of controlled openness for the car — along with how HTML5 fits into the picture. The cameras were rolling, so grab some popcorn, dim the lights, and check it out:

DevCon5 recap: building apps for cars

Tina Jeffrey

Last week I had the pleasure of presenting at the DevCon5 HTML5 & Mobile App Developers Conference, held at New York University in the heart of NYC. The conference was abuzz with the latest and greatest web technologies for a variety of markets, including gaming, TV, enterprise, mobile, retail, and automotive.

The recurring theme throughout the event was that HTML5 is mainstream. Even though HTML5 still requires some ripening as a technology, it is definitely the burgeoning choice for app developers who wish to get their apps onto as many platforms as possible, quickly and cost effectively. And when a developer is confronted with a situation where HTML5 falls short (perhaps a feature that isn’t yet available), then hybrid is always an option. At the end of the day, user experience is king, and developers need to design and ship apps that offer a great experience and keep users engaged, regardless of the technology used.

Mainstream mobile device platforms all have web browsers to support HTML5, CSS3, and JavaScript. And there’s definitely no shortage of mobile web development frameworks to build consumer and enterprise apps that look and perform like native programs. Many of these frameworks were discussed at the conference, including jQuery Mobile, Dojo Mobile, Sencha Touch, and Angular JS. Terry Ryan of Adobe walked through building a PhoneGap app and discussed how the PhoneGap Build tool lets programmers upload their code to a cloud compiler and automatically generate apps for every supported platform — very cool.

My colleague Rich Balsewich, senior enterprise developer at BlackBerry, hit a homerun with his presentation on the multiple paths to building apps. He walked us through developing an HTML5 app from end to end, and covered future features and platforms, including the automobile. A special shout-out to Rich for plugging my session “The Power of HTML5 in the Automobile” held later that afternoon.

My talk provided app developers with some insight into creating apps for the car, and discussed the success factors that will enable automakers to leverage mobile development — key to achieving a rich, personalized, connected user experience. Let me summarize with the salient points:

What’s needed	What we're doing about it
The automotive community wants apps, and HTML5 provides a common app platform for infotainment systems.	We’ve implemented an HTML5 application framework in the QNX CAR Platform for Infotainment.
Automotive companies must leverage the broad mobile developer ecosystem to bring differentiated automotive apps and services to the car.	We’re helping by getting the word out and by building a cloud-based app repository that will enable qualified app partners to get their apps in front of automotive companies. We plan to roll out this repository with the release of the QNX CAR Platform 2.1 in the fall.
The developer community needs standardized automotive APIs.	We’re co-chairing the W3C Automotive and Web Platform Business Group, which has a mandate to create a draft specification of a vehicle data API. We’re also designing the QNX CAR Platform APIs to be Apache Cordova-compliant.
Automotive platform vendors must supply tools that enable app developers to build and test their apps.	We plan to release the QNX CAR Platform 2.1 with open, accessible tooling to make it easy for developers to test their apps in a software-only environment.

---

Jivin' up the Jeep with a fresh new version of the QNX CAR Platform

by Paul Leroux

Reskinnable, reconfigurable,
and refreshed

If you haven’t already heard, we've announced version 2.1 of the QNX CAR Platform for Infotainment. In fact, we’re demonstrating it this week at the Telematics Detroit conference.

So what’s new in 2.1? Well, let’s start with what hasn’t changed. The platform is still based on the same, reliable QNX architecture proven in tens of millions of vehicles. (Fact: In 2012, QNX technology shipped in 11 million cars. If you put those cars end to end, they’d circle the earth — and you’d still have about 6000 miles of cars left over. That's a lot of cars.) The platform also retains its inherent flexibility, allowing infotainment system designers to use multiple app environments, connect to multiple mobile platforms, and create a wide range of systems.

Um... let me correct that statement. The new version is, in fact, more flexible. From the beginning, the QNX CAR Platform has supported both HTML5 and OpenGL ES, the two most popular open standards for mobile development. And now, with version 2.1, it also supports Android apps, as well as apps and human machine interfaces (HMIs) built with the popular Qt 5 application framework.

The QNX reference vehicle — a modded Jeep Wrangler — is the perfect, well, vehicle for showcasing these new capabilities. Take, for example, the new digital instrument cluster, which is implemented in OpenGL ES:



I enjoyed the look of the reference vehicle’s original cluster, and still do. But you know what I like about the new version? It shows how a digital cluster can deliver state-of-the-art features, yet still honor the look-and-feel of an established brand like Jeep. These features include dynamic reconfigurability and the power to display turn-by-turn directions, weather updates, and other information provided by the head unit.

Speaking of which, here is the head unit’s main screen, which serves as a one-stop information center for turn-by-turn directions, weather, music, and recent messages:



Now let’s slide over to the passenger seat for a different perspective. If you look below, you’ll see the head unit’s app tray, which shows how the QNX CAR Platform can blend a variety of apps and HMI technologies on the same display — in this case, native and Android apps running on an HMI built with the Qt 5 application framework. In case you’re wondering, the Android app icons in this image are AutoTrader and TapTu. (That's right, they can be accessed just like other apps.)



If you’ve seen images of the QNX technology concept car (you know, the Bentley!), you’re already familiar with the gorgeous 3D navigation system created by our partner Elektrobit. Well, the reference vehicle also comes with a version of Elektrobit’s nav system, seen here:



And last, here’s an image of my personal favorite, the virtual mechanic. In this case, it's displaying trip information, including duration, mileage, and average speed:



There's a lot to see in version 2.1 of the QNX CAR Platform for Infotainment, but there's also a lot you can't see — such as improved power management, optimizations for faster boot time, and support for more hardware platforms, including Freescale i.MX 6Dual and i.MX 6Quad, NVIDIA Tegra 3, Texas Instruments OMAP 5, and Texas Instruments Jacinto 5 Eco.

What's more, I haven't shown you any of the new, pre-integrated partner apps that have been added to the platform, including HearPlanet, Parkopedia, Soundtracker, and wcities eventseekr. But no worries, I plan to reveal more in coming posts.

In the meantime, I invite you to check out the press release we issued this morning.

HTML5 blooper reel

I find bloopers infinitely amusing — mind you I’m talking about those that come on a reel, not those that happen for real. Missed deadlines, cost over-runs, IP disputes — these are the bloopers we all could do without.

Helping customers avoid bloopers is what we do — so to speak. Except it seems, when we put them in front of the camera. <grin>

Seriously though, no customers were hurt in the making of this video.



This compilation of bloopers from the HTML5 series highlights the professionalism of QNX customers, partners, and employees as well as their good nature.