Formal Verification of Multi-Thread Minimax Behavior Using mCRL2 in the Connect 4

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

-=- Summary -=-
This papers aims to formally model and verify parallel implementations of the minimax algorithm for computing optimal strategies in games. Since executing the minimax algorithm on the full game is linear in the number of possible game states, parallel implementations may help to combat the often exponential blowup in states. However, it is not evident that these parallel implementations function correctly. Thus, this paper provides an mCRL2 model of a parallel minimax implementation and verifies it using the mCRL2 toolkit.

-=- Scope -=-
The topic of this paper seems to fall within the scope of the journal, since 'computer science' is listed as one of the topics of the journal and formal verification is rooted in mathematics.

-=- Presentation -=-
The paper is generally easy to read and is well structured. The paper is not self-contained, since it implicitly assumes knowledge of mCRL2's syntax and semantics.

I think there are places where the paper would benefit from being more concrete and/or formal. For example, the multi-threaded minimax algorithm that the paper investigates is only given by means of a natural language description, while it would be much more insightful to include pseudo-code. This makes it clear what we are actually dealing with.

-=- Validation -=-
The setup of the experiments is not described in very much detail. Only table 1 shows that all properties hold. How these results were obtained is not clear from the paper.

The models are provided via Github. I attempted to run this model through the mCRL2 toolset, but often got stuck since the term rewrite system given by the data specification does not always terminate. This leads to tools that do not terminate or end in a stack overflow.

-=- Contribution -=-
While the contributions set out in the introduction are clear, I have reservations about what is ultimately presented.

The behaviour that is modelled in the mCRL2 model seems to be rather straightforward, namely a collection of 7 threads that act more or less independently and ultimately join by collectively executing the backtracking and defSuccessor actions. It does not feel like this is the kind of complex protocol that requires verification.

Moreover, I have doubts about the correctness of the temporal formulas that are provided in Section 4.7. In particular the formulas of 4.7.2 and 4.7.3 seem to formalise something different than intended. See my detailed comments below.

-=- Detailed comments -=-
Currently, the mCRL2 data specification (on pages 6-7) is given in a mix of mathematical notation and the corresponding ASCII notation. An example where you use mathematical notation is \mathbb{N} (instead of Nat, the ASCII representation). On the other hand, in mCRL2 equality on data is \approx, while its ASCII representation is ==. Likewise, the cons constructor for lists is \triangleright in maths and |> in ASCII. I think this should be made consistent.

The mCRL2 model for Connect Four contains parameters Rows and Columns that give the size of the board, but the model is not fully parametric in the sense that only changing these parameters is sufficient to actually obtain a smaller/bigger board. In other words, the size of the board is actually hard coded in several places of the data specification. The mCRL2 repository actually contains a fully parametric version of Connect Four, so I wonder why you have not simply re-used that model.

From the paper it is not clear why the proposed communication structure was chosen. In the model, actions min and max either happen alone or are done by 7 threads at the same time. Why is it not allowed for, e.g., 4 min actions to happen simultaneously?

The formula [!defSuccessorGen*]<true>true expresses that after any sequence of actions not containing defSuccessorGen it is possible to execute another action. The formulation on lines 230-231 is not accurate.

Also the liveness formula of Section 4.7.2 is also not accurately represented in text. The given formula expresses that "After performing a single min/max step, a defSuccessorGen action must unavoidably happen within a finite number of steps".

The first formula in Section 4.7.3 expresses that "at any point, after performing max(x,y,z,m), there is a trace consisting of different actions ending in defSuccessorGen". Thus, I do not think that this properly captures the desired property that actions cannot be repeated in the future.

-=- Minor points -=-
l.21: Sentence ends with two dots
l.23: Sentence ends with two dots
l.97: "the absence of deadlocks, the ability to reach terminal states" These two things seem to contradict each other.
l.110: "The number of states generated at each system level" At this point I do not quite understand what a system level is
l.152: "4.3.1. Especificación del dato turno" Please use only English
l.157: "the turn data type" The specification actually gives a token data type
l.157, equation: "map = next : turn → turn;" remove the = sign
l.173, equation: And "eqn" keyword is missing
l.187: "According to the two versions made" It is unclear at this point what versions you are referring to. Also the remainder of the paper does not really come back to this point.
l.218: "the blocking operator" -> the allow operator
l.229: "4.7.1. Ausencia de Deadlocks"
l.273: Please use English
l.314: "the blocking operator" -> allow operator

Author Response

For research article

