cars: Safety systems

Showing posts with label Safety systems. Show all posts

Klocwork joins QNX automotive safety ecosystem

Paul Leroux

This just in: Klocwork, a leader in development tools for creating secure software, has become an ecosystem partner for the QNX Automotive Safety Program for ISO 26262.

Klocwork joins a roster of companies, including Elektrobit, Freescale, NVIDIA, and TI, who already support the program, which is designed to help automotive companies build digital instrument clusters, ADAS systems, and other products with functional safety requirements.

Klocwork offers Insight, a source code analysis tool recently certified to the ISO 26262 and IEC 61508 functional safety standards. Insight plugs directly into the QNX Momentics Tool Suite, allowing developers to detect security and safety vulnerabilities on the fly, and to ensure their code meets functional safety standards.

"Klocwork Insight provides real-time feedback during code development, immediately alerting developers to code that may conflict with the MISRA C/C++ coding standards required by ISO 26262," said Grant Courville, director of product management at QNX. "Better yet, Insight plugs into our IDE to provide a seamless and productive development experience."

The QNX Automotive Safety Program for ISO 26262 was created to help automotive companies building functional safety products to leverage QNX Software Systems’ proven competency in certifications, safety-critical systems, and automotive software design. Key elements of the program include an example safety case based on the QNX Neutrino RTOS Safe Kernel, guidelines on safety-critical design for real-time OS-based systems, a suite of professional services, and an ecosystem of supporting vendors who offer complementary hardware, tool chains, graphics technologies, and consulting services for safety critical systems.

Read the press release.

Beyond the dashboard: discover how QNX touches your everyday life

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

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

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

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

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

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

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

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

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

Cyber security and connected cars

What does cyber security mean, what does it affect, why is it becoming critical, and what can you do about it? Those were some of the questions I addressed in a recent webcast on automotive cyber security, hosted by SAE International. I represented the software side of things and was accompanied by my hardware colleagues Richard Soja and Jeffrey Kelley, who work at Freescale and Infineon respectively.

I’ve hosted webinars on a variety of automotive and embedded software topics, but none with such an impressive range of participants. We had people from government organizations of several countries, not to mention automakers, tier 1 and tier 2 auto suppliers, telematics companies, mobile developers, concerned individuals, and even utility companies. And the range of questions and comments was equally diverse — from specific insights about elliptical encryption to sweeping “how does this affect society” musings.

My key takeaway: QNX isn’t alone in its concern for automotive cyber security. We have years of experience in building secure trusted systems and we’re excited to help customers build tomorrow’s secure cars. Nice thing is, the rest of the world is starting to get on board as well.

If you're interested, you can download the archived version of the webinar.

A need for speed... and safety

Matt Shumsky

For me, cars and safety go hand in hand. Don’t get me wrong, I have a need for speed. I do, after all, drive a 2006 compact with 140 HP (pause for laughter). But no one, and I mean no one, wants to be barreling down a highway in icy conditions at 120 km/hr without working brakes, am I right?

So this begs the question, what’s the best way to design a software system that ensures the adaptive cruise control system keeps a safe distance from the car ahead? Or that tells the digital instrument cluster the correct information to display? And how can you make sure the display information isn’t corrupted?

Enter QNX and the ISO 26262 functional safety standard.

QNX Software Systems is partnering with LDRA to present a webinar on “Ensuring Automotive Functional Safety”. During this webinar, you’ll learn about:

Development and verification tools proven to help provide safer automotive software systems
How suppliers can develop software systems faster with an OS tuned for automotive safety

Ensuring Automotive Functional Safety with QNX and LDRA
Thursday, November 20, 2014
9:00 am PST / 12:00 pm EST / 5:00 pm UTC

I hope you can join us!

My top moments of 2013 — so far

Paul Leroux

Yes, I know, 2013 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 2013 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 2013 — 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 2011, 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 2013 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 2013 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. :-)

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 2011, 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 2012, 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:

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

