2. Proof Automation for the SPARK Approach to High Integrity Ada
Andrew Ireland
Computing & Electrical Engineering
Heriot-Watt Univeristy
Edinburgh

3. Executive Summary Investigate the role of proof planning within
the SPARK approach to high integrity Ada
Funded by the EPSRC Critical Systems programme (GR/R24081) in collaboration with Praxis Critical Systems
Julian Richardson (Co-investigator) and Bill Ellis (Research Associate)

4. Outline Background and basic approach
Proposed verification architecture
Initial investigation into proof automation
Future work

5. Program Verification
Long history dating back to 70s, Wegbreit, German, Katz & Manna, …
Theorem proving and heuristic components were kept separate
Adopting a proof planning approach integrates high-level theorem proving and heuristic components

6. Ada Verification Systems
ANNA: Stanford University PAVG
Penelope: Odyssey Research Associates
MALPAS: TA Group (RSRE Malvern)
SPARK: Praxis Critical Systems (PVL)

7. Praxis Critical Systems
Internationally leading within the sector
Aerospace, Defence, Transportation, Finance, Energy and Utilities.
Boeing, Lockheed-Martin, CAA, FAA, QinetiQ (DERA), Westinghouse Signals, MONDEX,...

8. SPARK Projects
SHOLIS: Ship Helicopter Operating Limits Instrumentation System, UK MoD’s first Def Standard project
C130J: Lockheed Martin military transport aircraft
MONDEX: International smart card security, developed to ITSEC E6 standard

9. The SPARK Language
A subset of Ada that eliminates potential ambiguities and insecurities
Specification supported via code level annotations

10. Static Analysis
Data flow analysis: checks basic integrity constraints, e.g. definition-usage
Information flow analysis: checks various interdependencies via program annotations
Formal verification: generates verification conditions (VCs) based upon program annotations and SPARK semantics

11. The SPARK Tools path functions user SPADE SPARK VCs Proof Examiner
Checker
VCs
proof
code
flow analysis
feedback
rules
(lemmas)
SPADE
Simplifier

12. Clam-Oyster
user
conjectures
planner
checker
tactic
proof
theory

13. NuSPADE
conjectures
user
planner
VCs
checker
proof
cmd
theory

14. NuSPADE: High-Level Aims
Integrity: only modify the SPADE proof state via SPADE commands
Compatibility: preserve SPADE at its core
Transparency: provide users with the look-and-feel of a SPADE session

15. Proof Plans ind-strat inv-strat induction simplify ripple simplify
tautology
fertilize
tautology
fertilize

16. Polish Flag Problem
--# pre (for all I in IndexRange => (Flag(I)=Red or Flag(I)=White))
--# post for some P in Integer range (Flag'First) .. (Flag'Last+1) =>
--# ((for all Q in Integer range Flag'First..(P-1) => (Flag(Q)=Red)) and
--# (for all R in Integer range P..Flag'Last => (Flag(R)=White)));

17. Loop Invariant Flag'First I J Flag'Last
--# assert Flag'First<=I and
--# J<=(Flag'Last+1) and
--# I<=J and
--# (for all Q in Integer range Flag'First..(I-1) => (Flag(Q)=Red)) and
--# (for all R in Integer range J..Flag'Last => (Flag(R)=White));

18. SPARK Code loop … if else J:=J-1; T:=Flag(I);
Flag(I):=Flag(J); Flag(J):=T;
end if;
end loop;
SPARK Code
procedure Partition_Section(Flag: in out ArrayOfColours) is
subtype JustBiggerRange is Integer range Flag'First .. Flag'Last+1;
I: JustBiggerRange; J: JustBiggerRange; T: Colour;
begin
I:=Flag'First; J:=Flag'Last+1;
loop
--# assert Flag'First<=I and
--# J<=(Flag'Last+1) and
--# I<=J and
--# (for all Q in Integer range Flag'First..(I-1) => (Flag(Q)=Red)) and
--# (for all R in Integer range J..Flag'Last => (Flag(R)=White));
exit when I=J;
if Flag(I)=Red then
I:=I+1;
else
J:=J-1;T:=Flag(I);
Flag(I):=Flag(J); Flag(J):=T;
end if;
end loop;
end Partition_Section
Flag(I)=White

19. Verification Condition
procedure_partition_section_3.
H1: indexrange__first <= i .
H2: j <= indexrange__last + 1 .
H3: i <= j .
H4: for_all (q_: integer, ((q_ >= indexrange__first) and (q_ <= i - 1)) -> (element(flag, [q_]) = red)) .
H5: for_all (r_: integer, ((r_ >= j) and (r_ <= indexrange__last)) -> (element(flag, [r_]) = white)) .
H6: not (i = j) .
H7: not (element(flag, [i]) = red) .
->
C1: indexrange__first <= i .
C2: j - 1 <= indexrange__last + 1 .
C3: i <= j - 1 .
C4: for_all (q_: integer, ((q_ >= indexrange__first) and (q_ <= i - 1)) ->
element(update(update(flag, [i], element(flag, [j - 1])), [j - 1], element(flag, [i])), [q_]) = red)) .
C5: for_all (r_: integer, ((r_ >= j - 1) and (r_ <= indexrange__last)) ->
(element(update(update(flag, [i], element(flag, [j-1])), [j-1], element(flag, [i])), [r_]) = white)) .

20. Given
Goal
Ripple plan
= difference identification
+ reduction

24. Rewrite Rules

25. Ripple Preconditions
there exists a subterm T of the goal formula that contains a wave-front
there exists a wave-rule that matches T
any wave-rule conditions follow from the proof context
Resulting inward directed wave-fronts are potentially cancellable
Note: Stronger decision procedure required for 3

26. Speculative Loop Invariant
Flag'First P
Flag'Last
--# assert Flag'First<=P and
--# P<=(Flag'Last+1) and
--# (for all Q in Integer range Flag'First..(P-1) => (Flag(Q)=Red)) and
--# (for all R in Integer range P..Flag'Last => (Flag(R)=White));

27. Proof Failure
Given
Goal

28. Failure Analysis Blocked wave-front Matching wave-rule
Failed precondition
3. any wave-rule conditions follow from the
proof context

29. Productive Use Of Failure
Generalization
Case split
Revise Induction
Lemma speculation
Precondition 1 2 3 4
Patch X X X X

30. Proof Patch Find minimal instantiation for P such that i and (j-1)
lie out side r, i.e. P becomes j
Ripple plan applicable to revised invariant conjecture

31. Range Splitting Proof Critic
While the goal concerned with “white” gives rise to P = j, the complementary “red” goal gives rise to P = i
This inconsistency suggests the required 3-way range split, i.e. i j

32. Extending Critics Mechanism
Build upon current capability to analyse failures over multiple branches
Integrate a constraint solving capability
Develop a bottom-up invariant generation capability - also important for reasoning about the absence of run-time errors.

33. Future Work Complete first prototype of NuSPADE
Adapt existing proof plans for SPADE
Develop corresponding generic proof cmd templates (tactics)
Extend critics mechanism
Address proof management issues
Investigate industrial strength case studies