Vehicle-mounted central control screen control method, vehicle-mounted central control screen and storage medium

Abstract

This application discloses a method for controlling an in-vehicle central control screen, an in-vehicle central control screen, and a storage medium. This application relates to the field of general control system technology. The in-vehicle central control screen control method includes: in response to a triggering operation of an interface switching control in a first interface, obtaining at least one pre-stored layout information; selecting target layout information from the layout information based on preset rules; generating a second interface based on the target layout information, and rendering and displaying the second interface. This method solves the technical problem in related technologies where third-party central control screens display a single content, few functions, and are unable to meet user needs. It achieves the technical effect of adaptively generating interface layouts based on user needs, enhancing the display diversity of the central control screen.

Description

Technical Field

[0001] The present application relates to the general field of control system technology, and in particular to a vehicle-mounted central control screen control method, a vehicle-mounted central control screen and a storage medium. Background Art

[0002] With the continuous development of the automotive industry and consumers' increasing demands for a superior driving experience, the in-vehicle central control screen, a key component in modern vehicle interiors, has gradually become the core hub for vehicle information interaction and entertainment functions. With the advent of the digital age, liquid crystal display technology has begun to be applied to in-vehicle central control screens. This enables central control screens to present more complex information, including navigation maps and multimedia playlists, with higher resolution and richer colors.

[0003] However, current third-party central control screens basically use the native Android interface, displaying a single content and having few functions, which makes it difficult to meet user needs. Summary of the Invention

[0004] The main purpose of this application is to provide a vehicle-mounted central control screen control method, device and storage medium, aiming to solve the technical problem that the current third-party central control screen basically adopts the native Android interface, displays a single content, has few functions, and is difficult to meet the user's usage needs.

[0005] To achieve the above objectives, the present application provides a method for controlling a vehicle-mounted central control screen, the method comprising:

[0006] In response to a triggering operation of an interface switching control in the first interface, obtaining at least one pre-stored layout information;

[0007] Selecting target layout information from the layout information based on a preset rule;

[0008] Generate a second interface according to the target layout information, and render and display the second interface.

[0009] In addition, to achieve the above-mentioned purpose, the present application also provides a vehicle-mounted central control screen, which includes: a memory, a processor, and a computer program stored on the memory and runnable on the processor, and the computer program is configured to implement the steps of the vehicle-mounted central control screen control method as described above.

[0010] In addition, to achieve the above-mentioned purpose, the present application also provides a storage medium, which is a computer-readable storage medium, and the computer-readable storage medium stores a program for implementing the vehicle-mounted central control screen control method. The program for implementing the vehicle-mounted central control screen control method is executed by the processor to implement the steps of the vehicle-mounted central control screen control method as described above.

[0011] This application provides a method for controlling an in-vehicle central control screen. This method obtains at least one pre-stored layout information in response to a triggering operation of an interface switching control in a first interface; selects target layout information from the layout information based on preset rules; generates a second interface based on the target layout information, and renders and displays the second interface. This method addresses the technical problem in related technologies where third-party central control screens display a single content, few functions, and are unable to meet user needs. It achieves the technical effect of adaptively generating interface layouts based on user needs, enhancing the display diversity of the central control screen. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0013] Figure 1 A flowchart of the first embodiment of the vehicle-mounted central control screen control method of the present application is provided;

[0014] Figure 2 This is a schematic diagram of the first interface in Example 1 of the vehicle-mounted central control screen control method of this application;

[0015] Figure 3 These are four schematic diagrams of the layout information pre-stored in the first embodiment of the vehicle-mounted central control screen control method of this application;

[0016] Figure 4 This is a schematic diagram of user-defined layout information in Example 1 of the vehicle-mounted central control screen control method of this application;

[0017] Figure 5 This is a schematic diagram of the second interface in Example 1 of the vehicle-mounted central control screen control method of this application;

[0018] Figure 6 This is a schematic diagram of the hardware structure of the vehicle central control screen involved in this application. DETAILED DESCRIPTION

[0019] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not intended to limit the present application.

[0020] In order to better understand the technical solution of this application, the following will be described in detail with reference to the accompanying drawings and specific implementation methods. The current third-party central control screen basically adopts the native Android interface, displays a single content, has few functions, and is difficult to meet the user's usage needs. This application obtains at least one pre-stored layout information in response to the triggering operation of the interface switching control in the first interface; selects the target layout information in the layout information based on preset rules; generates a second interface according to the target layout information, and renders and displays the second interface. It realizes the technical effect of adaptively generating the interface layout according to user needs and improving the display diversity of the central control screen.

[0021] It should be noted that the execution subject of this embodiment can be a vehicle controller, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an in-vehicle central control screen capable of performing the above functions, etc. This embodiment does not specifically limit this. The following uses the in-vehicle central control screen as an example to illustrate this embodiment and the following embodiments.

[0022] Based on this, the first embodiment of the present application proposes a method for controlling a vehicle-mounted central control screen. Figure 1 The vehicle-mounted central control screen control method includes steps S10 to S30:

[0023] Step S10: In response to a triggering operation of an interface switching control in the first interface, obtaining at least one pre-stored layout information.

[0024] In this embodiment, the first interface and the second interface are both interfaces displayed on the vehicle's central control screen, and are not interfaces of specific content. For the interface switching action, the first interface is displayed before the switch, and the second interface is displayed after the switch. For example, when the interface switch is triggered continuously, interface 1 is the first interface, and interface 2 after the switch is the second interface. However, for the second interface switch, interface 2 is the first interface, and interface 3 is the second interface. In the content displayed on the vehicle's central control screen, refer to Figure 2 , Figure 2 It is an example of the first interface. There is a row of triggerable controls above the interface, one of which is an interface switching control. When the interface switching control is triggered, the pre-stored layout information is obtained. The layout information has at least one reference Figure 3 , Figure 3 There are four types of layout information shown in Figure 1. When the user does not customize the layout information, the system has several types of layout information built in when it leaves the factory, and each type of layout information has an associated layout type. Figure 4 If the user customizes the layout information, the user can set the layout type of the layout information. Layout information refers to the widgets that need to be displayed in the interface, as well as the size of each widget, the arrangement of the widgets, and other information.

[0025] In step S20 , target layout information is selected from the layout information based on a preset rule.

[0026] In this embodiment, the preset rule means that the vehicle-mounted central control screen obtains certain data, then matches the data with the preset rule, and selects target layout information in the layout information according to the matched rule.

[0027] As an optional embodiment, if there are at least two types of layout information, the priority of each type of layout information is obtained; and the target layout information is selected based on the priority. After obtaining the layout information, the priority of each type of layout information is determined based on the priority assigned by the user or based on the user's frequency of use, and the highest priority type is selected as the target layout information.

[0028] As another optional implementation, layout reference data is acquired, a recommended layout type is determined according to the layout reference data, and then the layout information matching the recommended layout type is selected as the target layout information.

[0029] Step S30: Generate a second interface according to the target layout information, and render and display the second interface.

[0030] In this embodiment, the second interface has been described above and will not be repeated here.

[0031] After determining the target layout information, obtain the component requirement data of each widget according to the widget in the target layout information, and then fill the component requirement data into each widget to generate the second interface, and then render the second interface to the vehicle central control screen, refer to Figure 5 , Figure 5 This is an example of the second interface.

