A smart meter transmission protocol processing system and method

Abstract

The present invention discloses a smart meter transmission protocol processing system and method. The system includes a receive message queue, a send message queue, an FSM state machine service module, and a protocol message engine. The receive message queue caches messages received from a communication port, waiting for the protocol message engine to retrieve them. The send message queue caches message data processed by the protocol message engine and ready for outbound transmission, and the communication port sequentially retrieves and transmits messages from the send message queue. The FSM state machine service module provides state transition services based on a parameter state transition table in the protocol message engine, assisting the protocol message engine in completing the state transition required by the current message. The protocol message engine performs protocol analysis of the message content and, based on different parameter combinations in the message, completes the required message transition and triggers corresponding processing functions. The system framework code of the present invention is concise, stable, and has minimal redundancy.

Description

Technical Field

[0001] The present invention relates to the technical field of electric meter data transmission, and in particular to a smart electric meter transmission protocol processing system and method. Background Art

[0002] In the power industry, data processing and transmission for smart meters follows a series of transmission protocols developed by the International Electrotechnical Commission (IEC) (i.e., the IEC Telecontrol Equipment and Systems series of protocols). my country has its corresponding DL / T series of protocols. These protocols define standard operating methods for data analysis and transmission between the monitoring and remote control ends of various types of metering equipment.

[0003] Because the business data and processes that need to be processed are very complex, the specific content of the above-mentioned protocol is also very complex. Its complexity is mainly reflected in two aspects. On the one hand, the protocol data structure is complex, and on the other hand, different parameter combinations in the protocol data structure will trigger different subsequent processing processes.

[0004] Taking the IEC103 V1997 protocol as an example, its frame structure is divided into two categories: fixed frame and variable frame. We will briefly understand its complexity by taking the variable frame as an example. Figure 2 shown.

[0005] The most important data structure in the IEC protocol is the ASDU (Application Service Data Unit), which is a structure with variable length. Figure 2 On the right, the INF-Set contained within an ASDU varies depending on parameters such as Type, Fun, and INF, and manufacturers are allowed to customize its contents, resulting in numerous ASDU types. The number of ASDU types defined in the IEC 103V1997 standard alone reaches ASDU47. Furthermore, even ASDUs with the same number may contain different data sets due to different internal parameter values, leading to even more diverse INF-Set contents.

[0006] The variable ASDU frame structure described above also leads to a variety of IEC103 process triggering methods. Although IEC103V1997 defines only 13 standard commands, nearly every command triggers different data flows at the message sender based on the ASDU content returned by the message receiver. These flows may in turn trigger other different data flows based on the content returned by the message receiver. In other words, nearly every command has different specific data flows and corresponding operation processing procedures in different situations.

[0007] For example, the General Interrogation (GI) command, defined in Chapter 7.4.3 of the IEC 103 V1997 specification, begins with ASDU7. The sender initiates a general data interrogation to the monitoring device. The response data received by the monitoring device may be ASDU1, ASDU2, ASDU4, ASDU6, ASDU8, or other burst data frames. These frames trigger different data processing flows within this GI command. Therefore, the complete data flow of this command is highly variable and complex. Furthermore, even if these ASDU types have the same ID, their behavior and the meaning of the data they carry may differ in different commands.

[0008] This complex situation leads to complex computer program processes for processing smart meter protocols, especially the code implementation is very cumbersome in protocol encoding and decoding and process triggering.

[0009] The current common practice is to parse ASDU frames byte by byte according to the protocol definition during encoding and decoding. When encountering key parameters that may change the subsequent content, special judgments and process jumps are made. While this method can meet protocol processing requirements, it also leads to complex code logic and a large amount of redundant code, making debugging and continuous iteration compatible with new ASDUs (especially manufacturer-defined ASDUs) more difficult. Furthermore, handling different IEC protocol versions requires a complete code refactoring to complete protocol processing. Summary of the Invention

[0010] The present invention aims to overcome the shortcomings of the prior art and provides a system and method for processing a smart meter transmission protocol. The architecture and method mentioned in the present invention mainly focus on solving the problem of processing variable processes caused by the variable structure of the ASDU.

[0011] The object of the present invention is achieved through the following technical solutions:

[0012] A smart meter transmission protocol processing system includes a receiving message queue, a sending message queue, an FSM state machine service module and a protocol message engine;

[0013] The receiving message queue is used to cache messages received from the communication port and wait for the protocol message engine to retrieve them;

[0014] The sending message queue: the cache protocol message engine processes the message data ready for outgoing, and the communication port obtains and sends the messages from the sending message queue in sequence;

