Network data transmission method based on TIA-485 bus and communication device

Abstract

The application discloses a network data transmission method based on TIA-485 bus and communication equipment, which is used for simulating Ethernet communication on a half-duplex TIA-485 bus without collision detection capability. The method comprises the following steps: a sending node receives an original IP data packet, resolves a target IP address of the original IP data packet into a target node identifier on the bus according to a maintained address mapping relationship; performs compression processing on an IP packet header, and replaces the source and / or target IP address with an address index code to generate a compressed network payload; encapsulates the target node identifier and the compressed network payload into a token data frame; and the sending node sends the token data frame after obtaining bus sending authority through a token polling mechanism. The application combines address mapping, IP packet header compression and token scheduling, and realizes efficient and reliable bearing of a standard IP protocol while maintaining the economy and reliability of TIA-485 wiring, so that upper-layer network applications can be operated without modification.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network communication, in particular to a network data transmission method based on TIA-485 bus and a communication device. BACKGROUND

[0002] Industrial control sites usually adopt centralized control mode, connecting various actuators and sensors through PLC or remote I / O modules. In order to improve the efficiency of complex device installation and commissioning, large systems are currently often pre-divided into multiple physical sections, and local controllers with edge computing capabilities are deployed in each section. Such controllers need to complete the logic control of the local section while communicating with upstream and downstream sections for task synchronization, state coordination and other data communication. Since their upper-layer application software is generally developed based on TCP / IP protocol stack, these distributed controllers must have network interconnection capability supporting IP protocol.

[0003] Currently, there are three ways to achieve such interconnection: the first way is to use standard Ethernet wired connection, which has high reliability, but requires additional deployment of switches and multiple independent network cables, which has the problems of complex wiring, high cost and distance and interference limitations in long-distance, multi-node and segmented docking industrial sites; the second way is to use wireless local area network, which simplifies wiring but lacks stability in complex electromagnetic industrial sites; the third way is to use cellular mobile networks, which is suitable for remote Internet of Things, but has concerns about transmission delay, high operating cost and data local transmission security, making it difficult to meet the real-time, reliable and economical data exchange needs between on-site devices.

[0004] TIA-485 bus, as a mature industrial serial communication standard, has the advantages of strong anti-interference ability, long transmission distance, support for multi-point connection and low wiring cost, and is a common choice for industrial device-level communication. However, as a half-duplex, physical layer and link layer specification without network layer function, it cannot directly carry Ethernet protocols based on contention detection, and it is also difficult to efficiently transmit TCP / IP data packets. Although there are existing technologies that transparently transmit serial data through Ethernet, they cannot enable devices to use IP-based high-level protocols for peer-to-peer communication natively and transparently.

[0005] Therefore, it is necessary to design a communication simulation method that combines the advantages of TIA-485 bus physical layer and the application requirements of TCP / IP protocol stack, so that scattered edge computing devices can directly build a virtual Ethernet supporting standard network programming interface through simple, reliable and low-cost bus connection, thereby overcoming the contradiction between wiring, cost, reliability and protocol compatibility faced by current industrial site device networking. SUMMARY

[0006] The technical problem solved by the present application is how to convert a standard original IP data packet into a format suitable for bus transmission on a half-duplex, non-collision detection capable TIA-485 bus, and realize reliable and orderly one-way data transmission by using a token polling mechanism.

[0007] To solve the above technical problems, the technical scheme adopted by the present application is a network data transmission method based on a TIA-485 bus, wherein the TIA-485 bus is a half-duplex bus, and the method comprises the following steps:

[0008] In a sending node, an IP data packet to be sent is received;

[0009] Based on a maintained address mapping relationship, a target IP address in the IP data packet is resolved into a target node identifier used on the TIA-485 bus;

[0010] An IP packet header of the IP data packet is compressed to generate a compressed network payload, wherein the compression process comprises replacing a source IP address and / or a target IP address in the IP data packet with a corresponding address index code according to the address mapping relationship;

[0011] The target node identifier and the compressed network payload are encapsulated into a token data frame;

[0012] After obtaining the sending right of the TIA-485 bus by a token polling mechanism in the sending node, the token data frame is sent to the TIA-485 bus.

[0013] Further, the token polling mechanism is realized by the following ways:

