Architecture this "basket" | C dimension

Software Defined Vehicles (SDV) is becoming a popular term in the post-pandemic era. Volkswagen CEO Dr. Diess praised Tesla, and recently, domestic brands have also announced their entry into the "Software Defined Vehicle" arena.

However, the understanding of "Software Defined Vehicles" is mainly from the consumer's perspective. There are differing opinions within the automotive industry's cutting-edge R&D field.

This involves the underlying foundation of the software. For example, what architecture is the software based on? How is the operating system defined? And who defines it? What problems will be encountered in the process of connecting everything, breaking down information silos, and how to solve them? This includes how the organizational structure of the companies behind software development is defined. This involves deeper issues.

At a forum in August, Huang Shaotang, CTO and Assistant President of Jiangling Motors, stated, "Software defines the car, architecture defines the software." He believes that software is tactics, while architecture is strategy. Therefore, we need to clarify what will define the future of automobiles.

Architecture or software?

First, let's discuss why the concept of "Software Defined Vehicles" emerged. A simple example will illustrate this. Tesla, a proponent of this concept, saw its Model X and Model S retain 57.22% and 57.74% of their residual value after two years of use (data disclosed at the 2019 China Automotive Finance and Retention Rate Research Committee Annual Meeting). This is considered a miracle in the current context of dismal residual values for used electric vehicles.

In addition, used Model 3s have recently been selling well in the US market. According to used car average sales day data from iSeeCars in the US, it takes an average of 68.9 days for a used car to be listed and sold. However, if a Model 3 appears on a dealer's website, under good condition and normal mileage, dealers only need an average of 29.3 days to sell it.

The quality and workmanship of the Tesla Model 3 are actually not as good as the top products of domestic independent brands. The reason why used cars can still sell better than fuel vehicles is entirely due to the powerful functions of its in-car software and intelligent driving assistance. This also illustrates the role of software FOTA in increasing the value retention of automotive products.

Tesla's rise is a result of the automotive industry having gone through "mechanically defined vehicles," "electrically defined vehicles," and "electronically defined vehicles." Currently, it is entering the "software defined vehicle" era.

The most significant aspect of "Software Defined Vehicles" is the change in business models. For example, McKinsey calculated that Tesla's customer-selected assisted driving and future fully automated driving software packages alone generated nearly US$1 billion to US$1.2 billion in gross profit in 2020. McKinsey also predicts that the market for software and electronic architecture in automobiles will reach US$469 billion by 2030. The prospects are bright.

So, why do those at the forefront of the automotive industry believe that architecture is more important? As industry insiders say, "For software-defined vehicles, the most crucial aspect is to reconstruct the underlying hardware and software infrastructure." Moreover, with the acceleration of "new four modernizations", competition among modern automakers is becoming increasingly focused on intelligence, such as autonomous driving and whole-vehicle FOTA. The basis of this competition still depends on the vehicle's electronic and electrical architecture (EEA).

In other words, what kind of architecture is used to support the software's operation? The entire automotive industry needs to reconsider the development of vehicle software and electronic and electrical architecture, shifting towards a more modular SOA architecture (Service-Oriented Architecture), making it easier to build modular software components. This is the major context for the rise of SOA.

Consider this: a few years ago, a car transmitted 15,000 data points per second, while in 2020, it needed to process over 100,000 data points per second. For example, according to a previous prediction from NXP's official website, the amount of code in automobiles is expected to grow exponentially from 2015 to 2025, with a compound annual growth rate of approximately 21%. Some vehicles already have over 200 million lines of code. The data speed of vehicles used to be approximately 150 kilobytes per second, but now it is gigabytes per second. In the future, if we enter the era of L5 autonomous vehicles, the required data and operating speed will be astonishing. The car has become an extremely complex software carrier.

Therefore, SOA is becoming an increasingly important architectural design concept, or a problem-solving method or "solution framework." Simply put, SOA requires each controller in the vehicle to provide its capabilities as a service, thereby building a flexible and variable platform system independent of vehicle models, chips, and operating systems to support various applications.