[0015] The FSM state machine service module provides state transition services according to the parameter state transition table in the protocol message engine, assisting the protocol message engine to complete the state flow required by the current message and trigger the corresponding processing function;

[0016] The protocol message engine completes the protocol analysis of the message and completes the required message flow work according to different parameter combinations in the message.

[0017] Furthermore, the protocol message engine includes a message distributor, a message parser, a message generator, a retransmission counter, a message processing callback mapping table, a key parameter decomposition tree and a parameter state transition table;

[0018] Message dispatcher: takes the message from the receiving message queue and passes it to the message parser for parsing and processing; at the same time, it puts the new message generated from the message generator after the message processing is completed into the message sending queue;

[0019] Message parser: Cooperates with the message processing callback mapping table to process messages, generates corresponding key parameter decomposition trees according to different message types, and maintains key parameters and their corresponding different values, as well as status identification information corresponding to specific values;

[0020] Message generator: uses the parameter state transition mapping table and the state migration service provided by the FSM state machine service module to drive the process flow by generating new messages required for the new state;

[0021] Resend counter: counts the number of retransmissions of each message in its active lifecycle and uses the count to determine whether to resend or interrupt the lifecycle.

[0022] Message processing callback mapping table: a processing sub-function mapping table built according to the message type defined by the protocol;

[0023] Key parameter decomposition tree: maintains the values of key parameters in each message and the status identification information corresponding to specific values;

[0024] Parameter state transition table: maps the process conversion relationship corresponding to the key parameters in each message to the state drive identifier required by the FSM state machine, and cooperates with the flow of the FSM complete processing process when the actual code is running.

[0025] A smart meter transmission protocol processing method, using a smart meter transmission protocol processing system, includes the following specific steps:

[0026] S1: Receive message: The message distributor of the protocol message engine receives the current protocol message from the receive message queue;

[0027] S2: Parsing the message: The message parser of the protocol message engine receives the message body passed from the message dispatcher, and then distributes the message structure to the corresponding processing sub-function according to the message type with the help of the message processing callback mapping table;

[0028] S3: According to the key parameters corresponding to the current message and the parameter state transition table, in cooperation with the FSM state machine service module, the parameter information of the message required for the next step is obtained, and then the corresponding message is generated through the message generator and transmitted to the message distributor for external transmission, thereby completing the message flow.

[0029] Furthermore, the step S1 also includes: S11: the message distributor of the protocol message engine checks the life cycle of the received message and performs retransmission management, and the retransmission management information is synchronized to the retransmission counter for management.

[0030] Furthermore, the step S2 further includes: S21: decomposing the message to generate a key parameter decomposition tree: performing preliminary parsing according to the frame structure defined by the protocol, maintaining the values of key parameters in each message in the current processing process and the state identification information corresponding to the specific values, thereby obtaining process flow information corresponding to various different parameter combinations;

[0031] S22: Maintain parameter state transition mapping table: map the process transition relationship generated by the key parameter decomposition tree to the state drive identifier required by the FSM state machine, and coordinate the flow of the complete FSM processing process when the actual code is running.

[0032] Furthermore, the step S3 also includes: S31: sending a message to drive the next level process: the message distributor performs life cycle management on the message received from the message generator, checks its retransmission status, synchronizes the retransmission management information to the retransmission counter for management, and then sends the checked legal message to the sending message queue for external transmission.

[0033] Beneficial effects of the present invention:

[0034] 1) Applicable to all different versions of electricity meter protocols.

[0035] 2) The message engine's key parameter decomposition tree and parameter state transition mapping table can be used to adapt any frame structure definition and its process control points, and the process flow is completed with the cooperation of the FSM state machine. The framework code is concise, stable, and has minimal redundancy. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying any creative work.

[0037] Figure 1 It is a system architecture diagram of the present invention;

[0038] Figure 2 This is the IEC103 V1997 variable frame structure diagram;

[0039] Figure 3 It is a process framework diagram of the present invention. DETAILED DESCRIPTION

[0040] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0041] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in this field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0042] The protocol processing flow of smart meters is complex, especially the code implementation in protocol encoding and decoding and process triggering is very troublesome.

[0043] The current common practice is to parse ASDU frames byte by byte according to the protocol definition during encoding and decoding. When encountering key parameters that may change the subsequent content, special judgments and process jumps are made. While this method can meet protocol processing requirements, it also leads to complex code logic and a large amount of redundant code, making debugging and continuous iteration compatible with new ASDUs (especially manufacturer-defined ASDUs) more difficult. Furthermore, handling different IEC protocol versions requires a complete code refactoring to complete protocol processing.

[0044] The present invention provides a smart meter transmission protocol processing software architecture and construction method. The architecture and method mentioned in the present invention mainly focus on solving the problem of variable process processing caused by the variable structure of ASDU. The advantages of the architecture and method mentioned in the present invention are:

