Developing a Framework for Simulation, Verification and Testing of SDL Specifications

1. Developing a Framework for Simulation, Verification and Testing of SDL Specifications Olga Shumsky Lawrence Henschen Northwestern University [shumsky,henschen]@ece.nwu.edu

2. 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

3. 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

4. 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

5. Protocol Modeling in SDL: Part 1

6. Protocol Modeling in SDL: Part 2

7. 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

8. SDL Specifications equivalent specifications Translator Formally correct Specifications in Lisp-Based Format Correct simulation of original specification Activator valid instance, valid specification pair System Instance Process Simulator & Utilities correct instance simulation System Simulation SDL Specifications Simulator Architecture

9. 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))))))

10. 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)

11. 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

12. 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)))

13. 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

14. 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

15. 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

16. 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

17. Testing of implementations • Simulator can be used for testing:implemented units are substituted in place of simulations

18. 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

19. 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