In this episode, we discuss how improved data access control can remove barriers to use case adoption in complex environments by enabling effective IoT governance. We also imagine a future of connected industry where data is an asset to be monetized effectively.

Peter Sorowka is the Chief Technology Officer and Managing Director of Cybus. Cybus develops a smart networking solution for Industry 4.0 and the Industrial Internet of Things (IIoT). Cybus enables innovative industrial equipment manufacturers to provide data-driven value-added services, such as quality management, remote monitoring or predictive maintenance, to its customers from manufacturing and logistics. For more information, please visit cybus.io.

_______

Automated Transcript

[Intro]

Welcome to the industrial IOT spotlight your number one spot for insight from industrial IOT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome come back to the industrial IOT spotlight podcast. I'm your host Erik Walenza CEO of IOT one. And our guest today is Peter Sorowka managing director and CTO of Cybus. Cybus lets you connect digital services as easily as installing apps on your smartphone and enables you to keep control of all the data that is about to leave your factory. In this talk, we discussed how improved data access and control can remove barriers to use case adoption in complex environments by enabling effective IOT governance. We also explored a future for connected industry in which data becomes a tangible asset that can be monetized through new business models. If you found these conversations valuable, please leave us a comment and a five star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@iotone.com.

[Erik]

Thank you, Peter. Thank you for joining us today.

[Peter]

Thanks for having me.

[Erik]

So Peter we're going to be discussing primarily today. Cybus and the solutions that you're bringing it to market for the, the smart factory. But before we jump into the company, I want to just learn a little bit more about where you yourself are coming from and how you ended up as the CTO of Cybus. Can you give us just a quick background on what led you to the managing director and CTO role here

[Peter]

I, myself, I am electrical engineer originally, but also in my studies and my research work after university, I've always touched more bits and bytes than electrons. So I would consider myself being a software engineer today. And I would say roughly five years ago, maybe it was five and a half, the whole IOT industry 4.0 hype started and back then two friends of mine and I decided to start a company in this field. And the, the main motivation that we had back then was that we were quite excited that the concepts of the internet, so interconnectivity, API APIs and so on were proposed to be extended to the real world. And we immediately understood the plethora of use cases and applications and systems that will be needed to be connected across windows. And we decided to take a very specific niche and to have to create a company that works on the, on the layer. That's usually called the gateway layer because that's a necessary evil everybody needs, but that supposedly doesn't create any value as its own. And we decided to be a company that has a core competence at the position where many others have a necessary evil and provide a focused solution on this layer.

[Erik]

Okay, great, this just came up in a conversation with an investor last week, the pain she was having with our portfolio companies there before we jumped into that, I have to take you on a quick diversion here, so apologies for this, but I see that you were running a peer to peer sharing platform for sailboats. Can you just give us a quick 60 second? What, what was this company that you had set up this boot shaft?

[Peter]

That was very, very good. So bolt shaft, it's a German play on words actually today you would describe it as Airbnb for sailboats, I would say. So we enabled private owners to share the sailboat through an app that we created that in 2010. And that was before Airbnb was at least in Germany famous or well known. And so we, we, we created everything from scratch three programs, that whole system to connect the sailboats and set ups systems from scratch. And today I would say what we did back then was an IOT platform for sailboat sharing. So we already had some insights into the technology that was required for IOT use cases. And also we had already done a number of mistakes, I would say technological mistakes or wrong decisions and learned a lot. And with this experience, basically we decided to go on the industrial market and apply our learnings and create a company from that.

[Erik]

Very good. So let's then dive in here. You've already alluded to the problem that you are solving here. Can you just describe a bit the tech stack on a typical solution where Cybus would be useful and how you fit in there? What is the pain that you're solving? And the typical tech stack we have focused on really the industrial IOT market. And I would narrow it a bit more down to connecting assets in factories session areas. So we are, it's really more about connecting machines to it systems in general. And then the interesting thing is there are so many perspectives from which you can approach IOT and the factory. There are so many different stakeholders that are interested in connecting the very same machines, two very systems. So you have a, you have a big data team that tries to connect machine data to a data Lake in order to do big data analysis.

