A message parsing method, terminal device and storage medium based on Protobuf

Abstract

The present invention relates to a message parsing method based on Protobuf, a terminal device and a storage medium, wherein the method comprises: setting the format of the Protobuf protocol, adding a message type field, an optional message header field and an optional message body field in the message body; when parsing the message, firstly determining the message type to which the message belongs based on the message type field in the Protobuf protocol format, then selecting a message header corresponding to the message from the optional message header field according to the message type, then obtaining a routing name of the message according to a routing name field in the message corresponding to the message header, then selecting a message body corresponding to the message from the optional message body field according to the routing name, and finally obtaining a message body part of the message according to the message corresponding to the message body. The present invention improves the efficiency and accuracy of data exchange.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular to a message parsing method, terminal equipment and storage medium based on Protobuf. Background Art

[0002] In traditional ECG monitor data transmission, binary bit-hopping decoding is usually used, which not only requires rewriting the original code after the protocol is updated, but also makes the data parsing process cumbersome and lacks flexibility. With the development of intelligent medical equipment, efficient data transmission and parsing have become crucial. Summary of the invention

[0003] In order to solve the above problems, the present invention proposes a message parsing method, terminal device and storage medium based on Protobuf.

[0004] The specific plan is as follows:

[0005] A message parsing method based on Protobuf, comprising the following steps:

[0006] Set the format of the Protobuf protocol and add the message type field, optional message header field, and optional message body field to the message body;

[0007] The optional message header field contains the message header corresponding to each message type; the construction of the message of the message header type contains the routing name field corresponding to the message;

[0008] The optional message body field contains different message bodies. In the construction of a message of the message body type, if the message corresponding to the message body contains stream data, the traditional Protobuf message body structure is replaced by a unified structure applicable to all data parsing, and different data are distinguished by unique data encoding in the structure;

[0009] When parsing a message, first determine the message type based on the message type field in the Protobuf protocol format, then select the message header corresponding to the message from the optional message header field according to the message type, then obtain the routing name of the message according to the routing name field in the message corresponding to the message header, and then select the message body corresponding to the message from the optional message body field according to the routing name, and finally obtain the message body part of the message according to the message corresponding to the message body.

[0010] Furthermore, a basic information field is added to the message body, and the basic information field includes one or more of a version, a timestamp, a message ID, a device code, and a channel ID.

[0011] Furthermore, the message types include event messages, event confirmation messages, control messages, stream data messages, stream data confirmation messages, command request messages and command response messages, among which control messages are used to control the opening and closing of the connection channel between the monitor and the central workstation, and to maintain the connection heartbeat; event messages and event confirmation messages are messages corresponding to events issued by the monitor, and the events issued by the monitor include device online, offline and monitoring on; stream data messages and stream data confirmation messages are messages containing streaming data; command request messages and command response messages are messages issued by the central workstation.

[0012] Furthermore, the message of the message header type also includes one or more of an event or control coding field, a timestamp field, and a checksum field.

[0013] Furthermore, when obtaining the message body portion of the message according to the message corresponding to the message body, the values ​​of all fields contained in the message are obtained for each parameter in the message.

[0014] A message parsing terminal device based on Protobuf includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the method described above in an embodiment of the present invention are implemented.

[0015] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method described above in an embodiment of the present invention are implemented.

[0016] The present invention adopts the above technical solution and realizes more efficient and scalable data transmission between the monitor and the workstation by customizing a special data interface, thereby improving the efficiency and accuracy of data exchange. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 Shown is a flow chart of a method according to a first embodiment of the present invention. DETAILED DESCRIPTION

[0018] To further illustrate various embodiments, the present invention provides drawings. These drawings are part of the disclosure of the present invention, which are mainly used to illustrate the embodiments and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these contents, ordinary technicians in this field should be able to understand other possible implementations and advantages of the present invention.

[0019] The present invention will now be further described with reference to the accompanying drawings and specific implementation methods.

[0020] Embodiment 1:

[0021] This embodiment proposes a message parsing method based on Protobuf, such as Figure 1 As shown, it includes: setting the format of the Protobuf protocol, adding a message type field, an optional message header field and an optional message body field in the message body. The optional message header field contains a message header corresponding to each message type; the construction of the message of the message header type contains a routing name field corresponding to the message; the optional message body field contains different message bodies. In the construction of the message of the message body type, if the message corresponding to the message body contains stream data (stream data message type), the message body structure of the traditional Protobuf is replaced by a unified structure applicable to all data parsing, and different data are distinguished by the unique code (code) of the data in the structure. When parsing the message, first determine the message type to which the message belongs based on the message type field in the Protobuf protocol format, then select the message header corresponding to the message from the optional message header field according to the message type, and then obtain the routing name of the message according to the routing name field in the message corresponding to the message header, and then select the message body corresponding to the message from the optional message body field according to the routing name, and finally obtain the message body part of the message according to the message corresponding to the message body.

[0022] Protobuf protocol is a data description language developed by Google for serializing structured data. Compared with traditional XML and JSON formats, Protobuf has smaller data volume, faster parsing speed, and better cross-platform performance. The communication protocol of this embodiment is based on the proto3 grammar of Protobuf, by defining rich message types (MessageType), and drawing on the design concept of HTTP protocol, using routing, header information, and the organization of message body, while realizing the cache and confirmation mechanism of messages, building a flexible and powerful communication framework, ensuring the high reliability and stability of data transmission between monitor and workstation.

[0023] The communication between the monitor and the central workstation is transferred through the corresponding parsing server. In this embodiment, the message body IotMessage based on the improved Protobuf protocol is constructed on the parsing server, and the specific definition is as follows:

[0024] message IotMessage{

[0025] uint32 version = 1;

[0026] uint64 timestamp = 2;

[0027] uint32 messageType=3;

[0028] uint64 messageId=4;

[0029] string deviceCode=5;

[0030] uint64 channelId=6;

[0031] oneof header{

[0032] EventMessageHeader eventMessageHeader=10;

[0033] StreamDataMessageHeader streamDataMessageHeader=11;

[0034] CommandRequestMessageHeader commandRequestMessageHeader=12;

[0035] CommandResponseMessageHeader commandResponseMessageHeader=13;

[0036] ControlMessageHeader controlMessageHeader=14;

[0037] }

[0038] oneof body{

[0039] MonitorMeasureData monitorMeasureData=100;

[0040] MonitorWaveData monitorWaveData=101; ...

[0042] }

[0043] }

[0044] IotMessage in the protocol is the core message structure, which contains fields such as version, timestamp, message type, message ID, device code, and channel ID, and implements optional message header fields and optional message body fields through one of. The request interaction between various devices is mainly based on IotMessage. Next, the composition attributes of IotMessage are introduced one by one.

[0045] Message Type definition:

[0046] 0x00000000Control message (control message);

[0047] 0x00010000Event message (event message);

[0048] 0x00010100Event ACK message (event confirmation message);

[0049] 0x00020000StreamData message (stream data message);

[0050] 0x00020100StreamData ACK message (stream data confirmation message);

[0051] 0x00040000 Command request message (command request message);

[0052] 0x00080000Command response message (command response message).

[0053] This embodiment defines different message types and their corresponding values ​​through MessageType to distinguish the types of messages. Each message type has its specific application scenario. 0x00000000 is a control message type, which is used to control the opening and closing of the connection channel between the monitor and the central workstation, as well as the maintenance of the connection heartbeat. 0x00010000 and 0x00010100 are used to receive unilateral push information of the monitor hardware push event class, and 0x00020000 and 0x00020100 are used to process and receive response stream data such as ECG waveform data, respiratory data, carbon dioxide and other streaming data. 0x00040000 and 0x00080000 are the message types for the central workstation to send commands to the hardware terminal. The message body corresponding to each corresponding message type is as follows.

[0054] message ControlMessageHeader{

[0055] string name = 1;

[0056] string controlId = 2;

[0057] uint64 timestamp = 3;

[0058] map<string,string> metas=4;

[0059] }.

[0060] ControlMessageHeader defines the header information of the control message (i.e., the message header), including the routing name (name), control ID (controlId), timestamp (timestamp), and metadata (metas).

