A matter of convergence: building digital instrument clusters with Qt on QNX

Tuukka Turunen

Guest post by Tuukka Turunen, Head of R&D at The Qt Company

The Qt application framework is widely used in automotive infotainment systems with a variety of operating system and hardware configurations. With digital instrument clusters becoming increasingly common in new models, there are significant synergies to be gained from using the same technologies for both the infotainment system and the cluster. To be able to do this, you need to choose technologies, such as Qt and QNX, that can easily address the requirements of both environments.

Qt is the leading cross-platform technology for the creation of applications and user interfaces for desktop, mobile, and embedded systems. Based on C++, the Qt framework provides fast native performance via a versatile and efficient API. It’s easy to create modern, hardware-accelerated user interfaces using Qt Quick user interface technology and its QML language. Qt comes with an integrated development environment (IDE) tailored for developing applications and embedded devices. Leveraging the QNX Neutrino Realtime OS to run Qt provides significant advantages for addressing the requirements of functional safety.

There is a strong trend in the automotive industry to create instrument clusters using digital graphics rather than traditional electromechanical and analog gauges. Unlike the first digital clusters in the 70s, which used 7-segment displays to indicate speed, today’s clusters typically show a digital representation of the analog speedometer along with an array of other information, such as RPM, navigation, vehicle information, and infotainment content. The benefits compared to analog gauges are obvious; for example, it is possible to adapt the displayed items according to the driver’s needs in different situations, or easily create regional variants, or adapt the style of the instrument cluster to the car model and user’s preferences.

A unified experience — for both developers and users
Traditionally, the speedometer and radio have been two very different systems, but today their development paths are converging. Convergence will drive the need for consistency as otherwise the user experience will be fragmented. To meet the needs of tomorrow’s vehicles, it is essential that the two screens are aware of each other and interoperate. It is also likely that, while these are converging, certain items will remain specific to each domain. Furthermore, the convergence will help accelerate time-to-market for car manufacturers by offering simplified system design and faster development cycles.

Qt, which is already widely used in state-of-the-art in-vehicle infotainment systems and many other complex systems, is an excellent technology to unify the creation of these converging systems. By leveraging the same versatile Qt framework and tools for both the cluster and the infotainment system, it is possible to achieve synergies in the engineering work as well as in the resulting application. With the rich graphics capabilities of Qt, creating attractive user interfaces for a unified experience across all screens of the vehicle cockpit becomes a reality.


Cluster demonstrator built with Qt 5.6.

Maximal efficiency
Qt has been used very successfully in QNX-based automotive and general embedded systems for a long time. To show how well Qt 5.6 and our latest Qt based cluster demonstrator run on top of the QNX OS, which is pre-certified to ISO 26262 ASIL D, we brought them together on NXP’s widely used i.MX 6 processor. As the cluster HMI is made with Qt, it runs on any platform supported by Qt, including the QNX OS, without having to be rewritten.

The cluster demonstrator leverages Qt Quick for most of the cluster and Qt 3D for the car model. The application logic is written in C++ for maximal efficiency. By using the Qt Quick Compiler, the QML parts run as efficiently as if they too were written in C++, speeding up the startup time by removing the run-time compilation step.

The following video presents the cluster demonstrator running on the QNX OS and the QNX Screen windowing system:



The QNX OS for Safety has been certified to both IEC 61508 SIL 3 and ISO 26262 ASIL D, so it provides a smooth and straightforward path for addressing the functional safety certification of an automotive instrument cluster.

Qt 5.6 has been built for the QNX OS using the GCC toolchain provided by QNX Software Systems. The display of the cluster is a 12.3" HSXGA (1280×480) screen and the CPU is NXP’s i.MX 6 processor, which is well-suited to automotive instrument clusters.

Our research and development efforts continue with a goal to make it straightforward to build sophisticated digital instrument clusters with Qt. We believe that Qt is the best choice for building infotainment systems and clusters, but that it is particularly beneficial when used in both of these. Please contact us to discuss how Qt can be used in automotive, as well as in other industries, or to evaluate the latest Qt version on the QNX platform.

Visit qt.io for more information on Qt.

---

About Tuukka
Tuukka Turunen leads R&D at The Qt Company. He holds a Master’s of Science in Engineering and a Licentiate of Technology from the University of Oulu, Finland. He has over 20 years of experience working in a variety of positions in the software industry, especially around connected embedded systems.

Goodbye analog, hello digital

Since 2008, QNX has explored how digital instrument clusters will change the driving experience.

Paul Leroux

Quick: What do the Alfa Romeo 4C, Audi TT, Audi Q7, Corvette Stingray, Jaguar XJ, Land Rover Range Rover, and Mercedes S Class Coupe have in common?

Answer: They would all look awesome in my driveway! But seriously, they all have digital instrument clusters powered by the QNX Neutrino OS.

QNX Software Systems has established a massive beachhead in automotive infotainment and telematics, with deployments in over 60 million cars. But it’s also moving into other growth areas of the car, including advanced driver assistance systems (ADAS), multi-function displays, and, of course, digital instrument clusters.

Retrofitting the QNX reference
vehicle with a new digital cluster.

