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. 

By Jim White, Co-Chair of the EdgeX Foundry Technical Steering Committee and CTO of IOTech Systems

Earlier this month, the EdgeX Foundry Technical Steering Committee (TSC) met in Phoenix, Arizona to finalize our Fuji release (due out at the end of this week – November 15^th) and scope the effort of our next release – code named Geneva – that we expect to release in the spring of 2020.  While officially this was a TSC meeting, we are an open project and always invite our developer community to participate in the discussions and planning effort whenever possible.

Hosted by Intel in downtown Phoenix, this season’s meeting was attended by more than 60 people in person and another dozen on line – our largest meeting yet.  Intel did a fabulous job of providing a great meeting space and allowing the community to enjoy the surrounds of the Phoenix area.  If they were responsible for the picture-perfect weather, they couldn’t have made it any nicer!  80 degrees and sunny each day.

Fuji is the community’s fifth release of EdgeX and a minor dot release (version 1.1) to our 1.0 Edinburgh release launched this past spring.  We have developed a well-established cadence that is two years in the making.  We have two releases a year (spring and fall) with the planning of the next release right on the heels of completed release.

If you are wondering what is in Fuji that is about to be released, the highlights of this release include:

• New and improved security services – fully integrated with existing micro services (API Gateway, secure storage)
• Application services and application functions SDK as full replacements for older export services (we expect to deprecate the export services with the next release)
• System management improvements to include ability to set configuration
• Improved testing and quality assurance procedures and tools
• Addition of an many more device services (actually to be released independently in mid-December with the device service SDK release).

