IoT Low-Code on the Shopfloor: Machine Data via OPC UA into ERP

Today on the IoT Use Case Podcast: IoT Low-Code for Blue-Collar. Or more precisely: a configurable platform for the Internet of Things that can also – and especially – be used by employees on the shopfloor. Our guests today are Peakboard GmbH and GIESSER Messer. We learn how to start small and scale in a meaningful way. And today, we take a sharp look at our use case. Enjoy.

Welcome to the IoT Use Case Podcast, the channel featuring the latest IoT projects from real-world implementation. Hello and welcome to the IoT Use Case Podcast. I’m your podcast co-host, Dr. Peter Schopf. Joining me in the studio today are Thilo, Head of Development at Peakboard, and Björn, Production Manager at GIESSER Messer. Thilo, let’s start with you. Please introduce yourself briefly. What are we going to discuss today?

Thilo

Hello Peter, my name is Thilo Brosinsky. At Peakboard, I’m responsible for software and product development. Today, we’re going to look at what Peakboard is and how it is used in this case at GIESSER Messer, and what can be achieved with Peakboard.

And where is Peakboard based?

Thilo

We are based in Stuttgart, although we work in a very distributed setup. Especially since COVID, we’ve become quite decentralized. We have offices in Stuttgart, Leipzig, and Chicago. Personally, when I’m in the office, I’m usually in Stuttgart. But like today, we often work from home.

Very nice. Björn, you are Production Manager at GIESSER Messer. How long have you been with the company? Tell us a bit about yourself and your company.

Björn

I’ve been with Johannes Giesser Messerfabrik GmbH in Winnenden since 2011. We are one of the leading manufacturers of professional knives. “Professional knives” refers to everything used by professionals working with knives – primarily in the meat-processing industry and skilled trades, but also bakers, chefs, confectioners, basically anyone working with knives. We manufacture our knives here at our site in Winnenden, not far from Stuttgart. That’s also how the connection came about, through a friend who works at Peakboard. We joined Peakboard at a very early stage, already with the first version. We were almost customer number one. Thilo, you can correct me if that’s not entirely accurate, but at least we were among the first users and were partly involved in ideas and developments at Peakboard.

Thilo

Absolutely. There weren’t many customers before that. As you said, it came out of a personal connection, basically within the first year of Peakboard’s existence. Peakboard has now been around for ten years, so GIESSER Messer has been with us for quite some time.

So we’re clearly among Swabians here. I grew up in Schwäbisch Gmünd and later moved to Bavaria, to Erlangen. That’s where some of these connections come from. Especially in the early phase, it’s important for many new companies to have a friendly customer, a pilot customer, to build something together. How did things start for you? Did you have a specific problem? Ten years ago – do you still remember the initial situation and how things evolved from there?

Björn

Peakboard initially had the idea of a welcome board – essentially a configurable display in entrance areas or parking lots. But I come from a technical background, and because I had contact with one of Peakboard’s lead developers, I said: I need this to be more technical. So we defined a few use cases. Very quickly, this involved interfaces like OPC UA, machine interfaces, reading machine data, and extracting data from an ERP system. Since this was also a specialty of the Peakboard founder, the ideas were well received and picked up. We started with the first Peakboard device. In terms of pricing, that was a topic for some people at the beginning: “Such a small box…?” There was some skepticism, including from management. Another employee had solved things using a small Raspberry device. That’s obviously a different price segment, but it also comes with completely different functionality. We started with the first board and a fair amount of skepticism. I’m someone who focuses on doing rather than theorizing. In production, I prefer trying things out. If it hadn’t worked, I would have dropped it immediately. Peakboard then developed into a success story in our operation. After the first board, ideas started flowing, and the former skeptics are now our power users. Today, we operate 14 boards. We’re a small to mid-sized company: 100 employees, two plants. By now, there’s technology attached to every machine and in every production area. Just seven days ago, I rolled out an entire template into live operation. It covered working time and production completion tracking at employee level, making completion times transparent. We are extremely flexible with this solution and can map almost anything.

That sounds very promising.

[05:59] Challenges, potentials and status quo – This is what the use case looks like in practice

How would you define a board, or Peakboard itself? What does it look like, what does it do, and what could you do with it? Then we’ll come back to Björn and what he actually does with it.

Thilo

