The long awaited Message Broker server managed by the Central Station Alarm Association (CSAA) has become operational in the production environment. The City of Richmond (Va.) Police Department’s Division of Emergency Communications and Vector Security, two of the three original Automated Secure Alarm Protocol (ASAP) pilot participants, migrated to the CSAA Message Broker officially at 1 p.m. Eastern time on Monday, April 16. Dozens of law enforcement, fire and emergency medical alarm notifications and subsequent update messages have been initiated between the two entities seamlessly and without incident.

As mentioned in an earlier article about the ASAP project (PSC eNews March 2, 2012: “ASAP to PSAP: Alarm Monitoring Companies Lining Up”), the Message Broker is a combination of hardware and software intended to perform a middleware function between Nlets and the alarm monitoring companies that want to take advantage of ASAP. The Message Broker performs error checking and ensures that the transmissions from the alarm monitoring companies are properly formatted before sending the message to Nlets for subsequent forwarding to the appropriate state control point and ASAP-participating PSAP. Conceivably, 75–150 alarm monitoring companies (including ADT) could become operational with the ASAP program over the course of the next few months. Hundreds more are likely to sign up over the next two to five years.

Migration to the Message Broker is transparent for Richmond PSAP staff: The move to production for Richmond 9-1-1 staff was seamless and uneventful. No training for dispatch staff was necessary because the alarm notifications continued to appear on the CAD event screen as a new call for service—exactly as they always had before the implementation of the Message Broker. The only notification that the 9-1-1 staff received about the migration was the appropriate Change Control notices which are strictly enforced by Richmond’s Department of Information Technology to make users aware of impending changes to the city’s production systems.

This success was the result of careful planning by Richmond IT staff and the specification given to Intergraph, Richmond CAD’s provider. Intergraph was tasked with upgrading Richmond’s ASAP interface from the 3.1 schema to the newest 3.3 schema, which is required by the Message Broker. The one caveat was making sure that Richmond’s interface was backward compatible with the 3.1 schema. Two alarm-monitoring companies will still deliver alarm notifications to Richmond based on the 3.1 schema until those alarm-monitoring companies are upgraded to the 3.3 schema by their automation provider and, ultimately, migrate to the Message Broker. Until then, Richmond must be able to receive alarm notifications based on either version of the schema, but only on one server. By taking the extra time to carefully plan and test backward schema compatibility, Richmond was spared time, effort and additional costs by not having to create multiple production interfaces and hardware environments. The word about this success has spread to other CAD providers who have a 3.1 ASAP solution in place or are currently developing an ASAP solution.

Alarm monitoring automation providers have a little more work to do: Compared to the dozen or so tier 1, 50-plus tier 2, and hundreds of smaller CAD providers, most alarm monitoring companies use an automation product from one of the half-dozen major automation providers. Vector Security’s automation provider, UTC Fire & Security, upgraded the software application used by Vector Security to the latest schema. The new schema provides additional data fields that will be crucial for alarm confirmation notices to PSAPs, but more importantly provides the fields required by the Message Broker. Further, the message “wrappers” must be changed slightly to transact with the Message Broker instead of Nlets. All of the alarm-monitoring company automation providers have the same ASAP 3.3 specification and are actively developing their solution. The happy ending, as with any American National Standard, is to develop the product once and deploy it many times.

A very small change for Central Station operators: According to Anita Ostrowski, Vector Security’s vice president for Central Stations, the alarm operators at Vector Security received very brief, informal training that was required when Vector migrated to the production Message Broker. No formal training or in-depth training program was required for Vector’s migration. Keeping in mind that Vector’s operators are now triggering alarm notifications to multiple PSAPs that participate in the ASAP program, there are distinct commands to send an update message to a PSAP, depending on whether the message is routed across the traditional Nlets path or via the Message Broker. Eventually, by late summer, all ASAP traffic will be routed through the Message Broker and the need to have distinct commands to send update messages depending on how a PSAP uses ASAP will become unnecessary.

About the Author
Bill Hobgood is a project manager for the city of Richmond’s DIT Public Safety Team and has 40 years of experience in public safety. He is also a project coordinator for APCO’s Comm Center & 9-1-1 Services Department and a subject matter expert on the ASAP project. Contact Bill via e-mail at [email protected].