Möchtest du unsere Inhalte auf Deutsch sehen?


Sensor2Cloud integration – how to save costs in engineering and product development


Click on the button to load the content from Spotify Player.

Load content

Listen to the IoT Use Case Podcast on Spotify.
Listen to the IoT Use Case Podcast on Spotify.
Listen to the IoT Use Case Podcast on other platforms.

IoT Use Case Podcast #120 - Perinet

In the 120th episode of the IoT Use Case Podcast, Madeleine Mickeleit discusses key challenges of Sensor2Cloud integration with Dr. Karsten Walther from Perinet.

Podcast episode summary

One of the main problems highlighted in the episode is the high level of effort involved in assigning IP addresses, integrating and connecting sensors and handling data in different IT systems. Dr. Walther explains how simplifying access to data can save engineering costs by reducing the complexity and costs associated with integrating different sensors and connecting to various IT systems.

He shares insights into the seamless connection of sensors and actuators to IT systems, discusses the importance of IoT products such as the periCORE SPE communication module and discusses the operational, technological and business use cases that Perinet offers its customers.

Perinet works closely with IoT partners and system integrators to expand the application of its technology in various industries.

Podcast interview

Hello, Karsten. Welcome to the IoT Use Case Podcast. I’m really glad that you’re here. How are you today and where can I reach you right now?


Hello Madeleine, thank you for the invitation to your great podcast. I’m in the office today. I’m doing great and I’m looking forward to the episode. It is an exciting topic.

You are in operational management and have a lot of experience and many years of experience, especially in automation. How did you actually come to Perinet?


I personally have actually been active in this area for 25 years. I studied computer science and electrical engineering and right from the start it was always about integrating the smallest systems, i.e. sensors, actuators and then IT-based processing. Then I left university, went on to do a doctorate at university and joined a development service provider for edge devices or what we would now call edge devices. In 2013, I actually joined Harting and worked there in the IoT division, including Industrial IoT, and saw many projects in the company for which we were ultimately also supposed to provide support with devices that we had developed.

Was it already called IoT back then? It probably had a different name, right?


It was actually already called Industrial IoT. My boss at the time was a real entrepreneur, he led the way and Dietmar Harting is also very interested in new topics that he is pursuing. That’s why he took up this topic very quickly. That was also the exciting thing, that we had the opportunity at Harting to work on a topic that many others didn’t even have on their radar.

Really exciting. Now you are completely independent with Perinet, you are not dependent on Harting. How did that come about with Perinet?


As I said, we have been working together on these IoT projects for five years and have developed products. On the one hand, it was very, very good basic training. What are the actual problems? On the other hand, we have also seen this typical dilemma in a large, successful company to expand a new business area. There are always hurdles to overcome. Especially when it is so different. Harting is mainly successful in electromechanics. We are now starting with the smallest electronic devices. Then, in 2018, we said we would now launch Perinet as a start-up outside the Group, but of course with Dietmar Harting personally as a shareholder, in order to be able to drive this whole topic forward much, much faster or much better.

With Perinet, you are fundamentally part of the electrical and electronic equipment manufacturer sector. You develop electronics to make sensors and actuators network-compatible, but you also have a very strong focus on the seamless connection of sensors and actuators to the IT systems, for example to the ERP. I imagine that when my home is a very well-organized team. I have my little helpers, my lamps that switch on when it gets dark. I have a heater that gets turned on before I get home and so on. I imagine you and Perinet are ultimately a kind of coach for this team. You are working on the technology that will really enable all devices to talk to each other and coordinate. Can you put it that way?


The application example is just right. Ten years ago, when I was still at the development company, we had developed a combined heat and power plant, for example. The task there was to also equip this with Ethernet, because the building management systems are all already IT systems. This is the basic issue we are dealing with, that IT is delving deeper and deeper into this topic. It used to be data centers, then it was home computers, and then came smartphones. We have seen the edge computer in the industrial sector, Raspberry Pi. Now it’s just a matter of taking the next development step and making the individual sensor network-compatible. There are already some devices on the market.

