Intelligent cabin control method and system

Abstract

The application discloses an intelligent cockpit control method and system, and relates to the intelligent vehicle and control fields.The intelligent cockpit control method of the application is aimed at the shortage of the OpenHarmony operating system, and the display operation of the vendor part of the display is partially rewritten, so as to make up for the shortage of the original native Hongmeng in the display aspect, solve the technical problems of the split function of the display card and the limitation of the multi-screen, and realize the display of one main and multiple auxiliary, and the number of auxiliary displays is greater than 2.In addition, the intelligent cockpit control system of the application proposes scene applications such as green travel, driver management, accurate command and traffic intelligent perception for the public transport and commercial vehicles, so as to widen various applications of the original native Hongmeng in the public transport and commercial vehicle fields, solve the problem of the crowd travel planning, increase the management function of the driver, and make the public transport and commercial travel more comfortable.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicles and control, specifically to an intelligent cockpit control method and system. Background Technology

[0002] New energy vehicles (NEVs) refer to automobiles that are driven by electric motors and powered by energy storage devices (such as batteries). They mainly include battery electric vehicles (BEVs), plug-in hybrid electric vehicles (PHEVs), and extended-range electric vehicles (EREVs). In recent years, with breakthroughs in battery technology, NEVs have experienced tremendous growth. In 2024, national sales of NEVs reached 12.866 million units, and by the end of 2024, the total number of NEVs in use exceeded 31 million, accounting for approximately 8.9% of the total vehicle fleet. According to the China Association of Automobile Manufacturers (CAAM), sales are projected to exceed 16 million units in 2025, reaching a penetration rate of 55%. NEVs comprise several key components, including intelligent cockpits, chassis systems (including batteries), and powertrain systems. With powertrain and battery technologies becoming increasingly homogenized, automakers are focusing on "intelligent cockpits" as a key element to enhance product competitiveness.

[0003] A smart cockpit refers to a system that deploys various information display, sensing, interaction, and cloud service technologies within a car's driver's cabin to achieve comprehensive intelligent interaction between people, vehicles, and the environment. Driven by both "intelligentization" and "connectivity," it upgrades traditional hardware such as dashboards and air conditioning controls into a digital platform that can be defined by software and continuously updated via OTA. It provides multimodal interaction through voice, gestures, facial recognition, and iris scanning, and enables personalized assistant functions through large-scale models. With its large screen, multimodal interaction, and AI voice assistant, the smart cockpit provides users with a "third space"-like driving experience and has become an essential feature of new energy vehicles.

[0004] The intelligent cockpit has been upgraded from a "digital dashboard" to a full-stack platform integrating perception, interaction, and cloud services, and is becoming a key entry point for differentiated competition in the automotive industry. With the improvement of computing power, the rise of domestic chips, and the implementation of large-scale model technology, the cockpit penetration rate will continue to increase rapidly, and in the future it will deepen into the "third living space", forming a closed-loop ecosystem of software and hardware, and in-vehicle and out-of-vehicle services. However, the existing intelligent cockpit still has the following shortcomings: (1) Difficulty in multi-screen / multi-modal integration: Due to the higher requirements of the "one chip, multiple screens" solution for the SoC's multiple interfaces and high-performance CPU / GPU, the existing chips are still insufficient in terms of multi-screen driving and virtualization support; (2) The current intelligent cockpit has done a lot of research in control, display and multimedia, but lacks in-depth customized applications, such as some in-depth development in various application scenarios, such as in-depth application development for buses, and in-depth application development for commercial vehicle dispatching, etc.

[0005] Therefore, it is still necessary to develop several new intelligent cockpit control methods and systems to address the current shortcomings and deficiencies. Summary of the Invention

[0006] In view of this, the main objective of this application is to provide an intelligent cockpit control method and system, in order to at least partially solve the above-mentioned technical problems.

[0007] To achieve the above objectives, as a first aspect of this application, a smart cockpit control method is proposed. The smart cockpit uses the OpenHarmony operating system. When sending the system-rendered screen to the vendor's implementation layer of the display device, the smart cockpit control method uses the vertical blanking signal of the main screen as the hardware vsync signal source, and the frame rate of the secondary screen is maintained at half of the main screen's frame rate. The smart cockpit control method includes the following steps:

[0008] Each display unit reported by the DRM driver is split into two logical displays;

[0009] Determine whether the two logical displays of the display unit have been written to the corresponding frame buffer. If not, wait until the writing is complete.

[0010] The contents of the frame buffer are bound to different hardware planes respectively, and the one-time write hardware operation of the DRM driver is executed uniformly to realize the split-screen mode of the vendor delivery step.

[0011] Furthermore, the intelligent cockpit control method further includes any of the following steps:

[0012] (1) In the last OnVsync call triggered by external vsync, call RequestNextVsync one more time;

[0013] (2) After the rendering service finishes processing a frame, check if there are any unsent sub-screen frames. If so, call RequestNextVsync once and mark it as a supplementary frame.

[0014] (3) Use setVsyncRate to configure the secondary screen to generate one software clock simulation trigger signal for every two hardware clock trigger signals, so that the system will automatically generate one software clock simulation trigger signal in each odd / even cycle, where the number of secondary screens is greater than 2.

[0015] As a second aspect of this application, a smart cockpit control method is also proposed. The smart cockpit uses the OpenHarmony operating system and employs the smart cockpit control method described above to control the display operation of the display in the smart cockpit. The smart cockpit control method includes the following steps:

[0016] The location information of the intelligent cockpit is collected through the positioning module;

[0017] The geographical location information is transmitted to the public transport cloud platform through the first communication module; the arrival information of the intelligent cockpit calculated by the public transport cloud platform based on the geographical location information is received;

[0018] The arrival information is displayed on the screen of the smart cockpit.

[0019] As a third aspect of this application, a smart cockpit control system is also proposed. The smart cockpit uses the OpenHarmony operating system and employs the smart cockpit control method described above to control the display operation of the displays within the smart cockpit. The smart cockpit control system includes:

[0020] The positioning module is used to collect the geographical location information of the smart cockpit;

[0021] The first communication module is used to transmit the geographic location information to a public transport cloud platform and receive the smart cockpit arrival information calculated by the public transport cloud platform based on the geographic location information.

[0022] The display module is used to display the arrival information.

[0023] Based on the above technical solution, the intelligent cockpit control method and system of this application have at least one of the following beneficial effects compared with the prior art:

[0024] (1) This application makes up for the shortcomings of native HarmonyOS in camera acquisition and display, solves the technical problems of adapting to the graphics card split function and multi-screen limitation, and can realize one main and multiple auxiliary displays with more than 2 auxiliary displays;

