A workflow-based implementation method for IEC104 communication protocol

Abstract

The present invention discloses a workflow-based IEC104 communication protocol implementation method, which belongs to the field of electric power communication technology. The method includes initialization, link management, service analysis, timing scheduling, message reception, message sending, service response and status recovery. The method solves the technical problems of using a configurable workflow engine to dynamically analyze and decouple various IEC104 ASDUs from services, and integrates intelligent reconnection and structured log push in a modular layered architecture. The present invention adopts modular division, single decoupling of module responsibilities such as link management, timing scheduling, message sending and receiving, service analysis, and status recovery, unified log queue push, greatly improving system observability, and adopting an exponential backoff strategy combined with link monitoring to achieve intelligent reconnection, taking into account both timeliness and resource conservation.

Description

Technical Field

[0001] The present invention belongs to the technical field of power communication, and in particular relates to a workflow-based IEC104 communication protocol implementation method. Background Art

[0002] In existing industrial automation and power monitoring systems, the IEC104 communication protocol is generally implemented using a process-oriented state machine or hard-coded callback method, which has the following shortcomings:

[0003] The protocol layer and the business layer are highly coupled. Modifying or extending a certain ASDU type often requires changing a large amount of code, resulting in poor maintainability.

[0004] Logs are mostly scattered printf / debugging statements, lacking unified structured push and front-end linkage, making debugging difficult and observability weak.

[0005] The reconnection strategy is mostly "fixed interval retry", which cannot be dynamically adjusted according to the network status, easily causing network jitter or resource waste, and insufficient fault tolerance. Summary of the Invention

[0006] The purpose of the present invention is to provide a workflow-based IEC104 communication protocol implementation method, which solves the technical problems of dynamically parsing and decoupling various IEC104 ASDUs using a configurable workflow engine, and integrating intelligent reconnection and structured log push in a modular layered architecture.

[0007] To achieve the above object, the present invention adopts the following technical solutions:

[0008] A workflow-based IEC104 communication protocol implementation method comprises the following steps:

[0009] Step 1: Initialization phase: The initialization module loads communication configuration parameters, creates a communication channel, registers scheduled tasks, initializes link status and counters, and establishes a logging system.

[0010] Step 2: Link management phase: The link management module establishes a TCP communication link, activates scheduled tasks, parses slave confirmation messages, maintains link heartbeat detection, and dynamically updates communication sequence numbers.

[0011] Step 3: During the service parsing phase, the service parsing module parses the ASDU type identifier of the received frame, executes the workflow, generates structured data based on the type matching parsing template, performs data push and instruction legitimacy verification, and generates and outputs log entries.

[0012] In step 4, the timer scheduling module activates periodic tasks based on the link status, routes event processing functions according to the counter ID, adaptively calculates the backoff delay based on the link quality prediction and anomaly detection mechanism, implements self-optimizing reconnection control, generates control command messages, and records them in logs.

[0013] Step 5: During the message reception phase, the message reception and processing module receives the byte stream, divides the valid frames into I-frames, S-frames, and U-frames through the synchronous state machine, and generates parsed logs that are pushed to the log queue.

[0014] Step 6: During the message sending phase, the message sending and buffering module assembles and sends the message according to the IEC104 protocol, manages the sending buffer and the timeout retransmission mechanism;

[0015] Step 7: In the service response phase, the service processing and response modules concurrently process the ASDU task object, generate feedback frames, and generate full-process logs.

[0016] Step 8: During the state recovery phase, the sending state recovery module implements a backoff and retransmission strategy for failed messages, triggers a disconnected link reconnection, and restores communication, generating a retry log.

[0017] Preferably, when executing step 1, the specific steps executed by the initialization module are as follows:

[0018] Step 1-1: Load the configuration file containing the target address, ASDU address, data start address and time parameters;

[0019] Step 1-2: Create a TCP communication channel object with a connection status flag;

[0020] Steps 1-3: Register scheduled tasks including heartbeat detection, confirmation timeout, and automatic reconnection;

[0021] Step 1-4: Initialize the link status to disconnected and clear the communication sequence number;

[0022] Steps 1-5: Build a log queue system that is linked to the visualization module.

[0023] Preferably, when executing step 2, the link management module executes the following steps:

[0024] Step 2-1: Initiate a TCP connection based on the configuration parameters and update the connection status flag;

[0025] Step 2-2: After the link is established, activate the scheduled tasks related to link maintenance;

[0026] Step 2-3: Send a link start frame and parse the slave station confirmation message;

[0027] Step 2-4: Periodically maintain heartbeat detection and update the communication sequence number.

[0028] Preferably, when executing step 3, the execution steps of the business analysis module are as follows:

[0029] Step 3-1: Extract the ASDU type identifier of the received I frame and match the parsing process template according to the ASDU type identifier;

[0030] Step 3-2: Trigger the parsing workflow based on the ASDU type identifier and execute the processing flow of field extraction, value conversion, quality verification and time labeling in sequence according to the logical node;

[0031] Step 3-3: Encapsulate telemetry data and telesignaling data to obtain standardized objects, and asynchronously push the standardized objects to the monitoring system;

[0032] Step 3-4: Verify the legitimacy of the remote control command based on the control records cached in the send buffer. If the verification is passed, generate an execution signal based on the content of the remote control command, record the operation trajectory, and generate an operation log;

[0033] Step 3-5: Build a time series queue for sequential event data and track the operation link for remote control instruction data;

[0034] Steps 3-6: Generate structured log entries containing information body address, processing status, and time tags, and synchronize the log entries to the log library, visualization platform, and alarm system.

[0035] Preferably, when executing step 4, the timer scheduling module executes the following steps:

[0036] Step 4-1: Obtain the connection status flag sent by the link management module in real time. When the link is successfully connected, activate the three pre-registered timed tasks and start the periodic timer;

[0037] Step 4-2: Routing to the corresponding processing according to the counter ID, including:

[0038] The connection check task triggers the reconnection process;

[0039] The time synchronization task triggers the generation of calibration commands;

[0040] The general summoning task triggers the generation of summoning command processing;

[0041] The power call task triggers the processing according to the configured interval;

[0042] Step 4-3: For any timed event or external "disconnection" signal, obtain the current connection status flag and the most recent heartbeat confirmation time; if the connection status flag is "disconnected" or the heartbeat confirmation timeout, use the exponential backoff algorithm to generate a reconnection delay and output a reconnection request signal after the delay; the reconnection request signal includes the delay time and the number of reconnections;

[0043] Step 4-4: Each time a timed event is triggered, the time synchronization counter and the total call counter are decremented respectively. When the time synchronization counter or the total call counter returns to zero, the initial value is reset and the corresponding command is triggered;

[0044] Step 4-5: Get the trigger command signal of each task, fill in the ASDU address, function code and timestamp for the trigger command, generate the control message and output it;

[0045] Steps 4-6: Record the metadata and execution results of the control message, generate a formatted log and push it to the log queue.

[0046] Preferably, when executing step 4-3, the following steps are specifically included:

[0047] Step 4-3-1: During each heartbeat transmission and confirmation process, a sliding window is maintained. The data in the sliding window is used to calculate the heartbeat success rate, and then the heartbeat quality is calculated. The heartbeat quality is used as an indicator of link quality.

