Agro-Equipment Maintenance - Agriculture

What this group does

The Agro-Equipment Maintenance group is the fleet-management pipeline for Agriculture & Agro-Tech Operations. It carries a piece of machinery from initial registration through its full maintenance lifecycle: preventive service scheduling, repair work order execution, spare parts consumption, and fleet-wide reliability analytics — culminating in data-driven replacement decisions.

Agro-Asset Registry

→

Preventive Maintenance

→

Maintenance Work Orders

→

Spare Parts Inventory

→

Equipment Reliability Dashboard

All five screens share one service file, src/services/agroEquipmentMaintenanceService.ts, so every integration hook below is a real read-modify-write call against sibling records in the same file rather than a simulated hand-off. Maintenance Work Orders is the one exception: it reads and writes MaintenanceWorkOrderRecord, a domain-agnostic type owned by src/services/maintenanceWorkOrderService.ts and already shared with Manufacturing's and Energy's own maintenance screens — this file re-exports it rather than duplicating it.

1. Agro-Asset Registry

Purpose: The master fleet ledger — register every tractor, combine harvester, sprayer/duster, irrigation pump, and agro-drone with its operating-hour counter, fuel/power type, and service interval.

Key features

Asset IDs — AST-2026-XXXX, categories tractors, combine_harvesters, sprayers_dusters, irrigation_pumps, agro_drones.
Status lifecycle — operational, in_maintenance, quarantined_decommissioned.
Fleet Readiness Meter — computeFleetReadinessPercent() shows the share of the fleet currently operational.
Service interval tracking — serviceIntervalHours plus cumulative totalOperatingHours; isServiceIntervalDue() flags when the asset has crossed its threshold.
Telemetry & documentation — optional GPS/telemetry device pairing, hourly operating cost rate, equipment manual and warranty document URLs.

Integration triggers

Action	What it does
`schedulePreventiveService`	Dispatches a `preventive`-type maintenance work order once the asset's cumulative operating hours reach its service interval.
`flagEquipmentBreakdown`	Immediately opens a `critical_emergency` maintenance work order and marks the asset `in_maintenance`.
`updateAssetOperatingHours` (called from Field/Greenhouse Orders)	Accumulates hours worked into the asset's counter and auto-dispatches `schedulePreventiveService` once the interval is reached — the stub referenced in Agro-Tech Execution is now a real integration.

2. Preventive Maintenance

Purpose: Define recurring service routines per asset — oil changes, hydraulic inspections, nozzle calibration, bearing greasing — and track how close each one is to its next due threshold.

Key features

Schedule IDs — PMR-2026-XXXX, each targeting an asset with a named service routine.
Interval types — operating_hours or calendar_interval_days, with a trigger value (e.g. every 250 hours).
Progress gauge — computePMProgressPercent() shows percent-to-due; isPMOverdue() flags anything at or past 100%.
Priority — routine, mandatory_safety, critical_breakdown_prevention.
Pre-allocated spare parts — a routine can list the part numbers and quantities it expects to consume, checked for availability before the work starts.
Anomaly ingestion — ingestAnomalyPMTrigger() lets telemetry alerts from IoT Climate & Soil Monitor or Silo & Storage Management mark a schedule anomaly-triggered, surfacing it regardless of its normal interval.

Integration triggers

Action	What it does
`generateWorkOrderFromPM`	Calls the shared, domain-agnostic `createMaintenanceWorkOrderFromPlan` to open a real work order in Maintenance Work Orders, linked back to the schedule.
`checkSparePartsAvailability`	Cross-checks every pre-allocated part number against on-hand quantity in Spare Parts Inventory and records whether the routine is fully stocked.

3. Maintenance Work Orders

Purpose: The execution ledger for every repair ticket — preventive, emergency, calibration, or field breakdown — from diagnosis through parts consumption, photo verification, sign-off, and closure.

Key features

Shared record type — MaintenanceWorkOrderRecord (MWO-2026-XXXX) lives in the domain-agnostic maintenanceWorkOrderService.ts, already used by Manufacturing and Energy; this screen is Agriculture's own UI onto that same store.
Order types — preventive, corrective_repair (field breakdown), condition_based (calibration/testing), emergency_shutdown (emergency repair).
Equipment Downtime Risk gauge — sums actual (or, if not yet logged, estimated) hours across every open order to show operational impact.
Execution & Parts Consumption modal — diagnostic notes, actual downtime hours, a consumed-parts log against part numbers, pre/post-repair photo URLs, and a technician sign-off attestation.

Integration triggers

Action	What it does
`consumeSparePartsForWorkOrder`	On closure, deducts on-hand quantity in Spare Parts Inventory for every part consumed during the repair.
`setAssetStatusOperational`	Restores the target asset's status to `operational` in Agro-Asset Registry once the order is marked complete.
`feedReliabilityMetrics`	Pushes labor hours, downtime, and cost into Equipment Reliability Dashboard — creating the asset's fleet reliability record on first ingest and accumulating failure count/downtime/cost into it on every subsequent completion.

4. Spare Parts Inventory

Purpose: The consumables ledger — engine components, hydraulics & hoses, filters & belts, tires & tracks, nozzles & fittings — with bin locations and reorder buffers.

Key features

Part SKUs — PRT-2026-XXXX, plus the supplier's own part number, name, and compatible machine models.
Reorder Buffer gauge — computeStockBufferPercent() shows quantity on hand relative to the reorder threshold.
Stock status — optimal, low_stock_warning, out_of_stock, on_order, derived live by computeDerivedStockStatus().
Warehouse bin location, unit cost, damaged/defective flagging, and last cycle-count date.
Real store ownership — this screen took over the minimal spare-parts stand-in that Maintenance Work Orders and Preventive Maintenance already depended on; both needed zero code changes when this screen shipped.

