Model Based Design
CDS News:
● M7 SPARC: 32 cores × 8 ‘hardware threads’ per chip
Overview:
● the design process: from requirements to models
● cruise control system
■ requirements, hardware
■ model: design outline, design, structure, process definitions
■ safety: property & its violation; issues in progress?
■ later: revised model and implementation
Note: this system itself is not directly examinable, but the ideas and methodologies are. Also may provide
reinforcement to previous material on safety & liveness, monitors, etc.
(these slides including graphics are a modified version of the slides from Ch8 of Magee & Kramer:
Concurrency)
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 1
The Design Process
● concepts: design process
■ requirements to models to
implementations
● models: check properties of interest:
■ safety on the appropriate
(sub)system
■ progress on the overall system
● practice:
■ model interpretation: to infer actual system behavior
■ threads and monitors
● aim: rigorous design process
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 2
From Requirements to Models via Design
● requirements:
■ goals of the system
■ scenarios (Use Case models)
■ properties of interest
● design: any appropriate approach can be used
■ identify the main events, actions, and interactions
■ identify and define the main processes
■ identify and define the properties of interest
■ structure the processes into an architecture
● model
■ check traces of interest
■ check properties of interest
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 3
Cruise Control System – Requirements
When the car ignition is
switched on and the on
button is pressed, the
current speed is recorded
and the system is enabled: it
maintains the speed of the
car at the recorded setting.
Pressing the brake,
accelerator or off button
disables the system.
Pressing resume or on
re-enables the system.
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 4
Cruise Control System – Hardware
A wheel revolution sensor generates interrupts to enable the car speed to be calculated.
Output: The cruise control system controls the car speed by setting the throttle via
the digital-to-analogue converter.
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 5
Model – Outline of Design
We first outline the processes and their interactions
Sensor Scan
monitors the buttons,
brake, accelerator
and engine events
⇒Sensors
Cruise Controller:
triggers clear speed
and record speed ,
and enables or
disables the speed
control
⇓ Engine ⇓ Prompts
Input Speed monitors
the speed when the
engine is on, and
provides the current
speed readings to
speed control
⇒speed
Speed Control clears
and records the
speed, and sets the
throttle accordingly
when enabled
⇒setThrottle
Throttle: sets
the actual
throttle
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 6
Model – Design
● identify main events, actions and interactions
■ from the Sensors:on, off, resume, brake, a elerator, engineOn, engineOff
■ from the Prompts:
speed, setThrottle, learSpeed, re ordSpeed,
enableControl, disableControl
● identify these main processes:
Sensor Scan, Input Speed, Cruise Controller, Speed Control, Throttle
● identify main properties:
safety: cruise control is disabled when off, brake or a elerator pressed
● define and structure each process
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 7
Model – Structure, Actions and Interactions
The CONTROL system
is structured as two
processes.
The main actions and
interactions are as
shown.
set Sensors = { engineOn , engineOff , on, off ,
resume , brake , a elerator }
set Engine = { engineOn , engineOff }
set Prompts = { learSpeed , re ordSpeed ,
enableControl , disableControl }
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 8
Model Elaboration – Process Definitions
We abstract away the values associated with speed and acceleration (zoom).
SENSORSCAN = ({ Sensors } −> SENSORSCAN ).
// monitor speed when engine is on
INPUTSPEED = (engineOn −> CHECKSPEED ),
CHECKSPEED = (speed −> CHECKSPEED
| engineOff −> INPUTSPEED
).
// zoom when throttle is set
THROTTLE = (setThrottle −> zoom −> THROTTLE ).
// perform speed ontrol when CC is enabled
SPEEDCONTROL = DISABLED ,
DISABLED = ( { speed , learSpeed , re ordSpeed } −> DISABLED
| enableControl −> ENABLED
),
ENABLED = ( speed −> setThrottle −> ENABLED
| { re ordSpeed , enableControl } −> ENABLED
| disableControl −> DISABLED
).
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 9
Model Elaboration – Process Definitionsset DisableA tions = {off , brake , a elerator }
// enable speed ontrol when ruising , disable when a disable a tion o urs
CRUISECONTROLLER = INACTIVE ,
INACTIVE = ( engineOn −> learSpeed −> ACTIVE
| DisableA tions −> INACTIVE
),
ACTIVE = ( engineOff −> INACTIVE
| on −> re ordSpeed −> enableControl −> CRUISING
| DisableA tions −> ACTIVE
),
CRUISING = ( engineOff −> INACTIVE
| DisableA tions −> disableControl −> STANDBY
| on −> re ordSpeed −> enableControl −> CRUISING
),
STANDBY = ( engineOff −> INACTIVE
| resume −> enableControl −> CRUISING
| on −> re ordSpeed −> enableControl −> CRUISING
| DisableA tions −> STANDBY
).
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 10
Model – CONTROL Sub-system & its Safety
● we compose the sub-system for separate analysis:| | CONTROL = ( CRUISECONTROLLER | | SPEEDCONTROL ).
● and use animation to check particular scenarios
■ is control enabled after the engine is switched on and the on button is pressed?■ is control disabled when brake is then pressed?■ Is control re-enabled when resume is then pressed?
● however, we need analysis to check exhaustively:
■ safety: is the control disabled when off, brake or a elerator is pressed?■ progress: can every action eventually be selected?
property CRUISESAFETY = // (see orresponding LTS)
( { DisableA tions , disableControl } −> CRUISESAFETY
| {on, resume } −> SAFETYCHECK ),
SAFETYCHECK =
( {on, resume } −> SAFETYCHECK
| DisableA tions −> SAFETYACTION
| disableControl −> CRUISESAFETY ),
SAFETYACTION = (disableControl −> CRUISESAFETY).
| | CONTROL = (CRUISECONTROLLER | | SPEEDCONTROL | | CRUISESAFETY).
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 11
Model – CONTROL Sub-system
● safety analysis using the LTSA produces the violation in CRUISESAFETY with the
following trace:engineOn learSpeed on re ordSpeed enableControl
engineOff off off
● i.e. if the system is enabled by switching the engine on and pressing the on button,
and then the engine is switched off, it appears that the control system is not
disabled!
● what if the engine is switched on again? We can investigate further using
animation, getting the trace:
engineOn learSpeed on re ordSpeed enableControl
engineOff engineOn speed setThrottle
i.e. the car will accelerate and zoom off when the engine is switched on again!
● note on the LTS: action hiding and minimization can help to reduce the size of an
LTS diagram and make it easier to interpret
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 12
Model LTS for CONTROLMINIMIZEDminimal | | CONTROLMINIMIZED = (CRUISECONTROLLER | | SPEEDCONTROL)
� { Sensors , speed }.
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 13
Model – Progress Properties
For the system with no safety property and no hidden actions:minimal | | CONTROLMINIMIZED = (CRUISECONTROLLER | | SPEEDCONTROL)
� { Sensors , speed }.
a check of the model for progress properties yields:
Progress violation for actions:
{accelerator, brake, engineOff, engineOn, off, on, resume}
Trace to terminal set of states:
engineOn
on
engineOff
engineOn
Cycle in terminal set:
speed
Interpretation: the system as modelled could indefinitely keep taking speed readings.
In practice?
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 14
Review – Cruise Control System So far
● analysis of the CONTROL system so far has revealed
■ a serious safety violation: the system is not safe!
■ a progress violation unlikely to be serious in practice
● we took advantage of the fact that safety checks are compositional
■ if there is no violation at a subsystem level, then there cannot be a violation
when the subsystem is composed with other subsystems
■ this is because, if the ERROR state of a particular safety property is unreachable
in the LTS of the subsystem, it remains unreachable in any subsequent parallel
composition
● ⇒ safety properties should be composed with the appropriate system or
subsystem to which the property refers
■ earlier detection of problems, better modularity
COMP2310 Lecture 15: Model Based Design (I) 2014 ◭◭ ◭ • ◮ ◮◮ × 15