Automotive Outlook: 2022

Short-term IC supply-chain problems and long-term architectural and business changes top the list of what’s ahead.


The auto industry is widening its focus this year, migrating to new architectures that embrace better security, faster data movement, and eventually more manageable costs.

The auto industry is facing both short-term and long-term challenges. In the short term, the chip shortage continues to top the list of concerns for the world’s automakers. That shortage has delayed new vehicle deliveries, interrupted repairs of existing vehicles, and it is expected to continue throttling industry growth until it is resolved. Manufacturing capacity is being added, and the supply chain issues are getting addressed, but it will take time before supply and demand balance out.

“A major issue for automotive overall in 2021 was the supply chain shortage, which is expected to continue into 2022,” said Robert Schweiger, director of automotive solutions at Cadence. “Because of that, various companies started to look into alternative ways to address this, eventually developing their own chips and eventually doing strategic partnerships with foundries.”

A prominent example is the partnership between Ford and GlobalFoundries. “It still remains to be seen what it means for 2022, but this shows the supply chain shortage has had a certain impact on decisions, on partnerships, on the strategy of automotive companies going forward,” Schweiger said.

Those shortages have put the spotlight on both parts sourcing and engineering talent, which are leading to longer-term and more fundamental changes. “OEMs and Tier 1s will increase their in-house engineering expertise for both hardware and software,” said Walter Wottreng, vice president of the Automotive Group at Synopsys. “Engineers will roll out flexible e/e architectures so they can quickly rewrite software and integrate alternative chips as the supply chain dictates. In addition, adding in-house expertise will help OEMs deal with the compression of the supply chain, as they will have more visibility into availability and direct relationships with semiconductor suppliers.”

In effect, carmakers and Tier 1s are raising the level of abstraction for how they approach shortages, allowing them some room to maneuver by developing their own software. “As a lesson-learned from the ongoing chip shortage, semiconductor vendors are becoming more active in the software space in order to make it easier for carmakers to adapt their latest silicon designs,” said Artur Seidel, Elektrobit’s vice president for the Americas. “They’re offering their silicon with dedicated software. This coupling includes safety/security components, so it’s a win-win for the customer. A couple of examples are Qualcomm’s acquisition of Veoneer, and Renesas offering a gateway solution, including software packages.”

Alongside of all of this, a flurry of deal-making is also underway, reflecting new developments and changes across the automotive sector. “In 2022, we see the automotive industry pushing towards an even more collaborative relationship between ecosystem partners including semiconductor suppliers, subsystem providers and OEMs,” said Lars Ullrich, vice president of automotive for the Americas at Infineon Technology. “We see a continued strong demand for automotive semiconductors in 2022 with a global push towards digitalization and electrification in tomorrow’s vehicle.”

What’s changing
One of the big changes is the focus on security — particularly software security — due to increased connectivity (V2X) and software-heavy systems for highly autonomous driving (HAD), Wottreng said.

Others point to similar shifts. Lee Harrison, automotive IC test solutions manager at Siemens EDA, pointed to multilayer security and device reliability as one of the biggest challenges for automotive ICs.

“Security is starting to garner huge attention. There is a lot of research, and investment to try and understand what is needed. Also, reliability and data collection are critical with new advanced ADAS systems, which make use of the latest technology nodes, for which there is no historical reliability data available,” Harrison said. “Designs for automotive applications require security to ensure sensitive data is inaccessible to outside agents. This used to be a somewhat niche requirement, and the implementation of custom solutions to meet these specific requirements was common. However, with the explosion within the semiconductor industry of automotive and cyber-physical systems in recent years, the requirements around secure test and monitoring have become mainstream. Chipmakers now need to extend security technology across several different levels of SoC development to provide the best coverage in a defense-in-depth solution.”

Others agree. “Although everybody says security is never a primary business driver, security is always a secondary business driver,” said Andreas Kuehlmann, CEO of Tortuga Logic. “The primary drivers are more things like safety in automotive, while in medical devices it’s privacy and medical history. And when we talk about compliance in regulated industries, security is always a foundational piece that is required for any one of these primary business objectives. For the automotive industry, the big wake-up call was the Jeep Cherokee incident, when Charlie Miller and Chris Valasek demonstrated you can run the vehicle into a ditch. They may not have been the first to hack into a car, but they were the first to make a movie out of it.”

