Design and Evaluation Tools for Automated Highway Systems

Design and Evaluation Tools for Automated Highway Systems Akash Deshpande and Pravin Varaiya [email protected], [email protected] Department of Electrical Engineering and Computer Sciences University of California, Berkeley, CA 94720

1 Introduction The Automated Highway Systems (ahs) project at UC-Berkeley is part of a comprehensive program initiated by the U.S. government under the Intermodal Surface Transportation Eciency Act of 1991 to improve safety and reduce congestion in the surface transportation system. UC-Berkeley's path Laboratory is part of a nine-member consortium along with General Motors, Bechtel, Parsons Brinckerho, Martin Marietta, Delco, Hughes, Caltrans, and Carnegie Mellon University. The consortium is funded by the Federal Highway Authority and it is responsible for designing, evaluating, and demonstrating a prototype ahs. There is also substantial related activity in Europe under the prometheus1 and the drive2 projects, and in Japan under the racs3 , amtics4 and vics5 projects. In the rest of this section we present a brief description of the path hierarchical control architecture for ahs. In section 2 we present the framework for ahs design and evaluation and give a summary of simulation and analysis tool needs. In section 3 we describe Smartahs, a hybrid system microsimulator that constitutes an important design and evaluation tool for ahs. In section 4 we present a summary and indicate opportunities for collaboration in the ahs tool development eorts.

1.1 The PATH AHS Architecture

The path Program at UC-Berkeley has proposed a hierarchical control architecture that yields up to a four-fold increase in transportation capacity while enhancing safety [4, 3]. The architecture proposes a strategy of platooning several vehicles as they travel along the highway. The separation of vehicles within a platoon is small (2m) while separation of platoons from each other is large (60m). The movement of vehicles is realized through simple maneuvers|join, split, lane change, entry, and exit|that are coordinated. The automation strategy of the path ahs architecture is organized in a control hierarchy with the following layers: Physical Layer| the automated vehicles. The vehicle dynamical models are given in terms of nonlinear ordinary dierential equations. Program for European Trac with Highest Eciency and Unprecedented Safety Dedicated Road Infrastructure for Vehicle Safety in Europe 3 Road/Automobile Communication System 4 Advanced Mobile Trac Information and Communication System 5 Vehicle Information and Communication System 1

2

1

Regulation Layer| control and observation subsystems responsible for safe execution of simple maneuvers such as join, split, lane change, entry, and exit. Control laws are given as vehicle state or observation feedback policies for controlling the vehicle dynamics. Coordination Layer| communication protocols that vehicles and highway segments follow to coordinate their maneuvers for achieving high capacity in a safe manner. The protocols are given in terms of nite state transition systems. Link Layer| control strategies that the highway segments follow in order to maximize throughput. Control laws are given as trac state and observation feedback policies for controlling the highway trac using activity ow models. And, Network Layer| end-to-end routing so that vehicles reach their destinations without causing congestion. Control laws are given in terms of uid ow and queuing models.

The physical, regulation, and coordination layers reside on each vehicle and the link and network layers reside on the roadside. To avoid single-point failures and to provide maximum exibility, the design proposes distributed multi-agent control strategies. Each vehicle and each highway segment is responsible for its own control. However, these agents must coordinate with each other to produce the desired behavior of high throughput and safety. The path architecture demonstrates hybrid system characteristics in three signi cant ways.  Interaction between the coordination and regulation layers. The coordination layer acts as a planning and supervisory controller that selects maneuvers to be executed by the vehicle based on safety and throughput considerations. It then directs the regulation layer to activate the appropriate feedback control laws for controlling the vehicle dynamics. This illustrates the usual hybrid control con guration treated in literature wherein a discrete event controller supervises a continuous parameter plant.  Interaction between the link and coordination layers. The link layer acts as an optimizing controller that selects vehicle activity pro les on highway segments based on throughput optimization considerations. It then directs the vehicles' coordination layer controllers to select maneuvers consistent with the desired activity pro les. This illustrates a novel hybrid control con guration wherein a continuous parameter controller directs the behavior of a discrete event plant.  Switched modes of operation. The system's operating modes are switched when available system capability changes due to events and weather conditions.

