Friends who are constantly following the autonomous driving industry may have noticed an interesting phenomenon: the topic of operating systems is not as hot as chips and LiDAR. Even the industry’s attention to operating systems is at least two to three years behind that of chips— chips were already a popular topic in 2017, while operating systems still seemed relatively “niche” within the industry in 2019.
Why does this difference exist?
In light of these questions, “Nine Chapters Autonomous Driving” interviewed many experts in the field of operating systems in November, including Bi XPeng, co-founder and vice president of research and development at Huayutong Softunion, Shang Jin, general manager and CTO of National Automotive Controller, Wang Haowei, chief architect of Zhongke Chuangda, and Mao Haiyan, business line director and global sales manager for Europe and America at Neusoft Rui Chi.
The consensus among the interviewees on this issue is as follows:
This is similar to the development process of smartphones. Initially, everyone hopes that their products will have obvious differences in functionality compared to their competitors. Hardware is the foundation and guarantee for implementing new functions (such as traditional chips that can support vehicle control, but cannot be used for autonomous driving). Therefore, hardware such as chips (mainly based on computing power) won high attention in the early stages of autonomous driving. In contrast, high-performance operating systems not only solve the problem of “can it be done,” but also the problem of “how well can it be done.” Early autonomous driving functions were relatively simple, and generally did not require high-performance operating systems.
L1-L2 autonomous driving is often achieved under a distributed EE architecture, with each function algorithm corresponding to an independent chip. These function algorithms are relatively simple and do not require high-performance chips. Microcontrollers (MCUs) are sufficient. These MCUs run Autosar Classic Platform (referred to as Autosar CP) and other real-time operating systems (RTOS). Autosar CP includes a complete set of operating systems, including the kernel + middleware, although its functional level is low and has many limitations, it seems to be “enough”.
In short, traditional ECUs have limited functions and relatively easy operation. For example, sensor processing only involves simple, low-resolution point clouds or digital images, and often only needs to schedule a single task, so there is no need for high-performance operating systems to implement resource scheduling and allocation.
Moreover, at this stage, function algorithms are highly coupled with MCUs. The MCUs that automakers buy from suppliers often come with algorithms, and automakers only need to do integration work, without the need to write their own algorithms. Therefore, there is no natural motivation to focus on operating systems. If the biggest “client” is not in a hurry, where will the motivation come from for entrepreneurs and investors?Compared with L2 and above, the function algorithms become much more complicated. Distributed EE architecture can no longer meet the requirements, and it is necessary to develop based on centralized EE architecture. Under the centralized EE architecture (domain controller, central computing platform), multiple algorithms run on a system-level chip (SOC) similar to Xavier, and a large amount of information needs to be collected to the domain controller for perception, calculation, decision-making, data transmission and fusion, which is much more complex than in a distributed architecture. In this case, the amount of data that the SOC chip needs to process increases exponentially, and the workload involved is also greater. Many tasks still need to be scheduled simultaneously in multiple threads, which requires a powerful real-time operating system to better allocate, schedule, and store computational and storage resources.
In addition, although SOC and MCU play similar roles, the former has much greater difficulty in implementing functional safety (such as algorithm security, data real-time performance, etc.) – MCU is only suitable for simple scenarios with clear requirements and low requirements for computing power and latency. Correspondingly, the ROTS running on it only needs to provide some scheduling mechanisms and process some simple logic. However, smart driving SOC needs to deal with complex scenarios, where the system’s algorithms are complex, rich in functions, and need dynamic deployment. At this time, Autosar CP can no longer meet the requirements, and high-performance operating systems gradually became a “must-have” for developers.
The more important reason is that whether it is Tesla, Weixiaoli, other domestic manufacturers, or Tier 1, everyone’s hardware framework has basically been determined, and the functions that can be realized based on the hardware have also been basically determined. Regardless of whose chip is used, the functions that can be realized are basically image perception, etc. Therefore, everyone naturally focuses on software differentiation when pursuing differentiation.
When everyone begins to pay attention to software differentiation, software and hardware decoupling will inevitably become the inevitable choice. Regardless of whether they have the ability or not, any ambitious automaker will no longer accept “software and hardware integrated solutions” provided by suppliers. Under the background of “software-defined cars”, automakers must go down and develop their own software algorithms, define functions, develop differentiated applications, and implement OTA upgrades, otherwise they will miss the most important value in the vehicle’s entire lifecycle. To achieve these, it is necessary to pay attention to the operating system.
Several interviewees pointed out that from the history of the intelligent smartphone industry, in the early stage of industry development, the operating system usually followed the chip manufacturers, and the operating system was “ready-made” when the whole machine manufacturers (mobile phone manufacturers, automakers) bought chips – at this stage, how to choose an operating system was more of a concern of chip manufacturers, and downstream whole machine manufacturers did not need to “worry too much”; but as the product maturity increased, the importance of the operating system gradually became prominent.From the perspective of autonomous driving, the chip solves the problem of “can or cannot”, while the operating system solves the problem of “good or not”. Before the problem of “can or cannot” is solved, the issue of “good or not” is not urgent. However, once the difficult problem of “can or cannot” is overcome, the issue of “good or not” naturally becomes the “main contradiction”.
In short, in the early stage of the development of the autonomous driving industry, chip manufacturers were leading the way with operating systems, but as the industry gradually matures, the voice of the operating system will become increasingly important. Many interviewees believe that at some stage in the future, when the industry has highly developed and developers are highly concentrated, the market concentration of operating systems will be very high.
In a narrow sense, the operating system mainly refers to the kernel of the operating system, while the broad operating system also includes the “middleware” above the kernel and below the application software. In the article “Current Status and Future of the Autonomous Driving OS Market” published in April of this year, the author analyzed the kernel of the autonomous driving OS in detail. In the next two to three months, the author will use 3-4 long articles to introduce the “popular science” of the autonomous driving middleware. Interested friends, please stay tuned for our updates.