If you look at the automation pyramid, you are very far down. You connect these sensors and actuators, to give a bit of context as to where we are even located spatially.


Exactly, or to put it another way, we take this term “Internet of Things” very literally. For us, every thing really does have an Internet address and is therefore part of the Internet.

You have communication modules, for example a device that enables the sensors and actuators to communicate with the network. You can perhaps think of it as a translator that speaks the language of the sensors and actuators and converts it so that a network ultimately understands it correctly. Can you put it that way?


Yes, ultimately our module is a small computer that a sensor manufacturer or actuator manufacturer can integrate into their device. The challenge for manufacturers here is, of course, that they produce temperature sensors, for example, and have a lot of knowledge in this area, but very little knowledge of how a computer works. Ultimately, if we install a network interface there, we suddenly turn this sensor into a normal computer. In the network, I can’t tell whether I’m talking to a sensor or whether I’m talking to my house bank on the Internet, except by the address. That’s exactly what we provide, the know-how, the electronics and the software to turn a small device into a computer.

You not only have the module that you supply, but also adapters and so-called converters in your portfolio. An adapter is connected to different plugs or transmission standards, similar to a travel adapter for sockets, you could say. A media converter is essentially a device that changes the way data is transmitted, for example from electrical signals to other signals that I need in order to send media correctly. In that case, are you also on the move with the products, right?


The module is actually our main product for the integration of sensors and actuators or small devices. However, it is now the case that not every manufacturer immediately has the quantities to change their device. For this, we have these exact adapters that allow you to retroactively turn a stock sensor into a computer by screwing this adapter onto it. It practically converts this analog signal, for example a 0 to 10 volt signal, which comes from the sensor. On the other hand, it has a network interface to make these individual sensors intelligent. Then we have other components, such as a 3-port switch, which can be laid in the cable harness or used to connect several sensors or several small devices. The media converter is there so that the network segment of the sensors can be connected to a standard network socket, because we technically rely on Single Pair Ethernet. This is a new Ethernet standard that is particularly suitable for these small devices. You then need a converter from this Single Pair Ethernet to classic Ethernet, as we know it from building installations.

The network switch you’re offering here is, I don’t know if you can compare it to a switch at a train station that routes data traffic in a network, so to speak, and ensures that the information ends up at the right destination, right?


Exactly, it is a regular network switch. The special feature is that it is so extremely small that it can be installed in the cable duct. We know a normal Switch, they are all bigger than a smartphone. I can’t simply install it somewhere in the installation, I always have to screw it to the wall and then run the cables to it. This small switch that we have can be laid directly in the cable harness. Ultimately, it is no different in size to a plug, but in terms of function it really is a classic network switch.

Now you’ve thrown SPE into the mix. SPE stands for Single Pair Ethernet. I sort of have a cable that only uses a couple of wires to transmit this data, which makes it somehow easier, cheaper and probably more sustainable in the end. In the end, this is the cable I need to connect the devices together, right?


Exactly, and the effect of why we use this is that it’s the first time in 30 years that the electronics needed for networking have gotten smaller. This allows us to integrate it into the sensor.

Why is integration into the sensor important for the IoT? What does seamless Sensor2Cloud integration mean? Why is the topic important now?


Let me take an example from daily life. When we talk to each other, we talk directly to each other. This is seamless communication. But when I speak in another language that I don’t know, I always need a translator. This means that I talk to the translator and the translator talks to my actual conversation partner. Communication is also more difficult and misunderstandings arise. In the technical world, we see this scenario very, very often. This means that, on the one hand, we have computers and IT systems that now communicate via HTTPS and MQTT, i.e. the classic TCP/IP protocols. On the other hand, we have the field level, where classic analog signals are still widely used, so where I actually need an electrical engineer who understands the whole thing or an automation technician. These are two completely different worlds. Completely different languages, completely different philosophies. That’s what makes this communication from the IT system to the field so difficult and the approach of seamless communication or our approach is that the sensor also comes into the IT world and thus direct communication is possible, which is much easier to establish and works better afterwards.

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