Response to Reviewer 1 Comments

1. Summary        
We sincerely appreciate the time and effort you have invested in reviewing our manuscript. Your feedback has been instrumental in enhancing the quality of our work. Below, you will find our detailed responses to each of your comments, along with the corresponding revisions highlighted in the re-submitted files. We have endeavored to address your suggestions comprehensively, while also providing justification for instances where we maintained the original approach. Thank you for your constructive and thoughtful comments.

2. Point-by-point response to Comments and Suggestions for Authors

Comments 1: The paper is generally easy to read and is well structured. The paper is not self-contained, since it implicitly assumes knowledge of mCRL2’s syntax and semantics.
Response 1: The theoretical basis of process algebra and mCRL2 was not included due to its length to avoid making the paper too long; however, a line is added in the introduction about that requires previous knowledge of these to read the paper.

Comments 2: I think there are places where the paper would benefit from being more concrete and/or formal. For example, the multi-threaded minimax algorithm that the paper investigates is only given by means of a natural language description, while it would be much more insightful to include pseudo-code. This makes it clear what we are dealing with.
Response 2: Thank you for your suggestion. I agree that including pseudo-code would make the algorithm clearer. Therefore, we have added a description of the pseudocode of the algorithm. This change can be found in lines 164-167.

Comments 3: The setup of the experiments is not described in very much detail. Only table 1 shows that all properties hold. How these results were obtained is not clear from the paper.
Response 3: Thank you for your comment. I agree that more details about the experiment setup are necessary. Therefore, I have added a brief description of how the verification tests were performed. This change can be found in lines 311-321.

Comments 4: The models are provided via GitHub. I attempted to run this model through the mCRL2 toolset, but often got stuck since the term rewrite system given by the data specification does not always terminate. This leads to tools that do not terminate or end in a stack overflow.
Response 4: Thank you for your feedback. we have addressed this issue by adding a screenshot with the configuration set to generate the .lps file in the readme of the repository.

Comments 5: The behavior that is modelled in the mCRL2 model seems to be rather straightforward, namely a collection of 7 threads that act more or less independently and ultimately join by collectively executing the backtracking and defSuccessor actions. It does not feel like this is the kind of complex protocol that require verification.
Response 5: Thank you for pointing this out. we agree with this comment. Therefore, we have added a justification of the technological innovation and the difficulty of verification in the introduction. This change can be found in lines 42-63.

Comments 6: Currently, the mCRL2 data specification (on pages 6-7) is given in a mix of mathematical notation and the corresponding ASCII notation. An example where you use mathematical notation is \mathbb{N} (instead of Nat, the ASCII representation). On the other hand, in mCRL2 equality on data is \approx, while its ASCII representation is ==. Likewise, the cons constructor for lists is \triangleright in maths and |> in ASCII. I think this should be made consistent.
Response 6: Thank you for your suggestion. we agree that making the notation consistent would be beneficial. Therefore, we have taken all equations to mathematical notation. This change can be found in Pages 7-9.

Comments 7: The mCRL2 model for Connect Four contains parameters Rows and Columns that give the size of the board, but the model is not fully parametric in the sense that only changing these parameters is sufficient to actually obtain a smaller/bigger board. In other words, the size of the board is actually hard coded in several places of the data specification. The mCRL2 repository actually contains a fully parametric version of Connect Four, so I wonder why you have not simply re-used that model.
Response 7: Thank you for pointing this out. By mistake, a specification of the Connect 4 game was added to the repository, which refers to a test that was done but is not part of the paper. This was removed from the repository, making the data model of the board and the game a single file.

Comments 8: From the paper it is not clear why the proposed communication structure was chosen. In the model, actions min and max either happen alone or are done by 7 threads at the same time. Why is it not allowed for, e.g., 4 min actions to happen simultaneously?
Response 8: Thank you for your feedback. we have added the justification for this in the respective lines. This change can be found in lines 250-254.

Comments 9: The formula [!defSuccessorGen*]<true>true expresses that after any sequence of actions not containing defSuccessorGen it is possible to execute another action. The formulation on lines 230-231 is not accurate.
Response 9: Thank you for your observation. we have corrected the wording of the property description. This change can be found in lines 262-266.

Comments 10: Also the liveness formula of Section 4.7.2 is also not accurately represented in text. The given formula expresses that 'After performing a single min/max step, a defSuccessorGen action must unavoidably happen within a finite number of steps.'
Response 10: Thank you for pointing this out. we have corrected the wording as mentioned. This change can be found in lines 268-271.

