Multiple acquisition equipment redundancy and load balancing system based on soft bus

Abstract

The present invention relates to a system for redundancy and load balancing of multiple acquisition devices based on a soft bus, including a platform server, a node management server, a message soft bus, and integrated monitoring subsystems in each region, wherein each integrated monitoring subsystem in each region includes a main communication front-end processor and a backup communication front-end processor, and the platform server, the node management server, the main communication front-end processor, and the backup communication front-end processor are all connected through the message soft bus communication; the node management server dynamically manages the main and backup states of all regional communication front-end processors, and the main communication front-end processor allocates all subsystem channels in the region to different communication front-end processors for access according to rules, thereby realizing multi-machine redundancy of the communication front-end processor; during operation, the main communication front-end processor adjusts the subsystem channel allocation in real time according to the load balancing algorithm. Compared with the prior art, the present invention solves the complex communication problem between heterogeneous components of a distributed platform, and at the same time alleviates the problem of excessive data access load of a single acquisition device.

Description

Technical Field

[0001] The present invention relates to the field of rail transit integrated monitoring, and in particular to a system for redundancy and load balancing of multiple acquisition devices based on a soft bus. Background Art

[0002] Modern intelligent rail transit platforms are connected to multiple subsystems, such as automatic train monitoring system (ATS), broadcasting system (PA), passenger information system (PIS), video monitoring system (CCTV), fire system (FAS), and environmental control system (BAS). By analyzing the data of many subsystems and combining them with intelligent operation and maintenance algorithms, auxiliary decision-making is provided for dispatchers, which not only improves the operation and maintenance efficiency, but also provides stronger protection for rail transit, especially unmanned driving safety through the linkage between subsystems in emergency situations. However, these subsystems are scattered throughout the line, the amount of data accessed is huge, and the access methods and communication protocols are also different. They cannot be directly connected to the rail transit platform. This requires the setting of a communication front-end between the subsystem and the rail transit platform to parse the subsystem data into platform-recognizable data.

[0003] When the line scale is small, a communication front-end processor can be set up in the center to access all subsystem data, and to ensure the stable operation of the communication front-end processor, two redundant communication front-end processors are usually set up. However, the general method is to set up a cold standby communication front-end processor. Only when the main communication front-end processor fails will the backup communication front-end processor take over all data access work. Although this method solves the system stability problem, since the cold standby communication front-end processor does not participate in data access work, it causes a waste of resources to a certain extent. In addition, due to the whole machine switching of the communication front-end processor and the data synchronization of the main and backup communication front-end processors, data fluctuations will occur during switching, affecting user use.

[0004] To solve the problem of data fluctuation, some practices are to use two hot-standby communication front-end machines to perform data access at the same time, and the server selectively receives the data uploaded by one of the communication front-end machines. However, this method cannot avoid the waste of resources and also increases the comparison work of the server. At the same time, due to the particularity of some subsystem interfaces, two-way connections cannot be supported, so this method also has certain limitations.

[0005] As the scale of lines increases, the centralized access method can no longer meet the processing needs of big data, so it is necessary to introduce distributed technology. By setting up multiple groups of redundant servers in the center and centralized stations, and sinking the communication front-end to the station, after the station accesses and processes the subsystem data, some data will be uploaded to the station server and the central server as needed, thereby reducing the processing pressure of the communication front-end and server. However, the introduction of distributed architecture has led to a significant increase in the number of communication front-ends and servers. If the traditional API coding communication method is used at this time, the network structure within the entire platform will be extremely complex, which is very unfavorable for platform development and maintenance, and it also creates certain difficulties for the later expansion of the platform. Summary of the invention

[0006] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and to provide a system with redundancy and load balancing of multiple acquisition devices based on a soft bus, which is suitable for the collection of data from external subsystems of a rail transit integrated monitoring platform, solves the complex communication problems between heterogeneous components of a distributed platform, and reduces the problem of excessive data access load on a single acquisition device.

[0007] The purpose of the present invention can be achieved by the following technical solutions:

[0008] A system for redundancy and load balancing of multiple acquisition devices based on a soft bus, comprising a platform server, a node management server, a message soft bus and integrated monitoring subsystems in each area, wherein each integrated monitoring subsystem in each area comprises a main communication front-end processor and a backup communication front-end processor, and the platform server, the node management server, the main communication front-end processor and the backup communication front-end processor are all connected through the message soft bus communication;

[0009] The node management server dynamically manages the master-slave status of all regional communication front-end machines. The master communication front-end machine allocates all subsystem channels in the region to different communication front-end machines for access according to the rules, thereby realizing multi-machine redundancy of the communication front-end machine. During operation, the master communication front-end machine adjusts the subsystem channel allocation in real time according to the load balancing algorithm.

[0010] Preferably, the message soft bus is a decentralized message soft bus based on a publish or subscribe system.

