Control Engineering Practice 6 (1998) 417—420

Time-stamped event histories: a real-time programming object

Alan Shaw*

Department of Computer Science and Engineering, University of Washington, Box 322350, Seattle, WA 98195-2350, USA

Received October 1997; accepted December 1997

Abstract

A case is made for providing direct support for time-stamped event histories (TEHs) in real-time programs. The paper describesa notation for TEHs, gives some programming examples, discusses an implementation, and concludes with some research issues.( 1998 Elsevier Science Ltd. All rights reserved.

Keywords: Events, real-time languages, time, programming support

1. Introduction

Time-stamped event histories (TEHs) are sequences ofevents ordered by time. They provide a description of thebehavior of a real-time system in terms of traces of its‘‘interesting’’ events. TEHs have been used as the basisfor the assertional verification, debugging, logging, andmonitoring of real-time systems. For these purposes, theyare employed both for the specification of requirementsand designs, and for the run-time examination of execut-able specifications and actual implementations.

The main insights are that there should also be benefitsin using TEHs directly for programming applications,and that support for TEHs should be defined and in-tegrated into real-time programming languages. Asser-tions on TEHs can be used in operational languages asguards or Boolean expressions to control or enablenormal computational actions, and to check for un-usual conditions. Histories are also convenient in othertypes of expressions, for example, to compute future datavalues.

TEH-like entities have certainly been used directly inprogramming in the past, but in an ad hoc manner.With conventional methods, histories are implicitlyembedded as part of the location state of a program,and explicitly maintained through variables and calls to

*Corresponding author. shaw@cs.washington.edu FAX: (206) 543-2969

timers. The contributions of this paper include definingappropriate TEH support mechanisms and outlininga variety of generic applications of TEHs in real-timeprogramming.

The direct application of TEH data in programmingwas proposed in a monitoring paper (Chodrow et al.,1991); the authors show how embedded timing con-straints can be employed for synchronous monitoring,but the more general idea has not been developed. Thework reported here has been stimulated by this run-timemonitoring research, as well as the monitoring work in(Raju and Shaw, 1994).

A new programming model, called time-sensitive ob-jects (TSOs), has also influenced this research (Callison,1995). It employs histories in a central way, usingtime-ordered validity intervals for data. TSOs offer adata-centered model for real-time programming, as analternative to the traditional process-centered model, andinclude a very general set of operations that is wellbeyond the mechanisms proposed here; for example, anoperation to extrapolate a future data value.

Some programming languages do support TEH-likeentities; however, the TEH abstractions are not straight-forward, and the languages are relatively exotic. The R¹

synchronizer scheme proposed within the real-time actormodel maintains those time-stamped message historiesneeded to check on invocation constraints expressedin a pattern language (Ren et al., 1996). LUSTRE(Halbwachs et al., 1991) and SIGNAL (Le Guernic et al.,1991) are two ‘‘synchronous’’ real-time languages thatassociate logical or real times with every data element in

0967-0661/98/$19.00 ( 1998 Elsevier Science Ltd. All rights reservedPII S 0 9 6 7 - 0 6 6 1 ( 9 8 ) 0 0 0 2 0 - 3

a program. LUSTRE is a data-flow language andSIGNAL is equational. These are elegant and inter-esting languages, especially for specifying some com-putations, but it is not evident that they can be usedfor large systems, or that the synchrony hypothesis ispractical.1

The TEH ideas first appeared in (Shaw and Rupp,1996). Since then, the notation has been refined, fur-ther experiments have been done, and an initial analy-sis of the real-time behavior of TEH mechanisms hasbeen performed. This work is described in the followingsections.

2. Defining and using TEHs

A TEH object is a finite, time-ordered, sequence of(event-type, value, time) triples

H"SX1,2 , X

nT"SX

~n,2 ,X

~1T ,

where each event Xi"(E, », ¹ ). E is the type or class of

the event, » denotes its value (optional), and ¹ is the timeof occurrence. Generally, events correspond to logicallyinstantaneous points in the execution of a system. Exam-ples are inputs, outputs, and communications; controlpoints in a program; and invocation of program opera-tions. For example, the following event

X"(Position, (25, 34), 8)

is of type Position, has a data value of (25, 34) (e.g., an(x, y) coordinate pair), and occurred at time 8; X wasobtained perhaps through a sensor.

A history is defined during program execution, andextends up to the most recent event X

nthat has occurred.

It is convenient to refer to the most recent events usingnegative subscripts. Thus X

~1denotes the most recent

event, and for positive i, X~i

is the ith most recent eventand X

i"X

i~n~1.

Only a finite window of H is maintained, the mostrecent m events. If more than m events have occurred,then the early events are lost. (Of course, they could havebeen copied to some other storage area if they were to beneeded in the future.)

Various projections or restrictions on a history can bespecified. In particular, it is useful to examine historiesthat include or exclude events from designated classes

1One of the basic assumptions of the synchrony hypothesis is thatcomputation steps take zero time. To this writer, this assumption seemsto define away one of the most difficult problems in real-time program-ming; that is, how to monitor and enforce the correct timing behavior ofcomputations that run on real processors.

(event-types). The notation is of the form H/K:

H/(C1,2 ,C

k): Include only events from classes

C1,2 ,C

k.

H/&(C1,2 ,C

k): Exclude events from classes

C1,2 , C

k.

When a history or projection H/K is declared (forexample, at initial program entry, upon activating a task,or upon entering a code block), the history is initializedto the empty sequence. Let E¹ be the set of event-typesdefined by H/K, to be included in the current history.

Whenever an event X occurs, it is appended to thecurrent history sequence, provided that its class is in E¹.The event type, value, and time components of an eventX

~iin a history are accessed using straightforward sub-

script indices as E~i

, »~i

, and ¹~i

, respectively. Becauseit is used frequently, a special syntax has been devised torefer easily to sequences of recent events. In its moststraightforward form, the notation

E( )"(C~k2

C~1

)

is an abbreviation for

(E~k

"C~k

)?,2 ,?(E~1

"C~1

).

This can be viewed as a Boolean function that returns‘‘true’’ if the last k events are from the classesC

~k,2 , C

~1starting from the kth most recent one.

Two additional conveniences are employed. First, anyof the C

~iin these lists can be a ‘‘wild card’ or ‘‘don’t

care’’ indicator, denoted by an asterisk. And finally, theabsence of an event at a particular position in the currenthistory is denoted by preceding its name by a ‘‘&’’symbol. For example,

E( )"(DiskIO,&¹emperature, *, Printer)

would evaluate to true only if the most recent event in thecurrent history was of Printer type, the second-last eventwas of no interest, the 3rd most recent event was not fromthe ¹emperature class, and the 4th last event belonged tothe DiskIO event-type.

3. Programming with TEHs

A number of example programs are presented in (Shawand Rupp, 1996). In this section, programming applica-tions are presented and classified, some further examplesare given, an implementation is described, and the timingcomplexity of TEH objects is discussed. There are severalareas in programming where TEHs appear particularlyuseful. One standard application is event logging. Finite-size recent histories of selected sets of events are collectedin a block or module, initialized by an H/K declaration

418 A. Shaw/Control Engineering Practice 6 (1998) 417—420

that specifies the current event types of interest. Thehistory can periodically be written to secondary storage.Typically, such a log is used for later off-line analysis.

A more interesting area is in generating exceptions.The conditions that cause exceptions are frequentlystated most conveniently as assertions on histories. Forexample, a short burst of interrupts or messages may bethe sign of a system overload. Suppose, for example, thatan overload is defined whenever 3 successive events fromclass Interrupt3 occur, with time less than delta separat-ing successive events. The overload should raise an ex-ception of type O»ER¸OAD, resulting in a transfer to anexception handler. (Ada-like jargon is being used.) As-suming that only the Interrupt3 history is kept, declaredby H/(Interrupt3), the code might be:

if ((T(!1)!T(!2))(delta) and

((T(!2)!T(!3))(delta) then raise OVERLOAD.

Without TEHs, the programmer would need to recordexplicitly the time of each interrupt, say by callinga Clock function and defining variables such as t—last,t—2nd—last, and t—3rd—last to hold the last three inter-rupt times.

A third application is in computing new data values.An example is the computation of a velocity based on thelast two Position events. If the history is restricted toH/(Position), the computation is simply:

Velocity.x :"(V(!1).x!V(!2).x)/(T(!1)

!T(!2));

Velocity.y :"(V(!1).y!V(!2).y)/(T(!1)

!T(!2));

where»elocity and » are both records with x and y fields.The computation could also be accomplished by expli-citly calling a Clock function when each Position eventoccurs and maintaining variables such as oldtime, new-time, oldx, newx, oldy, and newy, but this is tediousand error-prone. With TEHs, this housekeeping is doneautomatically.

The most common use is in guards that control normalcomputational actions. A variation of a favorite butsurprisingly difficult mouse-clicker problem will be usedto illustrate some aspects of programming style. Theproblem is interesting also because it is concerned almostexclusively with histories of events and handling timingconstraints correctly.

The program is to classify sequences of events froma single-button mouse, distinguishing among singleclicks, double clicks, and selections. The input from themouse can be either a D event (pressing the button) ora º event (releasing the button). If the time betweenD and º is less than tsc then a single-click event (SC) isdefined. If a single-click event is followed by anothersingle-click event with a separation time of less than tdc

between the first º and the second D, then a double-clickevent (DC) is also generated. Successive double-clickscannot overlap or share a single-click. Finally, if thesingle-click constraint is not met, a selection event (SS) isgenerated at the º.

The program uses the history H/(D, º, SC, DC, SS).Events are generated and received synchronously, fol-lowing the CSP model (Hoare, 1984). A ‘‘! ’’ denotes anevent generation (send message or output); the ‘‘? ’’ sym-bol means to accept an event (read message or input). Ifevent output and input occurs between a sender andreceiver, then it occurs simultaneously. The code for theclick classifier is:

— — Recent history E( ) and T( ) is assumed to beinitialized.

loopD? U? — — Accept a D and U event in order. Now,

E( )"(D, U).if (T(!1)!T(!2))(tsc thenbegin SC! — — Generate an SC event.

E( )"(D, U, SC).if (E(!4)"SC) and (T(!3)!T(!5))(tdc — — E( )"(D, U, SC, D, U, SC).then DC!

endelse SS! — — Generate a selection event.

end.

The claim is that the code more closely resembles theproblem specification than a program written in a stan-dard language. Programming this by more conventionalmeans requires either calls on a Clock function and theuse of variables to record time histories, as in the pre-vious examples, or a timeout mechanism with non-deter-ministic constructs, as employed in some of the solutionsto other versions. This is also a case where a conventionalprogram version is most naturally designed as a statemachine with the history embedded implicitly in thestates. The other notations, such as E( ), ‘‘&’’, and ‘‘*’’,have been convenient for other versions of this problemand other examples.

TEHs have been added directly to the language andsimulator for communicating real-time state machines(CRSMs) (Raju and Shaw, 1994), and many exampleshave been implemented and tested. Events are defined tobe input—output occurrences between machines, much asin the CSP-like communications above. The program-ming notation includes all of the facilities described in thelast section — history restrictions H/K, the E ( ) functions,and the event field access functions. Problems of theabove kinds resulted in more attractive programs withthe extended notation — more compact, elegant, andmore obviously following the specifications. However,TEH support does not seem to be useful for that class ofevent-oriented problems where only the most recentevent is of interest.

A. Shaw/Control Engineering Practice 6 (1998) 417—420 419

TEHs were implemented in a straightforward but notvery efficient way on top of the CRSM system, startingwith some code previously used for assertion monitoring.However, there also exists an efficient, predictable, andstill straightforward implementation. The basic historydata structure is a circular array, with the addition of anindex pointing to the most recent element of the historyH, one pointing to the oldest event in H, and a size field.Operations to add a new event to H and to access the ithmost recent event can all be done in constant time. Whenan event occurs, it is time-stamped by calling a Clockfunction, a constant time operation, and added to H if itis in E¹. A Boolean variable associated with each event-type can indicate whether or not the type is a member ofE¹; whenever E¹ is redefined with an H/K, the variablesare set to their appropriate truth values, an O(n) opera-tion where n is the number of event classes.

4. Some research issues

Current work is mainly addressing some questions inprogramming and applications. It has been assumed im-plicitly that the universe of interesting events is pre-de-fined for a particular system, and that H/K just imposesrestrictions on this universe. A more flexible approachwould permit the declaration or definition of events. Forexample, it would be useful to declare a particular pro-gram control point, such as the entry to a procedure, asan event class. Another useful facility is one to generatean event of a specified class at some future time; this isa generalization of a timeout, since there could also besome data, such as the value of a variable, associated withthe event.

The first experimental implementation involved graft-ing TEHs onto a graphical state machine simulator sys-tem. A textual programming language seems a morenatural environment. It is therefore of interest to extendsome contemporary real-time programming language,using its object features. Ada 95 seems the best candidateby far (Ada, 1995). This kind of extension will also allowa more precise analysis of the overheads of TEH support,and confirm that they can be searched and updatedefficiently, predictably, and deterministically.

A number of object-oriented languages and systemshave provided explicit support for concurrency and syn-chronization. More recently, real-time features, such astiming constraints and exceptions, have also been incor-porated. The cleanest solution seems to be to includesynchronization and timing constraints as part of guardsto operations, similar to Rtsynchronizers (Ren et al., 1996)and filters (Bergsmans and Aksit, 1996). The researchplan is to study the use of TEHs as part of the guardingportion. This should permit a more direct use of history,as well as providing simple solutions to real-time inherit-ance anomaly problems.

It is still too early to predict the range of applicationsof TEHs in real-time programs. More experience isneeded in experimenting with the ideas, especially onlarger applications. For some of the programs (forexample, variations on the mouse-clicker recognizer), itwas surprisingly challenging to arrive at an elegant solu-tion. The conclusion is that there is a new programmingstyle involved here, requiring some practice.

5. Summary

Programming support for time-stamped event his-tories, used in conjunction with other real-time features,can potentially result in more-readable and cleaner code,and programs that more closely resemble the specifica-tions. The result should also be more predictable, re-usable, and correct programs. The paper has describeda notation and implementation for TEHs, given someapplication examples, and discussed some next steps.

Acknowledgements

Doug Rupp implemented TEHs on top of the CRSMsystem, and collaborated on many of the initial experi-ments. This research was supported in part by the ArmyResearch Office under grant number DAAH04-94-G-0226.

References

Ada (1995). Annotated Ada Reference Manual, Version 6.0, Intermet-rics, Inc.

Bergmans, L., Aksit, M., 1996. Composing synchronization and real-time constraints. Journal of Parallel and Distributed Computing36(1), 32—52.

Callison, H., 1995. A time-sensitive object model for real-time systems.ACM Transactions on Software Engineering and Methodology 4(3),287—317.

Chodrow, S., Jahanian, F., Donner, M., 1991. Run-time monitoring ofreal-time systems. Proceedings of the IEEE Real-Time SystemsSymposium, pp. 74—83.

Le Guernic, P., Gautier, T., Le Borgne, M., Le Maire, C., 1991. Pro-gramming real-time applications with SIGNAL. Proceedings ofIEEE 79(9), 1321—1336.

Halbwachs, N., Caspi, P., Raymond, P., Pilaud, D., 1991. The syn-chronous data flow programming language LUSTRE. Proceedingsof IEEE 79(9), 1305—1320.

Hoare, C., 1984. Communicating Sequential Processes. Prentice-HallInt.

Raju, S.C.V., Shaw, A., 1994. A prototyping environment for specifying,executing, and checking communicating real-time state machines.Software-Practice and Experience 24(2), 175—195.

Ren, S., Agha, G., Saito, M., 1996. A modular approach to program-ming distributed real-time systems. Journal of Parallel and Distrib-uted Computing 36(1), 4—12.

Shaw, A., Rupp, D., 1996. Real-time programming with time-stampedevent histories. Technical report no. UW-CSE-96-05-02, Dept. ofComputer Science and Engineering, University of Washington.

420 A. Shaw/Control Engineering Practice 6 (1998) 417—420