Information transmission device based on multi-protocol dynamic conversion and data fusion and implementation method

Abstract

The invention provides an information transmission device and implementation method based on multi-protocol dynamic conversion and data fusion, and belongs to the technical field of information transmission, and the device comprises a multi-protocol communication interface module, a data analysis unit, a dynamic protocol conversion engine, a data fusion unit, a data assembly reporting unit and a log storage module. According to the method, information transmission is realized by initializing an interface, analyzing multi-protocol original data, dynamically converting the multi-protocol original data into a uniform format, fusing de-duplicated data, packaging, reporting and recording logs. The device and the method solve information interaction obstacles of different protocol devices, support bidirectional conversion of multiple industrial protocols, realize cross-protocol device collaboration and centralized management, improve the system intelligence level, and are suitable for scenes requiring multi-device collaboration, such as electric power, intelligent transportation, intelligent buildings and the like.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information transmission, in particular to an information transmission device based on multi-protocol dynamic conversion and data fusion and an implementation method thereof. BACKGROUND

[0002] In various industries (such as power systems, intelligent transportation, intelligent buildings, etc.), different devices often use multiple communication protocols such as Modbus, Profibus, CAN, Ethernet / IP, etc., resulting in "information silos" among devices due to non-uniform protocols, and efficient information exchange and centralized monitoring cannot be achieved. For example, in the power system, devices from different manufacturers may use Modbus and Profibus protocols respectively, and in the fire protection field, different brand hosts may transmit data based on RS232, RS485 (Modbus) protocols, etc., making it difficult to collaborate across devices and limiting data sharing, increasing system modification and operation costs, and restricting the development of industry digitization and intelligentization. SUMMARY

[0003] The present application provides an information transmission device based on multi-protocol dynamic conversion and data fusion and an implementation method thereof to solve the problems presented in the background art.

[0004] The specific technical solutions are as follows:

[0005] An information transmission device based on multi-protocol dynamic conversion and data fusion, comprising:

[0006] A multi-protocol communication interface module, containing three independent communication units, each communication unit simultaneously integrating 1 RS232 interface and 1 RS485 interface, supporting simultaneous access to three different protocol fire host computers, the interface module is configured with an isolation circuit, supporting an electrical isolation voltage of ≥2500V, the RS232 interface baud rate can be adaptively adjusted between 1200-115200bps, the RS485 interface supports a bus topology structure and a maximum transmission distance of ≥1200 meters;

[0007] A data analysis unit for receiving and analyzing the raw data of the multi-protocol communication interface module, wherein for RS232 protocol data, the valid data segment is located by frame header "7E" and frame trailer "7E", the 5th byte is extracted as event type identification (0x02 corresponds to fire alarm), the continuous 4-byte component address is analyzed as loop number and node number, and the GBK encoding field is identified to obtain device description; for Modbus protocol RS485 data, the data type is identified based on host address and command word "03", and the fault event (00 02) and fire alarm event (00 0E) in the valid data segment and the corresponding detector number are analyzed;

[0008] A dynamic protocol conversion engine, which contains a mapping relationship library of more than 8 industrial protocols, supports bidirectional conversion of the protocols and has a conversion delay of less than or equal to 10 ms, realizes real-time mapping of source protocol fields to target protocol fields through a preset protocol instruction mapping table and an offset calculation model, and is provided with a self-defined protocol expansion interface, so that a user can add a frame format, a field offset and a check rule of a new protocol through a configuration tool;

[0009] A data fusion unit, which removes, checks and integrates unified format data based on timestamps and priorities, and is internally provided with a cache pool with a capacity of 1000 to process data redundancy when a network fluctuates;

[0010] A data assembly and reporting unit, which encapsulates the fused data in a preset structure format, and uploads the data to a monitoring platform through a TCP / IP protocol, wherein the structure contains event encoding, standardized component address (loop number-node number format), device description (GBK to UTF-8 encoding), timestamp and CRC16 checksum.

[0011] A log storage module, which is used for storing device operation logs and data conversion records, has a maximum storage capacity of 10000, and each log contains a source interface type, an original data frame, converted data, a reporting state and a timestamp, and supports local viewing and remote retrieval.

[0012] The device, wherein the protocol mapping relationship library of the dynamic protocol conversion engine contains mapping rules of 10 mainstream industrial protocols, i.e., Modbus, Profibus, CAN, Ethernet / IP, Profinet, EtherCAT, DeviceNet, CC-Link, M-Bus and ZigBee, supports conversion of heterogeneous data of a fire-fighting host into a unified 16-bit transmission format with "0x40 0x40" as a frame header and "0x23 0x23" as a frame tail, and has an instruction mapping accuracy of greater than or equal to 99.9%; wherein the Modbus protocol supports RTU / TCP variant conversion, the CAN protocol supports 2.0A / 2.0B frame format analysis, and the Ethernet / IP protocol supports explicit / implicit message conversion.

[0013] The device, wherein in the structure of the data assembly and reporting unit, the standardized component address is stored in 4 bytes, wherein the first 2 bytes store a 16-bit value of a generalized node number in little-end mode, and the last 2 bytes store a 16-bit value of a generalized loop number in little-end mode, such as "01-0200-0100" corresponding to "0064 00C8" (hexadecimal); the timestamp is stored in 6 bytes, corresponding to a BCD encoding format of "year-month-day-hour-minute-second".