2 Framework for AHS Design and Evaluation The path ahs architecture is one amongst several possible ahs design concepts. For example, it is possible to envision ahs employing one or more of the following approaches: fully centralized control of all vehicles on the ahs, fully automated but uncoordinated vehicles, semiautomated 2

vehicles requiring active driver participation, mixed automated and manual vehicles on the ahs, and dierent entry and exit con gurations, amongst others. The ahs consortium is responsible for identifying several ahs design concepts, evaluating and selecting six of these for detailed study, specifying, evaluating and selecting three ahs designs from these six concepts, and nally synthesizing a single ahs design from the three. Dierent categories of tools are required to accomplish these tasks. Signi cant amongst these are simulation tools for system-level ahs simulation, technical analysis tools for safety, highway productivity, comfort, environmental impact, and cost, and design tools for vehicle, highway, communication, driver interface, and other technologies. We present a framework in which these tool needs can be discussed (see [1]). An ahs design consists of four speci cations: vehicle design, infrastructure design, ahs operating rules, and design failure events. An ahs is designed for deployment in an environment speci ed in terms of benchmark scenarios . The benchmark scenarios are given in terms of highway con guration, travel demand, weather conditions, and abnormal events. The performance of an ahs design under the speci ed benchmark scenarios is judged by a set of performance metrics . The performance metrics are employed to rank viable designs. The design tools aid the design of ahs-related modi cations of existing technologies and components and ahs-speci c development of new technologies. The evaluation tools provide the following: 1. A uniform language or templates for describing the ahs designs, the benchmark scenarios, and the performance metrics. 2. A set of analytical and simulation approaches for evaluating the performance of a speci ed ahs design, under a speci ed scenario, with respect to a speci ed metric. The results of these exercises are used by evaluators to compare dierent designs. The results are also used by ahs system designers to re ne their designs. To lay the foundation for developing the tool requirements, the three succeeding subsections provide more detail about the elements of ahs design, benchmark scenarios, and performance metrics.

2.1 AHS Design

Every ahs design or concept comprises four elements: vehicle design, infrastructure design, ahs operating rules, and failure events.

2.1.1 Vehicle Design The vehicle design comprises conventional vehicle design and ahs-speci c design. The conventional design includes the engine, powertrain, weight, size and other parameters that determine the capabilities of each vehicle type. More detailed speci cations include the variations in these parameters, their changes over time, the likelihood of defects and faults, and so on. The ahs-speci c design includes on-board sensors, communication devices, control algorithms and actuators. Possible on-board sensors include those measuring the vehicle's own state (self-state sensors), those sensing the infrastructure (roadway geometry sensors), those gathering the information about its surroundings (trac sensors and stationary object sensors) and driver state sensors. The selfstate sensors can be used to measure parameters such as engine speed, vehicle speed, air manifold temperature, acceleration, yaw, roll, and weight. (Vehicle's weight may also be measured by the infrastructure and communicated to the vehicle by the infrastructure.) Roadway geometry sensors are needed to recognize relevant roadway geometric parameters, e.g. lane markings, lane merge, 3

lane division, and curve. Trac and stationary object sensors are needed to ensure safe vehicle movement and maneuvers. Driver state sensors may also be needed for safe transition from automated driving mode back to manual driving mode. Communication devices include those equipped for vehicle-infrastructure and vehicle-to-vehicle communication. Given the sensed and communicated information, the control algorithms command the vehicle's actuators for automated steering, propulsion and braking.

2.1.2 Infrastructure Design

