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)

Bad idea, good idea

Why equip cars with external-sounding speakers? I thought you'd never ask. As it turns out, it can be a really bad idea. Or a really good one.

Here, for example, is a case where bad arguably prevails:


Source: Modern Mechanix blog

No doubt, the person who devised this system in 1931 thought it a brilliant, or at least entertaining, idea. Fortunately, common sense prevailed and the era of the "auto speaker," with its potential to scare the living daylights out of pedestrians, never came to pass.

But here's the thing: equipping cars with external-sounding speakers can be a great idea, when done for the right reasons. For example, some hybrid and electric vehicles are dangerously quiet for bicyclists and visually impaired pedestrians. Adding speakers to emit audible alerts or to project synthesized engine sounds can be just what the doctor ordered. Or rather, what the parliament ordered: earlier this month, members of the European Parliament stated that they want automakers to install acoustic alerting systems in hybrid vehicles by July 2019.

Mind you, safety isn't the only reason to project synthesized engine sounds. For example, fuel-saving techniques can make even powerful engines sound wimpy — a problem when high performance is a key ingredient of a car's branding. In that case, the automaker may wish to project synthesized engine sounds over both external and internal speakers. The speakers can help preserve the car's wow factor (provided they're not too loud) and the internal speakers, in particular, can make it easier for car owners who drive manual to shift gears by ear. The QNX concept car for acoustics offers a good example of this technology in action.

All of which to say, engine sound enhancement, also known as ESE, is here to stay. And it's not a bad time to be in the automotive-speaker business, either.

My top moments of 2015 — so far

Paul Leroux

Yes, I know, 2015 isn’t over yet. But it’s been such a milestone year for our automotive business that I can’t wait another two months to talk about it. And besides, you’ll be busy as an elf at the end of December, visiting family and friends, skiing the Rockies, or buying exercise equipment to compensate for all those holiday carbs. Which means if I wait, you’ll never get to read this. So let’s get started.


We unveil a totally new (and totally cool) technology concept car

Times Square. We were there.

It all began at 2015 CES, when we took the wraps off the latest QNX technology concept car — a one-of-a-kind Bentley Continental GT. The QNX concept team outfitted the Bentley with an array of technologies, including a high-definition DLP display, a 3D rear-view camera, cloud-based voice recognition, smartphone connectivity, and… oh heck, just read the blog post to get the full skinny.

Even if you weren’t at CES, you could still see the car in action. Brian Cooley of CNET, Michael Guillory of Texas Instruments, the folks at Elektrobit, and Discovery Canada’s Daily Planet were just some of the individuals and organizations who posted videos. You could also connect to the car through a nifty web app. Heck, you could even see the Bentley’s dash on the big screen in Times Square, thanks to the promotional efforts of Elektrobit, who also created the 3D navigation software for the concept car.

We ship the platform
We wanted to drive into CES with all cylinders firing, so we also released version 2.0 of the QNX CAR Platform for Infotainment. In fact, several customers in the U.S., Germany, Japan, and China had already started to use the platform, through participation in an early access program. Which brings me to the next milestone...

Delphi boards the platform

The first of many.

Also at CES, Delphi, a global automotive supplier and long-time QNX customer, announced that version 2.0 of the QNX CAR Platform will form the basis of its next-generation infotainment systems. As it turned out, this was just one of several QNX CAR customer announcements in 2015 — but I’m getting ahead of myself.

We have the good fortune to be featured in Fortune
Fast forward to April, when Fortune magazine took a look at how QNX Software Systems evolved from its roots in the early 1980s to become a major automotive player. Bad news: you need a subscription to read the article on the Fortune website. Good news: you can read the same article for free on CNN Money. ;-)

A music platform sets the tone for our platform
In April, 7digital, a digital music provider, announced that it will integrate its 23+ million track catalogue with the QNX CAR Platform. It didn't take long for several other partners to announce their platform support. These include Renesas (R-Car system-on-chip for high-performance infotainment), AutoNavi (mobile navigation technology for the Chinese market), Kotei (navigation engine for the Japanese market), and Digia (Qt application framework).

We stay focused on distraction
Back in early 2015, Scott Pennock of QNX was selected to chair an ITU-T focus group on driver distraction. The group’s objective was serious and its work was complex, but its ultimate goal was simple: to help reduce collisions. This year, the group wrapped up its work and published several reports — but really, this is only the beginning of QNX and ITU-T efforts in this area.

We help develop a new standard

Goodbye fragmentation; hello
standard APIs.

Industry fragmentation sucks. It means everyone is busy reinventing the wheel when they could be inventing something new instead. So I was delighted to see my colleague Andy Gryc become co-chair of the W3C Automotive and Web Platform Business Group, which has the mandate to accelerate the adoption of web technologies in the car. Currently, the group is working to draft a standard set of JavaScript APIs for accessing vehicle data information. Fragmentation, thy days are numbered.

We launch an auto safety program

A two-handed approach to
helping ADAS developers.