[0014] The device, wherein a heartbeat alive unit is further included, and a heartbeat frame containing device running state, interface connection state and remaining storage capacity is sent to a monitoring platform every 1800 seconds, the heartbeat frame is in the format of "0x40 0x40+service flow serial number+protocol version number+time label+source address+target address+application data unit length+command word+information object+check sum+0x23 0x23", and when no response is received for three times in succession, the original TCP connection is automatically disconnected and re-established, and communication failure log recording is triggered.

[0015] The device, wherein the log storage module adopts a cyclic coverage mechanism, and when the storage capacity reaches 10000, the earliest 10% records are automatically deleted, and the device supports log filtering according to event type (fire alarm, fault) and time range through device keys or remote instructions, the log export format is CSV, and the CSV contains original data frames (hexadecimal), converted data (hexadecimal), reporting results (success / failure) and time stamps (YYYY-MM-DD HH:MM:SS) fields.

[0016] The application further provides an information transmission implementation method based on multi-protocol dynamic conversion and data fusion, and the method comprises the following steps of using the device:

[0017] S1. A multi-protocol communication interface module is initialized, three groups of interface parameters (baud rate, check mode, timeout time) of the communication unit are configured, and communication connection with each fire-fighting host is established, wherein the RS232 interface is adapted to the Beida Qingniao protocol data, and the RS485 interface is adapted to the Modbus protocol of the Yian Te host data;

[0018] S2. Raw data is received in real time, and the protocol type is identified through a data analysis unit: RS232 data is analyzed to obtain event type (for example, 5th byte 0x02 is a fire alarm), component address (for example, "00 00 01 00 72" is analyzed to be 1 loop 114) and device description in GBK code (for example, "CA D6 B1 A8" is analyzed to be "hand report"); RS485 data of the Modbus protocol is analyzed from the reply frame "01 03 04 00 02 00 0E DA 37" to obtain host address "01", command word "03" and valid data ("00 02" is a fault, and "00 0E" is a fire alarm);

[0019] S3. The dynamic protocol conversion engine calls the protocol mapping relationship library to convert the parsed data into a unified format, wherein the event type is mapped to a preset code (fire alarm 0x02, fault 0x03), the component address is standardized to a "circuit number-node number" format, and the device description is converted to a UTF-8 code; the protocol mapping relationship library supports bidirectional conversion of Modbus, Profibus, CAN, Ethernet / IP, Profinet, EtherCAT, DeviceNet, CC-Link, M-Bus, ZigBee protocols, and the conversion delay is ≤10ms;

[0020] S4. The data fusion unit performs deduplication processing on homologous data of the same timestamp, retains valid data based on priority (fire alarm > fault > status), and stores data in a cache pool (capacity 1000) and starts a retransmission mechanism if network fluctuations are encountered;

[0021] S5. The data assembly and reporting unit encapsulates the data in a structure format, the structure including 1 byte of event code, 4 bytes of standardized address, 16 bytes of device description, 6 bytes of timestamp, and 1 byte of CRC16 checksum, and uploads it to the monitoring platform through the TCP / IP protocol, and triggers retransmission (up to 3 times) if the upload fails;

[0022] S6. The log storage module records the key information of steps S2-S5, generates a log containing the source interface type (RS232 / RS485), the original data frame, the converted data, and the reporting status, and automatically covers the earliest record when the number of logs reaches 10000.

[0023] The above method, wherein in step S3, the conversion process of the dynamic protocol conversion engine on CAN protocol data includes: parsing CAN frame ID (11 bits / 29 bits), data length code (DLC), and data field, mapping frame type (data frame / remote frame) to a unified event identifier, and converting data field by byte sequence to a standardized numerical value; for Ethernet / IP protocol data, parse the instruction specific field (Command Specific Data) in the message header, extract the I / O data and map it to a preset data object.

[0024] The above method, wherein in step S5, the transmission format of the structure is "0x40 0x40" as the frame header and "0x23 0x23" as the frame tail, wherein the application data unit length field (2 bytes) identifies the total number of structure bytes, the command word field (1 byte) is set to 0x02 to indicate event reporting, and the interaction process with the platform conforms to the timing logic of "registration->clock calibration->event reporting->heartbeat keep-alive".

[0025] The method, wherein the analysis of the RS232 data in step S2 further comprises: checking the integrity of the frame header "7E" and the frame tail "7E", calculating the checksum of the data segment (such as the checksum of "30 31 B2 E3 C2 A5 CC DD BF DA CA D6 B1 A8 CA D6 B1 A8 8C 3C"), and discarding the frame and recording error logs if the check fails.

[0026] The method, wherein in step S4, the deduplication processing of the data fusion unit is based on the error tolerance range of the timestamp ±100ms, and only the first occurrence record is retained for the repeated events of the same component address (such as the same fire alarm reported continuously within 1 minute); the consistency integration process includes format checking (length compliance), integrity checking (field non-empty), and range verification (address in the valid interval).

[0027] The present application has the following beneficial effects:

[0028] 1. Solving the problem of "information island": through multi-protocol compatible technology (supporting more than 8 mainstream industrial protocols) and multi-interface design, simultaneous access and bidirectional data conversion of different protocol devices are realized, the communication barrier of cross-protocol devices is broken, and device collaboration and data sharing are promoted.

[0029] 2. Improving data processing efficiency: relying on efficient protocol conversion algorithm and data fusion mechanism, real-time analysis, conversion and integration of data are realized, ensuring smoothness of the whole process from data reception to reporting, meeting the needs of real-time monitoring scenarios.