The term “digital cluster” means different things to different people. To boomers like myself, it can conjure up memories of 1980s dashboards equipped with less-than-sexy segment displays — just the thing if you want your dash to look like a calculator. Thankfully, digital clusters have come a long way. Take, for example, the slick, high-resolution cluster in the Audi TT. Designed to display everything directly in front of the driver, this QNX-powered system integrates navigation and infotainment information with traditional cluster readouts, such as speed and RPM. It’s so advanced that the folks at Audi don’t even call it a cluster — they call it virtual cockpit, instead.

Now here’s the thing: digital clusters require higher-end CPUs and more software than their analog predecessors, not to mention large LCD panels. So why are automakers adopting them? Several reasons come to mind:

• Reusable — With a digital cluster, automakers can deploy the same hardware across multiple vehicle lines simply by reskinning the graphics.
• Simple — Digital clusters can help reduce driver distraction by displaying only the information that the driver currently requires.
• Scalable — Automakers can add functionality to a digital cluster by changing the software only; they don’t have to incur the cost of machining or adding new physical components.
• Attractive — A digital instrument cluster can enhance the appeal of a vehicle with eye-catching graphics and features.
   

In addition to these benefits, the costs of high-resolution LCD panels and the CPUs needed to drive them are dropping, making digital instrument clusters an increasingly affordable alternative.

2008: The first QNX cluster
It’s no coincidence that so many automakers are using the QNX Neutrino OS in their digital clusters. For years now, QNX Software Systems has been exploring how digital clusters can enhance the driving experience and developing technologies to address the requirements of cluster developers.

Let’s start with the very first digital cluster that the QNX team created, a proof-of-concept that debuted in 2008. Despite its vintage, this cluster has several things in common with our more recent clusters — note, for example, the integrated turn-by-turn navigation instructions:



For 2008, this was pretty cool. But as an early proof-of-concept, it lacked some niceties, such as visual cues that could suggest which information is, or isn’t, currently important. For instance, in this screenshot, the gauges for fuel level, engine temperature, and oil pressure all indicate normal operation, so they don’t need to be so prominent. They could, instead, be shrunk or dimmed until they need to alert the driver to a critical change — and indeed, we explored such ideas soon after we created the original design. As you’ll see, the ability to prioritize information for the driver becomes quite sophisticated in subsequent generations of our concept clusters.

Did you know? To create this 2008 cluster, QNX engineers used Adobe Flash Lite 3 and OpenGL ES.

2010: Concept cluster in a Chevrolet Corvette
Next up is the digital cluster in the first QNX technology concept car, based on a Chevrolet Corvette. If the cluster design looks familiar, it should: it’s modeled after the analog cluster that shipped in the 2010-era ‘Vettes. It’s a great example of how a digital instrument cluster can deliver state-of-the-art features, yet still honor the look-and-feel of an established brand. For example, here is the cluster in “standard” mode, showing a tachometer, just as it would in a stock Corvette:



And here it is again, but with something that you definitely wouldn’t find in a 2010 Corvette cluster — an integrated navigation app:



Did you know? The Corvette is the only QNX technology concept car that I ever got to drive.

2013: Concept cluster in a Bentley Continental GT
Next up is the digital cluster for the 2013 QNX technology concept car, based on a Bentley Continental GT. This cluster took the philosophy embodied in the Corvette cluster — honor the brand, but deliver forward-looking features — to the next level.

Are you familiar with the term Trompe-l’œil? It’s a French expression that means “deceive the eye” and it refers to art techniques that make 2D objects appear as if they are 3D objects. It’s a perfect description of the gorgeously realistic virtual gauges we created for the Bentley cluster:



Because it was digital, this cluster could morph itself on the fly. For instance, if you put the Bentley in Drive, the cluster would display a tach, gas gauge, temperature gauge, and turn-by-turn directions — the cluster pulled these directions from the head unit’s navigation system. And if you threw the car into Reverse, the cluster would display a video feed from the car’s backup camera. The cluster also had other tricks up its digital sleeve, such as displaying information from the car’s media player.

Did you know? The Bentley came equipped with a 616 hp W12 engine that could do 0-60 mph in a little over 4 seconds. Which may explain why they never let me drive it.

2014: Concept cluster in a Mercedes CLA45 AMG

Plymouth safety speedometer, c 1939

Up next is the 2014 QNX technology concept car, based on Mercedes CLA45 AMG. But before we look at its cluster, let me tell you about the Plymouth safety speedometer. Designed to curb speeding, it alerted the driver whenever he or she leaned too hard on the gas.

But here’s the thing: the speedometer made its debut in 1939. And given the limitations of 1939 technology, the speedometer couldn’t take driving conditions or the local speed limit into account. So it always displayed the same warnings at the same speeds, no matter what the speed limit.

Connectivity to the rescue! Some modern navigation systems include information on local speed limits. By connecting the CLA45’s concept cluster to the navigation system in the car’s head unit, the QNX team was able to pull this information and display it in real time on the cluster, creating a modern equivalent of Plymouth's 1939 invention.

Look at the image below. You’ll see the local speed limit surrounded by a red circle, alerting the driver that they are breaking the limit. The cluster could also pull other information from the head unit, including turn-by-turn directions, trip information, album art, and other content normally relegated to the center display:



Did you know? Our Mercedes concept car is still alive and well in Germany, and recently made an appearance at the Embedded World conference in Nuremburg.

2015: Concept cluster in a Maserati Quattroporte
Up next is the 2015 QNX technology concept car, based on a Maserati Quattroporte GTS. Like the cluster in the Mercedes, this concept cluster provided speed alerts. But it could also recommend an appropriate speed for upcoming curves and warn of obstacles on the road ahead. It even provided intelligent parking assist to help you back into tight spaces.

Here is the cluster displaying a speed alert:



And here it is again, using input from a LiDAR system to issue a forward collision warning:



Did you know? Engadget selected the “digital mirrors” we created for the Maserati as a finalist for the Best of CES Awards 2015.

2015 and 2016: Concept clusters in QNX reference vehicle
The QNX reference vehicle, based on a Jeep Wrangler, is our go-to vehicle for showcasing the latest capabilities of the QNX CAR Platform for Infotainment. But it also does double-duty as a technology concept vehicle. For instance, in early 2015, we equipped the Jeep with a concept cluster that provides lane departure warnings, collision detection, and curve speed warnings. For instance, in this image, the cluster is recommending that you reduce speed to safely navigate an upcoming curve:



Just in time for CES 2016, the Jeep cluster got another makeover that added crosswalk notifications to the mix:



Did you know? Jeep recently unveiled the Trailcat, a concept Wrangler outfitted with a 707HP Dodge Hellcat engine.

2016: Glass cockpit in a Toyota Highlander
By now, you can see how advances in sensors, navigation databases, and other technologies enable us to integrate more information into a digital instrument cluster, all to keep the driver aware of important events in and around the vehicle. In our 2016 technology concept vehicle, we took the next step and explored what would happen if we did away with an infotainment system altogether and integrated everything — speed, RPM, ADAS alerts, 3D navigation, media control and playback, incoming phone calls, etc. — into a single cluster display.

On the one hand, this approach presented a challenge, because, well… we would be integrating everything into a single display! Things could get busy, fast. On the other hand, this approach presents everything of importance directly in front of the driver, where it is easiest to see. No more glancing over at a centrally mounted head unit.

Simplicity was the watchword. We had to keep distraction to a minimum, and to do that, we focused on two principles: 1) display only the information that the driver currently requires; and 2) use natural language processing as the primary way to control the user interface. That way, drivers can access infotainment content while keeping their hands on the wheel and eyes on the road.

For instance, in the following scenario, the cockpit allows the driver to see several pieces of important information at a glance: a forward-collision warning, an alert that the car is exceeding the local speed limit by 12 mph, and map data with turn-by-turn navigation:



This design also aims to minimize the mental translation, or cognitive processing, needed on the part of the driver. For instance, if you exceed the speed limit, the cluster doesn’t simply show your current speed. It also displays a red line (visible immediately below the 52 mph readout) that gives you an immediately recognizable hint that you are going too fast. The more you exceed the limit, the thicker the red line grows.

The 26262 connection
Today’s digital instrument clusters require hardware and software solutions that can support rich graphics and high-level application environments while also displaying critical information (e.g. engine warning lights, ABS indicators) in a fast and highly reliable fashion. The need to isolate critical from non-critical software functions in the same environment is driving the requirement for ISO 26262 certification of digital clusters.

QNX OS technology, including the QNX OS for Safety, is ideally suited for environments where a combination of infotainment, advanced driver assistance system (ADAS), and safety-related information are displayed. Building a cluster with the ISO 26262 ASIL-D certified QNX OS for Safety can make it simpler to keep software functions isolated from each other and less expensive to certify the end cluster product.

The partner connection
Partnerships are also important. If you had the opportunity to drop by our booth at 2016 CES, you would have seen a “cluster innovation wall” that showcases QNX OS technology integrated with user interface design tools from the industry’s leading cluster software providers, including 3D Incorporated’s REMO HMI Runtime, Crank Software’s Storyboard Suite, DiSTI Corporation’s GL Studio, Elektrobit’s EB GUIDE, HI Corporation’s exbeans UI Conductor, and Rightware’s Kanzi UI software. This pre-integration with a rich choice of partner tools enables our customers to choose the user interface technologies and design approaches that best address their instrument cluster requirements.

For some partner insights on digital cluster design, check out these posts:

• Elektrobit — Digital instrument clusters and the road to autonomous driving
• Crank — Reimagining digital instrument cluster design
• Rightware — Top 5 challenges of digital instrument clusters
• Disti — Bringing safety assurance to automotive instrument clusters

Bringing a bird’s eye view to a car near you

QNX and TI team up to enable surround-view systems in mass-volume vehicles

Paul Leroux

Uh-oh. You are 10 minutes late for your appointment and can’t find a place to park. At long last, a space opens up, but sure enough, it’s the parking spot from hell: cramped, hard to access, with almost no room to maneuver.

Fortunately, you’ve got this covered. You push a button on your steering wheel, and out pops a camera drone from the car’s trunk. The drone rises a few feet and begins to transmit a bird’s eye view of your car to the dashboard display — you can now see at a glance whether you are about to bump into curbs, cars, concrete barriers, or anything else standing between you and parking nirvana. Seconds later, you have backed perfectly into the spot and are off to your meeting.

