A matter of urgency: preparing for ISO 26262 certification

Yoshiki Chubachi

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

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

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

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

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

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

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

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

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

---

Additional reading

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

My top 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. :-)

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.

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!

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

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

Static Analysis' Role in Automotive Functional Safety

Thursday, July 17

10am PT, 1pm ET, 5pm UTC

Registration

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

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

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

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

---

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

The palindromic standard

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

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

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

The certificate.

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

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

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

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

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

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

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

---

Recommended reading

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

The isolation imperative: protecting software components in an ISO 26262 system

Software components can be impolite, if not downright delinquent. For instance, a component might:

• rob other components of CPU time
  
• rob other components of file descriptors and other system resources
  
• access the private memory of other components
  
• corrupt data shared with other components
  
• create a deadlock or livelock situation with other components
  

Shameful, I know. But in all seriousness, this sort of behavior can wreak havoc in a safety-critical system. For instance, let's say that a component starts to perform a CPU-intensive calculation just as the system enters a failure condition. Will that component hog the CPU and prevent an alarm process from running?

The answer, of course, is that it damn well better not.

It becomes important, then, to prevent components from interfering with one another. In fact, this principle is baked into the ISO 26262 functional safety standard for road vehicles, which defines interference as:

"...the presence of cascading failures from a sub-element with no ASIL [Automotive Safety Integrity Level] assigned, or a lower ASIL assigned, to a sub-element with a higher ASIL assigned leading to the violation of a safety requirement of the element”

To put it crudely, less important stuff can't stop more important stuff from happening.

So how do you prevent interference? One approach is through isolation. For instance, a system may implement spatial isolation between application processes. This would include mechanisms for interprocess communication and interprocess locking that prevent one process from inadvertently affecting another.

Mind you, there are multiple types of interference, so you need to implement multiple forms, or axes, of isolation. Time for a picture:




In general, you need to determine what does, and what doesn't, need to be isolated. You also need to identify which components are apt to be delinquent and build a cage around them to protect more critical components. Which brings me to a recent paper by my inestimable colleagues Chris Hobbs and Yi Zheng. It's titled "Protecting Software Components from Interference in an ISO 26262 System," and it explores techniques that can help you:

• implement the component isolation required by ISO 26262
• demonstrate that such isolation has been implemented

And while you're at it, check out the other titles in our "safe" whitepaper series. These include "The Dangers of Over-Engineering a Safe System" and "Ten Truths about Building Safe Embedded Software Systems."

And don't worry: there's nothing delinquent about downloading all of them.

My top 10 QNX Auto posts from 2015

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

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

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

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

Oops, I guess that makes 11.

Bringing safety assurance to automotive instrument clusters

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

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

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

Notional example of a primary flight display

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

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

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

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

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

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

Visit the DiSTI blog here.

---

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

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