Thesis

A Critical Study of Logical
Development in Mechanical
Reasoning Systems
Moin ul Deen
Department of Computer Science & Information Technology
University of Sargodha
A thesis submitted for the degree of

Masters in Computer Science
I dedicate this work to my beloved parents

for their great affection, encouragement and constant support,
which has always been a greatest source of inspiration
and the reason of what I am today.
Acknowledgements
I am most humbly grateful to Allah Almighty for His unbounded blessings upon me to acquire this thesis. Trembling lips and wet eyes for
Prophet Hazrat Muhammad (S.A.W), who is forever a torch of knowledge and guidance for the entire mankind. Foremost, I would like to
express my deepest gratitude to my supervisor Dr. Muhammad Ikram
Ullah, whose continous guidance, sage advice, patient encouragement,
insightful criticism and constant support helped me in all the time of
research and writing of this MS thesis. It is a great honor for me to
finish this work under his supervision. Besides my supervisor, I would
like to thank Prof. Dr. Anwar-ur-Rehman Pasha, Chairman Department of CS & IT, for his guidance and tremendous efforts in research.
I am also very thankful to many people who helped me during the
production of this thesis. Last but not the least, I would like to appreciate my family: espacially my father and mother for their day and
night endless support, prayers and encouragement throughout my life.
Moin Ul Deen
MSCSF14E028
Abstract
Mechanical reasoning is a key area of research on the crossroads of

mathematics, logic, and artificial intelligence particularly. Within the
domain of computer science and artificial intelligence, it gives highest
level of confidence in the correctness of safety-critical systems. These
computational tools are known as theorem provers, further divided
into automatic and interactive reasoners. Technically, mathematical
symbolism and diagrammatic notions lie at the core of mechanized
reasoning. Technically, mathematical formalism and diagrammatic
reasoning based approaches are employed to generate proof and to perform inference. Regarding logic, binary and fuzzy logical frameworks
are two well-known mathematical and logical frameworks underlying
the reasoning tools. However, there has been shortage of a comprehensive document, which provide proper guidance about preference
of theorem provers with respect to their design, performance, logical
framework, and their applications areas. This thesis proposes to review the historical development of theorem provers, classify theorem
provers and discuss some of their properties and limitations. Finally,
a theoretical model for a mechanical reasoning based on American
scientist-philosopher Charles Peirces Triadic logic will be discussed
and developed in relationship with binary and fuzzy.
Contents
1 Introduction
1.1
1.2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
1.1.2
Problem Statement . . . . . . . . . . . . . . . . . . . . . .
1.1.3
Research Questions . . . . . . . . . . . . . . . . . . . . . .
1.1.4
1.1.5
Research Objectives . . . . . . . . . . . . . . . . . . . . .
Research Methodology . . . . . . . . . . . . . . . . . . . .
3
3
Thesis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Literature Review
2.1
Survey of Existing Tools for Formal Verification . . . . . . . . . .
2.2
Automated Theorem Proving . . . . . . . . . . . . . . . . . . . .

2.2.1 A short survey of automated reasoning . . . . . . . . . . .
9
9
2.3
Interactive Theorem Proving . . . . . . . . . . . . . . . . . . . . .
2.3.1
A survey on Interactive Theorem Proving
. . . . . . . . .
2.3.2
Formalization of Real Analysis: A Survey of Proof Assistants and Libraries . . . . . . . . . . . . . . . . . . . . . .
10
2.3.3
The Seventeen Provers of the World . . . . . . . . . . . . .
11
2.3.4
Isabelle: The next 700 theorem provers . . . . . . . . . . .
12
2.3.5 A Survey of Interactive Theorem Proving . . . . . . . . . .

Model Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
2.4.1
Testing with model checkers: a survey . . . . . . . . . . .
13
2.4.2
Model-Based Development Using Simulink . . . . . . . . .
15
Diagrammatic Theorem Proving . . . . . . . . . . . . . . . . . . .

2.5.1 Mathematical Reasoning with Diagrams . . . . . . . . . .
16
16
2.4
2.5
iv
CONTENTS
2.5.2
Survey of Euler Diagram-based Notations . . . . . . . . .
17
3 Research Methodology
3.1 Objectives of The Research . . . . . . . . . . . . . . . . . . . . .
18
19
3.2
Levels of Research
. . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3
Classification of Research . . . . . . . . . . . . . . . . . . . . . . .
20
3.4
Approaches to Research Methodology . . . . . . . . . . . . . . . .

3.4.1 Research Design . . . . . . . . . . . . . . . . . . . . . . . .
20
21
3.4.2
Research Instrumentation . . . . . . . . . . . . . . . . . .
22
3.4.3
Promela Spin Specificaitoin Language . . . . . . . . . . . .
23
3.4.4
3.4.5
Spin Model Checker . . . . . . . . . . . . . . . . . . . . .

How SPIN Model Checker Works . . . . . . . . . . . . . .
24
26
3.4.5.1
Writing Specification In Promela . . . . . . . . .
26
3.4.5.2
Automata View Of Specified Model . . . . . . . .
27
3.4.5.3
3.4.5.4
Simulation Of Specified Model . . . . . . . . . .

Verification Of Model In Spin . . . . . . . . . . .
28
29
4 Formalization of Sliding Window Protocol
32
4.1
Communication Protocol
. . . . . . . . . . . . . . . . . . . . . .
33
4.2
Sliding Window Protocol Algorithm . . . . . . . . . . . . . . . . .
33
4.3
4.4
Properties of Communication System . . . . . . . . . . . . . . . .

Safety Properties . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
38
4.4.1
Absence of Deadlock . . . . . . . . . . . . . . . . . . . . .
38
4.4.1.1
Verificational Result Using On-The-Fly Verifier .
38
4.4.1.2 Verificational Result Using LTL Claim . . . . . .

Liveness Properties . . . . . . . . . . . . . . . . . . . . . . . . . .
40
41
4.5.1
Absence of Starvation . . . . . . . . . . . . . . . . . . . .
41
4.5.1.1
Verificational Results Using On-The-Fly Verifier .
42
4.5.1.2 Verificational Results Using LTL Claim . . . . . .

Measures of Complexity . . . . . . . . . . . . . . . . . . . . . . .
43
45
4.5
4.6
5 Conclusion and Future Direction
46
CONTENTS
6 Appendix A
6.1
6.2
48
Spin Model Checker . . . . . . . . . . . . . . . . . . . . . . . . . .

Spin Installation Manual . . . . . . . . . . . . . . . . . . . . . . .
7 Appendix B
7.1
48
48
52
Promela Specification for Goback-N SWP . . . . . . . . . . . . .
References
52
62
vi
List of Figures
3.1
GUI of Spin Model Checker . . . . . . . . . . . . . . . . . . . . .
25
3.2
Specification of Producer-Consumer Problem . . . . . . . . . . . .
27
3.3
Automata of Specified Model . . . . . . . . . . . . . . . . . . . .
28
3.4
3.5
Simulation View of Specified Model . . . . . . . . . . . . . . . . .

Verification Panel View of Spin . . . . . . . . . . . . . . . . . . .
29
30
6.1
6.2
SPIN Model Checker GUI . . . . . . . . . . . . . . . . . . . . . .

Automata View of Promela Model . . . . . . . . . . . . . . . . . .
50
51
vii
List of Tables
1.1
General Information about the System . . . . . . . . . . . . . . .
1.2
Category of the Automated Reasoning System . . . . . . . . . . .
1.3
General Programming Framework of the System . . . . . . . . . .
1.4
Internal Framework of the system . . . . . . . . . . . . . . . . . .
4.1
Complexity Measures of the Protocol . . . . . . . . . . . . . . . .
45
viii
Chapter 1
Introduction
In this chapter, an overview is presented on the underlying concepts related to
work done in this thesis. First, it briefly introduces the mechanical and automated
reasoning concepts related to formal method. then, background of thesis is presented. After this problem statement of this research work is stated. Research
objectives and questions of this study has been enlisted. Research methodology
for this work is discussed in the subsection of this chapter. in last structure of
thesis is described.
1.1 Introduction
1.1
Introduction
Capability to make implications is called reasoning, and automating this process

with the help of computational resources is known as automated reasoning. This
is similar to mechanical theorem proving. Mechanical reasoning is a key area
of research on the crossroads of mathematics, logic, and artificial intelligence
particularly. Technically, mathematical symbolism and diagrammatic notions
lie at the core of mechanized reasoning. Generally, it is helpful for a variety
of domain experts like Mathematicians, management consultants, hardware developers. Within the domain of computer science and artificial intelligence, it
gives highest level of confidence in the correctness of safety-critical systems. Primarily reasoning means deduction of a conclusion from given facts following a
set of logical rules/inference, and computational tools are the software tools or
mathematicians that perform the deductions. Inferencing is performed by two
methods, proving and model checking. In both approaches, Mathematical model
used Propositional logic, FOL (first order logic) and (HOL) higher order logic
for performing inferences. While, diagrammatic model used state charts, Euler diagram, Venn diagram, and petri-nets for performing inferences. Theorem
provers using computational resources are called automated theorem proving and
are divided into Automated Theorem Provers (ATP), Interactive theorem provers
(ITP), Diagrammatic Theorem Provers (DTP) and Model checkers. ATP deals
with the development of an automated computer program to show that a statement (conjecture) is a logical consequence of a set of statements (the axioms and
hypotheses).In contrast, ITP deals with the development of human-computer interaction i.e. computer work as a proof assistant. Model checkers are the formal
verification tools, capable of providing counterexamples to violated properties.
Normally, these counterexamples are meant to guide an analyst when searching
for the root cause of a property violation. Diagrams are commonly used in virtually all areas of representation and reasoning. In particular, they are invaluable
1.1 Introduction
in mathematics texts. They are used in a variety of ways, including to give examples showing why a theorem is true, to give counter-examples, or to explain
the structure of a proof. More rarely, diagrams can be used to prove a theorem
outright.
1.1.1
Background
1.1.2
Problem Statement
There has been less work done about theorem provers review, which provides a
proper guidance for new researcher in the area of formal method. Which help
them to analyze and use these tools according to their problem domain, and support them in their research about the development of new theorem provers. Comprehensive systematic literature review about formal reasoning tools is needed to
be surveyed.
1.1.3
Research Questions
Research questions for this study are as under: 1. Whether this study evaluate
all provers and specify any new dimension which is still uncovered? 2. Whether
this study provide historical background of all the provers and specify the state
of the art provers?
1.1.4
Research Objectives
Following research objectives will be met during this research; Systematic literature survey of formal reasoning tools will provide a comprehensive document,
which is very helpful for new researcher in the area of formal method. A platform
for evaluation and comparison of different reasoning techniques.
1.1.5
Research Methodology
This work will be exploratory by its nature and will be done in two-fold ways.
Initially, a systematic survey has been made following Kitchenhams approach
of systematic literature review as much close to Kitchenhams approach as this
1.2 Thesis Overview
Table 1.1: General Information about the System

General Information about the System
what is the name of author or contributors of the system?
What is the first appearance of the system w.r.t date or year?
what is the latest version of the system?
when was the system update last time?
what is the website address of the system?
Write the name of university/Industry behind the development of the system?
what is the license type of system?
What are the unique features of the system?
What is the application area or user community of the system?
What are the success stories of the system?
Table 1.2: Category of the Automated Reasoning System

Category of the Automated Reasoning System
what is the type of the system, either it is a Theorem Prover or Model Checker?
Either system is an Automated Theorem Prover or Interactive Theorem Prover?
What is the type of system with respect to reasoning (graphical or mathematical)?
What is the type of logic (classical or non-classical) of the system?
What is the type of system with respect to calculus (Deductive or inductive)?
Either set theoretic support or type theory support available in the system??
What is the programming paradigm (functional/imperative/others) of the system in which it is
survey can be developed. After slightly comprehensive survey work, number of
existing tools will be adopted for detail comparison and discussion. Here, in order
to substantiate our work, a questionnaire will be designed. In this regard, the
questionnaire will be forwarded to domain experts and research groups working
with a specific prover. Alongside, we will also gather data about tools by ourselves
that will be cross validated with the values taken from the questionnaire.
1.2
Thesis Overview
Chapter 1 gives an introduction to our work and Chapter 2 we have detailed literature review. In Chapter 3 general research methodology aspects are shown and
1.2 Thesis Overview
Table 1.3: General Programming Framework of the System

