M. Jackson: Problem Frames Two Sluice Gate Control Examples
Transcript
M. Jackson: Problem Frames Two Sluice Gate Control Examples
Egon Börger (Pisa) M. Jackson: Problem Frames Two Sluice Gate Control Examples Illustrating a required behaviour frame (Sluice Gate Control) a commanded behaviour frame (Operated Sluice Gate Control) Università di Pisa, Dipartimento di Informatica, I-56127 Pisa, Italy [email protected] c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 1 Sluice Gate Control Problem Description (p.49) A small sluice, with a rising and falling gate, is used in a simple irrigation system. A computer system is needed to control the sluice gate: the requirement is that the gate should be held in the fully open position for ten minutes in every three hours and otherwise kept in the fully closed position. The gate is opened and closed by rotating vertical screws. The screws are driven by a small motor , which can be controlled by clockwise, anticlockwise, on and off pulses. There are sensors at the top and bottom of the gate travel; at the top it’s fully open, at the bottom it’s fully shut. The connection to the computer consists of four pulse lines for motor control and two status lines for the gate sensors. NB. No initialization requirements are formulated. c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 2 Two-Phase Ground Model to capture user requirements Ground model, displayed in FSM-style graphical notation, abstracts from screws, motor, sensors, pulses, reducing the device to switching from phase fullyClosed to fullyOpen when time closedPeriod has passed, and back when openPeriod has elapsed timing model, using monitored boolean-valued locations Passed (openPeriod ), Passed (closedPeriod ) with appropriate interpretation motor actions Open = Shut = skip (placeholder for refinement) c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 3 ‘Showing’ the ground model to be ‘correct’ The above stated requirement is “that the gate should be held in the fully open position for ten minutes in every three hours and otherwise kept in the fully closed position”. The SluiceGateGround model and its runs are mathematical objects for which one can prove the following : Let S0, S1, . . . be any run of SluiceGateGround, started in an initial state S0 where ctl state = fullyClosed and – period =3 h, closedPeriod =170 min, openPeriod =10 min. Then for each number n the following holds: – state S2n is reached by step 2n, satisfies ctl state = fullyClosed and lasts closedPeriod (until step 2n + 1 is executed), – state S2n+1 is reached by step 2n + 1, satisfies ctl state = fullyOpen and lasts openPeriod (until step 2n + 2 is executed). Proof: Induction on n. c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 4 SluiceGateGround Domain Knowledge Open, Shut in the env work using a screws driving motor that can be set on and off has two move dir ection values: clockwise (say to raise the gate) and anticlockwise (say to lower the gate) obtains gate status information from two sensors informing about the (in SluiceGateGround monitored) Event(Top)/Event(Bottom) of the gate travel reaching its top (fully open)/bottom (fully closed). The connection bw motor, sensors and control program consists of four pulse lines to Emit(Pulse(...)) (output) for motor control two status lines to monitor Event(...)s (input) from the gate sensors This knowledge guides two refinements of SluiceGateGround: introducing the motor and the sensors in SluiceGateMotorCtl detailing the connection bw the controller and the physical equipment in the status line driven and pulse driving SluiceGateCtl c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 5 Refinement SluiceGateMotorCtl defining motor actions controlled locs motor : {on, off }, dir : {clockwise, anticlockwise} Boolean-valued monitored locations Event(Top), Event(Bottom) with appropriate Input Locations Assumption (for correctness proof) StartToRaise = (dir := clockwise, motor := on) StartToLower = (dir := anticlockwise, motor := on) StopMotor = (motor := off ) closedPeriod = period −(StartToRaiseTime + OpeningTime + StopMotorTime) −(StartToLowerTime + ClosingTime + StopMotorTime) c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 6 Refinement SluiceGate defining status lines and pulses Environment machine describing equipment actions when pulses appear Pulses = upon Event(Clockwise) do dir := clockwise upon Event(AntiClockwise) do dir := anticlockwise upon Event(MotorOn) do motor := on upon Event(MotorOff ) do motor := off SluiceGateMotorCtl with Emit(Pulse(. . .)) submachines StartToRaise = Emit(Pulse(Clockwise)) Emit(Pulse(MotorOn)) StartToLower = Emit(Pulse(AntiClockwise)) Emit(Pulse(MotorOn)) StopMotor = Emit(Pulse(MotorOff )) c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 7 Proving correctness of the refinement Correctness proof, relating abstract and refined runs, relies upon: Pulse Output Assumption: each Emit(Pulse(p)) in SluiceGateCtl yields Event(p) to happen in the env machine Input Locations Assumption reinterpreted, reflecting that the information detected by the sensors arrives at SluiceGateCtl as input Event(Top), Event(Bottom) via two status lines Usual convention that events are consumed by triggering the rule guarded by them NB. Refinement type is (1,2), meaning that: every segment consisting of one step of SluiceGateMotorCtl is refined by a segment of two corresponding steps of SluiceGate consisting of – one step of software machine SluiceGateCtl – followed by one step of environment machine Pulses c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 8 Further Constraints on SluiceGateCtl Runs Typically domain knowledge and/or the requirements impose further constraints on SluiceGateCtl runs to restrict the operator’s freedom to issue commands, since not each cmd sequence may be possible, reasonable and desirable. Exl: on cmds are ignored when the machine is already moving, off cmds when the gate is fully closed clockwise/anticlockwise cmds are ignored when the machine is already moving in the respective direction These matters are discussed below for the variant OperatedSluiceGate (called occasional sluice gate control in op.cit.). This will also illustrate reusing ASMs. c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 9 Specifying an Operated Sluice Gate Control An Illustration of Reusing ASMs We will reuse the ASMs developed for the Sluice Gate Control – the ground model SluiceGateGround – the refinement steps introducing • the equipment (motor and sensors in SluiceGateMotorCtl) • its connection to the machine (pulse and sensor status lines in SluiceGateCtl) the formulation of the domain knowledge (assumptions) needed for an argument to establish the correctness of failure free normal behavior – of the ground model wrt the user requirements – of the refinements wrt the ground model c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 10 Operated Sluice Gate Control Problem Description (p.90/91) A small sluice, with a rising and falling gate, is used in a simple irrigation system. A computer system is needed to raise and lower the sluice gate in response to the commands of an operator . The gate is opened and closed by rotating vertical screws. The screws are driven by a small motor, which can be controlled by clockwise, anticlockwise, on and off pulses. There are sensors at the top and bottom of the gate travel; at the top it’s fully open, at the bottom it’s fully shut. The connection to the computer consists of four pulse lines for motor control, two status lines for the gate sensors, and a status line for each class of operator command. ...the operator can position the gate as desired by issuing Raise, Lower and Stop commands: the machine should respond to a Raise by putting the gate & motor into a Rising state, and so on...The Rising and Falling states are mutually exclusive... c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 11 Reusing SluiceGateGround for OperatedSluiceGtGd OperatedSluiceGtGd & its refinements can be defined reusing SluiceGateGround components of SluiceGateMotorCtl and SluiceGateCtl Pulses & extending description technique for monitored sensor values to the new kind of to-be-monitored input coming through cmd status lines. OperatedSluiceGtGd is a variation of SluiceGateGround obtained through replacing the time events Passed (...Period ) by command and sensor events renaming the target entering abstract (read: skip) actions Open, Shut to Raise, Lower adding the target entering abstract (read: skip) action Stop The Assumption on Monitored Locations is carried over without change c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 12 Capturing User Requirements by OPERATEDSLUICEGTGD Rising RAISE Event(Stop) Or Event(Top) Event (Raise) STOP Stopped Event(Stop) Or Event(Bottom) Event (Lower) Falling c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright LOWER 13 Refining OperatedSluiceGtGd by Motor Actions & Pulses Reuse SluiceGateMotorCtl components to address mot acts OperatedSluiceGtMotCtl = OperatedSluiceGtGd where Raise = StartToRaise Lower = StartToLower Stop = StopMotor Reuse – the pulse refinement of StartToRaise, StartToLower, StopMotor to refine OperatedSluiceGtMotCtl to OperatedSluiceGtCtl – reuse Pulses to combine it with OperatedSluiceGtCtl to OperatedSluiceGt Assumption on cmd values: command status line value cmd makes Event(cmd ) true in OperatedSluiceGtMotCtl and OperatedSluiceGtCtl for each command cmd . c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 14 How to Discipline Operator Commands Fact: Some cmd sequences may be impossible to realize, or not be reasonable or not be desired. Problem: How to discipline cmd issuing and prevent the machine to obey to some in a given context undesired but issued cmd. In a math model one can always constrain runs to exclude certain cmd sequences. In real-life, one can issue operating instructions, but one cannot rely upon such instructions being followed always perfectly. Event classification (‘Reasons for disobedience’ p.112) – not sensible cmd: ‘makes no sense in the context of preceding cmds’ – not viable cmd: ‘inappropriate or impermissible in the current state’ – not overrunnable cmd: the response to the cmd has to be finished before other cmds come in (Ch.9.2 on ‘overrun concern’ due to mismatch of speeds bw triggering an action and its exec) • to be resolved by inhibition, ignoring or buffering events that occur when the machine is not ready to participate in them c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 15 Illustrating Cmd Sequence Constraints Define all not sensible or not viable cmd sequences, e.g. by a table or a finite state machine graph (here complementing the control state diagram used to define OperatedSluiceGtCtl): no two or more cmds are issued simultaneously say only sequences of pairs Raise, Stop or Lower , Stop are sensible. Then in any cmd sequence where one of the following pairs occurs, the second cmd has to be rejected as insensible: – Raise, Lower (possibly not viable for physical reasons) – Raise, Raise (includes no Raise when at top: not viable) – Lower, Raise (possibly not viable for physical reasons) – Lower, Lower (includes no Lower when at bottom: not viable) – Stop, Stop (no Stop when Stopped: NB that both the operator and the machine can trigger Stop) c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 16 How to Realize Cmd Constraints in the Machine Spec Detect issued cmds and ignore sensible cmds that are not viable (possibly notify their occurence). For example the following rule have the effect to simply consume a Stop cmd occurring in the top position without changing the state (except for the notification): if phase = Stopped and At(Top) and Event(Stop) then skip Notify(Stop at Top) ignore cmds that are not sensible (possibly notify their occurence) Exl: if phase = Rising and Event(Raise) then skip Notify(Raise when Rising) c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 17 References M. Jackson: Problem Frames. Addison-Wesley 2001 C. A. Gunter, E. L. Gunter, M. Jackson, P. Zave: A Reference Model For Requirements and Specifications. IEEE Software, May/June 2000 c 2007 Egon Börger, Dipartimento di Informatica, Università di Pisa, Pisa, Italy. Copyright 18