Especially for organizations in Silicon Valley and elsewhere that are just entering the automotive marketplace, implementing strict requirements management and complying with standards such as ISO 26262 are new ventures. Whereas industries such as consumer electronics are more forgiving to companies that bypass certain functional safety requirements in the name of shipping product more quickly and at lower costs, the automotive sector is based on comparatively interminable development cycles, and for good reason – the functional safety of automotive systems is a matter of life and death every time a car starts.

Unfortunately, while the ISO 26262 standard and other automotive engineering guidelines offer a handbook for developing functionally safe components and systems, they are not altogether straightforward, nor are they actually required by any governing body. The reason these standards are full of intricate nuances is largely thanks to increasing complexity in the multi-tiered automotive supply chain.

In contrast with the siloed, geographically integrated automotive ecosystems of the past, today’s automotive supply chains have seen a munging of roles as players enter the market and new capabilities emerge such as ADAS and autonomous drive, connected car/eMobility, and the software-defined car. Mobileye, for instance, produces both vision SoCs and full vision systems, which are historically roles filled by Tier 1 and Tier 2/3 suppliers. The rabbit hole gets even deeper, as semiconductor IP providers also now provide building blocks that aid in the creation of specialized chips.

Still, the value of ISO 26262 certification by organizations like TÜV SÜD is apparent. For both automakers and their suppliers, getting this stamp of approval from an independent third-party engineering evaluation agency not only validates the quality of software and hardware components integrated into the system stack, it also helps protect automotive electronics vendors against malpractice or negligence in the event of injury or death caused by supposed electronic system failure.

The final responsibility for certification lies with the auto manufacturer, who is tasked with compiling documentation and other engineering evidence into a package for certifying bodies. However, without a clearly defined procedure as to what or how automotive systems and development processes are certified, suppliers are often subjected to not only rigorously managing both product and functional safety requirements, but providing these artifacts to multiple clients, often in different ways, as well.

Thomas Maier, Business Development Manager at TÜV SÜD explained this challenge at Jama Software’s “Managing Safety in Complex Supply Chains” event in Santa Clara earlier this month.

“If you have a certificate that is, say, ASIL C, you cannot really be sure what is behind it. It depends very much on what the certifying organization actually does,” Maier said. “There are many levels of evaluation to ISO 26262. You can just take a process approach, or you can just check that the processes are checked by someone. Then you could also go much deeper on the product side with product review and inspection. If you do that, then the question is, ‘How much could you actually do? What is your depth? What is the technical competency of the assessors?’

“So there are many questions that need to be answered before you can say, ‘This certification actually purveys the confidence that you can use that safety element out of context blindly,’” he said. “So, what the certification process is, I only can speak for TÜV SÜD. What we require you to do is simply follow the standard.”

Dealing with requirements out of context

A component that typifies the challenges posed at certain levels of the supply chain is the term used by Maier, “safety element out of context,” or SEooC. A SEooC is a technology element, either hardware or software, that has not been developed for a specific component, product, or system. This is very much akin to how a general-purpose processor could be used in any type of device, but has significant design and documentation implications for the SEooC manufacturer in the context of an automotive supply chain.

Arteris IP is a semiconductor IP provider out of Campbell, CA. Kurt Schuler, the company’s vice president of marketing, has experience delivering SEooCs into the automotive supply chain. At the event, he explained how this process has changed Arteris’ engineering culture because of the need to align how their IP works with how it will be used in an overall system in a somewhat unspoken manner.

“We do not know what the end safety goals of a system are going to be,” Schuler said. “What that means is that with our IP we have to have assumptions of use and document those. And one of the most important things in ISO 26262 is that the development interface agreement is, in fact, an agreement on these assumptions of use of how our customer is going to use our IP. So you really have to have that documented and well understood.

“[Based on the customer] it’s the same type of documentation that’s expressed in the specification. Now one of the things that’s difficult is that … what you deliver is specified, but how you deliver that is generally not specified,” Schuler continued. “You really have to be able to explain if you have the right assumptions of use and then you have to be able to prove for those assumptions of use.”

A critical component of executing such projects is using proven requirements management processes that not only ensure product and functional safety requirements are being met across development teams within Arteris, but that the design output and documentation meets the agreed upon assumptions of the client/provider development interface agreement.

Requirements management: FuSa or product?

When it comes to managing, documenting, and reporting artifacts for functional safety compliance or the functionality of a product, miscommunication can be costly. For example, miscommunication in a complex design can waste valuable engineering time on project branches that don't satisfy the intended requirements in some small but significant way, or even at all. This is a common occurrence when large, distributed, or multiple development teams are working towards a single solution, and is obviously complicated further when working across organizational lines.

