System task generation, optimization, deployment methods, modules, and development tools

Abstract

This invention discloses a system task generation, optimization, and deployment method, module, and development tool. The task generation method includes: configuration, input, information acquisition, automatic generation, and compilation. A task generation module implements the task generation method. The optimization method includes: power-on operation, providing optimization suggestions, optimization, and recompilation. The deployment method includes both the task generation method and the optimization method. The task optimization module includes a task monitoring module and a task optimization module. The development tool includes an operating system automatic generation module and a task optimization module. The vehicle control system task generation method automatically deploys hundreds of applications, significantly reducing operating system configuration time and the probability of configuration errors. The optimization method can provide optimization suggestions for task deployment, thereby significantly shortening system optimization time.

Description

Technical Field

[0001] This invention relates to the technical field of automotive operating systems, specifically to methods, modules, and development tools for system task generation, optimization, and deployment. Background Technology

[0002] Automotive electronic controllers are evolving from traditional distributed controllers (ECUs) to highly integrated and intelligent centralized "domain controllers" or even "central computing units." Currently, "domain controllers" have become the mainstream of vehicle controllers. They centralize the processing of functions that were originally scattered across different ECUs by domain (such as cockpit, driving, body, and chassis). A single domain controller may integrate the functions of dozens of traditional ECUs. Domain controllers have many advantages, including hardware simplification, reducing the number of ECUs and wiring harness complexity, and enabling software-defined vehicles.

[0003] However, this also increases the complexity of developing vehicle control operating systems. Traditional ECUs typically only deploy independent functions, so they usually only need to run on a single-core chip, and the deployed applications are only a few to a dozen application software components (SWCs). The development and deployment of automotive operating system tasks can be completed manually through configuration tools.

[0004] However, due to the integration of functions, "domain controllers" often integrate hundreds or even more SWCs, which requires the deployment of hundreds of SWCs. Currently, vehicle control operating system development tools require manual creation of tasks and mounting of runnable entities to the operating system tasks. If the traditional method of manually creating tasks and mounting runnable entities is still used, not only will the workload increase exponentially, but it will also be very easy to introduce human configuration errors. Secondly, in terms of multi-core resource scheduling, domain controllers typically have 4 to 8 or more computing cores. How to scientifically allocate hundreds of Runnables to different computing cores faces complex constraints: not only do we need to consider the logical coupling between SWCs and the dependence of each component on the underlying basic software modules, but we also need to weigh the additional load and latency brought by inter-core communication, which brings challenges to the design and development of the operating system. In fact, if the deployment is not reasonable, it will affect the operation of the actual vehicle functions, and a lot of time will be needed for software optimization. Currently, there is a lack of efficient SWC deployment solutions in existing technologies. Inappropriate SWC deployment and allocation can lead to uneven system load and communication blockage, and in severe cases, it can even affect the real-time performance and safety of the entire vehicle. Summary of the Invention

[0005] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention provides a system task generation, optimization, and deployment method, module, and development tool.

[0006] According to a first aspect of the present invention, a vehicle control system task generation method includes the following steps: Configuration: Configure the standard files and configuration requirement files for the application to be mounted; Input: Input standard documents and configuration requirement documents; Information Acquisition: Obtain the requirements information from the standard files and configuration requirement files of the application to be mounted; Automatic generation: Automatically completes the generation of operating system tasks, multi-core deployment, and mounting of runnable entities; Compilation: Compile the configuration example code of the operating system and basic software code, the algorithm code of the application, and generate executable files.

[0007] The vehicle control system task generation method according to embodiments of the present invention has at least the following beneficial effects: The vehicle control system task generation method automatically deploys hundreds of applications, automatically generates operating system tasks, and completes multi-core deployment. This avoids manually creating operating system tasks, manually assigning application runnable entities to different cores, and manually mounting runnable entities to operating system tasks, thereby significantly reducing operating system configuration time and the probability of configuration errors.

