Real-Time System Requirements

1
Real-Time SystemRequirements Design Specs

Lecture 4/17

• Shaw - Chapters 3 4
• Homework 2
• 3.3.1,
• 3.4.1,
• Add Error states to Fig 4.1

2
The Problem

• We need to be able to describe a system
  unambiguously and prove that it can meet desired
  criteria before we begin the design.
• Unfortunately the reality is that for almost all
  practical systems, the complexity and the scale
  of the system makes this extremely difficult if
  not virtually impossible, at least with todays
  tools and methodologies.
• Concurrency can easily produce race conditions.
  Mutual exclusion solutions can produce deadlocks
  or starvation. Etc.

3
Practical Approaches?

• Behaviors for many scenarios of interest can be
  demonstrated through simulation or prototyping.
• Executable specifications can be useful for
  clarifying or refining requirements and designs.
• Bottom up approaches often allow designs to
  evolve through increasingly adding complexity to
  proven simplified models and subsystems.

4
Imperative vs Declarative Specs

• Imperative specs specify system behaviors in
  terms of algorithmic descriptions. These can be
  visualized and translated into computer
  procedures and prototypes, supporting rapid
  prototyping.

5
Imperative vs Declarative Specs

• Declarative descriptions specify properties that
  must be satisfied by the system. It is usually
  easier to prove properties with these
  descriptions, but more difficult to use them to
  generate designs.
• Declarative descriptions specify properties that
  must be satisfies by the system. It is usually
  easier to prove properties with these
  descriptions, but more difficult to use them to
  generate designs.

6
Some Approaches Shaw Explores

• Data Flow Diagrams Provides an attractive
  visualization which can be easily developed and
  evolved by a team.
• Tabular Languages Provides a way to express and
  communicate a lot of requirements in a
  comprehensive and complete process.
• State Machines State machines have proven to be
  a language of choice for many traditional
  modeling and design projects. A number of
  adaptations have been proposed and used
  effectively in real-time system designs.

7
Some Approaches Shaw Explores

• Formal Methods Sophisticated mathematical
  techniques can provide powerful description and
  verification of systems, for example
• Regular expressions
• Propositional Logic
• Predicates
• Temporal Logic

8
Data Flow Diagrams

• They are based on a familiar tool
• They provide an attractive visualization which
  can be easily developed and evolved by a team.

9
Data Flow Diagrams (DFD)
10
DFD Example
11
DFD Example
12
DFD Deficiencies

• Lack of control information
• Lack of timing
• Lack of scheduling specification

13
Tabular languages

• They provide a way to express and communicate a
  lot of requirements in a comprehensive and
  complete process.
• They nicely tabulate Conditions and Actions
• They are easily expanded, partitioned, and
  simplified.

14
Tabular Languages
15
Example of Tabular Language
16
Example Tabular Language
17
Tabular Language Deficiencies

• Timing and logical constraints are listed
  separately
• There does not appear to be an obvious way to
  include concurrency and timing in an effective
  way.

18
Finite State Machines

• State machines have proven to be a language of
  choice for many traditional modeling and design
  projects. A number of adaptations have been
  proposed and used effectively in real-time system
  designs.
• We will look at one approach Communicating
  Real-Time State Machines (CRSM)

19
FSM Example
20
FSM Example
21
Allowing Outputs in FSM
22
Chapter 4 Systems of State Machines

• Communicating Real-Time State Machines
• An attempt to create a complete executable design
  specification language
• Time is integral to the language

23
CRSMs

• CSRMs are state machine with guarded commands for
  transitions, synchronous communicating senders
  and receivers, and explicit time restrictions.
• A complete CSRM system contains both a simulation
  of the internal system and its external
  environment.
• They are an extension of Tony Hoares classical
  Communicating Sequential Processes

24
Terminology
Denotes the timing constraint, i.e. the lower
tmin and upper tmax bounds on time allowed during
the transition. Then for an execution or
deadline d,
0 lt tmin lt d lt tmax
25
Terminology

• Communication
• Communicating Channel name
• channel
• Sending a message over channel
• channel(message)!
• Receiving a message through channel
• channel(target)?
• ? Effect is equivalent to an assignment
• target message

26
CRSM Timing
M1 (sender) enters state U at time Tu, and M2
(Receiver) enters state X at Tx
I/O must occur between Tua and Txd or CRSM will
transition to an error state
27
Bounded Buffer Example
28
Mouse Click Example