WIRED Autopia slips into driver's seat of QNX reference vehicle

Chances are, you've seen pictures of the new QNX reference vehicle. You may have even seen the "making of" video that QNX released a few days ago. But have you seen any video of the vehicle in action?

If not, check out this vid by Doug Newcomb of WIRED Autopia. Last week, at Telematics Detroit, Doug met up with Andrew Poliak of QNX for a tour of the vehicle and its various features, including a re-skinnable UI and voice-controlled Facebook integration. The camera was rolling, and here's what it caught:


 

HTML5 brings new buzz to infotainment system development

QNX to unveil QNX CAR 2 platform on Freescale i.MX 6 at FTF Americas — a guest post from Paul Sykes of Freescale

If you’ve visited the QNX website recently or attended the Telematics Detroit conference last week, then you’ve surely noticed that HTML5 is getting a lot of attention in automotive these days. The buzz around HTML5 focuses on two areas: as an application development and delivery framework, and as an HMI framework. In discussions with many industry participants, my impression is that the application framework part is generally accepted, while the HMI framework part still isn’t well understood.

I don’t intend to discuss these HTML5 aspects in detail. There are experts within the ecosystem that can do a much better job than me. But I will say that Freescale applications processors will offer the processing and graphics performance to run the desired applications and bring the HMI to life with stunning graphics.

Next week, Freescale will host the annual FTF Americas event in San Antonio, TX. We are very excited about the first public unveiling of the QNX CAR 2 application platform on i.MX 6. Since QNX CAR 2 is based on HTML5, it is particularly fitting to mention in this blog. For those with an interest in understanding more about HTML5 for infotainment systems, QNX and many other ecosystem partners will be on hand at FTF to discuss their thoughts and plans.

Paul Sykes is a member of Freescale’s driver information systems team.
 

The making of the QNX reference vehicle: Jeep Wrangler

Guest post from Nicole Forget of QNX Software Systems

Nicole Forget

Just one week ago, our new reference vehicle was revealed at Telematics Detroit 2012. The Jeep Wrangler features QNX’s digital instrument cluster, which is totally re-skinnable. In fact, the entire user interface of the head unit, which was created using HTML5, can also be re-skinned. The head unit supports loads of functions, too, including the virtual mechanic, which are outlined in an earlier post.

The following video gives you some insight into the hard work that was put into the making of the reference vehicle. Check it out!


 

Moving beyond the browser: HTML5 as an automotive app environment

If you’ve already visited this blog, you’ll know that we are bullish on HTML5 as a way to implement infotainment system HMIs. Not surprisingly, I’ve spent a fair amount of time searching the Web for facts and opinions on using HTML5 in the car, to see how this idea is catching on.

Overall, people see numerous benefits, such as the ability to leverage mobile app development to keep pace with the consumer demands, the availability of a large pool of knowledgeable developers, and the attractiveness of a truly open specification supported by many possible vendors.

But when it comes to the challenges of making HTML5 a reality in the car, I found a common thread of questions, mostly rooted in the erroneous belief that an HTML5 application environment is “just a browser.” Everyone is familiar with the concept of a browser, so it’s easy to see why people take this point of view.

So what are the key differences between a browser and an HTML5 application environment? Here’s my quick view.

The experience
Everyone is familiar with the browser experience. You navigate to a web site through bookmarks, a search engine, or direct entry of a URL. The browser implements a user interface (aka the chrome) around a rendering engine and provides bookmarks, URL entry, back and forward, scrolling and panning, and other familiar features.

An automotive HMI based on HTML5 provides a different experience — just look at the accompanying screen shots and decide for yourself if they look like a browser. In fact, the user experience of an HTML5-based HMI is similar to that of any other purpose-built HMI. It can consist of a main screen, window management, navigation controls, and other typical user interface widgets.


A radio tuner and a media player from the QNX CAR 2 application platform. Both apps are based on HTML5, but beyond that, they neither act nor look like a web browser.

A system that uses an HTML5-based HMI can include:

• core applications that look and act like native applications
   
• add-on (downloaded and installed) applications that have controlled interfaces to the underlying hardware
   
• “web link” applications that simply link to a cloud-hosted application that can be downloaded on demand and cached

