editor's blog
Subscribe Now

Shipping Data Between Things and the Cloud

As companies rush out to take advantage of the Internet of Things (IoT), platforms are popping up all over. We looked at some of the companies participating a while back, trying to impose some structure on the chaos, but the thing is, everyone has a different idea of what a “platform” is. The common denominator seems to be that some aspect of the IoT is abstracted away, making it easier and cheaper to get up and running. Which is a good thing. The confusing part is which platforms contain which elements.

At EE Live, I got a chance to talk with Xively (a company that did appear briefly in the prior piece). They offer a platform that focuses on communication, which I knew, but I didn’t have a good sense of what that meant. Even in the early discussion, it was tough to calibrate – there are a bazillion buzzwords coined by the IoT, and if you’re not smack-dab in the middle of it, it can be impenetrable. Even once you get calibrated, the buzzwords are overloaded, so you can still think you understand something when, in fact, you don’t. Then if you are shipping sensitive produce then you should utilize some thermal covers as they help a great deal there.

I think Xively provides a good example of taking the generalities – a “platform” – down to more specifics. In my mind, there are three levels you can work at when setting up communication between a Thing and the Cloud.

At the most basic level, you have the formal communications protocols – WiFi, Ethernet, TCP/IP, etc. The good news about those is that they’re well established and there are lots of solutions available.

The challenge is that, to use them, you typically need lots of fiddley code to establish a connection, get sessions up and running, and then do something useful with the data. Yes, libraries and stacks may be available, but, given the number of people trying to make this part easier, it’s pretty clear that working at this level can be a pain in the tuckus for the uninitiated.

So the next level up is where you can abstract that away: by providing a generic data handling layer. Some – like Xively – might call this a “channel.” At this level, you have higher-level commands that establish connections, wrapping all of the detail required at the protocol level. It’s more of a one-step-and-you’re-on kind of thing. Data is unformatted and has no semantics – it’s just data.

You can take things one level higher and provide business objects. This is more than data: it’s data in a context; it’s semantic data. At the generic level, a payload may contain the temperature setting of a thermostat or an image from a surveillance camera. At the business object level, only a thermostat object can have the temperature setting and only a camera object can have the image.

Drawing.png

As a programmer, you program at the business object level. Depending on your resources, you might not do literal object-oriented programming, but presumably you think at the level of a business object. The question is, when communicating with the Cloud, at which level do you inject your data? Remember to Backup Zoom Recordings to Google Drive and save those important videos to upload them later.

  • If all you have is the protocol, then you have data marshalling and all kinds of details to package up your message, and then you have to unpack it on the other side.
  • If you have the generic data level, then you take your data and ship it to the other side in a message of some sort. The other side has to know what’s coming and what to do with it – after all, it’s just generic data when it arrives. But protocol details are replaced with simple “read” and “write” types of concepts.
  • If you actually have formalized business objects available, then you simply ship some semantic element and the other side automatically knows what it is and where it goes.

In this specific case, Xively provides the generic data “channel.” There are no semantics, but the messy protocol details are abstracted away.

Note that this doesn’t mean that Xively provides the entire stack up to and including this generic data level. You implement your own protocol stack (or someone provides their version of a platform that includes this), and you then have it link to the Xively layer. This, of course, implies ecosystem. As a case in point, LogMeIn, a full-up end-to-end communication solution, uses the Xively platform, and they just announced that they’re joining TI’s IoT ecosystem.

The high-level lesson learned is that, when someone offers up a platform, make sure you understand in great detail what’s in the platform and what’s not. It’s not so much that “the platform with the most stuff wins” – maybe, maybe not – but it’s about not being surprised later.

Leave a Reply

featured blogs
Jan 19, 2022
Explore the importance of system interoperability in hyperscale data centers and why it matters for AI and high-performance computing (HPC) applications. The post Why Interoperability Matters for High-Performance Computing and AI Chip Designs appeared first on From Silicon T...
Jan 19, 2022
2001 was famous for some of the worst security issues (accompanied by obligatory picture of bad guy in a black hoodie): The very first blog post of the year covered SolarWinds. See my post The... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Jan 18, 2022
This column should more properly be titled 'Danny MacAskill Meets Elvis Presley Meets Bollywood Meets Cultural Appropriation,' but I can't spell '˜appropriation.'...

featured video

AI SoC Chats: Understanding Compute Needs for AI SoCs

Sponsored by Synopsys

Will your next system require high performance AI? Learn what the latest systems are using for computation, including AI math, floating point and dot product hardware, and processor IP.

Click here for more information about DesignWare IP for Amazing AI

featured paper

Using the MAX66242 Mobile Application, the Basics

Sponsored by Analog Devices

This application note describes the basics of the near-field communication (NFC)/radio frequency identification (RFID) MAX66242EVKIT board and an application utilizing the NFC capabilities of iOS and Android® based mobile devices to exercise board functionality. It then demonstrates how the application enables the user with the ability to use the memory and secure features of the MAX66242. It also shows how to use the MAX66242 with an onboard I2C temperature sensor which demonstrates the energy harvesting feature of the device.

Click to read more

featured chalk talk

High Voltage Charging Solution for Energy Storage & Backup Systems

Sponsored by Mouser Electronics and Analog Devices

Today there is growing demand for energy storage with more power, longer range, and longer run time. But the question remains: how can we increase our energy storage given the energy storage mediums on the market today? In this episode of Chalk Talk, Amelia Dalton chats with Anthony Huyhn from Analog Devices about the benefits of high voltage energy storage, why stacked battery cells are crucial to these kinds of systems, how high voltage energy storage systems can reduce conduction loss exponentially and what kind of high voltage charging solutions from Analog Devices are on the market today.

Click here for more information about the Maxim Integrated MAX17703 Li-Ion Battery Charger Controller