No Cables, No PLC, No IT Project: Simply Connecting Decentralized Assets

Today on the IoT Use Case Podcast. The fast track into the Industrial Internet of Things. The heart of today's episode is how easy getting started can be, using a concrete all-in-one IoT system as an example. We'll look in particular at applications where you need sensor data but don't want to intervene in the PLC right away — such as industrial fans, decentralized infrastructure, level monitoring, or refill processes. To explore this, the company autosen is our guest, and with Dennis Jansen I'll be discussing the first solid IoT steps: attach the sensor, get the data out, derive actions. Enjoy!

Hello, dear friends of IoT! Welcome to the IoT Use Case Podcast. Today we're talking about a very pragmatic way to get started with the Industrial Internet of Things. We're answering the question: How do I get data out of decentralized, hard-to-reach, standalone objects into a usable cloud solution — without first having to rebuild the entire IT/OT landscape? My guest for this is Dennis Jansen from autosen. Dennis comes from product management and works closely with products like the io-key and the minion. Dennis, let's get concrete right away: when you at autosen talk about an easy entry into IoT, what very specific customer problem do you mean by that?

Dennis

Thanks for having me. If it's supposed to be easy, then as a customer I want to screw on a sensor, maybe enter a serial number — and then I want my data at my endpoint. I don't want to turn it into a separate project. I don't want to have to talk to my colleagues in IT, I don't want to spend hours pulling cables; I really want to run a plug-and-play or plug-and-work approach. That's what we've done at autosen, and I think with the minion we've taken it to the extreme.

Sounds good — but maybe not so easy to pull off. The whole topic of system integration: accessing a control system in an operational environment, in a setting where high reliability is required, where you can't just plug something in. What's the approach you're taking there?

Dennis

Our approach is: wherever a control system handles the processes, we don't touch it. At autosen, we believe in using products that are as simple as possible and require as little consulting effort as possible to identify the trouble spots and bring them online with individual IoT devices — devices that work on their own, that don't need the customer's IT, and that don't have to tap into the control system.

Trouble spots — can you give me some examples?

Dennis

We recently had the chance to visit a customer in the Netherlands who operates a large number of concrete plants. Production in these plants is highly automated — there are carts, cylinders, pneumatic and hydraulic systems, and the recipes run fully automatically. That's all no problem. But when the motor stops, the only way the customer notices is that the product stops moving. So what we do is monitor the power consumption at a motor like that, a rotational speed — or vibration would be the means of choice for that.

Okay, the minion — you've now said it twice, so explain it. Despicable Me, I think.

Dennis

I'm not sure it was that clever from a marketing standpoint, because everyone has that same thought. But it's not entirely wrong — if you translate minion, you end up at "little helper." And that's exactly what we built: a really little helper. A device with a cross-section of just 24 mm, made up of three parts: a sensor, a gateway, and a battery. They're connected to one another with simple snap fasteners and then attached at the point to be monitored — with an adapter, glued on, or, in the case of the vibration sensor, screwed on.

24 mm cross-section — do you have a comparison? A two-euro coin or something?

Dennis

Unfortunately I don't have a banana on hand — that's the typical unit of measure on the internet. Somewhere around the typical size of a postage stamp — that's the cross-section of the minion.

Postage-stamp size, then. Okay, so you have a very, very small complete system — really sensor, gateway, and battery in one. How did that come about? What was the requirement? Between small, affordable, and powerful, you have to make trade-offs. How did the specification to build a device like that come together?

Dennis

We're firmly convinced: if we can collect data and derive action items from it, the world gets better for all of us. And then the question becomes: how do I really get to every location? The answer is quick to explain. We have to rely on cellular, because cellular is the only way to get data out wirelessly anywhere. We need a battery, because otherwise, with an external power supply, I'd quickly be pulling cables again. And it has to be small.

To be completely honest: we first wanted to build the minion with an 18 mm cross-section. But we very quickly ran into the limits of antenna technology and then ended up a bit larger — 24 mm. And even that is still not entirely trivial.

I can believe that. But does it really have to be that small? Depending on what you use it for — a motor is fairly large, so a bigger sensor doesn't really get in the way. And with the battery, the rule of thumb is: the bigger, the better for service life. So where do you deploy the minion, and why exactly these requirements?

Dennis

