Statewide work zone information system

A computer system includes a memory and a processor. The processor executes instructions to perform steps that include receiving a message from an asset tracking device, the message comprising position information for the asset tracking device and a traffic control device type for a traffic control device that the asset tracking device is attached to. The processor uses the received message to determine a road that the traffic control device is positioned on and a location of the traffic control device along the road.

BACKGROUND

The deployment of construction equipment and work crews on a roadway is hazardous to drivers and the work crews. To reduce the hazard, work crews set out signs ahead of their work zones to warn drivers about the approaching work zone and to direct drivers to lower their speed and shift lanes if necessary. To maximize safety, layouts of signs and other traffic control devices are often set by government regulation and in some instances, government agencies are tasked with inspecting work zone layouts to ensure they comply with the regulations.

SUMMARY

A computer system includes a memory and a processor. The processor executes instructions to perform steps that include receiving a message from an asset tracking device, the message comprising position information for the asset tracking device and a traffic control device type for a traffic control device that the asset tracking device is attached to. The processor uses the received message to determine a road that the traffic control device is positioned on and a location of the traffic control device along the road.

In accordance with a further embodiment, a server includes a memory and a processor. The processor executes instructions to perform steps that include receiving location information for traffic control devices deployed across a region wherein the location information is transmitted by asset tracking devices connected to the traffic control devices. The server provides information for a map user interface showing where traffic control devices are deployed across the region based on the received location information.

In accordance with a still further embodiment, a method includes receiving location information for a plurality of traffic control devices from respective asset tracking devices mounted to the traffic control devices, receiving a request for the locations of traffic control devices along a route and providing the locations of each traffic control device that is positioned along the route.

DETAILED DESCRIPTION

Embodiments described below provide a real-time database of active work zones from the first Traffic Control Device (TCD) being placed to the crews packing up. This Statewide Work Zone Information System (SWIS) provides a database of past road projects, currently active road projects updated in real time, and future projects that are in the planning stage.

For currently-active road projects, SWIS is able to determine the actual layout of Traffic Control Devices (TCDs) on a roadway because each TCD is outfitted with a SWIS asset beacon that periodically transmits the TCD's location, TCD type, and battery status to a SWIS server. The SWIS server uses processing algorithms to determine where a work zone is located and update its information in real time. Additionally, SWIS uses a novel algorithm to determine if a work zone is set up fully, and flag it for inspection if it is ready. The inspection algorithm checks if the work zone is set up in compliance with government layout guidelines or with a pre-approved planned project layout. If the TCDs meet the layout requirements, no manual inspection is required. If not, the project is flagged for manual review.

Users, both those involved with the project and the general public, can access SWIS user interfaces through the Internet. The user interfaces provide interactive maps to search for and view past, current and future work zones. Users with more advanced permissions can create or update road projects through the SWIS web interface as well.

SWIS also provides accurate, up to date work zone traffic control conditions like new road alignments, lane closures, etc. to routing and navigation applications and to autonomous and semi-autonomous vehicles. For example, the position and types of Traffic Control Devices along a current route of a vehicle can be downloaded from the server to a routing Application on a mobile device. The routing Application can then use the Traffic Control Device information to augment a user interface generated by the routing Application to indicate approaching lane closures, flagging personnel, temporary stop signs and other Traffic Controls and to issue in-vehicle alerts.

Work Zones

FIG.1outlines standard components of a road work zone. Despite the wide variety of road work that might take place, these major components do not change. Every work zone has the four areas: the Advanced Warning Area, where drivers are notified of upcoming road work by a series of signs; the Transition Area, where traffic control gradually transitions from the original to the temporary traffic control in place for the work; the Activity Area, where the actual work takes place; and the Termination Area, where the original traffic control is restored.

In the Advance Warning Area, drivers will always first encounter a “Road Work Ahead” sign, followed by more specific signs that depend on the change in traffic control such as “Shoulder Closed” or “One Lane Road Ahead”, among many others. The specific signs that must be used are outlined in State or Federal traffic control rules based on the nature of the work. The spacing of these signs is dictated based on the posted speed limit prior to starting work in order to provide drivers sufficient time to prepare for the change.

In the Transition Area, channelizing devices such as cones, weighted channelizers, drums, or barricades, among others, are used to gradually force drivers out of the work area over a distance, called a taper, followed by a longitudinal buffer. The length of the taper and buffer also depends on the speed limit. The specific channelizing device depends primarily on the duration of the work.

In the Activity Area, where work takes place, a lateral clear zone is created between the channelizing devices that restrict movement of traffic, and the work area. Channelizing devices continue along the whole of the Activity Area. The size of the clear zone and spacing of channelizing devices varies depending on the road's posted speed limit prior to starting work.

In the Termination Area, a downstream taper which is typically much shorter than the upstream taper closes the activity area for the resumption of normal traffic control. An “End Road Work” sign is typically placed after the downstream taper to indicate that drivers have exited the work area.

In smaller work zones, these areas are often clear and well-defined. In larger work zones that span many miles, by contrast, vehicles may drive through an extended activity area with several transitions.

There can be different types of short term work zones based on the duration of the work such as: 15 minutes or less, 1 hour or less, 12 hours or less, and up to 3 days or less. For short term work, traffic control is generally established on the spot by the crew based on one of a set of authorized Temporary Traffic Control layouts. Work that can be completed in a short or intermediate time frame like this occurs quite frequently, and often fairly spontaneously when weather turns out to be favorable. Because of this, it is generally not economical to spend too much time planning traffic control. Instead, the effectiveness of the Temporary Traffic Control deployed relies on the experience of the work crew managers on site and their understanding of various guidelines set by the government. The personnel who decide on the traffic control used in these situations typically have an intimate understanding of the art of safe and effective Temporary Traffic Control gained from years of experience working in the field. Regular government inspections are also carried out to ensure that crews are adequately following the necessary guidelines.

While the experience of workers generally does a good job in ensuring that road work can be carried out safely and with minimal disruption of traffic, there are nonetheless numerous realities that limit the availability and accuracy of information describing this work for anyone who is not physically present at the site. Notice of short-term work is often not announced to the public with much or any advanced warning, and documentation of the work is often limited. This can lead to surprises for drivers who encounter unexpected road work, as well as potentially exacerbating poor traffic conditions during peak periods.

In addition to this, the demands of the work, particularly in the case of moving work spaces, can lead workers to make certain decisions for convenience that can potentially confuse drivers. A common practice, which is not allowed by regulations but is often effectively ignored, is the deployment of multiple sets of advanced warning signs over the course of a day as the work area moves down the road. For example, in the morning a crew might place the necessary advanced warning signs within the correct distance of the work area, but as the work moves down the road they might simply place a second set of signs 2 miles downstream without removing the upstream signs (as they are supposed to), subjecting drivers to two sets of advanced warnings. This repeated, unnecessary exposure may encourage them to frequently disregard these warnings.

Work lasting longer than 3 days generally involves additional planning to minimize the traffic impact. In these cases, the planning usually begins approximately 3 years in advance. In these cases, the road authority will usually develop the traffic control plan itself, based on their knowledge of the work that needs to take place, the common traffic conditions in the area, and other construction projects that may need to occur in the region. The traffic control plans in these situations are generally very detailed, as seen inFIG.2, outlining exactly which signs and barricades should be placed where. The plans are then included along with the work requirements so that a bidding process may take place to select one or more contractors to do the work and implement the traffic control plan. These projects generally also involve the assignment of a full-time project engineer located on-site in a temporary office, overseeing the work and responding to the inevitable issues and schedule changes that occur during the course of the project.

