Train converged domain controller and its redundancy design method, rail vehicles

Abstract

This application provides a train fusion domain controller and its redundancy design method, as well as a rail vehicle. The method includes: configuring two multi-core heterogeneous CPU cards for a preset fusion domain controller, with the two CPU cards operating in a master-slave hot redundancy mode; the controller has a backplane with at least two independent physical bus channels; when the master CPU card outputs control commands to a slave board connected to the backplane, and the master CPU card loses its heartbeat or malfunctions, the slave CPU card is upgraded to a new master CPU card; when the CPU card and the extended slave board use multiple buses for parallel transmission and reception, the application layer communicates data through a predefined master bus channel; the status of the master bus channel is monitored in real time, and if the master bus channel fails, the main path is switched to the backup bus channel; application data is synchronized between the master CPU card and the slave CPU card in real time, which can solve the problem of not supporting multiple redundancy switching and improve the reliability of the train domain controller.

Description

Technical Field

[0001] This application relates to the field of train domain controller technology, specifically to a train fusion domain controller and its redundancy design method, and rail vehicles. Background Technology

[0002] Currently, railway production control systems are focusing on researching domain controllers for multi-system integrated control, integrating existing controllers to address issues such as complex software interfaces and redundant hard-wired data acquisition. Because train domain controllers integrate more control functions, their reliability becomes particularly important. Currently, trains often use dual controllers for redundant control. Initially, both controllers are powered on and perform logic checks, with only the master controller handling external control. When the master controller fails, the slave controller takes over. However, due to the complexity of vehicle control, certain operating conditions only occur under specific circumstances. When the slave communication control unit recovers after a switchover, it may have missed previous train command collection and process control, leading to inconsistencies in the operating logic between the slave and master communication control units. This results in a loss of the ability to seamlessly switch back to the master communication control unit to take over the train.

[0003] Converged domain controllers, compared to traditional single-system controllers, have a wider control range and a greater impact, making domain control increasingly important in train control. However, existing converged domain controllers suffer from poor fault tolerance due to their single-module architecture, and the risk of overall controller failure due to critical component failures. With the introduction of a time-sensitive network communication architecture, the traditional master-slave switching between two control hosts via external diagnostics is no longer applicable. Summary of the Invention

[0004] To address one of the aforementioned technical deficiencies, this application provides a train fusion domain controller and its redundancy design method, as well as a rail vehicle.

[0005] According to a first aspect of the embodiments of this application, a redundancy design method for a train fusion domain controller is provided, comprising: The pre-configured converged domain controller is equipped with two multi-core heterogeneous CPU cards. The two CPU cards adopt a master-slave hot redundancy working mode and communicate through a heartbeat detection channel set between them. The converged domain controller has a backplane, and the backplane is configured with at least two independent physical bus channels. During the operation of the fused domain controller, the master CPU card and slave CPU card master-slave relationship are determined; the master CPU card outputs control commands to the daughterboard connected to the backplane; the slave CPU card monitors the signal of the heartbeat detection channel, and when the heartbeat of the master CPU card is lost or abnormal, a CPU-level switch is performed, the slave CPU card is upgraded to a new master CPU card and takes over control. When the main CPU card and the slave CPU card simultaneously receive data from the expansion daughter card in parallel through the redundant backplane bus, the application layer communicates data through a predefined main bus channel; the status of the main bus channel is detected in real time, and if a failure is detected in the main bus channel, the main path of data communication is automatically switched to the backup bus channel, and only the main CPU card sends control commands to the expansion daughter board.

[0006] In an optional embodiment of this application, the at least two independent physical bus channels include a first bus channel and a second bus channel, wherein the first bus channel adopts a PCIe bus, and the second bus channel adopts a star Ethernet bus; and the PCIe bus is configured in cold standby mode, and the Ethernet bus is configured in hot standby mode. In an optional embodiment of this application, the method further includes: Within different operating system partitions of the same CPU card, a set of redundant applications with identical control logic but different IP addresses are deployed. The application in one partition is designated as the primary application and enables multicast to issue control commands externally. The application in the other partition is designated as the backup application and its multicast port is blocked. The backup application continuously receives the heartbeat status of the primary application via unicast. When the primary application is determined to be faulty, the backup application opens its multicast port and takes over the external control functions.

