Process management method and vehicle

Abstract

The application provides a process control method and a vehicle, and relates to the technical field of intelligent networking. In the method, a plurality of first configuration information of the vehicle is acquired, and running control parameters common to each vehicle type can be constructed. Target configuration information is acquired through a vehicle type configuration word written in the vehicle, and the target running control parameters of the target outsourcing process corresponding to the current vehicle can be locked. Then, after the target outsourcing process is started, the target outsourcing process is controlled based on the target running control parameters. This can break the limitation of global solidification of the running control strategy, flexibly configure whether to start the running state monitoring and the abnormal fault recovery process, and does not need to change the running logic of the outsourcing process, but only needs to configure the running control parameters to realize the differentiated control of the outsourcing process. Therefore, the above scheme can adapt to diversified control requirements and effectively improve the adaptability of the outsourcing process to different vehicle types.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, and more specifically, to a process control method and vehicle in the field of intelligent connected vehicle technology. Background Technology

[0002] The Electronic Control Unit (ECU) is an embedded hardware controller in a vehicle. Its embedded software typically employs a multi-process architecture. This means the entire software is broken down into multiple processes (executable files or program units) that can be independently scheduled and run by the operating system. Each process has a specific function and communicates with others. Program units developed and maintained entirely by the vehicle ECU R&D team are called native built-in processes; third-party functional program units packaged and delivered by external suppliers for specific business applications and direct integration are defined as purchased processes.

[0003] Currently, in the aforementioned multi-process architecture, the operation and management strategy of the external procurement process is a globally fixed configuration, which cannot be flexibly configured as needed and is difficult to adapt to diverse management and management requirements.

[0004] Therefore, there is an urgent need for a process control method to improve the adaptability and flexibility of the procurement process. Summary of the Invention

[0005] This application provides a process management method and a vehicle, which can improve the adaptability and flexibility of the procurement process.

[0006] Firstly, a process management method is provided. This method includes: acquiring multiple first configuration information of a vehicle, each first configuration information including a configuration word for a vehicle model and operation management parameters for a target external purchase process under that model. The target external purchase process is an externally integrated process scheduled by the main process of the vehicle's electronic control unit. The operation management parameters are used to indicate whether to enable a monitoring process for the target operating status of the target external purchase process and whether to enable a fault recovery process corresponding to the target external purchase process under abnormal conditions; acquiring the vehicle model configuration word flashed in the vehicle; determining target configuration information matching the vehicle model configuration word from the multiple first configuration information; and extracting the target operation management parameters corresponding to the target external purchase process from the target configuration information; and after the target external purchase process starts, managing the target external purchase process based on the target operation management parameters.

[0007] In the above technical solution, multiple primary configuration information of the vehicle can be obtained to construct universal operation and control parameters for various vehicle models. By acquiring the target configuration information through the vehicle model configuration characters flashed in the vehicle, the target operation and control parameters for the target external purchase process corresponding to the current vehicle can be locked. Subsequently, after the target external purchase process starts, the process is controlled based on the target operation and control parameters. This breaks the limitation of globally fixed operation and control strategies, flexibly configuring whether to enable operation status monitoring and abnormal fault recovery procedures, without changing the operation logic of the external purchase process; differentiated control of the external purchase process can be achieved simply by configuring the operation and control parameters. Therefore, the above solution can adapt to diverse control needs and effectively improve the flexibility of the external purchase process for different vehicle models.

[0008] In conjunction with the first aspect, in some possible implementations, the procurement process of the target is controlled based on the target operation control parameters, including: monitoring the target operation status when the target operation control parameters indicate that the monitoring process for the target operation status of the procurement process is enabled; prohibiting the monitoring of the target operation status when the target operation control parameters indicate that the monitoring process is not enabled; and executing the corresponding fault recovery process when the procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process for the procurement process under abnormal conditions is enabled; and prohibiting the execution of the corresponding fault recovery process when the procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process is not enabled.

[0009] In the above technical solution, the indication to prohibit or execute target operation status monitoring based on target operation control parameters can flexibly control the monitoring behavior of process health status. The indication to prohibit or execute fault recovery procedures based on target operation control parameters can configure fault tolerance and self-healing mechanisms as needed when processes are abnormal. In other words, the above solution can enable or disable status monitoring and fault recovery strategies during process operation through configuration, achieving dynamic configuration of operation rules and improving the adaptability and maintainability of purchased processes during operation.

[0010] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target operating state includes a ready state and a live state, and the fault recovery process includes the whole machine restart process of the vehicle electronic control unit and the process restart process of the target outsourced process.

[0011] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: if the survival state or ready state of the target procurement process is abnormal, or if the process itself is abnormal, determining whether the corresponding process restart process is enabled, and obtaining the current first startup count of the target procurement process; if the corresponding process restart process is enabled and the first startup count is less than or equal to a first preset count, restarting the target procurement process and increasing the first startup count by a second preset count, the second preset count being less than the first preset count; if the corresponding process restart process is not enabled and / or the first startup count is greater than the first preset count, determining whether the corresponding whole machine restart process is enabled, and obtaining the current second startup count of the vehicle electronic control unit; if the corresponding whole machine restart process is enabled and the second startup count is less than or equal to a third preset count, restarting the vehicle electronic control unit and increasing the second startup count by the second preset count, the second preset count being less than the third preset count.

[0012] In the above technical solution, determining whether the process restart procedure is enabled and obtaining the first startup count establishes a preliminary self-healing defense against process-level faults. When the process restart procedure is enabled and the first startup count is within the limit, the purchased process is restarted and a second preset count is incremented, allowing the process to perform multiple lightweight self-recovery processes. When the process restart procedure is not enabled and / or the first startup count is exceeded, determining whether the entire system restart procedure is enabled and obtaining the current second startup count of the on-board electronic control unit (ECU) escalates fault handling to the system level. When the entire system restart procedure is enabled and the second startup count is within the limit, the ECU is restarted and a second preset count is incremented, providing the ECU with multiple fault tolerance opportunities and preventing it from falling into an infinite restart loop. In other words, the above solution introduces a tiered recovery mechanism and a dynamic counter, enabling the matching of corresponding levels of handling methods to different fault types in the purchased process, distinguishing between minor anomalies and severe faults. This avoids the situation of indiscriminately restarting the purchased process, resulting in ineffective resource occupation. By using a counter to quantitatively control the number of fault retries, the restart frequency of purchased processes can be precisely constrained, preventing processes from falling into a vicious cycle of repeated crashes and infinite restarts. In other words, it ensures that faults have the fallback capability of being repaired by retry, and can terminate scheduling in a timely manner after the retry threshold is reached, thus ensuring the stable operation of the vehicle electronic control unit.

[0013] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: prohibiting the starting of the vehicle electronic control unit when the corresponding whole machine restart process is not enabled and / or the second startup count is greater than the third preset count, storing the first abnormal information in the log, and controlling the vehicle electronic control unit to enter a degraded operation mode. The first abnormal information is used to indicate that the survival status of the target outsourced process is abnormal, the ready status is abnormal, or the process itself is abnormal, and the corresponding whole machine restart process is not enabled and / or the current second startup count is greater than the third preset count. The degraded operation mode is a restricted working mode that only retains the operation of basic functions.

[0014] In the aforementioned technical solution, the on-board electronic control unit (ECU) is prohibited from starting when the overall system restart process is not initiated and / or the second startup attempt exceeds the limit. This promptly terminates invalid startup attempts, preventing the system from entering an infinite restart loop and ensuring the vehicle's underlying security. Simultaneously, the first anomaly information, including the anomaly type and the reason for recovery failure, is stored in the log. This comprehensively records the fault scene and the failure state of the recovery mechanism, providing accurate data support for subsequent fault diagnosis and problem localization, thereby improving the operational safety and fault diagnosis efficiency of the ECU.

