Software-defined new energy commercial vehicle electric control system and control method based on multi-agent cooperation

Abstract

The application discloses a software-defined new energy commercial vehicle electric control system and control method based on multi-agent cooperation, relates to the technical field of automobile electric control, and comprises a decision analysis agent layer, an intra-domain control cooperation agent layer and a software-defined execution agent layer. The analysis agent receives a VCU driving instruction and generates a driving state word. The cooperation agent interacts with related electric control modules through an internal CAN, completes control target conflict resolution and driving control parameter determination, and the execution agent drives motors, oil pumps, air pumps, batteries, high-voltage power distribution and DCDC execution objects according to a special instruction set. The method realizes decoupling of electric control software and a hardware platform, supports multi-domain cooperative control in scenarios such as double-main-drive, speed-limit driving, heavy-load uphill and downhill driving, brake energy recovery and OTA upgrading, and improves vehicle safety, power smoothness, energy utilization efficiency and software upgrading and maintenance convenience.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control technology, specifically to a software-defined electronic control system and control method for new energy commercial vehicles based on multi-agent collaboration. Background Technology

[0002] New energy commercial vehicles typically feature multiple electronic control subsystems, including a main drive motor controller, auxiliary drive controller, air pump controller, electronic oil pump controller, battery management system, high-voltage power distribution unit, DC-DC conversion module, and superstructure control module. Each subsystem is responsible for functions such as power output, energy distribution, auxiliary drive, thermal management, braking power supply, and superstructure execution. Existing electronic control systems for new energy commercial vehicles often employ a control architecture developed independently for each functional domain. Each electronic control module is typically designed with software tailored to its own hardware capabilities and local control objectives. The control software is highly coupled with specific hardware platforms such as the main motor, pump drives, high-voltage control boards, and battery management boards. When hardware models, interface types, or execution objects change, the control software often needs to be adapted or even reconstructed, resulting in poor software reusability, high development and maintenance costs, and hindering subsequent on-demand function activation and OTA upgrades. Meanwhile, existing electronic control modules primarily rely on the vehicle control unit (VCU) for command distribution and status management. There is a lack of direct collaborative communication mechanisms between electric drive, battery, air pump, oil pump, power distribution unit, DC-DC converter, and superstructure modules, tailored to specific driving conditions. In scenarios with multiple objectives, such as dual-drive coordination, speed-limited driving, heavy-load uphill and downhill driving, downhill braking energy recovery, and safe parking, each module may respond independently based on its local objective, making it difficult to achieve vehicle-level coordination among power, safety, comfort, smoothness, and energy conversion efficiency. Especially when drive acceleration requests, braking energy recovery requests, battery charging and discharging limits, pump auxiliary load requirements, and high-voltage power distribution safety constraints coexist, existing systems lack a layered resolution mechanism for control objective conflicts. This makes it difficult to complete state consistency confirmation, control priority judgment, and collaborative allocation of execution parameters within a short communication cycle, thus limiting the development of new energy commercial vehicle electronic control systems towards software-defined, cross-domain collaborative, and reconfigurable control. Existing systems suffer from high hardware-software coupling, independent control of each electronic control unit, poor software scalability, and a lack of dynamic collaboration and control objective conflict resolution mechanisms. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a software-defined electronic control system and control method for new energy commercial vehicles based on multi-agent collaboration, in order to solve the problems mentioned in the background.

[0004] To achieve the above objectives, the present invention provides the following technical solution: In a first aspect, the present invention provides a software-defined new energy commercial vehicle electronic control system based on multi-Agent collaboration, including a vehicle communication unit, multiple electronic control function sub-modules, an internal collaborative communication unit, a multi-Agent software control unit, a software-defined execution unit, and an online debugging and upgrade unit; The electronic control function submodule is connected to the vehicle communication unit, the internal collaborative communication unit and the software-defined execution unit respectively, and is used to execute the corresponding electronic control functions in the electric drive, battery, air conditioning, superstructure, power distribution, air pump, oil pump and DC conversion control scenarios of new energy commercial vehicles. The multi-Agent software control unit is deployed on the control board or main control board of each electronic control function sub-module, and forms a three-level software-defined control architecture consisting of a decision analysis agent layer, an intra-domain control collaboration agent layer, and a software-defined execution agent layer, in order to realize vehicle control command parsing, inter-module control target coordination, control parameter generation, and low-level execution action control.

[0005] This technical solution is further optimized, and the vehicle communication unit includes power CAN, vehicle CAN and debugging and maintenance CAN; The power CAN is used to connect to the power domain control modules of the main drive MCU1 and the main drive MCU2; The vehicle CAN bus is used to connect to the vehicle electronic control function sub-modules of the auxiliary drive APC, OPC, BDU, PDU, and DC-CDC. The debug and maintenance CAN is used to connect to external debug and maintenance equipment during online debugging or software upgrades and updates.

[0006] To further optimize this technical solution, the internal collaborative communication unit includes an internal CAN, which connects the electronic control function sub-modules that need to work collaboratively. It is used to transmit inter-module collaborative instructions and status confirmation information in scenarios such as dual main drive motors, speed-limited driving, heavy-load uphill and downhill driving, safe parking on slopes, and power distribution, so that each electronic control function sub-module can complete rapid collaboration without relying on VCU step-by-step forwarding.

[0007] To further optimize this technical solution, the electronic control function sub-module includes a motor controller MCU, an air pump controller EPS, an electronic oil pump controller OPC, a high-voltage control board HVB, a battery management board BMS, a power distribution unit PDU, a DC-DC converter module DCDC, and control modules corresponding to the equipment on the new energy commercial vehicle. Each electronic control function submodule is housed within the protective housing of the commercial vehicle's electronic controller and is connected to the copper busbar connector, circulating cooling circuit, relay, IGBT drive unit, permanent magnet synchronous motor, reducer, lithium battery pack, brake-by-wire system, steering-by-wire system, suspension system, and DC-DC module. It is used to execute the control parameters output by the Agent layer according to the software definition to complete current, torque, speed, pressure, pump speed, energy distribution, or high-low voltage conversion actions.

[0008] To further optimize this technical solution, each software agent in the multi-Agent software control unit includes an external interaction and perception block, a state and knowledge data block, and a reasoning and execution block; The external interaction and sensing block is used to receive driving instructions issued by the VCU, module operation data, and collaborative information from other electronic control function sub-modules. The status and knowledge data block is used to store the module ID, driving status word, control level, module running status, control protection status, and local configuration parameters. The reasoning and execution block is used to generate control parameters or execution instructions based on the driving status word, control level, and cooperative communication results.

[0009] To further optimize this technical solution, the decision analysis agent layer is deployed in each electronic control function sub-module. It is used to receive the working instructions of the vehicle control unit (VCU) through the power CAN or the vehicle CAN, and to parse, classify and perform composite analysis on multiple VCU instructions that arrive in sequence to form the driving status word corresponding to the target control scenario. The driving status word is used to characterize the control scenario, control priority, execution mode, exit conditions, and abnormal status of the current electronic control function submodule.

[0010] To further optimize this technical solution, the intra-domain control collaboration agent layer is deployed in the electronic control function sub-module that requires inter-module coordination, and interacts with the intra-domain control collaboration agent layer of other related electronic control function sub-modules through the internal CAN. The intra-domain control collaboration agent layer is used to receive the driving status word generated by the decision analysis agent layer, and to notify other relevant modules of the control decision, execution status, fault status and control level of this module, while receiving specific control instructions between modules other than the VCU.

[0011] To further optimize this technical solution, the software-defined execution agent layer is deployed in the underlying control program of each electronic control function submodule. It is used to receive the driving control parameter values ​​output by the domain control cooperation agent layer and control the corresponding hardware execution objects according to the software-defined dedicated instruction set. The hardware execution objects include permanent magnet synchronous motors, reducers, lithium battery packs, brake-by-wire systems, steering-by-wire systems, suspension systems, DC-DC modules, oil pump actuators, air pump actuators, and superstructure actuators.

[0012] To further optimize this technical solution, the software-defined execution agent layer is configured with an agent-specific instruction set. This agent-specific instruction set is used to simulate industrial PLC logic and is compatible with IL instruction syntax. It adopts a lightweight embedded deployment method to realize digital input / output control, analog input / output control, timer control, arithmetic operations, logical operations, logical judgments, program jumps, and sub-function calls.

[0013] The control method for a software-defined new energy commercial vehicle electronic control system based on multi-agent collaboration, which operates based on the aforementioned software-defined new energy commercial vehicle electronic control system, includes the following steps: S1. The analysis agent collects its own operating data and reports the data via the power CAN or vehicle CAN bus; the vehicle VCU sends driving commands to the analysis agent, which then parses and rewrites the module's driving status word based on the message context. S2. After receiving the driving status word from the analysis agent, the collaborative agent interacts with relevant modules through the internal CAN bus to confirm the status word, and calculates and determines the driving control parameter values ​​based on the target dynamic weight. S3. After receiving the driving control parameter values, the Agent controls the driving according to the parameter settings and checks whether various control and protection measures have triggered unexpected events according to preset rules, and reports driving data and events to the cooperating Agent.

[0014] In a second aspect, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program instructions are executed by the processor, they implement the steps of a software-defined new energy commercial vehicle electronic control system and control method based on multi-agent collaboration as described in the first aspect of the present invention.

[0015] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program instructions are executed by a processor, they implement the steps of a software-defined new energy commercial vehicle electronic control system and control method based on multi-agent collaboration as described in the first aspect of the present invention.

[0016] Compared with existing technologies, this invention provides a software-defined electronic control system and method for new energy commercial vehicles based on multi-agent collaboration, which has the following beneficial effects: This software-defined electronic control system and method for new energy commercial vehicles based on multi-agent collaboration constructs a three-tier architecture within the system: a decision analysis agent layer, an intra-domain control collaboration agent layer, and a software-defined execution agent layer. This architecture enables each electronic control sub-module to first undergo scenario recognition by the analysis agent, which identifies the VCU driving commands and module operating status and generates driving status words. Then, the collaboration agent uses the internal CAN bus to confirm status, determine control levels, and collaboratively allocate control parameters with relevant modules. Finally, the execution agent drives the corresponding hardware execution objects according to the software-defined dedicated instruction set. This integrates vehicle control scenario recognition, inter-module control target collaboration, and... The separation of underlying hardware execution phases decouples the electronic control software from specific hardware platforms, improving the reusability of the same software across different hardware and vehicle models. Simultaneously, a direct coordination mechanism is established between the dual main drives, oil pump, air pump, power distribution unit, battery management module, DC-DC converter, and upper structure control module. This enables the system to coordinate conflicting control requests according to control levels and vehicle safety objectives under conditions such as speed-limited driving, heavy-load uphill / downhill driving, safe parking, and downhill braking energy recovery. This reduces uneven torque distribution, inconsistent response, and safety constraint lag issues caused by independent control of single modules, thereby improving the power smoothness, driving safety, energy utilization efficiency, and reliability of subsequent OTA upgrades and maintenance for new energy commercial vehicles. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is an overall block diagram of the electronic control system of the present invention; Figure 2 This is a schematic diagram of the CAN connection line for the new energy commercial vehicle electronic control product of the present invention; Figure 3 This is a schematic diagram of the software agent structure of the present invention; Figure 4 This is a schematic diagram of the hardware resources for the Agent-specific instruction set of the present invention; Figure 5 This is the instruction code table for the Agent-specific instruction set of this invention; Figure 6 This is an instruction classification table for the Agent-specific instruction set of this invention; Figure 7 This is an example of instruction operation for the Agent-specific instruction set of the present invention. Detailed Implementation

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0020] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0021] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places throughout this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment selectively excluded from other embodiments.