[0007] In an optional embodiment of this application, the method further includes: For redundant applications within the same CPU card, a shared memory region that can be read by each pair of applications is allocated to achieve real-time synchronization of control instructions and running status between the two. For applications with the same function but distributed across two different CPU cards, a separate data synchronization network interface is established between the two CPU cards for data communication, thereby achieving consistent synchronization of control status across CPU cards.

[0008] In an optional embodiment of this application, the step of allocating mutually readable shared memory regions to each pair of applications to achieve real-time synchronization of control instructions and running states between them includes: Suppose there are two applications, App A and App B. The system allocates two independent shared memory regions, Mem_A and Mem_B. Mem_A has write permissions granted only to App A and read permissions granted to App B; Mem_B has write permissions granted only to App B and read permissions granted to App A. In an optional embodiment of this application, the data communication via the independent data synchronization network interface established between the two CPU cards includes: On both CPU cards, a physical Ethernet synchronization link established via the main backplane bus is configured for each application with corresponding functionality, dedicated to transmitting control data for state synchronization. A second aspect of this application provides a train fusion domain controller, comprising: A multi-CPU redundancy module includes at least two CPU cards with heterogeneous multi-core processing capabilities. The two CPU cards are directly connected through a dedicated inter-card communication link for performing heartbeat detection and master / slave status switching. The backplane dual-bus module includes two different and independent main bus channels and backup bus channels set on the control backplane, which provide parallel data transmission and reception paths for at least the main CPU card and the slave CPU card. The controller status arbitration module makes comprehensive decisions on the overall master control, the selection of the primary communication bus, and the succession of control over the failed application based on the results of the heartbeat detection, the bus on / off status, and the application running status.

[0009] In an optional embodiment of this application, the train fusion domain controller further includes: The on-card application redundancy module runs two independent operating system partitions on a single CPU card, and deploys applications with the same functional logic but serving as hot backups for each other in different partitions. The two applications synchronize internal data through shared memory and achieve rapid transfer of control through a network unicast / multicast switching mechanism. The inter-card application synchronization module synchronizes control data and status between identical applications located on two separate CPU cards through an independent cross-CPU card synchronization network.

[0010] In one optional embodiment of this application, the primary bus channel is a PCIe bus, and the backup bus channel is a star Ethernet bus.

[0011] According to a third aspect of the embodiments of this application, a rail vehicle is provided, including the aforementioned train fusion domain controller.

[0012] The redundancy design method for the train fusion domain controller provided in this embodiment involves configuring two multi-core heterogeneous CPU cards in a preset fusion domain controller. The two CPU cards operate in a master-slave hot redundancy mode and communicate via a heartbeat detection channel between them. The fusion domain controller includes a backplane with at least two independent physical bus channels. During operation, the master-slave relationship between the master CPU card and the slave CPU card is determined. The master CPU card outputs control commands to the daughterboard connected to the backplane. The slave CPU card monitors the signal of the heartbeat detection channel; when the heartbeat is detected... When the main CPU card heartbeat is lost or abnormal, a CPU-level switch is performed, and the slave CPU card is upgraded to a new main CPU card and takes over control. When the main CPU card and the slave CPU card simultaneously receive data from the extended daughter card in parallel through the redundant backplane bus, the application layer communicates data through a predefined main bus channel. The status of the main bus channel is monitored in real time. If a failure is detected in the main bus channel, the main path of data communication is automatically switched to the backup bus channel. At the same time, only the main CPU card sends control commands to the extended daughter board, which can solve the problem of not supporting multiple redundancy switching and improve the reliability of the train domain controller. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating the redundancy design method for the train fusion domain controller provided in this application embodiment; Figure 2 This is a schematic diagram of a dual-CPU communication architecture for a train fusion domain controller provided in one embodiment of this application; Figure 3 This is a schematic diagram of a train fusion domain controller backplane bus redundancy scheme provided in one embodiment of this application; Figure 4 A schematic diagram of a redundant App solution under different operating systems on a single CPU card according to an embodiment of this application; Figure 5 This is a schematic diagram of a redundant App solution under different operating systems on a single CPU card provided in one embodiment of this application; Figure 6 This is a schematic diagram of a single-CPU card redundant App data synchronization scheme provided in one embodiment of this application; Figure 7 This is a schematic diagram of a dual-CPU card redundant App data synchronization scheme provided in one embodiment of this application; Figure 8 This is a schematic diagram of the train fusion domain controller structure provided in one embodiment of this application; Figure 9 This is a schematic diagram of a computer device structure provided in one embodiment of this application. Detailed Implementation

