Distributed control system (DCS) data distribution calculation method and system based on multi-task central processing unit (CPU)

Abstract

The invention relates to a distributed calculation method and system for DCS system data based on a multi-task CPU, and the method employs the cooperation of a kernel operation CPU unit, an I / O communication unit and a diagnosis unit, and can achieve the purposes: improving the stability of the system through avoiding the occurrence of a parking event caused by a non-hardware fault of the DCS system; based on a DCS intelligent diagnosis model, the system is responsible for completing software and hardware intelligent diagnosis of a DCS control module and outputting a control strategy to monitor each hardware circuit and software operation condition of the control module so as to realize real-time and accurate diagnosis of the system state, realize intelligent diagnosis of the DCS system and reduce the management difficulty of the DCS system. The multiple CPUs work cooperatively, tasks are processed in a partitioned mode, the operation load of the single CPU can be reduced, work of other parts cannot be affected after the single CPU breaks down, and the operation capacity and stability of the DCS system control module are improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of DCS system control, and particularly to an allocation calculation system, method and electronic device for DCS system data based on a multi-task CPU. Background Art

[0002] In the process of DCS system control, with the high functionality and complex design of system operation, the following technical problems gradually emerge:

[0003] There is no independent and complete hardware diagnosis scheme, and the hardware operation status of the control module cannot be identified. In the control room of the control station, the operation status and fault conditions of the DCS system control module cannot be known in time; system diagnosis adopts manual or physical diagnosis. Facing the massive diagnostic faults of the DCS system, real-time, accurate and timely diagnosis of the system status cannot be achieved. Manual diagnosis has low efficiency and increases management difficulty;

[0004] There is no DCS system operation status monitoring and restart function, and "shutdown" events of the DCS system are likely to occur;

[0005] A single CPU, as the core unit of the entire system, completes all data operations and data acquisition and output functions of the DCS system control module;

[0006] Some manufacturers' DCS systems do not have the direct communication ability of local I / O modules and need to cooperate with other I / O communication modules to complete communication, increasing the hardware cost. Summary of the Invention

[0007] To solve the above problems, the present application proposes an allocation calculation system, method and electronic device for DCS system data based on a multi-task CPU.

[0008] On the one hand, the present application proposes an allocation calculation system for DCS system data based on a multi-task CPU, including:

[0009] A kernel operation CPU unit, based on Linux - kernel operation CPU 2 - 4, responsible for executing the calculation and operation of kernel data;

[0010] An I / O communication unit, based on Linux - communication processing CPU 3 - 1, responsible for distributing and transmitting kernel data;

[0011] A diagnosis unit, based on the DCS intelligent diagnosis model pre-deployed in the system diagnosis CPU 1 - 8, responsible for completing the software and hardware intelligent diagnosis of the DCS control module and outputting control strategies, and simultaneously recording AI diagnosis operations and fault logs;

[0012] The kernel operation CPU unit, the I / O communication unit, and the diagnostic unit are communicatively connected to each other, and the kernel operation CPU unit is communicatively connected to the host computer.

[0013] As an alternative implementation of the present application, optionally, the method for constructing the DCS intelligent diagnosis model includes:

[0014] Collect historical diagnostic big data of the DCS system and preprocess it;

[0015] Perform feature engineering on the historical diagnostic big data, extract the corresponding historical diagnostic detection data and the corresponding historical control strategies, and construct the corresponding feature set;

[0016] Input the feature set into a preset RF model for feature matching training and learning to train and generate the DCS intelligent diagnosis model;

[0017] Collect the system real-time diagnostic data of the DCS system as a validation set and perform performance verification on the trained DCS intelligent diagnosis model:

[0018] If the verification is passed, deploy the DCS intelligent diagnosis model in the system diagnosis CPU;

[0019] If the verification fails, repeat the above steps to reconstruct the DCS intelligent diagnosis model.

[0020] As an alternative implementation of the present application, optionally, the diagnostic unit includes:

[0021] Power-off detection circuit 1-1 for implementing power-off detection of the control module's DC24V power supply;

[0022] IP address detection circuit 1-2 for identifying the IP address encoding of the control module's hardware physical, and setting the network IP address of the control module through DIP switches;

[0023] Watchdog circuit 1-3 for resetting and restarting the system diagnosis CPU1-8 after software crash;

[0024] Second pulse circuit 1-4 for reading the external second pulse signal, transmitting it to the Linux - kernel operation CPU2-4 and used for system time calibration;

[0025] RS485 circuit 1-5 for collecting data information of internal and external devices in the control cabinet;

[0026] SD card memory 1-6 for storing the log information of the control module's operation;

[0027] DC24V to 5V power supply 1-7 for providing DC5V power supply for the control module;

[0028] The system diagnoses CPUs 1-8, which are responsible for completing the intelligent diagnosis of the software and hardware of the DCS control module and outputting control strategies, and simultaneously recording AI diagnosis operations and fault logs;

[0029] The RTC power supply 1-9 is used for the power supply control of the DC24V to 5V power supplies 1-7;

[0030] The power-off detection circuit 1-1, the IP address detection circuit 1-2, the watchdog circuit 1-3, the second pulse circuit 1-4, the RS485 circuit 1-5, the SD card memory 1-6, the DC24V to 5V power supply 1-7, the system diagnosis CPU 1-8, and the RTC power supply 1-9 are respectively electrically connected to the system diagnosis CPU 1-8.

[0031] As an optional implementation scheme of the present application, optionally, the kernel operation CPU unit includes:

[0032] The DC5V to 3.3V and 3.3V to 1.2V circuit 2-1 is used to provide power supplies with various voltage ranges for the network interface circuit;

[0033] The Ethernet 2-2 and the Ethernet 2-3 are used to provide an Ethernet network for communication between the control module and the upper computer;

[0034] The Linux - kernel operation CPU 2-4 is used for kernel data processing;

[0035] The LED indicator circuit 2-5 is used to externally indicate the operating state of the control module system;

[0036] The Fram memory 2-6 is used to store system configuration data information;

[0037] The master-slave position detection circuit 2-7 is used to identify the master-slave positions of the control module in the redundant state, specifically, one of the control modules is in the host state and the other is in the standby state;

[0038] The master-slave redundant communication interface 2-8 is used for data interaction between the master and standby control modules of the control module and is for redundant configuration;

