The City of Seattle is known for its lush scenery and a cityscape bisected by several waterways. Bridges are often the primary lifelines connecting different parts of the city. In an emergency, it is critical these lifelines are available to first responders.
A few years ago, the Seattle Department of Transportation (SDOT) began making the status of all the movable bridges in Seattle available to the public via a map that updated in real time. Management at the Seattle Fire Department (SFD) 911 Fire Alarm Center approached SFD IT professionals to see if bridge status could somehow be imported into the computer aided dispatch system (CAD). This would give dispatchers better visibility into the status of roadways, so they could make unit recommendations based current conditions and the quickest route.
From curiosity to crisis
The West Seattle Freeway serves as the primary connection between West Seattle and the rest of the city. While inspecting the freeway in March of 2020, SDOT discovered the expansion of several cracks which resulted in a decision to shut the freeway down completely for safety reasons.
This scenario presented a major challenge for the fire department. With that route now closed off, the only way to efficiently get to West Seattle from the downtown area was the swing bridge located beneath it, which closed frequently throughout the day to let passing ships through. If the swing bridge was not accessible, responding fire vehicles would have to use another bridge further away, adding about 12 minutes to our route. We needed to make sure we were recommending the correct units based on the state of the swing bridge. The goal of transferring bridge data into the CAD went from being a technical and professional curiosity to being critical in the course of a week.
Collaboration comes to life
The original discussions with SDOT about their real-time bridge map revealed that they had written their own API (application programming interface) to show the status of the bridges and were happy to give that data to other city departments. The question remained, how to interface SDOT’s data with the fire department’s CAD system?
Seattle Fire currently uses CentralSquare CAD that has its own API known as Raptor, but we didn’t have a lot of experience using it. After a chance encounter with someone who had heard about the Raptor API, we were introduced to our counterparts at San Diego Fire-Rescue. When we connected with San Diego, we discovered that they had experienced some of the same challenges eighteen months earlier with a similar project. They had gone down the same path of needing to interface with data from different systems and better yet, they had already found a solution.
Sometimes the hardest part of a new initiative is knowing where to begin. Fortunately for us, San Diego generously shared how they solved those problems using the Raptor API. A slight push in the right direction was all we needed. Within three weeks of reaching out to San Diego, we implemented our first test version of the SDOT-CAD Bridge Monitor.
How tech helped solve the problem
The Bridge Monitor is middleware that looks for changes in bridge status from SDOT’s API, and then uses the CAD Raptor API to create a temporary road impedance within the CAD street network at the location of the bridge that just opened. When the impedance is active, CAD recognizes the route is no longer available and will not recommend units that normally would use the bridge. The road impedance also presents itself with a visual indicator on the CAD map, as well as providing an advisor alert that shows up in the CAD status bar.
Additionally, to make sure the data was consistent and that we were making accurate, data-driven decisions, we created test incidents in our test CAD environment to compare response times from various locations if the bridge was either up or down. We saw significant differences in which units were recommended and how long it would take a unit from downtown to travel all the way around the south end and into West Seattle. Those results from the test simulations eventually led to the department staffing West Seattle with additional units.
Possibilities and implications for the future
This effort enabled us to better serve our community. Consider if there was a large fire in West Seattle or a major medical response, such as a mass casualty incident, and all the units in West Seattle were exhausted. Without the ability to monitor the status of the bridge, CAD would see the bridge as usable and consider that route as available. From our simulations, it was clear that CAD would recommend the next available, closest units from downtown Seattle if a West Seattle unit was not available.
However, if the CAD system knows that the bridge is unavailable, it will recommend units in the south end of downtown. This cuts approximately 12 minutes of response time for the fire department. In any emergency, that can make a life-changing difference. It’s completely automatic and allows the dispatcher to concentrate on managing the incident.
Future plans include monitoring all the bridges instead of just the swing bridge. SDOT is also planning on making an API available to monitor the status of railroad crossings.
What can other agencies learn?
Collaborating with other agencies is critical. When faced with a new challenge, it’s easy to believe that you’re on your own and have to figure it out yourself; but you don’t. It’s very likely that other agencies have already gone through similar, if not identical problems, and can help your agency. By reaching out for assistance, your agency can save weeks, if not months of time.
My hope moving forward is that through a collaborative effort, agencies can develop a resource-sharing community to help solve common problems we all face. If anything, agencies will be able to participate and collaborate on getting answers to even the most basic question, “How do I even get started?”
Author Bio: Dan Whipple is the 911 CAD Administrator for the City of Seattle and is part of the Seattle IT Public Safety Applications Team.