woodyads

I use our stock standard BHPB server (SQL build) for our NVR system. We used Dell 2850 when we first put them in. Now we are using HP servers. My next itteration will be virtualised to a HP Blade servers with SAN for storage. We will look at a DR site offsite or in a separate server room. When you are dealing with real servers hardware not PC, properly build and maintained there is no way that DVR is anywhere near a reliable, compliant scaleable or secure as NVR. Its a big outlay but if you already have the Enterprise infrustructure the total cost of ownership is lower.

1 Work out the real Mb/s rate from the encoder. 2 Add up all the broadcast and multicast traffic on the network 3 Find out what your backplane band width rate of your switches are 4 Make sure all your protocols are correct UTP not TCP etc 5 Find what Qos is setup on the network 6 Look for any bottle necks in your network. (large amounts of data backed up can flood a switch regardless of backplane speed) 7 Check the resources on the client machine. Real time Encoding overhead = E Network latency =N Client overhead =C Operator reaction time =O E+N+C / E +N +C + O = System Latency to Operator reaction ratio In other words can the operator react in a reasonable time. Ping your encoder and that will give you the network latency Any traffic placed though a QoS Jitter buffer will further increase network latency.

Rory pretty much hit the nail on the head. You can still use analogue cameras on a NVR but you connect them to encoders at the point of the camera. Essentially an NVR system distributed the encoding to the camera location. With DVR's you bring back an analogue signal back to your server where the encoding is done. This has several flow on effects. If an encoder dies you only loose one camera. Your server can be standardised with no special hardware. Therefore it can be virtualised. The system is no longer CC (CCTV) Closed Circuit. It is routed packet. Addressing is moved from Layer 1 to Layer 3 see the OSI network model How it works. In NVR the client doesn't receive the stream from the server. The stream is multicast from the encoder at the camera. So as more clients view the stream there is no extra load on the server or the network. What does the NVR server do? Records streams for playback purposes Acts as a licence server to allow clients to join the network. Keeps a record of past files in a database Allocates security to the devices, users and groups. The services are essentially an SQL type server and a licence server. These functions can be split, load shared or virtualised to other machines as there is no dedicated hardware in the system. They are also well known to IT departments so updates virus control and all those nasty things can be handballed in an instance bringing you totally compliant with IT. Web vs.. IP I don't like the terminology "Webcam" as it implies HTTP protocol which is typically run on a single port (80 or 8080 for proxies) this rules out multicasting which is the backbone of multi client access. So pay attention, if your application has a "Web client" check to see if it still utilises the multicast stream and doesn't get a point to point stream off the server. OSI network model Layer 1 is the hardware layer, cables etc Layer 3 is the network layer, IP address. Not makeing much sence. Think of it like sending a parcel from vendor to customer. Layer 1 is building the road between the two and getting a truck to drive there. Layer 3 is given there are already roads and truck, planes and boats. You just write the address on the box and it will find its way there. So in DVR you must put cableing between the camera and the server and in NVR given you alread have the network in place you just need the encoder.

Rory, If you are only pumping one or two cameras through that cable, it's unlikely you are using more that 10mb/s. Force that port down to 10mb/s and you will get more distance. Again if your desperate you can force it to half duplex and improve the distance again. Yes you will need a manageable switch to do this. and don't use hubs as they only replicate the analogue signal with all its faults. Switches store and forward so they check the data then resend a fresh signal.

I have just been specking a new high transaction SQL server. Throwing about 14 disk in it. Every function is getting its own array of disks. One set for the OS, one for swap, one for Tempdb, one for each database and one for each log. There will be two databases on the server with a total disk capacity of 32 disk. All disks are to be 15,000k set up in raid 1 or raid 10 with no raid 5 at all. Lead me to think of the valour of putting individual cameras on their own disks. Depending on the amount of replay you do and the server configuration there is room to argue (in the case of no redundancy) smaller groups of cameras on individual disks and not raiding the disks. Or in the case of redundancy using many smaller arrays rather than one big one. The break even point in calculating the number of cameras depends on how much upset is caused to the array or disk by reviewing one stream while trying to write the other streams. You also have to take into consideration the efficiency of the controller, when you move to serial or fibre channel etc. There is no set answer as prices and performance of the components are constantly changing. One other big change is we have moved to parametric pricing. That means that we now get charged for server support and capital as a monthly expense over the life of the asset. This is not a lease but an internal charging method that takes the burden of spending IT capital. Most big companies are very limited in how much capital they can spend but their expense budget is quite limitless. The good news for CCTV here is it should be easier to get decent hardware in place . Rough figures. Server support $1500 - $2000 per month depending on services $30k server is now $700 per month. The server above is costing around $2200 per month for both support and capital.