[0048] The formula for calculating the heartbeat success rate is as follows:

[0049] ;

[0050] in, Indicates that the i-th heartbeat confirms the receipt of the response, Indicates that the i-th heartbeat timed out without receiving a response; It is expressed as the heartbeat success rate at the current moment, ; N is the size of the sliding window, t represents the time;

[0051] Step 4-3-2: Predict the link quality according to the following formula:

[0052] ;

[0053] in, is the predicted link quality indicator, is the smoothing factor, The value ranges from 0.2 to 0.5. Indicates the link quality indicator predicted at the previous moment, Initialized to 1;

[0054] Step 4-3-3: Based on the predicted link quality , dynamically adjust the reconnection delay , the specific formula is as follows:

[0055] ;

[0056] in, is the preset basic reconnection delay, is the adjustment factor to control the backoff increase;

[0057] Step 4-3-4: If If the heartbeat value is lower than the preset threshold of 0.3 for more than 5 times, the link is judged to be abnormal and a reconnection signal is triggered immediately without waiting for normal backoff. Otherwise, the reconnection delay is used. After the delay is completed, a reconnection request signal is output.

[0058] Preferably, when executing step 5, the message receiving and processing module executes the following steps:

[0059] Step 5-1: Read the newly arrived byte stream from the TCP communication channel, append it to the receive buffer, update the available byte length of the receive buffer, and prepare for synchronization and segmentation;

[0060] Step 5-2: Establish a semi-packet synchronization state machine and split the byte stream, specifically:

[0061] State WAIT_HEAD, waiting for the frame header:

[0062] Search for the first 0x68 bytes in the buffer. If found, switch the state to WAIT_LENGTH, otherwise discard one byte and continue.

[0063] Status WAIT_LENGTH, that is, the waiting length field:

[0064] Ensure the buffer length is ≥ 2 and read the second byte L as the APDU length;

[0065] Calculate the full frame length N=L+2 and switch to WAIT_FULL_PACKET;

[0066] If the buffer is less than two bytes, pause segmentation and wait for more data;

[0067] State WAIT_FULL_PACKET, waiting for a complete message:

[0068] If the available bytes in the buffer are ≥ N, extract the first N bytes as a complete frame and return to WAIT_HEAD;

[0069] Otherwise, pause the splitting, keep the existing buffer, and wait for new data to arrive;

[0070] State machine output: Whenever the state machine extracts a complete frame, it is passed to the subsequent steps for format verification and classification processing;

[0071] Step 5-3: Verify each extracted complete frame, including whether the start character is still 0x68, whether the length field L is consistent with the actual number of bytes N-2, and whether the total number of bytes meets the minimum message length requirement;

[0072] If the verification fails, the frame is discarded and a "discard log" is recorded; if the verification passes, it is considered a "qualified frame" and proceeds to step 5-4:

[0073] Step 5-4: Extract the control bit from the control field byte of the qualified frame and determine the frame type:

[0074] For I frames, the ASDU is output and handed over to the service analysis module; for S frames or U frames, the link control information is output and handed over to the link management module. The link control information includes the confirmation sequence number or the control command flag;

[0075] Step 5-5: For the I frame, the byte block of the ASDU is placed into the input queue of the service parsing module for deep parsing and service distribution based on the type identifier.

[0076] Step 5-6: For the S frame, extract the latest confirmation sequence number and notify the message sending and buffering module to release the confirmed sending record;

[0077] Step 5-7: For the U frame, parse the start command, stop command or test command, and update the connection status or heartbeat timing of the link management module;

[0078] Steps 5-8: For each processed frame, format it into a structured log entry according to the "frame type", "sequence number", and "parsing result" fields, and push the log to the log queue;

[0079] Step 5-9: When any state machine stops and fails to extract the complete message, the unparsed half-packet bytes in the buffer are retained;

[0080] If a complete frame cannot be formed after consecutive timeouts (within the configured threshold), perform the following steps:

[0081] Step 5-9-1: Find the next legal start character 0x68 and discard the leading garbage data;

[0082] Step 5-9-2: Keep the tail bytes of the half packet to ensure that the subsequent splicing can continue;

[0083] Step 5-9-3: If the buffer backlog is too large or exceeds the maximum timeout period, the buffer is cleared and a "receive timeout" alarm is generated.

[0084] Preferably, when executing step 6, the message sending and caching module specifically performs the following steps:

[0085] Step 6-1: Receive a sending instruction and parse the message type, which includes a time synchronization request, a general call request, a power call request, and a link start request;

[0086] Step 6-2: Assemble the link layer frame header, length field, control field and ASDU data area according to the IEC104 protocol, insert the current timestamp or function code, and generate a formatted message byte stream;

[0087] Step 6-3: Write the message byte stream into the TCP send buffer, perform the send operation, and return the write result;

[0088] Step 6-4: Integrate the message content and sending results into a log record item, and push the log message to the log queue;

[0089] Step 6-5: Encapsulate a sending record object and store it in a sending history queue. The sending record object includes frame content, sending time, number of retransmissions, and sequence number.

[0090] Step 6-6: Set the confirmation timeout threshold and start the monitoring process to track the confirmation status of the records to be confirmed;

[0091] Step 6-7: When the number of retransmissions is within the limit, retransmission is performed. When the threshold is reached, the disconnection reconnection is triggered and the pending confirmation record is cleared.

[0092] Preferably, when executing step 7, the business processing and response module executes the following steps:

[0093] Step 7-1: Receive an ASDU task object and store it in a concurrent task queue. The ASDU task object includes a type identifier, an information body address, a data value, and a time tag.

[0094] Step 7-2: Parse the task content through concurrent processing and perform the following multi-type processing:

[0095] For remote control tasks, a two-stage status verification process is performed;

[0096] For remote control tasks, calculate the target setting value;

[0097] For telemetry tasks or telesignaling tasks, update the equipment status or historical records;

[0098] For sequential events, generate time-series records;

[0099] Step 7-3: Obtain the processing result of step 7-2 and generate a control feedback frame. The control feedback frame selects the format of U frame or I frame according to the execution phase flag and fills the corresponding control field and ASDU field.

[0100] Step 7-4: Push the control feedback frame into the transmission queue of the link management module for transmission, and update the link sequence number and confirmation status;

[0101] Step 7-5: Extract the final status, value, or event record from the business processing result object and asynchronously push it to the monitoring system or database through the message queue for display or storage;

[0102] Step 7-6: Retrieve the task's original input, processing stage, feedback frame content, and execution result status, summarize them into log entries, distinguish between three types of information: received tasks, execution results, and feedback frames, and push them to the log queue.

[0103] Preferably, when executing step 8, the execution steps of the sending state recovery module are as follows:

[0104] Step 8-1: Receive the failed message, extract the sequence number of the failed message, construct a retry record object containing the message byte stream, sequence number, timestamp and initial retry count, and store it in the retry queue;

[0105] Step 8-2: Retrieve the first record in the retry queue. When the elapsed time exceeds the backoff interval, use the exponential backoff strategy to perform a backoff retransmission operation, including:

[0106] Write the message byte stream into the communication sending buffer;

