A concurrent testing method and system for protocols and interrupt programs in an industrial control system

Abstract

The application discloses a kind of concurrent test method and system of protocol and interrupt procedure in industrial control system, belong to software testing and software reliability field.The application is directed to the problem that potential data race in interrupt-driven embedded software is difficult to accurately identify, proposes to record events by program insertion, generate original execution sequence, and obtain filtered sequence after filtering irrelevant events, construct event sequence that can trigger data race in combination with interrupt information;By determining the necessary event set and the necessary partial order set, the partial order relationship between events is established based on directed graph and closure calculation is carried out, to judge whether data race really occurs.The application can accurately capture interrupt-related synchronization information, efficiently detect potential data race, and significantly improve the accuracy and reliability of concurrent testing of industrial control system software.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of software testing and software reliability, and particularly relates to a concurrent testing method for protocols and interrupt programs in an industrial control system. BACKGROUND

[0002] Industrial control systems are widely used in aerospace, automotive electronics, medical electronics and other fields, and these fields have very high requirements for the safety and stability of the system. Protocols, interrupt drivers and the like in the industrial control system respond to external or internal data and signals to process system tasks in real time. Interrupt drivers use a large amount of shared data to realize communication and data interaction between the main task and the interrupt and between different interrupts. However, due to the uncertainty of the protocols and interrupt drivers, various concurrent vulnerabilities and the like problems are often caused, such as data race, atomicity violation and deadlock. Such problems are difficult to detect and locate. Data race, as one of the most common concurrent errors, often occurs when multiple concurrent execution flows (such as concurrent execution of protocols, alternation of main tasks and interrupts, etc.) access the same shared resource at the same time, and at least one operation is a write operation. In these cases, the execution order of the program can be uncertain, thereby causing system abnormalities and even crashes.

[0003] Currently, although there are a large number of data race detection methods for multi-threaded programs, these methods cannot be directly applied to protocol programs and interrupt-driven programs in embedded systems such as industrial control, and the data race detection methods for protocol and interrupt programs in industrial control systems are relatively scarce. With the increase of system complexity, effective protocol testing not only needs to verify the functionality and performance of the protocol, but also needs to ensure the accuracy and timeliness of data transmission in a multi-task and concurrent environment. Protocol testing is a process of verifying and evaluating communication protocols, aiming to ensure that their functionality, performance and reliability meet the predetermined standards, including verifying the message format, state transition, data integrity and behavior of the protocol under different conditions. The main methods of protocol testing at present include: model-driven testing, researchers can simulate and test various message interactions and interrupt conditions by establishing a formal model of the communication protocol, this method helps to identify potential data races and deadlock problems, but when dealing with interrupt-driven programs, the accuracy and completeness of the model are still insufficient; state-based testing: this method evaluates the behavior of the protocol in a concurrent scenario by tracking the changes of system state under different events, but there is a state explosion problem in applications that require frequent interrupts and switching; Restrict Interrupt Procedure (RID) technology, which improves random testing by eliminating abnormal interrupts; lightweight tagging technology, which detects data races by using interrupt switch-based synchronization rules, but it relies on virtual system simulator execution environment, frequently triggers interrupts to generate enough execution interleaving sequences, resulting in a sharp increase in the number of paths, causing high execution overhead and blocking the main task process, which violates the timing design of the interrupt program. At the same time, these methods only consider the interrupt switch-based synchronization mechanism, ignoring the widely used custom synchronization mechanism in protocol and interrupt programs in industrial control systems. For example, flag variables are often used for custom synchronization, but these variables are not uniformly declared and defined, making it difficult to identify them, which greatly affects the partial order relationship of memory access, resulting in a large number of false positives and reducing the accuracy of detection. In summary, the current data race detection methods for protocol and interrupt programs in industrial control systems still have many limitations in accuracy and practicality, and further research and improvement are needed to improve the detection effect. SUMMARY

[0004] The purpose of the present application is to provide a concurrent testing method and system for protocol and interrupt programs in industrial control systems, which can detect whether a potential event sequence that can trigger a data race can actually occur, obtain a detection result in polynomial time, and the detected data race is real without false positives, effectively solving the problem of identifying potential data races in complex interrupt programs.

