--- title: "Assets" slug: "assets" status: "update" updated: 2025-07-15T22:14:43Z published: 2025-07-15T22:14:43Z canonical: "docs.bazefield.com/assets" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.bazefield.com/llms.txt > Use this file to discover all available pages before exploring further. # 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) ![](https://cdn.document360.io/a0786c0f-b171-4b24-8860-c32eb7ef2738/Images/Documentation/image-1744686048273.png?sv=2026-02-06&spr=https&st=2026-11-06T19%3A51%3A24Z&se=2026-11-06T20%3A51%3A24Z&sr=c&sp=r&sig=PdTbJCWWvNq3cKbUUPkcGoSSqkwNjApHpb7t3jXQT7Y%3D) | Property | Description | | --- | --- | | **Unique Identity or “Key”** | Each asset has a uniquely identifiable object Id and key in the system | | **Name** | Display name used in the user interface to identify and choose the asset. | | **Asset Type** | Defines what kind of object it is in functional or operational terms | | **Asset Model (***optional, but suggested***)** | The data structure and behavior of an asset within the software. While an Asset Type tells you what an asset *is* (e.g., a wind turbine, a PV inverter), the **Asset Model** tells you **how that asset is modeled** — including its **points (telemetry), events, and allocations.** It enables variations in how different real-world devices of the same type are configured, without changing their classification (e.g. a “GE” wind turbine versus a “Vestas” wind turbine) | --- ## **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. ![](https://cdn.document360.io/a0786c0f-b171-4b24-8860-c32eb7ef2738/Images/Documentation/image(95).png?sv=2026-02-06&spr=https&st=2026-11-06T19%3A51%3A24Z&se=2026-11-06T20%3A51%3A24Z&sr=c&sp=r&sig=PdTbJCWWvNq3cKbUUPkcGoSSqkwNjApHpb7t3jXQT7Y%3D) **Comparison between a flat “tag” based approach to modelling and accessing telemetry in a power plant (left) with an asset and asset model organized approach (right)** 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): - Subsequent articles in this section describe each of these data model concepts associated with the asset in detail. - [**Attributes:**](/product/docs/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:**](/product/docs/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** --- ## 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. ![](https://cdn.document360.io/a0786c0f-b171-4b24-8860-c32eb7ef2738/Images/Documentation/image(87).png?sv=2026-02-06&spr=https&st=2026-11-06T19%3A51%3A24Z&se=2026-11-06T20%3A51%3A24Z&sr=c&sp=r&sig=PdTbJCWWvNq3cKbUUPkcGoSSqkwNjApHpb7t3jXQT7Y%3D) 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. ![](https://cdn.document360.io/a0786c0f-b171-4b24-8860-c32eb7ef2738/Images/Documentation/image(88).png?sv=2026-02-06&spr=https&st=2026-11-06T19%3A51%3A24Z&se=2026-11-06T20%3A51%3A24Z&sr=c&sp=r&sig=PdTbJCWWvNq3cKbUUPkcGoSSqkwNjApHpb7t3jXQT7Y%3D) - **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: > [!WARNING] > 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