The fact that Fuji is a dot release on top of our 1.0 release is an important.  As the project matures and stabilizes, more companies are building products on top of EdgeX and the community wanted to provide them with affirmation that EdgeX is fit for purpose without changing everything each release – while still adding new features in a way that supports backward compatibility.  Companies like IOTech, Beechwoods, RSA and others (see https://www.edgexfoundry.org/edgex-in-market/) continue to leverage EdgeX and need the stability in order to avoid lots of thrashing each six months.  ObjectBox is releasing their version of core EdgeX services (replacements for the EdgeX reference implementation of these services) that incorporate their embedded database with Fuji this month to coincide with the EdgeX release.  These are prime examples of the community that now rely on EdgeX Foundry.

Looking ahead – what’s in the Geneva release?  Based on our planning this past week, Geneva will be version 2.0 – a major release.  It will include many new features and some changes.  Specifically, the Geneva release will feature:

• Automatic and dynamic device/sensor provisioning and on-boarding – allowing for more zero touch deployments
• Interoperability testing – allowing the community and users to get a better appreciation that all the micro services are working together properly
• Replacing the reference implementation rules engine service – the last of the legacy EdgeX Java micro services (allowing the footprint of the overall system to be significantly reduced)
• Use of Redis as the default reference implementation database (replacing MongoDB)
• Improved security services (more secret store usage, per service token use, token revocation/expiration/rotation)
• User guidance on platform needs (more performance statistics, number of devices allowed per service/EdgeX instance recommendations, platform and hardware recommendations per edge use case)
• Exploration of an alternate message support (offering an alternative to Zero MQ)
• Archive of Export Services (the new Application Services and App Functions SDK taking its place)
• Use of Jenkins Pipelines to improve and enhance our CI/CD processes
• A refactor of the EdgeX APIs to provide more flexible and more nimble request and response bodies in the message exchange, which should improve testing and improve some performance aspects
• A number of system and sub-system designs are also forecast to be completed with this release. These designs are pre-cursor work toward the Hanoi (fall 2020) and beyond releases

It’s starting to look like winter outside in the northern hemisphere.  Holiday season right around the corner.  EdgeX is heating up.  Good time to stay inside and curl up next to EdgeX and try out the latest features and explore the future roadmap.  Come join the fastest growing open source edge platform project.

Written by Jason Shepherd, LF Edge Board Member

On October 7^th and 8^th, I had the pleasure of attending the inaugural EdgeX Open Hackathon in Chicago. EdgeX Foundry is focused on facilitating interoperability between devices and applications, regardless of underlying hardware, OS, and connectivity protocol. The project is ultimately about creating a de-facto standard open API that binds together a preferred mix of open source and commercial value-add.

Once EdgeX hit 1.0 status in June with the Edinburgh release, the community started planning the EdgeX Open Hackathon series for leveraging the framework in customer-valued use cases.

The inaugural EdgeX Open, hosted at the Tech Nexus coworking space in Chicago, hosted by LF Edge, EdgeX Foundry and RILA

Six teams participated in this inaugural event, representing HAVI, Intel/Intuiface, Johnson Controls, UST Global and Volteo in addition to a small independent team of registered individuals. Pre-work was allowed but a “secret ingredient” (Iron Chef-style) was introduced the day of the event to level the playing field a bit. In this case, it was a camera using Intel’s OpenVINO computer vision and image recognition model to output an object recognition algorithm to an API. Teams were able to earn extra points by integrating this technology into their solution stack.

Read on for how the hackathon went down!

Day 1:

The first day began with pitches from top sponsoring companies Dell, HP and Intel on what EdgeX Foundry means to the IoT market. Nicholas Ahrens of the Retail Industry Leaders Association (RILA) talked about the importance of innovation in retail and then Brad Corrion of Intel walked the teams through the objectives and introduced the secret ingredient.

Brad Corrion walking through the event rules

During my pitch, I had the pleasure of announcing that the EdgeX Foundry project recently hit a million total microservice downloads since the April 2017 launch. To get a sense of the accelerating momentum, half of these downloads occurred in the past two months!

With intros completed, the developers got to work. Most of the teams brought a plethora of devices to work with including cameras, sensors, scanners and a thermal printer and many had done some pre-work. Numerous developer attendees had never used EdgeX before and all were able to get the framework running quickly. Once the set-up was completed, they started with their integration of various devices and application stacks to build out their use cases.

Teams diligently working on their solutions

The participants had their choice of one of three use cases, or an open category:

1. Advanced loss prevention – leveraging EdgeX to correlate computer vision events with telemetry from sensors such as RFID and transaction log data from Point-of-Sale systems for improved loss prevention/theft detection
2. Dynamic personalized retail experience – leveraging computer vision and sensor data to drive an improved in-store customer experience based on individual shopper preference
3. Inventory management – using data from sensors and scanners (hand-held and/or drone-based) to improve inventory accuracy
4. Open category – any retail-centric use case deemed valuable by end users

While it appeared that most of the users picked the open category, the reality is that they did variants of the three main use cases. The teams wasted no time getting to work (actually many were working during the intro pitches…) and the room was bustling all day with activity.

From top (counter clockwise): Team Havi, Team Johnson Controls, Team Skanna

The UST Global team came up with an innovative solution for highly perishable food using Augmented Reality (AR) and RFID to enable grocery store associates to point a smartphone at fresh meat and produce displays to see products that are nearing or beyond the expiration date, i.e. “How fresh is the meat?” This would benefit the grocery store in terms of streamlining how they find, sort and discount expiring food, and benefit the consumer in terms of choosing between either the freshest products or benefiting from dynamic price markdowns or food nearing the expiration date. They came prepared, complete with props including fake chicken nuggets and lamb chops, making me hungry every time I walked by their table.

The UST Global team working on their solution for “How Fresh is the Meat?”

Day one wound down with a whiskey tasting which reminded me of the face-to-face TSC meeting in Edinburgh a year prior where we also ended the first day with a whiskey tasting. I sense a theme here!  Whiskey sommelier Anthony Dina selected three boutique whiskeys from the “edges of the earth” – one from a small batch distiller in the US, one from Scotland and one from New Zealand.

Whiskey from the edges of the earth

We then had some tasty Chicago deep dish pizza, followed by the “EdgeX Open Mic” – a community music jam.  Tony Espy (Canonical) and I worked up a variety of singalongs and managed to get a handful of folks belting out Neil Diamond’s Sweet Caroline and John Denver’s Country Roads, plus he and I did some pretty decent versions of Radiohead’s High and Dry and Jeff Buckley’s “Halleluiah”… especially considering this was only the second time we’ve played together (the first being an open mic night in Edinburgh during the Fall 2018 EdgeX F2F TSC).

Tony and I belting out the jams

Several folks came up to us afterwards and talked about how they played instruments spanning guitar to saxophone. At the next EdgeX Open, we clearly need to prepare more in advance and get a full band together, or perhaps we should just serve a little more whiskey beforehand! Or, both?

Day 2:

Day two started early with the teams continuing to build out their solutions unified by the EdgeX framework. Around 11am the judges we’re introduced – Eran Harel from AppCard, Nicholas Ahrens from RILA, Juan Santos from Tavistock Group, Mark Stutzman from Area 15, and Scott Gregory from HP. The judges subsequently spent time with each team to learn about their solutions before deliberating.

Hackathon Judges

Each team was then able to formally pitch to the judges and all participants in a final presentation that walked through their solution, what ingredients they used and how EdgeX was used for integration. The judges deliberated a bit more and then we had the closing ceremony, during which the winners were announced… and… drum roll… here they are!

The Intel/Intuiface team meeting with the judges

1^st Place – Team Volteo: An inventory management and loss prevention solution that used RFID sensors and networked cameras for accurate inventory management and to record door exit events by combining POS transaction data together with merchandise movement tracked by RFID sensors and cameras.

Team Volteo

2^nd Place – Team Intel/Intuiface: A predictive self-service checkout assistance solution that used RFID and computer vision to trigger an alert when a customer failed to scan items within a reasonable time and/or based on OpenVINO emotion detection during customer interaction with the kiosk.

Team Intel/Intuiface

3^rd Place – Team UST Global: An AR and RFID-based solution to track ultra-perishable goods in grocery stores and allow for dynamic pricing, e.g. how fresh is the meat? They developed an AR mobile app to scan food aisles and provide details on freshness, current price, etc.

Team UST Global

And this wasn’t just for bragging rights – 1^st, 2^nd and 3^rd place winners received $5000, $2500, and $1000 in cash respectively!  As co-founders of the EdgeX Foundry project, Jim White and I had the pleasure of handing out big checks during the award ceremony, summarily checking off a to-do on my bucket list!

Congrats to Team Volteo for winning the Grand Prize!

Thanks to our sponsors!

It has been an honor for me to participate in the EdgeX community over the years and this event was no exception. Big thanks to the LF Edge and the Retail Industry Leaders Association (RILA) for hosting the event, and to sponsors Canonical, Deep Vision, Dell Technologies, HP, Intel, IoTium and ZEDEDA who also provided their commercial offerings for the developers to use in their solutions as well as tech support on-site. Also, a shout-out to the planning committee which included volunteers from Dell, HP, IBM, Intel and the Linux Foundation.

EdgeX Foundry community leaders helped answer questions and more during the hackathon

Looking forward

The concept behind the EdgeX Open Hackathon is for it to be a global franchise series. Other markets in discussion for future events include manufacturing, smart cities, oil and gas, utilities/energy, agriculture, healthcare and beyond.

Stay tuned for more detail on the next installment, for which we also plan to include more about the overall LF Edge value prop by pulling from other enabling projects within the umbrella, combined with sponsor content. We’re thinking manufacturing in the Spring 2020 timeframe, likely aligned with an industry event such as Hannover Messe in a nearby town in Europe.

In the meantime, download EdgeX and build something great!

By Jason Shepherd, LF Edge Governing Board member and IoT and Edge Computing CTO, Dell Technologies

Founded in 1996, Technotects is an IoT technology consulting firm with broad domain expertise in industrial use cases. When one of their industrial equipment OEM customers independently realized the power of the EdgeX Foundry framework, Technotects planned and executed a Proof-of-Concept (PoC) with one of their customer’s typical process skid use cases.

This blog walks through the successful PoC, including what the solution entailed and Technotects’ experience working with the EdgeX platform. We’re seeing more and more of these types of real-world applications go public in the community on the heels of the EdgeX Foundry “1.0” Edinburgh release.

The use case

The use case for the PoC is monitoring sensor and pump information from a process skid used in a variety of applications, including agricultural, flavors and fragrances, pharmaceutical, petro-chem and food/beverage industries. Technotects’ goal of the effort was to prove that the EdgeX Foundry platform, combined with commercial value-add from the ecosystem, can provide an Internet of Things (IoT) solution stack that can address the unique interoperability challenges that industrial applications present, such as a mix of connectivity protocols and near real-time I/O processing, all while giving them the freedom of choice by being decoupled from proprietary, single-vendor solutions. In turn, this would allow their customers to improve their overall solution architectures, reduce runtime royalties and accelerate their time-to-market.

EdgeX-enabled Dell gateway utilized in the Technotects PoC

Technotects’ initial interest in EdgeX Foundry was the flexibility offered by the open ecosystem and the potential of reducing excessive runtime licensing fees per deployed host node, based on the combination of a proprietary edge application framework, edge historian and both southbound and northbound connectivity. In addition, they were attracted to the ability to make build-or-buy decisions with EdgeX without being locked into any specific choice for connectivity or applications value-add services.

The PoC basics

For the PoC, Technotects leveraged a Dell Edge Gateway 3002, Photon OS and VMware Pulse IoT Center, Edge Xpert from IOTech, RedisEdge from Redis Labs, Project Iris from RSA Labs, both AWS and Azure cloud platforms (hosting Redis for data backup) and a custom-built edge management console. Refer to the figure below for a block diagram of the setup and read on for more detail on how the effort came together.

IIoT Edge Stack Block Diagram for the Technotects PoC

Solution deep dive

For the EdgeX foundation of the stack, Technotects chose to work with IOTech’s Edge Xpert offering – a commercially-supported variant of the open source code that is available from the project GitHub within the Linux Foundation. Their use of Edge Xpert enabled them to focus on the integration with their customer’s preferred value-add software components rather than dealing with the open source code. They found IOTech’s documentation to be clear and the initial installation to be quick and straightforward – benefits when using a commercial variant that has additional hardening and packaging. Of course, using a commercially-supported variant versus simply downloading the open source code is a matter of personal preference.

EdgeX is completely neutral to OS, underlying hardware, protocol and programming language, and for this PoC, Technotects chose to leverage the Dell Edge Gateway 3002 and both Ubuntu from Canonical and Photon OS. Photon OS is an open source, container-optimized Linux distribution that has been nested within VMware’s vSphere offering for some time. Technotects was able to run their console, communication drivers, Edge Xpert and all the other referenced value-add software components in Docker containers in both operating systems, all without issue. They find that having the flexibility to deploy on any combination of hardware (x86 or ARM) and operating systems (Linux or Windows) in the field depending on customer need is valuable.

For southbound connectivity, Technotects leveraged a hybrid model. The process skids leverage a programmable logic controller for process control and for this PoC, Technotects used a commercially available Ethernet/IP driver to communicate with it. In turn, they connected this off-the-shelf, licensed driver package into the OPC-UA Device Service native to EdgeX. To connect to other devices on the skid, Technotects used the Modbus TCP protocol from IOTech’s Edge Xpert offer, written using the native EdgeX Device Service SDK. With the plug-in Device Service model, any combination of devices and protocols can be readily added in the future as needs evolve.

The solution architecture is a great example of both 1) how existing connectivity stacks can be used alongside native EdgeX Device Services in a hybrid model and 2) that in the EdgeX model, even connectivity written with the open EdgeX Device Service SDK can be monetized. Commercially-supported variants of EdgeX Device Services are likely to be attractive to end users with mission-critical use cases that involve bespoke and/or proprietary protocols in that support for this southbound connectivity often requires institutional knowledge gleaned from reverse engineering.

