Multi-node data communication method for simulating TTE protocol

Abstract

The invention provides a multi-node data communication method for simulating a TTE protocol. The method comprises the following steps: TTE equipment refers to equipment adopting a TTE interface; according to the method, an Ethernet card is simulated through software, and data sending and data receiving of a plurality of service nodes to TTE equipment can be achieved; when a service node communicates with TTE equipment, transmission paths for receiving and transmitting data are represented by VLIDs, and if the transmission paths are different, the VLIDs are different. According to the method, the Ethernet card is installed to simulate the TTE protocol through software, and the universal equipment is used for simulating and replacing the special TTE equipment, so that data transmission and data receiving between a plurality of service nodes and the TTE equipment are realized, and the method is verified to be feasible.

Description

Technical Field

[0001] This invention relates to the technical field of electrical performance testing, and specifically to a multi-node data communication method simulating the TTE protocol. Background Technology

[0002] Time-Trigger Ethernet (TTE) replaces event-triggered communication with time-triggered transmission, scheduling communication tasks to be sent at appropriate times. As a new high-speed, high-performance integrated electronic bus technology, TTE overcomes the shortcomings of the 1553B bus in terms of data transmission rate, time determinism, resource utilization, and fault tolerance, and its applications are increasing.

[0003] For TTE development systems, a typical configuration includes TTE network switches, TTE controller terminals, TTE user terminals, and physical links. Compared to traditional switches, TTE network switches offer clock synchronization capabilities and act as the decision-maker for clock synchronization. However, TTE network switches are expensive and require advance booking with long lead times. TTE user terminals require TTE carrier boards, each of which can only simulate one service node. For systems with multiple service nodes, the cost of purchasing TTE carrier boards is significant, and similarly, advance booking with long lead times is necessary. A certain test system involves communication between multiple (N≥2) service nodes and TTE equipment. Analysis shows that this service is not time-sensitive. Summary of the Invention

[0004] This invention provides a multi-node data communication method that simulates the TTE protocol. Its purpose is to solve the problem of data communication between multiple (N≥2) service nodes and TTE devices, including the sending and receiving of data from multiple (N≥2) service nodes to the TTE device. This invention installs an Ethernet card to simulate the TTE protocol through software, uses a general-purpose device to simulate and replace the dedicated TTE device, and realizes data sending and receiving between multiple (N≥2) service nodes and the TTE device. The feasibility of the method has been verified.

[0005] This invention is achieved by the following technical solution:

[0006] This invention provides a multi-node data communication method that simulates the TTE protocol. The TTE device refers to a device that uses a TTE interface. The method uses an Ethernet card to simulate the TTE device through software, enabling multiple service nodes to send and receive data to and from the TTE device. When the service nodes communicate with the TTE device, the transmission path for sending and receiving data is represented by VLID, and different transmission paths result in different VLIDs.

[0007] Optionally, in the above method, for the data sent to the TTE device, an Ethernet card can be used to simulate multiple service nodes sending data to the TTE device through software; wherein, the data sent to the TTE device by one service node is remote control data, and the data sent to the TTE device by other service nodes is telemetry data.

[0008] Optionally, in the above method, for receiving data sent by the TTE device, an Ethernet card can be used to simulate multiple service nodes receiving data from the TTE device through software. The data sent by the TTE device to one service node is telemetry data, and the data sent by the TTE device to other service nodes is remote control data.

[0009] Optionally, in the above method, for data sent to the TTE device, a database is used in conjunction with LabVIEW to complete the serialization process, and the encapsulated interface function is called to send the data to the TTE device; the steps are as follows:

[0010] The database records the communication protocol information related to each business node. If a business node sends instructions to the TTE device and receives telemetry data sent by the TTE device, then the database needs to record information such as instruction code, instruction name, and instruction code, as well as information such as parameter code, parameter name, parameter length in bytes, and parameter offset for each parameter in the telemetry data packet.

[0011] For telemetry data, the analog signal board collects voltage values ​​from different hardwired channels. The LabVIEW software sends the collected values ​​to the host computer software. The host computer software assembles the collected values ​​into data packets for multiple service nodes according to the communication protocol entered in the database and sends them to the LabVIEW software. The LabVIEW software adds MAC addresses and VLIDs to assemble the data packets of each service node into TTE packets and calls the encapsulated interface functions to send the TTE packets of multiple nodes to the TTE device.