[0011] Preferably, the system configures all devices accessing the platform to communicate using a message soft bus, and sets the message soft bus to strictly reliable transmission.

[0012] Preferably, the communication front-end processor provides data collection and command forwarding services through a message soft bus, the node management server provides full-line communication front-end processor master and standby status management services through a message soft bus, the platform server subscribes to communication front-end processor data through a message soft bus, and sends control commands to master communication front-end processors in different regions in combination with the communication front-end processor master and standby status information provided by the node management service.

[0013] Preferably, the node management server dynamically manages the active and standby states of all regional communication front-end processors. The specific process is as follows:

[0014] 1) When the communication front-end is started, it first registers its local information with the node management server;

[0015] 2) The node management server monitors the online status of the communication front-end processors in each region in real time. When the communication front-end processor in a certain region triggers a soft bus offline event, it re-elects the main communication front-end processor for the region according to the rules and publishes the election results immediately through the soft bus;

[0016] 3) When the node management server fails to start or run, the communication front-end registration will fail. If the communication front-end does not receive the response data containing the node status within the specified time t after issuing the registration message, it will re-initiate the registration until the registration is successful.

[0017] Preferably, the specific process of the communication front-end registering the local information with the node management server is as follows:

[0018] a) The communication front-end publishes the local area number, device number, and device status to the node management server;

[0019] b) The node management server groups the communication front-end processors according to the area number, and sets the active and standby status of the communication front-end processors according to the information of the communication front-end processors in the group;

[0020] c) If there is no communication front-end processor registered in the current group, or there is no online communication front-end processor, the communication front-end processor is set as the main communication front-end processor;

[0021] d) If a communication front end processor has been registered in the current group and there is a primary communication front end processor, the communication front end processor is set as a backup communication front end processor;

[0022] e) If a communication front-end has been registered in the current group, but there is no master communication front-end, the master communication front-end is selected according to the rules:

[0023] f) After successful registration, the node management server immediately returns the status information of all communication front-end processors in the area to the communication front-end processor, and adds the status of the communication front-end processor to the status information of the entire line communication front-end processors released periodically thereafter.

[0024] Preferably, the election rules in e) are:

[0025] First, the device status is compared, and the communication front-end processor with the best device status is selected as the main communication front-end processor;

[0026] Assume that the network status is NS, the single network online value is 0, the dual network online value is 1, the CPU usage is Ucpu, and the memory usage is Umem. The device status priority calculation formula is as follows:

[0027] 0.5×NS+0.3×(1-Ucpu)+0.2×(1-Umem)

[0028] If the device status priorities of all communication front-end processors are the same, the device numbers of the communication front-end processors are compared again, and the communication front-end processor with a larger device number is preferentially selected as the main communication front-end processor.

[0029] Preferably, the message soft bus configures the communication front-end processor FEP data publishing and subscription rules as follows:

[0030] FEP data is divided into four categories, namely system data S, business data D, control command C and command return R, where S is FEP status information, including equipment operation status, software operation status, system alarm and channel status, D is subsystem data parsed by FEP, C is FEP control command or subsystem control command, R is FEP control command return or subsystem control command return. Among the four types of data, S, D and R are actively released by FEP, and C is subscribed by FEP.

[0031] Each type of data is published and subscribed using a different soft bus topic, and the topic parameters are modified through the configuration library, including domain, partition, topic name, and content filtering conditions.

[0032] Preferably, the soft bus topics corresponding to the four types of data are combined into soft bus routes, and the FEP and different platform servers use the same or different topics to realize data publishing and subscription according to the soft bus routing configuration, and the FEP provides differentiated data collection services for different modules of the platform through the soft bus routing table.

[0033] Preferably, the soft bus routing table is configured as follows:

[0034] {ROUTE_1(T S ,T D ,T C ,T R ),…,ROUTE_N(T S ,T D ,T C ,T R )}

[0035] T S Represents the system data subject, T D Indicates the subject of business data, T C Indicates the control command subject, T R Indicates the command back to school theme.

[0036] Preferably, the system data S is periodically published data, wherein the device operation status, software operation status and channel status are all configured with a publishing cycle through a configuration library, and the system alarm is published at the fastest speed using a change trigger method. For different soft bus routes, the same system data topic can be configured.

[0037] Preferably, the business data D is divided into three categories, namely digital data, analog data and cumulative data. Each category of data corresponds to a data forwarding table. The mapping relationship between data and soft bus routing is configured in the data forwarding table. When the data in the data forwarding table changes, FEP uses the business data topic corresponding to the soft bus routing to publish the changed data to the corresponding platform server based on the mapping relationship between data and soft bus routing.

[0038] Preferably, the control command C can only be subscribed by the master FEP, and forwarded by the master FEP to the FEP where the main channel is located according to the channel distribution;