You have a maintenance team that wants to do smart or on demand maintenance planning. You have a production manager wants to introduce an MES system, and then you have all the clouds and then you have all the external stakeholders like the machine builders, suppliers, customers, insurances, banks, and everybody wants to connect the same machines to different target systems. And as everybody is bringing along their own gateway, that more or less uncontrolled would send the data somewhere. There's an interesting playground. I would say to introduce a layer of that distribution and to give control into the hands of the factories and in the end governance into the hands of the it departments to not lose overview about which data is collected, which data is sent, where, and also to avoid basically double connecting machines because you have two different gateways for the same machine because you have two different target systems. So that's the playground we are working on. And so our offering is a pure standalone. So not cloud connected or not clock dependent, let's say like this, a pure standalone software solution that's running on premise in the factory and it allows a multitenant and multipurpose data distribution.

[Peter]

So you mentioned that there's many stakeholders that want access to data for, for many different purposes. And then there, of course, are some stakeholders who expressly don't want other stakeholders to access their data. So I think a, a number of the larger kind of legacy sensor and PLC manufacturers try to put up barriers because this helps to protect their market share. Are you relevant in that kind of that, that battle to gain access to data when it's a, it's somewhat being protected by an OEM or, or is it basically this data has to be in the gateway? So there has to already be, let's say access to the, the end device before Cybus would be able to say regulate the flow of this data.

I mean, as you know, especially in the industry, we are really coming from a world where secrets like a secret protocols, secret proprietary data and codings also were put up to to ensure some competitive advantage and so on. And this kind of contradicts the I in IOT, right? I mean the, the internet lifts from APIs that are open and standardized and very non secret. And that's an interesting contradiction, I would say that's also something I observe the industry has along the last five years, that this idea that you always have to keep everything secret, must be given up a little bit in order to gain a joint benefit from collaboration still. It's not something that is simple. And, but there are some very interesting associations that have been founded to solve these problems. Specifically we are a member of the of the international data spaces association that tries to, to, to solve this problem that there is at the same time, the, the demand to protect data and to share data from different stakeholders.

And you need to somehow create trust. And the industrial, the international data space association has a very interesting reference model to solve this problem. There's even a inspect or just released for this which will become an ISO standards too soon. But there are also other associations like the open industry, 4.0 Alliance, which is also a German association of specifically sensor manufacturers that have realized years of trying to solve individual IOT solutions that in the end, the customers have a hard time accepting the incompatible solutions from the different suppliers because manufacturers, most factories have not only one supplier, but many. And if every supplier has their own full stack IOT solution, it just doesn't work. So they have to collaborate. And so there are these standardization efforts. We are active in some of them in the active world groups, and we try to always keep our software solution up to date with these standardization efforts to be able to be a solution provider in these specific groups.

[Erik]

Based on your perspective. I think you have a fairly unique perspective based on where are you on the tech stack? Where are we today in this, let's say this struggle. We looking at a three year time horizon or a 10 year time horizon, or who knows one time horizon when data from the vast majority of end points will be standardized, maybe not to the point, you know, HTML or HTTP, but standardized enough that somebody can go in with, you know, an application provider can go into a factory with a good application and they can get access basically to the data that they need in order to apply that. Cause I still today I talked to a lot of companies that feel like they need to build a full stack and deploy their own sensors in order for their solution to work. And it's a, I think it's a very interesting topic. What you know, where we are today in terms of the status quo and what the timeline might be to, let's say Nirvana.

[Peter]

So that's a super interesting question. So I think we are, when I dropped the history of, of IOT in the industry, then I would say for a number of years, everybody has been working on proof of concepts and pilots. Many companies still have a hard time getting beyond that because they realize that certain questions like the one we are just discussing really just arises. When you try to scale that particular project, it's fairly easy with today's technology, even with a raspberry PI and some open source software to just connect the machine to some cloud and do something right. And now I think we are in the beginning of the phase where people start to realize that they really need to find some standardization, but still, I think to be very honest, I think most associations are not on the right track for now. They try to overstand or dice things to the standards are getting fairly big.

