IoT Sensors in Machine Design: Adding Condition Monitoring Without Overengineering

Somewhere around my twelfth year designing production machinery, I noticed a pattern in how condition monitoring got specified on new equipment: either nobody thought about it until commissioning, when someone bolted on a vibration sensor as an afterthought, or someone went the opposite direction and specified a sensor for every bearing, shaft, and junction box on the machine because sensors had gotten cheap enough that it seemed harmless. Both approaches cause real problems down the line, just different ones. I have spent a fair amount of my career since then trying to find the middle path — designing condition monitoring into a machine from the concept stage, with enough sensing to catch the failure modes that actually matter, and not so much that the system drowns in data nobody looks at. This article is about how I approach that decision as a mechanical designer, not a controls engineer, because the mechanical design choices you make early on determine how much sensing actually helps later.

Start With Failure Modes, Not With a Sensor Catalog

The mistake I see most often, and the one I made myself early on, is starting the conversation with what sensors are available rather than what the machine is actually likely to fail from. A vibration sensor, a thermocouple, and a current clamp are each good at detecting specific failure signatures, and picking them without first doing a failure mode analysis tends to produce a sensor suite that misses the failures that actually happen in practice.

On a packaging line gearbox I designed condition monitoring for, I sat down with the maintenance team’s failure history before specifying a single sensor. Their records showed that over the previous five years, bearing failures accounted for the overwhelming majority of unplanned downtime on that gearbox family, with lubrication breakdown as the leading root cause. Knowing that, I specified a vibration sensor on each of the two main bearing housings and a temperature sensor on the oil sump, rather than the more generic instrumentation package the equipment vendor had originally proposed, which included an accelerometer on the housing exterior that would have been too far from the actual bearing races to catch an early-stage defect. Starting from the failure history instead of the vendor’s standard package changed which two sensors we actually needed and where exactly they needed to sit.

Sensor Placement Is a Mechanical Design Decision, Not an Afterthought

Where a sensor physically sits on a machine determines how useful its data will be, and that placement decision has to happen during mechanical design, not after the machine is built. I have seen too many cases where a vibration sensor gets mounted wherever there happened to be flat, accessible surface during commissioning, rather than where the vibration signature is actually strongest and cleanest.

On the same gearbox project, my first layout put the vibration sensor on the housing’s outer wall, about 150mm from the actual bearing, because that location was easy to access for maintenance and matched where I had seen sensors placed on similar machines before. When we brought in a vibration analysis specialist to review the design, she pointed out that the transmission path between the bearing and that mounting point ran through a bolted joint, which would attenuate and distort the exact frequency signatures we needed to detect early-stage bearing defects. I redesigned the housing to add a small machined boss directly over the bearing outer race, close enough that the sensor picked up a clean signal path with no bolted joint in between. That one change, decided at the mechanical design stage rather than left to whoever installed the sensor later, was the difference between data the specialist could actually use for defect detection and data that was borderline unusable.

Avoiding the Overengineering Trap

It is genuinely easy to over-instrument a machine now that MEMS sensors and wireless transmitters cost a few dollars each, and I have watched programs get seduced into sensing everything because the marginal cost per sensor looked trivial next to the value of avoiding a single unplanned shutdown. The actual cost of over-instrumentation is not the sensor hardware; it is the ongoing burden of managing, calibrating, and — most importantly — actually paying attention to all that data.

I was involved in a project where a client wanted vibration monitoring on every one of the forty-plus rotating shafts across a material handling line, essentially “just in case,” without any failure mode analysis behind the request. I pushed back and asked the maintenance team how many people would actually be reviewing forty-plus continuous data streams, and the honest answer was nobody had budgeted for that. We scaled the design down to the eight shafts with either a documented failure history or a safety-critical function, added simpler run-hour and temperature monitoring on the rest, and left clear provisions in the design — mounting bosses and cable routing — so additional sensors could be added later if a particular shaft started showing problems. That approach gave the client a monitoring system that people actually reviewed and trusted, instead of a wall of dashboards that would have been ignored within a month, which is exactly what happened on a comparable project I heard about from a colleague who was not able to talk his client out of the “sense everything” approach.

Power, Wiring, and the Physical Realities Sensors Bring to a Design

Every sensor you add to a machine design brings power and data routing requirements with it, and those requirements have real mechanical consequences — cable glands, junction boxes, conduit runs, and in the case of wireless sensors, battery access for replacement. I learned to treat these as first-class mechanical design constraints after a project where I had not.

On an early condition monitoring retrofit, I specified wired accelerometers on a rotating assembly without fully thinking through how the cable would route across a rotating-to-stationary interface. The result, once we got to commissioning, was a cable that had to cross a coupling guard in a way that fouled during machine operation within the first week, and we ended up having to switch to a wireless sensor and slip-ring-free design mid-project, which cost time and money that a better upfront layout would have avoided entirely. Now, whenever I specify a sensor, I trace its full cable or wireless path through the assembly during the CAD layout stage, checking for moving interfaces, thermal exposure, and maintenance access, before the sensor selection is considered final.

Choosing Between Wired and Wireless Sensing

The wired-versus-wireless decision comes up on nearly every condition monitoring design I do now, and I have stopped treating it as a simple cost comparison, because the operating environment usually makes the decision for you once you look closely enough.

On the packaging line gearbox, I ended up specifying wired sensors because the vibration data needed for early bearing defect detection required a continuous, high-fidelity signal that the wireless options available at the time could not reliably deliver at the sample rates we needed. On a separate project monitoring idler rollers spread across a 200-meter conveyor system, wireless was the obvious choice, since running conduit to forty individual roller locations would have been prohibitively expensive and the monitoring need there was closer to run-hours and basic temperature trending than high-frequency vibration analysis.

Getting the Threshold and Alert Logic Right During Design

Sensor selection and placement only solves half the problem; the other half is defining what values actually trigger an alert, and I have learned that this has to be worked out collaboratively with the maintenance and reliability team rather than set generically based on a vendor’s default thresholds.

On the gearbox project, the vendor’s default vibration alarm threshold was set conservatively low, generating alerts during entirely normal startup transients that had nothing to do with actual bearing degradation. Within the first month of operation, the maintenance team was getting multiple false alarms a week and had started ignoring the system, exactly the trust-erosion problem I described in more detail with digital twins elsewhere in my writing. We worked with the reliability engineer to set the threshold based on actual baseline data collected over several weeks of normal operation, with separate thresholds for steady-state running versus startup, and alert volume dropped to something the team could realistically respond to. Building that threshold logic properly took more calendar time than installing the sensors did, and I now budget for that time explicitly instead of treating threshold-setting as a quick afterthought at the end of commissioning.

What I Actually Recommend to Other Designers

If there is one habit I would pass on to another mechanical designer approaching condition monitoring for the first time, it is to resist the urge to let sensor availability drive the design. Start from documented or reasonably anticipated failure modes, place sensors where the physics of the failure mode actually puts the strongest signal, design the mechanical accommodations for cabling or wireless access as part of the core layout rather than as a retrofit, and get the alert thresholds tuned collaboratively with whoever has to act on the data. None of that requires expensive sensors or a large instrumentation budget. What it requires is treating condition monitoring as a mechanical design problem with its own failure modes, rather than an IT overlay bolted onto a finished machine, and in my experience that mindset shift produces better monitoring systems than any single sensor technology choice does on its own.