A vibration sensor sampling at 100 Hz. A temperature probe on a continuous line. A pressure transducer that never stops talking. Process data like this is everywhere on a modern plant floor, and almost none of it fits comfortably into a relational database one row at a time.
Most teams end up choosing between two bad options: store every raw sample and let the database grow out of control, or don't store it at all and lose the ability to analyze it later. Neither one is really a data strategy. It's a compromise forced by the shape of the data.
Kanoa MES 1.15 introduces a better option. Measures is a new feature included with Kanoa Ops that captures process measurements, aggregates them over a configurable window, and stores the statistical properties that actually matter—without requiring every raw sample to become its own database record.
Measures collects values from a data source—a PLC tag, an OPC value, or another connected input—over a window defined one of two ways:
When the window closes, Measures writes a single aggregated record: mean, standard deviation, minimum and maximum, sample count, and the window it represents. If a specification is linked, that record can also carry control limits and spec limits, along with a flag indicating whether the aggregated values fell outside of them.
The result is a measurement history that stays useful for trending, variation analysis, and process review, without turning every sensor into a firehose of raw rows.
It would have been easy to ship Measures as a bolt-on: a new table, a new screen, disconnected from everything else in Kanoa MES. That's not what happened, and that's worth calling out.
Measures links back to the same asset and item context that Kanoa Ops already establishes for work orders, downtime, and production events. A measurement isn't just a number—it's a number tied to an asset, in a window of time, in the middle of whatever else was happening on that line. That's the advantage of building on a foundation that already models the plant: adding a new kind of data doesn't mean starting over on context. It means connecting to context that already exists.
That's also why Measures could ship as part of Kanoa Ops rather than as a new licensed Solution. It extends the existing operational model instead of standing apart from it.
Once measurements are being captured, Kanoa Ops provides analysis views for:
None of this requires a separate historian project or a custom reporting build. It's part of the same Kanoa Ops experience teams already use for OEE, downtime, and production review.
Measures on its own captures and aggregates process data. Pair it with a Kanoa Quality license, and that aggregated data can also drive Statistical Process Control: control-limit evaluation against configured specifications, rule-based out-of-control detection, and centerlining against a linked quality attribute.
That's an important distinction to keep straight. Measures—the capture and aggregation of process data—is included with Kanoa Ops. SPC analysis on top of Measures requires Kanoa Quality. Teams evaluating Measures for SPC use cases should plan licensing around that boundary from the start.
If your team has been reaching for a custom historian integration, a side database, or a "we'll deal with it later" shrug every time a high-frequency sensor comes up in a project, Measures is worth a look before you build something bespoke. It's already part of Kanoa Ops as of Kanoa MES 1.15—no separate license, no separate module to configure—so it's available today in any environment already running Kanoa Ops on that version.
Configuration happens where you'd expect: define the measure, link it to an asset and a data source, choose the aggregation type, and—if SPC is in scope—link a quality attribute. From there, Kanoa MES handles the aggregation and the analysis views.
Measures shipped as part of Kanoa MES 1.15, included with Kanoa Ops. If your team is weighing how to handle high-frequency process data—or has been putting that decision off—this is a good time to take a look at what's already in the product you're running.