ISO 26262: People, Process and Product

Kurt Shuler, VP Marketing at Arteris IP, is pretty passionate that people working in the automotive supply chain should understand not just a minimalist reading of ISO 26262 as it applies to them but rather the broader intent, particularly as it is likely to affect others higher in the supply chain. As an active ISO 26262 working group member, I guess he has better insight than many of us regarding latent problems that might emerge after an IP, chip or system has nominally been signed off. He makes the point that, in compliance, everyone through supply chain is still learning; a subtle problem at one stage might never become an issue or might eventually emerge only in integration testing in the car.

At each stage in the chain, it is the responsibility of the integrator to determine if vendors of the products they use can validate all the claims they make in asserting they and their product(s) are compliant with the standard. This isn’t just about the product. Kurt summarizes it as being about people, process and product. Claims are required in each of these areas. It can be temptingly easy to go with minimalist check-marks especially on people and process and still pass all requirements on handoff to the next stage. Then later you hear of a problem at a Tier-1 or an Uber or Waymo which might have been flagged as a potential concern in a more robust reading of compliance. Would this have been your fault? Probably not. Did you make money? Almost certainly not. Probably best to accept that participating in the design of a (successful) car these days needs to be a much more collaborative enterprise than it used to be. We all have responsibilities to bound as well as we can how our product may behave throughout the supply chain.

People training is an area where Kurt is clearly concerned about divergence between how he sees compliance being implemented versus the spirit of the standard, especially in IP development. The requirement calls for a trained functional safety manager supported (maybe) by (some) functional safety engineers. But the spirit of the standard calls for a sustainable safety culture which implies training, demonstrated competences and qualifications much more broadly across the organization. This can extend to executives, marketing personnel, engineering staff, documentation teams, quality assurance managers, application engineers and others. Proof of this training can be and often is required by customers and third parties who verify compliance. Obviously this requires a bigger investment but supply chain learning will likely tend over time to those who invest more in organization training.

Kurt also sees deficiencies in how people interpret Quality Processes. As engineers we naturally gravitate towards technologies and tools (requirements management, change management, verification, etc) to address this area but in his view, while these can play a role, this is the wrong place to start thinking about quality management.

Quality management systems (QMS) have been around for a while. You’ve probably heard of ISO 9001, there’s something called automotive SPICE (nothing to do with circuit simulation, this is for automotive software development) and Capability Maturity Model Integration (CMMI). These aren’t tools, they’re processes defining best practices for development and support, though some provide quite specific guidance for semiconductor and software IP development. What is important in demonstrating adherence to a quality process is choosing one of these QMS systems and demonstrating continual use of that system by all employees. Again, not something you can just delegate to the safety team.

In product, Kurt highlights a couple of points that maybe aren’t at the top of your safety checklist. You are designing an IP and someone else will be designing using that IP. Also your testing will not be based on testing the IP in the content of the car, or a Tier-1 system or even in the chip. These could be fairly significant limitations when it comes confidence in the safety of your component in that car. ISO 26262 gets around this by requiring the component provider to document assumptions of use that detail what is expected from the integrator in reasonable use of that component. But the integrator is likely also going to configure your IP and you don’t know what configuration they will ultimately use. Messy. So the standard requires IP vendors and chip integrators to agree upon a Development Interface Agreement (DIA) defining the assumptions used by and responsibilities of both parties. That takes a lot of thought and work on both sides.

Finally. Kurt has concerns about how well IP developers understand the intent behind and practice of failure mode analysis. The natural engineering bias is to get as quickly as possible to quantitative analysis to assess and grade mitigation mechanisms for potential failures – the FMEDA step. But he points out that first you have to spend quality time on the FMEA step, otherwise the FMEDA is meaningless. Unfortunately FMEA doesn’t have a lot of tool support that I’m aware of. This is just hard engineering judgment work, partitioning the design into manageable pieces, deciding what are possible failure modes in each piece, what are reasonable assumptions about the likelihood of those failures and what methods you are going to use to mitigate such failures (duplication, parity, …).

Altogether this is a lot of work and a bigger commitment than some vendors may have fully understood. But to survive the natural selection that will emerge in automotive supply chains, it may not be avoidable. You can get more detail by downloading Kurt’s technical paper.