Home » IoT Embedded Systems » Featured Stories » What makes Automotive Electronics ISO 26262 Different from other Standards?

What makes Automotive Electronics ISO 26262 Different from other Standards?

A panel representing automotive, semiconductor, software and systems experts met to share insights on the hardware-software challenges of ISO 26262 compliance.

By John Blyler, Editorial Director, JB Systems

ISO 26262 addresses the needs for an automotive-specific standard that deals with the functional safety of hardware-software electrical/electronic/programmable safety critical systems. In alignment with good system engineering practices, ISO 26262 uses a system of steps to manage functional safety and regulate product development throughout the lifecycle on today’s hardware and software-integrated systems. Specifically, this standard details how to assign an acceptable risk level to a system or component and document the overall testing process.

What impact do compliance standards have on the design, verification and testing of electronic hardware-software systems? What new tools might be needed for safety requirements tractability and risk management? Recently, a panel of experts convened at the Jama Software headquarters to discuss the impact of the ISO 26262 functional safety standard on the development of future automotive electronic hardware and software systems. What follows are the key observations from that panel discussion. – JB


  • Mike Bucala, Lead Engineer – Vehicle Systems Quality, Daimler Trucks NA
  • Bill Chown, CIO INCOSE and Product Director, System-Level Engineering, Mentor Graphics
  • Derwyn Harris, Jama Software Co-Founder and Product Manager
  • Fred Roberts, Manager Corporate Applications, CAE Manager at Synopsys
  • John Blyler (Moderator), Editorial Director, JB Systems
Figure: Experts from Daimler Trucks, Mentor Graphics, Jama Software and Synopsys convened to discuss the hardware, software and systems design challenges with ISO 26262 compliance.

Figure: Experts from Daimler Trucks, Mentor Graphics, Jama Software and Synopsys convened to discuss the hardware, software and systems design challenges with ISO 26262 compliance.

Key Observations:

  • Blyler: One might be tempted to say that the focus on functional safety is yet another “Design-for-X” methodology of the day, where “X” is the activity that you did poorly the last product iteration, like requirements, testing, etc. But ISO 26262 is a compliance, risk-based safety standard future automobiles – not a passing fad.
  • Bucala: ISO standard is different than other risk standards because it focuses on hazards to persons that result from the malfunctioning behavior of EE systems – as opposed to the risk of failure of a product. For purposes of liability and due care, reducing that risk implies a certain rigor in documentation that has never been there before.
  • Chown: ISO 26262 is a specific derivation (IEC 61508) of a broader standard that worries about electrical and electronic systems. There are similar standards for aviation, medical, railroads, etc. We need to take what we learn in one industry and apply that across all industries.
  • Harris: We (Jama) are primarily a requirements management tool vendor. Why do we need to be certified for safety functionality? We do it so our customers will have confidence that our tool wouldn’t introduce problems when developing to this standard. it was an issue of demonstrating that our tools core functionality would not break things already in software.
  • Roberts: You cannot have the blue screen (of death) in a embedded car as you would on a PC. The standard helps you think about functional safety early in the design process. In the past, you would think about quality but there wasn’t that consequence (of human injury) in quality.
  • Roberts: You can’t release a patch for hardware IP as you would for software. Plus, with ISO 26262, you need to document the fix and prove that you are improving your process to eliminate that problem from happening again.
  • Chown: Not only do I have to demonstrate that the thing I fixed fixes the problem, but that it doesn’t have a side effect – even an undocumented one. Do I have a process that will help me understand how that happens ISO 26262 is really a mandatory standard even if it isn’t mandated. You must support it if you want to do business in the automotive electronics market.
  • Bucala: In the US, there is the issue of legal discovery. If you document a hazard then decide not to mitigate the hazard, you expose your company to potential consequences. The regulatory environment in Europe with type approval is different and somewhat immune from certain forms of liability.
  • Chown: How do I assess the system risk effectively? Do I treat everything as risky? That could cost a lot of money and put a lot of unnecessary layers of process in place. How do I go back and understand the real risk? With a systems engineering approach.
  • Harris: You want to avoid the “death by a thousand pin pricks,” where you mitigate every single risk to just an acceptable level. Now you may have created an inherently dangerous product because everything is barely on the edge of being acceptable. You have to gain a systems perspective.
  • Chown: I don’t believe that this standard is creating more processes or a different type of process. I believe it is requiring the existing process to pay attention to itself. In the past, you could skate over the details. Now, if you can put some traceability in place, it starts to reveal the areas weak in safety.
  • Bucala: I obtained a certification from TUR Nord in a week. That doesn’t mean that I was fluent in the standard but now I know where to look for answers.
  • Blyler: What’s being asked by this standard isn’t that much more than other standards have required in the past, such as the Capability Maturity Model Integration (CMMI) for hardware and software systems.
  • Chown: There are similarities between ISO 26262 and other standards in terms of assessing the probability of risk. How likely is a problem to occur and therefore what do I need to do about it? The big difference is the way each standard interprets the risk and specific terminological wordings.
  • Harris: If you have a (safety-aware) process that you feel is sound and you have documented that process, then there is a good chance you are 80 to 90% toward the essence of the intent of the ISO 26262 standard.
  • Roberts: In terms of understanding the standard, it is pretty well divided up into several different sections. You can spend a little bit of time at the 20,000 foot view to understand where everything is and the dig into those parts that apply to you.
  • Harris: There are several organizations that will help you with ISO 26262 certification, including Tuv Nord and Tuv Sud.
  • Harris: Many of these types of standards use different terminology, approach problems differently and think they are different from everyone else. But at the end of the day there are a lot of similarities. Ultimately, it is up to our customers to configure and utilize our software. There is the concept of intended use.
  • Roberts: Unlike a software company, if we release a bug in our hardware IP, we can’t release a patch to fix it. Further, we now have to look at failures that may happen for some other reason besides introduction of a bug. It may be a stray neutron, an electrical surge in the vehicle. We don’t know what would cause that failure but now we have to be able to detect and report it. This adds a new dimension to our design process.
  • Bucala: In the next version (2017) of ISO 26262, chip vendors will get their own section (#11). In the updated standard, we’ve considered business models from the semiconductor viewpoint.
  • Bucala: A big part of the updated standard (in 2017) will deal with safety elements outside of context, that is, beyond the intended design of the product. For example, we will address trucks and buses in the updated standard, which add the complication of intended use. The original design builds the truck for one purpose but then the buyer puts a machine or box on the back of it. How do you keep the residual risk down to an acceptable level in that situation?
  • Michael: At the very earliest stages of automotive electronic design, the hazards are envisioned that could result from the malfunction of a system. And those become translated into safety goals that mitigate those hazards. But that same safety goal then cascades throughout the entire life cycle process, through every step in the development and manufacturing chain. All the way to the microchip, at which that microchip is validated for a level of reliability that when integrated into an ECU and system maintains a certain level of reliability. It becomes an interesting way of showing that cascade of requirements that we haven’t had previously. In driving systems engineering to a new level of discipline.
  • Bucala: Cybersecurity is something that we have talked about a lot in the past two years of development of the ISO 26262 standard. We have intentionally segregated cybersecurity into its own discipline. There is a band new SAE standard for cybersecurity, chaired by Barbara Czerny. In the new version of the ISO 26262 standard (2017), we will include a handshake point at the systems level at which the hazards that can result from intentional misuse are considered – for example, from hackers.

Great information delivered straight to your inbox

Leave a Reply

Your email address will not be published. Required fields are marked *