tip Crew (Shift) Based Analytics: Examples and Potential Benefits

[John Cox]

TLDR/Summary

Manufacturing companies count on rotating teams of operators (commonly called shifts or crews) to keep the process operating safely at production targets and within quality specifications. In doing so, each operating crew develops their own unique personality and operating philosophy, with preferences on how to best run the process, where to set specific targets and setpoints, how to approach equipment maintenance, how to respond to process upsets, etc. As a result, there are many potential process improvement opportunities readily identified using crew-based analytics, but these types of analytics are often overlooked. The purpose of this “Tips & Tricks” is to spark ideas and illustrate useful methods/tools for crew-based analytics. Consider how you can expand your use of crew (shift) conditions in Seeq Workbench to discover new, value-adding process insights.

 

Overview

Example categories of crew-based analytics are listed below, but there are many more possibilities:

Monitoring regulatory control use and interactions by crew (Use Cases 1-2 below show examples)

• Do some crews “over control” the process by making too frequent target (setpoint) changes, for example, too tightly controlling a tank level? 
• Do all crews similarly utilize the regulatory control loops and Advanced Process Control (APC) applications? 
   

Monitoring process performance and maintenance effectiveness by crew (Use Cases 3-6 below show examples)

• Do key process values (e.g., average reactor temperature) change significantly by crew? 
• For a given product transition, does the amount of offclass produced vary widely by crew?
• Are batch step durations similar from crew to crew? 
• Is more fuel (energy) used because crews have different preferences on a startup sequence or specify targets too conservatively during normal operation? 
• For preventive maintenance tasks on discrete production machinery, is the post maintenance “time to normal production” consistent by crew? 
• Are equipment cleaning metrics (e.g., calculated heat transfer coefficients for heat exchangers) affected to different extents by the crew doing the cleaning? 

Six use cases are illustrated below:

Note: a crew (shift) condition, with capsules spanning each crew’s work shift, is the foundation for these types of use cases. If crew work shift information is already available as a datasource signal or condition, Seeq can use these directly. As needed, simple or complex crew work schedules can be created as conditions using Seeq formula (using the shifts() function is one of several approaches). See this post for detailed examples of creating more complex crew conditions: How to create shift conditions for different types of shift schedules

 

Monitoring operating crew interactions with the regulatory control layer

 Use Case 1: Setpoint Change Magnitude and Frequency

A reactor feed setpoint is manually adjusted by operators because the reactor operation and quality are quite sensitive to throughput changes. Operators have been coached to never make changes of more than 0.75 units, and to not make any change more frequently than once/hour. The use case starts with only the reactor feed setpoint signal and the crew schedule, represented as a condition comprised of individual capsules (8 hour time periods) spanning each crew’s shift:

 

Here, the very basic "Crew Condition" was created with the shifts() and combineWith() functions in Seeq Formula. See How to create shift conditions for different types of shift schedules for detailed examples of creating more complex crew conditions.

 

The next step is to calculate the running delta of the setpoint signal values to make it easy to flag setpoint changes. This is done with the runningDelta() function, and the result is converted to a step interpolated signal to better represent the discrete nature of the setpoint changes:

 

The running delta signal (FC250.SP Delta) looks as expected and can be easily searched to flag setpoint changes:

 

In the next step we create a “SP Changes” value search for when the “FC250.SP Delta” does not equal 0, generating capsules corresponding to each setpoint change that has occurred:

 

Now that we have the inputs needed to compare the number of setpoint changes by crew, we expand our time range out to the full 1 month range we want to investigate, and visually confirm that the results look as expected:

 

We use the Histogram tool with the “SP Changes” condition, crew condition, and the FC250.SP Delta signal, configured as shown, to analyze the distribution of reactor feed setpoint changes:

 

The histogram shows that Crew 1 and Crew 2 could learn from Crew 3's approach, as Crew 3 has the fewest changes in the yellow and red bins in the histogram.

 

Now that we have monitored for changes outside the 0.75 delta limit, we next analyze for how often the 1 change per hour directive is followed by each crew. We create capsules spanning each setpoint change via the toCondition() function, and find time periods where the next change is within an hour or less by removing resulting capsules longer than 1 hour:

 

For this time period, the previous formula highlights a time where the next setpoint change occurred in under an hour (in this case, 50 minutes):

 

Using the next formula, we flag “SP Change <= 1 Hour” as any SP changes which occur within an hour of a previous change:

 

The results are accurate for this short 1 day time range:

 

As well as our longer 1 month time range:

 

We then use the Histogram tool to analyze for too frequent setpoint changes by crew:

 

While Crew 3 is doing well avoiding larger magnitude changes, the histogram reveals they could wait longer between setpoint changes, letting everything line-out before determining if additional adjustments are required. Patience is key when process dynamics are significant, and this type of analysis can be eye-opening to operations crews who may not be aware of just how many adjustments are being made.

 

 

