A fault diagnosis apparatus for a vehicle

Abstract

The utility model discloses a kind of fault diagnosis instrument of vehicle, it is related to vehicle field, including host platform, data interface and at least one diagnosis subsystem, each diagnosis subsystem can obtain acquisition signal by data interface, and output corresponding analysis conclusion to host platform, host platform and all diagnosis subsystems are present communication connection, the analysis conclusion of all diagnosis subsystems can be integrated, to obtain the state information of vehicle comprehensively, finally determine the fault condition of vehicle. Through the cooperation of host platform and diagnosis subsystem, the monitoring of vehicle in many aspects is realized, the integration, fusion of multiple diagnosis subsystems are realized, the effect of reducing cost, simplifying system is reached, the comprehensive monitoring of vehicle is realized using diagnosis subsystem, which is beneficial to the root cause analysis of vehicle operation problems, further ensures the safety and reliability of the entire vehicle;Meanwhile, the diagnosis subsystem independently arranged can be flexibly configured according to the diagnosis demand in actual application, and the flexibility is high.

Description

Technical Field

[0001] This utility model relates to the field of vehicles, and in particular to a vehicle fault diagnosis instrument. Background Technology

[0002] With the continuous development of vehicle technology, the requirements for the reliability of vehicles in all aspects are becoming increasingly higher. In particular, during vehicle operation, how to monitor the operating parameters of various aspects of the vehicle and the overall stability of the vehicle in real time has become an important issue. At present, vehicle monitoring systems can only monitor some parameters of the vehicle, making it difficult to comprehensively monitor and analyze the overall operating parameters and fault conditions of the vehicle. Furthermore, the correlation between monitoring data is reduced, and it is impossible to comprehensively analyze the operating parameters of the vehicle and the root causes of safety problems from the perspective of the entire vehicle. There is no effective method in the existing technology that can simultaneously monitor the vehicle from multiple aspects and ensure vehicle safety. Utility Model Content

[0003] The purpose of this invention is to provide a vehicle fault diagnostic instrument that utilizes a diagnostic subsystem to achieve comprehensive vehicle monitoring, which facilitates root cause analysis of vehicle operation problems and thus ensures the safety and reliability of the entire vehicle.

[0004] To solve the above-mentioned technical problems, this utility model provides a vehicle fault diagnosis instrument, comprising:

[0005] Data interface;

[0006] At least one diagnostic subsystem is provided, which is connected to the acquisition device via the data interface to acquire the acquisition signals of the acquisition device in order to generate analysis conclusions for the vehicle; wherein the acquisition signals are signals characterizing the vehicle status information.

[0007] The host platform integrates all the diagnostic subsystems and is used to uniformly manage all the diagnostic subsystems in order to determine the fault status of the vehicle after performing fault fusion analysis through the diagnostic subsystems.

[0008] Optionally, the host platform includes a power supply board, an Ethernet communication board, a data storage board, a CPU board, a hardwired interface board, a speed board, and a backplane;

[0009] Each board in the host platform interacts with the diagnostic subsystem via the backplane.

[0010] Optionally, the host platform also includes a fan and a fan control board; the fan is integrated on the fan control board.

[0011] The fan control board is used to dissipate heat from the interior of the host platform via the fan.

[0012] Optionally, the diagnostic subsystem includes one or more of the following: axle temperature monitoring subsystem board, running gear monitoring subsystem board, stability monitoring subsystem board, instability monitoring subsystem board, and variable damping control subsystem board;

[0013] The axle temperature monitoring subsystem board is connected to the acquisition device through a composite sensor temperature interface to obtain the axle temperature information of the vehicle in order to obtain axle temperature pre-alarm conclusions.

[0014] The running gear monitoring subsystem board is connected to the acquisition device through a composite sensor vibration interface to obtain the first vibration information of the rotating parts of the running gear of the vehicle, so as to obtain the first vibration pre-alarm conclusion.

[0015] The stability monitoring subsystem board is connected to the acquisition device through the vehicle stability monitoring sensor interface to obtain the second vibration information of the vehicle body in order to obtain the second vibration pre-alarm conclusion.

[0016] The instability monitoring subsystem board is connected to the acquisition device through the bogie instability monitoring sensor interface to obtain the third vibration information of the vehicle's bogie in order to obtain the third vibration pre-alarm conclusion.

[0017] The variable damping control subsystem board is connected to an external shock absorber through a shock absorber damping control interface, and is used to output damping control signals to the shock absorber under the control of the CPU board.

[0018] Optionally, the shaft temperature monitoring subsystem board, the running gear monitoring subsystem board, the stability monitoring subsystem board, the instability monitoring subsystem board, and the variable damping control subsystem board are all connected to the respective boards in the host platform through the backplane.

[0019] Optionally, the running gear monitoring subsystem board includes:

[0020] The gearbox monitoring board is connected to the acquisition device installed in the gearbox bearing of the running gear of the vehicle through the composite sensor vibration interface, and is used to acquire the first vibration sub-information of the gearbox bearing of the running gear of the vehicle, so as to obtain the first vibration sub-early warning conclusion.

[0021] The axle box motor monitoring board is connected to the acquisition device installed in the axle box motor bearing of the vehicle's running gear via a composite sensor vibration interface. It is used to acquire the second vibrator information of the axle box motor bearing of the vehicle's running gear in order to obtain a pre-alarm conclusion for the second vibrator.

[0022] Optionally, the rotation speed board and the Ethernet communication board are the same physical plug-in board.

[0023] Optional, also includes:

[0024] The control network interface is connected to the vehicle's Ethernet control network;

[0025] A control and maintenance network interface is connected to the vehicle's control and maintenance network.

[0026] The MVB interface is connected to the vehicle's TCMS.

[0027] The maintenance interface connects to an external maintenance terminal.

[0028] Optionally, the power supply board includes a first power supply board and a second power supply board that are redundant backups of each other, and the CPU board includes a first CPU board and a second CPU board that are redundant backups of each other.

[0029] The Ethernet communication board and the speed board have completely independent first Ethernet communication switching module and second Ethernet communication switching module, so as to establish two redundant Ethernet communication networks inside the host platform through the first Ethernet communication switching module and the second Ethernet communication switching module.

