Chapter 3. Best Practices

Chapter 2 described current industry practices that agencies use in the design, management, and operations of their RCRS, together with the benefits recognized. A number of these practices have clearly demonstrated benefits to one or multiple agencies and have been selected as best practices to be further highlighted in this chapter. This chapter will describe each best practice approach listed in Table 8 and the benefits achieved by it.

The distinguishing factor between industry practices and best practices is that the best practices are those activities with the greatest benefits described or those practices that were deployed by multiple agencies, demonstrating benefits to each agency.

Several of the best practices included in this section are practices that have been implemented by multiple agencies. For these scenarios, the experiences of several agencies are presented to allow the reader to experience various details of implementation.

Table 8. Identified Best Practices Discussed in this Chapter

Identified Best Practice	Description
#1 – Automated Ingest of Law Enforcement CAD Data	An automated one-way transfer of data between the law enforcement CAD system (or systems in some states) and the RCRS. Through this transfer, a subset of the incidents in the CAD system are exported and automatically received by the RCRS. Sensitive information is removed and the event that is received by the RCRS contains only the description of what is occurring.
#2 – Combining RCRS Entry with Other Activities	Users of the RCRS are not performing entry solely for the purpose of populating the RCRS, but rather they are performing other functions, and achieving efficiencies, while improving the content of the information in the RCRS.
#3 – RCRS Ingest of Weather Data	A regular, automated ingest of weather data collected by systems external to the RCRS. Through this exchange, the regularly updated weather data is ingested on a timed cycle, and replaces the previous reports.
#4 – Integrating Lane Closure Databases into RCRS	The DOT operates a database and/or spreadsheet to track lane closures from the time that they are initially proposed and identified to result in a lane closure. This may be during early planning of roadwork to be performed in subsequent years, or it may be during the creation of emergency lane closures proposed for the following day. Creating a link between these databases and the RCRS ensures that an additional step is not required to inform TOC operators of planned lane closures.
#5 – RCRS Events Trigger of Field Device Messages	RCRS logic processes each active event against rules that determine when a message is applicable for display on one or more field devices (permanent or portable). Agencies may differ in their business rules regarding whether the RCRS generated messages are ‘recommended’ and must have operator approval before implementation, or if they are automatically implemented.
#6 – Generating Automated Performance Measure Data	RCRS records the time/date stamps assigned to key manual and automated actions (performed either by DOT staff or the RCRS), and store these time stamps to later generate reports. RCRSs that generate performance measure output are typically those that combine road condition and incident reporting with DOT dispatch and incident management (Best Practice #2). This is what allows for the time reports describing when responders arrive on scene and clear the incident.
#7 – Development and Operation Collaboration	Sharing at least a core portion of the RCRS software, and therefore eliminating the costs of each agency purchasing or creating the software. Collaboration can include common hosting of the RCRS (avoiding the IT hosting responsibility in each agency), or some collaborators sharing to develop additional modules or features that other members do not need, thus fulfilling their unique needs, while sharing cost savings.

Best Practice #1: Automated Ingest of Law Enforcement CAD Data

One challenge facing agencies is the timely entry of reliable incident and road closure information into the RCRS. Most incidents are now reported through cellular 9-1-1 calls to law enforcements agencies at the state or local level. Typically, when law enforcement agencies receive notices of incidents, they enter the details in their CAD system and manage the incident response. To include these event descriptions in a DOT RCRS, DOT staff need to acquire the information and manually re-enter the incident information into the RCRS.

A best practice implemented by a number of agencies to promote rapid entry of incidents into the RCRS and to minimize staff time required to enter events is the automated ingest of law enforcement CAD data into the RCRS. The concept that is common to deployments of this best practice is an automated one-way transfer of data between the law enforcement CAD system (or systems in some states) and the RCRS. Through this transfer, a subset of the incidents in the CAD system are exported and automatically received by the RCRS. Sensitive information (e.g., describing details of the crash or names of individuals) is removed and the event that is received by the RCRS contains only the description of what is occurring. This typically includes one or more phrases describing the situation, the incident location, and any additional details. Approaches differ in how the CAD incident descriptions are accepted into the RCRS, but typically there is some level of RCRS operator review before incidents become active events stored in the RCRS.