[0025] (2) This application expands the application scenarios of native HarmonyOS, enriches the various applications of intelligent cockpit in the fields of public transportation and commercial vehicles, solves the actual needs of the public for various rides, makes route planning more scientific and efficient, and also increases the management and personalized service functions of drivers, making public transportation and business rides more comfortable. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below.

[0027] Figure 1 This is a diagram of the OpenHarmony display system composition of this application, and a display architecture diagram in the OpenHarmony main documentation;

[0028] Figure 2This is a simplified logical architecture diagram of the software framework of the OpenHarmony display system of this application;

[0029] Figure 3 This is a schematic diagram illustrating the application scenario of this application;

[0030] Figure 4 This is a user journey diagram of the public integrated green travel scenario in this application;

[0031] Figure 5 This is a schematic diagram of the intelligent cockpit scenario for commercial vehicle drivers in this application;

[0032] Figure 6 This is a user journey diagram of the intelligent cockpit scenario for commercial vehicle drivers in this application;

[0033] Figure 7 This is a user journey diagram of the safe and efficient operation command scenario for public transportation companies, as described in this application.

[0034] Figure 8 This is a user journey diagram of the precise perception scenario for urban traffic in this application;

[0035] Figure 9 This is a flowchart of the intelligent cockpit control method of this application. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0037] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0038] The meanings of some terms in this application are as follows:

[0039] Render Service (RS): The rendering service is the core service of the OpenHarmony graphics subsystem. It is responsible for window compositing, rendering scheduling, and UI drawing. It is equivalent to the rendering engine of the operating system and is responsible for converting the UI descriptions submitted by various applications into the actual screen display content. The workflow of RS usually includes: (1) receiving rendering requests; (2) preprocessing; (3) rendering tree traversal; (4) VSync synchronization; (5) drawing command recording & playback; (6) hardware compositing; (7) display delivery.

[0040] Composer Host: The OpenHarmony rendering adaptation layer is a graphics compositing service process within the OpenHarmony system service layer. Running as an independent host process, it is responsible for rendering and compositing graphical elements from different windows, surfaces, and layers to generate the final image displayed on the screen, thus providing users with a smooth visual experience. In the system's graphics subsystem architecture, Composer works in conjunction with components such as RenderService, Skia, and NativeWindow, specializing in handling the rendering and compositing tasks of layers and surfaces. It is the core service for realizing multi-window, multi-layer UI compositing.

[0041] Fence: A synchronization mechanism for graphics rendering. In modern graphics APIs (such as Vulkan, DirectX12, OpenGL, Unity, etc.), Fence is a GPU-CPU synchronization primitive used to mark a certain execution point of the GPU and allow the CPU (or other GPU queues) to detect whether the point has been completed, thereby achieving safe resource sharing and orderly execution of instructions.

[0042] The "vendor" in OpenHarmony's display subsystem refers to the vendor implementation layer of DisplayVDI (VendorDeviceInterface). The VDI interface provides a standardized entry point for chip manufacturers, enabling seamless integration of different hardware with OpenHarmony's display driver framework. In the overall architecture, VDI sits at the bottom layer: framework layer → HDI implementation layer → vendor driver layer. The vendor driver layer implements the interface defined by HDI, shielding the differences between underlying chips and allowing the same upper-level framework to work on various display chips, thus achieving cross-platform and cross-architecture display adaptation. Therefore, the vendor essentially refers to the display driver implementation provided by the manufacturer, used to adapt display hardware, provide driver interfaces, and bridge the gap with the system display framework (such as ComposerHDI). In essence, the vendor "sends the system-rendered image to the vendor implementation layer of the display device."

[0043] Split mode: In OpenHarmony, this refers to the split-screen window mode, which allows a UIAbility (or a regular page) to be displayed side-by-side with another window on the same screen. Users can operate two applications or two sub-pages of the same application simultaneously on the same large-screen device.

[0044] RGA: The graphics accelerator of the RockChip chip.

[0045] DRM (Direct Rendering Manager): In OpenHarmony, it is a Linux kernel subsystem responsible for GPU resource management, memory allocation, display mode settings, and multiple display pipelines. HarmonyOS has ported and adapted this subsystem to provide efficient and unified hardware abstraction for the upper-layer graphics framework, supporting the graphics display needs of various scenarios from smart terminals to automotive and smart screens.

[0046] DRMcommit: In the OpenHarmony DRM subsystem, this is an operation used to write the prepared display state to the hardware all at once. It typically appears in the AtomicMode-Setting process, with the core function being drm_atomic_commit() (or its helper implementation drm_atomic_helper_commit()).

[0047] VBLANK (Vertical Blank) signal: This signal is generated by the display during the "vertical blank" period after the display completes a full frame scan and the electron beam (or pixel scan) returns to the top left corner. During this time, the screen does not display an image, and the display controller uses this time to perform internal operations such as frame buffer switching and refreshing.

[0048] Harmony adopts a novel architecture of microkernel + distributed soft bus, enabling low-latency collaboration and resource sharing across terminals. Harmony's open-source nature allows global developers to directly review and contribute code, resulting in significantly improved code quality and security after multiple rounds of community review. The establishment of the OpenAtom Foundation has brought together more than ten internet giants, including Huawei, Alibaba, Tencent, and Baidu, to jointly maintain the OpenHarmony project, forming a massive developer community. As of 2025, the native Harmony ecosystem has covered more than 1 billion devices, boasting over 15,000 native applications and meta-services, covering 18 vertical sectors including finance, education, industry, and transportation, forming a sustainable closed-loop industrial chain.

[0049] However, the native open-source HarmonyOS has only been around for a short time and still has many shortcomings. For example, in terms of camera capture and display, the native open-source HarmonyOS does not support multiple cameras and there is no version adapted for graphics card splitting. Furthermore, OpenHarmony's display architecture severely limits the frame rate in multi-screen scenarios.

[0050] Specifically, the display system of the native open-source HarmonyOS has the following current state:

[0051] The core of the display system is RenderService (RS), provided by the system and existing as an independent process. At compile time, two rendering modes can be selected: separate rendering and unified rendering. In separate rendering, the rendering work is completed within the RenderThread of the app process. RS mainly handles layer occlusion calculations, animation calculations, and rendering. The RS rendering tree is relatively simple, consisting of the various rendered layers. In unified rendering, each level of rendering element in the app has a corresponding entity within the RS rendering tree. The actual occlusion calculations for each rendering element are handled by RS. Because it can handle all rendering elements uniformly, unnecessary calculations can be avoided, resulting in higher overall efficiency, but the RS has a heavier workload. Currently, the only usable rendering backend for RS is OpenGL.