[0039] When each platform server issues a control command to the FEP, it first obtains the master FEP information of the corresponding area from the node management server and appends the master FEP number to the control command. Since the FEP sets a number-based content filtering condition when subscribing to the control command, that is, it only receives control commands in which the FEP number in the control command is the local number, the control command will only be subscribed by the master FEP.

[0040] Preferably, the command return R is issued in a change-triggered manner and is directly issued by the FEP that executes the control command or the FEP that receives the subsystem command return.

[0041] Preferably, the subsystem to which the communication front-end processor FEP is connected is virtualized as an RTU channel, and the RTU channel will serve as the minimum unit for channel redundancy and load balancing;

[0042] According to the subsystem characteristics and load balancing rules, the redundancy mode of each RTU is configured, including failover and load balancing. Failover means that the RTU is switched only when the link or service is unavailable, while load balancing means that the RTU can be switched dynamically according to the load balancing results.

[0043] Preferably, the main communication front-end processor adjusts the subsystem channel allocation in real time according to the load balancing algorithm as follows:

[0044] (1) After the FEP is elected as the master FEP, it first determines whether the RTU channel is allocated. If not, it evenly allocates the RTU channel to each FEP based on the RTU configuration and the current online FEP information;

[0045] (2) Each FEP creates corresponding services based on the RTU channel allocated to it, including collection service, forwarding service, and synchronization service;

[0046] (3) The standby FEP publishes the local device status information and RTU channel status information to the active FEP in real time. The active FEP calculates whether the RTU channel needs to be switched according to the load balancing rules.

[0047] (4) When load balancing switching occurs on the RTU channel, the active FEP will immediately publish the load-balanced RTU channel allocation results to other standby FEPs. If no channel switching occurs, the RTU channel information will be published periodically.

[0048] Preferably, the allocation rule of the RTU channels in (1) is:

[0049] a) If N rtu <=N fep , the RTUs are assigned to the FEPs in ascending order of RTU and FEP numbers;

[0050] b) If N rtu >N fep , then the number of RTUs allocated to each FEP is According to the RTU and FEP numbers from small to large, the RTU groups are assigned to the FEPs.

[0051] The number of RTUs is N rtu , the number of FEPs is N fep , FEP number is i, where i = 0, 1, 2..., Indicates rounding down.

[0052] Preferably, the acquisition service in (2) loads the corresponding device driver and acquisition protocol according to the RTU configuration to establish communication with the subsystem; the forwarding service publishes business data in real time according to the forwarding table, and the synchronization service synchronizes the RTU channel data to the FEP where other redundant RTU channels are located in real time.

[0053] Preferably, the load balancing rule in (3) is specifically:

[0054] A) If a FEP RTU channel is not in operation and the duration exceeds T offline, then select the current optimal FEP from other FEPs and switch the RTU channel to the optimal FEP. The selection of the optimal FEP is determined by the CPU usage U of the FEP. cpu 、Memory usage U mem and network status NS, the specific calculation formula is:

[0055] 0.5×NS+0.3×(1-U cpu )+0.2×(1-U mem )

[0056] The FEP with the largest calculation result is the optimal FEP. If multiple FEPs have the same calculation results, the FEP with the largest number is taken as the optimal FEP.

[0057] B) Let the CPU usage and memory usage of FEP be U. If U is greater than the set value U max , and the duration exceeds T overload , some RTU channels under this FEP need to be allocated to other FEPs.

[0058] Preferably, the allocation rules in B) are as follows:

[0059] B1) All RTU channels configured as load balancing under the FEP are allocated according to the channel-related usage rate U rtu Sort from small to large;

[0060] B2) Read U in sequence rtu , and select the current relevant usage U best Lowest FEP;

[0061] B3) If U rtu +U best max , the corresponding RTU channel is switched to the FEP with the lowest utilization rate, and U = UU rtu , U best =U best +U rtu ;

[0062] B4) If U rtu +U best >U max , jump out of the allocation process;

[0063] B5) If UU rtu >U max , repeat step B2, otherwise exit the allocation process.

[0064] Compared with the prior art, the present invention has the following advantages:

[0065] ​1) The data is distributed in an undifferentiated manner by connecting all FEPs to a decentralized message bus based on a publish / subscribe system;

[0066] 2) FEP multi-machine redundancy is realized, and a node management server is set up to dynamically manage the master and backup status of FEPs in all areas of the line; the master FEP allocates all subsystem channels in the area to different FEPs for access according to the rules;

[0067] 3) The performance of FEP equipment is fully utilized, while the stability of subsystem data access is also guaranteed. During operation, the main FEP adjusts the subsystem channel allocation in real time according to the load balancing algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] Figure 1 A network architecture diagram of multiple redundant acquisition devices according to the present invention;

[0069] Figure 2 This is a diagram of the main functional modules of the acquisition device described in the present invention;

[0070] Figure 3 This is the control command data flow diagram of the present invention. DETAILED DESCRIPTION

