Enabling and Integrating Constrained and Custom Hardware at the Edge

2 MINUTE READ
Greg Jones | August 25, 2017

It’s becoming increasingly difficult to integrate new sensors and small footprint hardware into broader systems or even the cloud. Under the constant pressure to develop lower cost solutions, there are often tradeoffs that leave devices operating as independent silos with limited compute stacks and interoperability. Examples include simple occupancy sensors, light sensors, equipment monitors with digital or analog I/O, or virtually any device running on extremely small footprint microprocessors. Some of these devices do not even have operating systems. In these situations, loading agents that require Java or other operating environments may not be possible.

Over my career, I’ve had to design products with very small processor footprints, developing software in low-level C code or in some cases Assembly language. Developing the operating code for the actual device can be a challenge, but getting that information to another system was always an even bigger challenge. It always sounds easy from the vendor but they may rely on specific operating systems or libraries that were not always available to us.

At MachineShop, we are focused on edge computing problems like this and enabling rich capabilities regardless of how constrained the various hardware components may be. Our platform runs on a wide variety of network-capable products using Linux and has been actively deployed in a host of environments. We have simple but powerful tools for ingestion of data over various higher level protocols like Modbus. The issue is that some of our customers don’t have the luxury of implementing these mostly heavyweight protocols.

Leveraging my experience working with small footprint devices, we took the approach of developing our own connectors in a variety of languages. These can be easily integrated with the OEMs own operating code. Code size, memory and processor power were all major considerations in the development of our SDK’s. To satisfy as many OEMs as possible, we developed SDK’s in the following languages:

· C++

· Python

· Go

· Java

· Groovy

Each of these SDK’s provides an interface that can be directly connected to a host operating the larger MachineShop Edge software platform. Interfacing to MachineShop Edge becomes just a configuration exercise and not a long process requiring the development of large amounts of code. Once the OEM’s device has been interfaced to MachineShop Edge, the business application has a host of tools it can utilize, including: data storage, local orchestration rules, direct interfaces to major IoT cloud services, and a host of other services. Using MachineShop Edge, the OEM’s device becomes an element in the platform that can be easily managed and controlled using standard RESTful API’s. Our Edge platform handles the conversion between the API and the protocols required to talk to the OEM device through our SDK.

As an OEM, this provides a pathway to upstream services while not burdening the device with additional licensing, development and support costs. It’s also possible that OEMs can operate their own service in collaboration with MachineShop. This would allow OEMs to offer rich, value added services that both increase revenue and decrease support costs.

We’ve made these SDK’s available publicly through our GitHub repository at MachineShop-IOT. Feel free to check them out and contact us to get a demo MachineShop Edge platform you can use to get started with MachineShop.

Topics: IoT, Device Management, edge intelligence, edge computing