model based design - australian national...

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

http://www.enterprisetech.com/2014/08/13/oracle-cranks-cores-32-sparc-m7-chip/

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


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


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.


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.


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


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


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 }


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

).


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


),

STANDBY = ( engineOff −> INACTIVE

| resume −> enableControl −> CRUISING


| DisableA tions −> STANDBY

).


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


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


Model LTS for CONTROLMINIMIZEDminimal | | CONTROLMINIMIZED = (CRUISECONTROLLER | | SPEEDCONTROL)

� { Sensors , speed }.


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?


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


model based design - australian national...

Documents