Blog

Edge Computing at IoT Solutions World Congress 2019

Every year one of the world’s largest Internet of Things trade shows, IoT Solutions World Congress, is held in Barcelona, Spain. It brings together device manufacturers, service providers, AI & ML companies and solutions integrators from around the world to share information about their products and the state of IoT ecosystems. Filling multiple convention halls at the Fira Barcelona center, and featuring the biggest names in IoT and technology, you can spend days walking the expo hall and talking to vendors.

Crowd at the LF Edge Booth

This wasn’t the first time the EdgeX Foundry has had a booth at IOTSWC, but this year they were joined by other LF Edge projects, specifically Home Edge and Project EVE, to present solutions across the edge landscape. Our booth was staffed by project contributors from all over the world, from the US and Europe to India and Taiwan, and featured real world examples of the open source technology that is being developed under the LF Edge umbrella.  Not only did our members get a chance to learn about each other’s projects during this time, they were able to explain those other projects to the visitors to our booth. It was truly a community coming together to support and promote the LF Edge as a whole.

EdgeX Smart Building Demo EVE deployments on a wind turbine

We spoke with thousands of people over the 3 days of conference, and gave countless demonstrations. One notable change in conversations from a year ago is that most attendees we spoke to this year already knew and understood the importance of edge computing, and were looking for specific solutions to the problems that they are now facing. And while many vendors at the show offered some of these solutions, only the LF Edge projects offered open, vendor agnostic platforms that prevent lock-in and promote an ecosystem of 3rd party development around commonly developed core.

Selfie of the LF Edge booth staffIf you missed us at IOTSWC, you can join our projects online where we have a public Slack, mailing lists and host our meetings in the open. You can also look for us at events in 2020!

The Inaugural EdgeX Open Hackathon

Written by Jason Shepherd, LF Edge Board Member

On October 7th and 8th, 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

1st 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

2nd 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

3rd 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 – 1st, 2nd and 3rd 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!

 

End User Case Study: Monitoring industrial equipment using EdgeX Foundry

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.

An Akraino Developer Use Case

Written by technical members members of the Akraino Edge Stack project including Bruce Lin, Rutgers; Robert Qiu, Tencent; Hechun Zhang, Baidu; Tina Tsou, Arm; Ciprian Barbu, Enea; Allen Chen, Tencent; Gabriel Yang, Huawei; Feng Yang, Tencent; Jeremy Liu, Tencent ; Tapio Tallgren, Nokia; Cristina Pauna, Enea

More intelligent edge nodes are deployed in 5G era. This blog shares a developer use case out of the Akraino project that the community is working on, specifically Telco  Appliance Blueprint Family, Connected Vehicle Blueprint, ELIOT: Edge Lightweight and IoT Blueprint Family, Micro-MEC, The AI Edge Blueprint Family, and 5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint.

Telco Appliance Blueprint Family

Telco Appliance blueprint family provides a reusable set of modules that will be used to create sibling blueprints for other purpose tuned appliances.

Appliance model automates the installation, configuration and testing of:

  • Firmware and/or BIOS/UEFI
  • Base Operating System
  • Components for managing containers, performance, fault, logging, networking, CPU

The first blueprint integrated with TA is REC. Other appliances will be created by combining other applications with the same underlying components to create additional blueprints.

TA produces an ISO that, after being installed in the cluster, provides the underlying tools needed by the applications that come on top of it. The build of this ISO is automated in Akraino’s CI and it includes:

  • Build-tools: Based on OpenStack Disk Image Builder
  • Dracut: Tool for building ISO images for CentOS
  • RPM Builder: Common code for creating RPM packages
  • Specs: the build specification for each RPM package
  • Dockerfiles: the build specifications for each Docker container
  • Unit files: the systemd configuration for starting/stopping services
  • Ansible playbooks: Configuration of all the various components
  • Test automation framework

The image provides the following components, used during installation:

  • L3 Deployer: an OpenStack Ironic-based hardware manager framework
  • Hardware Detector: Used to adapt L3 deployer to specific hardware
  • North-bound REST API framework: For creating/extending blueprint APIs
  • CLI interface
  • AAA server to manage cloud infrastructure users and their roles
  • Configuration management
  • Container image registry
  • Security hardening configuration
  • A distributed lock management framework
  • Remote Installer: Docker image used by Regional Controller to launch deployer

The image provides the following components, usable by the applications:

  • CPU Pooler: Open Source Nokia project for K8s CPU management
  • DANM: Open Source Nokia project for K8s network management
  • Flannel: K8s networking component
  • Helm: K8s package manager
  • etcd: K8s distributed key-value store
  • kubedns: K8s DNS
  • Kubernetes
  • Fluentd: Logging service
  • Elasticsearch: Logging service
  • Prometheus: Performance measurement service
  • OpenStack Swift: Used for container image storage
  • Ceph: Distributed block storage
  • NTP: Network Time Protocol
  • MariaDB, Galera: Database for OpenStack components
  • RabbitMQ: Message Queue for Openstack components
  • Python Peewee: A Python ORM
  • Redis

Radio Edge Cloud (REC)

Akraino Radio Edge Cloud (REC) provides an appliance tuned to support the O-RAN Alliance and O-RAN Software Community‘s Radio Access Network Intelligent Controller (RIC) and is the first example of the Telco Appliance blueprint family.

  • RIC on Kubernetes on “bare metal” tuned for low latency round trip messaging between RIC and eNodeB/gNodeB,
  • Support for telco networking requirements such as SRIOV, dual POD interfaces, IPVLAN
  • Built from reusable components of the “Telco Appliance” blueprint family
  • Automated Continuous Deployment pipeline testing the full software stack (bottom to top, from firmware up to and including application) simultaneously on chassis based extended environmental range servers and commodity datacenter servers
  • Integrated with Regional Controller (Akraino Feature Project) for “zero touch” deployment of REC to edge sites
  • Deployable to multiple hardware models

In Akraino, the work on this blueprint will fully automate the deployment and testing on multiple hardware platforms in a Continuous Deployment system.

SDN Enabled Broadband Access (SEBA):

Here is SEBA user story.

As a Service Provider, I want to setup SEBA environment so that I can use ONF SEBA platform.

As an Administrator, I want to validate HOST OS environment so that I can install Kubernetes/SEBA.

As an Administrator, I want to validate Software environment so that I can install Kubernetes/SEBA

As an Administrator, I want to validate Virtual Machines for my Kubernetes/SEBA environment so that I can validate environment

As a Administrator, I want to validate services for my Kubernetes/SEBA environment so that validate working environment

SEBA validation on ARM – IEC Type 2

SEBA stands for SDN Enabled Broadband Access. It is an ONF/Opencord project which implements a lightweight platform, based on R-CORD. It supports a multitude of virtualized access technologies at the edge of the carrier network, including PON, G.Fast, and eventually DOCSIS and more.

SEBA is also an Akraino Blueprint, but in the context of the IEC Blueprint, the SEBA usecase is deployed and verified on an IEC Type 2 platform. IEC is also the main Akraino sub-project/blueprint which enables ARM architectures for Telco/Enterprise Edge applications.

For the purpose of validating SEBA on IEC Type 2, a SEBA compliant ARM64 lab has been setup at the Akraino Community Lab at the University of New Hampshire (UNH). The lab consists of two development PODs, using Marvel ThunderX2 networking processor equipped servers and Ampere HR330A servers.

The connectivity is provided by Edgecore 7816-64X TOR switches which fulfill the role of Fabric Switches in the SEBA Architecture.

For the validation work we have first ported and deployed BBSim on IEC for ARM64 and right now there is ongoing work for porting and verifying PONSim.

PONSim is also a central piece of SEBA-in-a-Box (SIAB) which is one of the main testing CI/CD projects in upstream Opencord Jenkins infrastructure.

There is ongoing work in Akraino IEC for replicating the SIAB setup by utilizing the same testing environments and facilities provided by Opencord.

Finally, recent collaboration with Opencord resulted in forming a Multiarch Brigade with the purpose of making SEBA seamlessly work on multiple architectures apart from the x86 servers. So far there has been some evident interest from the community and other parties for enabling multiarch support and perpetual verification in a CI/CD manner by adapting the Opencord infrastructure to support other architectures and ARM64 in particular.

Connected Vehicle Blueprint

Connected Vehicle Blueprint focuses on establishing an open source MEC platform, which is the backbone for V2X application.

From use cases perspectives,  the following are the use cases we have tested in our companies. More is possible in the future.

  • Accurate Location: Accuracy of location improved by over 10 times than today’s GPS system.Today’s GPS system is around 5-10 meters away from your reallocation, <1 meter is possible with the help of Connected Vehicle Blueprint.
  • Smarter Navigation: Real-time traffic information update, reduce the latency from minutes to seconds, figure out the most efficient way for drivers.
  • Safe Drive Improvement: Figure out the potential risks which can NOT be seen by the driver.
  • Reduce traffic violation: Let the driver understand the traffic rules in some specific area.For instance, change the line prior to narrow street, avoiding opposite way drive in the one way road, avoiding carpool lane when single driver etc.

From technology architecture perspective,  the blueprint consists of four major layers.

  • Hardware Layer: Connected Vehicle Blueprint runs on top of community hardware. Both Arm and x86 server are well supported.
  • IaaS Layer: Connected Vehicle Blueprint can be deployed in virtual environment as well.  Virtual Machine , Container as well as other IaaS mainstream software(like openstake, kubernates et al)  are supported.
  • PaaS Layer:Tars is the microservice framework of Connected Vehicle Blueprint. Tars can provide high performance RPC call, deploy microservice in larger scale-out scenario efficiently, provide easy-to-understand service monitor feature.
  • SaaS Layer: The latest v2x application depicted in upper use cases perspective.

