Semiconductor companies have to contend with more than technology when it comes to the automotive market.
Self-driving cars are drawing semiconductor companies into legal and regulatory issues for the first time, adding a new level of scrutiny on cutting-edge chip technology.
It also opens up a whole new field for legal interpretation, case law, and regulation. While most liability cases in the past never crossed below the system vendor/supplier level, that could change with autonomous vehicles.
“In the technology industry people are always talking about paradigm changes and disruptive technologies — and this is disruptive in the sense that it really will change how people deal with transportation in many ways,” said Hilary Rowen, an insurance regulatory lawyer at Sedgwick LLP in San Francisco. “But it’s also disruptive for established auto safety and insurance regulatory systems. When you have something that is completely new, such as in the area of cyber security and privacy — you end up with situations where the old mechanisms for making sure that bad things don’t happen don’t work anymore and you have to come up with a new set of guardrails, and a new set of protections. The new protections may or may not be effective at first, but the whole idea is that you suddenly need a new set of rules because the old rules don’t work anymore because they simply weren’t designed for the situation that is now emerging. Self-driving cars challenge established driving safety regulatory mechanisms in much the same way that the Internet has created new privacy and data security issues that have triggered a great deal on discussion regarding the need for new rules and protections.”
This leads to the discussion of how self-driving cars will impact insurance. “When a fully self-driving car gets into an accident it is presumably going to be a either some combination of software and sensors screw up or it will just be one of those unavoidable things, like hitting black ice. When there is an accident, there will be a strong propensity to sue the auto manufacturer or the software developer – if the software developer is not the auto manufacturer – or potentially even to sue the sensor or chip developers. To the extent that these are dedicated-purpose chips such that much of the software is built into the chip design, potentially even chip developers could be found by a court to have contributed to the cause of accidents although they are a little more remote from the causation stream than the auto manufacturer. Auto accident claims for self-driving cars will start moving it out from under the private passenger auto policy, and the relatively low applicable insurance coverage limits under personal auto policies onto a product liability policy which usually has much higher coverage limits. This means there is an economic incentive to sue the auto manufacturer, the software developers, the sensor designers and the chip designers from the point of view of the injured party. In addition, if you’re in a vehicle that has driver controls, insurers and courts will need to address whether a given accident was caused by a failure of the self-driving car technology or was the result of the driver over-riding the self-driving systems,” she explained.
For these reasons, Rowen predicts there will be an increase in the number of technology ethicists who are dealing with effectively the “fat man and the trolley” problem. “If you could throw the fat man on the trolley that’s running amok down the track and save 20 schoolchildren, is it ethical to do that—to intentionally kill one person to save 20?”
The first widely reported self-driving car accident involved a Google car. That occurred at processing speeds similar to a human driver, but those speeds will improve as technology improves. The standards for software will likely be set differently. If there is enough data, what decision should be made to minimize damage?
These issues, in turn, play into the whole question of how do we insure and allocate those costs. “Yes we will have software and chip designers that are going to have to testify in class action lawsuits on what were the decisions that were made for dealing with different accident scenarios. It will be chip forensics in the sense that if the decision paradigm that becomes an issue was built into the chip, and not just a matter of the programming, a major issue in the lawsuit will be ‘Did this pattern of accidents occur because of a particular chip design?’ ‘Why did the software/the control system make the decision it did?’ ‘Did it arise out of the software or the chip design?’ and then, ‘was it optimal?’ From the point of view of the chip designers, they are moving into an environment in which there actually is an interaction between insurance and what they are doing in the sense that insurance and the whole tort system are a major part of how the costs of given activities are allocated in society,” she added.
Benjamin Lee, marketing director at Applied Materials, confirmed that chip forensics are becoming more common. “A recent agenda item with one of our customers from Europe was related to failed car module that occurred at the chip level. It took more than a year for them to complete the analysis and get down to the chip level. Finally, they narrowed it down to a single semiconductor equipment process step. It was very specific.”
This is exactly the kind of analysis that an insurance company or a judge may require to resolve issues in automotive-related cases. Preparing for what is sure to be a gargantuan market opportunity, even Applied Materials has been analyzing the market to understand where it is going, how it is growing, and at the device level, which segments are growing faster than others and have more technology inflections, Lee said.
The opportunity for Applied Materials is on the materials engineering and product development side, which requires more R&D. “ On the technical side, we’ll help analyze the problem and find ways to mitigate or resolve it through either process recipe or hardware changes,” Lee said. “Close collaboration with our customers these days is critical to ensuring everyone’s success. We need to engage early in the development cycle. Both sides benefit as this provides a head start in the product cycle. In our 200mm equipment product group, customers have come to us for product development to handle new materials such as SiC and GaN, wide band gap materials used in next generation Power Devices. SiC is a big thing that’s coming up for automotive. The inverters and power management systems in cars need to be more efficient and fast. We are engaged with some key customers who are developing and piloting these new materials.”
Challenges of advanced technologies
The emergence of advanced driver assistance systems (ADAS) and ultimately autonomous vehicle technology represents both a huge opportunity and great challenge for car companies and the automotive supply chain.
“The opportunity is clear – safer cars that completely transform the driving experience hold the promise for more product uniqueness and bigger revenue for the winners,” said , CTO of the IP Group at Cadence. “The challenges are a bit daunting, though. The car makers need to figure out how far they can push the technology envelope by bringing in significant new electronics hardware and millions of lines of code. At the same time, they must meet high but still ill-defined standards for safety, reliability and competitive differentiation. This step-function increase in electronics sophistication is percolating through the automotive supply chain, with major integrators and their traditional semiconductor suppliers working hard to figure out new techniques in computer vision, radar, LiDAR, convolutional neural networks, ISO 26262 functional safety, user interfaces and large-scale software system reliability, security and maintainability.”
The upside is this creates openings for new players to enter at every layer, both for conventional suppliers such as chipmakers and for new providers that offer specialized IP, verification methods, safety and security certification, software building blocks, and integration services,” he observed.
“In many ways, this looks like the smart phone revolution, in terms of the rapid increase in sophistication of an everyday object we thought we understood,” he said. “The superficial pace may look a little slower, given the longer design cycles needed in automotive, but the magnitude of the challenge may actually be greater. Imagine the smart-phone revolution, but with a requirement that phones last for 15 years and never ever have a software bug in an app, or ever drain the battery faster than expected. And all this change is likely to touch the technical community directly. We can reasonably expect to see overall demand for technical-savvy silicon and embedded software, with particular emphasis on relative sensing and recognition (vision, radar) plus highly secure and reliable decision-making subsystems. Autonomous driving technology is also likely to leverage and pull in expertise from wireless communications, including low-latency vehicle-to-everything links and real-time mapping and localization. Even psychology and physiology skills for human driver behavior prediction and user interface design will be at a premium for some systems.”
Marc Serughetti, director of business development for system level solutions at Synopsys, agreed that the automotive industry is going through significant changes. “The landscape, ranging from business models, industry players, applications and many more perspectives is changing rapidly. Software is at the core of these changes. A recent presentation from BMW, a 100-year-old automotive OEM, indicates their plans for half of their R&D staff to be computer programmers, competing with companies such as Google to build autonomous vehicles.”
However, he said a consequence of these changes is that automotive companies from semiconductor companies to Tier 1 suppliers and OEMs are aggressively upgrading their software and system development capabilities, not only with resources but also from a process and tooling perspective.
“These companies need to start development and test earlier, and are deploying new tools and methods that help to achieve this, which also enable more collaborative development along the supply chain,” Serughetti said. “The use of virtual hardware ECUs is an example technology that supports software development in the context of the hardware and the ECU environment. Using virtual ECUs enables early system software development, system integration using virtual Hardware-in-the-Loop, system fault testing in support of ISO 26262, and automated test regression.”
Last but not least — security
The final piece in this puzzle is security, and self-driving cars pose a huge concern given the amount of silicon and software and the size and mass of vehicles.
“The Internet revolution improved many aspects of our lives and boosted the world’s economy, but also introduced new threats and concepts such as cyber-crime and cyber-warfare,” said Asaf Ashkenazi, senior director of product management at Rambus Cryptography Research. “Self-driving cars are no different. There is no doubt that by the time self-driving cars roam our streets they will be fully connected, raising concerns about ensuring the integrity of the software, and ensuring it is not maliciously replaced by a rogue version that could bring harm to the passengers or bystanders. This is only one of many concerns that will need to be addressed by self-driving car manufacturers, operators and regulators.”
This is a risk-reward analysis, and self-driving cars will reduce accidents, traffic congestion and cost, said Ashkenazi. “We may also see some existing transportation-related businesses become redundant, and new businesses emerge to provide new services enabled by new technology.”
Security makes that equation more palatable, though, and done right it has to be designed with the car, not as an afterthought.
“Software security is necessary but insufficient to fully protect the self-driving car,” said Jonathan Valamehr, chief operating officer of Tortuga Logic. “Many vulnerabilities have been demonstrated where software security has failed, and SoC designers now understand that silicon security is no longer an option. An emerging trend called design-for-security (DFS) addresses these issues earlier in the design process. SoC design teams are re-organizing their groups to accommodate DFS by eliminating specialized security teams that operate outside the RTL design flow. By adopting DFS as part of the RTL design flow, an entire team addresses security instead of just one or two specialists, providing a predictable solution to manage security in automobiles.”
All of this is likely to drive some interesting discussions throughout the automotive ecosystem over the next decade.
“It’s a fascinating time when a whole industry, which has been widely perceived as a relatively late adopter of new electronics technologies, suddenly jumps into a leading position driven by the awareness of world-changing economic and technical potential,” Cadence’s Rowen said.
Related Stories
Autonomous Vehicle Disruptions Ahead
When self-driving cars actually reach the market is still not clear, but the automotive ecosystem is preparing for huge changes.
The Race To Secure The Car
Connectivity and complexity are raising concerns about safety and reliability.
Enabling Self-Driving Cars
What’s missing from the engineering ecosystem
Awesome article!
I’ve done some expert witnessing for automotive ECUs and other tech-liability claims. Lawsuits that trace the liability far down the chain have actually existed for awhile; companies like Exponent (Menlo Park) hire hundreds of masters and doctoral researchers in STEM to analyze legal liability claims involving STEM (e.g., pipes commonly break from natural occurrences like negligent site-specific erosion which, in turn, can cause catastrophic damage if its the wrong pipe or maybe a washing-machine’s timing unit deadlocked and didn’t turn off when filling, flooding an apartment while a tenant is at work). Unfortunately, most of the lawsuits are pretty grisly: manufacturing machines overriding safeties and physically mutilating workers, medical devices malfunctioning and crippling people, etc. I think there’s definitely a HW-SW engineering process that can provide reliable computing when physical safety is required, but it hasn’t really been an area of research outside of niche industries (e.g., NASA, the military, etc).