THE HATLEY/PIRBHAI MODEL - pudn.comread.pudn.com/.../592939/comp8100/Hatley-Pirbhai-BW.pdf · 2008-06-12 · •Primitive control flow definitions are common with most systems. •Decomposable

Page ‹#›

THE HATLEY/PIRBHAI MODEL

Software Improvements©Copyright 1997 Software Improvements

Real-Time Structured Analysis - Hat/Pir MSE - ANU

THEHATLEY/PIRBHAI

MODEL

So!Now I know alittle about the

DeMarco Model.But what’s thisHatley/Pirbhai

stuff?


INFORMATION vs REAL-TIME SYSTEMS

Information Systems:

– Analysed & designed on basis of static data models.

– Emphasis on data storage, update and access.

– Timing issues (although important) are not critical.

Real-Time Systems:

– Analysed & designed with an emphasis on timerelated change in conditions and processes.

– Data storage is usually not encyclopedic andtherefore does not require rigorous modelling.

Page ‹#›




REAL-TIME (EMBEDDED) SYSTEMS

DEFINITION:

• Any information processing activity or system whichmust respond to externally generated input stimuliwithin a finite & specified period of time (Young - 1982)

HARD REAL-TIME SYSTEMS:

• Are critically time dependent.

• Missed deadlines may be disastrous.

SOFT REAL-TIME SYSTEMS:

• Are time dependent.

• Missed deadlines not usually disastrous.See Burns & Wellings (Ref 26)


ASPECTS FOR CONSIDERATION

• Size and ComplexityManagement, Staffing, Development Techniques, Estimating,

Scheduling, Maintenance, Metrics etc.

• AlgorithmsManipulation of real numbers. Mathematical modelling of

system components that are under control (eg. PID).

• Reliability and SafetyExceptional conditions of operation. Risk of failure

predictions. Provision of facilities to guarantee reliability.

• ConcurrencyRecognition of separate system elements that must work or

be controlled in parallel.

• Time DependencySeparation of those system inputs that cause the generation

of certain system outputs within specific time constraints.

• Interaction with other systems

Page ‹#›




S/W ELEMENTS OF REAL-TIME SYSTEMS

Digital ControlAlgorithms

Data Acquisition

Data Retrieval, Massaging & Display

Operator Interface

DATABASE

INTERFACE

DISPLAYDEVICES

OPERATOR’SCONSOLE

MONITORINGSYSTEM

PROCESSINGSYSTEM

REAL-TIME CLOCK

REAL-TIME COMPUTER


DEMARCO MODEL REVISITED

• Assumes ideal technology:

Instantaneous responses.

Steady state operation.

Time independent.

• De-emphasises control view:

Decisions described at PSpec level only.

Ignores process sequencing/activation.

Little support for describing states.

• Emphasises data view:

All processing is on data.

Page ‹#›




HATLEY/PIRBHAI MODEL

• Hatley/Pirbhai (Requirements) Model =

DeMarco (Data Processing) Model + Control Model

• Control Model is used to specify:

–Requirements that exhibit finite state machine behaviour.

–What behaviour the Data Process Model must exhibit whenthe system is under the influence of particular external orinternal conditions or operating modes.

–Separate operational modes.

–High level decisions that affect operational modes.



Requirements Specifications are constructed using:-

– Data Flow Diagrams & Control Flow DiagramsShowing data processes, data inputs and outputs.

Showing control processing, control inputs and outputs.

– Requirements DictionaryContaining definitions of data inputs, outputs, stores andintermediate data plus definitions of control inputs, outputs,stores.

– Structured LanguageAs for DeMarco Model.

– Control SpecificationsFSMs which map control inputs to control outputs &/or showcontrol of data processes according to the control inputs.

Page ‹#›




PROCESSTRANSFORM

FUNCTIONBUBBLE

DFD/CFD ELEMENTS

TERMINATOR

DATAFLOWS

STORE

Processes should be named with a short action clause summarisingwhat is to be done to the input (data) in order to produce the output (data).

• Dataflows indicate the content and direction of flow of information (or materials) to and from processes, stores and terminators.• Treat them as pipelines along which single or groups of data/material items of known content and nature can flow.• Their names reflect their content - nouns or adjectives.• They do not contain or represent dynamic behaviour - no verbal names.

• Stores represent dataflows or control flows that are frozen for an indeterminate time.• The (data or control) information/materials they represent can be accessed at any time and in any order - non-destructively.• Nouns and/or adjectives should be used - sometimes plural.• Event stores (Ward/Mellor) queue incoming events - reads are destructive.

Terminators represent things that are external to the system, but whichare important because they provide &/or receive system input and output.