[0071] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0072] The present invention is a system suitable for multi-machine redundancy and load balancing of communication front-end machines in the field of rail transit, and proposes a communication method using a soft bus to adapt to the distributed architecture of a modern intelligent rail transit platform. The specific solution is:

[0073] 1. Configure the platform device to use the message soft bus communication

[0074] Configure all devices connected to the platform to communicate using the message bus, and set the message bus QoS to strict reliable transmission. FEP provides data collection and command forwarding services through the message bus, and the node management server provides full-line FEP master and standby status management services through the message bus. Other modules of the platform subscribe to FEP data through the message bus, and send control commands to the master FEP in different areas in combination with the FEP master and standby status information provided by the node management service.

[0075] 2. Configure the node management server to manage the active and standby status of all FEPs

[0076] When FEP starts, it first registers the local information with the node management server, including the following steps:

[0077] a) FEP publishes the local area number, device number, and device status to the node management server;

[0078] b) The node management server groups the FEPs according to the area number and sets the FEP master / slave status according to the FEP information in the group;

[0079] c) If there is no FEP registered in the current group, or there is no online FEP, set the FEP as the master FEP;

[0080] d) If there is a registered FEP in the current group and there is a primary FEP, set the FEP as a backup FEP;

[0081] e) If there is a registered FEP in the current group, but there is no master FEP, the master FEP is selected according to the rules. The election rules are as follows:

[0082] First, the device status is compared, and the FEP with the best device status is selected as the primary FEP. Assume that the network status is NS, the single network online value is 0, the dual network online value is 1, and the CPU usage is U cpu , the memory usage is U mem , then the device status priority calculation formula is as follows:

[0083] 0.5*NS+0.3*(1-U cpu )+0.2*(1-U mem )

[0084] If the device status priorities of all FEPs are the same, the FEP device numbers are compared again, and the FEP with the larger device number is selected as the master FEP.

[0085] f) After successful registration, the node management server immediately returns the status information of all FEPs in the area to the FEP, and adds the FEP status to the full-line FEP status information released periodically thereafter.

[0086] The node management server monitors the online status of FEPs in each area in real time. When a FEP in a certain area triggers a soft bus offline event, it re-elects a master FEP for the area according to the rules in step e and publishes the election result immediately through the soft bus.

[0087] When the node management server fails to start or run, the FEP registration will fail. If the FEP does not receive the response data containing the node status within the specified time t after issuing the registration message, it will re-initiate the registration until the registration is successful.

[0088] 3. Configure FEP data publishing and subscription rules

[0089] FEP data is divided into four categories, namely system data S, business data D, control command C and command return R, where S is FEP status information, including equipment operation status, software operation status, system alarm and channel status, D is subsystem data after FEP parsing, C is FEP control command or subsystem control command, R is FEP control command return or subsystem control command return. Among the four types of data, S, D and R are actively released by FEP, and C is subscribed by FEP.

[0090] To avoid mutual impact between data and ensure the efficiency of data publishing and subscription, each type of data uses different soft bus topics for publishing and subscription, and the topic parameters can be modified through the configuration library, including domain, partition, topic name and content filtering conditions.

[0091] The four topics are combined into a soft bus route. FEP and different modules of the platform use the same or different topics to publish and subscribe data according to the soft bus route configuration. FEP provides differentiated data collection services for different modules of the platform through the soft bus route table. The soft bus route table configuration is as follows:

[0092] {ROUTE_1(T S ,T D ,T C ,T R ),…,ROUTE_N(T S ,T D ,T C ,T R )}

[0093] System data S is generally periodically released data, among which the device operation status, software operation status and channel status can be configured with a release cycle through the configuration library, while system alarms are released at the fastest speed using change triggers. For different soft bus routes, the same system data topic can be configured to reduce the FEP release pressure.

[0094] Business data D can be divided into three categories: digital data, analog data and cumulative data. Each type of data corresponds to a data forwarding table. The mapping relationship between data and soft bus routing is configured in the forwarding table. When the data in the forwarding table changes, FEP uses the business data topic corresponding to the soft bus routing to publish the changed data to the corresponding module of the platform based on the mapping relationship between data and soft bus routing.

[0095] Control command C can only be subscribed by the master FEP, and forwarded by the master FEP to the FEP where the master channel is located according to the channel distribution, so as to avoid the security problem of repeated issuance of control commands when dual masters and dual channels appear. When each module of the platform issues a control command to the FEP, it first obtains the master FEP information of the corresponding area from the node management server, and adds the master FEP number to the control command. Since the FEP sets a content filtering condition based on the number when subscribing to the control command, that is, it only receives control commands in which the FEP number in the control command is the local number, the control command will only be subscribed by the master FEP.

[0096] The command return R is issued in a change-triggered manner and is directly issued by the FEP that executes the control command or the FEP that receives the subsystem command return, and is no longer forwarded through the master FEP.

[0097] 4. Channel redundancy and load balancing rules

