CN113434437B

CN113434437B - Interface protocol data analysis method and system

Info

Publication number: CN113434437B
Application number: CN202110984705.1A
Authority: CN
Inventors: 崔岩; 彭栋; 张玙; 郭军强; 陈志强; 曹雅鑫; 邓一兵
Original assignee: CRSC Research and Design Institute Group Co Ltd
Current assignee: CRSC Research and Design Institute Group Co Ltd
Priority date: 2021-08-26
Filing date: 2021-08-26
Publication date: 2022-04-12
Anticipated expiration: 2041-08-26
Also published as: CN113434437A

Abstract

The invention discloses an interface protocol data analysis method and a system, wherein the analysis method comprises the following steps: loading all second-level FieldDef nodes under the first-level structDefinitions node in the interface protocol data to form a second-level FieldDef node set; judging whether the secondary FieldDef node set is empty or not; if not, sequentially taking out a secondary FieldDef node from the secondary FieldDef node set in sequence, and deleting the secondary FieldDef node from the secondary FieldDef node set; judging whether the secondary FieldDef node contains a reference field and the field value is true; if so, finding a secondary structDef node with the same field value as the secondary FieldDef node identity; judging whether the structtype field value under the secondary structDef node is virtual; if so, starting a virtual type structDef analysis process; if not, starting a structDef analysis process of the struct type; after the analysis process is completed, judging whether the bit number of the analyzed bit stream interface protocol data is equal to the length of the bit stream interface protocol data; if so, the analysis flow ends. And analyzing the interface protocol data in various forms by taking bit as the minimum analysis unit.

Description

Interface protocol data analysis method and system

Technical Field

The invention belongs to the field of train control system testing, and particularly relates to an interface protocol data analysis method and system.

Background

When the train control system is tested, a peripheral simulator of the tested device needs to be developed, test data is injected into the tested device, a test scene is constructed, the feedback of the tested device is received, and test judgment is carried out. Interface protocol data parsing is one of the key links.

The purpose of interface protocol data parsing is to convert received test data in the form of a byte stream into readable user data that can be understood by a tester. The existing interface protocol data analysis method is usually realized by adopting a code writing mode, and a set of codes is specially developed for analyzing the interface protocol data aiming at each interface protocol. The code writing workload is large, the time is long, and the test of the train control system is seriously dependent on the development progress of developers. The code writing often has defects, testers find the defects in the using process and need to feed back to developers for modification, and the efficiency is low. The code is repeatedly written, so that the code is redundant and difficult to maintain. Therefore, it is desirable to develop a method and a system for analyzing interface protocol data, which can analyze multiple interface protocol data and improve the test efficiency of the train control system.

Disclosure of Invention

Aiming at the problems, the invention discloses an interface protocol data analysis method, which comprises the following steps:

loading all second-level FieldDef nodes under the first-level structDefinitions node in the interface protocol data to form a second-level FieldDef node set;

judging whether the secondary FieldDef node set is empty or not;

if not, sequentially taking out a secondary FieldDef node from the secondary FieldDef node set in sequence, and deleting the secondary FieldDef node from the secondary FieldDef node set;

judging whether the secondary FieldDef node comprises a reference field and the field value is true;

if so, finding a secondary structDef node with the same field value as the secondary FieldDef node identity;

judging whether the structtype field value under the secondary structDef node is virtual;

if so, starting a virtual type structDef analysis process; if not, starting a structDef analysis process of the struct type;

after the structDef analysis process of the virtual type or the struct type is completed, judging whether the bit number of the analyzed bit stream interface protocol data is equal to the length of the bit stream interface protocol data; if so, the analysis flow ends.

Furthermore, the following steps are carried out before all the second-level FieldDef nodes under the first-level structDefinitions node in the interface protocol data are loaded to form a second-level FieldDef node set:

and converting the byte stream interface protocol data to be analyzed into bit stream interface protocol data to obtain the length of the bit stream interface protocol data.

Further, the determining whether the secondary FieldDef node includes a reference field and the field value is true further comprises:

if not, acquiring a bits field value L of the secondary FieldDef node;

taking the nth bit to the (n + L) th bit from the bit stream interface protocol data as the value of the secondary FieldDef node, and then analyzing the taken value;

judging whether the bit number of the analyzed bit stream interface protocol data is equal to the length of the bit stream interface protocol data; if so, the analysis is ended.

Furthermore, n is the data bit number of the resolved bit stream interface protocol; when the analysis is started, n is 0.

Further, the structDef parsing process of struct type includes the following steps:

loading all three levels of FieldDef nodes under the two levels of structDef nodes to form a first three levels of FieldDef node set;

judging whether the first third-level FieldDef node set is empty or not;

if not, sequentially taking out a third-level FieldDef node from the first third-level FieldDef node set in sequence, and deleting the third-level FieldDef node from the first third-level FieldDef node set;

acquiring a bits field value L of a third-level FieldDef node taken out from the first third-level FieldDef node set, taking an nth bit to an nth + L bit from bit stream interface protocol data as a value of the third-level FieldDef node taken out from the first third-level FieldDef node set, and then analyzing the taken value;

judging whether the bit number of the analyzed bit stream interface protocol data is equal to the length of the bit stream interface protocol data or whether the first three-level FieldDef node set is empty; if yes, returning the data bit number n of the analyzed bit stream interface protocol.

Further, the StructDef parsing flow of the virtual type includes the following steps:

loading all three levels of FieldDef nodes under the two levels of structDef nodes to form a second three levels of FieldDef node set;

judging whether the second third-level FieldDef node set is empty or not;

if not, sequentially taking out a third-level FieldDef node from the second third-level FieldDef node set in sequence, and deleting the third-level FieldDef node from the second third-level FieldDef node set;

finding a first secondary structDef node with the same value as the identity field of the third-level FieldDef node extracted from the second third-level FieldDef node set;

loading all three levels of FieldDef nodes under the first and second levels of structDef nodes to form a third level of FieldDef node set;

judging whether the third-level FieldDef node set is empty or not;

if not, sequentially taking out a third-level FieldDef node from the third-level FieldDef node set in sequence, and deleting the third-level FieldDef node from the third-level FieldDef node set;

judging whether the third-level FieldDef nodes extracted from the third-level FieldDef node set contain an attribute field and the field value is true;

if so, acquiring a bits field value L of the third-level FieldDef node taken out from the third-level FieldDef node set, taking Ntemp bit to Ntemp + L bit from bit stream interface protocol data as a value of the third-level FieldDef node taken out from the third-level FieldDef node set, and then analyzing the taken value;

judging whether the analyzed value is consistent with the val field value of the first secondary structDef node;

if so, starting a structDef analysis process of the struct type.

Further, the interface protocol data includes a fixed frame header and a packet list.

Further, the fixed frame header includes a packet and a field.

Further, the packet list includes packets and fields.

Further, the packet includes a field.

An interface protocol data parsing system, comprising:

the loading unit is used for loading all second-level FieldDef nodes under the first-level structDefinitions nodes in the interface protocol data to form a second-level FieldDef node set;

a judging unit, configured to judge whether the second-level FieldDef node set is empty, judge whether the second-level FieldDef node includes a reference field and a field value is true, judge whether a structtype field value under the second-level StructDef node is virtual, or judge whether a bit number of parsed bit stream interface protocol data is equal to a length of the bit stream interface protocol data; if so, ending the analysis process;

an obtaining unit, configured to sequentially take out a secondary field def node from the secondary field def node set in order, and delete or find a secondary StructDef node having a same field value as the secondary field def node identity field value from the secondary field def node set;

and the parsing unit is used for starting a structDef parsing flow of a virtual type or starting a structDef parsing flow of a struct type.

Further, it is particularly useful for:

Compared with the prior art, the invention has the beneficial effects that: the interface protocol data analysis method and system provided by the invention can analyze interface protocol data in various forms by taking bit as the minimum analysis unit, can support dynamic analysis based on information type numbers, has better applicability, effectively reduces development workload, avoids repeated code development for each interface protocol, and improves the overall efficiency of train control system testing.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and those skilled in the art can also obtain other drawings according to the drawings without creative efforts.

FIG. 1 shows a schematic diagram of a simulator architecture according to an embodiment of the invention;

FIG. 2 illustrates a flow diagram for a simulator receiving test data according to an embodiment of the invention;

FIG. 3 shows a flow diagram for simulator transmit test data according to an embodiment of the invention;

FIG. 4 illustrates an interface protocol data structure diagram according to an embodiment of the invention;

FIG. 5 illustrates a tree structure diagram of interface protocol data according to an embodiment of the present invention;

FIG. 6 illustrates an interface protocol data parsing flow diagram according to an embodiment of the invention;

FIG. 7 illustrates a structDef parsing flow diagram for struct types according to an embodiment of the invention;

fig. 8 illustrates a flow chart of StructDef parsing of virtual type according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The invention provides a train control system-oriented simulator automatic generation method, which comprises the following steps:

analyzing the protocol description file;

initializing and starting a protocol processing unit according to the application protocol in the protocol description file;

initializing and starting a safety function unit according to a safety protocol in the protocol description file;

and initializing and starting the communication functional unit according to the communication protocol in the protocol description file.

Fig. 1 shows a schematic diagram of a simulator structure according to an embodiment of the invention. As shown in fig. 1, based on the above method for automatically generating a simulator for a train control system, an automatic generation system for a simulator for a train control system is provided, which includes: the system comprises a protocol processing unit, a safety function unit, a communication function unit, an interface generation unit and a program control unit;

a protocol processing unit: the protocol description file is used for analyzing the protocol description file, and initializing and starting the communication functional unit according to the communication protocol configuration described in the protocol description file; initializing and starting a safety function unit according to the safety protocol configuration in the protocol description file; initializing and starting an application protocol processing function of the device according to the application protocol configuration in the protocol description file;

the interface generation unit is used for periodically receiving the test data to be analyzed after the safety verification sent by the safety function unit, forwarding the test data to be analyzed to the interface generation unit and displaying the received interface protocol data; forwarding to the program control unit and further sending to an external program (such as an automatic test program);

and the interface control unit is used for periodically sending test data to the safety function unit and responding to control instructions of the interface generation unit and the program control unit to control communication connection or update the test data.

A safety function unit: the device is used for starting RSSP-1 and RSSP-2 protocol stacks or not starting related functions according to the safety protocol configuration analyzed by the protocol processing unit;

the system comprises a communication functional unit, a data processing unit and a data processing unit, wherein the data processing unit is used for periodically receiving test data sent by the communication functional unit and carrying out redundancy removal and safety protocol check on the test data according to a safety communication protocol; if the test data passes the verification, sending the test data to the protocol processing unit; if the test data fails to be verified, triggering a processing rule specified by a secure communication protocol;

and the safety function layer encapsulation module is used for periodically receiving the test data sent by the protocol processing unit, encapsulating the safety function layer of the test data according to the safety communication protocol and then sending the test data to the communication function unit.

A communication function unit: the system comprises a protocol processing unit, a TCP and UDP communication connection unit and a communication connection unit, wherein the protocol processing unit is used for analyzing the communication protocol configuration of the TCP and UDP communication connection unit;

the device is used for periodically receiving the test data sent by the tested device and forwarding the test data to the safety function unit;

and the device is used for periodically receiving the test data sent by the safety function unit and sending the test data to the tested device.

An interface generation unit: the system comprises a protocol processing unit, a data processing unit and a data processing unit, wherein the protocol processing unit is used for analyzing test data;

the system is used for responding to the operation of a user on the protocol tree and sending a control instruction to the protocol processing unit;

and the protocol processing unit is used for receiving and displaying the test data from the tested equipment sent by the protocol processing unit.

A program control unit: the system is used for supporting the telnet interface to connect with an external program;

the automatic test interface data is used for analyzing the automatic test interface data sent by the external program and forwarding the automatic test interface data to the protocol processing unit;

the device is used for receiving the test data from the tested device sent by the protocol processing unit and sending the test data to an external program.

FIG. 2 shows a flow diagram for a simulator receiving test data according to an embodiment of the invention. As shown in fig. 2, the specific flow of the simulator receiving the test data is as follows:

the communication functional unit receives test data;

the safety function unit removes redundant data and carries out safety check;

the protocol processing unit analyzes the test data;

interface display of an interface generation unit;

the programming unit sends to an external program.

FIG. 3 shows a flow diagram for simulator transmit test data according to an embodiment of the invention. As shown in fig. 3, the specific flow of sending test data by the simulator is as follows:

the program control unit receives an external program instruction to update test data;

the interface generation unit responds to manual operation to update the test data;

the protocol processing unit encapsulates the test data;

the safety function unit carries out safety layer encapsulation on the test data;

the communication function unit sends test data to the device under test.

Fig. 4 shows a schematic diagram of an interface protocol data structure according to an embodiment of the invention. As shown in fig. 4, the present invention provides an interface protocol data transceiving method, which includes the following steps:

the interface protocol data is as follows: describing structures of an element structDefinitions, a field FieldDef, a structure structDef and a value ValueDef;

generating 16-system byte stream interface protocol data according to the value of each field in the interface protocol data and the description format of the interface protocol data;

sending the byte stream interface protocol data to the tested equipment;

and the tested device receives the byte stream interface protocol data.

As shown in fig. 4, the interface protocol data includes a fixed frame header and a packet list; the fixed frame header comprises an information packet and a field; the information packet list comprises information packets and fields; the information packet comprises fields; the field includes a value. According to the structure of the interface protocol data, the elements defining the corresponding XML are exemplarily explained.

< FieldDef fixed frame header/>)

< FieldDef packet List/>)

< structDef fixed frame header >

< FieldDef field 1/>)

< FieldDef field 2/>)

< FieldDef field n/>)

</StructDef>

< structDef packet List >

< FieldDef packet 1/>)

< FieldDef packet 2/>)

< FieldDef packet n/>)

</StructDef>

< structDef packet 1>

< FieldDef field 1>

< ValueDef value 1>

</FieldDef field 1>

< FieldDef field 2/>)

</StructDef>

</StructDefinitions>

StructDefinations describes the most basic information of interface protocol data, the type of device that sends and receives the interface protocol data. The specific attributes of the element structdefins are shown in table 1.

Wherein messaging refers to receiving and sending messages. The train operation control system is called a train control system for short, takes a CTCS-3 level train control system as an example, and mainly comprises ground equipment and vehicle-mounted equipment. The ground equipment comprises a track circuit, a transponder, a train control center system (TCC), a temporary speed limiting server system (TSRS) and a Radio Block Center (RBC). Train control system peripherals include computer interlocking systems (CBI) and dispatch centralization systems (CTC). The vehicle-mounted equipment generally refers to equipment, an automatic train protection device ATP.

FieldDef describes a field, which may be a fixed header, a packet list, a specific packet, or a specific field contained in a packet, contained in interface protocol data. The specific properties of the field FieldDef are shown in table 2.

