Machine Condition Monitoring & Automated Inspection

What do you cover under machine condition monitoring?

Machine condition monitoring and automated inspection are engineered into the machine or the product.

That means multi-channel acquisition, on-machine signal processing, and a transport design to filter and send the essential data upstream for analysis. As an example, our team has built acquisition and transport designs correlating piezo vibration, current and temperature at the drive and fan ends sub-second at the controller, and line-scan inspection systems classifying a moulded consumer product at production rate. Condition monitoring and in-line inspection are two disciplines, and they sit on one page because our engineering underneath both is shared: sensing choice, sample rate, correlation, and what leaves the machine. Monitoring watches the machine’s own health over time. Inspection judges each part the machine produces. The engagement is usually one of these shapes:

• A readiness assessment. A predictive maintenance readiness assessment or machine health assessment and audit that states what the machines can already support, including when the answer is “not much yet”.
• The acquisition layer. Multi-channel data acquisition with sensor placement, sample rate and channel correlation designed around the fault.
• On-machine processing. Vibration analysis for predictive maintenance and motor current signature analysis run at the machine, so a developing fault shows in a trend held locally instead of waiting for the next bulk upload.
• Data reduction and transport. What is kept at full rate, what is aggregated, what is sent upstream, and over which transport.
• An in-line inspection system. Automated optical inspection integration, from image acquisition on the line’s own camera stack through to classification at line rate.
• An online condition monitoring system, end to end, built inside the machine, including the third-party sensing units, gateways and analytics backends it has to work with. Note that we do not sell an off-the-shelf monitoring product.

Four decisions sit behind all of them, and they are taken in this order:

1. Which fault you are trying to catch.
2. Where you have to sense to see it.
3. How fast you have to sample before it becomes invisible.
4. What analysis runs on the result.

Most projects start at the last one, but it needs the insight generated from the previous three steps. A model cannot recover information that was never sampled. The sample rate follows from the fault’s P-F interval: the time between the point where the fault becomes detectable and the point where the machine fails. A rate chosen to suit a historian’s ingest budget can miss that interval entirely, and the dataset then holds no trace of the fault. Most of the value we add is upstream of the analytics, in the acquisition and transport design.

We do not instrument plants or commission machines. The monitoring layer inside your machine or your product is ours to design and build, and we integrate and test it with your engineers, onshore while that phase is running and remotely afterwards.

Can the sampling and data-reduction design be changed after deployment?

The sampling design can be revisited, but the data-reduction half of it is irreversible.

Once a machine has aggregated a signal to a one-minute average and discarded the rest, the transient that was the early warning is gone. The data-reduction decision is a design commitment, and it is made per signal, not per system. Some channels justify full-rate capture and a fast transport, and most do not. In practice the bands fall out at roughly 100 ms, 40 ms, 10 ms and 1 ms depending on what the signal is for, and the transport selection follows from the band:

Those paths are established in the readiness assessment, before anything is committed, because they decide what the backend can be asked to do afterwards. That is where this work meets OPC UA modelling above it and real-time Ethernet beneath it.

Who chooses the historian or analytics backend?

You do, or your data platform does.

We design the acquisition and transport layer to feed a historian, an MES or a named analytics backend, and we treat that target as given. Selecting and operating it is a platform decision with its own procurement. Where a controller exposes what is needed, the acquisition layer works across PLC brands, because it runs over standard paths and not through vendor-specific tooling.

Where does in-line inspection differ from condition monitoring?

The measurement is an image, and the judgement is per part instead of per trend.

• Image processing first. Most in-line inspection is image processing. The camera vendor supplies an SDK and an imaging stack, usually OpenCV-based, and thresholding, morphology and dimensional checks on that stack resolve the majority of defect classes without any model at all. That is the first thing we try, because it is faster to build, cheaper to run and easier for a quality team to explain.
• A trained classifier second. It goes in where image processing cannot separate the classes: variable, natural or textural defects where the rule is not expressible as a threshold. When that step is needed we train the model against your labelled examples, and we benchmark the architecture against the number of examples it needs. A heavier model that classifies marginally better but needs several times the labelled examples is the wrong choice for a deployment that has to produce those examples on a running line. As an example, our team has built a line-scan inspection system for a moulded consumer product, separating correctly formed units from partially formed, empty and incomplete ones.

What happens to an inspection model when the product changes?

It gets retrained, and we design for that from the start.

A product change, a lighting change or a line-rate change can all move a classifier’s accuracy, and on a running line at least one of the three will happen. The same benchmarking process runs again against fresh labelled examples, so the model size sets the number of training iterations and the cost of each round of change. Your team is typically the one producing those examples on a running line, and once the architecture is established the retraining can be done by the same team.