Evolved Enterprise Operations For Clover South Africa

00:00
Jaco
Good morning, good afternoon, good evening from wherever you are joining us, whatever the time is. Thank you for joining us. My name is Jaco. I look after the team at element eight. Element eight is the subsaharan African distributor for ignition. Very proudly. So we are excited to be a part of ICC this year, of course, virtually again following last year’s first virtual ICC. We have, on our side, we have Francois and Deon from Clover. Francois is the engineering manager at Clover. And Deon is the electrical and control systems development or responsible at least for electrical and control systems development at Clover. So we’re really excited to be able to tell the clover story today. We’re going to get into a little bit more detail around what the journey is and where it all started for you. But Francois Dion, welcome to the virtual ICC.

00:45
Francois
Thanks very much.

00:48
Jaco
The title of this presentation is evolved enterprise operations. So what we’re going to be chatting about today is, first of all, I definitely want to start it off with you, Francois, on the next slide and kick us off in terms of why the change. We don’t typically, when it comes to technology, we don’t typically just say, let’s either go for a or b or kick off something just for almost said giggles and laughter. But we do it because of very specific reasons and technology reasons and benefit that we anticipate at the end of the journey. So I want to kick off with that. Then we’re going to talk a little bit about some of the architectural aspects of where you are right now.

01:29
Jaco
And I understand that it’s evolving and growing, but I definitely want to get a view of the architectural view that you will eventually have. And then the final point that we have on here is we would love to understand, let’s call it the timing. A lot of this was initiated and started very soft, poor timing because nobody planned it that way. But it was literally on the advent of COVID and everything else around remote working and protocols and just the ability to be able to work together as a team. So I just want to understand that a little bit better as well.

02:05
Deon
So that’s what we’re going to chat about today.

02:07
Jaco
You okay with that?

02:09
Francois
Yeah, great.

02:09
Jaco
Fantastic. So maybe, Francois, we can kick it off with you in terms of just the why, where you started, why ignition.

02:19
Francois
I almost want to say thanks, Jaco. This specific journey for us started kind of in the middle of 2019. And at that stage, were less focused on the actual technology solution, but more on the automation discipline. So we set out and just redefined our automation roadmap, specifically with the focus on supporting business strategy and the objectives that the business want to achieve, and align our development to support those objectives. We reviewed our current state of automation technology in the business and the capabilities that we could achieve at that stage, road mapped our competencies and tech based technologies to support the capabilities that we want to achieve in future. And then based on that, went out to look at new technology. Now this roadmap really brought to life a couple of new capabilities for Clover.

03:32
Francois
And it was actually at that stage we thought probably about a five year journey.

03:37
Jaco
Five year journey, yes.

03:39
Francois
So at this stage in our journey we had a fairly strong incumbent in terms of our technology platform within Clover and we really had to re-evaluate how well we would be able to achieve our roadmap with this incumbent. But we also had a few very large consolidation projects coming up within the business that gave us the opportunity to really launch into a new technology base. So we did actually go through a process of technology selection again. So in that process we highlighted a bunch of criteria that we wanted to meet. So I think if you go to the next slide, we stuck it basically in different categories. So starting with capability, do you want to add here?

04:32
Deon
Yes. As Francis mentioned where that comes that we had established standards for our PLC controllers. Now, selecting something new cannot necessitate redoing what we had. So whatever we choose must seamlessly interact with our existing standards. We want to have a good relationship with it and stay on the good side of news articles about security breaches. So we want something to run on our established Microsoft system and not be hampered by not being able to run on the latest and greatest versions with the latest security badges. A capability we did not have in the past was the capability of running on a variety of client devices. In the past, you selected a resolution, you developed your application based on that.

05:25
Jaco
Super resolution and that’s it.

05:26
Deon
And to change is not easy. So we want to break away from it so that we can decide fit for purpose where it must run. And while we’re at it, cost the net wipe phones all the way up to large forms.

05:45
Francois
The next big thing that we looked at was scalability. So this was also always a bit of a problem for us because scalability often comes with cost and sometimes prohibitively comes with cost. And we felt at certain points that it became a design consideration.

