A Model Checking Methodology for Embedded Systems Kuntal Roy Advanced Research and Learning Institute (ALaRI) University of Lugano, Lugano 6904, Switzerland Email: [email protected]

Abstract Model checking has been proved to be a part and parcel in validating the behavior of embedded systems. In this paper, an automated design flow is described to formally verify the correctness of a system specified in Unified Modeling Language (UML). The models are constructed as state machines and the properties to be satisfied against the system model are specified as sequence diagrams. In this connection, the methodology is applied to an IPSec accelerator. The behavior of the scheduler unit in the IPSec accelerator is emphasized and a behavior that should not be satisfied is verified to establish the correctness of the model checking methodology. 1. I NTRODUCTION Increasing complexity and the demand of shortening the time-to-market for embedded systems have made the challenge of properly designing a system-on-chip more significant. In fact, being able to avoid any error in the design stage and accordingly preventing an error propagation in the subsequent product development stages to avert a costly redesign step have become a crucial part of designing an embedded system. Thus, verification of the correctness of a system design have become a growing concern now-a-days. After several years of work, the software community has agreed to a set of notations along with visual interface for describing a software that is known as Unified Modeling Language (UML) [1]. However, the prowess of UML is not only limited to the description of a software but also it has been a successful modeling language for describing a system. In brief, UML is an object oriented modeling language that consists of graphical and textual notations, organized in a set of diagrams. Class diagram, state machine, and sequence diagram are the three major diagrams that are important to encapsulate the design of a system. A class diagram shows the different objects in the system along with the connection between the objects. State machines describe the state transitions for the different objects specified in the class diagram. In other words, state machines model a system. A sequence diagram defines a property of a system. For model checking, we need to test a property against the model of a system. Allowed properties should pass the checking whereas the forbidden properties should be restricted during model checking. Figure 1 shows

Fig. 1:

Model checking.

a graphical view signifying the conformance check of the properties against the model of a system. Model checking [2] is not a new concept. In 1977, Pnueli introduces the use of (linear) temporal logic for specifying program properties over time [3]. In 1981, model checking has been introduced by Clarke & Emerson [4] and Quielle & Sifakis [5]. The ideas were based on explicitly traversing a graph and the capacity was limited by state explosion. In 1986, Vardi & Wolper introduce automata-theoretic approach for model checking [6]. Also, in early mid 80s, Holzmann started working on SPIN model checker [7]. Since then, model checking is extensively studied in literature [8], [9], [10]. The use of UML as electronic system level design methodology is described in [11]. As the UML 2.0 was undertaken to make the application of UML to wider designer including the system level designer, model checking for the same is proposed in [12]. In spite of enormous efforts, there exists a significant gap between the designing of a system and the verification of the system properties. A system is usually described with some UML tool and a model checker (e.g., SPIN [13]) usually works with a code written in a verification language e.g., promela [14]. The methodology described in this article is inspired from the development of a tool named Hugo/RT [15] that enable us to automatically transform UML 2.0 interactions into B¨uchi automata [2]. Subsequently, the tool generates a code in some verification language to be input to a model checker. However, there exist several problems to correctly transfer the model and properties described in some UML modeling tool into a verification language. The problems are

pointed out and corresponding remedies are walked through to be successfully able to apply the model checking methodology for a simple requester-responder and IPSec accelerator designs. The rest of the paper is organized as follows. Section 2 describes the tools used in the design flow of the model checking methodology. The unified design flow is presented in 3. Section 4 and Section 5 describe the application of the model checking methodology for a simple requester-responder model and a IPSec accelerator model focusing on its scheduler unit. Finally, Section 6 concludes the paper. 2. T OOLS U SED In this section the tools used in the model checking methodology are described briefly. A. ArgoUML ArgoUML [16] is a leading UML modeling tool that is free and open source under the Berkley Software Design (BSD) license. ArgoUML, although rich in features, still lacks some of the features of high-end commercial tools. However, ArgoUML is a very active project and the tool is rapidly evolving. ArgoUML is developed with 100-percent java programming language. ArgoUML version 0.24 is used in this paper. B. Hugo/RT Hugo/RT [15] is an open-source model translator for model checking. It works on UML specifications. A UML model consisting of classes, state machines, collaborations, interactions, and OCL (Object Constraint Language) constraints can be translated into the system languages required for different model checkers, including the well known on-the-fly model checker SPIN. The proprietary UML TExtual format (UTE) [17] reflects the UML features that are handled by Hugo/RT. The current version 0.50a is used in this work.