http://www.pugetsystems.com/articles.php?id=29 Thinking of you guys when I read this article. I don't totally agree with this guy as he is not dealing with Enterprise equipment. but he has some good points for low end, home user equipment, (read high end, enthusiast). However he does have some good data on hard drive failure rates that most of you would find useful. Be warned hard drive failure can be due to shipping technique. In particular if a drive is shipped by air then heats up too quickly in the wrong environment. Most drives are packaged to endure this but if they are removed from the packaging it can create problem.

One reason for the excessive packaging of hard drives is temperature control. Being in a remote location there is a good chance that your drives are being effected by cooling down and reheating up to quick. Sitting in the sun then in a metal cage then loaded onto a plane and taken to 30,000ft Then a couple of hours latter they are back on the tamac. It can create condensation which corrodes the components. It use to be a big issue in the early 90's when distributors were a bit blaze about their packaging techniques. We had failure rates for certain vendors at 10% then others were around 1.5%.

With the plethora of large screens out there. Does anyone have a good mix of Wide screen and video card. Would like to run two wide screens of one computer if possible. What are the catches, what resolutions are truly possible, Has anyone researched or better still actually tested the solutions. I am feeling particularly lazy about this and someone out there must know the answers.

Found 3 option depending on your budget or the dulux model. Didn't that last company make sewing machines.

Hmmm easy solution get your customers to spend more money on UPS's Sorry got no real answers apart from that one. We have big power issues here but have the money to solve them. We have a 20~30MW diesel power house (backup only it was replace with Natural Gas) a 20MW Gas Turbine and a portable 4MW Gas turbine. Yep portable comes on the back of 4 semi's . Still its small and unreliable by city standards we probably have 10 > 4 hour and 20 < 4 hour outages per year. Your most cost effective method of dealing with Power outages is a decent UPS. My main UPS is 30KVA with 1800kg of batteries and we power 8 servers, 8 workstation, 10 network devices for about 8 hours. Cost is about $23k AUD about $20k US. This is about 1/4 of the price of installing small 1kVA UPS's Solar is way too expensive 2 cameras and one Network device (120w) cost about $15k. However it is very reliable, no moving parts. Backup Gensets are just too unreliable. Best I found are from a mob in Canada called Mechron. They make incredibly reliable gensets/RAPS but at a price. Guess your best option option is to argue for your mains power suppliers to install a backup prime genset with auto kick over.

Hey Rory are you expecting some power issues? what are your main concerns?

