Source: China Automotive Software Conference @ China Association of Automobile ManufacturersThe autonomous driving operating system is a software platform specifically designed to support the functions of autonomous driving in vehicles. It needs to coordinate and manage the hardware and software resources of the vehicle, meeting the strict requirements for safety, reliability, real-time performance, and data processing capabilities for various autonomous driving applications.The Linux system has significant advantages in terms of open-source kernel, rapid iteration capabilities, cost-effectiveness, and a rich ecosystem. The application of Linux in automobiles is not limited to in-vehicle entertainment systems but has also expanded to critical control and autonomous driving systems. The autonomous driving field has widely accepted and applied Linux as the foundational software for autonomous driving operating systems, which helps promote technological development in the automotive sector and the construction of an open-source ecosystem, shortening innovation cycles and reducing iteration costs, thus forming a sustainable automotive software innovation platform. With the development of technology and the improvement of standards, it is expected that the market share of Linux systems in the autonomous driving field will continue to rise.The Linux kernel originated in 1991, initiated by Finnish programmer Linus, who was then pursuing a PhD in computer science at the University of Helsinki. Initially, his goal was limited to learning about operating system kernel development and writing an operating system for his personal computer. He released the kernel to the internet and made the source code public. As programmers from around the world contributed, the kernel was continuously enriched, optimized, and stabilized, significantly improving performance, security, and usability. The Linux community has also formed a large open-source community.The open-source nature of the Linux kernel and its community-driven development model have allowed it to rapidly develop and proliferate, becoming an important platform for technological innovation and software development, giving rise to numerous distributions based on the Linux kernel, such as Ubuntu, Debian, Fedora, and RHEL (Red Hat Enterprise Linux), gradually becoming the most widely used operating system globally, serving as the infrastructure for cloud computing, big data, artificial intelligence, and playing an indispensable role in various industries. As vehicles develop towards intelligence and connectivity, their electronic and electrical system designs are becoming increasingly complex. As the core of vehicle control and data processing, the operating system faces growing challenges in functional safety technology. Intelligent driving systems based on Linux, intelligent parking systems, and Navigation on Autopilot (NOA) must not only provide users with superior functional experiences but also ensure that the system architecture design meets functional safety requirements, complies with international standards, passes compliance certification, and meets regulatory requirements. AUTOSEMO technical expert Cheng Zhifeng delivered an excellent speech. Cheng Zhifeng pointed out that there are market development opportunities for autonomous driving Safety Linux, and the technical design of Safety OS needs to consider four key factors, including spatial isolation, temporal isolation, bidirectional communication, and ensuring that all access, communication, and other activities are monitorable and traceable. Furthermore, all vehicle manufacturers, representative enterprises, and ecological partners need to work together to collaboratively build the industry, breaking down the autonomous driving systems based on Linux into multiple parts to tackle functional safety compliance issues one by one. This report was led by Horizon, with Changan Automobile, Lingzhu Technology, and Red Hat Software as deputy leaders, and participated by over 30 units including China Automotive Technology and Research Center, Neusoft Ruichi, ZTE, Safran, Infineon, Huizhou Huayang, Guokecushi, Desay SV, TTTech, Hejian Gongruan, Hedo Technology, China Automotive Research, PwC Basic Software, Zhongling Zhixing, Haomo Zhixing, and Botai Vehicle Networking.
The following content is a transcript of the on-site speech for learning reference only! “ Hello, experts! I am Cheng Zhifeng from Horizon. This afternoon, I am honored to represent the AUTOSEMO research report working group to share with you the research report on functional safety of Linux for autonomous driving. This report was conducted with the support and organization of the Software Subcommittee of the China Automotive Industry Association and AUTOSEMO.
Several experts have already mentioned the open software architecture of autonomous driving systems. Our report focuses on a specific technical point within the open software architecture—the research on the functional safety of the Linux system used in autonomous driving systems. I will introduce it from several aspects.
First, regarding the background of this work. Several experts have also mentioned that due to the new electronic and electrical architecture, the intelligent driving domain, cockpit domain, and vehicle control are merging, resulting in a coexistence of multiple operating systems and multiple functional safety levels within the entire intelligent driving system. Only with the support of multiple systems can we achieve the parallel operation of intelligent driving, human-machine interaction in the cockpit, and vehicle control functions.
The overall software architecture for autonomous driving shown in this diagram has already been introduced by several experts, so I will not elaborate further. In our multi-domain integration process, multiple operating systems with different functional safety levels coexist. The systems within the red dashed box are the main research objects of this report, which primarily serve as the foundational base for autonomous driving, supporting upper-level functions such as perception, planning, and decision-making. This is the focus of our discussion today.
For this type of system, the items on the right are key points of focus during the selection and evaluation process. First, whether such high-level (HL) systems have undergone strict pre-production verification and whether they can achieve at least ASIL B functional safety level in the upper-level perception and control functions. During the project evaluation and selection phase, when we look at the current market, it seems that there should be many options, but in the process of project implementation, we find that the range of options is very limited. One key evaluation factor is whether the system’s functional safety characteristics meet the ASIL B safety level.
Why is the Linux system applied in autonomous driving? The reasons are generally well understood. There are multiple considerations, whether from a technical perspective, its open-source nature, ecosystem, or the scale of talent reserves and development teams, everyone tends to adopt the Linux system. Our report predicts that the demand for Linux systems in the autonomous driving field will continue to increase.
In terms of functional safety requirements for safety OS in the autonomous driving field, we consider it from three levels: the first is from the legal and regulatory perspective. With the tightening of regulations and the improvement of laws, whether it is global regulations like R152 or domestic laws and regulations for L3 autonomous driving, they collectively impose higher functional safety requirements on the chip and underlying operating system for autonomous driving applications.
Taking the R152 standard as an example, the most basic AEB function in the ADAS system emphasizes traceability. From a conservative perspective, we interpret that the application function must derive back to the base, which is the operating system and chip, both of which need to possess functional safety characteristics.
The second level is from the perspective of domestic OEMs, who are also facing the evolution of high-level autonomous driving and the need to select functional safety operating systems for their overseas business. The industry is migrating to compete in L2+ level autonomous driving, with typical applications being urban NOA intelligent driving functions, where the foundational part must meet functional safety and high real-time, low-latency requirements.
Additionally, for global OEMs and Tier 1 suppliers, their process systems and overall product solutions impose stricter functional safety requirements on Safety OS.
However, what is the current situation? Currently, there are no Linux system products applied in autonomous driving that meet ASIL B functional safety. In strict requirements scenarios, everyone still tends to use certified Safety RTOS solutions.
Based on this, a joint initiative was launched in January 2023 regarding the research on functional safety of Linux for autonomous driving, led by Horizon, Changan Automobile, Red Hat Software, and Lingzhu Technology, with over 30 participating units. This work is mainly guided and organized by the Software Subcommittee of the China Automotive Industry Association and the China Automotive Basic Software Ecological Committee AUTOSEMO, and the research report 1.0 was released in September this year. This report focuses on the current industry progress in autonomous driving scenarios both domestically and internationally, and combines the technical dimensions of how to conduct functional safety development and design with the security features of Linux. Additionally, as a continuous effort, a report 2.0 version will be released in the future.
As mentioned earlier, the report is divided into two dimensions: 1) We conduct research on various survey subjects, involving multiple leading players in the industry, regarding the standards related to functional safety and the progress of representative industry products, from OEMs to Tier 1 suppliers to component suppliers; 2) The technical functional safety development process.
Here is a brief introduction to the framework of report 1.0. The entire report is divided into ten chapters, with the first few chapters mainly providing a general overview. The key content starts from Chapter 3, which provides a comprehensive overview of Linux functional safety. From Chapter 4, we conduct thematic analyses of the work mentioned in the overview, including how to combine ELISA and the classic ISO26262 for functional safety-related design and development analysis, and the combination of ISO PAS8926 standard with Linux. Chapter 7 discusses the development process of various modules related to functional safety, and Chapter 8 covers the environments, tools, and toolchains involved in the development process. Chapter 9 discusses how to conduct Linux-related certification, and finally, Chapter 10 summarizes and looks ahead. The appendix includes two technologies involved in the Linux development process, specific module development examples, and how RUST language can be used for kernel security development.
The focus of the ten chapters, particularly Chapter 3, is the most important part of our report’s research. First, we illustrate the scope of functional safety involved in Linux, analyzing why achieving functional safety certification in Linux faces inherent design shortcomings and challenges. We provide an overview of the current progress in the industry from domestic and international perspectives, listing and analyzing from the angles of industry organizations, standards, suppliers, and OEMs.
Chapter 4 begins to delve into specific sections, with the core viewpoint of the ELISA analysis being that functional safety development should be combined with specific scenarios and systems for targeted analysis.
For ISO 26262, the main goal is to achieve ASIL B for Linux, combining the typical automotive software development process such as the V-model, and analyzing how to integrate community development outcomes with Linux.
Regarding the ISO PAS 8926 standard, the new concept it proposes, the pre-existing software architecture element PSAE, is analyzed from multiple aspects, including its impact analysis, practicality assessment, and the scenarios in which the PSAE method is suitable for analysis. The positive significance of this standard lies in providing valuable exploration and reference for how to achieve functional safety in the automotive industry, especially for complex open-source software like Linux.
Chapter 7 begins to combine the functional safety mechanisms provided by the Linux system, analyzing from multiple levels, including kernel security architecture, address space security, memory isolation, and BSP functional safety, providing some analysis examples.
Chapter 8 analyzes our compilation toolchain and some basic libraries, such as security compilation options in the GNU toolchain, mathematical libraries, and the basic libc library.
Chapter 9 provides suggestions and practices for existing Linux functional safety certification from the perspectives of two certification bodies, and concludes with a summary and outlook.
Next, I will introduce key content from the report. First, we analyze the functional safety modules involved in the Linux kernel itself. From the kernel perspective, we can see the classification of 14 kernel subdirectories, and we will break down and analyze the key systems involved, which will be further analyzed in Chapter 7 on safety development.
The report also mentions the classification of various enterprises in the autonomous driving field, including OEMs, Tier 1 suppliers, and component suppliers. In the process of project implementation, different strategies and development approaches for using the Linux system are observed, with varying attitudes, implementation methods, and paces. We see that some OEMs prioritize using Safety RTOS under strict functional safety concepts, while others take a more forward-looking approach by conducting preliminary research projects with suppliers on Linux, expecting to gradually transition to Linux in future project implementations. Some OEMs consider project implementation speed and adopt a microkernel combined with virtualization, enhancing the functional safety of Linux to ensure overall functional safety from a design perspective, meeting relevant requirements. Additionally, some OEMs directly use Linux as the main operating system in the intelligent driving domain, integrating it with their self-developed SoC’s BSP code, upstreaming to the Linux community mainline code, which can be seen from version 5.18 onwards.
From the supplier’s perspective, the demand is more driven by the needs of OEM customers. To meet these demands, various solutions are available, whether from virtualization, multi-system integration, or a single Linux system approach.
Regarding the system on Tesla’s FSD, in terms of vehicle control, cockpit, and intelligent driving, both the cockpit and intelligent driving utilize the Linux system. The intelligent driving function uses Linux to meet the complete solution for perception, decision-making, and control. The most significant feature of the Linux system in Tesla’s FSD is that it does not primarily aim for ISO 26262 certification but focuses on ensuring higher safety through system-level redundancy design.
A typical case from the supplier’s perspective is NVIDIA’s functional safety Linux-related solution discussed at the 2022 GTC conference, which divides the Linux kernel into three parts: Safety, Core, and QM, with the three parts isolated from each other and monitored using a Monitor, ensuring that the Safety part is not affected by the Core context, focusing on how various memory and corresponding isolation mechanisms meet the specific requirements of intelligent driving functions.
Red Hat’s RHIVOS system’s most significant feature is achieving ASIL B on a single Linux system. It analyzes which subsystems in the ADAS application scenario need to meet ASIL B requirements, and Red Hat adopts a continuous certification method, gradually certifying multiple subsystems to ultimately meet ASIL B requirements.
EB’s system adopts a combined solution based on a microkernel system, combined with Hypervisor and security-enhanced Linux. Recently, we saw the latest progress where the Hypervisor has achieved ASIL B certification.
In summary, we currently observe three types of system solutions commonly used in the intelligent driving domain. The first type involves running Linux and RTOS on different cores within a single SoC, where the RTOS interacts with the Linux system that primarily carries the autonomous driving business functions, monitoring and diagnosing the Linux system. This satisfies the safety requirements for the kernel itself, including hardware redundancy and monitoring methods. The second type is a combination of RTOS + Hypervisor + Linux, which is presented in more complex SoCs. The third type includes some models that directly adopt a single-chip Safety RTOS system, with a safety island MCU for interaction and monitoring.
Regarding the well-known ISO 26262 standard, how to combine it with the complex Linux kernel for certification is a common concern. Due to the large code scale of Linux and its development approach, whether regarding documentation output, development, testing, or third-party inspection, it is necessary to consider how to integrate with the V-model, and there are still many challenges. Meanwhile, the third edition of ISO 26262 is currently under revision.
The key concept of PSAE in ISO PAS 8926, how it relates to Linux and the ISO 26262 standard, is also analyzed in the report. Here, we provide some suggestions from the implementation perspective, indicating that the current stage should primarily adopt and reference ISO 26262, given that ISO PAS 8926 was just released. It will take at least 2-3 years for it to be accepted and implemented. There are still many unclear points in software safety design, secure coding, and practical operations, and the practices of various units in the industry vary, such as how to judge the effectiveness and comprehensiveness of isolation mechanisms and software monitoring mechanisms. We will continue to follow up and analyze from report 1.0 to 2.0 in the subsequent stages.
Chapter 7 mainly combines how the Linux kernel security mechanisms integrate with functional safety development, providing some analysis. This includes analyzing from the perspectives of address space security, response time safety, timing safety, data integrity, communication to boot security, and how to ensure overall functional safety, including how to handle fault diagnosis in redundancy design, but due to time constraints, I will not elaborate on the details.
In the certification section, the report lists two certification bodies, providing suggestions and practices for how Linux can conduct functional safety development, including three methodological recommendations: strictly following Part 6 of the ISO 26262 standard for software development, adopting software component identification methods, and using proof of use methods.
The final summary of the report proposes some thoughts on Linux safety compliance in design and development, mainly consisting of four steps. The first step focuses on enhancing functional safety for individual Linux systems. The second step targets ASIL B, combining the Hypervisor base to support functional safety isolation and monitoring for the Linux system. We see that the mainstream implementation solutions in the industry combine the first and second steps. The third step involves some enterprises and organizations currently implementing certification work in this manner, mainly referencing ISO 26262 and the national standard 34590 guidance, decomposing the Linux kernel into SEooC forms for functional safety transformation and continuous certification for individual subsystems, tackling large complex software and monolithic kernels one by one. The fourth step involves integrating the necessary SEooC subsystems in the kernel into a complete functional safety Linux product and distribution, specifically targeting the mass production implementation of intelligent driving solutions. The report also mentions the overall timeline, predicting that this issue may be resolved in about 2-3 years, around 2026.
Finally, regarding the development suggestions for Linux, from the present to 2026, there are still opportunities and windows for products corresponding to Linux functional safety requirements. This is also a foundation for all of you present, whether you are customers from OEMs or suppliers, to jointly research this field.
Specific technical design suggestions for how Linux can achieve functional safety include spatial isolation, temporal isolation, ensuring reliability and integrity in communication, and ensuring that all activities, memory allocations, etc., are traceable and monitorable.
Subsequently, multiple levels of ecological cooperation will be necessary, and the good resolution of this issue relies on the joint cooperation of the upstream and downstream of the industry.
Some matters that were not emphasized in this report 1.0 will be analyzed in the subsequent 2.0 phase. For example, whether the Linux kernel for autonomous driving should be upstreamed, how to upgrade the Linux kernel under the OTA method in vehicles, the matching of computing chips and Linux kernel versions, and the integration of the overall vehicle software system, as well as the timing issues. The commercial model of open-source Linux applied to autonomous driving products and its integration with the automotive industry are not functional safety topics, but they are also issues that need to be addressed in the process of Linux implementation, which will require further analysis in the report 2.0 phase.
My report ends here, thank you all!
“
(Note: This article is organized based on on-site shorthand and has not been reviewed by the speaker.)
Note:
For the complete 36-minute speech video, click the link below. If you cannot access it successfully, please contact the editor for learning materials, for reference only!