[0005] To achieve the above purpose, the technical scheme adopted by the present application is as follows:

[0006] A concurrent testing method for protocol and interrupt programs in an industrial control system, comprising the following steps:

[0007] instrumenting the program to be tested, recording events, and generating an original execution sequence;

[0008] filtering irrelevant events in the original execution sequence to obtain a filtered execution sequence;

[0009] identifying interrupt information through static analysis to obtain a set of interrupt-related synchronization operations;

[0010] constructing an event sequence that can trigger a data race according to the filtered execution sequence and the set of interrupt-related synchronization operations;

[0011] determining a necessary event set according to the event sequence that can trigger a data race and the filtered execution sequence;

[0012] calculating a necessary partial order set according to the necessary event set;

[0013] using a directed graph to represent the partial order relationship according to the necessary event set and the necessary partial order set, with vertices representing events and edges representing the partial order relationship between events;

[0014] performing partial order closure calculation according to the directed graph, and if a loop occurs during the calculation, it is determined that the event sequence that can trigger a data race cannot occur in reality; otherwise, it is determined that the event sequence that can trigger a data race can occur in reality, indicating that there is a data race in the program to be tested.

[0015] Further, the recorded events include memory events, lock events, branch events, and synchronization events.

[0016] Further, the filtered irrelevant events include local variables, read-only variables, and redundant branches.

[0017] Further, the step of identifying interrupt information through static analysis includes:

[0018] parsing the source code of the interrupt driver through static analysis to construct a program dependency graph;

[0019] accurately locating and identifying interrupt information through analysis of static information in the program dependency graph, the interrupt information including:

[0020] interrupt switch operation: a sequence of instructions related to enabling or masking interrupts, controlling the enablement and disablement of interrupts in the program;

[0021] interrupt entry and exit: indicating the beginning and end of the interrupt service program, which is a key node for program flow switching;

[0022] flag variable operation: as a lightweight synchronization mechanism, it realizes the cooperative control between interrupts and tasks through explicit read-write operations.

[0023] Further, the step of constructing the event sequence that can trigger data race includes:

[0024] finding pairs of read-write events that belong to different threads and operate on the same shared variable, wherein at least one write operation is included;

[0025] crossing the pairs of read-write events with one event before and one event after the pairs in the filtered execution sequence to generate the event sequence that can trigger data race.

[0026] Further, if the filtered execution sequence contains three or more threads, the step of constructing the event sequence that can trigger data race further includes:

[0027] identifying other thread events in the multi-threaded execution sequence that can interfere with the pairs of read-write events;

[0028] constructing an adjacency set according to the adjacency relationship requirements to ensure that events in other threads cannot be inserted between the pairs of read-write events;

[0029] combining the constructed adjacency set with the event sequence that can trigger data race as a constraint condition for the generation of the event sequence.

[0030] Further, the necessary event set meets four conditions: program feasibility, observation feasibility, lock semantics feasibility, and interruption feasibility.

[0031] Further, the necessary partial order set includes program partial order, observation partial order, lock semantics partial order, and interruption partial order, and includes partial order constraints that events in the event sequence that can trigger data race are arranged in a given order;

[0032] The necessary partial order set requires that the partial order satisfies the following asymmetric preemption relationship of the interruption service program:

[0033] Any interruption service program of any priority is allowed to preempt the main task that is running;

[0034] An interruption service program with a higher priority is allowed to preempt the interruption service program that is executing with a lower priority;

[0035] Any interruption service program of any priority cannot preempt the interruption service program with a higher priority than itself, and can only continue to run after the high-priority interruption service program completes execution;

[0036] Interruption service programs of the same priority cannot preempt each other, and can only continue to run after the first executed interruption service program completes execution.

[0037] Further, the step of performing partial order closure calculation according to the directed graph includes:

[0038] Before performing the partial order closure calculation, first add the partial orders in the necessary partial order set into an intermediate set;

