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 KPI’s 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.
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 https://www.oee.com/calculating-oee.html
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:
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:
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.
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.