Industrial App Development

Manufacturing plants, energy operators, and heavy industry companies building equipment monitoring platforms, predictive maintenance systems, and industrial workflow software need engineering teams who understand both the real-time telemetry architecture and the operational safety requirements these environments impose. Scrums.com provides dedicated software engineering teams for industrial software development, deploying production-ready systems with IoT sensor pipelines, OPC-UA and MQTT integration, append-only equipment event logs, and the anomaly detection infrastructure that drives predictive maintenance.

IoT Sensor Ingestion, Equipment Telemetry, and Edge Architecture

Industrial platforms ingest high-frequency data from heterogeneous sensor types (temperature, pressure, vibration, flow rate, current draw, torque) across hundreds or thousands of assets simultaneously. The ingestion architecture must handle burst volumes, device outages, and partial data without dropping readings.

The sensor data model uses a telemetry_readings table: asset_id, sensor_id, reading_type (TEMPERATURE | PRESSURE | VIBRATION_RMS | CURRENT_AMPS | FLOW_RATE | RPM | TORQUE), reading_value, unit, recorded_at (sensor timestamp), ingested_at (server timestamp), and source_protocol (MQTT | OPC_UA | MODBUS | HTTP). The recorded_at/ingested_at separation handles edge buffering: sensors in remote locations batch readings during connectivity outages and upload in bulk; queries always filter on recorded_at.

Deduplication uses a UNIQUE constraint on (asset_id, sensor_id, recorded_at) with ON CONFLICT DO NOTHING. The telemetry_readings table is append-only. For continuous high-frequency streams (vibration at 1kHz+, current draw at 100Hz), raw data writes to a TimescaleDB hypertable with BRIN indexes and time-based compression. Downsampled materialised views serve dashboards; raw data is retained at full resolution for root cause analysis.

Edge computing is supported through an edge_devices table: device_id, location_id, firmware_version, connectivity_status, last_heartbeat_at, and a buffer_config (JSONB for store-and-forward settings). Edge devices write to a local buffer and upload to an edge_upload_queue on reconnect. The upload queue consumer is idempotent on (device_id, batch_id).

The current_sensor_status materialised view holds one row per sensor with the latest reading_value, recorded_at, and data_freshness_status (LIVE | STALE | OFFLINE based on configurable thresholds). This drives the live equipment dashboard without querying the telemetry_readings table directly.

Predictive Maintenance, Anomaly Detection, and Work Order Workflow

Industrial platforms derive their operational value from detecting equipment degradation before failure. The anomaly detection and maintenance workflow architecture determines whether the platform prevents downtime or just records it.

Anomaly detection uses a detection_rules table: rule_id, asset_id (or asset_type for fleet-wide rules), sensor_id, detection_method (THRESHOLD | RATE_OF_CHANGE | Z_SCORE | CUSUM | FFT_PEAK), threshold_config (JSONB), severity (CRITICAL | MAJOR | MINOR), and a flag to suppress alerts during planned maintenance windows. Rules are stored as config, not code: new detection methods add a strategy implementation; the rule row controls which strategy fires.

Every telemetry reading evaluated against detection_rules writes a detection_evaluations row regardless of outcome: a full audit trail of every anomaly check. When a rule fires, an anomaly_events row is created: asset_id, rule_id, triggering_reading_id, detected_value, severity, detected_at, and a status machine (OPEN / ACKNOWLEDGED / UNDER_INVESTIGATION / RESOLVED | FALSE_POSITIVE). Status transitions write anomaly_status_events rows.

Work orders are generated automatically from anomaly_events at or above a configurable severity threshold. The work_orders table: work_order_id, asset_id, trigger_type (ANOMALY | SCHEDULED | MANUAL | INSPECTION_FINDING), priority (P1 | P2 | P3 | P4), status machine (CREATED / ASSIGNED / IN_PROGRESS / PARTS_REQUIRED / ON_HOLD / COMPLETED | CANCELLED), assigned_technician_id, due_at, and a work_order_events child table. Work orders are never deleted; cancellation uses the CANCELLED terminal state.

Planned maintenance schedules use a maintenance_schedules table: trigger_type (CALENDAR | RUNTIME_HOURS | CYCLE_COUNT | CONDITION_BASED) and interval parameters. A scheduler job checks due maintenance against asset runtime hours (aggregated from telemetry_readings) and calendar, creating work_orders for due items. Maintenance completion writes a maintenance_completions row with technician_id, completed_at, duration_minutes, parts_used (JSONB), and next_due_at computed from completion timestamp.

