A method for automatically configuring communication parameters and routing of a BMS based on an AUTOSAR architecture

Abstract

The application discloses a BMS communication parameter and routing automatic configuration generation method based on an AUTOSAR architecture, and comprises the following steps: integrating BMS scattered configuration input information into structured multi-dimensional configuration input, including defining the physical topology structure of battery packs of each vehicle type; generating communication configuration according to the structured multi-dimensional configuration input, including: using a collection message intelligent distribution algorithm to realize that different vehicle types automatically generate different message distribution results according to their topology parameters, and signal level fine configuration; and converting the generated communication configuration into different format outputs to adapt to different development tool chains and application scenarios. The application realizes double improvement of configuration generation efficiency and quality, significantly shortens the BMS communication stack development cycle, effectively improves bus load and communication real-time performance through BMS scene-oriented deep optimization, and supports multi-vehicle type platform reuse, and comprehensively enhances the full-scene adaptation capability.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics and embedded software development technology, and in particular to a method and system for automatically generating communication parameters and routing configurations for a battery management system based on the AUTOSAR standard architecture, applicable to BMS platform development scenarios with multiple vehicle models and multiple battery pack topologies. Background Technology

[0002] With the rapid development of the new energy vehicle industry, the software complexity and communication requirements of the battery management system (BMS), as the core control unit of the power battery system, continue to increase.

[0003] Under the AUTOSAR architecture (AUTomotive Open System Architecture), the communication function of the BMS is implemented collaboratively by multiple basic software modules such as CanIf (CAN Interface), PduR (PDU Router), and COM (Communication). The configuration parameters of each module are interconnected and numerous.

[0004] BMS communication has distinct characteristics compared to other vehicle ECUs (Electronic Control Units): First, it collects an exceptionally large number of signals, with hundreds of individual cell voltage and temperature signals, accounting for over 70% of all signals; second, the signals exhibit strong regularity, with collected signals arranged systematically by cell, module, and slave board; third, the message period varies greatly, ranging from tens of milliseconds to seconds, a span of hundreds of times; fourth, the battery topology is highly diverse, with significant differences in the number of cells connected in series and parallel, the number of modules, and the number of slave boards across different vehicle models; and fifth, there is an urgent need for platformization, as the same platform needs to support multiple vehicle models, each requiring separate configuration.

[0005] Currently, there are two main methods for configuring BMS communication: one is manual configuration, where engineers define messages, signals, and routes one by one in the AUTOSAR configuration tool. This method is labor-intensive, time-consuming, error-prone, and difficult to ensure configuration consistency. The other method is to use general configuration generation tools (such as the automatic generation method for CAN communication and routing configuration of multiple vehicle models under the AUTOSAR architecture disclosed in Chinese patent document CN117692271A). These tools automatically generate configurations by parsing DBC (Database CAN) or ARXML files (AUTOSAR XML, AUTOSAR configuration description files). However, these tools are all designed for general ECUs and have not been deeply optimized for the structural characteristics of BMS.

[0006] The general configuration generation tool has the following shortcomings in the BMS scenario: First, the collection message allocation is unreasonable, the data load utilization is low, and the cross-module data reassembly overhead is large; Second, the configuration granularity is limited to the message level, and there is a lack of fine-grained configuration strategies at the signal level; Third, the multi-vehicle adaptation capability is weak, and each vehicle model needs to be reconfigured, lacking efficient platform-based configuration management methods. Summary of the Invention

[0007] The purpose of this invention is to provide a method and system for automatically generating communication parameters and routing configurations of a battery management system based on the AUTOSAR standard architecture, so as to break the status quo that the existing AUTOSAR communication configuration generation schemes are all general ECU designs and lack targeted optimization for BMS structural features.

[0008] To address this, the present invention provides a method for automatically generating communication parameters and routes for a Battery Management System (BMS), comprising: integrating the dispersed configuration input information of the BMS into a structured multi-dimensional configuration input, including defining the physical topology of the battery pack for each vehicle model; generating communication configuration based on the structured multi-dimensional configuration input, including: using an intelligent message allocation algorithm to automatically generate different message allocation results for different vehicle models based on their topology parameters, and uniformly processing acquisition signals from different sources and application signals input by the user, automatically generating complete configuration parameters conforming to the AUTOSAR standard according to mapping rules; and converting the generated communication configuration into different output formats to adapt to different development toolchains and application scenarios.

[0009] According to another aspect of the present invention, an automatic configuration generation system for communication parameters and routes for a Battery Management System (BMS) is provided. This system employs a three-layer architecture, including a configuration input layer, an intelligent generation engine layer, and a configuration output layer. The configuration input layer integrates the dispersed configuration input information from the BMS into a structured, multi-dimensional configuration input, including defining the physical topology of the battery pack for each vehicle model. The intelligent generation engine layer generates communication configurations based on the structured, multi-dimensional configuration inputs, including: using a message allocation algorithm to automatically generate different message allocation results for different vehicle models based on their topology parameters; and uniformly processing acquisition signals from different sources and application signals input by the user, automatically generating complete configuration parameters conforming to the AUTOSAR standard according to mapping rules. The configuration output layer converts the generated communication configurations into different output formats to adapt to different development toolchains and application scenarios.

[0010] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the above-described method for automatically generating communication parameters and routes for a BMS.

[0011] Compared with the prior art, the present invention has the following beneficial effects:

[0012] (1) Improved configuration generation efficiency and quality, and significantly shortened development cycle.

[0013] This invention achieves fully automated generation of BMS communication configurations, reducing the workload of traditional manual configuration (which can take several days) to minutes. Acquisition signals no longer need to be manually defined one by one; the tool automatically generates a complete list of acquisition signals based on battery topology parameters. Message allocation, signal layout, and periodic configuration are all automatically optimized by algorithms. Configurations for each layer (Com, PduR, CanIf) are automatically generated item by item, eliminating the need for manual configuration. Multiple output formats are generated at once, eliminating the need for repeated conversions between different tools. Cross-module consistency checks are also performed during configuration generation to ensure the correct correspondence between configuration layers, avoiding omissions and errors that are prone to occur during manual configuration.

[0014] (2) Deep optimization of BMS scenarios significantly improves bus performance and communication efficiency.

[0015] Deep optimization was performed to address the structural characteristics of the BMS, which involves a large number of signals and strong regularity. A message allocation algorithm based on battery topology driving and acquisition chip constraints ensures physical locality of data and chip boundary alignment, reducing the overhead of cross-chip and cross-module data reassembly. Fine-grained signal-level configuration extends the configuration granularity from the message level to the signal level, automatically generating ComSignal and notification callback configurations item by item, achieving fully automated signal configuration generation. Automatic generation of routing and interface configurations ensures the consistency and integrity of configurations at the Com, PduR, and CanIf layers, avoiding errors from manual cross-module configuration adjustments.

[0016] (3) Multi-model platform reuse, enhanced adaptability to all scenarios

[0017] This invention enables centralized management and rapid adaptation across multiple vehicle models and platforms using an Excel sheet configuration table. The configuration for each vehicle model can be defined and adjusted using parameters in the table, including battery topology, acquisition chip model, and temperature sensor distribution. Adding a new vehicle model only requires modifying the topology parameters in the sheet; the system automatically generates the configuration for all acquisition signals, eliminating the need to manually define hundreds of acquisition signals. It also supports dual-format output of ARXML and C code, adapting to different development toolchains and application scenarios, significantly enhancing its all-scenario adaptability.

[0018] In addition to the objectives, features, and advantages described above, the present invention has other objectives, features, and advantages. The invention will now be described in further detail with reference to the figures. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0020] Figure 1 This is a flowchart of the automatic configuration generation method for communication parameters and routes for BMS according to an embodiment of the present invention;

[0021] Figure 2 This is the overall system architecture diagram;

[0022] Figure 3 This is a flowchart of the improved FFD message packaging algorithm;

[0023] Figure 4 This is a flowchart of the signal layout optimization algorithm;

[0024] Figure 5 This is a flowchart of the configuration output layer technology method;

[0025] Figure 6 This is a flowchart for configuring quality verification. Detailed Implementation

[0026] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] like Figure 1 As shown, the automatic configuration generation method for communication parameters and routes for BMS in this embodiment includes the following steps S1 to S3.

[0028] S1. Integrate the scattered configuration input information of BMS into a structured multi-dimensional configuration input, including defining the physical topology of the battery pack for each vehicle model;

[0029] S2. Generate communication configuration based on structured multi-dimensional configuration input, including: using the intelligent allocation algorithm of the collected messages to realize different message allocation results for different vehicle models according to their topology parameters, and uniformly processing the collected signals from different sources and the application signals input by the user, and automatically generating complete configuration parameters that conform to the AUTOSAR standard according to the mapping rules.

[0030] S3. Convert the generated communication configuration into different output formats to adapt to different development toolchains and application scenarios.

[0031] The battery management system communication parameter and route automatic configuration generation system in this embodiment is used to implement the above method. It is implemented based on the AUTOSAR standard architecture, and the overall system adopts a three-layer architecture design, as follows: Figure 2As shown, it includes: a configuration input layer, an intelligent generation engine layer, and a configuration output layer. The configuration quality verification system runs throughout the entire process, performing consistency checks at each stage, including input, generation, and output, providing end-to-end quality assurance for the entire configuration generation process.