[0022] Example 1: Reference Figures 1 to 7 This is the first embodiment of the present invention, which provides a software-defined electronic control system for new energy commercial vehicles based on multi-Agent collaboration. The system includes a vehicle communication unit, multiple electronic control function sub-modules, an internal collaborative communication unit, a multi-Agent software control unit, a software-defined execution unit, and an online debugging and upgrade unit. The multiple electronic control function sub-modules are respectively connected to the vehicle communication unit, the internal collaborative communication unit, and the software-defined execution unit, and are used to execute corresponding electronic control functions in electric drive, battery, air conditioning, superstructure, power distribution, air pump, oil pump, and DC-DC conversion control scenarios of the new energy commercial vehicle. The multi-Agent software control unit is deployed in the control board or main control board of each electronic control function sub-module, and forms a three-level software-defined control architecture according to the decision analysis agent layer, the domain control collaboration agent layer, and the software-defined execution agent layer, to realize vehicle control command parsing, inter-module control target collaboration, control parameter generation, and low-level execution action control.

[0023] The vehicle communication unit includes a power CAN, a vehicle CAN, and a debugging and maintenance CAN. The power CAN is used to connect to power domain control modules such as the main drive MCU1 and main drive MCU2. The vehicle CAN is used to connect to vehicle electronic control function sub-modules such as the auxiliary drive APC, OPC, BDU, PDU, and DC-DC. The debugging and maintenance CAN is used to connect to external debugging and maintenance equipment during online debugging or software upgrades. The internal collaborative communication unit includes an internal CAN, which connects the electronic control function sub-modules that need to work collaboratively. It is used to transmit inter-module collaboration commands and status confirmation information in scenarios such as dual main drive motors, speed-limited driving, heavy-load uphill and downhill driving, safe parking, and power distribution, enabling each electronic control function sub-module to complete rapid collaboration without relying on VCU hierarchical forwarding.

[0024] Multiple electronic control function sub-modules include a motor controller MCU, an air pump controller EPS, an electronic oil pump controller OPC, a high-voltage control board HVB, a battery management board BMS, a power distribution unit PDU, a DC-DC converter module DCDC, and control modules corresponding to the equipment on the new energy commercial vehicle. Each electronic control function sub-module is set in the protective housing of the commercial vehicle's electronic controller and is connected to copper busbar connectors, circulating cooling circuits, relays, IGBT drive units, permanent magnet synchronous motors, reducers, lithium battery packs, brake-by-wire systems, steering-by-wire systems, suspension systems, and DC-DC modules. They are used to execute control parameters output by the Agent layer according to software definitions to complete current, torque, speed, pressure, pump speed, energy distribution, or high-low voltage conversion actions.

[0025] Each software agent in the multi-agent software control unit includes an external interaction and perception block, a state and knowledge data block, and a reasoning and execution block. The external interaction and perception block receives driving commands, module operation data, and collaborative information from other electronic control function submodules issued by the VCU. The state and knowledge data block stores the module ID, driving status word, control level, module operating status, control protection status, and local configuration parameters. The reasoning and execution block generates control parameters or execution commands based on the driving status word, control level, and collaborative communication results. Through this structure, each electronic control function submodule can run one or more software agents on its own hardware and form a distributed collaborative control capability under a unified communication interface and unified execution rules.

[0026] The decision analysis agent layer is deployed in each electronic control function submodule. It receives operating commands from the vehicle control unit (VCU) via the powertrain CAN or vehicle CAN, and parses, classifies, and performs composite analysis on multiple VCU commands arriving in sequence to form a driving status word corresponding to the target control scenario. The driving status word represents the current control scenario, control priority, execution mode, exit conditions, and abnormal states of the electronic control function submodule. When a new energy commercial vehicle is in a driving condition with multiple control objectives, the decision analysis agent layer transmits the control scenario and driving status word it has parsed to the domain-specific control collaboration agent layer, enabling different electronic control function submodules to perform coordinated control around vehicle power performance, comfort, safety, smoothness, and energy conversion efficiency.

[0027] The intra-domain control collaboration agent layer is deployed in the electronic control function sub-modules that require inter-module coordination, and interacts with the intra-domain control collaboration agent layers of other relevant electronic control function sub-modules via internal CAN. This layer receives the driving status word generated by the decision analysis agent layer and notifies other relevant modules of its control decisions, execution status, fault status, and control level. It also receives specific inter-module control commands, excluding those from the VCU. In scenarios such as dual main drive motor coordinated control, speed limit control, heavy-load uphill / downhill driving, regenerative braking, or safe parking, the intra-domain control collaboration agent layer handles conflicts between multiple control objectives based on the control level and determines driving control parameter values ​​under the principle of prioritizing higher-level operating conditions. When it detects an inconsistency between the current driving status word and the vehicle's safety control objective, the intra-domain control collaboration agent layer can notify the decision analysis agent layer to force a change in the driving status word to ensure the consistency of the vehicle's control actions.

