BLESS: Formal Specification and Verification ofBehaviors for Embedded Systems with Software1
Brian R. Larson, Patrice Chalin, John Hatcliff
Kansas State University
May 16, 2013
1Work supported in part by the US National Science Foundation (NSF)(#0932289, #1239543), the NSF US Food and Drug AdministrationScholar-in-Residence Program (#1065887, #1238431) the National Institutesof Health / NIBIB Quantum Program, and the US Air Force Office of ScientificResearch (AFOSR) (#FA9550-09-1-0138).
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 1 / 49
Current Systems Engineering Challenges
involve both hardware and software (design process needing tomove functionality between the two)
bigger systems (more µP; more software)
many teams (geographically dispersed, different organizations)
challenges of systems integration (getting teams to agree so thatthe system pieces will eventually "glue together")
benefits from multiple forms of analysis (earlier is better)
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 2 / 49
AADL
Architecture Analysis and Design Language
AADL is a component-oriented modeling language for embeddedsystems.
SAE International standard AS5506B (v2.1 2012) defines corelanguage semantics rigorously, but natural language.
AADL includes constructs for both hardware (physical) and software(logical) components.
Extensible through annex sublanguages and user-definedproperties.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 3 / 49
AADL graphical
AADL Graphical NotationSystem : PCA / PCA
safety
alarm
Get_Fault_Log
The_Fault_Log
Voltage_OOR Defective_Btty
BubblePump_Too_Hot
Prime_FailureUpstream_Occlusion
Downstream_Occlusion
Prescribed_Flow_Rate
Upstream_Flow_Rate
Downstream_Flow_Rate
Stop_Pump_Completely
Pump_At_KVO_Rate
Drug_Not_in_Library
Hard_Limit_Violated
Empty_Reservoir
Low_Reservoir
AlarmWarning
HW_Detected_Failure
Max_Dose_Warning
Low_Battery_Warning
Security_Fault
operation
command parameters status
Get_Event_Log
The_Event_Log
Load_Drug_Library
Remaining_Battery_TimeUsing_Battery_Power
Low_Battery_Warning
Prescribed_Flow_Rate
Stop_Pump_Completely
Pump_At_KVO_Rate
Drug_Not_In_Library
Hard_Limit_Violated
AlarmWarning
Max_Dose_Warning
security
Prime Change_RateDoor_Open
Upstream_Flow_Rate
Downstream_Flow_Rate
Security_Fault
HW_Detected_Failure
Security_Provisioning
power
Remaining_Battery_Time
Using_Battery_Power
Low_Battery_WarningVoltage_OOR Defective_Btty
Get_Fault_Log
The_Fault_Log
Get_Event_Log
The_Event_Log
Load_Drug_Library
Infused_Drug
fluid
Empty_Reservoir
Low_Reservoir
Door_Open
Upstream_Occlusion
Upstream_Flow_Rate
Pump_Too_HotPrime_Failure
HaltPrime Change_RateRate
Downstream_Flow_Rate
Bubble
Downstream_Occlusion
Drug_Outlet
alarm
security
status
parameters
command
Security_Provisioning
System : PCA::operation / unnamed
command
parameters
status
Get_Event_Log
The_Event_Log
Load_Drug_Library
Remaining_Battery_Time
Using_Battery_Power
Low_Battery_Warning
Prescribed_Flow_Rate
Stop_Pump_Completely
Pump_At_KVO_Rate
Drug_Not_In_Library
Hard_Limit_Violated
Alarm Warning
Max_Dose_Warning
operation_process
Door_Open
Prime
Change_Rate
Prescribed_Flow_Rate
Patient_Request_Bolus
System_Status
Using_Battery_Power
Remaining_Battery_Time
Drug_Not_In_Library
Low_Battery_Warning
Load_Drug_Library
Get_Event_log
The_Event_Log
Hard_Limit_Violated
Pump_At_KVO_Rate
Max_Dose_Warning
Scan_DataWarningAlarm
Clinician_Requested_Bolus
Bolus_Duration
RxConfirm_RxReject_Rx
Soft_Limit_Warning
Start_FlowStop_Flow
Alarm_Inactivation
Stop_Pump_Completely
Pause_InfusionResume_Infusion
encrypt
decrypt
sign
verify
verified
result
security
status
parameters
command
Upstream_Flow_Rate
Downstream_Flow_Rate
HW_Detected_Failure
Stand_Alone
control_panel
System_Status
Warning
Alarm
Alarm_Inactivation
Clinician_Request_Bolus
Bolus_Duration
Start_FlowStop_Flow
Confirm_RxReject_Rx
Rx
Hard_Limit_Violated
Soft_Limit_Warning
Pause_InfusionResume_Infusion
patient_button
Request_Bolus
security
Prime
Change_Rate
Door_Open
Upstream_Flow_Rate
Downstream_Flow_Rate
scanner
Scan_Data
security
encrypt
decrypt
sign
verify
verified
result
Security_Fault
Security_Provisioning
Stand_Alone
Unable to makefeature groupconnection to fg'son left with Adele.
This is a knownissue and high-priority for fixing.
Security_Fault
HW_Detected_Failure
Security_Provisioning
stand_alone_switch
Stand_Alone
Process : PCA::operation::operation_process / unnamed
Door_Open
Prime
Change_Rate
Prescribed_Flow_Rate
Patient_Request_Bolus
System_Status
Using_Battery_Power
Remaining_Battery_Time
Drug_Not_In_Library
Low_Battery_Warning
Load_Drug_Library
Get_Event_log
The_Event_Log
Hard_Limit_Violated
Pump_At_KVO_Rate
Max_Dose_Warning
Scan_DataWarning
Alarm
Clinician_Requested_Bolus
Bolus_Duration
Rx
Confirm_Rx
Reject_Rx
Soft_Limit_Warning
Start_Flow
Stop_Flow
Alarm_Inactivation
operation_thread
Log_EventGet_Drug_Record The_Drug_Record
Door_Open
Patient_Request_Bolus
Using_Battery_Power
Remaining_Battery_Time
Low_Battery_Warning
CP_Start_Flow
CP_Stop_Flow
CP_Clinician_Requested_Bolus
CP_Bolus_Duration
Confirm_Rx
Reject_Rx
Alarm_Inactivation
Warning
Alarm
Pump_At_KVO_Rate
Stop_Pump_Completely
Scan_Data
Prime
Change_Rate
Prescribed_Flow_Rate
System_Status
Drug_Not_In_Library
Hard_Limit_Violated
Max_Dose_Warning
Rx
Soft_Limit_Warning
command parame... status security
Pause_Infusion
Resume_Infusion
encryptdecrypt
signverify
verified
result
Upstream_Flow_RateDownstream_Flow_Rate
Stand_Alone
drug_library_thread
Load_Drug_Library
Get_Drug_Record The_Drug_Record
event_logger_thread
Get_Event_Log
The_Event_Log
Log_Event
Stop_Pump_Completely
Pause_Infusion
Resume_Infusion
encryptdecrypt
signverify
verified
result
securitystatusparameterscommand
Upstream_Flow_RateDownstream_Flow_Rate
can't make feature group connectionsHW_Detected_Failure
Stand_Alone
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 4 / 49
AADL textual
AADL Textual Notation
� �system PositionControlSystemfeaturesPositionSetpoint: in event data port Position;properties
Timing_Properties::Clock_Period_Range=>PSC::StepDuration;end PositionControlSystem;
system implementation PositionControlSystem.commonsubcomponentsc: system Controller; --processor, memory, process, threadsa: system Actuator; --motor, valve, hard-wired circuits
connectionsps: port PositionSetpoint->c.PositionSetpoint;ac: subprogram access c.ActuatorCommand -> a.ActuatorCommand;
end PositionControlSystem.common;� �Larson, et. al. (Kansas State University ) BLESS May 16, 2013 5 / 49
AADL tools
AADL Tools
Open-Source AADL Tool Environment (OSATE): provides referenceimplementation as Eclipse plugin.2
AADL Inspector: stand-alone commercial tool3
many analysis tools available:scheduling (Cheddar), code generation (Ocarina-RAMSES),requirements (RDALTE), mass, power, port connection consistency,bus power draw, ARINC-653 configuration, unhandled faults, fault-treeanalysis, failure modes and effects analysis, functional hazardanalysis, statistical model checking (PRISM), Lute
2Software Engineering Institute at Carnegie Mellon University3Ellidiss Technologies
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 6 / 49
AADL SAVI
“Integrate Then Build"
System Architecture Virtual Integration (SAVI):
Boeing, Airbus, Lockheed Martin, BAE Systems, Rockwell Collins, GEAviation, FAA, DoD, SEI, Honeywell, Goodrich, United Technologies,and NASA
precise system architecture – machine-analyzable, singlearchitectural model annotated with precise notation
important interactions are specified and interfaces are designed,and integration verified before the internals of components arebuilt
produce implementations that are compliant with the architecture
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 7 / 49
AADL SAVI
Annex Sublanguages
The AADL standard defines a core language to express systempartitioning and connectivity.
The core language allows extension by annex sublanguages.
annex MyAnnex {** . . . **}
Several annex sublanguages have been standardized by SAEInternational as annexes to the core standard.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 8 / 49
AADL limitations
AADL Has No Behavioral Interface Specifications
AADL emphasizes "integration" (as in the SAVI program), but currentonly provides structural / type-based declaration of interfaces, but nobehavior properties
What is true about the component when it issues an event on aport?
What is assumed by a component when it reacts to an event?
What do emitted/received values mean?
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 9 / 49
AADL limitations
Weak Specifications for Internal ComponentBehavior
AADL provides a Behavioral Annex sublanguage grammar, but nosemantics for BA, much less formal semantics.� �annex behavior_specification {**variableslast_beat: BLESS_Types::Time;
statespower_on : initial state;pace : complete state;sense : complete state;check_pace_vrp : state;check_sense_vrp : state;off : final state;� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 10 / 49
AADL limitations
� �transitionsT1: power_on-[]->sense{n! & last_beat := now};
T2: pace,sense-[on dispatch stop]->off;T3: pace-[on dispatch timeout (p n) l ms]->pace{p! & last_beat := now};
T4: pace-[on dispatch s]->check_pace_vrp;T5: check_pace_vrp-[(now-last_beat) < r]->pace;T6: check_pace_vrp-[(now-last_beat) >= r]->sense{n! & last_beat := now};
T7: sense-[on dispatch timeout (p n) l ms]->pace{p! & last_beat := now};
T8: sense-[on dispatch s]->check_sense_vrp;T9: check_sense_vrp-[(now-last_beat) < r]->sense;T10: check_sense_vrp-[(now-last_beat) >= r]->sense{n! & last_beat := now};
**}; --end of BA for VVI� �Larson, et. al. (Kansas State University ) BLESS May 16, 2013 11 / 49
AADL limitations
No Reasoning Framework
AADL emphasizes analysis, but doesn’t provide a semantics norfoundational verification algorithms for reasoning about componentcomposition nor BA to interface compliance.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 12 / 49
AADL needs
AADL Needs
formal behavior interface specification language
formal component behavior language
verification method that implementation meets specification
verification tools that produce independently auditable evidence ofcompliance of behaviors to specs
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 13 / 49
BLESS
BLESS is Annex Sublanguage of AADL
BLESS programs are attached to system architecture to definecomponent behavior.
SAE International standard AS5506B defines the Architecture Analysisand Design Language (AADL). Discovered in 2007, AADL replacedcrude structural constructs of DAREN.
BLESS is pure behavior; AADL is pure structure.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 14 / 49
BLESS
BLESS is Programming Language to ControlMachines
Behavior Language for Embedded Systems with Software (BLESS)mathematically defines embedded programs, their specifications, andtheir executions from first principles
BLESS assertions provide formal behavior interface specificationlanguage
BLESS annex subclauses provide formal component behaviorlanguage
BLESS proof tool enables verification method that implementationmeets specification that produces independently auditableevidence of compliance of behaviors to specs
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 15 / 49
BLESS
BLESS Proves Component Behavior Correctness
Formally prove that every execution upholds its specification by:
Write BLESS contracts for AADL component interfaces
Write BLESS internal component behaviors
Annotate programs with BLESS assertions forming proof outlines.
Use proof tool to transform outlines into proofs.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 16 / 49
BLESS BA
BLESS akin BA
Behavior specification annex sublanguage standardized as annexdocument of AS5506 ; known as “BA"
BA inspired BLESS; coordinated grammars during standardizationprocess. Like BA, BLESS behaviors are state-transition systemsaugmented with simple temporal logic formulas.
assertassertion declarations
invariantinvariant assertion
variablesvariable declarations
statesstate declarations
transitionssource-[condition]->destination {action};
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 17 / 49
Assertion
BLESS Assertions
Proof outlines are Assertions4 attached to states, and inserted beforeand after actions.
Assertions are bounded, first-order predicates augmented with simpletemporal operators: @ ^ ’
Assertions delimited by double angle brackets: << >>
<<VS: : s@now and notVRP()>>
4Capital ‘A’ for temporal logic formulas used for BLESSLarson, et. al. (Kansas State University ) BLESS May 16, 2013 18 / 49
Assertion Triples
Verification Conditions
Verification conditions are Hoare triples:
{P} S {Q} ≡ <<P>>S<<Q>>
where P and Q are Assertions and S is an action.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 19 / 49
Proof Tool
BLESS Proof Tool Makes Proofs from Outlines
The BLESS proof tool transforms programs having proof outlines into acomplete, formal proof5 semi-automatically.
5Proofs are sequences of theorems, each of which is given, axiomatic, orderived from earlier theorems by sound inference rules. No sequence oftheorems–no proof.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 20 / 49
Proof Tool
BLESS Proof Tool is Proof Checker
The BLESS proof tool applies human-selected tactics.
All information needed for proof must appear in BLESS programsource text.
The BLESS proof tool is a verification condition generator + proofchecker–not a theorem prover.
Resulting correctness proof created as witness during program proofchecking.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 21 / 49
Proof Tool
Generate VCs, Pound Into Normal Form
The BLESS proof tool
generates verification conditions from BLESS program text
reduces compound actions to atomic actions
transforms atomic actions into implications
pounds implications into axiomatic normal form
Human directed tactics selected from GUI, or read from script, appliedto each unsolved proof obligation in current pool.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 22 / 49
Assertion
BLESS Assertions
BLESS Assertions6 are first-order predicates enclosed in <<>> with asimple temporal operator.
p@t means predicate p evaluated at real-valued time t.
Assertions may be attached as BLESS::Assertion properties of ports,or appear within BLESS annex subclauses.
p^k means predicate p evaluated at k periods from now.
p’ is shorthand for the value of p one period hence: p’≡p^1
6capital ‘A’ is used as a proper noun for BLESS AsserionsLarson, et. al. (Kansas State University ) BLESS May 16, 2013 23 / 49
VVI Mode Cardiac Pacing
VVI is ‘Hello World!’
VVI-mode cardiac pacing is ‘Hello World!’ example ofsingle-component behavior.
Composition of proved-correct AADLcomponents into proved-correct systems will be the subject of futurepapers and presentations.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 24 / 49
VVI Mode Cardiac Pacing
VVI-Mode Pacemaker
“VVI" is a cardiac pacing mode that lets a patient’s heart beat on itsown above a prescribed rate, but take over to emit a short current tocause contraction when the patient’s intrinsic rate fell below theprescribed rate.7
The first “V" of “VVI" says pace ventricle (right-ventricle unlessotherwise indicated), the second “V" says sense ventricle, and the “I"says to inhibit pacing when sensed beats are sufficiently fast.
The lower rate limit (LRL) is the heart rate, prescribed by the physicianin beats per minute at which the pacemaker will not let the heart beatmore slowly. In practice, the lower rate limit is less thought of by its ratein beats-per-minute, but by its duration in milliseconds.
7PACEMAKER System Specification, Boston Scientific, 2007.Larson, et. al. (Kansas State University ) BLESS May 16, 2013 25 / 49
VVI Mode Cardiac Pacing AADL diagram
VVI.aadl Component
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 26 / 49
VVI Mode Cardiac Pacing AADL text
VVI.aadl Component� �thread VVIfeaturess: in event port; --ventricular contraction has been sensedp: out event port --pace ventricle{BLESS::Assertion=>"<<VP()>>";};
n: out event port --non-refractory ventricular sense{BLESS::Assertion=>"<<VS()>>";};
l: in data port T; --lower rate limit intervalr: in data port T; --ventricular refractory period
propertiesDispatch_Protocol => Aperiodic;
annex BLESS {** . . . **};end VVI;� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 27 / 49
VVI Mode Cardiac Pacing Medical Effectiveness
Effectiveness Property
The invariant that keeps the patient lively is:
“There will always be a pace or a (non-refractory) sense inthe previous lower-rate limit interval."
Long pauses between heartbeats must not occur. Cardiologistschoose a lower-rate limit (LRL) maintained by the pacemaker, ondemand, when the patient’s intrinsic rate would be too slow.
A typical LRL of 60 beats-per-minute (bpm) has an LRL interval of1000 ms.
Real hearts are electrically-noisy after contraction. Therefore, duringventricular refractory period (VRP) following a sense or pace, electricalsignals should be ignored.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 28 / 49
BLESS source Invariant
Thread Invariant
Thread behavior is specified by its thread invariant, much like a loopinvariant, and its BLESS::Assertion properties of ports.
The current instant is now.� �invariant<<LRL(now)>> --LRL is true, whenever "now" is� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 29 / 49
BLESS source assert
Assertion LRL
Assertion LRL takes a parameter x.
The invariant says LRL(now) will be true, whenever now happens tobe.� �
<<LRL:x: --Lower Rate Limitexists t:T --there was a momentin x-l..x --within the previous LRL intervalthat (n@t or p@t) >> --with a pace or non-refractory sense� �
(there is a time, t in the lower-rate limit interval before time x in whicheither a ventricular-pace, or non-refractory ventricular-sense eventoccurred.)
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 30 / 49
BLESS source assert
Ventricular Refractory Period (VRP)
After contraction, hearts have electrical noise that should be ignored.The ventricular refractory period (VRP) determines the period ofunresponsiveness. notVRP becomes true after VRP has expired.� �
<<notVRP: : --Ventricular Refractory Period(n or p)@last_beat --last beat before now,and (now-last_beat)>=r>> --older than VRP� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 31 / 49
BLESS source assert
Port Assertions
Assertion properties of out event ports specify what must be true whenan event is sent by the port.� �
<<VS: : --ventricular sense detected, not in VRPs@now and notVRP() >>
<<VP: : --cause ventricular pace(n or p)@(now-l) --last beat occurred LRL interval ago,and --not since thennot (exists t:T --there is no time
in now-l,,now --since then, ",," means open intervalthat (n or p)@t) >> --with a pace or sense� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 32 / 49
BLESS source states
States
Thread states may be
initial starting state, must have exactly one
final ending state, no outgoing transitions
complete suspend until next dispatch upon entering
execute transitory states
States may have Assertions that specify what is true when the threadis in a state.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 33 / 49
BLESS source states
States� �statespower_on : initial state --powered-up,<<VS()>>; --start with "sense"
pace : complete state--a ventricular pace has occured in the--previous LRL-interval milliseconds
<<PACE(now)>>;check_pace_vrp : state
--execute state to check if s sooner than VRP after pace<<s@now and PACE(now)>>;
sense : complete state--a ventricular sense has occured in the--previous LRL-interval milliseconds
<<SENSE(now)>>;check_sense_vrp : state
--execute state to check if s sooner than VRP after sense<<s@now and SENSE(now)>>;
off : final state; --upon "stop"� �Larson, et. al. (Kansas State University ) BLESS May 16, 2013 34 / 49
BLESS source states
State Assertions
� �<<PACE:x: --pace occurred in the previous LRL intervalp@last_beat and --previous beat was a pace(exists t:T --there is a timein x-l..x --in the previous LRL intervalthat p@t) >> --with a ventricular pace
<<SENSE:x: --sense occurred in the previous LRL intervaln@last_beat and --previous beat was a sense(exists t:T --there is a timein x-l..x --in the previous LRL intervalthat n@t) >> --with a non-refractory sense� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 35 / 49
BLESS source states
Initial and Stop Transitions
Transitions have one or more source states, transition condition,destination state, and possibly an action.� �transitionsT1_POWER_ON: --initializationpower_on -[ ]-> sense{<<VS()>>n!<<n@now>> --first "sense" at initialization& last_beat:=now<<last_beat=now>>};
T2_STOP: --turn off pacingpace,sense -[on dispatch stop]-> off{};� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 36 / 49
BLESS source states
Transitions After Pace
� �T3_PACE_LRL_AFTER_VP: --pace when LRL times outpace -[on dispatch timeout (p n) l ms]-> pace{ <<VP()>>p!<<p@now>> --cause pace when LRL times out& last_beat:=now <<last_beat=now>>};
T4_VS_AFTER_VP: --sense after pace=>check if in VRPpace -[on dispatch s]-> check_pace_vrp{};� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 37 / 49
BLESS source states
Check if in VRP
� �T5_VS_AFTER_VP_IN_VRP: -- s in VRP, go back to "pace" statecheck_pace_vrp -[(now-last_beat)<r]-> pace{};
T6_VS_AFTER_VP_IS_NR: --s after VRP,--go to "sense" state, send n!, reset timeouts
check_pace_vrp -[(now-last_beat)>=r]-> sense{ <<VS()>>n!<<n@now>> --send n! to reset timeouts&last_beat:=now <<last_beat=now>>};� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 38 / 49
Verification Conditions
Verification Conditions
Subprogram behaviors have one verification condition.
Thread behaviors have a verification condition for each state andtransition.
VVI.aadl requires 15 verification conditions.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 39 / 49
Verification Conditions complete states
Complete State Proof Obligations
The Assertions of complete states must imply the threadinvariant.� �P [64] <<PACE(now)>>S [51] ->Q [51] <<LRL(now)>>What for: <<M(pace)>> -> <<I>> from invariant Iwhen complete state pace has Assertion<<M(pace)>> in its definition.� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 40 / 49
Verification Conditions execute states
Execute State Proof Obligations
The execute states, check_pace_vrp and check_sense_vrp, must havean enabled, outgoing transition:� �P [71] <<s@now and PACE(now)>>S [71]->Q [71] <<((now-last_beat) < r) or ((now-last_beat) >= r)>>What for: Serban’s Theorem: disjunction of execute conditionsleaving execution state check_pace_vrp,<<M(check_pace_vrp)>> -> <<e1 or e2 or . . . en>>� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 41 / 49
Verification Conditions transitions
Initial Transition Proof Obligation
For transition T1_POWER_ON from the power_on initial state:� �P [60] <<VS()>>S [82]<<VS()>>n!<<n@now>>&last_beat := now<<last_beat = now>>Q [68] <<SENSE(now)>>What for: <<M(power_on)>> A <<M(sense)>> forT1_POWER_ON:power_on-[ ]->sense{A};� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 42 / 49
Proof of VVI.aadl
Proof of VVI.aadl
Though rather long, inspecting the generated proof is the means toconvince oneself that all of the obligations have indeed beenproved.
The proof of VVI.aadl requires 123 theorems, that last of which says allverification conditions have proofs.
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 43 / 49
Proof of VVI.aadl VVI Complete State Proofs
pace upholds invariant
The first three theorems prove that the Assertion of complete statepace upholds the thread invariant.� �Theorem (1) [serial 1155]76 {P} <<(exists t:Timing_Properties::Time
in now-PP::lower_rate_limit_interval..nowthat vp@t )
andvp@last_vp_or_vs>>
64 S =>64 {Q} <<(exists t:Timing_Properties::Timein now-PP::lower_rate_limit_interval..nowthat nr_vs@t )
or (exists t:Timing_Properties::Timein now-PP::lower_rate_limit_interval..nowthat vp@t )>>
by And-Elimination/Or-Introduction Schema: (P and Q)=>(P or R)� �Larson, et. al. (Kansas State University ) BLESS May 16, 2013 44 / 49
Proof of VVI.aadl VVI Complete State Proofs
� �Theorem (2) [serial 1129]76 {P} <<(exists t:Timing_Properties::Time
in now-PP::lower_rate_limit_interval..nowthat vp@t )
andvp@last_vp_or_vs>>
64 S =>64 {Q} <<exists t:Timing_Properties::Timein now-PP::lower_rate_limit_interval..nowthat (nr_vs@t or vp@t) >>
by Distribution of preconditions, and over or, and distribution of postcondtitions, or over andand theorem 1.� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 45 / 49
Proof of VVI.aadl VVI Complete State Proofs
� �Theorem (3) [serial 1002]76 {P} <<PACE(now)>>64 S =>64 {Q} <<LRL(now)>>
by Substitution of Assertion Labelsand theorem 2:� �
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 46 / 49
Summary
BLESS is
an AADL annex sublanguage defining behavior of components
a simple temporal logic to specify behavior (port Assertions andcomponent invariant)
a plug-in to OSATE which is a plug-in to Eclipse, which
generates verification conditions
transforms proof outlines into complete proofs (with humanguidance)
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 47 / 49
Summary
Future Work
coupling of BLESS behavior with EMV2 error models (SEI)
prove component invariants from proofs of subcomponents
simulation
code generation
proof obligation export to other tools
use “smarter" inference engine to generate intermediateassertions in proof outline
submit BLESS to SAE International to become annex standard ofAADL
Larson, et. al. (Kansas State University ) BLESS May 16, 2013 48 / 49