Vehicle-mounted system process control method, device and equipment based on large model decision

Abstract

The invention relates to the technical field of computers, and discloses a vehicle-mounted system process control method, device and equipment based on large model decision, and the method comprises the steps: obtaining an original data flow of a vehicle multi-mode sensor; analyzing the original data stream to generate a standardized feature vector; outputting a scene label corresponding to the current vehicle by analyzing the feature vector; dividing the to-be-started application process into different grades according to a preset scene grading mapping table; allocating corresponding hardware resources to different levels of application processes, and dynamically adjusting an allocation scheme of the hardware resources of the vehicle-mounted system; according to the adjusted resource allocation scheme, the application processes of the corresponding levels are started in sequence; and when it is detected that the feature vector has a change exceeding a preset threshold, re-outputting the scene label, and synchronously updating the application process grading and resource allocation scheme according to the re-output scene label. Therefore, quick starting of the application process, reasonable distribution of system resources and optimization of user experience are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer technology, and particularly relates to a process control method, device and equipment for a vehicle-mounted system based on a large model decision. BACKGROUND

[0002] With the continuous improvement of the intelligent level of automobiles, the vehicle-mounted central control system has become the core interactive unit of the automobile and bears multiple functions such as navigation, entertainment, vehicle control and safety warning. At present, the mainstream vehicle-mounted central control system mostly adopts an Android customized system, and the process management logic thereof mainly depends on the default mechanism of the operating system, such as the Zygote process hatching mechanism and the ActivityManagerService scheduling mechanism. In actual application, the pre-installed applications in the vehicle-mounted system are mainly started through two ways.

[0003] The first way is a static rule starting way. The technical personnel hard-code the list of application package names that need to be started in the init.rc file or SystemServer, and all application processes in the list are started in the preset order after the system is started. The starting order of the application processes follows the fixed order set by the script or Activity Manager Service, and the scheduling of system resources depends on the default cgroup and cpuset configuration. The advantage of this starting way is that it is simple to implement and does not require complex judgment logic, but it has obvious limitations. All pre-installed applications will be started regardless of whether they are currently needed, resulting in a large amount of system resources being occupied.

[0004] The second way is an event-triggered starting way. Only the core interactive processes such as the desktop, status bar and application list are automatically started when the system is started, and other application processes need to wait for the user to trigger a specific operation, such as clicking the application icon, before they are started. Although this way reduces the resource consumption at the initial stage of system starting to a certain extent, the user needs to wait for the process to start when using non-core applications, which cannot meet the demand for instantaneity in the vehicle-mounted scenario.

[0005] There are many problems to be solved in the existing two process starting modes of vehicle-mounted systems. Firstly, resource waste and performance lagging are prominent. Starting all applications will cause high memory occupation of the system, especially on low-end vehicles. Background processes will fiercely compete for CPU resources, causing system running lag, operation delay and other phenomena. Event-triggered starting cannot meet the immediate use demand of high-frequency applications. Secondly, the scene adaptability is poor. The existing technology does not distinguish the driving scenes of vehicles. The same process starting strategy is used in different states such as cold start, driving and parking, which causes fragmented user experience. High-frequency application starting needs to wait for the preparation of background processes, which cannot match the immediacy requirement of vehicle-mounted scenes. Thirdly, there is no intelligent optimization mechanism. The process starting decision is not made in combination with the user's usage habits, which causes some useless processes to be resident in the system for a long time, occupying valuable hardware resources, while the user's commonly used application processes need to be frequently restarted, forming a contradiction between resource allocation and user demand.

[0006] In the prior art, some patents propose improvement schemes for vehicle-mounted system process management. For example, the patent CN103399785A discloses an improvement method for Android vehicle-mounted system process management. The method identifies during system package scanning through configuration and introduces interface weight to judge process priority. However, this scheme still lacks the ability to perceive dynamic scenes of vehicles and cannot adaptively adjust according to the driving state of vehicles and user behavior. The intelligent degree of process management is low, and it is difficult to solve the core pain points of current vehicle-mounted system process starting. SUMMARY

