Growing Complexity Adds To Auto IC Safety Challenges

The automotive industry is working to streamline, automate and tame verification of automotive electronic control units, SoCs and other chips used in vehicles, many of which are becoming so complex and intertwined that progress is getting bogged down.

Modern cars may have up to 100 ECUs, which control such vehicle functions as engine, powertrain, transmission, brakes, suspension, entertainment system, sensor systems and more. The ISO 26262 standard addresses the safety and reliability of these electronic systems, relying on the Automotive Safety Integrity Levels (ASILs) to determine risk classes for different ECUs in the vehicle. Those ASIL classifications range from A to D (least to most demanding), each with different constraints and requirements for the ECUs.

From an implementation standpoint, building ECUs to be ASIL-compliant requires the addition of verification hardware and safety mechanisms such as redundancy of critical components, error correction codes, built-in self-test (BiST), system watchdogs, or cyclic-redundancy checks. Today, verifying ECUs as ASIL-compliant is a rigorous and time intensive process.

“Automotive cybersecurity adds another set of constraints to verification,” said Thierry Kouthon, technical product manager for Rambus Security. “All safety-critical systems are security-critical because a successful cyberattack on a safety-critical system could lead to human endangerment.”

Standards such as SAE J3061 and ISO/SAE 21434 address automotive cybersecurity, which in automotive involves potential threats rather than known hazards. “This dramatically increases the scale, complexity and time of the verification effort that must be performed within the constraints imposed by automotive production calendars,” Kouthon said.

Much of this is brand new for the auto industry “Digitalization and connectivity in automobiles is on the rise, and this is fueled by megatrends such as automated driving, in-car connectivity, and shared mobility,” said Sandeep Krishnegowda, senior director of marketing and applications, memory solutions, at Infineon. “The increased levels of connectivity come with significant cybersecurity risks, as access to electronic systems and data, vehicle safety and consumer privacy needs to be protected. Safety and security become fundamental requirements in automotive systems to guarantee trust and dependability of in-vehicle electronics. Vehicle manufacturers around the world will need to obtain cybersecurity approvals to register their vehicles with the relevant authorities. Traditionally, safety and security requirements have been managed by car manufacturers and system providers. However, with the increasing complexity of electronics involved, the responsibility of addressing safety and security is now propagating through the supply chain to semiconductor companies, and that includes memory devices.”

Fig. 1: New concept for automotive ECU design, security and safety. Source: Mentor, a Siemens Business

This is easier said than done. For one thing, designs and algorithms used in automotive applications are in an almost constant state of flux, which is why many of them have some level of programmability built in.

“A lot of designs in automotive are highly configurable, and they’re configurable even on the fly based on the data they’re getting from sensors,” said Simon Rance, head of marketing at ClioSoft. “The data is going from those sensors back to processors. The sheer amount of data that’s running from the vehicle to the data center and back to the vehicle – all of that has to be traced. If something goes wrong, they’ve got to trace it and figure out what the root cause is. That’s where there’s a need to be filled.”

In addition, many of these devices are expected to function perfectly for a decade or more.

“The only way this works is with a continuous verification methodology,” said John Hallman, product manager for trust and security at OneSpin Solutions. “You need to set up a verification suite at the chip level, and when the design changes, you adapt to the update. You also need to maintain the environment against changing security vulnerabilities, which might be a model of a fault from a vulnerability in another car. But in all cases, you need the ability to make changes.”

Some of that can be offline, such as a digital twin, Hallman said. But regardless of where that model resides, it needs to be flexible and consistently checking for problems.

Exactly how engineering teams should think about verifying safety and security really depends on the scope of the project. “Starting with the easiest step, which is IVI cluster consolidation, it’s quite straightforward because there is a limited feature set to verify and to qualify for that,” said Michael Ziganek, general manager of the Automotive Business Unit at Mentor, a Siemens Business. “But in autonomous driving systems going forward, the industry is still struggling — especially at Level 4 and Level 5, where the right approach has not been found yet.”