DFD/CFD ELEMENTS

• Control flows indicate the composition and direction of flow of control information to and from CSpecs, control stores and terminators.• Treat them as pipelines along which single or groups of control items of known composition flow.• Their names reflect their content - nouns or adjectives.• They do not contain or represent dynamic behaviour - no verbal names.• Event flows (Ward/Mellor) have similar meaning to control flows but are also used as prompts to enable/disable processes and they do not contain grouped elements.

CONTROLFLOWS

CSpec

• Control Specifications (CSpecs) are used to indicate finite state machine behaviour in the form of:

STATE TRANSITION DIAGRAMSSTATE EVENT MATRICESDECISION TABLESPROCESS ACTIVATION TABLES

See Hatley/Pirbhai (Ref 8) and Ward/Mellor (Ref 9)

Page ‹#›




CONTROL FLOW DIAGRAMS

Basic characteristics of CFDs:

• They are paired with Data Flow Diagrams

• Have the same:

Numbering, Levelling, Balancing, Parent/Child relationships.

• Show processes (same as DFDs) but not Data Flows.

• Only concerned with elements that are affected by control.

• Data processors are affected by high level control decisionsbut data flows are not.

• Show Control Flows and Stores

• Show Control Specifications (if any)


DATAFLOW DIAGRAM DECOMPOSITION

RequirementsDictionary

Data Flow /Data StoreDefinition~~~~~~~~~~~~~~~~~~

DFD 1.1 DFD 1

DFD 0

CONTEXT DATA

THE SYSTEM

0

Actuator

Human

Physical Environment

Software Package

Sensor

PROCESS

1PROCESS

2

PROCESS

3PROCESS

4STORE-A

PROCESS

1.1.1PROCESS

1.1.2

PROCESS

1.1.3

STORE-A

PROCESS

1.1PROCESS

1.2

PROCESS

1.3

STORE-B

Page ‹#›




CONTROL FLOW DIAGRAM DECOMPOSITION

RequirementsDictionary

Control Flow /Control StoreDefinition~~~~~~~~~~~~~~~~~~~~~~

CFD 1.1 CFD 1

CFD 0

CONTEXT CONTROL

PROCESS

1.1PROCESS

1.2

PROCESS

1.3

STORE-B

Control Output-A

Control Input-A

s1

s2

Decision

PROCESS

1PROCESS

2

PROCESS

3PROCESS

4STORE-A

Control Input-AControl

Input-B

s1

Control Output-A

Control Output-B

THE SYSTEM

0

Actuator

Human


Software Package

Sensor

Control Output-B

Control Output-A

Control Input

PROCESS

1.1.1PROCESS

1.1.2

PROCESS

1.1.3

STORE-A Decision


COMBINED DFD/CFD DECOMPOSITION

DFD/CFD 1.1 DFD/CFD 1

DFD/CFD 0

CONTEXT DATA & CONTROL

THE SYSTEM

0

Actuator

Human


Software Package

Sensor

Control Output-B

Control Output-A

Control Input

PROCESS

1PROCESS

2

PROCESS

3PROCESS

4STORE-A

Control Input-AControl

Input-B

s1

Control Output-A

Control Output-B

PROCESS

1.1.1PROCESS

1.1.2

PROCESS

1.1.3

STORE-A Decision

PROCESS

1.1PROCESS

1.2

PROCESS

1.3

STORE-B

Control Output-A

Control Input-A

s1

s2

Decision

Page ‹#›




CONTROL FLOWS

• Represent pipelines that transport control informationof known composition.

• Named according to content - use nouns or adjectives.

• Compositional elements can be primitive or collective.

• Primitive elements always consist of discrete values.


CONTROL FLOWS

POSSIBLE SOURCES:

» External environment

» Control Specifications (CSpecs)

» Process Specifications - resulting from decisionsmade within PSpec about input data conditions.

POSSIBLE DESTINATIONS:

» External environment

» Control Specifications

» Not PSpecs - they only transform data inputs.

Page ‹#›




REQUIREMENTS DICTIONARY

• Contains definitions of both data flows & stores andcontrol flows & stores.

• Notation used for all definitions is that of DeMarco.

• Primitive data flow definitions can be continuous ordiscrete in nature.

• Primitive control flow definitions must be discrete innature.


REQUIREMENTS DICTIONARY

Symbol

=

This + That

n{ That }m

[ This | That | Another | ... ]

(This)

" That "

* Note about this & that *

This + That + Another + ...

<That>This

Meaning

composed of

This together with That

n to m iterations of That

select one of This or That or Another or ...

