Stone Brewing Successfully Implements Modern Batch System

[0:00] [silence]

Moderator: [0:15] It’s my pleasure to introduce our speakers today, experienced engineers that get things done and looking forward to their story about their projects. We start with Fred, who is the principal engineer…

Nicole Williams: [0:27] That one.

Moderator: [0:28] Sorry.

[0:29] [laughter]

Moderator: [0:29] Let’s go to the next slide.

Nicole: [0:31] Oh, sorry.

Moderator: [0:32] We start with Fred, who’s the principal engineer at Wunderlich-Malec. He has over 18 years of experience in control systems, SCADA, HMI, PLCs, a wide range of experience and the full breadth of project experience, from estimation and implementation and programming. He’s the full package here.

[0:53] We also have Nicole Williams who’s the senior director of brewing operations at Stone Brewing. Starting out as a brewery process engineer, she’s climbed the ranks and fielded several successful projects, leading in those projects technically and in project management.

[1:11] We’ve got a very experienced pair telling us about their projects. Please join me in welcoming them to the stage.

[1:17] [applause]

Nicole: [1:28] First off I should probably get it out of the way. I did not bring samples.

[1:30] [laughter]

Nicole: [1:34] I am here to talk about our new brewhouse control system. For those of you who don’t know, hopefully, you all do, but Stone Brewing is one of the largest craft breweries in the US.

[1:47] We were founded in 1996 in San Diego, and are really famous for pioneering the west coast IPA style of beer that’s popular across the US now. We have two main production facilities, our Escondido, California Brewery and our Richmond, Virginia Brewery.

[2:09] Escondido was our flagship brewery. That’s the brewery that we’re talking about today. Our beers are distributed in 50 states and 40 countries. We’ve grown a whole lot since 1996, but we’re still an IPA powerhouse. That’s Stone.

[2:31] What we’re talking about specifically today is our brewhouse. In the brewing process, the brewhouse portion is where we make wort. Wort is basically unfermented sugary sweet water that is later fermented to become beer.

[2:46] We have two brewhouses that both make our wort for us. They’re about 120 barrels each. One went in in 2005, one went in in 2011 when we expanded the brewery. Definitely starting to get into the aging systems realm.

[3:07] Why are we upgrading our brewhouse systems? Well, the first one is obsolescence, the start of all the brew control projects. We were buying spares on eBay, so it was time.

[3:21] We looked at our system holistically and really felt that there was no way to replace one component. We couldn’t just upgrade the PLCs, or the scanner system, or the servers. It all had to get to a truly modern system. We needed to go from the ground up to avoid going through the same eBay hunts two years later.

[3:42] At this point, we got into the realization that to do this, we would be reprogrammed between PLCs anyway. There was no real reason to constrict ourselves to a direct migration of our existing data systems and PLCs. This opened us up to some more possibilities. We started with what was wrong with our new system that we need to fix.

[4:06] We had a couple of pain points. One of them was that our system is very panned. This is very common in brewing systems. You get a system that’s designed for brewing. It does one thing. It’s very constrictive. That’s what we had.

[4:21] We found that there was a little bit of trouble getting support for the system because it was so specialty. Also, it was difficult to troubleshoot. The SCADA system itself had very unintuitive configuration. Our documentation from the original system configuration was very limited.

[4:42] Not really the SCADA system’s fault, but it was all commented in German, which made it really tricky for me, unfortunately. Fred speaks German, I don’t. All of these things led to some poor integrations over the years as we added in more systems.

[5:00] The SCADA systems were a copy and paste of each other. When we put in the 2011 one, we copied an instance of the 2005 one. As a result, they had a lot of shared tag meanings and don’t talk nicely to each other. That became really problematic when we had shared resources between the two.

[5:22] Part of this is also just that a lot of the equipment vendors that we work with weren’t overly familiar with our program on this data system. Every new equipment deployment we did wound up with two integrators and, again, a lot of issues with shared resources.

[5:40] Also, the pain point for us on this was our limited clients. We basically had two clients that we could use for brewing, recipe development, and engineering. This led to a definite lack of progress and innovation on the brewhouse. All of the above ultimately limited our ability to improve and expand the system.

[6:02] Stone is a little bit unconventional, and one of our core values as a company is giving the middle finger the status quo. We couldn’t do that when we couldn’t work on the brewhouse.

