Computer-Aided Dispatch Trends That Should Be on Your Radar — Part 2

A previous blog explored several short-term trends regarding computer-aided dispatch (CAD) of which emergency communications officials should be aware. These include:

• The rapid evolution of CAD mapping
• The increasing momentum of CAD interoperability
• The improved integration of CAD systems with law enforcement RMS and other data platforms

This blog explores a longer-term trend that is equally compelling.

Browser-based CAD systems — In the past, CAD functionality required a piece of software, known as a client, to be loaded onto every workstation in an emergency communications center (ECC). Today, this functionality increasingly can be achieved via a web-based browser. The host software, often referred to as a tenant, is installed on a server that is housed in the ECC’s equipment room or in the cloud. Any authorized workstation or user can log into the CAD system via a web browser and leverage all of the functionality that the browser-based application offers.

There are numerous advantages to this approach. A big one is that 911 telecommunicators can be just about anywhere that internet connections are available and still perform their jobs. Let’s say that a wildfire is bearing down on an ECC, and officials have decided to move personnel to another center that is not in harm’s way. Telecommunicators could carry laptops with them, plug into the other center’s network upon arrival, and with a few keystrokes be logged into their center’s CAD system as if they never left. They would have full system functionality, including their individual screen layouts — something that is vitally important to every telecommunicator. Similarly, field personnel — law enforcement, fire/rescue, and emergency medical personnel — could leverage a mobile data capability, the sister product of CAD, from both Windows and non-Windows tablet computers, provided that they have a web browser that provides access.

Another example of this utility was found during the COVID-19 pandemic, when we learned of several ECCs that allowed telecommunicators to work from home out of necessity, partly due to shelter-in-place orders. A browser-based CAD system makes it easier to implement such a strategy, provided that telecommunicators have access to incoming 911 or ten-digit calls, or for remote dispatch — the more likely scenario — they can dispatch resources using a portable radio.

Another advantage is more pedestrian, but it is just as big. In the traditional model, software updates often need to be deployed to remote client workstations from a server or, for larger version upgrades, a technician may have to touch every workstation. This is problematic because upgrades thus require considerable management time to ensure that updates have been delivered successfully and to troubleshoot when they fail. For a regional 911 authority the problem is compounded because it might have many centers spread over a large geographic area, with an even greater number of mobile data clients on mobile computers in the field. This problem goes away with the browser-based model. The update is applied to the application hosted on the server, and then the browser, when logging into the application, has immediate access to the update and any new functionality. Browser-based applications provide a distinct level of efficiency and upgradeability that is not enjoyed by their client-server counterparts.

This is analogous to the evolution that occurred with email. In the beginning, the software that enabled a person to access their email existed solely on their desktop computer. If they went to a friend’s house, they lost their ability to send and receive emails. That all changed when service providers moved to the browser-based approach, which is a big reason for why email today is accessible anytime, anywhere, and on any device.

In short, browser-based CAD systems give public safety agencies and their personnel flexibility, portability, and ubiquity that is incredibly valuable.

Despite the benefits, challenges exist for browser-based CAD systems in this stage of their evolution. As a result, many ECC practitioners believe that they’re not quite ready for prime time, which is why this is a longer-term trend that bears close monitoring. Right now, browser-based systems cannot provide the robust feature set provided by traditional, client-server CAD systems. Here’s an example. Most fire departments rely on static run cards that are loaded into their CAD systems. These run cards automatically designate the companies and apparatus that should be dispatched to an incident based on the number of alarms. That’s vital information that incident commanders need at their fingertips — some departments want to know the next 10, 20, even 40 companies that would be sent to a huge warehouse fire. But so far browser-based systems have been unable to deliver this level of detail or imbedded functionality.

The reader might think that an automatic vehicle location (AVL) solution coupled with a browser-based CAD system might be an adequate work around — it isn’t. Knowing where the closest available unit is located at any given moment only tells half the story — an incident commander also needs to know that the unit has the proper equipment and personnel for the incident. Let’s say that it’s a structure fire involving an office building — if the closest available unit doesn’t have a 50-foot ladder, it won’t be of much help. Dispatching fire/rescue resources can be quite complicated, and the department’s CAD system needs to be up to the task.

Also, the geographic information system (GIS)-based mapping capability of the current iteration of browser-based CAD systems is lacking compared with traditional systems. Let’s consider a 911 call that reports an incident that requires swift-water rescue of a kayaker who is struggling on a river. Telecommunicators and incident commanders need to know the location of every boat ramp, so that response resources can be placed into the water at the point nearest to the victim. This is not a layer that is leveraged every day, but when it is needed, it needs to be called up immediately. What about a shooting that occurs on a hiking trail in a state park? This is a serious event that requires rapid response — and that response depends on the ability of telecommunicators to call up mapping layer that shows the location of every hiking trail. If you can’t see them on the map, emergency response becomes a lot more challenging.

Here’s yet another example. Fire departments need a mapping layer that not only shows the location of hydrants, but also their status, updated continually by the municipal water department. Rolling up to a structure fire where a hydrant is dry is not ideal, but it can be dealt with by incident commanders — provided that they are aware of the hydrant’s status.

Again, the depth of information described in these examples, as well as the robust portfolio of interfaces to other systems that client-server systems offer, isn’t routinely provided by browser-based CAD systems today. However, we have learned to never bet against technology developers. Eventually, this sort of robustness will be provided by browser-based CAD systems — it’s just a matter of time. So, stay tuned.

We would love to work with you to map out the evolution of your agency’s CAD environment, in particular how and when you should take advantage of this long-term trend and the three short-term trends described in our previous blog. Please reach out.

Bob Scott is MCP’s automated systems domain lead. Email him at BobScott@MissionCriticalPartners.com.