[0039] Then process each partial order relation in the intermediate set, if there is an edge of the partial order relation in the directed graph, then insert the partial order relation to form a loop, which indicates that the event sequence that can trigger the data race cannot actually occur;

[0040] If there is no edge of the partial order relation in the directed graph, then add the partial order relation to the directed graph as a new edge, and perform the transitive closure, observation closure, lock closure, interrupt closure and adjacency closure calculation;

[0041] In the closure calculation process, if the new edge causes a loop in the directed graph, it indicates that the event sequence that can trigger the data race cannot actually occur, otherwise it indicates that the event sequence that can trigger the data race can actually occur.

[0042] A concurrent test system for protocols and interrupt programs in an industrial control system, comprising:

[0043] An execution sequence acquisition module for instrumenting a program to be tested, recording events, and generating an original execution sequence; filtering irrelevant events in the original execution sequence to obtain a filtered execution sequence;

[0044] An interrupt information collection module for identifying interrupt information through static analysis to obtain a set of interrupt-related synchronization operations;

[0045] An event sequence generation module for constructing an event sequence that can trigger a data race based on the filtered execution sequence and the set of interrupt-related synchronization operations;

[0046] A sequence feasibility calculation module for determining a set of unnecessary events and a set of necessary partial orders based on the event sequence that can trigger a data race and the filtered execution sequence; using a directed graph to represent partial order relations, with vertices representing events and edges representing partial order relations between events; performing partial order closure calculation based on the directed graph, and if a loop is generated during the calculation, determining that the event sequence that can trigger a data race cannot actually occur; otherwise, determining that the event sequence that can trigger a data race can actually occur, indicating that there is a data race in the program to be tested.

[0047] The beneficial effects achieved by the present application include:

[0048] 1. Support for modeling the preemption relationship of interrupt-driven programs: According to the asymmetric preemption relationship requirement, the present application processes interrupt thread-related events based on interrupt priority, ensures that interrupts of the same priority cannot preempt each other, and ensures that a low-priority interrupt can only continue to run after a high-priority interrupt completes execution after being preempted by a high-priority interrupt, accurately reflecting the synchronization mechanism of interrupt-driven embedded software.

[0049] 2. Precise capture of interrupt-related synchronization information: The present application extracts a set of synchronization operations related to interrupts in embedded software by identifying interrupt switch operations, interrupt entry and exit events, and flag variable operations, providing accurate basic information for subsequent data race analysis.

[0050] 3. Efficient detection of potential data races: The present application converts interrupt-related synchronization information into event sequences of potential data races, and through the construction of necessary event sets and necessary partial order sets, combined with closure computation to dynamically verify whether the event sequence can actually occur, thereby efficiently determining whether there is a data race in the program under test, improving the accuracy and reliability of detection.

[0051] 4. Solving the problem of concurrent analysis of multi-threaded and interrupt programs: The present application provides a systematic testing scheme for the concurrent characteristics of industrial control system protocols and interrupt programs, which can take into account the synchronization relationship between threads and interrupt-driven behavior, overcoming the problem of insufficient detection accuracy in complex concurrent scenarios of traditional methods. BRIEF DESCRIPTION OF DRAWINGS

[0052] Figure 1 The flowchart of the implementation of the concurrent testing method of protocols and interrupt programs in the industrial control system of the embodiments of the present application. DETAILED DESCRIPTION

[0053] In order to make the technical features and advantages or technical effects of the above technical solutions of the present application more obvious and easy to understand, the following detailed description is made with reference to the drawings.

[0054] The present embodiment discloses a concurrent testing method of protocols and interrupt programs in an industrial control system, as shown in Figure 1 The processing steps can be divided into four stages: execution sequence collection, interrupt information collection, event sequence generation, and sequence feasibility calculation, which can be completed by the four modules of the concurrent testing system of protocols and interrupt programs in the industrial control system disclosed by the present embodiment: execution sequence collection module, interrupt information collection module, event sequence generation module, and sequence feasibility calculation module. The specific description of the above four stages is as follows:

[0055] I. Execution sequence collection stage