[0052] Interfacing with RS is host_composer, which is also a separate process. Its implementation library is provided by the vendor. It receives the display layer information from RS via IPC communication, performs the necessary hardware layer compositing acceleration work, and sends the final display layer to the DRM driver. In addition, it is also responsible for hardware vsync acquisition and IPC callbacks to RS.

[0053] At the same level as host_composer is host_allocator, which is responsible for displaying memory allocation and has a simple function.

[0054] RS also interacts with WindowManager (WM for short). It is the bridge between RS and UI. UI window operations call the WM interface, and WM is responsible for the corresponding operations in RS (such as the creation of display nodes for each window).

[0055] OpenHarmony's display system has only one vsync signal source, provided to the RS and the application. It does not provide vsync for different display frame rates. After receiving the vsync signal, the RS processes the corresponding display nodes of all displays serially and sends the information to the host_composer for display.

[0056] Furthermore, OpenHarmony's layer compositing is divided into two modes: Client mode and Hardware mode. Client mode is performed within the host composer (RockChip series chips use RGA), and when a GPU is available, it's implemented via the GPU, resulting in faster speeds (around 2 ms for a 3588 main screen), but it also has limitations, such as the inability to perform transcoding. Hardware mode is performed within the host composer (RockChip chips use RGA), which is relatively slower (calling RGA3 for two 1080p layers takes 5-6 ms), and it can perform transcoding, but it has more limitations, such as the inability to perform certain retouching tasks, like rounding rectangle corners. Currently, OpenHarmony's RockChip adaptation uses both compositing modes simultaneously during separate rendering: Hardware mode is used when the number of layers is 4 or less, and Client mode is used when it's greater than 4.

[0057] In response to the above situation, this application proposes an intelligent cockpit control method. Figure 9 This is a flowchart of the intelligent cockpit control method of this application, such as... Figure 9 As shown, the intelligent cockpit control method includes the following steps:

[0058] When performing the display operation of sending the display to the vendor, that is, when the system rendering screen is sent to the vendor implementation layer of the display device, each display unit reported by the DRM driver is split into two logical displays.

[0059] Determine whether the two logical displays of the display unit have been written to the corresponding frame buffer. If not, wait until the writing is complete.

[0060] The contents of the frame buffer are bound to different hardware planes, and the DRM driver performs a one-time hardware commit operation to achieve the split mode of the vendor step (host_composer).

[0061] The two logical displays are divided into a primary display and a secondary display. The primary display contains complete data members, such as the primary plane, which is responsible for directly outputting the composited main frame buffer to the display controller. It carries the rendering of the overall screen, including the UI and window system, and is the main screen seen by the user. The secondary display, corresponding to the overlay plane, is used to overlay another buffer on top of the primary screen. Common uses include video playback, camera preview, cursor or UI animation, and other scenarios that require an independent layer. This plane can be updated independently without resubmitting the entire main frame, thereby improving rendering efficiency, but it needs to access the primary display to achieve full functionality.

[0062] In the aforementioned one-time hardware commit operation, only one write-to-plane operation was performed.

[0063] In the vendor display operation, the vertical blanking (VBlank) signal of the main screen is used as the hardware vsync signal source. The frame rate of the secondary screen is kept at half of the frame rate of the main screen. For cases where the number of secondary screens is greater than 2, such as 4, any of the following measures are taken: (1) In the OnVsync call triggered by the last external source vsync, call RequestNextVsync one more time; (2) After RS ​​processes a frame, check whether there are any secondary screen frames that have not been displayed. If so, call requestNextVsync once and mark it as a supplementary frame; (3) Use setVsyncRate to configure the secondary screen to use hardware vsync every two times. The nc (hardware clock trigger signal) triggers a software vsync (software clock simulation trigger signal), so the system will automatically generate a software vsync once in each odd / even cycle. That is, the system generates timer events at the software level (such as SurfaceFlinger, Choreographer) and simulates the trigger signal generated by the vsync tick. Thus, for every two hardware clock trigger signals generated, one additional software clock simulation trigger signal is generated, so the system will automatically generate a software clock simulation trigger signal once in each odd / even cycle. RS does not require an additional RequestNextVsync, and the rendering timing of the secondary screen is always predictable. Through any of the above operations, scenarios with more than two secondary screens can be implemented, and the situation where the last frame of the secondary screen cannot be sent for display in time can be avoided (the vsync signal is processed on demand. If the last frame of the secondary screen is rendered but does not catch up with the corresponding odd / even vsync in RS and there is no further interface update in the entire system, RS will not receive a new vsync signal).

[0064] In the vendor delivery operation, the main screen uses client mode, while the secondary screen uses hardware mode. The video hardware decoding result format is RGBA, thus leveraging the characteristics of each to improve the actual frame rate during delivery. Client mode is not used exclusively for two reasons: first, the GPU's primary task is rendering the app, and layer compositing should not consume too much bandwidth; second, OpenGL's single-threaded requirement would preclude parallelization.

[0065] Specifically, during DRM commit, the release-fence of the display cache is obtained and stored in the corresponding display output object of the RS display backend. Subsequently, in the next vsync cycle, the compositing thread (SurfaceFlinger, SF) waits until this release-fence is triggered before starting image compositing. This setup avoids the chaotic handling of cached fences caused by the dual-buffering mechanism in HarmonyOS rendering and display submission; it enables parallel work within the same vsync cycle, completing app drawing, SF compositing, and display submission within the same vsync cycle through the fence, thereby improving frame rate and reducing latency; it also avoids frame loss and tearing, preventing half-frame display (tearing) or screen flickering caused by premature cache overwriting; and it allows the rendering pipeline to reuse the cache without blocking the UI thread, improving overall rendering throughput.

[0066] This application applies the above research results to commercial vehicles and buses, and further expands and strengthens the application scenarios of the intelligent cockpit using the OpenHarmony operating system to address common problems in public transportation such as waiting anxiety and missing stops, which affect the public's riding experience. It also proposes an intelligent cockpit control method from the application scenario level, including the following steps:

[0067] The location information of the intelligent cockpit is collected through the positioning module;

[0068] The geographical location information is transmitted to the public transport cloud platform through the first communication module; the arrival information of the intelligent cockpit calculated by the public transport cloud platform based on the geographical location information is received;

[0069] The arrival information is displayed on the screen of the smart cockpit.