[0015] In combination with the first aspect and the above implementation methods, in some possible implementation methods, before obtaining the vehicle model configuration word flashed in the vehicle, the method further includes: determining whether a first target process is in a ready state, wherein the first target process is a native built-in process that can be directly started and used to load the vehicle model configuration word; and obtaining the vehicle model configuration word flashed in the vehicle includes: if the first target process is in a ready state, obtaining the vehicle model configuration word flashed in the vehicle from the storage file associated with the first target process.

[0016] In the above technical solution, determining whether the first target process (the native built-in process used to load the vehicle configuration word) is in a ready state establishes a reliable process loading environment, ensuring the vehicle has the basic capability to perform subsequent configuration reading. Once the first target process is in a ready state, the vehicle configuration word is retrieved from its associated storage file. This can be achieved by using the native built-in process as a proxy, ensuring the safe and accurate reading of the vehicle configuration word. In other words, by introducing the native built-in process as an intermediate layer, the above solution encapsulates the vehicle configuration word reading logic within a stable native built-in process, decoupling configuration information acquisition from the main process and avoiding risks or dependencies arising from direct operation by the main process.

[0017] In combination with the first aspect and the above implementation methods, in some possible implementation methods, before obtaining multiple first configuration information of the vehicle, the method further includes: obtaining multiple third information bound to the vehicle electronic control unit, wherein each third information corresponds to a native built-in process and the native program code corresponding to the native built-in process, and the native program code is the inherent execution code of the native built-in process; and starting the multiple native built-in processes based on the native program code corresponding to each of the multiple native built-in processes.

[0018] In the above technical solution, multiple third pieces of information are acquired before acquiring multiple first configuration information. This allows for the dynamic definition of the native built-in processes actually installed in the vehicle, establishing the configuration basis for the basic operating environment. Based on the native program code corresponding to each native built-in process, multiple native built-in processes are launched, ensuring that each process is correctly loaded according to its corresponding startup parameters. Furthermore, the native built-in processes do not rely on complex external configuration matching processes. After the vehicle's electronic control unit is powered on, the native built-in processes can be directly launched based on the native program code. This provides a stable and reliable basic operating environment for the scheduling of subsequent externally purchased processes, effectively improving the overall response speed and operational reliability of the vehicle's electronic system.

[0019] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the single first configuration information also includes the start parameters of the target purchase process under the vehicle model. The method further includes: after the on-board electronic control unit is powered on, in response to the start operation of the target purchase process, extracting the target start parameters corresponding to the target purchase process from the target configuration information; using the target start parameters as input parameters, passing them into the general program code corresponding to the target purchase process, generating execution program code to start the target purchase process; wherein, the general program code is the program code common to the target purchase process that does not change with the vehicle model, and the target start parameters are parameters that control the differentiated start of the general program code.

[0020] In the above technical solution, after the on-board electronic control unit is powered on, in response to the startup operation of the target purchase process, the target startup parameters corresponding to the target purchase process are extracted from the target configuration information. This locks the startup parameters of the target purchase process corresponding to the current vehicle. Subsequently, the target startup parameters are used as input parameters and passed to the general program code corresponding to the target purchase process to generate the execution program code. This allows the use of the same set of general program code applicable to all vehicle models, and the actual startup status of the target purchase process can be changed simply by using the target startup parameters corresponding to the current vehicle model. That is, the differentiated startup requirements of different vehicle models for the purchase process are implemented in a configuration form with a one-to-one correspondence between vehicle model and startup parameters, directly decoupling the vehicle model differentiation logic from the code layer to the configuration layer. This eliminates the need to release multiple versions of program code for the target purchase processes of multiple vehicle models, significantly reducing the maintenance workload caused by multiple versions of program code, and at the same time, it does not require modification of the general program code, effectively improving the flexibility of the purchase process to adapt to different vehicle models.

[0021] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the method further includes: obtaining the current operating condition parameters of the vehicle, and adjusting the target start-up parameters based on the current operating condition parameters to obtain the adjusted start-up parameters; and passing the target start-up parameters as input parameters into the general program code corresponding to the target outsourcing process to generate the execution program code, including: passing the adjusted start-up parameters as input parameters into the general program code corresponding to the target outsourcing process to generate the execution program code.

[0022] In the above technical solution, only one set of universal program code that does not change with vehicle model needs to be developed. By matching the corresponding startup parameters with the vehicle model configuration words pre-flashed in the vehicle, multi-vehicle compatibility can be achieved without developing separate program code for each vehicle model. This can significantly save storage resources, simplify development, flashing, and version management, and reduce maintenance costs. On this basis, the target startup parameters corresponding to the vehicle model are adjusted based on the vehicle's current operating parameters. This allows the operation of the target outsourced process to match the actual usage scenario of the vehicle, that is, to meet the differentiated startup control requirements of the vehicle under different usage scenarios. In addition, the entire differentiated adaptation process only requires the adjusted startup parameters to be used as input parameters after power-on startup, which are passed to the universal program code (which is pre-fused in the vehicle electronic control unit). There is no need to re-flash new program code, that is, the universal program code and the startup parameters are decoupled, and the universal program code can be reused. Therefore, this solution can further improve the adaptation flexibility of the outsourced process.

[0023] Secondly, a process management device is provided, comprising: an acquisition module, configured to: acquire multiple first configuration information of a vehicle, each first configuration information including a configuration word of a vehicle model and operation management parameters of a target external purchase process under that vehicle model, the target external purchase process being an externally integrated process scheduled by the main process of the vehicle electronic control unit, the operation management parameters being used to indicate whether to enable the monitoring process of the target operating status of the target external purchase process and whether to enable the fault recovery processing process corresponding to the target external purchase process in abnormal situations; acquire the vehicle model configuration word flashed in the vehicle, determine the target configuration information matching the vehicle model configuration word from the multiple first configuration information, and extract the target operation management parameters corresponding to the target external purchase process from the target configuration information; and a management module, configured to manage the target external purchase process based on the target operation management parameters after the target external purchase process is started.

[0024] In conjunction with the second aspect, in some possible implementations, the control module is specifically used to: monitor the target's operational status when the target operation control parameters indicate that the monitoring process for the target procurement process is enabled; prohibit monitoring the target's operational status when the target operation control parameters indicate that the monitoring process is not enabled; and execute the corresponding fault recovery process when the target procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process for the target procurement process under abnormal conditions is enabled; and prohibit the execution of the corresponding fault recovery process when the target procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process is not enabled.

[0025] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the target operating state includes a ready state and a live state, and the fault recovery process includes the whole machine restart process of the on-board electronic control unit and the process restart process of the target outsourced process.

[0026] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the acquisition module is further configured to determine whether the corresponding process restart process is enabled and acquire the current first startup count of the target purchased process when the survival state, ready state, or process itself of the target purchased process is abnormal; the device further includes: a processing module, configured to restart the target purchased process and increase the first startup count by a second preset count when the corresponding process restart process is enabled and the first startup count is less than or equal to a first preset count; the acquisition module is further configured to determine whether the corresponding whole machine restart process is enabled and acquire the current second startup count of the vehicle electronic control unit when the corresponding process restart process is not enabled and / or the first startup count is greater than the first preset count; the processing module is further configured to restart the vehicle electronic control unit and increase the second startup count by the second preset count when the corresponding whole machine restart process is enabled and the second startup count is less than or equal to a third preset count.

[0027] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the processing module is further configured to prohibit the starting of the vehicle electronic control unit when the corresponding whole machine restart process is not enabled and / or the second startup count is greater than the third preset count, store the first abnormal information in the log, and control the vehicle electronic control unit to enter a degraded operation mode. The first abnormal information is used to indicate that the survival status of the target outsourced process is abnormal, the ready status is abnormal, or the process itself is abnormal, and the corresponding whole machine restart process is not enabled and / or the current second startup count is greater than the third preset count. The degraded operation mode is a restricted working mode that only retains the operation of basic functions.