The StructDef describes a structure, is a description of a fixed frame header, a packet list or a specific packet, and describes the name and type of the specific structure through attributes. Specific properties of the structure StructDef are shown in table 3.

The ValueDef defines a value, which is a specific value of a field contained in a packet. The value can be one or more. A value is a specific optional sub-element when a field is used as a field. The specific attributes of the value ValueDef are shown in table 4.

Wherein, the value represents the value range of the field value.

Fields except the ValueDef definition value are illegal, and validity check can be carried out on the values of the fields.

The following exemplarily illustrates the above interface protocol data by taking a packet sent by the RBC to the TSRS as an example:

< structDefinitions identification = "RBCToTSRSTelegram" tips = "RBC and TSRS communication protocol" enutp = "RBC and TSRS Telegram" >)

< structDef identity = "TelegramHeader" structtype = "struct" tip = "Packet Header" enutp = "Packet Header" >)

< FieldDef identity = "MessageType" defaultVal = "0x8004" at = "1" bits = "16" tip = "Message Type" Enutip = "Message Type"/>

< FieldDef identity = "srctcsid" defaultVal = "0x00000000" at = "2" bits = "32" tip = "Sender designation" enutip = "Sender Mark"/>)

< FieldDef identity = "DesCTCSID" defaultVal = "0x00000000" at = "3" bits = "32" tip = "receiver designation" enutp = "receivemark"/>)

< FieldDef identity = "Version" defaultVal = "0x01000000" at = "4" bits = "32" tip = "protocol Version, and the current protocol Version is 0x01" enutip = "System Version"/> "

< FieldDef identity = "PacketNum" defaultVal = "0x0001" at = "5" bits = "16" tip = "number of application packets" enutp = "The total number of packets in this application packet"/>

< FieldDef identity = "GroupPos" defaultVal = "0xFFFF" at = "6" bits = "16" tip = "intra-Group position" enutp = "Group position" FiledType = "ENUM" >, and "location" position ">, respectively

< ValueDef identity = "0" tip = "First Message in Group" enutp = "First Message in Group"/> "within Group

< ValueDef identity = "1" tip = "position of message in group within group" enutp = "The group contacts one message"/> ", where The message is in The group

< ValueDef identity = "2" tip = "message is in The group's value corresponding position" enutp = "The position of message in The group"/> ", in The group

< ValueDef identity = "65521" tip = "Last message in The group" enutp = "The Last message in The group"/>

< ValueDef identity = "65535" tip = "group has only One message" enuip = "One message in the group"/> ", in the group

</FieldDef>

</StructDef>

</StructDef>

< structDef identity = "Status" structtype = "struct" val = "0x03" default = "true" tip = "TSR Status" enutp = "TSR Status" >)

< FieldDef identity = "Reserve" at = "1" bits = "16" tip = "reservation" enutip = "Reserve"/>)

< FieldDef identity = "m _ messageLength" at = "2" bits = "16" islength = "true" tip = "Packet Length" envutip = "Packet Length"/>)

< FieldDef identity = "information type" at = "3" bits = "16" type = "true" defaultVal = "0x0003" tip = "information type" enuthip = "Message type"/>)

< field def identity = "RBC" at = "4" bits = "32" tip = "device identification, CTCS ID of RBC" enutip = "Equipment Mark" printbegin = "true"/>, and

< FieldDef identity = "TSR" at = "5" bits = "8" tip = "TSR Number" enutip = "TSR Number"/>)

< FieldDef identity = "exstatus" at = "6" bits = "8" tip = "execution state" enutp = "Excute Status" FiledType = "ENUM" >)

< ValueDef identity = "0" tip = "No Information" enutp = "No Information"/>)

< ValueDef identity = "85" tip = "authentication Success" enutp = "Verification Success"/>)

< ValueDef identity = "165" tip = "execution Success" enutp = "Execute Success"/>)

</FieldDef>

< FieldDef identity = "v" at = "7" bits = "8" tip = "Speed Limit value" enutip = "Limit Speed" existby = "exstatus" existwhen = "85,165" FiledType = "ENUM" >)

</FieldDef>

< FieldDef identity = "Reason" at = "8" bits = "8" tip = "Speed Limit cause" enutrip = "Limit Speed person" existby = "existtus" existwhen = "85,165" FiledType = "ENUM" >)

< ValueDef identity = "0" tip = "unknown" enutp = "Unknow"/>)

< ValueDef identity = "1" tip = "construction" Enutip = "construction"/>)

< ValueDef identity = "2" tip = "wind, rain and snow" enutp = "monitor"/>)

< ValueDef identity = "3" tip = "sudden disaster" enutp = "Outburst"/>)

</FieldDef>

< FieldDef identification = "dpatch" at = "9" bits = "128" tip = "scheduling Command number, assigned by CTC dispatcher, string format" enutip = "Dispatch Order" existby = "exstatus" existwhen = "85,165"/>

< FieldDef identity = "CTC" at = "10" bits = "32" tip = "operator ID, CTCS ID of CTC/TCC (4 bytes)" enutip = "Dispatch Order" existby = "exstatus" existwhen = "85,165"/>, and CTC/TCC

< FieldDef identity = "user" at = "10" bits = "16" tip = "operator ID, user number (2 bytes)" enutip = "Dispatch Order" existby = "exstatus" existwhen = "85,165"/> ", user number (2 bytes)" enutip = "Dispatch Order" existby = "existhus =

< FieldDef identity = "stn" at = "11" bits = "32" tip = "order Station Number" Enutip = "receiving Instruction Station Number" existby = "ending Instruction Station Number" existby = "existstus" existwhen = "85,165"/>)

< FieldDef identity = "Line" at = "12" bits = "8" tip = "Line Number" enutip = "Line Number" existby = "exstatus" existwhen = "85,165"/>)

< FieldDef identity = "StLong" at = "13" bits = "16" tip = "starting Mileage Long Chain marker" enutip = "The mark of start Mileage Chain in" existby = "existstus" existwhen = "85,165"/>)

< FieldDef identity = "endLong" at = "14" bits = "16" tip = "Mileage Long Chain marker" enutip = "The mark of end Mileage Chain" existby = "exttutus" existwhen = "85,165"/>)

< FieldDef identity = "stCoord" at = "15" bits = "8" tip = "starting Mileage coverage flag" enutip = "Start Mileage Mark" existby = "existstatus" existwhen = "85,165"/> ", and

< FieldDef identity = "endCoord" at = "17" bits = "8" tip = "End Mileage cover flag" enutip = "End Mileage Mark" existby = "existtus" existwhen = "85,165"/>)

< FieldDef identity = "stPoint" at = "19" bits = "32" tip = "starting point milestone" enutip = "start mark" existby = "exstatus" existwhen = "85,165"/>)

< FieldDef identity = "endPoint" at = "20" bits = "32" tip = "end point milestone" enutip = "end mark" existby = "exstatus" existwhen = "85,165"/> ", and" end point milestone = "existwhen ="85,165 "/>", respectively

</StructDef>

< structDef identity = "Error" structtype = "struct" val = "0x05" default = "true" tip = "TSR Error Receipt" enut = "TSR Error Receipt" >)

< FieldDef identity = "information type" at = "3" bits = "16" type = "true" defaultVal = "0x0005" tip = "information type" enuthip = "Message type"/> ", and" information type "exit =" and "Message type"/> ", respectively

< field def identity = "rbc" at = "4" bits = "32" tip = "device identification" enutp = "Equipment Mark" print = "true"/> ", and

