Notes
Outline
Developing a Framework for Simulation, Verification and Testing of SDL Specifications
Olga Shumsky
Lawrence Henschen
Northwestern University
[shumsky,henschen]@ece.nwu.edu
Introduction
Formal verification is widely used in hardware verification
Errors found late in the production cycle are more expensive to correct in hardware than in software
In safety-critical software systems correctness requirements warrant formal verification
Emphasis on design processes that already employ formal methods
Specification and Description Language SDL
A formal description technique standardized in 1988 by International Telecommunication Union
Intended for description of communication protocols
Used on a variety of distributed, concurrent, communicating, asynchronous systems
Many support tools exists, but no framework for theorem-proving based verification
Main building blocks are processes represented by extended finite-state machines and delaying and instantaneous communication links
Example of Modeling with SDL:
a simple communication protocol
A sender and a receiver communicate
Buffer size is 1: each message must be acknowledged before next is sent
If acknowledgement does not arrive in a reasonable time, message is resent
The communication network may lose but not corrupt messages
Protocol Modeling in SDL: Part 1
Protocol Modeling in SDL: Part 2
Simulator vs. Specification Verification
We are building a verified simulator for SDL specifications – one-time effort
Design engineers can use the simulator  to verify SDL specifications – multiple verification efforts on multiple designs
ACL2 used in both cases
SDL Specifications Simulator Architecture
Process Translation
Superficial, stores entities as lists
Receiver process translated:
(receiver (1 . 1)
          (ackid frameid)
          (start (() (task ackid -1)
                     (label 1)
                     (output ack (ackid) () ())
                     (nextstate waiting)))
          (waiting ((frameid (frameid))
                    (decision ((= frameid (+ ackid 1))
                               (task ackid (+ ackid 1))
                               (join 1))
                              ((<> frameid (+ ack 1))
                               (join 1))))))
Communication Network
Translation
Paths consisting of several links are collapsed into multi-component single entities
Instantaneous paths:
(source destination route-name)
Delaying paths:
(source destination (member routes) queue)
Network from example:
(sender receiver (out1 link in2) nil)
(receiver sender (out2 link in1) nil)
Translator Correctness
Defined an inverse function untranslate, and prove that no information is lost w.r.t. to a specialized equivalence relation
(equal* (untranslate (translate S)) S)
Trivial for process translation
Tricky for network translation
Activator
SDL differentiates between process definition and process instance
Defined process activation mechanism
Receiver process instance
(1 receiverprocess start
  ((ackid . nil) (frameid . nil) (self . 1)
     (sender . nil) (parent . 0) (offspring . nil)
    ((start …)) nil)
Correctness property: defined a recognizer for valid instances of a system
(defthm activate-makes-instance
  (implies (wf-type S)
             (wf-instance (activate S) S)))
Process Simulator
Receiver Process Simulation
Concurrency Simulation
An oracle indicates to the top-level simulator function the id of the next instance to simulate
How fine-grained should a simulation be?
Transitions are considered atomic: the simulation might miss some possible real-life process interleaving scenarios
Actions are considered atomic: some actions, such as procedure calls, are more time consuming than simple actions, such as goto and nextstate
We are implementing mechanisms to handle both cases, so that appropriate process interleaving can be selected for each application
Network Handling
A signal traveling through an instantaneous path is immediately delivered to the destination
An oracle is supplied to delaying paths to determine whether the path forwards the signal
If there is an inconsistency in the address of the signal, a warning is generated, and the signal is discarded
SDL Specifications Verification
Once the simulator is proved correct, we can prove properties of specifications w.r.t. the simulator
Our protocol is correct if sender and receiver agree on the id of the last successfully transmitted frame
(defthm sender-receiver-agree-1
  (<= (variable-value 'ackid
  (instance 'receiver (simulate S O)))
      (variable-value 'frameid
               (instance 'sender (simulate S O)))))
(defthm sender-receiver-agree-2
(let ((v1 (variable-value
'ackid (instance 'receiver (simulate S O))))
         (v2 (variable-value
'frameid (instance 'sender (simulate S O)))))
    (implies (< v1 v2) (= (+ 1 v1) v2))))
Defined access functions to extract variables and instances
Testing of implementations
Simulator can be used for testing: implemented units are substituted in place of simulations
Related Work
Other approaches to verification of SDL specifications are based on model checkers.  A couple of examples
IF system from Verimag converts SDL to PROMELA and uses SPIN model checker
A proprietary verification system at Siemens relies on a BDD-based symbolic checker
Summary
We are developing a simulator for SDL specifications
We are using ACL2 for the development and verification of the simulator
The goal is to provide a framework for verification of SDL specifications using a theorem prover
The simulator also helps in testing of implementations: acts as a test driver and helps compute expected results for test cases