The web link approach makes it easy to update applications: just update the server and the remote client systems will automatically pull the application when needed.

Local resources
Web browsers pull text, images, and other content from the web and render it on the user’s machine. The process of loading this remote content accounts for much of the user’s wait time. This paradigm changes with a local HTML5 application environment — because resources can exist locally, images and other components can load much more quickly.

What’s more, screens and user interfaces can be designed to fit the platform’s display characteristics. There is no need for panning and scrolling, and only limited need for zooming. Resources such as RAM can be optimized for this experience.

Security and sandboxing
Browsers load content and executable JavaScript code dynamically. This really is the power of the web technologies. The problem is, dynamically loaded code represents a threat to an embedded platform.

Browsers are designed to be sandboxed. By default, JavaScript code can execute only in the context of a browser engine, and cannot access the underlying operating system primitives and hardware. This approach changes in an HTML5 application environment. To give JavaScript code the ability to behave like a native application, the environment needs interfaces to the underlying OS through to the hardware. Plugins are used to implement these HTML5-to-OS interfaces.

Nonetheless, access to the underlying platform must be carefully controlled. Hence, a security scheme forms a critical component of the HTML5 application environment.

Application packaging
The app experience has become familiar to anyone who owns a smartphone or tablet. An HTML5 application environment in the car can also support this kind of experience: developers create and sign application packages, and users can download those packages from an application store. In an automotive context, authenticity of the applications and control over what they can or cannot do is critical. Again, a security model that enforces this forms a key part of the HTML5 application environment.

So, how should you think of an HTML5 application environment?
From my perspective, an HTML5 environment is like any other traditional HMI toolkit, but with much more flexibility and with inherent support for connected applications. In an HTML5 application environment, you can find technologies similar to those of any proprietary toolkit, including:

• a rendering engine (HTML5 rendering engine)
• a set of content authoring and packaging tools
• layout specifications (HTML5 and CSS3)
• a programming language (JavaScript)
• an underlying data model (DOM)

The difference is, these components are developed with a web experience in mind. This, to me, is the most significant benefit: the web platform is open, scalable, and well understood by countless developers.

Biff! Bap! Ker-Pow! It’s the BatBerry interview!

Paul Leroux interviews Tim Neil, a director of product management at RIM, who is building his very own Batmobile™. This project might sound like fun (and Tim assures us it is), but it also demands a wealth of skills, from welding to HTML5 programming.

Tim Neil

Tim, could you give us a quick overview of the BatBerry project?
The BatBerry combines my love of cars, Batman, and technology. I’ve always wanted to build this car and I’ve had a couple of unsuccessful attempts at creating a carputer. When RIM started creating a 7" tablet, I knew the time was right to bring all of these interests together.

How did you get started on this project?
I started my research about 15 years ago, trying to determine how and where to get started. For instance, I needed to track down the shifter, which is a throttle quadrant from a WWII US Navy bomber.

By 2010, I had finished modifying my custom Subaru WRX, and I needed to get started on something new — working on cars is my way of escaping and relaxing. The time was right, and I got the green light from my wife. Luckily for me, she knew of my desire to build this car when we met and it didn’t scare her away. :-)

The BatBerry, about a year after Tim launched his project

Reading your blog, I’m totally impressed by the scope of the BatBerry project — be it creating dashboard panels, writing control software, or building a retractable license plate. Do you do most of the work yourself?

Yes, I try to do as much of the work myself as possible. I leave important things that I don’t have experience in, like doing the frame stretch, to the professionals. I did the same thing building up my Subaru over the past 7 years: learning how to do body work, interior, stereo, engine modifications, etc. I like to learn things as I go and I’ve always had a knack for figuring out how things work. I always figure, what’s the worst thing that can happen? If screw up, I just have to try again.

To pull this off, you need to be a jack of all trades. I’m sure you had skills to begin with — but did you also have to pick up any along the way?
Welding is one of the biggest skills that I’ve picked up so far. I bought myself a welder, watched a couple of YouTube videos, and got to work. I can tell you, my welds look MUCH better now than my first ones. From all the welders I’ve talked to, it’s a skill that simply takes patience and practice.