[0045] 1) Applicable to all different versions of electricity meter protocols.

[0046] 2) The message engine's key parameter decomposition tree and parameter state transition mapping table can be used to adapt any frame structure definition and its process control points, and the process flow is completed with the cooperation of the FSM state machine. The framework code is concise, stable, and has minimal redundancy.

[0047] The framework of this program is as follows Figure 1 As shown, the function description of each module of the system framework is as follows:

[0048] 1) Receive message queue: Caches messages received from the communication port, waiting for the protocol message engine to retrieve them.

[0049] 2) Send message queue: The cache protocol message engine completes processing of the message data ready for outgoing, and the communication port obtains the messages from the send message queue in sequence and sends them.

[0050] 3) FSM state machine service module: provides basic state transition services based on the parameter state transition table in the protocol message engine, and assists the protocol message engine in completing the state flow required by the current message.

[0051] 4) Protocol message engine: completes the protocol analysis of the message and completes the required message flow work based on the different parameter combinations in the message. It includes the following sub-modules and data structures.

[0052] Message Dispatcher: Receives and sends messages. It is responsible for taking out messages from the receive message queue and passing them to the message parser for parsing and processing. It is also responsible for putting new messages generated from the message generator after message processing into the message sending queue. All of the above types of messages will be resent counted.

[0053] Message Parser: Defines the structure and parameters of each message according to the protocol, and processes messages in conjunction with the message processing callback mapping table. During processing, a key parameter decomposition tree is generated for each message type, maintaining key parameters, their corresponding values, and the state identifiers corresponding to specific values. When the message generator generates the next message, the key parameter decomposition tree, in conjunction with the parameter state transition mapping table, determines the message to which the message should transition under the current parameter configuration. The message generator then generates a new message to drive the process.

[0054] Message Generator: The message generator is an important module that drives the next step of the process flow. It uses the parameter state transition mapping table and cooperates with the state migration service provided by the FSM state machine service module to drive the process flow by generating new messages required for the new state.

[0055] Resend counter: counts the number of retransmissions of each message in its active life cycle. The count is configurable and determines whether to resend or interrupt its life cycle.

[0056] Message processing callback mapping table: A processing sub-function mapping table built according to the message type defined by the protocol allows the message parser to distribute a large number of messages to the corresponding processing sub-functions for processing with simple code.

[0057] Key parameter decomposition tree: The frame structure of the meter protocol, especially the ASDU, contains numerous parameters with various values. The system flow is determined by the values of key parameters among these parameters. Therefore, a key parameter decomposition tree is maintained to store the values of key parameters in each message in the current processing process and the status identification information corresponding to specific values. In this way, a simple framework code can be used to handle various parameter combinations and their corresponding process flows.

[0058] Parameter state transition table: The protocol defines the process transitions corresponding to message parameters. The key parameter decomposition tree above maintains this transition relationship. To drive the actual code process, we define a parameter state transition mapping table and maintain it during message parsing. This transition relationship is mapped to the state drive identifier required by the FSM state machine, coordinating the flow of the complete FSM processing process during actual code execution.

[0059] The steps of this program are as follows Figure 3 As shown:

[0060] S1: Receive message

[0061] The message dispatcher of the protocol message engine receives the current protocol message from the receive message queue.

[0062] S11: The message dispatcher of the protocol message engine checks the life cycle of the received message and performs retransmission management. The retransmission management information is synchronized to the retransmission counter for management.

[0063] S2: Parsing the message

[0064] The message parser of the protocol message engine receives the message body passed from the message transceiver, and then distributes the message structure to the corresponding processing sub-function according to the message type with the help of the message processing callback mapping table, avoiding the processing of various message frame structures in the main framework.

[0065] S21: Decompose the message to generate a key parameter decomposition tree

[0066] A preliminary analysis is performed according to the frame structure defined by the protocol. Since the frame structure defined by the electricity meter protocol, especially the ASDU, contains many parameters and many parameter values, the system flow is determined by the values of the key parameters among these parameters. Therefore, a key parameter decomposition tree is maintained to maintain the values of the key parameters in each message in the current processing process and the status identification information corresponding to the specific values. In this way, a simple framework code can be used to handle various parameter combinations and their corresponding process flows.

[0067] S22: Maintain parameter state transition mapping table

[0068] The protocol defines the process conversion corresponding to the message parameters. The above key parameter decomposition tree has maintained this conversion relationship. In order to drive the actual code process, we define a parameter state conversion mapping table and maintain it in the message parsing. The above conversion relationship is mapped to the state drive identifier required by the FSM state machine. When the actual code is running, it cooperates with the flow of the FSM complete processing process.