General Programming Framework of the System
What is the programming language in which system is developed?
What type of user interface (Command line or Graphical) available in the system?
Write the name of operating system that are supported by the system?
What is the architecture of the system (modular or monolithic)?
Either system support scalability feature?
Object oriented programming features available in the system or not?
Either system available as a standalone program or a distributed program?
Either system support code generation facility for the proof?
Table 1.4: Internal Framework of the system

Internal Framework of the system
Proof kernal is availble in the system or not?
Either system is extensible or programmable by the user?
Editor support is available in the system or not?
what is the evaluation of the system in the application domain?
Either system support scalability feature?
Object oriented programming features available in the system or not?
Either system avilable as a standalone program or a distributed program?
Either system support code generation facility for the proof?
1.2 Thesis Overview
our work is specified accordingly. Moreover, we present our formal specification

of sliding window protocol in Chapter 4. In Chapter 5 end with conclusion and
future directions.
Chapter 2
Literature Review
In this section, we presented existing work regarding Automated Theorem Proving (ATP), Proof Assistant, Diagrammatic Reasoning and Model Checking. in
this regard, only survey papers have been selection for literature review.
2.1
Survey of Existing Tools for Formal Verification
This paper survey formal reasoning tools ( open source and commercial). Author
highlight the limitation of testing and simulation techniques, abstraction level
of these reasoning tools, taxonomy of these formal method tools. After a brief
introduction, author provides a list of the tools used for: abstract model checking, hardware description languages checking, software correctness checking, and
provable correct design creation.
Testing and simulation bounded to running actual code for showing the output
of a digital system. Without running actual code, prediction of output results
and systems functional properties are difficult to verify. So, formal method is a
best solution for such situation. Formal method include a database of automated
mathematical techniques that help in the decision of proposition related to digital
system properties.
Author categories formal method tools into two broad categories Model checkers
and Theorem provers. Model checkers provide the understanding that what can
2.1 Survey of Existing Tools for Formal Verification
be done automatically while Theorem prover provides a way for human intervention and innovation. Author stated that model checkers demand less expertise as
compared to Theorem prover. Author mention a tool Rodin, which merge model
checker and theorem prover into one place.
Author discussed abstraction level of formal method tools. High level abstraction formal tools mostly used for validating system or proving their specification.
These are also used for race condition checking and deadlock properties of digital systems. On the other hand, low level abstraction tools utilized for Register
Transfer Logic (RTL) code and reachability properties of the systems.
Abstract model checking is the First Category of the formal tools discussed by
the author. Modeling language is the main entity of such tool, through which
an abstract model is created. These modeling languages are specific to tool, so
each tool has different modeling language. Properties of these languages are:
semantics (vital for formal verification) are well define , conciseness due to which
design detail is not elaborated, and unique features for verification process. Tools
which are listed in this category are: Spin, Uppaal, SMV, NuSMV, FDR, Alloy,
and Simulink Design Verifier. Under the first category, a subcategory (Actual
Design Description Verification tool) is also introduced. Software verification
tools enlisted in this category are Farma-C, BLAST, Java Pathfinder, Spark ADA,
Malpas. Tool for verification of Hardware Description Language (HDL) listed in
this subcategory are Questa Formal, Solidify, JasperGold and Incisive
Creation of probable correct design is the second category, in which a formal
platform and methodology is provided for modeling mathematically a system
and proving its properties. Tools under this category are Vienna Development
Method (VDM), Z, B, Event B and Rodin
Tools which come under the first category are model check. These are easier
to use and require less expertise. In model checkers, these is no independent way
to verify validity of a proof. While, tools discussed in the second category are
theorem prover. They require great expertise to use them and they are capable
for independently proving a proof term.
2.2 Automated Theorem Proving
2.2
Automated Theorem Proving
From the mid of 19th century, computers have been playing an important role
in mathematics and logic to prove theorem. Early work and later development
about theorem provers can be found in the survey [? ] R.Castelo, and R.mili [? ]
presented actual classification of theorem provers and evaluate TPs applications
on specific problems. ATP and ITP are subcategories of general purpose TP.
Author said that we build TP according to our problem domain, which could be
very efficient and effective in order to solve it.
2.2.1
A short survey of automated reasoning
Harrison, J. [? ] Compared Theorem provers and Computer Algebra System.

Harrison explained that both are Computers programs, and used for formal symbolic manipulation. He said that TP could be distinguished by few features such
as logical expressiveness, clear semantics, and logical rigor. Author highlighted
the significant problems of TPs, one of them is the proof search in logical system
to express high level mathematics. Harrison argue that we use features of both
approaches. Use CAS to compute results and then the results can be checked in
TP. Moreover, according to Harrison, the existing research can be categorized under automated reasoning AI verses Logic-oriented, automated verses interactive,
proof search verses special algorithm.
2.3
Interactive Theorem Proving
in this section we present survey paper related to proof assistant or interactive

theorem prover or tactic provers.
2.3.1
A survey on Interactive Theorem Proving
Asperti review the interactive theorem provers tools. Author highlighted the
main goals of ITP domain. First goal of ITP system is, reducing the cost of
formalization and improving the benefit. Second, invention of new ways of doing
mathematics with help of digital systems. third, computing system must have
2.3 Interactive Theorem Proving
database of contents related to mathematical expression and understand their representation. forth, in proof editing process user must focused on the innovative
selection of the proofs. Fifth, system must provide the facility of automatically
proof checking and building large databases of mathematical knowledge which are
trust-able. Author show the current achievement of ITP system. Some of these
achievements are: prime number theorem proof with Isabelle system, four color
theorem proof with Coq system, and Jordan curve theorem proof with HOL light.
Asperti also specify the major components of ITP systems. He classify the generation of interactive theorem provers. Author presented two generation of these
tools. First generation of ITP consist of procedural, declarative style provers
and tools having logical framework. While, second generation ITP consist on
types, types theory programs and Higher Order Logic programs. Type theory is
an alternative of set theory and it is strongly connected with constructive logic
Procedural style systems used backward reasoning. This style is compact and
unreadable. While, declarative style used forward reasoning. This style is more
verbose and readable. ITP Tools which are review by the author are: Automath,
HOL family ( HOL4, HOL88, HOL90, HOL lite and Proof Power), Isabelle/Isar,
NuPRL, Coq family ( Coq, Agda, Lego, Matita), PVS, IMPS, and Mizar. Logical Control Function (LCF), Mizar, and Automath are the tools belong to first
generation. LCF use procedural style for proving. Mizar adapt declarative style
for proving. Automath used logical framework( which support many logic) for
proof procedure. Second generation ITPs are: HOL family, Isabelle, Nuprl, Coq,
Lego, Agda, Matita, IMPS and PVS. Asperti described the logic, typed, and
implementation language of these systems.
2.3.2
Formalization of Real Analysis: A Survey of Proof

Assistants and Libraries
As title reveal, it is a review of the interactive theorem prover or proof assistant. This survey highlight the properties related to: arithmetic operators, real
number, limits, integrability, differentiability and many others for real time analysis. System which is selected by the author for formalization of these properties
are: Coq, HOL4, HOL Light, Isabelle/HOL, ProofPower-HOL, and PVS. On
10
the other hand, author also focus on libraries used by these system and account
them. Libraries which are mention in this paper are:C-CoRN/MathClasses used
for Coq, ACL2(r) used for ACL2, and NASA PVS library for PVS. Basically
representation of real numbers in the above mentioned systems and various other
properties are studied.
Author provide a brief introduction of the real number concept. After that author define his major goal of this study, that is a comparison of theses interactive
theorem provers and their libraries. This work provide a general overview about
the given systems to reader of this document. It also help a new user of these
system to choose proof assistant according to their problem domain. Author
selected those system which are decades old and having their standard libraries.
Author conclude this survey that some approaches best deal some properties
and there is no system which provide all of them at one place. This document
help to users in exchanging different proof and theorems in between these proof
assistant. Author also point out that most of the standard libraries are poorly
documented, which does not provide a clear understanding to user. Author also
provide information about the hundred famous theorems. He also provide a
reference to check these theorem and their formal proof available on Wiedijks
website. Author said that real analysis of ACL2 (r) is not mature or developed
as compared to other proof assistants. Non-availablity of (Higher order Logic)
HOL makes ACL2 (r) to explore functions. Proof assistant Mizar is based on
set theories while others systems are typed-based, so those all are more user
friendly as comapred to Mizar. Standard library of Coq for real numbers analysis
is outdated. Automation strength of: PVS, HOL light, HOL4, ProofPower-HOL
and Isabelle-HOL are similar.
2.3.3
The Seventeen Provers of the World
Freek compared working environment of different interactive theorem provers

or proof assistant in mathematics. He presented Pythagoras proof of the irrationality of 2 both formally and informally. Author mailed this theorem to
various interactive theorem provers communities. Freek listed the name of those
proof assistant, whom authors respond to his mail and provide solution of this
11
theorem in their proof assistant program. These interactive theorem provers

are HOL, Mizar, PVS, Coq, Otter/Ivy, Isabelle/Isar, Alfa/Agda, ACL2, PhoX,
IMPS, Metamath, Theorema, Lego, Nuprl, Omega, B method, Minlog. These all
tools prove this theorem formally. While, informally this theorem is also proved.
Henk Barendregt informally prove this this theorem. .
author design a consumer test for differentiating these proof assistant. This
test contained following question: either small proof kernel is availble in the system?, either calculation can be proved automatically?, either system is extensible
or programmable by the user? , either automation of the system is powerful?,
either readable proof input file facility is available in the system? Either system
supported constructive logic or not?, what is the logical framework of the system?
Either it is a typed system?, either system type is decidable?, either system type
is dependent?, either system is based on Higher order logic (HOL)?, either system
is based on ZFC set theory?, either system contained a large mathematical standard library?, either system provide statement about R?, either system provide
statement about ?.
author also design general question about these system, which are the following:
what is the website address of the system?, what are the documentation, tutorial,
publication or books?, which logic is used for developing the system?, how system
is implemented?, what is the working environment of the system?, what is the
unique feature of the system as compared to other system?, how many versions
of the system are available?, who is the author of the system or contributed to
the system development?, how many user communities available for the system?,
how much mathematics is formalized by the system or evaluation of the system?,
what is the representation of theorem solution?, what is required to elaborate
proof in more dettil?.
2.3.4
Isabelle: The next 700 theorem provers
Paulson, L. C. surveyed generic theorem prover Isabelle, which was design for
ITP. Author explained that how logics are represented and illustrated. Paulson
compared his purposed approach with the Edinburgh Logical Framework. Author mentioned that Isabelle is first based on elementary ideas which are now
12
2.4 Model Checkers
formally developed. The LF is a theoretical system for which implementations

are emerging. Main difference between Isabelle metalogic and ML, are proof
terms.
2.3.5
A Survey of Interactive Theorem Proving
Maric, F. A [5] presented an overview of interactive theorem proving. Author said

that Formal verification still needs support of back-end mathematical libraries,
proper channel for sharing knowledge among the systems, helpful ways of verification and incorporation of computation, best way to store and retrieve background
facts, and better GUI (graphical user interface) to users for describing mathematical objects. Maric said that, a large community of researchers is addressing all
these problems, and there are optimistic estimates that by the middle of the century, mechanically verified mathematics will be commonplace. Maric discuss the
history, logical foundations, main features of state-of-the-art ITP systems.
2.4
2.4.1
Model Checkers
Testing with model checkers: a survey
Fraser, G., Wotawa, F., Ammann, P. E. overview the achievements that have
been made for testing with model checkers. Testing remains the most important
method to verify the quality of software. Author said that Automation is necessary, because manual testing takes a lot of effort and is error prone. Fraser
explained that the model-based approach to software testing encompasses the
creation of an abstract model, which is used to automatically create test cases.
At the same time, the model tells us the expected outcome.
A survey of tools for model checking and model-based development
This paper overview model checking tools and model-based development tools.
Author presented SLAM and BLAST, both are software verification tools. These
tools integrate various concepts such as: Automated Theorem Proving (ATP),
program analysis, model checking and program abstraction. Reason behind this
integration is to completely utilization of strength of all these techniques. Large
13
2.4 Model Checkers
software product need a comprehensive testing to ensure its correctness. Testing

