The ollowin paper was oriinally published in the Proceedins o the Conerence on Domain-Speciic Lanuaes Santa Barbara, Caliornia, October 1997 SHIFT and SMART-AHS: A Lanuae For Hybrid System Enineerin Modelin and Simulation Marco Antoniotti A. Göllü University o Caliornia, Berkeley For more inormation about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: oice@usenix.or 4. WWW URL: http://www.usenix.or
SHIFT and SMART-AHS: A Lanuae For Hybrid System Enineerin Modelin and Simulation Marco Antoniotti Aleks Gollu Caliornia PATH University o Caliornia at Berkeley marcoxa,ollu@path.berkeley.edu Abstract shit is a new prorammin lanuae, whose aim is to acilitate the implementation o reusable simulation rameworks by teams o enineers. shit incorporates system theoretic concepts emerin rom the eld o Hybrid Systems analysis and modelin. The SMART AHS ramework is a collection o shit libraries devoted to the construction o Hybrid System based simulation o Automated Hihways Systems. In this paper we describe how the shit simulation environment and lanuae have impacted on the development o the SMART AHS ramework. Our claim is that shit provides the proper level o abstraction or enineers who ace complex modelin and simulation tasks, where phase chanes and continuous variables interact in subtle ways. 1 Introduction shit is a new prorammin lanuae, whose aim is to acilitate the implementation o reusable simulation rameworks by teams o enineers. shit incorporates system theoretic concepts emerin rom the eld o Hybrid Systems analysis and modelin (e.. see [1]) into an object-oriented lanuae environment that oers the proper level o abstraction or describin complex applications such as automated hihway systems, air trac control systems, robotic systems, shop oors, coordinated submarines and other systems whose operation cannot be captured easily by conventional models. These application domains share the ollowin key characteristics. The behavior o objects in the system have both continuous and discrete event components; The systems consist o heteroeneous set o interactin objects where models o individual objects are known and the oal is the study o the emerent behavior resultin rom their interaction; and A static block diaram representation is not sucient to speciy all data dependencies amon objects since the sets interactin objects vary over time. Moreover the practitioners involved in these projects are, most o the time, enineers who like to work with their own \tools o the trade". shit oers them with two o them { automata and dierential equations { well interated into a sinle environment and lanuae. Our work on simulation rameworks was driven by application needs in hihway automation. In the early 90s, PATH (Partners or Advanced Transit and Hihways) proposed a specic control hierarchy or the hihway automation project. The need or a simulation environment was obvious, since we were dealin with a complex and very lare system, which ave no hope or a closed orm mathematical analysis. Followin an unsuccessul market study o the available tools, a decision was made to internally develop a system to simulate the PATH control architecture or hihway automation. A C based simulation system, SmartPath, was created [8]. The project evolved and ained national attention. Followin the oriinal proposal, the National Automated Hihway System Consortium (NAHSC) was unded and other hihway automation architectures were developed. It became evident that a eneralized simulation ramework was needed that could acilitate the specication, simulation, and evaluation o dierent hihway automation architectures. As a result SMART AHS C++, a C++ based persistent simulation ramework was developed [8].
SMART AHS C++ used a set o class libraries developed in C++, SmartDB, as its object model, and delivered a ramework or urther customization by application developers. However, SMART AHS C++ had it shortcomins. It did not allow its users to proram in their \own" domain which was dierential equations and state machine representations. It introduced articial specication rules and syntax resultin rom the use o a eneral-purpose prorammin lanuae. We eel that these shortcomins are shared by most simulation libraries embedded in a host lanuae which does not support lanuae extensions (like Simula, C or C++ or Java). In parallel to our AHS work, we were involved with several other projects, such as air trac manaement, power transmission and distribution systems, and network manaement systems. In system enineerin, we have observed a eneral shit towards hierarchical control o lare systems that combined classical continuous eedback systems, with more recent discrete event based control alorithms and protocol specications. This hybrid systems paradim has proven ideal or the specication, control, and verication o such complex, lare, dynamical systems. Our experience with a multitude o such systems resulted in a set o requirements or rameworks or the desin, specication, control, simulation, and evaluation o lare dynamical systems. No lanuae, product, or tool in the market nor in academia satised all requirements. The desin and implementation o a lanuae that addressed all the requirements required expertise rom several disciplines includin computer science, electrical enineerin, and mechanical enineerin. Such a multi-disciplinary team was assembled at PATH/UC Berkeley and a new prorammin lanuae, shit, was born. This paper provides an overview o the concepts and constructs o the shit lanuae, and a discussion o the impact on the development cycle o simulation model illustrated throuh the SMART AHS case study. The shit mathematical model is beyond the scope o this paper: we reer the interested reader to [7] or a comprehensive exposition. 1.1 Related Work shit is used to describe models with switched dierential equations (such as a vehicle with automatic ear shit) and coordinated behaviors (such as communicatin controllers). Standard math and simulation tools such as Matlab tm, Mathematica tm, Maple tm or MatrixX tm, while suitable or numerical or symbolic interation o xed sets o dierential equations, are dicult to use in applications with rapidly chanin sets o dierential equations (due to the evolution o relationships amon components), complex event-trierin conditions (such as existential queries on the state o the world), and complex proram loic (such as synchronous compositions o state machines). More traditional discrete event simulation packaes like GPSS tm, while oerin a tried and tested base, lack the acilities or writin concise hybrid systems models. The hybrid systems approach [1] satises our needs or component modelin but it lacks the capacity to model dynamically reconurable interactions between components. The Omola/Omsim [11] lanuae has a very similar approach to hybrid system modelin as shit. Both systems provide a modelin lanuae with simulation semantics; both support discrete event and continuous time behavior representation; both have the necessary constructs or hierarchical modelin and specication reuse. However, Omola is desined to represent statically interconnected objects. Furthermore, it does not provide the means to manipulate sets and arrays o components. In shit, these manipulations are used to express and compute the evolution o the interconnections amon components as the world evolves. Statecharts [9] and Aros [10], based on Statecharts, are approaches or synchronous discrete event modelin. Their ocus is on hierarchical specication o nite state machines. shit does not provide explicit acilities or hierarchical behavior specication; instead, it provides a sub-typin mechanism wherein a subtype (presumably more detailed) must present the same interace as its super-type. shit adds continuous time semantics and dynamic recon- urability o the synchronization structure. Subtypin and other constructs may be used to oranize components hierarchically. Recent extensions to the DEVS [16] ormalism have introduced notions o dynamic reconuration [4, 13]. However, the DEVS ormalism is primarily aimed at discrete event simulation and the extensions or continuous evolution laws are limited. Model specication in DEVS is done with C++, SmallTalk or Common Lisp classes that implement the mathematical model at hand, requirin the user
to work at the host lanuae level. 1.2 Preliminary Discussion Our mathematical model or the discrete event semantics is similar to Milner's -calculus [12]. Both models achieve reconuration by a renamin o event labels used in synchronization. The nite state machine part o shit implements this model. The dierential equation part o shit allows systems o rst order ODE's. The abstraction acilities in eneral-purpose prorammin lanuaes such as the oriinal Simula or C/C++, althouh powerul enouh to encode our models, would not allow us to write simple, concise descriptions o our desins. The best that could be hoped or, would be an interation at the level o \embedded interpreters" a latcl/tk or SQL 1. shit provides both hih-level system abstractions and the exibility o a prorammin lanuae. However, all the eatures that shit oers are careully desined to constrain the prorammin style and to conorm to the underlyin mathematical model, while avoidin rustration or the user. As a rst statement about the impact o shit in the prorammin o complex simulations, when we will discuss the reimplementation o SMART AHS in shit in Section 3, we will see that the size o the resultin \libraries" and \projects" decreased by almost 50%, while the code could be more easily reused. Users o shit within the PATH project, NAHSC and UCB reported avourably on the ease with which their enineerin models were readily translated into workin simulations. Moreover, since a shit proram is a direct implementation o a hybrid system specication (even thouh an extended one), the resultin code can be easily manipulated and ed into the new breed o automated verication systems like Kronos [6]. Thouh not substantiated by a direct comparative study, but only by an \a posteriori" examination o the evolution o shit, SmartPATH, SMART AHS C++ and SMART AHS, we claim that these results justiy the considerable research and implementation eort that went into the develoment o these new tools. 1 The shit systems provides a C API or this style o prorammin. 2 SHIFT Lanuae Overview A shit proram describes a set o interactin objects called components and rouped into component types 2. The shit type declaration construct species the prototypical behavior o all components o a iven type. shit supports a sinle inheritance scheme which has proven sucient or our needs. The set o components types and their instances in a shit proram, directly describe a hybrid system with comprises synchronizin nite states machines and dierential equations. shit additionally supports a small set o basic data types (number and symbol) { and o constructed types (array and set). The set o built-in types has the ollowin characteristics: Objects o type number have piecewise constant or piecewise continuous real-valued time traces. The latter variables have type continuous number. Objects o type symbol have piecewise constant symbol-valued time traces. In shit symbols are similar to C enumeration tas. However they do not require a declaration. An object o type set(t), where T is a native or user-dened type, contains a set o elements o type T. An object o type array(t) contains a onedimensional array o elements o type T, whose dimension is determined at creation time. A component prototype is dened by the shit type declaration. The structure o a type rouhly consists o inputs instance variables (or simply \variables") which can be read but not chaned by the behavior o the component and which are visible outside the scope o the type denition. outputs instance variables which can be read and chaned by the behavior o the component and 2 Our terminoloy abuses words like type. Usin more standard Object Oriented terminoloy,wewould speak o instances and classes. We use the term \component" since the control theory application domain imposes a natural part-o metaphor on the sotware architecture.
which are visible outside the scope o the type denition. states instance variables which can be read and chaned by the behavior o the component but that are not visible outside the scope o the type denition. discrete modes and transitions i.e. the denition o the nite state machine behavior o the type. dierential and alebraic equations i.e. the denition o the continuous behavior o the type. The terminoloy is taken rom the standard Control Theory practice and it rouhly translates into the well know concepts o private and public slots in a class. Also, the notions o inputs and outputs are supported by the lanuae in order to promote a \black box" sotware development style. As an example, here is a rst shit code rament: type car input output state continuous number throttle; continuous number position, velocity; continuous number acceleration; continuous number uel level; car car in ront; controller controller; The discrete nite state behavior and the continuous behavior o a type are specied in dierent \clauses" o a user denition. The continuous behavior is specied by ordinary dierential equations and alebraic denitions which are rouped under the ow clause. Each instance variable can be used in these equations and their behavior is computed accordinly 3. Each equation roup (appropriately called a ow) can be labeled with a meaninul name. The deault ow contains the equations which are to be used whenever there 3 O course, only continuous number variables make sense in a dierential denition. are no special provision or computin the value o the variables involved. The discrete clause denes the possible values or the type's mode (i.e. the nite state \current state") and associates to each o them a set o dierential equations and alebraic denitions or one o the ows dened in the ow clause. The dierential equations are specied by systems o rst order ODE o the orm x 0 = (x; u), where x is a sinle variable and u is a vector o \other" variables. The alebraic denitions cannot contain circular dependencies. Such dependencies are detected at run-time, and an error is sinaled by the run-time system. As an example (continuin the \car" example): type car ow deault position' = velocity; velocity' = acceleration; discrete acceleratin acceleration = 3;, cruisin velocity = 30;, brake acceleration = -5; ; Notice that the cruisin state redenes velocity, which becomes alebraically dened (as a constant in this case) instead o dierentially dened (as the interal o the acceleration). Transitions between discrete modes are dened in the transition clause, as in the ollowin example. type car transition acceleratin -> cruisin when velocity >= 30, cruisin -> brakin when position(car in ront) - position < 5; The example uses the state variable car in ront containin a reerence to another car, whose relative position is used in decidin when to apply brakes. Transitions are labeled by a (possibly empty) set o
event labels. These labels allow transitions to synchronize with each other. Moreover, transitions may be uarded by boolean expressions { introduced by the when keyword { and may trier a set o actions rouped in a do clause. These actions reset 4 (i.e. assin) the values o variables, may create new components and may reconnect their inputs and outputs. Suppose that we wish the car to brake when a roadside controller sinals an emerency. This can be specied with the transition type car cruisin -> brakin controller:emerency when position(car in ront) - position < 5;, The initializations o a newly-created component o some type are dened in the setup clause. For example, each component o type car may add itsel to the set cars when it is created. type car setup do ; cars := cars + sel ; The denition o the controller type includes an exported event, emerency, and a transition that triers it. type controller export emerency, ; discrete normal, panic mode, ; transition normal -> panic mode emerency when some critical condition; shit allows the system modeler to speciy very complex patterns o synchronous composition o - nite state automata. The transition uards may contain existential quantiers that query the state o sets o components (possibly all existin components). For example, let cars be the set o all the components o the car type and let the road consist o a sinle lane. Then, the variable car in ront is updated as ollows. type car transition cruisin -> cruisin when exists c in cars : position(c) > position and position(car in ront) > position(c) do car in ront := c; 4 The terminoloy, once aain is borrowed rom the eld o hybrid system studies. In practice a shit proram would not use this exact code unless cars were a small set. A more ecient mechanism requires maintainin multiple sets o cars associated with lanes and hihway sements. 2.1 SHIFT Support Environment shit has many more eatures which we do not discuss here in urther detail since they are outside the scope o the paper 5.Wenow briey comment on the shit support environment and implementation. shit prorams are translated directly into C by the shic compiler. The resultin C le is then linked with the shit runtime library in order to produce an executable (a le conventionally endin with.sim). The runtime library takes care o the implementation o the hih level data structures used by shit (e.. sets) and makes provisions to interate the dierential equations via standard Rune-Kutta alorithms. There are no special optimizations that are done by the compiler 6. The only requirement imposed on the system is that the behavior o the run-time which essentially interprets the set o nite state machines and dierential equations complies with underlyin mathematical model. 5 Amon them: sinle inheritance, complex set and array ormers a la SETL [14], arbae collection (usin Boehm's conservative GC [5]), a orein unction interace acility and a C API which allows an experienced prorammer to control shit simulations rom C and C++ prorams. 6 As a matter o act, many constructs and compilation policies could be optimized away by some rather simple data ow analysis. However, this has not been so ar the emphasis o our work.
There are several subtleties involved in the interaction between the RK interation routine and the uard evaluation code. Lanuaes like Omola/Omsim that support only a static set o dierential equations can perorm compile-time optimizations to select interation step sizes. In shit since the dependencies amon the components can chane at run-time, it is not possible to optimize interation step-sizes with respect to uard-crossins. shit applications so ar have been primarily in non-sti systems, hence a xed-step RK interation alorithm had the best perormance. We reconize that this is still an open research eld. The executable le can be run is two ways: by startin a command line monitor or by connectin the simulation with a Tcl/Tk raphical user interace in a client/server ashion 7 (see Fiure 1 or a screen shot). Both the command line monitor and the raphical environment allow the user to control the runnin simulation. Typical operations include data inspection steppin by time click and by \simulated time" stoppin and resumption o execution in correspondence o discrete transitions. These operations support the simulation modeler \at the riht level" o abstraction and allow her/him to quickly determine whether there are loical problems in the code. 3 Developin Simulation Frameworks in SHIFT: The SMART AHS Case We used shit to develop a specialized ramework (SMART AHS) or the construction o simulation models o hihways. The overall desin principles were rst described in [15]. The objectives o the SMART AHS ramework are listed hereater. 7 The choice to use a client server architecture or the GUI was based on two considerations. (1) The development o the GUI could proress rather independently o the development on the shit compiler and runtime. (2) It was reconized since the early desin staes that shit simulations could require hue memory spaces: hence the necessity to bein able to run simulation remotely on powerul workstation while interactin with them on a local { and less powerul { machine. 1. To provide researchers with a standardized tool which can be used or evaluation o simulation results under dierent policies. 2. To allow the quick construction o alternative simulation models. 3. To allow the simulation o models at dierent ranularity levels. 4. To be able to handle medium to lare scale simulations. In Sections 3.1 and 3.2 we describe the SMART AHS architecture and discuss the lessons learned in its deployment as one o the standard tools used by the National Automated Hihway System Consortium (NAHSC). 3.1 SMART AHS Architecture The SMART AHS ramework is rouhly divided into two parts. The rst is a \static" part which contains hihway type denitions used to compose dierent hihway layouts. The second part contains dierent vehicle models used or diverse simulations. The hihway types comprise Lane, Section, Sement, Barrier, Block and Weather. These types and their structure constitute a data description lanuae or hihways. The vehicle types are centered around a container type called AutomatedVehicle. Its most immediate sub-components are Controller, VehicleModel and VREP (Vehicle Roadway Environment Processor). Fiure 2 contains a schematic representation o the AutomatedVehicle shit code. This architecture meets the requirements by allowin the system modeler to plu in dierent controllers and vehicle dynamic models. Researchers at PATH have successully developed two classes o models or hihly detailed vehicle dynamics simulation and or hih volume hihway simulations with complex vehicle maneuvers. The detailed simulation model describes a vehicle at the level o ear shitin and enine dynamics. The model is realistic and based on real data collected by General Motor researchers. The \hih volume" simulation model uses a simplied vehicle dynamics model (there is no need to simulate the enine dynamics when computin ows over stretches o hihway) and a controller
Fiure 1: A screen shot o the Tcl/Tk shit environment. The simulation bein run models a ood processin manuacturin line. which is devoted to maintain saety parameters (e.. distance rom the vehicle in ront) and to perorm mere maneuvers on entrance and exit ramps. 3.1.1 Micro Simulation o Houston Metro Katy Corridor The \hih volume model" was developed to ather data or a project sponsored by the Houston Metro Transportation Authority. The project asked evaluation data or a preliminary desin o a stretch o hihway with three entry ramps and three exit ramps. The main objective o the study was to evaluate the conestion build up at the three entry ramps under dierent demand volumes with autonomous and hihly automated vehicles 8. Other parameters whichwere under study include the required lenth o the entry ramps to ensure completion o mere maneuvers. A more detailed descrip- 8 The term \autonomous" is here intended in the ollowin sense: a vehicle/driver which takes decisions based only on its sensor input and on certain assumptions on the behavior o nearby vehicles. The hih automation characteristic can be thouht o as modern Adaptive Cruise Control technoloy. tion o the experiment and o its results is contained in [2, 3]. Most o the work done to develop the simulation went into the construction o a Controller module which would obey a distributed protocol or cruisin and merin into existin trac. A code rament or the Controller is shown in Fiure 3. The GUI environment was used to visualize the results o the simulation in order to spot problematic areas o the protocol. We tested our cases on a matrix iven by hih and low trac demand and by enorcin two dierent vehicle trackin policies. The trac demands levels can be summarized as ollows: low ca. 2000 vehicles/hour injected in the hihway system. hih ca. 4000 vehicles/hour injected in the hihway system. In each case each o the vehicles was simulated by instantiatin a ull blown AutomatedVechicle con-
AutomatedVehicle VREP x y p Controller throttle steerin brake VehicleModel lane accel. Fiure 2: Schematic Block Diaram o AutomatedVehicle shit code. tainer, and each instance obeyed the protocol implemented in the Controller. The overall speed o the simulation, dependin on the size o the input data was always between 4 and 9 times o simulated physical time 9. 3.2 Discussion and Evaluation o the SMART AHS Framework The construction o the SMART AHS ramework and o applications based on it, has iven us an insiht on how to conduct the development o an harmonious set o libraries. This was a requirement o the overall project and our aim. We consider our experience so ar successul and we credit this success to two main characteristics o the shit and SMART AHS ramework. shit provides a sound and restricted mathematical model (Hybrid Systems) which can be successully mastered by an enineer in a rather short period o time. The tools provided (dierential equations and nite state automata) are the \riht" ones or the kind o models we were taretin. shit and SMART AHS code is sinicantly more compact. The shit implementation o SMART AHS consists o 3,300 lines o shit code and 2,000 lines o C leacy code 10, plus about 5,000 lines or the ull shit runtime 11. The Houston-Metro case study consisted o 9 However, the slow down is due mainly to the current implementation o sets in shit. New tests will be perormed with a new implementation which will improve on the memory usae o the internal data structures. 10 Mostly, I/O routines or the uploadin o the enine model data. 11 Which includes all the necessary development hooks, GUI hooks, C API and Forein Function Interace. 3,800 additional lines o shit code. The predecessor o SMART AHS (SMART AHS C++ ) consisted over 20,000 lines o C++ code, without the code or the distributed merin controller and the hihway buildin The SMART AHS ramework has a very small set o \how-to-use" rules that a prorammer needs to know about. As a result new users can immediately become more productive in application development. Based on our experience with the previous incarnations o SMART AHS, rameworks based on C/C++ usually have too many \how-to-use" rules that are not enorced by any compiler and result in unpredictable run-time errors i not ollowed properly. O course these remarks can be taken as a simple recipe or \ood enineerin practice", yet we claim that the overall desin o the tools did pay o considerably. The entire simulation study o the Houston Katy Corridor was built rom scratch (i.e. the hihway layout, the vehicle dynamics models, the mere and cruise protocol and the actual simulation runs) in less that three work weeks. The mere simulation case study is bein ollowed by more complex studies reardin emissions evaluation, coordination protocols involvin radio communications, \platoonin" o cars on automated hihways, and detailed physical simulation o crash and \nearmiss" situations or saety analysis.
type Controller output continuous number acceleration; state Vehicle the vehicle, side lane vehicle; continuous number same lane accel; number nominal speed; discrete cruisecruise law; yield yield law; ow deault same lane accel = track acceleration(same lane rel speed, xdot(the vehicle), nominal speed); ; cruise law acceleration = same lane accel; ; yield law acceleration = min(same lane accel, side lane accel) ; transition cruise -> yield when rear xp(the vehicle) >= L ap visible rane(junction) and exists mp in merin vehicles(junction) : ((rear xp(mp) >= ront xp(the vehicle)) and (rear xp(mp) <= ront xp(the vehicle) + lateral sensor rane) and (xdot(the vehicle) <= xdot(mp) + yield rel speed threshold)) do side lane vehicle := mp;, Fiure 3: A rament o the Controller code. The rament shows the transition that takes the (instance o) the Controller o the vehicle rom the cruise to the yield state. The condition upon which this transition is allowed is expressed in the when clause. The variables suxed by xp and yp represent positions. The accessor xdot(the vehicle) is interated to the current speed o the vehicle. When the transition has taken place, the interation will use a modied set o equations to produce the value or the acceleration parameter, whose computation eventually relies on a C unction (track acceleration). These projects simply extend the ramework or chane the simulation ranularity, conrmin our claim that the level o abstraction provided by shit and SMART AHS is the proper one. Other shit applications developed within UCB Mechanical Enineerin and Electrical Enineerin departments also conrm that the model/simulate/analyze cycle improves considerably when compared to more traditional approaches applied to similar problems. 3.2.1 Preliminary Cost Analysis The overall shit desin and development took about 18 months or a core roup, averain six people (thouh the complete list o people who actually contributed is much loner). The rst version o shit became available in September o 1996 and it did not include many o the eatures that were introduced later, durin the winter o 1996/97. Cur-
rently there are ve projects directly unded by either PATH or the NAHSC that are usin shit and SMART AHS. These projects directly involve about 20 people or the development and the interpretation o the simulation results. New projects will be added to this list as the FY 98, as the NAHSC expands and redirects its eorts. The cost or the Houston case study turned out to be in the order o 3 men/month. Subsequent projects (emission control simulation, platoonin and coordination) reused much o the overall structure developed in the rst place or the Houston Case Study and showed a aster turnaround o the simulation results. SHIFT is used in other application domains such as autonomous underwater vehicles, and air trac manaement simulations. However, our roup has not undertaken a ormal project trackin eort in order to evaluate the overall impact o the technoloy outside Caliornia PATH. 4 Conclusion In this paper we presented shit: a new prorammin lanuae based on theoretic concepts emerin rom the eld o hybrid systems. We have claimed that shit oers the proper level o abstraction or describin complex applications such as automated hihway systems, air trac control systems, robotic shop oors, coordinated submarines and other systems whose operation cannot be captured easily by conventional models. To support our claim we have described our experience with the SMART AHS ramework or the simulation o complex hihway systems. Our experience indicates that shit and SMART AHS do achieve the objectives that were at the base o its desin. In particular, shit is currently enjoyin a rowin popularity and is bein used as a teachin tool in various courses in the Electrical Enineer Department o UC Berkeley. Future work on shit will include the ollowin items: urther research on the interaction between the interation and uard crossin alorithms; parallelization and distribution o the run-time system; interation with automated verication systems such as Kronos [6]. As already mentioned, at this point we cannot provide a direct comparative study o the \simulation development costs" or shit and SMART AHS with respect to a more traditional approach based on standardized libraries. Settin up such a study would require a considerable eort in itsel and the identication o a proper set o tools to compare shit and SMART AHS aainst. However, the eedback we athered rom the users o shit makes us very condent that the results would tip the balance in its direction. 5 Acknowledments We wish to thank all the people at Caliornia PATH and elsewhere, especially A. Deshpande, F. Eska, A. Girault, M. Kourjanski, J. Misener, V. Murier, L. Semenzato, J. Sousa, P. Varaiya, D. Weismann, S. Yovine, and the National Automated Hihway System Consortium 6 Availability O course, shit and SMART AHS can be downloaded or ree under a UCB-style license rom our home paes http://www.path.berkeley.edu/ http://www.path.berkeley.edu/shit http://www.path.berkeley.edu/smart-ahs and our tp site tp.path.berkeley.edu:pub/path/shift tp.path.berkeley.edu:pub/path/smart-ahs Reerences [1] R. Alur, C. Courcoubetis, T. A. Henziner, and P. Ho. Hybrid Automata: An Alorithmic Approach to the Specication and Verication o Hybrid Systems. In R. L. Grossman, A. Nerode, A. P.
Ravn, and H. Rischel, editors, Hybrid Systems, volume 736 o Lecture Notes in Computer Science, paes 209{229. Spriner-Verla, 1993. [2] M. Antoniotti, A. Deshpande, and A. Girault. Microsimulation analysis o automated vehicles on multiple mere junction hihways. In Proceedins o the IEEE Conerence on Systems, Man, and Cybernetics (SMC97). IEEE, October 1997. [3] M. Antoniotti, A. Deshpande, and A. Girault. Microsimulation analysis o multiple mere junctions under autonomous ahs operation. In Proceedins o the IEEE Conerence on Intellient Transportation Systems (ITSC97). IEEE, November 1997. [4] F. Barros. Dynamic Structure Discrete Event System Specication Formalism. Transactions o the Society or Computer Simulation, 1:35{46, 1996. [5] H. Boehm and M. Weiser. Garbae Collection in an Uncooperative Environment. Sotware Practice and Experience, paes 807{820, September 1988. [6] C. Daws, A. Olivero, S. Tripakis, and S. Yovine. The tool kronos. In Hybrid Systems III, Verication and Control, volume 1066 o Lecture Notes in Computer Science. Spriner-Verla, 1996. [7] A. Deshpande, A. Gollu, and P. Varaiya. A Formalism and a Prorammin Lanuae or Dynamic Networks o Hybrid Automata. In Hybrid Systems IV. Spriner-Verla, 1997. [8] F. Eska, D. Khorramabadi, and P. Varaiya. An Automated Hihway System Simulator. Transportation Research Journal, part C, 3(1), 1995. [9] D. Harel. Statecharts: A Visual Approach To Complex Systems. Science o Computer Prorammin, 8(3):231{275, 1987. [10] F. Maraninchi. The Aros Lanuae: Graphical Representation o Automata and Description o Reactive Systems. In Proceedins o the IEEE International Conerence on Visual Lanuaes. IEEE, 1991. [11] S. E. Mattson and M. Anderson. The Ideas Behind Omola. In Proceedins o the IEEE Symposium on Computer Aided Control System Desin, CADCS 1992. IEEE, March 1992. [12] R. Milner, J. Parrow, and D. Walker. A calculus o mobile processes, I and II. Inormation and Computation, 100(1):1{77, September 1992. [13] H. Praehoer, F. Auerni, and G. Resiner. An Environment or DEVS-based Multiormalisms Simulation in Common Lisp/CLOS. Discrete Event Dynamic Systems: Theory and Application, 3(2):119{ 149, 1993. [14] J. T. Schwartz, R. B. K. Dewar, E. Dubinsky, and E. Schonber. Prorammin with Sets. An Introduction to SETL. Spriner-Verla, 1986. [15] P. Varaiya. Smart Cars on Smart Roads: Problems o Control. IEEE Transactions on Automatic Control, 38(2):195{207, February 1993. [16] B. Zeiler. Multiaceted Modelin and Discrete Event Simulation. Academic Press, London, Orlando, 1984.