Why did it blow and what went! Integrated circuits work on 3.5v ~ 5v, Computer power supplies are a bit different they supply 5v and 12v. 5v is for the integrated circuits which is then broken down to 3.5 and lower for the high density chipsets. The 12V is used for electric motors in the hard drives while the intelligence in the hard drive is IC at 5v. Where am I going with this? Your cameras have probably suffered little damage. Hopefully the damage has been done to the onboard power converter. Take the camera to a electronic technician (TV repair man) and there is a good chance of finding the fault. Why was the power supply 13.8v? When charging a battery you require a higher voltage than the battery. Car batteries should sit between 12.8v and 13.2v but when your charging you should measure around 13.8v across the battery as the alternator will charge at 13.8v. Hence 2-way radios and other vehicle equipment is designed to take at least 13.8v. The power supply you have been supplied with is designed specifically to supply power for those devices when in a rack etc. Another problem you have is the distance. You will get volt drop over 40m so you need to put individual power converters at each camera, get away from 12VDC, or install very fat power cable. Most high end PTZ units tend to use 24VAC then have a converter to change the power back to 12v for the camera and its own motors etc. The IC's will again use 5v. The rules here are the higher the voltage the smaller the cable you can use and hence the longer the cable. So 24VDC is better than 12VDC. The next rule is AC is more efficient over distance than DC. Hence 24VAC tends to be the standard for cameras for large infrastructure projects. How to fix your problem. Forget the fuse idea it won't work. Fuses are to stop your wiring from burning out if there is an excessive load (lack of resistance in your circuit) . The lack of resistance could come about from a short between your wiring or two many devices though too smaller main wiring. Your wiring could catch fire and set fire to the building. So you need the fuses but they won't stop the cameras from frying. Voltage that is killing your cameras fuses can't modify voltage. 1: (If you had to use the 13.8v power supply.) Put a battery in the circuit and install a solar controller. The battery will filter the power from spikes and the solar controller will deliver your 12 volts. Bit expensive and there are a few other issues to deal with. 2: Buy a 12V power supply. Problem is distance so you should run mains to each camera and then install a small 12v plug pack for each camera 3: Buy cameras that are fit for purpose (24VAC) or get 24VAC to 12VDC for each camera and run them all off a mains to 24VAC converter. These are common place available from lighting shops.

Yeh our IT department setup VOIP by using a VLAN. Problem is when someone plugs in a laptop to a phone port it can take down the phone system. Not a very robust option, I am currently redesigning the network to utilise QOS properly as soon I will be using the corporate LAN as the backbone for two way radios as well as phones. Disadvantage of running a separate security network is you can't push the video traffic to any desktop you like. The main advantage with an IP system comes when you use application layer security not physical layer security. We are about to build 2 new remote offices and a separate network would mean separate links and more RF issues.

Rory, The security issues with computers are many. I kind of think that if I am going to leave holes get IT to deal with it. This is the long way at looking at the problem but is how I think I have a choice of databases. MDE or SQL. Problem with databases is backing them up. There are open file issues and restores don't always work. You really need a specialist cause you want to get on with what you are good at. So my IT department have no issues with SQL it is enterprise orientated and we have hundreds of SQL databases. So that falls under the service agreement where the MDE does not. Its not all that hard to backup an MDE but I am not interested in testing the restores, tape integrity and everything else I should do. Problem with SQL is it advertises its presents over the network and requires protocols to log in etc. (same for MDE's) . Remember the Slammer virus. Many viruses have exploited holes in the login protocols, and once they get in they look for typical files they can infect. From there they can re-enable services or replace service files with infected versions. So at the end of the day anything that resembles a standard PC or server required daily virus and security updates. All of which should be tested in a test bed environment before deployment. Encoders may use as little as 3 login or reply services, and do not have a standard directory structure. Change of firmware must be done through a dedicated protocol, it can't use redirector or many other standard services or the standard Windows logon protocol. The first service a hacker will find is telnet. However this should be blocked at your firewall. Encoders are just to limited to provide any services to be of any use to viruses. I am always going to be suspicious of any cut down version of Windows or Windows CE. Two of my vendors are currently looking at such systems and I am leaving it up to IT to pass judgement. I certainly won't be an early adapter of that technology. If i am forced to use it I will certainly deploy Static IP addresses and port filtering to those areas. Not as good as being able to handball it all off to IT.

Special thanks to Survtech and Rory. I have to give a presentation on Wednesday to 30 people from other mine sites around Australia. And will have several of them flying to site on Thursday to view my setups and systems. Most are interested in the IP video system but can't see the importance of the synergies. Your feed back to what I have been saying is invaluable. It gives me an idea to what people will consider as important.