[0012] For remote control data, after the command is sent from the display terminal, the host computer software sends the command code to the LabVIEW software according to the communication protocol entered in the database. The LabVIEW software adds MAC address and VLID to form a TTE packet, and calls the encapsulated interface function to send the TTE packet to the TTE device.

[0013] Optionally, in the above method, for data sent by the TTE device, the encapsulated interface function is called to receive the data and filter out irrelevant TTE packets. The database is used in conjunction with LabVIEW to complete the deserialization process. The steps are as follows:

[0014] The TTE device sends data in the form of TTE packets. The encapsulated interface function receives the data and filters out irrelevant TTE packets. The LabVIEW software reads the TTE packets, removes the packet header, and sends the header-less data packet to the host computer software based on information such as the MAC address and VLID. At this point, it is equivalent to sending data packets from multiple service nodes to the host computer software. The host computer software reads the data packets, determines the data packet type, and identifies the data packet content. If it is remote control data, it finds the bound hardwire channel according to the database configuration information and feeds back to the LabVIEW software to execute the corresponding action of the hardwire channel. If it is telemetry data, it parses the telemetry data according to the database configuration information and transmits it to the display terminal for display.

[0015] Optionally, in the above method, the verification of successful data transmission and reception can be performed throughout the entire link. For remote control data, the display terminal sends a command to the TTE device and receives the TTE device feedback code. By searching the database for the hard-wired channel bound to the feedback code and executing the corresponding action, the success of reception can be determined based on the changes in the hard-wired channel. For telemetry data, typical parameters can be selected, and a standard signal source can be used to output voltage values ​​in the typical parameter hard-wired channel. The success of telemetry data transmission can be determined based on whether the changes in the standard signal source and the changes in the voltage value of the display terminal are consistent.

[0016] The present invention can achieve at least the following beneficial effects:

[0017] First, this invention uses general-purpose equipment instead of dedicated equipment. TTE communication relies on TTE switches and TTE carrier boards, while this invention uses general-purpose Ethernet cards and software simulation to enable data transmission and reception between TTE devices and multiple service nodes without relying on dedicated equipment;

[0018] Secondly, this invention enhances system flexibility and scalability through a multi-service node integrated design. When the service scale expands, only the service node configuration needs to be added, without reconstructing the underlying hardware architecture, thus shortening the system expansion cycle and adapting to rapidly changing multi-node communication needs. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 A schematic diagram of data transmission and reception according to an embodiment of the present invention is shown;

[0021] Figure 2 A schematic diagram of data transmitted from a service node to a TTE device according to an embodiment of this application is shown;

[0022] Figure 3 A schematic diagram illustrating a service node receiving data from a TTE device according to an embodiment of the present invention is shown.

[0023] Figure 4 This illustration shows a schematic diagram of the process by which a service node sends data to a TTE device according to one embodiment of this application;

[0024] Figure 5 This invention illustrates a flowchart of a service node receiving data sent by a TTE device according to some embodiments of this application.

[0025] Figure 6 A schematic diagram of data transmission and reception according to Embodiment 3 of the present invention is shown;

[0026] Figure 7 A voltage variation graph of a 28V voltage captured by an oscilloscope according to Embodiment 3 of this application is shown; Figure 8 A schematic diagram of data transmission and reception according to Embodiment 4 of the present invention is shown;

[0027] Figure 9 A voltage variation graph of the 28V voltage captured by an oscilloscope in channel 2 according to Embodiment 4 of the present invention is shown.

[0028] Figure 10 A voltage variation graph of the 28V voltage captured by an oscilloscope in channel 3 according to embodiment 4 of the present invention is shown. Detailed Implementation

[0029] This invention uses a single Ethernet card to simulate the TTE protocol in software, enabling data communication between multiple (N≥2) service nodes and a TTE device. Specifically, for data sent to the TTE device, a single Ethernet card can simulate the TTE protocol to allow multiple (N≥2) service nodes to transmit data to the TTE device; similarly, for data received from the TTE device, a single Ethernet card can simulate the TTE protocol to allow multiple (N≥2) service nodes to receive data from the TTE device. This forms a closed loop for data transmission and reception, within which the correctness of data transmission and reception is verified.

[0030] To better understand the present invention, the following examples will further illustrate the content of the present invention.

[0031] Example 1

[0032] This invention provides a multi-node data communication method simulating the TTE protocol. The TTE device mentioned in this invention refers to a device using a TTE interface. The method uses an Ethernet card to simulate data transmission and reception between multiple (N≥2) service nodes and the TTE device via software. When service nodes communicate with the TTE device, the transmission path for sending and receiving data is represented by a VLID; different transmission paths result in different VLIDs. A schematic diagram is shown below. Figure 1 As shown.

