Understanding your sensors: Choosing a protocol.
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Dyrkorn, Kristoffer
The Norwegian Public Roads Administration is using the protocol OPC-UA in an IoT project for gathering and analysis of road traffic data. OPC-UA, while not very widely used, fits our needs very well, and has some valuable properties that might fit other IoT projects in other domains. We have been using the protocol for more than 2 years in our project. In this talk, a short introduction to the protocol and its abilities will be given, along with a feature comparison to alternative protocols. Then, a walkthrough of the experiences we have had during the project - from initial design concerns behind the protocol choice, to a wide selection of surprises and obstacles when starting up - and finally how we reached an end state of a stable production system. The presentation will end with a summary of hindsights and some suggestions for selection criteria when considering protocols in IoT projects.
 Welcome to my presentation. I will be talking about how to understand your sensors, integrating with them, choosing the right protocol in terms of an IoT application. The background that I have in this context is that I have been working on a project that does integrate an application with sensors or at least measurement devices as we call them, which in turn are connected to a typical sensor. The project measures traffic data, vehicle traffic data. It's a road analysis project. There's one of the previous project members in the audience today, so if there are any difficult questions, I will route them to this person. No, I will do that. Okay, talking to your sensors and understanding your sensors, that's the context today. What you actually do when you connect to a sensor is that you are integrating. A schematic display of integration can be seen upon to be very, very simple, just like this, but integration in practice can be a lot more complicated. This is one of the reasons I'm here to talk about this today. Whenever you talk, have two components that talk together, there are a lot of considerations that you have to take. Some of them are obvious from the beginning, some of them appear in the way. Details of integrations, you can really quickly end up with a long list, which in turn decides which protocol you should be using. I will be discussing a few of these criterions in this talk, but I will also explain some of the most typical protocols that you can choose among. To begin with, should you push from A to B or pull from B to A? Is this synchronous asynchronous peer-to-peer or through a broker through a middleman? Do you need to validate data before sending them or before receiving them? What if A or B crashes? Should you resend things? Should you ignore what happens? What is your data format? Which protocol are you using for the data? How do you encode them? What about authentication? What about performance? What about encryption? What about scalability? Et cetera, et cetera, et cetera. These criteria are not necessarily relevant in every case, but they can be relevant for you. It depends on the application you are building. It depends on your situation. They can in turn introduce a lot of complexity. There are, of course, a lot more points in such a list than what I have included here, but these are some that appear in my mind at least. As you can see, the sequence is not entirely random. They are sorted, but that's not the point here. But this influences what type of integration protocol you should be using. Among other things, these are relevant. So what is the situation that I have experience in terms of doing these kinds of integrations? Well, the project consists of a network of sensors. Here is a very simplified map of the sensors. These are measurement points, which we call them, which are installed along the roads in Norway. The project is underway, meaning we are not into full production yet, but when we are, there will be something like 4,000 or 5,000 devices in a roadside installation that collects data from each and every vehicle that passes by. We, meaning the project that I am a part of, we collect the information and store them for analysis. These devices are not low-power devices. They are not resource constrained. They have power. They have 3G network available. So this is not a constrained environment in terms of how much memory you have, how much CPU you have, how much bandwidth you have. The bandwidth is sometimes a bit limited, but it's usually quite okay. So we can look upon this as an industrial IoT application. It's not a consumer IoT application. And this, of course, introduces some other constraints than other applications. So a little bit more detail. What we are doing, we are measuring and storing road traffic information. What about the vehicles that pass by? Was it a car? Was it a motorcycle? Was it a bus? Was it a lorry? Et cetera, et cetera. So record the time stamp, the speed, vehicle length, vehicle type, et cetera. All of this information is non-identifying. We don't have any information about the driver or the license plates or anything like that. No photos are taken here. We are storing each and every event. So for each, every event that is registered, the event itself is sent to the application that we have. And here we have an installation. The field engineer here is very proud. He shows us the new cabinet with the new installation. This is just besides the opera here in Oslo. It was a sunny day and everything was just nice. It even worked when he installed it. So everybody was happy. And this is how it looks like. So the blue box there inside the cabinet, that's the box that is responsible for connecting to the roadside sensor, which is actually just cables in the pavement. So whenever you drive by and see squares in asphalt just like this, this means that somebody has installed these loops, which is essentially a cable, which measures the flux or the magnetism of the vehicles that pass by. And through that can decide which type of vehicle that passed by and then send that information to us. So the signal analysis is done inside these blue boxes. You can see one here if I can find my mouse pointer. Yeah, here it is. It's a bit small, but it's a quite powerful device. It doesn't have advanced signal analysis. And the project itself has been in production for more than two years. So we have some practical experiences about how these things work. A little bit more schematic overview. The sensors, the loops, they are underneath the road pavement. And so whenever a vehicle passes by, we can register this. And there's a cable that goes to what we call the data logger. That was the blue box. This is an embedded Linux device, which does the signal analysis. These loggers are connected into a 3G modem, which then transmits each and every event to the application that we are building. And what sometimes happens is whenever there's a bus driving by, for instance, when a lot of people send SMS or something like that, the connection might go down because the 3G connection here does not have high priority. So robustness in terms of network outage is extremely important for us. We need to get hold of the information about the cars that pass by, even though the network can be down at times. So on the receiving end, the system we have built consists basically of an application with some storage underneath, a storage system for very quick saving of data and reading of data and analysis. And we have the option to do real-time use of traffic that passes by or ad hoc reports, meaning aggregates of information about the cars, about the speeds, about the types of vehicles that pass by at given times of the day, et cetera. Traffic patterns, more or less. And we have an installation component and an administration component to look at the insides of the application. And the delay from a vehicle passes by until we can see it in our real-time view component is something like one or two seconds. We have not optimized this for low latency, but the latency still is quite low. And we are happy with that because we can look upon the system and see how is the traffic now. That can be interesting to be able to, not at least in terms of doing the quality assurance of an installation. So the field engineer does that as the last step of an installation to ensure that whatever the system records is actually what's taking place on the road behind him or her. So the question is what protocol should we be using for connecting our application to this environment? When looking at the IoT most used protocols, there are some candidates that reappear. And I've been looking at them very briefly. One of them is the XMPP protocol. It has a rather long history. It started being used more or less as a chat protocol, actually, from Jabber. If anybody has been using Jabber, this is what's actually taking place underneath. It is XML-based. So whenever you work with this, you need to be able to work or love XML. Some do, some don't. But it's part of this protocol. It's very much XML-based, which means you do text transfer. It also means it's not very bandwidth efficient. But it is distributed. It means you can relay messages from one XMPP server to another, just like email. So you can forward and relay information across various servers from one end user to a different end user. It is very distributed in its architecture. It's extensible. It has lots of extra add-ons to it, and it's open. There are a lot of open implementations of this protocol. It supports encryption, just like HTTPS in the normal Internet web sense, but not end-to-end. So whenever a message is relayed, it can be read by the intermediate servers. You can also use different transfer protocols underneath it, meaning it's more or less like XML and some more parts, and then HTTP, for instance, underneath. The issue with XMPP is the robustness of it and the quality of service that you can expect from it. It is more or less a fire and forget protocol. You don't have any assurance of what's happening after a message has been sent. Will it be received by a client or not? As mentioned, it's not very hand-bandwidth efficient, and binary data must be encoded, the typical base 64 encoding, et cetera. Some of these issues might be addressed by the extensions to this protocol, but you might have some trouble finding the right implementation for them for every case that you might end up with. But it is a candidate. Have a look at these, what you call it, the standards, the XMP323 and 325, which defines control of sensors, control of the endpoints, and also the messaging in itself. They can be relevant to have a look at in terms of the functionality of this protocol, what it offers in some of the limitations might appear from that. This is one to consider, definitely. A different one, a little bit of a different end of the spectrum is cope. It's defined by the Internet engineering task force. This is more for the low end or low resource type of applications or sensors that you might have. It exposes a REST-like API, so reasonably high level, but it still uses UDP as the transport layer, so it is not bound to TCP, which means that it has a different resolution in terms of how the message is passed and what you actually need underneath to be able to pass messages. It is designed for a one to one type of situation where you have one client and one server. It also has encryption support but not TLS, but something at the lower level, like the UDP lever. It also has support for payloads, content negotiation, et cetera. It's a little bit more flexible and you can adjust how data should be interpreted under way. It also has a very limited but might be reasonable quality of service functionality. Also, you have event listeners, so you can get a message whenever a sensor has a change that it wants to publish. It is also very bandwidth efficient. Publish andcribe support is a little bit limited, so be aware of that. It's not through message queuing as we might expect it. You don't have any topics that multiple sensors can connect to and send messages to. It's a one to one protocol, mainly. But consider that one as well. It's widely used. Different one, MQTT also appears a lot. This is actually also quite an old protocol. I think it was partly made by IBM in its time, something around 1999, I believe, but it has since been open source and it's really available and simple to find implementations for it. In this case, the sensor is a client. This is the opposite of the previous protocols. The previous ones, the sensor is the server. Here, the sensor is a client and it connects to an MQTT broker. This is integration through a broker. It's also designed for low resource usage and it uses TCP for transport. It has various quality of service support levels and it's quite robust and it supports buffering or messages whenever you have a network outage. Also, encryption and authentication is available. The interesting thing is that it promises exactly one delivery of messages. According to computer science theory, this is actually not possible. You cannot have exactly one guarantee in practice. You might have it in theory in terms of how the messages are transferred, but at the implication level, you cannot have one, exactly one delivery of a message. It's an interesting problem to consider. But if you are unsure, please have a look at the Internet. Do some searching about exactly one messaging. It might get quite theoretically detailed, but it's an interesting question. I think everybody, when you see exactly one's delivery, you should be a bit skeptical. MQTT relies on an always on connection, which might or might not fit your needs. If you have a low resource usage need, then having always a connection up is not what you look for. You want to then shut down the connection and then do reconnect at given times in order to save power, for instance, if you have a battery-powered device. Now a little bit about the protocol that we are using. It's OPC UA. I might be a bit biased here, but okay, I'm trying to do a reasonably objective comparison here. This one has it roots in industrial robot control. So it's built for a little bit of different context than the other protocols, perhaps. In this case, the answer is a server. A server here defines or has inside three structure of nodes, meaning it is a data model that describes the server itself. What you do when you connect to a server is that you can ask for these three structure and then read out information about the capabilities of the server of the device itself. It's quite flexible and each node in these three structure represents either attributes. We can just read and pull or events, meaning whenever something changed, you get a push message out of the server or you even have methods. So you can call a remote method on the device if you want to. This can be very, very powerful. I will return to that later. Also, for each node, there is values that you can read and each value has a rich metadata set, meaning you can get information about when the value was set, what the previous value was, for instance, various things that might be very relevant for your application, depending on what you are building, of course. It is TCP based, so this is internet friendly in this sense, and data are transfer binary, reasonable bandwidth efficient way of sending the data. It also has great features for security, authentication of both client and server, and also encryption and the authentication can be done through certificates. So you have quite a strong knowledge of what is connecting to what whenever you do an integration using OPC if you want to. Also, and this is very important in our case, you can transfer real-time data using this, or you can also ask for historical data in this protocol. And this goes back to then the situation we have where we have events that are taking place, cars that drive by a measurement point, and for instance, then we have a network outage, and 1,000 cars pass by, and one hour later when the network is up again, we want to ask how many cars have passed by in the meantime. So you would like to ask for data that has taken place earlier. And this is very well made in this protocol. It has support for batching the, if you ask for too large interval and too many messages, the device itself can batch the responses automatically, and this is handled by the protocol. It is also very robust. It has a buffering of messages, so whenever a network goes down, both the client and the server will know it and act accordingly. So it is very much a transparent protocol in terms of whatever happens when the network is gone. It is large. It contains a lot of functionality which you might or might not need. At times it is complex and a bit non-intuitive. It can be actually too flexible as well. There are various ways that you have to implement this protocol for your specific need if you have a specific device. So you need to interpret how the device actually works and then from that expose this through the protocol and then let clients connect to this properly. So it might be a bit of knowledge that you have to build in order to use this protocol correctly. But that's, in our case, that's okay. We have had our experiences and our issues. I'll return to that. But for our part, it now works and it's stable and it does its job. So what should you select such a protocol upon? So more criteria which is not related to integration itself. You should decide at which level should you rely on a given network infrastructure functionality. It's building upon UDP, the right thing is building upon TCP, the right thing is building upon HTTP, the right thing. How does your network look like? Would you end up having to open firewalls or doing nothing, et cetera? The devices you have, how much resources do they have? How much RAM do you have? How much CPU do they have? How much power do they draw? The protocols can have an influence on the resources they actually use. And also robustness, of course. What happens when a network goes down and comes up again, et cetera. And also message flow. Is this a one-to-one protocol or is it publishing to the whole world, et cetera? In our case, bidirectional information transfer is very, very important. I'll get back to that also. Scalability, according to the number of messages that have to be transferred or the number of sensors that you have installed in your network, is also important. And also the various implementations that are available. Is this a vendor-neutral implementation, a vendor-neutral protocol? How open is it? Is it open source? Can it be freely used inside your application? What are the license conditions, et cetera? And also the tool sets. You should never forget that you have debugging tools and perhaps also tools that are not from the vendor that are giving you this package, the SDK or the implementation. So you can find out if the vendor has done some vendor-specific tricks that can be really hard to debug if there are some internal things that you cannot look at because they are hidden by the vendor. So the main criteria that we ended up with choosing OPC UA was the robustness part of this, the security, the option that you have to have certificates on both clients and server. And also the ability to read historical data. We can ask the devices for old information. So each device has a buffer, which is really large, actually, which stores each and every vehicle that has passed by. So the number of events that they store, I think it's something like one million events, actually. So whenever there's a road traffic installation which has a lot of traffic, I think the amount of time data should be available is something like three months in hindsight. So we can survive a network outage of nearly three months, actually. The feature set in OPC UA is quite rich. You have the option to remote call a procedure which the device itself exposes. We are using this for other things, firmer upgrades. And this is quite interesting. Whenever we discuss Internet of Information, I'm sorry, Internet of Things applications, security very often appears. And it's the so-called Internet of Insecure things that sometimes is said. We are using this to remote call a procedure on the device that lets the device download a firmer upgrade, a firmer image. So we can tell each and every device you should upgrade yourself now. We have the firmer images stored inside the application. So we ask the device, download this image from our application and install it on yourself. And using this, we can remote upgrade any device that we have connected to our application. This makes maintenance really easy and also patching security errors or bugs or whatever, really, really easy. It has been a little bit bumpy road together, but the ability to do this is very important. You can, of course, do this as long as you have a bidirectional message transfer. You can craft a specific message to a device which should then be interpreted as do install a new firmer upgrade. So the point in itself might not be the OPCU protocol, but to have a bidirectional connection. Because then you can trigger upgrades on your sensors. And I think that is a really, really, really important feature to have. So whenever you're considering a protocol, do you consider security updates as part of this and remote administration? Also, after some testing, whenever the protocols were considered, there were found that there existed high quality implementations of the protocol. The protocol itself is theory, but implementations are practice. And as we know, these can be two different things. So there was one implementation that was chosen for the product and we have been using that. And it has been the right choice for us. We have had very, very few issues with the library we are using, which is a Java based commercial library that does OPCU. So here the picture besides this is from a test lab. It's at Krett. It's a little bit south of Tronia. And here there are two of these devices that have been used for testing. This one is here. Interesting enough, industrial design is not always very modern. And this one here is also being used for testing. This is a bit old picture. So this box is no longer used in its original version. But the internals of it has been upgraded. So it's still in use, actually. So these two are different devices that have are used in the field. And so this is how it can look like in a testing lab. Some of the implementations that you can look at, if you're interested in looking at OPCU further, the Java one we are using is from a Finnish company, Prusys. Here it is. Yes. The license is commercial, but I would like to add to that that it's a reasonable license. Depends on the definition of reasonable, but it's not extremely expensive. It's flexible, in my point of view. You don't pay per installation. You pay per developer. And that's reasonable. In my opinion. There are also some open implementations popping up. We have not tested this. We cannot say that this is a good implementation or this is a bad implementation, but they should be considered. If you are curious and if you're interested in looking at this OPCU protocol..NET implementation, this is open source, MIT license. We have some experience with that from previous summer. We also did a little bit of patching to it. It lacked the event, functionality of the OPCU protocol. So this was added by someone in our project. But it's a fairly good implementation. It has lots of unit tests in it. So this is one to consider if your environment should be or is JavaScript based. In practice, node if you're using node. C libraries are also available and also quite good one in Python. So depending on your environment and your application architecture, there are some options for this protocol. There are also some very, very resource optimized implementations that you can run on microcontrollers et cetera. I think OPCU is server can be implemented running on something like 10 gigabytes of RAM. Something like that. At extreme end. So theory and practice. The protocol was chosen. The devices were bought and we started integrating them. What happened? Well, there are some ways to interpret the protocol which can differ from one hardware vendor to a different hardware vendor and also in terms of how the software we were using interpret the protocol. So especially handshakes when you establish a connection and also the reconnect protocol. We had some problems with that in order to make that happen correctly. So we used wire shark to look at what happened and from that learned how the response was and how it should be and what the request was and what the request should be. So wire shark supports OPCU quite well. You can use that for debugging and see what actually is going on. And that is a very good thing to do. Interesting thing. Some response times were longer than the timeouts. So you would never get an answer. That's not good. So theory and practice. If you were asked for more data then the device could return in the expected amount of time. So okay, you have to adjust the timeouts. These timeouts were not on our side. They were on the device vendor side. So we have not control over these timeouts. And also in this case, the device itself is a server. So when you connect to the server from multiple clients, you expect that messages that are published should be received by all the clients. What we experienced is that in the beginning when we connected two clients to the same box, the responses were actually around Robin. So you didn't get a full view of what was happening. And that was not expected. When we publish, you publish to all, not around Robin. So it was a little bit of discussion and then they fixed that. I will not mention names here just to be precise. These things happen no matter what the vendor name is. At one given time, we wanted to test how you can read real-time events, the passing of vehicles happening right now, together with history reads, meaning from previous hour or yesterday or something. And it turned out you can get one of those and not both. And we were not happy with that because we want to do both at the same time. That's very important for us. And then the firmer upgrades. A specific requirement was set that you should upgrade a box in one go. It should be an atomic event. And this was a bit interestingly interpreted to be the option that you can download three firmers instead of one. And then these three ones should be then upgraded in series. And that was not what we said and not what we meant, neither of those. But it was what happened and we found out that a little bit late. So this is now working on as we speak. Also the implementation was a bit incorrect here and there, including in our library to a small degree. But apart from that, we have been very satisfied with the library. And also, whenever you do a specification of something, there's always something that can be interpreted differently than actually what you meant. It is what we said, but it was not what we meant. To mitigate this, there are some things that you can do. I will return to that. And no matter how you specify things and you test things, there will always be new things that you find out under way whenever you test things. So testing, testing, testing, testing is needed. There are so many practical considerations. Whenever you're dealing with physical devices, there's so many things can happen that you cannot upfront find out all of them, what they are and no upfront what they should be or know what the effects are either directly or two weeks later. So you have to actually experience things in practice. So a little bit of summary. What are the main experiences? You should consider the whole stack whenever you look at a protocol. You should look at the network underneath. You should look at what the sensor itself is capable of. You should look at what integration needs is, what should be in a protocol and what should be in your application? What logic should you rely on is handled by the protocol? What logic should you rely on yourself in terms of what the application actually contains of logic? You should do the theoretical evaluation. Have a look at the Internet. What have other projects done? Ask and connect with people. Read about other one's experiences. And you have to do field testing. Their experiences might not be the same as yours. The actual implementation you are building might be quite different in ways that are hidden before you test them. One experience I would like to emphasis on is that you should create a compatibility kit. Something like a test implementation that is an actual small implementation of a device, either a client or a server. So the opposite connection point can connect you. So you have in practice a test that can be run. So you can say to a vendor, okay, if your box connects to this code and these and these and these operations perform well, then you are passing the test and then we can integrate with you. It should be part of the specification to hand out such an implementation. Because then you know in practice what actually the interpretation of a given protocol or a given set of logic on rules is. And then that can expose a lot of details that would otherwise be left. Of course, the question then is what should the scope of such a kit be? But at least doing it will help, in my opinion. We are also doing gradual deployments. This is very important, I think, for being able to adjust the course in a way. During the first year, I think we deployed something like 100 devices. We learned a lot from that. Now we are at around 600 devices and we have still some things to learn. But what we have done between each batch of installation is to adjust the requirements. So each batch was a separate buying process, which means you can adjust the requirements for each buying process. So there's gradual deployment going on, meaning that you do not buy all the devices at once. So whenever you see there is a misinterpretation in the communication or in the specification or something is not the way you wanted it to be, you can adjust before buying the new batch. So you can adjust as you go. And this is a typical engineering principle, I guess, to measure, evaluate and adjust. But also do that whenever you have a project in this sense. Because there are so many things you cannot explicitly define upfront. So you have to be able to set up your project so they can do things gradually. And gradual deployments and also compatibility toolkits, that might be the main and most important experiences that we have had that I would like to share with you. Any questions? Yes? The question was how the network is whenever we are where we do these connections. It is a separate network. It is internet, but it is separated from the rest of the world, so to say. So it can be considered a VPN. Am I correct? Yes? Yes? Okay. Since I mentioned wire shark, why did I mention that or how were we able to do this debugging using wire shark? Was that the context? Okay. At that moment we didn't use the encryption code. It can be specified whenever you start a server or a client. Actually, then the server defines what is happening. No. But in this sense, we could imagine somebody opening these cabinets and installing their own devices. If they really would like to, I don't know why, but it could be done. In this sense, then you can have a certificate on each box, which is verified in our application. Is this a logic box? Should we get data from it or not? But when doing debugging, you need to lose the encryption. Yes? Yes? It is only TCP based. Okay. I can talk a little bit more about that. Here we are. Yes? I mentioned that we had an unexpected situation about the publish, subscribe part of the functionality, meaning that whenever we send a message, it should be sent to all clients that were connected. That didn't happen in practice, but that's what we expected. The protocol itself is based on TCP. So it makes the assumption that you have a connection which is already up and always up. So whenever it goes down, it waits until the network is up again. So you are basically always connected. And when you are connected, you can decide yourself what you want to do. As a client, you can ask the server, meaning the device, for some information, meaning polling. You can also say to the device, whenever a value changes at this part here, for instance, let's say a node on this node tree structure inside the device, exposes the temperature of the device. So whenever the temperature is over 100 degrees, let's say that, send an event back. So you can poll or you can have push information. And also you can do event listening. That's what we are using mainly for the road traffic measurements. Whenever a vehicle passes by, this is registered as an event taking place inside the sensor and the device. And then the device pushes that information to us. So we are always up. And sometimes we ask the device, sometimes we just receive messages as they happen. So you basically listen for information in the main use case for such a protocol here. So when the network goes down, these messages are buffered on each side. And then when it comes up again, then they are transferred. Yes. But we don't want that in our case. I don't know if the protocol supports sending to each and every client separately. I guess then the client must ask separately and then necessarily will respond towards each client. You have the notion of sessions and subscriptions inside it. Whenever you connect, you start having a connection. That's the sort of the basic object that you can interact with in the protocol. And on that you have a session which is then client specific. And upon that you can add subscriptions which are then what should trigger something on your side when everything, something happens on the server. So you can decide depending on which type of call you do against the sensor if it should be a message to everyone or just for me type of information. I'm a bit unsure of the nuances in the details here, but this is how we have used it at least. But it's a large standard. It might be that it contains more advanced information or, sorry, functionality in this regard. Yes. This protocol actually, I'm sorry, the question was a usual way to connect to Internet of Things devices is also through JSON or HTTP, meaning traditional Internet protocols. OPCU also supports SOAP web services as the protocol. So you can choose either to use the TCP based, meaning socket level, binary protocol information, or you can use a basic standard web services endpoint type of integration point. So you can use XML at least and SOAP if you want to connect to OPCU device. We have not been doing that, I think mainly due to bandwidth resource limitations. Binary information is a bit more efficient than XML over HTTP. But of course, depending on your situation and what your needs are, if you do normal HTTP integration, you have maybe it's an easier protocol to understand. It's more transparent. There are one billion clients that talk HTTP. So the availability of toolkits, et cetera, cannot be matched by anything. And also you have these things like compression, which can be added, G-Zipping, et cetera, and also TLS and security encryption, et cetera. So a little bit depending on your needs and what actually the devices support and what they have in terms of available resources. HTTP could of course also be a relevant protocol for many situations. More questions? Should I do a demo of the system? Do you want to see real traffic, live traffic? I have some spare moments. I'll connect. I hope this will work. Of course it will work. Thanks for having me. So, here we are in production. A little bit fuzzy graphics. Okay, I think it's the projector. Let's see. All of the green dots are running sensors. The red ones are not connected at the moment, mainly due to network outages. So we have something like 500 devices right now and 170 of them are not connected. This is, as mentioned, mainly due to network outages. At a given time, we have something like 20% of the devices being disconnected. So we can look at some road traffic. Okay, around Oslo it was not so good. Okay, here's one. Okay, this one probably has more traffic. It's more interesting to look at traffic. And here's some maintenance information about the box itself, the device itself. Some photos of it where it is installed. So here it's a little bit more of spaghetti than the previous picture, but okay. And here's the road with these markers in it where the sensors, or the cables actually are placed. And here is the traffic. Okay, there's not too many cars driving. There's one. Yes. And the delay here is something like one and a half second from the vehicle passes by until we can look at this on the screen. So whenever a field engineer does the installation, this is a picture similar to this is the last step in the installation procedure. So the field engineer is standing right next to where the sensors are and then, okay, this car draws that direction approximately the speed, et cetera. You can look at this for ages, but okay, it's not that interesting. But okay, it sort of displays the essence of the application, besides, of course, the reporting part of this. Meaning that we can do aggregates and look at how many cars are driven by the last hours, the last weeks, et cetera, et cetera. And we have quite a lot of information stored inside the system. We can do vehicle classification. It's part of what these boxes do in the field. The engine type is not part of the classification. The emission types, et cetera. No, we don't know that. Yes. That's a lookup. That's actually available for everyone to look at. This is a different application inside the public roads administration, the Vaivessen. Okay, not that one. What they offer, Vaikart roadmap, more or less. That's, okay, fart. You can look at all the information that is stored. It's a public database. You can query it and navigate to all types of objects that are installed roadside. This is an application that everybody can use. It's not limited in these senses. So here we have something like 20,000 various or available speed limit objects inside the database. So we just get that information from this system. It's a different system inside or an internal system at the public roads administration. But it's available for anyone to use. So we just connect those information in our application. So there are all kinds of various strange things that you can look at inside this application. It's used for entrepreneurs to be able to estimate the maintenance cost, the maintenance project, whenever a part of the road should be maintained by somebody else. They can look at this system and have an idea how much they should maintain in practice. And road maintenance is also part of our application because whenever you look at how many cars that are driven by, you get a good estimate of whenever the pavement needs replacing, for instance. It's read only and property. We cannot influence the speed limit, no. But the statistics say a little bit about how people actually drive. And of course, that's information that's interesting for when you're building roads and also for the police. It can be interesting. But I guess the police, they already know where people drive too fast anyway. And also this information does not connect any person-specific information to the given event. You just know that some vehicle drove by. Yes, question? The clients. Meaning... The clients, meaning our application, in terms of integration or how the data is being used. The client is our application. Sorry about that. I'll just find the illustration here. Here. Each narrow data logger, in the OPCU protocol, whenever you connect two devices, the part which is the sensor, that's the server. And the client, in our case, is one application. So we have one application that's connected to all of these sensors. So you can say there's many sensors to one application type of integration. So our application has to handle the connections to all of these sensors at a given time. So that's something what we do when we restart the application. The first thing we do is to re-establish all connections to all of the devices. So there's actually just one client in our case. The devices themselves do not talk to each other. They all talk to us. Actors. Actors, yes. That's part of the application, internals. Yes. If you have been using Erlang or something like that in software architecture, there's a pattern which is called the actor pattern. And we are using that in our application. So we have basically one little worker that has the responsibility to connect to a data logger. And there will be many of those. And yes. But fortunately, the implementation of those is really efficient. So far it has not bothered us. But I will not talk much about the application, not at least here. Any more questions? No? Okay. Thank you. Thank you. Thank you.
 Welcome to my presentation. I will be talking about how to understand your sensors, integrating  with them, choosing the right protocol in terms of an IoT application. The background  that I have in this context is that I have been working on a project that does integrate  an application with sensors or at least measurement devices as we call them, which in turn are  connected to a typical sensor. The project measures traffic data, vehicle traffic data.  It's a road analysis project. There's one of the previous project members in the audience  today, so if there are any difficult questions, I will route them to this person. No, I will  do that. Okay, talking to your sensors and understanding your sensors, that's the context  today. What you actually do when you connect to a sensor is that you are integrating. A  schematic display of integration can be seen upon to be very, very simple, just like this,  but integration in practice can be a lot more complicated. This is one of the reasons I'm  here to talk about this today. Whenever you talk, have two components that talk together,  there are a lot of considerations that you have to take. Some of them are obvious from  the beginning, some of them appear in the way. Details of integrations, you can really  quickly end up with a long list, which in turn decides which protocol you should be  using. I will be discussing a few of these criterions in this talk, but I will also explain  some of the most typical protocols that you can choose among. To begin with, should you  push from A to B or pull from B to A? Is this synchronous asynchronous peer-to-peer or through  a broker through a middleman? Do you need to validate data before sending them or before  receiving them? What if A or B crashes? Should you resend things? Should you ignore what  happens? What is your data format? Which protocol are you using for the data? How do you encode  them? What about authentication? What about performance? What about encryption? What about  scalability? Et cetera, et cetera, et cetera. These criteria are not necessarily relevant  in every case, but they can be relevant for you. It depends on the application you are  building. It depends on your situation. They can in turn introduce a lot of complexity.  There are, of course, a lot more points in such a list than what I have included here,  but these are some that appear in my mind at least. As you can see, the sequence is not  entirely random. They are sorted, but that's not the point here. But this influences what  type of integration protocol you should be using. Among other things, these are relevant.  So what is the situation that I have experience in terms of doing these kinds of integrations?  Well, the project consists of a network of sensors. Here is a very simplified map of  the sensors. These are measurement points, which we call them, which are installed along  the roads in Norway. The project is underway, meaning we are not into full production yet,  but when we are, there will be something like 4,000 or 5,000 devices in a roadside installation  that collects data from each and every vehicle that passes by. We, meaning the project that  I am a part of, we collect the information and store them for analysis. These devices  are not low-power devices. They are not resource constrained. They have power. They have 3G  network available. So this is not a constrained environment in terms of how much memory you  have, how much CPU you have, how much bandwidth you have. The bandwidth is sometimes a bit  limited, but it's usually quite okay. So we can look upon this as an industrial IoT application.  It's not a consumer IoT application. And this, of course, introduces some other constraints  than other applications. So a little bit more detail. What we are doing, we are measuring  and storing road traffic information. What about the vehicles that pass by? Was it a  car? Was it a motorcycle? Was it a bus? Was it a lorry? Et cetera, et cetera. So record  the time stamp, the speed, vehicle length, vehicle type, et cetera. All of this information  is non-identifying. We don't have any information about the driver or the license plates or  anything like that. No photos are taken here. We are storing each and every event. So for  each, every event that is registered, the event itself is sent to the application that  we have. And here we have an installation. The field engineer here is very proud. He  shows us the new cabinet with the new installation. This is just besides the opera here in Oslo.  It was a sunny day and everything was just nice. It even worked when he installed it.  So everybody was happy. And this is how it looks like. So the blue box there inside the  cabinet, that's the box that is responsible for connecting to the roadside sensor, which  is actually just cables in the pavement. So whenever you drive by and see squares in  asphalt just like this, this means that somebody has installed these loops, which is essentially  a cable, which measures the flux or the magnetism of the vehicles that pass by. And through  that can decide which type of vehicle that passed by and then send that information to  us. So the signal analysis is done inside these blue boxes. You can see one here if  I can find my mouse pointer. Yeah, here it is. It's a bit small, but it's a quite powerful  device. It doesn't have advanced signal analysis. And the project itself has been in production  for more than two years. So we have some practical experiences about how these things work. A  little bit more schematic overview. The sensors, the loops, they are underneath the road pavement.  And so whenever a vehicle passes by, we can register this. And there's a cable that goes  to what we call the data logger. That was the blue box. This is an embedded Linux device,  which does the signal analysis. These loggers are connected into a 3G modem, which then  transmits each and every event to the application that we are building. And what sometimes happens  is whenever there's a bus driving by, for instance, when a lot of people send SMS or  something like that, the connection might go down because the 3G connection here does  not have high priority. So robustness in terms of network outage is extremely important for  us. We need to get hold of the information about the cars that pass by, even though the  network can be down at times. So on the receiving end, the system we have built consists basically  of an application with some storage underneath, a storage system for very quick saving of  data and reading of data and analysis. And we have the option to do real-time use of  traffic that passes by or ad hoc reports, meaning aggregates of information about the  cars, about the speeds, about the types of vehicles that pass by at given times of the  day, et cetera. Traffic patterns, more or less. And we have an installation component  and an administration component to look at the insides of the application. And the delay  from a vehicle passes by until we can see it in our real-time view component is something  like one or two seconds. We have not optimized this for low latency, but the latency still  is quite low. And we are happy with that because we can look upon the system and see how is  the traffic now. That can be interesting to be able to, not at least in terms of doing  the quality assurance of an installation. So the field engineer does that as the last  step of an installation to ensure that whatever the system records is actually what's taking  place on the road behind him or her. So the question is what protocol should we be using  for connecting our application to this environment? When looking at the IoT most used protocols,  there are some candidates that reappear. And I've been looking at them very briefly. One  of them is the XMPP protocol. It has a rather long history. It started being used more or  less as a chat protocol, actually, from Jabber. If anybody has been using Jabber, this is  what's actually taking place underneath. It is XML-based. So whenever you work with this,  you need to be able to work or love XML. Some do, some don't. But it's part of this protocol.  It's very much XML-based, which means you do text transfer. It also means it's not very  bandwidth efficient. But it is distributed. It means you can relay messages from one XMPP  server to another, just like email. So you can forward and relay information across various  servers from one end user to a different end user. It is very distributed in its architecture.  It's extensible. It has lots of extra add-ons to it, and it's open. There are a lot of open  implementations of this protocol. It supports encryption, just like HTTPS in the normal  Internet web sense, but not end-to-end. So whenever a message is relayed, it can be read  by the intermediate servers. You can also use different transfer protocols underneath  it, meaning it's more or less like XML and some more parts, and then HTTP, for instance,  underneath. The issue with XMPP is the robustness of it and the quality of service that you  can expect from it. It is more or less a fire and forget protocol. You don't have any assurance  of what's happening after a message has been sent. Will it be received by a client or not?  As mentioned, it's not very hand-bandwidth efficient, and binary data must be encoded,  the typical base 64 encoding, et cetera. Some of these issues might be addressed by the  extensions to this protocol, but you might have some trouble finding the right implementation  for them for every case that you might end up with. But it is a candidate. Have a look  at these, what you call it, the standards, the XMP323 and 325, which defines control  of sensors, control of the endpoints, and also the messaging in itself. They can be  relevant to have a look at in terms of the functionality of this protocol, what it offers  in some of the limitations might appear from that. This is one to consider, definitely.  A different one, a little bit of a different end of the spectrum is cope. It's defined  by the Internet engineering task force. This is more for the low end or low resource type  of applications or sensors that you might have. It exposes a REST-like API, so reasonably  high level, but it still uses UDP as the transport layer, so it is not bound to TCP, which means  that it has a different resolution in terms of how the message is passed and what you  actually need underneath to be able to pass messages. It is designed for a one to one  type of situation where you have one client and one server. It also has encryption support  but not TLS, but something at the lower level, like the UDP lever. It also has support for  payloads, content negotiation, et cetera. It's a little bit more flexible and you can adjust  how data should be interpreted under way. It also has a very limited but might be reasonable  quality of service functionality. Also, you have event listeners, so you can get a message  whenever a sensor has a change that it wants to publish. It is also very bandwidth efficient.  Publish andcribe support is a little bit limited, so be aware of that. It's not through message  queuing as we might expect it. You don't have any topics that multiple sensors can connect  to and send messages to. It's a one to one protocol, mainly. But consider that one as  well. It's widely used. Different one, MQTT also appears a lot. This is actually also  quite an old protocol. I think it was partly made by IBM in its time, something around  1999, I believe, but it has since been open source and it's really available and simple  to find implementations for it. In this case, the sensor is a client. This is the opposite  of the previous protocols. The previous ones, the sensor is the server. Here, the sensor  is a client and it connects to an MQTT broker. This is integration through a broker. It's  also designed for low resource usage and it uses TCP for transport. It has various quality  of service support levels and it's quite robust and it supports buffering or messages whenever  you have a network outage. Also, encryption and authentication is available. The interesting  thing is that it promises exactly one delivery of messages. According to computer science  theory, this is actually not possible. You cannot have exactly one guarantee in practice.  You might have it in theory in terms of how the messages are transferred, but at the implication  level, you cannot have one, exactly one delivery of a message. It's an interesting problem  to consider. But if you are unsure, please have a look at the Internet. Do some searching  about exactly one messaging. It might get quite theoretically detailed, but it's an  interesting question. I think everybody, when you see exactly one's delivery, you should  be a bit skeptical. MQTT relies on an always on connection, which might or might not fit  your needs. If you have a low resource usage need, then having always a connection up is  not what you look for. You want to then shut down the connection and then do reconnect  at given times in order to save power, for instance, if you have a battery-powered device.  Now a little bit about the protocol that we are using. It's OPC UA. I might be a bit  biased here, but okay, I'm trying to do a reasonably objective comparison here. This  one has it roots in industrial robot control. So it's built for a little bit of different  context than the other protocols, perhaps. In this case, the answer is a server. A server  here defines or has inside three structure of nodes, meaning it is a data model that  describes the server itself. What you do when you connect to a server is that you can ask  for these three structure and then read out information about the capabilities of the  server of the device itself. It's quite flexible and each node in these three structure represents  either attributes. We can just read and pull or events, meaning whenever something changed,  you get a push message out of the server or you even have methods. So you can call a remote  method on the device if you want to. This can be very, very powerful. I will return to  that later. Also, for each node, there is values that you can read and each value has  a rich metadata set, meaning you can get information about when the value was set, what the previous  value was, for instance, various things that might be very relevant for your application,  depending on what you are building, of course. It is TCP based, so this is internet friendly  in this sense, and data are transfer binary, reasonable bandwidth efficient way of sending  the data. It also has great features for security, authentication of both client and server,  and also encryption and the authentication can be done through certificates. So you have  quite a strong knowledge of what is connecting to what whenever you do an integration using  OPC if you want to. Also, and this is very important in our case, you can transfer real-time  data using this, or you can also ask for historical data in this protocol. And this goes back  to then the situation we have where we have events that are taking place, cars that drive  by a measurement point, and for instance, then we have a network outage, and 1,000 cars  pass by, and one hour later when the network is up again, we want to ask how many cars  have passed by in the meantime. So you would like to ask for data that has taken place earlier.  And this is very well made in this protocol. It has support for batching the, if you ask  for too large interval and too many messages, the device itself can batch the responses  automatically, and this is handled by the protocol. It is also very robust. It has a  buffering of messages, so whenever a network goes down, both the client and the server  will know it and act accordingly. So it is very much a transparent protocol in terms  of whatever happens when the network is gone. It is large. It contains a lot of functionality  which you might or might not need. At times it is complex and a bit non-intuitive. It  can be actually too flexible as well. There are various ways that you have to implement  this protocol for your specific need if you have a specific device. So you need to interpret  how the device actually works and then from that expose this through the protocol and  then let clients connect to this properly. So it might be a bit of knowledge that you  have to build in order to use this protocol correctly. But that's, in our case, that's  okay. We have had our experiences and our issues. I'll return to that. But for our part,  it now works and it's stable and it does its job. So what should you select such a protocol  upon? So more criteria which is not related to integration itself. You should decide at  which level should you rely on a given network infrastructure functionality. It's building  upon UDP, the right thing is building upon TCP, the right thing is building upon HTTP,  the right thing. How does your network look like? Would you end up having to open firewalls  or doing nothing, et cetera? The devices you have, how much resources do they have? How  much RAM do you have? How much CPU do they have? How much power do they draw? The protocols  can have an influence on the resources they actually use. And also robustness, of course.  What happens when a network goes down and comes up again, et cetera. And also message  flow. Is this a one-to-one protocol or is it publishing to the whole world, et cetera?  In our case, bidirectional information transfer is very, very important. I'll get back to  that also. Scalability, according to the number of messages that have to be transferred or  the number of sensors that you have installed in your network, is also important. And also  the various implementations that are available. Is this a vendor-neutral implementation, a  vendor-neutral protocol? How open is it? Is it open source? Can it be freely used inside  your application? What are the license conditions, et cetera? And also the tool sets. You should  never forget that you have debugging tools and perhaps also tools that are not from the  vendor that are giving you this package, the SDK or the implementation. So you can find  out if the vendor has done some vendor-specific tricks that can be really hard to debug if  there are some internal things that you cannot look at because they are hidden by the vendor.  So the main criteria that we ended up with choosing OPC UA was the robustness part of  this, the security, the option that you have to have certificates on both clients and server.  And also the ability to read historical data. We can ask the devices for old information.  So each device has a buffer, which is really large, actually, which stores each and every  vehicle that has passed by. So the number of events that they store, I think it's something  like one million events, actually. So whenever there's a road traffic installation which  has a lot of traffic, I think the amount of time data should be available is something  like three months in hindsight. So we can survive a network outage of nearly three months,  actually. The feature set in OPC UA is quite rich. You have the option to remote call a  procedure which the device itself exposes. We are using this for other things, firmer  upgrades. And this is quite interesting. Whenever we discuss Internet of Information, I'm sorry,  Internet of Things applications, security very often appears. And it's the so-called  Internet of Insecure things that sometimes is said. We are using this to remote call  a procedure on the device that lets the device download a firmer upgrade, a firmer image.  So we can tell each and every device you should upgrade yourself now. We have the firmer images  stored inside the application. So we ask the device, download this image from our application  and install it on yourself. And using this, we can remote upgrade any device that we have  connected to our application. This makes maintenance really easy and also patching security errors  or bugs or whatever, really, really easy. It has been a little bit bumpy road together,  but the ability to do this is very important. You can, of course, do this as long as you  have a bidirectional message transfer. You can craft a specific message to a device which  should then be interpreted as do install a new firmer upgrade. So the point in itself  might not be the OPCU protocol, but to have a bidirectional connection. Because then you  can trigger upgrades on your sensors. And I think that is a really, really, really important  feature to have. So whenever you're considering a protocol, do you consider security updates  as part of this and remote administration? Also, after some testing, whenever the protocols  were considered, there were found that there existed high quality implementations of the  protocol. The protocol itself is theory, but implementations are practice. And as we know,  these can be two different things. So there was one implementation that was chosen for  the product and we have been using that. And it has been the right choice for us. We have  had very, very few issues with the library we are using, which is a Java based commercial  library that does OPCU. So here the picture besides this is from a test lab. It's at Krett.  It's a little bit south of Tronia. And here there are two of these devices that have been  used for testing. This one is here. Interesting enough, industrial design is not always very  modern. And this one here is also being used for testing. This is a bit old picture. So  this box is no longer used in its original version. But the internals of it has been  upgraded. So it's still in use, actually. So these two are different devices that have  are used in the field. And so this is how it can look like in a testing lab. Some of  the implementations that you can look at, if you're interested in looking at OPCU further,  the Java one we are using is from a Finnish company, Prusys. Here it is. Yes. The license  is commercial, but I would like to add to that that it's a reasonable license. Depends  on the definition of reasonable, but it's not extremely expensive. It's flexible, in  my point of view. You don't pay per installation. You pay per developer. And that's reasonable.  In my opinion. There are also some open implementations popping up. We have not tested this. We cannot  say that this is a good implementation or this is a bad implementation, but they should  be considered. If you are curious and if you're interested in looking at this OPCU protocol. .NET implementation, this is open source, MIT license. We have some experience with  that from previous summer. We also did a little bit of patching to it. It lacked the event,  functionality of the OPCU protocol. So this was added by someone in our project. But it's  a fairly good implementation. It has lots of unit tests in it. So this is one to consider  if your environment should be or is JavaScript based. In practice, node if you're using  node. C libraries are also available and also quite good one in Python. So depending on  your environment and your application architecture, there are some options for this protocol.  There are also some very, very resource optimized implementations that you can run on microcontrollers  et cetera. I think OPCU is server can be implemented running on something like 10 gigabytes of  RAM. Something like that. At extreme end. So theory and practice. The protocol was chosen.  The devices were bought and we started integrating them. What happened? Well, there are some  ways to interpret the protocol which can differ from one hardware vendor to a different hardware  vendor and also in terms of how the software we were using interpret the protocol. So especially  handshakes when you establish a connection and also the reconnect protocol. We had some  problems with that in order to make that happen correctly. So we used wire shark to look at  what happened and from that learned how the response was and how it should be and what  the request was and what the request should be. So wire shark supports OPCU quite well.  You can use that for debugging and see what actually is going on. And that is a very good  thing to do. Interesting thing. Some response times were longer than the timeouts. So you  would never get an answer. That's not good. So theory and practice. If you were asked for  more data then the device could return in the expected amount of time. So okay, you have  to adjust the timeouts. These timeouts were not on our side. They were on the device vendor  side. So we have not control over these timeouts. And also in this case, the device itself is  a server. So when you connect to the server from multiple clients, you expect that messages  that are published should be received by all the clients. What we experienced is that in  the beginning when we connected two clients to the same box, the responses were actually  around Robin. So you didn't get a full view of what was happening. And that was not expected.  When we publish, you publish to all, not around Robin. So it was a little bit of discussion  and then they fixed that. I will not mention names here just to be precise. These things  happen no matter what the vendor name is. At one given time, we wanted to test how you  can read real-time events, the passing of vehicles happening right now, together with  history reads, meaning from previous hour or yesterday or something. And it turned out  you can get one of those and not both. And we were not happy with that because we want  to do both at the same time. That's very important for us. And then the firmer upgrades. A specific  requirement was set that you should upgrade a box in one go. It should be an atomic event.  And this was a bit interestingly interpreted to be the option that you can download three  firmers instead of one. And then these three ones should be then upgraded in series. And  that was not what we said and not what we meant, neither of those. But it was what happened  and we found out that a little bit late. So this is now working on as we speak. Also the  implementation was a bit incorrect here and there, including in our library to a small  degree. But apart from that, we have been very satisfied with the library. And also,  whenever you do a specification of something, there's always something that can be interpreted  differently than actually what you meant. It is what we said, but it was not what we  meant. To mitigate this, there are some things that you can do. I will return to that.  And no matter how you specify things and you test things, there will always be new things  that you find out under way whenever you test things. So testing, testing, testing, testing  is needed. There are so many practical considerations. Whenever you're dealing with physical devices,  there's so many things can happen that you cannot upfront find out all of them, what  they are and no upfront what they should be or know what the effects are either directly  or two weeks later. So you have to actually experience things in practice.  So a little bit of summary. What are the main experiences? You should consider the whole  stack whenever you look at a protocol. You should look at the network underneath. You  should look at what the sensor itself is capable of. You should look at what integration needs  is, what should be in a protocol and what should be in your application? What logic  should you rely on is handled by the protocol? What logic should you rely on yourself in  terms of what the application actually contains of logic? You should do the theoretical evaluation.  Have a look at the Internet. What have other projects done? Ask and connect with people.  Read about other one's experiences. And you have to do field testing. Their experiences  might not be the same as yours. The actual implementation you are building might be quite  different in ways that are hidden before you test them. One experience I would like to  emphasis on is that you should create a compatibility kit. Something like a test implementation  that is an actual small implementation of a device, either a client or a server. So  the opposite connection point can connect you. So you have in practice a test that can  be run. So you can say to a vendor, okay, if your box connects to this code and these  and these and these operations perform well, then you are passing the test and then we  can integrate with you. It should be part of the specification to hand out such an implementation.  Because then you know in practice what actually the interpretation of a given protocol or  a given set of logic on rules is. And then that can expose a lot of details that would  otherwise be left. Of course, the question then is what should the scope of such a kit  be? But at least doing it will help, in my opinion. We are also doing gradual deployments.  This is very important, I think, for being able to adjust the course in a way. During  the first year, I think we deployed something like 100 devices. We learned a lot from that.  Now we are at around 600 devices and we have still some things to learn. But what we have  done between each batch of installation is to adjust the requirements. So each batch was  a separate buying process, which means you can adjust the requirements for each buying  process. So there's gradual deployment going on, meaning that you do not buy all the devices  at once. So whenever you see there is a misinterpretation in the communication or in the specification  or something is not the way you wanted it to be, you can adjust before buying the new  batch. So you can adjust as you go. And this is a typical engineering principle, I guess,  to measure, evaluate and adjust. But also do that whenever you have a project in this  sense. Because there are so many things you cannot explicitly define upfront. So you have  to be able to set up your project so they can do things gradually. And gradual deployments  and also compatibility toolkits, that might be the main and most important experiences  that we have had that I would like to share with you. Any questions? Yes?  The question was how the network is whenever we are where we do these connections. It is  a separate network. It is internet, but it is separated from the rest of the world, so  to say. So it can be considered a VPN. Am I correct? Yes? Yes?  Okay. Since I mentioned wire shark, why did I mention that or how were we able to do this  debugging using wire shark? Was that the context? Okay. At that moment we didn't use the encryption  code. It can be specified whenever you start a server or a client. Actually, then the server  defines what is happening. No. But in this sense, we could imagine somebody opening these  cabinets and installing their own devices. If they really would like to, I don't know  why, but it could be done. In this sense, then you can have a certificate on each box,  which is verified in our application. Is this a logic box? Should we get data from it or  not? But when doing debugging, you need to lose the encryption. Yes? Yes?  It is only TCP based. Okay. I can talk a little bit more about that. Here we are.  Yes? I mentioned that we had an unexpected situation about the publish, subscribe part  of the functionality, meaning that whenever we send a message, it should be sent to all  clients that were connected. That didn't happen in practice, but that's what we expected.  The protocol itself is based on TCP. So it makes the assumption that you have a connection  which is already up and always up. So whenever it goes down, it waits until the network is  up again. So you are basically always connected. And when you are connected, you can decide  yourself what you want to do. As a client, you can ask the server, meaning the device,  for some information, meaning polling. You can also say to the device, whenever a value  changes at this part here, for instance, let's say a node on this node tree structure inside  the device, exposes the temperature of the device. So whenever the temperature is over  100 degrees, let's say that, send an event back. So you can poll or you can have push  information. And also you can do event listening. That's what we are using mainly for the road  traffic measurements. Whenever a vehicle passes by, this is registered as an event taking  place inside the sensor and the device. And then the device pushes that information to  us. So we are always up. And sometimes we ask the device, sometimes we just receive messages  as they happen. So you basically listen for information in the main use case for such  a protocol here. So when the network goes down, these messages are buffered on each  side. And then when it comes up again, then they are transferred.  Yes. But we don't want that in our case. I don't know if the protocol supports sending  to each and every client separately. I guess then the client must ask separately and then  necessarily will respond towards each client. You have the notion of sessions and subscriptions  inside it. Whenever you connect, you start having a connection. That's the sort of the  basic object that you can interact with in the protocol. And on that you have a session  which is then client specific. And upon that you can add subscriptions which are then what  should trigger something on your side when everything, something happens on the server.  So you can decide depending on which type of call you do against the sensor if it should  be a message to everyone or just for me type of information. I'm a bit unsure of the nuances  in the details here, but this is how we have used it at least. But it's a large standard.  It might be that it contains more advanced information or, sorry, functionality in this  regard. Yes.  This protocol actually, I'm sorry, the question was a usual way to connect to Internet of  Things devices is also through JSON or HTTP, meaning traditional Internet protocols. OPCU  also supports SOAP web services as the protocol. So you can choose either to use the TCP based,  meaning socket level, binary protocol information, or you can use a basic standard web services  endpoint type of integration point. So you can use XML at least and SOAP if you want  to connect to OPCU device. We have not been doing that, I think mainly due to bandwidth  resource limitations. Binary information is a bit more efficient than XML over HTTP.  But of course, depending on your situation and what your needs are, if you do normal  HTTP integration, you have maybe it's an easier protocol to understand. It's more transparent.  There are one billion clients that talk HTTP. So the availability of toolkits, et cetera,  cannot be matched by anything. And also you have these things like compression, which  can be added, G-Zipping, et cetera, and also TLS and security encryption, et cetera. So  a little bit depending on your needs and what actually the devices support and what they  have in terms of available resources. HTTP could of course also be a relevant protocol  for many situations. More questions? Should I do a demo of the system? Do you want to  see real traffic, live traffic? I have some spare moments. I'll connect. I hope this will  work. Of course it will work.  Thanks for having me.  So, here we are in production.  A little bit fuzzy graphics.  Okay, I think it's the projector.  Let's see.  All of the green dots are running sensors.  The red ones are not connected at the moment, mainly due to network outages.  So we have something like 500 devices right now and 170 of them are not connected.  This is, as mentioned, mainly due to network outages.  At a given time, we have something like 20% of the devices being disconnected.  So we can look at some road traffic.  Okay, around Oslo it was not so good.  Okay, here's one.  Okay, this one probably has more traffic.  It's more interesting to look at traffic.  And here's some maintenance information about the box itself, the device itself.  Some photos of it where it is installed.  So here it's a little bit more of spaghetti than the previous picture, but okay.  And here's the road with these markers in it where the sensors, or the cables actually  are placed.  And here is the traffic.  Okay, there's not too many cars driving.  There's one.  Yes.  And the delay here is something like one and a half second from the vehicle passes by  until we can look at this on the screen.  So whenever a field engineer does the installation, this is a picture similar to this is the last  step in the installation procedure.  So the field engineer is standing right next to where the sensors are and then, okay, this  car draws that direction approximately the speed, et cetera.  You can look at this for ages, but okay, it's not that interesting.  But okay, it sort of displays the essence of the application, besides, of course, the  reporting part of this.  Meaning that we can do aggregates and look at how many cars are driven by the last hours,  the last weeks, et cetera, et cetera.  And we have quite a lot of information stored inside the system.  We can do vehicle classification.  It's part of what these boxes do in the field.  The engine type is not part of the classification.  The emission types, et cetera.  No, we don't know that.  Yes.  That's a lookup.  That's actually available for everyone to look at.  This is a different application inside the public roads administration, the Vaivessen.  Okay, not that one.  What they offer, Vaikart roadmap, more or less.  That's, okay, fart.  You can look at all the information that is stored.  It's a public database.  You can query it and navigate to all types of objects that are installed roadside.  This is an application that everybody can use.  It's not limited in these senses.  So here we have something like 20,000 various or available speed limit objects inside the  database.  So we just get that information from this system.  It's a different system inside or an internal system at the public roads administration.  But it's available for anyone to use.  So we just connect those information in our application.  So there are all kinds of various strange things that you can look at inside this application.  It's used for entrepreneurs to be able to estimate the maintenance cost, the maintenance  project, whenever a part of the road should be maintained by somebody else.  They can look at this system and have an idea how much they should maintain in practice.  And road maintenance is also part of our application because whenever you look at how many cars  that are driven by, you get a good estimate of whenever the pavement needs replacing,  for instance.  It's read only and property.  We cannot influence the speed limit, no.  But the statistics say a little bit about how people actually drive.  And of course, that's information that's interesting for when you're building roads  and also for the police.  It can be interesting.  But I guess the police, they already know where people drive too fast anyway.  And also this information does not connect any person-specific information to the given  event.  You just know that some vehicle drove by.  Yes, question?  The clients.  Meaning...  The clients, meaning our application, in terms of integration or how the data is being used.  The client is our application.  Sorry about that.  I'll just find the illustration here.  Here.  Each narrow data logger, in the OPCU protocol, whenever you connect two devices, the part  which is the sensor, that's the server.  And the client, in our case, is one application.  So we have one application that's connected to all of these sensors.  So you can say there's many sensors to one application type of integration.  So our application has to handle the connections to all of these sensors at a given time.  So that's something what we do when we restart the application.  The first thing we do is to re-establish all connections to all of the devices.  So there's actually just one client in our case.  The devices themselves do not talk to each other.  They all talk to us.  Actors.  Actors, yes.  That's part of the application, internals.  Yes.  If you have been using Erlang or something like that in software architecture, there's  a pattern which is called the actor pattern.  And we are using that in our application.  So we have basically one little worker that has the responsibility to connect to a data  logger.  And there will be many of those.  And yes.  But fortunately, the implementation of those is really efficient.  So far it has not bothered us.  But I will not talk much about the application, not at least here.  Any more questions?  No?  Okay.  Thank you.  Thank you.  Thank you.
