1 Introduction. In recent years, the safety-critical software development community is increasingly moving towards a model-based development process, in which ...
A Dynamic Assertion-Based Verification Platform for Validation of UML Designs Ansuman Banerjee1 , Sayak Ray1 , Pallab Dasgupta1, Partha Pratim Chakrabarti1, S. Ramesh2 , and P. Vignesh V. Ganesan2 1
Indian Institute of Technology Kharagpur 2 General Motors India Science Labs
Abstract. For quite some time, the Unified Modeling Language (UML) [5] has been adopted by designers of safety critical control systems such as automotive and aviation control. This has led to an increased emphasis on setting up a validation flow over UML that can be used to guarantee the correctness of UML models. In this paper, we present a dynamic property verification (DPV) framework for validation of UML designs. The verification engine is built on top of Rhapsody [3], a popular UML simulator, using the concept of dynamic property monitoring over simulation runs. In view of the growing popularity of modelbased development, we believe that the verification methodology presented in this paper is of immediate practical value to the UML-based design community.
1 Introduction In recent years, the safety-critical software development community is increasingly moving towards a model-based development process, in which the largely textual way of requirement capturing is replaced by executable specification models at different levels of abstraction. For the past few decades, the Unified Modeling Language (UML) [5] has been one of the preferred choices in the software community for the design of a wide variety of applications at a higher level of abstraction, ranging from automotive control to medical instrumentation. This has led to an increased emphasis on setting up a validation flow over UML that can be used to guarantee the correctness of UML models. In the last few decades, formal property verification has established itself as an effective validation methodology, both in the hardware and software verification community for its ability of automatic and exhaustive reasoning. Verification practitioners have also been able to uncover flaws in the specifications of complex protocols and intricate bugs in live designs. Unfortunately, the exponential increase in complexity and the increasingly distributed nature of functions as used in application software renders formal verification infeasible for intricate software systems because of its inherent capacity bottleneck in handling large systems. In the last decade, the more popular validation methodology (at least in the hardware domain) has been dynamic property verification (DPV). DPV is a semi-formal approach where the formal properties are checked over simulation runs. DPV is highly scalable and can support a richer specification language as compared to languages supported by formal verification tools. Cha et al. (Eds.): ATVA 2008, LNCS 5311, pp. 222–227, 2008. c Springer-Verlag Berlin Heidelberg 2008
A Dynamic Assertion-Based Verification Platform for Validation of UML Designs
223
UML Models
Rhapsody Simulation Engine
Verification Engine
Interface signals
Fig. 1. The DPV platform over Rhapsody
The main contribution of this paper is in developing an integrated platform for validating behavioral requirements over UML Statecharts using DPV. The salient features of our contribution are (a) Action-LTL, an extension of Linear Temporal Logic (LTL) [2] to facilitate the expression of properties arising in the context of software systems, (b) A verification engine for dynamic assertion monitoring over Rhapsody simulation runs, and (c) An integrated interface for facilitating DPV for checking Action-LTL requirements on the UML model under test in Rhapsody. The main novelty of this work lies in the way this framework has been built to facilitate dynamic property verification in the UML context in Rhapsody. Figure 1 shows the overall architecture. A number of different approaches for the verification of UML Statecharts have been developed by researchers. [1] presents a survey of these approaches. The main principle behind many of these approaches is to translate the Statecharts into some format which is amenable to formal verification tools, and on the other hand, use the power of temporal logic for specifying behavioral requirements. A model checker is then invoked to establish the truth or falsify the specification on the model. The main novelty of our work is in developing a DPV solution for validating behavioral requirements over UML Statecharts. With the growing popularity of model-based development, we believe that this work will have value for the model-based design community.
2 Tool Architecture In this section, we describe the overall architecture of our verification platform, along with details of its main components. To emphasize the challenges overcome in the process, we discuss the issues in building a DPV tool for UML and our approach in handling these. The requirements of a DPV platform are as follows: 1. A modeling language for the system under test and a simulator for that language 2. An assertion specification language 3. A verification engine running on top of the simulator 2.1 Modeling Language and Simulator In this work, we used UML as the model development language, and Rhapsody [3] as the UML simulator. For this, we needed to understand the simulation semantics of
224
A. Banerjee et al.
Rhapsody, the way it handles concurrency and communication. The main idea behind our framework is to evaluate assertion requirements on the basis of responses produced by the model under test during simulation inside Rhapsody. The behavior of a system described in Rhapsody is a set of possible runs. A run consists of a series of detailed snapshots of the system’s situation. Such a snapshot is called a status. The first in the sequence is the initial status, and each subsequent one is obtained from its predecessor by executing a step triggered by the dispatch of an event. In Rhapsody, events form the central component for communication among Statecharts for different concurrent modules of a system. A status contains information about the present condition of all the objects in the system, data values, events and history information for states. The concept of status and step are of utmost importance since properties in Action-LTL are expressed over data values at status points and events at steps. 2.2 Action-LTL: Assertion Specification Language To describe correctness properties, one needs to describe properties over data attributes and events as well. Property specification languages that have been widely used in the verification community are pre-dominantly either state-based or event-based. However, for our purpose, we need to specify both state information and events (communication among components). For example, the Local Interconnect Network (LIN) [4] protocol specification has the following requirement: In slave node, detection of break/synch frame shall abort the transfer in progress and processing of the new frame shall commence. As this shows, both states (for describing a transfer in progress) and events (break/synch event) are required to capture the desired behavior. To address the above issue, we extended Linear Temporal Logic (LTL) with some interesting features, specifically, the ability to express requirements over events, ability to express arithmetic and relational queries over data attributes, the concept of local variables and the concept of parameterized events. Our logic is called Action-LTL and is used within our DPV framework for specifying assertions. We call the logic Action-LTL to distinguish it from the standard LTL used in the hardware verification community. However, it may be noted that this is not a new logic altogether. While the temporal features remain as earlier, the only major difference is in the definition of events that allow us to capture state-event requirements of protocols and a support for verification of properties involving the actual parameter values of parameterized events. The additional novelty of Action-LTL lies in its semantics, which had to be defined in accordance to the simulation semantics of Rhapsody, and was therefore, non-trivial. The following example illustrates the way Action-LTL properties are expressed and interpreted with respect to Rhapsody simulation runs. Example 1. Consider the system in Figure 2 consisting of objects M1 and M2. x is a data member of M1, y is a data member of M2. ev1 is an external event which is at the top of the event queue at the start of simulation. ev2 (a) is an event with payload, while ev3 and ev4 are normal events. State A is the initial state of M1 and State P is the initial state of M2. Hence, the initial status of the system consists of (M1.A, M2.P). Consider the following execution of the system: M1 receives event ev1 from the user. The transition from state A to state B is fired. This transition involves sending event
A Dynamic Assertion-Based Verification Platform for Validation of UML Designs M1
225
M2 ev1/M2 −> GEN(ev2(a))
A x=0
ev2(a)/M1 −> GEN(ev3)
B x=1
ev3
ev1 status (M1.x=0, M2.y=0)
P
ev4
ev2(5) status (M1.x=1, M2.y=0)
Q
y=0
y=5
ev3 status (M1.x=1, M2.y=5)
status (M1.x=0, M2.y=5)
Fig. 2. A Sample System
ev2(a) to object M2 (by placing a new event ev2 in the event queue with a value for parameter a), as specified by the action M2 → GEN(ev2 (a)) 1 . Once the transition to state B of M1 is completed, the status variable shows (M1.B, M2.P). In the next step, event ev2 is removed from the event queue, and is dispatched to object M2 with a value for a, causing it to take the transition from state P to Q. A sample snapshot of the Rhapsody execution trace of the system (consisting of status and steps) is shown in Figure 2. To demonstrate the power of Action-LTL, we present some correctness requirements on this system and the corresponding Action-LTL encodings. – M1.x = 0: The property formally expresses the requirement that M1 has x=0 in the initial status. In this case, M1.x = 0 evaluates to true if the data attribute x has the value 0. This property is true in our example model. – G (M2.ev2(a) ⇒ X (M2.y = a)): This expresses the requirement that always when event ev2 (a) is dispatched to M2, the value of M2.y equals the value of a in the next cycle. This evaluates to true vacuously in the first simulation step since ev2 is absent. It becomes true in the subsequent step considering the Rhapsody execution trace shown in Figure 2 (ev2 is instantiated with 5). – F ((M1.x = 0) ∧ (M2.y = 6)): This expresses the requirement that in some future status, the value of the data attributes x and y are 0 and 6 respectively. 2.3 The Verification Engine The main idea of DPV is based on examining the responses of the system under test during simulation. Therefore, one of the primary requirements was to define a interface for accessing model variables. The system under verification must allow some external hooks to access the model attributes and events visible to the verification engine. In addition, the granularity of model attribute sampling is also important, due to the absence of a universal clock (as in the hardware domain) and values of data attributes and events sampled at different points may result in different validation results. To address this issue, we had to understand the simulation semantics of Rhapsody and make necessary modifications. The model parameters are sampled by the assertion engine. The verification engine plays the most crucial role in the DPV process. Its main task is to sample the model attribute values from the interface at the end of every simulation cycle and evaluate the assertions on the basis of the sampled values. If any assertion evaluates to true or false, it reports the corresponding status to the user. For assertions 1
GEN is a Rhapsody macro used for event generation.
226
A. Banerjee et al.
whose success/failure span multiple simulation cycles, the verification engine prepares the property to be checked from the next simulation cycle and returns control to the simulator. In this work, the verification engine was built on top of Rhapsody, using the concept of dynamic property monitoring over simulation runs. This posed several challenges, starting from creation to integration of assertion monitors, and required us to engineer the internals of Rhapsody In our methodology, Action-LTL specifications are compiled into an assertion monitor and integrated with the Rhapsody models of the system under test. The assertion monitor is built as a Rhapsody object with embedded C routines for dynamic verification. The assertion monitor is then cosimulated with the model of the design-under-test and assertion violations/satisfactions are shown as events on the generated sequence diagram to facilitate debug. Action-LTL properties are interpreted in a similar manner as in case of simulationbased dynamic property verification. The status (satisfaction/violation) of a property can only be concluded if we can reach a decisive report within the number of cycles for which simulation is carried out. For example, violation of liveness properties and satisfaction of safety properties cannot be concluded. The task of dynamically monitoring the truth of a given Action-LTL property along a simulation run is intuitively simple. If we are required to check a property, ϕ, from a given time step, t, we rewrite the property into a set of propositions over the signals (data and events) at time t and a set of properties over the run starting from time t + 1. The rewriting rules are standard [2]. The assertion monitor reads the variable values from the active status at time t and substitutes these on the rewritten properties and derives a new property that must hold on the run starting from t + 1. Consider Example 2. Example 2. Consider the property: ψ = M1.p U (M2.q U M3.r) at time t, where p, q, r are all Boolean data attributes. We rewrite ψ as: ψ = (M3.r ∨ (M2.q ∧ X (M2.q U M3.r))) ∨ (M1.p ∧ X (M1.p U (M2.q U M3.r))) If the simulation at time t gives p = 0, q = 1, r = 0, then by substituting these values, the assertion monitor obtains the property X (M2.q U M3.r). At t + 1, it needs to check M2.q U M3.r. The same methodology is repeated on M2.q U M3.r at time t + 1. 2.4 The Integrated Framework Assertions in Action-LTL are written over the model attributes, specifically, the data members and events. Hence, to determine satisfaction/refutation of an assertion at a simulation step due to the model behavior, it is necessary to be able to sample values of the model attributes. In addition, the assertion monitor must be able to sense all the events dispatched in the model. Whenever an event is dispatched in the model, the verifier should be informed about the event, its parameters, if any, and its target. With inception of every event, the assertion monitor must check if the model configuration satisfies/refutes the desired specification. The assertion monitor must remember the context of verification; it must remember what has to be checked after dispatch of each event to certify correctness of the model at that point of time. We overloaded GEN,
A Dynamic Assertion-Based Verification Platform for Validation of UML Designs
227
Table 1. Results of DPV Module
No. of Project Sim. Time Sim. time Properties building time (without DPV) (with DPV) LIN 25 54 mins 12.9 mins 15.4 mins CMS 11 28.7 mins 7 mins 10.2 mins
to make the assertion monitor aware of any event transaction in the model. Whenever an event is dispatched in the original model, a copy of the event is instantaneously delivered to the assertion monitor. The assertion monitor has been implemented as a Rhapsody object with an embedded C routine. At every simulation step, on an event dispatch, the assertion monitor samples the data attribute values and checks for satisfaction/refutations. To read the values of the data attributes of each object at each simulation step, the assertion monitor object is integrated at the appropriate class hierarchy.
3 Results We deployed the DPV framework for the verification of two benchmarks, (a) an industrial implementation of the Local Interconnect Network (LIN) [4] protocol, and (b) an implementation of an access control mechanism in a web-based conference management system (CMS). The properties were extracted from the specification document. The dynamic ABV platform was tested on an industrial Rhapsody based LIN implementation and an in-house implementation of CMS. Table 1 shows the results obtained by our tool on a Pentium-4 with 1 GB RAM. Column 2 shows the number of properties. Column 3 shows the time required by Rhapsody in building the project. Column 4 shows the time required by the simulation platform to simulate the model without the assertion checking feature. Column 5 shows the respective times required when the assertion monitor is inserted inside the simulation platform for verifying properties. Results show that not much simulation overhead is incurred due to assertion checking.
References 1. Bhaduri, P., Ramesh, S.: Model Checking of Statechart Models: Survey and Recent Directions (2004) 2. Dasgupta, P.: A Roadmap for Formal Property Verification. Springer, Heidelberg (2006) 3. Harel, D., Kugler, H.: The Rhapsody semantics of Statecharts (or, On the Executable Core of the UML). In: Ehrig, H., Damm, W., Desel, J., Große-Rhode, M., Reif, W., Schnieder, E., Westk¨amper, E. (eds.) INT 2004. LNCS, vol. 3147, pp. 325–354. Springer, Heidelberg (2004) 4. http://www.lin-subbus.org/ 5. Object Management Group, Unified Modeling Language Specification, Version 1.4, Draft, OMG(2001), http://cgi.omg.org/cgibin/docad/018214