Still can't be fully virtual, . DVR's can have a workstation to view the image, but if you want to shut down the server, or want to move the server to a DR site it can't be done virtually. A virtual server can't have hardware dependencies, you might be able to put the licence server, data and database different servers that could be virtualised. Then the computer with the card will only be capturing and capture encoding itself. But once you have done this you have created a NVR anyway, using the computer with cards as of encoders. The big difference between an encoder and a computer with a card in it is security. Encoders are essentially data loggers that are not susceptible to the standard viruses as they have cut down OS's that are two rare to attract virus builders. They also lack the services required by viruses to spread themselves as well as only answer to a couple of open ports. So IT will accept your encoders or IP cameras as standard equipment but a computer or server with a Capture card in falls outside the SOE environment and is not EOA complient. My control and server rooms are adjacent to the Heavy Duty workshop. (not the best place for it but I wasn't given the time to erect a new building) If we had to evacuate and shut down power to the area I can start a new virtual server in one of the other two server rooms on site. I couldn't do this with DVR's with cards in them because IP is self routing and coax is not. The closest of these rooms is 1.6 km away and the closest camera is about the same distance with other 2km across wireless bridges. NVR has no specialised hardware, it becomes transparent and can be 100% virtualised. Its only dependency is IP address the clients machines call for this can be changed in one DNS entry. Even then IP addresses are virtual it is the mac address that is physical. While I could have built a cheaper solution using DVR I would end up having to support the server as a specialist system. As NVR I can push the whole server to IT and as classic enterprise orientated architecture the will deliver the whole virtualised server architecture from their budget with out me having to lift a finger. I am going into discussions next week with several other sites and one of the topics of discussion will be centralisation using virtualisation in a capital city. I have already had discussions with local IT about them using my server room as DR that they can visualise their servers into and we will be going that way. Our onsite processing plant has been told by the general manager to implement the same Open Route Surveillance system I have in the pit. So we will be able to share what ever server or servers we decide to put the NVR system on and where we would like to keep the data and use the budget to fund the virtualisation of other servers and services.

Very good points. The Casino industry being closed mouthed would a problem in getting reference sites. Also the issue of meeting minimum regulations wrapped with a least cost mentality. This will create a technology gap between casino's and other industries. The RIO for all NVR installations will at first come with synergies with other technologies. VOIP is one of the first for most industries, for us it was RF infrastructure and tyranny of distance. Our control room is 2km from our pit and we can't run any cable. (Definition of an excavator is a machine specifically built with the sole intention of locating and severing fibre cable). We did actually pick up VOIP as a bonus as we put in a building out in the middle of nowhere and used the data infrustructure for just 5 phones. I new another department was running short on copper cable for standard phones so I sold them the idea of VOIP and they helped pick up the cost. Server Virtualisation has been long been available for many NVR's. As long as there is no service specific hardware on the server it can be virtualised. This is the main advantage NVR's have over DVR's. DVR's can't be fully virtualised because of the cards in them. There is a term for all this garbage, its referred to as Enterprise Orientated Architecture. There are many crap articles on the net about it, check out TechRepublic for some of the better ones. Synergies for the Casino industry could come from VOIP or multi site management, or reducing the footprint of your control rooms. I guess a good question for Survtech is are the gambling machines on IP or looking to go that way, do you record the conversations of the security staff radios, is your data on virtual servers, have you looked into power on IP (not power over ethernet), does your data and video share the same UPS system, and are there any changes planned to the phone infrastructure in the near future? A strong argument against these technologies is the physical layer security. (Layer 1 in the ISO model) It has always been considered the primary level of security but as time goes by and security on the higher layers improves it is slowly being eroded. I believe that it will totally disappear. Another strong argument for Casino's not requiring to head down this path so quickly is many may not be public companies. Sarbanes and Oxley only applies to public companies, This is a set of regulations regarding the accountability of directors for the companies data. Those who have to comply, are more likely to have infrastructure and synergies to deploy these newer technologies. You guys are right NVR is expensive, I don't think NVR sells itself. I think you have to sell it off with other technologies.

Guess my point is, now is the time to nail the NVR market by becoming and expert in QoS and VOIP and doing the full integration. There are thousands of largish companies who would jump at the technology if they new it was there. The IT companies I talk about aren't your corner store boys, They are your big cumbersome Unisys's etc. Who are too busy fixing up all the Sarbanes and Oxley issues and VOIP to even consider CCTV. That's why there is an opportunity. They won't hunt down the work, they will eventually be asked by their customers for it. They will turn to the CCTV industry for the camera specifics but the rest of the work will go out other doors. The software, network, cabling, servers and control rooms will bypass the integrator along with bug bucks and opportunity. Fine if your happy with your home customers but once your corner computer stores starts selling to them your margin goes south pretty quick. Rory's right. You won't really loose work, but I can see there is an untapped market out there and its huge and premium.

