“A recent study by the National Highway Traffic Safety Administration (NHTSA) and supported by auto makers found some drivers took as long as 17 seconds to respond to a takeover request from the autonomous control system to resume control of the car. That’s time drivers don’t have.”
When your car’s on autopilot, will you be alert when needed?
Martyn Williams, Computerworld
“The big thing you want to know about a problem is to be able to figure out what went wrong so you don’t do it again. If you’ve got a good process behind that, there’s a probability you can get that. I really don’t want to put the same, old problem in a different, new use case.”
Bill Chown, SEMI Pacific NW Forum Discussion (below)
SEMI, “the global industry association serving the manufacturing supply chain for the micro- and nano-electronics industries” hosted a spring Pacific Northwest forum which our attendees—Bill Chown (INCOSE CIO, Mentor Graphics Marketing Director), John Blyler (Portland State University Systems Engineering Professor & Advisor) and Derwyn Harris (Jama Software Co-founder & Product Marketing Director)—immediately got together to talk about afterward.
The tragic autonomous driving accident in June has raised awareness and broadened interest in the topic of smarter, safer automotive electronics systems.
In this light, we’re posting a transcript of our attendees’ discussion, divided into three parts with one post each week. Read part two, below.
John Blyler: I think we worry, with automotive electronics systems, that a safety issue might go awry, because so many different systems are interacting in new ways, or potentially new ways. Bringing that around, to, specifically, ISO 26262—which is a type of a functional safety standard that focuses on risk—and this idea that the end products have to show some “goodness” about them. And in this context, that’s called…
Derwyn Harris: Fit for use.
John Blyler: Yes. Fit for use. Thank you. Which kind of gets…
Derwyn Harris: Fit for purpose.
John Blyler: Fit for purpose. Which begins to touch on things that as systems engineers, we’ve known for a long time. In terms of maturity models, how can we know that you have a good process here, that your tool will help us rather than hurt us?
Go faster: Jama for Automotive Electronics Providers
Derwyn Harris: Yeah. It’s an interesting experience for Jama, because we’re building software for automotive electronics systems designers, not the automobile itself. We’re providing a tool for tier-one and tier-two companies and OEMs to build components, software and systems of systems. So finding ourselves needing to meet requests from our customers to be “fit for purpose” required figuring out what that meant and what the reason for the request was.
And, really, it comes down to confidence and trust, and to knowing everything that’s going on within their process. The tools they’re using, the conversations they’re having, the findings that drive certain choices—everything about this entire development process needs to be transparent and understood, and everyone involved needs to trust in that process.
So, trusting that the tool they’re using is also going to adhere to that same rigor is important for these teams. That’s why we’ve sought the ISO 26262 certification that we’re getting [note: received April 12, 2016]. You go through the exact same requirements that a manufacturer goes through, so it’s a rigorous process.
And since the point is to achieve the “fit for purpose” certification; it’s serious. We’re actually going through all the same steps and questions that any organization would go through from a process standpoint. An interesting part of that is the safety manual we’re building, to describe how to use the software in a safe way.
Get moving: Jama for Automotive Electronics Providers
John Blyler: As CIO, I’m experienced with capability models. These were things that were used to judge for the aerospace industry initially, but other industries as well. The repeatability and goodness of the way you produce software and hardware. In the automotive world, they have SPICE, which I believe is a derivative of one of the CMMI models. A question that some folks have asked is, if I already have that, do I need to get a “fit for purpose” or vice versa? Can you comment on the relationship between those two?
Bill Chown: So there’s different layers in there. There’s goodness of process that you’re applying to what you’re doing. And then there’s the applicability of that process to a particular target use case. We have different rules for those target use cases, because there are different risks and there are different challenges. And so ISO 26262 is similar to but different from ARP4754A which applies to aircraft safety. Different standards for slightly different reasons, different sets of conditions and different risks.
So you need to apply a good process to a target use case, and that’s where these standards say, yes, you need a good process but here are the things you additionally need to take care of to make sure that you’re satisfying the needs of the automotive electronics industry, because it has its own set of constraints and its own set of ways of operating.
Now, whether every single fragment in the whole structure needs to be certified to CMMI level or…
John Blyler: ISO 26262.
Stay on course: Jama for Automotive Electronics Providers
Bill Chown: …all that. Probably not, because at the end of the day, the burden of proof is at the very end of the chain.
But they have a job to do, so if I can’t help the automotive manufacturer by providing confidence, it makes their job that much harder, and it’s much less likely that they’re going to want to pick someone who isn’t helping them than someone who is helping them to meet that objective. So it’s well worth considering these things as you go up the chain.
If you’re doing code generation that delivers code that’s going into the vehicle, you’ve got a higher level of responsibility there than somebody who’s helping to describe what the design’s going to be about, but you still can help the end user to meet their needs, if you can give them the confidence.
Derwyn Harris: Yeah. There’s sort of a nice little cascading aspect where the OEMs are requiring the tier ones to show, to demonstrate ISO 26262 and maybe SPICE, if SPICE is embedded within it. And then, in turn, they look to us to sort of fit the purpose. So it sort of cascades it down. I thought it’s kind of like the IoT of process, where we’re all becoming fairly consistent by requiring each other to follow these standards, that there’s a common understanding and trust.
Bill Chown: And that really helps. Having a common understanding makes a huge difference. There are so many cases that you can go back to where there wasn’t a common understanding—something didn’t happen the way it should have—and now it’s finger-pointing.
Derwyn Harris: Right. Yeah.
Bill Chown: And if we can come to a common understanding in the beginning, hopefully, there’s an awful lot less misunderstood instances. But even when there are misunderstood instances, it’s going to be much, much easier to look back through and see what we’ve got and understand what went wrong and what went right.
And the big thing you want to know about a problem is to be able to figure out what went wrong so you don’t do it again. If you’ve got a good process behind that, there’s a probability you can get that.
Derwyn Harris: Especially, as you said, if there’s a lot of reuse going on, you don’t have to keep reusing bad problems.
Bill Chown: I really don’t want to put the same, old problem in a different, new use case, thank you very much.
As companies continue to incorporate autonomous and other innovative technologies into system designs, adding reliable validation, verification and traceability analysis during development becomes critical. This is just part of what Jama’s robust requirements management platform does to help teams build smarter and safer complex systems. Sign up for a free, 30-day Jama trial.