[0107] Update the number of retries and sending timestamp;

[0108] Step 8-3: If the number of retries does not reach the threshold, keep the record and wait for the next retry. If the number of retries exceeds the threshold, clear the associated retry records and trigger a disconnection reconnection request. Generate a disconnection alarm log and push it to the log queue.

[0109] Step 8-4: After receiving the reconnection success signal, the message sending function is restored and the new message is injected into the communication link;

[0110] Step 8-5: Record the results of each retry attempt, the disconnection reconnection request triggered by exceeding the retry limit, the reconnection success or queue clearing event, format it as a log entry or alarm message, and push it to the log queue.

[0111] The workflow-based IEC104 communication protocol implementation method disclosed in the present invention solves the technical problems of dynamically parsing and decoupling various IEC104 ASDUs from their services using a configurable workflow engine, and integrating intelligent reconnection and structured log push in a modular layered architecture. The parsing process of the present invention is driven by template configuration, and adding or modifying ASDU types does not require code changes, only updating the process template. Modular division is adopted, and the responsibilities of modules such as link management, timed scheduling, message transmission and reception, service parsing, and status recovery are singularly decoupled. Unified log queue push is implemented, and front-end visualization and alarm system linkage are supported, significantly improving system observability. An exponential backoff strategy is combined with link monitoring to achieve intelligent reconnection, balancing timeliness and resource conservation. BRIEF DESCRIPTION OF THE DRAWINGS

[0112] Figure 1 It is the main flow chart of the present invention;

[0113] Figure 2 It is a flow chart of the initialization phase of the present invention;

[0114] Figure 3 is a flow chart of the link management phase of the present invention;

[0115] Figure 4 It is a flow chart of the business analysis phase of the present invention;

[0116] Figure 5 is a flow chart of the timing scheduling phase of the present invention;

[0117] Figure 6 It is a flow chart of the message receiving stage of the present invention;

[0118] Figure 7 It is a flow chart of the message sending stage of the present invention;

[0119] Figure 8 is a flow chart of the business response phase of the present invention;

[0120] Figure 9 It is a flow chart of the state recovery phase of the present invention. DETAILED DESCRIPTION

[0121] Depend on Figures 1-9 The method for implementing the IEC104 communication protocol based on a workflow includes the following steps:

[0122] Step 1: Initialization phase: The initialization module loads communication configuration parameters, creates a communication channel, registers scheduled tasks, initializes link status and counters, and establishes a logging system.

[0123] After the initialization module loads the configuration parameters, it stores them in a structure and establishes a log queue;

[0124] When executing step 1, the specific steps performed by the initialization module are as follows:

[0125] Step 1-1: Load the configuration file containing the target address, ASDU address, data start address and time parameters;

[0126] The initialization module must first retrieve and load the configuration parameter file, and read parameters from the configuration parameter file, including the destination address, public ASDU address, starting address of telesignaling, telemetering and telepulsing, and time parameters. The time parameters include heartbeat interval, confirmation timeout, and reconnection interval. The destination address includes the target host IP address and port number.

[0127] Store parameters into the internal configuration structure.

[0128] Step 1-2: Create a TCP communication channel object with a connection status flag;

[0129] The initialization module creates a TCP communication channel object in memory and retains the target IP and port, connection status flag, receive buffer and send buffer in the TCP communication channel object;

[0130] The TCP communication channel object will initiate a connection using the loaded IP / port information when the link is established.

[0131] Steps 1-3: Register scheduled tasks including heartbeat detection, confirmation timeout, and automatic reconnection;

[0132] Specifically: the initialization module notifies the timer scheduling module to generate scheduled tasks based on various time parameters in the configuration file. The scheduled tasks include sending confirmation timeout tasks, heartbeat sending tasks, and automatic reconnection tasks.

[0133] The scheduled task only performs the "registration" operation in this step and does not start. It will be activated uniformly after the link is successfully established.

[0134] Step 1-4: Initialize the link status to disconnected and clear the communication sequence number;

[0135] The initialization module sets all link status flags to the "disconnected" state, sets the link layer sequence number counter to zero, and clears or resets the send buffer and the receive buffer.

[0136] In this embodiment, the link layer sequence number counter refers to the transmit sequence number (TxSN) and receive sequence number (RxSN) maintained according to the IEC104 protocol, and is used for orderly confirmation of link layer frames.

[0137] Steps 1-5: Build a log queue system that is linked to the visualization module.

[0138] The initialization module creates a log queue and configures a formatting template, associating the log queue with the front-end display module. This allows subsequent modules to push formatted text into the log queue when messages are generated or status changes occur, and the front-end pulls and displays it in real time.

[0139] Step 2: Link management phase: The link management module establishes a TCP communication link, activates scheduled tasks, parses slave confirmation messages, maintains link heartbeat detection, and dynamically updates communication sequence numbers.

[0140] The link management module initiates a connection through the TCP channel, activates the scheduled task after the link is successfully established, parses the slave confirmation message, maintains periodic heartbeat frame detection during the link, and dynamically maintains the sending sequence number and receiving sequence number;

[0141] When executing step 2, the link management module performs the following steps:

[0142] Step 2-1: Initiate a TCP connection based on the configuration parameters and update the connection status flag;

[0143] The link management module retrieves the target host IP address and port number from the output of the initialization module, extracts the connection parameters, and initiates a connection request to the slave station through the TCP communication channel object; the target host IP address and port number;

[0144] Set a connection status flag variable m_bConnect. When the connection is successful, m_bConnect is set to true; when the connection fails, m_bConnect is set to false.

[0145] Step 2-2: After the link is established, activate the scheduled tasks related to link maintenance;

[0146] When the link is successfully connected, the link management module controls the timer scheduling module to start multiple scheduled tasks related to link maintenance, including:

[0147] Start the heartbeat detection task;

[0148] Start sending confirmation timeout detection task;

[0149] Start the reconnection monitoring task;

[0150] Each scheduled task performs periodic checks or reconnection operations according to the time interval registered in the initialization module.

[0151] Step 2-3: Send a link start frame and parse the slave station confirmation message;

[0152] After the link is established, the link management module organizes and sends a link startup message, which then starts the data transmission frame, namely the link startup frame;

[0153] The link startup message is used to start data interaction and is sent to the slave device through the existing TCP channel.

[0154] Step 2-4: Periodically maintain heartbeat detection and update the communication sequence number.

[0155] When executing steps 2-4, the specific steps include:

[0156] Step 2-4-1: After receiving the start frame, the slave device sends a confirmation message, which is a U frame or an S frame;

[0157] After receiving the confirmation message, the link management module parses the control bit, sequence number and function flag field to determine whether the link is successfully established and updates the relevant state variables, including the receiving sequence number m_unRxSN and the sending sequence number m_unTxSN;

[0158] Step 2-4-2: During the link maintenance process, the link management module periodically sends heartbeat messages to the slave station according to the timer event. If no response is received from the slave station within a certain period of time, reconnection is performed;

[0159] Step 2-4-3: During the communication process, the link management module continuously maintains the sending sequence number and the receiving sequence number, specifically including: each time an I frame is sent, the sending sequence number m_unTxSN is incremented; each time a confirmation frame is received, the receiving sequence number m_unRxSN is updated and the confirmed messages in the sending buffer are cleared; the confirmation frame is an S frame.

[0160] Step 3: During the service parsing phase, the service parsing module parses the ASDU type identifier of the received frame, executes the workflow, generates structured data based on the type matching parsing template, performs data push and instruction legitimacy verification, and generates and outputs log entries.

[0161] The service parsing module parses the ASDU type identifier of the I frame, matches the parsing template by type, executes the workflow, and asynchronously pushes the data to the SCADA or database after completing data encapsulation. It also verifies the legitimacy of remote control commands and generates execution signals, builds event queues and remote control execution links, and ultimately outputs structured service data streams and generates log entries.

[0162] When executing step 3, the execution steps of the business analysis module are as follows:

[0163] Step 3-1: Extract the ASDU type identifier of the received I frame and match the parsing process template according to the ASDU type identifier;

[0164] After receiving the I-frame message from the link, the service parsing module first extracts the content of the ASDU data area and locates the type identification byte in the first field. Based on this field, it identifies the data type of the current message and extracts the type identification value.

[0165] Type identification values ​​may include telemetry type, telesignaling type, sequential event, remote control command (single point / dual point), remote adjustment command, and unknown type;

[0166] After the recognition is completed, according to the recognition results, the parsing process template corresponding to the type identifier is matched and loaded into the memory as the execution path for this data parsing.

[0167] Step 3-2: Trigger the parsing workflow based on the ASDU type identifier and execute the processing flow of field extraction, value conversion, quality verification and time labeling in sequence according to the logical node;

[0168] The business parsing module automatically enters the preset parsing workflow based on the current type identifier value. The workflow is configured with multiple logical nodes, including field extraction nodes, value conversion nodes, quality verification nodes, and time label processing nodes. Each node is executed in the configured order to complete the ASDU field disassembly and data conversion tasks.

[0169] Telemetry class: extracts measurement value fields and parses the values ​​and their time tags:

[0170] Remote signaling class: extract status value field, analyze switch status and position change flag;

[0171] Sequential event class: extract event items and mark them in order according to event time;

[0172] Remote control command class: Identify single-point or double-point commands, verify command phase, execution flag and command legitimacy;

[0173] Remote control command class: Identify the "selection" or "execution" stage and extract the target value, adjustment parameters and path information;

[0174] Unknown type: The record type is abnormal, an alarm log is generated, and invalid data is discarded.

[0175] Step 3-3: Encapsulate telemetry data and telesignaling data to obtain standardized objects, and asynchronously push the standardized objects to the monitoring system; the monitoring system is the host SCADA platform or historical database, which is used to display and store the collected telemetry and telesignaling data in real time.

[0176] When the identification result is telemetry or telesignaling data, the business parsing module obtains key information such as the original measurement value, information body address, time tag, etc. from the parsing node, and encapsulates it into a standardized data item object according to a unified structure;

[0177] After the data items are packaged, they are sent to the monitoring system using an asynchronous push mechanism. This embodiment can also push them to a historical database or a front-end display module, thereby performing real-time reporting and archiving of the monitoring data.

[0178] Step 3-4: Verify the legitimacy of the remote control command based on the control records cached in the send buffer. If the verification is passed, generate an execution signal based on the content of the remote control command, record the operation trajectory, and generate an operation log;

[0179] When the recognition result is remote control command data, the business analysis module compares the currently received remote control command with the control record cached in the sending buffer to determine whether it is a legal response frame: if the verification passes, the corresponding record in the sending buffer is cleared, and an execution instruction is generated and issued according to the command content; at the same time, the execution trajectory of the remote control action is recorded, including information such as the instruction issuance time, control type, response status, etc., and written into the operation log.

[0180] Step 3-5: Build a time series queue for sequential event data and track the operation link for remote control instruction data;

[0181] When the recognition result is a sequential event or a remote control command, the service analysis module processes it according to the following steps:

[0182] For sequential events: parse each event record and its time tag, build an event queue in chronological order, and integrate it into event flow management;

[0183] For remote control commands: depending on whether it is the "selection" or "execution" stage, different business processing branches are triggered and remote control control signals are generated; the remote control path, operation stage, and execution parameters are automatically recorded to form a complete remote control execution link.

[0184] Step 3-6: Generate a structured log entry containing the message body address, processing status, and time stamp, and synchronize the log entry to the log library, visualization platform, and alarm system;

[0185] All parsed business data is ultimately uniformly formatted, structured, and packaged to generate structured log entries. The log entry content includes core fields such as the information body address, data type, parsing time, and processing result status. Log data can be written to the system log library, visualization platform, and operation and maintenance alarm system at the same time.

[0186] Step 4: In the scheduled scheduling phase, the timer scheduling module activates periodic tasks based on the link status, routes event processing functions according to the counter ID, adaptively calculates the backoff delay based on link quality prediction and anomaly detection mechanisms, implements self-optimizing reconnection control, generates control command messages, and records them in logs.

[0187] The counter ID is the timer number assigned to different timed tasks in the timer scheduling module, such as T1, T2, and T3.

[0188] The timer scheduling module activates the periodic task after the link is connected, routes the event processing function based on the counter ID, uses the exponential backoff method to reconnect, generates control command messages, and formats the task trigger record as a log entry and pushes it into the message queue;

[0189] When executing step 4, the execution steps of the timer scheduling module are as follows:

[0190] Step 4-1: Obtain the connection status flag sent by the link management module in real time. When the link is successfully connected, activate the three pre-registered timed tasks and start the periodic timer;

[0191] After obtaining the connection status flag sent by the link management module, if a "connected" signal is received, the three registered timed tasks are activated at the same time and the corresponding periodic timers are started.

[0192] Step 4-2: Routing to the corresponding processing according to the counter ID, including:

[0193] The connection check task triggers the reconnection process;

[0194] The time synchronization task triggers the generation of calibration commands;

[0195] The general summoning task triggers the generation of summoning command processing;

[0196] The power call task triggers the processing according to the configured interval;

[0197] Monitor and obtain the identification ID carried by each timer when it is triggered, and obtain the current system time and the remaining count value; the current system time and the remaining count value are obtained by the timer m_ucAdjustTime and the counter m_ucGenCall respectively;

[0198] According to the counter ID of the trigger event, the event is routed to the corresponding data processing function for processing, and the trigger instruction signal of each task is output;

[0199] The data processing function is as follows:

[0200] Connection check processing: Check the connection status flag, if it is found to be disconnected, enter the reconnection process;

[0201] Time synchronization task processing: read the current system time m_ucAdjustTime count, and prepare the time calibration command if it has returned to zero;

[0202] General call task processing: read the remaining count value m_ucGenCall count, and prepare the general call command if it has returned to zero;

[0203] Power call task processing: triggered according to the power call configuration interval.

[0204] Outputs trigger command signals for each task, such as "execute time synchronization", "execute general call", "execute power call" and "execute connection detection".

[0205] Step 4-3: For any timed event or external "disconnection" signal, obtain the current connection status flag and the most recent heartbeat confirmation time; if the connection status flag is "disconnected" or the heartbeat confirmation timeout, use the exponential backoff algorithm to generate a reconnection delay and output a reconnection request signal after the delay; the reconnection request signal includes the delay time and the number of reconnections.

