CN111026792A

CN111026792A - Message-driven key process holographic tracing method and system

Info

Publication number: CN111026792A
Application number: CN201911064701.0A
Authority: CN
Inventors: 陈天皓
Original assignee: Nanjing Sifang Epower Electric Power Automation Co ltd
Current assignee: Nanjing Sifang Epower Electric Power Automation Co ltd
Priority date: 2019-11-04
Filing date: 2019-11-04
Publication date: 2020-04-17

Abstract

The invention discloses a message-driven key process holographic tracing method and system, relates to a technology for tracing a key process based on an SCADA (supervisory control and data acquisition) system, and belongs to the technical field of calculation, calculation or counting. The tracing method records the global data section before the start of the key process, all data input of the system and all data exchange in the system before the termination after the start of the key process, realizes the tracing operation environment completely consistent with the real-time production environment through message driving, and can also realize the process tracing under the condition of adding the logic operation of newly increased input quantity or adjusted input quantity into the position. The system consists of three relatively independent main parts, namely a process recording module, a process tracing module and a time axis engine, wherein the process recording module extracts and stores data from a production environment, the process tracing module reproduces the reproduced key process scene in a virtual environment according to the stored data, and the time axis engine realizes the driving and the progress control of the tracing process.

Description

Message-driven key process holographic tracing method and system

Technical Field

The invention discloses a message-driven key process holographic tracing method and system, relates to a technology for tracing a key process based on an SCADA (supervisory control and data acquisition) system, and belongs to the technical field of calculation, calculation or counting.

Background

The continuous deep requirements of computer technology And automation technology on a Data Acquisition And monitoring Control (SCADA) system in various industries are not limited to the current running conditions of monitoring equipment, production lines And systems, but also require recording And storing panoramic Data in a period of time before And after some key time, And all events occurring in the period of time are traced And rewound again in a virtual environment afterwards, so that the function of 'time light backflow' is realized, And simulation intervention And result observation for positioning faults, researching accident reasons, optimizing processes, adjusting running processes And developing simulation training in the virtual environment can be performed in the tracing process.

The main components of the main SCADA system in the industrial control field are as follows: communication middleware (MSG _ BUS), a relational database system (DBMS), a real-time database based on a memory (RTDB), an INPUT quantity (digital quantity/analog quantity) processing service (INPUT _ SERV), a real-time ALARM service (ALARM _ SERV) and the like. When the system is running, the input message is transmitted to the input quantity processing service through the communication middleware, the input quantity processing service accesses the result into the real-time database after logical operation and transmits the information needing alarming to the real-time alarming service through the communication middleware, and the real-time alarming service sends out the alarming and writes the alarming into the relational database system. The key process tracing system is designed and implemented based on the basic support function of the above components, and the architecture thereof is shown in fig. 1.

In the existing SCADA system, the key process tracing is mostly realized by the following two ways: 1. calling a historical data recording file stored in the remote equipment, and arranging and graphically displaying the fault information recorded in the file according to the sequence by analyzing the data waveform in the file to achieve the tracing purpose; 2. and storing the real-time processing result in the system operation stage, and taking out the processing result from the storage medium according to the time sequence and carrying out graphical display when the tracing is needed, thereby realizing the tracing function. The first common key process tracing method relies on reading data from external equipment, the second common key process tracing method can only simply read recorded data and visual historical key processes, and the two common key process tracing methods cannot deduce modified processes and results under the condition of analog intervention, so that higher-level applications such as training simulation and the like are difficult to expand.

Disclosure of Invention

The invention aims to provide a message-driven holographic tracing method and a message-driven holographic tracing system for a key process, which aim to overcome the defects of the prior art, realize the holographic tracing of the key process caused by the same operational logic through messages generated during the operation of the system, and solve the technical problem that the existing key process tracing method depends on external input data and can not deduce the modified process and result under the condition of simulation intervention.

The invention adopts the following technical scheme for realizing the aim of the invention:

a message-driven key process holographic tracing method comprises the following two parts:

recording holographic data of the critical process: extracting and storing system model data in the production environment, recording a global data section before a key process starts in the production environment, all input data of a system before termination after the key process starts, and all data exchange generated in the system before termination after the key process starts, and encapsulating all system input data and all system internal exchange data before termination after the key process starts into a message packet;

after analyzing the message packet of the key process to be traced, tracing the key process based on the system model before the key process to be traced: caching a system model file before the start of a key process to be traced in a real-time database, loading a global data section before the start of the key process to be traced to an analyzed system model, caching system input data and system internal exchange data before the start and the termination of the key process to be traced and related item records read from a relational database according to the time sequence of message packet generation and event occurrence, sending the cached system input data and system internal exchange data before the start and the termination of the key process to be traced according to the time sequence to realize the tracing of the key process, and pushing the related item records to finish warning according to the time sequence.

