CONTROLLED TECHNICAL PUBLICATION
PrecisionDCMS Technical Manual
The controlled product and engineering basis for PrecisionDCMS hardware, software, deployment, availability, interfaces, authority, cybersecurity, acceptance, operations and lifecycle support.
- Access
- Open access
- Resource type
- Controlled technical manual
- Primary audience
- Engineers, operators, integrators, commissioning teams, cybersecurity reviewers and qualified project partners
- Product scope
- PrecisionDCMS Field Edition, NX, NX-Cloud, IO, GMS, Site Connector and collectors
TECHNICAL BASIS
A controlled reference for consistent engineering and lifecycle decisions.
The PrecisionDCMS Technical Manual defines the retained product architecture, reference hardware and service profiles, interface requirements, data and quality model, cybersecurity baseline, safety boundaries, commissioning obligations and lifecycle controls used to engineer PrecisionDCMS deployments.
It is written for practitioners who must determine not only what the product monitors, but where monitoring authority resides, how physical and Ethernet-native sources are acquired, what continues during failures, how Standard availability is constructed, how data and commands are governed and which records control the final deployment.
Product reference, not the project record
The Technical Manual is a product reference. The approved order, Basis of Design, authority schedule, submittals, configuration and acceptance records govern the project-specific implementation.
COMPOSABLE PRODUCT ELEMENTS
Select only the physical, local and hosted roles the environment requires.
PrecisionDCMS Field Edition
Industrial edge acquisition and local monitoring for physical I/O, serial interfaces, approved deterministic logic and facility/package systems. Field may operate standalone or as a connected acquisition layer for local NX or NX-Cloud.
PrecisionDCMS NX
Enterprise x86 monitoring for Ethernet-native facility, network, compute, storage and cluster systems. NX may operate as a local Lite or Standard monitoring authority and may optionally federate selected state to NX-Cloud.
PrecisionDCMS NX-Cloud
Hosted monitoring, data, visualization, identity, asset and dependency, workflow, API, reporting and evidence services. NX-Cloud may be shared, logically dedicated, dedicated, customer-cloud or private/sovereign.
PrecisionDCMS IO
A dedicated Field-family interface enclosure for structured field termination, protection, sensor power, isolation, signal conditioning, A/B fanout, test points, diagnostics, quick-connect harnesses and output-authority arbitration.
PrecisionDCMS GMS
An independently engineered gas-monitoring and shutdown-interface package. Local sensing, alarm, annunciation, safety relay and valve or shutdown behavior remain functional without a PrecisionDCMS node, facility network or Cloud service.
Site Connector and distributed collectors
Software roles for site identity, secure federation, protocol acquisition, proxies, agents, exporters, log and event intake, source-health monitoring, buffering and replay.
FIVE SUPPORTED ARCHITECTURES
Monitoring authority is selected by deployment, not assumed.
Scroll horizontally to see the full table.
| Pattern | Primary elements | Monitoring authority | Best fit | Required boundary |
|---|---|---|---|---|
| A — Field Standalone | Field Lite or Standard; optional IO and GMS; complete local runtime | Local Field monitoring stack | Small or moderate facility or packaged-system scope requiring complete local operation without WAN | Not the preferred large-cluster telemetry architecture |
| B — Field + NX-Cloud | Field Connected Edge; optional IO and GMS; Site Connector and proxy; hosted NX-Cloud; cluster collectors | NX-Cloud for hosted alarm, data and workflow; Field for physical acquisition, local continuity and approved local logic | Preferred production pattern when traditional I/O exists and managed hosted scale is desired | Local protective and equipment functions remain independent of hosted availability |
| C — Field + NX Local | Bounded Field acquisition plus local NX Lite or Standard | Local NX; Field remains the physical acquisition and any approved local command-authority layer | Air-gapped, sovereign or fully local facility and cluster operations | Greater on-site hardware, recovery and lifecycle responsibility |
| D — NX Local Only | NX Lite or Standard with direct Ethernet-native collection; no base Field hardware | Local NX | Environments in which every required source is available through an approved IP interface with sufficient detail, quality and feedback | Add a bounded Field package only when physical I/O, serial acquisition or deterministic local behavior is required |
| E — NX-Cloud Only | Hosted NX-Cloud plus approved private or outbound connectivity and software proxies or collectors; no PrecisionDCMS site appliance | NX-Cloud | IT and cluster monitoring or facilities independently monitored through another accepted system | Not a substitute for required local BMS, fire, gas, life-safety or protective systems |
FAILURE DOMAINS, NOT LABELS
Lite and Standard describe deployable availability patterns.
- Lite
- One Field Core or one NX Node. Lite is a complete deployment with an accepted single-node interruption and a defined backup, spare and recovery plan.
- Standard
- Two independently powered and networked matching Field Cores or NX Nodes. Standard means two nodes in separate accepted failure domains. Dual processors, dual power supplies or mirrored disks inside one chassis do not by themselves create Standard availability.
The manual defines Field and NX hardware families, power architecture, network interfaces, storage protection, management access, time, environmental limits, serviceability, spares and recovery. It also defines the acceptance obligations required to validate failover, surviving-node capacity, source continuity, alarm integrity and recovery.
FROM SOURCE TO OPERATING TRUTH
Acquisition preserves source meaning, quality and ownership.
PrecisionDCMS acquires physical points, serial data, Ethernet protocols, APIs, exporters, agents, logs and events through the product role suited to each source. It does not force every source through one controller or translate every domain into a lowest-common-denominator point model.
The manual defines thirteen protocol and interface families plus versioned OEM profiles. Actual support is determined by the selected product role, OEM model, firmware, exposed data, polling or subscription behavior, point count, event rate, authentication, command boundary and acceptance test.
Every normalized value must identify:
- Stable point and equipment identity
- Authoritative source
- Value and engineering unit
- Source time and receive time
- Quality and quality reason
- Staleness behavior
- Control class and commandability
- Schema or profile version
- Tenant and access scope where applicable
- Lineage to the source interface
Source health must be visible
Interface health, backlog, collection delay, authentication failure, stale state, out-of-service state and replay condition must be visible. An unavailable adapter must not create false normal state, false closure or uncontrolled replay.
ENGINEERED FOR HANDOFF AND RECOVERY
The manual connects product architecture to verifiable delivery.
- 01
Discovery and Basis of Design
Define monitored systems, interfaces, physical points, data ownership, authority, local and hosted roles, availability, retention, users, service scope, customer responsibilities and acceptance outcomes.
- 02
Detailed engineering and submittals
Produce architecture, network, power, I/O, panel, interface, cybersecurity, point, alarm, authority, dependency, test and documentation records appropriate to the selected product.
- 03
Staging and FAT
Assemble the approved baseline, load configuration, validate interfaces and simulations, exercise degraded modes, verify recovery assets and capture controlled factory evidence before site deployment.
- 04
SAT and commissioning integration
Validate installed power, network, source interfaces, time, identity, alarms, failures, communications, procedures and approved commands against live or accepted simulated conditions.
- 05
Operational readiness
Confirm users, escalation, runbooks, backup and restore, spares, vendor support, monitoring coverage, ticketing, change control, evidence, customer views and service commencement criteria.
- 06
Lifecycle operation
Maintain the supported baseline, configuration, certificates, credentials, dependencies, capacity, firmware, backups, recovery tests, OEM profiles, evidence and handback package.
WHICH RECORD CONTROLS?
Use the manual as a product baseline, not a substitute for the project record.
Hosted layer
Local node layer
Interface + collection layer
Project records control from the top down. Where a project-specific approved record differs from a general reference publication, the project record controls within its contractual scope. Deviations, exceptions and unsupported combinations must be documented rather than hidden in configuration.
- Executed agreement and approved order
- Approved Basis of Design
- Approved authority and responsibility schedules
- Approved submittals and deviations
- Configured baseline and as-built records
- FAT, SAT, commissioning and operational-readiness acceptance
- Controlled product manuals and reference publications
- General website and marketing material
Major technical subjects
- Product definitions and retained architecture
- Field, NX and NX-Cloud selection
- Lite and Standard availability
- Field Core and NX Node hardware profiles
- PrecisionDCMS IO and GMS
- Power, network and environmental requirements
- Physical I/O, signal duplication and output arbitration
- Site Connector, proxies, agents and collectors
- Protocol families and OEM profiles
- Canonical identity, time, quality and lineage
- Alarm, incident, dependency and evidence models
- Cybersecurity zones, identity and secrets
- Local, hosted and hybrid failure behavior
- Backup, restore and disaster recovery
- Integration with BMS, EPMS, DCIM, CMMS and customer systems
- Engineering, staging, FAT, SAT and commissioning
- Operational readiness and managed operations
- Lifecycle support, upgrade and handback
- Technical specifications, acceptance matrices and glossary
Frequently asked
Questions and answers
- Why is the Technical Manual controlled?
- It contains detailed product architecture, cybersecurity, interface, acceptance and failure-behavior information that should be shared within an established technical and confidentiality boundary. The access process also ensures that reviewers receive the current controlled release rather than a stale draft.
- Does the manual constitute a final project specification?
- No. It establishes the product baseline and engineering rules. The approved order, Basis of Design, authority schedule, submittals, configured baseline and acceptance records define the final deployment.
- Does Standard mean a single server with redundant components?
- No. Standard requires two matching nodes that are independently powered and networked in accepted failure domains. Redundant components within one chassis improve serviceability but do not remove the chassis as a common failure domain.
- Does protocol support imply command support?
- No. Monitoring support, write capability, workflow approval and equipment-changing authority are separate determinations. The default product posture is monitor-only. Any command path is separately engineered, bounded, accepted and audited.
- Can the manual be shared with an EPC, integrator or commissioning provider?
- Controlled sharing may be approved for qualified project participants after scope, confidentiality, document version and distribution responsibility are established.
Related resources
Field vs NX Selection Guide
Select the architecture from physical-interface, autonomy, availability, data-location, workload and operating-authority requirements.
Read resourceHardware and ConfigurationNX Hardware Profiles
Reference B16, S32, A64 and A128 local-node configurations with benchmark inputs, failure-domain requirements and order-specific sizing rules.
Read resourceHardware and ConfigurationIO and GMS Overview
Physical Field termination and signal-conditioning boundaries for IO, plus autonomous gas sensing, annunciation and shutdown-interface boundaries for GMS.
Read resourceCONTROLLED TECHNICAL ACCESS
Establish the review boundary and receive the applicable release.
Provide the project, role and technical scope. PrecisionX will confirm the current manual revision, confidentiality requirements and the companion documents appropriate to the architecture under evaluation.