06:08
Jaco
When you say at the expense of cost, you mean you are being penalised to want to grow and expand. Your system almost feels like you’re being penalised.

06:16
Deon
Correct.

06:18
Francois
Paying for correct. And we often found ourselves engineering around.

06:23
Jaco
That constraint, which is not ideal.

06:26
Francois
It’s suboptimal at best. So we had to look at how do we really start small, expand rapidly, because as a part of this project process that were going through, we really developed a bunch of small projects. Some of them were bit larger in rapid succession, and we had to grow with that very quickly and scale with it very quickly and reliably. So that dull scalability factor was also very important to us.

06:59
Jaco
I like the scalability. Scalability is one of those. If we want to talk about digital transformation, it doesn’t feel like we should have any slides in 2021 without talking about digital transformation. But one of the criteria, one of the underlying foundations of digital transformation is the fact that for it to be enterprise wide, it has to be scale from inception. If it doesn’t scale easily from inception, it’s likely not going to be enough to be enterprise wide and give you that total transformation that you’re looking for.

07:31
Deon
If you do not plan for that scalability from the start, it bites you a lot quicker than you ever could anticipate. So an important selection criteria is also simplicity. And how we saw this is also varying levels of simplicity with the highest emphasis that we place is on the actual user interface. Because in the end user of this is the operator running the plot. And we used the high performance HMI design philosophy, the overarching do not scream that everything is normal. So at first glance, everything looks pretty boring if you look at our HMIs, but that means everything is okay.

08:11
Jaco
Was this a new implementation for you as well? This is the first time you’ve rolled this out with it?

08:16
Deon
Not quite, but it is an evolution of it, because first time, in our incumbent solution, there were elements of it, but it was a learning for us all, so we could apply it properly. Then the next level of simplicity is simplicity. In actually rolling our projects, we don’t want everybody to have to reengineer everything from the start. So for our partners to implement, we want to provide a set of reusable assets, minimal engineering, just mass instantiation and configuration.

08:55
Jaco
So in other words, do the work up front and then benefit from that time savings later. By then, just simply reusing correct.

09:01
Deon
And also simplicity by familiarity. Because if we make everything look the same and operate the same, we can have operators understand other parts of the plant, so you can train them on the actual process that’s going on. But we don’t have to retrain a guy on how to operate the system generically.

09:20
Jaco
We understand that familiarity is quite a big part of the success of a technology over a longer term, because the sooner you can get that familiarity and that comfort of use up, then the better in the long term. Correct?

09:36
Francois
Cool.

09:37
Deon
Right.

09:38
Francois
So the common factors that we looked at then obviously cost we’ve mentioned in terms of licensing, but there’s kind of two aspects to that. There’s firstly the actual upfront cost, and then there is the scalability of that cost.

09:56
Jaco
Yeah.

09:57
Francois
So both of those were very important considerations for us. Complexity of the entire architecture. So complexity of the application, complexity of your systems architecture, complexity in the licensing model was something we tried to minimise. And then talking about resources, Deon already mentioned that something like your operating system standardisation was a big thing for us. So we didn’t want to worry or be bugged with foundational stuff. We want to run on latest greatest technology and not necessarily the most powerful technology, but fit for purpose technology that we can keep up to date. So in terms of those resources on the server and networking and user side, we wanted to optimise our implementation.

10:56
Jaco
Okay, so you’ve just mentioned fit for purpose. Actually, it’s the title of the next.

11:02
Deon
Slide.

11:04
Jaco
On the fit for purpose. I think what we’ve done is we’ve looked at each one of the criteria and we’ve sort of identified how you ultimately landed and where you ended with. So let’s kick it off with capability. Is there anything Francis or Dion, I suppose that you. Yes, because you led a lot of this initial capability, understanding and exploration.

11:26
Deon
Right? Correct. So nag Francois for the opportunity to evaluate the new technology and he reluctantly said, just get it out of your system. We’re going to get to the answer that we know and went ahead. So as you normally evaluate technology, you want to fail as quickly as you can, make sure that this thing can tick all the boxes that we can and as soon as possible, find out if it can do what we want. So we installed it, connected it to ours. We typically use a Siemens 1500 CPU with a built in OPC UA server. It installed and connected and browsed tags in minutes as advertised. Yeah. So then off to a good start. And then we systemically went through. What can it do? Can we create a reusable template? In this case, it’s a view. Can it launch a pop up?

