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.

Thanks James. Where 3G is available (pretty much everywhere) the results are very good. I'm putting together another piece based on 3G which I'll post in the next week or so.

Interesting that the Risco cloud service was disrupted by a problem with the Microsoft Azure cloud service and so I thought this would be an opportunity to describe what we as Alarm Transmission Service providers (ATSP) “do” and how we got here. An ATSP is not just about providing a piece of hardware that attaches a fire or intruder system to a network. It’s also the receiving equipment at the ARC, redundancy and resilience of that equipment, the provision of suitable SIM cards for radio network coverage, technical support for engineers in the field and for the ARC operation, disaster recovery when networks fail and continued development of systems and processes to cope with network evolution and new services. WebWayOne began trading as a designer and manufacturer of data communications equipment in 2000, before the company evolved into an ATSP and right now I think I can be bold enough to say it’s in the top 3 in the UK in terms of connections as we approach 50,000 in number. Of those top 3, we are the only one to have our own hardware and software development team and retain all manufacturing within the UK. Our core team came from a company called Controlware. A UK subsidiary of a German firm that the team ran from the early 90’s through to 1999 when we sold our share back to the parent company. But we kept the UK development group who were designing ISDN based communications equipment, which included a terminal adapter called a “WebWay”. In those days the Internet and World Wide Web was in its infancy and the only way to get on it was to use dial-up technology. Dual path transmission was nothing new to us as at Controlware. Through the 90’s we had been providing leased line backup services for blue chip Finance and Network providers to ensure their data networks kept running and we practised remote maintenance and diagnostics on this equipment to. So it was quite a shock when we realised that the Fire and Security Industry did little of either and was clinging onto out dated data communications using PSTN and modems. It was quite an achievement for our small team to win the contract to supply the National Lottery with ISDN terminal adapters for 30,000 lottery machines and the management platform to maintain the operational system. We also supplied Vision Systems (now Xtralis) with ISDN TAs for Adpro Fast Scan, VU and Trace products before broadband became widely available. BT RedCARE was “the brand” at the time and we incorporated the AIMs protocol into our ISDN terminal adapters and became the largest supplier of ISDN equipment to RedCARE. But then, as now, we were looking to the future and we could see that Broadband and radio services would become the norm and we set about building an “IP” based ATS. RedCARE were not interested, wishing to stick with PSTN and cast doubt over the reliability of Broadband whilst the BT parent was selling and promoting the service to Businesses and you and I alike. We were flabbergasted, but we decided it was time to go our own way. 2005 saw the first major roll out of an IP based ATS when we delivered a system to Dixons. It is still in place today. As for today we have 30 employees covering Product & Software Development, Production, Sales & Marketing and Technical Support. We have operations in Scandinavia, Europe and recently Australia. Looking after these systems is a huge responsibility and building in redundancy and resilience to cope with the type of system failure that Risco experienced is just part of the day job. As is providing a level of technical excellence and expertise that takes problem ownership away from the on site engineer. Our support team are 7 in total and they have to understand not only the way our hardware operates, but also how it interacts with 3rd party equipment that we have integrated into the ATS. So that means documenting and learning the programming and troubleshooting of our partners’ equipment. Identifying trends in network behaviour through support often leads to discussions with the network providers. In providing a SIM card with a device that supports radio is not just about cost or service availability. It’s also about support and operational considerations. WebWay have in excess of 40,000 SIM cards in operation with Telefonica. That gives us huge experience and breadth of knowledge in how the radio network operates and is evolving. More importantly it means we are engaged at a very high technical level that has (in the past) lead to us identifying problems with network delivery that Telefonica have taken note of and fixed. They have reciprocated in providing us advice and guidance when we are developing software that maximises the use of the roaming capabilities of their SIMs whilst not disrupting the network or causing problems elsewhere. Having our own developers is a huge asset. It means we can react very quickly to add in new features to the product range in both hardware and software terms. We were the first to roll out large IP/Radio based ATS services, the first to introduce integrated remote diagnostics and UDL support over the ATS and we have become the first to deliver 3G as a standard service for the radio path. But we don’t stop there and the exciting thing about having a development team is to turn ideas into reality and then deploy and see them in operation. From an Operational perspective I am certainly proud of the fact that we are a privately owned UK company that is able to manufacture technically advanced telecommunications equipment at home in the UK and at competitive prices. I do not foresee this situation changing any time soon. So being an ATS provider is not simply about making a printed circuit board that fits into an Intruder or Fire panel, that’s just one small part of the equation. It’s about service delivery from the protected premises right to the ARC. Future proofing our systems through strong development and innovation keep us ahead of the competition whilst ensuring that operational systems are robust and ready to cope with the worst that can be thrown at them, and then recover gracefully. I almost forgot adhering to Standards, but that’s another story.