“The era of “software-defined vehicles” has long begun, with more and more players, including OEMs, Tier 1 suppliers, and content providers, joining in and trying to carve out their own share of this trend.

As the value of automotive software is increasingly recognized, both within and outside the industry, the understanding and research of “software-defined” has deepened.

Recently, ARM launched the first architecture to introduce the concept of “cloud-native” into automotive software development, called SOAFEE, which stands for Scalable Open Architecture for Embedded Edge, along with two new reference hardware platforms.

More importantly, two executives from ARM—Robert Day, Director of Partnerships for ARM’s Automotive Division, and Deng Zhiwei, Senior Director of Partnerships for ARM’s Automotive and IoT Division in the Asia-Pacific—shared ARM’s thoughts on “software-defined vehicles” behind the SOAFEE software architecture.

In fact, there are many different interpretations of the concept of “software-defined vehicles” in the industry. From the perspective of the overall vehicle value, “software-defined vehicles” means that the value of the entire vehicle will no longer be determined by traditional mechanical hardware but by software and the electronic hardware that matches the software.

Morgan Stanley once mentioned in a report on the autonomous driving industry that in traditional car production, hardware accounted for 90% of the vehicle’s value, while software only accounted for 10%. However, in the future, the proportion of software in the overall vehicle value is expected to rise to 40%, while hardware will also decrease to 40%, with the remaining 20% determined by content.

The key to differentiating vehicles in the future may no longer depend on traditional hardware such as engines but will shift to software update services throughout the vehicle’s lifecycle.

The reason behind this, as Robert Day said, is that “software-defined vehicles” make the long-held belief in the automotive industry that “vehicles begin to age the moment they are delivered to the user” no longer applicable. In the future, through subsequent software updates, the driving experience of vehicles may only improve with increased mileage:

Just like consumers are already accustomed to software updates on smartphones, in the context of “software-defined vehicles,” the vehicle’s intelligent driving system can obtain more precise control or new functions through online upgrades; or, by analyzing and optimizing battery charge and discharge cycles, enhance the vehicle’s range…

Based on this, in the near future consumer market, software may replace traditional hardware to become the core competitiveness of future vehicles.

Currently, many car manufacturers at home and abroad are exploring software payment business models.

For instance, Tesla can generate cash income through the FSD fully autonomous driving optional package, OTA paid upgrades, and advanced vehicle networking subscription services, with cumulative cash income from FSD reaching $1.26 billion;

Meanwhile, Xpeng Motors in China has also started to offer its advanced autonomous driving system XPILOT 3.0 software to car owners for a fee this year. Perhaps driven by software revenue, Xpeng Motors’ gross margin has increased to 11.2% in the first quarter of 2021.

With many players stirring the pot, the automotive software market continues to grow.

According to McKinsey’s estimates, the automotive software market is expected to grow at a rate of 9% per year, reaching a total market size of $84 billion by 2030.

The vastness of the “software-defined vehicles” market is evident, but we also cannot ignore the technical challenges within.

ARM points out that a brand new model not only needs to include multiple mandatory functions that comply with regulations in different regions but must also provide hundreds of functional options, which can exponentially increase the potential variables.

To meet these functional configuration requirements, a method for large-scale development, testing, and provision of various functions is needed to minimize interference and interdependencies.

Moreover, software cannot exist without hardware support. Nowadays, the increasingly diverse and complex software functions of vehicles also put forward higher requirements for hardware platforms.

Unlike consumer electronics that can be replaced every two or three years, the average lifespan of a vehicle is often much longer. During this period, although automotive software can be updated through OTA, the sensors, computing modules, data buses, and other basic hardware installed at the factory are unlikely to change.

This means that manufacturers not only need to ensure that the hardware platform of the vehicle can provide functional safety, information security, and other functionalities at the time of production, but also need to have a certain degree of foresight and planning to ensure that the hardware platform’s performance is sufficient to support functional updates for the next decade or longer.

This also brings about a rather challenging question: what kind of hardware platform can provide the flexibility, computing power, and data capacity needed to handle complex scenarios that have not yet occurred?

ARM’s answer is “software-defined.”

In summary, based on the sharing of Deng Zhiwei and Robert Day, ARM actually interprets “software-defined” as a software-centric design approach.

Specifically, ARM’s understanding of “software-defined” not only refers to “starting and controlling a specific function by software,” but also “a complete software definition must include the abstraction of the underlying hardware so that the same software can run smoothly on different hardware. Additionally, the software definition must have the capability for continuous upgrades and updates, and it must be based on cloud technology for development and construction.”