[0028] The software-defined execution agent layer is deployed in the underlying control program of each electronic control function submodule. It receives driving control parameter values ​​output by the domain-specific control collaboration agent layer and controls the corresponding hardware execution objects according to a software-defined dedicated instruction set. These hardware execution objects include permanent magnet synchronous motors, reducers, lithium battery packs, brake-by-wire systems, steering-by-wire systems, suspension systems, DC-DC modules, oil pump actuators, air pump actuators, and superstructure actuators. The software-defined execution agent layer does not set up control target conflict resolution strategies. Instead, it decouples the specific execution actions during vehicle operation from the driving control parameters, directly performing current regulation, torque regulation, PWM output, GPIO output, IGBT drive, or relay control according to the received control parameters. This ensures that potential control conflicts are resolved and consistent within the domain-specific control collaboration agent layer before entering the execution layer, thereby reducing the complexity of the underlying execution and improving execution determinism.

[0029] The software-defined execution agent layer is configured with a dedicated agent instruction set. This instruction set is used to simulate industrial PLC logic and is compatible with IL instruction syntax. It adopts a lightweight embedded deployment method to implement digital input / output control, analog input / output control, timer control, arithmetic operations, logical operations, logical judgments, program jumps, and sub-function calls. The agent-specific instruction set relies on fixed hardware resource mapping, which includes at least general-purpose registers R0 to R15, accumulator ACC, digital inputs DI0 to DI15, digital outputs DO0 to DO15, analog inputs AI0 to AI7, analog outputs AO0 to AO7, and timers T0 to T15. Among them, general-purpose registers are used for integer storage and data transfer, accumulators are used for floating-point operation core storage, digital inputs are used for external Boolean signal input, digital outputs are used for Boolean signal output, analog inputs are used for floating-point input, analog outputs are used for fixed-point output, and timers are used for three types of timing control: TON, TOF, and TP.

[0030] The Agent-specific instruction set has a 16-bit instruction word length and a 6-bit opcode width. Instruction types include data load / store instructions, logic operation instructions, arithmetic operation instructions, digital input / output setting instructions, analog input / output setting instructions, timer control instructions, flow control instructions, and function or system instructions. Specifically, data load / store instructions are used for data reading / writing and register assignment; logic operation instructions are used for Boolean or numerical logic judgments; arithmetic operation instructions are used for floating-point or integer mathematical operations; timer control instructions are used for delay or pulse timing control; flow control instructions are used for conditional jumps or no-operations; and function or system instructions are used for function calls or system resets. Through the Agent-specific instruction set, the Agent can parse and execute reconfigurable control logic in embedded lightweight electronic control modules, enabling the same hardware platform to implement different control functions based on different software configurations.

[0031] The Agent-specific instruction set also sets execution conventions: register range is limited to R0 to R15, digital input / output range is limited to DI0 to DI15 and DO0 to DO15, analog input / output range is limited to AI0 to AI7 and AO0 to AO7, and timer range is limited to T0 to T15; constants include logical values, integers, and floating-point numbers; multiple operands within each instruction are separated by delimiters; subfunction names or labels are represented by six letters, and the subfunction call hierarchy does not exceed two levels; the program address space is 0 to 0x3FFF, a single instruction is concatenated in 16 bits, and the single program space does not exceed 32kB; the parsing and execution time of a single instruction from obtaining to updating the ENO state is fixed at no more than 1us; multiple program segments can be saved as needed within the same Agent, and there is no direct calling relationship between different programs. Through the above execution conventions, the dedicated instruction set can meet the requirements of efficient, deterministic, and reconfigurable execution of the new energy commercial vehicle electronic control system while ensuring real-time performance.

[0032] The online debugging and upgrade unit includes an upgrade agent, which is connected to the debugging and maintenance CAN bus. It provides specific driving data and upgrade assistance functions during online debugging or software upgrades. The upgrade agent is not part of the three-tiered operational architecture consisting of the decision analysis agent layer, the domain control collaboration agent layer, and the software-defined execution agent layer, and is not active during vehicle operation. The online debugging and upgrade unit can cooperate with the VCU and various domain control agents to perform OTA upgrades. During an upgrade, the VCU receives the cloud upgrade command and upgrade package, performs encryption and integrity checks, identifies the agent to be upgraded and its corresponding software module, and generates a layered upgrade sequence. Each collaborating agent synchronizes its upgrade preparation status via the internal CAN bus. The upgrade is performed under the conditions that the high-voltage bus is not energized, local storage space is sufficient, battery power is sufficient, and there are no fault codes. In case of an anomaly, a breakpoint resume or rollback mechanism is triggered to ensure that the upgrade process does not affect the vehicle's critical control safety.