[0061] message EventMessageHeader{

[0062] string name = 1;

[0063] string eventId = 2;

[0064] uint64 timestamp = 3;

[0065] map<string,string> metas=4;

[0066] uint32 flag = 5; / / 1st-2nd QOS service quality

[0067] }.

[0068] message StreamDataMessageHeader{

[0069] string name = 1;

[0070] string streamId = 2;

[0071] uint64 timestamp = 3;

[0072] map<string,string> metas=4;

[0073] uint64 seq = 5;

[0074] uint32 flag = 6; / / 1st-2nd bit QOS service quality; 3rd bit SYC first message; 4th bit FIN last message;

[0075] }.

[0076] EventMessageHeader and StreamDataMessageHeader define the header information of event and stream data messages, including name, event ID, timestamp, metadata, and flag.

[0077] message CommandRequestMessageHeader{

[0078] string name = 1;

[0079] string commandId = 2;

[0080] uint64 timestamp = 3;

[0081] map<string,string> metas=4;

[0082] uint64 expiredTimestamp=5;

[0083] }.

[0084] message CommandResponseMessageHeader{

[0085] string name = 1;

[0086] string commandId = 2;

[0087] uint64 timestamp = 3;

[0088] map<string,string> metas=4;

[0089] uint32 code = 5;

[0090] string msg = 6;

[0091] }.

[0092] CommandRequestMessageHeader and CommandResponseMessageHeader define the header information of the command request and response, including command name, command ID, timestamp, metadata, expiration timestamp (msg), and response code (code).

[0093] The name in the above Header message header is similar to the http route. Different names are like different routes that will transmit different message bodies. The specific names of the Header header are introduced as follows:

[0094] Control message definition (name field of ControlMessageHeader):

[0095] control / v1 / ping heartbeat ping;

[0096] control / v1 / pong heartbeat pong;

[0097] control / v1 / close to close;

[0098] control / v1 / channel / open opens the Channel; ...

[0100] The Header message header of the control message type is defined as above, including the opening and closing control of the connection channel, as well as the connection heartbeat ping and pong keep-alive messages, etc., which are mainly used to maintain the connection status between the monitor and the central workstation.

[0101] Event message type definition (name field of EventMessageHeader):

[0102] event / v1 / device / online device online event;

[0103] event / v1 / device / offline: device offline event; ...

[0105] The Header of the event message summarizes all the events that the monitor will send, such as device online, offline, monitoring start, etc.

[0106] StreamData type definition (name field of EventMessageHeader):

[0107] stream / v1 / device / logcat / data device log data stream;

[0108] stream / v1 / monitor / realtime / data monitors real-time data; ...

[0110] The Header message header of the StreamData message defines different types of stream data, such as device logs and real-time monitoring data.

[0111] Command type definition (name field of CommandRequestMessageHeader and CommandResponseMessageHeader):

[0112] command / v1 / system / datetime / synchronization date and time synchronization;

[0113] command / v1 / upgrade / query upgrade query; ...

[0115] The Header of the Command message defines different types of command requests and responses, and is used by the central workstation to issue related named operations to the monitor hardware, such as system time synchronization, upgrade query, parameter adjustment, etc. This design allows accurate tracking and management of commands, thereby enabling the workstation to issue commands to the monitor for communication.

[0116] In the message body, the structure of the traditional Protobuf is defined according to different structures for different parameters (i.e. one structure for one type of data). Parameters belonging to different data structures need to define two structures. When adding parameters and attributes later, the overall ProtoBuf structure still needs to be constantly adjusted and packaged, which is very unrobust. In order to solve this problem, this embodiment abstracts, classifies, and merges the relevant event measurement data, abstracts the characteristic attributes of various waveforms and measurements, and provides a comprehensive description of the monitoring data through a unified structure combined with different type codes, realizing the scalability of the structure. The specific structure is as follows:

[0117] Traditional protocol format:

[0118] message MonitorECGData{ / / ECG real-time data

[0119] bytes ecgData = 1;

[0120] int32 hr = 2;

[0121] float st1 = 3;

[0122] float st2 = 4; ...

[0124] }