Meanwhile, end users can benefit from a growing number of open source Device Service options available within the community and increasingly Device Services that are supported by sensor makers for greenfield applications, coming with the sensor just like a keyboard comes with a driver for a PC. (Side note: There are numerous additional opportunities in development in the EdgeX ecosystem, although I must be sensitive to NDAs until they’re made publicly available). Net-net, the value of the open, vendor-neutral EdgeX ecosystem is in providing developers and end users with choices based on whatever is most valuable for their business.

Technotects leveraged VMware’s Pulse IoT Center to manage and monitor the underlying gateway hardware, OS and the EdgeX application framework above. VMware Pulse is a massively scalable, platform and application-independent solution for onboarding, managing, securing and monitoring IoT devices and gateways. System update campaigns can be applied in bulk and admins are alerted to any issues with their devices deployed out in the field, all in real-time. While VMware Pulse can be used standalone with its embedded device agent, it’s especially powerful when used in concert with the EdgeX framework. Any preferred console to manage applications and the underlying host system can be used with the EdgeX framework, with application-level functionality being enhanced by taking advantage of the EdgeX System Management Agent (SMA).

Technotects found the northbound connectivity to both Azure and AWS available in IOTech’s Edge Xpert to be very easy to configure. This highlights a key benefit of the EdgeX framework – decoupling investments in southbound data ingestion from any given cloud to enable choice over the long term, including realizing true-multitenancy from the edge. With the addition of support for multiple application services in the recent 1.0 Edinburgh release, data related to infrastructure monitoring and management can be sent to their management console of choice (in this case VMware’s Pulse IoT Center), whereas data related to the process for data analytics and taking action can be sent to any combination of on-prem or cloud-based application stacks of choice.

For local data persistence, Technotects chose RedisEdge over the MongoDB reference database that has been the baseline in the project until the recent 1.0 Edinburgh release. Technotects found it very easy to replace MongoDB with RedisEdge with no functionality differences, thanks to the work of Redis Labs in terms of making it an available plug-in within the EdgeX ecosystem. This is yet another example of how EdgeX is truly open and vendor-neutral, enabling users to leverage any enhancing functionality of their choice.

Finally, the PoC explored RSA Labs’ Project Iris active threat monitoring solution. Iris is a container that plugs into the EdgeX framework (and any other stack that supports containers) to profile baseline behavior for the stack and connected devices and then uses machine learning to detect anomalies. In turn Iris create alerts linked back to RSA’s popular Netwitness offering.

Conclusion

In closing, Technotects found EdgeX Foundry easy to work with and was able to successfully replicate their customer’s use case for process skid monitoring by leveraging the commercially supported framework from IOTech and value-add from Canonical, Dell, Redis, RSA and VMware. The flexibility to simply plug value-add into the open, vendor-neutral EdgeX foundation will provide both Technotects and their customers with more options in the future and help mitigate lock-in to proprietary edge platforms.

The EdgeX project has matured over the past two years to the current 1.0 state, and if you’re one of the thousands of end users that has been quietly prototyping with the platform, we welcome you to come forward and share your story on the project website through a blog or simple testimonial statement. The more people that come forward to share their success stories, the faster EdgeX will become the de-facto standard interoperability framework for the IoT Edge and the more we can all focus on innovation rather than reinvention!

Thank you for your time, and now’s your time to download the code or contact any of the providers in the ecosystem and build something great! Perhaps, as many have, even start your own business model around the EdgeX framework – just think of what Android did for scaling out an application and services ecosystem for mobile devices.

f you have questions or comments, visit the EdgeX Foundry Slack Channel and share your thoughts in the #community channel. Or, join the LF Edge Slack Channel and share your thoughts in the #EdgeX channel.

Snaps are self-contained application packages designed to run on any system that supports them. Each snap is a compressed SquashFS package (bearing a .snap extension), containing all the assets required by an application to run independently, including binaries, libraries, icons, etc.

Snaps are managed by snap, the command-line userspace utility of the snapd service. With the snap command, users can query the Snap Store, install and refresh (update) snaps, remove snaps, and perform many other tasks such as managing application snapshots, setting command aliases, enabling or disabling services, etc.

The EdgeX Foundry project publishes a  snap named edgexfoundry, which includes all of the EdgeX core, export, security and support services, Mongo/Redis, and all of the 3rd party runtime dependencies (Consul, Vault, Kong, …). Hackathon participants should use the version from the latest/stable channel in the Snap Store, which is the 1.0.1 release (Edinburgh). See the snap’s README for details. To install from latest/stable run:

sudo snap install edgexfoundry

After installing the edgexfoundry snap view the services by issuing the snap services command.

sudo snap services edgexfoundry

Notice that after running this one simple snap install command, all of the services required to runEdgeX will have been installed and are already running in the background on your system. Note which services are enabled and which are active by running the snap services command.

Upon installation, the following EdgeX services are automatically enabled:

• cassandra (persistent storage for Kong)
• consul (aka ‘the registry’)
• core-command
• core-config-seed (one-shot)
• core-data
• core-metadata
• edgexproxy (one-shot)
• kong-daemon
• mongod
• mongo-worker (one-shot)
• pkisetup (one-shot)
• sys-mgmt-agent
• vault
• vault-worker (one-shot)

Note – some of the above services are “one-shot” services which run once and then exit. These will show up as “enabled” but “inactive”.

The following services are disabled by default:

• support-notifications
• support-logging
• support-scheduler
• export-client
• export-distro
• device-virtual
• device-random

Any disabled service can be enabled and started using snap set. For example:

sudo snap set edgexfoundry support-notifications=on

To turn a service off (thereby disabling and immediately stopping it) set the service to off:

sudo snap set edgexfoundry support-notifications=off

On install, all services in a snap have corresponding systemd service units dynamically generated by snapd, thus if enabled, each will automatically start running when the system boots.

To keep things simple for EdgeX Open the security services in the edgexfoundry snap should be disabled by running:

sudo snap set edgexfoundry security-services=off

Currently, all log files for the snaps can be found inside $SNAP_COMMON, which is /var/snap/edgexfoundry/common. Additionally, logs can be viewed using the systemd journal or snap logs. To view the logs for all services in the edgexfoundry snap use:

sudo snap logs edgexfoundry

Individual service logs may be viewed by directly specifying the service name:

sudo snap logs edgexfoundry.consul

Once the EdgeX snap has been installed and the desired services have been successfully started, we are ready to set up an application service and a device service.

As a quick test the Mosquitto snap can be installed and a test topic can be published using the mosquitto_pub command. Use the following command to install Mosquitto:

sudo snap install mosquitto

Edgex-device-mqtt is a device service which supports importing device/sensor data readings via the MQTT protocol. It requires a running MQTT broker, as well as a peer MQTT application. The device service listens on a specific topic for incoming readings which it injects into EdgeX via the device service SDKs’ asynchronous readings feature. A peer MQTT application will be provided for the hackathon which will generate a steady stream of incoming readings related to the hackathon retail scenarios. This peer application will be setup to publish multiple scenario-specific streams on different topics. The device-mqtt service configuration provides a configuration value called “IncomingTopic” which can be used to change the topic the service listens on for incoming readings. Use the following command to install edgex-device-mqtt from the stable channel:

sudo snap install edgex-device-mqtt

After installation, check the status of the edgex-device-mqtt device service:

sudo snap services edgex-device-mqtt

Notice that the edgex-device-mqtt device service is disabled and inactive. This was done intentionally as the configuration and device profile need to be specific to each installation. You’ll find the configuration and device profile in the writable area of the snap (aka $SNAP_DATA):

/var/snap/edgex-device-mqtt/current/config/device-mqtt/res

After making the necessary modifications to configuration.toml (e.g. setting the “IncomingTopic” or changing “Port”) and mqtt.test.device.profile.yml (e.g. modifying device-resources, device-commmands, or core-commands), start and enable edgex-device-mqtt like this:

sudo snap start --enable edgex-device-mqtt

You should now be ready to receive peer MQTT application readings.

Now let’s publish a topic with a randfloat32 value of 1.2:

mosquitto_pub -t DataTopic -m '{"name":"MQTT test device","cmd":"randfloat32","randfloat32":"1.2"}'

You can check the readings from core-data with the following command:

curl -s localhost:48080/api/v1/reading | jq

Note – jq is a lightweight and flexible command-line JSON processor. In its simplest form with no command-line arguments specified, it simply outputs JSON its been given in a human-readable format. If not available on your system, it can be installed using sudo snap install jq.

If you see something similar to the following output then edgex-device-mqtt is working correctly. Float values are encoded base64 by default. The value “P5mZmg==” is 1.2 in base64.

[
   {
     "id": "4f922fd7-5c0d-48e0-8a06-6218d4c05fa9",
     "created": 1568926981304,
     "origin": 1568926981290,
     "modified": 1568926981304,
     "device": "MQTT test device",
     "name": "randfloat32",
     "value": "P5mZmg=="
   }
 ]

Once the device service has been started the configuration information is now in Consul. If you need to make further modifications to either the configuration or device profile, you’ll need to make the modifications in Consul which can be accessed from a browser at http://localhost:8500. After making modifications in Consul, the device service needs to be restarted like this:

sudo snap restart edgex-device-mqtt

If you would like to manage your EdgeX instance using a web browser, adding devices, device profiles, as well as visualizing data sent through the export service, you can do this through the EdgeX Web management UI. To install the edgex-ui-go snap run the following:

sudo snap install edgex-ui-go --channel=latest/beta

Now navigate with your browser to http://localhost:4000. The default user credentials are username: admin password:admin. Add your gateway and you’re ready to manage your EdgeX instance through the web UI.

Extending EdgeX

This section gives some hints as to how you can build your hackathon entry by creating or using additional EdgeX services.

App-Service-Configurable

Edgex-App-Service-Configurable – this is a new snap built from the current development release of EdgeX (Fuji). It allows a variety of use cases to be met by simply providing configuration (vs. writing code). For more information about this service, please refer to the README. As with device-mqtt, this service is disabled when first installed, as it requires configuration changes before it can be run. As with the device-mqtt snap, the configuration.toml file is found in the snap’s writable area:

/var/snap/edgex-app-service-configurable/current/config/res/

Profiles

In additional to base configuration.toml in this directory, there are a number of sub-directories that also contain configuration.toml files. These sub-directories are referred to as profiles. The service’s default behavior is to use the configuration.toml file from the /res directory. If you want to use one of the profiles, use the snap set command to instruct the service to read its configuration from one of these sub-directories. For example, to use the push-to-core profile you would run:

$ sudo snap set edgex-app-service-configurable profile=push-to-core

In addition to instructing the service to read a different configuration file, the profile will also be used to name the service when it registers itself to the system.

Note, as this service is based on the latest development release of EdgeX, not all use cases are supported, in particular integration with the EdgeX rules-engine will not work when used in conjunction with the Edinburgh release of EdgeX. Perform the following steps to install the edgex-app-service-configurable application service using the mqtt-export-configuration example and Mosquitto to test:

sudo snap install edgex-app-service-configurable

sudo snap set edgex-app-service-configurable profile=mqtt-export