of software becomes difficult as software size increase. So, it needed an alternative
approach other than generally practiced approaches. Utilizing formal method approaches are the alternative techniques, which test the integration of such large
scale software efficiently. Automatically checking the properties of a software or
model checking have some trade-offs. These are soundness and completeness.
Analysis of the software is sound, if every true error is reported. procedure of the
software is complete, if every reported error is a true error. When some errors are
not reported, then analysis will not be sound. When false error reported , then
procedure is not complete. There is another example of such trade-offs which
is linked with analysis of complexity. Precise analysis needs more computation,
which in result compromised efficiency that is unacceptable. So, for efficiency
we compromised some degree of precision. Author presented predicate abstraction method for building conservative abstraction of software. In this method,
predicates are repeatedly added in the refinement process of abstraction until
original error trace is identified or given property is identified. So, predicate final
package improved repeatedly. Behavioral properties of system model are verified
with the help of model checker. Automation is the main benefit of this tool.
Tracing of error for each error path and computation of invariant are the main
advantages of these tools. Negative side of these tools are the scalability issue,
these are not scalable for large system. Another drawback is its individual model
of program, not the whole program. Implementation is started after the models
have been verified successflly. Automated theorem proving (ATP) is an area of
formal reasoning, which deals with construction of computer program for proving
mathematical theorems. Main advantages of such tool are: naturally handling
of unbounded domain, best implementation for specific problems. Some disadvantages of these tools are: invariants demand for performing analysis, human
interaction for proving a theorem prover, more expensive in the sense of computational complexity. Author stated the last technique in its research work is
Program Analysis. This technique predict statically the dynamic behavior of a
program at compile time. Positive side of this technique is its direct working on
code of the program. Author provided a comprehensive comparison among the
SLAM and BLAST tool. Static analysis is performed in both tools. Counter
14
2.4 Model Checkers
example guided abstraction refinement (CEGAR) for extraction of a finite state

model from program of C are similar in both these tools. Both tools are tested
on device drivers of operating system window. These both are comparable in
scalability and precision. Main difference among these tools is lazy abstraction
in BLAST, that permits discovery of predicate locally and on the demand which
save memory and time. BLAST specification language is easier to learn for new
users and for programmers. On the other hand, SLAM support recursive and
mutually recursive function while BLAST these functions.
Author also compared BLAST and SLAM with other model checker such as
SPIN and KRONOS. Traditional tools (SPIN and KRONOS) first build model
of a system and then actual implementation is performed, while in BLAST and
SLAM abstract model is extracted from existing code of a program and then it
is formally verified according model checking principles. Error tracing in SLAM
and BLAST are performed directly while it is not the case in SPIN and KRONOS. SPIN and KRONOS have a specification language to specify a model while
BLAST and SLAM use specification language to specify the properties which
needs to checked. BLAST and SLAM are used for sequential C programs while
SPIN and KRONOS used to verify real time system. SPIN and KRONOS demands a prior knowledge of formal languages and learn specification language for
specifying a model in tool. While, BLAST and SLAM does not demand such
things. Spin has been used in ring protocol and call processing application. Realtime systems have been verified with the help of KRONOS. BLAST extended to
verify multi threaded program but it could not achieve the level of KRONOS/.
2.4.2
Model-Based Development Using Simulink
in this work author review model-based development tools which are used both
in industry and academia. Author selected Simulink tool and discussed its application and limitation. According to author, Simulink is mostly used for feedback
and control systems in embedded devices. This tool can minimized the cost
and bugs of a system. Author said that teaching of Simulink to undergraduate classes is beneficial. it is a new paradigm in software development and it
ensure job placement for them because many leading companies investigate and
15
2.5 Diagrammatic Theorem Proving
use it. Author compared Simulink with other model-based development tool
such as SCR, SCADE (Safety Critical Application Development Environment),
UML2 and perfectDeveloper. Simulink is a cross platform tool while SCADE is
specific to Window operating system. Simulink is more powerful because it has
many data types built-in blocks and also have facility to define new one. While
SCADE have less data types. Simulink has been used for model generation while
SCADE used for proving model. So these both are used in conjunction for modelbased development. Both tools provide automated code generation facility. SCR
provides IDE (Integrated Development Environment) facility and simulation of
formal specification written in SCR notaions. It provide less modeling capability
as compared to Simulink. It does not model memory or continuous variables.
PerfectDeveloper provides a programming environment with OOP features and
ensure verification process using ATP (Automated Theorem Prover). It is similar
to SPARK Ada and it is a text-based tool. It does not provide simulation and
not allow for rapid prototyping as compared to SCADE and Simulink.
2.5
2.5.1
Diagrammatic Theorem Proving

Mathematical Reasoning with Diagrams
Mateja [? ] explore the history of diagrammatic systems, present diagrammatic

theorems and problems domain of diagrammatic reasoning. Author also discussed
constructive -Rule and schematic proofs for diagrammatic systems. Mateja also
provides procedure for designing a diagrammatic reasoning systems and also highlight diagrammatic reasoning operations. In the last author, presented a diagrammatic theorem prover DIAMOND. This book explain the ways through which we
prove mathematical reasoning with the help of diagrams. Mateja investigate this
domain and show that how we formalize and mechanize diagrammatic reasoning.
Winterstein, D.[? ] elaborate about diagram, its advantages over other approaches to provide reasoning, possibility of formalization of diagrammatic proof,
and selection of scheme to represent these proofs. Author overview state of the art
diagrammatic reasoning system and mention the problems and challenges which
they are facing.
16
2.5 Diagrammatic Theorem Proving
2.5.2
Survey of Euler Diagram-based Notations
John Howse [? ] review the notation which are used in Euler diagrams. He
also focus on the formalization and development of computer program support
for these notations. Author explained Venn diagram, Euler diagram, extension
of Venn diagram, Spider diagram, and Constraint diagram for theorem proving.
Rodgers [? ] surveyed theoretical results, generation techniques, transformation
methods and the development of automated reasoning system for Euler diagrams.
Rodgers also overview the applications areas and the ways in which Euler diagrams have been extended.
Stapleton, G.[? ] surveyed the reasoning systems that have evolved recently and
extend Euler diagrams. Author draw a comparison between these systems.
Kulpa, Z.[? ] discussed in detail the main problems encountered in reasoning
using diagrams. Yan, S. S., Zhao, N., Liao, S. Z.[? ] designed and developed a
reasoning system that combines diagrammatic and symbolic reasoning. Author
introduce a hybrid approach, which cover both areas.
17
Chapter 3
Research Methodology
In this chapter, we provide an overview and present the research methodology for
the current study. It details out the research approaches and a suitable methodology to achieve our goals, research design, also describes nature of our research
and adopted research methodology.
18
3.1 Objectives of The Research
The term research is structurly composition of two words re which means perform again and again search means look-up or find-out some fact [73]. Research
refers to as quest for learning[74]. Research is a way to promote knowledge and
effectively makes a person to relate himself with his environment in order to
achieve his purposes, and sorting out the conflicting key steps. It is the procedure of finding a dependable answer for a specific issue through the organized
and planned collection, investigation and interpretation of data. [73]. Consequently, the term research means to notice or perceive any fact time and again
from distinct perspectives. Research can also be described as a systematic and
scientific finding for relevant information on a particular topic in a specific field
of any discipline. Research is an inquiry and continuous thirst for searching facts
and cautious exploration of knowledge. Research is also culture, and this culture
is developing in field of computer science with various flavors, colours and trends.
Rusk, George J. Mouly, Francis G. Cornell, Clifford Woody of the University of
Michigan, C.C. Crawford, C. Francies Rummel,W.S. Monroe and R.M. Hutchins
have defined research with different definitions but these definitions share some
general characteristics [73].
3.1
Objectives of The Research
There are three fundamental objectives of research describe by the Singh, which
are theoretical objevtives, factual objectives and application objectives. Theoretical objective is to formulates new theories, laws or principles theoreticaly.
These type of researches are explanatory in nature as these explains the relationship among different variables. Researches in different disciplines like Chemistry,
Physics, Mathematics etc have theoretical objectives [73]. Factual objective is
to find out new facts factualy. These objectives of research are descriptive in
nature. These researches report or describe events or facts which have been happened in past era. These types of research is done in the discipline of history
[73]. Appication objective is to suggests new applications inspect of contributing
new knowledge in the collection of human knowledge. Application means the
19
3.2 Levels of Research
modification and improvement in the way of use or implementation a particular

practice [73].
3.2
Levels of Research
In practice, research is carried out on different levels and for different objectives.
The level of research is depend on the objectives the person intends to complete.
Generally there are two levels of research such as basic level and applied level [73].
Basic level is defined as basic research by Trevers. Basic level is intended to add
an oganized body of scientific knowledge, it does not process results of immediate
practical value [73]. Applied research is managed to solve instantly an immediate
practical problem and the objective of attaching the scientific knowledge is less
important. A common thinking is to assume that, the basic level researh is
much complex as compared to applied level. But this thinking is not true, as for
particular case the applied level researches are more complex and the basic level
of researches are simple for the same case [73].
3.3
Classification of Research
Research can be classify by using different ways . On the basis of the objectives of
the research, it can be classified in to two types: fundamental research and action
research. Our research is fundamental in nature. On the basis of research approaches, there are two types: cross-sectional research and longitudinal research.
On the basis of accuracy in the research findings, there are two types of research:
which are non-experimental and experimental. Experimental research is precise
in nature while the non-experimental is not a precise research. In this case, our
research is experimental. With respect to the nature of the findings researches are
fouund to be of two types: Explanatory Research and Descriptive Research. Explanatory research explains more concerned theories regading a particular field.
Descriptive research are more concerned with the facts [73].
20
3.4 Approaches to Research Methodology
3.4
Approaches to Research Methodology
Researcher broadly follows two approaches in the discipline of research methodology, which are qualitative approach and qualitative approach. Qualitative approach to research deals with subjective evaluation of opinions, behaviors and
attitudes. Research by using qualitative approach is a function of researchers
perceptions and impressions. The results generated by the qualitative reseach
are either in non-quantitative form or these are in the form which are not subjected to rigorous quantitative analysis. The groups interviewed, depth interviews
and projective techniques are being used in qualitative research. Data collection
quantitative research is done quantitatively in which rigorous quantitative analysis, can be easily completed in a formal and rigid style. Quantitative research
methods may be experimental, inferential and simulation-based. The inferential
method use questions and observations to collect the characteristics and properties of data or population. The experimental method provides a research environment which has a greater control over some variable changes another variable.
The simulation method is based on the construction of a virtual environment.
This approach allow us to observe the behavior of a particular system or its subsystems, we have modeled. Simulation is useful for model building approach. It is
a system and mechanisms to understand future conditions [73; 74]. The nature of
our research is quantitative. We have developed the mathematical model, which
represents our sliding window protocol, and will be use to prove the correctness
of the protocol specification.
3.4.1
Research Design
In the field of Computer Science the methodologies should be formalized. The