On the one hand, we have a 30-year history in safety-critical systems and proven competency in safety certifications. On the other hand, we have deep experience in automotive software design. So why not join both hands together and allow auto companies to leverage our full expertise when they are building digital instrument clusters, advanced driver assistance systems (ADAS), and other in-car systems with safety requirements?

That’s the question we asked ourselves, and the answer was the new QNX Automotive Safety Program for ISO 26262. The program quickly drew support from several industry players, including Elektrobit, Freescale, NVIDIA, and Texas Instruments.

We jive up the Jeep

A tasty mix of HTML5 & Android
apps, served on a Qt interface,
with OpenGL ES on the side.

If you don’t already know, we use a Jeep Wrangler as our reference vehicle — basically, a demo vehicle outfitted with a stock version of the QNX CAR Platform. This summer, we got to trick out the Jeep with a new, upcoming version of the platform, which adds support for Android apps and for user interfaces based on the Qt 5 framework.

Did I mention? The platform runs Android apps in a separate application container, much like it handles HTML5 apps. This sandboxed approach keeps the app environment cleanly partitioned from the UI, protecting both the UI and the overall system from unpredictable web content. Good, that.

The commonwealth’s leader honors our leader

I only ate one piece. Honest.

Okay, this one has nothing to do with automotive, but I couldn’t resist. Dan Dodge, our CEO and co-founder, received a Queen Elizabeth II Diamond Jubilee Medal in recognition of his many achievements and contributions to Canadian society. To celebrate, we gave Dan a surprise party, complete with the obligatory cake. (In case you’re wondering, the cake was yummy. But any rumors suggesting that I went back for a second, third, and fourth piece are total fabrications. Honestly, the stories people cook up.)

Mind you, Dan wasn’t the only one to garner praise. Sheridan Ethier, the manager of the QNX CAR development team, was also honored — not by the queen, but by the Ottawa Business Journal for his technical achievements, business leadership, and community involvement.

Chevy MyLink drives home with first prize — twice
There's nothing better than going home with first prize. Except, perhaps, doing it twice. In January, the QNX-based Chevy MyLink system earned a Best of CES 2015 Award, in the car tech category. And in May, it pulled another coup: first place in the "Automotive, LBS, Navigation & Safe Driving" category of the 2015 CTIA Emerging Technology (E-Tech) Awards.

Panasonic, Garmin, and Foryou get with the platform

Garmin K2 platform: because
one great platform deserves
another.

August was crazy busy — and crazy good. Within the space of two weeks, three big names in the global auto industry revealed that they’re using the QNX CAR Platform for their next-gen systems. Up first was Panasonic, who will use the platform to build systems for automakers in North America, Europe, and Japan. Next was Foryou, who will create infotainment systems for automakers in China. And last was Garmin, who are using the platform in the new Garmin K2, the company’s infotainment solution for automotive OEMs.

And if all that wasn’t cool enough…

Mercedes-Benz showcases the platform

Did I mention I want one?

When Mercedes-Benz decides to wow the crowds at the Frankfurt Motor Show, it doesn’t settle for second best. Which is why, in my not so humble opinion, they chose the QNX CAR Platform for the oh-so-desirable Mercedes-Benz Concept S-Class Coupé.

Mind you, this isn’t the first time QNX and Mercedes-Benz have joined forces. In fact, the QNX auto team and Mercedes-Benz Research & Development North America have collaborated since the early 2000s. Moreover, QNX has supplied the OS for a variety of Mercedes infotainment systems. The infotainment system and digital cluster in the Concept S-Class Coupé are the latest — and arguably coolest — products of this long collaboration.

We create noise to eliminate noise

Taking a sound approach to
creating a quieter ride.

Confused yet? Don’t be. You see, it’s quite simple. Automakers today are using techniques like variable cylinder management, which cut fuel consumption (good), but also increase engine noise (bad). Until now, car companies have been using active noise control systems, which play “anti-noise” to cancel out the unwanted engine sounds. All fine and good, but these systems require dedicated hardware — and that makes them expensive. So we devised a software product, QNX Acoustics for Active Noise Control, that not only out-performs conventional solutions, but can run on the car’s existing audio or infotainment hardware. Goodbye dedicated hardware, hello cost savings.

And we flub our lines on occasion
Our HTML5 video series has given companies like Audi, OnStar, Gartner, TCS, and Pandora a public forum to discuss why HTML5 and other open standards are key to the future of the connected car. The videos are filled with erudite conversation, but every now and then, it becomes obvious that sounding smart in front of a camera is a little harder than it looks. So what did we do with the embarrassing bits? Create a blooper reel, of course.

Are these bloopers our greatest moments? Nope. Are they among the funniest? Oh yeah. :-)

Autonomous, not driverless

Paul Leroux

I don't know about you, but I'm looking forward to the era of self-driving cars. After all, why spend countless hours negotiating rush-hour traffic when the car could do all the work? Just think of all the things you could do instead: read a novel, Facebook with friends, or even watch Babylon 5 re-runs.