However, the difficulty lies in the fact that SOA is difficult to switch to existing development architectures because the current mainstream automotive software development based on AUTOSAR has insufficient variability (due to space limitations, this will not be elaborated). However, even with SOA becoming mainstream today, traditional automakers are still hesitant due to the huge investment required for a complete transformation of the vehicle's electronic and electrical architecture (EEA). But not changing is not an option; for example, in autonomous driving, the limit of the traditional distributed architecture of EEA is to support L2 autonomous driving, and L3 is already beyond its scope. So, what about L4 and L5?

Taking Volkswagen's eighth-generation Golf as an example, as the first product based on the MQB EVO platform, its original architecture was overwhelmed, so it adopted new CAN FD and in-vehicle Ethernet technologies, increasing the bus bandwidth from 500K to 2M, which is equivalent to half an architectural transformation. In other words, it solves the problem from a more fundamental logical perspective. However, this also led to numerous software problems, delays in delivery, and created real-world difficulties.

The Volkswagen ID.3, based on the new MEB platform and equipped with the E3 cross-domain fusion architecture, was finally delivered in September of this year after a year's delay. However, according to analysis by Dongwu Securities, because Volkswagen still mainly relies on multiple traditional suppliers to achieve a complete software system and is constrained by functional safety standards, its software architecture still relies on the AUTOSAR architecture, namely the standardization of upper and lower interface standards. Compared to Tesla's software system, its architecture is still a generation behind Tesla.

After all, Tesla's Model 3 has been upgraded from a distributed plus domain fusion architecture to a cross-domain fusion architecture and is moving towards a cloud-centralized computing architecture. The gap cannot be denied, otherwise Diess would not have praised Musk.

This is a global trend. Zhang Jie, Deputy General Manager of Changan Automobile's Intelligent Research Institute and General Manager of Changan Automobile Software Technology Co., Ltd., a leading domestic independent brand, also agreed at a forum that "a good architecture can lay the foundation for software."

There is another key point: the current state of software development in automakers is that the vast majority of software is outsourced. Only through a new architecture can the control of software development return to automakers. Therefore, changing the architecture requires automakers to "spend big money," but it will also affect the "interests" of Tier 1 parts suppliers. This is the underlying reason why Volkswagen is struggling with architectural changes, and it is also the reason why domestic automakers dare not easily make such changes.

"Decoupling of hardware and software"

To understand "Software Defined Vehicles," we must also understand the important concept of "decoupling of hardware and software." This is also an important characteristic of "architecture defines software."

Decoupling hardware and software, or separating hardware and software development. With the development of intelligent cockpits and autonomous driving technology, vehicles require more ECUs and sensors. To achieve FOTA and "software-defined vehicles," the probability of errors in intelligent vehicles will be very high if hardware and software are not separated. The significant increase in electronic and software bugs in recent years' vehicle recalls is proof of this. Data from 2018 shows that the proportion of software failures in all vehicle recalls rose to 15%.

Understanding "decoupling" can be illustrated by the example of mobile phones. Initially, the software and hardware in mobile phones were tightly coupled, but with the rise of smartphones, mobile phones have become software platforms, eliminating the need to consider the underlying hardware.

The same is happening with automotive software, but the original distributed EEA has reached its bottleneck. ECUs come from different suppliers, with different embedded software and underlying code, resulting in a complex software ecosystem. Tier 1 suppliers are naturally resistant to "revolutionizing themselves" and lack the motivation. Therefore, the transition to "software-defined vehicles" means that the relationship between automakers and their partners must change.

For example, development cycles used to be based on "vehicle model year," and Tier 1 updates to ECM (Engineering Change Management) typically had a cycle of 2-3 years. This approach is no longer keeping up with the times and needs to be driven by "agile methods" (agile methods are a new type of software development method that emerged in the 1990s) to enable OTA.