[0125] message MonitorSpo2Data{ / / Real-time blood oxygen data

[0126] bytes spo2Data = 1;

[0127] int32 spo2 = 2;

[0128] int32 pr = 3; ...

[0130] }

[0131] message MonitorBPData{ / / Real-time blood pressure data

[0132] int32 year = 1;

[0133] int32 month=2;

[0134] int32 day = 3;

[0135] int32 hour = 4; ...

[0137] }

[0138] The improved protocol format of this embodiment is as follows:

[0139] message MonitorMeasureData{

[0140] uint32 code=1; / / parameter unique code

[0141] optional int32 valueType=2; / / data type

[0142] oneof value{

[0143] int64 integerValue = 50;

[0144] double floatValue = 51;

[0145] string stringValue = 52;

[0146] }

[0147] optional uint32 unitCode=3; / / unit code

[0148] optional double upperLimit=4;

[0149] optional double lowerLimit=5;

[0150] optional int32 alarmLevel=6;

[0151] uint32 stateFlag = 7;

[0152] map<string,string> meta=8;

[0153] oneof property{

[0154] MonitorMeasureNIBPProperty monitorMeasureNIBPProperty=70;

[0155] }

[0156] }

[0157] message MonitorWaveData{

[0158] uint32 code=1; / / waveform unique code

[0159] optional bytes valueBytes=2;

[0160] optional uint32 unitCode=3; / / unit code

[0161] optional double unitPerValue = 4; / / The value represented by each unit

[0162] optional uint32 samplingFrequency = 5; / / sampling rate

[0163] optional int32 valueByteType=6; / / value byte type

[0164] optional double zeroValue=7; / / 0 value

[0165] optional double maxValue=8; / / maximum value

[0166] optional double minValue=9; / / minimum value

[0167] optional float gain = 10; / / gain

[0168] optional float tachometer = 11; / / walking speed

[0169] uint32 stateFlag = 12;

[0170] map<string,string> meta=13;

[0171] } ...

[0173] Each end uniformly maintains the corresponding protocol Code encoding. For example, the code value of the HR heart rate value ECG_HR is defined as 1101, and the code value of ST1 is defined as 1104. The required data is extracted from them through different codes, thereby achieving the overall reuse of the same structure. The impact of subsequent changes on each user end will be minimal.

[0174] Alarm related data structure definition:

[0175] message MonitorTechAlarmData{

[0176] uint64 timestamp = 1;

[0177] uint32 code = 2;

[0178] optional double value = 3;

[0179] optional int32 alarmLevel=4;

[0180] optional double upperLimit=5;

[0181] optional double lowerLimit=6;

[0182] uint32 stateFlag = 7;

[0183] optional string name = 8;

[0184] optional uint32 unitCode=9; / / unit code

[0185] uint64 eventId = 10;

[0186] optional uint32 triggerType = 11; / / trigger type

[0187] }

[0188] message MonitorEventAlarmData{

[0189] uint64 timestamp=1; / / time when physiological event occurs uint32 code=2; / / physiological event code

[0190] optional double value=3; / / Physiological event measurement value optional int32 alarmLevel=4; / / Physiological event alarm level optional double upperLimit=5; / / Alarm maximum threshold optionaldouble lowerLimit=6; / / Alarm minimum threshold

[0191] uint32 stateFlag = 7; / / status bit

[0192] optional string name=8; / / alarm

[0193] }

[0194] The same is true for alarm and event processing. By abstracting alarm-related attributes, detailed description and processing of technical alarms and physiological event alarms are realized, including alarm levels, thresholds, status flags, etc.

[0195] On the basis of a stable and reasonable data structure, the structure integrates error codes and service quality, defines global error codes and business error codes, and facilitates error handling and debugging. At the same time, through the quality of service (QOS) flag, the message cache and confirmation mechanism can be implemented to ensure the reliability of data transmission.

[0196] The Protobuf-based communication protocol proposed in this embodiment not only improves the efficiency of data transmission between the monitor and the central workstation, but also provides strong support for future medical device communications through its high scalability.