[0032] As an optional implementation, the in-vehicle central control screen incorporates a high-performance processor responsible for overall system operations and control. It is connected to a large-capacity storage module for storing pre-stored layout information, various applications, and related data. The display module utilizes a high-resolution, high-brightness touchscreen, ensuring clear display in varying lighting conditions and accurate reception of user touch operations. The sensor module integrates multiple sensors, including a light sensor, gyroscope, and accelerometer, for real-time sensing of the vehicle's internal and external environment, as well as its driving status. Interface switching controls are located in a fixed area above the in-vehicle central control screen's display interface. These icons are presented as simple, clear icons, such as a rectangular icon with left or right arrows, for easy one-handed operation. When a user lightly touches the icon and swipes left or right, the central control screen's touch detection circuitry detects the trigger and transmits a signal to the processor. The system ships with pre-stored layout information for at least three different layout types, stored in a dedicated partition of the storage module. For example, one layout is designed specifically for long-distance driving, highlighting navigation information, range estimation, and fatigue warning components. These components are large, compact, and logically arranged, making it easy for drivers to access key information at a glance. Another layout focuses on urban commuting, prominently displaying music playback, real-time traffic information, and nearby parking lot search components for easy access in congested traffic. Finally, a general layout offers a balanced display of vehicle status (such as speed, fuel consumption, and tire pressure), multimedia entertainment, and commonly used quick settings. Users can access a dedicated settings interface on the central control screen, using intuitive controls like dragging, dropping, and zooming to rearrange widgets. They can define their own layouts and assign them specific layout types, such as "Weekend Travel Layout" or "Work Commute Layout." Customized layouts are also stored in the storage module and managed alongside the factory-installed layouts. Users can manually assign a priority value to each layout on a scale of 1-10, with higher values ​​increasing the priority. For example, if a user often travels on business, he or she may set the priority of "Long-distance Driving Layout" to 8, the priority of "Weekend Travel Layout" to 6, and the priority of "Work Commute Layout" to 7. Alternatively, the central control screen system has a built-in intelligent statistics module that silently records the usage time and number of times each layout information is used in the background. At regular intervals (such as a week), the system will recalculate the priority of each layout information based on statistical data. For example, if the cumulative usage time of "Work Commute Layout" reaches 5 hours and the number of times it is used is 20 times in the past week, after calculation through a specific algorithm, its priority may be increased to 8, surpassing other layouts to become the top priority. When the interface switch is triggered, the system first queries the priority list and selects the layout information with the highest priority as the target layout information. Alternatively, the central control screen obtains the current time information in real time by connecting to the on-board clock module.For example, between 7 and 9 a.m., the system identifies rush hour as rush hour and recommends a layout suitable for urban commuting. Between 6 and 8 p.m., if it's a Friday, based on historical data, it predicts the user is likely to travel after get off work and recommends a "weekend travel layout." Leveraging the vehicle's onboard GPS module, the central control screen accurately determines the vehicle's location. When the vehicle enters areas with weak signal strength, such as mountainous areas, navigation becomes increasingly important, and the system prioritizes layouts with stable offline navigation and a prominent signal strength display. If the vehicle is parked near a shopping mall parking lot, the system automatically switches to a layout that highlights nearby restaurants, shopping recommendations, and vehicle tracking. The system communicates with the vehicle's electronic control unit (ECU) to obtain status information such as speed, fuel consumption, and tire pressure. If the vehicle's speed consistently exceeds 100 km / h and fuel consumption is high, the system infers that the vehicle is traveling on a long highway and recommends a layout optimized for long-distance driving, displaying energy-saving driving tips and information about nearby service areas. The system determines the recommended layout type based on the collected layout reference data and pre-set matching rules. For example, if the current time is 8:00 AM, the vehicle is on a city arterial road, and the speed is between 30 and 50 km / h, matching rules determine that a "city commuting layout" should be recommended. After obtaining the recommended layout type, the central control screen searches the stored layout information for a matching layout and determines it as the target layout information. When each widget is loaded into the target layout information, the central control screen system sends a data request to the corresponding application or data source. For example, the navigation widget requests data such as the current location, destination information, and route planning from the onboard navigation system; the music player widget requests data such as the current playlist, song progress, and volume control from the multimedia playback system; and the vehicle status widget requests the latest data such as vehicle speed, fuel consumption, tire pressure, and fault warnings from the ECU. The central control screen's graphics processing unit (GPU) synthesizes and renders the interface based on the widget size and position specified in the target layout information and the acquired component requirement data. It uses advanced graphics rendering algorithms to ensure smooth display, vibrant colors, and clear and readable text. For example, when rendering the second interface of the long-distance driving layout, the navigation map is displayed in a larger size and high definition in the center of the screen, the estimated mileage is displayed in eye-catching digital form in the upper right corner, and the fatigue driving reminder is placed in the upper left corner as a flashing icon. Other components are reasonably distributed according to the layout. The entire process is completed within 1 second, realizing fast interface switching without affecting the driver's attention.

[0033] Through the above-mentioned detailed implementation methods and specific usage scenario examples, the vehicle-mounted central control screen control method of the present invention can effectively solve the problems of existing third-party central control screens, greatly improve the user experience in different driving scenarios, and meet diverse needs.

[0034] Based on the first embodiment, the second embodiment of the present application proposes a method for controlling a vehicle-mounted central control screen, step S20 including:

[0035] Step S21 : acquiring layout reference data, wherein the layout reference data includes vehicle operating state data, vehicle driving environment data, and driver image data.

[0036] In this embodiment, vehicle operating status data refers to various parameters reflecting the vehicle's real-time operating status. This data is collected by the onboard electronic control unit (ECU) and various sensors connected to it. It covers key indicators such as vehicle speed, engine speed, transmission gear, coolant temperature, fuel level, and tire pressure. For example, vehicle speed is measured by a wheel speed sensor installed on the wheel hub, and the ECU converts the actual vehicle speed value, typically expressed in kilometers per hour (km / h). Fuel level is sensed by a level sensor in the fuel tank and converted into a remaining fuel volume or percentage that can be read on the central control screen.

[0037] Vehicle driving environment data describes the relevant characteristics of the vehicle's external environment, including geographic location, weather conditions, road type, and traffic congestion. Geographic location is precisely determined by the vehicle's onboard Global Positioning System (GPS) module and presented as longitude and latitude coordinates, with accuracy down to the meter level or higher. This allows the central control screen to identify the vehicle's location in specific city blocks or highway sections. Weather data, updated in real time through connectivity with online meteorological service platforms, covers weather types such as sunny, rainy, snowy, and foggy, along with corresponding parameters such as temperature, humidity, and wind speed. This helps the central control screen proactively prepare functional layouts for different weather conditions. Road type is determined based on onboard map data and GPS trajectory analysis, distinguishing between urban roads, highways, and rural trails. Different roads have different requirements for navigation and warning functions. Traffic congestion levels are intuitively reflected by real-time traffic information services, combining color codes on the map (e.g., green for smooth traffic, yellow for slow traffic, and red for congested traffic) or congestion index values ​​to accurately reflect the current road's traffic efficiency. The geographic location data is continuously and automatically updated by the GPS module and transmitted to the central control screen in real time; the weather condition data requires the built-in networking function module of the central control screen to regularly (e.g., every 15 minutes) initiate query requests to the selected meteorological service platform, receive and parse the returned weather data; the road type and traffic congestion level information comes from the real-time update of the on-board map software on the one hand, and on the other hand, a comprehensive judgment is made based on the vehicle's own operating status data such as driving speed and acceleration. For example, long periods of low-speed driving with frequent starts and stops may indicate traffic congestion, while stable high-speed driving with small road curvature is likely to indicate a highway environment.

[0038] Driver image data is captured by in-vehicle cameras, including visual images of the driver's face, eyes, and body movements. This information is then processed by image recognition algorithms and converted into meaningful feature data. Facial features can be used to identify the driver and ensure accurate access to personalized settings. Eye features focus on factors such as eyelid closure frequency, eye movement direction, and amplitude to determine driver fatigue. Normally, eyelids close 10-20 times per minute; exceeding a certain threshold (e.g., 30 or more times per minute) may indicate fatigue. Body movements monitor the position of the driver's hands on the steering wheel and whether they frequently adjust their sitting position, assisting in determining driving comfort and concentration. For example, prolonged deviation from the standard grip on the steering wheel may indicate a need for more convenient control assistance features. A high-definition camera is typically mounted above the windshield or dashboard, capturing the driver's image at 25-30 frames per second. The image data is transmitted in real time to the image processor built into the central control screen. The image processor runs advanced deep learning image recognition algorithms, such as face, eye, and body recognition models based on convolutional neural networks (CNN), to extract and analyze features from each frame of the image, converting the raw image data into structured driver image data for use in subsequent steps.

[0039] Step S22: determining a recommended layout type according to the layout reference data.

[0040] In this embodiment, the decision model is an intelligent judgment system based on preset logical rules and algorithms. It takes acquired layout reference data as input and, through a series of complex calculations and judgment processes, outputs a corresponding recommended layout type. This model, pre-installed in the vehicle's central control screen's memory chip, covers the matching relationships between layout reference data and recommended layout types for a wide range of different scenarios. These relationships are derived through analysis and simulation of extensive real-world driving data, as well as the experience of professional drivers. For example, the model specifies that when the vehicle speed is above 100 km / h, on a highway, and the driver's eye closure frequency is normal, a "Long-Distance Highway Driving Layout" is recommended. This layout emphasizes navigation information stability, vehicle powertrain parameter monitoring, and continuous music playback to meet the needs of long-distance driving. Alternatively, when the weather is rainy or snowy, traffic congestion is high, and the driver's body movements indicate discomfort, a "Severe Weather Congestion Driving Layout" is recommended. This layout prioritizes components such as wiper control, defogger, real-time road condition analysis, and seat heating and ventilation adjustments to enhance driving safety and comfort. Once the vehicle's central control screen acquires the latest layout reference data, it immediately feeds this data into the decision model. The decision model first standardizes each data item, aligning it with a unified format and value range to facilitate subsequent calculations. Next, it analyzes and judges vehicle operating status data, driving environment data, and driver image data in a predetermined order of priority. For example, if vehicle operating status data is prioritized, and speed data indicates the vehicle is traveling at high speed, the model will initially screen several layout type candidates suitable for high-speed scenarios. It then combines subsequent driving environment data (such as weather and road type) and driver image data (such as fatigue status) to further narrow the selection range and ultimately determine a single recommended layout type. The entire calculation process is efficiently completed within the core processor area of ​​the central control screen, typically taking less than 1 second, ensuring timely response to the driver's interface switching needs.