[0033] The system also includes a hardware abstraction layer and a parameterized configuration module. The hardware abstraction layer encapsulates MCU peripheral drivers, communication protocols, sensor interfaces, and low-level hardware operations, and provides standardized interfaces to upper-layer software agents, enabling analysis agents, collaboration agents, and execution agents to operate independently of specific hardware models. The parameterized configuration module configures corresponding control parameters and software functional logic based on vehicle type, control domain type, execution object type, and function activation status, allowing the same electronic control hardware platform to adapt to the different control requirements of pure electric, hybrid, or fuel cell commercial vehicles through software configuration. Through the cooperation of the hardware abstraction layer and the parameterized configuration module, the system can achieve hardware-software decoupling, cross-hardware platform reuse of the same software, and multi-functional reuse on the same hardware platform.

[0034] Therefore, the software-defined new energy commercial vehicle electronic control system based on multi-agent collaboration forms the communication foundation through power CAN, vehicle CAN, internal CAN and debugging and maintenance CAN; the hardware support foundation through motor controller, air pump controller, electronic oil pump controller, high voltage control board, battery management board, power distribution unit and DC conversion module; the three-level software-defined control foundation through decision analysis agent layer, domain control collaboration agent layer and software-defined execution agent layer; and reconfigurable execution, software and hardware decoupling and security upgrade through agent-specific instruction set, hardware abstraction layer and upgrade agent. Thus, the new energy commercial vehicle has multi-domain collaborative control capabilities in scenarios such as dual main drive collaboration, speed limit driving, heavy load uphill and downhill, energy distribution, pump control, thermal management and superstructure control.

[0035] The control method for software-defined electronic control systems of new energy commercial vehicles based on multi-agent collaboration includes the following three steps: S1. Steps for generating driving status words based on agent analysis: Each electronic control function submodule's analysis agent receives driving commands from the vehicle control unit (VCU) via the powertrain CAN or vehicle CAN, and simultaneously acquires the module's operating status data. This operating status data includes motor speed, motor torque, current, voltage, temperature, gear position, handbrake status, battery SOC, fault status, and the feedback status of the corresponding actuators. Upon receiving a driving command from the VCU, the analysis agent does not simply execute a single command. Instead, it parses, classifies, and performs composite analysis on multiple consecutively arriving commands based on the message context, command arrival sequence, controlled object type, and the current module operating status. This determines whether the vehicle is currently in a control scenario such as speed-limited driving, dual-drive coordination, heavy-load uphill driving, downhill braking energy recovery, safe parking, pump-assisted drive, or power distribution. Subsequently, the analysis agent writes the identified control scenario into the module's driving status word, which includes at least a control scenario identifier, control mode identifier, control priority, exit condition, abnormal status identifier, and module ID. Using this driving status word, the analysis agent converts external vehicle control commands from the VCU into internal control states that can be recognized and negotiated by collaborating agents within the domain, enabling different electronic control modules to participate in subsequent collaborative control under a unified state semantic. The output of this step is the driving status word corresponding to each electronic control function submodule. The analysis agent receives VCU operating commands and performs "composite" analysis on the commands arriving in sequence to form a target control scenario, while simultaneously rewriting the module driving status word.

[0036] S2. Steps for coordinating control objectives and determining parameters based on collaborative agents: Based on the driving status word generated in step S1, the cooperating agent receives the driving status word output by the analysis agent of this module, and performs status interaction and consistency confirmation with the cooperating agents of relevant electronic control function sub-modules through the internal CAN bus. The relevant electronic control function sub-modules include main drive MCU1, main drive MCU2, power distribution unit (PDU), electronic fuel pump controller (OPC), air pump controller (APC) or EPS, battery management board (BMS), high-voltage control board (HVB), and DC-DC converter module (DCDC). During the interaction, the cooperating agent sends its control decisions, execution status, control level, fault status, and available execution capabilities to other relevant modules, while simultaneously receiving status information from other modules and determining whether there are conflicts between multiple control objectives. For example, in downhill braking and power generation, if both drive acceleration and regenerative braking safety control requests exist simultaneously, the cooperating agent prioritizes higher-level operating conditions, placing the vehicle's safe driving target before the drive output target and limiting torque requests that exceed motor external characteristics or do not meet safe operating conditions. In dual-drive speed-limited operating conditions, the cooperating agent determines the vehicle's target speed, vehicle output torque, and torque distribution ratio between MCU1 and MCU2 based on the current vehicle speed, target speed limit threshold, motor speed, gear status, battery SOC, and fault status. If the cooperating agent determines that the current driving status word is inconsistent with the vehicle's safety control target, it sends a forced change instruction to the analysis agent, causing the analysis agent to rewrite the driving status word. If no forced change is required, the cooperating agent generates driving control parameter values ​​based on the confirmed driving status word and target dynamic weights, and sends these parameter values ​​to the execution agent. The output of this step is the driving control parameter value confirmed by multiple agents, including target current, target torque, target speed, torque distribution ratio, pump output parameters, power distribution parameters, or high / low voltage conversion parameters. After receiving the driving status word from the analysis agent, the collaborative agent interacts with relevant modules via the internal CAN to confirm the status word, calculates the driving control parameter values ​​based on the target dynamic weight, and notifies the analysis agent to force a change in the driving status word if necessary.