[0014] To make the technical solutions and advantages of the embodiments of this application clearer, the exemplary embodiments of this application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0015] In the process of developing this application, the inventors discovered that existing fusion domain control systems have poor fault tolerance in their single-module architecture, and the failure of key components can easily lead to the overall failure of the controller.

[0016] To address the aforementioned issues, this application provides a redundancy design method for a train fusion domain controller. The method involves configuring two multi-core heterogeneous CPU cards into a pre-defined fusion domain controller. The fusion domain controller has an internal backplane with at least two independent physical bus channels. This method determines the master / slave relationship between the master and slave CPU cards, enabling real-time application synchronization. This solves the problem of not supporting multiple redundancy switching and improves the reliability of the train domain controller.

[0017] Please see Figure 1 The redundancy design method for the train fusion domain controller provided in this application includes the following steps S100~S400: S100, the preset converged domain controller is configured with two multi-core heterogeneous CPU cards. The two CPU cards adopt a master-slave hot redundancy working mode and communicate through a heartbeat detection channel set between them. The converged domain controller is equipped with a backplane, and the backplane is configured with at least two independent physical bus channels. S200, during the operation of the converged domain controller, determines the master / standby relationship between the master CPU card and the slave CPU card; the master CPU card outputs control commands to the daughterboard connected to the backplane; the slave CPU card monitors the signal of the heartbeat detection channel, and when it detects that the heartbeat of the master CPU card is lost or abnormal, it performs a CPU-level switch, the slave CPU card is upgraded to a new master CPU card, and takes over control. S300, when the main CPU card and the slave CPU card simultaneously receive data from the expansion daughter card in parallel through the redundant backplane bus, the application layer communicates data through a predefined main bus channel; the status of the main bus channel is detected in real time, and if a failure is detected in the main bus channel, the main path of data communication is automatically switched to the backup bus channel, and only the main CPU card sends control commands to the expansion daughter board. In the S400, the master CPU card and slave CPU card synchronize application data in real time. If the master CPU card fails, the slave CPU card seamlessly takes over the master control function. The new master CPU card continues to send application data to the new slave CPU card in real time to achieve synchronization. When the next failure occurs, the master and slave CPU cards can switch over again.

[0018] In an optional embodiment of this application, in step S100, the at least two independent physical bus channels include a first bus channel and a second bus channel. The first bus channel uses a PCIe bus, and the second bus channel uses a star Ethernet bus. Furthermore, the PCIe bus is configured in cold standby mode, and the Ethernet bus is configured in hot standby mode. In an optional embodiment of this application, the dual-CPU card communication architecture of the converged domain controller is as follows: Figure 2 As shown, the two multi-core heterogeneous CPU cards configured in the fusion domain controller process train control data simultaneously, with only one CPU outputting control commands to the daughterboard via the backplane bus manager. Communication between the two CPUs is of two types: direct master-slave communication with heartbeat detection, and hot standby redundancy. For example, when CPU1 is the master, CPU2 listens to CPU1 via fast communication channel 4. If CPU1's heartbeat fails, CPU2 automatically switches to master and executes the control functions. This redundancy switching function primarily involves the CPU controlling and monitoring the daughterboards within its domain controller.