[0039] The watchdog circuit 2-9 is used to switch the standby control module to the host state and reset the system of the host control module to the standby state after the diagnosis unit detects that the Linux - kernel operation CPU has a software crash, ensuring the continuity of the operation of the control module;

[0040] The Ethernet 2-2 and the Ethernet 2-3 are respectively electrically connected to the DC5V to 3.3V and 3.3V to 1.2V circuit 2-1;

[0041] The Ethernet 2-2, Ethernet 2-3, LED indicator circuit 2-5, Fram memory 2-6, master-slave position detection circuit 2-7, master-slave redundant communication interface 2-8, and watchdog circuit 2-9 are respectively electrically connected to the Linux-kernel operation CPU 2-4.

[0042] As an optional implementation of this application, optionally, the I / O communication unit includes:

[0043] The Linux-communication processing CPU 3-1 is responsible for communicating with the Linux-kernel operation CPU 2-4 and completing data forwarding of the I / O module;

[0044] The Ethernet 3-2 and Ethernet 3-3 are respectively used for network redundant communication with the extended I / O communication module;

[0045] The DC5V to 3.3V and 3.3V to 1.2V circuit 3-4 and the isolated DC5V circuit 3-5 provide power supplies with various voltage ranges for the network interface and bus circuits;

[0046] The extended CAN bus 3-6, extended CAN bus 3-7, CAN bus 3-8, and CAN bus 3-9 are respectively redundant communication field bus transceiver circuits for the local I / O module, and their acquisition and output are both redundant configuration structures;

[0047] The watchdog circuit 3-10 is used to reset and restart after the Linux-communication processing CPU experiences software downtime;

[0048] The DC5V to 3.3V and 3.3V to 1.2V circuit 3-4, extended CAN bus 3-6, extended CAN bus 3-7, CAN bus 3-8, CAN bus 3-9, and watchdog circuit 3-10 are respectively electrically connected to the Linux-communication processing CPU 3-1.

[0049] As an optional implementation of this application, optionally, it further includes:

[0050] The dual-port RAM 4-2 is used for data transceiver caching and is connected between the Linux-kernel operation CPU 2-4 and the Linux-communication processing CPU 3-1.

[0051] As an optional implementation of this application, optionally, it further includes:

[0052] The print interface 4-1 is used to print the print data output by the Linux-kernel operation CPU 2-4 and the Linux-communication processing CPU 3-1, and is connected between the Linux-kernel operation CPU 2-4 and the Linux-communication processing CPU 3-1.

[0053] On the other hand, this application proposes a method for allocating and calculating DCS system data based on a multi-task CPU, including the following steps:

[0054] System initialization: The Linux kernel operation CPU 2-4 sends an instruction to the system diagnosis CPU 1-8, requesting to read the IP address information; after receiving the instruction, the system diagnosis CPU 1-8 reads the hardware DIP switch and sends the IP address information back to the Linux kernel operation CPU 2-4 as the response data; the Linux kernel operation CPU 2-4 parses the response data to complete the initialization of the device;

[0055] Thread diagnosis: When the Linux kernel operation CPU 2-4 and the Linux communication processing CPU 3-1 are running, their respective sub-threads send pulse signals to the system diagnosis CPU 1-8 at regular intervals through controlling GPIO; the system diagnosis CPU 1-8 detects the pulse signals. If a certain thread's pulse signal is not received for a long time, the thread will be marked as faulty, and the fault and operation logs of the corresponding thread will be generated;

[0056] Data communication: Communication interface diagnosis, kernel data output, and kernel data input are carried out among the Linux kernel operation CPU 2-4, the Linux communication processing CPU 3-1, and the system diagnosis CPU 1-8 according to a preset program;

[0057] Redundancy switching: The Linux kernel operation CPU 2-4 sequentially detects the diagnosis of the primary-backup machine interface, determines whether the primary-backup switching condition is met according to the diagnosis of the primary-backup machine interface. If it is met, the primary-backup switching action will be executed, otherwise it will be abandoned.

[0058] On the other hand, this application also proposes an electronic device, including:

[0059] A processor;

[0060] A memory for storing instructions executable by the processor;

[0061] Wherein, when the processor is configured to execute the executable instructions, it implements the method for allocating and calculating DCS system data based on a multi-task CPU.

[0062] Technical effects of the present invention:

[0063] This application designs and adopts a new type of DCS control module. By cooperating with the kernel operation CPU unit, the I / O communication unit, and the diagnosis unit, it can achieve:

[0064] By avoiding the occurrence of "shutdown events" caused by non-hardware faults in the DCS system, the stability of the system is improved;

[0065] An independent diagnostic solution that can monitor and control the operation of each hardware circuit and software of the monitoring control module, and send the information to the computer in the control room of the control station for viewing and alarming. On-site personnel can view and handle it immediately to avoid accidents. By building a DCS intelligent diagnostic model based on a random forest model and deploying it in the system diagnostic CPU after verification, real-time and accurate diagnosis of the system status can be achieved, intelligent diagnosis of the DCS system can be realized, and its management difficulty can be reduced.

[0066] The 3 CPUs work together and process tasks in partitions, which can reduce the operating load of a single CPU. Even if a single CPU fails, it will not affect the work of other parts, improving the computing power and stability of the control module of the DCS system.

[0067] The control module of the present invention directly designs a local I / O communication field bus circuit, which can directly communicate with 64 local I / O modules in combination with software, reducing the market usage cost. At the same time, since intermediate product components are saved, the risk of bus communication failure is indirectly reduced, which is beneficial to low-cost and low-risk bus communication in on-site usage scenarios within 64 I / O modules.

[0068] Other features and aspects of the present disclosure will become apparent from the following detailed description of the exemplary embodiments with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] The drawings included in and constituting a part of the specification illustrate the exemplary embodiments, features, and aspects of the present disclosure together with the specification, and are used to explain the principles of the present disclosure.

[0070] Figure 1 It shows a schematic diagram of the unit composition structure of the control module of the present invention;

[0071] Figure 2 It shows a schematic diagram of the electronic system structure of the control module of the present invention;

[0072] Figure 3 It shows a schematic diagram of the IP address detection circuit of the present invention;

[0073] Figure 4 It shows a timing diagram of the system initialization of the present invention;

[0074] Figure 5 It shows a timing diagram of the thread diagnosis of the present invention;

[0075] Figure 6 It shows a timing diagram of the communication interface diagnosis of the present invention;

