A formal verification method and system for mobile internet of things applications

Abstract

The application discloses a kind of formal verification method and system for mobile internet of things application, utilize boundary course calculus to describe the containing relationship and action rule of entity, obtain the model of mobile internet of things application running scene;Utilize boundary logic to describe the property that running scene needs to satisfy, obtain the boundary logic formula set of running scene property;In turn judge whether the model of mobile internet of things application running scene satisfies each boundary logic formula in boundary logic formula set;If the model of mobile internet of things application running scene satisfies all boundary logic formula in boundary logic formula set, then no need to make any adjustment to running scene, otherwise adjust the deployment position and / or action rule of equipment, and re-verify.The application constructs the model of mobile internet of things application running scene accurately with boundary course calculus, strictly describes the property of mobile internet of things application running scene with boundary logic, effectively improves the reliability of formal verification.

Description

Technical Field

[0001] This invention relates to software technology, and in particular to a formal verification method and system for mobile Internet of Things (IoT) applications. Background Technology

[0002] With the continuous development of wireless communication and environmental sensing technologies, IoT devices are becoming increasingly common in people's lives. These devices use sensors to perceive the surrounding environment, make corresponding decisions based on the environmental conditions, and execute operations to meet user needs.

[0003] Verifying the reliability and security of IoT devices in various operating scenarios is essential, especially in critical applications such as autonomous driving and elderly care, where the behavior of IoT devices directly impacts user safety. Traditional testing methods struggle to cover all possibilities and cannot adequately meet the verification needs of scenarios with low tolerance for errors. Formal verification, however, effectively addresses these limitations of traditional testing methods, thereby improving the reliability and security of such applications.

[0004] Formal verification uses formal methods to verify the correctness of a system regarding specific properties. Model checking is an important method of formal verification. It abstracts the system into a model of finite states, describes the properties the system needs to satisfy using logical formulas, and checks whether the system model satisfies the logical formulas corresponding to the properties. However, current model checking methods, such as temporal logic (LTL, CTL, etc.), cannot adequately describe the physical or logical inclusion relationships and action rules of spaces, devices, and people in the aforementioned mobile IoT application scenarios, exhibiting insufficient descriptive capabilities. Therefore, it is necessary to construct a formal verification method capable of describing the inclusion relationships and action rules of entities for formal verification of mobile IoT applications. Summary of the Invention

[0005] The technical solution to achieve the purpose of this invention is: a formal verification method and system for mobile Internet of Things applications, to solve the problem of the lack of formal verification means in this field.

[0006] The technical solution to achieve the above objectives is: a formal verification method for mobile IoT applications, comprising the following steps:

[0007] Step 1: Use Ambient Calculus to describe the containment relationships and action rules of entities to obtain a model of the mobile IoT application operation scenario;

[0008] Step 2: Use ambient logic to describe the properties that the running scenario needs to satisfy, and obtain a set of ambient logic formulas for the properties of the running scenario;

[0009] Step 3: Sequentially determine whether the model of the mobile IoT application operation scenario satisfies each of the boundary process logic formulas in the set of boundary process logic formulas;

[0010] Step 4: Perform different operations based on the results of Step 3. If the model of the mobile IoT application operation scenario satisfies all the boundary logic formulas in the boundary logic formula set, then no adjustments need to be made to the operation scenario. Otherwise, adjust the deployment location and / or action rules of the device, and go back to Step 1 for re-verification.

[0011] Furthermore, in step 1, the inclusion relationships and action rules of entities are described using boundary process calculus to obtain a model of the mobile IoT application operation scenario. The specific steps are as follows:

[0012] 11) Obtain the immovable and movable entities in the mobile IoT application operating scenario, and classify them into immovable entities and movable entities according to whether they can move in the scenario;

[0013] 12) Determine the containment relationships between immovable entities, and the containment relationships between movable entities and other entities at the start of the scene. Describe the containment relationships between entities as follows: This indicates that the smallest entity containing entity a is b at this time;

[0014] 13) Construct a set of action rules (MR) for movable entities, where each action rule is described as follows:<act_name,conditions,act_type(objects)> Here, `act_name` is the name of the action rule, `conditions` are the conditions that trigger the action, `act_type` is the action type, and `objects` is a list of entities involved in the action. The action type `act_type` has three options: `enter`, `leave`, and `give`. `enter(a,b)` means that entity `a` enters `b`, causing... leave(a,b) means that an entity a inside entity b leaves entity b, causing... give(a,b) means that entity a will satisfy Entity b is sent out, making ;

