BMS protocol adaptation method and system based on CSV file and storage medium

Abstract

The invention discloses a BMS protocol adaptation method and system based on a CSV file and a storage medium. The method comprises the steps of standardizing CSV configuration file design, storing BMS protocol data in a fixed format and integrating a verification error correction mechanism; dynamic configuration management and initialization are conducted, a FATFS file system is used for managing CSV configuration files in an SD card, multiple transmission modes are supported, and dynamic loading and hot plugging are achieved; efficient data processing and analysis are carried out, and a complete process is designed to ensure that protocol data and CAN bus data are accurately matched; and performing security encryption and access control, performing encryption processing on the configuration file, and introducing an adaptive protocol version management and rollback mechanism. The system and the storage medium correspond to the system and respectively comprise related function modules, a storage layer, a management layer and the like. According to the scheme, standardized storage and efficient processing of the BMS protocol data are achieved, unified management is facilitated, development and maintenance cost is reduced, and effective management and use of the system on the configuration files in different environments are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of CSV file BMS protocol technology, and in particular to a BMS protocol adaptation method, system and storage medium based on CSV files. Background Technology

[0002] The application of BMS protocols in CSV files typically refers to recording battery parameters in a standardized format to achieve data exchange or monitoring. Its core is defining fields in the header, with each row storing time-series or battery status data, supporting cross-platform analysis, fault diagnosis, or charge / discharge control. The protocol likely follows industry standards to ensure compatibility. The simplicity of CSV makes it a common carrier for BMS data storage and transmission.

[0003] In the field of Battery Management Systems (BMS), different manufacturers' BMS protocols differ. Traditional adaptation methods often rely on code modification, which not only leads to a large amount of code writing and modification during development, increasing the workload of developers and the probability of errors, but also requires recompiling and deploying the entire code system when adapting to a new BMS protocol during the maintenance phase. This results in long development and maintenance cycles and high costs. At the same time, traditional methods lack flexibility and standardization in configuration file storage, transmission, and protocol data processing and management, making it difficult to adapt to the effective management of configuration files and the unified processing of protocol data from different manufacturers in different application scenarios, which is not conducive to the efficient adaptation of BMS protocols. Summary of the Invention

[0004] This invention provides the following technical solution: a BMS protocol adaptation method based on CSV files, comprising the following steps: S1 Standardized CSV Configuration File Design: S11. Use the standard CSV file format to store BMS protocol data in a fixed format. The data includes, but is not limited to, the CAN_ID, SignalName, StartByte, BitOffset, BitLength, Scale, Offset and IsSigned fields, and the BMS protocol data format is defined in a structured manner. S12. Integrate adaptive data validation and error correction mechanisms into CSV files, and introduce error correction mechanisms. S2 Dynamic Configuration Management and Initialization: S21. Use the FATFS file system to manage the CSV configuration files stored on the SD card, and transfer the configuration files via USB and HTTP. S22. Employs dynamic loading and hot-swapping functionality using CSV configuration files; S23. Introduce intelligent signal mapping and dynamic optimization algorithms to intelligently map and dynamically optimize signals in the BMS protocol, and predict potential signal conflicts and errors; S3 High-Efficiency Data Processing and Parsing: S31. Design a complete initialization process and processing process, including steps such as file reading, parsing, data reconstruction, signal matching, extraction, and global variable mapping. S32. Receive CAN bus data, reassemble the raw data, and convert the hardware-specific format into a standard CAN frame structure. S33. It adopts a distributed configuration management and collaborative update mechanism, allowing different devices and systems to share and synchronize CSV configuration files; S4 security encryption and access control: S41. Securely encrypt and implement multi-level access control for the CSV configuration file, using the AES-256 encryption algorithm to encrypt the configuration file; S42. Locate the predefined signal configuration based on the CAN ID, accurately extract the original value from the CAN data frame, and apply scaling parameters and offset to perform data conversion; S43. Write the parsed data into the BMS global output variable area to achieve efficient data sharing and utilization; S44. Introduce an adaptive protocol version management and rollback mechanism to automatically detect and record version changes in the CSV configuration file.

[0005] Preferably, in step S1, the adaptive data verification and error correction mechanism further includes: The checksum field adopts a dynamic generation strategy, which dynamically adjusts the check strength according to the business importance of each row of data in the CSV file. Critical data rows use CRC-32 check, while non-critical data rows use simple parity check. The error correction mechanism introduces redundant coding technology, inserting redundant rows into the CSV file according to a preset ratio. When a data error is detected, self-repair is achieved through cross-validation between the redundant rows and the erroneous rows. Establish a verification log system to record the time, location, and error type of each verification failure, providing data support for subsequent protocol optimization. The system dynamically allocates verification strength based on the business importance of each row of data in the CSV file. It uses CRC-32 checksum generation for critical data rows and simple parity checking for non-critical rows by parsing predefined metadata tags or automatically analyzing signal criticality. Secondly, redundant coded rows are inserted into the CSV file at a preset ratio. These redundant rows are generated using Reed-Solomon encoding or XOR operations. When a data error is detected, the system automatically matches the nearest redundant row with the erroneous row for cross-validation, and uses majority voting or error correction decoding algorithms to recover the original data. Finally, a structured verification log system is established to record the timestamp, CSV row number, error type, and automatic repair actions for each verification failure. The log is stored in a circular buffer and supports export analysis, providing statistical dimensions for subsequent protocol optimization. It also integrates anomaly pattern detection algorithms to trigger protocol configuration warnings when specific errors occur frequently.

[0006] Preferably, in step S2, the CSV configuration file dynamic loading and hot-plugging function adopts a double buffering mechanism to maintain the configuration file. The main buffer is used for the current system operation, and the backup buffer is used to load new configurations. Data consistency is ensured through atomic operations during switching. A configuration file preloading strategy is adopted to automatically detect and preload updated configuration files during system idle periods to reduce the delay during real-time updates. A configuration file difference comparison algorithm is introduced to synchronize changes to some files. A dual-buffering mechanism is employed to maintain configuration files. The primary buffer stores currently running configuration data, while the backup buffer is used to asynchronously load new configuration files. Memory barriers and atomic pointer swapping techniques ensure data consistency during buffer switching, guaranteeing uninterrupted system operation during configuration updates. Secondly, an intelligent preloading strategy is implemented. The system monitors CPU and I / O load and automatically scans the SD card directory during idle periods, comparing file timestamps and hash values. Background preloading is triggered only when a configuration file update is detected, parsing the new configuration into the backup buffer and performing version compatibility checks. An incremental update mechanism based on a binary difference comparison algorithm is introduced. When the system needs to apply configuration changes, only the changed file blocks are transmitted and replaced, not the entire file. Verification and comparison ensure the reliability of partial updates, while detailed version change logs are recorded to support rollback operations, thereby minimizing real-time update latency while ensuring system stability.

