Developing software for safety-critical systems? Have I got a book for you

Paul Leroux

Chris Hobbs is the only person I know who holds a math degree with a specialization in mathematical philosophy. In fact, before I met him, I didn’t know such a thing even existed. But guess what? That’s one of the things I really like about Chris. The more I hang out with him, the more I learn.

Come to think of it, helping people learn has become something of a specialty for Chris. He is, for example, a flying instructor and the author of Flying Beyond: The Canadian Commercial Pilot Textbook. And, as a software safety specialist at QNX Software Systems, he regularly provides advice to customers building systems that must comply with functional safety standards like IEC 61508, EN 5012x, and ISO 26262.

Chris has already written a number of papers on software safety, some of which I have had the great privilege to edit. You can find several of them on the QNX website. But recently, Chris upped the ante and wrote an entire book on the subject, titled Embedded Software Development for Safety-Critical Systems. The book:

• covers the development of safety-critical systems under ISO 26262, IEC 61508, EN 50128, and IEC 62304
• helps readers understand and apply remarkably esoteric development practices and be prepared to justify their work to external auditors
• discusses the advantages and disadvantages of architectural and design practices recommended in the standards, including replication and diversification, anomaly detection, and so-called “safety bag” systems
• examines the use of open-source components in safety-critical systems

I haven’t yet had a chance to review the book, but at 358 pages, it promises to be a substantial read.

Interested? Well, you can’t get the book just yet. But you can pre-order it today and get one of the first copies off the press. It’s scheduled for release September 1.

Read More

Getting in sync with brought-in devices

Building a head unit that needs to sync with smartphones, media players, memory cards, and USB sticks? With the QNX CAR Platform, you won’t be left to your own devices.

Paul Leroux

In previous posts, I discussed how the QNX CAR Platform for Infotainment is adept at juggling multiple concurrent tasks. For instance, it can perform 3D navigation, process voice signals, provide active noise control, display vehicle data, manage audio, run multiple application environments, and still deliver a fast, responsive user experience. If that’s not enough, it can also detect and play content from an array of media devices, including local drives, SD cards, and iPods, as well as Bluetooth, DLNA, and MTP devices.

When plugging a media device into a car’s head unit, most users expect immediate access to the device content; they also want to browse the content by metadata, such as genre, title, or artist. To present this content, the head unit must perform metadata synching. The question is, how can the head unit make the content instantly available, even when the media device contains thousands of files that may take many seconds or even minutes to fully synchronize?

To complicate matters, users often want to switch from one media source to another. For instance, a user listening to music stored on a DLNA device may ask the head unit to switch to an Internet radio station. From the user’s perspective, the switch should be fast, simple, and intuitive.

Handling device attachments (and

detachments) gracefully.

The head unit must also cope with the vagaries of user behavior. For instance, if the user yanks out a USB media stick during synching or playback, the system should recover gracefully; it should also provide appropriate feedback, such as displaying a menu that asks the user to choose from another media source. Likewise, if the user yanks out the media device and re-inserts it, the system shouldn’t get confused. Rather, it should simply resume synching content where it left off.

Handling scenarios like these is the job of the QNX CAR Platform’s multimedia architecture.

Architecture at a glance
The multimedia architecture integrates several software components to automatically detect media devices, synchronize metadata with media databases, browse the contents of devices, and, of course, play audio and video files. Together, these components form three layers:

• Human machine interface, or HMI

• Multimedia components

• OS services

Let’s look at each of these layers in turn, starting with the HMI.

At the top of the HMI layer, you’ll see the Media Player, a reference application that allows end-users to control media browsing and playback. Developers can customize this player or write their own player apps, using APIs provided by the QNX CAR Platform.

The Media Player comes in two flavors, HTML5 and Qt 5. To communicate with the architecture’s multimedia engine (mm-player), the HTML5 version uses the car.mediaplayer JavaScript API while the Qt version uses the QPlayer library. In addition to these interfaces, custom apps can use the multimedia engine’s C API. All three interfaces — car.mediaplayer, QPlayer, and C API — provide an abstraction layer that allows a media player app to:

• retrieve a list of accessible media sources: local drives, USB storage devices, iPods, etc.

• retrieve track metadata: artist name, album name, track title, etc.

• start and stop playback

• jump to a specific track

• handle updates in playback state, media sources, and track position

The interfaces that provide access to these operations aren’t specific to any device type, so player apps can work with a wide variety of media hardware.

The media player can quickly access and display a variety of metadata (artist name, album name, track title, etc.) stored in a small-footprint SQL database.

Multimedia components layer
If you look at the top of the multimedia components layer, you’ll see a box labeled mm-player; this is the architecture’s media browsing and playback engine. The mm-player does the dirty work of retrieving metadata, starting playback, jumping to a specific track, etc., which makes custom player apps easier to design. It also supports a large variety of media sources, including:

• local drives

• USB storage devices

• Apple iPod devices

• DLNA devices, including phones and media players

• MTP devices, including PDAs and media players

• devices paired through Bluetooth