[0028] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, before obtaining the vehicle model configuration character flashed in the vehicle, the device further includes: a determining module, used to determine whether the first target process is in a ready state, the first target process being a native built-in process that can be directly started and used to load the vehicle model configuration character; and the obtaining module, specifically used to obtain the vehicle model configuration character flashed in the vehicle from the storage file associated with the first target process when the first target process is in a ready state.

[0029] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, before acquiring multiple first configuration information of the vehicle, the acquisition module is further configured to acquire multiple third information bound to the vehicle electronic control unit, wherein each third information corresponds to a native built-in process and the native program code corresponding to the native built-in process, and the native program code is the inherent execution code of the native built-in process; the device further includes: a startup module, configured to start the multiple native built-in processes based on the native program code corresponding to each of the multiple native built-in processes.

[0030] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the single first configuration information also includes the start-up parameters of the target purchase process under the vehicle model. The determining module is further configured to extract the target start-up parameters corresponding to the target purchase process from the target configuration information in response to the start-up operation of the target purchase process after the vehicle electronic control unit is powered on. The device also includes a generation module, configured to use the target start-up parameters as input parameters, input the general program code corresponding to the target purchase process, generate execution program code, and start the target purchase process. The general program code is a program code common to the target purchase process that does not change with the vehicle model, and the target start-up parameters are parameters that control the differentiated start-up of the general program code.

[0031] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further used to obtain the current operating condition parameters of the vehicle, and adjust the target start parameters based on the current operating condition parameters to obtain the adjusted start parameters; and the generating module is specifically used to pass the adjusted start parameters as input parameters into the general program code corresponding to the target outsourcing process to generate the executable program code.

[0032] Thirdly, a vehicle is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the vehicle to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of a multi-process scenario provided in an embodiment of this application; Figure 2 This is a schematic flowchart illustrating a process control method provided in an embodiment of this application; Figure 3 This is an interactive diagram illustrating the initiation of multiple processes provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a process management device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a controller provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0035] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0036] The Electronic Control Unit (ECU) is an embedded hardware controller in a vehicle. The embedded software inside it often adopts a multi-process architecture. That is, the entire software business of the vehicle ECU is broken down into multiple processes (executable files or program units) that can be independently scheduled and run by the operating system. Each process has its own task to achieve different functions and communicate with each other.

[0037] For example, such as Figure 1 As shown, taking the in-vehicle intelligent cockpit domain control unit as an example, there are: a multimedia playback process, responsible for decoding, rendering, and outputting audio and video files to ensure smooth playback of the cockpit entertainment system; a voice interaction process, responsible for collecting microphone audio, performing speech recognition, natural language understanding, and speech synthesis to realize human-machine voice dialogue; a vehicle status monitoring process, responsible for real-time reading and parsing of Controller Area Network (CAN) bus data (such as vehicle speed, battery level, door status, etc.) to provide basic vehicle information for upper-layer applications; and a navigation map process, responsible for loading map data, processing positioning information, and real-time planning and calculation of driving routes. These processes cooperate under the unified scheduling of the operating system and exchange data through inter-process communication mechanisms such as shared memory and message queues, thereby collaboratively empowering the in-vehicle intelligent cockpit domain control unit and ensuring the normal operation of its core functions.

[0038] Among them, the program units independently developed and maintained by the vehicle ECU R&D team are called native built-in processes. Furthermore, these native built-in processes are responsible for fundamental core business functions such as configuration management, power control, bus interaction, cloud communication, and process scheduling management. Specifically, the native built-in process responsible for configuration management can be a `config` process, and the native built-in process responsible for power control can be a `power` process. After the vehicle ECU is powered on, it is directly started by the vehicle ECU's main process (main code). This is because the native built-in processes are essential basic processes for the vehicle ECU to run. All vehicle models, regardless of configuration differences, must rely on these processes to complete overall initialization and basic scheduling. There are no optional scenarios, no configuration condition judgments are required, and it starts directly upon power-on by default. Program units packaged and delivered by external suppliers, directly integrated for use, and used to implement specific additional functions are defined as purchased processes (specifically, external integration processes). For externally purchased processes, their activation method is not automatic by default. These processes are value-added options for the vehicle model. If a lower-spec model does not have certain externally purchased processes, then of course these processes do not need to be activated; for example, some lower-spec models do not have a voice interaction process. Higher-spec models, however, can have a voice interaction process, which can be activated or deactivated after the in-vehicle intelligent cockpit domain control unit is powered on. Furthermore, for the same externally purchased process, the activation parameters differ between different models. This is because different models differ in hardware configuration, functional configuration, regulatory requirements, and backend integration strategies. The same externally purchased process requires adaptation using differentiated activation parameters. For example, for the in-vehicle IDPS (Intrusion Detection and Prevention System) process, higher-spec models need to enable full Controller Area Network (CAN) bus and Ethernet message monitoring, while setting high-frequency abnormal alarm reporting parameters; mid-spec models only monitor regular driving control messages on the vehicle's CAN bus; and lower-spec models directly restrict some monitoring rules.

[0039] It should be understood that the multimedia playback process and vehicle status monitoring process can be optional external processes for any model, while the navigation map process and voice interaction process can be optional external processes for higher-spec models.

[0040] Currently, in the aforementioned multi-process architecture, the operation and management strategy of the external procurement process is a globally fixed configuration, which cannot be flexibly configured as needed and is difficult to adapt to diverse management and management requirements.

[0041] To address the aforementioned issues, this application proposes a process management method to improve the adaptability and flexibility of the procurement process. Specific implementation steps can be found in [link to relevant documentation]. Figure 2 .

[0042] Figure 2 This is a schematic flowchart of a process control method provided in an embodiment of this application.

[0043] It should be understood that the process management method provided in this application embodiment can be applied to vehicles.

[0044] For example, such as Figure 2 As shown, the method 200 includes the following steps 201 to 203.

[0045] Step 201: Obtain multiple first configuration information of the vehicle. Each first configuration information includes a configuration word of a vehicle model and the operation control parameters of the target external purchase process under that vehicle model. The target external purchase process is an externally integrated process scheduled by the main process of the vehicle electronic control unit. The operation control parameters are used to indicate whether to enable the monitoring process of the target operation status of the target external purchase process and whether to enable the fault recovery process corresponding to the target external purchase process in abnormal situations.

[0046] It should be understood that in step 201 above, the operational control parameters for the target outsourced process (specifically, the same outsourced process, such as the vehicle IDPS process) differ across different vehicle models. In some cases, these multiple first configuration information entries are stored in a first configuration file. Optionally, this first configuration file is the cfg_launch_optional.json file. Furthermore, the selection process for outsourced processes is determined by the vehicle itself, indicating which outsourced processes can be optionally installed during vehicle production. It is not an optional program unit inherent in the vehicle ECU hardware itself; the vehicle ECU merely acts as an execution carrier to identify and support certain outsourced processes.

[0047] It should be explained here that the aforementioned first configuration file can be stored inside a non-volatile storage medium of the vehicle's electronic control unit, such as non-volatile flash memory. The first configuration file is flashed when the vehicle is off the production line and is then permanently stored in the non-volatile storage medium. The first configuration file cannot be modified during vehicle use (i.e., it is read-only), and the first configuration information in the first configuration file will not be lost after a power outage.