[0056] The test program is instrumented, and memory events, lock events (lock application events, acquisition events, release events), branch events (conditional judgments), and synchronization events (thread-related) are recorded to obtain the original execution sequence. The execution sequence refers to the trajectory of the interleaved execution of multiple threads in a concurrent program, denoted by σ. The event is an element of the execution sequence, denoted by e. The relationship between events is called partial order, denoted by <. An event consists of four attributes, denoted by e = et(thrd, evnt, obj). Where et represents the event type; thrd represents the thread number to which the event belongs; evnt represents the sequential number of the event in the thread; and obj represents the object acted on by the event, including memory locations and locks. Events can be divided into the following four categories according to the different types of events:

[0057] (1) Memory events. Read events and write events represent read and write operations on memory location x, denoted by r(x) and w(x), and the event type is r and w.

[0058] (2) Lock events. Application events, acquisition events, and release events represent the application, holding, and release operations on lock l, denoted by req(l), acq(l), and rel(l), and the event type is req, acq, and rel.

[0059] (3) Branch events. Branch events represent the existence of program paths that are not recorded in the execution sequence (conditional judgments), denoted by br, and the event type is br.

[0060] (4) Synchronization events. Synchronization events include thread creation and merging, which are fewer in number and can be converted into existing concepts to represent.

[0061] After obtaining the original execution sequence, the execution sequence collection stage filters out a large number of events in the original execution sequence that do not affect other threads, including local variables, read-only variables, and redundant branches, to obtain the filtered execution sequence.

[0062] II. Interruption information collection stage

[0063] The display and implicit interrupt switch operations in the program to be tested are identified, including standard interrupt interfaces and interrupt registers, and the interrupt exit and entry and flag variables are identified to obtain the set of interruption-related synchronization operations. Specifically, the interrupt switch is usually implemented by a specific API or register, such as the standard interrupt switch API: enable_isr(-1) / disable_isr(-1) controls the switch state of all interrupts, and enable_isr(i) / disable_isr(i) controls the switch state of the interrupt isr iIn addition, some systems implement implicit switching of interrupts by operating the related hardware, such as implementing two-level control by using an interrupt enable register IE to open or close the interrupt, and controlling the opening and closing of the interrupt by using switching interrupt control bits EA, ET, and the like. At the same time, interrupt-driven embedded software usually also uses flag variables to complete interrupt synchronization operations, that is, shared resources are released by writing operations, and the resources are obtained by checking operations. The flag variables themselves do not participate in the calculation and do not depend on external inputs. They are either read and written only for constants or are passed by value to coordinate between the main task and the interrupt, or between the interrupts, to complete the access synchronization of shared resources.

[0064] The interrupt information is collected by static analysis in the interrupt information collection phase. Specifically, the key synchronization operations in the interrupt-driven program are accurately identified by establishing a program dependence graph. First, the source code in the interrupt-driven program is parsed, and a control flow graph and a data flow graph are constructed to capture the control dependencies and data dependencies in the program that can affect the interrupt behavior. On this basis, the control dependencies and data dependencies are integrated to form a program dependence graph. By analyzing the program dependence graph, the following interrupt synchronization operations can be accurately identified:

[0065] Interrupt switching operation: By identifying the interrupt enable or mask function (such as enable_isr or disable_isr) that can appear in the call of the main task or the interrupt service program, the key point of controlling the interrupt state is captured, and the context and dependency relationship in the program execution can be determined by program dependence graph analysis.

[0066] Interrupt entry and exit: The starting point (entry) and return point (exit) of the interrupt handling function are identified in the program dependence graph, and the function call relationship in the interrupt vector and the interrupt service program is analyzed to accurately locate.

[0067] Flag variable operation: The definition and use position are determined by data flow analysis, and by tracing the dependency chain of the flag variable, it can be identified whether they are used to synchronize the interaction between the interrupt and the main task. For nested flag variables, further confirmation is made by cross-function analysis whether they are related to the call of the interrupt service program.

[0068] By constructing a program dependence graph for the interrupt-driven program and analyzing it, the collection of standard interrupt interfaces and interrupt register related operations is realized, and the interrupt exit and entry and flag variables are identified, so as to obtain the interrupt-related synchronization operation set.

