ZoneMinder Forums

Here's a very involved new feature for ZoneMinder... Infact, it could be its' own open source project alltogether:

Physical Access Control.

When security is a concern, physical access is usually the thing that we (those who are trying to keep things secure) care most about. Zoneminder is an excellent recording solution for security... and ZM's functionality could be greatly enhanced with access control features.

What is Physical Access Control? - It is a method to provide access to those who you want, while preventing access to those you don't. A lock and key is a method of access control, but there are advantages to other systems. Today's access control hardware usualy consists of proximity cards, which are given to a user. When the user swipes his/her card past the reader, the cards' use is logged, and the door is allowed to open (Usualy by an electronic striker).

How is this useful? Cards can be stolen... just like keys. But, unlike keys, an individual card can be disallowed access (a lock could be changed, but all valid users who had a key would have to get a new key for the new lock). Doors which are forced open or left open too long can be detected... and ZoneMinder could use this information to set cameras to an alarm state.

Now here's the hard part: I'm no coder. Nor do I know if there is a standard for proximity cards, door strikers, keypads or other such physical access control hardware. While this idea is related to ZoneMinder, it defiantly could be its' own project. Where this idea goes from here... I have no idea. But this would be a great project to have for the open source minded security community.

--Pathway

This is something that has cropped up every now and again. I am all for it but it tends to hit a bit of a wall generally because there does not appear to be one (or even a small number of) standard and those that do exist tend to be proprietary and this obviously prevents them from being used in an open source project. Add to that the cost and difficulty in getting the actual access control hardware and it has tended to get bogged down pretty quickly.

The hooks for trggers etc are all there so there is the possibility of hooking up ZM with access control hardware as an integration exercise _if_ you can get the protocols and the hardware together.

zoneminder wrote:this obviously prevents them from being used in an open source project.

Actually the more proprietary something is, the more safe.

To a point. Which explains the reluctance of equipment manufacturers to release protocol details except under NDAs, which means that they cannot then be included in 'open' projects.

i would be interested in pushing this forward, either a seperate project or linked to zm. There aopen protocols that we could use for readers etc, but access control usually has its own hardware that can operate in the event of a cpu failure. ALl the interfacing between the controllers and the pc is via closed protocols. connecting readers directly to a zm box would be fine for small system (ie upto 4 doors) but i think an input/output system would be far more flexible (cause and effect) rather than running doors directly

Hello

Sorry for me english...

There are open standards in access control...
http://en.wikipedia.org/wiki/Wiegand_protocol
You can find there documentation about the protocol (2 pdf files)
There are many hardware products on the market who are Wiegand compilant.

I am also interested in such a project.

i am in. i can do some uC (AVR in particular)/generic hw development.

Another standard... for this:

http://www.rfc-editor.org/rfc/rfc4765.txt

Hardware control access sistem with IP transmision...

http://www.security.globalsources.com/g ... 084887.htm

Okay... First let me remind everybody that I'm not a programmer. Now that that is said:

If this was to be done, we would have to figure out some things...

There are basically 3 devices: Input devices (Keypads, Proximity Readers, etc) Door Strikers and sensors. Perhaps there are more, but these are the most commonly used items.

We would have to know how a keypad communicates with the server. Some keypads may be IP based (as mentioned above) while others are not. How would this software interpret it? Are there already programs that do this? Are any of them open source?

We would have to drive the Door Strikers somehow. How can a server control such a device? This may require external hardware.

We would have to have a way to sense the status of a sensor. I know there are "Normally Open" and "Normally Closed" sensors available... But again, I don't know if there is a computer interface to these.

If we can answer the interface questions to these three things, then this idea is possible and worth perusing.

--Pathway

I have recently visit a big fair of security products (location Romania/Bucharest). Many of the participants with IP products, are offering SKD for there products... in general I presume for windows (dll).

If we have the SDK that will help ?

ignition wrote:If we have the SDK that will help ?

I want to re-stress, I am not a programmer.

That being said, yes. It would help. It all depends on if we can do what we require with that SDK. For example, if a manufacturer has a door striker, and a computer-controlled switching power supply... maybe with an IP or Serial interface, and the SDK helped us with how to operate it... Then we defiantly could use it.

--Pathway

ignition wrote:I have recently visit a big fair of security products (location Romania/Bucharest). Many of the participants with IP products, are offering SKD for there products... in general I presume for windows (dll).

If we have the SDK that will help ?

if they had SDK for linux/unix that would help. protocol description would help as well. not much use for windows dlls unless you're going to reverse engineer protocol.

