Introduction
OEE (Overall Equipment Effectiveness) is a metric for measuring the efficiency, effectiveness and performance of production processes, by breaking them down into the three components Availability, Performance, and Quality.
Cumulocity is evolving its approach to OEE calculations to provide a more integrated and flexible solution. While the standalone Cumulocity OEE App has been deprecated, we are introducing an enhanced approach that better aligns with our platform’s current capabilities and long-term strategy.
The core calculation logic of the Cumulocity OEE App is now being made available as an open-source OEE block for Analytics Builder, enabling seamless integration with Cumulocity’s core applications. This strategic enhancement allows users to:
-
Create customized OEE calculations using Analytics Builder models
-
Manage asset hierarchies through Digital Twin Manager
-
Visualize data in Cumulocity IoT Cockpit using enhanced dashboarding capabilities
-
Implement flexible, enterprise-wide solutions tailored to specific business needs
As the OEE block is open-source, developers can modify and enhance it to meet their specific requirements.
Differences to the Cumulocity OEE App
The OEE Block differs in significant ways from the Cumulocity OEE App
- No Web application & microservices - the Cumulocity OEE App consisted of a Web application available via the application switcher in Cumulocity and microservices providing the backend functionality. The backend functionality is now integrated into the block that can be deployed into Cumulocity Streaming Analytics. OEE calculations are defined by creating Analytics Builder models in Streaming Analytics. Visualization of OEE results should be done in Cockpit using standard or custom widget.
- Focus on core calculation - the Cumulocity OEE App supported the definition of complex calculation rules. These were hard to understand for users and required complicated functionality in the OEE App. With the OEE Block, the focus is on the core OEE calculation logic. And data preparation should be done in Analytics Builder.
- No support for shift plans - the Cumulocity OEE App allowed the definition of shift plans that affected the OEE calculation. It also provided an API to integrate shift plans from external systems. With the OEE block, this is no longer supported but it is possible to use Analytics Builder functionality to affect OEE calculation based on shift plans.
- No support for production plans - the Cumulocity OEE App allowed the definition of production plans that affected the performance calculation of OEE. At the moment the OEE block only supports a fixed ideal cycle amount that is configured at build time of the Analytics Builder model. It is planned to provide functionality to set the ideal cycle amount via a block input which would enable users to dynamically change the production plan.
Installation
For End Users (Recommended)
You can download the latest release and install it using the Cumulocity Analytics Management extension.
For Developers
Alternatively, you can clone the repository or download a release to your computer. The OEE block is available from GitHub - Cumulocity-IoT/oee-block.
To add this block to a tenant, you will require:
- A copy of the block-sdk github repo
- A local install of Apama - Community edition - full version.
- A Cumulocity tenant with a suitable apama-ctrl microservice subscribed (custom blocks are not supported with apama-ctrl-starter).
Installation Steps:
Apama/bin/apama_env
./apama-analytics-builder-block-sdk/analytics_builder build extension \
--input oee-block/src/ --name oee\
--cumulocity_url https://$TENANT/ \
--username $USERNAME --password $PASSWORD --restart
Create Analytics Builder model to calculate OEE
Let us now create an Analytics Builder model to calculate OEE for a machine. A good starting point is the Normal #1 simulator from the oee-simulators project, which produces the following data:
-
Availability: the simulator produces an
Availability
event which has a fieldstatus
that is eitherup
ordown
. This event is produced 5-10 times per hour with 90% beingup
. -
Performance: the simulator produces an event
Piece_Produced
. The event is produced about 25 times per hour. -
Quality: the simulator produces a
Piece_Ok
event. The event is produced about 20 times per hour. Those events follow a few seconds after a correspondingPiece_Produced
event (both events have the same timestamp). SomePiece_Produced
events are not followed by aPiece_Ok
event (to simulate a piece with bad quality).
With this data available, we should connect the following inputs of the OEE block
-
Machine Status to logic evaluating the status field of the
Availability
event -
Amount to logic counting the
Piece_Produced
events -
Amt Ok to logic counting the
Piece_Ok
events
Step 1 - Data input
Note that Analytics Builder will by default reject incoming data that is older than 1s. If this happens, the apama-ctrl log will contain messages like this:
[correlator] 2024-11-29 14:21:31.100 WARN [140470856648256] - apama.analyticsbuilder.blocks.cumulocity.DroppedEventsWatcher [99] Number of events dropped are 58
In this case, the OEE block will not receive data and not calculate OEE. To solve the issue, ensure that data arrives without delay and if necessary increase the timeout:
With OEE block, it is also safe to enable “Ignore Timestamp” on the input blocks, as the block handles time separately from the Analytics Builder clock.
Step 2 - Block configuration
Reading the description of the simulator above carefully tells us that it produces 25 pieces per hour, so configuring it to calculate OEE once per hour with an ideal piece count of 25 probably makes the most sense:
Step 3 - Availability calculation
Next, for availability calculation, the Machine Status input should be connected. It expects a Boolean input, so the Availability
event cannot be used directly. Instead we first have to extract the value from its status
field (using the Extract Property block) and compare its value to up
(using the Expression block) to determine if the machine is running or not. The result should look like this:
Step 5 - Performance calculation
For performance calculation, the OEE block expects to receive piece counts on it Amount input. As we receive Piece_Produced
events for every single produced piece, we need to convert each event into a count of a single piece. This is achieved using the Constant Value block:
Step 5 - Quality calculation
Quality calculation follows the same pattern as performance calculation, but using the Piece_Ok
events connected to the Amt Ok input:
Step 6 - Connecting to output
As a last step, the outputs of the OEE calculation should do something meaningful. In our case, we want to write OEE, availability, performance, and quality as measurements on the original device. For this purpose, the corresponding outputs of the OEE block can be connected directly to the value inputs of Measurement Output blocks. The timestamp output should be connected to the time input of the output blocks to ensure that the calculation is associated with the correct interval. The result should look like this:
More examples
Additional examples on how to use the OEE block are available in the User Guide - Advanced Scenarios.
How to contribute
If you identify a bug or want to suggest feature requests, please raise a ticket here:
If you want to contribute changes or features, please follow the instructions given in the Developer Guide.