Monthly Archives

December 2019

LF Edge Member Spotlight: IOTech Systems

By Blog, EdgeX Foundry

The LF Edge community is comprised of a diverse set of member companies that represent the IoT, Enterprise, Cloud and Telco Edge. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source edge solutions. Today, we sat down with Andy Foster, Product Director, at IOTech Systems to discuss the importance of a growing ecosystem, their IoT framework, the impact LF Edge has made and what the future holds for the company.

Can you tell us a little about your organization?

IOTech’s vision is to build and deploy the pervasive secure, open IoT software platform for edge environments that helps drive innovation, global adoption, market velocity and scale.

The company is leveraging an open source strategy based on the LF Edge’s EdgeX Foundry project to accelerate growth of a global partner ecosystem and dramatically increase deployment velocity of IoT systems by reducing custom systems integration. The EdgeX project is aligned around a common goal – the simplification and standardization of the foundation for edge computing architectures in the IoT market.

IOTech is supporting the rapidly growing EdgeX global developer community and partner ecosystem by providing a fully commercialized version of the EdgeX called Edge Xpert.

This licensed offering comes bundled with a range of industrial grade connectors to popular North and Southbound and is available on multiple hardware and OS combinations with regular software upgrades and different support and maintenance service level options. Complementary professional service offerings include training, pilot project support, accelerated product extensions and third party product integrations.

Additionally, IOTech has extended  EdgeX with its recently announced Edge XRT, the first “hard” real-time edge IoT platform.

Edge XRT is designed to meet the needs of industrial edge applications faced with one or more of the following key challenges: deployable on ultra-low footprint embedded edge nodes; latency and response times measured in microseconds; requirement for predictable real-time processing and execution.

Why is your organization adopting an open source approach?

IOTech’s core business execution strategy is to support an open source business model. We believe that this is the only model that can realistically facilitate rapid global scale out of this technology in the window of opportunity that exists, both in terms of removal of barriers to development, deployment and Time to Market (TTM) for new products and services. IoT is also fundamentally about managing heterogeneity we believe that the market is demanding an ‘open’ versus proprietary approach at the platform level, our customers ultimately want choice of best of breed, not to be tied to one vendor’s solution.

Why did you join LF Edge and what sort of impact do you think LF Edge has on the edge, networking, and IoT industries?

We believe that the best way to address market fragmentation and drive edge technology adoption is through industry collaboration and an open architecture approach. LF Edge is creating an ecosystem of companies focused on addressing the key challenges faced by the next generation of edge systems.

LF Edge membership is growing rapidly and includes a broad spectrum of companies from major international technology leaders to new startups. The breadth of membership and expertise is helping to ensure a cross-industry approach, with organizations working collaboratively to solve a common set of edge related problems. By avoiding duplication while at the same time ensuring interoperability and re-use across LF Edge projects is key to speeding time to market and reducing the implementation risk of new edge technologies. 

What do you see as the top benefits of being part of the LF Edge community?

Firstly, by collaborating with other organizations on the development new open source edge technologies allows companies to pool resources and leverage the collective expertise of many of the world’s leading technology providers. For IOTech, this has the significant benefit of enabling us to bring new products to market more quickly and share the costs of developing these solutions.

Secondly, LF Edge is helping to shape the future direction of edge computing and being part of the ecosystem gives IOTech the ability to help influence that direction, something that is much more difficult to do if we were not a member. It also gives us much better visibility into the where the industry and market is moving with respect to edge computing technologies, as well as access to some of the best brains driving this change.

Finally, being part of growing LF Edge  ecosystem provides IOTech with many commercial opportunities to partner with other member companies to collaborate on new projects and drive business growth.

What sort of contributions has your team made to the community, ecosystem through LF Edge participation? 

IOTech are one of the founder members of the EdgeX Foundry project and have been actively participating in the project at various different levels from it’s inception. We have made significant contributions in terms of technical leadership and code contributions within the project. Members of the IOTech team currently hold the following leadership positions within EdgeX:

  • Keith Steele, TSC Chair and LF Edge Board Member
  • Jim White, TSC Vice Chair
  • Iain Anderson, Device Service WG Chair
  • Robin Chatterjee, Test/QA WG Chair

We have leveraged our expertise in OT systems to work extensively on EdgeX’s Device Service layer. This work includes the development of SDKs in Go and C and the implementation of a number of protocol specific Device Services including Modbus, BACnet, OPC UA, MQTT and Virtual.