[6:12] OK. Why the Ignitions FSOF solution? One of the big things that we’re going for with a new system is we wanted something with lower training costs. We love Ignition because it’s so easy to pick up for new engineers. There’s so many online resources available for training.

[6:35] This ultimately lowers our external support costs because we don’t need an integrator for every little improvement. We also love that it has unlimited clients and truly drives our ability to improve. Gives the supervisors and the brewers more time to work on recipes, gives engineers more time to keep making the improvements requested of us.

[7:01] We work totally on the team. Ignition can do anything. I love the customization and flexibility that this solution provided for us. Like I said, we were anti-can software. We didn’t want any black boxes. We wanted full visibility and control for our engineers.

[7:21] We also wanted to empower our brewers. We wanted them to have a lot more control over recipes and actual control of the process than most of these can systems wanted to give them. We wanted to be able to implement all their great ideas.

[7:39] The flexibility that this system has provided is really going to allow us to do that. We also love the improved maintenance troubleshooting of our new system. We’ve been able to visualize a lot more configuration, interlocking and alarm data with the new system.

[7:55] Finally, batch recording and tracking was a big deal to us. Being able to customize that and pull out the data that was important to us, not important to whoever built the brewing system that they were just handing out to everybody.

[8:13] With that, I’ll turn it over to Fred. You won’t have to watch him build more than we built anymore.

Fred Zaboli: [8:19] Thank you. Thank you, everybody. I’m Fred Zaboli, Wunderlich-Malec Engineering. We are an employee-owned company. We have over 500 employees. We are specialized in electrical and control systems and integration services.

[8:40] We do projects in most vertical industries like pharmaceutical, food and beverage, energy, water-based products, oil and gas and many others.

[8:54] We got invited to this project. We got invited from Stone Brewing to take a look at their packaging system. It was a job walk. So that’s where we got introduced to Nicole. She started talking about the brewhouse that they have. They have these brewhouses.

[9:16] She said, “OK, let’s take a look at the brewhouses after this job walk.” We take a look at it. It was really a closed system. Not much of a documentation, not much of information exists.

[9:30] She started saying that we have this problem. We cannot change it. If we wanted to change it, it has to be a control engineer. So that’s where we started thinking about it. That maybe we can have a way of operating that to a new system, PLC and also the Ignition system and batch system that we have in the system.

[9:58] We started to take a look at this project. Starting from designing of this project. We started to come up with a design of the PLC to rewrite the whole code for one of the brewhouse replacing the existing hardware to a new PLC with a new iOS.

[10:19] Also, we started into their existing HMI and replace it with Ignition because Stone Brewing, they already had Ignition in the packaging line and they were happy with that. They wanted to stay with the Ignition.

[10:35] Also, we figured that there is a really complex batch system existing, and we have to replace that if we wanted to go with Ignition and with a new control system. That’s where we propose having Ignition Perspective for the HMI, that’s the first risk we took.

[10:56] The second risk was to go with this new batch module and Batch Procedure Module. I wanted to thank Ignition and/or Inductive Automation and Sepasoft on support that they gave us throughout the design of this, because we had to run this with Inductive Automation.

[11:16] Also, we had to run it with Sepasoft to see if it’s possible to do this complex system with this new module. That’s where we started to do the actual innovation. I wanted to point out that the implementation of this project what it takes to do the implementation.

[11:39] The first phase was to come up with some sort of interface between PLC we have and this new batch module. That’s where Sepasoft implemented this PLC logic interface that they call it PLI, and that was the first one. It’s based on ISA88, all the states and the commands that we’re sending from the batch module, it’s all standard.

[12:08] This is what most of the PLC brands that you understand. The second phase was interacting with Ignition and coming up with the screens. This module provides these UBTs automatically. As soon as we start developing the UBT units and phases and adding our parameters to the phase, all these UBTs automatically shows up on your tag definitions. That helped a lot.

[12:41] All we had to do is to give it the same naming convention that we have on our batch engine in our PLC, so those guys can take a right path and talk to each other. That was the second phase. That was one of the requirement going with ISA88 standard and everything.

[13:04] That was one of the big point of the existing system because it wasn’t aligned with this standard. We had units, phases, and steps based on that ISA88. If I wanted to give you a size of this system, for one of the brewhouses, we have 10 units. We have 193 phases, and then we have 20 user parameter or settings per steps or per phases. That makes it a little bit complex system here, and the recipes are big and too granule.