This is optional

literally the word That

comment field and/or primitive element

key attribute of data entity (@ in TeamWork)

That version of This (TeamWork only)

Page ‹#›




Door_Position = [“Open” | “Closed”]

* The only door positions of interest *

----------

Rate: Event-driven by operator.

Fan_Setting = [“Off” | “Low” | “Medium” | “High”]

* Various fan rotation speed settings *

----------

Rate: As required.

Received = [“True” | “False”]

* Indicator for acknowledgment of receipt of certain signals *

----------

Versions: <Start_Date>, <Start_Time>, <Duration_Time>

CONTROL FLOW DEFINITION EXAMPLES



Primitive definition:

Windows_Command =

[“Main” | “Accessories” | “Windows_Applications”]

Decomposable definition:

Windows_Command =

[Main | Accessories | Windows_Applications]

Main =

[“File_Manager” | “Control_Panel” | “Print_Manager”

| “Clipboard” | “DOS_Prompt” | “Windows_Setup”]

Accessories =[“Notepad” | “Write” | “Clock” | “Calendar” | “Terminal”]

Page ‹#›





Grouped definition:

File_Management_Activity =

Main + File_Manager + File_Selection + (File_Operation) + ...

• Primitive control flow definitions are common with mostsystems.

• Decomposable definitions are less common.

• Grouped definitions are relatively uncommon.


CONTROL SPECIFICATIONS

Absolutes of Real-Time Systems:

– Behave predictably.

– Maintain history of events or system conditions.

– Change behaviour (predictably) according to eventhistory (past and present).

• These properties imply that real-time systems must dealwith a finite number of events and produce a finitenumber of outcomes in order to behave predictably.

Page ‹#›





Represent various finite state machines as follows:

• State Transition Diagrams STD

• State Event Matrices SEM

• Decision Tables DT

• Process Activation Tables PAT

• Finite State Machines (FSMs) can be used only when afinite number of inputs having a finite set of values canlead to a finite number of outputs (or set of actions)having a finite set of values.



CSpecs are best used for systems that exhibit:

• significant numbers of states or modes of operation.

• significant complexity in terms of elaborating decisionsthat affect or determine system configuration or modesof operation.

• significant numbers of inputs (events) that have noeffective content and merely serve as triggers/signalsfor actions that affect operational modes (or states) ofparts of the system.

• high level management control of large portions of thesystem.

Page ‹#›





The FSMs within CSpecs are best used to:

• elaborate system states in terms of externallyobservable behaviour - with STDs.

• specify states in terms of combinations of active andinactive processes - with STDs and PATs.

• specify sequences of high level actions that changeoperational modes - with STDs and PATs

• specify results of particular combinations of controlinput - with DTs and PATs

• map combinations of input control signals into anoutput signal - with DTs.


TYPES OF FSM USED WITHIN CSPECS

Two Categories:

COMBINATIONAL

– Outputs are uniquely determined by current inputs.

– Keeps no information of past events (no memory).

– Include Decision Tables & Process Activation Tables.

SEQUENTIAL

– Outputs determined using both current and previousinputs.

– Maintains information on specific system conditions(has memory).

– Include State Transition Diagrams & SEMs.

Page ‹#›




COMBINATIONS OF FSM TYPES IN CSPECS

ACTION LOGIC

COMBINATIONAL MACHINE

(PAT)

DECISION LOGIC

COMBINATIONAL MACHINE

(DT)

SEQUENTIAL MACHINE

(STD)

Control Events

Control Actions

Action Decisions

Event Decisions

Control Actions


HATLEY/PIRBHAI & SEQUENTIAL FSMs

Basic Characteristics:-

1 Use a hybrid form of Mealy and Moore models in anattempt to take advantage of both models.

– Basically use Mealy model.

– Additionally use Moore when it is (more) convenient.

2 Define states as being the mode or condition of system.

3 Output of SFSM includes activation of processes.

4 Actions associated with a transition continue in effectuntil the next transition.

Page ‹#›




HATLEY/PIRBHAI SFSM CONVENTIONS - STD

Actions includeactivation of processes onassociated DFD.

When Process-1 isactivated, it will remainactive (in State-2) untilEvent-3 causes atransition from State-2.

Events are represented withinput Control Flow values

Actions are represented with output Control Flow values or indicated Process Activations

CFD/DFDSTD

DataFlow-3

DataFlow-2

Event-1/Action-2

Event-3/Action-1; Action-2

DataFlow-1

Event-3

Event-2

Action-1

Action-2

Event-1

Event-2/Action-2

Event-3/Enable Process-2

Event-1/Enable Process-1

/Action-1