[0007] To solve the above problems in the prior art, the present application provides a vehicle-mounted system process control method, device and equipment based on large model decision, to realize the hierarchical starting of application processes, accurate allocation of resources and adaptive adaptation of scenes.

[0008] To achieve the above invention purposes, the present application adopts the following technical solutions:

[0009] In a first aspect, the present application provides a vehicle-mounted system process control device based on large model decision, comprising:

[0010] A vehicle-mounted hardware layer is used to continuously collect multi-modal sensor signals and obtain the original data stream of the multi-modal sensors of the vehicle. It is also used to trigger the decision layer to re-output the scene label when the data perception layer detects that the feature vector changes beyond the preset threshold.

[0011] A data perception layer is used to analyze and process the original data stream to generate a standardized feature vector.

[0012] A decision layer is used to output the scene label corresponding to the current vehicle by analyzing the feature vector.

[0013] an execution layer configured to divide the application processes to be started into different levels according to a preset scene grading mapping table;

[0014] a resource scheduler configured to allocate corresponding hardware resources for the application processes of different levels and dynamically adjust an allocation scheme of hardware resources of the vehicle-mounted system;

[0015] when the decision layer re-outputs the scene label, the execution layer and the resource scheduler synchronously update the application process level division and the resource allocation scheme;

[0016] a starting executor configured to start the application processes of corresponding levels in sequence according to the adjusted resource allocation scheme.

[0017] Optionally, the vehicle-mounted hardware layer comprises an information subscription module configured to listen to vehicle operation signals transmitted through a CAN bus and an Ethernet and simultaneously collect real-time data of multi-modal sensors; wherein the multi-modal sensors comprise ultrasonic radars, GPSs, cameras and microphones; and the real-time data of the multi-modal sensors comprise vehicle driving states, environmental information and user interaction information.

[0018] The vehicle driving states, the environmental information and the user interaction information are integrated into raw data streams in a unified format.

[0019] Optionally, the data perception layer comprises a visual recognition module, an ASR voice recognition module and a CarService signal analysis module.

[0020] The visual recognition module is configured to analyze image data collected by the cameras and extract vehicle surrounding environment features.

[0021] The ASR voice recognition module is configured to process audio signals collected by the microphones and recognize user voice instructions.

[0022] The CarService signal analysis module is configured to analyze core state signals of the vehicle-mounted system, fuse processing results and generate a standardized feature vector.

[0023] Optionally, the decision layer comprises a scene decision engine and a dynamic rule constraintor.

[0024] The scene decision engine is configured to perform inference operation on the input feature vector by using a machine learning model.

[0025] The dynamic rule constraintor is configured to check and correct the inference result according to preset vehicle operation rules and finally output a scene label.

[0026] The scene label covers multiple vehicle operation states such as parking, reversing and high-speed driving.

[0027] Optionally, the execution layer comprises a process topology controller and a scene hierarchical mapping table in JSON format.

[0028] The scene hierarchical mapping table comprises a plurality of scene tags and corresponding application process level division rules of each scene tag; wherein the application process level comprises a security level, a comfort level and a background level.

[0029] The process topology controller is configured to query the scene hierarchical mapping table and complete level classification of all to-be-started application processes according to a current scene tag.

[0030] Optionally, the start executor comprises an enhancement module.

[0031] The enhancement module is configured to monitor a process start state in real time during a process start process, trigger process topology reconstruction, readjust a resource allocation scheme and restart an abnormal process if an abnormal process start is detected.

[0032] In a second aspect, the present application provides a process control method for a vehicle-mounted system based on large model decision-making, which comprises:

[0033] Continuously collecting multi-modal sensor signals to obtain original data streams of multi-modal sensors of a vehicle;