[0041] Step S23 : selecting the target layout information corresponding to the recommended layout type from the layout information.

[0042] In this embodiment, layout information storage and management involves the organization, storage, and retrieval of all pre-stored layout information on the in-vehicle central control screen. Pre-stored layout information is stored in a specific data structure within the central control screen's high-capacity flash memory chip. Each layout has a unique identifier (ID) and an associated layout type tag. This layout information includes detailed attributes for each widget on the interface, including key elements such as the widget name, function description, coordinate position on the interface (in pixels), area occupied (length and width in pixels), display style (color, font, icon, etc.), and data source link (pointing to the application or vehicle system module that provides the widget data). For example, the navigation widget in the "Long-Distance Highway Driving Layout" has an ID of 001 and is located in the center of the screen. It measures 400 pixels long by 300 pixels wide, displays a high-definition map style, and its data source links to the in-vehicle navigation system. The music player widget, with an ID of 002, is located in the lower right corner of the screen. Its smaller size makes it easier to use with one hand, and its data source links to the multimedia playback system.

[0043] Once the recommended layout type is determined, the central control screen's search module quickly activates, using the recommended layout type as a keyword to perform a rapid search and match within the flash memory chip storing layout information. Using efficient indexing algorithms, such as those based on a B-Tree index structure, it locates all layout information entries matching the recommended layout type. Then, based on pre-set priority rules (such as prioritizing recently used and customized layouts, and if none exist, selecting the factory default layout with the highest priority), the final target layout is selected from the matching layouts. Once selected, all relevant data for the target layout is loaded into the central control screen's memory buffer, preparing for the next step in the interface generation and rendering process.

[0044] Through the above detailed implementation methods, the vehicle's central control screen can intelligently and efficiently select the target layout information that best suits the current driving scenario based on various accurately acquired layout reference data, thereby providing the driver with a more personalized and convenient central control screen control experience, significantly improving driving safety and comfort.

[0045] Optionally, step S22 includes: step S221, if there is abnormal data in the vehicle operation status data, determining that the recommended layout type is an abnormal prompt layout.

[0046] In this embodiment, vehicle operating status data refers to a collection of information collected in real time by the vehicle's electronic control unit and its connected sensors, reflecting the operating status of various vehicle systems. This information includes, but is not limited to, parameters such as vehicle speed, engine speed, coolant temperature, fuel level, and tire pressure. These parameters are transmitted to the vehicle's central control screen via an onboard network, such as the CAN bus, in a specific data format and frequency. Abnormal data refers to data in which one or more key parameters in the vehicle's operating status data deviate from the normal operating range. The normal operating range is a threshold range determined based on vehicle design specifications, safety standards, and statistical analysis of a large amount of actual operating data, used to measure whether the vehicle is in a healthy operating state. For example, the normal engine coolant temperature range for a typical family car is 80-105°C; data outside this range is considered abnormal. Abnormal notification layout: This is a specific interface layout pre-designed and stored in the vehicle's central control screen. It is specifically designed to display fault information, warning signs, and corresponding treatment suggestions to the driver in a prominent and intuitive manner when the vehicle experiences an operating anomaly. Its interface elements usually include a large red warning area, a prominent fault icon, concise and clear text descriptions, and operable emergency buttons such as calling for help and viewing detailed fault information.

[0047] The vehicle's central control panel contains a dedicated data receiving and monitoring module that reads vehicle operating status data from the CAN bus at regular intervals (e.g., 100 milliseconds). This module compares each received data item against the corresponding normal range thresholds stored in the central control panel's internal memory. The comparison algorithm utilizes an efficient binary search. If a parameter value exceeds the upper limit of its normal range or falls below the lower limit, the corresponding vehicle operating status data is immediately determined to be abnormal. The abnormal parameter's name, current value, and the direction of the threshold (above the upper limit or below the lower limit) are recorded. For example, if the engine coolant temperature reads 110°C, while the internally stored upper limit is 105°C, the coolant temperature is considered abnormal and recorded as "Coolant temperature, 110°C, above the upper limit." Once the monitoring module determines that the vehicle operating status data is abnormal, the central control panel's layout management system is immediately activated. This system first queries an internally stored layout mapping table, which uses the abnormal parameter name as an index and associates the corresponding abnormality notification layout ID. For example, if the coolant temperature is determined to be abnormal, the mapping table searches for the corresponding layout ID, "Coolant temperature abnormality notification layout," with ID 001. After finding the corresponding layout ID, the layout management system marks the exception warning layout as a recommended layout type and notifies the central control screen's graphics rendering module to prepare to render this layout. Simultaneously, detailed information from the exception data (such as fault parameters, current values, and threshold violations) is passed to the exception warning layout's data source, enabling accurate population of fault information and handling suggestions during rendering. For example, for a coolant temperature anomaly, the data source generates a text description, "Engine coolant temperature is too high, current temperature 110°C, please stop and check the cooling system," along with a steaming water tank icon as a warning.

[0048] Step S222: If there is no abnormal data in the vehicle operating status data, determine the driver's mood index based on the driver image data.

[0049] In this embodiment, driver image data refers to real-time visual image information of the driver's face, eyes, head, and other parts captured by a high-definition camera installed in the vehicle (typically located above the front windshield or dashboard). This data is converted into structured data through a series of image preprocessing and recognition algorithms. This data reflects features such as the driver's facial expressions, eye contact, and head posture, and is used to infer the driver's emotional state. Image preprocessing refers to a series of operations performed on the raw images captured by the camera to improve image quality, remove noise, and enhance key features, providing a good data foundation for subsequent image recognition algorithms. Common preprocessing operations include grayscale conversion, image noise reduction, and size normalization. For example, grayscale conversion converts color images into grayscale images, reducing data volume while highlighting features such as facial contours. Image noise reduction uses methods such as Gaussian filtering to remove random noise from the image, making the image clearer. Image recognition algorithm refers to an algorithm system built on deep learning models such as convolutional neural networks (CNNs) to extract features such as the driver's facial expressions, eye movements, and head posture from the preprocessed images and convert these features into emotionally meaningful classification results. For example, by training on a large number of driver image samples labeled with different emotions, a CNN model can accurately identify facial, eye, and head patterns corresponding to emotional states such as happiness, sadness, anxiety, and calmness. The mood index is a numerical indicator that quantifies a driver's emotional state, ranging from 0 to 10, with 0 indicating extreme frustration, anxiety, or fatigue, and 10 indicating extreme joy and relaxation. It is calculated using a pre-set weighting algorithm based on the emotional characteristics reflected in the driver's image data, providing a direct reflection of the driver's current mood. A weighting algorithm is a mathematical method that combines different emotional features in the driver's image data according to specific weights. Different emotional features contribute to the mood index to varying degrees. For example, facial expression may be assigned a weight of 0.5 because it is the most intuitive representation of emotion; eye movements may be assigned a weight of 0.3 because they are more sensitive to subtle changes in emotion; and head posture may be assigned a weight of 0.2 to assist in determining the overall emotional tendency. This weighting method is used to comprehensively determine the driver's mood index.

[0050] When the vehicle is started, the in-car camera automatically activates and continuously captures images of the driver at a rate of 25-30 frames per second. These images are transmitted via a high-speed USB cable to the image processor built into the vehicle's central control screen. The image processor first performs grayscale conversion on the received images, converting color images to grayscale to simplify subsequent calculations. Next, Gaussian filtering is used to reduce noise caused by factors such as lighting and camera shake. The images are then resized to a fixed size, such as 224×224 pixels, to facilitate input into the CNN model. These preprocessed images are then fed into a pretrained CNN model, which extracts and classifies features such as facial expressions, eye movements, and head posture. The model outputs a vector containing the driver's emotional characteristics, which is updated every second and represents the driver's current image state. After receiving the driver's emotional feature vector output by the CNN model, the central control screen initiates the mood index calculation module. The module first parses the vectors and extracts emotion scores corresponding to facial expressions, eye movements, and head posture. These scores are based on the emotion classification criteria set during model training. For example, a happy facial expression is assigned a score of 8, a calm eye movement is assigned a score of 7, and a normal head posture is assigned a score of 8. Then, using a preset weighting algorithm, the facial expression, eye movement, and head posture scores are multiplied by their corresponding weights and summed to produce a mood index. For example, if the facial expression score is 6, the eye movement score is 5, and the head posture score is 6, then the mood index = 6 × 0.5 + 5 × 0.3 + 6 × 0.2 = 5.7. The calculated results are updated every second, reflecting the driver's mood changes in real time.

[0051] Step S223: determining the type of environment in which the vehicle is located based on the vehicle driving environment data, wherein the environment types include highway, urban area, rural area, competition and market.

