Defining software in the realm of automation – Podcast Transript
Software is permeating every industry around the world, but to talk about how it is impacting the realm of automation and the factory floor, we’re talking to Rainer Brehm – the COO of the Automation Business at Siemens and the CTO of Digital Industries.
Nick Finberg
00:09
Welcome to the first episode of the Future Ready Podcast from Siemens. We’ll have lots of amazing guests and a handful of rotating hosts and moderators to cover a wide variety of topics, but today I am Nick Finberg, and I’ll be your moderator for all things software-defined. Today we have Rainer Brehm, the Chief Technology Officer for Siemens Digital Industries, as well as the Chief Operations Officer for our automation business. Rainer, it’s great to have you here, and I really appreciate you taking the time out of your busy schedule to co-host the series. But the stage is yours. What do you want to say about software-defined?
Rainer Brehm
00:41
I don’t know whether it’s the right thing to say to demystify a software-defined automation, but I think everybody talks about it and uh it’s such an important thing because it lays the foundation for also when we move into a more adaptive autonomous production. And um so I think it’s about explaining what it is about, where to start. what it means, what would be the future, and how it fits also into the story around uh AI, which is in in everybody’s mouth. Yeah. So that’s the reason I think it’s makes very much sense to you know um have a deep dive on that topic.
Nick Finberg
01:15
Awesome. Thank you so much. Well, we’re going to start off this first episode talking about kind of a high-level understanding of what is software defined and what your views are on this topic. So, let’s start off with that first question. Automation is kind of the backbone of industrial manufacturing. But today we hear more and more about automating the automation. What does that really mean?
Rainer Brehm
01:37
If you automate today, you’re writing a code, you write a program, you tell the automation what needs to be done. And um Where out maybe to start, where automation comes from. Automation uh is in the f mainly done in the factory and maybe in some infrastructure projects. People which did automations and still doing automation today maybe are coming more from the electrician side. So, people were doing the wiring and then doing some programming.That’s the reason why how you program a PLC today is a little bit like it’s a It’s a wire diagram. It’s called letter logic. And that’s a way how you think and how you do that. But still, you need to say like a wire diagram. This is how it looks like. And then you’re gonna test it and then you’re gonna execute it. When we say we want to automate automation, we want to automate this. We want to automate how automation is engineered and programmed, and we want to make automation much more flexible. That means you want to go away from a rule-based automation where you need to know everything up front into a more goal-driven automation and in goal-driven workflow. So that means the next level of automation is we might automate the unknown, the unpredictable, because automation is smart enough to react on certain aspects. without being pre-programmed for that. And that is what we mean by to automate automation. But we also see that Getting that flexibility in enables not only a much flexible automation program, but it enables a much more flexible and modular production and production system. Which lies then the foundation for applying AI, which moves us into autonomy. So automated automation means using software-defined automation to be more flexible. But also, in using new technologies like digital twin and industrial AI to change the way how you connect the design phase and the production phase.
Nick Finberg
03:47
Okay, so you talked a little bit about the AI disruption, and the constant change a little bit, but what’s the strategic role of software-to-find solutions in this shift? Why is it so relevant?
Rainer Brehm
03:56
Well in the past and normally our customer says, well, I did a start of production, now it works. And then never change a running system. So, keep it stable, don’t do anything, keep it running. Even so far, don’t switch off the power because we don’t know whether it starts again. So don’t do anything because it works. And today if you look at a software development, you’re constantly changing. You talk about DevOps. You are you’re doing something and you you’re testing it, you have a full delivery pipeline, and the customer is using it to get feedback. So, what you want to go in a continuous improvement. And that’s important for our customers because they need to test out also what they produce, how it fit, how it works, how they get more productivity. how it fits the customer to their customer demands. So, you need to be much more agile in in trying out new things and going away from a Never change a running system in constantly improve, adapt, modify uh your system. And there it cannot be done in changing the hardware all the time. That changes can be done, need to be fast. And software development is very fast. You change a line of code and then you deploy it and it runs. And so a lot of these new features and functionality, our customer needs will be software uh defined.And You see that not only in the in the in the manufacturing space or production space, you see that everywhere. And look at how uh televisions look like today. Television has a lot of software built in and you have apps and you can change apps and if you have when you streaming a thing comes up, you’re gonna have this new app and stream it. Uh the same looks at cars. Classical cars are more software defined. You get updates on your car; you get new functionality in your car. So, we see that um in a lot of a lot of a lot of um devices and that also means now we move more into software-defined uh production because the production is building those products I just talked about.
Nick Finberg
06:10
Okay, okay. So, when we talk about software-defined everything, what exactly does that cover? Is there a limit?
Rainer Brehm
06:16
I wish there would be no limit, and you can do everything with software. Uh but I’m also realistic. automation plays in the interaction of the physical world and the in the in the digital world. And um My wish would be, for example, a software-defined everything could mean you can download or even a system smart enough to fulfill any action. But you know, being now realistic, if there’s a robot and uh a robot and you want to grip something and you need to have a gripper, and the gripper needs to fit to the to the thing you want to g uh grip. From a dimension perspective, from a weight perspective. So, if I make everything software-defined in the gripper, the mechanic simply doesn’t fit. I think it’s hard to do software defined. So yes, there are limitations for sure, but um I think where we are and where the future is, we not at all have leveraged the potentials of software-defined. um in the in the automation space. And the software defined also goes not only kind of you know from a from a from the mechanical perspective, that we have much more functionality in software. It also goes a little bit into the topic around how you do it. I was just mentioning that that in the past the automation was mainly done by electrician. So, if you now look at the markets, and if I if I want to have an electrician at home because something is not working anymore, I I’m on the waiting list. So, they are not around the corner and say, now I do it. Probably I find more software developers than electrician currently. So that means also the way how automation will be done will be different. It’s not the electrician mainly anymore. There will be a lot of software developers which are writing software for automation, which are writing software for the real world, which are writing software for physical devices. And we need to make this physical world accessible to software developers, um like they can do software development for all kind of apps and programs they’re writing. And that excites me because you know you can create real-worldimpact in the physical world and we make it accessible to a broad community of software developers. I mean that’s really great. But in order to do that, we also need to, you know, enable the tools we have like software developers want to work. And that’s another topic around software definition. Not only the execution of the task, it’s also the engineering of that task.
Nick Finberg
08:50
Yeah, would you mind going into that in a little bit more detail? What exactly does that entail, building out that infrastructure?
Rainer Brehm
08:57
Well that that that means um on the on the engineering side, um how you do so uh modern software engineering, you basically uh you you’re programming it, then you store it in a repository, you have a you have version control, then you if you want to deploy something, you have a build, you test, and then you do uh kind of on a DevOps, you’re going directly in production. So, I have a completely different development repository deployment mechanisms like you have maybe today on an automation world. And I think we need to adapt that, and m make it maybe even command line first. And a lot of a lot of programming is done automatically anyway. So, no it’s not somebody writing a code anymore. Maybe it’s an agent or somebody else, yeah, who’s with who is writing the code. So therefore, we need to adapt that into we do it today. So, GitHub, for example, or GitLab is a repository and it needs to be used not only for software development but also for automation. And the same accounts for deployment pipelines. You want to deploy topics in a mass deployment like you do, for example, today. You’d write an app for a phone and then deploy it massively. So, we need to get this environment also into the automation world. I mean, number one. Then we need to leverage data much more. Because I think currently um the data is mainly used in the automation side to control something. That’s a primary task to do something. You control a machine or you do something you read inputs you do an action and then you write it to the outputs but this data have a secondary uh use you can use them to analyze it what’s going wrong you can use this data to further optimize So we need to also make this data available. Yeah, this is also something we need to change if we go into software defined automation. And then on the execution part, currently a lot of automation is done in a in a very closed embedded system. And I think we make need to more decouple that inference or that execution of the of the automation task, that workload can uh to different platforms. It can be still um embedded. It can run on an industrial PC, it can run on a virtual machine on an industrial PC, it can run on a virtual machine on a on a on a local server, or it runs somehow umin the cloud. So, there is also a detachment of that workload from the from the from the hardware uh it runs on. And that accounts for um classical PLC workload, as for AI inference, as for maybe um topics around operational software like a SCADA system and others.
Nick Finberg
11:43
Thinking about where to augment and how to scale. That’s super interesting. And it rings so true for the design side of production as well. Um but I think we’re gonna take a break here for now and we’ll be back with the next episode to pick up on some advice for companies looking at are already on the software-defined journey. For our audience, be sure to subscribe so you don’t miss it. And until then, you can check out the links in the description to learn more about software-defined.