[0007] Preferably, in step S2, the intelligent signal mapping and dynamic optimization algorithm specifically includes: Construct a signal mapping model based on deep reinforcement learning, using signal extraction accuracy and system resource consumption as reward functions, and adjust the mapping strategy in real time; An attention mechanism is introduced to enable the model to focus on signal features that are highly correlated with the current BMS protocol state; The design incorporates a conflict prediction module that learns from historical signal conflict patterns to provide early warnings of potential conflicts and adjust signal priorities accordingly.

[0008] A signal mapping model based on deep reinforcement learning is constructed, using the PPO algorithm as the core strategy. The signal extraction accuracy and system CPU / memory consumption are designed as a composite reward function, and the mapping strategy is continuously optimized through interaction with the environment. Secondly, a Transformer self-attention mechanism is introduced into the model architecture. The association weight between signal features and the current BMS protocol state is calculated through a multi-head attention layer, enabling the model to dynamically focus on key signals. A conflict prediction submodule is designed, which uses an LSTM network to learn the time series patterns of historical signal conflicts. When a similar pattern is detected, an early warning is triggered, and the signal parsing priority queue is dynamically adjusted through a DQN network. An online learning engine is deployed to continuously collect actual running data to optimize model parameters. At the same time, knowledge distillation technology is used to compress the complex model into a lightweight inference model to ensure real-time requirements. The entire process is accelerated by TensorRT and deployed in ONNX format to achieve efficient operation.

[0009] Preferably, in step S3, the distributed configuration management and collaborative update mechanism deploys a configuration file synchronization system based on a P2P network, allowing devices to directly exchange configuration file update packages; uses blockchain technology to record the history of configuration file changes; and employs smart contract-driven automatic collaborative updates, triggering a forced update process for the remaining devices after a preset proportion of devices have completed their configuration updates.

[0010] A distributed hash table network based on the LibP2P protocol stack is deployed, where device nodes automatically discover and connect to neighboring nodes using the Kademlia algorithm, forming a decentralized configuration file synchronization network. Next, an IPFS-based configuration file storage scheme is designed, storing CSV configuration files in fragments and generating unique content identifiers. Devices directly exchange file update packages via CID. A Hyperledger Fabric blockchain module is integrated, recording each configuration file change as an immutable ledger entry. Then, a smart contract engine is deployed, with contract logic including version consensus threshold checks. When the threshold is reached, a forced update process is automatically triggered for the remaining nodes, and concurrent update conflicts are resolved using the CRDT algorithm. Dynamic adjustment of the update strategy is implemented, automatically switching between full / incremental update modes based on network bandwidth and device battery status. The entire process uses gRPC-Web to achieve real-time state synchronization between the browser and the device, ensuring configuration consistency in a distributed environment.

[0011] Preferably, in step S4, the security encryption and multi-level access control further include: The encryption algorithm uses AES-256-GCM mode, providing both data confidentiality and integrity verification. The access control layer integrates biometric authentication as a supplement to authorization in high-security scenarios. A dynamic permission adjustment mechanism is adopted to automatically upgrade or downgrade access permissions based on user behavior analysis results. The CSV configuration file is end-to-end encrypted using AES-256-GCM encryption mode. Dual verification of data confidentiality and integrity is achieved through a 128-bit random initialization vector and 96-bit additional authentication data. The encryption key is dynamically generated by the hardware security module and derived based on the PBKDF2 algorithm combined with the device's unique identifier. Secondly, a dual-mode biometric authentication system combining fingerprint recognition and iris scanning is integrated into the access control layer. Liveness detection is performed using a feature point matching algorithm. When a high-security access request is detected, the user is required to complete dual biometric verification and generate a temporary access token containing the device fingerprint, timestamp, and permission scope, with a validity period of 15 minutes. Finally, a dynamic permission adjustment engine based on user behavior analysis is deployed. LSTM neural networks analyze users' historical operation patterns, and when abnormal behavior is detected, a permission downgrade process is automatically triggered. Simultaneously, combined with the RBAC model, the user's role and permission set is dynamically adjusted based on their real-time risk score. The entire process continuously verifies user identity and device trustworthiness through a zero-trust architecture, ensuring the security of configuration file access.

[0012] A BMS protocol adaptation system based on CSV files, employing the aforementioned BMS protocol adaptation method based on CSV files, includes: a standardized configuration file management module, a dynamic configuration management and initialization module, an efficient data processing and parsing module, and a security encryption and access control module. The standardized configuration file management module designs and maintains a structured CSV configuration file containing key fields such as CAN_ID, SignalName, StartByte, BitOffset, BitLength, Scale, Offset, and IsSigned, ensuring standardized storage of BMS protocol data. The dynamic configuration management and initialization module utilizes the FATFS file system to efficiently manage CSV configuration files on the SD card, and supports the transfer and updating of configuration files via USB and HTTP. The high-efficiency data processing and parsing module ensures that the CSV configuration file can be correctly parsed and applied by designing a complete initialization process and processing process, including file reading, parsing, data reconstruction, signal matching, extraction and global variable mapping steps. The security encryption and access control module performs secure encryption on the CSV configuration file, using the AES-256 strong encryption algorithm to ensure that only authorized users can access and modify the configuration file.

[0013] Preferably, the dynamic configuration management and initialization module further includes: a configuration file hot-swap engine, which isolates file system operations and protocol parsing processes through a hardware abstraction layer, maintains the continuity of CAN bus data parsing through memory-mapped file technology when switching configurations, and has a built-in version compatibility verification module that automatically triggers a protocol version negotiation process when a protocol field conflict is detected between the old and new configuration files. By completely decoupling the underlying file system operations from the upper-layer protocol parsing process through a hardware abstraction layer, when a new configuration file insertion event is detected, the hardware abstraction layer driver immediately locks the current main configuration file and creates a memory-mapped copy to ensure that the parsing process continues to use the old configuration to process real-time CAN data. At the same time, an asynchronous loading thread is started to read the new file into the backup buffer and perform version compatibility verification in memory: by parsing the protocol feature fingerprints of the new and old files, the field-level differences are automatically compared and the semantic converter is activated to dynamically reassemble the extended fields into a format compatible with the main file. If a critical field conflict is detected, a rule-based version negotiation process is triggered to generate a temporary compatible configuration according to the preset conflict resolution rule set. Finally, an atomic switching operation is used to point the memory-mapped pointer to the new configuration. The entire process maintains the millisecond-level continuity of CAN bus data parsing and monitors switching timeout exceptions through hardware.