The infrastructure design comprises the highway con guration such as the number and size of automated and manual lanes and how they are separated (whether by a physical or symbolic barrier), and the manner in which vehicles move between manual and automated lanes (whether via a transition lane or dedicated access ramps); the roadway facilities for check-in and checkout; arrangements for emergency vehicles; arrangement for non-compliant vehicles or drivers; the interfaces with urban arterials and other non-ahs roadway facilities; the distance between entrances and between exits; toll collection facilities. Whether the ahs is for urban or rural use is implied by the highway con guration. Infrastructure design also includes the sensors located in the roadway for assisting vehicle maneuvers and monitoring trac, such as magnetic or other markers, beacons, vision surveillance, loop detectors, and weigh-in-motion scales. Lastly, the infrastructure design includes the communication system for roadway-vehicle, roadwayroadway, and roadway-Trac Management Center communication.

2.1.3 Operating Rules The operating rules specify the ways in which vehicles are controlled individually, how they interact, and how their collective behavior is managed. An example of such a speci cation follows. The ahs operating rules can be speci ed in a multi-layered hierarchy comprising the physical, regulation, coordination, link and network layers. Each of these ve layers is brie y described below and example functions are also provided.  





The physical layer, which gives the vehicle dynamics, is obtained from the vehicle design and is not, strictly speaking, a part of the operating rules. The regulation layer describes the feedback laws that describe how the vehicle's throttle, braking and steering actuator signals are computed as a function of the sensor signals. This layer incorporates the operating rules about speed, spacing, lane changing, and entrance into and exit from the automated lanes. The coordination layer describes how neighboring vehicles coordinate their movement in order to facilitate maneuvers that aect each other. Coordination may be explicitly organized via inter-vehicle communication, or it may be implicit in the assumptions that each vehicle's controller (may be human) makes about the movement of its neighbors. The degree of explicit coordination is a parameter in the design of the operating rules. The link layer describes how the roadway (infrastructure) intervenes in the trac ow. This consists of feedback laws that order or guide the speed and path of individual vehicles in a section of the automated lanes, as a function of the sensor data that is available. 4



The network layer describes the rules that control the entry and exit of vehicles into and from the ahs. If the necessary infrastructure is in place, this layer includes the feedback laws that govern the metering of entry. If the ahs permits entry of multiple vehicles types (e.g., light and heavy duty vehicles) this layer determines how their entry is scheduled. If there is priority of use (e.g., transit and high occupancy vehicles over private automobiles, and emergency vehicles over all others) this layer selects the priority rules. This layer can also assist the link layer in path assignment to ensure a high rate of exit success.

An operating mode or regime is a collection of compatible rules for each layer. The system's operating modes are switched when available system capability changes due to events or weather conditions. There are at least two modes: normal mode and degraded mode. Normal mode assumes that the ahs is operating within normal conditions. Under fault conditions, or in adverse environments, the system is operated in a degraded mode. In an extreme form of a degraded mode, for example, vehicles in the automated lane are brought to a standstill, waiting for emergency assistance. Of course, dierent sections of the ahs may (indeed, will) operate under dierent modes at the same time.

2.1.4 Failure Events Failure events specify vehicle and infrastructure component failures and the resultant loss of system capabilities that are possible in the design. Associated to the failure events are their rates and distributions.

2.2 Benchmark Scenarios

The benchmark scenario, or operating environment, is speci ed by highway con guration, travel demand, weather, and fault events. Collectively, the environment stresses the ahs. The environment may be speci ed in terms of \base" cases and as a \parametrized" family.

2.2.1 Highway Con guration The highway con guration speci es the physical con guration of the highway including such attributes as number and arrangement of manual and automated lanes, exclusive rights of way, types of barriers (symbolic, physical) used to separate them, the interfaces between manual and automated lanes and non-ahs arterials, amongst others.

2.2.2 Demand The demand speci es the ahs trips, either as a trace or statistically, dierentiated by vehicle type, entry, exit, time of day, and location. The demand acts as \inputs" to the ahs, just as vehicles leaving the ahs act as \inputs" to the non-ahs system.

2.2.3 Weather The weather speci es the conditions of the roadway that can aect the capabilities of the vehicles, sensors, and operating rules. For example, a slippery road surface reduces the vehicles' maximum acceleration and braking, and fog or rain may reduce the capabilities of vision or other sensors.