12:22
Deon
Yeah, there. And just every challenge we threw at it could do. Not necessarily with us just sitting in front of the designer and getting it right the first time. There’s obviously some checking the documentation, which may add ignition’s documentation is absolutely stellar. It allowed us to develop quite a rich solution on our own with no formal training. Not that I say don’t do the training, just it is possible to get it done. Of course we checked it. Can we access it by phone? We can. Can we do it on a browser? It works. Work with a touch screen, seamless interface. There we go. It works. And then from a reliability point of view, because there’s no point, we develop this application and it falls over every few seconds. We set up the redundancy in a test environment. It works.

13:13
Deon
We’re not losing data from our storm forward engine works. We tried to break it and it kept living up to the challenge, just.

13:23
Francois
Maybe lost thought on the capability. So we obviously evaluated quite a few products when went into this technology selection process. And Dion mentioned now that I was a bit reluctant up front, and obviously with a product that is not well known in your local industry.

13:40
Jaco
Correct.

13:41
Francois
I was a bit reluctant, but once Dion showed me this capability of ignition, I very quickly got on board and we pushed.

13:53
Jaco
So the capability is quite a practical thing you went through. It was quite practical and sort of pragmatic to work through and understand scalability is a little bit different. So you can, from a licensing point of view and understanding the commercials, you can understand whether it’s scalable in the terms and the way that you deploy it on the architecture, but actually seeing it in action and understanding if it’s scalable, that’s a little bit more tricky to prove up front, isn’t it?

14:21
Deon
It is tricky to prove up front. So we did our development and tried to stage a representative architecture, okay? And it worked, did its thing, but now it’s very difficult to say, is a server going to handle 100,000 tags or is it going to go up to 2 million? But I think what we ended up on is we know it’s going to work initially and because it’s going to scale as we throw projects at it, we also know when it’s going to start running out of resources for sure. And understanding ignitions architecture, we had a clear path forward of what to do when that time comes in terms of.

14:59
Jaco
Understanding the load across multiple gateways.

15:01
Deon
As an example, exactly how to make this gateway into two gateways and split either front end and the back end, or even two front end back ends, we have options that we can do.

15:12
Francois
I think that was a big consideration for me as well, because this is a leap of faith and it’s one thing to see this work in a lab environment.

15:19
Jaco
Correct?

15:19
Francois
But once you’ve committed to this, to build one of your biggest factories on, you kind of sit in that direction. But the amount of mitigation that we could do, or that we can do in future should we need to. However, having said that, the resource requirement at this stage kind of indicates that we don’t have to do too much.

15:39
Deon
It looks like we may have over specked the server. It has not broken a swing.

15:49
Jaco
One thing I want to ask about is the concurrent development. So maybe another point that’s maybe or perhaps not that well known. So apart from the unlimited tags and clients, you also have what we refer to as unlimited designers, or typically engineering clients. Within your current environment, what does that design part of the project look like? Are there multiple designers working on multiple different areas at the same time? Or what does that development look like?

16:21
Deon
So this really was a breath of fresh air that we can have multiple people editing, obviously not the same resource, but that’s unlikely as we develop the standards our site projects inherit from that. And then with the project, the scale of what we embarked on, we will have multiple partners and engineers and developers working. And at no point do we have to tell a guy, everybody close your designer, it’s my turn.

16:48
Francois
It was actually a bit funny seeing that up on the slide now, because it’s a stumble block that we’ve not encountered.

16:54
Deon
Well, there’s certain problems we had in the past that just simply no longer exists. Solution.

17:00
Jaco
Amazing simplicity. I would imagine that through some of the instantiation and the templates and the designs and that approach that you spoke about earlier, I would imagine that through simplicity, or the label of simplicity, would have seen some of that as well.

