CTS-350X (v2)

28 Mbps Max / 10 Mbps Typical

Centralised (Max): 28 Mbps from radar to Track Engine & 28 Mbps from Track Engine to Client Application

Centralised (Typical): 10 Mbps from radar to Track Engine & 10 Mbps from Track Engine to Client Application

1. The CTS V2 radar has a 25cm resolution, so the amount of data generated for the same range is less. The CTS V4 has a 17cm resolution and therefore has increased detection performance.

CTS-350X (v4)

38 Mbps Max / 15 Mbps Typical

0.5 - 1 Mbps Typical

On-board (Typical): 15 Mbps from radar to Client Application

Centralised (Max): 38 Mbps from radar to Track Engine & 38 Mbps from Track Engine to Client Application

Centralised (Typical): 15 Mbps from radar to Track Engine & 15 Mbps from Track Engine to Client Application

1. Planning requirements should be based on typical figures. Max is included to illustrate worst case.

2. Note that on-board commissioning requirements do not include a max figure - this is because the on-board processing is designed to work with a typical data load - not the maximum.

3. The on-board bandwidth for normal operation is entirely dependent on the number of vehicles being tracked. If the road is busy this figure can reach 1 Mbps or in some extreme cases, exceed this for short periods.

4. Note that for centralised processing, the bandwidth requirement from the Track Engine to the Client Application is normally within the same data centre and therefore may only impact the local network switch or LAN.

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).

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.

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 

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 

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