From network architecture perspective,  the blueprint can be deployed in both 4G and 5G network. Two key points should be paid special attention to. One is offloading data to edge MEC platform.  The policy of data offload is configurable based on different applications.  The other is the ability that letting the edge talks to the other edges as well as remote data center. In some use cases, date process in one edge can NOT address the application’s requirements. We need to collect the data from different edges and figure out a “conclusion” for the application.

ELIOT: Edge Lightweight and IoT Blueprint Family

ELIOT AIoT in Smart Office Blueprint

This blueprint provides edge computing solutions for smart office scenarios. It manages intelligent devices, delivers AI training models and configures rules engine through cloud-edge  collaboration.

Services provided by cloud side:

  • Devices management
  • AI models training and deliver
  • Rules engine configuration
  • Third-party applications

Services provided by edge side:

  • Sending/Receiving devices data
  • Data analysis
  • AI models/Functions execution

Deployment environment:

  • Kubernetes
  • Container
  • VM
  • Bare Metal

Recently, we are still developing this project and Tencent will keep devoting great efforts to the research and development of this blueprint. In the near future, the project will also be open source. Any partners interested in this project are welcome to contact us and let’s work together to promote the application of edge computing in the field of smart office.

The AI Edge Blueprint Family

With this blueprint, teachers and school authorities could conduct a full evaluation of the overall class and the concentration of individual students, helping to fully understand the real time teaching situation. According to the concentration data of each course, teachers and school authorities can conduct knowledge test and strengthen.

The AI Edge Blueprint mainly focuses on establishing an open source MEC platform combined with AI capacities at the Edge, which could be used for safety, security, and surveillance sectors.

5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint.

The purpose of the blueprint is to offer a 5G MEC networking platform to support delay sensitive, bandwidth consuming services, such as cloud gaming, HD video and live broadcasting. In addition, network slicing will be utilized to guarantee excellent user experience.

As a service provider of cloud gaming, I want to set up a computing platform to execute game rendering as well as video encoding, and deliver the compressed video to the player via a 4G/5G network.

As cloud gaming is sensitive to latency, the computing platform is required to be as close as possible to the network edge. Besides that, a mechanism to discover the service and direct players’ traffic to the platform is demanded.

To direct players’ traffic to the platform, I install an edge connector which is responsible for enabling flexible traffic offloading by interacting with EPC or 5GC, and subscribing the edge slice, which provisions a certain level of QoS between UE and edge application.

To interface with the user plane of 4G or 5G, I install an edge gateway (GW). In 5G SA, the edge GW is connected to a UPF, to manage the traffic from the mobile network. In 5G NSA or 4G, the edge GW is connected to an eNB or SGW, with an additional function of handling GTP-U, the tunneling protocol adopted by 4G and 5G.

When a player accesses a cloud gaming service hosted on the platform, the edge connector will establish an appropriate route between the mobile network and the edge GW. The compressed video and the player’s control data will be transferred between the gaming server and the user equipment, traversing the edge GW.

As a service provider of live broadcasting or HD video delivery, I want to set up a platform to transcode the video source to fit the bandwidth of the transport.

Similar to the cloud gaming use case, an edge connector is installed to direct the traffic to the computing platform, and an edge GW is installed to manage the mobile traffic and terminate GTP-U under 4G or 5G NSA. The computing platform will transfer the format of the video to be adapted to either the wireless link towards the mobile user or the transport towards the internet. The computing platform may be connected to a CDN to optimize the live broadcasting or HD video delivery.

Micro-MEC (µMEC)

 µMEC is a low-power, low-cost server at the edge of the network that supports Smart City use cases with different sensors (including cameras), is connected to Internet and telco networks, and allows third-party developers to create ETSI MEC applications to it.

So the µMEC focuses on Smart City use cases. If you had different smart sensors in a city, collecting data that is available for free, what could you make possible? That was the challenge that we gave in a developer hackathon in May. We used the Akraino uMEC platform and created a model city. Different sensors collected information and made it available through a database.

 

For the next hackathon, we want to make it very easy for developers to create applications that run on the µMEC device itself. For this, we are implementing ETSI MEC compliant interfaces and leverage the OpenFAAS serverless platform.

The µMEC platform that we are developing in Akraino will have a trusted computing stack, from trusted hardware to secure networking and signed containers.

Akraino will be hosting a MEC Hackathon on November 18 at Qualcomm. For more information or to register, visit the Akraino MEC Hackathon wiki.  For more informations about Akraino or blueprints, click here.

EdgeX Open Hackathon & Snaps

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:

Running K8s Conformance Tests in Akraino Edge Stack

By Cristina Pauna, Bin Lu, Howard Zhang

Due to the large scale f its projects and various application scenarios, Akraino Edge Stack is complex when it comes to testing logistics;  normal integration or unit tests are not enough for testing the projects. To ensure that the full deployment is both functional and reliable, it needs to be tested at all layers of the stack, from hardware to application. To verify deployments based on Kubernetes at the platform layer, K8s conformance is a good way to do this job.

The k8s conformance tests are used in the CNCF vendor  Certified Kubernetes program. It integrates end-to-end (e2e) testing in Kubernetes which contains a wide range of test cases, and passing them proves a high level of common functionality of the platform.

K8s Conformance Tests in Akraino

General testing in Akraino is done using the Blueprint Validation Framework. The framework provides tests at different layers of the stack, such as hardware, operating system, cloud infrastructure, security, etc. Each layer has its own container image built by the validation project. The full list of images provided can be found in the project’s DockerHub repo. The validation project has an multi-arch approach. All images currently support both x86_64 and aarch64 architectures, and can be easily extended to other platform architectures in the future. This is implemented using docker manifest list so the same image name is used to pull regardless of the architecture of the System Under Test. Therefore the steps described in this article apply regardless of the architecture of the SUT.

The Kubernetes conformance tests are included in the k8s layer. The test suit can be run in a couple of ways, either by directly calling the e2e tool or though sonobuoy, which is a diagnostic tool that gathers logs and and stats in one archive. Regardless of how the tests are ran, it is possible to customise what test cases are included, which versions and even the container images within the tooling.

In Akraino, the conformance suite is run from a separate container, using the validation image built for the k8s layer: akraino/validation:k8s-latest. This image contains all of the tooling necessary for running tests on the k8s layer in Akraino, as well as the tests themselves. The tools that go into the image can be found in its Dockerfile. The container is designed to be started on a remote host that has access to the k8s cluster. Check the validation project User guide for more information on the setup.

The conformance suite is customized using the sonobuoy.yaml file. Some of the images used by sonobuoy in Akraino are built by the validation project in order to customize them to fit the community’s needs (e.g. akraino/validation:sonobuoy-plugin-systemd-logs-latest is based on the official gcr.io/heptio-images/sonobuoy-plugin-systemd-logs:latest but with added aarch64 support).

Prerequisites

Before running the image, copy the folder ~/.kube from your Kubernetes master node to a local folder (e.g. /home/ubuntu/kube) that will later be mounted in the container. Optionally, the results folder can be mounted in order to have the logs stored on the local server.

Run the tests

The Akraino validation project has a variety of tests for the k8s layer. To run just the conformance tests, follow the steps below:

  1. Clone the validation repo.
  2. Create a customized blueprint that will be passed to the container. The blueprint will contain just the conformance suite in it, like in the example below.

3. Fill in volumes.yaml file with the data that applies to your setup. The volumes that don’t have a local value set will be ignored. Do not modify the target part of each volume. These paths will be automatically created inside the container when started, and are fixed paths that the tools inside the container expect to exist as is.

In the example below, only the following volumes are set:

  • Location to the kube config files needed for access to the cluster
  • Location to the customized blueprint file
  • Location to where to store the results

4.  Run the tests

To run the tests, the blucon.py command is used which needs the name of the blueprint as input. The full suite takes around one hour to run, depending on the setup.

The sonobuoy containers can be seen running on the cluster on the heptio-sonobuoy namespace.

Get the results

The results are stored inside the container in the /opt/akraino/results folder. If a volume was mounted to this folder (e.g. /home/ubuntu/results) then they can be viewed from the host where the test was ran.

The results can be viewed with a browser, using the report.html file that the robot framework provides. In case of failures, the sonobuoy archive can be used to inspect all the logs.

 

EdgeX Open: Training

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 MQTTModbus 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.

EdgeX Foundry Contributors and Users Share Thoughts on the Edinburgh Release, the Growing Ecosystem and more!

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:

Building Automation: A Sweet Spot for EdgeX Foundry

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

The key objective for LF Edge’s EdgeX Foundry is to create a flexible and open edge computing IoT platform that can support a range of different vertical use cases across markets such as manufacturing, oil & gas and smart energy. A key vertical market that has emerged for the community and IOTech, in particular, has been involved in multiple projects is Building Automation.

Why is Building Automation proving to be such a sweet spot for EdgeX? In our experience, the requirements of the next generation of Building Automation applications align perfectly with the capabilities of EdgeX.  In particular, a modern building is a sophisticated and heterogeneous environment consisting of diverse subsystems including lighting, HVAC and access control. Data can be generated from multiple sources using a range of different device/sensor technologies and protocols (e.g. Modbus, BACnet, DALI, MQTT and others).

