jimcarter

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 19th 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.

Last week I was involved in a product refresh with the senior engineers of one of our UK National security companies. We covered off our new SPT.6 hardware in both its “Pro” and “Mini” versions which was all very nice, but it was the 3G capability of the new devices that drew much attention and I thought it would be useful to share some of the topics we covered. When you are in the business of data communications you have to constantly revisit and re-evaluate the old technologies, how they compare with the new and what operational differences there may be. Looking back on my piece written around radio installations I realise that some of what I wrote at the time (3 years ago) may not be relevant to today! What is apparent is that the wireless data network is improving with the release of 3G and 4G. Incidentally I saw a development 5G device on the BBC news website last week, its worth looking up. I am not about to go as far as saying that wireless will take over from broadband anytime soon, it will be quite a few years before mobile communications will mirror the last mile resilience and data speeds of a fixed line circuit. But from what I have seen, 3G is enough to consider radio only communications favourably for critical data transmission where circumstances require it and with a potential to reduce reporting times below what we would consider a 2G device capable of. Let us take a look at some basic comparisons between 2G & 3G. The switch from analogue GSM services to digital took place in the 90’s or in generation terms, from 1G to 2G. 2G was designed as a voice service with a basic data transmission capability, primarily for text and very limited Internet connectivity. Bandwidth is low but suited to applications where the packet data is small, such as a poll or alarm message in an alarm transmission system. However error correction is quite poor and inefficient and it is often necessary for devices to resend and validate data that has not been correctly received. This can lead to extended download times or a “timeout” to occur where the devices can no longer continue to communicate in the same “session”. This means the communication process has to begin again. 2G requires the last mile (between the base station and the module) to be stable, reliable and have a very good quality of service. 3G differs in that the service has been constructed around mobile data operations as well as voice. It came into its own when the rise in smart phone demand exploded. It is a protocol that has vastly improved error correction (less retries and “timeouts”), improved building penetration and at least double the download speeds. Resilience is improved too; a fall back to Edge (2.5G; or the stop-gap between 2G & 3G) and GPRS when 3G is not available maintains data connectivity. In operation, 3G (so my Development team tell me) is like DAB radio in that if you have a “signal” (literally any signal) it will work, where as 2G is more akin to Long Wave radio where signal and direction are required to obtain service. Translate this into a Security application and we find that our usual indicators are not entirely valid. For example signal strength has been used as a guide to 2G service availability (although not an entirely reliable one). On a scale of 1 to 10, anything indicating 3 or below could suggest a potential problem. In 3G terms, signal strength is meaningless. If the module has a good connection it will work as long as that connection is “up” regardless of signal, whether it be a 1 or a 10. How do we survey a site of this is the case? It can be argued that a survey is obsolete in its own right as the device has an ability to intelligently roam between service providers and incorporates a secondary roaming feature that can hop between technologies and frequencies (which makes jamming almost impossible by the way). But there are tools we can utilise and what is even better they are free! The network providers publish coverage maps on their websites. Some include service availability notifications as well. Or there are Apps that you can download to your Smartphone such as “Open Signal”. This App uses data gathered from its users to populate a service coverage map based on actual availability data as opposed to what the operators would like you to believe. It constantly updates, shows local serving cells and the more users there are the better the data mapping becomes. Building a next generation mobile data module into a security product has several challenges. Cost is the leading factor. New generations of devices carry a premium and it has only just become viable for WebWayOne to incorporate a 3G module as standard and retain a competitively priced SPT. Migrating to 4G will come but it will be the module price that determines when this will be. Next are the changes in software. You cannot simply bolt a 3G module onto a piece of hardware and expect it to work. The Development team have to “tame the beast”, working with the modules design teams; not only to make it work, but to maximise the features that the module can support, for example the ability for the module to manage the SIM cards connectivity to the network. Operationally the results are quite staggering. 3G coverage is excellent and the download speeds for a 650K file are 25 minutes on 2G compared to 6 to 8 minutes over 3G. Let me provide you with some hard information. I have two test SPTs at home, both are operating in radio only mode, both are configured for a 3-minute reporting time, have the same software and a Telefonica Roaming SIM card installed. I can share with you the comparison over the past month of testing that is revealing. My home is a particularly good testing ground as I live in a rural part of Berkshire with very poor radio reception and just two providers available, O2 & Vodafone. Below is the diagnostics I can retrieve from the SPT showing 3G operation on a 900 frequency band with a signal strength of just 2. And here are the comparisons in signal strength over the past month (scale 0 to 10 where 10 is the maximum signal). You will see they are very low, generally below 3. 3G Signal 2G Signal The 2G device is obviously struggling to maintain a connection and since the 22nd November it has lost registration to the core network to all services, whereas the 3G device has been online all of the time. This is reflected in the circuit availability. 2G network availability for the month is 81% 3G network availability is 99.79% When you translate the availability figures into the number of failures that would have been reported to the end user the scale of the difference is aparent. The 3G device would have reported just 3 fails (of which 2 of these were during tests I carried out with the device), compared to 385 fails from the 2G device. I would not advocate rushing out and installing 3G only with 3 minute reporting times or consider replacing broadband devices with radio only. But certainly where longer reporting times are concerned and a landline is not available or impractical then the stability figures we are seeing gives confidence. Coupled with a fixed line circuit, especially Broadband provides an incredibly robust solution. Looking to the future, the speeds that are being achieved and the reliability of the circuits demonstrate that high bandwidth applications can access the 3G to. Where Imaging or CCTV is concerned the speed in which you can transmit images to an operator is critical and therfore 3G is a viable backup path to broadband. So to conclude. 3G:- Supports faster Upload/Download speeds - future applications such as Imaging and CCTV have access to a viable backup network Has better building penetration Signal strength is not as operationally critical Will automatically drop to Edge or 2G if a 3G service is unavailable Frequency hopping renders jamming almost impossible Global SIM cards provide additional resilience in network roaming Additional software controls on the module allow for intelligent roaming (as opposed to letting the SIM card and network operators determine connectivity) Network coverage is excellent, before the ability to roam providers comes into the equation But remember; it is the GSM module and not the SIM that determines what technology can be accessed.