Is NX always cloud-hosted?

No. PrecisionDCMS NX is the local x86 product family. NX-Cloud is the hosted service. A project may use local NX, NX-Cloud, both in a federated design or neither where Field Standalone is sufficient.

Is Field required at every site?

No. Field is required when the project needs physical I/O, serial acquisition, approved deterministic local behavior, structured IO/GMS interfaces or other industrial-edge functions. An Ethernet-native site may use NX Local Only or NX-Cloud Only when all facility monitoring and protection boundaries are otherwise satisfied.

Can Field and NX both be Standard?

Yes. Availability is applied to each on-site product role independently. A deployment may use Field Standard and NX Standard when both the physical acquisition layer and local monitoring authority require two independent matching nodes.

Which architecture is preferred?

Field + NX-Cloud is the preferred production pattern when traditional I/O exists and managed hosted scale is desired. That does not make it universal. Local, sovereign, air-gapped, small-package or independently monitored environments may require another supported pattern.

Does the guide replace detailed sizing?

No. It establishes the architecture and sizing inputs. Final capacity requires the order-specific workload model, hardware or service profile selection and accepted benchmark where needed.

PRECISIONDCMS SELECTION GUIDE

Field vs NX Selection Guide

Choose the deployment architecture from the signals, systems, autonomy, data location, workload and operating responsibilities the site actually requires—not from a preferred controller or server.

Talk to engineering Request an Architecture Review

Access: Open access
Resource type: Architecture-selection guide and worksheet
Primary audience: Facility, controls, IT, platform, owner’s engineering and solution-architecture teams
Product scope: Field Edition, NX, NX-Cloud, IO, GMS and collectors

START WITH THE REQUIREMENT

Select the monitoring authority first. Add physical hardware only where the interface or local behavior requires it.

Field, NX and NX-Cloud are complementary product roles, not successively “better” editions of one appliance. Field is selected for physical and deterministic site requirements. NX is selected for enterprise x86 monitoring of Ethernet-native facility, network, compute, storage and cluster systems. NX-Cloud is selected for hosted monitoring authority, multi-site services, customer access and managed scale.

The correct architecture may use one role, combine Field with local NX, combine Field with NX-Cloud or use distributed collectors without a PrecisionDCMS site appliance. The selection must state where monitoring authority resides, what continues during WAN or node loss and which local systems remain responsible for protection.

Begin with interface, autonomy, availability, data location and workload. Do not begin with a preferred box.

REQUIREMENTS MATRIX

Six questions determine the base architecture.

Scroll horizontally to see the full table.

Six decision dimensions for PrecisionDCMS architecture selection
Dimension	Questions to answer	Selection effect
1 — Physical interface	Are required points exposed only as dry contacts, digital outputs, 4–20 mA, RTD, analog voltage, pulse, serial or another field interface? Is signal isolation, duplication, sensor power, testability or hardwired annunciation required?	Select a Field acquisition role. Add PrecisionDCMS IO where structured termination, A/B fanout, diagnostics, signal conditioning or future Standard conversion is required.
2 — Local autonomy	Must monitoring, history, local user access, alarm behavior, approved local logic or outage buffering continue without WAN? What is the accepted duration and reduced operating mode?	Select Field Standalone or local NX when complete local monitoring authority is required. Select Field + NX-Cloud only when bounded local continuity and hosted authority meet the requirement.
3 — Monitoring scope and workload	How many active items, values per second, events, logs, devices, users, reports and integrations are expected? Does the scope include servers, BMCs, GPUs, DPUs, fabrics, storage or cluster services?	NX or NX-Cloud is normally the primary monitoring platform for large Ethernet-native and full-stack workloads. Field is not the preferred high-cardinality cluster telemetry plane.
4 — Data location and isolation	Must history, identities, workflow, evidence or customer access remain local? Is shared hosted, logically dedicated, dedicated service cell, customer cloud or private/sovereign deployment acceptable?	Select local NX for complete local data and operational residency. Select the NX-Cloud isolation profile that matches contractual, regulatory and customer requirements.
5 — Availability and failure domains	Is a single-node interruption accepted? Which power, network, rack, room, site or region failures must be tolerated? What workload must the surviving node or service cell carry?	Apply Lite or Standard independently to Field and local NX. Standard requires two matching nodes in independent accepted failure domains. Hosted recovery is selected separately by service profile.
6 — Authority and responsibility	Who may observe, acknowledge, approve, command, administer and change each system? Which functions must remain local? Who owns incident coordination, field response, backup, recovery and lifecycle maintenance?	Define the authority schedule and operating tier before enabling integrations. Connectivity alone never grants command authority.