[0030] 3. Ensuring transmission stability: through the heartbeat keep-alive mechanism, data retransmission strategy and log storage function, the communication connection between the device and the platform is continuously maintained, the key operation information is recorded, the fault tracing and problem troubleshooting are facilitated, and the risk of data transmission interruption is reduced.

[0031] 4. Reducing application cost: without replacing the original device, protocol unification and collaboration are realized, reducing system modification investment; through centralized monitoring and automated data processing, the manual operation intensity is reduced, and the device life cycle is prolonged.

[0032] 5. Adapting to complex scenarios: the anti-interference design and wide temperature characteristics of the hardware adapt to the harsh industrial environment, and the software custom protocol extension function supports the addition of new protocol rules, improving the adaptability and flexibility of the device in different industry scenarios (power, fire protection, building, etc.). BRIEF DESCRIPTION OF DRAWINGS

[0033] Fig. 1 The composition schematic diagram of the information transmission device based on multi-protocol dynamic conversion and data fusion provided by the embodiment of the present application is shown;

[0034] Fig. 2A flowchart of a method for implementing information transmission provided by an embodiment of the present invention;

[0035] Fig. 3 This is a performance curve diagram of an information transmission device based on multi-protocol dynamic conversion and data fusion provided by an embodiment of the present invention. The horizontal axis represents protocol conversion delay, instruction mapping accuracy, deduplication error range, heartbeat interval, and RS485 transmission distance; the vertical axis represents the corresponding performance parameters (10ms / 99.9% / 100ms / 1800s / 1200m). The curve characteristics represent the performance of each indicator through point-line connections, reflecting the comprehensive advantages of the device in terms of conversion efficiency, data accuracy, system stability, transmission distance, and other dimensions. DETAILED DESCRIPTION

[0036] The technical solution of the present invention will be further described below with reference to the accompanying drawings and through specific implementation methods.

[0037] Among them, the accompanying drawings are only for illustrative purposes and represent only schematic diagrams rather than actual pictures, and should not be understood as limiting the present application; in order to better illustrate the embodiments of the present invention, some parts of the accompanying drawings may be omitted, enlarged or reduced, and do not represent the size of the actual product; for those skilled in the art, it is understandable that some well-known structures and their descriptions may be omitted in the accompanying drawings.

[0038] The same or similar numbers in the drawings of the embodiments of the present invention correspond to the same or similar parts; in the description of the present invention, it should be understood that if the terms "upper", "lower", "left", "right", "inside", "outside" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, the terms describing the positional relationship in the drawings are only used for illustrative purposes and cannot be understood as limiting the present application. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to specific circumstances.

[0039] In the description of the present invention, unless otherwise expressly specified or limited, when the term "connection" or the like appears to indicate a connection relationship between components, such term should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be internal communication between two components or an interaction between two components. For those skilled in the art, the specific meanings of the above terms in the present invention can be understood in specific circumstances.

[0040] Reference Figs. 1-3The embodiment provides an information transmission device based on multi-protocol dynamic conversion and data fusion, comprising a multi-protocol communication interface module, a data analysis unit, a dynamic protocol conversion engine, a data fusion unit, a data assembly and reporting unit and a log storage module, wherein:

[0041] The multi-protocol communication interface module comprises three independent communication units, each of which is integrated with an RS232 interface and an RS485 interface, supports simultaneous access to three different protocol fire hosts, the interface module is configured with an isolation circuit, supports an electrical isolation voltage of ≥2500V, the RS232 interface can be adaptively adjusted at 1200-115200bps, and the RS485 interface supports a bus type topology and a maximum transmission distance of ≥1200 meters;

[0042] The data analysis unit is used for receiving and analyzing the original data of the multi-protocol communication interface module, wherein the RS232 protocol data is positioned by a frame header "7E" and a frame tail "7E" to an effective data segment, the fifth byte is extracted as an event type identifier (0x02 corresponds to a fire alarm), the continuous four bytes of component address are analyzed into a loop number and a node number, and the GBK code field is identified to obtain device description; for the RS485 data of the Modbus protocol, the data type is identified based on the host address and the command word "03", the fault event (00 02) and the fire alarm event (00 0E) in the effective data segment are analyzed, and the corresponding detector number is analyzed;

[0043] The dynamic protocol conversion engine comprises a mapping relationship library containing more than eight industrial protocols, supports bidirectional conversion of the protocols, and the conversion delay is ≤10ms; the dynamic protocol conversion engine realizes real-time mapping of the source protocol field to the target protocol field through a preset protocol instruction mapping table and an offset calculation model; the engine is provided with a custom protocol expansion interface, and a user can add the frame format, the field offset and the check rule of a new protocol through a configuration tool; the offset calculation model adopts a dynamic segmentation algorithm, specifically: when a variable length field is detected, the offset calculation formula of the subsequent field is dynamically adjusted based on the length value of the previous field (ΔOffset=the starting offset of the current field+the length value of the previous field), so as to ensure the accuracy of field extraction;

[0044] The data fusion unit removes, checks and integrates the unified format data based on a timestamp and a priority, and a built-in cache pool with a capacity of 1000 is used to process data redundancy when the network fluctuates;

[0045] The data assembly and reporting unit encapsulates the fused data in a preset structure body format, the structure body comprises event encoding, standardized component address (loop number-node number format), device description (GBK to UTF-8 encoding), timestamp and CRC16 checksum, and is uploaded to a monitoring platform through a TCP / IP protocol;

[0046] Log storage module, for storing device operation log and data conversion record, maximum storage capacity is 10000, each log contains source interface type, original data frame, converted data, reporting state and timestamp, supports local viewing and remote retrieval.