[0008] According to some embodiments of the present invention, in the information acquisition step, the periodic requirements of the operable entity are obtained from a standard document; the deployment requirements are obtained from a configuration requirements document, the deployment requirements including functional safety requirements, dependent application information, call order requirements, and estimated CPU load.

[0009] According to some embodiments of the present invention, the operating system task generation step includes: The cores of the domain controller are divided into cores with different functional safety levels; Create initialization and periodic tasks for each core of the domain controller; Based on functional safety requirements, applications are assigned to the core of the corresponding functional safety level or the core of the next higher safety level. Based on the dependent application information, retrieve the applications allocated within the domain controller: If no other applications are required or no dependent applications exist within the domain controller, the application to be mounted will be mounted to the initialization task and then mounted to the corresponding periodic task according to periodic requirements. If there are dependent applications in the controller, the application to be mounted will be mounted to the initialization task and then mounted to the corresponding periodic task according to the periodic requirements. In accordance with the calling order requirements, the application to be mounted will be mounted after the dependent applications. If the total estimated load exceeds the load threshold after the application to be mounted is mounted, the application to be mounted will be mounted to the next core with the same functional security level, or the application to be mounted and its dependent applications will be mounted to the next core with the same functional security level.

[0010] According to a second aspect of the present invention, a vehicle control system task generation module is used to implement the vehicle control system task generation method described in any of the above embodiments.

[0011] The vehicle control system task optimization method according to a third aspect of the present invention includes the following steps: Power on the domain controller with the executable file written to it and monitor the execution of operating system tasks. Based on the recorded operating system task execution data, suggestions for optimizing operating system tasks are provided. Optimize operating system tasks; Recompile the operating system, configuration example code of the basic software code, and algorithm code of the application to generate an executable file.

[0012] The vehicle control system task optimization method according to embodiments of the present invention has at least the following beneficial effects: It can collect operating system-related data during system operation and provide optimization suggestions based on monitoring data. In the past, system optimization required developers to manually complete system optimization based on measured operating system data or anomaly information and their experience. The optimization cycle was long and required developers to have certain system optimization experience. This system can automatically complete system optimization based on system optimization rules proposed by experienced developers and system monitoring data, and continuously iterate, greatly shortening the system optimization time.

[0013] According to some embodiments of the present invention, the monitored operating system task execution status includes: task stack usage, CPU load rate of each core, task execution time of each application, task response time of each application, and system anomalies.

[0014] According to some embodiments of the present invention, when optimizing operating system tasks, engineers may manually adjust the operating system tasks or directly apply all optimization suggestions.

[0015] According to a fourth aspect of the present invention, a vehicle control system task optimization module is used to implement the vehicle control system task generation method described in any of the preceding claims, wherein the vehicle control system task optimization module includes: The vehicle control system task monitoring module is used to monitor and record the execution status of operating system tasks; The vehicle control system task optimization module is used to provide suggestions for optimizing operation tasks.

[0016] According to a fifth aspect of the present invention, a method for deploying a vehicle control task system is characterized in that it includes: The vehicle control system task generation method described in any of the above; The vehicle control system task optimization method described in any of the above embodiments is executed after the vehicle control system task generation method.

[0017] According to the sixth aspect of the present invention, an AUTOSAR development tool is used to implement the vehicle control task system deployment method as described in claim 9; the AUTOSAR development tool embeds: The operating system automatic generation module described above; As described above, the vehicle control system task optimization module.

[0018] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. Attached Figure Description

[0019] The present invention will be further described below with reference to the accompanying drawings and embodiments, wherein: Figure 1 This is a flowchart of a vehicle control system task generation method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the automatic generation of operating system tasks in an embodiment of the present invention. Figure 3 This is a flowchart of a vehicle control system task optimization method according to an embodiment of the present invention; Figure 4 This is a diagram showing the deployment of tasks in each core of the vehicle control system after tasks are automatically generated according to an embodiment of the present invention. Figure 5 This diagram illustrates the task deployment of each core in the vehicle control system after task optimization, as shown in this embodiment of the invention. Detailed Implementation

[0020] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0021] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the drawings and are only for the convenience of describing this invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0022] In the description of this invention, "multiple" refers to two or more. The use of "first" and "second" is for distinguishing technical features only and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or the order in which the indicated technical features are presented.

[0023] In the description of this invention, unless otherwise explicitly defined, terms such as "setting," "installing," and "connecting" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0024] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are some embodiments of the present invention, not all embodiments.

[0025] This invention discloses a vehicle control task system deployment method, a vehicle control system task generation method, a vehicle control system task optimization method, a vehicle control system task generation module, a vehicle control system task optimization module, an AUTOSAR development tool, and a storage medium.

[0026] The vehicle control system task generation module and the vehicle control system task optimization module are integrated into the AUTOSAR architecture development tool as functional components or plugins. Specifically, the vehicle control system task generation module and the vehicle control system task optimization module support local deployment via offline installation packages, or automated download, installation, and version iteration using the AUTOSAR development tool's built-in remote update mechanism or network distribution interface, or can be installed together with the purchase and installation of the AUTOSAR development tool. This integration method ensures deep coupling between the module and the development environment, enabling direct access to metadata within the development tool for task processing.

[0027] The vehicle control system deployment method includes a vehicle control system task generation method and a vehicle control system task optimization method. The vehicle control system task optimization method is performed after the vehicle control system task generation method.

[0028] The vehicle control system task generation module is used to implement the vehicle control system task generation method.

[0029] Reference Figure 1 and Figure 2 The method for generating tasks in a vehicle control system includes the following steps: S100, Configuration: Configure the standard file and configuration requirement file of the application to be mounted; S200, Input: Input standard documents and configuration requirement documents; S300, Information Acquisition: Acquire the requirement information in the standard file and configuration requirement file of the application to be mounted; acquire the lifecycle requirements of the runnable entity from the standard file; acquire the deployment requirements from the configuration requirement file, including functional safety requirements, dependent application information, call order requirements, and estimated CPU load; S400, Automatic Generation: Automatically completes operating system task generation, multi-core deployment, and mounting of runnable entities; S410, Divide the cores of the domain controller into cores with different functional safety levels; S420: Create initialization tasks and periodic tasks for each core of the domain controller; S430. Based on functional safety requirements, allocate applications to the core of the corresponding functional safety level or the core of the next higher safety level. S440. Based on the dependent application information, retrieve the applications allocated within the domain controller: S441. If no other application is required or no dependent application exists within the domain controller, the application to be mounted will be mounted to the initialization task and then mounted to the corresponding periodic task according to the periodic requirements. S442. If there are dependent applications in the controller, the application to be mounted will be mounted to the initialization task and then mounted to the corresponding periodic task according to the periodic requirements. In accordance with the calling order requirements, the application to be mounted will be mounted after the dependent applications. S450. After the application to be mounted is mounted, if the total estimated load is greater than the load threshold, the application to be mounted will be mounted to the next core with the same functional security level, or the application to be mounted and its dependent applications will be mounted to the next core with the same functional security level. S500, Compilation: Compiles the configuration example code of the operating system and basic software code, the algorithm code of the application, and generates an executable file.

[0030] The vehicle control system task optimization module is used to implement the vehicle control system task generation method. The vehicle control system task optimization method includes: an operating system task monitoring module, used to monitor and record the execution status of operating system tasks; and an operating system task optimization module, used to provide optimization suggestions for operating tasks.

[0031] The operating system task monitoring module employs compile-time static integration technology. During the compilation and build phase of the operating system tasks, the monitoring algorithm logic is embedded into the target executable file.

[0032] Reference Figure 3 The vehicle control system task optimization method includes the following steps: S600 powers on a domain controller with an executable file flashed on it and monitors the execution status of operating system tasks. The task execution status includes: task stack usage, CPU load rate of each core, task execution time of each application, task response time of each application, and system anomalies. S700: Based on the recorded operating system task execution status, provide operating system task optimization suggestions; S800 optimizes operating system tasks; when optimizing operating system tasks, engineers can manually adjust the operating system tasks or directly apply all optimization suggestions. S900, recompile the operating system, configuration example code of the basic software code, and application algorithm code to generate an executable file.

