In this episode of The Connected Factory Podcast, Kasper Karlsson Christiansen, Senior Platform Owner at VELUX, joins Alexander Krüger, Co-Founder of United Manufacturing Hub, to discuss his journey from electrician to building industrial IoT platform.
Kasper shares insights into his role in integrating machines with IT systems, the challenges of standardization, and the importance of event-based communication for scalable data flows. The conversation dives into fostering cross-functional collaboration, empowering local factory teams, and the benefits of avoiding vendor lock-in through flexible architectures. Kasper also highlights the value of tailored applications and leveraging open-source tools for modern manufacturing. The episode provides practical takeaways and inspiration for companies navigating IT/OT integration and digitalization.
Takeaways
- Standardization drives efficiency: Developing and sharing standardized templates and PLC function libraries with machine vendors accelerates integration and improves scalability.
- Event-based architectures: Shifting to event-based communication with JSON payloads enables flexibility and compatibility with modern IoT tools like Kafka.
- Cross-functional collaboration is key: Success in IT/OT integration requires a team that spans expertise from IT architects to factory floor operators, breaking traditional silos.
- Empowering local teams enhances innovation: Providing tools like Grafana and Kafka allows factories to create custom dashboards and applications, enabling local teams to innovate autonomously.
- Avoiding vendor lock-in enhances agility: Decoupling data producers and consumers ensures adaptability to evolving technologies and prevents dependency on a single vendor.
- Tailored applications improve usability: Designing software based on operator feedback ensures relevance, simplicity, and better adoption on the shop floor.
- IT must adapt to OT realities: IT teams must understand the physical dependencies and constraints of industrial environments to design practical solutions.
- Open-Source is underutilized in manufacturing: Manufacturing can benefit greatly from proven open-source tools and principles, as they offer reliable and cost-effective alternatives to proprietary systems.
Chapters
00:00 - Introduction and Guest Overview
00:35 - Kasper’s Journey: From Electrician to IoT Expert
03:14 - The Evolution of Industrial IoT at Velux
11:29 - Standardization and API-Driven Machine Integration
17:06 - Open Source and Event-Based Communication in IoT
20:12 - Building Cross-Functional IoT Teams
24:13 - Empowering Factories with Self-Service Tools
27:27 - Avoiding Vendor Lock-in Through Flexible Architectures
32:30 - Custom Applications for Factory Operations
34:41 - Lessons Learned: Bridging IT and OT Worlds
39:13 - The Future of Manufacturing Software
42:20 - Closing Thoughts and How to Connect
Transcript
Alexander:
So hi, I'm Alex. Co-Founder and CEO of the United Manufacturing Hub, and I'm happy to share today another episode of the Connected Factory podcast. Today I have Kasper with me, Kasper on the industrial IoT initiative fair as a platform owner, and I'm super stoked to let him tell you what went well, what didn't, and how it's currently looking like to give you guidance and also inspiration on how to build your and or other digital initiatives. Let's jump into it.
Kasper:
Yeah, I can do that. My name is Kasper, and the middle name is Korsholm Christiansen. So, it's not very easy to pronounce if you're not from the Nordics. But just living in Denmark, working at Velux as a senior platform owner for an industrial IoT platform. I am educated as actually an electrician back in the days, but always been working with machinery. For the last years as a programmer and then project manager, buying machinery and building machines. But for the last ten years, I have mainly worked on integrating machines with IT in different ways and had a lot of learnings on that. I can, it was ten years, good and bad.
And on my personal end, I live here on the west side of Denmark, close to the sea in a small town called Skagen, where we also have Velux as one of its European factories, which is also where I have my daily office. Today I'm sitting at home, but normally I'm at the office, live with my wife and two kids. In my free time, I watch handball, I go hunting, I do a lot of CrossFit. Have to say that I know that some. And then I am trying to learn to play guitar. That's not going very well. If you want to practice to fail fast, you need to buy a guitar. At least if you're like me, I've never been musically introduced. Yeah, I would have wished at that time. My parents back then would be more Asian parent style and forced me to not stop learning.
Alexander:
I was also trying to play guitar, but then as a teenager, there was obviously more interesting stuff to do than that. So I dropped out and I regretted it every day. And that's why I'm doing it more, actually. It's a super interesting pattern, this electrician through industrial IoT. So it sounds a little bit counterintuitive at first glance because some of the electricity that you work with and now you're working with Kubernetes and highly distributed IT systems. So what actually makes it easier transition, logical and easy for you? Why do you think others and perhaps you specifically actually move from electrician to IoT?
Kasper:
There was also quite a journey. You can say it's not like from day one. It's like when I started studying to be an electrician, I found also that was what I was going to do. I was just starting and, say, building houses and doing wiring and lamps and all of that. Then suddenly I found out you can actually also build machines. Then I started repairing some machines, and some, the company as well as apprentices, we had some contracts with some industrial companies where we had to maintain the machines. So quite soon I found out that was a little bit more fun, a little bit more complex to do.
Then I did my first automation projects, smaller ones, for some local industrial companies. Then I found out you could actually program the PLCs, and that was quite good. Probably I was a little bit nerdy back then, playing a lot of computer games and stuff. So that fit well with me. And so I actually changed my apprenticeship to look more on the automation side of it. When I was done with my education, I actually wanted to become a machine engineer.
But before doing that, I needed to earn a little bit of money. So I found a job at Velux. So fantastic. Yeah. One or two years and then some money, and then I will go to university. But I think I was at Velux for half a year maybe. And then they said, oh, we actually need a PLC programmer. Could you do that? And I was like, oh, that was actually what I wanted to study for was to actually do programming. But actually, they offered me after like half a year that I could do that full time. And then since then, I basically just learned to program by myself, or you can say by looking at my colleagues back then when they started it.
Alexander:
I really like this hands-on approach. If I would try to map out little bits into customers and community members that we know, it's often either or. So you starting from the IT perspective, like cloud native world, and try to push the data of the machines in there, but neglecting often that this is more complicated than that in the sense of what actually data types you want, how the machine works, which other relevant KPIs, if they're not already there, how you get it out and what. The other way, I would say autofocus, where they just push everything into a so-called mess, and try to make use of the data there.
I really like the approach on coming from the machine, but like you will also share later to try to match it with IT, like, really proven and scalable technologies to make it work. So really interesting. And also, I would say a similar pattern. I don't specifically know why, but it's interesting. How do you start it now from, you know, electrician like dipped your toes into PLC programming and then now what's the next step? Industrial IoT. What was the ignition point for that? And why did Velux actually prioritize something like that?
Kasper:
I think it's maybe a little bit of coincidence. You can say I've been at Velux for 16 years now. But in the beginning, I think within the last ten years, we also saw that there were also more requests coming for solutions where machines were talking together with our ERP system, more advanced solutions. So we had these projects coming up a lot of times, where we bought this new machine. Could you connect it to SAP? Could you connect it to the next machine? That's a matter of IT too. So there's some tracking and tracing out of this.
And, I don't know why, but somehow, in the beginning, I got part of those projects. And for a long period, when we had those projects, they sort of landed on me and I was and a couple of colleagues that I was very close to, so I just simply gained a lot of knowledge in those kinds of projects. I've also done machines from the part of Velux. We have two departments that are actually also building our own production equipment from the ground up, doing the drawings, the testing, building, and doing the FAT and SAT and all of that.
And that's also the department where I was hired at first. So I've also done machines where you follow the project from, you know, whiteboard sketches to 3D drawings to something we build in the workshop, and then you program it and test it and all of that. But then, there was this integration part afterwards, and suddenly I became like, this is. And I also found it quite interesting to be in this world between OT and IT. And that's, I don't know, maybe five, six years ago, I fully committed to say, okay, that is what I will focus on, that is this integration between OT and IT.
Alexander:
But some other companies would say let's do it even more so, like I would say, absolutely more hands-on approach. And Velux also works on machines. So why not just, okay, let's buy SAP. I'm not sure if you perhaps also have it on the site or if you can want to share that, but if it's a way more hands-on integration approach where you just don't trust a vendor with that and just let the team integrate.
Kasper:
Yeah, and it's not like we don't use off-the-shelf systems, and, you know, we have just been doing it. I think each industry and each company is different. You have to look at what you are producing and what actually drives your digitalization efforts. Velux is a manufacturing company. We're not doing food, beverages, or pharmaceuticals. So you can say the strict regulations around tracking and tracing don’t apply to us in the same way. When we have done digitalization, it's been based on where it makes sense for us to optimize processes.
What we are doing—making windows and related components—means our factories are quite diverse in terms of processes. There's a significant difference between what we do in one plant versus another. Having a standard system might not fit all cases. And like many companies, we've experimented here and there, trying to determine what makes sense in terms of digitalization and what doesn’t.
Alexander:
I think you're in a super lucky position, to be honest. A lot of manufacturers are stuck buying machines as package units or standard equipment. They often have limited on-site capabilities to connect these to standard systems or force a companion spec or data model. But for you, building your machines means you can focus on building APIs that make sense for your system. That hands-on approach is a fortunate position to be in.
For our listeners who might not have that, how would you define those APIs to make machines communicate effectively and scalably?
Kasper:
What we've done when building machines is standardize internally. At Velux, we don’t build all our machines, as some are off-the-shelf, but we’ve been creating internal standards for programming, UI development, and more for many years. For instance, we use the NAMUR state model and other methodologies. Over the 16 years I've been at Velux, it's been a continuous journey of standardizing our approach.
When we buy external machines, we also aim to make external vendors follow our standards. Whether it’s custom-built machinery or off-the-shelf, we push for alignment with our internal standards. Over time, we’ve developed robust templates and a library of PLC functions, which we provide not just as specifications but as ready-to-use building blocks. For example, we offer specific code for communication protocols rather than a 150-page spec.
Alexander:
That’s a great approach! A common issue is vendors receiving overly detailed specifications or overly generic ones. Neither is effective. Offering ready-made code seems like a significant step toward bridging that gap. I also notice that many standards fall short because they lack technical depth. It’s either too vague or too niche to adapt to broader use cases.
Your approach—providing building blocks—seems like a glimpse of hope for creating better communication between manufacturers and vendors.
Kasper:
Yes, and I often say that while it's easy to connect to a machine, getting the right data with context is much harder. It doesn’t matter which protocol you use. None of them truly guide you on how to communicate about things like alarms, for instance. Eight years ago, we decided we couldn’t keep starting from scratch with every new project. So, a colleague and I developed an event-based communication system using JSON payloads, even before MQTT gained traction.
Initially, we stored those JSON payloads in standard SQL databases. When we adopted MQTT later, the transition was seamless because we had already set the foundation with JSON.
Alexander:
That’s such a forward-thinking approach! Often in manufacturing, there’s a tendency to reinvent the wheel instead of adopting proven technologies. Banking and connected products already utilize concepts like message brokers and event-based systems. Manufacturing is a distributed system with APIs—machines producing and consuming data—so leveraging existing solutions like Kafka makes perfect sense.
Kasper:
Exactly. We’ve been lucky in having the right mix of skills on our team. For example, one of my colleagues came from an IT background, developing software for testing electronics. He brought in that mindset, and when we teamed up—combining his IT knowledge with our OT perspective—we created the framework we use today.
Alexander:
It sounds like you’ve nailed convergence, bringing IT and OT together the right way. How do you manage your team structure? Do you have plant-based personnel versus global personnel? How do you ensure resources are allocated correctly?
Kasper:
We don’t have a strict structure where each factory has one dedicated person. Instead, we rely on local managers and team members who want to work collaboratively. I would love for more factory personnel to co-create on our platform. It’s not always easy, but when you engage people already on-site—like electricians or analysts—they become motivated to contribute because they see the value.
Our goal is to create a platform that serves different skill levels, enabling users to create Grafana dashboards or small applications themselves, depending on their expertise. For more advanced use cases, we offer tools like Kafka for direct data manipulation. We want to empower factories to self-sustain their solutions while we maintain the platform.
Alexander:
That’s a great way to empower your teams. You’re essentially enabling the people closest to the machines to take ownership of their solutions, which is often more impactful than imposing something from the top down. It’s great for engagement and retention too, especially when technical people see you’re using tools like Kafka or Grafana that resonate with their interests. What’s the goal behind building this level of autonomy at the factory level?
Kasper:
The ultimate goal is to build a platform where we offer products and solutions that anyone can use, whether it's a simple Grafana dashboard or something more advanced like Kafka queries. We want to cater to different skill levels while ensuring that the technologies we provide remain scalable and easy to adopt.
For example, some factories now create their own Grafana dashboards. The local electrician collects the data, and the business analyst creates the dashboard. They operate independently without us needing to intervene. That’s the ideal scenario—empowering teams to build and manage their own solutions with minimal dependency on central teams.
Alexander:
That’s ideal indeed. It ensures that even smaller, local use cases—those that might only save a few thousand euros a year—get addressed without requiring huge projects or budgets. It’s about feeding the long tail of use cases and unlocking value that would otherwise go unnoticed. It also lets global teams focus on broader, high-impact projects.
Kasper:
Exactly. One of the key principles for us is to separate data producers and consumers. The same data source feeds different systems, whether it’s a third-party application, an open-source tool, or a custom-built app. This separation gives us the flexibility to adapt as technology evolves.
For instance, the software we use today might not be the best option in two years. By decoupling producers and consumers, we can switch vendors or tools without disrupting the entire ecosystem. Too many manufacturing companies get locked into specific solutions and struggle to adapt as needs change.
Alexander:
That’s such a forward-thinking strategy. Too often, companies end up locked into a monolithic system that tries to do everything but doesn’t excel at anything. The ability to choose best-of-breed solutions for specific needs, like OEE or energy monitoring, is a huge advantage.
On the other hand, this approach also requires more effort upfront. How do you justify that investment internally, especially when it’s not immediately visible to the business?
Kasper:
It does require a lot of effort upfront, especially when it comes to connecting machines properly. We spend significant time ensuring the integration is done right the first time, which can be hard to explain to internal stakeholders. It’s not cheap—our team now has 25 people—but the long-term benefits far outweigh the initial costs.
This strategy ensures we’re not locked into any single vendor and can evolve as the industry does. The flexibility to switch tools or vendors without having to rebuild the entire infrastructure is invaluable.
Alexander:
That’s a compelling argument, especially when you consider how fast manufacturing software evolves. I’m really looking forward to a future where ease of use and scalability are prioritized over ticking boxes on an RFP. Tools designed for the end user, not just for procurement, are the way forward.
Kasper:
Exactly. And with this approach, you can pick the best tool for each capability. For example, if one vendor offers excellent energy monitoring but lacks in quality tracking, you’re free to choose another tool for that specific need. It’s all about flexibility and tailoring solutions to what works best for your industry and processes.
Alexander:
That’s a great mindset, and it aligns well with the unified namespace concept. It allows manufacturers to adopt fit-for-purpose tools while maintaining a cohesive data ecosystem. I recently read your blog about how software is built for buying, not for the end user, and it resonated with me. Have you applied this principle internally?
Kasper:
Yes, we’ve applied it in small ways. For instance, we developed an internal application for order management that pulls live data from SAP and displays it for operators. It’s a very basic capability often included in larger MES solutions, but we tailored it specifically to our needs. We interviewed operators, designed mockups, and refined the UI based on their feedback. The result is an intuitive tool that does exactly what they need and nothing more.
Alexander:
That’s fantastic. Getting operator buy-in early on is so important. If the shop floor workers find a solution useful, it’s a true success. Otherwise, it risks becoming another unused tool. From your experience, what can IT learn from OT, and vice versa?
Kasper:
IT can learn a lot by getting closer to the machines and understanding the challenges of the OT environment. For example, concepts like CI/CD pipelines, which are common in IT, are much harder to implement in OT due to dependencies on hardware and software versions.
Conversely, OT can learn to adopt more modern IT practices, like leveraging open-source tools and cloud-native solutions. The idea that OT systems require a higher level of reliability than IT systems is outdated. Banks and financial institutions run their operations on open-source, high-reliability IT systems, so there’s no reason manufacturing can’t do the same.
Alexander:
That’s such a good point about reliability. OT often aims for 100% uptime, which isn’t realistic. IT systems operate at 99.9% or 99.99%, and even Google or Amazon don’t go beyond that without spending billions. It’s important to set realistic expectations and communicate the trade-offs between cost and reliability. What do you think OT teams can do to better communicate these challenges?
Kasper:
One key is setting the right expectations with stakeholders. When you connect machines to an IoT layer, you’re introducing another potential failure point. It’s important to be transparent about this upfront. Achieving 99.99% reliability is extremely expensive, and many stakeholders don’t fully understand the trade-offs.
A big issue is that when something goes wrong in OT, like a mechanical failure, it’s visible—you can see a bent cylinder or a broken motor. But when an IT-related issue occurs, like a network failure or a misconfigured data source, it’s invisible to the people on the shop floor. This creates frustration because they don’t understand the root cause.
We’ve been focusing on improving communication around these issues. For example, providing real-time feedback to operators about why a machine has stopped, whether it’s a network issue or missing data from SAP. Making these problems more visible helps reduce frustration and builds trust in the system.
Alexander:
That’s a great approach. Visibility is key to building trust. If operators understand why something isn’t working, they’re less likely to see it as a failure of the entire system. It’s also an opportunity to improve the product by gathering feedback. How do you incorporate feedback into your process?
Kasper:
Feedback is essential. One of the things we’ve done is create a system that collects anonymized metrics about how people interact with our tools. For example, we track where users encounter technical issues or fail to complete a task. This helps us identify and fix problems proactively.
We’ve also been working on creating a feedback loop with operators. Whenever we develop a new tool or feature, we involve them early in the process—through interviews, mockups, or prototypes—and iterate based on their input. This not only results in better tools but also increases operator buy-in and satisfaction.
Alexander:
That’s such a powerful approach. It’s something we’ve seen in open-source development as well—rapid iteration based on user feedback leads to better products. Speaking of open source, what’s your view on its role in manufacturing?
Kasper:
I think open source has huge potential in manufacturing. The idea that OT systems need to be built with proprietary industrial-grade hardware is outdated. Many IT systems today—banks, stock trading platforms—run entirely on open-source technologies. If they can handle the demands of high-frequency trading, I don’t see why manufacturing can’t adopt similar principles.
For example, we’ve had great success using open-source tools like Kafka and InfluxDB. These tools are not only cost-effective but also offer a level of flexibility and scalability that proprietary solutions often lack. The challenge is overcoming the mindset that OT is so special that it requires completely unique solutions. It doesn’t. We can learn a lot from the IT world and apply those lessons to OT.
Alexander:
I completely agree. The idea that OT systems are somehow more critical than IT systems is a myth. IT systems are the backbone of industries like finance, where downtime has massive implications. Manufacturing can definitely learn from the cloud-native community and adopt more open-source tools.
It’s also interesting how expectations around reliability differ. In IT, 99.9% uptime is considered excellent, but in OT, anything less than 100% is seen as unacceptable. Do you think this mindset is changing?
Kasper:
It’s starting to change, but slowly. Part of the problem is that people in OT aren’t used to dealing with abstract failures. When something mechanical breaks, they can see it and understand why it happened. But when something like a network issue or software bug causes downtime, it’s harder to grasp.
We’ve been working to bridge this gap by providing better visibility into IT-related failures. For example, if a machine stops because it received the wrong data from SAP, we want the operator to see that immediately rather than waiting for someone from IT to investigate weeks later. This kind of transparency is crucial for building trust in the system and shifting the mindset around reliability.
Alexander:
That makes a lot of sense. It’s about creating alignment between IT and OT teams and ensuring they have a shared understanding of the challenges and trade-offs. What advice would you give to companies just starting their IT/OT integration journey?
Kasper:
Start by building a cross-functional team that includes people from both IT and OT. The key is collaboration. IT needs to understand the realities of the shop floor, and OT needs to embrace modern IT practices.
I also recommend focusing on decoupling producers and consumers of data as early as possible. This gives you the flexibility to adapt to new technologies and vendors without having to rebuild your entire system. And finally, don’t underestimate the importance of user feedback. Involve operators and technicians early in the process to ensure the solutions you build actually meet their needs.
Alexander:
That’s fantastic advice, Kasper. Thank you so much for sharing your insights. I’m sure our listeners will find this incredibly valuable. If anyone has questions or wants to learn more, can they reach out to you?
Kasper:
Absolutely. Feel free to contact me anytime. I’m always happy to discuss these topics and share experiences.
Alexander:
Thank you, Kasper. It’s been an absolute pleasure. I look forward to continuing this conversation and seeing how your journey unfolds.