[0030] The first CPU board, the second CPU board, the hardwired interface board, the data storage board, and each of the diagnostic subsystems are all connected to the first Ethernet communication switching module and the second Ethernet communication switching module respectively through two Ethernet communication networks to realize information interaction between the boards.

[0031] Optional, also includes:

[0032] A CAN communication bus and / or RS485 communication bus are set between the first CPU board, the second CPU board, the data storage board, and each subsystem board to achieve backup of Ethernet communication.

[0033] This invention provides a vehicle fault diagnostic instrument, including a host platform, a data interface, and at least one diagnostic subsystem. Each diagnostic subsystem can acquire signals through the data interface and output corresponding analysis conclusions to the host platform. The host platform communicates with all diagnostic subsystems, integrating their analysis conclusions to comprehensively obtain vehicle status information and ultimately determine the vehicle's fault condition. The cooperation between the host platform and the diagnostic subsystems enables multi-faceted vehicle monitoring, achieving integration and fusion of multiple diagnostic subsystems. This reduces costs and simplifies the system. Utilizing the diagnostic subsystems for comprehensive vehicle monitoring facilitates root cause analysis of vehicle operation problems, further ensuring the overall vehicle safety and reliability. Furthermore, the independently configured diagnostic subsystems can be flexibly configured according to actual diagnostic needs, offering high flexibility. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this utility model, the drawings used in the prior art and embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this utility model. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 A schematic diagram of the internal architecture of a vehicle fault diagnostic instrument provided by this utility model;

[0036] Figure 2 A schematic diagram of the structure of a host platform provided by this utility model;

[0037] Figure 3 A schematic diagram of the circuit board composition of a vehicle fault diagnostic instrument provided by this utility model;

[0038] Figure 4 A schematic diagram of the structure of a vehicle fault diagnostic instrument provided by this utility model;

[0039] Figure 5 A schematic diagram of the interface of a vehicle fault diagnostic instrument provided by this utility model;

[0040] Figure 6 A schematic diagram of downlink data transmission in a fault diagnostic instrument provided by this utility model;

[0041] Figure 7 This is a schematic diagram of data uplink transmission in a fault diagnostic instrument provided by this utility model. Detailed Implementation

[0042] The core of this invention is to provide a vehicle fault diagnostic instrument that utilizes a diagnostic subsystem to achieve comprehensive vehicle monitoring, which facilitates root cause analysis of vehicle operation problems, thereby ensuring the safety and reliability of the entire vehicle.

[0043] To make the objectives, technical solutions, and advantages of the embodiments of this utility model clearer, the technical solutions of the embodiments of this utility model will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this utility model, not all embodiments. Based on the embodiments of this utility model, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of this utility model.

[0044] See Figure 1 As shown, Figure 1This utility model provides an internal architecture diagram of a vehicle fault diagnostic instrument. To solve the above-mentioned technical problems, this utility model provides a vehicle fault diagnostic instrument, including a host platform 1, a data interface 2, and at least one diagnostic subsystem 3.

[0045] Data interface 2;

[0046] At least one diagnostic subsystem 3 is connected to the acquisition device via a data interface 2 to acquire the acquisition signals from the acquisition device in order to generate analysis conclusions for the vehicle; wherein the acquisition signals are signals characterizing vehicle status information.

[0047] The host platform 1 integrates all the diagnostic subsystems 3. The host platform 1 is used to uniformly manage all the diagnostic subsystems 3, so as to determine the fault condition of the vehicle after performing fault fusion analysis through the diagnostic subsystems 3.

[0048] Data interface 2 is used to receive acquisition signals from the acquisition device; wherein, the acquisition signal is a signal characterizing vehicle status information;

[0049] The diagnostic subsystem 3 is used to acquire the collected signals through the data interface 2, analyze and process the collected signals to obtain analysis conclusions, and transmit the collected signals and analysis conclusions to the host platform 1.

[0050] The host platform 1 is used to uniformly manage all diagnostic subsystems 3. Managing the diagnostic subsystems 3 includes collecting the acquired signals and analysis conclusions sent by the diagnostic subsystems 3, sending signals to the diagnostic subsystems 3, recording the acquired signals and analysis conclusions sent by the diagnostic subsystems 3, and sending information externally. Sending information externally refers to sending information to devices outside the diagnostic tool, such as the host platform sending information to the vehicle and its management system.

[0051] Understandably, to achieve comprehensive vehicle monitoring, this application proposes an architecture of host platform 1 + diagnostic subsystem 3 to implement a vehicle fault diagnostic instrument. Host platform 1 uniformly hosts several diagnostic subsystems 3. Each diagnostic subsystem 3 can acquire data signals representing vehicle status information through its corresponding data interface 2, and then analyze and process these signals to determine analytical conclusions. All acquired signals and corresponding analytical conclusions are aggregated on host platform 1. All diagnostic subsystems are uniformly managed by the host platform, allowing host platform 1 to uniformly acquire and form vehicle status information by obtaining data from each diagnostic subsystem 3. Through the cooperation between multiple diagnostic subsystems 3 and host platform 1, real-time vehicle status information and monitoring data uploads are achieved. After acquiring all acquired signals and analytical conclusions, host platform 1 can comprehensively judge the vehicle's fault condition from multiple perspectives, thereby achieving comprehensive vehicle monitoring and fault diagnosis. By uniformly hosting all diagnostic subsystems 3 on host platform 1, the integration and fusion of multiple diagnostic subsystems 3 are achieved, resulting in cost reduction and system simplification. Utilizing the data correlation and fusion analysis of multiple different diagnostic subsystems 3 enables safety monitoring of rail transit vehicles.

[0052] It should be noted that this application does not impose any special limitations on the specific type and implementation method of each diagnostic subsystem 3. The subsystem can be configured according to the specific application of the vehicle. There are multiple options for the specific implementation method of its analysis and processing operations, which can be set according to the monitoring object and the specific situation of the collected signals. There are also multiple options for the specific implementation method of the analysis conclusions, which can be a summary of the patterns in the collected signals or a preliminary judgment of the vehicle anomalies represented by the collected signals. Similarly, this application does not impose any special limitations on the specific type and implementation method of data interface 2. The specific type and number of data interfaces 2 can be set according to the monitoring requirements of the diagnostic subsystem 3. To further improve the scalability and applicability of the diagnostic instrument, all data interfaces 2 adopt the same type of interface, thereby unifying the interface of the host platform 1. This application does not impose any special limitations on the specific type of vehicle or its implementation method.