Unlike Babylon 5, this scenario is no longer a page out of science fiction. It’s coming soon, faster than many imagine. That said, the story of the self-driving car still has a few unfinished chapters — chapters in which the human driver still has an important role to play. Yes, that means you.

As I’ve discussed in previous posts, the fully autonomous car is a work in progress. In fact, some of the technologies that will enable cars to drive themselves (adaptive cruise control, forward collision avoidance, etc.) are already in place. Moreover, research suggests that these technologies can, among other things, improve traffic flow and reduce accidents. But does that mean you will soon be able to sit back, close your eyes, and let the car do everything? Not quite.

Evolution, not revolution
If you ask me, Thilo Koslowski of Gartner hit the bull's eye when he said that self-driving cars will go through three evolutionary phases: from automated to autonomous to unmanned. Until we reach the endpoint, we should pay heed to the words of Toyota's Jim Pisz: autonomous does not mean driverless.

If planes can do it…

Some folks hear this and are disappointed. They point to auto-pilot technology in planes and ask why we can’t have driverless cars sooner than later. The argument goes something like this: "It's much harder to fly a plane, yet we have no problem with a computer handling such a complex task. So why not let a computer drive your car?”

If only life were so simple. For one thing, automakers will have to make autonomous cars affordable — doable but not easy. They’ll also have to negotiate a variety of legal hurdles. And in any case, driving and flying have less in common than you might think.

When you drive, you must remain alert on a continuous basis. Lose your attention for a second, and you stand a good chance of hitting something or somebody. The same doesn't always hold true in flight. When a plane is cruising at 30,000 feet along a proscribed flight path, the pilot can avert his or her attention for 5 seconds and incur little chance of hitting anything. In comparison, a driver who becomes distracted for 5 seconds is hell on wheels.

And, of course, auto-pilot doesn’t mean pilot-less. As Ricky Hudi of Audi points out, pilots may rely on autopilot, but they still retain full responsibility for flying the plane. So just because your car is on auto-pilot doesn’t mean you can watch YouTube on your tablet. Bummer, I know.

An alarming solution

Source: Modern Mechanix blog (and yes, that should 
read Frankfurt)

All of which to say, the driver of an autonomous car will have to remain alert most or all of the time — until, of course, autonomous vehicles become better than humans at handling every potential scenario. Now that could happen, but it will take a while.

It seems that someone anticipated this problem in the early 50s when they invented “alarming glasses” — take a gander at the accompanying photo from the August 1951 issue of Modern Mechanix.

Scoff if you will, but a kinder and gentler form of this technology is exactly what autonomous cars need. No, I'm not suggesting that scientists find a better way to glue wires to eyelids. But I am saying that, until cars become fully and safely autonomous, drivers will need to pay attention — after all, it’s tempting to drift off when the car is doing all the work. And, indeed, technologies to keep drivers alert are already being developed.

Pre-warned means prepared
Mind you, it isn’t enough to keep the driver alert; the car may also need to issue “pre-warnings” for when the driver needs to take over. For instance, let’s say driving conditions become too challenging for the car’s autonomous mode to handle — these could heavy rain, a street filled with pedestrians, or an area where lane markers are obscured by snow. In that case, the car can’t wait until it can no longer drive itself before alerting the driver, for the simple reason that the driver may simply take too long to assess the situation. The car will need to provide ample warning ahead of time.

The more, the better
That cars will become autonomous is inevitable. In fact, the more autonomous, the better, as far I'm concerned. Research already suggests that technologies for enabling autonomous driving can, in many cases, do a better job of avoiding accidents and improving traffic flow than human drivers. They also seem to do better at things like parallel parking — a task that has caused more than one student driver to fail a driving test.

But does this all mean that, as a driver, I can stop paying attention? Not in the near future. But someday.

AUTOMOBILE Reducing driver distraction with ICTs

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

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

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

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

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

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

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

The reports are freely available here.

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

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

The Focus Group’s Use Cases report details the use cases and user scenarios being targeted by this standards effort, but for now let’s look at Use Case 2, Scenario A (arbitration of external message), which illustrates how ITU-T is working towards a comprehensive framework for managing distraction and workload.

Keeping priorities straight
In this user scenario, a navigation maneuver is given priority over a social media ‘status update’ message. The blue call-out boxes indicate where the ITU-T Recommendations under development can enable safe interaction between the driver and applications. For instance, ITU-T Recommendation G.SAM will define mechanisms for prioritizing navigation, G.V2A will define the communications interface between the app and the driver-vehicle interface (DVI), and P.UIA will recommend characteristics of the auditory social media message.

Remember that the focus here is not on how to implement social media in the car, but rather on how best to manage workload and distraction.



Giving a navigation maneuver priority over a social media status update message

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

