Separate protection objectives before connecting interfaces
Fire warning protects life and facilities, cooling control protects thermal and hydraulic stability, and IT operations protects digital services and data availability. Boundaries should follow design authority, control rights, failure modes and acceptance evidence, not vendor brand or equipment location. A common BMS, DCIM or dashboard does not merge engineering accountability.
- Name design, supply, installation, configuration, testing, approval and operational ownership for every work package.
- For each cross-system interface, record provider, receiver, meaning, trigger, failure mode and acceptance method.
- Keep statutory fire functions, mechanical control and IT operational authority subject to their respective design and applicable requirements.
The fire boundary ends at approved alarm and control interfaces
Fire engineering owns risk zoning, detection design, alarm levels, fault monitoring, statutory interfaces, control logic and fire acceptance. Aspirating smoke detection can report alarms and faults to the fire alarm system and provide status to BMS or DCIM for operational visibility. BMS or DCIM should not assume statutory alarm or release logic without fire-engineering and authority approval. IT owns the business response to a received event, not the fire determination.
- Typical deliverables include detection and sampling design, alarm matrix, point list, test records and maintenance baseline.
- Alarm investigation, load isolation, personnel escalation and suppression control require separate ownership and triggers.
Hydraulic duty and control sequence define the cooling boundary
Mechanical design owns medium, flow, pressure, temperature, valve duty and hydraulic performance; controls design owns commands, feedback, alarms, interlocks and sequence; electrical design owns power and protection. Modbus, analog control or position feedback on a valve or actuator does not complete the BMS point list, network, permissions, sequence or fault handling. IT operations may consume cooling status but should not rewrite safety-related settings without approval.
- Typical deliverables include the design-condition schedule, valve-actuator combination, sequence, point list and functional tests.
- Control ownership across pumps, chillers, CDUs, valves, sensors and BMS should be explicit.
Responsibility, interface and acceptance matrix
Use this matrix to start scope definition, then expand every row into named owners, interface IDs and approved deliverables.
| Domain | Primary ownership | Typical output interfaces | Should not be assumed | Core acceptance evidence |
|---|---|---|---|---|
| Fire warning | Risk zoning, detection, alarms, faults, fire controls and specialist acceptance | Warning levels, fire alarm, fault, isolation and maintenance status | IT recovery, hydraulic control or unapproved suppression-release logic | Approved design, alarm matrix, points, transport and alarm tests, control records |
| Cooling control | Hydraulic duty, valves and actuators, sensors, control sequence and thermal response | Temperature, pressure, flow, position, command, equipment state and fault | Statutory fire decisions, IT application recovery or unapproved business-priority decisions | Duty and selection records, points, sequence, stroke tests, trends and functional tests |
| IT operations | IT assets, platforms, networks, incidents, change, backup, recovery and business escalation | Tickets, asset state, capacity, performance, service event and recovery status | Redefining fire signals, changing mechanical design values or bypassing professional safeguards | Asset and configuration baselines, monitoring tests, escalation exercises and recovery evidence |
| Shared interface governance | Common ownership, semantics, time, version, permissions, faults and scenario testing | Cross-system events, states, commands, acknowledgement, escalation and recovery records | Replacing discipline design authority or assigning ownership to generic vendor coordination | RACI, interface register, data dictionary, end-to-end scripts, defect closure and handover |
One organization may hold several roles, but design, approval, test and operational accountability should still be named separately.
Four steps from system objectives to accepted boundaries
Define what each discipline protects before deciding how signals cross boundaries, reducing scope gaps discovered after procurement.
- 01
Define objectives and scenarios
List normal, abnormal, fault and recovery scenarios for fire safety, thermal conditions, facility availability and digital continuity.
Output: objective tree, scenario list and requirements register - 02
Allocate systems and ownership
Assign named roles for design, supply, installation, configuration, test, approval, operation and maintenance.
Output: boundary diagram, scope matrix and RACI - 03
Freeze interfaces and failure modes
Record signals, meaning, units, time, protocol, authority, triggers, loss of communication and degraded behavior.
Output: interface register, point list, data dictionary and fault matrix - 04
Test in layers and hand over
Complete component, point-to-point, subsystem and end-to-end scenario tests, then transfer response and change controls to operations.
Output: test evidence, defect closure, procedures and baselines
EVIDENCE
Securiton data center product-application cases
Supplied Securiton material contains nine data center and critical-facility ASD records. The case page shows customer, location, year, model and quantity where listed; cross-discipline interfaces absent from the files are not added.
- Records
- 9
- Product scope
- ASD 532 / ASD 535 family
- Year range
- 2009–2021
Published fields include project name, location, year, model, quantity and selected sampling scope where listed.
The material does not fully state protected-zone schedules, sampling design, thresholds, fire controls, cooling or IT interfaces, acceptance records or operating metrics.
Verifiable content is limited to listed project and product-application fields. Cross-discipline boundary design and continuity metrics require separate project evidence.
Sources: S10
Frequently asked questions
Does BMS or DCIM become responsible for fire control after receiving a fire event?
No. BMS or DCIM can receive status for visibility and escalation, while statutory alarm and control authority remains subject to approved fire design and applicable requirements. Any command authority must be explicit in the interface and approval records.
Can IT operations change cooling-valve settings directly?
Only when the permitted range, authority, control sequence, change process and rollback conditions have been approved. The ability of an IT platform to send a command does not confer mechanical design authority.
Is a boundary matrix needed when one main contractor owns every system?
Yes. One contract can still contain different designers, suppliers, commissioning parties and operators. The matrix prevents internal gaps and creates traceability from ownership to test and handover.
How can completion of cross-discipline interfaces be verified?
Do more than check an online connection. Test meaning, time, authority, triggers, abnormal values, communication loss, degraded operation, recovery and operator response, and retain end-to-end evidence and defect closure.
Manufacturer, standards and public technical sources
Standards and public guidance frame lifecycle, continuity, commissioning and interfaces. Manufacturer and supplied material support only the product, service or project facts they explicitly list.
- S1 · ISOISO/IEC 22237-1:2021 Data centre facilities and infrastructures
General framework for data center facility lifecycle, availability and cross-discipline management.
- S2 · ISOISO 22301:2019 Security and resilience — Business continuity management systems
General framework for business impact, response, recovery and continual improvement.
- S3 · NISTSP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems
Supports lifecycle interface, integration, risk treatment and traceable verification activities.
- S4 · SecuritonSecuriSmoke ASD 531 / 532 / 535 official product page
Supports the aspirating smoke-detection product range and official product entry.
- S5 · SecuritonData center application information
Supports the data-center early-detection context; project design remains site-specific.
- S6 · GRUNEROfficial electric actuator product entry
Supports GRUNER actuator capabilities and official product information.
- S7 · GRUNEROfficial product download center
Entry for current manufacturer valve and actuator files.
- S8 · ASHRAECommissioning standards and guidance
Process references for commissioning, functional verification, existing-system assessment and handover.
- S9 · Beijing Yabowei Technology Co., Ltd.Supplied business, credential and public solution material
Supports only the IT services and credentials listed in the material, not an integrated cross-discipline delivery.
- S10 · SecuritonSupplied Securiton data center project-reference records
Supports the nine visible project records; only fields explicitly listed in the supplied material are used.
This page provides a project-boundary and interface-governance framework. It is not fire engineering, hydraulic design, a control program, cybersecurity design or an IT service contract. Final ownership, authority, editions, interfaces and acceptance must reflect the owner, design team, authority having jurisdiction and approved project documents.