[0033] In some embodiments of this application, for data sent to the TTE device, a single Ethernet card can be used to simulate multiple (N≥2) service nodes transmitting data to the TTE device via software. The data sent to the TTE device by service node 1 is remote control data, while the data sent to the TTE device by other service nodes is telemetry data, as illustrated in the diagram. Figure 2 As shown.

[0034] In some embodiments of this application, for receiving data sent by the TTE device, a single Ethernet card can be used to simulate multiple (N≥2) service nodes receiving data from the TTE device via software. The data sent by the TTE device to service node 1 is telemetry data, and the data sent by the TTE device to other service nodes is remote control data. A schematic diagram is shown below. Figure 3 As shown.

[0035] In some embodiments of this application, for data sent to the TTE device, a database is used in conjunction with LabVIEW to complete the serialization process, and the encapsulated interface function is called to send the data to the TTE device. The steps are as follows:

[0036] The database records the communication protocol information related to each business node. For example, business node 1 sends instructions to the TTE device and receives telemetry data sent by the TTE device. Therefore, the database needs to record information such as instruction code, instruction name, and instruction code, as well as information such as parameter code, parameter name, parameter length in bytes, and parameter offset for each parameter in the telemetry data packet.

[0037] For telemetry data, the analog signal board collects voltage values ​​from different hardwired channels. The LabVIEW software sends the collected values ​​to the host computer software. The host computer software assembles the collected values ​​into data packets for multiple service nodes according to the communication protocol entered in the database and sends them to the LabVIEW software. The LabVIEW software adds MAC addresses and VLIDs to assemble the data packets of each service node into TTE packets and calls the encapsulated interface functions to send the TTE packets of multiple nodes to the TTE device.

[0038] For remote control data, after the command is sent from the display terminal, the host computer software sends the command code to the LabVIEW software according to the communication protocol entered in the database. The LabVIEW software adds the MAC address and VLID to form a TTE packet, and calls the encapsulated interface function to send the TTE packet to the TTE device. A schematic diagram is shown below. Figure 4 As shown.

[0039] In some embodiments of this application, for data sent by a TTE device, an encapsulated interface function is called to receive the data and filter out irrelevant TTE packets. The deserialization process is completed using a database in conjunction with LabVIEW. The steps are as follows:

[0040] The TTE device sends data in TTE packets. The encapsulated interface function receives the data and filters out irrelevant TTE packets. The LabVIEW software reads the TTE packets, removes the header, and sends the header-less data packet to the host computer software based on information such as the MAC address and VLID. This is equivalent to sending data packets from multiple service nodes to the host computer software. The host computer software reads the data packets, determines the data packet type, and identifies the data packet content. If it is remote control data, it finds the bound hardwire channel according to the database configuration information and sends feedback to the LabVIEW software to execute the corresponding action for that hardwire channel. If it is telemetry data, it parses the telemetry data according to the database configuration information and transmits it to the display terminal for display. (See diagram below.) Figure 5 As shown.

[0041] In some embodiments of this application, the success of data transmission and reception can be verified throughout the entire link. For remote control data, a command is sent from the display terminal to the TTE device and a feedback code is received from the TTE device. By searching the database for the hard-wired channel bound to the feedback code and executing the corresponding action, the success of reception can be determined based on the changes in the hard-wired channel. For telemetry data, a typical parameter can be selected, and a standard signal source can be used to output voltage values ​​in the typical parameter hard-wired channel. The success of telemetry data transmission can be determined based on whether the changes in the standard signal source and the changes in the voltage value of the display terminal are consistent.

[0042] Example 2

[0043] In a certain test system, there are five service nodes communicating with the TTE device: Service Node 1, Service Node 2, Service Node 3, Service Node 4, and Service Node 5. The transmission paths between these five service nodes and the TTE device, along with their corresponding VLIDs, are detailed in Tables 1 and 2. Two examples are selected: one example involves two service nodes communicating with the TTE device, and the other involves all five service nodes communicating with the TTE device. The communication process between other service nodes and the TTE device is similar and will not be illustrated individually.

[0044] Table 1. Statistics of Remote Control Data Transmission Paths

[0045]

[0046] Table 2. Statistics of Transmission Paths Related to Telemetry Parameters

[0047]

[0048] Example 3