[0037] S3. Software-defined execution and feedback closed-loop steps based on the execution agent: After determining the driving control parameter values ​​in step S2, the executing agent receives the specific control parameters issued by the cooperating agent and controls the underlying execution objects according to the software-defined agent-specific instruction set. The underlying execution objects include permanent magnet synchronous motors, reducers, lithium battery packs, IGBT drive units, relays, brake-by-wire systems, steering-by-wire systems, suspension systems, DC-DC modules, air pumps, oil pumps, and upper-level actuators. Based on the received target current, target torque, target speed, output duty cycle, switch control quantity, or analog output quantity, the executing agent invokes dedicated instructions such as data loading, logic operations, arithmetic operations, timer control, flow jumps, function calls, and digital / analog input / output to complete PWM driving, GPIO output, FOC control, current closed-loop regulation, speed closed-loop regulation, pump speed control, relay action, or power conversion control. The execution agent does not resolve control target conflicts during execution; instead, it executes control actions solely according to the vehicle control parameters already agreed upon by the collaborating agents to ensure the determinism and real-time nature of the underlying execution logic. If overcurrent, overvoltage, overtemperature, communication interruption, sensor malfunction, actuator failure, or control protection conditions are triggered during execution, the execution agent generates event information and feeds back vehicle data and event status to the collaborating agent. The collaborating agent then reconfirms the status and adjusts the control parameters. If necessary, the analysis agent rewrites the driving status word, forming a closed-loop control process of "driving status word generation—collaborative parameter determination—software-defined execution—event feedback correction." After receiving the vehicle control parameter values, the execution agent controls the vehicle according to the parameter settings, checks whether the control protection measures have triggered unexpected events, and then reports the vehicle data and events to the collaborating agent.

[0038] Example 2: This embodiment provides that after the software-defined collaborative control method of the invention is completed, the collaborative control strategy scheme can be adjusted according to its respective achievement goals. Several specific control schemes are given below.

[0039] Collaborative speed-limiting vehicle control scheme: Based on the dual-master drive module, two analysis agents (deployed on MCU1 and MCU2 respectively) receive speed limit driving setting instructions (including speed limit threshold, trigger conditions, control priority and other configuration parameters) issued by VCU in real time. After synchronously parsing the instructions, the analysis agent of MCU1 generates a unified driving status word (marked as "speed limit mode enabled"), and sends it in parallel to the respective cooperating agents of MCU1 and MCU2 to complete the initialization preparation of the speed limit control scenario. After initialization, MCU1, acting as the main coordinating node, collects real-time vehicle driving data (including current vehicle speed or motor speed, gear status, handbrake status, battery SOC charging and discharging threshold, etc.). Combined with the speed limit threshold set by VCU, it calculates key control parameters such as the target vehicle speed, vehicle output torque, and torque distribution ratio through preset algorithms (speed PI adjustment, torque greedy distribution, speed difference PI adjustment, etc.). At the same time, it determines whether the speed limit triggering conditions are met (such as the vehicle speed reaching 90% of the speed limit threshold and not exceeding the shift speed, no emergency acceleration request, no fault code, etc.). Once triggered, it immediately initiates collaborative settings with the MCU2's cooperating agent and officially enters the speed limit driving control scenario.

[0040] During the parameter allocation phase, MCU1, based on the load balancing principle of the dual main drive modules, allocates the calculated target vehicle speed and output torque to MCU1 and MCU2 according to a preset ratio (which can be dynamically adjusted according to driving conditions, such as 5:5 allocation on flat roads and 6:4 allocation on uphill conditions). Then, the respective cooperating agents of the two MCUs send the commands to the corresponding execution agents (motor actuators and reducer actuators). The execution agents respond precisely to the commands, controlling the motor speed and torque output to ensure the vehicle speed remains stable within the speed limit threshold. Simultaneously, torque fluctuations are adjusted in real time to maintain optimal parameter adjustment (balancing power smoothness and energy economy). Throughout the speed limit control process, the VCU remains in a non-interventional state. The cooperating agents of MCU1 and MCU2 exchange driving data (vehicle speed, torque, speed, etc.) in real time via the internal CAN bus, dynamically correcting the control parameters to avoid problems such as exceeding speed limits and uneven torque distribution.

[0041] During the scenario anomaly handling phase, if any of the following anomalies occur (human intervention enabled: such as the driver pressing the accelerator hard to trigger a rapid acceleration request, or pressing the brake to exit the speed limit mode; system anomalies: such as vehicle speed sensor failure, motor failure, or CAN communication interruption; operating condition switching: such as entering a special operating condition like climbing or overtaking), the analysis agent of MCU1 will immediately identify the anomaly signal, rewrite the driving status word (marked as "speed limit mode exit"), and simultaneously send it to the analysis agent of MCU2. Subsequently, the collaborative agents of MCU1 and MCU2 will quickly negotiate and coordinate the exit strategy through the internal CAN, choosing between direct exit or timed segmented exit based on the anomaly type: direct exit from speed limit control and restoration of normal VCU control mode in case of active human intervention or serious system failure; and timed exit in special operating conditions, gradually adjusting the torque distribution ratio to slowly release the speed limit constraint to avoid sudden speed changes affecting driving safety. After exiting, the collaborative agent will reset the driving status word and synchronously feed back the exit result to the VCU, completing the closed-loop management of the speed limit driving control scenario.

