MIStudio for Seeq Users

A practical guide for engineers and analysts who are comfortable with Seeq Workbench and want to understand how the same analytical questions are expressed in MIStudio.

The goal of this guide is not to reproduce Seeq's user interface or terminology. MIStudio takes a different architectural approach: instead of making every analytical concept a special object, it combines general-purpose data acquisition, query, transformation, analytics, visualization, storage, AI, and automation components in a common dataflow.

The fastest way to become productive in MIStudio is to translate the intent of a Seeq workflow, not necessarily every intermediate Seeq item, into the smallest set of reusable MIStudio components that performs the same job.

A Seeq user is accustomed to working with a small number of analytical item types. Signals contain time-ordered samples; Conditions contain time-bounded Capsules; calculations create new Signals or Conditions; Workbench presents those items in trends, tables, and other analytical views.

MIStudio starts one level lower. Data is carried by MIStudio value objects and DataSources, and logic-blocks (“Blocks”) consume and produce those values. A database query, process signal, waveform, feature result, table, or calculated series can all participate in the same graph.

In Seeq, an analyst often creates named intermediate analytical items: a Condition for production, another Condition for a subset of production, a derived Condition for the first run after an event, and then statistics or profiles based on those capsules. Those items make the analytical reasoning explicit inside the worksheet.

MIStudio generally asks a different question: is the desired dataset already expressible with a general mechanism? If SQL can identify the runs, use SQL. If a filter or existing Block can derive the desired records, use it. If FeatureExtractor can partition and qualify the runs directly, let it do so. A special-purpose object is added only when a general solution does not already exist.

A practical migration begins with the analytical question, then separates it into four concerns: data selection, run definition, measurement, and presentation/action.

1. Identify the source data and the context fields required to answer the question.
2. Define which records belong to the analysis and how repeated executions are separated into runs.
3. Choose what should be calculated for each run and how reference/candidate runs should be selected.
4. Choose where the result goes: chart, table, comparison, database, another analytic, AI, or operational action.

A Seeq implementation might create or reuse Conditions for chamber clean and process runs, derive the first qualifying capsule after each clean, and then overlay or summarize the selected capsules. In MIStudio the same intent can be expressed as a compact pipeline.

The easiest migration concept is the Signal. A Seeq Signal is an ordered collection of time-based Samples. In MIStudio the equivalent data may be a live DataSource, a database result column, a waveform, or a column in a TwoDimensionalValueObject. Charts and analytical Blocks consume the data without requiring it to be promoted into a special Signal object first.

This matters when moving beyond historian analysis. The same downstream analytics can consume data prepared from a database, a real-time source, a COMTRADE record, a process interface, or the output of a previous analytical stage.

A Seeq Condition is a collection of Capsules created using common logic. In MIStudio, the closest functional idea is the population of runs that the next analytical stage should see. MIStudio does not require that population to be represented by a dedicated object type.

• If the database already contains batch/job/event identifiers, SQL can return exactly the relevant executions.
• FeatureExtractor row filters can qualify source records.
• groupBy can partition records by job, lot, wafer, recipe, module, time bucket, or another identifying dimension.
• Contiguity logic can split repeated executions when no explicit run ID exists.
• Windowing can keep only the meaningful portion of each run.
• Upstream Blocks can derive relationships such as 'first after clean' when that context is not already present in the source.

For a Seeq user, the key change is this: do not ask 'Where do I create the Condition?' first. Ask 'What is the most direct general-purpose way to produce the records or runs I want to analyze?'

Seeq Formula provides a unified language for creating derived Signals and Conditions. MIStudio distributes that work across several general mechanisms. Simple data selection may be SQL; a deterministic transform may already exist as a Block; a compact expression or script can handle custom logic; FeatureExtractor requests describe grouping, windows, metrics, filtering, ordering, and selection; and complex reusable behavior can be packaged as a Block.

The migration objective is therefore not to translate each Formula expression syntactically. Translate what the expression accomplishes, then choose the MIStudio component that already performs that job.

For many Workbench analyses, FeatureExtractor is the MIStudio component that replaces several separate analytical steps. It takes source observations, partitions them into comparable runs, optionally splits and windows those runs, computes requested features, qualifies the results, and can rank/select runs.

Its effective pipeline is:

filters → resampling → grouping → contiguity → windowing → metrics → output filters → ordering → selection

Common features include statistical, amplitude, time-domain, threshold/event, frequency-domain, autocorrelation, and correlation measures. Raw samples can also be retained when the analysis needs to return to a trace view.

A Seeq user is accustomed to configuring many analyses through a tool panel rather than writing a document. MIStudio follows the same usability principle for common FeatureExtractor cases through FeatureExtractorRequestCreator. Its property editors expose connection/table/column selection, metrics, grouping, filters, output filters, ordering, selection, window mode and offsets, gap handling, and other common settings.

The generated JSON remains visible and is the canonical request. That gives advanced users, scripts, and AI tools access to capabilities beyond what the simple property editor chooses to expose.

A familiar Seeq workflow is to compare a current run with known-good behavior. MIStudio separates the selection of the reference from the comparison itself.

1. FeatureExtractor creates one feature set per run.
2. Filters and output filters define the eligible population.
3. Order establishes how the runs should be ranked.
4. Select can label one run as 'golden' and the remainder as 'comparison' in the same extraction.
5. FeatureComparator compares the reference with each candidate and produces both overall deviation and per-feature detail.

FeatureComparator supports pairwise comparison or one reference against many candidates. It matches features by feature group, tag, and metric and reports delta, percent delta, ratio, significance, missing features, and an overall score for each candidate.