[0034] Analyzing and processing the original data streams to generate standardized feature vectors;

[0035] Outputting a scene tag corresponding to the current vehicle by analyzing the feature vectors;

[0036] Dividing to-be-started application processes into different levels according to a preset scene hierarchical mapping table;

[0037] Allocating corresponding hardware resources to the application processes of different levels and dynamically adjusting an allocation scheme of hardware resources of the vehicle-mounted system;

[0038] Starting the application processes of corresponding levels in sequence according to the adjusted resource allocation scheme; when a change of the feature vectors beyond a preset threshold is detected, re-outputting a scene tag and synchronously updating the level division of the application processes and the resource allocation scheme according to the re-output scene tag.

[0039] Optionally, the allocation of corresponding hardware resources to the application processes of different levels comprises setting differentiated resource allocation priorities for the application processes of different levels and allocating CPU computing resources, GPU rendering resources and memory storage resources in the order of the priorities.

[0040] Optionally, the starting the application processes of the corresponding levels in sequence according to the adjusted resource allocation scheme comprises: starting an interface of a reflection calling process and injecting a preset starting identifier, and starting the application processes of the levels in sequence according to a priority order of the security level, the comfort level and the background level; and simultaneously monitoring a process starting state in real time, and if a process starting exception is detected, triggering process topology reconstruction, readjusting the resource allocation scheme and restarting the abnormal process.

[0041] In a third aspect, the present application provides an electronic device, comprising:

[0042] at least one processor; and

[0043] a memory connected to the at least one processor in communication; wherein

[0044] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the method of any one of the second aspect.

[0045] Compared with the closest prior art, the present application has the following beneficial effects:

[0046] The process control method, device and equipment of the vehicle-mounted system based on large model decision provided by the present application avoid the problem of high memory occupation caused by full start by starting the application process on demand, and ensure that the hardware resources are tilted to the core application through the dynamic configuration of the resource scheduler, reduce the resource contention between processes, and significantly improve the system running smoothness. The problems of resource waste and performance lag are solved,

[0047] The method accurately identifies the vehicle running scene through the scene decision engine, formulates differentiated process starting strategies for different scenes, realizes the rapid start of safety applications and the delayed start of non-core applications, solves the problem of fragmented user experience in different driving scenes, and meets the instantaneity demand of the vehicle-mounted scene. Moreover, the user behavior and vehicle state are perceived in combination with multi-modal data, intelligent decision is made through a light machine learning model, high-frequency applications can be pre-started, the problem of frequent restart of useful processes is avoided, and the constant residence of useless processes is reduced, realizing intelligent management of the vehicle-mounted system process.

[0048] The present application scheme is developed based on the Android system, can be adapted to vehicle-mounted devices with different configurations, and the scene grading mapping table is stored in the JSON format, which is convenient for technicians to flexibly modify according to the vehicle model demand and user feedback, reduces the system maintenance cost, and has a wide application prospect. BRIEF DESCRIPTION OF DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings required to be used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn according to the actual proportions.

[0050] Figure 1 is a schematic structural diagram of a vehicle-mounted system process control device based on large model decision provided by the present application;

[0051] Figure 2 is a flow chart of a vehicle-mounted system process control method based on large model decision provided by the present application;

[0052] Figure 3 is an internal structure diagram of an electronic device provided by the present application. DETAILED DESCRIPTION

[0053] The embodiments of the technical solutions of the present application will be described in detail below with reference to the drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present application, and therefore only serve as examples, and cannot limit the protection scope of the present application.

[0054] It should be noted that, unless otherwise specified, the technical terms or scientific terms used in the present application should be understood as the usual meanings understood by the skilled person in the field to which the present application belongs.

[0055] The present application provides a vehicle-mounted system process control method, device and equipment based on large model decision. Specifically, it is a process start control scheme that can be widely applied to various vehicle-mounted devices carrying Android system, which solves the problems of resource waste, poor scene adaptability and lack of intelligent optimization existing in the process start of the existing vehicle-mounted system, and realizes the effects of application fast start, system resource reasonable allocation and user experience optimization. The embodiments of the present application will be described below with reference to the drawings.