[0032] I. Input Layer Configuration: Multi-dimensional Input Model Configuration

[0033] The configuration input layer is the entry point of the entire system. It is responsible for integrating scattered and multi-dimensional configuration information into a structured internal representation, providing a unified data foundation for subsequent intelligent generation.

[0034] This layer contains six configuration dimensions, each corresponding to a different aspect of BMS communication configuration.

[0035] The configuration input layer uses an Excel configuration spreadsheet as the input format, containing six configuration dimensions covering various aspects such as vehicle platform, battery topology, application communication matrix, function configuration, routing rules, and quality constraints. This Excel spreadsheet enables centralized management and rapid adaptation across multiple vehicle models and platforms; the configuration for each vehicle model can be defined and adjusted using parameters within the spreadsheet. The configuration input layer adopts a "configuration as data" design philosophy, managing all configuration information in a structured data format, avoiding the drawbacks of hard coding and manual configuration.

[0036] 1. Vehicle platform configuration dimension

[0037] Each vehicle model maintains a complete Excel configuration spreadsheet, containing six sheets: vehicle platform, battery topology, application communication matrix, function configuration, routing rules, and quality constraints.

[0038] The vehicle platform sheet contains basic information such as vehicle identification, platform version, and hardware platform, as well as CAN hardware configuration parameters, providing hardware resource basis for the automatic generation of CANIf module (CAN interface module) configuration.

[0039] CAN hardware configuration parameters include: baud rate configuration for each CAN channel, number of transmit mailboxes, number of receive mailboxes, mailbox type (basic mailbox / full-featured mailbox), message ID filtering mode (hardware filtering / software filtering), CAN FD (CAN with Flexible Data-rate) support, and data segment baud rate, etc. This dimension allows for quick identification and selection of target vehicle models, enabling centralized management of multi-vehicle configurations.

[0040] The vehicle platform configuration dimension also supports a vehicle inheritance mechanism, whereby child vehicles can inherit the configuration of their parent vehicles and make incremental modifications on this basis, further reducing the workload of configuration.

[0041] 2. Battery Topology Configuration Dimension

[0042] Defining the physical topology of the battery pack and the hardware configuration for data acquisition for each vehicle model is the core input for automatic signal generation. Users only need to configure the battery topology parameters and the model of the acquisition chip in this dimension, and the system can automatically generate all types of acquisition signals and their message assignments, eliminating the need to manually define hundreds of acquisition signals.

[0043] The configuration parameters in this dimension directly or indirectly serve the generation of acquired signals, message allocation, and signal attribute configuration. These include core parameters such as the number of battery cells in series, the number of slave boards, the model of the acquisition chip, the number of channels per chip, and the total number of temperature sensors, as well as auxiliary parameters such as the number of modules, ADC resolution, and register mapping method. The topology parameters differ for different vehicle models, and are distinguished by the corresponding columns in the table.

[0044] The battery pack topology configuration dimension includes the following core sub-items:

[0045] (1) Cell topology parameters: The number of cells in series is the core parameter for generating the acquired signal, which directly determines the total number of voltage acquisition signals.

[0046] (2) Module topology parameters: number of modules, number of cells per module, module numbering rules, etc., used for signal grouping reference and naming.

[0047] (3) Slave board topology parameters: number of slave boards, number of modules per slave board, number of cells per slave board, slave board numbering rules, etc. Among them, the number of slave boards and the number of cells per slave board are the core parameters for message grouping and CAN ID allocation, and the slave board numbering rules are used for signal and message naming.

[0048] (4) Acquisition chip parameters: acquisition chip model, number of chips per slave board, number of voltage channels per chip, number of temperature channels per chip, ADC resolution, register mapping method, etc. Among them, the acquisition chip model, number of chips per slave board, number of voltage channels per chip, and number of temperature channels per chip are the core parameters for signal generation and message packaging, which directly determine the acquisition capability and data organization method of each slave board; ADC resolution is used for signal resolution configuration; register mapping method is used for PDU layout optimization. Different acquisition chips (such as LTC6813, BQ76952, MC33772, etc.) have different number of channels, precision and register mapping, which have a direct impact on the allocation of acquisition messages and signal layout.

[0049] (5) Temperature sensor distribution parameters: total number of temperature sensors, number of temperature sensors per module, etc. The total number of temperature sensors is used to verify the integrity of the number of temperature acquisition signals, the number of temperature sensors per module is used for physical location reference, and the signal naming adopts a unified board-chip-channel numbering rule.

[0050] The battery pack topology configuration dimension supports multi-level topology descriptions, including three levels: cell level, module level, and slave board level. Each level has corresponding configuration parameters to ensure the completeness and accuracy of the topology description. Among them, the core parameters of the cell level and slave board level are direct inputs for the automatic generation of acquired signals and message allocation, while the module level parameters are mainly used for group reference and naming.

[0051] 3. Application Communication Matrix Configuration Dimension

[0052] This dimension defines the basic information for application layer communication, including application message definitions and application signal definitions. This dimension only covers application layer signals (such as SOC, SOH, fault alarms, control commands, etc.) and does not include data acquisition signals (single cell voltage, temperature, etc.), which are automatically generated by the system based on battery topology parameters. The message definition includes message name, message ID, transmission direction, DLC (Data Length Code), transmission cycle, function category, CAN channel, priority, whether it is CANFD, source node, and target node. The signal definition includes the associated message, signal name, signal type, bit width, data type, byte order, start bit, resolution, offset, initial value, invalid value, timeout factor, and unit. This dimension uses an Excel spreadsheet format for easier batch editing and management, and supports defining different application communication matrices for different vehicle models.

[0053] 4. Functional Configuration Matrix Dimension

[0054] This dimension defines the functional categories, names, descriptions, and supported vehicle models for various signals. It forms the basis for fine-grained signal-level configuration, enabling differentiated configuration strategies through functional classification. Different vehicle models can adjust their configuration parameters according to functional requirements. The functional configuration matrix supports a three-level functional classification system: Level 1 classification includes protection, status, acquisition, and diagnostic functions; Level 2 classification further subdivides Level 1, such as control functions including active equalization, thermal management, and fast charging; Level 3 classification allows for personalized configuration for specific signal types.

[0055] 5. Routing rule configuration dimension

[0056] Define routing rules for the PduR layer, including route ID, route name, source bus, destination bus, source packet ID, destination packet ID, route type, trigger method, activation conditions, and conditional expressions. This dimension supports configuration scenarios such as one-to-one routing and conditional routing, meeting the routing requirements of collected and application packets in the BMS communication stack. Routing rules are configured according to vehicle model; different vehicle models can define different routing strategies based on communication needs.

[0057] 6. Quality Constraint Configuration Dimension

[0058] Define quality constraints during the configuration generation process, including lower limits for message payload utilization (set separately for voltage and temperature message types), CAN ID uniqueness, signal integrity, routing connectivity, cross-module consistency, consistency of the number of acquired signals, and naming convention compliance, to ensure that the generated configuration meets preset quality requirements. Quality constraint parameters can be flexibly adjusted according to the actual needs of the vehicle model. Constraint types are divided into hard constraints and soft constraints: hard constraints are mandatory conditions; failure to meet them will terminate configuration generation and report an error; soft constraints are recommended conditions; failure to meet them will provide a warning but will not halt the generation process.

[0059] The design of the configuration input layer follows three principles: layered decoupling, incremental expansion, and consistency constraints. Layered decoupling means that each configuration dimension is relatively independent, allowing for individual modification and expansion, with interactions between dimensions through explicit interfaces. Incremental expansion means that vehicles in the same series can be iterated upon by copying existing Excel spreadsheets; derivative vehicles only need to copy the complete spreadsheet from the existing model and modify the differences (such as battery topology parameters, application signal additions or subtractions) to quickly generate new vehicle configurations, without starting from scratch. Consistency constraints ensure the integrity and correctness of configuration data through cross-dimensional consistency checks, including reference consistency, range consistency, and naming consistency.

[0060] II. Intelligent Generation Engine Layer

[0061] The intelligent generation engine layer is the core of the system, responsible for automatically generating complete communication configurations based on the structured model provided by the configuration input layer. This layer includes two core functional modules: a packet allocation algorithm and a signal-level fine-grained configuration generation mechanism. The intelligent generation engine layer integrates professional knowledge and experience in the BMS field into the algorithm, achieving an upgrade from mechanical conversion to intelligent optimization.

[0062] 1. Intelligent Allocation Algorithm for Collected Messages

[0063] In a distributed BMS architecture, this algorithm generates the communication stack configuration for the mainboard (BMC). The acquisition chip driver, SPI communication, and hardware register configuration for the slave board (CSC) are not within the scope of this algorithm. The algorithm standardizes the transmission format of the acquisition messages—including message ID allocation rules, signal arrangement within the message, and transmission period—allowing the slave board to package and transmit acquisition data according to this format. The mainboard then receives and parses the data using the same format, thus ensuring communication consistency between the master and slave boards.

[0064] The intelligent message allocation algorithm is a core algorithm designed for the structural characteristics of BMS (Battery Management System) that involves a large number of signals with strong regularity. This algorithm takes battery pack topology parameters as input and automatically completes the entire process of signal generation, signal grouping, message packaging, ID allocation, and signal layout optimization, achieving optimized allocation of acquired messages.