[0053] This invention provides a multi-system integrated fault diagnostic instrument for trains and other vehicles. It utilizes a diagnostic subsystem 3 to achieve comprehensive monitoring of vehicle status information. Simultaneously, all diagnostic subsystems 3 are integrated into a host platform 1, facilitating comprehensive fault diagnosis. It enables data correlation analysis between different diagnostic subsystems 3. The host platform 1 is configured to uniformly distribute and collect status information, and can also achieve unified recording and external transmission. After obtaining the collected signals and analysis conclusions from each diagnostic subsystem 3, the host platform 1 can perform correlation analysis between status information, expanding vehicle operation monitoring from specific points to a broader scope, making the monitoring content more comprehensive and more conducive to root cause analysis of vehicle operation problems.

[0054] See Figure 2 As shown, Figure 2 A schematic diagram of a host platform provided by this utility model; as an optional embodiment, the host platform 1 includes a power supply board, an Ethernet communication board, a data storage board, a CPU board, a hardwired interface board, a speed board, and a backplane;

[0055] Each board in host platform 1 interacts with the diagnostic subsystem 3 via the backplane;

[0056] The power supply board is used to provide power to the host platform 1 and the diagnostic subsystem 3;

[0057] Ethernet communication cards are used to build a communication network between host platform 1 and diagnostic subsystem 3;

[0058] The data storage board is used to store the received acquisition signals and analysis results;

[0059] The CPU board is used to determine the vehicle's fault status based on all received acquisition signals and analysis conclusions;

[0060] Hardwired interface boards are used to enable data interaction between the CPU board and the vehicle via hardwired connections.

[0061] The tachometer card is used to provide vehicle tachometer information.

[0062] It's easy to understand that the host platform 1 also needs to provide the basic conditions such as power supply, Ethernet communication, and speed required for the normal operation of each diagnostic subsystem 3. Each diagnostic subsystem 3 requires power to function properly; therefore, the host platform 1 needs a power supply board to power the entire diagnostic instrument. The uploading and downloading of acquired signals and analysis results require a communication network for transmission; therefore, the host platform 1 includes an Ethernet communication board to build the communication network within the diagnostic instrument, using an Ethernet network connection. The host platform 1 requires a processor for the joint analysis of status information; therefore, the host platform 1 includes a CPU (Central Processing Unit) board specifically for comprehensive analysis and fault diagnosis. After completing fault analysis, the host platform 1 needs to inform the vehicle of the confirmed fault; therefore, the host platform 1 includes a hardwired interface board to enable communication between the CPU board (i.e., the diagnostic instrument) and the vehicle. Considering the need for unified storage, the host platform 1 includes a dedicated data storage board to store acquired signals and analysis results, ensuring unified storage for comprehensive fault diagnosis and facilitating subsequent information retrieval. Considering that vehicle status acquisition requires the vehicle's rotational speed as a benchmark, and that other parameters must be correlated with the rotational speed to accurately and effectively monitor the vehicle's operating status and analyze faults, a dedicated rotational speed board is set up in the host platform 1. The rotational speed board will collect the vehicle's rotational speed signal in real time through rotational speed sensors and other means, thereby providing a rotational speed benchmark for fault diagnosis.

[0063] It should be noted that this application does not impose any particular limitations on the specific types and implementation methods of power supply boards, Ethernet communication boards, data storage boards, CPU boards, hardwired interface boards, and speed control boards; these can be configured according to the actual application scenario. For ease of integration, a backplane is also provided in the host platform 1. The backplane is used to fix the various boards in the host platform 1 and, through its internal integrated circuits, works with the power supply board to achieve power distribution and with the Ethernet communication board to achieve communication and interaction between the various boards. This application does not impose any particular limitations on the specific type and implementation method of the backplane.

[0064] As an optional embodiment, the host platform also includes a fan and a fan control board; the fan is integrated on the fan control board.

[0065] The fan control board is used to dissipate heat from the inside of the host platform via a fan.

[0066] As a specific embodiment, such as Figure 2As shown, the host platform 1 comprises a power supply board, an Ethernet communication board, a speed control board, a data storage board, a CPU board, a hard-wired interface board, a backplane, and a fan unit. The host platform 1 further includes a fan unit, which consists of a fan and a fan control board. The fan is directly integrated onto the fan control board, enabling the host platform 1 to have fan cooling capabilities. All boards in the host platform 1 are integrated onto the backplane, which provides power, speed control, communication, and data storage platforms for each diagnostic subsystem 3, and the fan unit provides cooling for the entire diagnostic instrument. The fan control board contains a fan control module and n fans. The fan control module monitors the temperature in the diagnostic instrument in real time via a temperature monitoring module, controlling the fans to operate for cooling when the temperature exceeds a threshold. Simultaneously, it communicates with the host platform 1, particularly the CPU board, via a communication module using a CAN (Controller Area Network) bus, enabling it to control the fans to start and stop when needed by the CPU board. The power supply board includes a first power supply board and a second power supply board, which are redundant backups of each other. Each power supply board includes a protection module and a power module, ensuring safety while providing power. The power supply board protects and processes the DC 110V power input from the vehicle, obtaining a 24V power supply, which independently powers each board in the main unit platform 1 and each diagnostic subsystem 3. Each board and each diagnostic subsystem 3 has two power inputs, each receiving power from the first and second power supply boards respectively. Specifically, the first and second power supply boards can also provide power monitoring signals, including power input failure signals and power output status signals.

