A test data construction method and system of an on-chain battery swap platform and a storage medium

Abstract

The present application relates to the technical field of system testing, and particularly relates to a test data construction method and system of an on-chain battery swap platform and a storage medium, the method comprising the following steps: randomly generating a vehicle message; receiving the vehicle message, an account and battery information; verifying the vehicle message by using a vehicle state data verification model, and eliminating the vehicle message that fails to pass the verification; after associating the vehicle message with the account and the battery information of an uploading person, generating transaction information and uploading the transaction information to a block chain storage; querying the block chain, and downloading the transaction information containing the vehicle message that is queried; extracting the vehicle message in the transaction information, and sending the vehicle message to the on-chain battery swap platform to be tested; and downloading a module to periodically generate a reward transaction, and transferring a token corresponding to the number of downloads into the account of the uploading person. The present application has the beneficial technical effects of improving the quality of test data and helping to improve the test efficiency.

Description

Technical Field

[0001] This invention relates to the field of system testing technology, specifically to a method, system, and storage medium for constructing test data for an on-chain battery swapping platform. Background Technology

[0002] The battery swapping business of new energy vehicles is gradually being implemented. The new energy vehicle battery swapping microservice platform is a functional platform for carrying out battery swapping business and settling accounts. Before the new energy vehicle battery swapping microservice platform is put into operation, its business logic needs to be tested. However, in the business scenario of combining new energy battery swapping with blockchain, the degree of automation of testing for the battery swapping business process is not high. The existing testing methods are: 1. Testers arbitrarily construct information such as SoC, kWh, TRIP of new energy vehicles and push the information directly to the message middleware. The message middleware forwards the message to the IOT service module for message processing, and then uses it to test the new energy vehicle battery swapping microservice platform. However, this testing method has two drawbacks: (1) There is no correlation between the arbitrarily constructed values ​​such as SoC, kWh, TRIP, etc., making it difficult to simulate real test scenarios and easy to construct some impossible test situations, reducing test accuracy and test efficiency; (2) This method directly sends the message to the message middleware without going through the blockchain link, resulting in an incomplete test process and easy to miss the failure scenario of the battery swapping business caused by blockchain anomalies. 2. Testers test through real vehicles. Although this testing method can actually simulate the real data of users. However, this method has extremely low testing efficiency, and many abnormal scenarios cannot be tested, resulting in incomplete test case coverage. Summary of the Invention

[0003] The technical problem this invention aims to solve is the lack of an efficient solution for generating test data for on-chain battery swapping platforms. This invention proposes a method and system for constructing test data for on-chain battery swapping platforms, which can provide test data that more closely resembles actual usage environments.

[0004] To solve the above technical problems, the present invention adopts the following technical solution: a method for constructing test data for an on-chain battery swapping platform, comprising the following steps:

[0005] Randomly generate vehicle messages;

[0006] Receive vehicle messages, account and battery information, wherein the vehicle messages include at least one vehicle status data;

[0007] The vehicle status data verification model is used to verify vehicle messages and remove vehicle messages that fail the verification. The vehicle status data verification model verifies whether at least one vehicle status data is matched. If they match, the verification passes; if they do not match, the verification fails.

[0008] After associating vehicle messages with the personnel's account and battery information, transaction information is generated and uploaded to the blockchain for storage;

[0009] Query the blockchain and download the transaction information containing vehicle messages.

[0010] Extract the vehicle messages from the downloaded transaction information and send the vehicle messages to the on-chain battery swapping platform to be tested.

[0011] Reward transactions are generated periodically, transferring tokens corresponding to the number of downloads to the account of the person who uploaded the download.

[0012] Preferably, the vehicle status data includes the battery pack SoC, remaining battery power, trip meter or vehicle alarm code, the trip meter being the mileage the vehicle has traveled this time, the battery information including the BMU number of the vehicle corresponding to the battery pack, and the upload module receiving vehicle registration information sent by the uploader, with each registered vehicle assigned a unique BMU number.

[0013] Preferred methods for establishing vehicle status data verification models include:

[0014] Set numerical filtering rules, which record the value rules for battery pack SoC, battery pack remaining power, trip meter, and vehicle alarm codes. Vehicle status data that does not conform to the value rules will fail verification.

[0015] Preferably, the vehicle status data verification model also includes exclusion rules, and the methods for establishing exclusion rules include:

[0016] List the numerical ranges for battery pack SoC, remaining battery capacity, and trip meter readings;

[0017] The numerical range is divided into at least one value interval, and an interval identification code is associated with the value interval. The battery pack SoC, the remaining battery power and the trip meter are assigned interval identification codes corresponding to the values, and the vehicle alarm code is regarded as the interval identification code.

[0018] Establish exclusion entries, which record the interval identifiers into which other vehicle status data cannot fall when a vehicle status data falls into an interval identifier code.

