Comparing Batches, Not Just Data Points: Two Approaches to Process Analytics

Regulated manufacturers generate enormous volumes of process data every day. Temperatures, flow rates, pressures, pH values and dozens of other signals are captured continuously throughout every production batch. The challenge is rarely whether the data exists. The more important question is whether engineers can use it quickly enough to understand what happened, how one batch differed from another and why a particular batch performed better or worse.

 

That question formed the basis of a recent proof of concept delivered by Réalta Technologies for a client in the food and beverage manufacturing sector. The objective was to combine high-frequency time-series process data with the context surrounding each individual batch, allowing process engineers to compare complete production runs directly rather than exporting data into spreadsheets and manually reviewing separate charts.

 

Rather than selecting a technology stack before proving the concept, we deliberately developed two different approaches to the same manufacturing analytics challenge. The first used established industrial historian and visualisation technologies. The second used an open-source, code-first architecture. The objective was not to decide that one technology was inherently better than the other, but to create two working systems that could be assessed using the client’s own manufacturing data.

 

For manufacturers considering how to move from raw process data towards practical batch analytics, the exercise illustrates an important point: there is rarely one correct architecture. The right answer depends on the systems already in place, the skills available internally, validation requirements, cost, scalability and what the organisation ultimately wants to do with its data.

 

Why batch comparison matters in manufacturing

 

Traditional process analysis often begins with individual data points. An engineer may look at the temperature profile of a vessel, the pressure recorded during a specific stage or the flow rate through a production step. That information can be valuable, but looking at signals individually does not always provide enough context to understand overall batch performance.

 

Batch-to-batch analysis changes the perspective. Instead of asking whether a temperature exceeded a particular value, engineers can examine the complete temperature profile of several production runs at the same time. They can see whether one batch heated more slowly, whether pressure behaved differently during a particular stage or whether a deviation began much earlier in the process than first assumed.

 

The same principle can be applied across multiple process variables. When temperature, pressure, flow, pH and other measurements are viewed alongside the relevant batch context, process engineers gain a much clearer picture of how the production process behaves from one run to the next.

 

This can help support troubleshooting, process optimisation and deeper investigation of production variation. It can also create a stronger foundation for more advanced analytical capabilities such as Golden Batch modelling, automated deviation detection and machine-learning applications.

 

The challenge is context, not simply data collection

 

Most modern manufacturing environments already capture significant volumes of operational data. PLCs, SCADA systems, process historians, laboratory systems and other industrial platforms continuously generate information about equipment and production performance. The difficulty is often connecting those time-series values with the context that makes them meaningful.

 

A temperature value on its own tells an engineer relatively little. To use that information effectively, they may also need to know which batch was running, which stage of production was active, which product was being manufactured and how that value compares with the same point in previous production runs.

 

This is why Réalta Technologies approaches process analytics as more than a visualisation exercise. Effective analytics depends on the relationship between time-series data, manufacturing context and the application through which engineers interact with that information. The proof of concept was designed around that relationship.

 

Approach One: Canary and Ignition

 

The first approach used Canary as the time-series historian and Ignition as the application layer. This represents a more conventional industrial architecture built around technologies that will be familiar to many manufacturers with established historian and SCADA environments.

 

The project began by loading approximately one month of the client’s own historical process data into Canary. The data was supplied as CSV files containing real manufacturing tag information, meaning the proof of concept could be developed and tested against actual production behaviour rather than simulated values.

 

This was important because a process analytics application can appear effective when demonstrated using clean sample data, but manufacturing environments are rarely that simple. 

Real production data contains variation, different operating conditions and the irregularities that engineers ultimately need to investigate. Using the client’s own information meant we could see how the application behaved under realistic conditions from the beginning.

 

Creating the batch comparison interface in Ignition

 

On top of the historian layer, Réalta Technologies developed a purpose-built application using Ignition Perspective. The user experience was intentionally kept straightforward. An engineer could select one or more production batches, choose the process tags they wanted to investigate and then compare those batches on a common trend.

 

The batch information itself was represented through event frames sourced from a SQL database containing the relevant batch metadata. Once the engineer selected the required batches and process variables, the application retrieved and aligned the corresponding time-series data so the different production runs could be viewed together.

 

That ability to overlay batches is where the application becomes particularly useful. A process engineer no longer needs to open one trend, make a note of what happened, load another batch and attempt to compare the two from memory. Several production runs can be viewed within the same analytical environment, making differences in process behaviour much easier to identify.

 

Using Python within the industrial application 

 

The batch comparison logic was implemented using Python scripting within Ignition. Ignition provides native scripting capabilities alongside its SQL connectivity, data binding and application-development tools. For this proof of concept, Python was used to support the logic required to retrieve, organise and present the batch information.

 

One interesting element of the project was the role of AI-assisted coding. Much of the application was developed with guidance from AI coding tools rather than requiring every element of the Python logic to be written manually by a dedicated Python developer.

 

For Réalta Technologies, this is a practical example of how AI can support engineering teams without replacing engineering judgement. The important capability is still understanding the manufacturing problem, defining the architecture, validating the data flows and ensuring the application produces meaningful results. AI-assisted development can accelerate parts of the implementation, but it sits within a much broader systems integration and engineering process.

 

Why an industrial platform approach can make sense

 

The main strength of the Canary and Ignition architecture is that it fits naturally into the kind of industrial technology environment many manufacturers already operate.

 

Where a manufacturer already has historian infrastructure, SCADA applications or an existing MES environment, adding a batch analytics capability may be an extension of systems and governance structures that already exist rather than the introduction of an entirely separate analytics platform.

 

That can have important implications for cybersecurity, user management, maintenance, data governance and validation. The proof of concept demonstrated how batch comparison functionality could be developed while remaining within a recognisable industrial technology architecture.

 

For regulated manufacturers in particular, these considerations can be as important as the analytical functionality itself. The most sophisticated application is of limited value if it creates unnecessary validation complexity, introduces an unsupported technology stack or becomes difficult for the organisation to maintain after deployment.

 

Approach Two: Python and Shiny

 

In parallel with the industrial-platform solution, Réalta Technologies developed a second version of the same batch analytics capability using an entirely different architecture.

 

This version used Python for data handling and analytics, with Shiny providing the interactive application layer. Instead of relying on a commercial historian and industrial visualisation platform, the second approach used open-source technologies that could be owned, extended and version-controlled directly by a data engineering or software team.

 

The manufacturing challenge remained the same. Engineers still needed to select production batches, compare process variables and identify differences between manufacturing runs. What changed was the technology used to deliver that capability. This allowed us to compare two architectures based on exactly the same business requirement rather than comparing technologies in isolation.

 

The flexibility of a code-first approach

 

One of the main advantages of the Python-based solution is flexibility. Because the analytical logic exists directly within Python, it can be extended using the wider ecosystem of statistical analysis, data science and machine-learning libraries available within the language. 

A solution that begins with simple batch overlays could therefore evolve into something considerably more advanced. For example, manufacturers might eventually want to define a Golden Batch profile and measure new production runs against it. They may want to detect unusual process behaviour automatically, calculate statistical differences between batches or introduce machine-learning models capable of identifying process patterns that are difficult to recognise manually.

 

A code-first architecture can make those types of extensions easier because the analytical logic is not restricted to the features available within a particular proprietary application layer. It can also offer a different commercial model by reducing dependency on additional historian or visualisation licences.

 

That may make it particularly attractive to organisations that are earlier in their digitalisation journey or that already have strong internal data engineering capabilities.

 

Flexibility comes with responsibility

 

Open-source does not automatically mean simpler. A code-first application gives an organisation greater control over how the solution is developed, but that control also creates additional responsibilities.

 

The organisation must consider how the application will be hosted, how users will be authenticated, how code will be maintained, how changes will be controlled and how the system will be supported over its lifecycle.

 

In a regulated manufacturing environment, validation also becomes an important consideration. A bespoke Python application may provide enormous flexibility, but the organisation still needs an appropriate approach to testing, documentation, change control and governance.

This is why architecture decisions should not be based on software licensing alone. The lowest-cost technology stack at the proof-of-concept stage is not automatically the lowest-cost solution over the complete lifecycle of the system.

 

Commercial platform versus open source is the wrong question

 

The purpose of developing both approaches was not to declare one the winner. Every manufacturer starts from a different position. One organisation may already have industrial historian and SCADA platforms supported by established engineering and validation teams. Another may have a strong cloud and data engineering capability and prefer to build more of its analytical functionality using open technologies.