At its core, Peakboard consists of three components. First, there is the Peakboard Box, which Björn already mentioned. It’s essentially a small computer that you connect to a display via a standard HDMI cable. Then there is the Peakboard Designer, which is really the heart of the system. It’s the software used to create custom applications. It’s a low-code platform that allows you to build very different kinds of applications. We originally came from data visualization and dashboards. That was Peakboard’s starting point. Over time, this evolved into the ability to build complete applications. In principle, you can gradually build your own MES system with Peakboard – without having to bring in a large system integrator – by implementing exactly the applications that are relevant to you. Typically, you start with a blank screen and connect data sources: an ERP system, a machine, an Excel file, a database, whatever you need. You can visualize this data, create terminals for shopfloor workers to enter data or write data back to ERP systems, and so on. These applications are then deployed to a Peakboard Box, where they run locally. The box is connected to a display, for example a touchscreen at the machine, making these applications available directly to shopfloor workers and employees in the field.

Low-code is a very exciting topic. Low-code means you don’t need someone who has formally learned programming; you can build things yourself. With other providers, expectations and reality sometimes diverge, and things become quite complex. How is it with you? Who actually “programs” these Peakboard boxes?

Thilo

Low-code is indeed used very loosely today. Anyone who does a bit less traditional coding tends to call their software low-code. At Peakboard, the approach is that everything can be implemented without programming. You connect data sources, then drag visual elements – charts, buttons, text boxes – onto the screen and create logic to write data back. There’s a puzzle-like principle where you assemble logic blocks. For example: if someone clicks a button, write this value back to the MES system. This is now also supported by AI, so you can tell the Peakboard Designer what you want to do, and it automatically generates the logic. This means the system is truly aimed at people who want to solve their problems – not necessarily IT specialists. And today we have the perfect example: someone responsible for production who needs to solve real-world problems.

You mentioned AI, which of course caught my attention. Do you differentiate between classic AI, where models are trained on data, and generative AI that configures flows and applications?

Thilo

Exactly, that’s the point.

Björn, is that really how it works in practice? As a production manager, are you actively “programming” dashboards from the machines? Who does that at your site?

Björn

Not just occasionally – actually quite regularly. I’m one of two people Thilo refers to as “power users.” I feel honored by that, because it’s true: I don’t come from a programming background. I had zero prior experience operating or programming such dashboards. But if you’re interested, it’s very intuitive and easy to get into. About 80 to 90 percent of applications can be implemented using drag-and-drop and predefined components. That’s very straightforward. At the same time, I also have the option to implement real scripting in the background. We’ve now connected all our machines. Most of this is done via OPC UA, but Modbus also works. You can directly connect Siemens controllers. We’ve integrated our first BACnet controllers in building automation. We visualize our energy management system. Quality records are written in the background to an SQL Server that Peakboard delivers as part of the hub. This puts us in a very broad position: pulling data from ERP systems and transferring it into different views on the boards, customized for each machine. That worked very well for us. The first board displayed production data: daily output within a defined responsibility area. That was the first time at GIESSER that a production number was made transparently visible on a daily basis directly on the shopfloor. Initially, people said: no one cares. Then something happened. The oldest employee – someone I assumed wouldn’t care anymore, with less than a year left until retirement – came to me after three days. Before that, the display had always been green. Then the daily output dropped below target, the display turned red, showing the number of units. He was the first to ask: “Why didn’t we reach our target today?” That showed me: if you provide the right data – without overloading people – it has an incredibly motivating effect. Not “you need to produce more,” but genuine interest in what someone does, how they do it, and what output is required to operate economically. Ultimately, every single workplace depends on that. This was a key moment, also for management. They said: great, then let’s do this in another department, and we need the numbers there too. From there, things grew quickly. We pushed machine manufacturers, especially regarding OPC UA: we need OPC UA interfaces in the machines. Initially, they said: “No problem, we can do that.” Then it turned out they couldn’t – at least not properly. Today, it’s standard. Some machine manufacturers even refer to it as the “GIESSER standard” when delivering new machines. They know exactly what’s required. We then installed boards on all machines: process data, media temperatures, key parameters comparing target vs. actual, cycle times – all of which support quality orientation. A lot has emerged from that. The second major topic is energy management. Boards are now installed in production showing energy values. We go as far as controlling machines by load. When machines are throttled or switched off, this is visualized along with the reason, so there are no questions. That’s also a critical use case.

That’s extremely interesting. You touched on many topics. Especially pull production: just to make sure I understand correctly – the next production step tells the previous one what it needs. That way, everyone knows exactly what is expected and where things are headed. Is that your definition of pull production?

Björn