The ISO 26262 functional safety standard: No way but up?

I was scanning some Google alerts the other day when my eyes stopped at an announcement from Freescale. The headline didn’t mince words: the Freescale Qorivva MPC5643L microcontroller, a 32-bit part based on the Power architecture, has become the first automotive MCU to receive ISO 26262 functional safety certification.

Did you notice? Freescale didn’t say only; they said first. Which suggests they see ISO 26262 as a growing trend in automotive. If so, I think they see right.

If you’re unfamiliar with ISO 26262, let me provide the Reader’s Digest version. First and foremost, it applies to automotive electronic or electrical systems that could pose a hazard (i.e. hurt people) if they malfunction. Examples include anti-lock brakes, traction control systems, adaptive cruise control systems, engine control units, and digital instrument clusters.

Will more automotive
components soon come
with stickers like this?

The standard isn’t concerned with how well such systems perform. Rather, it’s about reducing the risk, and mitigating the effects, of any malfunction that may cause injury or death. So even if something bad unexpectedly happens in a 26262-certified system — and the assumption is that bad things will happen, no matter how well the system is designed and tested — the system will minimize potential harm. For instance, consider the scenario where a high-priority software process enters an infinite loop and starts to gobble up CPU cycles. Obviously, it’s important to prevent this error from happening in the first place. But even if it does happen, the system should prevent the rogue process from starving other critical processes of CPU time. It should also achieve a graceful recovery from the failure state.

ISO 26262 applies to production passenger vehicles with a gross mass up to 3500 kilograms (7716 pounds). Anything else is out of scope. But while the scope is limited, the standard itself is comprehensive. It covers functional safety aspects of the entire development process, from requirements specification to product decommissioning. And in case you were wondering, it’s closely related to IEC 61508, the international safety standard with a very long history and which many other safety standards reference.

So why do I think that 26262 is on the ascent? For starters, the first edition of the standard was published less than a year ago, yet a silicon vendor has already spent the considerable effort to get an MCU certified. Achieving certification to a standard like ISO 26262 doesn’t come easy, so I assume Freescale did it only because they anticipate market demand. (Disclaimer: This statement isn’t based on any special knowledge of Freescale’s business, but is simply my opinion. Interpret it as such.)

TÜV Rheinland:
Also in the game

It doesn’t stop at Freescale. TÜV Rheinland, a global provider of technical services for safety-critical systems, now offers 26262 services (training, consulting, testing, certification, you name it) for a wide variety of automotive components in multiple geographies. And if TUV has gotten in the game, it’s a good signal that the 26262 standard has legs.

Meanwhile, the LinkedIn group dedicated to 26262 has more than 3600 members and grew by more than 50 members last week alone. If you visit the group, you’ll find engineers from automotive OEMs and tier ones looking for guidance on satisfying 26262 requirements — a sure sign that support for the standard is gearing up.

From what I can tell, things haven’t gotten to the point where a company has been mandated to have its automotive systems certified to ISO 26262. But it will happen. And chances are, it will snowball: the more companies that adopt the standard, the more others will feel the pressure and follow suit. Which means it’s only a matter of time before more ISO 26262 product announcements show up in my Google alerts.

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.

Some forward-thinking on looking backwards

The first rear-view camera appeared on a concept car in 1956. It's time to go mainstream.

Until today, I knew nothing about electrochromism — I didn’t even know the word existed! Mind you, I still don’t know that much. But I do know a little, so if you’re in the dark about this phenomenon, let me enlighten you: It’s what allows smart windows to dim automatically in response to bright light.

A full-on technical explanation of electrochromism could fill pages. But in a nutshell, electrochromic glass contains a substance, such as tungsten trioxide, that changes color when you apply a small jolt of electricity to it. Apply a jolt, and the glass goes dark; apply another jolt, and the glass becomes transparent again. Pretty cool, right?

