RealTime Analysis and Design

1
Real-Time Analysis and Design

• Dr. Jo Hartley
• Room N507
• 5th December 2000

2
Syllabus

• Introduction to real-time systems and Essential
  model
• Data transformations and Data flows, Data stores,
  Conservation of Data and Synchronous Data rules
• Control transformations, Event and Control flows,
  and Event stores

• Organising the model
• State-transition diagrams and Data transformation
  specification
• Implementation model
• Data dictionary
• Processor level
• Task level
• Module level
• Testing

3
Lecture 4.Real-Time Analysis and Design

• Processor level
• Task level
• Module level
• Review
• Essential model
• Implementation model
• Testing

4
Processors

• Definition
• person or machine that can carry out instructions
  and store data
• Concurrency
• true concurrency of operation possible, because
  processor provides its own execution and storage
  resources

5
Processor Environment Model

• Transforms (from Essential model) are matched to
  processor characteristics
• Processors are named according to purpose
• Processors have data and control flows

6
Mechanics of allocation

• Top-down approach through essential model
• allocate transformation to single processor
• if impossible, examine lower levels and allocate
• splitting transforms requires additional flows
  between processors
• combine into transformation schema for each
  processor
• Processor stage has one processor transformation
  for each processor

7
Splitting a control transformation

• Duplicate ST diagram for each processor
• Check conditions and actions for each transition
  for each processor and select appropriate case
• 1. Condition sensed and action taken by this
  processor Add an action to show condition has
  been sensed
• 2. Condition sensed by this processor, action
  taken by other processor Replace action by a
  signal that condition has been sensed
• 3. Condition sensed by other processor, action
  taken by this processor Replace condition by
  receipt of a signal that condition has occurred
• 4. Condition sensed and action taken by other
  processor Replace condition by receipt of
  signal that condition has occurred, remove action

8
Splitting a control transformation

• Check each state iteratively. For each state
  where
• All outgoing transitions have conditions that are
  signals from other processors and no actions
• All outgoing transitions are directed to a single
  destination state whose outgoing transitions all
  have conditions that are signals from another
  processor
• Do
• Remove state and its outgoing transitions
• Reroute incoming transitions to destination state
• Remove any actions which are signals with no
  recipient
• Rename states for clarifications

9
Tasks

• Definition
• set of instructions that is manipulated (started,
  stopped, interrupted and resumed) as a unit by
  the system software of a processor
• Concurrency
• capable of concurrency of operation if processor
  has multiple CPUs or shares its resources among
  the tasks to simulate concurrency

10
Task level

• Essential model mapped onto task level of
  implementation model
• If required, data transformation schema are used
  to model concurrency
• Any essential sequence or synchronisation is
  modelled with a State Transition diagram

11
Allocation to Tasks

• Approximations introduced
• sampling continuous flows
• buffering discrete inputs which arrive at too
  high a rate
• synchronising access to data
• simulating concurrency within a task
• managing communication between processors

12
Modules

• Definition
• set of instructions activated as a unit by the
  control logic within a task in a mutually
  exclusive fashion
• Concurrency
• no concurrency possible

13
Code Organisation

• design down to module level
• identify required modules
• resulting in structure chart
• design module internals
• resulting in pseudocode
• refine the design
• consider constraints of selected programming
  language
• optimise and package the design
• consider external constraints and hardware
  limitations

14
Design Strategies

• Transform Centred
• when task schema shows no. of transforms
  performed in sequence on one or two data streams
  which flow through the tasks
• Transaction Centred
• when data flow splits into several sub-types each
  of which require a different operation to be
  performed on them
• State Centred
• when essential control and sequencing within the
  task schema is specified by a control
  transformation

15
Transform Centred Design

• 1. Identify the main flow through the task.
• 2. Identify the most refined input and output
  flows.
• 3. Partition the diagram into afferent (input),
  efferent (output) and central parts.
• 4. Verify the partition is consistent with the
  essential purpose.
• 5. Reflect the partition by hierarchy of
  modules.
• 6. Extend hierarchy to manage input and output
  responsibility.

16
Transaction Centred Design

• 1. Input the source of transactions and the
  transactions to be performed.
• 2. Appoint a highest module.
• 3. Appoint a hierarchy of modules to do the
  following
• get and classify the source of transactions
• one module to carry complete responsibility for
  each transaction
• 4. Factor each transaction level module in the
  most effective manner, taking care not to combine
  transactions if they are very similar.

17
State Centred Design

• 1. Appoint a highest module.
• 2. Appoint manager modules for each state.
• 3. Treat events and conditions as a source of
  transactions and appoint junior manager modules
  to be in charge of each set of actions.

18
The Implementation Model
19
The Essential Model
20
Software safety

• schematic
• show that overall pattern of the system is
  correct using tokens
• prototype
• simulate quantitative aspects - direct
  implementation
• formal tool
• petri nets - hazard identification

21
Use of Tokens as Dynamic Overlay for
Transformation Schema

• Tokens are discrete inputs
• Continuous arrow implies presence of token always
• If wishing to store tokens, must place them in a
  store otherwise they are lost

22
The Rules of Tokenisation

• If a transformation schema has multiple input
  flows with two or more tokens, the resulting
  execution is sequential but indeterminate in
  order
• To show the overall pattern of the system model
  is correct
• Tokens are placed on all time-continuous data
  flows that are inputs to the schema
• Tokens are placed on transformations with no
  prompts
• All unprompted control transformations are placed
  in their initial states
• Tokens are placed on output event flows of
  control transformations as required by initial
  states
• Any executions required by previous steps are
  performed
• Tokens are placed in any control store with an
  initial value greater than zero
• Execute with output tokens on discrete outputs of
  the schema being recorded and removed

23
Executing the Transformation Schema

• Execution
• Transformation occurs in zero time

24
Executing the Transformation Schema

• Enabling
• Disabling

25
Control Transformation

• The execution of a control transformation is not
  defined unless there is a state-transition
  diagram.
• A control transformation is prepared for
  execution when a token has been placed within the
  state-transition diagram.
• The absence of a token is legitimate when the
  control transformation has been disabled by
  another.
• A token is placed on an input event for execution
  of an enabled control transformation.

Enable
A
A
B
Enable
Disable
B
Disable
26
Syllabus completed

• Introduction to real-time systems and Essential
  model
• Data transformations and Data flows, Data stores,
  Conservation of Data and Synchronous Data rules
• Control transformations, Event and Control flows,
  and Event stores

• Organising the model
• State-transition diagrams and Data transformation
  specification
• Implementation model
• Data dictionary
• Processor level
• Task level
• Module level
• Testing