OCEAN PRESENTATION

Welcome to this presentation on the Internet of Things. I actually love talking about the IoT because it embodies both the promise of technology and its inherent dangers. Depending on who you talk to, the era of IoT will either usher in the utopia of better healthcare, safer, more efficient transportation, increasingly reliable and responsive appliances and more productive workers, or it will create a dystopian nightmare where nothing is private, our critical systems are under constant attack, and nothing we have is secure. So we’re going to talk a little bit about all the possibilities and then some of the things you can do to protect yourself from the downside. So the reality is, is the Internet of Things is really a little bit of both. So it presents wonderful opportunities of things that we can do, and it also exposes some dangers that we need to be aware of. And then after I’m done doing an overview, Aaron is going to actually do a little bit of a technical deep dive in actually setting up Internet of Things coding. And we’re really lucky that Aaron actually comes to us, he joined Eradani from a company that actually made generic sensors, that was the business they were in, and so he was deeply into the IoT or the Internet of Things environment. And with that, I also encourage you, if you do have questions, please enter the questions in the questionnaire or in the chat, and we will try to get those answered for you. So I’m going to talk a little bit about that, the sort of impact, what is the impact of the Internet of Things, and then I’m going to give you some real world examples of things that people are doing with the Internet of Things in the IBM i environment today, then I’ll talk about what are the things to be concerned about, what are the things you need to think about as you start to enter the world of IoT, some of the resources that are available to help you, and then like I say, Aaron’s going to do a technical introduction.

So first, let’s talk a little bit about the whole Internet of Things and why it’s so important. Now, this is a graph of the number of connected devices in the Internet of Things year by year, and as you can see, it’s predicted that there are going to be 50 billion connected devices. The latest I’ve heard is that they’re expecting to have over 200 billion connected devices by the year 2025. So a massive number of devices that are interconnected through the Internet. And when you think about it, that’s just the number of devices. Every one of those devices are sending multiple messages. So the number of messages that are going to be sent via these Internet of Things devices are going to be in the trillions. So there are going to be massive, massive numbers of messages being sent through the Internet of Things that then have to be dealt with by the back-end systems. The idea of having these sensors out in the field is so that you can get useful information. So the question for us is going to be, so how do I process that information that’s coming out from all these sensors that are out in the field? This is just a simple example of an Internet of Things application that I see often in the IBM i world, and that is we have customers who have handheld devices out in their warehouses. So they have different kinds of handheld devices. Maybe they’re Android-type devices, or even older, they’re proprietary devices, where the warehouse workers use them to enter information about what they’re finding in the warehouse for printing barcode tags in the warehouse. So they use them for a variety of applications, and they talk to the IBM i to get data. So they enter information through these handheld devices, they retrieve information from the IBM i on these devices, and then oftentimes they’ll be connected to some local printer where they can print those barcode tags, so they can print information that they need where they are in the warehouse, and I’ve seen many IBM i users who are using these. So this is a fairly simple example of an Internet of Things application. So you have something that is connected, something out in the field that is connected to your IBM i. But we’re seeing an explosion of the different kinds of applications that people might use for the Internet of Things. So handheld devices is one thing, but now we’re seeing for a lot of our customers, we’re seeing more and more smart appliances. In fact, within the next few years, it will be very, very hard to buy an appliance that isn’t interconnected with the Internet, that doesn’t have online capabilities, because the manufacturers are using those devices, those sensors that are on those machines to manage things like their warranty service. They’re also going to use them to manage the reliability of their parts. They’re going to use them to track behavior. How often do you open the refrigerator door? What temperature do you tend to keep your refrigerator at? What’s the ambient temperature where that refrigerator is running? Did you leave your oven on? Has the oven been on for an extremely long period of time? So they’ll be using these systems to monitor the appliances that are in your house. And clearly, there will be lots and lots of benefits to having that kind of monitoring going on, where they can ensure that you’re using things in an energy-efficient way. And of course, there are the privacy concerns that somebody will be monitoring information about what you’re doing. The other thing we see is field sales and field service automation, where people are giving devices to their field people for things like, if I’m a salesperson, I can do all of my order entry, all of my checking of stock, all the things that I might need to do, I can do that from a remote device. But we’ve also seen people who are using them for things like plant inspections. So we were working with a customer that had federally required inspections that they had to do at all their manufacturing locations. And so they would send out their people, and the device would actually track exactly where they were, so that when they were entering an inspection report, it could actually ensure that they were at the location they said they were at. In other words, to make sure they were actually inspecting that device, that they were exactly where they said they were. So they were using the Internet of Things capability of tracking where somebody was to make sure they were getting accurate information. The other one that we hear a lot about are health monitors that are wearable devices. Mostly right now, wearable devices are really being used for exercise and for recreation, but we’re going to see more and more where these connected devices are going to be used for health monitoring. Things for monitoring your blood pressure, your respiration rate, glucose monitors for diabetics, pacemakers, and monitors that monitor your heart, your heart functions. We’re going to be seeing more and more of those kinds of technologies that will track what’s happening with you and feed that information back to your healthcare providers. Again, the great benefit is your healthcare providers will be able to monitor your health constantly so they can anticipate if a problem might be arising, and again, you’re sharing that kind of information in this interconnected way. Smart utilities. Where I live in California, the power company is looking at putting in smart monitors on all of their cables to check for cable breaks so they can immediately shut off power so we don’t have the wildfires that we’ve had over the past several years. So they’re looking at ways of using the Internet of Things to manage their power systems. And then, of course, we all know about connected transportation and smart vehicles so that the vehicles can talk to each other and we can make our transportation systems much safer and more efficient. So there are lots and lots of potential applications and things that people are doing today withmthe Internet of Things.