[0098] The subsystem to which the FEP is connected is represented by a virtual RTU channel, which will be the smallest unit of channel redundancy and load balancing. Based on the subsystem characteristics and load balancing rules, the redundancy mode of each RTU is configured, including failover and load balancing. Failover means that the RTU is switched only when the link or service is unavailable, while load balancing means that the RTU can be switched dynamically according to the load balancing results.

[0099] After the FEP is elected as the master FEP, it first determines whether the RTU channel is allocated. If not, it evenly allocates the RTU channel to each FEP based on the RTU configuration and the current online FEP information. Suppose the number of RTUs is N. rtu , the number of FEPs is N fep , FEP number is i (i = 0, 1, 2...), the allocation rule is:

[0100] a) If N rtu <=N fep , the RTUs are assigned to the FEPs in ascending order of RTU and FEP numbers;

[0101] b) If N rtu >N fep , then the number of RTUs allocated to each FEP is Allocate RTU groups to FEPs in ascending order of RTU and FEP numbers;

[0102] Each FEP creates corresponding services according to the RTU channels assigned to it, including collection services, forwarding services, and synchronization services. The collection service loads the corresponding device driver and collection protocol according to the RTU configuration to establish communication with the subsystem; the forwarding service publishes business data in real time according to the forwarding table, and the synchronization service synchronizes the RTU channel data to the FEPs where other redundant RTU channels are located in real time.

[0103] The standby FEP publishes the local device status information and RTU channel status information to the active FEP in real time. The active FEP calculates whether the RTU channel needs to be switched according to the load balancing rules. The load balancing rules are as follows:

[0104] a) If a FEP RTU channel is not in operation state and the duration exceeds T offline , then select the current optimal FEP from other FEPs and switch the RTU channel to the optimal FEP. The selection of the optimal FEP is determined by the CPU usage U of the FEP. cpu 、Memory usage U mem and network status NS, the specific calculation formula is:

[0105] 0.5*NS+0.3*(1-U cpu )+0.2*(1-U mem )

[0106] The FEP with the largest calculation result is the optimal FEP. If multiple FEPs have the same calculation results, the FEP with the largest number is taken as the optimal FEP.

[0107] b) Let the CPU usage and memory usage of FEP be U. If U is greater than the set value U max , and the duration exceeds T overload , some RTU channels under the FEP need to be allocated to other FEPs. The allocation rules are as follows:

[0108] 1. All RTU channels configured for load balancing under the FEP are allocated according to the channel-related usage rate U rtu Sort from small to large;

[0109] 2. Read U in sequence rtu , and select the current relevant usage U best Lowest FEP;

[0110] 3.If U rtu +U best max , the corresponding RTU channel is switched to the FEP with the lowest utilization rate, and U = UU rtu , U best =U best +U rtu ;​

[0111] 4.If U rtu +U best >U max , jump out of the allocation process;

[0112] 5. If UU rtu >U max , repeat step 2, otherwise jump out of the allocation process.

[0113] When load balancing switching occurs on the RTU channel, the active FEP will immediately publish the load-balanced RTU channel allocation result to other standby FEPs. If no channel switching occurs, the RTU channel information will be published periodically. Specific embodiments

[0115] Figure 1 This is a network structure diagram of the multiple redundant acquisition devices described in the present invention. Multiple FEPs are configured in each area. Soft bus communication is adopted between FEP and platform module. The communication protocol adopts the soft bus IDL+PROTOBUF custom format. FEP communicates with subsystems through Ethernet or serial port. The communication protocol uses IEC-60870-5-104, Modbus TCP or custom protocol.

[0116] In this embodiment, an area number and serial number are configured for each FEP, and the subsystems that need to be connected to each area are represented by RTU channels. For example, the power supply subsystem PSCADA is represented as RTU 1, the fire subsystem FAS is represented as RTU 2, and the environmental control subsystem BAS is represented as RTU 3.

[0117] Configure the interface mode and communication protocol of each RTU channel, and select the redundancy mode for each RTU channel. For subsystems that do not require frequent switching, such as the PSCADA subsystem, set the redundancy mode to the fault switching mode. For subsystems with large data volumes and low security levels, such as the FAS / BAS subsystem, set the redundancy mode to load balancing.

[0118] Configure the FEP soft bus routing table, including the system data topics, business data topics, control command topics and command return topics for FEP to communicate with each module of the platform, and configure the domain, partition, topic name and content filtering conditions of each topic. For example, in this embodiment, FEP can configure three soft bus routes to provide data services for the station server, the central PSCADA server and the central environmental control server respectively.

[0119] Configure the FEP data transfer table, including the digital transfer table, analog transfer table and cumulative transfer table. The transfer table contains the mapping relationship between RTU data and soft bus routes. For example, all PSCADA subsystem data is mapped with the station server soft bus route, and some important PSCADA data is mapped with the central PSCADA server soft bus route. When the PSCADA data changes, FEP uses one or more business topics to publish data according to the mapping relationship between the data and the soft bus route, thereby providing differentiated data services for different modules.

