feature article
Subscribe Now

Golgi and the IoT

Or, Does the IoT Demand a Cloud Platform?

We hereby embark on a reverie that commenced before and continued during the writing of this article. And I’m not quite sure if it’s done yet. The evolution of thought practically happened in real time as I tried to explain… stuff. And to draw said stuff. In the end, perhaps this is an etude in defining the Internet of Things (IoT). As usual, it may raise more questions than it answers.

I can’t believe it’s been almost two years since I made a feeble attempt to put some structure behind this nebulous concept of the IoT. Much of my thinking (not to mention the industry) has progressed since then, but I had a discussion recently that forced me to go back to an image I had put together illustrating how I saw the various pieces of the IoT coming together. To a first order, it still feels more or less relevant (although clearer than ever that it wasn’t put together by a true graphic artist).

I reprise the figure below as a starting point, but I’ve de-highlighted the bits I don’t really want to pay attention to in this discussion. I’ve even removed the “hub” (or “gateway”) – not because it’s not relevant, but because it’s a complicating factor that doesn’t really matter. Let’s pretend we don’t need it, shall we?

Figure_1.png 

What we’re left with is a configuration consisting of Things talking to the Cloud. And, critically, Phones that also talk to the Cloud. So data can travel from the Thing to the Cloud; the Cloud can work its deep learning and analytical magic and then present the results to the Phone for us to gaze at admiringly. (Assuming we’re under 40 years old and can read the text.)

But, after talking to Golgi,* I was left with the feeling that maybe it’s not quite so simple. Although, as I write, I must admit I’m still wrapping my head around what follows. Because, in my original thinking, the Cloud-to-Phone communication is bidirectional. Yes, data goes from the Cloud to the Phone, but then, presumably, instructions will go from the Phone back to the Cloud and thence back to the Thing. It’s all one big integrated-but-distributed beast.

Where does Golgi fit then? Golgi enables Phones to talk to Things. They do that by having the Thing talk to Golgi’s Cloud infrastructure, which then talks to the Phone. And vice versa. But they go to pains to clarify that they’re not a Cloud platform.

What that means is that Golgi isn’t implementing the Cloud portion of this figure. Because the goings-on in my conception of the Cloud are defined by the system developer. All of the analytics and algorithms are application-specific. With a convenient platform, it’s easy to configure and build all of this custom functionality, but, regardless of how much work was required, it’s still custom.

How does this compare to Golgi’s Cloud component? The difference is that you can’t control any of what goes on in the Golgi Cloud bits – they’re fixed, and they implement only what’s required to ensure that blobs of data travel reliably back and forth between the Thing and the Phone.

I got to see a demo of Golgi technology in action at the IoT DevCon recently; sure enough, given a collection of Things using a variety of communication modes – even texting (under the hood, using SMS as a channel) – they were able to control the Things from the Phone. In that case, it might seem odd to send the messages way off to the Cloud somewhere, only to have them come back two feet away, but it makes much more sense when the Things are at home and you’re on the train.

Still and all, having seen that, I was scratching my head (while nodding sagely so that no one could see that I was perhaps a step behind). If IoT apps talked to Phones from Cloud platforms (and Golgi wasn’t a Cloud platform), then why was a separate Golgi pathway needed?

Listening to the discussion, my initial takeaway was that this phone communication stuff is actually difficult, and that most of the other systems couldn’t make it work. So Golgi would let you establish a Phone connection alongside your other Cloud implementation. This would look something like the next figure.

 Figure_2.png

This still isn’t particularly satisfying. Even with this parallel path, you still need to be able to view Cloud data on the Phone. So it feels like this parallel path is only for controlling the Thing. Which is consistent with the fact that the communication model with Golgi is remote procedure call (RPC), not publish/subscribe. In other words, it’s command-centric, not message- or data-centric.

Still, communication really happens both ways with Golgi, so this just seems a bit clumsy.

It then occurred to me – literally while writing – that my confusion may all come down to how one defines the IoT. The original figure comes from my conceptualization of the different components of the IoT, and the presence of the Cloud with application-dependent functionality is, to me, a critical element in that definition. Otherwise you’ve simply got a collection of networked equipment.

But what if I backed off on that? What if some guy is making equipment and wants only to be able to control it from a phone from anywhere? No fancy-schmancy algorithms, no wading up to your armpits in pools of big data; just make the dang Phone talk to the dang Thing. Is that too much to ask?