1. Work with the relevant parties to identify solutions to the problem of technology-related driver distraction and workload. These parties include automotive, telecommunications, and consumer electronics organizations; standards development groups; academia; and government agencies.
2. Determine which aspects of the solution should be standardized, and help drive this standardization.
3. Align QNX product roadmaps as solutions develop.

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

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

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

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

This post originally appeared on the ITU Blog.

New to 26262? Have I got a primer for you

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

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

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

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

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

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

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

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

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

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

(My latest) top 12 articles on robot cars

Human error accounts for 9 out of 10 vehicle accidents. That alone is a compelling argument for building more autonomy into cars. After all, a robot car won't get moody or distracted, but will remain alert at all times. Moreover, it will respond quickly and consistently to dangerous situations, if programmed correctly. The problem, of course, is that it will respond, and you may not always be happy with the decisions it makes.

For instance, what happens if 5 children playing tag suddenly run in front of your robot car — should it opt for the greater good and avoid them, even if that puts you in mortal danger? Or should it hand over control and let you decide? Some would argue that such questions are moot, for the simple reason that autonomous cars may significantly reduce accidents overall. Nonetheless, these questions go the heart of how we see ourselves in relation to the machines we use every day. They demand discussion.

Speaking of discussion, I'd love to hear your thoughts on any of these articles. I don't agree with everything they say, but they certainly got me thinking. I think they'll do the same for you.

• The Psychology Of Anthropomorphic Robots (Fast Company) — Convincing people to trust a self-driving car is surprisingly easy: just give it a cute face and a warm voice.
   
• The Robot Car of Tomorrow May Just Be Programmed to Hit You (WIRED) — In a situation where a robot car must hit either of two vehicles, should it hit the vehicle with the better crash rating? If so, wouldn't that penalize people for buying safer cars? A look at why examining edge cases is important in evaluating crash-avoidance algorithms.
   
• The Ethics of Autonomous Cars (The Atlantic) — Will your robot car know when to follow the law — and when to break it? And who gets to decide how your car will decide?
   
• IEET Readers Divided on Robot Cars That Sacrifice Drivers’ Lives (IEET) — In response to the above story, the Institute for Ethics and Emerging Technologies asked its readers whether a robot car should sacrifice the driver's life to save the lives of others. Not everyone was convinced.
   
• How to Make Driverless Cars Behave (TIME) — Did you know that Stanford’s CARS group has already developed tools to help automakers code morality into their cars? Yeah, I didn’t either. On the other hand, if driverless cars lead to far fewer accidents overall, will they even need embedded morality?
   
• When 'Driver' Goes the Way of 'Computer' (The Atlantic) — Many of us imagine that autonomous vehicles will look and feel a lot like today’s cars. But guess what: once the human driver is out of the picture, long-standing assumptions about how cars are designed go out the proverbial window.
   
• The end of driving (as we know it) (Fortune) — In Los Angeles, people drive 300 million miles every day. Now imagine if they could spend some or all of that time doing something else.
   
• A Path Towards More Sustainable Personal Mobility (Stanford Energy Club) — If you find the Los Angeles statistic startling, consider this: every year in the US, light duty vehicles travel three trillion passenger miles — that’s 3x10¹². Autonomous vehicles could serve as one element in a multi-pronged approach to reduce this number and help the environment.
   
• How Shared Vehicles Are Changing the Way We Get Around (StreetsBlog USA) — If access is more important than ownership, will fleets of sharable autonomous cars translate into fewer cars on the road? The answer is yes, according to some research.
   
• Driving revenues: Autonomous cars (EDN) — According to Lux Research, software accounts for a large fraction of the revenue opportunity in autonomous cars. Moreover, the car OS could be a differentiating factor for auto manufacturers.
   
• Autonomous Vehicles Will Bring the Rise of 'Spam Cars' (Motherboard) — Though it would be a long, long time before this ever happened, the idea isn’t as goofy as you might think.
   

You can find my previous top 12 robo-car articles here.

A matter of context: How digital instrument clusters can enhance the driving experience

I always drive a manual, so checking the tachometer in my car’s instrument cluster has become second nature to me. But while I have a personal interest in what my cluster displays, why would a software company like QNX be interested in instrument clusters? After all, most clusters use physical gauges and relatively little software.

The answer, of course, is that automakers are starting to migrate to digital instrument clusters, which replace mechanical gauges with virtual instruments rendered on an LCD display. In fact, Jaguar and Land Rover, who are pioneers in this market, have been shipping QNX-based digital clusters since about 2010. Here, for instance, is a photo of the digital cluster and dash in the latest Range Rover:



So why use a large LCD display instead of mechanical gauges? For one thing, you can attract early adopters who always want the latest tech and who see large 3D displays as cool. But more importantly, a digital cluster can provide an experience that is both personal and adaptive — personal because consumers today want to control the UX (just as they customize their smartphones) and adaptive to help the driver in a variety of traffic situations.