Okay, that’s the fantasy. In reality, cars with dedicated camera drones will be a long time coming. In the meantime, we have something just as good and a lot more practicable — an ADAS application called surround view.

Getting aligned

Approaching an old problem from a
new perspective. Credit: TI

Surround-view systems typically use four to six fisheye cameras installed at the front, back, and sides of the vehicle. Together, these cameras capture a complete view of the area around your car, but there’s a catch: the video frames they generate are highly distorted. So, to start, the surround-view system performs geometric alignment of every frame. Which is to say, it irons all the curves out.

Next, the system stitches the corrected video frames into a single bird’s eye view. Mind you, this step isn’t simply a matter of aligning pixels from several overlapping frames. Because each camera points in a different direction, each will generate video with unique color balance and brightness levels. Consequently, the system must perform photometric alignment of the image. In other words, it corrects these mismatches to make the resulting output look as if it were taken by a single camera hovering over the vehicle.

Moving down-market
If you think that all this work takes serious compute power, you’re right. The real trick, though, is to make the system affordable so that luxury car owners aren’t the only ones who can benefit from surround view.

Which brings me to QNX Software Systems’ support for TI’s new TDA2Eco system-on-chip (SoC), which is optimized for 3D surround view and park-assist applications. The TDA2Eco integrates a variety of automotive peripherals, including CAN and Gigabit Ethernet AVB, and supports up to eight cameras through parallel, serial and CSI-2 interfaces. To enable 3D viewing, the TDA2Eco includes an image processing accelerator for decoding multiple camera streams, along with graphics accelerators for rendering virtual views.

Naturally, surround view also needs software, which is where the QNX OS for Safety comes in. The OS can play several roles in surround-view systems, such as handling camera input, hosting device drivers for camera panning and control, and rendering the processed video onto the display screen, using QNX Software Systems’ high-performance Screen windowing system. The QNX OS for Safety complies with the ISO 26262 automotive functional safety standard and has a proven history in safety-critical systems, making it ideally suited for collision warning, surround view, and a variety of other ADAS applications.

Okay, enough from me. Let’s look at a video, hosted by TI’s Gaurav Agarwal, to see how the TDAx product line can support surround-view applications:



For more information on the TDAx product line, visit the TI website; for more on the QNX OS for Safety, visit the QNX website.

Developing safety-critical systems? This book is for you

In-depth volume covers development of systems under the IEC 61508, ISO 26262, EN 50128, and IEC 62304 standards

Paul Leroux

In June, I told you of an upcoming book by my colleague Chris Hobbs, who works as a software safety specialist here at QNX Software Systems. Well, I’m happy to say that the book is now available. It’s called Embedded Software Development for Safety-Critical Systems and it explores design practices for building medical devices, railway control systems, industrial control systems, and, of course, automotive ADAS devices.

The book:

• covers the development of safety-critical systems under ISO 26262, IEC 61508, EN 50128, and IEC 62304
• helps developers learn how 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

Interested? I invite to you to visit the CRC Press website, where you can view the full Table of Contents and, of course, order the book.

Looking forward to getting my copy!

From ADAS to autonomous

A new webinar on how autonomous driving technologies will affect embedded software — and vice versa

Paul Leroux

When, exactly, will production cars become fully autonomous? And when will they become affordable to the average Jane or Joe? Good questions both, but in the meantime, the auto industry isn’t twiddling its collective thumbs. It’s already starting to build a more autonomous future through active-control systems that can avoid accidents (e.g. automated emergency braking) and handle everyday driving tasks (e.g. adaptive cruise control).

These systems rely on software to do their job, and that reliance will grow as the systems become more sophisticated and cars become more fully autonomous. This trend, in turn, will place enormous pressure on how the software is designed, developed, and maintained. Safety, in particular, must be front and center at every stage of development.

Which brings me to a new webinar from my inestimable colleague, Kerry Johnson. Titled “The Role of a Software Platform When Transitioning from ADAS to Autonomous Driving,” the webinar will examine:

• the emergence of high-performance systems-on-chip that target ADAS and autonomous vehicle applications
• the impact of increasing system integration and autonomous technologies on embedded software
• the need for functional safety standards such as ISO 26262
• the emergence of pre-certified products as part of the solution to address safety challenges
• the role of a software platform to support the evolution from ADAS to autonomous driving

If you are tasked with either developing or sourcing software for functional safety systems in passenger vehicles, this webinar is for you. Here are the coordinates:

Wednesday, October 7
1:00pm EDT
Registration Site

One OS, multiple safety applications

The latest version of our certified OS for ADAS systems and digital instrument clusters has a shorter product name — but a longer list of talents.

Paul Leroux

Can you ever deliver a safety-critical product to a customer and call it a day? For that matter, can you deliver any product to a customer and call it a day? These, of course, are rhetorical questions. Responsibility for a product rarely ends when you release it, especially when you add safety to the mix. In that case, it’s a long-term commitment that continues until the last instance of the product is retired from service. Which can take decades.