And we had the same in the, in the classic internet. So the classic internet try to find very complex standardizations like for the tech experts, from the audience, like the soap standard. So it was a technology, an interface technology basically based on XML, which tried to be, be able to explain the world that is super complex. It's super complete, I would say, but it's super hard and annoying to implement. And in the end, after this effort to have a very complex soap interface where we ended was the rest API and the rest API is what you see as a standard everywhere. So it's not important if you look at PayPal or Amazon or any other project, everything has a rest API, you even start creating your rest API when you program the new software today. And the rest API is the most simple and most non-standardized thing in the world, but it's so simple that it's trivially easy to adapt to a new recipe. And I'm pretty convinced that in the industry, we will see two or three more years of trying to over standardize everything. And then I hope that we will observe that things get more pragmatic and specifically I've a lot of trust in MQTT as a protocol, as becoming something as simple and pragmatic and straightforward and open like the air rest API has become for, for the classic internet. Okay. Okay. Very interesting. I hope so. And I guess this is going to be a bit of the open question right now, but two to three years, that would be a very welcome timeline for everybody.

[Erik]

To make it, make some sort of transition here. So I suppose where you are today, where Cybus is really providing value is not necessarily then providing access to the end points, but it's in a situation where this data is already moving to the gateways. You're providing value around governance, the it efficiency of managing who has access to data. And then is it also being able to, let's say optimize the use of gateways by not requiring kind of duplication for every use case that's being deployed with. Would those three be the, kind of the key elements of your value proposition or how would you frame that kind of the core elements of your value proposition when you're introducing to a new customer?

[Peter]

Okay. So that depends on, on which type of cast customer we're talking about. So we are selling to two fundamentally different customer groups.

One is the factories. So we are selling directly to factories. So operators of industrial production equipment for them, the governance problem is really the biggest one. So we, as I said, they have dozens or hundreds of machines from different ages, from different vendors with different maturity, I would say too, in regards of digitization. So some already have a user net and you can just plug in your cable and start reading the data and then modern protocol and many don't even have any digital interface. So really being able to abstract this heterogeneity and then route the data to different it systems, that's really the governance problem. And it's also the scalability problems. So when it comes to how to implement standard standardized processes about how the next machine will be connected, how to extend the data, that's gathered how to pre-process the data or where to do the pre processing.

I mean, if you look into it into the big enterprises, the biggest pain is usually called customization ERP systems. MES systems have a very high degree of customization because you're adapting your target system for, for every new data that's arriving with every new process we try to, to to take away the customization efforts in the target systems and on the machines, because we believe you should never be required to change a PLC program just because you are connecting in another cloud. And we try to, to, to centralize this customization effort into a configuration effort on the middleware layer, basically, and then it's really scalability is customization savings. It's security because when you connect to machines, you can also control machines, right? So it's very, very critical to prevent that if you don't want it and to allow it, if it's required and the second customer group, now that was a long sentence.

The second customer group are, the suppliers are the machine vendors are the insurances that are external to the factory, but also want to bring in some infrastructure, some gateways in order to get data out. And for them, we thought totally different problem. That's mainly acceptance, acceptance that your customer would share the data because there's this always open question who owns the data. And my answer to this question is it doesn't really matter about who owns the data, but it's very clear who has control over the network, where the data comes from, and that's always the factory. So when you start creating the gateway as an external company, you usually create a black box that's even remote controlled. And that somehow does what you want. And we propose to have not a black box gateway, but to give the control about the date gate gateway layer into the hands of your customers, but stay in control about the software and the configuration that's running there. And that's a very special, special USP off of the cybers connect web, because we can, we can combine, combine these two desires, the control desires, factory, the delivery, basically of the, the supplier about the actual intelligence and the configuration. This is really two very different that you propositions. I would say two very different customer groups, but in the end it will be always one installation of our software in the factory and serve those needs. Okay.

[Erik]

And is it more common that you'd be entering the factory initially through one or the other of these customer groups?

[Peter]

It's really today 50 50. So 50% of our customers are direct end users and 50% are suppliers. Then you have often a dual cases because most suppliers have their own factory as well. Right. And we of course are hoping that's an open secret to gain some acceleration when the machine vendors and the component suppliers start rolling out in large scale with our software distributing and factories, that's our strategy. But to be very honest today, the market is not that fast.