technique of formalization is commonly used to prove the facts about the system
or of an algorithm. One may be intrested to formalize the specification of the
softwares systems for the sake of automatic verfication of the implementation of
that softwares system. In the other hand some researchers may be intrested on
space or time complexity of an algotitm or they may be intrested on the quality
or correctness of the algorithms generated solution. The nature of our research
is quantitative. We have followed the simulation approach for this research [73].
21
A formal model of the system differs from the implementation in two essential
ways. Firstly, the model means an abstraction of a design of the system which
contains only those aspects of the system design having direct relevancy to the
properties to whome one is interested to prove. Secondly, the formal model just
contains things those are not the part of an systems implementation, such as
worst case assumptions about the systems behavior and the environment that
may interact with the system and the formal statement of correctness properties
[75]. We have developed a model which represents our protocol system. We have
used this model to prove the correctness of the specification. For our research, we
are focued on the GoBN sliding window protocol. We have start with the simpler
specification of the protocol and step by step move forwarded to the GoBN sliding
window protocol. We have chosen the SPIN Model Checker to formally check
and verify the protocol specification. Main avtivities involves in our research are
writing the specification in Promela language for the GoBack N sliding window
protocol and proving the correctness of the properties of these specification using
Spin model checker. For specification of Goback-N SW Protocol in Promela, see
Appendix in chapter: 7.
We will perform the following steps to meet our goals .
Writing the specification of basic GoBN sliding window protocol model in
Promela SPIN specifications language.
Defining the correctness properties of the GoBN sliding window protocol in
the temporal logic.
Finally these properties witten in the temporal logic will be verified using
Spin Model Checker.
3.4.2
Research Instrumentation
The field of theoratical computer sciecne has been widely studied and commonly
used in developmental theories of the softwares. In the development of various
computing domain systems the formal methods have been commonly used [76].
As discussed in the Section ??, there are two general formal verification techniques: Model Checking and Theorem Proving [24]. The technique of theorem
22
proving in the formal methods are used to verify the system and its properties. In
theorem proving properties are written in the form of formulas. These formulas
are written in propositional logic, first order logic or higher order logic based on
the specifications or the system needs. Theorem prover is used for the mechanical verification of hardware or software designs properties. Theorem proving
is suitable for very large or infinite space systems: software and hardware system [22]. Theorem proving can handle complex systems formalization. However,
theorem proving approach has various disadvantages too. As compared to the
model checking it is not automatic. Writing theorem is so much complicated,
time-consuming process and need technical knowledege for the formulation of the
system. The technique of model checking in the formal methods is a powerful,
automatic and fast for relatively finite state systems. As sometimes it produces
the required results in few minutes by exploring all the possible state of the system and checking either the correctness specification of the systems holds in each
state or not. The exploration and checking of the states is done mechanically
using a software tool in a brute-force manner [25]. Automatic verification is not
about just proving the correctness of the system, but about finding bugs or erros
much earlier in the development stage of the system before its implementation.
Model checking is done exhaustivly in state space of the system. It predicts design
defects and potential to minimize costs related to re-work and risks of failures
in critical systems. Usually, modeling all the properties of system design is not
much hard and if the system model has finite state space model checking ensure
the termination of the system.
3.4.3
Promela Spin Specificaitoin Language
Promela is short of Process Meta Language or Protocol Meta Language [18].

Promela is not programming language but it is a modeling language used to
modeled the concurrent system like multi-threaded system, synchronization and
message passing system and for the data structures with finite and fixed bound
systems. Promela language has a commands and expression syntax like C. Each
formal model can be verified by considering different types of assumptions regading the system and its correctness properties. If the property for the system is
23
not valid under a particular assumption, the verifier produces a counter example, which describes how a particular property may be violated. If the property
is valid under a particular assumption, it may be possible to more simplify the
system model based on that fact, and able to prove still the other properties of
the system. There are three sort of objects: process, message channel, variables
in Promela language. All the objects are global in Promela model. A Promela
model must contains at-least one process. Since the model checker, Spin is used
to prove the correctness of the concurrent systems and the model for the concurrent systems typically has more than one processes. Variables and Message
channels are two other objects used in Promela model. The scope of these object
either global or local. The globally declared object could be reffered to by all the
processes and locally declared object could be only reffered by a single process by
whom the object has declared and instantiated. As Usually it is necessary that
all objects must be declared before they are referenced [18] .
3.4.4
Spin Model Checker
A model checker is designed to verify that model satisfies the specification of a

system. An open source model checker Spin (Simple Promela Interpreter) is a
verification system for designing and verification of distributed and asynchronous
process system like communication protocols. Spin model checker is used to
prove the correctness properties of the communication processes. The intended
goal of the any model checker and all other testing and validation techniques are
to demonstrate with confidence that a proposed nodel, design or implementation
is per the requirements of the system. Some flaws those accurs commonly in
the design of the distributed and asynchronous systems are deadlock, livelock,
starvation, Underspecification, overspecification etc. Spin model checker accepts
the design specificaitoins those are written in a verification language Promela (a
Process Meta Language or Program Meta Language). Spin provides C-like notation (in Promela Language) for the specificaitoin of the finite state abstraction
of the system unambiguously. It accepts the correctness claims written in linear
temporal logic. The linear temporal logic(LTL) accepts certain valid claims in
the formula syntax. The Spin works in two basic ways: simulation and as a
24
verification. Simulation is used to get a quick impression of system behavior [49].

GUI of Spin Model Checker is shown in figure 3.1. The default extension for the
Promela Code File is .pml.
Figure 3.1: GUI of Spin Model Checker

Edit/View panel in figure 3.1 allows us to Open or Save any Promela verification
models. The default extension of the Promela model is .pml. In the black log
window resides in the bottom of this panel, Redundancy Check, Syntax Check,
and Symbol Table produces the corresponding output in the black log window at
the bottom of the panel. Find permits us to locate any search string from the
Promela model text. The Automata View button is used to populates the name
of the Processes in the blue canvas and generates the control flow graph for the
model It does so by first generating and compiling the model checkign code, if
there are suntax errors these will prevent compilation and warned about these
25
errors. Simulation/Replay panel in figure 3.1 has all relevant options for guided or
random simulation of the model, error trails produced in verification are used to
guide the execution. Run button is used to start the simulation run. Stop button
is used to stop it and the Rewind button is used to completely run from the
start. Symbol table button is used to view the each identifier and its associated
information regarding appearance and declaration in the Promeal code. Bottom
black window in 3.1 shows the output and the symbol table consist of variables,
processes, chan etc. Verification panel in figure 3.1 contains many helpfull options.
From this panel we first choose the type of verification and also the types of the
error-trails we want to see. After this we have to choose the storage mode , all
options other than exhaustive are helpfull to reduce the memory. Run button is
used to generate and compile the model, after this execute it, if no error occur
during the compilation. We can interrupt within a long running verification
using a Stop button. Help button is used to get more detailed information on
methods for reducing the complexity of the verification. Swarm panel in figure
3.1 allows us to configure a Swarm verification run, which is more effective for
the large and complex model of system. For using this option we must have
installed swarm preprocessor in our system, than we would be able to specify the
maximum runtime and number of the CPU cores to used for Swarm verification.
3.4.5
How SPIN Model Checker Works
Following steps are followed in Spin for verification of the specification of any
systems model.
3.4.5.1
Writing Specification In Promela
We have started with a Promela specificaitoin in SPIN model checker. For example specificaitoin of the Producer-Consumer problem is given in figure 3.2 and in
figure 3.1 at left-side white window. The producer-consumer problem also known
as bounded-buffer problem is a typical example of process synchronization problem. In this problem, there are two processes known as producer and consumer,
those shares a common, fixed sized buffer used as queue. Producer job is to create a data item and put items into the buffer and consumer job is take out or
26
consume items from the buffer. The main problem is to ensure that the producer
may not be able to add data items in to full buffer and the consumer may not
be able to remove or take out items from a empty buffer. The specification is
appeared in iSpin graphical-user-interface of SPIN model checker.
Figure 3.2: Specification of Producer-Consumer Problem
3.4.5.2
Automata View Of Specified Model
The main text-window shown in figure 3.1 offers some necessary edit and search
facilities. We can perform the action of syntax check and check for redundancies by pressing the corresponding buttons up-side of text window. Right-side
blue window in 3.1 shows the automata of the specified model by pressing the
Automata View button exist in right-side mid panel as shown in figure 3.3. It
populates the names of the proctypes(processes) and never claims. It generates
transition diagram regarding each process of the model by clicking on the process name and connectivity between the states of the transition diagram. Thats
why it is said as an automaton. It does so by first compiling the specified model
27
Promela code, if there exist any syntax error it prevent the compilation process
of the model.
Figure 3.3: Automata of Specified Model
3.4.5.3
Simulation Of Specified Model
Whenever we click on the button of Simulate/Replay in the Tool-bar shown in

figure 3.1 opens a Simulation panel. The Simulation panel provides all relevant
option for simulation of the model. To gain more insight into the progressive
behavior of the specified model, we can run either guided or random simulation.
Random Simulation is a good technique for the initial examination of the behavior
of the Promela model by observing its execution. SPIN model checker compiles
and executes a model written in Promela and compile-time errors and output for
28
the specified model appears in the right pane as shown in figure 3.4. Bottom leftpane as shown in figure 3.4 shows all variables values according to the respective
step in the simulation. Bottom middle-pane as shown in figure 3.4 shows all the
execution path. In simulation run there is an option to limit the number of steps
for exwcution, especially it is very important when we are modeling a concurrent
programs that needs not to terminate.
Figure 3.4: Simulation View of Specified Model
3.4.5.4
Verification Of Model In Spin
The most powerful functionality in Spin model checker is in-fact to performs

verification. It cab be selected by clicking verification tab in the tool-bar and
it can be seen in figure 3.5. Verification is essential whenever we deals with
concurrent programs. Verification is quite likely to find the counterexamples for
the specified model. Given a model specified in Promela language as input, Spin
29
performs verification of system by exploring its state space. Here in verification

panel we have multiple option for the verification of the model.
Figure 3.5: Verification Panel View of Spin

The most common way to express the properties of defined system in the Spin
through never-claims. The so called never-claims are used to express the arbitrary
regular properties. Spin model checker provides an automata Linear Temporal
Logic (LTL) formula translator to never claims. It is a good practice if we go
through the option available in the verification panel from left to right, by keeping
the default values. Firsty, choosing the type of verfication (Safety or Liveness)
is to be done. Secondly, the Storage mode and never claims is to be selected.
Thirdly, decision is to be made for specific Search Mode. Thus, like the liveness
properties: properties of potential-reception, and protect the development cycle
and messages.Fourthly, indicating what type of error trails we want to capture.
Once we have selected the desired options, by clicking the Run button generates and compiles the specific model and will execute it, if no errors prevent
compilation. In this way, both the liveness properties like: eventual-reception of
30
messages, non-progressive-cycles, and safety properties like: deadlock-avoidance,

invalid-end-states, unspecified-message-receptions and assertions can be checked.
If the system violates any property, it reports an invalid action or cycle. The
erroneous traced action can be replayed by a guided simulation. Spin has severial
techniques to cope with the state space explosion problem like: partial-orderreduction, state-vector-compression and bit-state-hasing.
31
Chapter 4
Formalization of Sliding Window
Protocol
The main goal of our work is to illustrate that how a well known protocol such
as sliding window protocol can be treated using a model checker Spin. We have
described the modeling and specificational aspects of sliding window protocol using Spin model checker. For installarion of Spin Model Checker see Appendix A
in Section[6.2].
32
4.1 Communication Protocol
4.1
Communication Protocol
Before writing the Algorithm of Sliding Window Protocol Algorithm, and SPIN
specification for the Sliding Window Protocol in Promela language, First we
have to define a protocol, and whats are the basic requirement of the protocol for
communcicational systems. Whenever any communication device or computer is
going to communicate with one an other, in advance they must have knowledge
about the formate of the information and the way in which it will be delivered.
Communication should be governed by standardized methods. These methods
are called communication protocol and all the communicating entities must agree
upon on these protocol [1] as dicussed in the Section ?? at Page # ??.
These communication protocols: specify syntax, semantic, communicational organization and also define particular mechanism for recovery. Automatic Reapeat
Request(ARQ) or Sliding-Window-Protocol is used in communcicational system
to control errors as for reliable communication, It use some errors detecting code
combined with retransmission satrategy. On the basic of retransmission mechanism are three schemes of sliding window protocol(SWP) as Stop-and-Wait,
GoBack-N, Selective-Repeat [6],[3]. as discussed in the Section ?? at Page # ??.
4.2
Sliding Window Protocol Algorithm
Algorithm for any system is any well-described computational procedure, which