17:16
Deon
And on the simplicity requirement, I think what we landed on really addressed our needs. We have, from the operator interface point of view, we have something that is simple. We encapsulate the whole high performance HMI theme. If something attracts your attention, it’s not right. We have a familiar format which we broke units, we model our plant into units, and each unit has a control page which contains a dashboard that has all the pertinent and contextual data for what you need at that time. It’s a capability of ignition that we discovered on the fly. Now we even have specific dashboards for the plant state, because while you’re cleaning a plant, you do not have to see the same things as when you’re producing products.

18:06
Jaco
Exactly. It’s very different.

18:07
Deon
And we show the correct data at the correct time. Then from a simplicity for integrators, we have a set of standards that you don’t have to engineer, just instantiate. You want to create a valve, do it in the PLC, use the same UDT with the same name. Just tell them what controller it is and it links up.

18:30
Jaco
So in many ways you’ve made the lives of your system integrators in many ways a little bit easier through a lot of the work that you did up front to do that.

18:41
Deon
Okay, so we did take on a lot of the work ourselves, but the simplicity requirement did not apply to the development engineering team. It was for users, and users first and foremost, operators. Second to that is project integrators.

18:57
Jaco
That makes sense.

18:58
Deon
What we also discovered we didn’t set out for that is how much ignition allows us to configure items in the runtime environment as opposed to having to dive into the design so we can change configuration items of devices in runtime. So I use the example of how many times that you commissioning a plant, you see there’s a description that doesn’t make sense. You can’t make a note of that. We’ll change it later and you never do. Now, right there. If you have the correct access, just change it. You see there’s something wrong. Fix it. The runtime editing of the dashboard is while we are planning a project, we don’t actually know what we want to see on those dashboards. It’s only when you start commissioning a plant you realize, I keep referring that to that temperature to see if that’s correct.

19:47
Deon
Put it on the screen right there. We realise now that we need to see it then. The last point for simplicity was actually maintaining the system. Lots of other systems that I’ve worked with in the past requires downtime for simply patching security updates. We have since we’ve rolled out ignition, updated the product multiple times. I want to say ten could be more without incurring downtime. With the redundant architecture we have, we can upgrade the backup, fall over to that, come back to the master. We’ve become so cavalier about it, we almost don’t even advise people that we’re going to do it. We just upgrade.

20:28
Jaco
Sure. Typically it would have been a massive consideration in terms of downtime, the given downtime, the risk. That’s a typical way that you would approach any update.

20:42
Francois
It’s a great benefit because you now plan maintenance for a Monday morning and not a Sunday afternoon, correct?

20:49
Jaco
Yeah, that is a big one.

20:50
Deon
We always say so that if something goes wrong, that we have people in business out, nothing has gone wrong.

20:59
Francois
Testing and rollout.

21:00
Jaco
So the testing and rollout, I would imagine there was a proof of concept. There was a trial or a production trial, and then there was a live production. And in many ways you are still in the live production as far as the rollout per nationwide is concerned.

21:16
Francois
So this has been a fairly expedited process since we made this call around the selection very close to when we started development. So what we had to do is very quickly do a proof of concept that I think went very well. We had certain key aspects that we had to test. It’s not anything that particularly pretty, but we had to see that it works. Fortunately, we had a small project that we could very quickly translate into ignition to do a live production trial. But I think we only ran it for about a month before we really started working on our new projects and the new implementation on larger projects. So as much as it was a fairly expedited process, I think it went fairly well.

22:18
Jaco
And this was obviously from a timeline point of view. This was last year, this was sort of mid when South Africa, we had lockdown, at least several stages of lockdown. So the development happened during that period. The rollout happened towards the end of that lockdown. That was probably quite tricky. And navigating a build of something this size and scale as a team when you are in lockdown.

22:47
Deon
Just to put it in perspective, that production trial, that process that we translated, we actually rolled it live into the factory. Without visiting the factory?

22:56
Jaco
Without visiting the factory. That’s incredible.

22:58
Deon
Wow. Okay.

23:00
Jaco
That says a lot.

23:02
Deon
So we didn’t even have the opportunity to in person train the operators on a new HMR. And they used it and they liked it.