[0070] The positioning module is, for example, a navigation module selected from one or more navigation systems, such as BeiDou, GPS, GLONASS, and Galileo.

[0071] The first communication module is, for example, a communication module selected from one or more of the following: wired serial communication modules (such as CAN, CAN-FD, Modbus, PROFIBUS, etc.), fiber optic communication modules (such as single-mode / multimode fiber, SFP, fiber optic Ethernet, etc.), mobile cellular modules (such as 2G / 3G, 4G LTE, 5G Sub-6 / mmWave, etc.), low-power wide area network (LPWAN modules, such as NB-IoT, LTE-Cat-M1, Zigbee, etc.), satellite communication modules (such as BeiDou, GNSS-RTK, etc.), dedicated vehicle / vehicle networking modules (such as 5G+C-V2X, Automotive LTE, etc.), and multi-functional integrated (Smart) modules.

[0072] The bus cloud platform, for example, calculates the arrival information of the next station based on the geographical location information using local or cloud-based map software, including the name of the next station and the remaining arrival time.

[0073] The intelligent cockpit also receives information about lost items sent by the bus cloud platform and notifies relevant staff on the bus, such as the driver, ticket seller, or security guard. This allows passengers to quickly send a lost item information to the bus cloud platform via their mobile phones after getting off the bus, and then send the lost item information to relevant staff for prompt search and preservation, preventing other passengers from taking it with them.

[0074] The smart cockpit also communicates with the bus driver's wristband via a second communication module to obtain health information collected by the wristband and send it to the bus cloud platform. The second communication module is, for example, a short-range communication module, selected from at least one of the following: a Bluetooth module, a Wi-Fi module, an optical communication module, a Zigbee module, etc., thereby enabling real-time monitoring of the bus driver's health status.

[0075] The intelligent cockpit also includes a vehicle self-inspection program, which transmits the self-inspection information to the public transport cloud platform through the first communication module.

[0076] The smart cockpit also provides a video acquisition module to acquire static or dynamic images of the exterior and / or interior of the smart cockpit, thereby acquiring traffic conditions, vehicle conditions, and weather conditions outside the smart cockpit, as well as passenger congestion conditions inside the smart cockpit.

[0077] This application also proposes an intelligent cockpit control system, wherein the intelligent cockpit uses the intelligent cockpit control method described above to control the display operation of the display in the intelligent cockpit, and the intelligent cockpit control system includes:

[0078] The positioning module is used to collect the geographical location information of the smart cockpit;

[0079] The first communication module is used to transmit the geographic location information to the public transport cloud platform and receive the smart cockpit arrival information calculated by the public transport cloud platform based on the geographic location information.

[0080] The display module is used to display the arrival information.

[0081] The positioning module may be a navigation module selected from one or more navigation systems, such as BeiDou, GPS, GLONASS and Galileo. It may be a navigation module of a single navigation system or a navigation module that integrates several navigation systems, such as a dedicated integrated navigation chip.

[0082] The first communication module may be selected from one or more of the following: wired serial communication modules, fiber optic communication modules, mobile cellular modules, low-power wide area networks (LPWANs), satellite communication modules, dedicated vehicle / vehicle networking modules, and multi-functional integrated modules. Examples of such modules include wired serial communication modules (e.g., CAN, CAN-FD, Modbus, PROFIBUS, etc.), fiber optic communication modules (e.g., single-mode / multi-mode fiber, SFP, fiber optic Ethernet, etc.), mobile cellular modules (e.g., 2G / 3G, 4G LTE, 5G Sub-6 / mmWave, etc.), low-power wide area networks (e.g., NB-IoT, LTE-Cat-M1, Zigbee, etc.), satellite communication modules (e.g., BeiDou, GNSS-RTK, etc.), dedicated vehicle / vehicle networking modules (e.g., 5G+C-V2X, Automotive LTE, etc.), and multi-functional integrated (Smart) modules.

[0083] The bus cloud platform calculates the arrival information of the next station based on the geographical location information using local or cloud-based map software. This information may include the name of the next station and / or the remaining arrival time, thus providing passengers with more specific and detailed arrival information and facilitating their travel planning.

[0084] The intelligent cockpit also receives information about lost items sent by the bus cloud platform and notifies relevant staff on the bus, such as the driver, ticket seller, or security guard. This allows passengers to quickly send a lost item information to the bus cloud platform via their mobile phones after getting off the bus, and then send the lost item information to relevant staff for prompt search and preservation, preventing other passengers from taking it with them.

[0085] The smart cockpit also communicates with the bus driver's wristband via a second communication module to obtain health information collected by the wristband and send it to the bus cloud platform. This second communication module is, for example, a short-range communication module, selected from at least one of the following: a Bluetooth / Starlight module, a Wi-Fi module, an optical communication module, or a Zigbee module, thereby enabling real-time monitoring of the bus driver's health status.

[0086] The intelligent cockpit also includes a vehicle self-inspection program, which transmits the self-inspection information to the public transport cloud platform through the first communication module.

[0087] The smart cockpit also provides a video acquisition module to acquire static or dynamic images of the exterior and / or interior of the smart cockpit, thereby acquiring traffic conditions, vehicle conditions, and weather conditions outside the smart cockpit, as well as passenger congestion conditions inside the smart cockpit.

[0088] The intelligent cockpit includes two main screens and four secondary screens. The display resolution of both the main screens and secondary screens is higher than 720p. For example, it can use two 1920x720 60fps main screens and four 1080p 30fps secondary screens.

[0089] This application also provides a public transport cloud platform, which receives the geographical location information sent by the smart cockpit and calculates the smart cockpit's arrival information.

[0090] The bus cloud platform calculates the arrival information of the next station using local or cloud-based map software, including the name of the next station and the remaining arrival time.

[0091] The bus cloud platform responds to lost item information sent by passengers on their mobile phones, sending it to the smart cockpit and notifying relevant staff on board, such as the driver, ticket seller, or security guard.

[0092] The bus cloud platform, based on the pre-shift routine inspection procedure, sends a command to the smart cockpit to obtain vehicle self-inspection information and / or the bus driver's health status, and receives the self-inspection information and / or health status sent by the smart cockpit.

[0093] The public transport cloud platform also includes an image analysis and processing module, which is used to send a command to the smart cockpit to acquire static or dynamic images of the exterior and / or interior of the smart cockpit, receive the static or dynamic images of the exterior and / or interior sent by the smart cockpit, and send them to third-party organizations related to urban traffic or safety management.

[0094] This application also provides a bus stop sign for receiving arrival information sent by a smart cockpit and displaying it through a display module.