Based on the above understanding, ARM summarized four requirements that must be achieved for “software-defined vehicles”:

ARM’s latest SOAFEE software architecture and hardware reference platform were born for this purpose.

According to reports, SOAFEE consists of two main parts:

As a software architecture and open-source reference implementation, SOAFEE meets the automotive industry’s special requirements for real-time and functional safety by augmenting existing cloud technologies; at the same time, SOAFEE is based on the SystemReady open standard in the Arm Project Cassini, achieving abstraction of the underlying hardware.

It is particularly noteworthy that this architecture introduces the concept of “cloud-native” development.

ARM believes that as automotive functions become more complex and diverse, and automotive software code becomes increasingly lengthy, the cloud-native development approach that effectively helped the cloud infrastructure industry reduce costs and shorten development times is more applicable to automotive development than ever before.

Deng Zhiwei explained that in a system operating under the concept of “cloud-native,” “containers” that provide independent operating environments for different application services are developed, tested, and validated in the cloud environment. Then, through a software module called an orchestrator, appropriate software and hardware resources are configured for each application and service within the “container,” allowing them to perform tasks within the vehicle. Meanwhile, another CI/CD (Continuous Integration/Continuous Delivery) module in the cloud is responsible for managing the updates of applications and services.

He also noted that although there are already many cloud technologies available on the market, when communicating with car manufacturers and Tier 1 suppliers, ARM found that while they had tried many so-called cloud technologies, several key issues remained unresolved by existing technologies.

This is because cloud technologies from data centers or servers cannot be directly applied to the automotive industry. The most critical point is that automotive requirements for functional safety and real-time performance cannot be met.

One of SOAFEE’s most important contributions is that it improves the orchestrator to be a software module capable of handling functional safety and real-time requirements.

Deng Zhiwei pointed out that SOAFEE is the first truly cloud-native software architecture that can be introduced into the automotive industry and meet the special needs of the automotive industry.

With its unique position in the industry supply chain, ARM leads the development collaboration of SOAFEE and designs and provides standards, software, developer resources, and dedicated processing platforms targeting the safety and real-time needs of automotive applications.

But why is this work led by ARM rather than other traditional players in the automotive industry?

The vision of “software-defined vehicles” undoubtedly relies on the support of a large ecosystem.

However, how players in the ecosystem can perform their respective roles and avoid the problem of duplicating efforts is also worth noting.

Due to the many and complex levels covered by automotive software, car manufacturers, Tier 1 suppliers, software vendors, and other companies should have different focuses when building the automotive software ecosystem.

Deng Zhiwei stated that, overall, car manufacturers and Tier 1 suppliers have many shared aspects in software and hardware investments. If there is a unified “software-defined vehicle” platform as a foundation for development, and differentiated functions and services are developed on top of that, it will effectively enhance the investment efficiency of the entire industry, benefiting enterprises and users in the supply chain.

In his view, car manufacturers should focus more on providing applications and services that reach end users; Tier 1 suppliers should pay more attention to the needs and development of intermediate software while meeting the applications and services of car manufacturers.

As for more universally applicable foundational software modules, such as operating systems and hypervisors, they should be developed by third-party vendors.

If the automotive industry wants to build its own foundational software, the scale of the entire industry will become very large. The best approach is to leverage the software community to collaboratively build these foundational software elements,” Deng Zhiwei explained.

ARM’s role in this automotive software supply chain is to build a standardized infrastructure that meets the vertical needs of the entire smart automotive industry.

Deng Zhiwei mentioned that when discussing the SOAFEE idea with car manufacturers, Tier 1 suppliers, and even IC design companies, “everyone suddenly breathed a sigh of relief, feeling that this idea is great.”

This is because this move not only does not limit innovative development but can also provide an open, open-source, and standardized architecture, allowing car manufacturers, Tier 1 suppliers, IC design companies, and others to share technological resources, saving development efforts, and focusing more on product development and differentiation creation in their respective fields.

Currently, in addition to AWS, ADLink, Ampere, and CARIAD, ARM’s plan has already received broad support from multiple companies in the entire supply chain, including Apex.AI, Continental, Green Hills Software, Linaro, Marvell, MIH Alliance, Red Hat, SUSE, Woven Planet, and Zing Robotics.

The ultimate fate of car manufacturing and autonomous driving players

There is no war between autonomous driving star startups