The sensor data must be normalized by the IoT platform running on an Edge node e.g. an industrial Gateway or on-premise server. The data can then be fed into the building management analytics which can make smart control decisions in “near” real-time on how to automatically optimize the building environment for the benefit of the users and also the building owners.  As an open source project, EdgeX Foundry (can support any “Southbound” OT protocol or “Northbound” Cloud endpoint) and its platform independence (not tied to a specific operating system or hardware/silicon) is key to its suitability for Building Automation use cases. Most importantly, EdgeX also provides “out-of-the-box” connectivity for a number of the protocols most commonly required in a smart building system. As of the most recent EdgeX Edinburgh release the list includes Modbus, BACNet, MQTT and OPC UA Device Services.

The below video showcases the demo created by IOTech on behalf of the Linux Foundation to highlight the key capabilities that make EdgeX a great choice of Edge IoT Platform for use in Building Automation applications. It shows the integration of multiple devices commonly found in commercial buildings (light and temperature sensors, HVAC controller, DALI lighting controllers, power meter and access control system). Based on occupancy data, the Edge Analytics automatically regulates the building environment, controlling the light levels and HVAC settings in multiple independent zones based on the ambient light and temperature readings from each zone. Overall power consumption of the building is also monitored and key data streams are exported to a Big Data application running on AWS Cloud.

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.

Using DockerHub in Akraino Edge Stack & Other Linux Foundation Projects

By Kaly Xin, Eric Ball,  and Cristina Pauna

DockerHub is the world’s largest library and community for container images. It offers a huge repository for storing container images and it is available world wide. It can automatically build container images from GitHub and Bitbucket and push them to Docker Hub. These are just a few of the features it provides, but maybe one of the best features is that it offers seamless support for multi arch images through fat manifest.

Why Docker Hub is recommended for Multi-Arch

Docker Hub registry is able to store manifest list (or fat manifests). A manifest list acts as a pointer to other images built for a specific architecture thus making it possible to use the same name for images that are built on hardware with different architectures.

Figure 1: Docker registry storing amd64, arm64 images and their fat manifest

In the picture above akraino/validation:k8s-latest is the fat manifest, and its name can be used to reference both images akraino/validation:k8s-amd64-latest and akraino/validation:k8s-arm64-latest. Inspecting the manifest offers the details on what images it has, for what hardware architecture and what OS.

Figure 2: Docker fat manifest details

How does it work?

When building an image for a specific arch, the arch is added in the tag of the image (akraino/validation:k8s-amd64-latest and akraino/validation:k8s-arm64-latest).

After the images are pushed in the Docker Hub repo, the manifest can be created from the two images. Its name will be the same as the two images but with the arch removed from the tag (akraino/validation:k8s-latest).

To do this in CI with Jenkins, the Jenkins slave has to have docker and a couple of other LF tools installed. The connection to Docker Hub is done through LF scripts (see releng-global-jjb for more info) and all you need to do is define the jjb jobs .

The Akraino validation project is already pushing to Dockerhub, so if you would like to check out some template code, take a look at ci-management/jjb/validation. The docker images are pushed in the official repo and the docker build jobs are running daily. 

In the figure below, the main Jenkins job (validation-master-docker) triggers two parallel jobs that build and push into the Docker Hub registry the amd64 (akraino/validation:k8s-amd64-latest ) and arm64 (akraino/validation:k8s-arm64-latest ) images.  At the end, the fat manifest (akraino/validation:k8s-latest ) is done in a separate job. 

When pulling the image, the name of the manifest is used  (akraino/validation:k8s-latest); the correct image will be pulled based on the architecture of the host from which the pull is made.

Figure 4: Pulling a docker image from two different hardware architecture servers using the same name

What’s next

Docker Hub has been integrated in LF projects like OPNFV from the beginning and is now integrated in Akraino too, so other open source projects can refer to this successful experience to integrate Docker Hub in their pipeline.

What to Expect from the Open Glossary of Edge Computing in 2019

By Alex Marcham, LF Edge and State of the Edge Contributor and Technical Marketing Manager at Vapor IO, and Matt Trifiro, Co-Chair at State of the Edge; Chair at Open Glossary of Edge Computing and CMO at Vapor IO

The Open Glossary of Edge Computing began as a utilitarian appendix to the 2018 State of the Edge report. It had humble goals: to cut through the morass of vendor- and pundit-driven definitions around edge computing and, instead, deliver a crisply-defined common lexicon that would enhance understanding and accelerate conversations around all things edge.

Very quickly, it became clear that the Open Glossary could be a powerful and unifying force in the fledgling world of edge computing and that no one entity should own it. Instead, everybody should own it. Thus began our partnership with The Linux Foundation. We converted the glossary into a GitHub repo, placed it under a Creative Commons license, and created an open source project around it.

In January 2019, the Open Glossary became one of the founding projects of LF Edge, the Linux Foundation’s umbrella group for edge computing projects. The Open Glossary now plays a critical role that spans all of the LF Edge projects with its mission to collaborate around a single point of reference for edge computing terminology. This community-driven lexicon helps mitigate confusing marketing buzzwords by offering a foundation of clear and well-understood words and phrases that can be used by everyone.

In 2019, the momentum of the Open Glossary project will continue unabated. Open Glossary has four main projects this year, building on its successes in 2018:

Grow the Community

The Open Glossary project depends on open collaboration, and the community is actively building engagement by seeking out participation from key stakeholder groups in edge computing. Within The Linux Foundation itself, the Open Glossary team has sought input from not only all of the LF Edge projects but also adjacent projects, such as the CNCF’s Kubernetes IoT and Edge working group. In addition, the Open Glossary has formed alliances with other edge computing groups and foundations, including the TIA, iMasons, and the Open19 Foundation. Partnering with other non-profits and consortia will help the project grow its base of passionate collaborators who are dedicated to expanding and improving the Open Glossary.

The Taxonomy Project

Readers of the Open Glossary want more than mere definitions; they want to know how the constituent parts fit together as a whole. To answer this request, the Open Glossary has begun the Taxonomy Project, a working group that seeks to create a classification system for edge computing across three core areas:

  • Edge infrastructure
  • Edge devices
  • Edge software

The Taxonomy Project will draw upon the expertise of subject matter experts in each of the core areas to define and hopefully also visualize the complex relationships between the different components in edge computing. The Taxonomy Project WG is being led by Alex Marcham and the Open Glossary will publish the first taxonomies in Q3 2019.

The Edge Computing Landscape Map

At the request of The Linux Foundation, the State of the Edge project also contributed its Edge Computing Landscape Map, which is now a working group under the auspices of the Open Glossary. The Landscape WG is being led by Wesley Reisz and has just started out. Currently, they have regular weekly meetings (Tuesdays at noon Pacific Time) and the group is actively working on refining the categories the LF Edge Landscape. The group seeks wider participation and will be asking for help to test and validate the proposed categories.

You can see the landscape map evolve at https://landscape.lfedge.org and join the mailing list here.

Glossary 2.0

Edge computing is a rapidly evolving area of development, deployment and discussion, and the Open Glossary contributors aim to keep the glossary up to date with the latest developments in industry and academia, driven by contributions from our project members. During 2019, the Open Glossary team aims to release its 2.0 version of the Open Glossary, which will be a timely update that continues to form the basis for clear and concise communication on the edge.

To see open issues and pull requests or to make contributions, visit the GitHub repo. Go here to join the mailing list.

In Summary

2019 is shaping up to be a pivotal year for edge technologies, their proponents and of course their end users. The Open Glossary project, as part of The Linux Foundation, is dedicated to continuing its unique mission of bringing a single, open and definitive lingua franca to the world of edge computing. We hope you’ll join us during 2019 as we focus on these goals for the project, and look forward to your contributions.

Contributors can get involved with the Open Glossary project by joining the mailing lists and contributing and commenting on the GitHub repository for the project.

Alex Marcham is a technical marketing manager at Vapor IO. He is one of the primary contributors to the Open Glossary and leads the Taxonomy Project working group. Matt Trifiro is CMO of Vapor IO and is the Chair of the Open Glossary project.

Your Path to Edge Computing: Akraino Edge Stack’s Release 1

By Kandan Kathirvel, Akraino Edge Stack TSC-Chair and Tina Tsou, Akraino Edge Stack TSC Co-Chair

The Akraino community was proud to announce the availability of its release 1 on June 6th. The community has experienced extremely rapid growth over the past year, in terms of both membership and community activity: Akraino includes broad contributions from across LF Edge, with 60% of LF Edge’s 60+ members contributing to project, as well as several other developers across the globe.

Before Akraino, developers had to download multiple open source software packages and integrate/test on deployable hardware, which prolonged innovation and increased cost. The Akraino community came up with a brilliant way to solve this integration challenge with the Blueprint model.

An Akraino Blueprint is not just a diagram; it’s real code that brings everything together so users can download and deploy the edge stack in their own environment to address a specific edge use case. Example use cases include IoT gateway, MEC for connected car, and a RAN intelligent controller that enables 5G infrastructure.

The Blueprints address interoperability, packaging, and testing under open standards, which reduces both overall deployment costs and integration time by users. The Akraino community will supply Blueprints across the LF Edge portfolio of projects, with plans to address 5G, IoT and a range of other edge use cases.

The key strength of the Akraino community is the well-defined process to welcome new Blueprints, new members, users and developers. The technical community is comprised of a Technical Steering committee (TSC), which consists of representatives from across member companies. The TSC acts as a “watchdog” to set process, monitor the community, and ensure open collaboration. In addition to the TSC, the Akraino community has seven sub-committees focused on much-needed areas such as security, edge APIs, CI and validation labs, upstream collaborations, documentation, process and community. Regular meetings are scheduled to ensure broader collaboration and accelerate progress on the various projects. The community calendar can be found here. It is not necessary to be a member to join the community calls, we invite anyone interested in learning more to join!