[0014] A token ring is logically constructed on the TIA-485 bus, and each node on the ring is allocated a unique node identifier;

[0015] A dynamic ring member list is maintained to record the current valid node identifiers and their order;

[0016] The token is passed between the nodes in the ring member list in turn, and the node holding the token obtains the sending right of the TIA-485 bus.

[0017] Further, the maintained address mapping relationship is established and updated by the following ways:

[0018] Each node announces its own IP address and the local address index allocated thereto;

[0019] In response to a query for an unknown IP address, an address query request is broadcast on the TIA-485 bus, and an address announcement returned by a node owning the address is received.

[0020] Further, the IP packet header compression processing includes the following steps when the IP packet is an IPv4 packet:

[0021] If the source IP address belongs to the sending node itself, a first identification bit indicating this state is generated; otherwise, the source IP address is replaced by its corresponding first index code in the address mapping relationship;

[0022] The target IP address is replaced by a second index code or complete address data, and the generation of the second index code includes the following steps: when the target IP address is a unicast address, a preset prefix byte not belonging to a legal IPv4 unicast address range is combined with the index value in the mapping relationship.

[0023] Further, the IP packet header compression processing includes the following steps when the IP packet is an IPv6 packet:

[0024] The source IP address is encoded into a source address field containing information about whether it is a local address;

[0025] The target IP address is subjected to a compression strategy, which includes a zero compression strategy of omitting continuous zero fields in the address or replacing them with a predefined multicast address index.

[0026] Further, the method further includes the following data scheduling steps:

[0027] The control message for maintaining the address mapping relationship is placed in a high-priority sending queue;

[0028] The encapsulated token data frame is placed in a normal-priority sending queue;

[0029] When obtaining sending permission, the message in the high-priority sending queue is preferentially sent.

[0030] Further, in the step of encapsulating the target node identification and the compressed network payload into a token data frame, consistent zero suppression encoding is used to encapsulate the frame data containing the compressed network payload.

[0031] Further, the method further includes the following rate adaptation steps:

[0032] According to the physical layer rate and protocol overhead of the TIA-485 bus, the available data bandwidth of the sending node is determined;

[0033] The data sending rate of the sending node is limited so as not to exceed the available data bandwidth.

[0034] The application further provides an Ethernet analog communication method based on a TIA-485 bus, data transmission is performed by executing the method according to any one of the above, and the method further comprises the following steps:

[0035] Receiving a token data frame from the TIA-485 bus at a receiving node;

[0036] Parsing the token data frame to obtain a sending node identifier, a target node identifier and compressed network payload;

[0037] Based on the address mapping relationship, restoring the sending node identifier to a source IP address and decompressing the compressed network payload to recover an original IP packet header;

[0038] Submitting the recovered IP data packet to an upper protocol stack.

[0039] The application further provides a communication device for connecting to a TIA-485 bus, comprising a processing unit and a memory, the memory storing a computer program, when the computer program is executed by the processing unit, the communication device is configured to implement the method according to any one of the above.

[0040] The application has the beneficial effects that: by parsing the target address of a standard IP data packet into a bus-specific node identifier, and performing address mapping-based compression encoding on the IP packet header, and combining a token polling mechanism to control the sending authority, efficient, reliable and orderly network data unidirectional transmission is realized on a half-duplex, collision detection-free TIA-485 bus; the scheme effectively avoids bus data collision, significantly improves bus bandwidth utilization, and enables upper IP applications to directly run without sensing the difference of the underlying bus. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained from the drawings shown without creative labor.

[0042] Figure 1 A network data transmission method flowchart based on a TIA-485 bus according to an embodiment of the application;

[0043] Figure 2 A TIA-485 bus structure schematic block diagram according to an embodiment of the application;

[0044] Figure 3 A network layer structure schematic block diagram according to an embodiment of the application;

[0045] Figure 4 a schematic block diagram of a link layer structure of an embodiment of the present application;

[0046] Figure 5 a schematic block diagram of a communication device of an embodiment of the present application. DETAILED DESCRIPTION

[0047] The technical solutions in the embodiments of the present application will be apparently and completely described with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by a person of ordinary skill in the art without any creative work fall within the protection scope of the present application.