23:09
Francois
It was a fairly like for like implementation. As Deon mentioned earlier, we already did some work in terms of our automation standard before went to ignition. However, I think if you had to compare that build to what we have in place at the moment, there’s a massive difference because we’ve been enhancing our standards quite a bit with the functionality that we’ve found with the.

23:36
Deon
And also when we really rolled this out in a large scale, we realised some design decisions we made didn’t scale so well. Just a quick example, we really abused tag event script and then realising that you quickly run out and you need to treat them with more respect. So yes, we did, but we kept it running.

24:00
Jaco
Yes.

24:04
Francois
So the very obvious one, capex and Opex savings, it actually talks to the next point as well, is besides the fact that there’s a base cost that is just more realistic, it also gave us the freedom to do a lot of things in our larger project that we otherwise wouldn’t have done, but were now able to do because we had that freedom.

24:36
Jaco
Internal team development of standards. I think that was a win from what you definitely explained.

24:42
Deon
But also with the use of the EAM module, we are really well positioned from our development team with our development servers to enforce the standards out. We don’t have this hanging site that’s on an old version that we forgot to update. We can distribute our standards and UDTs instantly.

25:02
Jaco
So maybe for those watching that’s not familiar with EAM. EAM is the enterprise application management. And to your point, that gives you the ability to, from a central point, manage, roll out, backup, instantiate everything from all your applications.

25:18
Deon
Forgot about the backup. That’s just been trial. It’s been doing its thing for months as it’s supposed to. But what we use it for is if we find a bug in our standard, I can fix it and I can push it out to all of our sites, call it instantly, it takes a few seconds and everybody’s got the latest version.

25:36
Jaco
Okay, yeah, that’s a big one. So the multi partner implementation, we had a little bit of debate around this one before we even started recording the session, because your approach to, and I know that we’ve put in here that it was influenced by, in some cases by regional and local support, but I think your approach to this one is quite commendable in the sense that you worked with a number of partners, implementation partners, throughout the rollout into implementation. Maybe if you can talk through a couple of the reasons why and what the experience has been like.

26:14
Deon
So to have this familiar operating experience by the operators, everything needs to look the same. So for that to look the same, it must be based on the same standard? Yes, but not just based on the same standard, also implemented using the same convention. The project, this consolidation project that Francois mentioned earlier is too big for any single partner integrator. We have to use multiple, but we don’t afterwards want to say, ooh, partner X did such a great job here. Partner y, not so much. After the project’s done, I don’t want anybody to be able to discern who did what. So in order to really have this single look and feel, we have a strict set of standards and implementation guidelines for them.

27:04
Deon
What we did find, and this is the next one, is the success of the implementation of those standards really depends on the partner having a holistic appreciation for how tightly integrated our standard is. Starting at the PLC, building on that, and it was more a case of embrace our workflow and just use it, and that was maybe a learning. Have a guy first appreciate how good the outcome is going to be, but then recognise the process to get there.

27:41
Francois
In a lot of cases, the partners we’ve worked with also saw ignition for the first time on this project.

27:48
Jaco
That’s right.

27:49
Francois
And as Deon said, there’s nothing to be scared of there if you follow our methodology. But it has been a quick learning for a lot of people.

28:03
Jaco
I’m sure that the learning curve has been quite steep for a couple of.

28:08
Deon
Folks, and also the quickest by necessity. They just simply didn’t have the luxury of time.

28:13
Jaco
Yeah. And the learning and just touch on the learning. So we obviously know from a partner point of views, we had some partners that physically attend the training, but it does seem like inductive university was the sort of primary approach as far as the training and the playing and sort of understanding the product for yourself kind of experience. It seems like inductive university was the primary vehicle for most people.

28:39
Deon
It was probably their first proper introduction to what the product. Indeed.

28:43
Jaco
And then that was followed by the sort of in office, face to face training. So given where you are at the moment with, I almost want to say, correct me if I’m wrong, I almost want to say you have a platform in place now. So although you have a SCADA control.

28:59
Francois
System.

