ClearWay™ System Design

Introduction

This section covers the key components of the ClearWay™ 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: . 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 Model

Centralised Processing

On-board Processing

Commissioning Requirements

Notes

Radar Model

Centralised Processing

On-board Processing

Commissioning Requirements

Notes

CTS-350X (v2)

28 Mbps Max / 10 Mbps Typical

N/A

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.

Software Components

The following components make up the Witness™ software:

Component

Description

Installation

Required

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

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 and Database Services.

Simple System Design

Summary

Features

Notes

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

 

Summary

Features

Notes

Features

Notes

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 

Large System Design

Summary

Features

Notes

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


Safety is everything.