[0095] The bus stop sign serves as an information display tool, visually showing the corresponding bus routes, operating vehicles, estimated arrival times of the two nearest buses, and the level of crowding in the carriages.

[0096] The present application will be further illustrated by specific embodiments below. It should be noted that the following embodiments are merely illustrative and not intended to limit the present application.

[0097] Example 1

[0098] The display module of the smart cockpit in this embodiment is implemented using the RK3588. The RK3588's display module VOP has a split function, allowing a single Video Port output to be horizontally split into two paths, driving two display interfaces simultaneously and displaying images with identical timing but independent content. The RK3588 has three VOPs with split functionality, so these three VOPs can drive six physical screens, each displaying an independent image. However, OpenHarmony does not have a version adapted for split functionality. Furthermore, OpenHarmony's display architecture severely limits the frame rate in multi-screen scenarios. Therefore, this embodiment has been optimized as follows to meet the customer's requirements for two 1920x720 60fps main screens and four 1080p 30fps secondary screens:

[0099] The development architecture view is shown below:

[0100] foundation / graphic / graphic_2d /

[0101] ├── figures# Image directory referenced in Markdown

[0102] ├── frameworks# Framework Code Directory

[0103] │├── animation_server# AnimationServer code

[0104] │├── bootanimation# Boot Animation Directory

[0105] │├── fence# fence code

[0106] │├── opengl_wrapper# opengl_wrapper

[0107] │├── surface# Surface code

[0108] │├── surfaceimage# surfaceimage code

[0109] │├── vsync# Vsync code

[0110] │├── wm# WM code

[0111] │├── wmserver# wmserver code

[0112] │├── wmservice# wmservice code

[0113] │├── wmtest# wmtest code

[0114] ├── rosen# Framework Code Directory

[0115] │├── build# Build instructions

[0116] │├── doc# doc

[0117] │├── include# External header file code

[0118] │ ├── modules# graphic Subsystem module code

[0119] │ ├── samples# Example code

[0120] │ ├── test# Develop test code

[0121] │ ├── tools# Tool Code

[0122] ├── interfaces# Directory for storing graphical interfaces

[0123] │ ├── inner_api# Directory for storing internal native interfaces

[0124] │ └── Directory for storing kits# js / napi external interfaces

[0125] └── utils# Widgets directory

[0126] This is from the OpenHarmony mainline documentation.

[0127] Figure 1 This is a diagram of the OpenHarmony display system composition in this application, and a display architecture diagram from the OpenHarmony main documentation. Figure 2This is a simplified logical architecture diagram of the software framework of the OpenHarmony display system described in this application. Figure 1 , 2 As shown, the core of the display system is the Render Service (RS for short), which is provided by the system and exists as an independent process.

[0128] (1) Adaptation and modification of the split mode of the vendor part (host_composer)

[0129] Each display unit reported by the DRM driver is split into two logical displays. These two logical displays are further divided into a primary display and a secondary display. The primary display contains complete data members, while the secondary display accesses the primary display to achieve its full functionality. Each commit (one-time write to hardware) operation of the DRM driver requires waiting until both logical displays of that display unit have updated their display buffers before binding their respective buffers to different hardware planes and executing the operation uniformly.

[0130] (2) Frame rate optimization

[0131] A. Handling different frame rates

[0132] Since there is only one vsync signal, the system uses the vblank signal of the main screen as the hardware vsync signal source. The clock cycle number of the secondary screen's display mode is exactly twice that of the main screen, meaning the secondary screen's frame rate is half that of the main screen. The main screen triggers rendering once for each vsync signal, while the secondary screen only updates the image on odd / even vsync signals (i.e., every second vsync signal). Therefore, it is necessary to determine the parity of the vsync signal when sending the RS (Real-Timeout) signal to see if the main screen and a group of secondary screens (a total of 4 screens) have all been rendered. To avoid the last frame of the secondary screen being an odd number, causing the RS to fail to receive a new vsync signal and thus fail to complete the rendering of the secondary screen, one of the following measures is adopted: (1) Call RequestNextVsync once more in the OnVsync call triggered by the last external vsync; (2) After the RS finishes processing a frame, check if there are any secondary screen frames that have not been sent. If so, call requestNextVsync once and mark it as "frame supplement"; (3) Use setVsyncRate(2) to configure the secondary screen to "trigger a soft vsync every two hardware vsyncs", so that the system will automatically generate a soft vsync in each odd / even cycle. The RS does not need an additional requestNextVsync, and the rendering timing of the secondary screen is always predictable.

[0133] B. The choice between separate rendering and unified rendering

[0134] While unified rendering offers high overall efficiency, Responder (RS) is burdened with heavy workloads. More importantly, it cannot achieve parallel processing of RS because the OpenGL backend only supports single-threaded processing. In contrast, separate rendering performs its rendering tasks separately within each app. RS primarily handles compositing and display preparation. When different compositing modes are used for the main screen and secondary screen, partial parallelization can be achieved. Therefore, separate rendering is chosen.

[0135] C. Handling layer compositing methods

[0136] Originally, each screen used two compositing methods, but this was unnecessary. In this application, the main screen uses client mode, and the secondary screen uses hardware mode. However, client mode cannot perform YUV to RGBA transcoding, while the original video hardware decoding result format is YUV. Therefore, the relevant gstreamer interfaces and OpenMax implementation were modified to make the video hardware decoding result format RGBA. The secondary screen uses hardware mode, and the colors are incorrect when playing hardware-decoded videos. This is because the video hardware decoding result format is RGBA, which is actually the result of the decoder calling RGA to transcode YUV. However, the existing RockChip SDK's RGA transcoding sets the Alpha value to 0 (it should generally be 255). Therefore, during hardware compositing, an assumption is used: the Alpha value of the top left corner of a normal layer is not 0. This is used to determine whether the current layer is a hardware-decoded video and to perform differentiated processing (although this has limitations, it should be acceptable in the secondary screen application scenario). Because hardware rendering is slower, in practice, clients are advised not to have more than two layers displayed on the secondary screen. This is reasonable in most applications: one background layer and one foreground window are sufficient. However, since the video is a separate layer when playing within a window, the layers below the video layer are discarded in this scenario (this limits the ability to move the container window while playing the video, otherwise it will cause ghosting). If the secondary screen has a large number of hardware rendering layers, resulting in long processing times, it will lengthen the display processing flow and reduce the actual frame rate. The main screen does not have these limitations. The reason for not using a client-side mode for all applications is twofold: first, the GPU's primary task is to render the app, and layer rendering should not consume too much space; second, OpenGL's single-threaded requirement makes parallelization impossible.