[0014] A BMS protocol adaptation storage medium based on CSV files, and a BMS protocol adaptation system based on CSV files as described above, includes: a standardized configuration storage layer, an intelligent configuration management layer, a security protection system, a dynamic adaptation engine, and a redundancy fault tolerance mechanism. The standardized configuration storage layer adopts a dual-mode CSV file architecture, including a main configuration file set and a dynamically extended field set. The main file fixedly includes the core fields CAN_ID, SignalName, and StartByte, and the extended set supports incremental field storage during protocol version upgrades. The intelligent configuration management layer uses a block storage strategy for configuration files, with the basic protocol parameter area and the device-specific optimization area physically isolated from each other. The security protection system implements a multi-layered encrypted storage scheme: the file system layer uses AES-256-GCM full-disk encryption, the file level is overlaid with dynamic token authentication, and the field level implements selective field encryption; Dynamic adaptation engine, built-in protocol feature library, storage medium for storing common BMS protocol fingerprint templates and conflict resolution rule sets; The redundancy and fault tolerance mechanism adopts an improved RAID storage architecture to achieve data striping and distributed verification within a single storage medium.

[0015] Preferably, the standardized configuration storage layer has a built-in protocol version adaptive engine, which realizes intelligent compatibility between new and old versions of CSV configuration files through a pre-set protocol feature fingerprint library. When a version difference is detected, the field mapping converter is automatically activated to dynamically reorganize the extended field set into a main file compatible format, and at the same time, the verification strategy adjustment module is triggered to switch the key data row verification algorithm combination according to the version characteristics. A protocol feature fingerprint database is pre-installed in the storage medium's solidified layer. This database extracts the core metadata features of each version of the CSV file using a hash algorithm, forming a multi-dimensional feature vector. When the system loads the configuration file, the engine first calculates the feature fingerprint of the current file and quickly compares it with the fingerprint database to identify the version difference. If the detected version difference exceeds a preset threshold, the field mapping converter is automatically activated. This converter uses a semantic-based field alignment algorithm to dynamically reorganize the newly added fields in the extended field set into a format compatible with the main file through predefined conversion rules. At the same time, the verification strategy adjustment module is triggered. This module dynamically switches the verification algorithm combination according to the version characteristics—CRC-32 verification is used for newly added key fields, while the original verification strength is maintained for old reserved fields. The entire process is seamlessly connected through a temporary version compatibility view established in memory, and the consistency of configuration synchronization between multiple devices is ensured through a version negotiation serial number mechanism.

[0016] In summary, compared with the prior art, the present invention provides a BMS protocol adaptation method, system, and storage medium based on CSV files, which has the following beneficial effects: The standard CSV file format is used to store BMS protocol data from different manufacturers with fixed field definitions. This structured approach enables standardized storage of protocol data, allowing BMS protocol data from different manufacturers to be extracted and saved in a unified format. This facilitates unified processing and management of protocol data from different manufacturers and provides a standardized data foundation for protocol adaptation. The FATFS file system is used to manage CSV configuration files stored on SD cards, and these files can be transferred via USB or HTTP. This management and transfer method makes the storage and transfer of CSV configuration files more flexible and convenient. The FATFS file system is mature and stable, and can effectively manage files on SD cards; USB and HTTP transfer methods are suitable for different application scenarios, enabling both short-range device connections and remote data interaction, facilitating the updating, sharing, and backup of configuration files, and ensuring effective management and use of configuration files in different environments. The design includes a complete initialization and processing flow, covering steps such as file reading, parsing, data reconstruction, signal matching, extraction, and global variable mapping. Through this series of processes, the protocol data in the CSV configuration file can be accurately matched and processed with the actual CAN bus data. The raw data is converted into a standard format and mapped to the global variable area, thereby achieving BMS protocol adaptation and enabling the system to correctly parse and process BMS protocol data from different manufacturers. By replacing traditional code modification with configuration file-based maintenance, large-scale code modifications are unnecessary when adapting to different BMS protocols from various vendors. This significantly reduces the amount of code written and modified during development, lowering the workload and error probability for developers. During maintenance, only configuration files need to be modified to adapt to new BMS protocols, without recompiling and deploying the entire code system, shortening the development and maintenance cycle and thus significantly reducing development and maintenance costs. Attached Figure Description

[0017] Figure 1 This is a flowchart of the method of the present invention.

[0018] Figure 2 This is a system flowchart of the present invention.

[0019] Figure 3 This is a flowchart of the storage medium of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please see Figure 1 The present invention provides the following technical solution: a BMS protocol adaptation method based on CSV files, comprising the following steps: S1 Standardized CSV Configuration File Design: S11. Use the standard CSV file format to store BMS protocol data in a fixed format. The data includes, but is not limited to, the CAN_ID, SignalName, StartByte, BitOffset, BitLength, Scale, Offset and IsSigned fields, and the BMS protocol data format is defined in a structured manner. S12. Integrate adaptive data validation and error correction mechanisms into CSV files, and introduce error correction mechanisms. in: CAN_ID: Identifies the CAN bus address.

[0022] SignalName: A unique identifier string assigned to commonly used variables in the BMS protocol.

[0023] StartByte: The starting byte position of the data in the CAN frame.

[0024] BitOffset: The bit offset address of the data within a byte (range 0-15).

[0025] BitLength: The actual length of the data (e.g., 16 bits, 8 bits, 1 bit, etc.).

[0026] Scale: The scaling parameter for data, used to address differences in unit formats between different manufacturers' protocol data. For example, when the unit is 0.1V, it is scaled to 0.1, and when the unit is 10V, it is scaled to 10.

[0027] Offset: Offset value.

[0028] IsSigned: Indicates whether the data is a signed number.

[0029] The CSV file structure is constructed strictly in accordance with the RFC 4180 standard, using UTF-8 encoding to ensure cross-platform compatibility, and forming a fixed data template through field order constraints. Metadata description blocks are then embedded in the file header, using JSON format to define field semantics, data types, and business importance levels, providing a foundation for subsequent verification strategies. For the adaptive verification mechanism, a dynamic verification engine is developed. This engine parses the importance markers in the metadata, automatically calling the CRC-32 checksum algorithm to generate checksums for data rows marked "CRITICAL," while using vertical redundancy verification for "NON-CRITICAL" rows, with the checksum appended as an independent column to the end of each row. Regarding the error correction mechanism, a redundant row generator based on Reed-Solomon encoding is implemented. When a data error is detected, the system recovers the original data through nearest-neighbor redundant row matching and error correction decoding algorithms. Simultaneously, a timestamped verification log system is established, recording error information in an independent CSV file. Log entries include error type, location coordinates, and automatic repair status, providing a big data analysis foundation for protocol optimization. The entire process achieves efficient I / O operations through memory-mapped file technology.