Well, in that case, the whole Cloud platform part of the picture disappears, and you’re left with Golgi as a communication channel. And there’s no ambiguity. The two Cloud entities (custom and Golgi) don’t coexist; they’re alternatives. The following image, to me, makes far more sense.

Figure_3.png 

The question that then comes to mind is, does such a Golgi implementation really represent an IoT instance? I think that this is what’s gotten me swimming a bit – the fact that this is supposed to be an IoT Thing without a real Cloud intelligence component. If my conclusion is correct (and a quick check-in with Golgi seemed to confirm it), then it feels to me like this is simply implementing a Phone as a (very) remote control for a Thing.

That’s not meant as a put-down; I’m sure there’s a ton of hard work that has gone not only into making the communication work via the many ways devices can talk, but also into defining the mechanism that lets developers build the apps that implement that communication. Using dev kits for the selected platforms, developers write programs using Golgi’s APIs and four basic data types, and then Golgi creates the drivers and files required to make this work on the targeted systems. Pretty slick.

But I just can’t visualize the IoT without the Cloud. Why? Because the Cloud is where all this abundance of data is supposed to be transformed into wisdom and peace and love and rock and roll. (Sex and drugs optional.) All that data fusion is what makes the IoT more than the sum of all the Things.

But I could be wrong. If you define the IoT as any distributed system with an internet component – which a Golgi-powered system would definitely be – then you don’t need a “smart” Cloud function. Feel free to opine in the comments below.

 

AFTERWORD: Between writing and submitting this piece, I happened to attend the Sensors Expo conference. One conversation with Anaren had a similar flavor: accelerating the ability to connect a phone to a device. Again, like a remote control. This reinforces a view of the IoT as being “connected devices” that may or may not have intelligent Cloud capabilities. I got the sense from some of the people that I talked to both at Sensors Expo and at DAC that the whole Cloud intelligence thing is still more concept than reality. (I’m sure some Cloud companies would disagree.)

 

*For those of you with medical skills, this will be obvious. For the rest of us, well, it’s not clear if this word has Greek, Latin, Germanic, or other roots. My pronunciation guess was a Hellenic “goal-ghee.” That’s not correct: it’s “Gaul-jee.”

 

More info:

Golgi

 

One thought on “Golgi and the IoT”

Leave a Reply

featured blogs
Oct 20, 2020
In 2020, mobile traffic has skyrocketed everywhere as our planet battles a pandemic. Samtec.com saw nearly double the mobile traffic in the first two quarters than it normally sees. While these levels have dropped off from their peaks in the spring, they have not returned to ...
Oct 20, 2020
Voltus TM IC Power Integrity Solution is a power integrity and analysis signoff solution that is integrated with the full suite of design implementation and signoff tools of Cadence to deliver the... [[ Click on the title to access the full blog on the Cadence Community site...
Oct 19, 2020
Have you ever wondered if there may another world hidden behind the facade of the one we know and love? If so, would you like to go there for a visit?...
Oct 16, 2020
[From the last episode: We put together many of the ideas we'€™ve been describing to show the basics of how in-memory compute works.] I'€™m going to take a sec for some commentary before we continue with the last few steps of in-memory compute. The whole point of this web...

featured video

Demo: Inuitive NU4000 SoC with ARC EV Processor Running SLAM and CNN

Sponsored by Synopsys

Autonomous vehicles, robotics, augmented and virtual reality all require simultaneous localization and mapping (SLAM) to build a map of the surroundings. Combining SLAM with a neural network engine adds intelligence, allowing the system to identify objects and make decisions. In this demo, Synopsys ARC EV processor’s vision engine (VPU) accelerates KudanSLAM algorithms by up to 40% while running object detection on its CNN engine.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

Fundamentals of Precision ADC Noise Analysis

Sponsored by Texas Instruments

Build your knowledge of noise performance with high-resolution delta-sigma ADCs. This e-book covers types of ADC noise, how other components contribute noise to the system, and how these noise sources interact with each other.

Click here to download the whitepaper

Featured Chalk Talk

PiezoListen: A New Kind of Speaker for New Applications

Sponsored by Mouser Electronics and TDK

Until recently, putting speakers into extremely space-constrained designs was a daunting challenge. Now, however, advances in piezo speakers bring remarkable performance to ultra-small ultra-thin speakers. In this episode of Chalk Talk, Amelia Dalton chats with Matt Reynolds of TDK about PiezoListen - a whole new kind of high-performance multilayer piezo speaker.

Click here for more information about TDK PiezoListen™ Ultra-Thin Piezo Speakers