[0015] 14) Construct the boundary process calculation process for the initial state of the mobile IoT application runtime scenario, referred to as the initial process P. init The boundary process calculus is expressed as:

[0016] P,Q::= 0 | n[P] | P|Q | MP

[0017] M::= in n | out n | open n | mv n out m | mv n in m

[0018] P and Q represent processes; M represents capabilities; 0 is an empty process; n and m represent the names of processes; n[P] represents a process named n, in which process P is running; P|Q represents parallelism of processes; MP means that the action of capability M is executed first, and then process P continues.

[0019] Let fn(P) be the set of names that appear freely in process P, then:

[0020] ;

[0021] For each entity a, construct a corresponding boundary condition, if a1, a2, ..., a k If it is any entity that is not contained by other entities, then the boundary a1[P] will be set. a1 ],a2[P a2 ],…,a k [P ak Parallel formation of a1[P a1 ]|a2[P a2 ]|…|a k [P ak If there is an inclusion relationship between a pair of entities a and b, a.loc = b, then the boundary condition a[P] will be set. a ]P move into boundary process b[P b [Form b[a[P]] a ]|P b Using the above operations, all the boundary processes corresponding to the entities are merged into an initial process P. init ;

[0022] 15) Using a tuple of initial process and action rule set <P init MR> represents a model of the operating scenario of mobile IoT applications.

[0023] Furthermore, in step 2, the properties that the running scenario needs to satisfy are described using bounded process logic, resulting in a set of bounded process logic formulas for the properties of the running scenario. The specific steps are as follows:

[0024] 21) Obtain the properties that mobile IoT application operating scenarios need to satisfy;

[0025] 22) Combining the model of mobile IoT application operation scenarios, the properties that mobile IoT application operation scenarios need to satisfy are formalized into boundary process logic formulas, resulting in the boundary process logic formula set LF, where the boundary process logic formulas are:

[0026] ;

[0027] Where 0 and T are atomic formulas, representing an empty process and an arbitrary process, respectively; represents the negation, disjunction, and conjunction of the formula, respectively; n[A] represents a process that is a bounded process named n and the processes inside the bounded process satisfy formula A; A|B represents a process that is divided into two parallel parts and the two parts satisfy formula A and formula B, respectively; and These represent the time modal words "will eventually" and "always" respectively; and These represent the spatial modal terms "a certain place" and "all places," respectively. and These indicate the use of existential quantifiers and universal quantifiers, respectively.

[0028] Define fn(A) as the set of names that appear freely in the bounded logic formula A, then:

[0029] .

[0030] Further, in step 3, it is determined whether the model of the mobile IoT application operation scenario satisfies each of the boundary process logic formulas in the set of boundary process logic formulas. The specific method is as follows:

[0031] a. Input a model of the mobile IoT application's operating scenario. <P init ,MR> and boundary logic formula A, proceed to step b;

[0032] b. Traverse all action rules in MR, and for each action rule, proceed to one of steps b1-b6 in process P. init Add the process with capabilities corresponding to the action rule, and after traversal, let the resulting new process be P. M Proceed to step c;

[0033] b1. If the triggering condition of the action rule is not met, or if the triggering condition of the action rule is met but the corresponding capable process already exists in process P, then continue to traverse the next action rule.

