Cloud native EDA tools & pre-optimized hardware platforms
From heated seats to automated cruise control, theft deterrents, and in-vehicle entertainment, an array of sophisticated features differentiates today¡¯s vehicles from those of five years ago. Some capabilities promote safer driving, while others create a more engaging in-vehicle experience. What all of them have in common is their reliance on connectivity and vast amounts of software.
Unlike older generation vehicles whose value has been marked by ride, horsepower, and safety, today¡¯s rides are defined by rich, differentiating software content¡ªwhich is also providing automakers with new revenue opportunities.
As vehicle architectures evolve, many carmakers are facing a relatively new challenge in efficiently developing reliable and secure automotive software. This shift requires new ways of thinking and a totally different approach to software development. In this blog post, I¡¯ll share some key considerations and questions to factor in when developing solutions for software-defined vehicles that must meet safety, security, reliability, and quality standards.
Today¡¯s cars have been characterized as a data center on wheels and, from a consumer viewpoint, an extension of the driver¡¯s smartphone. Look deep under the hood of high-end vehicles, and you¡¯ll find a digital platform made of 150 million lines of software code distributed among 80 or more electronic control units (ECUs), as well as in sensors, cameras, radar, and LiDAR devices which generate massive amounts of data. All of which culiminates in a change to what drivers expect from their cars due to the dramatic convergence of electrification, connectivity, and automation.
Automakers are continuing to adjust and adapt to a new way of designing and developing their vehicles. At the moment, it¡¯s not uncommon to find processes on the distributed side with various vehicle subsystems somehow coming together late in the game, which isn¡¯t an ideal way to work with all the considerations around increased levels of system interactions and safety. To keep them future-proof (like many of our electronic devices), modern cars must be designed to be upgraded over time through over-the-air (OTA) updates. Their processing capabilities and memory need to allow room for growth and change. And key components must be designed to adhere to functional safety standards.
Many OEMs are starting to recognize that new skill sets are needed in this new automotive digital platform environment. Often, teams are being tasked to create, from scratch, complex and robust software infrastructures that span multiple disciplines. They are also evaluating the best ways to manage their software components over time. For example, consider a software update that increases the battery range of an electric vehicle. Have you considered the impact on long-term battery storage and life? Just because you can does not mean you should make software changes. Who controls these changes? Is it only the OEM, Tier 1s, or possibly even the end user?
It¡¯s not just cool new automotive features that are driven by software. Vehicle tracking and monitoring is another aspect. For example, fleet vehicles equipped with software tools can share performance updates with fleet managers, enabling them to become aware of issues early on, and allowing fleet owners the opportunity to make adjustments that may extend the life of components or enhance vehicle performance.
For personal vehicles, traditionally, drivers would take them to the auto repair shop for maintenance. Today¡¯s cars can provide real-time snapshots as the vehicles are being driven. This, together with OTA capabilities, totally changes how vehicles can be maintained and calls for a new way of thinking by those in the auto industry and consumers alike.
There will also be new opportunities to partner with third parties to enhance the in-vehicle experience. For example, consider a coffee house chain that develops an in-vehicle app that tracks the vehicle¡¯s location and suggests a drink order as the car nears one of the chain¡¯s locations. While these kinds of opportunities can be enriching for drivers and passengers, automakers will have to ensure that the apps meet their standards for quality, safety, and security¡ªsomething that, until now, hasn¡¯t required consideration.
The increased pace of software development for today¡¯s vehicles presents a need for faster access to virtual models for testing. Virtualization can help increase the pace of testing and validation, but it also raises new questions. What¡¯s the best way to create a duplicate environment similar to what¡¯s happening in the vehicle? In a virtualization environment, before hardware becomes physically available, what¡¯s the most effective way to start software bring up and testing with virtual hardware to discover issues that need to be rolled into the physical hardware?
Given the changing needs of a vehicle¡¯s software infrastructure, there are also considerations around how software tooling is maintained, as well as implications on when and how upgrades are made. In other words, OEMs now manage software toolchains on which their vendors are dependent. When upgrades are made, vendors must be trained.
The hardware abstraction layer (HAL) could be considered one of the most critical components to the success of software-defined vehicles. At both the vehicle level and the data center level, both instances of the HAL must be close to identical, if not identical, to validate the amount of testing that will take place in the cloud and be pushed out to the vehicle. Otherwise, the testing may be invalidated. As teams evaluate how to migrate their environments to and from the cloud and into the vehicle, developing requirements for what the vehicle components must be able to support, the HAL becomes even more important. Over the next few years, we will see a shift towards standardization in HALs that will help drive the move towards virtualization.
Speaking of standardization, projects such as the Scalable Open Architecture for Embedded Edge (SOAFEE) project, of which Synopsys is a voting member, aim to make software development, testing, and validation more effective and efficient. SOAFEE is a collaborative project involving automakers, semiconductor suppliers, open-source and independent software vendors, and cloud technology leaders collaborating to produce a cloud-native architecture supported by open-source reference implementations for various automotive applications. The project¡¯s efforts can serve as a framework for any organization seeking to define standards around software-defined vehicles.
As you can see, software-defined vehicles are shifting the dynamics of the automotive development landscape, raising new considerations and questions for all the players in the ecosystem to address. Differentiation is now driven by software, along with the engineering ingenuity to conceive of and implement unique features and functions. For many automakers, this shift from a hardware to a software focus is fairly new territory, requiring new skill sets and a new way of thinking.
Synopsys offers a breadth of automotive chip design and verification, prototyping, IP, and software security solutions. We participate in a number of automotive standards organizations, shaping the direction of key processes and protocols. With our deep automotive expertise and technology portfolio, Synopsys can help automotive OEMs and Tier 1 businesses develop software-defined vehicle infrastructures that meet automotive functional safety standards. Working together, we can drive greater safety, security, reliability, and quality into automotive systems, while reigning in costs and meeting time-to-market targets. The future of the automotive industry is being shaped by lines of code, and software is opening up new pathways toward differentiation and revenue opportunities for anyone ready to seize them.