> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/academy/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-benchmarking-and-targets.md). # Introduction to Benchmarking and Targets Learn how historical baselines become meaningful targets and how to interpret changes in building performance. A building uses less energy this month than last month. Has its efficiency improved? Not necessarily. The weather may be milder, fewer people may be using the building, or operating hours may have changed. The reverse is also possible: consumption can rise even after a successful efficiency measure because the building is busier or the weather is colder. To judge performance, you need more than a previous total. You need a reference that helps explain what consumption would be expected under the conditions being compared. **Benchmark and Targets** in ABB Ability BuildingPro Suites builds that reference from historical asset data. You can use it to investigate changes in operation, monitor departures from a recent operating pattern, or track an energy-reduction goal. This Academy chapter explains how to choose and interpret that comparison. By the end, you should be able to: * Distinguish a B\&T config, a baseline, actual values, and target values. * Choose a fixed reference, a moving reference, or automatic baseline detection. * Turn expected operation into a fixed or gradual reduction target. * Read absolute, percentage, and cumulative differences without confusing them. * Recognize when the data or comparison needs further investigation. For the configuration procedures, use the [-> Benchmark and Targets product guide](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets.md). ## Start with the right question Benchmarking means evaluating performance against a reference. That reference might be another building, a standard, or the same building during an earlier operating period. The implementation covered here starts with an asset and its measured attribute. It models historical operation and compares actual values with the target derived from that model. The central question is: **How does this asset perform compared with the operation represented by the selected baseline?** That is different from ranking buildings by annual consumption per square metre. A modelled comparison does not automatically make unrelated buildings comparable or establish why one building performs differently from another. It is also different from forecasting. A forecast asks what a future value is likely to be. A historical benchmark asks what value the reference model would expect for the conditions being evaluated, and how the measurement compares with it. For future-value prediction, see [-> Predictive Forecasting](/collection/platform/platform-core/baseline-and-factors/forecast-engine.md). ## Four concepts that belong together ### B\&T config: what you measure A **Benchmark and Targets (B\&T) configuration**, shortened to **B\&T config**, selects the asset and source attribute you want to evaluate. For example, it might select the electrical energy attribute of a building's main meter. You can add **feature attributes** as contextual inputs. Outdoor temperature can help represent weather-related demand; occupancy can help represent changes in building use. These inputs help the model distinguish expected variation from an unexplained difference. They do not guarantee a better comparison. An irrelevant input or incomplete feature history can make the result harder to trust. Choose inputs that have a plausible relationship with the measured value and usable history over the relevant periods. ### Baseline: which operation is the reference A **baseline** defines the historical reference period and the settings used to calculate the comparison. A B\&T config can contain several baselines, allowing you to examine the same measurement against different references. The reference period matters because it defines what the model learns as expected operation. A baseline taken during an inefficient operating period does not become an efficiency standard simply because a model fits it well. ### Actual values: what happened **Actual values** are the measured values of the source attribute. They describe what the asset recorded, not what you hoped it would achieve. Check what that attribute represents before interpreting it. Energy consumption over an interval, instantaneous power, and a cumulative meter register are not interchangeable. The source unit and calculation timeframe determine the meaning of the comparison. ### Target values: what you compare against **Target values** are calculated from the baseline's model, including any configured percentage reduction. Without a reduction, the target represents modelled reference operation. With a reduction, it becomes a lower allowance against which you can track an improvement goal. A target is therefore a time series, not necessarily one constant number. Expected demand can vary with the modelled calendar patterns and selected feature inputs. {% hint style="info" %} The current interface calls a B\&T config a **target**, using labels such as **Add Target** and **Configure target**. Its **Target attribute** field selects the measured source attribute, not a generated target-value attribute. This chapter uses **B\&T config** to distinguish the configuration from its calculated target values. {% endhint %} ## Choose the baseline to match the decision The best reference is not necessarily the most recent period or the period with the lowest consumption. It is the period that makes the question you want to answer meaningful. ### Fixed reference: has performance changed since then? Choose **Manually**, then **Set Date**, when you know which historical operation should remain the reference. For an energy-efficiency project, a representative period before the intervention lets you compare later operation with the earlier operating pattern. The reference dates stay unchanged even as new measurements arrive. A fixed reference does not mean a flat target line. The model can still produce different expected values for different conditions. What remains fixed is the chosen historical period. Include the operating conditions that matter to the comparison. A quiet summer week is a weak reference for a building's full heating season. Avoid periods dominated by missing data, commissioning, or unexplained operating changes. ### Moving reference: is recent operation changing? Choose **Manually**, then **Moving baseline**, when the comparison should follow a rolling period of history. **Baseline length** determines how much history is included. **Offset days** leaves a gap between today and the end of that history. For example, a length of 365 days and an offset of 30 days uses a 365-day reference ending 30 days before today. This is useful for monitoring deviations from recent operation. A longer reference can include more seasonal variation; a shorter one responds more closely to recent conditions. The tradeoff is adaptation. A fault or persistent increase in consumption can eventually enter the rolling reference and become part of what the model treats as normal. A moving reference is therefore not an unchanged yardstick for long-term savings. Keep a fixed baseline as well when that distinction matters. ### Automatic detection: when did historical operation change? Choose **Auto** when you do not know where to place the reference boundaries. Automatic detection examines historical departures from the modelled operating pattern and identifies candidate operating periods. Its smoothing window, minimum duration, and drift threshold influence which changes stand out. Compare the detected periods with known events: a plant replacement, a new occupancy pattern, or a revised operating schedule. A detected boundary suggests something changed; it does not explain the cause or prove that the period is a suitable reference. This is retrospective analysis, not a continuously running anomaly alarm. For the settings and the consequences of rerunning detection, see [-> Create a Baseline](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/create-a-baseline.md). ## Turn expected operation into an improvement target A baseline answers, "What operation are we using as the reference?" A percentage **Offset** answers, "How far below that modelled operation do we want the allowance to be?" These are separate decisions. Moving the reference dates to include an improvement changes the comparison; it is not the same as setting an improvement goal against the original reference. | Offset | Meaning | When it is useful | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | **None** | No percentage reduction is applied to the modelled value. | Investigate departures from expected reference operation. | | **Fixed** | The full reduction applies from the configured start date. | Track a measure expected to take effect on a known date. | | **Gradual** | The reduction increases evenly from zero to the selected percentage between its start and end dates, then remains at that percentage. | Track a programme expected to deliver improvements progressively. | The percentage offset is not the moving baseline's **Offset days**. One changes the target allowance; the other changes where the historical reference ends. ### Example: an improvement that still misses the goal Suppose the modelled reference value for a day is **1000 kWh**. A **Fixed** 10% reduction makes the target **900 kWh** once the offset starts. If actual consumption is **950 kWh**: * It is 50 kWh below the modelled reference value. * It is still 50 kWh above the reduced target. * The actual-minus-target difference is **+50 kWh**. Consumption is lower than the modelled reference, but the 10% goal has not been met. That distinction is why a reduction relative to historical operation and compliance with a target are not the same result. These numbers are illustrative, not readings from the figures or a recommended reduction goal. ### A gradual target is not a steadily falling consumption line With a **Gradual** 10% reduction, the allowance is 100% of the modelled value at the start, 95% halfway through the offset period, and 90% at its end. The modelled value can still rise on a colder day or fall during a quieter operating period. Compare actual consumption with the allowance for the same interval, rather than expecting every point on the target line to be lower than the preceding point. Other settings also change the comparison. **Slope mode** determines how an existing reference-period trend is treated; **Timeframe** sets the calculation's aggregation interval. An hourly difference is not directly comparable with a monthly difference of the same numerical size. See [-> Configure a Baseline](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/configure-a-baseline.md) before changing these settings. ## Check whether the reference is credible Before judging later performance, inspect how the model represents the reference period. In **Target line overview**, the shaded region identifies that period. Start with **Predicted vs actual**: does the model broadly follow the measured operating pattern, or does it repeatedly miss normal peaks, quiet periods, and seasonal changes?
Target line overview showing predicted and actual values, absolute difference, percentage difference, and CUSUM for a selected historical baseline

