---
pdfexport: true
alias: tutorials-lineverification
timetoread: true
glightbox: false
tutorial: full
description: "The Line Verification feature systematically verifies materials during production, triggered by shift changes or breaks. It utilizes a Maintenance Plan"
---

# Line Verification

The Line Verification feature addresses the need for systematic verification activities while a **Material** is being processed. These verifications are particularly relevant in high-sensitivity production environments, where any changes in conditions, such as operator shifts, can impact product quality.

!!! info
    - Maintenance Management is a separately licensed module required to access this feature.
    - This feature is part one of a two-part process that pairs seamlessly with the Setup and Line Clearance feature. Check out the [[tutorials-setupandlineclearance]] tutorial.

## Overview

In this tutorial, we will explore expand the following sections:

- Feature Overview – explaining how Line Verification works
- Scenario – presenting a simplified example to understand the logic
- Configuration – showing a step-by-step guide to trigger verifications on in-process **Materials**, after shift breaks and shift changes
- Execution – triggering in-process **Material** verification using the feature
- Final Notes – pointing out some additional insights and considerations

## Feature Overview

This feature is event-based and is triggered after a **Material** is tracked, ensuring that critical verification occurs while the **Material** is in-process.

The feature is implemented within the Maintenance Management module and is driven by a **Maintenance Plan** assigned dynamically through a context resolution of the Smart Table [[materialinprocessverificationcontext-st]], creating a **Maintenance Plan** Instance when a **Material** is tracked in. This plan outlines the specific verification activities required for each **Material** during processing. In this tutorial, we will explore the time based activities, triggered on shift change events.

Once a **Material** is tracked in, a **Maintenance Plan** Instance is created and remains active throughout the time the **Material** is in-process, until it is tracked out. During this window, there is the need to execute verification activities, such as inspecting equipment, recalibrating scales, and checking environmental conditions (for example, temperature or humidity).

## Scenario

To assess how this industry and production requirement is addressed by Critical Manufacturing MES, let's consider a simplified model:

- **Shift Definition**: 6 shifts covering 24 hours.
- **Facility**: General Facility
- **Area**: Area 1
- **Flow** and **Step**: General Flow with Step 1
- **Products**: Product A
- **Resources**: Resource 1
- **Service**: Service A, required by Step 1 and Provided by Resource 1
- Role

Suppose that the process at Step 1 requires the operator with the Process Verification Role to monitor the temperature and humidity of the environment whenever a **Material** is in-process, at two specific moments: when the next shift employees return from their mid-shift break, and after a shift change. There is a scheduled and automatically triggered verification requested for the material that was left in-process.

Additionally, during shift changes, the new operators are required to:

- Confirm that all necessary durables are in the correct position
- Acknowledge the materials that are currently in line for processing at Step 1.

## Configuration

Basic entities like **Facility**, **Area**, **Services**, **Products**, **Parameters**, **Resources** and **Roles** won’t be detailed.

??? info "Useful Documentation"
    - [[tutorials-howto-createfacility]]
    - [[tutorials-howto-createarea]]
    - [[tutorials-howto-createservice]]
    - [[tutorials-howto-createproductgroup]]
    - [[tutorials-howto-createproduct]]
    - [[tutorials-howto-associateservicetoresource]]
    - [[tutorials-howto-createflow]]
    - [[tutorials-howto-createparameter]]
    - [[tutorials-howto-createresource]]
    - [[tutorials-howto-createroles]]
    - [[tutorials-howto-addvaluetosmarttable]] for assigning a **Service** to a **Step** on the [[servicecontext-st]] Smart Table

There are some entities whose configurations require closer attention:

- **Calendar** and **Shift Definition**
- **Step**
- **Data Collection** and **Checklist**
- **Maintenance Plan**

### Calendar and Shift Definition

This scenario assumes the existence of a **Calendar** with a **Shift Definition** that includes six shifts, covering the full 24-hour day.

Keep in mind the correct sequence when setting this up:

- First, create the Calendar.
- Then, define the Shift Definition.
- Finally, associate the Shift Definition with the Calendar.

The following images display the general configuration settings of the **Calendar** and **Shift Definition**:

=== "Calendar"
    ![Calendar](images/lv_calendar.png)
=== "Shift Definition"
    ![Shift Definition](images/lv_shift.png)

!!! info "Useful Documentation"
    - [[user-guide-create-calendar]]
    - [[tutorials-howto-createcalendar]]
    - [[user-guide-create-shift-definition]]
    - [[tutorials-howto-createshiftdefinition]]

### Step

For a **Step** to support in-process verification, the property `Enable In-Process Verification` must be set to true under the Settings section in the details of the **Step**.

The following images display the general configuration of the **Step**.

![Step](images/lv_step.png)

!!! info "Useful Documentation"
    - [[user-guide-create-step]]
    - [[tutorials-howto-createstep]]

### Data Collection and Checklist

The Data Collection consists of gathering a sample and recording two key **Parameters**: Temperature and Humidity.

The following image displays the general configuration of the **Data Collection**.

![DataCollection](images/lv_datacollection.png)

The **Checklist** is scoped under Maintenance Management and incorporates the **Data Collection**. Since the requirements differ for each scenario, there are two distinct **Checklists**.

The Shift Break **Checklist** includes two items, each corresponding to the collection of one **Parameter**: temperature and humidity.

The following images display the configuration of the Shift Break **Checklist**.

=== "Shift Break"
    ![Shift Break 1](images/lv_break_checklist_general.png)
=== "Item 1 - General Data"
    ![Shift Break 2](images/lv_break_checklist_1g.png)
=== "Item 1 - Data Collection"
    ![Shift Break 3](images/lv_break_checklist_1dc.png)
=== "Item 2 - General Data"
    ![Shift Break 4](images/lv_break_checklist_2g.png)
=== "Item 2 - Data Collection"
    ![Shift Break 5](images/lv_break_checklist_2dc.png)

The Shift Change **Checklist** contains four items:

- The first two are the same as in the shift break case, capturing Temperature and Humidity data.
- The remaining two require the operator to verify:
    - That Durables are in the correct position.
    - The status and acknowledgment of Work In Progress materials queued at the step.

The following images display the configuration of the Shift Change **Checklist**.

=== "Shift Change"
    ![Shift Change 1](images/lv_change_checklist_general.png)
=== "Item 1 - General Data"
    ![Shift Change 2](images/lv_change_checklist_1g.png)
=== "Item 1 - Data Collection"
    ![Shift Change 3](images/lv_change_checklist_1dc.png)
=== "Item 2 - General Data"
    ![Shift Change 4](images/lv_change_checklist_2g.png)
=== "Item 2 - Data Collection"
    ![Shift Change 5](images/lv_change_checklist_2dc.png)
=== "Item 3 - General Data"
    ![Shift Change 6](images/lv_change_checklist_3g.png)
=== "Item 4 - General Data"
    ![Shift Change 7](images/lv_change_checklist_4g.png)

!!! info "Useful Documentation"
    - [[create-data-collection]]
    - [[tutorials-howto-createdatacollection]]
    - [[user-guide-create-checklist]]
    - [[tutorials-howto-createchecklist]]

### Maintenance Plan

For this scenario, we will define a single **Maintenance Plan** of scope In-Process Verification. The associated maintenance activities must use a time based schedule type, allowing us to leverage the "On Shift Change" time due scale to implement the intended logic.

The following image displays the configuration of the **Maintenance Plan**.

![Maintenance Plan](images/lv_maintenance_plan.png)

Maintenance Activities Overview:

| Maintenance Activity Order | Trigger                                   | Duration               | Due Window                                                          | Tolerance                                                                                                           | Activity                                           |
|----------------------------|-------------------------------------------|------------------------|---------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|----------------------------------------------------|
| Shift Break Verification   | Halfway through the shift (offset of 50%) | 3 minutes (0.05 hours) | Must be completed 15 minutes (0.25 hours) after the mid-shift break | Cannot be performed before the halfway point of the shift, but can be completed anytime within the 15-minute window | Perform Shift Break Checklist and Data Collection  |
| Shift Change Verification  | When the shift changes                    | 6 minutes (0.1 hours)  | Must be completed 15 minutes (0.25 hours) after the shift change    | Early or late completion allowed within a 15-minute window                                                          | Perform Shift Change Checklist and Data Collection |