[0069] S3: Generates specific messages required for the next step in the process

[0070] Through the analysis work in the above steps, the corresponding parameters and state transition relationships have been determined, and the next step / next set of message structures required for their processes have also been determined. With the help of the state flow function of the FSM state machine service module, the framework generates the corresponding message through the message generator and transmits it to the message transceiver.

[0071] S31: Send a message to drive the next level process

[0072] The message transceiver manages the lifecycle of messages received from the message generator and checks their retransmission status. The retransmission management information is synchronized to the retransmission counter for management.

[0073] The checked legal messages are then sent to the outgoing message queue for external transmission.

[0074] The foregoing description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the form disclosed herein and should not be construed as excluding other embodiments. Various other combinations, modifications, and environments are possible, and modifications can be made within the scope of the concepts described herein through the above teachings or through techniques or knowledge in the relevant fields. Modifications and variations made by those skilled in the art without departing from the spirit and scope of the present invention are intended to be within the scope of the appended claims.

Claims

1. A smart meter transmission protocol processing system, characterized in that: Includes receiving message queue, sending message queue, FSM state machine service module and protocol message engine; The receiving message queue is used to cache messages received from the communication port and wait for the protocol message engine to retrieve them; The sending message queue: the cache protocol message engine processes the message data ready for outgoing, and the communication port sequentially obtains and sends messages from the sending message queue; The FSM state machine service module provides state transition services according to the parameter state transition table in the protocol message engine, and assists the protocol message engine in completing the state flow required by the current message; The protocol message engine: completes the protocol analysis of the message, and completes the required message flow and triggers the corresponding processing function according to the different parameter combinations in the message; The protocol message engine includes a message distributor, a message parser, a message generator, a retransmission counter, a message processing callback mapping table, a key parameter decomposition tree and a parameter state transition table; Message dispatcher: takes the message from the receiving message queue and passes it to the message parser for parsing and processing; at the same time, it puts the new message generated from the message generator after the message processing is completed into the message sending queue; Message parser: Cooperates with the message processing callback mapping table to process messages, generates corresponding key parameter decomposition trees according to different message types, and maintains key parameters and their corresponding different values, as well as status identification information corresponding to specific values; Message generator: uses the parameter state transition mapping table and the state migration service provided by the FSM state machine service module to drive the process flow by generating new messages required for the new state; Resend counter: counts the number of retransmissions of each message in its active lifecycle and uses the count to determine whether to resend or interrupt the lifecycle. Message processing callback mapping table: a processing sub-function mapping table built according to the message type defined by the protocol; Key parameter decomposition tree: maintains the values of key parameters in each message and the status identification information corresponding to specific values; Parameter state transition table: maps the process conversion relationships corresponding to the key parameters in each message to the state drive identifiers required by the FSM state machine, and cooperates with the FSM to complete the flow of the processing process when the actual code is running.

2. A method for processing a smart meter transmission protocol, using a smart meter transmission protocol processing system according to claim 1, characterized in that: The specific steps include: S1: Receive message: The message distributor of the protocol message engine receives the current protocol message from the receive message queue; S2: Parsing the message: The message parser of the protocol message engine receives the message body passed from the message dispatcher, and then distributes the message structure to the corresponding processing sub-function according to the message type with the help of the message processing callback mapping table; S3: Based on the key parameters of the current message, the parameter state transition table is compared with the FSM state machine service module to obtain the parameter information of the next message. The message generator then generates the corresponding message and transmits it to the message distributor for external transmission, thus completing the message flow. The step S2 further includes: S21: Decompose the message to generate a key parameter decomposition tree: Perform preliminary analysis according to the frame structure defined by the protocol, maintain the values of key parameters in each message in the current processing process and the status identification information corresponding to specific values, so as to obtain the process flow information corresponding to various parameter combinations; S22: Maintain parameter state transition mapping table: map the process transition relationship generated by the key parameter decomposition tree to the state drive identifier required by the FSM state machine, and cooperate with the FSM to complete the flow of the processing process when the actual code is running.

3. A smart meter transmission protocol processing method according to claim 2, characterized in that: The step S1 also includes: S11: the message distributor of the protocol message engine checks the life cycle of the received message and performs retransmission management, and the retransmission management information is synchronized to the retransmission counter for management.

4. A smart meter transmission protocol processing method according to claim 2, characterized in that: The step S3 also includes: S31: sending a message to drive the next level process: the message distributor performs life cycle management on the message received from the message generator, checks its retransmission status, synchronizes the retransmission management information to the retransmission counter for management, and then sends the checked legal message to the sending message queue for external transmission.

Images