[0206] When executing step 4-3, the specific steps include:

[0207] Step 4-3-1: During each heartbeat transmission and confirmation process, a sliding window is maintained. The data in the sliding window is used to calculate the heartbeat success rate, and then the heartbeat quality is calculated. The heartbeat quality is used as an indicator of link quality.

[0208] The formula for calculating the heartbeat success rate is as follows:

[0209] ;

[0210] in, Indicates that the i-th heartbeat confirms the receipt of the response, Indicates that the i-th heartbeat timed out without receiving a response; It is expressed as the heartbeat success rate at the current moment, ; N is the size of the sliding window, t represents the time;

[0211] Step 4-3-2: Predict the link quality according to the following formula:

[0212] ;

[0213] in, is the predicted link quality indicator, is the smoothing factor, The value ranges from 0.2 to 0.5. Indicates the link quality indicator predicted at the previous moment, Initialized to 1;

[0214] Step 4-3-3: Based on the predicted link quality , dynamically adjust the reconnection delay , the specific formula is as follows:

[0215] ;

[0216] in, is the preset basic reconnection delay, is the adjustment factor to control the backoff increase;

[0217] When the link quality is good, ,at this time , the delay is close to the baseline value;

[0218] When the link quality is poor, , the backoff interval is increased to reduce frequent reconnection;

[0219] Step 4-3-4: If If the heartbeat value is lower than the preset threshold of 0.3 for more than 5 times, the link is judged to be abnormal and a reconnection signal is triggered immediately without waiting for normal backoff. Otherwise, the reconnection delay is used. After the delay is completed, a reconnection request signal is output.

[0220] Step 4-4: Each time a timed event is triggered, the time synchronization counter and the total call counter are decremented respectively. When the time synchronization counter or the total call counter returns to zero, the initial value is reset and the corresponding command is triggered;

[0221] Each time a timing event is triggered, read the counter m_ucAdjustTime and the counter m_ucGenCall;

[0222] The counter m_ucAdjustTime and the counter m_ucGenCall are both decremented by one;

[0223] When the counter m_ucAdjustTime or the counter m_ucGenCall returns to zero, in addition to outputting the corresponding task trigger instruction, the corresponding counter is also reset to the initial configuration value.

[0224] Step 4-5: Obtain the trigger command signal for each task (such as heartbeat detection, time synchronization, general call, and power call), fill in the ASDU address, function code, and timestamp for the trigger command, generate a control message, and output it; in this embodiment, the command signal is an internal event identifier generated after the task expires.

[0225] The timer scheduling module obtains the trigger command signal of each task, fills in the corresponding ASDU address, function code and current timestamp for each control command, forms a complete message, and outputs three types of control command message byte streams.

[0226] Steps 4-6: Record the metadata and execution results of the control message, generate a formatted log and push it to the log queue.

[0227] Obtain the message content and execution results of various control command scheduling, format the binary content of the message, task type and trigger time into a log entry, and push it into the log queue.

[0228] Step 5: During the message reception phase, the message reception and processing module receives the byte stream, divides the valid frames into I-frames, S-frames, and U-frames through the synchronous state machine, and generates parsed logs that are pushed to the log queue.

[0229] The message receiving and processing module receives and caches byte streams from the TCP channel, segments valid frames by the start character 0x68 and the frame length, performs classification processing after format verification, and generates parsed logs that are pushed to the log queue. The byte stream is the raw network data read from the underlying TCP socket interface.

[0230] When executing step 5, the message receiving and processing module executes the following steps:

[0231] Step 5-1: Read the newly arrived byte stream from the TCP communication channel, append it to the receive buffer, update the available byte length of the receive buffer, and prepare for synchronization and segmentation;

[0232] Step 5-2: Establish a semi-packet synchronization state machine and split the byte stream, specifically:

[0233] State WAIT_HEAD, waiting for the frame header:

[0234] Search for the first 0x68 bytes in the buffer. If found, switch the state to WAIT_LENGTH, otherwise discard one byte and continue.

[0235] Status WAIT_LENGTH, that is, the waiting length field:

[0236] Ensure the buffer length is ≥ 2 and read the second byte L as the APDU length;

[0237] Calculate the full frame length N=L+2 and switch to WAIT_FULL_PACKET;

[0238] If the buffer is less than two bytes, pause segmentation and wait for more data;

[0239] State WAIT_FULL_PACKET, waiting for a complete message:

[0240] If the available bytes in the buffer are ≥ N, extract the first N bytes as a complete frame and return to WAIT_HEAD;

[0241] Otherwise, pause the splitting, keep the existing buffer, and wait for new data to arrive;

[0242] State machine output: Whenever the state machine extracts a complete frame, it is passed to the subsequent steps for format verification and classification processing;

[0243] Step 5-3: Verify each extracted complete frame, including whether the start character is still 0x68, whether the length field L is consistent with the actual number of bytes N-2, and whether the total number of bytes meets the minimum message length requirement;

[0244] If the verification fails, the frame is discarded and a "discard log" is recorded; if the verification passes, it is considered a "qualified frame" and proceeds to step 5-4:

[0245] Step 5-4: Extract the control bit from the control field byte of the qualified frame and determine the frame type:

[0246] I frame (application data frame): contains user data and the subsequent ASDU part should be extracted;

[0247] S frame (acknowledgement frame): contains only the receiving sequence number and is used to update the sender's confirmed frame status;

[0248] U frame (management frame): contains control commands such as link start, stop, and test, used to adjust the link status;

[0249] For I frames, the ASDU is output and handed over to the service analysis module; for S frames or U frames, the link control information is output and handed over to the link management module. The link control information includes the confirmation sequence number or the control command flag;

[0250] Step 5-5: For the I frame, the byte block of the ASDU is placed into the input queue of the service parsing module for deep parsing and service distribution based on the type identifier.

[0251] Step 5-6: For the S frame, extract the latest confirmation sequence number and notify the message sending and buffering module to release the confirmed sending record;

[0252] Step 5-7: For the U frame, parse the start command, stop command or test command, and update the connection status or heartbeat timing of the link management module;

[0253] Steps 5-8: For each processed frame, format it into a structured log entry according to the "frame type", "sequence number", and "parsing result" fields, and push the log to the log queue;

[0254] Step 5-9: When any state machine stops and fails to extract the complete message, the unparsed half-packet bytes in the buffer are retained;

[0255] If a complete frame cannot be formed after consecutive timeouts (within the configured threshold), perform the following steps:

[0256] Step 5-9-1: Find the next legal start character 0x68 and discard the leading garbage data;

[0257] Step 5-9-2: Keep the tail bytes of the half packet to ensure that the subsequent splicing can continue;

[0258] Step 5-9-3: If the buffer backlog is too large or exceeds the maximum timeout period, the buffer is cleared and a "receive timeout" alarm is generated.

[0259] Step 6: During the message sending phase, the message sending and buffering module assembles and sends the message according to the IEC104 protocol, manages the sending buffer and the timeout retransmission mechanism;