[0069] III. Event sequence generation phase

[0070] According to the filtered execution sequence and the set of interruption related synchronization operations, combined with the mode requirement of data race, the event pair that can potentially trigger data race is constructed. The two events belong to different threads and are memory read and write events of the same shared variable, and at least one of them is a write operation. The two events are arranged in cross with the event before and after the two events in the filtered execution sequence, and the event sequence that can potentially trigger data race is constructed, which is denoted as ρ. The construction method of the event sequence that can potentially trigger data race ensures that other events in different threads to which the two events belong will not occur between the two events. If the filtered execution sequence contains three or more threads, the adjacent set of adjacent relationship requirements also needs to be added to ensure that the events of other threads will not occur between the two events.

[0071] IV. Sequence feasibility calculation phase

[0072] After obtaining the filtered execution sequence σ and the event sequence ρ that can potentially trigger data race, the sequence feasibility calculation phase judges whether there is a real execution sequence σ' such that ρ is a subsequence of σ', and σ' satisfies the adjacent relationship defined by the adjacent set The adjacent relationship defined by the adjacent set, where D ρ represents the event set involved in σ. First, the necessary event set X that makes ρ occur is determined, that is, the event set that must be contained to make the event sequence that can potentially trigger data race occur truly, so as to satisfy the program feasibility (events conform to the program logic), observation feasibility (branch events after read events can correctly observe the read results), lock feasibility (contains the order between all required lock release and acquisition events), and interruption feasibility (satisfies the preemption relationship between interruption threads and tasks). After obtaining the necessary event set X, the partial order set P that must be satisfied on X, that is, the necessary partial order set, needs to be determined. P contains program partial order, observation partial order, lock partial order, and interruption partial order. In addition, to satisfy the adjacent relationship defined by the adjacent set , the sequence partial order specified in ρ also needs to be contained. The program partial order requires that the program partial order in X corresponding to σ needs to be contained in P, the observation partial order requires that if there is a branch event after a read event in X, the observation partial order thereof should belong to P. The lock partial order requires that the partial order between the lock acquisition event corresponding to the lock release event not in X and the conflicting release event thereof should belong to P. The interruption partial order includes the preemption relationship partial order between the interruption thread and the main program task, and the preemption relationship partial order between the high priority interruption thread and the low priority interruption thread, which requires that the partial order corresponding to the asymmetric preemption relationship of the interruption driven program should belong to P:

[0073] Any interruption service program of any priority can preempt the running main task;

[0074] A higher-priority interrupt service routine can preempt a lower-priority interrupt service routine that is currently executing.

[0075] No interrupt service routine of any priority can preempt an interrupt service routine of higher priority; it can only continue to run after the higher priority interrupt service routine has finished executing.

[0076] Interrupt service routines of the same priority cannot preempt each other; they can only continue running after the first interrupt service routine has finished executing.

[0077] After obtaining the necessary event set X and the necessary partial order set P, it is necessary to calculate the partial order closure of P to determine whether any contradictions occur during the process. This invention uses a directed graph G to represent the partial order, where the vertices are events, and the vertex set is the event set X; vertex e i to e j A directed edge represents a partial order e between two events. i <e j ,use <e i ,e j The calculation process first adds the partial orders in the partially ordered set P to the intermediate set Q, and then processes each partial order in Q...<e1,e2> Process it. If it exists in G.<e2,e1> If a directed edge is added, then...<e1,e2> This can create loops in G, leading to contradictions, and in this case, the event sequence ρ that could trigger a data race cannot actually occur. If G does not contain...<e1,e2> If there is a directed edge, then...<e1,e2> Add G, and process the transitive closure, observation closure, locking closure, interruption closure, and adjacency closure caused by the insertion of a new directed edge. If no contradiction arises during the entire closure calculation process, the event sequence ρ that can trigger data races can actually occur, meaning that data races exist in the program under test. The calculation rules for the transitive closure, observation closure, locking closure, interruption closure, and adjacency closure caused by the insertion of a new directed edge are as follows:

[0078] (1) Transitive closure: When adding to G<e1,e2> At times, there is a side<G.pred(e1,t),e1> The existence of this makes G.pred(e1,t) transitively reachable from e2. Therefore, a new directed edge needs to be added.<G.pred(e1,i),e2> Add it to Q. Similarly, it also needs to be added...<e1,G.succ(e2,i)> Also added to Q. Here, pred and succ represent the predecessor and successor events of the event, respectively, and t and i both represent the thread number.

[0079] (2) Observe the closure: Examine the memory location m involved in σ, and find the write event e to m that occurred before e1 within the same thread. w And the read event e after e2 within the same thread r For all others with ew Write events e′ that operate on the same memory location w Due to the addition of the edge<e1,e2> Afterwards, if e′ w to e r If reachable, insert an edge. <e′ w ,e w >;If e w to e′ w If reachable, insert an edge. <e r ,e′ w >

[0080] (3) Lock closure: Check all locks in σ and find the last event e that acquired lock l before e1 within the same thread. acq The first lock release event e that occurs after e2 within the same thread. rel .<e1,e2> Adding G caused e acq ∝e rel ∧e acq <e rel Therefore, to ensure that the two critical sections are mutually exclusive, it is necessary to add... <match σ (e acq ), match σ (e rel )>. Among them, match σ (e) represents the release or acquisition event that matches e in σ, e acq ∝e rel This indicates that the two events are conflicting events.

