Abstract:
The present invention is directed to a portable system for automatic data acquisition and processing of traffic information in real-time. The system incorporates a plurality of sensors operatively positioned upstream of a work zone or roadway incident with each of the sensors being adapted to detect current traffic conditions, at least one variable message device positioned upstream of the work zone or roadway incident, a plurality of remote station controllers, each operatively connected to the plurality of sensors and the variable message device, and a central system controller located within remote communication range of the remote station controllers, wherein the central system controller and the plurality of remote station controllers are capable of remotely communicating with one another. Each of the sensors is adapted to output traffic condition data to its corresponding remote station controller. The corresponding remote station controllers then transmit the traffic condition data to the central system controller. The central system controller automatically generates traffic advisory data based on the traffic condition data and transmits the traffic advisory data to the remote station controller that is connected to the variable message device. The traffic advisory data may also be used to communicate with and control highway advisory radio transmitters and ramp metering stations. Together, one or more variable message devices, highway advisory radio transmitters and ramp metering stations may be used to inform passing motorists of traffic conditions in and around a work zone or roadway incident, and thereby control and improve the safety and efficiency of traffic operations around such sites.

Description:
Work on the invention that is the subject of this application was conducted under the Work Zone Traffic Control System Cooperative Agreement with the Federal Highway Administration and the Maryland State Highway Administration. Both the Federal Government and the Maryland State Government may have rights in the invention as set forth in the above-referenced contract(s). 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention is directed to a system and method for the automated data acquisition and processing of traffic information in real time. Specifically, the present invention provides a system whereby up-to-the-minute information on the current traffic conditions surrounding a work zone or an incident on the road (e.g., a traffic accident) is communicated to drivers upstream of the work zone or incident via any number of independent visual or auditory display devices under common, wireless control. 
     2. Description of the Prior Art 
     Currently, systems used in controlling traffic conditions around work zones and incidents on the road are limited to the use of conventional static signs, flashing arrow signs, portable variable message signs (VMS) programmed with a single repeating message, or no signs at all. These methods provide little or no information useful to drivers for either avoiding the development of a traffic jam or finding alternative routes. Though portions of the highways close to large metropolitan areas are often equipped with permanently installed VMSs and traffic signal lights designed to control the in-flow or out-flow of traffic in the highways, there are large stretches of highways that lack any facilities for controlling the flow of traffic on the highway that are usable around work zones or incidents on the road. Rather, the same conventional methods with the same conventional equipment as described above are used and provide the same limited information to drivers. Even if permanently installed VMSs are available, current methods in the use of such devices also provide very limited information for drivers in avoiding traffic jams due to the presence of work areas and/or roadside incidents, and such information is not credible because the messages they convey are typically not appropriate to existing conditions. 
     Therefore, there exists a need for a system that can provide up-to-the-minute information on the current traffic conditions around a work zone or roadway incident such that drivers are able to use information to either change their speed or lane position to avoid traffic jams, or find and navigate alternative routes. 
     Finally, there exists a need for a system that can monitor the current traffic conditions such that the data provided by the system to drivers on the road is understood to be pertinent to those current conditions, at a specified point in time, thereby maximizing the usefulness of the outputted information. 
     SUMMARY OF THE INVENTION 
     One of the main objectives of the present invention, therefore, is to make available a system that can provide up-to-the-minute information on the current traffic conditions around a work zone or roadway incident such that drivers are able to use information to either change their speed or lane position to avoid traffic jams or find alternative routes. 
     Concurrently, another main objective of the present invention is to provide a system that can monitor the current traffic conditions such that the data provided by the system to drivers on the road is pertinent to those current conditions, and the credibility and usefulness of the outputted information is maximized. 
     A further objective of the present invention is to provide an automated system that monitors the current traffic conditions such that the data provided by the system to drivers on the road is pertinent to those current conditions and that provides up-to-the-minute information on the current traffic conditions around a work zone or roadway incident to drivers, wherein the system is capable of operating automatically without operator intervention after deployment and system initialization through the use of a computer or other equivalent data processing device. 
     An even further objective of the present invention is to provide a system that monitors the current traffic conditions such that the data provided by the system to drivers on the road is pertinent to those current conditions and that provides up-to-the-minute information on the current traffic conditions around a work zone or roadway incident to drivers, wherein components of the system are designed to be moved and re-deployed to different operating sites with minimum time and effort. 
     In a first aspect of the system, the present invention is directed to a system for monitoring and processing traffic information at or near work zones or roadway incidents so as to provide real-time traffic advisory information to passing motorists. The system incorporates a plurality of sensor means for detecting current traffic conditions at least one of upstream of a work zone or roadway incident, at least one display means positioned upstream of the work, zone or roadway incident for displaying traffic information to passing motorists, a plurality of first control means each operatively positioned and connected with each of the plurality of sensor means and the display means for receiving sensor data and processing real-time traffic information to be displayed, respectively, and second control means communicatively connected to the plurality of first control means for controlling operation of the plurality of first control means. The second control means includes means for receiving the sensor data from the plurality of sensor means via corresponding ones of the plurality of first control means connected to the plurality of sensor means, means for generating the real-time traffic information to be displayed based on the sensor data, and means for transmitting the traffic information to be displayed to a corresponding one of the plurality of first control means connected to the display means. 
     In a second aspect, the present invention is directed to a portable system for automatic data acquisition and processing of traffic information in real-time. The system incorporates a plurality of sensors operatively positioned upstream of a work zone or roadway incident, each of the sensors being adapted to detect current traffic conditions, at least one variable message device operatively positioned upstream of the work zone or roadway incident; a plurality of remote station controllers, each operatively connected to a corresponding one of the plurality of sensors and at least one variable message device; and a central system controller operatively located within remote communication range of the plurality of remote station controllers, the central system controller and the plurality of remote station controllers, each having means for remotely communicating with one another. Each of the plurality of sensors is adapted to output traffic condition data to a corresponding one of the plurality of remote station controllers. The corresponding ones of the remote station controllers are adapted to transmit the traffic condition data to the central system controller. The central system controller further includes means for generating traffic advisory data based on the traffic condition data, the central system controller being adapted to transmit the traffic advisory data to at least a selected one of the plurality of remote station controllers operatively connected to at least one variable message and/or radio device, whereby traffic advisory messages are displayed based on the traffic advisory data. 
     In a third aspect, the present invention is directed to a method for monitoring and processing traffic information at or near work zones or roadway incidents so as to provide real-time traffic advisory information to passing motorists. The method comprises the steps of continuously detecting current traffic conditions upstream of a work zone or roadway incident, automatically generating traffic advisory data based on the detected traffic conditions, and displaying traffic advisory messages to passing motorists upstream of the work zone or roadway incident based on the traffic advisory data. The step of detecting the current traffic conditions includes providing a plurality of sensors upstream of the work zone or roadway incident to quantify conditions indicative of current traffic operations. 
     In a further aspect, the present invention is directed to a method for controlling operation of an automated traffic information monitoring and processing system that includes at least a plurality of sensors for detecting current traffic conditions; at least one variable message device; a plurality of remote station controllers, each operatively connected to corresponding ones of the plurality of sensors and at least one variable message device; and a central system controller operatively located within remote communication range of the plurality of remote station controllers. The method incorporates the steps of receiving traffic condition data from remote station controllers connected to the plurality of sensors, which continuously detect traffic conditions upstream of a work zone or roadway incident; generating traffic advisory data via the central system controller based on the received traffic condition data; then transmitting the traffic advisory data to the plurality of remote station controllers processing the traffic advisory data in each of the plurality of remote station controllers, and displaying traffic advisory messages on at least one variable message device. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The invention will now be described in conjunction with the attached drawings, wherein: 
     FIG. 1 is a general system diagram of the system according to a preferred embodiment of the present invention; 
     FIG. 2 is a system diagram illustrating the communication between the components of the system according to the present invention; and 
     FIG. 3 is a system block diagram of the Roadside Remote Station (RRS) according to the preferred embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     With reference to the figures, like reference characters will be used to indicate like elements throughout the several embodiments and views thereof. In particular, with reference to FIGS. 1 and 2, the system 10 is generally composed of six basic elements. One or more portable variable message signs (VMS) 12 are deployed upstream of a work zone (WZ) or incident site (IS) to convey real-time traffic information to passing motorists. 
     At least one highway advisory radio (HAR) 14 may be used to provide more detailed traffic information than can be accommodated by the VMSs 12. If there is an alternate route available, the HAR 14 can provide supplemental route navigation instructions in the event the system determines that the diversion of traffic is recommended or necessary. 
     An on-site central system controller (CSC) 16 is connected via a conventional communications system to control the various elements of the system 10. To enable the system 10 to respond to traffic conditions in real-time, traffic sensors 18 continuously acquire traffic data at multiple locations within and upstream of the work zone or incident site WZ. Portable ramp metering signals 20 are used to limit access to the roadway during conditions of heavy congestion. Roadside remote stations (RRS) 22 are used to receive traffic data from the sensors 18 and, under control from the CSC 16, to program the VMSs 12 to display and the HAR 14 to broadcast messages appropriate to current traffic conditions. RRSs 22 also control the signal timing of the portable ramp metering signals 20. 
     In the physical implementation of the system 10, the VMSs 12, the HARs 14, the sensors 18 and the portable ramp metering signals 20 may all be implemented using conventional devices used to perform their functions, such as an ADDCO Model No. DH 1000 which may be used as a VMS 12. An Information Station Specialists Model No. Alert AM may be used as the HAR 14. Whelen Engineering Model TDW-10 sensors may be used for the traffic sensors 18, and the ramp metering signals 20 may be implemented using conventional traffic signals portably mounted with a RRS 22 and a power supply 242. The central system controller (CSC) 16 may be implemented using an IBM-compatible PC or equivalent programmable data processing device with the necessary software designed to control the components of the system 10, as will be explained in more detail hereinbelow. The components that are physically located near one another may be connected to one another via conventional communication networking, such as RS-232 serial type. Those that are remotely located from one another may be communicatively connected via conventional RF transmitters and receivers in the UHF spectrum. In addition, by using an IBM-compatible PC or equivalent programmable data processing device as the basis for the CSC 16 and RRSs 22 in each of the components of the system networked to the CSC 16, the system 10 is intended to operate in a completely automated fashion after its deployment and system initialization. 
     In a preferred embodiment, the above-described elements may be implemented as separate components that are operatively and communicatively connected to one another or combined into several functional groups as depicted in FIGS. 1 and 2. As shown, an enhanced embodiment of the VMSs 12&#39; may integrate an RRS 22 and a traffic sensor 18 with a portable VMS 12. The RRS 22 and traffic sensor 18 may be physically mounted on the portable VMS&#39;s trailer 121 and supplied with electrical power by the portable VMS&#39;s own power source 122. The portable VMS 12 may also serve as a mount for the RRS&#39;s communications antenna 221. 
     An enhanced version of the HARs 14&#39; may be composed of a portable HAR 14 and an RRS 22. As in the enhanced VMS grouping 12&#39;, the RRS 22 of an enhanced HAR 14&#39; is physically mounted on the portable HAR&#39;s trailer 141 and is supplied with electrical power by the portable HAR&#39;s power supply 142. 
     Portable ramp metering stations 20&#39; may be formed by combining portable ramp metering signals 20 with an RRS 22 and a trailer equipped with a solar- or diesel-generator-based power supply 201. 
     Supplemental speed station/repeater units (S 3  Rs) 24 for deploying additional traffic sensors 18 may comprise an RRS 22, a traffic sensor 18 and a trailer 241 equipped with a solar- or diesel-generator-based power supply 242. 
     Within the preferred embodiment of the present invention as described above, there are two configurations of the system 10 which differ in the deployment of the CSC 16; they are (1) a work zone configuration and (2) an incident management configuration. In the work zone configuration, the CSC 16 may be located in a construction trailer 26 at the work zone WZ. The construction trailer 26 is equipped to provide a long-term source of electrical power, security from theft and vandalism, and a benign operating environment. In addition, use of construction trailers typically allows the provision of a telephone connection enabling the system 10 to be monitored and controlled remotely. In the incident management configuration, the CSC 16 is located in an environmental and security enclosure 28 mounted on a trailer 281 equipped with a solar- or diesel-generator-based power supply 282. This configuration for locating and enclosing the CSC 16 minimizes the time necessary for deploying the CSC 16 and the system 10 as a whole. As a whole, the selection of the components in the system 10, examples of which are described above, is intended to make every element in the system 10 portable, thereby allowing the system to be moved and re-deployed to different operating sites with minimum time and effort. 
     The RRS 22 is a key component of the present invention designed specifically for the implementation and operation of the system 10. A block diagram of the RRS is shown in FIG. 3. The RRS 22 is supplied with nominal 12 volt DC power through the power input connection PI. A power filter 223 removes electrical noise and protects the RRS hardware from electrical transients. The power filter 223 supplies conditioned 12 VDC power to the radio modem 224, the power supply 225, and the traffic sensor 18 via a filtered power bus 227. An analog-to-digital converter (A/D) 228 measures the voltage of the filtered power bus 227. The power supply 225 converts the filtered nominal 12 VDC supplied by the filtered power bus 225 into 5 VDC to supply the single board computer circuit 229, the A/D converter 228 and a second modem 222. The radio modem 224 is equipped with an antenna 221. 
     In the preferred embodiment, the power supply 225 is an Octagon Systems Model 7112. The power filter 223 is implemented using conventional components known in the art. The radio modem 224 is formed using a Motorola Model K44GNM1001A RNet 9600 baud telemetry modem. The A/D converter 228 uses an Octagon 5720 8-bit analog input circuit. The single board computer circuit 229 is implemented using an Octagon Systems Model 4020 circuit or equivalent. The antenna 221 is implemented with an antenna known in the art applicable for use with the above-mentioned radio modem 224 or its equivalents, and the modem 222 is implemented using a ZOOM 2400 baud DTMF fax modem or equivalents. 
     In the operation of the system 10, the traffic sensor 18 periodically transmits traffic speeds to the single board computer 229 via an RS-232 compatible serial interface 226. Software running on the single board computer 229 receives speed data from the traffic sensor 18 and stores it. 
     The antenna 221 connected to the radio modem 224 can receive radio frequency (RF) communication signals from either another RRS 22 or the central system controller 16, and conveys the RF signal to the radio modem 224, such as via an antenna cable 221a. The radio modem 224 converts the RF signal into a serial data stream. The serial data from the radio modem 224 is then conveyed to the single board computer 229 via the RS-232 compatible serial interface 226. The single board computer 229 interprets the serial data stream from the radio modem 224 based on the communications protocol and the data packet format all to be explained hereinbelow. 
     In the general operation of the RRSs 22, the serial data streams they receive are analyzed by their single board computers 229 in order to extract the information therein, including data packet addresses. If analysis of the data packet addresses indicates that the receiving RRS is to respond, the single board computer 229 evaluates the packet&#39;s command field and performs the designated action. Valid commands and their associated actions will also be described hereinbelow. 
     If the data packet directs a RRS 22 to measure and return the voltage present on its filtered power bus 227, the single board computer 229 uses an ISA bus interface 229a to program the A/D Converter 228 to select the appropriate input and return a digital value corresponding to the voltage present on the filtered power bus 227. 
     If the data packet directs the RRS 22 to transfer a sequence of data bytes to a VMS 12, the RRS 22 does so using an RS-232 compatible serial interface 22a connecting it to the VMS 12. 
     If the data packet directs the RRS 22 to program a HAR 14, the RRS 22 uses an ISA bus interface 22b connecting it to a modem 222 to program the modem into generating Dual-Tone-Multiple-Frequency (DTMF) tones corresponding to the characters in the data packet. The modem 222 then transmits the DTMF tones to the HAR 14 via its telephone interface 222a. 
     Data Acquisition and Communications 
     In the general operation of the entire system 10 as illustrated in FIG. 2, the network of RRSs 22 are continuously receiving speed data from their corresponding sensors 18. At regular intervals such as every minute or as required by the specific application, the CSC 16 acquires the traffic data from the RRSs 22 using a radio modem identical to the radio modem 224 in each RRS 22. Like any other wireless communications system, the performance of the system 10 is highly dependent on local topographic factors. However, the system&#39;s communications sub-system has demonstrated a range in excess of three miles based on the above-described implementation of the system 10. To insure the system can be deployed at any incident or work zone site, each of the RRSs 22 is also designed to serve as a communications repeater, relaying commands to and data from RRSs 22 beyond the direct communications range of the CSC 16. When operating as communications repeaters, RRSs still receive data from their corresponding sensors 18 and can control a VMS 12, HAR 14 or ramp metering signal 20 as required. The CSC 16 configures the communications mode of each RRS 22 during system initialization. By using RRSs 22 as repeaters to relay commands and data, the system 10 can support incident sites or work zones of essentially unlimited length and of any topography. 
     Since any wireless communications system is subject to noise and other forms of interference, the system&#39;s communications protocol, which is explained in further detail hereinbelow, is designed with a mechanism for detecting when communications have been corrupted. When either the CSC 16 or an RRS 22 detects a garbled communications packet, the invalid packet is re-transmitted until it is received properly. This process insures the integrity of the system&#39;s critical data and command communications exchanges. 
     Traffic Data Processing and Advisory Message Selection 
     When traffic data from the RRSs 22 is acquired by the CSC 16, the CSC analyzes the data to predict delay and to detect hazardously low speeds (e.g., speeds of less than the posted speed limit) upstream of the incident site or work area. In the event of a deterioration in traffic conditions, the CSC 22 warns drivers using the VMSs 12 and optionally one HAR 14, and if necessary regulates access to the freeway using the ramp metering signals 20. The CSC 16 selects from several different classes of messages in memory and can combine messages as needed to describe multiple scenarios, such as simultaneous delay and hazardous speed conditions. The following message types may be stored in memory: lane closure messages; speed advisory messages; delay messages; diversion messages; and time-stamp messages. In addition to its automated VMS message selection mode, as controlled by the CSC 16, the system 10 allows manual entry of messages for special circumstances. 
     Since the system 10 has access to real-time, quantitative traffic data as a result of the plurality of traffic sensors 18 connected to its network of RRSs 22, the speed advisory and delay messages can be very specific, enhancing credibility. The CSC 16 is programmed with templates for each speed advisory and delay message and &#34;fills-in&#34; the message with the appropriate speed or delay information based on the current traffic data that it receives and processes. For example, when the system 10 detects modest levels of congestion (e.g., 5 minutes ), the CSC 16 will output the necessary data to selected RRSs 22 in order to program the appropriate VMSs 12 to display the delay and speed advisory messages as shown below: 
     
         ______________________________________Delay Message     Speed Advisory Message______________________________________5 MIN             SLOW TODELAY             40 MPHAHEAD             **NOW**______________________________________ 
    
     In all cases, the actual level of delay and advisory speed presented by the system is derived from the current traffic conditions data. If, to continue from the previous example, traffic conditions were detected as deteriorating further, the CSC 16 will process the traffic data describing the deteriorating conditions and then transmit the necessary data to adjust the messages as shown below: 
     
         ______________________________________Delay Message     Speed Advisory Message______________________________________15 MIN            SLOW TODELAY             25 MPHAHEAD             **NOW**______________________________________ 
    
     If the system 10 were to detect severe congestion and delay, the CSC 16 may then output the necessary data to the appropriate RRSs 22 for programming a HAR 14 to transmit the appropriate messages recommending that drivers divert to an alternate route and even supplying route navigation instructions. An example VMS diversion message is shown below: 
     
         ______________________________________  Phase 1       Phase 2______________________________________  ALT           TUNE  ROUTE         RADIO  EXIT 19       530 AM______________________________________ 
    
     Each VMS 12 may be programmed to display one or more of the message types, and different VMSs within the same network may display different message types. The CSC 16 selects messages for each VMS 12 independently, based on the current traffic speed downstream of the selected VMS, the predicted delay for the work zone or incident site as a whole, and the message types currently enabled on the selected VMS. Having determined the appropriate messages for the system&#39;s VMSs 12 and HAR 14, the CSC 16 will command the RRSs 22 controlling the corresponding equipment to update their messages if required. 
     As an enhancement to message credibility, the system&#39;s VMS and HAR messages are time-stamped; that is, they contain elements that specify when the message was last updated. The system automatically updates these messages. An example VMS speed advisory message and it&#39;s associated time-stamp message is shown below: 
     
         ______________________________________Phase 1              Phase 2______________________________________ROADWORK             SLOW TOADVISORY             25 MPH2:24 PM              **NOW**______________________________________ 
    
     As another feature of the present invention, the RRSs 22 are designed to operate with solar-powered VMSs and HARs, thereby minimizing the level of maintenance required by the system in terms of having to replenish the power supplies of the individual components in the system 10. The supplemental speed station/repeater units 24 and portable ramp metering stations 20 also utilize solar energy power supplies. Since the availability of power produced by solar panels is affected by both the level and duration of sunlight, systems that rely on solar power are vulnerable to service interruptions due to cloudy weather or the reduction in the number of daylight hours during winter. To insure continuous operation of the system during times of low solar power output (e.g., dark or overcast days), the CSC 16 periodically commands each RRS 22 to measure its battery voltage. RRSs whose battery voltage is low are flagged by the CSC 16, whereby the necessary warnings are relayed to operators monitoring the system. Maintenance crews can then be dispatched to the flagged RRSs to either replace or recharge their batteries before the equipment shuts down. 
     System Communications Protocol 
     The central system controller (CSC) 16 communicates with the remote roadside stations (RRSs) 22 through the exchange of data packets via wireless modems. The format of these data packets is shown in detail hereinbelow. In at least this first embodiment, communication between the CSC 16 and the RRSs 22 is half duplex. In order to communicate with each other, the CSC 16 and each of the RRSs 22 has a unique network address. In at least this first embodiment, the address of the CSC is always 0, while the address of the deployed RRSs may range from 1 to 127. Each RRS is assigned an address during an initial system setup conducted by the CSC, and stores that address in non-volatile memory. 
     When, in the operation of its program, the CSC 16 is directed to retrieve traffic sensor data from an RRS 22 or change the output of a device (i.e., a VMS or HAR) connected to an RRS, the CSC 16 will build a command packet, address the data packet to the target RRS 22, and then transmit the data packet. In general, all of the RRSs 22 will receive the transmitted command packet(s) through their wireless radio modems 224 and process those data packets accordingly. As will be explained further hereinbelow, those RRSs 22 to which a particular data packet is not addressed will discard the packet without further processing. The RRS 22, to which a data packet is addressed, will transmit a response signal back to the CSC 16 to indicate either that the data packet has been properly received or that the data packet should be re-transmitted. 
     Correspondingly, after transmitting a RRS command packet intended for a particular RRS 22, the CSC 16 will not transmit a second command packet for that unit until it receives a response to the first command packet or until after an no-response time period activated by the CSC 16 expires. 
     In this preferred embodiment, during the specific operation of processing a data packet initially received from the CSC 16, a RRS 22 will evaluate the addresses in the FDEST and IDEST fields of the data packet to determine what processing, if any, it should perform. In general, there are three kinds of packet processing an RRS 22 may perform. If the addresses in both the FDEST and IDEST fields match the address of the RRS, the data packet is thereby determined as being intended specifically for that RRS. The RRS will then execute the command specified in the packet&#39;s CMD field and transmit a reply packet with the results of the operation. 
     If the neither the FDEST field nor the IDEST field matches the RRS&#39;s address, the RRS will discard the packet without implementing the command or replying. 
     If the IDEST field matches the RRS&#39;s address but the FDEST field does not, the RRS must re-transmit the packet without processing it, if it is configured to do so. This is referred to as repeater operation and is discussed in the following section. 
     Lastly, if the FDEST field matches the RRS&#39;s address but the IDEST field does not, this is the case of an RRS unexpectedly detecting a data packet ultimately intended for it but intended to be relayed through a repeater RRS first. In this case, the packet will be discarded without processing. 
     After receiving a data packet, the RRS 22 to which the packet is addressed will validate it. This validation takes the form of a CRC calculation on the packet, packet parameter consistency checks and verification of the RRS&#39;s internal state or configuration (i.e., repeater status, attached device type, etc.). If the packet passes the CRC check and other tests, the RRS 16 will process and perform the command specified in the CMD field of the data packet, and then transmit a reply packet with its CMDSTAT field set appropriately. 
     Repeater Operation 
     In the deployment of the system 10, one or several RRSs 22 may be beyond the range of direct communication with the CSC 16 or beyond within line-of-sight of the CSC 16 (See FIG. 2). In these circumstances, an intermediate RRS 22 is configured for repeater operation; that is, for re-transmitting command and data packets. By using one or more intermediate repeater RRSs 22 to relay command and reply packets, the CSC 16 can communicate with RRSs 16 beyond the maximum line-of-sight range. As noted above, operation as a repeater does not limit the operation of a RRS in any way; it still responds to command packets directed to it as would RRSs not configured as repeaters. 
     Referring to the system data packet definition explained hereinbelow, a data packet&#39;s IDEST field indicates the address of the next unit that should handle the packet. In order to act as an intermediary in the communication between the CSC 16 and another RRS 22, a repeater RRS 22 must receive a data packet whose IDEST field matches its own address, and then transmit the packet to the next RRS 22 in the &#34;chain&#34; connecting the CSC 16 to the final destination RRS 22 designated by the FDEST field. In this preferred embodiment, RRSs 22 acting as repeaters use a structure called a remap table, internal to its software, to re-address data packets prior to re-transmission. The remap table is the key to repeater operation since, taken as a whole, the remap tables of the repeater RRSs 22 describe the IDEST address path to those RRSs 22 not in direct communication with the CSC 16. 
     Once an RRS 22 is commanded into repeater mode and its remap table is loaded from the CSC 16, it will relay command and reply packets by replacing the address in the IDEST field of the data packet (which initially will be its own address) with the value extracted from its remap table using the FDEST address as an index. This address may be that of the final destination RRS or another repeater RRS, depending on the geometry of the RRSs deployed in the system 10. So that a data packet&#39;s next intended recipient knows to whom to send a reply signal, the repeater RRS also replaces the address in the SENDER field of the data packet with its own. The ORG field of the data packet, which indicates the address of the originator of the packet, remains unchanged. The repeater RRS 22 will then transmit the modified packet. 
     To demonstrate this process, the following example as illustrated in FIG. 2 shows communication between the CSC 16 and a RRS 22 having an address #6 using the RRSs 22 at addresses #3 and #5 as repeaters. Before it can transmit an otherwise complete command packet, the CSC 16 determine the proper value of the IDEST field in its own remap table stored in its software, so that the data packet will be transmitted to a repeater RRS if required. In this example, the CSC&#39;s remap table looks like the following: 
     
         ______________________________________RemapTable    Explanation______________________________________0        Not used, we won&#39;t be talking to ourselves.1        We&#39;re in direct communication with RRS #1.2        We&#39;re in direct communication with RRS #2.3        We&#39;re in direct communication with RRS #3.4        We&#39;re NOT in direct communication with RRS #4.    Send its packets to RRS #3 first. (RRS #3 is a    repeater)5        We&#39;re NOT in direct communication with RRS #5.    Send its packets to RRS #3 first. (RRS #3 is a    repeater)6        We&#39;re NOT in direct communication with RRS #6.    Send its packets to RRS #3 first. (RRS #3 is a    repeater)--       (We&#39;re not in direct communication with any RRS    past #3. Packets for an RRS past #3 must be sent to    RRS #3 first, so the remaining 121 entries are also #    3.)______________________________________ 
    
     Since the first element in the remap table is the element for address #0, the CSC 16 extracts element 6 (for the corresponding RRS address) from the table and inserts that address into the IDEST field of the data packet. In this example, the CSC 16 inserts the address of RRS #3. This insures that the packet will be routed to repeater RRS #3 first. The packet transmitted by the CSC 16 will then be configured as follows: 
     
         ______________________________________Command Packet Sent by CSC               Description______________________________________SOM             0 × A5                   always 0 × A5FDEST           6       final destination is RRS #6IDEST           3       but packet goes to RRS #3                   firstSENDER          0       transmitted by the CSCORG             0       originated by the CSC(remaining fields omitted forclarity)______________________________________ 
    
     During system initialization, RRS #3 was configured as a repeater; its remap table will appear as follows, as an example: 
     
         ______________________________________IDESTAddress  Explanation______________________________________0        We&#39;re in direct communication with the CSC. Any    inbound replies get transmitted to it directly.1        We&#39;re in direct communication with RRS #1.2        We&#39;re in direct communication with RRS #2.3        We&#39;re in direct communication with RRS #3.4        We&#39;re in direct communication with RRS #4.5        We&#39;re in direct communication with RRS #5.6        We&#39;re NOT in direct communication with RRS #6.    Send its packets to RRS #5 first. (RRS #5 is a    repeater)--       (We&#39;re not in direct communication with any RRS    past #6. Packets for an RRS past #6 must be sent to    RRS #3 first, so the remaining 120 entries are also    #5.)______________________________________ 
    
     After receiving the data packet from the CSC 16, repeater RRS #3 modifies the packet and re-transmits it. So that the recipient knows to whom to reply, RRS #3 inserts its address into the SENDER field. Next, it extracts the new address for the IDEST field from entry 6 (the value of the FDEST field in the original) of its remap table. The modified packet will then appear as follows: 
     
         ______________________________________Command Packet Re-transmitted by RRS #3 Description______________________________________SOM           0 × A5                     always 0 × A5FDEST         6           final destination                     is RRS #6IDEST         5           but packet goes                     to RRS #5 nextSENDER        3           transmitted by                     RRS #3ORG           0           originated by                     CSC(remaining fieldsomitted for clarity)______________________________________ 
    
     During system initialization, RRS #5 was also configured as a repeater; its remap table will have been configured as follows, as an example: 
     
         ______________________________________IDESTAddress  Explanation______________________________________0        We&#39;re NOT in direct communication with the CSC.    Send its packets to RRS #3 first. (RRS #3 is a    repeater)1        We&#39;re NOT in direct communication with RRS #1.    Send its packets to RRS #3 first. (RRS #3 is a    repeater)2        We&#39;re NOT in direct communication with RRS #2.    Send its packets to RRS #3 first. (RRS #3 is a    repeater)3        We&#39;re in direct communication with RRS #3.4        We&#39;re in direct communication with RRS #4.5        We&#39;re in direct communication with RRS #5.6        We&#39;re in direct communication with RRS #6.--       (We&#39;re not in direct communication with any RRS    past #6. Packets for an RRS past #6 must be sent to    RRS #3 first, so the remaining 120 entries are also    #6.)______________________________________ 
    
     After receiving the data packet from RRS 3, repeater RRS #5 modifies it and re-transmits it. So that the recipient knows to whom to reply, RRS #5 inserts its address into the SENDER field. Next, it extracts the new address for the IDEST field from entry 6 (the FDEST field) of its remap table. The modified packet will therefore be configured as follows: 
     
         ______________________________________Command Packet Re-transmitted by RRS 5  Description______________________________________SOM           0 × A5                     always 0 × A5FDEST         6           final destination                     is RRS #6IDEST         6           packet goes to                     RRS #6 nextSENDER        5           transmitted by                     RRS #3ORG           0           originated by                     CSC(remaining fieldsomitted for clarity)______________________________________ 
    
     RRS #6 evaluates the data packet after receiving it from repeater RRS #5. Since both the FDEST and IDEST fields match its own address, RRS #6 validates the packet then executes the command within it. RRS #6 then transmits a reply data packet based on the results of executing the command from the CSC. That reply packet will appear as follows: 
     
         ______________________________________Reply Packet Sent byRRS 6                 Description______________________________________SOM           0 × A5                     always 0 × A5FDEST         0           final destination                     is CSC (ORG                     field in command                     packet)IDEST         5           but packet goes                     to RRS 5 first                     (SENDER field                     in command                     packet)SENDER        6           transmitted by                     RRS #6ORG           6           originated by                     RRS #6(remaining fieldsomitted for clarity)______________________________________ 
    
     After receiving the reply packet from the RRS #6, repeater RRS #5 modifies it and re-transmits it. So that the recipient knows where it came from, RRS #5 inserts its address into the SENDER field of the reply packet. Next, it extracts the new address for the IDEST field from entry 0 (the FDEST field) of its remap table. The modified packet will appear as follows: 
     
         ______________________________________Reply Packet Re-transmitted by RRS 5  Description______________________________________SOM           0 × A5                     always 0 × A5FDEST         0           final destination                     is CSCIDEST         3           but packet goes                     to RRS #3 nextSENDER        5           transmitted by                     RRS #5ORG           6           originated by                     RRS #6(remaining fieldsomitted for clarity)______________________________________ 
    
     Similarly, after receiving the reply packet from the RRS #5, repeater RRS #3 modifies it and re-transmits it. So that the recipient knows where it came from, RRS #3 inserts its address into the SENDER field of the reply packet. Next, it extracts the new address for the IDEST field from entry 0 (the FDEST field) of its remap table. This next modified packet will appear as follows: 
     
         ______________________________________Reply Packet Re-transmitted by RRS 3  Description______________________________________SOM           0 × A5                     always 0 × A5FDEST         0           final destination                     is CSCIDEST         0           and that&#39;s where                     it&#39;s going nextSENDER        3           transmitted by                     RRS #3ORG           6           originated by                     RRS #6(remaining fieldsomitted for clarity______________________________________ 
    
     As discussed above, communication between the CSC 16 and the network of RRSs 22 in the system 10 is accomplished using a specific data packet format, wherein the necessary address and command data are inserted in order to implement the necessary data transfers between the CSC 16 and designated RRSs and between RRSs. One example for the structure of the system data packet format and its component bytes for this preferred embodiment is illustrated and explained hereinbelow: 
     
         ______________________________________System Data Packet FormatByte # Msg Field Description______________________________________0     SOM       Start Of Message, always 0 × A51     FDEST     Address of CSC (reply packet) or RRS for           which this packet is ultimately intended           (command packet)2     IDEST     Address of next RRS to handle this packet3     SENDER    Address of RRS or CSC that transmitted           this packet4     ORG       Address of packet originator5     CMD       RRS command opcode6     CMDSTAT   Bit mapped status field, refers to processing of           last packet received.           Set to 0 by CSC, set appropriately by RRS           when replying.7     RRSSTAT   Bit mapped status field, refers to current           state of RRS. Set to 0 by CSC; set           appropriately by RRS when replying.8     MSGCNT    Set by CSC to reflect running total of           messages transmitted;           transmitted without modification by the RRS9     DATALEN   Total number of DATA bytes in this packet10    CRCMSB    Most significant byte of packet CRC11    CRCLSB    Least significant byte of packet CRC12-225 DATA      Optional variable length CMD-code-dependent           information______________________________________ 
    
     The fields of the System Data Packet are defined as follows: 
     SOM 
     The Start of Message Field is used to indicate the beginning of a packet. This byte will always have the value 0×A5. 
     FDEST 
     The final destination field indicates the address of the device which is to process the packet. Valid values are 0 (for an RRS replying to the CSC) and 1 through 127 (for an RRS command packet sent by the CSC). 
     IDEST 
     The intermediate destination field indicates the address of the next device to handle the packet, but not necessarily the device to process it. This field is used for communicating via repeater RRSs. This field is set equal to the FDEST field when the packet is transmitted to its final destination. Valid values are 0 (for an RRS replying to the CSC) and 1 through 127 (for an RRS command packet sent by the CSC). 
     SENDER 
     The SENDER field contains the address of the device that transmitted the packet. This may not be the same device that originated the packet if two devices are communicating via repeater RRSs. Valid values range are 0 (for an RRS command packet sent by the CSC) and 1 through 127 (for an RRS replying to the CSC). 
     ORG 
     This field contains the address of the first device to transmit the packet (the originator of the packet). This may not be the same device that most recently transmitted the packet if two devices are communicating via repeater RRSs. Valid values are 0 (for an RRS command packet sent by the CSC) and 1 through 127 (for an RRS replying to the CSC). 
     CMD 
     The command field contains a code corresponding to the operation the RRS is to perform. These command codes are defined in detail in Table 1 in the accompanying specification. 
     CMDSTAT 
     The CMDSTAT byte is returned by the RRS and represents the results of processing the last command packet intended for it. The byte is organized as a bit field; only one bit may be set at a time. Successful completion is indicated by returning a 0 in this field. 
     The CMDSTAT byte is defined as follows: 
     
         ______________________________________CMDSTAT ByteBit 7Bit 6  Bit 5  Bit 4  Bit 3 Bit 2  Bit l Bit 0______________________________________RRS  CRC    CMD    Configu-                     Invalid                           Device Health                                        Setbusy error  out of ration Para- Did Not                                  Test  Device       range  Error  meter Respond                                  Error Type                                        Error______________________________________ 
    
     The bit fields within the CMDSTAT byte are arranged in hierarchical order with bit 7 being the most severe error. For example, a 1 in bit 4 (Configuration Error) implies that the packet was received when the RRS was not busy, that the packet&#39;s CRC was correct, and that the value in the CMD field was legal. 
     In the implementation of the RRS 16, one example of the command opcodes for implementing the software of the RRS in this preferred embodiment is as follows: 
     
         ______________________________________RRS Command OpcodesCMD field     Description______________________________________0             NOP - no operation30            Clear RESET bit in RRSSTAT field40            Configure serial port50            Write data to serial port60            Become repeater, remap list attached61            Cancel repeater status91            Select active traffic data buffer105           Return radar sensor speed data180           Return input power voltage200           Return RRS version210           Retrieve extended statistics215           Reset extended statistics255           Reset RRS______________________________________ 
    
     CMD 0: NOP 
     The RRS will reply without performing any further operations. 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 30: Clear Reset Bit 
     The RRS will clear the RESET bit it reports in the RRSSTAT byte. 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 40: Configure Serial Port 
     The RRS will configure the serial port indicated by byte 12 as specified in byte 13 as follows, provided that byte 12 does not specify the port connected to the RRS&#39;s RF modem: 
     CMD Packet: 
     DATA field length: 2 
     DATA field: 
     byte 12: serial port to be reconfigured (1-4) 
     byte 13: 
     
         ______________________________________Bit 7 Bit 6   Bit 5   Bit 4 Bit 3                            Bit 2 Bit 1 Bit 0______________________________________Baud  Baud    Baud    Data  Data Parity                                  Parity                                        Stop2     1       0       Bits 1                       Bits 0                            1     0     Bits______________________________________ 
    
     Where: 
     
         ______________________________________Bit 4          Bit 3  Data Bits______________________________________0              0      80              1      71              0      undefined1              1      undefined______________________________________Bit 7   Bit 6         Bit 5  Baud Rate______________________________________0       0             0      3000       0             1      12000       1             0      24000       1             1      48001       0             0      96001       0             1      192001       1             0      Undefined1       1             1      Undefined______________________________________Bit 2          Bit 1  Parity______________________________________0              0      None0              1      Undefined1              0      Even1              1      Odd______________________________________   Bit 0        Stop Bits______________________________________   0    1   1    2______________________________________ 
    
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 50: Write Data to Serial Port 
     The RRS will copy the data string starting in byte 13 of the data section of the command packet to the serial port specified in byte 12 provided that byte 12 does not specify the port connected to the RRS&#39;s RF modem. The length of the data is equal to byte 9 of the packet (DATALEN) minus 1. The data must be no longer than 243 bytes. 
     Data fields: 
     CMD Packet: 
     DATA field length: 2-244 
     DATA field: 
     byte 12: serial port (1-4) 
     bytes 13-255: data to be transferred 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 60: Become Repeater 
     The RRS will use the remap table in the data bytes to act as a repeater, indicating this status through bit 7 of the RRSSTAT field. 
     Data fields: 
     CMD Packet: 
     DATA field length: 32 
     DATA field: Remap table: packet byte 12 corresponds to the IDEST field for the unit at address 0 (the CSC), packet byte 13 corresponds to the network address 1, etc. 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 61: Cancel Repeater Status 
     The RRS no longer acts as a repeater; it also clears bit 7 of its RRSSTAT field. 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 91: Select Active Traffic Data Buffer 
     This command controls the destination of incoming traffic data from the sensor connected to the RRS. When the RRS powers up, it will arbitrarily designate one of its two traffic data buffers as buffer 0 and the other as buffer 1. Buffer 0 will be the first active buffer and buffer 1 the initial inactive buffer. All incoming traffic data will be routed to the buffer currently designated as the active buffer. Reception of command 110 causes the RRS to return the contents of the inactive buffer. Upon reception of a valid Select Active Traffic Data Buffer command, the RRS shall re-initialize the traffic buffer designated in byte 13 and utilize it as the active buffer until otherwise directed. By definition, the other traffic data buffer becomes the inactive buffer 
     Data fields: 
     CMD Packet: 
     DATA field length: 1 
     DATA field: ID of active traffic data buffer (0 or 1) 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 105: Return Radar Sensor Speed Data 
     This command returns radar sensor speed data from the RRS&#39;s currently inactive traffic data buffer. 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: 4 
     DATA field: 
     Byte 12: 
     A hexadecimal value representing the average speed (in mph) measured since the last Select Active Traffic Data Buffer command was received. 
     Bytes 13-14: 
     A hexadecimal word (two bytes) representing the number of speed data points used in calculating the average speed reported in byte 12. Byte 13 is the MSB; byte 14 the LSB. 
     Byte 15: 
     The ID of the buffer from which the data was retrieved (0 or 1). 
     CMD 180: Return Input Power Voltage 
     This command causes the RRS to measure and return the DC voltage present at its 12 VDC power connector. 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: 1 
     DATA field One byte representing the input power voltage in units of 60 mV. 
     CMD 200: Return RRS Version 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: Variable, but less than 32 
     DATA field: A null-terminated ASCII string containing the version number and date 
     CMD 210: Return Extended Statistics 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: TBD 
     DATA field: Extended statistics, format TBD 
     CMD 215: Reset Extended Statistics 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     CMD 255: Reset 
     This command resets the RRS as if it had been powered-up. 
     Data fields: 
     CMD Packet: 
     DATA field length: 0 
     DATA field: N/A 
     REPLY Packet: 
     DATA field length: 0 
     DATA field: N/A 
     Although the present invention has been fully described in connection with the preferred embodiment thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications will be apparent to those skilled in the art. For example, other devices for implementing the VMSs 12, the HAR 14, the supplemental speed station/repeater units 24 and the ramp metering stations 20, as known in the art, may be substituted for the components specified above for this preferred embodiment. Other data packet formats, software opcodes or software may be substituted for those specified above, also as known in the art, so long as the basic structure and operation of the present invention and their equivalents as disclosed herein are maintained. Other renewable or self-sustaining power sources/supplies may be substituted for those described above, so long as the remote and/or longterm operational capability of the system&#39;s components is maintained. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims, unless they depart therefrom.