Despite this additional planning and oversight, however, there are still issues with the dissemination of information to the public during these projects. Though the road authority generally provides information about the project to the public well in advance of the start of work, it is almost always very limited in the level of detail provided both in when the project will actually begin, how it will progress, and when it will finally end. Major closures will usually be announced with at least a few days' notice, but this is not generally the case for the smaller disruptions that occur frequently during the project. The sequence of work may also change depending on many factors such as weather, the availability of materials, and complications encountered during work.

As stated previously, information about the actual current state of a work zone is usually hard to come by. The reasons for this are understandable, as the complexity of projects and variables such as weather conditions and contractor schedules make it hard to predict when work will take place. Despite these realities, there is a general need for this information. Disruptions to traffic from road constructions take a toll on the already heavily-loaded traffic network, often leading to severe congestion or crashes that cost society significant amounts in both money and lost productivity. The rapidly approaching future of Connected and Automated Vehicles (CAVs) also will necessitate an improved system for tracking the real-time state of work zones to allow their technology to function properly. Finally, the stress of ageing infrastructure means that road maintenance will occur more frequently as time goes on, placing an additional burden on inspectors who must ensure that the work being carried out is being done so safely and according to regulations.

Asset Tracking Devices

The first requirement of the SWIS is a mechanism for tracking the location and type of traffic control assets that make up the work zone. This is one of the fundamental information sources that SWIS uses to provide information to its users. In accordance with some embodiments, the traffic control assets have the following attributes:1. An adequate number of traffic control devices are equipped with asset tracking devices to provide the SWIS system with information about a work zone.2. The asset tracking devices are capable of generating real-time positioning information about themselves.3. The asset tracking devices are capable of communicating with the outside world wirelessly.a. The asset tracking devices are capable of using this communication to transmit their position to a centralized system.b. The asset tracking devices also transmit a regular “heartbeat” message to provide the central system with status information.c. The asset tracking devices are capable of transmitting maintenance information to the central system.d. The asset tracking devices are capable of being administered remotely to change operational parameters and install software upgrades.4. The asset tracking devices are removably attachable to the relevant traffic control devices that they are tracking with some asset tracking devices being capable of being attached to multiple different types of traffic control devices.5. The asset tracking device and the mechanism for attaching the asset tracking device to the traffic control device are capable of withstanding being struck by a vehicle at high speed without injuring the occupant.6. The asset tracking devices are self-sustaining, self-powered and require no interaction from work crews to be deployed.7. The asset tracking devices have an extended operational life that allows them to operate continuously for the life of a traffic control asset.8. The asset tracking devices are capable of operating in an outdoor environment in all weather conditions.9. The asset tracking devices are be capable of communicating with mobile devices in vehicles via local wireless communication to provide additional advanced warning when entering a work zone.

FIG.3provides a block diagram of an asset tracking device300in accordance with one embodiment. Asset tracking device300includes a microcontroller302that executes instructions stored in a memory304. A peripherals interface308connects microcontroller302to a Global Navigation Satellite System (GNSS)306, a cellular communication system310, a short-range communication system312and an accelerometer320. GNSS receives satellite signals and uses the received signals to determine a longitude and latitude of asset tracking device300. GNSS306provides the longitude and latitude to microcontroller302through peripherals interface308. Cellular communication system310allows microcontroller302to communicate with other devices through a cellular network. Short-range communication system312allows microcontroller302to communicate directly with other devices using a wireless signal modulated according to a protocol such as the Bluetooth protocol. Accelerometer320detects accelerations of asset tracking device and provides those acceleration measurements to microcontroller302. Microcontroller302uses the acceleration measurements to determine when asset tracking device300has been struck by a vehicle.

Microcontroller302, memory304, peripherals interface308, GNSS306, cellular communication system310and short-range communication system312are powered by a power controller314, which in one embodiment receives power from an internal battery318and a solar cell316. Power controller314uses electrical power from solar cell316to recharge battery318when excess power is available and uses a combination of electrical energy from solar cell316and battery318when the electrical energy from solar cell316is insufficient on its own to power asset tracking device300. In addition, power controller314periodically determines the state of charge of battery318and provides that state of charge to microcontroller302.

Cellular communication system310normally operates in a low-power mode where it monitors incoming signals for signals addressed to asset tracking device300. When a signal is detected that is addressed to asset tracking device300, cellular communication system310enters a higher-power mode to process the incoming packets and to provide response packets. Once the communication ends, cellular communication system310returns to the low-power mode.

Short-range communication system312and GNSS306are selectively powered on by microcontroller302and are usually not drawing any power. When powered on, short-range communication system312acts as a beacon and transmits a unique identifier for the asset tracking device300. Devices within range of asset tracking device300, such as smartphones and receivers in vehicles approaching a work zone, receive the unique identifier and submit the identifier in a request to a SWIS server for information associated with the identifier. For example, the associated information can indicate that the vehicle is approaching a work zone that workers are in the vicinity and/or the speed limit in the work zone.

Microcontroller302sends periodic messages to a SWIS server through cellular communication system310. In accordance with one embodiment, microcontroller302selects which message to send based on a change in status of the asset tracking device since the last message was sent. If microcontroller302determines that asset tracking device300has not changed significantly since the last message, microcontroller302sends a small message packet that only includes the unique identifier of the asset tracking device. These messages are designed to simply tell the server that the asset tracking device is still operational. When the status of the asset tracking device has changed, larger messages containing more information are sent by microcontroller302. For example, if the battery charge has dropped below a threshold level since the last message was sent, microcontroller302sends a message that contains the unique identifier for the asset tracking device, the current battery charge and optionally the traffic control device that the asset tracking device is attached to. If microcontroller302determines that the acceleration measurements from accelerometer320indicate that asset tracking device300was struck by a vehicle, microcontroller302sends a message to the SWIS server reporting the collision together with the unique identifier for the asset tracking device and optionally the type of traffic control device that the asset tracking device was attached to. When microcontroller302determines that the longitude and/or latitude of asset tracking device300has changed significantly, microcontroller302transmits a message to the SWIS server indicating the new longitude and latitude. In some embodiments, when sending the new longitude and latitude, microcontroller302also sends the current battery charge, the unique identifier of the asset tracking device, and the type of traffic control device that asset tracking device is attached to.

Asset tracking device300is capable of being remotely administered by a server through cellular communication system310. In particular, the server can instruct asset tracking device300to enter a low-power mode, can update operation instructions in memory304, and can alter the type of traffic control device that the asset tracking device is connected to, for example.

All of the functions discussed above are handled automatically by asset tracking device300without any interaction from workers on site.

Critically, the asset tracking devices are also designed to be crash-safe. This means that they will not cause injury to the occupants of a vehicle if they are struck, similar to the beacon lights that are frequently attached to traffic control devices in the field today. In one embodiment, the SWIS tracking devices are incorporated inside Flashing Barricade Lights that are Solar and Battery Powered, as seen inFIG.4.

SWIS System Architecture

FIG.5provides a block diagram of a SWIS system500in accordance with one embodiment. In SWIS system500, a plurality of asset tracking devices, such as asset tracking devices502,504and506, provide longitude/latitude information and other status information to a SWIS server508through a cellular network510and one or more additional networks512, such as the Internet. Although only three asset tracking devices are shown, any number of asset tracking devices may be present. In addition, the asset tracking devices can be spread across multiple different construction projects in a region, such as a state. Cellular network510includes a plurality of cellular antennae, often referred to as cell towers that are distributed across the region and one or more switches for conveying data packets between the cell towers and networks512.

As discussed further below, SWIS server508receives the messages from the asset tracking devices, uses the messages to determine the layout of traffic control devices at various work zones and identifies violations of layout regulations. To identify violations, SWIS server508uses information stored in a route server514that describes the location, shape and speed limits of different roadways in the region.

