Selecting Ignition Gateway Hardware for Edge and Central Roles

Karen Mitchell6 min read
Best PracticesOther ManufacturerSCADA Configuration
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

The proposed Ignition deployment has four edge panel gateways and one central gateway, with an estimated 5,000–10,000 tags and limited, slow history. Select each computer by measured gateway load, operating environment, storage duty, and acceptable outage time—not by tag count or the “server” label alone.

Which gateway role is the computer serving?

First confirm what each installation will do. The design describes four edge panel gateways and one central gateway; it does not describe four operator clients. That distinction matters: an edge gateway may collect data and communicate upstream, while the central gateway may carry additional aggregation, visualization, history, or other services. The actual division of work determines resource demand.

Reading to take What it tells you Next check
List gateway services, connected devices, tags, clients, history, and upstream links for each role. Shows whether edge units have similar loads and which services make the central gateway heavier. Compare each role with current Ignition system requirements, then measure representative load.
Confirm whether each edge unit is an edge gateway or a client. Prevents applying the wrong workload assumptions to the computer selection. Record the result in the hardware schedule.

The estimate of 5,000–10,000 tags across the system and history on less than 10% of tags is useful context, not a CPU or memory sizing formula. Gateway count, scan activity, client sessions, database activity, and project design affect load. Obtain vendor sizing guidance for the planned Ignition version and validate with a representative project rather than extrapolating from tag count alone.

What does a representative load test show?

Compare candidate hardware with the intended workload running. Use the same gateway configuration, device connections, client activity, and history behavior expected in service. Record CPU and memory utilization, storage capacity and activity, and whether the gateway remains responsive during normal and peak activity. Establish your own acceptance limits based on the required response and growth margin; the source provides no numeric limits.

Reading If it is high or constrained Next check
CPU utilization during representative and peak activity Gateway work may be CPU-limited; investigate the workload before selecting a faster processor. Check memory, storage, and the relevant gateway task metrics.
Memory use and available headroom Insufficient headroom can contribute to poor responsiveness or paging. Compare installed memory with measured demand and planned services.
Storage capacity, write activity, and response Capacity and write endurance are separate constraints; low history volume does not by itself establish storage suitability. Estimate retained data and write duty, then check the selected drive specifications.

Do not buy the central computer as a faster copy of an edge unit without first checking what runs centrally. Likewise, do not assume a light edge workload means any low-cost computer is suitable: service life, write duty, recoverability, and environmental fit still matter.

Does the control-room environment favor workstation or industrial hardware?

The stated installation environment is a control room, and the design does not require sealed fanless operation. That makes a commercial workstation a candidate, not an automatic choice. Compare its documented operating limits, cooling requirements, component lifecycle, serviceability, and warranty with the actual room conditions and maintenance plan.

The industrial PC candidates named are OnLogic CL250 and Helix 511. The proposed commercial candidate is a Dell Pro Max Micro workstation. These names identify options for evaluation; no processor, memory, drive, operating limit, or lifecycle specification is supplied here, so compare the exact offered configurations against the workload and site requirements.

Option Check at the equipment specification Decision effect
Commercial workstation Operating environment, cooling, serviceability, drive endurance, warranty, and replacement availability Use when its published limits and support path fit the control room and the required outage tolerance.
Industrial or fanless edge computer Temperature limits, thermal performance, processor capability, storage endurance, and service access Use when environmental tolerance or fanless construction has operational value; compare performance and cost rather than treating the category as inherently superior.
Rack server Facility cooling, power, rack depth, service capability, and any redundancy features Consider where central workload or availability requirements justify the added infrastructure and cost.

How much outage can the site accept?

Set the availability target before paying for server features. Ask what happens if an edge gateway or the central gateway fails, how long the process can operate without its data or interface, and how quickly staff can restore service. The acceptable outage period determines whether a single computer with a tested replacement plan is adequate or whether redundancy is warranted.

Server-grade systems may offer ECC memory and out-of-band management, but those features have value only if the site needs and will use them. Redundant power supplies also do not provide meaningful power redundancy when both supplies depend on the same non-redundant source. Review the complete path—computer, power, network, cooling, and recovery process—rather than counting hardware features in isolation.

Cloud hosting is another architectural option, not a default reliability guarantee. Compare connectivity dependence, operating responsibility, failure impact, and recovery expectations against an on-premises installation. If communications loss prevents operators from accessing a hosted gateway, that consequence must fit the process’ outage tolerance.

Will storage and procurement remain supportable?

Storage can be a weak link because gateway and database workloads write data over time. Evaluate both capacity and write endurance for the selected drive; low historian volume does not eliminate other operating-system, gateway, or database writes. Read the drive’s endurance specification and validate it against the expected write duty and replacement plan. Do not substitute a generic “SSD” label for that check.

Check that the specific configuration is currently orderable, has a clear lifecycle and warranty, and can be replaced within the site’s recovery window. The design discussion raises end-of-life listings and component lead times as procurement concerns. Confirm current status with the manufacturer or an authorized reseller before freezing the design, and identify an equivalent qualified replacement if supply risk is unacceptable. The mentioned target budgets—about $1,000 per edge unit and $5,000 for the central gateway—are planning constraints, not evidence that a particular configuration meets the requirements.

How do you qualify and deploy the selected configuration?

Use one qualification process for all candidates and document differences between edge and central roles. The resolving branch is the least-cost configuration that meets the measured workload, environmental limits, recovery objective, and procurement requirements with adequate headroom.

  1. Document the workload and services for every gateway; distinguish edge gateways from clients.
  2. Compare exact computer configurations with current Ignition requirements and manufacturer specifications for operating environment, processor, memory, cooling, drive endurance, warranty, and lifecycle.
  3. Run a representative configuration on the candidate hardware. Record CPU, memory, and storage readings during normal and peak expected activity; test gateway responsiveness and required client and device communications.
  4. Check the failure and recovery path: restore a gateway backup on replacement hardware, verify required project and history behavior, and confirm the recovery time fits the site target.
  5. Confirm availability, lead time, and replacement options for the exact parts before purchasing. Record the tested configuration and baseline readings.

After installation, compare live readings with the qualification baseline, verify the gateway reports normal status, confirm edge-to-central communications and required operator functions, and complete the planned backup-and-restore verification.

Frequently asked questions

How do I size an Ignition gateway for 5,000–10,000 tags?

Do not convert tag count directly into a processor or memory specification. Confirm the work assigned to each gateway, consult current Ignition requirements, and test the representative project while recording CPU, memory, and storage behavior.

How do I choose between a commercial workstation and an industrial PC?

Compare the exact models’ published operating limits, cooling, serviceability, drive endurance, warranty, and availability against the control-room conditions. The control room does not require sealed fanless operation in this design, but the workstation still has to meet those documented requirements.

Does a central Ignition gateway need a server?

Not automatically. Base the choice on measured central workload, acceptable outage time, and whether ECC memory or out-of-band management provides a needed capability; include facility cooling and power in the decision.

How do I verify the selected gateway computer?

Run the representative workload and record CPU, memory, and storage readings, then verify gateway status, edge-to-central communications, operator functions, and a backup restore on replacement hardware against the site’s recovery target.

Back to blog