FIELD INTERFACE AND GAS-SAFETY BOUNDARIES
PrecisionDCMS IO and GMS Overview
Two deliberately separate hardware products: one creates a maintainable, testable interface between field wiring and PrecisionDCMS Field Cores; the other preserves autonomous gas detection, annunciation and shutdown behavior independent of the monitoring platform.
- Access
- Open access
- Resource type
- Hardware and product-boundary overview
- Primary audience
- Controls, electrical, mechanical, process-safety, facility, commissioning and owner’s engineering teams
- Product scope
- PrecisionDCMS Field Edition, IO and GMS
ONE MONITORING SYSTEM. DIFFERENT AUTHORITY CLASSES.
Field termination and gas protection must not be collapsed into one ambiguous enclosure.
PrecisionDCMS IO — interface enclosure
PrecisionDCMS GMS — autonomous safety
PrecisionDCMS IO and PrecisionDCMS GMS may appear together in a Field deployment, but they perform fundamentally different functions.
PrecisionDCMS IO is a Field-family interface product. It creates a controlled landing point for field wiring and presents factory-tested A and B harnesses to Field Cores. It improves termination quality, protection, isolation, signal conditioning, diagnostics, testability, redundancy and future serviceability.
PrecisionDCMS GMS is a separately engineered gas-monitoring and shutdown-interface product. Its detector, local alarm, annunciation, safety relay and final-element behavior remain functional without a PrecisionDCMS node, facility network, WAN, NOC or Cloud service. PrecisionDCMS receives approved monitor-only status and evidence; it does not become the gas-safety controller.
Local gas safety executes without the monitoring platform
The monitoring platform may report a gas condition. The local gas-safety system must still detect, alarm and execute its engineered protective action when the monitoring platform is unavailable.
STRUCTURED FIELD INTERFACE
One controlled landing point for physical signals.
PrecisionDCMS IO is a dedicated Field-family interface enclosure for termination, protection, sensor power, isolation, signal conditioning, A/B fanout, test points, diagnostics, quick-connect harnesses and output-authority arbitration.
- 01
Field termination
Bring permanent field wiring to labeled, serviceable terminals rather than moving field conductors between controllers during an availability upgrade or hardware replacement.
- 02
Protection and power distribution
Provide order-specific branch protection, surge or transient protection, protected sensor power and distribution appropriate to the signal class and installation environment.
- 03
Isolation and signal conditioning
Apply galvanic isolation, conversion, scaling, filtering, burden, loop power or other accepted conditioning required to preserve source integrity and protect connected interfaces.
- 04
A/B fanout
Present mechanically keyed, factory-tested harness groups to matching Field Cores. The signal-redundancy class determines whether a source is passively observed, actively isolated, duplicated or switched.
- 05
Test and diagnostics
Provide labeled test points and diagnostics for power, branch, conditioner, continuity, source state and selected output-authority conditions without requiring uncontrolled field rewiring.
- 06
Output-authority arbitration
Where an approved Field command exists, prevent two Field Cores from driving the same output without a defined owner, healthy-state check, feedback and conflict behavior. The existence of arbitration hardware does not itself authorize a command.
NX Nodes do not connect directly to passive IO harnesses
An NX deployment that requires physical points uses a bounded Field acquisition package or approved Ethernet remote I/O with a documented authority and failure model.
AUTONOMOUS GAS MONITORING AND SHUTDOWN INTERFACE
Local detection and protective action remain independent.
PrecisionDCMS GMS is a separate gas-monitoring and shutdown-interface enclosure. Gas sensing, alarm relays, local annunciation and the valve or shutdown circuit remain functional without any PrecisionDCMS node, facility network or Cloud service.
- 01
Hazard-specific sensing
Detector chemistry, range, location, quantity, environmental rating, calibration, voting and alarm levels are selected through the project hazard analysis, code requirements, OEM instructions and authority-having-jurisdiction process.
- 02
Local annunciation
Warning, alarm, trouble, impairment and shutdown state are annunciated locally as required by the engineered cause-and-effect and operating procedure.
- 03
Hardwired protective path
The approved gas controller and hardwired safety relay chain own the permissive, trip and final-element behavior. Protective action does not wait for a monitoring server, message broker, NOC operator or hosted workflow.
- 04
Independent power
Gas-safety power is derived from the approved protected source and backup architecture. Rack-server power supplies are not treated as gas-safety power.
- 05
Monitor-only integration
PrecisionDCMS receives isolated status, quality, trouble, alarm, shutdown, bypass or impairment indication as approved. It may correlate the condition with power, cooling, access and work records while preserving the GMS as the local authoritative protective system.
- 06
Reset and bypass boundary
The base design does not permit PrecisionDCMS to force a gas valve open, reset a gas trip, clear a detector alarm, activate a bypass or defeat a local shutdown. Any exception requires an order-specific hazard analysis, code and listing review, explicit authority, engineered interlocks, local validation and accepted procedure.
DIFFERENT PURPOSES, DIFFERENT FAILURE PHILOSOPHIES
Use the product boundary to prevent unsafe assumptions.
Scroll horizontally to see the full table.
| Attribute | PrecisionDCMS IO | PrecisionDCMS GMS |
|---|---|---|
| Primary purpose | Structured physical-signal termination, conditioning, fanout, test and output arbitration for Field Edition | Autonomous gas detection, local annunciation and shutdown-interface package |
| Primary authority | Field interface and, only where approved, bounded output-path arbitration | Local gas controller and hardwired safety chain |
| Relationship to PrecisionDCMS | Direct Field-family hardware element connected to Field Cores | Independent safety package that exposes approved monitor-only status |
| Required without monitoring platform | Passive field termination and designed signal behavior remain; monitoring depends on the selected Field architecture | Detection, alarm, local annunciation and protective action remain functional |
| Power basis | Field product power architecture as engineered | Independently approved protected gas-safety power |
| Typical signals | DI, DO, 4–20 mA, RTD, analog, pulse, serial-interface support and conditioned field states | Detector status, warning, alarm, trouble, shutdown, valve/final-element feedback and impairment |
| Command boundary | Any output requires explicit authority, arbitration, feedback and acceptance | No remote enable, reset, bypass or forced-open function in the baseline |
| Selection basis | Point count, signal type, redundancy class, isolation, testability, expansion and field-cable architecture | Hazard analysis, gas type, detection objective, cause-and-effect, code, listing, area classification and AHJ requirements |
| Typical deployment | Field Lite or Standard; Field + NX Local; Field + NX-Cloud | Any architecture where gas scope exists, as an independently powered local package |
ORDER-SPECIFIC ENGINEERING
Neither enclosure is selected by a generic point count alone.
IO selection inputs
- Signal inventory and source equipment
- DI, DO, analog, RTD, pulse and serial-interface requirements
- Source and sink voltage, current and burden
- Wetting voltage and sensor power
- Required isolation
- Signal-redundancy class
- A/B observation or command behavior
- Test and calibration approach
- Cable type, shield, grounding and surge environment
- Enclosure location and environmental rating
- Maintainability and future Standard conversion
- Spare capacity and expansion
- Interface to Field Core A and B
- Accepted failure state
- FAT and SAT method
GMS selection inputs
- Hazardous gas or vapor
- Expected concentration, release and dispersion
- Detector technology, range and response
- Detector locations and coverage objective
- Warning, alarm and shutdown thresholds
- Voting, latching and reset behavior
- Local horn, strobe and display requirements
- Valve, damper, ventilation, generator or process final elements
- Required permissive and feedback states
- Manual emergency controls
- Impairment and bypass management
- Protected power and backup duration
- Area classification and enclosure rating
- Applicable code, listing and AHJ requirements
- Calibration, bump-test and maintenance program
- Cause-and-effect and proof-test procedure
Approvals are order-specific
Exact controller, detector, enclosure, sensor, relay, valve and area approvals are order-specific. Do not make a blanket certification, listing or hazardous-location claim for the product family.
OBSERVE THE PROTECTIVE SYSTEM WITHOUT TAKING IT OVER
PrecisionDCMS adds context, workflow and evidence around the local source.
Approved IO and GMS states are normalized with stable equipment and point identities, source and receive time, quality, alarm class, maintenance state and lineage. PrecisionDCMS can correlate a condition with equipment dependencies, access events, power or cooling state, incident workflow, notification, field response, maintenance and evidence.
- 01
Source condition
The field source or gas controller detects the state.
- 02
Local behavior
The local system executes its engineered alarm or protective action.
- 03
Monitor-only acquisition
PrecisionDCMS receives approved isolated state and health.
- 04
Operational correlation
The condition is related to affected equipment, rooms, services and active work.
- 05
Incident and dispatch
The agreed NOC, SOC, service desk or site process coordinates response.
- 06
Evidence and restoration
Alarm, action, test, maintenance, approval and verified return-to-service records remain linked.
Acknowledgment is not reset
A PrecisionDCMS acknowledgment may acknowledge the monitoring event. It does not reset the source gas controller, clear a latched protective trip or return the final element to service.
DESIGN THE SAFE STATE FIRST
Every loss of power, signal, controller or communication must have a defined outcome.
IO failure considerations
- Loss of Field Core A or B
- Loss of one power source
- Open, short or out-of-range field signal
- Conditioner or isolator failure
- Harness disconnection
- Source disagreement
- Output-owner conflict
- Loss of feedback
- Maintenance bypass or simulation
- Network or monitoring-stack impairment
GMS failure considerations
- Detector fault or loss
- Gas-controller fault
- Loss of primary power
- Loss of backup power
- Open safety circuit
- Relay or final-element feedback disagreement
- Local annunciator fault
- Network or PrecisionDCMS loss
- Active bypass or impairment
- Calibration or proof-test overdue
Defined outcomes for IO and GMS impairment
For IO, the design must identify which source remains observable, whether the value becomes uncertain or bad, whether an output is inhibited, how conflict is alarmed and what manual or recovery procedure applies. For GMS, failure and trouble states are handled by the approved local controller, hardwired safety chain and operating procedure; loss of PrecisionDCMS or network connectivity must not prevent detection, local alarm or the engineered protective action.
The IO and GMS Overview covers
- Correct product definitions and boundaries
- IO internal functional architecture
- Field termination and quick-connect approach
- Signal conditioning, isolation and diagnostics
- Signal duplication and A/B fanout concepts
- Output-authority arbitration principles
- GMS functional architecture
- Local detector, alarm, relay and final-element chain
- Independent power and local autonomy
- Monitor-only PrecisionDCMS integration
- Reset, bypass and command prohibitions
- Selection and engineering inputs
- Failure and impairment behavior
- FAT, SAT, calibration and proof-test considerations
- Required project records and responsibility boundaries
Frequently asked
Questions and answers
- Is PrecisionDCMS IO a remote I/O controller?
- It is primarily a Field-family interface enclosure that provides termination, protection, conditioning, diagnostics, A/B harnessing and output arbitration. The selected Field Core and I/O modules perform the acquisition and any approved local logic. An order may incorporate approved remote-I/O elements, but the product boundary must remain explicit.
- Can an NX Node connect directly to IO harnesses?
- No. Passive IO harnesses are designed for Field Cores. An NX architecture that needs physical points uses a bounded Field acquisition package or approved Ethernet remote I/O with a documented data, power, authority and failure model.
- Does PrecisionDCMS GMS replace a listed gas controller?
- No. GMS preserves an approved local gas controller, detector circuits, hardwired safety relay chain, local annunciation and final element as engineered. PrecisionDCMS receives approved monitor-only status and operational context.
- Can the NOC reopen a gas valve after an alarm?
- Not in the baseline design. Remote force-open, reset, bypass or trip-clear functions are prohibited. Return to service follows the approved local cause-and-effect, inspection, authorization and reset procedure. Any exception requires a separate hazard, code, listing, authority and acceptance process.
- Can GMS be used with NX-Cloud Only?
- Yes, as an independently powered and engineered local package. It does not depend on NX-Cloud for protective action. Approved status can be collected through an isolated interface or site collector for monitoring and evidence.
Related resources
Field vs NX Selection Guide
Select the architecture from physical-interface, autonomy, availability, data-location, workload and operating-authority requirements.
Read resourcePrecisionDCMSPrecisionDCMS Technical Manual
Controlled product requirements for Field Edition, NX, NX-Cloud, IO, GMS, Site Connector, collectors, software, cybersecurity, commissioning, operations and lifecycle.
Read resourceArchitecture BriefsAuthority and Safety Boundary Brief
How read authority, command authority, local protection, workflow approval, API access and evidence are separated across the operating system.
Read resourceDEFINE THE FIELD AND SAFETY BOUNDARIES
Engineer the interface before selecting the enclosure.
Provide the signal inventory, redundancy requirement, local-autonomy need and any known gas-hazard scope. PrecisionX will identify the required Field, IO and independently protected GMS workstreams.