Center and edge deployment

This guide takes one center and one edge site through deployment: the edge Gateway collects device data, the center Gateway aggregates it, and Studio manages projects and remote maintenance. Start with one site and one test variable before adding more sites and points.

Follow this sequence for the first deployment:

Install services → Enroll the site → Publish and verify collection → Select variables → Configure synchronization → Verify.

The main procedure uses Studio to configure SyncBridge automatically. Completion means reading a new sample from the site test point at the center. Follow steps 1–6 first. Manual SyncBridge, Gateway MQTT and shared-Broker routes and HTTPS / TLS are optional choices for sites that need them.

Before deployment

Before deployment: roles, network and accounts

What to install at each location

Complete two separate connections: management enrollment lets Studio maintain the site; data synchronization brings site variables into the center Gateway. An online site in Studio confirms management access only.

Run the center Gateway independently. Studio’s project runtime is for development and changes when projects are switched, so it should not be the continuously running aggregation service.

Choose one data route

Start with one route for the same variables to make sources and failures easy to identify. For custom JSON from third-party devices, first collect it into local variables, then include those variables in the synchronization scope.

Prepare endpoints and credentials

Examples use center.example.com for the center and 192.168.10.20 for the site. Replace them with actual reachable names or IPs. Screenshot values such as localhost and high ports belong to a same-machine example.

Allow traffic in the directions above. Reverse management tunnels work for sites without public inbound management access; the site must still reach Studio, its tunnel Broker and the selected data port.

Prepare three account types: a Studio account for center management, Watchdog accounts for site registration and deployment, and Gateway accounts for collection and synchronization configuration. Use each host’s own credentials; Watchdog and Gateway passwords are separate.

If management HTTPS or tunnel TLS is required, complete management encryption before enrollment. To encrypt data only, enable Use TLS in step 5.

Connect and publish the project

1. Install and start the center and site

Where: center management host, center data host and site gateway computer.

1. Download matching OS and CPU packages from Downloads: Studio for management, and Watchdog with TGateway for the center data host and site. Use the same current release at both ends.
2. Check runtime and architecture in Environment setup, then follow Windows deployment or Linux deployment. Extract complete packages and start Watchdog at the center and site, keeping the included GatewayApp directory.
3. Start TGateway.Studio.exe on Windows or ./TGateway.Studio on Linux from the complete Studio directory. Open its actual listener, typically http://center.example.com:5100.
4. Sign in to both Watchdogs. Confirm Gateway is running on the dashboard, then open each Gateway using its actual API port. Use delivered credentials, or sign in directly with admin / 111111 if unchanged. See Quick start.

5. Once startup succeeds, configure Watchdog using Windows service installation or Linux systemd setup. Keep Studio running under the center’s service manager too. Run one host instance per installation directory.

Complete when: Studio and both Watchdog/Gateway pairs are accessible, both Gateway processes are stable, and failure counts are not continuously increasing.

2. Establish Studio management access

Where: center Studio; outbound enrollment also requires the site Watchdog.

Open Site management in Studio and choose one connection method.

Option A: direct LAN or private-network access

Use this when Studio can reach the site Watchdog and Gateway directly.

1. Select Add site and Direct LAN for the maintenance connection.
2. Enter the site name, group, Watchdog host, port and Watchdog credentials. Enter the host and port separately.
3. Set the actual site Gateway port. HTTPS switches must match existing listeners; selecting them does not create remote HTTPS services.
4. Save and select Test, then continue with the management checks below.

Option B: the site initiates a connection to the center

Use this when the site can reach the center but the center cannot directly reach site management ports.

1. In Studio, open Tunnel and configure the Broker port, verification token and optional access key. Choose TCP or TLS, save and start the Broker. See Tunnels for the fields.
2. Return to Site management → Add site and select Edge connects to center. Enter the reachable center host, actual site Watchdog and Gateway ports, and Watchdog credentials. Enter only a hostname or IP for the center host.

3. Save, then select Generate enrollment code from the site’s operations. Check that the displayed Studio URL is reachable from the site.
4. In site Watchdog, open Tunnel management → Connect to center. Enter that HTTP/HTTPS URL and enrollment code, then select Enroll and connect.

5. Wait until both Watchdog and Gateway tunnels are connected and bound. Check local and exposed ports and allow the assigned center ports.

Codes expire after 10 minutes and can be used once. Regenerating a code, editing or deleting the site, or restarting Studio invalidates unused codes. Generate another if needed.

Check management access

In Studio, select Test for the site and confirm Watchdog is online and Gateway is running. Open Gateway interface and Operations → Site maintenance, sign in with their respective accounts, and confirm both belong to the intended site.

Complete when: Studio opens the correct site’s Gateway and Watchdog. Continue by preparing its collection project.

3. Publish the project and verify site collection

Where: Studio prepares and publishes the project; site Gateway verifies device data.

