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