< FieldDef identity = "v" at = "6" bits = "8" tip = "Speed Limit value" Enutip = "Limit Speed" FiledType = "ENUM" >)

</FieldDef>

< FieldDef identity = "Reason" at = "7" bits = "8" tip = "Speed Limit Reason" enuthip = "Limit Speed Reason" FiledType = "ENUM" >)

< ValueDef identity = "0" tip = "unknown" enutp = "Unknow"/>)

< ValueDef identity = "1" tip = "construction" Enutip = "construction"/>)

< ValueDef identity = "2" tip = "wind, rain and snow" enutp = "monitor"/>)

< ValueDef identity = "3" tip = "sudden disaster" enutp = "Outburst"/>)

</FieldDef>

< FieldDef identification = "dpatch" at = "8" bits = "128" tip = "scheduling Command number, assigned by CTC dispatcher, string format" enutp = "Dispatch Order"/>

< FieldDef identity = "CTC" at = "10" bits = "32" tip = "operator ID, CTCS ID of CTC/TCC (4 bytes)" enutip = "Dispatch Order"/>)

< FieldDef identity = "user" at = "10" bits = "16" tip = "operator ID, user number (2 bytes)" enutip = "Dispatch Order"/> ", and

< FieldDef identity = "error" at = "10" bits = "8" tip = "error code" enutip = "ErrorCode" defaultVal = "1" FiledType = "ENUM" >)

< ValueDef identity = "1" tip = "line number" enutp = "LineID"/>)

< ValueDef identity = "2" tip = "mile marker Invalid" enutp = "Stcoord Invalid"/>)

< ValueDef identity = "3" tip = "Speed Limit Invalid" enutp = "Limit Speed Invalid"/>)

< ValueDef identity = "4" tip = "corresponding speed Limit command" enutip = "Limit Cmd No Find"/> "is not found

< ValueDef identity = "5" tip = "speed Limit Zone with Overlap" enutp = "Limit Zone Overlap"/> "

< ValueDef identity = "11" tip = "number Error" enutup = "TSR _ No Error"/>)

< ValueDef identity = "15" tip = "reservation" enutp = "Reserve"/>)

< ValueDef identity = '16' tip = 'speed limit command issue To command Station failure' enautip = 'Cmd Send To Station Failed'/>)

< ValueDef identity = "255" tip = "other Error" enutup = "Error"/>)

</FieldDef>

< FieldDef identity = "erparam" at = "11" bits = "32" tip = "Error Parameter" enutip = "Error Parameter" exitby = "Error Parameter" existby = "Error" existwhen = "1" FiledType = "ENUM" >)

< ValueDef identity = "0" tip = "Line number not in the RBC jurisdiction" enutp = "Line ID Error"/>

</FieldDef>

< FieldDef identity = "erparam" at = "12" bits = "32" tip = "Error Parameter" enutip = "Error Parameter" exitby = "Error Parameter" existby = "Error" existwhen = "2" FiledType = "ENUM" >)

< ValueDef identity = "1" tip = "starting milestone" enutip = "stPoint Error"/>)

< ValueDef identity = "2" tip = "end milestone" enutup = "end Point Error"/>)

< ValueDef identity = "3" tip = "start and end milestone" enutip = "stPoint and end Point Error"/>)

</FieldDef>

< FieldDef identity = "Errparam" at = "13" bits = "32" tip = "Error Parameter" enutip = "Error Parameter" exitby = "Error Parameter" existber "=" Error "existwhen ="3 "/>)

< FieldDef identity = "erparam" at = "14" bits = "32" tip = "Error Parameter" enutip = "Error Parameter" exitby = "Error Parameter" existby = "Error" existwhen = "4" FiledType = "ENUM" >)

< ValueDef identity = "1" tip = "Line number" enutp = "Line ID"/>)

< ValueDef identity = "2" tip = "origin milestone system" enutip = "stCoord Error"/>)

< ValueDef identity = "3" tip = "end mile marker system" enutip = "end coord Error"/>)

< ValueDef identity = "4" tip = "origin mile value" enutip = "stPoint Error"/>)

< ValueDef identity = "5" tip = "end mile value" enutip = "end Point Error"/>)

< ValueDef identity = "6" tip = "origin Long chain identifier" enututp = "stChain Error"/>)

< ValueDef identity = "7" tip = "end Long chain identifier" enututp = "EnChain Error"/>)

</FieldDef>

< FieldDef identity = "Errparam" at = "15" bits = "32" tip = "Error Parameter" enutip = "Error Parameter" exitby = "Error Parameter" existby = "Error" existwhen = "5"/>)

< FieldDef identity = "erparam" at = "16" bits = "32" tip = "Error Parameter" enutip = "Error Parameter" exitby = "Error Parameter" existby = "Error" existwhen = "11" FiledType = "ENUM" >)

< ValueDef identity = "1" tip = "TSR number disagreement" enutp = "TSR _ No Disaccord"/>)

< ValueDef identity = "2" tip = "No TSR No. Enutip =" TSR No. Invalid "/>) No such TSR number

< ValueDef identity = "3" tip = "TSR number occupied" enutp = "TSR _ No Occupy"/>)

</FieldDef>

< FieldDef identity = "Errparam" at = "17" bits = "32" tip = "Error Parameter" enutip = "Error Parameter" exitby = "Error Parameter" existber "=" Error "existwhen ="15 "/>)

< FieldDef identity = "Errparam" at = "18" bits = "32" tip = "Error parameter Account number" enutip = "Error: State ID" existby = "Error" existwhen = "16"/>)

< FieldDef identity = "Errparam" at = "19" bits = "32" tip = "Error parameter-parameter manufacturer Custom" enutip = "Error: Custom" existby = "errode" existhen = "255"/>)

</StructDef>

< structDef identity = "Info" structtype = "struct" val = "0x17" tip = "RBC Speed Limit status detection Information" enuthip = "TSR Check Limit Speed Information" >)

< FieldDef identity = "information type" at = "3" bits = "16" type = "true" defaultVal = "0x0017" tip = "information type" enuthip = "Message type"/> ", information type =" Message type "/>"

< FieldDef identity = "tsrsid" at = "5" bits = "32" tip = "Line Speed Confirm Mark" enutip = "Line Limit Speed Confirm Mark"/> ", initial Line Speed Limit state Confirm Mark =" Line Limit Speed Mark "/>"

< FieldDef identity = "stScope" at = "6" bits = "16" tip = "TSR usable flag range starting point" enutip = "/>"

< FieldDef identity = "endScope" at = "7" bits = "16" tip = "TSR usable flag range end point" enuthip = "/>)

< FieldDef identity = "numExecuted" at = "8" bits = "16" tip = "number of speed limits executed" enutp = "/>)

</StructDef>

</StructDefinitions>

The messages (interface protocol data, 16-ary system) sent by the RBC to the TSRS are specifically as follows:

80 04 00 00 00 00 00 00 00 00 01 00 00 00 00 01 FF FF 00 00 00 14 00 17 00 00 00 00 00 00 00 00 00 01 00 FF 00 00。

fig. 5 shows a schematic diagram of a tree structure of interface protocol data according to an embodiment of the invention. As shown in fig. 5, the interface protocol data is shown in a tree structure, and the StructDefinitions nodes include a fixed frame header TelegramHeader node and a packet list ApplicationPacket node.

The TelegramHeader node comprises 6 sub-nodes including a message type MessageType, a sender mark SrcCTCSID, a receiver mark DesCTCSID, a protocol Version, the number of application packets PacketNum and a group position GroupPos, and the sub-nodes are sequentially analyzed according to the sequence during analysis.

