Product Usage Data in Mechanical Engineering: How Real-World Usage Data Shortens Development Cycles

Mechanical engineering firms carry out their design work behind the scenes. Their engineers calculate loads, service life and efficiency based on standards, experience and simulation. This often works well. But sometimes it doesn’t. A component wears out faster than calculated. A particular type of machine is used in applications that the developers never envisaged. One feature is hardly ever used, whilst another is used much more frequently than anticipated.

How do you know this? These days, often only when customers report problems or provide feedback – months or years after the product has been launched. That’s too late. The next generation is already well into development.

Product usage data changes this dynamic. When machines are monitored via telemetry whilst in operation, and when real-world usage data flows back into the company, a new window of learning opens up. Design engineers don’t just see what might happen; they see what is actually happening. Based on this, they can iterate more quickly and with greater confidence.

This article shows how usage data impacts product development – and how d.u.h.Group supports you in this process.

Usage data is useless in isolation. It needs context. Which machine variant? Which year of manufacture? Which serial number? Which design version? The link is the product’s digital identity – its digital thread.

The Digital Thread links requirements, design, simulation, production and operation. In mechanical engineering, it often begins in a PLM system such as Teamcenter. This is where the designs are stored in NX, along with bills of materials, variants, configurations and change history.

When usage data arrives, it needs a way into the Digital Thread. In practical terms, this means: a machine sends telemetry data (vibration, temperature, force, operating hours, faults). This data is linked to the serial number. Using the serial number, you can look up the following in Teamcenter: Which model series version? Which options? What specifications?

You can now carry out analyses: all machines from version 3.2 with the ‘High-Duty’ configuration show error rates 15 per cent higher than the average. Which components are affected? Teamcenter tells you what has changed from version 3.1 to 3.2. Was it a design change? A change of supplier?

With this context, design engineers can act quickly. They aren’t analysing in a vacuum. They have data, history and design context all in one place. The time to insight is drastically reduced.

Technically, this means that PLM must be open to external data. REST APIs or other integration methods allow usage data to be correlated with product metadata. This is now possible with Teamcenter and does not require a mammoth integration project. Middleware often connects the IoT platform to the PLM.

Usage data makes product development more empirical. It relies less on assumptions and more on facts.

A typical workflow might look like this: every month, you download usage data from installed machines. You aggregate it: average performance profiles by machine type, region and customer sector. You compare this with design specifications: where do the actual profiles deviate?

You identify patterns. For example: Hydraulic cylinder X is being operated at twice the cycle frequency specified. This shortens its service life. This option for these cylinders is popular with customers, but the performance profile is not healthy. The design team would need to respond.

Or: A sensor system Y is rarely calibrated by customers – even though the documentation provides clear instructions. The data shows that uncalibrated sensors systematically return incorrect values. This leads to substandard control. A constructive response: automatic self-calibration in the next version. A software update is rolled out to customers with older machines.

Or: Machine type Z is frequently used by customers in applications not covered in the specifications. The usage data clearly shows this. The design team could offer a specialised variant that better suits this application. This represents a new business opportunity.

These iterations often happen by chance or slowly at present. With structured usage data analysis, they can take place on a monthly basis. This significantly shortens development cycles.

The feedback loop is particularly valuable: your design engineer makes a change to the design. The version goes into production. You build the machines and install them. After three months of operation, you can see: is the change working? Have the objectives been achieved? Do you need to make adjustments? This is genuine learning by doing, only accelerated by data.

To illustrate the reality of the situation, here are three scenarios from the mechanical engineering sector:

Scenario 1 – Hydraulics: A manufacturer of hydraulic cylinders collects operational data from customers. The data reveals that, in the textile industry, cylinders are being operated at twice the specified cycle rate. In the mining industry, vibration levels are three times higher than those stipulated by standards. The engineers recognise this and develop variants: a lightweight version for standard applications, a robust version for the textile industry, and a vibration-damped version for mining. Revenue growth follows, as the product range now meets demand. Time-to-market for the variants: six weeks instead of the previous six months – because the data made the requirements clear.

Scenario 2 – Gearbox development: A gearbox manufacturer notices in the usage data that certain load profiles lead to tooth wear occurring earlier than simulations predicted. Design engineers analyse the data and discover that the actual tooth flank topography differs from the CAD specifications. A drift in the manufacturing process is to blame. However, the data also reveals that this drift actually performs better under certain load profiles. This leads to the idea of deliberately modifying the tooth profile to handle higher loads. A patent is filed. Usage data leads to innovation.

Scenario 3 – IoT machines: A manufacturer of production machines with built-in IoT observes from the data that many customers are not actively using the predictive maintenance function – even though it would reduce downtime. The usage data shows that the interface is too complex; customers do not understand it. The design team drastically simplifies the UI and calls it ‘Smart Mode’. Following the roll-out, 80 per cent of customers use it. Customer satisfaction rises as availability increases.

These scenarios are not utopian – they are happening today in companies that systematically utilise usage data.