[0056] Embodiment 1: Please refer to Figure 1 , Figure 1 A system architecture of a vehicle-mounted system process control device based on large model decision is provided for embodiment 1 of the present application. It includes a vehicle-mounted hardware layer, a data perception layer, a decision layer, an execution layer, a resource scheduler and a start executor, each layer and each device cooperates to form a complete process control closed loop. The vehicle-mounted hardware layer serves as a data acquisition terminal and provides raw data for the entire device; the data perception layer is responsible for data analysis and standardization processing; the decision layer undertakes scene judgment and decision function; the execution layer is responsible for application classification and process start control; the resource scheduler realizes dynamic configuration of hardware resources, and each module has clear division of labor, ensuring efficient execution of the method.

[0057] Specifically, the vehicle-mounted hardware layer is configured to continuously collect multi-modal sensor signals and obtain a raw data stream of the multi-modal sensors of the vehicle; and trigger the decision layer to re-output a scene label when the data perception layer detects that a feature vector has changed beyond a preset threshold.

[0058] The data perception layer is configured to analyze and process the raw data stream to generate a standardized feature vector.

[0059] The decision layer is configured to output a scene label corresponding to the current vehicle by analyzing the feature vector.

[0060] The execution layer is configured to divide the application processes to be started into different levels according to a preset scene classification mapping table.

[0061] The resource scheduler is configured to allocate corresponding hardware resources to the application processes of different levels and dynamically adjust the allocation scheme of the hardware resources of the vehicle-mounted system.

[0062] When the decision layer re-outputs a scene label, the execution layer and the resource scheduler synchronously update the application process level division and the resource allocation scheme.

[0063] The start executor is configured to start the application processes of the corresponding levels in sequence according to the adjusted resource allocation scheme.

[0064] In the above embodiment, the vehicle-mounted hardware layer includes an information subscription module configured to listen to vehicle operation signals transmitted through CAN bus and Ethernet and simultaneously collect real-time data of multi-modal sensors; wherein the multi-modal sensors include ultrasonic radar, GPS, camera, and microphone; and the real-time data of the multi-modal sensors include vehicle driving state, environmental information, and user interaction information.

[0065] The vehicle driving state, environmental information, and user interaction information are integrated into a raw data stream in a unified format.

[0066] Optionally, the data perception layer includes a visual recognition module, an ASR voice recognition module, and a CarService signal analysis module.

[0067] The visual recognition module is configured to analyze image data collected by the camera and extract vehicle surrounding environment features.

[0068] The ASR voice recognition module is configured to process audio signals collected by the microphone and recognize user voice instructions.

[0069] The CarService signal analysis module is configured to analyze core state signals of the vehicle-mounted system, fuse the processing results, and generate a standardized feature vector.

[0070] Optionally, the decision layer comprises: a scene decision engine and a dynamic rule constrainter.

[0071] The scene decision engine is configured to perform inference operation on the input feature vector by using a machine learning model.

[0072] The dynamic rule constrainter is configured to check and correct the inference result according to preset vehicle operation rules, and finally output a scene label, wherein the vehicle operation rules comprise gear-scene mapping rules, environment and device interaction rules, safety priority constraint rules, user behavior adaptation rules, and the like.

[0073] The scene label covers various vehicle operation states such as parking, reversing, and high-speed driving.

[0074] In the above embodiment, the execution layer comprises: a process topology controller and a scene hierarchical mapping table in JSON format.

[0075] The scene hierarchical mapping table comprises a plurality of scene labels and corresponding application process level division rules of each scene label, wherein the application process level comprises a safety level, a comfort level, and a background level, and the process levels are sequentially arranged from high to low in priority as the safety level, the comfort level, and the background level.