The ApplicationPacket node comprises a TSR state Status node, a TSR Error receipt Error node and an RBC speed limit state detection information Info node. The Status node comprises 19 sub-nodes including reserved Reserve, packet length m _ messageLength, information type InformationType, equipment identifier rbc, TSR number TSR, execution state extatus, speed limit value v, speed limit reason, scheduling command number dpatch, operator ID ctc, operator ID user, ordered station number stn, line number line, starting mileage long chain mark stLong, ending mileage long chain mark endLong, starting mileage system covering mark stCoord, ending mileage system covering mark endCoord, starting mileage mark stPoint and ending mileage mark endPoint, and the analysis is carried out sequentially according to the sequence. The Error node comprises 13 sub-nodes including a reserved Reserve, an information packet length m _ messageLength, an information type, a device identifier rbc, a TSR number TSR, an execution state extatus, a speed limit value v, a speed limit reason, a scheduling command number dpatch, an operator ID ctc, an operator ID user, an Error code errcode and an Error parameter errparam, and the analysis is carried out in sequence according to the sequence. The Info node comprises 8 sub-nodes including reserved Reserve, packet length m _ messageLength, information type InformationType, device identifier rbc, initial confirmation mark tsrsid of line speed limit state, starting point stScope of usable mark range of TSR, end terminal of usable mark range of TSR and number of executed speed limits numExecuted, and the nodes are sequentially analyzed according to the sequence during analysis.

Fig. 6 shows an interface protocol data parsing flow diagram according to an embodiment of the invention. The purpose of interface protocol data parsing is to convert received test data in the form of a byte stream into readable user data that can be understood by a tester. As shown in fig. 6, based on the above method for receiving and sending interface protocol data, the present invention further provides an interface protocol data analysis method, where the specific analysis process is as follows:

s601: converting byte stream interface protocol data to be analyzed into bit stream interface protocol data, acquiring the length Lmax of the bit stream interface protocol data, and defining the bit number n =0 of the analyzed bit stream interface protocol data;

s602: loading all second-level FieldDef nodes under the first-level structDefinitions node in the interface protocol data to form a second-level FieldDef node set;

s603: judging whether the secondary FieldDef node set is empty or not; if not, jumping to S604; if yes, jumping to S615;

s604: sequentially taking out a secondary FieldDef node from the secondary FieldDef node set in sequence and deleting the secondary FieldDef node from the secondary FieldDef node set;

s605: judging whether the secondary FieldDef node comprises a reference field and the field value is true; if not, jumping to S606; if yes, jumping to S608;

s606: acquiring a bits field value L of the secondary FieldDef node;

s607: taking the nth bit to the (n + L) th bit from the bit stream interface protocol data as the value of the secondary FieldDef node, and then analyzing the taken value, wherein the number of the bits of the bit stream interface protocol data after being analyzed is n + L; skipping S614;

s608: finding a secondary structDef node with the same value as the secondary FieldDef node identity field;

s609: judging whether the structtype field value under the secondary structDef node is virtual; if yes, jumping to S610; if not, jumping to S612;

s610: starting a virtual type structDef analysis flow, and transmitting bit stream interface protocol data, bit stream interface protocol data length Lmax and analyzed bit stream interface protocol data bit number n to the sub-flow;

s611: after the parsing of the structDef parsing flow of the virtual type is finished, returning the data bit number n of the parsed bit stream interface protocol; skipping S614;

s612: starting a struct def analysis flow of the struct type, and transmitting bit stream interface protocol data, the length Lmax of the bit stream interface protocol data and the number n of bits of the analyzed bit stream interface protocol data to the sub-flow;

s613: after the struct type structDef analysis flow finishes the analysis, returning the data bit number n of the analyzed bit stream interface protocol; and skipping to S614.

S614: judging whether the bit number n of the analyzed bit stream interface protocol data is equal to the length Lmax of the bit stream interface protocol data; if yes, jumping to S615; if not, jumping to S603;

s615: and finishing the analysis.

It should be noted that the parsing parent flow and the parsing child flow are corresponding, and fig. 6 is taken as an example for description, the entire parsing flow of fig. 6 is a main flow, and the StructDef parsing flow of struct type and the StructDef parsing flow of virtual type are child flows.

Fig. 7 illustrates a flow chart of StructDef parsing of struct type according to an embodiment of the present invention. As shown in fig. 7, a specific flow of the StructDef parsing flow of the struct type is as follows:

s701: the method comprises the following steps that bit stream interface protocol data, bit stream interface protocol data length Lmax and bit number n of the analyzed bit stream interface protocol data are transmitted into a parent process;

s702: loading all three levels of FieldDef nodes under the two levels of structDef nodes to form a first three levels of FieldDef node set;

s703: judging whether the first third-level FieldDef node set is empty or not; if not, jumping to S704; if so, jumping to S708;

s704: sequentially taking out a third-level FieldDef node from the first third-level FieldDef node set in sequence, and deleting the node from the first third-level FieldDef node set;

s705: acquiring a bits field value L of a third-level FieldDef node taken out from the first third-level FieldDef node set;

s706: taking the nth bit to the (n + L) th bit from the bit stream interface protocol data as the value of the third-level FieldDef node taken from the first third-level FieldDef node set, and then analyzing the taken value, wherein the number of the bits of the bit stream interface protocol data after being analyzed is n + L;

s707: judging whether the bit number n of the analyzed bit stream interface protocol data is equal to the length Lmax of the bit stream interface protocol data; if so, jumping to S708; if not, jumping to S703;

s708: returning to the father flow, and returning the data bit number n of the resolved bit stream interface protocol.

Fig. 8 illustrates a flow chart of StructDef parsing of virtual type according to an embodiment of the present invention. As shown in fig. 8, a concrete flow of the virtual type StructDef parsing flow is as follows:

s801: the method comprises the following steps that bit stream interface protocol data, bit stream interface protocol data length Lmax and bit number n of the analyzed bit stream interface protocol data are transmitted into a parent process;

s802: loading all three levels of FieldDef nodes under the two levels of structDef nodes to form a second three levels of FieldDef node set;

s803: judging whether the second third-level FieldDef node set is empty or not; if not, jumping to S804; if yes, jumping to S815;

s804: sequentially taking out a third-level FieldDef node from the second third-level FieldDef node set in sequence, and deleting the node from the second third-level FieldDef node set;

s805: finding a first secondary structDef node with the same value as the identifier field of the third-level FieldDef node extracted from the second third-level FieldDef node set, and defining a copy of the number n of bits of the resolved bit stream interface protocol data, wherein Ntemp = n;

s806: loading all three levels of FieldDef nodes under the first and second levels of structDef nodes to form a third level of FieldDef node set;

s807: judging whether the third-level FieldDef node set is empty or not; if yes, jumping to S803; if not, jumping to S808;

s808: sequentially taking out a third-level FieldDef node from the third-level FieldDef node set in sequence, and deleting the node from the third-level FieldDef node set;

s809: judging whether the third-level FieldDef nodes extracted from the third-level FieldDef node set contain an attribute field and the field value is true; if so, jumping to S811; if not, jumping to S810;

s810: the number of bits Ntemp = Ntemp + L of the parsed bit stream interface protocol; skipping S807; wherein L is a bits field value in a third-level FieldDef node taken out from the third-level FieldDef node set;

