Events

Overview

In Bazefield, Events represent time-bound digital conditions—typically signaling a change in the operational or physical state of an asset. Events capture key moments such as faults, alarms, run status, curtailments, and manual interventions, and are essential to operational awareness, downtime analysis, and intelligent alarm handling.

Unlike telemetry points, which continuously stream numerical data, Events define discrete periods where something happens, with a clear start and stop time, and a code or description indicating what occurred.

What Is an Event?

An Event is best understood as a unique combination of:

• An object (e.g., wind turbine, inverter, feeder)

• A start time

• An end time

• A code or description of the condition

Events are typically automatically generated from real-time telemetry (e.g., alarms, statuses, triggers), but may also be created manually—for example, by operators or imported logs.

📌 Example schema:

• Object: WF1-WTG001

• Start: 2022-11-01 09:47 UTC

• End: 2022-11-01 09:50 UTC

• Code/Description: Temperature Fault (277)

Examples of Events

• An inverter reaches run status and begins producing power

• A turbine faults with alarm code 277

• A feeder breaker opens due to manual intervention

• A site receives an external signal to limit power

These moments are captured as Events and stored for historical visibility, real-time monitoring, and downstream analytics.

How Are Events Generated?

Bazefield supports several methods or “protocols” for creating event automatically from telemetry.  The six most common distinct methods for generating events, supported across all technologies are described below with examples.

1. Single Point Events (one point for all events)
   These are discrete telemetry points (typically time-series integer point values) that represent multiple alarm states through different values. Each value corresponds to an event code, which Bazefield uses to match metadata from an event template. These points can originate from raw on-site SCADA systems or be user-defined calculations.  Single point events have the inherit restriction that only one event can ever be active at once when using them.

   

2. Multiple Point Events (one point per event)
   In this method, each alarm has its own binary (1/0) tag indicating its active state. Bazefield maps the point name directly to an event template to retrieve metadata. Like single point alarms, these can also come from raw SCADA data or from user-created expressions (e.g. online or interval-based calculations).  Multiple point events are very common for modern-day inverters where every alarm, status, and warning has it’s own independent 1/0 boolean tag on the interface.  While more complex than single point events, multiple point events offer the inherit advantage that an asset can correctly have more than one event active at once at any given point in time.

3. Binary Alarm Points (Bit Parsing)
   A single telemetry value represents multiple alarms encoded as a binary number. Bazefield parses the binary stream digit-by-digit, with each bit position mapped to a specific alarm via an event template.

4. Direct Database Tables or Views
   Bazefield can integrate directly with OEM-specific SQL databases via ODBC to pull alarm and event history logs. This is particularly common in wind turbines, where SCADA providers maintain event logs in local databases.

5. Event Conditions
   A flexible and modern method for defining custom alarms. Users can configure logical expressions that monitor telemetry values (or combinations) over a time duration. When the condition is met—for example, a temperature remaining above 70°C for one hour—an event is triggered. This feature is ideal for customized fault detection or performance thresholds.

These capabilities enable Bazefield to support highly standardized, vendor-agnostic event generation across complex portfolios—while also offering the flexibility for advanced users to tailor event logic to their unique operational needs.