Budget also matters. So does internal expertise. So does validation. So does the organisation’s appetite for maintaining custom code.

The proof of concept allowed Réalta Technologies and the client to compare both options as working systems, looking at how information moved through each architecture, how engineers interacted with the batch comparison functionality and what would be involved in supporting each solution over time.

 

That is a much stronger basis for a technology decision than comparing feature lists.

 

A hybrid approach may be the right answer

 

It is also important not to assume that manufacturers must choose entirely between commercial industrial software and open-source analytics.

In many environments, the strongest architecture may combine the two. A process historian might remain the trusted system for high-frequency operational data, while Python-based services perform more advanced analysis. An industrial application might provide the primary interface for production users, while a separate data science environment supports model development and experimentation.

The precise architecture depends on the manufacturing requirement. At Réalta Technologies, our role is not to force a client towards one platform. It is to understand the operational problem, existing infrastructure and long-term objectives, and then determine how the available technologies can be combined effectively.

 

From batch comparison to Golden Batch analytics

 

Batch overlay is a relatively simple concept, but it can become the foundation for much more advanced process analytics.

Once manufacturers can align production runs consistently and compare the same process stages across batches, they can begin asking more sophisticated questions. What does a high-performing batch look like? Which process variables are most closely associated with quality or yield? At what point does a poor-performing batch begin to diverge from the expected profile? Can an operator be alerted while the batch is still running rather than discovering the issue afterwards?

 

This is where Golden Batch analysis becomes particularly relevant. Rather than simply comparing one batch with another, manufacturers can establish a reference profile representing desirable process behaviour and compare future batches against that baseline.

 

Over time, statistical models and machine-learning techniques can add another layer of intelligence, helping engineering teams identify patterns across hundreds or thousands of production runs. The value is not simply more analytics. It is the potential to turn historical manufacturing data into practical operational knowledge.

 

Why the data foundation still matters

 

Regardless of which analytical approach is selected, reliable process analytics depends on the quality of the data underneath it.

Manufacturers need trustworthy time-series information, consistent timestamps, meaningful data quality indicators and sufficient context to understand which equipment, process stage and production batch each measurement belongs to.

 

This is where broader Data Infrastructure becomes important. Historians are one component of that architecture, but modern manufacturing environments may also include Unified Namespace architectures, MQTT brokers, industrial data platforms, contextualisation layers and scalable IT/OT integration.

 

The analytics application sits above these foundations. If the underlying data is incomplete, inconsistent or poorly contextualised, the quality of the analytics will inevitably suffer.

 

Proof of concept before full-scale investment

 

The project also demonstrates why a proof of concept can be valuable when manufacturers are considering new digital capabilities.

Technology decisions are often made through presentations, feature comparisons and demonstrations using idealised sample data. A proof of concept allows the organisation to go further.

 

By building both architectures using the client’s actual process data, we were able to move the discussion away from hypothetical questions about commercial versus open-source technology and towards evidence about how each solution would operate in practice.

 

That significantly reduces uncertainty before a manufacturer commits to a wider implementation. It also creates an opportunity to identify technical challenges, user requirements and data-quality issues while the scope is still deliberately small.

 

How Réalta Technologies approaches process analytics

 

At Réalta Technologies, we see process analytics as part of the wider manufacturing technology environment rather than a standalone reporting exercise.

That means understanding where the data originates, how it is collected, how production context is represented, how users need to interact with the information and how the architecture could evolve in the future.

Our capabilities across Data Infrastructure, Advanced Automation, Data Analytics and Reporting, Software Development and AI allow us to look across those layers rather than treating them as separate projects.

For one manufacturer, the right answer may be an application extending an existing historian and industrial software environment. For another, it may be a code-first analytics platform. In other cases, the strongest approach may be a combination of both. The technology should follow the manufacturing requirement.

 

The key takeaway

 

Manufacturers already have enormous quantities of process data. The opportunity is to move beyond looking at individual tags and begin analysing production in its proper manufacturing context.

 

Batch comparison provides a practical starting point. It allows engineers to view entire production runs together, recognise variation more quickly and begin identifying the process behaviours associated with successful and unsuccessful batches.

The Réalta Technologies proof of concept demonstrated two viable ways of achieving that outcome: an industrial historian and application architecture using Canary and Ignition, and an open-source approach using Python and Shiny.

 