[0030] S2 Dynamic Configuration Management and Initialization: S21. Use the FATFS file system to manage the CSV configuration files stored on the SD card, and transfer the configuration files via USB and HTTP. S22. Employs dynamic loading and hot-swapping functionality using CSV configuration files; S23. Introduce intelligent signal mapping and dynamic optimization algorithms to intelligently map and dynamically optimize signals in the BMS protocol, and predict potential signal conflicts and errors; This system efficiently manages CSV configuration files on SD cards using the FATFS file system, enabling physical transfer of configuration files via USB and supporting remote transfer via HTTP. It employs dynamic loading and hot-swapping of CSV configuration files, maintaining them through a double-buffering mechanism: a primary buffer for current system operation and a backup buffer for loading new configurations. Atomic operations ensure data consistency during switching. A configuration file preloading strategy automatically detects and preloads updated configuration files during system idle periods, reducing latency during real-time updates. A configuration file difference comparison algorithm is introduced to synchronize changes to certain files. Furthermore, intelligent signal mapping and dynamic optimization algorithms are implemented. A deep reinforcement learning-based signal mapping model is constructed, using signal extraction accuracy and system resource consumption as reward functions to adjust the mapping strategy in real time. An attention mechanism is introduced to focus the model on signal features highly correlated with the current BMS protocol state. A conflict prediction module is designed to learn from historical signal conflict patterns, providing early warnings of potential conflicts and adjusting signal priorities. This enables intelligent mapping and dynamic optimization of signals in the BMS protocol, and predicts potential signal conflicts and errors.

[0031] S3 High-Efficiency Data Processing and Parsing: S31. Design a complete initialization process and processing process, including steps such as file reading, parsing, data reconstruction, signal matching, extraction, and global variable mapping. S32. Receive CAN bus data, reassemble the raw data, and convert the hardware-specific format into a standard CAN frame structure. S33. It adopts a distributed configuration management and collaborative update mechanism, allowing different devices and systems to share and synchronize CSV configuration files; The CSV configuration file is loaded through a structured initialization process, including file reading, parsing, data reassembly, signal matching, extraction, and global variable mapping, ensuring efficient mapping between protocol configuration and system memory. Subsequently, raw CAN bus data is received, its hardware-specific format is parsed, and it is reassembled into a standard CAN frame structure using bit manipulation and byte alignment techniques to extract valid signal values. Finally, based on a distributed configuration management mechanism, real-time synchronization and version coordination of CSV configuration files across multiple devices are achieved using P2P networks and blockchain technology. Automatic updates are triggered by smart contracts to ensure configuration consistency, while incremental update strategies optimize network bandwidth usage. Finally, the parsed, standardized data is written to the global variable area for use by the BMS system.

[0032] S4 security encryption and access control: S41. Securely encrypt and implement multi-level access control for the CSV configuration file, using the AES-256 encryption algorithm to encrypt the configuration file; S42. Locate the predefined signal configuration based on the CAN ID, accurately extract the original value from the CAN data frame, and apply scaling parameters and offset to perform data conversion; S43. Write the parsed data into the BMS global output variable area to achieve efficient data sharing and utilization; S44. Introduce an adaptive protocol version management and rollback mechanism to automatically detect and record version changes in the CSV configuration file.

[0033] The CSV configuration file is securely encrypted using the AES-256 encryption algorithm. Specifically, the AES-256-GCM mode is used to achieve dual verification of data confidentiality and integrity. The encryption key is dynamically generated by the hardware security module and derived based on the PBKDF2 algorithm combined with the device's unique identifier. Biometric authentication is integrated as a supplementary authorization method for high-security scenarios, and a dynamic permission adjustment mechanism is employed to automatically upgrade or downgrade access permissions based on user behavior analysis. Secondly, during data processing, the corresponding configuration is retrieved from the predefined signal configuration based on the CAN_ID, the original value is accurately extracted from the CAN data frame, and scaling parameters are applied. The system performs data conversion between the number and offset; then, the parsed and converted data is written to the BMS global output variable area to achieve efficient data sharing and utilization; finally, an adaptive protocol version management and rollback mechanism is introduced. A structured verification log system is established to record the timestamp, CSV line number, error type, and automatic repair action for each verification failure, and an anomaly pattern detection algorithm is integrated. When specific errors occur frequently, a protocol configuration warning is triggered. At the same time, the system automatically detects and records version changes of the CSV configuration file, supports automatic collaborative updates driven by smart contracts and records the configuration file change history based on blockchain technology, and ensures that a quick rollback to a stable version can be achieved when configuration problems occur.

[0034] In step S1, the adaptive data verification and error correction mechanism further includes: The checksum field adopts a dynamic generation strategy, which dynamically adjusts the check strength according to the business importance of each row of data in the CSV file. Critical data rows use CRC-32 check, while non-critical data rows use simple parity check. The error correction mechanism introduces redundant coding technology, inserting redundant rows into the CSV file according to a preset ratio. When a data error is detected, self-repair is achieved through cross-validation between the redundant rows and the erroneous rows. Establish a verification log system to record the time, location, and error type of each verification failure, providing data support for subsequent protocol optimization. The system dynamically allocates verification strength based on the business importance of each row of data in the CSV file. It uses CRC-32 checksum generation for critical data rows and simple parity checking for non-critical rows by parsing predefined metadata tags or automatically analyzing signal criticality. Secondly, redundant coded rows are inserted into the CSV file at a preset ratio. These redundant rows are generated using Reed-Solomon encoding or XOR operations. When a data error is detected, the system automatically matches the nearest redundant row with the erroneous row for cross-validation, and uses majority voting or error correction decoding algorithms to recover the original data. Finally, a structured verification log system is established to record the timestamp, CSV row number, error type, and automatic repair actions for each verification failure. The log is stored in a circular buffer and supports export analysis, providing statistical dimensions for subsequent protocol optimization. It also integrates anomaly pattern detection algorithms to trigger protocol configuration warnings when specific errors occur frequently.