It's no wonder that most electric cars are some kind of huge SUV — you simply have room for a battery there. More volume, more installation space means more capacity, means a more powerful antenna, means a more capable system overall.

On an industrial fan I usually have room for a larger sensor — I won't deny that. But in systems that are relatively integrated — I'm thinking of centrifuges, for example, the pharmaceutical sector, which we've already dealt with — I simply have very little space. And there every millimeter bothers me.

That's why the goal was: somewhere within this conflict of interest — within this triangle of installation space, performance, and cost — to find an optimum that is very strongly oriented toward installation space. So that we can say: our solution really does fit everywhere.

It ranges from manufacturing all the way to decentralized individual objects — especially when they're spread across a large area, with all kinds of high-value equipment. In which areas are you currently deployed?

Dennis

We're used in access control, for example. There are flaps, doors, and gates that we can monitor. We simply detect when a door is opened and can tell the customer: access or no access. It's not a real-time system — a real-time system would also be far too expensive at that point. But at least they know: someone is now getting in the car, driving out to this asset, and taking a look. And here we're talking about assets, about areas where the individual components are kilometers apart from one another.

Another story: industrial fans. So basically a motor, a gearbox, a coupling, and at the end a large fan wheel. They run relatively constantly and are responsible, for example, for air-conditioning buildings or providing processes for the chemical or general industrial sector. And here we're not with the operator of the plant, but with the manufacturer of these fans — who then equips them with measurement systems and takes the topic of preventive maintenance off the customer's hands. The manufacturer is the one who resells the fans and can offer additional services such as maintenance contracts or cheaper replacement units.

So we're always a little bit alongside the manufacturing process, not directly inside it. We wouldn't be the supplier to the large automotive group, but the supplier to its supplier — to someone who wants to know for themselves how healthy their equipment is.

That makes sense — deliberately not integrating into the ERP or control system, but keeping it separate. Now, we've covered batteries — let's go through the device with its three layers: sensor, gateway, battery, step by step. The battery provides incredible flexibility, but it imposes the constraint that the device won't work for ten years. What kind of figures are we talking about?

Dennis

That depends very strongly on how and where the device is deployed. A battery is an electrochemical cell whose service life depends directly on temperature. Somewhere here in Central Europe, with an average annual temperature of 10–15 degrees — that's where we feel comfortable. When it gets too hot or too cold, the service life suffers. Admittedly, we also advertise with space — but I wouldn't deploy the minion there.

With the typical configuration, in which we record the data once a day and send it to the cloud endpoint once a day, we end up with a targeted service life of two years. Whether we'll reach that, I can't say yet, because the minion isn't that old yet. But it's looking good.

Very good. With one to one and a half years you can already do a lot — the maintenance cycles fit that anyway. And the most exciting part is always finding the right use cases for the respective capabilities. Then on to the gateway: the antenna is already a challenge in this installation space, and you transmit over the cellular network — which makes the device very attractive for providers of larger systems. You can pull the information directly from the field. Can you explain how that flows from the device all the way to the system operator?

Dennis

We use the common standards: LTE-M — which is essentially what's also in an ambulance, so a bit off to the side of the normal cellular networks — and NB-IoT as a fallback solution. NB-IoT doesn't allow as much data through, but it has very good availability. We take the data, encrypt it, send it over the cellular network to the nearest cell tower, and then it lands in our mobile carrier's VPN and is channeled from there into the cloud.

The cloud is either the autosen Cloud, which we provide along with it — a version of Cumulocity branded for us. But we can also simply say: you have your own MQTT endpoint, and that's where we send the data.

What would the alternatives have been? Did you make a selection — choosing this and not that, for these and those reasons?

Dennis

Cellular offers several options: 4G, 5G. In the field of industrial communication, we have NB-IoT and LTE-M. And something you shouldn't underestimate in Europe is good old EDGE, i.e. the 2G network — when we see that on our phone we always get a bit sad, but for IoT it still works quite well. However, we decided against 2G, simply because these networks are being switched off worldwide. The standard is moving away from it.

5G is ruled out because the advantages of 5G lie in low latency. In our typical use case we transmit data once a day — that's a few bytes. We have no need for high bandwidth and no need for low latency. So we opted for the standards that require as little energy as possible. Since we have the battery, we simply have to save power as much as we can. And that's exactly where LTE-M and NB-IoT come in, matching the data volumes we transmit.