[0260] The message sending and caching module assembles messages according to the IEC104 protocol, sends them via TCP, records the logs and places them in the sending history queue. If a timeout occurs, retransmission is performed based on the retransmission count threshold or a disconnected link is triggered and reconnected.

[0261] When executing step 6, the message sending and caching module specifically performs the following steps:

[0262] Step 6-1: Receive a sending instruction and parse the message type, which includes a time synchronization request, a general call request, a power call request, and a link start request;

[0263] In this embodiment, the message sending and buffering module receives a sending instruction from the timer scheduling module or the link management module and obtains the type and key fields of the message to be sent;

[0264] Specifically include:

[0265] Time synchronization request: contains the current timestamp and ASDU address;

[0266] General call request: contains ASDU address and function code;

[0267] Power call request: contains power function code and ASDU address;

[0268] Start link request: contains the link start control field;

[0269] Step 6-2: Assemble the link layer frame header, length field, control field and ASDU data area according to the IEC104 protocol, insert the current timestamp or function code, and generate a formatted message byte stream;

[0270] In this embodiment, specifically according to the IEC104 protocol format, the link layer frame header, length field, control field, and ASDU data area are assembled, and the current timestamp or function code is inserted to obtain a formatted message byte stream.

[0271] Step 6-3: Write the message byte stream into the TCP send buffer, perform the send operation, and return the write result;

[0272] Step 6-4: Integrate the message content and sending results into a log record item, and push the log message to the log queue;

[0273] Step 6-5: Encapsulate a sending record object and store it in a sending history queue. The sending record object includes frame content, sending time, number of retransmissions, and sequence number.

[0274] In this embodiment, the message sending and caching module encapsulates the message byte stream into a sending record object, including frame content, sending time, number of retransmissions, sequence number information, and inserts it into the sending history queue, and adds a record to be confirmed in the sending history queue.

[0275] Step 6-6: Set the confirmation timeout threshold and start the monitoring process to track the confirmation status of the records to be confirmed;

[0276] After setting the sending time of the record to be confirmed and the configured confirmation timeout, the message sending and caching module will notify the timer scheduling module to start the counter (this counter is a dedicated timeout timer used to track the confirmation timeout of each I frame) to monitor the confirmation status of the record to be confirmed;

[0277] Step 6-7: When the number of retransmissions is within the limit, retransmission is performed. When the threshold is reached, the disconnection reconnection is triggered and the pending confirmation record is cleared.

[0278] Specifically:

[0279] If the number of retransmissions does not exceed the maximum threshold, the sending record object corresponding to the record to be confirmed is rewritten into the sending buffer, and the sending time and retransmission number are updated;

[0280] If the number of retransmissions reaches the threshold, the link management module is notified to execute the link break reconnection process and clear all pending confirmation records.

[0281] Step 7: In the service response phase, the service processing and response modules concurrently process the ASDU task object, generate feedback frames, and generate full-process logs.

[0282] The business processing and response module receives ASDU task objects and processes them concurrently, verifies permissions and executes business logic in the thread pool, generates feedback frames and pushes them to the link send queue, and records the entire task process log in the message queue;

[0283] When executing step 7, the business processing and response module performs the following steps:

[0284] Step 7-1: Receive an ASDU task object and store it in a concurrent task queue. The ASDU task object includes a type identifier, an information body address, a data value, and a time tag.

[0285] The business processing and response module receives the ASDU task object output by the business analysis module, puts the task object into the concurrent task queue, and updates the task queue length; the ASDU task object includes the ASDU type identifier, information body address, original data value or status and time tag.

[0286] Step 7-2: Parse the task content through concurrent processing and perform the following multi-type processing:

[0287] For remote control tasks, a two-stage status verification process is performed;

[0288] For remote control tasks, calculate the target setting value;

[0289] For telemetry tasks or telesignaling tasks, update the equipment status or historical records;

[0290] For sequential events, generate time-series records;

[0291] In this embodiment, the business processing and response module takes a single ASDU task object from the task queue, parses the task content in the thread pool worker thread, performs permission verification, status verification and business calculation, and outputs a business processing result object;

[0292] Specifically:

[0293] Remote control task: Verify the legitimacy of the command and generate the status of the "accept" and "execute" stages;

[0294] Remote control task: Calculate the target set value according to the selection or execution process;

[0295] Telemetry / telesignaling tasks: handle status updates or historical record writing;

[0296] Sequence Events: Sequence and generate event records.

[0297] The business processing result object includes the execution stage flag (such as selection confirmation, execution confirmation), processing result status (success, failure reason) and possible new values ​​or status updates.

[0298] Step 7-3: Obtain the processing result of step 7-2 and generate a control feedback frame. The control feedback frame selects the format of U frame or I frame according to the execution phase flag and fills the corresponding control field and ASDU field.

[0299] In this embodiment, the business processing and response module extracts the stage flag, original information body address and ASDU address in the business processing result object, uses feedback data to fill the control field and ASDU field of the U frame or I frame, generates a confirmation response frame or execution result frame, and encapsulates it into a byte stream of the control feedback frame.

[0300] Step 7-4: Push the control feedback frame into the transmission queue of the link management module for transmission, and update the link sequence number and confirmation status;

[0301] Step 7-5: Extract the final status, value, or event record from the business processing result object and asynchronously push it to the monitoring system or database through the message queue for display or storage;

[0302] Step 7-6: Retrieve the task's original input, processing stage, feedback frame content, and execution result status, summarize them into log entries, distinguish between three types of information: received tasks, execution results, and feedback frames, and push them to the log queue.

[0303] Step 8: During the state recovery phase, the sending state recovery module implements a backoff and retransmission strategy for failed messages, triggers a disconnected link reconnection, and restores communication, generating a retry log.

[0304] The sending status recovery module builds a retry record for failed sending messages and triggers retransmission based on the backoff strategy. When the maximum number of retries is reached, the queue is cleared and the broken link is notified to reconnect. After the reconnection is successful, the sending function is restored. The retry log is recorded throughout the process and pushed to the message queue.

[0305] When executing step 8, the execution steps of the sending status recovery module are as follows:

[0306] Step 8-1: Receive the failed message, extract the sequence number of the failed message, construct a retry record object containing the message byte stream, sequence number, timestamp and initial retry count, and store it in the retry queue;

[0307] In this embodiment, after retrieving a complete message byte stream and its associated sending sequence number submitted by the message sending and caching module, the sending status recovery module will construct a retry record object, including the message byte stream, sending sequence number, current timestamp, and the initial value of the number of retries 0, and insert the retry record object into the retry queue.

[0308] Step 8-2: Retrieve the first record in the retry queue. When the elapsed time exceeds the backoff interval, use the exponential backoff strategy to perform a backoff retransmission operation, including:

[0309] Write the message byte stream into the communication sending buffer;

[0310] Update the number of retries and sending timestamp;

[0311] In this embodiment, the sending status recovery module retrieves the first record in the retry queue and calculates the time that has passed since the last retry; if the backoff interval that should be used has exceeded, a resend operation is performed;

[0312] The resend operation specifically includes: writing the message byte stream back to the TCP send buffer, updating the retry count of the record by one, and recording the new send timestamp.