Mind you, people dedicated to building safety-critical products aren’t prone to sitting on their thumbs. From their perspective, product releases are simply milestones in a process of ongoing diligence and product improvement. For instance, at QNX Software Systems, we subject our OS safety products to continual impact analysis, even after they have been independently certified for use in functional safety systems. If that analysis calls for improved product, then improved product is what we deliver. With a refreshed certificate, of course.

Which brings me to the QNX OS for Safety. It’s a new — and newly certified — release of our field-proven OS safety technology, with a twist. Until now, we had one OS certified to the ISO 26262 standard (for automotive systems) and another certified to the IEC 61508 standard (for general embedded systems). The new release is certified to both of these safety standards and replaces the two existing products in one fell swoop.

So if you no longer see the QNX OS for Automotive Safety listed on the QNX website, not to worry. We’ve simply replaced it with an enhanced version that has a shorter product name and broader platform support — all with the same proven technology under the hood. (My colleague Patryk Fournier has put together an infographic that nicely summarizes the new release; see sidebar).

And if you’re at all surprised that a single OS can be certified to both 61508 and 26262, don’t be. As the infographic suggests, IEC 61508 provides the basis for many market-specific standards, including IEC 62304, EN 5012x, and, of course, ISO 26262.

Learn more about the QNX OS for Safety on the QNX website. And for more information on ISO 26262 and how it affects the design of safety-critical automotive systems, check out these whitepapers:

• Architectures for ISO 26262 systems with multiple ASIL requirements
• Protecting Software Components from Interference in an ISO 26262 System

The A to Z of QNX in cars

Over 26 fast facts, brought to you by the English alphabet

Paul Leroux

A is for Audi, one of the first automakers to use QNX technology in its vehicles. For more than 15 years, Audi has put its trust in QNX, in state-of-the-art systems like the Audi virtual cockpit and the MIB II modular infotainment system. A is also for QNX acoustics software, which enhances hands-free voice communications, eliminates “boom noise” created by fuel-saving techniques, and even helps automakers create signature sounds for their engines.

B is for Bentley, BMW, and Buick, and for their QNX-powered infotainment systems, which include BMW ConnectedDrive and Buick Intellilink.

C is for concept vehicles, including the latest QNX technology concept car, a modded Maserati Quattroporte GTS. The car integrates an array of technologies — including cameras, LiDAR, ultrasonic sensors, and specialized navigation engines — to show how QNX-based ADAS systems can simplify driving tasks, warn of possible collisions, and enhance driver awareness.

D is for the digital instrument clusters in vehicles from Alpha Romeo, Audi, GM, Jaguar, Mercedes-Benz, and Land Rover. These QNX-powered displays can reconfigure themselves on the fly, providing quick, convenient access to turn-by-turn directions, back-up video, incoming phone calls, and a host of other information.

E is for experience. QNX has served the automotive market since the late 1990s, working with car makers and tier one suppliers to create infotainment systems for tens of millions of vehicles. QNX has been at work in safety-critical industrial applications even longer — since the 1980s. This unique pedigree makes QNX perfectly suited for the next generation of in-vehicle systems, which will consolidate infotainment and safety-related functions on a single, cost-effective platform.

F is for Ford, which has chosen the QNX Neutrino OS for its new SYNC 3 infotainment system. The system will debut this summer in the 2016 Ford Escape and Ford Fiesta and will be one of the first infotainment systems to support both Apple CarPlay and Android Auto.

G is for GM and its QNX-based OnStar system, which is now available in almost all of the company’s vehicles. GM also uses QNX OS and acoustics technology in several infotainment systems, including the award-winning Chevy MyLink.

H is for hypervisor. By using the QNX Hypervisor, automotive developers can consolidate multiple OSs onto a single system-on-chip to reduce the cost, size, weight, and power consumption of their designs. The hypervisor can also simplify safety certification efforts by keeping safety-related and non-safety-related software components isolated from each other.

I is for the ISO 26262 standard for functional safety in road vehicles. The QNX OS for Automotive Safety has been certified to this standard, at Automotive Safety Integrity Level D — the highest level achievable. This certification makes the OS suitable for a wide variety of digital clusters, heads-up displays, and ADAS applications, from adaptive cruise control to pedestrian detection.

J is for Jeep. The QNX reference vehicle, based on a Jeep Wrangler, showcases what the QNX CAR Platform for Infotainment can do out of the box. In its latest iteration, the reference vehicle ups the ante with traffic sign detection, lane departure warnings, curve speed warnings, collision avoidance alerts, backup displays, and other ADAS features for enhancing driver awareness.

K is for Kia, which uses QNX technology in the infotainment and connectivity systems for several of its vehicles.

L is for LG, a long-time QNX customer that is using several QNX technologies to develop a new generation of infotainment systems, digital clusters, and ADAS systems for the global automotive market.

M is for Mercedes-Benz, which offers QNX-based infotainment systems in several of its vehicles, including the head unit and digital instrument cluster in the S Class Coupe. M is also for market share: according to IHS Automotive, QNX commands more than 50% of the infotainment software market.

N is for navigation. Thanks to the navigation framework in the QNX CAR Platform, automakers can integrate a rich variety of navigation solutions into their cars.

