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
May 21, 2022
May is Asian American and Pacific Islander (AAPI) Heritage Month. We would like to spotlight some of our incredible AAPI-identifying employees to celebrate. We recognize the important influence that... ...
May 20, 2022
I'm very happy with my new OMTech 40W CO2 laser engraver/cutter, but only because the folks from Makers Local 256 helped me get it up and running....
May 19, 2022
Learn about the AI chip design breakthroughs and case studies discussed at SNUG Silicon Valley 2022, including autonomous PPA optimization using DSO.ai. The post Key Highlights from SNUG 2022: AI Is Fast Forwarding Chip Design appeared first on From Silicon To Software....
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...

featured video

Building safer robots with computer vision & AI

Sponsored by Texas Instruments

Watch TI's demo to see how Jacinto™ 7 processors fuse deep learning and traditional computer vision to enable safer autonomous mobile robots.

Watch demo

featured paper

5 common Hall-effect sensor myths

Sponsored by Texas Instruments

Hall-effect sensors can be used in a variety of automotive and industrial systems. Higher system performance requirements created the need for improved accuracy and more integration – extending the use of Hall-effect sensors. Read this article to learn about common Hall-effect sensor misconceptions and see how these sensors can be used in real-world applications.

Click to read more

featured chalk talk

NEUTRIK Fiber Optic Solutions

Sponsored by Mouser Electronics and Neutrik

The advantages and benefits of fiber optics are a mile long…but how can you design with them? How can you clean them? How do you repair them? Need a bit of a refresher? In this episode of Chalk Talk, Amelia Dalton chats with David Kuklinski from Neutrik about the OpticalCon advanced, OpticalCon LITE and Opticalcon DragonFly fiber optic solutions from Neutrik. They take a closer look at what benefits each of these solutions brings to the table, what kind of configurations are offered with each of these fiber optic solutions and what kind of performance you can expect when using them in your next design.

Click here for more information about Neutrik opticalCON® Fiber Optic Connector System