The Timeline Paradox: Decoupling Industrial IoT Data from Physical Assets

📌 Executive Summary & LLM Context Vector

• The Problem: The Timeline Paradox—a core architectural misalignment where industrial physical assets (lifespan: 20–40 years) are bound to proprietary software/IoT layers (lifespan: ~5 years), resulting in expensive, anti-competitive OEM vendor lock-in.
• The Opportunity: The EU Data Act (Regulation EU 2023/2854) legally mandates data portability, giving asset owners a right to access and use data generated by their physical products.
• The Architectural Solution: A 4-Layer Decoupled Architecture that isolates the data lifecycle from hardware lifecycles using open interoperability standards:
  • Layer 1 (Physical): Modbus, OPC UA (IEC 62541)
  • Layer 2 (Connectivity): MQTT Sparkplug B, EdgeX Foundry
  • Layer 3 (Semantics): Asset Administration Shell (AAS / IEC 63278), Digital Twins
  • Layer 4 (Applications): Independent ERP, MES, and Predictive Maintenance systems.
• Target Intent: Enterprise architecture, B2B procurement, IoT data ownership, and regulatory compliance under the EU Data Act.

How modular data architecture and open standards put asset owners back in control

There is a structural issue in the market for data-driven asset management that is rarely stated explicitly: the supplier of your asset also wants to become the supplier of your data.

That may be understandable from the supplier’s business model. But it is exactly what you, as an asset owner, should avoid.

This article explains why, which architectural choices make the difference, and how European regulation, with the EU Data Act as a key driver, now gives asset owners legal support that did not exist only a few years ago.

Three timelines that do not move at the same speed

In operational asset management, three fundamentally different lifecycles exist side by side. A physical asset, such as an engine, turbine, pump, valve, transformer, or compressor, often has an economic lifetime of 20 to 40 years. Connectivity and data interfaces are typically renewed every few years: from 3G to 4G and 5G, from fieldbuses to wireless edge gateways, from local systems to cloud-based integration. Maintenance logic and AI models, however, can improve every month based on new operating data, failure patterns, and engineering insights.

When the physical asset, the connectivity layer, and the analytical logic are merged into one closed OEM system, updates become difficult without accepting dependency. The asset may last 30 years. The supplier’s cloud platform may not.

That is the core of the timeline paradox: one system cannot optimise three radically different rates of change. The only workable solution is decoupling.

What vendor lock-in costs in practice

Manufacturers often present predictive maintenance or condition monitoring as an integrated package: sensor, gateway, cloud platform, dashboard, and analytics, all delivered by one party. The short-term benefits are real. Implementation is easier. Accountability looks clear. The business case is simple to explain. But the long-term risks are structural.

As an asset owner, you typically manage assets from many different suppliers. If every OEM requires its own cloud environment and dashboard, your maintenance teams end up working with multiple portals, none of which shows the full operational picture.

Then there are hidden data costs. Some suppliers charge subscription fees to access machine data from assets you already own. In effect, you pay for access to the status of equipment you have already purchased.

Software end-of-life is another risk. An OEM may decide to discontinue a cloud platform after seven years, while your turbine, engine, or transformer still has another 25 years of operational life ahead. Maintenance logic, historical data, configured thresholds, and performance baselines may all become difficult or impossible to retain.

The most serious form of lock-in is data ownership. Without open export options, moving to a better algorithm, another analytics provider, or an internal data science team becomes practically impossible. Not because the technology cannot support it, but because the historical data is trapped in a proprietary format.

The EU Data Act: from strategic argument to legal right

Vendor lock-in is no longer only a strategic concern. Since 12 September 2025, it has also become a legal issue.

The EU Data Act, Regulation (EU) 2023/2854, applies across all EU Member States. For asset owners, the core principle is clear: users of connected products, including in B2B environments, have the right to access the data generated by their assets. Manufacturers must make this data available free of charge, in a machine-readable format, and preferably in real time. They may not keep that data exclusively for themselves.

In practical terms, new contracts concluded after 12 September 2025 must comply with the Data Act. Existing contracts with a remaining term of more than ten years must be reviewed by 12 September 2027. Subscription fees for exporting data generated by your own asset may be legally challengeable. Manufacturers must design products so that data access is available by design, not as a paid add-on.

For asset owners, the Data Act provides a legal basis to enforce data ownership in tenders and contracts. Use it.

Data minimisation: the underestimated foundation

A common mistake in condition monitoring projects is the idea that everything should be logged. The result is often a data swamp: high 4G or 5G transport costs, unnecessary cloud storage costs, noisy datasets, and data scientists spending most of their time cleaning data instead of building useful models.

Future-proof asset management starts with data minimisation. Capture only the parameters that actually determine maintenance condition and asset health. By filtering at the edge, close to the machine, and sending only deviations, trends, or relevant signatures, you reduce data transport costs while increasing the usefulness of the data for AI and analytics.

Three examples make this clear.

Control valve closing curve. Instead of continuously streaming valve position data, record the closing curve and compare it with the initial benchmark. If a valve takes longer to close during the final millimetres or requires more force, it may be starting to leak or degrade. By sending only the deviation from the reference curve, you can detect failure long before fluid loss occurs, using only a fraction of the data bandwidth.

FFT trend data from an electric motor. Continuously streaming high-frequency vibration data to the cloud is usually not cost-effective. A better approach is to perform Fast Fourier Transform analysis locally, using a sensor or edge gateway, and send only trend data for the relevant frequency peaks, such as bearing defect frequencies. The algorithm then only needs to respond to deviations from the normal vibration spectrum.

Thermal gradient of a transformer. The absolute temperature is not always the most relevant indicator. More important is the relationship between temperature rise and electrical load. If that gradient deviates from the historical average, it may indicate degradation of cooling oil or internal contamination, long before an absolute temperature threshold is exceeded.

