Connect what you already run
Orbitify reads the systems you have rather than asking you to replace them. Protocol connectors, historian imports and an edge gateway for sites with poor connectivity.
Read what you already run
Every operator we talk to has been asked to rip something out before. Orbitify is built on the opposite assumption: the systems on your site stay, and the layer reads them.
Nothing is replaced to get started
Your SCADA keeps running the plant, your historian keeps the history and your maintenance system keeps issuing work. The layer reads them and puts what it learns back where you already look.
Direction is declared, not assumed
Every connector on this page says whether it reads, writes, or both. A connector that can write into your maintenance system is a change your team has to approve, so we do not hide it inside the word integration.
The connection is outbound by default
The gateway opens the connection outward and polls or subscribes from inside your network. No inbound port, no listener on the OT side, nothing waiting to be reached from the internet.
What comes in, what the model holds, what leaves
The same picture as on the homepage, in full. Sources on the left, the model in the middle, and the four things that leave it. The group marked two-way is the one Orbitify writes back into.
What comes in
Capture
- Drone RGB
- Drone thermal
- Ground robotPlanned
- 360 capturePlanned
Control systems
- SCADA
- OPC-UA
- Modbus
- MQTT
- IEC 61850
- DNP3
- BACnet
Existing platforms
- EAM and CMMS
- ERP work management
- Document control
- GIS
- BI and reporting
- Historians
- REST and webhook
Read from and written back to through their own APIs. Whatever is your system of record stays your system of record.
The layer
One asset model
Imagery, telemetry and paperwork land against the same assets, versioned over time, so an agent reads one thing instead of five.
- Asset register and hierarchy
- Work history
- As-builts and drawings
- Certificates and compliance
- Time-series history
What comes out
- Prioritised list of what to fix
- Work orders
- Audit trail
- Exports and reports
The connector matrix
What each protocol is usually attached to on a site, which way the data moves, and how we talk to it. The last two columns are the ones your network team will ask about.
- OPC UAPlant controllers, inverter gateways, modern SCADA serversTwo wayIt pushes to usIt pushes to us
- Modbus TCP / RTUInverters, trackers, meters, older field devicesReadWe poll itWe poll it
- MQTT / Sparkplug BEdge brokers, IIoT gateways, telemetry busesTwo wayIt pushes to usIt pushes to us
- IEC 61850 MMSSubstation IEDs, protection relays, bay controllersReadWe poll itWe poll it
- DNP3Transmission and distribution RTUsReadWe poll itWe poll it
- BACnet/IPBuilding and data centre plant, HVAC, power monitoringReadWe poll itWe poll it
- IEC 60870-5-104Utility telecontrol links to substationsReadIt pushes to usIt pushes to us
- SunSpecSolar inverters and string combinersReadWe poll itWe poll it
- REST / OpenAPIVendor cloud portals, maintenance systems, ticketingTwo wayRequest and responseRequest and response
- WebhooksAnything that should hear about a finding immediatelyWriteWe push to youWe push to you
- SFTP / CSV dropHistorian exports, meter data, legacy reporting jobsTwo wayScheduled batchScheduled batch
- ODBC / JDBCOn-premise historian and asset databasesReadScheduled batchScheduled batch
Where a system is not on this list, the usual route is its REST API, a historian export or an SFTP drop, all of which are supported. Protocol support is not the same as a tested vendor integration, and we will say which one you are getting before you sign anything.
What is already on your site
Grouped the way an operator keeps them apart: what controls the plant, what stores its history, what runs the business, and what captures the site. Direction is printed on every tile.
Control and field systems
Read through the gateway, on your network, in the direction you allow.
- SiemensRead
- Schneider ElectricRead
- ABBRead
- RockwellRead
- GERead
- SSMARead
- HuaweiRead
- MQTT brokerTwo way
Historians and data platforms
Backfill from what you already store, and push the model's own series back out.
- APAVEVA PIRead
- InfluxDBTwo way
- TTimescaleDBTwo way
- PostgreSQLTwo way
- Apache KafkaTwo way
- SnowflakeWrite
- SOS3 object storeTwo way
- GrafanaWrite
Maintenance, spatial and business systems
Where agent output has to land if it is going to become work rather than a dashboard.
- SAP PMTwo way
- IMIBM MaximoTwo way
- SServiceNowTwo way
- Esri ArcGISTwo way
- AutodeskRead
- SSharePointTwo way
- PBPower BIWrite
- SSalesforcePlanned
Capture and photogrammetry
Flight hardware and the file formats a survey team already works in.
- DJIRead
- PPix4DTwo way
- FTFLIR thermalRead
- G/GeoTIFF / LASTwo way
- offline for
- 3 d 4 h
- buffered
- 412 MB
- oldest reading
- 2026-02-01 06:12
- forward rate
- capped 2 Mb/s
Nothing is lost while the link is down, and nothing floods it when the link comes back.
For sites where the link is bad or absent
Remote solar, offshore wind and a substation with a deliberately air-gapped control network have the same problem in different words. The gateway is built for it rather than around it.
- 01
Collect locally
The gateway sits on the site network and polls or subscribes from the inside. Nothing is exposed outward and nothing waits on the internet.
- 02
Buffer on disk
Readings are written to local storage first. If the link is down for a week the data is still there, in order, with its original timestamps.
- 03
Forward when there is a link
When connectivity returns the buffer drains oldest first over a single outbound connection, at a rate you cap so it cannot saturate a shared satellite link.
- 04
Reconcile, do not overwrite
Late data is merged into the series at the time it was measured rather than the time it arrived, so a week of backfill does not appear as a week of flat line followed by a spike.
How other software reaches the agent
The agent answers people in Slack and software over MCP with the same reasoning and the same limits. Anything a person can ask for, a system can ask for, and neither gets past the threshold you set.
MCP server
Orbitify exposes its asset model, findings and work as MCP tools, so your own assistant or agent framework can query the model and act inside the same governance.
REST API
An OpenAPI described HTTP interface over assets, findings, telemetry series, work orders and documents. Token scoped, per-environment, with the same permissions your users have.
Webhooks and events
Subscribe to findings, state changes and decisions as they happen, so your ticketing or notification system hears about them without polling us.
Python and TypeScript SDKs
Thin typed clients over the same API, for data teams that want the model in a notebook rather than in a dashboard.
Tools exposed
- assets.queryresolve an asset and its children
- findings.listopen findings, filtered and ranked
- telemetry.seriestag history for a window
- work.createraise work, subject to limits
One call
findings.list
{ asset: "INV-04B", since: "14d", min_severity: "high" }
2 findings · 1 corroborated by telemetry · 1 awaiting a second source
A caller with the same token cannot use work.create beyond the autonomy limit set for that site. Above it the call returns a proposal for a person to approve rather than a created work order.
What connecting actually involves
Four steps, and the honest answer is that the first one takes the longest, because it is the one that depends on your team rather than ours.
Survey what exists
Which systems hold what, which tags matter, who owns the network segment, and what your change process requires. This is where a deployment is slow or fast.
Place the gateway
One outbound connection from inside your network. Reviewed by your security team before anything is installed, with the exact destinations and ports written down.
Map tags to assets
A tag name is not an asset. Mapping is what turns thousands of points into an inverter, a string and a module, and it is the step that makes everything downstream possible.
Verify against a known period
We replay a window you already understand and check the model agrees with your own reports before anything is allowed to act on it.
What integrators ask
Do you need an inbound firewall rule?
No. The gateway opens a single outbound connection and polls or subscribes from inside your network. There is no inbound port, no listener on the OT side and nothing on your network that can be reached from the internet.
Can Orbitify write into our maintenance system?
Where the connector is marked two way, yes, and only where you enable it. Write access is configured per system and per object type, so reading work orders from SAP without being able to create them is a normal and supported configuration.
Our historian is on-premise and stays there. Is that a problem?
No. The historian can remain the system of record for raw history while the layer holds the mapping and the derived series. In an edge or in-tenancy deployment the raw data never leaves your environment at all.
What if a vendor system is not on your list?
Most of the long tail is reachable over REST, ODBC or a scheduled export, which are all supported. If it is a genuinely closed system we will tell you that rather than promising a connector that would take a year.
How are credentials for our systems handled?
They are held in the deployment's secret store, scoped to the specific connector, and are never written into the asset model or exposed through the API or MCP surface. In an in-tenancy deployment they never leave your account.
What happens to data already in our historian?
It can be backfilled. Mapping the tags is the same work either way, and starting from history rather than from today is what lets drift and failure prediction be useful in the first weeks rather than the first year.