[0049] Based on Example 2, this example is designed. In Example 3, only Service Node 1 and Service Node 2 communicate with the TTE device, as shown in the schematic diagram. Figure 6 As shown, the data sent to the TTE device takes a remote control data (remote control data 1) and a telemetry parameter value (parameter 1) as an example. The remote control data is sent to the TTE device through service node 1. The TTE device receives and processes the data and provides feedback (feedback code 1). The specific content of the feedback determines which service node will perform the action. In this embodiment, service node 2 performs the corresponding action. Parameter 1 is collected by service node 2 and sent to the TTE device after the voltage value is collected. The TTE device packets the data and sends it to service node 1, which then transmits it to the display terminal for parsing and display.

[0050] To more clearly illustrate the data transmission and reception process, the communication processes for remote control data and telemetry data will be explained separately.

[0051] The main processes for sending and receiving remote control data in this embodiment are as follows:

[0052] Step 1: After sending the command (remote control data 1) from the display terminal, the host computer software sends the command code to the LabVIEW software according to the communication protocol entered in the database;

[0053] Step 2: Add MAC address and VLID, etc., to the LabVIEW software to form a TTE packet;

[0054] Step 3: Call the encapsulated interface function to send the TTE packet to the TTE device;

[0055] Step 4: The TTE device receives and parses the data, and sends a feedback code in the form of a TTE packet;

[0056] Step 5: The encapsulated interface function receives data and filters out irrelevant TTE packets;

[0057] Step 6: The LabVIEW software reads the TTE packet, removes the TTE packet header, and sends the data packet with the TTE header removed to the host computer software based on information such as MAC address and VLID.

[0058] Step 7: The host computer software reads the data packet, determines that the data packet type is remote control data, and identifies that the data packet content is to turn on the 28V power supply relay of channel 1, and feeds back to the LabVIEW software;

[0059] Step 8: The LabVIEW software control board turns on the 28V power supply relay for channel 1;

[0060] Step 9: Use an oscilloscope to capture voltage changes in the hard-wired channel to determine if reception was successful. Figure 7 As shown, the oscilloscope can capture the 28V voltage of channel 1, proving that the data sent by service node 1 to the TTE device and the data received by service node 2 from the TTE device are both correct.

[0061] The main processes for sending and receiving telemetry data in this embodiment are as follows:

[0062] Step 1: Use a standard signal generator to output the voltage value in the hard-wired channel of the telemetry parameter value (parameter 1);

[0063] Step 2: The analog signal board acquires voltage values ​​from the hard-wired channels, and the LabVIEW software sends the acquired values ​​to the host computer software.

[0064] Step 3: The host computer software assembles the collected values ​​into data packets for the corresponding business nodes according to the communication protocol entered in the database and sends them to the LabVIEW software;

[0065] Step 4: Use LabVIEW software to add MAC address, VLID, etc. to assemble the data packets into a TTE packet;

[0066] Step 5: Call the encapsulated interface function to send the TTE packet to the TTE device;

[0067] Step 6: The TTE device sends data in the form of TTE packets, and the encapsulated interface function receives the data and filters out irrelevant TTE packets;

[0068] Step 7: The LabVIEW software reads the TTE packet, removes the TTE packet header, and sends the data packet with the TTE header removed to the host computer software based on information such as MAC address and VLID.

[0069] Step 8: The host computer software reads the data packet, determines that the data packet type is telemetry data, identifies the content of the data packet and parses the telemetry data, and transmits it to the display terminal for display;

[0070] Step Nine: Adjust the voltage value output by the standard signal source in the hard-wired channel of parameter 1. Determine whether the telemetry data transmission was successful by comparing the changes in the standard signal source voltage with the changes in the display terminal voltage. Connect the standard signal source to the parameter 1 acquisition channel and output three different voltage values: 1V, 1.5V, and 3V. Monitor the changes in the display terminal voltage as the standard signal source output voltage changes. This verifies that the data sent by service node 2 to the TTE device and the data received by service node 1 from the TTE device are both correct.

[0071] Example 4:

[0072] Based on Example 2, this example is designed. In this example, five service nodes—service node 1, service node 2, service node 3, service node 4, and service node 5—communicate with the TTE device. A schematic diagram of data transmission and reception in this example is shown below. Figure 8 As shown in Table 3, four remote control data points are selected to be sent to the TTE device. These data are used to verify whether the remote control data sent to and received from the TTE device is correct.

[0073] Table 3 Remote Control Data for Example 2

[0074]

[0075]