[0019] Multiple exclusion entries are created to ensure that each exclusion entry covers every interval identifier code of each vehicle status data.

[0020] Preferred methods for establishing vehicle status data verification models include:

[0021] Read at least one vehicle message and associate the verification result of the vehicle message as sample data;

[0022] A vehicle message is randomly generated. The randomly generated vehicle message is compared with the exclusion rule. If it matches the exclusion entry, the vehicle message is marked as verification failed. If it does not match any of the exclusion entries, the vehicle message is marked as verification passed.

[0023] The tagged vehicle messages are included in the sample data;

[0024] A neural network model is established, wherein the input layer neurons of the neural network model correspond to the vehicle status data contained in the vehicle message, and the output of the neural network model is the probability distribution of the verification result;

[0025] The neural network model is trained and tested using the sample data until its accuracy reaches a preset threshold. The neural network model is then used as the vehicle status data verification model.

[0026] Preferred methods for establishing vehicle status data verification models include:

[0027] Read at least one vehicle message and associate the verification result of the vehicle message as sample data;

[0028] A neural network model is established, wherein the input layer neurons of the neural network model correspond to the vehicle status data contained in the vehicle message, and the output of the neural network model is the probability distribution of the verification result;

[0029] The neural network model is trained and tested using the sample data until its accuracy reaches a preset threshold. The neural network model is then used as the vehicle status data verification model.

[0030] Preferably, several interface modules for different types of SDKs are established, through which vehicle messages, account and battery information are received.

[0031] A computer system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements a test data construction method for an on-chain battery swapping platform as described above.

[0032] A computer-readable storage medium storing a computer program that, when executed by a processor, implements a method for constructing test data for an on-chain battery swapping platform as described above.

[0033] A test data construction system for an on-chain battery swapping platform is provided, used to execute a test data construction method for an on-chain battery swapping platform as described above. The system includes a generation module, an upload module, and a download module. The generation module randomly generates vehicle messages. The upload module receives vehicle messages, account information, and battery information uploaded by an uploader or generated by the generation module. Each vehicle message includes at least one vehicle status data. The upload module uses a vehicle status data verification model to verify the vehicle messages, discarding those that fail verification. The vehicle status data verification model verifies whether at least one vehicle status data matches; if they match, the verification passes; otherwise, it fails. The upload module associates the vehicle message with the corresponding uploader's account and battery information, generates transaction information, and uploads it to the blockchain for storage. The download module queries the blockchain, downloads the query information containing the vehicle message, extracts the vehicle message from the transaction information, and sends the vehicle message to the on-chain battery swapping platform to be tested. The download module periodically generates reward transactions, transferring tokens corresponding to the number of downloads to the account of the corresponding uploader.

[0034] The beneficial technical effects of this invention include: 1) Generating test data that is difficult to generate in real vehicle testing using the generation module, making the testing of the on-chain battery swapping platform more comprehensive and ensuring the stability and reliability of the on-chain battery swapping platform operation; 2) Receiving vehicle status data of real vehicles uploaded by uploaders through the upload module, obtaining the real vehicle status, and then establishing a vehicle status data verification model based on the real vehicle status data. The vehicle messages filtered by the vehicle status data verification model eliminate unreasonable vehicle status data, improving the quality of test data and helping to improve testing efficiency; 3) Storing vehicle messages using blockchain can ensure the authenticity of vehicle messages. The download module records the number of times vehicle messages are used and rewards uploaders based on the number of uses, which can stimulate the enthusiasm of uploaders and upload more real vehicle data to the blockchain; 4) Connecting with uploaders using different SDK types through the docking module can facilitate the upload of vehicle messages by uploaders and expand the range of vehicle status data that the upload module can receive.

[0035] Other features and advantages of the present invention will be disclosed in detail in the following detailed description and accompanying drawings. Attached Figure Description

[0036] The invention will be further described below with reference to the accompanying drawings:

[0037] Figure 1 This is a schematic diagram of the test data construction method according to Embodiment 1 of the present invention.

[0038] Figure 2 This is a schematic diagram of the method for establishing exclusion rules in Embodiment 1 of the present invention.

[0039] Figure 3 This is a schematic diagram of the computer system structure according to Embodiment 1 of the present invention.

[0040] Figure 4 This is a schematic diagram of the system structure constructed based on the test data of Embodiment 1 of the present invention.

[0041] Figure 5 This is a schematic diagram of the method for establishing a vehicle status data verification model according to Embodiment 2 of the present invention.

[0042] Figure 6 This is a schematic diagram of the method for establishing a vehicle status data verification model according to Embodiment 3 of the present invention.

[0043] Among them: 10. Computer system, 11. Memory, 12. Computer program, 13. Processor, 20. Blockchain, 21. Upload module, 22. Generation module, 23. Download module. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be explained and described below with reference to the accompanying drawings. However, the following embodiments are only preferred embodiments of the present invention and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of the present invention.