[0047] The device realizes the simultaneous access of multiple fire-fighting hosts of different protocols through the multi-protocol communication interface module, combines the targeted analysis of different protocol raw data by the data analysis unit, the multi-protocol bidirectional conversion capability of the dynamic protocol conversion engine, the processing of data redundancy by the data fusion unit, the unified format packaging of the data assembly and reporting unit, and the whole process recording of the log storage module, and can realize the compatible access, accurate analysis and conversion, effective processing of data redundancy, unified standard reporting of multi-protocol fire-fighting host data, and is convenient for the traceability and maintenance of the device operation process, and solves the "information island" problem of different protocol devices.

[0048] Among them: the pre-set protocol instruction mapping table is a structured data set that stores the correspondence between instructions of different industrial protocols, and its core function is to establish the mapping association of heterogeneous protocol instructions, and the specific scheme is as follows:

[0049] Mapping dimension: includes protocol type, instruction function (such as data acquisition, event reporting, state query, etc.), instruction code (instruction identifier of each protocol itself), data field correspondence (such as event type, component address, device description, etc. Field corresponding items in different protocols), data type conversion rules (such as mutual conversion of string and hexadecimal, encoding format conversion).

[0050] Storage form: built-in in the form of queryable table, for example, "03 function code (read hold register)" of Modbus protocol corresponds to "explicit message read instruction" of Ethernet / IP protocol, fire alarm event is identified by "00 0E" in Modbus and by a specific frame ID in CAN protocol, and they are all mapped to a unified "fire alarm event code".

[0051] Expansion mechanism: supports users to add protocol instruction mapping relationship through configuration tool, supplement the instruction function of new protocol and the corresponding rules of unified instruction in existing mapping table, without modifying the core code of the engine to adapt to new protocols.

[0052] Among them: offset calculation model:

[0053] The offset calculation model is an algorithm model for positioning the position of the target field in different protocol messages, which realizes accurate extraction and filling of fields by presetting the field layout rules of each protocol frame structure, and the specific scheme is as follows:

[0054] Core logic: For different protocol frame formats (such as start symbol, length field, data segment, fixed structure of check segment), preset the offset value (byte number) of each field relative to the frame start position and field length. For example:

[0055] In RS232 protocol data, the 4th byte (offset 4) after the frame header "7E" is the event type field, with a length of 1 byte;

[0056] In Modbus protocol messages, the 1st byte (offset 1) after the host address is the command word field, with a length of 1 byte, and the effective data segment starts from the 3rd byte (offset 3) after the command word.

[0057] Dynamic adaptation: Combine the "length field" in the protocol frame to dynamically adjust the offset calculation. When the frame structure contains a variable length field, correct the offset of the subsequent field based on the length value to ensure that the field extraction is not affected by data length fluctuations.

[0058] Cross-protocol consistency: Map the field offset rules of different protocols to a unified "target protocol frame structure". When converting, extract the source protocol fields according to the offset calculation model, and fill them according to the offset rules of the target protocol to achieve structured reconstruction of the data frame.

[0059] Through the above scheme, the protocol instruction mapping table solves the problem of "non-uniform instruction meaning" for different protocols, and the offset calculation model solves the problem of "non-uniform field position". Both of them support the dynamic protocol conversion engine to achieve accurate and efficient conversion of heterogeneous protocols, ensuring that event, state, and other information of different protocols can be correctly parsed and reconstructed into a unified format.

[0060] Among them, the dynamic protocol conversion engine contains the mapping rules of more than 8 mainstream industrial protocols, and its core implementation contains three levels:

[0061] 1. Protocol analysis layer: Match the frame header / frame tail of different protocols through regular expressions (such as Modbus RTU CRC checksum calculation rules, CAN protocol IDE bit analysis rules);

[0062] 2. Field mapping layer: Store the protocol mapping table in JSON format, for example:

[0063] {

[0064] "Modbus": {

[0065] "03 function code": {

[0066] "mapping target": "fire alarm event",

[0067] "address offset": {

[0068] "Loop number": "Byte 3 [7:4]"

[0069] "Node number": "Byte 3 [3:0]"

[0070] }

[0071] }

[0072] },

[0073] "CAN": {

[0074] "Standard frame": {

[0075] "Mapping target": "State change event"

[0076] "Data field analysis": "Bytes 0-3 are sensor values"

[0077] }

[0078] }

[0079] }。

[0080] 3. Real-time conversion layer: field reorganization based on FPGA hardware acceleration, conversion delay ≤ 5ms (actual data).

[0081] Among them, the redundant processing flow of the data fusion unit is as follows:

[0082] When network fluctuations cause data packets to be out of order, the data fusion unit performs the following operations:

[0083] 1. Cache pool temporarily stores data packets and marks the timestamp error range (±100ms);

[0084] 2. Perform weighted deduplication on duplicate data packets: fire event weight 100, fault event weight 50, state event weight 10;

[0085] 3. If the cache pool is full (1000), start the LRU (Least Recently Used) algorithm to discard low-weight data.

[0086] Among them, the extension function of the log storage module is:

[0087] The log module supports three special record types:

[0088] 1. Abnormal event record: including verification failure (record error frame CRC value), protocol timeout (record timeout times), memory overflow (record stack call path);

[0089] 2. Performance monitoring record: statistics of protocol conversion times per minute, average response time, cache hit rate;

[0090] 3. Configuration change record: record the modification history of user-defined protocol parameters (including modification time, operator ID, and new and old parameter comparison).