Since I was a kid I have always been able to figure things out. When I was 8 years old I was wiring my bedroom up to have a switch on my headboard automatically open the door. The best way that I can describe to people how I see the world is by watching the movie Iron Man. When you see Iron Man’s computer JARVIS take an object and expand it out into a million pieces to show how it works, that’s what I see when I look at something.

Tim's other project — a highly modified Subaru WRX

What kind of power plant does the BatBerry use? Have you modded it?
The car currently has a 305 4.3L L99 V8. I haven’t really modified it yet. I will likely go with a re-built version of the same engine so that I can re-use the ECU. I’m not looking to make this car into a high-performance hot rod — that’s where my Subaru comes in. Plus, it’s nice to drive distances not always looking for a gas station that serves 94 octane. :-)

The V8 puts out 200hp, which should be pretty good for the BatBerry, considering it is basically a frame with a 400-pound fiberglass body mounted to it. As long as it sounds nasty I’ll be happy. I have a couple of Flowmaster 40 series mufflers for it.

Anyone who reads this blog knows we are bullish on HTML5. So I was fascinated to hear that the BatBerry project has an HTML5 connection. Could you tell us about it?
As the former development manager for BlackBerry WebWorks at RIM, I wanted to show what could be done with HTML5 technology. I wanted to build an interface on my PlayBook and BlackBerry Smartphone that could control some of the systems of the car.

I also wanted to share as much code as possible between the Smartphone and PlayBook, and using WebWorks and HTML5 allows me to do this. These devices pair with a Bluetooth connection on an Arduino board to control a series of relays that raise and lower the 30-cal machine guns, open and close the canopy, raise and lower the suspension, and perform other functions.

All the source code for the project, including Arduino microcontroller code, is being shared in my BatBerry repo on github.


Sample screen captures of the BatBerry user interface

What has been your greatest challenge? And what are you most proud of, so far?
My biggest challenge has been finding time! I’ve been travelling for work more on weekends and while this winter was pretty mild, it was still a bit hard to head out into a freezing cold garage to put in a couple hours of work during the evenings.

I would say the two things I’m most proud of so far are my welding skills and my dash panels. I really wanted to give back something to others who have been building their own versions of this car. Screen-accurate dash panels were something missing from the community. In general, I really like to share what I’m doing so that others who want to do something similar can see what worked, and what didn’t work, for me.

The Discovery Channel has been tracking the BatBerry project. Do they plan to broadcast anything soon?
Nothing to air at the moment. The next step will be to get updated footage of some of the technology integration points. I’m getting close to being able to show the combination of HTM5, Arduino, and the machine guns to get some new footage. Once we reveal the car, filming will wrap up and go into post-production for airing sometime in the future on Daily Planet.

When you aren’t working on the BatBerry, what do you do?
I spend my spare time hanging out with my family, doing something with cars, or playing with technology. My daughter is a big Star Wars fan so she and I have been having some epic lightsaber battles lately. I’ve done a lot of car shows in the past with my Subaru and I really like meeting up and trading experiences with the car community around Toronto. At RIM, I direct the product management group responsible for developer tools, APIs, and SDKs — our focus is on removing barriers and adding features to make developers successful.

One more question: Which Batman character do you most identify with?
I would say Batman himself. While I’m not on the tipping point of insanity and looking to be a vigilante, I identify with the desire to make a difference. I also relate to the do-it-yourself attitude and the love of cool tech and cars. Plus, I’m just a geek at heart. :-)

---

To track the progress of the BatBerry project, check out Tim’s blog. You can also follow him on Twitter.

And while you’re at it, visit Tim’s YouTube channel. Here, for example, is a video showing the BatBerry’s replica machine guns:




Neither Tim Neil, his vehicle, nor Research In Motion (BlackBerry) are licensed by, endorsed by, sponsored by or affiliated with DC Comics or the owners of the “Batman” properties.
 

Everything you wanted to know about HTML5 in the car, Part III

Welcome to the third installment in my Q&A series on HTML5 in the car. In Part II, we looked at web servers, native plug-ins, instrument clusters, and display updates. This week, we turn our attention to tools, touch gestures, UI performance, and vehicle resources.

Are there any HTML5 HMI builder tools available?
Most of the well-known IDEs, including Eclipse, Dreamweaver, and Netbeans, support some flavor of HTML5 in their latest release. Adobe Edge, a new tool now available in preview, also lets you create animated HTML5 content. I suggest you check out the HTML5 Tools site, which publishes up-to-date tool reviews.

