#2:IoT starts with a business case (hopefully!).
Putting a sensor in your dog’s collar, or in a drilling machine, is not an end in itself…
What you want is rather be able to check that your dog remains in a given “geofence”, or, for a more tangible (and arguably useful) use case: monitor the usage patterns for your fleet of drilling machine, to figure out if maybe the workers need specific training to use it better, etc.
#3:So while you start with an application in mind, of course it will require some interaction with the physical world (yes, a dog collar, if that’s what you really want! 😁)…
#4:Eventually, you will need to figure out how to bridge the gap between the physical world and the application you want to create. That involves a whole lot of technologies that may sound like “IT as usual”, but certainly comes with some constraints and specifities inherent to IoT - more about this in a couple slides…
#5:From a 20,000 foot view, this how most if not all IoT architectures are implemented. In order for your data to make it to the cloud, and hence to the final application/user, the devices (think “microcontroller” and tiny brain that are the heart of sensors and actuators) need to be able to communicate. While some might have this capability (and more on that in the next slide), a gateway is typically in charge of connecting the constrained devices to the IoT.
#6:Let’s look a bit closer at the key characteristics of each element of an IoT solution.
Devices - or I should say constrained devices - are really doing a specific task (e.g measuring the vibrations of a motor).
We’re talking brains (microcontrollers) that are probably 1$, if not less, and that are by definition constrained in terms of computing capabilities, number of I/Os, etc.
Often, but not always, power consumption is a key aspect. So this will have impact on the H/W and S/W capabilities.
These devices are very specialized. If you can save 2 cents by getting rid of a H/W feature that you don’t need, you will do it. Similarly, you will make choices in your software, and you will e.g probably support the protocol you need and only this one.
Gateways / Smart Objects - as per the explanation I just did, you realize that most of the times, devices won’t have the ability to implement direct communication to the Internet. This is where you need what I call smarter objects, or gateways.
Here, connectivity is essential (of course, you aim at reaching a backend/cloud server eventually), an a smart object often will have many options for connectivity
Not only can the device/gateway communicate, but typically you want it to also be smart enough to actually manipulate messages, as opposed to “raw” data. That is to say, the smart object is already able to make some smart...er decisions when it comes to forwarding sensor data to the cloud or not, or figuring out which device a command being received from the cloud is targeted to
All in all, the gateway/smart object enables so-called edge computing
Cloud – this is where a lot of the IoT magic happens :-)
Of course, scalability is important. Horizontally, as the number of devices on the field grows (zillions of devices, eh?), as well as vertically, to deal with different business cases and their specificities
It’s all about integration, since you need to enable third party to e.g consume your sensors’ “fire hose”, or people to be able to build their own application and dashboards.
Lots of the value for IoT is in the data, and the cloud platform needs to help not only storing the huge amounts of data, but also analyzing and making sense out of it.
So assuming we are on the same page now on what those 3 key components are, let’s look in more details at what are the core features that need to be provided by each of them.
#12:Some concerns actually span across all the components.
You want security at each level, and things like the ability to only run trusted code on your devices, the ability to secure your communication channels against eavesdropping, or the ability to secure your Cloud platform REST APIs for giving users access only to what they’re supposed to have access to
IoT data is very diverse. If your IoT datastore does not give you a way to figure out the difference between temperature and pressure data, or to figure out what is in Celsius and what is in Fahrenheit, you will be in big troubles. Ontologies are needed to describe data that flows in the IoT value chain.
Tools. You need simulators, debuggers, emulators, etc. in order to accelerate IoT development, simplify testing, etc. Of course if you know us (Eclipse) you do realize we provide a lot in that area.
#13:So why doing this categorization anyways?
Well, identifying the different layers of a software stacks, and the interfaces through which each stack can communicates helps define an interoperable architecture:
each stack is independent from one another. You can use whichever cloud stack/provider you want, no matter your gateway stack – no vendor lock-in
within each stack, the layers are interchangeable. If you want to replace the communication layer of your gateway to speak HTTP WebSockets instead of MQTT, this is something that should be possible.
Each stack should be independent of the underlying platform. E.g for the the cloud stack, you probably want to leverage the likes of Docker, Cloud Foundry, Kubernetes, …
Open Standards have proven key (look at the history of the Internet, or in IoT and more recently: MQTT) for enabling interoperability too.
Of course, each component/service of your IoT stacks will need to expose well-defined APIs, as it’s what enables composition/reuse by others who add value on top of the stack.
#14:So what do we do at Eclipse for IoT?
Well, for the past 5 years, we’ve been working hard on creating a forum where individual and companies work together to create the software that can be used to create Open IoT Stacks.
[ We actually do much more than being a pure software provider - more on that towards the end of the presentation…]
#15:To update this slide → make a screenshot of https://iot.eclipse.org/member
#16:If you’ve been following us (we’ve been around for 5 years now!) from the beginning, and even if you have not, you realize we’re this open source community providing key components and libraries – let’s call them building blocks – that can be used to create an IoT solution.
Want an MQTT protocol stack? Sure, you can get it from Eclipse Paho. A security layer for your microcontrollers? Maybe you will use Eclipse tinydtls…
But more recently, we’ve seen a trend towards delivering more integrated platforms/stacks that take the building blocks I just mentioned, and integrate them in a readily usable stack. Much like the LAMP (Linux-Apache-MySQL-PHP) stack for the WWW, if you will.