Use Case 2: Monitoring Unit-wide Controller Usage by Crew

Regulatory control loops (PID controllers) are typically designed to be run in automatic or cascade mode, making automated compensating adjustments to keep the controller’s process value (PV) at setpoint. When controllers are switched from their intended or “normal” mode, there can be unforeseen impacts to raw material and energy consumption, product quality, or downstream equipment degradation.

To monitor controller usage (i.e., the crew running a controller in automatic or cascade mode versus manual mode), Seeq’s condition and asset group features (see Asset Groups and Asset Groups 101 for more details) are needed to create crew-specific calculations and then scale those calculations across all controllers in the unit.

With that background, this use case starts with crew-specific 8 hour shift capsules, and controller mode signal data (0=manual, 1=automatic, 2=cascade) in an asset group 8structure for the 21 controllers comprising Unit 1 of the process (refer to screenshot below). Note that each controller’s mode signal lies underneath each control loop “asset” in the Unit 1 Controllers asset group. The mode signal is trended for PC117 in lane 1. Downtime data is excluded (a critical step, see Data Cleansing Tips: Using the .remove() and .within() Formula Functions) and the weekly percent time in manual is set up as a crew-specific calculation scaled to each controller (asset), with the percentage based on the total time that each crew was on shift. The contextualized, crew specific selection of manual mode for PC117 is evident by the Manual Mode Crew 1 and Crew 2 capsules just above the signal trends:

 

The most significant calculation details are summarized below, using a weekly condition and the within(), keep() and aggregate() Formula functions. Manual mode for Crew 1 is calculated as shown:

 

The total time in manual for crew 1, as well as total on shift time (all on a weekly basis) are then calculated:

  

 

Those results are combined to calculate the weekly percent time in manual mode:

 

With the weekly percent time in manual set up as a crew-specific signal (analogous calculations are set up for Crews 2 and 3), capsules can identify when the percent time in manual is abnormally high (above 15% or above 50%, meaning controller usage is low):

  

 

The conditions above can be used as a basis to flag underutilized controllers in a treemap visualization (more info on Treemaps) for each crew.

Crew 1: Unit 1 Controllers % Time in Manual Mode (> 15% shown in yellow, > 50% shown in red)

 

Crew 2: Unit 1 Controllers % Time in Manual Mode (> 15% shown in yellow, > 50% shown in red)

 

Crew 3: Unit 1 Controllers % Time in Manual Mode (> 15% shown in yellow, > 50% shown in red)

 

The following insights are gained from the resulting treemaps, where each Unit 1 controller is represented by green, yellow (manual > 15 percent of time), or red (manual > 50 percent of time) squares:

• Unlike Crews 2/3, Crew 1 is running TC109 in automatic mode less than 50% of the time. TC109 is a recently commissioned controller designed to reduce product quality variability. Action is taken to further train Crew 1 on the importance of keeping this controller in automatic.
• FC157 and TC119 are controllers that all crews leave in manual. Crew feedback reveals the associated control valves need resizing to avoid saturation issues, so maintenance is scheduled.
• Crew 1 is running PC117 in manual mode between 15 and 50 percent of the time, resulting in its yellow designation. Conversations with Crew 1 reveal PC117 always oscillates following an equipment procedure only scheduled during their shift. An action item is given so the control engineer can address this oscillatory behavior.

 

Monitoring crew-influenced process performance

Use Case 3: Average Batch Phase Duration by Crew

The duration of each phase or step in a batch production process can be affected by crew process knowledge and operating preferences. Analyzing batch phase duration and performance by crew can potentially reduce phase durations, yielding benefits of less energy consumption and/or increased production.  

For this use case, we start with a Crew Condition and signals for batch number (id) and batch phase:

 

A Phases condition is easily created using the Condition with Properties tool and the phase signal. We choose to name the resulting capsule property (a capsule is created every time the phase signal value changes) as “Phase”:

 

Looking at the zoomed time period above, we notice there is an “END PROCESS” phase that should be excluded from further analysis. The keep() function in Seeq Formula creates a cleansed Phases condition which ignores the “END PROCESS” phases:

 

We next calculate the duration of each of the cleansed Phases, and we choose to place the discrete value result at the middle of each phase, using the Signal from Condition tool. Note that this approach, as we do the final steps in the analysis, will “count” the phase duration for a specific crew if the phase duration value falls anywhere within that crew’s shift. If we wanted to restrict the duration analysis to only phases started by a crew or started and completed within a given crew’s shift, we could do that easily with a few additional steps.

 

We now have a Phase Duration signal in units of minutes, located at the middle of the phase. Note there is no phase duration value where the phase signal is equal to “END PROCESS”, because those phases have been excluded.

 

The final step is to use the cleansed Phases condition, the Crew Condition, and the Phase Duration signal to view the Average Phase Duration by Crew in a histogram. We use two condition groupings to set up the histogram and customize the crew legend colors to green, blue, and red. We expand the time range to a longer time period (a month) to include enough data for meaningful interpretation:

 

