Skip to main content Skip to footer


How to calculate OEE and Operational KPI’s using Edge Analytics

An important use of machine data is to calculate different KPIs to measure the performance and behaviour of machines or processes. These KPIs can be used both to get instantaneous status and to track behaviour over time to make sure the behaviour does not deviate from what is expected. KPIs are also useful for evaluating the impact of optimization changes that have been introduced.

Edge analytics is a perfect tool both for collecting the relevant data and calculating these KPIs but also to trigger actions when anomalous behaviour is detected. Sitting close to the sources of the data means that results are available as quickly as possible and the responses can be fast.

Actions can be taken directly from the edge processing, while the actual KPI values can be delivered to on-premise or cloud systems for direct visualization and/or storage for trend analysis. If actions need to be taken based on trend analysis the edge can be complemented with a time series database to allow local analysis that also uses historical data.

Operational KPIs and OEE

The idea with a KPI is to present a single number that quantifies some relevant characteristic of the system under observation. It can be an absolute value, like Number of units produced in the last hour, but in many cases it is preferable to use relative numbers where the measurement is compared against the optimal results.

Relative values are typically presented as percentages, with 100% indicating optimal behaviour. KPIs can be based on a single measurement, but also be a combination of multiple measurements, like OEE (Overall Equipment Efficiency). OEE combines three KPIs into a single value: Availability, Performance and Quality.

Crosser OEE Formula

Getting started with KPIs

Before getting into the more complex KPIs such as OEE, let’s look at some simple KPIs. Many KPIs can be generated by either counting occurrences or measuring time spent in some states, accumulated over a fixed period of time, for example:

If we get a signal each time a new product is finished we can generate the KPI Products produced per hour

If we get a signal that is true when a machine is running and false when it’s not we can calculate the KPI Uptime, presented as a percentage where 100% means that it’s been running all the time.

KPIs like this can be used as is and be presented for example on a dashboard with the current values for live status and a graph over time for trend analysis. They can also be used to generate triggers when they deviate too much from expected values by comparing them against a threshold value. These triggers can then be sent to engineers on the floor or managers that need to take actions.

OEE - three KPI’s in one

By combining simple KPIs we can generate more complex KPIs which will give a more complete picture of the situation. Let’s take OEE as an example, for more information on how to calculate OEE see for example

The OEE KPI is a combination of three components: Availability, Performance and Quality. Each component is a value between 0 and 100%, where 100% corresponds to optimal behavior. Let’s tackle them one at a time.


Availability is a measure of how much of the available time a machine was operating (doing useful work) and is defined as:

Crosser OEE Availability

The Run Time we can measure if we have a signal telling us when the machine is running. The Planned Production Time needs to be provided as static input, e.g. if the machine is expected to run continuously during an 8 hour shift per day the Planned Production Time will be “8 hours per day” and we should only measure the Run Time during the Planned Production Time window.


Performance is a measure of how well a machine performs when it’s active, in terms of the number of units produced. It can be calculated by comparing the number of produced units in a time window with the optimal number of units the machine should be able to produce:

Crosser OEE Performance

Again we can measure Number of Units Produced if we get a signal when each new unit is completed. The Expected Number of Units must be provided as static input, e.g. “1000 units per hour”.


Quality measures the yield, i.e. the ratio of products produced that can actually be used without requiring rework or be scrapped:

Crosser OEE Quality

If we have a signal telling us the status of each product produced, Good or Bad, this number can be calculated without any additional information.

Calculating KPIs with Crosser Streaming Analytics

Based on the above discussions we see that many KPIs can be calculated by a few common operations applied on machine data. The Crosser Edge Streaming Analytics solution is the perfect platform for performing these calculations next to the machines, for immediate use to generate fast actions or provide information to dashboards, local or remote.

The Crosser module library has a set of modules specifically targeting KPI calculations. Combined with modules to collect data from machines and deliver results to different on-premise and cloud systems, a complete KPI driven analytics pipeline can easily be implemented.

Crosser KPI modules

Scheduler - Used to define when KPI measurements should be active, e.g. by defining shift hours. Will generate a “Start” message at the beginning of an active period and a “Stop” message at the end of the period. Any number of active periods can be defined, by referencing wall clock time.

Message Counter - Counts messages over a defined period of time, e.g. 1 hour. At the end of each time period a message with the following information is delivered:

  • Total number of messages received within the last time period
  • Number of messages for each value of a specified property. For example, if the message contains a property saying if a produced product was “good” or “bad” it will report the number of messages where it was set to “good” and the number of messages where it was set to “bad”
  • Relative number of messages for each value of a specified property. Using the same property and results as above, but dividing each value with the total number of messages received. Using the same example we will get “yield” and “scrap rate” This module will only count messages while in an active state, triggered by a “Start” signal, e.g. from the “Scheduler” module.

Time Counter - Measures the time spent in different states, by looking at a selected signal, e.g. “Machine running/stopped”, measured over a time period. At the end of each time period a message is delivered containing the absolute and relative time spent in each state (value of the input signal). This module will only measure time while in an active state, triggered by a “Start” signal, e.g. from the “Scheduler” module.

Crosser OEE Calculation Flow

Picture: Using pre-built modules to easily create OEE calculations from machine data
and publish the OEE to dashboards combined with message notifications based on thresholds.


Increase your insights and ability to act in realtime on signal changes with Crosser Edge Analytics. Improve your overall OEE performance by knowing more.

The pre-built modules for KPI calculations makes it easier than ever to implement a deeper understanding of your production processes and insights is the starting point of improvement.

Contact us to discuss how Crosser can be relevant and how to get going in no-time with the self-service capabilities of the platform.

Read more:

The Crosser Platform →

Edge Analytics →

About the author

Goran Appelquist (Ph.D) | CTO

Göran has 20 years experience in leading technology teams. He’s the lead architect of our end-to-end solution and is extremely focused in securing the lowest possible Total Cost of Ownership for our customers.

"Hidden Lifecycle (employee) cost can account for 5-10 times the purchase price of software. Our goal is to offer a solution that automates and removes most of the tasks that is costly over the lifecycle.

My career started in the academic world where I got a PhD in physics by researching large scale data acquisition systems for physics experiments, such as the LHC at CERN. After leaving academia I have been working in several tech startups in different management positions over the last 20 years.

In most of these positions I have stood with one foot in the R&D team and another in the product/business teams. My passion is learning new technologies, use it to develop innovative products and explain the solutions to end users, technical or non-technical."