[13:43] Then after that, if you wanted to talk about how we implement it. With Sepasoft module, they provide a lot of components to edit your recipes, configure your batch module, and also execute and monitor.

[14:04] Also, you could go to these components and start creating new units, creating your parameters, but for this size of project with 10 units, 193 phases, it was a little bit hard to do it manually. That’s where we got introduced to this new library of script that this Sepasoft module, the Batch Procedure Module provides.

[14:31] As soon as you install this module, all of these library of scripts are going to show up and you can use it either for executing a system, monitoring system, query information from your batch, and also you can use it for configuration, creating units, adding new parameters. That’s what we use.

[14:53] We came up with the Excel sheet in CSV format, and we used that in conjunction with the script, the new scripts that we are getting, and it automatically generates all these units and things like parameters without any error.

[15:11] The other thing that I wanted to mention in the implementation side is all these built-in components that it might take a long time to get these information from your batch system, but these built-in components like batch monitor, like batch control, recipe editors, all this stuff is built in and you don’t need to write any code or scripting to get to that point. That helps us a lot and it saves us a lot of time.

[15:41] At the end, in the implementation side, I wanted to mention the custom component that we had to create. One of the challenge we had on this project was that we had working system.

[15:55] We all know that it’s not fun to touch something that is already working and everybody’s saying that if something works, don’t touch it. In our case, we had to change it, we had to go into it. One of the things that we had on this project was that we had a lot of feature on the existing system that the operators were really comfortable using that.

[16:18] It wasn’t the best tool to use to do the operation, but we had to give it to the operators so they can continue their operation. That’s where we started to do custom component and Sepasoft batch and procedure module, help us with exposing everything to the Ignition front end with tags and information that is all exposed.

[16:49] You can use that and you can show it differently from the components that we already have built into the system. That was one of the thing we did.

[17:00] I wanted to show you some of the differences here. As far as the HMI, I said about the Perspective. First of all, Perspective was the good choice for this project. The reason was the quality of the graphic was substantially different in the new system. Also we followed the ISA101 as you see.

[17:28] In the right side, you have the old system with a lot of color and 3D typing and everything. In the left side we have a new system screens that they are all based on gray scale, high performance HMI.

[17:44] I’m glad that Nicole and the Stone team, they were in the same page with us as far as the standard of the ISA101 and high performance HMI. We didn’t have any argument on that part.

[18:00] Next slide I have here, you can see this is one of the components that they have in the existing system in the right side. They used to call it processor overview. It gives you an overview of the whole system, which unit is working and what unit is doing what is there.

[18:19] It was a limited configuration. It was some sort of configuration. It was some sort of a third-party software that they were using to monitor the batch. It was a separate piece of software. It was a limited configuration. In the left side, you see the replicate of that and the use of Perspective regular table.

[18:44] It’s not anything crazy. It’s a little bit of scripting in the background to extract those exposed information. It’s a regular Perspective table in the left side. With that, you get the live process set point change. That was one of the point that operators need to have to be able to change the set point, live, when one batch is running.

[19:10] For example, when they are in a specific unit and running a phase, there’s a bunch of set point on that. They already have those set points and that specific recipe, but when time comes, maybe operators decide to change the temperature, higher or lower, they can do it live from this screen.

[19:29] That was one of the custom-built component we did. You can get a bigger view of that here. In the top, you can see each line has a unit we have, and then we get the states in the second column, and then the mode, the batch ID.

[19:48] One of the challenge we had on this project was that, the Stone Brewers, they run three batch back to back, at the same time. They run one batch from the beginning, when it gets to the end of the line, they run another one, back to back. That’s how they get the best performance. We had to show them the whole overview. They can see which unit is running which batch ID.

[20:16] In the bottom you can see if you click on that unit and that specific phase that is running in the second row, top, you get all the set points and process value regarding that phase. This is some sort of a custom-build for Stone Brewing.

[20:36] The next comparison I have here was the way that we had the control recipe to show. They used to call it a control recipe. Whenever you wanted a recipe, you could see where it is, but it was very limited as far as the graphic.

[20:54] You cannot see the whole thing in one page. You have to scroll up and down, left and right to see where is the recipe running, what phase is running. In left side, you see the batch monitor screen that we made, that we monitor the running batch.

[21:15] Because it’s Perspective, because it’s HTML based and everything is built into the HMI, they can zoom in, zoom out, click wherever they want and they can see the whole picture of that batch. Also, they can add user-defined steps and they can put custom messages to this that we can get to it later on.