[0076] Figure 7 It shows a timing diagram of the kernel data output of the present invention;

[0077] Figure 8 A timing diagram showing the input of kernel data of the present invention is shown;

[0078] Figure 9 A timing diagram showing the redundant communication switching of the present invention is shown;

[0079] Figure 10 An application schematic diagram of an electronic device of the present invention is shown. Detailed implementation manners

[0080] Various exemplary embodiments, features, and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. Identical reference numerals in the drawings denote elements having the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0081] The special term "exemplary" herein means "serving as an example, embodiment, or illustration". Any embodiment described herein as "exemplary" is not necessarily to be construed as superior or better than other embodiments.

[0082] In addition, for a better illustration of the present disclosure, numerous specific details are given in the following detailed implementation manners. Those skilled in the art should understand that the present disclosure can be implemented without some specific details. In some instances, means, elements, and circuits well known to those skilled in the art are not described in detail so as to highlight the gist of the present disclosure.

[0083] Embodiment 1

[0084] As Figure 1 shown, on the one hand, the present application proposes a distribution calculation system for DCS system data based on a multi-task CPU, including:

[0085] A kernel operation CPU unit, based on Linux - kernel operation CPU (2 - 4), responsible for executing the calculation and operation of kernel data;

[0086] An I / O communication unit, based on Linux - communication processing CPU (3 - 1), responsible for distributing and transmitting kernel data;

[0087] A diagnosis unit, based on the DCS intelligent diagnosis model pre-deployed in the system diagnosis CPU (1 - 8), responsible for completing the software and hardware intelligent diagnosis of the DCS control module and outputting a control strategy, and simultaneously recording AI diagnosis operations and fault logs;

[0088] The kernel operation CPU unit, the I / O communication unit, and the diagnosis unit are communicatively connected to each other, and the kernel operation CPU unit is communicatively connected to the host computer.

[0089] The following will specifically describe the composition and functions of each unit in the control module in combination with the attached Figure 2 circuits and functions of each unit in the control module will be specifically described.

[0090] 1. Diagnostic unit --- CPU (deploy the DCS intelligent diagnostic model inside the chip)

[0091] Power-off detection (1-1), IP address detection (1-2), watchdog (1-3), second pulse (1-4), RS485 (1-5), SD card storage (1-6), DC24V to 5V power supply (1-7) (the system also additionally configures a DC24V to 5V power supply (1-10) for the diagnostic unit and the kernel operation CPU unit as a backup power supply), system diagnostic CPU (1-8), RTC power supply (1-9). These components form the diagnostic unit of the control module, which adopts an independent PCB structure and is responsible for completing the software and hardware diagnostic functions of the control module.

[0092] 1), The power-off detection (1-1) circuit is used to detect the power-off of the DC24V power supply of the control module. After the Linux - kernel operation CPU (2-4) reads the power-off signal, under the action of the energy storage circuit, it will continue to work for a few seconds. The CPU will immediately save the running data of the variables of each I / O module of the system according to the detected power-off signal, which is used to restore the current running state after the control module is powered on next time;

[0093] 2), The IP address detection (1-2) circuit is used to identify the hardware physical IP address coding of the control module, and the network IP address of the control module can be set through the DIP switch;

[0094] 3), The watchdog (1-3) circuit is used to reset and restart the system diagnostic CPU (1-8) after software crashes, so that the circuit can work continuously and normally;

[0095] 4), The second pulse (1-4) circuit is used to read the external second pulse signal and transmit it to the Linux - kernel operation CPU for system time calibration;

[0096] 5), The RS485 (1-5) circuit collects the data information of the internal and external devices in the control cabinet;

[0097] 6), The SD card storage (1-6) circuit is used to store the log information of the control module operation;

[0098] 7), The DC24V to 5V power supply (1-7) circuit is used to provide DC5V power for the control module;

[0099] 8), The system diagnostic CPU (1-8) circuit is the core CPU minimum system of the diagnostic circuit.

[0100] The system diagnoses the CPU and deploys a model file of the DCS intelligent diagnosis model through the program file loading method (such as burning), and after parameter tuning, it is put into application. The DCS intelligent diagnosis model can be pre-trained and constructed by the administrator based on the historical diagnosis big data of the DCS system.

[0101] The historical diagnosis big data of the DCS system can obtain the corresponding historical diagnosis big data from the log library or the background database of the DCS system, including the data items of the above 1)-8), such as:

[0102] For the historical diagnosis big data of power-off detection, it can be several groups including power-off signals (system-recorded corresponding signal values), power-off times (after reading the power-off signal, under the action of the energy storage circuit, it will continue to work for a few seconds), and historical variable operation data of each I / O module of the corresponding system (such as when a certain power-off detection is found, what are the circuit control parameters of each I / O module such as the second pulse or watchdog, that is, the historical control strategy given by the system at this time (each control parameter in this case)); several groups of the above historical diagnosis big data of power-off detection can be collected. When performing feature engineering on the historical diagnosis big data of power-off detection later, the feature data composed of the historical variable operation data of each I / O module of the system corresponding to each power-off signal value and time can be found: {(power-off signal value, power-off time), operation variables of each I / O module of the system}. The corresponding power-off detection feature set is composed of several groups of the above feature data and is input into the machine learning model for training, so that the model can learn the operation variables of each I / O module of the system corresponding to different power-off signal values and power-off times. For example, when the model diagnoses and detects that the system has detection data of (power-off signal value 1, power-off time 1) at this time, it will perform mapping according to the learned features and automatically map and match to output the operation variables 1 of the corresponding I / O modules of the system.

[0103] For the historical diagnosis data of the following other items, the feature engineering method can also be used:

[0104] 2), The IP address detection (1-2) circuit is used to identify the hardware physical IP address coding of the control module, and the network IP address of the control module can be set by DIP switches. The feature set is several groups of corresponding (physical IP address coding, network IP address);

[0105] 3), The watchdog (1-3) circuit is used to reset and restart the system diagnosis CPU (1-8) software after crashing, so that the circuit can work continuously and normally; the feature set is (crash signal, restart instruction)

[0106] 4), The second pulse (1-4) circuit is used to read the external second pulse signal and transmit it to the Linux-kernel operation CPU for system time calibration; the feature set is (second pulse signal, time calibration instruction)

