Title: Formal Specification and Verification of a Communication - - PDF document

Title: Formal Specification and Verification of a Communication Protocol (temporary) Author: Hojung Bang Affiliation: KAIST Address: 373-1, Kuseong-dong, Yuseong-gu, Daejeon, 305-701, Korea Abstract: In this paper, we summarized our experience on the formal specification and verification of a communication protocol that is used in a system air conditioner. Based on a given software requirement specification, we formalized a communication protocol in SDL and verified it using a model checker,

• SPIN. Since the SDL model constructed was is too large in state space for SPIN to handle, it had to be

reduced and abstracted before the verification. In spite of the reduction and abstraction, some properties cannot be checked in exhaustive manner. As a result, we found many errors in the requirements and some

• f them are not trivial to catch in other methods.

Selected Discussion Topic: Formal Method

• 1. Introduction

We formalized and verified the requirement specification of a communication protocol for a system air conditioner, which is being developed in Samsung Electronics, to detect possible errors and to suggest solutions to correct them. The communication protocol is designed to be used in the communication between the client and the server of a system air conditioner. A system air conditioner is a collection of devices that is installed into a large building and systematically controls the temperature of the building. It consists of clients, servers, and other devices: servers control other devices such as indoors and outdoors, whereas clients such as web-pad and personal computer are used for users to connect to servers and control the whole system. Unfortunately, the specification of the communication protocol does not exist in an independent document; rather it is included in both requirement specifications of the client and the server software, with a viewpoint of each side. These requirements were written in natural language with some semi- formal scenarios in MSC-like notation. According to the requirements, client software can control up to four servers and it can send another command before receiving the responses of previous ones. Timeouts exist for the arrival of responses: after a predefined period of time (9 sec) without any responses, the client regards the connection to the server is broken. We formalized the requirements into SDL model and verified it with model checking technique. Throughout the procedure, we are based on two criteria, completeness and consistency. The completeness

means that the system should always respond properly to all possible inputs from its environments. On the other hand, the consistency means that the system should stick to the requirements all the time; i.e., there should not be unexpected behaviors. As a result of the formalization and verification, we found many errors from the requirements. Errors detected in the modeling phase include incorrectness, inconsistency, and ambiguity. Some errors found in the model checking are not trivial to catch in the other methods. This paper is composed as follows: section 2 briefly introduces our approaches. Section 3 describes

• ur methods and experience of the modeling phase and section 4 explains those of the verification phase.

Section 5 concludes the paper.

• 2. Our approach

Our approach consists of two phases: modeling and verification. In the modeling phase, we tried to understand the given requirements and formalize it as a SDL model. We used inspections on the requirements and interviews with the developers in this phase. In the verification phase, we translated and modified the model and checked it using SPIN against various properties. The followings were happened during the modeling phase: (1) we performed several inspections to better understand the requirements. (2) Questions and ambiguity arisen from the inspections were solved through four interviews with the developers of the software for the client and the server. After that, (3) an SDL model was created based on our understanding of the requirements. (4) Some domain independent properties as well as the possibilities of all scenarios in the model were checked. (5) The resulting model was reviewed by the developers and was modified accordingly. The activities of the verification phase are as follows: (1) the SDL model was transformed into a corresponding Promela code. (2) An environment process was constructed and added to the existing code to make it a closed system. (3) The code was reduced and abstracted to be handled with SPIN. (4) Four types of properties are generated. (5) We checked the properties against the model (Promela code). The objective of the modeling and the verification phase are to check the completeness and the consistency of the requirements. In the modeling phase, the completeness of the requirements as well as that of the model was checked by the aid of the state-event table and Tau SDL Validator. In the verification phase, the consistency of them was checked using model checking technique with expected inconsistent scenarios as properties.

• III. Modeling

We used SDL as modeling language since it is developed thus well suited for telecommunication domain, where the interactions between participants are more focused than their internal behaviors. With