[0076] In this embodiment, four remote control data are sent by service node 1, as detailed in Table 3 (numbers 1-4). The remote control data are combined into TTE packets and sent to the TTE device. The TTE device receives, processes, and sends feedback codes. Based on the feedback codes, it is determined that each of the four service nodes will execute the data.

[0077] The main process is as follows:

[0078] Step 1: After sending the command (remote control data 2) from the display terminal, the host computer software sends the command code to the LabVIEW software according to the communication protocol entered in the database;

[0079] Step 2: Add MAC address and VLID, etc., to the LabVIEW software to form a TTE packet;

[0080] Step 3: Call the encapsulated interface function to send the TTE packet to the TTE device;

[0081] Step 4: The TTE device receives and parses the data, and sends a feedback code in the form of a TTE packet;

[0082] Step 5: The encapsulated interface function receives data and filters out irrelevant TTE packets;

[0083] Step 6: The LabVIEW software reads the TTE packet, removes the TTE packet header, and sends the data packet with the TTE header removed to the host computer software based on information such as MAC address and VLID.

[0084] Step 7: The host computer software reads the data packet, determines that the data packet type is remote control data, and identifies that the data packet content is to turn on the 28V power supply relay of channel 2, and feeds back to the LabVIEW software;

[0085] Step 8: The LabVIEW software control board turns on the 28V power supply relay for channel 2;

[0086] Step 9: Use an oscilloscope to capture voltage changes in the hard-wired channel to determine if reception was successful. Figure 9 As shown, the oscilloscope can capture the 28V voltage of channel 2, proving that the data sent by service node 1 to the TTE device and the data received by service node 2 from the TTE device are both correct.

[0087] The processing of remote control data 3, remote control data 4, and remote control data 5 is the same as above, and will not be repeated here. Only the sending and verification of instructions will be briefly described.

[0088] Step 10: Send a command (remote control data 3) from the display terminal;

[0089] Step 11: Use an oscilloscope to capture voltage changes in the hard-wired channel to determine if reception was successful. Figure 10 As shown, the oscilloscope can capture the 28V voltage of channel 3, proving that the data sent by service node 1 to the TTE device and the data received by service node 3 from the TTE device are both correct.

[0090] Step 12: Send a command (remote control data 4) from the display terminal;

[0091] Step 13: Use a multimeter to read the voltage change in the hard-wired channel to determine if the reception was successful. If a voltage of 100V can be read in channel 4, it proves that the data sent by service node 1 to the TTE device and the data received by service node 4 from the TTE device are both correct.

[0092] Step Fourteen: Send a command (remote control data 5) from the display terminal;

[0093] Step 15: Use a multimeter to read the voltage change in the hard-wired channel to determine if the reception was successful. If a voltage of 100V can be read in channel 5, it proves that the data sent by service node 1 to the TTE device and the data received by service node 5 from the TTE device are both correct.

[0094] Four parameter values ​​are selected for the data sent to the TTE device, as shown in Table 4, to verify whether the telemetry data sent to the TTE device and the telemetry data received from the TTE device are correct.

[0095] Table 4 Telemetry Parameters for Example 2

[0096]

[0097] The main processes for sending and receiving telemetry data in this embodiment are as follows:

[0098] Step 1: Use a standard signal generator to output voltage values ​​in the hard-wired channels of the telemetry parameter values ​​(parameter 2, parameter 3, parameter 4, parameter 5);

[0099] Step 2: The analog signal board acquires voltage values ​​from the hard-wired channels, and the LabVIEW software sends the acquired values ​​to the host computer software.

[0100] Step 3: The host computer software assembles the collected values ​​into data packets for the corresponding business nodes according to the communication protocol entered in the database and sends them to the LabVIEW software;

[0101] Step 4: Use LabVIEW software to add MAC address, VLID, etc. to assemble the data packets into a TTE packet;

[0102] Step 5: Call the encapsulated interface function to send the TTE packet to the TTE device;

[0103] Step 6: The TTE device sends data in the form of TTE packets, and the encapsulated interface function receives the data and filters out irrelevant TTE packets;

[0104] Step 7: The LabVIEW software reads the TTE packet, removes the TTE packet header, and sends the data packet with the TTE header removed to the host computer software based on information such as MAC address and VLID.

[0105] Step 8: The host computer software reads the data packet, determines that the data packet type is telemetry data, parses the telemetry data according to the database configuration information, and transmits it to the display terminal for display;