[0045] In the following description, terms such as “inner,” “outer,” “upper,” “lower,” “left,” and “right” are used only to indicate orientation or positional relationship for the convenience of describing the embodiments and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0046] Definition: State of charge (SoC).

[0047] Before introducing the technical solution of this embodiment, the application scenario and related technologies of this embodiment will be introduced.

[0048] The rapid growth in sales and ownership of new energy vehicles has led to a surge in demand for charging stations. Currently, new energy vehicles, especially pure electric vehicles, often experience range anxiety, making charging a crucial aspect of new energy vehicle services. While the construction growth rate of charging stations has remained high, the number of stations still falls short of meeting the rapidly increasing charging demand. Furthermore, charging at existing charging stations is time-consuming, resulting in long waits for drivers and a poor user experience. Therefore, battery swapping has emerged as a solution. Battery swapping involves installing easily removable modules of the battery pack within the vehicle. During swapping, automated equipment removes the original battery pack and immediately replaces it with a fully charged new one. The swap can be completed within minutes, after which the vehicle can be driven again without waiting. Battery swapping is rapidly developing into an important charging solution for new energy vehicles. Battery swapping platforms calculate the cost to the user based on battery consumption and other losses, providing a quick and convenient way to replenish power. Leveraging blockchain technology, the battery swapping platform enables efficient services such as data sharing and fully automated online transaction processing, further enhancing the user experience.

[0049] Currently, battery swapping for new energy vehicles typically utilizes automated swapping platforms. These platforms not only control the swapping equipment for battery pack installation and removal but also generate corresponding order information for users and process payments. Now, on-chain battery swapping platforms leveraging Blockchain 2.0 have emerged. These on-chain platforms offer significant advantages over conventional platforms, including higher credibility and data security.

[0050] Traditional battery swapping platforms store their business and financial data on their backend servers, which is susceptible to data loss, tampering, and falsification, resulting in low reliability and hindering business expansion. Blockchain-20, on the other hand, possesses inherent trustworthiness and can provide reliable data storage services, ensuring the authenticity and security of business and financial data, and guaranteeing the smooth operation of the battery swapping business.

[0051] Blockchain 20 provides trusted proofs because it is a chain of blocks. Each block stores specific information, and these blocks are linked together in chronological order of their creation. This chain is stored on all servers, and as long as one server in the entire system is operational, the entire Blockchain 20 is secure. These servers are called nodes in the Blockchain 20 system, and they provide storage space and computing power for the entire system. To modify information in Blockchain 20, the consent of more than half of the nodes must be obtained, and the information in all nodes must be modified. Since these nodes are usually controlled by different entities, tampering with information in Blockchain 20 is extremely difficult.

[0052] Leveraging Blockchain-20 for battery swapping not only allows for the preservation of crucial data directly related to cost calculation, such as remaining battery capacity, battery SoC, and trip meter readings, effectively preventing transaction disputes, but also preserves battery voltage, current, and temperature data. This data accumulation provides a foundation for future data analysis and mining. Based on the remaining battery capacity, SoC, and trip meter readings, the on-chain battery swapping platform calculates the cost of the swap and generates relevant order information. The functionality and business logic of the on-chain battery swapping platform will vary significantly depending on the operator. Before its launch, the platform's functionality and business logic need to be tested to ensure reliability. Current testing methods suffer from limited data sources or data detached from actual business operations, impacting the effectiveness of testing. Therefore, it is necessary to research test data generation schemes to improve the quantity and quality of test data. This embodiment provides a method for constructing test data for an on-chain battery swapping platform. Please refer to the appendix. Figure 1 This includes the following steps:

[0053] Step A01) Randomly generate vehicle messages;

[0054] Step A02) Receive vehicle messages, account and battery information. The vehicle message includes at least one vehicle status data.

[0055] Step A03) Use the vehicle status data verification model to verify the vehicle message and remove the vehicle message that fails the verification. The vehicle status data verification model verifies whether at least one vehicle status data is matched. If they match, the verification passes; if they do not match, the verification fails.

[0056] Step A04) After associating the vehicle message with the account and battery information of the corresponding uploader, transaction information is generated and uploaded to the blockchain 20 storage;

[0057] Step A05) Query blockchain 20 and download the transaction information containing vehicle messages;

[0058] Step A06) Extract the vehicle message from the transaction information and send the vehicle message to the on-chain battery swapping platform to be tested;

[0059] Step A07) Periodically generate reward transactions and transfer the tokens corresponding to the number of downloads to the account of the person who uploaded the download.

