The purpose of this assignment is to gain some experience in using theorem-proving for verification of system specifications.
You are to specify and verify two abstract data types for an elevator. Use PVS to prove that your spec is correct. For each proof obligation, first run grind to see if you got it right. Then, proof each obligation WITHOUT using ground or grind. Why? When safety-critical systems are being verified, just the answer YES is not enough (theorem-provers have errors, too). Instead, for certification, verifiers of these systems should submit a detailed proof - something a human can follow and assure that the proof was done correctly. So, in real-life verification, high-level strategies are used for debugging, whereas lower-level strategies are used for verification.
Submit your model, a list of properties you generated and a list of properties the theorem-prover generated. Also, submit scripts of all proofs you've done for these properties. Use PVS's pretty-printing capabilities for the proofs.
Part 1. Follow description below for a 20-floor elevator. Use theory nat as a type for the floor. Do not use predicate subtypes.
Part 2. Replace nat with a predicate subtype. Which properties are no longer necessary?
Part 2. Try this system for an N-floor elevator.
Part 3. (Theoretical). Can communications between datatypes be modelled somehow, or is all theorem-proving bound to verification of datatypes? I.e., can we effectively express the same properties as we've been verifying in assignments 1-3 using PVS? I.e., is a theorem-prover always more expressive than a model-checker?
Elevator Door Datatype
One data type specifies the behaviour of the elevator door. There are operations for creating an initial Door (which is closed), for changing the states of the Door (i.e., opening and closing the door), and for querying the current state of the Door. The syntax and informal semantics of the data type operations follow:
NewDoor: -> Door
/* creates a new, closed Door */
Open: Door -> Door
/* opens the door */
Close: Door -> Door
/* closes the door */
NOP: Door -> Door
/* no operation - the door stays in the same state */
IsOpen: Door -> Boolean
/* true if the door is currently open */
Elevator Datatype
The second abstract data type defines the behaviour of the elevator Car. There are operations for creating an initial elevator Car (which resides on the first floor), for changing the states of the Car (i.e., moving up and down the elevator shaft), and for querying the current state of the Car. The elevator cannot move below the first floor and cannot move above the 20th floor. The syntax and informal semantics of the data type operations follow:
NewElev: -> Elev
/* creates a new elevator car (on its own elevator shaft) on the first floor */
MoveUp: Elev -> Elev
/* moves the elevator up a floor */
MoveDown: Elev -> Elev
/* moves the elevator down a floor */
ExpressUp: Elev -> Elev
/* moves the elevator directly to the top floor */
ExpressDown: Elev -> Elev
/* moves the elevator directly to the bottom floor */
NOP: Elev -> Elev
/* no operation - the elevator stays on the same floor */
Floor: Elev -> Natural
/* returns the elevator's current floor */
You are to write axioms for the above abstract data types. You may use existing PVS theories for bool and nat. Use PVS to verify the following properties:
If you are interested in presenting your specification, please let me know. Everyone who is registered for this course has to present at least one assignment. If you are registered but have not presented anything yet, this is your chance. Even if you have presented one of your previous assignments, I would still like to hear from you.