The OEE Equipment Monitor Setup
A lot of data is taken into account for OEE calculations as well as contextual information, which makes the results more understandable. This data is provided by a number of objects in the I/O Model. When the OEE Equipment Monitor is configured, it needs to be pointed at these data objects. This is done by reference properties whose names generally end with 'Input'. Some of these inputs are mandatory, some are optional. It is highly recommended that you familiarize yourself with all of these inputs and (on your production system) configure as many as possible, even if they aren’t mandatory. The more inputs you provide, the better the result will be.
Go to the ISA-95 Equipment Model and select the asset for which you want the OEE indices to be calculated; in our example, this is 'The OEE Demo Cell'. Right-click on this object and selectto open the Create Equipment Monitor wizard which we will now go through step by step.
In the Common section, give the new object a suitable name and, optionally, add a description of the object’s function.Figure 2. The Common Section
For initial setup and all later configuration changes, the Processing Mode should be set to 'Configuration'. Setting this to 'Production' starts the OEE calculation.
Click Create to create the OEE Demo Equipment Monitor in the ISA-95 Equipment Model.
The new OEE Equipment Monitor object will appear underneath the cell for which we created it.Figure 3. The new OEE Equipment Monitor in the ISA-95 Model
To continue with its configuration, select the newly created OEE Equipment Monitor object in the ISA-95 Model and in the Property Panel expand the Configuration Options property compound.
The Configuration Options can link to specific OEE Configuration Objects. If no link is provided, the OEE Equipment Monitor will traverse the ISA-95 Model tree upwards and will use the first configuration object of each type, that it can find.
Traversing the ISA-95 Model tree in search for Configuration Objects may affect performance and should only be used to find Configuration Objects which are located in close proximity.
Configuration Objects which are further away from the OEE Equipment Monitor should be configured explicitly.
If no Configuration Object of this type is to be used, the corresponding Configuration Object Source property should be set to '/' to prevent the search.
At this time, set all Configuration Object Source properties to '/'.Figure 4. Preventing the automatic search for Configuration Objects
To get the most precise OEE in a production environment, this environment should be defined as precisely as possible in the Configuration Objects. This will be addressed later when we are Adding Configuration Objects but for this basic OEE example, Configuration Objects are not necessary.
For information regarding the individual properties refer to the Processing Options property compound.
This section defines how OEE Calculations are triggered and if (and how) Interim OEE Indices are calculated.
The Trigger Source property in the Trigger Options property compound of the Processing Options defines which logic is used by the Equipment Monitor to identify the start and end of a production run, and therefore HOW the OEE Calculations for a production run are triggered. See the Trigger Options for information on all the available options.
|The Trigger Source is a critically important setting, since it determines how accurately the OEE monitor will be able to detect the start and end of a production run. This value should not be changed while a production run is in progress.
|In general, OEE Calculations are triggered by a change of the value of an object in the I/O Model. As mentioned above, the OEE Equipment Monitor has a number of 'Input' properties which are used to reference a number of objects in the I/O Model. The specific 'Input' property (and therefore referenced object) used to indicate start and end of production runs depends on the selected option for the Trigger Source property. Since triggering OEE Calculations is a secondary use case of these 'Input' properties, they will be configured later in this document, in the context of their primary use case.
If there is an object in the I/O Model which holds the information on the current state of the monitored equipment, using the equipment state as the trigger for the OEE Equipment Monitor is the preferable option.
The OEE Simulation provides such an object ('OEE Simulator / Equipment State') so we will use this Trigger Source option for this example. The reference to this object will be configured later, in the Equipment State Input property of the Equipment State Options inside the Performance Options.
For the Trigger Source property, select the 'Equipment State Mapping' option, and in the State Trigger Options section, click on the table icon for the State Trigger Assignment property.Figure 5. Trigger Condition: Equipment State Mapping
For the first empty row in the 'State Trigger Assignment' configuration table, select the 'Starting' option from the drop-down list in the 'Equipment State' column and select 'Production Start' in the 'TPM Trigger Category'.
In the second empty row, select 'Complete' for the 'Equipment State' column and map it to the 'Production Finish' option in the 'TPM Trigger Category' column.Figure 6. Trigger Condition: State Trigger Assignment
Click OK to close the dialog.
Processing Time Basis and the Calculation Extensions property compound provide configuration options for interim OEE Calculations during the production run. For this example, we leave these properties on their default values. For more information on these properties, see Processing Options property compound.
For information regarding the individual properties see the Measurement Options property compound.
In the Measurement Options the unit of measurement can be provided as context information for the Production Runs table. This information is optional and does not affect the OEE calculation.
The Performance Measurement Type specifies if Discrete Units are to be counted or Volume or Mass to be measured. Depending on the selection here, individual options allow the unit in which the product which is produced on this asset is measured to be specified. For the example, leave these options as the default settings.
For information regarding the individual properties see the Availability Options property compound.
The Availability Options inform the OEE Equipment Monitor about the planned availability of the asset. The default value is 'Continuous Availability (24/7)' but it can also be set to 'Shift Regime', which means there is a more detailed availability configuration, defined in a specific TPM Shift Configuration Object.
The setting of the Availability Type affects how often the overall/Top OEE is calculated.
|Default OEE Calculation Time
The equipment regarded as available all the time (24x7).
End of day
The equipment regarded as available all the time (24x7) except during “Not Scheduled” and “Unscheduled” time. The Shift definitions, if defined, are ignored
End of day
The equipment is regarded as available only during defined shift times which are outside of “Not Scheduled” and “Unscheduled” times.
End of Shift
The Overall OEE Calculation Recurrence can be used to override the Default OEE Calculation Time, which depends on the selected Availability Type as shown in the table above. If set to '<null>', the default behavior applies.
|The Availability Options have no influence on the OEE calculations for equipment stops which are marked as "IsScheduled". In this case, this period is ignored for the OEE calculations.
For this example, leave the Availability Type on its default value 'Continuous Availability (24/7)' and the Overall OEE Calculation Recurrence on '<null>'.
For information regarding the individual properties see the Quantity Options property compound.
The Quantity Options link the OEE Equipment Monitor to the objects in the I/O Model which hold the current quantity data for the production. In other words, these fields tell the monitor how much was produced and possibly rejected.
Some - but not all - of the inputs need to be configured. Different combinations are possible. For the effects of the different combinations see Quantity Options property compound.
For this example …
Add the Total Quantity Input. To do this click the … icon for this property, expand the I/O Model tree and select the 'QuantityTotal' variable object from the OEE Simulator, then click OK to confirm your selection and close this dialog window.Figure 10. Selecting the Total Quantity Input
Then add the Good Quantity information: Check the checkbox for Good Quantity Available and select the Good Quantity Input in the same way as the Total Quantity Input.Figure 11. The Quantity Configuration with the Quantity Inputs selected
|If The Trigger Source property of Trigger Options compound in the Processing Options is set to 'Quantity Drop', any drop of a value of any of the objects referenced in the Quantity Inputs (which are also set as 'available') is regarded as the start of a new production run and triggers the calculation of the OEE indices.
For information regarding the individual properties see the Performance Options property compound.
In the Performance Options property compound, the key values regarding the equipments’s performance are configured. This is divided into three subsections, where Product Options define the ideal output numbers for the OEE calculation, Equipment State Options configure how changes in the equipment state affect the OEE and Equipment Failure Options define how the OEE is influenced by error messages coming from the equipment.
For information regarding the individual properties see the Product Options property compound.
In the Product Options section, the ideal production outputs are defined. Product specific values can be entered in a table and default values provided, if the product can not be found in this table.
The Search Target property defines whether the product name or the product code will be used to specify the product currently produced. For this example, leave it on 'Product Name'.
The actual information which identifies the current product, has to be provided by an object in the I/O Model. To connect the OEE Equipment Monitor to this object, it has to be selected as the Product Input. Click on the … icon for this property, select the object ('Product' for this example) from the I/O Model and confirm your selection by clicking OK.Figure 13. Selecting the Product Input
Next, click on the 'table' icon for the Product Configuration property to open the Product Configuration table. For each product defined in the OEE Simulator script, add a line, entering the values for 'Product Name' and 'Performance' from the 'Product Database' section of the script.
Alternatively, if the selected Product Input is configured to provide them, product codes can be used to identify the products. These then need to be specified in 'Product Code' column of this table and the Search Target property needs to be set to 'Product Code'.Figure 14. The Product Configuration Table
Click OK to close the table.
Default Performance, Default Quantity Multiplier, and Default OEE Target will be used as fallback values, if the current product can’t be found in the Product Configuration Table. Then OEE Top is calculated, based on these values, instead of OEE which is based on the product-specific values. These properties should be configured for a production environment but for this example, they can be left empty.
For information regarding the individual properties see the Equipment State Options property compound.
To be able to consider the state of equipment in the OEE calculation, the OEE Equipment Monitor needs to be linked to an object in the I/O Model which can be used as the Input for the current state of this equipment. This state has to codified according to the EquipmentStates Coding Group.
Set the Equipment State Input in the same way as the previous Inputs. For this example, link to the 'Equipment State' object of the OEE Simulator.
If 'Equipment State Mapping' is configured as the Trigger Source in the Trigger Options compound of the Processing Options, the object referenced in this input will be used to trigger the OEE calculation for a production run.
The system uses Equipment States according to the ISA-88 specification. To be useful for the OEE Monitor, these status codes need to be translated into the corresponding TPM Time Categories. This translation is configured in the State Time Assignment table.
Click on the table icon for the State Time Assignment property.Figure 16. Opening the State Time Assignment table
In the table, add a line for each state which is to be mapped. In each line, select the Equipment State and the corresponding Time Category from the respective drop-down lists.Figure 17. Selecting the Equipment State
For our example, set the State Time Assignment table to match the following configuration:Figure 18. The State Time Assignment table for the example
These settings look very similar to those for the State Trigger Assignment property which we already configured in the section on the Processing Options. The key difference is that the State Time Assignment settings relate to the way “run-time” is calculated while a production run is in progress, while the State Trigger Assignment settings control the start, end and reset triggers for a production run as a whole.
Then click OK to close the table display.
If only the Equipment State and Time Category is configured, Equipment State changes have no effect on the calculation of OEE but are recorded as context data in Production Runs table, column 'Internal Data'.
For the Equipment State Changes to be taken into account in the calculation of the OEE indices, the Stop Reason or Custom Stop Reason must to be configured. Their Stop Classification determines how they affect OEE.
The following table describes how the various options affect the OEE calculation:
|Effect on OEE
affects all OEE calculations
does not affect any OEE calculation
does not affect the calculation of OEE Solitaire
does not affect the calculation of OEE Solitaire
The Stop Classification for a Stop Reason is best configured in the Stop Reason Classification object which is specified in the Monitor objects Configuration Options > Stop Reason Configuration Source property but can also be specified in the 'Stop Classification' column of this table. Stop Classifications specified in the State Time Assignment table have precedence and therefore override the Stop Classifications configured in the Stop Reason Configuration object. If no Stop Classification is configured for a Stop Reason at all, it will be classified as 'Failure'.
If both the Stop Reason and Custom Stop Reason are configured in the State Time Assignment table, the Custom Stop Reasons will be taken into account unless the specified Custom Stop can not be found. In this case, 'Stop Reason' will be used as a fallback.
In case of duplicate entries, the first matching entry will be used.
For information regarding the individual properties see the Equipment Failure Options property compound.
Equipment errors also correspond to equipment stops. These stops are treated in a similar fashion as stops which are identified by Equipment State changes.
When the equipment monitor is running, it will detect stops, which are then recorded in the “Equipment Stops” table, by tracking error code or failure inputs. The stops recorded in this way will initially be assigned a “0 - No Reason” code, until an operator provides the actual stop reason. This manual step can be avoided, provided the machine being monitored emits sufficiently detailed error codes that can be directly associated with the defined Stop Reasons.
For a stop reason to be automatically assigned to a failure reason, the corresponding error code needs to be mapped in the OEE Equipment Monitor configuration.
Failures can be signalled to the OEE Equipment Monitor object in four different ways: by an error flag, an error code, an error message or an OPC A&E message. For this example, we select the Error Code variable, which the OEE Simulator script sends out in case of failure, from the I/O Model as the Equipment Error Code Input property.Figure 19. Selecting the Error Code Input
Automatic Stop Reason assignment is configured in the Equipment Error Stop Reasons table property. To do this, click on the table icon for this property.Figure 20. Mapping Errors to Stop Reasons
Add a new row to the table by clicking the + icon.Figure 21. The Equipment Errors Stop Reasons Table
In the 'Source' column select the criteria which identifies the error from the drop-down list. For this example select 'Error Code'.
Leave the 'Function' column as 'Equal'.
In the 'Value' column set the error code which you want to map to the stop reason, using '1' for this example which is based on the OEE Simulation Script.
To map the error code to a (Userdefined) Stop Reason, enter the ID of the Stop Reason to be used in the 'Stop Reason' column.
In the Stop Reason Configuration object, Built-in as well as Userdefined Stop Reasons can also be customized.
If you intend to map an error code to such a (Userdefined) Custom Stop Reason, enter the ID of the respective reason in the 'Custom Stop Reason ID'. To refer to the IDs of (Userdefined) Custom Stop Reasons, open the corresponding Stop Reasons table next to the Equipment Errors Stop Reason table.
The 'Custom' column has precedence over the 'Stop Reason' column. If the value for the 'Custom Stop Reason ID' is '<null>', the error will be mapped to the reason identified by the ID provided in the 'Stop Reason' column.
Click OK to confirm and close the dialog and Apply the changes to the properties.
For information regarding the individual properties see the Context Options property compound.
These options define from which objects in the I/O Model contextual information for the production run is retrieved.
Our example is running a batch production, so we provide a link to the BatchID Input by clicking on the … icon …
... selecting 'Batch ID' from the OEE Simulator in the I/O Model tree and clicking OK to confirm the selection and close the object picker window.
|If the Trigger Source property of the Trigger Options compound in the Processing Options is set to 'BatchID Changed', a change of the value of the object referenced in the Batch ID Input is regarded as the start of a new production run and triggers the calculation of the OEE indices.
For information regarding the individual properties see the Preset Options property compound.
These Options define a standard configuration for objects which are eventually created by the OEE Equipment Monitor.
In most use cases, like in this example, these settings should be left on their default configuration.
|If the OEE Equipment Monitor is running underneath a Local Core, Index Presets / Archive Options / Archive Selection and Big Table Preset / Big Table Data Store should point to data stores of this Local Core instead of the system data store of the Master Core.
For information regarding the individual properties see the Aggregation Options property compound.
The OEE Calculations of multiple OEE Equipment Monitors can be aggregated on the different levels of the business structure.
|So far our example only uses a single OEE Equipment Monitor, therefore aggregation would be useless. If you set up a second OEE Simulator and a second monitor configured for this second simulation, you can also configure OEE Aggregation as described here and see it at work.
When OEE Aggregation is initially triggered, an 'OEE/Aggregation' folder structure will be created for all business structure objects which are in the ISA-95 Equipment Model above the OEE Equipment Monitor - up to the Enterprise level.
Underneath these structures, individual sub-folders will be added for the configured Integration Scopes (see below) on the initial aggregation for this scope. In these scope-specific sub-folders, OEE Index objects will be created for the aggregated Availability, Performance, Quality and OEE indices which host the aggregated OEE data of all the OEE Equipment Monitors in this sub-tree of the business structure.
The OEE Integration Scope property compound defines how often OEE data is aggregated.
If a system has 2 OEE Equipment Monitor objects, one having 'Hour' as the Integration Scope, and the other one 'Day', an 'Hour' aggregation node and a 'Day' aggregation node would appear in the OEE folders of all the business structure objects above these monitors but no real aggregation would happen since both monitors don’t have common Integration Scopes.
|For Shift aggregation,
only OEE data from OEE Equipment Monitor objects which use the same xref:jumpstarts:using-oee:oee-configuration-shift.adoc[Shift Configuration object, window="_blank"] is aggregated.
For information regarding the individual properties see the Stop Reason Filter Options property compound.
The Stop Reasons Filter Options are used to restrict the options which will be available in WebStudio when annotating stop records with stop-reason codes.
The system has a number of built-in reasons for equipment stops, which may be assigned to stops in the OEE Equipment Stops table. By default all stops affect the calculation of the OEE Indices. This behavior can be overridden in Stop Reason Configuration Objects. Also Custom Stop Reasons can be defined there.
NOTE: Micro stops don’t affect the Availability Index, but rather the performance metric.
In the Stop Reason Filter table, ranges of Stop Reasons, which will be made available in WebStudio, can be specified.
|If no range is specified in this table, all defined Stop Reasons will be available in WebStudio. If at least one range is defined in this table, only the Stop Reasons which are included in the specified range(s) will be visible.
To add a range of Stop Reasons, follow these steps:
In the Stop Reason Filter Options, click on the table icon for the Stop Reason Filter property to open the Table Property Grid.
In the Table Property Grid, click on the + icon to add a new line to the Stop Reason Filter table.
In this new line, enter the ID of the first Stop Reason of such the range in the 'Stop Reason From' column.
Enter the ID of the last Stop Reason of this range in the 'Stop Reason To' column.
Click OK to close the Table Property Grid.
Finally, Apply the changes to the properties.
The Custom Stop Reason Filter property is used to define filters on the attribute fields of custom stops reasons. When editing the stops reasons in WebStudio, all available reason codes and custom stop reasons are presented to operators for selection.
It may however be that some stop-reasons only apply to certain machines, which is indicated by setting one or more of their attributes to the machine type or model or make for example.
The set of custom stop reasons presented to users in WebStudio can be controlled by defining filter expressions. Each row in the configuration table is set to contain strings that should match with corresponding attributes. A reason is included if any of the row expressions match. For example, suppose we want to return all custom reason strings where (attribute1 == “X” and attribute2 == “Y”) or (attribute1 == “Z”). This would be accomplished with the following settings in the filter table:
|Custom Filter 1
|Custom Filter 2
|Custom Filter 3
The 'Custom Filter' columns correspond to the 'Custom Attribute' columns of TPM Stop Reason Configuration objects. If the defined Custom Attributes match the corresponding Custom Filters, the Stop Reason will be visible.
|Custom Stop Reasons Filters are additive to the Stop Reason Filters. This means that Custom Stop Reasons will be included in the list of visible Stop Reasons if they are included in the Custom Stop Reason Filter - even if they fall within a range which is NOT included in the Stop Reason Filter.