[0060] The vehicle message contains vehicle status data required for testing. This data includes one or more of the following: battery pack SoC, remaining battery charge, trip meter reading, or vehicle alarm code. The trip meter reading indicates the vehicle's mileage driven by the battery in this test. Battery information includes the BMU number corresponding to the vehicle's battery pack. The upload module 21 receives vehicle registration information from the uploader; registered vehicles are assigned unique BMU numbers. The vehicle message is then provided to the on-chain battery swapping platform, which performs the battery swap based on the message, generates order information, and records the amount the user needs to pay for the swap.

[0061] In this embodiment, the battery pack SoC, remaining battery capacity, and vehicle alarm code in the vehicle message are used as the basis for billing. The cost of battery swapping is calculated by multiplying the remaining battery capacity by a preset first coefficient, adding the product of the battery pack SoC loss by a preset second coefficient, and adding the cost corresponding to the vehicle alarm code. The battery pack SoC loss is calculated as follows: the ratio of the current remaining battery capacity to the nominal battery capacity is used as the reference SoC. The reference SoC is subtracted from the current battery pack SoC to obtain the battery pack SoC loss. The battery pack SoC loss mainly represents the degree of reduction in the maximum available capacity of the battery pack. When the battery pack is newer, the SoC will be smaller for the same remaining capacity. If the battery pack is over-discharged after use, the battery pack SoC loss will be larger, and it may also cause the battery pack to issue a low battery warning. Thus, additional costs are added through the battery pack SoC loss and low battery warning items to compensate for the damage caused by over-discharge of the battery pack. At the same time, users are encouraged to use the power battery reasonably.

[0062] The battery pack SoC is used to indicate the remaining battery capacity range of 0%-100%. In the constructed vehicle information test message, this value exists in hexadecimal format, so it needs to be converted into a different data format.

[0063] The remaining battery capacity refers to the remaining capacity of the original battery before the battery swap. This value is strongly correlated with the battery pack's SoC value and is usually directly proportional to it. This value is greater than 0 and exists in hexadecimal, so it needs to be converted into the corresponding message format using a user-understandable decimal value.

[0064] The trip meter records the mileage of a new battery in the vehicle. This value is greater than 0 and is usually in hexadecimal or binary format, which needs to be converted into the corresponding message format for user-understandable decimal values.

[0065] Vehicle alarm codes, denoted by WarnCode, contain dozens of alarm information types, including voltage, current, temperature, battery level, and fire alarms. In this embodiment, the vehicle alarm code must include at least voltage alarms, temperature alarms, and remaining battery level alarms.

[0066] There is a correlation between the battery pack SoC, remaining battery power, trip meter reading, and vehicle alarm code in the vehicle status data. The generation module 22 randomly generates vehicle messages, assigning random values ​​to the battery pack SoC, remaining battery power, trip meter reading, and vehicle alarm code. This can cause mismatches between vehicle status data. Therefore, verification is required using a vehicle status data verification model. Mismatched vehicle messages are deleted, i.e., messages that fail verification are removed. For example, if the battery pack SoC value is 80%, the remaining battery power is 0.2kWh, the trip meter reading is 900km, and the vehicle alarm code is "no anomaly," then the SoC value of 80% indicates sufficient remaining battery power and a low driving range with the current battery pack. However, the remaining battery power of 0.2kWh and the trip meter reading of 900km do not match the battery pack SoC. Such vehicle messages cannot complete the test of the on-chain battery swapping platform and therefore need to be deleted.

[0067] On the other hand, when the battery pack's SoC value is 0.1%, the remaining battery capacity is 0.02kWh, the total mileage is 650km, and the vehicle alarm code is "no anomaly code," such a vehicle message is meaningless. Since the battery pack's SoC is extremely low, it will inevitably trigger a power alarm and generate a power alarm code. However, since this vehicle message lacks a vehicle alarm code, billing during battery swapping will be based on battery power consumption and SoC loss, rather than on the alarm-generating scenario, leading to a discrepancy between business logic and expectations. This prevents accurate testing of the on-chain battery swapping platform. A vehicle status data verification model can eliminate these mismatched vehicle messages, obtaining higher-quality, more realistic test data and improving the accuracy of on-chain battery swapping platform testing.

[0068] The on-chain battery swapping platform also records other information included in the order details, such as the order number, original battery code, remaining battery power, swapping time, swapping station location, new battery code, new battery power, and the amount payable for the swap. The platform uploads the hash value of the order information to a Blockchain-20 database for storage, creating a notarized record of the order information. This locally stored order information serves as the basis for collecting payments from users. Blockchain-20 notarization of order information ensures the authenticity of order information generated by the on-chain battery swapping platform, helping to avoid disputes. Furthermore, encrypting the order information before uploading it to the Blockchain-20 database allows for automatic settlement of order amounts via smart contracts.

