What Does Industrial Data Platform Development Include?
Industrial data platform development includes connecting your data sources, normalizing them into one schema, governing who can see what, and exposing the result to the people and tools that query it. For a maritime fleet, that means OEM telemetry, maintenance logs, manuals, and warranty and procurement records end up in a structure software can query. This is the work we do at SailPlan, on top of the systems an operator already runs.
The Core Work, Stage by Stage
Most of the effort sits in the middle of the project, not at the ends. Collecting data is a solved problem for most fleets. Making it mean the same thing across sources is where projects stall.
| Stage | What gets done | Fleet example |
|---|---|---|
| Source inventory | List every system that holds data, who owns it, and how it labels things | Telemetry portals, maintenance spreadsheets, manuals on shared drives, warranty files |
| Connection | Pull data from each source without replacing it | Read-only feeds from OEM telemetry platforms |
| Normalization | Map signal names, units and identifiers to shared fields | Two makers report the same temperature under different names and units |
| Relationships | Link records to permanent asset identifiers | A component tied to its maintenance history and vendor terms |
| Access and governance | Decide which authorized tools and people may query what | A technician sees procedures; finance sees cost |
| Consumption | Let dashboards, models and agents query the one structure | Anomaly checks and cost reports reading the same fields |
The Layers a Platform Has to Cover
Published architecture guidance splits the problem into layers. HiveMQ's guide to industrial IoT connectivity, data architecture and platform decisions argues that all three matter and that mistakes in the first two undermine the third. A layered IoT platform architecture description adds the device, communication, data processing, platform and application layers. A published industrial data platform reference architecture covers the same ground: ingest equipment and enterprise data, store it, contextualize it, then build datasets that dashboards and machine learning can use.
Those references describe building blocks. They do not say what a chief engineer or operations manager needs to ask of the result, and that question should shape the scope.
Where the Schema Fits, and Why It Is the Hard Part
A scanned manual or a CSV export is digitized, but it was made for a person to read. Machine-readable data has normalized identifiers, typed relationships and a structure software can query. Platform development that stops at storage leaves you with digitized data and a pile of one-off parsers.
The schema is where we spend our effort. It maps each manufacturer's signal names, units and identifiers to shared fields, then relates telemetry to procedures, financials, warranty terms, personnel and procurement records. We cover the design principles in our piece on a unified data schema for industrial AI, and the groundwork of naming equipment consistently in our guide to equipment taxonomy for maintenance data.
What Scope Usually Gets Left Out
Protocols and shipboard standards
Decide early which protocols the equipment speaks and which standards describe the data. We compare them in NMEA 2000 versus Modbus versus OPC UA on a vessel, and in our look at what the ISO 19848 shipboard data standard defines and does not define. A standard can name a signal without telling you how it relates to a work order or a warranty term.
Metadata and quality-control records
Data without a description cannot be reused. The U.S. Integrated Ocean Observing System makes this point in its data standards and requirements: descriptive information about datasets, sensors, platforms and quality-control procedures is essential for long-term usability and reuse, and providers should follow the FAIR principles of find, access, interoperate and reuse. That guidance is written for ocean observing, not fleet operations, but the lesson carries over. Record what each signal measures, its unit and how it was checked.
Institutional knowledge
Much of what keeps equipment running sits in senior technicians' memory and in undocumented fixes. Development should include a way to capture those fixes and link them to the equipment they apply to, so the next technician can search them at the machine.
Data Platform, Data Lake or Historian?
A lake holds raw data in its original formats and defers the question of meaning. We explain the difference in what an industrial data platform is compared with a data lake. A historian stores time-series values well but does not relate them to the rest of the operation, which we cover in data historian versus industrial data platform. An operational data store consolidates records, and we weigh it against a schema in operational data store versus unified schema. The choice depends on the questions you need answered across sources.
What We Build, and What We Do Not
- We build a unified, machine-readable data model that sits on top of your existing systems. It does not replace OEM platforms, historians or maintenance software.
- The model is model-agnostic. Translation work is done once, so new AI models, agents and dashboards connect to the same structure and you avoid paying the integration tax again.
- It supports routine answers to hard questions: searchable technician knowledge, anomaly detection across manufacturers, tracking against requirements, warranty and vendor coverage, root-cause tracing and true cost per operating hour.
- Our published work and deployments are in maritime. Our earlier emissions monitoring platform now belongs to Verret Marine Consulting, so questions about it go there.
FAQ
Does platform development mean replacing our current systems?
No. Your telemetry portals, maintenance software and warranty records stay where they are. Development adds a normalized layer above them, so a query can span sources without a custom connector for each.
Do we need to pick an AI vendor first?
No. A model-agnostic schema means the structure is built once and any authorized model, agent or dashboard can read it. Choosing a tool later does not reopen the data work.
What is the difference between a data engineer and a data scientist here?
A data engineer builds the connections, the schema and the access rules. A data scientist builds analyses and models on top. If the engineering is weak, the scientist spends time cleaning signal names instead of finding anomalies.
What should we define before development starts?
Write down the questions the platform must answer, such as which warranty claims are open or what a given asset costs per operating hour. Each question names the records that must be linked and the identifiers that must stay permanent, so the list decides what gets modeled first.
Related resources
- One Schema for Telemetry, Procedures, Financials and Institutional Knowledge: A Unified Data Schema for Industrial AI
- Equipment Taxonomy for Maintenance Data: A Practical Guide
- NMEA 2000 vs Modbus vs OPC UA: What Each Does on a Vessel
- ISO 19848 Shipboard Data Standard: What It Defines and Doesn't
- Industrial Data Platform vs Data Lake: What's the Difference, and How Do You Choose for Vessel Operations Data?
- What a Data Historian Can't Tell You About Your Fleet's True Cost
- Operational Data Stores vs. Unified Schemas: What Industrial Fleets Actually Need
- Model Context Protocol and Industrial Data Explained
- How Do You Track Warranty Claims Across Vendors? What a Unified Data Model Needs to Include
SailPlan builds the machine-readable data model that makes every AI tool in your stack actually work. Request a demo to see it in action.