IES: Smarter Energy Control with Ignition & MQTT

00:12
Speaker 1
All right, so next up we have ECM, Energy control and management. So Hendrik and Gerard, lovely guys, are very well known in this region. So they’ve developed a project for IES. Welcome to the stage, guys.

00:29
Speaker 2
Thank you.

00:34
Speaker 1
All right, Henny, do you want to take us through the additional requirements? Yeah, if you want. I mean, it’s up to you.

00:45
Speaker 2
Yep. I think Harat, thinking back, it’s his brainchild. So, coming out of the automation industry, going into the energy sector, I think one of the big challenges was monitoring.

01:02
Speaker 1
Yes.

01:02
Speaker 2
Data integrity, the availability of data and then the reports.

01:08
Speaker 1
Yeah, sorry. This is an energy management system. I should have mentioned that in the beginning. Yeah.

01:14
Speaker 3
So was in the automation industry for about 10 years. Cleaning scatter systems, complex control systems for various industry explosives, and FMCG. And then got involved in energy systems, steam turbines, wind turbines, and automation of medium voltage switch gear. And then decided to go into that sector full-time, but with a nice thing with a skill set of automation. Saw a lot of opportunity in the energy sector with the whole scalability thing in mind and with data integrity, especially because energy is a critical infrastructure.

01:56
Speaker 1
Right, Absolutely.

01:56
Speaker 3
I think South Africa has realised that over the past five or six years.

02:01
Speaker 2
Yeah.

02:02
Speaker 3
So looked at various types of technologies.

02:05
Speaker 1
And I believe that was the birth of ECM. And I mean that’s where you. You guys connected. Yeah, right.

02:12
Speaker 3
No, I think it was around 2020 when I had this vision of how implementing all these energy systems, but at the end of the day, managing it. Yeah, okay.

02:26
Speaker 2
Yeah.

02:26
Speaker 1
So any old background. Not as colourful. Hey.

02:31
Speaker 2
Very colourful. Before we go any further. Excuse me. Shoes.

02:36
Speaker 1
Yeah, yeah, I wasn’t going to mention the shoes. I don’t know if it was some kind of a statement or. No, no, it’s very cool.

02:41
Speaker 2
No, no. So the last time I was in front of people was when I was in the circuit. So just to relax a little bit, I just went back to my roots.

02:50
Speaker 1
I love it. Guys, we at least do the funky socks, so we’re not far behind. We’ll catch up. Yeah.

02:55
Speaker 2
All right.

02:56
Speaker 1
Yeah, there we go.

02:56
Speaker 2
Mission socks. At least that works. Yeah. So the challenge came to us to have a robust platform for monitoring that is lightweight as well. And that’s where the challenge came in. So, we went through various stages of developing most of the devices. Modbus TCP. So obviously, the first test is two VPNs. Connect that to a server and then via Modbus TCP, send that data. But when you look at your data stream, it’s a really Heavy data stream because it’s a quality tag that’s being sent up. So you’ve got a name, you’ve got a timestamp, you’ve got a value.

03:40
Speaker 2
And if you look at the possibilities of the hardware that sends that also went through a lot of iterations on the hardware that’s physically on the site that needs to send the data up, then if you look at a PLC and you want to use different technologies, you run out of memory very fast. So that’s where the drive towards MQTT went, or where the.

04:06
Speaker 1
Okay.

04:06
Speaker 2
The, the.

04:09
Speaker 1
And GSM or mobile kind of determines that.

04:13
Speaker 2
Yeah. So. So what happened was we’ve got a lot of remote sites, and now all of a sudden, you have bad signal reception. So first, you need to get the VPN up and running, and then secondly, over that VPN, you need to transfer heavy data. So that’s where the A Modbus broker is nice. When you have a light data stream. So when there is connectivity and you have storm forward, then your data is, your light data is transferred and then.

04:41
Speaker 1
Obviously, you want outside of the integrity, security is a big requirement as well.

04:45
Speaker 2
Yes. 100% TLS Nice certificates.