To perform media operations requested by a client media player, mm-player works in concert with several lower-level components that help navigate media-store file systems, read metadata from media files, and manage media flows during playback. The components include a series of plugins (POSIX, AVRCP, DLNA, etc.) that interface with different device types. For instance, let’s say you insert an SD card. The POSIX plugin supports this type of device, so it will learn of the insertion and inform mm-player of the newly connected media source; it will also support any subsequent media operations on the SD card.

If you look again at the diagram, you’ll see several other components that provide services to mm-player. These include:

• mm-detect — discovers media devices and initiates synchronization of metadata
• mm-sync — synchronizes metadata from tracks and playlists on media devices into small-footprint SQL databases called QDB databases
• mm-renderer — plays audio and video tracks, and reports playback state
• io-audio — starts audio device drivers to enable the output of audio streams

OS services layer
The lowest layer of the multimedia architecture includes device drivers and protocol stacks that, among other things, detect whether the user has inserted or removed any media device. The following diagram summarizes what happens when one of these services detects an insertion:

1. User inserts the device.
2. The corresponding driver or protocol stack informs device publishers of the insertion.
3. The publishers write the device information to Persistent Publish Subscribe (PPS) objects in a directory monitored by the mm-detect service. (Read my previous posts here and here to learn how QNX PPS messaging enables loosely coupled, easy-to-extend designs.)
4. To start synchronizing the device’s metadata, mm-detect loads the device’s QDB database into memory and passes the device’s mountpoint and database name to mm-sync.
5. mm-sync synchronizes the metadata of all media files on the device.
6. mm-sync uses media libraries to read file paths and other information from media tracks found on the device. It then copies the extracted metadata into the appropriate database tables and columns. Applications can then query the QDB database to obtain metadata information such as track title and album name.

These steps may describe how the architecture detects and synchronizes with devices, but they can't capture the efficiency of the architecture and how it can deliver a fast, responsive user experience. For that, I invite you to check out this video on the QNX CAR Platform. The section on multimedia synchronization starts at the 1:32 mark, but I encourage you to watch the whole thing to see how the platform performs multimedia operations while concurrently managing other tasks:



Media browsing and playback
I’ve touched on how the multimedia architecture automatically detects and synchronizes devices. But of course, it does a lot more, including media browsing and media playback. To learn more about these features, visit the QNX CAR Platform documentation on the QNX website.

---

Previous posts in the QNX CAR Platform series:
 

• A question of getting there — wherein I examine how the platform gives customers the flexibility to choose from a variety of navigation solutions

• A question of architecture — wherein I discuss how the platform simplifies the challenge of integrating multiple disparate technologies, from graphics to silicon

• A question of concurrency — wherein I address the a priori question: why does the auto industry need a platform like QNX CAR in the first place?

Read More

We showed you so

QNX has been building NFC functionality into concept cars since 2011. 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 2012 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 2011, 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 time
NFC 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.

Read More

QNX rolls out new wireless framework

Framework abstracts the complexity of modem control, enabling embedded developers to upgrade cellular and Wi-Fi hardware without having to rewrite applications.

Paul Leroux

Building cellular or Wi-Fi connectivity into a vehicle is never trivial (read: it can be an outright headache). Take, for example, the large amount of software needed to manage a cellular modem. The software needs to monitor and control power consumption, ensure data throughput and reliability, minimize call drops and call-setup failures, and manage modem reset and recovery — because even the best modems crash.

To complicate matters, modem technology for embedded systems is evolving quickly. Development teams need the freedom to upgrade to newer, more capable modems, without having to rewrite or redesign their applications. Likewise, they need the flexibility to choose the best modem for a particular region, product line, or price point.

Enter the QNX Wireless Framework, which QNX Software Systems released last week. Designed to simplify system design, the framework encapsulates the complexities of modem control through an easy-to-use application programming interface (API). Moreover, the API remains consistent across wireless modules and chipsets, allowing systems to quickly support new cellular or Wi-Fi products from vendors such as Gemalto, Sierra Wireless, Telit Wireless Solutions, and u-blox.

The QNX Wireless Framework can scale to meet a broad range of product requirements.
 

The QNX Wireless Framework is built on technology already deployed in millions of BlackBerry devices, supported by hundreds of mobile carriers, and field-proven in complex wireless environments. Better yet, it's backed by a dedicated, world-class team of wireless experts with hundreds of person-years of experience building carrier-grade mobile products.

To learn more about the QNX Wireless framework:

• read the press release

• read the product overview and product brief

• download the webinar on applying smartphone wireless technology to connected embedded systems

Read More

Building smartphone-caliber connectivity into cars

Paul Leroux

Implementing cellular and Wi-Fi connectivity in a vehicle is never trivial. But with the right technology, the task can become a lot simpler.

When it comes to selling cars, just how important is connectivity? Can the services provided by connected cars, such as Internet radio, remote diagnostics, and real-time traffic information, influence vehicle buying decisions? And if so, how much?