Automakers must think so, because they use this technology to create rear-view and side-view mirrors that dim automatically to reduce glare — just the thing when the &*^%$! driver behind you flips on his high-beams. Using photo sensors, these mirrors measure incoming light; when it becomes too bright, the mirror applies the requisite electrical charge and, voilà, no more fried retinas. (I jest, but in reality, mirror glare can cause retinal blind spots that affect driver reaction time.)

So why am I blabbing about this? Because electrochromic technology highlights a century-old challenge: How do you see what — or who — is behind your car? And how do you do it even in harsh lighting conditions? It’s a hard problem to solve, and it’s been with us ever since Dorothy Levitt, a pioneer of motor racing, counseled women to “hold aloft” a handheld mirror “to see behind while driving.” That was in 1906.

Kludges
For sure, we’ve made progress over the years. But we still fall back on kludges to compensate for the inherent shortcomings of placing a mirror meters away from the back of the vehicle. Consider, for example, the aftermarket wide-angle lenses that you can attach to your rear window — a viable solution for some vehicles, but not terribly useful if you are driving a pickup or fastback.

Small wonder that NHTSA has ruled that, as of May 2018, all vehicles under 10,000 pounds must ship with “rear visibility technology” that expands the driver’s field of view to include a 10x20-foot zone directly behind the vehicle. Every year, backover crashes in the US cause 210 fatalities and 15,000 injuries — many involving children. NHTSA believes that universal deployment of rear-view cameras, which “see” where rear-view mirrors cannot, will help reduce backover fatalities by about a third.

Buick is among the automotive brands that are “pre-complying” with the standard: every 2015 Buick model will ship with a rearview camera. Which, perhaps, is no surprise: the first Buick to sport a rearview camera was the Centurion concept car, which debuted in 1956:

1956 Buick Centurion: You can see the backup camera just above the center tail light.

The Centurion’s backup camera is one of many forward-looking concepts that automakers have demonstrated over the years. As I have discussed in previous posts, many of these ideas took decades to come to market, for the simple reason they were ahead of their time — the technology needed to make them successful was too immature or simply didn’t exist yet.

Giving cameras the (fast) boot
Fortunately, the various technologies that enable rear-view cameras for cars have reached a sufficient level of maturity, miniaturization, and cost effectiveness. Nonetheless, challenges remain. For example, NHTSA specifies that rear-view cameras meet a number of requirements, including image size, response time, linger time (how long the camera remains activated after shifting from reverse), and durability. Many of these requirements are made to order for a platform like the QNX OS, which combines high reliability with very fast bootup and response times. After all, what’s the use of backup camera if it finishes booting *after* you back out of your driveway?

Instrument cluster in QNX technology concept car displaying video from a backup camera.

Acoustics, ADAS, and autonomous cars, oh my!

Lynn Gayowski

Trying to make sense of where automotive technology is headed can be as tricky as finding your way through a poppy field while avoiding flying monkeys. Well strap on your shiny, red, video-watching shoes because Derek Kuhn can help. Derek, VP marketing and sales for QNX, was interviewed at Telematics Detroit and did an excellent job of summing up the latest on automotive acoustics, advanced driver assistance systems (ADAS), and autonomous cars.

QNX announced the new QNX OS for Automotive Safety at Telematics Detroit, so safety was clearly top of mind during the interview. One question posed was whether automakers have the potential to use safety options as revenue generators. There's a quote here I love: "Safety shouldn't be about premium." OEMs need to find cost-effective ways to bring next-generation safety to the mass market, not just luxury vehicles.

The section of the video I find most interesting is when Derek discusses how acoustics in a car play a big role in creating "the emotion and experience of driving." Noise reduction technology and engine sound enhancement both have a significant impact on a driver's affinity for a vehicle, and OEMs are taking note.

Check out the video for yourself here, my pretties:

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!

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.

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.

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

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)

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 2011, the Focus Group reached the end of its study period in March 2013 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:

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.
Determine which aspects of the solution should be standardized, and help drive this standardization.
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 2013, 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.

(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.