Aspects of the layout information stored in SWIS server508can be accessed using a variety of client applications such as SWIS project manager client516, SWIS navigation client518, SWIS viewing client520, and SWIS work crew client522. SWIS project manager client516allows a project manager to define a layout of traffic control devices for different work zones, to view the actual layouts provided by the work crews and to review layout violations detected by SWIS. SWIS navigation client518is an API that can be called by a navigation application to request the locations of traffic control devices along a route being driven or a route being considered. SWIS viewing client520allows users to view a map showing the locations of work zones in a region and within each work zone, the layout of traffic control devices. SWIS work crew client522provides alerts indicating layout violations to a work crew supervisor and allows the supervisor to instruct SWIS to ignore the violation or to mute the alert.

In addition, a SWIS admin client524is provided that allows for the administration of SWIS server508such as defining access rights for various functions, database maintenance, and code updates.

In accordance with one embodiment, SWIS server508has the following characteristics:1. Users spread throughout region are able to access SWIS server508regardless of where they are.2. SWIS server508has the capability to intelligently warehouse road construction project data.3. SWIS server508is able to autonomously monitor projects without an official Traffic Control Plan.a. SWIS server508supports manual input of an unofficial Traffic Control Plan.b. SWIS server508is able to generate an impromptu project if no corresponding road construction project record exists for a work zone being set up.c. SWIS server508supports the inspection of a work zone based on government rules4. SWIS server508autonomously monitors projects with a Traffic Control Plan.a. SWIS server508supports the automated ingestion of DGN files containing work zone Traffic Control Plans.b. SWIS server508supports the inspection of a work zone based on the layout described in the corresponding Traffic Control Plan.5. SWIS server508has the capability to interpret Asset tracking data as the live representation of a work zone.a. SWIS server508is able to determine what state a work zone is in so that it may prevent fallacious inspections from being performed.b. Asset tracking devices may send their location in areas other than a work zone. Therefore, SWIS server508is able to determine when an asset tracking device is in the bounds of a work zone and when it is not.6. SWIS server508is able to interpret Road Project meta-data.a. SWIS server508is able to reconcile a work zone in the process of being set up with its corresponding road construction project record, if the record exists.b. SWIS server508is able to autonomously detect and gracefully handle changes in the layout of a work zone. This includes the conclusion of a road construction project.7. SWIS server508is able to interpret and utilize road geometry information when monitoring projects.

FIG.6provides a block diagram of modules and other components implemented in SWIS server508. Within SWIS server508, a core database600contains information for future, current and past projects across a region, such as a state or country. In accordance with one embodiment, core database600is a SQL database, however other database structures may be used. Because core database600contains information for past projects, it contains a large amount of data. To accommodate this data, core database is typically stored in non-volatile storage devices. To improve system performance, some embodiments provide a Dynamic Memory Database (DMD)602that is held in volatile memory and typically only includes data for currently active projects and projects that are about to become active. A DMD manager604periodically loads DMD602with new project data for projects that are about to become active, periodically copies data from DMD602to core database600, and removes project data from DMD602when the project is no longer active. The use of DMD602allows for components to access project information faster than querying the entire core database600.

In accordance with one embodiment, data is stored in core database600and DMD602using a hierarchical structure of “Project”, “Traffic Control Plans” (TCPs) and “Work Zones” (WZs). A generalized layout of the structure is provided inFIG.7, with N representing any number of TCPs, WZs, or TCDs.

Projects are assigned to a “route”, or roadway, and have a general start date and end date assigned to them either based on when messages are received by SWIS or based on information provided in advance for a planned project. Every Project has at least one, but possibly several, Traffic Control Plans (TCPs). These TCPs are active within the project based on the time of day. For example, a small Project that doesn't affect traffic flow much may have only one TCP for the project duration. InFIG.7, the Project would only have TCP1active. A larger Project, such as on an interstate entering and leaving a downtown area, may have AM peak, PM peak, and Off-Peak TCPs. An AM Peak TCP might be two lanes entering downtown and one leaving. A PM Peak TCP may shift those lanes to two leaving downtown and one entering. Off Peak TCP may have two lanes in either direction. InFIG.7, the Project would use three TCPs for AM, PM and Off Peak. Each TCP dictates where barriers and signage are placed and may either be based on government set layouts or programmed in advance into SWIS by a construction supervisor.

Within TCPs, there are Work Zones (WZs). Each TCP may have one or many WZs at different points along the physical length of the Project. For example, the morning of a Project, one crew could have a WZ repairing potholes along an interstate while a different crew several miles down the road has a WZ reconstructing an off ramp. Because these WZs are along the same route, they fall under the same Project; because they are active at the same time of day, they fall under the same TCP. InFIG.7, this would be represented as Project->AM TCP->the two active WZs.

TCDs are categorized under WZs as their asset tracking devices send messages to SWIS server508with their location. InFIG.7, each WZ has at least one active TCD. More will become active as the project continues to be set up, and TCDs may change between WZs or even Projects.

To maintain consistency, the following constraints are placed on the projects, traffic control plans and work zones:Projects do not overlap in space and time.With a Project, the Project's upstream boundary is at least 250 feet away from the first traffic control device.Although a Project can have many traffic control plans, only one Traffic Control Plan can be active at a time.The boundaries of each Traffic Control Plan are the boundaries of the Project.The boundaries of Work Zones do not overlap.Work Zones depend on when a Traffic Control Plan is active.Each Work Zone has a single temporary traffic control layout.The Work Zone's upstream boundary is at least 250 feet before the Work Zone's first traffic control device.The Work Zone's downstream boundary is at the work zone's termination traffic control device.The distance between Work Zones in a Project must be no less than what is specified by government regulation.

Messages from asset tracking devices are received by a message reception module606that is tied to a port of SWIS server508. Upon receiving a new message, message reception module606process the message by, for example, de-serializing the message into object attributes and then calling a pre-check module608to evaluate whether the message should be kept for deeper processing.FIG.8provides a flow diagram of a method performed by pre-check module608in accordance with one embodiment.

At step800, pre-check module608is called and receives the contents of the message. At step802, pre-check module608examines the contents of the message to determine if the message is valid. This validity check includes determining if the message contains a valid asset tracking device id. If the message does not contain a valid asset tracking device id, the message is discarded at step804. The validity check also determines if the message is one of a set of acceptable message types such as Alive, Change in Position, Crash, and Low Battery. If the message is not one of the acceptable message types, the message is discarded at step804. If the message is an Alive message, Alive processing module610is called at step806to update core database600with the current date as the last date the asset tracking device was heard from. If the message is a valid Low Battery message, Low Battery processing module612is called at step808to send a Low Battery alert to one or more of the SWIS Admin client524, the SWIS project manager client516or the SWIS work crew client522through a client API616. If the message is a valid Crash message, a crash processing module614is called at step810to send an alert to the SWIS work crew client522through client API616.

If the message is a valid Change of Position message, pre-check module608compares the longitude and latitude of the asset tracking device to the boundaries of one or more warehouses or other storage areas to determine if the traffic control device is currently positioned in storage at step812. If the traffic control device is within storage at step814, the message is discarded at step816. If the traffic control device is not within storage at step814, pre-check module608converts the longitude and latitude into a route and mile point at step818using route information provided by route server514. The route and mile point are then added as an attribute of the message.

At step820, pre-check module608determines if an unprocessed message for the current asset tracking device is currently in a position queue618. If there are no unprocessed messages for the asset tracking device in queue618, the current message is added to position queue618at step822. If there is an unprocessed message in queue618for the asset tracking device, the message in the queue is replaced with the current message for the asset tracking device at step824. Replacing such messages in the queue reduces the amount of processing that SWIS server508performs because the server does not have to process a message containing no-longer-accurate position information for the asset tracking device. After either step822or step824, the process executed by pre-check module608for the current message ends at step826.