As mentioned previously, it can also be particularly challenging for new entrants into the automotive market who aren't prepared for the ins and outs of managing functional and product requirements simultaneously. Adrian Rolufs of Jama Software explained an example of how organizations mismanage requirements management. 

"I’ll see companies saying, ‘There’s this new functional safety thing that’s new to us, and we’re scared of it so we’re going to be hyper diligent on doing that very well and buy a Jama tool for that and track all of our requirements for functional safety there," Rolufs said. "For product we already know what we’re doing. We’ve been doing that for a long time, so we’re going to do that the old way.’

"That’s a common approach in established companies that are adding automotive capability to their team," he continued. "So they’ve built these products for a long time and say, 'We’re going to hire a couple of functional safety engineers who are going to take care of this functional safety stuff we don’t understand, and we’re just going to keep going business as usual.’

"Now all of a sudden you have room for miscommunication because some of these product requirements have an impact on functional safety at some point," Rolufs went on. "Safety impacts the functionality. It’s not a separate thing. In the end you’re building a product that is hopefully functionally safe and provides the intended function. An engineer has to develop that product within what the requirements are.

"Usually [these companies] get through one cycle of that and realize the flaws in their ways, and maybe their customers reject the product or they have some failures that are really embarrassing and then they start integrating these processes more," he added.

For Rolufs and Jama Software, the better approach is to treat functional safety and product requirements as one and the same. Even in the event that multiple engineering teams are using the same set of requirements, miscommunication and misunderstandings can be minimized. To Rolufs, "With requirements management, the simpler the solution you can come up with, the better. You have simple documentation, all of the requirements are written the same way, everyone can read the requirements in the same format.

"If my data is organized for me and your data is organized for you and I can’t read it, we’re not talking to each other," Rolufs explained. "A lot of engineers like to optimize specific ways of formatting data for their purposes. It works great when you have a team that’s just doing one specific thing, which we see a lot in semiconductors. You have a semiconductor team that for 20 years has been doing power management circuits, they’ll optimize the heck out of the information they have because they’ve done it a certain way for a long time. If you start building systems and you have mechanical teams, software teams, and electrical teams, they work in completely different ways so the optimization for them is very different.

"Finding something simple that they can all understand is really where you get the benefit [of requirements management] because that’s where you really start to break down the barriers between the teams building a product," Rolufs stated.

"Usually those companies see the most success the fastest. They go through fewer iterations of learning along the way," he said.

Requirements management tools for faster functional and product safety

Jama Software's Jama Connect is software-as-a-service requirements management platform certified for use in ISO 26262 development by TÜV SÜD. The tool is designed to tie together requirements in a common language for multiple and/or distributed development teams that consist of product definers, systems engineers, software architects, hardware designers, functional safety managers, customers, and partners in order to simplify the process of defining, validating, and verifying requirements.

According to Maier, the tool certification process is slightly different than certifying other elements of an automotive system. ISO 26262-certified tools must be qualified appropriately for use in the development of certain ASIL levels, and certification of these tools depends on the system or element being produced, the tool's inherent ability to catch or mitigate process faults, as well as how it is maintained over time.

In conjunction with tools like Jama Connect, experts like Rolufs frequently assist companies in the development of requirements management plans that best suit their existing and future product engineering goals. The advantage of this is multifaceted, as not only does it save organizations the cost of developing and certifying their own in-house requirements management platform, it also reduces the amount of expertise needed to address portions of the ISO 26262 standard that frankly don't apply to their core business goals. Developing a safety case, for instance, is one of those tasks.

"ISO 26262, among the many functional safety standards, is the only functional safety standard that actually uses a functional safety case," Maier said. "Because it’s usually a complex specification, you have to do loads of work products, and you can very easily lose the overview of work products. You can very easily just mechanically check off work products and not see the bigger picture.

"The thing about a safety case, is for every work product you do, you have to think about what its role is for the safety case. What is its role at the end? What is required by the ASIL?" he asked. "This is the basic reason that functional safety standards are heavy on processes. You need to build your processes on how you work and how much effort you put into things like specifications and your validations.

"Traceability is a very big issue supported by tools like Jama that collect all of the work products in a meaningful way to develop and execute a safety case," Maier concluded.

For more tips on avoiding the pitfalls of functional safety compliance, requirements management, and product requirements in general, view Jama Software's "Top 15 ISO 26262 Snafus."

eletter-08-07-2018

eletter-08-06-2018