Direct Air Capture: From Pilot to Autonomous Industrial Scale

Today on the IoT Use Case Podcast, we’re looking at how complex, novel plants can be built so that they not only work as a concept, but can also be operated under real-world conditions and, above all, scaled. Our guests are Greenlyte, represented by its Co-Founder and CTO Niklas Friederichsen, and ifm, represented by Christoph Schneider, Vice President Product Management. Vision and big plans alone are often not enough; you need functioning partnerships to solve the thousand everyday challenges. Enjoy the episode!

Hello and welcome to the IoT Use Case Podcast. Today we’re looking at how an innovative technology actually becomes an operational plant. Why the bottleneck is not necessarily the idea itself, but very practical topics such as sensor technology, wiring, data reliability, and remote maintenance. Joining me in the studio are Niklas Friederichsen from Greenlyte and Christoph Schneider from ifm. Niklas, making a pilot plant suitable for industrial use: could you describe how you approached this in practice and which plant we’re talking about today?

Niklas

Very gladly. Thank you for the invitation. I’m looking forward to talking with you today about how we bring IoT into the real world. Maybe just one or two sentences about what we do: We are Greenlyte, a company from Essen. We are building on a technology that we spun out of the University of Duisburg-Essen. It is a direct air capture technology. We have a process that allows us to absorb CO2 from the air and convert it into a pure CO2 stream, while also producing hydrogen. This is a technology that was researched in the lab and already worked very well there, showing very good data. For us, of course, it is now important to bring the whole thing to the right scale. And I think that’s also today’s topic: How do you take a technology from “we operate something in the lab” to a largely autonomous plant of the corresponding size operating in the field?

That’s really exciting, this green tech topic, CO2 capture. Could you describe again what the benefits are of implementing something like this? After that, we can move on to the challenges.

Niklas

We are very strongly driven by the mission that carbon itself is not the problem. The problem is digging carbon out of the ground and releasing it into the air in the form of CO2. We strongly believe that, with our technology, we can reverse this path: that we can absorb CO2 from the air into closed cycles, where we provide our gases, meaning our CO2 and hydrogen, for fuels, for example, or for chemicals. Or we can store the CO2 back in the ground in the long term, in order to reverse this effect of “CO2 from the ground into the air.” This will only work if the products we market, meaning these gases, these feedstocks, become affordable and economically viable. To achieve that, the whole thing has to be brought to a large scale and operated very autonomously. That is what we are working on right now. We were founded in 2022, now have 80 employees, and are working at full speed to bring the technology to the appropriate scale. We are currently operating a pilot plant in Duisburg on a 50-ton-per-year scale. The next step is what we call a first-of-a-kind plant in Marl, also very close to our headquarters, on a 1,500-ton scale. We believe that after that, the validation will have been achieved to then roll out this plant design commercially.

That’s already a significant increase from the first plant to the second. Which one are we talking about today: the first plant or already the expansion stage?

Niklas

When it comes to what we’re discussing today, we’re not really thinking so much about one specific plant. We have always said: What moves from the lab to the prototype has to be designed and built, in terms of IT infrastructure, in such a way that it can be transferred to large plants. I come from software development; before this, I helped build two companies where we developed software for B2B applications. For me, it is clear: Software is not built once and then simply operated. Software has to be continuously developed in an agile way. For us, it is extremely important that we already learn on our small plants from every sensor and every control logic in such a way that we can later roll this out very robustly. So when we talk about integrating the ifm solution, we always think about it on a small scale, but in a way that can be transferred one-to-one to the large plants.

When we get to the challenges: In the lab, it worked really well; now comes the reality check. Scaling, making it bigger, operating it reliably on an industrial scale. Where would you say the biggest challenges are, the most exciting areas?

Niklas

I wouldn’t say there is one major challenge. Overall, it is a relatively complex system. Topics that are very simple in the lab, such as dosing, are not quite so trivial outside on a large scale with the corresponding temperature fluctuations. That’s where it is important, and that’s where we exchange ideas with ifm: Even something like a level sensor, meaning how you determine whether a container is full and how full it is, becomes a not-so-trivial problem when foam formation comes into play, for example, and media change in their parameters. And we have many such issues. From the beginning, it was important to us not to say: “We’ll learn this manually for now and digitize it at some point later,” but to transfer it into a digital infrastructure from the very beginning. Problems we had two years ago, where it was challenging to automate certain dosing loops, are now already so strongly standardized that we can roll them out from one plant type to the next.

That’s not easy, especially at such an early stage with changing requirements. Christoph, turning to you: Were you actively looking for challenging start-ups that you could support? Did Niklas approach you? This is not exactly your standard business. You have to act differently when working with a start-up. How did this come about?