Comments 11: The first formula in Section 4.7.3 expresses that "at any point, after performing max(x,y,z,m), there is a trace consisting of different actions ending in defSuccessorGen". Thus, I do not think that this properly captures the desired property that actions cannot be repeated in the future.
Response 11: Thank you for your feedback. Given the observation, we have revised and reformulated the safety properties. This change can be found in lines 281-285.

Reviewer 2 Report

Comments and Suggestions for Authors

Minmax is primarily used for the decision-making process in adversarial games, and as the complexity of the game increases (deeper search trees and more states), the computational cost of the Minimax algorithm significantly increases. To reduce the computation time, researchers have tried to parallelize Minimax. Multi-threaded parallelization allows different subsequent states to be calculated simultaneously in different threads, improving efficiency. This paper uses the mCRL2 modeling language and toolset to formally verify the multi-threaded Minimax algorithm's behavior in the Connect 4 game, with the research goal of ensuring correctness in concurrent execution environments. The key properties verified include: (1) No deadlocks: the algorithm will not stall in any state; (2) Liveness: the algorithm will not enter meaningless loops; (3) Security: avoiding repetitive or inconsistent operations; and (4) Coherence in the growth of states: controlling the growth of the state space to stay within expected ranges. Using Connect 4 as a case study, the paper proves that the model can effectively be applied to real-world problems and provides a means of verifying parallel AI algorithms.

Parallelization Strategy: Each thread processes one subsequent state (i.e., the direct child node of the root node), and each thread runs the Minimax algorithm independently to calculate the score of the corresponding substate. After all threads have completed, the results are traced back to the root.

 

 On page 7, the function "isFinal(b) = isWinner(b, X) ∧ isWinner(b, O)∧ ∃row, column:N.(row < Rows ∧ column < Columns ∧ b.row.column = void)" is used to determine if the game is over, but the condition is written as both player X and player O winning the game and there being an empty square on the board to determine if the game is over. This judgment is problematic, as it is impossible for two players to win simultaneously in this game, and it is considered a draw when there are no empty squares on the board. Here, it should be written as "isFinal(b) = isWinner(b, X) ∨ isWinner(b, O) ∨ (¬∃row,column:N.(row < Rows ∧ column < Columns ∧ b.row.column = void))", meaning that either player O or player X wins, or the game is a draw due to the board being full.

 

Suggestion 1: The ProcessPool describes how a thread handles the current board state, specifically by checking whether column c is available (has an empty square) and whether the recursion depth allows further search. If a column is full but still calls ProcessPool, it will waste computing resources. It is suggested to add a pre-check logic to skip over full columns.

 

Suggestion 2: Even though the state growth consistency is controlled by validating the state generation, in complex games (such as chess or larger boards), the Minimax algorithm's state count will grow exponentially with depth. Even with parallel computation using multiple threads, there may still be a bottleneck in computing resources and memory consumption. When multiple threads access shared resources or state concurrently, it may result in race conditions, affecting performance.

Author Response

For research article

Response to Reviewer 2 Comments

1. Summary        
We sincerely appreciate the time and effort you have invested in reviewing our manuscript. Your feedback has been instrumental in enhancing the quality of our work. Below, you will find our detailed responses to each of your comments, along with the corresponding revisions highlighted in the re-submitted files. We have endeavored to address your suggestions comprehensively, while also providing justification for instances where we maintained the original approach. Thank you for your constructive and thoughtful comments.

2. Point-by-point response to Comments and Suggestions for Authors

Comments 1: “On page 7, the function "isFinal(b) = isWinner(b, X) ∧ isWinner(b, O)∧ ∃row, column:N.(row < Rows ∧ column < Columns ∧ b.row.column = void)" is used to determine if the game is over, but the condition is written as both player X and player O winning the game and there being an empty square on the board to determine if the game is over. This judgment is problematic, as it is impossible for two players to win simultaneously in this game, and it is considered a draw when there are no empty squares on the board. Here, it should be written as "isFinal(b) = isWinner(b, X) ∨ isWinner(b, O) ∨ (¬∃row,column:N.(row < Rows ∧ column < Columns ∧ b.row.column = void))", meaning that either player O or player X wins, or the game is a draw due to the board being full.”

Response 1: Thank you for pointing this out. Correction of the function is accepted due to an involuntary error in transcription. This change can be found in line 204.

Comments 2: The ProcessPool describes how a thread handles the current board state, specifically by checking whether column c is available (has an empty square) and whether the recursion depth allows further search. If a column is full but still called ProcessPool, it will waste computing resources. It is suggested to add a pre-check logic to skip over full columns.