[0120] like Figure 2 The main functional modules of the FEP of the present invention are shown, including a node management module, a forwarding module, a synchronization module and a collection module. After the FEP is started, all RTU channels are first set to a standby state. At the same time, the node management module registers the local information with the node management server through the soft bus, including the following registration steps:

[0121] a) Use the node registration topic to publish the local node information, including the region number, device number and device status, and wait for the node management server to respond;

[0122] b) If no response data containing the node status is received within time t, repeat step a;

[0123] c) If the response data containing the node status of the local machine is received within time t, it indicates that the node registration is successful. At this time, the active / standby status of the local machine is set according to the received status data.

[0124] If a FEP is elected as the master FEP, it first determines whether all current RTU channels have been allocated. If not, it allocates RTU channels to each FEP based on the RTU channel configuration and the current online FEP information. The allocation result is published to all standby FEPs through the soft bus. If the RTU channel has been allocated, it directly enters the load balancing calculation cycle.

[0125] If an FEP is elected as a standby FEP, it will subscribe to the RTU channel allocation results published by the main FEP directly through the soft bus, and publish the local status information and RTU channel status information to the main FEP through the soft bus in real time. The main FEP will perform load balancing calculations based on all the data, including the following calculation steps:

[0126] a) First check the RTU link status assigned to each FEP. If the link is not established and exceeds the specified time, reallocate the RTU channel.

[0127] b) Secondly, check the performance usage of each FEP. When it is found that the FEP performance is overloaded, combine the RTU channel performance usage of the FEP and reallocate some of the RTU channels to other FEPs with the best performance.

[0128] After successful registration, the node management module subscribes to the active and standby status information of all FEPs in the area published by the node management server in real time. When the active and standby status of the local device is found to have changed, it actively switches to the corresponding status.

[0129] When the FEP exits normally, the node management module will initiate the exit process, which includes the following two situations:

[0130] a) If the local FEP is the master FEP, first reassign all the local RTU channels to other FEPs in the area, and then publish the local deregistration information through the node registration topic. After receiving the FEP deregistration information, the node management server sets the FEP to offline state and reselects the master FEP for the area;

[0131] c) If the local FEP is a backup FEP, the node registration topic is used to publish the local deregistration information. After the main FEP receives the FEP deregistration information, it reallocates the RTU channel on the FEP to other FEPs in the area; after the node management server receives the FEP deregistration information, it sets the FEP to offline state.

[0132] When FEP exits abnormally, the exit process includes the following two situations:

[0133] a) If the local machine is the master FEP, after the node management server detects the FEP offline event, it sets the FEP to offline state and reselects the master FEP for the area. The master FEP reallocates the RTU channel on the offline FEP to other FEPs in the area based on the FEP status information published by the node management server;

[0134] b) If the local FEP is a backup FEP, the node management server will set the FEP to offline state after detecting the FEP offline event. The active FEP will reallocate the RTU channel on the offline FEP to other FEPs in the area based on the FEP status information released by the node management server;

[0135] The FEP starts the following services according to the RTU channel assigned to it:

[0136] 1. Start the data collection service of the corresponding channel. The main functions of the collection service include:

[0137] a) Create a communication link with the subsystem according to the channel interface configuration, and load the corresponding communication protocol library according to the channel protocol configuration;

[0138] c) Receive and parse subsystem data and write the data into the FEP real-time library;

[0139] d) Parse the platform control commands, package them according to the communication protocol structure, and forward them to the subsystem.

[0140] 2. Start the data forwarding service of the corresponding channel. The forwarding service includes the following functions:

[0141] a) Publish the local device operation status, software operation status, channel status, and system alarms in real time through the system data topic;

[0142] b) Check in real time whether the corresponding channel data in the forwarding table has changed. When the data changes, use the corresponding business data topic to publish the changed data according to the mapping relationship between the data and the soft bus route;

[0143] c) Subscribe to the control commands of each module of the platform through the control command topic;

[0144] like Figure 3 As shown, when subscribing to control commands, FEP sets a content filtering condition based on the FEP number, that is, only receives control commands in which the FEP number in the control command is the local number. When each module of the platform issues a control command, the master FEP number is attached to the control command based on the master-slave status information of each area FEP issued by the node management server. Therefore, the control command will only be received by the master FEP of the corresponding area.

[0145] After receiving the control command, the main FEP forwarding module first checks whether the RTU channel corresponding to the control command is allocated to the local machine. If so, it is directly forwarded to the corresponding subsystem by the local acquisition module. If not, the FEP where the RTU channel is located is queried according to the RTU channel allocation table, and then the FEP number in the control command is modified to the FEP number where the RTU channel is located, and the control command is reissued through the control command topic, thereby realizing one-to-one sending of control commands and avoiding control security issues when FEP has dual masters or dual channels.