[0048] Furthermore, for a detailed understanding of the external integration process in step 201 above, please refer to [link / reference]. Figure 1 The corresponding explanations will not be repeated here. Furthermore, the main process of the vehicle electronic control unit is used to uniformly schedule and manage the native built-in processes and the purchased processes, which corresponds to the program code (main code) in the main firmware of the vehicle electronic control unit in the aforementioned solution.

[0049] It should also be understood that in step 201 above, the operation control parameters refer to the configuration parameters of the monitoring strategy and anomaly handling strategy during the operation of the control process after the target procurement process has been started and entered the normal operation phase. The difference between operation control parameters and startup parameters is that the management period of startup parameters is the instant of startup, while the management period of operation control parameters is the operation phase of the procurement process.

[0050] Optionally, the target operating state includes a ready state and a live state, and the fault recovery process includes a whole-machine restart process for the on-board electronic control unit and a process restart process for the target outsourced process.

[0051] Furthermore, in the above scheme, the monitoring process is executed periodically or in real-time after the purchased process has successfully started and is in operation, and can monitor its liveness or readiness status. The fault recovery process is executed when the purchased process fails, after it has successfully started and is in operation. Monitoring the liveness status means monitoring whether the target purchased process is still running normally. Monitoring the readiness status means monitoring whether the target purchased process has completed initialization and can send and receive commands and perform business interactions normally. The whole machine restart process refers to the restart process performed by the on-board electronic control unit.

[0052] Optionally, the operation control parameters include a first status flag, a second status flag, a third status flag, and a fourth status flag. The first status flag is used to configure whether to enable the monitoring process for the liveness status of the target outsourced process. The second status flag is used to configure whether to enable the monitoring process for the ready status of the target outsourced process. The third status flag is used to configure whether to enable the process restart process of the target outsourced process when an anomaly occurs. The fourth status flag is used to configure whether to enable the whole machine restart process of the target outsourced process when an anomaly occurs.

[0053] Optionally, the first, second, third, and fourth status flags are heartbeat, ready, relaunch, and reboot, respectively. When heartbeat is true, it indicates that the liveness monitoring process is enabled; when heartbeat is false, it indicates that the liveness monitoring process is disabled. When ready is true, it indicates that the ready state monitoring process is enabled; when ready is false, it indicates that the ready state monitoring process is disabled. When relaunch is true, it indicates that the process restart process is enabled; when relaunch is false, it indicates that the process restart process is disabled. When reboot is true, it indicates that the whole machine reboot process is enabled; when reboot is false, it indicates that the whole machine reboot process is disabled.

[0054] In one possible implementation, before obtaining multiple first configuration information of the vehicle in step 201 above, the method 200 further includes: obtaining multiple third information bound to the vehicle electronic control unit, wherein each third information corresponds to a native built-in process and the native program code corresponding to the native built-in process, and the native program code is the inherent execution code of the native built-in process; and starting the multiple native built-in processes based on the native program code corresponding to each of the multiple native built-in processes.

[0055] It should be understood that in some cases, these multiple third-party information entries are stored in a second configuration file. Optionally, this second configuration file is the monitored_app.json file. Furthermore, when the multiple third-party information entries define the native built-in process that is actually assembled and started in the vehicle, there is no issue of the native built-in process exceeding its compatibility support range. The native built-in process does not need to be similar to the externally purchased process; it can be started directly based solely on the third-party information. For externally purchased processes, the compatibility support range is first defined using the first configuration information, then compared and verified using the vehicle model configuration word. Subsequently, the target configuration information is determined, and based on the target startup parameters corresponding to the target externally purchased process in the target configuration information, and based on the target startup parameters and the general program code corresponding to the target externally purchased process, the target externally purchased process is started. That is, the native built-in process can be regarded as an unconditionally started process, without any restrictions on startup (i.e., there is no need to obtain the first configuration information and the vehicle model configuration word, or determine the target configuration information that matches multiple vehicle model configuration words from multiple first configuration information entries, etc.), while the externally purchased process can be regarded as a conditionally started process.

[0056] In the above technical solution, multiple third pieces of information are acquired before acquiring multiple first configuration information. This allows for the dynamic definition of the native built-in processes actually installed in the vehicle, establishing the configuration basis for the basic operating environment. Based on the native program code corresponding to each native built-in process, multiple native built-in processes are launched, ensuring that each process is correctly loaded according to its corresponding startup parameters. Furthermore, the native built-in processes do not rely on complex external configuration matching processes. After the vehicle's electronic control unit is powered on, the native built-in processes can be directly launched based on the native program code. This provides a stable and reliable basic operating environment for the scheduling of subsequent externally purchased processes, effectively improving the overall response speed and operational reliability of the vehicle's electronic system.

[0057] In one possible implementation, the single first configuration information also includes the startup parameters of the target purchase process under the vehicle model. The method 200 further includes: after the on-board electronic control unit is powered on, in response to the startup operation of the target purchase process, extracting the target startup parameters corresponding to the target purchase process from the target configuration information; using the target startup parameters as input parameters, passing them into the general program code corresponding to the target purchase process, generating execution program code to start the target purchase process; wherein, the general program code is the program code common to the target purchase process that does not change with the vehicle model, and the target startup parameters are parameters that control the differentiated startup of the general program code.

[0058] It should be understood that, in the above scheme, "powering on the vehicle electronic control unit" means that after the whole vehicle is woken up and powered on, the vehicle electronic control unit connects to the power supply, starts hardware self-testing, loads software system, etc., and finally enters a working state that can normally handle tasks (such as scheduling processes).

[0059] It should also be understood that in the above scheme, the startup parameters of the external purchase process are used to define the configuration parameters for starting the corresponding external purchase process, including the program path parameter, that is, the storage path and file name of the executable file of the corresponding external purchase process; the prerequisite dependency parameter, that is, at least one process that needs to be run before the corresponding external purchase process starts; the startup delay parameter, that is, the delay time after receiving the startup instruction of the corresponding external purchase process; the process priority parameter, that is, the priority of scheduling the corresponding external purchase process; and the initial stack parameter, that is, the initial size of the stack memory and heap memory allocated when the corresponding external purchase process is started.

[0060] Furthermore, in the aforementioned solution, the general program code contains an input parameter parsing interface. This interface receives externally issued startup parameters specific to the target vehicle model (current vehicle) for the target procurement process, allowing for dynamic adjustment of the startup logic based on different input parameters. By passing the startup parameters as input parameters to the general program code and generating executable program code, dynamic binding between the startup parameters and the general program code can be achieved. This enables the same set of general program code to generate corresponding executable instances based on the startup parameters of different vehicle models, thus supporting flexible deployment and operation of the procurement process across multiple vehicle models. This not only improves the automation of program startup but also ensures that the procurement process can complete vehicle model adaptation during the startup phase, providing reliable technical support for unified process management across multiple vehicle platforms.

[0061] Furthermore, it's important to clarify that for the target outsourcing process, its universal program code is the latest version's universal program code. The startup parameters for the target outsourcing process under each vehicle model corresponding to multiple first configuration information entries should be compatible with the process version. When updating the target outsourcing process version, the universal program code and the corresponding first configuration information need to be adjusted simultaneously. This is because updating the process version may add sub-functions or increase the required startup parameter items.

[0062] It's also necessary to explain here that the aforementioned vehicle model configuration word can be used to match vehicle-specific target startup parameters. These target startup parameters refer to a set of control parameters synchronously passed in when starting a target outsourced process. They are used to specify the hardware adaptation specifications, functional operation rules, and resource allocation methods of the same set of general programs (general program code) under the current vehicle model, enabling the general program code to start differently according to the needs of the corresponding vehicle model. Subsequently, the target startup parameters are passed to the general operating framework to generate a vehicle-specific executable program (executable program code). That is, the vehicle model configuration word here is only used to pass input parameters. Relying on the target startup parameters to drive the same set of general operating framework to produce differentiated startup effects, the core is to control the specifications with which the same outsourced process starts (belonging to the parameter injection process). The application scenario of this method 200 is to start outsourced processes to improve the adaptation flexibility of outsourced processes across vehicle models.

