New to 26262? Have I got a primer for you

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

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

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

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

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

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

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

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

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

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

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.

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)

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.

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:

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.

Jivin' up the Jeep with a fresh new version of the QNX CAR Platform

by Paul Leroux

Reskinnable, reconfigurable,
and refreshed

If you haven’t already heard, we've announced version 2.1 of the QNX CAR Platform for Infotainment. In fact, we’re demonstrating it this week at the Telematics Detroit conference.

So what’s new in 2.1? Well, let’s start with what hasn’t changed. The platform is still based on the same, reliable QNX architecture proven in tens of millions of vehicles. (Fact: In 2012, QNX technology shipped in 11 million cars. If you put those cars end to end, they’d circle the earth — and you’d still have about 6000 miles of cars left over. That's a lot of cars.) The platform also retains its inherent flexibility, allowing infotainment system designers to use multiple app environments, connect to multiple mobile platforms, and create a wide range of systems.

Um... let me correct that statement. The new version is, in fact, more flexible. From the beginning, the QNX CAR Platform has supported both HTML5 and OpenGL ES, the two most popular open standards for mobile development. And now, with version 2.1, it also supports Android apps, as well as apps and human machine interfaces (HMIs) built with the popular Qt 5 application framework.

The QNX reference vehicle — a modded Jeep Wrangler — is the perfect, well, vehicle for showcasing these new capabilities. Take, for example, the new digital instrument cluster, which is implemented in OpenGL ES:



I enjoyed the look of the reference vehicle’s original cluster, and still do. But you know what I like about the new version? It shows how a digital cluster can deliver state-of-the-art features, yet still honor the look-and-feel of an established brand like Jeep. These features include dynamic reconfigurability and the power to display turn-by-turn directions, weather updates, and other information provided by the head unit.

Speaking of which, here is the head unit’s main screen, which serves as a one-stop information center for turn-by-turn directions, weather, music, and recent messages:



Now let’s slide over to the passenger seat for a different perspective. If you look below, you’ll see the head unit’s app tray, which shows how the QNX CAR Platform can blend a variety of apps and HMI technologies on the same display — in this case, native and Android apps running on an HMI built with the Qt 5 application framework. In case you’re wondering, the Android app icons in this image are AutoTrader and TapTu. (That's right, they can be accessed just like other apps.)



If you’ve seen images of the QNX technology concept car (you know, the Bentley!), you’re already familiar with the gorgeous 3D navigation system created by our partner Elektrobit. Well, the reference vehicle also comes with a version of Elektrobit’s nav system, seen here:



And last, here’s an image of my personal favorite, the virtual mechanic. In this case, it's displaying trip information, including duration, mileage, and average speed:



There's a lot to see in version 2.1 of the QNX CAR Platform for Infotainment, but there's also a lot you can't see — such as improved power management, optimizations for faster boot time, and support for more hardware platforms, including Freescale i.MX 6Dual and i.MX 6Quad, NVIDIA Tegra 3, Texas Instruments OMAP 5, and Texas Instruments Jacinto 5 Eco.

What's more, I haven't shown you any of the new, pre-integrated partner apps that have been added to the platform, including HearPlanet, Parkopedia, Soundtracker, and wcities eventseekr. But no worries, I plan to reveal more in coming posts.

In the meantime, I invite you to check out the press release we issued this morning.

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.

Enabling the next generation of cool

Capturing QNX presence in automotive can’t be done IMHO without a nod to our experience in other markets. Take, for example, the extreme reliability required for the International Space Station and the Space Shuttle. This is the selfsame reliability that automakers rely on when building digital instrument clusters that cannot fail. Same goes for the impressive graphics on the BlackBerry Playbook. As a result, Tier1s and OEMs can now bring consumer-level functionality into the vehicle.

Multicore is another example. The automotive market is just starting to take note while QNX has been enabling multi-processing for more than 25 years.

So I figure that keeping our hand in other industries means we actually have more to offer than other vendors who specialize.

I tried to capture this in a short video. It had to be done overnight so it’s a bit of a throw-away but (of course) I'd like to think it works. :-)