5

2.2.4 Abnormal Events Abnormal events specify instances of faults and malfunctions, collisions and other rare events. Events, too, are speci ed statistically or as a time trace. Events may cause the ahs operation to switch between operating modes.

2.3 Performance Metrics

The dierent ahs designs will be evaluated by ve stakeholders: the government, auto industry, insurance industry, the users, and public interest groups. Users include operators of automobiles, transit vehicles, and trucks, amongst others. Each of the ve stake holders will examine the ahs performance metrics of its interest and evaluate the ahs concepts and design. For convenience of discussion, related metrics are grouped into classes. For the purpose of identifying tool needs we consider the following performance metric classes and subcategories.

2.3.1 Safety 1. Collision rates: the expected number of collisions per vehicle kilometer traveled 2. Injury rates: the expected number of injuries of dierent AIS types per vehicle kilometer traveled 3. Total property damage and medical expenses per vehicle kilometer traveled 4. Collision-free guarantees under fault-free conditions: A guarantee that the design does not lead to a collision when no failure events or abnormal events occur 5. Fault tolerance: the number and types of faults and fault combinations despite which the design does not lead to collisions

2.3.2 Productivity 1. Throughput: source-destination ows in vehicles per hour and passengers per hour for each type of vehicle 2. Delays: expected travel time between source-destination pairs 3. Travel time predictability: variance of the above delays 4. Entry and exit productivity: trac ows through entries and exits, delays at entries and exits, queue lengths, and exit success rates. 5. Non-ahs impact: locally, the buer and throughput requirements imposed on non-ahs arterials by the ahs; globally, the network level abstraction of the ahs leading to changes in trac patterns and driver behavior

2.3.3 Comfort 1. Maximum longitudinal and lateral acceleration 2. Maximum longitudinal and lateral deceleration 6

3. Maximum speed 4. Separation and closing rates: separation between vehicles and the relative velocity and acceleration during maneuvers such as join or lane change. 5. User interface: driver interface within the vehicle to access ahs features, and feedback information provided to driver from the ahs. 6. Complexity of ahs driving tasks

2.3.4 Environmental Impact

1. Air pollution: emissions of carbon monoxide, hydrocarbons, and nitrous oxides by vehicle type and per vehicle kilometer traveled. 2. Fuel consumption: consumption of fuel per vehicle kilometer traveled for each vehicle type. 3. Noise pollution: eect of trac speed, volume, acceleration pro les, tire designs, sound walls and elevated structures on noise pollution. 4. Land use: local issues such as land used in construction of the ahs highways and global issues such as impact on regional trac patterns.

2.3.5 Cost 1. 2. 3. 4.

Infrastructure modi cation cost: cost of building the ahs infrastructure. Vehicle modi cation cost: cost of building the ahs vehicles. Operating cost: cost of operating the ahs. Macroeconomic impact: overall economic bene ts of the ahs such as job creation, technological advantages, and economies of scale.

An important characteristic of a design not measured by the above metrics is its exibility to satisfy the demands of dierent operating constraints. For example, dierent local administrations may choose to impose dierent constraints on the operation of the ahs within their domain of control. Similarly, dierent constraints may be imposed based on the time of day, allowing, for example, exclusive use of the ahs by heavy vehicles between midnight and 6:00 AM. The exibility of the design can be judged partially by variations in the performance metrics for dierent benchmark scenarios. To judge completely the exibility of a design, further qualitative investigations may be required.

2.4 Evaluation Methodology

Evaluating a single design or comparing alternative designs requires a methodology of using analysis and simulation tools. These tools provide formal or standardized languages or templates for specifying ahs designs, benchmark scenarios or the environment, and performance metrics. Standardization facilitates the objective comparison of dierent alternatives and promotes meaningful communication among dierent groups. The formal structure may be in the language of mathematics or in a programming language, assisted by aids such as block diagrams and other user-friendly interfaces. 7

