A Software Environment For Custom Simulation And ... - IEEE Xplore

A Software Environment for Custom Simulation and Monitoring of Real-Time Specifications Monica Brockmeyer* Farnam J ahanian Elly Winner Department of Electrical Engineering and Computer Science University of Michigan Ann Arbor, MI 48109-2122 {monicab,farnam,ewinner)@eecs .umich.edu Abstract

Ability to support plug-in viewers. The simulator should support alterna.tive representations of the simulation tra.ce. That is, users should be able to plug in viewers which are most approp r i d e for the specification under considerat,ion. Some views of simulated system behavior show t,he sta.te of the system at, a given time point, while ot,hers display the syst,em behavior as a function of time.

Introduction

Because high-assurance systems have many complex requireinent,s. including timeliness, dependabilit,y. and securit,y, t,hese systems a,re a.mong t,hose most, likely- to benefit from t.lie applicat.ion of formal specificat,ion met,hods. Several st.udies have shown that t,he cost of detecting and removing software errors increases significant,ly as the development, process moves from requiremenh specificatmiontoward implementat,ion [6]. Other st,udies have demonstrated that errors in t,he requirement,s specification are the most frequent cause of soft.ware errors and t,he most expensive t.0 correct, [2].

Interactive user participation in generating a simulation trace. The user should be able to

cont,rol t,he siniulat'ed syst,em behwior. In pa.rticu h r , when t,he system behavior is nondeterministic, the user should be able to select the desired behavior. One way to support, this is to permit the user to inject events int,o the execution trace.

*This work is supported in part. by t.he Naval Research Laborat ory iirider Grant N0001494P2015.

0-8 186-797 1-9/97 $10.00

1997 IEEE

Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC 20375 {heitmeyer,labaw}Oitd.nrl .navy.mil

To effectively detect errors in specifications of practical systems, specification languages and verification techniques must be complemented with software tools that are robust, flexible, and integrated [5]. Among the tools effective for testing and debugging specifications early in the design process are szmulators, which allow the user t,o generate and examine symbolic executions of the system under development. Simulation is even more effective if based on a formal specification. Further, the utility of simulation as an analytic technique increases as systems become larger and more complex, since large, complex systems are usually less amenable to formal verification. A siniulator that supports testing and debugging of formal specifications must satisfy a number of requirements :

T h e testtng and valadatzon of f o r m a l speczficatzons of hzgh-assurance real-tzme systems repiizres a n ertenszble szniulatzon enrwonment wzth support f o r users t o generate events, customzze dzsplays and monzt o r c w n t traces Thzs paper descrzbes MTSzm an customzzable szmulation platform f o r the Modechart Toolset ( M T ) MTSzm prozlzdes support f o r "pluggzng zn" user-defined vzeu'ers as well as user partactpataon i n the generatzon of szmiilatzoiis by allowtng users t o znject events znto f h e erecutton trace Moreover, M T Szm provzdes rnonitorzng and assertion checkzng of eaecutzon traces and the zntiocatzon of user-speczfied handlers upon assertzon vzolatzon Thzs paper also zntroduces a MTSzm component called WebSzm. a suzte of simulation iools f o r MT. n n d n n applzcntzon-speczfic component of MTSzm, whzch dzsplays f h e cockpzt of an F - I 8 azrcraft and models zts bomb release functzon

1

Constance Heitmeyer Bruce Labaw

Monitoring/Assertion-checking. Most. mon-

78

not found in research prototypes, e.g., -version management and support for splitting specifications into multiple documents. The STATEMATE user can invoke a variety of static queries about the system specification. STATEMATE also provides a reporting language and a query language based on conjunctions and transitive closures. One of the most powerful capabilities of STATEMATE is the Analyzer tool. This tool provides extensive user control over system simulation, including a simulation control hnguage, attachment of watchdog code for monitoring purposes, and connection of external C code to the symbolic execution. In an approach similar to our monitoring and assertion checking technique, these executions can be monitored via special "watchdog" code which is defined by the user in the Statecharts language. There is no automatic generation of watchdog code. It is also possible to set, breakpoints in the Statechart code. The Cabernet tool [13] provides a formal framework for developing real-time systems based on a temporal and functional extension of Petri Nets. The main components of this tool are a graphical editor, a suite of execution/animation/simulation tools which provide symbolic execution of the Petri net with an animated graphical display in real-time, and a reachability graph builder, a tool for mana,ging hierarchical specification and decomposit.ion of specifications. The semantics of Cabernet is defined by TRIO [7], a language developed specifically to support executable specifications and simulation. The Software Cost Reduction (SCR) toolset, SCR*, supports specification and analysis of requirements in the tabular SCR notation [ll].The tools provide completeness and consistency checking [lo] specification editing. simulation, and mechanical verification[l]. The SCR notation may he used to specify the required system functions a.s well as the required system timing and accuracy.

