Why Context Is Crucial to Edge Computing Success

The very nature of technological innovation lends itself to the kinds of buzzwords and jargon that can often prevent people from understanding the technologies themselves. These buzzwords range from metaphorical terms, but ultimately easy to understand, like “cloud”; to absolutely literal terms like “Internet of things”. Somewhere in the middle is where we get terms like “edge computing,” which is where the technology itself and the term used to describe it have one essential thing in common: they require context.

Why Context Is Crucial to Edge Computing Success

In IT, we call it a “use case.” Still, that term is essentially a tangible manifestation of the context in which the technology will be most effective, be it a manufacturing scenario, a telematics platform, or an IoT integration. Even within IoT, context is crucial because it can be used in something as simple as a smart thermostat, something as advanced as an MRI machine, or any number of use cases in between.

The real challenge when it comes to cutting edge computing is not so much creating a device, but making sure that the device can operate and transmit data reliably.

People focus on the platform side of the business too often because that’s where they are going to see ROI on data and analytics. But, still, if they don’t have the right things at the edge of the network, then all that wonderful back-end processing isn’t going to be much.

Edge computing tends to be overlooked

Edge computing tends to get overlooked because most people just take it for granted. This happens a lot during the manufacturing process, especially since there is a mind-set that when you buy a device like a laptop or smartphone, that device will communicate with other devices through a user-driven interface.

We are thinking: “use the smartphone to send data to the laptop and then use the laptop to send the same data to the printer.”

In the context of IoT devices, this is not how things work.

Without proper edge management, maintenance costs can skyrocket quickly for a device that is meant to be self-sufficient. And we’re not just talking about rolling trucks to troubleshoot a router. In some cases, these devices are literally designed to be buried in the ground next to crops to measure soil moisture.

I0T is a small device meant to exist and function on its own

In the IoT realm, we are building these new miniature devices that are meant to exist and function on their own. The initial interactions that we are having with most of our customers and business partners are centered around the question, “How do we connect with this? How do we handle this protocol? How do we support this sensor? “

Some of the biggest challenges arise when we go down to the electronics level and begin to figure out how to interact from electronics to the first level of the software level.


In the world of IoT, devices are created with some kind of communication standard in mind. However, remembering that the actual data they transfer, and how they transfer it, is another piece of the puzzle. In addition, the devices must be maintained throughout their useful life.

Maybe the temperature went up or down, or the device just needs to periodically send information to the network to do something.

Most of the time, people are challenged to design these things, and it might be the first time they have faced the challenge of caring about problems. People forget that it is not plug-and-play, like a laptop or a printer.

Modern mobile devices consume data

Even something as simple as data itself, and understanding how modern cellular devices consume data compared to their Wi-Fi and 3G counterparts, can derail an entire IoT project before it even takes off. It is a much more challenging world to deal with.

Is the device correctly scaled and calibrated?

Another key area of ​​that world involves being able to ensure that devices are properly scaled and calibrated, and that the data they transmit is handled in a meaningful way. For example, if something goes wrong with the connection, that data needs to be correctly queued so that when the connection is reestablished, it can end up where it was supposed to go.

Many otherwise very successful companies have learned these kinds of lessons the hard way by not considering how their devices would behave in the real world. For example, they could be testing those devices in a lab when they are finally designed to use mobile data. The cost of that critical communication function ends up being so high that the device is not a commercially viable product.

What is the first job or function of the device? Will it work as intended?

Of course, it can be even more disastrous when developers focus too much on how the device will work before they have spent enough time figuring out whether the physical device itself is going to work in the first place.

Whether it is some kind of simple telematics device for a vehicle, an advanced module for use in manufacturing, or any number of devices in between, the fundamental job of making sure that a given device and its components will work as intended. it is often relegated to people with less experience.

Appreciate the complexity

In many cases, people become involved and do not appreciate the complexity they are dealing with until they have already suffered a series of setbacks. It could be an environmental issue, a battery life issue, or even something as simple as where an antenna should be placed. Then once it’s been placed on the field, how will it update?

Is the item or device really ready to ship? Test, test, test.

When these types of devices fail after being placed in the field, the cost of replacing and re-shipping them alone can completely ruin the entire product line. This is why it is so important to test them in the field in smaller groups and avoid being seduced by the garden path of climbing them too quickly.

Big plans are great, but starting small and iterating over time is the ultimate case where an ounce of prevention is really worth more than a pound of cure.

Delivery to the customer: the “last mile”. But think of “the first mile first”.

People often speak of cutting edge computing as a “last mile” technology and, like the last mile of a marathon, it is the most challenging of all.

Historically, large telecommunications and IT companies describe connecting to a device or perimeter as the “last mile,” as in the delivery of data services from the curb to the house.

But that is a wrong point of view in IoT. It all starts with the device – the creator of the data. So connecting to the device and delivering data to the application infrastructure is “First Mile” crossing.

Either way, once we have the proper understanding and context of how edge computing works in the real world, the finish line is now in sight.

Image credit: valdemaras d .; pexels; Thank you!

John keever

John keever

Chief Technology Officer, Telit IoT Platforms Business Unit

John Keever currently serves as the CTO of Telit’s IoT Platforms Business Unit. He came to Telit from ILS Technology, a company that Telit acquired in 2013. Mr. Keever founded ILS Technology and began serving as Executive Vice President and Chief Technology Officer in October 2000. He has more than 30 years of experience in software engineering automation. and design. Mr. Keever has both hardware and software patents. Mr. Keever came to ILS Technology from IBM Corporation, where he was a global services principle responsible for architectures and implementations of electronic production solutions. Mr. Keever enjoyed more than 18 years of plant automation experience with IBM and was the former global support and development manager for Automation Connection, Distributed Application Environment, PlantWorks and Data Collection hardware and software products. Data. His prior experience within IBM includes leading marketing and solution architecture responsibilities for General Motors, BMW, Chrysler, Tokyo Electron, Glaxo-Wellcome, and many other global manufacturing companies. He has a BS in mechanical engineering from North Carolina State University, a master’s degree in mechanical engineering, majoring in electrical engineering and mathematics, from North Carolina State University. He has also done graduate work in computer engineering and operating systems design at Duke University. I have always been passionate about mechanical, electrical and computer engineering, having studied them in my undergraduate and master’s degrees. Founding my own company, ILS Technology, and working for a global IoT enabler like Telit has provided me with valuable insight into the business and technical aspects of IoT and the technology that I would like to share with the ReadWrite community. In addition to founding my own company, I have over 30 years of automation software engineering and design experience and 18 years of plant automation experience with IBM. This experience, coupled with a master’s degree in mechanical engineering, gives me the foundation and knowledge necessary to bring valuable information to the ReadWrite audience that can help improve their technical knowledge and share new insights on legacy practices. ReadWrite strives to produce content that enhances reader productivity and provides quality information. With 30 years of automation software engineering and design experience and 18 years of plant automation experience with IBM, I believe I have the foundation and knowledge necessary to contribute valuable and quality insights to ReadWrite audiences who not only They will help improve your technical knowledge, but also share new ideas about legacy practices.


Leave a Reply

Your email address will not be published. Required fields are marked *