[0035] In step S2, the dynamic loading and hot-swapping function of CSV configuration files adopts a double buffering mechanism to maintain the configuration files. The main buffer is used for the current system operation, and the backup buffer is used to load new configurations. During switching, atomic operations are used to ensure data consistency. A configuration file preloading strategy is adopted to automatically detect and preload updated configuration files during system idle periods to reduce the latency during real-time updates. A configuration file difference comparison algorithm is introduced to synchronize changes to some files. A dual-buffering mechanism is employed to maintain configuration files. The primary buffer stores currently running configuration data, while the backup buffer is used to asynchronously load new configuration files. Memory barriers and atomic pointer swapping techniques ensure data consistency during buffer switching, guaranteeing uninterrupted system operation during configuration updates. Secondly, an intelligent preloading strategy is implemented. The system monitors CPU and I / O load and automatically scans the SD card directory during idle periods, comparing file timestamps and hash values. Background preloading is triggered only when a configuration file update is detected, parsing the new configuration into the backup buffer and performing version compatibility checks. An incremental update mechanism based on a binary difference comparison algorithm is introduced. When the system needs to apply configuration changes, only the changed file blocks are transmitted and replaced, not the entire file. Verification and comparison ensure the reliability of partial updates, while detailed version change logs are recorded to support rollback operations, thereby minimizing real-time update latency while ensuring system stability.

[0036] In step S2, the intelligent signal mapping and dynamic optimization algorithm specifically includes: Construct a signal mapping model based on deep reinforcement learning, using signal extraction accuracy and system resource consumption as reward functions, and adjust the mapping strategy in real time; An attention mechanism is introduced to enable the model to focus on signal features that are highly correlated with the current BMS protocol state; The design incorporates a conflict prediction module that learns from historical signal conflict patterns to provide early warnings of potential conflicts and adjust signal priorities accordingly.

[0037] A signal mapping model based on deep reinforcement learning is constructed, using the PPO algorithm as the core strategy. The signal extraction accuracy and system CPU / memory consumption are designed as a composite reward function, and the mapping strategy is continuously optimized through interaction with the environment. Secondly, a Transformer self-attention mechanism is introduced into the model architecture. The association weight between signal features and the current BMS protocol state is calculated through a multi-head attention layer, enabling the model to dynamically focus on key signals. A conflict prediction submodule is designed, which uses an LSTM network to learn the time series patterns of historical signal conflicts. When a similar pattern is detected, an early warning is triggered, and the signal parsing priority queue is dynamically adjusted through a DQN network. An online learning engine is deployed to continuously collect actual running data to optimize model parameters. At the same time, knowledge distillation technology is used to compress the complex model into a lightweight inference model to ensure real-time requirements. The entire process is accelerated by TensorRT and deployed in ONNX format to achieve efficient operation.

[0038] In step S3, the distributed configuration management and collaborative update mechanism deploys a configuration file synchronization system based on a P2P network, allowing devices to directly exchange configuration file update packages; it uses blockchain technology to record the history of configuration file changes; and it uses smart contracts to drive automatic collaborative updates, triggering a forced update process for the remaining devices after a preset proportion of devices have completed their configuration updates.

[0039] A distributed hash table network based on the LibP2P protocol stack is deployed, where device nodes automatically discover and connect to neighboring nodes using the Kademlia algorithm, forming a decentralized configuration file synchronization network. Next, an IPFS-based configuration file storage scheme is designed, storing CSV configuration files in fragments and generating unique content identifiers. Devices directly exchange file update packages via CID. A Hyperledger Fabric blockchain module is integrated, recording each configuration file change as an immutable ledger entry. Then, a smart contract engine is deployed, with contract logic including version consensus threshold checks. When the threshold is reached, a forced update process is automatically triggered for the remaining nodes, and concurrent update conflicts are resolved using the CRDT algorithm. Dynamic adjustment of the update strategy is implemented, automatically switching between full / incremental update modes based on network bandwidth and device battery status. The entire process uses gRPC-Web to achieve real-time state synchronization between the browser and the device, ensuring configuration consistency in a distributed environment.

[0040] In step S4, security encryption and multi-level access control further include: The encryption algorithm uses AES-256-GCM mode, providing both data confidentiality and integrity verification. The access control layer integrates biometric authentication as a supplement to authorization in high-security scenarios. A dynamic permission adjustment mechanism is adopted to automatically upgrade or downgrade access permissions based on user behavior analysis results. The CSV configuration file is end-to-end encrypted using AES-256-GCM encryption mode. Dual verification of data confidentiality and integrity is achieved through a 128-bit random initialization vector and 96-bit additional authentication data. The encryption key is dynamically generated by the hardware security module and derived based on the PBKDF2 algorithm combined with the device's unique identifier. Secondly, a dual-mode biometric authentication system combining fingerprint recognition and iris scanning is integrated into the access control layer. Liveness detection is performed using a feature point matching algorithm. When a high-security access request is detected, the user is required to complete dual biometric verification and generate a temporary access token containing the device fingerprint, timestamp, and permission scope, with a validity period of 15 minutes. Finally, a dynamic permission adjustment engine based on user behavior analysis is deployed. LSTM neural networks analyze users' historical operation patterns, and when abnormal behavior is detected, a permission downgrade process is automatically triggered. Simultaneously, combined with the RBAC model, the user's role and permission set is dynamically adjusted based on their real-time risk score. The entire process continuously verifies user identity and device trustworthiness through a zero-trust architecture, ensuring the security of configuration file access.

[0041] Please see Figure 2 A BMS protocol adaptation system based on CSV files, employing the aforementioned BMS protocol adaptation method based on CSV files, includes: a standardized configuration file management module, a dynamic configuration management and initialization module, an efficient data processing and parsing module, and a security encryption and access control module. The standardized configuration file management module designs and maintains a structured CSV configuration file containing key fields such as CAN_ID, SignalName, StartByte, BitOffset, BitLength, Scale, Offset, and IsSigned, ensuring standardized storage of BMS protocol data. The CSV file template is designed to include key fields such as CAN_ID (identifying the CAN bus message ID), SignalName (signal name), StartByte (starting byte position), BitOffset (bit offset), BitLength (signal bit length), Scale (scaling factor), Offset (offset), and IsSigned (whether there is a signed bit), forming a standardized data structure. Then, the BMS protocol parameters are written to the file in a fixed column order using a CSV writing module, employing UTF-8 encoding to ensure compatibility. Next, a data verification layer is integrated to implement dynamic verification strategies for key fields (such as CAN_ID range checking and BitLength power verification), and a CRC-32 checksum is generated and appended to the end of the file. Simultaneously, a version controller is developed to embed a version number and feature fingerprint hash value in the file header, supporting backward compatibility during protocol upgrades. Finally, the FATFS file system API is used to implement atomic writing and exception recovery mechanisms for the CSV file, ensuring the integrity of storage operations.