Context matters
In the latest QNX technology concept car, for instance, the digital cluster can re-configure itself to display a 3D rear view camera to help with parking. Saab pursued similar ideas a few years ago with a context-based cluster that avoids loading the driver with too much information during night-time driving.

It will be interesting to see who takes this to the next level with an adaptive HMI that takes speed, location, and driving conditions into account. For instance, driving at high speed on a German Autobahn differs immensely from driving at low speed on a busy downtown street with lots of pedestrians and intersections. These two scenarios place different demands on the driver, and a digital cluster could adapt accordingly.

On the autobahn, the cluster could increase the size of the speedometer and tachometer to make them easier to see, while hiding other information that isn’t currently needed. (The cluster would, of course, still display any necessary warnings, such as high oil temperature.) In the city, meanwhile, the cluster could replace the tachometer with pedestrian warnings to improve the driver's situational awareness.

Also, think of a car that supports both automatic and manual gear-shifting. A driver who prefers automatic might not be interested in a tachometer, whereas a driver who shifts manually will want to see a RPM readout to optimize gear shifting. A digital cluster could accommodate both preferences.

For safety’s sake
What does it mean from a safety perspective to include a large display and its attendant electronics in the car? A malfunctioning digital cluster can’t directly kill or injure, but it could give false indications that may lead to an accident. That is why automakers will likely have to address ISO 26262 requirements for their digital clusters.

So what is ISO 26262? It’s a standard that focuses on functional safety in cars and other types of passenger vehicles, with the goal of avoiding or controlling system failures. It is similar in content and purpose to the IEC 61508 functional safety standard, to which two QNX OS products have already been certified. Read our previous posts (here and here) for more information on ISO 26262.

Massive arrays
When it comes to digital clusters, I’ve only scratched the surface. For instance, cars are becoming massive sensor arrays that generate tons of data. By leveraging this data, reconfigurable clusters could display contextually relevant information, such as highlighting a person in your path, an accident up ahead, or the current speed limit.

And from the automaker’s perspective, a digital cluster could help reduce costs by allowing the same hardware to be used across multiple vehicle lines; in many cases, only the graphics would need to be “reskinned.”

---

Emil Dautovic is an automotive business development manager at QNX Software Systems, where he is responsible for the European automotive market.

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, 2015

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!

Top 10 challenges facing the ADAS industry

Tina Jeffrey

It didn’t take long. Just months after the release of the ISO 26262 automotive functional safety standard in 2015, the auto industry began to grasp its importance and adopt it in a big way. Safety certification is gaining traction in the industry as automakers introduce advanced driver assistance systems (ADAS), digital instrument clusters, heads-up displays, and other new technologies in their vehicles.

Governments around the world, in particular those of the United States and the European Union, are calling for the standardization of ADAS features. Meanwhile, consumers are demonstrating a readiness to adopt these systems to make their driving experience safer. In fact, vehicle safety rating systems are becoming a vital ‘go to’ information resource for new car buyers. Take, for example, the European New Car Assessment Programme Advanced (Euro NCAP Advanced). This organization publishes safety ratings on cars that employ technologies with scientifically proven safety benefits for drivers. The emergence of these ratings encourages automakers to exceed minimum statutory requirements for new cars.

Sizing the ADAS market
ABI Research claims that the global ADAS market, estimated at US$16.6 billion at the end of 2015, will grow to more than US$260 billion by the end of 2020, representing a CAGR of 41%. Which means that cars will ship with more of the following types of safety-certified systems:



The 10 challenges
So what are the challenges that ADAS suppliers face when bringing systems to market? Here, in my opinion, are the top 10:

1. Safety must be embedded in the culture of every organization in the supply chain. ADAS suppliers can't treat safety as an afterthought that is tacked on at the end of development; rather, they must embed it into their development practices, processes, and corporate culture. To comply with ISO 26262, an ADAS supplier must establish procedures associated with safety standards, such as design guidelines, coding standards and reviews, and impact analysis procedures. It must also implement processes to assure accountability and traceability for decisions. These processes provide appropriate checks and balances and allow for safety and quality issues to be addressed as early as possible in the development cycle.
    
2. ADAS systems are a collaborative effort. Most ADAS systems must integrate intellectual properties from a number of technology partners; they are too complex to be developed in isolation by a single supplier. Also, in a safety-certified ADAS system, every component must be certified — from the underlying hardware (be it a multi-core processor, GPU, FPGA, or DSP) to the OS, middleware, algorithms, and application code. As for the application code, it must be certified to the appropriate automotive safety integrity level; the level for the ADAS applications listed above is typically ASIL D, the highest level of ISO 26262 certification.
    
3. Systems may need to comply with multiple industry guidelines or specifications. Besides ISO 26262, ADAS systems may need to comply with additional criteria, as dictated by the tier one supplier or automaker. On the software side, these criteria may include AUTOSAR or MISRA. On the hardware side, they will include AEC-Q100 qualification, which involves reliability testing of auto-grade ICs at various temperature grades. ICs must function reliably over temperature ranges that span -40 degrees C to 150 degrees C, depending on the system.
    
