Assets

Overview

In the context of Bazefield, an Asset is the fundamental digital object used to represent a physical or logical component of a renewable power plant. Assets serve as the building blocks for structuring and visualizing data in a way that aligns with the physical systems and operational logic of wind, solar, hydro, storage, and grid-connected infrastructure.

An Asset in Bazefield is more than just a data point — it’s a structured, object-oriented representation of physical plant infrastructure. It serves as the digital twin for real-world equipment and is key to organizing data, modeling performance, and enabling scalable analytics across renewables.

Definition

Assets are the fundamental building blocks of how data is modeled and organized within Bazefield. Each asset serves as the logical container for its underlying telemetry — including all tags sourced from the SCADA system — and represents a real-world piece of equipment in digital form. In short, an asset:

• Represents a real-world component (e.g., wind turbine, inverter, transformer), or a logical group of several interconnected components (e.g. a substation, an inverter station, a whole site in itself)

• Belongs to a broader Asset Type that defines its functional identity and classification.  

• Is typically instantiated from a specific Asset Model of that Asset Type (e.g. a “Vestas V90 3MW” is an asset model of a “wind turbine” asset type)

Why Assets?

Asset-oriented approaches to modeling the vast volumes of data produced by a power plant offer significant advantages over traditional tag-based or non-object-oriented methods.

The Tag-Based Approach

In a typical SCADA system, a tag is the most granular unit of data — a simple time-series stream of a single value (e.g., voltage, power output, breaker status) recorded at regular intervals. While it’s possible to view a power plant as a flat list of thousands of these tags, this approach quickly becomes cumbersome and difficult to scale, particularly when you're trying to extract meaningful insights, compare performance across assets, or manage large fleets.

In tag-based systems:

• There’s no inherent context for what a tag belongs to.

• There’s no hierarchy to understand system relationships.

• There’s no standardization, making cross-site or cross-technology reporting error-prone and time-intensive.

• Tags often differ by SCADA vendor, site, or naming convention, creating ambiguity and friction.

The Asset-Based Approach

To solve this, Bazefield employs an asset-based (object-oriented) modeling framework that transforms flat, unstructured tag data into organized, contextualized digital representations of real-world equipment. Each asset — such as a wind turbine, solar inverter, battery rack, or substation transformer — is modeled as a digital twin, grouping its relevant tags and telemetry under a unified structure.

Each asset is also linked to an Asset Model, which defines:

• The expected structure of its data

• How KPIs and calculations are applied

• The logic for interpreting performance or status

This modeling structure creates a clear and reusable foundation for analytics, visualization, and fleet-wide consistency.

In Bazefield, analogous “tags” for all assets are represented as “Points.” For instance, a power facility with 125 wind turbines is likely to have 125 “tags” for Nacelle Wind Speed readings. These would be consolidated under a shared point “Windspeed,” allowing the attributes of that point to be managed and controlled collectively for all assets, rather than individually for each tag.

Beyond points, other critical data associated with assets in the Bazefield include (but are not limited to):

• • Attributes:  Static key, value pairs of user defined data (e.g. the Rated Power attribute on a Vestas V90 3MW asset model would be 3000 kW).

  • Points: Time-series data streams that represent physical quantities over time (e.g. “Active Power”)

  • Events: Discrete occurrence or state change.  Unlike points, which track continuous time-series data, events are time-stamped records of something specific that happened — such as a fault, status change, threshold breach, or operational transition (e.g. a Vestas 309 Pause Pressed on Keyboard alarm code).  Articles Coming Soon

  • Allocations:  A system or manual generated categorization of time, typically driven by event or other logical triggers, used for availability logic and reporting. Article Coming Soon

  • Cases:  collaborative, traceable object in the system used to group related events and track follow-up activity on a specific asset or group of assets. It functions like a ticket or incident report, providing a workflow for users to assign, investigate, resolve, and document operational issues, performance anomalies, or maintenance needs. Article Coming Soon

  • Work Orders: A structured record that represents the labor, time, and tasks performed during a physical intervention on one or more assets, often modelled as part of a Case. Article Coming Soon

  Subsequent articles in this section describe each of these data model concepts associated with the asset in detail.

Real-World Example

The image below, taken from the Bazefield Object Manager application, is a real-world example of how Bazefield structures a solar site using asset-based modeling. In this case, we’re looking at a site called "Solar Farm 2", which includes eight PV inverters labeled SF2-INV01 through SF2-INV08.

Each of these elements — from the inverters to the site itself — is modeled using the same object-oriented structure, enabling consistent behavior, analytics, and hierarchy.

• Each inverter (e.g., SF2-INV01) is represented as a separate Asset (see above)

  • These belong to the "PV Inverter" Asset Type, which groups all inverter assets based on their role.

  • Inverter SF2-INV01 above, is then mapped to a “TMEIC Inverter” model.  This model defines

    • Which points (tags) belong to the asset

    • How KPIs like uptime, output, and efficiency are calculated

    • Logic for alarms, health, and state detection

• The parent node, "Solar Farm 2", is also an Asset.

  • It has the "Solar Farm" Asset Type, just like an inverter has "PV Inverter."

  • It uses a Site-Level Asset Model that defines how to:

    • Aggregate data from its child inverters

    • Track site-wide production, availability, or curtailment

    • Incorporate data from weather sensors or the point of interconnection

Why This matters

This example highlights one of the core strengths of Bazefield’s architecture:

Whether you're modeling a single inverter or an entire solar farm, the same asset-based principles apply — with consistent structures, point logic, and calculation behavior.

This allows:

• Easy navigation and visualization of plant hierarchy

• Scalable analytics, from component to fleet level

• Clear ownership of data, improving traceability and maintainability

• A foundation for digital twin functionality, as every asset mirrors a real-world object