[0042] The dynamic configuration management and initialization module utilizes the FATFS file system to efficiently manage CSV configuration files on the SD card, and supports the transfer and updating of configuration files via USB and HTTP. The SD card storage device is initialized through the FATFS file system interface, establishing a file system abstraction layer to shield the underlying hardware differences. Next, a configuration file manager is designed, employing a dual-buffering mechanism to maintain CSV configuration files. The primary buffer is used for real-time protocol parsing, while the backup buffer is used for asynchronous loading and updates. When a USB / HTTP transfer request is detected, a new configuration file is received via an asynchronous I / O task and stored in a temporary storage area. After the file verification module verifies integrity using SHA-256 hashing, a difference comparison engine is activated to analyze the version characteristics of the new and old files, automatically generating an incremental update package. Subsequently, a pre-loading process is triggered during system idle periods, loading the new configuration into the backup buffer using memory mapping technology. A semantic validator checks field compatibility, and if a protocol conflict is found, a rule engine is activated for intelligent repair. Finally, atomic pointer switching technology seamlessly switches between the primary and backup buffers, simultaneously updating the version status record and triggering a synchronization notification. The entire process is monitored for timeouts and anomalies by a hardware watchdog, ensuring that configuration updates do not affect the real-time operation of the BMS.

[0043] The high-efficiency data processing and parsing module ensures that the CSV configuration file can be correctly parsed and applied by designing a complete initialization process and processing process, including file reading, parsing, data reconstruction, signal matching, extraction and global variable mapping steps. Upon system startup, the CSV configuration file stored on the SD card is located and opened via the FATFS file system. The file content is read line by line, and each line is parsed according to the fixed format specifications of the CSV file to extract key fields such as CAN_ID, SignalName, StartByte, BitOffset, BitLength, Scale, Offset, and IsSigned. The parsed data is then reassembled, reorganizing the scattered signal data into a data format conforming to the standard CAN frame structure according to the CAN bus data frame requirements. Next, signal matching is performed, accurately matching the reassembled data with predefined signals in the BMS protocol based on identifiers such as SignalName. Then, signal extraction is performed, accurately extracting the required original values ​​from the matched data. Finally, the extracted signal data is mapped to the BMS global output variable area. By establishing a relationship between variable names and signal data, the parsed data is ensured to be correctly applied, achieving efficient data sharing and utilization within the system. The entire process strictly follows the designed processing flow, guaranteeing the correct parsing and application of the CSV configuration file.

[0044] The security encryption and access control module performs secure encryption on the CSV configuration file, using the AES-256 strong encryption algorithm to ensure that only authorized users can access and modify the configuration file. The AES-256-GCM encryption algorithm is used for end-to-end encryption of the CSV configuration file, generating a 128-bit random initialization vector and combining it with 96-bit additional authentication data to ensure data confidentiality and integrity. The encryption key is derived from the PBKDF2 algorithm and strengthened by combining the device's unique identifier and the user's preset password. The access control layer integrates fingerprint / iris dual-mode biometric authentication, requiring dual verification in high-security scenarios and generating a time-sensitive access token containing the device fingerprint, timestamp, and permission scope. An LSTM-based behavior analysis engine is deployed to continuously monitor user operation patterns. Abnormal behavior triggers dynamic permission adjustment using the RBAC model, combined with a zero-trust architecture to verify user identity and device trust status in real time. During file access, a hardware security module performs key decryption and permission verification. All operations are recorded in an immutable blockchain log, and memory-mapped file technology is used to prevent sensitive data from being written to disk. Ultimately, a four-in-one security protection system of encrypted storage, multi-factor authentication, dynamic permissions, and behavior analysis is formed.

[0045] The dynamic configuration management and initialization module also includes: a configuration file hot-swap engine, which isolates file system operations and protocol parsing processes through a hardware abstraction layer, maintains the continuity of CAN bus data parsing through memory-mapped file technology when switching configurations, and has a built-in version compatibility verification module that automatically triggers the protocol version negotiation process when a protocol field conflict is detected between the old and new configuration files. By completely decoupling the underlying file system operations from the upper-layer protocol parsing process through a hardware abstraction layer, when a new configuration file insertion event is detected, the hardware abstraction layer driver immediately locks the current main configuration file and creates a memory-mapped copy to ensure that the parsing process continues to use the old configuration to process real-time CAN data. At the same time, an asynchronous loading thread is started to read the new file into the backup buffer and perform version compatibility verification in memory: by parsing the protocol feature fingerprints of the new and old files, the field-level differences are automatically compared and the semantic converter is activated to dynamically reassemble the extended fields into a format compatible with the main file. If a critical field conflict is detected, a rule-based version negotiation process is triggered to generate a temporary compatible configuration according to the preset conflict resolution rule set. Finally, an atomic switching operation is used to point the memory-mapped pointer to the new configuration. The entire process maintains the millisecond-level continuity of CAN bus data parsing and monitors switching timeout exceptions through hardware.

[0046] Please see Figure 3 A BMS protocol adaptation storage medium based on CSV files, and a BMS protocol adaptation system based on CSV files, comprising: a standardized configuration storage layer, an intelligent configuration management layer, a security protection system, a dynamic adaptation engine and a redundancy fault tolerance mechanism. The standardized configuration storage layer adopts a dual-mode CSV file architecture, including a main configuration file set and a dynamic extended field set. The main file fixedly contains the core fields CAN_ID, SignalName and StartByte, and the extended set supports incremental field storage when the protocol version is upgraded. The core protocol fields are solidified into the main configuration file set to ensure the stability of basic parsing functions. At the same time, a dynamically extended field set is created as an auxiliary CSV file, which is associated with the main file through version number marking and feature hash. When the protocol is upgraded, the newly added non-destructive fields are written into the extended set. When the system loads, version differences are automatically identified by feature fingerprint comparison. A dual-file parallel parsing strategy is adopted. The main file provides the basic parsing framework, and the extended set supplements incremental parameters through a key-value pair mapping mechanism. The parsing engine dynamically merges the field definitions of the two to form a complete protocol configuration view. At the same time, a version compatibility verification module is built in. When a field conflict is detected, a semantic converter is triggered to convert the extended fields into the old version compatible format, ensuring a smooth transition when the protocol evolves.

[0047] The intelligent configuration management layer uses a block storage strategy for configuration files, with the basic protocol parameter area and the device-specific optimization area physically isolated from each other. The configuration file is divided into a basic protocol parameter area and a device-specific optimization area. Physical isolation is achieved by allocating independent storage space on the storage medium. The basic protocol parameter area stores core and general protocol parameters such as CAN_ID and SignalName, while the device-specific optimization area stores parameters that are optimized and adjusted for specific devices. During file read and write operations, the system automatically locates the corresponding storage area based on the parameter type. At the same time, an indexing mechanism is established to quickly access data in different areas. When data is updated, the basic protocol parameter area and the device-specific optimization area are updated independently, and a version control mechanism records the changes in each area to ensure data consistency and traceability.