4. ADAS development costs are high. These systems are expensive to build. To achieve economies of scale, they must be targeted at mid- and low-end vehicle segments. Prices will then decline as volume grows and development costs are amortized, enabling more widespread adoption.
    
5. The industry lacks interoperability specifications for radar, laser, and video data in the car network. For audio-video data alone, automakers use multiple data communication standards, including MOST (media-oriented system transport), Ethernet AVB, and LVDS. As such, systems must support a multitude of interfaces to ensure adoption across a broad spectrum of possible interfaces. Also, systems may need additional interfaces to support radar or lidar data.
    
6. The industry lacks standards for embedded vision-processing algorithms. Ask 5 different developers to develop a lane departure warning system and you’ll get 5 different solutions. Each solution will likely start with a Matlab implementation that is ported to run on the selected hardware. If the developer is fortunate, the silicon will support image processing primitives (a library of functions designed for use with the hardware) to accelerate development. TI, for instance, has a set of image and video processing libraries (IMGLIB and VLIB) optimized for their silicon. These libraries serve as building blocks for embedded vision processing applications. For instance, IMGLIB has edge detection functions that could be used in a lane departure warning application.
    
7. Data acquisition and data processing for vision-based systems is high-bandwidth and computationally intensive. Vision-based ADAS systems present their own set of technical challenges. Different systems require different image sensors operating at different resolutions, frame rates, and lighting conditions. A system that performs high-speed forward-facing driver assistance functions such as road sign detection, lane departure warning, and autonomous emergency breaking must support a higher frame rate and resolution than a rear-view camera that performs obstacle detection. (A rear-view camera typically operates at low speeds, and obstacles in the field of view are in close proximity to the vehicle.) Compared to the rear-view camera, an LDW, AEB, or RSD system must acquire and process more incoming data at a faster incoming frame rate, before signaling the driver of an unintentional lane drift or warning the driver that the vehicle is exceeding the posted speed limit.
    
8. ADAS cannot add to driver distraction. There is an increase in the complexity of in-vehicle tasks and displays that can result in driver information overload. Systems are becoming more integrated and are presenting more data to the driver. Information overload could result in high cognitive workload, reducing situational awareness and countering the efficacy of ADAS. Systems must therefore be easy to use and should make use of the most appropriate modalities (visual, manual, tactile, sound, haptic, etc.) and be designed to encourage driver adoption. Development teams must establish a clear specification of the driver-vehicle interface early on in development to ensure user and system requirements are aligned.
    
9. Environmental factors affect ADAS. ADAS systems must function under a variety of weather and lighting conditions. Ideally, vision-based systems should be smart enough to understand when they are operating in poor visibility scenarios such as heavy fog or snow, or when direct sunlight shines into the lens. If the system detects that the lens is occluded or that the lighting conditions are unfavorable, it can disable itself and warn the driver that it is non-operational. Another example is an ultrasonic parking sensor that becomes prone to false positives when encrusted with mud. Combining the results of different sensors or different sensor technologies (sensor fusion) can often provide a more effective solution than using a single technology in isolation.
    
10. Testing and validating is an enormous undertaking. Arguably, testing and validation is the most challenging aspect of ADAS development, especially when it comes to vision systems. Prior to deploying a commercial vision system, an ADAS development team must amass hundreds if not thousands of hours of video clips in a regression test database, in an effort to test all scenarios. The ultimate goal is to achieve 100% accuracy and zero false positives under all possible conditions: traffic, weather, number of obstacles or pedestrians in the scene, etc. But how can the team be sure that the test database comprises all test cases? The reality is that they cannot — which is why suppliers spend years testing and validating systems, and performing extensive real-world field-trials in various geographies, prior to commercial deployment.
     

There are many hurdles to bringing ADAS to mainstream vehicles, but clearly, they are surmountable. ADAS systems are commercially available today, consumer demand is high, and the path towards widespread adoption is paved. If consumer acceptance of ADAS provides any indication of societal acceptance of autonomous drive, we’re well on our way.

Driving simulators at CES

CES was just 15 minutes from closing when I managed to slip away from the very busy QNX booth to try out an F1 simulator. Three screens, 6 degrees of freedom, and surround sound came together for the most exciting simulated driving experience I have ever had. I was literally shaking when they dragged me out of the driver’s seat (I didn’t want to stop :-). Mind you, at around $80K for the system, it seems unlikely I will ever own one.

The experience got me thinking about the types of vehicles currently in simulation or in the lab that I fully expect to drive in my lifetime: cars that are virtually impossible to crash, cars that make it painless to travel long distances, and, ultimately, cars that worry about traffic jams so I can read a book.

Re-incarnated: The QNX reference
vehicle.

QNX Software Systems had a very popular simulator of its own at CES this year. You may have seen some details on it already but to recap, it is a new incarnation of our trusty QNX reference vehicle, extended to demonstrate ADAS capabilities. We parked it in front of a 12 foot display and used video footage captured on California’s fabled Highway 1 to provide the closest thing to real-world driving we could create.