[0091] Specifically, in the embodiment, the protocol mapping relationship library of the dynamic protocol conversion engine contains mapping rules of 10 mainstream industrial protocols, including Modbus, Profibus, CAN, Ethernet / IP, Profinet, EtherCAT, DeviceNet, CC-Link, M-Bus, and ZigBee, supports converting heterogeneous data of the fire host into a unified hexadecimal transmission format with “0x40 0x40” as the frame header and “0x23 0x23” as the frame tail, and the instruction mapping accuracy is ≥99.9%; wherein the Modbus protocol supports RTU / TCP variant conversion, the CAN protocol supports 2.0A / 2.0B frame format analysis, and the Ethernet / IP protocol supports explicit / implicit message conversion.

[0092] The dynamic protocol conversion engine contains mapping rules of 10 mainstream industrial protocols and supports conversion into a unified transmission format, which can significantly improve the compatibility of devices for multiple industrial protocols, ensure that heterogeneous data of different protocols can be efficiently converted into a unified format, and enhance the flexibility and versatility of devices in adapting to multiple types of devices in complex industrial scenarios.

[0093] Specifically, in the structure of the data assembly and reporting unit in the embodiment, the standardized component address is stored in 4 bytes, of which the first 2 bytes store the hexadecimal value of the generalized node number in little-end mode, and the last 2 bytes store the hexadecimal value of the generalized loop number in little-end mode, such as “01-0200-0100” corresponding to “0064 00C8” (hexadecimal); the timestamp is stored in 6 bytes, corresponding to the BCD encoding format of “year-month-day-hour-minute-second”.

[0094] Through the specific storage format of the standardized component address and the timestamp, the data structure is standardized and unified, ensuring consistency of component addresses and time information from different sources during transmission and analysis, facilitating accurate identification and processing of data by the monitoring platform, and improving the accuracy of data interaction.

[0095] Specifically, in the embodiment, it also includes a heartbeat keep-alive unit that sends a heartbeat frame containing device running status, interface connection status, and remaining storage capacity to the monitoring platform every 1800 seconds. The heartbeat frame format is “0x40 0x40 + business flow number + protocol version number + time tag + source address + target address + application data unit length + command word + information object + checksum + 0x23 0x23”; when no response is received for 3 consecutive times, the original TCP connection is automatically disconnected and a new connection is established, and a communication failure log is triggered at the same time.

[0096] The heartbeat keep-alive unit can continuously maintain the communication connection between the device and the platform, discover and handle communication interruption problems in a timely manner, reduce data transmission interruption caused by communication failure, and improve the stability and reliability of device and platform communication through periodic sending of heartbeat frames, reconnection mechanism when communication fails, and log recording.

[0097] Specifically, in the present embodiment, the log storage module adopts a cyclic coverage mechanism, and when the storage capacity reaches 10,000, the earliest 10% of the records are automatically deleted; the log can be filtered by event type (fire alarm, fault), time range through device keys or remote instructions, and the log export format is CSV, containing the original data frame (hexadecimal), converted data (hexadecimal), reporting result (success / failure), and timestamp (YYYY-MM-DD HH:MM:SS) fields.

[0098] The cyclic coverage mechanism of the log storage module realizes efficient management of logs, and the filtering and exporting functions facilitate targeted inquiry of device operation and data processing records, support tracing of device status, data conversion, and reporting process, provide convenience for fault troubleshooting and device monitoring, and improve the maintainability of the device.

[0099] Among them, the deduplication and priority decision of the data fusion unit adopt a dynamic weighting algorithm, and the core equation is as follows:

[0100] ;

[0101] Among them:

[0102] S is the data validity comprehensive score (threshold value ≥ 0.6 to retain data);

[0103] P is the event priority coefficient (fire alarm = 1.0, fault = 0.7, status = 0.3);

[0104] Δt is the deviation of data timestamp and reference time (unit: ms);

[0105] T0 is the time decay constant (fixed value 500 ms);

[0106] L valid / L total is the data field integrity ratio (number of valid fields / total number of fields);

[0107] E i is the i-th error identifier (0 = no error, 1 = check error, 2 = format error);

[0108] ω1−ω4 are dynamic weights (satisfy ω1+ω2+ω3+ω4=2.0, and ω1≥0.5).

[0109] The specific equation is as follows:

[0110] 1. Parameter description table

[0111]

[0112] 2. Example, taking the fire alarm event reported by the fire host as an example:

[0113] Event priority P = 1.0, timestamp deviation Δt = 20 ms, data field integrity ratio 1.0 (no missing fields), no error (E i = 0); weight configuration ω1 = 0.8, ω2 = 0.5, ω3 = 0.5, ω4 = 0.2;

[0114] Calculation process:

[0115] S = (0.8 x 1.0) + (0.5 x e −20 / 500 ) + (0.5 x 1.0) - (0.2 x 0)

[0116] ≈ 0.8 + 0.48 + 0.5 = 1.78 ≥ 0.6 (data retention).

[0117] 3. Technical effect: The time decay, priority, integrity, and error level are fused through a nonlinear function, breaking through the single-dimensional limit of traditional threshold judgment; it has dynamic adaptability, and the weights can be adjusted according to the scene (such as increasing ω2 to strictly control the time deviation in the power system); it has good anti-interference performance, suppressing data with large time deviation through an exponential function, and amplifying the influence of serious errors through the error multiplication term.

[0118] 4. Working principle flow:

[0119] 1. The data fusion unit receives unified format data, extracts timestamp, priority, field integrity, error code, etc.