[0052] In this embodiment, vehicle driving environment data refers to a collection of information describing the vehicle's external operating environment, acquired through the vehicle's GPS, onboard mapping software, various environmental sensors (such as light sensors and millimeter-wave radar), and interactions with external networks such as traffic information centers. This information includes geographic location (latitude and longitude coordinates), road type (freeway, urban road, rural road, etc.), traffic conditions (congestion level, vehicle speed distribution, etc.), surrounding facilities (shopping malls, gas stations, schools, etc.), and weather conditions (sunny, rainy, snowy, foggy, etc.). Onboard mapping software data: Onboard mapping software contains a vast amount of built-in geographic information, including information on road networks of varying levels and points of interest (POIs). Combined with the vehicle's real-time location information, this data can be used to determine the vehicle's road type and surrounding facilities. For example, if the vehicle's GPS coordinates are on a highway section identified by the mapping software, the vehicle can be determined to be traveling on a highway. If a nearby POI search reveals a large number of shopping malls and restaurants, the vehicle is located in a bustling urban area. Traffic Condition Data: This data, collected through on-board millimeter-wave radar, cameras, and connections to traffic information centers, reflects information such as vehicle density, average speed, and congestion levels. For example, millimeter-wave radar can monitor the number and distance of vehicles ahead in real time, while cameras can identify road signs and traffic light status. Combined with macro-traffic data provided by the traffic information center, these data can be used to comprehensively assess road congestion, using colors such as green for smooth traffic, yellow for slow traffic, and red for congested traffic. Environment Type: This data categorizes the vehicle's external operating environment, including highways, urban areas, rural areas, racetracks, and markets. Different environment types have different traffic rules, driving requirements, and functional priorities. For example, highway environments require accurate navigation, stable speed monitoring, and long-distance driving assistance; urban environments emphasize real-time traffic conditions, parking guidance, and local services; rural environments prioritize road navigation, signal enhancement, and emergency rescue; racetracks focus on vehicle performance monitoring, track maps, and lap time tracking; and market environments prioritize pedestrian warnings, slow-moving maneuvers, and nearby shopping information.

[0053] After the vehicle's central control screen analyzes the vehicle's driving environment data, the environmental assessment module determines the vehicle's driving environment type based on pre-defined environmental assessment rules, taking into account multiple factors including geographic location, road type, traffic conditions, surrounding facilities, and weather conditions. For example, if the vehicle's GPS coordinates are on a highway, the vehicle speed is stable above 80 km / h, traffic conditions are smooth, there are no dense commercial facilities nearby, and the weather is clear, the environmental assessment module determines that the vehicle is in a highway environment. If the vehicle is located in a busy urban area surrounded by numerous shopping malls and restaurants, traffic is congested, and the speed is low, the vehicle is determined to be in an urban environment. If the vehicle is in a remote rural area with narrow roads, low traffic volume, and many farmlands nearby, the vehicle is determined to be in a rural environment. If the vehicle is near a racetrack with numerous race cars and spectator facilities nearby and the speed is high, the vehicle is determined to be in a racing environment. If the vehicle is near a farmers' market with heavy traffic, slow speeds, and signs of street vendors nearby, the vehicle is determined to be in a market environment.

[0054] Step S224: determining the recommended layout type according to the mood index and the environment type.

[0055] In this embodiment, the layout matching rule base: a set of pre-set rules stored in the flash memory chip of the vehicle's central control screen, establishes a correspondence between the mood index, the environment type and the recommended layout type. These rules are based on a large number of driving scenario simulations, user surveys and professional driving experience summaries, and are intended to provide the driver with a central control screen interface layout that best fits the current mood and driving environment. Correspondence: refers to different mood index ranges and environment type combinations, each corresponding to a unique recommended layout type. For example, when the mood index is between 8-10 and the environment type is urban, the recommended layout type is "pleasant urban commuting layout"; if the mood index is between 3-5 and the environment type is high-speed, the recommended layout type is "soothing long-distance driving layout". This correspondence is organized in the form of a lookup table to facilitate quick retrieval and matching.

[0056] During the development phase of the in-vehicle central control screen, the R&D team collected extensive driving scenario data, including real-world examples of different drivers in various moods and environments. Using data analysis tools, they extracted key features and, incorporating professional driving knowledge, developed initial layout matching rules. Subsequently, through multiple rounds of field testing, the team invited drivers of varying ages, genders, and driving habits to try out the system. The rules were then refined based on their feedback. For example, the team discovered that some drivers with a mood index of 6-7 and experiencing urban congestion preferred a simple, clear layout that prioritized music playback and real-time traffic conditions. Consequently, the rules were adjusted accordingly. Ultimately, the refined rules were coded into the central control screen's flash memory chip, forming a layout matching rule library that provides a solid foundation for subsequent real-time layout recommendations. Recommended layout type: Based on the driver's current mood index and the vehicle's environment, the optimal layout for the in-vehicle central control screen is accurately retrieved from the layout matching rule library. This layout integrates relevant functional components to optimize the interface display and meet the needs of specific scenarios. For example, if the driver's mood index is 7 and the vehicle is in a rural environment, a "Comfortable Rural Driving Layout" is retrieved from the rule base. This layout might enlarge the navigation map scale, highlight nearby farmhouses, and provide soft music playback, allowing the driver to enjoy a pleasant rural drive. After the central control screen receives the current driver's mood index and the vehicle's environment type, the recommended layout module is activated. This module uses the mood index and environment type as dual indexes to quickly search and match within the layout matching rule base. Leveraging efficient hash tables or B-tree indexing algorithms, the corresponding recommended layout type is typically found within a few milliseconds. Once found, the recommended layout type is marked and passed to subsequent steps, preparing for target layout selection and interface generation and rendering, ensuring the driver is presented with the most appropriate central control screen interface at the moment. For example, if the recommended layout type is "Pleasant Urban Commute Layout," the recommended layout module passes this type information to the layout selection subsystem. This subsystem selects a specific target layout from the stored layout information based on the type and notifies the graphics rendering module to prepare for rendering.

[0057] Through the above detailed implementation methods, the vehicle's central control screen can closely integrate the vehicle's operating status, driver's emotions and driving environment, intelligently and accurately determine the recommended layout type, and then create a personalized and scenario-based central control screen control experience for the driver, effectively ensuring driving safety and comfort.

[0058] Based on any of the above embodiments, in the third embodiment of the present application, after step S22, the following steps are included:

[0059] Step S24, determining the layout type of each of the layout information, and if the layout type identical to the recommended layout type does not exist, determining the components to be displayed according to the layout reference data;

[0060] Step S25, determining a target component based on the components to be displayed, the size of each component to be displayed, and the panel size of the vehicle-mounted central control screen;

[0061] Step S26: determining the target layout information according to the target component.

[0062] In this embodiment, layout type is a classification summary of layout information, which is used to distinguish the layout modes of the central control screen interface under different usage scenarios or functional emphases. Common layout types include long-distance driving layout, urban commuting layout, entertainment and leisure layout, etc. The layout information of different layout types differs significantly in component selection and layout design to adapt to the needs of drivers in corresponding scenarios. For example, the long-distance driving layout will focus on components such as navigation information, vehicle status monitoring (such as fuel consumption, tire pressure), and fatigue driving reminders, and these components will occupy a larger and more conspicuous position on the interface, so that the driver can pay attention to key information at any time; while the entertainment and leisure layout may place entertainment components such as music playback, video playback, and games in the core area, with a colorful display style to enhance the entertainment experience.

[0063] After the in-vehicle central control screen is powered on and the system is initialized, the layout management module reads all pre-stored layout information from the storage system (such as a flash memory chip). This layout information is stored in a specific data structure, and each layout information is accompanied by a tag field that identifies its layout type. The layout management module traverses all layout information, extracts and records the layout type of each layout information, constructs a layout type list, and stores it in memory for subsequent quick query. After determining the recommended layout type according to the previous process, the system searches for a match in this layout type list. If no identical layout type is found, the next step is triggered, which is to determine the components to be displayed based on the layout reference data.

[0064] Components to be displayed: A collection of functional components suitable for the current driving scenario and required to be displayed on the central control screen, derived from a comprehensive assessment of layout reference data. For example, when a vehicle is driving on a mountain road, the driving environment data indicates complex road conditions, and the driver's image data indicates a focused expression. In this case, the navigation component, vehicle status monitoring component (particularly tire pressure and brake system status), and signal strength indicator component may be identified as components to be displayed to ensure driving safety. Another example is that in a congested city, if the driver's image data indicates fatigue, the music player component, real-time traffic information component, and surrounding life service components (such as nearby coffee shop recommendations) may be identified as components to be displayed, both to relieve driver fatigue and facilitate navigation through traffic jams.