Hi,

I would be interested helping with the development of something like this. Personally I think this should be started as a development seperately from ZoneMinder - but with the option to easily integrate the two.

This project will also involve some hardware development:

* Access Control Cards: One can use either magnetic stripe cards (the readers for this normally have TTL outputs [a clock and data line]) or go the proximity card route (This readers normally have a RS232 output which can be connected to a computer directly).

For both the magnetic stripe and proximity readers, one has to convert this into a "bus"- or "star"-like architecture. Having a PC for each card reader isn't feasible. Some conversion to RS-485 or Ethernet will have to take place.

* Physical connection to locks: Some circuitry would have to be developed also to actually interface with door locks. Since most of these use magnetic coils or solenoids and use a signifigant amount of power, some heavy duty powersupply with the computer only driving a relay would be best.

Also, we have the same problem: We want one computer being able to support multiple doors - so some hardware would have do be developed to support Ethernet or RS485 for this as well.

The standard software user wanting to impliment an open source access control system doesn't neccesarily have the technical skills to build his own RS232 -> Ethernet converters - even if the schematics is supplied with the software.

If any one has a better idea - I'm quite open to suggestions.

Regards,
Christiaan

Hi All.

I am new to this forum but having been involved in this type of project before, and I would strongly suggest:


1> Go the IP/Ethernet route. These days there are many low-cost single chip micro-processors(uP)/Ethernet solutions. IP capability allows the "at the door uP" to do swipe/proximity reading, control the door switch locally, allows monitoring of forced entry (using XY movement switches).
A great benefit is using the same cat5E or cat6 cable to handle audio/visual intercom connectivity (via the unused twisted pairs). Concurrent data and door handling is a big plus, only sticking to viable international protocols and solutions is better.


2> Strike plate relays are usually powered by AC or DC but DC being the norm. All that is required on the door site is a opto-isolated uP switching a MosFET driver. Some sites I been to even use PoE technology to power the striking plates and the remote uP boards.


3> Going the IP/Ethernet route allows simplified administration using:

A) Isolated network(s) IPv6; Using IPv6 allows each module to be identifiable and can easily linked to a site map.

B) SNMP solution for big sites (using IPv4) or sites with remote buildings;
Additionally, either SNMP or IPv6 allows a problematic "at the door" uP board to flash a LED to identify it to humans when in need of maintenance as well as reporting capability.

C) Use WiFi encrypted connectivity for those "impossible to reach locations";

D) Using something like Linux-RTA (Run Time Access) makes access control very easy programming wise. Using SQL statements and the many SQL knowledgeable languages allows easy development of client control programs/applets - see:
http://linuxappliancedesign.com/projects/rta/index.html for more information, IMHO it is a very smooth idea.

E) Doorway uP can update directly Linux system logs, or if you wanted any particular security log you wised.

F) At the initial setup & test phase of the project, ethernet uP connectivity allows you to bootp each uP directly from the server, hence it is really easy to update/correct the remote uP's until your sure everything is 100%. One site I know of kept this as the default mechanism with only a "Emergency Exit Mode" on board the uP allowed to override the security system. Another plus, is once your sure things are 100% you can remotely "flash" the program into each individual controller without having to touch them physically.

G) Window status and sensing can be coupled in providing environmentally neutral climate control. Again any number of sensors can be appended to each uP controller. On area uP could be used for a number of windows - in the cases where windows can of course be opened - which is coming back in fashion with all the issues associated with global warming, lowering the cost of air conditioning and "sick buildings".


4> As already mentioned, any number of external sensors can be connected to the uP, such as smoke, light, gas, temp and air current sensing just to name a few. Usually using the One-Wire protocol on v.cheap sensors. Likewise as each sensor has a 128 bit serial number administration and a general "Building Health Monitoring" system is relatively easy (though vast) to build. If your interested in some of these sensors have a look at http://www.sparkfun.com for low cost (1 off) availability.


5> You can append any type of security protocol onto any connections. Be they SSL or whatever. Linux has it all, it is just a matter of scoping out what is required and ensuring overheads are kept to a minimum.


6> On the facility side, most new buildings already have Cat5E/Cat6 cabling available. If you need cabling added, today such cable is cheap, available, simple to install and importantly test-able by local contracting staff (and yourself), so the costs would be kept to a minimum. Adding specialized cabling usually is - a big time waster, big $ hole, or technically problematic for the next site maintainer (give some thought to this as it maybe you who is the next site maintainer). The beauty of Cat5E/6 is you only have to document its locations, nothing else

My 2c worth.