[0107] In addition, it also has the function of switching between the primary and standby machines. When the switching condition is met, the primary-standby switching operation is executed, and the relevant operation logs are recorded. The switching data between the primary and standby machines (the historical primary-standby switching strategy related to the switching) can also extract the corresponding detection parameters when the switching condition is met, and combine with the primary-standby switching operation instruction to construct the corresponding feature set. When the model detects the detection parameters of the switching, it automatically outputs the corresponding primary-standby switching operation instruction (the switching instructions and parameters in different modes are constructed by the administrator).

[0108] Extract the corresponding detection feature variables and the historical control strategies given by the corresponding system, construct the corresponding feature set through feature extraction methods and use it for model training, so as to construct the DCS intelligent diagnosis model.

[0109] Next, taking the RF (Random Forest Model) as an example, a construction method of the DCS intelligent diagnosis model will be described:

[0110] Here, taking the historical diagnosis big data of power-off detection as an example, the feature sets of other types of diagnosis data can be obtained in the same way according to the RF model training and learning, or the multi-modal algorithm model can be used for multi-modal data processing, which is decided by the administrator:

[0111] 1). Data collection and preprocessing

[0112] Collect the historical diagnosis logs, events, and data of the DCS system, including:

[0113] Power-off signal value and time: Record the signal value and the time when each power-off event occurs.

[0114] System I / O module operation variables: When each power-off event occurs, collect the operation status variables of each I / O module of the system at the same time. These variables may include but are not limited to voltage, current, temperature, rotation speed, switch status, etc.

[0115] Data preprocessing

[0116] Data cleaning: Remove invalid or abnormal data to ensure data quality.

[0117] Feature engineering: Select or construct meaningful features according to domain knowledge, which may include statistical values of the original data (such as mean, standard deviation), change amounts within a time window, etc.

[0118] Data standardization / normalization: Perform standardization or normalization processing on the feature data to eliminate the dimension difference.

[0119] 2). Construct the feature data set

[0120] Feature pairs: Combine each group (power-down signal value, power-down time) with the operating variables of each I / O module in the system to form feature pairs.

[0121] Feature set: A power-down detection feature set consisting of multiple groups of feature pairs is used as the input data for the model.

[0122] Feature extraction method can be extracted and prepared according to the data type. For example:

[0123] Data preparation

[0124] Ensure that the system can record power-down events and save the relevant signal values and timestamps.

[0125] Ensure that the system can record the operating status and control strategies of each I / O module during each power-down event.

[0126] Power-down signal feature extraction

[0127] Signal value: Directly extract the signal value corresponding to the power-down event from the system record. This may be a digital or analog quantity, depending on the system design and implementation.

[0128] Feature representation: Represent the signal value as one of the features, which can be expressed as signal_value.

[0129] Power-down time feature extraction

[0130] Timestamp: Read the system timestamp when the power-down signal occurs.

[0131] Energy storage working time: Determine the time (in seconds) that the system can continue to work after the power-down signal according to the system design and the characteristics of the energy storage circuit. This time can be obtained from the system configuration or experiments.

[0132] Feature representation: Represent the timestamp as timestamp and the energy storage working time as energy_storage_time.

[0133] I / O module historical control strategy feature extraction

[0134] Module identification: Identify all I / O modules in the system and assign a unique identifier to each module.

[0135] Status variable collection: Collect the status variables of each I / O module during a power-down event, such as second pulse, watchdog status, output level, input signal, etc.

[0136] Control strategy record: Record the control strategies of the system for each I / O module at this time, such as whether a certain module is enabled, the set parameters of the module, etc.

[0137] Feature Representation: Create features for the status variables and control strategies of each I / O module. For example, for the second pulse module, it can be represented as second_pulse_status (status) and second_pulse_control (control strategy); for the watchdog module, it can be represented as watchdog_status and watchdog_control, etc.

[0138] Feature Combination

[0139] Combine the features extracted above into a feature vector for subsequent machine learning model training or analysis. The feature vector may contain the following elements:

[0140] feature_vector =

[0141] signal_value,

[0142] timestamp,

[0143] energy_storage_time,

[0144] second_pulse_status,

[0145] second_pulse_control,

[0146] watchdog_status,

[0147] watchdog_control,

[0148] ... # Features of other I / O modules

[0149] .

[0150] Data Storage and Preprocessing

[0151] Store the extracted feature vector in a database or file for subsequent processing.

[0152] Preprocess the features as needed, such as standardization, normalization, missing value handling, etc.

[0153] Precautions

[0154] Ensure that the system can accurately record power-off events and status changes of I / O modules.

[0155] When extracting features, consider the actual operating conditions of the system and possible noise interference.

[0156] For recording control strategies, it may be necessary to access the system's control logic or configuration files to obtain accurate information.

[0157] The feature extraction process should be as automated as possible to reduce human errors and improve work efficiency.

[0158] Through the above feature extraction method, key features such as power-off signals, power-off times, and historical control strategies of each I / O module of the corresponding system can be extracted from the system records, providing strong support for subsequent analysis and modeling.

[0159] 3). Model training

[0160] Select a model

[0161] Select the Random Forest (RF) as the machine learning model because of its good classification performance and anti-overfitting ability.

[0162] Train the model

[0163] Use the power-off detection feature set to train the Random Forest model, enabling the model to learn the operating variable patterns of each I / O module of the system under different power-off signal values and power-off times.

[0164] Evaluate the performance of the model through methods such as cross-validation, and adjust the model parameters to optimize the performance.

[0165] 4). Model validation and testing

[0166] Validate the performance of the model on an independent test set to ensure that the model has good generalization ability.

[0167] Use evaluation metrics (such as accuracy, recall, F1-score, etc.) to quantify the performance of the model. Administrators can use real-time data for diagnosis and prepare the validation set by themselves.

[0168] 5). Model deployment

[0169] Deployment environment preparation

[0170] Prepare the deployment environment for the system diagnostic CPU, including installing necessary software libraries and dependencies (technicians complete the corresponding CPU program loading process by themselves).

[0171] Ensure that the deployment environment can support the operation of the Random Forest model.

[0172] Model integration and testing

[0173] Integrate the trained Random Forest model into the system diagnostic CPU to achieve real-time operation of the model.

[0174] Conduct system integration testing to ensure that the model can correctly receive input data and output diagnostic results.

[0175] Real-time diagnosis and feedback

[0176] When the system diagnosis CPU receives new power-off signal values and power-off times, it automatically calls the random forest model for diagnosis.