As TSC Vice chair and original EdgeX architect, Jim White has been active across all of the project’s WGs, providing technical leadership and support to the EdgeX teams.  For almost three years Keith Steele has been Chair of the TSC, helping to coordinate the projects direction and actively promote its goals and objectives within the EdgeX ecosystem and wider industry.

In addition to IOTech’s contributions to EdgeX Foundry we are also participating other complementary LF Edge projects such as the Akraino Time-Critical Edge Compute project where our EdgeX experience can be shared within the wider LF Edge ecosystems.

What do you think sets LF Edge apart from other industry alliances?

Put simply delivery focus! Other bodies are focused on producing guidelines and possibly new edge standards, whereas LF Edge’s objective is to produce open source solutions that can be deployed in real system or proven blueprints that can be used to support real edge use cases. 

How will  LF Edge help your business?

Firstly, the collaborative development that is inherent in a open source project is allowing  IOTech to leverage a far larger pool of development resources than is currently possible on our own. This is helping us to bring new edge solutions to market more quickly.

Working within an ecosystem of the world’s leading-edge technology companies ensures that the technologies that we develop are addressing the real needs of industry. It provides our customers with the reassurance that our products were developed with broad industry support, helping reinforce the importance of openness and choice.

Finally, from a marketing perspective the profile of LF Edge generates a lot of attention in our target markets and the efforts of the LF marketing team provides member companies with lots of opportunities to complement their own marketing programs and also share costs, for example by attending key industry tradeshows as a co-sponsor on the LF Edge booth.

What advice would you give to someone considering joining LF Edge? 

From IOTech’s perspective we’ve hopefully outlined the key benefits of joining LF Edge. We also think that these benefits will apply to most organizations. Our recommendation is to join, embrace collaboration and most importantly get involved. Your return on investment will be multiplied depending the effort you apply and the projects that you support. Where else can a company leverage the combined expertise in edge computing and resources of the LF Edge ecosystem, especially when combined with the many commercial opportunities for collaboration and partnering.

 

Node-RED and EdgeX Foundry

By Blog, EdgeX Foundry

Written by Odysseas Lamtizidis, EdgeX Foundry Technical Community Member

In this post we will be looking into the integration of two fundamental Open Source platforms for the Internet of Things.

The first being Linux Foundation’s EdgeX Foundry platform as the backbone of our system and Node-RED which will be used to simulate a Device Service.

But first things, first. What is Node-RED?

As we read from their website:

Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.

It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click.

Node-RED thus is an event-driven flow-based programming platform that is built on Node.js, leveraging it’s lightweight nature and extensive scalability to create applications mainly for the Internet of Things.

A flow-based programming language is a language where the application functionality is expressed as a series of black-boxes that are connected, creating a chain where the output of a box is the input of the next one. Each box receives a message, performs a certain functionality on it and then forwards it to the output and the next box.

Node-RED has various ready nodes (boxes), from creating http resources to converting the message to JSON or running an arbitrary user-defined javascript functions. Below we see an example of a flow as seen from the web editor.

Image X shows a flow in the node-RED web editor, where multiple nodes are defined and connected to create a certain application logic. The flows start with an MQTT listen node which will be triggered whenever an MQTT message is broadcasted in a certain topic.

The project was started from IBM’s Emerging Technology Services group and has a vivid community. You can find more information on the site and in the forums.

EdgeX Integration

As mentioned above, we will be using Node-RED as a custom device service, replacing the standard EdgeX Foundry device-sdk-go library which is used to develop custom device services.

A device-service is a “service” that defines and controls an array of IoT devices, but following the EdgeX micro-services architecture, a device-service as seen from the EdgeX system, is in essence a RESTful API.

Thus, by following the device-service specifications document, one can easily create the appropriate flows in Node-RED so that:

  1. The device-service properly registers itself to EdgeX
  2. The device-service has the necessary API resources according to the device-service spec
  3. The device-service performs arbitrary functionality to manage it’s devices

In our use-case implementation, we will be using Node-RED to introduce a proof-of-concept integration of a Lora-device, using the ChirpstStack (aka Loraserver) network stack and their application-level server. In essence, since the application server can not be directly integrated into EdgeX (different API structure), we will be using Node-RED service as a middleware, translating the EdgeX commands/API calls to Chirpstack’s application server and vice-versa.

Image XX illustrates the high-level architecture of the device service system we described, showcasing the use of Node-RED as a middleware for the 2 distinct RESTful APIs. The image is taken from an original work, please see #More Information.

