Transcript of Automate the Automation Engineer with Davy Demeyer

David (00:00) Welcome, you’re listening to the IT OT Insider podcast. I’m your host, David. Subscribe to get the latest insights shaping the world of industry 4.0 and smart manufacturing. Today I’m pleased to welcome Davy Demeyer. Davy has a very long career in industrial automation. He was working for Actemium, a system integrator. First as a project manager here in Belgium. And in 2012, he moved to Shanghai where he got the opportunity to build up a new local team. and actually become their brand manager or their branch manager. Since this year, he’s back in Belgium. He founded the company Acceleer and he is on a mission to change the way we write and deploy PLC code, if I’m correct. In this episode, we’re going to talk about basic automation, PLC coding. Davy even has applied concepts from DevOps into the PLC domain. He calls that design ops super interesting. So yeah. Davy, thank you for joining us. Davy (01:02) Hello David, thanks for inviting me. So you already gave all the introduction. David (01:08) Yeah, I already love to give some of the highlights. At least that’s what I found on your LinkedIn profile and in introduction meeting we had. I’d love you to walk me and the audience a bit through your career, your experiences, etc. So, yeah, Davy, please continue. Davy (01:31) Yeah. So, so, it’s mostly correct. What you said, actually I didn’t start as a project manager. I started doing the job myself as automation engineer. and actually before that I have a software background. So actually I programmed, when I still was a student, I already, I started programming on a, on a four eight six. Remember the thing before the Pentium, I started programming in basic. And then I made the decision to, to go to industry because I wanted to make things move. So I thought software is a bit boring. So I ended up joining Promatic at that time. So I don’t know if you still remember that name. That was a family company that later was acquired by Actemium. And I mostly did special projects because I wanted to go abroad. So at the start, they sent me to UK, to Germany. And then in 2006, China started booming, or it was already starting to boom, but then the big industrial investments came and they asked me to join the first project, and that was in Wuhan, for commissioning big continuous annealing lines. So that’s in the steel industry, so the end customers were the car industry. So I spent almost more than a year in China at the start, then I did a couple of other projects in chemical industry. And then indeed in 2012, We did another, well, we at that time it was Actemium. So there was another big acquisition of Cegelec, a name that’s in Europe quite well known. And then there was a business unit in Shanghai that did design and build for process industry, but there was no automation or software yet. So they asked me to go to Shanghai to build a new team and to help also integrate that business unit. So that’s a bit the backstory of Haya and the… David (03:05) Mm-hmm. Davy (03:28) ended up in China. And then for the past 10 years, yeah, I served mostly multinational customers, mainly in foods, pharma, and chemicals. So my background is really mostly the process industry. So for the past 10 years, we supported them, mostly expanding a lot of green fields, later on also quite some brown fields. That’s what I did for the past 10 years. And then Yeah, I always had a bit of nagging feeling about how we did automation. Because I had a software background, I was always bit annoyed by how difficult it is to design and deliver our projects. And over the years, it became more and more obvious that the gap with the software world was becoming much bigger. And I wanted to do something about it, but I realized if I want to do something about it, I need to actually start a company who focuses on this, not from a system integrator point of view, but really from a solution and a product. So that’s what I did. I made a decision and I moved to Belgium this year to set up the company. And now I am back in Brussels to do this. David (04:50) A lot of experience and I’d like to dig a deep… It’s difficult for me to pronounce my words today. I want to do a more deep dive in what you mentioned is the way we work in automation. On this podcast, I would say most of the things we discussed in the past were more focused on the data layer. on applications. We had one podcast with Gregory where we touched a bit more the SCADA MES layer. But why don’t we start with the control layer? Could you explain a bit, I would say, to the audience what is a control layer? What components do we see over there? What is the role of a PLC? for example, especially in the process industry, what’s the difference between a PLC and a SCADA? Let’s start at level one. Davy (05:58) Okay. So some people sometimes have different opinions about this. So the first of all, we have the hardware that executes the programs and these are called PLCs, programmable logic controllers. So we don’t program them with normal software. We always have to have this special vendor specific software. So if you buy, for example, from a Siemens hardware, you have to use the engineering software from Siemens. Same for Rockwell, same for Schneider, same for many different brands. So that’s where we write the main control. And then we also need to do some visualization. And this typically ends up in something we call the HMI or the SCADA system. And the SCADA system is typically just a visualization of your machine or your plant. And then it connects with some tags to visualize the data. The SCADA is typically quite simple. You would not make big data applications on top of that. So it’s just a representation of what’s in the PLC. And then your question about the difference between PLC and DCS. So at a certain moment, and this is a long time ago, people realized that the basic PLCs were not powerful enough for the complex control loops in chemical industry. And this started making special DCS systems. So on the one hand, at that moment, they were more powerful, but they also had some specific properties. For example, some chemical plants, you can never, never stop. So if you make a code change, you need to be able to download and run time. So there were all kinds of specific things they added in these DCS systems. So there became a big separation. Now, the original thing about the capacity, a difference that’s not longer true. So today the PLCs, are just as powerful and actually sometimes even more powerful than a DCS system. But we still have this really divided approach, a divided world where you either have to buy a PLC system or you have to buy a DCS system. While actually a lot of process industries, they do run on PLC systems because some of them say we don’t need this bulky DCS system. We need something that’s more flexible or they want to invest less cost. And for them, maybe doing a full download is not such a big deal. So a lot of process industries or process plans still run again on PLC systems. That’s the basis. David (08:43) You mentioned that also program a PLC. Can you explain that in more detail? What does it mean to program a sequence in a PLC? Davy (08:57) Well, there is actually an IEC standard. First of all, there’s an IEC standard and it defines five languages. One is ladder. Another one is instruction lists, which is almost like machine code, but this becomes depreciated because we don’t want to program like this anymore. Another one is structured text, which is a bit like Pascal. And then we have SFC. And I think, and FBD. FBD is like function blocks that you connect together. That’s how you program a PLC. And then for the DCS systems, they have all that. And on top of it, they add CFC. So CFC is, it’s like a function block, but it’s more flexible. You can more position it nicer graphically. then the SFC, it’s similar like in, in the PLC, the SFC, but it’s a bit more added functionality to enable to connect to batching systems. So these sequences are a bit more powerful. David (10:01) And you mentioned that there is, I would say, a divide in how you work with these types of systems versus how you work with, I would say, traditional software. Obviously, the IT world changed dramatically over the last, yeah, 10, 20, whatever years. It changes every day, but that goes extremely fast. If I look back to the languages I learned when I was still studying, today you… hardly see them any longer, they are replaced by something else. How do you see the way you work in the OT world with PLCs, for example, how do you see that changing or not changing? Davy (10:44) Well, until recently there was almost no change. So we still programmed and we still program mostly in these closed systems. And what we have not been able to do and what has happened in the software world. So in the software world, what has happened, people build software on top of software, on top of software. So there’s libraries, there’s APIs. We certainly had good systems being introduced. We had DevOps building on top of all these things. And we have never been able to really evolve in the automation layer. So we basically program in the same way as we did 20 years ago. Sure, there have been some evolutions. So the IDEs have been upgraded. It sometimes becomes a bit easier to find, like, where is the tag and things like this. but the basic programming workflow has not really changed. So for example, we don’t have access to our code. Our code is always mostly, there are some exceptions that I will come back to later, but mostly the code is locked up into the internal database of the IDE. So you cannot use modern version control because of that. We don’t have access to CLI tools. So CLI tool is a tool that you would use on the comment line to, for example, do automatic compile. So we also, in many cases, again, there’s some exceptions, we don’t have access to this. So we cannot actually automate our own work. Imagine that somebody would say, okay, we want to check in the codes and then we want to do an automatic compile and do some other things. You cannot automate this today. You have to manually click, click, click. David (12:36) So you’re an automation engineer, but you can only automate the process plans. You can’t automate your own work. Davy (12:43) Yeah, so this is something that I find difficult to grasp. We are automation engineers, but we have not been able to automate our own work. It is actually Slogan that’s starting to gain a bit momentum, automate the automation that’s recently come up. And what that actually means is, OK, people, need to now finally build the tools. or open up the engineering environments to automate our own work. So which is already very common in the software world. So the programming is like this. In many cases, we also program in a very graphical way. So especially in the DCS systems, it’s a lot of lines. It’s almost like you make like electrical connections because you have these graphical charts and you have the function blocks and that you have to wire them together. which is okay if you have to build a new program, but imagine you make a mistake, but you make a mistake and you realize you have made this mistake 100 times or somebody come with a new requirement. So you have to start adding 100 times this line. So then it becomes really, really, really tough. So the SFCs are also quite graphical, but that’s okay. You want to engineer like this. In general, it’s very, very tough. And I have seen many projects where we, at a certain moment, we want to make some, like what in software we call refactoring, and there’s new requirements or we need to add something. And then it just takes days or weeks of work to do this kind of things. it’s totally different than the software world. So that’s the current situation. David (14:31) And in your opinion, what can we learn from the software world? What is, I would say, if you take, I already mentioned DevOps in the beginning, right? So I would say the DevOps movement in general was also, there is a current, I would say there is a current situation. We are not working in an optimal way. How can we improve the ways we work? We take what works, we add some new collaboration models, maybe some new software, maybe some automatic flows, whatever. What can we take from the IT world in your opinion? And how should the PLC DCS world evolve? Davy (15:17) Yeah, so first of all, I don’t think we need to change the basic engineering workflows. So some people advocate, OK, we need to bring all these tools to our world, but that doesn’t work. We have a different kind of engineering environment. We do have the physical environment. So So I talk a lot about these graphical tools and how difficult they are to, to, to program at scale. I’m not advocating to remove this. So we still need to have this because it does help us when you have a graphical representation of your program, you can really quickly understand it and debug it. And for some things it’s just easier to engineer like this. However, we are missing quite something. So for example, version control is very, very, very tough at this moment. The whole software world has moved to Git. So Git is what is a Git system. You have a textual representation of your project and your configuration. You upload it to your Git system. You make a new version. You upload it again. It’s a very simple explanation now. People who know Git will say that’s not true. But basically, then when you want to make a comparison, you have the text files next to each other, and you can clearly see where the change has happened. who has done the change and what has happened. Today, it is very, very, very difficult to do in our automation engineering environment. So the vendors, they try to build something around it, and it works. But actually, what we want, we want to go to the standard tools that everybody is using. Because these standards tools, don’t stand by themselves. People have them build other tools and other workflows on top of them. So if we use a version control of a vendor, we first have to learn this then. We cannot further automate on top of it. So the first thing is the DevOps. Sorry, the first thing is the Git, the version control that we want to have. Another thing we want to have is code generation. So one solution to doing big refactorings, but also at the start of a new project, and actually even over the lifetime of a project sometimes, because it’s so repetitive what we do. So you can have a chemical plant, like 6,000 IO is not a lot in a chemical plant. It’s often goes to 10,000, 20,000 or more. So it will be much more easy. And some people are doing this. Actually, a lot of people are doing this. you prepare your design in a certain kind of format that’s convenient for you in Excel or in Word. And then what people do, they run a script and they try to auto-generate the code. So this works more or less today, but it would be much easier if we have access to the row text files because then all this workflow becomes much more convenient. And then the whole DevOps ID. So we also want to… If we make a change somewhere, we want to be able to click on a button, then the compile happens automatically, especially in a test environment. Because before we go to the plant, we have to make so many changes and quickly test them. But today, we make the change in a document, then we make the change in the program, then we click Download. We also have to download the HMI that we need to press Run maybe. So there’s a lot of manual clicks for every change you have to do. So what actually should be possible, we make a change. You click one button, you wait a couple of seconds, and you start testing. That’s how modern software development works. You change something, you quickly press play. If some things need to be deployed, it happens automatically. Even in some software environments, you don’t even have to click. You change, and it automatically updates real time. So we also need to have this. And then another thing is also testing frameworks. So you know, the way that we test, So because we program everything manually, we have a lot of mistakes, which is normal. If you program by hand, nobody can program without mistakes. But then you have to try to find your mistakes. You know they are there. But you know you cannot just bring your software like this to production. So what happens? We first test by yourself a lot. And then depending on the industry, like in pharma, we just spend months and months testing. David (19:27) Mm-hmm. Davy (19:49) So, and then you need to do another set of tests. need to then test together with the customer. You go to the site, you test again. So, and the software world, like a hyper scale like Amazon, when they write their own software, you cannot imagine that they do like this. They have fully automated test suits that go through every critical thing. They click a button, everything is tested. They make a change, they click the button again, everything is tested again. David (20:18) So something like unit testing doesn’t really exist in PLC coding. Davy (20:19) Yeah, yes, Again, there’s now new developments, but until recently, and still for many systems, it doesn’t exist. And actually, if you look in the absolute number of installed base, for most of the systems, it doesn’t exist. Like, for example, for pharma, I would say 95 % of the installed base in the world doesn’t use automated unit testing. It’s all manual. Most of the things in Big Pharma, it’s manual testing. David (20:55) And then we’re wondering why industry 4.0 adoption is so slow and low. Davy (21:00) Well, I actually posted today on LinkedIn. So industry 4.0, the idea is good. You want to connect everything and there’s a vision of how industry will look like in the future. But what I think is missing is people have not explained that actually we need to bring in modern software development practices. I don’t mean we’re gonna program or PLCs or DCS in Python or something. That’s not what I mean, but the underlying layer. So these engineering systems, they need to be opened up. So they need to allow us to do this version control, to automate the work that we think that needs to be automated, to bring in this concept of automated tests. this has to happen. It really has to happen. We cannot continue automating like this. Now, I already said this a couple of times, so mostly it’s not like this, but quite some vendors are starting to realize this and are starting to bring new engineering environments on the market that do implement all these things. So for example, I can name a couple of vendors. So Siemens is bringing Semantic AX to the market. So this is now based on Visual Studio Code from Microsoft. And it has almost all the things that I just explained. So it stores the text as pure text, all the configuration as I think JSON files. It has a CLI, it has a unit testing framework. And so other companies that work on this are codices. So codices will publish codices go. Backoff will publish PLC++ I think, although that will come in one year. And then BNR will… publish their automation studio codes. I think that’s the main vendors that I’m aware of that are doing this. David (23:04) So I knew that corporate reporting ran on Excel almost everywhere. Now I also know that code generation on the automation layer also seems to be running on Excel for some customers. I’m gonna throw in a buzzword here. Is Gen.ai gonna help us? Davy (23:24) Yeah, so a lot of people now in the automation world and a lot at the vendor side, they say, okay, the future is just generative AI. We implement it in our engineering environments and they will just generate the code automatically. I doubt that will work like this. So basically they are saying, okay, let’s this step of going to modern development tools. We somehow put the generative AI inside our applications that are quite closed, which have proprietary formats. And then we think that this generative AI will figure out everything. But the power of generative AI is that it can train on open interfaces, on open data, and then it can use these interfaces. Generative AI is especially powerful on textual. representations. Of course, it can do much more, but I don’t think that we will just bypass this step that we can say, okay, we don’t need all these open interfaces. And I think we first need to do this. And then on top of it, we will build the generative AI. David (24:35) Yeah. And also I think it’s currently, I’d say, a generative AI on the Gartner hype cycle is currently, I would say, at the top, right? it’s just, I would say we’ve been getting acquainted to what is possible and not. A lot of startups, a lot of companies have invested in Gen. AI. And I think a lot of us are now also, yeah, experiencing that it’s… not the silver bullets. Davy (25:13) It’s very powerful in software development, in modern software development. I heard people telling the explanation why it’s so powerful is because actually the people who design the generative AI, like open AI, one of the first use cases for them is helping with development because they are developers by themselves. So now there’s a bit of the discussion lately, this week and last week, about if the… AI is hitting a bit of a wall. I don’t know if you saw this. But at the same time, they’re saying actually, if you already take into account where we are now, we already have 10 years of engineering work to do to just implement the generative AI everywhere. David (25:45) Mm-hmm. That’s right. Yeah, that’s right. Davy (26:00) But if you think about it, think like that’s not just automation workflow. It’s the whole engineering workflow, how we build and engineer new plans. So we start with a concept design. We go to detail designs. We do the automation engineering, the mechanical engineering, electrical engineering. Then we go to commissioning and then we have to run the plant. I think we are, we probably already have generative AI that’s strong enough. to, for a big part, help us through this whole workflow. But really, to extreme way, where you could say, OK, I want to generate a plant and the AI, if it has the necessary knowledge, if it knows about the processes, and actually they already know a lot of processes, you could, for example, say, build me a chocolate plant, engineer me a chocolate plant. I can already imagine that it first makes the basic design for a big part, maybe a human reviews it. Then it makes a detailed design. Again, human reviews it. It helps with automation. And then finally with preparing everything for the build. Because a lot of the engineering work that you do is so repetitive. It’s so basic. So I don’t say that you’re just going to ask a question to an AI, and it will just fully do it by itself. So what I say, it’s probably possible to build an engineering flow. David (27:13) Mmm. Davy (27:27) and then plug in the AI at all the different stages. And then it’s already at each stage, it probably helps you to, I don’t know, 70, 80 % of the work. So I think we will soon, in the next 10 years, we will come to collaboration between the LLMs and the engineers, and it will just allow us to work much faster. David (27:38) Yeah So really as an assistant, for the, you said, especially for the repetitive work-wise. Davy (27:54) Yeah, because we already see it works for the software development. So I think now this will spread to all kinds of engineering work. David (28:04) Yeah, there is a sidestep I’d like to take. You are involved in an organization called the Society of Automation and Software Engineers. That’s I like very, I think it’s something very, I would say worthwhile to mention here as well. I say, who are they? What’s their role? What was the thing they’re trying to achieve? Davy (28:34) Yeah. So it’s basically at the heart, it’s a Slack group. So it started, I think about somewhere last year. There somebody from Loop. So Loop is a robotic system integrator in the US from Portland. So he made the announcement on LinkedIn. And basically he said, look, he said basically similar what I just explained the whole time. The way that we do automation engineering, it’s It’s a bit rigid. Actually, we should bring in more of these software principles. And he made a call and he said, look, everybody who is interested to combine automation and software, join the Slack and let’s just have a chat. So in the meantime, it has been steadily growing. They did a first meetup at, I think, one of the automation fairs in the US. And then there was the first official on site events. two months ago in Portland. So I was one of the panel members because they invited me because I have quite some interesting ideas. So we were there with, it’s very interesting because there’s people from all different backgrounds. So you have a discrete automation, a robotics automation. So of course the process industry is represented. People who work on vertical farms, on drones. But so basically everybody who needs to be able to, who’s working on the combination of automation and software. it’s not a sales or marketing, it’s a very atypical event. So people don’t go there to present their products. You’re actually not allowed to present your products. So people were just talking about what they were doing. Insofar, they were allowed to talk about it because there were quite some people of very interesting companies. Yeah, so it’s very cool group. So if anybody is interested, go to it’s sase.space, and then you enter your email address and then you get access to the Slack. And I think for the next Hanover Messe, we will probably also try to organize a meetup there. David (30:51) really? That’s interesting. Hannover Messe is in May? Something like that. Anyways, early next year. First half of next year. I actually I should know this. But okay. Anyways, I’m sure the readers can find it when they Google Hannover Messe. It’s a nonprofit, right? It’s actually just, I would say it’s more like a platform to share experience. Davy (30:57) I don’t know. David (31:20) Or do they also want to build something or standardize something? Davy (31:21) EF. So for now, it’s a group. So I think you have to see it a bit as a developer community that’s growing. There will probably be a nonprofit setup because if we’re starting to organize some things, it’s better to have this. So I think Loop is looking into this. There’s encouragement for people to build. We’re still figuring out what we want to do because we don’t just want to be an organization. that makes another set of standards. So we’re seeing where it goes, but it’s really developers who come to this platform. really automation engineers who want to combine software or software engineers who happen to end up in the automation world. David (32:20) It’s like this really famous XKCD comic where you say like there are what was it there are 10 competing standards like let’s make one new one and then a while later there are now 11 competing standards. Davy (32:34) Yes, yeah. Yeah, so no, that’s not what we want to do. But you sometimes see people coming and saying, look, I’m working on this open source project and they present it. Or even not open source with people who start new kinds of companies. That’s really interesting. David (32:58) One of things you also mentioned is the fact that when we’re writing software for the industry, or I would say for physical things, let’s put it this way, when we’re writing software for physical things, we don’t really start at the development phase of the software. We actually already start at the design phase of the asset, of that physical thing, right? Starting to write software is actually the second step. First of all, you want to decide on how the physical thing will look like, how it will work, what sensors are part of it, what actuators are part of it. Can you maybe elaborate a little bit more on that difference? Davy (33:42) Yeah. So what you’re just explaining or where you’re going to is, I’ve been thinking a lot of how to bring these software principles, especially from DevOps to industry and then primarily to process automation because it’s the world I know best. so DevOps, you go from development to operations, but actually in the In process automation, we don’t start at development. It’s not like in software, you have iterative process where you develop and you improve the product over time. So we don’t do like this. We start from the design. So we would, for example, get the PIN IDs from the mechanical engineer. And then we first, before we develop, we write down everything on paper. So on Excel or on Word, and there we are again with our Excel and Word. Yeah, the whole industry runs on Excel and Word. David (34:31) Yes. Davy (34:34) So we describe everything in these documents. And then only after this has been reviewed, often by multiple people, then we go to the development. But basically, if you think about it, everything that we program is written down in the design specifications. Because we would really in detail list all the equipment, but also list all the sequences. We would list the conditions when something goes wrong, what we have to do then. David (34:53) Mm-hmm. Yep. Davy (35:04) So actually what’s already is happening a lot in the industry is people try to code generate based on this, but it’s very difficult. And it’s not very, you cannot often repeat it because you’re stuck with these Excel and Word documents. And often you then have to do a new system. You have to switch from Siemens to Rockwell. So your whole workflow doesn’t work anymore. So what I’m actually now advocating is instead of DevOps, we start from the design. So it becomes DesignOps. David (35:18) Mm-hmm. Yeah. Davy (35:34) And so we work together around the design. We move away from Word and Excel, so we go more to a collaborative environment. We keep the code generation, but with proper workflows. We take in techniques from the software world. Like there’s a lot of libraries that use templating, like the double handlebars. We introduce a better way of managing these templates. For example, we connect them to a private GitLab server or a public GitHub. We generate the code and then also for them to go to the final ops, which initially is first your testing environment. So we make sure that all this gets updated easier. And then finally also to deploy to the production. Still, the automation engineer is still inside the factory sitting next to the machine. But we try to make this whole workflow more easy. So that’s what I have been promoting a lot recently is that we need to go to a system of design ops, not DevOps, at least in the process industry. David (36:41) That’s a super interesting vision. Are we far from that? Is there still lot needed? Are changes needed in the industry? Davy (36:51) I think all the building blocks are there. It’s not a technical limitation. So in the last months, we’ve been building and testing a lot. And it’s actually working. So all the building blocks are there. I’m also, I don’t want to go away from the existing workflows. mean, you might think, okay, this is, you introduce DevOps IDs, this is totally new. No, we don’t want to go away from, we still make our design, we still make it in a similar way. So even though we don’t use Excel, it still looks a lot like a spreadsheet. We don’t use Word or Visual, it still looks a lot like a workflow. And we still use our existing IDEs. So. If we are in the Siemens world, it will be a lot of structured text, which is very common in Europe. Like for Rockwell, we will probably still use a lot of ladder, which is in the US and Canada. It’s very popular. I understand that. So people say, look, this is really convenient to debug. But I don’t advocate to go away from these things. Just make everything automated. Again, to come back to automate automation. We automate our own workflows and like this we come to design ops, which is a bit like DevOps as applied to industry. David (38:23) I wanted to make a short summary myself of our conversation, but I think you did a brilliant job here, Davy. I would say the fact that automation needs to be automated, the fact that I would say design ops is what I like that term a lot. It really, I would say, shows the fact that there is this physical reality there as well. And what I didn’t know was there was also so much Word and so much Excel being used in this part of the world as well. So hopefully we can see that changing in the years to come. Thank you very much for joining this episode. For the ones who want to know more, I’ll make sure to put a link to Davy’s LinkedIn profile. and the SASE website in the show notes. And again, thank you, Davy, for joining us and to our audience. Make sure to subscribe, stay tuned and until the next episode. Bye bye.