A process traffic control device (process TCD) module620of SWIS server508performs deeper processing on incoming change-of-position messages through a method shown in the flow diagram ofFIG.9. At step900ofFIG.9, process TCD module620selects a message from position queue618. At step902, process TCD module620reads the asset tracking device id of the message and determines whether the traffic control device associated with the asset tracking device has already been assigned to a project-traffic control plan-work zone combination. If the traffic control device has already been assigned to a project-traffic control plan-work zone combination, the position of the asset tracking device is compared to its previous position within the project-traffic control plan-work zone at step904. If the asset tracking device is in substantially the same position, the message is discarded at step906.

If the traffic control device associated with the asset tracking device of the message has not be assigned to a project-traffic control plan-work zone combination at step902or if the position of the asset tracking device has changed at step904, process TCD module620compares the position of the asset tracking device to the boundaries of active projects at step908. When the asset tracking device is not within an active project boundary, process TCD module620creates an unplanned project-traffic control plan-work zone combination in DMD602with an initial boundary that includes the asset tracking device at step910.

At step912, process TCD module620searches for work crews that are near the unplanned project-traffic control plan-work zone based on information provided by one or more SWIS work crew clients522. At step914, process TCD module620assigns the closest work crew to the unplanned project-traffic control plan-work zone. This work crew will be alerted when the layout of traffic control devices in the unplanned project-traffic control plan-work zone do not meet regulations, when a traffic control device has a low battery and when a traffic control device is hit by a vehicle. At step916, process TCD module620adds the asset tracking device of the message and its associated traffic control device to the unplanned project-traffic control plan-work zone. At step918, process TCD module620flags the unplanned project for inspection as described further below.

When the asset tracking device of the current message is within an active project's boundary at step908, process TCD module620flags the active project for inspection at step920. Process TCD module620then determines if the asset tracking device is within an active traffic control plan at step922. If the asset tracking device is not within an active traffic control plan, a rogue work zone is created in DMD602at step924and the traffic control device associated with the asset tracking device is set as part of the rogue work zone.

When the asset tracking device is within an active traffic control plan at step922, process TCD module620determines if the asset tracking device is within an active work zone at step926. If the asset tracking device is not within an active work zone, an unauthorized work zone is created in DMD602at step928and the traffic control device associated with the asset tracking device is added to the unauthorized work zone. When the asset tracking device is within an active work zone at step926, the traffic control device associated with the asset tracking device is removed from its previous project-traffic control plan-work zone combination and is added to the active project-active traffic control plan-active work zone combination determined in steps908,922and926at step930. After steps930and928, process TCD module620returns to step900to select a new message from position queue618.

SWIS server508also includes a work zone inspection module622that inspects the layouts of traffic control devices in projects that have been flagged for inspection, rogue work zones and unauthorized work zones. By default, all projects are flagged for inspection when they first become active. Work zone inspection module622consists of a sanity check module624and a layout violations module626.

Sanity check624is a complex algorithm that determines if a project is ready for inspection, and if it is not, raises an alert for the crew to examine what is wrong with the project layout.FIG.10provides a flow diagram of a method performed by sanity check624in accordance with one embodiment.