You are a vendor to the Casino industry. I was implying what I would look for if I was in the Casino industry not as a vendor. My point being that with no reference sites I would be unlikely to take on a vendor based on designs only. If your customers aren't asking for and checking reference sites then it is their bad practice and not one that should be seen as an industry standard or acceptable by any means. Much of my job is correcting poorly deployed IT infrastructure where the customer has failed to check the vendors reference sites. We call this slide-ware because the customer buys on the strengths of a power-point slide presentation. How to check a reference site. Get on the phone and find the person who is fixing the stuff-ups. Not the person who ordered the system they will always tell you its great. Make sure they have similar issues to you. Even if the Video system is non IP you should still check reference sites. CCTV on IP can use layer 1,2,3 and 4 security. Non IP can only use layer 1 security. There is food for thought. Banks use DR sites for their data so why don't casinos for their data and video? These facilities already exist. Virtualisation of servers and infrastructure. Increases availability, instant failover and rebuild. SAN infrastructure is crucial to server virtualisation. QoS. Since it is the biggest slice of the pie and the thing that will create the most headaches moving forward into the future. Eventually IT firms will sell IP infrastructure consolidation, Phones, VC, Two Way, Surveillance and data all done properly with QoS. Video surveillance integrators will loose business to these companies. Not caring less about QoS could be a big mistake. I thought the casino industry would be all over these technologies. Especially for entities that own more than one casino.

If you have a look at High end NVR software it should have the following. A licence server, SQL security matrix, Video Encoder software, A Watchdog, Front end application, Backend application, PTZ Protocols, Most of these products are already written or you must buy the licence to use. There is no point in a Video Surveillance software company writing their own Licence server when you can buy it off Rainbow Technologies and let them deal with all the security patches etc. Same goes for the Watchdog. It is quite viable for a company to buy all this software and stitch it together to make a different product.

Visio is the standard for most companies. However I use Excel for most of my network diagrams, physical layouts etc. The advantage is you can do calulation on the side, and anyone else you deal with doesn't need Visio to view it.

The first thing I ask for is a reference site. I work on a hot mine so my questions are. Give me the phone name and email address of a customer in a hot, dry, dusty environment with a tight IT security model and remote power and complex RF issues. The other customer would have to be of the same scale. I'm also check for a history of the equipment operating at 60 degree C. If I was in the casino industry I would be asking for a past customer with the same network infrastructure, a tight IT security model, a solid implementation of Qos, Redundancy, live disaster recovery sites, SANS infrastructure, and virtualisation. I would also want to know how big your insurance policy was. It may be advisable to try to team up with a QoS consultant. Currently Voice on IP are the highest paid specialists in the IT industry. The real issues with VOIP are QoS based. Once you install VOIP and Video on IP the synergies are massive as one will pay for the other. In reality once you head down either path QoS will become the future focus.