itoring too$ only allow the user to set simple breakpoint,s~ or to detect the occurrence of simple events. A T o r e powerful option is to design the simulator to support user specification of complex asserti ns in a high-level language and to aut,oma,ticaly monitor the a.ssertions during simulation. 1

P

0

Separatiod of simulation mechanism from policy and^ display. To facilitate changes to the simulator, the simulation engine should be separate from bdth the policy t.hat guides a simulation session and ithe visualization tools.

This paper hA,s two objectives. First, it describes MTSim, a powedful and flexible approach to simulatbased on formal specifications, satisfy the above requirements. Second, the papbr demonstrates the power and flexdescribing a suite of simulation as MTSim clients. a tool for testing specifications, as well a.s an application-sbecific interface for modeling the becockpit. This interface provides an mimics the physical appearance of a.n F-18 cockpit. MTSim has deen developed within the context of the Modechart olset (MT) [4], a collection of integrated t.ools devyloped by researchers at the Naval Re-

4 P

checking, simu-

~

sizing those designed for real-time systems. Section 3 describes t,he cliebts we have developed for the MTSim

3

This sect,ion r views various formal methods for developing real-ti e systems with a pa.rticular emphasis 011 t,ool support. Several researchers have noted the need R for e" '""k 't,ool support for these approaches, e.g. [ 5 , 91. The STATETATE system [8], which has been widely employe in industry, has many capabilities

This section describes several prototype MTSim clients. Each client, supports one of the main tasks required of an industrial-strength specification and simulation environment, namely flexible displays, event injection, and monitoring and assertion checking. In addition, the t.ools demonstrate that the MTSim framework is suitable for the development of both general-purpose and application-specific display tools. Client tools built upon the MTSim framework are likely to require several key functions. Some clients will only need to register for event notifications in order to display the simulation behavior. Others may want to participate in the simulation behavior by gen-

79

MTSim Clients

monitoring and assertion checking Modechart specifications, see [3]. Monitoring and assertion checking can be used to detect undesirable behavior or an assertion violation as an execution trace is generated. By combining evaluation of a property with a graphical representation of the execution trace, the monitoring and assertion checking tool can work together wit8hother simuhtion tools to display the system behavior represented by the formal Modechart specification. The user can observe this simulated behavior to ensure that it captures his/her intent. A monitoring and assertion checking tool can also invoke user-defined handlers upon the detection of certain properties. The handlers can be used t,o change the simulator execution profile or even the system state before the simulation resumes. The user can specify assertions in two different ways:

erating events to inject into the simulation trace. Finally? a client may need to start and stop a simulation and t.0 instruct the MTSim Server which specifica,tion to simula,te. Corresponding t,o tjliese roles, t,he Client, API support,s three types of clients, which are distinguished in ternis of t.he level of privileges granted to t,hem by the MTSim Server. A controller client has the most extensive set of simulator operations and is responsible for initiating a simulation session, indicating t,o the MTSim server which Modechart is to be siiiiula.ted,and establishing simulation options and defaults. Controller clients may also perform all of the operat,ions which can be performed by the other types of clients. Once a controller client has initia.ted a simulation session, other types of clients may at,tach to that session. These clients, which perform more basic operat,ioiis are display c1ient.s and participants. Display clieiit,s are the most basic type of client. They may at,tach to a simulation session, register to receive simula.t,ion not,ificat,ions, and detach. Pa.rticipant clients have t,he privileges of display- clients, but, may also generate events which a.re submitted t.0 the MTSim Server for execution. The client, tools supported by MTSim include WebSim, a suit.e of graphical, simulation tools implemented a.s Java Applets on the MTSim Client API, and a n F-18 int.erface.

3.1