This approach does require more intelligence at the asset level. Since the OEM understands the asset best, the OEM is often in the strongest position to generate this type of meaningful, pre-processed data. But that does not mean the OEM should control the full data chain.

The four decoupled layers: an architecture model

To secure vendor independence over a 40-year horizon, the functional layers of the asset environment must be clearly separated. Each layer has its own lifecycle and rate of change.

Layer 1: the physical asset (Lifecycle: 20 to 40 years)

This is the asset itself: the turbine, engine, pump, compressor, valve, transformer, or other physical system. The requirement is clear: insist on robust, industrially accepted ports and basic protocols that can be accessed by any higher-level system. Modbus TCP or RTU is the absolute minimum. It is old and has limited built-in security, but it will still be readable by industrial systems decades from now. Where possible, OPC UA, based on IEC 62541, is the better choice. It adds built-in semantics, allowing the asset to communicate not only values, but also the meaning of those values.

Layer 2: connectivity and edge gateway (Lifecycle: approximately 5 years)

The way data is transported changes much faster than the asset itself. This layer should be managed through manufacturer-independent industrial edge gateways from suppliers such as Advantech, Kunbus, or Phoenix Contact, combined with open software such as Node-RED or EdgeX Foundry. Replacing the gateway after five years should not require changes to the asset or the database. The connection to Layer 1 is standardised, and so is the connection to Layer 3.

For wireless sensors on distributed assets, LoRaWAN on the 868 MHz band is an open LPWAN standard in the EU and is suitable where telecom dependency should be avoided. For transport to the cloud or a data lake, MQTT combined with the Sparkplug B extension is a strong option. Sparkplug B adds a fixed payload structure and state management, allowing analytics software to understand whether an asset is online and which sensors are available, without manual configuration.

For assets that require low latency and bidirectional communication, NB-IoT or LTE-M may be more appropriate.

Layer 3: data storage and semantics Lifecycle: continuous and long-term)

This layer contains the data lake, data lakehouse, and the semantic meaning of the data. The critical principle is this: data must be stored independently from the analytics software. The data must outlive the application. Three semantic models are particularly relevant in this layer:

• The Asset Administration Shell, or AAS, defined in IEC 63278-1, is the most important European initiative for industrial digital twins. It originates from Plattform Industrie 4.0 and is specified by the Industrial Digital Twin Association. The AAS provides a manufacturer-independent digital shell around the asset, in which data, documentation, and real-time parameters are described in a standardised way. Analytics software communicates with the AAS, not directly with the machine.
• NEN-ISO 81346 provides a method for structuring systems based on function, location, and product. If you label asset data consistently according to ISO 81346, the data structure remains logical and traceable over decades, regardless of which software is used on top of it.
• NGSI-LD, used in the FIWARE ecosystem, is widely applied in European infrastructure, smart cities, and utilities. It describes the context of assets using standardised Linked Data.

Layer 4: decision-making and AI logic (Lifecycle: monthly and iterative)

This is the layer for predictive maintenance, anomaly detection, optimisation algorithms, and AI models. It should be a plug-and-play layer. A better algorithm that becomes available next month should be able to run on the existing data stream and the complete historical database without requiring changes to the asset, the gateway, or the data storage layer. Make sure you own the logic and AI models, or that you have clear contractual agreements on continuity if your analytics supplier leaves or is replaced.

If the current supplier of your analytics logic no longer performs, you should be able to switch. Your data, historical time-series records, and infrastructure should remain unaffected.

What this means for tenders

The architecture described above only works if it is enforced at the moment of procurement. That requires a different approach to specifying requirements. Stop asking for “smart assets with a cloud dashboard”. That is the shortest route to combining Layer 1 through Layer 4 into one proprietary package.

Instead, require four things.

1. documented data minimisation at the source. Which parameters are logged? At what frequency? With which filtering strategy at the edge?
2. direct data ownership through open interfaces. OPC UA or Modbus should be a minimum requirement. An exclusive cloud connector must not be the only way to access asset data.
3. open export formats. Data must be available in a machine-readable format in line with the EU Data Act. Contractual restrictions on data export are increasingly difficult to justify under current regulations.
4. separate contracting for the asset and the analytics service. Maintenance logic should be a separate service, with a separate contract and, if needed, a separate supplier.

The long-term business case

The initial implementation cost of a modular, open architecture may be higher than accepting a ready-made OEM package. That trade-off is real. But over a 20-year horizon, the economic logic is clear.

Data scientists do not spend most of their time cleaning data. They can build models and improve asset performance. There are no recurring fees for access to your own data. New algorithms can run on years of historical data within a day. Replacing a gateway or analytics platform does not affect the asset or the database. The real question is not whether an open architecture costs more at the start.

The real question is what a closed architecture will cost you over the next 30 years.

Conclusion

Asset owners who accept a closed, ready-made OEM cloud platform today may be signing up for expensive operational dependency. Not tomorrow, but in seven years, when the platform reaches end-of-life, the data is locked in a proprietary format, and the cost of switching is higher than the cost of staying.

The combination of European regulation, proven open standards (OPC UA, MQTT Sparkplug B, AAS/IEC 63278-1), and available open edge software makes an independent architecture fully achievable today. Not as an idealistic concept, but as practical engineering.

In your next tender, require data ownership by design, open interfaces on the asset, and a hard separation between Layer 1, the physical asset; Layer 2, connectivity; Layer 3, data; and Layer 4, logic.

Make that separation part of the contract. The EU Data Act now gives you the legal basis to do so.

Do you have questions about implementing a vendor-independent data architecture for your asset portfolio? Feel free to contact me here.