System Settings
System settings are used to maintain dual-machine hot standby (master-standby switching), alarm recovery strategies, network parameters, time synchronization, system control, and PING (network connectivity testing). After entering the page, you can switch between different configuration modules via the left navigation side.
System settings are part of the operation and maintenance function. Before modifying the network, time, redundancy, or performing a restart, confirm the maintenance window, remote connection method, and backup configuration; Do not arbitrarily adjust these parameters during critical stages of equipment operation on the production floor.
First, look at the terminology
| Terminology | On-site understanding |
|---|---|
| Dual-machine hot standby | Two gateways form the same redundant group, and at the same time, the authorized unit is responsible for data collection, data forwarding, alarming, and rule engine tasks. |
| Current Working/Standby | Current Work Node undertakes production tasks; The standby node remains connected and synchronized, and production tasks can only start after meeting the takeover conditions. |
| Connection Check | Regularly confirm that the two gateways are online at the endpoint. After consecutive link failures, the system then uses shared arbitration authorization to determine whether takeover is permitted. |
| Shared arbitration | The same SQLite file accessible by both gateways. The system uses file locks and short leases to allow only one machine to obtain work authorization, not an independent third node. |
| PING | network connectivity test. PING only indicates that the IP is reachable and does not necessarily mean that Web, database, MQTT, or PLC ports are always available. |
| DHCP | automatically acquires IP, gateway, and DNS. Production gateways are generally recommended to use a fixed IP to avoid address changes after reboot. |
| DNS | domain name resolution server. When using domain names to connect to services like MQTT, OPC UA, Webhook, NTP, etc., you need to have a usable DNS. |
| NTP / UTC | NTP is the server for automatic time calibration; UTC is the Universal Standard Time. Alarms, historical data, and log checks rely on accurate timing. |
Function Entry
After logging into GatewayRuntime Web, enter "System Management → System Settings."
Module List
| Module | Purpose |
|---|---|
| Dual Machine Hot Standby | View local roles, four types of production tasks, peer connections, and arbitration authorization status, configure node identity, dual network link, TLS, shared arbitration, and historical compensation. |
| Alarm Configuration | Configure whether the alarm is removed directly from the real-time alarm list after recovery. |
| Network Configuration | View network card information and edit DHCP, IP, subnet mask, gateway, and DNS server. |
| Time Sync Configuration | View local time, UTC time, and time zones, manually set system time, configure NTP servers, and sync intervals. |
| System control | Restart the GatewayRuntime runtime, restart the application, download and configure database backups. |
| PING Test | Perform connectivity tests on specified IPs or domain names, checking successes, failures, packet loss rates, average latency, and per-packet results. |
Dual Machine Hot Standby
Click "Dual Machine Hot Standby" on the left. The page centrally displays the current node, local role, peer connection, shared arbitration authorization, configuration summary, and historical data protection, and provides operations such as editing, refreshing, immediate synchronization to the peer, and manual switching between primary and standby devices.
| Area | Key Check |
|---|---|
| Current node | Is this machine currently working, standby, taking over, needing processing, or a failed switch; Check whether the four types of tasks—collection, data forwarding, alarm, and rule engine—are consistent with the local role. |
| Peer Connection | The transmission status, complete health, number of consecutive failures, identified peer nodes, and peer roles of each link. Only after establishing a connection and passing group name, node identity, role, and security validation can the link be complete and healthy. |
| Task Authorization | After configuring shared arbitrage, confirm that the authorization is held by and only the current worker node, and check the authorization expiration date, master-standby handover serial number, and recent switch errors. |
| Historical Data Protection | View protected targets, peer synchronization, write-to-database status, journal, and database write authorization status. |
Click "Edit Configuration" to open the dual-machine hot standby side panel.
| Configuration Items | Description |
|---|---|
| Enable dual-machine hot standby | After activation, the two gateways will run as master-standby roles. After shutting down, the machine runs independently and does not participate in peer connection or arbitration. |
| Redundant group name | Both gateways must fill in the same non-null name. Nodes with inconsistent names cannot establish control relationships. |
| Local node name | Stable unique name of the current gateway. Required when enabling dual-machine hot standby; two gateways cannot use the same name. |
| Peer node name | Name of another node the current gateway expects to connect. Required when enabled, and must be exactly the same as the "local node name" of the counterpart to avoid incorrect node access. |
| Connection Method | One unit selects "Waiting for Peer Connection," the other selects "Active Connection to Terminal"; The roles at both ends must complement each other. |
| Peer address | Address of the first control connection, usually IP:port, without http:// or https://. The listening side enters its local listening address; the connecting side enters the reachable peer address. |
| Dual Network / Second Link Address | Required after second link enabled and cannot be the same as the first link. It is recommended that the two links use different network cards, switches, or segments; Any complete health chain can maintain end-to-end online judgment. |
| Connection keys at both ends | Both gateways must fill in the same complex string for control link identity verification. It is not equivalent to link encryption. |
| Local connection certificate / Trusted root certificate / Peer certificate Hostname | Bidirectional TLS configuration optional. All three fields must be filled in or left blank; The hostname or IP should exist in the peer service certificate SAN. Each gateway selects its own connection certificate and trusts the root certificate issued by the peer certificate. |
| Encryption protocol / Check if certificates have been revoked | Set permitted protocol versions and revocation check policies when using TLS; No special requirements should use the system security default values. |
| Arbitration files shared between two machines | Recommended production environment configuration. Both gateways must point to the same SQLite file on shared storage, and the system allows only one to obtain work authorization through file locks and short leases. You can use a consistent UNC path or shared storage mount path on both ends, and ensure both ends have read/write and file lock capabilities. |
| Work authorization duration | Shared arbitration lease validity period, unit milliseconds, minimum 3000, default 15000. |
| Work Authorization Renewal | Lease renewal period, unit: milliseconds, minimum 500, and must not exceed one-third of the authorized duration; Default is 3000. |
| Switch safety margin | nodes must stop production tasks in advance. The safety window, unit, milliseconds, minimum 500; the sum of the renewal cycle must be less than the authorized duration, default 2000. |
| Connection Inspection Interval | End-to-end connection inspection interval, unit: milliseconds, minimum 1000, default 60000. Too small increases network load, while too large lengthens fault detection time. |
| Number of disconnection checks | After all configured links fail continuously and reach this threshold, fault handling begins, ranging from 1 to 100, default 3. When configuring shared arbitration, nodes must still obtain work authorization to activate production tasks. |
| Data Synchronization Interval | The interval between the current working node and the standby node synchronizing configuration and variable data, unit: milliseconds, minimum 1000, default 1000. |
| Historical Data/Alarm Compensation | When enabled, supported historical targets first write the local reliable Journal, then synchronize to the peer, and fill in after switching or database recovery. This ability is enabled by default and is independent of the target's own dual-database mirroring. |
| Historical Protection Parameters | Can adjust the number of synchronizations per session, peer confirmation timeout, local waiting for synchronization limit, database write authorization duration and renewal, and failure retry interval. Set by disconnection duration, historical write volume, network latency, database load, and disk capacity. |
After upgrading the configuration of the old dual machines, you should not keep only the original address and connection key. Please first fill in the names of redundant groups, local nodes, and end-to-end nodes on both gateways, then check that the connection methods are complementary, that both ends have consistent keys, and configure shared arbitration and TLS according to production risk. After saving, confirm the counterpart identity, link integrity and health, arbitration authorization, and the status of four types of production tasks, before conducting the switching drill.
Historical Data and Historical Alarm Reliability
After dual-machine hot standby is enabled, historical data and alarms can use main and backup historical compensation. This feature is enabled by default: the system saves historical events to the local Journal and synchronizes them to the peer node; Before a node obtains work authorization and becomes the current working node, it will first fill in any incomplete entries and avoid duplication by using the unique record key when writing to standard SQL history tables. Therefore, after master-standby switching, short-term interruptions on the peer link, or runtime reboots, historical records still in the local Journal or offline cache can be rewritten, preventing duplicate writes of already stored records.
| Project | Description |
|---|---|
| Applicable Subjects | Historical data objectives, historical alarm objectives. |
| Prerequisites | Enable dual-machine hot standby and keep the "Historical Data/Alarm Compensation" switch on. |
| Applicable databases | Standard SQL write links: SqlServer, MySQL, Sqlite, PostgreSQL. |
| Not applicable | QuestDB, TDengine, custom SQL patterns, historical table scripts, historical alarm table scripts, and other custom write links are not included in this deduplication and completion mechanism. |
| On-site Recommendations | It is recommended to enable offline caching simultaneously for historical data and alarm targets, and reserve disk space based on offline time, write volume, maximum number of rows retained in journals, and maximum rows in cached files. Before going live, verify master-standby switching, disconnection, temporary database unavailability, and restart recovery in the maintenance window. |
Historical Data Protection Diagnostics
The "Historical Data Protection" area is used to confirm whether historical targets support master-reserve compensation, whether there is backlog in the journal, and whether the current node holds authorization to write to the target library. After enabling dual-machine hot standby and configuring historical data or alarm targets, it is recommended to check the area after joint debugging, switching drills, and recovery.
| Region | Description |
|---|---|
| Overview Metrics | Displays the current node, maximum sequence, The number to be synchronized to the peer and the number to be written to the database. If backlog remains above zero for a long time, check the dual-machine link, peer node, target database, and offline cache. |
| Filter Conditions | You can filter events by Journal target key, source node, record type, record unique key, and whether to wait for Peer or DB. |
| Target Support | Lists the reliable synchronization status of historical data targets and historical alarm targets, plugin names, target types, reasons not supported, and Journal target keys. |
| Journal Status | Summarizes the maximum sequence, total rows, pending Peer, pending DB, earliest backlog time, and latest event time by target key, source node, and record type. |
| Epoch Lease | View the holding node, lease expiration date, and current status of the target library lease, used to determine whether the current node has inscription rights. |
| Journal Events | View the sequence of individual historical events, source nodes, record types, record unique keys, peer/DB tags, and raw loads, suitable for locating a variable or alert for why it hasn't been updated. |
When the protection status is "Not Supported," common reasons include enabling custom SQL, enabling historical table scripts, or using QuestDB, TDengine, or other non-standard SQL write links. Such targets can still use their own offline cache, but do not include idempotent completion and diagnostic statistics in the main and secondary history.
The shared arbitration file is not an independent third node, but the same SQLite file accessible to both gateways. If shared arbitration is not configured, it will enter link-only active-standby mode, and network partitioning may cause active trading. When all three TLS items are left blank, the two-end connection key is still used for identity verification, but the link content is unencrypted TCP. Production deployments should be configured with reliable shared storage and certificates, and verify scenarios such as broken chain, power outage, shared storage unavailability, recovery, and manual switching at maintenance windows.
Alarm Configuration
Click "Alarm Configuration" on the left. This module is used to set the handling method after alarm recovery.
| Configuration Items | Description |
|---|---|
| Remove immediately after alarm recovery | Once enabled, remove alarms from the real-time alarm list during recovery; When closed, the restored alarm still needs to be confirmed before being removed. |
The switch will save immediately after switching. Before modifying the production environment, confirm the duty and alarm confirmation processes to avoid premature removal of alarms during resumption.
Network Configuration
Click "Network Configuration" on the left. The page displays the current network card list and supports refreshing and editing.
| Column | Description |
|---|---|
| Network card name | Network interface name. |
| Description | Network interface description. |
| Type | Network interface type. |
| Status | Enabled or disabled status. |
| IP address | current network card IP. |
| Subnet mask | Current subnet mask. |
| Gateway | Default Gateway. |
| MAC address | physical address of the network card. |
| DHCP | whether DHCP is enabled. |
| Operation | Open the network configuration side panel. |
When editing network configurations, the following fields can be maintained.
| Configuration Items | Description |
|---|---|
| Network Card Name | Read-only displays the current network card. |
| Enable DHCP | After activation, the system automatically obtains network parameters. |
| IP address | displayed and editable when DHCP is closed. The fixed address of the gateway operating host in the field network should be filled in. |
| Subnet mask | displayed and editable when DHCP is closed. It must match the on-site network segment plan; incorrect entries will prevent devices on the same network segment from accessing it. |
| Gateway | displayed and editable when DHCP is closed. When accessing cross-subnet devices, NTP servers, or external platforms, the correct default gateway must be provided. |
| DNS Server | supports multi-value input and allows you to choose or manually create DNS addresses. When accessing MQTT, Kafka, OPC UA, Webhook, or NTP services using domain names, you need an available DNS. |
Modifying the network card, gateway, or DNS may cause the current web connection to be interrupted. Before saving, please confirm the remote access method and backup connections on site.
After enabling DHCP, IP, subnet masks, gateways, and DNS are assigned by the network environment, and addresses may change after device reboot or lease updates. When the production gateway requires a fixed access address, static IPs are prioritized or fixed leases are bound to the on-site DHCP server.
Time Sync Configuration
Click "Time Sync Configuration" on the left. The page is divided into two sections: "System Time" and "NTP Configuration."
| Area | Configuration Items | Description |
|---|---|---|
| System time | Local time | Host local time. |
| System time | UTC time | current UTC time. |
| System time | Time zone | Name of the host time zone. |
| System time | time zone ID | Host time zone identifier. |
| System Time | Set Time | Open the "Set System Time" side panel, select a new time, and confirm save. |
| NTP Configuration | Enable NTP | Control whether NTP Auto-Sync is enabled. |
| NTP configuration | NTP server | displays after enabling NTP, supporting multi-selection, filtering, and manual creation. |
| NTP configuration | synchronous interval | displays a range of 1 to 1440 minutes after enabling NTP. |
| NTP configuration | instant synchronization | executes NTP synchronization instantly. |
| NTP configuration | save | save NTP enabled status, server list, and sync interval. |
Manually setting system time affects collection timestamp, alarm time, historical data storage time, and certificate verification. After enabling NTP, you should specify the time server that the gateway can access; When the intranet cannot access the public network, use the on-site intranet NTP server. The synchronization interval is measured in minutes, ranging from 1 to 1440.
System Control
Click "System Control" on the left. This module provides runtime reboot, application restart, and configuration database backup.
| Operations | Description |
|---|---|
| Restart the Runtime | Restart the GatewayRuntime runtime. A confirmation popup will appear before execution. Suitable for scenarios such as reloading the runtime after saving or restarting to recover abnormal collection. |
| Restart the software | Restart the application. After execution, the web connection will be interrupted and you need to reconnect. Suitable for scenarios where the application itself is abnormal or system parameter adjustments require a full reboot. |
| Backup Configuration Database | Download a coherent SQLite single-file snapshot containing WAL committed data that can be opened independently for configuring backups or delivering archives. For large-scale configuration, modify network parameters, adjust dual-machine hot standby, or back up before release, it is recommended. |
Operations involving runtime or application restart may affect collection, data forwarding, and web connections. Please perform in the maintenance window.
PING Test
Click "PING Test" on the left. After entering the target address, you can set the number of tests and timeout, then click Start Test.
| parameters | Description |
|---|---|
| Destination address | IP address or domain name to be tested. |
| Number of tests: | number of PING requests, ranging from 1 to 20. |
| Timeout | Timeout per request, ranging from 1000 to 30,000 milliseconds. |
| Start testing | perform PING tests. |
| Clear results | Clear the current test results. |
After testing, the page displays summary cards and packet-by-package tables.
| Results | Explain |
|---|---|
| Target hosts | Actual response target hosts. |
| Number of Successes | Number of Successful Responses. |
| Number of failures | Number of times no response or errors occur. |
| Packet loss rate | failure rate. |
| Average latency | Average round-trip time for successful requests. |
| Delay range | Minimum and maximum round-trip times. |
| Packet-by-packet results | Status, response address, latency, TTL, and error messages for each request. |
successful PING only indicates that the network layer is reachable and cannot prove that MQTT, OPC UA, database, or Webhook service ports are available. If ping succeeds but business connection fails, continue to check the destination port, firewall, account password, certificates, and protocol configuration.
Related Links
- Collection Configuration - Channel, Device, Variable, Alarm, and Value Filtering Configuration
- Data Forwarding - Configuration of Historical Data, Real-Time Data, Historical Alarms, etc.
- Development Interface: Gateway API Documentation - Settings Page Related Interfaces