[0048] It should be noted that the descriptions of "first", "second", etc. in the present application are only for the purpose of description, and cannot be understood as indicating or implying the relative importance of the indicated technical features or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In addition, the technical solutions of various embodiments can be combined with each other, but it must be based on the fact that a person of ordinary skill in the art can realize it. When the combination of technical solutions appears contradictory or unachievable, it should be considered that the combination of technical solutions does not exist, and is not within the protection scope required by the present application.

[0049] The general idea of the present application is to build a complete communication protocol stack running on TIA-485 bus. The protocol stack includes link layer and network layer, which work together to simulate Ethernet communication behavior. Among them, the link layer solves the ordered access and conflict avoidance problem on half-duplex bus through token ring protocol; the network layer solves the IP addressing and low bandwidth efficiency problem through address mapping protocol and IP packet header compression technology.

[0050] As shown in Figure 1 An embodiment of the present application is: a network data transmission method based on TIA-485 bus, the TIA-485 bus is a half-duplex bus, and the method comprises steps S1-S5.

[0051] As shown in Figure 2As shown, TIA-485 bus uses twisted-pair shielded cable with characteristic impedance close to 120 Ω (e.g. RVVP, STP, etc.). The two wires of the twisted pair serve as A / B signal lines. The wire diameter is 0.5-1.0 mm² (24~18 AWG). In the case of long distance and large number of nodes, thicker cable can be selected to reduce voltage drop. Do not use miscellaneous wire splicing. Miscellaneous wire splicing has large impedance variation and is prone to reflection. The topology strictly adopts a bus structure. All communication devices are connected as nodes in series on a main line. Star-shaped and tree-shaped branches should be avoided as much as possible due to serious reflection in branch structure. The wiring should be separated from strong electricity. Keep at least 20-30 cm away from power cables and frequency converter output lines, and the farther the better. If necessary, use metal wire slot or steel pipe shielding, and the shielding should be continuous. Add a 120 Ω terminal resistor at each end of the TIA-485 bus to match the characteristic impedance of the twisted pair. The resistor should be as close as possible to the terminal of the last node at both ends. If the end node has a built-in terminal resistance function, it is preferred to turn it on and use the built-in terminal resistance.

[0052] S1, receiving an IP data packet to be sent at a sending node.

[0053] In this step, a TUN virtual network interface is created on the sending node (usually an edge computing device). The operating system and all upper layer applications treat it as a normal network card, and all data packets sent to it with a target IP that is not the local IP will be captured by this interface. The protocol stack obtains the original and complete IP data packet (including IPv4 or IPv6). In order to adapt to the limited bandwidth of the underlying bus, the TUN interface must be shaped for outgoing traffic, for example, in Linux, use the tc qdisc command to limit the rate to the available bandwidth (e.g. 800 kbps) calculated based on the physical layer rate (e.g. 1 Mbps) minus the protocol overhead (e.g. token frame header, COBS encoding overhead, token transfer interval), and set reasonable burst capacity and delay tolerance parameters to prevent sending queue congestion and TCP timeout.

[0054] S2, based on the maintained address mapping relationship, resolving the target IP address in the IP data packet into a target node identifier used on the TIA-485 bus.

[0055] In this step, it is completed by the address mapping protocol (AMP) of the network layer, and the structure of the network layer of the application is as shown in Figure 3 The function is equivalent to the ARP of Ethernet, but is designed for token ring environment. Each node maintains two key tables: the first table is the self-address table, which records all local IP addresses and their assigned local indexes (0-15); the second table is the global address mapping table, which records the correspondence between the identifiers of other nodes on the bus and their IP addresses. When resolving the IP address, the global mapping table is queried first.

[0056] In specific embodiments, the maintained address mapping relationship is established and updated by the following ways:

[0057] A1, each node announces its own IP address and the local address index allocated thereto.

[0058] When the node IP address is changed (added or deleted), or the node first joins the token ring, it will be announced through the sending of an AMP full table packet (frame type binary 00100000) or an update packet (frame type binary 00110000) broadcast. The full table packet contains in turn: the total number of node IP addresses, and the type-index byte of each IP (such as IPv4 address index x encoded as 0111xxxx, IPv6 address index x encoded as 1111xxxx) and the complete address data. The node will calculate a CRC8 check value (polynomial 0x07) for its own address table, which is used in the update packet for other nodes to compare consistency.

