ÐÇ¿Õ´«Ã½

To the industry – or 'officialdom' – the moniker 'Alarm Receiving Centre' (or ARC for short) has become the recognised statutory term for any facility where intruder alarm connections are monitored and a response co-ordinated. The same abbreviation is also used for fire. An ARC might also be the term applied to describe a facility where video is monitored (ie images are relayed from designated CCTV-based installations), although of late a variety of other sobriquets – including remote video surveillance – have appeared on the scene.

The ARC of today, then, is easily understood in both the fire and security sectors. It has a function. A place. An irrefutable underpinning logic. However, a pattern is steadily beginning to emerge that might well disrupt the ordered world of the ARC as we know it. It's not so much a paradigm shift, but rather a gradual change in need. The need for end users to be able to monitor many different kinds of data, whether it emanates from intruder alarms, CCTV cameras, refrigeration plant, heating, ventilating and air conditioning (HVAC) units or a building management system (bms).

The ordered world of separate monitoring facilities for separate industries, where security, fire and bms are kept apart like squabbling children, might soon be blown away for the sham that it has undoubtedly become. An ARC would then be a very different beast from that which we know and love, instead providing a bureau or suite of end user services encompassing everything from security through to major environmental and process control functions.

The key that's steadily unlocking the potential for the ARC of the future is the idea that every disparate protocol can be interpreted by a common software and given common language, such that the maker's name on the product at either end of the communication process becomes an irrelevance.

To understand this point further perhaps requires an examination of the most common protocols currently in use, and a retrospective on how the present situation has arisen.

Data communication protocols
A data communication protocol is effectively a set of rules governing the exchange of data over a computer network. The rules take the form of a written specification that spells out what's required to conform to the protocol.

For example, let's take a look at BACnet (one of the most common protocols used in the building services arena). The rules here cover everything from what kind of cable to use to how to form a particular request or command in a standard way. As implied, what makes BACnet special is that the rules relate specifically to the needs of building automation and control equipment (ie they cover elements such as how to ask for the value of a temperature, define a fan operating schedule or send a pump status alarm).

BACnet provides a standard way of representing the functions of any device, as long as it has these functions. Typical examples would be analogue and digital inputs and outputs, schedules, control loops and alarms. This model of a device represents these common functions as collections of related information called 'objects' (each of which has a set of properties that describe it still further).

Each analogue input, for instance, is represented by a BACnet 'analogue input object' which has a set of standard properties like present value, sensor type, location, alarm limits and so on. Certain of these properties are required while others are optional. One of the object's most important properties is its 'identifier', a numerical name that allows BACnet to access it in an unambiguous way.

BACnet's object-oriented model and the various services or message types are relatively easy to comprehend. However, the end user would still need to choose an appropriate network technology that will eventually connect everything together. The list of potential candidates can be reduced to perhaps five different options, each of which fills a particular niche in terms of the price versus performance trade-off that's of particular concern to most security managers.

Network technologies explained
The first of the network technologies is Ethernet, the fastest operating at 10 Mbps (millions of bits per second) with 100 Mbps also available. Ethernet is also likely to be the most expensive choice in terms of cost per device.

Next comes ARCnet, at 2.5 Mbps. Both Ethernet and ARCnet can use a variety of physical media (including fibre optic cable, standard coaxial cable and twisted pair). Echelon's well-known LonTalk network may also be deployed on various media.

All three of these variations are examples of local area networks (LANs).

A key point to stress here is the fact that BACnet messages can – at least in principle – be transported by any network technology if and when it becomes cost-effective to do so. Again, this is all still relatively straightforward to comprehend. Alas, it's also the point at which the story becomes slightly more complicated...

BACnet, for example, can use LonTalk. However, this doesn't mean that any equipment using LonTalk can automatically 'speak' to BACnet systems. LonTalk is the Echelon Corporation's specification for a LAN technology that some thought would be a useful addition to the BACnet standard. BACnet uses LonTalk to convey BACnet messages in an identical manner to the way in which BACnet messages are themselves transmitted by way of Ethernet and ARCnet, etc.

Confusion stems mainly from the fact that Echelon enjoys its own generic control language which is also transported by LonTalk. In order for LonTalk devices to be interoperable, even using Echelon's language, there has to be agreement between implementers as to what the generic messages mean in a particular context. The point is that the BACnet language and the Echelon language are fundamentally different. Devices using one of the languages can never hope to inter-operate directly with those using the other, even though they might possibly share a common LonTalk LAN.

For nearly a decade now the building management sector has been trying – with mixed success – to promote common protocols, primarily with a view to creating an integration-rich market. However, the facts are such that the conventional supply of bms is changing. Packaged plant with Internet Protocol (IP) technology is becoming ever more viable and cost-effective (when procured correctly, that is).

