When you first unpack, install, and hook up an Alarm/Access Control System it is as dumb as a rock. Ok, it is a rock with electricity going through it, but it is still dumber than every politician in the world. Yes, it is really that dumb. But just like Albert Einstein as a baby, it is going to get a whole lot smarter.

After loading the operating system and Alarm/Access Control System program, and any other necessary software, you will hook up the server to the network and begin programming device hardware configurations for the entire Alarm/Access Control System.

Every device has a number of configurations that are required for the system to work properly. The server manages all of these and distributes the configurations out to field devices such as Access Control Panels.

Common configurations typically include (these may vary by system brand):

Servers store all system historical event data. Everything that happens out in the field or at a Console Workstation is recorded into a Historical Log file (or files).

Typical Historical Data stored will include a record where the first field is the year/month/day and that will be followed by the type of historical event, followed by the specific change of state or command. Historical Data may include:

Servers also manage all digital communications throughout the entire Alarm/Access Control System. The Server:

It is common to see both a Primary Host Server and a Back-up Host Server installed on a system to minimize the possibility of a server failure. By the way, I strongly recommend this unless the client does not need the Access Control System to function. I am not being flippant. A redundant server is always recommended.

There are two operating modes for Back-up Servers:

A Fail-Over Server is a server programmed exactly like the Primary Host Server, but is “standing by,” constantly waiting in the wings for the Primary Host Server to somehow fail. Failure can happen when the Primary Host Server is taken down for maintenance or due to a malfunction. The Fail-Over Server receives programming and configuration updates constantly from the Primary Host Server so it is always prepared for the emergency. When the emergency passes and the Primary Host Server comes back online, the Fail-Over Server relinquishes its role back to the Primary Server. The Fail-Over Server may not maintain current historical archives.

A Redundant Host Server is a server that performs all of the functions of the Fail-Over Server, but is also updated constantly and online just like the Primary Host Server. The only difference between the two in normal times is that all commands are being distributed to the system through the Primary Host Server. That role changes should the Primary Host Server go down for any reason.

The Primary Access Control Host Server also serves the System Workstations with all of the data they request. Workstations interact continuously with their server, constantly receiving data from and sending data to the server.

Data Received by Workstations may include:

Data Sent to Server by Workstations may include:

Servers also serve reports to workstations and printers. Typical reports may include:

Most Access Control System manufacturers have woken up to this fact and are now making scalable systems. A scalable system is one that does not require the abandonment of any equipment in order to grow in scale. The organization may have to purchase a larger license, but they do not have to throw capital investment away to expand their system from 64 to 65 card readers or from 128 to 129 card readers as was often the case in the past. Quite literally, a number of manufacturers required that when a client needed to grow their systems from 128 to 129 card readers, they had to replace all of the Access Control System panels and software with another, larger version, all for a modest cost of about $50,000. Yikes!!!

Wait! It was worse than you think. When Alarm/Access Control System manufacturers finally began listening to their customers who were screaming for scalable systems, their solution was to create scalable hardware coupled up with non-scalable software. How did they do that? By selling software that was limited to 64, 128, 256, 512, or 1,028 card readers. After selling the client on a “scalable” system, when the client needed to grow from 128 to 129 card readers, he discovered that he had to buy the next higher capacity of software, at a modest cost of about $50,000! Yikes again! That is $50,000 for almost the exact same software with a key enabled to grow to 256 readers instead of 128. This was common in the industry, and it was especially true of larger, more capable systems.

Finally, along came a company who understood how outraged clients were and they offered the first truly scalable system. The cost of the software was mostly built into the hardware cost so that one basically never needed to upgrade the software, only add hardware to it to grow its scale.

That was real competition for the other major Access Control System manufacturers and little by little true scalability grew across the entire marketplace. Today it is difficult to find a non-scalable system. This approach also saw the introduction of the first multi-site systems.

Up until this time, most Access Control Systems were designed to serve only one facility. The system may have been installed at multiple buildings on a campus, but all were managed from a single Primary Host Computer (at this time, redundant servers were a rarity). This required that all new employees, in order to receive an access card, had to go to a single Security Badging Center to have their Photo ID made and to have their data entered into the facility's Access Control System. This limitation made operation across multiple sites virtually impossible. Accordingly, it was common to see large corporations with many different brands and models of Alarm/Access Control Systems serving their entire Enterprise. This created incompatible cards, so management and other employees who worked at multiple sites had to carry multiple access cards, one for each site they visited.

The first step toward Enterprise-scalable systems was system-wide card compatibility; that is, the ability to utilize a single access card across the entire Enterprise. Due to client demand, Access Control System manufacturers began using the Wiegand interface as a standard, allowing for different facility codes for each facility on a common card format. Thus, management could hold only one card that was good across the entire Enterprise.

The next step along the way to true Enterprise scalability was the implementation of a single, common brand/model of Alarm/Access Control System across the entire Enterprise. This allowed large corporations to take advantage of buying power and provided for uniform training and maintenance. This phase was pushed along by the consolidation of many small independent integrators into large national integrators, who gave large corporations and government entities buying leverage to get all their facilities “under the tent.”

Until to this time, each facility had its own Primary Host Server.

As Enterprise-class organizations began to pay attention to improving cost control on their security units (due to bean counters) and to improve uniformity of corporate security policies across the Enterprise (mostly due to litigation), a demand developed for the ability to establish common security and access control policies across the Enterprise. This illuminated the need to develop a means to control the application of those policies.

One of the best ways to do that was to put access control policies under the control of a single Master Host Server. In the earliest implementation of this, the application was developed for a single Master Host Server, “talking” to Administrative Workstations outfitted at each remote site. These all communicated across telephone modems, constantly passing data up and down the line. This did not work well because of the amount of data being communicated often exceeded the capabilities of the telephone line and the inherent unreliability of modem speeds during weather events.