For example, due to the increasing computational demands brought about by the development of the Internet of Vehicles and the need for extensive ecosystem interaction, automakers must develop big data analysis systems to handle this massive data flow, even in near real-time. This requires automakers to place great importance on the importance of software and the concept of "iteration." During visits to automakers, it was observed that companies such as Changan and Chery have established their own big data analysis centers.

Looking at Tesla's data, as an outlier that first implemented FOTA, from 2012 to April 2019, there were over 100 iterations in total, including 11 bug fixes, 67 full-function deployments, and 64 interactive interface deployments. Furthermore, from the implementation of the Summon function via OTA in 2016 to the implementation of Smart Summon via OTA in October 2019. Each major FOTA created a leap in user experience. For users, this feeling of constant updates, similar to smartphones, is something that fuel vehicles cannot provide.

NIO, after overcoming numerous challenges, has implemented support for both SOTA and FOTA, with FOTA being particularly important. SOTA mainly upgrades the UI, navigation, and audio-visual systems. In terms of FOTA, NIO has achieved updates to the chassis, assisted driving domain, power and infotainment, and body domain. Currently, NIO's OTA iteration speed maintains an average of one version per month, and statistics show that it has been pushed to over 260,000 vehicles, with over 90 new features.

For example, at this year's Beijing Auto Show, William Li announced that the NOP navigation assist function will be pushed to users in batches via FOTA in mid-October with the upgrade to NIO OS 2.7.0. The pace of NIO's software version upgrades is something that many traditional automakers cannot currently achieve, and this pace is putting immense pressure on traditional automakers.

Of course, regarding "hardware-software decoupling," another issue needs to be considered: as the importance of digital modules in the vehicle architecture increases, the hardware configuration requirements behind the in-vehicle software also increase. In other words, software solves application-level problems, but if the hardware and communication do not keep pace, then deeper, more fundamental problems must be addressed. This is the view of some industry insiders.

During an interview with reporters at the Beijing Auto Show, Zhu Huarong, chairman of Changan Automobile, stated that this round clearly shows a rapid transition from hardware functions to software definition. This stage will involve hardware-software integration to enhance the definition and functions of automotive products. "We cannot simply say that hardware has no value. I believe that hardware is like a person's basic physical condition. If the physical condition is poor, even the best mind is useless. However, when the physical condition is good, software can make a person more intelligent."

An Conghui, CEO and President of Geely Automobile Group, shares a similar view. In an interview with the Auto Community reporter, he also stated that the hardware layer is an advantage for traditional automakers, including the design, development, verification, testing, simulation, and analysis of the entire mechanical architecture. However, this advantage needs to be transformed into integrating new energy and other software. "We believe it should be a combination of hardware and software, not just relying on software, nor is it as everyone understands now that traditional automobiles rely solely on hardware. Deep integration is essential to provide customers with an ultimate experience." The "integration" he mentioned, of course, also requires hardware-software decoupling and implementation under a new architecture.

However, solving this fundamental problem is still easier than software. Because fundamental problems are broadly divided into two categories: the narrow sense of insufficient computing power of hardware chips, and the broad sense of poor communication. Currently, high-performance chips and communication facilities, including 5G, are developing rapidly. For automakers, it's simply a matter of finding a balance between performance, quality, and cost.

Therefore, we know that "software-defined vehicles" still need to be based on an advanced architecture definition as the "framework." Although consumers see the software, for automakers, the "framework" of the architecture they develop is more important, and the traditional underlying logic needs to be subverted and reconstructed. What we need to do is maintain a more open mindset and embrace the unknown variables.

Postscript: The Birth of C Dimension

Auto Community has been around for ten years, and now we are trying to think from the source about the development laws of the automotive and even broader technology fields. Starting from the day before yesterday, we started weekly updates of the "C Dimension" column on the "Auto Community" WeChat official account, and we will launch a new WeChat official account in the future, continuing to focus on new technologies and new industries from the perspective of in-depth observation.

C is a magical letter. Car, Communication, and Chip all start with C, while Comment, Charge, and Challenge also begin with this letter. The "CASE" of "New Four Modernizations" is closely related to it. Naturally, Champion is adjacent to them in the vocabulary.