Packaged control systems are generally supplied with proprietary protocols and individual control strategies. These control systems are very often provided by the OEM at low or even no cost. Traditionally, the bms contractor would then overlay a further layer of controls technology, complete with extra installation, engineering and commissioning, duplicating the cost to carry out the interface.

The ordered world of separate monitoring facilities for separate industries, where security, fire and bms are kept apart like squabbling children might soon be blown away for the sham that it has undoubtedly become

If we then apply this philosophy on a far wider scale within a building environment, the additional costs can escalate at an alarming rate. Most building services applications comprise many different intelligent control systems – building management, lighting, fire, access control, CCTV, power management (LV/HV), etc – all of which rarely interact with one another (with the exception of the odd hard-wired interlock). However, these systems have been installed at significant cost with overlapping technologies, spare capacity, their own independent network and head-end.

The opportunity exists to maximise the systems interaction and operation while minimising the capital outlay by eradicating the duplication of project management, labour and resource, product overlap, infrastructure and networking and proprietary head-ends. In doing so the end user may replace these multi-proprietary head-ends with a single web server.

Connect the web server to your site Intranet and you can now use any web browser to view and modify any of the control systems. Connect it to the Internet and you have the ability to carry out full remote diagnostics, monitoring, control and alarm reporting. Such a method represents an attractive proposition to end users looking for a completely integrated yet cost-effective facilities solution.

It's no surprise that many bms manufacturers are now fearful of the growth in packaged controls and web technologies.

Total Facilities Management
Recently, packaged plant has overtaken the supply and installation of separate plant and engineered building services solutions with HVAC equipment such as air handling units, boilers and chillers being delivered to site with complex control systems already on board.

By the same token, the development of intelligent fire protection systems, lighting controls, elevators, smoke and access control solutions has continued apace, nearly all of them starting to provide a communications interface through which information is made available for the total monitoring and control of the system by end users. This fact alone has impacted upon the way in which the communications and management infrastructures for all the technology systems in a corporate building are being designed.

The concept of Total Facilities Management (TFM) offers a truly integrated technology of its own, one which has been designed from the outset to allow the management and optimisation of all microprocessor-based systems installed in a building by the use of a manufacturer's communications interface.

In a nutshell, TFM puts the bms back to its original use as a controller of HVAC installations, at the same time bringing the benefits of all building systems (including HVAC controls and security systems) together on one operating platform.

TFM offers a number of benefits for the security and facilities manager, as well as the building owner. In terms of a management perspective, there's a single point of entry to the complete network of building systems (including all the various disciplines). This allows for the command and control of all systems through a common user interface, making use of modern IT infrastructures to allow interaction with building systems from any location.

There is also now an opportunity to locally or remotely manage non-electronic aspects of facilities management. For example, through TFM, a remote user can examine the effectiveness of maintenance and access strategies by the use of remote or local CCTV systems. Any resultant issues may then be entered into the TFM database. These incidents will sit alongside electronic security system-generated incidents for a given location.

TFM in the real world
BMS manufacturers are possibly most alarmed right now because the concept of TFM is no longer just a concept but very much reality. Certainly in the case of SSS Protec's purpose-built central station in Bristol. If you were to use the term ARC here it would be something of a misnomer. In fact, the operation is best described as a Communications Centre.

Purpose-designed and built using no less than 18 miles of cabling, the SSS Protec facility already handles around 6,000 signals, managing a client portfolio that takes in the retail, financial and general commercial environments.

There are currently 12 operator stations and a supervisor station, with staff using flat screen computers and adopting a Call Centre-style methodology by working in 'cells' or teams. Currently, the teams are divided into intruder connections, remote monitoring connections and a Help Desk.

As you'd expect in a central station, staff are issued with access control cards that log each operator on and off duty. Also, four different lighting levels are available to take into account both day and night shifts. All of the technology employed has dual redundancy, with a further 'ARC' replicated off-site in the event of total disaster. All calls are recorded 24/7.

The powers-that-be at SSS Protec, in particular managing director Terry Baker, are firm believers that it's the management of data that sets one ARC operator apart from another – notably, for example, feeding information to a client 'by exception'. This concept of total and complete management significantly drives the cost out of facilities management, including security, Health and Safety and fire protection (see panel 'Total Facilities Management: cost benefits for end users').

For too long, the myth that BACnet would be the panacea for all future building protocols has been allowed to perpetuate when the reality of the situation is somewhat different. As a result, multiple protocols have been allowed to continue unchecked to the extent that confusion reigns supreme. Much like buying a video recorder back in the late 1970s – should you go for VHS or Betamax – or a DVD today, one excludes the other.

The end result is that bms specialists, security professionals and fire prevention managers have all positioned themselves independently, sharing some similarities but not enough that the ultimate integration of their respective systems would be considered as either a worthwhile or practical step.

All parties in the management chain have fought shy of developing common platforms – and will probably fight hard against anyone with a solution that can interpret any protocol into a common language that other systems might then understand. It's simply not in their commercial interests to do so.