[0033] Once the domain controller boots up and enters the running state, the monitoring algorithm runs synchronously with the application tasks, capturing real-time operational characteristic data of the operating system tasks (such as task execution time, cycle jitter, and core resource utilization) as monitoring data. Subsequently, the monitoring module uploads the collected monitoring data to the host computer analysis terminal via a pre-defined communication link (including but not limited to wired transmission based on Ethernet or CAN bus, or wireless transmission based on Wi-Fi, 4G / 5G), or stores the monitoring data on a storage medium and transmits the monitoring data to the host computer using the storage medium. Based on the received monitoring data, the host computer analyzes and evaluates the execution status of the operating system tasks.

[0034] A computer-readable storage medium stores: a first computer-executable instruction and a second computer-executable instruction. The first computer-executable instruction is used to cause a computer to execute a vehicle control system task generation method; the second computer-executable instruction is used to cause a computer to execute a vehicle control system task optimization method.

[0035] This embodiment uses a domain controller that integrates body, power, and chassis functions as an example to illustrate the method for automatic generation and optimization of vehicle control operating system tasks.

[0036] This embodiment assumes that the domain controller chip has four real-time cores. Core 0 has an ASIL D functional safety level and deploys CAN and ETH drivers. Core 1 has an ASIL D functional safety level. Cores 2 and 3 have a QM functional safety level, with core 2 deploying a CAN driver. This paper assumes that a total of 10 SWC applications need to be integrated, including 5 in the body domain (Body_SWC1 ~ Body_SWC5), 3 in the power domain (PT_SWC1 ~ PT_SWC3), and 2 in the chassis domain (Chassis_SWC1 ~ SWC2).

[0037] The configuration requirements for each application SWC are as follows (in actual projects, each SWC has a separate configuration requirement table, and each configuration requirement table can be imported separately into the operating system task automatic generation module. For ease of description, the SWC configuration requirements are summarized in the table below): Table 1 Summary of SWC Configuration Requirements

[0038] Note: The configuration requirements in this document are hypothetical and may differ from actual project storage requirements.

[0039] The runnable lifecycle requirements for each application's SWC arxml file are as follows: Table 2. Runnable Periods for Each SWC

[0040] The operating system task auto-generation module is embedded in the Classic AUTOSAR basic software development tool, using the aforementioned SWC.arxml and SWC configuration requirements as input files. After each application's SWC.arxml input file is imported into the operating system task auto-generation module, the module analyzes the runnable information in each SWC.arxml file, determines the required periodic tasks based on the runnable's lifecycle, extracts relevant deployment requirements from the SWC configuration requirement file, and prioritizes creating the corresponding operating system task and mounting the runnable on the first core that meets the requirements. For applications with the same periodic task that need to be deployed to the same core, deployment is performed according to the configuration order; if there are special call order requirements, they are configured accordingly. If the calculated CPU load exceeds a threshold, new applications are deployed sequentially to the next core that meets the requirements. This system specifies that the single-core CPU load should be less than 85%, a value that can be configured as needed in the operating system task auto-generation module.

[0041] The order in which core cycle tasks are created and application SWC runnables are mounted in the operating system tasks depends on the order in which the application SWC.axml and configuration requirement files are imported into the operating system task automatic generation module. After the task is generated, the development engineer can manually adjust the order in which the runnables in the same operating system cycle task are called. In this example, the .axml and configuration requirement files of each SWC are imported in the order shown in Table 1.

