Designing Ignition Server and Thin Client Architecture

Overview: What Runs Where

The most common design mistake in a first Ignition deployment is collapsing two distinct roles into one machine. Ignition is a server-centric platform: the gateway runs the project, drivers, tag engine, historian and alarming; the client only renders the session. Once you accept that split, the control-room question — "do I need servers, or can the operator stations run the software?" — answers itself.

Four operators with four keyboards and four mice equals four clients, not four servers. Those clients never hold the project logic, tag database or driver connections; they hold a display session that the gateway serves.

Client Hardware: Thin Clients Are Sufficient

If the application is built in Perspective, the client requirement is simply a device capable of running a modern web browser and presenting a desktop environment to the operator. A small fanless industrial thin client (OnLogic-class or equivalent) meets this without qualification. A dedicated Perspective Workstation application is available for a kiosk-style, chrome-less experience with multi-monitor handling, but it is optional — a browser pointed at the gateway URL is a fully supported client.

Practical selection criteria for the operator station:

• Enough CPU/GPU to drive the intended monitor count and resolution smoothly — graphics rendering is the client's only real workload.
• SSD boot media and an OS image you can re-flash quickly; a failed thin client should be a 10-minute swap, not a rebuild.
• Wide-temperature, fanless construction if the station sits in a panel or an unconditioned room.
• Dual NIC or a managed VLAN port if the operator LAN is segregated from the control network.

Gateway Servers and Redundancy

Redundancy in Ignition means two physically separate gateway servers configured as a master/backup pair. This requires:

1. Two server machines, ideally identical in CPU, memory and storage so failover performance is predictable.
2. Two licenses — the backup gateway is a licensed installation, not a free spare. Budget for this at the quotation stage; it is the single most frequently missed line item.
3. A reliable network path between master and backup for state synchronization, plus reachable paths from both gateways to every PLC and to every client subnet.
4. Project and tag configuration maintained on the master and replicated to the backup, so a failover does not present operators with a stale project.

If you delete the two servers and run the software directly on operator workstations, you have not simply saved money — you have changed the architecture. Each workstation becomes its own gateway with its own driver connections and its own tag database, you multiply your device connections and licenses, and there is no coordinated failover. That is not redundancy; it is four independent, divergent SCADA systems sharing a control room.

Sizing: Reading the Hardware Recommendation Correctly

Ignition publishes hardware guidance in tiers. The medium tier reads:

The tier is defined by the combination of all four columns, not by any single one. It describes a gateway that is simultaneously polling up to 25 devices, maintaining 10,000 tags, and serving up to 20 concurrent client sessions. Your loading is compared against the whole envelope:

A four-operator, 10,000-tag system sits comfortably inside the medium tier on the client axis (4 of 20 sessions) and at the stated limit on the tag axis. A current-generation 1U rack server such as a Dell PowerEdge R350 exceeds the 4-core/4 GB/SSD baseline by a wide margin, so CPU and RAM are not the constraint. The scale reference point worth remembering: a 10,000-tag gateway is not an inherently heavy workload — the platform will run that tag count on hardware far smaller than a rack server.

Where to spend the headroom

• Memory: allocate generously beyond the 4 GB baseline and set the gateway JVM heap explicitly. Historian queries and many concurrent Perspective sessions are the memory consumers, not idle tags.
• Storage: SSD is called out in the recommendation for a reason — historian and alarm-journal writes are I/O-bound. Separate the OS volume from the database/history volume where possible.
• Cores: extra cores buy you concurrency for client rendering, scripting and query execution rather than raw tag throughput.

Reference Architecture for Four Operators

Control Network (PLCs / VLAN A)
        |
  +-----+------+                +-------------+
  | Gateway A  |<== redundancy ==>| Gateway B  |
  | (master)   |   sync link      | (backup)   |
  +-----+------+                +------+------+
        |                              |
        +----------- Operator LAN (VLAN B) ------+
              |        |        |        |
           TC-01    TC-02    TC-03    TC-04
        (browser / Perspective Workstation)

Deployment sequence:

1. Install and license Gateway A. Configure device connections, tags, and the project. Validate against the PLCs before touching redundancy.
2. Install and license Gateway B on identical hardware. Configure the redundancy pair (master/backup) and confirm the backup receives the project and tag configuration.
3. Assign the gateways static IP addresses on both the control and operator subnets, or place a virtual/front-end address in front of the pair so clients follow failover automatically.
4. Image one thin client fully — OS hardening, auto-login to a locked operator account, browser or Perspective Workstation launching the project URL at startup, screen blanking disabled — then clone it to the remaining three.
5. Label each station and assign per-station identity if your project uses location-aware screens or per-terminal security roles.

Verification and Commissioning Tests

1. Session count: open all four operator sessions simultaneously and confirm the gateway status page shows four active sessions with no license warning.
2. Failover: with all four clients live, power down Gateway A. Record time-to-reconnect on each client and confirm tag values resume updating from Gateway B. Repeat for a network-cable pull, which exercises a different failure path than a clean shutdown.
3. Failback: restore Gateway A and confirm the pair returns to the intended master/backup roles without duplicate device connections.
4. Loaded performance: with all sessions open on the busiest screen, watch gateway CPU, heap usage and tag-group execution overrun on the gateway status pages. Sustained overruns mean scan classes are too aggressive for the tag count, not that the server is undersized.
5. Historian sizing: log for a representative period, measure actual database growth per day, and project it against the retention requirement before the disk fills in production.
6. Client recovery: pull power on one thin client. It must boot straight back into the operator session with no login or browser interaction required.

Common Design Errors