Data Analysis Agent

Role

The Data Analysis Agent is a Phase 1 specialist responsible for retrieving and analysing historical BWTS sensor data from PostgreSQL. When the IOT Manager dispatches a trend-analysis task, this agent runs structured queries against telemetry tables, identifies patterns, correlates parameters, and returns a self-contained report — ready for the Manager’s cross-referencing step.

Caution

BWTS operates only during port calls (10–36 hours) with days or weeks idle between sessions.

Never use fixed time windows like “last 24 hours” or “last 7 days” — the system may have been completely offline during that period, producing misleading gaps. Always run recon first to discover actual operating sessions before any analysis.

---

Analysis Workflow

1. Recon — Discover Sessions

   Run the recon analysis to identify all operating sessions in the database. This returns session start/end timestamps, durations, and gaps. Every subsequent analysis uses these session boundaries as its time window.

2. Point-in-Time Checks

   Run snapshot analyses (system_snapshot, uv_compliance) against the most recent data point within the current session to establish the system’s present state.

3. Trend Analysis — Current Session

   Run trend and health analyses (uv_trend, power_headroom, lamp_health, filter_health, flow_analysis, thermal_status) scoped to the current operating session identified by recon. Look for drift, spikes, oscillations, and threshold breaches.

4. Compare to Previous Session

   Run baseline_comparison to compare the current session’s metrics against the previous session. Identify degradation, improvement, or sudden shifts between sessions that may indicate maintenance events or progressive wear.

5. Synthesise

   Combine all analysis outputs into the final DATA ANALYSIS REPORT. Cross-reference correlated parameters (e.g., UV intensity dropping while flow rate increases), flag data gaps, and summarise findings with supporting evidence.

---

Pre-Built Analyses

The primary tool bwts_analysis.py ships with 13 pre-built analyses, each tuned for a specific aspect of BWTS operations.

#	Analysis	Description
1	recon	Discover operating sessions — start/end timestamps, durations, idle gaps. Must run first.
2	system_snapshot	Point-in-time snapshot of all key parameters at the most recent reading
3	uv_compliance	Check whether UV intensity meets IMO D-2 compliance thresholds
4	uv_trend	UV intensity trend over the current session — detect drift, decay, or sudden drops
5	power_headroom	Compare current UV lamp power draw against rated capacity — remaining headroom percentage
6	lamp_health	Per-lamp status: intensity, hours run, power draw, failure indicators
7	filter_health	Filter differential pressure trend — detect clogging, backwash effectiveness
8	flow_analysis	Flow rate stability, pump cycling patterns, valve position correlation
9	thermal_status	Temperature readings across the treatment train — detect overheating or cooling failures
10	cip_status	Clean-In-Place cycle history — last CIP timestamp, duration, chemical concentration
11	alert_patterns	Historical alert frequency and clustering — recurring alarms, storm detection
12	correlated_scan	Multi-parameter correlation — identify parameters that move together during anomalies
13	baseline_comparison	Compare current session metrics against the previous session to detect degradation

Tip

You do not need to run all 13 analyses for every alert. The IOT Manager’s task will specify which parameters are relevant. However, recon is always the first step — no exceptions.

---

Output Format

Every Data Analysis Agent response follows the DATA ANALYSIS REPORT structure:

Report Sections

Section	Content
Operation Context	Vessel, equipment tag, session boundaries from recon, operating mode
Trend	Time-series summary for the flagged parameter — direction, rate of change, threshold proximity
Lamp Status	Per-lamp intensity, hours, power draw — only if UV-related alert
Correlated Observations	Other parameters that moved in sync with the flagged parameter
Baseline	Comparison against previous session — better, worse, or unchanged
CIP Status	Last CIP cycle details — relevant for fouling or efficiency alerts
Operating Mode	Whether the system was in Treatment, Standby, CIP, or Bypass during the anomaly
Evidence Summary	Bullet-point list of findings with timestamps and values
Data Gaps	Any missing readings, sensor dropouts, or incomplete sessions

Example Snippet

=== DATA ANALYSIS REPORT ===

OPERATION CONTEXT
  Vessel: MT Oceanic Star
  Equipment: BWTS-UV-003
  Session: 2026-05-18 06:12 → 2026-05-18 18:44 (12h 32m)
  Mode: Treatment

TREND — UV_INTENSITY
  Start of session: 42.8 mJ/cm²
  End of session:   31.2 mJ/cm²
  Direction: Declining (-27%)
  Rate: -0.93 mJ/cm²/hour
  Threshold (40 mJ/cm²) breached at: 2026-05-18 09:17

CORRELATED OBSERVATIONS
  - FLOW_RATE increased 18% over same window (inverse correlation)
  - LAMP_3_POWER steady — no electrical fault detected

EVIDENCE SUMMARY
  • UV intensity declined 27% over 12.5 hours
  • Flow rate increase suggests higher turbidity reducing UV transmission
  • No lamp failure — all 4 lamps drawing rated power
  • CIP last run 28 days ago (due at 30 days)

---

Tools

graph LR
    DA["Data Analysis\nAgent"] --> BW["bwts_analysis.py\nPrimary — 13 analyses"]
    DA --> DQ["db_query.py\nRaw SQL fallback"]

    BW --> PG[("PostgreSQL")]
    DQ --> PG

    subgraph "Tables"
        T1["bwts_iot_telemetry\n103 columns, ALL-CAPS"]
        T2["bwts_iot_predictions\ncamelCase columns"]
    end

    PG --- T1
    PG --- T2

    style DA fill:#1a1a2e,stroke:#e94560,stroke-width:3px,color:#fff
    style BW fill:#16213e,stroke:#0f3460,stroke-width:2px,color:#fff
    style DQ fill:#16213e,stroke:#0f3460,stroke-width:2px,color:#fff
    style PG fill:#0d1b2a,stroke:#1b9aaa,stroke-width:2px,color:#fff
    style T1 fill:#0d1b2a,stroke:#1b9aaa,stroke-width:1px,color:#fff
    style T2 fill:#0d1b2a,stroke:#1b9aaa,stroke-width:1px,color:#fff

Tool	Purpose
bwts_analysis.py	Primary analysis tool. Accepts an analysis name (e.g., recon, uv_trend) and optional parameters. Returns structured output.
db_query.py	Raw SQL fallback for ad-hoc queries not covered by the 13 pre-built analyses. Use sparingly.

Note

Column naming matters. The bwts_iot_telemetry table uses ALL-CAPS column names (e.g., UV_INTENSITY, FLOW_RATE, FILTER_DP). The bwts_iot_predictions table uses camelCase (e.g., predictedValue, confidenceScore). Mixing conventions will produce empty result sets with no error.

---

What It Does NOT Do

No Maintenance Records

Maintenance history, work orders, and service schedules belong to the PMS Agent. This agent has no access to maintenance tables.

No Manual Search

Equipment manual lookups and documented-cause searches are the Manual Agent’s responsibility. This agent works exclusively with sensor data.

No Report Generation

Produces a structured text report for the IOT Manager’s synthesis step. Never generates HTML, never formats client-facing reports, and never sends emails.

No Email or Notifications

Has no communication tools. Writes its findings to the task system only. All external communication flows through the Report Agent.

Note

The Data Analysis Agent’s boundary is data in, structured findings out. It reads from PostgreSQL and writes to the LifeOSAI task system. It touches no other systems.