04:49
Speaker 1
Okay. So, based on those requirements, as you mentioned, the legacy type approaches were ruled out.

04:55
Speaker 2
Yeah. And the other thing was scalability in the task. So now all of a sudden you’ve got something that’s. That replicates the ignition word, which is you have a repeater. So you’ve got something that repeats a lot of the time with minimal variations. So if you can plot certain patterns and you can have something that scales dynamically by your requirements, then you’ve got a solution that uses minimal of your time to roll out, and that’s that. That was the end goal that we needed. We needed something that was cost-effective, robust, subscription-based, and easy to use.

05:41
Speaker 1
Yeah.

05:42
Speaker 2
To scale.

05:43
Speaker 1
And you’ve got the benefit of the reporting by exception as opposed to the polling that.

05:47
Speaker 2
Okay.

05:48
Speaker 1
July 2025.

05:52
Speaker 2
Yeah. So if you want to do the challenges.

05:56
Speaker 3
Yeah. So I mean obviously with the decentralised nature and all the remote sites, I mean coming from legacy systems, it’s heavyweight, it’s difficult to manage. I think that was present in the medical clinic example as well, with the 50 sites across the country. So yeah, definitely getting the correct communication protocols up and running, finding the correct hardware and then just packaging that all together, and Ignition gave us the perfect package to fit it all in. Right. And then there’s a lot of with all your user management, which makes it really nice. Yeah. So maybe you can run through the solution.

06:49
Speaker 2
Yeah. So basically, what I said earlier, the first approach was a VPN. It’s still something that we use, but we only use it instances where you need to do remote programming of a PLC on site. So you’ve got your connection on your public IP to your MQTT broker and only in a scenario where you need to assist a client, then you opt to allow the VPN to connect our firewall and then you can remotely program or give the client the assistance that he needs.

07:30
Speaker 1
Sorry. MQTT does support write back. Essentially, it’s two ports. So you do have the right back capability with MQTT.

07:39
Speaker 2
So we do set points, we send site points, set points to the site, and then we also water down the data to an additional extent. I think in the videos that we display, we can look at them a little bit more. But what we do is, because we know at what, when we do a request, what the data is and in what order the data is, we can completely remove the requirement for the name of a tag. So basically, you have a timestamp, and you get a set of arrays of data. By mapping that on the server side, you have super lightweight data, which you send back to the other side as well.

08:32
Speaker 2
If you’ve got a Modbus server that’s sitting at the end of an MQTT gateway, then you can send an array of data that the gateway knows how to handle and decipher, and you can send your set points as well. And then your MQTT broker gives you, for argument’s sake, it gives you a cookie and a status of the message that you sent. So you can form your quality tag. So you have an event handler that’s waiting for that response to the request that you published, and then you can form your quality tag on the server side. So it’s the power of MQTT, and all the devices that you can use these days can give you really robust data. That’s very light.

09:20
Speaker 1
Yeah. And then you opted for an SQL DB in the background.

09:26
Speaker 2
Yeah. So the SQL DB is probably just part of my background. So what we use that for is how we define our tags. So now obviously you tell the MQTT Broker Gateway that I want 125 addresses, and this is my reference ID to it. But when those values are returned, you need to map them at the back. So by using an Ignition named query, it was a very nice way to get the information out of a database. Use the power of SQL DB engine to process the data fast and efficiently, and then populate that and send it directly into DAX.

10:09
Speaker 1
Okay. And then you mentioned a single low-cost device was identified to fulfil the requirements. So there was an off-the-shelf.

10:18
Speaker 2
Yeah, yeah. So, so what’s nice is the way ignition is in, you can integrate with technology that’s currently relevant and off. Off the shelf. So when we started this journey to find the correct technology, it was like, How will we do it? And I remember taking something off the shelf, the office, and going, let’s try. And as soon as you went down the rabbit hole, it’s just like. But the guys who develop hardware these days have lightweight data in mind. So yeah, it’s something that we could use and roll it out.

11:02
Speaker 1
Okay, so the solution is a PLC Modbus MQTT Modbus gateway to the broker to your central ignition server.