O is for the over-the-air update solution of the BlackBerry IoT Platform, which will help automakers cut maintenance costs, reduce expensive recalls, improve customer satisfaction, and keep vehicles up to date with compelling new features long after they have rolled off the assembly line.

P is for partnerships. When automotive companies choose QNX, they also tap into an incredibly rich partner ecosystem that provides infotainment apps, smartphone connectivity solutions, navigation engines, automotive processors, voice recognition engines, user interface tools, and other pre-integrated technologies. P is also for Porsche, which uses the QNX Neutrino OS in its head units, and for Porsche 911, which formed the basis of one of the first QNX concept cars.

Q is for the QNX CAR Platform for Infotainment, a comprehensive solution that pre-integrates partner technologies with road-proven QNX software to jump-start customer projects.

R is for the reliability that QNX OS technology brings to advanced driver assistance systems and other safety-related components in the vehicle — the same technology proven in space shuttles, nuclear plants, and medical devices.

S is for the security expertise and solutions that Certicom and QNX bring to automotive systems. S is also for the advanced smartphone integration of the QNX CAR Platform, which allows infotainment systems to support the latest brought-in solutions, such as Apple CarPlay and Android Auto. S is also for the scalability of QNX technology, which allows customers to use a single software platform across all of their product lines, from high-volume economy vehicles to luxury models. And last, but not least, S is for the more than sixty million vehicles worldwide that use QNX technology. (S sure is a busy letter!)

T is for Toyota, which uses QNX technology in infotainment systems like Entune and Touch ‘n’ Go. T is also for tools: using the QNX Momentics Tool Suite, automotive developers can root out subtle bugs and optimize the performance of their sophisticated, multi-core systems.

U is for unified user interface. With QNX, automotive developers can choose from a rich set of user interface technologies, including Qt, HTML5, OpenGL ES, and third-party toolkits. Better yet, they can blend these various technologies on the same display, at the same time, for the ultimate in design flexibility.

V is for the Volkswagen vehicles, including the Touareg, Passat, Polo, Golf, and Golf GTI, that use the QNX Neutrino OS and QNX middleware technology in their infotainment systems.

W is for the QNX Wireless Framework, which brings smartphone-caliber connectivity to infotainment systems, telematics units, and a variety of other embedded devices. The framework abstracts the complexity of modem control, enabling developers to upgrade cellular and Wi-Fi hardware without having to rewrite their applications.

X, Y, and Z are for the 3D navigation solutions and the 3D APIs and partner toolkits supported by the QNX CAR Platform. I could show you many examples of these solutions in action, but my personal favorite is the QNX technology concept car based on a Bentley Continental GT. Because awesome.

Before you go... This post mentions a number of automotive customers, but please don’t consider it a complete list. I would have gotten them all in, but I ran out of letters!

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.

Bringing safety assurance to automotive instrument clusters

Guest post by Chris Giordano, director of global business and software support, DiSTI Corporation

Digital instrument clusters in automobiles are here and almost any aviator could tell you this change was coming. Since the 1970s pilots have benefited from the use of digital screens in the cockpit to depict and convey aircraft status information.

The technology came as a response to the growing number of elements that were competing for space within the cockpit and for the pilot’s attention. What was needed was a way to process the raw aircraft system and flight data into an easy-to-understand picture of the aircraft’s situation: position, orientation, altitude, speed. Engineers at NASA Langley Research Center teamed with industry partners to develop the display concepts that would become the foundation of today’s primary flight displays (PFD).

Notional example of a primary flight display

By the early 1980s, as software continued to replace the functionality found in hardware components, certification had become more complicated. Potential flaws could be prevalent in both the hardware and the software. To alleviate this problem, standards for software development for aircraft systems emerged. In the U.S., DO-178 became the standard and the Europeans ratified the ED-12 equivalent. These standards not only took a logical assessment and validation of the input and output of a system, but dove further into the development cycle to prove that procedures were in place to prevent and minimize risk of a system failure. As a result, whenever a passenger walks down the jetway and onto their flight, these software standards help ensure they arrive safely.

In the past decade the automotive industry has progressed through a similar expansion in software use. Today, electronics and software drive 90% of all innovation. Electronics and software also determine up to 40% of the vehicle’s development costs. Anywhere from 50% to 70% of the development costs for an Electronic Control Unit (ECU) are related to software (Challenges in Automotive Software Engineering, Manfred Broy, Institut für Informatik Technische Universität München, 2006). New vehicles are monitoring complex engines, providing route guidance, communicating with other networks, avoiding accidents, and serving up media. Each new feature adds to system complexity, furthering the need to use software development best practices in order to avoid a big bowl of spaghetti code.

Notional example of an advanced instrument cluster start-up system check

The need for safety becomes more prevalent in the embedded system software as graphics-based instrument clusters continue to replace traditional analog-based gauge clusters. Enter the ISO 26262 standard for functional safety of electrical and electronic components in production passenger vehicles. Formally released in November 2011, the standard establishes the state-of-the-art for the automotive industry and assures the functional safety of these systems.