Response 2: Thank you for your suggestion. In the ProcessPool process, we have performed this validation in the execution using this line in the specification in mCRL2 (void in getCol(column) && depth < maxDepth); it was already implemented, as can be seen in line 234.

Comments 3: Even though the state growth consistency is controlled by validating the state generation, in complex games (such as chess or larger boards), the Minimax algorithm’s state growth will grow exponentially with depth. Even with parallel computation using multiple threads, the state level may still be a bottleneck in computing resources and memory consumption. When multiple threads access the same resources, it may cause delays.

Response 3: Thank you for your observation. The state count of the Minimax algorithm will grow exponentially with depth. Even with parallel computing using multiple threads, as mentioned, the state level is limited by a maximum search depth level for this case study. This consideration has been noted.

Reviewer 3 Report

Comments and Suggestions for Authors

This paper reports the attempt to apply model checking to an algorithm intended to be used for two-player perfect-information-game-like programs.

 

Technological novelty: Model checking is a well-established technology. Simply applying model checking to a particular algorithm does not contribute to the advancement of the technology. The paper does not clearly articulate the technological novelty in the attempt. 

 

Algorithm presentation: The algorithm under verification is a parallel minimax algorithm. The paper does not provide a clear description of the algorithm, except for a flow chart-like illustration. Hence, it is not possible for readers to comprehend how it works, and, in turn, it is not possible to judge whether the proposed modeling is correct or not.

 

Difficulty in verification: As far as can be imagined from the textual description and the illustration, the algorithm is a simple fork-join style algorithm, where different threads never mutually interact until they meet at the join point. If this is the case, no race condition occurs, and its correctness regarding control (not data) seems straightforward. 

 

Properties verified: Several properties were verified in this study. Four of them are claimed to be security properties. However, they are not related to any security features or issues, such as authentication, encryption,  access control, vulnerabilities, etc.

 

Presentation of modeling formalism: Almost nothing is described about the modeling language. This severely limits readers' understanding of the models presented. 

Author Response

For research article

Response to Reviewer 3 Comments

1. Summary        
We sincerely appreciate the time and effort you have invested in reviewing our manuscript. Your feedback has been instrumental in enhancing the quality of our work. Below, you will find our detailed responses to each of your comments, along with the corresponding revisions highlighted in the re-submitted files. We have endeavored to address your suggestions comprehensively, while also providing justification for instances where we maintained the original approach. Thank you for your constructive and thoughtful comments.

2. Point-by-point response to Comments and Suggestions for Authors

Comments 1: Technological novelty: Model checking is a well-established technology. Simply applying model checking to a particular algorithm does not contribute to the advancement of technology. The paper does not clearly articulate the technological novelty in the attempt.

Response 1: Thank you for your comment. A justification of the technological innovation and the difficulty of verification has been added to the introduction. This change can be found in lines 42-63.

Comments 2: Algorithm presentation: The algorithm under verification is a parallel minimax algorithm. The paper does not provide a clear description of the algorithm, except for a flow chart-like illustration. Hence, it is not possible for readers to comprehend how it works, and, in turn, it is not possible to judge whether the proposed modeling is correct or not.

Response 2: Thank you for your observation. A description of the algorithm’s pseudocode has been added as suggested by reviewer 1. This change can be found in lines 164-167.

Comments 3: Difficulty in verification: As far as can be imagined from the textual description and the illustration, the algorithm is a simple fork-join style algorithm, where different threads never mutually interact until they meet at the join point. If this is the case, no race condition occurs, and its correctness regarding control (not data) seems straightforward.

Response 3: Thank you for pointing this out. A justification of the technological innovation and the difficulty of verification has been added to the introduction. This change can be found in lines 42-63.

Comments 4: Properties verified: Several properties were verified in this study. Four of them are claimed to be security properties. However, they are not related to any security features or issues, such as authentication, encryption, access control, vulnerabilities, etc.

Response 4: Thank you for your comment. Due to an error in the translation of the paper into English, the properties were written as security, and this was corrected to the current denomination, which is safety. These properties, in the light of process algebra, usually say that something bad will never happen, as mentioned in [5]. For this reason, the properties of this research fall within this definition and are not related to security issues such as authentication, encryption, access control, vulnerabilities, etc.