[Erik]

I'd like to dive into a little bit more detailed for both of these cases. If we focus first on the factory, this is actually a, a point that's very relevant to me at this moment because we have a company that we're working with that has this, this challenge, right? They're moving to a new greenfield facility. They have some legacy use cases. They want, they have some new use cases that they want to deploy. And the question is, how do we minimize the complexity and the cost of both deploying sensors to acquire this data, to play in their connectivity. And then also to an extent, you know, deploying specific applications, we don't necessarily even want to have a unique application, or let's say app for each, each application. We want to try to standardize some of this. So there's a lot of complexity in this situation. In this case, they prefer to have a platform that is governing the processing and the storage of data. And then there's the question of what, what requirements do we, you know, do we put into that platform? Well, when we build it and those requirements would be driven by the use cases. So if you're moving into kind of a messy situation like this, how would you view this? So what would be your main questions, your main lines of inquiry in order to understand the customer and then understand how your solution can help them to resolve some of the complexity?

[Peter]

My approach on, on complexity, like an answer with a very simple word, that's decoupling. I try to decouple everything from everything. And in the, in the classic software development, we have a notion that's called microservice architecture. Microservice architecture means we try to split a big complex software project into individual independent modules. And these modules can be developed on their own and don't know anything about the others, and they can have an individual lifecycle. And this is very efficient. It also has some challenges to be honest, but it's very efficient because you can throw away modules, you cannot use new ones, you can replace individual ones. And I see the smart factory as a very big microservice architecture. So I have my data sources and I have my data sinks and the data sources are usually the centers and the machines and so on. And primarily machines should do what they should do, produce stuff.

So primarily a PLC has, if you ask me the tasks to control the process and a real time fashion, then very efficiently PLC should never know anything about a cloud or an MES system. Or so instead I see then the, the protocols like OSU or Mo, or it doesn't really matter as like the API to the machine and the machine should expose the data it can provide. And it might also expose some, some control and points, but then that's it. And the same on the other side of the table and MES system is an MES system. And it has many information about processes and orders and order numbers, but an MES system has no idea about big data or predictive maintenance or even maintenance process that it shouldn't have because that's not its, so I really believe in specialization and I say, okay, MES system or ERP system, you also should implement your specific interface, your API that is designed and the way you need it, that you shouldn't know anything about OSU.

I think architecture in between the middleware that connects the respective APIs with each other. And we believe in MQTT as I just said. So that's the message. Architecture can very well collect data from the one site and deliver it in the right format on the other side, and really draw the lines between the many elements, so many microservices. And then you're pretty efficient because you can, you can, of course installing some such an architecture, such infrastructure for the first use case is quite an effort and it's a bigger effort than just connecting directly, but already the second use case will benefit largely because you just already have everything's there. It allows you to quickly iterate to quickly add more applications, to try something, to let it fall again, if it's not worth it to change something in the bottom or in the, in the top without touching the rest of the system. So that's, that's my approach on this complexity.

[Erik]

Okay. And if you're in a brownfield environment, is, is it any different from, into Greenfield or you just start with what you have and you just built the infrastructure as you've just described it and try to adapt the existing system and infrastructure to this ideal format,

[Peter]

The rough process the same, but of course it's very different when it comes to the specifics because in the brownfield environment, the biggest problem you usually have is that connecting a single machine, usually as a research project for its own. Right? So my, my typical customer interaction here is my favorite anecdote customer coming to me say, can you connect my factory? I say, of course, which data do you need? And the answer usually is everything. And then I ask why, and then the customer would say, that's what I want to find out. And when they then say yeah, okay. So how old are your machines and how different are they? Then usually we end up in a, in an effort estimation that quickly can go towards five to 10,000 European machine because we just have to find out everything. Nobody knows anything about the interfaces and the protocols since the address space, that's usually not effective.