[0069] Specifically, a settlement smart contract is published on Blockchain 20. Users submit at least one token to the settlement smart contract's temporary storage account for registration and declare their permission for settlement. The on-chain battery swapping platform encrypts the order information using a preset key and uploads it to Blockchain 20. The settlement smart contract queries Blockchain 20, decrypts the order information, and generates transaction information matching the amount payable for the battery swap. The user's pre-submitted tokens are transferred from the temporary storage account to the on-chain battery swapping platform's account, completing the automatic payment process.

[0070] In the technical solution provided in this embodiment, the vehicle status data verification model plays a crucial role. Specifically, this embodiment provides a method for establishing a vehicle status data verification model, which includes the following steps: setting numerical filtering rules, whereby the numerical filtering rules record the value rules for the battery pack SoC, remaining battery power, trip meter, and vehicle alarm codes; vehicle status data that does not conform to the value rules fails verification.

[0071] By setting value selection rules, vehicle messages that do not conform to the rules are deleted, thereby improving the quality of vehicle messages used for testing. The value selection rules are determined based on the relationships between vehicle status data. This embodiment provides specific examples of value selection rules:

[0072] Value rule 1: The difference between the product of the battery pack SoC and the nominal battery capacity and the remaining battery capacity should be within a preset range. If the difference exceeds the preset threshold, it means that the vehicle message does not meet the value rule.

[0073] Rule 2: When the battery pack SoC is lower than the preset threshold or the remaining battery power is lower than the preset threshold, the vehicle alarm code should be the battery power alarm code. If there is no battery power alarm code, it does not meet the rule.

[0074] Value rule 3: The absolute value of the difference between the battery pack SoC and 100%, the product of the preset mileage coefficient, and the difference between the odometer reading should be within the preset range. If the difference exceeds the preset threshold, it means that the vehicle message does not conform to the value rule.

[0075] Rule 4: The absolute value of the difference between the remaining battery charge and the nominal battery charge, multiplied by the preset mileage coefficient, and the difference between the odometer reading should be within the preset range. If the difference exceeds the preset threshold, it means that the vehicle message does not conform to the rule.

[0076] The four value selection rules described above can eliminate most mismatched vehicle messages. However, this embodiment cannot exhaustively list all value selection rules, and those skilled in the art can add new value selection rules according to actual circumstances.

[0077] On the other hand, this embodiment also provides a scheme that includes exclusion rules in the vehicle status data verification model. Exclusion rules can be used alone or in conjunction with value rules as the vehicle status data verification model. When used in conjunction with value rules as the vehicle status data verification model, only vehicle messages that conform to both the value rules and the exclusion rules can be retained for testing on the on-chain battery swapping platform.

[0078] Please see the appendix Figure 2 Methods for establishing exclusion rules include:

[0079] Step B01) List the range of values ​​for the battery pack SoC, remaining battery capacity, and trip meter.

[0080] Step B02) Divide the numerical range into at least one value interval, associate interval identification code with the value interval, assign the interval identification code corresponding to the battery pack SoC, the remaining battery power and the trip meter, and the vehicle alarm code as the interval identification code.

[0081] Step B03) Establish exclusion entries. Exclusion entries record the interval identifiers that other vehicle status data cannot fall into when a vehicle status data falls into an interval identifier.

[0082] Step B04) Create exclusion entries multiple times so that the exclusion entries cover each interval identifier code of each vehicle status data.

[0083] The battery pack SoC's numerical range is [0, 100%]. This range is divided into 5 intervals, each with an associated interval identifier code, A1 to A5. In this embodiment, the battery pack's nominal capacity is 50 kWh, so the remaining battery capacity range is [0, 50] kWh. This remaining battery capacity range is divided into 5 intervals: [0, 10), [10, 20), [20, 30), [30, 40), and [40, 50], each with an associated interval identifier code, B1 to B5. The trip meter's numerical range is [0, 1000]. This range is divided into 10 intervals, each with an associated interval identifier code, C1 to C10. Vehicle alarm codes are considered as interval identifier codes, and are 9011 to 9013.

[0084] The generated exclusion entry is (A1, B5, C1, ALL), meaning that when the battery pack SoC value is in the range [0, 10%), the remaining battery charge value falls within the range [40, 50], the trip meter value falls within the range [0, 100), and regardless of whether a vehicle alarm code exists, it matches this exclusion entry. Therefore, this vehicle message should be excluded. In reality, there should also be the following exclusion entry: (A1, B2-B4, C1, ALL), meaning that when the battery pack SoC value is in the range [0, 10%), and the remaining battery charge range identifier is B2-B4, all of these should be excluded. All exclusion entries will constitute an exclusion rule.

[0085] Furthermore, several different types of SDK interface modules are established to receive vehicle messages, account information, and battery information through these interface modules.

[0086] On the other hand, this embodiment provides a computer system, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements a test data construction method for an on-chain battery swapping platform as described above.