[0120] 2. Dynamically assign ω1-ω4 weights based on event type (such as fire);

[0121] 3. Substitute the equation to calculate S value, if S ≥ 0.6, retain the data, otherwise store in the cache pool for re-verification;

[0122] 4. Discard data in the cache pool that is timeout (≥ 3s) and S < 0.6, and record the log.

[0123] This equation realizes the accurate determination of data effectiveness in complex industrial scenarios through nonlinear coupling of multiple parameters, which is significantly improved compared to existing single rule determination (such as only based on timestamp deduplication), effectively reducing invalid data transmission while ensuring zero loss rate of critical events (such as fire).

[0124] The embodiment also provides an information transmission implementation method based on multi-protocol dynamic conversion and data fusion, adopting the device and comprising the following steps:

[0125] S1. initializing the multi-protocol communication interface module, configuring interface parameters (baud rate, check mode, timeout time) of the three groups of communication units, and establishing a communication connection with each fire host, wherein the RS232 interface is adapted to the Beida Qingniao protocol data, and the RS485 interface is adapted to the Modbus protocol Yiante host data;

[0126] S2. Real-time receiving of original data, identification of protocol types through the data analysis unit: RS232 data analysis to obtain event types (such as fire alarm 0x02 for the 5th byte), component addresses (such as “00 00 01 00 72” analysis for 1 loop 114), and GBK encoded device descriptions (such as “CA D6 B1 A8” analysis for “hand report”); Modbus protocol RS485 data analysis from the reply frame “01 03 04 00 02 00 0E DA 37” to obtain host address “01”, command word “03”, and valid data (“00 02” for fault, “00 0E” for fire alarm);

[0127] S3. The dynamic protocol conversion engine calls the protocol mapping relationship library to convert the parsed data into a unified format, wherein the event type is mapped to a preset code (fire alarm 0x02, fault 0x03), the component address is standardized to “loop number-node number” format, and the device description is converted to UTF-8 code; the protocol mapping relationship library supports bidirectional conversion of Modbus, Profibus, CAN, Ethernet / IP, Profinet, EtherCAT, DeviceNet, CC-Link, M-Bus, and ZigBee protocols, and the conversion delay is ≤10ms;

[0128] S4. The data fusion unit performs deduplication processing on the homologous data of the same timestamp, retains valid data based on priority (fire alarm> fault> state), and stores the data in the cache pool (capacity 1000) and starts the retransmission mechanism if network fluctuation is encountered; the data fusion unit adopts a timestamp hierarchical strategy to process network fluctuation data:

[0129] Priority 1 (fire alarm): cache time ≤500ms;

[0130] Priority 2 (fault): cache time ≤1000ms;

[0131] Priority 3 (state): cache time ≤2000ms;

[0132] S5. The data assembly reporting unit encapsulates the data in a structure format, including 1 byte event encoding, 4 bytes standardized address, 16 bytes device description, 6 bytes timestamp, and 1 byte CRC16 checksum, and uploads it to the monitoring platform through the TCP / IP protocol. If the upload fails, retransmission (up to 3 times) is triggered.

[0133] S6. The log storage module records the key information of steps S2-S5, generates a log containing the source interface type (RS232 / RS485), the original data frame, the converted data, and the reporting status. When the number of logs reaches 10,000, the earliest records are automatically overwritten.

[0134] This method realizes the orderly processing of the whole process of multi-protocol data from access to reporting by initializing the adaptation to different fire host computers, specifically analyzing the original data, converting multiple protocols into a unified format, fusing data redundancy, standardizing packaging and reporting, and recording the whole process of logs. It ensures that the data is accurately and efficiently uploaded to the monitoring platform, meeting the data interaction needs of different protocol fire host computers.

[0135] Specifically, in this embodiment, in step S3, the conversion process of the dynamic protocol conversion engine for CAN protocol data includes: parsing CAN frame ID (11 bits / 29 bits), data length code (DLC), and data field, mapping the frame type (data frame / remote frame) to a unified event identifier, and converting the data field to a standardized numerical value according to the byte sequence; for Ethernet / IP protocol data, parse the instruction specific field (Command Specific Data) in the message header, extract the I / O data and map it to the preset data object.

[0136] The specific conversion process of CAN and Ethernet / IP protocol data ensures that the frame information and data of these two protocols can be accurately mapped to a unified format, improving the adaptation accuracy of devices to these two protocols and ensuring the accuracy and reliability of specific protocol data conversion.

[0137] Specifically, in this embodiment, in step S5, the transmission format of the structure is "0x40 0x40" as the frame header and "0x23 0x23" as the frame tail. The application data unit length field (2 bytes) indicates the total number of structure bytes, and the command word field (1 byte) is set to 0x02 to represent event reporting. The interaction process with the platform conforms to the timing logic of "registration → clock calibration → event reporting → heartbeat keep-alive".

[0138] The unified transmission format of the structure and the standard interaction timing with the platform make the data reporting format consistent and the interaction process orderly, avoiding data transmission errors caused by format or timing chaos, and ensuring the smoothness and consistency of device and platform data interaction.

[0139] Specifically, in the embodiment, the analysis of the RS232 data in step S2 further includes: checking the integrity of the frame header "7E" and the frame tail "7E", calculating the checksum of the data segment (such as the checksum of "30 31 B2 E3 C2 A5 CC DD BF DA CA D6 B1 A8 CA D6 B1 A8 8C 3C"), and discarding the frame and recording error logs if the check fails.

