Coming Soon: The 'Holy Grail' of Central Station Communications

by Geoff Kohl, editor On Jul 28, 2005

"Chief, we're at 103 Rockhaven Boulevard West and there's no fire."

It's the kind of situation that happens from time to time â€“ miscommunications between public service answering points (PSAPs) and central station staff members can lead to mis-directed emergency responses. While the results aren't often disasterous, it's always been one of those issues that's made the industry scratch its head and wonder, 'What if we could do this all electronically and eliminate the errors?"

Soon, it seems, that will be the case. In what may be one of the most long-awaited offerings for the central station alarm monitoring industry, the alarm data will soon be able to be sent electronically from the central station to the jurisdiction's PSAP thanks to a partnership between the Central Station Alarm Association (CSAA) and the Association of Public-Safety Communications Officials International(APCO).

The electronic transfer of the alarm data, attempted before with programs like the SANTA system which saw limited success, has always been the dream of alarm communications according to Steve Doyle, the executive vice president of the Central Station Alarm Association.

"There's always been a need for this," explains Doyle. "When a central station calls a PSAP, someone has to read the info about the premises and events and the person on the other end has to type this into their system. That can take between 2 and 5 minutes, and it's possible that info may be transposed, that 3rd St. could become 33rd St. The holy grail has always been if they could electronically send this info over just by hitting a button."

And while the technology isn't quite here yet, it's certainly well on its way.

The latest news is that the CSAA and the APCO have jointly agreed to create a standard for these digital communications. According to Ed Bonifas of Illinois' Alarm Detection Systems, the project has been in the works for some time, and now that testing has been done jointly by some companies and PSAPs, this standardized technology (known officially as the "APCO standard for alarm data exchange") isn't too far from hitting the streets. The standard pulls together not only the CSAA and the APCO, but uses the input from software developers GE, Bold, DICE and MicroKey.

The collaboration started when the CSAA was able to get involved with the APCO's Project 36, a project which had as its goal the creation of a standard interface to allow communications between computer-aided dispatch centers (CADs).

"The problem for them was that if a car chase was happening, the dispatch centers would actually have to manually pick up the phone and alert the next city or county to pass along the details because a lot of the communications systems weren't compatible," explains Ed Bonifas, whose company, Alarm Detection Systems Inc., is a full-service dealer/monitoring provider with 25,000 accounts doing $25 million in sales a year.

Bonifas added that the initiative to create a system where PSAPs could communicate freely was the perfect launching point for bringing the alarm industry into the picture as well. And partnering with the APCO project also will mean a higher rate of implementation once the standard is finalized, says Bonifas.

"The challenge on implementation isn't going to be on the alarm industry side since there are only a handful of software companies (such as GE, Bold, DICE, etc.) that have to put this in," says Bonifas.

The challenge, instead, will be at the PSAPs, which aren't profit-driven entities. Some will do it right away, he says, but for other PSAPs, depending on the software and computer hardware systems they use, the implementation time might be longer.

Doyle agrees.

"I know there's going to be tremendous buy-in from the central stations; company owners want to limit liability exposure because of mis-delivered information," says Doyle. "And once the PSAPs realize that APCO is behind it, then the cities will be demanding it."

The standard may make some industry long-timers recollect a time in the 1990s when a similar system was attempted, but was being developed by just one provider. Many business owners reacted negatively to it, thinking it would be expensive and would only ensure that money was going to one pocket. The industry outcry â€“ right or wrong â€“ kept the project, which wasn't developed with public and private sector input, from ever growing legs, explains Doyle.

The implementation of this joint APCO, CSAA standard, however, will be quick in our industry, says Doyle, because the system was not designed to make money for any of the involved parties, but simply to solve a persistent problem in the industry.

"This is one of the things trade associations have to do these days â€“ they have to bring the public and private sectors together," says Doyle. "And that's what we're doing here."

Still, says Pam Petrow, the executive vice president of Vector Security, and a key player in the creation and testing of the standardized interface, the industy shouldn't expect this software out by Christmas 2005, especially since most of the work is on a gratis basis, with software developers donating the time when they are able.

According to Petrow, her company has been involved with testing the interface with PSAPs for the City of Richmond and York County, Va., as well as with CAD vendors and General Electric's Monitoring Automation Systems software. The second part of the test that Vector Security is participating in will move to the software from DICE and MicroKey as well as PSAPs from California and Florida. And a third testing period is planned after that.

The challenge, says Petrow, is getting on board with all the PSAPs to interface with their CAD software.

"There are a lot of established [CAD] vendors, and then there are companies that are producing independent software designs, and then there are even in-house players, IT staff members who are creating software," says Petrow, explaining why the interface isn't an "instant gratification" project.

But if that was the only challenge, the project would have been a piece of cake. Petrow lists the following challenges as areas that the CSAA/APCO interface standard had to overcome, and she says the testing has been vital to this process:

Terminology - The alarm industry uses many alarm event types interchangeably. During a discussion the operator could clarify if a panic was a silent or audible signal and possibly the type of emergency condition it signified. Electronically, we had to define what type of response we wanted for the various signal types - burglary, panic, emergency, duress, hold-up, etc.

Which data elements to pass - All CAD systems are different with different fields available for recording data and these fields have varying lengths. We had to determine what information was critical to communicate and how that data would be passed: number of characters, if the characters could be alpha, numeric or alpha/numeric, if the field was mandatory or optional.

Technology roadblocks - many CAD systems are self-written and the authors don't have the experience to write an interface for their products. We needed to spell out the exact requirements so consistent data could be exchanged from many different parties with different levels of IT sophistication.

How does a PSAP know to accept data from an incoming source - There has to be a way to authenticate the sending party.

Ability to accept or reject transmissions - Depending on the circumstance a PSAP may decide they are not accepting an alarm transmission (may be the wrong PD, wrong emergency agency police vs. fire vs. EMS, storms, etc) so a protocol for rejecting a transmission had to be established.

IT security issues

Street nomenclature - Different databases use different abbreviations and data entry protocols for addresses which could lead to rejections if not compatible.

Even with this heavy list of challenges that must be surmounted to create a shared standard, the rough spots in the technology are being smoothed over, and the process is moving forward.

"Our goal is to have testing done at the end of the year and then move on to the registration server [an online database of sorts that would be part of the authentication process and would tell station's which PSAPs are on board with the new standards, and tell PSAPs which stations are up to speed as well]," explains Petrow. "We hope to have the interface standard set up by mid to late 2006, but for now, we're just thrilled have it working."