Skip to main content
Question

How to identify process cycles?

  • June 14, 2026
  • 1 reply
  • 10 views

I am working with a cooking process where the sequence generally consists of:

  • Steam valve opens

  • Temperature rises

  • Product cooks

  • Cooling starts

  • Transfer valve opens

  • Product transfer completes

I would like to automatically identify every complete cooking cycle over several months of historical data.

Currently I can identify individual events using tag values, but I am interested in understanding the most robust TrendMiner approach for detecting complete cooking cycles and creating a reusable context for future analysis.

Would you use Value Based Search, ContextHub, Event Analytics, or another method?

How would you structure the logic to reliably identify the start and end of each cooking cycle?

1 reply

Forum|alt.badge.img
  • Employee
  • June 18, 2026

Hi ​@TIM,

Value-Based Search, Event Analytics and ContextHub aren't alternatives here; they're a pipeline, and you'll want all three. VBS detects the cycles, Event Analytics measures them, and ContextHub persists them as the reusable, queryable record you're after. Get the detection step solid and everything downstream (comparison, deviation, stage delays, similarity) reads from one canonical cycle list.

 

Detecting the cycles. The robust start/end logic hinges on a single tag that's true for the entire cycle. Your best anchor is the recipe/step tag, because it's the process's own definition of the cycle rather than something inferred from physical signals far less brittle. The cleanest route is a binary formula tag spanning the recipe:

CycleActive = if(and(StepNo >= <first step>, StepNo <= <last step>), 1, 0)

then VBS on CycleActive = 1. If your cycle is bounded by discrete signals instead of a step number steam valve opens through transfer complete you can compose the same idea with or() across the phase flags, or latch on the start signal. If you'd rather not build a tag at all, condition = Constant on the step tag also segments each contiguous block cleanly (Constant pattern).

Set a minimum-duration cut on the VBS so aborted or partial runs don't show up as "cycles" pick something comfortably below your shortest real cycle but above the noise. 

 

Measuring them. Open Event Analytics on the result list and add per-cycle calculations duration, peak temperature, avg steam pressure, Δ level, whatever you'll want later. You can attach up to 30, and building them now means they travel with the saved search. This is also where you sanity-check the detection: if the duration histogram has a junk cluster near zero, your duration cut needs raising.

 

Persisting them the reusable part. Create context items from the search results: a custom type like "Cooking Cycle" on the cooker component, and toggle "map to fields" so your Event Analytics KPIs land as sortable, filterable columns rather than evaporating (mapping calcs to context fields). In ContextHub, the Gantt view is excellent for eyeballing cycle cadence and spotting overlaps or gaps across runs most people stay in the Table view and never find it (context-item types & views).

One admin note: custom context types are created by an Application Admin (the gear menu, bottom-left), so you may need to request "Cooking Cycle" rather than self-serve it. Worth doing a specific type stays useful for filtering, where the generic pre-loaded types turn into noise at scale.

Kind regards
Frederik