Another consideration is that the legal system for every country is unprepared for autonomous and semi-autonomous driving. “In the end, the OEM needs to take over liability, and they have to make sure that nobody is actually in danger,” Zikganek said. “If a car crashes, whose fault is it? Two or three years ago, the industry thought this was solved. But if you watch what’s been happening lately, everyone has pushed back saying, ‘Not so fast. Let’s go to Level 3 autonomous and concentrate on features such as highway assist, and parking assist. Everything else is really difficult.’ The verification for a current ADAS system is quite straightforward, with the usual verification methods, and everything else is an exception. If an exception is there, the system is turned off. But you can’t do that with Level 4 and Level 5.”

One of the big challenges has been shifting the mindset in the automotive world. Automotive companies need to start thinking like electronic systems companies, from the system-level down as well as from the chip-level up.

“What’s interesting in automotive today is to see the evolution of what needs to be developed, and what needs to be verified,” said Marc Serughetti, senior director, product marketing and business development at Synopsys. “Several years ago, people were looking at functionality and how to do functional verification of the design, and we know that over the past four or five years safety has become the big thing. ISO 26262 is driving a lot of technology development in this area. And then, because it’s electronic, because it’s computing, because it’s open to the network and all sorts of things, security is the thing that’s coming together. You can’t really detach safety and security. They are tied together.”

But that also requires a new way of looking at problems. What works in verification debug can cause problems for security, said Frank Schirrmeister, senior group director of solutions marketing at Cadence. “If you leave the debug channel open, you’re in trouble. You have to isolate things, and then selectively get rid of them for security reasons.”

The good and bad of standards
How much of all this can be standardized remains to be seen. Safety and security are required, but it’s more difficult to design those into systems because the systems themselves are in an almost constant state of change. That makes it much harder to define standards, particularly since many of them are dependent on the interactions of multiple systems.

“Standardizing security is a little tricky because what a lot of people do is look at a class of threats, such as those in the Federal Information Processing standard for cryptographic devices, which apply to the smart chips in credit cards,” said Jason Oberg, CEO of Tortuga Logic. “There are certain standards, but they’re more about protecting certain classes of threats that are defined by that market. Security, in general, is hard to standardize. It’s more about a process. On the automotive side, it’s really important is to go through a process of looking at where the chip is going to be, because that will dictate what attack vectors are viable and what the impact may be. It’s important that a process is put in place with a kind of threat model saying, ‘If I’m building this MCU that’s going to go in the autopilot system, or maybe a high-performance core that’s going to go in the ADAS system, there’s a process to examine what would an attacker try to compromise, and what capabilities do they have.’ Is this something connected to the network, or is this something that’s boxed in an enclosure? Going through that whole process is important. From there you get your core business and security requirements, and then you can drive that as part of your verification plan.”

While this process is well-established for software, it is just beginning to shift to the hardware domain.

“A lot of the larger semiconductor companies are starting to do these things, and it’s very different than functional safety, which is about making sure that you’re fault-tolerant,” Oberg said. “If you have a bit flip, your system still works correctly. ISO 26262 has requirements on how you do that, and so on, but from a security standpoint it’s different because you could have no bit flips, but then someone extracts firmware from the device, finds a vulnerability that maybe is replicated across all devices or all cars using this chip, and then it’s a huge mess. It has to be viewed as a process and less around covering only specific threats, which is typically what the standards do.”

Understanding where an organization stands in terms of security maturity is a first step when helping companies in the automotive ecosystem implement a methodology to verify hardware for security and safety, said Marc Witteman CEO of Riscure. “What kind of people do they have? How are these people trained? What is their experience? This gives us an impression on where they stand in security maturity.”

From there a gap analysis can be done to determine what level they want to reach, and a training program can be implemented to bring them to that level, followed by certification. But the key is to think about security at a system level, and potentially a system-of-systems level.

“Security is about the entire system,” Oberg stressed. “It all goes back this process of threat modeling — figuring what the impact would be. If you’re completely vertically integrated like Tesla, which builds their own silicon, they have a lot more visibility on the end system and where that system is going to go. If it’s a little more fragmented and you’re buying a commercial off-the-shelf piece of silicon to build this other system, it’s very hard. Security’s not composable. It’s very hard to build a process around that kind of infrastructure. Companies like Apple and Tesla have the same type of model, and we’re seeing that becoming a lot more common across a lot of the tech companies — building a lot of their foundational roots of trust in silicon, because they get a lot more visibility into the system security by doing so.”