The following image displays the configuration of the Shift Break Verification maintenance activity.

=== "General"
    ![Shift Break General](images/lv_sb_general.png)
=== "Schedule"
    ![Shift Break Schedule](images/lv_sb_schedule.png)
=== "Execution"
    ![Shift Break Execution](images/lv_sb_execution.png)

The following image displays the configuration of the Shift Change Verification maintenance activity.

=== "General"
    ![Shift Change General](images/lv_sc_general.png)
=== "Schedule"
    ![Shift Change Schedule](images/lv_sc_schedule.png)
=== "Execution"
    ![Shift Change Execution](images/lv_sc_execution.png)

To connect all elements of the configuration, the system uses the Smart Table [[materialinprocessverificationcontext-st]]. In this table, it is defined:

- The **Step** (which must have In-Process Verification enabled)
- Optional context variables to refine applicability
- The corresponding **Maintenance Plan** to be triggered when the **Material** is tracked-in at that **Step**

The following table displays the Smart Table configuration.

| Step   | Maintenance Plan                 | Owner Role           |
|--------|----------------------------------|----------------------|
| Step 1 | Standard In Process Verification | Process Verification |

!!! info "Useful Documentation"
    - [[tutorials-howto-assignrolestouser]]
    - [[tutorials-howto-addvaluetosmarttable]] for assigning a **Maintenance Plan** to a **Step** on the [[materialinprocessverificationcontext-st]] Smart Table
    - [[user-guide-create-maintenance-plan]]

This is the [Master Data file](masterdata/lineverification_tutorial.xlsx) used to create this model.

## Execution

After all configurations are completed, the operation that sets everything in motion is the Track-In of a **Material** at a **Step** where in-process verification is enabled.

Once the **Material** is tracked in, navigating to the Material Maintenance View will display its Maintenance Plan Instances, as illustrated in the image below.

=== "Shift Change"
    ![Shift Change Execution](images/lv_maintenance_view_sc.png)
=== "Shift Break"
    ![Shift Break Execution](images/lv_maintenance_view_sb.png)

In the example, the **Material** was tracked in at 04:55 PM.

The next shift begins at 06:00 PM, so two Maintenance Activity Orders are created:

- One with a due date at 06:15 PM PM, for the Shift Change Verification
- Another with a due date at 08:00 PM, for the Shift Break Verification

If the due time arrives and the **Material** is still in process, the verification must be performed.

If a user attempts to Track-Out the **Material** without completing the required verification, the system will notify them about the pending In-Process Verification Maintenance Plan Instance.

Refer to the diagram below for a clear, visual timeline of these events.

![alt text](diagrams/lv_timeline.drawio.svg)

The operations required to carry out these verifications follow the standard Maintenance Activity Order flow: Begin, Perform, and Complete.

The video below illustrates the execution of this scenario.

<!-- Video filename: lv_tutorial.mp4 -->
{% set video_id = 'f9d81c3584a613533a382888aaa3f08a' %}
{% include-markdown 'includes/cloudflare_stream.md' %}

!!! info "Useful Documentation"
    - For a more in-depth understanding of this module, please refer to the [[tutorials-maintenancemanagement]] tutorial.

!!! note
    - The Material Traceability View includes a dedicated section to accommodate In-Process Verifications.
    - The **Material** `In-Process Verification Maintenance Plan Instance` the reference to the associated instance.

## Final Considerations

Keep in mind the following behaviors and consequences related to the In-Process Verification Maintenance Plan Instance:

- Terminate / Abort **Material** - Terminates the instance and clears the associated property
- Split / Expand **Material** - Resets the instance in the resulting child materials
- Merge **Material** - Merge is blocked if any of the Materials involved have an active instance
- Track-In **Material** - Creates a new Maintenance Plan Instance based on the resolved **Maintenance Plan** from the In-Process Verification context of the **Material**; sets the In Process Verification Maintenance Plan Instance accordingly
- Track-Out **Material** - Validates the Maintenance Activity Orders associated with the instance; if validation passes, terminates the instance and clears the property