In 2014, telecom giant Telefónica decided to find out. In a survey of 5000 consumers, the company found that 71% of respondents were interested in using, or were already using, connected car services. Other studies report similar findings. Parks Associates, for example, found that 78% of people who already own a connected car will demand connectivity features in their next vehicle.

Of course, “connected car” means different things to different people. It could, for example, refer to a car that has a built-in cellular modem, or to a car that uses the driver’s smartphone to access online services. Moreover, the features offered by my connected car may differ completely from the features offered by your connected car. But no matter what form it takes, or what applications it enables, connectivity in the car can be a challenge to implement. In a recent blog post on LinkedIn, Roger Lanctot of Strategy Analytics attests to this difficulty, stating that nearly every car maker seeking to implement connectivity has stumbled on issues ranging from bad connections and poor user interfaces to interminable delays.

Consider, for example, the challenge of embedding a cellular modem in a vehicle — or any other embedded device, for that matter. Initializing and managing the modem requires a large set of software that, among other things, must:

• handle modem reset and recovery, because even the best modems crash
• monitor and manage power consumption to optimize current draw
• ensure data throughput and reliability
• reduce or eliminate call-drops and call-setup failures

The challenge doesn’t stop there. Network operators, for example, are paying more attention to M2M connections on their networks, thereby increasing the demand for operator-approved modems and modules. Meanwhile, system designers may need to swap out modems to target different regions or price points, or to take advantage of newer, more capable modem technology. The goal, then, is to implement a flexible, future-proofed design that can accommodate such changes with a bare minimum of fuss.

Enter a new webinar hosted by my colleagues Karen Bachman and Leo Forget. In “Applying smartphone wireless technology to connected embedded systems,” they will examine the challenges of embedding wireless connectivity and explore how to address these challenges through software frameworks developed for smartphones and other mobile devices. True to the title, Karen and Leo will look at use cases not just for automotive, but for other industries as well, such as medical and industrial. The bulk of the conversation, though, will focus on common issues that embedded developers face, regardless of the device type they are building.

Attend this webinar to learn about:

• Applications that stand to benefit the most from wireless connectivity
• Challenges and complexity of bringing connectivity to cars and other embedded systems
• Potential security and privacy risks introduced by wireless connectivity, including unauthorized access and unencrypted data transfer
• The benefits of creating flexible products that easily accommodate advances in modem technology

Here are the webinar coordinates:

Applying smartphone wireless technology to connected embedded systems
Thursday, March 26, 2015
12:00 pm to 1:00 pm EST
Register: TechOnLine

Read More

“What do you mean, I have to learn how not to drive?”

The age of autonomous driving lessons is upon us.

Paul Leroux

What would it be like to ride in an autonomous car? If you were to ask the average Joe, he would likely describe a scenario in which he sips coffee, plays video games, and spends quality time with TSN while the car whisks him to work. The average Jane would, no doubt, provide an equivalent answer. The problem with this scenario is that autonomous doesn’t mean driverless. Until autonomous vehicles become better than humans at handling every potential traffic situation, drivers will have to remain alert much or all of the time, even if their cars do 99.9% of the driving for them.

Otherwise, what happens when a car, faced with a situation it can’t handle, suddenly cedes control to the driver? Or what happens when the car fails to recognize a pedestrian on the road ahead?

Of course, it isn’t easy to maintain a high level of alertness while doing nothing in particular. It takes a certain maturity of mind, or at least a lack of ADD. Which explains why California, a leader in regulations for autonomous vehicles, imposes restrictions on who is allowed to “drive” them. Prerequisites include a near-spotless driving record and more than 10 years without a DUI conviction. Drivers must also complete an autonomous driving program, the length of which depends on the car maker or automotive supplier in question. According to a recent investigation by IEEE Spectrum, Google offers the most comprehensive program — it lasts five weeks and subjects drivers to random checks.

1950s approach to improving driver
alertness. Source: Modern Mechanix blog

In effect, drivers of autonomous cars have to learn how not to drive. And, as another IEEE article suggests, they may even need a special license.

Ample warnings
Could an autonomous car mitigate the attention issue? Definitely. It could, for example, give the driver ample warning before he or she needs to take over. The forward collision alerts and other informational ADAS functions in the latest QNX technology concept car offer a hint as to how such warnings could operate. For the time being, however, it’s hard to imagine an autonomous car that could always anticipate when it needs to cede control. Until then, informational ADAS will serve as an adjunct, not a replacement, for eyes, ears, and old-fashioned attentiveness.

Nonetheless, research suggests that adaptive cruise control and other technologies that enable autonomous or semi-autonomous driving can, when compared to human drivers, do a better job of avoiding accidents and improving traffic flow. To quote my friend Andy Gryc, autonomous cars would be more “polite” to other vehicles and be better equipped to negotiate inter-vehicle space, enabling more cars to use the same length of road.

Fewer accidents, faster travel times. I could live with that.


2015 approach to improving driver alertness: instrument cluster from the QNX reference vehicle.

Read More

Hypervisors, virtualization, and taking control of your safety certification budget

A new webinar on how virtualization can help you add new technology to existing designs.