So what we do in the Brownfield is we recommend customers to start very simple and to find common denominators between the machines. And they might be much simpler than the customer expects like connecting energy centers because most machines need electrical energy. That could also already, if you some hints, or my favorite is really connecting the status lights, this little traffic light on the, on the, on the top of the machine, green, yellow, red, which is very, very simple, but just a 24 volt voltage signal that you can easily grab by connecting the things you can with a very low investment already know from all of your machines, if they are currently running or if they have some, some kind of error and that's not much, but if you know it from, from all the machines, then it's already a lot. And I usually recommend customers to start with that.

Then you can start implementing the first use cases like a dashboard that shows the machine status, like very simplified OEE calculation, like notification services for the maintenance team. And as I say, better, start with that and get to a point where you say it's not enough anymore because XYZ is missing. And then we can specifically care about adding XYZ to our data inventory and look after that. And somehow get to a point where we can define a requirement. And with this modularized approach that I said in the first answer, it's very easy to really add more complexity to the system as we need it and not have a dead end road for a specific it system when we started from.

[Erik]

Okay. Very, very interesting. Yeah. Thank you for sharing your perspective there. And then if we look at the other customer group, which is the, the machine builders, the technology providers, I guess one of the key, one of the areas that I think is very interesting, but maybe most challenging is this topic of how to provide data to stakeholders when it doesn't necessarily benefit the, let's say the owner or the manager of the data. So I guess the typical case would be a machine builder or going to a factory and saying, can I have access to the data that's coming off my machines. It's going to be very useful for my R and D process. And I'm going to be able to build better machines and sell them to you. And the factory says, okay, great. You can build better machines. Maybe I get some minor benefit from that, but there's potentially some unforeseen risks.

And, and you know, I'm just not going to, I'm not going to provide you access, right? The default answer is no, but there's certainly a lot of value in these cases to provide any data, whether it's to a, a service provider, a supplier, or a customer who might want to know if their product is coming off the line and so forth. So the question is how do you enable companies to safely and securely provide access to the data, to, to access that value? How do you see this evolving? Do you see a lot of use cases among your customers where they're using Cybus to enable the sharing of data to, you know, in cases where it's not necessarily that it directly benefits the owner of the data, but maybe there's some, some monetization model or there's some way where you can create a little bit of a market ecology around data.

[Peter]

So I'm always a bit reluctant when somebody asks a question like this in the real world. Because I think always, if you, if you have to start about to discuss about data, if that's a start, then something's wrong. I would say that you should always discuss about the value of the predictive maintenance. You should always discuss about the, you will never have a downtime anymore, and that's something you can sell to a customer. And when the customer buys it. And one of the notes then in the contract is by the way that only works. If you share this data specifically for that, then probably the problem has already gone. But if you discuss about the data in the first place, so the data is the only central element, and then you try to find an excuse, why you would need the data, then something is still wrong.

And then I would say we are still very much in a world where nobody really has an idea still. Yes, I know examples where that worked. And actually I have a very specific customer case study in mind from a German milling and drilling machine builder. One of the larger ones who has actually done exactly that. So they have given gateways to customers and they have given them some reduction on the maintenance contract. So they actually, basically, they paid them now for four for getting the data. And then they collect the data, the data for their research work. They were actually quite successful with that. So they, in the end were able to bring a new product family onto the market, which was 30% cheaper than all the other machines. And it was limited in their capabilities. So the Spindler was not turning that fast and the, the machine was just smaller, but that was all based on the learnings of the actual machine usage of customers. And they realize that although customers buy a machine that has this spindle speed of, I don't know, 20,000 RPM, nobody would ever exceed 10,000 RPM. So they learned that they could just sell simpler machines. And that was the story that actually happened by paying the customer basically for getting off the data.

[Erik]

Okay. Interesting. Yeah. And I can see why you generally be adverse to this, but I think it's quite interesting that a lot of the more profitable and maybe less moral or arguably less moral profitable internet companies that really have developed businesses where they sell services or they give away services basically to acquire data and then they sell data. So it's a, it's kind of an open question, whether that's viable in the internet of things world. And if so, where there's a company, a, that a friend of mine ran back in 2013 or 14 and it went, it went bankrupt or they closed it down. But what they were doing was kind of selling at a very low cost. These sensors into factories and the value proposition was you can deploy the sensor, you can collect energy data and understand your consumption of energy, which will enable you to reduce your energy bill. And so that's the benefit to you? The benefit to us is that we get energy data and this was in China. And their thought process was if we can get enough factories to deploy this and we get enough energy data, then we have a leading indicator for energy consumption.