The above picture illustrates the primary use of Akraino R1 Blueprints and its targeted deployment areas. The release 1 Blueprints cover everything from a larger deployment in a telco-based edge cloud to a smaller deployment, such as in a public building like a stadium. Each Blueprint is validated via community standards on real physical lab hardware, hosted by either the community or the users.

Akraino Edge Stack prides itself on continuous refinement and development to ensure the success of Blueprints and projects. The community is already planning R2, which will include both new Blueprints and enhancements to existing Blueprints, tools for automated Blueprint validations, defined edge API’s, new community lab hardware, and much more. For future events and meetings please visit: https://wiki.akraino.org/display/AK/Akraino+TSC+Group+Calendar.

 

Hello System Management!

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.

Project EVE Code Now Available

Project EVE (Edge Virtualization Engine), part of LF Edge since the organization’s inception, earlier this week marked an important milestone: the official handover of code from ZEDEDA. EVE provides an open standard for edge virtualization, helping make it as easy and secure to manage applications on edge devices as it is in the cloud. With EVE, enterprises can run a wide variety of applications on any edge-class gateway while enjoying the benefits of data center virtualization, like zero-touch provisioning and secure, one-click software update rollouts at IoT scale.

“Project EVE’s release under LF Edge is an important milestone for the edge computing industry,” said Melissa Evers-Hood, senior director of Google Operating Systems for Intel System Software Products, and chair of the LF Edge Governing Board. “An open approach to virtualization can help companies address the growth in diverse services and hardware configurations being deployed at the edge. Using virtualization to consolidate workloads provides companies with a more flexible and elastic infrastructure, allowing them to secure and manage these services while containing costs.”

Project EVE  allows applications ranging from legacy software programs running in virtual machines (VMs) to the latest microservices architectures to operate in a secure and reliable way on smaller edge devices. This is accomplished through the use of a type-1 hypervisor, an Edge Container runtime, and a hardened root-of-trust implementation, enabling workloads to run in either a VM or standard container environment. By decoupling software from hardware, EVE also allows for multi-tenant deployments that can operate in complete isolation from each other, increasing security and decreasing complexity.

Key features of Project EVE include:

  • Compatibility with all major edge hardware and cloud providers—no vendor lock-in
  • Ability to support any application that can run in a VM or standard container
  • Simplified application management through standardized APIs
  • Smarter hardware usage through coordinated resource allocation and partitioning
  • Ability to create a zero-trust approach to security, leveraging a hardened root-of-trust implementation

As the number of IoT devices continues to skyrocket, it’s becoming more and more important for businesses to be able to process, analyze, and act on sensor data in real time via local edge gateway systems. Project EVE provides a key component of the technology stack needed for powerful computing at the edge. By contributing the code for Project EVE to LF Edge, ZEDEDA is furthering the organization’s mission to create an open framework for edge computing.

For more information about Project EVE, visit https://www.lfedge.org/projects/eve/.

 

LF Edge at IoT World

LF Edge will be at IoT World 2019 in Santa Clara, Cali. from May 13 to 16. The event is the leading IoT showcase that features the top technologies, strategies, and case studies for the key industries implementing IoT. This year, LF Edge projects Akraino, EdgeX Foundry & Project EVE will be at the show floor to show off their latest demos in booth #610.

Akraino will be on-site to show off it’s it’s latest line of blueprints, which are designed to support a wide variety of edge use cases. Akraino will show off it’s SDN Enabled Broadband Access (SEBA) blueprint, ELIOT (Edge Lightweight and IoT) Blueprint, Micro-MEC Blueprint and the Future Network Lab Connected Vehicle Blueprint. The Akraino community tests and validates the blueprints on real hardware labs supported by users and community members.

EdgeX Foundry will showcase it’s building automation demo, which highlights EdgeX’s ability to bring together a real-world, smart flexible office space environment based on components from a variety of vendors leveraging numerous connectivity standards, operating systems and hardware types.

EdgeX will also be featured in a demo from Beechwoods Software that showcases the AMD Edge Gateway reference running EdgeX and supporting IBM Watson IoT for both the cloud and the analytics engine.

In addition, Project EVE will also be on the scene with its new wind turbine model. Based on the EdgeX framework and the Project EVE technology, the demo will showcase turbine  operations analytics.

LF Edge members will be also be on-site to provide background on any of the projects or walk you through an interactive demo. Stop by booth #610 to learn more or attend any of the following IoT presentations on Thursday, May 16:

  • Jason Shepherd, LF Edge Governing Board Member and CTO of IoT and Edge Computing at Dell Technologies, will present a session at 11:40 am – Noon in Grand Ballroom F. The presentation titled, “The Holy Grail for Digital & Data,” explores where companies are today with their data strategy and where they might be in five to ten years.
  • Arpit Joshipura, GM of Networking & Orchestration + Edge / IOT at the Linux Foundation, will present on a panel titled “The Fast and The Curious: Smart, Safe Ways to Accelerate Building and Deployment,” at 1:40 pm – 2:20 pm in Grand Ballroom G. He’ll be joined by Frederic Desbiens,  IoT & Edge Program Manager at The Eclipse Foundation, Christopher Konopka, Developer Evangelist at Twilio & Brian Buntz, Content Director at IoT World Today. Attendees of this session will learn about the latest methods for bringing a commercial or in-house IoT application or device into production more quickly, efficiently and securely.
  • Arpit Joshipura will then join Sue Troy, IoT World Today Executive Editor and Alexander Olesen, Founder of Babylon Micro-Farms, for the last panel of the day titeld, “What’s the deal with…?” From 4:20 – 5 pm in the Grand Ballroom G, the panel will discuss  new IoT technologies, projects, hardware, software and services and a wide range of other topics like edge and IoT, starting an IoT company , 5G, WIFI 6, digital twins, challenges and concerns.

If you have questions or comments, visit the LF Edge Slack Channel and share your thoughts in the #community or project channels.

EdgeX Foundry Is a Finalist for The IoT World Awards

EdgeX Foundry, the vendor-neutral, operating system and hardware independent, open source, microservice, software edge computing platform, is a finalist for the “Best Edge Computing Solution & Achievements in IoT Integration” award for the IoT World Awards. The awards celebrate the success and outstanding contributors to the very best in the world of IoT.

Other finalists in this category include Dell Technologies and FogHorn – both are currently LF Edge members and are still very active in EdgeX Foundry – as well as Itron Inc and Lantronix Inc.

Not only will EdgeX Foundry be attending the award celebration but will be on-site on the exhibition floor. To see interactive EdgeX Foundry demos, which include building automation and a wind turbine, visit the LF Edge booth (Booth 610). For more information about the activities planned for IoT World, visit https://www.lfedge.org/event/iot-world-2019/.

EdgeX Foundry focuses on IoT Edge, and helps simplify the process to design, develop and deploy solutions across industrial, enterprise, and consumer applications. Since it’s launch in 2017, EdgeX has met several technical milestones in its roadmap including the Barcelona release, California release, & Delhi release.

In January 2019, EdgeX Foundry joined Akraino, Project EVE, The Open Glossary of Edge Computing and Home Edge to form LF Edge, an umbrella organization dedicated to establishing an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating systems.

The winner of the award will be announced at the IoT Awards Dinner & Gala in Santa Clara, CA on May 15. To learn more about the awards or any of the other categories, click here.

Arm at the Edge: Telco and IoT Akraino Blueprints debut at ONS 2019

By Tina Tsou, co-chair, Akraino Edge Stack Technical Steering Committee & Enterprise Architect, Arm. A version of this post also appeared on the Arm Community blog

Last week at Open Networking Summit in San Jose, there was a lot of buzz about the Akraino Edge Stack Project. Launched in 2018, Akraino Edge Stack was developed to create an open source software stack that supports high-availability cloud services optimized for edge computing systems and applications.

Significant progress has been made in this community since the launch, and many member companies showcased their Akraino blueprints last week. Arm is very active in the Akraino community and is excited about the Akraino Edge Stack Blueprints.

Here are some additional details about the four blueprints that were shown:

1) SDN Enabled Broadband Access (SEBA) on Ampere-based servers

For users of Virtual broadband access (XGS-PON which is a higher bandwidth, symmetric version of GPON), Ampere demonstrated SDN Enabled Broadband Access (SEBA) validation on Arm. The SEBA blueprint in the Akraino Edge Stack Project, can run applications of Virtual broadband access – vOLT access and aggregation for 5000 edge locations. There are three servers per POD, with x86 and Arm (with 8-16 cores each). The power consumption is restricted to less than 1 kW and includes NEBS compliance and 48V DC. The Ampere eMAG-based server delivers competitive performance per watt with 32 Armv8 CPU cores at 3+ GHz with Turbo. 

The foundation of the SEBA validation on Arm demo is built on Integration Edge Cloud (IEC) blueprint family. The Integrated Edge Cloud (IEC) enables new functionality and business models on the network edge with benefits such as lower latency for end users, less load on the network since more data an be processed locally, and full utilization of the computational power of the edge devices.

VMWare proposed multi-cloud xConnection to interconnect different kinds of clouds of IT and Telco. The IEC had several deployment models that each support different business case such as telco/enterprise edge cloud (ex. MEC or brand office data center) or telco/enterprise remote edge locations (ex. SD-WAN, IoT Gateways). The demonstration included Ubuntu, Kubernetes, and Calico on Arm.

2) ELIOT (Edge Lightweight and IoT) Blueprint on Huawei IoT Gateway 