[0065] The in-vehicle central control screen incorporates an intelligent decision-making algorithm module, which receives the latest layout reference data as input. The algorithm first analyzes vehicle operating status data. If it detects unusual speed fluctuations, elevated engine temperatures, or other potential faults, it immediately adds components such as vehicle fault diagnosis and emergency rescue to the set of components to be displayed. It then considers vehicle driving environment data and selects appropriate navigation, road condition, and weather warning components based on geographic location (e.g., urban, rural, highway), road type (main road, minor road, freeway), traffic congestion level (smooth, slow, congested), and weather conditions (sunny, rainy, snowy, foggy, etc.). Finally, based on the driver's emotional state (e.g., anxiety, fatigue, or joy) as reflected in the driver's image data, it adds components such as music playback, entertainment and relaxation, or alerts. For example, on a rainy day in congested city traffic, if the driver's image data indicates anxiety, the algorithm might select components to display, including precise navigation, real-time traffic analysis, wiper control, music playback for relaxation, and nearby parking search. Component size: The physical space occupied by each component to be displayed on the central control screen interface, usually measured in pixels for length and width. The setting of component size must take into account the needs of the component's own functional display, ensuring that the information is complete, clear and readable, while also taking into account the aesthetics and rationality of the overall layout of the central control screen. For example, a navigation map component may require a larger size, such as 400 pixels long by 300 pixels wide, in order to clearly present map details, route planning, and navigation instructions. On the other hand, a simple volume adjustment icon component, due to its intuitive operation and single function, may only require a smaller size, such as 30 pixels long by 30 pixels wide.

[0066] In addition to the functional logic code, the in-vehicle central control screen's storage system also stores default component size data for each component to be displayed. Once the components to be displayed are determined, the system retrieves this default size information from storage and constructs a component size list in memory, recording the dimensions of each component to be displayed. Simultaneously, the system interacts with the display panel driver module to obtain the in-vehicle central control screen's panel size information, typically expressed as the screen's diagonal length (e.g., 10 inches corresponds to a resolution of 1920×1080 pixels) and the number of horizontal and vertical pixels. Target components: After comprehensively considering multiple factors, including the functional importance, size compatibility, and overall central control screen layout of the components to be displayed, the final set of functional components to be displayed on the current central control screen interface is determined. This represents an optimized subset of the components to be displayed. Due to the limited panel size of the in-vehicle central control screen, it is impossible to display all components to their ideal dimensions. Selection and adjustment must be made based on the actual situation. The target components represent this trade-off. For example, in a certain driving scenario, the components initially determined to be displayed include navigation, music playback, vehicle status monitoring, surrounding life services, weather warnings, etc. However, due to the size limitation of the central control screen, if all of them are displayed, the interface may be too crowded and the information may be messy. After analysis, the surrounding life service components are temporarily discarded (or their size is reduced and displayed briefly in the form of icons), and navigation, music playback, vehicle status monitoring, weather warnings, etc. are retained as target components, and their size and position are further optimized.

[0067] The layout optimization algorithm for the in-vehicle central control screen is activated, taking as input the list of components to be displayed, their sizes, and the panel dimensions of the in-vehicle central control screen. The algorithm first ranks the components by functional importance, based on the layout reference data described above and the priority of common driving scenarios. For example, in highway driving scenarios, navigation and vehicle status monitoring components are highly important, ranking highly. In congested urban areas, real-time traffic information and music playback components are more important.

[0068] After sorting, the algorithm begins with the most important components and attempts to place them on the central control screen. Based on the component size and the central control screen panel size, it uses layout planning algorithms (such as a greedy layout strategy that prioritizes filling key areas of the screen to avoid large blank or overcrowded areas) to allocate positions and adjust sizes. During this process, if it is found that adding a component will lead to an unreasonable interface layout (such as important information being blocked or action buttons being too cramped to click), the algorithm considers reducing its size or temporarily excluding it from the target components. After multiple rounds of iterative optimization, a set of target components with a reasonable layout and appropriate functionality is ultimately determined, and their final size and approximate location on the central control screen are recorded.

[0069] The layout generation module for the vehicle's central control screen is activated, taking as input the determined target components and their associated size, position, display style, data source, and other information. First, based on the number and size of the target components, the module uses a two-dimensional spatial layout algorithm (such as a layout algorithm based on binary tree partitioning, which gradually divides the central control screen space to accommodate the placement of each target component) to accurately calculate the coordinate position of each target component on the central control screen and record it in pixels. For example, if the navigation component is ultimately determined to be 350 pixels long by 250 pixels wide, the layout algorithm may calculate the coordinates of its upper left corner to be (50, 30), i.e., 50 pixels on the horizontal axis and 30 pixels on the vertical axis, indicating its specific placement on the central control screen.

[0070] Next, the module adjusts and optimizes the display style of the target components according to the current driving scenario requirements and driver preferences. For example, in daytime driving scenarios under strong sunlight, the font color is set to a dark, high-contrast color to ensure clear readability; in scenarios where the driver's attention needs to be reminded, the icons of certain important components are set to flash. At the same time, the module ensures that each target component is correctly connected to its corresponding data source, establishes a data connection with the corresponding on-board system module through the system's built-in communication protocol, and ensures real-time updates of component data. Finally, the target layout information containing all these key elements is stored in memory, ready to enter the subsequent interface generation and rendering process, that is, to convert the target layout information into the actual visible central control screen interface.

[0071] Through the above detailed implementation methods, when the vehicle-mounted central control screen encounters layout information that does not match the recommended layout type, it can adaptively and intelligently and reasonably generate the target layout information that is most suitable for the current driving scene based on the current rich and diverse layout reference data, greatly improving the driver's control experience and ensuring driving safety and comfort.

[0072] Based on any embodiment, in the fourth embodiment of the present application, step S30 includes:

[0073] Step S31: determining at least one first component in the first interface and at least one second component corresponding to the target layout information.

[0074] In this embodiment, the first component refers to the various functional modules presented on the currently displayed first interface. These functional modules exist in the form of visual components, such as a navigation bar component, a music player component, a vehicle status display component, etc. Each first component has a specific position, size, display style and corresponding functional logic. Together, they constitute the content of the first interface and provide the user with initial interactive information. The second component is the functional module to be displayed on the second interface to be switched based on the target layout information. Similar to the first component, the second component also covers a variety of functional types, but its selection and layout are based on the target layout information, aiming to meet the current driving scenario or the interaction requirements after changes in user needs. For example, in a long-distance driving scenario, the second component may strengthen the navigation and vehicle endurance information display components and weaken the entertainment components.

[0075] The in-vehicle central control screen system maintains an interface component management module. When an interface switch operation is triggered and the target layout information is determined, this module first parses the current primary interface. It traverses the display hierarchy of the primary interface, starting from the top-level container, and identifies each primary component according to predefined component identification rules. These identification rules are based on the component's type tag, layout attributes, and connection characteristics with the underlying data source. For example, if a module with a map icon, real-time interaction with the vehicle navigation system, and occupying a specific screen area is found, it is identified as a navigation bar component and recorded as a primary component. Information such as its position (expressed in screen pixel coordinates, such as (x1, y1) for the top left corner and (x2, y2) for the bottom right corner), dimensions (width w1 and height h1 in pixels), and display style (such as map color, text font, and icon style) are extracted and stored in a temporary memory data structure. Simultaneously, based on the target layout information, the system retrieves the corresponding secondary component information from the stored component library. The target layout information clearly includes a list of the second components to be displayed and their related layout properties. For example, for a target layout designed for urban commuting, it specifies that it must include a real-time traffic component, a local music playback component, a nearby parking lot query component, etc. According to the list, the system obtains the preset position (such as the upper left corner coordinates are (x3, y3), the lower right corner coordinates are (x4, y4)), size (width w2, height h2), display style (such as traffic color identification rules, music playback control button style) and other detailed information of each second component one by one, and also stores them in a temporary memory data structure to distinguish them from the first component information for subsequent processing.

[0076] Step S32: determining the same components in the first component and the second component.

[0077] In this embodiment, identical components are components that exist in both the first and second interfaces and have the same function. Although their position, size, and even display style may differ in the two interfaces, they essentially belong to the same functional module. For example, both interfaces have an audio component for controlling volume, but in the first interface it may be located in the lower left corner, smaller and simpler in style, while in the second interface it is moved to the upper right corner based on layout requirements, with a larger size and more eye-catching style to facilitate user operation. Identifying identical components helps achieve smooth transitions when switching between interfaces, reducing visual abruptness for users.

[0078] The system initiates a component comparison algorithm module, which takes the previously acquired and stored first and second component lists as input. The comparison algorithm first traverses the second component list for each first component, matching them based on the component's functional identifier. This functional identifier is a unique code assigned to a component during development to distinguish components with different functions, such as "NAV_001" for a navigation component and "MUSIC_001" for a music player component. When a component with the same functional identifier as the first component is found in the second component list, it is determined to be an identical component and marked from both lists and recorded in a dedicated identical component set. For example, if there is a volume adjustment component with the identifier "VOLUME_001" in the first component list, and a component with the same identifier is found when traversing the second component list, then this volume adjustment component is confirmed to be an identical component and added to the identical component set. At the same time, a matching mark is made at the corresponding position in the two original lists to avoid repeated comparisons.

[0079] Step S33: determining the displacement of each identical component from the position of the first interface to the position of the second interface.

