Casino Video Surveillance Design Case StudyBy Ben Wood, Published Nov 21, 2008, 12:00am EST
Distributed architecture is the key concept behind casino system designs. All encoding and recording is done on the single channel (blade) DVRs, before such devices are connected to the main CCTV network. The advantage of such a concept is that very low overall bandwidth is required, i.e. thousands of cameras can be recorded without depending on the network. Only what the operators want to see, be that live views or recorded footage, needs to be streamed over the network, hence bandwidth requirements are only dictated by the number of decoders required, which is always much lesser than the number of inputs (encoders).
I am proud to be involved in some of the largest fully digital CCTV systems (no analogue matrices involved) in the world, such are the Sands (1,300), Venetian (3,500), City of Dreams (4,000) and other large casinos in the Macau area, all of which were designed with the Dallmeier's cutting edge Digital Matrix System [link no longer available], based on a choice of MPEG2 and MPEG4 encoding, single channel "blade" design.
My intentions (as an older CCTV engineer :-) are to just put down some historical facts for the younger achievers out there, before my recollection evaporates in the “Ether.” [Editor's Note: Vlado is a CCTV Legend and the Author of the "CCTV Bible"]
Although the concept of distributed architecture is very nice and clean, and easy to implement (from the conceptual point of view), I have been also involved in systems where customers have an existing analogue matrix switcher and they do not wish to completely remove it.
Their justification is that the operators are well trained and versed in using the “good old” keyboards, and while the matrix is working well, there is no need to remove it completely, only add DVR functionality that can be executed easily from the CCTV keyboards (playback, time/date search, synchronous playback, etc.).
To achieve such a functionality - high level interfacing (HLI) has been done in quite few casinos in Australia, where DVRs have been implemented as part of a ”hybrid” design, where the main role of switching is still done by the “good old” analogue matrix.
Systems like these are currently in Crown casino in Melbourne, Star City in Sydney (where, strangely, one analogue matrix was removed and another put in place in order to be interfaced with their new digital system), Burswood in Perth, Jupiters on the Gold Coast, etc.
Hybrid” matrix is a more complex design as it requires not only the HLI implementation, but also requires careful re-programming of the analogue matrix macros, and only a handful people know how to do this. Still, the point I am making here is such designs are possible, they have been done and they (still) work well.
SkyCity Casino Migration Case Study
The SkyCity casino in Darwin was completely changed over to digital without any down-time in early 2008. For casinos this is a pretty important requirement. Legally, casinos in Australia (and in many countries) cannot operate without CCTV system running. This means losses, and casino must not operate with losses.
The Digital CCTV system at the SkyCity casino in Darwin was installed in the first half of 2008, as a complete replacement of the existing outdated analogue matrix switcher.
- The new system offers a full digital CCTV matrix switching, recording, distribution and PTZ control of all cameras via a network without the need for analogue matrix.
- The key software component is the [link no longer available] - Security Management System software.
- The key hardware components are the Dallmeier [link no longer available] modular CCTV encoders and recorders in Euro card format.
The DIS-2 modules are complete computers running on embedded Linux operating system, controlling the hardware based A/D conversion and compression, as well as network communication. Each DIS-2 module accepts one CCTV camera analogue signal and converts it to digital MPEG-2 streaming (MPEG-4 is also possible, since each DIS-2 has dual encoders, one for MPEG-2 and the other for MPEG-4).
The total number of DIS-2 units is equivalent to the number of cameras in the system (over 320 in the initial stage), as each DIS-2 encodes and records one camera individually. Once each camera signal is encoded into a digital stream, it is recorded on the internal two hard disk drives, and made available for live viewing via the local area network. Each camera stream, recorded or live, can be viewed by any operator on the network at any time, irrespective of how many operators want to connect to the same DIS-2.
The storage length of the MPEG-2 encoded signal, as well as its quality, depends on the disk drives size and the chosen compression streaming rate (which may vary from 0.2Mb/s up to 16Mb/s). The current configuration allows for over 7 days of permanent recording using 3Mb/s, but longer period by increasing compression, or higher quality by decreasing compression, are possible.
Distributed Architecture Employed
The overall design concept is of a "distributed architecture", which guarantees high quality digital video, high redundancy (any DVR can have a drive failure, but no loss of recording will occur) and uses very low bandwidth, as determined by the number of operators/monitors.
The DIS-2 modules are on the periphery of the “horizontal” network dedicated to CCTV, which means encoding and recording is done before the signals get onto the network, hence a network failure does not jeopardize the integrity of the system.
System Control Software
The main system control software is the Dallmeier SeMSy - Security Management System software.
The SeMSy software does an intelligent management of the whole system. Each operator has a SeMSy running on their own PC, as well as Dallmeier multi-functional keyboard, from which each operator can have full control over the entire system. This includes selecting any live view camera on any monitor, selecting any recorded footage of any camera on any monitor and selecting and controlling any PTZ camera.
All of these selections and controls can be done from each SeMSy workstation as well as from each keyboard independently. There are currently 6 main workstations in the main control room, one for the casino manager and one for the technician, but more can easily be added in the system.
The SeMSy system has also a backup server, in case there is a problem with the main server running the SeMSy software. For even higher redundancy of this important system software, all configuration and parameters are continuously updated and backed up via the network on each operator workstation.
Included on each SeMSy workstation, there is a very intelligent and intuitive to use Graphical User Interface (GUI) software called Advanced Maps. This software is integrated with the SeMSy and allows operators to easily locate a camera in the system, without necessarily knowing their physical number, but rather their position only. The SeMSy Maps [link no longer available] can read and accept directly AutoCAD drawings with the cameras and layouts automatically being recognised with their numbers and location.
All SeMSy stations are continually updated with the latest camera list, names, bookmarks, events and maps via the SeMSy Pro servers. This means only one central server needs to be updated with any required information and all operators have instant access to the latest casino layout changes via the network.
Equipment Rack Layout
In the current system with over 320 cameras, there are total of 5x19” racks. The first rack is populated with the server computers, DIS-1 decoders and core network switchers.
The racks 2, 3, 4 and 5 contain all the DIS-2 subracks and Cisco network switchers. Each 19” rack has sufficient space for 9 subracks with DIS-2 modules, making total of 90 camera encoders and recorders per 19” rack (making a total of 270 encoders) and the last one has the balance of the cameras.
Total of 10 DIS-2 encoder/recorders are housed in each subrack. Each subrack has dual (redundant) power supply at the back of the subrack. If power is lost on one, or the power supply itself fails, the second power supply is automatically turned on and powers the whole subrack and its modules without a loss of power. For a proper power redundancy the two power supplies are connected to two separate mains phase rails.
There are 9 such subracks per 19” rack (totalling 90 cameras per rack), with the exception of the last rack having slightly less than this. Each DIS-2 unit is fully self contained hardware dual encoder (MPEG2 and MPEG4 are possible), running on Linux OS on a flash disk, and capable of fully redundant (mirrored) recording with the 2 hard drives used in each DIS-2.
In the initial system, each DIS-2 unit has twin 250GB drives which are configured in mirror recording mode, meaning that the digitized and compressed signal is recorded on both drives simultaneously. This is done for redundancy purposes. If one of the two drives fail the other one keeps recording without loss of recorded footage. Each DIS-2 is also hot-swappable so that, when needed, any DIS-2 module can easily be removed and new one put in place as a replacement, with an appropriate replacement IP address.
Similar redundancy is included in the network design due to the redundant network switching, so even a network failure will not jeopardize the recording of all cameras.
The modular design of this system allows for easy expansion by just adding DIS-2 modules, one per each new camera, and putting them on the same network, with appropriate IP addressing and logical allocation entered in the system.
There is no theoretical limit on how many additional DIS-2 modules can be added, although for practical purposes after around 1,500 cameras additional system SeMSy servers would be required for better handling of the amount of channels.
The network itself does not require any bandwidth expansion, because the streaming bandwidth required is determined only by the number of monitors, and at this stage the 1Gb/s network in place is sufficient for more than 250 monitors. Understandably, each new camera (DIS-2 module) will require a physical network port to be able to insert it in the same network.
Back to Top