takes input in the form of some value, or set of values for computation and produces results in the term of some values, or set of values. Thus an algorithm is
a set of some sequential and computational steps to transform a given input into
output as desired in [77].
In this study we have develop an algorithm [1] for specification of goback-n
sliding window protocol. The goback-n swp gurantees successful trasmission of
data/messsages from the source to destination by using noisy channel, inwhich
data may get lost due to noise. The goback-n sliding window protocol ensures
that the sender send data to the receiving entity and does not wait for any acknowledgement from the receiver for maximum use of the channel bandwidth. It
keeps the image of the sent data untill the arival of the acknowledgement from
33
4.2 Sliding Window Protocol Algorithm
the receiving entity [1] as discussed in the Section ?? on Page # ??.

In goback-n algorithm [1], we have a process PASR (line 3), which is one communication entity in our goback-n algorithm. In goback-n swp algorithm each
communicating entity can send and receive data to or from the other communicating entity. To achieve full-duplex data transmission the Process PASR has
two pair of channels pasrpktOut and pasrpktIn (line 2) to communicate with other
communicating process. It uses one cahnnel for simplex data transmission in different directions. Process PASR in algorithm [1] use the cahnnel pasrpktOut to
send data to other communicating entity. And it use the channel pasrpktIn to
receive data from other communicating entity.
The Process PASR has three major states, data sending stata (line 14), data
receiving state (line 21) and timeout checking state (line 34). There are some
local variables like LastPacketSent (line 4) , LastPacketReceived (line 9), AckExpected (line 5) , NextPacketExpected (line 6), PacketDataReceived (line 8),
PacketDataSent line 7), TempBuffer (line 10), s (line 11), i (line 12) and an
array of DataBackUp (line 13) of SRWinSize size for storing the sent data.
The prerequisite to send data from a process PASR to other communicating entity is that the TempBuffer must has within process PASR sending window size
SRWinSize (line 14). Whenever the TempBuffer is within the sending window
size, the process PASR step-forward the TempBuffer (line 15). It generates a
randomdata through RandomNumberGenerator function (line 16). The process
PASR sends the sequence number of data being send LastPacketSent, the data
PacketDataSent and other related information to the other process or communicating entity by using channel of pasrpktOut (line 17). After sending the data,
the process PASR stores the sent data PacketDataSent in a list of DataBackUp
(line 18) at the corresponding addresses. The process PASR can use the list
DataBackUp to retransmit the relevant data to other process or communicating
entity whenever there is need of retransmission. The process PASR send data at
it channel pasrpktOut as long as the value of TempBuffer is within the PASRs
window size.
In goback-n algorithm [1] process PASR use the channel pasrpktIn (line 21) for
receiving data from the other communicating entity/process as the process PASR
34
Algorithm 1: Algorithm for goback-n Process PASR

SRW inSize 3
Channel pasrpktIn, pasrpktOut
Process-PASR()
LastP acketSent 0
AckExpected 0
N extP acketExpected 0
P acketDataSent 0
P acketDataReceived 0
LastP acketReceived 0
T emp Buf f er 0
s0
i0
DataBackU p[SRW inSize] 0
while (T emp Buf f er < W indowSize) do
T emp Buf f er T emp Buf f er + 1
P acketDataSent RandomN umberGenerator()
ChannelpasrpktOut LastP acketSent, P acketDataSent, (N extP acketExpected + SRW inSize)
%(SRW inSize + 1)
18
DataBackU p[LastP acketSent%SRW inSize] = P acketDataSent
19
LastP acketSent LastP acketSent + 1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
20 end
21 while (ChannelpasrpktIn LastP acketReceived, P acketDataReceived, s) do
22
if (LastP acketReceived N extP acketExpected) then
23
N extP acketExpected N extP acketExpected + 1
24
else
25
Skip
26
end
27
if ((LastP acketSent < AckExpected)AN D(LastP acketSent > s))OR((LastP acketSent <
AckExpected)AN D(AckExpected <= s))OR((AckExpected <= s)AN D(s < LastP acketSent))
then
28
T emp Buf f er T emp Buf f er 1
29
AckExpected AckExpected + 1
30
31
32
else
Break
end
33 end
34 while (T ransmissionT imeOut) do
35
LastP acketSent AckExpected
36
i1
37
while (i <= T emp Buf f er) do
38
ChannelpasrpktOut
LastP acketSent, DataBackU p[LastP acketSent%SRW inSize], (N extP acketExpected +
SRW inSize)%(SRW inSize + 1)
39
LastP acketSent LastP acketSent + 1
40
ii+1
41
end
42 end
35
has a functionality of full duplex transmission. Process PASR will also be triggered whenever a data arrives. After verifying the correctness of the data the
process PASR takes actions according to sequence number of arrived data. It
compares the sequence number of its expected data NextPacketExpected with
arrived datas sequence number LastPacketSent (line 22) of the other communicating entity/process, which has sent the data. It verifies the sequence number
of arrived data to the sequence number of the expected data, other-wise ignores
it. After this the PASR verifies some information and make sure that the correct data are received (line 27) and the proper acknowledgement has sent, If the
information verified, then it decrement the TempBuffer (line 28) and increment
the AckExpected (line 29) so that it can make room for the sender to send more
data to the other communicating process. The size of window for receiving data
is always 1. The process PASR is always looking for the arrival of a specific data.
Any data arriving out of order is discarded and there is a need to resent the data
by the sender.
In goback-n algorithm [1], the transmission times may get out during propagation or nothing else is happening, it provides an escape from a hang state of
the system. There is a checkpoint for checking time out (line 34). In goback-n
protocol there is the functionality of sending all the data of the sender window
N again to the other communicating process, whenever the sent data couldnt
arrived in order or its not a correct data as required. Whenever the transmission
time got out, it assigned the value of AckExpected to LastPacketSent (line 35)
as AckExpected is the sequence number of data received correctly up till now by
the receiver. It sends all the data according to their sequence number by using
the transmission channel pasrpktOut and by using the DataBackUp list (line 38)
where the backup of the sent data has saved. It increases the temp pointer i and
sent all the data whenever the pointer in smaller than or equal to the TempBuffer.
So, all the required data will be again sent to the other communicating process.
Promela specification for the goback-n sliding window algorithm protocol is given
in Chapter :[7]
36
4.3 Properties of Communication System
4.3
Properties of Communication System
Whenever we want to justify that a particular concurrent does what we reveal

it should do, Lamport [78], Bowen [79] and Holzmann [49] founded that there
are usually two types of properties for concurrent system. These properties are
safety and liveness. Safety and liveness properties are very important properties
for concurrent systems like communcication protocols. Safety property states
that nothing wrong will happens in execution of a program [79]. It ensures that
system will never enter into an undesireable state [78]. Liveness property state
that something good will happen in due course [79]. Its ensures that in the end of
program, It will enter in an valid state [78]. There are some basic safety properties
which are: deadlock freedom, unspecified reception and unreachable code [49].
Lamport state that there are some familiar properties like: partial correctness,
mutual exclusion and absence of deadlock which are safety properties. Properties
like absence of livelock, starvation and existence of cyclically recurring states are
the liveness properties [78]. Generally there are two sort of correctness claims.
Safety claims about valid and invalid states of the system. Liveness claims about
feasible and unfeasible execution of the system. These both correctness properties
for any distributed system like communcication protocol can be defined within
or outside the specified model. For the formal verification of distributed system,
properties like safety and liveness has an importance. These two properties have
been studies extensively. These properties could not be violated. It means that
the bad things should be avoided [25]. SPIN generally accepts the correctness
properties written in LTL syntax. LTL formula is used to write both the safety
and liveness properties. In LTL formula, properties of any system are globally
specified with the following syntax:
ltl [name] {formula}
Linear Temporal Logic (LTL) formula f of the type []f is called the formula
for the safety property and Linear Temporal Logic (LTL) formula f of the type
<>f is called the formula for the liveness property. LTL formulas can be express
within or outside the specified model written in Promela specification language.
37
4.4 Safety Properties
4.4
Safety Properties
It states that bad thing never happen during the execution of the program. These
are the properties of the system those may not be violated. It can be check by
inpecting a finite behavior. When we use Promela specification language as a
varification language, we must ensure very specific assertions about the behavior
of the system being modeled. If the Promela language is being used to check
absence of deadlocks, the SPIN verifier must be able to differentiat between a
valid/normal endstate from invalid/abnormal end. A valid/normal state could
be a state in Promela process that instantiated and reached properly to the end
of the definid program body and all the message channel are empty. Generically
all the properties related to the system reachable states are known as safety
properties and endstate mark the local control state that is valid termination
point for that process instantiations.
4.4.1
Absence of Deadlock
In Promela language all the processes are executed to examine whether all the
processes reaches to their valid end-state. By default, endstates are those valid
states at which the Promela process reached at the end of its code. Deadlock occurs at a state where there is nothing further to happen, means that in exhaustive
state space of system there is not any outgoing edges or no successors. This state
is called as endstate. In system model the endstate is a state where blocking of
the proces is acceptable mean it is normal. Valid endstate is useful for checking
the absence of deadlock. In a deadlock condition some processes reaches at their
endstate but atleast one process has not reached at valid endstate.
4.4.1.1
Verificational Result Using On-The-Fly Verifier
SPIN model checker checks deadlock automatically and has a capability of searching state space of specified model either using depth first search or breadth first
search. If the system being model never reaches at a state where there no more
action is possible then it would be statisfied that it is deadlock free. it is property related to safety. First we have verified our Promela model for GobackN
38
sliding window protocol using on-the-fly verification pan of SPIN model checker.
We have added (line 23 & 73) an endstate label with prefix end to the model
that is used to mention a valid endstate. After that we have selected the safety
property option of invalid endstate (deadlock) from the verification pan as shown
in the results and run the SPIN verifier. It shows the verificational results of
the specifies model as under. There is not any error and not trace any invalid
endstate. If it has invalid endstate, the Goback-N SWP is the victim of deadlock,
mean there is the presence of deadlock. The verificational results also shows that
non of the both processes terminates their execution, means there are some unreached endstates. It does not have a problem as in communcication system the
protocol should keep on communication. As results shows that there is not such
a trace leading to bad thing, it satisfied that the GobackN SWP is deadlock free
communcication protocol.
spin -a GoBN06022016.pml
Pid: 3089
(Spin Version 6.4.4 -- 1 November 2015)
+ Partial Order Reduction
Bit statespace search for:
never claim
- (not selected)
assertion violations - (disabled by -A flag)
cycle checks
- (disabled by -DSAFETY)
invalid end states +
State-vector 84 byte, depth reached 9999, errors: 0
370023 states, stored
187856 states, matched
557879 transitions (= stored+matched)
0 atomic steps
hash factor: 2.83381 (best if > 100.)
bits set per state: 3 (-k3)
Stats on memory usage (in Megabytes):
36.700 equivalent memory usage for states (stored*(State-vector + overhead))
0.125 memory used for hash array (-w20)
0.076 memory used for bit stack
0.534 memory used for DFS stack (-m10000)
1.201 other (proc and chan stacks)
2.026 total actual memory usage
39
unreached in proctype PASR

GoBN06022016Deadlock.pml:55, state 41, "-end-"
(1 of 41 states)
unreached in proctype PBSR
GoBN06022016Deadlock.pml:104, state 41, "-end-"
(1 of 41 states)
pan: elapsed time 0.28 seconds
No errors found -- did you verify all claims?
4.4.1.2
Verificational Result Using LTL Claim
To prove the property of absence of deadlock using linear temporal logic (LTL),
we have added (line 107) LTL formula as it is suggested a suitable formalism for
the specification and verification of the cocurrent system. In our model there
are two communication processes. The correctness requirements for verifying the
absence of deadlock in linear temporal lofic (LTL) formula is:
ltl deadlock{[]!(PASR@invalidend && PBSR@invalidend)}.
The linear temporal logic (LTL) formula deadlock is expressed as to ensure
that both processes could not reached at their invalid endstates. We have selected
invalid endstate (deadlock) under safety pan, check the use claim option and
write the name of claim as deadlock. When we have run the verifier, it shows
the verificational results of the specifies model as under. The verifier has not
trace any error leading to bad thing. The results shows that non ot the both
processes of the GobackN sliding window protocol terminates their execution and
did not reached to an invalid endstate state leading to deadlock. LTL formula
ltl deadlock{[]!(PASR@invalidend && PBSR@invalidend)} and on the fly verifier
of the SPIN model checker ensures that there is not any presence of deadlock in
the GobackN sliding window protocol, mean its a deadlock free communication
protocol.
ltl deadlock: [] (! (((PASR@invalidend)) && ((PBSR@invalidend))))
Pid: 3935
+ Partial Order Reduction
40
4.5 Liveness Properties