Node-RED introduction

The development of an application in Node-RED is fairly simple, the user installs Node-RED using a deployment of choice (npm, docker, etc.), as detailed in the docs, and then access the web-editor at http://localhost:1880. The user then proceeds to select nodes and connect one to another. There are a handful of tutorials on the node-RED docs for the user to grab the gist of the platform, the learning curve is truly small.

After creating the flow, the user simply clicks “deploy” and the flow is activated by Node-RED. Node-RED is fairly customisable, enabling the change various aspects of the application, using the settings.js file. We invite the user to explore the documentation and the node-RED forum so as to gain better understanding of the capabilities of the platform.

An important aspect that is worth mentioning is the variable (context) storage mechanism (Context Store). The variables (flow, global) are normally stored in memory but in order to achieve persistency even at the event of a reboot, the user should enable the file-storage, as indicated in the docs. This will save the variables every X seconds in a JSON file, performing checkpoints of persistency. The interval can be reduced, but it can have an impact on performance, especially if we use a flash-storage (such as an sd card) which in the long-term will greatly stress the card.

EdgeX Foundry Registration

In order for the device-service to register with EdgeX, it simply has to perform a series of API calls to the EdgeX core-services, namely to core-data and to core-metadata, according to the EdgeX API walkthrough that is available at the EdgeX docs.

Disclaimer: Please note that the docs are somewhat outdated and the device addressable is no longer needed, the device resource is defined at the provisioning phase.

X2

The reference flow is shown in image X2. The main building blocks are the HTTP REQUEST node and FUNCTION node. For ease of use, for each http request, we define every attribute of the request (body, url) at the function node that proceeds each HTTP REQUEST node. This enables complete customisation and easy debugging for each node. For increased ease-of-use, we defined the majority of the bodies in a function at the start of the flow so we can easily modify common parts (like device name).

The bodies can either be saves as different attributes of the msg object or as flow variables that are loaded before each HTTP REQUEST node. The first is more memory efficient.

After a successful registration, a special flag is saved that is checked at the start of the flow so in the case of a service restart, the device-service will know not to repeat the registration. Moreover, the use-case flow lacks advance flow control mechanisms that will pause the registration in case of an error or controls that enable the device-service to restart registration from the last successful step.

At the moment, the PoC flow we simply restart from the start in case of restart. This is acceptable as EdgeX will simply ignore duplicate objects.

Regarding chirpstack, the registration subflow starts at the end of the EdgeX Registration flow. At some point in the registration, an endpoint is defined so that the Chirpstack application server makes an HTTP request at the Node-RED API endpoint, each time a value is received from the LoRa device. Node-RED receives that value and transforms the request to an EdgeX appropriate format in order to forward it to EdgeX-core-data service.

Device-service API resources

The PoC chooses to implement a subset of the available API specification and doesn’t support the addition of more than one device under the device service. The API conforms to the device specification where the reader can read in-detail the description of each resource.

The API structure is shown in image X1. Note that according to the EdgeX specs, the commands are issued to the device service using a this url structure: device/<device_id>/<command_name>, where device_id is generated at the device provisioning phase, while the command_name is defined at the device profile.

In order to support this structure, the API endpoint is set to listen for any url with the structure device/:variable_1/:variable2, and then proceeds to check the variables at the FUNCTION node that supersedes the HTTP endpoint node. Thus, the user can create a single endpoint to receive all the requests with the above structure and then differentiate depending on the variables.

Finally, the /health endpoint is used by the consul service registry. The user could implement a flow logic where errors are caught and saved into a flow or global variable so they can be used to generated the appropriate error code and message when the /health endpoint is used by consul. The PoC does not implements such a logic and the device-service is set to always as healthy in Consul.

Moreover, a command is defined, that simply returns the last read value from the lora-device.

Arbitrary Functionality

We could enable any kind of functionality, from running arbitrary shell commands on the system or entire program logic in FUNCTION nodes. In this PoC the device-service simply works as a middleware.

More Information:

The source-code for the above blog-post can be found on Github, it is part of a larger project where all the platforms that are described are presented in depth (such as ChirpStack aka Loraserver). The project’s document can be found on ResearchGate.

To learn more about EdgeX Foundry, visit the website or wiki.  Or, you can join the conversation and ask questions on our Slack channel.

This blog originally ran on Odysseas’ blog on Notion. You can view the original here