And we can either, we can use this data to, you know, sell this to wall street or sell this to let's say, commodity traders or, or themselves become a trader on the energy markets and have kind of a unique data set that nobody else has, which I thought was, it was at least quite an interesting concept. Obviously it didn't in practice, work out and maybe it was a bit too early, but do you see the potential for kind of energy broker or a data broker businesses to start to evolve? Let's say if you're extremely successful and enough factories kind of have controllable you know, control of their data at the right level, do you see that as a likely course of market development, or do you see some fairly significant barriers to that type of business model becoming successful?

[Peter]

I think that's absolutely the, the, the future. So what I find most interesting is to think about who is able to provide database services in the future, who's able to provide a service like the best predictive maintenance as a service thing. And I think today it's very much restricted to the machine builders themselves, but I believe that as data becomes more easily available or accessible, there's a big potential that other customers, pure digital companies can provide such services. And I think at the very least, because of this value, that you can actually create a business based on data. Something like a data stock exchange will develop, but as you just draw this comparison between our private data and the company data, I think there's a big differentiation to be made between consumer or B2B scenarios, because I think exactly the transparency that we about our private data that we know we are aware of in our private life is exactly one of the things that motivates businesses to be much more careful about their data.

So I think in order to be able to have such a data exchange market in the future, we need to bring the data, producers, the factories, in this case, into the driver's seat, and to give them tools to control which data they sell. And that's exactly what this international data space association is doing. So that they're creating even something like a digital rights model. So you can attach users rights to data so that it's only allowed to use it for a specific purpose, or you're only allowed to keep it for number of specific time in order to, to prepare something like this. So I think that is absolutely the future. And I, I, I always try to do a very simple comparison on your smartphone. We have this very simple user experience that each app tells you what it wants to access from your private data, right?

I mean like Google maps wants to access your location. And of course you allow that because it's peer, you cannot navigate on Google maps without sharing your location. But if a random website or a random app that doesn't have anything to do with navigation asks me for accessing my location, then I would say no, because I need a clear reason to share my data for us, for receiving the specific service. And that's what we try to copy in our software. So when you, when you have a factory and you have, I explained earlier, we have like a multitenant scenario where a machine builder, for example, can provide a plugin to your IOT infrastructure. And this plug in would send certain data to the cloud machine builder. When you activate the plug in at first, it presents you, which data is is transferred. So very similar to this smartphone process. And second, it also gives you transparency along the lines. So you are always see who receives which data and you can immediately interrupt. So this, I think, control and transparency, beats trust.

[Erik]

So I I'd love to dive into a use case or a case study, but before we go there, I just wanted to quickly touch on one other topic that I think we've just briefly mentioned, which is the topic of security. So this is certainly one of the, let's say a top three in any case concern or priority for just about every manufacturer, where do you see the, let's say the status cool of the security landscape right now, and how does Cybus fit into that landscape?

[Peter]

Cybersecurity, when people talk about cybersecurity, you very often talk firewalls, intrusion detection and so on. So the combination is that you will usually call cyber companies, are companies that install something in your network, which tries to monitor your network traffic and tries to warn you when something unusual is happening or tries to control with which device is allowed to communicate with which other device. And if you ask me that's super important, but I think it's not everything because that's like having a security team in your building or locks doors. But as we have such a complex system that we discussed earlier, we will have so many data sources and data things. I believe that there is a security layer that's hardly talked about, and that's really a pure access control layer. So for example, I have a dashboard which shows the current status of the machine and the dashboard is running maybe in the cloud, but maybe also locally.

So then this dashboard should be able to get data from the machine, right? It needs to get data from the machine, but it never should be allowed to also control the machine. And that does the security layer. That's hard to talk about. So really access control, not about who is able to talk to, to whom at all, but to, to narrow it down to the specific data points that are allowed to be red or the specific data points that are allowed to be written back. And that is the security layer where, which we try to, to add to the system, I don't say replace anything, but really add to the system, probably some more technical backgrounds protocols. Like obviously you have a strong security focus and it's the most modern protocol in the industry, but I have never seen an OPC UA server that implements an access control scheme.