[0065] The algorithm supports generating collection message schemes corresponding to different vehicle models based on vehicle model configurations. Different vehicle models automatically generate different message allocation results based on their topology parameters.

[0066] It comprises five core components: an automatic signal generation mechanism, a physical topology-based signal grouping optimization, a message packaging optimization algorithm, a hierarchical CAN ID intelligent allocation strategy, and a signal layout optimization algorithm.

[0067] The five parts are arranged in a progressive order according to the sequence of signal processing: First, an automatic list of acquired signals is generated to solve the signal source problem; then, preliminary grouping is performed based on the topology to solve the signal organization problem; next, message packaging optimization is performed to solve the mapping problem between signals and messages; then, CAN IDs are assigned to solve the message identification and priority problem; finally, the layout of signals in messages is optimized to solve the problem of internal space utilization in messages, and together they achieve intelligent and efficient allocation of acquired messages.

[0068] The specific parts are as follows:

[0069] 1) Automatic signal generation mechanism

[0070] Based on battery topology parameters, acquisition chip parameters, and signal naming convention templates, a complete list of acquisition signals is automatically generated, eliminating the need for manual definition by the user. Voltage acquisition signals are generated sequentially according to cell number, and temperature acquisition signals are generated sequentially according to chip temperature channels. Each signal is automatically populated with default attributes, including data type, length, resolution, offset, unit, and range. Different vehicle models generate a corresponding number of acquisition signals based on their topology parameters and chip model.

[0071] The key steps of the automatic signal generation mechanism include:

[0072] (1) Voltage signal generation: Based on the number of battery cells in series and the model of the acquisition chip, a list of voltage acquisition signals is automatically generated according to the hierarchical structure of slave board-chip-channel. The number of voltage channels on each slave board is determined by the chip model, and the signal number corresponds one-to-one with the chip channel number.

[0073] (2) Temperature signal generation: Based on the total number and distribution parameters of temperature sensors, a list of temperature acquisition signals is automatically generated according to the hierarchical structure from board to chip to channel. The number and type of temperature signals are determined by the temperature channel configuration of the acquisition chip.

[0074] (3) Automatic filling of signal attributes: Automatically set the length, resolution, range and other parameters of the signal according to the resolution of the ADC (Analog-to-Digital Converter) of the acquisition chip; automatically set the default data type and byte order according to the signal type.

[0075] (4) Naming rule application: Automatically generate signal names according to the preset number-based naming rule template.

[0076] The automatic signal generation mechanism employs a number-based naming convention template. Voltage and temperature signals are named sequentially from board-chip-channel number to ensure consistency and regularity. During signal generation, the physical value range of the signal is also automatically calculated to ensure configuration accuracy.

[0077] 2) Signal grouping optimization based on physical topology

[0078] The acquired signals are grouped hierarchically according to the physical topology of the battery pack and the channel constraints of the acquisition chips. The first layer is grouped by slave board, with acquisition signals from the same slave board preferentially assigned to the same message; the second layer is grouped by acquisition chip, with acquisition signals from the same chip preferentially combined to ensure data chip boundary alignment; the third layer is grouped by module, with acquisition signals from the same module preferentially combined together. This grouping method ensures the physical locality of data and reduces the overhead of cross-chip and cross-module data reassembly.

[0079] Signal grouping also considers signal type and transmission period attributes:

[0080] (1) Separation of voltage signal and temperature signal: Since the quantity and accuracy requirements of voltage signal and temperature signal are different, they are usually divided into independent message groups to facilitate differentiated configuration.

[0081] (2) Grouping of signals of the same type: voltage signals and temperature signals are grouped according to board-chip-channel.

[0082] (3) Periodic Consistency Grouping: Grouping signals with the same or similar periods into the same group facilitates the unified configuration of message periods.

[0083] Signal grouping based on physical topology proceeds layer by layer from bottom to top. Signals from the same chip are grouped together first, then signals from the same slave board are grouped together, and finally, they are organized by module until the message size requirement is met. During grouping, the slave board, chip, and module to which the signal belongs, as well as the signal type and transmission period, are comprehensively considered to ensure that signals within the same group are physically related and periodically similar. The channel boundary of the acquisition chip is a crucial constraint for grouping; signals from the same chip are avoided from being split into different messages as much as possible to reduce data reassembly overhead.

[0084] 3) Message Packaging Optimization Algorithm

[0085] The improved First Adaptive Decreasing (FFD) algorithm is used for message packaging optimization. It supports both standard CAN (8-byte DLC) and CAN FD (64-byte DLC) message formats. Under the premise of meeting the constraints of period, priority and functional grouping, it maximizes message payload utilization and improves bus resource utilization efficiency.

[0086] Detailed algorithm flow is as follows Figure 3 As shown. Figure 3 The detailed process of the improved FFD message packaging algorithm is presented, including the specific steps of the preprocessing stage, the core algorithm stage, and the postprocessing stage.

[0087] Unlike the standard FFD algorithm, the improved FFD algorithm of this invention utilizes the structural features of the BMS, using attributes such as battery topology, signal function classification, slave board grouping, and chip channels as pre-grouping criteria and constraints. The algorithm adopts a three-stage structure of "preprocessing - core algorithm - post-processing".

[0088] (1) Pretreatment stage

[0089] First, all signals to be packaged are categorized and sorted. The categorization dimensions include: by slave board (ensuring signals from different slave boards are not mixed), by chip (signals from the same chip are grouped together preferentially), by cycle (signals from the same cycle are packaged preferentially), by priority (signals with the same priority are packaged preferentially), and by signal type (voltage / temperature, etc.). The sorting rule is a multi-level key sorting based on "slave board number → chip number → cycle → priority → signal width in descending order," ensuring that signals in the same group are processed first. Simultaneously, a constraint table is established, including cycle constraints, priority constraints, topology constraints, slave board constraints, chip constraints, and byte alignment constraints. The specific steps are as follows:

[0090] S101. Signal Classification and Organization. All acquired signals are classified into voltage signal groups and temperature signal groups according to their type. The two types of signals are packaged separately and not mixed together.

[0091] S102. Group by slave board. Further group each type of signal according to its slave board. Signals from the same slave board are placed together, and signals from different slave boards are not mixed.

[0092] S103. Grouping by Chip. Within each slave board, signals are further grouped according to the acquisition chip, with signals from the same chip being preferentially grouped together.

[0093] S104. Signal Size Sort. Sort the signals in each chipset from longest to shortest to prepare for subsequent FFD packaging.

[0094] (2) Algorithm execution phase

[0095] An improved FFD strategy is used for packing. The difference from standard FFD is that standard FFD only considers space size, while the improved FFD prioritizes matching packets from the same slave board, chip, cycle, and priority during the search. Only when these packets cannot be accommodated are other packets considered. This ensures both packing efficiency and satisfies various constraints. The specific steps are as follows:

[0096] S105. Processing each slave board sequentially. Pack the signals of each slave board into packets according to their board numbering order.

[0097] S106, Chip-by-chip packaging. Within each slave board, the signal groups of each chip are processed sequentially according to chip order.

[0098] S107, FFD Packaging. For each chip's signal group, an improved FFD algorithm is applied for packing: the largest signal is taken, and attempts are made to put it into existing messages in turn. If it can fit and all constraints are met, it is put in; otherwise, a new message is created.

[0099] S108. Constraint Check. After each signal is sent, it is necessary to check whether all constraints are met, including chip channel constraints, slave board boundary constraints, type consistency constraints, cycle consistency constraints, etc. If not met, rollback and try the next message.

[0100] S109. Overcapacity Splitting Processing. When the signal from a single chip exceeds the capacity of a single message, the signal is split into multiple messages according to the chip channel order to ensure that the channel order is not disrupted.

[0101] (3) Post-processing stage

[0102] Load rebalancing and local optimization are performed. Post-processing further improves packet quality, reduces packet count, and effectively increases packet payload utilization. The specific steps are as follows:

[0103] S110. Message Load Statistics. Statistically analyze the actual load size and utilization rate of each message, identifying messages with excessively high or low loads.

[0104] S111. Load balancing adjustment. Signal migration adjustment is performed on messages with significant load differences, migrating some signals from messages with excessively high loads to messages with lower loads, thereby reducing load differences between messages;

[0105] S112. Message Quantity Optimization. Attempt to merge adjacent messages or reduce the number of messages, minimizing the total number of messages while satisfying all constraints.

[0106] S113. Final Verification. Perform a final constraint verification on all messages to ensure that all messages meet the requirements.

[0107] 4) Hierarchical CAN ID intelligent allocation strategy

[0108] A hierarchical CAN ID allocation strategy is adopted, which divides CAN IDs in an orderly manner according to the hierarchical structure of slave board-type-message sequence number. The first layer allocates continuous ID segments according to slave board to ensure that the message IDs of the same slave board are continuous; the second layer allocates sub-segments according to signal type, with voltage acquisition and temperature acquisition occupying different sub-segments; the third layer assigns sequence numbers to messages in each sub-segment according to the chip order.