That’s exactly the definition. We work primarily on a weekly rhythm. Everything that needs to be completed within the week is defined, and the following week is already displayed, so in practice we are always ahead of time. I personally tend to be very “firefighter-like”; in other words, you need to stay ahead of the situation. This can be transferred to industrial production, ensuring delivery deadlines are not missed. We achieved this very effectively and became almost completely paperless. The number of accompanying documents was reduced to almost zero – only what’s absolutely necessary remains. That way, if a system ever fails – and even the best system can fail – no one can say: “I can’t continue production.” We have a small fallback window of one or two days. After that, we need current data again. Today, if I enter an urgent order, the system immediately shows shortages all the way to the first production step. Workers know instantly: okay, material needs to go to the laser now, and we start from raw parts through to final production.

Thilo

I’d like to pick up on the topic of system reliability. This is a very important point for us. When you introduce a system to control production and visualize data, you cannot afford downtime in a production environment. That’s why Peakboard is built as a decentralized system. The entire application runs on the Peakboard Box located next to the display. Other systems are built centrally, with a server that distributes displays elsewhere. If such a server fails or the network connection drops, production can come to a standstill if the system is production-critical. With Peakboard, the focus is on decentralization. You build the application in the Peakboard Designer, deploy it to the Peakboard Box, and it continues to run autonomously. Of course, if you access an SAP system, you need connectivity to SAP. But the application logic itself runs locally. Ideally, you keep one or two spare boxes in reserve. Then a failure affects only one station, not the entire company. A second important point: many providers force users into the cloud. With us, the user decides. We offer a cloud option, but we also fully support on-premises setups. Because once you depend on the cloud in production, it becomes critical. If the internet connection fails because someone accidentally cuts a cable outside, the cloud is gone – no matter how securely it’s designed.

On the topic of central versus decentralized: did you arrive there by coincidence because you started with boxes, or was this a deliberate decision? How did that come about?

Thilo

It was a deliberate decision. We don’t want to force users into a server-client architecture, because that always creates a single point of failure. The second advantage is that you can start small. If I want to start a project, I don’t have to involve IT to set up a server first. I can start with a single Peakboard Box, create an application for it, and get going immediately. With a small investment, you can solve the first problems.

I find that very compelling. Customers often struggle to get started because they first need data transparency, supplier alignment, and staff training – it’s always a major hurdle. And in the end, there’s rarely one single killer use case that pays for everything. What I found very illustrative in your case is that while pull production is one use case, you’ve achieved many smaller wins. Many people look for a gold bar, but in reality, it’s often many small benefits – gold grains – that add up to a handful of gold. That’s hard to sell upfront, because management often looks for the gold bar. Does that image fit your journey, Björn?

Björn

I love that image and call it “scaling systems.” You always start with something, break the ice with employees, management, and decision-makers. Our structures are relatively flat, so I don’t need excessive persuasion. But often the issue is that systems are very large, and it’s harder to convince someone to invest 50,000 or 100,000 euros. And you’re right: there isn’t one single factor you can calculate and say: “This saves X amount.” First, you need acceptance. That’s exactly where this approach shines: with the first board, you already create an application that solves a significant part of a problem. That paves the way. And you end up with a system you don’t have to throw away. It’s a modular system that builds on itself. You don’t need the hub from day one. But when you install the third, fourth, or fifth board, the hub becomes relevant. Then we’re back to the central element: many islands are managed and monitored through a central instance, including update management. This is done in a controlled, manageable way: system reliability, notifications when a board fails. If a board fails, you pack it into the spare box on the shelf, send it back, and usually within one or two days – with the right service level – you have a replacement. If you operate 13 or 14 boxes like we do, keeping one spare on the shelf means you can restore operation very quickly: plug it in, deploy the visualization, and it’s back online. That gives you resilience. What’s important is scalability without having to rethink everything or throw it all away. That’s what I find so appealing.

“Scaling systems” is a great term. Thilo, you’ve talked a lot about GIESSER Messer. Where else are you active, and where might there be limits? Do you see boundaries where the system is no longer suitable? Give us a few examples.

Thilo

I’ll address one point first, since Björn mentioned the hub. Earlier, I said Peakboard consists of three elements: the Peakboard Box and the Designer. If you paid close attention, you noticed something was missing: the Peakboard Hub. It’s a server application that can be used on-premises or as a cloud variant. It provides a central instance where all devices can be viewed and managed. What’s important to us is that even if the hub fails, everything continues to run autonomously. The logic runs on the boxes. But you still benefit from centralized management. As for your question: in terms of industries, we’re not limited. We operate across many sectors – mechanical engineering, knife manufacturing, food production, automotive, and more. We’re broadly positioned. In terms of use cases, almost anything is possible, although that’s hard to generalize. One area where we’re very active is the digitalization of shopfloor meetings. That works well because you can connect various data systems and also write data back. Then there’s downtime tracking: reducing downtime, production data acquisition, terminals for workers to clock actual times, machine data acquisition. Essentially, the system is very open. In terms of company size, it ranges from setups like the one discussed today to large-scale enterprise deployments. Major customers include Bosch and Würth, who use Peakboard across many sites.