[0313] Step 8-3: If the number of retries does not reach the threshold, keep the record and wait for the next retry. If the number of retries exceeds the threshold, clear the associated retry records and trigger a disconnection reconnection request. Generate a disconnection alarm log and push it to the log queue.

[0314] In this embodiment, if the number of retries of a retry record is less than the maximum retry threshold, it will be retained in the queue and wait for the next retry;

[0315] If the number of retries reaches or exceeds the threshold, the retry record object is deemed to have failed to be sent successfully, the corresponding retry record is cleared, and a broken link reconnection request is output; the broken link reconnection request includes notifying the link management module (M2) to execute the reconnection process, clearing all remaining retry records, and recording and pushing the alarm log.

[0316] Step 8-4: After receiving the reconnection success signal, the message sending function is restored and the new message is injected into the communication link;

[0317] In this embodiment, the sending status recovery module obtains the reconnection success status fed back by the path management module, and after triggering the reconnection success, sets the sendable flag to true, allowing message sending and the buffer to continue pushing new messages to be sent.

[0318] Step 8-5: Record the results of each retry attempt, the disconnection reconnection request triggered by exceeding the retry limit, the reconnection success or queue clearing event, format it as a log entry or alarm message, and push it to the log queue.

[0319] The workflow-based IEC104 communication protocol implementation method disclosed in the present invention solves the technical problems of dynamically parsing and decoupling various IEC104 ASDUs from their services using a configurable workflow engine, and integrating intelligent reconnection and structured log push in a modular layered architecture. The parsing process of the present invention is driven by template configuration, and adding or modifying ASDU types does not require code changes, only updating the process template. Modular division is adopted, and the responsibilities of modules such as link management, timed scheduling, message transmission and reception, service parsing, and status recovery are singularly decoupled. Unified log queue push is implemented, and front-end visualization and alarm system linkage are supported, significantly improving system observability. An exponential backoff strategy is combined with link monitoring to achieve intelligent reconnection, balancing timeliness and resource conservation.

Claims

1. A workflow-based IEC104 communication protocol implementation method, characterized by: The steps include: Step 1: Initialization phase: The initialization module loads communication configuration parameters, creates a communication channel, registers scheduled tasks, initializes link status and counters, and establishes a logging system. Step 2: Link management phase: The link management module establishes a TCP communication link, activates scheduled tasks, parses slave confirmation messages, maintains link heartbeat detection, and dynamically updates communication sequence numbers. Step 3: During the service parsing phase, the service parsing module parses the ASDU type identifier of the received frame, executes the workflow, generates structured data based on the type matching parsing template, performs data push and instruction legitimacy verification, and generates and outputs log entries. Step 4: In the scheduled scheduling phase, the timer scheduling module activates periodic tasks based on the link status, routes event processing functions according to the counter ID, adaptively calculates the backoff delay based on link quality prediction and anomaly detection mechanisms, implements self-optimizing reconnection control, generates control command messages, and records them in logs. When executing step 4, the execution steps of the timer scheduling module are as follows: Step 4-1: Obtain the connection status flag sent by the link management module in real time. When the link is successfully connected, activate various pre-registered timed tasks and start the periodic timer; Step 4-2: Routing to the corresponding processing according to the counter ID, including: The connection check task triggers the reconnection process; The time synchronization task triggers the generation of calibration commands; The general summoning task triggers the generation of summoning command processing; The power call task triggers the processing according to the configured interval; Step 4-3: For any timed event or external "disconnected" signal, obtain the current connection status flag and the most recent heartbeat confirmation time; if the connection status flag is "disconnected" or the heartbeat confirmation timeout, use the exponential backoff algorithm to generate a reconnection delay and output a reconnection request signal after the delay; the reconnection request signal includes the delay time and the number of reconnections; Step 4-4: Each time a timed event is triggered, the time synchronization counter and the total call counter are decremented respectively. When the time synchronization counter or the total call counter returns to zero, the initial value is reset and the corresponding command is triggered; Step 4-5: Get the trigger command signal of each task, fill in the ASDU address, function code and timestamp for the trigger command, generate the control message and output it; Steps 4-6: Record the metadata and execution results of the control message, generate a formatted log, and push it to the log queue; When executing step 4-3, the specific steps include: Step 4-3-1: During each heartbeat transmission and confirmation process, a sliding window is maintained. The data in the sliding window is used to calculate the heartbeat success rate, and then the heartbeat quality is calculated. The heartbeat quality is used as an indicator of link quality. The formula for calculating the heartbeat success rate is as follows: Where Ii=1 means that the i-th heartbeat confirmation has received a response, and Ii=0 means that the i-th heartbeat has timed out and no response has been received; St represents the heartbeat success rate at the current moment, St∈[0,1]; N is the size of the sliding window, and t represents the time; Step 4-3-2: Predict the link quality according to the following formula: in, is the predicted link quality indicator, α is the smoothing factor, and α is between 0.2 and 0.

5. Indicates the link quality indicator predicted at the previous moment, Initialized to 1; Step 4-3-3: Based on the predicted link quality indicators Dynamically adjust the reconnection delay Dt. The specific formula is as follows: Among them, Dbase is the preset basic reconnection delay, k is the adjustment factor, which controls the backoff increase; Step 4-3-4: If If the heart rate is continuously lower than the preset threshold of 0.3 for more than 5 heartbeat cycles, the link is judged to be abnormal and a reconnection signal is triggered immediately without waiting for normal backoff. Otherwise, a reconnection request signal is output after the reconnection delay Dt is completed. Step 5: During the message reception phase, the message reception and processing module receives the byte stream, divides the valid frames into I-frames, S-frames, and U-frames through the synchronous state machine, and generates parsed logs that are pushed to the log queue. Step 6: During the message sending phase, the message sending and buffering module assembles and sends the message according to the IEC104 protocol, manages the sending buffer and the timeout retransmission mechanism; Step 7: In the service response phase, the service processing and response modules concurrently process the ASDU task object, generate feedback frames, and generate full-process logs. Step 8: During the state recovery phase, the sending state recovery module implements a backoff and retransmission strategy for failed messages, triggers a disconnected link reconnection, and restores communication, generating a retry log.

2. The workflow-based IEC104 communication protocol implementation method according to claim 1, characterized in that: When executing step 1, the specific steps performed by the initialization module are as follows: Step 1-1: Load the configuration file containing the target address, ASDU address, data start address and time parameters; Step 1-2: Create a TCP communication channel object with a connection status flag; Steps 1-3: Register scheduled tasks including heartbeat detection, confirmation timeout, and automatic reconnection; Step 1-4: Initialize the link status to disconnected and clear the communication sequence number; Steps 1-5: Build a log queue system that is linked to the visualization module.

3. The workflow-based IEC104 communication protocol implementation method according to claim 2, characterized in that: When executing step 2, the link management module performs the following steps: Step 2-1: Initiate a TCP connection based on the configuration parameters and update the connection status flag; Step 2-2: After the link is established, activate the scheduled tasks related to link maintenance; Step 2-3: Send a link start frame and parse the slave station confirmation message; Step 2-4: Periodically maintain heartbeat detection and update the communication sequence number.