[0019] In an optional embodiment of this application, the converged domain controller internally provides redundancy for two backplane buses. The CPU board in the converged domain controller controls various daughterboards via the backplane buses. The backplane has two buses, A and B, which transmit and receive in parallel, such as... Figure 3 In this configuration, CPUs 1, 2, and 3 use master bus A, while CPUs 5, 6, and 7 use slave bus B. Bus 4 serves as the life signal communication and detection channel between CPU1 and CPU2. Bus A can utilize a PCIe bus for higher real-time performance, while bus B can employ a star-shaped Ethernet bus. The PCIe interfaces of the two CPUs use cold standby redundancy, while the Ethernet bus uses hot standby redundancy. Each bus leverages its advantages: PCIe offers high real-time performance, while Ethernet provides multi-functional integration capabilities (besides serving as the slave bus for the domain control backplane, it also handles Ethernet transmission and reception for applications to external devices via the Ethernet bus manager). Normally, both CPU cards transmit and receive data simultaneously via buses A and B. The application layer defaults to using the higher-priority bus A for transmission and reception control. When a communication failure occurs on bus A, the system automatically switches to bus B for control.

[0020] In an optional embodiment of this application, the method further includes: Within different operating system partitions of the same CPU card, a set of redundant applications with identical control logic but different IP addresses are deployed. The application in one partition is designated as the primary application and enables multicast to issue control commands externally. The application in the other partition is designated as the backup application and its multicast port is blocked. The backup application continuously receives the heartbeat status of the primary application via unicast. When the primary application is determined to be faulty, the backup application opens its multicast port and takes over the external control functions.

[0021] In an optional embodiment of this application, fault migration redundancy is set in different sections of a single CPU card, and two Apps under different operating systems of the same train domain controller are mutually redundant to improve system reliability. For example... Figure 4 App1 and App3 are redundant, running on different operating systems on the same domain controller. When App1 fails, App3 can take over the control functions. The specific implementation method is as follows: Figure 5 As shown, App1's external IP is A, and App3's external IP is B. Both App1 and App3 use multicast for external communication. For example, when App1 is functioning normally, App3 blocks the sending and receiving of external multicast data. App1 and App3 communicate with each other via unicast. When App3 receives abnormal data from App1 via unicast, App3 enables its external multicast function.

[0022] In an optional embodiment of this application, the method further includes: For redundant applications within the same CPU card, a shared memory region that can be read by each pair of applications is allocated to achieve real-time synchronization of control instructions and running status between the two. For applications with the same function but distributed across two different CPU cards, a separate data synchronization network interface is established between the two CPU cards for data communication, thereby achieving consistent synchronization of control status across CPU cards.

[0023] In an optional embodiment of this application, the step of allocating mutually readable shared memory regions to each pair of applications to achieve real-time synchronization of control instructions and running states between them includes: Suppose there are two applications, App A and App B. The system allocates two independent shared memory regions, Mem_A and Mem_B. Mem_A has write permissions granted only to App A and read permissions granted to App B; Mem_B has write permissions granted only to App B and read permissions granted to App A. In an optional embodiment of this application, the data communication via the independent data synchronization network interface established between the two CPU cards includes: On both CPU cards, a physical Ethernet synchronization link established via the main backplane bus is configured for each application with corresponding functionality, dedicated to transmitting control data for state synchronization. In an optional embodiment of this application, during single-CPU card application software data synchronization, different partitions of applications on a single CPU card are redundant, and data synchronization is achieved through shared memory, such as... Figure 6 Applications App1 and App3 are redundant. Since switching between the two apps needs to be seamless, all control commands must be synchronized. For shared memory region 1, App1 has write permissions, and App3 has read permissions. Similarly, for shared memory region 2, App3 has write permissions, and App1 has read permissions. This ensures data synchronization.

[0024] In an optional embodiment of this application, during application software data synchronization between dual CPU cards, the application software data synchronization between dual CPU cards is as follows: Figure 7 The App1 on CPU1 board and the App1 on CPU2 board are redundant. To ensure consistency in domain control, the App1 on the two CPU boards needs to synchronize data. The specific method is as follows: Figure 7 As shown in the diagram, App1 on CPU1 board and App1 on CPU2 board communicate within the domain controller via an Ethernet bus to synchronize data. For external Ethernet communication channels 1 and 2, the primary communication channel is determined by the CPU. For example, in this diagram, when CPU1 is the primary channel, it controls external communication through channel 1. CPU2, as the secondary channel, continuously monitors the status of CPU1. When CPU1 fails, CPU2's external channel 2 replaces bus 1 to control external communication.