First things first: should you say “hypervisor” or “virtual machine monitor”? Both terms refer to the same thing, but is one preferable to the other?

Hypervisor certainly has the greater sex appeal, suggesting it was coined by a marketing department that saw no hope in promoting a term as coldly technical as virtual machine monitor. But, in fact, hypervisor has a long and established history, dating back almost 50 years. Moreover, it was coined not by a marketing department, but by a software developer.

“Hypervisor” is simply a variant of “supervisor,” a traditional name for the software that controls task scheduling and other fundamental operations in a computer system — software that, in most systems, is now called the OS kernel. Because a hypervisor manages the execution of multiple OSs, it is, in effect, a supervisor of supervisors. Hence hypervisor.

No matter what you call it, a hypervisor creates multiple virtual machines, each hosting a separate guest OS, and allows the OSs to share a system’s hardware resources, including CPU, memory, and I/O. As a result, system designers can consolidate previously discrete systems onto a single system-on-chip (SoC) and thereby reduce the size, weight, and power consumption of their designs — a trinity of benefits known as SWaP.

That said, not all hypervisors are created equal. There are, for example, Type 1 “bare metal” hypervisors, which run directly on the host hardware, and Type 2 hypervisors, which run on top of an OS. Both types have their benefits, but Type 1 offers the better choice for any embedded system that requires fast, predictable response times — most safety-critical systems arguably fall within this category.

The QNX Hypervisor is an example of a Type 1 “bare metal” hypervisor.

Moreover, some hypervisors make it easier for the guest OSs to share hardware resources. The QNX Hypervisor, for example, employs several technologies to simplify the sharing of display controllers, network connections, file systems, and I/O devices like the I²C serial bus. Developers can, as a result, avoid writing custom shared-device drivers that increase testing and certification costs and that typically exhibit lower performance than field-hardened, vendor-supplied drivers.

Adding features, without blowing the certification budget
Hypervisors, and the virtualization they provide, offer another benefit: the ability to keep OSs cleanly isolated from each other, even though they share the same hardware. This benefit is attractive to anyone trying to build a safety-critical system and reduce SWaP. Better yet, the virtualization can help device makers add new and differentiating features, such as rich user interfaces, without compromising safety-critical components.

That said, hardware and peripheral device interfaces are evolving continuously. How can you maintain compliance with safety-related standards like ISO 26262 and still take advantage of new hardware features and functionality?

Enter a new webinar hosted by my inimitable colleague Chris Ault. Chris will examine techniques that enable you to add new features to existing devices, while maintaining close control of the safety certification scope and budget. Here are some of the topics he’ll address:

• Overview of virtualization options and their pros and cons
   
• Comparison of how adaptive time partitioning and virtualization help achieve separation of safety-critical systems
   
• Maintaining realtime performance of industrial automation protocols without directly affecting safety certification efforts
   
• Using Android applications for user interfaces and connectivity

Webinar coordinates:
Exploring Virtualization Options for Adding New Technology to Safety-Critical Devices
Time: Thursday, March 5, 12:00 pm EST
Duration: 1 hour
Registration: Visit TechOnLine

Read More

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 2011, 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.

Read More

Tom’s Guide taps QNX concept car with CES 2015 award

Have you ever checked out a product review on Tom’s Guide? If so, you’re not alone. Every month, this website attracts more than 2.5 million unique visitors — that’s equivalent to the population of Toronto, the largest city in Canada.

The folks at Tom’s Guide test and review everything from drones to 3D printers. They love technology. So perhaps it’s no surprise that they took a shine to the QNX technology concept car. In fact, they liked it so much, they awarded it the Tom’s Guide CES 2015 Award, in the car tech category.

To quote Sam Rutherford of Tom’s Guide, “After my time with QNX’s platform, I was left with the impression there’s finally a company that just “gets it” when it comes to the technology in cars. The company has learned from the success of modern mobile devices and brought that knowledge to the auto world…”.

I think I like this Sam guy.

Engadget was also impressed...

A forward-looking approach to seeing
behind you.

The Tom’s Guide award is the second honor QNX picked up at CES. We were also shortlisted for an Engadget Best of CES award, for the digital rear- and side-view mirrors on the QNX technology concept car.

If you haven’t seen the mirrors in action, they offer a complete view of the scene behind and to the sides of the vehicle — goodbye to the blind spots associated with conventional reflective mirrors. Better yet, the side-view digital mirrors have the smarts to detect cars, bicycles, and other objects, and they will display an alert if an object is too close when the driver signals a lane change.

In addition to the digital mirrors, the QNX technology concept car integrates several other ADAS features, including speed recommendations, forward-collision warnings, and intelligent parking assist. Learn more here.

Read More

Volkswagen and LG Gear up with QNX

Design wins put QNX technology in a wide range of infotainment systems, instrument clusters, and ADAS solutions.

Earlier today, QNX Software Systems announced that infotainment systems powered by the QNX Neutrino OS are now shipping in several 2015 Volkswagen vehicle models, including the Touareg, Passat, Polo, Golf, and Golf GTI.