So what are some of the characteristics of IoT applications? Well, one of the things that’s fairly typical for IoT applications that’s different than what we’re used to working on in the IBM i world is they are mostly event-driven. And in the IBM i world, we’re used to the program driving the process, where you do step one, then you do step two, and the program is telling the application, here’s the order of operations, these are the things I’m going to do. In the IoT world, typically things wait until something happens, and then they go into action. So for example, an example of this are the sensors in the road that control the traffic lights. So rather than the old way where you had a program that controlled the traffic light that would say, you know, every minute we’re going to go through a green, yellow, red cycle, now it’s, well, when a car pulls up, then we’ll start the process of changing the traffic lights. So we’re actually waiting for an event to occur, and then we’ll actually take some action. And that’s a fairly common thing in the Internet of Things world, where things wait until there’s an event, and then they take an action. We’re also dealing with devices with very limited storage. So oftentimes these sensors are very, very, very small devices with very, very little capability. So the programs that you write for them have to be very efficient. In fact, Aaron, I don’t know if you, I remember on one of the sensors you were writing, you were limited to, I forget, what is it, 36K or 40K of memory? I’ll actually talk about that in a minute, but we actually started with 16, 16K of total space on the chip, and then we had to upgrade it because it wasn’t enough. So that, and that’s for program and data. You know, I remember back in the day when I first started programming on the System 34, we had to write everything in a 64K region size. So we could use up to 64K, and we thought that was pretty limiting, but you can imagine if you have 16K, and that’s the total space that you can use, so you have limited storage on these devices. You may have limited bandwidth, so you may have these sensors out in very remote locations that don’t have, you know, big Internet pipes where they can communicate lots of information. So you have to be very, very efficient with the information that you’re sending out. And the amount of data is going to be massive. If you look at this chart, actually I’ll go into this chart in some more detail in a minute, but there’s massive amounts of data that will be coming out through these connected devices. So what are some of the things you need to worry about? What are some of the things you need to be thinking about? Well, security, privacy, and that massive amount of data. 