If an existing site already collects correctly, check the completion criteria below and proceed to step 4. To archive current site changes, use Projects → Download from gateway before later deployment so an older local project does not overwrite them.

Prepare collection in Studio

1. Open Projects → New project and enter a site-specific name, purpose, and available local port. Use Import project for an existing ZIP. The local port is for local validation and does not change the site port.
2. Select Run locally, wait for its running state, then select Open project to enter Gateway Web. Local projects with different ports can run at the same time.
3. In Development configuration → Collection configuration, create a channel with the site’s IP/port or serial parameters. Create a device, select its collection plugin and set its station address and other properties.
4. Add one test variable with the documented address, data type, permissions, collection period and byte order. Save and enable it. Plugins with their own connections keep connection parameters in device properties; see Collection configuration.

Without a PLC, use the Modbus simulator in Collect your first point. If the center cannot reach the real site PLC, prepare the settings here and verify actual collection after deployment.

Upload to site Watchdog

1. If the site already has a project, create a backup in its Watchdog Backup management.
2. Select Upload on the Studio project and choose the site tested in step 2.
3. For configuration-only uploads, leave Also Update Gateway Program off and confirm that the site has the matching gateway version installed.
4. To include the bundled Gateway, check its version and platform against the site OS and CPU before enabling Also Update Gateway Program. For another platform, first update its official gateway package through Site management, then upload configuration only.
5. Upload and wait for completion. In site Watchdog, check the active project, Gateway version and process logs. Open site Gateway and inspect the test variable.

Upload can restart the supervised Gateway; use an allowed interruption window. See Projects for complete parameters, or upload and apply a full package through Watchdog project management.

Complete when: site Watchdog runs this project and the test variable is healthy and matches the device. Record its name, value and update time for the center comparison.

Configure and verify synchronization

4. Select the site variables to synchronize

Where: site Gateway → Development configuration → Data forwarding.

1. Add and enable a forwarding group, for example Center aggregation.
2. Choose manual variable selection. Add and enable the healthy test variable from step 3.
3. Choose the required trigger, such as change-triggered sending; set the period for timed sending. For Gateway MQTT, disable Online Filter so snapshots include offline variables and metadata.
4. Save the group. See Data forwarding for complete scope and trigger settings.

Complete when: an enabled site group contains the test variable. Studio uses this scope without adding all site variables; it creates the synchronization target in the next step.

5. Configure and enable synchronization in Studio

Where: center Studio → Site management → target site → Data synchronization.

Enter both endpoint configurations

Studio uses management URLs to configure the two Gateways; site Gateway uses the data host and port to send data. These may use different network addresses, but each must be reachable by its caller. Do not enter Studio, Watchdog or tunnel Broker ports here.

Connect, select the group and apply

1. Select Connect both ends and wait for sign-in checks. This reads the site’s enabled forwarding groups.

2. Select Center aggregation from step 4. If the list is empty, save and enable the site group, then reconnect.

3. Check protocol, port, TLS and group, then select Configure and enable. Login passwords are used only for this operation and cleared when the panel closes.

4. Wait for Configuration saved at both ends; data connection confirmed. If synchronization is pending or a stage fails, inspect that stage, fix its error and retry with the same parameters.

Successful automatic setup creates the center receiver, site sending target and center mirror variables. New links disable remote writes. SyncBridge and GatewayMqtt both support site offline caching; confirm that the target’s failed-send retry cache is enabled. GatewayMqtt applies center variables after the first snapshot; check that its Center variables stage completes.

Multiple sites can share a center listener with the same protocol, port and TLS mode. Repeated setup reuses objects and credentials. Failures may leave completed stages in place, so inspect and retry without repeatedly changing names. Keep TLS mode consistent on a shared port; use another port or a coordinated maintenance window to change it.

Complete when: Studio confirms the data connection. Verify actual values in step 6. Automatic certificate issuance does not include renewal; see Data encryption.

6. Verify with one test variable

Where: site Gateway and center Gateway.

1. At the site, find the test variable from step 3 and check its value, status and update time.
2. Check the selected route at the center:

3. Find the matching source variable in center collection and compare value, status and update time with the site.
4. Change an approved test point through the device or simulator. Wait for collection and forwarding, then confirm the center follows the change. Do not write to unauthorized production points.
5. Confirm both supervised processes are stable and the site forwarding target is online. For either protocol, check that offline cache is not continuously growing.

Pass criteria: management access works, site collection is healthy, and the center follows a real value change. Then expand the forwarding scope to the remaining business variables.

SyncBridge manages its mirrors automatically. They need no collection channel and cannot be manually deleted or assigned another plugin; maintain source settings in the synchronization target. For historical backfill, enable site caching and include central mirror variables in a Historical Data Storage target’s group. SyncBridge and dedicated Gateway MQTT collection preserve original collection and record times while retaining the latest current state. Follow Offline cache and historical backfill to verify disconnection recovery and check capacity, Broker sessions and duplicate-record behavior.