Further, in a message-driven holographic tracing method for key processes, the recording of holographic data for key processes is enabled based on schedule triggering, based on specific event triggering, or based on manual operation behavior.

Further, in the holographic tracing method for the key process driven by the message, in the event of tracing the key process based on the system model before the key process to be traced after the message packet of the key process to be traced is analyzed, the added input quantity of the key process to be traced is cached according to the time sequence of the generation of the message packet and the occurrence of the event, and the added input quantity is adjusted to be added to the position of the logical operation process.

Further, in the message-driven holographic tracing method for the key process, description information of holographic data of the key process, the corresponding relation between the description information and a message packet, and alarm information in the key process are cached in a relational database.

A message-driven holographic tracing system for critical processes, comprising:

the key process recording module is used for extracting and storing system model data in the production environment, recording a global data section before the key process starts in the production environment, all input data of a system before the key process starts and is terminated, and all data exchange generated in the system before the key process starts and is terminated, and packaging all system input data and system internal exchange data before the key process starts and is terminated into a message packet;

the process tracing module caches a system model file before the start of the key process to be traced in a real-time database, loads a global data section before the start of the key process to be traced to an analyzed system model, caches system input data and system internal exchange data before the start and the end of the key process to be traced and relevant event records read from a relational database according to the time sequence of message packet generation and event occurrence, sends the cached system input data and system internal exchange data before the start and the end of the key process to be traced according to the time sequence so as to realize the tracing of the key process, and pushes the relevant event records to finish warning according to the time sequence; and a process for the preparation of a coating,

and the time axis engine is used for providing a basic clock for the key process recording module and the process tracing module.

Further, in the message-driven key process holographic tracing system, the process tracing module realizes fast playing, slow playing, single step and continuous operation of a tracing process through a time axis engine.

Further, in a message-driven holographic tracing system for critical processes, a timeline engine is integrated in a process tracing module.

By adopting the technical scheme, the invention has the following beneficial effects: compared with the traditional implementation mode, the input information used in the method is recorded and stored in the real-time operation of the system, various special files are not generated by external equipment during tracing, a method for simply reading and displaying historical results is abandoned in the tracing process, the key process is calculated again by adopting the same input conditions and operation logic, when the input conditions and the operation logic are completely the same as the previous conditions, all phenomena can be accurately reproduced, and the models and the operation logic of the tracing operation environment and the real-time production environment are completely consistent, completely isolated and not interfered with each other; on the other hand, new input can be added or the position of the new input added in the operation process can be adjusted when needed, so that the tracing process is more flexible, and a foundation is laid for the implementation of advanced applications such as process optimization, operation flow adjustment, simulation training development and the like.

Drawings

Fig. 1 is a diagram of the basic support function architecture of the process traceability system.

Fig. 2 is a schematic diagram of the work flow of CASE _ SERV and related modules.

Fig. 3 is a schematic flowchart of the PDR _ SERV and related modules.

FIG. 4 is a FSM state transition diagram for PDR _ SERV.

Detailed Description

The technical scheme of the invention is explained in detail in the following with reference to the attached drawings.

The application defines key process holographic data comprising:

(1) global data section before the start of the critical process, comprising: a system model at a particular time and all steady state run time data based on the then-current model.

(2) All data inputs of the system before termination after the start of the key process, for example: collecting various digital quantity and analog quantity collection values of the monitored object, collecting alarms of equipment and a communication system and the like.

(3) All data exchanges that take place inside the system before the critical process starts are terminated, for example: the system processes and processes the acquired value, controls and feeds back, diagnoses and alarms.

The key process record starting mode defined by the application comprises the following steps:

(1) starting at a predefined specific time based on a schedule;

(2) triggering an initiation based on a particular event, e.g., a specified accident or fault signal;

(3) the start is based on manual action, e.g. clicking a start button.

The key process tracing operation modes defined by the application comprise the following three modes:

(1) the tracing environment is completely consistent with the real-time production environment, is completely isolated and does not interfere with each other;

(2) the method supports the processes (fast playing, slow playing, single step and continuous) for controlling the tracing and can suspend the ongoing process tracing;

(3) the system model of the operational environment should match the model of the recording time.

The key process holographic tracing system consists of three relatively independent main parts, namely a process recording module (CASE _ SERV), a process tracing module (PDR _ SERV) and a Time Axis Engine (TAE).