4. The workflow-based IEC104 communication protocol implementation method according to claim 3, characterized in that: When executing step 3, the execution steps of the business analysis module are as follows: Step 3-1: Extract the ASDU type identifier of the received I frame and match the parsing process template according to the ASDU type identifier; Step 3-2: Trigger the parsing workflow based on the ASDU type identifier and execute the processing flow of field extraction, value conversion, quality verification and time labeling in sequence according to the logical node; Step 3-3: Encapsulate telemetry data and telesignaling data to obtain standardized objects, and asynchronously push the standardized objects to the monitoring system; Step 3-4: Verify the legitimacy of the remote control command based on the control records cached in the send buffer. If the verification is passed, generate an execution signal based on the content of the remote control command, record the operation trajectory, and generate an operation log; Step 3-5: Build a time series queue for sequential event data and track the operation link for remote control instruction data; Steps 3-6: Generate structured log entries containing information body address, processing status, and time tags, and synchronize the log entries to the log library, visualization platform, and alarm system.

5. The workflow-based IEC104 communication protocol implementation method according to claim 4, characterized in that: When executing step 5, the message receiving and processing module executes the following steps: Step 5-1: Read the newly arrived byte stream from the TCP communication channel, append it to the receive buffer, update the available byte length of the receive buffer, and prepare for synchronization and segmentation; Step 5-2: Establish a semi-packet synchronization state machine and split the byte stream, specifically: State WAIT_HEAD, waiting for the frame header: Search for the first 0x68 bytes in the buffer. If found, switch the state to WAIT_LENGTH, otherwise discard one byte and continue. Status WAIT_LENGTH, that is, the waiting length field: Ensure the buffer length is ≥ 2 and read the second byte L as the APDU length; Calculate the full frame length N = L + 2 and switch to WAIT_FULL_PACKET; If the buffer is less than two bytes, pause segmentation and wait for more data; State WAIT_FULL_PACKET, waiting for a complete message: If the available bytes in the buffer are ≥ N, extract the first N bytes as a complete frame and return to WAIT_HEAD; Otherwise, pause the splitting, keep the existing buffer, and wait for new data to arrive; State machine output: Whenever the state machine extracts a complete frame, it is passed to the subsequent steps for format verification and classification processing; Step 5-3: Verify each extracted complete frame, including whether the start character is still 0x68, whether the length field L is consistent with the actual number of bytes N-2, and whether the total number of bytes meets the minimum message length requirement; If the verification fails, the frame is discarded and the "discard log" is recorded; if the verification passes, it is considered a "qualified frame" and proceeds to step 5-4: Step 5-4: Extract the control bit from the control field byte of the qualified frame and determine the frame type: For I frames, the ASDU is output and handed over to the service analysis module; for S frames or U frames, the link control information is output and handed over to the link management module. The link control information includes the confirmation sequence number or the control command flag; Step 5-5: For the I frame, the byte block of the ASDU is placed into the input queue of the service parsing module for deep parsing and service distribution based on the type identifier. Step 5-6: For the S frame, extract the latest confirmation sequence number and notify the message sending and buffering module to release the confirmed sending record; Step 5-7: For the U frame, parse the start command, stop command or test command, and update the connection status or heartbeat timing of the link management module; Steps 5-8: For each processed frame, format it into a structured log entry based on the "Frame Type", "Sequence Number", and "Parsing Result" fields, and push the log to the log queue; Step 5-9: When any state machine stops and fails to extract the complete message, the unparsed half-packet bytes in the buffer are retained; If a complete frame is not formed after consecutive timeouts within the configured threshold, the following steps are performed: Step 5-9-1: Find the next legal start character 0x68 and discard the leading garbage data; Step 5-9-2: Keep the tail bytes of the half packet to ensure that the subsequent splicing can continue; Step 5-9-3: If the buffer backlog is too large or exceeds the maximum timeout period, the buffer is cleared and a "receive timeout" alarm is generated.

6. The workflow-based IEC104 communication protocol implementation method according to claim 5, characterized in that: When executing step 6, the message sending and caching module specifically performs the following steps: Step 6-1: Receive a sending instruction and parse the message type, which includes a time synchronization request, a general call request, a power call request, and a link start request; Step 6-2: Assemble the link layer frame header, length field, control field and ASDU data area according to the IEC104 protocol, insert the current timestamp or function code, and generate a formatted message byte stream; Step 6-3: Write the message byte stream into the TCP send buffer, perform the send operation, and return the write result; Step 6-4: Integrate the message content and sending results into a log record item, and push the log message to the log queue; Step 6-5: Encapsulate a sending record object and store it in a sending history queue. The sending record object includes frame content, sending time, number of retransmissions, and sequence number. Step 6-6: Set the confirmation timeout threshold and start the monitoring process to track the confirmation status of the records to be confirmed; Step 6-7: When the number of retransmissions is within the limit, retransmission is performed. When the threshold is reached, the disconnection reconnection is triggered and the pending confirmation record is cleared.

7. The workflow-based IEC104 communication protocol implementation method according to claim 6, characterized in that: When executing step 7, the business processing and response module performs the following steps: Step 7-1: Receive an ASDU task object and store it in a concurrent task queue. The ASDU task object includes a type identifier, an information body address, a data value, and a time tag. Step 7-2: Parse the task content through concurrent processing and perform the following multi-type processing: For remote control tasks, a two-stage status verification process is performed; For remote control tasks, calculate the target setting value; For telemetry tasks or telesignaling tasks, update the equipment status or historical records; For sequential events, generate time-series records; Step 7-3: Obtain the processing result of step 7-2 and generate a control feedback frame. The control feedback frame selects the format of U frame or I frame according to the execution phase flag and fills the corresponding control field and ASDU field. Step 7-4: Push the control feedback frame into the transmission queue of the link management module for transmission, and update the link sequence number and confirmation status; Step 7-5: Extract the final status, value, or event record from the business processing result object and asynchronously push it to the monitoring system or database through the message queue for display or storage; Step 7-6: Retrieve the task's original input, processing stage, feedback frame content, and execution result status, summarize them into log entries, distinguish between three types of information: received tasks, execution results, and feedback frames, and push them to the log queue.

8. The workflow-based IEC104 communication protocol implementation method according to claim 7, characterized in that: When executing step 8, the execution steps of the sending status recovery module are as follows: Step 8-1: Receive the failed message, extract the sequence number of the failed message, construct a retry record object containing the message byte stream, sequence number, timestamp and initial retry count, and store it in the retry queue; Step 8-2: Retrieve the first record in the retry queue. When the elapsed time exceeds the backoff interval, use the exponential backoff strategy to perform a backoff retransmission operation, including: Write the message byte stream into the communication sending buffer; Update the number of retries and sending timestamp; Step 8-3: If the number of retries does not reach the threshold, keep the record and wait for the next retry. If the number of retries exceeds the threshold, clear the associated retry records and trigger a disconnection reconnection request. Generate a disconnection alarm log and push it to the log queue. Step 8-4: After receiving the reconnection success signal, the message sending function is restored and the new message is injected into the communication link; Step 8-5: Record the results of each retry attempt, the disconnection reconnection request triggered by exceeding the retry limit, the reconnection success or queue clearing event, format it as a log entry or alarm message, and push it to the log queue.

Images