Industrial source models
Source inventories, tag and event definitions, identifiers, timestamps, and links to production context.
Service
Industrial data and analytics
Build the data path behind production reporting.
GTMI builds data models, pipelines, reporting stores and dashboards for manufacturing. We use approved source access and agree each measure with its operational owner.
For operations, engineering, and data teams planning production reporting or an industrial analytics pipeline.
- 01
Capture
PLC, SCADA, MES, historian
- 02
Model
Events, tags, metric definitions
- 03
Serve
APIs and reporting stores
- 04
Use
Dashboards and shift reports
Reporting access follows source-system approvals. Operational owners approve the metric and the decisions made from it.
What GTMI takes on
Data engineering and reporting in one scope
GTMI can build the data pipeline and reporting application, or deliver a specific part of that work. Work includes source inventories, tag and event models, transport, storage, calculations, access rules, and dashboard implementation. We first identify who or what will use the data and what the report must show. That determines the sources and interfaces needed within your manufacturing environment.
Pipelines and storage
MQTT and API transport, historian patterns, time-series data, and PostgreSQL reporting stores.
Reporting applications
Grafana and Power BI views for agreed production measures, OEE, shift reporting, and operational review.
Data operations
Data-quality checks, approved consumer access, refresh expectations, and documented support ownership.
The delivery work
Model the data and define its ownership
Source work can span PLC, SCADA, MES, historian, ERP, quality, and manual inputs. GTMI documents event meaning, timestamps, identifiers, calculation rules, and handling of missing or corrected records. We review metric definitions with the client’s operational owners and document the data-quality checks and responsibilities alongside the model. The resulting definition gives production reviewers a consistent basis for selecting the figures to use, comparing shifts and investigating a disputed result.
Implement a supported reporting path
Delivery can use MQTT or API transport, historian and time-series patterns, PostgreSQL stores, and Grafana or Power BI, depending on the environment. For execution systems, the design uses approved read-only interfaces or API boundaries and separate analytics storage where required. GTMI implements the agreed pipeline and reporting views, checks them against source records, and documents refresh, access, and support responsibilities.
Data and reporting deliverables
- Source inventory and approved metric definitions
- Tag, event, and reporting data models
- Implemented pipelines and consumer access
- Reporting views and operating documentation
Platforms
- PostgreSQL
- TimescaleDB
- InfluxDB
- MQTT
- Grafana
- Power BI
Illustrative example: fictional manufacturing data
A shift that crosses midnight
The fictional assembly shift runs from 22:00 on 3 April to 06:00 on 4 April 2030, in UTC. A calendar-day extract misses the first two hours. A different exclusion rule changes the denominator again.
| Definition field | Reporting rule |
|---|---|
| Measure | Availability: running minutes divided by scheduled production minutes |
| Source | Fictional timestamped line stop/start events and the shift schedule |
| Shift boundary | 22:00 to 06:00 UTC; assign the full shift to its start date |
| Exclusions | Subtract the scheduled 30-minute break from production minutes |
| Corrections | Retain the original event, reason and reviewer for each correction; mark reports provisional until reviewed |
| Sample status | No missing events or corrections in this dataset; assumes the line ran between the listed stops |
| Event | UTC interval | Minutes |
|---|---|---|
| 1. Unplanned stop | 22:40 to 23:05 | 25 |
| 2. Planned break | 00:15 to 00:45 | 30 |
| 3. Unplanned stop | 02:10 to 02:30 | 20 |
| View | Running / denominator | Availability |
|---|---|---|
| Full shift, planned break excluded | 405 / 450 min | 90.0% |
| Calendar extract, 00:00 to 06:00 only | 310 / 330 min | 93.9% |
| Full shift, planned break included | 405 / 480 min | 84.4% |
The full shift contains 480 minutes, a 30-minute planned break and 45 minutes of unplanned stops: 405 running minutes. The differences above come from the time boundary and exclusion rule, not changed production. An agreed definition tells the review team which figure to use. This is availability only, not a complete OEE calculation.
Working together
Data design and reporting delivery
Start with an architecture package for a reporting requirement, or scope the implementation of its pipeline and views.
Data architecture package
Source, model, transport, and access design for a named reporting requirement, ready for client review.
Pipeline and reporting delivery
Implementation of the agreed data path and reporting views, including checks against the sources and handover.
Where next
Define the engagement
Scope the reporting or data work
Tell us which decision the report supports and why the figures are disputed or difficult to use. We can identify whether the work belongs in source capture, the measure definition, the pipeline or the reporting view. Existing reports and source samples can follow later.