The user can use a subset of Real-Time Logic to specify assert,ions. These assertioiis are specified via a graphical, form-based interface. The user writes the relevant information into a template of a.n RTL formula and is thus not required to write RTL formulae from scratch. The WebSim Monitor supports flexible specification of assertions by automatically translating RTL assertions into Modechart moniforing fragmen,ts in order to provide a specification for the monitoring process. The monitoring fragment,s, expressed as Modechart specifications, are used to represent the assertions of interest. The MTSini Server produces an execution t,race of tlie augmented specification. The monitoring fragment is symbolically executed together with the original specification generating an execution trace tshat highlights the violation of the original assertion. As a. result,, detection of the viohtion of a potentially complex assertion is reduced to detect.ion of a simple event or set of events in the simulation of t8hemoiiit,oriiigfragment.

WebSim

WehSim permit,s a specification designer to view, ma.nipulat.e,and analyze a specification from a variety of viewpoint,s. Below. we provide a.n overview of the WebSiin Coiitroller, discuss the support that the MTSim API provides for monitoring aiid assertion checking, aiid describe t,liree types of general-purpose displays WebSim provides aiid how the MTSim Client API supports flexibk disphys. 3.1.1

The WebSim Controller

The controller init,iat.es a simulation session, loads Modeclia.rt,s, a i d sta,rts and stops simulations. The cont,roller also sets simulat.ion para.meters. This perniit,s the client to indicate values when the specification is incomplete or to instruct, tmhesiniulat,or about how t,o handle noiidet,erniiiiisrn. 3.1.2

0

The WebSini Monitor

The FVehSini Monit,or performs nionit,oring and assertion checking. For a description of our approach t.0

80

The user can also specify assertions directly by representing the monitoring fragments in Modeclia.rt. This a.llows maximum flexhilitmyin tlie kinds of properbies t,ha.t can be monit,ored. The monit,oring fragment,s can he developed in t,he specification editor in the same ma.nner as ordinary Modechart, specificat,ions. The only important difference is t,hat. the user must identify to the WehSim Monitor t,hose events which represent. assertmionviolations.

be based on the interface to t,he original Modechart Toolset Simulator, which is illustrated in Figure 2.) Each bar indicates the behavior of one mode, transition, or external event over time. Time is indicated by the horizontal axis. Thick lines indicate the periods of time during which each mode is active. This type of display gives a good summary of the behavior of the system over time but does not provide a "snapshot" of the system. Thus, the Animator and the Time Process client are highly complementary.

pausing or stopping the simulamessages, event logging,

tions.

3.1.3

Generic1 Viewers: WebSim Displays

Figure 2: Timeprocess Display

3.2

Fig&

Application-Specific Tool: An Interface for an F-18 Cockpit

1: TVebSim Animator three types of displays. The first [ll].The second display, an view of the simu-

I-

-x

t "5 Figure 3: F-18 Cockpit Simulation Interface

81

interface into MTSim as a client. We designed the client a.s a controller client, which loads the specification and starts the simulation before the panel is displayed. We made one change to the graphical interface itself, adding a button and a text display a.t the bottom of the screen to display the time and to permit the user to advance the time. Because the TAE+ toolkit does not generate Java code, we wrote a Java wrapper and integrated the generated C code into Java as a native method. The original C code was modified to invoke the standard MTSim Client API. We developed two Java classes, Main and Cockpit. Main is the class which launches the application and performs initialization. The Cockpit class implements the ClientEventHandler interface and responds to event notifications sent from the MTSim Server. The notify method calls native methods to update the F-18 interface in response to event notifications.

