CN114741123A - Onboard software formal verification system - Google Patents
Onboard software formal verification system Download PDFInfo
- Publication number
- CN114741123A CN114741123A CN202210129476.XA CN202210129476A CN114741123A CN 114741123 A CN114741123 A CN 114741123A CN 202210129476 A CN202210129476 A CN 202210129476A CN 114741123 A CN114741123 A CN 114741123A
- Authority
- CN
- China
- Prior art keywords
- verification
- software
- verification result
- source code
- model
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a formal verification system for airborne software, which comprises: the system comprises a requirement verification result generation module, a source code verification result generation module, a target code verification result generation module and a verification passing module. Therefore, by adopting the embodiment of the application, the verification activity of the airborne software is divided into three stages of requirement and design, source code and executable target code, and for the verification activity of each stage, the verification target defined in DO-333 is combined, and a formalized analysis and verification methodology is provided for verification, so that the safety of the airborne software is improved.
Description
Technical Field
The invention relates to the technical field of airborne software and airworthiness certification, in particular to an airborne software formal verification system.
Background
With the rapid development of the technology of the airborne control system, it is urgent to ensure the reliability, robustness and adaptability of airborne software. Failure of the on-board software can result in catastrophic loss of property and life safety. For on-board systems, it is of utmost importance to ensure their safety. This requires that the on-board software must be subject to strict security certification, meaning that the software artifacts produced at each stage of the on-board software development process need to meet security certification goals. RTCA issued the DO-178B airworthiness certification standard in 1992 to explain the software lifecycle and guide the development and validation process of airborne software. With the continuous increase of the software scale, the complexity of the onboard software is continuously increased, the number of components, modules, interfaces and the like involved in the software is increased, the possibility of software failure is gradually increased, and a serious obstacle is brought to the safety analysis and verification of the onboard software. In recent years, the number of code lines of onboard software has also increased exponentially. For example, the embedded software code on the plane of the army F-35 fighter is up to 1000 ten thousand lines, and the code quantity of the flight control system of the Boeing 787 is over 1000 ten thousand lines.
With the large increase in the size and complexity of the onboard software code, the traditional software verification methods have been unable to meet this increasingly high security requirement.
Disclosure of Invention
The embodiment of the application provides an airborne software formal verification system. The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed embodiments. This summary is not an extensive overview and is intended to neither identify key/critical elements nor delineate the scope of such embodiments. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
In a first aspect, an embodiment of the present application provides an onboard software formal verification system, where the system includes:
the requirement verification result generation module is used for verifying the requirement and the design stage of the airborne software and generating an initial verification result;
the source code verification result generation module is used for verifying the source code stage of the airborne software and generating a source code verification result;
the target code verification result generation module is used for verifying the executable target code stage of the airborne software and generating a target code verification result;
the verification passing module is used for determining that the onboard software passes verification when the initial verification result, the source code verification result and the target code verification result all accord with preset values; wherein the verification process is based on the verification target defined in the DO-333.
Optionally, the requirement verification result generating module includes:
the model building unit is used for building a demand model and a behavior model according to the demand of the airborne software and the data in the design stage;
the behavior model verification unit is used for verifying whether the behavior model meets the formalized property specification of the demand model by adopting a formalized analysis tool;
and if so, the verification result generating unit is used for generating an initial verification result.
Optionally, the model building unit is specifically configured to:
rewriting a system of the airborne software and the requirements and properties of the software by using a formal logic language to form a formal property specification to generate a requirement model of the system;
and establishing a behavior model of the system by using a formal modeling language according to the detailed design description of the system.
Optionally, the source code verification result generating module includes:
the formal model abstraction unit is used for abstracting a formal model from the source code of the airborne software by adopting a model extractor;
the temporal logic protocol rewriting unit is used for rewriting the requirements of the airborne software into temporal logic protocols;
a judgment result generation unit, configured to verify, by using a model checker, whether the formal model satisfies the temporal logic convention, and generate a judgment result;
and the source code verification result generation unit is used for generating a source code verification result based on the judgment result.
Optionally, the determination result generating unit is specifically configured to:
extracting the temporal logic specification into a precondition and a postcondition according to the definition of the requirement;
converting the preconditions and postconditions into target annotations in a C program;
and using a model checker to prove whether the onboard software program meets the target annotation through a deductive reasoning method, and generating a judgment result.
Optionally, the source code verification result generating unit is specifically configured to:
when the judgment result meets the temporal logic protocol, generating a source code verification result;
alternatively, the first and second electrodes may be,
when the judgment result is that the temporal logic convention is not satisfied, generating a counter example;
and judging whether the judgment result is valid according to the path of the counter example.
Optionally, the system further includes:
and the data overflow judging module is used for verifying variables, arrays and pointer elements in the source code by symbol execution, data flow analysis and an abstract interpretation method so as to judge whether the source code has data overflow.
Optionally, the verification is performed on the executable target code phase of the onboard software, and the target code verification result generation module includes:
the first verification unit 301 is configured to verify traceability of an executable target code to a source code of the onboard software by using compiler verification, translation validation and a reverse analysis method;
a second verification unit 302, configured to verify an attribute of the executable target code by using a static analysis method;
a result generating unit 303, configured to generate a target code verification result.
Optionally, in the verification of the executable object code phase of the onboard software, the correctness verification when the compiler verifies is performed based on a semantic equivalence theory.
Optionally, in the verification of the executable target code phase of the onboard software, the idea of translation confirmation is to verify whether the generated target program correctly implements the source program through a program analyzer.
The technical scheme provided by the embodiment of the application can have the following beneficial effects:
in the embodiment of the application, the onboard software formal verification system firstly verifies the requirement and design stages of the onboard software to generate an initial verification result, then verifies the source code stage of the onboard software to generate a source code verification result, secondly verifies the executable target code stage of the onboard software to generate a target code verification result, and finally determines that the onboard software passes the verification when the initial verification result, the source code verification result and the target code verification result all accord with preset values. Therefore, by adopting the embodiment of the application, the verification activity of the airborne software is divided into three stages of requirement and design, source code and executable target code, and for the verification activity of each stage, the verification target defined in DO-333 is combined, and a formalized analysis and verification methodology is provided for verification, so that the safety of the airborne software is improved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.
Fig. 1 is a schematic structural diagram of an onboard software formal verification system provided in an embodiment of the present application;
FIG. 2 is a schematic diagram of a requirement verification result generation module according to an embodiment of the present disclosure;
fig. 3 is a schematic diagram of a source code verification result generation module according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a target code verification result generation module according to an embodiment of the present application;
FIG. 5 is a schematic flowchart of a method for formal verification of onboard software according to an embodiment of the present application;
FIG. 6 is a formal verification diagram of a demand and design phase provided by an embodiment of the present application;
FIG. 7 is a schematic diagram of a model checking applied in a requirement and design phase according to an embodiment of the present application;
FIG. 8 is a schematic diagram illustrating theorem proving applied in the design phase and requirement provided by an embodiment of the present application;
fig. 9 is a formal verification diagram of an executable object code phase provided in an embodiment of the present application.
Detailed Description
The following description and the drawings sufficiently illustrate specific embodiments of the invention to enable those skilled in the art to practice them.
It should be understood that the described embodiments are only some embodiments of the invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of systems and methods consistent with certain aspects of the invention, as detailed in the appended claims.
In the description of the present invention, it is to be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. The specific meanings of the above terms in the present invention can be understood in specific cases to those skilled in the art. In addition, in the description of the present invention, "a plurality" means two or more unless otherwise specified. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
The application provides a formal verification system for airborne software, which is used for solving the problems in the related art. In the technical scheme provided by the application, verification activities of the airborne software are divided into three stages of requirements and design, source codes and executable target codes, and for the verification activities of each stage, a formal analysis and verification methodology is provided for verification by combining verification targets defined in DO-333, so that the safety of the airborne software is improved, and the detailed description is given by adopting an exemplary embodiment.
Referring to fig. 1, a schematic structural diagram of an onboard software formalization verification system according to an exemplary embodiment of the present invention is shown. The onboard software formal verification system may be implemented as all or part of the terminal in software, hardware, or a combination of both. The system 1 comprises a requirement verification result generation module 10, a source code verification result generation module 20, an object code verification result 30 and a verification passing module 40.
The requirement verification result generation module 10 is used for verifying the requirement and the design stage of the airborne software and generating an initial verification result;
a source code verification result generation module 20, configured to verify a source code phase of the airborne software and generate a source code verification result;
a target code verification result generation module 30, configured to verify an executable target code phase of the airborne software, and generate a target code verification result;
the verification passing module 40 is used for determining that the verification of the airborne software is passed when the initial verification result, the source code verification result and the target code verification result all accord with preset values; wherein the verification process is based on the verification target defined in the DO-333.
Optionally, for example, as shown in fig. 2, the requirement verification result generating module 10 includes:
the model building unit 101 is used for building a demand model and a behavior model according to the demand of the airborne software and the data in the design stage;
the behavior model verifying unit 102 is configured to verify whether the behavior model meets a formalized property specification of the demand model by using a formalized analysis tool;
and a verification result generation unit 103, configured to generate an initial verification result if the verification result is positive.
Optionally, the model building unit is specifically configured to: rewriting a system of the airborne software and the requirements and properties of the software by using a formal logic language to form a formal property specification to generate a requirement model of the system; and establishing a behavior model of the system by using a formal modeling language according to the detailed design description of the system.
Optionally, for example, as shown in fig. 3, the source code verification result generating module 20 includes:
a formal model abstraction unit 201, configured to abstract a formal model from a source code of the onboard software by using a model extractor;
the temporal logic protocol rewriting unit 202 is configured to rewrite a requirement of airborne software into a temporal logic protocol;
a judgment result generation unit 203 for verifying whether the formal model satisfies the temporal logic specification by using the model checker, and generating a judgment result;
a source code verification result generation unit 204 for generating a source code verification result based on the judgment result.
Optionally, the determination result generating unit is specifically configured to: extracting the temporal logic specification into a precondition and a postcondition according to the definition of the requirement; converting the pre-condition and post-condition into a target annotation in a C program; and using a model checker to prove whether the onboard software program meets the target annotation or not through a deductive reasoning method, and generating a judgment result.
Optionally, the source code verification result generating unit is specifically configured to: when the judgment result meets the temporal logic protocol, generating a source code verification result; or when the judgment result is that the temporal logic convention is not satisfied, generating a counterexample; and judging whether the judgment result is valid according to the path of the counterexample.
Optionally, the system further includes: and the data overflow judging module is used for verifying variables, arrays and pointer elements in the source code by symbol execution, data flow analysis and an abstract interpretation method so as to judge whether the source code has data overflow.
Optionally, for example, as shown in fig. 4, the target code verification result generating module 30 includes:
the first verification unit 301 is configured to verify traceability of an executable target code to a source code of the onboard software by using compiler verification, translation validation and a reverse analysis method;
a second verification unit 302, configured to verify an attribute of the executable target code by using a static analysis method;
a result generating unit 303, configured to generate a target code verification result.
Optionally, in the verification of the executable object code phase of the onboard software, the correctness verification when the compiler verifies is performed based on a semantic equivalence theory.
Optionally, in the verification of the executable target code phase of the onboard software, the idea of the translation validation is to verify, by a program analyzer, whether the generated target program correctly implements the source program.
It should be noted that, when the onboard software formalization verification system provided in the above embodiment executes the onboard software formalization verification method, only the division of the above functional modules is taken as an example, and in practical application, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above described functions. In addition, the onboard software formal verification system provided by the embodiment and the onboard software formal verification method embodiment belong to the same concept, and the embodiment of the method embodiment shows the implementation process, which is not described herein again.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
In the embodiment of the application, the onboard software formal verification system firstly verifies the requirement and design stages of the onboard software to generate an initial verification result, then verifies the source code stage of the onboard software to generate a source code verification result, secondly verifies the executable target code stage of the onboard software to generate a target code verification result, and finally determines that the onboard software passes the verification when the initial verification result, the source code verification result and the target code verification result all accord with preset values. Therefore, by adopting the embodiment of the application, the verification activity of the airborne software is divided into three stages of requirement and design, source code and executable target code, and the verification activity of each stage is verified by combining the verification target defined in the DO-333 and providing a formal analysis and verification methodology, so that the safety of the airborne software is improved.
The onboard software formal verification method provided by the embodiment of the present application will be described in detail below with reference to fig. 5 to 9. The method may be implemented in dependence on a computer program, operable on an on-board software formal verification system based on the von neumann architecture. The computer program may be integrated into the application or may run as a separate tool-like application.
Referring to fig. 5, a flowchart of a method for verifying an onboard software format is provided according to an embodiment of the present application. As shown in fig. 5, the method of the embodiment of the present application may include the following steps:
s101, verifying the requirement and the design stage of airborne software to generate an initial verification result;
in the embodiment of the application, when the requirement and design stage of the airborne software is verified and an initial verification result is generated, firstly, a requirement model and a behavior model are built according to the requirement and the data of the design stage of the airborne software, and then a formal analysis tool is adopted to verify whether the behavior model meets the formal property specification of the requirement model; and if so, generating an initial verification result.
Further, when a demand model and a behavior model are constructed according to the demand of the airborne software and the data in the design stage, firstly, a formal logic language is used for rewriting a formal property specification of a system of the airborne software and the demand and property of the software to generate the demand model of the system, and then a formal modeling language is used for establishing the behavior model of the system according to the detailed design description of the system.
In one possible implementation, such as shown in fig. 6, the onboard software form verification method proposed in the present application, in which the verification method is performed in the design and requirement phases. The method comprises the following steps: the method comprises the steps of rewriting a system of airborne software and requirements and properties of the software by using a formal logic language to a formed property specification (phi) to generate a requirement model of the system; then, according to the detailed design description of the system, a formal modeling language is used for establishing a behavior model (M) of the system (S); finally, the behavior model (M) is verified to meet the property specification (phi) through a formal analysis tool, namely M is equal to phi, so that whether the system meets the expected functions and attributes of the system is verified.
Specifically, as shown in fig. 7, the model checking method adopted in the demand and design stage is as follows: the verification method of the model checker is to perform exhaustive search on the state space of the established model to verify whether the behavior model of the system can meet the property specification to be verified. FIG. 3 illustrates a verification flow that applies the model checking technique during the requirements and design phases. Firstly, requirements expressed by natural language and system description are rewritten into accurate property specifications and behavior models through formal logic and modeling language, and the property specifications used in model checking are mainly expressed by a temporal logic formula. The property specification and the behavioral model are then input into the respective model checkers for verification. When the proof indicates that the system cannot satisfy the property specification, the model checker will give a corresponding counter-example path. The verifier should analyze according to the counter example path whether the description of the behavior model and the property specification is wrong, and can re-verify after finding the mistake and modifying, otherwise, the original requirement and system design need to be reviewed. Corresponding targets in DO-333 can be verified when the results of the certification indicate that the system satisfies the property specification, this stage referring mainly to the targets in table fm.a-3 and table fm.a-4 in appendix fm.a.
Specifically, as shown in fig. 8, the theorem proving method adopted in the requirement and design stage is as follows: and adopting a formal logic formula to express the properties which should be met by the system to be verified, and then expressing the properties to be verified in a theorem mode. The model of the system is abstracted from the system design and expressed in the forms of propositions, logics, theorems, inference rules and the like, and is described by using the implementation language of a theorem prover. The authentication process of theorem provers can be divided into automatic and interactive processes. The verification work of the interactive theorem prover is to add necessary reasoning rules to axioms and proven theorems and lemmas and apply proving strategies under the operation of a verifier, and generate new theorems and continuously deduce until the defined theorems are proved.
S102, verifying a source code stage of the airborne software to generate a source code verification result;
in the embodiment of the application, when a source code verification result is generated, firstly, a model extractor is adopted to abstract a formal model from a source code of airborne software, then, requirements of the airborne software are rewritten into temporal logic specifications, secondly, a model checker is used to verify whether the formal model meets the temporal logic specifications or not, a judgment result is generated, and finally, the source code verification result is generated based on the judgment result.
Specifically, when the model checker is used for verifying whether the formal model meets a temporal logic specification and generating a judgment result, firstly, the temporal logic specification is extracted into a precondition and a postcondition according to the definition of requirements, then the precondition and the postcondition are converted into a target annotation in the C program, and finally, the model checker is used for proving whether the airborne software program meets the target annotation by a deductive reasoning method and generating the judgment result.
Specifically, when a source code verification result is generated based on the judgment result, firstly, when the judgment result meets the temporal logic protocol, the source code verification result is generated; or when the judgment result is that the temporal logic convention is not satisfied, generating a counterexample; and judging whether the judgment result is valid according to the path of the counter example.
Furthermore, the variable, array and pointer elements in the source code are verified through symbolic execution, data flow analysis and abstract interpretation methods to judge whether data overflow exists in the source code.
In a possible implementation manner, as shown in fig. 9, for the verification method at the source code stage, as for the verification work that the source code conforms to the design model, the method of using model checking mainly includes firstly abstracting a formal model from the source code by using a model extractor, then rewriting requirements into temporal logic specifications, finally verifying whether the model can satisfy the requirements specifications by using a model checker, and giving counter-examples when the model cannot satisfy the requirements, and judging whether the verification result is valid according to counter-example paths. And adopting a theorem proving method, extracting the specifications into a preposed condition and a posted condition according to the definition of requirements, converting the preposed condition and the posted condition into comments in the C program, and finally proving that the program meets the comments by using a verifier through a deductive reasoning method. For static analysis of the source code phase, the state space is simplified by bounded model checking, predicate abstraction, counter-instance driven abstraction refinement, etc.
S103, verifying an executable target code stage of the airborne software to generate a target code verification result;
in the embodiment of the application, when the target code verification result is generated, the traceability from the executable target code to the source code of the airborne software is verified by adopting a compiler verification method, a translation confirmation method and a reverse analysis method, then the attribute of the executable target code is verified by adopting a static analysis method, and finally the target code verification result is generated.
Specifically, in the verification of the executable object code phase of the onboard software, the correctness verification is performed based on the semantic equivalence theory when the compiler verifies.
Specifically, in the verification of the executable target code phase of the onboard software, the idea of translation confirmation is to verify whether the generated target program correctly implements the source program through a program analyzer.
In a possible implementation manner, the verification work of the target code phase can be executed, mainly including: the verification of the correctness of the compiler is based on the semantic equivalence theory. The formal semantics of the source code language and the object code language are first defined. A source code language to object code language compilation process is then defined. And expressing the equality between the two formalized semantemes as theorem in an assertion form, and finally realizing the theorem proving by induction and calculation by adopting a theorem proving tool. And, a method of translation validation: and inputting the source program and the target program into the analyzer for verification. If the parser verifies that the generated target program correctly implements the source program, a detailed attestation script is generated that requires further validation using an attestation checker. If the parser cannot prove the correct consistency of the source program with the target program, a counter-example is generated. The counter-example includes a scenario where the behavior between the source program and the target program is inconsistent, and further analysis is required.
S104, when the initial verification result, the source code verification result and the target code verification result all accord with preset values, determining that the verification of the airborne software is passed;
wherein the verification process is performed based on a verification target defined in DO-333;
in general, DO-333 is a complementary document of DO-178C regarding formalization methods that are intended to be incorporated into an existing set of development and validation processes to facilitate their application. The formalization method is a technology based on strict mathematical theory, and can be used for describing the specification of software characteristics, thereby being applied to the development and verification of software. Formalization methods can use mathematical methods at various stages of the system so that the behavior of the system can be accurately described and characterized. Compared with the traditional technologies such as simulation and test, the formalization method can add verification activities in the early stage of software development and verify early software products such as system requirements and design so as to discover errors as early as possible and avoid the delay of projects and a large amount of reworking in the later stage. The formalization method can also carry out strict analysis and verification on the source code and the target code, carry out multi-stage error correction, have accurate error positioning and extremely high coverage rate and greatly improve the reliability of verification. DO-333 indicates that "formal analysis may be applied to a small portion of the validation goals, or may be a major source of evidence for achieving goals related to most development and validation. This indicates that the formalization method can be used as a verification means instead of part of the review or test method, or in combination with the review and test method, for achieving the verification goal of the output product at each stage of software development as defined in DO-333.
In one possible implementation manner, when the initial verification result, the source code verification result and the target code verification result all accord with preset values, the onboard software is determined to be verified.
In the embodiment of the application, the onboard software formal verification system firstly verifies the requirement and design stages of the onboard software to generate an initial verification result, then verifies the source code stage of the onboard software to generate a source code verification result, secondly verifies the executable target code stage of the onboard software to generate a target code verification result, and finally determines that the onboard software passes the verification when the initial verification result, the source code verification result and the target code verification result all accord with preset values. Therefore, by adopting the embodiment of the application, the verification activity of the airborne software is divided into three stages of requirement and design, source code and executable target code, and for the verification activity of each stage, the verification target defined in DO-333 is combined, and a formalized analysis and verification methodology is provided for verification, so that the safety of the airborne software is improved.
The present invention also provides a computer readable medium having stored thereon program instructions which, when executed by a processor, implement the onboard software formal verification method provided by the various method embodiments described above. The present invention also provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the onboard software formal verification method of the various method embodiments described above.
It will be understood by those skilled in the art that all or part of the processes of the methods of the above embodiments may be implemented by a computer program to instruct associated hardware, and the program for onboard software formal verification may be stored in a computer readable storage medium, and when executed, may include the processes of the embodiments of the methods as described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory or a random access memory.
The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.
Claims (10)
1. An on-board software formal verification system, the system comprising:
the requirement verification result generation module is used for verifying the requirement and the design stage of the airborne software and generating an initial verification result;
the source code verification result generation module is used for verifying the source code stage of the airborne software and generating a source code verification result;
the target code verification result generation module is used for verifying the executable target code stage of the airborne software and generating a target code verification result;
the verification passing module is used for determining that the onboard software passes verification when the initial verification result, the source code verification result and the target code verification result all accord with preset values; wherein the verification process is based on the verification target defined in the DO-333.
2. The system of claim 1, wherein the requirement verification result generation module comprises:
the model building unit is used for building a demand model and a behavior model according to the demand of the airborne software and the data in the design stage;
the behavior model verification unit is used for verifying whether the behavior model meets the formalized property specification of the demand model by adopting a formalized analysis tool;
and if so, the verification result generating unit is used for generating an initial verification result.
3. The system according to claim 2, characterized in that the model construction unit is specifically configured to:
rewriting a system of the airborne software and the requirements and properties of the software by using a formal logic language to form a formal property specification to generate a requirement model of the system;
and establishing a behavior model of the system by using a formal modeling language according to the detailed design description of the system.
4. The system of claim 1, wherein the source code verification result generation module comprises:
the formal model abstraction unit is used for abstracting a formal model from the source code of the airborne software by adopting a model extractor;
the temporal logic protocol rewriting unit is used for rewriting the requirements of the airborne software into temporal logic protocols;
the judgment result generation unit is used for verifying whether the formal model meets the temporal logic specification by using a model checker, and generating a judgment result;
and the source code verification result generating unit is used for generating a source code verification result based on the judgment result.
5. The system according to claim 4, wherein the determination result generating unit is specifically configured to:
extracting the temporal logic specification into a precondition and a postcondition according to the definition of the requirement;
converting the preconditions and postconditions into target annotations in a C program;
and using a model checker to prove whether the onboard software program meets the target annotation through a deductive reasoning method, and generating a judgment result.
6. The system of claim 4, wherein the source code verification result generation unit is specifically configured to:
when the judgment result meets the temporal logic protocol, generating a source code verification result;
alternatively, the first and second electrodes may be,
when the judgment result is that the temporal logic convention is not satisfied, generating a counter example;
and judging whether the judgment result is valid according to the path of the counter example.
7. The system of claim 4, further comprising:
and the data overflow judging module is used for verifying the variables, the arrays and the pointer elements in the source code by a symbol execution method, a data flow analysis method and an abstract interpretation method so as to judge whether the data overflow exists in the source code.
8. The system of claim 1, wherein the object code verification result generation module comprises:
the first verification unit 301 is configured to verify traceability of an executable target code to a source code of the onboard software by using compiler verification, translation validation and a reverse analysis method;
a second verification unit 302, configured to verify an attribute of the executable target code by using a static analysis method;
a result generating unit 303, configured to generate a target code verification result.
9. The system of claim 8, wherein the verification of the executable object code phase of the onboard software is based on semantic equivalence theory when the compiler verifies correctness.
10. The system of claim 8, wherein the translation validation is performed by a program analyzer to verify that the generated target program correctly implements the source program in the verification of the executable target code phase of the onboard software.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210129476.XA CN114741123A (en) | 2022-02-11 | 2022-02-11 | Onboard software formal verification system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210129476.XA CN114741123A (en) | 2022-02-11 | 2022-02-11 | Onboard software formal verification system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114741123A true CN114741123A (en) | 2022-07-12 |
Family
ID=82274945
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210129476.XA Pending CN114741123A (en) | 2022-02-11 | 2022-02-11 | Onboard software formal verification system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114741123A (en) |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080098347A1 (en) * | 2006-10-20 | 2008-04-24 | Hana Chockler | Model Checking of Non-Terminating Software Programs |
| CN104714829A (en) * | 2013-12-15 | 2015-06-17 | 中国航空工业集团公司第六三一研究所 | Compiling linkage method for ensuring consistency of object code and source code |
| CN110262794A (en) * | 2019-06-03 | 2019-09-20 | 南京航空航天大学 | A kind of AADL behaviour expanding method and tool based on specification with description language |
| CN112199271A (en) * | 2020-08-31 | 2021-01-08 | 南京创联智软信息科技有限公司 | Source code formal verification method |
| CN112380112A (en) * | 2020-10-14 | 2021-02-19 | 浙江望安科技有限公司 | Java automatic formalization modeling detection verification method and system |
| CN112464174A (en) * | 2020-10-27 | 2021-03-09 | 华控清交信息科技(北京)有限公司 | Method and device for verifying multi-party secure computing software and device for verifying |
| US20210103514A1 (en) * | 2019-10-08 | 2021-04-08 | Sap Se | Reusable test cases for identifiable patterns |
| CN112699041A (en) * | 2021-01-04 | 2021-04-23 | 中车青岛四方车辆研究所有限公司 | Automatic deployment method, system and equipment for embedded software |
| US20210141914A1 (en) * | 2019-11-08 | 2021-05-13 | Tata Consultancy Services Limited | System and method for software verification |
-
2022
- 2022-02-11 CN CN202210129476.XA patent/CN114741123A/en active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080098347A1 (en) * | 2006-10-20 | 2008-04-24 | Hana Chockler | Model Checking of Non-Terminating Software Programs |
| CN104714829A (en) * | 2013-12-15 | 2015-06-17 | 中国航空工业集团公司第六三一研究所 | Compiling linkage method for ensuring consistency of object code and source code |
| CN110262794A (en) * | 2019-06-03 | 2019-09-20 | 南京航空航天大学 | A kind of AADL behaviour expanding method and tool based on specification with description language |
| US20210103514A1 (en) * | 2019-10-08 | 2021-04-08 | Sap Se | Reusable test cases for identifiable patterns |
| US20210141914A1 (en) * | 2019-11-08 | 2021-05-13 | Tata Consultancy Services Limited | System and method for software verification |
| CN112199271A (en) * | 2020-08-31 | 2021-01-08 | 南京创联智软信息科技有限公司 | Source code formal verification method |
| CN112380112A (en) * | 2020-10-14 | 2021-02-19 | 浙江望安科技有限公司 | Java automatic formalization modeling detection verification method and system |
| CN112464174A (en) * | 2020-10-27 | 2021-03-09 | 华控清交信息科技(北京)有限公司 | Method and device for verifying multi-party secure computing software and device for verifying |
| CN112699041A (en) * | 2021-01-04 | 2021-04-23 | 中车青岛四方车辆研究所有限公司 | Automatic deployment method, system and equipment for embedded software |
Non-Patent Citations (3)
| Title |
|---|
| ZONGYU CAO，YANHONG HUANG，JIANQI SHI: "Formal Analysis and Verification of Airborne Software Based on DO-333", 《ELECTRONICS》, pages 1 - 20 * |
| 杜泽民;陈宜成;: "基于模型驱动的嵌入式软件需求验证研究", 电子世界, no. 08, pages 210 - 211 * |
| 胡林平;: "机载软件适航技术研究与工程应用", 航空计算技术, no. 03, pages 96 - 99 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108509336A (en) | A kind of operating system canonical form chemical examination card and test method | |
| CN101404045A (en) | Method, system, and computer program product for generating automated assumption for compositional verification | |
| Brown et al. | Software testing | |
| Gaaloul et al. | Mining assumptions for software components using machine learning | |
| CN113282492A (en) | Operating system kernel formal verification method | |
| Yang et al. | Specification-based test repair using a lightweight formal method | |
| CN112380112A (en) | Java automatic formalization modeling detection verification method and system | |
| Aagaard et al. | A methodology for large-scale hardware verification | |
| Alhabardi et al. | Verification of bitcoin script in agda using weakest preconditions for access control | |
| CN111679964B (en) | Formal verification method of microkernel operating system interface based on boundary model detection technology | |
| CN114741123A (en) | Onboard software formal verification system | |
| Yang et al. | Equivalence checking for compiler transformations in behavioral synthesis | |
| CN114721734A (en) | Onboard software formal verification method | |
| Hagihara et al. | Minimal strongly unsatisfiable subsets of reactive system specifications | |
| Cimatti | Beyond boolean sat: Satisfiability modulo theories | |
| Bouali et al. | Formal verification for model-based development | |
| Gocht et al. | End-to-End Verification for Subgraph Solving | |
| CN111245676B (en) | Communication protocol credibility verifying device | |
| CN103488571A (en) | Method for verifying correctness of JavaScript procedure in mixed mode | |
| EP3608786B1 (en) | Systems and methods of requirements chaining and applications thereof | |
| Hollmann et al. | A family of simulation criteria to guide DEVS models validation rigorously, systematically and semi-automatically | |
| CN111382066A (en) | Software defined network application security attribute testing method in development | |
| Mavridou et al. | Bridging the Gap Between Requirements and Model Analysis: Evaluation on Ten Cyber-Physical Challenge Problems | |
| Honda et al. | Range analyzer: An automatic tool for arithmetic overflow detection in model-based development | |
| Saifan et al. | Using formal methods for test case generation according to transition-based coverage criteria |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |