Skip to main content
PrecisionDCOSPrecisionX CriticalPrecisionDCOS home

Technical search

Jump to any product, solution or page

PrecisionDCMS

The monitoring and management core

PrecisionDCMS is the detailed core of PrecisionDCOS — from field signal to verified evidence. It spans physical acquisition, local and hosted runtimes, point engineering, prime-power coordination and a deep connector library.

Modules
Field · NX · NX-Cloud · IO · GMS
Deployment
5 models (A–E)
Availability
Lite · Standard
Connectors
40+ protocols

Overview

Signal to verified evidence

PrecisionDCMS acquires physical and Ethernet-native signals, gives every point stable identity, time and quality, and carries it through history, operations and evidence — locally, hosted, or both.

Monitor broadly. Command narrowly. Keep protection local.

Modules

Six modules, one core

Adopt the modules your site needs. They share the same identity, quality and authority models.

Signal path

How a value becomes evidence

Every value travels the same governed path so operators trust what they act on.

01

Acquire

Field / connectors

02

Identify

stable IDs

03

Qualify

time + quality

04

Operate

history, alerts

05

Prove

linked evidence

Canonical signal path. Physical and Ethernet-native sources converge into one governed model.

Deployment models

Five patterns from standalone to hosted

The same core deploys five ways. Model B (Field + NX-Cloud) is the preferred production pattern when traditional I/O exists and managed hosted scale is desired.

A

Field Standalone

Cloud dependencyNone

Complete local monitoring runtime with no cloud dependency.

  • Field Lite or Standard
  • Optional IO and GMS
  • Complete local monitoring runtime
  • Local UI, history, users, alerts and permitted commands
  • No cloud dependency

Best for: Small or moderate facility / packaged-equipment scope

B

Field + NX-Cloud

PreferredCloud dependencyAuthoritative

Preferred production pattern when traditional I/O exists and managed hosted scale is desired.

  • Field Connected Edge with PFC and physical acquisition
  • Edge Continuity runtime
  • Zabbix proxy and Site Connector
  • Local queue and fallback view
  • NX-Cloud authoritative monitoring and workflow
  • Cluster collectors and bounded local continuity during WAN loss

Best for: Traditional I/O present, managed hosted scale desired

C

Field + NX Local

Cloud dependencyNone

Full local facility and cluster monitoring with complete data residency.

  • Field acquisition package
  • Local NX Lite or Standard
  • Complete local facility and cluster monitoring
  • Full local data and operations residency

Best for: Sovereign, air-gapped or fully local requirements

D

NX Local Only

Cloud dependencyNone

Direct Ethernet-native acquisition with no base physical I/O.

  • NX Lite or Standard
  • Direct Ethernet-native acquisition
  • No base physical I/O
  • Complete local monitoring, history and operations
  • Add a bounded Field package only when physical or deterministic requirements exist

Best for: Ethernet-native sources; no hardwired I/O required

E

NX-Cloud Only

Cloud dependencyFull

Hosted NX-Cloud with software proxies and collectors — no site appliance.

  • Hosted NX-Cloud
  • Private or outbound connectivity
  • Software proxies and collectors
  • No PrecisionDCMS site appliance
  • Allowed only where facility systems are independently monitored
  • Not a substitute for required local BMS, fire, gas or protective systems

Best for: Independently monitored facility systems; hosted operations

Availability editions

Lite and Standard, defined precisely

Availability language is deliberately unambiguous, because in critical infrastructure the difference decides whether a single failure interrupts operations.

Availability editions and their architectural requirements.
EditionNodesDefinition
LiteOne Field Core or one NX NodeA complete deployment with an accepted single-node interruption and a defined backup, spare and recovery plan.
StandardTwo independently powered and networked matching nodesStandard means two nodes — not two processors or two power supplies inside one server. Independent power and network failure domains, leader/follower or approved active/active collection, no shared-storage dependency in the base local architecture, tested failover, fenced singular actions. Point-level redundancy remains separately engineered.
Availability editions and their architectural requirements.

What Standard is not

Standard is not two processors or two power supplies inside one chassis. Point-level redundancy remains separately engineered.

Redundancy is engineered, not assumed

Node redundancy and point-level redundancy are distinct decisions. Both are specified per configuration rather than implied by an edition name.

Technical FAQs

Frequently asked questions

Explore the family

Related products

Configure PrecisionDCMS for your facility

Bring your I/O inventory, protocols and availability targets. We will map them to a Field, NX and NX-Cloud configuration.