[0048] The security protection system implements a multi-layered encrypted storage scheme: the file system layer uses AES-256-GCM full-disk encryption, the file level is overlaid with dynamic token authentication, and the field level implements selective field encryption; The file system layer employs AES-256-GCM encryption to fully encrypt the entire storage medium. A 128-bit random initialization vector and 96-bit additional authentication data ensure dual verification of data confidentiality and integrity. The encryption key is dynamically generated by the hardware security module and derived based on the PBKDF2 algorithm combined with the device's unique identifier. At the file level, a dynamic token authentication mechanism is overlaid. When a user accesses a file, the system generates a temporary access token containing the device fingerprint, timestamp, and permission scope. The user must provide this token to complete authentication; expired tokens require re-application. At the field level, selective field encryption is implemented. Based on the business importance and sensitivity of the fields, critical fields are individually encrypted using the AES-256-GCM encryption algorithm. The encryption key is also dynamically generated by the hardware security module, ensuring that only authorized users can access and modify these critical fields. Furthermore, encrypted fields are marked with metadata for proper processing during data parsing.

[0049] Dynamic adaptation engine, built-in protocol feature library, storage medium for storing common BMS protocol fingerprint templates and conflict resolution rule sets; The engine uses a pre-built protocol feature library to solidify fingerprint templates for common BMS protocols. It then uses a hash algorithm to extract core metadata features from the CSV configuration files of each protocol to generate multi-dimensional feature vectors. When a new configuration is loaded, the engine calculates the file feature fingerprint in real time and compares it with the template in the library to identify the protocol version and compatibility. If a version difference is detected, the engine activates a conflict resolution rule set. This rule set is built based on historical protocol conflict cases. It locates the field conflict type through pattern matching, then calls a predefined conversion strategy to dynamically adjust the signal configuration. At the same time, it triggers a verification strategy adaptation module to dynamically switch the verification algorithm combination of key data rows according to the protocol version. Finally, it achieves seamless adaptation by establishing a temporary compatible view in memory. The entire process is guaranteed by a version negotiation serial number mechanism to ensure the consistency of configuration synchronization between multiple devices.

[0050] The redundancy and fault tolerance mechanism adopts an improved RAID storage architecture to achieve data striping and distributed verification within a single storage medium; The implementation process for data striping and distributed verification within a single storage medium is as follows: The storage medium is divided into multiple fixed-size data blocks, and the data is distributed and stored in these data blocks in a striped manner to improve data read and write efficiency; at the same time, distributed verification information is calculated for each striped data according to a preset algorithm, and the verification information is distributed and stored in specific data blocks; when a data error is detected, the system automatically locates the erroneous data block, uses the stored distributed verification information, and recovers the erroneous data through the verification algorithm to ensure data integrity and reliability. The entire process is completed within a single storage medium without the need for additional hardware support.

[0051] The standardized configuration storage layer has a built-in protocol version adaptive engine. It achieves intelligent compatibility between new and old versions of CSV configuration files through a pre-built protocol feature fingerprint library. When a version difference is detected, the field mapping converter is automatically activated to dynamically reorganize the expanded field set into a main file compatible format. At the same time, the verification strategy adjustment module is triggered to switch the combination of key data row verification algorithms according to the version characteristics. A protocol feature fingerprint database is pre-installed in the storage medium's solidified layer. This database extracts the core metadata features of each version of the CSV file using a hash algorithm, forming a multi-dimensional feature vector. When the system loads the configuration file, the engine first calculates the feature fingerprint of the current file and quickly compares it with the fingerprint database to identify the version difference. If the detected version difference exceeds a preset threshold, the field mapping converter is automatically activated. This converter uses a semantic-based field alignment algorithm to dynamically reorganize the newly added fields in the extended field set into a format compatible with the main file through predefined conversion rules. At the same time, the verification strategy adjustment module is triggered. This module dynamically switches the verification algorithm combination according to the version characteristics—CRC-32 verification is used for newly added key fields, while the original verification strength is maintained for old reserved fields. The entire process is seamlessly connected through a temporary version compatibility view established in memory, and the consistency of configuration synchronization between multiple devices is ensured through a version negotiation serial number mechanism.

[0052] The standard CSV file format is used to store BMS protocol data from different manufacturers with fixed field definitions. This structured approach enables standardized storage of protocol data, allowing BMS protocol data from different manufacturers to be extracted and saved in a unified format. This facilitates unified processing and management of protocol data from different manufacturers and provides a standardized data foundation for protocol adaptation. The FATFS file system is used to manage CSV configuration files stored on SD cards, and these files can be transferred via USB or HTTP. This management and transfer method makes the storage and transfer of CSV configuration files more flexible and convenient. The FATFS file system is mature and stable, and can effectively manage files on SD cards; USB and HTTP transfer methods are suitable for different application scenarios, enabling both short-range device connections and remote data interaction, facilitating the updating, sharing, and backup of configuration files, and ensuring effective management and use of configuration files in different environments. The design includes a complete initialization and processing flow, covering steps such as file reading, parsing, data reconstruction, signal matching, extraction, and global variable mapping. Through this series of processes, the protocol data in the CSV configuration file can be accurately matched and processed with the actual CAN bus data. The raw data is converted into a standard format and mapped to the global variable area, thereby achieving BMS protocol adaptation and enabling the system to correctly parse and process BMS protocol data from different manufacturers. By replacing traditional code modification with configuration file-based maintenance, large-scale code modifications are unnecessary when adapting to different BMS protocols from various vendors. This significantly reduces the amount of code written and modified during development, lowering the workload and error probability for developers. During maintenance, only configuration files need to be modified to adapt to new BMS protocols, without recompiling and deploying the entire code system, shortening the development and maintenance cycle and thus significantly reducing development and maintenance costs.

[0053] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0054] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A BMS protocol adaptation method based on CSV files, characterized in that, Includes the following steps: S1 Standardized CSV Configuration File Design: S11. Use the standard CSV file format to store BMS protocol data in a fixed format. The data includes, but is not limited to, the CAN_ID, SignalName, StartByte, BitOffset, BitLength, Scale, Offset, and IsSigned fields. S12. Integrate adaptive data validation and error correction mechanisms into CSV files, and introduce error correction mechanisms. S2 Dynamic Configuration Management and Initialization: S21. Use the FATFS file system to manage the CSV configuration files stored on the SD card, and transfer the configuration files via USB and HTTP. S22. Employs dynamic loading and hot-swapping functionality using CSV configuration files; S23. Introduce intelligent signal mapping and dynamic optimization algorithms to intelligently map and dynamically optimize signals in the BMS protocol, and predict potential signal conflicts and errors; S3 High-Efficiency Data Processing and Parsing: S31. Design a complete initialization process and processing process, including steps such as file reading, parsing, data reconstruction, signal matching, extraction, and global variable mapping. S32. Receive CAN bus data, reassemble the raw data, and convert the hardware-specific format into a standard CAN frame structure. S33. It adopts a distributed configuration management and collaborative update mechanism, allowing different devices and systems to share and synchronize CSV configuration files; S4 security encryption and access control: S41. Securely encrypt and implement multi-level access control for the CSV configuration file, using the AES-256 encryption algorithm to encrypt the configuration file; S42. Locate the predefined signal configuration based on the CAN ID, accurately extract the original value from the CAN data frame, and apply scaling parameters and offset to perform data conversion; S43. Write the parsed data into the BMS global output variable area; S44. Introduce an adaptive protocol version management and rollback mechanism to automatically detect and record version changes in the CSV configuration file.