[0087] like Figure 3 As shown, the computer system includes a processor 13, a memory 11, and a computer program 12 stored in the memory 11 and executable on the processor 13. When the processor 13 executes the computer program 12, it implements the steps in the proposal consensus execution method in the above embodiments.

[0088] Computer system 10 can be a general-purpose computer system or a special-purpose computer system. In a specific implementation, computer system 10 can be a server cluster including multiple servers. Those skilled in the art will understand that... Figure 3 This is merely an example of computer system 10 and does not constitute a limitation on computer system 10. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0089] Processor 13 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0090] In some embodiments, memory 11 may be an internal storage unit of computer system 10, such as a hard disk or RAM of computer system 10. In other embodiments, memory 11 may be an external storage device of computer system 10, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on computer system 10. Furthermore, memory 11 may include both internal storage units and external storage devices of computer system 10. Memory 11 is used to store operating system, application programs, boot loader, data, and other programs. Memory 11 may also be used to temporarily store data that has been output or will be output.

[0091] On the other hand, this embodiment provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements a test data construction method for an on-chain battery swapping platform as described above.

[0092] On the other hand, this embodiment provides a test data construction system for an on-chain battery swapping platform, used to execute the aforementioned test data construction method for an on-chain battery swapping platform. Please refer to the appendix. Figure 4The test data construction system includes a generation module 22, an upload module 21, and a download module 23. The generation module 22 randomly generates vehicle messages. The upload module 21 receives vehicle messages, account information, and battery information uploaded by the uploader or generated by the generation module 22. The vehicle message includes at least one vehicle status data. The upload module 21 uses a vehicle status data verification model to verify the vehicle message and removes vehicle messages that fail verification. The vehicle status data verification model is pre-established and stored in the upload module 21. The vehicle status data verification model verifies whether at least one vehicle status data matches each other. If they match, the verification passes; if they do not match, the verification fails. After associating the vehicle message with the uploader's account and battery information, the upload module 21 generates transaction information and uploads it to the blockchain 20 for storage. The download module 23 queries the blockchain 20, downloads the transaction information containing the vehicle message, extracts the vehicle message from the transaction information, and sends the vehicle message to the on-chain battery swapping platform to be tested. The download module 23 periodically generates reward transactions and transfers the tokens corresponding to the number of downloads to the uploader's account.

[0093] The generation module 22 randomly generates vehicle message data, and the upload module 21 receives the vehicle messages randomly generated by the generation module 22, as well as the vehicle messages uploaded by the uploader, and related account and battery information.

[0094] Upload module 21 uses a vehicle status data verification model to verify vehicle messages, discarding those that fail verification. The remaining vehicle messages are then associated with account and battery information and uploaded to the block storage. Generation module 22 has a fixed account and fictitious battery information.

[0095] Download module 23 downloads the corresponding vehicle messages from blockchain 20, thus obtaining test data that meets the testing requirements. This provides test data for the on-chain battery swapping platform, enabling the testing of the platform's business logic.

[0096] On the other hand, this embodiment also provides a scheme in which the upload module 21 includes at least one interface module. Each interface module supports different SDK types, and the uploader connects to the corresponding interface module. The uploader can manually connect to the upload module 21, specifically by providing a user-friendly interface where they manually fill in vehicle information, account information, and battery information before submitting it to the upload module 21. Alternatively, the upload module 21 can also interface with the automation system owned by the uploader to automatically upload vehicle information, account information, and battery information. Since the automation systems owned by the uploaders may use different programming languages, the upload module 21 provides SDKs in different languages ​​to interface with the automation systems of different uploaders. The upload module 21 provides upload interfaces for vehicle information, account information, and battery information. The uploader's automation system uploads data by calling these upload interfaces. By connecting with uploaders using different SDK types through the interface module, it is easier for uploaders to upload vehicle information, expanding the range of vehicle status data that the upload module 21 can receive.

[0097] The beneficial technical effects of this embodiment include: generating test data that is difficult to generate in real vehicle testing with the help of the generation module 22, making the testing of the on-chain battery swapping platform more comprehensive and ensuring the stability and reliability of the on-chain battery swapping platform; receiving vehicle status data of real vehicles uploaded by uploaders through the upload module 21, obtaining the real vehicle status, and then establishing a vehicle status data verification model based on the real vehicle status data, filtering out unreasonable vehicle status data through the vehicle status data verification model, improving the quality of test data, and helping to improve testing efficiency; storing vehicle messages through the blockchain 20, ensuring the authenticity of vehicle messages, and recording the number of times vehicle messages are used through the download module 23, and rewarding uploaders based on the number of uses, which can stimulate the enthusiasm of uploaders and upload more real vehicle data to the blockchain 20.

[0098] Example 2:

[0099] A method for constructing test data for an on-chain battery swapping platform is presented in this embodiment. Based on Embodiment 1, this embodiment proposes a new improvement to the method for establishing a vehicle state data verification model. Please refer to the appendix. Figure 5 In this embodiment, the method for establishing a vehicle status data verification model includes:

[0100] Step C01) Read at least one vehicle message and associate the verification result of the vehicle message as sample data;

[0101] Step C02) Randomly generate vehicle messages and compare them with the exclusion rules. If the message matches the exclusion entry, mark the vehicle message as failing verification. If the message does not match any exclusion entry, mark the vehicle message as passing verification.

[0102] Step C03) Incorporate the randomly generated vehicle messages after tagged into the sample data;

[0103] Step C04) Establish a neural network model. The input layer neurons of the neural network model correspond to the vehicle status data contained in the vehicle message. The output of the neural network model is the probability distribution of the verification result.

[0104] Step C05) Use sample data to train and test the neural network model until the accuracy of the neural network model reaches a preset threshold. The neural network model is then the vehicle status data verification model.

[0105] Based on Example 1, this embodiment provides a method for establishing a vehicle status data verification model when used in conjunction with exclusion rules, and provides more accurate vehicle status data verification by means of a neural network model.

[0106] A neural network model is a classification model, belonging to a type of machine learning technique. By training a neural network model on sample data, it can classify data other than the sample data. A neural network model consists of an input layer, at least one intermediate layer, and an output layer. The output layer uses the softmax function as its activation function and outputs the probability distribution of the class to which the input data belongs.

[0107] Normalized data is typically input into neural network models to facilitate faster convergence. In this embodiment, the battery pack SoC itself is normalized data. The remaining battery capacity is normalized by using the ratio of the remaining battery capacity to the nominal battery capacity. The trip meter is normalized by using the ratio of the trip meter reading to the preset maximum mileage. At least one constant value is set within the [0,1] interval to represent the vehicle alarm code, thus achieving a normalized representation of the vehicle alarm code.

[0108] The verification results of manually labeled vehicle messages are used as sample data. Manual labeling is costly and inefficient. Therefore, in step C02), vehicle messages are randomly generated. These randomly generated messages are compared with exclusion rules. Messages matching exclusion rules are marked as failing verification, while messages not matching any exclusion rules are marked as passing verification. This quickly increases the amount of sample data and reduces the workload of manual labeling. For example, if the battery pack SoC value is 5%, the remaining battery capacity is 45kWh, the trip meter value falls within 65, and there is no vehicle alarm code, then it matches an exclusion rule, and the vehicle message will be marked as failing verification. If the battery pack SoC value is 5%, the remaining battery capacity is 7kWh, the trip meter value falls within 365, and there is no vehicle alarm code, then it does not match any exclusion rules, and the vehicle message will be marked as passing verification. This method provides a large amount of sample data.

[0109] On the other hand, training the neural network model with randomly generated vehicle messages labeled by exclusion rules, and then testing it with manually labeled sample data, will yield better results.

[0110] This embodiment, building upon Embodiment 1, provides a vehicle state data verification model based on a neural network model. This model enables the rapid establishment of verification rules using sample data, eliminating the need for exhaustive selection and exclusion rules. While exhaustive exclusion rules can improve the accuracy of the neural network model in this embodiment, as long as the model passes the test with manually labeled sample data, incomplete or incorrect exclusion rules will not affect the quality of the final test data. This saves significant work on exhaustive selection and exclusion rules, improving the efficiency of test data generation.

[0111] Example 3:

[0112] A method for constructing test data for an on-chain battery swapping platform is presented in this embodiment. Based on Embodiment 1, this embodiment proposes a new improvement to the method for establishing a vehicle state data verification model. Please refer to the appendix. Figure 6 In this embodiment, the method for establishing a vehicle status data verification model includes:

[0113] Step D01) Read at least one vehicle message and associate the verification result of the vehicle message as sample data;

[0114] Step D02) Establish a neural network model. The input layer neurons of the neural network model correspond to the vehicle status data contained in the vehicle message. The output of the neural network model is the probability distribution of the verification result.

[0115] Step D03) Use sample data to train and test the neural network model until the accuracy of the neural network model reaches a preset threshold. The neural network model is then the vehicle status data verification model.

[0116] Compared to Example 2, this example specifically describes a method for establishing a vehicle status data verification model based on a neural network model without relying on exclusion rules to assist in generating sample data. In this example, all sample data is uploaded by the uploader, read in step D01), and then manually labeled to verify the results. Although the sample data used in this example has a higher acquisition cost, it has extremely high accuracy and can provide a more accurate vehicle status data verification model.

[0117] The beneficial technical effects of this embodiment include: the neural network model can quickly establish verification rules using sample data, eliminating the need for exhaustive enumeration of value selection rules and exclusion rules.