[0076] The process topology controller is configured to query the scene hierarchical mapping table and complete the level classification of all to-be-started application processes according to the current scene label.

[0077] In the above embodiment, the start executor comprises: an enhancement module.

[0078] The enhancement module is configured to monitor the process start state in real time during the process start, and if an abnormal process start is detected, trigger process topology reconstruction, re-adjust the resource allocation scheme, and restart the abnormal process.

[0079] Embodiment 2: Please refer to Figure 2 , Figure 2 A process control method for a vehicle-mounted system based on large model decision is provided for the embodiment 1 of the present application, and the method specifically comprises the following steps:

[0080] S101 continuously acquires multi-modal sensor signals to obtain original data streams of vehicle multi-modal sensors.

[0081] S102 analyzes and processes the original data streams to generate standardized feature vectors.

[0082] S103 outputs a scene label corresponding to the current vehicle by analyzing the feature vector.

[0083] S104 divides the to-be-started application processes into different levels according to a preset scene hierarchical mapping table.

[0084] S105 allocates corresponding hardware resources to application processes of different levels and dynamically adjusts the allocation scheme of vehicle system hardware resources.

[0085] S106 starts the application processes of the corresponding levels in sequence according to the adjusted resource allocation scheme; when a change in the feature vector exceeding the preset threshold is detected, the scene label is re-output, and the application process level classification and resource allocation scheme are updated synchronously according to the re-output scene label.

[0086] In step S106 above, allocating corresponding hardware resources to application processes of different levels includes: setting differentiated resource allocation priorities for application processes of different levels, and allocating CPU computing resources, GPU rendering resources and memory storage resources in order of priority.

[0087] In step S106 above, starting application processes of corresponding levels in sequence according to the adjusted resource allocation scheme includes: calling the process startup interface through reflection and injecting a preset startup identifier, starting application processes of each level in sequence according to the priority order of security level, comfort level, and background level; at the same time, monitoring the process startup status in real time, and if an abnormal process startup is detected, triggering process topology reconstruction, readjusting the resource allocation scheme and restarting the abnormal process.

[0088] To make the technical solution of the present invention clearer and more explicit, the following describes in detail the method for dynamic start-up control of vehicle system processes based on large model decision-making.

[0089] Example 3: Dynamic start control of the process in a reversing scenario;

[0090] This embodiment applies to a vehicle reversing scenario. In this scenario, safety-related applications need to be launched first to ensure that users can obtain reversing image and radar warning information in a timely manner. Comfort-related applications and background applications are launched in turn with delayed startup. The specific implementation steps are as follows:

[0091] After the vehicle starts, the Android vehicle system completes the SystemServer startup process. The init process automatically starts the preset process dynamic control program, which enters the running state, resides in the system process space, and waits to receive sensor data.

[0092] The information subscription module of the vehicle hardware layer starts working, listening to the vehicle gear position signal transmitted by the CAN bus. When it detects that the gear has been switched to reverse, it simultaneously collects the distance detection signal of the ultrasonic radar, the reversing image signal of the camera, and the position signal of the GPS, integrates these signals into a raw data stream, and transmits it to the data perception layer in real time.

[0093] The data perception layer parses and processes the raw data stream: the visual recognition module analyzes the reversing image captured by the camera in real time and extracts obstacle features in the image; the ASR voice recognition module is in standby mode and continuously listens for voice commands that the user may issue; the CarService module analyzes the vehicle gear signal and speed signal to confirm that the vehicle is in reversing mode, and the processing results of each module are fused to generate the feature vector corresponding to the reversing scene.

[0094] After receiving the feature vector, the scene decision engine of the decision layer uses a machine learning model to perform inference operations on the feature vector. Combined with features such as the vehicle gear being reverse and the vehicle speed being low, it initially determines that the current scene is a reversing scene. The dynamic rule constraint device verifies the result according to preset rules, confirms that it meets the judgment conditions of a reversing scene, and finally outputs the scene label REVERSE.