[0146] d) Publish the subsystem command to return to school in real time through the command to return to school topic.

[0147] 3. Start the data synchronization service of the corresponding channel. The synchronization service checks in real time whether the data of the corresponding RTU channel in the local real-time library has changed. When the data changes, the changed data is published through the data synchronization topic, and the FEP of other redundant RTU channels subscribes to the data through the data synchronization topic to achieve data synchronization between redundant RTU channels.

[0148] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus, characterized in that: It includes a platform server, a node management server, a message soft bus and integrated monitoring subsystems in each area, wherein each integrated monitoring subsystem in each area includes a main communication front-end processor and a backup communication front-end processor, and the platform server, the node management server, the main communication front-end processor and the backup communication front-end processor are all connected through the message soft bus communication; The node management server dynamically manages the master and standby status of all regional communication front-end processors. The master communication front-end processor allocates all subsystem channels in the region to different communication front-end processors according to the rules, thus realizing multi-machine redundancy of the communication front-end processors. During operation, the master communication front-end processor adjusts the subsystem channel allocation in real time according to the load balancing algorithm. The specific process of the node management server dynamically managing the active and standby status of all regional communication front-end machines is as follows: 1) When the communication front-end is started, it first registers its local information with the node management server; 2) The node management server monitors the online status of the communication front-end processors in each region in real time. When the communication front-end processor in a certain region triggers a soft bus offline event, it re-elects the main communication front-end processor for the region according to the rules and publishes the election results immediately through the soft bus; 3) When the node management server fails to start or run, the communication front-end registration will fail. If the communication front-end does not receive the response data containing the node status within the specified time t after issuing the registration message, it will re-initiate the registration until the registration is successful; The specific process of the communication front-end registering the local information with the node management server is as follows: a) The communication front-end publishes the local area number, device number, and device status to the node management server; b) The node management server groups the communication front-end processors according to the area number, and sets the active and standby status of the communication front-end processors according to the information of the communication front-end processors in the group; c) If there is no communication front-end processor registered in the current group, or there is no online communication front-end processor, the communication front-end processor is set as the main communication front-end processor; d) If a communication front end processor has been registered in the current group and there is a primary communication front end processor, the communication front end processor is set as a backup communication front end processor; e) If a communication front-end has been registered in the current group, but there is no master communication front-end, the master communication front-end is selected according to the rules: f) After successful registration, the node management server immediately returns the status information of all communication front-end processors in the area to the communication front-end processor, and adds the status of the communication front-end processor to the status information of the entire line communication front-end processors released periodically thereafter; The election rules in e) are: First, the device status is compared, and the communication front-end processor with the best device status is selected as the main communication front-end processor; Assume that the network status is NS, the single network online value is 0, the dual network online value is 1, the CPU usage is Ucpu, and the memory usage is Umem. The device status priority calculation formula is as follows: 0.5×NS+0.3×(1-Ucpu)+0.2×(1-Umem) If the device status priorities of all communication front-end processors are the same, the device numbers of the communication front-end processors are compared again, and the communication front-end processor with a larger device number is preferentially selected as the main communication front-end processor.

2. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 1, characterized in that: The message soft bus is a decentralized message soft bus based on a publish or subscribe system.

3. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 1, characterized in that: The system configures all devices connected to the platform to use message soft bus communication and sets the message soft bus for strict reliable transmission.

4. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 1 or 3, characterized in that: The communication front-end processor provides data collection and command forwarding services through the message soft bus, the node management server provides the master-slave status management service of the entire line of communication front-end processors through the message soft bus, and the platform server subscribes to the communication front-end processor data through the message soft bus, and sends control commands to the main communication front-end processors in different regions in combination with the master-slave status information of the communication front-end processors provided by the node management service.

5. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 1, characterized in that: The message soft bus configuration communication front-end processor FEP data publishing and subscription rules are specifically as follows: FEP data is divided into four categories, namely system data S, business data D, control command C and command return R, where S is FEP status information, including equipment operation status, software operation status, system alarm and channel status, D is subsystem data parsed by FEP, C is FEP control command or subsystem control command, R is FEP control command return or subsystem control command return. Among the four types of data, S, D and R are actively released by FEP, and C is subscribed by FEP. Each type of data is published and subscribed using a different soft bus topic, and the topic parameters are modified through the configuration library, including domain, partition, topic name, and content filtering conditions.

6. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 5, characterized in that: The soft bus topics corresponding to the four types of data are combined into soft bus routes. FEP and different platform servers use the same or different topics to publish and subscribe data according to the soft bus route configuration. FEP provides differentiated data collection services for different modules of the platform through the soft bus routing table.

7. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 6, characterized in that: The soft bus routing table configuration is as follows: {ROUTE_1(T S ,T D ,T C ,T R ),…,ROUTE_N(T S ,T D ,T C ,T R )} T S Represents the system data subject, T D Indicates the subject of business data, T C Indicates the control command subject, T R Indicates the command back to school theme.

8. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 7, characterized in that: The system data S is periodically published data, in which the device operation status, software operation status and channel status are all configured with a publishing cycle through the configuration library, and the system alarm is published at the fastest speed using a change trigger. For different soft bus routes, the same system data topic can be configured.

9. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 7, characterized in that: The business data D is divided into three categories, namely digital data, analog data and cumulative data. Each type of data corresponds to a data forwarding table. The mapping relationship between data and soft bus routing is configured in the data forwarding table. When the data in the data forwarding table changes, FEP uses the business data topic corresponding to the soft bus routing to publish the changed data to the corresponding platform server based on the mapping relationship between data and soft bus routing.

10. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 7, characterized in that: The control command C can only be subscribed by the master FEP, and forwarded by the master FEP to the FEP where the main channel is located according to the channel distribution; When each platform server issues a control command to the FEP, it first obtains the master FEP information of the corresponding area from the node management server and appends the master FEP number to the control command. Since the FEP sets a number-based content filtering condition when subscribing to the control command, that is, it only receives control commands in which the FEP number in the control command is the local number, the control command will only be subscribed by the master FEP.

11. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 7, characterized in that: The command return R is issued in a change-triggered manner and is directly issued by the FEP that executes the control command or the FEP that receives the subsystem command return.

12. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 1, characterized in that: The subsystem to which the communication front-end processor FEP is connected is virtualized as an RTU channel, which will serve as the minimum unit for channel redundancy and load balancing. According to the subsystem characteristics and load balancing rules, the redundancy mode of each RTU is configured, including failover and load balancing. Failover means that the RTU is switched only when the link or service is unavailable, while load balancing means that the RTU can be switched dynamically according to the load balancing results.

13. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 12, characterized in that: The main communication front-end processor adjusts the subsystem channel allocation in real time according to the load balancing algorithm as follows: (1) After an FEP is elected as the master FEP, it first determines whether the RTU channels are allocated. If not, it evenly allocates the RTU channels to each FEP based on the RTU configuration and the current online FEP information. (2) Each FEP creates corresponding services based on the RTU channel allocated to it, including collection service, forwarding service, and synchronization service; (3) The standby FEP publishes the local device status information and RTU channel status information to the active FEP in real time. The active FEP calculates whether the RTU channel needs to be switched according to the load balancing rules. (4) When load balancing switching occurs on the RTU channel, the active FEP will immediately publish the load-balanced RTU channel allocation results to other standby FEPs. If no channel switching occurs, the RTU channel information will be published periodically.

14. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 13, characterized in that: The allocation rule of the RTU channels in (1) is: a) If N rtu <=N fep , the RTUs are assigned to the FEPs in ascending order of RTU and FEP numbers; b) If N rtu >N fep , then the number of RTUs allocated to each FEP is According to the RTU and FEP numbers from small to large, the RTU groups are assigned to the FEPs. The number of RTUs is N rtu , the number of FEPs is N fep , FEP number is i, where i = 0, 1, 2..., Indicates rounding down.

15. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 13, characterized in that: The acquisition service in (2) loads the corresponding device driver and acquisition protocol according to the RTU configuration to establish communication with the subsystem; the forwarding service publishes business data in real time according to the forwarding table, and the synchronization service synchronizes the RTU channel data to the FEP where other redundant RTU channels are located in real time.

16. The system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 13, characterized in that: The load balancing rules in (3) are specifically as follows: A) If a FEP RTU channel is not in operation and the duration exceeds T offline , then select the current optimal FEP from other FEPs and switch the RTU channel to the optimal FEP. The selection of the optimal FEP is determined by the CPU usage U of the FEP. cpu 、Memory usage U mem and network status NS, the specific calculation formula is: 0.5×NS+0.3×(1-U cpu )+0.2×(1-U mem ) The FEP with the largest calculation result is the optimal FEP. If multiple FEPs have the same calculation results, the FEP with the largest number is taken as the optimal FEP. B) Let the CPU usage and memory usage of FEP be U. If U is greater than the set value U max , and the duration exceeds T overload , some RTU channels under this FEP need to be allocated to other FEPs.

17. A system for redundancy and load balancing of multiple acquisition devices based on a soft bus according to claim 16, characterized in that: The allocation rules in B) are as follows: B1) All RTU channels configured as load balancing under the FEP are allocated according to the channel-related usage rate U rtu Sort from small to large; B2) Read U in sequence rtu , and select the current relevant usage U best Lowest FEP; B3) If U rtu +U best max , the corresponding RTU channel is switched to the FEP with the lowest utilization rate, and U = UU rtu , U best =U best +U rtu ;​ B4) If U rtu +U best >U max , jump out of the allocation process; B5) If UU rtu >U max , repeat step B2, otherwise exit the allocation process.

Images