DOC PREVIEW
Toronto CSC 340 - Lecture 16 - Modelling “Events”

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© Easterbrook 20041Lecture 16:Modelling “events” Focus on states or events? E.g. SCR table-based models Explicit event semantics Comparing notations for state transition models FSMs vs. Statecharts vs. SCR Checking properties of state transition models Consistency Checking Model Checking, using Temporal Logic When to use formal methodsUniversity of TorontoDepartment of Computer Science© Easterbrook 20042What are we modelling? Starting point: States of the environment Events that occur in the application domain (that change the state of the environment) Requirements expressed as: Constraints over states and events of the application domainE.g. “When the aircraft is in the air, the pilot should be prevented from accidentally engagingthe reverse thrust” To get to a specification: For each relevant application domain event, find a corresponding input event For each relevant state, ensure there is a way for the machine to detect it For each required action, find a corresponding output eventApplication DomainMachine DomainD - domain propertiesR - requirementsC - computersP - programsUniversity of TorontoDepartment of Computer Science© Easterbrook 20043softwareMonitored VariablesEnviro-mentSysteminputdevicesinputdataitemsdataitemsoutputdevicesoutputControlled VariablesEnviro-mentTabular Specifications: SCRCurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@T--tACInactive@F---Off-@T--Heat---@TACHeat@F---Off--@T-InactiveAC@F---Off--@T-InactiveModesEventsNoFailure@T(INMODE)neverBlah@T(thingy)@T(other)DoodahneveralwaysACFailure, HeatFailurenever@T(INMODE)ACpower =OffOnModesEventsNoFailurefalsetrueACFailure, HeatFailuretruefalseBuzzer =OffOnModesEventsNoFailuretruefalseACFailuretemp > temp0temp <= temp0HeatFailurefalsewaterlevel =lowWarning light =OffOnVariableTypeInitial ValueUnitsWarningFlagbooleanfalse-OtherFlagbooleantrueFudgelevelenumeratedone-Waterlevelreal0.0mtemperaturereal0.0degrees CBlipCounterinteger0milesTimeNowreal100.0secAirBrakeAccreal0.0m/secConstantTypeValueUnitsLowTempinteger15degrees CHighTempinteger23degrees CMaxTimeOutinteger300millisecReferenceSafetyLevelsafetytypelow-TempMargininteger5degrees CTypeBaseTypeValuesUnitsWarningLevelenumeratedlow,med,high-Temperatureinteger-100..100degrees CWaterlevelinteger0..100metersFlagenumeratedon, off-Dictionaries:Monitored/ControlledVariablesTypesConstantsMode Transition TablesCurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@T--tACInactive@F---Off-@T--Heat---@TACHeat@F---Off--@T-InactiveTimeout@F---No Failure-ff@TACFailureCurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@T--tACInactive@F---Off-@T--Heat---@TACHeat@F---Off--@T-InactiveAC@F---Off--@T-InactiveModesEventsNoFailure@T(INMODE)neverBlah@T(thingy)@T(other)DoodahneveralwaysACFailure, HeatFailurenever@T(INMODE)Heater =OffOnModesEventsNoFailure@T(INMODE)neverSensorFail@T(reset=on)@T(INMODE)TimeoutalwaysneverACFailure, HeatFailurenever@T(INMODE)Warning light =OffOnEvent TablesCondition TablesTables:also:Assertions,Scenarios,...Four Variable Model:SCR SpecificationUniversity of TorontoDepartment of Computer Science© Easterbrook 20044SCR basics Modes and Mode classes A mode class is a finite state machine, with states called system modes Transitions in each mode class are triggered by events Complex systems described using several mode classes operating in parallel System State is defined as: the system is in exactly one mode from each mode class… …and each variable has a unique value Events Single input assumption - only one input event can occur at once An event occurs when any system entity changes value An input event occurs when an input variable changes value Notation: We may need to refer to both the old and new value of a variable: Used primed values to denote values after the event @T(c) ≡ ¬c ∧ c’ e.g. @T(y=1) ≡ y≠1 ∧ y’=1 @F(c) ≡ c ∧ ¬c A conditioned event is an event with a predicate @T(c) WHEN d ≡ ¬c ∧ c’ ∧ dSource: Adapted from Heitmeyer et. al. 1996.2University of TorontoDepartment of Computer Science© Easterbrook 20045 Mode Class Tables Define a (disjoint) set of modes (states) that the software can be in. A complex system will have many different modes classes Each mode class has a mode table showing the events that cause transitions between modes A mode table defines a partial function from modes and events to modes Example:Defining Mode ClassesSource: Adapted from Heitmeyer et. al. 1996.CurrentModePoweredonToo ColdTemp OKToo HotNew ModeOff@T-t-Inactive@Tt--Heat@T--tACInactive@F---Off-@T--Heat---@TACHeat@F---Off--@T-InactiveAC@F---Off--@T-InactiveUniversity of TorontoDepartment of Computer Science© Easterbrook 20046 Event Tables defines how a controlled variable changes in response to input events Defines a partial function from modes and events to variable values Example: Condition Tables defines the value of a controlled variable under every possible condition Defines a total function from modes and conditions to variable values Example:Defining Controlled VariablesSource: Adapted from Heitmeyer et. al. 1996.ModesHeattarget - temp ≤ 5target - temp >5ACtemp - target ≤ 5temp - target >5Inactive, OfftrueneverWarning light =OffOnModesHeat, AC@C(target)neverInactive, Offnever@C(target)Ack_tone =BeepClangUniversity of TorontoDepartment of Computer Science© Easterbrook 20047offhookidle connectedringtonedialtonebusytoneon hookon hookon hookon hookoff hookDial[calleebusy]Dial[callee idle]CalleeacceptsCallee disconnectsidle connectedringtonedialtonebusytoneon hookoff hookDial[calleebusy]Dial[callee idle]CalleeacceptsCallee disconnectsRefresher: FSMs and StatechartsUniversity of TorontoDepartment of Computer Science© Easterbrook 20048SCR EquivalentCurrentModeoffhookdialcalleeoffhookNewModeIdle@T--DialtoneDialtone-@TFRingtone-@TTBusytone@F--IdleBusytone@F--IdleRingtone--@TConnected@F--IdleConnected--@FDialtoneAC@F--Idle Interpretation: In Dialtone: @T(offhook) WHEN callee_offhook takes you to Ringing In Ringtone: @F(offhook) takes you to Idle Etc…3University of TorontoDepartment of Computer Science© Easterbrook 20049State Machine Models vs. SCR All 3 models on previous slides are (approx) equivalent State machine


View Full Document

Toronto CSC 340 - Lecture 16 - Modelling “Events”

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download Lecture 16 - Modelling “Events”
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 16 - Modelling “Events” and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 16 - Modelling “Events” 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?