Author| Golden Monkey
Produced | Yanzhi Automobile
Zhiquan | Into the camera lens / module / CMOS chip group, add micro yijijuechen2023
The core of the underlying software for intelligent driving is its operating system, which mainly runs on the intelligent driving domain controller and supports the high-performance computing and high-bandwidth communication heterogeneous chips required for autonomous driving. Considering that the smart driving system itself has high requirements for safety, real-time and reliability, such requirements will also be simultaneously loaded on the underlying operating system performance and computing power. For example, in order to meet the requirements of fusion perception and decision-making computing, the operating system needs to have powerful computing capabilities; in order to meet the real-time access and processing of multi-sensor data, a strong data throughput is required; finally, in order to meet the needs of various algorithm models , high ecological compatibility and scalability are also necessary requirements.
Differences between Linux and QNX
At present, there are two main development paths for the core of the intelligent driving operating system in the industry (of course excluding some self-developed types, such as Huawei's AOS). One is an operating system developed based on pure Linux native code grafting. There is also a derivative version of this category, which is an enhanced security Linux operating system developed for functional safety level ASIL B, which inherits the rich open source ecology of Linux, based on the powerful open source Linux macro kernel, and focuses on enhancing its security and real-time performance. .
The other is the QNX operating system that is more respected in the industry. This operating system is mainly a commercial real-time operating system provided by Blackberry Limited. It is a Unix-like operating system. The kernel used in this operating system is a microkernel.
Overall, the overall differences between Linux and QNX are as follows:
The target system types for Linux are embedded systems, mobile devices, personal computers, servers, mainframes, and supercomputers. The computer architectures supported by Linux are IA-32, x86-64, ARM, PowerPC, and SPARC. Its kernel type is Monolithic. Its native API is LINUX/POSIX. It has a preferred license of GNU GPLv2 (kernel). The non-native APIs supported through its subsystems are Mono, Java, Win16, and Win32. The file systems supported by Linux are ext2, ext3, ext4, btrfs, ReiserFS, FAT, ISO 9660, UDF, and NFS.
QNX's target system types are automotive, medical, smartphone, consumer, industrial, embedded systems, and security. The computer architectures supported by QNX are x86, SH-4, PowerPC, ARM, and MIPS. Its kernel type is microkernel. Its native APIs are POSIX and Java. It has a proprietary preferred license and its subsystems do not support non-native APIs. The file systems supported by QNX are QNX4FS, QNX6, ext2, FAT, ISO 9660, Joliet, NFS, CIFS, ETFS, UDF, HFS, HFS+ and NTFS.
In this regard, QNX mainly supports the Cortex-A series (ARMv7 or ARMv8 and subsequent), and does not plan to support the Cortex-M and R series (especially MCUs without MMU low frequency, etc.) to support the X86 series. In this regard, QNX is slightly inferior to Linux.
It can be said that QNX is a commercial real-time operating system that complies with the Posix standard. Linux is a general-purpose open-source operating system kernel that is not officially Posix-compliant. In fact, to developers, both feel like Unix. However, considering the different requirements for the development of intelligent driving systems, the application scenarios of the two are also different.
In addition, the QNX operating system has passed TÜV Rheinland's basic functional safety certification IEC61508SIL3, the highest level of road vehicle functional safety ISO 26262 AISL D standard, medical industry IEC62304 and railway EN50128 functional safety certification. The scope of certification includes tool chain TCL3 certification, Neutrino microkernel, APS adaptive partition scheduling, libc, libm and libsupc++ libraries, etc.
Therefore, it can be seen from the comparison of the above aspects that Linux still has certain disadvantages in adapting to self-driving cars. From the perspective of at least meeting functional safety ASIL B, QNX can meet the functional safety level of the intelligent driving system, but Linux cannot meet the performance indicators.
The current status of the use of Linux and QNX in the field of intelligent driving
The reasons for using Linux in the development of smart cars are mainly based on the following reasons:
Linux has a variety of programming languages and development tools. Such as gcc, cc, C++, Perl, Fortran77, etc. The interface and software adaptability to different development platforms will be better. Since most of the Linux kernel is written in C language, and adopts the portable Unix standard application program interface, and supports i386, Alpha, AMD, Sparc and other system platforms, it can well support the control of related embedded devices such as on-board smart cars .
At the same time, Linux is a truly multi-tasking and multi-user operating system. Developers can configure the required permissions for the resources they need. This method allows multiple applications to call operating system resources at the same time without affecting each other. Moreover, since the source code in Linux is optimally designed with a standard 32-bit computer, it can basically ensure the stability of the system and is not prone to downtime.
In addition, it is quite important that tools such as firewall, intrusion detection, and security certification built into Linux can also meet the needs of network security in many cases. In terms of processor support, Linux can support Cortex-A & M and X86 series, and its support is relatively comprehensive.
Based on the above reasons, the Linux system is widely used in the current intelligent driving industry.
operating system |
factory |
Linux |
NIO, Xpeng, SAIC MAXUS, FAW Hongqi, Human Horizons, GAC, Hongjing Zhijia |
QNX |
Didi, Desay SV, Mode Smart, some foreign OEMs |
Security defects of Linux in smart driving design
Compared with the Internet industry, the indicators of special concern in the field of autonomous driving include functional safety. And Linux is still quite immature in terms of functional safety. Mainly reflected in the following aspects:
1. Functional security of virtualization
Linux uses Open Source/GPL2/3; Monolithic kernel.
First of all, GPL can allow users to maximize the authorization of the products used, ensuring that users can obtain freely distributed products that can be run, copied, researched and improved. Therefore, for open source products such as Linux, allowing development community engineers to arbitrarily inject unstable or buggy program codes may lead to sudden system crashes, which naturally cannot meet functional safety requirements.
2. The security of the operating system itself
In addition, from the perspective of operating system functional safety, operating systems such as Linux are designed based on the macro-kernel architecture, and their hard real-time problems and open source version branch maintenance problems are quite obvious. May meet the exposure, severity, and controllability requirements in functional safety. However, in-depth customization has extremely high requirements for the team, which is almost impossible for the autonomous driving R&D team.
3. Graphics function safety
The graphics processing function of Linux mainly refers to that the image processing software modules basically do not have relevant functional safety certification. Therefore, the use of Linux in the process of image analysis and processing cannot guarantee its functional safety.
In addition, there are as many as 25 million lines of Linux source code. Generally, the project development team of Zhijia System Company does not have the ability to tailor Linux, and the overall identification is difficult. At the same time, the requirements for software architects are relatively high, and software security analysis for Linux systems is required. And the difficulty of the design process will increase.
At present, no one in the industry that uses the Linux operating system has passed the functional safety certification. It is difficult for the industry to develop Linux systems to achieve ASIL B. Mainly reflected in the following points:
1. Missing process documents
First of all, Linux system software lacks requirements and architecture documents, and the consistency of requirements, architecture, and design codes cannot be traced. At the same time, software lacks safety analysis, including FMEA analysis, without identifying failure modes. The Linux software monitoring process does not perform a reasonable ASIL decomposition, and additional consideration of independence is required.
2. Hard real-time performance cannot be fully guaranteed
It is difficult to guarantee hard real-time performance in the process of Linux system development, and the cost of code transplantation is high. The real-time kernel cannot show superiority on Linux, and the software in the Linux kernel cannot satisfy security.
3. Large testing workload
The overall coding rules of Linux do not conform to ISO26262, especially for functional safety, which needs to be cut to a certain extent. The workload of code is relatively large, and the workload of unit testing is also relatively large.
Improving the design method of Linux defects in intelligent driving system
Of course, there are also some manufacturers, tier1 or tier2 on the market who are considering improving the Linux system to a certain extent. Implement strategies for functional development and security enhancement of the Linux Guest OS.
For example, the ELISA project (https://elisa/tech/) has been working on how to certify the Linux system as ASILB; and the project is currently in progress. The SIL2 LinuxMP project (http://sil2.osadl.org) has also been developed. Many other projects also refer to the results of this project, including the content related to development tools, but they have not been certified as B. In addition, the Bosch V2x project has also done similar research, but has not completed the corresponding certification.
To sum up, the security method adopted for Linux is nothing more than making different coping strategies for its baseline selection, requirement definition, reduction/configuration, and security analysis.
First of all, the baseline selection generally selects the LTS version of the open source community as the baseline source, refers to the industry's mainstream version baselines such as: redhat/windriver, and takes the BSP support of the target chip as a reference. Major function updates and vulnerability updates need to be carried out in real time. At the same time, use the method of analysis + review to verify the results of the selection.
Second, the important part includes requirements definition. For example, from product requirements to Linux memory allocation, it is necessary to optimize task scheduling, process management, and memory management, and effectively define target ASIL levels, Failsafe, FTTI, etc. At the same time, properly select the SOC and have Safety manual. The effective implementation of external security mechanisms (such as program flow monitoring, data flow monitoring, redundant computing, redundant storage, etc.) is also very important. An efficient inspection method is required to verify the requirements. Of course, refining based on requirements and extracting effective data flow and control flow for analysis and verification is also an important part of Linux security analysis.
Finally, two aspects of configuration reduction are involved, and the kernel is trimmed according to the Strace information of demand analysis through efficient configuration tools (such as OSADL Minimization tool), and the kernel is configured according to the best time or product characteristics, and finally based on inspection and analysis The method to configure and verify the kernel.
In addition to the measures listed above, Linux can also be used as a software component for software component identification (ASIL B), but this type of identification is not suitable for the identification of very large software codes, and related standards are still being formulated in process.
Generally speaking, this kind of modification may cause the system software to be unable to continue to show the superiority of conventional Linux after the modification to a certain extent. And to a certain extent, there will be shrink-packed Linux software packages, which can be executed on any hardware without any restrictions, and can also be used for application restrictions that require high safety.
As shown in the figure above, in a typical intelligent driving system, Linux is used as the overall process description of the operating system to communicate between cores. The functional safety strategy of Linux is mainly to detect software errors in the Linux kernel space through in-kernel or inter-kernel diagnosis. Then, a complete diagnostic process is implemented by collecting software errors between cores and in user space. In addition, the software test library and the main CPU core on the safety island realize continuous monitoring of potential hardware errors. These hardware errors may occur during power-on or during operation, and the errors are reported to the corresponding diagnostic modules. At the same time, the safety island diagnosis module and the safety main CPU core diagnosis process module can report software errors to the MCU diagnosis module.
Analysis of the advantages of QNX application in intelligent driving system
Under normal circumstances, whether the functional safety level of the autonomous driving system can be achieved can be decomposed from the bottom up into the hardware driver layer, hardware abstraction layer, operating system layer, real-time scheduling layer, inter-core communication layer, and application software layer. As another operating system used in the field of smart driving, QNX adopts Hypervisor virtualization technology that has passed the ISO 26262 ASIL D standard, the highest level of road vehicle functional safety certified by TUV Rheinland. The scope of certification includes tool chain TCL3 certification, Hypervisor and OS kernel, APS, Libc, libm, libsupc++, vdev, SMMU, etc.
The figure below shows the achievement of the functional safety goals of the entire software architecture.
Among them, most software modules can meet the functional safety goals through certain means, but the operating system is developed with reference to the Linux infrastructure, which cannot meet the functional safety requirements. Because whether it is from the basic requirements of functional safety to the operating system or the value-added requirements, it cannot meet the corresponding performance index requirements.
On the other hand, the QNX Platform for Dashboards is built on BlackBerry QNX's highly optimized OpenGL-based graphics framework for automotive dashboard reference hardware, supported by a leading cluster UI framework. What's more, the QNX instrument cluster platform also offers an ISO 26262 ASIL B pre-certified graphics monitor subsystem. ISO 26262 ASIL D pre-certified RTOS and toolchain for BlackBerry QNX.
As a member of the ISO/SAE 21434 global standard for network information security (basic software group, the only operating system supplier), QNX will pass the highest level of network information security of ISO/SAE21434 CAL4 after the standard is officially released in 2021. Network information security modules include QNX SDP 7.0, Certicom (for Onstar), larvis, BlackBerry Cybersecurity Service, etc.
Then QNX has so many benefits. If the current development team considers replacing Linux with QNX, what aspects need to be considered and what impact will it have on security?
1. How to implement memory protection?
Linux also supports process and thread design, and its protection strategy is the same as that of QNX, but it has not passed functional safety certification. Therefore, it is necessary to do "redundant storage + verification" at the application layer to achieve security protection. This process may double the memory and computing power. At the same time, it needs to be confirmed whether there can be a hardware MPU (reasonable OS is called) to ensure safety.
2. How to realize the functional module partition design?
Linux needs to confirm whether the priority of processes and threads can be configured, threads have interfaces to the application layer, and process design requirements include application layer configuration and interface design.
3. Does the software architecture design need to be readjusted?
For the switching process of the operating system, in fact, the application layer does not need to be refactored, but the BSP part needs to be adjusted according to QNX.
4. Is task scheduling or thread polling affected?
Since the task scheduling of Linux has not passed the functional safety certification, the execution cycle of the watchdog monitoring task also needs to be further optimized. At the same time, it is also necessary to strengthen the protection measures of the message queue. For example, the communication between processes adopts the method of "reading" shared memory and disabling the write permission, and formulates corresponding protection measures.
5. File system and time management strategy?
Finally, all tasks can be implemented in the form of reference files. System time management: Whether the clock, system time, timer, etc. are completely irrelevant to functional safety also requires a certain degree of verification analysis.
Summarize
The core of the intelligent driving operating system is based on the standard POSIX interface, compatible with international mainstream system software middleware such as Adaptive AUTOSAR, and meets the functional safety and information security requirements required by different applications of intelligent driving. Considering the current mainstream smart driving operating system capabilities, we can formulate different strategic requirements and value-added different R&D methods according to our own R&D capabilities. The ultimate goal is to apply the unit architecture and bearing functions of the SOC heterogeneous hardware of the intelligent driving system to meet the different requirements of functional safety: the AI unit kernel system supports QM ~ ASIL B, the computing unit kernel system supports QM ~ ASIL D, and the control unit kernel system needs to support ASIL D safety level.
Scan and join the free "Smart City Smart Transportation" knowledge planet to learn more industry information and materials.
Welcome to the Intelligent Transportation Technology Group!
Contact information: WeChat ID 18515441838