SDL, we can specify synchronous as well as asynchronous communication without difficulty. Inspections and interviews are used throughout the modeling phase: we applied inspection several times to better understand the specification and to find possible errors in the generated model. Inspection is one of the most powerful verification techniques, and can be applied to all phases of software

• development. We also had interviews with the developers several times before and after constructing

models to resolve questions arisen from the inspections, to confirm our understanding, and to review constructed model. An SDL model was constructed from the requirements and additional information obtained during the inspections and the interviews with the developers. Tau SDL Suite 4.2 was used as a modeling tool. The resulting model consists of five blocks, a block for client and four identical blocks for servers, and each block contains a process. We did not model the environment of the system. To construct an SDL model we extracted signals and states from the requirements. We first extracted possible signals and their important parameters. A parameter of a signal is regarded as important if its value affects the external behavior of the receiving components; i.e., it is used in determining the type of signal to be sent as a response to the signal. After that we extracted possible states from the requirements. Some states could be extracted directly from MSC-like scenarios: a status when a process sent a signal and waits its response can be a state; we called these types of states as ‘explicit’ states. To the contrary, the ‘implicit’ states are extracted in a different manner: implicit states are the local variables that are needed to decide external behaviors of the components. To check the completeness of the model we created a state-event table per a process. The table for a process has all the states of the process as its rows and all events as its columns. This table is used to see how a process in each state reacts to each possible input signal and if this reaction is explicitly specified in the requirements or in the model. A process in a state can react to an input signal by transiting to the next state, raising an exception, or simply neglecting it. This table helped to find unspecified assumptions

• f the requirements.

Additional checks are performed to validate the conformance between the requirements and the model and to check domain independent properties: using Tau SDL Simulator, we checked that all scenarios in the requirements are also possible in the resulting model. With the aid of Tau SDL Validator, we also checked the model to see if there is unexpected dead-lock, live-lock, or implicit signal

• consumption. The validated model was reviewed by the developers and modified accordingly.

The modeling itself can help to detect errors and ambiguities in the requirements since it is impossible to construct a model without thorough understanding of the target requirements. During the modeling phase, we found 34 errors in the requirements: 12 incorrect specifications, 2 inconsistencies between the two requirements, 3 ambiguities, and 17 simple errors such as typo, incorrect names, and references.

• IV. Verification

In the verification phase, we checked the consistency of model with model checking technique; SPIN is used for the project, since it supports communication channel as a native construct, thus is well- suited for SDL specification. We transformed the SDL model into a corresponding Promela code using in-house tool SDL2SPIN. SDL2SPIN supports a subset of SDL constructs and converts basic constructs of SDL to that of Promela. During the transformation some modifications are needed to make the model finite: for example, the size

• f channels should be bounded and the domains of variables should be restricted to finite ones.

In addition, an environmental process should be constructed and added to the existing model to make it closed system since SPIN supports only closed models. We constructed a liberal one that can send all possible signals with all possible values of parameters to the other processes without any restriction. Since the resulting model was too big for SPIN to handle, we had to reduce the model while maintaining its proper behaviors. We reduced the number of servers from 4 to 2. Since we wanted to check the interference between multiple servers, two servers are our minimum requirements. After that, we abstracted internal behaviors of each process that are intrinsic and removed all timers by adding corresponding external input signals for all timeout signals. We also restricted the behavior of the environment process based on the synchrony hypothesis so that it can emit signals only when the other processes are in stable states. As the result of these reduction and abstraction, the size of model was significantly reduced; however, the resulting model was still too big for exhaustive search; therefore, we had to use Bitstate reduction option for some properties. Properties were specified in LTL or with Timeline editor and checked repeatedly with diverse

• ptions of SPIN. LTL is powerful but hard to specify or understand in case of complicated properties.

Timeline editor is easier and provides graphical user interface in sacrifice of expressive power: it cannot specify properties with fairness. The following are the four types of properties we used in the verification: possibility of scenarios, responsiveness, precondition, erroneous behaviors.

