The number of radar required, and the radar model, is usually based on a recommendation from Navtech Radar or one of our partners. Although we can make approximate estimates based on maps and drawings, an accurate site design can only be made once a site survey has been completed. We use an online planning tool for the initial estimations and these designs can be shared with customers to visualise how a site would be covered with different radar models.

A Track Engine can support up to ~ 8 radar, so technically the minimum depends on the number of radar. Even for fewer than 8 radar, a second Track Engine can be included in the system as backup for automatic failover.

The system only requires a single Management Server. This handles all the core system functions, such as configuration management, inter-module communication and user management. An additional Management Server can also be included for redundancy with automatic failover.

In theory this is unlimited, but in practice there are limitations based on the total number of connections supported by the Management Server and how easy it is to manage the Track Engines within the Topology manager in the User Interface. Existing production environments are using up to 30x Track Engines.

This is a complex question and is affected by the following factors:

• Processing Power: the tracker uses sophisticated algorithms that are processor and memory intensive.

• On-board or Local Processing: the on-board processing module on the CTS350-X and HDR100 series radar can handle the tracking on the radar. This removes a lot of the load from the Track Engine and therefore allows the Track Engine to support more radar.

• Network Capacity: if lots of radars have to send their raw network data to the same server platform, then it may exceed the default capacity of the hardware.

• Radar Range: radars with greater range will generate more data and therefore more network traffic and will require more processing power to analyse all of the data.

• Size of Tracking Area and Total No. of Targets per Minute: busy sites with lots of movement, i.e. a highway, will generate lots of targets for tracking. This will put a heavy load on the tracker, and therefore greater demands on the Track Engine.

As a guideline, when using local trackers (i.e. all trackers running on the Track Engine) we recommend a CPU core and 64MB of RAM per radar. So typically this means a Track Engine can support between 4-8 radar. depending on the model. When using on-board (i.e. the tracker is running on each radar) then the Track Engine can support between 10-20 radar.

The number of cameras supported is theoretically unlimited and is in no way related to the number of radars. Practically, there is a maximum number that the Camera Controller can manage and this is largely dependent on how busy each of the cameras will be. For planning purposes, we would recommend working on a maximum of 80 cameras. Other factors do apply, such as the bandwidth and speed required for telemetry and the bandwidth required for the video feeds.

Track Engines output track data. This data is only generated when the tracker is following a target, the amount of data per track is very small (approximately 112 bytes per track) so the total requirement is entirely dependent on the number of targets being tracked. However, Track Engines consume raw data from the radar. The amount of data generated by each radar is dependent on its range. For planning purposes, we recommend visiting the relevant System Design pages for AdvanceGuard® and ClearWay™.

Certain modes on the radar can significantly reduce network bandwidth but use of these settings is governed by specific requirements for each site

The bandwidth for other modules is governed by the number of targets being tracked. This will increase for busy sites and with each additional radar. The amount of data being sent per target is very small so overall network bandwidth is modest. There is also a certain amount of regular health and status data being sent between modules. Typically, the impact of this data can be ignored unless the system is utilising a large number of radars (e.g. greater than 20).

Yes. Each module can be installed on separate servers connected via Ethernet or all on the same hardware. Each module will provide a load on the server but this will be largely dependent on how busy the overall system is.

The key considerations are as follows:  

• Disk space and access speed: the speed of the internal database will be affected by hard disk speed. Unlike many database applications, Witness will typically write more information to the database, rather than read. This means good disk speed is important.

• Memory (RAM): the system holds quite a lot of temporary data in memory and also the database server requires additional RAM. The more load on the system, the greater the memory use.

• Network Bandwidth: the system deals primarily with target/track data and therefore the bandwidth requirements are not large - the amount of data per track is very small (approximately 112 bytes per track) so the total requirement is entirely dependent on the number of targets being tracked. Obviously, as the number of radars attached to the system increases, so does the overall number of tracks. The amount of data generated by each radar is also dependent on its range, and though certain modes on the radar can significantly reduce network bandwidth, use of these settings is governed by specific requirements for each site. We would recommend a RAID sub-system for speed and redundancy. In addition, the size of the storage will dictate how much data can be stored. The level at which space is consumed is entirely dependent on the number tracks going into the database. We would also recommend at least 512MB RAM per Management Server.

Yes, with the exception of the User Interface. The User Interface requires a capable 3D accelerated graphics card which generally excludes the use of virtualised platforms. The software has been tested extensively with Microsoft Hyper-V and we also have several large production systems running on VMWare.

Yes, all modules including the User Interface will work on the server OS, but as already mentioned it does require a capable graphics card and the overall responsiveness of User Interface may be affected if the server is prioritising background processes. The Management Server, Track Engine and Camera Controller are ideally suited to the server platform.

Witness™ does not have an SDK for integrating code directly into a third party application. However, it does have an API which is capable of receiving and generating data as XML over Ethernet. This enables third party software to receive data about tracks and alarms, and also to provide commands to affect the behaviour of the software. There is an Interface Control Document (ICD) which outlines the data reports and command instructions.

At the moment we have built-in support for the Axis range of encoders. This enables the software to support PTZ control of older analogue cameras over Ethernet. Witness V4.0 no longer support direct serial connections to cameras (RS422/485). 

Yes. The software will work on a peer-peer network, as well as a network domain. The User Interface will utilise the underlying Windows security model and will choose the domain model if the user selects the Single Sign On (SSO) option at login. The Management Server must be configured to support Active Directory integration before users attempt to use SSO. 

Yes. There are a number of external sensors which are supported along with the use of simple static sensors such as PIR. Static sensors can be connected to Witness via the Advantech Digital IO hardware (e.g. the ADAM 6060). Witness™ can incorporate these inputs into the rule engine allowing alarms to be raised and cameras automatically controlled.

AdvanceGuard can support up to 100+, depending on the total number of targets being tracked at any one time. ClearWay can support up to 300+ radar with certain limitations on displaying real time target data.

A standard installation can support at 30+ UI clients.

In certain circumstances – yes. Typically, we do not recommend using wireless as a means of connecting the radar to Track Engines. Other aspects of the software can be connected wirelessly, e.g. the User Interface or the Camera Controller connecting to a Management Server. Using wireless technology exposes a system to a range of issues which a normal wired network would not experience. This varies from bandwidth and latency problems through to interference. Navtech does not provide any direct support for wireless networks, so we recommend using a wireless specialist for installation and support.