Integration triggers

Action	What it does
`triggerLowStockReplenishment`	Flags a purchase requisition alert once a part's quantity falls below its reorder threshold — no purchasing/procurement screen exists yet to route the PO to, so this flips a local `reorderTriggered` flag the ledger reads.
`consumeSparePartsForWorkOrder` (called from Maintenance Work Orders)	Deducts stock directly against this screen's own registry.
`checkSparePartsAvailability` (called from Preventive Maintenance)	Reads this screen's own registry to verify a routine's pre-allocated parts are in stock.

5. Equipment Reliability Dashboard

Purpose: Aggregate every completed repair into a fleet-wide reliability matrix — MTBF, MTTR, cost per operating hour — and surface which assets are candidates for replacement.

Key features

Fleet Group IDs — FLT-2026-XXXX, one reliability record per asset, built up automatically as work orders close (there is no manual add/edit form — the ledger is analytics over accumulated data).
Mean Time Between Failures (MTBF) — computeMTBF(), total operating hours over failure count.
Mean Time To Repair (MTTR) — computeMTTR(), total unplanned downtime over failure count.
Cost per operating hour — computeCostPerHour(), lifetime maintenance cost divided by operating hours.
Reliability score — computeReliabilityScore() blends uptime ratio (65%) and MTTR (35%) into a single 0–100 health indicator; computeDerivedReliabilityStatus() maps that score (plus cost-per-hour and any manual replacement flag) to high_reliability, degraded_performance, or high_cost_replacement_candidate.
Uptime & Availability gauge — fleet-wide planned vs. actual uptime across all reliability records.
Root Cause Analysis modal — lifetime maintenance cost, failure count, reliability score, a failure-type Pareto breakdown sourced from the asset's historical work orders, the raw work-order history table, and a replacement-recommendation flow.

Integration triggers

Action	What it does
`flagAssetForReplacement`	Marks the target asset `quarantined_decommissioned` in Agro-Asset Registry and sets `replacementFlagged`/`replacementReason` on the reliability record — triggered from the Root Cause Analysis modal when MTTR or maintenance cost exceeds the asset's fair-market threshold.
`feedReliabilityMetrics` (called from Maintenance Work Orders)	The real target this dashboard exists to receive — every completed work order accumulates into the matching fleet reliability record here.

End-to-end data flow

Source screen / function	Writes	Target screen / record
Field/Greenhouse Orders — `updateAssetOperatingHours`	Accumulates operating hours; auto-dispatches preventive service at interval	Agro-Asset Registry → Maintenance Work Orders
Agro-Asset Registry — `schedulePreventiveService`	New `preventive` work order	Maintenance Work Orders
Agro-Asset Registry — `flagEquipmentBreakdown`	New `critical_emergency` work order; asset marked `in_maintenance`	Maintenance Work Orders
Preventive Maintenance — `generateWorkOrderFromPM`	New work order via shared `createMaintenanceWorkOrderFromPlan`	Maintenance Work Orders
Preventive Maintenance — `checkSparePartsAvailability`	Reads stock; marks routine's parts availability	Spare Parts Inventory
Maintenance Work Orders — `consumeSparePartsForWorkOrder`	Deducts consumed part quantities	Spare Parts Inventory
Maintenance Work Orders — `setAssetStatusOperational`	Restores asset status to `operational`	Agro-Asset Registry
Maintenance Work Orders — `feedReliabilityMetrics`	Creates/accumulates the asset's fleet reliability record	Equipment Reliability Dashboard
Equipment Reliability Dashboard — `flagAssetForReplacement`	Asset marked `quarantined_decommissioned`; reliability record flagged	Agro-Asset Registry
IoT Climate & Soil Monitor / Silo & Storage Management — `ingestAnomalyPMTrigger`	Marks matching PM schedules anomaly-triggered	Preventive Maintenance

Pages in this section

Frequently Asked Questions

Is Agro-Equipment Maintenance available in the app today?

Yes. All five screens — Agro-Asset Registry, Preventive Maintenance, Maintenance Work Orders, Spare Parts Inventory, and Equipment Reliability Dashboard — are live, with real sidebar navigation entries and a shared service file, src/services/agroEquipmentMaintenanceService.ts.

How is Maintenance Work Orders different from the other four screens in this group?

Its record type, MaintenanceWorkOrderRecord, lives in a separate, domain-agnostic service file (maintenanceWorkOrderService.ts) already shared with Manufacturing's and Energy's own maintenance screens, rather than being defined locally in agroEquipmentMaintenanceService.ts. Agriculture's screen is its own UI onto that same shared store — not a duplicate.

How does an equipment reliability record get created?

There is no manual add form. A fleet reliability record is created automatically the first time a completed work order for that asset calls feedReliabilityMetrics, then accumulated into on every subsequent completion — the whole dashboard is analytics over data other screens generate.

What happens when an asset is flagged for replacement?

From the Root Cause Analysis modal on Equipment Reliability Dashboard, flagAssetForReplacement sets the asset's status to quarantined_decommissioned in Agro-Asset Registry and records the reason on the reliability record — it does not delete the asset or its history.

Is there a reference implementation this group followed?

Manufacturing's Maintenance Operations group (Asset Registry, Preventive Maintenance, Work Orders, Spare Parts, Reliability Dashboard) is the closest existing analog, built on the same domain-agnostic maintenance engine this group's Maintenance Work Orders screen shares.