[0059] A2, in response to a query for an unknown IP address, broadcast an address query request on the TIA-485 bus and receive the address announcement returned by the node owning the address.

[0060] When there is no record of the target IP address in the global mapping table, the node will construct an AMP "IPv4 request packet" (frame type binary 01100000) or "IPv6 request packet" (frame type binary 01110000) broadcast on the bus. To prevent network shock, the protocol sets a dense IP query time window (e.g. 10 seconds) and a dense IP query limit (e.g. 5 times) flow control mechanism. Any node owning the IP address will reply to the query with a full table packet. In addition, the node will also periodically or when the address table has been unchanged for a long time, send a refresh packet (frame type binary 01010000) carrying its own address table CRC to maintain the robustness of the mapping table.

[0061] S3, performing compression processing on the IP packet header of the IP data packet to generate a compressed network payload, wherein the compression processing includes replacing the source IP address and / or the target IP address in the IP data packet with the corresponding address index code according to the address mapping relationship.

[0062] This step is the core of improving the transmission efficiency on the low-speed bus. Through deep analysis of the IP packet header by compression algorithm, the long IP address is replaced by short index code using the address mapping relationship established by AMP, and a large number of fields that are fixed values or zeros in typical communication are omitted.

[0063] In specific embodiments, the IP packet header is compressed, and when the IP packet is an IPv4 packet, the compression specifically includes steps S311-S312.

[0064] S311, if the source IP address belongs to the sending node itself, a first identification bit indicating this state is generated; otherwise, the source IP address is replaced with a first index code corresponding to the address mapping relationship.

[0065] This step is IPv4 source address coding: first, it is judged whether the source IP address belongs to the local machine. If yes, the second bit (k bit) of the first byte (counting from 0) of the compressed header is set to 1, indicating that the source address is the sending node address itself. If not (k=0), the index of the source IP address needs to be obtained by querying the address table. When coding, a byte is used, of which the high 4 bits are fixed as 1110 (0xE), and the low 4 bits are the index value. The 0xE prefix belongs to the multicast segment (224.0.0.0-239.255.255.255) in the legal IPv4 unicast address, so it will not be confused with the real source address, ensuring the unique identifiability of the coding.

[0066] S312, the target IP address is replaced with a second index code or complete address data, and the generation of the second index code includes: when the target IP address is a unicast address, a preset prefix byte not belonging to the legal IPv4 unicast address range is combined with the index value in the mapping relationship.

[0067] This step is IPv4 destination address encoding: this encoding is defined by the 3rd and 4th bits (l and m bits) of the 1st byte of the compressed header. First, query the AMP global mapping table to obtain the node identification and address index corresponding to the destination IP address. Case one: if the destination address is a broadcast address (255.255.255.255), set l = 1, m = 1, and no additional field is needed. Case two: if the destination address is a unicast address and is the only IPv4 address of the opposite node, set l = 0, m = 1. Case three: if the opposite node has multiple IPv4 addresses, set l = 1, m = 0, and add a destination address encoding byte later, with the high 4 bits being 1111 (0xF) and the low 4 bits being the address index obtained by querying. Case four: if the destination address is a multicast address, set l = 1, m = 0, and add a destination address encoding byte later, with the high 2 bits being 01 and the low 6 bits being the pre-defined multicast sequence number (0-63). In addition, the low 4 bits of the 0th byte of the compressed header are directly taken from the IHL field of the original IPv4 header. The Total Length field has its high 5 bits always 0 under MTU limitation, so only the low 11 bits are taken and stored in the 1st and 2nd bytes together with the protocol type encoding (ij bits). The TOS, Identification, Flags and Fragment Offset fields in the original header are omitted if they are all detected to be zero, and the presence or absence of each field is indicated by the b, c, d bits of the 0th byte, respectively.

[0068] In specific embodiments, the IP packet header is compressed, and when the IP packet is an IPv6 packet, the compression specifically includes steps S321-S322.

[0069] S321, encode the source IP address into a source address field containing information on whether it is a local address.

[0070] This step is Ipv6 source address encoding: also indicated by the k bit of the 1st byte of the compressed header. If k = 0 and the subsequent source address field is a specific value 0xFF, it indicates that the source address is the unique IPv6 address of the sending node. If k = 1, it indicates that the high 4 bits of the first byte of the source address field contain the index of the source IPv6 address in the own address table.