The four preview charts show different aspects of the same comparison. Read them together with the highlighted reference period and the selected baseline settings.

For a reference without an intentional reduction, differences should be broadly balanced rather than persistently biased in one direction. A strong trend in the differences already inside the baseline can make later changes difficult to interpret. Use the **Metrics** tab as supporting evidence: * The coefficient of determination, **R²**, helps assess how well the model explains variation in the evaluated data. * Error metrics such as mean absolute error (**MAE**) and root mean square error (**RMSE**) help assess the size of prediction errors. Interpret them against the source unit and typical values. * Check the evaluated period and available data, not only the headline score. A good score is not proof that the reference represents efficient operation, that a change was caused by an intervention, or that the model will be equally reliable under different conditions. Review the charts, data quality, and operating context together. For the chart interactions and metric definitions, see [-> Review a B\&T Config](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/review-a-target.md). ## Read the results from four perspectives The preview and Insight Analytics provide complementary views. Each answers a different question. ### Actual and target: where do the curves separate? **Usage vs target** shows the measured and target values together. Look for whether a gap is occasional, seasonal, or sustained. A falling actual curve does not by itself mean a target is being met. The target may be falling faster. Equally, rising energy use may remain within a modelled allowance that reflects higher demand. ### Difference: how large is the gap? **Overspend** shows the actual-minus-target difference: `difference = actual value - target value` For positive energy-consumption targets, a positive value means use above the allowance, a negative value means use below it, and zero means a match. Despite the name **Overspend**, these differences are not automatically monetary costs. With an energy source in kWh, the absolute difference is in kWh. Whether a positive or negative difference is desirable depends on the measurement. Lower energy use can be desirable; lower production output may not be. Even lower consumption needs context: a closed building or an incomplete meter history can also produce it. ### Percentage difference: how large is the sustained relative departure? **Percentage difference** compares trailing moving averages of actual and target values. It is not the percentage difference for each individual pair of observations. For a positive smoothed target: * A rise from **-20% to -5%** remains below target, but the margin is shrinking. * A fall from **+20% to +5%** moves closer to the target, but remains above it. * Zero means the smoothed values match, including any reduction already applied to the target. Do not add percentage samples to calculate an overall deviation. {% hint style="warning" %} If the moving-average target is zero or very close to zero, the generated percentage output is set to zero to avoid division by zero. That zero does not prove the target is met. Check the absolute difference and underlying values instead. {% endhint %} ### Cumulative sum: are small differences adding up? **Overspend CUSUM** displays the cumulative sum (CUSUM) of the raw interval differences. For example, differences of **+20 kWh**, **-10 kWh**, and **+30 kWh**, starting from zero, produce cumulative values of **20 kWh**, **10 kWh**, and **40 kWh**. The final accumulated difference is 40 kWh. Adding the three cumulative values together would count earlier differences again. Read the slope separately from the curve's height: * A rising curve adds net above-target differences. * A falling curve adds net below-target differences. * A nearly flat section adds little net difference, even if individual differences are not zero. If an upward curve becomes flat after an intervention, new excess has stopped accumulating over that section. The earlier excess has not automatically been recovered. A bend in the curve can help locate when performance changed, but it does not establish why. ## Put the comparison to work ### Operational monitoring Use a moving reference when the question is whether current operation departs from recent behaviour. An absolute difference can support a rule for excess in the source unit; a percentage difference can support a rule for a relative, sustained departure. Choose a threshold that allows ordinary variation and matches the source unit and calculation timeframe. A deviation is a reason to investigate the meter, equipment, schedules, weather, and building use, not an automatic diagnosis. ### Improvement tracking Use a fixed, representative pre-intervention reference and the appropriate reduction offset. Follow actual values against the changing allowance, then use differences and CUSUM to see how the gap develops. Keep the reference and settings documented. If you change the baseline while assessing a project, you change what the comparison means. A lower measured value alone is not a verified saving caused by that project. ### From a preview to platform-wide outputs Saving a baseline does not activate it. Activation starts background calculations and creates normal asset attributes for target values, absolute differences, percentage differences, and CUSUM. You can use these `[B&T]` attributes in rules, rule chains, and dashboard widgets like other attributes, subject to the usual selector requirements. Calculated history may not be available immediately after activation. See the [-> generated attribute reference](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets.md#generated-asset-attributes) for their exact names, where they are added, and their lifecycle. Check dependent rules and widgets before pausing or deleting a baseline: those actions can remove generated values and history. ## Continue in the product guide Use the separate procedures when you are ready to configure your own comparison: * [-> Create a B\&T Config](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/create-a-target.md) to select the measurement and optional feature inputs. * [-> Create a Baseline](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/create-a-baseline.md) to choose fixed dates, a moving reference, or automatic detection. * [-> Configure a Baseline](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/configure-a-baseline.md) to set the reduction, trend treatment, and timeframe. * [-> Review a B\&T Config](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/review-a-target.md) before activating its outputs. * [-> Activate or Pause a Baseline](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/activate-or-pause-a-baseline.md) to control background processing. * [-> View a B\&T Config in Insight Analytics](/collection/platform/platform-core/baseline-and-factors/portfolio-benchmark-and-targets/view-a-target-in-insight-analytics.md) to explore the generated history. ## Key takeaway A useful benchmark is not just a line to beat. It is a clearly chosen reference that makes a performance difference interpretable. Choose the measurement and reference to match the decision, apply a reduction only when it represents your goal, and read actual, absolute, relative, and cumulative results together. The result helps you identify where to investigate and whether operation is moving towards the selected target; it does not replace judgement about data quality, building conditions, or the cause of a change. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.buildings.ability.abb/collection/academy/building-intelligence-ai-and-machine-learning-in-buildingpro-suites/machine-learning/introduction-to-benchmarking-and-targets.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.