11:14
Speaker 2
Yeah, so that was just. That’s the data flow, if I call it like that. So you’ve got a PLC in the field, which you have your local control, you’ve got your user, or if it’s a power plant controller or a plant controller that controls heating, you’ve got something that needs to multiplex data and store it in a way that you can link that up to your project in Ignition. So that’s where the PLC comes in. You can allocate your DB data block in an unknown order. You tell the PLC to create its own Modbus server. So you can read that data off the server with a Modbus MQTT gateway that is then transported to the MQTT broker via the public IP. So as soon as there’s connectivity, it sends that, and then at the end of that is your ignition server.

12:16
Speaker 2
And what’s nice about the possibilities that the ignition server gives you is you can use a namespace that you create, and then you can have different projects that only look at different namespaces. So you can have different root MQTT tags that are coming in, and depending on what lands inside that tag with a unique ID as a drill-down identity, then you can execute the correct script that needs to run.

12:56
Speaker 1
Okay.

12:59
Speaker 2
Yeah, so that’s just a very rough architecture of what’s happening. So at the bottom, you’ve got your PLCs or your devices that read smart bus or any form of data analogue. And in certain scenarios, it all depends on your store and Ford requirements, I mean, if you use a cheap off-the-shelf option, then you’re Limited.

13:23
Speaker 1
You won’t have store forward.

13:25
Speaker 3
Yeah.

13:25
Speaker 2
Yeah. So mission-critical cases. You go for each of your licenses. If you’ve got that nice month. Store n forward.

13:36
Speaker 1
Yeah.

13:36
Speaker 2
At your.

13:37
Speaker 1
You’ve got the 35 days available.

13:39
Speaker 2
Yes. And then you’re on the other side. If you have a low data flow and you have only a few critical parameters, then you can use just basically MQTT directly to your broker to the ignition server. Then there’s two ways that we’ve done it. We’ve used the Cyrus distributor, which is the MQTT broker flavour of Ignition itself. And then we’ve also used third-party MQTT brokers. Both are really easy to integrate with Ignition. No problems? No.

14:18
Speaker 1
So the lovely thing about MQTT is the very flexible kind of architectures you can create with multiple brokers 100%.

14:26
Speaker 2
From there on. So it’s the ignition engine. That’s something that I firmly believe one cannot go without. And that’s because that’s the heart of the data processing. And to use the data within Ignition from there is very simple. So it’s CirrusLink dot, and then you get all your functions. So it was a real pleasure.

14:51
Speaker 1
Okay. The sexy stuff.

14:56
Speaker 2
Okay, so this is just a demo program we did for the event. There’s just a lot of dashboard items. And then over here, I show how easy it is to actually create a new site.

15:14
Speaker 1
You need to talk us through this. It’s very well done.

15:17
Speaker 2
Yeah. So on a live application, it’s actually going to either scan a QR code or it’s just a screen from your perspective.

15:27
Speaker 1
So this is new hardware. This is new hardware, new site.

15:30
Speaker 3
Yeah.

15:31
Speaker 2
So you need to create a new site.

15:33
Speaker 1
Yeah.

15:34
Speaker 2
And what you basically need is to give it the IP address of your EMS on site. You need to tell it what type of system it is, and you need to tell it. What’s the third thing? It’s so much easier when you just scan the QR code. Oh, it’s the unique serial number.

15:54
Speaker 1
Oh, yes.

15:54
Speaker 2
Yeah. So each brand has a unique serial number. So what I’m showing these is just so.

16:03
Speaker 3
Show the plank simulating adding a site, right?

16:06
Speaker 2
Yeah, yeah. So this specific one is just an additional device. So basically, what I did was just a multiplexing block inside the portal. I gave it an additional PV for argument’s sake. It’s a Huawei smart logger additional data point. So add that to the system. We want to run that script again. And then it needs to add all the tags automatically, as soon as it adds all the tags. So Ignition needs to create all the tags because I feel it’s a soul-crushing process to add tags.