Gateway-based solutions would be another option — there are many technologies where lots of small devices transmit over one radio standard and send their data through a central gateway to an endpoint. But we deliberately didn't want that, because we want to tackle fully distributed assets where we don't have to set up another gateway every time. And that's how we ended up with cellular and these cellular standards.

I always find it really interesting how different products and solutions come about.

Dennis

Though it has to be said: the device has a modular design, and we're not done yet. There will certainly be other means and methods as well.

Can you also speak to the variants that are currently available? We've covered the battery and the gateway — the sensor is now the open topic, and that's probably where there's the greatest variety of variants. Can you lay out the configuration once more?

Dennis

In the battery area, we found that there are some places where the customer wants flexibility — perhaps even willing to run a cable. We've even caught customers cutting the batteries open, separating out cells, and building their own power supply onto it. As an engineer, I think that's great, of course; as a salesperson, somewhat less so. That means we'll also be offering an additional power supply unit that allows the customer to operate the device however they like. It comes with an industry-standard connector, a component that brings the voltage down to the necessary level. You can also connect a solar cell with a buffer battery — the flexibility is very much on the customer's side.

On the sensor side, we currently have three sensors in the portfolio for typical scenarios. We talked about vibration. Another sensor is a radar sensor that can determine fill levels or distances. In addition, a climate sensor for temperature and humidity. And then we have an adapter that I'm especially enthusiastic about: I simply connect a 4-to-20 milliamp analog sensor to it. The minion then powers this sensor, and that way I can connect industry-standard sensors digitally via the minion.

And for anyone who needs even more, we've developed a protocol that sits between the gateway and the sensor — we call it SensCom: a specification for hardware, software, and interface. It enables our customers to build their own sensors. We already have customers who have done that — who have built force transducers or measured currents with it. In this way we've achieved a high degree of genericness and once again put the flexibility into the hands of our customers.

When you develop something like this, all kinds of complexity levels come together: battery, gateway, antenna, sensor technology. Do you have all that knowledge in-house? How did you set up partnerships for it?

Dennis

autosen is a small, mid-sized company with roughly 30 full-time positions. It's clear that we don't do all of this in-house. Many people will know that we're very closely tied to ifm — there's a great deal of contact and collaboration in the area of sensor technology. The know-how for the gateway lies largely with autosen and was also created largely by autosen. But that doesn't mean we don't have strong partners — for example Murata, who supply a radio module and have built antennas for us that didn't exist in this form before. I always say: everyone said you couldn't realize high-performance antennas in this installation space — and we did it anyway, together with our colleagues at Murata.

The battery, to be honest, is a bought-in part. It's developed in Japan and built and tested in Thailand. A nice international partnership has grown out of that as well.

Great, now back to the fields of application: what does it actually deliver? We've talked about battery life — what other relevant performance figures are there?

Dennis

The most important thing we set as our goal: from unpacking the package with all its components to having the data in the cloud, under no circumstances may more than 30 minutes pass. And we achieved that goal too. There's a great deal of IT in the background that links the minion to the customer's cloud at the time of purchase, based on its serial number — so that once it's assembled, it has to search for the cellular network just once, finds it, and immediately sends the data to the right endpoint. Annoying configurations, entering IP addresses, and so on — all of that is eliminated.

What the customer does have to set: how often the minion should transmit, how often it should measure — for that we built a wizard in the cloud that you run through easily with a few clicks.

That's the central theme — in the past it was often too complex to set up topics like this. Then you need the IT department, but you're actually in a factory environment. Do you deliver the devices directly to system manufacturers who configure them and ship them out? Or does configuration have to happen again on site?

Dennis

Our goal isn't to avoid contact with customers — quite the opposite, I love engaging with customers. But for the typical business model of visiting every customer, having a coffee, and then going to the plant, we simply don't have the staff. That can't be mapped onto our business model — hence this approach of simplicity.

Nonetheless, we have consulting packages: you can call us in an easy, unbureaucratic way. We can also travel to the customer, install and configure the sensors, and really figure out what the relevant measured variables are and which KPIs need to be determined. That way I get around a bit too — and honestly, I love seeing where our devices are being used.

And when people ask: which systems did you build the minion for? There are so many different things you can do with vibration measurements alone that it's really hard to fit it into a short list.