I always talk about specific practical use cases here in the podcast. Now your use case is more of a technical one, let’s say. You are not so close to the business use cases, but rather the use case for you revolves around connectivity, data connection and integration. Your customers, or their end customers, will then probably implement various business use cases that are developing in the direction of, let’s say, the supreme discipline, such as predictive maintenance, condition monitoring, asset tracking and so on. Did I understand that correctly?


Exactly. We are a component or technology supplier. We supply individual components, and our customers are often system integrators or operators who use our components to solve their problems. Last week, a laundry operator wanted to know when which machine was running so that they could better monitor their machinery. This is the classic customer and operates several laundries. In other words, they have a central system somewhere, an IT system, and the customer wants the data there. That’s why the components we offer are very helpful for them, because they can transfer the data directly to the cloud or their IT system and analyze it there. This overall process of obtaining this data is then considerably simplified by our technology.

Ultimately, it’s always about making a business case and saving time and money through various technologies. You talked about this effort and the challenge. Staying with the sensor manufacturer and the IT system, could you elaborate a bit on what kind of overhead is involved for sensor manufacturers that you work with? Are these commissioning costs or what exactly are they?


For the sensor manufacturer, it is mainly the know-how and the effort required to integrate this technology into the sensor. We are doing the groundwork with a module that is relatively easy to integrate. The users of the sensors, either system integrators or those working for plant operators, want to access the data as quickly as possible. However, there is always the problem that there are x different sensors and every plant operator uses different systems to control their system. These must be brought together. And this is actually the biggest problem that causes the effort, that you have to take a close look at what signals the sensor returns and, on the other hand, how the IT system has to be connected. This is exactly what we experienced at Harting back then, that the main costs of IoT projects were incurred in this area.

In the end, this means that time and money are involved. These are engineering efforts from the operations people who work there in the field and establish the connection, but also from IT. In the end, that’s an engineering expense or a cost center that probably goes into it.


Exactly, usually even several cost centers, because in the classic case I have the automation technician, the operator and then someone from IT, the administrator and then at some point the data analyst. All four of them have to work together and coordinate. This leads to some interesting discussions. They use the same terms and mean completely different things, because of course they are completely different worlds. Simplifying this is actually our goal.

You just described it as a system integrator, or also a manufacturer, which could perhaps also be a mechanical or plant engineering company. They sell the machine and in the end the aim is to achieve a certain margin. What is the business case for the machine manufacturer here again? They take your components, integrate them into the machine, and sell it further. Can you say anything more about this?


There are different machines here. There is a special area, classic machine automation, which is not our area, where I have the PLC at this point or PLC that controls the machine. Rather, our technology is always good when a higher-level evaluation needs to take place. For example, a crane manufacturer rented out its crane by the hours it was used in the field. It was then important for the crane manufacturer or rental company to log these operating hours and of course send them to central systems so that the customer using the crane could be invoiced automatically. These are the applications that are also of interest to machine and plant manufacturers.

This means that it calculates the usage, so to speak, i.e. the data is ultimately probably operating data from this crane. This data is then presumably connected to your module via a wired connection. What is the process leading up to the evaluation? After all, you supply the hardware and support the integration with your hardware. Can you explain again exactly how this crane manufacturer is now working with you?


The crane manufacturer had its own development, which in principle functions as system integration. Whether such problems are solved internally or an external system integrator is commissioned is up to each customer to decide. Ultimately, although it is a crane manufacturer, we were communicating with a system integrator at the time. The problem there was that several sensors are attached to the crane and the usual systems on the market connect each sensor wirelessly, for example, because the data ultimately has to be transmitted. But managing this wireless system was very time-consuming, and they wanted to reduce this effort. There were also breakdowns in the field, which resulted in maintenance work. With our system, the sensors are connected via Single Pair Ethernet and then there is a classic LTE gateway or mobile radio gateway that establishes the connection to the cloud. Just how you can use a DSL box or an LTE gateway or even fiber optics at home. The crane would then have a central Internet access point. But the sensors communicate locally safely and reliably over the network, and then the data is transmitted to the cloud via it. In this case, the customer used our components to connect the sensors, cable voltage and the like, collect the data and send it to the cloud. The customer selected the sensors themselves, configured our adapters so that they send the data to the right place, installed everything on the crane and also evaluates the data in the cloud. This means that the system integrator deals with areas in which we cannot provide support. We don’t sell sensors, they are different for every application. Nor do we offer a cloud platform for processing. Our main expertise is in distributing electronics that facilitate access to data. The system integrator brings all of this together for the customer or operator of a system so that the business case or added value for the customer is ultimately ensured.

