Best practices when setting up context item types/fields/workflows.
When it comes to defining best practices for contextualizing events in TrendMiner, it is important to understand some key elements used in ContextHub:
Context items -> A context Item is a block of information linked to a data point or a period of data associated with an event identified in your datasets. Instead of writing a note in a book, add your thoughts and observations to a context item.
Context item type -> Categories that provide meaning to context items. For example: "shutdown" type // "maintenance" type // "Operating" type, etc.
Workflow -> Is the path or the states that an event of a certain type will follow. For example: Start and end (event with duration) // Without states (start and end occur simultaneously at a timestamp).
Context item field -> Use this option to add structured metadata to context items in the form of parameters. For example:
For batch records, context fields like; product type, input feed and final concentration.
For maintenance activities, context fields like; “planned/unplanned”, “long/short”.
This document will explain how and in what order you should configure each element to establish the overall system with ContextHub, using a practical example.
Anmerkung
This is done with admin rights, via the configuration window of ContextHub.
 |
We want to create a system where all asset shutdowns in a process are contextualized. For each asset, we have independent sensors that describe the states "Running/Stopped".
Additionally, we want to classify the shutdowns as "Planned/Unplanned", which is important for the monthly review and decision-making by the maintenance team. The evaluation is done by the process expert when a shutdown occurs and will be noted manually.
The context items/events are associated with a context item type. The context item type used is "Shutdown". Multiple context items corresponding to this type will be created, whether planned or unplanned.
These events have a start and an end. To facilitate this, we need to ensure that there is a workflow with the states "start" and "end", associated to the Context Item type – “Start and states workflow“, by default in TM.
Finally, we need to define the extra categories that we want to be able to identify for this context item type. In this case, whether the shutdown was planned or unplanned.
In summary, the preliminary steps to implement the ContextHub system are:
Verify that a Workflow exists or create one -> In this use case, with a start and an end.
Create the extra characteristics or context fields that we want to attribute to the context item type -> In this use case, "planned/unplanned".
Create the context item type, with created workflow and the defined extra characteristics -> In this use case, "shutdown" context item type, associating it with the workflow “start and states” and the context field of "planned/unplanned".
A toggle button can be activated so that the state of the context field is displayed in the Gantt Chart, created later.
Once the previous steps are completed, end users can use the Context Item Types and Context Fields for their daily use.
In this case, create a search with an associated monitor, eg:
Value-based search with a shutdown for more than X minutes.
In this monitor, the context item type "shutdown" will be specified. The context field "planned/unplanned" will be left blank, as it will be manually filled in afterwards.
 |
When a shutdown occurs, it will appear in the Gantt Chart or table created in ContextHub.
Consequently, the process expert can click and edit the context item. In the edit menu, all associated context fields will appear. The process expert will select the "planned/unplanned" context field and mark the corresponding option in each case, thus recording the nature of each shutdown according to the context and his criteria.
Color formatting can be added to differentiate between different types of shutdowns in a more visual and direct manner.
Once the generic process has been explained, the following recommendations are suggested for the most efficient use of these contextualization elements:
Keep context item types general: Aim to keep your types as general as possible so that they can be reused for other similar processes.
Customize them for specific use cases by setting fields rather than creating specific context item types.
For example, have a Context item type "shutdown" with context fields such as "planned/unplanned", "short/long", "root cause", "Line". By doing this, context fields can be attached to multiple context item types, reducing the need for multiple types.
Keep context item types simple: Use start/end workflows or no workflow at all for simplicity.
Use dropdown lists over free string fields: to minimize typos.
Avoid redundant information: Ensure that your final context items do not contain redundant information. For instance, if you're already attaching items to a certain component, avoid adding a field that specifies the component in some way.
Utilize Enumeration Fields for Workflow Tracking: Use enumeration fields to guide context items through a series of calls to action. For instance, you can employ a monitor to create context items for anomalies with a default field value of "to be investigated." Subsequently, this field value can be updated to reflect stages such as "under investigation," "investigated," or "ignored." This approach facilitates the tracking of context items across workflows for engineers or operators.
Ensure clear and distinct context type names: Make sure context type names are well-differentiated to prevent confusion. Check existing names before creating a new type to avoid duplication. Avoid generalized names; for example, don't create a context type named "Batch" if it doesn't apply to all batch processes in your plant.
Grant admin rights to key users: Provide admin rights to key users so they can manage these elements without relying on IT admins, streamlining the process and increasing efficiency.