[0067] Furthermore, the CPU board specifically includes a first CPU board and a second CPU board. Each diagnostic subsystem 3 transmits the collected signals and analysis results to the first and second CPU boards for unified storage. Then, the first and second CPU boards uniformly send various types of information to the vehicle. Simultaneously, the first and second CPU boards uniformly obtain common information from the vehicle and then distribute it to each diagnostic subsystem 3. The first and second CPU boards are redundant backups of each other, therefore they can be implemented in exactly the same way. The first CPU board includes a CPU and no fewer than three independent Ethernet communication physical network cards, such as... Figure 2As shown in Communication 1, Communication 2, and Communication 3, Communication 1 and Communication 2 are used to implement two Ethernet communications within the host platform 1, respectively. Communication 3, an independent network card, is used for communication between the host platform 1 and the vehicle, serving as the first interface for vehicle communication, and can specifically connect to the vehicle's control network. Simultaneously, an MVB (Multifunction Vehicle Bus) communication module is reserved to implement MVB communication functionality. This module is activated when the vehicle control network uses an MVB interface, ensuring effective communication between the host platform 1 (CPU board) and the vehicle. The implementation of the second CPU board is the same as that of the first CPU board, and will not be described further here. The second vehicle communication interface implemented by the second CPU board via the Ethernet communication physical network card can also serve as a backup for the first vehicle communication interface implemented by the first CPU board, and can specifically connect to the vehicle's control network and / or maintenance network.

[0068] The hard-wired interface board features multiple hard-wired signals, enabling the host platform to establish a third interface for vehicle communication via hardware signals. This interface serves as a redundancy backup for the first and second interfaces implemented by the CPU board. An internal CPU is also included to receive and process these multiple hardware signals. The data storage board comprises a CPU and a storage disk, used to organize and store the acquired signals, analysis results, and other data. The storage disk can be implemented using a removable hard drive, etc. This application does not impose any specific limitations on this method. Removable hard drives facilitate easy removal and data transfer, significantly improving data download efficiency.

[0069] Specifically, by setting up power supply boards, Ethernet communication boards, data storage boards, CPU boards, hard-wired interface boards, and speed boards in the host platform 1, the basic working conditions for fault diagnosis of each diagnostic subsystem 3 and the CPU board are provided to ensure the normal operation of the entire diagnostic instrument.

[0070] See Figure 3 As shown, Figure 3 This utility model provides a schematic diagram of the circuit board composition of a vehicle fault diagnostic instrument; as an optional embodiment, the diagnostic subsystem 3 includes one or more of the following: axle temperature monitoring subsystem board, running gear monitoring subsystem board, stability monitoring subsystem board, instability monitoring subsystem board, and variable damping control subsystem board;

[0071] The axle temperature monitoring subsystem board is connected to the acquisition device through a composite sensor temperature interface to collect the axle temperature information of the vehicle, analyze the axle temperature information, obtain the axle temperature pre-alarm conclusion, and send the axle temperature information and the axle temperature pre-alarm conclusion to the CPU board and the data storage board.

[0072] The running gear monitoring subsystem board is connected to the acquisition device through a composite sensor vibration interface. It is used to collect the first vibration information of the rotating parts of the vehicle's running gear, analyze and process the first vibration information to obtain the first vibration pre-alarm conclusion, and send the first vibration information and the first vibration pre-alarm conclusion to the CPU board and the data storage board.

[0073] The stability monitoring subsystem board is connected to the acquisition equipment through the vehicle stability monitoring sensor interface. It is used to collect the second vibration information of the vehicle body, analyze and process the second vibration information to obtain the second vibration pre-alarm conclusion, and send the second vibration information and the second vibration pre-alarm conclusion to the CPU board and the data storage board.

[0074] The instability monitoring subsystem board is connected to the acquisition equipment through the bogie instability monitoring sensor interface. It is used to collect the third vibration information of the vehicle's bogie, analyze and process the third vibration information to obtain the third vibration pre-alarm conclusion, and send the third vibration information and the third vibration pre-alarm conclusion to the CPU board and the data storage board.

[0075] The variable damping control subsystem board is connected to the external shock absorber through the shock absorber damping control interface, and is used to output the damping control signal of the shock absorber under the control of the CPU board.

[0076] Understandably, the diagnostic instrument can integrate and expand various monitoring-type diagnostic subsystems through the host platform 1. These monitoring-type subsystems can specifically include axle temperature monitoring subsystem boards, running gear monitoring subsystem boards, stability monitoring subsystem boards, and instability monitoring subsystem boards. Correspondingly, data interfaces 2 include composite sensor temperature interfaces, composite sensor vibration interfaces, vehicle stability monitoring sensor interfaces, and bogie instability monitoring sensor interfaces. The axle temperature monitoring subsystem board can collect and analyze vehicle axle temperature information through the composite sensor temperature interface. This axle temperature information specifically includes the axle temperatures of the running gear axle boxes, gearboxes, motor bearings, and motor stators. By monitoring and collecting axle temperature data, it determines whether there are any abnormalities in the vehicle's axle temperature and generates corresponding axle temperature pre-alarm conclusions when abnormalities occur, sending them to the host platform 1. The host platform 1 then conducts comprehensive analysis to determine the cause of the axle temperature abnormality and locate the fault. The running gear monitoring subsystem board can collect and process vibration and impact signals from rotating components through a composite sensor vibration interface, enabling fault diagnosis of rotating components (including bearings, gears, treads, etc.) and outputting corresponding first-level vibration pre-alarm conclusions. The stability monitoring subsystem board can collect and process lateral, vertical, and longitudinal vibration accelerations of the car body through a car body stability monitoring sensor interface, performing real-time monitoring of the car body's running quality, thereby achieving vibration monitoring of the car body and analyzing its operating status. It also outputs a second-level vibration pre-alarm conclusion when the corresponding second-level vibration information is abnormal. The instability monitoring subsystem board can collect and process lateral and vertical vibration accelerations of the bogie through a bogie instability monitoring sensor interface, performing real-time monitoring of the bogie's operating status, achieving bogie vibration monitoring, and outputting a third-level vibration pre-alarm conclusion for instability conditions.

[0077] On the other hand, the diagnostic instrument can integrate and expand the control-type diagnostic subsystem through the host platform 1. Specifically, the control-type diagnostic subsystem can be a variable damping control subsystem board. After comprehensively analyzing the vibration information and vibration pre-alarm conclusions output by the stability monitoring subsystem board and the instability monitoring subsystem board, the host platform 1 can effectively determine the operating status of the bogie and the car body. Based on this, the host platform 1 can send corresponding control signals to control the undercarriage shock absorbers through the variable damping control subsystem board, and adjust the running quality of the car body in real time by controlling the damping magnitude of the undercarriage shock absorbers.