Without you, this crane manufacturer and its engineering team would end up with very high costs. What you explained earlier is also a bit like the allocation of IP addresses, cabling efforts but also engineering efforts with the sensors. That’s what they end up saving with you.


Exactly, and this is where we distinguish ourselves by being very consistent. If you consider how many internet-enabled devices there are, how many sensors, then the number of sensors and actuators is far greater. Many products come onto the market and work, but the fact is that a sensor also has an IP address, similar to a router. With a router, it is legitimate for me to go and assign an IP address once and take care of it. But if I have 100 sensors in the field and have to do this 100 times, then I’m unnecessarily increasing the workload. In fact, many things are memorized, such as assigning a bus address, assigning an IP address. That’s in people’s heads, but it’s not necessary. We focus precisely on this aspect of avoiding unnecessary expenses in the first place. This could also be referred to as auto-configuration of the devices. So, I install them and can work directly with these devices and only have to make the necessary configurations, such as telling the sensor: OK, you’re monitoring the crane’s off switch.

Right. And what you mention is actually very interesting, because it also represents a cultural change to say: Hey, you don’t actually have these expenses. Because that’s exactly what has been learned, because it’s been done the way it’s always been done for years – that’s always the classic. Now to say: let’s rethink this. There is a system that saves this effort, which ultimately means hard cash.

[23:32] Solutions, offerings and services – A look at the technologies used

We talked about it, you have different products. You call the communication module periCORE. periNODE is your smart adapter. It is then a smart component, which is actually a small connector, so to speak. If I want to start now, how do I do that? So it depends on the use case how I then put the components together? Can you explain how you deal with the customer when, for example, the next crane manufacturer comes along and says, hey, I’ve got another case here?


Exactly. As this is a new technology, we offer starter kits that arrive fully configured so that the customer can gain initial experience with the system. So first of all, let’s see: How do we actually envision this system? How does the sensor communicate with the software? Because this is indeed something completely new. In the past, sensors were passive and were queried, and now I have sensors that are computers and can become active themselves; they can report themselves when the relevant switch is triggered. In the classic bus system, I always have a bus master that queries every sensor: Has something happened? And in this case, communication can be completely reversed, i.e. the sensor can initiate communication when something happens, and these are really completely new approaches and require a rethink. That’s why we take the approach of starter kits, with which the customer gains initial experience with the product and the system, and then it really comes down to the customer saying: Yes, I have the monitoring point, I need a sensor there, and there and there; I want to monitor that in this system. And then the customer can put it together as they wish. That is also a big advantage. If I’m working in a network and need another sensor, I simply plug another sensor into the network. In a traditional bus system, I have to think again about which bus addresses I have to assign, teach, and do all these things. Here you can really be done very quickly and easily, which also makes it easy for the customer because they can get started simply and easily. So typically they say: We want to monitor this and that. And then you actually start with one or two sensors and set up the entire system first. And then you gradually add more sensors, which has the further advantage for the customer that the projects become smaller and more manageable.

I don’t want to go into too much technical detail now, but feel free to take a look at perinet.io. I’m currently on your website and there you can also see the starter kits, which are made up of completely different components, as you’ve just described. At the beginning, we talked about the integration of this data and sensor data into the cloud. I would now like to close the circle a little on how this works. For example, how is the data integrated if your crane manufacturer also wants to have the hours per use in its various IT systems because it has to run an evaluation or pass this on somehow? How does this integration of sensor data work?


