Qualify the site
Review host, network, protocol, and local operating requirements.
Edge deployment service
Get the first site connected.
Install TwinEdge OS, connect the plant protocols, and validate local collection, history, and analytics.
Connected through the TwinEdge platformIntelligence at the equipment01 / SYSTEM VIEW
01Acquire02Store03Analyze04Synchronize
START WITHOPC UA · Modbus · MQTT
TWINEDGE CONNECTSIntelligence at the equipment
MOVE FORWARD WITHLocal apps + fleet context
THE WORKFLOW
From first signal to a connected site.
Commission the runtime
Install, connect sources, map the assets, and confirm local operation.
Prepare the handover
Define synchronization, support, and the next site rollout.
A defined first outcome
Keep the initial scope tied to a useful operating decision.
Usable work left behind
Retain mappings, configuration, and a repeatable workflow.
A clear next step
Use the first result to shape rollout and support.
BUILT FOR THE OPERATION
The context your team needs.
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
When enabled under an approved connectivity policy: package updates, telemetry sync, model distribution, health checks, and support bundle export.
GO DEEPER
Details for your operating context.
Edge throughput and deployment evidence
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.
- 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.
CONNECTED BY DESIGN
Fits the systems around it.
Keep source context available as the workflow moves between teams and applications.
One connected record.
Edge deployment service
- 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, TwinEdge Chemical, 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.
- TwinEdge DRIVE can use validated TwinEdge OS protocol, physics, evidence, and command services to govern selected variable-speed actions through the existing control path.
BEFORE YOU START
A few useful answers.
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.
How is TwinEdge OS administered in the hardened OT deployment?
Approved administrators connect through HTTPS or key-based SSH from designated IPs or a jump host. The routed management path is restricted by the network firewall, and the edge server enforces its own host-firewall rules. SSH password authentication and root login are disabled.
Does the edge server initiate connections to the internet?
Not in the hardened local OT profile shown here. It initiates only permitted local PLC communication. It can reply within established, permitted sessions, including an approved administrator’s connection from another subnet.
Does protection depend only on the network firewall?
No. The edge server enforces its own firewall policy. That policy still restricts access when traffic reaches the device without traversing the routed network firewall, such as traffic from another host on the local subnet.
Can Wi-Fi or Bluetooth turn back on after a reboot?
They are disabled at the boot-configuration level in this profile and remain off across reboots. Enabling them requires a configuration change on the device. The same principle applies to unused interfaces covered by the deployment configuration.
How does this work with cloud-connected TwinEdge deployments?
The topology shows the hardened local OT profile. Cloud coordination requires a separately approved connectivity policy; it is not an active path through the blocked outbound connection illustrated here.
THE NEXT CONNECTION
Explore the product familyBuild the rest of your loop.
START WITH YOUR OPERATION
Put the next decision in motion.
Discuss your sources, assets, and the outcomes your team wants to improve.