Asset Models

Overview

In Bazefield, an Asset Model defines the structure, behavior, and logic for how a particular type of asset operates within the system. It governs the way telemetry data (tags), calculations, KPIs, and events are handled for an asset — acting as a blueprint that gives meaning to raw data.

Asset Models are a critical part of Bazefield’s object-oriented architecture. They allow different real-world devices — even if they serve the same purpose — to be modeled consistently while accommodating differences in vendor, firmware, or site configuration.

Definition

An Asset Model is a reusable set of model templates that determines what data an asset includes, how that data is structured, and what rules or calculations apply. It defines how the system interprets telemetry points, alarms, events, allocations, and operational logic for a specific type of asset.

Each asset in Bazefield must be associated with one (and only one) Asset Model, which itself is tied to an Asset Type. While the Asset Type defines what the asset is and it’s broad functional purpose (e.g., inverter, battery rack, wind turbine), the Asset Model defines how that asset behaves in terms of its data and structure. There may exist several asset models within a single asset type

Core Characteristics & Templates

Beyond being associated and inheriting default attributes from its Asset Type, an Asset Model in Bazefield is not a single static definition — it's a modular structure, composed of multiple model templates, each defining a different aspect of how the asset behaves, processes data, and is visualized.

Each Asset Model is composed of these templates, allowing:

Consistent structure across similar asset types
Customization for OEM-specific or site-specific configurations
Easy updates and scalable deployment across large portfolios

These templates provide the foundation for turning raw SCADA data into structured, insightful, and actionable digital assets.

Model Template Type	Brief Description	Real-world Example
Point Templates Article Coming Soon	Dictates the normalized Bazefield specific namespace of an underlying time-series tag. Point templates organize expected data points (e.g., Active Power, Voltage), including names, units, and data types. These points could either be raw “device” driven points from the SCADA system directly, or a Bazefield calculated point based on a user-defined expression or model. An asset may have hundreds of individual points associated with it, and point templates help organize these in a logical fashion for the users.	A template of common KPI calculations (performance ratio, production, etc.) for a TMEIC inverter
Device Templates Article Coming Soon	Defines how the “device” points in a point template map to the underlying SCADA devices. While the point template defines the common normalized namespace of the telemetry (e.g. “Wind Speed”), the device templates describe on a model by model basis how the typical SCADA system associated with that model labels the associated point. Device templates are most common to model the OPC namespaces associated with various asset vendors.	A template of all the GE SCADA 12 OPC device points and namespaces for a GE wind turbine
Event Templates Article Coming Soon	Standardized event codes, names, descriptions, and associated attributes (e.g., severity, category) of the alarms, field status indicators, or warnings associated with assets of this asset model. Event templates are generally used to track and digitize vendor by vendor alarm lists and are most associated with SCADA firmware versions. Event templates are also used to track standard availability categorizations and rules associated with events, so that users can control what time is counted as “available” versus “unavailable”.	A template of all alarms and vendor, IEC, and GADS classifications for a Vestas V90 wind turbine with Vestas Online Business SCADA systems
Allocation Rule Sets Article Coming Soon	A sequential list of rule-based conditions for one or more availability “allocation” systems used to determine how an asset's current state should be categorized within a predefined set of performance or availability categories (e.g., Available, Unavailable, Curtailed). This approach guarantees a deterministic, auditable path for how performance time is attributed.	A solar IEC allocation system, based on how a Sunrun inverter should be classified based on its events and points
Workflow Templates Article Coming Soon	Automated workflow rules that can associated model events with automated work flows that are processed when that event changes state (e.g. starts, ends, is acknowledged, changes priority). This is most useful for Remote Operators to automate mundane communications and work when a certain event or fault occurs, rather than have to perform the actions manually each time.	A template connecting critical safety alarms for a substation to automated priority escalations and emails
Script Models Article Coming Soon	Auxiliary scripts that can operate on all assets using this model — e.g., adjustments, tagging, cleanup, scheduled processing jobs, etc.	A backfilling script that is required to be run for a Siemens Gamesa wind turbine for re-pulling its historical reporting data from its SCADA SQL Server
Control Commands Article Coming Soon	A template of writeable device points with for asset control, along with their meaning (description, name, etc) for control purposes	The 15 OPC commands available for a Nordex wind turbine supervisory control

Real-World Example: Designing a Site

This image illustrates how asset models and templates are applied across different asset groups within a renewable energy site — in this case, Site A — using Bazefield’s object-oriented modeling framework.

Model Inheritance

Bazefield supports model inheritance, allowing asset models and their associated templates (such as point templates, event templates, allocation rule sets, and device mappings) to be inherited from a parent model. This means users can define shared logic, structure, and rules at a higher level — such as for an entire technology type or OEM — and have those settings automatically applied to all child models. Inheritance enables efficient reuse, centralized control, and easy customization, as child models can override only the specific elements they need to differ, while still benefiting from the foundation defined in the parent. \

Real World Example

The image below provides a real-world modelling example of how model inheritance is leveraged to simplify and organize the modelling of wind turbine asset types in Bazefield.

Core Model Layer – (Orange Horizontal Bar):

- The Wind Turbine CORE Model contains logic, telemetry definitions, and rules that are shared across all wind turbines, regardless of manufacturer.
- This layer acts as a universal baseline model that all vendor-specific models inherit from.
Vendor-Level and Variant-Level Models (Orange Boxes):
- Below the core model, there are vendor-specific layers (e.g., Vestas, GE, Vendor N), each inheriting from the core model and including logic unique to that vendor’s fleet.
- Each vendor model can contain multiple sub-models for different variants (e.g., Vestas V90 3MW, GE 2.7MW 127m) — capturing model-specific telemetry, alarms, and allocation rules.
- This allows Bazefield to support standardization where possible, and customization where necessary.
Bottom Layer – Actual Asset (Green Box):
- A specific physical asset (e.g., WTGA01 from Wind Farm 1) is instantiated from one of the leaf-level models (e.g., “Vestas V90 3MW”).
- This asset inherits all templates and logic defined at the core, vendor, and variant levels — forming a complete, digital twin of the real-world turbine.

A similar approach is used to model vendors of PV inverters, as well as storage Power Conversion Systems.