Comments 5: Presentation of modeling formalism: Almost nothing is described about the modeling language. This severely limits readers’ understanding of the models presented.
Response 5: Thank you for your feedback. The theoretical basis of process algebra and mCRL2 was not included due to its length to avoid making the paper too long. However, a line is added in the introduction about that requires previous knowledge of these to read the paper.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

-=- Revisions -=-
I would like to thank the authors for the detailed response and their efforts in addressing my comments. I think most of my comments have been addressed adequately, but a few issues remain that I believe need to be resolved before publication. In particular, I believe it is important to get the mu-calculus formulas and their descriptions right, since these are a core part of the paper. See below for my detailed comments.

The paragraph about supporting the field of formal verification in the local academic landscape appealed positively to me.

-=- Detailed comments -=-
Algorithms 1 and 2 seemingly implement a recursive procedure. However, it is unclear how they terminate. The currentDepth parameter is not increased anywhere (which is counter-intuitive) and the state.depth variable is not explained.

Table 1 is missing a significant amount of context. It is not clear what is measured exactly and what conclusions should be drawn from these figures. In my opinion, it is not necessary to illustrate the benefits of parallel algorithms in this paper, a citation would suffice (like, for example, Leiserson et al. "There’s plenty of room at the Top: What will drive computer performance after Moore’s law?." Science 368.6495 (2020): eaam9744.)

There are still a couple of issues related to the formulas and their explanation. In Section 4.7.2 you mention things like "it must be possible" and "the defSuccessorGen action is eventually reachable". Both these characterisations are strictly weaker than what the formula states, which is that the defSuccessorGen action must unavoidably occur. In Section 4.7.3, the formulas does not correspond to those in the Github repo (the repo is correct, these are not). In 4.7.4, the added value of the fixpoint \nu X is unclear; at the moment it does not seem to add anything to the validity of the formula.

Details have been added to the experimental section, but the description remains somewhat high-level (for example, l.319 "optimization tools are used to improve efficiency"). If there are crucial steps necessary for reproducing the results, then it would be good to be more specific. If you have measured the runtimes, then I also suggest adding those.

-=- Minor remarks -=-
l.64 "a prior knowledge" -> prior knowledge
Still ASCII notation is used in some places. For example <= after l.239 and <| after line 242.
l.279 "in The future" -> in the future
l.297 "Succesor" -> successor
l.297 <= -> \leq
l.312 "-Calculus" -> \mu-calculus
l.313 ".mfc" -> ".mcf" (stands for mu-calculus formula)

Author Response

For research article

Response to Reviewer 1 Comments

Summary
We sincerely appreciate the time and effort you have invested in reviewing our manuscript. Your feedback has been instrumental in enhancing the quality of our work. Below, you will find our detailed responses to each of your comments, along with the corresponding revisions highlighted in the re-submitted files. We have endeavored to address your suggestions comprehensively, while also providing justification for instances where we maintained the original approach. Thank you for your constructive and thoughtful comments.

Point-by-point response to Comments and Suggestions for Authors

Comments 1:Algorithms 1 and 2 seemingly implement a recursive procedure. However, it is unclear how they terminate. The currentDepth parameter is not increased anywhere (which is counter-intuitive) and the state.depth variable is not explained.
Response 1: The suggestion is accepted. In fact, the formulation in pseudocode was incorrect; therefore, a correction is made so that it is clearly understood. (Line 173).

Comments 2: Table 1 is missing a significant amount of context. It is not clear what is measured exactly and what conclusions should be drawn from these figures. In my opinion, it is not necessary to illustrate the benefits of parallel algorithms in this paper, a citation would suffice (like, for example, Leiserson et al. ’There’s plenty of room at the Top: What will drive computer performance after Moore’s law?. ’ Science 368.6495 (2020): eaam9744.)
Response 2: The suggestion is accepted. Table 1 was removed, and we used a reference for explaining the benefits of parallel algorithms as requested by the reviewer. (Lines 153- 157).

Comments 3: There are still a couple of issues related to the formulas and their explanation. In Section 4.7.2 you mention things like ’it must be possible’ and ’the defSuccessorGen action is eventually reachable’. Both these characterisations are strictly weaker than what the formula states, which is that the defSuccessorGen action must unavoidably occur.
Response 3: The observation is accepted, it is modified by using a stronger textual expression when interpreting the formula. (Lines 273 - 282).

Comments 4: In Section 4.7.3, the formulas does not correspond to those in the Github repo (the repo is correct, these are not).
Response 4: Properties have been corrected according to what is in the repository. (Lines 287 - 291).