[0042] The operating system task auto-generation module is embedded in the Classic AUTOSAR basic software development tool, using the aforementioned SWC.arxml and SWC configuration requirements as input files. After each application's SWC.arxml input file is imported into the operating system task auto-generation module, the module analyzes the runnable entities in each SWC.arxml file, determines the required periodic tasks based on the runnable entity cycles, extracts relevant deployment requirements from the SWC configuration requirement file, and prioritizes creating the corresponding operating system task and mounting the runnable entity on the first core that meets the requirements. For applications with the same periodic task that need to be deployed to the same core, deployment is performed according to the configuration order; if there are special call order requirements, they are configured accordingly. If the calculated CPU load exceeds a threshold, new applications are deployed sequentially to the next core that meets the requirements. This system specifies that the single-core CPU load should be less than 85%, a value that can be configured as needed in the operating system task auto-generation module.

[0043] The order in which each core's cycle task is created and each application SWC's runnable entity is mounted in the operating system task depends on the order in which the application SWC.axml and configuration requirement files are imported into the operating system task automatic generation module. After the task is generated, the development engineer can manually adjust the order in which each runnable entity is called within the same operating system cycle task. In this example, the .axml and configuration requirement files of each SWC are imported sequentially according to the order in Table 1.

[0044] The specific steps are as follows: 1) After importing Body_SWC1.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and 5ms periodic task that need to be generated. Since its configuration requirements description has no functional safety requirements, depends on the CAN basic software module, and has no dependency requirements on other SWCs, and cores 2 and 3 are non-functional safety cores, it is prioritized to be assigned to core 2. The operating system automatic generation module creates the initialization task and 5ms periodic task on core 2, and attaches the initialization of Body_SWC1 and the 5ms runnable entity to the corresponding operating system task on core 2.

[0045] 2) After importing Body_SWC2.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and the 10ms periodic task that need to be generated. Since its configuration requirements description has no functional safety requirements, depends on the CAN basic software module, and depends on Body_SWC3, and Body_SWC3 has not yet been imported, it is not processed for now. Therefore, it is prioritized for allocation to core 2. The operating system automatic generation module creates the 10ms periodic task on core 2, and the 10ms runnable entity is mounted on the corresponding operating system task on core 2. Since an initialization task has already been created on core 2, the initialization runnable entity of Body_SWC2 is mounted into the initialization task of core 2, with the mounting position following the initialization runnable entity of Body_SWC1. At this time, two applications are deployed in the core 2 periodic task, and the estimated sum of the loads is 45%, which is less than 85%, meeting the load threshold requirements.

[0046] 3) After importing Body_SWC3.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and the 10ms periodic task that need to be generated. Since its configuration requirements description has no functional safety requirements, depends on the CAN basic software module, and depends on Body_SWC4, which has not yet been imported, it is not processed for now. Body_SWC2 depends on this SWC and needs to be called after this SWC, so it is prioritized for allocation to core 2. Since the initialization task and the 10ms periodic task have already been created on core 2, the initialization runnable entity of Body_SWC3 is mounted to the initialization task of core 2, with the mounting position following the initialization runnable entity of Body_SWC2. The 10ms runnable entity of Body_SWC3 is mounted to the 10ms periodic task of core 2, with the mounting order preceding the 10ms runnable entity of Body_SWC2. At this time, three applications are deployed in the periodic task of core 2, and the estimated sum of the load is 55%, which is less than 85%, meeting the load threshold requirement.

[0047] 4) After importing Body_SWC4.arxml and its configuration requirements, the operating system's task automatic generation module parses out the initialization task and the 10ms periodic task that need to be generated. Since its configuration requirements description lacks functional safety requirements and depends on the CAN basic software module, and Body_SWC3 depends on this SWC and needs to be called after this SWC, it is preferentially assigned to core 2. Because core 2 has already created the initialization task and the 10ms periodic task, the initialization runnable entity of Body_SWC4 is mounted to the initialization task of core 2, with the mounting position following the initialization runnable entity of Body_SWC3. The 10ms runnable entity of Body_SWC4 is mounted to the 10ms periodic task of core 2, with the mounting order preceding the 10ms runnable entity of Body_SWC3. At this point, four applications are deployed in the periodic task of core 2, with an estimated total load of 65%, which is less than 85%, meeting the load threshold requirement.