Kuehlmann said that was a wake-up call for the entire automotive industry, and a positive development. “They realized security is not only a safety matter. Unlike general reliability of cars, security is like an on/off switch. If you have a bad mechanical part, where bad typically means there’s some distribution, a fraction of them are bad but the majority are good, and that fraction shifts over time. The automotive industry is actually extremely good in measuring and monitoring that, and doing recalls. If you get above a certain threshold of bad parts, if it’s the airbag or another aspect of the vehicle, the automotive OEM does a massive recall, and that’s a purely economic decision,” he said.

Cybersecurity changes that equation. “If a particular model of a car is vulnerable, all cars on the road are vulnerable, meaning you can hack all cars at the same time,” Kuehlmann said. “That’s completely new, and it’s not only in automotive. That’s why boardrooms have difficulty getting their arms around what cybersecurity means. The traditional risk management tools don’t directly apply. You can be as preventive as you want, but if someone publishes how to hack car XYZ, and it’s published on the internet, all cars are suddenly vulnerable. With the flip of a switch, you can automate it, and that is something very fundamental. It’s also something the automotive industry understands.”

Automotive economics 2.0
A key way the auto industry addresses these kinds of issues is through standards, which in the past have proved effective in controlling costs throughout the ecosystem. This is especially true with zonal controllers, which are on the drawing boards at many carmakers, including some using leading-edge process nodes.

“The cost of developing zonal controllers at very advanced nodes will be high,” said Cadence’s Schweiger. “And for high cost, you need high volume to share the cost among many companies. That means eventually a certain company will develop the controller, but it will be available to their competitors, to the whole industry in order to get the volume up. What I’ve observed in automotive — for example, with AUTOSAR — is there were early adopters that had the idea about AUTOSAR as an automotive operating system, and they were starting to come up with their own proposals. Then they tried to bring additional automotive companies together to form a consortium to eventually jointly develop a new kind of standard, an open standard like we have today. Today, hundreds of companies are part of the AUTOSAR organization. Automotive is all about open standards, not proprietary solutions. That’s why with zonal controllers and zonal architectures, we again may see that a few companies will take the bumpy road, try to come up with their own solution, which later on becomes a standard that is open to many companies in order to address the cost issue.”

This applies to the economics of security, as well. “Particularly as we talk about cars being connected for over-the-air updates, vehicle-to-vehicle communication, vehicle-to-infrastructure (V2I) communication, all of this dramatically increases the importance of cybersecurity,” Kuehlmann said. “Without precautions, without building security into the product — and not only into the product, but into the entire infrastructure — we’ll have massive problems. Security is part of the reason why autonomous development has slowed a bit. The challenges within automotive cybersecurity are extraordinary, and they’re different than what we used to know.”

Understanding this, and planning for it, are two different things, though. Securing a car requires layers of security that are built into the initial architecture, but with enough flexibility to adjust to new threats as they become known. In the case of a car, which could be on the road for a couple decades, resilience is critical.

This is at the heart of a concept called “defense in depth.” It involves a range of technologies that can be implemented at different levels of the design to build rings of defense, using relatively simple concepts to introduce many levels of protection for a device, as well as providing a significant defense against malicious attacks, according to Siemens’ Harrison.

Some of these concepts are passive, providing a lock against access, while other technologies are reactive in that they can take evasive action when a threat is detected. This may be as simple as resetting the device if a BiST controller is configured into an unexpected mode, or blocking an illegal bus transaction based on data gathered by a bus sentry analytics monitor.

Fig. 1: Defense in depth model. Source: Siemens EDA

The use of embedded analytics technology increasingly is relied upon as an on-chip analytics engine, part of a device safety island used to monitor critical activities within a vehicle. “If any of these operations appear to be abnormal, or are not regular operations, they are monitored and flagged by the embedded analytics monitoring technology. An extreme example would be for the vehicles infotainment system sending communications data to critical vehicle functions, such as brakes and steering. In normal operation this would never happen, so it can be classed as an illegal operation, and thus can be detected and blocked,” Harrison explained.

Fig. 2: An embedded in-system configuration. Source: Siemens EDA

In the past, simple solutions to secure the external interface included not bonding the JTAG pins in the production package, or disconnecting the TAP using some form of one-time programmable (OTP) fuse. However, with the increasing need for connectivity to monitor in-use data, access to the internal test network — either externally or through an embedded safety island — is now a must-have for automotive SoCs.