To demonstrate the power and flexibility of the MTSim Client API, we integrated an existing interface for an F-18 cockpit into the MTSim framework. We had several goals in developing this client. First, we wanted to test the usefulness of the MTSim framework for implementing applicat,ion-specific client,s. Beca.use such clients are used in specialized roles, we felt that a rapid and st,raight,forwarddevelopment process was desirable. Second, we wanted to demonstrate a,n MTSim client which participated in the simulation by generating events to be incorporated into the simulation trace. And finally, we wanted to evaluate how easily existing software could be incorporated into MTSim. The F-18 cockpit interface was developed by NRL researchers as an interface to the SCR* Toolset [ll] aiid was implemented in Motif using Century Computing’s TAE+ interface builder The purpose of the interface is to mimic the externally visible behavior of the cockpit of a Navy a.ttack aircraft during a bomb release mission. In particular, the interface helps simulates the bomb release function of an F-18. The F-18 interface, shown in Figure 3 , “participat.es” in the simulation process. The user, interacting with the simulation interface, provides the system inputs (provided by the pilot and t8heexternal environment in the real-world system), while the MTSim Server simulates the system response to these inputs. It, is possible t80use the F-18 interface together with other display tools to provide additional information to the user. The bullseye in the center of the windshield can be moved to indicate the miss distance (the projected dist,ance from bomb inipact point*to the target). The small plane icon in the upper right corner can be used to indicate whether the plane has overflown its target. The Master Function Switch is modeled with a pop-up selector on the left panel, while the right panel displays t,lie stations which cont,ain a bomb. On the throttle, tthere are two pushbut,tons. One is used to designate a t,a.rget. If a. t.arget is locked onto, the words “Target Designated” appear under the target. The ot,her pushbutton is used to release the bomb. If all conditions are correct for a bomb to be released the bomb is re1ea.sed upon pushing t,he bomb release button. In this case the words “Bomb Released” appear on top of the plane icon in the right panel. Reengineering the SCR version of the F-18 interface for MTSim involved two steps. First, the formal SCR specification for bhe bomb release mechanism was translat.ed into Modechart. (A discussion of the t,ransla,t.ion is beyond t,he scope of this paper.) Second, after translating the formal specification, we integrated the

4

MTSim Architecture and Design CLIENT

SERVER

weor code

Client API

ll Figure 4: Overall Architecture of MTSim Figure 4 illustrates the three major parts of the MTSim architecture: the server, the MTSim Client Stub and MTSim clients. The MTSim Server is responsible for generating execution traces consisteiit with the Modechart specification. It also accepts connections from clients, satisfies requests froin clients and reports the simulation events back to the clients. The MTSim Client Stub provides an easy-to-use programming interface to facilitate development of a variety of simulator clients. This interface permits a client to attach and detach from a simulation session, set simulation options, inject simulation events into the event stream, synchronize with the MTSim Server, and request notification of event occurrences. Both general-purpose and application-specific clients can be built using the MTSim framework The MTSim Server is implemented in a combination of Java and C. Simulation databases and code per-

82

These C libraries are wrapped in Java, where they are native functions. This approach maintains compatibilit8ybetween MTSim a,nd other tools in the Modechart Toolset which have been written in C.

Modechart Toolset simulator,

4.2

The MTSim Client Stub

The MTSim client stub is the mechanism through which MTSim clients communicate with the MTSiin Server. The client, stub has two main components, a Client Request Manager and a Client Event Notifier. The client program invokes the methods included in t,he APT o n - t h e client stub. The client stub translates these into messages which are sent to the MTSim server. The client stub reads reply messages from the server to determine the return value and whether an exception needs to be thrown to the user code. The only state maintained by the client stub is held by the Client Event Notifier. When the user submits a request for an event, notifica.tion to the MTSim Server, the MTSim client stub maintains a callback object for that request. When an event notification is received by the client stub, the Event Notifier invokes the notify method on the appropriate callback object.

ation Manager, the sions and attaches Session Manager also instantianagers for each client as they attach to a sew Managers coordinate with the respond to client operations as operations are generally in core client class pro-

5

MTSim Client API A typical scenario for using the API in a client pro-

gram is as follows:

1. Attach to a simulation session. The client program creates a client object. The client then uses the Attach method of the newly created client object to attach to the MTSim Server, indicating the MTSim server and a session name in the URL string.

tialize the simu strearn. This

is determined by the Event Noe been submitted by the client.

2. Register for event notifications. After at-

of these Event rences for whic

taching, the client process will generally register MTEventPatterns with the server using the method RegisterForNotification. In doing so, the clients indicate to the server the simulator events for which they would like to receive notification. The MTEventPatterns class provides a powerful approach to specifying individual Modechart events or groups of events. The client program also indicates whether the server should synchronize with the client when the specified event occurs. If synchronization is requested for certain events, upon generation of those events, the server will wait for the client to invoke the Continue method before proceeding with the simulation. Finally, the client provides an object which implements the ClientEventHandler interface. Upon receipt of an event notification which matches the MTEventPattern, the client object will perform