29:01
Jaco
In place, you almost have a foundational product in place now. So looking at the future in terms of rollout to other areas, sites, plant areas, what is in the pipeline as far as the future is concerned for you and your team and what’s next on the roadmap?

29:21
Francois
Initially I told you that once we’ve designed our technology roadmap, we estimated about five years to achieve most of those capabilities. And I think now, two years later, we can tick off most of those boxes.

29:36
Deon
Just time for a new roadmap.

29:39
Jaco
The roadmap needs to be updated.

29:42
Francois
One of the things that make me the most excited about that roadmap is generating more contextual data, which was a big shortcoming in our previous standards. And I think that’s where the value will come out for the business side. So whatever we don’t touch with our consolidation project now, I think once we demonstrate the capabilities that we can bring with this new standard and this new technology, there will be more of a business appetite to adopt those same capabilities in other areas. So probably what’s happening next is a rollout of this to legacy systems and then really making use of all that data that we generate and building some business intelligence on top of that.

30:38
Deon
Well, say that having reliable data in the background enables us to.

30:44
Jaco
Absolutely. That’s the foundation. Right. Nobody wants to question the validity or the accuracy of the data. That’s got to be a given, and then you have the confidence to understand. Cool. This is some of the decision making capability that we have, not only for our team, but for the rest of business, where the rest of business is looking potentially to us for some data and information to make decisions, we can now confidently give that to them. That’s the difference with that. Well, that’s amazing. Out of a five year plan, you’ve pretty much been able to bring a lot of those things into play within two years.

31:18
Jaco
That’s not only a complement to, I suppose, ignition naturally, through enabling that, but also to you and your teams, you and Dion and the team for being able to do that, obviously with the help of the partners.

31:30
Francois
Yeah. Thanks, Jaco. We’ll take the contribution. If it wasn’t for ignition, there are.

31:37
Deon
Certain things that we’re doing now that just would not have been possible without ignition. And just an example, the controllers we use, Siemens, have a connection limit or a subscription limit of 10,000.

31:50
Jaco
Yes.

31:51
Deon
Without ignition, allowing us to read a whole structure, and that counts in as one subscription, we would not have been able to even subscribe to all the data, and then we would have had to make architectural changes, again, not using symbolic address signal.

32:10
Francois
Yeah, I think something that helped us quite a bit was that a lot of those items in our roadmap would have been third party applications within our previous environment, whereas that’s inherently built into ignition, or ignition at least gives you a foundation on which to build it more effectively.

32:32
Jaco
Okay.

32:33
Francois
And that’s really been a great help.

32:35
Jaco
Yeah, that does make a big difference. Also, from a cost point of view, from a complexity point of view, that makes a big difference. But you’re right. We’re talking about essentially technology, people and process. And I think the technology in your case was definitely a win because your team and the people were able to implement and improve processes. So, good story all around. So, looking at the architecture, I want to spend a little bit of time just to give you an idea of the scope. So I understand that this is very much work in progress and it grows weekly and it’s being built up. But right now, Deon, we’re on 300,000 tags.

33:08
Deon
Yeah, that number surprised me because it grew really quickly in the last few weeks.

33:12
Jaco
Good surprise, bad surprise. Good surprise, but good.

33:16
Deon
Yeah, I was surprised to see that we’ve already up to 300,000 tags.

33:20
Jaco
Yeah, that’s amazing. Without knowing it. That’s the impressive part.

33:23
Deon
I just keep looking at the server performance and it’s happy.

33:26
Jaco
Amazing. 500 screens. And we talk about SCADA screens specifically. They rolled out over 35 clients. And that’s in some cases a very remote view. I think you have a mobile view, you have a couple of mobile clients that you’ve enabled people with.

33:41
Deon
Some mobile, some fixed. And what ignition has also allowed us to do is that team leaders and plant managers can view HMI and even take control from their offices and use that to train their operators.

33:57
Jaco
Amazing.

33:57
Deon
Quick intervention. Doesn’t have to walk into the plant if somebody needs an opinion on something. Yeah. So we didn’t want a generic, I’ve got an alarm. Whatever the information, we can deduce out of the control system to tell and operate exactly what went wrong. We wanted to do that. So every device type motor, for instance, can tell exactly what’s wrong. It’s not healthy, but I can tell you, is it not healthy because the motor starts, has got a fault, or do I lack communication to it? Because if you just generically say there’s.