The CASE _ SERV runs in a production environment, and has the main function of periodically extracting and storing system model data from the RTDB to form a system model file; storing runtime data before the key process starts as required to form a runtime data profile file; the input data and the internal exchange data of the system are captured and stored in a rolling mode from the MSG _ BUS in real time, and when the process end time is reached, the data in the last period of time (namely the time between the start and the end of the key process) is intercepted, and a message file is formed. The CASE _ SERV packs and numbers files belonging to the same key process, and the packed file pack is called CASE. The description of each key process and its correspondence to CASE is stored in the DBMS.

The PDR _ SERV has the main function of reproducing the stored key process in the virtual environment, determining the serial number of the key process according to the key process description needing to be traced, and further retrieving the related CASE for unpacking. Analyzing the model file and recovering the system model before the key process starts in an independent area in the RTDB; analyzing the operation section file, and additionally updating the obtained operation data to a system model before the start of a key process in the RTDB; then, analyzing the message file, and caching system input data and internal exchange data for later use according to the time sequence of message generation and event occurrence; and finally, reading the related item records in the key process time period from the DBMS, and caching for standby according to time sequencing.

The TAE is a core component of the PDR _ SERV, and the main function is to provide time service for all application programs in the virtual environment, namely all programs in the virtual environment acquire the system 'current time' from the timeline engine. In effect the timeline engine is the basic system clock that controls the callback, pause of time, and speed control of the passage of time during the critical process time period. When backtracking begins, the clock is dialed back to the moment when the key process begins and the engine is started, starting the process of production and consumption based on the message: over time, the PDR _ SERV simulates the message producer in the production environment, converts the INPUT data and internal exchange numbers in the cache into messages according to time and publishes the messages to the MSG _ BUS, and the associated message consumers (e.g., INPUT _ SERV and ALARM _ SERV) consume the subscribed messages from the MSG _ BUS to perform subsequent processing. For the event records in the cache, the PDR _ SERV sends the event records to the ALARM _ SERV according to time to complete the ALARM push presentation, and for some specific types of operation type events (other logic not associated with the message packet), it is also necessary to add input according to the specific content of the events, and simulate the operation logic in the production environment to perform the matching processing (for example, modify the operation data in the RTDB).

1. At the start of the trace back, the system initializes a virtual environment in which: and the PDR _ SERV sends the message files recorded by the CASE _ SERV one by one according to the time progress of the TAE, and the INPUT _ SERV and the ALARM _ SERV are executed according to normal operation logic. After the message reaches the INPUT _ SERV and ALARM _ SERV through the MSG _ BUS, all the operation logic is the same as the real-time operation. Process recording module (CASE _ SERV)

1) Content of process trace back records

The CASE _ SERV is a background program for storing all data related to key processes in the system, and the recorded time range can be set to be a specified time, a specified accident or fault signal generation, M seconds before a start button is manually clicked and N seconds after the start button is manually clicked (M and N can be configured). The stored data can be classified into the following 4 categories.

Model data: the system periodically checks the RTDB model data change mark, and if the real-time model is detected to be changed, the model data section is extracted and compressed and stored as an RTDB _ case file.

And (3) graphic data: because the basic SCADA system integrates SVN service, and each version of the graphic file is subjected to version management, the graphic data does not need to be stored additionally, and only the version number of the graphic at the key moment needs to be recorded.

Initial runtime data section: and extracting the state values of all the devices M seconds before the key moment by adopting a cache mechanism, and compressing and storing the device IDs and the state values into rhdb _ case files in a one-to-one correspondence manner.

Data input and data exchange messages: messages (various digital quantity and analog quantity acquisition values of a target monitoring object, state changes of acquisition equipment and a communication system) received from an external interface of the SCADA system are divided into a full data message and a changed data message, and the CASE _ SERV only captures the changed messages; the internal data exchange of the system relates to rich message types, the CASE-SERV only captures source messages associated with services, and various intermediate messages and service-independent messages are not processed. In a production environment, a CASE _ SERV actually captures messages at every moment and stores the messages in a limited temporary queue with enough size in sequence, and when N seconds arrive after a critical moment, data at the tail of the queue (from M seconds before the critical moment to N seconds after the critical moment) is taken out and compressed to be stored as an msg _ CASE file.

Finally, all the generated files are packaged into a CASE and stored in a file server, and the CASE number, the version number of the graphic file and other information related to the CASE are written into a CASE information table of the DBMS. In the process of creating a CASE, a CASE _ SERV is required to be coordinated with a series of related basic support functions, and the work flow is shown in fig. 2.

2) Conditions for process record triggering

The process records adopt a message triggering mechanism, namely, a CASE _ SERV subscribes a message subject (TOPIC _ CASE _ CREATE) to an MSG _ BUS, and each time a message of the subject is received, the collection, extraction and storage of relevant data in the background are started.

And (3) triggering a time schedule: a schedule is written by a timed task management service within the production system. When a particular time on the schedule is reached, the system background will send a TOPIC _ CASE _ CREATE message.

