BLESS Tutorial: A Hands-On Introduction to the … Tutorial: A Hands-On Introduction to the BLESS...

BLESS Tutorial:A Hands-On Introduction to the

BLESS Proof Toolplug-in to OSATE

Brian R LarsonKansas State University & Software Engineering Institute

[email protected]

July 11, 2013

Brian R Larson () BLESS Hands-On Tutorial July 11, 2013 1 / 60

Agenda

1 Install BLESS

2 VVI@NFM2013

3 Prove VVI

4 DDD

5 Stepper

6 Isolette

7 PCA Pump

8 PO Smart Alarm

9 Wrap-up


Install BLESS

Install OSATE First

The BLESS proof tool is a plug-in to the Open-Source AADL ToolEnvironment (OSATE) which is itself a plug-in to Eclipse.

The easiest way is to download Eclipse with OSATE installed at:http://www.aadl.info/aadl/osate/stable/2.0.2/products/

Otherwise you can use the Eclipse update site:http://www.aadl.info/aadl/osate/stable/2.0.2/update-site/

The AADL wiki can be helpful:https://wiki.sei.cmu.edu/aadl/index.php/Main_Page


http://www.aadl.info/aadl/osate/stable/2.0.2/products/

http://www.aadl.info/aadl/osate/stable/2.0.2/update-site/

https://wiki.sei.cmu.edu/aadl/index.php/Main_Page

Install BLESS

Install BLESS Plug-In

A bunch of BLESS stuff is available at:https://docs.google.com/folder/d/0B78p4vjrmr9lMnZlNkhmcEdIbE0/

edit?pli=1

Sample OSATE packages with BLESS behaviors and proof scripts canbe found in BLESStutorial.files.zip


https://docs.google.com/folder/d/0B78p4vjrmr9lMnZlNkhmcEdIbE0/edit?pli=1

https://docs.google.com/folder/d/0B78p4vjrmr9lMnZlNkhmcEdIbE0/edit?pli=1

Install BLESS

To get the BLESS proof tool:

Download BLESSupdate.zip at the site above, and uncompress it.It holds a local update site for Eclipse.

Launch OSATE

Select Help->Install New Software. . .

Click the "Add. . . " button, which opens an "Add Repository"

Click the "Local. . . " button and then select the BLESSupdatefolder. Enter a name like "BLESS" and click the OK button.

In the Install window, click the check box by "OSATE Plug-in", then"Next".

Accept the license, and finish.


Install BLESS

Import Projects into OSATE

Import the "vvi" and "bless-predeclared" AADL projects intoOSATE (from BLESStutorial.files.zip) byFile→Import→General→Existing Projects Into Workspace

Browse to the root folders of "vvi" and "bless-predeclared",checking copy projects into workspace

Get "Plugin_Resorces" project by right-clicking in the "AADLNavigator" pane, choosing "Reset/create all Predeclared andAnnex Properties"

Open the "vvi" project (should be open, but BLESS processes allopen projects together)

Click the praying hands icon

Choose Load Model from BLESS menu.

Choose BLESS→Actions→make all obligationsBrian R Larson () BLESS Hands-On Tutorial July 11, 2013 6 / 60

Install BLESS

Eclipse Hints

"Refresh" from context menu frequently

Project→Clean. . . fixes much

Close Unrelated Projects

Save, then BLESS→load model, to syntax-check BLESS annexlibraries, subclauses, and properties1

1I wish I could get Xtext to shut-up about syntax errors in AADL declarativemodels while I’m typing.


VVI@NFM2013

First BLESS Paper

First BLESS paper at NASA Formal Methods in May 2013 usedVVI.aadl as its "Hello World!" example.


VVI@NFM2013

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)


VVI@NFM2013

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.


VVI@NFM2013

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



Pump_At_KVO_Rate

Drug_Not_In_Library

Hard_Limit_Violated

AlarmWarning

Max_Dose_Warning

security

Prime Change_RateDoor_Open

Upstream_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


Bubble

Downstream_Occlusion

Drug_Outlet

alarm

security

status

parameters

command


System : PCA::operation / unnamed

command

parameters

status

Get_Event_Log

The_Event_Log

Load_Drug_Library


Using_Battery_Power

Low_Battery_Warning



Pump_At_KVO_Rate

Drug_Not_In_Library

Hard_Limit_Violated

Alarm Warning

Max_Dose_Warning

operation_process

Door_Open

Prime

Change_Rate


Patient_Request_Bolus

System_Status

Using_Battery_Power


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


Pause_InfusionResume_Infusion

encrypt

decrypt

sign

verify

verified

result

security

status

parameters

command

Upstream_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


scanner

Scan_Data

security

encrypt

decrypt

sign

verify

verified

result

Security_Fault


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


stand_alone_switch

Stand_Alone

Process : PCA::operation::operation_process / unnamed

Door_Open

Prime

Change_Rate



System_Status

Using_Battery_Power


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


Using_Battery_Power


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


Scan_Data

Prime

Change_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


Pause_Infusion

Resume_Infusion

encryptdecrypt

