like the one of Rushby [131] have built the basis of the methods adoption. Formal methods integration in modern certification/qualification activities are carried on and discussed in seminars grouping both industrials and academic domain experts like the Dagstuhl seminars².
Integrating formal methods in the development of embedded safety-critical systems may be used for leveraging verification activities and for the fulfilment of DO-178C certification objectives like: a) re- quirements correctness and consistency verification; b) source code review; c) test case replacement; d) low-level requirements verification; and e) system development process effort reduction (documentation generation).
As for DO-178C certification objectives, it is our belief that DO-330 qualification activities might also be leveraged by the use of formal methods for: a) requirements completeness verification; b) requirement coverage verification; c) tool source code review; d) tool testing effort; and e) tool development process effort reduction.
We have shown the applicability of formal analysis on BlockLibrary instances models and the confi- dence they bring on the BlockLibrary specification. We will then show in the following sections how such a model instance can be used for the generation of certification data helping in the qualification and verification of an ACG development or the code it generates.
9.2 BlockLibrary use for the certification of an ACG tool
As a development tool, an ACG that generates safety-critical system code must be qualified. Qualification must be done according to the DO-330 document. The BlockLibrary approach has been designed and developed with the objective of formally specifying ACG dataflow input language semantics. As such it must be used as an input language documentation and specification provider.
In the following we provide credible uses for a BlockLibrary specification in the context of the qual- ification of an ACG. We sum-up these uses in Figure 9.1. In this figure, the left part represents a Block- Library model from which automatic generations can be done (green arrows) and on the left side, the inner structure of the Projet-P ACG (details on the Projet-P ACG can be found in Section 2.3.2). In DO-331, “potential uses” for models are provided as: “Providing unambiguous expression of requirements and architecture; Supporting the use of automated code generation; Supporting the use of automated test generation; Supporting the use of analysis tools for verification of requirements and architecture; Supporting the use of simula- tion for partial verification of requirements, architecture, and/or Executable Object Code”[6]. We will illustrate these uses in the context of the Projet-P ACG.
9.2.1 Providing unambiguous expression of requirements and architecture
A correct BlockLibrary instance provides the specification for a set of blocks. For each block, it contains the complete and disjoint set of its Configuration elements. From a Configuration, we have shown in Chapter 7 that we can extract and verify the block semantics as a function contract (a Hoare triple).
In the context of a development tool qualification, it is mandatory to provide certification data among which are the Tool Operational Requirements (TOR). TOR for an ACG are supposed to provide for each possible element of the input language the expected output of the ACG tool. The semantics verification transformation provides this information but the generated output code is written using WhyML code which is not a classical embedded systems source code like C or Ada.
We propose to use the BlockLibrary semantics transformation as a basis for the development of an automated code generation providing for a specific Configuration element its expected embedded sys- tem generated source code.
In addition to the link between the BlockLibrary specification and the expected generated embedded code, a BlockLibrary Configuration element can be mapped to a concrete dataflow block with a specific configuration. Indeed, the Configuration element pre-conditions will provide the parameters
9.2. BLOCKLIBRARY USE FOR THE CERTIFICATION OF AN ACG TOOL
Figure 9.1: BlockLibrary use for ACG verification and development
values for this block configuration and thus can be mapped to specific block instances.
From the original Configuration semantics verification we obtain the assurance of the semantics specification correctness (Chapter 7). This assurance, given by the use of annotations must then be pro- vided on the C code level. This can be done by translating the Annotation elements provided in the Configuration semantics definition to annotations on the generated source code (ACSL annotations on C code or Spark annotations on Ada code). As annotation languages are defined using propositional logic semantics, the translation of the Configuration pre and post conditions is close to the one pro- vided for the translation to WhyML. The annotated embedded system source code with annotations can then be verified using a deductive verification approach through tools like Frama-C for C source code verification or the Spark Examiner for Ada source code.
Combination of block instance configuration and expected generated code is the exact content expected for the TOR of an ACG. We thus would be able to automatically produce such elements in various forms as for example: a model containing the informations that can be used in specific requirements manage- ment tools like the qualifying machine³ or a textual documentation used as a reference documentation of
9.2. BLOCKLIBRARY USE FOR THE CERTIFICATION OF AN ACG TOOL
the supported blocks for the ACG developers. These generation of documentations are referred to as the BL_TR_4 and BL_TR_5 transformations in Figure 9.1.
9.2.2 Supporting the use of automatically generated code
The Projet-P/Hi-MoCo and GeneAuto ACG research projects architecture are sensibly the same as the first one was strongly inspired by the second one. The ACG parses the model, it sequences and types the model (only in the GeneAuto ACG) or extracts these data from the model execution (for the QGen toolset), for each input block it matches the generated code according to the code backends containing the code to generate (the code model in Section 2.3.1) and finally it prints the code to the expected code formalism (C or Ada languages in our case). Some of these code generation steps rely on the information contained in the block library: parsing of the input model informations (parameters values of the blocks), matching the block instances with their allowed configurations in order to verify the block typing and generate the corresponding block code.
In our example ACG projects, each code backend is a file (a Java class in the GeneAuto ACG or an Ada module in the Projet-P ACG). In a code backend, the block configuration is checked and according to it, the corresponding code model is generated.
A BlockLibrary Configuration contains the expected generated code as a simple function code (a BAL operation specification). For each Configuration, a set of StructuralFeature are speci- fied along with some INVARIANT annotations and MODE_INVARIANT additional configurations. These constraints along with the StructuralFeature definitions are the only information required in order to match the block instance to its expected configuration and thus its corresponding expected generated code contained in the BlockMode semantics specification(s). The BAL function body is the expected gen- erated code for a block Configuration element. From this, it would be possible to generate automati- cally the corresponding code model structure that must be generated in the code backend (transformation BL_TR_2.2 in Figure 9.1). The choice between code backends will be conditioned by the Configuration Annotation and the StructuralFeature definition (type and allowed values defined by their at- tached INVARIANT Annotation). Likewise, the automatic generation of annotations on the generated code as prescribed in Section 8.1 can be done automatically but this will be done according to the anno- tations written on the BAL code.
Formal verification of completeness and disjointness done on the Configuration elements for a block specification ensures that if the code backend is generated correctly, then the generated code will not contain any dead code and would be traceable to each Configuration element it was generated from. This will ease the verification of the code backend and the overall code generated providing additional automatic traceability information from TOR to developed (generated) ACG code.
Code backend generation is one example of ACG code that might be generated automatically from a BlockLibrary instance. We do not provide an implementation example for this generation but we are confident on its feasibility as the BAL is quite similar to software behavior models.
According to the structure of the ACG tool one might be able to generate different modules of the ACG used for example to check block typing; or generate ACG configuration files like the block library file (as provided in Figure 2.3) through the BL_TR_1.1 or BL_TR_1.2 transformations in Figure 9.1.
9.2.3 Supporting the use of analysis tools for verification of requirements and architecture.
As previously stated, it is the purpose of the BlockLibrary approach to ensure the correctness of the ACG input block specification. It is therefore a formal model for the definition of blocks specification and a formal verification of requirements.
9.2.4 Supporting the use of simulation for partial verification of requirements, architecture, and/or Executable Object Code.
Each BlockLibrary instance Configuration is composed of a set of StructuralFeature elements with a defined data type and dimensionality and a set of constraints on the StructuralFeature values.
9.2. BLOCKLIBRARY USE FOR THE CERTIFICATION OF AN ACG TOOL
Figure 9.2: BlockLibrary use for test procedures generation and verification
In this section, we will show that these elements can be used in order to achieve automatic generation of test cases and for the verification of ACG development activities.
Each Configuration element can be considered as a complete source for test case generation. Indeed each Configuration element is a distinct configuration for a block instance. From each Configuration, according to the StructuralFeature specifications (data types and INVARIANT Annotation) and the Configuration Annotation (MODE_INVARIANT), we can extract a Constraint Satisfaction Problem (CSP). From this CSP, solvers such as MiniZinc⁴ or Choco⁵ can extract matching set of values for each StructuralFeature that can be used as the input values for a block execution.
According to a block Configuration element and its previously generated parameters and input val- ues, we can generate an input model containing a block instance corresponding to the specified block Configuration element. This model can then be used: a) in a simulation tool (for example the one used for the usual development of input models) and then be used to simulate the block behavior; and b)
⁴http://www.minizinc.com