21
Computer Languages 27 (2001) 93–113 www.elsevier.com/locate/complang Visual temporal logic as a rapid prototyping tool Martin Fr anzle , Karsten L uth Carl von Ossietzky Universit at Oldenburg, Department of Computer Science, P.O. Box 2503, D-26111 Oldenburg, Germany Received 27 April 2001; accepted 27 April 2001 Abstract Within this survey article, we explain real-time symbolic timing diagrams and the ICOS tool-box supporting timing-diagram-based requirements capture and rapid prototyping. Real-time symbolic timing diagrams are a full-edged metric-time temporal logic, but with a graphical syntax reminiscent of the informal timing diagrams widely used in electrical engineering. ICOS integrates a variety of tools, ranging from graphical specication editors over tautology checking and counterexample generation to code generators emitting C or VHDL, thus bridging the gap from formal specication to rapid prototype generation. c 2001 Elsevier Science Ltd. All rights reserved. Keywords: Requirement capture; Rapid prototyping; Temporal logic; Hardware synthesis 1. Introduction Due to rapidly dropping cost and the increasing power and exibility of embedded digital hardware, digital control is becoming ubiquitous in technical systems encountered in everyday life. Often, such embedded systems can hardly be altered once they have been shipped out due to extremely large quantities being shipped, or they even have to be right rst time due to their crucial impact on safety of human life. For example, modern means of transport rely on digital hardware even in vital sub-systems like anti-locking brakes, y-by-wire systems, or signaling hardware, as does medical equipment even in such critical applications as life-support systems or radiation treatment. This article reects work that has been partially funded by Deutsche Forschungsgemeinschaft under grants no. Da 205= 5-1 and -2. Corresponding author. Tel.: +49-441-798-3046; fax: +49-441-798-2145. E-mail address: [email protected] (M. Fr anzle). 0096-0551/01/$ - see front matter c 2001 Elsevier Science Ltd. All rights reserved. PII: S0096-0551(01)00017-0

Visual temporal logic as a rapid prototyping tool

Embed Size (px)

Citation preview

Page 1: Visual temporal logic as a rapid prototyping tool

Computer Languages 27 (2001) 93–113www.elsevier.com/locate/complang

Visual temporal logic as a rapid prototyping tool�

Martin Fr#anzle ∗, Karsten L#uthCarl von Ossietzky Universit�at Oldenburg, Department of Computer Science, P.O. Box 2503,

D-26111 Oldenburg, Germany

Received 27 April 2001; accepted 27 April 2001

Abstract

Within this survey article, we explain real-time symbolic timing diagrams and the ICOS tool-box supportingtiming-diagram-based requirements capture and rapid prototyping. Real-time symbolic timing diagrams are afull-4edged metric-time temporal logic, but with a graphical syntax reminiscent of the informal timing diagramswidely used in electrical engineering. ICOS integrates a variety of tools, ranging from graphical speci5cationeditors over tautology checking and counterexample generation to code generators emitting C or VHDL, thusbridging the gap from formal speci5cation to rapid prototype generation. c© 2001 Elsevier Science Ltd. Allrights reserved.

Keywords: Requirement capture; Rapid prototyping; Temporal logic; Hardware synthesis

1. Introduction

Due to rapidly dropping cost and the increasing power and 4exibility of embedded digital hardware,digital control is becoming ubiquitous in technical systems encountered in everyday life. Often,such embedded systems can hardly be altered once they have been shipped out due to extremelylarge quantities being shipped, or they even have to be right 5rst time due to their crucial impacton safety of human life. For example, modern means of transport rely on digital hardware evenin vital sub-systems like anti-locking brakes, 4y-by-wire systems, or signaling hardware, as doesmedical equipment even in such critical applications as life-support systems or radiation treatment.

� This article re4ects work that has been partially funded by Deutsche Forschungsgemeinschaft under grants no. Da205=5-1 and -2.