[0095] In the above embodiments, the machine learning model selected is a local lightweight LLM model. This LLM model is a pre-built visual recognition model for high-frequency use in vehicle scenarios (such as reversing image detection and ADAS environmental perception) based on the technical principles of machine learning. By optimizing the convolution calculation logic, it can realize inference operations on the scene.

[0096] The process topology controller of the execution layer queries a preset scene hierarchy mapping table, which contains a JSON-formatted policy sub-table corresponding to the reversing scene. Based on this policy table, the process topology controller classifies the reversing camera application (ltd.qisi.avm) and radar warning application (ltd.qisi.radar) into the safety level, the music application (ltd.qisi.qqmusic) into the comfort level, and the weather application (ltd.qisi.weather) into the background level.

[0097] After receiving the application process classification results, the resource scheduler immediately adjusts the hardware resource allocation scheme: it binds high-performance CPU cores to security-level application processes, allocates sufficient memory space for storing reversing image data, and increases I / O bandwidth to ensure real-time transmission of image data; it reserves basic CPU and memory resources for comfort-level application processes; and it temporarily allocates the minimum resources to background-level application processes, with resource adjustments made after the security-level applications are running stably.

[0098] The executor starts the application process according to the resource allocation scheme: by calling the startProcessLocked() interface of ActivityManagerService through reflection, a security-level application startup identifier is injected, and the reversing camera application and radar warning application are started first; after the above two applications have started and are running stably, the music application is started; the background weather application is started gradually when system resources are idle, thus completing the process startup process in the reversing scenario.

[0099] During the reversing process, the vehicle hardware layer continuously collects sensor signals. When the data perception layer detects that the gear has been switched to forward or parking, the feature vector changes significantly, triggering the decision layer to re-output the scene label. The execution layer and resource scheduler then synchronously update the application process level and resource allocation scheme, switching to the process control strategy corresponding to the scene.

[0100] Example 4: Dynamic process startup control in high-speed driving scenarios:

[0101] This embodiment applies to a high-speed driving scenario, where intelligent driving applications such as navigation and voice interaction need to operate efficiently, entertainment applications run on demand, and background applications reduce resource consumption. The specific implementation steps are as follows:

[0102] After the vehicle system starts up, the process dynamic control program starts up normally and runs in the system process space, entering the data listening state.

[0103] The information subscription module of the vehicle hardware layer collects real-time vehicle speed signals through GPS. When the vehicle speed is detected to continuously exceed the preset high speed threshold, it obtains signals such as engine speed and gear through the CAN bus. At the same time, it collects images of the road ahead through the camera and collects voice signals in the vehicle through the microphone. The data is integrated to form a raw data stream and transmitted to the data perception layer.

[0104] The data perception layer parses the raw data stream: the visual recognition module analyzes road images and extracts features such as lane lines and traffic signs; the ASR voice recognition module is in a high-sensitivity state and accurately recognizes user voice commands; the CarService module parses vehicle speed signals and driving status signals to confirm that the vehicle is in a high-speed driving state, and integrates the results of each module to generate a feature vector of the high-speed driving scenario.

[0105] The decision-making engine in the decision-making layer analyzes the feature vectors and, based on machine learning models and features such as vehicle speed and road images, infers that the current scenario is a high-speed driving scenario. After the dynamic rule constraint verifies that there are no errors, it outputs the scenario label DRIVE_HIGH_SPEED. For example, emergency scenario label, comfort scenario label, etc.

[0106] The execution layer queries the scenario hierarchy mapping table, classifying navigation applications and voice interaction applications into the security level, music applications and radio applications into the comfort level, and shopping applications and news applications into the background level.

