Batch Tracking

Production events associated with Batch production are tracked in inmation using the Batch Tracker object. The Batch Tracker can create, archive and modify Batch Production Records by tracking production events and automatically contextualizing the data depending on its configuration.

Each Batch Tracker can be mapped to a particular piece of equipment in the ISA-95 Equipment model. Batch Characteristics can then be configured to individual data items in your I/O model. These Batch Characteristics are mapped to particular Batch Production Record attributes, as defined in the ISA-88 standard. The Batch Tracker will react to all production events and create/update the Batch Production Record automatically.

Batch Tracker Overview
Figure 1. Batch Tracker Overview

Basic Function

The Batch Tracker is a simple automated document writer; all content of the produced document is either taken from the configuration or from input data. The resulting document produced is known as a 'Batch Production Record' (BPR). Similar to a book or an article, these resulting documents can be broken down into sections such as chapters, paragraphs and sentences. In the 'Batch Production Record', these are called "Operations", "Equipment Phases" and "Equipment Steps" according to the ISA88 terminology. The digital equivalent of the Batch Production Record is referred to as the Electronic Batch Record (EBR).

These different configuration objects define how the document shall be written. During this writing process, there are two things to consider:

  • what data shall be included in the individual Batch, Operation, Eq.Phase, Eq.Step.

  • what data shall be used to identify the BatchStart, Operation, Eq.Phase or Eq.Step.

Therefore, the Batch Tracker monitors several input channels (from objects in the Model Panels) and reacts to changes of individual values in a highly configurable manner.

The most important part is to identify the Batch Start and Batch End. These "events" provide the frame for each Batch Production Record.
The second most important thing is to identify the Electronic Batch Record (EBR) (for example, a BatchId) so that the resulting document can be found in the database later. For a system where the EBR is not uniquely identified by the BatchId, there are further configuration possibilities.

If the Batch Start, Batch End and Batch ID are configured, then the Batch Tracker can be set into Production mode and be operational. During its runtime, this object holds not only the configuration on batch level, but it also holds the current state for tracking, as well as the current state of the compiled tracking document.

As mentioned before, the configuration object defines which content shall be collected in the resulting document. The main section for this collection is the "Properties" section, where the different properties for the EBR are defined. The various configurations allow different uses of the information, as well as many different means of pre- or postprocessing of the data. For a simple start the following settings are sufficient.

  • Label: <some name>

  • EU Overwrite: ""

  • Input: <path of the object to monitor>

  • Target Field: "Custom Measurement"

  • B2MML Data Type: "Default"

  • Field Processing: "Direct"

  • Data Collection: "Time Series (Distinct)"

  • BPR Element: "Default"

  • Report Order: 1

This will resample the given input at 1/s intervals and collect the changes of that input. If this input has a specific meaning (e.g. it provides the BatchId) then the TargetField setting must be changed to assign the specific meaning to this input. This however, does not change the recording of the property, the specific meaning just comes on top. Additionally, different types of preprocessing can be configured with the Field Processing setting. If the data won’t be collected as a time series and only "minimum", "maximum" or "average" for the given time period shall be recorded, this can be changed by configuring a different Data Collection type.

In addition to the properties, events and trends can also be configured as part of the EBR, but this will be described in their own chapters.

As explained above, the EBR as a document has a structure, which also includes Operations. The generation can be configured in a Batch Operation Object below the Batch Tracker object. These operations can have their own characteristics, events and trends exactly the same way as a Batch can have. In the same way that a book can have multiple sections, an EBR can have multiple operations and for each operation, there can be an individual configuration.

Operations are identified by OperationID or OperationName, so each configuration is given a unique OperationID or a unique OperationName, which must be configured as properties on Batch level.

In addition to the distinct Operations, it is also possible to provide a configuration which will be applied for all operations, independent of their OperationID or OperationName. This also allows provision for "unexpected" Operations, which could not be foreseen and therefore not be configured beforehand.

Even if an operation occurs, where no configuration is present, this will still be recorded, but no specific properties, events or trends will be included.

In general, changes in the OperationID or OperationName start a new operation, unless both change to a nil value. If both are nil, this will lead to a gap between operations.

In order to structure the Operation further, Equipment Phases can be defined. They behave exactly like Operations but provide an additional level of detail. Equipment Phases can be further divided into Equipment Steps and behave exactly like Equipment Phases. All together a Batch Production Record consist of:

  • The Batch (Start, End, BatchID, EquipmentID, characteristics, trends, events)

  • The Operations (start, end, Name/ID, characteristics, trends, events)

  • The Equipment Phase (start, end, Name/ID, characteristics, trends, events)

  • The Equipment Step (start, end, Name/ID, characteristics, trends, events)

Acquisition Architecture

The Batch Tracker uses the standard mechanisms of inmation to access data known to the inmation system. Therefore, it can use objects in the I/O Model, ISA95 Equipment Model or KPI Model as inputs. If the Batch Tracker is running in delayed mode, then the configured property must be stored to the data historian and the archive options must be configured. Therefore a productive archive must be selected and an Archive Strategy must be chosen (currently there is only the Archive Strategy “Raw History” available). Based on the different configuration objects for the Batch Tracker, Operation, Equipment Phase and Equipment Step, the relevant information is collected and compiled into one large JSON document. This document is sent as a custom event to the persistence layer.

In the persistence layer, the data format is transformed into a ISA88/BatchML format encoded in BSON and stored in the Production Tracking Data Store. Due to the limitations on document size and for better searchability, the original Batch Tracker document is split up into several BSON documents within MongoDB. These documents are distributed across several MongoDB collections for better searchability.

Currently the Batch Tracker does not read historical values directly for redundant items, but reads the data from the original items and does a stream merge. This workaround requires the redundant item to be used directly. If the redundant item used is an Analog Measurement within the ISA95 model, the data will not be read correctly.
Batch Tracker - Acquisition Architecture
Figure 2. Batch Tracker - Acquisition Architecture

Batch Tracker Configuration

The Configuration of the BatchTracker is split across several objects in the I/O-Model, which are described in the following documents:

Additionally there are some Advance Topics regarding the BatchTracker configuration, which deal with corner cases as well as the behavior during error.