34:31
Jaco
A fault, there’s a fault on the.

34:32
Deon
Motor, guy’s going to call the electrician, there’s nothing wrong with the motor, there’s nothing wrong with the drive, you simply can’t talk to it. So pointing that operator in the right direction as quickly as possible is very important. So that’s why we try to be as detailed as possible. And we also, on most devices, we allow for custom alarm messages, which ignition then can look up that custom definition and tell you this is not a generic device alarm here. And it’s a free text that we can say this went wrong.

35:04
Jaco
Very.

35:04
Deon
I can’t tell you how many alarms we have, but they’re quite explicit and they tell you exactly what went wrong.

35:10
Francois
Okay, amazing.

35:12
Jaco
From a sort of hardware, let’s call it a hardware device specific architecture. We obviously protocols used OPC, UA, predominantly Siemens, in certain cases, depending, I would imagine, on the model of PlC that you were using.

35:24
Deon
Yeah, it’s mostly OEM equipment. If we put something down, we prefer UA. So right now we set the primary gateway and it’s backup. So we say it’s a scale out architecture that’s not yet scaled out. So as soon as we run out of processing power or whatever hardware resources we have, we know exactly how to split it into another redundant pair, link them together into the scale out architecture. And obviously we don’t have to stop there.

35:50
Jaco
And depending it grows more, we scale out even more exactly. And depending on where the bottle makers, if you want to call it that, it could be on either the sort of acquisition side or it could be on the serving side. But you have the ability to set that up depending on where the bottle makers.

36:05
Deon
So the logical first split would probably be into a front end and a back end. Just split your tags and your perspective server. And then, well, who runs our resources next? And that’ll show us what needs to be done.

36:17
Jaco
Okay, so far so good. So these are a couple of the screens that we have. So this is a bulk CRP or clean and place control page. And these are the control page that you referred to earlier, correct?

36:31
Deon
We didn’t show anything that gives away anything confidential here. Okay, that’s good. On the left you can see a dashboard. And this is where we say, depending on the plant state, we’ll show the correct contextual data. If it changes to idle, you only see what’s applicable in idle. Any decisions that you need to make to get out of there, we show you step messages. This is a mimic. Again, the only thing with colour in there is a device that’s currently in an arm.

36:58
Jaco
And especially even operators and whatever your structure is, or how your operations look, whether it’s shift supervisors or eventually the plant supervisors and managers, if everybody has the same consistent view, and recognising that there’s so much value in the tribal knowledge or the tacit knowledge, then for those teams that exists, once you’ve established.

37:22
Francois
There’s a barrier, you remove exactly. When you put it out in a.

37:25
Jaco
New plant, everybody’s immediately on the same page. This is a recipe view.

37:32
Deon
It’s just a simple recipe manager. I don’t know our experiences in the past when we needed recipe managers, they’re either too simple for our needs, or they’re too good and too expensive. So we ended up do our own little homegrown solution that offers us capabilities. We need ignition and the python in the background. How well it handles data structures allows us to create this flexible structure. Because it’s the same recipe manager, but every recipe has a different data structure and it allows us to do that.

38:05
Jaco
Cool. Amazing. I think we’re out of time. We’ve probably gone a little bit overtime. Hopefully that was valuable. To those watching and listening, we’re going to share, maybe if we can, a little bit higher quality of the screenshot. If somebody really wants to understand what a high performance situation your wear screen looks like nowadays, I think it’s a good example of it. And then naturally we’ll share your contact details.

38:30
Francois
If that’s okay.

38:31
Deon
Well, just in retrospect, I’m very glad went to the ignition for all the challenges we have had in our project. Our Scada platform has not been one of them. It’s been working well.

38:43
Jaco
Okay.

38:43
Francois
I think that says it very well. Yes. Positive experience.

38:47
Jaco
Awesome. Francois, Deon, thank you very much for joining us. Hopefully that was valuable to those of you that are watching and listening.