The automotive ecosystem is becoming much harder to navigate as automakers, Tier 1s and IP vendors redefine their relationships based upon shifting value caused by an rapidly expanding amount of increasingly interdependent and complex electronic content.
Predictions of massive change started almost a decade ago with a number of pilot programs around autonomous vehicles. But those shifts really begun showing up across the supply chain over the past few years, as carmakers scrambled to keep pace with Tesla’s autopilot technology. Prior to that, carmakers (OEMs) defined their requirements, and the majority of the non-proprietary systems were provided by Tier 1 suppliers.
“Semiconductor chips were provided by semiconductor vendors, both fabless and IDMs,” said Thomas Wong, business development director in Cadence’s IP Group. “A number of ECUs, especially for engine control, were designed as custom chips. Most of the semiconductor vendors in the automotive space had a deep bench of knowledge in-house, especially in the areas of quality, reliability and safety. Most, if not all, of the IPs used in those chips were designed in-house, and the design cycle could be as long as three to four years,”
Fast forward to 2020, and the automotive landscape looks very different. Besides established carmakers, there is a new breed of companies getting into the car-making business. “Take a look at the number of electric vehicle startups and the cash-rich Internet giants getting into the car business,” said Wong. “With the popularity of ADAS and autonomous driving, the computational needs for these SoCs have pushed automotive semiconductors into very advanced process nodes. To achieve Level 2/3 capabilities, you need sensor fusion (vision, radar, ultrasonic and LiDAR). To go beyond that, you will need in-vehicle ML/AI computation (AI inference on the edge) for pathfinding (sense, compute, decide). Next on the horizon will be V2V and V2X. On top of these technical challenges, some OEMs have begun designing advanced SoCs themselves as they perceive these R&D efforts as differentiating and game-changing. As an example, Tesla has deployed their in-house designed HW3 hardware, which is shipping in both the Model 3 and Model S.”
Creating a functionally safe and secure system from scratch requires a tremendous amount of design expertise. Autopilot systems are incredibly complex, and the expertise to build these systems is in very short supply.
“It requires multiple sensor inputs,” said Burkhard Huhnke, vice president, automotive at Synopsys. “We need to make decisions on how the car is moving, maybe even without the impact of the driver. How do you assemble such a system out of sensor and domain controller data and out of the inputs, which are a data stream? It requires sensor fusion and a protected communication channel from the sensor into the domain controller. And then, if the domain controller makes a decision, it has to make the appropriate path planning of, for example, the next steering wheel angles, acceleration of the car, and the positioning of the car. Closing this loop of positioning the car right now, and in the next few seconds, is the job of the controlled loop systems of an ADAS modern autopilot system.”
Measuring the data from the lane markers, obstacles on the road, including cars and other objects, starts with input from the sensors.
“Just looking at camera data, that needs to be pre-processed by algorithms, which are able to capture obstacles in an the image,” Huhnke said. “There are static objects, lane markers, there are moving objects, and so on. This requires very fast processing of this data. Imagine you have 60 frames per second. You have maybe an HD matrix/charge coupled device matrix, which requires very fast calculations to determine what’s actually in the picture. If I take the most advanced autopilot system in the market, it has maybe three cameras — short-range, mid-range and far-range, and you need to detect obstacles in each image super fast. Calculating performance is key. This brings accelerators into the discussion, which are now required, as well as accelerators in IP, which are optimized for the algorithm of object detection. This includes an instance of a very fast CNN (convolutional neural network) system, which is an accelerator to do object recognition of the matrices.”
This is just one step in pre-processing and identifying of obstacles in the image. It also includes multiple images with a different focal points for near-field, mid-field and far-field to identify similar objects and different objects. The different aspects of those images have to be fused together extremely quickly, which requires a sensor fusion processor that identifies the key information in each picture and provides this determined object into the domain controller. All of this is optimized IP. Subsystems are needed that understand perfectly how to determine these objects out of the camera information.
“Imagine there is a threshold in the positioning of one of the objects you detected,” Huhnke explained. “Then you have huge problems. So security is an aspect, along with functional safety, since what you identify as an object is going to result in an activity of the car. This has to be functionally safe within a defined failure rate. And how can you calculate the failure rate of this entire system? This speaks to different layers of the ecosystem. How do you calculate the failure rate through the entire system? That requires a failure rate at the IP level, a failure rate at the system level, a failure in the vehicle. Only then are you able to understand how precise and accurate the object detection is so that it can be calculated into the activity and plan a path for the car. And that requires knowledge of the vehicle down into the IP world and back up into the vehicle. This collaboration is programmed and has to happen in a customized autopilot system that uses functionally safe and secure IP building blocks.”
Simon Rance, head of marketing at ClioSoft, agrees. “Functional safety requirements in the automotive industry flow from supply chain to IP development,” he said. “This flow encompasses both end product-level requirements management and IP-level requirements management. Traceability challenges begin with requirements and the specification, but they become more complex during the design and development phase. To ensure traceability and adhere to functional safety requirements, you need robust IP data management. According to the ISO 26262 standard, ‘Safety requirements shall be traceable with a reference being made to each source of a safety requirement at the next upper hierarchical level, the next lower hierarchical level, or to its realization in the design and the verification specification.’ Having an IP data management system that follows and ensures the above steps is absolutely necessary in meeting the overall functional safety requirements flow with traceability. The ability to trace all the IP revisions and, of course, its usage hierarchically is why IP data management is so important for ADAS. Without IP data management and reporting, automotive companies will struggle to adhere to functional safety requirements.”
Meeting the high-reliability standards of the automotive market also means companies must work in close collaboration across the semiconductor ecosystem. “This includes the semiconductor foundry, device packaging, underlying semiconductor IP and certification bodies to ensure compliance. The design of the IP, for example, has to be certified for fault-tolerance (ISO26262 ASIL) and environmental standards (AEC-Q100). To meet these standards, IP companies need to work in collaboration with third-party companies that evaluate and certify the IP for fault-tolerance. IP companies also have to work in close collaboration with the foundry to ensure the design will meet the overall environmental requirements including temperature and aging,” Frank Ferro, senior director, product marketing, IP Cores at Rambus pointed out.
Who do you trust?
Another automotive tenet is reliability. “This system has to work for 15 years in the traffic, and everybody expects it to work perfectly,” said Huhnke. “These subsystems must be functionally, safe, secure with a root of trust, and proven reliable by testing and continuously monitoring the function. Without the connection in between IP building blocks and the vehicle view it would not work. You have to understand what kind of function you are going to build in this high level of the vehicle, and how to provide the highest accuracy, reliability and security from the IP standpoint because based on this IP, the SoC is created and then the board. These are the basis of the electronics of the domain controller and the brain of the object detection and controlled-loop system.”
The complexity grows rapidly from here. This is only the electronics subsystem level. Another layer is the partnerships that are required to make this all work, and those relationships are in a state of constant change.
“There are companies that for many years have been providing IP into automotive, and they’re finding themselves in a difficult situation,” said David Fritz, senior director, autonomous and ADAS SoCs at Mentor, a Siemens Business. “The trust relationship all the way through the ecosystem, from the OEM down through Tier 2s and the IP suppliers, hasn’t been the best. In the past, if you look at the actual contracts, they are incredibly onerous. There is uncapped liability, as well as other things that most companies would never ever agree to, and yet the suppliers have been forced to do that by the OEMs because they rely on the Tier 1, which relies on the Tier 2, which relies on a IP supplier. If anybody in that chain fails to deliver, then it could stop the whole model year from coming out. It could kill a company.”
Most of those restrictions are in place because of previous failures. “So there is a trust gap,” said Fritz. “That’s the reason why an OEM could go to a very large semiconductor company and say, ‘You have a track record of delivering high-quality, highly complex solutions. We want to talk with you.’ The issue that’s happening there is the understanding of the requirements in the automotive industry are different. Even though there are new relationships being formed that threaten the old relationships, even the new relationships require a new methodology from the OEM.”
The rules have changed, however. The OEMs now demand that beyond the data sheet, the IP suppliers must prove their IP works. For instance, in the past, an automotive IP company would begin to get requirements in the RFPs from the OEMs, such as delivery of a model with a model of particular fidelity within six months of signing the contract. And then, every six months thereafter, the IP supplier would have to show empirical proof in the model that it is trending toward the final requirements. This has been standard practice in the smart phone industry for some time, but it is new in the automotive space.
“The ECU based companies aren’t used to that at all,” Fritz said. “If you say to a supplier, ‘I need to deliver these models to our customer, the OEM,’ they’d say they didn’t have them. So immediately they’re a problem. However, a lot of the new startup companies with new methodologies for companies transitioning into automotive from other domains are capable of doing that. That’s part of the upheaval. But this is an opportunity for existing suppliers to differentiate. They do have these models, or they couldn’t do what they’re doing. They’re just not used to sharing them. The trust has to be built back up that been broken over the last hundred years.”
To Arteris IP, which has been active in the automotive market since 2010 and has established relationships with most of the automotive semiconductor players, this behavior is not a surprise.
“There’s paperwork that goes back and forth about who has been certified for what, or how to go about assessments or about ISO 26262,” said Kurt Shuler, vice president of marketing at Arteris IP. “For companies new to this, whether on the semiconductor side making an automotive chip or an IP that’s going into automotive, it can be weird to get questions from customers asking for the processes to be described, or how traceability of requirements is done through to the specifications, and the implementation queue. If you’re not in automotive or medical devices or something similar, like military/aerospace, you’re not used to being asked those questions or even revealing that information externally. If you’re new to an automotive chip, or new to automotive IP, you have to deal with that. It’s an education process.”
But it also is indicative of a growing tension over who’s calling the shots in automotive, particularly as more electronic content is added into vehicles and many vehicles behave exactly the same way on the road.
“Nobody wants to be the Foxconn of cars, just stamping the metal, so there’s a fight over the architecture for all these systems,” Shuler said. “The Tier 1s traditionally have been the automotive component suppliers, many of which were spun out of the OEMs. The OEMs are now in an interesting situation where the Tier 1s think they own the system, which clashes sometimes with the semiconductor people who may be system people who do their own semiconductors, like a Mobileye or an Nvidia who say they own the system. The OEMs, either through themselves or through their autonomous driving subsidiaries like Cruise, owned by GM, are saying they are creating their own system, so they own the system and tell the Tier 1 what they want. It’s a disaggregation and a re-verticalization of the value chain in some cases.”
Today, OEMs have a new set of partnerships. “Even three years ago, OEMs were conservative to the point of, ‘Mr. Tier 1, what can you give me?’ To another Tier 1, ‘What can you give me?’ ‘I’ll make a choice to a phase of Tier 1, here’s what we want.’ We’re going to tell you what to do to the point of now realizing they are not getting what they want from the Tier 1, and deciding to do it themselves. They want to own it, so those companies have now become more cognizant of the semiconductor input on the side of things,” Shuler said. “Today, all OEMs have at least small chip development teams. Some have large organizations. In the traditional case, what they’re doing is specifying and sharing requirements with their Tier 1s and ultimately the semiconductor suppliers, but in some cases, they’re jumping over. Instead of talking to the Tier 1, they’re talking directly to a semiconductor provider, such as NXP. In other cases, they’re designing their own chips. Chip design has really democratized with this whole IP industry. Anybody can create a chip if you have enough money and can get the expertise. Now that Google, Microsoft and Facebook are designing their own chips, they’re paying top dollar for really good chip talent. The Tier 1s are starting to go in that direction, and even the OEMs are looking at it, so it has changed who we talk to.”
There’s also non-linear competition. “Networks-on-chip enable the bandwidth, the latency, the complexity of an SoC, as well as the data protection for data traveling to the SoC — data and transit through that SoC. So while that is important to the traditional chip vendor, if I want that chip vendor to use it, and I want to get top economic value for it, even if a Tier 1 or OEM is not my customer I still need to educate them about a network-on-chip interconnect. The great thing about the partnerships is you get a better system view because everybody does their own little piece. Even though we look at a company like a Denso or a Mobileye, NXP, or Toshiba, and even though we think they’re working on huge problems for their customer, that’s not the whole world. They’re a small piece of a bigger thing, and the more we all understand about the context of the bigger thing, the more proactively we can address issues at our particular level,” Shuler offered.
Unpaved road ahead
But carmakers are still learning how to design and build advanced SoCs, and it will take many years before they can bring this entire capability in house, said Cadence’s Wong. “In the meantime, they will partner with third-party IP vendors, ASIC design service providers, EDA vendors, OS vendors, applications software vendors, etc. And let’s not forget the need for functional safety-like adherence to ISO 26262 standards. Even in the case of SoC implementation, you will likely see these SoCs with heterogenous architectures being populated with a NoC fabric (network-on-chip), internally developed IP blocks, third-party interface IPs, and CPU, GPU, and DSP blocks from other third parties. This is where interoperability testing will be needed, and co-operation of all members in the ecosystem is needed.”
Depending on where a particular company fits in the food chain, the ecosystem can look very different.
“Furthermore, automotive chips and systems are getting more complex in responding to end market needs and consumer choices. It is no longer a hardware-centric system, but rather software and hardware co-designs. Software can manifest itself as operating systems and its related development infrastructure such as compilers and debuggers, as well as applications software that is likely to come from a myriad of partners. For example, most new-generation infotainment systems support Apple CarPlay and Android Auto. Over-the-air updates also require wireless connectivity such as cellular or WiFi as well as extensive security measures. With this backdrop, you now have another set of ecosystem partners. All these interrelated systems must ‘talk’ to each other. This ecosystem will require massive interoperability testing to make things work seamlessly, and a lot of these systems are mission-critical when related to ADAS systems,” said Wong. “The entire industry is on a much tighter development timeline, and the mantra from carmakers is shift left. Everyone is trying to reduce development time from 4 years to 2 years (more realistically from 5 years to 3 years). With these complex systems involving lots of software, it is important to be able to start software development before you have the hardware ready. Remember, it will take 2 years to develop a new SoC.”
Mentor’s Fritz expects this turmoil to continue for the next five or six years, and believes it eventually will be resolved by a revolutionary change that’s currently underway, which is essentially the whole concept of having 50 to 200 separate, independently developed ECUs spread throughout the car, each doing its own task in its own way, with its own software and interfaces. “All of the OEMs are either actively working on programs or laying out programs to completely re-architect the automobile from the ground up. And one of the first things that they attack is this whole ECU, each one by a different company done in different way doing something different. AUTOSAR is meant to normalize that. The problem is there are new features that AUTOSAR can’t handle, including the data traffic required for ADAS — certainly not Level 4 or even Level 3 autonomy — so you have go around that network infrastructure that AUTOSAR is built on.
All of this should open the door for a lot more suppliers to come in and be able to play in a new market. Consumers will win, too. The best solutions will win, and more interesting solutions will be enabled.
Until recently, Fritz believed the revolution in automotive would be centered on and driven by autonomous vehicles and advanced ADAS. “I’ve given up on thinking that you can incrementally go through ADAS and find your way into autonomous driving. That in itself requires a rethink of how the whole system is architected, and companies in the automotive ecosystem are architecting for these new business models, along with normalization, central computing and zone controllers, among other things. They’re also designing in the capacity to do Level 5 autonomy. It doesn’t mean they are going to deploy it immediately, but it means it’s going to be designed for that from the start and released incrementally.”
What this means is that even though the automotive revolution isn’t yet about autonomous driving. It’s about the whole experience, which is enabled by democratization of these architectures within the OEMs ecosystem, whereby each OEM has its own approach, while all heading in roughly the same direction. And it requires the interplay of all companies within the ecosystem to make this a reality.