“With any solution, it is also possible to implement a number of layers of security, so that different keys can unlock the device to specified levels, granting different access rights for different applications or users. This approach is used extensively in the automotive ecosystem, where different levels of access are given depending on the device location,” Harrison said.

Additionally, given the rapid advancements in automotive ADAS development, the automotive ecosystem is now developing chips at the most advanced process nodes, for which there is little historical data. “Without that data, automotive chip suppliers are having to build those reliability models on the fly by collecting a huge amount of on-chip data from devices as they are shipped and go into service in the field. There are many new and old technologies now being used to collect on-chip data,” he added.

More data, more complexity
As vehicles become increasingly autonomous, the amount of sensor data that needs to be processed increases significantly. The question now is how much is done by zonal controllers and how much is done through a sensor fusion system. Either way, the amount of data that needs to be moved is increasing.

“You need a 10-gigabit or higher link,” said Cadence’s Schweiger. “That’s the next big thing that needs to go into a car.”

Regardless of where it is processed, though, the chips doing the processing are becoming more complex. There are more types of processing elements, including accelerators that can speed up object detection and classification.

“This is part of the ADAS systems, in addition to mapping and other functions,” said Kurt Shuler, vice president of marketing at Arteris IP. “Here, initially it was algorithms and AI or machine learning on visual inputs. Then, lidar and radar data was added to that in a sensor fusion function. That is then overlaid with mapping. This means even more hardware architectures are driven by the needs of the software.”

Mobileye was a pioneer in this approach to software, but other companies are taking this approach now, as well.

“What that means is that architects have a huge challenge of just getting the data from one part of the chip to the other part of the chip,” Shuler said. “The quality of service, tweaking that network-on-chip topology and the logic in it that does the prioritization, and the ordering of the data — that’s a huge challenge.”

Synopsys’ Wottreng suggested this will lead to the creation of software ecosystems, which in turn will shift left in the design cycle to reduce design and verification time, while also driving growth of digital twins. All of this is necessary to reach the next step in autonomous vehicles, but many barriers remain.

“Fully self-driving cars may be a little way off, but increased levels of assistance coupled with applications that have restricted operational design domains see us making real progress,” said Dipti Vachani, senior vice president and general manager of Arm’s Automotive and IoT line of business, in a recent report. “To enable this new range of capabilities, vehicle electric architecture will undergo challenging evolutions as disparate ECUs are merged into domain controllers. A digital twin is a ‘live’ digital recreation of these domain controllers within an individual car on the road. This enables developers to test out ADAS, autonomous, and other future software workloads. The importance of this to the industry really seems to be a question of differing mindsets. To a hardware or a software developer right now it’s a tool to help them get their job done and perhaps identify flaws and bugs. To an executive, though, it’s the pathway to new revenue streams — real-time and continuous diagnostics, predictive maintenance, and so on. Two-thirds of software developers recognize the profound impact that the software-defined vehicle (SDV) will have on their work and the industry as a whole. What’s perhaps less evident at this stage is how important digital twins will be in enabling developers to deploy solutions faster.”

Schweiger said the automotive industry, and in particular, the OEMs and Tier 1s, still need to find their role in the development of complex chips so that eventually an OEM could develop its own SoCs for autonomous driving. “This is complex because a lot of the functionality gets integrated into the SoC, and those complex SoCs are running a very complex software stack, as well. What role will an OEM play in this setup? What role will the Tier 1 play? What is the role of semiconductor vendors who also moved up the supply chain in providing complete driving systems already, such as Nvidia? Can we expect a commercial solution, as we are used to from a semiconductor vendor, or will the industry or certain OEMs also create certain partnerships and they do their own thing?”

Cost is another factor with autonomous driving, because these complex compute platforms required are very expensive to develop, he noted. “What we will see in the beginning of fully autonomous vehicles are commercial vehicles, robotaxis, trucks, trains, and eventually our own autonomous vehicle or at least in a shared model. For private use, the cost of this system needs to go down. The huge sensor stack and very complex compute platforms cost a lot of money, so the cost needs to come down.

