Aware Mate FAQ

Aware Mate supports active bridge watchkeeping using an on-board camera and local processing. It monitors defined visual indicators related to presence, attention and alertness, provides local advisory prompts, and produces aggregated information for operational review. It supports the bridge team alongside existing equipment and procedures. 

It means the unit of review is the watchkeeping process, not the individual. Aware Mate helps operators understand whether the bridge watch is being maintained in practice: coverage, sustained attention-drift exposure, local recovery, occupancy context where enabled, and review trends. Signals require human interpretation inside operator procedures.

No. The system is designed as safety support, not surveillance. Processing is on board by default. Aware Mate does not perform identity recognition or emotion recognition, and raw video is not sent ship-to-shore by default. Reporting should be governed by operator SOP, crew notice, role-based access and defined retention.

No. Aware Mate provides advisory signals from sustained visual patterns, such as prolonged eye closure, gaze direction and head position. These observations do not establish a medical condition or prove whether an officer understands the navigational situation. A face or eyes becoming unavailable to the camera is not, by itself, proof that the officer has left the bridge. 

BNWAS is a valuable baseline for absence, non-response or failure to acknowledge. It confirms interaction, not sustained alertness. Aware Mate is upstream: it provides local advisory prompts when sustained watchkeeping-state signals suggest the watch may be weakening. It does not replace BNWAS, mandatory equipment, lookout obligations or bridge procedures.

Video is analysed on board; the core function does not require cloud processing. Where reporting is enabled, routine off-vessel reports use aggregated operational data, without crew identifiers or exact event times. Any optional video recording, additional export or remote access must be separately agreed and documented, together with retention periods and access permissions, in the deployment documentation. 

No. Aware Mate is not designed for face recognition, identity matching or crew identification.

No. It does not perform emotion recognition or workplace emotion inference.

No. Aware Mate uses video analytics only. Audio analytics are part of the separate Helm Order Monitor product line.

Where reporting is enabled, shore receives aggregated summaries such as monitoring coverage, alert trends, absence flags and technical health information, according to the agreed reporting scope. Raw video is not sent ashore by default. Aggregation and the absence of identity recognition do not guarantee anonymity: watch schedules or other information may allow indirect identification. Access and use must therefore remain within the agreed privacy boundaries. 

A typical pilot follows: scope → install → crew briefing → calibration → active operation → close-out decision. The purpose is to validate operational fit: bridge layout, lighting, local alert behaviour, nuisance burden, crew acceptance, privacy/SOP fit and usefulness of aggregate outputs.

Typical pilot KPIs include uptime, detection coverage, alert latency, false-critical alerts, nuisance burden, crew acceptance, commissioning pass/fail, and reporting usefulness. These support pilot readiness and operational-fit assessment, not casualty-reduction proof.

Not at this stage. Operational bridge testing supports pilot readiness and integration diligence. Casualty-reduction or claims-reduction claims require a longer and broader evidence base.

Nuisance burden is a core pilot metric. Commissioning includes camera placement, lighting checks, calibration and threshold tuning. Alerts are graded and advisory, with pause/mute/override handled under operator SOP.

Where permitted and approved, Aware Mate can provide optional dry-contact or alert-chain outputs. It should not be presented as replacing BNWAS or modifying mandatory equipment without owner, service, class or flag review where required.

The HMI is designed with reference to maritime display and alerting principles, including clear status indication, colour discipline and consistent alert handling. Deployment-specific alignment depends on final configuration and any integration with shipboard alerting.

Yes, subject to bridge layout and operating profile. Inland use is especially relevant where long routine stretches, night navigation, bridge transits, locks, confined waters or track-pilot / route-guidance operation create monitoring-heavy watchkeeping.

The deployment should be explained before active use. Crew should receive a simple trust briefing: what the system does, what it does not do, what shore does not see, how local prompts work, and how pause/mute/override and feedback are handled.