Verex local configuration and usage notes
This is the place to document notes about the configuration of Verex, local conventions etc.
Verex handles both access (door locks) and intruder alarms. In principle they can be tightly integrated (e.g. entering an area with a valid card can be made to disarm that area). However for reasons that are largely historical, the two have been kept separate in the our system.
These notes are intended to supplement, not replace, the Verex documentation. The primary documentation from the distribution CD is in the directory /usr/groups/admin/verex/doc/Director/; the main manual is 21-0381Ev4_74GuardallDirectorUsrGd--English.pdf. The online help in the Director interface itself appears to be a different presentation of essentially the same text.
Much of the programming of Verex has been automated using the ERM interface of Verex. Rather than setting up users directly in Verex, we have higher level data structures in the Administration database.
Notes on Verex concepts
- An account is a major unit of management, which might roughly be expected to correspond with a building. We only need one account "Computer Laboratory" for normal use. There is also a dummy "Playpen" account which was used for testing of automatic updates. Most activities in Verex take place in the context of an account with only a few things being global.
- An operator is somebody who uses the Director interface tool. In general we use CRSIDs as operator names. Each operator has a set of operator permissions which controls what that person can do. Initially, all operators have "Master" permissions and can do anything, including creating more operators. Each operator has a password to control access.
- PC client
- The term client refers to the machine which runs the user interface. All clients must be registered with the server by initially transferring a "cyclic ID" value out-of-band from client to server. Clients can also have permissions which can restrict what an operator can do from them.
- A user is a person who interacts with the security system by going through doors and using keypads. The primary identification of a user is an integer. A user may have a PIN (used to authenticate access from a keypad) and/or a card number. The user record holds name information but this does not need to be unique.
- An authority defines what a user can do in terms of operations on alarm keypads and access through doors. Each user has precisely one authority.
- A schedule is used to control time dependent activities. Each schedule defines an "on" and "off" pattern based on time and date, and can be used for a variety of purposes such as locking and unlocking doors, arming and disarming alarms etc.
- A panel is a semi-autonomous system which sits on the network and controls doors, keypads, alarm circuits etc. The Verex server machine controls the panels.
- A keypad is a means by which users can communicate with a panel.
- An area is a part of the building which has controlled access or is protected by an alarm.
- Fairly obvious, a door gives access from one area to another.
- input point
- A logic signal that a panel can sense, such as a door contact, proximity detector etc.
- output point
- A logic signal that a panel can control, e.g. to operate a sounder or signal to Security.
- Enterprise Resource Management - a fancy name for a simple interface for importing and exporting information from the system. Updates are done by writing rows into a SQL table which is polled by the Verex software.
Our system has 3 panels. One in GN19 controls the whole of the intruder alarm system. The access control system is split across two panels in GW05 and GS33. Each panel has a local network connection to VLAN 194. The wiring beyond the panels to the rest of the system is the responsibility of Briar Security, who set up the associated configuration in Verex.
The controlling server is verex01.ad in GN09. It is dual-homed, with network interfaces on VLANs 100 and 194 (delivered on a single trunk connection). The IP addresses on VLAN 194 are documented in the DNS. However at the present time there is no IP forwarding between VLAN 194 and any other VLAN, so the panels are not reachable from any machine other than verex01.ad.
The Verex server holds all its non-volatile state in a SQL database called Director. This is a database within the main SQL server system and is replicated and backed up alongside all our other databases. The server itself holds essentially no permanent state and there are no specific backup arrangements for it.
Areas are local to a panel. The areas defined for the alarm panel are in effect groupings of circuits to be treated as an entity. Several of these areas refer to physical locations such as GN09, but there is also a catch-all area "Perimeter" which covers the majority of circuits which are set outside office hours. If a requirement arises to treat a set of circuits differently, they can be made into a separate area, but note that changes will impact how University Security have to operate the system.
The areas defined on the two access control panels refer to physical regions of the building to which access is controlled. In order that these areas can be distinguished in our automatic processing of cards, the names of access areas all begin with a single space character. This space character also ensures that these areas sort first in the user interface when setting up authorities. In addition, the base name of each area ends with an underscore. For example, the name of the area which consists of the two entrance doors is " entrance_". The area names have to correspond with those used in the configuration of "capabilities" in the Administration database.
There is precisely one logical area whose doors are split across both access control panels. This is the main office area of the building, and the panel-specific areas are called " offices_1" and " offices_2".
Each door reader is assigned to the appropriate area. In the case of a door which has readers on both sides, the area for each direction is programmed independently.
Doors are assigned to the appropriate access panel (determined by the physical wiring). The name of each door is generally of the form "From - To", generally expressed in the direction less secure to more secure. The "From" is sometimes omitted if it seems totally obvious. Where there is more than one door between the same two places, a qualifier (usually a compass point) is given in brackets. The text names appear in logs. Each door also has a short "LCD Name" intended for display on keypads, but in practice in our system they never do.
There are no doors assigned to the alarm panel. The alarm monitored doors appear as "Input points" instead.
We have reserved user numbers 1-99 for manual configuration. In general they are used for alarm system users, and generally refer to a class of people rather than individuals. They have PINs assigned, and an authority that controls what they can do in the intruder alarm system. They do not have card numbers assigned other than for testing purposes.
User numbers above 100 are programmed in automatically using the ERM import interface. These users relate to cards, and associate each card with a name and an authority. It is not useful to assign PINs to them. These users should not be changed from within Verex; changes to names etc should be done in the local web interface. If a user entry becomes corrupted, it can be deleted and the local web interface "anomalies" page should then offer to put it back. The Verex "Card Lost" facility should not be invoked; use the local web interface "Blacklist" facility instead.
A person can have more than one card, which will have the same name. In the scrolling access log in Verex Director, the internal user number is also recorded, allowing identification of which card was used. The underlying log in the SQL database also records the card number for every access attempt.
Authorities control what users can do. Every user has precisely one authority. There are two types of authority in our system.
Authority numbers 1-9 are ignored by local web interface. They are used to determine permissions to control the intruder alarm system and are therefore given to user numbers 1-99. They have permissions relating to the alarm areas and none over the access areas.
Authority numbers above 10 are used by the access control system and are given to user numbers 100 upwards. They have authority over access areas (the ones whose names begin with a space) and none over alarm areas. They are NOT automatically programmed by the local interface, but can be verified to be consistent with what they should be.
The user interface in Verex Director for setting up authorities is a bit tricky. Read the documentation carefully. The best way to make a new authority is to copy one that is similar to the requirements, and add or remove areas. Each area within an authority has a set of "attributes", and it is important to ensure that when adding an area you add it to the right attribute set. You will normally want to leave the attributes unchanged. It is important to distinguish between the areas with a blue square (areas that have some attributes in this authority) and the rows which are currently highlighted (areas whose attributes you are currently editing). Read the documentation carefully. The best procedure is usually:
- Select an existing authorised area by clicking on a blue square.
- Click on "Select all matching areas" (all rows with a blue square should then be highlighted)
- To remove an area: right click on its row and choose "Remove Area"
- To add an area, click in the leftmost column to the left of the grey square.
- Save the changes before you click anywhere else
In particular, note that if you try to add an area by clicking on the grey square, it will indeed turn blue, but it will almost certainly have the wrong attributes and probably not work. Careful aim is needed. Read the documentation carefully.
Verex uses a single pool of schedules to control a wide variety of time dependent behaviour. At any instant, each schedule is either "on" or "off"; what that actually means depends on what that particular schedule is used for.
Each schedule has the following properties:
- A name, which we generally try to make descriptive of its logical function rather than the time interval it represents.
- Up to six on/off time intervals, each of which has a bit mask selecting the days of the week on which it applies. Times have a granularity of 10 minutes.
- An indication of whether "holiday" operation begins at midnight or at the end of an "on" interval that ends after midnight.
- An indication of what is to happen on the three different types of holiday date (see next section). The options are "Treat as regular day" (self-explanatory), "No Access" (schedule is "off" all day"), "Access always" (schedule is "on" all day") or a reference to another schedule. The last option allows a different non-trivial schedule to be used on holiday dates.
There are 3 different "types" of holiday. These have no inherent meaning. Holiday dates are defined on the "Holiday/Daylight Savings" screen. The first two are reserved as dates on which the clocks change. The rest can be used to assign one of the 3 available holiday types to a day of the year. Each can be a specific date, or a reference such as "first Monday of the month". Holiday dates do not have a year attached, so dates such as Easter which vary will have to be adjusted each year. However most bank holidays use a "Nth Monday in month" approach so will normally not need to be changed. The Christmas closing dates may need minor adjustment depending on how Christmas Day falls in the week.
The holiday types have been used as follows:
- Days such as bank holidays which are treated as if they were a Sunday for both access control and the intruder alarm system.
- Temporarily in use for advance programming of an "early opening" request for the main entrance.
- Used for programming special access to the main entrance by changing to a different schedule. All schedules other than the main entrance door schedule have "Treat as regular day" for holiday type 3.
If holiday type 2 is brought into use, care should be taken to ensure that the correct behaviour is selected for every extant schedule, since it is impossible to determine in advance what the requirement might be.
The use of the holiday mechanism to program ad hoc unlocking is not particularly flexible, since there are only 3 holiday types available. There is no way to have a 1-off event which automatically disappears after it happens; if not removed a holiday will repeat every year. Given that some manual intervention is invariably required after the event, ad hoc access to an area may be more conveniently achieved by altering its schedule and putting it back afterwards, rather than using holiday dates. The selection of time intervals by days of the week is useful here.
The south courtyard doors were added to the system in 2011 and the north in 2012.
For the south courtyard, the most southerly pair of doors has a reader both sides and appears on the system as a perfectly ordinary In/Out door ("Out" is towards the courtyard, "In" is back to the Street). The other three pairs of doors have no readers and therefore no door controller; their locking state is instead controlled by an "output point" in the alarm section of the configuration.
For the north courtyard, each pair of doors is a separate In/Out door with its own pair of card readers.
The same schedule ("Courtyard Doors") is used to control the locking of all of the doors, but using two different mechanisms. The card reader doors have the schedule attached in the ordinary way; the non-reader doors are done by attaching the same schedule to control the state of the output point "Courtyard Door Open".
Capabilities have been arranged to minimise the risk that somebody will not be able to return to the Street from the Courtyard.
The doors are normally unlocked during the working week in summer on a schedule which is active from Monday morning to mid afternoon Friday. Building Services are supposed to check at the locking up time that anybody still outside has a card to get back in. In winter, or on very windy days, the doors can be locked by amending the schedule (most easily by unticking the Monday start and accepting the warning that the schedule has no active time slots).
Car Park Barrier
Entrance to the car park is controlled by a rising barrier. It appears on the system as two different "doors" with different properties.
Door 23, labelled "Car Park Barrier" is the one operated by the card reader. The transition from "locked" to the "unlocked" state triggers the barrier to drop, and it rises again when a car has driven over it regardless of the locked/unlocked state. Therefore it only makes sense to configure this circuit for momentary operation.
Door 24, labelled "Car Park Barrier Key" is intended for manual control of the barrier. In the "unlocked" state, the barrier drops and remains down. When put back to "locked", the barrier rises immediately. It is not known whether there is an interlock to prevent it rising if a vehicle is crossing at the time.
In addition to the card reader, a general purpose input point is configured to operate door 23. The input point is presented in GN19 and connected via the structured wiring system to a board in GN09 which is driven by an experimental numberplate recognition system. If this system malfunctions it can be disconnected and the Verex system will operate normally.
The car park exit barrier is opened by a vehicle detection loop and is not under any kind of remote control; it exists only to prevent the exit lane being used for unauthorised entrance.
Archiving the event log
By default the event log grows without limit. There is a facility to archive the event log under "Database Management". Since the archives are written by the Verex Director process, they cannot easily be sent directly to the filer. Instead the archive is done to a local directory C:\Verex_Temp and then copied to \\filer\groups\admin\verex\archive using a user account on the server machine. Any date period can be archived; so far it has been done by calendar year.
After archiving, the file should be re-imported. This adds the data back into the database, but in a separate "archive" table. The advantage of this is that the data is available for querying if needed, but does not slow down routine operations.
The Operator Log and the Communications log can simply be purged from time to time, keeping only the last few months.