[21:43] This is the look of one of the recipes that they want. This is a single one, two-unit CIP unit. We’re doing CIP here. Those three batches I was talking about that they’re running back-to-back, they might be able to run some CIP in between of each batch, so it’s pretty complex.

[22:08] I wanted to point out the items that made this project a success. First one, I would say was the equipment icon. For each equipment, valve Morrow’s instrument, you have an icon that then it gives you all the device status and everything. It’s available everywhere.

[22:30] There’s two out there in HMI, Perspective HMIs. Then we have navigation icon in the middle. Navigation icons that you can get all the status of the devices under that zone of your navigation. For example, if you wanted to zoom in from your overview screen, you click on this navigation button that it takes you to the mash kettle area.

[22:54] If you have any device under that mash kettle area that is in manual mode or it has alarm, you get that on the navigation button, so you know how many alarm you have in that area, what state of device you have there.

[23:09] On the right side here, you have the instrument icon that gives you plenty of information. You can change the configuration of your instrument. You can change the alarm settings for that instrument.

[23:25] It doesn’t need any control engineers, doesn’t need any PLC change. It’s all throughout the HMI. Left side, you see bottom left, you see the unit state object. This is another custom object we created. It’s a template in Perspective.

[23:42] You can give the name of the unit to this template and you can drop it off in any screen and it gives you the information of that unit. What state is that, when it started, when it ended, and timing-wise, how far you are to the end of that state. You can drop it off everywhere you want.

[24:04] We have another component here, the batch commands, that is available on all Sepasoft’s Batch Procedure Module, most of them, that you can command your batch engine and execute your batch engine. You can run your batches, you can abort, reset, stop, and give all different sort of commands from everywhere.

[24:31] This is the main overview screen. We have Brewhouse One on top, we have Brewhouse Two on bottom. This is something new to Stone Brewing compared to the old system. Old system, there it was completely two separate different systems, but this one is all-in-one Ignition gateway.

[24:50] You get the whole idea of what’s going on in that brewhouse. Because we used the Perspective screens, the graphics were easier to change and also it was accessible from everywhere, from any devices. Also, we get some site features like dark modes, and those features that come with Perspective module.

[25:18] The good thing about going with Perspective and Batch Procedure Module is that all those components, they are aligned with Perspective standards. When you change your dark mode, it also changes dark mode on those components. You don’t need to do further changes on your HMI.

[25:41] Here I have a couple of good story, or I should say new features that we didn’t have in the old system, and it came up in the two other projects. We didn’t think about it in the beginning of our project, but it turned out that we need to have these new features.

[26:00] One of them is user messages, and the user messages, I’m talking about the process messages. You have alarms. The system is running, you get alarm. So that’s a different type of event, but then your batch gets to a specific step, and it needs operator’s attention and action, you need to give operator a message.

[26:27] We have this phase on Sepasoft’s procedure module that you can set up some messages. These messages are specifically for users, and users that they can change the recipe, they can add as many user messages as they want. These are all fully customized, and they can put unlimited number of these messages.

[26:51] It doesn’t make any PLC changes, or it doesn’t make any attention from the control engineers, and it’s all in the body of that recipe. I wanted to get the feedback on this one from Nicole. I know there’s a good story about that.

Nicole: [27:07] Yeah, this was a feature that we were really excited to put into the brewers hands. Like Fred mentioned, this is something we had in the old system, because we grew a wide variety of recipes. I know you said we’re doing IPAs, but we do a little bit of everything.

[27:26] We’re constantly innovating, so we have a lot of manual pop editions, manual special malt editions, places where the brewers need to intervene in the process. So that’s what we were using these before, but they were built in, and some of the messages were weird.

[27:42] They weren’t quite in German, but they were a bad translation, and so our brewers just basically had SOPs that said, “When you get this strange message, this is what you’re actually supposed to do.”

[27:52] Now when they build a recipe, they’re building these messages in themselves, and putting in useful prompts and useful information, and they’ve really expanded the number of messages in the system significantly since we added this feature.

[28:08] As soon as Fred showed somebody how to do it, I feel like we got 10 new messages into the recipes that day.

Fred: [28:14] I didn’t have to set up any of those messages, and I know being a controller genius, the way that we write stuff, it doesn’t make any sense for operators, and we always have this problem, the description of the logs doesn’t make any sense. It makes sense when you’re writing the code, but it doesn’t make sense when you’re operating the system.