State-1

State-2

State-3

Process-1

Store

Process-2


DataFlow-3

DataFlow-2

DataFlow-1

Event-3

Event-2

Action-1

Action-2

Event-1

Process-1

Store

Process-2

EVENT

STATE

Enable P-1

State-2

Action-2

Action

Next State

Action-2

State-2

Enable P-2

State-3

A-1 & A-2

State-1

Event-1 Event-2 Event-3

State-1

State-2

State-3

HATLEY/PIRBHAI SFSM CONVENTIONS - SEM

The State Event Matrix is analternative form for an STD.

CFD/DFDSEM

For Mealy form of SFSM cells of the matrixthat correspond to a transition will containthe resulting action together with the nameof the destination state.

Page ‹#›




HATLEY/PIRBHAI CFSM CONVENTIONS

The value of Event Decision isdetermined by the combinationof the input values of Event-1,Event-2 and Event-3.


Event decisions are represented withoutput Control Flow values.

CFD/DFDDT

DataFlow-3

DataFlow-2

DataFlow-1Event-3

Event-2EventDecision

Event-1

Process-1

Store

Process-2

Event-1 Event-2 Event-3EventDecision

DiscreteValue-1

DiscreteValue-2

DiscreteValue-3

Decision1

DiscreteValue-2

Discretevalue-3

DiscreteValue-1

Decision2

DiscreteValue-1

DiscreteValue-2

Decision2

DiscreteValue-1


HATLEY/PIRBHAI CFSM CONVENTIONS

The integer values indicate (de)activation of Process-1 and/or Process-2 and are determinedby the combination of the input values of Event-1,Event-2 and Event-3.


Control Actions are represented withindications of process activation in a table.

CFD/DFDPAT

ControlActions

Only those processes beingcontrolled are shown in the PAT

DataFlow-3

DataFlow-2

DataFlow-1

Event-3

Event-2

Event-1

Process-1

Store

Process-2

Event-1 Event-2 Event-3Process

1

DiscreteValue-1

DiscreteValue-2

DiscreteValue-3

1

DiscreteValue-2

Discretevalue-3

DiscreteValue-1

1

DiscreteValue-1

DiscreteValue-2

0DiscreteValue-1

Process2

0

2

1

Page ‹#›




CONTROL SPECIFICATIONS AS STDs

Light_Setting

Fan_Setting

Lock_Setting

<Timing_Data>Received

Door_Position

Time_To_Stop

Time_To_Start

<Setpoint_Temp>Received

TemperatureTime_Remaining

Heat_Setting

Temperature_Overrun

<Overall>Setpoint_Range

Setpoint_Temperature

<Accepted>Timing_Data

Timing_Data

<Accepted_Duration>Time

Average_Temperature

Calculate

Average

Temperature

Maintain

Setpoint

Temperature

Accept

Setpoint

Temperature

Accept

Timing Data

1

2

4

6

TEMPERATURE_STATISTICS

ACCEPTED_SETPOINT_TEMPERATURE

TEMPERATURE_TOLERANCES

DATE_AND_TIMEACCEPTED_TIMING_DATA

Count Down

To Time Out

7

Oven_Statess1

Processes under control

FSM Control Flow Outputs (Actions)

FSM Control Flow Inputs (Events)

<Additional>Temperature

Combined DFD0/CFD0 showingdata & control processing


CONTROL SPECIFICATIONS AS STDs

Light_Setting

Fan_Setting

Lock_Setting


Door_Position

Time_To_Stop

Time_To_Start


Calculate

Average

Temperature

Maintain

Setpoint

Temperature

Accept

Setpoint

Temperature

Accept

Timing Data

1

2

4

6





Count Down

To Time Out

7

Oven_Statess1

Processes under control

FSM Control Flow Outputs (Actions)

FSM Control Flow Inputs (Events)

CFD0 showing controlprocessing only

Page ‹#›




CONTROL SPECIFICATIONS CONTAINING STDs

IDLE_WAITING

Time_To_Stop/Lock_Setting = "Unlocked"; Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"

Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"

(~<Duration_Time>Received | ~<Setpoint_Temp>Received)

Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"; Disable "Count Down To Time Out"

Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"; Enable "Count Down To Time Out"

Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"

~<Start_Time>Received

<Start_Time>Received


<Duration_Time>Received & <Setpoint_Temp>Received

Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature" Enable "Count Down To Time Out"

Time_To_Start

/Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"

(~<Duration_Time>Received | ~<Setpoint_Temp>Received)/Disable "Count Down To Time Out"

