Your plant historian probably contains more useful questions than anyone has had time to ask. Years of pressures, temperatures, speeds, states, alarms, laboratory results, production counts, and meter readings may already cover the problem that prompted the latest improvement meeting. The opportunity is not to buy a larger analytics platform first. It is to frame one operational question, extract a defensible comparison set, and keep the limits of the evidence visible.
Wayne Matthews describes modern historians as access points for process, alarm, asset, production, and consumption analysis, not merely archives for drawing trends. ISA on process historians Our editorial inference is that this breadth is useful only when plant context travels with the values. The five analyses below can start with tools most engineers already use. Each names the data, method, question, and boundary.
Prepare a comparison set before choosing a chart
A quick export can create a convincing chart and a weak conclusion. Before analysis, define the asset, product or recipe, operating state, time window, and decision owner. Then inspect tag units, sampling mode, missing periods, manual entries, sensor changes, clock shifts, and maintenance windows. If the historian compresses values, record that too. A trend built from exception-based samples behaves differently from one built from fixed intervals.
Start with one narrow table. Put timestamp, asset ID, process state, product or grade, batch or order, shift, and the measurements needed for the question in separate columns. Add event markers for startup, shutdown, cleaning, changeover, maintenance events, and quality holds. Matthews notes that current historians may receive records from control, laboratory, ERP, and asset systems through open interfaces; the engineer still has to preserve which system supplied each field. ISA on historian inputs
Use the historian trend client for visual inspection and SQL for repeatable extraction. A spreadsheet works for filtering, pivots, scatterplots, and small control charts. Python or Jupyter helps when joins or models must be rerun. Use BI after the method is stable.
The first check is comparability. NIST’s guidance on process comparisons explains that statistical tests and confidence intervals support decisions about processes, while its assumptions page warns that common tests may depend on one distribution, normality, and observations that are not correlated over time. NIST comparisons NIST assumptions Historian points are often autocorrelated and operating modes are mixed, so a default t-test may answer a question the plant never asked.
Write the question before opening the chart: “For Pump P-204 during steady production of Grade A, did discharge pressure behavior change after the July intervention?” That fixes the population, state, product, event, and comparison. Keep the raw extract read-only, store query logic, and save a data dictionary beside the result.
Find degradation trends before they become failures
Degradation analysis looks for a sustained change in a condition indicator while the equipment performs comparable work. Useful data can include vibration summary values, bearing temperature, valve travel time, motor current, differential pressure, cycle duration, controller output, throughput, and maintenance timestamps. Product grade, ambient conditions, load, and operating state belong in the extract because they can move the same signal without indicating damage.
Overlay comparable production windows in the historian client and mark interventions. Calculate a daily or per-cycle median rather than treating every scan as independent. Plot it with a rolling median or exponentially weighted moving average. NIST describes control charts as time-ordered displays with a center line and limits; points inside limits can still form a nonrandom pattern. NIST control charts The chart screens; it does not diagnose.
It answers: “Has this indicator shifted under comparable conditions, and when did the change begin?” Rising valve travel time after the same command can justify inspecting friction, air supply, positioner behavior, or mechanical condition. It cannot identify the mechanism. A temperature trend can prompt a lubrication check; it cannot calculate remaining useful life without a separately validated prognostic model.
Use maintenance records to test the story. Does the signal reset after an intervention? Does it worsen only at high load? Is the apparent drift a sensor replacement, calibration change, or tag scaling edit? Historian systems can combine process and asset information for diagnostic work, but their availability does not remove the need to understand the equipment and records. ISA on process and asset analysis NIST also ties out-of-control findings to investigation for an assignable cause rather than treating the chart as the cause itself. NIST control-chart interpretation
A sound output contains the indicator, state filter, baseline, method, first sustained deviation, maintenance history, and missing evidence. Send it to the equipment owner with a specific inspection question. The record may support inspection; it does not predict failure, authorize setpoint changes, or replace asset condition monitoring.
Connect process parameters with product quality
This analysis joins process history to a quality response at the correct production unit. You need a trustworthy batch, roll, pallet, campaign, or time-window key; process values aligned to the material’s residence time; recipe and grade; laboratory or inspection result; equipment state; rework status; and relevant raw-material or environmental fields. A timestamp-only join is risky when material spends time in tanks, ovens, queues, or recirculation loops.
Start with engineering logic, not a correlation matrix. Choose a response such as moisture, viscosity, thickness, yield, or defect rate. Calculate plausible process features for each production unit: mean, range, time above a limit, ramp rate, dwell time, or phase variability. Plot the response against each feature and separate products and operating modes. Use SQL plus Python when joins must be audited.
NIST distinguishes correlation, where variables move together, from causality, where changing one variable causes a change in another. It states plainly that correlation does not imply causality and recommends designed experiments when the goal is to establish causal relationships. NIST experimental design NIST’s comparison guidance also puts assumptions and confidence intervals ahead of casual interpretation. NIST process comparisons
This asks: “Which recorded process conditions are associated with a better or worse quality response within comparable production?” The result narrows an investigation. Off-spec moisture may cluster with longer hold times in one recipe. That does not prove that changing hold time will improve quality. Product mix, material, sampling, season, or hidden control action may drive both variables.
Treat the result as a hypothesis. Check sensor validity, join logic, measurement timing, omitted variables, and whether the relationship persists in another period. If a control change could affect safety, quality, or validated operation, follow change control and use an approved trial or experiment. The quality deviation evidence workflow keeps the boundary clear: historian evidence supports triage; accountable roles decide containment and change.
Report data lineage, the overall association, and splits by product, equipment, and state. A relationship that disappears after stratification was probably confounded. A repeating relationship remains a candidate, not a verdict.
Rank alarm activity without rationalizing by spreadsheet
Alarm analysis needs the event journal, not only a count exported from a dashboard. Collect alarm tag, message, priority, activation and return times, acknowledgement time, suppression or shelving state, equipment, area, operator station, and process mode. Preserve duplicate events and chattering behavior until the analysis explicitly classifies them. Add production states such as startup, shutdown, cleaning, grade change, and idle because expected alarm activity can differ sharply between modes.
Build a Pareto by occurrence count, then add duration, standing time, acknowledgement behavior, and hourly distribution. Slice the results by equipment and operating mode. The ISA-18 series describes alarm management as a lifecycle that includes philosophy, identification, rationalization, implementation, maintenance, monitoring, and change management. Its monitoring guidance names alarm rates, standing alarms, and response times as performance measures. ISA-18 alarm lifecycle
The historian article gives a practical example: shift reports can include standing alarms, top alarms by occurrence, suppressed alarms, mean rates, and hourly distributions, with drill-down to raw events around an incident. ISA historian alarm analysis Those views answer: “Which alarms consume attention, persist, or cluster on specific equipment and operating modes?” They help select candidates for engineering review.
They do not authorize removal, suppression, shelving, priority changes, or limit changes. A frequent alarm may reflect configuration, a recurring upset, a failed instrument, a procedure problem, or a safeguard working as intended. Frequency cannot distinguish those cases. ISA places identification and rationalization inside a documented lifecycle covering need, justification, priority, classification, and operating context. ISA-18 identification and rationalization
Send the top candidates to a multidisciplinary review with the alarm philosophy, cause, consequence, operator action, response time, and state logic available. The alarm management evidence guide shows how to preserve that boundary. A good weekly output names the dominant contributors, their mode dependence, and the next evidence check. It never turns “top ten” into “delete ten.”
Compare shifts without turning data into a league table
Shift comparison is useful when it reveals a process or support-system difference that the plant can act on. It becomes misleading when shift label substitutes for operating context or individual performance. Collect good count, scrap and rework, planned rate, runtime, unplanned stops, product mix, recipe, campaign length, staffing level where permitted, changeovers, material holds, maintenance windows, and environmental conditions. Aggregate to a level that protects individuals and fits local labor, privacy, and works-council requirements.
Define the denominator first. Units per scheduled hour, units per runtime hour, first-pass yield, stop minutes per running hour, and energy per good unit answer different questions. Stratify by product, line, and state; compare medians and distributions. NIST frames process comparison through tests and confidence intervals, requiring uncertainty rather than ranking small differences as facts. NIST comparisons
Check the assumptions. Closely spaced production observations are often correlated over time, and a mixed population may not follow one normal distribution. NIST recommends examining distribution shape and time correlation before applying tests that rely on those assumptions. NIST statistical assumptions A box plot by shift and product is often more honest than a single percentage with two decimal places.
It asks: “After normalizing for product, line state, and opportunity time, where does performance differ enough to investigate the work system?” A gap might point to changeover sequencing, maintenance access, material timing, startup conditions, or standard work. It must not become a scorecard for named operators. Shift is a grouping variable, not an explanation.
Review results with shift representatives before assigning cause. Ask whether reason codes are consistent, one shift inherits more startups, or maintenance events are recorded differently. Historian benchmarking can compare real records across units; we infer that such comparisons require definitions and operational context. ISA historian benchmarking
Publish the normalized comparison, known imbalances, and one process question. If the gap remains, observe the work and test the suspected mechanism before assigning action.
Detect energy anomalies in the operating state that created them
An energy anomaly is a measured departure from expected consumption under comparable conditions. Collect interval electricity, gas, steam, compressed-air, water, or fuel data at the finest useful meter boundary. Join it to production quantity, good output, product mix, equipment state, runtime, weather where relevant, cleaning, startup, shutdown, and maintenance events. Align meter and production intervals; energy for one hour cannot be divided by output from another.
Choose an energy performance indicator that fits the process. DOE defines EnPIs as measured values, ratios, or models and says energy intensity divides consumption by productive output over the same period. DOE energy metrics Kilowatt-hours per good unit works when output explains most variation. Otherwise, use a regression baseline or separate state models.
Calculate expected consumption for each interval, then plot residuals: actual minus expected. Use a control chart or EWMA to screen sustained shifts rather than chasing every spike. DOE recommends comparing actual and expected consumption, monitoring relevant variables, and evaluating data under consistent operating conditions. DOE monitoring and analysis NIST warns that chart limits and distribution assumptions affect false investigation risk, so thresholds should reflect the process and cost of a missed or false signal. NIST control charts
It asks: “When did this system consume materially more or less energy than its baseline predicts for the same work and state?” A positive residual during idle may point to loaded equipment. A sustained shift after a maintenance event may justify checking controls or measurement. Normalization can expose a change hidden by lower total consumption.
The anomaly does not prove waste or savings. Meter error, product mix, necessary cleaning, weather, startup, timing, or a changed boundary may explain it. DOE says finer metering can reveal deviations earlier, while consistent conditions and representative baselines support reliable evaluation. DOE energy monitoring Use the industrial energy evidence guide before claiming a benefit.
Frequently asked questions
Do I need a data science platform to start?
No. A historian trend client, SQL export, or spreadsheet is enough for a well-bounded first analysis. Python becomes useful when joins, feature calculations, or models must be rerun reliably. Preserve the query, filters, definitions, and source fields for reuse.
Start with a question whose answer can change one inspection or review. A polished dashboard is unnecessary at this stage. Repeatability and a clear evidence boundary are enough.
How much historian data should I export?
Use enough data to include comparable operating cycles, seasonal effects, maintenance events, and known good periods. There is no universal number of days. Start with the physical process and the question, then check whether the window contains enough comparable observations and whether control or sensor changes split the record.
If the process has rare modes, extend the window rather than mixing unlike states. Record retention and sampling changes before treating older and newer data as one population.
Can a correlation prove the root cause of a quality problem?
No. Correlation identifies a relationship worth investigating; it does not establish that one variable caused the other. NIST separates correlation from causality and points to engineering judgment and designed experiments for causal work. NIST experimental design
Should the most frequent alarm be removed?
No. Frequency is a screening signal, not authority to suppress, reprioritize, or remove an alarm. Review its documented purpose, consequence, operator action, operating state, priority, and lifecycle requirements before any change. ISA-18
What should I do with a detected anomaly?
Open a bounded engineering review that checks data quality, operating context, and the relevant plant procedure before changing the process. Assign an owner, preserve the extract and method, record alternative explanations, and define what observation would confirm or reject the hypothesis.
Close the review with the decision, evidence used, unresolved uncertainty, and any follow-up measurement. That record makes the next anomaly easier to assess.
Begin with a question tied to a decision, keep the extract and method reproducible, and ask the responsible engineer to review the result in context. One useful analysis completed this week is worth more than a broad dashboard nobody can defend.
Sources
- NIST: Experiments and Experimental Design
- NIST: What are Control Charts?
- NIST: Product and Process Comparisons
- NIST: Statistical Assumptions
- DOE: Determine Performance Metrics
- DOE: Measure, Monitor and Analyze Performance Metrics
- ISA: ISA-18 Series of Standards
- ISA InTech: New Roles for Process Historians