[0048] 5) After importing Body_SWC5.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and the 100ms periodic task that need to be generated. Since its configuration requirements describe no functional safety requirements, depends on the CAN basic software module, and has no dependencies on other SWCs, it is preferentially assigned to core 2. Because an initialization task has already been created on core 2, the runnable initialization entity of Body_SWC4 is mounted to the initialization task on core 2, following the order of its initialization. Since no 100ms periodic task has been created on core 2 before, a 10ms periodic task is created, and the 100ms runnable entity of Body_SWC5 is mounted to the 100ms periodic task on core 2. At this point, five applications are deployed in the periodic task on core 2, with an estimated total load of 80%, which is less than 85%, meeting the load threshold requirement.

[0049] 6) After importing PT_SWC1.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and 5ms periodic task that need to be generated. Since its configuration requirements describe the functional safety level requirement as ASIL D and it depends on Chassis_SWC1, and since Chassis_SWC1 has not been imported yet, no processing is done for now. Core 0 and Core 1 are functional safety cores, so they are assigned to Core 0 first. The operating system automatic generation module creates the initialization task and 5ms periodic task on Core 0 and mounts the initialization and 5ms runnable entities of PT_SWC1 onto the corresponding operating system task of Core 0.

[0050] 7) After importing PT_SWC2.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and the 5ms periodic task that need to be generated. Since its configuration requirement describes a functional safety level of ASIL D and it has no dependencies on other SWCs, it is preferentially assigned to core 0. Because an initialization task has already been created on core 0, the runnable initialization entity of PT_SWC2 is mounted into the initialization task of core 0, following the initialization runnable entity of PT_SWC1. Similarly, because a 5ms periodic task has already been created on core 0, the 5ms runnable entity of PT_SWC2 is mounted into the 5ms periodic task of core 0, following the initialization order of PT_SWC1. At this point, two applications are deployed in the periodic task on core 0, with an estimated total load of 75%, which is less than 85%, meeting the load threshold requirement.

[0051] 8) After importing PT_SWC3.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and the 10ms periodic task that need to be generated. Since its configuration requirement describes a functional safety level of ASIL B, it needs to be deployed to a functional safety kernel and has no dependency on other SWCs. Therefore, it is initially assigned to kernel 0. However, since the current estimated load on kernel 0 is 75%, adding PT_SWC3 would increase the estimated load to 105%, exceeding 85%. Therefore, PT_SWC3 is deployed to kernel 1. The operating system automatic generation module creates the initialization task and the 10ms periodic task on kernel 1, attaching the initialization of PT_SWC3 and the 5ms runnable entity to the corresponding operating system task on kernel 1.

[0052] 9) After importing Chassis_SWC1.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and the 5ms periodic task that need to be generated. Since its configuration requirements describe a functional safety level requirement of ASIL B, and it depends on the ETH basic software module, and PT_SWC1 depends on this application, it is preferentially assigned to core 0. Because an initialization task has already been created on core 0, the runnable initialization entity of Chassis_SWC1 is mounted into the initialization task of core 0, with the mounting position following the runnable initialization entity of PT_SWC2. Since a 5ms periodic task has already been created on core 0, the runnable 5ms instance of Chassis_SWC1 is mounted into the 5ms periodic task of core 0. Because PT_SWC1 needs to be called after Chassis_SWC1, the mounting position is before PT_SWC1. At this point, three applications are deployed in the periodic task on core 0, with an estimated total load of 80%, which is less than 85%, meeting the load threshold requirement.

[0053] 10) After importing Chassis_SWC2.arxml and its configuration requirements, the operating system task automatic generation module parses out the initialization task and the 10ms periodic task that need to be generated. Since its configuration requirements do not specify functional safety level requirements, it needs to be deployed to a non-functional safety kernel and has no dependencies on other SWCs. Therefore, it is initially assigned to kernel 2. However, since the current estimated load on kernel 2 is 80%, adding Chassis_SWC2 would increase the estimated load to 100%, exceeding 85%. Therefore, Chassis_SWC2 is deployed to kernel 3. The operating system automatic generation module creates the initialization task and the 10ms periodic task on kernel 3, mounting the initialization and 10ms runnable entities of Chassis_SWC2 onto the corresponding operating system tasks on kernel 3.

