Points

Overview

Points are dynamic, time-series values that represent the quantitative value of a certain sensor over time. Unlike attributes — which describe what an asset is — points capture what an asset does and how it behaves. They’re the core telemetry used to visualize performance, detect issues, calculate KPIs, and normalize data across vendors or technologies.

In Bazefield, points either represent direct measurements from data sources and devices (e.g. “raw” or scaled SCADA telemetry), or calculated using expressions and deterministic logic. Every point belongs to a specific asset and updates over time as new data is received.  Historical point data is saved in the Bazefield Data Engine & Historian, which supports multiple database technologies.

Definition

A point is a named variable bound to real-time and historical data for an asset, It can represent physical measurements (like wind speed or power output), system statuses (like fault states or curtailment), or derived analytics (like performance ratios or expected generation).  

From an end-user perspective, there are two main classes of points in Bazefield:

• Device Attached (“Raw”) Points – Time series data directly mapped to the output of a sensor from an external source like SCADA interfaces, PLCs, APIs.  Device attached points are typically read into the system in their “raw” state with only minor scaling manipulation or validation as needed.  Often these points are sourced and mapped on the Bazefield Edge Buffer.

• Calculated Points – Values derived within Bazefield centralized architecture using online expressions, interval logic, or calculation models.  These points are typically configured on the Bazefield web portal, and calculated on either the Bazefield Storage Node or the Bazefield Proxy Node.

Point data itself is represented by 4 main components:

• A Name (e.g., ActivePower)

• A TimeStamp (e.g., 12:35:49.271 UTC)

• A Value (e.g., 78.237)

• A Quality Flag (e.g., 192:GOOD)

Points vs Tags

Many SCADA engineers are used to referring to the local address or register of a sensor on a SCADA interface as a “tag”.  A tag refers to a single telemetry stream tied directly to a single sensor, register, or data point on a physical device.  These tags are often formatted using vendor-specific naming conventions, making them difficult to standardize across technologies, plants, and fleets of assets.  

Bazefield introduces a structured, model-driven approach that separates low-level SCADA tags from domain-level telemetry points, enabling vendor-agnostic and scalable data handling.

For example, a wind farm SCADA system might expose a tag such as:

WP1.T001.P_ACT

• WP1.T001.P_ACT represents the full tag name as represented on the SCADA OPC device (e.g. data source)

• WP1.T001 represents the asset identifier in the SCADA system (in this case the name of a specific turbine)

• P_ACT is the vendor-defined signal name, in this case representing the Active Power measurements of Turbine 1 of Wind Plant 1.

In Bazefield, P_ACT would be modeled as a Device Point, which is then mapped to a Domain Point — a normalized name used across all assets, vendors, and SCADA sources.  In this case, “ActivePower” would be a good choice for a user-friendly normalized point name by which the data is accessed.

To further unify and standardize the signal, Bazefield also creates a Bazefield-specific normalize Tag Name by concatenating the asset name with the Domain Point name, separated by a hyphen.  In this case, the Bazefield tag name may be:

WP1-WTG001-ActivePower

A summary of this relationship is provided in the table below, a snippet from the Bazefield Asset Models application which administers Bazefield points.

This layered approach empowers users to work with a clean, standardized telemetry model while retaining traceability to the original SCADA sources.

From a user perspective, it enables the Bazefield applications and users to access data more simply by defining just the point name and the asset name (see example below in the Bazefield data export application).

Examples of Common Points

The table below provides some simple examples of various points modelled in the Bazefield system.  For a complete description of Bazefield product certified point definitions per asset type, visit the Certified Product Templates section.  These templates essentially give both Bazefield support engineers and clients a starting point for what data is required to be modelled for different types of assets in renewable power plants.

Why Points Matter

✔️ Operational Clarity
They show you exactly what’s happening now — at the asset level and across your fleet.

✔️ Performance Insight
Points power every KPI, downtime metric, and calculation you rely on for benchmarking and optimization.

✔️ Vendor-Agnostic Modeling
Use calculated points to standardize behavior across OEMs and systems.

✔️ Automation & Scalability
From alarms to availability modeling, points enable advanced automation and rule-based behavior.

✔️ Data Integration
Every point is historized, available to export, and ready to feed into external BI, reporting, and grid systems.