Understanding_your_sensors__How_to_choose_a_protocol_0_179.png Understanding_your_sensors__How_to_choose_a_protocol_180_359.png Understanding_your_sensors__How_to_choose_a_protocol_360_407.png Understanding_your_sensors__How_to_choose_a_protocol_408_635.png Understanding_your_sensors__How_to_choose_a_protocol_636_779.png Understanding_your_sensors__How_to_choose_a_protocol_780_1415.png Understanding_your_sensors__How_to_choose_a_protocol_1416_2231.png Understanding_your_sensors__How_to_choose_a_protocol_2232_13103.png Understanding_your_sensors__How_to_choose_a_protocol_13104_15275.png Understanding_your_sensors__How_to_choose_a_protocol_15276_31427.png Understanding_your_sensors__How_to_choose_a_protocol_31428_37307.png Understanding_your_sensors__How_to_choose_a_protocol_37308_40055.png Understanding_your_sensors__How_to_choose_a_protocol_40056_45803.png Understanding_your_sensors__How_to_choose_a_protocol_45804_50807.png Understanding_your_sensors__How_to_choose_a_protocol_50808_50879.png Understanding_your_sensors__How_to_choose_a_protocol_50880_51491.png Understanding_your_sensors__How_to_choose_a_protocol_51492_51707.png Understanding_your_sensors__How_to_choose_a_protocol_51708_51947.png Understanding_your_sensors__How_to_choose_a_protocol_51948_52091.png Understanding_your_sensors__How_to_choose_a_protocol_52092_52571.png Understanding_your_sensors__How_to_choose_a_protocol_52572_52823.png Understanding_your_sensors__How_to_choose_a_protocol_52824_52883.png Understanding_your_sensors__How_to_choose_a_protocol_52884_53039.png Understanding_your_sensors__How_to_choose_a_protocol_53040_53099.png Understanding_your_sensors__How_to_choose_a_protocol_53100_53267.png Understanding_your_sensors__How_to_choose_a_protocol_53268_53831.png Understanding_your_sensors__How_to_choose_a_protocol_53832_54191.png Understanding_your_sensors__How_to_choose_a_protocol_54192_59111.png Understanding_your_sensors__How_to_choose_a_protocol_59112_59579.png Understanding_your_sensors__How_to_choose_a_protocol_59580_60131.png Understanding_your_sensors__How_to_choose_a_protocol_60132_60731.png Understanding_your_sensors__How_to_choose_a_protocol_60732_61607.png Understanding_your_sensors__How_to_choose_a_protocol_61608_63419.png Understanding_your_sensors__How_to_choose_a_protocol_63420_64103.png Understanding_your_sensors__How_to_choose_a_protocol_64104_64475.png Understanding_your_sensors__How_to_choose_a_protocol_64476_64667.png Understanding_your_sensors__How_to_choose_a_protocol_64668_64931.png Understanding_your_sensors__How_to_choose_a_protocol_64932_66071.png Understanding_your_sensors__How_to_choose_a_protocol_66072_66419.png Understanding_your_sensors__How_to_choose_a_protocol_66420_67835.png Understanding_your_sensors__How_to_choose_a_protocol_67836_68315.png Understanding_your_sensors__How_to_choose_a_protocol_68316_68423.png Understanding_your_sensors__How_to_choose_a_protocol_68424_71831.png Understanding_your_sensors__How_to_choose_a_protocol_71832_71987.png Understanding_your_sensors__How_to_choose_a_protocol_71988_72071.png Understanding_your_sensors__How_to_choose_a_protocol_72072_72119.png Understanding_your_sensors__How_to_choose_a_protocol_72120_74375.png Understanding_your_sensors__How_to_choose_a_protocol_74376_74447.png Understanding_your_sensors__How_to_choose_a_protocol_74448_74495.png Understanding_your_sensors__How_to_choose_a_protocol_74496_74543.png Understanding_your_sensors__How_to_choose_a_protocol_74544_74591.png Understanding_your_sensors__How_to_choose_a_protocol_74592_74923.png