[0107] The resource scheduler optimizes the resource allocation scheme, prioritizing CPU computing resources for the positioning calculation and path planning modules of navigation applications, focusing GPU resources on supporting the rendering and display of navigation maps, allocating dedicated memory space for voice interaction applications to ensure fast response to voice commands, allocating medium resources to entertainment applications, and limiting CPU utilization and memory usage for background applications.

[0108] The executor sequentially launches security-level, comfort-level, and background-level applications. At the same time, it monitors the running status of navigation and voice interaction applications through the enhancement module. If any abnormalities such as lag occur, it immediately triggers process topology reconstruction and reallocates resources to ensure the stable operation of core applications.

[0109] When the vehicle speed drops below the highway threshold, or when GPS detects that the vehicle has left the highway section, the data perception layer triggers a scene update, the decision layer outputs a new scene label, and the process startup strategy is switched synchronously to adapt to the new driving state of the vehicle.

[0110] Example 5: Dynamic process startup control in parking scenarios;

[0111] This embodiment applies to a vehicle parking scenario, where users have lower requirements for application launch speed. The system can launch more entertainment and lifestyle applications, improving the user experience after parking. The specific implementation steps are as follows:

[0112] After the vehicle is parked and the engine is turned off, the on-board system is not completely shut down. The process dynamic control program continues to run, maintaining the operation of the basic functional modules.

[0113] The vehicle hardware layer detects the fixed vehicle location via GPS, the CAN bus detects that the gear is parked, the engine speed is zero, and the ultrasonic radar and camera are in a low-power monitoring state. These status signals are integrated into a raw data stream and transmitted to the data perception layer.

[0114] After the data perception layer parses the data, it confirms that the vehicle is in a parked state, generates a feature vector of the parking scene, and transmits it to the decision layer.

[0115] The decision-making layer outputs the scene label PARK, and the execution layer queries the mapping table to classify basic applications related to vehicle control into the safety level, video applications, shopping applications, music applications, etc. into the comfort level, and system update applications, backup applications, etc. into the background level.

[0116] The resource scheduler evenly allocates hardware resources, ensuring that security-level applications maintain basic resource usage, while comfort-level applications receive sufficient CPU and memory resources to guarantee the smooth operation of entertainment applications. Background applications utilize parking downtime to gradually complete system updates and data backups without affecting user experience.

[0117] The starter activates applications in a hierarchical order to meet users' entertainment and lifestyle service needs after parking, thereby enhancing the user experience.

[0118] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the present invention. In practical applications, technicians can adjust the scene tag type, application classification rules, and resource allocation strategies according to factors such as the configuration of different vehicle models and the usage habits of user groups to adapt to diverse in-vehicle needs.

[0119] In one embodiment, the present invention also provides an electronic device, which may be a terminal, and its internal structure diagram may be as follows. Figure 3 As shown. The electronic device includes a processor, memory, communication interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements the vehicle system process control method for large model decision-making as described in any of steps S101 to S106. The display screen can be a liquid crystal display (LCD) or an e-ink display. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse.

[0120] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0121] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0122] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0123] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0124] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0125] The above are merely embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of the claims of the present invention pending approval.

Claims

1. A large model decision-based in-vehicle system process control device, characterized by, The system comprises: a vehicle hardware layer, configured to continuously collect multi-modal sensor signals and obtain a raw data stream of multi-modal sensors of a vehicle; and configured to trigger a decision layer to re-output a scene label when the data perception layer detects that a feature vector changes beyond a preset threshold; a data perception layer, configured to analyze and process the raw data stream to generate a standardized feature vector; a decision layer, configured to output a scene label corresponding to the current vehicle by analyzing the feature vector; an execution layer, configured to divide to-be-started application processes into different levels according to a preset scene grading mapping table; a resource scheduler, configured to allocate corresponding hardware resources to the application processes of different levels and dynamically adjust an allocation scheme of hardware resources of the vehicle system; when the decision layer re-outputs the scene label, the execution layer and the resource scheduler synchronously update the application process level division and the resource allocation scheme; and a starting executor, configured to start the application processes of the corresponding levels in sequence according to the adjusted resource allocation scheme.