[0063] In the above technical solution, after the on-board electronic control unit is powered on, in response to the startup operation of the target purchase process, the target startup parameters corresponding to the target purchase process are extracted from the target configuration information. This locks the startup parameters of the target purchase process corresponding to the current vehicle. Subsequently, the target startup parameters are used as input parameters and passed to the general program code corresponding to the target purchase process to generate the execution program code. This allows the use of the same set of general program code applicable to all vehicle models, and the actual startup status of the target purchase process can be changed simply by using the target startup parameters corresponding to the current vehicle model. That is, the differentiated startup requirements of different vehicle models for the purchase process are implemented in a configuration form with a one-to-one correspondence between vehicle model and startup parameters, directly decoupling the vehicle model differentiation logic from the code layer to the configuration layer. This eliminates the need to release multiple versions of program code for the target purchase processes of multiple vehicle models, significantly reducing the maintenance workload caused by multiple versions of program code, and at the same time, it does not require modification of the general program code, effectively improving the flexibility of the purchase process to adapt to different vehicle models.

[0064] In some embodiments, the method 200 further includes: if the target purchase process is a vehicle safety-related purchase process, triggering the start operation of the target purchase process if the vehicle starts; or, if the target purchase process is not a vehicle safety-related purchase process, triggering the start operation of the target purchase process if the current vehicle status meets the preset conditions for starting the target purchase process.

[0065] In one possible implementation, the method 200 further includes: obtaining the current operating condition parameters of the vehicle, and adjusting the target start-up parameters based on the current operating condition parameters to obtain the adjusted start-up parameters; and passing the target start-up parameters as input parameters into the general program code corresponding to the target outsourcing process to generate executable program code, including: passing the adjusted start-up parameters as input parameters into the general program code corresponding to the target outsourcing process to generate the executable program code.

[0066] In the above technical solution, only one set of universal program code that does not change with vehicle model needs to be developed. By matching the corresponding startup parameters with the vehicle model configuration words pre-flashed in the vehicle, multi-vehicle compatibility can be achieved without developing separate program code for each vehicle model. This can significantly save storage resources, simplify development, flashing, and version management, and reduce maintenance costs. On this basis, the target startup parameters corresponding to the vehicle model are adjusted based on the vehicle's current operating parameters. This allows the operation of the target outsourced process to match the actual usage scenario of the vehicle, that is, to meet the differentiated startup control requirements of the vehicle under different usage scenarios. In addition, the entire differentiated adaptation process only requires the adjusted startup parameters to be used as input parameters after power-on startup, which are passed to the universal program code (which is pre-fused in the vehicle electronic control unit). There is no need to re-flash new program code, that is, the universal program code and the startup parameters are decoupled, and the universal program code can be reused. Therefore, this solution can further improve the adaptation flexibility of the outsourced process.

[0067] In some embodiments, the target external process is a voice interaction process, and the target startup parameters include the default number and activation position of the microphone hardware module. The microphone hardware module is the audio acquisition hardware of the voice interaction process. The target startup parameters are adjusted based on the current operating condition parameters to obtain the adjusted startup parameters, including: when the current operating condition parameters include the presence detection information of each seat, determining the target number and target activation position of the microphone hardware module based on the presence detection information, where the presence detection information is used to determine whether there is an occupant on the corresponding seat; replacing the default number of startups with the target number of startups, and replacing the activation position with the target activation position.

[0068] It should be understood that, under normal circumstances, the default number of microphone hardware modules enabled is the total number of microphone hardware modules, and the enabled location is the installation location of each microphone hardware module.

[0069] In some embodiments, determining the target number of microphone hardware modules to be enabled and the target location of the microphone hardware modules based on the presence detection information includes: when the presence detection information indicates that there is an occupant on the first seat, determining that the target location of the microphone hardware modules includes a first location, the first location being the installation location of the microphone hardware modules closest to the first seat; determining the number of occupants in the vehicle based on the presence detection information; and determining the target number of enabled microphone hardware modules based on the number of occupants.

[0070] Optionally, when the vehicle is a sedan and the number of occupants is the number of loads, the target number of activated units is the total number of microphone hardware modules; when the number of occupants is specifically 2 and both are in the front row, the target number of activated units is the number of microphone hardware modules already installed in the front row.

[0071] Step 202: Obtain the vehicle model configuration character written in the vehicle, determine the target configuration information that matches the vehicle model configuration character from the multiple first configuration information, and extract the target operation control parameters corresponding to the target external purchase process in the target configuration information.

[0072] It should be understood that in step 202 above, "flashing" refers to a one-time writing process in which the configuration information indicating the vehicle model is written into the non-volatile storage medium of the vehicle's on-board electronic control unit when the vehicle is off the production line at the factory. The vehicle model configuration information cannot be modified when the vehicle is used subsequently.

[0073] Furthermore, it should be understood that obtaining multiple initial configuration information for a vehicle is for the purpose of pre-entering the operational control parameters and startup parameters of the external purchase process corresponding to different vehicle models. This establishes a complete comparison table of startup parameters and operational control parameters for the external purchase process under multiple vehicle models as a query database. The vehicle model configuration word is a unique vehicle model identifier. Comparing the two allows the inherent vehicle model to be used as a search index to filter out the target startup parameters and target operational control parameters specific to the target external purchase process for the current vehicle from the query database. This ensures that the same set of general program code can execute differentiated startup and operation strategies according to the vehicle model configuration requirements, avoiding mismatches in startup parameters and operational control parameters that could lead to inconsistencies between the operational rules of the external purchase process and the actual configuration of the vehicle.

[0074] Furthermore, there are situations where the target configuration information matching the vehicle configuration word cannot be found in multiple first configuration information sources, such as the aforementioned database update delay, incorrect vehicle configuration word writing during offline flashing, or omission of the corresponding vehicle's startup parameters or operation control parameters in the first configuration file.

[0075] In some embodiments, the method 200 further includes: if no operation control parameter matching the vehicle model configuration word is found from a plurality of first configuration information, obtaining a default operation control parameter, wherein the default operation control parameter is a pre-set general minimum operation control parameter; controlling the target procurement process based on the default operation control parameter; and / or, if no startup parameter matching the vehicle model configuration word is found from a plurality of first configuration information, obtaining a default startup parameter, wherein the default startup parameter is a pre-set general minimum startup parameter; passing the default startup parameter as an input parameter into the general program code corresponding to the target procurement process, generating execution program code to start the target procurement process.

[0076] It should be understood that the above default startup parameters or default operation control parameters are set according to the minimum functional requirements and basic security policies, and are designed to ensure that the purchased process starts or runs normally and maintains a basic usable state.

[0077] In one possible implementation, before obtaining the vehicle model configuration character flashed in the vehicle in step 202, the method 200 further includes: determining whether a first target process is in a ready state, wherein the first target process is a native built-in process that can be directly started and used to load the vehicle model configuration character; and, obtaining the vehicle model configuration character flashed in the vehicle in step 202 includes: if the first target process is in a ready state, obtaining the vehicle model configuration character flashed in the vehicle from the storage file associated with the first target process.

[0078] It should be understood that in the above scheme, the first target process is specifically the config process. The first target process is a configuration service process responsible for power-on reading of various vehicle configuration information, data verification, diagnostics / remote configuration modification, etc., separating configuration management from the main process and running it independently. Typically, multiple vehicle configuration words can only be retrieved from the storage file associated with the first target process when the first target process is in a ready state. This is because the first target process exclusively manages the configuration information and mounts the storage file. When the first target process is in a ready state, it has completed initialization, loaded the vehicle configuration words, and mounted the storage file. At this point, retrieving multiple vehicle configuration words from the storage file ensures that no vehicle configuration words are lost, guaranteeing the integrity of the vehicle configuration word retrieval.