[0197] Embodiment 2:

[0198] The present invention also provides a Protobuf-based message parsing terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps in the above-mentioned method embodiment of the first embodiment of the present invention when executing the computer program.

[0199] Further, as an executable solution, the Protobuf-based message parsing terminal device can be a computing device such as a desktop computer, a notebook, a PDA, and a cloud server. The Protobuf-based message parsing terminal device may include, but is not limited to, a processor and a memory. Those skilled in the art will appreciate that the composition structure of the above-mentioned Protobuf-based message parsing terminal device is merely an example of a Protobuf-based message parsing terminal device, and does not constitute a limitation on the Protobuf-based message parsing terminal device, and may include more or less components than the above, or a combination of certain components, or different components. For example, the Protobuf-based message parsing terminal device may also include input and output devices, network access devices, buses, etc., and the embodiments of the present invention do not limit this.

[0200] Further, as an executable solution, the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the Protobuf-based message parsing terminal device, and uses various interfaces and lines to connect the various parts of the entire Protobuf-based message parsing terminal device.

[0201] The memory can be used to store the computer program and / or module, and the processor realizes various functions of the message parsing terminal device based on Protobuf by running or executing the computer program and / or module stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function; the data storage area can store data created according to the use of the mobile phone, etc. In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0202] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method in the embodiment of the present invention are implemented.

[0203] If the module / unit integrated in the Protobuf-based message parsing terminal device is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-OnlyMemory), random access memory (RAM, Random Access Memory) and software distribution medium, etc.

[0204] Although the present invention has been specifically shown and described in conjunction with the preferred embodiments, it should be understood by those skilled in the art that various changes may be made to the present invention in form and details without departing from the spirit and scope of the present invention as defined by the appended claims, all of which are within the scope of protection of the present invention.

Claims

1. A message parsing method based on Protobuf, characterized in that: The following steps are involved: Set the format of the Protobuf protocol and add the message type field, optional message header field, and optional message body field to the message body; The optional message header field contains the message header corresponding to each message type; the construction of the message of the message header type contains the routing name field corresponding to the message; The optional message body field contains different message bodies. In the construction of a message of the message body type, if the message corresponding to the message body contains stream data, the traditional Protobuf message body structure is replaced by a unified structure applicable to all data parsing, and different data are distinguished by unique data encoding in the structure; When parsing a message, first determine the message type based on the message type field in the Protobuf protocol format, then select the message header corresponding to the message from the optional message header field according to the message type, then obtain the routing name of the message according to the routing name field in the message corresponding to the message header, and then select the message body corresponding to the message from the optional message body field according to the routing name, and finally obtain the message body part of the message according to the message corresponding to the message body.

2. The message parsing method based on Protobuf according to claim 1, characterized in that: A basic information field is also added to the message body, and the basic information field includes one or more of a version, a timestamp, a message ID, a device code, and a channel ID.

3. The message parsing method based on Protobuf according to claim 1, characterized in that: Message types include event messages, event confirmation messages, control messages, stream data messages, stream data confirmation messages, command request messages and command response messages. Among them, control messages are used to control the opening and closing of the connection channel between the monitor and the central workstation, and to maintain the connection heartbeat; event messages and event confirmation messages are messages corresponding to events sent by the monitor. Events sent by the monitor include device online, offline and monitoring on; stream data messages and stream data confirmation messages are messages containing streaming data; command request messages and command response messages are messages sent by the central workstation.

4. The message parsing method based on Protobuf according to claim 1, characterized in that: The message of the message header type also includes one or more of an event or control code field, a timestamp field, and a checksum field.

5. The message parsing method based on Protobuf according to claim 1, characterized in that: When obtaining the message body portion of the message according to the message corresponding to the message body, the values ​​of all fields contained in the message are obtained for each parameter in the message.

6. A message parsing terminal device based on Protobuf, characterized in that: The method comprises a processor, a memory and a computer program stored in the memory and running on the processor, wherein the processor implements the steps of any one of the methods of claims 1 to 5 when executing the computer program.

7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images