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
Dec 8, 2023
Read the technical brief to learn about Mixed-Order Mesh Curving using Cadence Fidelity Pointwise. When performing numerical simulations on complex systems, discretization schemes are necessary for the governing equations and geometry. In computational fluid dynamics (CFD) si...
Dec 7, 2023
Explore the different memory technologies at the heart of AI SoC memory architecture and learn about the advantages of SRAM, ReRAM, MRAM, and beyond.The post The Importance of Memory Architecture for AI SoCs appeared first on Chip Design....
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

Dramatically Improve PPA and Productivity with Generative AI

Sponsored by Cadence Design Systems

Discover how you can quickly optimize flows for many blocks concurrently and use that knowledge for your next design. The Cadence Cerebrus Intelligent Chip Explorer is a revolutionary, AI-driven, automated approach to chip design flow optimization. Block engineers specify the design goals, and generative AI features within Cadence Cerebrus Explorer will intelligently optimize the design to meet the power, performance, and area (PPA) goals in a completely automated way.

Click here for more information

featured paper

3D-IC Design Challenges and Requirements

Sponsored by Cadence Design Systems

While there is great interest in 3D-IC technology, it is still in its early phases. Standard definitions are lacking, the supply chain ecosystem is in flux, and design, analysis, verification, and test challenges need to be resolved. Read this paper to learn about design challenges, ecosystem requirements, and needed solutions. While various types of multi-die packages have been available for many years, this paper focuses on 3D integration and packaging of multiple stacked dies.

Click to read more

featured chalk talk

Automotive/Industrial PSoC™ High Voltage (HV) Overview
Sponsored by Mouser Electronics and Infineon
In this episode of Chalk Talk, Amelia Dalton and Marcelo Williams Silva from Infineon explore the multitude of benefits of Infineon’s PSoC 4 microcontroller family. They examine how the high precision analog blocks, high voltage subsystem, and integrated communication interfaces of these solutions can make a big difference when it comes to the footprint size, bill of materials and functional safety of your next automotive design.
Sep 12, 2023
10,495 views