[0079] It should also be understood that the initiation process of the external procurement process requires the execution of a two-stage process. The first stage is the ready waiting process of the first target process (which requires the first target process to be in a ready state), and the second stage is the configuration matching process (which requires the target configuration information to be determined).

[0080] In the above technical solution, determining whether the first target process (the native built-in process used to load the vehicle configuration word) is in a ready state establishes a reliable process loading environment, ensuring the vehicle has the basic capability to perform subsequent configuration reading. Once the first target process is in a ready state, the vehicle configuration word is retrieved from its associated storage file. This can be achieved by using the native built-in process as a proxy, ensuring the safe and accurate reading of the vehicle configuration word. In other words, by introducing the native built-in process as an intermediate layer, the above solution encapsulates the vehicle configuration word reading logic within a stable native built-in process, decoupling configuration information acquisition from the main process and avoiding risks or dependencies arising from direct operation by the main process.

[0081] In some embodiments, determining whether a first target process is in a ready state includes: determining that the first target process is in a ready state when a ready notification signal of the first target process is received; and determining that the first target process is not in a ready state when a ready notification signal of the first target process is not received.

[0082] Step 203: After the target procurement process is started, control the target procurement process based on the target operation control parameters.

[0083] It should be understood that the target operation control parameters in step 203 above are obtained by the main process of the vehicle electronic control unit. After the target outsourcing process is started, the main process reads the target operation control parameters and selectively enables the target operation status monitoring process and the corresponding fault recovery processing process based on the target operation control parameters. The entire control logic is executed inside the main process. The strategy selection is completed only based on the target operation control parameters. There is no need to modify or change the operation logic of the target outsourcing process itself, nor is it necessary to introduce additional program code for the target outsourcing process.

[0084] In one possible implementation, step 203, controlling the target procurement process based on the target operation control parameters, includes: monitoring the target operation status when the target operation control parameters indicate that the target operation status monitoring process for the target procurement process is enabled; prohibiting the monitoring of the target operation status when the target operation control parameters indicate that the monitoring process is not enabled; and executing the corresponding fault recovery process when the target procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process for the target procurement process under abnormal conditions is enabled; and prohibiting the execution of the corresponding fault recovery process when the target procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process is not enabled.

[0085] In the above technical solution, the indication to prohibit or execute target operation status monitoring based on target operation control parameters can flexibly control the monitoring behavior of process health status. The indication to prohibit or execute fault recovery procedures based on target operation control parameters can configure fault tolerance and self-healing mechanisms as needed when processes are abnormal. In other words, the above solution can enable or disable status monitoring and fault recovery strategies during process operation through configuration, achieving dynamic configuration of operation rules and improving the adaptability and maintainability of purchased processes during operation.

[0086] In one possible implementation, the method 200 further includes: if the survival state or ready state of the target procurement process is abnormal, or if the process itself is abnormal, determining whether the corresponding process restart process is enabled, and obtaining the current first startup count of the target procurement process; if the corresponding process restart process is enabled and the first startup count is less than or equal to a first preset count, restarting the target procurement process and increasing the first startup count by a second preset count, the second preset count being less than the first preset count; if the corresponding process restart process is not enabled and / or the first startup count is greater than the first preset count, determining whether the corresponding whole machine restart process is enabled, and obtaining the current second startup count of the vehicle electronic control unit; if the corresponding whole machine restart process is enabled and the second startup count is less than or equal to a third preset count, restarting the vehicle electronic control unit and increasing the second startup count by the second preset count, the second preset count being less than the third preset count.

[0087] It should be understood that in the above scheme, the second preset number of times is 1. Optionally, the first preset number of times is greater than the third preset number of times, where the first preset number of times is 10 and the third preset number of times is 3.

[0088] In the above technical solution, determining whether the process restart procedure is enabled and obtaining the first startup count establishes a preliminary self-healing defense against process-level faults. When the process restart procedure is enabled and the first startup count is within the limit, the purchased process is restarted and a second preset count is incremented, allowing the process to perform multiple lightweight self-recovery processes. When the process restart procedure is not enabled and / or the first startup count is exceeded, determining whether the entire system restart procedure is enabled and obtaining the current second startup count of the on-board electronic control unit (ECU) escalates fault handling to the system level. When the entire system restart procedure is enabled and the second startup count is within the limit, the ECU is restarted and a second preset count is incremented, providing the ECU with multiple fault tolerance opportunities and preventing it from falling into an infinite restart loop. In other words, the above solution introduces a tiered recovery mechanism and a dynamic counter, enabling the matching of corresponding levels of handling methods to different fault types in the purchased process, distinguishing between minor anomalies and severe faults. This avoids the situation of indiscriminately restarting the purchased process, resulting in ineffective resource occupation. By using a counter to quantitatively control the number of fault retries, the restart frequency of purchased processes can be precisely constrained, preventing processes from falling into a vicious cycle of repeated crashes and infinite restarts. In other words, it ensures that faults have the fallback capability of being repaired by retry, and can terminate scheduling in a timely manner after the retry threshold is reached, thus ensuring the stable operation of the vehicle electronic control unit.

[0089] Optionally, the abnormality of the ready state of the target procurement process may be that after the target procurement process is started, no ready notification signal of the target procurement process is received within a preset time period; the abnormality of the survival state of the target procurement process may be that after the target procurement process is started and is in the ready state, no heartbeat signal of the target procurement process is detected for a preset number of consecutive times.

[0090] In one possible implementation, the method 200 further includes: prohibiting the starting of the vehicle electronic control unit when the corresponding whole machine restart process is not enabled and / or the second startup count is greater than the third preset count, storing the first abnormal information in the log, and controlling the vehicle electronic control unit to enter a degraded operation mode. The first abnormal information is used to indicate that the survival status of the target outsourced process is abnormal, the ready status is abnormal, or the process itself is abnormal, and the corresponding whole machine restart process is not enabled and / or the current second startup count is greater than the third preset count. The degraded operation mode is a restricted working mode that only retains the operation of basic functions.

[0091] It should be understood that the above scheme may cause anomalies from multiple independent dimensions (anomalies in the liveness state and / or the ready state and / or the process itself) to cause the vehicle to perform a whole-machine restart process. Therefore, it is necessary to set an upper limit protection process for the number of times before the whole-machine restart process to prevent any abnormal process from dragging the entire vehicle electronic control unit into repeated restart processes.

[0092] In the aforementioned technical solution, the on-board electronic control unit (ECU) is prohibited from starting when the overall system restart process is not initiated and / or the second startup attempt exceeds the limit. This promptly terminates invalid startup attempts, preventing the system from entering an infinite restart loop and ensuring the vehicle's underlying security. Simultaneously, the first anomaly information, including the anomaly type and the reason for recovery failure, is stored in the log. This comprehensively records the fault scene and the failure state of the recovery mechanism, providing accurate data support for subsequent fault diagnosis and problem localization, thereby improving the operational safety and fault diagnosis efficiency of the ECU.

[0093] In some embodiments, before controlling the target procurement process based on the target operation control parameters in step 203, the method 200 further includes: determining the current operating scenario of the vehicle based on the current operating condition parameters of the vehicle; and adjusting the target operation control parameters based on the operating scenario to obtain the adjusted operation control parameters.

[0094] It should be understood that the target operation control parameters obtained based on the vehicle model configuration are used to configure whether to enable the monitoring process for the target operating status of the target outsourced process and / or whether to enable the corresponding fault recovery process when the target outsourced process fails, under the corresponding vehicle model and in the default state. That is, the target operation control parameters refer to the default start / stop switches of the factory-preset target operating status monitoring process and fault recovery process, which are universal benchmark configurations that do not distinguish between vehicle operating scenarios.