Often, automotive customers will ask system designers to make an infotainment system work "like an iPhone,” with the popular gesture controls. Does HTML5 support "inertial" menus and two-finger zoom?
Multi-touch is handled at the app level; here’s an example. Pinch zooming at the browser level is browser-dependent — the QNX browser handles it, but not every browser does. As for physics-based scrolling, HTML5 doesn’t support it “out of the box”; it needs to be added. Frameworks like Sencha Touch provide these types of controls.

Will the performance of HTML and JavaScript be adequate for critical user interface components or computations, such as safety-related notifications?
This has to be tested on a case-by-case basis. For the UI elements, yes, the performance should be adequate. Our testing indicates you can build HMIs that are surprisingly responsive. Also, our WebKit port lets you do things things like run JavaScript code in other tabs, threads, or processes to ensure those ocmponents aren’t being thread-blocked by something less critical.

I do get a little gun-shy recommending HTML5 for safety-critical components, because JavaScript isn't inherently real-time. If you wouldn't feel comfortable using Java for a critical coding task, you shouldn't use HTML5 either. If you want predictable, real-time performance for a lower-level computation that cannot tolerate any delay, the code should execute in a non virtual-machine environment. Most code doesn’t really fit that description, so most of the time JavaScript should work just fine.

How do you call vehicle resources — vehicle HMI, vehicle diagnostics information, etc. — on a HTML web app in the car? What's the process in plain words?
In plain words, it’s kinda hard. :-) But here’s my best take on this question: we solve this by creating a vehicle-bus driver that exports data through a publish/subscribe mechanism. The HTML5 layer talks to that piece through a JavaScript interface.
 

A quick tour of the QNX CAR 2 application platform

If you're looking for a quick, two-minute intro to the QNX CAR 2 application platform, you've come to the right place.

In this video, Kerry Johnson, automotive product manager at QNX, takes us on a tour of the platform, including its home screen, media player, application area, HTML5 support, phone app, and acoustic processing.

Ready? Then hit the Play button and let's get started:



In case you didn't know, the QNX CAR 2 platform forms the basis of the QNX concept car, a specially modified Porsche 911 that demonstrates what to expect in next-generation car infotainment systems. Earlier this year, the platform drove home with a 2012 Best of CES award, in the Car Tech category.
 

HTML5: Bustin' the myths

Did you know you can build HTML5 apps that don't use an Internet connection? Did you know you can run HTML5 apps without a web browser? And did you know HTML5 apps can show snappy performance even on automotive silicon? (As you can well imagine, in-car infotainment systems don't ship with quad-core server-class CPUs.)

If you answered no to any of these questions, you need to stop for a minute and check out this interview with QNX Software Systems' Kerry Johnson. Heck, even if you answered yes to all three questions, you'll probably still appreciate what Kerry has to say — and besides, you'll catch a glimpse of a complete in-car UI coded in HTML5. What could be bad?



While I have you, check out Andy Gryc's Q&A series on HTML5, if you haven't already. You'll find the first two installments here and here.
 

Everything you wanted to know about HTML5 in the car, Part II

Welcome to the second installment in my Q&A series on HTML5 in the car. Last week, we looked at CSS, cross-platform execution, and asynchronous design. This week, we turn our attention to web servers, native plug-ins, instrument clusters, and display updates.

If I don’t use a web server in my infotainment system, will I miss out on some features of HTML5?

A web server isn’t strictly necessary, but there are two very good reasons for including one. First, it lets you export a user interface to devices outside the car, thereby allowing mobile phones or tablets to run apps that are hosted on the vehicle head unit. Second, it lets you export internal car resources, as a URL, to HMI software running in the head unit. For instance, the web server could provide the HMI with access to static vehicle-configuration data (through an xml file) or to a back-up camera (through a video stream).

Will using native code plug-ins compromise my ability to leverage HTML5?

This is tricky, because a lot of things you want to do may require native code. So, yes, use native code, but do it judiciously. The more native code you use, the more it will limit the cross-platform capability of the HTML5 code that relies on it. The good news is that with HTML5 gaining so much functionality, plug-ins are needed far less than ever before.