[0140] The check step in the analysis of the RS232 data can filter invalid or error raw data, avoid error data from entering the subsequent processing flow, ensure the accuracy of the parsed data, and reduce the interference of error data on data conversion and reporting.

[0141] Specifically, in the embodiment, in step S4, the deduplication processing of the data fusion unit is based on the error tolerance range of the timestamp ±100ms, and only the first occurrence record is retained for the repeated events of the same source component address (such as the same fire alarm reported continuously within 1 minute); the consistency integration process includes format checking (length compliance), integrity checking (field non-empty), and range verification (address in the valid interval).

[0142] The deduplication processing and the consistency integration process of the data fusion unit can eliminate repeated data, check data format and integrity, ensure the uniqueness and validity of the reported data, and improve the quality of the transmitted data, thereby providing reliable data support for the monitoring platform.

[0143] The embodiment also provides the following experimental table:

[0144]

[0145] In summary, the device realizes the conversion and transmission of multi-protocol data through the cooperation of "hardware architecture + software process", and the principle is as follows:

[0146] 1. Hardware architecture

[0147] Modular design is adopted, including a multi-protocol communication interface module (integrating RS232, RS485, RJ45, CAN, etc., supporting simultaneous access to multiple devices with different protocols), a main control module (realizing data processing and control based on a microcontroller), a communication module (supporting Ethernet, wireless transmission, etc.), and an auxiliary module (power supply, storage, etc.). The hardware layer is adapted to the industrial scene through isolation circuit, anti-electromagnetic interference design, and provides a basis for multi-protocol data access and stable transmission.

[0148] 2. Software process

[0149] Data receiving and analysis: Real-time receiving of raw data of different protocols (such as RS232 protocol frame structure data, Modbus protocol 485 message) through multi-protocol communication interface, and analyzing the event type (such as fire alarm, fault), component address (such as loop number, node number), device description (such as manual report, detector) and other key information in the data based on preset rules.

[0150] Protocol conversion and data fusion: Relying on a dynamic protocol conversion engine, heterogeneous data is converted into a unified format through a pre-set protocol instruction mapping table (establishing a correspondence between different protocol instructions) and an offset calculation model (locating the target field position in the message); at the same time, through data fusion mechanism, the same source data is de-duplicated and checked to ensure data consistency.

[0151] Data reporting and interaction: Encapsulating data in a unified structure format (including event code, address, description, timestamp, etc.) and uploading to the monitoring platform through TCP / IP protocol; following the interaction process of "power-on initialization → registration → clock calibration → event reporting → heartbeat keep-alive", stable communication with the platform is ensured, and all data needs to be confirmed by the platform.

[0152] Method for use

[0153] 1. Parameter configuration: Setting basic parameters through local buttons and display screen or remote web, including platform IP address and port, communication protocol (national standard / custom), communication method (Ethernet / wireless), device code and target code, etc., to ensure that the communication parameters of the device and the platform match.

[0154] 2. Device deployment: Connecting the device to the target scene (such as a substation, a smart building), connecting different protocol devices (such as a fire host, a sensor) through a multi-protocol communication interface, completing the physical connection of power supply and communication lines, and ensuring interface matching (such as RS232 connecting a Beida Jade Crane host, RS485 connecting a Modbus protocol device).

[0155] 3. Operation management: The device automatically completes initialization after power-on, establishes connection with the platform and registers; during operation, the device state, protocol conversion log and reporting record can be viewed in real time through local or remote methods; when communication failure occurs, the device will automatically attempt to reconnect and record fault logs, facilitating troubleshooting by operation and maintenance personnel.

[0156] The above is only a preferred embodiment of the present application, and does not limit the implementation and protection scope of the present application. For those skilled in the art, it should be realized that any equivalent replacement and obvious changes made by applying the contents of the present application specification and drawings should be included in the protection scope of the present application.

Claims

1. An information transmission device based on multi-protocol dynamic conversion and data fusion, characterized in that: include: The multi-protocol communication interface module includes three independent communication units. Each communication unit integrates one RS232 interface and one RS485 interface, supporting simultaneous access to three fire control hosts with different protocols. The interface module is equipped with an isolation circuit and supports an electrical isolation voltage of ≥2500V. The baud rate of the RS232 interface can be adaptively adjusted between 1200-115200bps. The RS485 interface supports a bus topology with a maximum transmission distance of ≥1200 meters. A data parsing unit is configured to receive and parse the raw data from the multi-protocol communication interface module, wherein for RS232 protocol data, the valid data segment is located by using the frame header "7E" and the frame footer "7E", the fifth byte is extracted as the event type identifier, the continuous 4-byte component address is parsed into the loop number and the node number, and the GBK encoding field is identified to obtain the device description; for RS485 data of the Modbus protocol, the data type is identified based on the host address and the command word "03", and the fault event (0002) and the fire alarm event (00 0E) in the valid data segment and the corresponding detector number are parsed; Dynamic protocol conversion engine, with a built-in mapping library for more than 8 industrial protocols, supports bidirectional protocol conversion with a conversion delay of ≤10ms. The dynamic protocol conversion engine uses a preset protocol instruction mapping table and offset calculation model to achieve real-time mapping of source protocol fields to target protocol fields. The engine has a custom protocol extension interface, and users can add new protocol frame formats, field offsets, and verification rules through the configuration tool; The data fusion unit deduplicates, verifies, and integrates unified format data based on timestamps and priorities. A built-in cache pool with a capacity of 1,000 entries is used to handle data redundancy during network fluctuations. The data assembly and reporting unit encapsulates the fused data in a preset structure format, which includes event code, standardized component address, device description, timestamp and CRC16 checksum, and uploads it to the monitoring platform via TCP / IP protocol; The log storage module is used to store device operation logs and data conversion records, with a maximum storage capacity of 10,000 entries. Each log contains the source interface type, original data frame, converted data, reporting status, and timestamp, and supports local viewing and remote retrieval.