[0078] It should be noted that this application does not specifically limit the specific types and implementation methods of the axle temperature monitoring subsystem board, running gear monitoring subsystem board, stability monitoring subsystem board, instability monitoring subsystem board, and variable damping control subsystem board. The axle temperature monitoring subsystem board can be implemented through a combination of temperature acquisition boards and temperature processing boards. Figure 2As shown, the monitoring-type diagnostic subsystem board performs signal acquisition and signal processing, while the control-type diagnostic subsystem board executes the control signals issued by the host platform 1 through the actuator.

[0079] Specifically, through various types of monitoring-type diagnostic subsystems, real-time monitoring and comprehensive analysis of vehicle status information in various aspects can be achieved. Furthermore, control-type diagnostic subsystems can be integrated to adjust the vehicle's operating status. It has strong scalability and flexibility, and the type of diagnostic subsystem 3 integrated in the diagnostic instrument can be flexibly adjusted according to actual application needs.

[0080] As an optional embodiment, the shaft temperature monitoring subsystem board, the running gear monitoring subsystem board, the stability monitoring subsystem board, the instability monitoring subsystem board, and the variable damping control subsystem board are all connected to the respective boards in the host platform 1 via a backplane.

[0081] It is easy to understand that, in order to achieve the connection between the host platform 1 and the various diagnostic subsystems 3, a backplane is set in the host platform 1. Each diagnostic subsystem 3 can directly connect to the various boards in the host platform 1 through the backplane. Specifically, the backplane will have several reserved slots and will integrate circuits that work with the host platform 1 (power circuits that work with the power supply board and communication circuits that work with the Ethernet communication board, etc.). After the configuration of the diagnostic subsystems 3 is determined according to actual needs, each board in the host platform 1 and each diagnostic subsystem 3 can be directly fixed into the reserved slots to achieve connection. This application does not make any special restrictions on the specific number and implementation method of the reserved slots. The specific implementation needs to be based on the interface. After the host platform 1 is configured, the reserved slots can be set directly, and a spare slot can be reserved in advance for future expansion of the diagnostic subsystems 3.

[0082] Specifically, the backplane is used to integrate and connect the main platform 1 and various diagnostic subsystems 3 in the diagnostic instrument, simplifying wiring and improving the overall integration of the diagnostic instrument. All the reserved slots on the backplane follow a unified standardized interface protocol, ensuring the scalability of the main platform 1. The diagnostic subsystems 3 only need to match the reserved slots on the backplane to achieve seamless docking with the diagnostic instrument, resulting in strong compatibility.

[0083] As one specific embodiment, see Figure 4 As shown, Figure 4This utility model provides a structural schematic diagram of a vehicle fault diagnostic instrument. The various boards and diagnostic subsystems 3 in the main platform 1 are assembled in a chassis. Twelve pre-set slots, as shown in the figure, allow for flexible adjustment of the board configuration of the diagnostic subsystems 3 as needed. For example, initially, independent boards for axle temperature monitoring, running gear monitoring, stability monitoring, instability monitoring, and variable damping control can be set. Later, the insertion and removal states of each subsystem board can be flexibly selected according to requirements. When needed, they are inserted into the pre-set slots to cooperate with the main platform 1 for fault diagnosis; when not needed, the boards can be directly removed.

[0084] As an optional embodiment, the running gear monitoring subsystem board includes:

[0085] The gearbox monitoring board is connected to the acquisition device installed in the gearbox bearing of the running gear of the vehicle through the composite sensor vibration interface. It is used to collect the first vibration information of the gearbox bearing of the running gear of the vehicle, analyze and process the first vibration information to obtain the first vibration pre-alarm conclusion, and send the first vibration information and the first vibration pre-alarm conclusion to the CPU board and the data storage board.

[0086] The axle box motor monitoring board is connected to the acquisition device installed in the axle box motor bearing of the vehicle's running gear via a composite sensor vibration interface. It is used to collect the second vibration information of the axle box motor bearing of the vehicle's running gear, analyze and process the second vibration information to obtain the second vibration pre-alarm conclusion, and send the second vibration information and the second vibration pre-alarm conclusion to the CPU board and the data storage board.

[0087] Understandably, to achieve more accurate monitoring of vibration information in the running gear, gearbox monitoring boards and axle box motor monitoring boards can be further used to implement the running gear monitoring subsystem boards. The gearbox monitoring board is specifically used to collect and process vibration information from the running gear gearbox bearings, and the axle box motor monitoring board is specifically used to collect and process vibration information from the running gear axle box motor bearings. This allows the host platform 1 to achieve more accurate fault location through comprehensive analysis. This application does not specifically limit the specific types and implementation methods of the gearbox monitoring boards and axle box motor monitoring boards.

[0088] As an optional embodiment, the rotation speed board and the Ethernet communication board are the same physical plug-in board.

[0089] It's easy to understand that, to further simplify the design and reduce the overall implementation cost of the diagnostic instrument, the speed control board and the Ethernet communication board can be further integrated into a single physical pluggable board, using one physical pluggable board to implement both the speed control board and the Ethernet communication board. For example... Figure 2 As shown, the speed board and Ethernet communication board are directly implemented using a separate Ethernet communication and speed processing board, which integrates a speed processing module to provide vehicle speed information, and integrates a first Ethernet communication switching module and a second Ethernet communication switching module to build a communication network between the host platform 1 and the diagnostic subsystem 3.

[0090] As an optional embodiment, the host platform 1 is specifically used to perform fault fusion analysis based on the information sent by each subsystem board and the corresponding pre-alarm conclusions in order to determine the fault status of the vehicle.

[0091] Understandably, each subsystem board transmits the collected signals, such as axle temperature information, first vibration information, second vibration information, and third vibration information, to the host platform 1. Based on the information it has monitored, each board performs preliminary analysis and processing to obtain corresponding axle temperature pre-alarm conclusions, first vibration pre-alarm conclusions, second vibration pre-alarm conclusions, and third vibration pre-alarm conclusions. These pre-alarm conclusions are also output to the host platform 1. The host platform 1 comprehensively analyzes all the received information and pre-alarm conclusions to perform fault fusion analysis, thereby determining the vehicle's fault condition and achieving fault diagnosis.

[0092] As an optional embodiment, it also includes:

[0093] Control network interface, which connects to the vehicle's Ethernet control network;