[28:37] For this system, it was easy because I just gave operators these user messages, and they went crazy with it. They added a lot of these messages, they added their own descriptions. One day I was there, and they were early stage of the project, they started to run one of these recipes, and I’m getting a lot of messages that I don’t understand what it is, and I heard that their supervisor added these messages, and they loved it.

[29:08] Because it doesn’t have control engineers’ attention, they don’t have to put work orders, they don’t have to take the control engineers’ time to do this stuff, so it was a cool feature that we didn’t think about it, but it came up throughout the process.

[29:22] We have two other things here. Some new features here. We have value problems, and loopback logic. This is a good one. It happened that it looks like that the operators they used to do a lot of manual operation, and we knew it from the beginning of the project.

[29:47] We knew that they’re going to put a recipe in manual mode, which you can do, and then they used to do manually operating those steps, or go back up like 10 steps before, and run it from there and do it again. I asked the operator, “Why are you guys doing that?”

[30:05] One of the operators said, “Because you have to take samples on this step, and you have to make sure if you need to do rinse again, or if you need to boil again, or if the boiling is enough or not.” It is a lot of manual interaction, and it caused a lot of problems when you were starting the new system, but they used to do it in the old system.

[30:30] I reached out to several staff, we talked about this manual operation, and they said, “Why you guys don’t use the loopback?” They didn’t have this feature in the old batch engine they had. I brought it up in front of the operators, and I said, “What is loopback?”

[30:50] He said, “We can ask you if you wanted to go back to that specific step and do it again and again.” This is good. The supervisor said, “This is good because instead of having a lot of SOPs for the operators, and it leaves in their mind, we can just put all this built into the recipe.”

[31:13] We can ask operator to go and check, and to go and take samples. We can do some action, and we don’t have to put the whole recipe in a manual operation. That’s one of the good things that happened, and it helped the operation a lot.

Nicole: [31:30] It’s going to help enormously. Just to clarify, those brewers weren’t going rogue by putting it in the manual, that was in our SOP, because we didn’t have the ability to ask them if they wanted to repeat a step.

[31:43] There was no other way to accomplish what needed to be accomplished in the brewing process with the system that we had, and so now I feel like we all spend half our lives trying to make sure people aren’t putting systems into manual work around issues.

[31:57] Imagine if your baseline procedures put it in manual, at that point there’s no fear of putting it in manual, because that’s a normal part of the process. This is going to help us get away from a lot of manual operation generally.

Fred: [32:13] We have one feature here, recipe creation. This is a good one. Nicole mentioned that we didn’t have a way of modifying the existing recipe, or we did have on the existing system, but it was limited and only a few people could do that. It definitely needs some changes and modification to the PLC as well, because it was tied to each other.

[32:46] The new system, the way that this recipe editor component comes, you can do import, export, you can duplicate the recipe, and quickly get the new recipe and just change some of those settings and come up with a new brand.

[33:05] To me, it was impressive because this system, I didn’t create any of these recipes, I just created one base recipe, and then it didn’t take that much time.

[33:17] I remember it was in the beginning of the project, we just ran the new gateway, and I was working in my laptop, and I turned my head around and I saw one of the operators, he started to create six, seven recipes and brands right away in half an hour without training.

[33:38] That told me that this system it’s easier for them to create and edit recipes. I remember Nicole had to ask them, don’t do it because we don’t know if the main recipe is good enough, but they were faster than us, right?

Nicole: [33:54] Yeah, it was awesome.

Fred: [33:56] That’s all of our slides here. I wanted to thank Sepasoft, throughout the automation, helping us here throughout the whole project, designing of that. They help us a lot, they support us a lot with these features that we were asking.

[34:20] I know sometimes we would ask a lot, sometimes some stuff were short, but we come together and we did this and it was really great.

[34:30] [applause]

Nicole: [34:39] I don’t know how they convinced me, but I should be the first one to try the new system, but I will say no regrets, it’s been really smooth. We have amazing partners in Wunderlich, Sepasoft and Inductive, so would recommend to a friend.

[34:52] [applause]

Moderator: [35:01] Thank you, Nicole. Thank you, Fred. You were already one of our favorite brewers using our OE product, and we only have more reason to drink Stone.

