Developing a Framework for Simulation, Verification and Testing of SDL Specifications Olga Shumsky Lawrence Henschen Northwestern University

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 Activator Translator Process Simulator & Utilities SDL Specifications Specifications in Lisp-Based Format System Instance System Simulation Formally correct valid instance, valid specification pair equivalent specifications correct instance simulation Correct simulation of original specification

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 Simulator functions defined for: signal input and output, assignment, updating state, decision, process creation, procedure call, timer operations, stop, and goto Correctness: simulating each action preserves wf-instance property actionstateMemoryqueue After instantiationstart(ackid. nil) (frameid. nil) (sender. nil)nil After initializationwaiting(ackid. -1) (frameid. nil) (sender. nil)nil Signal arrives in queuewaiting(ackid. -1) (frameid. nil) (sender. nil)Frame(0) Signal consumedwaiting(ackid. -1) (frameid. 0) (sender. 2)nil Transition completedwaiting(ackid. 0) (frameid. 0) (sender. 2)nil

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