Best Practice Status: At least four documented deployments of this best practice were identified. Each deployment is beyond the proof of concept phase and accepted as a fully implemented component of the RCRS, delivering daily benefits.

Success Stories

The concept of automating the ingest of law enforcement CAD data into RCRSs was originally researched and demonstrated through a series of FHWA sponsored operational tests in Washington State¹⁹ and Utah²⁰ between 2002 and 2006. Since early demonstrations, a number of agencies have created the automated ingests to deliver CAD data to RCRSs, examples of these are highlighted as follows:

In Minnesota, the RCRS has ingested incident reports from the State Patrol CAD system since 2010. The integration removes sensitive information from CAD-generated events and ingests them into the RCRS, allowing operators to take over further updates to the entry and add further details (e.g., add event duration, change the location description of the event). The integration has worked well but initially there were issues with transferring data between the two agency firewalls that led to 5-10 minute delays in data transfers. That issue was resolved through CAD system updates. RCRS operators may select if they wish for the incident to continue to be updated as additional CAD updates come in, or if they wish for all updates to be performed by RCRS operators.

Wisconsin DOT operates CAD to RCRS integration. In Wisconsin, law enforcement CAD to RCRS integration ingests incident reports from the Wisconsin State Patrol, the Milwaukee County Sheriff’s Office, and a handful of other local law enforcement CAD systems in Wisconsin. Integrating from multiple law enforcement CAD systems introduces some additional challenges. Similar to other examples, the ingest of CAD data removes any sensitive information and filters incidents that are not of interest to WisDOT. The incident descriptions are then translated from the Global Justice XML Data Model format into the IEEE 1512 standard format. The incidents are then integrated into the ATMS software operated by WisDOT as incidents. The operators in the statewide TOC then take over updating the incidents.

New York State Thruway Authority (NYSTA) is another agency operating an automated interface between the CAD system and the RCRS. NYSTA operates the same RCRS software as MnDOT operates. Feedback from NYSTA indicated that the 9-1-1 center CAD integration has greatly reduced the need for voice communication with the State Police to understand incidents. To that extent, NYSTA estimated that 90-95% of all incidents in the RCRS come from the State Police CAD system integration. A key finding in the NYSTA system was the need for RCRS operators to be able to edit the location of the event that is received from the CAD system. The location edit feature was determined to be critical, as often the location contained in the CAD system does not match the actual location of the event, or because the traveler information event disseminated to the public is best described by a larger area (e.g., between two major intersections) to allow drivers to detour and avoid the event.

West Virginia is another state DOT operating an automated interface with 9-1-1 center CAD systems. The RCRS operated by West Virginia DOT (WVDOT) operates an automated ingest function to acquire incident reports from the various 9-1-1 call centers’ CAD systems. Traffic operators at the statewide TMC receive popup notices in real time as 9-1-1 operators enter new and updated data on 9-1-1 calls. Incident reports to the TMC are filtered to remove any sensitive information. The traffic operator can approve the default message, replace it, or add amplifying remarks. It is a conscious policy to force traffic operator to intervene before information is sent to the public. 9-1-1 system data is not necessarily verified or appropriate for the public, so traffic operators are required to exercise their judgment before sending information to the public. West Virginia has 9-1-1 integrations in place for almost all counties which contain Interstate mileage. Plans are in place to add coverage for all remaining Interstate mileage as well as strategically chosen US primary routes.

Automated Ingest of Law Enforcement CAD Data – Benefits