cations may be for event occurclient has asked to synchronize

0nent.s are writ.ten in Java with

83

ratory who developed the graphical F-18 cockpit interface.

a callback to the client by invoking the notify method of the ClientEventHandler object.

References

3 Begin a Modechart simulation. Controller clients will then generally invoke a LoadModechart method, and optionally set the simulation options using one of the SetSimOptions methods. They will then start the simulation using the Start Simulation method.

Ramesh Bharadwaj and Constance L. Heitmeyer. Verifying scr requirements specifications using state exploration. In Proceedings of First A C M SIGFLAN Workshop on Automatic Analysis of Software, January 1997. Software Engineering Economics. B. Boehm. Prentice-Hall, Englewood Cliffs, NJ, 1981. M. Brockmeyer, F. Jahanian, C. Heitmeyer, and B. Labaw. An approach to monitoring and assertionchecking distributed real-time systems. In Workshop o n Parallel and Distributed Real- Time Systems, April 1996. P. C. Clements, C. L. Heitmeyer, B. G. Labaw, and A. T. Rose. MT: A toolset for specifying and analyzing real-time systems. In Proc. I E E E Real- Time Systems Symposium, December 1993. D. Craigen, S. Gerhart, and T. Ralston. An international survey of industrial applications of formal methods. Technical Report NRL-9581, Naval Research Laboratory, Washington, DC, 1993. D.A. Gabel. Technology 1994: Software engineering. IEEE Spectrum, 31(1):38-41, january 1994. C. Ghezzi, D. Mandrioli, and A. Morzenti. TRIO, a logic language for executable specification of real-time software. Journal of System Software, 12, 1990. D. Ilarel et al. STATEMATE: A working environment for the development of complex reactive systems. I E E E Trans. Software Engineering, SE-16, April 1990. C. IIeitmeyer and D. Mandrioli, editors. Formal Methods for Real-Time Computing. John Wiley and Sons, 1996. Constance L. Heitmeyer, Ralph D. Jeffords, and Bruce G. Labaw. Automated consistency checking of requirements specifications. A CM Trans. on Sqftware Eng. and Methodology, 5(3):231-261, July 1996. Constance L. Heitmeyer, James Kirby, and Bruce Labaw. Tools for formal specification, verification, and validation of requirements. In Proceedings of 12th Annual Conference on Computer Assurance (COMPASS '97), June 1997. F. Jahanian and A. I(. Mok. Modechart: A specification language for real-time systems. IEEE Trans. Sqftware Engineering, 20( IO), December 1994. D. Mandrioli. A. Morzenti, M. Pezze, P. SanPietro, and S. Silva. A Petri net and logic approach to the specification and verification of real time systems. In C. Heitmeyer and D. Mandrioli, editors, Formal Methods f o r Real- Time Computing, chapter 6. John Wiley and sons, 1996.

4 R,eceive event notifications. While the simulation is running, the server will generate event notifications in the form of MTEventOccurrence objects and send the notifications to the various clients. T h e client will be notified as described above and will use the notifications to update its display or perform any relevant computations.

5 Stop the simulation.

At some point the controller client will issue the StopSimulation method, and the various client,s will detach themselves from the simulation.

6 Request a Modechart. Any client may get a static representation of the loaded Modechart by issuing the GetModechart method at any time.

6

Conclusions and Future Work

This paper has described MTSim, an extensible simulation framework for formal specifications. This infrastructure supports a customizable environment for simulation, permitting users to plug in specialized viewers and other simulation tools including monitoring and assertion checking tools. We have also presented several tools developed using the MTSim framework, including SVebSim, a. suite of general-purpose monitoring tools which execute on the World Wide Web in the browser environment and a free-st anding application-specific simulation interface which models the cockpit of an F-18 aircraft. We have several goals for advancing the MTSim fra.mework. Among these is support for persistent simulat,ion sessions, which will include development of a model for logging and replay services. In addition, we hope to get feedback from users of the WebSim tools, as well as investigate other types of monitoring (such as performance monitoring) and to extend the types of assertions supported by the WebSim monitor. Finally, we plan to evaluate the use of the MTSim framework to support,simulattionof otrherformal specification languages, such as SCR.

Acknowledgements We would like to acknowledge the contributions of Eylon Caspi and others at the Naval Research Labo-

84