Design Feedback

AHS Design

Simulation Tools

Vehicle Infrastructure Operation Events

Analysis Tools

Safety Benchmark Scenarios

Capacity

Highway Traffic Weather Events

Comfort

Environment NonAHS Models

Safety Collision Rates Injury Rates Collision−free Guarantees Fault Tolerance Productivity Throughput Delays Travel Time Predictability Exit Success Rate Non−AHS Impact Comfort Maximum Acceleration Maximum Deceleration Maximum Speed Separation and Closing Rates User Interface Environmental Impact Air Pollution Noise Pollution Land Use Cost Infrastructure Modification Vehicle Modification Operating Costs Fuel Consumption Macroeconomic Impact

Cost Tool Interaction

Figure 1: Evaluation Tools The relationship between the ahs design, benchmark scenarios, performance metrics and evaluation tools is shown in Figure 1. Once an ahs design, environment and performance metric are speci ed, one or several tools may be used to evaluate the performance of the design. Symbolically, if D stands for design, E for environment, and P for performance metric, all formally speci ed, then an appropriate tool evaluates the functional relationship, P

= f (D; E )

For two reasons, a suite of tools rather than a single tool will be needed. First, dierent performance metrics may require dierent formalizations, and, second, the design, environment and performance metric may be modeled with dierent levels of emphasis or abstraction. It is expected that dierentiating among initial designs may be carried out by tools that require relatively abstract models. Designs that survive this initial screening can only be compared using more detailed speci cations. Objective comparisons will now require a uni ed framework that is capable of representing faithfully greater levels of detail. Tools that provide such a framework will then also be incorporated into the design process (see Figure 2). Three roles are involved in the tool use for evaluation of ahs designs: the evaluator, the ahs designer, and the tool designer. The evaluator chooses the performance metric to be analyzed, and picks a suite of evaluation tools to be used for this purpose. The ahs designers and the tool designers collaborate to model the design in terms of the input parameters of the tools. This may entail the use of additional tools as pre lters to process the design, and it may also entail modi cation of the evaluation tool. Similarly, the tool designers and the evaluator collaborate to model the chosen benchmark scenario in terms of the input parameters of the tool. After using the tools to generate the performance metrics, all three collaborate to interpret them. At this stage, decision support tools may be required to collate the large arrays of design performance metrics using utility-directed aggregation functions. 8

Metrics

AHS Concept

AHS

Performance

Specification

Design

Evaluated by

Evaluation Tools

Design Redesign

Tools

Figure 2: ahs Design Process

2.5 Design and Evaluation Tools

Design tools are required for developing sensors, actuators, controllers, communications, fault management, and driver interfaces. Sensors comprise vehicle and roadside sensor models, sensor performance, and sensor fusion. Actuators comprise vehicle actuator models and performance, vehicle dynamical models and parameter databases. Controllers comprise regulation layer emulators and performance, coordination layer protocol simulators and veri ers, and link and network layer controllers. Communications comprise vehicle-vehicle, vehicle-roadside, and roadside-tmc communications using infrared, radio, satellite, ber and other channels. Fault management comprises fault prediction or detection, diagnosis, tolerance, and recovery. Driver interface comprises interface design and driver tness testing. Evaluation tools are required for system- and component-level simulation and technical analysis to yield performance metrics for a given design and benchmark scenario. The Smartahs system simulator is discussed in the next section. Analysis tools are required for estimating safety, productivity, comfort, environmental impact, and cost metrics. The input parameters of most of the analysis tools are speci ed in terms of the detailed quantitative or qualitative behavior of the design. Such parameters are not easily available and hence Smartahs-based design microsimulations are central to the functioning of most of these tools.

