Specify a complete connected experience.
A room-availability service connects several sources: reservations, presence signals and room identities. To give an occupier a clear, dependable view, specify how those sources work together and the meaning of the status people see.
Map the journey from the person’s question to the information source and displayed result. Identify the application, interface, network and source system, with the team responsible for each element. Use that map to write the interface requirements.
For room availability, define what each state means. “Booked” describes a reservation. “Occupied” describes a measurement under the sensor’s rules. “Available” is a service decision which may depend on both. Agree whether the display informs people, releases reservations or controls something; each creates a different responsibility and consequence.
Specify the normal path and an exception before developing the screen. Agree the room identifier, update path, stale-data display and fault information available to the operator. These requirements make a simple user journey deliverable across supplier boundaries.
Separate identity, meaning and transport.
A name, a model and a message format solve different problems. The asset register identifies the thing. A semantic model describes what it is and how it relates to a room, system or point. A protocol carries messages; the payload defines the fields in those messages.
Decide whether an identifier names a physical device, a function or a location. A replacement device needs its own physical identity, while the room or measurement function may continue. Keep the visible asset label and any QR or barcode linked to the maintained register. A tenant's display name should be able to change without breaking the underlying mapping.
Brick can link a modelled point to an external BACnet object or time-series reference. Project Haystack defines entities, identifiers, tags and relationships. Digital Buildings provides an ontology with configuration and validation tools. Select and pilot the model against the client's required queries, receiving systems and ability to maintain it.
The MQTT specification leaves payload content open. Saying that two products support MQTT therefore leaves the data agreement unfinished. Specify the topic and access rules, field names, units, timestamps, schema version, stale-data treatment and delivery behaviour. For BACnet or another source protocol, record the exact object or address and the supported functions as well.
Take a representative example through the whole chain: a labelled device, its register entry, the points schedule, an actual payload and the value shown to an operator. Ask the receiving supplier to demonstrate how an unknown point, a changed unit and an outdated reading are treated. This exposes gaps before they are repeated across a building.
Compare options against the specification.
Use advertised integrations to explore potential routes, then confirm the model, version, licence and configuration required. Ask suppliers to identify demonstrated connections and the development or testing still needed to meet the specification.
Compare equivalent scopes covering source systems, gateways, networks, licences, mapping, configuration, testing, training and support. Allocate each responsibility to the supplier, client or other appointed party so the complete service is accounted for.
Protocol or platform support is worth checking at the relevant level. The BACnet Testing Laboratories: tested product listings identifies tested products and their supported BACnet functionality. That evidence can inform selection; the client’s complete service still needs a project-specific demonstration across the actual interfaces.
Ask for an example export and a change scenario. If the client changes platform, can it retain its asset register, configuration, history and agreed data meanings? If a sensor is replaced or a floor changes tenant, who updates the mapping and what is retested?
Name the owner at each boundary.
Give each interface a clear delivery and operating owner. Record who provides the source, maps the information, configures the receiving service, approves network access and resolves faults.
Confirm each dependency with the party responsible for it. Put permission, privacy and security decisions into the integration plan, with the authorised client or specialist approver and the date needed.
Use a responsibility record with a named party for provision, approval, configuration, demonstration and operational support. Include landlord–occupier boundaries and the point at which a supplier hands over to an integrator. An escalation route should work even when both parties believe the other system is at fault.
The NCSC: Creating and maintaining a definitive view of your OT architecture addresses records of assets, connectivity and third-party dependencies in operational technology. For an advisory appointment, the practical question is whether authorised IT/OT teams have enough information to assess the proposed connection and maintain it. The consultant’s integration brief does not replace their security design or approval.
Check delivery against the agreed requirements.
Run the demonstration or pilot against the agreed scenario. Record the connected systems, information used, expected behaviour and the operator’s view when a source becomes unavailable. State the scope of the result so the next decision rests on clear evidence.
Carry the integration plan from specification through procurement, implementation and acceptance. Track the intended service, dependencies and evidence at each review point, including practical completion where applicable.
Make a demonstration script from the brief: initial state, trigger, expected behaviour, evidence to capture and who will witness it. Include loss of a source, delayed updates, an expired permission where appropriate and recovery. Agree how test data will be distinguished from actual operating information.
A pilot should resolve a specific uncertainty. A room trial may test coverage and the application flow. It does not automatically prove performance on every floor, a different network or another tenant’s system. Record the conditions under which the result can be used for the next decision.
An interface record the team can use.
An interface record for room availability can cover the following:
- Purpose: show an agreed room status to occupants and the workplace team.
- Sources: reservation system, presence source and the maintained room register.
- Meaning: state definitions, update rules and the display when a source is unavailable.
- Ownership: source administrator, connector supplier, application owner and client approver.
- Proof: agreed occupied, reserved, unoccupied and unavailable scenarios using the relevant versions.
- Operation: monitoring, support route, change control and access renewal.
Make the record concise enough for coordination and specific enough to assign an action. Link it to the requirement, supplier proposal and test evidence so the team can assess changes against the original outcome.
Questions to ask before committing.
- Which exact capability has been demonstrated?
- What data definitions and update requirements apply?
- Which licences, permissions and prerequisites are included?
- Who owns each interface during delivery and operation?
- What happens when a source or connection is unavailable?
- How can configuration and useful information be retained if the service changes?
Sources and further reading.
- BACnet Testing Laboratories: tested product listings — Check the exact product and supported BACnet functionality, then test the proposed service.
- NCSC: A definitive view of OT architecture — A reference for maintaining assets, connections and third-party dependencies with IT/OT teams.
- Brick: External representations — Links modelled points to BACnet objects and time-series references.
- Project Haystack: Ontology — Explains entity identity, display names, tags and relationships.
- Google: Digital Buildings ontology — Describes the model, building configurations and validation workflow.
- OASIS: MQTT 5.0 specification — Defines transport behaviour while leaving the application payload to be agreed.
Further reading
Choosing the model, naming and information contract