FIVE SUPPORTED PATTERNS

Use the smallest architecture that fully satisfies the requirement.

A — Field Standalone

Choose Field Standalone for a small or moderate facility or packaged-system scope that requires complete local monitoring and physical acquisition without WAN dependency. Use Field Lite when an accepted single-node interruption is permitted; use Field Standard when two independent matching Field Cores are required.

B — Field + NX-Cloud

Choose Field + NX-Cloud when traditional I/O or serial acquisition exists and the project wants hosted full-stack monitoring, data, identity, workflow, evidence and managed multi-site scale. This is the preferred production pattern for those conditions. Define the bounded local view, alarm subset, buffering and local-response behavior for hosted or WAN impairment.

C — Field + NX Local

Choose Field + NX Local when physical acquisition is required and complete facility and cluster monitoring must remain local. Field owns the physical interface and any accepted local field behavior; local NX owns full monitoring, history and operations. This pattern carries greater on-site hardware and lifecycle responsibility.

D — NX Local Only

Choose NX Local Only when every required source is available through an approved Ethernet interface with adequate data, quality, authentication and feedback, and when complete monitoring authority must remain local. Add a bounded Field package only if physical or deterministic requirements emerge.

E — NX-Cloud Only

Choose NX-Cloud Only for IT, cluster or independently monitored facilities that can use approved outbound or private collectors without a PrecisionDCMS site appliance. Do not use this pattern as a replacement for required local BMS, fire, gas, life-safety or protection.

DECISION WORKFLOW

Resolve the architecture in this order.

Requirement inputsInterface · autonomy · data location

Industrial interface / local autonomy

PrecisionDCMS Field EditionField acquisition

Ethernet-native / higher throughput

PrecisionDCMS NXLocal node

Combine where the estate is mixedField + NX + collectors

The selection sequence flows top to bottom: establish scope, mark the physical-interface boundary, select monitoring authority, define degraded modes, size the platform, apply availability and isolation, define authority and safety, then produce the project record.

01Step 1 — Establish the monitored and managed scope. Inventory facility, network, security, server, BMC, accelerator, fabric, storage, cluster and shared-service sources. Identify which are merely visible, which are authoritative and which require operational workflow.
02Step 2 — Establish the physical-interface boundary. Mark every required DI, DO, analog, RTD, pulse, serial, hardwired alarm, local annunciation and independently powered safety interface. These requirements establish the bounded Field and IO/GMS scope.
03Step 3 — Select the monitoring authority. Decide whether the complete monitoring, history, users, alerts and workflows reside in Field, local NX or NX-Cloud. Do not leave the answer implicit.
04Step 4 — Define degraded modes. State what operators see and do during node, network, WAN, hosted-service, identity and source-system impairment. Define buffer capacity, staleness, failover, local access and recovery.
05Step 5 — Size the platform. Use measured or conservatively modeled active items, sustained values per second, event rate, API cost, logs, retention, users, reports, collector duties and surviving-node load. Validate exceptional workloads through benchmark.
06Step 6 — Apply availability and isolation. Select Lite or Standard for on-site nodes and the required shared, dedicated or private hosted profile. Place matching Standard nodes in accepted independent failure domains.
07Step 7 — Define authority and safety. Publish who may read, acknowledge, administer, approve and command. Keep local protection independent. Do not enable a command path simply because the source protocol technically permits a write.
08Step 8 — Produce the project record. Capture the selection in the Basis of Design, architecture, equipment schedule, data-flow diagram, responsibility matrix, authority schedule, failure-mode narrative, point and asset inventory and acceptance plan.

