Recommended architecture: keep each viable legacy system as the system of control, then add a governed integration layer that reads, normalises and relates the data needed for cross-system operations. Do not begin by replacing every controller or by building a new dashboard that operators must manage in parallel.
Design recommendation: give the integration layer a clear job—connect authorised points, preserve point identity and engineering context, standardise timestamps and units, expose role-appropriate views, and send approved events into the existing work process. Disable write-back by default and enable it only for a documented use case with change control, testing and rollback.
This pattern is consistent with BACnet's role as a data-communication mechanism for building automation and control systems, with open-API patterns that bring data from different systems into a common pool, and with BCA's framing of Smart FM as an integration of systems, processes, technologies and people. It is an architecture choice, not a promise that every legacy device will be interoperable.
When this approach fits
Use a layered integration approach when the building has serviceable plant and controls but fragmented visibility across BMS, IoT meters, access control, vertical transport, lighting, power monitoring or other equipment systems. Use it for a portfolio only when the proposed common operating view preserves site-specific control sequences.
Select this method when the buyer needs to:
investigate an operational event across more than one system;
relate alarms and readings to an asset register or spatial model;
reduce duplicate manual data collection without changing plant control on day one;
preserve investments in controllers, meters and specialist systems; or
establish an information foundation for later Smart FM use cases.
BCA Academy material describes BIM, IoT, cloud, big data and AI as technologies that can support Smart FM and digital-twin use cases. For this decision framework, do not require all of them at once; select the stack against the operating question, available data and the site's risk tolerance.
When it does not fit
Site-screening rule: do not make integration the first priority when critical controllers are unsafe, unsupported or unable to provide trustworthy data. Replace or remediate the underlying control problem first. Before integration, ask whether asset ownership, maintenance practice, cyber responsibilities and managed site connectivity have named owners; close material gaps before expanding scope.
Pause the programme if the only proposed value is “one more dashboard.” For procurement review, classify a new interface without process ownership, alarm routing or closure evidence as a second-silo risk even if its data connections work. Likewise, avoid a broad write-back scope before the site has verified points, permissions, interlocks and rollback procedures.
Inventory the legacy estate before choosing connectors
Start with a joint walk-through involving facilities operations, controls specialists, IT or OT security, maintainers and relevant vendors. Build an integration inventory that records:
system name, service and accountable owner;
controller, gateway and front-end versions;
physical and network boundaries;
protocol or interface, licence dependency and vendor support status;
point count by type, including commands, setpoints, alarms and calculated values;
units, ranges, timestamps, quality flags and naming conventions;
control authority, interlocks and operational consequence of a bad command;
asset, floor, zone and meter relationships;
data retention, export and outage behaviour; and
known gaps, manual workarounds and operator pain points.
Treat point names as evidence to be verified, not as a ready-made data model. During mapping, test whether matching labels carry different meanings and whether different labels refer to the same asset. Existing BMS interoperability is a recognised challenge, and published research has explored architectures that combine BIM, BMS and real-time IoT sensor data. The recommendation is therefore to test meaning as well as connectivity.
Design the protocol and data layers separately
Use two separate acceptance questions: the protocol layer asks, “Can we connect safely?” and the data layer asks, “Can an operator understand and use what arrives?” Do not approve operational completeness on the strength of a protocol test alone.
At the protocol layer, document whether each connection is read-only or read/write, how it authenticates, how it behaves during an outage and who can approve a change. BACnet may provide a communication mechanism in building automation environments. For every other connection, require the vendor to identify the supported API, export, gateway or site-specific adaptor. Do not approve a connector that bypasses safety logic or vendor support constraints.
At the data layer, create a canonical identity for every integrated asset and point. Preserve the native identifier, then add normalised attributes such as asset class, location, engineering unit, source system, sampling behaviour and data-quality status. Relate alarms, readings, work orders and model objects without overwriting the source record.
Open APIs can support application integration through a common data pool. Webuild's public IoT platform page describes equipment-data collection, connectivity and unified management, while its public digital-twin page describes combining a three-dimensional model with equipment status, alarms and operations monitoring. These are product capability statements only. Site compatibility, interfaces, cybersecurity and required configuration must be verified during technical discovery.
Implement in controlled stages
Establish the boundary
Agree the operating question, the systems in scope, the control boundary and the acceptance criteria. Select a first scope narrow enough for the site team to observe and important enough to test an actual workflow.
Connect and validate
Begin read-only. Validate representative points against the native interface and field conditions. Check units, sign conventions, timestamps, quality flags, asset relationships, alarm states and outage recovery. Record exceptions rather than hiding them in transformation logic.
Integrate the workflow
Route selected events to a named owner and an existing response process. Capture acknowledgement, investigation, action and closure evidence. Train operators using real scenarios, and keep the native system available for diagnosis and fallback.
Expand by proven pattern
Add systems, sites or use cases only after the first pattern has clear ownership and stable data. Introduce write-back separately, with a risk assessment, approved command list, interlock review, staged testing and rollback. The T/CREA 002-2023 smart-building standard notes that alteration and extension projects should consider compatibility and integration with existing facilities; this article applies that as a general retrofit principle, not as a claim of project compliance.
Compare the main options
Read every cell as a site question, design target or evidence request; do not treat the table as measured product performance.
| Option to evaluate | Site condition to verify | Design target | Risk or limitation to test | Procurement evidence required |
|---|
| Retain separate native systems | Has the team decided that no cross-system workflow is justified for this scope? | Keep current control interfaces unchanged for the approved scope | How will operators investigate and report across separate systems when needed? | Name the owner and support boundary for every retained system |
| Add a read-only integration layer | Does the site need shared visibility while command authority remains out of scope? | Correlate selected data without granting command authority | Which actions would still require the native systems and procedures? | Provide a validated point list, identity mapping, access design and data-quality acceptance record |
| Add governed write-back | Has the specific command workflow passed site risk review and controlled testing? | Route only approved commands into the defined workflow | Which safety, cyber, change and failure conditions must the site test and accept? | Provide the approved command list, interlock review, test evidence, rollback plan and named approvers |
| Replace selected legacy components | Has the site verified that a source component fails its support, safety or reliable-data acceptance criteria? | Replace only the component that fails the documented acceptance test | What disruption, migration, re-commissioning and fallback work would the change introduce? | Provide cutover, fallback, re-commissioning and acceptance evidence |
Allow a proposal to combine these options. Reject “integrate everything” and “replace everything” as untested defaults; decide system by system and workflow by workflow.
FAQ
Must we replace the BMS first?
This framework does not require blanket replacement. Retain a BMS only after the site verifies that it is safe, supportable and able to expose the required data through an approved interface. Replace or remediate components that do not meet the site's operational, safety, support or information requirements; integrate the rest in stages.
Will a common data layer take control away from operators?
Design it not to. Start with read-only access, keep the native controls available and define control authority explicitly. Limit any later write-back to approved commands with tested safeguards and rollback.
How do we avoid losing existing control points?
Preserve the native point identifier and control semantics, reconcile the integrated value against the source system, and maintain a point register showing what is connected, transformed, excluded or write-enabled. Never treat a renamed display label as proof that the underlying control meaning is intact.
Can one platform connect every vendor and protocol?
Do not assume so. Verify compatibility for the specific system version, interface, licence, network and vendor-support arrangement, then document exceptions before contracting the full estate.
Is a digital twin required?
No. Use a spatial or asset model when it helps operators understand relationships and act. Webuild publicly describes a digital-twin capability that combines models, equipment status, alarms and monitoring, but the buyer should select it only where the operating use case warrants the additional model governance.
Related Reading
- Share
-
12
- 正在更新中...
- What Operational Data and Audit Trail Should an Existing Building Retain for Green Mark?
