Plant Intelligence...en bier!

Het is een (niet zo) goed bewaard geheim dat we bij Sure Controls een zelfgemaakte bierautomaat hebben. De bierautomaat is altijd het hoogtepunt van elke rondleiding die we onze klanten geven. Ik dacht dat het ook een heel coole manier zou kunnen zijn om enkele van onze Plant Intelligence-mogelijkheden te demonstreren! Een paar weken geleden heeft onze huisbrouwmeester Josh een paar batches gebrouwen. Terwijl hij het bier brouwde, hebben we onze interne historicus, die we gebruiken voor het intern testen van klantprojecten, aangesloten en gebruikt om gegevens te verzamelen. Wat ik met dit artikel hoop aan te tonen, is hoe we verbinding kunnen maken met het proces om de gegevens te communiceren, en vervolgens, zodra de gegevens zijn verzameld, welke methoden we kunnen gebruiken om de gegevens te bekijken.
Deel 1 – Gegevens verzamelen
In mijn eerdere blog "Demystifying Data Collection" besprak ik in enig detail standaarden en protocollen. Ik zal hier niet zo diep op ingaan, maar deze oefening is een goed voorbeeld van hoe we projecten aanpakken die we voor onze klanten uitvoeren. Eerst ging ik zitten met Josh, onze brouwmeester, om te bepalen wat de kritieke informatiepunten waren die we moesten verzamelen. In principe zijn er drie stappen in het brouwproces, Mash, Boil en Break. Het kritieke item dat tijdens deze stappen moet worden gecontroleerd, is de temperatuur. We hadden ook een manier nodig om ons gegevensverzamelingssysteem te vertellen in welke stap van het proces we ons bevonden.
Voor het verzamelen van temperatuurgegevens analyseerden we de biermachine en merkten op dat er temperatuurregelaars waren aangesloten om de verwarmingselementen voor de kookpannen te regelen gebruikt in het proces. Gelukkig hebben deze controllers communicatiemogelijkheden, dus het bleef alleen om de benodigde standaard en protocollen te bepalen. Deze specifieke besturingen gebruiken Modbus als hun communicatieprotocol. Dit is geweldig, want Modbus is heel gebruikelijk en gemakkelijk om mee te praten. Een uitdaging die we hadden, was dat de controllers zelf alleen een seriële verbinding gebruikten voor communicatie, en onze Historian-server was op enige afstand. Om dit op te lossen hebben we een serieel naar TCP/IP gateway-apparaat gebruikt. Hierdoor kon onze Historian-server Modbus TCP gebruiken om rechtstreeks met de bedieningselementen te communiceren en de temperatuurgegevens te verzamelen die we nodig hebben. Vervolgens om de processtapvraag op te lossen.
Om vast te leggen in welke stap van het proces we ons bevonden, besloten we een kleine PLC en HMI te gebruiken. We hadden gelukkig een kleine PLC die we gebruiken voor het testen van applicaties, en een HMI die we gebruiken voor verkoopdemo's. We hebben de PLC geprogrammeerd met een register dat tekstgegevens bevatte. We then programmed the HMI with some simple buttons for our brew master Josh to select which step of the brewing process he was in. By pressing the “Mash” button for example, the HMI would then write the value “Mash” into the register programmed in the PLC. The PLC was connected to the Ethernet network, and Historian could then read the register directly logging the process step. This will aid later when viewing the data, in order to give it context.
Part 2 – We have data – now what?
Once the batch of beer was brewed, we used the process steps logged by the PLC as our flags for pulling the data. By noting when the process steps change, we could capture the start and end points for each step of the process. We then brought up each step of the process in a trend view:
The Mash

Here we can see that during the Mash phase of the brewing process, our temperature maintained a steady 153° Fahrenheit.
The Boil

The same thing holds true for the boil phase, our temperature holds at a steady 210° Fahrenheit.
The Break

This step is considered critical to the brewing phase, as it is important to bring the Wort (this is what the liquid is called during the brewing process – it’s not beer yet) down to a temperature where it is safe to pitch the yeast. We can see here by our trend that it took approximately 13 minutes to bring the Wort from 200° down to 100° Fahrenheit. All in all, it appears our brew master did an excellent job with this particular batch of beer.
Let’s talk a bit more about the data. We used trends for our initial analysis. Presenting the data visually in this way allow us to quickly spot any anomalies that might have cropped up during the process. If, for example, during the boil phase, if we saw a sudden drop in temperature for a small period of time, then we would start to ask what happened? Did a fuse pop, causing an actual loss in temperature, thus putting the batch in peril? Or did a sensor become detached and thus the data is skewed, but once reattached we could see the temperature was holding constant, so the batch is likely okay? This kind of analysis can become very useful in identifying “what went wrong” if something didn’t pass quality tests for example.
So, what if we just want a simple summary of what happened during the batch? Using the Query tool from our Historian client, I can do a simple summary like this:

This is a very simple statistical analysis of the temperature of our Wort during the Mash phase. I pulled Min, Max, Average and Standard Deviation. This gives us a great one line view of what happened. I can see that the temperature stayed within one degree of setpoint, and averaged almost exactly at setpoint for the duration of the time.

I can see that there is a slightly larger variation during our Boil process, but still well within acceptable parameters.
Finally, if I really want to do a “deep dive” into the data, I can easily export to Excel which is a familiar tool and I can view the raw data directly, create my own charts and reports for doing additional analysis:

Some additional “Tips and Tricks” for data collection. If we were a real brewery, it would be a very good idea to assign a batch number to this batch, and log that value to Historian as well. Then, the next time I brewed the type of beer “Citra Tripel”, I could go back and compare my latest batch to the previous batch. If my beer taster(s) note anything extraordinary about a particular batch, we can then analyze what happened, and then update our recipe in order to replicate that improvement in future batches, or just compare how we did. Also, using the trend tool, we can pull up data from both batches simultaneously using the “time offset” feature, allowing a nice detailed visual comparison by overlaying both batches within the same trend.
I hope you enjoyed this article. This really just scratches the surface for what automated data collection can do for process improvement. In a future article, I will discuss additional techniques for capturing downtime data and analyzing causes. In addition, I will talk about how we can leverage the data collection system to notify our process team when an event is occurring, instead of analyzing what happened “after the fact”.