Elektrobit’s Seidel suggested automotive vehicles at scale will require high-performance-compute (HPC) vehicle architectures at high volume, but at price levels that are acceptable. “While a lot of progress is being made, we are still in a transition phase with many carmakers rolling out the next generation of advanced architectures, like zonal architectures, around 2024. This means a lot of the platforms currently on the road are not yet advanced to a point where they can enable the connected compute and seamless OTA that autonomous vehicles will require. We work with carmakers, Tier 1 suppliers, and chipmakers, to make sure that many of the software building blocks that bring these architectures to life (aka Automotive OS) are available.”

Testing and validation needs to continue to be refined as well. “There must be a firm legal and regulatory framework for autonomy,” Seidel said. “This is where the industry needs to do a lot more work. There are many parallel and competing developments happening when it comes to autonomous driving. On one hand, this is normal for a new industry, where the stakes are this high, and there is a window of opportunity for the first company to crack the problem. On the other hand, autonomous vehicles are extremely safety-relevant, which means that due diligence is as important as speed. Therefore, we need to see more collaboration in addition to competition. It seems there are more companies developing self-driving stacks in parallel, with no interchangeability, than there are carmakers. Acceptance will require an exchange of best practices and data. A key limitation to progress is that there are not enough resources for every carmaker to develop the required platforms and software stacks in parallel. We need a model where systems are modular and interchangeable, and where there is more sharing of resources among all players.”

Thierry Kouthon, technical product manager at Rambus noted a unique dynamic among automotive manufacturers on the two camps of networking architectures leveraged to connect the vehicle’s sensory systems with the ADAS and processing. “Many modern automakers, such as Tesla and Waymo, tend to favor centralized processing since it allows for more seamless iteration and easier software updates. On the flip side, more traditional automakers are still opting for zonal architectures that are more flexible, and suited for working with legacy designs, broader product portfolios and third-party component manufacturers. Both groups are also contending with the growing security concerns. Centralized processing environments make software security updates easier, but also means that a hardware compromise could be catastrophic in allowing access to a majority of the control systems. And zonal environments need to contend with securing the hardware and software of each specific zonal gateway. The risk of compromise is lowered, but the system security needs to be more widespread across the entire vehicle. Zonal architecture adds a level of complexity to vehicle security as each zone deals with sensors and ECUs that belong to different security domains, such as drive-train, vehicle comfort, or engine control — that need to be kept isolated by software means.”

An interesting challenge starting to arise for these auto OEMs, especially for Tesla and Waymo, in the wiring itself. “The amount and proliferation of sensors and systems across semi-autonomous vehicles make wiring one of the heaviest subsystems. This issue is compounded for electric vehicles which need to shed excess weight, due to balancing out the increased weight of the car’s battery. Hence many automakers are exploring new technologies, including MIPI Controllers, to try and limit the wiring needed. Zonal architectures, inherently address the wiring problem by keeping gateways for each vehicle zone close to the ECUs and sensors they control, while the gateways communicate with one another via a backbone network,” Kouthon said.

This sharing of resources is something the automotive ecosystem is adept at doing, and in 2022, standards work will push ahead. The ISO 26262 working group will meet again this year to discuss what’s next for Edition 3, which follows Edition 1 from 2011, and Edition 2 in 2018.

In addition, Shuler noted that the IEEE 2851 provisional working group is collaborating with Accellera on data standards to automate and share data in line with FMEDA (Failure Modes Effects, Diagnostics Analysis). “The whole point there is to make it easier for people in the value chain to be able to share data between tools, because right now if you’re a Bosch or a Continental or a Denso or an OEM — and getting functional safety information and FMEDA files from various sources, and you need to do analysis for your overall system — it’s really hard to pull that data together to analyze it. The various sources of data may all be different. Imagine the spec doesn’t specify what your failure mode distribution spreadsheet needs to look like, how to do the calculations, and how to go back and trace. You might have some numbers in a table, but where did they actually come from? How are they actually calculated? The work being done by Accellera and IEEE P2851 will make that easier. Then you should be able to share the data, understand how the data was calculated, and back up and see how it makes sense. You can’t do that with a spreadsheet table.”

Looking ahead
Arm recently surveyed 900 people in the Arm global ecosystem to understand priorities and perspectives on what the future holds. “When we asked which automotive trends and technologies would most impact the industry in the next five years, two clear themes emerged — evolving functional safety standards and requirements, and the move toward software-defined vehicles,” said Chet Babla, vice president of Arm’s Automotive and IoT line of business.