[0109] This strategy supports both standard frame (11-bit ID) and extended frame (29-bit ID) formats, allowing for flexible selection based on application scenarios: the standard frame mode is suitable for simple systems and is compatible with traditional CAN buses; the extended frame mode is suitable for complex systems, offering a larger ID space and supporting more slave boards and message types. Both modes employ the same hierarchical allocation rules to ensure consistency in allocation logic.

[0110] The specific rules of the hierarchical CAN ID allocation strategy include:

[0111] The first layer: ID segment partitioning at the board level. Based on the number of slave boards in the system, the entire collected message ID space is evenly divided into several consecutive ID segments, with each slave board assigned an independent ID segment. There is a one-to-one correspondence between the slave board number and the starting address of the ID segment; the smaller the slave board number, the smaller the starting address of the ID segment. The size of each slave board's ID segment is determined based on the maximum number of messages per slave board, with some margin for future expansion. In standard frame mode, when the system supports a maximum of 16 slave boards, each slave board can be allocated an ID segment of 32 consecutive IDs. Slave board 0 occupies 0x200-0x21F, slave board 1 occupies 0x220-0x23F, and so on. In extended frame mode, the slave board number occupies the 3rd byte of the ID; slave board 1 corresponds to the 0x18FF01xx segment, slave board 2 corresponds to the 0x18FF02xx segment, and so on, supporting a maximum of 256 slave boards. Through this board-level partitioning, diagnostic tools can quickly determine the slave board to which a message belongs simply by analyzing the high-order bits of the ID, without needing to parse the message content.

[0112] The second layer: Type-level sub-segment division. Within the ID segment of each slave board, it is further divided into several sub-segments according to signal type. Voltage acquisition messages and temperature acquisition messages occupy different sub-segments, and message IDs of different types do not overlap. The size of the type sub-segment is determined based on the maximum number of messages of that type, with reserved expansion margin. In standard frame mode, the first 16 IDs in the ID segment of each slave board are assigned to voltage acquisition messages, and the last 16 IDs are assigned to temperature acquisition messages; in extended frame mode, voltage acquisition messages are numbered starting from 0x01, temperature acquisition messages starting from 0x11, status messages starting from 0x21, fault messages starting from 0x31, control messages starting from 0x41, and diagnostic messages starting from 0xF1. Through type-level division, the signal type of the message can be directly seen from the ID, facilitating rapid identification and filtering.

[0113] The third layer: Sequence number allocation. Within each type sub-segment, sequence numbers are assigned to messages sequentially according to the order of the acquisition chips. Channel data from the same chip is prioritized in earlier messages, and chips are arranged in chip number order. For example, in the voltage acquisition sub-segment, the 24 channels of chip 0 occupy the first 3 message IDs, the 24 channels of chip 1 occupy the next 3 message IDs, and so on. Sequence number allocation ensures the correspondence between ID numbers and physical chips, facilitating fault location and debugging. The ID number allows for quick identification of the slave board to which the message belongs, the signal type, and the approximate chip location, enabling preliminary fault location and message filtering without parsing the message content.

[0114] In addition to the three-layer basic allocation rules, the hierarchical CAN ID intelligent allocation strategy also includes the following refined rules:

[0115] (a) Priority Mapping Rules: CAN ID priority segments are divided according to the functional importance of the messages. The IDs of data acquisition messages are automatically generated by the tool according to a hierarchical allocation strategy, and priority segments are automatically mapped. The IDs of application messages such as protection, control, status, and diagnostic messages are directly obtained from the input table (application communication matrix table), but the priority segments of their IDs still follow a unified division principle: protection messages (such as fault alarms, overvoltage, and overtemperature) are located in the highest priority ID segment; control command messages are located in the medium-high priority ID segment; data acquisition messages are located in the medium priority ID segment; status information messages are located in the low priority ID segment; and diagnostic messages are located in a separate diagnostic ID segment. Through the above priority mapping rules, it is ensured that critical messages have priority in obtaining transmission rights during bus contention.

[0116] (b) ID Conflict Detection Mechanism: ID conflicts are detected in real time during the allocation process, including conflicts between acquisition messages and conflicts between acquisition messages and application messages. When a conflict is detected, the ID allocation scheme is automatically adjusted, migrating the conflicting message IDs to an available ID segment. Conflict detection covers the entire ID space, ensuring the uniqueness of all message IDs.

[0117] (c) Expansion Reservation Mechanism: Each level of ID allocation reserves a certain amount of expansion space, supporting the addition of slave boards, chips, and channels without the need to reallocate existing IDs. The expansion reservation ratio is usually 20%-30%, which can be flexibly adjusted according to the scalability requirements of the project.

[0118] (d) ID naming mapping table: Automatically generates a mapping table between CAN ID and signal name, including ID value, message name, signal list, slave board number, chip number, channel range and other information.

[0119] (e) Vehicle Model Adaptation Rules: Different vehicle models have different numbers of slave boards and chip configurations, and the ID allocation scheme is automatically adapted. When switching vehicle models, the system automatically recalculates the ID segment size of each layer based on the topology parameters of that vehicle model to maintain the consistency of the allocation rules.

[0120] 5) PDU signal layout optimization algorithm

[0121] Optimize the start bit arrangement of the signal in the PDU data field to improve data payload utilization. Detailed algorithm flow is as follows: Figure 4 As shown. Figure 4 The complete flowchart of the signal placement optimization algorithm is presented. Starting from the input signal list, it goes through sorting, initialization, cyclic placement, boundary filling, and verification, finally outputting the optimized placement scheme. The placement optimization adopts a multi-rule constraint strategy to find the optimal signal arrangement scheme under various constraints.

[0122] The specific algorithm flow is as follows:

[0123] S201. Input the list of signals to be laid out and the constraints to provide basic data for subsequent layout optimization. Constraints include byte alignment constraints, clustering of similar types, chip channel order alignment, and signal group continuity.

[0124] S202. Signal sorting. Arrange signals in descending order of bit width, following the principle of prioritizing larger signals. Larger signals are placed first because they are more difficult to locate in suitable positions; amplifying signals first reduces fragmented space.

[0125] S203. Initialize the PDU data field space marker, marking all bits as available. Standard CAN uses 8 bytes, while CANFD uses 64 bytes.

[0126] S204. Enter the loop processing and determine if there are any unplaced signals. If there are still unplaced signals, continue processing; if all signals have been placed, exit the loop and enter the boundary filling optimization stage.

[0127] S205. If there are still unplaced signals, retrieve the signal with the current maximum bit width and process it.

[0128] S206. Find the optimal starting bit that satisfies the constraints. The search process must satisfy multiple constraints: byte alignment requirements (if the signal requires byte alignment, the starting bit must be an integer multiple of the byte boundary), similar signal concentration requirements (if there are similar signals nearby, prioritize the nearby location), chip channel sequence alignment (signals on the same chip channel should be arranged as continuously as possible for easier data processing), and signal groups should remain continuous (functionally related signal groups should be placed together as much as possible).

[0129] S207. Determine if a suitable position has been found. If a suitable position that satisfies all constraints has been found, continue placing the signal; if no suitable position has been found, it means that the current PDU space is insufficient and a new PDU needs to be created.

[0130] S208. If no suitable position is found, it means there is insufficient space. Create a new PDU, and then return to the step of finding the best starting position to find a suitable position again in the new PDU.

[0131] S209. If a suitable position is found, place the signal at that starting position.

[0132] S210. Update the PDU space flag, marking the bit occupied by the signal as used.

[0133] S211. Return to the loop condition and continue processing the next signal. Repeat the above steps until all signals have been placed.

[0134] S212. After all signals have been placed, perform boundary filling optimization. Utilize the remaining fragmented space in the PDU data field to place small signals such as Boolean and state signals, further improving space utilization.

[0135] S213. Perform layout result verification, check whether all constraints are met, ensure that all signals are correctly placed without overlap or out of bounds, and that all constraints are met.

[0136] S214. Output the optimized signal layout scheme.

[0137] After layout optimization, further optimization can be achieved by adjusting signal positions. Adjustment methods include: swapping the positions of two signals, inserting a signal into another position, or moving a group of signals to a different location. Through continuous trial and comparison, the arrangement scheme with the highest utilization rate can be found.

[0138] 2. Signal-level fine-grained configuration generation

[0139] The core of the signal-level fine-grained configuration generation mechanism is to achieve automatic mapping from BMS signal definition to AUTOSAR Com module configuration. This mechanism unifies the processing of two types of signals: automatically generated acquisition signals from different sources and user-input application signals. It automatically generates complete configuration parameters conforming to the AUTOSAR standard according to preset mapping rules, eliminating the need for manual configuration. It comprises two parts: automatic ComSignal configuration generation and notification callback configuration generation.

[0140] (1) ComSignal configuration is automatically generated

[0141] ComSignal configuration data comes from two sources: one is automatically generated acquisition signals (individual cell voltage, individual cell temperature, etc.) by the system, and the other is application signals (SOC, SOH, fault alarms, control commands, etc.) entered by the user through an Excel spreadsheet. Although the two types of signals come from different sources, they are automatically converted into AUTOSAR standard ComSignal configuration parameters according to a unified mapping rule, eliminating the need for manual configuration.

[0142] ComSignal configurations are automatically generated item by item, each with its own defined generation rules. For acquisition-type signals and application-type signals, most configuration items follow the same generation rules, while some use differentiated processing methods based on the characteristics of the two signal types. The specific configuration items and generation rules are as follows:

[0143] (a) Signal Name Configuration: Acquisition signals are generated according to the naming rule "<signal prefix>_slave board number_chip number_channel number". The signal prefix is ​​read from the "Associated Signal" field of the function configuration table (e.g., the associated signal for voltage acquisition is CellVoltage_*, and the associated signal for temperature acquisition is CellTemp_*, taking the part before the wildcard as the prefix). For example, the voltage signal of the first channel of the first chip on the first slave board is named CellVoltage_Slave01_Chip01_Ch01, and the temperature signal of the first channel of the first chip on the first slave board is named CellTemp_Slave01_Chip01_Ch01. The naming rule ensures that the physical location and type of the signal can be directly identified from the signal name, facilitating debugging and problem localization. The names of application-type signals are directly obtained from the user-defined signal names in the Excel input table, such as BMS_SOC, BMS_MaxCellVoltage, etc.

[0144] (b) Signal Length and Data Type Configuration: The signal acquisition type is determined based on the acquisition chip model. For example, when using the LTC6813 chip, the voltage acquisition signal is a 16-bit unsigned integer (corresponding to the chip's 16-bit ADC sampling accuracy), and the temperature acquisition signal is a 16-bit signed integer (corresponding to the NTC sensor resolution). The length and data type of the application type signal are directly read from the Excel input table, supporting standard AUTOSAR data types such as uint8, uint16, uint32, sint8, sint16, sint32, float32, and boolean.

[0145] (c) Byte Order Configuration: Byte order configuration information is read from the Excel configuration table. The byte order of application signals is read from the "Byte Order" field in the "Signal Definition Table," and each signal can be configured individually. The byte order of acquisition signals is read from the global byte order configuration item in the "Battery Topology Configuration Table," and acquisition signals of the same battery pack use a unified byte order. Both big-endian (Motorola format) and little-endian (Intel format) modes are supported. Big-endian mode is used by default when not specified by the user (compliant with general automotive electronics industry standards). The configuration generation tool automatically adjusts the arrangement of signals in the message based on the read byte order information to ensure communication compatibility between different ECU nodes.

[0146] (d) Initial and Invalid Value Configuration: The initial and invalid values ​​for acquired signals are determined according to the signal type. For 16-bit unsigned voltage signals, both the initial and invalid values ​​are 0xFFFF (65535). For 16-bit signed temperature signals, both the initial and invalid values ​​are 0x8000 (-32768). This ensures that if no valid data is acquired during the power-on initialization phase, the upper-layer application can identify the invalid data state. The initial and invalid values ​​for application-type signals are preferentially read from an Excel input table. If not specified by the user, the maximum value is used as the invalid value for uint types, the minimum value for sint types, and NaN for float types.

[0147] (e) Timeout Monitoring Configuration: The timeout period is configured as a multiple of the signal transmission cycle. The timeout factor for protection signals is 2 times the transmission cycle, for control signals it is 3 times the transmission cycle, for status signals it is 3 times the transmission cycle, for acquisition signals it is 5 times the transmission cycle, and for diagnostic signals it is 10 times the transmission cycle. The timeout handling action is uniformly configured as "replace with invalid value," meaning that after a signal times out, the signal value is automatically replaced with the corresponding invalid value, and a timeout notification callback is triggered simultaneously.

[0148] (f) Transmission Period Configuration: The basic transmission period is configured according to signal function: 100ms for protection signals, 200ms for control signals, 500ms for status monitoring signals, 1000ms for data acquisition signals, and 2000ms for diagnostic information signals. Acquisition signals also support two special configurations: first, the transmission period is an integer multiple of the acquisition chip's sampling period to avoid data duplication or omission; second, all acquisition signals within the same message use the same transmission period to simplify message scheduling. The transmission period for application signals is preferentially read from an Excel input table; if not specified by the user, the corresponding period is configured according to the function category.

[0149] (g) Event-triggered transmission configuration: For status-based and event-based application signal transmission, event-triggered transmission mode is supported. Configuration parameters include a change threshold and a minimum transmission interval. The change threshold can be configured as a percentage or absolute value of the signal range. For example, the SOC signal change threshold can be set to 1% of the range (or an equivalent absolute value). The minimum transmission interval is a configurable parameter used to prevent frequent transmissions caused by signal jitter near critical values. Application signal transmission can be configured as a hybrid transmission mode of "periodic + event," where periodic transmission ensures timely data updates, and event triggering ensures real-time status changes. Acquisition-type signals are received, and their update cycle is determined by the transmission cycle of the slave board's acquisition messages; no transmission mode is configured on the mainboard side.

[0150] The configuration generation process also includes a consistency check of signal attributes to ensure that parameters such as the physical value range, resolution, and offset of the signal are consistent with the application layer definitions. Different vehicle models can adjust the signal classification and configuration parameters according to functional requirements.

[0151] (2) Notification callback configuration generation

[0152] Notification callback configurations are automatically generated item by item, with each item having a defined generation rule. Notification callback configurations include two categories: PDU-level notifications and signal-level notifications. Acquisition-type signals and application-type signals use a unified configuration framework, with differentiated triggering strategies based on signal type and purpose. Specific configuration items and generation rules are as follows:

[0153] (a) PDU Sending Completion Notification Configuration: Each I-PDU in each sending direction is configured with a sending completion notification callback to confirm successful message transmission. The callback function name is automatically generated based on the message name, following the naming convention of "Message Name_TxConfirmation". Both collection and application messages use the same naming convention. The triggering time for the sending completion notification is uniformly configured as "triggered after successful message transmission", used by the upper layer to statistically analyze the sending success rate and diagnose sending failures.

[0154] (b) PDU Reception Completion Notification Configuration: Each I-PDU in the receiving direction is configured with a reception completion notification callback to notify the upper layer that message reception is complete. The callback function name is automatically generated based on the message name, following the naming rule "Message Name_RxIndication". Both acquisition-type and application-type messages use the same naming rule. The triggering timing of the reception completion notification is configured differently based on the message type: acquisition-type messages use a "trigger on every reception" strategy, facilitating batch data processing by the acquisition management module; application-type messages are configured based on signal importance, with important messages triggering on every reception, while ordinary messages can be configured to trigger after a timeout.

[0155] (c) Signal Timeout Notification Configuration: Each signal is configured with a timeout notification callback to monitor signal reception status. The callback function name is automatically generated based on the signal name, following the naming convention of "signal name_TimeoutNotification". The triggering strategy for timeout notifications is configured according to the signal function category: protection signals adopt the "trigger immediately upon timeout" strategy to ensure that fault information is processed in a timely manner; status signals and acquisition signals adopt the "replace with invalid value upon timeout + trigger notification" strategy, which is normally read periodically by the application layer, and a notification is triggered only after the timeout; event signals adopt the "do not trigger upon timeout" strategy, and are triggered only when the event occurs.

[0156] (d) Notification Callback Function Naming Rules: All notification callback functions are automatically generated according to a unified naming rule to ensure consistent naming, ease of searching, and maintenance. The suffix for a send completion notification is _TxConfirmation, the suffix for a receive completion notification is _RxIndication, the suffix for a timeout notification is _TimeoutNotification, and the suffix for an error notification is _ErrorNotification. Function names are uniformly prefixed with either the message name or the signal name to ensure that the corresponding message or signal can be identified from the function name.

[0157] (5) Notification merging optimization configuration: For multiple signals within the same message, notification merging optimization is supported to reduce the number of notifications and context switching overhead. Acquisition signals are enabled by default. All acquisition signals in the same message are merged into one PDU-level reception notification, which is triggered uniformly after the message reception is completed, greatly reducing the number of notifications. Application signals are judged based on the signal receiver. If the receivers of multiple signals are the same software module and the processing time is similar, they are automatically merged into one notification; otherwise, independent notifications are retained.

[0158] 3. Router configuration is automatically generated.

[0159] The core of the automatic route configuration generation mechanism is to achieve automatic mapping from the route rule configuration table to the AUTOSAR PduR module configuration. Based on the user-input route rule table, this mechanism automatically generates a complete route configuration for the PduR layer, including source Pdu configuration, destination Pdu configuration, route type, triggering method, etc., without requiring manual configuration of each element.

[0160] The routing configuration data comes from the "Route Rules Table" in an Excel spreadsheet. This table defines information such as the source packet, destination packet, route type, trigger method, and activation conditions for each route. The configuration generation tool automatically generates the corresponding PduR route configuration items based on each record in the Route Rules Table. The route configuration is automatically generated item by item, and each configuration item has a clear generation rule.

[0161] (1) Source Pdu Configuration: Based on the "Source Message ID" field in the routing rule table, the source Pdu is automatically associated with the generated CanIf layer or COM layer Pdu configuration. For acquisition message routing, the source Pdu is the CanIf layer receive Pdu (acquisition message received from the CAN bus); for application message routing, the source Pdu is the COM layer send Pdu (message sent by the application layer). The name of the source Pdu is automatically generated based on the message name, and the naming rule is "message name_SrcPdu".

[0162] (2) Target Pdu Configuration: Based on the "Target Message ID" field in the routing rule table, the corresponding target layer Pdu configuration is automatically associated. For acquisition message routing, the target Pdu is the COM layer receive Pdu (acquisition messages uploaded to the application layer); for application message routing, the target Pdu is the CANIf layer send Pdu (application messages sent to the CAN bus). The name of the target Pdu is automatically generated based on the message name, and the naming rule is "Message Name_DestPdu".

[0163] (3) Route type configuration: Automatically configured according to the "Route type" field in the routing rule table. This scheme adopts one-to-one routing (one source Pdu corresponds to one destination Pdu), that is, the route for collection packets is CanIf receiving Pdu → Com receiving Pdu, the route for application packets (TX) is Com sending Pdu → CanIf sending Pdu, and the route for application packets (RX) is CanIf receiving Pdu → Com receiving Pdu. One-to-one routing is suitable for routing scenarios within the BMS motherboard's internal communication stack and does not involve cross-bus gateway forwarding.

[0164] (4) Triggering method configuration: Automatically configured according to the "Triggering method" field in the routing rule table. Supported triggering methods include: direct forwarding (forwarding to the target Pdu immediately after the source Pdu is received), periodic forwarding (forwarding at regular intervals according to the configured period), and event triggering (forwarding only when specific conditions are met). The default method for collecting packets is direct forwarding to ensure the real-time performance of the collected data; the triggering method for application packets is selected according to the packet type, with direct forwarding for control packets and periodic forwarding for status packets.

[0165] (5) Routing path configuration: The routing path is automatically determined based on the communication direction of the message. The routing path for the acquisition message is "CanIf receive → PduR → Com receive", the routing path for the application message TX route (sending messages such as status, protection, and diagnostic messages) is "Com send → PduR → CanIf send", and the routing path for the application message RX route (receiving messages such as control and diagnostic messages) is "CanIf receive → PduR → Com receive". In this scheme, CAN0 is the internal CAN (connected to the slave board, transmitting acquisition messages), and CAN1 is the external CAN (connected to the vehicle controller, transmitting application messages), and does not involve cross-bus gateway forwarding scenarios.

[0166] (6) Enable Condition Configuration: Automatically configured according to the "Enable Condition" field in the routing rule table. Supported enable conditions include: Always Enabled and Conditional Enabled (whether to enable depends on a specific signal value or system status). The default configuration is Always Enabled, which is suitable for regular communication scenarios; for routes that require dynamic switching (such as switching between charging mode and driving mode), the configuration is Conditional Enabled.

[0167] The configuration generation process also includes a consistency check of the routing configuration to ensure that both the source and destination PDUs exist, the routing path is complete, and the triggering method matches the message type. Routing rules are adjusted for different vehicle models based on their bus topology and communication requirements.

[0168] 4. CanIf configuration is automatically generated.

[0169] The data for the CanIf configuration comes from three sources: first, the acquisition message configuration (message ID, period, length, priority, etc.) automatically generated by the intelligent message allocation algorithm; second, the application message configuration defined in the "Application Communication Matrix Table" of the Excel input spreadsheet; and third, the CAN hardware configuration parameters (baud rate for each channel, number of Tx mailboxes, number of Rx mailboxes, filtering mode, CAN FD support, etc.) from the vehicle platform configuration table. The configuration generation tool automatically generates the corresponding CanIf configuration items based on the message configuration information and hardware resource parameters. The CanIf configuration is automatically generated item by item, and each configuration item has a clear generation rule.

[0170] (1) CAN controller configuration: The CAN controller configuration is automatically generated based on the CAN hardware parameters in the vehicle platform configuration table. The configuration content includes: the number of CAN channels is read from the "CAN Channel Count" field; the baud rate of each channel is read from the "CAN0 Baud Rate", "CAN1 Baud Rate", etc., the standard CAN defaults to 500kbps, the baud rate of the arbitration segment of the CAN FD message is consistent with the standard CAN, and the baud rate of the data segment is read from the "CAN FD Data Segment Baud Rate" field; the sampling points are automatically calculated based on the baud rate and MCU clock, and the default configuration is 80% sampling points; the clock source is automatically selected based on the MCU model.

[0171] (2) Tx Pdu Configuration: For messages sent in the transmission direction, a CanIf Tx Pdu configuration is automatically generated. The configuration includes: the Pdu name is automatically generated based on the message name, with the naming rule being "message name_TxPdu"; the Pdu length is automatically configured based on the message data length; the message ID is directly read from the message configuration; the CAN channel is automatically mapped according to the message type (acquisition messages are mapped to CAN0, i.e., internal CAN, used to connect to the slave board to transmit acquisition signals; application messages are mapped to CAN1, i.e., external CAN, used to connect to the vehicle controller to transmit status, protection, control, diagnostic, and other application messages); the sending mailbox is obtained from the "Tx mailbox number" field of the vehicle platform configuration table, and then allocated according to message priority. Protection and control messages are given priority in being allocated dedicated mailboxes, while status and acquisition messages share mailboxes. The Tx Pdu configuration for acquisition messages and application messages adopts a unified generation rule, and whether to generate a Tx Pdu is determined based on the communication direction of the message.

[0172] (3) Rx Pdu Configuration: For messages in the receiving direction, a CANIf Rx Pdu configuration is automatically generated. The configuration includes: the Pdu name is automatically generated based on the message name, with the naming rule being "message name_RxPdu"; the Pdu length is automatically configured based on the message data length; the message ID is directly read from the message configuration; the CAN channel is automatically mapped according to the message type (collection messages are mapped to CAN0, application messages are mapped to CAN1); the receiving mailbox is obtained from the "Rx mailbox number" field of the vehicle platform configuration table, and then allocated according to the message ID range, supporting both basic mailbox and full-function mailbox modes. Collection messages are in the receiving direction (sent from the slave board to the main board via internal CAN), and application messages are determined to be sent or received based on the communication direction.

[0173] (4) Hardware Object (Hoh) Configuration: Hardware objects are automatically allocated based on the CAN hardware resource parameters and message quantity in the vehicle platform configuration table. The total number of sending hardware objects (HTH) is read from the "Tx mailbox count" field and allocated according to priority: protection and control messages are allocated dedicated HTHs, while status and acquisition messages share HTHs; the total number of receiving hardware objects (HRH) is read from the "Rx mailbox count" field and allocated according to message ID range, supporting both list filtering and range filtering modes. The mailbox type (basic mailbox / full-function mailbox) is automatically determined based on the MCU model and message type. Full-function mailboxes are used for messages requiring complex filtering, while basic mailboxes are used for messages with simple ID filtering.

[0174] (5) Callback Function Configuration: The callback functions of the CanIf layer are automatically configured according to the communication direction and function type of the message. The send completion callback (TxConfirmation) is used to confirm that the message was sent successfully. The function name is automatically generated according to the message name, and the naming rule is "message name_TxConfirmation". The receive indication callback (RxIndication) is used to notify the upper layer that the message has been received. The function name is automatically generated according to the message name, and the naming rule is "message name_RxIndication". The receive callback of the acquisition message triggers PduR routing, and the receive callback of the application message triggers COM layer signal processing.

[0175] (6) Message ID Filtering Configuration: For messages received, message ID filtering is automatically configured based on the "Filtering Mode" field of the vehicle platform configuration table. When the filtering mode is "Hardware Filtering", a hardware ID filtering table is configured to receive only messages within the configured range. The ID range of the collected messages is continuously allocated according to the slave board, and the range filtering is configured. The IDs of the application messages are allocated according to the function category, and the list filtering is configured. When the filtering mode is "Software Filtering", a software filtering callback function is configured to determine whether the message ID matches in the callback. The filtering of CAN FD messages also needs to consider the configuration of the FD flag bit.

[0176] During the configuration generation process, a consistency check of the CAN If configuration is also performed to ensure that the correspondence between Tx / Rx Pdu and hardware objects is correct, that mailbox resources do not conflict, that message IDs are not duplicated, and that callback function names are unique. Different vehicle models adjust the hardware object allocation strategy based on the MCU model and the number of CAN channels.

[0177] III. Output Configuration Layer: Multi-format Output Configuration

[0178] The configuration output layer is responsible for converting the internally represented configuration into different output formats to adapt to different development toolchains and application scenarios. For example... Figure 5 As shown, the configuration output layer adopts a technical solution of "unified core model + pluggable format converter + step-by-step conversion process" to realize the one-time generation of configuration data and multi-format output. Figure 5 The complete technical process of the configuration output layer is presented, starting from the input of the core configuration model, through format converter selection, multi-step conversion processing, quality verification, file generation, and finally outputting a multi-format configuration file set.

[0179] The entire process is driven by a unified core configuration model, supporting multiple formats through a pluggable format converter. The step-by-step conversion process ensures decoupling and maintainability. The configuration output layer supports exporting configuration files separately for each vehicle model, generating independent configuration files for easy integration and management. The output content includes both automatically generated acquisition class configurations and user-defined application class configurations, forming a complete communication configuration. The specific method for configuration output is as follows:

[0180] 1. Format Converter Selection and Loading Mechanism

[0181] Based on output format requirements, the corresponding format converter is dynamically selected and loaded. A pluggable architecture is adopted, with each output format corresponding to an independent converter module. Converters are independent of each other; adding a new output format only requires developing a new converter module, without modifying the core generation engine. The converter interface definition includes three core parts: an input interface, responsible for receiving a unified core configuration model; a conversion processing interface, responsible for executing specific format conversion logic; and an output interface, responsible for generating the final output file. All converters adhere to a unified interface specification, ensuring complete decoupling between the core engine and the converters.

[0182] 2. Metamodel Mapping

[0183] The core configuration model elements are mapped to the target format metamodel, completing the semantic-level transformation. This step is responsible for converting the unified internal representation into the target format semantic model, ensuring the semantic correctness of the transformation process. Metamodel mapping includes three core steps: 1. Model element mapping: Mapping configuration elements in the core model (such as signals, messages, routing paths, mode management, etc.) to the corresponding metamodel elements in the target format, establishing the correspondence between elements; 2. Reference relationship conversion: Converting the element reference relationships in the core model into the reference methods of the target format, ensuring the integrity and correctness of the reference relationships, and avoiding dangling references or reference errors; 3. Namespace adaptation: Adjusting the namespace and naming method of elements according to the naming conventions and namespace requirements of the target format to ensure compliance with the requirements of the target format.

[0184] 3. Structural transformation

[0185] The semantic model is converted into a specific structure in the target format, completing the structural transformation. This step is responsible for organizing the semantic model into a specific file structure and configuration hierarchy in the target format. The structural transformation includes three core steps: 1. Module / File Structure Organization: Based on the specifications and best practices of the target format, configuration elements are organized into corresponding module and file structures, determining the file division and organization methods; 2. Configuration Item Hierarchy Mapping: Configuration items in the core model are mapped and organized according to the hierarchical requirements of the target format, adjusting the hierarchical and containment relationships between configuration items; 3. Data Type Conversion: Data types in the core model are converted to data types supported by the target format, handling attributes such as default values, value ranges, and constraints.

[0186] 4. Format-specific optimization

[0187] Format-specific optimizations are performed based on the target format's unique rules and best practices. This step is responsible for format-level optimization and adaptation, improving output quality and tool compatibility. Format-specific optimization includes three core aspects: 1. Application of format-specific rules: Applying the target format's unique rules and constraints to ensure the output fully conforms to the format specifications and meets the strict requirements of the tools; 2. Compatibility handling: Addressing compatibility issues between different tool versions, adapting to the characteristics of different tools, and ensuring that the output file can be correctly recognized and imported by mainstream tools; 3. Performance optimization and readability enhancement: Optimizing file structure and element arrangement to improve tool loading speed and processing efficiency; at the same time, enhancing file readability to facilitate manual review and debugging.

[0188] 5. Output quality verification

[0189] Multi-dimensional quality checks are performed on the converted configuration to ensure the correctness and completeness of the output. Quality checks are a crucial step in the configuration output process, identifying quality issues during the generation phase and preventing them from flowing into subsequent development stages. Output quality checks include three core dimensions: Syntax checks: verifying that the syntax of the output file conforms to the target format specifications, ensuring that the file can be correctly parsed by the tool without syntax errors; Completeness checks: verifying that all configuration items have been correctly converted without omissions or losses, ensuring the integrity of the configuration; Consistency checks: verifying the consistency between the output results and the core configuration model, ensuring that no errors were introduced during the conversion process and that the output results are consistent with the input model.

[0190] 6. Document Generation and Organization

[0191] The validated configuration is used to generate the final output file, and the file structure is organized according to specifications. This is the final step in the configuration output process, responsible for delivering the conversion result to the user in a standardized format. File generation and organization includes three core components: Module / Bus-based file splitting: Based on best practices for the target format, the configuration is split into multiple files according to modules, buses, etc., facilitating management and maintenance and supporting collaborative team development; Directory structure generation: A standardized directory structure is generated, organizing different types of files into their corresponding directories to maintain a clear file organization structure; Version information injection: Version information, generation time, configuration parameters, and other metadata are injected into the output file for easy configuration traceability and version management.

[0192] The configuration output includes two formal configuration output formats and one auxiliary review output, each corresponding to different development scenarios:

[0193] (a) ARXML Configuration Output: Generates a standard AUTOSAR XML (ARXML) configuration file containing complete configuration information for modules such as CanIf, PduR, and Com. The configuration content covers both automatically generated acquisition-type messages and signals, as well as user-defined application-type messages and signals. ARXML is the standard configuration exchange format for AUTOSAR, compatible with mainstream AUTOSAR configuration tools (such as Vector DaVinci Configurator, EB tresos, etc.). The generated ARXML file can be directly imported into these tools for subsequent development and integration, suitable for development workflows using third-party AUTOSAR configuration tools. ARXML configuration output uses a template-based generation method, with predefined ARXML templates for each module. During generation, the data from the internal configuration model is populated into the templates to generate an ARXML file conforming to the AUTOSAR standard. ARXML validity is also checked during the output process to ensure that the generated file conforms to XML syntax specifications and AUTOSAR schema definitions. It supports splitting output by module and merging into a single file to meet the import requirements of different tools.

[0194] (b) C Code Configuration Output: Generates compilable C code configuration, including configuration structures, macro definitions, callback function declarations, and constant definitions for modules such as CanIf, PduR, and Com. The generated code conforms to the AUTOSAR standard and coding conventions and can be directly integrated into the BMS project for compilation and use. The C code configuration output uses a code generation engine to automatically generate the corresponding C code based on the internal configuration model. The generated code follows the MISRA C coding conventions to ensure code security and maintainability. The code also includes detailed comments explaining the meaning and origin of each configuration item, facilitating subsequent maintenance and debugging. Static code analysis is also performed during the code generation process to ensure that the generated code is free of syntax errors and potential problems.

[0195] (c) Acquisition Signal Verification Excel Output (Auxiliary Verification Output): Exports the automatically generated acquisition signals (individual unit voltage, individual unit temperature) and message allocation results into a multi-sheet Excel file, allowing engineers to quickly verify the correctness of the acquired signal generation results. The exported content includes: a complete list of voltage signals and a complete list of temperature signals (each containing complete attributes such as signal name, associated message, message ID, corresponding slave board / chip / channel, start bit, length, data type, byte order, resolution, offset, initial value, invalid value, and value range); the layout of voltage and temperature message signals for each slave board; and summary statistics of messages (message ID, number of signals, data length, load utilization, etc.). This output is for auxiliary verification purposes, allowing engineers to visually check signal naming rules, message packaging rationality, and ID allocation correctness. It does not affect the formal configuration output of ARXML and C code.

[0196] IV. Configure a quality verification system

[0197] Configuration quality verification is not a standalone layer, but rather a cross-layered assurance mechanism that runs throughout the entire configuration generation process. It performs consistency checks at each stage, including input, generation, and output, to identify potential problems early. (See attached image) Figure 6 The design principles of the quality verification system are: elevating quality verification from simple syntax checking to semantic verification; advancing the verification timing from the integration testing phase to the configuration generation phase; and expanding the verification content from a single dimension to multi-dimensional comprehensive verification. Through automated and intelligent quality verification, configuration quality is significantly improved, reducing rework costs later. Quality verification supports independent verification of the configuration for each vehicle model, ensuring that the configurations of each model meet quality requirements. The specific verification process is as follows:

[0198] S301. Input the configuration data to be verified, including all relevant configuration information such as the generated communication configuration, routing configuration, and mode management configuration, to provide basic data for subsequent verification.

[0199] S302. Perform basic syntax validation. Basic syntax validation is the first line of defense, primarily checking the correctness and completeness of the basic configuration syntax. Basic syntax validation includes two core validation items: Naming convention validation: ensuring that all configuration elements are named in accordance with conventions for easy maintenance. The validation method is to check whether the name of each configuration element conforms to naming rules (prefix, suffix, character set, etc.), is meaningful, and is unique; Configuration completeness validation: ensuring that all necessary configuration items are configured to avoid omissions. The validation method is to check whether the required configuration items for each module are filled in, whether there are default values, and whether there are empty configurations.

[0200] S303. Determine if the syntax check passes. If the syntax check fails, it indicates that there are basic syntax errors or omissions in the configuration, which need to be corrected; if the syntax check passes, proceed to a deeper semantic check.

[0201] S304. If the syntax check fails, record the syntax error information, generate a detailed check report indicating the specific error location and type, and then return to correct the configuration. After correction, re-enter the configuration data to be verified and perform verification again, forming a closed-loop verification mechanism.

[0202] S305. If the syntax check passes, proceed to the semantic check. Semantic check is the second layer of verification, utilizing BMS structural features for deep logical verification to check the correctness and consistency of the configuration at the semantic level. Semantic check includes seven core verification items: ID uniqueness check: Ensures all message IDs are unique on the same bus, avoiding communication errors caused by ID conflicts. The verification method is: traverse all message IDs, establish an ID set, and check for duplicates; simultaneously check if the IDs are within the legal range and conform to the hierarchical ID allocation rules; Signal integrity check: Ensures all defined signals have corresponding message and routing configurations, avoiding signal loss. The verification method is: traverse all signal definitions, checking if each signal has a corresponding ComSignal configuration, is mapped to a PDU, and has a corresponding routing path; Routing connectivity check: Ensures all routing paths are connected, avoiding routing breaks. The verification method is: traverse the routing path from the source node to the destination node, checking if each hop has a corresponding routing configuration, ensuring complete path connectivity; Cross-module consistency check: Ensures that the configurations between different modules are consistent, avoiding configuration conflicts between modules. The verification methods are as follows: 1. Check if the reference relationships between modules such as CanIf, PduR, and Com are consistent, and whether PDU IDs and signal IDs are consistent across modules. 2. Signal integrity verification: Using battery topology knowledge, verify that all cell voltage, temperature, and other acquired signals are fully configured without omissions. The verification method is to calculate the required number of acquired signals based on battery topology parameters (number of strings, number of modules, number of slave boards, number of temperature sensors, etc.) and compare it with the actual number of generated signals to check for omissions. 3. Topology consistency verification: Verify that signal grouping and message allocation are consistent with the battery topology structure. The verification method is to check whether signals from the same module are in the same group, and whether signals from the same slave board are in the same message ID segment, and whether they conform to the topology grouping rules. 4. Naming convention compliance verification: Verify that the naming of signal names, message names, PDU names, callback function names, etc., conforms to the preset naming conventions to avoid configuration reference errors caused by inconsistent naming. The verification method is as follows: check whether the name of the acquired signal conforms to the naming rule of "signal prefix_slave board number_chip number_channel number", check whether the message name, PDU name, callback function name, etc. conform to the unified naming standard, and check whether the names are completely consistent when referencing the same object among different modules.

[0203] S306. Determine if the semantic validation passes. If the semantic validation fails, it indicates that there are deep logical errors or inconsistencies in the configuration, which need to be corrected; if the semantic validation passes, it indicates that the configuration quality is acceptable.

[0204] S307. If semantic validation fails, record the semantic error information, generate a detailed validation report indicating the specific error location, error type, and correction suggestions, and then return to correct the configuration. After correction, re-enter the configuration data to be validated and perform validation again, forming a closed-loop validation mechanism.

[0205] S308. If the semantic validation passes, the configuration validation passes, and the quality is qualified.

[0206] S309. Output the verified configuration for use in subsequent development processes.

[0207] Compared with the prior art, the present invention has the following beneficial effects:

[0208] (1) Improved configuration generation efficiency and quality, and significantly shortened development cycle.

[0209] This invention achieves fully automated generation of BMS communication configurations, reducing the workload of traditional manual configuration (which can take several days) to minutes. Acquisition signals no longer need to be manually defined one by one; the tool automatically generates a complete list of acquisition signals based on battery topology parameters. Message allocation, signal layout, and periodic configuration are all automatically optimized by algorithms. Configurations for each layer (Com, PduR, CanIf) are automatically generated item by item, eliminating the need for manual configuration. Multiple output formats are generated at once, eliminating the need for repeated conversions between different tools. Cross-module consistency checks are also performed during configuration generation to ensure the correct correspondence between configuration layers, avoiding omissions and errors that are prone to occur during manual configuration.

[0210] (2) Deep optimization of BMS scenarios significantly improves bus performance and communication efficiency.

[0211] Deep optimization was performed to address the structural characteristics of the BMS, which involves a large number of signals and strong regularity. A message allocation algorithm based on battery topology driving and acquisition chip constraints ensures physical locality of data and chip boundary alignment, reducing the overhead of cross-chip and cross-module data reassembly. Fine-grained signal-level configuration extends the configuration granularity from the message level to the signal level, automatically generating ComSignal and notification callback configurations item by item, achieving fully automated signal configuration generation. Automatic generation of routing and interface configurations ensures the consistency and integrity of configurations at the Com, PduR, and CanIf layers, avoiding errors from manual cross-module configuration adjustments.

[0212] (3) Multi-model platform reuse, enhanced adaptability to all scenarios

[0213] This invention achieves rapid adaptation across multiple vehicle models and platforms by using a separate Excel configuration table for each vehicle model. Each model maintains a complete Excel configuration table, with configuration parameters managed independently and without interference, including battery topology, acquisition chip models, temperature sensor distribution, etc. Adding a new model only requires modifying the topology parameters in the Excel table; the system automatically generates all acquisition signal configurations, eliminating the need to manually define hundreds of acquisition signals. It also supports dual-format output of ARXML and C code, adapting to different development toolchains and application scenarios, significantly enhancing its all-scenario adaptability.

[0214] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for automatically generating communication parameters and routes for a BMS, characterized in that, include: The scattered configuration input information of BMS is integrated into a structured multi-dimensional configuration input, including the definition of the physical topology of the battery pack for each vehicle model; The communication configuration is generated based on structured multi-dimensional configuration input, including: using the intelligent allocation algorithm of the collected messages to automatically generate different message allocation results for different vehicle models according to their topology parameters, and uniformly processing the collected signals from different sources and the application signals input by the user, and automatically generating complete configuration parameters that conform to the AUTOSAR standard according to the mapping rules. The generated communication configuration is converted into different output formats to adapt to different development toolchains and application scenarios.

2. The method for automatically generating communication parameters and routes for BMS according to claim 1, characterized in that, The process of integrating the scattered configuration input information of the BMS into a structured multi-dimensional configuration input includes adopting a multi-worksheet structure, with each dimension of configuration input maintaining one worksheet, in order to integrate the scattered configuration input information into structured configuration input information.

3. The method for automatically generating communication parameters and routes for BMS according to claim 2, characterized in that, The multi-dimensional configuration inputs include vehicle platform configuration dimension, battery topology configuration dimension, application communication matrix configuration dimension, function configuration matrix dimension, routing rule configuration dimension, and quality constraint configuration dimension.

4. The method for automatically generating communication parameters and routes for BMS according to claim 1, characterized in that, The method of using a smart message allocation algorithm to automatically generate different message allocation results for different vehicle models based on their topology parameters includes the following steps: Based on battery topology parameters, acquisition chip parameters, and signal naming rule templates, a complete list of acquired signals is automatically generated. The acquired signals are hierarchically grouped according to the physical topology of the battery pack and the channel constraints of the acquisition chip; The battery topology, signal function classification, slave board grouping, and chip channel are used as the basis and constraints for pre-grouping, and the first-fit decreasing algorithm is used to optimize message packaging. A hierarchical CAN ID allocation strategy is adopted, which divides CAN IDs in an orderly manner according to the hierarchical structure of board-type-message sequence number; The initial position arrangement of signals in the PDU data field is optimized, and the signal arrangement scheme is optimized under a multi-rule constraint strategy.

5. The method for automatically generating communication parameters and routes for BMS according to claim 4, characterized in that, The first-fit decreasing algorithm for message packaging optimization includes the following steps: All signals to be packaged are classified and sorted. Classification dimensions include: by board, by chip, by cycle, by priority, and by signal type. The sorting rule is: multi-level keyword sorting in descending order of board number → chip number → cycle → priority → signal bit width. Pack the messages, prioritizing those that are "from the same slave board, the same chip, the same cycle, and the same priority". Only when there are no more messages that can be included will other messages be considered. The message load is statistically analyzed, and the load is balanced and adjusted to reduce the total number of messages while satisfying all constraints, and finally verified.

6. The method for automatically generating communication parameters and routes for BMS according to claim 4, characterized in that, The optimized signal arrangement in the PDU data field optimizes the signal arrangement scheme under a multi-rule constraint strategy, including the following steps: sorting the signals to be laid out in descending order of bit width and initializing the PDU data field space marker; cyclically retrieving the current maximum bit width signal and searching for the best starting position that satisfies the constraints of byte alignment, same type concentration, channel order alignment, and continuous signal group. If not found, a new PDU is created and the search is repeated. Once found, the signal is placed and the space marker is updated; after all signals are placed, the remaining fragment space is used to fill small signals; after verifying that all constraints are met, the optimized layout scheme is output.

7. The method for automatically generating communication parameters and routes for BMS according to claim 1, characterized in that, The process of generating communication configuration based on structured multi-dimensional configuration input also includes routing configuration and interface configuration to achieve automatic generation of the full-stack configuration of the AUTOSAR communication stack.

8. The method for automatically generating communication parameters and routes for BMS according to claim 1, characterized in that, The process of converting the generated communication configuration into different output formats includes the following steps: Dynamically select and load the corresponding format converter based on the output format requirements; Mapping elements of the core configuration model to the target format metamodel completes the semantic-level transformation; The semantic model is converted into a specific structure in the target format, thus completing the structural-level conversion; Format-specific optimizations are performed based on the specific rules of the target format. Perform syntax validation, integrity validation, and consistency validation on the converted configuration.

9. A system for automatically generating communication parameters and routes for a BMS, characterized in that, It adopts a three-layer architecture, including a configuration input layer, an intelligent generation engine layer, and a configuration output layer. The configuration input layer is used to integrate the scattered configuration input information of BMS into a structured multi-dimensional configuration input, including defining the physical topology of the battery pack for each vehicle model; The intelligent generation engine layer is used to generate communication configurations based on structured multi-dimensional configuration inputs, including: using the acquisition message allocation algorithm to automatically generate different message allocation results for different vehicle models based on their topology parameters, and uniformly processing acquisition signals from different sources and application signals input by users, and automatically generating complete configuration parameters that conform to the AUTOSAR standard according to mapping rules. The configuration output layer is used to convert the generated communication configuration into different output formats to adapt to different development toolchains and application scenarios.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1 to 8.

Images