Neither approach is universally correct. The right architecture depends on existing infrastructure, internal capabilities, validation requirements, budget and the manufacturer’s longer-term ambitions for analytics and AI.

 

The real value of the proof of concept was replacing assumptions with evidence.

 

If your organisation is exploring how to move from raw process data to genuine batch-to-batch insight, Réalta Technologies can help assess the options, build and test the architecture, and develop a path towards more advanced process analytics.

 

[email protected]

IRL: +353 21 243 9113 | US: +1 302 509 4401

Batch analytics is the process of analysing manufacturing data in the context of complete production batches rather than reviewing individual process values in isolation. It allows engineers to compare production runs, identify process variation and investigate why one batch behaved differently from another.

Batch-to-batch comparison aligns data from multiple production runs so engineers can compare equivalent process stages and variables. For example, temperature, pressure or flow profiles from several batches can be overlaid on one trend to make differences easier to identify.

Golden Batch analysis uses a high-performing or representative production run as a reference profile. Subsequent batches can then be compared against that profile to identify deviations and understand whether process behaviour is moving away from an expected operating pattern.

Yes. Process historians provide the high-frequency time-series data required for many batch analytics applications. However, the historian data normally needs to be combined with contextual information such as batch IDs, production stages and equipment relationships to support meaningful comparison.

In this proof of concept, Canary provided the historian layer while Ignition provided the application and visualisation environment. This approach can be attractive to manufacturers that already use industrial platforms and want analytics to fit within familiar operational, security and governance structures.

Yes. Python provides extensive libraries for data manipulation, statistical analysis, machine learning and visualisation. In this proof of concept, Réalta Technologies combined Python with Shiny to create an open-source alternative to the industrial-platform architecture.

Not necessarily. Each approach has different strengths. Industrial platforms can offer established infrastructure and governance, while open-source technologies can provide 11 

greater analytical flexibility and direct control over the code. The right approach depends on the manufacturer's existing systems, skills, budget, validation requirements and long-term objectives.

A proof of concept allows manufacturers to test an architecture using real production data before committing to a larger implementation. It can reveal technical limitations, data-quality issues, user requirements and lifecycle considerations that are difficult to identify through theoretical technology comparisons alone.

Comparing Batches, Not Just Data Points: Two Approaches to Process Analytics

Regulated manufacturers generate enormous volumes of process data every day. Temperatures, flow rates, pressures, pH values and dozens of other signals are captured continuously throughout every production batch. The challenge is rarely whether the data exists. The more important question is whether engineers can use it quickly enough to understand what happened, how one batch differed from another and why a particular batch performed better or worse.

 

That question formed the basis of a recent proof of concept delivered by Réalta Technologies for a client in the food and beverage manufacturing sector. The objective was to combine high-frequency time-series process data with the context surrounding each individual batch, allowing process engineers to compare complete production runs directly rather than exporting data into spreadsheets and manually reviewing separate charts.

 

Rather than selecting a technology stack before proving the concept, we deliberately developed two different approaches to the same manufacturing analytics challenge. The first used established industrial historian and visualisation technologies. The second used an open-source, code-first architecture. The objective was not to decide that one technology was inherently better than the other, but to create two working systems that could be assessed using the client’s own manufacturing data.

 

For manufacturers considering how to move from raw process data towards practical batch analytics, the exercise illustrates an important point: there is rarely one correct architecture. The right answer depends on the systems already in place, the skills available internally, validation requirements, cost, scalability and what the organisation ultimately wants to do with its data.

 

Why batch comparison matters in manufacturing

 

Traditional process analysis often begins with individual data points. An engineer may look at the temperature profile of a vessel, the pressure recorded during a specific stage or the flow rate through a production step. That information can be valuable, but looking at signals individually does not always provide enough context to understand overall batch performance.

 

Batch-to-batch analysis changes the perspective. Instead of asking whether a temperature exceeded a particular value, engineers can examine the complete temperature profile of several production runs at the same time. They can see whether one batch heated more slowly, whether pressure behaved differently during a particular stage or whether a deviation began much earlier in the process than first assumed.

 

The same principle can be applied across multiple process variables. When temperature, pressure, flow, pH and other measurements are viewed alongside the relevant batch context, process engineers gain a much clearer picture of how the production process behaves from one run to the next.

 

