OO Formal Methods in DESS RealTime

1
OO Formal Methods in DESS(Real-Time Embedded
Applications)

• Vieri del Bianco, Luigi Lavazza, Marco Mauri
• Software Engineering Area
• delbian_at_bigfoot.com

2
Summary

• Introduction to formal methods for real-time
  requirements and specifications
• approaches
• Classifications of real-time specifications
  complexities with reference to three examples
• Car speed regulator
• GRC generalized railroad crossing
• DESS sample problem
• The DESS approach to the specification of
  real-time systems

3
Approaches descriptive formalism

• Pure temporal logic
• implicit time
• no metrics
• Time infinitely elastic
• Metric temporal logic
• Lots of dialects
• Time metric defined
• Discrete or dense time (both approaches in a
  formalism are very rare

• Examples
• RTL (Real-Time Logic)
• RTTL (Ostroff) (Real-Time Temporal Logic)
• Abadi Lamport
• TRIO (TRIO)
• ASTRAL (TRIO)
• TLT

4
Approaches operational formalism

• Synchronous approach
• Finite State Machines
• Lots of dialects
• Global clock
• Each component can change its own local state
  synchronously with other components
• Signals (local, shared)
• Time (explicit or implicit), typically discrete

• Examples
• Timed Automata
• KRONOS

5
Approaches operational formalism

• Asynchronous approach
• Petri nets
• Lots of dialects
• Each process evolves autonomously, only
  occasionally synchronizes with other processes
• Time may be either discrete or dense (rational,
  real)

• Examples
• PN
• TPN (timed)
• CPN (coloured)
• CTPN (communication timed)

6
Approaches real differences

• Synchronous vs asynchronous
• Expressiveness is almost identical
• But philosophically there is a big difference
• There exist cases in which the asynchronous
  approach is the only feasible approach
• Distributed systems components physically in
  different locations
• Not pure signals signals through channels
• Speeds comparable with light speed

• Descriptive vs operational
• Operational nearer to implementation code
• Firm distinction is not always clear
• Expressiveness is not the same
• Usually descriptive languages are more expressive

7
Approaches dual formalism

• Dual language
• System described with an operational formalism
  (automata, PN)
• System properties are asserted through a
  descriptive formalism (temporal logic)
• System is proved verifying properties against the
  system (model checking, formal demonstrations)

• Examples
• Ostroff
• TRIO/PN (trio with axioms to traduce Petri Nets
  formalisms)
• STEP
• Kronos

8
Specifications classification

• No pretension to be a full classification
• Results of some simple pilot examples used to
  test DESS and other methodologies
• Big differences in complexity were found
• independent from the specification size
• some complexities are not solvable with a single
  (operational) approach (we need at least a dual
  approach)
• intuitive time constraint may be simple to
  express but very hard to formalize
• complexity differences appear when changing the
  temporal logic dialect, even with the same time
  constraints

9
Specification car speed regulator
Vtarget

• Periodic behaviour
• In every period the task assigned must be
  completed
• Task is fixed
• Little evolution possibilities
• No complex concurrent behaviour
• Evolution is fully deterministic

Speed Regulator
?C
Cdriver
Engine Unit
Vcar
10
Specification GRC generalized railroad crossing

• Aperiodic behaviour
• System is totally controlled by external events
• Not so many possible system evolutions
• Concurrent behaviour
• Evolution is not fully deterministic
• The utility condition implies the maximization of
  opening time

RI
II
RO

• RI in sensor
• RO out sensor
• RI-RO monitored zone
• II-RO critic zone
• Security gate closed when a train is in the
  critic zone
• Utility gate will be opened when there are no
  trains in the critic zone

11
Specification DESS example 1/2

• Deadline constraint
• Each tick of Clock 1 the filter must elaborate
  the Sensor 1 signal in Td
• Separation constraint
• Each data output by the corrector must be emitted
  no before than Tsmin and no after than Tsmax
• Freshness constraint
• Each data output by the corrector must be
  computed from input data no older than Tf
• Correlation constraint
• Each data output by the corrector must be
  computed from input data which are not separated
  by a delay lt Tc

Sensor 1
Sensor 1
Clock 1
Clock 2
Filter 1
Filter 2
Buffer 1
Buffer 2
Corrector
Clock 3
Sensor 1
12
Specification DESS Example 2/2

• Aperiodic behaviour
• System is totally controlled by independent
  clocks
• Lots of possible system evolutions
• Heavy concurrent behaviour
• Independent clocks
• Ticks may be lost without breaking the constraints

• Evolution is not deterministic
• There is not a well defined evolution
• Ticks may be lost
• Same data mey be used several times by the
  corrector

13
DESS approach

• Lots of effort in usability
• UML diagrams and notation are adapted to support
  formal notation of choice
• Dual approach
• The Operational Formalism is Synchronous, based
  on Finite State Machines with temporal
  constraints
• The Descriptive Formalism is based on a Temporal
  Logic, possibly fully integrated in OCL. The
  particular dialect has to be chosen yet

• Translation
• Formalism adopted should be translatable to
  current available model checkers and validators
• UML diagrams
• State diagrams are modified to support a formal
  Finite State Machine notation (lots of
  differences in semantic aspects)
• OCL modified to embed the concept of time
• Open issues
• Whether and how introduce the concept of
  connector
• Scalability of the approach

14
Car Speed Regulator
Object Diagram
15
CSR Clock
Clock State Diagram
16
CSR Filter
Filter State Diagram
17
CSR Calculator
Calculator State Diagram
18
CSR Enabler
Enabler State Diagram
19
CSR Speed Sensor
Speed Sensor State Diagram
20
CSR Enable On State
On Composite State State Diagram
21
CSR Conclusion

• All the constraints are static, they bounds
  static variables
• The time constraints are all implied by the
  system, they are embedded in the system itself.
  That is, all the time constraints are expressed
  in a direct operational way
• The model is verified by default (it is
  constructed to fulfill the constraints)

• The only property that must be verified is the
  possible existence of the system (non zenoness
  property)
• In this case there is no need to define a
  Temporal Logic to express more complex time
  properties of the system