[0034] b2. If the action is enter(a,b), and the boundary condition b[P] b ] and boundary process a[P a There is no nesting relationship between them, but the boundary b[P] b Or boundary process b[P b The boundary process of the outer kb layer and the boundary process a[P] a Or boundary process a[P a If there exists a parallel relationship in the boundary process of the outermost ka layer and ka,kb≥1, then in the boundary process a[P] aAdd a process M1.M2.in b.0, where M1 is the output of out i1.out i2. …. out i ka .0, i1, i2, ..., i ka The boundary processes a[P] are in sequence. a The names of the boundary processes of the 1st, 2nd, ..., ka layers are related to the boundary process b[P]. b Or boundary process b[P b The boundary process with parallel relationships at the kb-th layer is boundary process a[P]. a If it is itself, then M1 does not need to be added; M2 is in j. kb . in j kb-1 ... in j1.0, where j kb j kb-1 ..., j1 are the boundary processes b[P] in sequence. b The name of the boundary process at level kb, kb-1, ..., 1, if it is related to the boundary process a[P] a Or boundary process a[P a The boundary process with parallel relationships in the outer ka-th layer is boundary process b[P]. b If it is itself, then there is no need to add M2, and then continue to traverse the next action rule;

[0035] b3. If the action is enter(a,b), and the boundary condition b[P] b ] is the boundary process a[P a If the k-th boundary equation is such that k ≥ 2, then in the boundary equation a[P] a Add a process `out i1. out i2. .... out i` inside the `[` element. k-1 .0, where i1, i2, ..., i k-1 The boundary processes a[P] are in sequence. a The names of the boundary processes at levels 1, 2, ..., k-1 are determined, and then the next action rule is traversed.

[0036] b4. If the action is leave(a,b), and the boundary condition b[P] b ] is the boundary process a[P a If the k-th boundary equation is such that k ≥ 1, then in the boundary equation a[P] a Add a process `out i1. out i2. .... out i` inside the `[` element. k .0, where i1, i2, ..., i k The boundary processes a[P] are in sequence. a The names of the first, second, ..., kth boundary processes are identified, and then the next action rule is traversed.

[0037] b5. If the action is give(a,b), and the boundary condition b[P] b ] is the boundary process a[Pa If the first-level boundary equation is outside, then in the boundary equation a[P] a Add a process `mv b out a.0` within the `[` block, and then continue iterating through the next action rule;

[0038] b6. In other cases, continue iterating through the next action rule;

[0039] c. Determine if If yes, proceed to step r2; otherwise, proceed to step d1.

[0040] d1. Determine whether If yes, proceed to step d2; otherwise, proceed to step e1.

[0041] d2. Determine if P M If ≡0, proceed to step r2; otherwise, proceed to step r1.

[0042] e1. Determine if If yes, proceed to step e2; otherwise, proceed to step f1.

[0043] e2. Recursively check if it exists ,make ,in n0 is a randomly generated new name that satisfies If yes, proceed to step r2; otherwise, proceed to step r1.

[0044] f1. Determine if If yes, proceed to step f2; otherwise, proceed to step g1.

[0045] f2. Recursively determine whether for any All If yes, proceed to step r2; otherwise, proceed to step r1.

[0046] g1. Determine if If yes, proceed to step g2; otherwise, proceed to step h1.

[0047] g2. Recursively determine if there exists a Q such that P M →*Q and If yes, proceed to step r2; otherwise, proceed to step r1.

[0048] h1. Determine if If yes, proceed to step h2; otherwise, proceed to step i1.

[0049] h2. Recursively determine whether for any Q, P... M →*Q then If yes, proceed to step r2; otherwise, proceed to step r1.

[0050] i1. Determine if If yes, proceed to step i2; otherwise, proceed to step j1.

[0051] i2. Recursively determine if there exists a Q such that P M ↓*Q and If yes, proceed to step r2; otherwise, proceed to step r1.

[0052] j1. Determine if If yes, proceed to step j2; otherwise, proceed to step k1.

[0053] j2. Recursively determine whether for any Q, P... M ↓*Q If yes, proceed to step r2; otherwise, proceed to step r1.

[0054] k1. Determine if If yes, proceed to step k2; otherwise, proceed to step l1.

[0055] k2. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step k3.

[0056] k3. Recursively check if If yes, proceed to step r2; otherwise, proceed to step r1.

[0057] l1. Determine if If yes, proceed to step l2; otherwise, proceed to step m1.

[0058] l2. Recursively determine whether If yes, proceed to step l3; otherwise, proceed to step r1.

[0059] l3. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step r1.

[0060] m1. Determine if If yes, proceed to step m2; otherwise, proceed to step n1.

[0061] m2. Recursively determine whether there exist Q and R such that If yes, proceed to step r2; otherwise, proceed to step r1.

[0062] n1. Determine if If yes, proceed to step n2; otherwise, proceed to step o1.

[0063] n2. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step r1.

[0064] o1. Determine if If yes, proceed to step o2; otherwise, proceed to step p1.

[0065] o2. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step r1.

[0066] p1. Determine if If yes, proceed to step p2; otherwise, proceed to step q1.

[0067] p2. Recursively determine if If yes, proceed to step r1; otherwise, proceed to step r2.

[0068] q1. Determine if If yes, proceed to step q2; otherwise, proceed to step r1.

[0069] q2. Recursively determine if there exists a Q such that If yes, proceed to step r2; otherwise, proceed to step r1.

[0070] r1. Command ,represent Proceed to step s;

[0071] r2. Let ,represent Proceed to step s;

[0072] s. Output res, the algorithm ends;

[0073] Where ≡ represents the structural congruence relation between processes, and the relevant properties are:

[0074] ;

[0075] → represents a reduction relationship between processes, →* represents a reflexive transitive closure of the reduction relationship, and the relevant properties are:

[0076] ;

[0077] ↓ indicates a nested relationship between processes. Then P↓Q,↓* represents the reflexive transitive closure of the nested relationship.

[0078] Furthermore, the specific steps of step 4 are as follows:

[0079] 4a) If the model of the mobile IoT application operation scenario satisfies all the boundary process logic formulas in the set of boundary process logic formulas, it indicates that all the properties of the IoT application operation scenario are satisfied, and the formal verification of the mobile IoT application ends.

[0080] 4b) If the model of the mobile IoT application operation scenario does not satisfy some of the boundary process logic formulas in the set of boundary process logic formulas, it means that there are properties that cannot be satisfied in the current scenario. The location of the device deployment and / or the action rules should be modified, and step 1 should be returned.

[0081] A formal verification system for mobile Internet of Things (IoT) applications is provided, which implements formal verification for mobile IoT applications based on the aforementioned formal verification method for mobile IoT applications.

[0082] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs formal verification for mobile Internet of Things (IoT) applications based on the aforementioned formal verification method for mobile IoT applications.

[0083] A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, formal verification for mobile Internet of Things (IoT) applications is performed based on the aforementioned formal verification method for mobile IoT applications.

[0084] Compared with the prior art, the present invention has the following significant advantages: 1) It uses formal methods to describe the physical or logical inclusion relationships and action rules of space, equipment and personnel, which solves the problem of lack of formal verification means for mobile Internet of Things applications; 2) It uses boundary process calculus to accurately construct the model of the operating scenario of mobile Internet of Things applications and uses boundary process logic to strictly describe the properties of the operating scenario of mobile Internet of Things applications, which effectively improves the reliability of formal verification. Attached Figure Description

[0085] Figure 1 This is a diagram illustrating the implementation steps of the present invention;

[0086] Figure 2 This is a software structure diagram of the present invention;

[0087] Figure 3 This is the algorithm flowchart for step 3 of the present invention. Detailed Implementation

[0088] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0089] 1. Scenario Cases