So let’s talk a little bit about security. Why do we care about security? Well, the thing about IoT devices is they are working in the physical world. They actually have an immediate impact in the physical world. So they can control the temperature of your oven. They can control the temperature of your refrigerator, the heating in your house. So these connected devices can have an impact immediately on your house. On our power system, so they control our power grids. So they can route power to places where they’re needed and take it away from places where it’s not needed. So they’re controlling the power system. You can imagine we want to make sure that those things are secure and nobody can get control of those kinds of systems. The traffic systems, if we get a problem with the traffic light systems, we could create problems in the real world. Connected cars, obviously, if we have a problem, they could create problems in the real world. And of course, connected medical devices, if I’ve got a pacemaker that’s connected to the internet, I want to make sure that that thing is secure. So security becomes a very, very important consideration in the internet of things world. Also, because there are so many devices and these devices have processing power, they have been used to attack systems. And because there are so many of them, they can create massive attacks. Some of the biggest denial of service attacks have been launched from internet of things devices. And one of the reasons for that is historically they have not been well secured. And so hackers have been able to take control of hundreds of thousands or millions or even billions of these sensors and have them launch attacks on websites. So they create an opportunity for creating havoc in the internet. So another reason why you want to make sure that they can’t be taken over and that they’re secure. And it’s often hard to understand exactly what the connections are that get that device to you. So how is that device coming through, especially if you’re using devices that are provided by others, what are the connections it’s going through in order to get to my system and how do I make sure that every hop in that connection chain is secure? Now we’re not going to have time to go into a real detailed discussion of security and how to implement security and internet of things, but I did want to point you to some of the best places to get information on how to do this. So the National Institutes of Standards and Technology has their internet of things security detailed publication that has just gone final and that’s this document right here. And you’ll get the slides for this and you’ll be able to go to this link and you can download that document and it talks about what you need to do to implement security for IoT. Underwriter Laboratories, interestingly, is going to do for internet of things security what it does for electronics safety. It’s going to start rating devices as to how secure they are so that you know if you put a device in your house, you’ll have something to attest to the fact that it’s not going to get hacked, that the device in your house is secure. And then the Internet Security Foundation is actually a European organization whose whole focus is just IoT security. And so if you go to the IoT Security Foundation’s website, you can also see their best practices guidelines. So privacy, now we’re aware of lots and lots of privacy issues. We hear about this a lot. You know, one of the issues is, you know, somebody listening in on my cell phone conversations. But there are things that are actually totally legal and ubiquitous that you may or may not be aware of. This is, I just took a couple of screenshots off of my iPhone of the location tracking data that my iPhone is collecting about me. This is just from, you know, a visit to Burbank and it shows me everywhere I went in Burbank and when I click on one of the locations, it actually brings up another window that shows me when I got there, when I left and how I got there. And all that information is being tracked on my phone. And if you have enabled location services for an application, they have access to that data and many of those companies share that data. So they’re gathering information from your device, they’re aggregating that and often sharing it to people who are aggregating it with other data that they’re collecting about you. So a lot of information is being collected and aggregated and shared about you. We have cameras now everywhere. So cameras are collecting information and people are monitoring those cameras. They had an issue in the UK recently where a school principal was concerned that a family was coming to their school, but they lived outside the district and he couldn’t prove it. So what he tried to do is he followed the mom and she walked home after visiting the school and he followed her on the cameras until he followed to where she lived. And he tried to use that as a way to kick her out of the school, actually ended up coming back to him as a privacy invasion, but he was able to do that using these publicly available cameras. Home control devices, we’ve all heard the stories about how these things are listening all the time and recording information. So there are real privacy concerns about devices that are running inside the house. And then of course the wearables and health monitors, that data is information about your health that is being collected, aggregated, and potentially shared with insurance companies, with companies who make medical devices, with lots and lots of different companies. So when you’re setting up your Internet of Things environment, you need to think about what are the privacy concerns of my customers and how do I protect my customers? And here are some resources on privacy, again, some standards. So ISO has its standards on privacy. The Center for Long-Term Cybersecurity at the University of California at Berkeley actually just did a paper on privacy for the Internet of Things. And then the IEEE has some documentation on privacy for Internet of Things. So the other issue is the volume of data. We’re getting billions and billions and billions of messages from a whole variety of sensors that are hitting our systems. And you can imagine when we start putting out all of these health sensors, the number of messages that you might be getting. I was talking to an insurance company, he told me, he said, well, just think if you get 10 messages per hour to your health monitoring system per person, and you’ve got 10 million subscribers, that’s two and a half billion messages a day.

Now, somehow you’ve got to be able to process that data. So when it’s setting up your Internet of Things environment, you need to be thinking about what am I going to do with all that data? What am I going to do with this data that’s coming in from these sensors? How am I going to analyze it in order to find the insights that I’m looking for? Because the whole reason I’ve got those sensors out there is to find insights. Now, the insurance company told me that there’s a real concern here because if you start monitoring this kind of data, if you’re a healthcare provider and you start monitoring this kind of data, if there’s something in the data that says your patient might have a problem and you miss it, you could be liable because you’re getting the information. So I really need to be paying attention to all of this data that’s coming in. We were working with a trucking company who told us they had put sensors in all their trucks and they were checking things like speed, direction, tire pressure, temperature, engine performance, gas mileage, all the stuff they were collecting about the truck’s performance. They were gathering six terabytes of data per truck per year and they had 1,000 trucks in their fleet. So they were gathering six petabytes of data about their trucks every year. So again, how do you deal with that volume of data? How do you get useful insights out of that volume of data? And this is that IDC chart of the flood of, the oncoming flood of data, so the amount of data that’s coming in. So if you think about the average internet user is using one and a half gigabytes of data per day, which we, you know, that seems like a whole lot. I remember the days when you, you know, you got like two gig in your, in your mobile plan and that was all you had for the month. A smart hospital, they’re saying three terabytes of data a day, an autonomous vehicle, four terabytes, an airplane, 40 terabytes of data per day, and a smart factory, one petabyte of data per day of information that’s being collected from all of these sensors. So a significant amount of data. So there’s an architecture that you set up in order to try to deal with this. And this is sort of the conceptual three level architecture of an IoT environment. So you’ve got the perception layer, that’s the layer of the actual sensors that are out in the field, the things that are collecting data, that’s your, you know, your, your temperature sensors, your fire sensors, your connection sensors, security systems, you know, whatever it is you have out there, the things that are sensing what’s happening. They then route their messages into some network layer that, that is collecting all these messages and sending them out to those people who are interested, those applications that need them. And so it would be at that level where things might be coming out to your IVMI, where you’re, you’re aggregating the messages and then, then sending them to your IVMI for processing. It’s also the layer where you make, you might put in analytics and machine learning algorithms that look at that data so that the system can make decisions without somebody actually looking at the data. So you have AI decision-making where, you know, the health monitoring systems are looking for particular things so that they can send out an alert. So rather than dealing with two and a half billion messages a day, you’re only dealing with the alerts that the system is putting through to say, Hey, here, I’ve identified something that might be a problem. So you’ve got your perception layer of your sensors, the network layer that’s route, that’s gathering and routing the messages and the application layer that’s processing the messages. So a little bit more technically, this is typically how this works. So I’ve got the sensor, and then I’ve got a broker for the messages. And then I have the company or the devices that are consuming the messages. And this is, this is what we call a event-driven pub sub model or publish subscribe model. So something happens, the sensor finds something, it publishes that data to the broker, and then different devices, different applications subscribe to that data. So they say, I want to subscribe to temperature. They will then get that from the broker. So the broker is this MQTT broker. This is just an example of a broker. There are multiple brokers, but this is probably the most ubiquitous one. MQTT is Message Queuing Telemetry Transport. It’s the ISO OASIS standard for IoT brokers. It was actually developed by IBM and some partners to develop, to monitor oil pipelines out, your remote oil pipelines out in the desert. So MQ actually originally was related to IBM’s MQ series product, but now it’s Message Queuing Telemetry Transport. But anyway, it’s the broker that’s collecting those messages and then sending them out to the subscribers. So I’ve got the publisher who’s publishing the data, the broker that’s collecting it, and then the subscribers that are consuming it. The idea is to create an environment where the connectivity is simple. So you don’t have to worry about complex connectivity for collecting the data from all these devices. That the devices become easy to manage. So there’s not stuff that I have to do to try to manage every single one of these thousands or millions of devices that are out in the field. I have an easy way to ingest the information. So I have an easy way to get the information to the right places, and then I can run data analytics so that I can generate things like risk alerts so I can identify when something arises from those sensors that I need to pay attention to. So that’s the idea behind this architecture. So the point is that the sensors have a very small code footprint and potentially low bandwidth so that we’re trying to limit as much as possible how much data has to flow through this system. Okay. So that’s sort of high level what IoT is all about. Some of the concerns around IoT and basic architecture around IoT. I’m going to turn things over to Aaron now and have him give you a little bit of a deeper dive into the actual IoT architecture and how things work.

