Skip to content
Field guide8 Curing Problems: How to Diagnose, Fix, and Prevent Them
Concept

Process Monitoring, Data Logging and Alarms

The sensors, observations, records, software, alarms and interlocks used to show whether a curing process remains within defined conditions and to trigger timely action when control is lost.

What monitoring means. Process monitoring is the planned observation or measurement of a control at a stated frequency. It shows whether an operation is being carried out within its defined conditions. In curing, monitoring may cover ingredient weights, product and room temperature, fermentation time and pH, chamber humidity, smoking or cooking schedules, cooling, water activity, mass loss, packaging and storage. The monitored variable must relate to the decision it controls.

Monitoring, verification and validation

Monitoring follows the process while it operates. Verification checks that the monitoring and wider control system are being implemented and remain effective. Validation supplies evidence that the control measure or process is capable of controlling the hazard. A continuous temperature chart is monitoring; comparison with an independent reference can be verification; scientific evidence supporting the required time and temperature is validation.

Manual and continuous systems

Manual monitoring uses an operator, instrument and record at specified times. Continuous monitoring uses a sensor and recording system to collect values automatically. Continuous data can reveal short excursions and cycles that periodic checks miss. Manual checks can confirm product condition, provide context and detect an automated sensor failure. The two approaches can support each other when their roles are defined.

The signal chain

A typical automated system consists of a sensor, cable or wireless link, transmitter, controller, data logger or software, display and stored record. A failure anywhere in that chain can alter or remove the result. A controller may continue using its local probe while the remote dashboard stops updating, or a display may show the last value after communication is lost. The system should identify stale, missing and invalid data rather than present them as current.

Choosing what to monitor

Monitor variables that show the control is operating and endpoints that show the required product change occurred. Chamber temperature and humidity describe the environment; pH, water activity, weight change and core temperature describe aspects of the product. Setpoint, output status and fan operation can help diagnose the system but are not substitutes for the measured condition. Avoid collecting data that no one reviews or can interpret.

Monitoring location

Sensor position defines the value. A probe beside a cold-air return, over a humidifier, against a wall or in an easy-to-reach product may not represent the least favourable condition. Commissioning and mapping should identify useful permanent positions. Product checks should follow a sampling plan that covers expected variability. Moving a fixed sensor requires documentation and may break comparison with earlier trends.

Frequency and sampling interval

Frequency should be sufficient to detect loss of control in time to act. A slow drying trend may be reviewed daily, while cooking or cooling can require much shorter intervals. Automated sample intervals should capture relevant cycling and events without obscuring the record in needless volume. Manual frequency should consider process speed, variability, operator workload and the maximum time product could remain outside control before detection.

Setpoints, operating limits and critical limits

A setpoint is the controller target. An operating limit or action limit gives an earlier warning that the process is moving away from the desired range. A critical limit separates acceptable from unacceptable control at a critical control point. These terms should not be used interchangeably. Control systems often cycle around a setpoint, so alarm and critical limits must be based on the actual process and measurement uncertainty, not placed arbitrarily close to the target.

Schedules and process recipes

Programmable controllers can store stages for fermentation, drying, smoking, cooking or cooling. Each recipe should identify the product, version, authorised settings and effective date. Copying a schedule from another product can be unsafe because diameter, formulation, load and required endpoint differ. Changes should be approved and linked to affected batches. Passwords or permissions should prevent casual editing of critical settings.

Data logging

A data logger records values with a time stamp. It may be built into equipment, connected to external sensors or used as an independent portable device. Important characteristics include range, accuracy, resolution, sample interval, memory, battery life, clock stability, environmental protection and export format. The logger should retain enough raw data to reconstruct the process and should not silently replace old records when memory is full.

Data integrity

A defensible record identifies the batch, date and time, instrument or sensor, units, actual value, operator or system, corrections and any later change. Original data should be preserved or reproducible as a true copy. Clock changes, unit conversions, sensor replacement, missing points and manual edits require control. A graph without the underlying values can conceal gaps; a spreadsheet without protected formulas can change results after release.

Alarm types