[0137] D. Parallelization of the display section

[0138] Despite employing the above methods, the frame rate still struggled to meet requirements under heavy loads on the secondary screens (such as when playing video through a window). Therefore, parallelization of the display delivery was implemented: the main thread handles the serial display delivery for the two main screens; a separate thread handles the serial display delivery for the two secondary screens simultaneously. This modification ensures that the frame rate still meets customer requirements even under heavy display loads.

[0139] The key points for partial parallelization are: link host_composer to RS as a library; after host_composer is changed to a library, since its original implementation is also basically applicable to individual processing based on each display, only a small part of the code needs to be locked for protection.

[0140] Parallelization of RS: Most of the RS display process code is suitable for parallelization. The main modification is to create a separate visitor for each display thread. In addition, there is only one global instance of hdi_backend. The onPrepareCompleteCb_ variable in it stores the client composition callback. It needs to be updated once when processing each screen. Originally, there was no problem when processing serially, but it is not possible after parallelization. However, since the client composition only needs two main screens, and these two main screens are serial, it is only necessary to refresh this variable when processing the main screen.

[0141] Parallelization adaptability investigation of host_allocator: Since only the allocmem method is IPC when the surface_buffer implementation of RS calls host_allocator, and the map operation is implemented in the local stub, and the map operation is thread-safe, and the experiment found that allocmem is not called in the display thread, the parallelization modification of RS has not created the possibility of parallel calls to host_allocator, so host_allocator does not need to be modified.

[0142] E, fence point adjustment

[0143] HarmonyOS rendering and display delivery employs a dual-frame buffer mechanism: one for display output in the DRM driver, and the other for rendering. The original display delivery process had a somewhat chaotic handling of buffer fences. Now, during DRM commit, the release-fence of the display buffer is retrieved and stored in the output object of the corresponding display in the RS display delivery backend. When the system receives the next vsync, it waits for the previous release-fence to be released (ensuring the previous frame is fully displayed) before starting the compositing of the new frame image (processed within the hdi_backend). This creates a closed loop of "commit-wait-render-commit," avoiding resource contention.

[0144] Through the above optimizations, the customer's requirement of two 1920x720 60fps main screens and four 1080p 30fps secondary screens can be met.

[0145] Building upon the hardware implemented in Example 1, this application uses the OpenHarmony commercial vehicle intelligent cockpit domain controller as its core. The hardware employs a domestically produced SOC chip, and the software utilizes the OpenHarmony operating system. Based on the OpenHarmony operating system, upper-layer applications and public transportation ecosystem applications are developed, comprehensively replacing Android, Linux, and QNX operating systems. This achieves independent controllability, security, and stability for core commercial vehicle applications, and targets four groups: the public, drivers, operating companies, and public management institutions, constructing a system such as... Figure 3 The integrated green travel, intelligent cockpit for commercial vehicles, safe and efficient operation command, and precise perception scenario application experience of urban traffic described in Examples 2-5 are shown.

[0146] Example 2

[0147] To address the common issues affecting public transportation experiences, such as anxiety from waiting blindly and missing stops, this embodiment leverages the interconnectivity and information sharing between the OpenHarmony commercial vehicle intelligent cockpit domain controller, electronic bus stop signs, passenger mobile phones, and the public transportation cloud platform to build an integrated green travel service network for the public, from boarding planning to disembarking and exiting the station.

[0148] In the context of travel planning, passengers' mobile phones can obtain static information such as route, station location, and operation plan through the public transport cloud platform, as well as dynamic information such as real-time location and passenger volume collected and transmitted by the intelligent cockpit domain controller of the bus. Passengers can input their departure and arrival locations, and their mobile phones can display route plans from dimensions such as short time, less walking, fewer transfers, and no subway, to help passengers choose the best travel mode and avoid long waiting times.

[0149] Focusing on the bus stop waiting scenario, electronic bus stop signs can share information with the smart cockpit domain controllers of buses through a bus cloud platform. When passengers arrive at the bus stop, they can view real-time information such as operating routes, vehicles, and estimated arrival times through the electronic signs. Simultaneously, the smart cockpit domain controllers of approaching vehicles can connect seamlessly with waiting passengers' mobile phones via the bus cloud platform, providing real-time notifications of vehicle arrivals. This convenience is especially important for passengers with special needs, allowing them to stay informed about vehicle status and prepare for boarding.

[0150] Regarding the disembarking and exiting the station, passengers' mobile phones can obtain real-time location information collected and transmitted by the intelligent cockpit domain controller of the vehicle they are riding through the bus cloud platform. This automatically reminds passengers of the vehicle's arrival status, preventing passengers from missing their stop and delaying their journey, and providing them with a fully controllable, convenient and worry-free public transportation experience.

[0151] Figure 4 It is a user journey map of the public's integrated green travel scenario, such as Figure 4 As shown, in public transportation scenarios, while ensuring public privacy, a public-interest positioning ecosystem mutual assistance service network can be built. The intelligent cockpit domain controller of the bus can serve as one of the base stations for locating people and items, assisting in the technical verification of public welfare actions such as finding relatives of special groups and quickly recovering lost items.

[0152] Table 1. List of Equipment for Integrated Green Travel Scenarios for the Public

[0153]

[0154] Table 2 List of Application Scenarios for Integrated Green Travel for the Public

[0155]

[0156] Table 3. List of Connected Devices for Integrated Green Travel Scenarios in the Public

[0157]

[0158] Example 3

[0159] To address the needs of commercial vehicle drivers for a simple and safe cockpit environment, an efficient and integrated interactive experience, and the operational companies' requirements for monitoring drivers' health status, this embodiment leverages the interconnection and information sharing between the commercial vehicle's OpenHarmony intelligent cockpit domain controller and the driver's mobile phone, wristband, and public transport cloud platform to provide drivers with a safe, intelligent, and efficient work experience from before their shift to after their shift.

[0160] Figure 5 This is a schematic diagram of a smart cockpit scenario for commercial vehicle drivers, such as... Figure 5As shown, regarding the pre-shift preparation scenario, drivers can access information such as pre-shift routine checks, departure plans, and vehicle status via the bus cloud platform on their mobile phones. After arriving at the depot and completing pre-shift procedures such as alcohol testing, oath-taking, and sign-in, drivers can directly check their pre-shift status test results, vehicle status, and driving tasks via their mobile phones. When approaching the departure point, they can collect the car keys, inspect the vehicle, and prepare for departure.