[0095] Furthermore, in the above solution, the target operation control parameters are adjusted based on the operating scenario. This is because the target operation control parameters are default and fixed general baseline configurations, but the control requirements of vehicles differ under different operating scenarios. For example, when the vehicle is off and in sleep mode, there is no need to monitor the status of the target purchased processes or execute fault recovery procedures. When the vehicle is in normal operation, the status of purchased processes can be monitored. For purchased processes related to driving safety (such as driving control processes), when a purchased process fails, fault recovery procedures (including prohibiting the process restart process and the entire machine restart process) are prohibited. Faults are only reported when a purchased process fails, and the driver is responsible for handling them to avoid risks caused by sudden functional interruptions while driving. For non-driving purchased processes such as multimedia playback processes, when a purchased process fails, only the process restart process is allowed, and the entire machine restart process is never allowed. Therefore, the target operation control parameters corresponding to the purchased processes can be adjusted based on the current operating scenario of the vehicle to obtain the adjusted operation control parameters. That is, it is possible to generate real-time operating rules adapted to the current vehicle operating conditions.

[0096] In the above technical solution, the target operation and control parameters corresponding to the target procurement process are obtained, which provides a default baseline strategy for monitoring and fault recovery of the procurement process. Subsequently, the real-time dynamic operating conditions of the vehicle are perceived, and the target operation and control parameters are adjusted based on the operating scenario to obtain the adjusted operation and control parameters. This enables the actual operation strategy to adaptively adjust according to the vehicle status. That is, the above solution introduces a linkage mechanism between the vehicle's current operating condition parameters and the target operation and control parameters. When the operating scenario changes, the operating strategy for status monitoring and fault recovery can be automatically adjusted, realizing the scenario-based dynamic generation of the operating strategy, which significantly improves the adaptability and operational reliability of the procurement process under different operating conditions.

[0097] In some embodiments, based on the operating scenario, the target operating control parameters are adjusted to obtain adjusted operating control parameters, including: when the operating scenario is a driving scenario, maintaining the monitoring process for the current target operating state of the target purchased process, modifying the current system restart process of the target purchased process to prohibit the current system restart process of the target purchased process, and determining whether the target purchased process is a driving safety-related purchased process; when the target purchased process is a driving safety-related purchased process, modifying the current process restart process of the target purchased process to prohibit the current process restart process of the target purchased process; when the target purchased process is not a driving safety-related purchased process, maintaining the current process restart process of the target purchased process to generate adjusted operating control parameters; when the operating scenario is a scenario where the vehicle is powered on and parked, maintaining the monitoring process for the current target operating state of the target purchased process and the process restart process, and modifying the current system restart process of the target purchased process to prohibit the current system restart process of the target purchased process. The startup process is modified to prohibit the current system reboot process of the target external process, in order to generate adjusted operation control parameters. In the case of a firmware upgrade or hibernation scenario, the monitoring process for the current target running status of the target external process is modified to prohibit its activation, the process restart process for the target external process is modified to prohibit its activation, and the system reboot process for the target external process is modified to prohibit its activation, in order to generate adjusted operation control parameters. In the case of a diagnostic scenario, the monitoring process for the current target running status of the target external process is maintained, the process restart process for the target external process is modified to prohibit its activation, and the system reboot process for the target external process is modified to prohibit its activation, in order to generate adjusted operation control parameters.

[0098] Figure 3This is an interactive diagram illustrating the initiation of multiple processes provided in an embodiment of this application.

[0099] For example, such as Figure 3 As shown, after the vehicle electronic control unit (VECU) is powered on, if the target external process associated with the VECU is started, the main process parses the second configuration file to obtain multiple third pieces of information, and parses the first configuration file to obtain multiple first configuration information. Subsequently, after parsing the multiple third pieces of information, based on the native program code corresponding to each of the multiple native built-in processes, multiple native built-in processes are started, i.e., unconditionally started processes (including the first target process) are started directly. For conditionally started processes (i.e., the target external process), the system waits for the first target process to be in a ready state. After receiving the ready notification signal from the first target process, the system retrieves the vehicle model configuration word flashed in the vehicle from the storage file associated with the first target process. Further, the system determines the target configuration information matching the vehicle model configuration word from the multiple first configuration information, extracts the target startup parameters corresponding to the target external process from the target configuration information, and starts the target external process based on the target startup parameters and the general program code corresponding to the target external process.

[0100] Figure 4 This is a schematic diagram of the structure of a process management device provided in an embodiment of this application.

[0101] For example, such as Figure 4 As shown, the device 400 includes: Module 401 is used for: The vehicle acquires multiple first configuration information, each first configuration information including a configuration word of a vehicle model and the operation control parameters of the target external purchase process under that vehicle model. The target external purchase process is an externally integrated process scheduled by the main process of the vehicle electronic control unit. The operation control parameters are used to indicate whether to enable the monitoring process of the target operation status of the target external purchase process and whether to enable the fault recovery process corresponding to the target external purchase process in abnormal situations. Obtain the vehicle model configuration character written in the vehicle, determine the target configuration information that matches the vehicle model configuration character from the multiple first configuration information, and extract the target operation control parameters corresponding to the target external purchase process in the target configuration information; The control module 402 is used to control the target procurement process based on the target operation control parameters after the target procurement process is started.

[0102] Optionally, the control module 402 is specifically configured to: monitor the target operating status when the target operating control parameters indicate that the monitoring process for the target procurement process is enabled; prohibit monitoring the target operating status when the target operating control parameters indicate that the monitoring process is not enabled; and execute the corresponding fault recovery process when the target procurement process is abnormal and the target operating control parameters indicate that the corresponding fault recovery process for the target procurement process under abnormal conditions is enabled; and prohibit the execution of the corresponding fault recovery process when the target procurement process is abnormal and the target operating control parameters indicate that the corresponding fault recovery process is not enabled.

[0103] Optionally, the target operating state includes a ready state and a live state, and the fault recovery process includes a whole-machine restart process for the on-board electronic control unit and a process restart process for the target outsourced process.

[0104] Optionally, the acquisition module 401 is further configured to determine whether the corresponding process restart process is enabled and acquire the current first startup count of the target procurement process when the survival state, ready state, or process itself of the target procurement process is abnormal; the device 400 further includes: a processing module, configured to restart the target procurement process and increase the first startup count by a second preset count when the corresponding process restart process is enabled and the first startup count is less than or equal to a first preset count; the acquisition module 401 is further configured to determine whether the corresponding whole machine restart process is enabled and acquire the current second startup count of the vehicle electronic control unit when the corresponding process restart process is not enabled and / or the first startup count is greater than the first preset count; the processing module is further configured to restart the vehicle electronic control unit and increase the second startup count by the second preset count when the corresponding whole machine restart process is enabled and the second startup count is less than or equal to a third preset count.

[0105] Optionally, the processing module is further configured to prevent the vehicle electronic control unit from starting when the corresponding whole machine restart process is not enabled and / or the second startup count is greater than the third preset count, store the first abnormal information in the log, and control the vehicle electronic control unit to enter a degraded operation mode. The first abnormal information is used to indicate that the survival status of the target outsourced process is abnormal, the ready status is abnormal, or the process itself is abnormal, and the corresponding whole machine restart process is not enabled and / or the current second startup count is greater than the third preset count. The degraded operation mode is a restricted working mode that only retains the operation of basic functions.

[0106] Optionally, before obtaining the vehicle model configuration character flashed in the vehicle, the device 400 further includes: a determining module, used to determine whether the first target process is in a ready state, the first target process being a native built-in process that can be directly started and used to load the vehicle model configuration character; and the obtaining module 401, specifically used to obtain the vehicle model configuration character flashed in the vehicle from the storage file associated with the first target process when the first target process is in a ready state.