[0071] S322, apply a compression strategy to the destination IP address, which includes a zero compression strategy of omitting consecutive zero fields in the address, or replacing them with a pre-defined multicast address index.

[0072] This step is the encoding of IPv6 destination address: indicated by l and m bits, a variety of flexible strategies are adopted. For unicast address, 1 byte index encoding can be used. For multicast address, 1 byte multicast index encoding (high 2 bits 01) is used. For IPv6 address with significant continuous zero field (this is a common case), zero compression strategy is adopted: find the longest continuous zero segment in the address, replace it with "::", and use one length indication byte in the compressed encoding to record the length of non-zero segments before and after the zero segment (0-7 each), then directly transmit these non-zero segments, thereby greatly reducing the amount of data. For some predefined, commonly used multicast addresses (such as all nodes, all routers, DHCPv6 service addresses, etc.), the protocol defines shorter fixed encodings (for example, represented by 1 byte special code), without the need to transmit the complete 16 byte address.

[0073] S4, encapsulate the target node identifier and the compressed network payload into a token data frame.

[0074] This step is completed by the link layer, and the purpose is to add control information required for bus transmission to the upper layer data. The encapsulated token data frame is the atomic transmission unit on the bus. The structure of the link layer of the present application is shown in Figure 4 .

[0075] In a specific embodiment, in the step of encapsulating the target node identifier and the compressed network payload into a token data frame, consistent zero-overwrite encoding is used to encapsulate the frame data containing the compressed network payload.

[0076] In a specific embodiment, the encapsulated frame data is re-encoded using consistent zero-overwrite encoding (COBS). The COBS encoding rule ensures that there is no 0x00 byte in the frame, so that 0x00 can be explicitly used as a frame delimiter. The encoder traverses the original data and replaces 0x00 with the distance value from the current point to the next 0x00 (or the end of the frame) when it encounters 0x00. The decoder restores the original data according to these distance values and inserts 0x00. Although COBS introduces a small amount of overhead (at least 1 byte per frame, and each original 0x00 becomes a non-zero distance value), its overhead is constant and the algorithm is simple and reliable. Combined with the compression processing in step S3, which has greatly eliminated 0x00 in the IP packet header, the actual additional overhead of COBS is effectively controlled.

[0077] S5, after the sending node obtains the sending right of the TIA-485 bus through the token polling mechanism, the token data frame is sent to the TIA-485 bus.

[0078] This step is the core application of the link layer token ring protocol, which solves the conflict avoidance problem on the half-duplex bus. The protocol allocates the sending right through the sequential delivery of a virtual, logical token in the ring-shaped node list.

[0079] In specific embodiments, the token polling mechanism is implemented by means of B1-B3 as follows:

[0080] B1. A token ring is logically constructed on the TIA-485 bus, and each node on the ring is assigned a unique node ID.

[0081] In this step, when a node is powered on or detects that the bus is silent for longer than the maximum bus silence time (e.g., 3 seconds), it considers that there is no active ring on the network and creates a new token ring as the originating node. It generates a 4-byte ring ID, with the first byte being its own node ID and the last three bytes being random values (0x00 should be avoided). At the same time, it assigns itself a node ID (e.g., 0x01) and enters a waiting node state, starting to periodically send an invitation to join frame (frame type binary 10100011).

[0082] B2. A dynamic ring member list is maintained, recording the current valid node IDs and their order.

[0083] In this step, each node locally maintains an online member table, recording the IDs of all active nodes in the ring in the order of joining. This list is synchronized through the reception of a member table frame (frame type binary 10100101) or a declaration frame carrying the MemberTableCRC. The member table frame contains a MemberTableEntities field, which is in the format: [online node ID1, ID2,..], 0xFF, [abandoned node IDa, IDb,..]. A CRC8 check value is used to verify the consistency of the list. When a node joins (receives an acknowledgement to join frame, frame type binary 10100010) or leaves (receives a declaration to leave frame, frame type binary 10100100, or times out), the list is updated.

[0084] B3. The token is passed between nodes in the ring member list in turn, and the node holding the token obtains the transmission right of the TIA-485 bus.