The fact is that the sensor, or now with our electronics, can already process the data appropriately and send it in data formats that a normal computer can process. Typically, this is specified by the customer, as they already have ERP systems or other systems running or use IoT platforms, which is also very popular. For example, these support the MQTT protocol across the board and can process JSON data. This is exactly what comes from the sensor. All this data processing takes place in the sensor and it simply sends the data to a computer in the network. The system integrator now only has to decide how the network structure makes sense. I have the MQTT broker, do I use it locally on an edge computer or do I have the data sent directly to the cloud to an MQTT broker there? They just have to provide the network technology, but that’s what we do every day. For example, each of us uses the WLAN access point and connects to our laptop. And in the end, that’s all it is. I simply have to connect to the local network and can then of course communicate with the Internet.

Do you also cooperate with IoT partners in this area? I’m not sure if such large hyperscalers might be a bit too much, but do you have partners who can support you with this? Because at one point, and you mentioned this, the data formats are already ready to use. But what is then done with this data is decided by the customers in their own systems. Do you also have partners for this, or how does it work?


Exactly, so we are greatly simplifying access to the data. We have nothing to do with the data analysis itself; our partners actually take care of that. We have software partners who operate cloud platforms, offer online SCADA, online PLC systems and the like, and then the system integrators. But the fact is that every customer has a different system and a different problem to solve. That is why we are actually looking for more system integrators to work with our system. Surprisingly, we have relatively few partners here in Germany, but we now have a large number of partners in other European countries.

Very cool. So, here’s the call: If you’re system integrators or you’ve been listening and you say these are projects that we know about and we’re interested in, and if easy access to the data is an issue for you, then I would say talk to each other. Karsten, you are also in our IoT partner network, but I have also linked your contacts in the show notes. Take a look there and get in touch. I think you can also be found on LinkedIn. This is very valuable for expanding your ecosystem and learning from these exciting topics together. Yes, and perhaps as a last call for today: you are also present at some trade fairs, so there is still a lot to come that you will be presenting. I would love to visit you myself, just drop by your booth. Where can you be reached? Where do I need to go?


The next major trade fair is Light + Building, where we will actually be presenting a new concept for building cabling, i.e. a one-cable solution for connecting all devices with one cable. For example, ventilation control units or fan flaps or pumps, i.e. hot water pumps and so on. We have also gained a lot of partners who are presenting this with us, other companies, other device manufacturers. Then we are also at the Hannover Messe and there is a special part there to show again what actually makes an intelligent sensor and there we show, for example, how the sensors interact with each other independently.

Thank you very much for the presentation at the Hannover Messe. Also important again: If you’re listening to this episode and it’s still before April, check your calendars for Tuesday, April 23. A large IoT meet-up sponsored by Hannover Messe will also take place at 5 pm. We do this together. I think Karsten, you’ll probably be there too, or someone from your team. Just drop by the Perinet booth at the Hannover Messe. Otherwise you can simply network on LinkedIn. This is also the quick and easy way. From my side, Karsten, thank you very much for this exciting session today. It’s always super cool to bring OT together with IT and also to understand how you can make it very easy to access the data. It was very easy to understand which hardware and modules can be used and how the whole thing works. You have provided some very valuable insights that are not readily available, such as how a computer communicates with a field device and the importance of translation in that process. The end result is concrete added business value that saves time and money. That’s why it’s important to spread the word. I think that’s why we’re talking about it today. Many thanks from my side. I give you the last word for today.


Yes, Madeleine, thank you very much for this nice discussion or conversation. I think that’s exactly what makes your format here so valuable. They are complex things when you try to explain them, so in our case, it’s always like this: you don’t know who is listening. I find a format like yours here very, very valuable, because it really is a new technique and in conversation, I think you can follow and understand it much, much better. So the questions you asked are also very, very nice, because they naturally take us in an understandable direction.

Very nice. Yes, thank you very much for the compliments at this point. I am always very happy when feedback comes in. I’ve said my last word, so I’ll keep this short and wish you a good rest of the week. Take care, Karsten, and we’ll see you very soon. Ciao.

Please do not hesitate to contact me if you have any questions.

Questions? Contact Madeleine Mickeleit

Ing. Madeleine Mickeleit

Host & General Manager
IoT Use Case Podcast