The systems include the RNS 850 GPS navigation system in the Volkswagen Touareg, which recently introduced support for 3D Google Earth maps and Google Street View. The system also offers realtime traffic information, points-of-interest search, reverse camera display, voice control, Bluetooth connectivity, rich multimedia support, four-zone climate control, a high-resolution 8-inch color touchscreen, and other advanced features.

Bird's eye view: the RNS 850 GPS navigation system for the Volkswagen Touareg SUV. Source: VW

“At Volkswagen, we believe deeply in delivering the highest quality driving experience, regardless of the cost, size, and features of the vehicle,” commented Alf Pollex, Head of Connected Car and Infotainment at Volkswagen AG. “The scalable architecture of the QNX platform is well-suited to our approach, enabling us to offer a full range of infotainment systems, from premium level to mass volume, using a single, proven software base for our Modular Infotainment Modules (MIB) and the RNS 850 system.”

QNX and LG: a proven partnership
QNX also announced that LG Electronics’ Vehicle Components (VC) Company will use a range of QNX solutions to build infotainment systems, digital instrument clusters, and advanced driver assistance systems (ADAS) for the global automotive market.

The new initiative builds on a long history of collaboration between LG and QNX Software Systems, who have worked together on successful, large-volume telematics production programs. For the new systems, QNX will provide LG with the QNX CAR Platform for Infotainment, the QNX Neutrino OS, the QNX OS for Automotive Safety, and QNX Acoustics for Voice.

“QNX Software Systems has been our trusted supplier
for more than a decade... helping LG deliver millions
of high-quality systems to the world’s automakers”
— Won-Yong Hwang, LG's VC Company
“QNX Software Systems has been our trusted supplier for more than a decade, providing flexible software solutions that have helped LG deliver millions of high-quality systems to the world’s automakers,” commented Won-Yong Hwang, Director and Head of AVN development department, LG Electronics’ VC Company. “This same flexibility allows us to leverage our existing QNX expertise in new and growing markets such as ADAS, where the proven reliability of QNX Software Systems’ technology can play a critical role in addressing automotive safety requirements.”

Visit the QNX website to learn more about the Volkswagen and LG announcements.

Read More

To infotainment... and beyond! First look at new QNX technology concept car

The new car delivers everything you’d expect in a concept vehicle from QNX. But the real buzz can be summarized in a four-letter word: ADAS

The technology in today's cars is light-years ahead of the technology in cars 10 or 20 years ago. The humans driving those cars, however, have changed little in the intervening years. They still need to focus on a host of mundane driving tasks, from checking blind spots and monitoring road signs to staying within the lane and squeezing into parking spaces. In fact, with all the technology now in the car, including a variety of brought-in devices, some drivers suffer from information overload and perform worse, instead of better, at these crucial tasks.

Advanced driver assistance systems, or ADAS, can go a long way to offset this problem. They come in a variety of shapes and sizes — from drowsiness monitoring to autonomous emergency braking — but most share a common goal: to help the driver avoid accidents.

Which brings us to the new QNX technology concept car. As you’d expect, it includes all the advanced infotainment features, including smartphone connectivity and rich app support, offered by the QNX CAR Platform for Infotainment. But it also integrates an array of additional technologies — including cameras, LiDAR, ultrasonic sensors, and specialized navigation software — to deliver ADAS capabilities that simplify driving tasks, warn of possible collisions, and enhance overall driver awareness.

Mind you, the ADAS features shouldn’t come as any more of a surprise than the infotainment features. After all, QNX Software Systems also offers the QNX OS for Automotive Safety, a solution based on decades of experience in safety-critical systems and certified to ISO 26262, Automotive Safety Integrity Level D — the highest level achievable.

Okay, enough blather. Time to check out the car!

The “I want that” car
If the trident hasn’t already tipped you off, the new technology concept car is based on a Maserati QuattroPorte GTS. I won’t say much about the car itself, except I want one. Did I say want? Sorry, I meant lust. Because omigosh:



The differentiated dash
Before we run through the car’s many features, let’s stop for a minute and savor the elegant design of its QNX-powered digital instrument cluster and infotainment system. To be honest, I have an ulterior motive for sharing this image: if you compare the systems shown here to those of previous QNX technology concept cars (here, here, and here), you’ll see that they each project a distinct look-and-feel. Automakers need to differentiate themselves, and, as a group, these cars illustrate how the flexibility of the QNX platform enables unique, branded user experiences:



The multi-talented digital instrument cluster
Okay, let’s get behind the wheel and test out the digital cluster. Designed to heighten driver awareness, the cluster can show the current speed limit, display an alert if you exceed the limit, and even recommend an appropriate speed for upcoming curves. Better yet, it can display turn-by-turn directions provided by the car’s infotainment system.

Normally, the cluster displays the speed limit in a white circle. But in this image, the cluster displays it in red, along with a red bar to show how much you are over the limit — a gentle reminder to ease off the gas:



Using LiDAR input, the cluster can also warn of obstacles on the road ahead:



And if that’s not enough, the cluster provides intelligent parking assist to help you back into tight spaces. Here, for example, is an impromptu image we took in the QNX garage. The blue-and-yellow guidelines represent the car’s reverse trajectory, and the warning on right says that you are about to run over an esteemed member of the QNX concept team!



The rear- and side-view mirrors that aren’t really mirrors
By their very nature, car mirrors have blind spots. To address this problem, the QNX concept team has transformed the car’s rear- and side-view mirrors into video displays that offer a complete view of the scene behind and to the sides of the vehicle. As you can see in this image, the side-view displays can also display a red overlay to warn of cars, bikes, people, or anything else approaching the car’s blind zones:



The ADAS display for enhancing obstacle awareness
I don’t have pictures yet, but the car also includes an innovative LED-based display lets you gauge the direction and proximity of objects to the front, rear, and sides of the vehicle — without having to take your eyes off the road. Stretching the width of the dash, the display integrates input from the car’s ultrasonic and LiDAR sensors to provide a centralized view of ADAS warnings.

The easy-to-use infotainment system
To demonstrate the capabilities of the QNX CAR™ Platform for Infotainment, we’ve outfitted the car with a feature-rich, yet intuitive, multimedia head unit. For instance, see the radio tuner in the following image? That’s no ordinary tuner. To change channels, you can just swipe across the display; if your swipe isn’t perfectly accurate, the radio will automatically zero in on the nearest station or preset.

Better yet, the radio offers “iHeart drive anywhere radio.” If you drive out of range of your favorite AM/FM radio station, the system will detect the problem and automatically switch to the corresponding digital iHeartRadio station. How cool is that?



Other infotainment features include:

• Natural voice recognition — For instance, if you say “It’s way too cold in here,” the HVAC system will respond by raising the heat.
• Integration with a wide variety of popular smartphones.
• Support for multiple concurrent app environments, along with a variety of Android and HTML5 apps, as well as an HMI built with the Qt framework.
• A backseat display that lets passengers control HVAC functions, navigation, song selection, and other infotainment features.

The oh-so-awesome partners
The car is a testament not only to QNX technology, but to the ecosystem of technology partners that provide complementary solutions for QNX customers. Peek under the hood, and you'll find the latest tech from Elektrobit, iHeart, Nuance, Pandora, Parkopedia, Phantom Intelligence, Qualcomm, RealVNC, Rightware, and TE Connectivity.

The other stuff
Do not, for one minute, think that the Maserati is the only attraction in the QNX booth. Far from it. We will also showcase a significantly revamped QNX reference vehicle, outfitted with lane departure warnings, traffic sign recognition, and other ADAS features, as well as the latest version of the QNX CAR Platform — more in an upcoming post.

Visitors to the booth will also have the opportunity to experience:

• a 3D navigation solution from Aisin AW
• a digital instrument cluster designed by HI Corporation
• two QNX CAR Platform demo systems, one powered by a dual-core Intel Atom E3827 processor, the other by an NVIDIA Tegra Visual Computing Module
• the latest incarnation of the Oscar-winning Flying Cam SARAH aerial camera system

Read More

There’s experience, and then there’s experience

Or how a single word can have a trunkful of meanings.

"Liked your blog post. It was so random.” That, believe it or not, is one of the nicest things anyone has ever said to me. You may think it funny that I see this as a compliment. But truth be told, randomness is part of my mental DNA — as anyone who has attempted to hold a conversation with me can attest. Even Google seems to agree. A few years ago, they temporarily closed my Blogger account because, according to their algorithms, my posts consisted of random, machine-generated words. I kid you not.

So why am I going on about this? Well, someone asked me about QNX Software Systems’ experience in the automotive market and, sure enough, my mind went off in several directions all at once. Not that that’s unusual. In this case, however, there was justification for my response. Because when it comes to cars and QNX, experience has a rich array of meanings.

First, there is the deep experience that QNX amassed in the automotive industry. We’ve been at it for 15 years, working hand-in-hand with car makers and tier one suppliers to create infotainment systems, digital instrument clusters, connectivity modules, and handsfree units for tens of millions of vehicles.

Next, there’s the experience of working with QNX the company. In the auto industry, almost every automaker and tier one supplier has unique demands — not to mention immovable deadlines. As a result, they need a supplier, like QNX, that’s deeply committed to the success of their projects, and that can provide the expert engineering services they need to meet start-of-production commitments. No shrink-wrapped solutions for this crowd.

Then, there’s the experience of using QNX technology to build automotive systems — or any type of system, for that matter. Take the QNX OS, for example. Its microkernel architecture makes it easier to isolate and repair bugs, its industry-standard APIs make it easy to port or reuse existing code, and its persistent publish/subscribe technology offers a highly flexible approach to integrating high-level applications with low-level business logic and services.

And last, there’s the experience of using systems based on QNX technology. One reason we build technology concept cars is because words cannot express the rich, integrated user experiences that our technology can enable — experiences that blend graphics, acoustics, touch interfaces, natural language processing, and other technologies to make driving simpler and more convenient.