(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &<Duration_Time>Received & <Setpoint_Temp>Received/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";Enable "Count Down To Time Out" READY_WAITING

READY_IMMEDIATE

RUNNING

3

4

5

6

(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& <Duration_Time>Received & <Setpoint_Temp>Received

/Light_Setting = "Off"; Fan_Setting = "Off" Lock_Setting = "Unlocked"

IDLE WITH DOOR OPEN

IDLE WITH DOOR CLOSED

2

1

FSM Actions that control Processes on corresponding DFD

Light_Setting

Fan_Setting

Lock_Setting


Door_Position

Time_To_Stop

Time_To_Start


Oven_Statess1

Pure Hatley/Pirbhai STD


CONTROL SPECIFICATIONS CONTAINING STDs

RUNNING

/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"

Time_To_Stop/Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"

Door_Position = "Closed"

(~<Duration_Time>Received| ~<Setpoint_Temp>Received

Door_Position = "Open"/Disable "Count Down To Time Out"

Door_Position = "Closed"

Door_Position = "Open"



(~Duration_Time>Received| ~<Setpoint_Temp>Received)

<Duration_Time>Received &<Setpoint_Temp>Received

Door_Position = "Closed"/Enable "Count Down To Time Out"

Time_To_Start

(~<Duration_Time>Received| ~<Setpoint_Temp_Received)/Disable "Count Down To Time Out"

(<Start_Date>Received |~<Start_Date>Received) &<Start_Time>Received &<Duration_Time>Received &<Setpoint_Temp>Received

IDLE WITH DOOR CLOSED /Light_Setting = "Off"; Fan_Setting = "Off" Lock_Setting = "Unlocked"

IDLE WITH DOOR OPEN

/Light_Setting = "On"; Fan_Setting = "High"

IDLE_WAITING


READY_WAITING

/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = Unlocked"; Enable "Count Down To Time Out"

READY_IMMEDIATE


1

2

3

4

5

6

(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& <Duration_Time>Received& <Setpoint_Temp>Received

FSM Actions that control Processes on corresponding DFD

Light_Setting

Fan_Setting

Lock_Setting


Door_Position

Time_To_Stop

Time_To_Start


Oven_Statess1

Combined Mealy& Moore STD

Page ‹#›




CONTROL SPECS CONTAINING DTs AND STDs

IDLE_WAITING

Time_To_Stop/Lock_Setting = "Unlocked"; Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"









<Duration_Time>Received & <Setpoint_Temp>Received


Time_To_Start/Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"

(~<Duration_Time>Received | ~<Setpoint_Temp>Received)/Disable "Count Down To Time Out"

(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &<Duration_Time>Received & <Setpoint_Temp>Received/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";Enable "Count Down To Time Out"

READY_WAITING

READY_IMMEDIATE

RUNNING

3

4 6

(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& <Duration_Time>Received & <Setpoint_Temp>Received

/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"

IDLE WITH DOOR OPEN


2

1

5

Use a DT when combinations of specificevents result in the establishment of particular important conditions of whichthe system needs to be aware.

<Duration_ Time>

Received

<Setpoint_ Temperature>

Received

Minimum_ Inputs_

Available

"True" *Don't Care* "False"

*Don't Care* "True" "False"

"True" "True" "True"


Minimum_Inputs_

Available<Duration_Time>

Received

Light_Setting

Fan_Setting

Lock_Setting

<Start_Date>Received +<Start_Time>Received

Door_Position

Time_To_Stop

Time_To_Start

<Setpoint_Temperature>

Received

Calculate

Average

Temperature

Maintain

Setpoint

Temperature

Accept

Setpoint

Temperature

Accept

Timing Data

1

2

4

6





Count Down

To Time Out

7

Oven_Statess1

s0 Enough_Inputs

Enough_Inputs

s0


Each CFD contains justONE CSpec sometimesmade up of two or moreSHEETS

Page ‹#›




Minimum_Inputs_


Received

Light_Setting

Fan_Setting

Lock_Setting


Door_Position

Time_To_Stop

Time_To_Start


Received

Calculate

Average

Temperature

Maintain

Setpoint

Temperature

Accept

Setpoint

Temperature

Accept

Timing Data

1

2

4

6





Count Down

To Time Out

7

Oven_Statess1

s0 Enough_Inputs

Enough_Inputs

s0


CSpec bars can be duplicated for diagrammatic convenience.Each duplicated CSpec barrepresents the same SHEET.



IDLE_WAITING

Time_To_Stop/Lock_Setting = "Unlocked; Disable "Maintain Setpoint Temperature"; Disable "Count Down To Time Out"


~Minimum_Inputs_Available







Minimum_Inputs_Available


Time_To_Start/Lock_Setting = "Locked"; Enable "Maintain Setpoint Temperature"

~Minimum_Inputs_Available/Disable "Count Down To Time Out"

(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &Minimum_Inputs_Available;/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";

READY_WAITING

READY_IMMEDIATE

RUNNING

3

4 6

(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& Minimum_Inputs_Available

/Light_Setting = "Off"; Fan_Setting = "Off" Lock_Setting = "Unlocked"

IDLE WITH DOOR OPEN


2

1

5

;

SHEET-1 (s1) Oven_States

<Duration_ Time>

Received

<Setpoint_ Temperature>

Received

Minimum_ Inputs_

Available

"True" *Don't Care* "False"

*Don't Care* "True" "False"

"True" "True" "True"

SHEET-0 (s0) Enough_Inputs

Page ‹#›




CONTROL SPECS CONTAINING PATs AND DTs

“Open”

“Closed”

Door_Position

<Start_Date>Received


<Duration_Time>

Received

Time_To_Start

Time_To_Stop


Received

PROCESS7

PROCESS1

Light_Setting

Fan_Setting

Lock_Setting

“Open”

“Open”

“Closed”

“Closed”

“Closed”

“Closed”

“True”

“False”

“False”

“False”

“False”

“False”

“False”

“False”

“False”

“False” “False” “False”


“False” “False”

“False”

“False”

“False”

“False”

“False”

“False”

“False”

“False”“True” “True”

“True” “True”

“True”

“True”“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

*Don’t Care*

“False”

“False”

*Don’t Care*

*Don’t Care*

*Don’t Care*

“Off”

“On”

“Unlocked”

“Locked”

“On”

“On”

“Locked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off” “Off”

“High”

“High”

“High”

0 0

0

0

0

0

0

0

0

0

1

0

1 1

1

1

CONTROL EVENTSEVENT

DECISIONSCONTROLACTIONS



“Open”

“Closed”

Door_Position



<Duration_Time>

Received

Time_To_Start

Time_To_Stop


Received

PROCESS7

PROCESS1

Light_Setting

Fan_Setting

Lock_Setting

“Open”

“Open”

“Closed”

“Closed”

“Closed”

“Closed”

“True”

“False”

“False”

“False”

“False”

“False”

“False”

“False”

“False”




“False”

“False”

“False”

“False”

“False”

“False”

“False”



“True”


“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

*Don’t Care*

“False”

“False”

*Don’t Care*

*Don’t Care*

*Don’t Care*

“Off”

“On”

“Unlocked”

“Locked”

“On”

“On”

“Locked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off” “Off”

“High”

“High”

“High”

0 0

0

0

0

0

0

0

0

0

1

0

1 1

1

1

The DT part of a combined PAT and DT.

DTs should be used whenever complicated decisions about control input combinationsneed to be made in order to produce possible combinations of control outputs.

Page ‹#›





“Open”

“Closed”

Door_Position



<Duration_Time>

Received

Time_To_Start

Time_To_Stop


Received

PROCESS7

PROCESS1

Light_Setting

Fan_Setting

Lock_Setting

“Open”

“Open”

“Closed”

“Closed”

“Closed”

“Closed”

“True”

“False”

“False”

“False”

“False”

“False”

“False”

“False”

“False”




“False”

“False”

“False”

“False”

“False”

“False”

“False”



“True”


“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

*Don’t Care*

“False”

“False”

*Don’t Care*

*Don’t Care*

*Don’t Care*

“Off”

“On”

“Unlocked”

“Locked”

“On”

“On”

“Locked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off” “Off”

“High”

“High”

“High”

0 0

0

0

0

0

0

0

0

0

1

0

1 1

1

1

The PAT part of a combined PAT and DT.

PATs can be used whenever complicated decisions about control input combinationsneed to be made in order to produce possible combinations of control actions.



“Open”

“Closed”

Door_Position



<Duration_Time>

Received

Time_To_Start

Time_To_Stop


Received

PROCESS7

PROCESS1

Light_Setting

Fan_Setting

Lock_Setting

“Open”

“Open”

“Closed”

“Closed”

“Closed”

“Closed”

“True”

“False”

“False”

“False”

“False”

“False”

“False”

“False”

“False”




“False”

“False”

“False”

“False”

“False”

“False”

“False”



“True”


“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

“True”

*Don’t Care*

“False”

“False”

*Don’t Care*

*Don’t Care*

*Don’t Care*

“Off”

“On”

“Unlocked”

“Locked”

“On”

“On”

“Locked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Unlocked”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off”

“Off” “Off”

“High”

“High”

“High”

0 0

0

0

0

0

0

0

0

0

1

0

1 1

1

1

This PAT contains the transition information of the previous STD.Each row of this PAT could be viewed as representing a state - perhaps!

Using a COMBINATIONAL FSM to represent state information creates ambiguity.Combinational FSMs should be used only in situations when past history is unimportant.

PATs are best usedwhen it is necessaryto view all of thepossible processactivations for a given CFD.

PATs should not beused in lieu of STDsbecause they tend tohide important stateinformation.

Page ‹#›




CONTROL SPEC CONTAINING DT, STD & PAT

Minimum_Inputs_


Received

Light_Setting

Fan_Setting

Lock_Setting


Door_Position

Time_To_Stop

Time_To_Start


Received

Calculate

Average

Temperature

Maintain

Setpoint

Temperature

Accept

Setpoint

Temperature

Accept

Timing Data

1

2

4

6





Count Down

To Time Out

7

Oven_Statess1

s0 Enough_Inputs

Enough_Inputs

s0

Count_Down

Maintain_Setpoint

PATs2

Process (de)activations resultingfrom control actions within an STDcan be made more obvious on thecorresponding CFD by inclusionof a PAT.

The disadvantage is thatsome superfluous controlflows have to be created to connect the STD withthe PAT.


CONTROL SPEC CONTAINING DT, STD & PAT

IDLE_WAITING

Time_To_Stop/Lock_Setting = "Unlocked"; Maintain_Setpoint = "Off"; Count_Down = "Off"



Door_Position = "Open"/Light_Setting = "On"; Fan_Setting = "High"; Count_Down = "Off"

Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"; Count_Down = "On"




Door_Position = "Closed"/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Locked"; Maintain_Setpoint = "On" Count_Down = "On"

Time_To_Start/Lock_Setting = Locked"; Maintain_Setpoint = "On

~Minimum_Inputs_Available/Count_Down = "Off"

(<Start_Date>Received | ~<Start_Date>Received) &<Start_Time>Received &Minimum_Inputs_Available/Light_Setting = "Off";Fan_Setting = "Off";Lock_Setting = "Unlocked";Count_Down = "On"

READY_WAITING

READY_IMMEDIATE

RUNNING

3

4 6

(<Start_Date>Received | ~<Start_Date>Received) & <Start_Time>Received& Minimum_Inputs_Available

/Light_Setting = "Off"; Fan_Setting = "Off"; Lock_Setting = "Unlocked"

IDLE WITH DOOR OPEN


2

1

5


Minimum_Inputs_Available

Alternative to showing (de)activationsof processes within STD is to provideaction decisions (output control flows)that enter a PAT.

Count_ Down

Maintain_ Setpoint

PROCESS 7

"On" "Off" 1

"On" "On" 1

"Off" "Off" 0

PROCESS 1

0

1

0

SHEET-2 (s2) PAT

Page ‹#›




REQUIREMENTS MODEL SUMMARY

DATA FLOWDIAGRAMS

PROCESSSPECIFICATIONS

CONTROL FLOWDIAGRAMS

CONTROLSPECIFICATIONS

DataInput

DataOutput

ControlInput

ControlOutput

Control Inputderived from

Data Conditions

Process Activationsderived from

Control Decisions

PROCESS MODEL

CONTROL MODELAdapted from Hatley/Pirbhai-1987 (Ref 8)


TIMING SPECIFICATIONS

System and Software Requirements Specifications:

– are the result of analysis.

– are fully documented statements of what a system orsoftware product must achieve.

– should not contain descriptions of system structureor how to achieve particular requirements.

– become the starting point for design.

Timing Specifications therefore:

– are determined for overall (external) systembehaviour.

– are not provided for particular (internal) processessince no design structure has yet been determined.

Page ‹#›




TIMING SPECIFICATIONS

THESYSTEM

0

TERMINATOR TERMINATOR

TERMINATOR TERMINATOR

T0

0

T10 -T0

0

T 0 -T02

Repetition Rate

Input-to-OutputResponse Time

All Timing Specifications relate toinputs to, & outputs from systemas a whole.

There are two types ofTiming Specification.


TIMING SPECIFICATIONS - REPETITION RATE

<Accepted> Timing_Data

Time_Remaining

Temperature_ Overrun

Average_ Temperature

Setpoint_ Temperature

Timing_Data

Temperature

Heat_Setting

Light_Setting

Fan_Setting

Door_Position

Lock_Setting

Maintain Oven

Temperature

0

OPERATORDOOR

EXHAUST FAN

OVEN LIGHT

HEATING ELEMENTTHERMOMETER

Output signal(s) that are requiredto be recomputed at a particularfrequency.

Page ‹#›




TIMING SPECIFICATIONS - REPETITION RATE

REPETITION RATE:

– The required recomputation rate of signal outputs tothe external environment.

– Is included with the description of the signal in theRequirements Dictionary.

• Example (from previous slide)

Time_Remaining = *The amount of time that remains before a run ends*----------Units: Hours:Minutes:SecondsRange: 0:0:0 to 12:0:0Accuracy: 1 secondRate: Once per minute


TIMING SPECIFICATIONS - I>O RESPONSE TIME

INPUT-TO-OUTPUT RESPONSE TIME:

– A specification of allowable timing ranges (withinwhich the system must respond) for each input eventand the resulting output response(s).

– Can be included with each of the dictionarycomponents that contribute to the various sets ofevent-responses.

– Is better to tabularise.

Page ‹#›






Time_Remaining

Temperature_Overrun

Average_Temperature

Setpoint_Temperature

Timing_Data

Temperature

Heat_Setting

Light_Setting

Fan_Setting

Door_Position

Lock_Setting

MaintainOven

Temperature

0

OPERATORDOOR

EXHAUST FAN

OVEN LIGHT

HEATING ELEMENTTHERMOMETER

Input signals and correspondingoutput responses, some of whichare time critical.



EXTERNALINPUT

SIGNAL

EXTERNALOUTPUTSIGNAL

RESPONSETIME

EVENT EVENT

Temperature Temperaturevalue is read

Heat_Setting Heat_Settingvalue is issued

< 1 second

Temperatureoutside

tolerance

Temperature_Overrun

Temperature_Overrun value

is issued

< 0.5 second

Door_Position Door isclosed

Fan_Setting,Light_Setting

Fan and Lightare turned off.

< 50 milli secs

Timing_Data Timingdata isentered


Timing_Datavalue is

accepted

Not critical.

...................... .............. ................... .................... ....................

Table of Specified Input-to-Output Response Times

Page ‹#›




GUIDELINES FOR USING HATLEY/PIRBHAI

There are no strict step-by-step procedures.

However, the following guidelines are useful:-

• Construct an Event/Action list to more easily:

– Identify processes that transform input data (ormaterial) flows into output data flows.

– Isolate those inputs that directly control the internaloperation of the system.

– Isolate those data inputs that are used to makedecisions about controlling parts of the system.

– Identify various operating modes together with theinputs that cause operational mode changes.



• Use Event/Action list to separate data signals fromcontrol signals.

– Data signals usually have some content in the formof a range of non-discrete values.

– Control signals will always have discrete values andtend to be used to trigger some action.

Activate, enable, engage, execute, stop/start, trigger, toggle.

– Some signals may have discrete values but not bepart of the control model - they are then data signals.

Page ‹#›





• Use Event/Action list to establish processes first.

– Because it is preferable to identify what is to becontrolled before isolating control-type activities.

• Establishing what is to be controlled before thinking too muchabout control issues ensures less confusion and fasterprogress toward a good set of requirements specifications.

– Because the control model is dependent upon theprocess model in most systems.

– By applying DeMarco approach to construct theessential functional abstractions anddecompositions.

• This can be done by transforming the event/action list into a setof event/action diagrams before composing a set of DFDs.



• Keep control issues at a high-level.

– Because it is important to determine systemoperating modes (states).

– Because low-level control issues tend to be morestrongly related to implementation issues.

• Overuse of Hatley/Pirbhai Model at lower levels of functionaldecomposition can obscure specifications with implementationdecisions.

– Because it will aid architectural decisions during thedesign phase.

Page ‹#›




HATLEY/PIRBHAI & SYSTEM DEVELOPMENT

SYSTEMREQUIREMENTS

COLLECTION

SYSTEMDESIGN

SOFTWAREREQUIREMENTS

ANALYSIS

HARDWAREREQUIREMENTS

ANALYSIS

SYSTEMINTEGRATIONAND TESTING

PRELIMINARYDESIGN

DETAILEDDESIGN

FABRICATION

HWCITESTING

PRELIMINARYDESIGN

DETAILEDDESIGN

CODINGAND UNITTESTING SOFTWARE

INTEGRATIONTESTING

SYSTEMREQUIREMENTS

ANALYSIS

HARDWARE DEVELOPMENT

SOFTWARE DEVELOPMENT

Documents

THE HATLEY/PIRBHAI MODEL - pudn.comread.pudn.com/.../592939/comp8100/Hatley-Pirbhai-BW.pdf · 2008-06-12 · •Primitive control flow definitions are common with most systems. •Decomposable