By using the QNX Neutrino OS and the DiSTI GL Studio toolkit, a development team can reduce the time and effort required to certify their solution to the automotive ISO 26262 functional safety standard up to Automotive Safety Integrity Level D (ASIL D), the highest classification of safety criticality defined by the ISO 26262 standard. This compliance allows automakers and Tier 1s to use this solution to meet safety certification requirements within the scope they choose.

This QNX Neutrino OS and DiSTI GL Studio solution will be on display at this year’s TU-Automotive Detroit. Check it out in the QNX booth, #C92 and the DiSTI booth, #A21.

Visit the DiSTI blog here.

---

Chris Giordano has been developing and supporting commercial HMI software for over 16 years and has been the lead engineer or program manager for 58 different visual programs at The DiSTI Corporation. Currently, Chris manages DiSTI’s Global Business and Software Support and is the program manager for several automotive OEM and Tier 1 supplier companies that utilize DiSTI’s GL Studio for their HMI development efforts. Chris worked very closely with the team at DiSTI that took GL Studio through the ISO 26262 certification process.
 

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.

Better safe than sorry — don’t miss our webinar on automotive systems

Lynn Gayowski

I’m from Winnipeg where there is an extremely high population of terrible drivers, so I like to think I have a special understanding of what automotive safety is all about. (I’m sorry Winnipeg, I do still love you. Anyone who changes lanes without signalling should feel the finger of shame pointing at them right now.) But when we’re talking about automotive functional safety, I think there’s still a lot of learning left to do.

Enter my esteemed colleague Yi Zheng. Yi will be presenting a webinar on Designing Automotive Systems with the ISO 26262 Standard. Highlights will include:

• Lessons learned from safety standards in other industries
• The key concepts of ISO 26262
• What ISO 26262 requirements mean for the design of your system 

If you’re looking to brush up on your automotive safety knowledge I invite you to join. Here are the details:

Designing Automotive Systems with the ISO 26262 Standard  Monday, July 28, 2014

9 a.m. PT / Noon ET / 4 p.m.  UTC

Registration & more info here.

Attend from the comfort of your home or office – no parallel parking required!

Static analysis, functional safety, and why you should attend this webinar

Let's cut to the chase. Any webinar hosted by Chris Hobbs, a member of the safe systems team at QNX, is worth a listen. I honestly can't listen to the man for 5 minutes without learning something new. So if you're developing systems that must, or may need to, comply with the ISO 26262 functional safety standard, you owe it to yourself to attend the webinar that Chris will co-host this week:

Static Analysis' Role in Automotive Functional Safety

Thursday, July 17

10am PT, 1pm ET, 5pm UTC

Registration

As you may already know, ISO 26262 recommends static code analysis for ASILs B to D. And that's because static analysis can make a real contribution to functional safety — exactly the approach this webinar will explore. Topics will include:

• Functional safety and ISO 26262
• The balance between dynamic and static analysis
• How purpose-built tools can simply the qualification process

As an added bonus, Chris will be joined by co-host Steve Howard of Klocwork. Steve has over 15 years' experience in safety-critical and mission-critical software development, working with verification and validation tools.

Learn more about Chris, Steve, and the webinar here.

---

Recommended reading by Chris Hobbs
Testing as a road to confidence-from-use
The Dangers of Over-Engineering a Safe System
Protecting Software Components from Interference in an ISO 26262 System
Ten Truths about Building Safe Embedded Software Systems

The palindromic standard

The QNX OS for Automotive Safety was recently granted ISO 26262 certification. So why is that such a big deal? Allow me to explain.

When it comes to being hard to pronounce, ISO 26262 takes the cake among international safety standards. If you don’t believe me, just try to say “ISO 26262” ten times quickly, in any language.

You know what else is hard? Achieving compliance with ISO 26262. QNX Software Systems has just received its first ISO 26262 certificate from TUV Rheinland, so I can make that claim with a strong measure of confidence!

The certificate.

ISO 26262 is a new functional safety standard developed specifically for passenger vehicles. Published in 2011, it is based on the grand-daddy of functional safety standards, IEC 61508. Since its introduction, ISO 26262 has grabbed a lot of attention in the automotive industry. Why? Because rapid advancements in technology are presenting new safety challenges. The sophisticated hardware and software technologies now making their way into passenger vehicles may enable cool features, but they also stretch the concept of safety beyond mechanical parts. ISO 26262 is specifically developed to address the safety requirements of these electric and electronic components.

Due diligence
The ISO 26262 standard describes how safety functions must be addressed throughout the entire software lifecycle. This approach ensures that safety isn’t treated as an afterthought during final testing, but as a matter of due diligence in every stage of development. Apart from following functional safety processes, the software maker must continually ask questions such as these:

• In what ways could my software fail?
  
• If it does fail, how could it affect the safety of the overall system?
  
• How can I mitigate the risk of failure?

These questions would sound familiar to any experienced safety engineer, but they might not be top of mind for many designers. Safety design imposes an extra dimension to a project that must be budgeted for, right from the start. In addition to the discipline and effort needed to develop any safety product, the ISO 26262 standard demands that you prove your product is safe.

Constructing the argument that the product complies with the standard, such as through building a safety case, is far from trivial. For instance, using methods like Goal Structuring Notation can help make a strong argument by giving some reason to the sea of documentation that serves as evidence for your safety claim. But it takes skill to wield the power of GSN to produce an effective, well-structured safety case.