We were excited to partner with Huawei to demonstrate the ELIOT: Edge Lightweight and IoT Blueprint Family.  The ELIOT blueprint was designed to service the need of many diverse business applications that require a converged IoT gateway, and Enterprise WAN edge use of SD-WAN solutions or universal CPU (uCPE). The IoT gateway can be deployed in smart cities, smart homes, connected farming, agriculture logistics industrial, and Industrial IoT.  SD-WAN, WAN edge, uCPE are designed to be used for hybrid WAN, hybrid cloud deployment, and BYOD.  ELIOT is very scalable, from 1 single unit to 10K, 100K, 1000K, or more. ELIOT also supports diverse types of edge applications in many industries and market segments, including but not limited to: telcos, operators, service/cloud providers, medicine, smart cities, industrial IoT, home, and enterprise. The cloud/network infrastructure for ELIOT includes containers, Kubernetes, and the Kubernetes ecosystem. At the same time, the blueprint is designed to use lightweight operating systems and container runtime environments.

“The IoT gateway and enterprise edge SD-WAN gateway are two great examples of computing or power resource constrained edge nodes. The ELIOT project provides end-to-end light-weight open source blueprints for deploying and managing these use cases, built on any processor architecture, to foster a vibrant ecosystem around edge gateways in both hardware and software.”

–  Bill Ren, Chief Open Source Liaison Officer, Huawei

3) Micro-MEC Blue Print from Nokia

Nokia, Arm, and other ecosystem partners within the Akraino/LF Edge community have formed an edge blueprint for a Smart Cities platform called Micro-Mec (uMEC) targeted for a range of use cases. Nokia is using an Arm-based Marvell CN83xx uMEC design to show a highway traffic monitoring application. The uMEC enables new functionalities and business models on the network edge. The benefits of running applications on the network edge include lower latencies for end users, less load on the network since more data can be processed locally, and better security/privacy since sensitive data need not be transferred to a centralized location.

All these new services support the business case for building new high-speed networks which in turn enable new things. The uMEC has several deployment models that each support different business cases including:

  • Fixed installation as part of 5G NR base station enabling new services that require low latency such as AR/VR.
  • As an extension of the previous, the “Smart City” deployments have additional functions such as weather stations, cameras, displays, or drone charging stations.  The control software for these functions would run on the uMEC.
  • In an Industry 4.0 use case set, the uMEC is deployed as part of a 5G network and would provide a platform for running services for the factory floor.
  • In a train, the uMEC could collect and store surveillance camera data for later uploading. 

“Nokia is very excited to demo the the new edge blueprint for operators and smart cities called Micro Multiaccess Edge (uMEC). It demonstrates how even a very small ARM- based system can implement a Smart City use case, and complements the industry standard Open Edge hardware that is used in the Radio Edge Cloud and the 5G Radio Access Network,” said Tapio Tallgren, Project Technical Leader for uMEC and Akraino Technical Community

4) Tencent Future Network Lab Connected Vehicle Blueprint

The Connected Vehicle Blueprint focuses on the MEC platform, which is the backbone for V2X (Vehicle to Everything) applications. The blueprint can be used in multiple use cases, including but not limited to: 

  • Accurate Locations: The blueprint is designed to deliver more than 10X finer granularity in location. GPS is 5-10 meters level location which can be improved to <1 meter.
  • Smart Navigation: Real-time traffic information update reduces the latency from minutes to seconds to provide the more efficient path for drivers.
  • Safer Driving: Insight into potential risks which can’t be seen by drivers’ eyes.
  • Reduced Violation in Traffic Rules: Let the driver understand the traffic rules in some specific area.  For example, change in lines for an upcoming and narrow street, avoiding opposite way drive in the one way road, and avoiding carpool lanes for a single driver.

The blueprint can be flexibly deployed in multiple environments, including bare metal, virtual machine, and container based on commodity hardware (Arm/x86 server). The major software component of this blueprint is Tars, a Linux Foundation microservice Framework project. Tars can be deployed in Arm and x86 servers.  For more detail information for Tars, refer to the github link.

Learn more about connected vehicle blueprint on Google Drive or read the blog post here

“Tencent continuously promotes network innovation from various application perspectives. We believe that application-based network innovation promotes a stronger ecosystem, which brings tremendous benefits to our customers and stakeholders.” –– Zhang Yun Fei, Director of Future Network Lab, Tencent

“Open source is an important technical strategy for Tencent. As both a platinum member and board member of the Linux Foundation, Tencent continuously makes contributions to the Linux Foundation and its projects. After the Tars project contributed to the LF in 2018, and recent Akraino blueprint, Tencent will continue to contribute several new open source projects focused on cache and configuration. We welcome additional participation from more Linux Foundation member companies!” — Xin Liu, Linux Foundation Board member, and Tencent General Manager

We are excited about these great Blueprint demonstrations and the others shown last week. I want to acknowledge the Akraino Edge Stack Project Technical Steering Committee, PTLs, committers, and contributors, for their support with our activities at the conference.  It is truly a team effort! Special recognition goes to:

  • Aaron Byrd, AT&T
  • Matt Taylor, Ampere
  • Trevor Tao, Arm
  • Gabriel Yu, Huawei
  • Tapio Tallgren, Nokia
  • Robert Qiu, Tencent
  • Xinhui Li, VMware
  • Ken Yi, DiDi
  • Wenhui Zhang, PSU

Connected Vehicle Blueprint Debuts at ONS NA 2019

The  Connected Vehicle Blueprint, established within the Akraino community by contributions from Tencent Future Network Lab, Arm, Intel, and Nokia, was demonstrated onsite at Open Networking Summit this week in San Jose. The blueprint demo clearly depicts features, architecture as well as the potential benefits for customers. The Connected Vehicle Blueprint focuses on the MEC platform, which is the backbone for the V2X (Vehicle to Everything) Application.

The blueprint can be used in multiple use cases, including, but not limited to:

  • Accurate Location: The blueprint brings more than 10X fine gratuity location. GPS is 5-10 meters level location, that can be improved to <1 meter, which is the distance of a typical street lane.
  • Smart Navigator: The real-time traffic information update, reduces the latency from minutes to seconds, figures out the most efficient route for drivers.
  • Safe Drive Improvement: Helps the driver figure out any potential traffic risks that may not be seen by the driver.
  • Reduces traffic violations: Helps the driver understand local traffic rules. For instance, changing the lane prior to a narrow street, avoiding driving on the wrong side of a one-way road, avoiding carpool lanes as a single driver, etc.

“Tencent continuously promotes network innovation from various application perspectives. We believe that application-based network innovation promotes a stronger ecosystem, which brings tremendous benefits to our customers and stakeholders,” said Zhang Yun Fei, Director of Future Network Lab, Tencent.

“Open source is an important technical strategy for Tencent. As both a platinum member and board member of the Linux Foundation, Tencent continuously makes contributions to the Linux Foundation and its projects. After the Tars project contributed to the LF in 2018, and recent Akraino blueprint, Tencent will continue to contribute several new open source projects focused on cache and configuration.  We welcome additional participation from more Linux Foundation member companies!” said Xin Liu, Linux Foundation Board Member and Tencent General Manager

The blueprint can be flexibly deployed in multiple environments, including bare metal, virtual machine and container-based environments on commodity hardware. The major software component of this blueprint is Tars, a Linux Foundation microservice framework project.  For more detail information on Tars, refer to the link:  https://github.com/TarsCloud/Tars

For more information regarding the connected vehicle blueprint, refer to:

EdgeX Foundry is now available as a Snap

Tony Espy, EdgeX Foundry Technical Steering Committee Member & Technical Architect – Devices & IoT at Canonical, gives details on the recent availability of EdgeX Foundry in snap format. The new availability gives millions of Linux users and developers access to the continuously growing Snap Store.

EdgeX Foundry is a vendor-neutral open source project that concentrates on building a common framework for IoT edge computing. With a focus on the IoT Edge, EdgeX simplifies the process to design, develop and deploy solutions across industrial, enterprise, and consumer applications. Since it’s launch in 2017, EdgeX has met several technical milestones in its roadmap including the Barcelona release, California release, & Delhi release.

In January 2019, EdgeX Foundry joined Akraino, Project EVE, The Open Glossary of Edge Computing and Home Edge to form LF Edge, an umbrella organization dedicated to establishing an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating systems.

In adopting the universal Linux app packaging format, EdgeX Foundry will make its IoT Edge platform available to an ever-growing community of Linux developers, including those on Debian, Fedora, Manjaro, OpenSUSE, Zorin and Ubuntu. Automatic updates and rollback capabilities are staples of snap software, meaning EdgeX Foundry users will always have the best and latest version running.

Snaps are containerised software packages, designed to work perfectly and securely within any Linux environment; across desktop, the cloud and IoT devices. Thousands of snaps have been created since the first one in 2016. EdgeX Foundry joins Plex, Spotify, Skype, and Slack, who have all benefited from snaps’ update and security features.

“Canonical’s Snap Store provides an easy and secure way to distribute our software to an increasing number of developers and users,” said Jim White, Vice Chair – Technical Steering Committee at EdgeX Foundry. “What’s more, snaps help cater to EdgeX Foundry developers, who benefit from snap confinement, binary delta downloads, ease of deployment/configuration, and sophisticated service management.”

The EdgeX snap is fully confined, which means snapd ensures that applications and services provided by the EdgeX snap may only use hardware and system resources that have been explicitly granted to the snap. Binary delta downloads is a feature which benefits users of snaps by lowering the bandwidth required for software updates. Ease of deployment/configuration stems from the fact that the snap provides all of the EdgeX reference services as a single package. This makes it trivial to build an appliance-like image using the EdgeX snap with Ubuntu Core.

Finally, it also should be noted that all of the EdgeX reference services in the snap are deployed as system services. This ensures that EdgeX will be automatically started when a device boots, services can be individually managed (i.e. enabled/disabled/started/stopped/restarted), and services will be automatically restarted by the system if they exit due to an error condition.

