Guides
Building Monitoring Requirements: Connect Signals to Operator Decisions
Prepare a building-monitoring brief that defines each signal, its meaning, information age, operator response and acceptance evidence before requesting a system proposal.
DETIAN ICT · Tanzania & East Africa
Discuss your ICT project with DETIAN.
DETIAN ICT supports audiovisual, security, network and smart-building projects in Tanzania and East Africa, with design, equipment supply, installation and maintenance services.
Share your site location, required systems and available drawings or equipment list. Start a discussion about the work scope and the information still needed.
Start with the decision the information will support
Before requesting a building-monitoring dashboard, identify the operational decision behind each proposed signal. State what the information means, where it comes from, who will use it and what that person should do when it needs attention. A screen full of readings is useful only when the team can interpret them within the agreed scope.
For a business facility in Tanzania or elsewhere in East Africa, the first deliverable can be a small signal-to-decision brief. DETIAN's public smart-building planning guidance starts with the facilities to be monitored, the operations team's tasks, existing controllers and available interfaces. The worksheet below develops that planning question without selecting equipment or assuming that an existing system can supply the requested information.
Describe the signal before specifying the screen
Give each proposed item a reference tied to a building, area and equipment label. Describe the meaning in ordinary language: for example, a controller's reported lighting state for a named area. Distinguish a reported state from a measured physical condition, a scheduled setting and an instruction sent to equipment. They answer different questions even when a display uses similar words.
For a numeric reading, identify the quantity and unit. For a state, ask the system owner to define the possible labels and their meaning. Record the source of that definition and which details remain unconfirmed. A supplier should not have to guess whether a value represents a current observation, a requested setting or an older record.
List the known controller or source system, its custodian and any interface documentation already available. Ask the responsible technical team to confirm whether the required information can be obtained and under what conditions. A visible value on an existing local screen does not establish that another system can retrieve it. Keep proposed new sensors separate from information the existing installation may already provide.
Copy three short records for each proposed monitoring item
Signal record — Item ID: ___; building/area/equipment: ___; information required: ___; meaning and unit or state labels: ___; source and document reference: ___; interface availability: confirmed / awaiting assessment; remaining question and owner: ___.
Decision record — Item ID: ___; operational question: ___; viewing role and operating period: ___; condition requiring attention: ___; next action under the site's approved procedure: ___; responsible recipient: ___; action outside this role's authority: ___.
Evidence record — Item ID: ___; agreed input or demonstration condition: ___; expected display, including information age or availability: ___; observer and method: ___; actual result: ___; evidence reference: ___; exception, owner and next step: ___.
Use the same item ID across the three records. Begin with a few items that support actual decisions instead of listing every value that might be available. Keep technical thresholds, sampling intervals and any rule for treating information as old marked for agreement by the responsible project team. This worksheet supplies no universal values for them.
Make information age and missing reports visible
Ask how a viewer will distinguish a current report, an older report and an unavailable source. Record what the displayed time represents: the source's observation time, receipt by an intermediate system, or another defined event. Name the time zone and identify any unconfirmed clock relationship. A recent page refresh alone should not be presented as a new equipment observation.
Decide what the operator needs to see when no usable current information is available. Keep “not available” separate from an ordinary equipment state such as “off”. Ask the supplier to explain the proposed display and the evidence needed to demonstrate it. Do not assume that an empty field or unchanged value will be understood consistently by different operators.
If historical views are requested, describe the decision they support and the period the owner needs to examine. Ask separately about the available records, gaps and proposed retention arrangement. A live display does not establish that a usable history exists. Avoid putting personal or sensitive operational data into an initial public enquiry.
Work through a fictional lighting-status example
Imagine a fictional office considering a display for lighting group DEMO-L1. The facilities team wants to know the controller's reported state before deciding whether an authorised local check is needed. The source interface has not yet been assessed. This is an invented planning exercise, not a DETIAN installation or a measured result.
The signal record says “reported on/off state for DEMO-L1”, with the controller documentation still to be supplied. It does not ask the display to certify room brightness, occupancy or energy use. The decision record identifies the facilities duty role and refers any unusual report to the site's existing inspection procedure; it gives the viewer no new authority to switch equipment.
Prepare three proposed evidence rows. L1-A asks whether an agreed valid sample is shown against the correct item and meaning. L1-B asks how a sample older than the project's agreed age condition is labelled. L1-C asks how unavailable information is distinguished from a reported “off” state. The owner and supplier must agree the test inputs and expected presentation before these become acceptance checks.
Suppose an authorised demonstration covers L1-A and L1-C, but L1-B has not been exercised. Record those individual outcomes and leave L1-B open. If the exercise used sample data, describe it as a display demonstration with sample data. It does not prove a live controller connection, measurement accuracy or operation under every site condition.
Separate viewing, notification and control in the proposal
A proposal should identify which items are included for viewing, which may generate a notification and whether any control action is being requested. Treat these as separate functions with their own responsibilities and evidence. Do not allow a monitoring brief to silently become permission for remote equipment commands.
For a requested notification, identify the event meaning, intended recipient, operating hours and the action expected under the approved site procedure. Ask who maintains the recipient arrangement and how an unresolved notification is handled. Seeing a notification on a screen, delivering a message and having a person act on it are separate outcomes to review.
Where control is proposed, refer the operating authority, equipment behaviour and safety requirements to the responsible specialists and the site's approval process. This guide gives no control settings or installation instructions. Building protection and life-safety functions need their own applicable design and approval; the fictional display exercise is not evidence for those functions.
Ask suppliers to answer the unresolved items
Give each supplier the same brief revision and ask for a response by item ID. Request the proposed source, interface assumptions, supplied equipment or software, customer dependencies, display behaviour, acceptance method and exclusions. If an interface or data meaning is unverified, keep that dependency visible beside the price and scope instead of treating it as included integration.
Ask who maintains the signal definitions and display labels when equipment, room names or operating procedures change. Identify which records the owner will receive and who may administer them. The project handover index can organise those final records, while the monitoring brief defines what information and decisions the proposed system must support.
Agree any later demonstration with the authorised owner and technical team. Use approved test material or a suitable agreed environment; do not disconnect live equipment, change alarm thresholds or issue operating commands just to populate a test row. Retain the actual conditions and exceptions so the acceptance decision is tied to what was demonstrated.
Bring DETIAN a bounded monitoring enquiry
Prepare the project country and town, facility type, relevant system list, available controller or interface documentation and a few completed signal-to-decision records. Include the intended schedule, the roles able to clarify requirements and the points requiring a site assessment. Use the official contact route to agree how necessary technical material should be shared.
Ask DETIAN to discuss the proposed design, supply, installation and support scope for these requirements. A useful initial outcome is agreement on which monitoring items can be assessed, which source information is missing and what evidence the proposal should include. Compatibility, equipment availability, site attendance, costs and delivery arrangements remain matters for the actual project discussion.