[0081] (4) Interrupt Closure: Check the events in all interrupt synchronization operation sets in σ, and find the last matching event e that occurred before e1 within the same thread, based on the different event categories. acq And the first matching event e that occurs after e2 within the same thread. rel .<e1,e2> Adding G caused e acq ∝e rel ∧e acq <e rel Therefore, to ensure the asymmetric preemptive relationship, it is necessary to add... <match σ (e acq ), match σ (e rel For interrupt enable events, interrupt entry events, and flag variable read events, the corresponding events are interrupt disable events, interrupt exit events, and flag variable write events, respectively.

[0082] (5) Adjacency closure: check all required adjacency pairs <(e1, e2)> in the adjacency set A and all threads i. The adjacency set A requires that the predecessor successor of e1 and e2 are the same in each thread i, that is, G. pred(e2, i) should also be the predecessor of e1, so the partial order is added to Q. Similarly, the partial order generated by the other three cases is also added to Q.

[0083] If a loop is generated in the closure calculation process, it can be determined that p cannot actually occur.

[0084] Although the present application has been disclosed with examples as above, it is not intended to limit the present application, and any appropriate modification or equivalent replacement of the technical solutions of the present application made by those skilled in the art shall be covered within the protection scope of the present application, and the protection scope of the present application shall be subject to the limitations of the claims.

Claims

1. A method for concurrent testing of protocols and interrupt routines in an industrial control system, characterized in that, Includes the following steps: Instrument the program to be tested, record events, and generate the original execution sequence. The recorded events include memory events, lock events, branch events, and synchronization events. Filter irrelevant events from the original execution sequence to obtain the filtered execution sequence. The filtered irrelevant events include local variables, read-only variables, and redundant branches. Interrupt information is identified through static analysis, resulting in a set of interrupt-related synchronization operations. This set of interrupt-related synchronization operations includes interrupt switching operations, interrupt entry and exit points, and flag variable operations. The interrupt switching operation involves a sequence of instructions to enable or disable interrupts, controlling the activation and deactivation of program interrupts. The interrupt entry and exit points mark the start and end of the interrupt service routine, which are key nodes for program flow switching. The flag variable operation, as a lightweight synchronization mechanism, achieves coordinated control between interrupts and tasks through explicit read and write operations. Based on the filtered execution sequence and the set of interrupt-related synchronization operations, an event sequence that can trigger data races is constructed. The steps for constructing an event sequence that can trigger data races include: identifying read-write event pairs belonging to different threads that operate on the same shared variable, where at least one write operation is included; and interleaving the read-write event pairs with one event before and after them in the filtered execution sequence to generate an event sequence that can trigger data races. Based on the sequence of events that can trigger data races and the filtered execution sequence, a necessary set of events is determined; this necessary set of events simultaneously satisfies four conditions: program feasibility, observation feasibility, lock escaping feasibility, and interruption feasibility. Based on the necessary event set, a necessary partial order set is calculated. This necessary partial order set includes program partial order, observation partial order, locking partial order, and interrupt partial order, as well as partial order constraints that arrange events in a given order within an event sequence that can trigger data races. The necessary partial order set requires that the partial orders satisfy the following asymmetric preemption relationships of interrupt service routines: interrupt service routines of any priority are allowed to preempt the running main task; interrupt service routines with higher priorities are allowed to preempt the executing lower-priority interrupt service routines; interrupt service routines of any priority cannot preempt interrupt service routines with higher priorities than themselves, and can only continue running after the higher-priority interrupt service routine has completed execution; interrupt service routines of the same priority cannot preempt each other, and can only continue running after the interrupt service routine that was executed first has completed execution. Based on the necessary event set and the necessary partial order set, a directed graph is used to represent the partial order relation, where vertices are events and edges are the partial order relations between events; Partial order closures are calculated based on directed graphs, including transitive closures, observation closures, locking closures, interruption closures, and adjacency closures. If a loop occurs during the calculation, it is determined that the event sequence that could trigger a data race cannot actually occur; otherwise, it is determined that the event sequence that could trigger a data race can actually occur, indicating that a data race exists in the program under test.

2. The method as described in claim 1, characterized in that, The steps for identifying interruption information through static analysis include: The source code of the interrupt driver is analyzed through static analysis to construct a program dependency graph; By analyzing the static information in the program dependency graph, interrupt information can be accurately located and identified.

3. The method as described in claim 1, characterized in that, If the filtered execution sequence contains three or more threads, the steps for constructing an event sequence that can trigger a data race also include: Identify other thread events in a multi-threaded execution sequence that may interfere with read / write events; Construct an adjacency set based on adjacency requirements to ensure that events from other threads are not inserted between read / write event pairs; The constructed adjacency set is combined with the event sequence that can trigger data competition as a constraint for the generation of the event sequence.

4. The method as described in claim 1, characterized in that, The steps for calculating the partial order closure from a directed graph include: Before performing partial order closure calculation, the partial orders in the necessary partial order set are first added to the intermediate set; Then, each partial order relation in the intermediate set is processed. If there is an edge in the directed graph that has the partial order relation, then inserting the partial order relation will form a loop, indicating that the event sequence that can trigger data competition cannot actually occur. If there is no edge with the partial order relation in the directed graph, then the partial order relation is added to the directed graph as a new edge, and transitive closure, observation closure, locking closure, interruption closure and adjacency closure are calculated. During closure calculation, if a new edge causes a cycle to form in the directed graph, it means that the event sequence that can trigger a data race cannot actually occur; otherwise, it means that the event sequence that can trigger a data race can actually occur.

5. A concurrent testing system for protocols and interrupt routines in an industrial control system, implementing the method described in any one of claims 1-4, characterized in that, include: The execution sequence acquisition module is used to instrument the program under test, record events, and generate the raw execution sequence. Filter irrelevant events from the original execution sequence to obtain the filtered execution sequence; The interrupt information collection module is used to identify interrupt information through static analysis and obtain a set of interrupt-related synchronization operations. The event sequence generation module is used to construct an event sequence that can trigger data races based on the filtered execution sequence and the set of interrupt-related synchronization operations. The sequence feasibility calculation module is used to determine the set of unwanted events and the set of necessary partial orders based on the event sequence that can trigger data competition and the filtered execution sequence; based on the set of necessary events and the set of necessary partial orders, a directed graph is used to represent the partial order relationship, where the vertices are events and the edges are the partial order relationships between events; the partial order closure is calculated based on the directed graph, and if a loop is generated during the calculation process, it is determined that the event sequence that can trigger data competition cannot actually occur; Otherwise, if the sequence of events that can trigger a data race can actually occur, it indicates that a data race exists in the program under test.

Images