[0177] According to the output of the model, map and match the operating variables of the corresponding system I / O modules, providing a basis for system maintenance and fault troubleshooting.

[0178] 6). Continuous optimization and update

[0179] Monitor the performance of the model during actual operation, and promptly discover and solve problems.

[0180] As new data accumulates, regularly update the model to improve the accuracy of diagnosis.

[0181] Through the above steps, a DCS intelligent diagnosis model based on the random forest model can be constructed, verified and then deployed in the system diagnosis CPU to achieve real-time and accurate diagnosis of the system status, realize the intelligent diagnosis of the DCS system, and reduce its management difficulty.

[0182] 2. Kernel operation CPU unit - CPU

[0183] DC5V to 3.3V, 3.3V to 1.2V (2-1), Ethernet (2-2), Ethernet (2-3), Linux - kernel operation CPU (2-4), LED indicator (2-5), Fram storage (2-6), master-slave position detection (2-7), master-slave redundant communication interface (2-8), watchdog (2-9) constitute the kernel operation CPU unit, which is responsible for the operation of the control module control algorithm, network communication with the upper computer, and distribution and acquisition of I / O data, and conducts data interaction with the Linux - communication processing CPU (3-1);

[0184] 1), The DC5V to 3.3V, 3.3V to 1.2V (2-1) circuit provides power for the network interface circuit in various voltage ranges;

[0185] 2), The Ethernet (2-2) and Ethernet (2-3) circuits are three-speed adaptive Ethernet networks for communication between the control module and the upper computer;

[0186] 3), The Linux - kernel operation CPU (2-4) circuit is the minimum system for kernel data processing of the control module;

[0187] 4), The LED indicator (2-5) circuit is used to externally indicate the operating status of the control module system;

[0188] 5), The Fram storage (2-6) circuit is used to store system configuration data information;

[0189] 6), The master-slave position detection (2-7) circuit is used to identify the master-slave positions of the control modules in the redundant state, specifically, one control module is in the host state and the other is in the standby state;

[0190] 7), The master-slave redundant communication interface (2-8) circuit is used for data interaction between the master and standby control modules, and is a redundant configuration;

[0191] 8), The watchdog (2-9) circuit is used to diagnose that when the software of the Linux-kernel operation CPU crashes, the standby control module switches to the host state, and the host control module resets the system and switches to the standby state to ensure the continuity of the operation of the control module.

[0192] 3. I / O Communication Unit - CPU

[0193] The Linux-communication processing CPU (3-1), Ethernet (3-2), Ethernet (3-3), DC5V to 3.3V 3.3V to 1.2V (3-4), isolated DC5V circuit (3-5), extended CAN bus (3-6), extended CAN bus (3-7), CAN bus (3-8), CAN bus (3-9), watchdog (3-10) constitute the I / O communication unit, which is responsible for communicating with 64 local I / O modules and 7 groups of I / O expansion connection modules;

[0194] 1), The Linux-communication processing CPU (3-1) circuit is responsible for communicating with the Linux-kernel operation CPU (2-4) and completing the data forwarding of the I / O modules;

[0195] 2), The Ethernet (3-2) and Ethernet (3-3) circuits are used for network redundant communication with the extended I / O communication module;

[0196] 3), The DC5V to 3.3V 3.3V to 1.2V (3-4) and isolated DC5V circuit (3-5) circuits provide power supplies with various voltage ranges for the network interface and bus circuits;

[0197] 4), The extended CAN bus (3-6), extended CAN bus (3-7), CAN bus (3-8), CAN bus (3-9) circuits are redundant communication field bus transceiver circuits for local I / O modules, and both the acquisition part and the output part are redundant configurations;

[0198] 5), The watchdog (3-10) circuit is used to reset and restart after the software of the Linux-communication processing CPU crashes.

[0199] 4. This solution also designs:

[0200] The dual-port RAM (4-2) belongs to the dual-port RAM cache circuit and serves as a data interaction cache bridge between the Linux kernel operation CPU (2-4) and the Linux communication processing CPU (3-1), used for data reception and transmission caching to improve data stability.

[0201] The printing interface (4-1) is the output printing structure of the Linux kernel operation CPU (2-4), which outputs the data to be printed after calculation.

[0202] For each of the above circuits, users can specifically select the corresponding electronic circuits and chips such as the corresponding CPU according to the specific project, and this embodiment does not make any limitations.

[0203] For example, Figure 3 As shown in the IP address detection circuit (1-2), there are two 8-bit DIP switches on the base, corresponding to the two IO pin expansion chips PCF8574T (U14, U114) respectively. Each expanded IO pin has pull-up and pull-down resistors. Among them, the resistors R78, R79, R80, R88, R89, R90 of U14 and R178, R179, R180, R188, 189, 190 of U114 are the address selection resistors of the chips. After being selected and mounted according to the figure, the address of U14 is 000 and the address of U114 is 001. C165 and C265 are the filter capacitors of these two chips respectively, and R87 and R86 are the pull-up resistors of the I2C bus (I2C_ADD_SDA and I2C_ADD_SCL). These two chips convert the DIP switch address information on the base into an I2C signal and transmit it to the diagnostic unit, and the diagnostic unit then transmits this address information to the kernel operation unit through I2C.

[0204] Based on the DCS control module of the above solution, three CPU partitions are used to process data and signals.

[0205] These three CPUs are: the Linux kernel operation CPU (2-4), the Linux communication processing CPU (3-1), and the system diagnostic CPU (1-8). Each CPU is responsible for different functions:

[0206] The Linux kernel operation CPU (2-4) is responsible for executing the calculation and operation of kernel data.

[0207] The Linux communication processing CPU (3-1) is responsible for distributing and transmitting kernel data.

[0208] The system diagnostic CPU (1-8) is responsible for functions such as recording operation logs and fault logs.

[0209] Data exchange of the main control module (the control module of DCS) involves the following function blocks:

[0210] Initialization function block: Used to initialize each CPU of the main control module and ensure their normal operation.

[0211] Thread diagnosis function block: Used to monitor and diagnose the thread status and operation of each CPU to ensure their normal operation.

[0212] Data communication function block: Responsible for data exchange and communication between CPUs, including transferring data from the Linux - kernel operation CPU (2 - 4) to the Linux - communication processing CPU (3 - 1).

