Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Development in Mechanical
Reasoning Systems
Moin ul Deen
Department of Computer Science & Information Technology
University of Sargodha
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
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
2.2
9
9
2.3
2.3.1
. . . . . . . . .
2.3.2
10
2.3.3
11
2.3.4
12
13
13
2.4.1
13
2.4.2
15
16
16
2.4
2.5
iv
CONTENTS
2.5.2
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
20
21
3.4.2
Research Instrumentation . . . . . . . . . . . . . . . . . .
22
3.4.3
23
3.4.4
3.4.5
24
26
3.4.5.1
26
3.4.5.2
27
3.4.5.3
3.4.5.4
28
29
32
4.1
Communication Protocol
. . . . . . . . . . . . . . . . . . . . . .
33
4.2
33
4.3
4.4
37
38
4.4.1
Absence of Deadlock . . . . . . . . . . . . . . . . . . . . .
38
4.4.1.1
38
40
41
4.5.1
Absence of Starvation . . . . . . . . . . . . . . . . . . . .
41
4.5.1.1
42
43
45
4.5
4.6
46
CONTENTS
6 Appendix A
6.1
6.2
48
7 Appendix B
7.1
48
48
52
References
52
62
vi
List of Figures
3.1
25
3.2
27
3.3
28
3.4
3.5
29
30
6.1
6.2
50
51
vii
List of Tables
1.1
1.2
1.3
1.4
4.1
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
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
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
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
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
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
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
2.3
2.3.1
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
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
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
11
2.3.4
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.3.5
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
14
2.4.2
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
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
16
2.5.2
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
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
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
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
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
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
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
24
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
Following steps are followed in Spin for verification of the specification of any
systems model.
3.4.5.1
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.
3.4.5.2
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.
3.4.5.3
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.
3.4.5.4
29
30
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
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
33
34
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
37
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
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
4.4.1.2
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.
spin -a GoBN29022016.pml
ltl deadlock: [] (! (((PASR@invalidend)) && ((PBSR@invalidend))))
Pid: 3935
(Spin Version 6.4.4 -- 1 November 2015)
+ Partial Order Reduction
40
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
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
(Spin Version 6.4.4 -- 1 November 2015)
Bit statespace search for:
never claim
+ (:np_:)
assertion violations - (disabled by -A flag)
non-progress cycles + (fairness enabled)
invalid end states - (disabled by -E flag)
State-vector 116 byte, depth reached 9999, errors: 0
301388 states, stored (455885 visited)
523769 states, matched
42
4.5.1.2
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.
spin -a GoBN29022016.pml
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
(Spin Version 6.4.4 -- 1 November 2015)
Bit statespace search for:
never claim
+ (nonprog)
assertion violations - (disabled by -A flag)
non-progress cycles + (fairness enabled)
invalid end states - (disabled by -E flag)
State-vector 116 byte, depth reached 9999, errors: 0
516622 states, stored
1129056 states, matched
1645678 transitions (= stored+matched)
0 atomic steps
hash factor: 2.02968 (best if > 100.)
bits set per state: 3 (-k3)
Stats on memory usage (in Megabytes):
67.006
0.125
0.076
0.534
1.538
44
4.6
Measures of Complexity
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
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
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
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:
50
51
Chapter 7
Appendix B
7.1
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
53
75
76
77
78
79
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
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
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
60
BIBLIOGRAPHY
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