[0054] At this point, the operating system task auto-generation module imports the arxml and configuration files, and automatically completes the multi-core deployment of the application SWC and the generation of operating system tasks according to preset rules. The deployment status of tasks on each core is as follows: Figure 4 As shown. The generated operating system and other basic software modules, along with application algorithm code, are compiled using a compiler to produce an executable file.

[0055] Using a flashing tool, the executable file can be downloaded to the domain controller hardware. After power-on, the operating system in the domain controller runs, sequentially polling and calling the tasks of each core in each cycle. During the operation of the operating system, the operating system task monitoring module runs in the background, monitoring various information about the operating system, such as task stack usage, CPU load rate of each core, execution time of each task, response time of each task, system anomalies, etc., and uploading the system monitoring data to the host computer in real time via CAN communication.

[0056] After receiving the system monitoring data, the host computer first saves the data. Developers then import the collected operating system monitoring data into the operating system task optimization module. This module is pre-embedded in the ClassicAUTOSAR basic software development tool. The module analyzes the operating system monitoring data and provides modification suggestions. Developers can then choose to fix one or more items individually, or fix all items with a single click.

[0057] For example, in this case, when importing monitoring data, the operating system task optimization module detected an anomaly of multiple activations in the 5ms cycle task of core 0. The analysis revealed that this was due to the excessively long execution time of the 5ms cycle task. The module further analyzed the execution time of each application (Chassis_SWC1, PT_SWC1, PT_SWC2) within the 5ms task and found that PT_SWC2's execution time was too long. Since core 1 had a low load and was a functional safety core, PT_SWC2 was moved to core 1. After the move, the estimated load on core 1 was 65%, less than 85%, meeting the threshold requirement. Therefore, a core relocation suggestion was given. After developer confirmation, a 5ms cycle task was automatically created on core 1, and the initialization of PT_SWC2 and the 5ms cycle runnable entity were automatically mounted to the initialization and 5ms cycle task of core 1. Code was generated, and the optimized core task deployment is as follows: Figure 5 As shown, developers can recompile and flash the program to run on the domain controller, continuously monitor operating system data, and iterate and optimize until the system performance is optimal.

[0058] The task deployment scheme provided in this embodiment of the invention is completed collaboratively by the vehicle control system task generation module and the vehicle control system task optimization module, so as to realize the vehicle control system task generation method and the vehicle control system task optimization method.

[0059] The vehicle control system's task generation module is responsible for automatically deploying hundreds of applications, automatically generating operating system tasks, and completing multi-core deployment. This avoids manually creating operating system tasks, manually assigning application runnable entities to different cores, and manually mounting runnable entities to operating system tasks, thereby significantly reducing operating system configuration time and the probability of configuration errors.

[0060] Simultaneously, a vehicle control system task monitoring module and a vehicle control system task optimization module were proposed. After the initial deployment of the application, the domain controller was powered on for testing. During the testing process, the operating system task monitoring module monitored the execution of operating system tasks and uploaded the monitoring data to the AUTOSAR development tool. The operating system task optimization module of the AUTOSAR development tool analyzed the monitoring data and provided operation task optimization suggestions according to the rules pre-set by the engineer.

[0061] The operating system task monitoring module can collect all operating system-related data during system operation. In traditional controller development, different information needs to be collected by different modules. For example, the collection of task execution cycle and task response time information requires the integration of third-party dedicated tools or hand-written code. The collection of CPU load rate test data requires a separate module or hand-written code. The collection of abnormal information requires the abnormal handling module. The system task monitoring module mentioned in this article uniformly implements the function of collecting all data and collects all operating system-related running / abnormal data.

