Competing amid economic and supply chain volatility requires agility, and agility hinges on real-time, reliable operational data. Yet for many manufacturers, that level of visibility remains elusive.
Flexware Innovation recently partnered with an automotive manufacturer struggling to achieve a clear view of operational performance. The team had a simple question, but it was hard to answer: which machines are costing us the most downtime?
The gap for this manufacturer wasn’t the data. Every machine was already generating the information—controllers tracked state, faults hit the HMI and operators could name the problem cells from memory. The challenge was turning the data into actionable insights.
To gain the visibility required for faster, more informed decisions, the manufacturer needed to bridge the gap between data generation and operational intelligence. That transformation depended on four foundational steps: creation, contextualization, standardization and connection.
Creation: Capture the Right Signal
The first step to unlocking visibility is determining whether the right signal exists.
For the automotive manufacturer, some machines on that floor reported only one piece of information: running or not running. That signal only told them a cell stopped. It did not tell them why.
This is a common barrier to effective downtime analysis. It’s also the cheapest to fix. Machine states and stop reasons can be programmed within a few hours during a scheduled upgrade.
One way to test whether the right signal exists is to take your most quoted plant metric and trace it back to the machine that produces it. If you can’t do that without making assumptions, the right signal doesn’t exist yet.
Contextualization: Tell the Full Story
Knowing a machine stopped at 10:42 is nearly useless. What turns that information into insight is context like which product was running, which shift was on the floor and which upstream cell starved it.
Context must be attached where the data is created. Otherwise, it will need to be reconstructed later by another system, making the solution difficult to scale.
Timestamps are also critical context, and there are at least three that should be included: the time the event occurred, the time the value was read and the time it was written to a historian. Each one answers a different question, and conflating them can distort the timeline. For example, on a polled architecture, the system only checks for a new value at set intervals, so the time it’s read and recorded can lag behind the moment the event happened.
Engineering unit conversion has the same problem. When conversion happens in the PLC on one line, in a gateway on another and in the visualization layer on a third, it results in three different answers to the same question. The more reliable approach is to convert the value as close to the source as practical, and let everything downstream inherit it.
To test whether the right context is present, pick one recorded value and determine what product was running when it was captured. If that takes a second system and an employee’s memory, you don’t have the right context.
Standardization: Ensure Consistency
Even with the right signals and context in place, the data is still incomplete without standardization. The automotive manufacturer ran into this challenge because it was running equipment from several builders, each with its own machine state definition.
Rank those machines against each other, and the results become unreliable.
One way to address this is by adding translation logic to reconcile the differences. However, each new line adds another layer of complexity to that logic until the system becomes difficult to maintain.
The better approach is to treat program structure as data structure.
Frameworks like ISA-95 and PackML already provide a common vocabulary. The key is to pick one and ensure consistency.
With that standardization in place, the new work conforms by default, and legacy equipment can be normalized once at an edge node or gateway rather than in every application that consumes it.
To test for effective standardization, ask two engineers from two lines to define “running” and “downtime,” and compare the answers.
Connectivity: Access the Data
The final barrier for the automotive manufacturer was connectivity. A few machines had standalone panels that weren’t reporting beyond the floor. The data existed, but no one outside that immediate area could see it.
The cause of this issue was twofold. The first constraint was architecture. The network had no route upward.
The second was the quiet killer: permission. When exposing each new piece of information requires a program change, a validation and a maintenance window, nothing compounds, and the plant stays in a permanent pilot. Proper network segmentation removes that bottleneck.
To evaluate connectivity, consider how long it takes to make one new piece of machine data visible to a business system. If the answer is weeks, your constraint is architectural, not technical.
Unlocking Operational Data
These four steps are essential for unlocking actionable insight. Skip any one of them, and you end up with ambiguous values or, worse, inaccurate answers that lead to misguided action.
By following this approach, the automotive manufacturer got its answer: a clear, ranked list of which machines were driving the most downtime. But the more valuable outcome was the data foundation that was created. The next question—and the one after that—will get answered in a fraction of the time because the underlying data infrastructure is in place. Now, the manufacturer can make quick decisions and act with agility in the face of unrelenting disruption.
Full visibility is achievable with the right roadmap. Start building yours with an Automation Layer Assessment.