[0213] Redundancy switching function block: Used to implement the switch between the primary and standby machines. When the switching condition is met, perform the primary - standby switching operation and record the relevant operation logs.

[0214] The specific interaction will be described in Embodiment 2.

[0215] For the I / O expansion interface, reference can be made to CN218957060U "A 32 - channel digital input module applied to the DCS system" applied by the applicant.

[0216] The Linux - communication processing CPU (3 - 1) can use an FPGA chip to implement the dual - port RAM communication function inside the FPGA, replacing part of the circuit of the dual - port RAM (4 - 2), which can reduce the hardware cost.

[0217] Obviously, those skilled in the art should understand that to implement all or part of the processes in the above - mentioned embodiments, it can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer - readable storage medium. When the program is executed, it can include the processes of the above - mentioned control embodiments. Those skilled in the art can understand that to implement all or part of the processes in the above - mentioned embodiments, it can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer - readable storage medium. When the program is executed, it can include the processes of the above - mentioned control embodiments. Among them, the storage medium can be a magnetic disk, an optical disk, a Read - Only Memory (ROM), a Random Access Memory (RAM), a Flash Memory, a Hard Disk Drive (abbreviation: HDD), or a Solid - State Drive (SSD), etc.; the storage medium can also include a combination of the above - mentioned types of memories.

[0218] Embodiment 2

[0219] Based on the implementation principle of Embodiment 1, on the other hand, the present application proposes a method for allocating and calculating DCS system data based on a multi-task CPU, including the following steps:

[0220] System initialization: The Linux - kernel operation CPU 2 - 4 sends an instruction to the system diagnosis CPU 1 - 8, requesting to read the IP address information; after receiving the instruction, the system diagnosis CPU 1 - 8 reads the hardware DIP switch and sends the IP address information back to the Linux - kernel operation CPU 2 - 4 as response data; the Linux - kernel operation CPU 2 - 4 parses the response data to complete the initialization of the device;

[0221] Thread diagnosis: When the Linux - kernel operation CPU 2 - 4 and the Linux - communication processing CPU 3 - 1 are running, their respective sub - threads send pulse signals to the system diagnosis CPU 1 - 8 through controlling GPIO at regular intervals; the system diagnosis CPU 1 - 8 detects the pulse signals. If a certain thread's pulse signal has not been received for a long time, the thread will be marked as faulty, and the corresponding thread's fault and operation logs will be generated;

[0222] Data communication: Among the Linux - kernel operation CPU 2 - 4, the Linux - communication processing CPU 3 - 1 and the system diagnosis CPU 1 - 8, communication interface diagnosis, kernel data output and kernel data input are carried out according to a preset program;

[0223] Redundancy switching: The Linux - kernel operation CPU 2 - 4 sequentially detects the diagnosis of the master - slave interface, judges whether the master - slave switching condition is met according to the diagnosis of the master - slave interface. If it is met, the master - slave switching action will be executed; otherwise, it will be abandoned.

[0224] Specifically,

[0225] 1. System initialization

[0226] As Figure 4 shown, in the initialization function block processing, the Linux - kernel operation CPU (2 - 4) sends an instruction to the system diagnosis (CPU) (1 - 8) through the I2C interface, requesting to read the IP address information. After receiving the instruction, the system diagnosis (CPU) (1 - 8) reads the hardware DIP switch and sends the IP address information back to the Linux - kernel operation CPU (2 - 4) as response data. After the Linux - kernel operation CPU (2 - 4) parses the response information, the initialization process of the device is completed. Once the device initialization is completed, the Linux - kernel operation CPU (2 - 4) sends the information of "start - up completed operation log" to the system diagnosis (CPU) (1 - 8) through the serial port. The system diagnosis (CPU) (1 - 8) parses this information and stores it.

[0227] 2. Thread Diagnosis

[0228] As Figure 5 shown, during the processing of the thread diagnosis function block, when the Linux - kernel operation CPU (2 - 4) and the Linux - communication processing CPU (3 - 1) are running, their respective sub - threads send pulse information to the system diagnosis (CPU) (1 - 8) at regular intervals through the control of GPIO. The system diagnosis (CPU) (1 - 8) will detect these pulse signals. If a pulse signal from a certain thread is not received for a long time, that thread will be marked as faulty, and a thread fault log will be generated.

[0229] 3. Data Communication

[0230] As Figure 6 、 7 and Figure 8 show, during the data communication processing, it can be generally divided into three function blocks, including: communication interface diagnosis, kernel data output, and kernel data input.

[0231] During the communication interface diagnosis processing, the Linux - kernel operation CPU (2 - 4) reads the network status of the system at regular intervals. If the network is disconnected, the Linux - kernel operation CPU (2 - 4) will send the information of "network fault log" to the system diagnosis (CPU) (1 - 8) through the serial port. The system diagnosis (CPU) (1 - 8) will parse this information and store it. In addition, the Linux - communication processing CPU (3 - 1) also reads the CAN error count and the network status of the system at regular intervals. If the CAN error count exceeds 255, it will mark the CAN communication as faulty. If the network is disconnected, it will mark the network as faulty. The Linux - communication processing CPU (3 - 1) will report the data of "fault information" to the Linux - kernel operation CPU (2 - 4) at regular intervals. When the Linux - kernel operation CPU (2 - 4) parses that the fault information of the Linux - communication processing CPU (3 - 1) has changed, it will send the instruction of "Linux - communication processing CPU (3 - 1) fault information" to the system diagnosis (CPU) (1 - 8) through the serial port. The system diagnosis (CPU) (1 - 8) will parse this information and generate a network fault log or a CAN fault log according to the situation and store it.

[0232] In the processing of kernel data output, the Linux - kernel operation CPU (2 - 4) modifies the output data. It periodically sends the assembled data packets to the Linux - communication processing CPU (3 - 1) via the dual - port RAM, and at the same time determines whether the transmission via the dual - port RAM is successful. If the transmission fails, the dual - port RAM is marked as faulty. If the transmission is successful, it waits for the response result returned by the Linux - communication processing CPU (3 - 1). If the response result waiting times out, the dual - port RAM is marked as faulty. When the dual - port RAM is marked as faulty, the Linux - kernel operation CPU (2 - 4) sends the information of "dual - port RAM fault log" to the system diagnosis (CPU) (1 - 8) via the serial port. The system diagnosis (CPU) (1 - 8) parses this information and stores it. When the Linux - communication processing CPU (3 - 1) receives the "output data" instruction, it parses the data. If it is local data, it assembles it into a CAN communication data frame, sends the data to the IO module via the CAN bus, and returns a response message to the Linux - kernel operation CPU (2 - 4). If it is not local data, it forwards the data to the IO expansion module via the network and returns a response message to the Linux - kernel operation CPU (2 - 4).