Christoph

Working with a start-up always means being able to react quickly, understand things quickly, and implement them quickly. Of course, that is different from working with an established company that has been planning for a long time how a plant will be built and what things should look like. That is also a challenge we take on: approaching things with our customers in a solution-oriented way in order to implement them, and also being able to react quickly. If you see that a level system does not work in this tank because it is too strongly affected by foam, and you didn’t know foam could occur, then you have to switch, use a different sensor principle, in order to commission the plant quickly or operate it safely. In working with a start-up, that is always a challenge. My colleagues have to react quickly, be on site again and again, and make sure these things are understood and implemented immediately. That also includes understanding: What can I do? Not just saying in general terms, “Pick something, we’ll have something that will work,” but understanding the specific problem and saying, “We have exactly the right thing for this.” And then improving it in detail when you realize: The process behaves differently after all. Everything was fine in the lab, and when the plant is outside, it behaves differently. These are the things you have to implement quickly.

We’re not talking about one sensor, as far as I understand, but many. Niklas, could you describe the complexity of the plant again? You also talked about software, but hardware and sensor technology are certainly major topics as well. Describe the plant in terms of its complexity.

Niklas

We don’t talk about problems, but challenges. The complexity basically comes from two directions. First, we think of our plant very strongly in line with renewable energies. Our process for removing CO2 from the air and producing hydrogen and CO2 is a relatively energy-intensive process. The aim is to remove net CO2 from the atmosphere, which means that the energy used has to be renewable. Renewable energy has the characteristic of not being constant, but subject to fluctuations. That means our entire plant has to be designed in line with renewable energies, which makes the whole thing very dynamic. Second, in the direct air capture process, we have a procedure where we do not define the operating parameters ourselves; rather, the operating parameters are determined by the environment. Parameters such as relative humidity and temperature are externally given. Our plant has to dynamically adapt both to the availability of affordable energy and to the parameters of the environment, which makes the control concept relatively demanding. We absorb in a liquid, which means we are at home in classical process engineering, and we desorb in electrochemistry, which means we are very close to the world of hydrogen electrolysis. These are two very different schools of thought in automation and control, which we have to bring together. There is nothing in there, and this was also important to us at the beginning when we decided to spin out and scale this technology, where you would say: At this one point, we need the ultimate breakthrough. But taken as a whole, it is a challenging control task, because I have to bring the question of “How do I buffer over longer periods?” and “How do I make ideal use of changes in the environment?” very closely into line with process control.

And it’s not what first comes to mind, like a kind of battery, where you say: If I have load peaks, I transfer everything into liquid fuel and convert it back later when electricity is needed. This has other aspects.

Niklas

Exactly, it is not the classic battery. The lifecycle “electricity to fuel back to electricity” is not our goal. It is more about supplying processes that will depend on fuels or hydrocarbons in the long term with green raw materials, and producing them in such a way that renewable energies are used as ideally as possible. You have this fluctuation aspect, like a battery, on the power consumption side, but it is not about converting the energy back into electrical energy.

Christoph, could you speak about the individual challenges, the sensors, and the difficulties? What was unusual compared to your other activities?

Christoph

The variety of sensors, of course: optical sensor technology, pressure measurement, differential pressure measurement to monitor filters or membranes. It was also about levels and temperatures at different points, bringing all of this together. One key point was that we collected everything via IO-Link and forwarded it to the corresponding controller. One challenge was also that ifm does not have all sensors in its portfolio, for example no pH sensor. Integrating these things, clarifying what is actually needed, and combining it into one concept. Not saying: “We only have these three, and you’ll have to take care of the rest yourself,” but helping to shape this as a solution, helping to commission it, parameterize it, and store the parameters so that these parameter sets can be reused when transferred to the next larger plant. These are things that are important in order to scale the whole thing for the next plant and continue using it.

Starting with IO-Link as a topic: If someone is not yet familiar with it and you say it was something special to introduce and use it, could you explain it in simple terms? What is IO-Link for listeners who have not heard of it before?

Christoph

IO-Link is basically the digitalization of the last meter of cable from the controller to the sensor. In the past, you either used digital signals, meaning switch on/off, or transmitted an analog value, with all the issues involved in transmitting that analog value into a controller. With IO-Link, this is digitized: You no longer have losses like with analog, and you have the ability to receive more than one piece of information from a sensor via one cable. A flow sensor, for example, provides temperature, pressure, flow, and also a totalizer via IO-Link. This means I have more information from the sensor and can implement and use it differently in my system.

Niklas