[0094] Control + maintenance network interface, connected to the vehicle's control + maintenance network;

[0095] The MVB interface connects to the vehicle's TCMS.

[0096] The maintenance interface connects to an external maintenance terminal.

[0097] The control network interface is used to connect to the vehicle's Ethernet control network and interact with the vehicle's TCMS for data exchange.

[0098] The control and maintenance network interface is used to connect to the vehicle's control and maintenance network and exchange information with the vehicle's TCMS and maintenance network.

[0099] The MVB interface is used to provide a data exchange channel between the host platform 1 and the vehicle's TCMS when the vehicle's TCMS interface is MVB.

[0100] The maintenance interface is used to connect to an external maintenance terminal so that the external maintenance terminal can perform maintenance operations on the fault diagnostic instrument.

[0101] It is easy to understand that the host platform 1 needs to communicate with the vehicle to notify it of fault conditions and obtain vehicle status information. Therefore, the host platform 1 also includes one or more combinations of control network interface, control + maintenance network interface, MVB interface, and maintenance interface. The control network interface is used to connect with the vehicle's Ethernet control network to realize information exchange between the host platform 1 and the vehicle's TCMS (Train Control and Management System). Specific information categories include, but are not limited to, the time, kilometer markers, latitude and longitude, mileage, driver's operating terminal, traction level, braking level, and outside temperature transmitted from the TCMS to the host platform 1. The host platform 1 also transmits the following to the TCMS: host platform 1 life signals, equipment fault signals, instability warning / alarm signals, stability warning / alarm signals, bearing warning / alarm signals, gear warning / alarm signals, tread warning / alarm signals, shock absorber damping control signals, temperature data, and temperature warning / alarm signals. The control + maintenance network interface is used to connect to the vehicle's control + maintenance network, enabling information exchange between the host platform 1 and the vehicle's TCMS and related maintenance network systems. These systems include, but are not limited to, PHM (Prognostics and Health Management) and WTD (Wireless Data Transmit Device). Besides the information transmitted via the control network interface, the information exchanged within the maintenance network can also include raw data, conclusions, and information related to instability pre- / alarm events, as well as bearing, gear, and tread pre- / alarm events transmitted from the host platform 1 to the TCMS. The MVB interface is used when the vehicle's TCMS interface is MVB (non-Ethernet). The host platform 1 connects to the TCMS system via the MVB interface for information exchange, and the information exchanged through the MVB interface is similar to that via the control network interface. The maintenance interface is used to connect external maintenance terminals to the host platform 1, enabling external maintenance terminals to perform relevant maintenance operations.

[0102] As a specific embodiment, such as Figure 2 As shown, the control network interface and / or control + maintenance network interface can be implemented in the CPU board through the setting of the independent Ethernet communication physical network card 3, and the MVB interface can be implemented by reserving the MVB communication module.

[0103] In summary, see Figure 5 As shown, Figure 5 This utility model provides an interface diagram of a vehicle fault diagnostic instrument; the entire diagnostic instrument includes, for example,... Figure 5 The input / output interfaces are shown. Combined with... Figure 2 As shown, the diagnostic instrument interface specifically includes two power interfaces that work with the power supply board to receive the two redundant DC 110V power inputs from the vehicle via the two power supply boards in the host platform 1. It also includes a speed input interface and a speed output interface that work with the Ethernet communication and speed processing board. The speed input interface receives the raw speed signal from the vehicle's speed sensor, and the speed output interface outputs the raw speed signal processed by the speed processing module in the host platform 1. Independent composite sensor vibration signal interfaces receive the raw vibration signals collected by various composite sensors installed in the running gear; independent composite sensor temperature signal interfaces receive the raw temperature signals collected by various composite sensors installed in the running gear; independent vehicle stability monitoring sensor interfaces receive the raw vibration signals collected by the vehicle stability monitoring sensor; independent bogie instability monitoring sensor interfaces receive the raw vibration signals collected by the bogie instability monitoring sensor; and a shock absorber damping control interface outputs the damping control signal for the shock absorber from the host platform 1.

[0104] On the other hand, the diagnostic tool communicates with the vehicle via a control network interface, a control + maintenance network interface, an MVB interface, a maintenance interface, and a hardware interface. Specifically, the MVB interface uses MVB1 and MVB2 interfaces as backups. The hardware interface board communicates with the vehicle's TCMS via hard-wired interface 1 and hard-wired interface 2 to transmit the diagnostic tool's operating status and monitoring results. The hardware interface serves as a backup interface for the control network interface, control + maintenance network interface, and MVB interface implemented based on Ethernet / MVB communication. The interaction between the host platform 1 and the vehicle via the hardware interface includes, but is not limited to, the following signals transmitted from the host to the TCMS: instability warning / alarm signals, stability warning / alarm signals, bearing warning / alarm signals, gear warning / alarm signals, tread warning / alarm signals, temperature warning / alarm signals, host normal / fault signals, and temperature sensor normal / fault signals.

[0105] Specifically, through multiple redundant communication interfaces and hardware interfaces, reliable communication between the host platform 1 and the vehicle can be effectively guaranteed, so as to ensure the pre-alarm and alarm functions of the diagnostic instrument.

[0106] As an optional embodiment, the power supply board includes a first power supply board and a second power supply board that are redundant backups of each other, and the CPU board includes a first CPU board and a second CPU board that are redundant backups of each other.

[0107] The Ethernet communication board and the speed board have completely independent first Ethernet communication switching module and second Ethernet communication switching module, so as to establish two redundant Ethernet communication networks inside the host platform 1 through the first Ethernet communication switching module and the second Ethernet communication switching module.

[0108] The first CPU board, the second CPU board, the hardwired interface board, the data storage board, and each diagnostic subsystem 3 are all connected to the first Ethernet communication switching module and the second Ethernet communication switching module through two Ethernet communication networks to realize information exchange between the boards.