[0080] In this embodiment, displacement describes the change in coordinates of the same component when it moves from its position in the first interface to its position in the second interface, measured in screen pixels. It consists of a horizontal displacement (Δx) and a vertical displacement (Δy). The horizontal displacement is equal to the horizontal coordinate of the component's top left corner in the second interface minus the horizontal coordinate of the component's top left corner in the first interface. The vertical displacement is equal to the vertical coordinate of the component's top left corner in the second interface minus the vertical coordinate of the component's top left corner in the first interface. Accurately calculating the displacement is key to achieving smooth component animation transitions, allowing users to intuitively experience the continuity of interface switching.

[0081] For each component tagged in the same component set, the system calculates the displacement using its position information stored in the first and second interfaces. Given the coordinates of the top-left corner of a component in the first interface (x1, y1) and the coordinates of the top-left corner of the corresponding component in the second interface (x3, y3), the horizontal displacement Δx = x3 - x1, and the vertical displacement Δy = y3 - y1. The system calculates the displacement for each component using this formula and stores the result in a displacement list as a structure (containing the component identifier, Δx, and Δy) for subsequent rendering steps. For example, if an audio player component moves from position (10, 20) in the first interface to position (50, 60) in the second interface, the calculated horizontal displacement is 40 pixels and the vertical displacement is 40 pixels, recorded in the displacement list as {"AUDIO_001", 40, 40}.

[0082] Step S34: rendering the same component based on the displacement, and rendering the remaining components in the second component except the same component, so as to render the second interface.

[0083] In this embodiment, the graphics rendering module of the vehicle's central control screen is activated, receiving as input a list of displacement values ​​and a second component list (containing marked identical components and remaining components). First, for identical components, the graphics rendering module utilizes the GPU's graphics animation capabilities to set a movement animation path for each identical component based on the Δx and Δy values ​​in the displacement list. For example, for a navigation component with displacements {"NAV_001", 30, 20}, the GPU will gradually move the navigation component from its initial position on the first interface by 30 pixels horizontally and 20 pixels vertically at a preset animation frame rate (e.g., 60 frames per second) during each rendering frame, until it reaches the target position on the second interface, achieving a smooth transition. Simultaneously, during this movement, the navigation component's appearance, such as color and font, is updated in real time based on the component's preset display style on the second interface, ensuring consistency with the overall style of the second interface. For all components in the second component list, excluding identical components, the graphics rendering module renders them directly according to their preset positions, sizes, and display styles on the second interface. Since these components do not require a positional transition, they only need to be drawn once at the corresponding locations on the second interface. For example, if there is a newly added surrounding life service component in the second interface, the graphics rendering module will quickly fill in pixels at the corresponding position on the central control screen based on its preset upper left corner coordinates (x5, y5), size (width w3, height h3) and unique display style (such as colorful icons and eye-catching text logos), and draw the image of the component to make it fully presented. Through the above collaborative rendering operations, the switched second interface is finally fully presented on the in-vehicle central control screen, bringing users a smooth and natural interface switching experience. At the same time, since the same components are rendered independently before rendering, the in-vehicle central control screen does not need to repeatedly obtain the data required by the components, thereby improving the speed of interface switching.

[0084] Through the above detailed implementation methods, when switching interfaces, the vehicle-mounted central control screen can methodically handle the relationship between the first interface and the second interface components based on the target layout information, and achieve smooth switching of the interfaces by accurately calculating the displacement and rendering it reasonably, thereby greatly improving the user operation experience and making it more in line with the needs of driving scenarios.

[0085] Optionally, step S34 includes:

[0086] Step S341: Determine component requirement data of each of the remaining components.

[0087] In this embodiment, "remaining components" refers to components within the second interface corresponding to the target layout information, excluding those components that share the same functionality as the first interface. These components are introduced to meet new layout requirements, driving scenarios, or user preferences, each with unique functionality, such as a vehicle health diagnostic component, a nearby gas station search component, or a personalized theme switching component. Component-required data refers to the specific data sources required for each remaining component to function properly and accurately display information. Different remaining components rely on different types of data, which are closely related to their functionality and are key to their practicality. For example, the instrument cluster component requires real-time operating data such as vehicle speed, engine speed, and fuel consumption from the vehicle's electronic control unit; the music component requires information such as the playlist, the title of the currently playing song, the artist, duration, and progress from the vehicle's multimedia system; and the vehicle health diagnostic component retrieves potential problem information such as abnormal tire pressure and engine fault codes from the vehicle's fault diagnosis module.

[0088] The in-vehicle central control screen has a built-in component data management module. When rendering the secondary interface, this module first analyzes the data requirements of each remaining component. This module relies on a component information database pre-stored in the central control screen system. This database records detailed data requirements for each component type, including data name, data format, and data source identifier. For example, for a smart navigation component, the database records its data requirements: real-time location coordinates (in latitude and longitude format, with the data source identified as "NAV_SYSTEM"), destination information (in text format, with the source identified as "USER_INPUT_OR_HISTORY"), and traffic information (in color coding or congestion index, with the source identified as "TRAFFIC_INFO_SERVICE"). The component data management module, based on this database, analyzes the component requirements of each remaining component, compiles these requirements into a data request list, and stores it in memory in preparation for the next data acquisition operation.

[0089] Step S342: Obtain the component demand data from the vehicle controller based on the vehicle central control bus.

[0090] In this embodiment, the vehicle central control bus (ECU) is a collection of physical links and communication protocols used to enable high-speed, stable communication between various electronic control units (ECUs) and the vehicle's central control screen within the vehicle's electronic system. Examples of ECUs include the CAN bus (Controller Area Network Bus) and the LIN bus (Local Interconnect Network Bus). Through the ECU, the central control screen can send data requests to key vehicle controllers, such as the engine controller, transmission controller, and body controller, and receive feedback from them. A vehicle controller generally refers to an electronic control unit (ECU) responsible for managing and controlling a specific system or function. These ECUs are located throughout the vehicle and monitor and control the vehicle's operating status in real time. For example, the ECU controls core engine parameters such as fuel injection and ignition timing, while also providing operating data such as engine speed and coolant temperature. The body controller controls vehicle components such as doors, windows, and lights, and also provides feedback such as door closure and light status. The tire pressure monitoring system controller monitors tire pressure and, if an abnormality is detected, promptly alerts the relevant systems and provides specific pressure readings.

[0091] After the central control panel's component data management module generates a data request list, the communication module activates. Based on the source identifier for each data request in the list, this module identifies the corresponding vehicle controller and establishes a connection with it via the vehicle's central control bus. For example, to obtain vehicle speed data from the instrument cluster component, the communication module identifies the speed data as originating from the ECU. It then sends a data packet with a specific request identifier to the ECU via the CAN bus. The request format adheres to the standard CAN bus protocol, using a standard frame format. The frame ID is a code specifically reserved for speed data requests (e.g., 0x100), and the data field contains a detailed description of the request (e.g., "REQUEST_SPEED_DATA"). Upon receiving the request, the vehicle controller, following its own processing flow, extracts the corresponding speed data from internal storage or real-time monitoring data. It then sends a response packet containing the speed data back to the central control panel, also following the CAN bus protocol. The central control panel's communication module receives and parses these packets, extracting the speed data and storing it in the corresponding instrument cluster component's data buffer for subsequent rendering.

[0092] Step S343: If empty data is received from the vehicle controller, replacement data associated with the component requirement data is determined.

[0093] In this embodiment, empty data refers to the situation where the central control screen requests component required data from the vehicle controller through the on-board central control bus, but the vehicle controller is unable to provide valid data due to various reasons (such as the controller is not configured with the corresponding function, sensor failure, temporary interruption of the communication link, etc.), and the returned data packet has no actual content or only contains an error identifier. For example, when requesting data from an advanced driver assistance system from the vehicle controller of an older model, since the vehicle is not equipped with this system at all, the vehicle controller may return a data packet with only the error code "0xFF", indicating that the required data cannot be provided. This is an empty data situation. Replacement data refers to data generated by a pre-set backup data source or calculation method in order to ensure that the remaining components can still display information normally on the second interface when receiving empty data, without blank spaces or error prompts. The determination of replacement data requires comprehensive consideration of the functional characteristics of the component, user experience, and other available data sources. For example, when real-time vehicle speed data cannot be obtained from the vehicle controller, if the central control screen itself has a GPS module, the positioning data of the GPS module combined with the time interval can be used to estimate the vehicle speed as replacement data; for example, if the music component cannot obtain the currently playing song information from the in-vehicle multimedia system, it can switch to an online music platform and use the user's previous playback history or popular recommended song information as replacement data to maintain the basic function display of the music component.