Alarms can be visual, audible, local, remote or recorded as events. They may respond to high or low values, rate of change, sensor failure, door opening, power loss, communication loss or prolonged deviation. A pre-alarm allows intervention before a process limit is crossed. Delays can prevent nuisance alarms during normal cycling, but an excessive delay can hide a meaningful excursion. The alarm rationale should be documented.

Alarm response

Every significant alarm needs a named response: acknowledge, investigate, restore control, identify affected product, record actual conditions, escalate and decide disposition. Acknowledging a notification only confirms that someone saw it. The response record should show what was found and done. Out-of-hours routing, contact failure and absence cover need planning. Repeated nuisance alarms should be corrected, not normalised.

Interlocks

An interlock prevents or stops an operation unless required conditions are present. Examples include preventing a cutter from running with a guard open, stopping a pump when a valve position is unsafe, or preventing a thermal programme from advancing without a required condition. Interlocks should move the system toward a safe state and should not be bypassed for convenience. Authorised overrides must be controlled, visible, time-limited where possible and reviewed.

Fail-safe design

A fail-safe response considers what happens when a sensor, relay, network, utility or power supply fails. Depending on the process, the safer action may be to stop heating, stop product feed, close a valve, hold a programme or activate an independent alarm. There is no single safe state for every chamber. Failure analysis should consider both food safety and machine safety and should avoid creating a second hazard through abrupt shutdown.

Testing alarms and interlocks

Challenge each function under controlled conditions before routine reliance and at a justified interval afterwards. Simulate high and low inputs, disconnect sensors where safe, test power and communication loss, confirm recipients and record response time. Testing only the indicator lamp does not prove the sensor, logic, notification and human response chain. Record failures and repairs and retest the affected function.

Remote monitoring

Remote dashboards and messages allow faster response when no one is beside the equipment. They introduce dependencies on power, batteries, gateways, internet service, cloud platforms, accounts and phone settings. Use local recording or control that survives network loss where the process requires it. Control access, preserve ownership of data exports and know what happens if the supplier service ends.

Trend review

Trends show cycling, drift, seasonal change and gradual loss of capacity. Review not only excursions but also longer compressor run times, increasing humidity recovery, changing pH rate, repeated door alarms or growing differences between sensors. Trend limits can prompt maintenance before failure. Compare product outcomes with environmental records so an apparently small equipment change is not ignored.

Excursions and product disposition

When a limit is crossed or data are missing, establish the time, magnitude, affected positions and product exposure. Restore control, but do not assume that restoration makes the batch acceptable. Evaluate the hazard using the validated process, other reliable measurements and competent technical evidence. Segregate affected product until a documented decision is made. Repeated excursions require corrective action on the cause.

Exception records

Some systems store only deviations and may be adequate where law and risk allow. Their weakness is that absence of an exception can be confused with loss of recording. Periodic proof-of-operation, sensor status and review are therefore important. For complex fermentation and drying work, full trend records often provide more useful evidence than a simple statement that no alarm occurred.

Review and release

A batch record should be reviewed for completeness, actual values, alarms, overrides, corrections, missing data and required endpoints before release. Automated pass indicators should be traceable to controlled logic and current specifications. The reviewer should be able to distinguish a process that remained in control from one that was corrected after an excursion but still requires product assessment.

Small-scale monitoring

A small producer can use independent min-max instruments or loggers, written batch sheets and timed checks. Record actual readings and actions, not only ticks. A second thermometer or reference check can reveal controller drift. If remote alarms are used, test delivery and maintain a plan for power or internet loss. The system can be simple, but the response to a failed chamber or missing endpoint must be decided in advance.

Common failures

Frequent failures include flat logger batteries, wrong time zones, full memory, disabled alarms, sensors moved during cleaning, copied records, unreviewed graphs, changed units, ignored overrides and systems that keep displaying the last good value. Human factors matter: an alarm threshold that produces constant nuisance messages teaches people to ignore it. Good monitoring is designed for reliable action, not maximum data volume.

What monitoring can prove. Monitoring can show the conditions measured at the stated locations and times. It cannot by itself prove that every position was identical, that the sensor was accurate, that the product achieved an unmeasured endpoint or that the process was scientifically adequate. Those conclusions require mapping, calibration, representative sampling, verification and validation.

Related in the Codex

References