If you have been in data communications as long as I have you will know that remote diagnostics and maintenance are nothing new. I remember back in 1992 watching in awe as our technical director (Phil Meredith) was stood next to some ISDN Back-up kit hooked up to a monitor running a windows application.

On the screen, a cursor flicked over the menus and it was obvious somehow the system was being configured. “How are you doing that Phil?” I asked.

“I’m not, its one of the support guys in Germany”.

A more extreme example of remote maintenance occurred on the 19^th December 2014. BBC news reported that International Space Station Commander Barry Wilmore was in need of a ratchet socket wrench. “Made in Space” is the company who supplied a 3D printer that is installed in the ISS. They heard about this and set about drawing up a solution on their CAD machine. They emailed the drawings up to the ISS and Commander Wilmore duly printed out a useable wrench!

Upload; Download. A phrase that is used in our industry to describe the remote connectivity and programming of an alarm panel; comprised of a remote signalling device connected to a data network and software loaded onto the users PC that manages the panel configuration.

All sounds pretty simple but more complex in communication terms, especially when using low bandwidth data networks such as dial-up PSTN or 2G/GPRS. Indeed its not just the communications networks that are the problem. For the designer of a signalling device there are many challenges, especially where hardware is concerned.

The vast majority of installed panels have a PSTN dialler capability and this has been seized as an opportunity to use what is commonly termed “Dialler or Modem Capture”. In this method the communicator will have an interface that emulates a telephone line, presenting dial tone and line voltage.

The panel modem “thinks” it is connected to a telephone line. The interface will “capture” any transmission from the panels modem and convert it to a digital signal and transmit over the alternate network. This is usually an IP connection over radio or Broadband.

Whilst quite “neat” it is a technique that is suited to older panels that do not support a data interface. However there are a number of problems to overcome when designing a dial capture interface.

Alarms & UDL Combined

Panels that utilise a PSTN modem for communication cannot transmit alarms whilst a UDL connection is in session. So there needs to be a mechanism where the panel will “tear down” the UDL session if there is an alarm to transmit. This will take time and may add a delay in transmission time that puts the solution outside the ATS delivery requirements.

Transmission time

Modems have to “train” with their counterpart modem at the far end of the connection in order to transmit data. This can take a number of seconds and there is an inherent delay before the SPT has processed the alarm through the DCM mechanism and prepared it for transmission. This time delay could also fall outside of the permissible alarm transmission times associated with high-end security ATS requirements.

Alarm Acknowledgement

The panel has an alarm to send. It dials via its modem and the SPT picks up the alarm through the Dial Capture mechanism. The SPT will even acknowledge that it has the alarm, so as far as the panel is concerned alarm delivery has been successful.

However the alarm is still with the SPT. What if the SPT cannot send the alarm because one or more of its circuits are down? How does the SPT tell the panel that the alarm has not gone anywhere?

In ATS terms, if all routes to the ARC are down, they should know about it when the reporting time has been reached. You can use clever mechanisms like removing dial tone or line voltage from the DCM, but how quickly should this be actioned by the SPT and how should it report to the panel?

Technology

Modem design has evolved over many years and is generally handled in “soft modems” these days. Indeed the hardware components are becoming increasingly scarce and in danger of obsolescence, which in turn increases the cost of manufacture.

The range of protocols both standard and bespoke in modem communication design is vast. The Dial Capture Interface has to mimic a “local exchange” and support a compatible “receiving” capability. The sending of alarms is not too difficult to achieve but UDL is a completely different matter. If you end up with an incompatibility between the sending and receiving modem, the solution simply won’t work.

Over the years Alarm Panel manufacturers have developed their own transmission protocols in order to provide security and an ability to communicate with their own maintenance software. This means when transmitting data in a UDL session the developer will need to have obtained, understood and enabled the communicator to identify these different protocols in order to utilise them. This is not a simple exercise.

The real difficulty is coping with all these variants, because if you want a truly generic modem capture that covers all panels then your communicator will have to accommodate a vast library of protocols. This requires memory, and lots of it, as well as processing speed. If you don’t have these in your SPT, then you will end up producing individual comms devices for individual panel manufacturers.

Serial Data Connection

A Serial data interface to the panel is my preffered solution. However the designer of the communicator must include a number of hardware interfaces (the most common being; RS485, RS232 and TTL a derivative of RS232) as well as understanding the individual panel protocols.

One would expect the speed to increase in a UDL session but this is not always the case. Where panels have changed little in their communication techniques over the years we find data buses that still run at archaic speeds. For example our SPT will run up to 115k in the serial bus, but invariably the panel bus is as slow as 9600.

It is worth noting that some panels suffer from the same inability (as PSTN) to transmit alarms when a UDL session is running when connected to the serial data bus and it is advisable to check whether this is the case.

Once the integration with a panel is complete one may expect that’s “job done”, onto the next. But that is not the case. Collaboration with the panel manufacturer at the development level is crucial. If either party updates the production software of their device there should be a period when the solutions are tested before release. In reality there are many instances where this may not happen and incompatibilities creep in. Managing these is complex and the development team has to be right on the button to deal with any problems, quickly.

From my point of view, being able to support both Dial Capture and a Serial bus connectivity should be standard for any SPT. Wherever possible the Serial connection to the panel has to be favoured over dial capture as it is more elegant but less complex and overall more reliable for our critical data applications. Dial Capture will not go away anytime soon but it could be argued that if the panel only supports PSTN, then it may well not be compliant and needs replacing anyway.