s811: acquiring a bits field value L of a third-level FieldDef node taken out from the third-level FieldDef node set, taking Ntemp bit to Ntemp + L bit from bit stream interface protocol data as a value of the third-level FieldDef node taken out from the third-level FieldDef node set, and then analyzing the taken value;

s812: judging whether the value analyzed by the three levels of FieldDef nodes extracted from the third level of FieldDef node set is consistent with the val field value of the first level of second level of structDef nodes; if yes, jumping to S813; if not, jumping to S803;

s813: starting a struct type structDef analysis flow, and transmitting bit stream interface protocol data, bit stream interface protocol data length Lmax and analyzed bit stream interface protocol data bit number n to a sub-flow;

s814: after the struct type structDef analysis flow finishes the analysis, returning the data bit number n of the analyzed bit stream interface protocol;

s815: returning to the father flow, and returning the data bit number n of the resolved bit stream interface protocol.

The parent flow of the virtual type StructDef parsing flow is the whole parsing flow shown in fig. 6, and the child flow of the virtual type StructDef parsing flow is the struct type StructDef parsing flow.

Based on the above method for analyzing interface protocol data, the present invention further provides an interface protocol data analyzing system, which includes:

An acquisition unit, specifically configured to:

Illustratively, the method and the system for analyzing the interface protocol data are explained, the byte stream interface protocol data to be analyzed is 80040000000000000000010000000001 FF 0000001400170000000000000000000100 FF 0000, and the specific analysis process is as follows:

step 1: converting the byte stream interface protocol data to be analyzed into 2-system bit stream interface protocol data, namely 1000000000000100000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000111111111111111110000000000000000000000000001010000000000000101110000000000000000000000000000000000000000000000000000000000000000000000000000000100000000111111110000000000000000, wherein the length of the byte stream interface protocol data to be analyzed is 38 bytes, and the length Lmax of the bit stream interface protocol data after conversion into the 2 system is 304 bits;

step 2: loading all secondary FieldDef nodes under the primary structDefinitions nodes according to the configured primary structDefinitions to form a secondary FieldDef node set, wherein the secondary FieldDef node set comprises two nodes of a fixed frame header TelegramHeader and an information packet list application packet, and if the secondary FieldDef node set is not empty, continuing to analyze;

step 3: taking out a second-level structDef node which is arranged at the top and is named as a TelegramHeader from a second-level FieldDef node set according to the arrangement sequence, wherein the node comprises a reference field and the field value is true, finding a second-level structDef node of which the identity field value is TelegramHeader, starting a structDef parsing process of the struct type and starting a TelegramHeader parsing process (see below);

step 4: after the TelegramHeader node finishes analyzing, the bit number of the analyzed bit stream interface protocol data is 144 bits and is less than 304 bits, and the analysis is continued;

step 5: taking out nodes named as ApplicationPacket nodes from the secondary FieldDef node set according to the arrangement sequence, wherein the nodes comprise reference fields and the field values are true, finding out secondary structDef nodes with identification field values of the ApplicationPacket, starting a structDef analysis process of a virtual type and starting the ApplicationPacket analysis process (see below), wherein the structtype field values of the secondary structDef nodes are virtual;

step 6: after the application packet node finishes analyzing, the bit number of the analyzed bit stream interface protocol data is 304 bits;

step 7: the bit number of the analyzed bit stream interface protocol data is equal to the length of the bit stream interface protocol data, and all analysis is completed.

The TelegramHeader resolution procedure is as follows:

step 1: loading all three-level FieldDef nodes under a second-level structDef node with an identity field value of TelegramHeader to form a first three-level FieldDef node set, wherein 6 subnodes including MessageType, SrcCTCSID, DesCTCSID, Version, PacketNum and GroupPos are included, sequentially analyzing according to the sequence during analysis, and continuing to analyze if the first three-level FieldDef node set is not empty;

step 2: sequentially taking out a node from the first three-level FieldDef node set, wherein the node is named as MessageType, deleting the node from the first three-level FieldDef node set, the length of the node is 16 bits, and the Chinese name is the message type, so that 16 bits are taken out from the offset 0 of the bit stream interface protocol data, assigning the 16 bits to the field of the message type, namely 1000000000000100, and after analysis, the hexadecimal system is 0x8004, wherein the number n of the analyzed bit stream interface protocol data bits is 16 bits and is less than the length Lmax of the bit stream interface protocol data, and continuing to analyze;

step 3: sequentially taking out a node from the first three-level FieldDef node set, wherein the node is named as SrcCTCSID, deleting the node from the first three-level FieldDef node set, the length of the node is 32 bits, and the Chinese name is a sender mark, so that from the offset 16 of the bit stream interface protocol data, taking out 32 bits, assigning a field of the sender mark, namely 00000000000000000000000000000000, after analysis, the hexadecimal system is 0x00000000, at the moment, the number n of the analyzed bits of the bit stream interface protocol data is 48 bits and is less than the length Lmax of the bit stream interface protocol data, and continuing to analyze;

step 4: sequentially taking out a node from the first three-level FieldDef node set, wherein the name is DesCTCSID, and deleting the node from the first three-level FieldDef node set, the length of the node is 32 bits, and the name of the Chinese is receiver mark, so that from bit stream interface protocol data offset 48, taking out 32 bits, assigning a field of the receiver mark, namely 00000000000000000000000000000000, the hexadecimal system is 0x00000000, at the moment, the number n of the analyzed bit stream interface protocol data bits is 80 bits and is less than the length Lmax of the bit stream interface protocol data, and continuing to analyze;

step 5: sequentially taking out a node from the first three-level FieldDef node set, wherein the node is named Version, and deleting the node from the first three-level FieldDef node set, the length of the node is 32 bits, and the Chinese name is protocol Version, so that 32 bits are taken out from the offset 80 of the bit stream interface protocol data, the 32 bits are assigned to the field of the protocol Version, namely 00000001000000000000000000000000, the hexadecimal system is 0x01000000 after analysis, at the moment, the number n of the analyzed bit stream interface protocol data bits is 112 bits and is less than the length Lmax of the bit stream interface protocol data, and the analysis is continued;

step 6: sequentially taking out a node from the first three-level FieldDef node set, wherein the node is named as PacketNum, deleting the node from the first three-level FieldDef node set, the length of the node is 16 bits, and the Chinese name is the number of application information packets, so that starting from bit stream interface protocol data offset 112, taking out 16 bits, assigning the 16 bits to the field of the number of application information packets, namely 000000000001, and after analysis, the hexadecimal is 0x0001, wherein the number n of the analyzed bits of the bit stream interface protocol data is 128 bits and is less than the length Lmax of the bit stream interface protocol data, and continuing to analyze;

step 7: taking out a node in the first three-level FieldDef node set according to the sequence, wherein the node is named as GroupPos, and deleting the node from the first three-level FieldDef node set, the node length is 16 bits, and the Chinese name is the position in the group, so that 16 bits are taken out from the bit stream interface protocol data offset 128, the 16 bits are assigned to the field of the position in the group, namely 1111111111111111, the hexadecimal system is 0xFFFF after the analysis, the field is an enumeration value type, the field can be translated into a message only contained in the group according to the value of 0xFFFF, namely 65535, the number n of the analyzed bit stream interface protocol data bits is 144 bits and is less than the length Lmax of the bit stream interface protocol data, and the analysis is continued;

step 8: the first three-level FieldDef node set is empty, and the number n of the data bits of the resolved bit stream interface protocol is returned to the father process and is 144 bits.

The ApplicationPacket parsing process is as follows:

step 1: loading all three-level FieldDef nodes under a second-level structDef node with an identity field value of an application packet to form a second-level FieldDef node set, wherein the second-level FieldDef node set comprises 3 sub-nodes including Status, Error and Info, and if the second-level FieldDef node set is not empty, continuing to analyze;

step 2: sequentially taking out a node from the second third-level FieldDef node set, wherein the node is named as Status, deleting the node from the second third-level FieldDef node set, loading all FieldDef nodes under a second-level structDef node with the identity of Status to form a third-level FieldDef node set, wherein the third-level FieldDef node set comprises 19 child nodes including Reserve, m _ messageLength, InformationType, rbc, tsr, estatus, v, reason, dpatch, ctc, user, stn, line, stLong, endLong, stCoord, endCoord, stPoint and endPoint, and if the third-level FieldDef node set is not empty, continuing to analyze;

step 3: sequentially taking out a node from the third-level FieldDef node set, wherein the node is named Reserve, deleting the node from the third-level FieldDef node set, the length of the node is 16 bits, the node does not contain an istype field, and the record of Ntemp =144+16= 160;

step 4: sequentially taking out a node from the third-level FieldDef node set, wherein the node is named as messageLength, deleting the node from the third-level FieldDef node set, the length of the node is 16 bits, the node does not contain an istype field, and the record of Ntemp =160+16= 176;

step 5: sequentially taking out a node from the third-level FieldDef node set, wherein the node is named as InformationType and deleted from the third-level FieldDef node set, the length of the node is 16 bits, the node comprises an istype field, the field value is true, and the node is taken out by 16 bits, namely 0000000000010111, starting from bit stream interface protocol data offset 176, the hexadecimal system is 0x17, the val field value of a second-level structDef node named as Status is 0x03 and is inconsistent with 0x 17;

step 6: sequentially taking out a node from the second-level FieldDef node set, wherein the node is named as Error, deleting the node from the second-level FieldDef node set, loading all FieldDef nodes under a second-level structDef node with identity as Error to form a fourth-level FieldDef node set, and containing 13 sub-nodes including Reserve, m _ messageLength, informationType, rbc, tsr, extatus, v, reason, dpatch, ctc, user, Error and erparam, and continuing to analyze if the fourth-level FieldDef node set is not empty;

step 7: sequentially taking out a node from the fourth-level FieldDef node set, wherein the node is named Reserve, deleting the node from the fourth-level FieldDef node set, the length of the node is 16 bits, the node does not contain an istype field, and recording Ntemp =144+16= 160;

step 8: sequentially taking out a node from the fourth third-level FieldDef node set, wherein the node is named as messageLength, deleting the node from the fourth third-level FieldDef node set, the length of the node is 16 bits, the node does not contain an istype field, and the record of Ntemp =160+16= 176;

step 9: sequentially taking out a node from the fourth-level FieldDef node set, wherein the node is named as InformationType and deleted from the fourth-level FieldDef node set, the length of the node is 16 bits, the node comprises an istype field, the field value is true, and the 16 bits, namely 0000000000010111, are taken out from the original data offset 176, the hexadecimal system is 0x17, the val field value of the secondary structDef node is 0x05, and the value field value is inconsistent with 0x 17;

step 10: sequentially taking out a node with the name of Info from the second-level FieldDef node set, deleting the node from the second-level FieldDef node set, loading all FieldDef nodes under a secondary structDef node with the identity of Info, forming a fifth-level FieldDef node set, wherein the fifth-level FieldDef node set comprises 8 child nodes including Reserve, m _ messageLength, InformationType, rbc, tsrsid, stScope, endScope and numExecuted, and continuing to analyze if the fifth-level FieldDef node set is not empty;

step 11: sequentially taking out a node from the fifth-level FieldDef node set, wherein the node is named Reserve, deleting the node from the fifth-level FieldDef node set, the length of the node is 16 bits, the node does not contain an istype field, and the record of Ntemp =144+16= 160;

step 12: sequentially taking out a node from the fifth third-level FieldDef node set, wherein the node is named as messageLength, deleting the node from the fifth third-level FieldDef node set, the length of the node is 16 bits, the node does not contain an istype field, and the record of Ntemp =160+16= 176;

step 13: sequentially taking out a node from the fifth-level FieldDef node set, wherein the node is named as InformationType and deleted from the fifth-level FieldDef node set, the length of the node is 16 bits, the node comprises an istype field, the field value is true, and the 16 bits, namely 0000000000010111, are taken out from the original data offset 176, the hexadecimal system is 0x17, and the val field value of the secondary structDef node is 0x17 and is consistent with 0x 17;

step 14: starting an Info parsing process (see below);

step 15: after the Info is analyzed, the bit number n of the analyzed bit stream interface protocol data is 304 bits and is equal to the length Lmax of the bit stream interface protocol data;

step 16: returning the data bit number n of the resolved bit stream interface protocol to the parent flow as 304 bits.

The Info resolution process is as follows:

step 1: loading a fifth-level FieldDef node set under a structDef node with an identity field value of Info, wherein the fifth-level FieldDef node set comprises 8 sub-nodes including Reserve, m _ messageLength, InformationType, rbc, tsrsid, stScope, endScope and numExecuted, and if the fifth-level FieldDef node set is not empty, continuing to analyze;

step 2: sequentially taking out a node from the fifth third-level FieldDef node set, wherein the node is named Reserve, and deleting the node from the fifth third-level FieldDef node set, the length of the node is 16 bits, and the Chinese name is reserved, so that 16 bits are taken out from the original data offset 144 and assigned to the reserved field, namely 000000000000, the hexadecimal system is 0x0000, and the number n of the data bits of the resolved bit stream interface protocol is 160 bits;

step 3: sequentially taking out a node from the fifth third-level field def node set, wherein the node is named as m _ messageLength, and deleting the node from the fifth third-level field def node set, the node length is 16 bits, and the Chinese name is the packet length, so that 16 bits are taken out from the original data offset 160 and assigned to the field of the packet length, namely 0000000000010100, the hexadecimal system is 0x0014, and the number n of the data bits of the resolved bit stream interface protocol is 176 bits;

step 4: sequentially taking out a node from the fifth-level FieldDef node set, wherein the name of the node is InformationType, and deleting the node from the fifth-level FieldDef node set, the length of the node is 16 bits, and the name of a Chinese character is an information type, so that 16 bits are taken out from the original data offset 176 and assigned to a field of the information type, namely 0000000000010111, the hexadecimal system is 0x0017, and the number n of the data bits of the resolved bit stream interface protocol is 192 bits;

step 5: sequentially taking out a node from the fifth-level FieldDef node set, wherein the node is named rbc, and deleting the node from the fifth-level FieldDef node set, the length of the node is 32 bits, the Chinese name is equipment identification, therefore, 32 bits are taken out from original data offset 192, and are assigned to the field of the equipment identification, namely 00000000000000000000000000000000, the hexadecimal system is 0x00000000, and the number n of the data bits of the resolved bit stream interface protocol is 224 bits;

step 6: sequentially taking out a node from the fifth-level FieldDef node set, wherein the node is named tsrsid and deleted from the fifth-level FieldDef node set, the length of the node is 32 bits, the Chinese name is a line speed limit state initial confirmation mark, therefore, 32 bits are taken out from an original data offset 224 and assigned to a field of the line speed limit state initial confirmation mark, namely 00000000000000000000000000000000, the hexadecimal system is 0x00000000, and the number of bits n of the analyzed bit stream interface protocol data is 256 bits;