[0042] Collaborative OTA upgrade and update solution: Based on the multi-agent collaborative architecture and the hardware-software decoupling characteristics of software-defined electronic control, with the goal of "safe, efficient, and uninterrupted key vehicle control", the VCU coordinates the execution of various domain control agents (MCU1, MCU2, APC, OPC, PDU, etc.). The specific process is as follows: The VCU receives the OTA upgrade command and upgrade package from the cloud (supporting differential upgrades, transmitting only the version difference part, greatly reducing bandwidth consumption and upgrade time). First, the upgrade package is encrypted and verified (using AES-256 encryption and SHA-256 dual verification, which meets the ISO 26262 functional safety requirements). After the verification is passed, the upgrade package information is parsed, the agent to be upgraded and the corresponding software module are identified, and a hierarchical upgrade timing strategy is generated (taking over vehicle power, such as shutting down the vehicle's main power output to avoid affecting the overall vehicle driving safety during the upgrade process, prioritizing the upgrade of non-critical domain agents, and then upgrading critical domain agents such as brake air pump and main motor drive, etc.).

[0043] The VCU sends upgrade commands, upgrade package fragments, and upgrade timing to each collaborating agent. The collaborating agent of the Power Distribution Unit (PDU) acts as the core coordination node, establishing collaborative communication with other domain agents via internal CAN to synchronize upgrade preparation status (such as verifying that the high-voltage bus is not energized, checking local storage space, verifying that the battery level is ≥30% or in a charging state, and that there are no failure codes). Once ready, each agent executes the upgrade operation according to the preset timing: non-critical domain agents complete the upgrade first and restart, sending back an upgrade success signal; subsequently, the collaborating agents of MCU1 and MCU2 collaboratively execute the electric drive domain upgrade, employing a dual backup mechanism (rolling A / B partitions). After the upgrade is completed, the two MCUs collaboratively verify upgrade consistency to ensure control parameter matching.

[0044] During the upgrade process, if network interruptions or verification failures occur, the collaborating agents immediately trigger a breakpoint resume or rollback mechanism to delete incomplete firmware and restore the previous version. Simultaneously, the VCU records the exception information and sends it to the cloud. Once the upgrade is complete, each collaborating agent reports the upgrade results to the VCU, which then aggregates and synchronizes the data with the cloud, completing the OTA upgrade loop. If the upgrade needs to be terminated (e.g., due to an emergency while driving), any analysis agent triggers an upgrade pause command. Collaborating agents negotiate via internal CAN to exit the upgrade process in stages, prioritizing vehicle power and safety control. The upgrade restarts once the condition is restored. The entire process requires no manual intervention, enabling dynamic software iteration and secure upgrades, while also meeting the full lifecycle management requirements of software-defined electronic control systems.

[0045] Software and hardware decoupling and reuse methods: Based on the core design concept of software-defined electronic control, and relying on the Hardware Abstraction Layer (HAL) and SOA service architecture, the decoupling of software and hardware in the electronic control system and the general reuse of hardware are realized. The specific approach is as follows: The AUTOSAR layered architecture design is adopted, which divides the software system into the application layer, the runtime environment layer (RTE), the basic software layer (BSW), and the hardware abstraction layer (HAL). The HAL layer encapsulates all low-level hardware operations (such as MCU peripheral drivers, communication protocols, sensor acquisition, etc.) and defines standardized API interfaces, so that the application layer software is completely independent of specific hardware models, realizing "develop once, adapt to multiple hardware", and completely solving the pain points of strong software and hardware coupling in traditional electronic control systems and the need to redevelop software for hardware iteration.

[0046] At the hardware reuse level, based on software parameterized configuration and functional modular design, the same hardware platform can be reused in multiple scenarios and for multiple functions. For example, the DC-DC module of the electric drive system can simultaneously realize three functions: high-voltage pre-charging, low-voltage power supply, and energy recovery regulation by configuring different control parameters and functional logic through software. This replaces the traditional independent pre-charging relay and low-voltage power supply module, reducing hardware redundancy and lowering the overall vehicle cost. Domain controllers of the same model (such as MCU1 and MCU2) can adapt to the electric drive control requirements of pure electric and hybrid vehicles respectively by defining different control strategies and service modules through software, or simultaneously undertake the control functions of the power domain and thermal management domain without modifying the hardware structure.

[0047] At the collaborative reuse level, agents from different domains achieve cross-hardware reuse and collaborative invocation of software functions through standardized SOA service interfaces. For example, the SOC estimation algorithm software of the BMS Agent can be seamlessly deployed on BMS hardware platforms of different manufacturers (such as Infineon TC397 and NXP S32K3) through the general interface of the HAL layer without modifying the core algorithm code. The NVH control software module of the electric drive agent can be called by the chassis agent to collaboratively achieve vehicle vibration reduction and noise reduction, realizing cross-domain reuse of software functions. At the same time, the hardware abstraction layer supports hardware status self-diagnosis, and the software can detect hardware compatibility in real time. When the hardware model is changed, only the HAL layer driver configuration needs to be updated, without reconstructing the application layer software, which greatly shortens the development cycle and reduces the adaptation cost. This meets the core requirements of software-defined electronic control of "hardware generalization and software customization". At the same time, through differentiated interface design and reuse logic, it avoids the patent conflicts of existing software and hardware decoupling.

[0048] Example 3:

[0049] This embodiment also provides a computer device applicable to a software-defined new energy commercial vehicle electronic control system and control method based on multi-agent collaboration, including a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to realize the software-defined new energy commercial vehicle electronic control system and control method based on multi-agent collaboration proposed in the above embodiment.

[0050] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements a software-defined new energy commercial vehicle electronic control system and control method based on multi-agent collaboration as proposed in the above embodiments.

[0051] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0052] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0053] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0054] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0055] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0056] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration, characterized in that, It includes a vehicle communication unit, multiple electronic control function sub-modules, an internal collaborative communication unit, a multi-agent software control unit, a software-defined execution unit, and an online debugging and upgrade unit; The electronic control function submodule is connected to the vehicle communication unit, the internal collaborative communication unit and the software-defined execution unit respectively, and is used to execute the corresponding electronic control functions in the electric drive, battery, air conditioning, superstructure, power distribution, air pump, oil pump and DC conversion control scenarios of new energy commercial vehicles. The multi-Agent software control unit is deployed on the control board or main control board of each electronic control function sub-module, and forms a three-level software-defined control architecture consisting of a decision analysis agent layer, an intra-domain control collaboration agent layer, and a software-defined execution agent layer, in order to realize vehicle control command parsing, inter-module control target coordination, control parameter generation, and low-level execution action control.

2. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 1, characterized in that, The vehicle communication unit includes a power CAN, a vehicle CAN, and a debugging and maintenance CAN; The power CAN is used to connect to the power domain control modules of the main drive MCU1 and the main drive MCU2; The vehicle CAN bus is used to connect to the vehicle electronic control function sub-modules of the auxiliary drive APC, OPC, BDU, PDU, and DC-CDC. The debug and maintenance CAN is used to connect to external debug and maintenance equipment during online debugging or software upgrades and updates.

3. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 1, characterized in that, The internal collaborative communication unit includes an internal CAN, which connects the electronic control function sub-modules that need to work collaboratively. It is used to transmit inter-module collaborative instructions and status confirmation information in scenarios such as dual main drive motors, speed-limited driving, heavy-load uphill and downhill driving, safe parking on slopes, and power distribution, so that each electronic control function sub-module can complete rapid collaboration without relying on VCU step-by-step forwarding.

4. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 1, characterized in that, The electronic control function sub-module includes a motor controller MCU, an air pump controller EPS, an electronic oil pump controller OPC, a high-voltage control board HVB, a battery management board BMS, a power distribution unit PDU, a DC-DC converter module DCDC, and control modules corresponding to the equipment on the new energy commercial vehicle. Each electronic control function submodule is housed within the protective housing of the commercial vehicle's electronic controller and is connected to the copper busbar connector, circulating cooling circuit, relay, IGBT drive unit, permanent magnet synchronous motor, reducer, lithium battery pack, brake-by-wire system, steering-by-wire system, suspension system, and DC-DC module. It is used to execute the control parameters output by the Agent layer according to the software definition to complete current, torque, speed, pressure, pump speed, energy distribution, or high-low voltage conversion actions.

5. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 1, characterized in that, Each software agent in the multi-agent software control unit includes an external interaction and perception block, a state and knowledge data block, and a reasoning and execution block. The external interaction and sensing block is used to receive driving instructions issued by the VCU, module operation data, and collaborative information from other electronic control function sub-modules. The status and knowledge data block is used to store the module ID, driving status word, control level, module running status, control protection status, and local configuration parameters. The reasoning and execution block is used to generate control parameters or execution instructions based on the driving status word, control level, and cooperative communication results.

6. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 1, characterized in that, The decision analysis agent layer is deployed in each electronic control function sub-module. It is used to receive the working instructions of the vehicle control unit (VCU) through the power CAN or the vehicle CAN, and to parse, classify and perform composite analysis on multiple VCU instructions that arrive in sequence to form the driving status word corresponding to the target control scenario. The driving status word is used to characterize the control scenario, control priority, execution mode, exit conditions, and abnormal status of the current electronic control function submodule.

7. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 1, characterized in that, The intra-domain control collaboration agent layer is deployed in the electronic control function sub-module that requires inter-module coordination, and interacts with the intra-domain control collaboration agent layers of other related electronic control function sub-modules through the internal CAN. The intra-domain control collaboration agent layer is used to receive the driving status word generated by the decision analysis agent layer, and to notify other relevant modules of the control decision, execution status, fault status and control level of this module, while receiving specific control instructions between modules other than the VCU.

8. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 1, characterized in that, The software-defined execution agent layer is deployed in the underlying control program of each electronic control function submodule. It is used to receive the driving control parameter values ​​output by the domain control cooperation agent layer and control the corresponding hardware execution objects according to the software-defined dedicated instruction set. The hardware execution objects include permanent magnet synchronous motors, reducers, lithium battery packs, brake-by-wire systems, steering-by-wire systems, suspension systems, DC-DC modules, oil pump actuators, air pump actuators, and superstructure actuators.

9. The software-defined electronic control system for new energy commercial vehicles based on multi-agent collaboration according to claim 8, characterized in that, The software-defined execution agent layer is configured with an agent-specific instruction set. This agent-specific instruction set is used to simulate industrial PLC logic and is compatible with IL instruction syntax. It adopts a lightweight embedded deployment method to realize digital input / output control, analog input / output control, timer control, arithmetic operations, logical operations, logical judgments, program jumps, and sub-function calls.

10. A control method for a software-defined new energy commercial vehicle electronic control system based on multi-agent collaboration, operating based on the software-defined new energy commercial vehicle electronic control system according to any one of claims 1-9, characterized in that, Includes the following steps: S1. The analysis agent collects its own operating data and reports the data via the power CAN or vehicle CAN bus; the vehicle VCU sends driving commands to the analysis agent, which then parses and rewrites the module's driving status word based on the message context. S2. After receiving the driving status word from the analysis agent, the collaborative agent interacts with relevant modules through the internal CAN bus to confirm the status word, and calculates and determines the driving control parameter values ​​based on the target dynamic weight. S3. After receiving the driving control parameter values, the Agent controls the driving according to the parameter settings and checks whether various control and protection measures have triggered unexpected events according to preset rules, and reports driving data and events to the cooperating Agent.

Images