[0062] The operating system task optimization module provides optimization suggestions based on preset rules (optimization rules can be user-defined), and can deploy optimized multi-core tasks with one click. Previously, system optimization required developers to manually perform optimizations based on measured operating system data or anomaly information and their experience. This process was time-consuming and required developers to have considerable system optimization experience. This system can automatically perform system optimization based on optimization rules proposed by experienced developers and system monitoring data, and iterate continuously, significantly reducing system optimization time.

[0063] The computer-readable storage medium of this invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0064] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0065] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0066] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0067] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A method for generating tasks in a vehicle control system, characterized in that, Includes the following steps: Configuration: Configure the standard files and configuration requirement files for the applications to be mounted; Input: Input standard documents and configuration requirement documents; Information Acquisition: Obtain the requirements information from the standard files and configuration requirement files of the application to be mounted; Automatic generation: Automatically completes the generation of operating system tasks, multi-core deployment, and mounting of runnable entities; Compilation: Compile the configuration example code of the operating system and basic software code, the algorithm code of the application, and generate executable files.

2. The vehicle control system task generation method according to claim 1, characterized in that, In the information acquisition step, the periodic requirements of the runnable entity are obtained from the standard documents; the deployment requirements are obtained from the configuration requirements documents, which include functional safety requirements, dependent application information, call order requirements, and estimated CPU load.

3. The vehicle control system task generation method according to claim 1, characterized in that, The steps for generating operating system tasks include: The cores of the domain controller are divided into cores with different functional safety levels; Create initialization and periodic tasks for each core of the domain controller; Based on functional safety requirements, applications are assigned to the core of the corresponding functional safety level or the core of the next higher safety level. Based on the dependent application information, retrieve the applications allocated within the domain controller: If no other applications are required or no dependent applications exist within the domain controller, the application to be mounted will be mounted to the initialization task and then mounted to the corresponding periodic task according to periodic requirements. If there are dependent applications in the controller, the application to be mounted will be mounted to the initialization task and then mounted to the corresponding periodic task according to the periodic requirements. In accordance with the calling order requirements, the application to be mounted will be mounted after the dependent applications. If the total estimated load exceeds the load threshold after the application to be mounted is mounted, the application to be mounted will be mounted to the next core with the same functional security level, or the application to be mounted and its dependent applications will be mounted to the next core with the same functional security level.

4. A vehicle control system task generation module, characterized in that, Used to implement the vehicle control system task generation method as described in any one of claims 1-3.

5. A method for optimizing vehicle control system tasks, characterized in that, Includes the following steps: Power on the domain controller with the executable file written to it and monitor the execution of operating system tasks. Based on the recorded operating system task execution data, suggestions for optimizing operating system tasks are provided. Optimize operating system tasks; Recompile the operating system, configuration example code of the basic software code, and algorithm code of the application to generate an executable file.

6. The vehicle control system task optimization method according to claim 5, characterized in that, The monitored operating system task execution status includes: task stack usage, CPU load rate of each core, task execution time of each application, task response time of each application, and system anomalies.

7. The vehicle control system task optimization method according to claim 5, characterized in that, When optimizing operating system tasks, engineers either manually adjust the operating system tasks or directly apply all optimization suggestions.

8. A vehicle control system task optimization module, characterized in that, For implementing the vehicle control system task generation method as described in any one of claims 5-7, the vehicle control system task optimization module includes: The vehicle control system task monitoring module is used to monitor and record the execution status of operating system tasks; The vehicle control system task optimization module is used to provide suggestions for optimizing operation tasks.

9. A method for deploying a vehicle control task system, characterized in that, include: The vehicle control system task generation method as described in any one of claims 1-3; The vehicle control system task optimization method as described in any one of claims 5-7 is executed after the vehicle control system task generation method.

10. An AUTOSAR development tool, characterized in that, Used to implement the vehicle control task system deployment method as described in claim 9; the AUTOSAR development tool includes: The operating system automatic generation module as described in claim 4; The vehicle control system task optimization module as described in claim 8.

Images