Fig. 2:

Design flow.

C. SPIN SPIN [13] is a widely used open-source model checker that can be used for the formal verification of distributed software systems. The tool has been developed at Bell Labs starting in 1980 and is available from 1991. In April, 2002 the tool was awarded the prestigious System Software Award for 2001 by ACM. The design of SPIN is focused on the efficient verification of asynchronous software systems. SPIN translates each process template defined in promela, into a finite automaton. To perform verification, SPIN takes a correctness claim that is specified as a temporal logic formula, converts that formula into a B¨uchi automaton. A B¨uchi automaton accepts a system execution if an only if that execution forces it to pass through one or more of its acceptance states infinitely often. SPIN does the entire computation, starting from the individual concurrent components and a single B¨uchi automaton representing a correctness claim, in one single procedure using a nested depth-first search algorithm.

Apart from the above tools, an open source graph visualization software named Graphviz [18] that is used to convert the .dot graph files for B¨uchi automata generated by Hugo/RT to any of the image (e.g., .jpg, .ps etc.) files. 3. D ESIGN F LOW According to the model checking methodology, we need to perform the following subsequent steps. 1) Draw the class diagram, corresponding state machines, and the required sequence diagrams as needed in ArgoUML. 2) Convert the ArgoUML project to the corresponding UTE [17] format (.ute file) with the help of the tool Hugo/RT. 3) There is some problem with the current version of Hugo/RT for which Hugo/RT does not write correctly the sequence diagram part in the generated .ute file. It has to be written manually.

Fig. 3:

Class diagram for requester-responder model.

Fig. 5:

Fig. 4:

State machine for Responder.

State machine for Requester.

4) In this step, the model checking is performed by SPIN in collaboration with Hugo/RT. The updated .ute file from the previous step is used as input in this step. It needs to use two options -c and -i. The option -c corresponds to the sequence diagram name and -i corresponds to a specific interaction. It is possible to define more than one interaction in the .ute file but, only one can be used at a time for model checking. The model translator Hugo/RT translates the UML design to the verification language promela that is input to the model checker SPIN. The unified design flow is shown in the Figure 2. 4. A R EQUESTER -R ESPONDER M ODEL In this section we describe a simple requester-responder model for a better understanding of the readers and to be able to follow conveniently the model checking for an IPSec accelerator model described in the next section. The model consists of two objects Requester and Responder. Requester sends a request to the Responder and upon reception of such a request, the Receiver sends a response back. The corresponding class diagram, state machines, and sequence diagram are shown in Figures 3-6. It needs mantion here that any transition between the states has a generic format trigger [guard condition]/action where guard condition refers to a condition upon satisfying along with the trigger allows the system to change the state, otherwise, no state change is possible. The action is a task to be performed immediately after the change of a state. The B¨uchi automata corresponding to the sequence diagram is shown in Figure 7. The sequence diagram part that has to be handwritten in the .ute file is given in Appendix I. In Appendix II, an Observer process in promela generated by Hugo/RT corresponding to the sequence diagram is given. 5. A N IPS EC ACCELERATOR M ODEL IPSec [19] is a suite of protocols that adds security to communication at IP level. As the protocols uses cryptographic algorithms that are computationally very intensive, a hardware

Fig. 6: Sequence diagram containing a request and a subsequent response for the requester-responder model.