[0161] Focusing on the driving scenario within the bus, the intelligent cockpit domain controller can highly collaborate with the bus cloud platform to integrate and optimize functions such as operation scheduling, video surveillance, active safety, and passenger services. It efficiently collects and processes all data from the entire vehicle, directly driving multiple displays inside the vehicle and centrally empowering various in-vehicle camera terminals with AI capabilities. This allows drivers to intuitively and clearly understand the surrounding environment and passenger dynamics while driving, enjoying a simple and intelligent driving interaction experience. Simultaneously, the intelligent cockpit domain controller can seamlessly communicate with the driver's health wristband. While driving, the driver wears the health wristband, and the real-time health status data monitored by the wristband is uploaded to the bus cloud platform via the intelligent cockpit domain controller. The entire data transmission relies on the dedicated bus network, effectively protecting the driver's personal privacy and ensuring the high quality and reliability of health monitoring data. Integrating data such as driver operating habits and abnormal behavior monitoring, it facilitates comprehensive and convenient monitoring of safety risks during bus operations by the operating company's safety management personnel, enabling timely and effective measures to ensure bus driving safety.

[0162] Figure 6 It is a user journey map of the intelligent cockpit scenario for commercial vehicle drivers, focusing on the post-shift return-to-the-park scenario, such as... Figure 6 As shown, drivers can access operational tasks and vehicle status information collected and transmitted by the bus's intelligent cockpit domain controller via the bus cloud platform on their mobile phones. After completing their task and returning to the depot, drivers can directly view a summary of the task's execution, the next task, and the corresponding vehicle status information on their mobile phones, thus improving the driver's work experience and efficiency.

[0163] Table 4. List of Equipment for Smart Cockpit Scenarios for Commercial Vehicle Drivers

[0164]

[0165] Table 5 List of Smart Cockpit Application Scenarios for Commercial Vehicle Drivers

[0166]

[0167] Table 6. List of Connected Devices for Smart Cockpit Scenario in Commercial Vehicles

[0168]

[0169] Example 4

[0170] In response to the phased construction of multi-source commercial vehicle on-board terminals and the inconsistent data perception quality standards, there is an urgent need for system integration to support enterprises in achieving safe and stable operation services, precise control, and improved organizational efficiency. This project is based on the interconnection and information sharing between the commercial vehicle OpenHarmony intelligent cockpit domain controller, the public transport cloud platform, and employee mobile phones to create an intensive, efficient, safe, and controllable operation command system for public transport companies.

[0171] Figure 7 This is a user journey diagram illustrating the command and control scenarios for safe and efficient operation of public transportation companies. For example... Figure 7 As shown, focusing on operational scenarios, the intelligent cockpit domain controller for buses can centrally collect and process core operational information, including passenger volume, vehicle location, driving conditions, and real-time road conditions. This information is then transmitted to the bus cloud platform, supporting company employees in conducting closed-loop management of the entire bus lifecycle—including network planning, schedule preparation, resource allocation, dispatching, and evaluation—through multiple terminals such as mobile phones and computers. Bus company managers can use the network planning module of the bus cloud platform to monitor basic route indicators and bus resource distribution in real time, formulate route infrastructure layout and route planning schemes, and, combined with macro and micro analysis, intuitively evaluate the adjusted network layout level, outputting scientific and reasonable optimization decisions. Based on basic data such as routes, and combined with multi-dimensional analysis of passenger flow and vehicle operation data, bus regional dispatchers can use the bus cloud platform's driving plan preparation module to effectively optimize driving plans based on travel demand and coordinate the allocation of personnel and vehicle resources within the region according to the driving plans. Drivers in each fleet can view driving plans and shift schedules on their mobile phones and execute operational tasks on time. Regional dispatchers can monitor the execution of operational tasks in real time through the bus cloud platform's dispatch and command module. For dynamic events such as traffic congestion, vehicle delays, and bus berthing during operation, they can promptly output control strategies such as skip-stop dispatching, interval dispatching, and cross-line dispatching, which are then distributed to the intelligent cockpit domain controllers of buses, reminding drivers to make timely adjustments. Simultaneously, managers at various levels within the bus company can use the bus cloud platform's monitoring dashboard module and mobile terminals to evaluate and analyze multi-dimensional indicators such as passenger flow, capacity, safety, service, energy consumption, and revenue. This provides quantitative feedback on the company's operational production and management, assisting in developing improvement measures and systematically enhancing operational efficiency and resource utilization effectiveness.

[0172] Table 7. Equipment List for Safe and Efficient Operation Command Scenarios in Public Transportation Companies

[0173]

[0174] Table 8. List of Application Scenarios for Safe and Efficient Operation Command in Public Transportation Companies

[0175]

[0176] Table 9. List of Interconnected Equipment Combinations for Safe and Efficient Operation Command Scenarios in Public Transportation Enterprises

[0177]

[0178] Example 5

[0179] Addressing the needs of public management agencies for data on public travel, road structure, and traffic conditions to quantitatively support decisions in urban planning, emergency command, and traffic congestion mitigation, this project leverages the video monitoring and AI recognition functions of the OpenHarmony intelligent cockpit domain controller for commercial vehicles, as well as interconnection and information sharing with the public transport cloud platform. This provides real-time and accurate data perception capabilities for urban transportation services, digitally empowering urban traffic governance and smart city construction.

[0180] Figure 8 It is a user journey map of a precise sensing scenario in urban traffic. For example... Figure 8 As shown, focusing on urban transportation perception scenarios, the intelligent cockpit domain controller of public buses incorporates an AI processing core. This core enables various camera devices throughout the vehicle to continuously collect image information of passengers inside the vehicle, as well as surrounding roads and buildings. This information can be shared with third-party organizations via the public transport cloud platform. On one hand, this empowers urban traffic management, providing data support for public management agencies to understand the real-time characteristics of public travel, optimize the layout of transportation infrastructure, and propose effective countermeasures to alleviate urban traffic congestion. On the other hand, it empowers urban emergency command, providing basic data support for safety management departments to build an urban transportation resource information network. In the event of emergencies, resources can be quickly allocated, improving emergency command efficiency and promoting the construction of safe cities. Simultaneously, the image data acquired by the intelligent cockpit domain controller can serve as a key input for high-precision map updates, driving the development of intelligent connected vehicle technology.

[0181] Table 10 List of Equipment for Precision Sensing Scenarios in Urban Traffic

[0182]

[0183] Table 11 List of Application Scenarios for Precise Sensing in Urban Traffic

[0184]