Aaron? Okay. Great. Thanks, Dan. So give me one second to share my screen, share my presentation. All right. So what we’re going to go through here is from a technical perspective, a deeper technical view of some of the concepts that Dan was just talking about and how these concepts actually affect your applications and the way that you architect them. And so basically what we’re going to do is we’re going to start off with a little bit about IoT architectures and how some of those, again, how some of those concepts that Dan mentioned are going to affect that architecture. We’re going to talk about some of the concerns that you need to look at when you are securing these systems, because that is, of course, a critical concern. We’re going to talk a little bit more about the details of the MQTT protocol and how it works. And then we’re going to tie that all together and the concepts that Dan was mentioning before by looking at a real application. And so this is an application that I built a couple of years ago that we’re going to be looking at here. And so it’s a real MQTT-based IoT application. And then we’re just going to open it up for some questions. So let’s get started. So Dan mentioned some of this before, but from an architecture perspective, when we talk about an IoT application, one of the biggest changes that you’re going to be working with is that you’re connecting to a huge number of small devices in the field. When we talk about something like a Node.js API application, if we’re talking about building a dashboard or something, which is one of the common applications of these web-based technologies, you’re typically talking about a relatively small number of users. And that number of users may be up in the hundreds of thousands for a modestly sized application. And that is a large number of users, but on the scale of IoT applications, it’s miniscule. Again, as Dan mentioned, we’re talking about hundreds of billions of devices by 2025. And so even in an individual application, you can easily end up breaking those hundreds of thousands of numbers and potentially even breaking into the millions in a successful deployment of a significant application. So you need to make sure that your application is capable of handling that kind of load. And again, it’s not just a large amount of data, it is a flood of small bits of data. And there’s a critical distinction there in how you handle it, especially when you’re working on an IBM i. The IBM i in traditional applications and in the database is typically designed to work with a huge data payload and churning through records that are present in large amounts of data. This is different in that, again, the data is extremely granular. You may be talking about a status report from a device, which we’ll actually see later. You may be talking about a status report that is 17 bytes, or eight bytes, or something like that, or potentially even a single bit. You’re talking about very small amounts of data that just come together to make this incredible flood of information. And that also means that we need to make sure that our system is capable of handling this event-driven nature of an IoT system. You’re getting tons of these little pinprick messages coming in. And so you need to be able to react to those. A typical procedural process that we build traditional applications with just won’t work for an application like this. You need something, again, that is reactive, especially because you’re going to be getting lots of different types of messages. Now we at Eradani talk about this a lot when we talk about which technologies you should use for what use cases, which languages. This is one of those instances where I and my team would strongly recommend technology like Node.js if you’re working with something like this. You’re talking about Node.js, the technology, again, that is fully event-based, the language to its core is event-driven and is reactive. And so it’s much easier to write applications like this when you’re working with something like Node.js because it just handles those events very, very well. So beyond that, we’ve got our data. We’ve talked about data. We’ve talked about the event-driven nature. We also need to make sure that we’re capable of handling the inherent unpredictability of the devices and of the network. You have to remember that we’re talking about typically very small devices that are built to be largely a top priority in what I’ve seen is typically to make them cheap rather than reliable. And so what we end up with, you add that to the network, and what we end up with is devices that may or may not be sending responses. They may miss a couple. They’re very unreliable typically in these applications, especially if they’re deployed to remote locations, and you often have a lot of network latency in between the messages. And so we also need to make sure that our application is capable of handling that inherent uncertainty and that it’s not going to break down and that the devices are not going to break down when communication inevitably breaks down because I guarantee you, having worked on a couple of IoT projects throughout my career, I can tell you it will break down eventually and you will need to be able to handle that. And then the last thing that I’ve seen missed in a lot of cases is why it’s bold on my slide here is you have to remember a lot of the concerns come from the fact that these devices are in the field. They are not in your office.

 So what does that mean? When we talk about a typical system architecture, this especially becomes important with security. We have to remember that we don’t have control over the physical device once it’s deployed. If I write an application on my IBM i, that IBM i is sitting in, actually in the case of Eradani, it’s sitting in a locked data center behind wonderful network firewalls, behind locked doors with armed guards patrolling the premises at all times. We know that this system is safe. We know that it’s completely safe and we know that it’s safe from tampering on the physical level. When we talk about an IoT device, you have absolutely no way to guarantee that. You deploy a device and the people who are using it have full access to the hardware that you’re deploying to them. They can crack open the container and just wire into the chip directly. And so because of that, you have to make sure that you’re thinking about it from that perspective and that you’re protecting your system effectively, knowing that you do not, and also being ready for the, again, those uncertainties of the network and updates and changes in your system over time and the evolution of the system, knowing that you, again, cannot access these devices directly. So again, looking at some of these critical technical concerns, we’re going to look at, we want to make sure we’re thinking about how do we secure the servers? How do we secure the devices? How do we manage our communication? What protocols do we use and how do we make sure that our systems are reliable? Looking at that, how do we secure our devices? Again, this is something that I see missed again and again, I’m going to say this a bunch of times as I talk here, because I’ve seen it missed so many times, almost every time in the initial architectures, actually. And I have a note here that says, even your fish tanks. And there’s a story behind that, that is not a project I worked on, but there was a casino, the name was not published, but there was a casino that had a wonderfully secure network and all of their information secured, all of their systems secured, and they got hacked. And 10 gigabytes of data, again, unpublished exactly what it was, but 10 gigabytes of data was stolen by hackers. And the way that they stole it was by breaking into an IoT thermometer that was in a fish tank in the building. That IoT thermometer had network credentials stored on it in clear text, in the memory, so they were able to break into that, break into the fish tank, or into the thermometer, and get the credentials to the network. And from there, they were able to break into the system and steal some data. So even the smallest of the small IoT devices, we need to make sure that we’re securing and we’re watching and thinking about that in our architecture. So one of the nice things, when we talk about server security, right, so I’m talking about your IBM i that’s processing the data, I’m talking about your Node.js application, your Python application, Java, whatever you have listening on the back end for those IoT messages. Luckily, that can typically be added as a module to your existing applications, especially if you’re working with an open source language, I’m pretty sure every single one of them has an IoT module out there. And so that means that you can use here, this is the easy part, in here, you can use the same security methods as your other web applications. So for example, in our applications, we’re using all token based authentication with JSON web tokens. We make sure that we’re encrypting all of the data, right, I mean, these are the same things that you would worry about with any other web API application. And we make sure that we’re working, that we have tightly defined user permission structures. That’s another important point when we’re talking about an architecture. And more than anything else, especially if you’re building this application directly on IBM i, in the open source environment, make use of the IBM i security, right? We have here a platform that has probably the most advanced security system of any platform, at least that I’m aware of. You know, it’d be a shame to build an application and not take advantage of that, right? So just remember that when you’re talking about server security, a lot of this stuff is the same concerns that go into another application. And there isn’t that much to look at outside of that. The one place where the server security is different is where it touches the device. And that is most notably in the encryption, right? 

