G-SIM

Plan your G-SIM configuration carefully, as so many things impact each other. How you group your sites and what your camera naming and labeling conventions are can have a huge impact on maintenance.

Sites

Choose a site naming convention that makes sense. Remember: sites are physical or logical groupings. If in your installation it makes sense to have a site per building, then do that. Another installation may group all the buildings in one site, the perimeter in another, and entrances/ exits to the facility in yet another. Or it could be low, medium, and high security areas.

Camera Grouping

Again, think carefully about how you will group the cameras, and remember that cameras get their display attributes from the camera group they belong to. Usual methods of grouping the cameras are via camera type (fixed, PTZ, movement sensing, ...) or camera function (stairwell, exit, ...).

Camera Names and Labels

This is an extremely important decision. Most people would want a simple increasing number sequence for cameras, perhaps with a type or location prefix. The only time this works is if nothing changes — ever. Of course, this is hardly ever the case.

IMPORTANT: Cameras IDs must be uniquely assigned and cannot have duplicates.

The above means that in conjunction with your customer, you need to come up with a camera naming and labeling convention that is flexible enough to allow for additions or removals (or reassigning) of cameras. Every suggested convention should be tested against at least the following criteria:

  • Does it make sense to the customer?
  • Can it cope with camera additions or deletions?
  • If strict adherence to the convention is required, could it ever be necessary to change existing camera mappings? This could become a lot of work - think of all the alarm and map linking that has been done. Also think about alarm and event history in the data base.

You also need to think of how things are defined at the GeViSoft, GeViScope, G-Core and Health Agent levels.

Alarms

It is important not only to decide on which event should create an alarm, but to decide on other factors as well:

  • Should the alarm be generated by GeViSoft or by the NVR itself?
  • Is it a derived alarm, where two or more events are taken to create a new one? E.g. an activity detection alarm from a camera is within 2 seconds of a microwave barrier being breached. Together they constitute a major alarm, whereas each by itself may only indicate a spurious trigger.
  • Are the alarms designated as auto pop-up really that important? If they happen too often, then they cannot be that critical (and these are only to be used for the most absolutely critical alarms). Should auto pop-up alarms use separate window (tab view mode), or use viewers on the screen layout (viewer group mode)?
  • Which alarms are more events than alarms? In other words, they need to be recorded for auditing purposes only — "live" investigation by an operator would be a waste of time. Make sure that these are then never displayed.
  • Some alarms are hybrid in the sense that though they may not require action by operators, it is nevertheless good for the operators to know about them. In such a case, mark them as auto-expiry after a pre-defined period.

These are just a few of the things to think about. As you gain experience with G-SIM, you will develop your own list to use at installations and during maintenance.

Rights and Restrictions

In a role-based security model as G-SIM has, it is vital to define and configure rights and restrictions correctly. Be careful to have the correct definitions for privileges, permission, and restrictions. Getting them wrong is a sure way of having complete chaos at go-live.

Pay special attention to the differences between restricting and allowing access, particularly the implications on what happens when new kit is added.

Maps

Maps are absolutely core to the functioning of G-SIM, showing operators where something is taking place. Here we look at maps in broad brush strokes only.

A good approach is a combination of geo-accurate (GIS), fixed and variable scale maps.

A good example is the railways. The distance between stations is simply too great to use fixed scale maps, nor is it useful to indicate the route that the railway takes. What is important when looking at an overview of a rail network is to know that station A and B are connected, and that if something is wrong at either end or in between, you will be able to represent it. Once you are at station level, though, it may be important to use a fixed scale map. In other words, use the correct map for the correct purpose.

Once you have this understanding, you need to decide on at least the following:

  • How large the maps should be in the display (impacting your templates).
  • What is the color scheme? We once encountered a graphic designer who saw no problem with orange grass and green water!
  • Will they be based on CAD drawings, on aerial photos, or a combination?
  • Who will supply the maps?
  • Who will pay for the extra work to prepare the maps?
  • Which graphics formats will be used?
  • Investigate the map sizes, looking particularly at the difference between a compressed map image (e.g. a PNG file) and its uncompressed size in RAM, as the difference can be vast. As an example, a random photograph in my collection is 1.25 MB on disc, but has a memory size of 22.9 MB. All map images would need to be investigated, and edited (color and resolution reduction, for example) before they are used.
  • Which information needs to be shown, and which not?

  • If your maps should cover city or even country level and cameras have geo-coordinates, then GIS maps are good choice. Think carefully about choosing of map provider, it’s tariff plans and map using mode.

Lastly, time the whole process of going from nothing to a completed map for a few of them. There is always more work to this than anticipated.

Remote Consoles

Make sure that your customer understands the power of Remote Consoles (ReCons). Show them different use cases and work through these with them until they themselves come up with how they will be using Remote Consoles in their particular installation. Once you are at this point, the following can be addressed:

  • Use the output from your work on rights to decide who will have access to which Remote Consoles.
  • Where will the Remote Consoles be placed, and what will be displayed on them?

Video Walls

It is important that your customer understands that though Remote Consoles and video walls are related, their purposes and their use are often very different. A Remote Consoles can have, say, four screens, while with a video wall you also need to consider layout of the screens relative to each other; how many Remote Consoles you are going to need to make up a video wall; which graphics cards to use, etc.

Remember that you need not only display security related information. You can use video capture from a machine running a software-only NVR to capture a news or stock feed to display in a foyer, for example (or some sporting event). Just factor in all the costs!