Harsh Joshi
Co-founder & Technical Director
Predictive maintenance starts on the drawing, not the dashboard. How OEMs design sensors, connectivity, and data paths into machinery before design freeze.
IoT in mechanical engineering connects physical machinery with sensors, embedded computing, connectivity, and software so manufacturers can monitor equipment and support predictive maintenance.
Consider what happens without it. An OEM sells a machine, ships it, and then hears nothing until a customer calls with a failure. The service team drives out, diagnoses the problem on site, orders a part, and comes back a week later. Nobody in the engineering team knows what the machine was doing in the hours before it stopped.
That gap is the practical reason IoT in mechanical engineering has moved from a nice-to-have to a design requirement. When sensing and connectivity decisions are made during the mechanical design phase instead of afterwards, the result is a machine that supports predictive maintenance, remote diagnostics, and service contracts as a native capability.
Most content on this subject falls into one of two camps. Hardware articles describe better mechanical design. Software articles describe dashboards and analytics. The harder question sits between them: what does a mechanical engineering team actually have to change in a machine's design so that predictive maintenance works once the machine is in the field? That is what this article covers, along with the decisions, trade-offs, and mistakes that shape whether the data turns out to be useful.
IoT vs IIoT in Mechanical Engineering
IoT is a broad term for connected physical devices. Industrial IoT (IIoT) applies the same connected-device principles to industrial machinery, production equipment, and operational processes, where reliability, uptime, safety, and integration with plant systems are especially important.
In mechanical engineering, the distinction matters because an IIoT-enabled machine has to work within real industrial constraints: vibration, temperature, ingress protection, plant networks, maintenance workflows, and service lives measured in decades rather than years.
What Predictive Maintenance Requires From the Machine Itself
Predictive maintenance uses live equipment data to estimate when a component is likely to fail, so that service happens before the failure instead of after it. It sits between two older approaches: reactive maintenance, which fixes things after a breakdown, and preventive maintenance, which services parts on a fixed calendar or run-hour schedule whether they need it or not.
The prediction is only as good as the signal, and the signal comes from the machine. That is the part mechanical teams own. A vibration sensor bolted onto a painted sheet metal cover will not tell you much about a bearing three castings away. A temperature probe reading ambient air inside an enclosure will not tell you a gearbox is running hot. Getting a usable signal is a mechanical design problem before it is a data science problem, which is why embedded systems and IoT engineering belongs in the design review rather than in a later phase.
Four things have to be designed in, not added later:
- A sensing location that reflects the failure mode. The sensor needs a rigid, direct mechanical path to the component you care about.
- Physical provision for the hardware. Mounting bosses, tapped holes, cable routes, connector cutouts, and service access all consume space in the assembly.
- Power and thermal budget. Sensors, a controller, and a radio all draw current and produce heat inside an enclosure that was sized before anyone mentioned telemetry.
- Environmental protection. Adding a connector or antenna window to an IP65 enclosure changes the sealing design and the environmental test plan.
Why Retrofitting Telemetry Costs More Than Designing It In
Clamp-on sensor kits exist, and for an installed base they are often the only option. For a new machine program, retrofitting is usually the more expensive route once the whole picture is counted.
A retrofit tends to accept whatever mounting surface is available, so the signal is noisier and the analytics need more filtering and more data to reach the same confidence. It adds external boxes, external cabling, and external failure points that a service technician now has to maintain. It frequently reopens the compliance file, because a bolt-on radio changes the EMC profile and, in regulated equipment, may require the safety case to be revisited. And it is a per-unit cost applied one machine at a time rather than a design cost amortized across a production run.
Designing sensing into the machine turns the same functionality into a small number of features on drawings that were being produced anyway: a machined boss, a routed cable channel, a sealed connector, a slightly larger control enclosure.
Choosing What to Measure: Start From the Failure Modes
The most common mistake in smart machinery design is instrumenting whatever is easy to instrument and hoping the data proves useful later. Fleets of machines end up streaming temperature readings that nobody has ever used to make a decision.
A better starting point is a failure mode analysis your team probably already has. For each significant failure mode, ask three questions: what physical change happens before this failure, can that change be measured from outside the failing component, and what would we actually do differently if we saw it. If the third question has no answer, that measurement is not worth its cost.
| Failure Mode | Useful Measurement | Mechanical Design Implication |
|---|---|---|
| Bearing wear, imbalance, misalignment | Vibration (accelerometer) | Rigid mounting pad near the bearing housing, defined orientation, short cable run |
| Overheating in gearboxes, motors, hydraulics | Temperature (thermocouple, RTD, thermistor) | Probe pocket or contact point on the actual heat path, not ambient enclosure air |
| Motor degradation and mechanical load change | Motor current signature | Current sensing in the drive or control cabinet, plus space for the sensing hardware |
| Seal, valve, or filter degradation | Pressure or differential pressure | Port location, fitting, and access for calibration or replacement |
| Cavitation, gear or valve defects | Acoustic or ultrasonic | Sensor placement away from dominant noise sources, acoustic path considered |
| Duty cycle and utilization tracking | Run hours, cycle counts, load profile | Usually available from the controller with minimal added hardware |
Cycle counts and duty-cycle data deserve a specific mention. They are cheap to capture, they need no extra sensor in most machines, and they are often the single most useful input for warranty analysis and service planning, because they tell you how hard each unit in the field is actually being worked.
Edge or Cloud: Where the Processing Should Happen
Once a machine produces data, someone has to decide where it gets interpreted. This choice affects the bill of materials, the connectivity plan, and the recurring cost of the product for years.
| Approach | What It Does | Best For | Main Trade-Off |
|---|---|---|---|
| On-device (edge) processing | Analyzes signals locally and transmits results or alerts only | High-frequency data such as vibration, poor or costly connectivity, latency-sensitive responses | More capable and more expensive hardware; harder to change the logic after shipping |
| Cloud processing | Streams raw or lightly processed data to a platform for analysis | Fleet-wide analytics, model retraining, cross-customer comparison | Bandwidth and recurring platform cost, dependence on the customer's network |
| Hybrid | Edge extracts features, cloud handles trending and modeling | Most industrial machinery programs | Requires clear design agreement on what happens where |
Raw vibration data illustrates why this matters. Sampling an accelerometer at a rate high enough to see bearing defect frequencies produces far more data than most industrial connections can carry continuously. Extracting the features on the device and sending a small summary is usually the only practical option. That decision then feeds back into hardware selection, which is why edge and cloud architecture should be settled early rather than after the enclosure is fixed.
Connectivity has a similar effect on the mechanical design. A machine on a factory network may use Ethernet with a protocol such as OPC UA or Modbus TCP. Mobile or remote equipment may need cellular, LTE-M, NB-IoT, or LoRaWAN, each with implications for antenna placement, enclosure material, and where metal panels can sit. An antenna behind a steel cover is a design problem that is far easier to solve on a model than on a finished machine.
Turning Sensor Data Into a Maintenance Decision
A predictive maintenance system is not one thing. The widely used reference model for this is ISO 13374, which describes condition monitoring and diagnostics as a sequence of functional blocks: acquiring data, manipulating it into useful features, detecting an abnormal state, assessing machine health, generating a prognosis, and finally producing an advisory that a person or system can act on. The companion standard, ISO 17359, covers how to set up a condition monitoring program in the first place.
The practical value of that model is that it shows how many steps sit between a sensor and a service decision, and how many of them are software rather than hardware. Most stalled projects fail somewhere in the last two blocks. The machine is instrumented, the data is arriving, and nobody has built the part that turns a health score into a work order in the customer's maintenance system. Connecting device data to the applications where maintenance decisions are actually made is digital engineering work, and it needs an owner from the start of the program.
Prediction quality also depends on something no architecture diagram shows: labelled failure data. A model that estimates remaining useful life needs examples of machines that degraded and failed, with the failure recorded and matched to the sensor history. Early in a product's life, that data does not exist yet. Realistic programs begin with threshold alarms and trend monitoring, then move toward prediction as the fleet accumulates history. Promising customers accurate failure forecasting at launch is a commitment most new smart machinery programs cannot keep.
A Practical IoT Architecture for Mechanical Machinery
A connected machine typically follows one chain: failure mode, then measurement, then sensor, then edge controller, then connectivity, then cloud or local analytics, then maintenance decision. Designing that chain as a whole, rather than one link at a time, is what stops a team from collecting data that cannot support a useful action.
The Business Case Behind Smart Machinery
For an OEM, the reason to embed telemetry is rarely the maintenance feature by itself. It is what the data makes possible commercially.
Service economics improve first. Remote diagnosis means a technician arrives knowing which part is likely at fault and carrying it, instead of making a diagnostic visit followed by a repair visit. Warranty analysis improves next, because engineering can see how failed units were actually operated, which separates genuine design weaknesses from misuse or unusual duty cycles. That feedback loop is one of the strongest long-term arguments for connectivity, and it flows straight back into the next product engineering cycle.
Connected machines also make new commercial models possible. Equipment as a service, where a customer pays for availability, output, or usage rather than buying the machine outright, depends entirely on the manufacturer being able to measure usage and manage uptime remotely. Without embedded telemetry, that model has no basis for billing and no way to control the risk the manufacturer has taken on.
These benefits carry real costs, and an honest business case should state them: added bill of materials cost per unit, recurring connectivity and platform fees, cybersecurity obligations that continue for the life of the product, and the need to support over-the-air updates for devices in the field for a decade or more. A machine with a network connection is a machine that will eventually need a security patch, which means secure boot, signed firmware, and an update path have to be part of the original architecture.
Where Smart Machinery Programs Usually Go Wrong
A few patterns show up repeatedly:
- Treating telemetry as a late-stage addition. By the time the enclosure and castings are frozen, the good sensing locations are gone and the team is left with compromises.
- Collecting data with no defined decision. If no one can name the action a measurement will trigger, the measurement is cost without benefit.
- Ignoring the customer's IT reality. Plant networks have firewalls, security policies, and IT owners. A machine that assumes open outbound internet access will not connect on many sites.
- Underestimating the software half. Hardware teams often scope the sensors and the firmware accurately and then discover the cloud platform, device management, and integration work is the larger effort.
- Skipping the field validation of the sensing itself. Sensor placement that looks correct in CAD can sit on a resonance or read the wrong thermal path. Validate on a real machine under real load before committing to production tooling.
- Leaving security until later. Retrofitting secure boot and encrypted communication into a shipped product is far harder than designing them in.
A Practical Checklist Before Design Freeze
Run through these questions before the mechanical design is locked:
- Which failure modes are we trying to detect, and what would we do differently if we detected them early?
- Does each sensor have a mechanically sound location with a direct path to what it measures?
- Have mounting features, cable routing, connectors, and service access been added to the CAD model?
- What is the power budget, and does the enclosure still meet its thermal and IP requirements with the electronics inside?
- What is processed on the device and what goes to the cloud, and does the hardware selection match that split?
- Which connectivity option suits the machine's installed environment, and where does the antenna go?
- How does an alert reach the person or system that schedules maintenance?
- How will firmware be updated securely once machines are in the field?
- Who owns the data, the customer or the manufacturer, and is that agreed contractually?
- What does the recurring cost per machine per year look like, and who pays it?
Questions nine and ten catch teams out more often than the technical ones. Data ownership in industrial equipment is frequently unresolved until a customer raises it during procurement, and a recurring cost with no owner tends to become the manufacturer's cost by default.
Building Machinery That Can Report Its Own Condition
Predictive maintenance is not something a machine acquires after it ships. It is a set of mechanical, electrical, firmware, and software decisions that are cheapest and most effective when they are made together, while the design is still on screen. The teams that get value from IoT in mechanical engineering are the ones that start from a specific failure mode and a specific service decision, then work backwards to the sensor, the enclosure, and the data path.
Monarch Innovation works across both halves of this problem, combining mechanical product engineering with embedded firmware, PCB design, industrial connectivity, edge intelligence, and cloud integration in one team, so sensing decisions and software decisions are made in the same room rather than handed between vendors. If you are planning a new machine program or a smart product upgrade, contact Monarch Innovation to discuss your architecture before the design is frozen.
Talk to Our Digital Engineering Team About Smart Product Architecture
Planning a connected machine or adding condition monitoring to an existing product line? Contact Monarch Innovation to discuss sensor strategy, edge and cloud architecture, connectivity, and how the data will reach your service team.
Frequently Asked Questions About IoT in Mechanical Engineering
What is IoT in mechanical engineering?
IoT in mechanical engineering is the practice of embedding sensors, connectivity, and processing into physical machines so equipment reports its own operating condition. It brings mechanical design together with electronics, firmware, and software, allowing manufacturers to support remote monitoring, predictive maintenance, and data-driven product improvement across a fleet of machines.
Why should telemetry be designed in rather than retrofitted?
Designing sensing into a machine gives cleaner signals, fewer external failure points, and lower per-unit cost, because mounting features and cable routes become ordinary drawing details. Retrofits accept whatever mounting surface exists, add external hardware, and can reopen EMC and safety documentation, which usually makes them more expensive over a production run.
Which sensors are used for predictive maintenance on industrial machines?
Vibration accelerometers detect bearing wear, imbalance, and misalignment. Temperature sensors track thermal problems in motors, gearboxes, and hydraulics. Motor current sensing reveals load changes and degradation. Pressure sensors monitor seals, valves, and filters. Run hours and cycle counts from the controller are often the cheapest and most useful data of all.
Should predictive maintenance data be processed at the edge or in the cloud?
Most machinery programs use both. High-frequency signals such as vibration are usually processed on the device, because streaming raw data continuously is impractical. Fleet-wide trending, comparison, and model development happen in the cloud. The split should be decided early, since it determines hardware selection and enclosure requirements.
Does predictive maintenance work as soon as a machine ships?
Rarely. Accurate failure prediction needs historical examples of machines that degraded and failed, matched to their sensor data. New products start with threshold alarms and trend monitoring, then move toward prediction as fleet history builds. Manufacturers should avoid promising precise failure forecasting at product launch.
How does connected machinery support equipment as a service?
Equipment as a service charges customers for availability, output, or usage instead of an outright purchase. That model depends on measuring how each machine is used and managing uptime remotely. Embedded telemetry provides the usage data for billing and the condition data needed to control the manufacturer's downtime risk.
What standards apply to condition monitoring systems?
ISO 17359 provides general guidelines for setting up a condition monitoring program, covering what to monitor and how to establish it. ISO 13374 defines the architecture for processing, communicating, and presenting condition monitoring data, describing the flow from data acquisition through health assessment, prognostics, and advisory generation.
What ongoing costs come with a connected machine?
Expect added bill of materials cost per unit, recurring connectivity charges, cloud or platform fees, and long-term security maintenance. Networked products need secure boot, signed firmware, and an over-the-air update path for their full service life. Agreeing who pays these recurring costs is part of the commercial design, not an afterthought.