You know, if we’re talking about, when we talk about encryption, there’s a couple of key principles that we look at. But two that I’m going to point out here are the authenticity of data and the confidentiality of data, right? Confidentiality of data refers to making sure nobody else can decrypt our messages, nobody else can read the data that we’re sending. And the authenticity or the integrity of the data ensures that the data we are sending is real, is coming from an authorized source, hasn’t been tampered with. And so in different applications, you’re going to be looking at different requirements. In the application that I’m going to walk through later in this presentation, we actually didn’t have to worry so much about confidentiality. We were sending simple status reports from the device. And we didn’t really have a requirement to make sure that those could not be read. We were much more concerned about malicious users coming in and attempting to falsify information going to or from a device, because these devices were capable of controlling machinery. And we needed to make sure that no matter what happened, we could trust the messages that were coming back and forth, and again, less concerned about whether or not someone could read them. And the reason we had to draw a distinction there, I mean, naturally, normally you’d want to have both, but we had to draw a distinction because of, actually Dan mentioned this earlier, that we were working initially on a chip with 16K of space on it, and that includes the actual programs as well as all of its working memory. And so we, and encryption obviously is one of the most computationally expensive operations you can do. And so we had to be very, very careful with how much space we were using. And so it became clear to us, and this is the kind of thing that you do when you’re working in a tightly constrained IoT environment. It became clear that if we sacrifice that confidentiality, which wasn’t really a requirement anyway and just focused on integrity and authenticity of our data, we would be able to save a significant amount of space that could keep us from, at least in that case, from having to upgrade our chip and I believe double the cost of the devices. So just pointing out here that there are hardware concerns here as well that need to be taken into account when you are looking at how you’re going to secure these devices. But again, we need to make sure that those don’t outweigh the actual security of the device. And unfortunately, they very often do in my experience. Now when we look at the device, the security on the device, again, we talked a little bit about this with the encryption, but the biggest, the number one piece of advice that I can give you about this that nobody ever follows for some reason, but it is really important is to treat your IoT devices like any other system. I see developers all the time, and especially when I was working in a particular IoT company where I was 100% dedicated to IoT projects, that there was a very different air around the IoT devices versus the servers. The servers were tightly controlled, the data was very well secure, and then the devices were kind of, eh, whatever we can do. And it’s very important to not do that because when you start going down that route, what you end up with is a device that, you end up with a vulnerable fish tank thermometer. You end up with, you would never store network credentials in clear text on your IVMI, so don’t do it on your IoT device. And the same goes for certificates, encryption keys, anything else sensitive that’s on the device, treat it like it’s your IVMI, treat it like it’s your core system, and a lot of these security concerns will be automatic because you’re probably already using them elsewhere. Again, I already talked about making sure we have secure authentication, we have encryption, and if we do have to have keys on the device, making sure that those keys are stored securely on a hardware level as well as a software level. And again, I told you I was going to say this a bunch of times, but remember, you do not have control over the device in the field, which means, again, if you have an encryption key in clear text in the memory of the device, somebody can crack open the case and they can get onto your device, right, so they can actually physically access the device and they can physically access its memory, and if they know where to find your data, they can actually get it without having any kind of remote access to the device, and you will have no idea because chances are this device is sitting out in a field somewhere, in a literal field in some cases, and you’re not going to be able to verify that, so make sure you’re watching that. And then just one last note, remember that you’re going to have to work around hardware limitations, especially when you’re trying to manage the cost of the device like we were. In our project, eventually, we did have to upgrade to the 32K chip, and it doubled the cost of the chip, unfortunately. Now, I mean, you know, that was from 50 cents to a dollar, I think, but when you’re talking about a million IoT devices, you know, that starts to mount.