[0109] It is understandable that the communication network established by the Ethernet communication card in host platform 1 can be directly implemented by setting up the corresponding Ethernet communication switching module to achieve intranet communication in the diagnostic instrument. For example... Figure 2 As shown, the Ethernet communication and speed processing board has two completely independent Ethernet communication switching modules, establishing two redundant Ethernet communication networks within the host. The first CPU board, the second CPU board, the hard-wired interface board, the data storage board, and each diagnostic subsystem 3 are all connected to the first Ethernet communication switching module and the second Ethernet communication switching module via two independent and physically isolated Ethernet connections, as shown in the figure. All boards are equipped with two physical Ethernet communication network cards, Communication 1 and Communication 2, to connect with the first and second Ethernet communication switching modules, thereby enabling information exchange between the boards.

[0110] Specifically, redundancy settings are used to effectively ensure the reliable operation of the host platform 1 and the entire diagnostic instrument, including but not limited to redundancy of power supply boards, CPU boards, and communication, to ensure the normal operation of the diagnostic instrument.

[0111] As an optional embodiment, it also includes:

[0112] A CAN communication bus and / or RS485 communication bus are set up between the first CPU board, the second CPU board, the data storage board, and each subsystem board to achieve backup for Ethernet communication.

[0113] It is easy to understand that, to further ensure communication reliability, a CAN communication bus and / or an RS485 communication bus have been added between the various boards of the host platform 1 and the various diagnostic subsystems 3 as backups for Ethernet communication. For example... Figure 2 As shown, each board is connected to the CAN bus via a CAN module and to the RS485 communication bus via an RS485 module.

[0114] See Figure 6 As shown, Figure 6This invention provides a schematic diagram of downlink data transmission in a fault diagnostic instrument; see also Figure 7 As shown, Figure 7 This invention provides a schematic diagram of data uplink transmission in a fault diagnostic instrument. As an optional embodiment, the CPU board is also used for:

[0115] Synchronization control signals are sent to each subsystem board to control the acquisition device to synchronously acquire each acquisition signal.

[0116] Understandably, each diagnostic subsystem 3 connects to the backplane of the host platform 1 via a unified interface and independently executes its own monitoring, diagnostic, and control functions. Simultaneously, each diagnostic subsystem 3 periodically exchanges information with the host platform 1 through a communication network, enabling the sharing of public information (such as vehicle time, kilometer markers, latitude and longitude), unified data storage, and unified external (vehicle, etc.) communication. The data transmission method within the entire diagnostic instrument is as follows: Figure 6 and Figure 7 As shown, on the one hand, after the CPU boards (including the first CPU board and the second CPU board) in the host platform 1 obtain public information from the vehicle, they transmit the public information downlink to each diagnostic subsystem 3 board via multicast through the communication network inside the diagnostic instrument. On the other hand, the information and pre-alarm conclusions of each diagnostic subsystem 3 are transmitted uplink to the CPU boards and data storage boards in the host platform 1 via the communication network inside the diagnostic instrument.

[0117] Furthermore, considering the different services and data volumes of each diagnostic subsystem 3, network partitioning can be performed to assign different diagnostic subsystems 3 to different communication groups. For example... Figure 7 As shown, the CPU board, data storage board, running gear monitoring subsystem board, and axle temperature monitoring subsystem board are grouped into the same communication group. This allows the running gear monitoring subsystem board to receive relevant data when the information and pre-alarm conclusions from the axle temperature monitoring subsystem board are uploaded to the host platform 1, enabling correlated diagnosis. For example, when the axle temperature monitoring subsystem board detects an excessively high temperature at a certain measuring point, the host platform 1 can send relevant information to the running gear monitoring subsystem board, controlling it to continuously collect data at the location of the excessively high temperature. Conversely, when the running gear monitoring subsystem board detects a fault at a certain measuring point, it can also integrate the axle temperature information from the axle temperature monitoring subsystem board, thereby achieving accurate diagnosis through multiple physical quantities such as temperature and vibration (impact) signals at that measuring point. This achieves integrated diagnostic correlation between the axle temperature monitoring subsystem board and the other subsystem board.

[0118] It is easy to understand that there are mutual influences between the train's track, running gear wheelset treads, bogies, and car body. Therefore, the main platform 1 can perform correlation analysis on the monitoring information from the axle temperature monitoring subsystem board, running gear monitoring subsystem board, stability monitoring subsystem board, and instability monitoring subsystem board. When the main platform 1 detects that the third vibration information and the third vibration pre-alarm conclusion of the instability monitoring subsystem board indicate excessive vibration or instability pre-alarm / alarm, or that the second vibration information and the second vibration pre-alarm conclusion of the stability monitoring subsystem board indicate significant vibration or pre-alarm, it can simultaneously transmit this information to the running gear monitoring subsystem board. This allows the running gear monitoring subsystem board to collect and diagnose data at the measurement points of each axle box in the corresponding bogie, and to perform a comprehensive analysis by combining the vibration (impact) signals from the tread, axle box, and track.

[0119] Based on this, in order to ensure the synchronization of data collected by the axle temperature monitoring subsystem board, the running gear monitoring subsystem board, the stability monitoring subsystem board, and the instability monitoring subsystem board at certain times, a synchronization control signal is designed inside the host platform 1. This synchronization control signal is initiated by the CPU board in the host platform 1 to control the acquisition devices through each subsystem board to synchronously acquire various acquisition signals. For example... Figure 2 As shown, the CPU board, data storage board, hardware interface board, and diagnostic subsystem board are all equipped with synchronization modules to receive synchronization control signals. This application does not specifically limit the specific implementation method of the synchronization control signals.

[0120] Specifically, through the design of synchronous control signals, the host platform 1 can achieve synchronous acquisition among multiple diagnostic subsystems 3, so as to ensure the accuracy and reliability of subsequent horizontal fusion analysis of data from multiple diagnostic subsystems 3, and make the vehicle monitoring process more comprehensive.

[0121] As an optional embodiment, sending synchronization control signals to each subsystem board includes:

[0122] Synchronization requirements are sent to each subsystem board via Ethernet communication; the synchronization requirements include the acquisition target, acquisition start time, and acquisition end time.

[0123] Synchronization pulse signals are sent to each subsystem board to control the acquisition device to perform synchronous acquisition based on the synchronization requirements after receiving the synchronization pulse signals.

