| Term | Definition |
|---|---|
| Alarm Load | Alarm Load refers to the assessment of real-time data against an expected range derived from benchmarking. If the data falls outside the "normal operational range," it's flagged as "not normal"; otherwise, it's deemed Normal. |
| Alarm Model | An alarm model assesses real-time data against a predefined expected range determined by a predictive model. The Alarm Model is deemed "not normal" if it falls above or below the "normal operational range." Conversely, if the value lies within this range, the Alarm Model is considered Normal. |
| Alarm Time | Required observation time of the values of the tag to consider it as a deviation. |
| Anomaly | Automatic warning that the system generates based on deployed predictive models. Deviations on non-KPI tags are reported as Anomalies. |
| APC | Auxiliary Power Consumption |
| APR | Advance pattern recognition |
| Asset | The entire plant |
| Auxiliary power consumption | The consumption of power by the auxiliary components of main equipment. For example, a boiler. To run, a boiler needs motors, pumps, fans etc that consume power. Suppose the Turbine generates 150 MW power, the auxiliary equipment consumes about 8 to 10 percent of the power generated by the turbine, |
| Bad Direction | Alarms are Low, Normal, or High in intensity. Defining Bad Direction makes an alarm unidirectional. In other words, if alarm is required to be triggered only when the intensity of an occurrence is High, the Bad Direction value must be High. |
| Benchmarking | A process wherein based on years of historic values of a particular Sensor (Tag), an accepted/"good" operating range is determined. This range is dynamically updated and stored in the tag's metadata. |
| BEP Operating Range | The recommended operating band defined around the Best Efficiency Point, typically 70% to 110% of the BEP flow. Operation within this band (shown as the green zone) is considered healthy; operation outside it (red zones) indicates inefficient or potentially harmful conditions. |
| Best Efficiency Point (BEP) | The flow rate at which the equipment operates at its maximum efficiency, as specified in the equipment datasheet. Operating close to the BEP minimises energy loss and mechanical wear. |
| Characteristic Performance Curve | A visual comparison between the design performance of rotating equipment (such as pumps and compressors) and its actual operating performance. The design curve supplied in the equipment datasheet is digitised in Pulse, and live sensor data is plotted on it so that users can see at a glance whether the equipment is operating within its expected range. |
| Component | The various parts of an equipment |
| Critical Limit | The maximum allowable value for a sensor tag, specified by the client during onboarding. Crossing this limit indicates an abnormal or unsafe equipment condition and is the threshold against which Remaining Useful Life is calculated. |
| Criticality | Severity of an occurrence or incident |
| Curve Fitting (Polynomial Coefficients) | The method Pulse uses to recreate a datasheet curve mathematically. Points read from the original graph are fitted with a polynomial equation (intercept, x, x², x³ …); the coefficients are tuned until the generated curve closely matches the original, allowing values to be calculated for any intermediate point. |
| Data validity | Valid data of the tags fluctuated within the threshold limits and is never constant even when the equipment is in running condition. |
| Design Curve | The expected behaviour of equipment across its operating range, taken from the manufacturer’s datasheet (for example, Flow vs Efficiency, Head or Power). In Pulse it is shown as the black reference line on the characteristic curve. |
| Deviation | When a Sensor records an abnormal value (higher or lower) than the benchmarked value, a deviation is created. |
| Deviation Vs Incident | When a Sensor (Sensors are referred to as Tags across the Platform) records an abnormal value (higher or lower) than the benchmarked value, the value is considered to be a Deviation. Deviations are tracked through various means such as boolean events, equipment load deviations, model deviations, etc. Isolated deviations, if any, are closed as soon as the recorded value falls back to normal. However, if the deviations continue to recur over a considerable period of time, and trigger other deviations, an Incident is generated. An incident, therefore, is a cluster of correlated deviations. In the initial stages, the Platform assesses if the group of deviations meets the criteria to initiate an incident. At this point, there are two possibilities: either an incident is already underway, or a new one needs to be initiated. Simultaneously, only one active incident is allowed for a fault-tree. If a new incident needs to be initiated, the platform examines if any incident has been closed within the past 24 hours. If affirmative, the same incident is reopened, but only if the incident has been reopened fewer than 10 times previously or has remained inactive for a month. Subsequently, on the newly opened incident or the one that is already active, various actions are taken. These actions include updating the incident with new data, providing information on the root cause and recommended actions, updating the priority, and presenting a set of questions where sensors are not present. Deviations are categorized into either KPI or non-KPI types. Subsequently, they are further classified based on their deviation type and directed to the respective detector. Upon receiving the deviations, the detector assesses whether they meet the criteria for initiating or concluding a faultTree issue. Should the deviations meet the conditions for opening a faultTree incident, they are routed to the incident opening module. Conversely, if they satisfy the closing conditions, they are directed to the incident closing module. Every incident when generated undergoes a process that determines what its severity should be. The longer and more a parameter deviates from its expected behavior, the greater the severity would be. |
| Equipment | The components making up a System (Economizer, heater, etc). Equipment is usually a set of self-sufficient machinery that contributes to a specific aspect of the functioning of a System. |
| Expected Band | The range of values a tag is expected to stay within under the current operating conditions, derived from benchmarking or predictive models. It is shown as a shaded band on incident and deviation charts; values outside the band are treated as deviations. |
| Fault Tree & Anomaly Engine | Incident sources in the platform are of two types - Anomaly Engine (Operations) and Fault Tree (V2). A Fault Tree Template is a generic template that diagnoses the root cause(s) of observed deviations in an asset, based on a set of predefined rules. These rules are used to determine what kind of faults have occurred and what their causes are. A fault template is generic among units, i.e., it's not attached to a specific unit. These templates have to be applied to a particular unit to define the faults of that unit. When a Fault Template is applied to a unit, it becomes a Fault Tree. Fault trees are unit specific, i.e., they contain tags specific to that unit. When a new Plant is onboarded, no Fault Trees are configured yet, but a number of Sensors (Tags) would have been onboarded simultaneously. During this initial period, instead of waiting for the Fault Trees to be configured and deployed, the Anomaly Engine is triggered, which starts throwing up incidents so that no alarms are lost. Incidents based on Fault Trees have Probable Root Cause(s) for analysis and mitigation plans. Fault Trees are gradually configured and deployed duly covering the Sensors deployed across the plant. As the number of Tags (Sensors) via the Fault Tree increases, the anomalies decrease. |
| Fault Tree Instance | A Fault Tree template when applied to a specific Unit becomes a Fault Tree Instance. A single template may end up as multiple instances when applied to a Unit (e.g. a HP Heater template will end up as 4 instances as applied to 4 individual HPH) |
| Fault Tree Template | Implementation of KPI along with Root Cause diagnostics in Pulse software format. Fault Trees usually trigger an Incident. |
| FGET | Flue Gas Exit Temperature |
| Fleet | Group of plants operated by an organization |
| Forecast Horizon | The forward-looking period over which the RUL model predicts sensor values — 15 days. The trained (historical) data is shown as a solid line and the predicted data as a dashed line in the trend chart. |
| Incident | Alarm generated when a KPI deviates. Each KPI typically is backed by a Fault Tree which also helps look across multiple sensors to identify a root cause.. An Incident contains details of the parameter deviation, root cause diagnostics detected automatically, ability to interact collaboratively and resolve the issue. |
| KPIs | Key Performance Indicators – critical indicators of health of an asset or a process which when deviates from an expected range, needs to be raised as an Incident |
| Load Bucket | A defined range of equipment load values used to group operating conditions. Vibration readings are normalised against the benchmark median for their load bucket, so that changes in load are not mistaken for deterioration. |
| Marker | A reference point placed on the characteristic curve using datasheet values, such as the Rated Point or the Best Efficiency Point. Markers make it easy to judge how far the current operating point is from the intended condition. |
| Measure location | The location at which the sensor is placed on the Equipment/Component/Sub-Component. E.g., Inlet, Outlet. |
| Measure property | The medium or base property of the System that is being monitored. |
| Measure type | The specific type of measurement carried out on the MeasureProperty. E.g., Temperature, Flow, Viscosity. |
| Measure unit | The standardized quantity used for expressing the result of a measurement. It provides a scale for measuring the value of the Measure Type. |
| MS Flow | Main Steam Flow |
| Noise | Incidents identified as false alarms or irrelevant are considered Noise. |
| Operating Point | The current, real-time position of the equipment on the characteristic curve, calculated from live tag values. It is shown as a marker so that actual performance can be compared directly with the design curve. |
| P-F Interval | The time between the point at which a potential failure can first be detected (P) and the point of functional failure (F). Early detection through RUL forecasting extends the usable P-F interval, allowing repairs to be scheduled during planned outages. |
| Plant | The industrial site with all the necessary physical and/or mechanical infrastructure |
| Predictive Maintenance | Predictive maintenance is work that is scheduled in the future based on analysis of sensor measurements and formulae. It uses data analysis to identify operational anomalies and potential equipment defects, enabling timely repairs before failures occur. It aims to minimize maintenance frequency, avoiding unplanned outages and unnecessary preventive maintenance costs. |
| Process excursion time | time window to trigger recommendation if process deviates the set time and density |
| Rated Point | The standard (nameplate) operating condition of the equipment as defined by the manufacturer. In many cases it coincides with the Best Efficiency Point unless the datasheet states otherwise. |
| Remaining Useful Life (RUL) | The estimated time, in hours, before a monitored temperature or vibration tag on rotating equipment is forecast to reach its defined critical limit. RUL helps maintenance teams plan interventions before a failure occurs. |
| Root Cause | A Root Cause can be defined as the fundamental reason or underlying factor that directly leads to the occurrence of one or more symptoms or undesired events within a system. Root causes are typically identified through thorough analysis and investigation of the system's components, processes, and interactions. |
| Site | The location at which the asset lies |
| Sub-component | The various parts of a component |
| System | Systems within an asset (Boiler system, condenser system, etc). A System is a collection of equipment that performs a specific task. |
| Tag | A tag is basically a description of a sensor. Each sensor in the plant is given a unique identifier called "dataTagId" along with information such as instrument properties, its location in the plant, the property it measures, etc. All this information is added to a record called "tag meta" in the Database. |
| Tag meta | Tagmeta is a Digital Blueprint of the physical asset. While onboarding an asset onto the platform, a hierarchical structure of the asset is created based on a format defined in the metadata such that the platform will be able to fetch relevant information for any given tag with ease. |
| Training Window | The period of historical data (the most recent 30 days of hourly averages, excluding shutdowns) used to train the RUL forecasting model at each retraining cycle. |
| Transient state of systems | When the load has a ramp up or ramp down, it is called transient state. To detect this, a threshold is set and any recordings beyond that threshold are considered to be in a transient state. |
| Unit | A plant is generally called a Unit |
| Within Limits / Limit Already Crossed | RUL status indicators. “Within Limits” means the forecast does not reach the critical limit within the forecast horizon. “Limit Already Crossed” means the training data has already exceeded the critical limit at least once, and the status persists until that period leaves the training window. |