A communication method for formation and component distribution equipment
By creating high-reliability and low-reliability message sending queues in the fractionation capacity device, the problems of data loss and resource consumption in the communication of the fractionation capacity device are solved, and higher communication reliability and resource utilization efficiency are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- FUJIAN NEBULA ELECTRONICS CO LTD
- Filing Date
- 2023-03-28
- Publication Date
- 2026-06-26
Smart Images
Figure CN116521391B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of formulation and capacity technology, and in particular to a communication method for a formulation and capacity device. Background Technology
[0002] After the battery cells are manufactured, they need to be formed and tested using a formation and capacity testing device. Formation is the initial charge and discharge of the battery cells to activate the internal chemical substances. Capacity testing is the sorting of the battery cells by capacity. During the formation and capacity testing process, each formation and capacity testing device (equivalent to a mid-level computer) needs to interact with the host computer to exchange business messages. The message types of business messages include at least real-time UI data, security data, instruction data, fan data, and equipment update data.
[0003] The host computer and the intermediate computer communicate using gRPC. Existing gRPC handlers use different processing methods for different message types, but the reliability requirements for different message types are not the same, leading to the following problems:
[0004] For some business messages, such as device update data, data already stored in a temporary queue will be immediately cleared when a communication failure occurs, while data in the global queue will not be cleared. On the one hand, device update data is data with high reliability requirements, and if the communication failure is only short-lived, the data should not be lost. However, the immediate clearing of data stored in the temporary queue when a communication failure occurs will cause data loss and affect reliability. On the other hand, if data in the global queue is not deleted when a communication failure occurs, it may accumulate and cause excessive consumption of memory resources if the communication failure lasts for a long time.
[0005] For some business messages, such as UI and security data, when new data arrives, the data in the global queue is cleared in the data acquisition thread. Although this can prevent the data from accumulating more and more when communication failures occur, data may be lost in short-term communication failures, or even when the communication volume is large and the network latency is long, which may affect reliability. For example, security data should not be lost during normal communication and short-term communication failures.
[0006] Therefore, how to provide a communication method for formation and capacity testing devices to improve communication reliability and reduce resource consumption has become an urgent technical problem to be solved. Summary of the Invention
[0007] The technical problem to be solved by the present invention is to provide a communication method for a formation and capacity testing device, thereby improving the communication reliability of the formation and capacity testing device and reducing resource consumption.
[0008] This invention is implemented as follows: a communication method for a batch capacity-container device, comprising the following steps:
[0009] Step S10: The capacity-deploying device creates a first message sending queue and a second message sending queue, sets a duration threshold and a reliability lookup table;
[0010] Step S20: The data collection module of the formation and capacity testing device acquires business data and transmits the business data to the gRPC message construction module of the formation and capacity testing device.
[0011] Step S30: The gRPC message construction module converts the business data into gRPC messages, and encapsulates the gRPC messages into Pack class objects based on template classes and virtual functions;
[0012] Step S40: After the gRPC message construction module verifies the reliability of the business data based on the reliability lookup table, it pushes the Pack class object to the first message sending queue or the second message sending queue.
[0013] Step S50: The gRPC message sending module of the formation and capacity testing device performs communication verification with the host computer and generates a communication verification result;
[0014] In step S60, the gRPC message sending module, based on the communication verification result, clears the Pack class objects stored in the first message sending queue and the second message sending queue, or parses the Pack class objects to obtain gRPC messages and sends them to the host computer.
[0015] Furthermore, in step S10, the first message sending queue is used to store Pack class objects for high-reliability service data; the second message sending queue is used to store Pack class objects for low-reliability service data.
[0016] The duration threshold is used to periodically clean up Pack-type objects stored in the first message sending queue when communication is abnormal; the reliability lookup table stores a one-to-one correspondence between data types and reliability.
[0017] Further, step S20 specifically includes:
[0018] The data collection module of the batch capacity device periodically obtains business data from shared memory or from the listening socket for the corresponding thread, and transmits the business data to the gRPC message construction module of the batch capacity device in real time.
[0019] Further, step S30 specifically includes:
[0020] The gRPC message construction module converts the business data into corresponding gRPC messages based on the data type, and encapsulates the gRPC messages into Pack class objects carrying send interface functions based on template classes and virtual functions.
[0021] Further, step S40 specifically includes:
[0022] Based on the reliability lookup table and the data type of the business data, the gRPC message construction module verifies the reliability of the business data. If the reliability is high, the corresponding Pack class object is pushed to the first message sending queue, and the gRPC message sending module of the capacity-sharing device is woken up. If the reliability is low, the corresponding Pack class object is pushed to the second message sending queue, and the gRPC message sending module of the capacity-sharing device is woken up.
[0023] Further, step S50 specifically includes:
[0024] After the gRPC message sending module of the capacity forming device is woken up, it performs a communication verification with the host computer to determine whether communication can be carried out. If it can, a communication verification result indicating normal communication is generated; if it cannot, a communication verification result indicating abnormal communication is generated.
[0025] Further, step S60 specifically includes:
[0026] Step S61: The gRPC message sending module parses the communication verification result. If the communication is normal, proceed to step S62; if the communication is abnormal, proceed to step S63.
[0027] Step S62: The gRPC message sending module sequentially obtains Pack class objects from the first message sending queue or the second message sending queue, parses the Pack class objects in real time to obtain gRPC messages and corresponding sending interface functions, and sends the gRPC messages to the host computer in real time through the sending interface functions.
[0028] Step S63: The gRPC message sending module immediately clears the Pack class object stored in the second message sending queue and determines whether the communication abnormality time exceeds the duration threshold. If yes, the Pack class object stored in the first message sending queue is cleared; otherwise, proceed to step S64.
[0029] Step S64: The gRPC message sending module determines whether the communication anomaly has been recovered within the specified time threshold. If yes, proceed to step S62; otherwise, proceed to step S63.
[0030] Furthermore, the gRPC message construction module and the gRPC message sending module run through different threads.
[0031] Furthermore, when the gRPC message sending module is idle, it sleeps on a condition variable.
[0032] Furthermore, the gRPC message construction module and the gRPC message sending module are synchronized using condition variables and mutexes.
[0033] The advantages of this invention are:
[0034] By creating a first message sending queue and a second message sending queue, the first message sending queue is used to store Pack class objects for high-reliability business data, and the second message sending queue is used to store Pack class objects for low-reliability business data. When communication between the fragmentation and capacity-sharing device and the host computer fails, the Pack class objects stored in the second message sending queue are immediately cleared, while the Pack class objects stored in the first message sending queue are retained until a set time threshold is reached. After the time threshold is exceeded, the Pack class objects stored in the first message sending queue are also cleared. In other words, business data with different reliability is processed in a hierarchical manner, decoupling the handling method of communication failure from reliability (data type), avoiding the loss of important data, and avoiding excessive consumption of memory resources. Ultimately, this greatly improves the communication reliability of the fragmentation and capacity-sharing device and greatly reduces resource consumption. Attached Figure Description
[0035] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0036] Figure 1 This is a flowchart of a communication method for a batching and capacity-maintaining device according to the present invention.
[0037] Figure 2 This is a timing diagram of the high-reliability service data transmission of the present invention.
[0038] Figure 3 This is a schematic diagram of the hardware architecture of the present invention. Detailed Implementation
[0039] The technical solution in this application embodiment has the following general idea: a first message sending queue for storing high-reliability Pack class objects and a second message sending queue for storing low-reliability Pack class objects are created. When communication is abnormal, the second message sending queue is immediately cleared. After the time threshold is exceeded, the first message sending queue is also cleared. Service data with different reliability is processed in a hierarchical manner to avoid losing important data and to avoid consuming too much memory resources, thereby improving the communication reliability of the fractionation and capacity-saving device and reducing resource consumption.
[0040] Please refer to Figures 1 to 3 As shown, a preferred embodiment of the communication method for a batching and capacity-building device according to the present invention includes the following steps:
[0041] Step S10: The capacity-deploying device creates a first message sending queue and a second message sending queue, sets a duration threshold and a reliability lookup table;
[0042] Step S20: The data collection module of the formation and capacity testing device acquires business data and transmits the business data to the gRPC message construction module of the formation and capacity testing device.
[0043] Step S30: The gRPC message construction module converts the business data into gRPC messages, and encapsulates the gRPC messages into Pack class objects based on template classes and virtual functions;
[0044] Step S40: After the gRPC message construction module verifies the reliability of the business data based on the reliability lookup table, it pushes the Pack class object to the first message sending queue or the second message sending queue.
[0045] Step S50: The gRPC message sending module of the formation and capacity testing device performs communication verification with the host computer and generates a communication verification result;
[0046] In step S60, the gRPC message sending module, based on the communication verification result, clears the Pack class objects stored in the first message sending queue and the second message sending queue, or parses the Pack class objects to obtain gRPC messages and sends them to the host computer.
[0047] This invention improves scalability because when adding new data types, there's no need to add communication exception handling code for new business data. High-reliability business data (Pack objects) can be directly pushed into the first message sending queue, and low-reliability business data (Pack objects) can be pushed into the second message sending queue. On the other hand, it improves reliability and reduces unnecessary memory resource consumption. For high-reliability business data, it won't be deleted if a communication exception occurs, as long as the exception duration doesn't exceed a time threshold. For low-reliability business data, it's directly deleted upon communication exception, reducing resource consumption.
[0048] In step S10, the first message sending queue is used to store Pack class objects of high-reliability business data; the second message sending queue is used to store Pack class objects of low-reliability business data; both the first message sending queue and the second message sending queue are global message sending queues.
[0049] The duration threshold is used to periodically clean up Pack-type objects stored in the first message sending queue when communication is abnormal; the reliability lookup table stores a one-to-one correspondence between data types and reliability.
[0050] Step S20 specifically involves:
[0051] The data collection module of the fragmentation capacity device periodically obtains business data from shared memory or from the listening socket for the corresponding thread, and transmits the business data to the gRPC message construction module of the fragmentation capacity device in real time, that is, the business data is used as a parameter to call the interface function of the gRPC message construction module.
[0052] Step S30 specifically involves:
[0053] The gRPC message construction module converts the business data into corresponding gRPC messages based on the data type, and encapsulates the gRPC messages into Pack class objects carrying send interface functions based on template classes and virtual functions.
[0054] Since different types of gRPC messages correspond to different types of sending interface functions, they cannot normally be directly placed in the same message sending queue. A message sending queue requires each element to be of the same type. Therefore, it is necessary to encapsulate different types of gRPC messages and their corresponding sending interface functions. This invention combines template classes and virtual functions to encapsulate gRPC messages and sending interface functions into a Pack class object.
[0055] The Pack class object internally contains a pointer to the abstract base class BaseStore, which defines virtual functions for sending gRPC messages. The Store class is a subclass of BaseStore, implementing the virtual functions used by BaseStore for sending gRPC messages. The Store class also stores pointers to the gRPC message data and the sending function. The Store class is a template class, which can automatically adapt to the diversity of gRPC message types and their corresponding sending functions. When adding a new gRPC message type, it is not necessary to add a subclass to encapsulate the new message type.
[0056] Step S40 specifically involves:
[0057] Based on the reliability lookup table and the data type of the business data, the gRPC message construction module verifies the reliability of the business data. If the reliability is high, the corresponding Pack class object is pushed to the first message sending queue, and the gRPC message sending module of the capacity-sharing device is woken up. If the reliability is low, the corresponding Pack class object is pushed to the second message sending queue, and the gRPC message sending module of the capacity-sharing device is woken up.
[0058] Step S50 specifically involves:
[0059] After the gRPC message sending module of the capacity forming device is woken up, it performs a communication verification with the host computer to determine whether communication can be established. If communication is successful, a communication verification result indicating normal communication is generated; otherwise, a communication verification result indicating abnormal communication is generated. In practice, a preset number of communication verifications can be performed consecutively. If all verifications fail, a communication verification result indicating abnormal communication is generated.
[0060] Step S60 specifically includes:
[0061] Step S61: The gRPC message sending module parses the communication verification result. If the communication is normal, proceed to step S62; if the communication is abnormal, proceed to step S63.
[0062] Step S62: The gRPC message sending module sequentially obtains Pack class objects from the first message sending queue or the second message sending queue, parses the Pack class objects in real time to obtain gRPC messages and corresponding sending interface functions, and sends the gRPC messages to the host computer in real time through the sending interface functions.
[0063] Step S63: The gRPC message sending module immediately clears the Pack class object stored in the second message sending queue and determines whether the communication abnormality time exceeds the duration threshold. If yes, the Pack class object stored in the first message sending queue is cleared; otherwise, proceed to step S64.
[0064] Step S64: The gRPC message sending module determines whether the communication anomaly has been recovered within the specified time threshold. If yes, proceed to step S62; otherwise, proceed to step S63.
[0065] In practice, the gRPC message sending module can cache the Pack class objects stored in the first message sending queue and the second message sending queue in a local temporary queue. When it is necessary to clear the data in the first message sending queue or the second message sending queue, the corresponding data is cleared from the local temporary queue.
[0066] The gRPC message construction module and the gRPC message sending module run in different threads. By separating the gRPC message construction module and the gRPC message sending module, when the message fields change, only the gRPC message construction module needs to be updated, which greatly improves scalability.
[0067] When the gRPC message sending module is idle, it sleeps on a condition variable.
[0068] The gRPC message construction module and the gRPC message sending module are synchronized using condition variables and mutexes.
[0069] In summary, the advantages of this invention are as follows:
[0070] By creating a first message sending queue and a second message sending queue, the first message sending queue is used to store Pack class objects for high-reliability business data, and the second message sending queue is used to store Pack class objects for low-reliability business data. When communication between the fragmentation and capacity-sharing device and the host computer fails, the Pack class objects stored in the second message sending queue are immediately cleared, while the Pack class objects stored in the first message sending queue are retained until a set time threshold is reached. After the time threshold is exceeded, the Pack class objects stored in the first message sending queue are also cleared. In other words, business data with different reliability is processed in a hierarchical manner, decoupling the handling method of communication failure from reliability (data type), avoiding the loss of important data, and avoiding excessive consumption of memory resources. Ultimately, this greatly improves the communication reliability of the fragmentation and capacity-sharing device and greatly reduces resource consumption.
[0071] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.
Claims
1. A communication method for a batching and capacity-building device, characterized in that: Includes the following steps: Step S10: The capacity-deploying device creates a first message sending queue and a second message sending queue, sets a duration threshold and a reliability lookup table; Step S20: The data collection module of the formation and capacity testing device acquires business data and transmits the business data to the gRPC message construction module of the formation and capacity testing device. Step S30: The gRPC message construction module converts the business data into gRPC messages, and encapsulates the gRPC messages into Pack class objects based on template classes and virtual functions; Step S40: After the gRPC message construction module verifies the reliability of the business data based on the reliability lookup table, it pushes the Pack class object to the first message sending queue or the second message sending queue. Step S50: The gRPC message sending module of the formation and capacity testing device performs communication verification with the host computer and generates a communication verification result; In step S60, the gRPC message sending module, based on the communication verification result, clears the Pack class objects stored in the first message sending queue and the second message sending queue, or parses the Pack class objects to obtain gRPC messages and sends them to the host computer.
2. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: In step S10, the first message sending queue is used to store Pack class objects of high-reliability service data; the second message sending queue is used to store Pack class objects of low-reliability service data. The duration threshold is used to periodically clean up Pack-type objects stored in the first message sending queue when communication is abnormal; the reliability lookup table stores a one-to-one correspondence between data types and reliability.
3. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: Step S20 specifically involves: The data collection module of the batch capacity device periodically obtains business data from shared memory or from the listening socket for the corresponding thread, and transmits the business data to the gRPC message construction module of the batch capacity device in real time.
4. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: Step S30 specifically involves: The gRPC message construction module converts the business data into corresponding gRPC messages based on the data type, and encapsulates the gRPC messages into Pack class objects carrying send interface functions based on template classes and virtual functions.
5. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: Step S40 specifically involves: Based on the reliability lookup table and the data type of the business data, the gRPC message construction module verifies the reliability of the business data. If the reliability is high, the corresponding Pack class object is pushed to the first message sending queue, and the gRPC message sending module of the capacity-breaking device is woken up. If the reliability is low, the corresponding Pack class object is pushed to the second message sending queue, and the gRPC message sending module of the capacity-deploying device is woken up.
6. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: Step S50 specifically involves: After the gRPC message sending module of the capacity forming device is woken up, it performs a communication verification with the host computer to determine whether communication can be carried out. If it can, a communication verification result indicating normal communication is generated; if it cannot, a communication verification result indicating abnormal communication is generated.
7. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: Step S60 specifically includes: Step S61: The gRPC message sending module parses the communication verification result. If the communication is normal, proceed to step S62; if the communication is abnormal, proceed to step S63. Step S62: The gRPC message sending module sequentially obtains Pack class objects from the first message sending queue or the second message sending queue, parses the Pack class objects in real time to obtain gRPC messages and corresponding sending interface functions, and sends the gRPC messages to the host computer in real time through the sending interface functions. Step S63: The gRPC message sending module immediately clears the Pack class object stored in the second message sending queue and determines whether the communication abnormality time exceeds the duration threshold. If yes, the Pack class object stored in the first message sending queue is cleared; otherwise, proceed to step S64. Step S64: The gRPC message sending module determines whether the communication anomaly has been recovered within the specified time threshold. If yes, proceed to step S62; otherwise, proceed to step S63.
8. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: The gRPC message construction module and the gRPC message sending module run in different threads.
9. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: When the gRPC message sending module is idle, it sleeps on a condition variable.
10. The communication method for a formation and capacity testing device as described in claim 1, characterized in that: The gRPC message construction module and the gRPC message sending module are synchronized using condition variables and mutexes.