[0118] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A method for constructing test data for an on-chain battery swapping platform. Its features are, Includes the following steps: Randomly generate vehicle messages; Receive the vehicle message, account and battery information, wherein the vehicle message includes at least one vehicle status data; The vehicle status data verification model is used to verify the vehicle messages and remove vehicle messages that fail the verification. The vehicle status data verification model verifies whether at least one vehicle status data is matched. If they match, the verification passes; if they do not match, the verification fails. After associating the vehicle message with the uploader's account and battery information, transaction information is generated and uploaded to the blockchain for storage; Query the blockchain and download the transaction information containing the vehicle message; Extract the vehicle message from the downloaded transaction information and send the vehicle message to the on-chain battery swapping platform to be tested; Reward transactions are generated periodically, transferring tokens corresponding to the number of downloads to the account of the person who uploaded the download. The vehicle status data verification model also includes exclusion rules, and the methods for establishing exclusion rules include: List the numerical ranges for battery pack SoC, remaining battery capacity, and trip meter readings; The numerical range is divided into at least one value interval, and an interval identification code is associated with the value interval. The battery pack SoC, the remaining battery power and the trip meter are assigned interval identification codes corresponding to the values, and the vehicle alarm code is regarded as the interval identification code. Establish exclusion entries, which record the interval identifiers into which other vehicle status data cannot fall when a vehicle status data falls into an interval identifier code. Multiple exclusion entries are created to ensure that each exclusion entry covers every interval identifier code of each vehicle status data. Methods for establishing vehicle status data verification models include: Read at least one vehicle message and associate the verification result of the vehicle message as sample data; A vehicle message is randomly generated. The randomly generated vehicle message is compared with the exclusion rule. If it matches the exclusion entry, the vehicle message verification fails. If it does not match any of the exclusion entries, the vehicle message verification passes. The tagged vehicle messages are included in the sample data; A neural network model is established, wherein the input layer neurons of the neural network model correspond to the vehicle status data contained in the vehicle message, and the output of the neural network model is the probability distribution of the verification result; The neural network model is trained and tested using the sample data until its accuracy reaches a preset threshold. The neural network model is then used as the vehicle status data verification model.

2. The method for constructing test data for an on-chain battery swapping platform according to claim 1, characterized in that, The vehicle status data includes the battery pack SoC, remaining battery power, trip meter or vehicle alarm code. The trip meter is the mileage the vehicle has traveled this time. The battery information includes the BMU number of the vehicle corresponding to the battery pack. The upload module receives the vehicle registration information sent by the uploader. Registered vehicles are assigned a unique BMU number.

3. The method for constructing test data for an on-chain battery swapping platform according to claim 2, characterized in that, Methods for establishing vehicle status data verification models include: Set numerical filtering rules, which record the value rules for battery pack SoC, battery pack remaining power, trip meter, and vehicle alarm codes. Vehicle status data that does not conform to the value rules will fail verification.

4. A method for constructing test data for an on-chain battery swapping platform according to claim 1 or 2, characterized in that, Methods for establishing vehicle status data verification models include: Read at least one vehicle message and associate the verification result of the vehicle message as sample data; A neural network model is established, wherein the input layer neurons of the neural network model correspond to the vehicle status data contained in the vehicle message, and the output of the neural network model is the probability distribution of the verification result; The neural network model is trained and tested using the sample data until its accuracy reaches a preset threshold. The neural network model is then used as the vehicle status data verification model.

5. A method for constructing test data for an on-chain battery swapping platform according to any one of claims 1 to 3, characterized in that, Establish several interface modules for different types of SDKs, and receive vehicle messages, account and battery information through these interface modules.

6. A computer system, characterized in that, The computer system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When executed by the processor, the computer program implements a test data construction method for an on-chain battery swapping platform as described in any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements a test data construction method for an on-chain battery swapping platform as described in any one of claims 1 to 5.

8. A test data construction system for an on-chain battery swapping platform, used to execute the test data construction method for an on-chain battery swapping platform as described in any one of claims 1 to 5, characterized in that, The system includes a generation module, an upload module, and a download module. The generation module randomly generates vehicle messages. The upload module receives vehicle messages, account information, and battery information generated by the uploader. Each vehicle message includes at least one vehicle status data. The upload module uses a vehicle status data verification model to verify the vehicle messages and removes those that fail verification. The vehicle status data verification model verifies whether at least one vehicle status data matches each other. If they match, the verification passes; otherwise, the verification fails. The upload module associates the vehicle message with the corresponding uploader's account and battery information, generates transaction information, and uploads it to the blockchain for storage. The download module queries the blockchain, downloads the transaction information containing vehicle messages, extracts the vehicle messages from the transaction information, and sends the vehicle messages to the on-chain battery swapping platform to be tested. The download module periodically generates reward transactions, transferring the tokens corresponding to the number of downloads to the account of the corresponding uploader.

Images