Attack of the Things; or, how to build an IoT Application in a Hurry

Posted by Daniel Barnes on 3/6/17 11:17 AM

Your CEO has just rushed in all excited! He's had this brilliant vision for an IoT application and the investors loved it. He already told them "It's easy! We should have that in 6 months, tops!" Cold sweat.

What was that thing about platforms decreasing time to market? Does that really work? Let's take a look at SNAP, the Things Platform starting with the nuts and bolts. Of course, realize that a Product Manager is writing this. When you're ready to really dive in deep, you can get all the reference material, API documentation, etc from our developer site. I'm hoping to just splash your toes a bit with a somewhat Real World example.

Let's start with a Thing. No. Let's take Dr. Seuss's advice and start with two Things to make it interesting. 

Things.jpg

Remember Two Things

You have one Thing that needs to monitor the temperature of a very important motor and another Thing that needs to sound an alarm and flash a light if the temperature of the motor gets too hot.

Perhaps your first inclination is, "That's easy. I'll just hop on the existing WiFi network and I'm done." Then you talk to the Emperor of IT, Prince of Password Expiration, Duke of Daily Microsoft Updates.

You:  I would like to add a couple of small Things to your WiFi network....

Emperor of IT, etc.: SILENCE! OT Dog. We have ruled that NO barbaric Things SHALL pass into the Kingdom of the IT.

Ok, well maybe it's not that dramatic, but you've probably experienced something like that before. So now you're wondering how you're going to wirelessly connect these two Things.

SNAP provides an overlay network that allows Things to communicate over a heterogenous set of underlying technologies such as 802.15.4 or TCP. Using the SNAP protocol, two devices can invoke functions on each other via an RPC mechanism.

Remember one of the key sets of problems Cloud platforms solve? Cloud platforms transform networking problems (hard) into data-centric problems (easier). SNAP abstracts you from 802.15.4 or TCP. It abstracts you from the SNAP protocol. From headers, and sequence IDs, checksums and bits and bytes. It lets you focus on calling functions on your Things, rather than sending packets.

Cloud platforms also make it really easy to bake qualities such as scalability, reliability and security into applications. The SNAP protocol bakes reliability and security measures in by providing CRC's and AES 128-bit encryption. Much of this is configurable.

For now we'll focus on the 802.15.4 network. We'll talk more about overlay networks in a bit. 

Core: An OS for the Thing

Core provides an implementation of the SNAP network stack to specific modules. Currently only 2.4 GHz 802.15.4 is supported, but there are plans to support other frequencies and underlying technologies this year. You embed these modules into your Things to allow them to seamlessly communicate. 

Core contains a set of built-in RPC functions and the ability to expand with your own definition of functions. Core separates the implementation of the network communication and built-in implementations from your own user functions by separating the firmware Synapse creates from the user implementations you create. Your user implementation is written as a SNAPpy (a paired down version of python) script and is independently updated from the Core firmware.

User scripts give you the ability to not only access hardware such as ADCs and GPIO, but also give you a place to do computation on the Thing.

Unknown-1.jpeg

Three Things: The Power of Mesh

Let's add another motor to our setup. Unfortunately it is out of direct range of the alarm "Thing", but is in range of the other temperature sensor. SNAP supports mesh routing as well as mesh multicast repeats. Whenever your new motor passes its temperature threshold, it can send an RPC to the alarm "Thing" via a repeating "Thing". Your application code doesn't have to know anything about the intermediate hops. It just knows its destination and the function it wants to call.

One Large "Thing" Network

So far, I've shown you three Things. Big Deal. That's not scalable. How do you handle a sea of Things? And maybe you do really want to bring your data and control out to the IT network and even over the WAN. How does that work? 

A Synapse gateway provides the bridge between an IP network and the Thing network. Connect provides the interface to the Things via the gateway. Remember that a gateway is not necessary for the mesh or "Things" to do their job. If you want something with more horsepower or want an aggregation point or just want IP connectivity into your "Thing" network, that's where Connect comes in.

Let's say you are now monitoring many of your motors and you want to do some data trend analysis in the Cloud. Typically, you'd write an application on the gateway that uses Connect to pull sensor data from the Things via RPC's and then push it over an IP protocol to some other destination (such as REST Post to a cloud API). Applications using Connect have the full python language and LINUX stack at their disposal, making them a great place to do more intense computations.

This will still likely require some tribute to His IT Majesty, but you have a much better chance of adding a single LINUX device to an IT network than a bunch of very small embedded devices. Notice that the mesh is helping you work around those pesky Real World obstacles.

One Overlay Network - Multiple Physical Layer Networks

Now that you've scaled up your single network to, say, 1,000 things, maybe you want to scale to other areas of the same building. But now you have another problem. You can't repeat the 802.15.4 network over all of the distance nor through some of the obstacles. But you do have LAN connectivity between the various sites. This is where the overlay network comes into play. The SNAP protocol is independent of the underlying transport technology and Connect on the gateway can communicate over 802.15.4 and TCP/IP at the same time. A Thing on one physical 802.15.4 network can call RPCs on another Thing that is separate by multiple IP and 802.15.4 hops. Neither Thing knows about the underlying networks.

Summary

SNAP solves two sets of problems.

  1. Transform networking problems (hard) into data-centric problems (easier)
  2. Make it really easy to bake qualities such as scalability, reliability and security into applications

SNAP solves the first problem by allowing you to send RPC's between nodes without concerning yourself with the packet format, with headers and CRC's and sequence ID's. It lets you focus on programming remote nodes by calling functions.

SNAP makes it easy to bake in scalability with it's mesh routing and overlay network. It makes reliability better by providing CRC's, sequence numbers, and mesh networking for network traffic and separating the core firmware from the user scripts on the Thing. SNAP provides security with AES encryption of traffic between nodes.

I don't pretend to believe that these measures alone completely solve the problems, but they are necessary. Check out our first platform release notes and future posts to see how we are progressing towards enhancing the solutions to these sets of problems.

 

Synapse Blog

Subscribe to Email Updates

Recent Posts