For more details on how to use the EdgeX Foundry snap click here. EdgeX Foundry is available to download as a snap by clicking here.

This blog originally ran on Canonical’s Ubunto blog. You can view the blog here.

An Enhanced Delhi Code with More Bells and Whistles

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.

ETRI unveils Time-Sensitive Networking IIoT Gateway based on EdgeX

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.

EdgeX Foundry Releases Delhi and Plans for Edinburgh

The technical details on the current and next release of EdgeX Foundry

Jim White, Dell Technologies IoT Platform Development Team Lead & EdgeX TSC Vice Chair

This week, EdgeX Foundry announces the release of Delhi, our third major release in 12 months.  With each release that this growing community kicks out – I get a little nostalgic.  EdgeX started its life in my kitchen.  Like a lot of open source software efforts – it started humbly.  In the case of EdgeX, it started on my laptop, propped open on my kitchen island one summer weekend about 4 years ago with an adult beverage or two.

Today, Edgex is being developed around the globe by a lot of tremendous software engineering talent.  I was proud to start EdgeX, but I am even more proud to be part of an exciting group of international engineers building the most flexible, interoperable, open source IoT platform on the planet. This new release, Delhi, contains a new service and several key features that have our community and potential customers excited about the future of EdgeX Foundry.

Delhi Release

System Management

Most importantly, this release contains the first EdgeX system management capability.  A new service – the System Management Agent (SMA) – serves as the coordinator for control plane information (status, configuration and metrics around EdgeX services) and control actions on EdgeX services (start, stop, and restart).  Cloud or third party systems can call on the API provided by the SMA to trigger the actions or to get the control plane data they need. The SMA can serve as a one-stop shop for managing an instance of EdgeX.  Each EdgeX micro service has a corresponding management API that the SMA calls on to help control that service (example – stop the service) or pull back its latest configuration or metrics.  The SMA and 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 (like LWM2M or SNMP).

Device Service SDKs

The original platform that started on my kitchen island was a Java platform.  Last year, the community embarked on an endeavor to replace the bulky and slow Java services and tools with Go and C services and tools.  Device Services – the EdgeX services that connect “things” to the platform are still in Java but not for long.  With the Delhi release, two new Device Service SDKs have been created.  The Go and C SDKs are allowing the community to create smaller, lighter, faster device/sensor connecting services that will allow EdgeX to operate in very limited resource compute environments – the thin edge in IoT solutions.

Improved Service Resiliency and Decoupling

In the past, the EdgeX microservice dependencies required the services be brought up with wait times between the startup of each service to allow the system time to bring things up in order.  The services now are able to automatically check and detect when a dependent is in place and to become fully functional only after a dependent is up.  This greatly reduces the start of all of EdgeX from minutes to seconds – around 5-10 seconds on average.  The services now detect a dependent has gone down and will keep retrying that service until it comes back up.  This gives EdgeX more resiliency than it had in the past.

EdgeX User Interfaces

EdgeX was built to facilitate machine to machine communications.  As such, it did not have a user interface.  With the Delhi release, user interfaces were created – largely to help visually showcase EdgeX functionality and to help developers – these UI also serve to show how EdgeX can be driven and operated.

Improved Core and Supporting Services

Many of the core and supporting services in EdgeX were improved and more unit testing was added to allow the community to keep an eye on the quality of the overall system and compatibility of future features of EdgeX.  The Scheduling Service was also transitioned from Java to Go.

More Secure

Security services were initiated in our last release (California).  The Delhi release includes the next wave of security features such as access control to grant access to appropriate services, and improved security service bootstrapping.

Better Tested

As mentioned, more unit tests were added to the EdgeX services.  Additionally, automated blackbox tests are in place for each service to make sure the public API of each service performs as documented.

Ecosystem Growth

In addition to all this hard work, our EdgeX Foundry ecosystem continued to expand during this release cycle.  Among the new companies to join EdgeX Foundry are Basking Automation, Data Ahead, Intel, Redis Labs, and ZEDEDA.  This community also launched the availability of a developer kit and community demonstrator (for showcasing EdgeX during conferences and IoT events).  Find out more about these here.  Stay tuned to the EdgeX news and announcement pages as some big organizations are preparing to announce their joining early in the New Year.

Edinburgh

OK – no time to rest on our laurels.  What’s next EdgeX?  I am glad you asked!  Indeed, the EdgeX technical steering committee (TSC) along with several community members met in Edinburgh Scotland to plan and scope our next release – code named Edinburgh – which is scheduled for April 2019 (I assure you the release name and TSC meeting place alignment happened a little serendipitously).

As Keith Steele, Chair of the EdgeX Foundry Technical Steering Committee, reported in his blog post, the results of the meeting were “superb” – as the Scots like to say.

The Edinburgh release has been scoped to include a rather significant amount of new features as well as making improvements on the current code base (“cleaning up technical debt” as we like to say).  Given the increase in community membership and number of contributors to the project, we feel this scope is within reach.  Here are some of the major efforts the membership has planned for the next 5-6 months.

Binary Data Support

The Edinburgh release of EdgeX will support the ingestion, use, and export of binary data (using CBOR format).  To date, EdgeX has supported ingesting, using and exporting integer, float, string, and boolean types of discrete data collected from sensors.  Many of the edge use cases involve video images, audio data, and other data that is binary data serialized.

Automated Performance and Security Testing

EdgeX has come a long way over the past few releases in increasing and improving its quality through testing.  In the Edinburgh release, performance and security testing will be automated.

Cornucopia of new Device Services

The new Go and C Device Service SDKs created with the Delhi release allow the community to create smaller, faster, less-resource consuming replacements for the Java Device Services that now serve to connect “things” to EdgeX.  This includes Modbus, BACNet, BLE, MQTT and SNMP Device Services.  As there has been a bit of a pent up demand to get new Device Services for EdgeX due to the development of the SDKs, we believe this release will contain even more thing connectors than we could have imagined a year ago.

The paint on the new SDKs isn’t even dry and we already have the community showing off some early prototypes of new Device Services today and the numbers are impressive.  In one small example, our old Java Modbus Device Service was 141MB in size and consumed 184MB of memory.  The Go version produced with the new SDK is 16MB in size and uses just 8MB of memory.

Application Services

The current EdgeX Export Services, while functional, create scalability issues. The current EdgeX capability relies on the Export Services to know and understand all possible endpoint distribution mechanisms and transformation capability necessary to support all clients – even if the use case requires only a single, simple client (like sending the raw sensor event data to an MQTT pipe in JSON). As the number and type of EdgeX north side clients (cloud, enterprise and on-prem IoT servers) expands, this service will be too big and complex to support the north side needs.

The Edinburgh release will feature a new type of “exporting” service – the Application Service.  The initial and simple Application Services in the Edinburgh release will be designed and implemented to support smaller, more tailored exportation needs. These services will contain just the functionality (filtering, transformation, enrichment, etc.) needed for a single endpoint. To address multiple endpoints, multiple Application Services will be created (versus having one massive export service as EdgeX has today). In a way, the Application Services will begin to look more like the south side Device Services – that is functionality dedicated to a particular client protocol and data need. Long term over the course of a number of releases, Application Services will replace EdgeX Export Services as the north side distribution facility.

Improved User On-boarding & Support Plan

EdgeX Foundry has been a developer driven effort.  As the platform is and will continue to be used in real world IoT solutions, it becomes imperative that the community improve the quality and volume of documentation, tutorials, examples, videos, etc. to help user communities go from day 0 to production as quickly as possible.  It is also imperative that EdgeX institute a long term support plan/strategy to give the user community assurances about what they can expect from the open source effort they put into their products.  The TSC Chair (Keith Steele) and TSC Vice-Chair (me) are dedicating our resolve to address these two concerns as part of the Edinburgh release cycle.

Certification Program

A certification program will be outlined in concert with the Edinburgh release. A certification program will enable third parties creating EdgeX services to verify their services as alternative or enhancing capability to those provided by the EdgeX open source effort.  This will allow 3rd parties to add value (proprietary or open source) to EdgeX that customers can rely on to meet the EdgeX APIs and work without additional code change (enabling a plug-and-play ecosystem).  Various levels of certification are being considered, from micro service replacement certification (validating alternate or commercial implementations of EdgeX micro services satisfy API requirements along with performance metrics and quality checks) to full EdgeX deployments (for commercial versions of EdgeX).  Additional certification processes may be developed around particular cross cutting features such as security.

And More…

  • Use of Vault namespaces for storing secrets for the micro services.
  • Initial EdgeX secrets (needed to start Vault/Kong) will be encrypted on the file system using a secure storage abstraction layer – allowing other implementations to store these in hardware stores (based on hardware root of trust systems)
  • Refactor EdgeX database-using services (Core Data, Metadata, Export Client, Logging, Notifications, and Scheduling) to be more loosely coupled to the persistence mechanism (currently MongoDB). This will better facilitate the use of alternative persistent stores and technology in future implementations and even allow the project to select alternate or additional reference implementation databases in future releases.
  • A smaller, lighter, faster rules engine service to replace the last of the EdgeX Java micro services.
  • System Management will offer service health/status checks and additional metrics
  • Updating the versioning and dependency management system for all Go micro services (replacing a deprecated technology)
  • Upgrading all 3rd party open source tools included with EdgeX (Consul, Kong, Vault, etc.) to use the latest releases

For a full list of the Edinburgh release scope and roadmap, see the project Wiki.

It’s a large scope, but the community and team of developers is growing.  Contact our Developer Advocate, Michael Hall, if you and your team would like to be a part of our effort – it’s an exciting time to be part of an exciting and industry impacting project.  I have every confidence the EdgeX Edinburgh release will make some news in April 2019… as long as I can keep the team away from all the Scottish whisky we brought home from our trip!