So, shifting off of the security topic here, we’re going to talk about communication for a minute. Dan mentioned earlier MQTT, that is, it’s not the only way that you can have an IoT device talk to your central systems or to other IoT devices, but it is the most popular, as well as its variants, I’ll briefly touch on MQTT-SN in a minute, there’s a couple of variants here, but it is the most popular, and so, especially if you’re working in the open source world, I highly recommend it, I’ve worked with it many times and it’s never let me down, so you can trust it. Again, remember, when we talk about communication, we’re talking about large numbers of small messages. Now, this creates a critical difference in the way our communication works, in that we have to be extremely careful about protocol overhead, and what does that mean? When we’re talking about sending a message via HTTP, or actually, better yet, HTTPS, we’re talking about encrypted communication over the HTTP protocol, you end up with a lot of information that goes in your message for routing, for where does it need to be delivered, what kind of data’s included, header information in the package, in your data payload, all of that stuff is required by the protocol to effectively deliver your message, but none of it is actually relevant to the actual message you’re sending, and so you have to send it on every message that you send, and so what ends up happening is, actually, for example, in the last IoT project that I was working on before I came to Eradani, we had relatively large devices, and we were originally setting up the communication over HTTP, and we found that a status report from the device that was supposed to be sent every minute was taking, I believe, if I’m remembering the numbers correctly, 586 bytes to get our message transmitted via HTTP. We switched over to MQTT and redid our communication protocol, and we got that down, I believe, to 17. Actually, we went 586 bytes to 17 bytes on a status update, and we were paying for cell connectivity for each device, and we were working with Verizon to get data plans for each device, and so that was a massive, massive cost saver on the project, just switching protocols to a much lighter-weight protocol like MQTT. Actually, in that case, it brought us down from, I believe, $3 a month per device down to one, which, again, we’re talking about a million devices, that’s $2 million a month. If we got to that level of deployment, we’d be looking at $2 million a month that would be saved just by switching to MQTT from the HTTP original architecture, so these are serious concerns. These are not little minor things to look at. Now, MQTT, and I’m just going to go through this quickly, MQTT is a publish-subscribe-based protocol. That means that a particular client in the system publishes a message on a topic, so what they do is they send their message, they provide a topic for their message, they send it to a central broker, or a distributed system, and that broker system then distributes it to all of the subscribers to that message. So, for example, if I have a topic, temperature updates, and I am firing off a message with a temperature update every minute, I can have another client that says, all right, I want to subscribe to temperature updates, and it will then immediately start receiving those updates from the central broker system. So it’s not a traditional client-server kind of architecture that you see with something like HTTP. It’s a different type of protocol, so just be aware of that. Again, I mentioned MQTT is extremely lightweight, so if you’re working with small devices or limited data plans, it’s very, very useful. It was designed for unreliable networks with high latency, so the protocol itself built into its DNA is unreliable networks. The project it was developed on was for monitoring oil pipelines off in the wilderness with satellite uplinks, and so it needed to handle extremely unreliable conditions, and so that’s what it was designed to do. Now, I mentioned earlier the MQTT broker. When we talk about that central broker, there’s a lot of products that can manage that communication for you. Just to name a couple, pretty much anything that has MQ on the end is going to have this. We’ve got ActiveMQ, IBM MQ, Hive MQ, and then there’s also the cloud systems. Every major cloud platform supports a distributed MQTT and scalable MQTT broker system. Again, I’d highly recommend those if you’re expecting your traffic to spike because you can auto-scale your system’s capacity based on your needs, which may spike very rapidly. And again, that’s every major cloud provider I have in that second bullet has that. And then there’s also when you’re developing and when you’re creating listeners and clients for the MQTT messages, there are lots of open-source tools available as well. Mosquito is a great open-source system that you can get that provides command-line tools and interfaces that you can use to send and receive MQTT messages. It’s especially useful when you’re getting up and running developing. And then there’s also various open-source modules for, again, pretty much every open-source language that will handle MQTT connections for you. For example, you’ve got things like Mosca.js and MQ.js in the JavaScript world that can handle those functions for you and provide nice interfaces for it. So it’s a very easy system to implement. Now I mentioned a bit before about this, but I’m just going to, I just have a slide here about it that I’m going to walk through, is the MQTT message structure. When we send an MQTT message, there’s only a couple of components. Number one is we have a topic, so we are sending messages on topics, so I say, again, I had an example earlier. I said, I’ve got a temperature updates topic and I’m firing messages onto that topic. Many, many devices can be publishing to that topic. The broker will then forward all of their messages that are on that topic onto the client devices that subscribe to that particular topic. And just as a quick look at the topics, topics are defined as text. What we do is we do flash segmented topics so that I can have a tree of, a tree topic structure. So in this case, you can see I have a four level topic structure for sending my messages. Just a little quick thing, there are some cool syntax things you can do here with topics when you’re subscribing, which I’ll show you in a bit. For example, we have the plus that we can put in the slash, basically is a wildcard. It means anything at this layer.