In terms of wiring, we have an IO master that sits relatively close to a group of sensors at our absorption unit. We route from this IO master to the controller, which greatly reduces the amount of cabling that has to be laid on the construction site. At the same time, we are more flexible and can replace sensors more easily, which happens again and again in our case. We are constantly optimizing our systems, and with the IO-Link system we are very flexible when it comes to replacing sensors. Of course, we discuss what might make sense, but in the end you have to try it out, test new solutions, look at it together via the digital interface in moneo, and perhaps realize: That was not the ideal path; we’ll go through another iteration. That is what differentiates us as a start-up: We can try things out quickly, explore possibilities, and readjust, where it would be more difficult in other types of organizations.

If we transfer this to other types of plants: Do you have any tips on how you test sensors to see whether they are valid? Do you monitor this over certain periods? Do you sometimes install different sensors that measure the same thing in order to compare them? Are there approaches to testing sensor technology so that it works reliably? Did you have problems with data?

Niklas

Of course, anyone who integrates sensor technology will run into problems somewhere. I think our problems are no different from anyone else’s. We calibrate sensors. We now have a very rigorous approach to factory and site acceptance tests, where we check every single sensor during commissioning. That is industry standard. We have not taken any special paths there, at least not that I’m aware of.

Is there also the occasional innovative approach?

What is standard and everyday practice for us is not lived everywhere, and not every partner goes along with it: Everything that is a relatively small prototype in our case has remote control. All our test rigs and plants feed their data into the same data lake. Accordingly, we are able to look quite precisely at every test rig, at what each sensor is doing, what data it is delivering, and review it together with people who understand sensor technology even better than we do. We are able at any time to access every sensor in our infrastructure, which now comprises several hundred, and read out data, also via moneo, that goes beyond what is fed into our controller. That is certainly an advantage. For us, it feels normal because it is lived practice, but I’m not sure whether it is done that way everywhere.

Christoph

Digitalization is often still a foreign concept, and in many areas of industry it is not yet practiced consistently; sometimes out of convenience, sometimes because people are not used to it. What characterizes this project is that we have the combination here where we can remotely access controllers, make changes to controllers via the moneo cloud, and at the same time have historical data and see what happens afterwards. I can analyze how the plant is running: Is it running when enough energy is available? What does it look like over the course of the day? I can analyze such things and optimize the plant. Especially in a project like this, the optimization process is practically a daily task. If I have this data, I can do more. This has to be pushed further in industry in the future. Only if I have a good data basis through the sensor technology, through data that is actually available to run analyses, beyond what goes into the controller. Often it is the case that in the controller I only want a limit value, for example for a temperature, because the plant should then shut down. But I want to track the temperature: What happened before it shut down? Did an error occur somewhere? We try to publish these things through projects like this and discuss them with our customers in order to highlight the benefit: What does it bring if I digitalize, communicate with IO-Link or other bus systems, and record the whole thing?

A term that has come up several times is moneo. Could you explain that in more detail for listeners who do not know it yet? What is moneo, and how does it come into play here?

Christoph

moneo is now a cloud platform. Through moneo, I can parameterize sensors, either remotely or directly with a notebook at the sensor. I can transfer parameter data to the sensor and save it. On the other hand, through moneo in the cloud, I have the ability to gain remote access to the controller. That means: I’m sitting in the office and can use the controller’s parameterization software to directly access the plant and the controller and program it. At the same time, I have a channel through which I can transfer process data to the cloud and perform pre-calculations. For example: I have two pressures and want to calculate a differential pressure that is important for monitoring a filter or membrane. In moneo, I can calculate the difference from the two pressures and monitor it. Or: I have a certain geometry of a tank, enter this, and then I don’t just have “level half full,” but I know: There are 238 liters in this tank. I can calculate and visualize that via the software platform and add alarms. This goes as far as the fact that we have now also integrated AI, which performs anomaly detection. In the future, this will bring further advantages for systems like these. At Greenlyte, it is not yet integrated, but once plants move further out of prototype status, you have the chance to detect anomalies and intervene early so that the plant runs safely and stably.

Niklas

We have a BOM manager, meaning a piece of software that we wrote ourselves, in which we manage revisions of our plant. Every component change in our plant leads to a revision. This is managed in our systems engineering. If someone in systems engineering replaces a component or, for example, a tank, then this component carries parameters with it, and this tank then has, for example, the parameter volume. If a level sensor carries an IODD, meaning an IO Device Description, we can change the parameter via moneo. The systems engineer can change the parameter, and the whole thing can be pushed to the controller and from there to the IO master. Basically, I can carry out a revision of our plant without having to write, push, or release a single line of new code, but solely through configuration in the moneo platform. At first, this is a relatively small step in relation to one sensor or one change, but in daily work it is important because we are not operating one plant, but now eight plants. Our teams are set up so that small teams with a lot of responsibility are each responsible for one plant. Wherever we do not need a handover from one discipline to another, where one person in process design or systems engineering can carry out the revision themselves, we gain speed. It makes things more pragmatic, and there are fewer handover points. With the sheer number of changes and sensors, every change that takes one day rather than two helps us learn faster.

