[Abstract:] The development of industrial control network technology will lead to the emergence of a new industrial branch in the automation field, focusing on industrial network products, network integration, and shared technology R&D services. Gateways, bridges, and network components in industrial control networks will play a crucial role in the future of automation. Research on the technology, theory, and standardization of gateways, bridges, and network components is still in its initial stages, but holds great promise for the future. I. Introduction A little over a decade ago, computer network technology had already become a branch of the computer industry, but industrial control network technology had not yet formed in the automation field. Computer networks have brought unexpected and enormous changes to the IT industry and people's lives; the rapid development of network technology has spurred the emergence of a business group within the IT industry specializing in network product R&D, system integration, and technical services, thus forming a new industry. The development of industrial network technology can be seen as an extension of digital communication technology from the computer industry to the automation industry; in recent years, the emergence and development of fieldbus technology have also brought revolutionary changes to the automation field. Industrial control networks meet the technical requirements of FA/PA for factory information integration, providing a technical platform; while the development of semiconductor microelectronics technology has also provided technical and economic guarantees for the intelligentization of field devices. Industrial control networks, drawing on mature IT technologies, have developed rapidly, sparking countless innovative ideas and opening up vast business opportunities for product development, system integration, and technical services. II. The development of industrial control network technology will drive the emergence of a new industrial branch in the automation field. 1. Industrial control networks will play a crucial role in current and future automation systems. In recent years, the development of automation technology and the ever-changing market landscape have significantly altered the market structure. Some once-renowned companies have seen their market share decline considerably. Some companies that have stagnated in product technology are struggling to survive. Others, however, have maintained rapid market growth, consolidating and strengthening their position. Looking back at the development of the automation industry, a clear trend emerges: companies that prioritized and invested in fieldbus technology and products over a decade ago have maintained and solidified their market position and achieved growth; those that failed to keep pace and missed this opportunity have irreversibly declined, relegated to second-tier positions in the automation industry. This also illustrates another point: industrial control networks will play a vital role in current and future automation technologies. Why is this the case? The reasons have been repeatedly stated by many experts on various occasions: the development of fieldbus technology is based on the following reasons: (1) The network requirements of the equipment and control layers in factory informatization: To achieve factory information integration, communication networks are the technological foundation; fieldbus is a network technology for the factory equipment and control layers (workshop level), therefore, fieldbus technology is the technological foundation for factory information integration. Factory informatization is an essential way to upgrade and transform traditional manufacturing. If my country becomes a manufacturing powerhouse, factory informatization is an important link. Due to the recent demand for factory informatization, the market demand for equipment-level networks and workshop-level equipment networking has grown rapidly, thus promoting the rapid development of fieldbus technology, as well as the industrial Ethernet technology and related products that have emerged in recent years. (2) Automation systems based on fieldbus technology have indeed brought benefits to users. After more than ten years of promotion and application, fieldbus technology has indeed brought benefits to users. Several prominent points are: ① Saving on cable and engineering installation costs: In Europe and America, engineering installation costs are very high, and users are increasingly concerned about the labor costs of projects. In addition, the engineering quality risks and schedule risks caused by a large number of cables being laid, installed, and connected are also increasingly attracting the attention of users. In this regard, fieldbus technology has unparalleled advantages over traditional I/O hard-wiring technology. ② Remote parameterization saves a lot of time for engineering debugging and commissioning. ③ More complete system fault diagnosis function, combined with Internet technology, truly realizes remote fault maintenance. ④ Rich information integration provides possibilities for production management and equipment (asset) management at all levels. (3) The development of computer and semiconductor technology has reduced the cost of intelligent field devices and made them more widely used. The premise of the development of fieldbus technology is the intelligence of field devices. The intelligence of field devices requires the semiconductor industry to provide low-cost, high-function, and highly integrated processor chips and sensor chips. Therefore, the development of fieldbus technology is closely related to the development of semiconductor integrated circuit technology. The rapid development of semiconductor technology in recent years has provided good conditions for reducing the cost and popularizing the application of industrial intelligent field devices. 2. From a technical point of view, industrial control network technology is gradually developing into an independent branch of automation technology. From a technical point of view, industrial control network technology may gradually develop into an independent branch of automation technology. This is because: (1) While industrial control network technology draws on computer network technology, it was developed to meet the specific technical requirements of the automation field; it also applies technologies from other fields, such as semiconductor technology. Industrial control network technology differs from computer network technology. (2) Industrial control network technology has its own unique specialization compared to other technologies in the original automation field. Previously, there was no network technology in the automation field; industrial control network technology will gradually develop into a new and independent technical branch within the automation field. 3. Driven by the market, a group of companies specializing in industrial control network technology, products, and system integration will inevitably emerge, forming a new industrial branch. Based on the development principles of technology, market, and professional division of labor, a group of companies specializing in the R&D and manufacturing of industrial control network products, system design and integration, and research on common basic technologies will emerge in the automation industry. A large number of talents in the development, manufacturing, marketing, and technical support of industrial control network technology and products will also emerge. These companies will engage in the following businesses: (1) Research and development of common basic technologies and related products, including: technical standards, product testing, integration and installation technologies, product development tools, network diagnostic tools, protocol chips, software tools, etc. (2) Product R&D and manufacturing, including: gateways, bridges, repeaters, hubs, switches, optical transceivers, connectors, cables... (3) Industrial control network system design and integration: unit device networking and monitoring systems, workshop-level monitoring systems... Conclusion: A number of enterprises specializing in industrial control network technology R&D, products, and system integration will emerge in the field of automation, and a new industrial branch will appear in the field of automation. III. Gateways, bridges, and network components will play an important role in the future field of automation Gateways, bridges, and network components will play an important role in the future field of automation. On the one hand, due to the increasing demand in the industrial network market, network components will naturally occupy an important position in the entire automation system. However, this article wants to discuss another issue: we will face the reality of multiple network protocols coexisting for a considerable period of time in the future, so gateways and bridges used for protocol conversion will play an important role in future automation systems. 1. "Coexistence of multiple network protocols" will continue for a considerable period of time in the field of automation. "Coexistence of multiple network protocols" will continue for a considerable period of time in the field of automation, which is due to: (1) Historical reasons. Due to well-known historical reasons... (2) Economic Interests of Product Suppliers: Due to economic interests, international alliances of companies supporting various industrial network protocol standards could not find room for compromise in the short term. (3) Market Constraints on Product Technology Development, or simply put, User Acceptance of New Technologies. (4) Technical Reasons: A Review of the Path of International Standardization in Industrial Control Network Technology: The path taken by international standardization in industrial control network technology is indeed different from that in the IT industry. In the IT industry, after years of market selection, Ethernet+TCP/IP ultimately became the de facto near-unique standard. When the IEC International Standards Industrial Control Network Working Group IEC 61158 was first established, it was widely believed that international standardization of industrial control networks would follow a similar path to the development of IT networks, resulting in a single industrial network standard covering most of the needs in the field of industrial automation. However, after more than a decade of effort, no industrial control network similar to Ethernet+TCP/IP has met all the technical needs of the industrial automation field; today, industrial control network standards and products in the automation field remain in a state of chaos and fragmentation. What are the reasons? On the surface, it appears to be due to competition among major international automation conglomerates for their own interests; however, this is only one aspect of the problem. There are deeper reasons: due to the unique characteristics of the automation industry (relative to the IT industry) and its specific requirements for industrial control network technology, a single network technology standard cannot meet all the technical requirements of the industrial automation field. In recent years, with the rise of industrial Ethernet, people have failed to learn from the lessons of the fieldbus standardization process, still fantasizing about using a single network technology standard to cover all the control network needs of a factory from top to bottom. I find this deeply perplexing. Question: When facing different levels and functional requirements, is a "one-size-fits-all" approach a wise choice? Please see Figure 1 below: PA Process Automation Market. This chart shows the proportion of various fieldbus applications in the process automation industry. In most cases, this table is used to illustrate the market share of a certain fieldbus, demonstrating its market performance. However, we can see another problem from this chart: in the process automation industry, the total use of various fieldbuses to connect field devices does not exceed 23%, with the remainder being HART, 4-20mA, and I/O, accounting for approximately 78%. I couldn't find relevant data on Fieldbus (FA) devices. While the number of devices using fieldbus connections might be slightly higher than in the PA (Power Actuator) industry, it's certain that a significant proportion of field devices are connected to controllers via I/O (digital and analog signals). This is the result of over a decade of promoting fieldbus. Industrial Ethernet, on the other hand, is currently mostly used for connections between controllers, forming workshop-level networks. Very few applications truly penetrate to the underlying device layers; they are practically nonexistent in the statistics mentioned above. Why is this the case? Having worked in fieldbus technology promotion for many years, I've observed that field devices used in actual engineering projects employ various connection methods, which are closely related to the functionality and cost of the field devices. For example, frequency converters typically use PROFIBUS-DP or DEVICENET; encoders may use PROFIBUS-DP, DEVICENET, or CANOPEN; digital displays and alarms mostly use low-cost buses like MODBUS/485 or CAN; and push-button boxes and photoelectric switches are all connected via I/O. Site cost is a crucial factor. Site cost refers to the additional cost incurred in adding a communication interface (of a specific protocol) to a field device. Site cost sometimes refers to the increased cost of the product, and sometimes to the increased price. According to the psychology of Chinese customers, the cost (price) increase for products with fieldbus interfaces should be between 10% and 30%; otherwise, they will choose another low-cost communication connection technology. Various fieldbuses (including industrial Ethernet) have significantly different site costs due to differences in function, application environment, and application targets. Similarly, field devices have significantly different costs (prices) due to differences in function, application environment, and application targets. Faced with different functional requirements and cost differences at different levels, multiple communication technology standards should be available for users to choose from in order to configure a system with optimal performance and price. Therefore, the conclusion is that "coexistence of multiple network protocols" will continue in the field of automation for a considerable period of time. 2. Interconnection of heterogeneous communication networks is a problem we must face in the future. Since "coexistence of multiple network protocols" will continue in the field of automation for a considerable period of time, the interconnection of heterogeneous communication networks is a problem we must face in practice. Interconnection of heterogeneous communication networks mainly refers to connecting devices with different communication protocols to a certain industrial control network, or the interconnection of fieldbus systems with different protocols. For example, some common problems encountered include: the requirement for connecting MODBUS devices (devices with the MODBUS communication protocol) to the PROFIBUS bus; the problem of connecting enterprise-defined RS-232/485 devices (such as the HOSTLINK protocol of OMRON PLC) to the PROFIBUS bus; and the problem of connecting DEVICENET devices to the PROFIBUS bus, etc. 3. Gateways and bridges are essential for interconnecting networks with different protocols and at different levels. Interconnecting devices with different network protocols inevitably requires the use of fieldbus gateways and bridges with protocol conversion capabilities. For example, the following are some commonly used gateway bridges: ⑴ PROFINET Gateway ① PROFINET/PROFIBUS Gateway: A gateway connecting a PROFIBUS bus system (product) to a PROFINET network; ② PROFINET/INTERBUS Gateway: A gateway connecting an INTERBUS bus system (product) to a PROFINET network; ③ PROFINET/DeviceNet Gateway: A gateway connecting a DeviceNet bus system (product) to a PROFINET network; ⑵ PROFIBUS Gateway ① PROFIBUS/MODBUS Gateway: A gateway connecting a MODBUS system (product) to a PROFIBUS network; ② PROFIBUS/MODBUS-TCP Gateway: A gateway connecting a MODBUS-TCP system (product) to a PROFIBUS network; ③ PROFIBUS/DeviceNet Gateway: A gateway connecting a DeviceNet system (product) to a PROFIBUS network; ⑶ PROFIBUS Bridge ① PROFIBUS/RS232/RS485 Bridge: A gateway connecting RS-232/485 products to a PROFIBUS network; ② PROFIBUS/CAN Bridge: A gateway for CAN products to connect to a PROFIBUS network; ③ PROFIBUS/Ethernet+TCP/IP Bridge: A gateway for Ethernet+TCP/IP products to connect to a PROFIBUS network; 4. Engineering Examples of Gateways and Bridges Performing Protocol Conversion Functions in Automation Systems ⑴ Typical MCC and PCC Monitoring Systems Figure 2 shows a typical MCC (Motor Control Center) and PCC (Power Control Center) monitoring system in a factory power distribution monitoring system. Currently, domestically produced MCCs and PCCs are generally priced between 1000 and 3000 yuan, with each device handling at least 50 bytes of communication data. MCCs and PCCs priced above 2000 yuan typically have a PROFIBUS-DP interface, while those around 1000 yuan usually use the low-cost MODBUS/485 protocol. In an actual factory power distribution monitoring project, there are generally more than 200 MCCs and PCCs, and large projects can have up to 1000. PROFIBUS network connection is used, with a baud rate of 187.5K typically employed. Theoretically, a single PROFIBUS bus can have a maximum of 125 stations, with each segment having a maximum of 32 stations. More than 32 stations require repeaters to separate the segments. It can be calculated that a project with 500-600 devices requires at least 5 PROFIBUS networks, or 5 PROFIBUS masters. The PROFIBUS network typically needs to connect upwards to the factory's main control system backbone network, such as Ethernet-TCP/IP in a DCS system. Therefore, a PROFIBUS gateway is required, providing one or more (e.g., 5) PROFIBUS master interfaces downwards and an Ethernet-TCP/IP interface upwards. Ideally, the gateway should be an open (embedded) system, such as WinCE or Win2000, allowing users to develop their own application layer protocols, such as MODBUS/TCP. If the MCC and PCC use the MODBUS/485 protocol, the system cost is relatively lower; however, a gateway is still needed, providing an Ethernet-TCP/IP interface upwards and one or more MODBUS/485 master interfaces downwards. MODBUS connections all use RS-485, with a baud rate typically of 19.2K. Theoretically, a single MODBUS bus can have a maximum of 255 stations, with a maximum of 32 stations per segment. More than 32 stations require repeaters to separate network segments. ⑵ City A Metro Line 1 Passenger Information and Display System: City A Metro Line 1 has several PIIS (Passenger Information and Display System) and DTI (Distance Time Indicator) units at each station. PIIS displays the arrival time of the next train arriving at the station and its destination station name; DTI displays the departure time in seconds to the driver in the station. Both PIIS and DTI have RS-485 communication interfaces, and the communication protocol is defined by the project specifications. The data displayed by PIIS and DTI comes from the PROFIBUS master station (RTU DP Master), therefore, both PIIS and DTI need to be connected to the PROFIBUS-DP network using a PROFIBUS/RS485 bus gateway. Each station in this project has 4 PIIS and 2 DTI, sharing 6 PB-B-RS485 bus bridges; a total of 96 PB-B-RS485 bus bridges are used across the 16 stations. This can be considered a large-scale application example of fieldbus gateways in a critical project. The project has been in operation for nearly 2 years, and the equipment and system are functioning well. See Figure 3. (3) The environmental and equipment monitoring system of Metro Line 5 in City B includes station-level subsystems for 16 underground stations, station-level subsystems for 7 ground stations, station-level subsystems for Parking Lot C, and station-level subsystems for Depot D. This system provides comprehensive and effective automated monitoring and management of the HVAC systems, water supply and drainage systems, low-voltage power distribution and lighting systems, elevator systems, safety door systems, and emergency lighting power supplies for all 23 stations and parking lots/depots of Metro Line 5 in City B. It promptly and accurately uploads monitoring data to the integrated monitoring system and simultaneously receives control commands such as mode control and single-point control from the integrated monitoring system. This ensures that the equipment operates in a safe, reliable, efficient, and energy-saving optimal state, providing a comfortable passenger environment. Furthermore, it can better coordinate the operation of station equipment in the event of a fire or traffic jam, fully utilizing the functions of various equipment to guarantee passenger safety and normal equipment operation. The system structure of the underground station is shown in Figure 4 (the system structure of the above-ground station is similar): The station-level network structure is a redundant dual-ring network. The bus between the redundant PLCs and RI/O at both ends A and B is a redundant dual-bus. The connection between the system and third-party communication equipment in the field is achieved through a single bus connected to a Y-LINK via the dual bus. The communication equipment connected to the monitoring system includes: ISCS, chillers (above 350KW), chillers (below 350KW), EPS (Emergency Power Supply for Fire Protection), ATV frequency converters for fans, multi-split air conditioners, landscape lighting for cable-stayed bridges, frequency converters for cooling towers, automatic fire alarm systems (FAS), wheelchair lifts, machine-room-less elevators, moving walkways, escalators under 6 meters, escalators over 6 meters, UPS, and vibration detection modules. The monitoring system uses the following third-party communication interfaces with field devices: RS485-ASCII, LONWORKS, MODBUS-RTU, and PROFIBUS-DP. All third-party field devices must be connected to PROFIBUS-DP; therefore, a communication gateway using PROFIBUS/MODBUS, PROFIBUS/LONWORKS, or a PROFIBUS-to-custom protocol is required for connection. (4) PROFINET/CBA PROFINET is an industrial Ethernet technology standard proposed by the PROFIBUS international organization. PROFINET emphasizes the protection of existing investments, meaning it must be able to interconnect with existing fieldbus systems (PROFIBUS, INTERBUS) to achieve transparent data transmission. PROFINET/CBA is a solution proposed for workshop-level network monitoring. CBA treats production unit equipment as process technology modules, encapsulates them as PROFINET components, defines input/output data, and achieves integration between components. CBA does not concern itself with the internal implementation technology of the process technology modules; whatever fieldbus is used internally, it connects all fieldbus systems to PROFINET through a "proxy server." The "proxy server" must at least have protocol conversion gateway functions and other functions such as controllers. (See Figure PROFINET/CBA in Book IV. The Technology, Theory, and Standardization of Gateways, Bridges, and Network Components Hold Great Potential) Gateways, bridges, and network components will play a crucial role in the future of automation. Many companies have recognized this business opportunity and have begun technical research, product development, and manufacturing work related to gateways, bridges, and network components. More and more users are accepting fieldbus gateways and bridges; system integrators are also becoming proficient in the application technologies of these products. Despite this, the development of industrial control networks is relatively recent, and research, product development, and manufacturing of gateways, bridges, and network components are still in their initial stages. Practical applications and market demands are developing rapidly, making it essential to accelerate the development of technologies, theories, and standardization related to gateways, bridges, and network components for industrial control networks. This article aims to stimulate further discussion and encourages collaboration with interested parties in this research and development. 1. The first step in defining the relevant technical theories should be the definition of technical concepts. Industrial control network technology draws on computer network technology and theories, but it is unnecessary to be confined to them. (1) Technical Concepts of Gateways and Bridges in Computer Networks The technical concepts of gateways and bridges in computer network technology theory have changed significantly with the development of network technology. Based on my research, I summarize the following: "Gateways used to be an easily understood concept. In the early days of the Internet, the term gateway referred to a router. A router was a marker in the network that went beyond the local network. This 'gateway' to the unknown was used, and still is used, to calculate routes and forward packet data to parts outside the originating network; therefore, it was considered the gateway to the Internet. Over time, routers became less mysterious. The emergence and maturity of public IP-based wide area networks (WANs) promoted the growth of routers. Now, routing functions can also be performed by hosts and switching hubs, and gateways are no longer a mysterious concept. Now, routers have become multifunctional network devices. They can divide LANs into several segments, interconnect related LANs in private WANs, and interconnect various WANs to form the Internet. Thus, routers have lost their original gateway concept. However, the term gateway has persisted, continuously being applied to various different functions, making defining a gateway no longer easy. Currently, there are three main types of gateways:" Protocol gateways, application gateways, and security gateways. The only remaining general meaning is that they act as gateways between two different domains or systems, and the nature of the differences to be overcome determines the type of gateway required. "The conversion process can occur at Layer 2, Layer 3, or between Layers 2 and 3 of the OSI reference model. However, there are two types of protocol gateways that do not provide conversion functionality." Currently, many computer networks use the term "gateway." The following diagram (Figure 6) illustrates some connections between the concepts of "gateway": (See book for diagram) "A bridge operates at the data link layer, connecting two local area networks (LANs). It forwards frames based on MAC addresses (physical addresses) and can be considered a 'low-level router' (a router operates at the network layer, forwarding based on network addresses such as IP addresses). It can effectively connect two LANs, restricting local communication to the local network segment and forwarding corresponding signals to another network segment. Bridges are typically used to connect a small number of network segments of the same type. Bridges are generally divided into two main categories: transparent bridges and source routing bridges." (2) In fieldbus technology, the technical concepts of gateways and bridges primarily refer to intermediaries between two different domains or systems, often referring to protocol conversion devices in heterogeneous networks. A gateway generally refers to a device that converts between two (or more) different fieldbus protocols, typically including the physical layer, data link layer, application layer, and even the user layer. Examples include PROFIBUS-DP/MODBUS gateways, PROFIBUS-DP/MODBUS/TCP gateways, and PROFIBUS-DP/PROFINET gateways. The protocol conversion for these three types of gateways includes the physical layer, data link layer, and application layer, as shown in Figure 7. (See figure in the book). For example, connecting a Toshiba VF-A7 inverter to a PROFIBUS-DP gateway: The Toshiba VF-A7 inverter has an RS-485 interface and a company-defined protocol. The gateway should read/write data to the VF-A7 inverter according to the VF-A7 protocol, and the content and format of the read/write data should meet the relevant PROFIBUS inverter specifications. The other side of the gateway should conform to PROFIBUS-DP and relevant inverter industry standards. See Figure 8. (Figure from book) Bridge: Generally refers to a conversion device between two different fieldbus protocols, usually only including the physical layer and link layer. For example: PROFIBUS-DP / CAN bridge, see Figure 9. (Figure from book) (2) Physical layer devices widely used in industrial control networks Due to the needs of industrial environment, network topology, transmission distance, transmission rate, number of stations, terminal matching, etc., a large number of various physical devices are required in the actual application of fieldbus. These devices usually do not have message receiving and forwarding functions, and mainly play the role of extending transmission distance, increasing the number of stations, and changing network topology. For example: Devices working at the same physical layer: repeaters, branches, hubs... Devices that convert between different physical layer protocols: DP/PA couplers, RS-232/485 optical terminal devices, etc. Various types of connectors commonly used in fieldbus systems, such as D9, M16, RJ45, etc., should also belong to physical layer devices, but these are beyond the scope of this article. 2. Regarding product technology (1) According to the ISO/OSI model, fieldbuses typically only have physical, link, and application layers. To address product interchangeability, an additional eighth layer is defined: the user layer, which describes the attributes of various devices in detail and is called the device specification. See Figure 10. (See the book for the figure) Gateways used in industrial control networks, as devices for converting different communication protocols, typically include layers 1, 2, 7, and (8). Gateways that include user layer protocol conversion are the most convenient for users and can be called dedicated gateways (or product gateways, or transparent gateways). For the sake of distinction, gateways that only include protocol conversion of layers 1, 2, and 7 can be called protocol gateways. ① Dedicated (product) gateways refer to gateways that include user layer protocol conversion. When using such a gateway, users do not need to understand the communication protocols of either party, but only need to understand the product information format (product specification). As shown in Figure 11: PROFIBUS dedicated (product) gateway PB-B-VFA7 connected to Toshiba inverters. (See diagram in book) In the PROFIBUS configuration, the user finds "Toshiba Inverter PROFIBUS Gateway PB-B-VFA7" in the device catalog. After configuring it on PROFIBUS, the PROFIBUS I/O data area displays a PROFIBUS (standard) inverter, which details the meaning of each I/O word (byte). Thus, the actual Toshiba VF-A7 inverter becomes a PROFIBUS inverter (slave) in the PROFIBUS master station S7-300. The user does not need to understand the RS-485 communication protocol of the Toshiba VF-A7 inverter; monitoring of the Toshiba VF-A7 inverter can be achieved simply by reading/writing PROFIBUS I/O. This is the transparent data reading and writing achieved by the product (dedicated) gateway, making it the most convenient gateway for users. ② Protocol gateways convert one communication protocol to another, which can also be seen as a mapping of data areas between two different protocol network segments. Network protocol conversion includes layers 1, 2, and 7. For example, a PROFIBUS-DP/MODBUS protocol gateway allows users to connect Altivar frequency converters to the PROFIBUS bus. The difference from a dedicated (product) gateway is that users need to understand the MODBUS protocol and the MODBUS data area address of the Altivar frequency converter. Therefore, users need to configure MODBUS communication commands according to the Altivar frequency converter's "Product Communication Manual" to achieve the exchange of PROFIBUS and MODBUS data. In the STEP 7 master station configuration, the user sees the gateway and configures MODBUS commands, not the frequency converter product itself. See Figure 12 below: (Figure from the book) ⑵ Network Bridge: A network protocol conversion device for different protocols, typically including layers 1 and 2. ① Commonly used bridge products: PB-B-CAN: PROFIBUS to CAN bridge; PB-B-RS232/485: PROFIBUS to RS232-485 bridge; PB-B-Ethernet-TCP/IP: PROFIBUS to Ethernet bridge; ② Challenges in bridge product applications: Fieldbus bridges present a challenge in practical use, which must be considered during product design: How can users implement application layer data when connecting a device with one protocol (layers 1, 2, and 7) to a network with another protocol (layers 1, 2, and 7)? It's best to provide an example. Taking "PB-B-RS232/485: PROFIBUS to RS232-485 bridge" as an example, it requires connecting an RS-232/485 device with a custom communication protocol to PROFIBUS. The enterprise-defined communication protocol is as follows: ● RS-232/485 half-duplex (baud rate, start bit, data bits, parity bit, stop bit...) ● Master/slave response mode ● Data message format (binary): Send: Address code Function code Data area First address Data length CRC check Response: Address code Function code Data area First address Data length Data segment CRC check For example: The RS-232/485 interface of the PB-B-RS232/485 bridge sends the following message: Address code Function code Data area First address Data length CRC check 01H 01H 0010H 000AH CRC The message function is to read the 10 bytes starting from 0010H in the RS-232/485 device data area; The RS-232/485 device responds as follows: Address code Function code Data area First address Data length Data segment CRC check 01H 01H 0010H 000AH Data 1 Data 2 ... Data 10 CRC Check Issue: The PB-B-RS232/485 bridge only has a physical layer interface on the RS-232 side. Where does the message data come from? There are currently two solutions: Method 1: Implement application layer data in the master station (controller) in the bus bridge configuration, as shown in Figure 13 above: (See book for figure) PROFIBUS output area: QB0: RS-232/485 data message transmission length QB0 In this example: 7 QB1: RS-232/485 transmit/receive control word: D7: set_tr D6: set_re D5—D2 D2: relen D1: auto_ D0: start_tr Force receive complete/transmit allowed Force wait for receive No need to receive by length Transmit mode Start transmission QB256～QB319: Configured 64-byte RS-232/485 message data area. QB256 QB257 QB258～QB259 QB260 QB261～QB262 QB263 ... QB319 Address code Function code Data area First address Data length CRC check Not needed Not needed Not needed 01H 01H 0010H 000AH CRC ＊＊ ＊＊ ＊＊ (B) First, the PROFIBUS master station sends QB256～QB319 to the PB-B-RS232/485 bridge via PROFIBUS. The bridge uses automatic transmission/or triggered transmission according to the control word QB1, and sends the RS-232/485 message data QB256～QB262 to the device according to the transmission length of QB0. See Figure 14. (See diagram in book) (C) Field device response IB0: Length of the response message received by the bridge from the field device; IB1: Communication status word; D7: oe_er D6-D3 D2: re_ing D1: tr_ing D0: reok_tren Parity check error Not needed Receiving Sending Receiving complete/Sending allowed IB256～IB319: Configured with a 64-byte RS-232/485 receive message data area. IB256 IB257 IB258～IB259 IB260 IB261 ... IB270 IB271～IB272 IB273 ... IB319 Address code Function code Data area Start address Data length Data 1 ... Data 10 CRC check ** ** ** 01H 01H 0010H 000AH * . . . . . . * CRC ** ** ** The receiving process is shown in Figure 15: Message transmission between field devices, bus bridge, and PROFIBUS master (see book for figure). Method 2: Configuration and download method The bridge manufacturer provides a bridge message configuration software to configure the bridge's send/receive messages, and then download them to the bridge. See Figure 16 below. (See book for figure) 3. Regarding standardization work (1) Technical standards for industrial control network equipment are very necessary, as they can promote the development and improvement of technology and products, and are beneficial to user use and promotion. (2) Relevant standards should include ① Technical concepts ② User interface (interface) ③ Technical indicators: synchronization, consistency, data update rate, etc.