So if we have, for example, you know, my application temperature updates, my application humidity updates, my application time updates, you could do my application plus updates. And what you’ll end up with is getting all three of those just to make it easier for you to subscribe to those. And then we also have the hash symbol, which basically says anything that begins with this topic, I want everything after that. That’s what I want to subscribe to. So we have a string topic and that’s actually often where a lot of the data is because it’s text. So again, you’re going to want to keep those topics simple if you’re trying to reduce your data. For example, in that application I was talking about earlier, we had the intense data requirements. We had single letter topics just so that we could keep it as minimal as possible in the data we were sending. And then we had a mapping module in our code that made them more human readable once they were off the network. So then beyond that, we have a binary message and this is also very different from something like HTTP, unless you’re doing HTTP2, which we’re sending our messages as we send data directly as binary rather than text. That saves us some data again. One important thing to mention about MQTT messages is quality of service. Quality of service is a critical component of reliability in an IoT application, in an MQTT based application. Basically what we can do is when we configure our MQTT clients and brokers, we can decide how reliable we need the message to be. And what that gives us is a trade-off between reliability and the data that we’re sending. So if I say, so quality of service is defined as a number zero through two, basically if I say quality of service zero on my message, that’s interpreted as what we like to call a fire and forget. Basically what happens is your system will send the message and if it’s received, great. If not, great. It does not care. It will not notify you. It itself will not even know. So it just fires off those messages. And that’s what’s able to send, for example, a status update in 17 bytes. But you also have no guarantee that it’s actually going to make it. Quality of service one says our message is going to be received at least once. What it’s saying is I’m going to send the message and I will, when it is received, I’ll receive, I’m going to make sure that it actually gets to the broker. But it might be sent more than once. It might be routed weirdly and it might show up three hours later. But it will be received at least once. And then quality of service two takes the most data overhead. But it says it will be received, your message will be received and confirmed exactly once. You will be notified when your message is received. And so if you have critical messages, quality of service two, make sure to configure that because a lot of clients default to one or zero. And again, that’s going to require some more protocol overhead to do those higher quality of service levels. So again, I mentioned we have MQTT-SN is another protocol. Because we’re running low on time, I’m going to just leave that as a term for you to look up, MQTT-SN. The last thing I want to mention about this is you can set up an MQTT, what’s called an LWT message, the last will and testament. Basically what that does is says the device, when it connects the broker, it can register that if it suddenly and ungracefully disconnects for any reason and the broker decides that it’s dead, the broker can send out a notification message that’s specified by the device to make sure that that gets successfully to everybody that needs to hear it. And then the last thing I want to mention is that when you’re talking, we’re working with IBM i applications, so we’re going to need to make sure that our data can get from the devices to the IBM i. This is something that we at Eradani have done a bunch of webinars on, and IBM has some great tools for working with this.

