OEE Block released for Cumulocity Analytics Builder

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 field status that is either up or down. This event is produced 5-10 times per hour with 90% being up.

  • 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 corresponding Piece_Produced event (both events have the same timestamp). Some Piece_Produced events are not followed by a Piece_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.

4 Likes