[0025] The redundancy design method for the train converged domain controller in this application solves the problems of long master-slave switching time and inapplicability to time-sensitive TSN networks in traditional external communication by using a dual-multi-core heterogeneous CPU card design within the domain controller. The dual backplane bus redundancy scheme of the converged domain controller solves the problem of the entire domain controller failing when a single backplane bus fails. The fault migration redundancy scheme between different partitions of a single CPU card solves the problem of vehicle control failure when a single application of a single CPU card fails, improving the reliability of single CPU card control. The application redundancy switching mechanism between two CPU cards within the same domain controller improves the overall reliability of the domain controller. The data synchronization design of two applications on a single CPU card within the domain controller through shared memory solves the problem of control asynchrony after switching between two redundant applications on a single CPU card. The data synchronization design of two applications on dual CPU cards within the domain controller through a synchronization interface solves the problem of control asynchrony after switching between two redundant applications on dual CPU cards.

[0026] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the diagram may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0027] Please see Figure 8 One embodiment of this application provides a train fusion domain controller 800, including: The multi-CPU redundancy module 810 includes at least two CPU cards with heterogeneous multi-core processing capabilities. The two CPU cards are directly connected through a dedicated inter-card communication link for performing heartbeat detection and master / slave status switching. The backplane dual-bus module 820 includes two different and independent main bus channels and backup bus channels set on the control backplane, providing parallel data transmission and reception paths for at least the main CPU card and the slave CPU card. The controller status arbitration module 830 makes comprehensive decisions on the overall master control, the selection of the primary communication bus, and the succession of control over the failed application based on the heartbeat detection results, bus on / off status, and application running status.

[0028] In an optional embodiment of this application, the train fusion domain controller further includes: The in-card application redundancy module 840 runs two independent operating system partitions on a single CPU card, and deploys applications with the same functional logic but serving as hot backups for each other in different partitions. The two applications synchronize internal data through shared memory and achieve rapid transfer of control through a network unicast / multicast switching mechanism.

[0029] In an optional embodiment of this application, the train fusion domain controller further includes: The card-to-card application synchronization module 850 synchronizes control data and status between identical applications located on two separate CPU cards through an independent cross-CPU card synchronization network.

[0030] In one optional embodiment of this application, the primary bus channel is a PCIe bus, and the backup bus channel is a star Ethernet bus.

[0031] The train fusion domain controller of this application improves the reliability of the train domain controller from multiple dimensions, such as core board configuration, backplane bus design, redundancy design of different applications of single and multi-core heterogeneous CPU cards through virtual management layer, dual CPU card redundancy application design, and data synchronization scheme design between redundant applications. It solves the problems of poor fault tolerance of single module architecture, long master-slave switching time, and master-slave data asynchrony from the native redundancy design scheme inside the domain controller.

[0032] Specific limitations regarding the aforementioned train fusion domain controller 800 can be found in the above section on the redundancy design method for train fusion domain controllers, and will not be repeated here. Each module in the aforementioned train fusion domain controller 800 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the corresponding operations of each module.

[0033] In one embodiment, a computer device is provided, the internal structure of which can be as follows: Figure 9 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and the database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the redundancy design method for a train fusion domain controller as described above. It includes: a memory and a processor; the memory stores the computer program; and the processor executes the computer program to implement any step in the redundancy design method for the train fusion domain controller as described above.

[0034] In one embodiment, a rail vehicle is provided, including the aforementioned train fusion domain controller.

[0035] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, can implement any step in the redundant design method of the train fusion domain controller described above.

[0036] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of this application can be implemented in various computer languages, such as C, VHDL, Verilog, the object-oriented programming language Java, and the interpreted scripting language JavaScript.