16:45
Speaker 1
2000 plus hours, you said 2000 kegs is soul destroying.

16:52
Speaker 2
So then it creates all the tags there, you can see it created PV Inverter 2 automatically, and then it updates all the screens dynamically as well.

16:59
Speaker 1
Fantastic.

17:00
Speaker 2
So really well done. Is this possible for different sites? It’s possible. So it’s the same process if you want to add a completely additional site.

17:09
Speaker 1
Yeah.

17:10
Speaker 2
And then also what the system does is it checks. So for that type, there’s an argument’s sake. So in this specific one, you would see there’s a limit of five subdivisions for the inverter, and it will actually, let’s call it, ping the device to see what values are in those registers. And if there are no values, it doesn’t create those tags, and it also doesn’t read them going forward. So that’s basically the process that you can see there. So the end goal of this was to have something that’s 100% dynamic. So for the users as well. So then you’ve got three tiers. So we use the RDP of Ignition that’s built into the default one. And then in SQL, we allocate, we have super users, which are our company.

18:04
Speaker 2
Then we’ve got, let’s call it SIs that sit below us that need to be able to allocate plants to stack different owners. And then the bottom tier is the owner. So then you can allocate sites to the different users dynamically as well. So I think that’s actually on the next slide. Yeah, so this is just the end product that we had for ies. So what you can see there is.

18:33
Speaker 1
This is for your own monitoring. This is for your monitoring.

18:36
Speaker 2
Yeah, so this is for IES. So what they are pushing for is that with every one of their batteries, they want to have an app as well. And that is where the whole drive came from. It must be 100% dynamic because I believe one of those batteries can have up to two and a half thousand tags. And then they would tell you, but okay, this side has five batteries. So now, yes, you can do it with a UDT. But then somebody still needs to go and add it in the background and make sure everything works fine. So the drive was to have something that would see that there are five batteries and populate accordingly.

19:20
Speaker 1
Okay.

19:22
Speaker 3
So I mean, besides getting the architecture right, our next challenge is Rapid deployment.

19:27
Speaker 1
Yes.

19:28
Speaker 3
And I believe we’re getting there. And as you can see, works well.

19:35
Speaker 1
Okay.

19:37
Speaker 2
Beyond. Okay. Also, this, the screen is just showing the different users’ different rights.

19:46
Speaker 1
Access.

19:46
Speaker 2
Different access. So one of the. So now you’ve got this dynamic platform. IES needs to be able to see all of their sites across the country, but the owner only needs to see his one or multiple batteries. So it was just to be able to. Yeah. Allocate certain rights to. And then there’s also the like administrator can. So IES can change the logos to fit their client.

20:18
Speaker 1
Yeah, so it’s.

20:19
Speaker 2
Yeah. Just. Just to give cost customisation functionality as well. So all of those images are stored in a database, and then you’re in the same position as the reporting. So all of the custom information is saved in the SQL database, and when a report is called, then that’s populated.

20:41
Speaker 1
Okay.

20:45
Speaker 2
So this is just to. I think this is something nice that we do as well. It’s on the perspective side of the Ignition SCADA. So in this scenario it’s not that handy. But for a navigator we did, we’ve got 500 screens and it needs to be perspective. So the conventional way is you do a large screen and you do a small screen, use a page break. So you basically have three screens for every screen that you need.

21:14
Speaker 1
Yes.

21:15
Speaker 2
So what we do is we use the advanced style sheet CSS. CSS. Then we define a class for argument’s sake that’s called three column, and that we know that everywhere in the program that we use three columns, we just allocate that class and then by using that small script over there in the advanced style sheet, it sizes everything automatically.

21:45
Speaker 1
Basically that’s best practice.

21:47
Speaker 2
Then you have 500 screens for 500 purposes, and you can still juggle how things need to display. So that was also a nice tool that the technician provided us.

22:02
Speaker 1
Yeah.