A sample climate control app from the
QNX CAR 2 platform, created with HTML5.

Would you consider HTML5 as an option for cluster instruments: speedometers, tachometers, etc.?

At this point, I’d say no. HTML5 makes a lot of sense for in-vehicle infotainment, but it doesn’t provide the response needed for a vehicle cluster and it won't ensure safety-critical certification. Plus, the instrument cluster isn’t where you realize a lot of HTML5’s value: downloadable apps, connectivity to mobile devices, and so on. If the cluster and the infotainment system eventually merge into one big screen, then it’s more likely you could use HTML5 for both — but that’s still a few years out.

What’s a good way to get responsive display updates (10Hz update) into HTML5? Websockets?

If you need to deliver high-speed updates to your head unit, Websockets is one way to go. Make sure, however, that you don’t stall the rest of the JavaScript engine while your main thread is blocked on tasks. If you create another thread to monitor for changes, you can do it just as effectively (and probably with less work) with a JNEXT or NPAPI call into native code.
 

Everything you wanted to know about HTML5 in the car, Part I

My HTML5 webinar generated a lot of interesting dialog about what HTML5 means for in-vehicle systems. People asked questions about everything from security and performance to WebGL and cross-platform execution. Many of the same questions come up with when I speak with customers and analysts, which got me to thinking: Why not address them in this blog?

So without further ado, here is the first of my "FAQs" on HTML5 in the car. If you have a question and you don’t see it answered here, leave a comment and let me know! I’ll try my best to answer it in a future post.

How can you create multiple in-vehicle user interfaces using a single HTML5 code base?
The key to achieving this is the Cascading Style Sheets language, or CSS.

CSS controls the look and feel of web pages, but it can also be used to control the look and feel of a vehicle head unit. By changing a single CSS file, you can, for example, change all the fonts and background colors in a website (or head unit) from Arial and white to Verdana and black.

Mind you, CSS does much more than that. It also lets you specify how individual tags in HTML documents are displayed: layout, margins, sizes, colors, behavioral characteristics, events, and so on. Consider, for example, a phone app accessed through the vehicle head unit. If that app provides an HTML5-based user interface, each OEM could provide a default CSS that controls how the app looks on the head unit, adapting the app to meet in-vehicle usability standards and, of course, branding it.

A sample app from the QNX CAR 2 application
platform, created with HTML5

Let’s say your phone has an HTML5 navigation app that you want to run in your Audi today and your Chevy tomorrow. Although the phone serves up the app content identically in both cases, the Audi system can use a CSS to ensure that the app looks ‘Audi-like’, with that distinctive black and silver coloring, and the Chevy system can use a CSS that gives it the app the look-and-feel of OnStar. In effect, CSS can give the OEM more control over brought-in applications than other types of ‘screen replication’ technologies, like MirrorLink or iPod Out.

Keep in mind, though, that CSS can’t solve different OEM input philosophies, such as touch, hardkey, softkey and so on. You could use CSS to change the appearance for different inputs, but you would still need to have JavaScript hooking things up underneath.

You mentioned that cross-platform execution is a key benefit of HTML5. Do you have any recommendations on how to implement it?
Cross-platform execution is definitely something you want to keep in mind when designing software for vehicle head units. If you’re careful to ensure your app avoids features specific to the embedded environment, you can use mobile and embedded apps with the same HTML5 code base. It shouldn’t be difficult to make sure your app runs in both environments, but it’s better to plan for this going into design. That way, you can avoid using anything that prohibits cross-platform execution.

Could HTML5 replace the current HMI systems in head units that support multiple applications, and still be event driven and asynchronous in nature?
Definitely. JavaScript in HTML5 supports the concept of separate threads, called workers, that can handle events asynchronously. Although workers have some restrictions, such as the inability to modify the Document Object Model (DOM) or access globals, they should still be able to handle most asynchronous events. Maximum flexibility may require additional support from the HTML5 engine. To that end, QNX Software Systems has invested a lot of time in improving WebKit to allow code to run in separate engine web views, in different threads, in different processes, and even in completely independent HTML5 engine instances.

Stay tuned for Part II, where I plan to tackle questions on web browsers, web servers, and instrument clusters.
 

OnStar Interview: Standards, HTML5, and the OEM