“As drivers continue to rely on ADAS features like lane departure assistance or assisted parking, for example, functional safety-capable computing is increasingly critical. Arm and others continue to expand safety-capable IP offerings to accelerate autonomous decision-making across a range of ADAS and digital cockpit applications. In addition, Arm plays an active role in the development of international safety guidelines such as ISO 26262 and continues to support partners in their certification processes of Arm-based devices. The Arm Safety Ready Program includes a portfolio of Arm IP that includes ISO 26262-certified software tools and components and safety documentation to make it easier for our partners to develop and certify their safety-capable solutions. In addition, the Arm Functional Safety Partnership Program continues to ensure our ecosystem can connect with the right partners specializing in the software, tools, design services and training needed to support functional safety development and deployment.”

To accelerate the software-defined future for the automotive industry, Arm recently announced it is delivering critical resources through SOAFEE, a new software architecture and open-source reference implementation that brings real-time and safety needs of automotive together with the advantages of a cloud-native approach. Because there has been growing momentum for SOAFEE, a special interest group of industry leaders has been formed to spearhead and define the cloud-native development paradigm, as well as the strategic direction of the SOAFEE project.

Continuing growth and evolution
Unlike other markets, where funding and activity levels out after a few years, there appears to be no let-up in startup funding or in the number of big companies getting involved in automotive.

“This activity still seems to be going,” said Shuler. “There are companies doing all kinds of cool, different sensors, and lidars, RF SoC — basically active scan phased-array radars on a chip. There are more and more companies coming out with these devices. While the problems aren’t anywhere near solved, there seems to be more and more people still coming into the market to try to solve things. There’s still tons of engineering work being done, even for safety-related aspects of autonomous vehicles. The standards of how to do things evolve, as architectures evolve, and it’s Darwinian. You can tell when a new technology has become a commodity when you look at all the competitors block diagrams, and they all look the same. For example, in 2011, 2012, and 2013, cellular phone modem diagrams all started to look the same. Or if you look at a cellular phone application processor, they all started to look the same, and that means the problem is pretty much solved. Then it’s just a Darwinian thing where there may be 20 or 40 companies fighting it out, down to 2, 3 or 4 remaining. There’s so much processing that has to go in automotive, and it’s not just ADAS. It’s about bringing many of the systems from the Dark Ages into today’s technology, and it’s going to be a long time before the problems have been solved.”

Willard Tu, senior director, automotive business unit at Xilinx, has a similar view. “Never before have I seen so much disruption in the automotive industry,” he said. “You’ve got connected vehicles, you’ve got a bunch of startups that never were part of the automotive ecosystem, and now they’re everywhere. There’s so much funding going into automotive startups, it’s crazy. Then, of course, there’s the move toward electrification, thanks to Elon Musk, and everybody’s trying to play catch up. Another significant change for the automotive ecosystem is hardware versus software approach. Carmakers always relied on making the car, and following that with a transaction. ‘I sold you a car. I made my profit.’  Now they all want to copy the mobile phone market and have recurring revenues. It’s definitely the future, but it’s hard to do at scale. For a premium car, I can understand it. For an affordable entry-level car, are you going to put all that electronics in there? It’s baby steps. It’s easy for a Tesla. It’s easy for a Rivian or somebody who’s brand new that has no volume. But can you imagine an OEM saying, ‘I’m going to put it in every vehicle and see if anybody’s going to give me money for this?’ I’m convinced it will happen. It’s just a matter of when.”

The relationships between OEMs and Tier 1s is changing, as well. “It used to be the Tier 1s really dictated what’s going on,” Tu said. “These OEMs want differentiation, and the software business model really resides with them. So they’re getting a lot more active in electronics than they used to be. This adds uncertainty into the market, so it is open to newcomers that can provide answers to the uncertainty with flexible platforms to solve it.”

Automotive Knowledge Center
Zonal Architectures Play Key Role In Vehicle Security
Will zonal architectures in automotive applications provide unique benefits to cybersecurity?
Advanced Packaging For Automotive Chips
Cost, thermal dissipation, and overall reliability will likely determine which technologies get used where.
Competing Auto Sensor Fusion Approaches
Cost, data volume, and complexity drive multiple solutions.
Changes In Auto Architectures
From driver-centric to driverless functionality.

Leave a Reply

(Note: This name will be displayed publicly)