In short, achieving ISO 26262 certification is a huge undertaking. But then, so is the importance of the ultimate goal: safer cars.

Again, for an inkling of how tough it is to get certified, just keep repeating the name of the standard without screwing up...

---

Recommended reading

QNX Unveils New OS for Automotive Safety
Architectures for ISO 26262 systems with multiple ASIL requirements (whitepaper)
Protecting Software Components from Interference in an ISO 26262 System (whitepaper)
Ten Truths about Building Safe Embedded Software Systems (whitepaper)

A matter of urgency: preparing for ISO 26262 certification

Yoshiki Chubachi

Guest post by Yoshiki Chubachi, automotive business development manager for QNX Software Systems, Japan

Two weeks ago in Tokyo, QNX Software Systems sponsored an ISO 26262 seminar hosted by IT Media MONOist, a Japanese information portal for engineers. This was the fourth MONOist seminar to focus on the ISO 26262 functional safety standard, and the theme of the event conveyed an unmistakable sense of urgency: “You can’t to afford to wait any longer: how you should prepare for ISO 26262 certification”.

In his opening remarks, Mr. Pak, a representative of MONOist, noted that the number of attendees for this event increases every year. And, as the theme suggests, many engineers in the automotive community feel a strong need to get ready for ISO26262. In fact, registration filled up just three days after the event was announced.

The event opened with a keynote speech by Mr. Koyata of the Japan Automobile Research Institute (JARI), who spoke on functional safety as a core competency for engineers. A former engineer at Panasonic, Mr. Koyata now works as an ISO 26262 consultant at JARI. In his speech, he argued that every automotive developer should embrace knowledge of ISO 26262 and that automakers and Tier 1 suppliers should adopt a functional "safety culture." Interestingly, his argument aligns with what Chris Hobbs and Yi Zheng of QNX advocate in their paper, “10 truths about building safe embedded software systems.” My Koyata also discussed the difference between safety and ‘Hinshitu (Quality)” which is a strong point of Japan industry.

Next up were presentations by the co-sponsor DNV Business Assurance Japan. The talks focused on safety concepts and architecture as well as on metrics for hardware safety design for ISO 26262.

I had the opportunity to present on software architecture and functional safety, describing how the QNX microkernel architecture can provide an ideal system foundation for automotive systems with functional safety requirements. I spoke to a number of attendees after the seminar, and they all recognized the need to build an ISO 26262 process, but didn’t know how to start. The need, and opportunity, for education is great.

Yoshiki presenting at the MONOist ISO 26262 seminar. Source: MONOist

The event ended with a speech by Mr. Shiraishi of Keio University. He has worked on space satellite systems and offered some interesting comparisons between the functional safety of space satellites and automotive systems.

Safety and reliability go hand in hand. “Made in Japan” is a brand widely known for its reliability. Although Japan is somewhat behind when it comes to awareness for ISO 26262 certification, I see a great potential for it to be the leader in automotive safety. Japanese engineers take pride in the reliability of products they build, and this mindset can be extended to the new generation of functional safety systems in automotive.

---

Additional reading

QNX Unveils New OS for Automotive Safety
Architectures for ISO 26262 systems with multiple ASIL requirements (whitepaper)
Protecting Software Components from Interference in an ISO 26262 System (whitepaper)
Ten Truths about Building Safe Embedded Software Systems (whitepaper)

My top 10 QNX Auto posts from 2013

Normally, people write this kind of post at the beginning or end of a calendar year. But as an old friend once said, “Paul defines his own kind of normal.” He may have been right, I don’t know. What I do know is that this is definitely a personal list. It consists of posts that either made me laugh, taught me something I didn’t know, or helped me see things in a new light. I hope they do the same for you.

Disclosure: I wrote a couple of the posts in question. Because, sometimes, the best way to learn about something or see it in a new light is to write about it. :-)

Okay, enough preliminaries, let’s get to it…

• What happens when autonomous becomes ubiquitous? — One question, seventeen answers.
   
• Top 10 lessons learned from more than a decade in automotive — When it comes to software in the car, John Wall is the man.
   
• Protecting software components in an ISO 26262 system — Sometimes, software components can be downright delinquent.
   
• Why doesn’t my navigation system understand me? — Big data might be important, but small data can add a personal touch.
   
• Top 10 challenges facing the ADAS industry — For ADAS systems to be successful, a safety culture must be embedded in every organization in the supply chain. And that’s just the first challenge.
   
• Reducing driver distraction with ICTs — Yes, mobile phones can contribute to driver distraction. But they can also help solve the problem.
   
• A sound approach to creating a quieter ride — Paradoxically, the best way to eliminate engine noise is to generate noise.
   
• What's the word on HTML5? — If you want to know what experts at Audi, OnStar, Gartner, Pandora, TCS, and QNX think about HTML5 in the car, this is the post with the most (videos, that is).
   
• A matter of context — A look at how digital instrument clusters can help provide the right information, at the right time.
   
• My top moments of 2013 — Because this reminds me of the fantastic momentum QNX is building in automotive.
   
• HTML5 blooper reel — Because laughter.
  

Oops, I guess that makes 11.