[0085] In this step, the token is passed among the ring members in turn. The token-holding node can send data frames or maintenance frames within the token's validity period (e.g. 50 ms). If it has no data to send, it should send a token release frame (frame type binary 10100001) to pass the token to the next node in the local online member table. If a node is detected to be silent for more than the maximum node silence time (e.g. 200 ms), other nodes in the ring will consider it offline, move it from the local online member table to the discard table, and consider the token to have logically passed to the next node. This mechanism enables the token ring to have the ability to automatically recover from node failures. The protocol also defines rules for handling the merging after a bus break: when a node receives a token frame with a RingId smaller than its current record, it will actively abandon the current ring state and try to join the ring identified by the RingId, thus eventually implementing the merging of multiple split rings.

[0086] In specific embodiments, the method further comprises the following data scheduling step:

[0087] C1, placing control messages for maintaining address mapping relationship in a high-priority sending queue;

[0088] C2, placing the encapsulated token data frame in a normal-priority sending queue;

[0089] C3, when obtaining sending permission, preferentially sending messages in the high-priority sending queue.

[0090] In this embodiment, multiple sending queues are maintained inside the protocol stack to distinguish priorities. The highest-priority queue is used for AMP control messages (address announcement, query, etc.) and critical link layer maintenance frames (such as token release frames). The normal-priority queue is used for encapsulated user data token frames. When a node holds the token, all packets in the high-priority queue are strictly preferentially sent, and then data in the normal queue is sent. This ensures the timeliness of the network control plane, and even under high data load, the basic functions such as address discovery and ring maintenance are not affected.

[0091] In specific embodiments, the method further comprises the following rate adaptation step:

[0092] D1, determining the available data bandwidth of the sending node according to the physical layer rate of the TIA-485 bus and the protocol overhead;

[0093] D2, limiting the data sending rate of the sending node so that it does not exceed the available data bandwidth.

[0094] In this embodiment, the network layer needs to evaluate the actual available data bandwidth of the bus. This needs to consider multiple factors such as the physical layer nominal rate (e.g. 1 Mbps), the fixed overhead of token frame, the COBS encoding expansion factor, the idle time slot caused by token rotation, etc. After calculating a conservative available data bandwidth value (e.g. 700-800 kbps), a hard egress rate limit is imposed on the TUN virtual interface through the operating system tool (e.g. Linux TC). This is essentially to let the flow control protocol such as TCP run on a virtual link that matches its physical characteristics, thereby avoiding the problem of bus queue overflow, packet being discarded, and then causing timeout retransmission and throughput collapse due to too high sending rate.

[0095] The embodiment of the present application also provides an Ethernet simulation communication method based on a TIA-485 bus, data transmission is performed by executing the method in any of the above, and further comprising steps S6-S9.

[0096] S6, receiving a token data frame from the TIA-485 bus at a receiving node.

[0097] S7, parsing the token data frame to obtain a sending node identifier, a target node identifier and a compressed network payload.

[0098] In this step, the receiving node continuously listens to the bus and obtains the original token frame through COBS decoding. It verifies the frame CRC (short frame CRC8, long frame CRC32) and checks whether the target node identifier matches the local ID, the subscribed multicast ID or the broadcast ID (0xFF).

[0099] S8, restoring the sending node identifier to a source IP address based on the address mapping relationship, and decompressing the compressed network payload to recover the original IP packet header.

[0100] This step is the reverse process of the sending end processing. First, the IP address list of the sending node is obtained by querying the AMP global mapping table according to the sending node identifier. Second, the state bits such as k, l and m in the compressed packet header are parsed: if k = 1, the source address is the unique address of the sending node (obtained from the list); if k = 0, the specific source IP is determined according to the prefix and index value of the source address encoding byte. For the target address, the complete target IP address is restored according to the l, m bits and possible subsequent encoding bytes, combined with the self address table or multicast mapping table. Finally, according to the state bits such as b, c and d, the IP packet header fields (such as TOS, Identification, etc.) omitted by the sending end are filled with default values (0) or read from the specified position of the compressed packet body, and the original IP packet header conforming to the RFC standard is completely reconstructed, and the IPv4 header checksum is recalculated.

[0101] S9, submit the recovered IP data packet to the upper layer protocol stack.