[0233] In the processing of kernel data input, the Linux - communication processing CPU (3 - 1) receives input data via the network interface or the CAN bus. It packets the data and sends it to the Linux - kernel operation CPU (2 - 4) via the dual - port RAM, and at the same time determines whether the transmission via the dual - port RAM is successful. If the transmission fails, the dual - port RAM is marked as faulty. If the transmission is successful, it waits for the response result returned by the Linux - kernel operation CPU (2 - 4). If the response result waiting times out, the dual - port RAM is marked as faulty. When the Linux - kernel operation CPU (2 - 4) receives the "input data" instruction, it parses the data and writes the data into the kernel input data area.

[0234] 4. Redundancy switching, redundant communication

[0235] Such as Figure 9As shown in the figure, during the processing of the redundant switching function block, the Linux-kernel operation CPU (2-4) will sequentially detect the installation status and communication status (USB communication status / 485 communication status / pulse GPIO status) of the standby machine. If it is found that the standby machine is not installed, the Linux-kernel operation CPU (2-4) will send the information of "standby machine offline fault log" to the system diagnosis (CPU) (1-8) through the serial port. The system diagnosis (CPU) (1-8) will parse this information and store it. When the communication status (USB communication status / 485 communication status / pulse GPIO status) changes, the Linux-kernel operation CPU (2-4) will send the information of "redundant communication fault log" to the system diagnosis (CPU) (1-8) through the serial port. The system diagnosis (CPU) (1-8) will parse this information and store it. The Linux-kernel operation CPU (2-4) will compare the diagnosis situations of the main-standby machine interfaces. If the main-standby switching conditions are met, it will perform the main-standby switching action and send the information of "main-standby switching operation log" to the system diagnosis (CPU) (1-8) through the serial port. The system diagnosis (CPU) (1-8) will parse this information and store it.

[0236] Adopting the above solution can achieve:

[0237] 1. Avoid the occurrence of "shutdown events" caused by non-hardware faults in the DCS system and improve the stability of the system;

[0238] 2. An independent diagnosis solution can monitor the operation of each hardware circuit and software of the monitoring and control module and send it to the computer in the control room of the control station for viewing and alarming. On-site personnel can view and process it in the first time to avoid accidents;

[0239] 3. The 3 CPUs work together and process tasks in partitions, which can reduce the operating load of a single CPU. Even if a single CPU fails, it will not affect the work of other parts, improving the computing power and stability of the DCS system control module;

[0240] 4. The control module directly designs a local I / O communication field bus circuit, which can directly communicate with 64 local I / O modules in combination with software, reducing the market usage cost. At the same time, since intermediate product components are saved, the risk of bus communication faults is indirectly reduced, which is beneficial to low-cost and low-risk bus communication in on-site usage scenarios within 64 I / O modules.

[0241] Each module or step of the present invention described above can be implemented by a general-purpose computing system. They can be centralized on a single computing system or distributed over a network composed of multiple computing systems. Optionally, they can be implemented by program code executable by the computing system. Thus, they can be stored in the storage system for execution by the computing system, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the present invention is not limited to any specific combination of hardware and software.

[0242] Embodiment 3

[0243] As Figure 10 shown, further, on the other hand, the present application also proposes an electronic device, including:

[0244] A processor;

[0245] A memory for storing instructions executable by the processor;

[0246] Wherein, the processor is configured to implement the method for allocating and calculating DCS system data based on a multi-task CPU when executing the executable instructions.

[0247] The electronic device according to the embodiments of the present disclosure includes a processor and a memory for storing instructions executable by the processor. Wherein, the processor is configured to implement the method for allocating and calculating DCS system data based on a multi-task CPU as described above when executing the executable instructions.

[0248] Here, it should be noted that the number of processors can be one or more. At the same time, in the electronic device according to the embodiments of the present disclosure, an input system and an output system can also be included. Wherein, the processor, the memory, the input system and the output system can be connected through a bus or in other ways, which is not specifically limited herein.

[0249] The memory, as a computer-readable storage medium, can be used to store software programs, computer-executable programs and various modules, such as: the programs or modules corresponding to the control method in Embodiment 2 of the present disclosure. The processor executes various functional applications and data processing of the electronic device by running the software programs or modules stored in the memory.

[0250] The input system can be used to receive input numbers or signals. Among them, the signal can be a key signal related to the user settings and function control of the device / terminal / server. The output system can include a display device such as a display screen.

[0251] The embodiments of the present disclosure have been described above. The above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The choice of terms used herein is intended to best explain the principles of the embodiments, practical applications, or technical improvements to the technologies in the market, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A DCS system data distribution and calculation system based on a multi-task CPU, characterized in that: include: The kernel computing CPU unit, based on Linux - the kernel computing CPU (2-4), is responsible for performing calculations and operations on kernel data; I / O communication unit, based on Linux--communication processing CPU (3-1), is responsible for distributing and transmitting kernel data; The diagnostic unit, which is pre-deployed in the system diagnostic CPU (1-8), is responsible for completing the intelligent software and hardware diagnosis of the DCS control module and outputting the control strategy, while recording the AI ​​diagnostic operation and fault log; The core operation CPU unit, the I / O communication unit and the diagnosis unit are connected to each other for communication, and the core operation CPU unit is connected to the host computer for communication.

2. A DCS system data distribution and calculation system based on a multi-task CPU according to claim 1, characterized in that: The method for constructing the DCS intelligent diagnosis model comprises: Collect and pre-process historical diagnostic big data of DCS system; Performing feature engineering on the historical diagnostic big data, extracting corresponding historical diagnostic test data and corresponding historical control strategies, and constructing corresponding feature sets; Inputting the feature set into a preset RF model, performing feature matching training and learning, and training and generating the DCS intelligent diagnosis model; Collect the real-time diagnostic data of the DCS system as a validation set and perform performance verification on the DCS intelligent diagnostic model generated by training: If the verification is successful, the DCS intelligent diagnosis model is deployed in the system diagnosis CPU (1-8); If the verification fails, repeat the above steps to rebuild the DCS intelligent diagnosis model.