So when you have access and you have access, when you don't have access, you don't have access, but there's no in between, there's no gray scale and other protocols like the seven protocol that you use to reprogram also of our network on the Siemens PLC that has not even encryption that has no password. It doesn't have any excess control either, but still these are the protocols that we are basing the whole industrial IOT. And so this really in a positive sense access control layer, so that ensures a least privilege approach. So each microservice that we treat data from another one is only able to retrieve the minimum that it requires. That is some security notion that we add with our software to the whole system.

[Erik]

Interesting. Yeah. I've heard other people discussing, let's say the shortfalls of a firewall because you're, you're not only trying to protect the system from external bad actors, right? There are also internal actors who might have legitimate because of their legitimate access to system, but who could also have motives that are not aligned with the company. Right. So I can see how an access control system would at least constrain their ability to, to act within it's the only attack prevention, to be honest. It's, it's also failures. I mean, assistant can just work wrong in order to cause damage and it doesn't need to be evil in the first place. And also it's also a governance issue because when you have in the end hundreds of systems connected to each other, then you will need to know what happens when you unplug a particular cable now to speak. Did you activate a specific sensor? What happens, which systems will be effected that has a relation, do you need to keep track of and having a well-maintained access control list is an approach to that. Yeah. Good perspective.

Let's then discuss a case study and let's look at it from an end to end perspective. So from, let's say the first conversations with the customer about their they're challenged through the deployment, do you have a particular case in mind?

[Peter]

Yeah, so I would jump again into the case of this milling and drilling machine builder. I mentioned earlier, it's one of the top three in Germany. And they were quite early thinking about digital services, providing basically a web portal for their customers, where they could see their machines, the health status of the machines probably recommendations that order, how to, to, to better perform on the machines and order spare parts, maybe even automatically this customer as everybody else implemented everything on their own in the first place. So they implemented a, I'm not even sure which cloud platform they chose, but that doesn't matter.

So they implemented this portal, they implemented a very simple gateway. They were able to deploy via VPN to their customers and they installed, they rolled it out in the first place in their own premises because that's, it's a company that produces on their own machines. Basically. That's basically the situation where they, where we found them or they found us. So technically everything worked. Of course, as I said, it's technically not very hard, but they had a hard time rolling that out to customers because this was one of these black box gateway issues that didn't find much acceptance, especially at larger customers. That was one problem. The second problem was this customer had created a known department for creating this digital services. And there were a number of software developers in the department sooner or later, they realized that the gateway is not as simple as they thought, because you have to be very universal when it comes to a proxy scenarios as customers, you have to be efficient on deployment. You have to maintain the gateway security critical, as we said and they said, no, our core competence is not creating gateways, but our core competence must be creating the digital services. And so they were searching for a supplier with a play gateway solution that solves the acceptance.

[Erik]

In this case, are you providing the entire gateway? Kind of white labelling gateways and installing your technology? Are you deploying on the existing gateways that they already had deployed?

[Peter]

What we did was pretty interesting because they have already created their gateway or at least the specific business logic they needed for the gateway. And as most people today they implement as a, as a Docker container and DACA is quite  a good plug and play solution when it comes to integrating somewhere else. And we have in our software, our runtime, environmental third party Docker containers, because that's how we consider plugins to be most straightforward. And so it was pretty straightforward to take their existing gateway technology, integrate their specific business logic into our solution and deploy that to the end customer. And so then we basically provided the prepper for product lifecycle management updates, integrating into customer achieves systems, active directory integration that the customers proxy integration and so on, but we never do white labelling.

So what the customer, the end customer again, is a cyber connect with a, we call it service. You could also call it an app, but we call it the service with a service that carries the label of the machine builder. And the service can be deactivated or activated. And if you activate it, then you get presented a little dialogue that explains machine builder, XYZ wants to access data from the following machines. Then of course you have to enter the IP addresses of the machines. And specifically the following data will be transferred to the cloud of manufacturer. And then it really leaves you with allow or not. And if you don't allow it, then of course it doesn't get activated, but that's a sales problem basically for the machine builder. And if you allow it, our software ensures that the opposite end connections to machines is set up that's right.