sudo snap start --enable edgex-app-service-configurable.app-service-configurable

mosquitto_sub -t "edgex-events"

Multiple Instances

Multiple instances of edgex-app-service-configurable can be installed by using snap Parallel Installs. This is an experimental snap feature and must be first be enabled by running this command:

sudo snap set system experimental.parallel-instances=true

Now you can install multiple instances of the edgex-app-service-configurable snap by specifying a unique instance name when you install the snap. The instance name is made of the name of the snap plus a unique suffix which starts with the character “_”. This name only needs to be specified for the second and susbequent instances of the snap.

sudo snap install edgex-app-service-configurable edgex-app-service-configurable_http

or

sudo snap install edgex-app-service-configurable edgex-app-service-configurable_mqtt

Note – you must ensure that any configuration values that might cause conflict between the multiple instances (e.g. port, log file path, …) must be modified before enabling the snap’s service.

New Application or Device Services

Participants can also choose to construct their entry by building new device services (using the device SDKs) or new application services (using the application SDK). As the hackathon is time-boxed, most participants may just build new services natively vs. choosing to create Docker containers and/or snaps. For those interested in creating snaps for their new services, the following services can be useful as templates:

• edgex-device-mqtt (snapcraft.yaml)
• edgex-device-modbus (snapcraft.yaml)
• edgex-app-service-configurable (snapcraft.yaml)

What is EdgeX Foundry?

The EdgeX Foundry is a Linux Foundation project with the goal of providing an open and extensible platform for IoT edge computing. As a platform, EdgeX doesn’t try to solve business problems directly, but rather to provide a solid base for such a solution to be built using off the shelf components, provided by the EdgeX Foundry project or 3rd parties, which all interoperate using the same open APIs.

EdgeX is built as a collection of microservices which communicate with each other over a set of standard, open REST APIs. This design gives it a few  distinct advantages over other approaches to edge computing. First, it allows you to run the microservices on different machines, or even on different parts of the network. For example, you can run device controlling services on the devices themselves, with the data collection and processing services on a computer with more storage and CPU capability. This design also means that individual components can be substituted with alternative implementations that fill a specific need, without having to replace or modify any of the other services. Finally, it allows you to add new services that bring in new capabilities. The most common types of services to add into EdgeX are custom Device and Application services.

How EdgeX fits into a smart edge solutions

Every IoT project needs to address the difficulties of connecting multiple, disparate devices together and to controlling software, often over slow or unreliable connections. As such, managing that communication, providing fault tolerance, security, and near-device compute capabilities are a functions any successful IoT project must provide. This common plumbing is precisely what EdgeX Foundry provides.

By using EdgeX components in your solution, you get a mature, tested, stable foundation on which you can build your own value-add products or services.

• If you are building smart IoT devices, you can use EdgeX to connect to existing cloud offerings or datacenter software without having to build those connections into your device.
• If you are developing analytics, automation or other kinds of business intelligence software, EdgeX lets you ingest data from devices that speak any number of protocols and use many different data models, without having to build those translations and transformations yourself.
• If you provide custom deployments, EdgeX gives you an ecosystem of plug-and-play components that you can use to build up complex solutions quickly and reliably.

Running EdgeX in a development environment

You can build the EdgeX Foundry services using the open source code on Github, but more often than now you just need to get these services running so that you can connect your own services to them. To support that, the project publishes Docker images based on the latest stable release of the open source code, as well as docker-compose.yml files that will run all the necessary services together on your development machine.

1. Install Docker and Docker Compose
2. Download the latest stable docker-compose.yml file
3. Run `docker-compose up -d`
4. Verify that the services are all working with `docker-compose ps`
5. Test the APIs with http://localhost:48080/api/v1/ping

Once you have the EdgeX services running, you can take our Quick Start guide, or more in-depth API Walkthrough to get a feel for how EdgeX services work together.

Extending EdgeX to hardware with Device Services

In order to connect new devices to your EdgeX instance you will need to use a Device Service. These specialized services are responsible for communicating to devices over their own protocol, sending data from them into the EdgeX core-data service, and taking commands from the EdgeX core-command service and using them to control the device.

The EdgeX Foundry provides reference device services for a number of common IoT and smart device protocols, including MQTT, Modbus and plain HTTP, and you can use those pre-written services if your device supports those protocols. But if you need something more, the EdgeX Foundry Device SDKs make it easy for you to build a new device service capable of supporting your device.

Using either the Go or C SDKs, you can bootstrap a new Device Service that will already handle all of the setup and configuration for your new service, including uploading your Device Profiles into EdgeX core-metadata, provisioning any devices you have pre-defined, and scheduling automatic readings from your devices. The SDK also provides functions for calling all the common EdgeX APIs in a language-friendly way. All you have to do is add your device-specific connection and control code.

Training Tip: You can do end-to-end testing of your new Device Service by connecting your local EdgeX deployment up to a cloud service or NodeRed instance, and watch the readings flow in and commands go out.

Extending EdgeX to the cloud with Application Services

Since EdgeX Foundry itself doesn’t try to do anything other than efficiently moving data off the edge, you’re eventually going to want to send that data to some software for further processing. To do that, EdgeX provides a couple of ways to publish data to software running either on the edge, in a data center, or the cloud.

The first method is to use the pre-built Export Services, which are capable of sending data as JSON or XML over simple HTTP or MQTT to another service. This is a good option if you are using a service that already knows how to handle these common protocols, and can do any data transformations you need.

But if those aren’t suitable, the EdgeX Foundry also provides an Application Functions SDK for writing custom handlers, which can do anything from publishing data to a remote host, to performing local transformations, analytics and responses right from the edge. The SDK allows you to trigger you application functions whenever data comes into EdgeX, or on-demand, and even provides functions for publishing your data (via HTTP or MQTT) when you’re done handling it locally. Application Functions can even be chained together to build complex pipelines, reusing the same Application Functions in different ways.

Training Tip: You can do end-to-end testing of your new Application Service by connecting the Virtual Device Service to your local EdgeX deployment, which can simulate device data coming in.

Last month, EdgeX Foundry released its production ready Edinburgh release, which provides an open platform for IoT edge computing to a growing global ecosystem for a range of vertical markets including enterprise, industrial, retail and consumer. The fourth release in the EdgeX roadmap, the EdgeX Edinburgh release supports complementary products and services such as commercial support, training and customer pilot programs created by LF Edge members and contributors.

Now that EdgeX is “ready for primetime,” learn more about what contributors and users of the EdgeX Foundry platform had to say about the new release.

According to AWS, AWS, Dell Technologies, and the open-source EdgeX Foundry have collaborated to create IoT edge interoperability and simplify integration across inherently heterogeneous solution stacks. AWS customers can now seamlessly deploy AWS IoT Greengrass to the IoT edge within the EdgeX framework. The EdgeX framework enables data ingestion across connected devices and data sources for AWS IoT Greengrass and AWS IoT Core. This is further enhanced with plug-in value-add from the growing EdgeX and LF Edge ecosystems.