[0090] A hotel uses two robots to deliver items to its guests. The hotel has two floors: the lobby and reception are on the first floor, and the guest rooms are on the second floor, connected by an elevator. Guests can order food by phone from the front desk. Front desk staff will place the food in the robot and set its delivery destination. The robot will then take the elevator to the guest's room, where the guest will collect the food before the robot returns to the first floor.

[0091] 2. Implementation steps

[0092] Step 1: Use boundary process calculus to describe the containment relationships and action rules of entities, obtaining a model of the operational scenario for mobile IoT applications. This includes the following specific steps:

[0093] 11) Obtain immovable and movable entities in the mobile IoT application operation scenario. Here, entities generally refer to physical spaces, equipment, or personnel, and are divided into immovable entities and movable entities according to whether they can move in the scenario.

[0094] The immovable entities in this scenario are: guest room R_201, guest room R_202, first floor space F_1, second floor space F_2, and the entire hotel space Hotel. The movable entities are: robot Rbt_1, robot Rbt_2, food Fd_201, food Fd_202, and elevator Elvt.

[0095] 12) Determine the containment relationships between immovable entities, and the containment relationships between movable entities and other entities at the start of the scene, describing the containment relationships between entities as follows: This indicates that the smallest entity containing entity a is b at this time;

[0096] The containment relationship between immovable entities in this scenario is as follows:

[0097] .

[0098] The containment relationships between movable entities and other entities at the start of the scene are as follows: ;