The resulting virtual drive showcased the capabilities not only of QNX technology, but of our ecosystem as well. Using the video footage, we provided camera inputs to Itseez’ computer vision algorithms to demonstrate a working example of lane departure warning and traffic sign recognition. By capturing GPS data synchronized with the video footage, and feeding the result through Elektrobit’s Electronic Horizon Solution, we were able to generate curve speed warnings. All this was running on automotive-grade Jacinto 6 silicon from Texas Instruments. LiDAR technology from Phantom Intelligence rounded out the offering by providing collision feedback to the driver.

The lane departure and curve speed warnings in action. Screen-grab from video by Embedded Computing Design.

Meeting the challenge
While at CES, I also had the opportunity to meet with companies that are working to make advanced ADAS systems commercially viable. Phantom Intelligence is one example but I was also introduced to companies that can provide thermal imaging systems and near-infrared cameras at a fraction of what these technologies cost today.

These are all examples of how the industry is rising up to meet the challenge of safer, more autonomous vehicles at a price point that allows for widespread adoption in the foreseeable future. Amazing stuff, really — we are finally entering the era of the Jetsons.

By the way, I can’t remember what booth I was in when I drove the simulator. But I’m willing to bet that the people who experienced the Jeep at CES will remember they were in the QNX booth, seeing technology from QNX and its key partners in this exciting new world.

A glaring look at rear-view mirrors

Some reflections on the challenge of looking backwards, followed by the vexing question: where, exactly, should video from a backup camera be displayed?

Mirror, mirror, above the dash, stop the glare and make it last! Okay, maybe I've been watching too many Netflix reruns of Bewitched. But mirror glare, typically caused by bright headlights, is a problem — and a dangerous one. It can create temporary blind spots on your retina, leaving you unable to see cars or pedestrians on the road around you.

Automotive manufacturers have offered solutions to this problem for decades. For instance, many car mirrors now employ electrochromism, which allows the mirror to dim automatically in response to headlights and other light sources. But when, exactly, did the first anti-glare mirrors come to market?

According to Wikipedia, the first manual-tilt day/night mirrors appeared in the 1930s. These mirrors typically use a prismatic, wedge-shaped design in which the rear surface (which is silvered) and the front surface (which is plain glass) are at angles to each other. In day view, you see light reflected off the silvered rear surface. But when you tilt the mirror to night view, you see light reflected off the unsilvered front surface, which, of course, has less glare.

Manual-tilt day/night mirrors may have debuted in the 30s, but they were still a novelty in the 50s. Witness this article from the September 1950 issue of Popular Science:



True to their name, manual-tilt mirrors require manual intervention: You have to take your hand off the wheel to adjust them, after you’ve been blinded by glare. Which is why, as early as 1958, Chrysler was demonstrating mirrors that could tilt automatically, as shown in this article from the October 1958 issue of Mechanix Illustrated:


Images: Modern Mechanix blog

Fast-forward to backup cameras
Electrochromic mirrors, which darken electronically, have done away with the need to tilt, either manually or automatically. But despite their sophistication, they still can't overcome the inherent drawbacks of rear-view mirrors, which provide only a partial view of the area behind the vehicle — a limitation that contributes to backover accidents, many of them involving small children. Which is why NHTSA has mandated the use of backup cameras by 2018 and why the last two QNX technology concept cars have shown how video from backup cameras can be integrated with other content in a digital instrument cluster.

Actually, this raises the question: just where should backup video be displayed? In the cluster, as demonstrated in our concept cars? Or in the head unit, the rear-view mirror, or a dedicated screen? The NHTSA ruling doesn’t mandate a specific device or location, which isn't surprising, as each has its own advantages and disadvantages.

Consider, for example, ease of use: Will drivers find one location more intuitive and less distracting than the alternatives? In all likelihood, the answer will vary from driver to driver and will depend on individual cognitive styles, driving habits, and vehicle design.

Another issue is speed of response. According to NHTSA’s ruling, any device displaying backup video must do so within 2.5 seconds of the car shifting into the reverse. Problem is, the ease of complying with this requirement depends on the device in question. For instance, NHTSA acknowledges that “in-mirror displays (which are only activated when the reverse gear is selected) may require additional warm-up time when compared to in-dash displays (which may be already in use for other purposes such as route navigation).”

At first blush, in-dash displays such as head units and digital clusters have the advantage here. But let’s remember that booting quickly can be a challenge for these systems because of their greater complexity — many offer a considerable amount of functionality. So imagine what happens when the driver turns the ignition key and almost immediately shifts into reverse. In that case, the cluster or head unit must boot up and display backup video within a handful of seconds. It's important, then, that system designers choose an OS that not only supports rich functionality, but also allows the system to start up and initialize applications in the least time possible.

AUTOMOBILE Talking safety in Novi

Grant Courville

