 Welcome everybody. I hope you're having a good time. My name is Michael. I'm in the development team of the IoT service from the SAP. And today I'm talking about the IoT service, how we run it. Of course, I want to show you a little bit of the demos that you know what we are talking about. And of course, since we're here at the Cloud Foundry Summit, we also want to jump into what are the challenges? So what are we leveraging from Cloud Foundry and how this all fits together. But before we start, you might have seen already some presentations about IoT today or in the past. Just a short motivation. Of course, IoT is about connecting things, devices, so whether it be machine or robot, and collect data from these devices and of course make meaningful value out of that. So connected to applications like predictive services, remote maintenance and whatever scenarios you can have. And of course, the challenge is how do we get this data? Because these machines rely of course on how big they are, how much data they produce, what kind of data they produce, maybe structured data or unstructured data. Then of course, how they talk to each other. So we are talking there about protocols. So there you see it's a huge here to genius world. And this is of course, a big challenge. And in order to get this data from these devices, you need some kind of data ingestion. And that's the promising of an IoT service, basically to collect the data from these devices, connect these devices, even they've arrived at protocols and of course, in their characteristics, and then provide this data to the applications. I mean, I just now talked about, let's say, collecting data. Of course, it's also the other direction. Sometimes you maybe want to change your configuration at the device or even send two commands to them. So we are talking now about, let's say, bi-directional communication. So you have devices on the one hand, collecting via sensors, data, so whatever this may be, maybe temperature or certain status. And on the other hand, you want to send commands to the devices up to even firmware updates for software. And of course, this is a challenge what we are facing. Now, what I'm talking about now is an offering which is called SAP Cloud Platform Internet of Things. So this is basically what I call and refer here now to IoT service. It's based on an acquisition. So last year, we acquired a company based in Italy called Blood One. And this has been very strong in connecting a set of devices and supporting a variety of protocols in the IoT space. And of course, we move this into the cloud, into the Cloud Foundry environment. This is why I mentioned here now for the Cloud Foundry environment. We started with a beta program because it's really important to listen to the customer, what are the needs, maybe like how to collect the data, where to collect the data, and what kind of data. So one example, I even have it in the audience, was with Mitsubishi, where we presented a demo at the Hannover Fair, so how to collect the data and then visualize this in an according manner so that we collected the data from a robot. And after a certain time, we got all this feedback, of course, put it right into the development, and basically offered the service now since May this year. We offer the service. We run first on Amazon Web Service. So this is our basically first cloud provider. Of course, we are intending building on top of SAP Cloud Platform. Therefore, we are using this multi-cloud approach. I will talk about this at a later moment. Plat one. So PLAT dot one. Now, since I want to go a little bit more into the detail, I pulled out an architecture slide which shows on high level what components we are talking about. I'm always talking about devices, so connecting devices. What do we see in the left side? Are devices which may talk different protocols? What we support out of the box is the communication via MQTT, so this is a very common protocol in the IoT space, and, of course, HTTP to the cloud. And now in the center, what you see is the IoT service running basically as a banking service on AWS. And with that, we have multiple components. One is the IoT gateway cloud. Maybe some of you have listened to the integration of BIM. So this is why it might be familiar to you. And IoT gateway cloud is basically the connection point which provides the variety of protocols. Actually, there are two running two instances because one for MQTT and one for HTTP. So in this data is sent to the IoT messaging service. This is basically our message broker. Underneath, we have an active MQ. So basically, we can publish all messages to our internal message broker and then handle the data. And that's the responsibility of this core component. So to persist the data, we currently store the data in a Postgres database and, of course, provide according APIs to create devices, to create, let's say, the modeling of a device, so what data they can talk to, for example, and, of course, getting the device data via API. So we have a strong approach that we say API first. So this is really key. So whatever you want to do with the platform or with the service, you can do via API. And, of course, on top, we are leveraging also this API via an according user interface. We call it IoT service cockpit. So this is what you see on the top right. This is basically our user interface for creating, visualizing some data and, of course, dealing with the service. Now, since there might be some devices who don't talk HTTP or MQTT, we are having another component or basically the component you see I mentioned before with IoT Gateway, which is basically a Java runtime with an OSGI container, which can also run on the edge side, which means it's not running in the cloud. You have the ability to install this on-premise and, therefore, you are able also to talk other protocols. So we support out-of-the-box, beyond HTTP and MQTT, for example, file adapters. So in case you have legacy files or you have structured data in a CSV format, XML format, whatever have you, you can connect to these files, get the data out of that in a structured format and send this to the cloud. Similar approach we have for co-op, SNMP and Modbus. These are also our very common standard protocols. And, of course, there are more to come. So, for example, we are investigating in OPC UA. So this is a very common protocol in the manufacturing space. But, of course, we want to be open there and allow even partners or customers to develop their own. So this is really important. So once you have a device, maybe it's a very specific protocol in your environment, what do you do then? For that, we will offer an SDK which allows you as a partner or as a customer to develop your own protocol. And I mentioned that this is a Java runtime with an OSGI container. And, of course, it has ability to deploy their things during runtime. And this is exactly what we are doing. So we can install, update and upgrade these individual adapters for these specific protocols via the cloud on this edge software, which means whether you develop your own adapter or use one of the extended adapters, you can manage them via the cloud and basically put them onto the IoT gateway edge. And with that, actually, we already talked about the first part. So we have now the ability to connect to devices with various protocols. And then, of course, we send this data, I mentioned already, to our internal message broker, so the messaging service that we use JMS. And then, of course, have according APIs and whatever to provide this data. Now, what do we do with this data? I mentioned already that we store this data in a Postgres database. Of course, this is one option. But then I talked also to make this application, this data available for the applications. We publish the data to a Kafka cluster. Of course, we have a big data stack afterwards, so to do some data retention. So we are talking about a HANA database. So it's a hot storage. So we can do a strong analytics on top. Then we can store the data in Cassandra or even S3. And on top of that, we have an, we call so IoT application enablement. So we have a thing model, which enriches the data with semantics. So I talked about that we have structured data in a certain format, which we are collecting, which we are providing to the application. And therefore, we are able, basically, to enrich this with semantics and build applications on top. With application, I mean something like predictive analytics, connected goods and all these applications what you can have. Or even that customers or partners can develop their own applications since they're leveraging Cloud Foundry. So you have your own, let's say, build packs or basically are able to deploy your applications there. Customers and partners are able to develop their applications and exactly use the data out of the model what we are providing. So this fits the whole picture. So we are talking about the data ingestion. We are talking about managing or basically providing the ability to connect the various devices with different protocols and of course needs. We are talking about the bidirectional communication. So we are not only sending the data to the cloud. We also can send commands to the devices. So of course, we have a recording persistency layer. We are connecting to certain platform service from SAP Cloud Platform, so namely here Kafka and of course, Postgres and further going to become. And of course, providing this data to the applications in order to make this available exactly there is Cloud Foundry layer. Now, what is this in the end, what we are providing? We were talking a long time, so are we going on top of Cloud Foundry or are we going on the YAS layer? So currently the IoT service, it's a backing service. And there, of course, we are leveraging of some benefits what Cloud Foundry brings. So we have our own service broker there. So we are using full Bosch deployments. So we have different plans for sizing when we provision the IoT service. And of course, we use a Bosch director for provisioning the instances. So I can easily go and do a rest call, just say what sizing I want to have, so which Bosch plan. And then I easily have an instance automatically deployed on AWS. So this is, of course, a huge benefit what we are having. But there are also some challenges which I will come later to when we go with it. Now, of course, we are integrating with certain services as well. I mentioned not so far like how do we do security. So whenever we connect a device to the cloud, we need some kind of security and therefore authentication we use certificates. So we use a trust center service from SAP in order to get device certificates in order to have a secure communication. I mentioned already the Kafka. So basically a Kafka broker in between to send all data to to make it available in our big data storage for the applications. And for example, AWS RDS, where we store currently, for example, the metadata for the device model and what have you. And unfortunately, we have to manage some components even ourselves. So like a Bosch director service broker, and even Alcsec. Of course, we are leveraging also from the platform services from SAP Cloud Platform. But this is something, of course, we have to manage and of course, yeah, this is a challenging thing for us. Now, before I go into the demo, I want to shortly mention the device model what you have because sometimes we talk about devices, machines and what have you. For that, I brought up a short picture to explain shortly the device model. I talked about gateway and protocols. So let's assume we have a device talking HTTP. So then we are talking a really a device, a physical device, which has a unique address, which you address. So for example, an IP address. And within this device, we have an additional abstraction layer which is sensors. You can think of a car which has an engine and which has some tires. Of course, they have totally different semantic sensors and how you address them. So this is why we have an additional abstraction layer. And of course, we want to have a reusability. So let's assume you have four tires and each tire has a temperature sensor. You don't want to model each one itself. So what type kind of data it's sending and so on. So we introduce an entity so-called sensor type, which you can reuse. And what does the sensor type actually does? Yeah, it defines what data we can send to the device or the device is sending to the cloud. And there we're talking about capabilities. I mentioned something like a temperature value already, which would be one property. So like let's say a double value send to the cloud. And if you have more than that, you can encapsulate this within one capability. Now let's go to a short demo. So I have not bring a big, huge machine with me now. So I thought something, what is light and what is handleable? So I feel such a sensor type. It's basically this measures temperature, acceleration and what have you. But this one is talking Bluetooth. So it does not have internet connectivity. So therefore I'm just using my mobile phone here, which connects to Bluetooth to this device. And then I want to send this device. But firstly, let's see how we do that. So what you see here now is IoT service cockpit, basically the user interface, which I was mentioning in beforehand. And here I already modeled and created certain devices. One which you see here is already this is our sensor tech here. And if you look into that, I mentioned we are talking about structured data about modeling of capabilities. And here you see that this sensor here has certain capabilities. So sending, for example, the acceleration, the pressure and temperature. So exactly what I was talking about. And if you can press on this one, you will see, okay, this is a single precision value. So basically your float value, which is defined here. So this is the data what we are expecting. And even we have a measurement, so a measure unit. So we are expecting here Celsius. So not that you're wondering that it's really that cold here. So these are Celsius values. Okay, so this is what we are doing. And I mentioned about certificates. So what you can do here even, you can download your certificate, especially specifically for this device. I did this already beforehand. So I downloaded a certificate on my laptop. And if you now show, let's see if you are receiving some data. So for that, I select this note here or let's say our device. And I want to say some real time data. So there's nothing coming at the moment. Nothing is incoming. But for that, let's use basically the console. So I use curl. Basically, this is a tool for sending HTTP commands or HTTP posts. And what I'm doing now is sending here basically an HTTP post with my certificate. So I have a certificate file to my laptop and a key for that. I send this with exactly one value here. So the value here is zero to the specific device to my instance. So I just do this two times. And what we should see now here, so there's two times of value zero arrived. So now since that you also want to see something. So I have now here a value which is 21. So you see this here on the lower corner. So I sent another value 21 two times. So via HTTP. And if you go back to our cockpit, we nicely see that the data arrived. So this simply shall show the ability that sending basically measures with certain semantics to the cloud. And here to show this even more practical. I said I have now the sensor tech here. So this was just some data sent via curl. So what I have here now is the mobile. So I'm starting on application, which is actually connecting to this instance, which I just showed where I showed the cockpit. So I connect to this instance. So I will select my device was currently this device over here, which is now popping up. And last but at least I decide how to send the data. We just have seen HTTP. So let's now use MQTT. Certificates already installed here. So this is why the connectivity works. So now I'm connecting to the cloud via MQTT. And if we now go back to our cockpit, we have to select a different device because now it's a sensor tech with MQTT. And let's see if we see some real time measures. And there we go. So this is a real time measures here now on the upper chart for this temperature. So if I hold it in my hand, I should see that this temperature is increasing. There we go. And of course I can have even some more fun. So not only selecting the temperature, also maybe the acceleration. And if I set these three values and just turn this around, you will see that this is all flipping up and down. So we are talking here now about, let's say real time data consumption and ingestion. I mean, now I'm using the interval of one second. But it shows basically that we are able to collect the data from a device, push this to the cloud. This data is persisted in parallel. And then of course, this user interface subscribes to the data and makes this available for the end user. Of course, this is only in the cockpit. The same, of course, applies for the application. So if you now develop an application on top, you exactly make use of this. So you have the semantics. So what data we are talking about. So is it a temperature value or something else? You know what data format we are talking about. So are these integer double values and whatever have you. And then of course puts this in the cloud. Now what have been the challenges? I mentioned there was a strong decision. So where do we put the IoT service? Because it would be really beneficial to make use of C path, put it on the cloud foundry layer. But there have been some challenges. And one of them is we are talking about high scale data ingestion. So we are not talking about one device or hundreds of devices. There are use cases with thousands of devices and even more. Which we want to connect to and collect data to and even send data to these devices. And this of course evolves over time. And there's not only one use cases, there are multiple use cases. And therefore you need a huge number of concurrent connections to get this data ingestion. So we had a challenge. That's a go router. Which is basically a single entry point for any connection does not scale or is not suited basically for such high scale scenarios. So we just limited or run out of number of concurrent connections. And how you can connect the data to let's say the cloud foundry layer. So this was one decision why we had to move basically to the YAS layer. And then secondly, this is why I basically focus on this scenario with MQTT. So there are certain ports and of course certain protocols necessary. And at the cloud foundry layer you have really limited support in terms of protocols. So HDP is supported. And of course this is one limit. We cannot face because we talk about IoT, about connecting the variety of protocols. And of course this is a very strong requirements. And if you don't manage that, we cannot talk about IoT. So this is why we decided to go to the YAS layer. But even there you have some challenges because if you go to the YAS layer, you miss all the nice features which you have in the past layer. So I mentioned that we have some, let's say our self-managed services, like Bosch Director and whatever have you. And like the Alkstek. So everything which is about scaling. So basically just provide another instance, failover come and logging and of course monitoring whatever comes with the past, you lose. So you have to do it yourself on the YAS layer which is of course quite challenging because it's additional effort and it's additional infrastructure which you have to maintain, operate and whatever. The last thing is about scalability and multi-tenancy. So we need to scale out for certain components. Let's take certain components like the IoT gateway. It would have been nice if this instance or this one's on the Cloud Foundry layer. You can easily just create another instance or container and whatever have you, but beyond the YAS layer. Of course there are options as well, but you have to do it differently. And of course this is something which we are working out. So pick out individual components, how to scale them. And of course we are discussing putting certain components on the Cloud Foundry layer. Of course as I said we are still there in the integration process, but this is of course challenging as we are facing. And there of course, like the first ones, again we come to this question. So how can we improve with the Go Router? So how to support these high-scale scenarios on the Cloud Foundry layers and even introduce additional protocols because it won't stay with HTTP and with MQTT. Of course there are many other protocols we want to support, especially on the Cloud Foundry layer. And this is exactly where we are going to go to. So we are going to introduce multi-tenancy at instance level. So what I've showed you is a cockpit I locked in with basically a tenant on the application layer. So we have a very fine-grade access control, which means you have certain devices and you can exactly decide which user within which environment or tenant we call it, can it have access to data or create devices and of course there are certain roles. But we are talking about here now about multi-tenancy, so to have not only let's say an instance, provide via bush release so that you have even multiple tenants within this environment. And of course this is a challenge which we are facing now. I mentioned already the scale out, so for individual components. So of course we will discuss which components put on the Cloud Foundry layer and last but not least multi-cloud. So what I have shown you is running on AWS. I mentioned that we are also making use of AWS RDS and of course we need to get rid of that and we are connecting to certain platform services. And this is of course what we are working on. I'm sorry. Then when I locked in I have not shown you this. You go with your own user management and of course it's very important if you're dealing within the application and then you want to go to the IoT and of course managing these. Of course these are different roles of users and certain type of users. But that's what we are going there of course integrating with URA so that even Cloud Foundry users are able to log in of your service. And last thing what I also would like to mention, I've shown the authentication we have certificates. So of course this is the most common used security mechanism in the IoT space. But like token-based authentication like OOS, this is something which is easy to handle and of course especially for starting scenarios whatever. This is really important. We use this also in our IoT service in the NEO environment. So basically one of the other IoT service and this is also what we are going to introduce so that we have a token-based authentication for certain devices. As I said there are many challenges. So it's not just that you take a service and put it in the Cloud Foundry environment and it works for all use cases. IoT has its specific requirements. This is important to note. And of course I hope I could give you a short introduction of what the IoT service are about, how we make use of this, what the challenges are and of course looking forward to feedback. So thanks for your attendance and thank you.