Have you ever explained to your kids why the solid rocket boosters on the Space Shuttle are the width of two Roman warhorses standing side-by-side? If you haven’t, I suggest you do. The incredulous looks are well worth it. For additional bonus laughter from the younger crowd, you may want to add in the fact that we’re talking about the rear ends of horses.

What this little bit of trivia does for us, the 'older' crowd, is offer a lesson in standardization. A set of specs, rules, measurements, and so on can have long-lasting repercussions. And so, on the one hand, it behooves us to choose wisely; while on the other hand, it reminds us about the importance of being open to change.

Steve Schwinke, director of advanced technology for OnStar, is among a growing number of industry leaders who believe that HTML5 has the potential to dramatically change our industry for the better. Steve believes in strength in numbers and has great faith in the OEM community to work together to help shape the standard and promote its widespread adoption.

Here’s what Steve had to say about HTML5 when we visited him in Detroit just before the holidays in December.



This interview of Steve Schwinke is the fifth in a series from QNX on HTML5.

HTML5 Hackathon

Learn how to put together HTML5 apps at the HTML5 Hackathon. You'll get hands-on experience with WebWorks, which is the BlackBerry tool for building applications with HTML5.

That'll get you primed for building HTML5 apps for the QNX CAR 2 application platform!

CrackBerry posts first peek at OnStar RemoteLink for BlackBerry PlayBook

Paul Leroux

This morning at CES, CrackBerry.com met up with QNX's Andrew Poliak for a walkthrough of the new OnStar RemoteLink app for the BlackBerry PlayBook.

If you aren't familiar with RemoteLink, it provides a very cool and powerful connection to OnStar-equipped vehicles. From the convenience of your tablet or phone, you can access gas mileage, tire pressure, and other information in real time; you can even remotely start your vehicle and unlock its doors.

Cooler yet, the new version running on the PlayBook boasts a user interface built entirely in HTML5. But enough blather from me. Roll the tape...



Did you know? QNX is the core OS for the PlayBook, but it's also the OS for OnStar and OnStar FMW.
 

HTML5 is a great option for the risk-adverse

The conservative nature of automakers makes them ideal candidates for the brand-spanking new HTML5. Say what?