∗ Corresponding author. Tel.: +49-441-798-3046; fax: +49-441-798-2145.E-mail address: [email protected] (M. Fr#anzle).

0096-0551/01/$ - see front matter c© 2001 Elsevier Science Ltd. All rights reserved.PII: S 0096-0551(01)00017-0

Page 2: Visual temporal logic as a rapid prototyping tool

94 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

As, furthermore, many embedded systems are developed under tight time-to-market constraints, earlyavailability of unambiguous speci5cation of their intended behaviour has become an important factorfor quality and timely delivery.

Such a speci5cation is, however, always a compromise between various demands: ought it to beoperational, in order to guide developers and programmers in the implementation phase, or oughtit to be declarative in order to allow straightforward formulation of safety requirements, thus sup-porting safety analysis? Ought it to be formal, thus facilitating formal analysis and hence providingcorrectness guarantees that are not otherwise available, or may it be informal if this enhances com-prehensibility, thus simplifying traditional approaches for ensuring quality of software, like testingand certi5cation by code inspection?

Due to their prospects for reconciling some of these seemingly contradictory demands, graphicalspeci5cations have recently attracted much interest. Their prospects for gaining comprehensibility ofeven complex speci5cation are deemed so high that it should be possible to simultaneously further thelevel of formality without sacri5cing understandability. However, even with graphical speci5cations,the global interaction patterns of complex (for example, distributed) systems remain complex and,furthermore, it seems that graphical idioms also tend to hide some of the 5ne-grain semantics fromthe user, at least from the non-expert one. Thus, while being a big step ahead, graphical speci5cationformalisms are not per se a means for ensuring that “what you specify is what you mean”.

The problem of misconceptions in early development phases is, however, well-known in softwareengineering. A traditional remedy is rapid prototyping, where a partially developed product is broughtinto executable shape in order to assess its compliance with expectations. We suggest to take over theparadigm of “rapid prototyping” to the realm of formal, graphical, and declarative (i.e., intrinsicallynon-operational) speci5cations such that these become executable, thereby facilitating early evaluationof speci5cations on an operational model. If such a prototyping process is based on an unambiguoussemantics of speci5cations and applies rigorous rules for deriving executables from speci5cationsthen it can, furthermore, be made sure that the prototype obtained is in strict correspondence withthe speci5cation such that the evaluation is faithful.

In this article, we propose a method of that kind: it builds upon a fully formal semantics ofspeci5cations and applies automata-theoretic constructions for fully automatically deriving operationalsystems that represent the speci5cation in a “what you specify is what you get” way. The method hasbeen developed and implemented by the computer architecture group of Oldenburg University, whichhas dedicated part of its rapid prototyping project ‘EVENTS’ [1] towards automatic prototyping ofembedded control hardware from fully formal speci5cations given as real-time symbolic timingdiagrams. Real-time symbolic timing diagrams (RTSTDs, for short), as introduced in [2], are agraphical formalism for specifying behavioural requirements on hard real-time embedded systems.They are a full-4edged metric-time temporal logic, but with a graphical syntax reminiscent of theinformal timing diagrams widely used in electrical engineering.

In Sections 2 and 3, we introduce real-time symbolic timing diagrams and give an overview overthe ICOS tool-box supporting requirements capture and rapid prototyping using RTSTDs. As theICOS approach to rapid prototyping is based on synthesis of embedded control hardware—most fre-quently 5eld-programmable gate arrays—satisfying the speci5cation, we then turn to game-theoreticmethods of controller synthesis. Section 4 introduces the controller synthesis problem, and Section 4.1outlines a classical controller synthesis framework based on the eOective correspondence of proposi-tional temporal logic to 5nite automata on in5nite words and on the theory of !-regular games [3].

Page 3: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 95

Fig. 1. A requirement for a light controller, speci5ed as an RTSTD. The perpendicular line to the far left indicatesthe activation mode of the diagram, which here is the so-called invariant mode, meaning that the diagram has to applywhenever its activation condition 5res. The activation condition is the state condition crossed by the perpendicular line, i.e.reset scene=‘0’∧ motion sensor=‘0’. The solid arcs represent strong temporal constraints on the allowed evolutionof the system, while weak constraints (i.e., assumptions on the environment) are printed as dashed arcs.

A compositional variant of this approach, which is more suitable for rapid prototyping purposes dueto its reduced complexity, is shown in Section 4.2. This is our current synthesis method, which hasbeen fully implemented in the ICOS tools [4,5]. The results obtained using this method on e.g. theFZI production cell [6] indicate that the compositional extension yields a signi5cant enhancement forreactive systems, yet a further compositional treatment of timing is necessary for real-time systems.Section 4.3 sketches the basic design decisions underlying such an extension which is currently beingimplemented for a new release of ICOS, while Section 5 compares this to the state of the art.

2. Real-time symbolic timing diagrams

The RTSTD language [2] is a metric discrete-time temporal logic with an intuitive graphical syn-tax reminiscent of the informal timing diagrams widely used in electrical engineering, and with adeclarative semantics which was originally formalized through a mapping to propositional temporallogic (PTL). In contrast to some other approaches using timing diagrams, e.g. those described in[7,8], symbolic timing diagrams do not have any imperative control structure like iteration or se-quencing. Instead, the recurrence structure of RTSTDs is expressed in terms of the modalities oflinear-time temporal logic, thus providing a direct logical interpretation. In fact, RTSTDs providea declarative rather than an operational speci5cation style, even despite their intuitive syntax: anRTSTD is interpreted as a constraint on the admissible behaviours of a component, and a typicalspeci5cation consists of several small RTSTDs, with the individual constraints being conjoined. Themain consequence is that RTSTDs are well-suited for incremental development of requirements spec-i5cations. However, they pose harder problems than more operational timing diagrams when usedas source language for code generation. Fig. 1 shows an example RTSTD, specifying a requirementfor a light controller.

A basic 1 RTSTD consists of the following parts:

1 Additionally, some syntactic sugar for making large speci5cations more concise is oOered.

Page 4: Visual temporal logic as a rapid prototyping tool

96 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

• An entity declaration de5ning the interface of the component (not shown in Fig. 1). It speci5esthe signals (e.g. reset scene, motion sensor), their data types (e.g. Bit) and access modes(in or out, i.e. being driven by the environment or the component, resp.).

• A set of waveforms (here reset scene, motion sensor). A waveform de5nes a sequence ofBoolean expressions associated with a signal (e.g. reset- scene =‘0’, then reset scene=‘1’,then reset scene=‘0’ in the upper waveform of Fig. 1). The point of change from validity ofone expression to another is called an event. A distinguished activation event, which speci5es aprecondition for applicability of the diagram, is located to the left over the waveforms.

• A set of constraints, denoted by constraint arcs, which de5ne a partial order on events. Wedistinguish between strong constraints and weak constraints. Strong constraints are those whichhave to be satis5ed by the system under development, while weak constraints denote assumptionson the behaviour of the environment. Violation of a weak constraint implies that the remainderof the timing diagram is preempted and consequently poses no further design obligations.Table 1 summarizes the diOerent kinds of strong constraints. Each of these has a weak coun-terpart, denoted by a dashed instead of a solid constraint arc.

The constraints, which are more closely examined in the next section, are akin to negation-free4at formulae of PTL [9], i.e. correspond to until- or unless-formulae with propositional left-handside, yet add expressiveness beyond the 4at fragment of PTL by subsuming the timed variants ofuntil and unless also. 2

• An activation mode. Initial diagrams describe requirements on the initial system behaviour whereasan invariant diagrams expresses requirements which must be satis5ed at any time during systemlifetime. Invariant mode corresponds to the ‘always’ modality of linear-time temporal logic, im-plying that—in contrast to timing diagram formalisms employing iteration—multiple incarnationsof the diagram body may be simultaneously active if the activation condition 5res again beforethe end of the body has been reached.

2.1. Example

This section presents a simple speci5cation to illustrate the features of the RTSTD language. Theexample was inspired by the Light Control System case study [10], and describes a light controllersystem for a meeting room in an oSce building.

The light controller is equipped with the following inputs and outputs:

• an output lights on that switches the lights on and oO.• A person in the room can modify the light scene. An input reset scene is used to reset thescene to the default settings.

• The controller is connected to a motion sensor. The input motion sensor indicates whether aperson was detected by the sensor.

• The input pulse is used to check if the motion sensor is working correctly. It must be set to a“high” (= ‘1’) value by the motion sensor every 60 s.

• The output failure indicates that there is a problem with the motion sensor.

2 Flat PTL, as de5ned in [9], cannot simulate the timed variants as it does not feature a next operator.

Page 5: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 97

Table 1The basic strong constraint types of RTSTDs and some compound constraint

(a) Simultaneity constraint (b) Precedence constraint

If any of the events e or f occurs then Event f does not occur before e. Oncethe other one has to happen simultaneously. e has taken place, f may or may not happen.

(c) Leads-tot constraint (d) Con8ict t constraint

If event e happens then f occurred e and f do not occur less than t time-unitsbeforehand or it follows strictly less than apart, with t ∈N¿0.t time-units after e, where t ∈N ∪ {∞}.

Conjunction of precedence, con4icts, and leads-tot constraints

f follows e within time window [s; t).

The initial diagram in Fig. 2(a) speci5es the initial values of the output ports. Initial diagramsare distinguished by a double perpendicular line at their left side. All other diagrams are invariantdiagrams, which will become “activated” whenever their activation condition holds.

The diagrams in Figs. 2(b) and 1 describe the behaviour of the controller if the motion sensordoes not detect any person: according to Fig. 1, the light scene settings will be reset after 300 s if

Page 6: Visual temporal logic as a rapid prototyping tool

98 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

Fig. 2. Light controller speci5cation: (a) Initial values; (b) Switching lights oO; (c) Failure mode.

no motion can be detected. A weak constraint (the dashed line) is used to express the assumptionthat no motion sensor event occurred prior to the reset. According to Fig. 2(b), lights will be turnedoO after 150 s, provided there is no motion and the controller is not in the failure state.

The diagram in Fig. 2(c) shows a safety property: it signals a failure if no pulse can be detectedduring a period of 60 s. If a pulse would be detected in this time frame, then the violation of theweak constraint would preempt the timing diagram, and as a consequence, no further constraints areimposed on the signals.

2.2. Detailed semantics

We will now provide a detailed semantics of RTSTDs by mapping them to timed automata [11],thereby employing the discrete-time interpretation of timed automata. While a dense-time interpre-tation would also make sense, we prefer the discrete-time one, as it renders timed automata aneOective Boolean algebra, whereas timed automata are not even closed under complementation inthe dense-time setting [11].

We start by giving semantics to waveforms. A waveform w, graphically depicted by

is a sequence of propositional predicates �0; : : : ; �n over the values of a signal or port, interspersedby events e1; : : : ; en. We assume the latter to be uniquely named throughout the whole RTSTD. 3 Awaveform is called deterministic iO any two adjacent �i are mutually exclusive, i.e. iO �i ∧ �i+1 is

3 Within our tool-box, unique naming is in fact ensured by the editor; the user need not even name events.

Page 7: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 99

unsatis5able for each i∈{0; : : : ; n − 1}. We assign to w a timed B#uchi automaton communicatingport valuations as well as Boolean valuations for the event names, i.e. having alphabet �=� ×(Event → B). Here, � is the set of possible port valuations, as stated in the entity declaration. Eventis the set of all event names in the timing diagram, extended by a special preemption event PEinvoked upon violation of some weak constraint, and for each weak constraint a further distinguishedevent violationi signaling violation of that weak constraint. Valuations of events will only be usedinternally for synchronizing constraints to waveforms and will be 5nally hidden from the semanticssuch that the overall semantics of timing diagrams is in terms of sequences of port valuations only.

The B#uchi automaton assigned to w is the automaton Aw=

where doubly circled states denote accepting states (in this case, each state) and the predicates onthe transition arcs mean that any alphabet entry satisfying the predicate may give rise to the corre-sponding transition. This automaton construction ensures that the port behaviour is compatible withthe sequence �0; �1; : : : ; �n of predicates and that occurrences of the events e1; : : : ; en are con5ned tohappen at the time instants corresponding to appropriate changes in the port valuation. All events notbelonging to e1; : : : ; en may occur at any time, as they are not related to waveform w. Furthermore,Aw (and similarly any of the remaining automata) accepts the preemption event PE at any time,thereafter imposing no further constraints on port behaviour and event occurrences.

Constraint arcs impose extra constraints on the occurrence of events. The strong simultaneityconstraint c1 from Table 1(a) con5nes the two events e and f to happen simultaneously and thusmaps to automaton Ac1 =

Page 8: Visual temporal logic as a rapid prototyping tool

100 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

In contrast, the weak counterpart of above simultaneity constraint maps to automaton Ac1w =

which does not impose any constraints, but signals constraint violation through the distinguished eventviolationi. The disjunction of the Violationi events from all automata implementing weak constraints,where the index i distinguishes the events used in the diOerent automata, will subsequently formthe preemption event PE. This causes the timing diagram to be preempted and thus to impose nofurther constraints on the temporal behaviour as soon as any weak constraint arc becomes violated.Weak variants of the other constraint types are derived analogously; we will therefore not elaborateon them in the remainder.

The strong precedence constraint from Table 1(b) requires that event f may not occur before e,which is enforced by automaton Ac2 =

Note that f need not happen, even if e has already been observed.

A strong timed leads-to constraint, as in Table 1(c), is implemented by automaton Ac3 =

where c is a clock that is local to this automaton. Being motivated by the needs of synchronoussystem design, we slightly deviate from the usual interpretation of clocks in timed automata [11] andassume that clocks count transitions rather than an independent system time. Note that this is in factequivalent to assuming that one transition takes place every time instant, which can be enforced byusing an additional clock in the standard model of timed automata. Our convention merely saves thisclock. Through use of the clock, above automaton forces f to take place less than t time units aftere has occurred. Note that in case t=∞, which denotes an unbounded liveness constraint, properbehaviour is enforced by B#uchi acceptance and the middle state being non-accepting, causing f toeventually happen.

Page 9: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 101

Finally, a strong con4ict-t constraint, as in Table 1(d), asks for e and f to keep a temporaldistance of at least t time units, which is implemented by Ac4 =

Now it remains to issue a preemption event PE whenever some weak constraint has been violated.Therefore, we “or together” the violation signals violation1; violation2; : : : of all weak constraintsactually occurring in the timing diagram by APE =

The semantics of a complete timing diagram body is the conjunction of the semantics of itsparts, yet projected to the behaviour on the ports only, thus eliminating all event names. This canbe achieved by 5rst taking the automaton product of the automata encoding the waveforms andconstraints of the timing diagram, then applying morphism � : �→ � de5ned by �((�; e))= �:

ATD=�

∏w∈w (TD)

Aw ×∏

c∈c (TD)Ac × APE

;

where w(TD) is the set of waveforms in TD and c(TD) is the set of constraints in TD. It is easyto see that the resulting B#uchi automaton is deterministic if all waveforms in TD are deterministic.

2.2.1. Initial and invariant diagramsThe semantics of an initial diagram is simply that of its body: for any run r ∈�!, i.e. for any

in5nite sequence r of port valuations, we de5ne satisfaction of a timing diagram TD by r, denotedr |= TD, by

r |= TD iO r ∈LATD ; provided TD is initial:

Here, LA denotes the !-regular language recognized by A under the convention that one transitionis taken every time instant. Consequently, the set M<TD= of models of an initial diagram TD is an!-regular language, and the construction of ATD eOectively yields an automaton recognizing M<TD=.The expressiveness of initial diagrams is that of negation-free 4at PTL formulae [9], yet extendedby a next operator; however, much conciseness is gained by being able to directly specify metrictime bounds instead of having to expand them into an appropriate cascade of next operators.

Page 10: Visual temporal logic as a rapid prototyping tool

102 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

Invariant diagrams add further expressiveness by embedding the semantics of the diagram bodyinto a single, outermost always operator: for any run r ∈�!,

r |= TD iO ∀i∈N:(

ri satis5es a⇒ r[i; : : : ]∈LATD

); provided TD is invariant:

Here, ri denotes the ith position in r; a is the activation condition of TD, which is the conjunction ofthe leftmost state predicates of all waveforms in TD, and r[i; : : : ] denotes r from position i onwards,i.e. the in5nite sequence 〈ri; ri+1; ri+2; : : :〉 of port valuations. Thus, r |= TD iO starting in any timeinstant that satis5es the activation condition a, the timing diagram body is satis5ed by the remainingbehaviour. Intuitively, one may think of a new incarnation of the timing diagram body being createdwhenever the activation condition 5res.

Please note that—as discrete-time timed automata are only more concise, yet not more expres-sive than untimed B#uchi automata—an eOective automata-theoretic construction for (untimed) B#uchiautomata recognizing the set M<TD= of models of an invariant diagram TD is in principle avail-able: it consists of 5rst unraveling the timed automaton ATD into an untimed B#uchi automaton, thencomplementing it into an automaton ATD, thereafter adding an initial loop of shape

which non-deterministically waits until starting ATD in a situation satisfying activation condition a,and 5nally complementing the resulting device again. However, this construction is extremelyexpensive due to the double complementation of B#uchi automata involved. This is the reason for inpractice con5ning ourselves to deterministic timing diagrams. These yield timed B#uchi automata ATDwhich are extremely simple and cheap to complement, as they are deterministic and the only kindof loops occurring in above construction is self-loops, where a state directly loops back to itself.Under these circumstances, complementation of ATD can be achieved by simply complementing theset of accepting states, 4 even though we are dealing with B#uchi acceptance.

As a last step in giving semantics to timing diagrams, the semantics of a set of timing diagrams isde5ned to simply be the conjunction (i.e. language intersection, corresponding to automaton product)of the semantics of the individual timing diagrams.

4 Clearly, one has to make the partial transition relation depicted in the above automata diagrams complete by introducingnon-accepting sink states.

Page 11: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 103

Fig. 3. The ICOS system.

3. The ICOS tool-box

Despite the appealing graphical syntax of RTSTDs, speci5cation of reactive systems using RTSTDsremains a challenging task. The ICOS tool-box, as shown in Fig. 3, is a comprehensive set of toolsthat supports this process [4,5,12].

ICOS is built around a timing diagram database that holds all speci5cation clauses belonging tothe current project. The database is augmented by a layer of procedures for compiling RTSTDs toother eOective representations of reactive behaviour, like propositional temporal logic (PTL) [13]or B#uchi automata [3]. These procedures, as well as the corresponding derived representations ofreactive behaviour, are in general hidden from the user. Instead, they are invoked (resp., constructed)on the 4y whenever a particular representation is needed for some user-selected task (e.g., for codegeneration).

User-selectable activities are concerned with design, veri5cation, simulation, synthesis, and de-bugging. Design-related activities involve creating and editing RTSTDs with a graphical editor, aswell as browsing the speci5cation database. Veri<cation entails static analysis, for checking whetherinterfaces are consistently used, and automatic tautology checking, for formally verifying that somere5ned speci5cation satis5es the original commitments of the design task. Simulation is performedupon a keystroke by 5rst generating a 5nite automaton faithfully re4ecting the semantics of thespeci5cation, then encoding it in the C programming language, and 5nally linking it to a simulationenvironment, thus facilitating interactive simulation of speci5cations. The intermediate steps involveddo, however, not require any user interaction.

Page 12: Visual temporal logic as a rapid prototyping tool

104 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

Simulation shares most of the basic technology with synthesis. Synthesis goes however a bit fur-ther in that it actually delivers code for programming a 5eld-programmable gate array (FPGA), thusyielding an embedded control device that can be plugged into the application context rather than justan interactive simulation. The steps involved are, 5rst, the generation of a set of interacting Mooreautomata satisfying the speci5cation, second, their translation to synthesizable VHDL code, and third,synthesis of a corresponding FPGA. We will expand on the techniques underlying synthesis in thenext section, as embedded controller synthesis forms the backbone of our rapid prototyping method.

Test monitor generation is a minor variant of this synthesis process which yields an FPGA thatdoes not control its application context, but instead may be plugged into the application context asan online monitor, then monitoring the running system for violations of the speci5cation.Debugging, 5nally, yields error paths pinpointing the problem whenever synthesis fails due to a

contradictory (and thus unimplementable) speci5cation, or if tautology checking 5nds a non-tautology.

4. Synthesis

Automatic synthesis of FPGA-based controllers is the core of our rapid prototyping method forRTSTD speci5cations. The application scenario is that the user invokes a fully automatic synthe-sis procedure once the requirement set, being formalised through RTSTDs, is deemed suScientlycomplete. The synthesis algorithm then tries to construct an FPGA-based embedded controller satis-fying the speci5cation—i.e., an operational prototype—or, if it detects non-implementability of thespeci5cation—delivers diagnostic information.

In fact, the synthesis method is a three-step procedure: 5rst, the synthesis algorithm tries toconstruct a Moore automaton satisfying all stated requirements. However, no appropriate Mooreautomaton need exist due to a contradictory speci5cation in which case the algorithm creates errorpaths to help the programmer re5ne the speci5cation. Otherwise, the second step can commence,where the generated Moore automaton is automatically translated to VHDL code. The subset ofVHDL used as target language is such that the 5nal step of actually implementing the automatonby a given target technology (e.g. FPGAs) can be done through compilation (sometimes called“high-level synthesis” by the tool vendors) of the VHDL description, and we have indeed integratedour tools with the Synopsys [14] and some Xilinx tools to achieve this.

As high-level synthesis is by now an industrially available technology, we will in the remainderof this article concentrate on the 5rst step and will sketch diOerent speci5cation-level synthesisprocedures yielding sets of interacting Moore machines from RTSTD speci5cations. The proceduresdiOer in the methods used for dealing with timing constraints and in the number and shapes of theinteracting Moore machines generated, which aOects the average-case complexity of the synthesisprocedure and the size of the hardware devices delivered. Given a speci5cation �; the problem ofconstructing a Moore automaton satisfying the speci5cation, called the synthesis problem, is to 5nda Moore automaton A� which is

(1) well-typed w.r.t. �, i.e. has the inputs and outputs that the entity declaration of � requires, andaccepts any input at any time (i.e., only the outputs are constrained),

(2) correct w.r.t. �, i.e. the possible behaviours of A� are allowed by the speci5cation �, formallyLA� ⊆ M<�=, where M<�= is the set of behaviours satisfying � and LA� is the set of possiblebehaviours of A�.

Page 13: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 105

Fig. 4. The basic synthesis chain.

By adoption of logical standard terminology, an algorithm solving the synthesis problem is calledsound iO, given any speci5cation �; it either delivers an automaton that is well-typed and correctw.r.t. the speci5cation �, or no automaton at all. It is called complete iO it delivers an automatonwhenever a well-typed and correct automaton w.r.t. the speci5cation exists.

4.1. Classical controller synthesis and RTSTDs

For control problems speci5ed by !-regular games, e.g. 5nite game graphs augmented with theB#uchi acceptance condition, there is a 5rmly developed theory of winning strategy construction [3].This theory provides fully automatic procedures for generating 5nite-state winning strategies, i.e.5nite-state controllers, from !-regular games specifying the allowable behaviour. As the semanticsexposed in Section 2.2 provides an eOective mapping of deterministic RTSTDs to deterministic B#uchiautomata, which can be interpreted as 5nite game graphs when augmented with the port directionsfrom the entity declaration, this approach can be extended to deal with deterministic RTSTDs also.Soundness and completeness of the synthesis method then is directly inherited from the correspondingproperties of winning strategy construction in regular games.

In fact, this chain of algorithms, depicted in Fig. 4, forms the backbone of the ICOS tool set[5,12].

However, this basic synthesis chain suOers from complexity problems if the speci5cation is large,i.e. is a conjunction of multiple timing diagrams, as the regular games constructed then tend tosuOer from state explosion. With the basic method, game graphs grow exponentially in the numberof timing diagrams due to the automaton product involved in dealing with conjunction. As this wouldrender application for rapid prototyping impractical, the ICOS tools oOer modi5ed procedures whichreduce the complexity of dealing with large speci5cations. Obviously, such extensions cannot dealeSciently with arbitrary RTSTD speci5cations, but they are, however, carefully designed to coverthe typical speci5cation patterns.

4.2. Compositional synthesis

The 5rst such variant is a compositional extension of the basic algorithm. Within this approach,which is sketched in Fig. 5, the speci5cation is 5rst partitioned into a maximal set of groups offormulae G1; : : : ;Gn such that each output is constrained by the formulae of at most one group.Then synthesis down to a winning strategy is performed for each group individually, yielding foreach group Gi a Moore automaton Ai that has just the outputs constrained by Gi as outputs, and allother ports as inputs. The individual Moore automata are then compiled to synthesizable VHDL andcomposed by parallel composition.

Page 14: Visual temporal logic as a rapid prototyping tool

106 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

Fig. 5. Compositional synthesis.

Table 2Performance of compositional synthesis (after [12])

Component No. of Game graph Controller Time (s)STDs states=transitions states=transitions

Non-compositional synthesis of a controller for the FZI production cell [6], most complex componentsa

Press 14 1703=115897 82=435 4483Crane 16 1574=76041 190=1303 1035

Compositional synthesis of a controller for the FZI production cell, most complex component b

Press, vertical movement 5 27=193 6=26 8

aSystem speci5cation comprises 8 independent components. One controller per component is synthesized.bSpeci5cation is automatically partitioned into 26 groups. One controller per group is synthesized.

With this compositional method, growth of the game graph is linear in the number of groups, andexponential growth is only encountered in the maximal size of the individual groups. Table 2 providesempiric results from [12], obtained by Feyerabend and Schl#or when using both the non-compositionaland the compositional synthesis procedure of ICOS for synthesizing a controller for the FZIproduction cell [6]. Overall, Feyerabend and Schl#or have found the compositional approach to saveover 99% of the transitions in the game graphs of the major components.

Soundness of the compositional synthesis technique is easily established:

Theorem 1. Let G1; : : : ;Gn be groups of RTSTDs with Oi being the outputs constrained by Gi; andwith Oi ∩ Oj = ∅ for i �= j. Let Ai be the Moore automaton synthesized for Gi. Then A1‖ · · · ‖Anis well-typed and correct w.r.t. G1 ∧ · · · ∧ Gn; where ‖ denotes parallel composition of Mooreautomata.

Proof. Correctness of A1‖ · · · ‖An w.r.t. G1 ∧ · · · ∧ Gn is straightforward, as parallel compositionof Moore automata with disjoint output alphabets semantically yields language intersection, asdoes conjunction of RTSTDs. Thus, soundness of the basic synthesis algorithm, which yields LAi ⊆M<Gi= for the individual groups, implies LA1‖···‖An =LA1 ∩ · · · ∩ LAn ⊆ M<G1= ∩ · · · ∩ M<Gn==M<G1 ∧ · · · ∧ Gn=.

Page 15: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 107

Fig. 6. Synthesis chain employing timer decomposition.

Similarly, well-typedness of A1‖ · · · ‖An w.r.t. G1 ∧ · · · ∧ Gn follows from soundness of the basicsynthesis procedure since the composition rules for interfaces agree for Moore automata and RTSTDsif outputs occur at most once in a parallel composition.

Completeness is, however, lost using compositional synthesis. The problem is that a certain groupmay not be synthesizable without knowledge about the behaviour of another group. Such problemsare regularly encountered within compositional methods, and we propose to solve them by just thesame techniques that proved to be helpful in compositional veri5cation: the necessary information onthe other components can be formalized via assumptions (for example, through weak constraint arcs).It should be noted that ICOS helps in 5nding adequate assumptions, as an error path is suppliedwhenever synthesis of a component fails.

4.3. Synthesizing hardware clocks

However, there still is some reason for dissatisfaction: as timing annotations have to be unwoundto an according number of transitions in the game graph by the translation of RTSTDs to !-regulargames, the modular synthesis method remains exponential in the number of potentially overlappingtiming constraints. This makes dealing with timing constraints of more than a handful time unitshardly aOordable—realistic real-time system programming cannot be done with such code generationmethods. Therefore, we are heading for an algorithm that is of linear complexity in the number oftiming constraints, even though completeness is thereby necessarily sacri5ced. What is thus neededis a synthesis method that separates generation of timers controlling the allowable passage of timefrom synthesis of an untimed control skeleton. In the remainder, we sketch a synthesis techniquewhich oOers the desired separation. It is currently being integrated into ICOS. In this hybrid ap-proach, small—and thus harmless w.r.t. the state explosion problem—time constants are treated bypurely !-automata-theoretic means, whereas large-scale timing constraints, if found to be suScientlyindependent, are directly mapped to hardware timers (see Fig. 6).

The new approach directly takes advantage of the timed automata used in the semantics sketchedin Section 2.2. For initial-mode diagrams TD, the basic construction is absolutely straightforward:the timed automaton ATD is taken and any clock featuring clock conditions that monitor more thana user-speci5ed threshold of time steps is converted to a separate timer component such that clockresets and clock conditions can be replaced by communication with that component, as shown inFig. 7.

Thereafter, the remaining clocks, i.e. those controlling time intervals of less than the threshold,are removed by expanding their eOect to an appropriate number of unit-delay transitions. This results

Page 16: Visual temporal logic as a rapid prototyping tool

108 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

Fig. 7. Converting clocks to timer components.

in an untimed automaton, called sequential skeleton in the remainder, which communicates with theenvironment and with the timer components. From then on, synthesis treats the timers similar toenvironment components, which means that the behaviour of these components is left untouchedduring synthesis. The advantages are twofold: 5rst of all, the 5xed behavioural description of timersallows for the use of pre-fabricated, optimized hardware components, and second, controller synthesiscan concentrate on solving the control problem described by the small, untimed automaton thatremains.

This is, however, only the basic idea. In practice, we use a more elaborate construction whichmakes synthesis with timer decomposition more versatile, i.e.—although still being necessarilyincomplete—let it succeed more often. For example, we use timers c which additionally gener-ate a c.pre elaps signal one clock tick before really elapsing. Using such timers, the control problemremaining after timer decomposition, i.e. the sequential skeleton, can be conjoined with an assump-tion on environment behaviour expressing that no c.elapsed signal may ever occur without beingpreceded by a c.pre elaps signal, which allows the synthesis procedure to generate controllers thattake action just in time before a timing constraint may be violated.

Furthermore, the synthesis problem becomes more subtle if TD is an invariant diagram. The prob-lem is that invariant diagrams can feature so-called self-reactivation, meaning that within a satisfyingrun, the activation condition may 5re again in step i although the behaviour is still constrained bya timing diagram body that has been activated in step j¡ i, thus causing multiple instances of thebody to be simultaneously active. While this may at 5rst seem to only correspond to the merelyintuitive idea of “a new incarnation of the body being created whenever the activation condition

Page 17: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 109

Fig. 8. Modi5ed sequential skeleton.

5res”, self-reactivation does indeed always manifest itself in a blow-up of the !-regular game graphin the classical synthesis chain, as well as in a growth of the minimum number of timers neededfor an implementation using hardware timers. To see this, consider a requirement of the form “anyrising edge on input a is followed by a rising edge on output b exactly 107 clock ticks later”, 5

which clearly requires storing the exact occurrence times of up to 5×106 rising edges in order to befaithfully implemented. If not implemented by completely diOerent means, e.g. huge shift-registers,this would require a corresponding number of hardware timers in the synthesized controller, whichwould clearly be impractical.

Therefore, we use a diOerent strategy for using timers: we always do allocate just one hardwaretimer per timing constraint and ask the synthesis algorithm to try to construct a control strategywhich can ensure the original requirement with just that single instance of the timer. The basic ideatowards this is again simple: as shown in Fig. 8, we add a further signal c.busy to the sequentialskeleton, which is set to true whenever the timer is actually needed, and left unspeci5ed otherwise.We then take that sequential skeleton, which still represents the semantics of the diagram body only,and add the necessary automata-theoretic constructions for obtaining invariant-mode semantics, asexplained in Section 2.2. If we then build the automaton product of the resulting regular game Gwith automaton Atimer noninterference =

then this product automaton represents a control problem that calls for 5nding a control strategysuch that no incarnation of the sequential skeleton being embodied in G asks for starting c whenanother instance of the skeleton holds c busy. If synthesis succeeds on that control problem thenit yields a control strategy which—by never starting c when it is already busy—requires just oneinstance of the timer, which thus can be implemented by a single standard hardware timer.

This method will, however, fail on above sample requirement, as it is not realizable with asingle timer. Yet, we think that sparse use of timers is common engineering practice and that apractical synthesis algorithm should re4ect this by reporting problems with the speci5cation ratherthan generously allocating lots of timers if the speci5cation calls for them. The gain is that bydirectly mapping all timing constraints of signi5cant size to hardware timers, the method is linearin the number of timing constraints. If it is furthermore combined with modular synthesis then

5 While this particular requirement cannot be formalized using deterministic RTSTDs (the input language of our synthesistools), similar, yet more complicated, speci5cations featuring reactivation can be expressed. We have taken this particularexample only for the sake of brevity.

Page 18: Visual temporal logic as a rapid prototyping tool

110 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

super-linear blow-up can only occur through individual timing diagrams containing unusually largenumbers of events or through large groups of formulae controlling the same outputs. These situationsare, however, atypical, rendering the new method a practical rapid-prototyping tool for real-timeembedded controllers.

Similar methods are, btw., currently explored by the second author for dealing with data in anessentially uninterpreted way. The idea is that thus the traditional separation between control anddata can be incorporated into game-theoretic synthesis methods. The net eOect is that a large datapath no longer yields a blow-up of the game-graph, making automatic synthesis applicable to muchlarger systems.

5. Discussion

We have presented a rapid-prototyping framework for requirements speci5cations that are for-malised through real-time symbolic timing diagrams, a metric-time temporal logic with a graphicalsyntax akin to the informal timing diagrams used in electrical engineering [2]. The underlying coretechnology is fully automatic synthesis of embedded control hardware from requirements speci5ca-tions. This involves two major steps: 5rst, the generation of Moore automata satisfying the speci-5cation, and second, the actual implementation of these automata by embedded control hardware.For the latter step, we rely on industrially available tools from Synopsys and Xilinx that performFPGA-based implementation of VHDL-coded Moore-automata [14]. In contrast, the former step isbased on procedures that have been speci5cally implemented for the ICOS tool-box [4,5,12]. Whilethe underlying algorithms have been derived from the well-established theory of winning-strategyconstruction in !-regular games, the overall approach is—being targeted towards rapid prototyping—mostly pragmatic, weighing eSciency higher than completeness. Two key issues have been identi5edin this respect: 5rst, the necessity of compositional synthesis of parallel components and second, earlydecomposition of timing issues from the synthesis problem. The result is a synthesis method of lowcomplexity, which is thus suitable as a development tool in rapid prototyping contexts.

Within the ICOS tool-box, these algorithms are closely integrated with a graphical speci5cationeditor supporting the speci5cation phase and all compilation and mapping algorithms necessary formechanically translating down to automatically synthesizable VHDL code such that implementa-tion is truly automatic from the speci5cation level all the way down to actual hardware. ICOSfurthermore comprises—under a common user interface—tools for browsing and manipulating aspeci5cation database, as well as for interactively simulating and for verifying speci5cations. It isthus a comprehensive environment for the incremental development of RTSTD-based requirementsspeci5cations. Furthermore, within the rapid-prototyping project “EVENTS” [1], ICOS is conjoinedwith Statemate-based code generation techniques such that rapid prototyping of hybridly speci5edsystems, where some components have a declarative formulation through RTSTDs while others areoperationally described by Statecharts [15], becomes feasible. While this involves integration of dif-ferent rapid-prototyping tools through automatic interface generation for the generated components,other extensions to the source language accepted can be accomplished within just the ICOS tool:ICOS is modularly built such that while the current version is dedicated towards RTSTD-basedspeci5cation, an adaptation to other declarative speci5cation formalisms is also possible. A possiblecandidate formalism, for which front-end tools like graphical editors are already under development

Page 19: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 111

at our department, is that of Live Sequence Charts (LSCs), an extension of Message Sequence Charts(MSCs) recently proposed by Damm and Harel [16].

On the algorithmic side, we think that the main contribution of the ICOS tools to game-theoreticsynthesis are methods for dealing with timing or with the data path in an uninterpreted way. Dueto the obvious necessity of treating timing mostly independent from algorithmic aspects withinany reasonably eScient synthesis method for hard real-time controllers, quite a few other researchgroups work on this theme. However, most approaches are based on mainly operational rather thandeclarative speci5cation styles (e.g. [17]). Closest to our approach is [18], where Dierks and Olderogdetail a direct mechanism for deriving timer actions from speci5cations formalised through a veryrestrictive subset of Duration Calculus [19], the so-called DC-implementables [20]. Dierks’ algorithmis extremely eScient, but at the price of a very restrictive speci5cation format: the processablespeci5cations are con5ned to be ‘phased designs’ in the sense of the ProCoS projects [21], whichare akin to RTSTDs featuring just three events. While our formalism is more expressive in thisrespect, Dierks and Olderog do, on the other hand, go ahead by dealing with a dense-time logic andanalyzing certain kinds of switching latency.

6. Summary

Within the survey article “Visual Temporal Logic as a Rapid Prototyping Tool”, a rapid-prototypingframework for requirements speci5cations that are formalised through real-time symbolic timing dia-grams is presented. Real-time symbolic timing diagrams is a metric-time temporal logic with a graph-ical syntax akin to the informal timing diagrams used in electrical engineering. Being a full-4edgedtemporal logic, such diagrams are well-suited for a declarative, i.e. highly non-operational, styleof requirement formalization. The basic idiom of such a system description is that of a constraintexcluding some undesirable behaviours, whereas operational descriptions are based on the idiomof operations giving rise to desired behaviour. The main advantage of the declarative style is thatrequirements can be dealt with modularly, thereby representing each property by an independentspeci5cation. This is particularly useful for safety requirements, which can hardly be held localin operational descriptions. The drawback, however, is that the exploratory design style of simu-lating or even prototyping an abstract design before re5ning it further, which comes almost forfree with operational methods, has no immediate counterpart in the declarative world. Within ourrequirements-engineering and rapid-prototyping tool-box “ICOS”, we try to overcome this problemby oOering suitable automatic procedures that construct operational prototypes from declarativespeci5cations.

The underlying core technology is fully automatic synthesis of embedded control hardware fromrequirements speci5cations. This involves two major steps: 5rst, the generation of Moore automatasatisfying the speci5cation, and second, the actual implementation of these automata by embeddedcontrol hardware. For the latter step, we rely on industrially available tools that map VHDL-codedMoore-automata to 5eld-programmable gate arrays. In contrast, the former step is based on proceduresthat have been speci5cally implemented for the ICOS tool-box. While the underlying algorithms havebeen derived from the well-established theory of winning-strategy construction in !-regular games,the overall approach is—being targeted towards rapid prototyping—mostly pragmatic, weighingeSciency higher than completeness. Two key issues have been identi5ed in this respect: 5rst, the

Page 20: Visual temporal logic as a rapid prototyping tool

112 M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113

necessity of compositional synthesis of parallel components and second, early decomposition of tim-ing issues from the synthesis problem. The result is a synthesis method of low complexity, whichis thus suitable as a development tool in rapid prototyping contexts.

Within the ICOS tool-box, these algorithms are closely integrated with a graphical speci5cationeditor supporting the speci5cation phase and all compilation and mapping algorithms necessary formechanically translating down to automatically synthesizable VHDL code such that implementationis truly automatic from the speci5cation level all the way down to actual hardware.

References

[1] L#uth K, Metzner A, Peikenkamp T, Risau J. The EVENTS Approach to Rapid Prototyping for Embedded ControlSystems. Zielarchitekturen eingebetteter Systeme (ZES’97), 14. ITG=GI Fachtagung Architektur von Rechnersystemen(ARCS ’97), Rostock, Germany, September 1997.

[2] Feyerabend K, Josko B. A visual formalism for real time requirement speci5cation. In: Bertran M, Rus T, Editors.Transformation-Based Reactive System Development, LNCS 1231 Berlin: Springer, 1997. p. 156–68.

[3] Thomas W. Automata on in5nite objects. In: Leeuwen Jv. editor. Handbook of Theoretical Computer Science, volumeB: Formal Models and Semantics, Amsterdam: North-Holland, 1990, p. 133–91.

[4] Korf F. System-Level Synthesewerkzeuge: von der Theorie zur Anwendung. Dissertation, Fachbereich Informatik,C. v. Ossietzky Universit#at Oldenburg, Germany, 1997.

[5] L#uth K. The ICOS synthesis environment. In: Ravn AP, Rischel H. Editors. Formal Techniques in Real-Time andFault-Tolerant Systems, LNCS 1486. Berlin: Springer, 1998. pp. 294–7.

[6] Lewerentz C, Lindner T. Editors. Formal Development of Reactive Systems: Case Study Production Cell, LNCS891. Berlin: Springer, 1995.

[7] Borriello G. Formalized timing diagrams. In: The European Conference on Design Automation 1992, Silver Spring,MD: IEEE Computer Society Press, 1992. p. 372–7.

[8] Khordoc P, Dufresne M, Czerny E. A Stimulus=Response System based on Hierarchical Timing Diagrams. TechnicalReport No. 770, Universite de Montreal, 1991.

[9] Dams DR. Flat fragments of CTL and CTL∗: separating the expressive and distinguishing powers. Logic Journal ofthe IGPL 1999;7(1):55–78.

[10] B#orger E, Gotzhein R. Editors. Requirements Engineering—The Light Control Case Study. Journal of UniversalComputer Science 2000;6(7).

[11] Alur R, Dill DL. A theory of timed automata. Theoretical Computer Science 1994;126(2):183–235.[12] Feyerabend K, Schl#or R. Hardware synthesis from requirement speci5cations. In: Proceedings of EURO-DAC’96

with EURO-VHDL’96. Silver Spring, MD: IEEE Computer Society Press, 1996.[13] Manna Z, Pnueli A. The Temporal Logic of Reactive and Concurrent Systems, vol. 1. Berlin: Springer, 1992.[14] Golsen S. State machine design techniques for Verilog and VHDL. Synopsys Journal of High Level Design, Sept.

1994. http://www.synopsis.com/news/pubs/JHLD/[15] Harel D, Lachover H, Naamad A, Pnueli A, Politi M, Sherman R, Shtul-Trauring A. STATEMATE; a working

environment for the development of complex reactive systems. In: Proceedings of the 10th International Conferenceon Software Engineering. Silver Spring, MD: IEEE Computer Society Press, 1988. p. 396–406.

[16] Damm W, Harel D. LSCs: Breathing Life into Message Sequence Charts. In: FMOODS’99, IFIP TC6=WG6.1Third International Conference on Formal Methods for Open Object-Based Distributed Systems. Dordrecht: KleuwerAcademic Publishers, 1999.

[17] Vanbekbergen P, Gossens G, Lin B. Modeling and synthesis of timed asynchronous circuits. In: Proceedings ofEURO-DAC with EURO-VHDL 94. Silver Spring, MD: IEEE Computer Society Press, 1994.

[18] Olderog E-R, Dierks H. Decomposing real-time speci5cations. In: Langmaack H, de Roever WP, Pnueli A. Editors.Compositionality: The Signi5cant DiOerence, LNCS 1536. Berlin: Springer, 1998. p. 465–89.

[19] Chaochen Z, Hoare CAR, Ravn AP. A calculus of durations. Information Processing Letters 1991;40(5):269–76.

Page 21: Visual temporal logic as a rapid prototyping tool

M. Fr�anzle, K. L�uth / Computer Languages 27 (2001) 93–113 113

[20] Ravn AP. Design of Embedded Real-Time Computing Systems. Doctoral dissertation, Department of ComputerScience, Danish Technical University, Lyngby, DK, 1995.

[21] Bowen JP, Fr#anzle M, Olderog E-R, Ravn AP. Developing correct systems. In: Proceedings of the Fifth EuromicroWorkshop on Real-Time Systems. Silver Spring, MD: IEEE Computer Society Press, 1993. p. 176–89.

Dr. Martin Fr'anzle has a diploma in Computer Science and a doctoral degree in natural sciences from Kiel University,Germany. He is currently a senior research assistant in the Computer Architecture Group of the Computer ScienceDepartment of Oldenburg University, Germany. His research interests are primarily in real-time and hybrid control systems,with special emphasis on their high-level modelling and on formal methods for their analysis, speci5cation and design,and automatic veri5cation.

Karsten L'uth has a diploma in Computer Science. He is currently a research assistant in the Computer Architecture Groupof the Computer Science Department of Oldenburg University, Germany. His research interests are real-time systems,hardware-software codesign, rapid prototyping, analysis, design, and modelling of embedded systems, and automatic testgeneration.