The very nature of technological innovation lends itself to the types of buzzwords and jargon that can often prevent people from understanding the technologies themselves. These buzzwords range from metaphorical, but ultimately easy to understand, terms like “cloud”; to literally literal terms like “Internet of Things”. Somewhere in between we get terms like “edge computing,” 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 Successful Edge Computing

In IT, we call this a “use case”. Yet this term is essentially a tangible manifestation of the context in which the technology will be most effective, whether it is a manufacturing scenario, a telematics platform, or a 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 cases. of use between the two.

The real challenge in edge computing is not so much to create a device, but rather to ensure that that device can function and transmit data reliably.

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

Advanced computing tends to be overlooked

Edge computing tends to be overlooked because most people just take it for granted. This often happens during the manufacturing process, in particular, because there is a mindset that when you buy a device like a laptop or smartphone, it the device will communicate with other devices via a user-controlled interface.

We think, “use the smartphone to send data to the laptop, then use the laptop to send the same data to the printer”.

In the context of IoT devices, that’s not really how it works.

Without proper management of the edge, maintenance costs can quickly skyrocket for a device that is supposed to be self-contained. 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 footprint device intended to exist and operate on its own

In the field of IoT, we are building these new small footprint devices that are supposed to exist and work on their own. The first interactions we have with most of our customers and business partners focus on the question, “How do we connect to this thing?” How to manage this protocol? How do we support this sensor? “

Some of the biggest challenges come when we step down to the electronics level and start figuring out how to interface from electronics to the first level of the software level.

Communication

In the world of IoT, devices are built with some form of communication standard in mind. However, keeping in mind that the actual data they transfer – and how they transfer it – is another piece of the puzzle. In addition, devices must be maintained for the life of the device.

Maybe the temperature has risen, or the temperature has fallen, or the device is just periodically intended to send information back into the network to do something.

Most of the time, people are challenged to design these things, and this may be the first time they’ve been challenged to worry about the issues. People forget that it’s not plug-and-play, like a laptop or a printer.

Modern cellular devices consume data

Even something as simple as the data itself – and figure out how modern cellular devices consume data compared to their Wi-Fi and 3G counterparts, can derail an entire IoT project before it even starts. It’s a much more difficult world to manage.

Is the device properly scaled and calibrated?

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

Many otherwise very successful businesses have learned these types of lessons the hard way by ignoring count how their devices would behave in the real world. For example, they can test these devices in a lab when they are ultimately designed to use cellular data. The cost of this critical communication function ends up being so high that the device is not a commercially viable product.

What is the first task or function of the device? will it work as expected?

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

Let it be some kind of simple vehicle telematics device, an advanced module for use in manufacturing, or any number of devices in between, the essential work of ensuring that a given device and its components will perform as intended is often left to those with the less experience.

Appreciate the complexity

In many cases, people are thrown into it, and they don’t appreciate the complexity they cope until they have already suffered a number of setbacks. It could be an environmental issue, a battery life issue, or even something as simple as where an antenna needs to be placed. Then, once placed in the field, how will it be updated?

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

When these types of devices fail after having already been placed in the field, the cost of replacing and reshipping them can alone completely torpedo the entire product line. This is why it is so important to field test them in small groups and to avoid getting carried away by the garden path of resizing them too quickly.

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

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

People often refer to advanced computing as “last mile” technology, and like the last mile of a marathon, it is the most difficult of all.

Historically, large telecom and IT companies have described connecting to a device or the edge as the “last mile,” as if providing data services from the sidewalk to the home.

But that’s an incorrect point of view in IoT. It all starts with the device – the author of the data. Therefore, the connection to the device and the transmission of data to the application infrastructure crosses the “First Mile”.

Either way, once we have the right understanding and context for how advanced computing works in the real world, the finish line is already in sight.

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

John keever

CTO, Telit IoT Platforms Business Unit

John Keever is currently CTO of Telit’s IoT Platforms Business Unit. He joined Telit from ILS Technology, a company which Telit acquired in 2013. Mr. Keever founded ILS Technology and started as Executive Vice President and Chief Technology Officer in October 2000. He has over 30 years of experience in automation software engineering. and design. Mr. Keever holds hardware and software patents. Mr. Keever joined ILS Technology after working at IBM Corporation, where he was a global services manager responsible for architectures and deployments of electronic production solutions. Mr. Keever has accumulated over 18 years of factory automation experience at IBM and is the former Global Head of Development and Support for Automation Connection, Distributed Applications Environment, PlantWorks and Data Collection hardware and software products. His previous experience with IBM includes marketing and solution architecture responsibilities for General Motors, BMW, Chrysler, Tokyo Electron, Glaxo-Wellcome and many other global manufacturing companies. He holds a BA in Mechanical Engineering from North Carolina State University, an MA in Mechanical Engineering, with minors in Electrical Engineering and Mathematics, from North Carolina State University. He also completed graduate studies in computer engineering and operating systems design at Duke University. I have always been passionate about mechanical, electrical and computer engineering, having pursued them in my bachelor’s and master’s degrees. Founding my own company, ILS Technology, and working for a global IoT enabler like Telit has given me valuable insight into the business and technical aspects of IoT and technology that I would like to share with the ReadWrite community. . In addition to starting my own business, I have over 30 years of automation software engineering and design experience and 18 years of factory automation experience with IBM. This experience, coupled with a Masters in Mechanical Engineering, gives me the foundation and knowledge to bring valuable information to ReadWrite audiences that can help improve their technical knowledge and share new insights into legacy practices. ReadWrite strives to produce content that promotes reader productivity and provides quality information. With 30 years of experience in engineering and designing automation software and 18 years of experience in factory automation with IBM, I believe I have the foundation and knowledge to bring valuable and quality information to the audience of ReadWrite, who will not only help improve their technical knowledge, but also share new ideas about legacy practices.

LEAVE A REPLY

Please enter your comment!
Please enter your name here