1. Automotive Operating System
Automotive operating systems include safety vehicle operating systems, smart driving operating systems, and smart cockpit operating systems.
1. Secure in-vehicle operating system
The safe on-board operating system is mainly oriented to the field of classic vehicle control, such as power system, chassis system and body system. The application object is an electronic control unit (ECU). The embedded real-time operating system has the advantages of high reliability, real-time, interactivity and multi-channel. The system response is extremely high, usually at the level of milliseconds or microseconds, which meets high real-time requirements.
Currently, mainstream safety vehicle operating systems are compatible with two types of automotive electronic software standards, OSEK/VDX and Classic AUTOSAR. Among them, the Classic platform is based on the OSEK/VDX standard, which defines the technical specifications for a safe vehicle operating system.
2. Intelligent driving operating system
The intelligent driving operating system is mainly oriented to the field of intelligent driving and applied to the intelligent driving domain controller. This type of operating system has high requirements on safety and reliability, as well as high requirements on performance and computing power. The safe on-board operating system based on OSEK/VDX and Classic AUTOSAR software architecture can no longer meet the development needs of future self-driving cars. The AUTOSAR organization launched the Adaptive AUTOSAR platform for a centralized electrical and electronic architecture for more complex domain controllers and central computing platforms.
The definition of Adaptive AUTOSAR adopts the operating system based on the POSIX standard, which can provide standardized platform interfaces and application services for the operating system supporting the POSIX standard and different application requirements, mainly to meet the development needs of automobile intelligence. However, this type of operation The system is currently becoming more mature around the world, but the ecology is not yet complete.
3. Smart cockpit operating system
The smart cockpit operating system mainly provides a control platform for automotive infotainment services and in-vehicle human-computer interaction. It is an operating environment for automobiles to realize cockpit intelligence and multi-source information fusion. The requirements for real-time performance and reliability of the operating system are not strict.
The smart cockpit operations of mainstream models mainly include QNX, Linux, Android, etc. QNX occupies the vast majority of the traditional smart cockpit operating system. In recent years, the entertainment and information service attributes of the smart cockpit have become more prominent. Android, which has a large number of mature information service resources, is favored by many OEMs and has become a rising star.
2. Vehicle operating system
The smart cockpit operating system in the automotive operating system does not directly participate in the control decision-making of the car, and will not affect the driving performance and safety of the vehicle. It is generally referred to as the in-vehicle infotainment system (IVI). This is also the main area of responsibility of Android programmers, and the focus of our study will be later.
1. Mainstream vehicle operating system structure
figure 1
The current domestic mainstream vehicle operating system architecture is shown in Figure 1. The right side is the car’s central control and co-pilot screens. The operating system is generally Android. The left side is the car’s instrument screen, which is generally QNX system. It can be understood corresponding to Figure 2, the red frame is the display of the embedded system of the instrument, and the yellow frame is the display of the central control and co-pilot Android system.
figure 2
2. Vehicle system analysis
image 3
Figure 3 In the car structure diagram, the structure in the red frame is similar to that of the android mobile phone system, the difference is that a large number of Android system services (services) of the car system will be cut, and a large number of additional exclusive car services (services) will be added.
The yellow box is the Native middle layer, including HAL (Hardware Abstraction Layer) and Android BSP (Board Support Package) , which play a link between the preceding and the following.
The hardware abstraction layer is an interface layer between the Android operating system kernel and the hardware system in Figure 3, and its purpose is to abstract the hardware.
It hides the details of the hardware system interface of a specific platform, provides a virtual hardware platform for the operating system, makes it hardware-independent, and can be transplanted on various platforms. From the point of view of software and hardware testing, the testing work of software and hardware can be completed based on the hardware abstraction layer respectively, which makes it possible to carry out parallel testing of software and hardware.
The HAL layer is a software layer that the upper-layer application shields the operation of the underlying hardware, that is, the upper-layer application does not need to care about how the underlying hardware works, and only needs to call the unified interface provided by the underlying layer. The HAL layer is connected to specific hardware BSP interfaces, such as audio and video interfaces, radio interfaces, network interfaces, spi interfaces, etc.
Board Support Package ( BSP ) (Board Support Package) is the bootloader (Bootloader), kernel (Kernel), root file system (Rootfs) and toolchain (Toolchain) required to build an embedded operating system. Provide a complete software resource package .
As a realization of hardware abstraction layer, board support package BSP (Board Support Package) is a scheme adopted by most existing commercial embedded operating systems to realize portability. BSP isolates the correlation between the supported embedded operating system and the underlying hardware platform, so that the embedded operating system can be commonly used on the hardware platform supported by BSP, thereby realizing the portability and cross-platform of the embedded operating system. And the versatility and reusability of the embedded operating system.
Since both belong to the middle layer, what is the difference between the HAL layer and the BSP layer?
Just imagine, in the development of large-scale projects, if the program only has simple function encapsulation, once the hardware changes, we will need to make large-scale changes to the BSP (board support layer), which will undoubtedly be a huge burden on program maintenance.
After introducing the concept of HAL (Hardware Abstraction Layer), the HAL library further encapsulates the BSP library to form a unified standard. When we change the hardware circuit part next time, we only need to change the specific function of the BSP library instead of Any modifications to the application layer are required.
This is the embodiment of layered thinking.
Going down is the underlying hardware and embedded system enclosed by the green box .
Among them, the embedded system generally adopts QNX embedded system, which is a commercial Unix-like real-time operating system, mainly aimed at the embedded system market. The system adopts a micro-core architecture, and most of its functions are run by small tasks. Called server, this architecture allows users or developers to turn off unnecessary functions without changing the operating system itself.
QNX is widely used in fields that require high safety and real-time performance, such as automobiles, rail transit, and aerospace, and has a very high market share in the automotive field. The product was developed in the early 1980s and later changed its name to QNX Software Systems, which has been acquired by BlackBerry.
The upper-layer application of the instrument on the left side of Figure 3 also controls the hardware through the underlying embedded system of QNX. However, QNX generally implements relatively small functions, such as opening the car window, turning off the air conditioner, etc., which is not suitable for making beautiful interfaces and complex operations . wait.
Therefore, the Android system is added to the right center console to display the interface and perform complex operations of human-computer interaction functions.
In short, the Android in-vehicle system can be regarded as a virtual system running on QNX. The underlying technical principle is the Hypervisor, an intermediate software layer running between the basic physical server and the operating system, which allows multiple operations System and applications share hardware. It can also be called VMM (virtual machine monitor), that is, a virtual machine monitor.
Further down, we come to the hardware implementation part . Let us study together how the QNX embedded system realizes the control hardware interaction.
It can be seen from Figure 3 that the SOC interacts with the QNX system, so what is the SOC ?
Generally speaking, SoC is called a system-on-chip, also called a system on a chip , which means that it is a product, an integrated circuit with a dedicated purpose, which contains a complete system and all the content of embedded software . At the same time, it is also a technology to realize the whole process from determining system functions, to software/hardware division, and to complete the design. See Figure 4 for the real object, Qualcomm Snapdragon 8155 SoC chip.
Figure 4
In a narrow sense, it is the chip integration at the core of an information system, which integrates the key components of the system on a chip; in a broad sense, SoC is a tiny system. If the central processing unit (CPU) is the brain, then SoC It is the system that includes the brain, heart, eyes and hands.
The car SoC is very similar to the common mobile phone SoC, integrating CPU and GPU inside.
At present, the most mainstream vehicle-mounted SoC is Qualcomm's SA8155P (8155 for short), which is developed by Qualcomm on the basis of the mobile phone SoC Snapdragon 855.
It is manufactured using a 7-nanometer process, has eight cores, and has a computing power of 8TOPS, which means 8 trillion operations per second. It can support up to 6 cameras, connect 4 2K screens or 3 4K screens, support WiFi6, support 5G, support Bluetooth 5.0.
In addition, compared with 820A, 8155 also adds NPU (neural network processing unit) , which is responsible for some tasks of vehicle AI calculation, so that CPU can focus more on other important tasks.
We know that MCU, that is, the microcontroller unit, is responsible for a large part of the functions of the car, such as analyzing and processing various data through the on-board controller to make optimal decisions; responsible for the infotainment interaction and motion control of the vehicle, Such as opening the car window, turning off the air conditioner, etc., that is, the MCU can be applied to the communication, energy, storage, perception and calculation of the vehicle, which plays an important role in the automotive industry.
The SoC chip integrates the functions of many MCUs . The previous work done by multiple MCUs is integrated, and the MCU is gone. It is replaced by external IO pins. Connecting the IO pins can realize interaction and complete the previous MCU. function.
The SoC sends and receives data signals with the MCU through the SPI protocol ( Serial Peripheral Interface ), and the MCU controls the hardware to perform actions through the CAN bus , such as opening the car window and turning off the air conditioner.
Among them, CAN Controller Area Network ( CAN or CAN bus for short ) is a vehicle bus standard with rich functions. It is designed to allow microcontrollers and instruments on the network to communicate with each other without the need for a host. It is based on a messaging protocol and was originally designed to use multiplexed communication cables in vehicles to reduce copper wire usage, and has since been adopted by other industries as well.
CAN is a very important serial communication bus in the vehicle field. We can view and set the door, engine, and trunk modules at any time on the central control screen. In fact, it is realized with the help of CAN bus. Even Android programmers often need to Deal with it, and I will talk about this thing in detail later.
3. Android Automotive platform
Android Automotive is a full-stack, open source, and highly customizable platform implemented through Android's common framework, language, and API.
1. The relationship between Android Automotive and the entire Android ecosystem
- Android Automotive is the Android platform .
It is not a fork or parallel development of Android, it has the same codebase and is in the same repository as Android on Android devices like phones, tablets etc. Based on a robust platform and feature set developed over 10 years, it leverages existing security models, compatibility programs, developer tools and infrastructure while continuing to be highly customizable and portable, completely free and open source .
- Android Automotive extends the Android platform .
As we build Android into a full-featured infotainment platform, we've added support for car-specific requirements, features, and technologies. Android Automotive will be a one-stop in-vehicle infotainment platform, just like Android is for mobile devices today.
2. Android Automotive Architecture
Figure 5
Android Automotive adds some car-related modules (green background in the dotted box in Figure 5) to the original Android system architecture:
1) Car App: including Apps developed by OEMs and third parties
2) Car API: Provide specific interfaces for automotive Apps
3) Car Service: Car-related services in the system, mainly based on CarProperty to implement Vechile-related strategies
4) Vehicle Network Service: The network service of the car
5) Vehicle HAL: The hardware abstraction layer description of the car, defining the interface of the vehicle attributes that the OEM can implement
Refer to Figure 6, the green is the Android native function module, and the blue is the Android Automotive added function module.
Figure 6
4. Vehicle application
1. SystemUI
That is, the UI of the system.
SystemUI is a standard android application that provides a unified management solution for the system UI. A series of background pop-up windows such as the common status bar, navigation bar, message center, volume adjustment pop-up window, and Bluetooth connection pop-up window are all managed by the SystemUI module.
Development Difficulty: SystemUI, as the first application with UI started by the Android system, has high requirements for startup performance and stability. SystemUI needs to manage a lot of modules, which leads to heavy development tasks. Some vehicle projects require SystemUI to be compatible with the original application layer API, so the difficulty of development will increase. Developers need to have a certain understanding of Android's native SystemUI source code.
2. Launcher
The desktop of the Android system.
Difficulty of development: Launcher is one of the applications that interact with users the most, and it also has high requirements for startup performance and stability. The difficulty of Launcher development is mainly focused on the interaction with the 3D car model (if there is a 3D model), it may need to support the display of Widget (WidgetHost), dragging and editing of various applications, etc. It is best for developers to have a certain understanding of the Android native Launcher source code.
3. Settings
system settings.
It is a very important system-level application in the vehicle Android system. It is the control center of the entire vehicle IVI system. The sound effects, wireless communication, status information, safety information, etc. of the vehicle need to be viewed and controlled through system settings.
Development Difficulty: The main difficulty of system settings is focused on the understanding of Android Framework layer APIs, such as Bluetooth and Wi-Fi settings, which require developers to have a certain understanding of system-level APIs, which often require reading the source code of Android native applications Only then can we understand, so the system setting is also an in-vehicle application that is relatively difficult to develop.
4. CarService
One of the core services of the car Android system.
All applications need to query and control the status of the vehicle through CarService. For example: vehicle speed, gear position, ignition status, etc.
5. VehicleSettings
Vehicle settings, more commonly known as "vehicle control vehicle settings".
Responsible for managing the application of the entire vehicle's internal and external settings, mainly for data interaction with CarService. There are many configurable items. Driving mode, steering wheel power assist, rearview mirror folding, ambient light, cockpit monitoring, wireless charging, etc.
Difficulty of development: The main difficulty lies in the complex and changeable UI. Some host manufacturers will introduce 3D interactive models into the HMI, and they also need to consider the communication with the 3D model. At the same time, they need to be proficient in using CAN tools to simulate the movement of the car. CAN signals are used for debugging and development.
6. HVAC
air conditioner.
Responsible for managing the application of the entire vehicle air conditioner, mainly for data interaction with CarService.
Development Difficulty: Similar to "Vehicle Control Device".
7. Map
map.
One of the core functions of the vehicle system, responsible for functions such as navigation and voice prompts. Different host manufacturers have different development methods. There are three kinds:
1) Choose to use the map SDK of Baidu and Gaode to develop the navigation application by itself;
2) Outsource the navigation module to Baidu and Gaode, and the map supplier will carry out customized development;
3) Directly integrate the existing car version of the map supplier application;
Development Difficulty: Mainly focus on the application and understanding of the map SDK, and the map application is a module with high performance requirements.
8. Multi-Media
multimedia applications.
Generally, it includes picture browsing, online audio and video player, USB audio and video player, radio, etc.
The in-vehicle applications are much more than the ones mentioned above. According to different needs, there are still many services that need to be customized. Here are only the most common types of applications.
There will also be some third-party applications on the car, the common ones are QQ Music, WeChat, QQ, Douyin, Xunfei Input Method, etc. The host manufacturers of these applications will not obtain the source code, and generally only get an apk for direct integration Just go to the Android system.
References:
Soc (system-on-a-chip) - Wikipedia
SPI (SPI protocol)_360 Encyclopedia
Vehicle system development - Android Automotive - Programmer Sought
How much do you know about automotive operating systems?
What is the magic of Qualcomm Snapdragon 8155? _Qualcomm 8155_aFakeProgramer's Blog-CSDN Blog