Encryption and other connection routes

Optional: HTTPS and TLS

Encrypt management connections

Follow Management certificates: prepare identity → import peer trust → enable HTTPS or tunnel TLS → verify the endpoint → update site URLs. That page includes listener configuration and renewal.

Tunnel TLS covers the site-to-center tunnel. Browser access to an exposed mapping still needs HTTPS separately. Certificate names must match actual connection names, and machine clocks must be correct.

Encrypt data connections

With Use TLS enabled in step 5, Studio configures data certificates in both Gateways:

Inspect certificates in each Gateway’s Development configuration → Certificate management. The CA private key stays at the center. Each site receives public CA trust and, for SyncBridge, its own client identity. Manage these separately from management certificates.

Automatic setup does not renew certificates. Resolve conflicting names, expiry or wrong certificate purposes through Gateway certificate management, save the target/device, rebuild its connection and verify values again.

Optional: manual configuration and other routes

After successful automatic setup and verification, no manual setup below is needed.

Configure SyncBridge manually

For custom endpoints, multiple Hubs or independent plugin maintenance, use SyncBridge in this order:

1. Prepare enabled groups at both ends, including the required variables at the site, and add a SyncBridge target at each end.
2. Select HubServer and a listener address at the center; select EdgePublisher and center endpoints at the site. Give each node a unique Peer ID and use the same nonempty verification token.
3. For TLS, select a server identity at the center and this site’s client identity at the edge. Configure CA trust at both ends. The client identity’s DNS name or subject CN must match the site’s Peer ID; the TLS target hostname must match the center identity.
4. Enable the center first, then the site. Check configuration synchronization and the full snapshot, then perform step 6. Variables removed from scope retain center mirrors marked as missing-source; they are not automatically deleted.

Configure Gateway MQTT manually

The center directly accepts site connections

When the center can open an MQTT listener, automatic GatewayMqtt in step 5 is normally sufficient. To manage listeners, source authentication or client-certificate binding yourself:

1. Create a Gateway MQTT Collection Server at the center. Configure its listener, Topic root and independent credentials/ClientIds for each source.
2. Add an MQTT Client Producer to the site group and connect to that listener using the matching source identity.
3. Apply the fixed Topic and payload settings, inspect the snapshot and apply center variables, then return to step 6.

Both ends connect to a shared Broker

Use this after step 4 in place of Studio automatic setup. Both the center and site are MQTT clients of the same Broker.

1. Prepare independent center and site accounts, ClientIds and ACLs at the Broker. Restrict each site to its own Topic namespace.
2. Create Gateway MQTT Collection Client in center collection. Enter the Broker endpoint, credentials and Topic root. Register each site’s unique RemoteKey, such as edge-01, under remote sources.
3. Add MQTT Client Producer (MqttClientProducer) to the site forwarding group, connect to the same Broker with the site identity, and configure Topics and payload as below.
4. For TLS, both ends trust the Broker CA and use its matching SSL target hostname. Configure separate client identities only if the Broker requires mutual TLS.
5. In center protocol debug, confirm the source is online, request a snapshot, preview variable differences and apply the plan. Return to step 6.

Broker ACLs must allow site variable/response publication and request subscriptions, plus center subscriptions and requests for authorized sources. A connection alone is insufficient for snapshots and synchronization.

Fixed Topics and payload requirements

Gateway MQTT uses a fixed catalog protocol. For Topic root TGateway/Gateway and RemoteKey=edge-01, use TGateway/Gateway/edge-01/Variable, TGateway/Gateway/edge-01/RpcQuest and TGateway/Gateway/edge-01/RpcWrite for variable, snapshot-request and write-request Topics.

Follow Configure MQTT upload on each edge for all fields: enable list upload; disable dictionary upload, retained messages, JSON null filtering and offline-data filtering; leave variable scripts/templates empty; check QoS and chunk size. Use a different RemoteKey at each site.

Receiving a remote catalog does not create queryable local variables until its synchronization plan is previewed and applied. Variable addresses are RemoteKey/RemoteVariableId; use the remote ID, not the ID generated at the center.

Collect third-party MQTT devices

For custom JSON, use ordinary MQTT Collection Client or MQTT Collection Server at the site, with Topic and JSONPath variable addresses.

For example, {"data":{"temperature":31}} published to factory/line1/telemetry can use address factory/line1/telemetry;$.data.temperature. Verify the site reads 31 and follows changes, then add this local variable to the step 4 group for synchronization.

Maintenance and troubleshooting

Expansion and maintenance

Record site names, management endpoints, project versions, runtime identifiers, synchronization protocol/port, certificate expiry and backup locations. Keep credentials, PFX files and private keys in controlled storage.

Troubleshoot the failed step

Daily operations: Studio manual, Watchdog manual and Gateway manual.