[35:12] To kick off the Q&A time, we’re going to open it up to all of you, so if you have a question for them about their project, or about using Ignition and the Batch Procedure Module to solve these problems, now is the time. To kick things off while you think of your questions, what is your favorite Stone beer?

Fred: [35:38] Mine is this, Delicious IPA.

Moderator: [35:41] Good one.

Nicole: [35:43] He jumped in because it’s my favorite, too. He wanted to steal my answer.

[35:46] [laughter]

Moderator: [35:46] OK, so you know which beer to try first. All right, any questions from the audience? Yes, Doug.

Doug: [35:57] Do I need a mic over here?

Moderator: [35:59] I’m going to repeat the question after you ask it.

Doug: [36:01] All right. How often are you going in and creating new recipes? It sounded like you initially had operators creating recipes.

[36:12] Is this something where you’ve got a new set of hops and you want to try something new and you’re going to run it through all your equipment and you go in and you offer a recipe, or are you taking an existing one and just manually writing out those user notes?

Moderator: [36:30] The question is can you tell us about the frequency of new recipe authorship?

[36:34] [laughter]

Nicole: [36:37] As an organization, we make new recipes constantly, but I am never offering new recipes, neither is Fred. That’s in our brewers’ hands. Anytime we’re doing new hop additions or what have you, they’re very much in control of that, which is super cool.

[36:55] I’d say the edge case where we would need to author a new recipe would be if we’re doing a totally new product where they can just copy a recipe.

[37:04] We make seltzer on one of our brewhouses and not the other. If we wanted to bring seltzer in, that would be a pretty different process. We’d probably step in, author the original recipe, and then let them copy from there.

Moderator: [37:16] Great. Yes, Huck.

Huck: [37:18] Can you talk about the process that you went through to validate the new system that you were getting the same results from the process of the old? How did you fix…Without minimizing the production downtime, how did you transfer the recipe?

Moderator: [37:38] Sorry, Nicole. I’ve got to repeat it for the folks that are watching.

Nicole: [37:41] Oh, sorry.

Moderator: [37:42] The question is how did you validate that the new batching system did everything you needed it to do, like the old one?

Nicole: [37:49] Fred, I will let you take that one because your cutover process is amazing.

Fred: [37:54] As I said, this system was an existing system running, and nothing was wrong with it operationally. What we did, we came up with the idea of all the I/Os and all the instrument and everything was coming to remote I/O racks. All the I/Os were there. All we needed to do was to put a new PLC and show up over the network.

[38:20] We were taking over all the existing I/O. That’s what we did. We have 10 BSDs, something around 500 I/Os.

[38:30] In one point of time when we were doing the testing in the beginning, we come in the morning, switching over to the new system, doing our test, switching back to the old system, let operation continue, and the day after we’re coming back. So that’s how we minimize the impact on production.

[38:51] I think we didn’t impact any production time. We tried our best to know that…We have a favorable plan always. That’s what we did.

Nicole: [39:04] Because we were able to cut back and forth like that, brewing is a relatively slow process to get to finished beer. We were able to do a single-batch brew. Typically, we’ll do three brews into a single fermenter. We’ve got some smaller fermenters.

[39:15] We do a single-batch brew, let that ferment out, do all of our standard quality checks, sensory checks, and then we knew that that beer was ready to go. We did a couple single-brew batches like that before we did our final cutover and start brewing full fermenters.

Fred: [39:30] But as far as testing, we had a different type of stage of the testing. In the beginning, we do oil test and then we did phase logic test. Then after that we start doing the water test, like just running water through the system, and then get to the actual beer so we don’t waste that much material.

Moderator: [39:52] Good call. That would be a crime. OK.

[39:54] [laughter]

Moderator: [39:56] Yes, Justin.

Justin: [39:56] What does Ignition server architecture look like and is it redundant and have you had any problems?

Moderator: [40:04] Can you describe your Ignition server architecture for us, please?

Fred: [40:07] Yes. The Ignition architecture is…they already had a gateway that it was responsible for the packaging line and other part of the brewery.

Nicole: [40:20] All of our operations except the brewhouse.

Fred: [40:21] Except the brewhouse. What we did, we added a new gateway to the system and we connected the existing historian.

[40:32] I should say the new brewhouse system is…the architecture of the Ignition is front and back architecture and we’re using remote tags. All the tags are posting in the main gateway because we already have connection to the historian, we already have drivers and everything ready and we only add this new gateway with the batch engine on it and with the remote tags we were able to get all this information.