And looking ahead: where is the system heading? What are the next steps in product development?

Thilo

The vision is for Peakboard to be the gateway to the shopfloor worker and logistics staff. Everything related to data within a company, and everything that needs to reach blue-collar workers in the field, should flow through Peakboard. Typically, we’re talking about graphical interfaces at the shopfloor level. Peakboard should be the central unit that retrieves data from systems, presents it to employees, processes it further, or writes it back. Today, AI also plays an important role: data can be processed by AI and presented to employees. And in the other direction, employees enter data that is processed by AI and written back into systems.

Björn, from your perspective: how do you see your production evolving? Will it remain focused on pull production? What are the next steps?

Björn

The next major focus is clearly energy management. We’ve started there, but it’s an extremely complex topic because many players are involved: different controllers, different information sources. We purchase electricity at spot prices, down to hourly pricing. This involves energy storage systems and everything related to energy management and resource efficiency. One important message for listeners: this requires patience. If someone believes this can be implemented within days, weeks, or even a few months in an existing plant with legacy structures, that’s unrealistic. It’s different when you build a new facility and plan everything from scratch. In every plant and every construction phase, different technologies are in place. That’s why we rely on an all-rounder like Peakboard, which offers a wide range of interfaces. It works – but it’s a marathon, not a sprint. Especially when you need to explain things to employees, like why the heating might be turned off temporarily. When you see peak loads and additional electric heating running, you might switch off heating for half an hour – no one freezes. It’s about making people aware of these topics. Visualization is a key building block here.

That’s almost a perfect closing statement. Thilo, is there anything you’d like to add?

Thilo

I would encourage everyone to simply get started. With Peakboard, you have the opportunity to try things out. You don’t need a huge project. You can download the Peakboard Designer for free and use it with full functionality without investing a single euro. Then test whether it works as described here. Just do it. Don’t be afraid, don’t assume it’s a massive project tying up ten employees for a year. You can start small and still achieve a lot.

Björn, any final words?

Björn

I always have to be careful, because people sometimes assume I’m financially involved with Peakboard. That’s not the case. But some things can only be communicated honestly in your own dialect, so to speak. I couldn’t promote an inferior product. Just as our knives belong to the top tier, Peakboard clearly does as well. We’ve done joint events, including at our employer association Südwestmetall. People quickly become suspicious: “He must be getting commission if he’s that enthusiastic.” Thilo summed it up perfectly: just get started. If you have an application in mind, try it. This year, we hosted a programmers’ day. Developers visited our plant and saw how the product really comes to life. Many programmers are deeply immersed in code and could see the applications in practice. Peakboard has a young team, short communication paths, and great support. If you have an idea, get in touch and try it out. I’d be surprised if people didn’t develop the same enthusiasm and enjoy using the product. In the end, that’s the key: you need to enjoy using a solution. It has to be practical and deliver real benefits for the company. Those are, for me, the keys to a successful product – and Peakboard clearly meets them.

That’s where I find it difficult myself. This is not meant to be a marketing event at all – but the enthusiasm really comes through. If I were running a production facility, I’d just get started. Next time, I’ll make sure to ask more critical questions to balance things out. But now a quick question: have you ever worked with Peakboard yourself or seen it live?

Björn

Not personally, no. That’s actually a pity. Since this is an audio-only podcast, it would have been great to show something directly. I’d really like to take a look at the Designer.

Björn

You’re welcome to come by anytime with Thilo and see how the project works in real life. The only thing I get from Peakboard is a mug once a year, if I’m lucky.

That must be a great mug.

Björn

It really is a great mug. Other than that, I’m not incentivized.

Thank you very much for the invitation. If I can arrange it, I’ll definitely take you up on it. I really enjoy visiting production sites and seeing how things work. Every plant is different, and use cases are at different stages. The motto “just get started” is very strong. Thank you both for your time and for sharing your insights. And thanks to all listeners who stayed with us until the end. See you next time. Thank you.

Thilo

Thank you from my side as well.

Björn

Thank you.