Nor can words express the sheer variety of user experiences that our platform makes possible. If you look at the QNX-powered infotainment systems that automakers ship today, it soon becomes obvious that they aren’t cookie-cutter systems. Rather, each system projects the unique values, features, and brand identity of the automaker. For evidence, look no further than GM OnStar and the Audi Virtual Cockpit. They are totally distinct from each other, yet both are built on the very same OS platform.

On a personal note, I must mention one last form of experience: that of working with my QNX colleagues. Because that, to me, is the most wonderful experience of all.

Read More

QNX celebrates crystal anniversary in automotive

Long-term success in the auto market relies on a potent mix of passion, persistence, innovation, and quality. And let's not forget trust.

Imagine, for a minute, that you are a bird. Not just any bird, but a bird that can fly 11,000 kilometers, non-stop, without food or rest.

That’s hard to imagine, I know. But the bird in question — the bar-tailed godwit — is very real, and its ability to fly across vast distances is well documented. Every year, as winter approaches, the godwit lifts off from its breeding grounds in Alaska, bears southwest, and doesn't stop beating its wings until it touches down in New Zealand. Total uninterrupted flight time: 216 hours.

The godwit epitomizes indomitable drive, infused with a dose of pure stick-with-it-ness. Qualities that, to me, characterize QNX Software Systems’ success in the auto market — a story that took flight 15 years ago.

Bar-tailed godwit: long-distance champion
© Andreas Trepte

It all started in 1999, when Motorola and QNX unveiled mobileGT, an automotive reference platform based on the QNX Neutrino OS. For the first time, QNX publicly threw its hat into the automotive ring. Mind you, QNX was already busy behind the scenes: 1999 also marked the first year that QNX technology shipped in passenger vehicles. It’s been a steady climb ever since, and you can now find QNX technology in tens of millions of vehicles.

There are many technical reasons why QNX has become a premier software provider for the automotive market. But for automakers and their tier one suppliers, technology alone isn’t enough. They also need to know that, as a supplier, you are deeply committed to the success of their projects — like the flight of the godwit, bailing out halfway isn’t an option. They also need to trust that, when you say you’ll do something, you will. And that you’ll do it on time. Even if you have to cross an ocean to do it.

In short, you might enter this market because of your skills and passion, but you thrive in it because you behave as a real partner, working in concert with your customers and fellow technology suppliers. That’s why I refer to our fifteenth anniversary in the car business with the same language used to describe a fifteenth wedding anniversary. Because we’re committed, we’re passionate, and we’re in for the long haul.

Read More

The power of together

Bringing more technologies into the car is all well and good. The real goal, however, is to integrate them in a way that genuinely improves the driving experience.

Can we all agree that ‘synergy’ has become one of the most misused and overused words in the English language? In the pantheon of verbal chestnuts, synergy holds a place of honor, surpassed only by ‘best practices’ and ‘paradigm shift’.

Mind you, you can’t blame people for invoking the word so often. Because, as we all know, the real value in things often comes from their interaction — the moment they stop acting alone and start working in concert. The classic example is water, yeast, and flour, a combination that yields something far more flavorful than its constituent parts. I am speaking, of course, of bread.

Automakers get this principle. Case in point: adaptive cruise control, which takes a decades-old concept — conventional cruise control — and marries it with advances in radar sensors and digital signal processing. The result is something that doesn’t simply maintain a constant speed, but can help reduce accidents and, according to some research, traffic jams.

At QNX Software Systems, we also take this principle to heart. For example, read my recent post on the architecture of the QNX CAR Platform and you’ll see that we consciously designed the platform to help things work together. In fact, the platform's ability to integrate numerous technologies, in a seamless and concurrent fashion, is arguably its most salient quality.

This ability to blend disparate technologies into a collaborative whole isn't just a gee-whiz feature. Rather, it is critical to enabling the continued evolution and success of the connected car. Because it’s not enough to have smartphone connectivity. Or cloud connectivity. Or digital instrument clusters. Or any number of ADAS features, from collision warnings to autonomous braking. The real magic, and real value to the consumer, occurs when some or all of these come together to create something greater than the sum of the parts.

Simply put, it's all about the — dare I say it? — synergy that thoughtful integration can offer.

At CES this year, we will explore the potential of integration and demonstrate the unexpected value it can bring. The story begins on the QNX website.

Read More

Beyond the dashboard: discover how QNX touches your everyday life

QNX technology is in cars — lots of them. But it’s also in everything from planes and trains to smart phones, smart buildings, and smart vacuum cleaners. If you're interested, I happen to have an infographic handy...

I was a lost and lonely soul. Friends would cut phone calls short, strangers would move away from me on the bus, and acquaintances at cocktail parties would excuse themselves, promising to come right back — they never came back. I was in denial for a long time, but slowly and painfully, I came to the realization that I had to take ownership of this problem. Because it was my fault.