[41:07] As far as redundancy, this setup is not redundant yet as far as this Ignition software, but they are living in a redundant server. All of these are virtual machines, the historian, the main gateway and the batch gateway and they are sitting in a fault-tolerant server that you don’t see the difference if it goes down.

Moderator: [41:33] Yes, sir.

Audience Member: [41:35] What were the challenges you faced and how did you make it work?

Moderator: [41:39] The question is what are the major challenges and how did you overcome them?

Fred: [41:43] You wanted to start with that?

Nicole: [41:45] Go for it.

Fred: [41:48] Yeah, challenges. The first challenge was to study the existing system because it wasn’t written as a design document so we had to study the existing system. We had to find out how many units we had, how they are interacting with each other and then come up with the number of these set points.

[42:13] That whole system wasn’t easy to export your information so we had to go one by one and study each phases and see how it works. We had an idea, we are our own company, doing breweries, we work on other projects. We had idea of how it works, but you have to replicate what they exist, they have.

[42:34] The biggest challenge was that we study the existing system and come up with the replicate of that. How we overcome that, we use a lot of simulation.

[42:47] I have a virtual machine in my laptop that it was set up with Ignition, several soft modules and PLC simulator right there and all of the phase logics we wrote, we run it in the simulator before we go to the production. That way we eliminated a lot of problems when we do the testing and we didn’t want it to stop and go down.

Nicole: [43:13] A few things made it past the simulator, but not too many.

Fred: [43:17] Yeah. Not too many, yes.

[43:17] [laughter]

Moderator: [43:20] Excellent. I passed you earlier, yes, sir.

Audience Member: [43:23] I was going to ask about material consumption. If you’ve only got 10 units, you got to put it on two phases, doesn’t seem like you have many units for the number of active phases?

[43:37] Normally you’d have storage units and then you can tune out of that into your active, whatever those cost units are, and then through to the finish and you could usually chase the genealogy through for it. You don’t have to have any material consumptions and genealogies?

Moderator: [43:52] Can you describe the material consumption and genealogy tracking in this project?

Nicole: [44:00] I’m not 100 percent sure I understand the question.

[44:03] Essentially, as one batch moves through the brewhouse and each batch gets its own unique identifier — three batches go into a fermenter, so each one has a modifier on that initial batch coding — each unit in the brewing process is so linked, we don’t delineate, there’s no break in the process, it’s a pretty straight transfer between one vessel and the next. That’s how our batching works and tracking works.

Audience Member: [44:39] It’s more from where it comes out of say, a silo? Which silo are you consuming from, what that lot is, and how much of that lot have you consumed? Are you consuming that particular batch? On the evidence, you know what’s actually made it up because it’s moving that lot of tracking through.

Nicole: [44:59] We don’t have packet trace or any formal system set up, but all of the lot tracking that are on materials tracking is logged, just there’s some scripting into a SQL database.

Moderator: [45:13] I know some people that can help you with that.

[45:18] [laughter]

Moderator: [45:18] Say the word.

[45:22] [laughter]

Moderator: [45:22] OK, yes.

Audience Member: [45:25] You mentioned earlier you used a CSV file to generate your equivalent model from a spreadsheet. I was curious, is that a one-time deal where you started off there and then you change the unit and then you made the SQL interface, or were you able to re-script that whole configuration from scratch by modifying the CSV?

Moderator: [45:45] Sorry, can you describe the…It was the recipe generation process from a CSV file? Can you describe it?

Fred: [45:56] Yeah, the CSV generation…for the beginning, I just came up with that CSV file and that script to create that for just the beginning. But then when we got to the Brewhouse Two, I had to reuse that.

[46:10] I put more comments into it, and I also incorporated that as a button into the screen. If, in the future, somebody wanted to create a new phase, not using the component, they can just give the name and the list of parameters and it’s going to generate that.

[46:30] To answer your question, no, it wasn’t just for the beginning. It ended up having it in the screen. Not for everybody, not for operators, just for the control engineers.

Moderator: [46:41] Right. I think we’re at time.

Fred: [46:45] Yeah, 47.

Moderator: [46:46] OK. We’re just a little bit over time. I think we could ask if you guys can hang around for a few minutes to catch any other questions, I saw some hands going up.

[46:58] Thank you everybody for coming, and thank you Nicole and Fred for sharing this successful project.

[47:03] [applause]