Comments 5: In 4.7.4, the added value of the fixpoint \nu X is unclear; at the moment it does not seem to add anything to the validity of the formula.
Response 5: It is reviewed and it does not contribute to the validity of the formula. Therefore, the fixed-point operator \nu is removed from such a formula. (Lines 303 - 304).

Comments 6: Details have been added to the experimental section, but the description remains somewhat high-level (for example, l.319 ’optimization tools are used to improve efficiency’). If there are crucial steps necessary for reproducing the results, then it would be good to be more specific. If you have measured the runtimes, then I also suggest adding those.
Response 6: Suggestion accepted. The section 4.9 was extended to explain in more detail how the property verification was performed. (Lines 318 - 342).

Comments 7: 

 -=- Minor remarks -=-
l.64 ’a prior knowledge’ -> prior knowledge
Still ASCII notation is used in some places. For example <= after l.239 and <| after line 242.
l.279 ’in The future’ -> in the future
l.297 ’Succesor’ -> successor
l.297 <= -> \leq
l.312 ’-Calculus’ -> \mu-calculus
l.313 ’.mfc’ -> ’.mcf’ (stands for mu-calculus formula)

Response 7: Everything was corrected as requested. ( Line 65, Line 244 and 247,Line 285,Line 303,Line 303).

Reviewer 3 Report

Comments and Suggestions for Authors

Basically, the issues with the study that I pointed out in the first round of review still pertain, but, as the authors claim in the revised version, if the study contributes to the technological advances of local society, I would not oppose accepting the paper for publication, subject to the condition that revisions are appropritately made to address the following issues as follows.

 

Page 3: 3.4 lists properties that are verified. However, they do not match the later part of the paper. For example, liveness is not included. Also, 3.3 and 3.4 are also inconsistent with respect to properties considered. These inconsistencies must be resolved.

Page  3, lines 135-137: This sentence cannot be parsed. Please rewrite this.

Page 3, line 138: "safety" -> "Safety"

Page 4, Figure 1: This is NOT a flowchart. Please redraw the chart or correct the caption so that it can accurately describe the chart. 

Page 4, line 164 and Page 5: The way of presenting Algorithms 1 and 2 is weird. These algorithms should not be embedded directly within the regular text of the paper.

Lines 277-280. "safety" -> "Safety" The first sentence of 4.7.3 contains at least two typos ("and" -> dele, "The" -> "the"). 

Line 290. No period at the end of a sentence.

Author Response

For research article

Response to Reviewer 3 Comments

Summary
We sincerely appreciate the time and effort you have invested in reviewing our manuscript. Your feedback has been instrumental in enhancing the quality of our work. Below, you will find our detailed responses to each of your comments, along with the corresponding revisions highlighted in the re-submitted files. We have endeavored to address your suggestions comprehensively, while also providing justification for instances where we maintained the original approach. Thank you for your constructive and thoughtful comments.

Point-by-point response to Comments and Suggestions for Authors

Comments 1: Page 3: 3.4 lists properties that are verified. However, they do not match the later part of the paper. For example, liveness is not included. Also, 3.3 and 3.4 are also inconsistent with respect to properties considered. These inconsistencies must be resolved.
Response 1: The suggestion is accepted. The inconsistencies are fixed by adding the specific properties verified in the research. (Lines 121 – 125 and 132 - 142).

Comments 2: Page 3, lines 135-137: This sentence cannot be parsed. Please rewrite this.
Response 2: The suggestion is accepted. The sentence is rewritten. (Lines 140 -142).

Comments 3: Page 3, line 138: ’safety’ -> ’Safety’
Response 3: The typo is fixed on its respective line. (Line 137).

Comments 4: Page 4, Figure 1: This is NOT a flowchart. Please redraw the chart or correct the caption so that it can accurately describe the chart.
Response 4: “Flowchart” is changed to ‘Scheme’. (Page 4, Figure 1).

Comments 5: Page 4, line 164 and Page 5: The way of presenting Algorithms 1 and 2 is weird. These algorithms should not be embedded directly within the regular text of the paper.
Response 5: The text in the middle of the algorithms is removed and a paragraph is placed at the beginning. (Lines 171- 173).

Comments 6: Lines 277-280. ’safety’ -> ’Safety’ The first sentence of 4.7.3 contains at least two typos (’and’ -> dele, ’The’ -> ’the’).
Response 6: Typos errors are corrected (Lines 284 -287).

Comments 7: Line 290. No period at the end of a sentence.
Response 7: The missing punctuation mark is added. (Line 296).