Increase in number of incidents reported in the RCRS Increased timeliness of incident reports Reduced workload having to manually enter incidents (as many as 95% of incidents automatically received Reduced verbal communications with law enforcement agencies.

Best Practice #2: Combining RCRS Entry with Other Activities

Several industry practices included in Chapter 2 describe approaches where the entry of incidents and events into the RCRS is accomplished not as a stand-alone activity, but in conjunction with other DOT or law enforcement activities. These actions “Combining RCRS entry with other activities” is identified as a best practice because a number of states actively execute this and have recognized benefits. The concept that is common to all uses of this best practice is that the users of the RCRS are not performing entry solely for the purpose of populating the RCRS, but rather they are performing other functions, and achieving efficiencies, while improving the content of the information in the RCRS. Individual agencies have achieved this best practice through a variety of approaches. In some situations, one common software solution is used as both the RCRS and the incident response and dispatch system. In other situations, the RCRS software remains a separate system, but staffing arrangements result in one group performing multiple dispatch activities in addition to RCRS entry.

Best Practice Status: At least four examples of combining RCRS entry with other activities were identified, although the approaches are all different. The deployment examples are all well embraced by the agencies operating them, suggesting that combining RCRS entry with other activities (using a variety of approaches) is an acceptable long term solution.

Success Stories

Oregon and Florida are examples where a combined RCRS/Incident management system is used by operators. In Oregon, the use of one common software system by TOC operators to record phone and radio reports, manage maintenance or incident response and to perform RCRS entry ensures that there is never the need to perform dual entry of incident information, and ensures that all incidents that Oregon DOT staff are responding to are included in the RCRS. For example, a phone or radio report of a tree falling and blocking a lane or road would be entered in the system, as would the actions taken to dispatch maintenance crews to remove the tree and related debris. This same entry would result in the RCRS storing an event describing the lane closure and disseminate this information to the public. Internal filters automatically determine which entries are disseminated through traveler information systems. In Florida, operators in the 12 TOCs use the combined TMC/RCRS software to manage incidents and report details of the incident for information dissemination. Combining the incident management and RCRS functionalities as Oregon and Florida do has the benefits of comprehensive data in the RCRS, reduced staff time performing dual entry, and allows both DOTs to generate detailed performance measure metrics for incident response.

Another example of this best practice is Washington State DOT integrating their RCRS with their radio log system (used to log all calls and radio communications during the dispatch of incident response) through a common database. The integration of the two systems through a common database prevents the need for dual entry. As a radio operator receives a call and enters it into the radio log, they can hit a button causing the event to also be part of the RCRS, where TMC staff could also add details to the event description. Because radio operators are staffed 24/7 and TMC staff are not always staffed 24/7, this allows RCRS entry by the radio operators at all times. Again, the benefits are more comprehensive coverage of RCRS reports and reduced dual entry.

In Idaho, RCRS entry is integrated with other activities through a unique staffing approach. The Idaho Transportation Department (ITD) has a contract with the Idaho Department of Health and Welfare (DHW) agency, Emergency Medical Services (EMS) Bureau to perform RCRS entry. The EMS staff members also perform medical dispatch, and dispatches for a variety of other services, including Idaho Bureau of Homeland Security, HazMat response and Idaho Fish and Wildlife. Because this one group of dispatchers performs dispatching for such a wide variety of services, they have a vast knowledge and understanding of the conditions, events, and incidents impacting Idaho. This allows for accurate and thorough descriptions of conditions and events in the Idaho RCRS and extensive coordination among agencies during major events, and avoids the need for any dual entry in multiple systems.

Combining RCRS Entry w/Other Activities – Benefits

More comprehensive set of incidents and events in RCRS Reduced need for dual entry of events Ability to generate detailed performance measure reports

Best Practice #3: RCRS Ingest of Weather Data

Weather measurements from environmental sensors deployed at RWIS sites provide real-time automated data describing the atmospheric and pavement conditions. However, the integration of RWIS data into an RCRS is not a trivial concept, as manual entry is a labor intensive task. A best practice implemented by a number of agencies is the automatic ingest of weather data (including RWIS data, NWS data, or other weather reports) into RCRSs. The concept that is common to all the deployments is a regular, automated ingest of weather data collected by systems external to the RCRS. Through this exchange, the regularly updated weather data is ingested on a timed cycle, and replaces the previous reports. The approaches differ in the source of the weather data. Some RCRSs ingest data from agency operated RWIS sites equipped with atmospheric and pavement sensors to record data, while others ingest NWS provided data describing conditions, watches and warnings. Another aspect of the best practice that differs by approach is how the RCRS stores the weather data. Some systems assign the weather data to a stretch of highway as an “event”, another example is to use a set of rules to attach weather reports to incidents manually entered in the RCRS based on the location of the incident. Finally, some RCRSs store the weather data ‘as reported’ for on-screen map displays to operators and travelers.

Best Practice Status: A large number of agencies have deployed and continue to operate RCRS ingests of weather data, suggesting that this is a best practice that offers many benefits and is well accepted by RCRS operators. Similarly, RWIS sites are extensively deployed throughout the country to support a consistent use of this practice.

RCRS Ingest of Weather Data – Benefits

More timely weather reports in the RCRS Reduced manual entry of weather conditions RCRS users can view weather information to assist in creating event descriptions Increased weather information disseminated to travelers

Success Stories

There is wide-scale deployment of RWIS systems, particularly in cold weather states. The RWIS data is always available to DOT agencies, and also is often disseminated to the traveling public. Similarly, there is national coverage of NWS atmospheric weather data, watches and warnings. The benefits of this best practice are achieved when DOTs create an automated ingest of the weather data into the RCRS. This project identified five state DOTs that have achieved success in creating and operating this ingest. The following real-world deployment examples describe more details of this best practice.

In Maryland, the CHART RCRS ingests data from the RWIS network to deliver high-level roadway weather information to travelers. In addition to ingesting the weather information, the RWIS data is also automatically added to any incident entered into CHART to maintain a record of road conditions at the time of the event. A unique aspect to the Maryland approach is that attaching weather reports to incidents allows the department to identify patterns between incidents and weather conditions.

In Ohio, basic air and pavement data from the 174 RWIS sites throughout the state are integrated into the Buckeye RCRS every five minutes. This ingest of RWIS data provides additional information to travelers and allows internal Ohio DOT staff to view the weather information through the RCRS, which is particularly helpful when updating the manual road weather reports.

North Dakota DOT integrates wind speed and radar data into their RCRS. The wind speeds are stored in the RCRS and passed to the department’s traveler information website for display to travelers. Both the wind speeds and the radar data are visible to RCRS users to allow them to view current conditions and make decisions about weather pattern changes.

Idaho operates a module to their RCRS that ingests RWIS data and assigns a “circle of influence” to the weather reports based on rules that are mostly dictated by the terrain surrounding the RWIS site (e.g., mountainous terrain the circle of influence is smaller than flat areas). The weather reports are presented on the 511 website together with the circle of influence, allowing website visitors to understand what geographic area is most likely experiencing the conditions.

Iowa DOT operates a module in their RCRS to ingest National Weather Service watches, warnings, advisories and other similar products in the Common Alert Protocol (CAP). A unique benefit to this is that the interface that ingests the data can now be used for additional alerts published using the CAP.

Best Practice #4: Integrating Lane Closure Databases into RCRS

Disseminating planned lane and road closure information due to roadwork or other DOT activities has potentially tremendous benefits. These benefits diminish if not all the lane closing roadwork events are included, or if the reports lack details of when and where lane closures will occur. There are significant challenges to assembling a comprehensive list of roadwork activities, especially when attempting to describe specific details of closures. This project identified several examples where DOTs use an internal database to plan, authorize, and track upcoming and active roadwork related lane closures. In these examples, there is an automated link between these internal planning databases and the RCRS, creating an environment where roadwork entries in the RCRS are accurate and comprehensive. For these reasons, this was identified as a best practice. The concept that is common to all the example deployments is that the DOT operates a database and/or spreadsheet to track lane closures from the time that they are initially proposed and identified to result in a lane closure. This may be during early planning of roadwork to be performed in subsequent years, or it may be during the creation of emergency lane closures proposed for the following day. In these cases, the database is typically used to circulate notice of the lane closure and ensure that proper authorizations or permits are obtained. Creating a link between these databases and the RCRS ensures that an additional step is not required to inform TOC operators of planned lane closures.

Best Practice Status: Three deployment examples related to this best practice were identified, and the extent that other agencies follow similar practices is unknown. This best practice offers a solution to a challenge that all agencies face, however the internal planning database (and the committed use of the database by others in the agency) is critical to implementing this, therefore it is a best practice that is only suitable to agencies with these existing conditions.

Success Stories

Research and outreach conducted in this project identified three examples where an internal database tracking planned closures is integrated with the RCRS, as follows:

In Wisconsin, DOT staff throughout the agency use the Lane Closure System (WisLCS) to enter the proposed lane closures, describing impacts, activities, dates and times of closures. The range of staff that uses this tool includes Planning, Construction, and Maintenance. WisLCS is described as an internal business process and approval tool, as any staff involved in planning, operating, or approving lane closures uses the tool to enter, describe, approve, or remove lane closure descriptions. In addition to serving as the business process and approval tool, WisLCS acts as one module of the overall RCRS. Therefore, there is no need for TOC operators to enter lane closures into an RCRS, each closure exists in the WisLCS as a result of the business process followed to create, describe, and approve the closure.

In Maryland, the Lane Closure Program is used by Maryland State Highway Administration (MDSHA) to enter permits for any along roadways under MDSHA jurisdiction. The respective districts review and approve permits as they are requested. When the scheduled day of work arrives, contractors notify MDSHA staff to activate their permit. MDSHA staff verifies the permit and enters the roadway impacts in CHART as they were defined in the permit. The permitting process ensures that all roadwork is known before it occurs and the integration with CHART allows travelers to receive up-to-date information about potential impacts.

Michigan has developed and uses an agency-wide reporting tool to enter planned and active roadwork, describing every stage of the project. The planning group in Michigan DOT uses this tool when construction projects are being planned, initiating entry of events early in the planning stage. Similarly, the construction group may also create road work events or update events already created by the planning group. Similarly, as maintenance activities are planned by the maintenance group, they are entered into the same tool. This tool is used to describe planned road work through each stage of the approval and/or permitting process. The use of this one common entry tool for creating road work projects, and editing them (with edits coming from multiple groups), provides an environment where accurate descriptions about the construction and maintenance activities are available in one database, together with information about impacts that drivers can expect.

Integrating Lane Closure Databases into RCRS – Benefits

Increased number of lane closing events in the RCRS Reduced manual entry of roadwork Increased details of when and where lane closures will occur

Best Practice #5: RCRS Events Trigger of Field Device Messages

The most common role performed by an RCRS is the automated supply of information to the state DOT traveler information website and phone system. However, a number of agencies also rely on their RCRS to automatically create messages to be disseminated through field devices, such as DMS and HAR. These approaches are identified as best practices as they remove or reduce the manual intervention needed from operators to disseminate information to travelers through field devices. The common aspect of all these example deployments is RCRS logic that processes each active event against rules that determine when a message is applicable for display on one or more field devices (permanent or portable). Agencies may differ in their business rules regarding whether the RCRS generated messages are ‘recommended’ and must have operator approval before implementation, or if they are automatically implemented. Similarly, the approach toward executing the field device messages may also differ. For systems where the RCRS has combined functionality with a TMC software, the RCRS/TMC software will communicate directly to the field device. Other situations utilize ITS standards for center to center communications where the RCRS communicates with the TMC software responsible for controlling the display of DMS or HAR messages.

Best Practice Status: At least three deployment examples were identified and other deployments are likely. For RCRSs that are combined with TMC software, this best practice is straight-forward and has a high likelihood for achieving benefits. Other RCRSs require another TMC software for the RCRS to communicate with using center-to-center standards, to support the full integration. Either way, the benefits of allowing RCRS entry and field device control without the need to access two systems are clearly recognized.

Success Stories

Research and outreach conducted in this project identified a number of examples where the RCRS triggers the recommendation of messages for field device control:

The New York State Thruway Authority (NYSTA) RCRS operates modules that consider all active incidents in the RCRS and recommends message content to be posted to one or more DMS signs and broadcast from one or more HAR stations. This RCRS functionality helps operators make decisions about what messages to post as quickly as possible, considering the location of the event, the location of the field devices, and other active events and messages disseminated on the field devices. As incidents are entered in the NYSTA RCRS (either by operators using the user interface, through the integration with the CAD-9-1-1 interface, or through the TRANSMIT integration), the system automatically processes a set of rules and generates recommended messages for either permanent or portable DMS signs upstream of the incident(s). A similar set of rules also recommends messages for broadcast on the HAR towers. Operators using the RCRS are able to view recommended messages, and may either confirm the message or edit the message before posting, or ignore the message suggestion. The NYSTA operators use the RCRS to manually enter messages to be displayed on portable or permanent DMS. Therefore, the RCRS maintains information describing the current messages displayed on each sign. This allows ‘rules’ or algorithms to consider whether other existing messages (e.g., messages manually entered by users for display on the sign) are higher in priority to messages that might be generated to describe incidents on the Thruway.

The control of HAR towers is similar, with NYSTA staff using the RCRS to define content to be played on the HAR stations. Logic in the RCRS considers the current play list for each HAR tower and identifies recommended messages to be broadcast on the HAR towers. As events in the RCRS expire or are cancelled by operators, the same logic automatically clears DMS message displays or HAR tower broadcasts describing the event. NYSTA staff worked with the contractor to develop the logic that determines the messages that are recommended for both DMS and HAR. Travel times are a common message displayed on DMS and broadcast over HAR, especially during peak periods.

The Florida SunGuide Software System has the ability to automatically recommend messages to be posted on DMS based on current events and conditions. The SunGuide System operates with a message template editor that enables DOT operators to customize how they want different types of events to be described on DMS. For example, FDOT can configure a template describing how major crashes should be described in a DMS message, and another template modification can describe how minor crashes should be defined.

In Iowa, HAR and Low Power FM broadcasts are used to disseminate traveler information through AM and FM radio broadcasts. The playlists and content are determined by the RCRS, using a set of rules similar to those described above.

Benefits of the deployments of this best practice include

• Quicker posting of messages to DMS and HAR, and therefore better informed travelers;
• Support to operators to consider all incidents and all DMS when determining a response; and
• Reduced staff time that would otherwise be spent entering messages for field device display.

RCRS Events Trigger of Field Device Messages – Benefits

Reduced manual creation of DMS and HAR content Reduced time to display incident and event information on DMS and HAR Consideration of the broad picture of events when selecting messages

Best Practice #6: Generating Automated Performance Measure Data

Many state and local DOTs now identify performance targets, and use performance measures to decide how to invest resources in projects that will achieve these targets. A key aspect of Map-21 is the establishment of a performance and outcome based program. Several states now use their RCRS to generate the data to support performance measurements. The concept that is common to the best practice deployment examples is that the RCRSs record the time/date stamps assigned to key manual and automated actions (performed either by DOT staff or the RCRS), and store these time stamps to later generate reports. These time stamps create a timeline for incident response that typically includes:

• Time the incident is reported;
• Time the incident is available on 511 phone, web and social media outlets;
• Time that DOT or law enforcement responders arrive on scene;
• Time that the scene is cleared;
• Time that any reports of traffic delay or lane closures are cleared; and
• Any times that condition reports change (e.g., entering a lane or road closure for limited periods during response).

A unique aspect of this best practice is that the RCRSs that generate performance measure output are typically those that combine road condition and incident reporting with DOT dispatch and incident management (see Best Practice #2). This is what allows for the time reports describing when responders arrive on scene and clear the incident.

Best Practice Status: At least three deployment examples were identified and the agencies have used the RCRS for performance reporting for multiple years. The benefits are high and the risks are low for this deployment. It is suitable to agencies that enter enough data into the RCRS to generate the performance measures needed.

Success Stories

Three examples of this best practice were identified. In each example, the agencies have come to rely on the output of the RCRS to generate performance measurements.

The Oregon RCRS performance measure reports allow Oregon DOT to track such things as the percentage of incidents disseminated to the traveling public within 10 minutes of notification. In addition, the report includes a graph displaying the monthly average delay in notifying the public of incidents and condition changes. The integration of the Oregon DOT RCRS with the actual system used to manage incidents makes the performance reporting possible. It creates a set of data about milestones such as:

New Jersey DOT has been generating monthly performance reports for the Federal Highway Administration’s division office since 2006. The reports present information about incident management performance and they are generated using data from the agency’s RCRS. In 2008, New Jersey DOT and FHWA worked together to identify a set of performance measures that could be reported on a monthly basis. The following performance information is included in the monthly report to FHWA:

• Number of incidents;
• Average incident duration;
• Number of incidents > 90 minutes in duration and number of incidents < 90 minutes in duration;
• Incidents during peak/non-peak;
• Total incidents on freeways/arterials;
• Incidents involving fatalities; and
• Incidents involving Incident Management Response Team (IMRT).

The reports further break down the information by incident type (e.g., crash, emergency roadwork, debris on roadway) and by roadway. This information is not only reviewed by FHWA, it is also used by the New Jersey DOT as a resource in their congestion relief program.

The reports are specified by New Jersey DOT and programmed to be automatically generated by the RCRS.

Because the Florida RCRS functionality is integrated as part of the overall event management, the result is a ‘rich’ data set of information describing all aspects of each event. The RCRS is capable of automatically generating performance measurement reports that describe individual event details, weekly, monthly, quarterly, or annual measures. Some example outputs that can automatically be generated by the system include:

• Notification Duration – the number of minutes between the time FDOT or FHP are notified and the TMC/TOC is notified;
• Verification Duration – the number of minutes between the time the FDOT TMC/TOC is notified and the TMC/TOC verifies the event;
• Response Duration – the number of minutes between the TMC/TOC verifying the event and first responder arriving on the scene;
• Open Roads Duration – the number of minutes between the first responder arriving and the travel lanes being cleared;
• Roadway Clearance Duration – the number of minutes between the initial FDOT or FHP notification and the travel lanes being cleared; and
• Incident Clearance Duration – the number of minutes between the FDOT or FHP notification time and the time the last responder departs from the incident.

RCRS Generates Automated Performance Measure Data – Benefits

Increased performance management data Reduced staff time tracking performance metrics Better understanding of the impacts of traveler informations

Best Practice #7: Development and Operation Collaboration

The costs of developing and maintaining an RCRS can be significant. Beyond the costs related solely to the software, there are costs related to the planning and design of the system (including costs to continuously monitor the changing landscape of Internet browsers and functionality supported), the costs of training, and training materials and other documentation. There are several examples of agencies that have collaborated together to develop, maintain, and continue to enhance one common RCRS. A common aspect of agencies collaborating in the development of the RCRS is the sharing of at least a core portion of the RCRS software, and therefore eliminating the costs of each agency purchasing or creating the software. Beyond this commonality, there are examples where collaboration includes common hosting of the RCRS (avoiding the IT hosting responsibility in each agency). There are also examples where some members sharing in the collaboration develop additional modules or features that other members do not need. Therefore, these agencies accomplish their unique needs, while still sharing in the cost savings.

Best Practice Status: There are examples of agencies collaborating in RCRS development for more than 15 years. This is a proven success story for those agencies that can accept the compromises of collaborative development in exchange for the benefits that come with it.

Success Stories

One example of RCRS collaboration is TRANSCOM, where three states (New York, New Jersey, and Connecticut) use a common RCRS, allowing operators in each state to see incidents across jurisdictions. This common RCRS works as the agencies are adjacent to each other and one central system provides seamless integration of incidents.

Another example is the CARS Consortium, where a group of agencies collaborate in the development, operations, and hosting of the RCRS software, but individual software applications are operated for each agency. Consortium members cited the sharing of development costs, the sharing of training and user materials, and the sharing of lessons learned as key benefits of this type of collaboration.

Another example of shared source code deployed in different locations is the Florida and Texas collaboration on the SunGuide / LoneStar systems. Similar benefits were cited, including shared development costs, experience sharing, and collaboration among users.

The nature of RCRSs is such that similar functions are performed by nearly every agency that operates an RCRS. Therefore, the opportunities for collaboration, cost sharing, and technology transfer are tremendous. Collaborating with other agencies is not suited to all organizations. Collaboration implies some compromise between partnering agencies, but the individuals sharing their experiences on this best practices relayed a feeling that the benefits outweighed the drawbacks.

Collaboration In Development and Operation of RCRS – Benefits

Cost sharing with partner agencies Sharing lessons learned, training material, and other resources Opportunities for economies of scale and increased capacity when hosted together