This can help support troubleshooting, process optimisation and deeper investigation of production variation. It can also create a stronger foundation for more advanced analytical capabilities such as Golden Batch modelling, automated deviation detection and machine-learning applications.

 

The challenge is context, not simply data collection

 

Most modern manufacturing environments already capture significant volumes of operational data. PLCs, SCADA systems, process historians, laboratory systems and other industrial platforms continuously generate information about equipment and production performance. The difficulty is often connecting those time-series values with the context that makes them meaningful.

 

A temperature value on its own tells an engineer relatively little. To use that information effectively, they may also need to know which batch was running, which stage of production was active, which product was being manufactured and how that value compares with the same point in previous production runs.

 

This is why Réalta Technologies approaches process analytics as more than a visualisation exercise. Effective analytics depends on the relationship between time-series data, manufacturing context and the application through which engineers interact with that information. The proof of concept was designed around that relationship.

 

Approach One: Canary and Ignition

 

The first approach used Canary as the time-series historian and Ignition as the application layer. This represents a more conventional industrial architecture built around technologies that will be familiar to many manufacturers with established historian and SCADA environments.

 

The project began by loading approximately one month of the client’s own historical process data into Canary. The data was supplied as CSV files containing real manufacturing tag information, meaning the proof of concept could be developed and tested against actual production behaviour rather than simulated values.

 

This was important because a process analytics application can appear effective when demonstrated using clean sample data, but manufacturing environments are rarely that simple. 

Real production data contains variation, different operating conditions and the irregularities that engineers ultimately need to investigate. Using the client’s own information meant we could see how the application behaved under realistic conditions from the beginning.

 

Creating the batch comparison interface in Ignition

 

On top of the historian layer, Réalta Technologies developed a purpose-built application using Ignition Perspective. The user experience was intentionally kept straightforward. An engineer could select one or more production batches, choose the process tags they wanted to investigate and then compare those batches on a common trend.

 

The batch information itself was represented through event frames sourced from a SQL database containing the relevant batch metadata. Once the engineer selected the required batches and process variables, the application retrieved and aligned the corresponding time-series data so the different production runs could be viewed together.

 

That ability to overlay batches is where the application becomes particularly useful. A process engineer no longer needs to open one trend, make a note of what happened, load another batch and attempt to compare the two from memory. Several production runs can be viewed within the same analytical environment, making differences in process behaviour much easier to identify.

 

Using Python within the industrial application 

 

The batch comparison logic was implemented using Python scripting within Ignition. Ignition provides native scripting capabilities alongside its SQL connectivity, data binding and application-development tools. For this proof of concept, Python was used to support the logic required to retrieve, organise and present the batch information.

 

One interesting element of the project was the role of AI-assisted coding. Much of the application was developed with guidance from AI coding tools rather than requiring every element of the Python logic to be written manually by a dedicated Python developer.

 

For Réalta Technologies, this is a practical example of how AI can support engineering teams without replacing engineering judgement. The important capability is still understanding the manufacturing problem, defining the architecture, validating the data flows and ensuring the application produces meaningful results. AI-assisted development can accelerate parts of the implementation, but it sits within a much broader systems integration and engineering process.

 

Why an industrial platform approach can make sense

 

The main strength of the Canary and Ignition architecture is that it fits naturally into the kind of industrial technology environment many manufacturers already operate.

 

Where a manufacturer already has historian infrastructure, SCADA applications or an existing MES environment, adding a batch analytics capability may be an extension of systems and governance structures that already exist rather than the introduction of an entirely separate analytics platform.

 

That can have important implications for cybersecurity, user management, maintenance, data governance and validation. The proof of concept demonstrated how batch comparison functionality could be developed while remaining within a recognisable industrial technology architecture.

 

For regulated manufacturers in particular, these considerations can be as important as the analytical functionality itself. The most sophisticated application is of limited value if it creates unnecessary validation complexity, introduces an unsupported technology stack or becomes difficult for the organisation to maintain after deployment.

 

Approach Two: Python and Shiny

 

In parallel with the industrial-platform solution, Réalta Technologies developed a second version of the same batch analytics capability using an entirely different architecture.

 

This version used Python for data handling and analytics, with Shiny providing the interactive application layer. Instead of relying on a commercial historian and industrial visualisation platform, the second approach used open-source technologies that could be owned, extended and version-controlled directly by a data engineering or software team.

 