“AMD processors deliver the performance, advanced security features, and scalability to support the most demanding edge computing requirements, while providing breakthrough processing agility for x86-based IoT infrastructure. As a founding member of EdgeX Foundry, AMD continues to support a powerful and open ecosystem for interoperable IoT and edge compute solutions, that leverage the robust, scalable and open EdgeX framework.” – said Amey Deosthali, Director of Embedded Channel Applications, AMD

“HP joined the LF Edge project to help facilitate collaboration among industry-leading vendors and partners to solve common business problems. We are happy to see the Edinburgh production release by EdgeX Foundry to help support that objective. This release delivers commercial viability with increased stability and connectivity across a wide range of standards to reduce costs, complexity, and time to deploy. We look forward to seeing innovations at the edge that accelerate deployment of comprehensive retail use cases.” – Aaron Weiss, Vice President and General Manager, Retail Solutions, HP Inc.

“With the EdgeX Foundry Edinburgh Release, industrial IoT companies can easily integrate Mocana’s TrustCenter™ and TrustPoint™ cyber protection software solution to ensure the safety and reliability of industrial gateways and controllers. Mocana’s FIPS 140-2 validated device security software and security management platform enable companies to build and operate tamper-resistant products that protect the device, data, applications and communications. EdgeX and Mocana together help manufacturers and operators to accelerate compliance, ensure privacy, and protect the most complex industrial systems that run microservices, containerized applications, and hardware-based secure elements, such as the Trusted Platform Module (TPM).” – Keao Caindec, Head of Cyber Protection & Privacy, Mocana

“The production-ready EdgeX Foundry Edinburgh release provides important new capabilities for edge computing nodes.  The availability of an open, vendor-neutral source framework for connecting IoT devices to applications and cloud computing facilities is critical to the success of IoT and Edge processing efforts across multiple industries.” – Sam Fuller, Director of Strategy, NXP Semiconductors

EdgeX Foundry Hackathon

The EdgeX Foundry community is planning a series of hackathons focused on addressing real-world use cases with solutions built from commercial content from sponsors unified by the EdgeX framework.

The inaugural EdgeX hackathon will be hosted at Tech Nexus in Chicago on October 7 and 8. The event will focus on the retail market and work stemmed from the Commerce (e.g. Retail) Working Group within the EdgeX Foundry project and the related Open Retail Initiative (ORI).

Participating developers (from students to retail end users) will use their talents and creativity combined with the EdgeX framework, commercial content from sponsoring companies and the rules of the event to develop a solution for either one of the specified customer-valued retail use-cases or an additional open category.

Details about the competition, link to register and more will be available in the next few weeks. Stay tuned here for more.

Other supportive quotes:

“EdgeX Foundry is the key component of Beechwoods IoT gateway solution that allows our customers to engage confidently in edge computing technology. With the Edinburgh release, this solution will be ready to transition from customer engagement to product deployment.” – Brad Kemp, President, Beechwoods Software

“The Edinburgh release of EdgeX Foundry brings much needed standardization and stability for edge computing in production environments through an open source, common framework. The availability of the EdgeX Foundry snap enables developers an easy path to getting started with EdgeX Foundry, and benefit from confinement, easy integration into their own infrastructure, and automatic updates. In addition, this release introduces new device snaps providing integration with MQTT and ModBus.”- Loic Minier, IoT Field Engineering Director, Canonical

“As EdgeX Foundry reaches maturity with the Edinburgh release, CloudPlugs is excited to also announce the integration of the CloudPlugs IIoT platform with the open EdgeX ecosystem.  CloudPlugs IoT is a robust backend to deploy, orchestrate and manage EdgeX-compliant devices and micro service-based applications, as well as to manage and visualize field data. The EdgeX framework provides new levels of flexibility in field-level interoperability and the combination of EdgeX with CloudPlugs IoT delivers a powerful, end-to-end software and service stack to digitize assets and to deploy commercial and industrial IoT solutions at scale.” – Jimmy Garcia-Meza, CEO, CloudPLugs Inc. 

“Having started the EdgeX movement with a small team at Dell before contributing the code to the Linux Foundation, it’s certainly amazing to see the traction we’ve gotten through open, vendor neutral collaboration in a few short years. It’s a testament to the power of the network effect in the open source community which ultimately enables developers to focus on value rather than reinvention.” – Jason Shepherd, former chair of the EdgeX Foundry Governing Board and IoT and Edge CTO, Dell Technologies

“EdgeX Foundry provides an important software platform standardizing on the south bound IoT device connectivity and northbound data storage connectivity and allows vendors to plug in their core IoT capabilities in between. FogHorn is aligned with this data ingestion and publication standardization and will continue to collaborate as appropriate.” – Sastry Malladi, CTO, FogHorn

“The EdgeX platform offers HMS Networks a path to quickly build Industrial IoT solutions by providing predefined set of services for I/O functionality. HMS has created a J1939 service for EdgeX platform to help simplify IoT solutions for the commercial vehicle telemetry market. Ultimately, the EdgeX platform will significantly reduce the R&D investment required to create a majority of the Industrial IoT applications required in the market today.” – Tom McKinney, Director Engineering Services and Business Development, HMS Networks

“EdgeX Foundry is an important project arriving at the right time. It promises to connect devices to capabilities, and then get out of the way so you can run containerized workloads to generate insights, run model scoring, or detect anomalies… all at the edge. IBM is collaborating with EdgeX Foundry as part of our hybrid cloud strategy to help enterprises unlock the value of data from on-premises to the cloud to the edge.” – David Boloker, Distinguished Engineer, IBM

“EdgeX Foundry’s open source platform enables the industrial software ecosystem to integrate rapidly with ioTium’s managed services converged infrastructure offering – it’s microservices framework with open APIs is a powerful driver in the fragmented Industrial Control Systems market. ioTium enables rapid scalable deployment of the EdgeX Foundry framework globally.”- Ron Victor, CEO, ioTium 

“EdgeX Foundry provides an open framework for ease of design, development, & deployment at the Edge, while addressing stringent security,  privacy & compliance requirements. NetFoundry added its vendor-agnostic, connectivity-as-code solution to  EdgeX in order to enable developers and integrators to get similar ease of use, security and performance for their northbound application connectivity to core, clouds and service meshes. With the release of the EdgeX Edinburgh release, the EdgeX Foundry developer community has all the tools needed to deliver on market needs and ensure secure, agile innovation at the Edge” – Galeal Zino, CEO, NetFoundry Inc.