3 Smartahs|a Hybrid System Simulator Smartahs is a microsimulator for dierent ahs designs and scenarios. Smartahs can be used to describe layered control architectures with several granularities of time- and event-driven simulation requirements. For example, it can model the path control hierarchy consisting of the physical, regulation, coordination, link, and network layers. While the regulation layer is time-driven, the coordination layer is event-driven. The network layer is both time- and event-driven. Smartahs can be used to specify distributed agent control laws with both discrete event and continuous variable feedback and coordination. For example, each vehicle and highway segment have their own sensors, actuators, transmitters, receivers, and control policies. Smartahs can be used to describe dierent modes of system operation in terms of dierent dynamical models and control policies. For example, under abnormal weather conditions such as rain or ice, the system can activate dierent brake models and join control laws. Smartahs has a scalable distributed processing architecture which makes it suitable for largescale simulations. For the prototype implementation, a single Sun Sparc 10 workstation can simulate 9

up to 50 vehicles in real time. With software and hardware enhancements, we expect the distributed processing simulation software to scale to 100,000 vehicles and 1000 miles of highways for non-real time simulation. Smartahs provides full access to system state and state trajectories by saving them into a database. Consequently, Smartahs can be used to specify various state monitors that inspect components of the system state to generate dierent performance metrics both on-line and o-line. For example, occurrence of collisions can be checked on-line, while fuel eciency and air pollution can be checked o-line. Simulation runs can be stopped, changed, and continued for full control over the simulation scenarios. Consequently, trac events and weather conditions speci ed in the benchmark scenarios can be introduced during runs using the simulation control mechanism. Smartahs provides graphical user interfaces for specifying the inputs, controlling the simulation runs, and visualizing the outputs. For example, highway con gurations in a benchmark scenario can be speci ed graphically using a highway editor. Similarly, the vehicle traces can be visualized graphically. Smartahs can interface to non-ahs trac simulators such as Integration, FreeSim, and NetSim using link or network layer interfaces, and it can interface to vehicle simulators using regulation layer interfaces.

3.1 Object Management Systems

Smartahs is developed using the Object Management Systems (oms) object-oriented approach. This approach provides the oms object model, the Smartdb software platform implementing this object model, and the OMS model-based software engineering life-cycle. Object Management Systems are object-oriented software systems for simulating, evaluating, and controlling large-scale physical environments. Examples of such environments are transportation networks, telecommunications networks, power distribution networks, air trac control, and management information systems. These environments are heterogeneous, dynamic, and distributed. oms provide the following functions.6 Con guration Management| the ability to specify and control the con guration of the physical environment; Fault Management| the ability to detect faults and signi cant events in the physical environment, to respond to them with graceful degradation of system performance, and to recover from them; Performance Management| the ability to track, optimize, and ne-tune the physical system performance; Accounting Management| the ability to account for physical system usage and charge the users according to pricing policies; Access and Security Management| the ability to specify and control users' access to the physical system in a multi-user operating environment; 6

These functions are based on the osi nm/Forum functional categories for network management[2].

10

Resource Management| the ability to provide an inventory of all physical system resources and to administer their maintenance schedules; Planning Management| the ability to specify, simulate, and evaluate alternative physical system con gurations and control policies.

3.2 The OMS Object Model

The oms object model is derived from two streams of theoretical development: object-oriented modeling and mathematical systems theory. We give a brief description of the model features.

3.2.1 State An object's attributes describe its state, inputs, and outputs. The system is a collection of objects, and its state can be thought of as the state of individual objects along with their input-output interconnections. The system as a whole has inputs and outputs corresponding to the free inputs and outputs of objects in it.

3.2.2 Methods The methods of an object are memoryless (or reentrant) maps from its state and input to a new state and new outputs. Methods can encode object behaviors using dierent kinds of deterministic, nondeterministic, or stochastic dynamical models such as nite state machines or dierential equations. In addition, a method can specify new objects to be created, existing objects to be deleted, new input-output connections to be made, and existing input-output connections to be removed. Each method also speci es its triggering inputs and triggered outputs.