[0102] In this step, an IP data packet generated from the sending end application layer, processed through the complex protocol stack, traversed the TIA-485 bus, and finally restored at the receiving end, is submitted to the TCP / IP protocol stack of the receiving end. For the two application programs, the entire communication process is no different from using a normal Ethernet, and the difference of the underlying bus is completely shielded.

[0103] In summary, the technical scheme provided by the embodiment of the application successfully builds a transparent, efficient and reliable virtual Ethernet channel by innovatively integrating the link layer token ring protocol and the network layer address mapping and compression protocol on the TIA-485 bus. The scheme not only effectively solves the problems of high complexity, high cost and distance limitation caused by traditional Ethernet wiring in industrial sites, but also fully utilizes the inherent advantages of the TIA-485 bus, such as strong anti-interference, low cost and suitability for long-distance multi-node connection. Through dynamic address mapping instead of ARP, deep IP packet header compression, and token-based deterministic scheduling, the utilization rate of the limited bus bandwidth is greatly improved, and data conflicts are fundamentally avoided. At the same time, the node self-discovery, topology self-healing and rate adaptation capabilities of the protocol stack ensure the long-term stable operation of the network in the industrial environment. Finally, the upper layer application program based on the TCP / IP protocol stack can run directly on the hybrid network without any modification, realizing complete Ethernet communication simulation from the physical layer to the application layer, and providing a highly cost-effective and reliable device interconnection solution for industrial Internet of Things and edge computing scenarios.

[0104] The embodiment of the application also provides a communication device for connecting to a TIA-485 bus, comprising a processing unit and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processing unit, the communication device is configured to implement the method according to any one of the above.

[0105] The network data transmission method based on the TIA-485 bus can be implemented in the form of a computer program, which can run on a communication device as shown in Figure 5 .

[0106] Please refer to Figure 5 , Figure 5 is a schematic block diagram of a communication device provided by the embodiment of the application. The communication device 500 can be a terminal or a server, wherein the terminal can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a personal digital assistant, a wearable device and other electronic devices with communication functions. The server can be a stand-alone server or a server cluster composed of multiple servers.

[0107] Referring to Figure 5 The communication device 500 comprises a processor 502, a memory and a network interface 505 connected through a system bus 501, wherein the memory can comprise a non-volatile storage medium 503 and an internal memory 504.

[0108] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 comprises program instructions which, when executed, can cause the processor 502 to perform a network data transmission method based on TIA-485 bus.

[0109] The processor 502 is configured to provide computing and control capabilities to support the operation of the entire communication device 500.

[0110] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503, which, when executed by the processor 502, can cause the processor 502 to perform a network data transmission method based on TIA-485 bus.

[0111] The network interface 505 is configured to perform network communication with other devices. Those skilled in the art can understand that Figure 5 The structure shown in FIG. 5 is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the communication device 500 to which the scheme of the present application is applied. The specific communication device 500 can comprise more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0112] The processor 502 is configured to run the computer program 5032 stored in the memory to implement the steps of the network data transmission method based on TIA-485 bus as described above.

[0113] It should be understood that, in the embodiments of the present application, the processor 502 can be a central processing unit (CPU), and the processor 502 can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0114] Those skilled in the art can understand that all or part of the processes in the method of the above-mentioned embodiments can be completed by instructing the relevant hardware by a computer program. The computer program includes program instructions, and the computer program can be stored in a storage medium, which is a computer readable storage medium. The program instructions are executed by at least one processor in the computer system to realize the process steps of the above-mentioned embodiment of the method.

[0115] Therefore, the application further provides a storage medium. The storage medium can be a computer readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. The program instructions are executed by a processor to make the processor execute the steps of the network data transmission method based on the TIA-485 bus as described above.

[0116] The storage medium can be a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk, and various computer readable storage media that can store program codes.

[0117] Those skilled in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in general terms in the above description. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the application.

[0118] In several embodiments provided by the application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of each unit is only a logical function division, and actual implementation can have another division manner. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0119] The steps in the method of the embodiments of the application can be adjusted, combined and deleted according to actual needs. The units in the device of the embodiments of the application can be combined, divided and deleted according to actual needs. In addition, each functional unit in each embodiment of the application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit.