step 7: sequentially taking out a node from the fifth-level FieldDef node set, wherein the node is named stScope, and deleting the node from the fifth-level FieldDef node set, the length of the node is 16 bits, the Chinese name is the starting point of the TSR available mark range, therefore, starting from the original data offset of 256 bits, taking out 16 bits, assigning the 16 bits to the field of the starting point of the TSR available mark range, namely 00000001, and the hexadecimal system is 0x0001, and at this moment, the number n of the data bits of the resolved bit stream interface protocol is 272 bits;

step 8: sequentially taking out a node from the fifth-level FieldDef node set, wherein the node is named endScope, and deleting the node from the fifth-level FieldDef node set, the length of the node is 16 bits, the Chinese name is TSR available mark range end, therefore, from the original data offset 272, 16 bits are taken out and assigned to the field of the TSR available mark range end, namely 0000000011111111, the hexadecimal system is 0x00FF, and the number n of the data bits of the resolved bit stream interface protocol is 288 bits;

step 9: sequentially taking out a node from the fifth three-level FieldDef node set, wherein the node is named numExecuted, and deleting the node from the fifth three-level FieldDef node set, the length of the node is 16 bits, the Chinese name is the executed speed limit number, therefore, starting from the original data offset 288, taking out 16 bits, assigning to the field of the executed speed limit number, namely 000000000000, the hexadecimal system is 0x0000, and the number of bits n of the resolved bit stream interface protocol data is 304 bits

step 10: the bit number n of the analyzed bit stream interface protocol data is equal to the length Lmax of the bit stream interface protocol data, and the bit number n of the analyzed bit stream interface protocol data is returned to the parent process and is 304.

According to the analysis process, the original byte stream interface protocol data is analyzed, and the analyzed content is shown in table 5.

Although the hexadecimal interface protocol data is exemplified above, the present invention is not limited thereto and can resolve interface protocol data in various forms, such as binary, octal, decimal, hexadecimal, etc. One skilled in the art can synthesize the present invention according to the analytic principles and practical application, so long as the principles of the present invention can be implemented.

The interface protocol data analysis method and system provided by the invention can analyze interface protocol data in various forms by taking bit as the minimum analysis unit, can support dynamic analysis based on information type numbers, has better applicability, effectively reduces development workload, avoids repeated code development for each interface protocol, and improves the overall efficiency of train control system testing.

The invention also provides a description method of the simulator and the external program interface, which comprises the following steps:

the description is made according to the structures of opening the network connection OpenLink, closing the network connection CloseLink, setting the network connection parameter configuration, adding a data packet AddPacket, deleting a data packet DeletePacket, setting a variable value SetVariable in the data packet and feeding state information PacketInfo.

And (3) starting network connection OpenLink: and starting the network connection of the simulator and the tested device. Table 6 shows specific attributes of opening a network connection. Illustratively, OpenLink 1A-1A.

Close network connection CloseLink: and closing the network connection of the simulator and the tested device. Table 7 shows specific attributes of closing the network connection. Exemplary, CloseLink 1A-1A.

Setting a network connection parameter Configure: setting a network connection communication period, a pause period number and whether to send a heartbeat. Table 8 shows specific attributes for setting the network connection parameters. Illustratively, the communication period is set to 500ms, Configure 1A-1A SendPeriod 500.

Adding a data packet AddPacket: and adding a test data packet into the message. Once indicates that the test data packet is added to the communication message, and Always indicates that the test data packet is permanently added to the communication message. Table 9 shows the specific attributes of the add packet. Illustratively, sending SAM packets: AddPacket (always) 1A-1A SAM { "ObjectId": 103, "saiD": 2, "routeType": 0, "routesstatus": 2, "gradedStatus": 0, "dangerPoint": 0, "rolIn": 0} }.

Deleting the data packet DeletePacket: all test packets are deleted. The VariableName and the VariableValue are selectable items and represent variable names and corresponding numerical values in the application information packets, and if the VariableName and the VariableValue exist, the corresponding variable names and the corresponding numerical values in each information packet need to be checked when the test data packets are deleted. Note: when the packet name is x, the VariableName and variablenvalue are not filled in. Table 10 shows the specific attributes of the deleted packet. Illustratively, all packets, DeletePacket 1A-1A, are deleted.

Setting the value of variable SetVariable in the data packet: the value or length of the fields in the message is set. SetVariable is a command symbol, PacketName is the test packet name, PacketName is a prime, meaning that all fields within the protocol named VariableName are modified. The VariableName is the variable name of the field in the data packet, and when the VariableName is the prime, all fields in the PacketName data packet are changed. Value is the Value of the change field. Table 11 shows specific attributes for setting variable values within a data packet. Illustratively, the Value of the object ID within the modified SAM package is 7, SetVariable 1A-1A SAM object ID Value 7.

Feedback state information PacketInfo: and feeding back the message sent by the tested device to the simulation model. The packetName represents the test data packet name, and JsonString represents a Json character string consisting of fields and corresponding numerical values in the packet. Table 12 shows specific attributes of the feedback status information. Illustratively, PacketInfo LinkName TIM { "objectId": 103, "length": 5, "" train status ": 0," "maStatus": 2, "" train position ": 1000," "train Length": 100, "train speed": 20 }.

The present embodiment is exemplified by XML language, json or other custom description language convenient for computer processing may also be adopted, and the keyword recommendation in the embodiment is not limited to use the specification in the present invention.

Although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims

1. An interface protocol data analysis method is characterized by comprising the following steps:

judging whether the secondary FieldDef node set is empty or not;

2. The method according to claim 1, wherein the following steps are performed before all second-level fieldef nodes below the first-level StructDefinitions node in the interface protocol data are loaded into the second-level fieldef node set:

3. The method according to claim 1, wherein said determining whether said secondary FieldDef node contains a reference field and the field value is true further comprises:

if not, acquiring a bits field value L of the secondary FieldDef node;

taking the nth bit to the (n + L) th bit from the bit stream interface protocol data as the value of the secondary FieldDef node, and then analyzing the taken value; wherein n is the data bit number of the analyzed bit stream interface protocol; when the resolution is started, n is 0;

4. The interface protocol data parsing method according to claim 1, wherein the struct def parsing flow of struct type includes the following steps:

judging whether the first third-level FieldDef node set is empty or not;

acquiring a bits field value L of a third-level FieldDef node taken out from the first third-level FieldDef node set, taking an nth bit to an nth + L bit from bit stream interface protocol data as a value of the third-level FieldDef node taken out from the first third-level FieldDef node set, and then analyzing the taken value; wherein n is the data bit number of the analyzed bit stream interface protocol; when the resolution is started, n is 0;

5. The interface protocol data parsing method of claim 1, wherein the virtual type StructDef parsing flow comprises the following steps:

judging whether the second third-level FieldDef node set is empty or not;

judging whether the third-level FieldDef node set is empty or not;

if so, acquiring a bits field value L of the third-level FieldDef node taken out from the third-level FieldDef node set, taking Ntemp bit to Ntemp + L bit from bit stream interface protocol data as a value of the third-level FieldDef node taken out from the third-level FieldDef node set, and then analyzing the taken value; wherein Ntemp is the copy of the data bit number n of the analyzed bit stream interface protocol, and Ntemp = n;

if so, starting a structDef analysis process of the struct type.

6. The method according to claim 1, wherein the interface protocol data includes a fixed frame header and a packet list.

7. The method of claim 6, wherein the fixed frame header comprises a packet and a field.

8. The method of claim 6, wherein the packet list comprises packets and fields.

9. The method according to claim 7 or 8, wherein the packet comprises a field.