• 1. Possibility of scenarios

The properties for possibility of scenarios are used to check the conformance the SDL model and Promela model. All scenarios that were possible in the specification and in the SDL model should also be possible in the Promela model. These properties are specified as timelines with Timeline editor and transformed into Büchi automata to be used in SPIN. As a result, we found that all the scenarios in the requirements are possible except one scenario, which has two preconditions to be executed, but they are turned out to be exclusive each other.

• 2. Responsiveness

We also checked every request to the servers is responded in fair system behaviors. The template for the properties is ‘FC -> [] (REQ -> <> RES).’ It says that as long as the fairness condition (FC) holds, the requests (REQ) should be responded (RES) after all. FC was introduced to guarantee the statement-level fairness of each process, which is not guaranteed in the SPIN. SPIN should search all the possible behaviors in the model to validate the given properties, which is impossible due to the size of the model. Because of this problem, we used ‘bit-state’ reduction technique for these properties. It is quite efficient technique, but yields a partial verification. According to the result, all the scenarios satisfy this responsiveness.

• 3. Precondition for scenarios

The properties for extracting precondition are used to find precondition (PC) for a scenario to finish

• successfully. The template for these properties is ‘FC && PC -> [] (START -> <> END).’ It says that the

pre-condition (PC) as well as FC holds in the system, the started scenarios (START) should be ended successfully without exception (END). To know the implicit assumptions for scenarios is important in that the information could remove the ambiguity or misunderstanding of the requirements. We also used ‘bit-state’ reduction option. As a result, we found preconditions for complicated scenarios. Most of them are not specified explicitly in the requirements.

• 4. Erroneous Behaviors

We checked the possibilities of inconsistent behaviors. It should be impossible for a component to proceed without taking the counterpart’s response to the request. To check this property, we instrumented a Boolean flag to the model to see if the response really happened after the request and used using ‘REQ && (! SIGNAL U RES)’ as template. SIGNAL indicates that the request (REQ) was properly processed and response was sent. We found some cases where the communication behaviors of components are inconsistent: in several traces, the client that is waiting a response after sending a command mistakes the responses of other commands as proper ones and proceeds in unexpected way. The signal received after timeouts or sent by the wrong servers can cause a similar inconsistency. To remedy this problem, we recommended to include message identifier for acknowledge (or exception) message to distinguish from each other and session identifier to all messages to determine the responses of the commands of the same type. In summary, we constructed 102 properties and checked each of them twice with different options. Among them, 50 properties for possibility of scenarios, 38 properties for responsiveness and preconditions, 14 properties for erroneous behaviors. We used a Pentium 4, 3.2GHz process with 3GB

RAM to execute SPIN. Checking exhaustive took about an hour per property until success or out of memory message and checking with Bitstate option took about 10 minutes each. Average length of counter-example is about 200,000 depths.

• V. Conclusion and Experiences

We applied formal methods in the verification of a communication protocol and found a number of errors in the protocol specification. We used inspection and interview as aids of formal methods. Inspection is a powerful technique for specification as well as model. In constructing a model for verification, modeling environmental process is difficult: too liberal processes increase the state space of the target system in addition to introducing unrealistic behaviors. While, too restricted ones can miss the behaviors of the real environments, thus result in unsafe model. Synchrony hypothesis was useful in determining the level of environmental modeling. Specifying properties is the most difficult part in applying model checking since extracting good properties requires domain knowledge. Properties constructed to detect errors such as those for erroneous behaviors are useful in detecting errors. SPIN is not scalable enough to handle industrial application software. The target model was so large that after we tried hard to reduce the size of state space by applying possible reduction and abstraction techniques to the model, SPIN failed to check it exhaustively. Fortunately, model checking has a practical advantage in error detection. It works well rather in detecting errors than in verifying the error-freeness.