That naturally makes my next question harder. I would have liked to ask whether you have an example calculation — did it pay off for the customer or not?

Dennis

That's of course difficult to say, because that's the customer's business model, and they in turn have their own end customer. People don't like to disclose that. But let me lay out an example calculation.

I'm firmly convinced: I don't need to measure anything if I don't derive an action from it. If I don't do anything with the measured value, it does me no good. As an example: I have a large heating-oil tank on my company premises — let's say 30,000 liters. If I go and measure the fill level, that's nice at first. Then I know when it's empty — and ideally it's not empty in January; instead, we have the chance to ensure that our processes keep running. But that's still boring — at first it's just measuring.

Now, though, I could think about a very simple automation. Oil prices fluctuate over the year — seasonally, and sometimes even intra-seasonally, by as much as 10, 20, 30 cents per liter. If I now define two thresholds: first at 20% — that's when I have to refill. And second at 50% — when the tank falls below 50% and the price is close to the minimum of the last two or three months, I automatically reorder heating oil. Then, with a 30,000-liter tank at typical consumption, I can save a good 3,000 euros a year — through such a very simple automation. And the measurement system pays for itself after just one month.

And I see this in a great many places where measuring is still done manually, where someone comes, transfers it onto paper, and then again into an Excel spreadsheet. We waste a lot of labor on tasks like this that we could be putting toward smarter things.

Another example: a customer of ours monitors tanks located at their customers' sites. Their business model is: the end customer doesn't worry about fill levels at all — they've simply paid for the tanks to always be full. You could solve that by just always refilling. But you can also determine the fill levels and, when they fall below a certain threshold, plan the delivery in advance. That way you can adjust production and delivery routes accordingly — you save trips. And the end customer is simply satisfied, because their processes always keep running.

Nice example. As you said at the outset with your vision — wireless IoT everywhere, and that we're then simply better off, processes run more reliably, failures are detected immediately. I think there's still a lot to be done across the board. And with more data, especially in the AI context, further use cases and automations become possible that perhaps can't even be mapped out right now, but will emerge step by step.

As we come to a close: what were the biggest mistakes? Developing something like this is no small feat, and you probably paid some tuition along the way. What are the insights from this build process that can help listeners — if they want to build such elements themselves or work together with you?

Dennis

We've already talked about the size. You asked, does it really have to be that small? From today's perspective, I would actually set aside one or two applications, build it a bit bigger — and in return simply generate more reception, more battery, and thus more service life. We realized this when we pursued the 18 mm approach and fixed the size right from the start, instead of considering: let's first start as small as possible and see whether there's still something we can optimize there. We could have done that differently.

Otherwise, we learned: where do we want to be sharp, where do we have to be sharp? We handled that quite well. In the area of SensCom we're very generic — we can integrate any possible sensor that adheres to the protocol. At the same time, we tailored our own sensors very sharply to the use cases where we genuinely saw a use case.

And then I'd also say: bring critical tests forward a bit earlier. We had a mechanical issue — we had to rework the design of the connection between the individual parts. That cost us half a year. It was necessary, but we could have done it earlier.

I glossed over that briefly earlier too — the plug connection, click connection, what did you call it again?

Dennis

Snap fastener — others say bayonet mount. It's a fastener with a small twisting motion.

Something like that is really impressive when it works well and the parts mesh together with high quality. Great, thank you very much. From my side, I found this really exciting: very concrete, based on a concrete solution, and we also talked about the application areas and the benefits. Do you have any further remarks that might interest our listeners?

Dennis

First of all, I'd like to thank you for the opportunity to speak openly here about the minion — to share a bit of behind-the-scenes insight and also to say what didn't go so well. And otherwise, I'd be glad if our listeners keep in mind that the minion is only at the beginning of its development — there will be more to come. And I think it's worth following us to see what will become possible in the area of radio technology, battery technology, and sensor technology.

What's the best way to stay in touch?

Dennis

Above all, follow us on LinkedIn — that's the best idea, I think. Subscribe to the newsletter, take a look at the autosen website. And if there's concrete interest, we have an appointment-booking tool where you can look at my calendar and book a slot. That should also be of interest if you'd like to talk a bit about the technology.

I found it very interesting. Thank you very much, Dennis. I wish you a pleasant rest of your day, and until next time.