The FeatureExtractor beans transform raw process data into numerical features suitable for Fault Detection and Classification (FDC), troubleshooting, dashboards, reporting, machine learning, and AI-assisted diagnostics.
Unlike traditional charts that display raw signals, FeatureExtractor summarizes the behavior of one or more process variables over a specified time window.
The resulting JSON may be consumed by:
* Apache ECharts visualizations * Rules engines * Machine learning models * MCP servers and Large Language Models (LLMs) * FDC applications * Custom MIStudio scripts and workflows
The FeatureExtractor beans are deterministic. They perform mathematical operations only and do not perform diagnosis or generate recommendations.
FeatureExtractorWide operates on tabular datasets where each process variable is represented by a separate column.
Example:
| Timestamp | SteamTemp | SprayFlow | SprayValve |
|---|---|---|---|
| 09:00:00 | 542.1 | 2.4 | 14.1 |
| 09:00:05 | 541.8 | 2.5 | 14.3 |
| 09:00:10 | 541.2 | 2.8 | 14.9 |
This format is commonly encountered when:
* Importing CSV files * Querying traditional relational databases * Working with laboratory or batch datasets * Evaluating historical snapshots
FeatureExtractorNarrow operates on historian-style datasets where tag values are stored as rows.
Example:
| Timestamp | Tag | Value |
|---|---|---|
| 09:00:00 | SteamTemp | 542.1 |
| 09:00:00 | SprayFlow | 2.4 |
| 09:00:00 | SprayValve | 14.1 |
This format is commonly encountered when:
* Using industrial historians * Working with TimescaleDB hypertables * High-cardinality telemetry systems * Long-term archival systems
Both beans produce identical output JSON.
FeatureExtractor may be used as an FDC engine by computing features between significant process events.
Examples include:
* Wafer Start → Wafer Complete * Carrier Arrived → Carrier Departed * Recipe Start → Recipe End * Batch Start → Batch Complete * Alarm Raised → Alarm Cleared
Rather than classifying faults using raw traces, the FDC system classifies based on extracted behavior.
For example:
* Maximum chamber pressure * Mean RF power * Temperature ramp rate * Dominant vibration frequency * Oxygen excursion duration * Correlation between gas flow and pressure
This often produces more robust fault signatures than using raw data directly.
* count * mean * median * min * max * range * stddev * variance
* first * last * delta * percent_change * slope * rate_of_change
* duration_above_threshold * duration_below_threshold * excursion_count
* dominant_frequency * dominant_period * top_frequencies * spectral_power
Frequency-based metrics are especially useful for:
* Motor vibration * Fan instability * Oscillatory control loops * Pump cavitation * Mechanical resonance
* correlation * lag_correlation * correlation_matrix * lag_correlation_matrix
Relationship metrics quantify how variables move together and whether one signal leads another.
FeatureExtractor reports data quality information independently of the extracted features.
Examples include:
* Expected sample count * Observed sample count * Missing sample count * Missing percentage * Resampling method used
Custom expectations may also be evaluated.
Examples:
* Expected number of Wafer Complete events * Expected number of Carrier Departed events * Expected number of recipe steps
Feature extraction is configured using JSON.
The request specifies:
* Data source * Time range * Sampling period * Feature groups * Metrics to compute * Quality expectations
FeatureExtractorRequest may be generated manually, through scripts, by MIStudio workflows, or by AI systems.
The output is a deterministic JSON document containing:
* Computed metrics * Data quality information * Optional MCP metadata
The output intentionally excludes:
* Diagnoses * Recommendations * Confidence estimates * Root cause determinations
These higher-level interpretations may be performed by:
* Rules engines * Statistical models * Human operators * Large Language Models
FeatureExtractor is frequently used together with KnowledgeBase and MCP components.
Typical workflow:
User Question → KnowledgeBase Retrieval → FeatureExtractorRequest → FeatureExtractorWide/Narrow → FeatureExtractorResult → MCP Server → LLM Explanation
In this architecture:
* KnowledgeBase determines what should be examined. * FeatureExtractor computes the evidence. * MCP exposes the evidence. * The LLM explains the evidence.
Because FeatureExtractor produces deterministic output, the same evidence can be consumed by multiple AI models or non-AI systems.