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

Download Report

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

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

system Protocol Sender link [Frame, Ack] Receiver block Sender SenderProcess link out1[Frame] in1[Ack] link block Receiver out2[Ack] ReceiverProcess link in2[Frame] link

Protocol Modeling in SDL: Part 2

process SenderProcess process ReceiverProcess Start dcl AckId,FrameId Integer; timer Timer; Start dcl AckId,FrameId Integer; FrameId = 0 AckId = -1 Frame(FrameId) Ack(AckId) set(timer) waiting sending Frame (FrameId) Ack(Ackid) timer AckId=FrameId (true) FrameId = FrameId + 1 (false) FrameId = AckId + 1 AckId+1=FrameId (true) (false) AckId =AckId + 1

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

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

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

protocol

in1

sender

out1 link in2

receiver

out2

SenderProcess

(out1 link in2) (out2 link in1)

ReceiverProcess SenderProcess ReceiverProcess

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 action After instantiation state start Memory (ackid . nil) (frameid . nil) (sender . nil) queue nil After initialization Transition completed waiting Signal arrives in queue waiting Signal consumed waiting waiting (ackid . -1) (frameid . nil) (sender . nil) (ackid . -1) (frameid . nil) (sender . nil) (ackid . -1) (frameid . 0) (sender . 2) (ackid . 0) (frameid . 0) (sender . 2) nil Frame(0) nil nil • 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

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: such as goto and nextstate some actions, such as procedure calls, are more time consuming than simple actions, • 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

system Protocol Sender link [Frame, Ack] Receiver block Sender SenderProcess link out1[Frame] in1[Ack] link block Receiver out2[Ack] ReceiverProcess link in2[Frame] link

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