[0106] Step 9: Adjust the voltage value output by the standard signal source in the hard-wired channel of parameter 2, and compare it with the value of parameter 2 on the display terminal;

[0107] Step 10: Adjust the voltage value output by the standard signal source in the hard-wired channel of parameter 3, and compare it with the value of parameter 3 on the display terminal;

[0108] Step 11: Adjust the voltage value output by the standard signal source in the hard-wired channel of parameter 4, and compare it with the value of parameter 4 on the display terminal;

[0109] Step 12: Adjust the voltage value output by the standard signal source in the hard-wired channel of parameter 5, and compare it with the value of parameter 5 on the display terminal;

[0110] Step 13: The values ​​of parameters 2 to 5 on the display terminal are consistent with the values ​​indicated by the standard signal source, which verifies that the data sent by the four service nodes to the TTE device and the data received by service node 1 from the TTE device are all correct.

[0111] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A multi-node data communication method simulating the TTE protocol, characterized in that, A TTE device refers to a device that uses a TTE interface; the method uses an Ethernet card to simulate data transmission and reception between multiple service nodes and the TTE device through software; when a service node communicates with the TTE device, the transmission path for sending and receiving data is represented by VLID, and different transmission paths result in different VLIDs.

2. The method according to claim 1, characterized in that, For data sent to the TTE device, an Ethernet card can be used to simulate multiple service nodes sending data to the TTE device through software; among them, the data sent by one service node to the TTE device is remote control data, and the data sent by other service nodes to the TTE device is telemetry data.

3. The method according to claim 1, characterized in that, To receive data from a TTE device, an Ethernet card can be used to simulate multiple service nodes receiving data from the TTE device through software. The data sent by the TTE device to one service node is telemetry data, and the data sent by the TTE device to other service nodes is remote control data.

4. The method according to claim 1, characterized in that, For data sent to the TTE device, a database is used in conjunction with LabVIEW to complete the serialization process, and the encapsulated interface function is called to send the data to the TTE device; the steps are as follows: The database records the communication protocol information related to each business node. If a business node sends instructions to the TTE device and receives telemetry data sent by the TTE device, then the database needs to record information such as instruction code, instruction name, and instruction code, as well as information such as parameter code, parameter name, parameter length in bytes, and parameter offset for each parameter in the telemetry data packet. For telemetry data, the analog signal board collects voltage values ​​from different hardwired channels. The LabVIEW software sends the collected values ​​to the host computer software. The host computer software assembles the collected values ​​into data packets for multiple service nodes according to the communication protocol entered in the database and sends them to the LabVIEW software. The LabVIEW software adds MAC addresses and VLIDs to assemble the data packets of each service node into TTE packets and calls the encapsulated interface functions to send the TTE packets of multiple nodes to the TTE device. For remote control data, after the command is sent from the display terminal, the host computer software sends the command code to the LabVIEW software according to the communication protocol entered in the database. The LabVIEW software adds MAC address and VLID to form a TTE packet, and calls the encapsulated interface function to send the TTE packet to the TTE device.

5. The method according to claim 1, characterized in that, For data sent by TTE devices, the encapsulated interface function is called to receive the data and filter out irrelevant TTE packets. The deserialization process is then completed using a database in conjunction with LabVIEW. The steps are as follows: The TTE device sends data in the form of TTE packets. The encapsulated interface function receives the data and filters out irrelevant TTE packets. The LabVIEW software reads the TTE packets, removes the packet header, and sends the header-less data packet to the host computer software based on information such as the MAC address and VLID. At this point, it is equivalent to sending data packets from multiple service nodes to the host computer software. The host computer software reads the data packets, determines the data packet type, and identifies the data packet content. If it is remote control data, it finds the bound hardwire channel according to the database configuration information and feeds back to the LabVIEW software to execute the corresponding action of the hardwire channel. If it is telemetry data, it parses the telemetry data according to the database configuration information and transmits it to the display terminal for display.

6. The method according to claim 1, characterized in that, To verify whether data transmission and reception are successful, verification can be performed throughout the entire link. For remote control data, the display terminal sends instructions to the TTE device and receives feedback codes from the TTE device. By searching the database for the hard-wired channel bound to the feedback code and executing the corresponding actions, the success of reception can be determined based on the changes in the hard-wired channel. For telemetry data, a standard signal source can be selected to output voltage values ​​in the hard-wired channel of typical parameters. The success of telemetry data transmission can be determined by whether the changes in the standard signal source and the changes in the voltage value displayed on the terminal are consistent.

Images