A High Speed Redundant IO Bus for Energy Power Controller System

This paper designs and implements a High Speed Redundant IO Bus for Energy Power Controller System. The physical layer adopts multi-point low-voltage differential signal standard. This bus has the characteristics of high real-time, high throughput and easy expansion. The controller communicates with IO module by A/B bus alternately, monitors link status in real time and collects IO module data. Non real time slots can be used to control non real time messages for IO modules such as time synchronizing and memory monitoring. The controller ARM core runs QNX real-time operating system, and transmits the message needed to communicate with IO modules to the FPGA through DMA. After receiving the message, the FPGA parses the message and automatically fills in the CRC check code and frame end flag at the end of the message. When the FPGA receives the data feedback from the IO module, it performs CRC verification. If the verification passes, it fills the corresponding module receiving buffer. Otherwise, it fills the CRC verification error flag in the register of the corresponding IO module to reduce the load of the arm core.

communication packets of the universal asynchronous receiver transmitter (UART). The detailed design is cited from paper [11].

Overall System Plan
The current mainstream control system architecture can be generally divided into four levels: the field instrument layer, the control device unit layer, the factory (workshop) layer, and the enterprise management layer [12], where the control unit layer includes the controller and the IO module. The interconnection between the controller and the IO module is the hub of data transmission of the whole system. It has very high requirements in real-time, reliability and scalability. The efficiency of the bus directly affects the performance of the entire control system [1]. The controller designed in this paper adopts the scheme of active/standby redundancy, and the IO unit adopts the A/B redundant IO bus scheme. The active and standby controllers communicate with the IO module through the A/B redundant bus, but only the active controller sends the query data and control messages to the IO module alternately through the A/B redundant bus, and the standby controller passes the A/B redundancy. The bus monitors the response data of the IO module to determine the continuity of the link. After the standby controller is upgraded to the active controller, the original active controller no longer sends query data and control packets, and the newly-based controller sends query data and control packets. The system structure is shown as in Fig. 1, wherein the IO module can be analog input (AI), analog output (Analog Output, AO), digital input (DI), digital output (Digital Output, DO) or some other special IO module. A pair of controllers can carry 6 redundant IO buses, and each IO redundant bus can mount 10 IO modules. Therefore, the controller designed in this paper can mount 60 local IO modules.

Protocol Design And Implementation
The real-time and reliability of communication between the controller and the IO module mainly depends on the communication rate of the physical layer and the scheduling strategy of the data link layer. The communication protocol designed in this paper specifies the information exchange mode between the controller and the IO module. This protocol complies with the open system interconnection reference model (OSI/RM) and uses the application layer, data link layer and physical layer. The application layer implements the real-time data or non-real-time data analysis of the IO module, the data link layer implements a cyclic redundancy check (CRC), and the physical layer implements the codec function of the serial port data.

Data Link Layer Protocol
The data link layer is responsible for performing link layer protocol data unit (PDU) interaction between the controller and the IO module on the link. The data link layer defines the protocol data units in details as shown in Fig2.

Application Layer Protocol
The application layer protocol mainly includes 3 parts: 1) The controller groups the query or control message sent to the IO module according to the configuration file of the IO module; 2) Parses the real-time data sent by the IO module, and sends the data to fill in the IO receiving buffer; 3) Group or parse non-real-time packets.
Since the QNX real-time operating system transmits the message delivered to the IO module to the FPGA through DMA, it is required to design the issued message format to ensure the correctness of the data received by the FPGA. The data format defined by ARM to FPGA is shown in Fig 3. The "info" uses 6 bits as the subnet mask. Each bit represents each branch of the 6 buses. For example, 0x1 means sending on the first bus, 0x10 means sending on the fifth bus, and 0x3f means that all the 6 branches will send. The "len_byte" represents total length of the data packet in this frame. The "content" is the data link layer protocol data unit (PDU), but there is no CRC checksum and frame tail flag. These two items will be automatically added by FPGA to reduce the load on the ARM chip.
Because sending data by DMA will lead to DMA interrupts, after the FPGA receives the data, it does not transmit the data to the QNX real-time operating system through DMA, but stores the data in the global data area by means of the circular buffer. This design has two advantages: 1) Reducing the number of DMA interrupts, the QNX real-time operating system does not need to generate an interrupt to process data after the FPGA receives each IO module data; 2) IO modules under 6 buses can be processed uniformly, and the data of the IO module can form a cross-section, which is beneficial to the algorithm page processing.

Software Design
The software program mainly includes: 1) IO module configuration file analysis; 2) Serial port register configuration; 3) Serial port driver configuration; 4) FPGA register configuration; 5) Real-time message transmission; 6) Non-real-time message transmission. After the controller is powered on, the parameter configuration will be set first. After the setting is completed, the FPGA generates a 5ms pulse signal at a fixed period. After the QNX real-time operating system captures this pulse signal, it performs packetization and analysis of real-time and non-real-time messages.

Real-time Message Transmission
After the QNX real-time operating system captures the timing interrupt generated by the FPGA, it first analyzes the message that the FPGA transmits to the application layer through the circular buffer, and fills the real-time acquisition data of the IO module into the memory area of the IO module according to the analysis result. Then the controller groups control or query messages sent to the IO module according to the IO module configuration information. Finally, after scanning 60 IO modules, the formed sent message will be transmitted to the FPGA through DMA. After the FPGA receives the message, it parses it in the format listed in Table 2, and fills in the CRC checksum and frame tail flag at the end of the link protocol data unit (PDU). Please refer to Fig. 4 for the specific flow.

Non-Real Time Message Transmission
Because the FPGA generates 5ms pulse signal at a fixed period to receive and send real-time messages, it is required to consider adding non-real-time messages to these real-time messages, e.g.: time synchronization, IO module memory query, specific IO module upgrade program, etc. These non-realtime messages will not affect transmission of real-time messages. The design scheme of this paper is: If the branch has non-real-time data, a frame of non-real-time message will be added at the end of the realtime message transmission period of this branch. If the branch has no non-real-time data, time slot of this branch will be ignored. With this scheme, conflicts between real-time message transmission and non-real-time message transmission can be effectively resolved. In this figure: T1 represents the time when the QNX real-time operating system parses the data sent by the IO module, T2 represents the packetization time when the QNX real-time operating system issues the query or control packet according to the IO module configuration file, and T3 represents the time When T3 is reached, the FPGA analyzes the delivered data message according to the format in Tab.2, and automatically adds a CRC checksum and a frame tail flag to issue a query or control message. In theory, the communication time can reach a cycle of 5ms, because T1, T2, and T3 do not occupy the bus bandwidth time. If this cycle is a message sent by the A bus, then the next cycle is switched to the B bus to send a message. In this way, switching and sending can not only reduce the communication load of the IO module, but also monitor the status of the A / B bus communication link. However, the disadvantage of this operation is to process the data fed back by the IO module. It needs to wait for 2 query cycles (i.e.:, 10ms). If the A-bus or B-bus communication link is disconnected, it will cause the entire branch query period to double. However, the controller and the IO module are grouped in a panel cabinet, and the controller will alarm when the communication link is disconnected, so this situation can be avoided well.

Conclusion
This paper presents the design and implementation of a high-speed redundant IO bus based on FPGA. The system combines the advantages of the embedded ARM chip and FPGA perfectly, and realizes the development of embedded platform combining FPGA and ARM chip, which improves the real-time performance, reliability and stability of the system. This design can guarantee the real-time concurrent processing of the 6-channel IO module bus, and it does not occupy the processing time of the ARM chip, so it has excellent value and promotion significance.