3. The DCS system data distribution and calculation system based on multi-task CPU according to claim 1 is characterized in that: The core computing CPU unit comprises: DC5V to 3.3V and 3.3V to 1.2V circuits (2-1) are used to provide power supplies of various voltage ranges for the network port circuit; Ethernet (2-2) and Ethernet (2-3), used to provide an Ethernet network for communication between the control module and the host computer; Linux--kernel computing CPU (2-4), used for kernel data processing; LED indicator circuit (2-5), used to externally indicate the operating status of the control module system; Fram memory (2-6), used to store system configuration data information; A master-slave position detection circuit (2-7) is used to identify the master-slave position of the control module in a redundant state, specifically one of the control modules is in a master state and the other is in a standby state; Active / standby redundant communication interface (2-8), used for data interaction between active and standby machines of the control module, for redundant configuration; The watchdog circuit (2-9) is used to switch the standby control module to the host state after the diagnosis unit detects that the Linux kernel operation CPU has a software crash, and the host control module resets the system to switch to the standby state to ensure the continuity of the control module operation; The Ethernet (2-2) and the Ethernet (2-3) are electrically connected to the DC5V to 3.3V and 3.3V to 1.2V circuits (2-1) respectively; The Ethernet (2-2), Ethernet (2-3), LED indicator circuit (2-5), Fram memory (2-6), master-slave position detection circuit (2-7), master-slave redundant communication interface (2-8) and watchdog circuit (2-9) are electrically connected to the Linux kernel operation CPU (2-4) respectively.

4. The DCS system data distribution and calculation system based on multi-task CPU according to claim 1 is characterized in that: The I / O communication unit comprises: Linux--communication processing CPU (3-1), responsible for communicating with Linux--kernel operation CPU (2-4) and completing data forwarding of I / O modules; Ethernet (3-2) and Ethernet (3-3), respectively used for network redundant communication with the extended I / O communication module; The DC5V to 3.3V and 3.3V to 1.2V circuits (3-4) and the isolated DC5V circuit (3-5) provide power supplies of various voltage ranges for the network port and bus circuits; The extended CAN bus (3-6), the extended CAN bus (3-7), the CAN bus (3-8), and the CAN bus (3-9) are respectively redundant communication field bus transceiver circuits of the local I / O module, and their acquisition and output are both redundant configuration structures; Watchdog circuit (3-10), used for Linux--communication processing CPU reset and restart after software crash; The DC5V to 3.3V and 3.3V to 1.2V circuits (3-4), the extended CAN bus (3-6), the extended CAN bus (3-7), the CAN bus (3-8), the CAN bus (3-9) and the watchdog circuit (3-10) are electrically connected to the Linux-communication processing CPU (3-1) respectively.

5. The DCS system data distribution and calculation system based on multi-task CPU according to claim 1 is characterized in that: The diagnostic unit comprises: A power failure detection circuit (1-1) is used to detect power failure of the DC24V power supply of the control module; The IP address detection circuit (1-2) is used to identify the physical IP address code of the control module hardware and set the network IP address of the control module by dialing; Watchdog circuit (1-3) is used for system diagnosis and resetting and restarting after CPU (1-8) software crashes; The second pulse circuit (1-4) is used to read the external second pulse signal, transmit it to the Linux-kernel operation CPU (2-4) and use it for system time calibration; RS485 circuit (1-5) is used to collect data information from external devices in the control cabinet; SD card memory (1-6), used to store log information of control module operation; DC24V to 5V power supply (1-7), used to provide DC5V power supply for the control module; System diagnosis CPU (1-8), responsible for completing the intelligent diagnosis of the software and hardware of the DCS control module and outputting the control strategy, while recording the AI ​​diagnosis operation and fault log; RTC power supply (1-9), used for power supply control of DC24V to 5V power supply (1-7); The power-off detection circuit (1-1), the IP address detection circuit (1-2), the watchdog circuit (1-3), the second pulse circuit (1-4), the RS485 circuit (1-5), the SD card memory (1-6), the DC24V to 5V power supply (1-7), the system diagnosis CPU (1-8) and the RTC power supply (1-9) are electrically connected to the system diagnosis CPU (1-8), respectively.

6. The DCS system data distribution and calculation system based on multi-task CPU according to claim 1 is characterized in that: Also includes: The dual-port RAM (4-2) is used for data transmission and reception buffering and is connected between the Linux-kernel operation CPU (2-4) and the Linux-communication processing CPU (3-1).

7. The DCS system data distribution and calculation system based on multi-task CPU according to claim 1 is characterized in that: Also includes: The printing interface (4-1) is used for printing the printing data output by the Linux-kernel operation CPU (2-4) and the Linux-communication processing CPU (3-1), and is connected between the Linux-kernel operation CPU (2-4) and the Linux-communication processing CPU (3-1).

8. A method for calculating the distribution of DCS system data based on a multi-task CPU, characterized in that: The steps include: System initialization: The Linux-kernel operation CPU (2-4) sends a command to the system diagnosis CPU (1-8) to request to read the IP address information; after receiving the command, the system diagnosis CPU (1-8) reads the hardware dial code and sends the IP address information back to the Linux-kernel operation CPU (2-4) as response data; the Linux-kernel operation CPU (2-4) parses the response data to complete the initialization of the device; Thread diagnosis: When the Linux--kernel operation CPU (2-4) and the Linux--communication processing CPU (3-1) are running, their respective sub-threads control the GPIO timing to send pulse signals to the system diagnosis CPU (1-8); the system diagnosis CPU (1-8) detects the pulse signals, and if it does not receive the pulse signal sent by a thread for a long time, it will mark the thread as a fault and generate the fault and operation log of the corresponding thread; Data communication: between the Linux-kernel operation CPU (2-4), the Linux-communication processing CPU (3-1) and the system diagnosis CPU (1-8), communication interface diagnosis, kernel data output and kernel data input are performed according to a preset program; Redundant switching: Linux--kernel operation CPU (2-4) detects the diagnosis status of the master-slave interface in turn, and determines whether the master-slave switching conditions are met based on the diagnosis status of the master-slave interface. If so, the master-slave switching action will be executed, otherwise it will be abandoned.

9. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; Wherein, the processor is configured to implement the DCS system data distribution calculation method based on a multi-tasking CPU as described in claim 8 when executing the executable instructions.

Images