“As Digital Transformation for IoT gathers momentum, companies are demanding the same reliability, performance and security at the edge as they are used to getting from their Cloud Computing stack. With this release, EdgeX with Redis Labs RedisEdge not only delivers upon those expectations, but provides an ecosystem of open source technologies and plug-ins such as Redis Modules that help developers innovate.” – Dave Nielsen, Head of Community and Ecosystem Programs, Redis Labs

“EdgeX Foundry addresses the problem of the license stack at the IoT Edge constantly increasing in cost by providing a well architected, high performance, open source platform that can be used for industrial solutions today.” – Mike Malone, Vice President, Technotects, Inc.

“EdgeX Foundry’s global community ecosystem has experienced explosive growth, and the tangible advances delivered in the EdgeX  Edinburgh release are exciting developments for edge computing. We fully support EdgeX Foundry’s goals to establish an open interoperable framework for edge computing to provide developers with increased control over how, when, where and with whom they run their applications and manage their data. We look forward to continuing our contributions to the EdgeX Foundry community and related efforts in fostering open industry-wide innovation such as the Open Retail initiative.” – Mimi Spier, Vice President, Edge and IoT Business, VMware

“As a founding member of LF Edge, Wipro is proud to have contributed to the Edinburgh release. We will continue to actively participate as it is a key platform for delivering open, microservices-based, edge IoT applications for today’s interoperable distributed enterprise world.” – Andrew Aitken, general manager and global open source practice leader, Wipro Limited.

“ZEDEDA’s vision is to free cloud-native and legacy apps to run on any edge device anywhere in the world. This vision drives our support for EdgeX Foundry and its mission of promoting open interoperability between edge devices. We’ve made our virtualization solutions compatible with EdgeX releases because we believe they will have a central role in our industry’s future.” – Joel Vincent, VP Marketing, ZEDEDA

To learn more about the EdgeX Foundry Edinburgh release:

• Press Release: https://www.lfedge.org/2019/07/11/edgex-foundry-announces-production-ready-release-providing-open-platform-for-iot-edge-computing-to-a-growing-global-ecosystem/
• Technical blog: https://www.edgexfoundry.org/blog/2019/07/11/edgex-foundry-ready-for-prime-time/
• EdgeX Edinburgh release page: https://www.edgexfoundry.org/release-1-0-edinburgh/

• EdgeX documentation: https://docs.edgexfoundry.org/Ch-QuickStart.html

Written by Andy Foster, active member of the EdgeX Foundry technical community and Product Director at IOTech

For more information about EdgeX Foundry, visit the website here. To learn more about the other edge computing projects under the LF Edge umbrella, visit the website here.

Written by Akram Ahmad, EdgeX Foundry contributor and Principal Software Engineer at Dell Technologies

For those of you not yet familiar with the canonical way of introducing new technology-centric stuff, at least the way we do it in the world of computer programming–and thinking here specifically to the “Hello World!” first-ever program introduced to the world by programming legends Kernighan and Ritchie with their C programming language–please allow me to clarify what may be an admittedly enigmatic title we’ve got for this blog post. Essentially, it was with the EdgeX Foundry Delhi Release that the team had the pleasure of introducing EdgeX System Management capability to the world! Hence, “Hello System Management!” (More on the Edinburgh Release in just a bit.)

It’s my ongoing privilege to be a part of helping design, implement, and shepherd System Management (or “SM” for short) to date, and going forward. With that in mind, I would like to give you a flavor of the capabilities that SM brings to the table.

You can think of the System Management Agent (SMA), in particular, as a brand-new service which serves as the coordinator for control plane information (i.e. status, configuration, and metrics for EdgeX services). The SMA also control actions on EdgeX services (i.e. starting, stopping, and restarting services). Cloud or third-party systems can, in turn, call on the API provided by the SMA to trigger the actions or to get the control plane data they need. In a nutshell, the SMA can serve as a one-stop shop for managing a deployed instance of EdgeX.

Each EdgeX micro service has a corresponding management API that the SMA calls on to help control that service (e.g. to stop the service) or fetch its latest configuration or metrics. The SMA, along with the management API provided by each service, will be expanded in future releases of EdgeX and will one day offer control plane data and actions via alternate protocols (for example via the well-known protocol SNMP that is part of the TCP/IP suite that powers the Internet as we know it today).

I invite you to hold on to the thought that, for the constellation of services that will be offered via EdgeX, there needs to be “controller” of sorts…

Now, let’s turn to the truism that an IoT platform like EdgeX is used to collect the data from “Things.” Put another way, the platform ingests data that is physically sensed from IoT sensors and devices. Work associated with collecting, managing, and disbursing sensed data is exactly the kind of work associated with a “data plane.” On the other hand, the kind of work associated with operating and managing the IoT platform software and infrastructure is best described as “control plane” operations.

This includes getting the IoT platform and infrastructure running (or shutdown), configuring the platform software for the particular use case, and understanding the health and status of the software platform (is it running and what type of resources is the IoT software platform using?). Analysis of any control plane data may be used to take action as well, but action revolves around the IoT platform itself–not the sensed or controlled world. For example, in the control plane, it may be determined that a service needs to be restarted because it is consuming too much memory.

This is where the SMA comes in!

The System Management (SM) service will assist in protecting EdgeX and reducing the surface area of an API attack. Rather than opening up access to all services to the central management system, the SM service serves as a single point proxy to the control plane for all of EdgeX services for the central management system. The SMA, therefore, reduces the number of access points to EdgeX and reduces potential security vulnerabilities. It also allows the central management system to be loosely coupled to all of EdgeX—requiring the central management system to again have just one access address (the address of the SM service) that it needs to know about for any EdgeX deployment.

Before digging deeper, let’s recap what we’ve learned so far: System Management (SM) functionality, as determined by the EdgeX community, is generally associated with control plane data and operations.  The control plane (and System Management) is about managing the IoT platform and infrastructure. The data plane is all about managing and understanding the physical world that the IoT platform is there to observe and control. Think about it: Whether one is talking about towering skyscrapers or flimsy tents rigged on the grounds of a park, there remains, as ever, the crucial need for control. Without coordination, things can get chaotic in a heartbeat.

Also, and crucially, SM is also about providing information—having retrieved that information in the first place—about the status of the services it manages. Eventually, building on this capability, SM will provide the means to reconfigure the services themselves. At this time, with the Edinburgh Release, SM can provide performance and memory metrics for requested services. Likewise, SM can provide detailed configuration information for the services requested by users of SM, as well as the health status of those services (whether given services are up or down.)

In other words, while control is a critical capability, SM is about more than just control. By the same token, we want to make it abundantly clear that we are building System Management (SM) capability to facilitate other central systems, and not be those central systems. In a nutshell, EdgeX SM is about helping promote interoperability—in this case, allowing you to manage EdgeX with your choice in central management system.