2. The system of claim 1, wherein, The vehicle hardware layer comprises an information subscription module, configured to listen to vehicle operation signals transmitted through a CAN bus and an Ethernet and simultaneously collect real-time data of multi-modal sensors; wherein the multi-modal sensors comprise ultrasonic radars, GPSs, cameras and microphones; and the real-time data of the multi-modal sensors comprise vehicle driving states, environmental information and user interaction information. The vehicle driving states, the environmental information and the user interaction information are integrated into a raw data stream in a unified format.

3. The system of claim 2, wherein, The data perception layer comprises a visual recognition module, an ASR voice recognition module and a CarService signal analysis module; the visual recognition module is configured to analyze image data collected by the camera and extract environmental features around the vehicle; the ASR voice recognition module is configured to process audio signals collected by the microphone and recognize user voice instructions; and the CarService signal analysis module is configured to analyze core state signals of the vehicle system, fuse processing results and generate a standardized feature vector.

4. The system of claim 3, wherein, The decision layer comprises a scene decision engine and a dynamic rule constrainter; the scene decision engine is configured to use a machine learning model to perform inference operation on the input feature vector; the dynamic rule constrainter is configured to check and correct the inference result according to preset vehicle operation rules and finally output a scene label; the scene label covers multiple vehicle operation states such as parking, reversing and high-speed driving.

5. The system of claim 4, wherein, The execution layer comprises a process topology controller and a scene grading mapping table in JSON format; the scene grading mapping table comprises multiple scene labels and application process level division rules corresponding to each scene label; wherein the application process levels comprise a safety level, a comfort level and a background level; the process topology controller is configured to query the scene grading mapping table and complete level classification of all to-be-started application processes according to the current scene label.

6. The system of claim 1, wherein, The starting executor comprises an enhancement module; the enhancement module is configured to monitor a process starting state in real time during the process starting, trigger process topology reconstruction if a process starting abnormality is detected, and re-adjust a resource allocation scheme and restart an abnormal process.

7. A large model decision-based vehicle-mounted system process control method, characterized in that, The method comprises: continuously collecting multi-modal sensor signals to obtain an original data stream of a vehicle multi-modal sensor; parsing the original data stream to generate a standardized feature vector; outputting a scene label corresponding to the current vehicle by analyzing the feature vector; dividing the application process to be started into different levels according to a preset scene classification mapping table; allocating corresponding hardware resources to the application processes of different levels, and dynamically adjusting the allocation scheme of the hardware resources of the vehicle-mounted system; starting the application processes of the corresponding levels in turn according to the adjusted resource allocation scheme; when it is detected that the feature vector changes beyond a preset threshold, re-outputting a scene label, and synchronously updating the application process level division and the resource allocation scheme according to the re-output scene label.

8. The method of claim 7, wherein, The method comprises:

9. The method of claim 7, wherein, allocating corresponding hardware resources to the application processes of different levels, and dynamically adjusting the allocation scheme of the hardware resources of the vehicle-mounted system; 10. An electronic device, comprising: allocating corresponding hardware resources to the application processes of different levels, and dynamically adjusting the allocation scheme of the hardware resources of the vehicle-mounted system; allocating corresponding hardware resources to the application processes of different levels, and dynamically adjusting the allocation scheme of the hardware resources of the vehicle-mounted system. The method comprises: allocating corresponding hardware resources to the application processes of different levels, and dynamically adjusting the allocation scheme of the hardware resources of the vehicle-mounted system; allocating corresponding hardware resources to the application processes of different levels, and dynamically adjusting the allocation scheme of the hardware resources of the vehicle-mounted system; allocating corresponding hardware resources to the application processes of different levels, and dynamically adjusting the allocation scheme of the hardware resources of the vehicle-mounted system. The electronic device comprises: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the method of any one of claims 7-9.

Images