acceleration is needed to achieve a high throughput. This is the motivation behind the design of a system-on-chip implementing IPSec. During model checking, we focus on the Scheduler unit that is one of the major decision making part of the implementation. The Scheduler unit receives packets to be processed, and schedules them to the crypto-engines(s). But, before scheduling, it has to receive two subsequent signals: scheduleProcess from InDBManager and confirmPacket from NetIOManager. The class diagram, state machine for the Scheduler unit, and the corresponding sequence diagram are shown in the Figures 8, 9, and 10, respectively. The B¨uchi automaton corresponding to the sequence diagram is given in Figure 11. It can be noticed from the B¨uchi automaton that the reception of the signal confirmPacket is always preceded by the reception of the signal scheduleProcess. However, the sending of the signals from their corresponding objects (i.e., InDBManager and NetIOManager) can be in any order. This can be followed from the state machine of the Scheduler unit (Figure 9). The system cannot leave its initial state WaitForProcRequest until and unless it receives the scheduleProcess signal. Accordingly, if the signal scheduleProcess is not received or it is received after the signal confirmPacket, the system is not going to work. Another sequence diagram is drawn as shown in the Figure 12 to verify the correctness of the model checking methodology. In this case, the Scheduler sends the packet to the crypto-engine without receiving the scheduleProcess signal from InDBManager. Accordingly, the state machine (Figure 9) cannot get initiated from its initial state waitForProcRequest as the signal scheduleProcess is not received. The B¨uchi automaton corresponding to the sequence diagram (Figure 12) is shown in Figure 13. SPIN does the checking by

Fig. 8:

Class diagram for IPSec accelerator model focusing on the Scheduler unit.

Fig. 10:

A sequence diagram containing a correct sequence of execution.

Fig. 7: B¨uchi automaton corresponding to the sequence diagram in Figure 6.

Fig. 9:

State machine for Scheduler unit.

constructing the B¨uchi automaton for the model and checking the acceptance cycles. The description of the Scheduler class for IPSec accelerator model in UML textual format is given in Appendix III. We can notice that the signature and behavior descriptions along with the transitions between the states are encapsulated inside the class. The descriptions are corresponding to the state machine (Figure 9) and the class diagram (Figure 8).

Fig. 11:

B¨uchi automaton for the sequence diagram in Figure 10.

responder = responder; } object responder : Responder { requester = requester; } interaction newInteraction { Fig. 12: A sequence diagram containing an incorrect sequence of execution.

request : requester –> responder: request(); response : responder –> requester: response(); basic { requester { snd(request); rcv(response); } responder { rcv(request); snd(response); } } } A PPENDIX II P ROMELA C ODE G ENERATED BY H UGO /RT FOR THE SEQUENCE DIAGRAM IN R EQUESTER -R ESPONDER M ODEL

Fig. 13:

B¨uchi automaton for the sequence diagram in Figure 12.