Let’s shift gears a bit now: When you look at a typical fog deployment, a larger management system will want to manage the control plane of the edge systems as well as all the intermediate and upper level nodes and resources of the overall deployment. Just as there is a management system to control all the nodes and infrastructure within a cloud data center, and across cloud data centers, so too there will likely be management systems that will manage and control all the nodes (from edge to cloud) and infrastructure of a complete fog or IoT deployment.

If you will be so kind as to allow me the use of just one more metaphor, it will be this one: Think to a team of workhorses ploughing the land (EdgeX services). Then think to the driver (System Management). Finally, and without going too crazy about the farming metaphor—all metaphors, including this one, can carry only so much water—I invite you to imagine two scenarios (1) First, the one without the other, and (2) Second, the two (i.e. the team of workhorses and the driver) working in unison. If you associated chaos with the first scenario, and clockwork unison with the second, you are in good company.

So with the Edinburgh Release, we will continue building SM capability to facilitate other central systems. Again, the goal is not to be those central systems, but rather to facilitate those systems. May your System Management (SM) learnings continue, and may the community be the better for it!

If you have questions or comments, visit the EdgeX Foundry Slack Channel and share your thoughts in the #community channel. Or, join the LF Edge Slack Channel and share your thoughts in the #EdgeX channel.

A few weeks back, the EdgeX Foundry community released Delhi.  This release (the third public major release of EdgeX in a little more than a year) included many new features and I outlined them in my last blog post . Today, the project announced the availability of an enhanced Delhi release, with a smaller collection of new and updated capabilities built on top of Delhi.  

The Delhi code release offers so many new features, I’m not going to list them all. Instead, I’d like to focus on what’s new with this enhanced Delhi release.  In particular, the enhanced version of Delhi begins to allow for freedom of choice with regard to databases in EdgeX. With this release, several of the services (core data, metadata and export client specifically) have been engineered to use either MongoDB (the long used default persistence for EdgeX) or Redis. This improvement to the EdgeX platform is significant for several reasons:

• It highlights the ability for organizations to select and more easily use the data store that best fits their use case and system needs.  Platform support, performance characteristics, licensure issues, in-memory options, etc. are all architectural considerations when looking at persistence in your IoT platform.  
• It is the first step in providing proper abstraction and loose coupling around the persistence layer.  Eventually, this work which we hope will be completed for the Edinburgh release (April 2019) will allow architects more freedom to customize, extend, and replace this layer based on their persistence needs.
• EdgeX is all about providing interoperability, flexibility and facilitating choice at the edge – choice in sensor connectivity, analytics, cloud connectivity, deployment, etc. This new feature again showcases EdgeX’s flexibility – flexibility in persistence realm.  Future releases of EdgeX, using patterns established with this database abstractions, are looking at offering even more flexibility and interoperability in areas like messaging, security, communications, system management, etc.

The EdgeX community (which includes members of the Redis Labs team) worked throughout the Delhi release to simultaneously refactored several of the EdgeX microservices to offer Redis as embedded data services.  Specifically, this means we:

• Incorporated the EdgeX services with the tools needed to connect to databases such as Redis and MongoDB
• Leveraged Redis’ multi-model capability and data structures to serialize EdgeX data models for persistence, and index them for queries
• Decoupled the EdgeX models from a single persistence mechanism
• Solve identity issues, such as identifying sensor readings, in a database-independent way
• Added Redis to the EdgeX deployment/orchestration facilities
• Provided Redis initialization and bootstrapping scripts in support of EdgeX

Again, all of this work is important first steps toward more unilateral independence and choice with regard to persistence in EdgeX in future releases.

In addition to the work to provide alternate database connectors in several key EdgeX microservices, the enhanced Delhi code will also include the following:

• New device service connectors, created from the new SDKs made available for Modbus and MQTT.  These were device services created with the new Go and C Devcie Service SDKs that were made available with the Delhi release.  Device connectors provide the “thing” or sensor/device connectivity in EdgeX.
• A simple example device service simulator that developers can use to learn the EdgeX device service framework and speed up their development efforts.
• Additional and improved documentation that includes all the new features from the Delhi release.
• The EdgeX Foundry snap published in the the Snap Store (https://snapcraft.io/edgexfoundry) for the first time.

It should be mentioned that with the new Device Service SDKs, we are seeing a real escalation in EdgeX “thing” connectivity.  As I write this post, several additional Device Services have been created beyond what is offered in the “dot” release. So stay tuned to the EdgeX community outlets for more in this area coming soon.

Big shout out to the technical community for helping us achieve another technical milestone To learn more about the Redis connection, please click on this blog.

If you have questions or comments, visit the EdgeX Foundry Slack Channel and share your thoughts in the #community channel.

Guest post written by Geun-Yong Kim, EdgeX Foundry member and Researcher at ETRI

EdgeX Foundry member, ETRI (Electronics and Telecommunications Research Institute) exhibited the EdgeX-based gateway system at the 2018 Photonics Convergence Industry Road Show held in Gwangju, Korea, on November 20- 21, 2018. The Photonics Convergence Industry Road Show is an annual event that companies related to Korean photonics convergence showcase their products and technologies, share best practices and build a stronger network.

< ETRI booth at 2018 Photonics Convergence Industry Road Show >

ETRI’s Time-Sensitive networking IIoT gateway is based on the Go version of the EdgeX framework. It is equipped with hardware that can install a device module with legacy device interface such as RS-232/485, Modbus, etc. It also provides time synchronization accuracy of less than 300ns error for Time-Sensitive Networking, which is a new Ethernet standard that guarantees bounded latency of data transmission.

< ETRI TSN IoT Gateway collecting measured data from BMT Smarteye sensors>

Since BMT gateways collect data sequentially from Smarteye sensors, there was a limit to the data analysis. Therefore, ETRI developed the device that can acquire data from multiple RS485 interfaces at the same time and implemented a new Device Service of EdgeX Foundry to handle it. The ETRI gateway is able to collect 27 kinds of data from BMT Smarteye power measurement sensors. It also collects measured data from three Smarteyes simultaneously per second and the demo included collecting data, exporting data, and rules detecting from data.

Additionally, ETRI developed GUI optimized for EdgeX micro service structure, and users can easily install and delete micro services for gateway by GUI. ETRI has also developed the TSN micro service, rules engine for analyzing power measurement data for TSN networking function, and implemented the GUI to visually express data flow between micro services.

< Micro service management GUI >

< Data collection and graph from BMT Smarteyes >

ETRI will continue researching and developing industrial IoT gateways for the renewable energy industry and power utility sectors based on the EdgeX Foundry framework. For more information, you can email Geun-Yong Kim at gykim@etri.re.kr. 

If you have questions or comments, visit the EdgeX Foundry Slack Channel and share your thoughts in the #community channel.