A reference profile is one way to describe normal behavior across comparable runs. In MIStudio, separate the question into two parts: how the reference population is selected, and what representation of that population is useful.

• If the goal is one representative golden run, rank/select one run and overlay it with current candidates.
• If the goal is a population of known-good runs, keep the entire qualifying population and calculate statistics/features across it.
• If the goal is an expected trace envelope, retain relative-time samples and calculate the desired aggregate/envelope with a general transformation or another analytical stage.
• If the goal is detection, compare features and/or traces and route deviations into downstream event, storage, AI, or notification logic.

MIStudio intentionally does not require every one of these cases to be implemented by a dedicated 'reference profile' subsystem. The appropriate reusable components are composed according to the use case.

MIStudio charts and tables are consumers of data rather than special views tied to one analytics model. A SQL result can feed a chart directly. A FeatureExtractor result can feed a comparison or be materialized for display. The same value can be routed simultaneously to multiple consumers.

FeatureSampleSeries extracts raw samples from FeatureExtractor results and republishes them as a TwoDimensionalValueObject and as chart-ready series data. For repeated runs it can align each run on relative time, which provides the familiar overlay of runs that occurred at different wall-clock times. It can also use absolute time, categorical axes such as wafer/slot/step, or frequency for spectral output.

This is one of the most important differences to internalize when moving from an analysis-centered environment. MIStudio does not treat the output of FeatureExtractor as the end of the analysis. FeatureSampleSeries can materialize selected results back into the ordinary MIStudio data model, and that data can be fed to another FeatureExtractor or any other compatible Block.

Workbench-style analysis is often interactive. MIStudio supports that mode, but the same components can also be left running as part of an operational application.

For example, a power-quality application might:

1. Acquire a real-time waveform.
2. Divide it into analysis windows.
3. Run FeatureExtractor for each window.
4. Detect an anomaly using features or a comparison rule.
5. On detection, write the waveform to COMTRADE and store the event in a database.
6. Generate the relevant chart or disturbance view.
7. Send the event, features, and contextual knowledge to an LLM for interpretation.
8. Email or otherwise notify the responsible engineer.

The FeatureExtractor does not need to contain COMTRADE writing, database persistence, AI, or email logic. Each is a separate reusable component. The application is created by wiring them together.

MIStudio can expose analytical Blocks as tools to an AI model. The intended pattern is to keep measurement and feature computation deterministic while using the model for orchestration, contextual interpretation, explanation, and follow-up actions.

For example, an AI agent can identify the relevant tags and context, generate a FeatureExtractor request, run the deterministic extraction, evaluate a FeatureComparator result, retrieve related documents, and explain the likely cause of the observed change. This is an extension of the same component graph, not a separate copy of the process data.

• Start with the analytical question, not with finding a one-for-one replacement for every Seeq item.
• Use SQL when the database already knows the answer to the selection problem.
• Let FeatureExtractor define runs when grouping, gaps, or windows are sufficient.
• Use upstream preprocessing when the population requires richer temporal or domain logic.
• Keep the data reusable: a result displayed in a chart can usually be routed somewhere else at the same time.
• Prefer one general Block that solves a class of problems over a special-purpose Block for one analytical scenario.
• Use RequestCreator for common FeatureExtractor requests; use JSON when the analysis exceeds the convenience UI.
• Remember that analysis can be recursive: extracted features can become input data for another level of analysis.

A Seeq user already has most of the analytical instincts needed for MIStudio: select the relevant data, identify comparable process episodes, calculate meaningful metrics, compare current behavior with a reference, and visualize the result. The main change is architectural.

In MIStudio, the analysis is not the container for the dataflow. The analysis is one participant in the dataflow.

Signals can come from live equipment, databases, files, or earlier calculations. Process populations can be produced by SQL, filters, grouping, or preprocessing. FeatureExtractor characterizes runs. FeatureComparator measures drift. FeatureSampleSeries returns samples to ordinary MIStudio data for charts, tables, storage, or another analysis. The same graph can then persist evidence, ask an AI model for interpretation, or take an operational action.

For users accustomed to an interactive time-series analytics environment, MIStudio should therefore feel less like learning a different set of analytical mathematics and more like learning how those analytical operations fit into a broader, composable industrial application platform.

When recreating an existing Seeq analysis in MIStudio, this checklist helps keep the migration focused on the analytical intent rather than on reproducing every intermediate object.

• Once validated, consider which formerly interactive steps can become continuous workflows, including persistence, AI interpretation, and notification.
• Validate the MIStudio result against representative historical cases before enabling automated actions.
• Recreate only the intermediate objects that add reusable meaning; do not reproduce an intermediate Condition or calculation solely because it existed in the original worksheet.
• Choose the required outputs: feature table, relative-time overlay, comparison score, stored event, downstream feature stream, or another analytical pass.
• Decide whether the reference is a fixed run, a dynamically selected golden run, or a population of known-good runs.
• List the calculations that must be preserved and map them to existing Blocks, FeatureExtractor metrics, SQL, or scripts.
• Identify each population of runs or time intervals and decide whether SQL, grouping, contiguity, or upstream preprocessing is the simplest way to produce it.
• Identify the source signals, tables, events, and contextual fields actually used by the analysis.

Seeq terminology in this guide follows the current Seeq Knowledge Base descriptions of Signals, Samples, Conditions, Capsules, Formula, tables/charts, and Reference Profile. The MIStudio mappings are functional mappings intended to help with migration; they are not assertions that the two products use identical internal data models.