never claim
+ (deadlock)
cycle checks
- (disabled by -DSAFETY)
invalid end states - (disabled by never claim)
0 atomic steps
43.456
0.125
0.076
0.534
1.538
equivalent memory usage for states (stored*(State-vector + overhead))

memory used for hash array (-w20)
memory used for bit stack
memory used for DFS stack (-m10000)
total actual memory usage

4.5
Liveness Properties
All the properties related to the sequences of states are known as liveness properties. These are the properties of the system those must be satisfied. Liveness
properties ensures that something good eventually happen and system will enter
in a desirable state during execution of the program [79][78].
4.5.1
Absence of Starvation
Starvation or livelock are the liveness properties of any distributed system. Starvation or Livelock occurs when all the process instantiated in a system are doing
useless computation. In Promela we tries to find non progressive cycle. It is
basically an infinite loop, where process execution takes place but progress is not
achieved. In this situation all the parties involved in communcication system
41
keeps on exchanging control signals, but actual data transformation could not
took place.It has a necessity to clarify what is progress. It could be done by
marking a state where effective progress may take place during execution with
progress lable. This state could be a state of incrementing sequence number or
where a valid data is being accepted by the receiver.
4.5.1.1
Verificational Results Using On-The-Fly Verifier
We have verify our Promela model for GobackN SWP for absence of livelock
or absence of starvation. We have used Spin on-the-fly verification. Spin has
special mode for proving the absence of starvation or absence of livelock (non
progress cycle), which are basically due to a non progressive cycle. For checking
and Verification of the properties of absence of non progress cycle, we have added
(line 30 & 80) an progress state label with prefix progress to the model that is
used to mention a valid progress-state where actual progress is being carried out.
After that we have select non progress cycle option from liveness verification
pan. If the verifier found an error and shows that there is a non progress cycle,
then GobackN sliding window protocol is the victim of starvation or livelock
otherwise. If it could not found any non progressive cycle , then it is not the
victim of starvation or livelock. When we have run the Spin verifier, it shows the
verificational results of specified model for absence of starvation as under. The
verifier could not inspect an error in the complete state space for GobackN model,
and trace that there is not any non progress cycle. It mean that the GobackN
sliding window protocol is not the victim of starvation or livelock .
spin -a GoBN29022016Safety.pml
Pid: 4935
never claim
+ (:np_:)
non-progress cycles + (fairness enabled)
invalid end states - (disabled by -E flag)
301388 states, stored (455885 visited)
42
979654 transitions (= visited+matched)

0 atomic steps
39.090
0.125
0.076
0.534
1.636

unreached in proctype PASR

GoBN29022016Safety.pml:66, state 42, "-end-"
(1 of 42 states)
unreached in proctype PBSR
GoBN29022016Safety.pml:124, state 42, "-end-"
(1 of 42 states)
4.5.1.2
Verificational Results Using LTL Claim
To prove the property of absence of starvation using linear temporal logic (LTL),
we have added (line 110) LTL formula in our model as it is suggested as a suitable
formalism for verifcation of concurrent systems like communcication protocol.
The correctness requirements for the verification of the absence of starvation in
linear temporal logic (LTL) formula is:
ltl nonprog{<>[](PASR@progress&&PBSR@progress)}
The linear temporal logic (LTL) formula nonprog is expressed within the specified model to ensure that both communcication process could not inspect or trace
any non progressive cycle, where there the actual communication progress could
not happen. For verification, we have selected non progress cycle from the liveness verification pan, check the use claim option and write the name of calim for
absence of starvation as nonprog. When we have run the Spin verifier, it shows
the verificational results of the specifies model as under. The Spin verifier could
43
not inspect any error in the complete state space for GobackN model, and trace
that there is not any non progressive cycle in both the communicating processes.
It mean that the GobackN sliding window protocol is not the victim of starvation. LTL formula ltl nonprog{<>[] (PASR@progress && PBSR@progress)} and
on the fly verifier of the SPIN model checker ensures that there is not the presence
of starvation in the GobackN sliding window protocol, mean its a starvation free
communication protocol.
ltl deadlock: [] (! (((PASR@invalidend)) && ((PBSR@invalidend))))
ltl nonprog: <> ([] (((PASR@progress)) && ((PBSR@progress))))
the model contains 2 never claims: nonprog, deadlock
only one claim is used in a verification run
choose which one with ./pan -a -N name (defaults to -N deadlock)
or use e.g.: spin -search -ltl deadlock GoBN29022016.pml
Pid: 3786
pan: ltl formula nonprog
never claim
+ (nonprog)
non-progress cycles + (fairness enabled)
invalid end states - (disabled by -E flag)
0 atomic steps
67.006
0.125
0.076
0.534
1.538

44
4.6 Measures of Complexity
4.6
Measures of Complexity
To get a glimpse of the complexity of Goback-N SWP model, the measures of

complexity with repect to time and space. We first perform an exhaustive verification using ispin interface of SPIN to verify some basic correctness properties of
Goback-N SWP, such as deadlock freedom, invalid endstate, unreachable code,
etc. The model is run with default verifier options by enabling some reduction
and compression strategy, we can measure the state space size of the SPIN verifier build to complete the verificatoin. The results after varying the range of the
window size from 2 to 5 are as shown in Table 4.1. Exhaustive verification of Spin
is used to ensure either the specified models behavior is error free or not. From
Table 4.1 it is clear that with increase in the number of window size, the total
number of reachable states, the required memory and the time required by SPIN
for the proof also increases. It shows that the computational cost is linear to the
number of reachable states both in time and space. We have performed the verificartion run on system Core i3 with RAM of 2GB. This GobackN model can be
verified for more than window size on a system with higher memory. The coding
for the sliding window protocol is done in using Promela specification language
and the iSpin version 6.4.4 graphical environment has been used for the purpose
of simulation and verification of the behavior of the modeled system. During the
process of the SPIN simulation, execution and verification, it verifies the specified
systems desired properties.
Table 4.1: Complexity Measures of the Protocol
Window Size
No of States
Memory(Mb) Time Elasped (Sec)
2
3
4
5
375222
538696
542324
569122
1.831
2.026
2.097
2.124
45
0.18
0.28
0.29
0.3
Chapter 5
Conclusion and Future Direction
Now a days our dependency on computer related technologies is increasing. Bug
in any computer system may have a disastrious results. Error in fire or flood
alarming system, radar system may cause the lives of human beings in danger.
The old error reduction, dectection and prevention technical tools are not sufficient. However, formal mehtods techniques provides desired level of safety, as
FMs make it possible to attain reliability and correctness during different phase
of system design and implementation.
Formal methods are mathematical software engineering techniques those are
used in all the phases like specification, analysis, design as well as testing of the
system. The implementation of these methods in specification and verification
is so much costly, thats why its not feasible to check in detail, all the desired
requirements of the computer system. Identification of crucial componnent leads
to reduction of testing cost. Moreover, by studying these partial components in
detail, the mathematical model of components can be made and verified [80].
The need of communication protocols in current era has increased. There day
to day development often leads to premature and rapid development. They have
not often scaled to satisfy, their important properties like absence of starvation
and deadlock. Sliding window is a well known technique used by the Transmission Control Protocol (TCP) to control the flow of data between the computers or
network nodes, which made the reliability of sliding window protocol more important. Spin model checker is a widely used model checking tool for specification,
simulation and verification of the communication protocols. It is mostly used for
46
analysis and formal verification of concurrent systems. Starting from the work
done by Smith [5] and Holzmann [18], we have formally specified the goback-n
sliding window protocol in the specification language Promela and its correctness
properties in Linear Temporal Logic (LTL). After that we have formally verified the correctness properties like absence of deadlock and absence of starvation
with the help of Spin model checker, which in turn verified the correctness of our
specification of protocol.
Generally model checking requires extensive technical experties, but SPIN model
checker is an automated model checking tool. It provides number of built-in features like simulation, automation, compression and verification. SPIN gets stuck
during verification, whenever something goes wrong and provides the complete
state of simulation run. This technique is help during verification of computer
system. In future, one direction would be the formalization and verification of
selective repeat request sliding window protocol and other concurrent programs.
47
Chapter 6
Appendix A
6.1
Spin Model Checker
The model checker SPIN can be runs on Linux, Windows, Solaris, and Unix machines. Spin software is distributed in source form, which encourage the research
in the filed of formal verification. SPIN has required some pakages, which are not
by default in Linux repositories, so we have to use some command to add some
new packages in our system.
6.2
Spin Installation Manual
For installing the SPIN on Linux system by using the Termial Window we have
to use the follow the following steps and commands:
For installing any new application, we should update packages in our system. For updating the packages in operating system Linux type the following command in terminal window :
sudo apt-get update
Use following command to include the necessary packages in our operating
system Linux:
sudo apt-get install texlive-full
48
6.2 Spin Installation Manual
To compile the SPIN from its sources on a system, we have a need to Install
the a copy of yacc compiler, graphviz, pan. Installing the all of these use
the following command:
sudo apt-get install byacc
Download the latest full distribution of SPIN source code from:
http://spinroot.com/spin/src/index.html
Put the downloaded SPIN source code on the desired directory as Desktop.
Type the following command in terminal window to change the directory,
where downloaded source code has placed:
cd Desktop
Unpack and compile SPIN latest source code full distribution spin645.tar.gz
by typing the following command:
gunzip spin645.tar.gz
tar -xf spin645.tar
cd Spin
cd Src6.4.5
make
It will be compiled. If it compiled properly without errors, then copy the executable of SPIN in to the our system path. Type the following command
to do this:
sudo cp spin /usr/bin/
We can use the version command to check the correctness of the SPIN
installation, use the following command to check the installation. If the
version appear, then its means that the SPIN installs properly:
spin -V
49
There are many graphical interfaces of model checker Spin, those are used
to verify the system. One graphical user interface is ispin. It is simple and
efficient GUI for verification of systems. For installing the ispin GUI, first
select the ispin directory from our system by using following command:
cd ../ispin
After selecting ispin directory type the following command to install ispin:
sh install.sh
Now the SPIN and its GUI ispin has been successfully installed.
To execute the SPIN model checker through terminal window write the
following command:
ispin
After running the above command the ispin GUI of SPIN will appear as:
Figure 6.1: SPIN Model Checker GUI
50
To view the automata/transition graph for a particular model in SPIN,

there must be availability of dot tool. Dot tool is from the graphiz distribution. For installing the dot tool we will write the following command in
the terminal window of Linux system:
sudo apt-get install graphviz
sudo apt-get install pan
When we have installed the dot tool using above command, we can view
the automata or transition graph of each proctype of Promela model in
Automata View panel as:
Figure 6.2: Automata View of Promela Model
51
Chapter 7
Appendix B
7.1
Promela Specification for Goback-N SWP
/*------------------|PROMELA SPECIFICATION FOR GOBACK-N SWP|-----------------*/