Last week, I had the pleasure of participating in a panel at Telematics Update's Advanced Automotive Safety Conference in Novi, Michigan. A key theme of the panel was — you guessed it — safety.

The two-day event brought together automakers, suppliers, government representatives, research groups, integrators, analysts, and educational institutions to discuss the latest standards and innovations in automotive safety and V2X. The show covered all aspects of vehicle connectivity, as well as the relationship of big data and cloud connectivity to automotive security.

The themes of reliability, security, and safety were front and center in my panel, “Automated Vehicles: The Stepping Stone to Autonomous Driving.” The panel was chaired by IHS Automotive and included experts from DENSO, Ricardo Inc., and the National Advanced Driving Simulator. Everyone on the panel agreed that interoperability and standardization are critical to accelerating innovation, and that ADAS systems are paving the path to autonomous driving.

All in all, the show was an informative event that helped identify the next steps in automotive safety — a topic near and dear to the QNX auto team.

---

Grant Courville is director of product management at QNX Software Systems.

Enabling drivers to interact safely with applications and services

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

If you jump to the end of this post, you’ll find a list of use cases being targeted by this effort. For now, let’s look at Use Case 2, Scenario A (arbitration of external message), which illustrates how we are working towards a comprehensive framework for managing distraction and workload.

Keeping priorities straight
In this user scenario, a navigation maneuver is given priority over a social media status update message. The blue call-out boxes indicate where the ITU-T recommendations under development can enable safe interaction between the driver and applications. For instance, ITU-T recommendation G.SAM will define mechanisms for prioritizing navigation, while G.V2A will define the communications interface between the app and the driver-vehicle interface (DVI), and P.UIA will recommend characteristics of the auditory social media message.

Remember that the focus here isn't on how to implement social media in the car, but rather, on how best to manage workload and distraction.



Giving a navigation maneuver priority over a social media status update message

Often, I am asked how this effort differs from the MirrorLink standard being developed by the Car Connectivity Consortium. The simple answer is that MirrorLink addresses only some of the use cases listed below. For instance, the scope of MirrorLink is limited to applications and services running on nomadic devices. Furthermore, adaptation of the driver-vehicle interface and external applications and services in the current MirrorLink solution uses a simple two-state approach, driving or not driving, which limits the ability of the vehicle to control the timing and modality of communications with the driver. Also, MirrorLink doesn’t adequately address arbitration or integration of communications with all external applications and services.

In for the long haul
At QNX Software Systems, our aim is to:

1. Work with the relevant parties to identify solutions to the problem of technology-related driver distraction and workload. These parties include automotive, telecommunications, and consumer electronics organizations; standards development groups; academia; and government agencies.
2. Determine which aspects of the solution should be standardized, then help drive this standardization.
3. Align QNX product roadmaps as solutions develop.

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

The end of the beginning
The first major milestone in this effort was achieved at the closing plenary of the ITU-T Study Group 12 meeting, held on March 28 in Geneva. Here, the final report and 4 deliverables of the ITU-T Focus Group on Driver Distraction were approved. There was also approval of a liaison statement communicating these results to a large list of organizations working on this topic.

This marks the end of the focus group, but is really just the beginning for QNX and ITU-T efforts in this area. In future posts, I will explore various aspects of this comprehensive strategy.

---

Use cases and user scenarios targeted by ITU-T recommendations

Use Case 1: Interaction with external application/service
   a) Application on nomadic device
   b) Application on cloud-based server
   c) Downloaded Application
   d) Broadcast of roadway information
   e) Tethering
Use Case 2: Arbitration and integration of external message
   a) Arbitration of messages
   b) Integration of messages
   c) Both arbitration and integration of messages
   d) E-call
Use Case 3: Negotiation of network Quality of Service (QoS)
   a) Application selects network
   b) Application suspends interaction
   c) Application availability due to roaming
Use Case 4: Management of multiple dialogues
   a) Opening/closing an application
   b) Switching between applications
   c) Interaction with background application
Use Case 5: Adaptation of DVI (driver-vehicle interface) and external applications/services to driver abilities
   a) Driver with disability
   b) Dynamically changing driver capabilities
   c) Detection of impaired driver state
Use Case 6: Adaptation of DVI and external applications/services to roadway situation
   a) Driver busy notification
   b) Delay of message delivery in demanding driving situation
   c) Change message format based on road conditions
   d) Interruption of driver interaction
Use Case 7: Adaptation of DVI and external applications/services to vehicle status
   a) Vehicle enters safe operating condition (e.g., park gear, < 5 m.p.h., etc.)
   b) Driver adjusts vehicle controls (e.g., climate control, etc.)
   c) Suppression of hazard alert due to safe speed
Use Case 8: Adaptation of DVI and external applications/services to local regulations
   a) Application blocked
   b) Application suspended
   c) Interface modality disabled
   d) Age restriction
   e) Content restriction

For details on these use cases, download the FG Distraction Use Cases report.