22:04
Speaker 2
So this is something that comes from the art. So if you tell my wife I was serious for. For a little bit, she won’t believe me. So please tell her. But yeah, I admire what inductive automation has accomplished with Ignition SCADA. Through my years in automation, I’ve never found a platform with the possibilities that were the limitation of my imagination until now. We’ve done a lot of automation, and it’s every time there’s like, okay, but we’ve hit this roadblock, and you start scrolling through forums, you start scratching your head, bounce ideas back and forth, and all of a sudden it’s like, but it’s actually a simple problem.

22:51
Speaker 3
Well, the answer is in front of you.

22:53
Speaker 2
Yeah, so. Yeah, so. And what makes the experience even better, you’ve got this amazing platform is the Element eight team. And I want to thank Jaco, Gary, and the rest of the team. Yeah, it’s, you’re always willing to assist and yeah, I genuinely believe inductive ignition with Element8 is a one-time shot.

23:20
Speaker 1
Thank you.

23:27
Speaker 2
And then Gerard, closing statement from you.

23:31
Speaker 3
Jaku and team, thank you very much. We really appreciate all the things you’ve done for us over the years, and hosting events like this, and the reason for the Crocs.

23:40
Speaker 1
Yes.

23:40
Speaker 3
Is I’m curious, I don’t know if you’ve told your international colleagues what lacquer means. Yes, there’s always lacquer like Crocs.

23:52
Speaker 1
Thank you for the kind words. Really appreciate it. And that’s why we’re here to help. But I think there’s a common theme emerging with MQTT. The scalability is obviously a big aspect of it. You’ve done a couple of things, sounds like you guys can chat about, you can exchange notes, but there’s definitely a common theme of MQTT and the scalability is such a big aspect of it, you know, so energy control and management. I mean, you guys, potentially the scales of what you’re looking at are expanding. It was very important to get that right up front.

24:26
Speaker 2
Just to add some figures to the MQTT is the conventional VPN Modbus TCP. We were looking at 18 gigs of data a month. With our watered-down MQTT solution, we’re looking at two gigs a month.

24:41
Speaker 1
Wow.

24:42
Speaker 2
So just by doing that, we had sites where we couldn’t connect to the site with the VPN because that was too heavy. But these days, you can’t connect to the VPN, but the MQTT data is still flowing, so that MQTT is powerful.

24:59
Speaker 1
Amazing. Well done, guys. Thank you. Gary, any questions for them?

25:02
Speaker 2
No, it’s very interesting to see the way you’re using the MQTT.

25:10
Speaker 1
It’s very different to what normal people would do. Initially, when I saw that scripting it, I said That’s the lazy way, but I realised it’s actually the smart way.

25:19
Speaker 2
Yeah, yeah. So, so we’ve, we’ve got the different parent projects now for everything and yeah, everything happens automatically.

25:28
Speaker 1
Also got an inheritance that you can. Lovely.

25:31
Speaker 2
Yeah. And so you’ve got your parent project that sits on Gateway scripts or gateway events, and then you just reference it towards the right namespace. And by doing that, everything can be customised but automatically. You know what I find interesting is that every time I talk to him and he says, Yeah, but you must see what else I’ve done. Yeah, you should see version 2.0.

26:01
Speaker 1
So there was Khalid Neni from Energy Control and Management. Any questions for them? Yeah, there’s a question there.

26:12
Speaker 2
Yeah. So store and forward. So the one way is your edge device. So that was on one side of the architecture. On the other side is the device that we use. It runs on a Linux system, so it gives you the possibility to do scripting. So as soon as we detect that the connection is down, we start populating, let’s call it a buffer, with the same lightweight arrays of data. And as soon as the connection comes back on, we just send it to the.

26:48
Speaker 1
To the broker, and there’s data back full and the appropriate date. Timestamps.

26:52
Speaker 2
Yeah, so because there are timestamps. So use in. You get a function in Ignition that you populate with a quality tag in your historian. So because we’ve got the timestamp that data actually worked, we just saved it with that timestamp, and we force the quality to. Good.

27:17
Speaker 1
There was another question. Okay, thank you very much. Appreciate it.

27:27
Speaker 2
Thank you.

27:30
Speaker 1
Thank you, guys.