I find this use case exciting because precisely this “from pilot to industrial plant” topic addresses many points through its complexity and the partnership between you: sensor technology, selection and monitoring, a cloud platform. Niklas, could you say something about your partnership? How does it work, what is important to you, and how is it developing further?

Niklas

Because we are organized in such a way that there are always people responsible for a plant, we have clear responsibilities: Who gets this plant running, who is responsible for the next revision. We have not organized it so that we have one central ifm contact person and, whenever someone at the plant is struggling with a sensor, they first have to go to that person, who then contacts ifm. We live the exchange in such a way that everyone who is responsible for a plant on our side can access all systems, has a view of the electrical design, process engineering design, and software, and seeks direct contact when problems arise. Even at the risk that a similar problem has already been discussed before. For us, speed is a currency. The faster we give a team, when solving a problem, the opportunity to say: “Call them, clarify the problem, log into moneo together, take a look, and bring the plant back into the target state,” the faster we can tackle different problems simultaneously with relatively small teams. We know that we can do much more. The platform is extremely powerful, and we are not using the full range of capabilities. But we manage this flexibly: What makes us fast in our daily work? We exchange ideas regularly, about once a quarter, to understand what else is possible. At the same time, we have to prioritize very strongly internally what specifically helps us right now.

If you look to the future and assume everything goes optimally: How scalable is your technology? Do you expect every large factory to have such a plant on site because it has solar systems on the roof and uses your plant as an addition? Or rather selectively, one plant per federal state? Looking globally: How big will your business become, and how dynamic will the plants remain?

Niklas

It can scale almost without limit. If you look at the oil and gas industry, you see scales that are hard to imagine. We strongly believe that humanity will not stop consuming hydrocarbons. So we have to replace the sources of hydrocarbons. That means we will need a great many, very large plants. These plants will be located where the expansion of renewable energies does not compete with farmland, because the advantage of the technology, both hydrogen production and our technology, is that it is designed to be geographically agnostic. I believe that globally there will be clusters where it makes economic sense to build these plants on a large scale. This technology is almost infinitely scalable. The larger the fleet of plants becomes, the more important it will be to understand exactly: What maintenance cycles do I have? How do maintenance cycles differ depending on the location? If I am closer to the sea, I may have to service components sooner than in a dry region. The topic of pattern monitoring, meaning knowing when, for example, a fan starts to run unevenly and being able to detect that earlier via the platform, will have great value for us, because maintenance cycles are a major cost lever in the process industry. At the same time, this is not yet the huge lever for our plants in Duisburg and Marl. That is exactly what I meant: We want to understand where the journey can go, see potential to expand this further, and at the same time have to look at what specifically solves problems for us in the plants today and over the next one and a half to two years.

Christoph

If the plant is in Morocco one day, or somewhere in the middle of the desert, because that is where the sun is and enough energy is available, then you can’t just quickly get in the car and check the fan. You have to monitor remotely, record parameters, and receive alarms so that you have personnel and materials on site in time to avoid downtime or to operate components for as long as intended. These are things that will become extremely important in the process industry in the future.

I’m excited to see how this develops. I’d be happy if we could speak again in a few months or years about what you have learned and how many plants will then be in Morocco and elsewhere. Do you have any final words, anything I haven’t asked so far?

Christoph

I think it is extremely important that this switch also takes place in everyone’s mind: that you think these things through already on a small scale so that you can then scale the whole thing later. You should not first build something and then start saying: “Now I have to digitalize, now I need these things.” That is a point that has to increasingly make its way into industry.

Niklas

From our perspective, it is important to invest in infrastructure in such a way that you enable people or teams to cover a very large scope independently. The advantage of such systems is that you do not need five or six handovers, as was often the case in the past, which makes processes expensive and time-consuming. You build the infrastructure in such a way that a lot can be solved through configuration, where in the past you might have had to replace hardware or write software. This allows you to keep teams relatively small, agile, and dynamic. We see the great benefit in investing relatively early in infrastructure that will scale later, and not in trying to think up and build the infrastructure while already scaling. Doing both at the same time is a complexity you should avoid.

Great. Thank you very much, dear listeners, for staying with us until the end. Thank you very much, and see you soon.

Niklas

Thank you very much.

Christoph

Thank you.