6. C ONCLUSIONS AND F UTURE W ORKS In this paper a model checking methodology for a UML design comprising of class diagram, state machines, and sequence diagrams is demonstrated with some of the available open source tools. The problems found during the walkthrough are pointed out. However, they are taken care of and subsequently the model checking methodology is successfully applied to check any mismatch between the model of a system and the requirements. This kind of formal verification allows a designer to quickly fix the problems in the design by crosschecking the model and properties. Also, any incremental design updation can be facilitated by checking the system functionality with some sequence diagrams. However, the problems in the Hugo/RT tool should get fixed to facilitate a convenient walk-through through the methodology. Also, rather than only ArgoUML, we need support for other UML modeling tools especially the commercial tools to model check the existing designs already done in some other UML modeling tools. A PPENDIX I S EQUENCE D IAGRAM IN UML T EXTUAL F ORMAT FOR R EQUESTER -R ESPONDER M ODEL object requester : Requester {

proctype Observer() { bit v 1[4]; bit direction; byte sender; int behavioural; int arguments[max parameters]; byte receiver; nc s 2: if :: (((v 1[0] && v 1[1]) && v 1[2]) && v 1[3]) –> goto nc s 1 :: observer?direction,sender,receiver,behavioural –> if :: direction == RECEIVE && sender == obj responder && behavioural == send response && receiver == obj requester && receiver == obj requester && (((!v 1[0] && v 1[1]) && v 1[3]) && v 1[2]) –> atomic { v 1[0] = 1; goto nc s 2 } fi fi;

effect ;

nc s 1: if :: true –> goto acceptAll fi; acceptAll: if :: 0 == 0 –> goto acceptAll fi

} top initial0 –> waitForProcReqest { guard true; effect ; } waitForProcReqest –> scheduleMsgReceived { trigger scheduleProcess; guard true; effect ; }

} A PPENDIX III S CHEDULER C LASS FOR IPS EC ACCELERATOR M ODEL class Scheduler { signature { attr cryptoEngine : CryptoEngine; attr packetInQueue : boolean; operation cryptoProcess(); reception scheduleProcess(); reception confirmPacket(); reception checkPacketInQueue(); } behaviour { states { simple waitForProcReqest; simple schedule; simple scheduleMsgReceived; simple cryptoProcess; initial top initial0; } transitions { schedule –> cryptoProcess { guard true; effect cryptoEngine.cryptoProcess(); } cryptoProcess –> schedule { trigger checkPacketInQueue; guard packetInQueue == true; effect ; } cryptoProcess –> waitForProcReqest { trigger checkPacketInQueue; guard packetInQueue == false; effect ; } scheduleMsgReceived –> schedule { trigger confirmPacket; guard true;

} } } ACKNOWLEDGMENT The author would like to thank Mauro Prevostini, Jochen Wuttke, and Alberto Ferrante for their help. R EFERENCES [1] UML Website: http://www.uml.org. [2] E. M. Clarke, O. Grumberg, and D. A. Peled, Model Checking. The MIT Press, 2000. [3] Z. Manna and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems. Springer, 1992. [4] E. M. Clarke and E. A. Emerson, “Design and Synthesis of Synchronization Skeletons Using Branching-Time Temporal Logic,” in Springer, Lecture Notes in Computer Science, vol. 131, May 1981. [5] J. Queille and J. Sifakis, “Specification and Verification of Concurrent Systems in Cesar,” in Springer, Lecture Notes in Computer Science, vol. 137, 1981, pp. 337–351. [6] M. Vardi and P. Wolper, “Automata-theoretic techniques for modal logics of programs,” Journal of Computer and System Science, vol. 32, no. 2, pp. 182–221, Apr. 1986. [7] G. J. Holzmann, “The Model Checker SPIN,” IEEE Transactions on Software Engineering, vol. 23, no. 5, pp. 1–17, May 1997. [8] F. Schneider, S. Easterbrook, J. Callahan, and G. J. Holzmann, “Validating requirements for fault tolerant systems using model checking,” in Proc. International Conference on Requirements Engineering, ICRE. Colorado Springs, Co., USA: IEEE, 1998, pp. 4–14. [9] O. Kupferman, M. Y. Vardi, and P. Wolper, “An automata-theoretic approach to branching-time model checking,” Journal of the ACM, vol. 47, no. 2, pp. 312–360, 2000. [10] G. J. Holzmann and R. Joshi, “Model-Driven Software Verification,” in Springer, Lecture Notes in Computer Science, vol. 2989/2004, Feb. 2004, pp. 76–91. [11] A. Basu, M. Lajolo, and M. Prevostini, “UML in an Electronic System Level Design Methodology,” in UML-SoC 2004 (DAC Workshop), San Diego, California, USA, June 2004. [12] A. Knapp and J. Wuttke, “Model Checking of UML 2.0 Interactions,” in Critical Systems Development Using Modeling Languages (CSDUML), 2006. [13] SPIN Website: http://www.spinroot.com. [14] Promela Quick Reference: http://www.spinroot.com/spin/Man/Quick.html. [15] Hugo/RT Website: http://www.pst.ifi.lmu.de/projekte/hugo/. [16] ArgoUML Website: http://argouml.tigris.org/. [17] UTE: http://www.pst.ifi.lmu.de/projekte/hugo/#UTE. [18] Graphviz Website: http://www.graphviz.org/. [19] A. Ferrante and V. Piuri, “High-level Architecture of an IPSec-dedicated System on Chip,” in NGI 2007, Trondheim, Norway, May 2007.