3.2.3 State Transitions The system is activated by triggering some subset of its inputs. All object methods triggered by these inputs are executed. The outputs of these executed methods themselves trigger other methods, which are then executed, and so on. We require, and impose conditions to ensure, that this method execution sequence is unique (i.e., there are no race conditions or indeterminacies) and that it is nite (i.e., it terminates). If such an execution sequence satis es all system constraints, then the system state at the end of the sequence is committed; otherwise it is rolled back to the beginning of the sequence and the triggering input is discarded.

3.2.4 Constraints Constraints of four types are de ned: State constraints| constraints on the values of the state, inputs, and outputs of an individual object; Connection constraints| constraints on establishment of input-output connections between objects; 11

Object 1

Free Inputs

Object 1

Object 3

Object 3

Free Outputs Triggering Input

Object 2

Successive Method Triggerings

Object 1

Object 2

Object 3

Object 2

Object 4

Method

OMS

Check constraints before commiting state transition

Create new object and connect it

OMS Engine

OMS Engine

Triggered Output

OMS Engine

Figure 3: (a) A Sample oms. (b) Triggering Input. (c) State Transition. Relationship constraints| state constraints expressed over several objects that are related through relationships; and Behavior constraints| state constraints that must be satis ed before and after the execution of a single method of an object.

Figure 1-a shows a sample oms with three interconnected objects. Figure 1-b shows a triggering input applied to the oms and the method that it triggers. Figure 1-c shows the eect of the state transition caused by this triggering input: creating a new object and connecting it to existing objects through input-output relationships, and computing the triggered output of the system. Note the resemblance of this oms data and process model to integrated circuit diagrams, output feedback control systems, Petri nets, and neural networks.

3.2.5 Distribution Because of the restrictions imposed on the state transitions, the expressive power of a stand-alone oms is less than that of recursively enumerable languages. This is so by design: formal tools are available for synthesis, veri cation, and testing in the case of regular languages and some context free and context sensitive languages. The restricted expressive power of a stand-alone oms enables us to exploit such tools. However, a combination of two or more interacting oms can be used to obtain the full expressive power of recursively enumerable languages. Such a combination can be used to realize distributed and hierarchical system architectures. For example, we use a hierarchy of three oms to implement time- and event-driven scheduling (see [7]).

3.3 Smartdb, Smartahs, SmartPath

Smartdb is a software implementation of the oms Object Model. In addition to the implementation of this model, Smartdb provides several additional features:  It implements a relationship object and provides speci c and useful relationships such as input-output, containment, views, agent-manager, client-server, and process layers; (A process layer is a collection of objects scheduled for execution at a common time- or event-granularity. Process layers are used to build layered or hierarchical system architectures.)  It implements commonly used objects such as events, sensors, actuators, schedulers, and users; 12