The manufacturing challenge remained the same. Engineers still needed to select production batches, compare process variables and identify differences between manufacturing runs. What changed was the technology used to deliver that capability. This allowed us to compare two architectures based on exactly the same business requirement rather than comparing technologies in isolation.

 

The flexibility of a code-first approach

 

One of the main advantages of the Python-based solution is flexibility. Because the analytical logic exists directly within Python, it can be extended using the wider ecosystem of statistical analysis, data science and machine-learning libraries available within the language. 

A solution that begins with simple batch overlays could therefore evolve into something considerably more advanced. For example, manufacturers might eventually want to define a Golden Batch profile and measure new production runs against it. They may want to detect unusual process behaviour automatically, calculate statistical differences between batches or introduce machine-learning models capable of identifying process patterns that are difficult to recognise manually.

 

A code-first architecture can make those types of extensions easier because the analytical logic is not restricted to the features available within a particular proprietary application layer. It can also offer a different commercial model by reducing dependency on additional historian or visualisation licences.

 

That may make it particularly attractive to organisations that are earlier in their digitalisation journey or that already have strong internal data engineering capabilities.

 

Flexibility comes with responsibility

 

Open-source does not automatically mean simpler. A code-first application gives an organisation greater control over how the solution is developed, but that control also creates additional responsibilities.

 

The organisation must consider how the application will be hosted, how users will be authenticated, how code will be maintained, how changes will be controlled and how the system will be supported over its lifecycle.

 

In a regulated manufacturing environment, validation also becomes an important consideration. A bespoke Python application may provide enormous flexibility, but the organisation still needs an appropriate approach to testing, documentation, change control and governance.

This is why architecture decisions should not be based on software licensing alone. The lowest-cost technology stack at the proof-of-concept stage is not automatically the lowest-cost solution over the complete lifecycle of the system.

 

Commercial platform versus open source is the wrong question

 

The purpose of developing both approaches was not to declare one the winner. Every manufacturer starts from a different position. One organisation may already have industrial historian and SCADA platforms supported by established engineering and validation teams. Another may have a strong cloud and data engineering capability and prefer to build more of its analytical functionality using open technologies.

Budget also matters. So does internal expertise. So does validation. So does the organisation’s appetite for maintaining custom code.

The proof of concept allowed Réalta Technologies and the client to compare both options as working systems, looking at how information moved through each architecture, how engineers interacted with the batch comparison functionality and what would be involved in supporting each solution over time.

 

That is a much stronger basis for a technology decision than comparing feature lists.

 

A hybrid approach may be the right answer

 

It is also important not to assume that manufacturers must choose entirely between commercial industrial software and open-source analytics.

In many environments, the strongest architecture may combine the two. A process historian might remain the trusted system for high-frequency operational data, while Python-based services perform more advanced analysis. An industrial application might provide the primary interface for production users, while a separate data science environment supports model development and experimentation.

The precise architecture depends on the manufacturing requirement. At Réalta Technologies, our role is not to force a client towards one platform. It is to understand the operational problem, existing infrastructure and long-term objectives, and then determine how the available technologies can be combined effectively.

 

From batch comparison to Golden Batch analytics

 

Batch overlay is a relatively simple concept, but it can become the foundation for much more advanced process analytics.

Once manufacturers can align production runs consistently and compare the same process stages across batches, they can begin asking more sophisticated questions. What does a high-performing batch look like? Which process variables are most closely associated with quality or yield? At what point does a poor-performing batch begin to diverge from the expected profile? Can an operator be alerted while the batch is still running rather than discovering the issue afterwards?

 

This is where Golden Batch analysis becomes particularly relevant. Rather than simply comparing one batch with another, manufacturers can establish a reference profile representing desirable process behaviour and compare future batches against that baseline.

 

Over time, statistical models and machine-learning techniques can add another layer of intelligence, helping engineering teams identify patterns across hundreds or thousands of production runs. The value is not simply more analytics. It is the potential to turn historical manufacturing data into practical operational knowledge.

 

Why the data foundation still matters

 

Regardless of which analytical approach is selected, reliable process analytics depends on the quality of the data underneath it.

Manufacturers need trustworthy time-series information, consistent timestamps, meaningful data quality indicators and sufficient context to understand which equipment, process stage and production batch each measurement belongs to.

 

