ALLINLET Cloud

ALLINLET Cloud is the managed deployment option for teams that want to connect field and enterprise sources without operating the integration platform themselves. This page describes the target architecture. Every element is subject to validation in your project before it is relied upon in production.

What the Cloud option is for

Cloud suits organisations whose sources can already reach the internet through a controlled path: MQTT brokers, REST and GraphQL APIs, published open data, object storage buckets and gateways that forward plant data over TLS. The platform receives those observations, attaches source identity, timestamps and quality information, and exposes a single normalised flow to downstream applications, dashboards and data stores.

It is not a substitute for a site network design. Controllers, meters and fieldbus devices normally stay behind a gateway or historian, and that gateway is the component that talks to Cloud. Engineers keep control of which tags, topics or tables leave the site.

Target architecture

The intended design separates three layers. An ingestion layer holds connector configurations and receives or polls data. A processing layer validates payloads, maps units and identifiers, and records the time a measurement was taken separately from the time it arrived. A delivery layer makes the resulting records available through APIs and exports. Tenants are kept apart logically, and credentials for sources are stored outside connector definitions.

Region, retention period, throughput limits and backup arrangements are agreed per project. We do not publish a generic service level, certification list or price for Cloud; those terms are defined in writing once the scope has been assessed.

Prerequisites

  • An outbound path from each site or gateway to the platform, approved by the network owner.
  • A source inventory: device or system names, protocols, addressing, polling or publishing intervals and expected volume.
  • Credentials or certificates issued by the source owner, with least-privilege read access.
  • Agreed units, identifiers and a naming convention for assets and measurements.
  • A named owner on your side for each source who can confirm whether values are correct.

What a record means

Each stored observation carries the source reference, the measurement name, the value, its unit where known, the source timestamp, the receive timestamp and a quality indication. A missing or invalid reading is recorded as such rather than converted into zero. Buffered data uploaded after an outage keeps its original time, so applications can tell late data from current data.

Limitations to plan around

  • Catalogue entries describe possible integration paths. Not every listed connector is implemented or validated, and status is confirmed per source during scoping.
  • Cloud cannot read devices that are only reachable on an isolated plant network; a site gateway or the Edge configuration path is needed.
  • Latency depends on the site uplink and source intervals. Cloud is not a control system and must not be used to close safety or process loops.
  • Large binary streams such as video are referenced or summarised, not treated as ordinary time series.

Next steps

Start with a short source inventory and one representative connection. Compare Cloud with the self-hosted Enterprise option and the Edge configuration registry before deciding where integration should run.

Further reading

Catalogue listings describe possible integration paths. Implementation and validation status is confirmed for each source during project scoping; no certification, service level or price is implied by this page.

Plan your data integration

Share your devices, protocols and network constraints, and we will propose a first validated connection.

Related pages