[0099] 13) Construct a set of action rules (MR) for movable entities, where each action rule is described as follows:<act_name,conditions,act_type(objects)> Here, `act_name` is the name of the action rule, `conditions` are the conditions for triggering the action, `act_type` is the action type, and `objects` is a list of entities involved in the action. The action type `act_type` is divided into three types: `enter`, `leave`, and `give`. `enter(a,b)` means that entity `a` enters `b` such that `a.loc` = `b` (before the action, `b` must not be inside `a`). `leave(a,b)` means that an entity `a` inside entity `b` leaves entity `b` such that `a.loc` = `b.loc`. `give(a,b)` means that entity `a` sends out entity `b` that satisfies `b.loc` = `a`, such that `a.loc` = `b.loc`.

[0100] Let U be the set of robot serial numbers, V be the set of hotel room serial numbers (which are also the food serial numbers), and W be the set of hotel floor serial numbers. Therefore, in this scenario, U = {1, 2}, V = {201, 202}, and W = {1, 2}.

[0101] To facilitate the description of the states of the robot and elevator in the scene, for any... Rbt_i.hasFood = true if and only if Otherwise, Rbt_i.hasFood = false; for any i ∈ U, Rbt_i.destF = F_2 if and only if Rbt_i.hasFood = true, otherwise Rbt_i.destF = F_1; Elvt.isBusy = true if and only if Otherwise, Elvt.isBusy = false.

[0102] The set of action rules (MR) defined by the application developer is:

[0103]

[0104] 14) Constructing the boundary process calculation process (hereinafter referred to as the initial process) for the initial state of the mobile IoT application operation scenario P init The syntax for boundary process calculus is:

[0105] P,Q::= 0 | n[P] | P|Q | MP

[0106] M::= in n | out n | open n | mv n out m | mv n in m

[0107] P and Q represent processes; M represents capabilities; 0 is an empty process; n and m represent the names of processes; n[P] represents a process named n, in which process P is running; P|Q represents parallelism of processes; MP means that the action of capability M is executed first, and then process P continues.

[0108] For each entity a, construct a corresponding boundary process a[0], if a1, a2, ..., a k If it is any entity that is not contained by other entities, then the boundary a1[P] will be set. a1 ],a2[P a2 ],…,a k [P ak Parallel formation of a1[P a1 ]|a2[P a2 ]|…|a k [P ak If there is an inclusion relationship between a pair of entities a and b, a.loc = b, then the boundary condition a[P] will be set. a ]P move into boundary process b[P b [Form b[a[P]] a ]|P b Using the above operations, the boundary processes corresponding to all entities can be merged into a single initial process P. init ;

[0109] The initial process P of this scenario init For Hotel[Elvt[0]|F_1[Rbt_1[Fd_201[0]]|Rbt_2 [Fd_202[0]]]|F_2[R_201[0]|R_202[0]]].

[0110] 15) Using a tuple of initial process and action rule set <P init MR> represents a model of the operating scenario of mobile IoT applications.

[0111] Combine the action rule set MR constructed in step 13) and the initial process P constructed in step 14). init Combine into a binary pair <P init ,MR> is the model of the operating scenario of the mobile IoT application.

[0112] Step 2: Use bounded process logic to describe the properties that the running scenario needs to satisfy, and obtain a set of bounded process logic formulas for the properties of the running scenario. This includes the following specific steps:

[0113] 21) Obtain the properties that mobile IoT application operating scenarios need to satisfy;

[0114] Property 1: Due to the limited space inside the elevator, two robots must not exist inside the elevator at the same time;

[0115] Property 2: Without considering elevator space limitations, both robots can deliver their meals to the correct room and return to the first floor.

[0116] 22) Combining the model of mobile IoT application operation scenarios, the properties that mobile IoT application operation scenarios need to satisfy are formalized into bounded process logic formulas, resulting in the bounded process logic formula set LF, where the syntax of the bounded process logic formula is:

[0117]

[0118] Where 0 and T are atomic formulas, representing an empty process and an arbitrary process, respectively; , respectively represent the negation, disjunction and conjunction of the formula; n[A] represents that the process is a process named n and the processes inside the process satisfy the formula A; A@n represents that the process can satisfy the formula A after being placed in the process named n; A|B represents that the process can be divided into two parallel parts and these two parts satisfy the formulas A and B respectively; and These represent the time modal words "will eventually" and "always" respectively; and These represent the spatial modal terms "a certain place" and "all places," respectively. and These indicate the use of existential quantifiers and universal quantifiers, respectively.

[0119] Property 1 can be formalized as Property 2 can be formalized as Then the set of boundary process logic formulas LF is:

[0120]

[0121] Step 3: Sequentially determine whether the model of the mobile IoT application operation scenario satisfies each of the boundary process logic formulas in the set of boundary process logic formulas;

[0122] Based on the algorithm judgment in step 3, the model of the mobile IoT application operation scenario does not satisfy the boundary logic formula corresponding to property 1 in the boundary logic formula set, but satisfies the boundary logic formula corresponding to property 2 in the boundary logic formula set.

[0123] Step 4: Perform different operations based on the results of Step 3. If the model of the mobile IoT application operation scenario satisfies all the boundary logic formulas in the boundary logic formula set, then no adjustments need to be made to the operation scenario. Otherwise, adjust the deployment location and / or action rules of the device, and go back to Step 1 for re-verification.

[0124] Since the model of this mobile IoT application's operating scenario does not satisfy the boundary process logic formula corresponding to Property 1 in the set of boundary process logic formulas, it indicates that two robots are simultaneously present in the elevator. This is because the triggering condition of the action rule Rbt_enter_Elvt does not include a judgment on whether a robot is already present in the elevator. Therefore, it is corrected to...

[0125] The new model containing the corrected action rules is then transferred to step 1 for re-verification. The result satisfies all the bounded process logic formulas in the set of bounded process logic formulas, indicating that the properties of the scenario are satisfied. The formal verification of the scenario is now complete.