In step1000, sanity check624selects one of the flagged projects. At step1002, sanity check624determines if the traffic control devices for any active work zone in the project are grouped together (i.e. still in the back of the crew's truck or waiting on the side of the road). If a grouping is found, the project's layouts are not ready for inspection since the traffic control devices are still being marshalled before being laid out. As a result, sanity check624keeps the project from being inspected at step1004but continues to flag the project for inspection such that the project remains in the set of flagged projects. This will cause the project to be selected again from the set of flagged projects for inspection. After step1004, the process determines if there are more flagged projects at step1006. If there are more flagged projects, sanity check624returns to step1000to select another flagged project.

If traffic control devices in a work zone of a flagged project are not grouped together at step1002, sanity check624compares the project's boundary to neighboring project boundaries at step1008. If a neighboring project boundary is sufficiently close to or overlapping the currently selected boundary at step1010, sanity check624combines the two projects into a single project at step1012. The two projects are combined by determining if either project is a planned project. If one of the projects is a planned project and the other is an unplanned project, the traffic control plans, work zones and traffic control devices of the unplanned project are shifted to the planned project in DMD602and the unplanned project is deleted from DMD602. The planned project then becomes the current project being examined by sanity check624. If both projects are unplanned, the traffic control plans, work zones and traffic control devices of the unplanned project with the smallest number of traffic control devices are shifted to the other unplanned project in DMD602and the smaller unplanned project is deleted from DMD602. The combined project then becomes the current project being examined by sanity check624. If both of the projects are planned, the projects are kept separate.

If the project is not close enough to another project to be merged with that other project at step1010or after the merger takes place at step1012, sanity check624selects a work zone in the current project at step1014. At step1016, sanity check624identifies work zones that neighbor the selected work zone and determines the distance between the boundaries of the selected work zone and the neighboring work zones. If any of the neighboring work zones are close enough to be combined with the selected work zone at step1018, the neighboring work zone and the selected work zone are merged into a single work zone in DMD602at step1020.

The selected work zone is then examined to determine if it has been designated as a rogue work zone at step1022. If the work zone is a rogue work zone, sanity check624determines at step1024whether alerts for the rogue status of the work zone have been muted by the work crew using SWIS work crew client522. If alerts have not been muted, the current project is prevented from being inspected and an alert about the rogue status of the work zone is sent to the work crew through SWIS work crew client522at step1026. The process then continues at step1006to determine if there are other flagged projects.

If the work zone is not a rogue work zone or if alerts have been muted at step1024, the selected work zone is examined by sanity check624to determine if it has been designated as an unauthorized work zone at step1028. If the work zone has been designated as unauthorized, sanity check624determines at step1030whether alerts for the unauthorized status of the work zone have been muted by the work crew using SWIS work crew client522. If alerts have not been muted, the current project is prevented from being inspected and an alert about the unauthorized status of the work zone is sent to the work crew through SWIS work crew client522at step1032. The process then continues at step1006to determine if there are other flagged projects.

If the work zone is not an unauthorized work zone or if alerts have been muted at step1030, sanity check624determines if there are more active work zones in the current project to process at step1034. If there are more work zones, another work zone is selected by returning to step1014and steps1016-1034are repeated for the newly selected work zone.

When all of the active work zones of the current project have been processed, sanity check624determines if there are more flagged projects to process at step1006. If there are more flagged projects, another flagged project is selected by returning to step1000and steps1002-1034are repeated for the newly selected project.

Projects that keep failing Sanity Check624must be addressed (by supervisors responding to alerts or violations raised by SWIS) or they will never be inspected.

All flagged projects that pass sanity check624are ready for layout inspection.FIG.11provides a flow diagram of a method of layout inspection used by layout violations module626to determine if the layout of the traffic control devices matches a plan for the layout or whether the layout meets government regulations.

In step1100, layout violations module626selects one of the flagged projects that passed sanity check624. At steps1102and1104, layout violations module626selects an active traffic control plan in the selected project and an active work zone within the selected active traffic control plan. At step1106, layout violations module626determines whether any of the traffic control devices in the selected work zone have changed positions and whether any traffic control devices have been added to or removed from the work zone since the last time the layout of traffic control devices in the work zone was evaluated. If there has been no change in the traffic control devices of the work zone at step1106, layout violations module626does not re-evaluate the layout and instead determines if there are more active work zones for the selected traffic control plan at step1114.

When there has been a change to the traffic control devices of a selected work zone at step1106, layout violations module626searches for a stored layout for the work zone in DMD602at step1108. Such a stored layout is part of the formal traffic control plan that the work zone is part of. If a stored layout is found, layout violations module626compares the positions of the traffic control devices in the work zone to the stored layout and flags all differences at step1110. An alert is then sent to the work crew through SWIS work crew client522noting the differences between the plan and the actual layout of the traffic control devices at step1111.

The stored layout can have one or more approved deviations from standard layouts set by regulations because of special conditions on the road. Because the process for planning a work zone requires many people to approve of the plans, however, it can be assumed that these deviations are safe. This assumption helps avoid additional difficulty in the layout selection process.

When there is no stored layout for the work zone at step1108, layout violations module626calls a layout identification module628to determine which of a set of standard layouts is most similar to the layout of traffic control devices and to evaluate the layout of the traffic control devices relative to that most-similar layout at step1112. In accordance with one embodiment, the set of standard layouts are defined by a government entity responsible for ensuring that work zone traffic control devices are laid out properly.FIG.12, discussed further below, provides a flow diagram of a method of identifying the most-similar standard layout and evaluating the positions of the traffic control devices relative to that standard layout.

After the positions of the traffic control devices have been compared to the planned layout or the most-similar standard layout, the process ofFIG.11determines if there are more active work zones to be processed. If there are more active work zones, another active work zone is selected at step1104and steps1106-1114are repeated. When all of the active work zones have been processed, the method determines if there are more active Traffic Control Plans to process for the selected project at step1116. When there are more Traffic Control Plans to process, the method ofFIG.11returns to step1102to select another active Traffic Control Plan for the current project and steps1104-1116are repeated. When all of the active Traffic Control Plans of the selected project have been inspected, the process ofFIG.11continues at step1118where work zone inspection622determines if there are more projects set for inspection. When there are more projects, the process returns to step1100and another project is selected. Steps1102-1118are then repeated. When all of the projects set for inspection have been inspected, the process ofFIG.11ends at step1120.

FIG.12provides a flow diagram of one method of step1112for identifying a standard layout that is most similar to the actual layout of traffic control devices in a work zone and evaluating the actual layout relative to the identified most-similar standard layout. The layout identification process is performed by layout identification module628and requires that a minimum set of tagged assets be present in the work zone to provide the system with sufficient information to guarantee identification of the correct standard layout. In accordance with one embodiment, these include all signs, the flagger's pole/stop sign (for flagger operations), the channelizing device at the center of the driving lane within the upstream taper (or at the beginning of a lane shift), and the last channelizing device of the downstream taper (or end of a lane shift). In instances when one or more of these assets is missing, layout identification module628may still be able to identify the correct layout but it is not guaranteed that it will identify the correct layout.

As noted above, asset tracking devices provide the type of traffic control device they are connected to when they provide their longitude and latitude. For channelizing devices (drums, cones, etc.), this involves simply identifying the type of channelizing device and not whether they are an upstream or downstream device. For signs, this means providing an identifier for the sign that indicates the information conveyed by the sign (e.g. W20-1 for a Road Work Ahead sign).

The process ofFIG.12begins in step1200where the attributes for the work zone's road are retrieved from route server514. In one embodiment, these attributes include the road type (number of lanes and whether it is divided or undivided), posted speed limit, and Average Annual Daily Traffic (AADT) of the road. Layout identification module628retrieves such information using the route and mile markers identified for the traffic control devices in the work zone by pre-check608.

In accordance with one embodiment, the attributes of the work zone's road are used to reduce the number of layouts that must be considered. First, at step1202, a set of layouts that are permitted for the road's type is selected thereby removing layouts that are not permitted for the road's type. At step1204, the selected layouts are augmented by adding layouts based on the Average Annual Daily Traffic of the road. Specifically, if the AADT of the road is below a threshold, low-AADT layouts are added to the set of selected layouts. At step1206, the set of layouts is augmented with additional layouts based on the speed limit of the road. In particular, if the speed limit is below a threshold, low-speed layouts are added to the set of possible layouts.

Once the set of possible layouts has been selected, a vector is created from the traffic control devices detected for the work zone at step1208. To construct this vector, layout identification module628first determines a direction of travel relative to the traffic control devices. In accordance with one embodiment, the direction of travel is determined based on the position of traffic control devices that are identified as signs relative to the position of traffic control devices that are identified as channelizing devices. In general, two or more signs will precede the channelizing devices in the work zone. Thus, the channelizing devices should be downstream from the signs along the direction of travel. Once the direction of travel is set, the traffic control devices are ordered in the vector based on their mile post along the road.

At step1210, the vector is applied to the layouts in the set of layouts to determine how many layouts match the vector by providing the same traffic control devices in the same order as the vector. In accordance with one embodiment, the layouts are stored as a tree structure that is traversed based on the traffic control devices in the vector. Thus, beginning with the first traffic control device in the vector, one branch in the tree is selected, thereby selecting a subset of the layouts. The next traffic control device in the vector is then used to select the next branch to follow in the tree. If there is no branch for the vector's current traffic control device, all of the branches from the current point in the tree are followed and the vector's current traffic control device remains unchanged. The vector's current traffic control device is then compared to the next lower branches in the tree. This allows for situations where a traffic control device is missing from the work zone. Note that this also creates multiple possible paths through the tree.

After the tree has been traversed, a count of the number of matching layouts is made. A matching layout for the vector is found when all of the traffic control devices of the vector have been processed.

FIG.13provides an example of traversing a tree structure1301of layouts for an input vector where a single matching layout is found. InFIG.13, the vector consists of traffic control devices C and P designated as vector [CP]. Tree structure1301includes a set of nodes, shown as dots, connected by branches, shown as lines. Each branch is associated with a traffic control device, represented by letters along the branches. The start of the tree structure is node1300. InFIG.13, the traffic control devices of the vector that are yet to be found in the layouts are listed in brackets by the nodes that are traversed. The first traffic control device listed in the brackets is the traffic control device that is used to select a branch from that node.

At node1300, traffic control device C of vector [CP] matches branch1302. As a result, branch1302is followed to node1304and layout identification module628advances to traffic control device P in the vector. At node1304, traffic control device P does not match either of branches1306and1308, which are for traffic control devices H and I, respectively. As a result, both branches are followed and traffic control device P continues to be the current traffic control device under consideration. Following branch1306leads to node1310where branch1312matches traffic control device P. As a result, branch1312is followed to an end1314of the tree and the end of the vector is also reached.

Following branch1308from node1304with P as the current traffic control device leads to node1316. At node1316, neither of branches1318and1320match traffic control device P and as a result both branches are followed to respective ends1322and1324while maintaining traffic control device P as the current traffic control device of the vector.

InFIG.13, three paths were followed to respective ends of the tree. However, only end1314was reached after processing all of the traffic control devices in the vector. Since traffic control device P had not been processed when ends1322and1324were reached, the layouts associated with those paths do not match the traffic control devices of the work zone. As a result, only the layout associated with the path that ended at node1314is a match for the traffic control devices ofFIG.13.

FIG.14provides an example where multiple layouts match a traffic control device vector.FIG.14is similar toFIG.13except that an additional level is present in the tree ofFIG.14at node1314. Because of this, there are two paths1402and1404from node1314that would both match the vector and reach the end of the tree at respective nodes1406and1408with all of the traffic control devices of the vector having been processed. Thus, the layouts associated with both of these paths match the traffic control device vector.

If none of the layouts match the traffic control device vector, none of the paths traversed through the tree will process all of the traffic control devices in the vector. When this occurs at step1210, layout identification module628searches for matching layouts without regard to the order of the traffic control devices in the work zone. In accordance with one embodiment, this is done by returning to the highest level node at which no match was found for the current traffic control device in the vector. At that node, instead of simply trying to match the current traffic control device, all of the remaining traffic control devices in the vector are considered and all branches that match at least one of the remaining traffic control devices are followed. The matching traffic control device is then removed from further consideration for that path and the next node along the branch is processed. A count of the number of matching layouts is then determined where a matching layout is one in which all of the traffic control devices for the vector have been processed by the time the end of the tree is reached.

When only one layout matches the vector's traffic control devices at steps1210or1216, the positions and ordering of the work zone's traffic control devices is evaluated relative to the matching layout at step1212. When multiple layouts match the vector's traffic control devices at steps1210or1216, the matching layout with the fewest extraneous traffic control devices is selected and the work zone's layout is evaluated relative to the selected layout at step1214. Thus, if the work zone is missing two traffic control devices listed in a first layout but is missing only one traffic control device of a second layout, the work zone will be evaluated relative to the second layout.

When none of the layouts match the work zone's traffic control devices, an alert is sent to the work crew at step1218through SWIS work crew client522.

FIG.15provides a method of evaluating the layout of traffic control devices relative to a matching layout in steps1212and1214. In step1500, traffic control devices that are in the matching layout but are missing from the work zone are identified. At step1502, one of the missing traffic control devices is selected and at step1504, layout violation module626determines if the inclusion of the traffic control device in the matching layout is speed based such that for some speed limits, the traffic control device must be present in the layout while for lower speed limits, the traffic control device is optional. If the missing traffic control device is speed based, the speed limit of the road is compared to the speed at which the traffic control device becomes mandatory at step1506. If the speed limit is above the speed at which the traffic control device becomes mandatory or if the traffic control device is not speed based, an alert is set for the missing traffic control device at step1508. If the road's speed limit is not above the speed at which the traffic control device becomes mandatory, no alert is set and the process continues at step1510.

In step1510, layout violation module626determines if there are more traffic control devices missing from the work zone. If there are more missing traffic control devices, the process returns to step1502and another missing traffic control device is selected and processed using steps1504-1508. When there are no more missing traffic control devices at step1510, layout violation module626determines the required spacing between traffic control devices based on the matching layout and the speed limit of the road at step1512. Specifically, the spacing between traffic control devices in a layout is designed to give drivers a certain amount of time between traffic control devices. As the speed limit increases, the distance between traffic control devices must be increased to maintain the amount of time between traffic control devices designated in the layout. In some embodiments, each layout designates multiple different spacing distances, one for each of a set of speed ranges, for each traffic control device.

At step1514, layout violations module626compares the spacing between traffic control devices determined for the layout to the spacing between traffic control devices in the work zone. An alert is then set for each traffic control device that is not spaced correctly from the upstream traffic control device. At step1516, the alerts set in steps1508and1514are reported to the work crew using SWIS work crew client522.

Client APIs616provide user interfaces to SWIS Admin client524, SWIS Project Manager client516, SWIS viewing client520and SWIS work crew client522. Although shown as separate clients, each of these clients can be realized in a single application by assigning different rights to different users of the application. Based on the rights assigned to the user, different user interfaces or different elements within a common user interface are made available to the user to thereby construct the various clients.

One common user interface provided in all of the clients is a mapping user interface that allows the user to view all currently active projects in a region, such as a state.FIG.16provides an example of such a user interface. InFIG.16, an interactive map1602is shown next to a list of projects1600. The scale of map1602is adjustable by the user so that the user can zoom in and out of different areas. When zoomed out, as shown inFIG.16, a number of different projects are shown, with each project represented by a circle around a number such as circles1604,1606,1608,1610and1612. The numbers in the circles are the number of traffic control devices deployed for the project. For each active project, a project entry is provided in list of projects1600such as project entries1614,1616,1618,1620, and1622. Each project entry is selectable and when selected causes a window to open below the entry that includes information about the project such as information window1624for the selection of entry1614. The information includes a traffic control plan listing control1626that provides a list of traffic control plan headers1628when selected. Each traffic control plan header is selectable and when selected provides information about the traffic control plan including controls to view the work zones of the traffic control plan and the traffic control devices deployed in each work zone.

FIG.17shows the user interface ofFIG.16zoomed in on the project represented by circle1604ofFIG.16. In the view of the project shown inFIG.17, the individual traffic control devices that have been deployed for the project are shown on map1602by icons1702,1704,1706and1708. These icons depict the traffic control devices they represent. For example, for signs, the icons depict what is shown on the signs. The icons for channelizers such as barrels and cones depict barrels and cones, respectively. Each traffic control device shown on map1602also has an entry, such as entries1710,1712,1714and1716in project information window1624. These entries are within a work zone description area1724for the project.

InFIG.17, the traffic control devices of the work zone are in the process of being deployed by a work crew. In addition, the project has not been pre-planned but instead has been created by SWIS server506as indicated by entry1700in information window1624.

FIG.18provides the same view asFIG.17but after more of the traffic control devices for the project have been deployed. As a result, additional icons1802,1804and1806are shown on map1602for additional deployed traffic control devices and additional entries1808, and1810are provided in information window1624. Note that other traffic control device entries are present in information window1624but are not visible in the view provided inFIG.18. The additional entries can be viewed by scrolling down the project list.

FIG.19shows the user interface ofFIG.18after all of the traffic control devices have been deployed and the work zone has been evaluated for violations. InFIG.19, the work zone display control has been deselected so that the traffic control devices are not listed in project list1600. InFIG.19, work zone inspection622ofFIG.6has discovered a layout violation, which is shown as violation entry1900. By selecting violation entry1900, the user causes a pop-up window2000ofFIG.20to be displayed that provides the identifier2002for the asset tracking device, the state of charge2004of the battery in the asset tracking device, an icon2006representing the traffic control device and a description of the layout violation2008. If the user has rights to modify the layout violation, the user may change the “flagged” designation2010to mute alerts based on the violation. Specifically, by leaving “flagged”2010checked, alerts will continue to be issued until the violation is corrected. By unchecking “flagged”2010, alerts will be muted.

Users with sufficient permission are provided with a user interface that allows the user to modify project information in the project information window.FIG.21provides an example of a user interface2100that includes map window1602and an editable project information window2102. InFIG.21, each field shown with a box around it is editable including the project description, the start and end date of the project, the start and end locations of the project, the origin of the project plan, and the start and end of each work zone in the project, for example.

In accordance with some embodiments, a chronoscopic view of projects is provided that allows a user to view projects that were/are/will be active within a date range.FIGS.22and23provide chronoscopic views for two different date ranges. Specifically,FIG.22shows active projects for a date range2202from 2018-04-12 to 2021-10-18 andFIG.23shows active projects for a date range2302from 2019-06-12 to 2021-10-17. During date range2202, project list2200indicates that seven projects were active and during date range2302, project list2300indicates that three projects were active. InFIGS.22and23, the date range is set using slider controls that set the start and end date of the date range. Although not shown, when the date range is changed, the icons on map1602also change to reflect the active projects for the date range. When the set date range only covers currently active and soon-to-be active projects, the information for the projects is taken from DMD602. When the date range includes past projects that are no longer active, the information for the inactive projects is taken from core database600.

Users with appropriate permissions can create projects directly in SWIS.FIG.24provides a project creation user interface where a user can enter the project name, description, and start and end dates of the project. The user can also create a new traffic control plan using control2400.

When control2400is selected, the user interface ofFIG.25is displayed, which includes input fields2500and2502for entering the start and end dates of the traffic control plan. The user interface ofFIG.25also includes a “Create New Work Zone” control2504. When control2504is selected, the user interface ofFIG.26is displayed, which includes Set First TCD control2600, Set Last TCD control2602, Save Work Zone control2604and a collection of traffic control device icons2606. Each of traffic control device icons1606depict the traffic control device they represent with the icons that represent signs showing the content of those signs. To add a traffic control device to the work zone, the user drags the corresponding icon from collection2606to the desired position for the traffic control device on map1602.FIG.27shows the user interface ofFIG.26after icons2700,2702,2704,2706,2708and2710have been dragged onto the map. Once placed on the map, an icon can be selected to display the position set for the traffic control device. This position information can then be edited to refine the position of the traffic control device.

After adding all appropriate traffic control devices, the user saves the project to SWIS with the “Save Project” button2712. The saved project will then become a project plan that a future deployment of traffic control devices will be compared against to determine if the traffic control devices are properly laid out. When button2712is selected, SWIS determines whether the project should be loaded into DMD602or core database600based on the start date of the project. In accordance with one embodiment, when the start date is less than 30 days away, the project is stored in DMD602. Otherwise, the project is stored in core database600.

1.1 Use Scenarios

1.1.1 Use Scenario for Short-Term Road Construction Project

A maintenance crew is deployed to fill potholes on a county road. As the work zone is on a two-lane, two-way road, it requires a flagger to provide traffic control so that vehicles can safely merge into the adjacent lane when one lane is closed. The first traffic control device the crew drops is a “Road Work Ahead” sign tagged with a SWIS asset tracking device. The asset tracking device connected to this sign sends its location to SWIS server508at 07:31 AM. The next sign—a “One Lane Road Ahead” sign with an asset tracking device—is dropped by the crew 762 feet downstream from the previous sign and sends its location to SWIS server508at 07:32 AM. The crew then drops a tagged “Be Prepared to Stop” sign 743 feet further downstream and a tagged “Flagger Ahead” sign another 750 feet downstream. The asset tracking devices connected to these signs send their locations at 07:34 AM and 07:35 AM, respectively. The asset tracking device connected to the “Be Prepared to Stop” sign sends its location to SWIS server508at 07:33 AM and the asset tracking device connected to the “Flagger Ahead” sign sends its location at 07:34 AM. Barring communication issues, it can safely be assumed that by 07:35 AM, SWIS server508has received the aforementioned messages.

At this point, SWIS server508has not concluded that any of these devices are on the same work zone. At 07:35 AM, unrelated to any events in the field, pre-check608is invoked. It uses the traffic control devices dropped by the crew to create a record of an active project. As no traffic control plan exists for the project, SWIS server508uses government rules and route metadata to determine the boundaries of the project. After the traffic control devices have been processed by process TCD module620, the pothole-filling project (albeit not fully set up) is now viewable to its managers in SWIS.FIG.28shows the work zone with deployed traffic control devices, and timestamps of messages received.

After the “Flagger Ahead” sign comes the work area itself. It begins with an upstream transition, consisting of a merging taper responsible for channeling traffic into the adjacent lane, circumventing the work space. The crew set up the flagging station and merging taper 1028 feet from the Flagger Ahead sign. They use cones and drop them in the manner described by government protocol. Only the first and last barrels are equipped with SWIS asset tracking devices, which send their location to SWIS server508at 07:36 AM and 07:39 AM. At 7:40 AM, process TCD module620is triggered again. It adds the recently dropped traffic control equipment to the project and extends the project's boundaries.

The project is using a flagging layout on a two-lane road, therefore the crew needs to deploy another Advance Warning Area for the adjacent lane. This Advance Warning Area is referred to as the Termination Advance Warning Area. At 07:45 AM, process TCD module620is triggered again, before the Be Prepared to Stop and Flagger ahead signs can send their location. Only the Road Work Ahead and One Lane Road Ahead signs are added to the record. This time, process TCD module620flags the project for inspection. As the pothole-filling project's Termination Advance Warning Area is missing signage, work zone inspection622determines the project is not fully set up, and does not inspect it. After the “Be Prepared to Stop” sign and the “Flagger Ahead” sign are dropped, the setup of the work zone is complete.

At 07:50 AM, the data associated with all tagged traffic control devices in the work zone of this project is processed. At 08:00 AM, work zone inspection622is activated again. Now that the work zone for the project is completely set up, an inspection is warranted. In the case of the pothole-filling project, the work zone has been set up correctly and all asset tracking devices are functioning normally. Therefore, no alerts are generated.

Work on the pothole-filling project concludes at 11:03 AM. The next time it is called, work zone inspection622can determine that project takedown is occurring due to the significant changes in location. SWIS updates its records to show that the project has concluded. Upon reaching the equipment warehouse, SWIS recognizes the location trackers attached to the signs are inside the geo-fence of a warehouse and orders them to enter power-save mode.

This section describes forks in the previous scenario. Each fork states where it begins in the scenario, how it is handled by the system, and where it ends and the scenario resumes. If the fork does not specify time, then the scenario is not drastically impacted chronologically.

1.1.2.1 Converging Deployment of Traffic Control Devices

This fork begins at the beginning of the scenario. Instead of one truck to deploy traffic control devices, the crew uses two. One truck begins at the Advance Warning Area while the other begins at the Termination Area of the Pothole Project's Work Zone. By 07:35 AM, the crews have deployed signs one through four, and seven through ten. When these traffic control devices are processed by the system, it groups them into two different SWIS Projects. When the system processes traffic control devices again at 07:40 AM, SWIS adds assets five and six to these projects. At 07:45 AM, sanity check624is triggered. It evaluates both projects and generates warnings for them. The routine then further assesses the projects and determines they should be one project. Therefore, the two SWIS projects are then merged. When this merged project is evaluated by the Inspection Routine at 08:00 AM, no further violations are generated and the warnings are suppressed and the scenario continues normally.

1.1.2.2 SWIS Uses the Wrong Speed Limit for the Route

This fork begins at 07:35 AM when the first traffic control devices are processed by SWIS. During setup, SWIS incorrectly determined the speed of the road to be 45 miles per hour instead of 55 miles per hour. This means that SWIS now expects the spacing between advance warning signs to be 600 feet instead of 750 feet. At 8:00 AM, when the SWIS Project is inspected for the first time, the system raises an alert to the crew's supervisor that their project is in violation of spacing requirements. As they know the speed limit is 55 miles per hour, the supervisor can either suppress the alert, or change the speed limit SWIS has inferred for the project. Regardless of their choice, the alert is resolved and the scenario continues normally.

1.1.2.3 Violation: Advance Warning Sign Spacing

This fork begins when the crew deploy the “Be Prepared to Stop” sign. Instead of 743 feet, the crew erroneously deploy the sign 942 feet downstream from the previously placed sign. This distance is greater than the accepted margin of error for sign spacing. When it runs at 08:00 AM, SWIS's Inspection Routine recognizes the placement as a violation of acceptable work zone layout and raises an alert to the crew's supervisor. Once they receive the alert, the supervisor can either suppress the violation or order their crew to move the sign to its correct location. They choose the latter option, and when the Inspection Routine is invoked again at 08:15 AM no violations are detected. The scenario continues normally.

1.1.2.4 Violation: Improper Temporary Traffic Control Layout

This fork begins with the deployment of the sign after the “Road Work Ahead” sign. Instead of the “One Lane Road Ahead” and “Be Prepared to Stop” advanced warning signs, the crew deploy a “Flagger Ahead Sign”. They then set up the work space and make the same error with setting up the downstream advance warning area. When SWIS runs its Inspection Routine at 08:00 AM, it determines that both advance warning area setups are in violation of work zone layout rules and generates an alert to the crew's supervisor.

The supervisor sends the truck back to the yard to obtain the required traffic control devices. When it returns at 8:47 AM, the crew corrects the layout by moving the “Road Work Ahead” sign for both advance warning areas upstream by approximately 1500 feet, making space for the two signs in between. When they complete the deployment by 08:55 AM, process TCD module620updates the start and end points of the SWIS Project and its Work Zone to reflect the placement of the “Road Work Ahead” signs. At 09:00 AM the project is inspected by SWIS's scheduled Inspection Routine, which yields no violations. The scenario continues normally.

1.1.2.5 Non MUTCD Compliant TCD Deployment

This fork assumes that the pothole filling project is comprised of two pothole filling operations along County Road138. After completing traffic control device deployment at 07:39 AM, the crew preemptively deploy another set of Advance Warning Area Signs 2000 feet before the “Road Work Ahead” sign of the Termination Advance Warning Area. This is a common practice in the industry, but it does not comply with government regulations. While the extra signage may confuse motorists and compromise the safety of the crew, it means they will not need to walk all the way upstream to collect the first four Advance Warning Area signs. They complete this setup by 07:52 AM and begin filling the potholes in the first work area.

When SWIS's scheduled Inspection Routine is invoked at 08:00 AM, it detects three Advance Warning Areas in the project's work zone. As there are no subsequent traffic control devices after the last Advance Warning Area, SWIS determines that it is not actively part of the current work zone. Therefore, SWIS removes the devices from the work zone and associates them as rogue traffic control devices of the project.

The crew finish filling the potholes of the first work zone at 11:03 AM and proceed to deploy the second. They pick up the traffic control devices from the Work Area and Termination Advance Warning Area and deploy them after the preemptively deployed Advance Warning Area, leaving the first Advance Warning Area. This deployment is completed by 11:14 AM. The preemptively deployed Advance Warning Area is still associated with the project as a set of rogue traffic control devices. When SWIS's Inspection Routine is invoked at 11:15 AM, the distance between the first Advance Warning Area's last traffic control device and the Work Area's first traffic control device violates government regulations. This prompts SWIS to further assess the project and determine that the previously rogue traffic control devices are exactly where an Advance Warning Area should be. Therefore, SWIS re-classifies the traffic control devices in the preemptive Advance Warning Area as being part of the project and updates its bounds. The system then associates the traffic control devices from first Advance Warning Area as rogue traffic control devices of the project.

Work on the pothole-filling project concludes at 3:06 PM. The next time it is called, SWIS's Inspection Routine determines that project takedown is occurring due to the significant changes in location. SWIS updates its records to show that the project has concluded. Upon reaching the equipment warehouse, SWIS recognizes the location assets attached to the signs are inside the geo-fence of a warehouse and disregards further messages until they are moved again.

1.1.2.6 Asset Hardware Failure

This fork begins while workers are filling potholes. At 09:02 AM, the SWIS asset on the upstream Advance Warning Area's “Be Prepared to Stop” sign experiences catastrophic hardware failure. It loses contact with the SWIS server. The work zone is still set up correctly, but the system is unable to verify this is what is currently true in the work zone. When the Inspection Routine is run on the project at 09:45 AM, SWIS alerts the crew's supervisor that it has not heard from this asset tracking device in the threshold that the asset tracking devices have been configured to send messages to SWIS. The supervisor has the option to either suppress alerts regarding the asset tracking device for the duration of the project or until a replacement asset tracking device can be installed on the sign. In this case, the supervisor chooses the first option. The scenario continues normally.

1.1.2.7 Asset Power Loss

This fork begins in the previous fork at 09:02 AM. Instead of hardware failure, the asset tracking device's battery level dips below 20%. When the Inspection Routine Executes at 09:15 AM, a warning is generated for the asset tracking device. When the Inspection Routine Executes at 09:30 AM, another warning is generated for the asset tracking device. These warnings are not forwarded until their third occurrence. At 09:45 AM, when the Inspection Routine generates its third warning for the asset tracking device and its battery level is at 13% an alert is sent to the crew's supervisor. The supervisor has the option to suppress the alerts regarding the asset tracking device for the duration of the project or until a replacement battery (or asset tracking device) can be installed on the sign. In this case, the supervisor instructs his crew to swap out the dying battery in the asset tracking device with a new one. The scenario continues normally.

In accordance with one embodiment, the various clients described above are written in JavaScript while the server and other components are written in Python. Data pertaining to projects and system configuration are stored in a SQL database which is acted on by the SWIS server. The client is responsible for displaying project data for users and the server is responsible for work zone layout inspection, communication with deployed assets (IoT location aware asset tracking devices), as well as hosting and transmitting project data.

The embodiments described above provide a simple means for project managers to monitor work zones around a state. As a result, project managers are able to monitor a large number of work zones without physically visiting the work zones as was required in the past. The system also automatically inspects work zone layouts and notifies work crews when a work zone does not match a project plan or government regulations. The embodiments also provide a system that records the layouts of short-term work zones that do not have a documented project plan. In the past, the layout of such work zones was not recorded making it difficult to evaluate the efficacy of traffic control devices in such work zones. While long-term work zones are extensively planned, there is, like for short-term work zones, a lack of statistics regarding the efficacy of traffic control. To generate meaningful statistics for these work zones there needs to be a means of collecting real-time work zone layout information and comparing it to what planners have dictated the layout should look like. The embodiments above provide the actual layout of the traffic control devices and flag any deviations so that there is an accurate record of how the work zone was laid out. The embodiments above also provide real-time work zone information to the driving public that allows the public to select different routes or modes of transportation in response to all kinds of work—not just the big, long-term projects that cause the most disruption. In addition, the embodiments provide detailed work zone information that allow navigation applications to notify users and vehicles of approaching work zones.

FIG.29provides an example of a computing device10that can be used to implement one or more of the servers discussed above. Computing device10includes a processing unit12, a system memory14and a system bus16that couples the system memory14to the processing unit12. System memory14includes read only memory (ROM)18and random-access memory (RAM)20. A basic input/output system22(BIOS), containing the basic routines that help to transfer information between elements within the computing device10, is stored in ROM18. Computer-executable instructions that are to be executed by processing unit12may be stored in random access memory20before being executed.

Computing device10further includes an optional hard disc drive24, an optional external memory device28, and an optional optical disc drive30. External memory device28can include an external disc drive or solid-state memory that may be attached to computing device10through an interface such as Universal Serial Bus interface34, which is connected to system bus16. Optical disc drive30can illustratively be utilized for reading data from (or writing data to) optical media, such as a CD-ROM disc32. Hard disc drive24and optical disc drive30are connected to the system bus16by a hard disc drive interface32and an optical disc drive interface36, respectively. The drives and external memory devices and their associated computer-readable media provide nonvolatile storage media for the computing device10on which computer-executable instructions and computer-readable data structures may be stored. Other types of media that are readable by a computer may also be used in the exemplary operation environment.
A number of program modules may be stored in the drives and RAM20, including an operating system38, one or more application programs40, other program modules42and program data44. In particular, application programs40can include programs for implementing any one of the applications discussed above. Program data44may include any data used by the systems and methods discussed above.
Processing unit12, also referred to as a processor, executes programs in system memory14and solid-state memory25to perform the methods described above.
Input devices including a keyboard63and a mouse65are optionally connected to system bus16through an Input/Output interface46that is coupled to system bus16. Monitor or display48is connected to the system bus16through a video adapter50and provides graphical images to users. Other peripheral output devices (e.g., speakers or printers) could also be included but have not been illustrated. In accordance with some embodiments, monitor48comprises a touch screen that both displays input and provides locations on the screen where the user is contacting the screen.
The computing device10may operate in a network environment utilizing connections to one or more remote computers, such as a remote computer52. The remote computer52may be a server, a router, a peer device, or other common network node. Remote computer52may include many or all of the features and elements described in relation to computing device10, although only a memory storage device54has been illustrated inFIG.29. The network connections depicted inFIG.29include a local area network (LAN)56and a wide area network (WAN)58. Such network environments are commonplace in the art.
The computing device10is connected to the LAN56through a network interface60. The computing device10is also connected to WAN58and includes a modem62for establishing communications over the WAN58. The modem62, which may be internal or external, is connected to the system bus16via the I/O interface46.

In a networked environment, program modules depicted relative to the computing device10, or portions thereof, may be stored in the remote memory storage device54. For example, application programs may be stored utilizing memory storage device54. In addition, data associated with an application program may illustratively be stored within memory storage device54. It will be appreciated that the network connections shown inFIG.29are exemplary and other means for establishing a communications link between the computers, such as a wireless interface communications link, may be used.