This is another case where I would strongly recommend working with an open source language. Those languages have connectors and toolkits that can get you direct connections to DD2 or into your RPG programs. That’s also something that we work with a lot at Eradani is helping people set that up. So that’s one thing that you can do pretty easily with these systems. And then one last time, I’m just going to say, remember you don’t have physical control over your device. Again, I cannot stress enough. Maybe I have, maybe I’ve stressed it too much, but in my experience, I cannot stress enough how important this is. So that’s it for my speech here, for my monologue. Now what I’m going to do is I’m going to show you a quick sample application. We’re going to show you some Node.js code from an application that I wrote a while ago that actually does this. And this was a configurable IoT sensor project. Basically the sensor would go out into the field and send status updates to the central system and also receive commands issued by web app users. And this was a Node.js and Node.js backend with an Angular web interface front end using the Moska MQTT broker system. And again, this system had extremely tight budget requirements. So I’m just going to hop over to here. When we look at a Node.js based IoT system, the code is actually pretty simple. Basically what we do is we pull in a module, right? This is something that you’ll see a lot in open source systems. We basically just come in here and we import our, up here we import our module, this const Moska, require Moska. What we’re doing is we’re importing the downloaded module here that we got from the central Node package registry. Then we come down here and basically what we do is we just say, all right, initialize the server and that module will handle the entire thing for us. And what that does is it creates a local broker on this Node.js application. Again for high performance systems that are going to have lots of devices, I would strongly recommend that you look at a distributed broker system like one of the cloud-based offerings or one of the MQ products. Those are going to be great tools for you. But basically we just have some simple function calls in here. So if I come in here, I’m going to scroll down a little bit, you can see that I have these handlers in my JavaScript and I’m just going to talk about these a bit. I say on an event, I want you to do this, right? So I set up my server so that it’s listening for events and again, that gets back to that event-based nature of JavaScript. I say when I get a message published or when a client is subscribed, I want you to do this. And then what I do is I say down here, I can say I want to subscribe to a topic and you can see I’ve got this C plus E. Again, we have those single letter topics to keep the length small. And so what I’ve got is what I’m saying is I want to subscribe to every topic that is C slash something slash E. And if I remember correctly, that was the command. I don’t remember what that topic was, but I remember we had a mapping. Anyway. Oh yeah, device echo. There we go. It’s right there in the comment. Okay. And then what I’m doing is I’m saying when I get a message on there, I want you to run this code using that message as the input. So again, these are pretty simple systems to set up. 

Unfortunately, we’re just about out of time. So I just wanted to point out this code and just show that it is very simple to do this kind of thing. I’m going to show you one last thing. And that is on here. If you come to this URL, this npmjs.com slash package slash MQTT, you can also do this by Googling MQTT NPM, again, MQTT NPM. You’ll get over here. They have example code that you can use with this module. You can take this code, plug it into Node.js, and it will, presuming you’ve installed the MQTT module, and it will give you some test capabilities here. For example, you can see they are connecting and reading the connect event, and then reading subscription events and publishing messages. So you see we’ve got a publish, we’ve got a topic, and our message. So I hope that was informative. I know it was fast, but we are at the end of our block, I believe. And so I’m going to pass things back to Dan to wrap this up real quick. Dan? Great. Thanks, Aaron. Yes, I know that was just like we were talking about. That was a flood of data. I know there was a whole lot of information there. And so if you have questions about this, feel free to reach out to us at Eradani. We are happy to talk to you about these Internet of Things applications and to help you get set up. I didn’t see any questions in the question box, but Margaret, I’ll just turn it back over to you. Are there any questions or anything else we should address? No, actually, there aren’t any questions right now, but thanks for letting everyone know that they can just reach out to you directly. So thank you so much. This was really a fantastic presentation, really packed with great information. Thank you. Great. Thank you. Thanks, everybody. Have a great day.