Edge deployment service
Deploy TwinEdge OS for no-cloud, offline, or protocol-rich industrial sites.
The edge deployment service helps qualify site constraints, install TwinEdge OS, connect protocols, configure buffering, validate local analytics, and define sync and support procedures.
Site constraints
Install
Protocols
Buffering
Local analytics
Support bundle
A field-ready service for software-first local deployments.
Platform in action
TwinEdge OS console for protocol access, dashboards, ML inference, and cloud sync
TwinEdge OS gives teams visible protocol adapters, local dashboards, ML inference controls, visual tag mapping, service state, offline resilience, and governed cloud sync close to equipment.
Protocol adapter console
TwinEdge OS exposes local protocol adapter configuration for edge, cloud-connected, and offline deployments.
Local OS dashboard
The local console shows services, asset cards, protocol labels, and local operating status.
ML inference controls
Runtime controls show scheduled inference, service health, loaded models, inputs, outputs, and local model inventory.
Visual tag mapper
Visual mapping helps bind source tags and industrial data into asset and namespace context.
Edge runtime proof
Run the same operating layer close to the assets when the site demands it.
TwinEdge OS brings protocol collection, buffering, local dashboards, inference, alerts, support bundles, and controlled sync into one edge runtime that still connects to the broader TwinEdge product family.
Local
Runtime
Protocol access, storage, dashboards, inference, and alerts at the site.
Hybrid
Deployment
Edge, cloud-connected, no-cloud, and controlled sync patterns.
Resilient
Operations
Store-forward behavior supports offline and constrained environments.
Workflow
Local intelligence at the site
Connect industrial sources, build trusted context, govern recommendations, and turn approved decisions into operational work.
Connect protocols and sources
Use OPC UA, Modbus, MQTT, databases, files, and edge services to collect the data needed for local context.
Run locally when offline
Buffer data, run local workflows, serve dashboards, dispatch alerts, and generate support bundles even when cloud connectivity is unavailable.
Sync with cloud when connected
Move telemetry, metadata, model packages, and fleet status to TwinEdge Cloud based on the customer deployment model and approval policy.
Capabilities
TwinEdge OS capabilities
Downloadable edge deployment
Runs as software on supported Linux or container hosts, with gateway or Box packaging available when needed.
Local analytics and inference
Protocol access, storage, ONNX inference, dashboards, alerts, and offline-capable operation close to equipment.
Cloud coordination
Cloud-managed package updates, telemetry sync, model distribution, health checks, and support bundle export where allowed.
Engineering controls
Engineering controls for industrial AI.
TwinEdge can show real telemetry, local inference, protocol flows, and agent traces without claiming uncontrolled autonomy or SCADA replacement.
Read-only first
Physical writeback is disabled by default and recommendations pass through approval gates.
Replayable evidence
Plans, diffs, source context, and approval history remain available for review.
Deployment choice
Cloud-connected, local, and offline paths support evaluation without forcing one architecture.
Source system respect
TwinEdge works above SCADA, historians, CMMS, GIS, LIMS, ERP, and data lakes rather than pretending to replace them all.
Edge benchmark · measured, not modeled
TwinEdge OS beat Siemens’ published 20K OPC UA reference — and durably stored the stream.
At the directly comparable 20,000-tag tier, the TwinEdge OS C/open62541 data plane delivered lower latency than Siemens’ published IIH live-value reference while also storing every reading into Apache IoTDB with a perfect store ratio, zero sequence gaps, and zero replay backlog.
20,333/s
stored readings
20,000-tag tier, 60-second run at 100 ms publish/sample, store ratio 1.000.
100 ms
p95 source-to-ingest
Against Siemens’ 115 ms published 20K live-value update reference.
13.0%
lower latency
15 ms faster than the Siemens published 20K live-value reference.
Zero
gaps · replay lag · storage errors
Durable binary-log append plus IoTDB acceptance across the full stream.
Head-to-head at 20,000 tags
Siemens’ table measures IIH Semantics processing time to client availability; TwinEdge measures p95 source-to-ingest plus confirmed storage acceptance, so the numbers are labeled accordingly and the Siemens figures are used as a public reference baseline.
| Metric | Siemens public 20K reference | TwinEdge local 20K result |
|---|---|---|
| Tags | 20,000 | 20,000 |
| Live / reference latency | 115 ms live-value update | 100 ms p95 source-to-ingest |
| Secondary latency | 125 ms RDF update | 200 ms p99 source-to-ingest |
| Stored throughput | Not published | 20,333.3 readings/s |
| Store ratio | Not published | 1.000 |
| Sequence gaps | Not published | 0 |
| Replay lag | Not published | 0 records |
Local capacity ladder
Beyond the 20K Siemens comparison, the same data plane sustained higher local stored-throughput probes — every tier held a 1.000 store ratio with zero sequence gaps and zero replay lag.
| Tier | Stored readings/s | p95 | Result |
|---|---|---|---|
| 10K | 10,166.7 | 200 ms | Passed local gate |
| 15K | 15,250.0 | 200 ms | Passed local gate |
| 20K | 20,333.3 | 100 ms | Passed Siemens comparison |
| 25K | 25,416.7 | 200 ms | Passed local gate |
| 50K | 50,416.7 | 500 ms | Passed local gate |
| 100K | 101,758.3 | 500 ms | Passed stretch probe |
| 250K | 254,941.7 | 1000 ms | Passed stretch probe |
Benchmark methodology & caveats
- · Competitive local benchmark, not a Siemens device certification.
- · Compares TwinEdge p95 source-to-ingest plus storage acceptance against Siemens’ published live-value processing reference; internal product counters are not identical.
- · Siemens reference: published IIH Semantics physical/online OPC model, single client and connection.
- · Before a production sizing commitment, rerun the same gates on the target ARM64 gateway or x86 industrial PC with long-duration soak and power-loss recovery tests.
Outcomes
Operational outcomes
Teams get the context, controls, and execution path needed to move from noisy industrial data to approved operational action.
Plant operations
Keep critical dashboards, alerts, and inference local while still sending data to cloud services when the site is connected.
OT and IT
Use a bounded software runtime without waiting on appliance procurement.
Enterprise teams
Standardize edge analytics across sites while using cloud visibility, fleet coordination, and governed sync where approved.
Connected platform
Extend the same context across the operating layer
DataOps Workbench creates the physics-aware, AI-ready context.
Agentic Analytics uses that context to explain, draft, and validate recommendations.
TwinEdge OS supports cloud-connected, offline, and protocol-rich edge deployments.
AssetOps EAM and TwinEdge Field close the loop from recommendation to work, guided mobile diagnostics, human-reviewed evidence, and closeout.
Water OS, Wastewater OS, Chemical OS, Water Loss OS, Water Quality, Capital Planning, ESG, and Facility OS package industry workflows.
REST and MCP data products make context available to enterprise applications and AI systems.
Frequently asked questions
Questions about Edge deployment service
Clear answers for buyers, operators, engineers, and evaluation teams.
What is TwinEdge OS?
TwinEdge OS is the local industrial edge runtime in the TwinEdge product family. It connects site protocols, buffers telemetry, runs local analytics and ONNX inference, serves dashboards, dispatches alerts, and synchronizes approved data with TwinEdge Platform.
Can TwinEdge OS run without cloud connectivity?
Yes. It is designed for offline and intermittently connected sites, with local protocol access, storage, dashboards, inference, alerts, and store-and-forward behavior.
Which industrial protocols does TwinEdge OS support?
The product includes connector families for OPC UA, Modbus, MQTT, EtherNet/IP, Siemens S7, BACnet, and other site sources. Exact protocol, driver, and hardware certification should be confirmed for each deployment.
What hardware runs TwinEdge OS?
TwinEdge OS is software-first and can run on supported Linux or container hosts, including suitable industrial PCs, gateways, and Raspberry Pi-class evaluation hardware. Production sizing depends on workload and site requirements.
How is TwinEdge OS different from TwinEdge Platform?
TwinEdge OS is the local edge runtime. TwinEdge Platform is the cloud and hybrid coordination layer for shared context, analytics, fleets, agents, AssetOps, Field, compliance, and reporting.
Who this is not for / non-goals
- •Not a safety PLC, SIS, or hard-real-time motion controller replacement.
- •Not a guarantee of every industrial protocol/hardware profile without site validation.
- •Not cloud-only SCADA; local OT constraints still require proper network design.
See claims and boundaries and labeled proof.
Related for search and evaluation
Primary product for asset management and maintenance work.
Condition, physics, and remaining-life workflows.
Governed recommendations with approval and replay.
Maximo, HighByte, MaintainX, Fiix, and field alternatives.
Definitions for CMMS, DataOps, UNS, twins, and agents.
Labeled benchmarks and pilot methods.
Evaluate TwinEdge
Plan your first TwinEdge workflow.
Review the operating model with our team, or download TwinEdge to evaluate the platform in your own environment.