Potentially valuable insights are quickly noted from the histogram results above:

• For potential process improvements, the first item to investigate is the excessive average DISCHARGE duration when Crew 1 is on shift. It is worth seeing if anything can be learned by Crews 1/3 from Crew 2, which has the lowest average DISCHARGE duration.
• Average REACT times are consistent across crews which is an encouraging sign. 
• Assuming quality and overall performance is good during their shifts, Crew 2 appears to be the highest performing crew in terms of consistently minimizing phase duration, especially for the START and DISCHARGE phases. 
• It is well known that CHARGE A and CHARGE B phases should be of similar duration, therefore an effort should be made to reduce CHARGE B times across all crews. 

 

Use Case 4: Energy Usage for Energy-intensive Equipment

A distillation column reboiler uses a large amount of steam. The amount used is determined by how closely the crew maintains the column operation to the optimal conditions, and by how well they maintain the column feed consistency through regular maintenance swaps of the feed filters. Seeq is used to monitor longer-term steam usage by each crew, based on their last 10 operating shifts and data from normal operating conditions.

To do this, the average steam flow for each time Crew 1 is on shift is calculated using the steam flow signal, a Signal from Condition, and the crew capsules, with crew specific conditions derived from the overall crew condition using the keep() Formula function. It is of course important to remove downtime data from the calculations (see Data Cleansing Tips: Using the remove() and within() Formula Functions for suggestions):

  

 

The result from the Signal from Condition is then used in a Formula to calculate the average usage over the last 10 times Crew 1 was on shift (the aggregateByCount() function is very helpful here):

 

Similar calculations are created for Crews 2 and 3. The aggregated steam usage results are reported in a Simple table. Crew 3 could improve their performance to keep the steam usage below the benchmark and closer to that achieved by Crews 1 and 2.

 

 

Use Case 5: Crew Control of Critical Process Targets

Using Seeq’s Parallel Coordinates view to analyze critical process targets and values can reveal important differences in crew operating philosophies. Here, a distillation tray temperature control target (setpoint) is adjusted by operators, with the goal being to run the product impurity close to its upper limit of 0.975, which will enable higher production rates through the distillation column (which is the current process bottleneck):

 

The parallel coordinates view for the dataset above (see screenshot below), color-coded by crew with off-spec product highlighted in red, clearly reveals a strong inverse relationship between tray 32 temperature and the level of product impurity (%). Crew 3 is very quality conscious and as a result is being conservative in their operating practices and running the product impurity with a wide safety margin below the off-spec limit of 0.975. As a result, and without realizing it, Crew 3 is reducing production capacity on a sold-out product. Coaching and training utilizing these process insights convinced Crews 2 and 3 that they can safely run the tray 32 temperature at lower values, increasing throughput by allowing the impurity levels to increase slightly without breaching the off-spec limit. Sharing this analysis with Crew 1 provided a better understanding of the ideal operating window for maximizing throughput while reducing off-spec excursions.

 

 

Monitoring crew-influenced maintenance effectiveness

Use Case 6: Isolating and Quantifying Maintenance Performance by Crew

Contextualization of the process data to identify maintenance periods is necessary to calculate the resulting maintenance effectiveness per crew, indicated by the pressure reduction achieved through cleaning of equipment that fouls in proportion to time in service. The key concept in this use case is using capsule adjustment features and data alignment methods to align cleansed pressure averages preceding and following maintenance. Here are the steps:

1. Identify the maintenance periods based on a large pressure decrease.

 

2. Grow the maintenance periods slightly to eliminate anomalies near the maintenance work.

 

3. Calculate an averaged pressure over an appropriate time period (e.g., 2 hours) before and after maintenance. Note the use of startKey() and endKey() in the formulas. 

 

4. Align the before/after pressures to the same point in time to enable calculation of the net pressure reduction due to maintenance (see Aligning Data Values: Common Use Cases Involving Time Delays, Lab Data, and Process Events for more details on methods to align).

 

5. Calculate the percentage pressure reduction due to maintenance.

 

6. Identify the subset of maintenance periods completed by a single crew from start to finish (Crew Shifts Spanning Maintenance Periods).

 

With these steps completed, the “Pressure Reduction % (from Maintenance)” values, isolated to each time a single crew was responsible for maintenance (where green capsules are present), can be analyzed to compare and improve crew-to-crew maintenance effectiveness.

 

Summary

The use cases above are merely a starting point in an often overlooked category of industrial analytics. Capturing operator tendencies and behaviors - which can vary widely from crew to crew – can be instrumental in improving manufacturing operation and reducing costs. Consider how you can expand your use of crew (shift) conditions in Seeq Workbench to discover new, value-adding process insights.

 

Edited 4 hours ago by John Cox
correcting formatting issues