[0124] It is easy to understand that the synchronization control signal can be implemented by issuing synchronization requirements in conjunction with synchronization pulse signals. The host platform 1 first issues synchronization requirements to each diagnostic subsystem 3 board via communication connection. The synchronization requirements specify the acquisition target, acquisition start time, and acquisition end time. The acquisition start time and acquisition end time are both specified based on the synchronization pulse signal. For example, the rising edge of the second pulse of the synchronization pulse signal is specified as the acquisition start time. Then, the synchronization pulse signal is issued. After receiving the synchronization pulse signal, each diagnostic subsystem 3 executes the synchronized acquisition task according to the synchronization requirements. This application does not make any special restrictions on the specific type and implementation method of the synchronization requirements and synchronization pulse signals.

[0125] As an optional embodiment, sending synchronization control signals to each subsystem board includes:

[0126] A preset level combination is sent to each subsystem board via a synchronization control line to control each subsystem board to control the acquisition device to perform synchronous acquisition based on the preset level combination;

[0127] Each subsystem board has a pre-set correspondence between preset level combinations and synchronization requirements.

[0128] It is understandable that the synchronization control signal can also be implemented directly using a preset level combination. This method eliminates the need for prior communication; instead, the correspondence between the preset level combination and the synchronization requirements is pre-designed in the program of each diagnostic subsystem 3. When the host platform 1 needs synchronization control, it directly sends a specific level combination to each diagnostic subsystem 3. After receiving the signal, the diagnostic subsystem 3 identifies the corresponding synchronization requirement based on the correspondence and begins executing the synchronization acquisition task accordingly. This application does not impose any special limitations on the preset level combinations and their correspondence with synchronization requirements.

[0129] In this specification, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0130] The above description of the disclosed embodiments enables those skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A malfunction diagnosing apparatus for a vehicle, characterized by comprising: include: Data interface; At least one diagnostic subsystem is provided, which is connected to the acquisition device via the data interface to acquire the acquisition signals of the acquisition device in order to generate analysis conclusions for the vehicle; wherein the acquisition signals are signals characterizing the vehicle status information. The host platform integrates all the diagnostic subsystems and is used to uniformly manage all the diagnostic subsystems in order to determine the fault status of the vehicle after performing fault fusion analysis through the diagnostic subsystems.

2. The malfunction diagnosing apparatus for a vehicle according to claim 1, characterized by The host platform includes a power supply board, an Ethernet communication board, a data storage board, a CPU board, a hardwired interface board, a speed board, and a backplane. Each board in the host platform interacts with the diagnostic subsystem via the backplane.

3. The malfunction diagnosing apparatus for a vehicle according to claim 2, characterized by The host platform also includes a fan and a fan control board; the fan is integrated on the fan control board. The fan control board is used to dissipate heat from the interior of the host platform via the fan.

4. The malfunction diagnosing apparatus for a vehicle according to claim 2, characterized by The diagnostic subsystem includes one or more of the following: axle temperature monitoring subsystem board, running gear monitoring subsystem board, stability monitoring subsystem board, instability monitoring subsystem board, and variable damping control subsystem board; The axle temperature monitoring subsystem board is connected to the acquisition device through a composite sensor temperature interface to obtain the axle temperature information of the vehicle in order to obtain axle temperature pre-alarm conclusions. The running gear monitoring subsystem board is connected to the acquisition device through a composite sensor vibration interface to obtain the first vibration information of the rotating parts of the running gear of the vehicle, so as to obtain the first vibration pre-alarm conclusion. The stability monitoring subsystem board is connected to the acquisition device through the vehicle stability monitoring sensor interface to obtain the second vibration information of the vehicle body in order to obtain the second vibration pre-alarm conclusion. The instability monitoring subsystem board is connected to the acquisition device through the bogie instability monitoring sensor interface to obtain the third vibration information of the vehicle's bogie in order to obtain the third vibration pre-alarm conclusion. The variable damping control subsystem board is connected to an external shock absorber through a shock absorber damping control interface, and is used to output damping control signals to the shock absorber under the control of the CPU board.

5. The malfunction diagnosing apparatus for a vehicle according to claim 4, characterized by The axle temperature monitoring subsystem board, the running gear monitoring subsystem board, the stability monitoring subsystem board, the instability monitoring subsystem board, and the variable damping control subsystem board are all connected to the respective boards in the host platform via the backplane.

6. The malfunction diagnosing apparatus for a vehicle according to claim 4, characterized by The running gear monitoring subsystem board includes: The gearbox monitoring board is connected to the acquisition device installed in the gearbox bearing of the running gear of the vehicle through the composite sensor vibration interface, and is used to acquire the first vibration sub-information of the gearbox bearing of the running gear of the vehicle, so as to obtain the first vibration sub-early warning conclusion. The axle box motor monitoring board is connected to the acquisition device installed in the axle box motor bearing of the vehicle's running gear via a composite sensor vibration interface. It is used to acquire the second vibrator information of the axle box motor bearing of the vehicle's running gear in order to obtain a pre-alarm conclusion for the second vibrator.

7. The malfunction diagnosing apparatus for a vehicle according to claim 6, characterized by The rotation speed board and the Ethernet communication board are the same physical plug-in board.

8. The malfunction diagnosing apparatus for a vehicle according to claim 7, characterized by Also includes: The control network interface is connected to the vehicle's Ethernet control network; A control and maintenance network interface is connected to the vehicle's control and maintenance network. The MVB interface is connected to the vehicle's TCMS. The maintenance interface connects to an external maintenance terminal.

9. The malfunction diagnosing apparatus for a vehicle according to claim 8, characterized by The power supply board includes a first power supply board and a second power supply board that are redundant backups of each other, and the CPU board includes a first CPU board and a second CPU board that are redundant backups of each other. The Ethernet communication board and the speed board have completely independent first Ethernet communication switching module and second Ethernet communication switching module, so as to establish two redundant Ethernet communication networks inside the host platform through the first Ethernet communication switching module and the second Ethernet communication switching module. The first CPU board, the second CPU board, the hardwired interface board, the data storage board, and each of the diagnostic subsystems are all connected to the first Ethernet communication switching module and the second Ethernet communication switching module respectively through two Ethernet communication networks to realize information interaction between the boards.

10. The malfunction diagnosing apparatus for a vehicle according to claim 9, characterized by Also includes: A CAN communication bus and / or RS485 communication bus are set between the first CPU board, the second CPU board, the data storage board, and each subsystem board to achieve backup of Ethernet communication.

Images