2. The device according to claim 1, characterized in that The protocol mapping relationship library of the dynamic protocol conversion engine contains mapping rules for 10 mainstream industrial protocols: Modbus, Profibus, CAN, Ethernet / IP, Profinet, EtherCAT, DeviceNet, CC-Link, M-Bus, and ZigBee. It supports converting the heterogeneous data of the fire host into a unified hexadecimal transmission format with "0x400x40" as the frame header and "0x23 0x23" as the frame footer. Among them, the Modbus protocol supports RTU / TCP variant conversion, the CAN protocol supports 2.0A / 2.0B frame format parsing, and the Ethernet / IP protocol supports explicit / implicit message conversion.

3. The device according to claim 1, characterized in that In the structure of the data assembly reporting unit, the standardized component address is stored in 4 bytes, of which the first 2 bytes store the hexadecimal value of the generalized node number in little-endian mode, and the last 2 bytes store the hexadecimal value of the generalized loop number in little-endian mode; the timestamp is stored in 6 bytes, corresponding to the BCD encoding format of "year-month-day-hour-minute-second".

4. The device according to claim 1, characterized in that It also includes a heartbeat keep-alive unit that sends a heartbeat frame containing the device's operating status, interface connection status, and remaining storage capacity to the monitoring platform every 1800 seconds. The heartbeat frame format is "0x40 0x40 + service serial number + protocol version number + time tag + source address + destination address + application data unit length + command word + information object + checksum + 0x23 0x23"; If no response is received for three consecutive times, the original TCP connection is automatically disconnected and reconnected, and communication fault logging is triggered.

5. The device according to claim 1, characterized in that The log storage module adopts a cyclic overwriting mechanism. When the storage capacity reaches 10,000 records, the oldest 10% of the records are automatically deleted. Supports filtering logs by event type and time range through device buttons or remote commands. Log export format is CSV, which includes the original data frame, converted data, report results and timestamp fields.

6. A method for implementing information transmission based on multi-protocol dynamic conversion and data fusion, using the device of claim 1, characterized in that: The following steps are involved: S1. Initialize the multi-protocol communication interface module, configure the interface parameters of the three communication units, and establish a communication connection with each fire host. The RS232 interface adapts to the Beida Jade Bird protocol data, and the RS485 interface adapts to the Modbus protocol Yiant host data. The interface parameters include baud rate, verification mode, and timeout period. S2. Receive raw data in real time and identify the protocol type through the data parsing unit: For RS232 data, parse the event type, component address, and GBK-encoded device description. For RS485 data using the Modbus protocol, parse the host address "01," command word "03," and valid data from the reply frame "01 03 04 0002 00 0E DA 37." S3. The dynamic protocol conversion engine calls the protocol mapping library to convert the parsed data into a unified format, in which the event type is mapped to a preset code, the component address is standardized to the "loop number - node number" format, and the device description is converted to UTF-8 encoding; the protocol mapping library supports bidirectional conversion of Modbus, Profibus, CAN, Ethernet / IP, Profinet, EtherCAT, DeviceNet, CC-Link, M-Bus, and ZigBee protocols, with a conversion delay of ≤10ms; S4. The data fusion unit deduplicates data from the same source with the same timestamp, retaining valid data based on priority. If network fluctuations occur, the data is stored in a cache pool and a retransmission mechanism is initiated, with the priority being: fire alarm > fault > status. S5. The data assembly reporting unit encapsulates the data in a structure format, which includes a 1-byte event code, a 4-byte standardized address, a 16-byte device description, a 6-byte timestamp, and a 1-byte CRC16 checksum. The data is uploaded to the monitoring platform via TCP / IP protocol. If the upload fails, a retransmission is triggered. S6. The log storage module records the key information of steps S2-S5 and generates a log containing the source interface type, original data frame, converted data and reporting status. When the number of logs reaches 10,000, the earliest record is automatically overwritten.

7. The method according to claim 6, characterized in that In step S3, the dynamic protocol conversion engine converts CAN protocol data through the following steps: parsing the CAN frame ID, data length code, and data field, mapping the frame type to a unified event identifier, and converting the data field into a standardized value in byte order; for Ethernet / IP protocol data, parsing the instruction-specific field in the message header, extracting I / O data, and mapping it to a preset data object.

8. The method according to claim 6, characterized in that In step S5, the transmission format of the structure uses "0x400x40" as the frame header and "0x23 0x23" as the frame trailer. The application data unit length field indicates the total number of bytes in the structure, and the command word field is set to 0x02 to indicate event reporting. The interaction process with the platform conforms to the timing logic of "registration → clock calibration → event reporting → heartbeat keepalive".

9. The method according to claim 6, characterized in that In step S2, parsing the RS232 data also includes: checking the integrity of the frame header "7E" and the frame footer "7E", calculating the checksum of the data segment, and discarding the frame and recording an error log if the check fails.

10. The method according to claim 6, characterized in that In step S4, the deduplication processing of the data fusion unit is based on the error tolerance range of ±100ms of the timestamp, and only the first occurrence record is retained for repeated events of the same source component address; the consistency integration process includes format verification, integrity check and range verification.

Images