/*---------------|GLOBAL VARIABLES & FUNCTIONS FOR PROCESS PASR|-------------*/
1 #define SRWinSize 5 /*window size*/
2 #define inc(x) x=(x+1)%(SRWinSize+1) /*function for incrementing*/
3 #define dec(x) x=(x-1) /*function for decrementing*/
4
/*--------------------------|CHANNELS FOR PROCESS PASR|-----------------------*/
5 chan SRC[2] = [SRWinSize] of {byte,byte,byte}
6
/*----------------------------|START OF PROCESS PASR|-------------------------*/
7 active proctype PASR() /*start of process*/
8 {
/*----------------------|LOCAL VARIABLES FOR PROCESS PASR|--------------------*/
9 byte lps;
/*seq no of last data sent*/
10 byte ackexp; /*acknowledge expected*/
11 byte pktexp; /*seq no of expected data*/
12 byte pktdatarec; /*data received*/
13 byte lpr; /*seq of last data received*/
14 byte buffer; /*temporary buffer*/
15 byte s;
16 byte i;
17 byte dataBkup[SRWinSize];
/*Array for the Backup of data*/
18 byte randdatanbr; /*variable for random data*/
19 chan pktIn, pktOut; /*object of channel SRC*/
20 pktIn = SRC[_pid]; /*channel for receiving data*/
21 pktOut = SRC[1-_pid]; /*cahnnel for transmitting data*/
22
/*------------------------|SENDING PART OF PROCESS PASR|----------------------*/
23
24
25
26
27
28
end: do
:: buffer < SRWinSize -> /*checking buffer pointer value*/
inc(buffer); /*incrementing the buffer value*/
randdatanbr = randdatanbr+(buffer*SRWinSize)%255;
pktOut ! lps, randdatanbr, (pktexp + SRWinSize) % (SRWinSize+1); /*sending data through channel pktOut*/
dataBkup[lps%SRWinSize] = randdatanbr; /*backup the stored data*/
52
7.1 Promela Specification for Goback-N SWP
29 inc(lps); /*incrementing seq no of last data sent*/

/*-----------------------|RECEIVING PART OF PROCESS PASR|----------------------*/
30
31
32
33
34
35
36
37
38
39
40
41
42
progress: :: pktIn ? lpr, pktdatarec, s -> /*checking of arriveness of data*/

if
:: assert(lpr == pktexp) -> /*comparing seq nos*/
printf("Receive Data Number: %d\n", lpr);
inc(pktexp) /*incrementing seq no of data expected*/
:: else -> skip
fi;
do
:: ((ackexp <= s) && (s < lps)) || ((ackexp <= s) && (lps < ackexp)) || ((s < lps) && (lps < ackexp)) ->
acceptdec: dec(buffer); /*decrementing buffer pointer value*/
inc(ackexp) /*incrementing acknowledge expected*/
:: else -> break
od
/*-------------------|TIMEOUT,RESENDING PART OF PROCESS PASR|-------------------*/

43
44
45
46
47
48
49
50
51
52
53
54
55
56
:: timeout -> /*guard for checking timeout*/

lps = ackexp;
printf("Transmission Timeout\n"); /*printing transmission timeout*/
i =1;
do
:: i <= buffer ->
pktOut ! lps, dataBkup[lps%SRWinSize], (pktexp+SRWinSize) % (SRWinSize+1); /*resending the data again*/
acceptsinc: inc(lps); /*incrementing seq no of last data sent*/
i++; /*incrementing*/
:: else -> break
od
od
invalidend: /*label for LTL claim to trace invalid endstate */
}
/*----------------------------|END OF PROCESS PASR|-----------------------------*/

/*---------------------------|START OF PROCESS PASR|----------------------------*/
57 active
58 {
proctype PBSR() /*start of process*/
/*----------------------|LOCAL VARIABLES FOR PROCESS PBSR|----------------------*/

59 byte lps;
/*seq no of last data sent*/
60 byte ackexp; /*acknowledge expected*/
61 byte pktexp; /*seq no of expected data*/
62 byte pktdatarec; /*data received*/
63 byte lpr; /*seq of last data received*/
64 byte buffer; /*temporary buffer*/
65 byte s;
66 byte i;
67 byte dataBkup[SRWinSize];
/*Array for the Backup of data*/
68 byte randdatanbr; /*variable for random data*/
69 chan pktIn, pktOut; /*object of channel SRC*/
70 pktIn = SRC[_pid]; /*channel for receiving data*/
71 pktOut = SRC[1-_pid]; /*cahnnel for transmitting data*/
72
/*------------------------|SENDING PART OF PROCESS PBSR|------------------------*/
73 end: do
74 :: buffer < SRWinSize -> /*checking buffer pointer value*/
53
7.1 Promela Specification for Goback-N SWP
75
76
77
78
79
inc(buffer); /*incrementing the buffer value*/

randdatanbr = randdatanbr+(buffer*SRWinSize)%255;
pktOut ! lps, randdatanbr, (pktexp + SRWinSize) % (SRWinSize+1); /*sending data through channel pktOut*/
dataBkup[lps%SRWinSize] = randdatanbr; /*backup the stored data*/
inc(lps); /*incrementing seq no of last data sent*/
/*-----------------------|RECEIVING PART OF PROCESS PBSR|----------------------*/

80
81
82
83
84
85
86
87
88
89
90
91
92
progress: :: pktIn ? lpr, pktdatarec, s -> /*checking of arriveness of data*/

if
:: assert(lpr == pktexp) -> /*comparing seq nos*/
printf("Receive Data Number: %d\n", lpr);
inc(pktexp) /*incrementing seq no of data expected*/
:: else -> skip
fi;
do
:: ((ackexp <= s) && (s < lps)) || ((ackexp <= s) && (lps < ackexp)) || ((s < lps) && (lps < ackexp)) ->
acceptdec: dec(buffer); /*decrementing buffer pointer value*/
inc(ackexp) /*incrementing acknowledge expected*/
:: else -> break
od
/*-------------------|TIMEOUT,RESENDING PART OF PROCESS PASR|-------------------*/

93 :: timeout -> /*guard for checking timeout*/
94 lps = ackexp;
95 printf("Transmission Timeout\n"); /*printing transmission timeout*/
96 i =1;
97 do
98 :: i <= buffer ->
99 pktOut ! lps, dataBkup[lps%SRWinSize], (pktexp+SRWinSize) % (SRWinSize+1); /*resending the data again*/
100 acceptsinc: inc(lps); /*incrementing seq no of last data sent*/
101 i++; /*incrementing*/
102 :: else -> break
103 od
104 od
105 invalidend: /*label for LTL claim to trace invalid endstate */
106 }
/*----------------------------|END OF PROCESS PASR|-----------------------------*/
/*------------ -------|START OF LTL FORMULA SPECIFICATION|----------------------*/
/*---------------------|START OF LTL FORMULA FOR DEADLOCK|----------------------*/
107 ltl deadlock{
108 [] ! (PASR@invalidend && PBSR@invalidend)
109 }
/*----------------------|END OF LTL FORMULA FOR DEADLOCK|-----------------------*/
/*--------------------|START OF LTL FORMULA FOR STARVATION|---------------------*/
110 ltl nonprog{
111 <>[] (PASR@progress && PBSR@progress)
112 }
/*---------------------|END OF LTL FORMULA FOR STARVATION|----------------------*/
/*----------------------|END OF LTL FORMULA SPECIFICATION|----------------------*/
/*--------------------|END OF PROMELA CODE FOR GOBACK-N SWP|--------------------*/
54
Bibliography
[1] A. B. Forouzan, Data Communications & Networking (sie). Tata McGrawHill Education, 2006.
[2] K. K. Bansal and R. K. Yadav, Analysis of sliding window protocol for
connected node, International Journal of Soft Computing and Engineering
(IJSCE), 2012.
[3] S. Lin, D. J. Costello, and M. J. Miller, Automatic-repeat-request errorcontrol schemes, IEEE Communications Magazine, pp. 517, 1985.
[4] W. Stallings, Data and computer communications. Pearson/Prentice Hall,
2007.
[5] M. A. Smith and N. Klarlund, Verification of a sliding window protocol using
IOA and MONA. Springer, 2000.
[6] D. Hercog, The importance of sliding window protocol generalisation in a
communication protocols course, in International Conference on Engineering Education ICEE, Gliwice, pp. 1822, 2010.
[7] L. Sterling and E. Shapiro, The Art of Prolog. Wiley Online Library, 1988.
[8] S. Reeves and M. Clarke, Logic for computer science. Citeseer, 1990.
[9] K. Rosen, Discrete Mathematics and Its Applications 7th edition. McGrawHill Science, 2011.
[10] J. B. Almeida, M. J. Frade, J. S. Pinto, and S. M. de Sousa, An overview of
formal methods tools and techniques, in Rigorous Software Development,
pp. 1255, Springer, 2011.
55
BIBLIOGRAPHY
[11] B. Russell and A. N. Whitehead, Principia mathematica vol.1, 1925.

[12] J. Van Benthem and K. Doets, Higher-order logic, in Handbook of Philosophical Logic, pp. 189243, Springer, 2001.
[13] T. Kleymann, Hoare logic and auxiliary variables, Formal Aspects of Computing, vol. 11, no. 5, pp. 541566, 1999.
[14] M. C. Browne, E. M. Clarke, and O. Gr
umberg, Characterizing finite kripke
structures in propositional temporal logic, Theoretical Computer Science,
vol. 59, no. 1, pp. 115131, 1988.
[15] E. M. Clarke and E. A. Emerson, Design and synthesis of synchronization
skeletons using branching time temporal logic. Springer, 1982.
[16] G. De Giacomo and M. Y. Vardi, Linear temporal logic and linear dynamic
logic on finite traces, in Proceedings of the Twenty-Third international joint
conference on Artificial Intelligence, pp. 854860, AAAI Press, 2013.
[17] D. M. Gabbay and J. Robinson, Handbook of Logic in Artificial Intelligence
and Logic Programming: Volume 5: Logic Programming. Oxford University
Press, 1998.
[18] G. J. Holzmann, The SPIN model checker: Primer and reference manual,
vol. 1003. Addison-Wesley Reading, 2004.
[19] J.-P. Queille and J. Sifakis, Specification and verification of concurrent systems in cesar, in International Symposium on Programming, pp. 337351,
Springer, 1982.
[20] L. Lensink, Applying formal methods in software development. 2013.
[21] S. Wolff, Scrum goes formal: Agile methods for safety-critical systems, in
Proceedings of the First International Workshop on Formal Methods in Software Engineering: Rigorous and Agile Approaches, pp. 2329, IEEE Press,
2012.
56
BIBLIOGRAPHY
[22] E. M. Clarke and J. M. Wing, Formal methods: State of the art and future
directions, ACM Computing Surveys (CSUR), vol. 28, no. 4, pp. 626643,
1996.
[23] J.-P. Katoen, Concepts, algorithms, and tools for model checking. IMMD
Erlangen, 1999.
[24] F. Sheldon, G. Xie, O. Pilskalns, and Z. Zhou, A review of some rigorous
software design and analysis tools, Software Focus, vol. 2, no. 4, pp. 140
150, 2001.
[25] C. Baier, J.-P. Katoen, et al., Principles of model checking, vol. 26202649.
MIT press Cambridge, 2008.
[26] D. Dams, R. Gerth, S. Leue, and M. Massinek, Theoretical and Practical Aspects of SPIN Model Checking: 5th and 6th International SPIN Workshops,
Trento, Italy, July 5, 1999, Toulouse, France, September 21 and 24, 1999,
Proceedings. Springer, 2003.
[27] S. Owre, N. Shankar, and J. Rushby, User guide for the pvs specification
and verification system (beta release), Computer Science Laboratory, SRI
International, Menlo Park, CA, 1993.
[28] G. Huet, G. Kahn, and C. Paulin-Mohring, The coq proof assistant a tutorial, Rapport Technique, vol. 178, 1997.
[29] M. J. Gordon, HOL: A proof generating system for higher-order logic.
Springer, 1988.
[30] M. Ben-Ari, Principles of the Spin model checker. Springer Science & Business Media, 2008.
[31] I. Sommerville, Software Engineering: Seventh Edition. Pearson Education,
2004.
[32] W. H. Hesselink, Mechanical verification of lamports bakery algorithm,
Science of Computer Programming, vol. 78, no. 9, pp. 16221638, 2013.
57
BIBLIOGRAPHY
[33] F. Qin, J. Tucek, J. Sundaresan, and Y. Zhou, Rx: treating bugs as