AVOID FALSE SIMPLICITY

The wrong architecture often begins with an unstated assumption.

“Ethernet-native” is assumed without inspecting the interface

An equipment Ethernet port may expose only a limited web page, proprietary service tool or incomplete register set. Confirm data, quality, events, authentication, polling behavior and supported firmware before removing Field acquisition.

A cloud dashboard is mistaken for local protection

Hosted monitoring may detect and communicate an abnormal condition. It does not become the required local protective device or life-safety system.

Standard is represented by one chassis

Dual CPUs, power supplies and disks improve component resilience. They do not remove the chassis, rack or upstream network as common failure domains.

Field is sized as the full cluster telemetry plane

Field is appropriate for bounded physical and facility acquisition. High-cardinality server, accelerator, fabric, storage and cluster monitoring normally belongs on NX or NX-Cloud.

Data location is discussed without monitoring authority

“Local data” may refer to a cache, full history, evidence, user identity or the authoritative alarm engine. State exactly which functions are local and which are hosted.

Write capability is mistaken for approved authority

A writable register or API is not a command design. Define owner, preconditions, interlocks, expiration, feedback, rollback, audit and test before any action is enabled.

WHAT THE GUIDE PRODUCES

A selection that can be carried into engineering.

The document should include fillable or printable worksheets for:

Monitored-system and source inventory
Physical I/O and serial-interface inventory
Source-data and OEM-profile qualification
Monitoring-authority decision
Local-continuity and outage requirement
Active-item, value-rate, event and retention estimate
User, report, API and tenant estimate
Lite versus Standard failure-domain decision
NX-Cloud isolation and recovery decision
Read, acknowledge, administer and command authority matrix
Safety and local-protection boundary
Existing BMS, EPMS, DCIM, CMMS and customer-system retention
Connectivity and collector pattern
FAT, SAT and operational-readiness implications
Open assumptions, exceptions and validation actions

Frequently asked

Questions and answers

Is NX always cloud-hosted?: No. PrecisionDCMS NX is the local x86 product family. NX-Cloud is the hosted service. A project may use local NX, NX-Cloud, both in a federated design or neither where Field Standalone is sufficient.
Is Field required at every site?: No. Field is required when the project needs physical I/O, serial acquisition, approved deterministic local behavior, structured IO/GMS interfaces or other industrial-edge functions. An Ethernet-native site may use NX Local Only or NX-Cloud Only when all facility monitoring and protection boundaries are otherwise satisfied.
Can Field and NX both be Standard?: Yes. Availability is applied to each on-site product role independently. A deployment may use Field Standard and NX Standard when both the physical acquisition layer and local monitoring authority require two independent matching nodes.
Which architecture is preferred?: Field + NX-Cloud is the preferred production pattern when traditional I/O exists and managed hosted scale is desired. That does not make it universal. Local, sovereign, air-gapped, small-package or independently monitored environments may require another supported pattern.
Does the guide replace detailed sizing?: No. It establishes the architecture and sizing inputs. Final capacity requires the order-specific workload model, hardware or service profile selection and accepted benchmark where needed.

Related resources

Hardware and Configuration

NX Hardware Profiles

Reference B16, S32, A64 and A128 local-node configurations with benchmark inputs, failure-domain requirements and order-specific sizing rules.

Read resource Hardware and Configuration

IO and GMS Overview

Physical Field termination and signal-conditioning boundaries for IO, plus autonomous gas sensing, annunciation and shutdown-interface boundaries for GMS.

Read resource PrecisionDCMS

PrecisionDCMS Technical Manual

Controlled product requirements for Field Edition, NX, NX-Cloud, IO, GMS, Site Connector, collectors, software, cybersecurity, commissioning, operations and lifecycle.

Read resource

SELECT THE RIGHT AUTHORITY

Turn the requirements into a defensible deployment pattern.

Provide the source inventory, physical interfaces, data-location requirements and expected workload. PrecisionX will help identify the smallest supported architecture that meets the operating and failure-mode requirements.

Request an Architecture Review Talk to engineering