[0107] Optionally, before acquiring multiple first configuration information of the vehicle, the acquisition module 401 is further configured to acquire multiple third information bound to the vehicle electronic control unit, wherein each third information corresponds to a native built-in process and the native program code corresponding to the native built-in process, and the native program code is the inherent execution code of the native built-in process; the device 400 further includes: a startup module, configured to start the multiple native built-in processes based on the native program code corresponding to each of the multiple native built-in processes.

[0108] Optionally, the single first configuration information also includes the start parameters of the target purchase process under the vehicle model. The determining module is further configured to extract the target start parameters corresponding to the target purchase process from the target configuration information in response to the start operation of the target purchase process after the vehicle electronic control unit is powered on. The device 400 also includes a generation module, configured to use the target start parameters as input parameters, input the general program code corresponding to the target purchase process, generate execution program code, and start the target purchase process. The general program code is a program code common to the target purchase process that does not change with the vehicle model, and the target start parameters are parameters that control the differentiated start of the general program code.

[0109] Optionally, the determining module is further configured to obtain the current operating condition parameters of the vehicle, and adjust the target starting parameters based on the current operating condition parameters to obtain the adjusted starting parameters; and the generating module is specifically configured to use the adjusted starting parameters as input parameters and pass them into the general program code corresponding to the target outsourcing process to generate the executable program code.

[0110] Figure 5 This is a schematic diagram of the structure of a controller provided in an embodiment of this application.

[0111] For example, such as Figure 5 As shown, the controller 500 includes a storage module 501 and a processing module 502. The storage module 501 stores executable program code 503, and the processing module 502 is used to call and execute the executable program code 503 to perform a process control method.

[0112] Figure 6This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0113] For example, such as Figure 6 As shown, the vehicle 600 includes a memory 601 and a processor 602. The memory 601 stores executable program code 603, and the processor 602 is used to call and execute the executable program code 603 to perform a process management method.

[0114] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to execute a process management method provided in embodiments of this application.

[0115] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0116] When each functional module is divided according to its corresponding function, the device may further include an acquisition module, a startup module, a processing module, a generation module, a control module, and a determination module. It should be noted that all relevant content in the above method embodiments can be referenced to the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0117] It should be understood that the apparatus provided in this embodiment is used to execute the above-described process control method, and therefore can achieve the same effect as the above-described implementation method.

[0118] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant executable program code.

[0119] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0120] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a process management method provided in the above embodiments.

[0121] This embodiment also provides a computer-readable storage medium storing executable program code. When the executable program code is run on a computer, the computer performs the aforementioned method steps to implement a process control method provided in the above embodiment.

[0122] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a process control method provided in the above embodiment.

[0123] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0124] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0125] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0126] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A process management method, characterized in that, The method includes: The vehicle acquires multiple first configuration information, each first configuration information including a configuration word of a vehicle model and operation control parameters of the target external purchase process under the vehicle model. The target external purchase process is an externally integrated process scheduled by the main process of the vehicle electronic control unit. The operation control parameters are used to indicate whether to enable the monitoring process of the target operation status of the target external purchase process and whether to enable the fault recovery process corresponding to the target external purchase process in abnormal situations. Obtain the vehicle model configuration character written in the vehicle, determine the target configuration information that matches the vehicle model configuration character from the plurality of first configuration information, and extract the target operation control parameters corresponding to the target external purchase process in the target configuration information; After the target procurement process is started, the target procurement process is managed based on the target operation control parameters.

2. The method according to claim 1, characterized in that, The control of the target procurement process based on the target operation and management parameters includes: When the target operation control parameters indicate that the monitoring process for the target operational status of the target procurement process is enabled, the target operational status is monitored; when the target operation control parameters indicate that the monitoring process is not enabled, monitoring of the target operational status is prohibited; and, If the target procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process for the target procurement process under abnormal conditions is enabled, the corresponding fault recovery process shall be executed; if the target procurement process malfunctions and the target operation control parameters indicate that the corresponding fault recovery process is not enabled, the execution of the corresponding fault recovery process shall be prohibited.

3. The method according to claim 1 or 2, characterized in that, The target operating state includes a ready state and a live state, and the fault recovery process includes a whole-machine restart process for the vehicle electronic control unit and a process restart process for the target outsourced process.

4. The method according to claim 3, characterized in that, The method further includes: If the survival status of the target procurement process is abnormal, or the ready status is abnormal, or the process itself is abnormal, determine whether the corresponding process restart process is enabled, and obtain the current first startup count of the target procurement process; When the corresponding process restart procedure is enabled and the first startup count is less than or equal to the first preset count, the target outsourcing process is restarted, and the first startup count is increased by a second preset count, where the second preset count is less than the first preset count. If the corresponding process restart procedure is not enabled and / or the first number of startups is greater than the first preset number of startups, determine whether the corresponding whole machine restart procedure is enabled, and obtain the current second number of startups of the vehicle electronic control unit; When the corresponding whole machine restart process is enabled and the second startup count is less than or equal to the third preset count, the vehicle electronic control unit is restarted, and the second startup count is increased by the second preset count, where the second preset count is less than the third preset count.

5. The method according to claim 4, characterized in that, The method further includes: If the corresponding whole machine restart process is not enabled and / or the second startup count is greater than the third preset count, the vehicle electronic control unit is prohibited from starting, the first abnormal information is stored in the log, and the vehicle electronic control unit is controlled to enter a degraded operation mode. The first abnormal information is used to indicate that the survival status of the target outsourced process is abnormal, the ready status is abnormal, or the process itself is abnormal, and the corresponding whole machine restart process is not enabled and / or the current second startup count is greater than the third preset count. The degraded operation mode is a restricted working mode that only retains the operation of basic functions.

6. The method according to claim 1, characterized in that, Before obtaining the vehicle model configuration characters flashed in the vehicle, the method further includes: Determine whether the first target process is in a ready state. The first target process is a native built-in process that can be directly started and used to load the vehicle configuration word. And, obtaining the vehicle model configuration characters flashed in the vehicle includes: When the first target process is in a ready state, the vehicle model configuration word written in the vehicle is obtained from the storage file associated with the first target process.

7. The method according to claim 1 or 6, characterized in that, Before acquiring the multiple first configuration information of the vehicle, the method further includes: Acquire multiple pieces of third information bound to the vehicle electronic control unit. Each piece of third information corresponds to a native built-in process and the native program code corresponding to the native built-in process. The native program code is the inherent execution code of the native built-in process. The multiple native built-in processes are started based on the native program code corresponding to each of the multiple native built-in processes.

8. The method according to claim 1, characterized in that, The single first configuration information also includes the startup parameters of the target external purchase process under the vehicle model, and the method further includes: After the vehicle electronic control unit is powered on, in response to the start operation of the target procurement process, the target start parameters corresponding to the target procurement process are extracted from the target configuration information; The target startup parameters are used as input parameters, and the general program code corresponding to the target outsourcing process is passed in to generate the execution program code to start the target outsourcing process; The general program code is a program code that is universal to the target procurement process regardless of the vehicle model, and the target startup parameter is a parameter that controls the differentiated startup of the general program code.

9. The method according to claim 8, characterized in that, The method further includes: Obtain the current operating parameters of the vehicle, and adjust the target start parameters based on the current operating parameters to obtain the adjusted start parameters; And, the step of passing the target startup parameters as input parameters to the general program code corresponding to the target outsourcing process to generate executable program code includes: The adjusted startup parameters are used as input parameters and passed into the general program code corresponding to the target outsourcing process to generate the executable program code.

10. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 9.

Images