2. The BMS protocol adaptation method based on CSV files according to claim 1, characterized in that: In step S1, the adaptive data verification and error correction mechanism further includes: The checksum field adopts a dynamic generation strategy, which dynamically adjusts the check strength according to the business importance of each row of data in the CSV file. Critical data rows use CRC-32 check, while non-critical data rows use simple parity check. The error correction mechanism introduces redundant coding technology, inserting redundant rows into the CSV file according to a preset ratio. When a data error is detected, self-repair is achieved through cross-validation between the redundant rows and the erroneous rows. Establish a verification log system to record the time, location, and error type of each verification failure, providing data support for subsequent protocol optimization.

3. The BMS protocol adaptation method based on CSV files according to claim 1, characterized in that: In step S2, the CSV configuration file dynamic loading and hot-swapping function adopts a double buffering mechanism to maintain the configuration file. The main buffer is used for the current system operation, and the backup buffer is used to load new configurations. When switching, atomic operations are used to ensure data consistency. A configuration file preloading strategy is adopted to automatically detect and preload updated configuration files during system idle periods to reduce the delay during real-time updates. A configuration file difference comparison algorithm is introduced to synchronously change some files.

4. The BMS protocol adaptation method based on CSV files according to claim 1, characterized in that: In step S2, the intelligent signal mapping and dynamic optimization algorithm specifically includes: Construct a signal mapping model based on deep reinforcement learning, using signal extraction accuracy and system resource consumption as reward functions, and adjust the mapping strategy in real time; An attention mechanism is introduced to enable the model to focus on signal features that are highly correlated with the current BMS protocol state; The design incorporates a conflict prediction module that learns from historical signal conflict patterns to provide early warnings of potential conflicts and adjust signal priorities accordingly.

5. The BMS protocol adaptation method based on CSV files according to claim 1, characterized in that: In step S3, the distributed configuration management and collaborative update mechanism deploys a configuration file synchronization system based on a P2P network, allowing devices to directly exchange configuration file update packages; it uses blockchain technology to record the history of configuration file changes; and it uses smart contracts to drive automatic collaborative updates, triggering a forced update process for the remaining devices after a preset proportion of devices have completed their configuration updates.

6. The BMS protocol adaptation method based on CSV files according to claim 1, characterized in that: In step S4, the security encryption and multi-level access control further include: The encryption algorithm uses AES-256-GCM mode, providing both data confidentiality and integrity verification. The access control layer integrates biometric authentication as a supplement to authorization in high-security scenarios. A dynamic permission adjustment mechanism is adopted to automatically upgrade or downgrade access permissions based on user behavior analysis results.

7. A BMS protocol adaptation system based on CSV files, employing the BMS protocol adaptation method based on CSV files as described in any one of claims 1-6, characterized in that, include: The system includes a standardized configuration file management module, a dynamic configuration management and initialization module, an efficient data processing and parsing module, and a security encryption and access control module. The standardized configuration file management module designs and maintains a structured CSV configuration file, which contains key fields such as CAN_ID, SignalName, StartByte, BitOffset, BitLength, Scale, Offset, and IsSigned, to ensure the standardized storage of BMS protocol data. The dynamic configuration management and initialization module utilizes the FATFS file system to efficiently manage CSV configuration files on the SD card, and supports the transfer and updating of configuration files via USB and HTTP. The high-efficiency data processing and parsing module ensures that the CSV configuration file can be correctly parsed and applied by designing a complete initialization process and processing process, including file reading, parsing, data reconstruction, signal matching, extraction and global variable mapping steps. The security encryption and access control module performs secure encryption on the CSV configuration file, using the AES-256 strong encryption algorithm to ensure that only authorized users can access and modify the configuration file.

8. A BMS protocol adaptation system based on CSV files according to claim 7, characterized in that: The dynamic configuration management and initialization module also includes: a configuration file hot-swap engine, which isolates file system operations and protocol parsing processes through a hardware abstraction layer, maintains the continuity of CAN bus data parsing through memory-mapped file technology when switching configurations, and has a built-in version compatibility verification module that automatically triggers the protocol version negotiation process when a protocol field conflict is detected between the old and new configuration files.

9. A BMS protocol adaptation storage medium based on CSV files, comprising a BMS protocol adaptation system based on CSV files as described in any one of claims 7-8, characterized in that, include: The system includes a standardized configuration storage layer, an intelligent configuration management layer, a security protection system, a dynamic adaptation engine, and a redundancy fault tolerance mechanism. The standardized configuration storage layer adopts a dual-mode CSV file architecture, which includes a main configuration file set and a dynamically extended field set. The main file fixedly contains the core fields CAN_ID, SignalName, and StartByte, while the extended set supports incremental field storage during protocol version upgrades. The intelligent configuration management layer uses a block storage strategy for configuration files, with the basic protocol parameter area and the device-specific optimization area physically isolated from each other. The security protection system implements a multi-layered encrypted storage scheme: the file system layer uses AES-256-GCM full-disk encryption, the file level is overlaid with dynamic token authentication, and the field level implements selective field encryption; Dynamic adaptation engine, built-in protocol feature library, storage medium for storing common BMS protocol fingerprint templates and conflict resolution rule sets; The redundancy and fault tolerance mechanism adopts an improved RAID storage architecture to achieve data striping and distributed verification within a single storage medium.

10. A BMS protocol adaptation storage medium based on CSV files according to claim 9, characterized in that: The standardized configuration storage layer has a built-in protocol version adaptive engine, which realizes intelligent compatibility between new and old versions of CSV configuration files through a pre-set protocol feature fingerprint library. When a version difference is detected, the field mapping converter is automatically activated to dynamically reorganize the expanded field set into a main file compatible format. At the same time, the verification strategy adjustment module is triggered to switch the combination of key data row verification algorithms according to the version characteristics.

Images