Data points are subscribed that these data points are made available in the right format to the Docker container off the machine builder that the Docker container is running basically. So that's a plug and play user experience on the same deployment of our subs connect, where you could also either installed similar service from another vendor or do something else with the same data. So in this case, and that's how we have this logic tendency. We have even situations where this machine builder could deploy their services and our software was already there because we already did another sale earlier at the same customer. Okay.

[Erik]

Okay. Very interesting. So this is really almost a sales enablement proposition for your customer care.

What was the deployment time for this? So let's say from the time that you started having conversations to the time this was deployed, what, what does what does a typical, maybe you could ask, what was it for this situation? And then what would be a typical timeline?

[Peter]

It really depends on, on the prerequisites. They were quite good here because as I said, the machine was already equipped with the necessary interfaces and the, and the cloud platform was already developed. So I think we had three to four months. We worked together with them like full time on our site. But just because they have a sprint planning and things develop and we have individual refuse, but I think in very, in a few weeks you can already achieve a lot. It totally depends on, on the prerequisites. So if today, a customer approaches us and says, here's an OPC server, we need a gateway solution for Azure IOT. Then it's something we can, we can implement in very few days. If we start at Houston machine, can you explain OPC UA? And which cloud should we choose then of course, a more complex consulting project starts. The pure implementation is pretty straightforward because we usually don't have to customize anything it's just configuration.

[Erik]

Okay. So your business model, I mean, I guess it's dictated to an extent by just the maturity of the, of the market right now, but then what a typical solution, it would look like some upfront advisory or development costs like a onetime. And then does it move to a SAS model based on the number of gateways or machines or, or facilities, or how does a typical business model look like for, let's say maybe a factory in a in a technology provider.

[Peter]

Of course we can do some consulting work or system integration where we really sell days basically when that's required by the customer, but that's not our business model. We have a small team of support engineers that can help here, but we are not trying to maximize these days instead if a customer really needs consulting or system integration support, we have partners namely from the big ones, MHP and DXC that are trained for our software and they are doing really the bigger projects here. And then our business model is it's a licensed model. And there are two models basically. So when we use held factories and that's a very classic software license, a monthly subscription that's scales was a number of machines. And also with the enterprise grade, basically. So in the smaller tiers, we don't support complex user management and so on.

And in the larger years, you can have high availability, clustering support, enterprise active directory integrations for these service providers. Like I just described this more complex because usually they have they're at the beginning of defining their own business model. So we have a value based selling approach here. And we usually agree on a license per deployment of the service that is a ratio of, of the turnover of the service provider. But that's a very individual thing because we have realized that usually the service providers, they're just they're often at a point where they discuss technology, but their business case is also not find yet. And we try to be not in the way there.

[Erik]

Oh, that's a super, super interesting though that I mean one of the things that really fascinates me around the IOT market is that the technology enables a tremendous amount of business model innovation. Right. And, and you're now in the position of basically innovating together with your hands to figure out what makes sense for, you know, for both of you in the long term. Very good.

Well, I think this has been for me really a fascinating conversation. Is there anything that we haven't touched on yet that you think is it important to cover?

[Peter]

I think we discussed a lot of things. I just, I look into my notes, but there's nothing in particular that I think we have missed.

[Erik]

Great. Then just maybe one last question from me, which is what is the best way for people to reach out to you or to the team if they're interested in learning.

[Peter]

So just the easiest way is send us an email to hello@cybus.io. You can also visit our website. There's some white papers to download it's cybus.io, and we would be very happy if you would reach out to us. It doesn't matter if you're in a factory at the beginning of your own digital endeavor, or if you're in machine builder or components, supplier that wants to provide digital services. Everybody who needs a gateway to get machine data into a cloud might be potential customers.

[Outro]

Thanks for tuning into another edition of the industrial IOT spotlight. Don't forget to follow us on Twitter at IoTONEHQ and to check out our database of case studies on iotone.com/casestudies. If you have unique insight or a project deployment story to share, we'd love to feature you on a future edition. Write us at team@iotone.com.