While this seems paradoxical, it is an interesting take-away from the discussion between TCS' director of engineering Michael Camp and our very own Andy Gryc. If you've got three minutes to spare, watch the latest video in our HTML5 series for the whole story. (As usual, don't miss the ending. ;-)

This interview of Michael Camp is the fourth in a series from QNX on HTML5.

HTML5 and the software engineer

HTML5 appears to have a number of benefits for consumers and car manufacturers. But what is often good for the goose is not necessarily good for the developer. Talking to the guys in the trenches is critical to understanding the true viability of HTML5.

Andy Gryc and Sheridan Ethier, manager of the automotive development team at QNX, pair up for a technical discussion on HTML5. They explore whether this new technology can support rich user interfaces, how HTML5 apps can be blended with apps written in OpenGL, and if interprocess communication can be implemented between native and web-based applications.

So without further ado, here’s the latest in the educational series of HTML5 videos from QNX.



This interview of Sheridan Ethier is the third in a series from QNX on HTML5.

Is HTML5 a good gamble?

As the consumer and automotive worlds continue to collide, HTML5 looks like a good bet. And not a long shot either. In fact, the odds are all automakers will eventually use it. But since the standard won’t be mature for some time yet, should you take a chance on it now? 

To answer this, Andy Gryc talks to Matthew Staikos of RIM. Matthew is the manager of the browser and web platform group at RIM, and has over 10 years of software development experience with a strong focus on WebKit for mobile and embedded systems. Matthew co-founded Torch Mobile, which was acquired by RIM for their browser technology.

Andy’s conversation with Matthew is the subject of the following video, the second in an educational series designed to get an industry-wide perspective on HTML5. 

This interview of Matthew Staikos is the second in a series from QNX on HTML5.

What’s HTML5 got to do with automotive?

There’s been a lot of noise lately about HTML5. A September 2011 report by binvisions shows that search engines and social media web sites are leading the way toward adoption: Google, Facebook, YouTube, Wikipedia, Twitter, and plenty more have already transitioned to HTML5. Some are taking it even further: Facebook has an HTML5 Resource Center for developers and the Financial Times has a mobile HTML5 version of their website.

It won’t be long before HTML5 is ubiquitous. We think automakers should (and will) use it. 

To elucidate the technology and its relevance, we’ve created a series of educational videos on the topic. Here is the first in that series. Interviews with partners, customers, and industry gurus will soon follow. 

This simple overview is the first in a series from QNX on HTML5. (Personally I like the ending the best.)

Seamless connectivity is for more than online junkies

As much as I’m not always enamored with sitting behind a computer all day, I find being off the grid annoying. Remember this email joke?

You know you’re an online junkie when you:
• wake up at 3:00 am to go to the bathroom and stop to check your email on the way back to bed
• rarely communicate with your mother because she doesn’t have email
• check your inbox. It says ‘no new messages,’ so you check it again 

Even though this joke circulated several years ago, it still strikes a chord. The big difference now is that there’s no longer a subculture of ‘online junkies.’ From the time we wake up in the morning to the time we go to bed, we all want to be connected — and that includes when we get behind the wheel. So to this joke I would add:

• resent driving because it means going off the grid

At QNX, we’re working toward a seamless experience where people can enjoy the same connectivity whether they’re texting their spouse from the mall or checking traffic reports while driving down the highway. See what I mean:



For more information about the technology described in this video, visit the QNX website.
 

Can HTML5 keep car infotainment on track?

Paul Leroux

True story: When a train on the Trans-Mongolian Railway crosses from Mongolia into China, it must stop and have all of its wheel assemblies replaced. Why? Because the track gauge (distance between the rails) is 1520 mm in Mongolia and 1435 mm in China. Oops!

The rail industry realized long ago that, unless it settled on a standard, costly scenarios like this would repeat themselves ad infinitum. As a result, some 60% of railways worldwide, including those in China, now use standard gauge, ensuring greater interoperability and efficiency.

The in-car infotainment market should take note. It has yet to embrace a standard that would allow in-car systems to interoperate seamlessly with smartphones, tablets, and other mobile devices. Nor has it embraced a standard environment for creating in-car apps and user interfaces.

Of course, there are existing solutions for addressing these issues. But that's the problem: multiple solutions, and no accepted standard. And without one, how will cars and mobile devices ever leverage one another out of the box, without a lot of workarounds? And how will automakers ever tap into a (really) large developer community?

No standard means more market fragmentation — and more fragmentation means less efficiency, less interoperability, and less progress overall. Who wants that?

Is HTML5, which is already transforming app development in the desktop, server, and mobile worlds, the standard the car infotainment industry needs? That is one of the questions my colleague, Andy Gryc, will address in his seminar, HTML5 for automotive infotainment: What, why, and how?. The webinar happens tomorrow, November 15. I invite you to check it out.
 

Tech-nimble

After working more than 20 years in high tech, I've settled on a mantra: This too shall pass. (Hey, I didn’t say it was original!) To that end, patience is critical, as is flexibility. And ultimately, success depends less on predicting technology trends and more on responding to them. You've got to be tech-nimble, which requires not only the willingness to change, but the technology to accommodate — and profit from — that change.

Yesterday, Adobe announced a restructuring based on a change in direction, from mobile Flash to HTML5. Some might consider this development as proof that Adobe lost the battle to Steve Jobs. But to my mind, they've simply recognized a trend and responded decisively. Adobe has built a product portfolio based heavily on tooling, including tools for HTML5 development. So they definitely fall into the tech-nimble category.

QNX has an even greater responsibility to remain tech-nimble because so many OEMs use our technology as a platform for their products. Our technology decisions have an impact that ripples throughout companies building in-car infotainment units, patient monitoring systems, industrial terminals, and a host of other devices.

So back to the Flash versus HTML 5 debate. QNX is in a great position because our universal application platform approach enables us to support new technologies quickly, with minimal integration effort. This flexibility derives in part from our underlying architecture, which allows OS services to be cleanly separated from the applications that access them.

Today, our platform supports apps based on technologies such as Flash, HTML5, Qt, native C/C++, and OpenGL ES. More to the point, it allows our customers to seamlessly blend apps from multiple environments into a single, unified user experience.

Now that’s tech-nimble.