It implements the oms Engine|the machinery that executes the model dynamics. The oms Engine provides an interface for creating and deleting objects, connecting and disconnecting them, triggering methods, executing state transitions, checking constraints, propagating event noti cations, and providing event- and time-based scheduling; and  It provides system architecture tools for data distribution, process distribution, object migration, process migration, packaging objects into process layers based on their scheduling requirements, versioning, concurrency control, backup and restore, schema evolution, and other utilities. We have customized Smartdb to form the Smartahs and SmartPath platforms for highway system simulation and evaluation. Smartahs is used to capture dierent ahs designs and benchmark scenarios and to generate performance metrics through micro-simulation of the designs. Smartahs provides generic objects for modeling highway con guration, vehicles, control and communication agents, and performance monitors. Smartahs also provides a scheduler that simulates time- and event-driven object behaviors. The scheduler is con gurable and it can simulate objects at dierent time scales. Vehicle movement, for example, may be scheduled every 100ms and roadside controllers every 15s. Smartahs provides the following object implementations. Highway objects: lane segment, highway section, entry, exit, and zone; vehicle objects: vehicle, engine, brakes, steering, sensors, transmitters, and receivers; and process layers: physical, regulation, coordination, link, and network. Data and processing distribution is based on zones. The SmartPath oms is obtained when the path ahs architecture described above is implemented in Smartahs [5, 6]. SmartPath consists of specialized objects and their behaviors given in terms of dynamical system models such as dierential equations, nite state machines, uid ows, and queuing networks, and it also speci es sensors, actuators, transmitters, receivers, control and communication policies, and operating rules. The SmartPath simulation setup consists of seven speci cations: highway con guration, travel demand, weather conditions, highway automation devices, vehicle automation devices, and the simulation scheduling policy. (Automation devices consist of sensors, actuators, communications devices, and control agents.) Simulation runs are used to collect design performance metrics such as safety, productivity, comfort, and environmental impact, generated by monitoring the system state during the simulation runs. Smartahs can be used to optimize design performance with respect to these metrics by tuning design parameters dynamically. SmartPath simulation performance depends on the time-granularity of the simulation. If the integration routines used to calculate vehicle displacement are set to 5{50ms step size, and vehicle position on the highway is updated every 100ms, 50 vehicles can be simulated in real-time on a Sun Sparc 10 workstation. (The integration step-size is dynamically adjusted by Smartahs based on vehicle displacement.) Simulation pro les indicate that 80% of the simulation time is spent on time-driven simulation of the dierential equations that model vehicle dynamics. Implementing these on a vector parallel processing system is expected to speed up the simulation signi cantly. A distributed processing version of SmartPath is under implementation for problem scales as large as 100,000 vehicles over 1000 miles of highways. Once an ahs design is simulated, evaluated, and optimized, Smartahs can be used with hardware emulators as well as actual hardware components instead of software sensors and actuators. This aids model validation and robustness testing of the control laws. For full deployment, the regulation layer control algorithms can be deployed in vehicles and the link and network layer control algorithms can be deployed on the roadside. In this environment, Smartahs acts as a distributed operating system for command and control of the deployed ahs. 

13

4 Conclusions We have presented a brief description of the Automated Highway Systems project and have discussed the path design for ahs. The design proposes a hierarchical control architecture that can be modeled and analyzed using the hybrid systems approach. We have presented the framework for ahs design and evaluation and have given the tool needs for these tasks. We have discussed the Smartahs hybrid system microsimulator and have described the oms object model and the Smartdb software platform underlying the Smartahs implementation. The ahs design and evaluation program presents several opportunities for collaborative tool development eorts. Of special interest are tools for formal veri cation, controller synthesis, optimization, and automated testing of hybrid systems. While stand-alone tools that generate speci c performance metrics are useful, tools that integrate and interoperate with Smartahs are particularly important. These hybrid systems analysis and synthesis tools can use the oms object model as a starting point for developing decidable or otherwise tractable abstractions.

Acknowledgements The ahs project involves a large team of researchers, engineers, and technicians and we acknowledge their contributions. In particular, we are grateful to Datta Godbole, Aleks Gollu, and Jacob Tsao of path.

References [1] NAHSC Consortium. Task No. B4A: Tool Needs for AHS Design and Evaluation|Draft. April 1995. [2] OSI/Network Management Forum. \OSI Basic Reference Model." ISO 7498-1. 1992. [3] Steve Shladover et al. \Automated Vehicle Control Developments in the path program." IEEE Trans. Vehicular Tech. Vol. 40. pp. 114-130. Feb. 1991. [4] P. Varaiya. \Smart Cars on Smart Roads: Problems of Control." IEEE Trans. Automatic Control. Vol. 38, No 2. Feb. 1993. [5] A. Gollu, A. Deshpande, P. Hingorani, P. Varaiya. \SmartDb: An Object Oriented Simulation Framework for Highway Systems." Fifth Annual Conference on AI, Simulation and Planning in High Autonomy Systems. Gainesville, Florida. 1994. [6] F. Eska , Delnaz Khorramabadi, and P. Varaiya, \An Automatic Highway System Simulator." Transpn. Res.-C Vol. 3, No. 1, pp. 1-17, 1995. [7] A. Gollu. \Object Management Systems." Ph.D. Thesis, University of California at Berkeley. 1995.

14