Sea360® System Design
- Charlotte Dakin-Norris
Introduction
This section covers the key components of the Sea360® system - hardware and software - and how they interact with each other across a network. It also covers topics such as configuration options, sensor network requirements and options for resilience.
Contents
Network Bandwidth
Specific bandwidth requirements are covered in more detail below, and in the Hardware Prerequisites page:Hardware Prerequisites. However, sufficient capacity must be allowed for the radar data and this must be based on an absolute allocation of bandwidth, not an average. The data from a radar will continuously stream at the specified data rate, it will not vary. Taking into account the radar data and any other data being transmitted on the network (i.e. CCTV video), we would recommend that this does not exceed 70% of the available bandwidth. We would not recommend a data network with less than 1Gbps bandwidth.
Radar Series | Centralised Processing | On-Board Processing | Commissioning Requirements | Notes |
|---|---|---|---|---|
HDR 100 | 2 - 22 Mbps | 0.5 - 1 Mbps | On-board (Typical): 2 - 22 Mbps from radar to Client Application Centralised (Max): 22 Mbps from radar to Track Engine & 22 Mbps from Track Engine to Client Application |
|
HDR 200 | 10 - 38 Mbps | N/A | Centralised (Max): 38 Mbps from radar to Track Engine & 38 Mbps from Track Engine to Client Application |
|
HDR 300 | 47 - 90 Mbps | N/A | Centralised (Max): 90 Mbps from radar to Track Engine & 90 Mbps from Track Engine to Client Application |
|
Software Components
The following components make up the Witness™ software:
Component | Description | Installation | Required |
|---|---|---|---|
Management Server Service | Provides central management and messaging services including integration with 3rd party systems. | One instance per server and a total of 2 for the whole system. | At least 1x Management Server (Max of 2x). |
Camera Controller Service | Provides dynamic management of cameras, including integration with 3rd party systems. | One instance per server. | At least 1x Management Server on which the Camera Controller Service can be co-located. |
Track Engine Service | Provides dynamic management of trackers, either on the radar or running on Track Engine. | One instance per server. No limit on installations . | At least 1x Track Engine. |
Helvellyn Client Application | Provides an administrative and configuration client for the system. | One instance per PC. No limit on the number of clients. | At least 1x UI. |
Mongo Database Service | Provides data storage for the configuration and recording facilities for alarms, tracks and logging. | One instance per server. One or more installations per system. | At least 1x database server. |
For simple designs, one server can suffice to support the Management Server, Camera Controller and Database Services.
Simple System Design
Features | Notes |
|---|---|
Simple setup | Only 2x systems to setup |
Low infrastructure cost | Only 2x servers (or virtual systems) are required |
Limited capacity | A single track engine can only support ~8 radar |
Expandable | Additional track engines and radar can be added easily |
No redundancy | Redundant servers and software can be added later if required |
Medium System Design
Simple setup | Limited number of servers and only a single database server to configure |
Low infrastructure cost | Not fully redundant so fewer hardware costs |
Improved capacity | Additional track engines provide support for more radar. A dedicated database server allows for greater loads and longer data collection periods |
Expandable | Additional track engines and radar can be added easily |
Limited redundancy | Separating management of radar on to different track engines provides some redundancy. This configuration can lose a track engine yet remain functional, albeit with less operational radar |
The Camera Controller does not need to go on the same system as the Management Server but, practically, this is the easiest option, as the load of the Camera Controller is not high, and therefore can be co-located with the Management Server.
Large System Design
Features | Notes |
|---|---|
More complex setup | More hardware and more demanding network requirements increase the overall system complexity |
Higher infrastructure cost | Fully redundant design requires additional server hardware |
Improved capacity | Additional track engines provide support for more radar. A dedicated database cluster allows for very large loads and longer data collection periods |
Greater expandability | Additional track engines and radar can be added easily and the database cluster ensures the system can deal with large capacities |
Full redundancy | With duplicate management servers, self-healing track engines and a database cluster, this design is very resilient with no single point of failure |
Related Information
-
ClearWay™ System Design (Witness 4.0)
-
Software Prerequisites (Witness 4.0)
-
Installing the Software (Witness 4.0)
-
Installation Guide (Witness 4.0)
-
ClearWay ™ (Products)
-
Earthing Point - HDR 200/300 Series (Products)
-
ICD-001 System Profile Command (Witness 4.0)
-
Rules (Witness 4.0)
-
Breach Lines (Witness 4.0)
-
Entity Timeouts (Witness 4.0)
-
UI Recording (Witness 4.0)
-
AdvanceGuard® System Design (Witness 4.0)
-
System Design (Witness 4.0)
-
AdvanceGuard® Alarm Panel (Witness 4.0)
-
ClearWay™ Alarm Panel (Witness 4.0)