To by specific, it was my motor mouth. Whenever someone asked what I did for a living, I’d say I worked for QNX. That, of course, wasn’t a problem. But when they asked what QNX did, I would hold forth on microkernel OS architectures, user-space device drivers, resource manager frameworks, and graphical composition managers, not to mention asynchronous messaging, priority inheritance, and time partitioning. After all, who doesn't want to learn more about time partitioning?

Well, as I subsequently learned, there’s a time and place for everything. And while my passion about QNX technology was well-placed, my timing was lousy. People weren’t asking for a deep dive; they just wanted to understand QNX’s role in the scheme of things.

As it turns out, QNX plays a huge role, and in very many things. I’ve been working at QNX Software Systems for 25 years, and I am still gobsmacked by the sheer variety of uses that QNX technology is put to. I'm especially impressed by the crossover effect. For instance, what we learn in nuclear plants helps us offer a better OS for safety systems in cars. And what we learn in smartphones makes us a better platform supplier for companies building infotainment systems.

All of which to say, the next time someone asks me what QNX does, I will avoid the deep dive and show them this infographic instead. Of course, if they subsequently ask *how* QNX does all this, I will have a well-practiced answer. :-)

Did I mention? You can download a high-res JPEG of this infographic from our Flickr account and a PDF version from the QNX website.



Stay tuned for 2015 CES, where we will introduce even more ways QNX can make a difference, especially in how people design and drive cars.

And lest I forget, special thanks to my colleague Varghese at BlackBerry India for conceiving this infographic, and for the QNX employees who provided their invaluable input.

Read More

A question of getting there

The third of a series of posts on the QNX CAR Platform. In this installment, we turn to a key point of interest: the platform’s navigation service.

From the beginning, we designed the QNX CAR Platform for Infotainment with flexibility in mind. Our philosophy is to give customers the freedom to choose the hardware platforms, application environments, user-interface tools, and smartphone connectivity protocols that best address their requirements. This same spirit of flexibility extends to navigation solutions.

For evidence, look no further than our current technology concept car. It can support navigation from Elektrobit:



from Nokia HERE:



and from Kotei Informatics:



These are but a few examples. The QNX CAR Platform can also support navigation solutions from companies like AISIN AW, NavNGo, TCS, TeleNav, and ZENRIN DataCom, enabling automakers and automotive Tier 1 suppliers to choose the navigation solution, or solutions, best suited to the regions or demographics they wish to target. (In addition to these embedded solutions, the platform can also provide access to smartphone-based navigation services through its support for MirrorLink and other connectivity protocols — more on this in a subsequent post.)

Under the hood
In our previous installment, we looked at the QNX CAR Platform’s middleware layer, which provides infotainment applications with a variety of services, including Bluetooth, radio, multimedia discovery and playback, and automatic speech recognition. The middleware layer also includes a navigation service that, true to the platform’s overall flexibility, allows developers to use navigation engines from multiple vendors and to change engines without affecting the high-level navigation applications that the user interacts with.

An illustration is in order. If you look the image below, you’ll see OpenGL-based map data rendered on one graphics layer and, on the layer above it, Qt-based application data (current street, distance to destination, and other route information) pulled from the navigation engine. By taking advantage of the platform’s navigation service, you could swap in a different navigation engine without having to rewrite the Qt application:



To achieve this flexibility, the navigation service makes use of the QNX CAR Platform’s persistent/publish subscribe (PPS) messaging, which cleanly abstracts lower-level services from the higher-level applications they communicate with. Let's look at another diagram to see how this works:



In the PPS model, services publish information to data objects; other programs can subscribe to those objects and receive notifications when the objects have changed. So, for the example above, the navigation engine could generate updates to the route information, and the navigation service could publish those updates to a PPS “navigation status object,” thereby making the updates available to any program that subscribes to the object — including the Qt application.

With this approach, the Qt application doesn't need to know anything about the navigation engine, nor does the navigation engine need to know anything about the Qt app. As a result, either could be swapped out without affecting the other.

Here's another example of how this model allows components to communicate with one another:

1. Using the system's human machine interface (HMI), the drivers asks the navigation system to search for a point of interest (POI) — this could take the form of a voice command or a tap on the system display.
2. The HMI responds by writing the request to a PPS “navigation control” object.
3. The navigation service reads the request from the PPS object and forwards it to the navigation engine.
4. The navigation engine returns the result.
5. The navigation service updates the PPS object to notify the HMI that its request has been completed. It also writes the results to a database so that all subscribers to this object can read the results.

By using PPS, the navigation service can make details of the route available to a variety of applications. For instance, it could publish trip information that a weather app could subscribe to. The app could then display the weather forecast for the destination, at the estimated time of arrival.

To give developers a jump start, the QNX CAR Platform comes pre-integrated with Elektrobit’s EB street director navigation software. This reference integration shows developers how to implement "command and control" between the HMI and the participating components, including the navigation engine, navigation service, window manager, and PPS interface. As the above diagram indicates, the reference implementation works with both of the HMIs — one based on HTML5, the other based on Qt — that the QNX CAR Platform supports out of the box.

---

Previous posts in the QNX CAR Platform series:

• A question of architecture
  
• A question of concurrency

Read More