allergiesa safe method to survive software failures, in ACM SIGOPS Operating Systems Review, vol. 39, pp. 235248, ACM, 2005.
[34] L. J. May, Major causes of software project failures, CrossTalk: The Journal of Defense Software Engineering, vol. 11, no. 6, pp. 912, 1998.
[35] G. L. Lann, An analysis of the ariane 5 flight 501 failure-a system engineering perspective, in Engineering of Computer-Based Systems, 1997. Proceedings., International Conference and Workshop on, pp. 339346, IEEE,
1997.
[36] D. R. Wallace and D. R. Kuhn, Failure modes in medical device software:
an analysis of 15 years of recall data, International Journal of Reliability,
Quality and Safety Engineering, vol. 8, no. 04, pp. 351371, 2001.
[37] A. S. Tanenbaum, Computer networks, 4-th edition, ed: Prentice Hall,
2003.
[38] G. Tarry, Le probleme des labyrinthes, in Nouvelles Annales de Mathematiques, vol. 14, pp. 187190, Gauthier-Villars, 1895.
[39] J. C. Knight, C. L. DeJong, M. S. Gibble, and L. G. Nakano, Why are
formal methods not used more widely?, in Fourth NASA formal methods
workshop, Citeseer, 1997.
[40] A. Felty and D. Miller, Specifying theorem provers in a higher-order logic
programming language, in 9th International Conference on Automated Deduction, pp. 6180, Springer, 1988.
[41] C. L. Heitmeyer, M. M. Archer, E. I. Leonard, and J. D. McLean, Applying
formal methods to a certifiably secure software system, Software Engineering, IEEE Transactions on, vol. 34, no. 1, pp. 8298, 2008.
[42] W. K. Lam, Hardware Design Verification: Simulation and Formal MethodBased Approaches (Prentice Hall Modern Semiconductor Design Series).
Prentice Hall PTR, 2005.
58
BIBLIOGRAPHY
[43] J. Woodcock, P. G. Larsen, J. Bicarregui, and J. Fitzgerald, Formal methods: Practice and experience, ACM Computing Surveys (CSUR), vol. 41,
no. 4, p. 19, 2009.
[44] P. E. Ammann, P. E. Black, and W. Majurski, Using model checking to
generate tests from specifications, in Formal Engineering Methods, 1998.
Proceedings. Second International Conference on, pp. 4654, IEEE, 1998.
[45] E. Borger, High level system design and analysis using abstract state machines, in Applied Formal MethodsFM-Trends 98, pp. 143, Springer, 1999.
[46] J. P. Bowen and M. G. Hinchey, Ten commandments of formal methods...
ten years later, Computer, vol. 39, no. 1, pp. 4048, 2006.
[47] M. Kaufmann, J. S. Moore, and P. Manolios, Computer-aided reasoning: an
approach. Kluwer Academic Publishers, 2000.
[48] B. Potter, D. Till, and J. Sinclair, An introduction to formal specification
and Z. Prentice Hall PTR, 1996.
[49] G. J. Holzmann, The model checker spin, IEEE Transactions on software
engineering, no. 5, pp. 279295, 1997.
[50] S. Owre and N. Shankar, The pvs prelude library, Computer Science Laboratory, SRI International, pp. 131, 2003.
[51] I. Sommerville and P. Sawyer, Requirements engineering: a good practice
guide. John Wiley & Sons, Inc., 1997.
[52] S. A. Seshia, Sciduction: Combining induction, deduction, and structure
for verification and synthesis, in Design Automation Conference (DAC),
2012 49th ACM/EDAC/IEEE, pp. 356365, IEEE, 2012.
[53] Y. Zhao, Z.-y. Yang, J. Xie, and Q. Liu, Formal model and analysis of
sliding window protocol based on nusmv, Journal of Computers, vol. 4,
no. 6, pp. 519526, 2009.
59
BIBLIOGRAPHY
[54] D. Chkliaev and V. Nepomniaschy, Deductive verification of the sliding

window protocol, Automatic Control and Computer Sciences, vol. 47, no. 7,
pp. 420426, 2013.
[55] J. Rushby, Harnessing disruptive innovation in formal verification, in Software Engineering and Formal Methods, 2006. SEFM 2006. Fourth IEEE International Conference on, pp. 2130, IEEE, 2006.
[56] R. A. Groenveld, Verification of a sliding window protocol by means of process
algebra. University of Amsterdam, Programming Research Group, 1987.
[57] J. van Wamel, A study of a one bit sliding window protocol in ACP. University of Amsterdam, 1992.
[58] F. W. Vaandrager, Verification of two communication protocols by means
of process algebra, NASA STI/Recon Technical Report N, vol. 87, p. 11064,
1986.
[59] M. Bezem and J. F. Groote, A correctness proof of a one-bit sliding window
protocol in crl, The Computer Journal, vol. 37, no. 4, pp. 289307, 1994.
[60] E. Madelaine and D. Vergamini, Specification and verification of a sliding
window protocol in lotos., in FORTE, vol. 91, pp. 495510, 1991.
[61] J.-L. Richier, C. Rodriguez, J. Sifakis, and J. Voiron, Verification in xesar
of the sliding window protocol, in Proceedings of the IFIP WG6. 1 Seventh
International Conference on Protocol Specification, Testing and Verification
VII, pp. 235248, North-Holland Publishing Co., 1987.
[62] R. Kaivola, Using compositional preorders in the verification of sliding window protocol, in Computer Aided Verification, pp. 4859, Springer, 1997.
[63] A. Sinha, R. Ajay, and S. Singh, Modeling & verification of sliding window
protocol with data loss and intruder detection using nusmv, 2012.
[64] P. Godefroid and D. E. Long, Symbolic protocol verification with queue
bdds, Formal Methods in System Design, vol. 14, no. 3, pp. 257271, 1999.
60
BIBLIOGRAPHY
[65] K. Stahl, K. Baukus, Y. Lakhnech, and M. Stefen, Divide, abstract, and

model-check, in Theoretical and Practical Aspects of SPIN Model Checking,
pp. 5776, Springer, 1999.
[66] T. Latvala, Model checking LTL properties of high-level Petri nets with fairness constraints. Springer, 2001.
[67] B. Jonsson and M. Nilsson, Transitive closures of regular relations for verifying infinite-state systems, in Tools and Algorithms for the Construction
and Analysis of Systems, pp. 220235, Springer, 2000.
[68] D. Chkliaev, J. Hooman, and E. De Vink, Verification and improvement of
the sliding window protocol, in Tools and Algorithms for the Construction
and Analysis of Systems, pp. 113127, Springer, 2003.
[69] R. Cardell-Oliver, Using higher order logic for modelling real-time protocols, in TAPSOFT91, pp. 259282, Springer, 1991.
[70] C. Rockl and J. Esparza, Proof-checking protocols using bisimulations, in
CONCUR99 Concurrency Theory, pp. 525540, Springer, 1999.
[71] V. Rusu, Verifying a sliding-window protocol using pvs, in Formal Techniques for Networked and Distributed Systems, pp. 251268, Springer, 2002.
[72] B. Badban, W. Fokkink, J. F. Groote, J. Pang, and J. van de Pol, Verification of a sliding window protocol in crl and pvs, Formal Aspects of
Computing, vol. 17, no. 3, pp. 342388, 2005.
[73] Y. K. Singh, Fundamental of research methodology and statistics. New Age
International, 2006.
[74] C. R. Kothari, Research methodology: methods and techniques. New Age
International, 2004.
[75] G. J. Holzmann and M. H. Smith, Software model checking, in Formal methods for protocol Engineering and distributed systems, pp. 481497,
Springer, 1999.
61
BIBLIOGRAPHY
[76] C. Jones, P. OHearn, and J. Woodcock, Verified software: A grand challenge, Computer, vol. 39, no. 4, pp. 9395, 2006.
[77] T. H. Cormen, Introduction to algorithms. MIT press, 2009.
[78] S. Owicki and L. Lamport, Proving liveness properties of concurrent
programs, ACM Transactions on Programming Languages and Systems
(TOPLAS), vol. 4, no. 3, pp. 455495, 1982.
[79] B. Alpern and F. B. Schneider, Recognizing safety and liveness, Distributed
computing, vol. 2, no. 3, pp. 117126, 1987.
[80] F. Babich and L. Deotto, Formal methods for specification and analysis
of communication protocols, Communications Surveys & Tutorials, IEEE,
vol. 4, no. 1, pp. 220, 2002.
62

Thesis

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Thesis

Transféré par

Droits d'auteur :

Formats disponibles

A Critical Study of Logical

A thesis submitted for the degree of

I dedicate this work to my beloved parents

Mechanical reasoning is a key area of research on the crossroads of

Survey of Existing Tools for Formal Verification . . . . . . . . . .

Automated Theorem Proving . . . . . . . . . . . . . . . . . . . .

Interactive Theorem Proving . . . . . . . . . . . . . . . . . . . . .

A survey on Interactive Theorem Proving

Formalization of Real Analysis: A Survey of Proof Assistants and Libraries . . . . . . . . . . . . . . . . . . . . . .

The Seventeen Provers of the World . . . . . . . . . . . . .

Isabelle: The next 700 theorem provers . . . . . . . . . . .

2.3.5 A Survey of Interactive Theorem Proving . . . . . . . . . .

Testing with model checkers: a survey . . . . . . . . . . .

Model-Based Development Using Simulink . . . . . . . . .

Diagrammatic Theorem Proving . . . . . . . . . . . . . . . . . . .

Survey of Euler Diagram-based Notations . . . . . . . . .

Approaches to Research Methodology . . . . . . . . . . . . . . . .

Promela Spin Specificaitoin Language . . . . . . . . . . . .

Spin Model Checker . . . . . . . . . . . . . . . . . . . . .

Writing Specification In Promela . . . . . . . . .

Automata View Of Specified Model . . . . . . . .

Simulation Of Specified Model . . . . . . . . . .

4 Formalization of Sliding Window Protocol

Sliding Window Protocol Algorithm . . . . . . . . . . . . . . . . .

Properties of Communication System . . . . . . . . . . . . . . . .

Verificational Result Using On-The-Fly Verifier .

4.4.1.2 Verificational Result Using LTL Claim . . . . . .

Verificational Results Using On-The-Fly Verifier .

4.5.1.2 Verificational Results Using LTL Claim . . . . . .

5 Conclusion and Future Direction

Spin Model Checker . . . . . . . . . . . . . . . . . . . . . . . . . .

Promela Specification for Goback-N SWP . . . . . . . . . . . . .

GUI of Spin Model Checker . . . . . . . . . . . . . . . . . . . . .

Specification of Producer-Consumer Problem . . . . . . . . . . . .

Automata of Specified Model . . . . . . . . . . . . . . . . . . . .

Simulation View of Specified Model . . . . . . . . . . . . . . . . .

SPIN Model Checker GUI . . . . . . . . . . . . . . . . . . . . . .

General Information about the System . . . . . . . . . . . . . . .

Category of the Automated Reasoning System . . . . . . . . . . .

General Programming Framework of the System . . . . . . . . . .

Internal Framework of the system . . . . . . . . . . . . . . . . . .

Complexity Measures of the Protocol . . . . . . . . . . . . . . . .

Capability to make implications is called reasoning, and automating this process

1.2 Thesis Overview

Table 1.1: General Information about the System

Table 1.2: Category of the Automated Reasoning System

1.2 Thesis Overview

Table 1.3: General Programming Framework of the System

Table 1.4: Internal Framework of the system

1.2 Thesis Overview

our work is specified accordingly. Moreover, we present our formal specification

Survey of Existing Tools for Formal Verification

2.1 Survey of Existing Tools for Formal Verification

2.2 Automated Theorem Proving

Automated Theorem Proving

A short survey of automated reasoning

Harrison, J. [? ] Compared Theorem provers and Computer Algebra System.

Interactive Theorem Proving

in this section we present survey paper related to proof assistant or interactive

A survey on Interactive Theorem Proving

2.3 Interactive Theorem Proving

Formalization of Real Analysis: A Survey of Proof

2.3 Interactive Theorem Proving

The Seventeen Provers of the World