Automotive Hardware-Software Challenges with ISO 26262

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

Panelist:

• Mike Bucala, Lead Engineer – Vehicle Systems Quality, Daimler Trucks NA
• Bill Chown, CIO INCOSE and Product Director, System-Level Engineering, Mentor Graphics Corporation
• 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

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.

Read the full story at JB Systems