Triggering of manual operation action: the maintenance interface of the CASE information reads information such as name, occurrence time, graphic version number, file number, etc. of each CASE from the DBMS. A button for manually triggering CASE is also provided. When the operator clicks this button, the human interface framework sends a TOPIC _ CASE _ CREATE message.

Accident and fault signal triggering: when the monitoring or protection program of a specific function of the production system determines that an accident occurs, the corresponding program directly sends a TOPIC _ CASE _ CREATE message.

2. Process tracing module (PDR _ SERV)

The PDR _ SERV uses the data stored in the CASE and DBMS to reproduce the critical processes in the virtual environment at the current time and operator's actions. The TAE is integrated in the PDR _ SERV as a core component and drives the PDR _ SERV to run. The PDR _ SERV is composed of a PDR console component, a CASE matching component, a scene recovery component, a progress control component, a time axis engine component (TAE) and the like. In the tracing process, a series of related basic support functions need to be coordinated and matched, the work flow of the tracing process is shown in fig. 3, and the PDR clock realizes the function of TAE.

1) PDR control console

The PDR console is an interface program, screens and filters CASE needing to be traced, and controls the progress in the tracing process. After a PDR console interface is called out, the system automatically switches the RTDB to a data area corresponding to the virtual environment; and after the PDR console interface is closed, the system automatically switches the RTDB back to the data area corresponding to the production environment. The PDS console can select the CASE to be traced, supports self-adjustment of the time interval within the time period of CASE recording, and can set pause, recovery, automatic playing speed and manual single-step playing step length. After a CASE is selected, the PDR console sends a trace back starting message to a background service of the PDR _ SERV through the MSG _ BUS, wherein the message contains a CASE file number.

2) Tracing workflow

After receiving the starting message, the background service of the PDR _ SERV searches all information of the CASE including the version number of the corresponding graphic file from the DBMS according to the number of the CASE file. Then, taking out a corresponding CASE file package from the file server and exporting a corresponding graphic file from the SVN server; and deploying the CASE file package at a server end, and deploying the graphic file at a workstation end.

Next PDR _ SERV attempts to restore the system environment M seconds before the critical time: the parsed RTDB _ case file content is imported into the RTDB through the import function of the RTDB to restore the system model at that time. And then, updating the content of the parsed rhdb _ case file into the RTDB item by item according to the device ID through an updating function of the RTDB to restore the current state of all devices. And then, msg _ case is analyzed, relevant matters are read from the DBMS, and the analyzed content is stored and stored in a temporary cache according to time sequence. Then according to the time lapse condition of the TAE, sending the message messages to the INPUT _ SERV according to the time sequence, and driving the INPUT _ SERV to run as the key process occurs; and sending the system and operation type events to ALARM _ SERV to realize ALARM pushing.

3) State switching for background services of PDR _ SERV

The basic design idea of the PDR _ SERV background service is a Mealy Finite State Machine (FSM), which consists of 4 states, respectively "initialization", "loadable", "playable" and "playing". After the PDR _ SERV background service program is started, entering an 'initialization' state; entering a 'loadable' state after initialization is completed; after receiving a starting message of a PDR console, performing CASE matching, exporting, model and initial state recovery and the like on a PDR _ SERV background service, and entering a playable state after all the work is finished; after receiving the play message of the PDR console, entering a 'playing' state; in the 'playing' state, the inversion speed, the continuous inversion, the single-step inversion and the pause inversion can be adjusted; and after the inversion is finished, the 'loadable' state is entered again. The state transition diagram is shown in fig. 4.

Claims

1. A message-driven holographic tracing method of key processes is characterized in that,

2. The message-driven holographic tracing method for key processes, according to claim 1, wherein the recording of the holographic data for key processes is enabled based on a schedule trigger, a specific event trigger, or a manual operation behavior.

3. The holographic tracing method of the key process driven by the message according to claim 1, characterized in that, in the event of tracing the key process based on the system model before the key process to be traced after analyzing the message packet of the key process to be traced, the added input quantity of the key process to be traced is cached and the added input quantity is adjusted to be added to the position of the logical operation process according to the time sequence of the generation of the message packet and the occurrence of the event.

4. The message-driven holographic key process tracing method of claim 1, wherein the description information of the holographic data of the key process and the corresponding relationship between the holographic data of the key process and the message packet, and the alarm information in the key process are cached in a relational database.

5. A message-driven holographic traceability system of critical processes, comprising:

6. The holographic tracing system of claim 5, wherein said process tracing module implements fast playback, slow playback, single step, continuous operation of tracing process through a timeline engine.

7. The message driven critical process holographic traceability system of claim 5, wherein the timeline engine is integrated into the process traceability module.