Industrial apps like these are built and delivered by dedicated engineering teams through our mobile app development service.

Asset Management, OEE Analytics, and Production Reporting

Asset management covers the full equipment lifecycle from installation through decommissioning. Each asset record carries a typed status (OPERATIONAL, DEGRADED, UNDER_MAINTENANCE, or DECOMMISSIONED) and status transitions are recorded in an append-only asset_status_events table with the triggering work order reference, responsible technician, and timestamp. DEGRADED is entered automatically when predictive maintenance anomaly scores breach a configured threshold; UNDER_MAINTENANCE is entered when a work order is opened against the asset; OPERATIONAL is restored when the work order is closed with a resolution outcome. Assets cannot be moved directly from UNDER_MAINTENANCE to DECOMMISSIONED without an intermediate operational period or an explicit decommission approval event, enforced by transition validation logic.

Overall Equipment Effectiveness (OEE) is calculated as Availability multiplied by Performance multiplied by Quality. Availability is derived from uptime events vs planned production hours; Performance from actual output rate vs designed output rate; Quality from accepted units vs total units produced. These source values are recorded as append-only rows in their respective event tables. The oee_by_asset_by_shift materialised view aggregates them per asset per shift period and is refreshed at shift close. OEE scores are never stored as mutable values: the materialised view is always recomputable from source events, so a correction to any source row (for example, reclassifying a downtime event from PLANNED to UNPLANNED) regenerates the correct OEE figure automatically.

Shift reporting uses a shift_reports materialised view that is auto-generated at shift close. Each report captures total production volume, total downtime duration, downtime breakdown by category (mechanical, electrical, material, quality, planned), OEE score, top fault codes, and energy consumption per asset. Shift supervisors receive the report via notification without manual assembly. Historical shift reports are immutable snapshots; corrections are applied to source event tables and the view is refreshed, not by editing the report record directly.

Production reporting materialised views extend beyond the shift to support daily, weekly, and monthly aggregations. A production_summary_by_line_by_day view supports operations management dashboards, while a quality_defect_pareto_by_week view ranks defect codes by frequency and supports root-cause prioritisation. All views are driven from the same append-only source tables, ensuring that dashboard figures and export reports are always consistent.

Safety Inspection Systems, Permit-to-Work, and SCADA Integration

Safety inspection workflows capture structured checklists against assets, locations, and work orders. Each inspections record carries a state (SCHEDULED, IN_PROGRESS, COMPLETED, or FAILED) and each line item in inspection_items carries an outcome of PASS, FAIL, N/A, or ACTION_REQUIRED. FAIL and ACTION_REQUIRED outcomes automatically create corrective_action_requests linked to the inspection item, the responsible team, and a due date derived from the severity configuration table. Corrective action status flows through OPEN, IN_PROGRESS, VERIFIED, and CLOSED states, with each transition appended to a corrective_action_events log. Inspections cannot be marked COMPLETED while any ACTION_REQUIRED item has an open corrective action, enforced at the application boundary.

Permit-to-Work (PTW) controls access to hazardous work areas and energy isolation points. Permits follow a state machine: REQUESTED, UNDER_REVIEW, APPROVED, ACTIVE, SUSPENDED, CLOSED, or REJECTED. The critical constraint is that ACTIVE is only reachable from APPROVED: this transition is enforced via a status_transitions configuration table in the database, not in application code, meaning the gate cannot be bypassed by a code path that skips the approval step. Energy isolation steps for each permit are recorded in an energy_isolation_log table as immutable rows; isolation cannot be marked as removed until the permit reaches SUSPENDED or CLOSED, preventing re-energisation of equipment while a permit is active.

SCADA integration connects the platform to plant control systems via OPC-UA. A dedicated OPC-UA adapter reads tag values from SCADA servers on a configurable polling interval and writes normalised readings to a scada_read_log table. Alarms raised by SCADA systems are captured in scada_alarm_events with alarm type, severity, tag reference, and acknowledgement status. A scada_correlation_map table links SCADA tag identifiers to platform asset identifiers, allowing alarm events to be automatically associated with the correct asset record and trigger work order creation when alarm severity and duration thresholds are met. Adding a new SCADA data source requires a new adapter configuration entry, not a code change, keeping OT and IT integration manageable as plant topology evolves.

Regulatory and compliance reporting for industrial environments requires evidence that safety controls were active and effective. The append-only structure of inspection records, corrective action logs, permit state events, energy isolation logs, and SCADA alarm events provides a complete, tamper-evident audit trail. Compliance reports can be generated directly from these source tables without relying on summary values that could be edited after the fact.