[0094] After receiving data from the vehicle controller, the central control panel's communication module features a dedicated data validation submodule to determine whether the data is empty. This submodule uses pre-defined empty data detection rules, such as checking whether the packet length is zero or whether it contains only specific error flags. If the data is empty, it immediately triggers the replacement data determination process. The component data management module then restarts, using the component requirement data for the empty data as a clue to query the central control panel's built-in replacement data knowledge base. This knowledge base, accumulated during the central control panel's development process based on different vehicle models, potential empty data scenarios, and corresponding feasible replacement solutions, is stored in the form of a lookup table. For example, regarding vehicle speed data requirements, the knowledge base records: If the CAN bus request to the ECU for vehicle speed data is empty, it attempts to obtain positioning data from the GPS module and calculate the vehicle speed using the distance formula and time difference between two points. If the music playback information obtained from the in-vehicle multimedia system is empty, it connects to an online music platform, queries the user's play history, and retrieves the previous song information as a replacement. The component data management module follows the guidance of the knowledge base to determine the replacement data source or calculation method corresponding to the current empty data component requirements, records it, and prepares for the next data acquisition or calculation operation.

[0095] Step S344: Calculate the component requirement data based on the replacement data, and render the remaining components based on the component requirement data.

[0096] In this embodiment, the component requirement data is calculated: after the replacement data is determined, since the form or source of the replacement data may not be completely consistent with the original component requirement data, it is necessary to use certain mathematical formulas, logical algorithms or data conversion operations to process the replacement data into component requirement data that meets the normal display requirements of the remaining components. For example, when using the positioning data of the GPS module to calculate the vehicle speed, it is necessary to first convert the latitude and longitude coordinate difference into the actual distance (using a suitable distance calculation formula based on factors such as the curvature of the earth), and then divide it by the time interval to obtain the vehicle speed data in kilometers per hour. This is a typical process for calculating component requirement data. Render the remaining components: fill the component requirement data obtained or calculated through the above steps into the corresponding remaining components, and use the graphics processing unit and related graphics library of the central control screen to present the component requirement data in a visual form according to the preset layout and display style of the component, and finally complete the complete rendering of the second interface. For example, the calculated vehicle speed data is filled into the vehicle speed display area of ​​the instrument panel component, and a vehicle speed instrument panel image with numbers, pointers and other elements is drawn through the graphics processing unit, so that the current vehicle speed information is accurately and prominently displayed on the second interface; for another example, the song information obtained from the online music platform is filled into the music component, and a music playback interface containing elements such as song title, singer, and playback progress bar is drawn, so that users can operate the music playback function normally.

[0097] If the replacement data source is determined to require calculation, the central control screen's calculation module is activated. Based on the replacement data type and the corresponding component's required data, it selects an appropriate mathematical formula or algorithm for calculation. For example, using the GPS module to calculate vehicle speed, the calculation module first obtains the latitude and longitude coordinates of two consecutive GPS locations within a certain time interval (e.g., 5 seconds). It then uses the Haversine formula to calculate the actual distance between the two points. This distance is then divided by the 5-second interval to obtain the vehicle speed value. The result is formatted according to the instrument panel component's required data format (e.g., a floating-point number with one decimal place) and stored in the instrument panel component's data buffer. If the replacement data originates from another data source, such as song information from an online music platform, the component data management module directly formats the acquired data according to the music component's format requirements and also stores it in the corresponding buffer. Finally, the central control screen's graphics rendering module is activated. Based on the component's required data in the data buffer of each remaining component, combined with the component's preset layout (e.g., position on the secondary interface, area occupied), and display style (e.g., font, color, and icon style), it utilizes the graphics processing unit's graphics rendering capabilities to convert the component's required data into a visual image. Taking the instrument panel component as an example, the graphics processing unit adjusts the angle of the instrument panel pointer according to the numerical size of the vehicle speed data, and draws clear vehicle speed dials, digital displays and other elements, so that accurate vehicle speed information can be presented on the second interface; for the music component, the graphics processing unit draws the song information display area, play button, progress bar, etc., and displays the song title, singer, playback progress and other information to the user in an intuitive form. Through these collaborative operations, the second interface is finally fully rendered, providing users with a coherent and reliable central control screen display effect.

[0098] Through the above detailed implementation method, even when the third-party central control screen faces difficulty in reading the original vehicle data, it can still ensure the complete and accurate display of the second interface by reasonably determining the replacement data, cleverly calculating the component requirement data and accurately rendering the remaining components, greatly improving the user experience and adapting to diverse vehicle configurations and driving scenarios.

[0099] Based on any of the above embodiments, in the fifth embodiment of the present application, after step S30, the following steps are included:

[0100] Step S40: switch the background image.

[0101] In order to further enhance the user's customized programs and the intelligence of the vehicle's central control screen, after the second interface is generated, the background image of the interface can also be adaptively generated.

[0102] Optionally, step S40 includes:

[0103] Step S41: Acquire voice data in response to a triggering operation of a background generation control in the second interface.

[0104] In this embodiment, the background generation control is a visual element on the second interface of the vehicle's central control screen that is specifically used to trigger the adaptive background generation function. It is typically presented to the user as an icon, button, or a specific area. It is designed to make it easy for users to activate this function when they need to customize the interface background. For example, it can be a circular icon with the text "Customize Background" located in the lower right corner of the screen. Clicking this icon initiates the background generation process. Alternatively, it can be a drop-down menu option at the top of the screen. Selecting the "Voice-Generated Background" sub-option under "Background Settings" also triggers the control. Voice data refers to the audio information clips recorded by the user through the vehicle's microphone to convey the background generation instructions to the vehicle's central control screen. This voice data contains the user's desired description of the interface background, preferred elements, and scene adaptation requirements. It is received by the vehicle's audio acquisition module in the form of audio waveforms. For example, a user might say, "I want a seaside sunset background, perfect for night driving." This sound containing textual meaning constitutes voice data.

[0105] The vehicle's central control screen system monitors the operational status of each control on the second interface in real time. When it detects that the background generation control has been triggered (such as the user clicking the background generation icon), the audio acquisition module is immediately activated. The audio acquisition module is connected to the microphone in the car and collects ambient sound at a preset audio sampling frequency (such as 16kHz) and quantization accuracy (such as 16 bits) for a period of time (usually set to 5-10 seconds to ensure that the user has enough time to fully express the command). The collected sound signal is converted into digital voice data and stored in a temporary buffer area of ​​the central control screen, awaiting subsequent processing. At the same time, to improve the accuracy of voice recognition, during the collection process, the system will also utilize the noise reduction microphone array technology in the car to perform signal processing on the sound collected by multiple microphones to remove background noise (such as vehicle driving sound, wind noise, etc.), thereby enhancing the clarity of the user's voice signal.

[0106] Step S42: extract the instruction field in the voice data.

[0107] In this embodiment, the instruction field is a key semantic information segment extracted from the original voice data. This information directly reflects the user's core requirements for the interface background, including specific content such as background theme, style, scene adaptation, and color preference. For example, in the voice message "I want a seaside sunset background, suitable for night driving," "seaside sunset" is the background theme instruction field, and "suitable for night driving" is the scene adaptation instruction field. Together, they will serve as important basis for subsequent background generation.

[0108] The voice recognition and analysis module built into the central control screen is activated to process the voice data in the temporary buffer area. The module first uses advanced voice recognition algorithms, such as a model based on a combination of deep learning convolutional neural networks and long short-term memory networks, to convert the sound waveform in the voice data into a text string. Then, using the semantic parsing algorithm in natural language processing technology, the text string is segmented, POS tagged, and syntactically analyzed to identify words and phrases with key instruction meanings and extract them as instruction fields. For example, for the voice mentioned above, after voice recognition, the text "I want a seaside sunset background, suitable for night driving" is obtained. Then, through semantic parsing, instruction fields such as "seaside sunset" and "night driving" are extracted and organized into structured data form and stored in memory for the next step.

[0109] Step S43: Generate an interface background based on the instruction field and the vehicle driving environment data.

[0110] In this embodiment, vehicle driving environment data, as previously described, encompasses information such as the vehicle's current location, road type, traffic conditions, and weather conditions. This data is acquired through the vehicle's GPS, onboard mapping software, various sensors, and interactions with external networks, comprehensively reflecting the vehicle's external operating environment. For example, a vehicle may be located on a mountain highway in clear weather with smooth traffic. This information is crucial for generating an interface background tailored to the current driving scenario. Interface background refers to the image or pattern ultimately rendered behind the secondary interface on the vehicle's central control screen, serving as a visual backdrop. It must meet the user's personalized needs expressed through voice commands while also adapting to the vehicle's current driving environment, enhancing the interface, improving the visual experience, and aiding driver perception. For example, when driving at night and a user requests a "seaside sunset" background, the generated interface background might be a tonal-adjusted seascape with a dark blue primary hue and a soft orange sunset glow. This not only meets the user's needs but also avoids being too glaring and disrupting the driver's vision during nighttime driving.