This is where broader Data Infrastructure becomes important. Historians are one component of that architecture, but modern manufacturing environments may also include Unified Namespace architectures, MQTT brokers, industrial data platforms, contextualisation layers and scalable IT/OT integration.

 

The analytics application sits above these foundations. If the underlying data is incomplete, inconsistent or poorly contextualised, the quality of the analytics will inevitably suffer.

 

Proof of concept before full-scale investment

 

The project also demonstrates why a proof of concept can be valuable when manufacturers are considering new digital capabilities.

Technology decisions are often made through presentations, feature comparisons and demonstrations using idealised sample data. A proof of concept allows the organisation to go further.

 

By building both architectures using the client’s actual process data, we were able to move the discussion away from hypothetical questions about commercial versus open-source technology and towards evidence about how each solution would operate in practice.

 

That significantly reduces uncertainty before a manufacturer commits to a wider implementation. It also creates an opportunity to identify technical challenges, user requirements and data-quality issues while the scope is still deliberately small.

 

How Réalta Technologies approaches process analytics

 

At Réalta Technologies, we see process analytics as part of the wider manufacturing technology environment rather than a standalone reporting exercise.

That means understanding where the data originates, how it is collected, how production context is represented, how users need to interact with the information and how the architecture could evolve in the future.

Our capabilities across Data Infrastructure, Advanced Automation, Data Analytics and Reporting, Software Development and AI allow us to look across those layers rather than treating them as separate projects.

For one manufacturer, the right answer may be an application extending an existing historian and industrial software environment. For another, it may be a code-first analytics platform. In other cases, the strongest approach may be a combination of both. The technology should follow the manufacturing requirement.

 

The key takeaway

 

Manufacturers already have enormous quantities of process data. The opportunity is to move beyond looking at individual tags and begin analysing production in its proper manufacturing context.

 

Batch comparison provides a practical starting point. It allows engineers to view entire production runs together, recognise variation more quickly and begin identifying the process behaviours associated with successful and unsuccessful batches.

The Réalta Technologies proof of concept demonstrated two viable ways of achieving that outcome: an industrial historian and application architecture using Canary and Ignition, and an open-source approach using Python and Shiny.

 

Neither approach is universally correct. The right architecture depends on existing infrastructure, internal capabilities, validation requirements, budget and the manufacturer’s longer-term ambitions for analytics and AI.

 

The real value of the proof of concept was replacing assumptions with evidence.

 

If your organisation is exploring how to move from raw process data to genuine batch-to-batch insight, Réalta Technologies can help assess the options, build and test the architecture, and develop a path towards more advanced process analytics.

 

[email protected]

IRL: +353 21 243 9113 | US: +1 302 509 4401

Batch analytics is the process of analysing manufacturing data in the context of complete production batches rather than reviewing individual process values in isolation. It allows engineers to compare production runs, identify process variation and investigate why one batch behaved differently from another.

Batch-to-batch comparison aligns data from multiple production runs so engineers can compare equivalent process stages and variables. For example, temperature, pressure or flow profiles from several batches can be overlaid on one trend to make differences easier to identify.

Golden Batch analysis uses a high-performing or representative production run as a reference profile. Subsequent batches can then be compared against that profile to identify deviations and understand whether process behaviour is moving away from an expected operating pattern.

Yes. Process historians provide the high-frequency time-series data required for many batch analytics applications. However, the historian data normally needs to be combined with contextual information such as batch IDs, production stages and equipment relationships to support meaningful comparison.

In this proof of concept, Canary provided the historian layer while Ignition provided the application and visualisation environment. This approach can be attractive to manufacturers that already use industrial platforms and want analytics to fit within familiar operational, security and governance structures.

Yes. Python provides extensive libraries for data manipulation, statistical analysis, machine learning and visualisation. In this proof of concept, Réalta Technologies combined Python with Shiny to create an open-source alternative to the industrial-platform architecture.

Not necessarily. Each approach has different strengths. Industrial platforms can offer established infrastructure and governance, while open-source technologies can provide 11 

greater analytical flexibility and direct control over the code. The right approach depends on the manufacturer's existing systems, skills, budget, validation requirements and long-term objectives.

A proof of concept allows manufacturers to test an architecture using real production data before committing to a larger implementation. It can reveal technical limitations, data-quality issues, user requirements and lifecycle considerations that are difficult to identify through theoretical technology comparisons alone.