2 Great Weeks in the Life of EdgeX Foundry

By Keith Steele, Chair of the EdgeX Foundry TSC

I wrote this blog on a train from Edinburgh back to my home town in Newcastle UK, ending two weeks of spirited activity for the EdgeX community. On October 15-17, we gathered in Barcelona for IOT World Solutions Congress and then we met in Edinburgh for our bi-annual Technical Steering Committee (TSC) meeting.

Both weeks were by hugely successful for the project with some major milestones achieved, market momentum demonstrated and collaboration that solidified plans for our impressive roadmap, which agreed for the next EdgeX release in April.

Most striking of all, however is the growing ecosystem of contributors driving the project forward, their talent, enthusiasm and unselfish collaboration. It was just a pleasure to witness and a lot of fun – I’ll never quite forget the gradual rise in volume in the room as we progressed through the Scotch Whiskey tasting with the TSC!

Anyway, I digress, let’s start this blog in Barcelona, or for some of us Toulouse! The IOTech team had a slight travel diversion due to storms and ended up in nice Southwestern French city, but didn’t get to explore. Undeterred, the team developed an alternate travel route and finally showed up in Barcelona to see the EdgeX Foundry booth ready and looking sharp with the new community demo as a nice focal point.

The New Community Demo

EdgeX Foundry’s new community demo set out to demonstrate the full capability of EdgeX in the context of a realistic use case, we chose Buildings Automation but it could have been any edge vertical. When we say the full capability of EdgeX we mean:

  • Multi vendor, multi protocol southbound connectivity and data interoperability – the demo has over a dozen different connected devices seamlessly interoperating through EdgeX using standard connectivity software!
  • Hardware independence – the demo has three gateways from three different vendors hosting EdgeX, demonstrating its distributed microservice capability
  • Silicon provider independence – three Gateways, three different chip sets; 32 and 64 bit ARM and 64 bit Intel
  • Application plug and play – standard Microservice API’s enabled easy replacement of the EdgeX rules engine reference implementation with NodeRED to demo Edge analytics capability
  • Local Edge Control – the demo is not just about collecting data, it shows full the full command capability of EdgeX
  • Connect to any Cloud – the demo shows connectivity to AWS but this could just as easily have been Azure, Google, or any cloud
  • Interaction with Cloud Applications – in this case, we showcased higher level Energy Management and Space optimization software interacting with the Edge system but with flow of data filtered and optimized to cut expensive cloud data usage costs!

If you weren’t at the show, you’ll be able to see a video of it soon. In the meantime, James Butcher, Senior Solutions Architect at IOTech, shares the details of how the demo came together in this blog post.

So, how was it all received?

I say without hesitation this was a great show for EdgeX (and I say this as someone who usually regards trade shows as only marginally more useful than a Celine Dion tribute act).

The EdgeX Foundry stand was continuously busy – attendees came to see the community demo and meet with EdgeX members Basking Automation, CloudPlugs, Dell, Enigmedia, IOTech, and Mainflux as well as Redis Labs, RSA, VMware and ZEDEDA with their own presence demonstrating their integration with EdgeX.

At the show, we announced Intel and eight other tech influencers joined the project and there was huge interest for this and the new EdgeX dev kits at the show. Jason Shepherd, Chair of the EdgeX Foundry Governing Board, and I were busy briefing customers, analysts and media, while traffic to the booth was heavy and constant. James, one of the people manning the community demonstrator only managed lunch at 4pm the 1st day of the show!

My own takeaways

Barcelona, for me, proved without a shadow of doubt an open approach at the Edge is now a well-established need and EdgeX is regarded as the leading open implementation.

The vendor neutral approach is the clear driver, the Edge is by its nature a very heterogeneous and users want a solution that is designed to support that heterogeneity rather than a proprietary solution that locks them in to a specific vendor.

The flexibility of choice of cloud and hardware providers were big winners with visitors to the EdgeX booth. Some of the bigger users are hedging their bets with dual approaches, but there was evidence from the many vendors visiting the booth that they recognized they were going to have to support EdgeX.

Another big motivator was an open approach as a basis for bringing together the 6-10 vendors/technology partners typically required to deliver an end to end IOT solution using EdgeX as an integration point allowing vendors to keep their proprietary value add while collaborating across a standard and open infrastructure. Interesting times!

On to Edinburgh for the EdgeX Technical Steering Committee meeting.

Good to see the numbers growing with 40-50 people attending across the 3 days of the meeting, again from all corners of the globe. Nice to also to see many new faces from Intel, Siemens, Thales, Analog Devices, Canonical, Dell, ForgeRock, Intel, IOTech, Mainflux, Redis Labs, Samsung Electronics, Siemens AG, Technische Universität Berlin, University of Edinburgh, VMware, and Wanxiang Group.

The main meeting discussion topics were the roadmap for the next release, called ‘Edinburgh’ (scheduled for release in April 2019) and the status of the Delhi release, which we just announced the code freeze with release in mid-November.

The Delhi release is a very important milestone for EdgeX as the core services have now all been refactored in Go and C providing a big improvement in performance, footprint and scalability.

A dot release to Delhi is going to be released in December to provide Redis as the underlying database option (in place of MongoDB) for several services including Core Data, Core Metadata and Export Client.  This work will be even more of a focus for Edinburgh where the easy replacement and swap of databases that support EdgeX is desired.

In parallel to the formal Delhi release of EdgeX, several community developer kits will also be made available, the first based on the Samsung Pi and Artik developer boards (link). The dev kits will go a long way to onboarding future EdgeX developers and improving developer onboarding will be a key priority for the TSC this year.

Here’s a short list of what was scoped for the Edinburgh release:

  • Support for binary data to be processed by EdgeX for the first time to allow for carrying video images, audio data, and the like.
  • Implementation (initial) of Application Services, an eventual replacement for Export Services, will be more scalable and functionally driven microservices for getting data from EdgeX to other systems and applications.
  • Definition for how EdgeX will operate on top of hardware root of trust systems and take advantage of the secure storage with an abstraction layer
  • Performance targets for EdgeX are already being hit, but performance testing as part of the continuous integration and release process.
  • Building better abstraction and separation of concerns around persistence for the services using a database (MongoDB today) in order to allow easy replacement of the database in the future.
  • Implementing the next wave of system management features to include providing more service metrics and offering EdgeX metrics, configuration and status information via additional control plane protocols (such as LWM2M, SNMP, etc.).
  • Adding a plethora of Device Services (DS) for various protocols given the new DS SDKs in Go and C.

Look for a future post by Jim White, our EdgeX Foundry Vice Chair of the TSC, to provide more details on the upcoming April 2019 release.

A few other points of notes from the meeting

We agreed it was time to have a release manager to oversee the bi-annual EdgeX releases and this task would be undertaken by the major contributors. Ideally, we’d rotate ownership of this task and it would be a good way forward with potentially 4-member companies taking it in turns by rotation. A call will be set up shortly to discuss this process and move forward with it.

The DevOps and QA/Test Working Groups will, for the next few months, run combined calls given the close cooperation needed and the focus in the EdgeX Edinburgh release on incorporating automated performance and scalability tests as part of the overnight runs. Look out for the new time for these meetings shortly.

Now the C and the GO SDK’s are available a big part of the Device and DeviceSDK Working Group’s work will now switch to acceleration and collaboration around accelerating new Device Service connectivity. This is obviously seen as key to widespread deployment of EdgeX going forward.

As mentioned, we had to have a little bit of fun while in Edinburgh. There’s nothing quite like Scotch Whiskey tasting in Edinburgh.

 

 

Remember, if you can’t make the meetings you can join by phone and the recordings of the meeting can be found here.

The next F2F TSC meeting will be hosted in Seoul, South Korea on April 22 -25.2019. You can register here and find more information is available on the EdgeX Wiki.

It was also announced the October 2019 meeting will take place at Intel’s facility in Chandler Arizona. We look forward to collaborating with you there!!

Finally, a couple of thank you notes, the first one to Jeremy Phelps, who is stepping down as chair from the DevOps Working Group, Jeremy’s enthusiasm, skill and effort levels have been just stellar and he will be a hard act to follow!

Lastly, thanks to the team at the Linux Foundation for their massive efforts in bringing both Barcelona and Edinburgh to fruition with professionalism and untold patience having to deal with me. Maybe next time, we all get an Octopus T-shirt!

Best Regards,

Keith Steele, TSC Chair

If you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

EdgeX Foundry Member Spotlight: ZEDEDA

The EdgeX Foundry community is comprised of a diverse set of member companies that represent the IoT ecosystem. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source solutions. Today, we sat down with Joel Vincent, the Chief Marketing Officer for ZEDEDA, to discuss the power of IoT, edge computing, the reason they recently joined EdgeX Foundry and preview the new demo they are debuting at IoT Solutions World Congress in a few weeks.

What does your company do?

Quite simply, ZEDEDA is building an applications services platform for the cloud-native edge. Our vision is to free cloud apps and allow any app to run anywhere on any device. As edge computing expands beyond the constraints of embedded computing, ZEDEDA effectively completes the cloud.

Why is your company investing in the IoT ecosystem?

IoT and the world of Edge Computing is not just expected to be orders of magnitude larger than the cloud itself, it’s going to be a world of inter-networked, multi-vendor, multi-owner, hardware diversity. We haven’t seen anything like this since the advent of TCP/IP itself. How do you get this diverse universe of computing working together to allow businesses to use the edge to evolve?  It’s going to require multi-vendor cooperation, open source efforts, and universal standards built around an IoT ecosystem.