signverify

verified

result

securitystatusparameterscommand

Upstream_Flow_RateDownstream_Flow_Rate

can't make feature group connectionsHW_Detected_Failure

Stand_Alone


VVI@NFM2013

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;� �Brian R Larson () BLESS Hands-On Tutorial July 11, 2013 12 / 60

VVI@NFM2013

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


VVI@NFM2013

“Integrate Then Build"

System Architecture Virtual Integration (SAVI):

Embraer, Boeing, Airbus, Lockheed Martin, BAE Systems, RockwellCollins, GE Aviation, FAA, DoD, SEI, Honeywell, Goodrich, UnitedTechnologies, 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


VVI@NFM2013

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.


VVI@NFM2013

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?


VVI@NFM2013

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;� �


VVI@NFM2013� �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� �Brian R Larson () BLESS Hands-On Tutorial July 11, 2013 18 / 60

VVI@NFM2013

No Reasoning Framework

AADL emphasizes analysis, but doesn’t provide a semantics norfoundational verification algorithms for reasoning about componentcomposition nor BA to interface compliance.


VVI@NFM2013

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


VVI@NFM2013

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.


VVI@NFM2013

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


VVI@NFM2013

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.


VVI@NFM2013

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};


VVI@NFM2013

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 BLESSBrian R Larson () BLESS Hands-On Tutorial July 11, 2013 25 / 60

VVI@NFM2013

Verification Conditions

Verification conditions are Hoare triples:

{P} S {Q} ≡ <<P>>S<<Q>>

where P and Q are Assertions and S is an action.


VVI@NFM2013

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.


VVI@NFM2013

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.


VVI@NFM2013

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.


VVI@NFM2013

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 ofports, 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 AsserionsBrian R Larson () BLESS Hands-On Tutorial July 11, 2013 30 / 60

VVI@NFM2013

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.


VVI@NFM2013

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.Brian R Larson () BLESS Hands-On Tutorial July 11, 2013 32 / 60

VVI@NFM2013

VVI.aadl Component


VVI@NFM2013

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;� �


VVI@NFM2013

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.


VVI@NFM2013

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� �


VVI@NFM2013

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.)


VVI@NFM2013

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 hasexpired.� �

<<notVRP: : --Ventricular Refractory Period(n or p)@last_beat --last beat before now,and (now-last_beat)>=r>> --older than VRP� �


VVI@NFM2013

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 timein now-l,,now --since then, ",," means open intervalthat (n or p)@t) >> --with a pace or sense� �


VVI@NFM2013

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.


VVI@NFM2013

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"� �Brian R Larson () BLESS Hands-On Tutorial July 11, 2013 41 / 60

VVI@NFM2013

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� �


VVI@NFM2013

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{};� �


VVI@NFM2013

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{};� �


VVI@NFM2013

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>>};� �


VVI@NFM2013

Verification Conditions

Subprogram behaviors have one verification condition.

Thread behaviors have a verification condition for each state andtransition.

VVI.aadl requires 15 verification conditions.


VVI@NFM2013

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.� �


VVI@NFM2013

Execute State Proof Obligations

The execute states, check_pace_vrp and check_sense_vrp, musthave an 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>>� �


VVI@NFM2013

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};� �Brian R Larson () BLESS Hands-On Tutorial July 11, 2013 49 / 60

VVI@NFM2013

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.


VVI@NFM2013

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)� �Brian R Larson () BLESS Hands-On Tutorial July 11, 2013 51 / 60

VVI@NFM2013

� �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.� �


VVI@NFM2013

� �Theorem (3) [serial 1002]76 {P} <<PACE(now)>>64 S =>64 {Q} <<LRL(now)>>

by Substitution of Assertion Labelsand theorem 2:� �


Prove VVI

Examine VVI Initial Proof Obligations

All the initial obligation for VVI are generated together. Look at them tosee if you think they constitute the verification conditions appropriatefor the behavior.


DDD

DDD Cardiac Pacing Example

Close "vvi" project

Import "DDD" project

Assertion labels are global. DDD redefines LRL.

Scoping of Assertions with explicit usage on "maybe someday" list ofBLESS tool changes


Stepper

Stepper Motor Example


Isolette

Isolette Example


PCA Pump

PCA Pump Example

To be exemplar for FDA


PO Smart Alarm

Pulse Oximeter Smart Alarm

This was the first models to prove composition of (thread)behaviors

Change in proof rules for discrete time broke the proof script forPO.aadl8

Trouble recognizing locally-declared constants; AADL properties arerecognized as constants: P::V^x⇔ P::V

8prior rules would drop ^ inappropriatelyBrian R Larson () BLESS Hands-On Tutorial July 11, 2013 59 / 60

Wrap-up

Please Try BLESS

I have suggestions for starter components to prove behavior meetsspecification.

I will help.


Date post:	26-May-2018
Category:	Documents
Upload:	duongdan
View:	214 times
Download:	0 times

BLESS Tutorial: A Hands-On Introduction to the … Tutorial: A Hands-On Introduction to the BLESS...

Documents