Abstract
A system is disclosed for evaluating offshore survey operational signals and procedure tolerances into a shared, multi-state operational condition propagated consistently across command centre, procedures, logbook, maps, notifications and reporting surfaces. In one embodiment telemetry, environmental measurements, equipment states, procedure tolerance limits, departmental rules and manual inputs are evaluated by a condition engine; breached tolerances raise blocked states globally and per department; acknowledgement records visibility without clearing underlying conditions; and indeterminate handling distinguishes unknown from normal.
Technical field. Operational decision-support software for offshore survey campaigns, in particular evaluation of live signals and procedure tolerances into a propagated operational condition state.
Technical Design Rationale
Live operational inputs and procedure tolerances are conventionally checked in separate tools, producing inconsistent readiness judgements across departments.
The disclosed method addresses the technical problem of evaluating heterogeneous signals and machine-readable procedure tolerances into one explainable condition state that propagates consistently and distinguishes unknown from normal.
Background and operational problem
Offshore operations depend on concurrent inputs — weather, vessel motion, positioning quality, sensor health, equipment state, and procedure tolerances — observed in separate systems.
A technical problem exists: how to evaluate these inputs and procedure tolerances into one explainable, time-stamped operational condition consistent across every surface, with explicit handling when inputs are missing or stale.
Inventive contribution
The inventive contribution is integrating heterogeneous-signal evaluation, machine-readable procedure tolerances, departmental scoping, acknowledge-not-override semantics, and blocked-state propagation into one consistent, explainable, auditable operational condition.
System overview
In one embodiment the system comprises a signal intake; a tolerance rule set bound to planned activities; a condition evaluator producing states with contributing causes and freshness; a propagation layer distributing state to consuming surfaces; and an acknowledgement layer recording visibility without suppressing underlying conditions.
Components
- Procedure tolerance
- A machine-readable limit attached to a planned activity — weather window, motion limit, positioning quality, or equipment constraint.
- Operational signals
- Environmental, vessel, navigation, sensor, equipment, and manual inputs feeding evaluation.
- Condition state model
- Ordered states such as normal, caution, critical, and indeterminate with explicit stale and offline handling.
- Blocked state
- Global or department-scoped state raised when a tolerance is breached or cannot be evaluated.
- Acknowledgement
- Records that a condition has been seen; does not clear the underlying state.
- Actual-versus-plan record
- Retained comparison of observed conditions against planned tolerances.
Data-model shape
- Tolerance
- { activity ref, limit kind, predicate, severity, owning department(s) }
- Signal record
- { source kind, value / state, observed-at, freshness }
- Condition-state record
- { context, state, causes[], last-evaluated, freshness }
- Blocked-state record
- { context, blocked flag, breached tolerances[], scope }
- Acknowledgement
- { condition ref, actor, acknowledged-at }
Workflow
- 01
Define tolerances
Procedure tolerances are defined as machine-readable constraints bound to activities.
- 02
Intake signals
Operational signals arrive from telemetry, equipment, and manual entry.
- 03
Evaluate
The engine computes condition state with causes and freshness.
- 04
Raise blocked state
Breached or non-evaluable tolerances raise blocked states globally or per department.
- 05
Propagate
Current state distributes to command centre, procedures, logbook, maps, and reports.
- 06
Retain comparison
Actual-versus-plan comparison is retained for review.
UI / operational behaviour
In one embodiment tolerances appear alongside planned activities; a global condition indicator sits in the application shell; per-department indicators show scoped state; detail panels list contributing causes and freshness; and blocked states render prominently with breached tolerances visible.
State machine (high level)
evaluateLimits(activity, conditions):
bound = tolerancesFor(activity)
breached = []; indeterminate = []
for t in bound:
v = conditions.value(t.inputRef)
if v is missing or stale: indeterminate += t; continue
if breaches(t, v): breached += t
if breached.notEmpty: return BLOCKED(breached)
if indeterminate.notEmpty: return INDETERMINATE(indeterminate)
return CLEARIllustrative high-level pseudo-code only. This is not production source code and does not disclose implementation-specific algorithms, schemas, thresholds, credentials, customer data, or deployment details.
A tolerance that cannot be evaluated produces an explicit indeterminate state rather than a clear one.
Alternative embodiments and variants
Tolerance kinds
- Wind, wave, swell, current, visibility
- Vessel roll, pitch, heave
- Positioning quality
- Sensor and inertial quality
- Launch-and-recovery windows
- Client-defined limits
Scope
- Global blocked state
- Department-specific state
- Activity-level
Output surfaces
- Command centre
- Procedure timeline
- Logbook
- Map views
- Daily progress report
- Notification panel
Example offshore use cases
- A planned ROV activity carries a sea-state tolerance; as conditions exceed the limit, department and global blocked states raise before launch.
- A positioning-quality tolerance breach blocks only the survey department while other activities remain clear.
- A telemetry feed goes offline; affected conditions become indeterminate rather than appearing normal.
Benefits and technical effect
The system connects planned tolerances to live operational state; provides one explainable condition across surfaces; distinguishes unknown from normal; and retains actual-versus-plan records. HSE-related constraints may appear as one tolerance category among others.
Implementation details intentionally omitted
This disclosure is intentionally limited to system concepts, workflows, data-model shapes, state machines, UI behaviours, and alternative embodiments. Source code, exact algorithms, credentials, deployment configuration, customer-specific procedures, real project data, private reports, generative instruction workflows, and commercial terms are intentionally omitted and retained separately as confidential implementation material.
Commercial relevance
Operators gain a single operational-awareness layer across departments with earlier visibility of degraded and blocking conditions. Live readings require verification against procedure tolerances.
Frequently asked questions
How does the system handle missing or stale data?
Missing, stale or offline inputs degrade the condition to an explicit indeterminate state rather than being presented as normal.
Does acknowledging a condition clear it?
No. Acknowledgement records that a condition has been seen and understood; it does not clear or suppress the underlying state.