Hubs, Switches and Routers Brands matter, models matter, but setup is more important. Apart from your bottleneck at the DSL Router your setup is more important than your hardware. However your hardware can limit your setup. A hub is an analogue repeater, that repeats out to multiple RJ45 ports. There is little or no intelligence. You can get managed hubs but there is not much point. So any degradation in the signal is passed however the signal is reamplified along with any imperfections. The result is packet loss and resend, not a bad picture but more packets. . A Switch takes the signal and digitally reproduces it. So the signal is entirely rejuvenated. But a switch also has intelligence and once it knows the RJ45 port that the packet belongs to it will only send it to that port. Bit of a red herring cause many IP video systems use broadcast addresses which tell the switch to send it to all RJ45 ports anyway. Hubs rely on the devices network card to detect packet collision and resend, where as Switchs can store and forward packets. Different switches have a different backplain speed so switches ain't switches. Yes brand and model matters. Switches can have even more intelligence again depending on the brand and model. Packet filtering, VLAN and Qos are some of these functions. The use of these functions are growing exponentially. Where once we segregated networks based on physical boundaries, we are now segregating networks based on services. Routers. By definition change the media and protocol that packets travel on. For instance: from IP on copper to ISDN on Fibre etc. However we mainly view these as devices that route packets from one network to another or join us to the wider internet. Routers by basic design block broadcast packet (Many IP Video systems use broadcast packet) So switches are fooled by broadcast and routers block them. So how do you manage broadcast traffic to do what you want. Use port filtering on the switches to physically restrict the flow of video traffic to geographic locations and you use tunnelling to pass the broadcast traffic through the router to another network. Again you can use port addressing at the router to filter out any unwanted video traffic. Not all routers support tunnelling and not all switches support port filtering so yes it does matter which brand you use. So the firm you are to get a phone call from in 12 months time is currently upgrading their entire network to state of the art edge and core switches. They put in VOIP phones and all is running well. They are ripe for the plucking for a nice IP video security system when they ring you and they have a nice fat budget. However the firm that installed the IP phones didn't really understand how to setup QoS. When you install your cameras all the phones will come down at 8am every morning. Are you going to be adequately educated and prepared for the situation, what if your competitor is. So how you set it up is more important to speed than the equipment that you use. If you intend entering or staying in the IP side of the industry I would suggest you learn about this area in-depth and the ocean is very deep. Just because something works doesn't mean you have it right. Even if you have a few IP installation working don't stop reading up on IP,QoS, Routing and Filtering. Note I differentiate between RJ45 ports the physical port you plug your wire into (layer 1) and a port address which is part or a packet and a virtual port (layer 2)

You will need to survey their network, best to use a network capacity planner. Your cameras / encoders need to support port address control and broadcasting. They will need to bring the aggregate bandwidth on a link or several links to handle the broadcast. This includes planning the backplane speed of the core switch and firewall. Be warned its better to though money at hardware and reduce management of ports and hardware devices. Yes you will need manageable devices and if your client has a buy the cheapest policy then walk away from the deal and find a mature client. I would then use an NVR with distributed file servers (or SANS see below) , group cameras together via port address into manageable groups based on broadcast bandwidth then filter the port addresses to each file server. Work out which groups of cameras will be displayed on which client then filter accordingly. Get rid of any 10mb-s gear from your network or port filter out those as well. You must also set up port filtering to stop aggregate broadcasting travelling back up your LAN. Filter each site from broadcasts from other sites. One of the advantages of this setup is the removal of dependency on cabling and hardware. By changing your port filters you can reroute traffic to cater for bandwidth without getting out of your desk. Buy setting up two core switches and firewalls you can prioritise in case of fail over or set up for total redundancy. Logically and bandwidth wise this is infinitely scalable (well maybe to a couple of thousand camera groups). of coarse there are camera and client limitations on the server software. Live viewing is direct to client so there is no capacity issue with NVR servers. I have treated this like you are trying to get 5fps + from 250 cameras with a high quality picture, kind of a worst case senario. (SANS) I am have not researched how NVR software works with SANS. But I would suspect that you can record and replay directly to the IP address of a SANS box without using the server. Find out if this is the case. If so this is definitely the way to go. If not you will need to use distributed file severs which are supported. If your system is dependent on the server for replay or recording you can work around this by using multiple NICs but there are some funny bugs in MS servers you need to read up on. Bottom line is spend the money on a system that will support direct SANS or distributed file systems. I won't bother researching this till I have to and that will be next year for a SQL and Application server consolidation project not for a CCTV project, but I will pickup the NVR system as a matter of coarse. Does anyone know the answer to this question?

I am sure there are many systems that can handle 250 cameras software wise. But the trick here is how you utilise the existing resources or redesign and modify what you have. Its quite simple, first the layout How many sites? How fat are the WAN links (if any) How many Switches (closets) How many buildings or floors. How How much cascading of network devices (or is it perfect star topology) Where is the central monitoring station in relation to the core switch and how many screens / streams do you want to view. Does the client have an underutilised SQL server somewhere. How many users / seats do you want be able to view and review streams. Is there anyone on the general network you want to give viewing or reviewing access.