theory MinMax_Verif
use import MinOutputScalarMultipleInputsScalars_sig0
use import MaxOutputScalarMultipleInputsScalars_sig0
use import MinMaxParameters_PreConditions
5 use import MinMaxInScalars_PreConditions
goal MinMax_completeness :
forall out: tOut_MinMaxOutScalar_TDouble ,
nbInputs: tNbInputs_MinMaxParameters_TInt16 , 10 in1: tIn1_MinMaxInScalars_TDouble ,
functionParam: tFunctionParam_MinMaxParameters_MinMaxFunction minMaxParameters_PreConditions nbInputs functionParam /\ minMaxInScalars_PreConditions nbInputs in1 functionParam ->
15 minOutputScalarMultipleInputsScalars_sig0 out nbInputs in1 functionParam \/ maxOutputScalarMultipleInputsScalars_sig0 out nbInputs in1 functionParam goal MinMax_disjointness :
forall out: tOut_MinMaxOutScalar_TDouble ,
20 nbInputs: tNbInputs_MinMaxParameters_TInt16 , in1: tIn1_MinMaxInScalars_TDouble ,
functionParam: tFunctionParam_MinMaxParameters_MinMaxFunction minMaxParameters_PreConditions nbInputs functionParam /\ minMaxInScalars_PreConditions nbInputs in1 functionParam 25 ->
not ( minOutputScalarMultipleInputsScalars_sig0 out nbInputs in1 functionParam /\ maxOutputScalarMultipleInputsScalars_sig0 out nbInputs in1 functionParam) end
Listing 7.30: Completeness and disjointness verification goals
7.6.2 Semantics verification transformation
Semantics verification targets the assessment of the correctness of the semantics definition provided in the BlockMode elements in order to assess the correctness of the operational specification with respect to the axiomatic one provided in the pre/post conditions. We do not enforce BlockMode semantics definition to contain both axiomatic and operational semantics but it is mandatory to provide it during the specification phase in order to be able to perform this verification.
For each BlockMode specification and each Signature that can be extracted from it, we have shown in Section 6.5 that we can extract functions with contracts. Our semantics verification mechanism is inspired from this translation but is different as its target language is the WhyML language.
For each Signature extracted from each BlockMode extracted from each BlockType, we can build one Hoare triple for each semantics phase. Each Hoare triple can then be translated to a WhyML function and its contract. The function is composed of the operational semantics provided in each semantics phase definition and of its contract composed of:
• Pre-conditions extracted from: all the INVARIANT provided by all the StructuralFeature; all the
MODE_INVARIANT contained in the Signature BlockVariant elements and the BlockMode element; and from the pre-conditions contained in the semantics phase definition.
• Post-conditions extracted from: the post-conditions contained in the semantics phase definition. We provide in Figure 7.31 the translation for one of the MinMax block semantics definitions. 7.7 Variability verification through SMT solving
The previously generated Why theories are fed into the Why3 tool taking care of their translation to suit- able formats for verification through SMT solvers or proof assistants. Here we will focus on the use of SMT solvers as we are targeting fully automated verification activities to ease the writing and verification
7.7. VARIABILITY VERIFICATION THROUGH SMT SOLVING
definition bal = compute_MinOutScalarMultipleInputsScalars {
2 postcondition ocl {
In1 ->forAll(i| i.value >= Out.value) }
var res = In1 [0]. value;
for (var i = 1; i < (size(In1)); i = i + 1){ 7 if (res > In1[i]. value){
res = In1[i]. value; } } Out.value = res; 12 } is translated to let compute_MinOutScalarMultipleInputsScalars (out: tOut_MinMaxOutScalar_TDouble ) 3 (nbInputs: tNbInputs_MinMaxParameters_TInt16 ) (in1: tIn1_MinMaxInScalars_TDouble ) (functionParam: tFunctionParam_MinMaxParameters_MinMaxFunction ) requires { nbInputs.value_pt >= 1 }
requires { length in1 = nbInputs.value_pt }
8 requires { nbInputs.value_pt > 1 }
requires { functionParam.value_pt = Min }
ensures { forall i0: int.
0 <= i0 < length in1 ->
in1[i0]. value_inpg >=. out.value_outpg 13 } =
let res_outer = in1 [0]. value_inpg in let res = ref res_outer in
for i = 1 to length in1 - 1 do if ! res >. in1[i]. value_inpg then 18 res := in1[i]. value_inpg
done ;
out.value_outpg <- ! res
Figure 7.31: Signature function with contract extraction of BlockMode specification
of specification by domain experts. However, in case of automatic verification failure, we could still fall back on proof assistant for the most complex blocks under the guidance of a proof expert.
7.7.1 Specification extract variability verification
In the MinMax block specification provided in Listing 7.2, we only extract a part of the specification. Ap- plying the previously defined extraction mechanism provides the two goals detailed in Listing 7.30. Completeness goal verification
If we simplify the completeness goal and express it using only expressions based on StructuralFeature elements values (by replacing the predicates calls by their definition and if we remove the duplicates ex- pressions that can be removed), we obtain the goal of Listing 7.32.
goal MinMax_completeness :
1 <= value_pt nbInputs /\ length in1 = value_pt nbInputs -> 1 < value_pt nbInputs /\ value_pt functionParam = Min \/
1 < value_pt nbInputs /\ value_pt functionParam = Max
Listing 7.32: Simplified completeness and disjointness goals
It is impossible to prove correct the MinMax_completeness goal to be true. Indeed, in the premises of the implication, the value_pt nbInputs value is supposed to be greater or equals to 1 and equals to the length of the in1 PortGroup (the number of these ports groups) but in the conclusion, we must prove the value_pt nbInputs to be greater than 1.
7.7. VARIABILITY VERIFICATION THROUGH SMT SOLVING
1 goal MinMax_disjointness :
1 <= value_pt nbInputs /\ length in1 = value_pt nbInputs -> not ((1 < value_pt nbInputs /\ value_pt functionParam = Min) /\
1 < value_pt nbInputs /\ value_pt functionParam = Max)
Listing 7.33: Simplified completeness and disjointness goals
This problem is due to the content of the MinMax block specification part we based our generation on. This specification only provides BlockMode for the cases where the number of inputs is greater than 1. If we want to verify this part of the specification, we have to restrain the specification of the NbInputs parameter to be strictly greater than 1. In this case the verification is done automatically in a few tenth of a second (0.09 seconds to be exact) by the Alt-Ergo SMT solver². The example provided here whereas being simple is very representative of the typical block specification errors.
Disjointness goal verification
Regarding the proof for the MinMax_disjointness, we can also apply the same simplification as pre- viously and obtain its expression based only on StructuralFeature values expressions as provided in Listing 7.33. This goal is verified by SMT solvers in 9 tenth of a second using the Alt-Ergo SMT solver.
Verification of the disjointness goal is done easily as the second components of every configuration predicates are exclusive (value_pt functionParam).
Of course, as our goal is not to verify partial configurations of a block, we applied the verification trans- formation to full block specifications. Results obtained are discussed in the following section.
7.7.2 Entire specification verification
We provide the entire specification in a textual form in Appendix A.2 for the MinMax block. Table 7.34 gives the verification times for some blocks we have written a BlockLibrary specification for. These verifications have been done using the Alt-Ergo SMT solver. According to what was previously stated, it is expected that according to the number of Signature element computed from a block specification, the verification time increases. This is mostly due to the exponential size of the disjointness goal. With the goals size increase comes an increase in the verification time and in the system resources needs. It is worth noting that despite the complexity of the Delay block example, the time required for the verification remains reasonable.
Block name #BlockMode #Signature TimeCompleteness(s) TimeDisjointness(s) MemoryMaxuse(KiB)
MinMax 10 10 0.09 0.09 123,960
Sum 8 8 0.11 0.13 130,844
Lookup 6 6 0.26 1.36 136,808
Delay 12 144 2.45 8.06 1,507,972
Table 7.34: Some blocks specification verification performances
7.7.3 Goals transformation as a mean to ease the verification
Using SMT solvers through the Why3 platform has some advantages. Among these we can cite the pos- sibility to apply transformations on the theories to prove, before translating these ones to SMT solvers or proof assistants inputs.
7.7. VARIABILITY VERIFICATION THROUGH SMT SOLVING
Transformations
Transformations allows manipulating the expressions in order to simplify the goals to prove. For exam- ple, transformations allows to produce one goal for each component of a conjunction; in-line predicates definitions (replace a predicate call with its definition) or terms definitions, remove let definitions by re- placing the defined variable by its definitions in each of its use and many other ones. Goals simplifications done previously are the result of using this transformation mechanism. Further details about available transformations are provided in the Why3 manual [3].
Application to the completeness verification
We take as example the translation for the erroneous part of the MinMax block specification. We will focus on the MinMax_completeness goal. On this goal, we apply three inline_goal transformations. These lead to the simplified result that was detailed in Listing 7.32. We then apply the introduce_premises transformation leading to the introduction of both conjunction components of the premise as axioms. We finally apply the split_goal_full transformation distributing the logical conjunctions over the logical disjunction leading to four different goals to prove. We give the final goals details in Listing 7.35. The last goal is trivially proven as it aims at proving the definition of the minMaxFunction type. The other three are not provable from the informations provided in the H and H1 axioms.
1 constant out : tOutPortGroup real
constant nbInputs : tParameterType int
constant in1 : list (tInPortGroup real)
constant functionParam : tParameterType minMaxFunction
6 axiom H : 1 <= value_pt nbInputs
axiom H1 : length in1 = value_pt nbInputs
goal MinMax_completeness_1 : 1 < value_pt nbInputs \/ 1 < value_pt nbInputs goal MinMax_completeness_2 : 1 < value_pt nbInputs \/ value_pt functionParam = Max 11 goal MinMax_completeness_3 : value_pt functionParam = Min \/ 1 < value_pt nbInputs
goal MinMax_completeness_4 : value_pt functionParam = Min \/ value_pt functionParam = Max
Listing 7.35: Inlined and split resulting goals for the completeness goal
Interpretation of the results
One main advantage of the use of this tool is the ability, with a minimal knowledge of first order logic and its manipulation, to actually apply the transformations, see their results and from this either a) manage to do the proof with SMT solvers and eventually with proof assistant; or b) guess informations on the reasons why the verification is failing and thus modify the block specification with this new knowledge. We like to call this a proof ”debugging” process. This implies the ability to provide feedback information at the BlockLibrary conforming models level.
General transformation application methodology process
The completeness and disjointness goals have specific shapes, it is possible to define transformation ap- plication methodologies in order to simplify them and then obtain simpler sub-goals that one may try to prove with SMT solvers or if SMT solvers fails to conclude by relying on proof assistants.
Both completeness and disjointness goals are implications. Their premises are shaped as conjunctions and their conclusions are shaped according to the goal. We detail in Figure 7.36 (respectively in Figure 7.37) the transformation application methodologies that can be used on the completeness goal (respec- tively on the disjointness goal). In these figures, arrows denote the application of one or more transforma- tions. The content of the rectangular notes is the general pattern of the goal on which the transformation is applied.
7.7. VARIABILITY VERIFICATION THROUGH SMT SOLVING goal completeness: P1 /\ ... /\ Pn -> C1 \/ ... \/ Cm axiom H: P1 axiom ... axiom Hn: Pn goal completeness: C1 \/ ... \/ Cm intro_premises axiom H: P1,1 /\ ... /\ P1,p axiom ... axiom Hn: Pn,1 /\ ... /\ Pn,l goal completeness: C1,1 /\ ... /\ C1,q \/ ... \/ Cm,1 /\ ... /\ Cm,r inline_all (eliminate_if \/ eliminate_let \/ simplify_formula)* axiom H: P1,1 /\ ... /\ P1,p axiom ... axiom Hn:Pn,1/\ ... /\ Pn,l goal completeness1: C1,1 /\ C2,1 /\ ... /\ Cm,1 goal completeness2: C1,1 /\ C2,2 /\ ... /\ Cm,1 goal completeness... goal completenessN: C1,q /\ ... /\ Cm,r split_goal_full (eliminate_if \/ eliminate_let \/ simplify_formula)*
Figure 7.36: Completeness goal transformation application methodology
goal disjointness: P1 /\ ... /\ Pn -> not (C1 /\ C2) /\ not (C1 /\ C3) /\ ... /\ not (Cn-1 /\ Cn)
axiom H: P1 axiom ... axiom Hn: Pn
goal disjointness: not (C1 /\ C2) /\ not (C1 /\ C3) /\ ... /\ not (Cn-1 /\ Cn) intro_premises
axiom H: P1 axiom ... axiom Hn: Pn
goal disjointness1: not(C1 /\ C2) goal disjointness...
goal disjointnessN: not (Cn-1 /\ Cn) split_goal_full
axiom H: P1,1 /\ ... /\ P1,p axiom ...
axiom Hn: Pn,1 /\ ... /\ Pn,l
goal disjointness1: not (C1,1 /\ ... /\ C1,q /\ C2,1 /\ C2,r) goal disjointness...
goal disjointnessN: not (Cn-1,1 /\ ... /\ Cn-1,s /\ Cn,1 /\ ... /\ Cn,t) inline_all
(eliminate_if \/ eliminate_let \/ simplify_formula)*