TwinEdge downloads

Download the product that matches your site data path.

TwinEdge packages are organized around how industrial data moves: live protocol sources, historian and enterprise systems, local edge runtime, and governed analytics. Start with the product that fits where your data begins and where it needs to go.

Product architecture for local evaluationPick the package by source type, site runtime, and the output path your team needs to validate.Local runAPI/MCPSyncSOURCE SYSTEMSTWINEDGE PRODUCTSOPERATING OUTPUTSSCADA / PLCOPC UAHistoriansMQTT / SQLFiles / APIsSite / edge runtimeOT Bridgeread protocolsCollectorbuffer + normalizeTwinEdge OSlocal runtimeAgentic Analyticsgoverned actionLocal dashboardsAlerts + diagnosticsAPI / MCPReports + workflowsLOCAL-FIRST DATA PATHRun near equipmentWindows, Linux, Docker, edge hostNormalize contextTags, events, files, source healthPublish outputsDashboards, APIs, reports, sync

Connect source systems

Use OPC UA tools, OT Bridge, or Collector depending on whether the first source is a live protocol endpoint, historian, database, file, or API.

Run at the site

Place the package on Windows, Linux, Docker, or an edge host so the first evaluation can happen near the real operational data path.

Shape operational context

Normalize tags, files, events, and source health into asset-aware context that downstream analytics and dashboards can understand.

Send intended outputs

Keep outputs local, publish to TwinEdge OS dashboards, expose APIs/MCP, or sync selected data to enterprise systems when enabled.

Enterprise packages

Choose by connection role, local runtime, and output path.

Agentic Analytics, Collector, OT Bridge, and TwinEdge OS solve different parts of the same operating architecture. Each card explains what it connects to, where it runs, how it sends data, and what the evaluation team should prepare.

Analytics, AI governance, API/MCP

TwinEdge Agentic Analytics

Evaluate governed operational recommendations, source evidence, approval gates, and API/MCP products.

Connects

Context from TwinEdge OS or Collector, historian extracts, SQL/API sources, documents, alerts, events, and operating procedures.

Runs

Docker, Linux, or Windows evaluation environment close to the governed operational data layer.

Sends

Human-approved recommendations, evidence packets, API/MCP responses, and workflow handoffs to the systems your team already uses.

Expect

Use it to prove whether your operating context is complete enough for explainable analytics and supervised action.

Historians, files, APIs, SQL

TwinEdge Collector

Bring historians, files, APIs, MQTT, SQL, and enterprise sources into a clean operating data layer.

Connects

PI-style historians, relational databases, REST endpoints, MQTT topics, flat files, CSV exports, and enterprise source systems.

Runs

A lightweight service on Windows, Linux, or Docker near the source systems or in a controlled integration zone.

Sends

Normalized time-series, events, files, source health, and lineage into TwinEdge OS, Agentic Analytics, or customer endpoints.

Expect

Plan to validate credentials, source schedules, tag naming, buffering behavior, and the first asset mappings.

OPC UA, Modbus, MQTT, OT networks

TwinEdge OT Bridge

Bridge plant-network protocol sources into governed context without forcing a cloud-first architecture.

Connects

OPC UA endpoints, Modbus TCP sources, MQTT brokers, gateway feeds, and plant-network protocol data.

Runs

An edge or DMZ-friendly host that can sit close to OT sources while keeping the control layer separated.

Sends

Selected tag streams, events, and protocol status to Collector or TwinEdge OS through the approved site path.

Expect

Plan for endpoint addresses, certificates, network rules, tag allowlists, and a clear read path before live activation.

No-cloud, edge, offline resilience

TwinEdge OS

Run the local operating layer for protocols, buffering, dashboards, alerts, inference, and diagnostics.

Connects

Collector, OT Bridge, local OPC UA/MQTT/Modbus sources, file drops, APIs, and site-specific operating models.

Runs

A local edge, server, workstation, or Docker runtime where the site needs data, rules, and dashboards to stay local.

Sends

Local dashboards and alerts first; approved exports, APIs, MCP products, or cloud sync only when that path is enabled.

Expect

Use it to evaluate the complete local runtime: source ingest, buffering, model context, diagnostics, and operator-facing views.

Benefits

Product selection starts with how the site actually works.

A useful evaluation needs more than an installer. The team should know the source systems, host location, network boundary, local runtime needs, and which outputs are allowed on day one.

Clear role for every package

Collector handles enterprise sources, OT Bridge handles protocol access, TwinEdge OS handles local runtime, and Agentic Analytics handles governed recommendations.

Local-first evaluation

Teams can validate the source path, buffering, dashboards, and diagnostics before deciding what should leave the site.

Practical OT expectations

The page tells engineers what they need ready: endpoints, credentials, certificates, tag lists, host choice, and first asset mappings.

Data path before scale

Each product makes the next handoff explicit, so the evaluation starts with the right connection pattern instead of a generic installer.

How products work together

From source connection to governed operating output.

Most evaluations begin with one product, then expand as the data path becomes clear. The architecture can stay local, publish to enterprise systems, or expose selected context through APIs and MCP products.

Protocol access

OPC UA, Modbus, MQTT, gateway feeds, certificates, tag allowlists

Source activation

Historians, SQL, REST, files, MQTT topics, schedules, lineage

Local operating layer

TwinEdge OS for buffering, dashboards, alerts, diagnostics, and offline continuity

Governed output layer

Agentic Analytics, evidence, API/MCP products, reports, and workflow handoff

Developer tools

OPC UA utilities for engineers and integrators.

Use the OPC UA utilities when the first question is source behavior, certificates, node structure, subscriptions, or a local test server before a platform package is introduced.

OPC UA inspection

OPC UA Client

Browse OPC UA servers, inspect node hierarchy, read values, monitor subscriptions, and manage certificates.

Connects

Live OPC UA servers, certificate stores, namespaces, node trees, variables, methods, and subscription endpoints.

Runs

A desktop utility for engineers checking connectivity before a platform package is placed near the site sources.

Sends

Read and subscription checks back to the engineer; exports and observations can guide the later OT Bridge configuration.

Expect

Use it to confirm server reachability, security settings, node structure, and tag behavior before deeper integration.

OPC UA test source

OPC UA Basic Simulation Server

Spin up a local OPC UA server for testing clients, tags, subscriptions, and simulated operating values.

Connects

Local clients, development environments, integration tests, and demo pipelines that need a repeatable OPC UA source.

Runs

A local desktop server with simulated nodes and values, useful when live control-network access is not available.

Sends

Simulated OPC UA values and subscriptions to clients, OT Bridge tests, or engineering validation workflows.

Expect

Use it to exercise connection settings, node browsing, subscriptions, and downstream handling before touching a live source.

OPC UA WebClient

Connect to OPC UA servers directly from your browser when you only need quick inspection and do not need a desktop package.

Choose your evaluation path

Pick the package that matches your first source and runtime.

Start with the source system you need to prove, then choose the product that can run where the site allows it and send the outputs your team is ready to validate.