Until this time, all inter-site communication was over modems.

Finally, the system architecture evolved into what we now call a “Super-host/Sub-host” configuration in which each individual facility is equipped with its own Primary Host Server and these all connect to a “Super-host” at the Corporate Headquarters facility.

This called for the development of TCP/IP Ethernet communications between Super-and Sub-hosts to facilitate the larger amount of data communicated and to take advantage of the corporate Wide Area Network (WAN) that already connected their Information Technology (IT) systems.

It was not long after that TCP/IP connectivity was extended to include communications to Access Control Panels to allow connection of small unstaffed remote sites. Soon after that, TCP/IP Ethernet was used to connect the Cluster Master Access Control Panel for each individual building on the campus. This was ultimately followed by using TCP/IP Ethernet to connect most if not all Access Control Panels throughout the system, taking advantage of existing Ethernet systems and more uniform connectivity.

The Core Network typically comprises between one to any number of Digital Ethernet Switches for an Alarm/Access Control System. Typically, the network may include:

The Core Network should include one or more good quality digital switches such as Cisco, HP, 3Com, and so forth (avoid the cheap computer store brands). The switch should be capable of supporting VLANs, VPNs, and both Unicast and Multicast protocols to the individual port. Redundant power supplies on the switch are a plus. Better switches are more reliable, less prone to the aging effects of the environment (temperature and humidity effects), and are more likely to work well when the Access Control System becomes part of a larger Integrated Security System including Digital Video Cameras and Digital Intercoms.

I recommend that all Digital Switches in the same network are of the same brand (all Cisco, all 3Com, etc.). This facilitates better management of the switches and greater reliability of the network in real-world operations.

The Servers are the core of the network. When you have a Primary and Back-up Server, they should be connected together over an Ethernet network. These will network together through a “Core Switch.”

Although Workstations can sometimes be connected to servers using serial communications (RS-232 or Universal Serial Bus, USB), TCP/IP Ethernet connections are recommended. These will connect to the Servers through the Core Switch.

Assuming that the system comprises only a single building, the Access Control Panels can connect to the network through an Edge Switch located near the Cluster Master Access Control Panel. Other panels can connect to the Cluster Master through TCP/IP Ethernet or RS-485 for most brands.

Ethernet has speed and connection distance limitations. Common Ethernet speeds include:

TCP/IP can connect via Copper or Fiber. Copper connections have a nominal distance limitation of 270 feet (100 m) for 10Base-T and 100Base-T systems. Copper connections include Category 5, (CAT-5), CAT-5E, and CAT-6 types. For 10Base-T and 100Base-T connections, CAT-5 and 5E connections are acceptable up to 100 m. CAT-6 connections serve 1 Gbps connections up to 100 m. CAT-6 cabling can also provide up to 1,500 feet for 100Base-T connections.

Fiber connections include Multi- and Single-mode types. Multi-mode fiber is intended for relatively short runs or runs having lower speeds (1 Gbps or less). This is common for any runs over 100 m, such as between buildings. For 10 Gbps connections, always use Single-mode fiber between buildings.

Alarm/Access Control Systems typically push relatively few data as compared to Digital Video Systems (the exception is that those systems also send video with alarm information).

Access Control Networks for Access Control Panels can typically be 100Base-T networks. Connections between Edge Switches (at the Access Control Panels) and the Core Switch (at the Servers) can be over 100Base-T copper Ethernet up to 100 m. Distances over that should connect through Multi-mode Fiber using SFP connectors on the Digital Switch.

When you connect an Alarm/Access Control System to other security and building systems, it is often best to do so by Ethernet connections. The exception is for connections between systems using dry contact interfaces, such as alarm or door control interfaces between systems.

Whenever connecting multiple systems on the same network, it is best to do so by placing each system on its own VLAN.

VLANs allow you to isolate communications between systems, buildings, and sites to better manage the quality of communications when multiple systems share the same physical network. VLANs are accommodated with programming on the Digital Switches and with a VLAN addressing scheme so that you can easily see which VLAN each system and device are located within.

A typical VLAN addressing scheme might be

VLANs require the Core Switch to be a Routing Switch capable of Level 3 commands. Distribution and Edge Switches must be capable of accepting VLAN programming. Additionally, VLANs can be programmed for each system for each building.

When the Alarm/Access Control System expands across multiple sites it will be necessary to configure VLANs for each system for each site, and the VLANs may need to be Routed through an existing Business IT Network to avoid the usually unbearable cost of a dedicated Wide-Area Security System Network.

In such cases, the Security System may need to comply with Network and Routing protocols and addressing schemes of the IT Department. For this reason, it is advisable to coordinate beforehand with the IT Department Director to obtain VLAN protocols and an addressing scheme for the Alarm/Access Control System network that will comply in the future with protocols and addressing schemes already in use by the IT Department.

Although the Security System may be on its own network now, as it grows to span multiple sites, it will often need to be routed through the IT Network. Making sure that you have VLAN protocols and addressing schemes that already comply with the IT Department's standards will ensure the least possible disruption if the two are merged together in the future and no harm is done if they are not merged.

Additionally, it is recommended to place the Security System behind a hardware Firewall to protect both the Alarm/Access Control System and the Business IT System from each other to ensure sustainability and reliability for both systems.

For the ultimate in protection, I recommend that the Security System be routed through a VPN, which both completely isolates and encrypts the security system data from the Business IT Network. VPNs are also a good solution for merging systems if the VLANs are not protocol/network address compatible.