How has IoT impacted your company? What benefits have you seen or what do you expect to achieve?

The forces that made the Internet of Things possible gave rise to the fundamental technologies that made ZEDEDA possible. Compute power continues to shrink in size and cost and increase in capabilities. It was only a matter of time before compute power that was once considered server-class was small enough, powerful enough, and cheap enough to be embedded in everyday devices that even a consumer can afford. That meant a new compute orchestration layer was required. That’s where we came in. In fact, we couldn’t have created ZEDEDA 3 or 4 years ago. Computing technology and IoT have advanced that quickly.

Why did your company join EdgeX Foundry?

EdgeX Foundry represents an opportunity to collaborate with other thought leading companies in edge computing and really make an open edge framework a reality. With a vision of apps running anywhere, on any device, over any network the goals of EdgeX Foundry aligned perfectly with our vision and mission for the future of computing.

How are you going to use the framework?

For us and the orchestration of the edge virtualization requires apps to view, understand, and address hardware in a standard fashion. Initially on of the most difficult things to orchestrate is how an app accesses the hardware resources its running on and with the diversity of hardware a framework defining how resources are handled and abstracting the “sausage making” away from the app development so that any app can address any hardware resource is a major key.

So our first effort, which we are demonstrating at IoT Solutions World Congress 2018 is how to get the EdgeX microservices deployed on thousands of devices that are geographically distributed in a simple, repeatable, and secure fashion. Once enabled, an app build to the EdgeX framework will be able to “work” on the hardware we’ve enabled.

Where do you see enterprise and industrial IoT in 20 years?

You won’t see it. It will just be. Everything will be connected, the cloud will be ubiquitous (seamless between the cloud we know today and the edge that is being built in a standard fashion tomorrow), and from this how we experience the world will be completely different. You will EXPERIENCE IoT in everything you do, but you won’t see a damn thing!

Seeding an Open Marketplace for IoT Edge Computing

Guest post by Jason Shepherd, EdgeX Foundry Chair of the Governing Board and Dell IoT and Edge Computing CTO

Hello Members and Friends of the EdgeX Community,

I hope you’ve had a great summer with friends and family. As we head into some big project announcements at IoT Solutions World Congress (SWC) in Barcelona from October 16-18, I wanted to take the opportunity to make sure you’re aware about a few member opportunities.

First, a quick update on the project momentum. We’re seeing a big ramp in the number of unique code contributors on the heels of the switch to Go Lang for the baseline reference implementation in our recent ‘California’ release. We’re now approaching 70 as of this month. Net-net, more and more people by the day are seeing the benefits of our approach to facilitating greater interoperability at the IoT edge!

As a result, some very large names will be announced as new project members at IoT SWC on October 16. We see many more on the horizon as the word continues to spread and the community meets commitments on delivering a high quality foundation to facilitate interoperability across the complex IoT landscape.

The community has chosen to organize around an October/April semi-annual release cadence, so the Delhi runway is a little shorter. Still, we’re going to see some major enhancements including the first management features, more security enhancements, C and Go Lang-based Device Service SDKs and a reference GUI for demos and simple deployments.

The latest project overview deck including more on progress to date and where we’re headed can be found here.

Other big news at IoT SWC will be the impending release of Delhi code, the launch of our community demonstrator to showcase the value of the project and enable future plug-fests and hackathons, EdgeX developer kits and more Vertical Solution Working Groups (VSWGs). I’ll focus on the latter two for the rest of this project update.

EdgeX-enabled Dev kits

The IoT journey often starts with an aspirational view seeded through a simple PoC to work through architectural and business model considerations before scaling up into deployment. Low-cost developer (dev) kits comprised of a board, collection of pre-integrated sensors and integration with an IoT platform stack are great tools to enable software developers to quickly prototype their ideas with a “fail fast” mentality.

However, the plethora of dev kits out there typically lock the developer into a particular backend platform or cloud. In comparison, kits based on the EdgeX Foundry framework will provide developers with complete freedom of choice, backed by the vendor-neutral EdgeX APIs that bind together choice of devices and applications regardless of protocol, OS, or underlying hardware used.

These dev kits and associated plug-in value-add will give developers confidence that they can prototype with their choice of ingredients while taking advantage of plug-in components from the growing EdgeX ecosystem. And perhaps more importantly, they’ll be able to readily swap out elements later as they optimize their solution and ramp into production and day to day operation.

In all cases these EdgeX dev kits will enable developers to innovate rather than reinvent. The following is a high-level summary of benefits specific to two key personas:

Benefits for end-user developers:

  • Get started developing your IoT solution at a low cost of entry while maximizing options from edge to cloud and minimizing potential for vendor lock-in
  • Facilitate integration and build/buy/partner decisions by tapping into the open ecosystem
  • Have confidence that the foundation of your PoC efforts has staying power due to backing from a growing, vendor-neutral community

Benefits to developers with IoT ecosystem providers (e.g. Device Makers, OEMs, ISVs, SIs):

  • Realize drag from end-user developers earlier in their PoC efforts without having to support myriad custom integrations with your commercial offerings
  • Grow your business faster via the network effect stemming from an open ecosystem with transparent and trusted security and manageability
  • Influence the development of an open commercial marketplace for EdgeX-certified components

More detail can be found in the overview deck. As highlighted, there will be community and commercial tracks for the dev kits. For options in the community track the bill of materials will be purchased independently online, code downloaded straight from a special repository on the project GitHub and questions answered through forums like the EdgeX Rocket Chat. We’re going to start small here and let the open source contributions grow organically.

The commercial track will provide EdgeX members with the ability to seed the emergence of an open marketplace for IoT edge computing. In turn, this will afford end users with attractive options to get started with professional support so they can focus on their preferred value-add instead of working with open source code.

The dev kit program will also help shape the definition of the formal certification program within the EdgeX project targeted for launch with the ‘Edinburgh’ code release in April 2019.  This program will enable anyone to certify that their proprietary offer is “EdgeX-compliant” based on following the specified set of interoperability APIs in Core Services regardless of additional IP added.

 

This is why the project is called “EdgeX Foundry” instead of the obvious “Edge Foundry” – the “X” allows the name to be trademarked. Imagine that “X” on your website which gives your customers comfort that you’re part of a broader, interoperable and trusted ecosystem. Stay tuned for more on this front and we welcome you to get involved in the certification planning working group!

Getting back to the dev kits, there will be several options available to you as a Technology or Services provider in the commercial track:

  1. “Core”: Offered by a provider who’s supporting the baseline EdgeX framework in a ‘Red Hat’ model while ultimately being completely neutral to all value-add such as hardware, OS, connected devices, analytics, security enhancements, platform, cloud, etc.
  2. “Platform”: A kit linked to a specific IoT software platform or cloud, enabling the customer to dive right in with your offer while still being able to take advantage of the ecosystem of plug-in EdgeX value-add
  3. “Plug-in”: Discrete plug-in value-add for devices/sensors, analytics, database, security, management, etc.

The benefit here is the network effect, for example if you offer an IoT platform you don’t need to support the baseline open source EdgeX framework if you don’t want to. Instead, you could partner with a “Core” commercial dev kit provider and simply support an Application microservice for your platform that complies with the APIs in Core Services while leveraging the communication protocol of your choice (standard or proprietary).  In another example, you might be a sensor maker who only supports Device Services in your chosen protocol and programming language (plugging into others’ “Core” and “Platform” dev kits), and so forth.

In order to participate in the dev kit program simply get going with the EdgeX code to develop your offer, establish your preferred commercial terms and contact pr@edgexfoundry.org to let the Linux Foundation team know your plans no later than October 5 if you want to be included in the IoT SWC press release.  More information will be available publicly closer to the announcement.

Note that we’re limiting the benefit of advertisement of commercial dev kit offers through official EdgeX channels to EdgeX project members at this time in order to limit scope while we perfect the process. This ultimately leads to an open commercial marketplace, so get in early and ride the wave!

Vertical Solution Working Groups

The Vertical Solution Working Groups (VSWGs, led by Samsung) are an important function within the EdgeX Foundry project.  We’ve had groups for Smart Factory (Samsung) and Oil and Gas (NOV) for some time to work through the process and are now ready to start ramping more groups to accelerate the strong foundation we’ve built to date. The VSWGs serve several important purposes:

  • Developing unique requirements and code contributions for their respective markets
  • Feeding requirements back into the EdgeX core working groups to optimize the baseline framework to be suitable for as many use cases as feasible spanning Industrial to Enterprise to Consumer, including B2B2C crossover in the domains of retail, healthcare, insurance, utilities, etc.  After all, the true promise of IoT is bringing together a system of systems, and what better way to span private and public domains than an open interoperability framework!

We welcome any member to volunteer to lead a new VSWG or join one already in flight. It’s a great way to demonstrate thought leadership while making sure the EdgeX foundation has the right features and specific extensions for the verticals and use cases that matter the most to you.

We’ve talked with members that are considering working groups around Buildings, Retail, Transportation, Healthcare, Smart Cities and Smart Homes so if any of these areas or others interest you, join on in, or create one for another domain! It’s a low time commitment to help speed up time to revenue in your respective space, not to mention learn from and influence others focused on the same space through open, vendor-neutral collaboration.

To learn more or start a new VSWG please email EdgeX-TSC-Vertical-Solutions@lists.edgexfoundry.org.

Exciting times ahead!

In closing, we have a lot of great things going on as a community just 16 short months since we launched the project, and we’re just scratching the surface of the opportunity ahead. Our future is bright, let’s really put on the gas as we head into the tail end of 2018!

Regards,

Jason Shepherd

Chair of the Board, EdgeX Foundry