[0185] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for controlling an intelligent cockpit, wherein the intelligent cockpit uses the OpenHarmony operating system, characterized in that, When sending the system-rendered screen to the display device's vendor implementation layer, the intelligent cockpit control method uses the main screen's vertical blanking signal as the hardware vsync signal source, and the secondary screen's frame rate is maintained at half of the main screen's frame rate. The intelligent cockpit control method includes the following steps: Each display unit reported by the DRM driver is split into two logical displays; Determine whether the two logical displays of the display unit have been written to the corresponding frame buffer. If not, wait until the writing is complete. The contents of the frame buffer are bound to different hardware planes respectively, and the one-time write hardware operation of the DRM driver is executed uniformly to realize the split-screen mode of the vendor delivery step. Furthermore, the intelligent cockpit control method further includes any of the following steps: (1) In the last OnVsync call triggered by external vsync, call RequestNextVsync one more time; (2) After the rendering service finishes processing a frame, check if there are any unsent sub-screen frames. If so, call RequestNextVsync once and mark it as a supplementary frame. (3) Use setVsyncRate to configure the secondary screen to generate one software clock simulation trigger signal for every two hardware clock trigger signals, so that the system will automatically generate one software clock simulation trigger signal in each odd / even cycle, where the number of secondary screens is greater than 2.

2. The intelligent cockpit control method according to claim 1, characterized in that, The two logical displays are divided into a main logical display and a secondary logical display. The main logical display contains complete data members, corresponds to the main plane, and is responsible for directly outputting the main frame buffer after system synthesis to the display controller. It carries the rendering of the UI and the overall window system screen and is the main screen seen by the user. The secondary logical display corresponds to the overlay plane and is used to overlay another layer of buffer on top of the main screen. Common uses include video playback, camera preview, cursor or UI animation, which require independent layers. The overlay plane can be updated independently without resubmitting the entire main frame, thereby improving rendering efficiency, but it needs to access the main logical display to achieve full functionality.

3. The intelligent cockpit control method according to claim 1, characterized in that, When the system renders the screen and sends it to the display device's implementation layer, the main screen uses client mode and the secondary screen uses hardware mode. The video hardware decoding result is in RGBA format. During the one-time hardware write operation of the DRM driver, the release-fence of the frame buffer is obtained and stored in the output object of the display corresponding to the rendering service's backend. Then, in the next vsync cycle, the image compositing can only begin after the previous release-fence is released.

4. A smart cockpit control method, wherein the smart cockpit adopts the OpenHarmony operating system, and the display operation of the display in the smart cockpit is controlled by the smart cockpit control method as described in any one of claims 1-3, characterized in that, The intelligent cockpit control method includes the following steps: The location information of the intelligent cockpit is collected through the positioning module; The geographical location information is transmitted to the public transport cloud platform through the first communication module; the arrival information of the intelligent cockpit calculated by the public transport cloud platform based on the geographical location information is received; The arrival information is displayed on the screen of the smart cockpit.

5. The intelligent cockpit control method according to claim 4, characterized in that, The positioning module employs a navigation module selected from one or more navigation systems, including BeiDou, GPS, GLONASS, and Galileo; and / or The first communication module is one or more of the following communication modules: wired serial communication module, fiber optic communication module, mobile cellular module, low power wide area network, satellite communication module, dedicated vehicle / vehicle networking module, and multi-functional integrated module; and / or Based on the geographic location information, the bus cloud platform calculates the arrival information of the next station using local or cloud-based map software, including the name of the next station and / or the remaining arrival time.

6. The intelligent cockpit control method according to claim 4, characterized in that, The smart cockpit also receives information about lost items from passengers sent by the bus cloud platform and notifies relevant personnel on board; and / or The smart cockpit also communicates with the bus driver's wristband via a second communication module to obtain health information collected by the wristband and send it to the bus cloud platform; wherein the second communication module is selected from at least one of a short-range communication module, a satellite flash / Bluetooth module, a WIFI module, an optical communication module, and a Zigbee module, thereby enabling real-time acquisition of the bus driver's health status; and / or The intelligent cockpit also includes a vehicle self-check program, and transmits the self-check information to the public transport cloud platform via a first communication module; and / or The intelligent cockpit can also acquire static or dynamic images of the exterior and / or interior of the intelligent cockpit in real time and transmit them to the public transport cloud platform through the first communication module, thereby enabling the public transport cloud platform to acquire traffic conditions, vehicle conditions, weather conditions outside the intelligent cockpit and / or passenger congestion conditions inside the intelligent cockpit.

7. A smart cockpit control system, wherein the smart cockpit adopts the OpenHarmony operating system, and uses the smart cockpit control method as described in any one of claims 1-3 to control the display operation of the display in the smart cockpit, characterized in that, The intelligent cockpit control system includes: The positioning module is used to collect the geographical location information of the smart cockpit; The first communication module is used to transmit the geographic location information to a public transport cloud platform and receive the smart cockpit arrival information calculated by the public transport cloud platform based on the geographic location information. The display module is used to display the arrival information.

8. The intelligent cockpit control system according to claim 7, characterized in that, The positioning module employs a navigation module selected from one or more navigation systems, including BeiDou, GPS, GLONASS, and Galileo; and / or The first communication module is one or more of the following communication modules: wired serial communication module, fiber optic communication module, mobile cellular module, low power wide area network, satellite communication module, dedicated vehicle / vehicle networking module, and multi-functional integrated module; and / or Based on the geographic location information, the bus cloud platform calculates the arrival information of the next station using local or cloud-based map software, including the name of the next station and / or the remaining arrival time.

9. The intelligent cockpit control system according to claim 7, characterized in that, The smart cockpit also includes a lost and found module, used to receive information about lost items sent by passengers from the public transport cloud platform and notify relevant personnel on board; and / or The smart cockpit also includes a second communication module for communicating with the wristband worn by the bus driver to obtain health information collected by the wristband; wherein, the second communication module is a short-range communication module, selected from at least one of a StarFlash / Bluetooth module, a WIFI module, an optical communication module, and a Zigbee module, thereby enabling real-time acquisition of the bus driver's health status.

10. The intelligent cockpit control system according to claim 7, characterized in that, The intelligent cockpit also includes a vehicle self-inspection module for performing self-inspections on the vehicle and transmitting the self-inspection information to the public transport cloud platform via a first communication module; and / or The smart cockpit also includes a video acquisition module for acquiring static or dynamic images of the exterior and / or interior of the smart cockpit, and transmitting them to the public transport cloud platform through the first communication module, so that the public transport cloud platform can acquire real-time traffic conditions, vehicle conditions, weather conditions outside the smart cockpit and / or passenger congestion conditions inside the smart cockpit.

Images