Who can connect
Approved administrator IPs or the designated jump host, using HTTPS or key-based SSH.
TwinEdge OS
Keep intelligence at the equipment.
AI-native industrial edge OS. Hardened for OT.
TwinEdge OS is the AI-native edge server. Connect your PLCs, keep local history, and run models beside the machine — including with no internet.
Secure industrial edge runtimeBuilt at the edge. Ready for operations.Industrial edge runtime
Chassis
Edge runtime
CPU
Memory
Storage
Thermal
Power
I/O
TwinEdge OS · local administration
TwinEdge OS runs on a hardened industrial edge server. Operators reach it from a connected workstation — not from a public cloud console.
The hardened local OT deployment
Access is explicit. Enforcement stays on the device.
The hardened OT deployment permits approved administration and local PLC communication. The network firewall restricts the routed management path, while the edge server's own firewall enforces its rules independently. Everything outside the permitted traffic policy is denied.
Secure at the equipment.Hardened local OT deploymentDEPLOYMENT ILLUSTRATION
Industrial equipment stays on the existing PLC. TwinEdge OS is a peer on the local OT subnet behind its own default-deny firewall. Approved administrators connect with HTTPS or key-only SSH through a network firewall. New connections the edge server tries to start off the subnet are dropped at the device firewall.
Approved workstation / jump hostHTTPS + key-based SSH from designated sources
Network firewall / gatewayApproved admin sources only
Local OT subnetWired switch · Existing PLC · Pump / motor / sensors
TwinEdge OS · device firewallDefault deny. Collect, store, analyze. Wi-Fi and Bluetooth disabled at boot.
Other subnets / InternetNew edge-initiated connections blocked at the device firewall
TwinEdge starts a local PLC session on the OT subnet, then collects, stores, and analyzes beside the machine. Blocked external paths stay visible but unused.
Hardened on the device
- Key-only SSH
- Dedicated OT account. SSH password authentication and root login disabled.
- HTTPS configuration UI
- Configure the edge server through its encrypted management interface from approved sources.
- Unused interfaces disabled at boot
- Wi-Fi, Bluetooth, and unused interfaces remain disabled across reboots. Enabling them requires a device configuration change.
- Host firewall enforced locally
- The device accepts approved management connections and permitted session responses. Other new inbound traffic is dropped; new edge-initiated traffic is limited to permitted local PLC communication.
HTTPS + key-only SSHApproved admin sourcesFirewall on the deviceNew off-subnet connections blocked
What the edge can initiate
Permitted PLC communication on the local subnet. New connections to other subnets or the internet are blocked.
What stays disabled
SSH password login, SSH root login, Wi-Fi, Bluetooth, and unused interfaces in this deployment profile.
View traffic policy
| Direction / session | Policy in this deployment |
|---|---|
| Approved admin → edge | Allow HTTPS and SSH through the routed network boundary and the device firewall. |
| Any other source → edge management | Drop new connections, including attempts arriving from the same local subnet. |
| Edge → local PLC | Permit configured local PLC communication. Not a whole-subnet wildcard. |
| Replies within permitted sessions | Allow established-session response traffic, including replies to approved administrators outside the subnet. |
| Edge → other subnets / Internet | Deny new edge-initiated connections. |
| Other new inbound services | Deny; internal runtime components do not imply extra reachable services. |
Shown: the hardened local OT deployment. Cloud-connected deployments use a separately approved connectivity policy. This table describes session-level behavior, not an executable firewall ruleset.
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.
Connect the source
Bring OPC UA, Modbus, MQTT, and local interfaces into an asset-aware runtime.
Keep the site working
Store readings, run inference, serve dashboards, and raise alerts locally.
Coordinate across sites
When enabled under an approved connectivity policy, synchronize data, packages, and fleet health.
Continuity onsite
Local operation continues through connectivity interruptions.
One runtime to manage
Collection, storage, inference, and dashboards share the edge host.
A connected fleet
Carry site context into wider analytics and operations.
FROM THE PRODUCT
See the work in context.
Select a screen to explore the workflow. Open it for a closer look.
01 / INSIDE TWINEDGE
See the site at a glance
Asset health, host resources, and protocol services share one local dashboard.
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.
TwinEdge OS
- 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.