[0037] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0038] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0039] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0040] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0041] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0042] In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a connection that allows communication between them; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication between two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0043] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0044] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A redundancy design method for a train fusion domain controller, characterized in that, include: The pre-configured converged domain controller is equipped with two multi-core heterogeneous CPU cards. The two CPU cards adopt a master-slave hot redundancy working mode and communicate through a heartbeat detection channel set between them. The converged domain controller has a backplane, and the backplane is configured with at least two independent physical bus channels. During the operation of the fused domain controller, the master CPU card and slave CPU card master-slave relationship are determined; the master CPU card outputs control commands to the daughterboard connected to the backplane; the slave CPU card monitors the signal of the heartbeat detection channel, and when the heartbeat of the master CPU card is lost or abnormal, a CPU-level switch is performed, the slave CPU card is upgraded to a new master CPU card and takes over control. When the main CPU card and the slave CPU card simultaneously receive data from the expansion daughter card in parallel through the redundant backplane bus, the application layer communicates data through a predefined main bus channel; the status of the main bus channel is detected in real time, and if a failure is detected in the main bus channel, the main path of data communication is automatically switched to the backup bus channel, and only the main CPU card sends control commands to the expansion daughter board.

2. The method according to claim 1, characterized in that, The at least two independent physical bus channels include a first bus channel and a second bus channel, wherein the first bus channel adopts a PCIe bus and the second bus channel adopts a star Ethernet bus. Furthermore, the PCIe bus is configured in cold standby mode, and the Ethernet bus is configured in hot standby mode.

3. The method according to claim 1, characterized in that, The method further includes: Within different operating system partitions of the same CPU card, a set of redundant applications with identical control logic but different IP addresses are deployed. The application in one partition is designated as the primary application and enables multicast to issue control commands to the outside world. The application in the other partition is designated as the backup application and its multicast port is blocked. The backup application continuously receives the heartbeat status of the primary application via unicast. When the primary application is determined to be faulty, the backup application opens its multicast port and takes over the external control functions.

4. The method according to claim 1, characterized in that, The method further includes: For redundant applications within the same CPU card, a shared memory region that can be read by each pair of applications is allocated to achieve real-time synchronization of control instructions and running status between the two. For applications with the same function but distributed across two different CPU cards, a separate data synchronization network interface is established between the two CPU cards for data communication, thereby achieving consistent synchronization of control status across CPU cards.

5. The method according to claim 4, characterized in that, The method of allocating mutually readable shared memory regions to each pair of applications to achieve real-time synchronization of control instructions and running states between them includes: Suppose there are two applications, App A and App B. The system allocates two independent shared memory regions, Mem_A and Mem_B. Mem_A has write permissions granted only to App A and read permissions granted to App B. Mem_B has write permissions granted only to App B and read permissions granted to App A.

6. The redundancy design method for the train fusion domain controller according to claim 4, characterized in that, The data communication via the independent data synchronization network interface established between the two CPU cards includes: On both CPU cards, a physical Ethernet synchronization link established via the main backplane bus is configured for the corresponding application to transmit control data for state synchronization.

7. A train fusion domain controller implemented based on the redundancy design method of the train fusion domain controller according to claims 1 to 6, characterized in that, include: A multi-CPU redundancy module includes at least two CPU cards with heterogeneous multi-core processing capabilities. The two CPU cards are directly connected through a dedicated inter-card communication link for performing heartbeat detection and master / slave status switching. The backplane dual-bus module includes two different and independent main bus channels and backup bus channels set on the control backplane, which provide parallel data transmission and reception paths for at least the main CPU card and the slave CPU card. The controller status arbitration module makes comprehensive decisions on the overall master control, the selection of the primary communication bus, and the succession of control over the failed application based on the results of the heartbeat detection, the bus on / off status, and the application running status.

8. The train fusion domain controller according to claim 7, characterized in that, The train fusion domain controller also includes: The on-card application redundancy module runs two independent operating system partitions on a single CPU card, and deploys applications with the same functional logic but hot standby for each other in different partitions. The two applications synchronize internal data through shared memory and achieve rapid transfer of control through network unicast / multicast switching mechanism. The inter-card application synchronization module synchronizes control data and status between identical applications located on two separate CPU cards through an independent cross-CPU card synchronization network.

9. The train fusion domain controller according to claim 7, characterized in that, The primary bus channel is a PCIe bus, and the backup bus channel is a star Ethernet bus.

10. A rail vehicle, characterized in that, include: The train fusion domain controller as described in any one of claims 7 to 9.

Images