Automotive IQ managing editor, Will Hornick spoke with Bill Taylor, Managing Partner at kVA USA about functional safety and the ISO 26262 standard. Their conversation covered the challenges that many automotive companies are dealing with in implementing this state of the art functional safety standard and developments in the industry making functional safety even more important. Additionally, Bill shared his insight into some of the different traditions of safe development in the U.S. compared to Europe.
I’m interested in your background and what attracted you to the industry?
My background is in the automotive industry, which is a common background for all of kVA’s engineers. We hire automotive people who have done product engineering in the automotive space. We live and breathe cars.
I think that the auto industry is unique. It’s unlike any industry out there, in its massive scale and its impact on people’s lives. The industry is undergoing major changes, which are really exciting. Vehicle features are growing quickly, with expanding electronic and software systems.
I often hear the comment that cars are so electronic and interconnected that they are becoming like cell phones. Well, yes and no. The car is more connected, yes, but it’s still a car. And it must be developed in a way that it stays safe in operation. If you have a cell phone with a bug or a glitch, it’s just an annoyance. But if an automobile has a glitch, then people can get injured or worse. A car is a 3000 - 4000 pound piece of machinery. That creates unique safety issues that need to be addressed.
What new projects/technologies do you see in the auto industry that require functional safety expertise?
Functional safety is a big issue for what we would think of as "traditional" automotive systems. If you look at engines, transmissions, steering, brakes and so forth, all of these systems are being improved with more electronics and more software. So that provides a lot of great advantages, in that we get smoother shifts, better fuel economy, better braking performance, etc. All these systems can be improved with electronic functions. But all these systems are also safety-critical systems. So they cannot afford to have any bugs or faults that create unsafe events. When we add electronics or software to these systems, we need to ensure the systems are still safe. And that is where functional safety standards like ISO 26262 play a role.
Another topic area involves automated driving features. "Automated" is a word that covers a lot of ideas - it can be anything from a feature like lane centering, adaptive cruise control, traffic jam assist, and so forth, all the way to fully automated driving vehicles. Again, when those technologies work the way they are supposed to, the user experience gets better and more convenient. But if those automated systems fail, they impose risks that need to be addressed.
There is an adaptation going on in automotive space. We are moving towards more automation, more electronic integration. This shift creates a lot of new issues that need to be worked out, safely. That’s what kVA does. We work with the OEMs, suppliers, and regulators in some cases, so that the new innovations in new vehicles are all still safe.
Do you see the traditional phrase of quality management playing a role here as well, or is functional safety unique?
This is a good question, because there are certainly some aspects of quality management that are critical for safety. For example, one part of the ISO 26262 standard is to have appropriate quality management measures in place as you execute your engineering development process.
Quality management is necessary but not sufficient to achieve overall system safety. What functional safety adds is a systematic way to design out potential design malfunctions within the system, verify it with test and analysis, and ultimately produce a design that is safe. So it’s not only about product quality, but also about how the product is designed and developed.
For some of the people who may have been in the more traditional quality management role, what did functional safety consist of prior to the ISO 26262 guideline?
We always say that ISO 26262 didn’t invent safety. Before the standard existed, we were still developing safe vehicles and there were methods available in the past to do that. There were some other international standards like IEC 61508, which can work but isn’t well-matched to the needs of the automotive industry. Sometimes industry groups came together to develop system-specific standards- for example the Egas standard, which we’ve used quite a bit in the past. And individual automakers have all sorts of internal processes they use to make sure things are safe. Safety is always taken very seriously by the automotive industry.
So it’s not the case that we come to ISO 26262 with a base of zero. Not at all. But what we do see is that, in the past, different automakers and regulators had spoken different languages. The ISO 26262 is really a standard that encourages us to harmonize – to use the same language and ratings systems, and the same kinds of analysis techniques and terminologies. And so I think it is a big step forward for us to be able to harmonize and streamline the discussion.
How do you sell the benefits of ISO 26262 to a relatively small company that either might be not used to working with it or just doesn’t have the staffing level or the knowledge level to deal with it?
There are definitely some resource requirements for functional safety, and there is no getting around that. The standard requires a safety manager, it requires sometimes more process, more tools, more in the way of personnel support. So there are some direct costs associated with achieving safety, and we need to recognize this. By the same token, one big advantage of ISO 26262 standard is that it brings our focus, and our resources, to the early phases of the development process. There are many studies showing the positive impact of catching issues as early as possible in product development. We can save a lot of money by identifying issues early. ISO 26262 helps us do this.
One important philosophy is that ISO 26262 doesn’t consist of entirely new tasks and requirements. Many companies bring to the table a good starting point. For example, in the automotive industry, a lot of companies do FMEAs to evaluate safety issues in design. Safety analysis including FMEAs are a part of what ISO 26262 requires. So sometimes we can use either existing processes, or slight modifications of those existing processes, to conform to ISO 26262 requirements.
The standard does impose resource requirements on suppliers, and it needs to be taken seriously and resourced accordingly. More and more, it is becoming a ticket of entry for automotive suppliers.
You are located in the U.S. What kinds of challenges has the ISO guideline brought specifically to the US automotive industry? How have the challenges differed for European companies?
Well there are some typical challenges we see when implementing ISO 26262 no matter the location. We need to write good safety requirements, perform safety analyses, understand ASIL decomposition, etc. - the list goes on. The challenge is pretty substantial, no matter where in the world the product is designed. The ISO 26262 provides the roadmap to address these issues using consistent techniques and methods. But following that roadmap can be a challenge.
Having said that, there is a different history depending on where our clients are located. In some European nations for example, there is a strong history of calculating fault metrics, which are basically the numbers that would "prove" that the safety functions are reliable. And ISO 26262 Part 5 includes requirements to make these calculations for ASIL C and D systems –the most safety critical systems. Those calculations are not trivial. The US automotive industry hasn’t traditionally done this, and probably hasn’t entirely embraced the concept of calculating those numbers.
We spend a lot of time with our US clients in calculating probabilistic metrics for hardware failures, safety failure fractions, single point fault metrics, all of these kinds of numbers that standards require. But sometimes these calculations can be misinterpreted, because they are sometimes stretched beyond their original intent. These calculated values are really meant to address random hardware failures, and not systematic failures. So for example, if you have a software component, and it is supposed to return a certain value – value X – if you make a mistake in writing the software, it returns value Y instead. That is not something we can address with a probabilistic calculation. That is a systematic issue, and that has to be addressed with systematic measures. Those measures are things like code development processes, code testing, inspecting and reviews, tool-chain confidence, and good requirements management.
I do think that there is a growing recognition globally that safety is about much more than probability of component failure. Safety is a systems issue. That’s an important idea, and ISO 26262 reflects that idea in many ways.
What’s different for the U.S. market versus the European market when it comes to functional safety?
Well, there are some differences related to the legal systems and industry norms. For example, in Europe, there is a strong tradition in the safety community of using ISO standards and a credible third party assessor. This combination provides strong liability protection in many European legal situations.
In the US, things look somewhat different. There are big variations in liability laws from state to state, and the court system is somewhat less predictable. Some concepts that work well in the E.U. are not as workable in American legal environments – for example the concept of Tolerable Risk or Reasonable Risk. We work very hard to stay in tune with our U.S. clients, to really listen to what they need and how to structure their safety cases, so that the end outcome really lowers risk for everyone.
But despite differences, there’s a common theme: the decision to achieve safety according to accepted standards is critical in any product liability situation. We see ISO 26262 as a standard that will carry a lot of weight in this area, worldwide.
Has the ISO 26262 standard made enough of an impact to say that development is fundamentally safer?
We have seen specific cases where we can identify safety issues with safety analysis, that wouldn’t have been found before ISO 26262 processes in place. Maybe testing would have uncovered these issues later, maybe not. But with ISO 26262, we find them earlier. For example, we‘ve found software components that weren’t developed to the ASIL standards of ISO 26262 part 6, yet were mixed with safety-related code. ISO 26262 says that if you’re not able to show "freedom from interference" between safety and non-safety code, then the full embedded software needs to be developed according to ISO 26262. So that has to be changed. In some cases, this leads us to find a different way. For example, ASIL decomposition of the software, into ASIL and QM components that are separate, so that common cause failures are avoided.
Could we discuss the changing landscape in the automotive industry? You spoke about automated driving features and electrification, which might enable some companies to enter the automotive industry that have traditionally been other industries.
We see different needs across the spectrum. On one end of the spectrum are traditional automakers. They bring a lot of established processes to the table, built up over many decades of experience. On the other end of the spectrum, we see companies without a history of automotive development, and all of these processes are relatively new to them. So there’s a demand for structured methods to make these products safe, among the new industry players.
One example is human machine interaction or HMI. I think everyone recognizes HMI as a key factor in the safety of automated vehicles. In fact a lot of these companies that are new to this domain have a lot of expertise in HMI, but from a background of consumer products and internet devices. And there are different priorities in that space. For example, if you’re designing an infotainment system or smart phone, you might prioritize multi-function capabilities, innovation, speed to market, and new cool applications.
But if we’re not careful, those priorities can run counter to safety priorities. In the cars we all drive, the gas pedal is on the right and the brake pedal is on the left. I don’t want innovation in the layout of those pedals. I always want those to be the same. Those traditions are pretty deeply intertwined in what it means to be safe.
We need to develop future cars, without compromising the safety we have achieved in the automotive space. And that takes a careful balance.
I’m very open minded about what specific innovations might be workable, in vehicle automation and across the spectrum. We are definitely going to see some changes in the automotive space. The product will be different - but it will still be a car, and we still have to assure its safety for the car buying public. There are some smart people developing some great futuristic concepts out there. They’ll figure it out over time.
Another difference in perspective that a lot of these new entrants bring, which again is not right or wrong, just different, is their focus on their speed to market and agile software development. In the safety world, often times we limit ourselves to use, for example, only a limited subset of a programming language, where we say only this well-understood, fully verified functionality is authorized for use in our safety software. And that can be a bit limiting, because people want to push the envelope and always want to do things faster and use all the fanciest tricks they have in their coding toolbox. Sometimes safety standards just don’t allow it. I think it can be frustrating for innovators sometimes. Standards like ISO 26262 say we deliver these trusted methods, we verify everything, validate everything we do – sometimes that’s not the recipe people use for radical innovation.
I love innovation. But: I’m happy when the software in control of my car is built methodically and deliberately.
I can imagine that some of your clients who are newer in this field do really rely on some of that wisdom that you spoke there.
Look, it is very rare outside the automotive space to have large machines carrying passengers past each other, each going 70 mph in opposite directions separated by a few feet, with only a minimally trained driver to control it all. If you have not dealt with that challenge before in a safety sense, then the automotive industry is a very new place for you. That is the kind of thing we take for granted in the automotive space. Our cars do that every day. That is just a different world from the perspective of other industries out there.
Given that potential future, how do you see those challenges changing in time? Do you see the standard getting updated?
Absolutely. There are new sub-committees working on future updates of ISO 26262 to include commercial vehicles and motorcycles, and also for semi-conductors. Semiconductor manufacturers are a good example of how these changes to the standard come about. These are companies that have to design and develop products far before they get detailed requirements from their customers. They develop on their own initiative, based on what they believe will be the demand later. And they make products that go into a wide variety of applications.
Despite those challenges, we see that the semi-conductor industry really is taking a leadership role in ISO 26262. They typically use the methodology we call Safety Element out of Context, or SEooC. That method within ISO 26262 allows elements like microprocessors to be developed independently from their usage context. The concept of SEooC was defined late in the first round of development of ISO 26262, in part 10. So it ended up in the informative part, as opposed to the normative part. We see high probability of substantial updates to the SEooC guidance in future versions, because the SEooC approach can really work. And in fact, it works not only for semiconductors, but also for folks developing other sub-components or sub-systems in an overall vehicle.
The automotive industry hasn’t fully embraced multi-core processors but they are becoming important.
Yes. One architectural principle is to design a safety related system such that it isn’t degraded or interfered with by a non-safety system (which may not have been designed with the same rigor). Traditionally that has meant a separate micro-processor, for example, to compute all your safety checks and plausibility checks, physically separate from your baseline processor. Multi-core processors, if designed correctly, can actually put safety and non-safety software and hardware together on the same piece of silicon. But if you were to put that piece under a microscope you will see that there is physical separation between the safety and non-safety function. So the multi-core is a really nice fit in many cases.
What kind of timeline do you believe is realistic moving to a predominantly multi-core industry?
All the major players are working on implementing multi-core, and safety is a major driver of that. So we’ll see a lot more of them in the next three to five years because the development is well underway behind closed doors. Having said that, it is not clear that every application will go to multi-core. It is just going to depend, as all things always do, on the cost versus the benefit. But certainly they will play a major role over time.
I am interested to learn your approach to functional safety and some of the tools that you and your company actually provide.
At kVA we have clients that come to us with a pretty wide variety of needs and also a wide variety of starting points. Some start with a lot of safety background and safety processes in place, while others start from scratch. They all want to get to the same place. They all want to develop safe products, and they want to have a structured, verified safety case that they can use to document product safety.
So at kVA, we are a US-based company and we are specialize entirely in functional safety, and we have been doing this for a while now, since before the final version of ISO 26262 was even published. We perform safety analysis, such as FMEDA and FTA. We write safety requirements and do structuring of those requirements – so, moving down from higher to lower levels and requirements for composition. We also perform hazard analysis and risk assessment using ISO 26262 principles. And we have tools, templates, and methodologies in all of those areas that are consistent with ISO 26262, and practical for use in the real world development programs.
We also work in topic areas not covered by the current ISO 26262 standard, and try to use the best methodologies from any credible source to fit the need. In automation for example, some issues are not a good fit for the current scope of ISO 26262. So we step outside the world of ISO standards, and into other methods where we think it makes sense.
There are also certain roles defined in ISO 26262 that our company can fulfill. Sometimes that includes kVA serving as the safety manager on a program. Or, sometimes a safety manager exists in house, but that safety manager needs an assistant and collaborator - someone to help them make sure they are doing their job completely. We sometimes serve as advisor to the safety manager. And there are also cases where we will serve either as a safety reviewer, auditor or assessor. So we serve those roles as well. Every client is unique, and their needs are unique.
You provide support from the beginning to the end of the process. Must be pretty rewarding.
It is. At the founding of the company we invested in understanding the standard and how it impacts safety. We have spent a lot of time really understanding those details. And now that we see the standard being rolled out extensively in the US market, we see a lot of demand. It is rewarding. And I think it is also rewarding to work on almost every part of the vehicle. At kVA we work on engines, transmissions, plug-in vehicle powertrains, steering, brakes, batteries, automation - just about everything you could name. That diversity of projects is always fun to work on, for me and for all our engineers. It’s rewarding, not only because it is diverse and interesting, but also because we believe we’re help design safety into our products, even if those products vary quite a bit technically from each other.
I started in this industry almost 18 years ago. And I still look at cars and trucks I’ve worked to develop and say, yeah, I designed a small part of that car, or made it better or helped to make it safe. I think all engineers love to see their products and ideas on the road. That’s a shared theme at our company. Probably there’s a little bit of that in every automotive engineer.
Thanks so much for sharing your expertise.