[0111] The vehicle's central control screen's intelligent background generation engine activates, taking the extracted command field and the currently acquired vehicle driving environment data as dual inputs. First, the command field determines the general direction of the background theme. Once a "seaside sunset" theme is chosen, for example, the engine selects original images, textures, patterns, and other materials related to seaside sunsets from its extensive built-in resource library. This library can be a collection of image resources pre-stored in the central control screen's local storage system or online resources accessed through a network connection in the cloud. The materials are then optimized and adjusted based on the vehicle's driving environment data. If the vehicle is in a night-time driving environment and the command field does not explicitly oppose night-time adaptation, the engine will perform night scene processing on the selected seaside sunset material, reducing the overall brightness, increasing the color contrast, and making the orange afterglow more prominent to adapt to the nighttime visual experience; if the vehicle is in a congested road condition and the user's command mentions "relaxing atmosphere", the engine may superimpose some dynamic elements such as flying seagulls and lapping waves on the seaside sunset background to create a soothing and relaxing atmosphere and alleviate the user's anxiety in congestion; if the vehicle is driving in a mountainous area and the weather is rainy and foggy, combined with the "suitable for mountain driving" command field, the engine may incorporate some looming mountain road outlines and suggestive lighting elements into the background, which not only echoes the theme but also enhances driving safety prompts. Through these multi-dimensional optimization adjustments, the interface background that meets user needs and driving scenarios is ultimately generated.

[0112] Step S44: rendering the interface background as the background image of the second interface.

[0113] In this embodiment, rendering a background image involves visually presenting the generated interface background to the bottom layer of the second interface of the vehicle's central control screen as a visual backdrop for the entire interface. This involves a series of technical operations, including graphics processing, pixel filling, and color matching. By calling the central control screen's graphics processing unit and related graphics libraries, the interface background is converted into an actual visible image according to the predetermined layout and display requirements. For example, the night-adapted seaside sunset background image generated through the above steps is filled into the background area of ​​the second interface through the graphics processing unit's rendering pipeline, giving the entire interface a visually fresh look while ensuring that other components on the interface (such as navigation, instrument panel, etc.) can be displayed normally on the background without interfering with each other.

[0114] After receiving the generated interface background, the graphics rendering module of the in-vehicle central control screen initiates the rendering process. First, based on the layout architecture of the secondary interface, it determines the background image's coverage area. This typically covers the entire screen area, but reserves space for display of various functional components (such as the aforementioned secondary component) to prevent the background image from obscuring critical information. Next, utilizing the graphics processing unit's 2D graphics rendering capabilities, the pixel data of the interface background image is applied pixel by pixel to the secondary interface's background area, at predetermined coordinates and dimensions. During this filling process, pixel colors are precisely adjusted based on the background image's color mode and display requirements to ensure high color reproduction and visual quality. For example, for backgrounds with dynamic elements, such as the aforementioned seaside sunset background with flying seagulls, the graphics rendering module also leverages the graphics processing unit's animation processing capabilities to update the seagull's position, posture, and other animation frames in real time at a predetermined animation frame rate, such as 30 frames per second, to ensure they appear within the background.

[0115] Through the above detailed implementation methods, after generating the second interface, the vehicle-mounted central control screen can further respond to the user's personalized needs for background images. With the help of voice commands and vehicle driving environment data, it can intelligently generate and render an adaptive interface background, greatly improving the intelligence level and user experience of the central control screen, so that it can better serve the driving scenario.

[0116] The present application provides a vehicle-mounted central control screen, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the vehicle-mounted central control screen control method in the above-mentioned embodiment one.

[0117] Reference below Figure 6 , which shows a schematic diagram of the structure of a vehicle-mounted central control screen suitable for implementing the embodiments of the present application. The vehicle-mounted central control screen in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, tablet computers, vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The in-vehicle central control screen shown is only an example and should not bring any limitations to the functions and scope of use of the embodiments of the present application.

[0118] like Figure 6As shown, the in-vehicle central control screen may include a processing device 1001 (e.g., a central processing unit, graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the in-vehicle central control screen. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007, such as a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008, such as a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003, such as a magnetic tape, hard disk, etc.; and communication devices 1009. Communication devices 1009 can allow the in-vehicle central control screen to communicate with other devices wirelessly or wired to exchange data. Although the figure shows an in-vehicle central control screen with various systems, it should be understood that implementation or presence of all the illustrated systems is not required. More or fewer systems may be implemented or present instead.

[0119] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the vehicle-mounted central control screen control method in the above-mentioned embodiment.

[0120] The computer-readable storage medium provided herein may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory, read-only memory, erasable programmable read-only memory, flash memory, optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including, but not limited to, wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0121] The computer-readable storage medium may be included in the vehicle-mounted central control screen; or it may exist independently without being assembled into the vehicle-mounted central control screen.

[0122] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the vehicle-mounted central control screen, the vehicle-mounted central control screen: responds to the triggering operation of the interface switching control in the first interface, obtains at least one pre-stored layout information; selects target layout information in the layout information based on preset rules; generates a second interface according to the target layout information, and renders and displays the second interface.

[0123] Computer program code for performing the operations of the present application can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0124] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code includes one or more executable instructions for realizing the prescribed logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the prescribed function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0126] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned in-vehicle central control screen control method. This computer-readable storage medium can address the technical issues of displaying limited content and limited functionality, which can hinder user satisfaction. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are similar to those of the in-vehicle central control screen control method provided in the aforementioned embodiments, and are not further elaborated here.

[0127] An embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above-mentioned vehicle-mounted central control screen control method.

[0128] The computer program product provided in this application can solve the technical problem of displaying a single piece of content, having few functions, and being unable to meet user needs. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this application are the same as those of the vehicle-mounted central control screen control method provided in the above embodiments, and will not be elaborated here.

[0129] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. A method for controlling a vehicle-mounted central control screen, characterized in that: The vehicle-mounted central control screen control method includes: In response to a triggering operation of an interface switching control in the first interface, obtaining at least one pre-stored layout information; Acquiring layout reference data, wherein the layout reference data includes vehicle operating state data, vehicle driving environment data, and driver image data; Determine a recommended layout type based on the layout reference data, wherein, if there is no abnormal data in the vehicle operation status data, feed the driver image data into a pre-trained CNN model, the model extracts and classifies features of facial expressions, eye movements, and head postures in the driver image data, outputs a vector data containing the driver's emotional features, parses the vector data, extracts the emotional scores corresponding to the facial expressions, eye movements, and head postures, and multiplies the scores of the facial expressions, eye movements, and head postures by corresponding weights according to a preset weighting algorithm, and then sums them to obtain the driver's mood index; determine the type of environment in which the vehicle is located based on the vehicle driving environment data, the environment types including highways, urban areas, rural areas, competitions, and markets; determine the recommended layout type based on the mood index and the environment type, and different combinations of mood index ranges and environment types correspond to unique recommended layout types; Selecting target layout information corresponding to the recommended layout type from the layout information; Generate a second interface according to the target layout information, and render and display the second interface; The step of generating a second interface according to the target layout information and rendering and displaying the second interface includes: Determining at least one first component in the first interface and at least one second component corresponding to the target layout information; determining identical components in the first component and the second component; Determining the displacement of each identical component from the location of the first interface to the location of the second interface; The same component is rendered based on the displacement amount, and the remaining components of the second component except the same component are rendered to render a second interface.

2. The vehicle-mounted central control screen control method according to claim 1, characterized in that: The step of determining the recommended layout type according to the layout reference data includes: If abnormal data exists in the vehicle operation status data, the recommended layout type is determined to be an abnormality prompt layout.

3. The vehicle-mounted central control screen control method according to claim 1, characterized in that: After the step of determining the recommended layout type according to the layout reference data, the method further includes: determining a layout type of each piece of layout information, and if the layout type identical to the recommended layout type does not exist, determining a component to be displayed according to the layout reference data; Determining a target component based on the components to be displayed, the size of each of the components to be displayed, and the panel size of the vehicle central control screen; The target layout information is determined according to the target component.

4. The vehicle-mounted central control screen control method according to claim 1, characterized in that: The step of rendering the remaining components in the second component except the same component includes: determining component requirement data for each of the remaining components; Obtaining the component demand data from the vehicle controller based on the vehicle central control bus; If empty data returned by the vehicle controller is received, determining replacement data associated with the component requirement data; The component requirement data is calculated based on the replacement data, and the remaining components are rendered based on the component requirement data.

5. The vehicle-mounted central control screen control method according to claim 1, characterized in that: After the step of generating a second interface according to the target layout information and rendering and displaying the second interface, the method includes: Responding to a triggering operation of a background generation control in the second interface, acquiring voice data; Extracting an instruction field from the voice data; Generate an interface background based on the instruction field and the vehicle driving environment data; Render the interface background as the background image of the second interface.

6. The vehicle-mounted central control screen control method according to claim 1, characterized in that: After the step of acquiring at least one pre-stored layout information and before the step of determining at least one first component in the first interface and at least one second component corresponding to the target layout information, the method includes: If there are at least two types of layout information, obtaining the priority of each type of layout information; The target layout information is selected based on the priority.

7. A vehicle-mounted central control screen, characterized in that: The vehicle-mounted central control screen includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the vehicle-mounted central control screen control method as described in any one of claims 1 to 6.

8. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the steps of the vehicle-mounted central control screen control method as described in any one of claims 1 to 6 are implemented.

Images