Timing Specification Techniques

1
Timing Specification Techniques

• W. T. Tsai
• Department of Computer Science and Engineering
• Arizona State University
• Tempe, AZ 85287
• wtsai_at_asu.edu

2
Overview

• Motivation
• Guarded Method Sequence Specification (GMtSS)
• Design and Implementation Techniques for
  Time-Critical Systems
• GMtSS Specialization and Inheritance

3
Motivation

• In recent years demands for challenging
  new-generation real-time application arisen
• Distributed multimedia processing
• Next-generation RT VR (Virtual Reality)
• Multi-party multi-media conferencing
  collaboration
• Distributed orchestra
• Military command-control
• Time-sensitive health care
• Tele-medicine, Remotely controlled surgery, etc.
• Non-stop web servers
• Embedded Computing Systems
• Sensor networks
• Embedded computing
• Ubiquitous computing

4
Timing Should be Addressed at Specification Level

• Addressing timing issues at coding and testing
  level is rather late.
• It is necessary to add timing constraints into
  the system specifications.
• One approach is to add timing constraints into a
  specific specification language such as UML.
  Currently, many attempts have been made to add
  constraints into UML such as OCL (e.g.,
  http//www.klasse.nl/ocl/ocl-introduction.html),
  but in most cases, timing constraints have not
  been a priority item.

5
Adding Timing into Software

• Many programming languages allow timing
  information to be accessed directly, e.g., Ada,
  OCCAM2, and C. For example, in ANSI C has a
  basic time type time_t.
• IEEE POSIX standards requires at least one clock
  to be supported with minimum resolution of
  CLOCK_REALTIME is 50 Hz or 20 ms.
• However, programming in time is still difficult
  and complicated.

6
Adding Timing Information into OO Programs

• Prof. K. H. Kim in his DREAM project developed a
  set of programming constructs that allow timing
  information to be processed in an OO language.
• Basic idea is that methods can be triggered by
  time without any other external sources such as
  methods, i.e., the method will be activated once
  the time arrives. You may find his approach by
  reading the following overview paper.
• http//dream.eng.uci.edu/TMO/pdf/overview_200502.p
  df

7
Adding Timing Information into OO Programs

• At time T do S
• Start S during T - ?, T ?
• S may be a single assignment statement, a
• compound statement, or a function.
• http//dream.eng.uci.edu/TMO/pdf/overview_200502.p
  df

8
Adding Timing Information into OO Programs

• Write abstract specifications of timing-sensitive
  actions
• Design Time-triggered Message-triggered Objects
  (TMO) or Time-Triggered Spontaneous Method (SpMs)
• Specify method completion deadline
• Maximize concurrency by data relation analysis

http//dream.eng.uci.edu/TMO/pdf/overview_200502.p
df
9
Guarded Method Sequence Specification (GMtSS)

• Introduction
• Method Sequence Specification (MtSS)
• Guarded MtSS (GMtSS)
• Usage of GMtSS guards
• Restrictions on Guards
• Interpretation of GMtSS
• Trigger and Synchronization Properties using
  GMtSS
• Completeness and Consistency Checking of GMtSS
  specifications

10
GMtSS Motivation

• Several OO and other modeling techniques exist.
  Examples Causal obligations, MtSS, action
  histories, event trace diagrams, path expressions
  etc.
• Modeling of object interactions involving time
  has received limited attention
• Techniques to model interactions between objects
  in OO systems involving timing constraints are
  required

11
GMtSS

• MtSS Regular expression based notation for
  specifying the sequencing relationships among
  different methods of a class. No support for
  representation of timing constraints
• GMtSS Is an extension to MtSS
• Enables the specification of constraints that
  involve sequencing as well as timing
  relationships among the method interactions
  between the objects

12
GMtSS Definition

• Consists of three components
• a MtSS referred to as the base MtSS
• zero or more guards, referred to as the guard
  set, that specify timing and other relationships
  among methods in the base MtSS
• a condition vector that represents boolean
  relationships among the base MtSS and the guards

13
GMtSS Guards

• Uni-Guards
• Bi-Guards
• MtSS Guards
• S-Guards

14
Uni-Guards

• Guards that express timing relationships that
  involve a single method. Uni-guards specify how
  much time should have elapsed since a particular
  method call
• 3 types
• Delay specifies that at least a certain time
  must have passed after the execution of a certain
  method
• Deadline specifies that at most a certain amount
  of time must have passed after a method call
• Exact specifies that exactly a certain amount of
  time must have passed after a method call
• Condition Brady Therapy active for at least 5
  seconds
• Base MtSS (activate_brady suspend_brady
  resume_brady deactivate_brady) .
  activate_bradyi
  
• Guard Delay (activate_bradyi) 5

15
Bi-Guards

• Conditions expressed between pairs of method
  calls
• 3 types
• Delay used to specify that at least a certain
  amount of time must pass between two method calls
• Deadline used to specify that at most a certain
  amount of time must pass between two method calls
• Exact used to specify that exactly a certain
  amount of time must pass between two method calls
• A slow atrial beat (at least 3 seconds between
  consecutive atrial beats) is expressed as
  follows
• Base MtSS a_beati. a_beati1
• Guard Delay (a_beati, a_beati1) 3

16
MtSS-Guards

• Used to specify that a sequence of methods must
  not occur relative to the occurrence of some
  method in another MtSS
• Specified as m.!M, indicating that the method
  sequence M must not occur after the occurrence of
  the method m
• The condition Magnet applied for 30 seconds
  without removal can be expressed as follows
• Base MtSS (apply_magi remove_mag).
  apply_magj
• Guard1 Exact (apply_magj) 30
• Guard2 apply_magj. !remove_mag

17
GMtSS Examples

• Normal atrial beat. This is defined as an atrial
  beat (a_beat) that occurs at least one second and
  at most three seconds after the preceding atrial
  beat
• Base MtSS a_beati. a_beati1
• Guard1 Delay (a_beati, a_beati1) 1
• Guard2 Deadline (a_beati, a_beati1) 3
• No ventricular beat (v_beat) within 3 seconds of
  an atrial beat (a_beat)
• Base MtSS a_beat
• Guard1 Exact (a_beat) 3
• Guard2 a_beat. !v_beat

18
Interpretation of GMtSS

• GMtSS is considered to be satisfied when the
  condition vector which is based on the base MtSS
  and individual guards is satisfied over the
  objects method call history
• A base MtSS is interpreted using a corresponding
  equivalent automata
• Each Guard (except S-Guard) also has a equivalent
  automata defined. Delay Uni-Guard automata shown
  here.
• Based on the base MtSS automata as well as the
  automata for the guards, a GMtSS is satisfied at
  some instant if each of the automata is in its
  final state at that instant

19
Interpretation of GMtSS

• GMtSS is considered to be satisfied when the
  condition vector which is based on the base MtSS
  and individual guards is satisfied over the
  objects method call history
• A base MtSS is interpreted using a corresponding
  equivalent automata
• Each Guard (except S-Guard) also has a equivalent
  automata defined
• Based on the base MtSS automata as well as the
  automata for the guards, a GMtSS is satisfied at
  some instant if each of the automata is in its
  final state at that instant

20
Trigger and Synchronization Properties using GMtSS

• Can be used to represent constraints or
  conditions that an application must satisfy
• Synchronization Properties model the conditions
  (represented using a GMtSS) that must be
  satisfied for a method to be safely invoked
• Trigger Properties specify what actions must be
  executed when a certain set of conditions
  (represented using a GMtSS) is satisfied

21
Synchronization Properties

• Requirement Brady Therapy can be suspended only
  if it has been active for at least 5 seconds
• Let G be the GMtSS that specifies the condition
  Therapy active for at least 5 seconds
• Synchronization Property Enable (suspend_brady)
  G

22
Trigger Properties

• Trigger property is modeled as T-gtm1, m2 mN,
  where T is a GMtSS and m1, m2 etc. represent
  methods in objects
• If three consecutive fast beats occur, then
  Therapy must be activated
• Let G1 be the GMtSS specifying three consecutive
  fast beats. This requirement can be specified as
  follows G1 -gt activate_brady

23
Consistency Checking

• Consistency Checking Ensures that the
  specifications do not conflict with each other
• Localized consistency checking Given the
  complexity and size of constraints in typical
  industrial systems, it is not practical to
  perform checks on a global scale. Localized
  checks that focus on specific areas are required.
• Propose 3 different types of localized checks
  based on experience for GMtSS specifications
• Peer consistency checks
• Scenario based consistency checks
• Platform consistency checks

24
Peer Consistency

• Focuses on consistency checks between peers which
  are system entities that exchange messages or
  data. Ensures that the behavior of a system
  component will not conflict or cause problems to
  its peer.
• Focuses on different timing properties and
  specifies rules.
• Types of checks
• early event check If a component requires a
  delay before a certain event is generated by its
  peer, then check if its peer has a corresponding
  requirement inserting at least that amount of
  delay before generating that event, i.e., ensure
  that a component does not generate an event
  earlier than its peer expects it.
• Other checks late event check, minimum rate
  check, maximum rate check, exact rate check,
  periodic event check

25
Scenario-based Consistency

• Check consistency within a scenario or a set of
  actions
• Types of checks
• deadline-deadline consistency check This check
  considers the case where a scenario has a
  deadline on its completion and one or more of its
  sub-scenarios also have deadlines on them. The
  deadline-deadline consistency check verifies
  whether the deadline of a sub-scenario is
  consistent with that of the scenario in which it
  is a part of.
• deadline-delay consistency check This check
  considers cases where a scenario has a deadline
  on its execution while a sub-scenario has a delay
  constraint on it. This check verifies whether the
  delay constraint on a sub-scenario is consistent
  with the deadline constraint of the scenario that
  it is part of.

26
Platform consistency

• Platform support can be critical for satisfying
  certain types of timing requirements
• Check consistency of timing specifications with
  platform
• Example checks
• processor speed.
• number of transactions that can be handled per
  second by the database.
• message handling capabilities of middleware such
  as CORBA or RPC
• capabilities of transport links such as switches,
  routers, T1 lines etc.

27
Design and Implementation Techniques for
Time-Critical Systems

• GMtSS Implementation Framework
• Design Idioms for Time-Critical Systems
• Design Patterns

28
GMtSS Implementation Framework Goals

• Develop a reusable OO framework that facilitates
  embedding of GMtSS specifications into
  application code.
• Framework must provide a base set of classes with
  common functionality. Applications must be able
  to extend/specialize the framework classes for
  their individual constraints.
• De-couple constraints from other system
  functionality so that each of them can be
  modified and carried over into future product
  versions independently
• Additional types of guards must be easy to add
• Allow for flexible modification of constraints

29
GMtSS Object Model
30
GMtSS Implementation Framework

• Implementation of Guards
• each guard is assumed to have a separate class
• applications instanstiate guard classes when
  implementing GMtSS properties
• base guard class provides interfaces that are
  used for providing interfaces to GMtSS and other
  interacting classes
• specialized guard classes implement the finite
  automata for interpreting the specific guard.
• each Guard is assumed to implement the abstract
  EventHandler interface so that it can be notified
  of events
• each Guard registers with the EventDispatcher to
  be notified of events of interest to it.
• MtSS also considered a special type of guard for
  implementation ease

31
GMtSS Implementation Framework contd.

• Implementation of GMtSS
• abstract GMtSS class implements the containment
  relationship with a base MtSS and several guard
  classes
• concrete GMtSS classes implements the condition
  vector and the interpretation mechanisms for a
  particular GMtSS
• concrete GMtSS classes use the interfaces
  provided by the Guard classes to query the state
  of each guard
• applications have to develop concrete GMtSS
  classes, one for each GMtSS property

32
GMtSS Implementation Framework contd.

• Implementation of Synchronization Properties
• for each property, develop the required concrete
  GMtSS classes.
• instantiate the concrete GMtSS objects at
  appropriate locations in the applications
• Setup the appropriate GMtSS objects.
• When a method is invoked, query the state of the
  GMtSS objects to check if the method is enabled
  or disabled based on the enable or disable
  properties associated with the method.

33
GMtSS Implementation Framework contd.

• Trigger Properties
• framework provides abstract ActionHandler class
  with an action method
• concrete ActionHandler classes specialize the
  action method
• applications have to develop the concrete
  ActionHandler classes.
• applications have to instanstiate concrete
  ActionHandler objects and register them with
  GMtSS objects.
• the action method is invoked on each of the
  registered ActionHandler objects whenever GMtSS
  in the trigger property is satisfied

34
Example wireless application

• Wireless application with several timing
  constraints
• developed specialized GMtSS classes as well as
  specialized ActionHandler classes
• Application included both trigger and
  synchronization properties
• state machine implemented using GMtSS framework

35
GMtSS Implementation Framework Observations

• Supports modification of constraints and
  associated actions independently
• GMtSS and guard classes can be reused across
  products
• Additional guard types can be supported by adding
  specialized Guard classes for them to the
  framework. Other parts of the framework are not
  impacted by this.
• Analysis is required to determine when GMtSS
  objects need to be created during run-time
• Same action handler class can be used for several
  trigger properties

36
Design Idioms for Time-Critical Systems

• Piggybacking
• Quick Repeating
• Detect Transmission Failures Closest to the
  Receiver
• Reduce Context Switching Delays
• Prioritize Event Processing

37
Combined View Pattern

• Use this pattern when multiple attribute values
  are needed from a remote server at the same time
  and operations to retrieve individual attributes
  are costly

38
Transaction Pattern

• Use this pattern when failures can happen during
  the execution of a complex operation

39
Timed Operation Pattern

• Use this pattern when a deadline timing
  constraint needs to be placed on the execution of
  a synchronous method

40
Command Sequencer Pattern

• Use this pattern when the same command needs to
  be performed on a list of entities in a specific
  sequence. The sequence may need to be changed
  dynamically.

41
Message Retransmitter

• Use this pattern when reliable delivery of
  messages is required through re-transmissions of
  messages when their acknowledgements do not
  arrive within a given timeout period.

42
GMtSS Specialization and Inheritance

• Adding new system features while maintaining
  existing constraints is important when families
  of products are developed
• Helps in reducing the costs of development as
  well as testing
• OO technology facilitates behavioral refinements
  and extensions to classes using the concept of
  inheritance
• Inheritance can be used as a mechanism for either
  reusing the code in existing classes or for
  behavioral subtyping to define subclasses that
  behave as subtypes of their parent classes.
• How can GMtSS based specifications used for
  specifying constraints on a base class be
  modified in a subclass such that the subclass is
  a behavioral subtype of the base class?
• The concept of GMtSS specialization and
  generalization is proposed as a means to support
  behavioral subtyping of classes that use GMtSS
  specifications.

43
Subtyping

• The behavior of objects can be viewed as
  describing the type information for the objects,
  i.e., a description of how the objects can be
  used safely.
• According to principle of substitutability
  Wegner 88 used widely An instance of a subtype
  can always be used in any context in which an
  instance of a supertype was expected.
• In the context of safety-critical systems, we
  define a subtype to be one that satisfies all the
  safety constraints of the supertype.
• This means that whenever a subtype is substituted
  in place of a supertype, no safety constraints
  would potentially be violated.
• How can constraints on base classes expressed
  using GMtSS be translated into GMtSS
  specifications for their subtypes based on above
  definition?

44
Subtyping Example

• A Therapy object can be in one of two states
  active or inactive, with transitions between the
  two states when calls are made to activate () and
  deactivate () methods. Initially the object is
  assumed to be in the inactive state.
• Can be modeled as
• Enable (activate) lt(activate.deactivate), gt
• Enable (deactivate) lt(activate.deactivate).acti
  vate, gt

45
Subtyping Example contd.

• A Timed Therapy object can be in one of two
  states active or inactive, with transitions
  between the two states made on activate () and
  deactivate () method calls. Once the object
  enters the active state, it must remain in the
  state at least for 3 seconds before it can be
  de-activated. Initially the object is assumed to
  be in the inactive state.

46
Subtyping Example contd.

• Substituting a Therapy object in place of a Timed
  Therapy object would lead to a violation of the
  safety constraint on the deactivate method
  because the Therapy object would accept the
  deactivate method within 3 seconds after entering
  the active state.
• Substituting a Timed Therapy object for a Therapy
  object would not lead to violations of any safety
  constraints of the Therapy object.
• Timed Therapy is a subtype of Therapy

47
GMtSS Specialization rule

• A GMtSS specialization is defined as a
  relationship between two GMtSSs defined such that
  one of the GMtSSs holds whenever the other holds
  for a given method call history. A GMtSS Gi is
  defined to be a specialization of GMtSS Gj
  (represented as Gj-gtGi), if Gi is satisfied
  whenever Gj is for a given method call history
  (conversely Gj is called the generalization of
  Gi). Thus Gj-gtGi means that Gi holds whenever Gj
  holds for a given method call history.

48
Synchronization Properties Modification

• Enable Property Rule Changing an enable property
  of the form Enable (m) GB in a base class B
  to the form Enable (m) GD, where GB is a
  specialization of GD, in a derived class D,
  ensures that the enable property in the base
  class B still holds in the derived class D.
• Disable Property Rule Changing a disable
  property of the form Disable (m) GB in a base
  class B to the form Disable (m) GD, where GD
  is a specialization of GB, in a derived class D,
  ensures that the disable property in the base
  class B still holds in the derived class D.

49
Trigger Properties Modification

• Trigger Property Rule Changing a trigger
  property of the form TB-gtR in a base class B to
  the form TD-gtR, where TD is a specialization of
  TB, in a derived class D, ensures that the
  trigger property in the base class B still holds
  in the derived class D.

50
GMtSS Specialization Rules

• Base MtSS Weakening
• Rule 1 L(Base(Gi)) ? L(Base(Gj)).
• Delay Constraints
• Rule 2 For any Delay uni-guard gk Delay(m)
  T1, a corresponding Delay uni-guard gl of the
  form Delay(m) T2, is weaker if T1 gt T2.
• Other rules for other types of GMtSS constructs
  are defined

51
Construction Approach

• Incrementally weaken elements of a GMtSS to
  derive a specialized GMtSS
• Weaken base MtSS, guards or condition vector

52
GMtSS Specialization Observations

• Work focused on individual objects
• Many systems also have constraints that span many
  sub-systems and objects within them - a more
  detailed analysis is required to understand the
  ramifications of making extensions to one or more
  sub-systems or objects.
• Changes to one object may necessitate
  modifications to other interacting objects or
  sub-systems.
• Verification still required even with systematic
  changes
• Tools and techniques that can facilitate testing
  with emphasis on the modified parts of the
  constraints, can be useful in reducing the costs
  associated with testing new products.