[0126] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0127] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A formal verification method for mobile Internet of Things (IoT) applications, characterized in that, Includes the following steps: Step 1: Use boundary process calculus to describe the inclusion relationships and action rules of entities to obtain a model of the mobile IoT application operation scenario; Step 2: Use bounded process logic to describe the properties that the running scenario needs to satisfy, and obtain the set of bounded process logic formulas for the properties of the running scenario; Step 3: Sequentially determine whether the model of the mobile IoT application operation scenario satisfies each of the boundary process logic formulas in the boundary process logic formula set; Step 4: Perform different operations based on the results of Step 3. If the model of the mobile IoT application operation scenario satisfies all the boundary logic formulas in the boundary logic formula set, then no adjustment needs to be made to the operation scenario. Otherwise, adjust the deployment location and / or action rules of the device, and go back to Step 1 for re-verification. in: In step 1, the inclusion relationships and action rules of entities are described using boundary process calculus to obtain a model of the mobile IoT application operation scenario. The specific steps are as follows: 11) Obtain the immovable and movable entities in the mobile IoT application operating scenario, and classify them into immovable entities and movable entities according to whether they can move in the scenario; 12) Determine the containment relationships between immovable entities, and the containment relationships between movable entities and other entities at the start of the scene. Describe the containment relationships between entities as follows: This indicates that the smallest entity containing entity a is b at this time; 13) Construct a set of action rules (MR) for movable entities, where each action rule is described as follows:<act_name,conditions,act_type(objects)> Here, `act_name` is the name of the action rule, `conditions` are the conditions that trigger the action, `act_type` is the action type, and `objects` is a list of entities involved in the action. The action type `act_type` has three options: `enter`, `leave`, and `give`. `enter(a,b)` means that entity `a` enters `b`, causing... leave(a,b) means that an entity a inside entity b leaves entity b, causing... give(a,b) means that entity a will satisfy Entity b is sent out, making ; 14) Construct the boundary process calculation process for the initial state of the mobile IoT application runtime scenario, referred to as the initial process P. init The boundary process calculus is expressed as: P,Q::= 0 | n[P] | P|Q | MP M::= in n | out n | open n | mv n out m | mv n in m P and Q represent processes; M represents capabilities; 0 is an empty process; n and m represent the names of processes; n[P] represents a process named n, in which process P is running; P|Q represents parallelism of processes; MP means that the action of capability M is executed first, and then process P continues. Let fn(P) be the set of names that appear freely in process P, then: ； For each entity a, construct a corresponding boundary condition, if a1, a2, ..., a k If it is any entity that is not contained by other entities, then the boundary a1[P] will be set. a1 ],a2[P a2 ],…,a k [P ak Parallel formation of a1[P a1 ]|a2[P a2 ]|…|a k [P ak If there is an inclusion relationship between a pair of entities a and b, a.loc = b, then the boundary condition a[P] will be set. a ]P move into boundary process b[P b [Form b[a[P]] a ]|P b Using the above operations, all the boundary processes corresponding to the entities are merged into an initial process P. init ; 15) Using a tuple of initial process and action rule set <P init ,MR> represents a model of the operating scenario of a mobile IoT application; In step 2, the properties that the running scenario needs to satisfy are described using bounded process logic, resulting in a set of bounded process logic formulas for the properties of the running scenario. The specific steps are as follows: 21) Obtain the properties that mobile IoT application operating scenarios need to satisfy; 22) Combining the model of mobile IoT application operation scenarios, the properties that mobile IoT application operation scenarios need to satisfy are formalized into boundary process logic formulas, resulting in the boundary process logic formula set LF, where the boundary process logic formulas are: ； Where 0 and T are atomic formulas, representing an empty process and an arbitrary process, respectively; represents the negation, disjunction, and conjunction of the formula, respectively; n[A] represents a process that is a bounded process named n and the processes inside the bounded process satisfy formula A; A|B represents a process that is divided into two parallel parts and the two parts satisfy formula A and formula B, respectively; and These represent the time modal words "will eventually" and "always" respectively; and These represent the spatial modal terms "a certain place" and "all places," respectively. and These indicate the use of existential quantifiers and universal quantifiers, respectively. Define fn(A) as the set of names that appear freely in the bounded logic formula A, then: 。 2. The formal verification method for mobile IoT applications according to claim 1, characterized in that, Step 3: Sequentially determine whether the model of the mobile IoT application's operating scenario satisfies each boundary process logic formula in the set of boundary process logic formulas. The specific method is as follows: a. Input a model of the mobile IoT application's operating scenario. <P init ,MR> and boundary logic formula A, proceed to step b; b. Traverse all action rules in MR, and for each action rule, proceed to one of steps b1-b6 in process P. init Add the process with capabilities corresponding to the action rule, and after traversal, let the resulting new process be P. M Proceed to step c; b1. If the triggering condition of the action rule is not met, or if the triggering condition of the action rule is met but the corresponding capable process already exists in process P, then continue to traverse the next action rule. b2. If the action is enter(a,b), and the boundary condition b[P] b ] and boundary process a[P a There is no nesting relationship between them, but the boundary b[P] b Or boundary process b[P b The boundary process of the outer kb layer and the boundary process a[P] a Or boundary process a[P a If there exists a parallel relationship in the boundary process of the outermost ka layer and ka,kb≥1, then in the boundary process a[P] a Add a process M1.M2.in b.0, where M1 is the output of out i1. outi2. …. out i ka .0, i1, i2, ..., i ka The boundary processes a[P] are in sequence. a The names of the boundary processes of the 1st, 2nd, ..., ka layers are related to the boundary process b[P]. b Or boundary process b[P b The boundary process with parallel relationships at the kb-th layer is boundary process a[P]. a If it is itself, then M1 does not need to be added; M2 is in j. kb . in j kb-1 ... in j1.0, where j kb j kb-1 ..., j1 are the boundary processes b[P] in sequence. b The name of the boundary process at level kb, kb-1, ..., 1, if it is related to the boundary process a[P] a Or boundary process a[P a The boundary process with parallel relationships in the outer ka-th layer is boundary process b[P]. b If it is itself, then there is no need to add M2, and then continue to traverse the next action rule; b3. If the action is enter(a,b), and the boundary condition b[P] b ] is the boundary process a[P a If the k-th boundary equation is such that k ≥ 2, then in the boundary equation a[P] a Add a process `out i1. out i2. .... out i` inside the `[` element. k-1 .0, where i1, i2, ..., i k-1 The boundary processes a[P] are in sequence. a The names of the boundary processes at levels 1, 2, ..., k-1 are determined, and then the next action rule is traversed. b4. If the action is leave(a,b), and the boundary condition b[P] b ] is the boundary process a[P a If the k-th boundary equation is such that k ≥ 1, then in the boundary equation a[P] a Add a process `out i1. out i2. .... out i` inside the `[` element. k .0, where i1, i2, ..., i k The boundary processes a[P] are in sequence. a The names of the first, second, ..., kth boundary processes are identified, and then the next action rule is traversed. b5. If the action is give(a,b), and the boundary condition b[P] b ] is the boundary process a[P a If the first-level boundary equation is outside, then in the boundary equation a[P] a Add a process `mv b out a.0` within the `[` block, and then continue iterating through the next action rule; b6. In other cases, continue iterating through the next action rule; c. Determine if If yes, proceed to step r2; otherwise, proceed to step d1. d1. Determine whether If yes, proceed to step d2; otherwise, proceed to step e1. d2. Determine if P M If ≡0, proceed to step r2; otherwise, proceed to step r1. e1. Determine if If yes, proceed to step e2; otherwise, proceed to step f1. e2. Recursively determine whether there exists an n∈Λ such that ,in n0 is a randomly generated new name that satisfies If yes, proceed to step r2; otherwise, proceed to step r1. f1. Determine if If yes, proceed to step f2; otherwise, proceed to step g1. f2. Recursively determine whether the following holds true for any n∈Λ. If yes, proceed to step r2; otherwise, proceed to step r1. g1. Determine if If yes, proceed to step g2; otherwise, proceed to step h1. g2. Recursively determine if there exists a Q such that P M →*Q and If yes, proceed to step r2; otherwise, proceed to step r1. h1. Determine if If yes, proceed to step h2; otherwise, proceed to step i1. h2. Recursively determine whether for any Q, P... M →*Q then If yes, proceed to step r2; otherwise, proceed to step r1. i1. Determine if If yes, proceed to step i2; otherwise, proceed to step j1. i2. Recursively determine if there exists a Q such that P M ↓*Q and If yes, proceed to step r2; otherwise, proceed to step r1. j1. Determine if If yes, proceed to step j2; otherwise, proceed to step k1. j2. Recursively determine whether for any Q, P... M ↓*Q If yes, proceed to step r2; otherwise, proceed to step r1. k1. Determine if If yes, proceed to step k2; otherwise, proceed to step l1. k2. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step k3. k3. Recursively check if If yes, proceed to step r2; otherwise, proceed to step r1. l1. Determine if If yes, proceed to step l2; otherwise, proceed to step m1. l2. Recursively determine whether If yes, proceed to step l3; otherwise, proceed to step r1. l3. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step r1. m1. Determine if If yes, proceed to step m2; otherwise, proceed to step n1. m2. Recursively determine whether there exist Q and R such that If yes, proceed to step r2; otherwise, proceed to step r1. n1. Determine if If yes, proceed to step n2; otherwise, proceed to step o1. n2. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step r1. o1. Determine if If yes, proceed to step o2; otherwise, proceed to step p1. o2. Recursively determine whether If yes, proceed to step r2; otherwise, proceed to step r1. p1. Determine if If yes, proceed to step p2; otherwise, proceed to step q1. p2. Recursively determine if If yes, proceed to step r1; otherwise, proceed to step r2. q1. Determine if If yes, proceed to step q2; otherwise, proceed to step r1. q2. Recursively determine if there exists a Q such that If yes, proceed to step r2; otherwise, proceed to step r1. r1. Command ,represent Proceed to step s; r2. Let ,represent Proceed to step s; s. Output res, the algorithm ends; Where ≡ represents the structural congruence relation between processes, and the relevant properties are: ； → represents a reduction relationship between processes, →* represents a reflexive transitive closure of the reduction relationship, and the relevant properties are: ； ↓ indicates a nested relationship between processes. Then P↓Q,↓* represents the reflexive transitive closure of the nested relationship.

3. The formal verification method for mobile IoT applications according to claim 2, characterized in that, In step 4, if the model of the mobile IoT application operation scenario satisfies all the boundary process logic formulas in the set of boundary process logic formulas, it indicates that all the properties of the IoT application operation scenario are satisfied, and the formal verification of the mobile IoT application ends. If the model of the mobile IoT application's operating scenario does not satisfy some of the boundary process logic formulas in the set of boundary process logic formulas, it indicates that there are properties that cannot be satisfied in the current scenario. The location of the device deployment and / or the action rules should be modified, and the process should be returned to step 1.

4. A formal verification system for mobile Internet of Things (IoT) applications, characterized in that, Based on the formal verification method for mobile IoT applications as described in any one of claims 1-3, formal verification for mobile IoT applications is achieved.

5. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it performs formal verification for mobile Internet of Things (IoT) applications based on the formal verification method for mobile IoT applications as described in any one of claims 1-3.

6. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, formal verification for mobile Internet of Things (IoT) applications is performed based on the formal verification method for mobile IoT applications as described in any one of claims 1-3.

Images