But even for fragmented approaches, there are ways of building that process. “You can still talk to your customers to understand as the product lead, ‘Where is this going to go, and what you are concerned about from a security perspective?’ You can take that back to the development teams and make sure that process is being built. It’s just a lot easier to go to the cubicle right around the corner to talk to the people who are building the chip.”

Safety and security can follow the same type of development approaches as the rest of a design.

“In safety you look at failure modes, and how to have safety mechanisms for those failure modes,” Synopsys’ Serughetti said. “Then you go through the design to the verification, all of the traditional activities, and security is parallel to this. You have to look at potential vulnerabilities, and you have to think, from the start, where the design is going to be vulnerable. What do I need to do to protect against this? How do I go about verifying? The two tie together from a high-level perspective on our side, and those are parallel flows in the design that are interconnected from a technology standpoint. There’s a lot of commonality between the two. On the verification side, for example, we talk about fault injection, fault campaigns, when we do safety. But on some aspect this concept of fault campaign applies for security, as well. You’re looking at injecting faults to see how you respond from a security perspective. We all know that security comes from multiple places — from the software, from the hardware, and we also know it’s possible to look at the thermal signature of a chip to try to figure out how that chip behaves.”

From an implementation perspective, there also are parallels between functional safety and security.

“On the functional safety side you might have a dual-core lockstep redundant system, and you need to make sure those systems are separated physically, where the standard cells are placed and legalized appropriately,” said Stewart Williams, senior automotive vertical marketing manager at Synopsys. “The routing needs to be managed in a certain way so that routing from one core doesn’t overlap another core. There may be other requirements as well. From a security perspective there can be those kinds of requirements too. There are placement considerations, there are routing considerations. So in a similar way, these technologies that are developed for functional safety from an implementation perspective can have application in the security world, as well.”

Again, where the chip is in the actual car will dictate what threats are relevant and the common weaknesses, Oberg said. “If you look at an ADAS system, the impact of something misbehaving is very high. If it’s in another less-critical system, such as the way the AC is controlled, there’s less of a business impact of a problem. It’s less significant than if it’s an ADAS system or an ECU controlling the brakes, and that has to be taken into account. It’s hard to say, for every chip in the car, these are the threats. There is probably a subset where that is true, but in general you have to look at, ‘If I’m selling an ADAS system, this is what I need to be doing. If I’m selling into the braking ECU, or I’m in the infotainment system, the process is still the same.’ But the weaknesses that are relevant, and the relevant threats, are going to vary based on where that is going. That’s part of the reason it’s complicated. There is so much fragmentation around that.”

Still, designing in safety and security is like selling insurance.

“If you don’t have it, you may grow to regret it,” Schirrmeister said. “Like verification in general, it’s an assurance for having done certain things. There are certain areas, like in medical and defense, where you almost don’t want to take the call from somebody who might tell you something because once you know about it, now you have to implement it. It’s a fascinating business from a verification perspective, but as a designer you have to be very careful. That’s where standardization can be important — to separate the scary things that might happen from the ones most that are the most relevant and that happen most often. There’s no shortage of recent failures to point to in order to create this scared state. Then it’s up to the user, who has to be very level-headed to decide which items items are really pushing the needle.”

Conclusion
Numerous pressures to figure all of these interactions between security and safety, design and verification requires automotive OEMs to break down silos within their organizations. According to all accounts, OEMs have realized they must bring together teams to improve communication and co-design and verify hardware, software and the system. That is the only way to cost-effectively manage the complexity of autonomous vehicle development. The good news is this also opens up new opportunities across the automotive ecosystem to support all of that work with consulting services, tools and methodologies.

— Ed Sperling contributed to this report.

Related
Are Today’s MEMS Gyros “Good Enough”?
Big improvements in precision may require new applications and market dynamics.
Sensor Fusion Challenges In Cars
As more pieces of the autonomous vehicle puzzle come into view, the enormity of the challenge grows.
Who Owns A Car’s Chip Architecture
Carmakers and their suppliers compete for dominance, creating challenges across the electronics industry.
Formal Verification Becoming Critical To Auto Security, Safety
Obstacles remain, but adoption is growing.