[0120] The integrated unit, if realized in the form of a software function unit and sold or used as an independent product, can be stored in a storage medium. Based on such understanding, the technical solutions of the present application essentially or say the part of the prior art that contributes to the present application, or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a communication device (which can be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the method described in the various embodiments of the present application.

[0121] The above is merely specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present application, and these modifications or replacements shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

[0122] The above is merely specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical range disclosed by the present application, and these modifications or replacements shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A network data transmission method based on a TIA-485 bus, wherein the TIA-485 bus is a half-duplex bus, characterized in that, The method includes the following steps: At the sending node, IP data packets to be sent are received; Based on the maintained address mapping relationship, the target IP address in the IP packet is resolved to the target node identifier used on the TIA-485 bus; The IP header of the IP data packet is compressed to generate a compressed network payload, wherein the compression process includes replacing the source IP address and / or destination IP address in the IP data packet with the corresponding address index code according to the address mapping relationship; The target node identifier and the compressed network payload are encapsulated into a token data frame; After the sending node obtains the sending permission of the TIA-485 bus through the token polling mechanism, it sends the token data frame to the TIA-485 bus. The token polling mechanism is implemented in the following way: A token ring is logically constructed on the TIA-485 bus, and a unique node identifier is assigned to each node on the ring. Maintain a dynamic list of ring members, recording the currently valid node identifiers and their order; The token is passed sequentially among the nodes in the ring member list, and the node holding the token gains the right to send data on the TIA-485 bus.

2. The network data transmission method based on the TIA-485 bus according to claim 1, characterized in that, The maintained address mapping relationship is established and updated in the following ways: Each node announces its own IP address and the local address index assigned to it; In response to a query for an unknown IP address, an address query request is broadcast on the TIA-485 bus, and an address announcement is received from the node that owns the address.

3. The network data transmission method based on the TIA-485 bus according to claim 1, characterized in that, The compression of the IP header of the IP data packet, when the IP data packet is an IPv4 data packet, specifically includes: If the source IP address belongs to the sending node itself, a first identifier bit indicating this state is generated; otherwise, the source IP address is replaced with its corresponding first index code in the address mapping relationship. The target IP address is replaced with a second index code or complete address data. The second index code is generated by combining a preset prefix byte that does not belong to the range of valid IPv4 unicast addresses with its index value in the mapping relationship when the target IP address is a unicast address.

4. The network data transmission method based on the TIA-485 bus according to claim 1, characterized in that, The compression of the IP header of the IP data packet, when the IP data packet is an IPv6 data packet, specifically includes: The source IP address is encoded into a source address field that includes information on whether it is a local address. A compression strategy is applied to the target IP address, the compression strategy including: a zero compression strategy that omits consecutive zero fields in the address, or replaces them with a predefined multicast address index.

5. The network data transmission method based on the TIA-485 bus according to claim 1, characterized in that, The method also includes the following data scheduling steps: Place control messages used to maintain address mapping relationships in a high-priority sending queue; Place the encapsulated token data frame into a normal priority sending queue; When sending permission is granted, messages in the high-priority sending queue are sent first.

6. The network data transmission method based on the TIA-485 bus according to claim 1, characterized in that, In the step of encapsulating the target node identifier and the compressed network payload into a token data frame, consistent zero-crossing encoding is used to encapsulate the frame data containing the compressed network payload.

7. The network data transmission method based on the TIA-485 bus according to claim 1, characterized in that, The method further includes the following rate adaptation steps: The available data bandwidth of the transmitting node is determined based on the physical layer rate and protocol overhead of the TIA-485 bus. The data transmission rate of the sending node is limited to ensure that it does not exceed the available data bandwidth.

8. A method for Ethernet analog communication based on the TIA-485 bus, characterized in that, Data transmission is performed by executing the method as described in any one of claims 1 to 7, and further includes the following steps: At the receiving node, a token data frame is received from the TIA-485 bus; Parse the token data frame to obtain the sending node identifier, the target node identifier, and the compressed network payload; Based on the address mapping relationship, the sending node identifier is restored to the source IP address, and the compressed network payload is decompressed to restore the original IP packet header; The recovered IP packets are submitted to the upper-layer protocol stack.

9. A communication device for connecting to a TIA-485 bus, characterized in that, The device includes a processing unit and a memory, the memory storing a computer program that, when executed by the processing unit, configures the communication device to implement the method of any one of claims 1 to 8.

Images