Coastlines · PHAROS
Where every buoy goes, and what it really covers.
PHAROS plans a barrier of sensor buoys before anything goes in the water. It clips each footprint against the seabed, scores the barrier as a probability, and reports how it holds on its weak crossings.
Who it is for
For those who have to defend a layout.
Coastal and port authorities and operators of maritime infrastructure, including dual-use buyers. A range map draws a circle around each sensor. The seabed does not behave that way, and a barrier that looks continuous on paper usually is not. PHAROS puts that argument on the planning table, before the purchase.
What it does
What the calculation engine does.
- 01
Terrain-masked coverage
The depth profile is traced along every direction from each node, and the usable footprint is returned as a polygon, with the nominal range kept next to it.
Implemented in the engine - 02
Radar and sonar together
The model counts water as protected where the radar and the sonar footprints intersect. That is its criterion, chosen for the objective of a contact that can be resolved and acted on. Overlap is reported separately, as redundancy.
Implemented in the engine - 03
Detection probability
Computed per crossing track, across every sensor that sees it, over a sampled set of crossings. The headline figure is the fifth percentile of detection probability over those crossings, not the mean. The weakest sampled crossing is a different figure and is reported separately.
Implemented in the engine - 04
Layout and gap list
A sector and a number of nodes in. A layout, the list of gaps and the reasoning for each, out.
Implemented in the engine - 05
Barrier over time
Sea-state forecast and availability objectives for aids to navigation, so the barrier is assessed as it changes.
Implemented in the engine - 06
Contacts and commands
Vessel identification data separates a detection from an alarm. Commands to a node pass through a role-gated queue and count only when the node acknowledges.
Implemented in the engine
Dual use
Export control comes first.
PHAROS is dual-use software subject to export control review. We establish the end user and the jurisdiction before a technical conversation goes further, and we decline the enquiries we cannot place. The position is set out on the trust page.
A configuration and what the engine returns
The planner prototype, on synthetic data.
The problem
A planning team has a sector, a sensor model and a number of nodes, and has to say whether the barrier holds.
The screen
The sector with the nodes by state, the deployment panel, and the rule checks: continuity, terrain masking, radar and sonar pairing, navigable corridor.
What the user does
Chooses the sector, the sensor model and the pattern, places a batch, then asks the solver for a proposal.
The result, and its limits
A layout, the checks that pass or fail and the gaps. Every node and every figure in this view is synthetic. It shows how the engine reasons, not a real barrier.
The metric and its assumptions
The four modules, and where each one stands
Implemented in the engine Prototype
The calculation engine is implemented. The planner interface is a prototype on synthetic data.
Implemented in the engine Integration at the customer
In the engine: attribution of contacts with vessel identification data, and the role-gated command queue. Not in the engine: the connection to a customer's command system. That is an integration built with each customer, and none is shown here.
Implemented in the engine Direction
In the engine: the assessments, meaning availability objectives for aids to navigation and the barrier over a sea-state forecast. Not built: routing a maintenance vessel from those assessments. That is a direction of development.
Prototype Direction
In the prototype: a log of the actions taken in the planner. Not built: a tamper-evident register of decisions, for example one chained by hashes. That is a direction of development, and nothing here should be read as saying it exists.
In daily work
How a planning team uses it.
- 01
Define
The sector, the sensors available and the traffic that matters.
- 02
Compute
Coverage, gaps and detection probability for the proposed layout.
- 03
Compare
Alternative layouts, including a node added where the sampled crossings are weakest.
- 04
Defend
The result, with its assumptions on screen, goes into the planning file.
Data and integrations
What it needs in order to work.
Results and limits
What you get, and where it stops.
What you get
- Coverage the seabed actually allows
- Detection probability at the fifth percentile, with the weakest sampled crossing reported separately
- A gap list produced with the layout
- Assumptions shown with every result
Limits
- It is a planning tool. It does not detect anything by itself
- Results are estimates and depend on the depth data and the sensor specifications provided
- Every figure on this site comes from synthetic data
- Availability is subject to export control review
What is real on this page
Implemented means the function exists and runs in the product. It does not mean it has been validated in a customer's operation. Where something is a prototype, a demonstration on synthetic data, an integration done at the customer or a direction of development, it is labelled as such.
The calculation engine is built and covered by its own test suites.
The planner interface is an interactive prototype running on synthetic data. Figures shown publicly are planning estimates.
Nothing operational, no customer data and no real positions are published anywhere.
Start an evaluation
Name the sector and what has to cross it.
Give us a stretch of coast, the sensors available to you and the traffic you care about. We tell you what the engine would compute and what data it needs.
Enquiries are subject to export control review. We establish the end user and the jurisdiction first.