Points are the individual inputs and outputs a building automation system reads and commands: a temperature, a fan status, a valve position. The sequence of operation is the written description of how the system uses those points to run the equipment. Together they define what the BAS actually does, and when either is missing or vague, the system ends up programmed by guesswork.
What a point is
Every connection between a controller and the real world is a point. There are four basic hardware types:
- Analog input (AI): a measured value that varies continuously, such as a temperature, pressure, humidity or flow, usually from a sensor sending a 4–20 mA, 0–10 V or resistance signal.
- Analog output (AO): a variable command, such as a valve or damper position or a fan speed sent to a drive.
- Binary input (BI): an on/off status, such as a fan proven by a current switch, a filter alarm or a door contact. Also called a digital input.
- Binary output (BO): an on/off command, such as starting a fan or a pump. Also called a digital output.
Beyond these, controllers hold software points: setpoints, schedules, calculated values such as a mixed air temperature reset, and modes. Integrated equipment such as drives, meters and packaged units adds network points read over BACnet or Modbus rather than wired individually. The diagram shows the hardware points on a typical air handler.
The points list
The points list is a table of every point the system will have, organized by piece of equipment. It is the backbone of the controls specification: contractors price from it, programmers build from it and commissioning agents test against it. A useful points list shows, for each point:
| Column | What it records |
|---|---|
| Equipment and point name | Following an agreed naming convention, for example AHU-1 supply air temperature |
| Type | AI, AO, BI, BO, or software and network points |
| Units and range | °C, Pa, %, L/s; the sensor or signal range |
| Alarms | High and low limits, delays and who is notified |
| Trending | Whether the point is logged, and how often |
| Graphic | Whether it appears on the operator graphic |
Agree the naming convention before programming starts. Consistent names make graphics, alarms, trends and future analytics far easier, and they make it possible to move to a different service provider later. Our guide to BACnet and Modbus covers how points appear on the network.
Sequences of operation
A sequence of operation describes, in plain language, how the controls run a system in every mode: occupied and unoccupied, warm-up and cool-down, normal operation, safety trips and recovery after a power failure. A good sequence is specific enough that two programmers working separately would produce systems that behave the same way. It names the points it uses, gives setpoints and limits (or says where they are adjustable), describes how control loops are tuned to behave, and says what happens when something fails.
Many control actions are closed loops. The controller compares a measured value with its setpoint and adjusts an output to close the gap, then measures again. A supply air temperature loop, for example, opens the cooling valve further when the air leaving the coil is warmer than the setpoint.
Sequences also contain logic: conditions that must be met before something happens, and what to do if they are not. The diagram below follows part of a typical air handler start-up in occupied mode.
Writing sequences from scratch for every project invites inconsistency. ASHRAE Guideline 36 publishes detailed, tested sequences for common air handler and terminal unit arrangements, and many designers now base their sequences on it, adapting it to the equipment actually installed. Check the current edition, and confirm that your controls contractor's platform can implement the sequences as written.
An example sequence
Here is how a short, well-written sequence for a variable air volume (VAV) box with hot water reheat might read. The setpoints are left adjustable, and the points it uses all appear in the points list.
VAV box with reheat, typical sequence. In occupied mode, the controller maintains zone temperature at the occupied cooling setpoint by modulating the airflow setpoint between the minimum and maximum airflow, each adjustable. When the zone temperature falls below the occupied heating setpoint, airflow is held at the heating airflow setpoint and the reheat valve modulates to maintain the heating setpoint, with discharge air temperature limited to an adjustable maximum. Between the two setpoints, airflow is held at minimum and the reheat valve is closed. In unoccupied mode the damper closes, and if the zone drifts outside the unoccupied setpoints the box requests the air handler to run. If zone temperature stays outside its setpoint by more than an adjustable amount for longer than an adjustable delay, an alarm is sent to the operator. On loss of communication with the supervisory controller, the box continues in occupied mode at its last setpoints.
Notice what the example does: it covers every mode, names the setpoints and says they are adjustable, describes what happens between modes, sets an alarm with a delay so it does not chatter, and says what the box does when something fails. A sequence missing any of these leaves the programmer to decide, and different programmers decide differently.
When reviewing a sequence, a useful test is to pick a point from the points list and look for it in the sequence, then pick a sentence in the sequence and look for the points it needs. Any gap in either direction is a problem to fix before programming starts.
Testing points and sequences
Points and sequences are only as good as the proof that they work. Testing normally happens in stages:
- Point-to-point checkout. Every input is checked against a reference reading and every output is commanded and observed at the device, so a valve command of 50 percent produces a half-open valve, the right one. Record each result on the points list.
- Functional performance testing. Each mode of each sequence is exercised, including failures: the fan is stopped to see the alarm and the safe response, the outdoor temperature is overridden to test economizer changeover.
- Trend review. After the building is occupied, trends of key points over days or weeks show how loops behave in real conditions: hunting valves, simultaneous heating and cooling, schedules that do not match occupancy.
This testing is a core part of commissioning a new building.
Common problems
- Sequences that say "per manufacturer" or "as required" instead of describing the control.
- Points lists that do not match the sequences, so points needed for a sequence were never installed.
- Operator overrides left in place for months, quietly disabling the sequence.
- Sensors in poor locations, such as a mixed air sensor in a stratified airstream.
- Alarms with no limits, delays or owners, so operators learn to ignore them.
- Sequences changed during commissioning without updating the documentation.
How ehZee can help
We write points lists and sequences of operation as part of BAS design, coordinate them with the mechanical design, and review testing so the system is shown to do what the sequences say. See our building automation system design service.
Common questions
Who should write the sequence of operation?
The design team, usually the mechanical engineer with the controls designer. Leaving it to the controls contractor means each bidder interprets the design differently and the owner cannot check the result.
Our building has no written sequences. Can they be recovered?
Yes. The existing programs can be reviewed and the actual behaviour observed with trends, then written up as the sequence that is actually running. That is often the first step in tuning or upgrading an older system.
How many points should be trended?
At least every temperature, setpoint, valve and damper command, and fan and pump status on major equipment. Storage is cheap compared with the cost of troubleshooting without history.