Highway Safety Manual Case Study 2: Implementing a New Roadway Safety Management Process with SafetyAnalyst in Ohio
The Federal Highway Administration (FHWA) developed SafetyAnalyst under a pooled fund study in cooperation with participating state and local agencies. SafetyAnalyst is a software tool designed to implement analysis methods presented in the American Association of State Highway and Transportation Officials’ (AASHTO’s) Highway Safety Manual (HSM) Part B- Roadway Safety Management Process, Chapters 4 through 9. As such, SafetyAnalyst contains tools to perform Network Screening, Diagnosis, Countermeasure Selection, Economic Appraisal, Priority Ranking, and Countermeasure Evaluation. This softwarealsouses the crash modification factors (CMFs) contained in Part D of the HSM to assist with countermeasure selection and economic evaluation. SafetyAnalyst also has the flexibility to allow user-defined CMFs or allow state-specific CMFs to expand or override the CMFs found in the HSM Part D.
Ohio is one of the states leading the way in the integration of SafetyAnalyst into state safety programs. The Ohio Department of Transportation (ODOT) is using SafetyAnalyst to assist with all steps of their safety management system, including: network screening, diagnosis, countermeasure selection, economic appraisal, prioritization, and countermeasure evaluation. To assist with visualization of the screening methods, ODOT is integrating the output data into a geographic information system (GIS) to display and compare the results.
SafetyAnalyst relies on linked crash, traffic volume, and geometric (road, intersection and ramp) databases. ODOT catalogs much of these data for other uses; however, SafetyAnalyst requires using DOT data that must be properly formatted before running the software. ODOT programmers developed tools to automate the data mapping transformation. Following the data transformation, ODOT staff found it very efficient to extract the data from SafetyAnalyst and usea freeware version of DbVisualizer to perform data quality checks. For example, ODOT performed a data quality check using the DbVisualizer software to query the number of roundabouts in the database and compared the results to what SafetyAnalyst reports. The comparison also included the known number of roundabouts on the system.
Much of the ODOT’s data is already maintained in-house; however, they undertook several significant efforts to obtain additional data and improve data quality. The extensive data gathering effort increased output reliability, so that safety funds can be directed to locations where transportation improvements have the greatest potential to reduce severe (fatal and injury) crashes and save lives.
“Ohio DOT is excited about the opportunities that SA provides the highway safety engineering community by allowing the end users to easily perform network screenings and countermeasure evaluations with a high level of statistical rigor.”
Process improvements were implemented to obtain traffic volume and intersection characteristics for local cross streets of state-maintained facilities. Innovative techniques to obtain the data initially included coordinating with the traffic monitoring group to estimate local road volumes where actual counts were unavailable. This was done through use of travel demand models and development of county-specific volumes by functional classification for roads not in the travel demand model. As a long-term solution, ODOT is increasing their count program to collect traffic volumes at an additional 8,400 locations on a 6-year cycle. Other examples of data gathering efforts include cataloging ramp volumes; intersection traffic control; and on-street parking location and type. Much of this data gathering was accomplished using GIS tools, on-line aerial photography or DOT-maintained video logs.
While many people and agencies were noted for their efforts for the successful deployment of SafetyAnalyst, ODOT’s Information Technology (IT) department stood out. Working with IT staff was crucial to ensure hardware and software needs were met in all offices. ODOT IT staff also provided crucial services in developing and testing the tools used to map or transform DOT database information to SafetyAnalyst requirements. Having these in-house tools simplifies the routine update of information into SafetyAnalyst. IT support also included deployment of the software, software maintenance and upgrades, and communications with the software developer while troubleshooting.
ODOT is planning to make SafetyAnalyst available to staff in the Central and District Offices. This will give Districts direct access to the SafetyAnalyst database and analysis tools. Many of the planned efforts also focus on building partnerships with local agencies to ensure the SafetyAnalyst database will have coverage of both state and local roads. This will allow the network screening and project identification processes to be extended to address severe crashes that occur on the local system.
Specific hurdles ODOT overcame during the deployment of SafetyAnalyst include: 1) developing a systematic process to aggregate and integrate all of the required data elements into SafetyAnalyst; 2) addressing the logistics and cost to make the software available in all the District offices; 3) creating a process to address data consistency and use between offices as database updates occur; and 4) meeting the need for more training so District personnel can apply the software correctly and interpret the results. Going forward, expected challenges include data availability and data quality, especially as it relates to extending the program to cover local roads.
As part of the SafetyAnalyst development process, ODOT hosted a 3-day training session for the pooled fund partners. Additionally, ODOT hosted an additional 2-day training session to ensure all of their staff were properly trained. ODOT has also developed module-specific Help Sheets to guide their staff through the software. (NOTE: The Help Sheets are typically generic enough that other agencies may find them useful. For more information about Ohio DOT’s Help Sheets, refer to the Ohio DOT contact.)
ODOT quickly discovered that a big advantage of SafetyAnalyst – in comparison to the previous mainframe process — is the ability to quickly apply the more sophisticated screening methods within the HSM. ODOT is now able to easily analyze locations based on specific site sub-types, and test and compare multiple screening methods.
In Ohio, one of the benefits of applying various HSM screening methods was identifying ways to overcome some of the limitations of existing practices. For example, the previous mainframe methodology typically over-emphasized urban “sites of promise” – locations identified for further investigation and potential countermeasure implementation. These locations were usually in the largest urban areas, often with a high frequency of crashes that were low in severity. Now, several screening methods can be used in the network screening process resulting in greater identification of rural corridors and projects. This identification enables the Ohio’s safety program to address more factors contributing to fatal and injury crashes across the state, instead of being limited to high-crash locations in urban areas, where crashes often result in minor or no injuries.
Jonathan Hughes, P.E.
You will need the Adobe Reader to view the PDFs on this page.
FHWA is introducing the HSM case study series that highlights noteworthy implementation of HSM methodology.
FHWA, in partnership with AASHTO, has established a method for obtaining technical support through www.highwaysafetymanual.org. Once there, practitioners can use the technical support link to post questions either by emailing them to firstname.lastname@example.org or by posting them into the user discussion forum (http://www.hsmforum.org).