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