A Framework for Model and Verification of Safety-Critical Operating System Based on ARINC653
Hoon Ko
Round 1
Reviewer 1 Report
Review comment have been addressed enough for my acceptance of the paper.
Author Response
Point 1: Review comment have been addressed enough for my acceptance of the paper.
Response 1: Thank you very much for your support and positive comments. We are grateful for your contribution of time and insightful suggestions. We have revised the article abstract、section 3、section 4, section 7. We have added a more detailed description of our work.
Reviewer 2 Report
This is to work a framework for model and verification of safety-critical operation system based on ARINC653. It looks interested but I have to decide major-revision to this paper for next reasons,
- This is based on ARINC653, but what ARINC653 is not enough. Surely, there is for ARINC653 in subsection 3.1, however it is weak description for this paper. The authors need to add more write in detail.
- It is not clear why the authors decided to write this paper. The Authors need to add more sentences in abstract such as existing problem, suggesting idea, and results simply and in impact.
- In Section 4. Overview, there is a figure 4 Model and verification architecture. Some labels are in red. Any differences?
- Is there a structure of context table in this paper?
- This model contains some blocks, maybe I guess each block is an each step, but the descriptions for figure 1 are very weak.
- I think the figure 1 in section 4 and section 5 methodology should be connected logically. However two parts looks separated.
- Evaluation section needs more pages and the results has only table 2. The authors need more analysis and add more in evaluation section.
Author Response
Point 1: This is based on ARINC653, but what ARINC653 is not enough. Surely, there is for ARINC653 in subsection 3.1, however it is weak description for this paper. The authors need to add more write in detail.
Response 1: Thank you very much for the support and positive comments. We are grateful for your contribution of time and insightful suggestions. We have added a more detailed description to the description of ARINC653 in Section 3.
Point 2: It is not clear why the authors decided to write this paper. The Authors need to add more sentences in abstract such as existing problem, suggesting idea, and results simply and in impact.
Response 2: Thank you very much for your comments . We revised the abstract based on comments. The revised abstract is as follows:
“As the scale and complexity of safety-critical software continue to grow, it is necessary to ensure safety and reliability to avoid minor errors leading to catastrophic disasters. Meantime, the traditional method, such as testing and simulation alone is insufficient to ensure the correctness of systems. This leads to using formal methods to provide sufficient evidence for systems. However, design a high assurance safety-critical system by formal methods is challenging due to the complexity of operating systems. Also, the traditional interactive theorem prover used in system verification requires hand-written proofs, which are more expensive. Therefore, the efforts of providing a standardized formal framework as well as safety proofs, are notable for the develop a safety-critical system. The purpose of this paper is to provide a safety framework to establish a highly reliable and safety-critical operating system based on the ARINC653 standard, a multilevel and standardized formal model. To verify the functional correctness of this model, we propose a context-based formal proof method for programs. To achieve this goal, we first model 57 core services of ARINC653 and define the high-level requirements as pre-and post-conditions. Then, we construct a set of specification statements a formal axiom system transformed into logical sentences, and the core service model is transformed into a logical sentence sequence to be proved. Finally, a context-based formal proof system for specification correctness is developed. We have verified the correctness of safety-critical operating system core services with this system. Experience shows that the verification system of we developed can be achieved the functional correctness of a complete OS with a low implement burden, and that can simplify the difficulty of automated verification and increase the degree of automation of proof.”
Point 3: In Section 4. Overview, there is a figure 4 Model and verification architecture. Some labels are in red. Any differences?
- Is there a structure of context table in this paper?
- This model contains some blocks, maybe I guess each block is an each step, but the descriptions for figure 1 are very weak.
Response 3: Thank you very much for your comments. Figure 1 has been modified. We have modified the red color of labels. The context table is described in Table 1.We have added some detailed descriptions of Figure 1 in section 4(Line 272- 283).
Point 4: I think figure 1 in section 4 and section 5 methodology should be connected logically. However, two parts look separated.
Response 4: Thank you very much for the support and positive comments. We are grateful for your contribution of time and insightful suggestions. We further refined this paper to make it clearer and more logical. According to the comments, we have made part changes to the content of section 4 (Line 284-300).
Point 5: Evaluation section needs more pages and the results has only table 2. The authors need more analysis and add more in evaluation section.
Response 5: Thank you very much for your attention, comments and questions. We have added analysis in the evaluation section (Line 537-550, Line 553-559, Line 562-564).
Round 2
Reviewer 2 Report
I think this paper followed the first’s review comments, I pleased for my acceptance to this paper. But some sentences are not smooth, just I would like the authors to update the unsmooth sentences in this paper.
This manuscript is a resubmission of an earlier submission. The following is a list of the peer review reports and author responses from that submission.
Round 1
Reviewer 1 Report
The paper claims to formally verify an ARINC653 operating system. Since ARINC653 is a standard on how to develop such operating systems, it remains unclear which operating system has been verified?
The proposed method is based on the "formal proof for program correctness based on context" (lines 60,61). Still, Figure 1 uses the ARINC653 "Specification". It makes a big difference whether a specification or a software source code is verified. This needs to be explicitly stated in the paper! If you use a specification as input, design/create your own program out of it, and verify this program in the end it does not say much about the specification ...
The approach is based on the analysis of the states (see lines 267-272). There is no discussion of the feasibility of this idea. The state of a full operating system would include the complete hard-disc as well. Thus, after very few states you will run int memory shortage issues ... How do you address these issues with your approach?
Section 6 is very hard to read. What were the initial requirements from ARINC653? What exactly is now checked/verified by your algorithm (see Fig. 2 and Fig. 3)?
Your evaluation delivers no results. Did you finally verify ARINC653? If so what errors did you find? Or, was everything perfect?
- what is the "f program" in the paragraph above line 274?
- Incomplete sentence "Constraints in." (line 380)
Author Response
Response to Reviewer 1 Comments
Point 1: The paper claims to formally verify an ARINC653 operating system. Since ARINC653 is a standard on how to develop such operating systems, it remains unclear which operating system has been verified?
Response 1: Thank you very much for the support and positive comments. We are grateful for your contribution of time and insightful suggestions. We further refined this paper to make it clearer and more logical. This paper designs the core services and basic functions of the lightweight operating system based on the system requirements specified by the existing ARINC653 avionics application software standard interface. We model 57 core services and verify the correctness of the program.
Point 1:The proposed method is based on the "formal proof for program correctness based on context" (lines 60,61). Still, Figure 1 uses the ARINC653 "Specification". It makes a big difference whether a specification or a software source code is verified. This needs to be explicitly stated in the paper! If you use a specification as input, design/create your own program out of it, and verify this program in the end it does not say much about the specification
Response 2: Thank you very much for your comments. Figure 1 has been modified. A formal specification can also be understood as a program, which is a program written in an abstract modeling language.
Point 3: The approach is based on the analysis of the states (see lines 267-272). There is no discussion of the feasibility of this idea. The state of a full operating system would include the complete hard-disc as well. Thus, after very few states you will run int memory shortage issues ... How do you address these issues with your approach?
Response 3: Our approach is not based on the analysis of the states. The execution process of the program is essentially the process of modifying the context variables. Assuming that a certain context is Contextn before the program is executed, a new context Contextn+1 is formed after the program is executed. The context here only records the value of the variable and does not record the constraint relationship of the variable.
Point 4: Section 6 is very hard to read. What were the initial requirements from ARINC653? What exactly is now checked/verified by your algorithm (see Fig. 2 and Fig. 3)?
Response 4: Thank you very much for your attention, comments and questions. The document "Avionics Application Software Standard Interface Set "Part 1, defines “Required Services.” Part 1 constitutes the basic requirements and guidance for an ARINC 653 compliant O/S API. The system requirements in this article are the service requirements in the ARINC653 specification, which are expressed in the form of narratives. The output and system status of the core service will change with the input of the service. On the basis of fully understanding the system requirements, we have summarized the mapping of the input and output of each sub-service in the ARINC653 core service, which is represented by a first-order logic expression. The Expression has accurate semantics, which eliminates the ambiguity and ambiguity in the description of system service functions, and forms the pre-and post-conditions of the service. Take this as the high-level requirement in the software requirements. We establish a software requirement model in the low-level requirement stage and use an abstract modeling language to establish a low-level requirement software model based on the above-mentioned system requirements and precisely described high-level requirements. Fig. 2 is the specification of low-level requirements for of GET_PROCES. Fig3 is a set of semantic conversion rules. We use this rule to convert abstract language programs into first-order logic sentence sequences, and then verify the logic sequence through the formal axiom system. We add the proof result in subsection 5.2.
Point 5: Your evaluation delivers no results. Did you finally verify ARINC653? If so what errors did you find? Or, was everything perfect?
Response 5 : Thank you very much for your comments . Our framework is based on the modeling of 57 core services of ARINC653 operating system and describes high-level requirements as pre- and post-conditional forms; then a set of formal axiom systems that transform program statements into logical statements are constructed, and the core service model is transformed into logical statements. The sequence is yet to be proved. The framework uses formal methods for system development and can verify whether the modeling program meets the system requirements defined in the ARINC653 standard.
Point 6: what is the "f program" in the paragraph above line 274?
Response 6 : Thank you for underlining this deficiency. In this paper, Г denotes the program to be proven. We added a description about Г in subsection 5.2.
Point 7: Incomplete sentence "Constraints in." (line 380)
Response 2: Thank you very much for your carefulness. Sorry, we have such a low-level error. And, we have corrected this error(Line 380, page 12). We promise to be more rigorous and careful in future writing.
Reviewer 2 Report
Content
----------
The goal of this paper is to propose a context-based formal proof method for program correctness.For this purpose, the author practice context to denote the context of program operation and apply abstract high-level requirements into functional models, which are described as pre-and post-conditions. Then, the author exercise the high-level requirement pre-conditions as an initial context of the program to be proved and the formal verification of correctness is to verify the consistency of termination context for the post-conditions of high-level requirement.The author expected that the verification system of we developed can be achieved the functional correctness of a complete OS with a low implement burden, and that can simplify the difficulty of automated verification and increase the degree of automation of proof.
Major comments
--------------
1. The concept of ARINC653 is vague and contradictory.
In the title "ARINC653 Operating System". It seems ARINC653 is OS.
p4. line 149 -- "ARINC653 is an application program interface specification proposed for the integration of avionics system data [7]." Here ARINC is a specification.
Evaluation
--------------
Given the above, I'm in a position to major revision.
Author Response
Point 1:The concept of ARINC653 is vague and contradictory.
In the title "ARINC653 Operating System". It seems ARINC653 is OS.
p4. line 149 -- "ARINC653 is an application program interface specification proposed for the integration of avionics system data [7]." Here ARINC is a specification.
Response 1: Thank you very much for your support and positive comments. We are grateful for your contribution of time and insightful suggestions. We have revised the title of the article as “A Framework for Model and Verification of Safety-critical Operating System Based on ARINC653”. We also modify the expression of "ARINC653 Operating System" in the article.
Round 2
Reviewer 2 Report
The author revised as the the previous comments.
