Receivers, command messages and underwater signals need distinct proof

In September 30 reporting from REPMUS, Lee Willett describes a Royal Navy experiment that separates dropping a sonobuoy from receiving it. TKMS Sonartech Atlas’s Sonix VHF receiver/processor package was fitted to Tekever’s AR5 drone and ZeroUSV’s Oceanus 17 surface craft. The navy also bought a second system for fitting to its platforms.

The receiver hosts do not yet contain the whole acoustic chain. Processing ran ashore. The stated aim for the following 12 months was onboard AI processing to reduce communications load and delay. Kelluu’s airship attended REPMUS but did not carry Sonix; integration was planned, with altitude intended to extend line-of-sight buoy reception.

For Canadian acoustic suppliers and maritime-autonomy integrators, this older trial is a useful architecture comparison: buoy placement, receiver altitude, processing location and coalition reporting are separate design choices. A remotely operated receiving platform does not establish autonomous acoustic classification, and a planned persistent airship fit is different from a demonstrated one.

Nine command systems shared the same operational-picture feed during REPMUS, according to Lee Willett’s September 25 briefing report. A frigate defended by up to 30 uncrewed craft faced more than 60 attacking surface and air vehicles. The exercise director attributed the common architecture to STANAG 4817. The outcome of the attack was not disclosed; both sides had to broadcast positions and were separated for safety. These conditions support an interoperability experiment, not an assessment of survival against an opaque adversary.

An earlier NATO public procurement Q&A gives a more concrete integration example. For IFIB 26-07, answer 106 specifies JSON messages sent by HTTP POST to a NATO web service over a VPN; answer 80 says the telemetry scheme is considered final for promulgation and will not evolve for that contract. More detail follows award. Those statements describe that implementation, not a universal transport mandate or a certified current edition for every STANAG 4817 system.

The distinction is useful for Canadian developers: ask which message set, tasking functions, authority handoffs and tested profile the customer needs. A common map feed, vehicle control and autonomous mission execution are different claims. A standard identifier alone does not answer them.

NATO’s 2017 description of JANUS is precise about its role: a common digital acoustic signal lets underwater devices contact one another, announce their presence and organize a network. Portugal’s November 2022 official ratification order identifies STANAG 4748 as the Digital Underwater Signalling Standard for Network Node Discovery and Interoperability, ANEP 87 EditionA. These are historical function and identifier records; they do not establish the applicable 2026 edition or guarantee a product’s conformance.

The shore connection is a second handoff. NATO describes surface gateway buoys using radio links to support vessels or satellites, while underwater traffic travels acoustically. That explains why an allied sensing chain can require both an underwater common language and a separate reporting/tasking architecture above the water.

For Canadian ocean-technology teams, the engineering question is what crosses each boundary: an announcement of presence, a contact report, a mission task or a high-volume sensor record. JANUS compatibility can help heterogeneous equipment find a common acoustic starting point. It does not by itself demonstrate broadband performance, every mission service or an end-to-end operational network.