All Posts By

EdgeX Foundry

Simplified IoT Powered by EdgeX Foundry

By | Blog

Guest blog post by Siddharth Tiwari, Chief Architect, Application and Big Data/IoT Transformation for Dell EMC

IoT is not just a buzz word, it’s a new way to make our surroundings and our lives more interactive and responsive. Here at Dell, we interact with customers day in and day out discussing various problems and issues.  Some relate to supply chain, some relate to fraud, some to yard management and then some to just mere optimizing customer interactions. Over time, I realized that many of these issues can be simply resolved by introducing more connectivity across various assets through the Internet of Things.

It’s easier said than done – connecting things together can get quite complex. Imagine having 100 people in a room. They’re all speaking different languages and trying to have a conversation. This is similar to what happens when one tries to connect desperate assets together. For example, some devices may talk SNMP, while some other may communicate over BACNET. It becomes challenging to bring all of them on to a common platform.

But not to worry!! EdgeX Foundry has come to the rescue! First of all, it simplifies the architecture, which can become really complex, by adopting a modular micro-service based approach. Secondly, since it’s highly extensible, it allows one to add and customize it based on needs. Last but not least, its footprint is so small that it can be easily run on something as small as a Raspberry Pi.

In this blog, I am going to demonstrate how EdgeX Foundry is simple to architect. When combined with our top of the line skills around data science and architecture, it becomes one of the most effective tools to solve really complex issues.

So, as a matter of introduction, I have been living in Arizona for a large part of my life. One issue I have had always grappled with has been the balance of Temperature and humidity. According to experts for healthy lifestyle, one must have at least 40 to 50% of humidity maintained at all times, whether winters or summers. But, when you live in a hot and dry place like Arizona, what you get is mostly 1% humidity, and as soon as winter arrives, all the heating from Air-conditioning reduces internal humidity again to 2 to 4%. Then you grapple with a challenge to maintain optimized temperature and humidity, which made me run my thermostat and humidifier constantly.

So that was my problem, and being a data scientist, I knew I can model this correlation out and create some kind of rule for optimizing the same. But, to achieve this, I needed consistent data and a little bit better enterprise grade acquisition mechanism and then resources to model this. After a lot of research, I found EdgeX, which helped me answer a lot of things in a straight forward manner. Finally, I decided to take more of an IoT approach to this problem, similar to how we go about helping our customers, so that I can repurpose some of this at an enterprise level.

What I needed to do were following:

  1. Ability to collect temperature and humidity outside, and at various locations inside.
  2. The collection points should operate at really low energy and must send all the data wirelessly.
  3. A gateway which could collect all this data and route it where I can store the data reliably.
  4. Ability to distribute the same over the internet, and utilize a publically exposable service to access data over an API.
  5. A rule engine, so that I could get a trigger over to take decisions.
  6. Something that can take these rules and convert the same into commands.
  7. Integration between my Thermostat and Humidifier.

Now, it was important to assign bill of material to above, so I chose following:

  1. Low power temperature and humidity sensor:- DHT22
  2. Low power module to broadcast this data: ESP8266 wifi module
  3. Dell 3000 to act as gateway
  4. EdgeXFoundry the brains, which gets all this data and routes it to end points
  5. Raspberry pi zero, which ran SNMP service to broadcast temperature and humidity so that edgeXFoundry’s device-snmp service can walk SNMP messages and distribute to external end points.
  6. Alexa SDK which became my central command center
  7. A Smart thermostat
  8. Humidifier
  9. A GPU based PowerEdge server to perform all the Deep Learning and Machine Learning activity

The Architecture looked something like below:

The first thing to be done was to broadcast the temperature and humidity values over from ESP8266 modules over UDP to Raspberry Pi and then extract the message from the packets and then make them accessible over SNMP.

We created firmware, which got the analog data from the sensor and broadcasted those values over UDP, over to raspberry Pi which was running SNMP service. Once we had the packets arrive, we needed to extend SNMP to broadcast humidity and temperature over two different individual OIDs. Honestly, this was the most difficult part.

Now, came EdgeX and rest of the things were cakewalk. Just three things and we were set:

  • Create an addressable
  • Create a device profile
  • Attach the device to a service – SNMP in our case

Now, all set to distribute data over to cloud hosted MQTT broker. Once we had all the data over to cloud, we created two streams: one where we utilized EdgeX Foundry’s rule engine to trigger certain events using Alexa’s SDK and the other to do all the machine learning in the backend and integrate the same with Alexa SDK to provide a decisioning engine.

We grabbed all the data in Azure to create real-time dashboards and collected data in a PowerEdge machine and ran multiple algorithms every 10 hours to create correlation between Humidity and Temperature and use it to tweak the level of Air conditioning, heating and humidification.

We ran hexplot, robust and KDE to make sure, we are getting best correlations, some of the outputs of the algorithms looked as below:

As it shows while temperature as more distributed pattern, humidity has single collocated pattern and both have a negative correlation coefficient of -0.6 and that is consistent across all three plots.

We used elastic search hosted in Azure to pull all this data and plot it on real-time using kabana.

Real-time Azure Dashboard

 

All events inside Elastic search

 

Visible negative correlation

While this is basic, it gave me a lot more useful and optimized methodology to maintain a balance between temperature and humidity. Not only this, I was able to predict certain level of impact of outside conditions towards the environment inside.

These parameters were exposed via a python based decision module to utilize Alexa SDK to proactively manage when and by how much I should humidify, cool or heat my home.

What was the outcome? Well EdgeX enabled me to simplify this task so much that it takes minutes for me to add more devices and definition to the data I receive or collect. Moreover, I maintain humidity of around 42% consistently around me, and as a byproduct I have ended up saving more than $35 on an average on my electricity bills.

Bottom line is, while IoT is a complex animal to handle, EdgeX makes it quite easy to integrate various different kind of devices and while doing that provides scalable way to distribute all this data to external endpoints. It automatically creates and enables a rules engine, which can take this information and enable one to create various triggers to effectively realize the potential of IoT.

On top of all this, our services enable simplification of complications which inhibit IoT adoption, from Engineering, data science and business perspective. Power of connected things is endless, and our solutions help streamlining and simplifying their adoption on all aspects.

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

Looking Back on EdgeX Foundry’s First Year and Preparing for Continued Growth in 2018

By | Blog

Written by Jason Shepherd, Chair of the EdgeX Foundry Governing Board and Dell Technologies IoT CTO

I can’t begin to express how exciting it is to see how what we started as a small team at Dell in July of 2015 has blossomed into a vibrant community of nearly 70 member companies with much more activity brewing behind the scenes. It truly is the most rewarding collaboration I’ve been part of in my career and I want to thank the many people that have helped along the way.

We’ve accomplished a lot as a community in just the past nine months since the April 2017 launch:

  • The Technical Steering Committee (TSC) and work groups are running smoothly and we have established a bi-annual release roadmap that we’re already meeting schedule commitments against – both with the first ‘Barcelona’ community release that dropped Oct 20 and the ‘California Preview’ last week.
  • Last October we announced an alliance with the Industrial Internet Consortium to collaborate on test beds and best practices and we’ve also established liaison agreements with multiple standards bodies and other open source projects.
  • More alliances are in the works across the board. Part of the power of EdgeX is that it’s a tangible foundation that can help standardization efforts work better together.

EdgeX Road Map

 

We’re all ears for new collaboration ideas that further the cause for greater IoT interoperability and adoption.

As with any open source project you don’t have to be a member to download or use the code, join the TSC meetings or participate in the working groups, but membership does come with benefits.  In addition to being visible on the logo boards as a thought leader and having direct (Platinum tier) or indirect (Silver tier) representation on the Governing Board we also offer a variety of events where members can join at a subsidized cost.

EdgeX Foundry Members

 

For example, we had our first official joint project presence at IoT Solutions World Congress in early October with 12 EdgeX member companies in attendance demonstrating their commercial value add on top of the EdgeX foundation. The booth was packed throughout the show and more events are in the works including Hannover Messe in April where we’ll celebrate our first birthday in the same spot it all got started a year prior.

Many EdgeX members have struck up new strategic relationships and even business since the project tends to act as a vendor-neutral IoT partner program.

Every day we’re seeing more and more active contributions from the community, a number of which are highlighted throughout this blog.

The blog on the Schlumberger contribution is a great example of the power of the project – just like that any existing southbound device connectivity now has a path to Google IoT Core.  We also already have an EdgeX Export Service for Azure IoT Suite and AWS is in process along with numerous other targets including the industrial clouds, tools like OSIsoft Pi, SAP Leonardo and IBM Watson.

Late last year the Dell team did a hackathon to tie AR tools into EdgeX to enable an entirely new UI experience. We’ve even prototyped with voice assistants like Amazon Alexa, enabling voice control of connected equipment through any number of underlying communication protocols.

Each of the posts below is a great example of the scale and innovation possible when developers stop reinventing the plumbing of an IoT stack and start focusing on value creation around the wheel.

On the south side, we’ll see device makers start providing EdgeX-compliant drivers with their products for greenfield applications, plus we’ll see a business models for creating and selling Edge-X compliant device services that interface with legacy equipment.

Beyond the core project we’ve seen the community expand in the form of university-sponsored EdgeX research efforts plus EdgeX-focused hackathons.  Throughout 2018 we’ll be encouraging more developer engagement through various types of channels.

We can always use more help so if you’re a developer and would like to get involved just dive in!  In terms of spreading the word in general a great starting point is by joining our Speaker’s Bureau.  And finally, nothing brings together a community like free food and drinks – so help us spread the word on EdgeX at your local IoT meetup and we’ll provide $250 for your tab.

Closing on the community aspect, while we greatly appreciate our founding and new members and their ongoing contributions and commitment to our cause what’s equally exciting is the activity that most don’t see behind the scenes – hundreds more companies in various forms of engagement spanning active evaluation to building PoCs to even incorporating EdgeX into their commercial products.

Are we there yet?

Speaking of commercialization, customers ask me all the time when EdgeX “will be ready”. My first answer is always this – whenever you package up a version of the code and pick up the phone to offer customer support. But then I expand by saying that I see field PoCs beginning to scale out this summer after the June California release and production deployments increasingly spinning up later this year.

Frankly, the EdgeX code base is more mature today than what a lot of people are hacking together out there for PoCs but at the same time we want to make sure we do things right. Aside from the massive reduction in footprint from the original seed code (more on that later) the biggest inflection point in June will be the addition of key security and manageability features.

From a Dell perspective, we purposely didn’t include much for security in the initial seed contribution because we felt it was important that these features are defined by the community so they’re universally trusted. So, for the past 9 months there has been a global collaboration between security and manageability leaders to define layer upon layer of security modules and management practices with the first wave of functionality from a broader roadmap hitting in June.

And like everything else, the baseline plumbing APIs and reference services for this functionality will be open to enable a variety of best-in-class commercially-licensed EdgeX-compliant plug-ins for security and manageability functionality.

Most importantly, we’re starting to see the EdgeX framework being included in projects by end customers.  I haven’t yet met an end user who doesn’t love the benefits an open ecosystem that provides freedom of choice to make or buy value-added components. Important to any open source project is the commercialization aspect as while many end customers love the benefits of EdgeX they don’t necessarily want to support the open source baseline themselves.

Numerous companies are already launching their own commercially-supported versions of EdgeX together with developer support. I need to stay vendor-neutral here but definitely keep an eye out for more on this front!

Size (and speed) matters.

When Dell started incubating the code that became EdgeX, we were more interested in the right architecture for facilitating and building an ecosystem than optimizing the starting footprint.  As such, our original contribution that was based on Java and some Javascript and Python had a pretty large footprint.

However, the beauty of a microservices framework is that each component can be individually replaced with more compact versions that leverage the same APIs.

Fast forward to now and the Go Lang-based microservice alternatives in last week’s “California-preview” release demonstrate a path to reducing the footprint and boot times by an order of magnitude.

The code is in the GitHub now – download and give it a spin!

The net effect is that soon the full EdgeX stack will run on a Raspberry Pi-class device and of course microservices can be broken apart in any combination to run on even lighter weight devices.

Further, there’s no reason various sections of the code can’t be combined in commercial implementations using the same foundational APIs – it really comes down to a tradeoff of performance over flexibility.

Get on the bus!

In addition to the massive footprint reduction, work is already underway for a message bus option to improve throughput for streaming data between microservices as compared to the current REST-based intercommunication.

This combined with the overall Go Lang work for reducing footprint is driving increased interest across the board. We purposely didn’t start with a high performance, low footprint foundation because it’s important to allow the community to creep up on what’s table stakes for open source versus valuable to make proprietary while still leveraging the common APIs for interoperability.

It’s all about the APIs.

This ability to build proprietary, interchangeable components brings me to one of the first misconceptions that I encounter when I talk with people about EdgeX.

Some think that you have to give away all of your IP because it’s an open source project. However this is far from the case because the EdgeX project has been carefully architected to enable commercial value-add around a lowest-common denominator open source foundation, more specifically the associated APIs.  As such, you don’t have to contribute any value-added functionality you develop to open source, rather you’d just leverage the specified open SDKs and/or APIs to create them if you want to be “EdgeX-compliant”.

The bottom line is that EdgeX is more about the community-governed APIs than the code itself and you can replace every lick of code and still be “EdgeX-compliant” by following the baseline APIs.  So, in the future we’ll see proprietary high-performance versions that use the same foundational EdgeX APIs.  For example, by replacing the current Core Services baseline with a compressed C-based binary you could enable PLCs that can be software-defined with plug-in value add from the ecosystem.

There are many opportunities for proprietary value add beyond the EdgeX foundation spanning functions for real-time operation, workload orchestration, load balancing, failover, redundancy, TSN, security, system management, analytics and device drivers. This ability to monetize within an open, hardware- (e.g. x86, ARM), OS- (e.g. Linux, Windows, Unix, RTOS) and protocol-agnostic ecosystem while minimizing reinvention is what’s driving so much interest in the project.

What’s with that ‘X’?

Clearly “Edge Foundry” plays off of Cloud Foundry but we sometimes get the question “what’s with that X?”

The answer is that the X allowed the project name to be trademarked for use as a future certification mark. We’re targeting a launch of a certification program within the Linux Foundation project early in 2019 and this vendor-neutral effort will enable providers to certify that regardless how much they added to or changed the baseline code for their commercial offering they maintained the specified EdgeX APIs that facilitate interoperability.

Stability for key elements in the certification program (e.g. required APIs and overall process) will be maintained through the EdgeX Technical Steering Committee (TSC) and a versioning system.  This certified value-add can be a full EdgeX-compliant IoT platform, a value-added plug-in microservice(s) or a services model that taps into the APIs.

Imagine your offering accompanied by the EdgeX logo which gives customers the confidence that they can readily plug it into their solution… now that scales!

It’s not just about gateways.

A second misconception I often see is that EdgeX is only about edge gateways.

While it’s most tangible to first talk about the project in the context of gateways because these devices are inherently a place where “south meets north” in an IoT stack, the loosely-coupled microservices architecture enables interoperable value-add to come together across any sort of distributed computing model.

Microservices serving various functions can be deployed in any number of different types of container or VM technologies – all on one device or spread across many devices working together in a broader networked system.

Device Services can be broken out and deployed on capable smart sensors that in turn communicate directly with a server in a datacenter or in the cloud – look ma, no gateway!

Further, we’re starting to see people experiment with the idea of co-processing within one device by running the Core and Export Services on the main host processor and analytics on a co-processor (e.g. GPU or FPGA) for acceleration.

In all cases these functions – whether based heavily on the open source code or 100% net-new proprietary code – can be written in any different programming language and be bound together by the common EdgeX APIs.

Net-net, we’ve had thousands of conversations with partners and end customers regarding the project approach and every day it becomes even clearer how EdgeX benefits end users in the inherently heterogeneous IoT market.

The enablement of distributed computing is what really sets EdgeX apart – there are many great open source efforts out there but there remains to be nothing like EdgeX for facilitating a truly open ecosystem for distributed IoT edge computing.

Putting things in perspective.

The IoT market is messy and there are a lot of solutions looking for problems out there, so as the code takes shape to facilitate grater interoperability we’re also working together to put the project in perspective for valuable real-world use cases.

Samsung is chairing a Vertical Solutions Working Group that will host specific use case-focused projects that drive requirements from end users back into the roadmap in addition to developing and deploying test beds.  They’re organizing one themselves for smart factories and the TSC recently approved a proposal from National Oilwell Varco (NOV) to spin up a project for Oil and Gas.

The working group will host similar efforts for many other industries and use cases and each will be a great way to prove out the platform in real-world settings. Building Automation is likely one of the next efforts to spin up and we encourage you to step forward and collaborate with industry peers on other key use cases spanning transportation to retail to healthcare and beyond.

As things progress we’ll group common paradigms as appropriate (for example needs for remote oil and gas and mining sites are very similar) while recognizing unique needs, ecosystem players and standards by industry.

Last month we launched an effort to post relatable stories about these use cases enabled by EdgeX in online communications.  Stay tuned for more details there.

With that I’ll close for now.  Again, thanks to everyone for their contributions to date and I look forward to what’s in store for 2018!

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

Running EdgeX Foundry on Kubernetes

By | Blog

Guest blog post by Rohit P Sardesai, System Architect, Huawei Technologies India Pvt Ltd.

Why Kubernetes for Edge?

An edge computing platform comprises of many management and application services deployed on tens of thousands of edge-gateways managing millions of devices. Ensuring reliability and scalability of these services at such a large scale can be ensured by a platform like Kubernetes which orchestrates containers in a scalable and highly available way.

Kubernetes Pods and Deployments

Pods are the smallest deployable units of computing that can be created and managed in Kubernetes. A pod is a group of one or more containers logically co-located to share the same network, volumes etc.

A Deployment is a controller which manages pods and ensures the desired number of pods are always running.

An EdgeX core-metadata deployment yaml could be defined as below:

Figure 1. Metadata-deployment.yaml

 

The spec defines the containers to run, docker image to use, and ports to expose.

Kubernetes volumes

A Kubernetes volume is just a directory to store some data. To use a volume, a pod specifies what volumes to provide and where to mount those into containers. In Fig 1 above, volumes and volumeMounts are specified for the mongodb data, logs, and consul-config and consul-data directories.

Kubernetes Services

A Kubernetes Service is acts an intermediary for pods to talk to each other, providing features like load balancer and service-discovery. It routes the requests to backing pods based on matching labels.

Figure 2: EdgeX Services Communication

 

An EdgeX core-metadata Service yaml could be described as below:

Figure 3: Metadata-service.yaml

 

The config-seed service in EdgeX currently provides service discovery for all other services. Kubernetes Services serve the same purpose, so we don’t need to run the config-seed service in Kubernetes.

All other EdgeX micro-services have a dependency on the config-seed service which can be removed by setting the setting spring.consul.enabled to false in bootstrap.properties and rebuilding the docker image.

Figure 4: Disable consul dependency

Setting up a single node Kubernetes cluster

kubeadm tool can be used to setup a single node Kubernetes cluster :  https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/

Kubernetes supports different pod network add-ons implementing the Container Network Interface (CNI). I used Weave as the pod network add-on.

If using weave, make sure you start kubeadm with the correct pod-network-cidr range:

$kubeadm init –pod-network-cidr=10.244.0.0/16

Next, install the Weave pod network:

$kubectl apply -f “https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d ‘\n’)”

Creating Services and Deployments

Create Service objects for all the EdgeX micro-services using the kubectl command line tool.

$kubectl create –f <service.yaml>

Next, create the Deployment objects for all the services.

$kubectl create –f <deployment.yaml>

The order of creation of the deployment objects is similar to the Docker Compose approach. The only difference being we don’t bring up the volume and config-seed services.

Deployment and Service yamls and scripts to create the EdgeX Services and Deployments can be found here: https://github.com/rohitsardesai83/edgex-on-kubernetes

Figure 5: Project structure

 

The scripts in the hack folder can be used to bring up/down the EdgeX services.

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

EdgeX F2F TSC Meeting and the evolution of the EdgeX Cadence

By | Blog

Written by Dell’s Jim White, EdgeX Foundry TSC Member and Chair of Core Services Working Group

Last week (Jan 16-18), the EdgeX Foundry Technical Steering Committee (TSC) had our 4th face-to-face meeting in Orlando.  Our previous meetings were held in Boston (June), London (July) and Barcelona (October).

All of the EdgeX project business is conduct in an open fashion, so we invite anyone with input and something to contribute to join us in our face to face meetings.  To that end, while we had 10 TSC members in attendance, we also 14 non-TSC members attend, with another dozen joining at some point during the week by conference call.  The EdgeX technical community is certainly alive and well!

Our meeting topics were far and wide, but the central themes were focused on:

  1. The work tasks and duties around getting the California Release out (scheduled for June 2018)
  2. Architectural issues that need addressing for the California Release and beyond

California Release Planned

The California Release will include the first EdgeX security and system management features.  There is much work to be done, but the committee agreed on the implementation of these first elements toward offering a more secure and better managed EdgeX platform by June:

  • An open source reverse proxy will be selected and integrated in to EdgeX to protect against unauthorized access of the micro service REST APIs.
  • An open source authentication/authorization service will be incorporated in to EdgeX and be used by the reverse proxy, but other elements of EdgeX in the future.
  • An open source data protection service will be integrated in to EdgeX to provide key management, certificate services, and encryption capability – which can and will be used by several elements of EdgeX.
  • Each micro service will be outfitted with a system management API that allows it to set the service’s administrative state, stop the service, or get/set its configuration among other operations.
  • A system management micro service (call the system management agent) will facilitate 3rd party requests (eventually in a system management API of choice like OMA LwM2M, SNMP, etc.) while also performing more broad operations such as restarting all micro services.

Architectural Resolutions

As with any software system, there are a number of architecture issues which need to be addressed – or on occasion readdressed – as the platform evolves.  With EdgeX, we are learning that face-to-face meetings are a great place to tackle the architectural decisions where brainstorming, whiteboarding, and extended conversations over lunch/dinner/drinks can really help to resolve issues that don’t fit in our weekly working group conference calls.

The architectural topics discussed and resolved during our meeting last week include:

  • EdgeX will officially support one main “reference implementation” of any micro service at a time going forward. With Go Lang micro services being created to help reduce the footprint, startup time, and performance associated to some of our Java micro services, the question was raised as to what happens to the Java micro services once the Go Lang replacements are ready?  We decided that going forward, the community would have one main implementation of each micro service, but if others in the community were willing to help maintain/support other implementations, they could be retained as “alternate” implementations – otherwise they would be archived.  EdgeX remains committed to its polyglot tenet – that is, any micro service can be allowed to be created using any programming language of choice.  The reference implementation of each micro service will be the implementation that the community believes is the best implementation – regardless of language – while also meeting the API requirements and quality agreements for that service.
  • EdgeX is starting to receive some sizable contributions. How do we take on large code contributions from the community?  What’s the process for ingesting the code, making sure it fits the current architecture (or plan-fully rethink the current architecture if necessary), and meets quality levels expected of the project?  A new contribution process and tooling framework was designed by the community to deal with this need.  More information will be made available on the Wiki as this is drafted and formalized.
  • EdgeX uses Docker and Docker Compose for its deployment architecture today. What does EdgeX want to support in the future?  The community agreed to continue to use Docker and Docker Compose but also allow members of our community to present alternatives and ideas for additional solutions – like Kubernetes – in the near future.
  • With multiple Device Service SDK’s to be constructed in different languages over this release cycle, what elements of design should the different SDKs share and where can they be different? Our Device Services Working Group chairman is going to lead a requirements session followed by a design session in the coming months to bring some conclusions to this issue.

Other Significant Work

What else was covered in our face-to-face meeting?  Plenty!  You can see a deck of resolutions and action items here.

Additionally, if you want to see the agenda or listen to recordings of the meeting, you can also find them on our Wiki.

Other highlights include:

  • We resolved to make the California Preview available by Jan 31st. The Preview will include the Go Lang Core service replacements and demonstrate, dramatically, improvements in micro service footprint, memory and CPU usage, and start up times.  I’ll have another blog post in the near future to outline the performance improvements we are seeing with Go Lang.
  • In addition to security and system management, the California Release will include more complete blackbox testing as well as performance tests, native ARM testing, SDKs in C and Go Lang, and improved documentation
  • We revised and updated our roadmaps for the Delhi release (Oct 2018) and newly named Edinburgh Release (April 2019). Look soon to our project Wiki for details on these updates.
  • Plans were made to participate, formally as a community, with presentations/demos at Hannover Messe and IoT Solutions World Congress among other potential conferences this year.
  • We also resolved to meet again for our next face-to-face in June, right after the California release, to plan the Delhi release at a venue to be determined.

And We Had Fun!!!

Being a part of EdgeX has been a highlight to my career.  The community of experts that participate in EdgeX Foundry are just plain good people to be around.  There are some spirited discussions, but egos are always checked at the door in these meetings.

We always manage to get in at least one community dinner, and for this meeting, our dinner was at the top of the Orlando airport’s Hyatt hotel.  Plenty of good spirits and spectacular views to go around.

A number of our community planned to go to Cape Canaveral to see a rocket launch on the last evening.  Unfortunately, the launch was cancelled due to weather.  But this gave us all an appetite to one day see EdgeX in “SpaceX” and come back to see another launch.

Learn How to Connect New Devices and Sensors Quickly with these EdgeX Device Service/Device Profile Tutorials

By | Blog

Written by Dell’s Jim White, EdgeX Foundry TSC Member and  Chair of Core Services Working Group

As you explore EdgeX Foundry, one of its strengths is its ability to bring on connectivity to new devices and sensors quickly.  This is facilitated by the device service SDK and device profiles.

Recently, Chad Young of Dell helped create some wonderful additions to the EdgeX tutorial set in these areas.  Chad create a collection of videos to give better examples of how to use the SDK to create a device service in a step by step video guide.  These videos can be found on the EdgeX Foundry YouTube channel: https://www.youtube.com/c/EdgeXFoundry. He also created a Wiki page in the EdgeX documentation that covers the same:  https://wiki.edgexfoundry.org/display/FA/Modbus+-+Adding+a+device+to+EdgeX.

For additional background, Tyler Cox also from the Dell team added more documentation about the device profile, providing more details and linked in references to examples (https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=7602686).

Device services are the micro service connectors interacting with the devices or IoT objects that include, but are not limited to: appliances in your home, alarm systems, HVAC equipment, lighting, machines in any industry, irrigation systems, drones, traffic signals, automated transportation, and so forth.

The device services communicate with the devices, sensors, actuators, and other IoT “things” through protocols native to the IoT object. The DS Layer converts the data produced and communicated by the IoT object, into a common EdgeX Foundry data structure, and sends that converted data into the Core Services layer, and to other microservices in other layers of EdgeX Foundry.

As one might expect, the device service SDK helps developers create the device service micro services.  The SDK provides the boilerplate code – what we can the device service scaffolding – to which a developer can more quickly add the specific elements for communicating with a type of device/sensor and get it plugged into EdgeX.

Each specific device and sensor that is managed by EdgeX Foundry must be registered with Metadata and have a unique ID associated to it. Information, such as the device’s or sensor’s address is stored with that identifier. Each device and sensor is also associated to a device profile. This association enables Metadata to apply generic knowledge provided by the device profile to each device and sensor that is connected via the device service to EdgeX.

The additional tutorials and documentation were as a result of requests from the EdgeX community for more help.  We heard and continue to listen to community requests.  Please keep the feedback coming!

We hope the community will find these additions in the tutorials and documentation around the SDK and device profile helpful, and our thanks to Chad and Tyler for their great work.

Porting EdgeX to Pivotal Cloud Foundry

By | Blog

Guest blog post by Trevor Conn, Principal Software Engineer, Dell Technologies

A short while ago I was introduced to the EdgeX Foundry platform when I attended a local IoT Meetup in Austin, TX. The presentation was given by fellow Dell Technologies colleague Jim White and I went up to introduce myself afterwards. We discussed the future possibility of making the EdgeX Foundry services cloud ready and I told him of my experience using Pivotal Cloud Foundry (PCF) in a production environment. Given the popularity of PCF, we thought it would make sense to see what it would take to port a couple EdgeX services into the platform.

The proof of concept I present below involves porting two of the foundational EdgeX services to PCF and then calling those services from the Virtual Device service running on my local workstation. Basically, I took the scenario Jim presents in Session 1 of the EdgeX Foundry Tech talks as my scope of work for this proof of concept. If you’re going to follow along, then you will want to fork the Github repos for the following three services:

You will be making changes to the first two, deploying those to PCF and then running the last service on your local machine while pointing to your PCF deployments.

The changes to be made to core-data and core-metadata are essentially the same:

1.Add three new packages for Spring Cloud functionality with regard to configuration, as well as PCF integration. You accomplish this by adding the following to the pom.xml

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-localconfig-connector</artifactId>

<version>2.0.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-cloudfoundry-connector</artifactId>

<version>2.0.1.RELEASE</version>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-spring-service-connector</artifactId>

<version>2.0.1.RELEASE</version>

</dependency>

2. Next, add another configuration class which will be annotated with @Profile in order to differentiate which configuration to use when deployed to a PCF cloud environment versus the default local environment. In my case, I called this new class “CloudConfig” and inherited from AbstractCloudConfig.

3. As you can see in the screenshot above, a new property is necessary to indicate the name of the data service we need to connect to. In our case, this is a Mongo database hosted outside of PCF. However, we still need to provide the cloud infrastructure with a name and a connection string whereby the persistence layer can function. I’ll go into more details about that below. For now, add the following entries to the application.properties file:

#—————–Mongo Cloud Config——————————————

spring.cloud.appId:    edgex-core-data

spring.cloud.data-service: mongodb-coredata

The data-service value will be injected into the private dataServiceName member.

4. Since we are now distinguishing our configuration by profile, I needed to also add an @Profile annotation to the existing AppConfig class.

5. In our case, connectivity to Mongo was a little challenging. The PCF infrastructure at our disposal does not have MongoDB available within the cloud marketplace. That is to say, Mongo for PCF is not enabled. The only option available was to set up a Mongo instance on an external VM and then configure a user provided service within PCF consisting of the service’s name and a connection string. This limitation unfortunately meant I could not utilize the auto-configuration that Spring Cloud Service Connectors

Once I had the user provided service created, I then implemented my Mongo client within the above CloudConfig class like so:

So as you can see, the dataServiceName is used to find the service within PCF. Since we know we’re trying to access a Mongo database, I then cast the ServiceInfo to a MongoServiceInfo which gives me access to the URI I specified when creating my user defined service.

6. With those changes in place you’re ready to deploy. PCF will require a manifest file during deployment that provides parameters for the definition of the container your service will run on. Rather than including all of the content here, I will just link to the manifest file I created for the core-data service. The core-metadata manifest is the same except for the application name.

For a thorough explanation of what all of these settings mean, I refer you to the Cloud Foundry manifest documentation.

7. For the actual deployment, I found that it required use of both the Cloud Foundry command line as well as the Boot Dashboard provided within the Spring Tool Suite editor. There is certainly a way to streamline this step, but I have not had time to dig into it further. You would want to eliminate reliance on the Boot Dashboard for any kind of real deployment pipeline.

The issues I faced here were as follows:

  • The CF command line would provision the container appropriately, download the necessary buildpacks, create the necessary mappings for the user provided service to my application, but then it could never successfully build the application.
  • The Boot Dashboard was unable to do any of the above if I was deploying the service for the first time. At the point where it should have created the initial mapping of the services, it would just hang and then time out.

The approach I took for deployment of new services was to use the command line tool first, which would establish the necessary scaffolding in PCF, and then use the Boot Dashboard to deploy the code and get it built correctly.

Again, a little more work needs to be done here to make this cleaner.

8. And with all of that done, you’re ready to test!

Again, the test scenario involves running the Virtual Device service locally and pointing it to the deployed PCF endpoints. There are two changes necessary to the properties of the device-virtual project

  • In the src/main/resources/rest-endpoint.properties file, you will want to change all of the entries to point to the relevant PCF routes instead of localhost
  • In the src/main/resources/application.properties file, you will want to change the “service.host” value to either your IP address or your fully qualified host name

        ** NOTE: In our case we were running our tests on a VPN whereby our local machines were on the same network as the PCF cluster. If you are behind a firewall trying to hit an external PCF cluster, this reverse lookup will not work without some additional network configuration. **

9. Start the device-virtual project as a Java application and you should start seeing the core-data service’s event counter increment.

The above was a fun, brief initiative undertaken in order to gauge the amount of work necessary to move the whole EdgeX Foundry platform to a cloud infrastructure. Due to the modularity of Spring along with the flexibility in the design of the EdgeX services themselves, the changes needed to accomplish this were not at all extensive. With this effort somewhat quantified, I look forward to hopefully working more on these capabilities in the coming year.

Performance Vs Flexibility – EdgeX Microservices Could be Combined

By | Blog

Written by Dell’s Jim White, EdgeX Foundry TSC Member and  Chair of Core Services Working Group

I was posed a great question recently by one of our EdgeX contributors.  As he suggested, he was “wrapping his head around EdgeX” when he wondered if it made sense to have the core microservice (those being core data, core metadata, and core command) all be different microservices.  As he commented: “I think the microservice design is a good option, allowing to separate some components outside of the core of EdgeX”, but as he further suggested, “it seems that a lot of time and CPU is spent with RPC between those microservices.”  Would it be better (both easier and faster), he mused, “to have only one core service implementing all those together?”

As I indicated to this developer – he can consider his head fully wrapped around the EdgeX architecture if he is coming to such questions.  Indeed, his question is a legitimate consideration.  Architecture is about tradeoffs.  EdgeX is about offering options to meet the potential tradeoff considerations.  In this case, performance versus flexibility.

We (the original creators of EdgeX) believe there are legitimate reasons why you may want to separate those concerns (core data, metadata and command).  As each is a different function, you may need to improve or significantly modify one of the functions.

For example, we envision a very different and more secure offering of command microservice in the future that checks authentication/authorization before actuation is allowed on a device.  The microservices may need/want to separate their repositories.  Both core data and metadata use MongoDB today, but we have seen situations at Dell (and actually done implementations) where for security, performance, or other reasons that the underlying persistent storage is different for each microservice.  The sensitivity of the incoming sensor data may be such that the core data microservice has to be constructed differently and completely isolated from metadata and command to meet legal or regulatory considerations.  There may also be cases where, due to availability of resources or need (or again to secure some data), that the various functions need to reside physically on different platforms (EdgeX on a more distributed layout).

Having said this, there are also other use cases where these core microservices (and others) may be combined – as indicated by the contributor, likely for optimal performance, to in order to reduce footprint, etc..  In fact, at Dell we conducted such an exercise to prove this out.  By combining core data, metadata and command, we were able to reduce the footprint and improve performance of the Java core services significantly and we envision going forward there will be, potentially, an offering of a single “combined” core microservice in EdgeX.  This will be at the expense of flexibility, but for those looking to productize EdgeX, this may be a perfectly acceptable trade off.

Productization of EdgeX and its use in real world edge/IoT use case scenarios are apt to uncover all sorts of interesting needs.  EdgeX is a collection of building blocks to create a solution.  Some refinements and adjustments to EdgeX may, and probably will, need to be made to accommodate a particular use case.  The flexibility of EdgeX is its strength.  And don’t forget, the flexibility allows those who adopt and embrace it to figure out ways to add value – and thereby generate potential revenue – from their adaptations.

So, the contributor that asked the question about potentially combining microservices was absolutely right on track with his thinking.  We will welcome combined core service (or other services) as alternatives as EdgeX marches forward – while at the same time maintaining separate core microservices to support other use cases.  The beauty of microservices is that they can be replaced and augmented in many ways – in some cases by collapsing them.

EdgeX enables Phenomenal Applications

By | Blog

Guest blog by Marc Hammons and Tyler Cox (Dell Client CTO Software Architecture Team)

For those not yet in the know, EdgeX Foundry is a platform that provides IoT edge computing; making it easier to connect your “things” (sensors and devices) to the rest of your enterprise and allowing your enterprise to interact and help control those things.

Today, EdgeX is headless – there is no user interface.  The beauty of the platform is that it enables any type of interface – new or existing.   The idea is for organizations to use any preferred cloud or enterprise dashboard and management console with EdgeX to monitor and control their things that communicate via any standard.  The EdgeX community believes this presents an incredible opportunity for differentiation via entirely new and innovative user interfaces to help manage IoT deployments.  A few organizations like Dell have built some UIs for demonstration purposes. Now, we encourage EdgeX community members to add unique value by creating open source or commercial interfaces for EdgeX.

During a recent local hackathon, the Dell client CTO team completed a unique interface for interacting with sensors and devices that interoperate through the EdgeX framework.  The result was an amazing augmented reality (AR) interface to observe the readings coming from sensors and actuate the devices with hand signals.  Take a look at the video below demonstrating several things being controlled by the Dell AR app integrated with EdgeX.

EdgeX helps to normalize control of the edge to a common set of easy to use APIs regardless of the underlying communication protocols. This demo shows how those APIs allow some wonderfully new and imaginative ways to visualize and control resulting data feeds.  EdgeX helps users stop reinventing and instead focus on innovation – this is where the payoff of IoT and edge computing starts to show signs of revolutionizing our lives!

This demo shows connectivity and control of a Modbus motor, SNMP managed Patlite, and Bosch BLE sensor pack through the AR headset and EdgeX, but imagine how the same principles could be used by support technicians inside of a complex factory control room, workers performing field maintenance on machines, sensor-enabled distribution centers, or even working within your company’s own server room.  That’s what could happen as we, the IoT community, collaborate on common interoperability frameworks like EdgeX, which makes it easier for application providers to focus their efforts on creating amazing interfaces among other valuable innovations.

For those interested in more of the tech details, the team used the Meta 2 AR headset and the Darknet open source neural network framework with its “you only look once” (YOLO) algorithm to help enable the system to recognize the various connected devices.  Unity was used to create the AR application interface that interacts with EdgeX version 0.2 running on the Dell Edge Gateway 5000.  The entire application was created in the two day hackathon – which speaks to the ease of use and utility of the EdgeX framework.

For more information, you can check out these resources:

Recap: EdgeX Foundry’s First Technical Face-to-Face

By | Blog

Ahead of the EdgeX Foundry technical meeting happening in London this week, we wanted to share some highlights from our first technical Face-to-Face (F2F) meeting, which took place in Boston at the beginning of June. A special thanks to everyone who attended and to Analog Devices for graciously hosting us at their headquarters.

We had a diverse group of participants from across the IoT landscape including start-ups, established companies, system integrators, cloud service providers and hardware manufacturers.  More than 60 people traveled to Boston from across the U.S. and as far away as Norway, France and Poland, with an additional 20+ joining remotely by phone. Companies participating in the meeting included Analog Devices, ARM, Canonical, Dell EMC, ForgeRock, GE, IBM, Linaro, NetFoundry, Neustar, Object Management Group, Parallel Machines, Schneider Electric, Siemens, Switch Automation, RSA and Two Bulls.

The working meeting brought together technical representatives from EdgeX Foundry member companies as well as the wider technical community to align on project goals, develop working groups, establish the Technical Steering Committee (TSC) structure and begin discussing next steps for EdgeX Foundry including a future certification program.

Meeting highlights include appointing Keith Steele, CEO of IOTech, as chair of the Technical Steering Committee (TSC) and approving the formation of eight initial EdgeX working groups:

This week’s meeting is being hosted by Dell EMC to discuss the goals and objectives for the first MVP release named Barcelona due out this fall. A draft Barcelona MVP plan is available here

Interested in joining the next TSC meeting or participating in a working group? Subscribe to one of our mailing lists or visit the EdgeX wiki to stay up-to-date on upcoming face-to-face meetings and technical developments. You can also follow us on Twitter or LinkedIn for the latest news and announcements.

Full notes, presentations and recordings from the Boston face-to-face are also available on the EdgeX wiki.

New EdgeX Foundry Unifies the IoT Marketplace to Accelerate Enterprise IoT Deployments

By | Announcement

50 companies join new Linux Foundation project to build an open framework for IoT edge computing

HANNOVER (HANNOVER MESSE) AND SAN FRANCISCO – April 24, 2017 – The Linux Foundation today announced the launch of EdgeX Foundry, an open source project to build a common open framework for Internet of Things (IoT) edge computing and an ecosystem of interoperable components that unifies the marketplace and accelerates enterprise and Industrial IoT. The initiative is aligned around a common goal: the simplification and standardization of Industrial IoT edge computing, while still allowing the ecosystem to add significant value.

IoT is delivering significant business value by improving efficiencies and increasing revenue through automation and analytics, but widespread fragmentation and the lack of a common IoT solution framework are hindering broad adoption and stalling market growth. The complexity of the current landscape and the wide variety of components creates paralysis. EdgeX solves this by making it easy to quickly create IoT edge solutions that have the flexibility to adapt to changing business needs.

“Success in Internet of Things is dependent on having a healthy ecosystem that can deliver interoperability and drive digital transformation,” said Jim Zemlin, Executive Director of The Linux Foundation. “EdgeX Foundry is aligning market leaders around a common framework, which will drive IoT adoption and enable businesses to focus on developing innovative use cases that impact the bottom line.”

Unifying the IoT Market

EdgeX Foundry is unifying the marketplace around a common open framework and building an ecosystem of companies offering interoperable plug-and-play components. Designed to run on any hardware or operating system and with any combination of application environments, EdgeX can quickly and easily deliver interoperability between connected devices, applications, and services, across a wide range of use cases. Interoperability between community-developed software will be maintained through a certification program.

Dell is seeding EdgeX Foundry with its FUSE source code base under Apache 2.0. The contribution consists of more than a dozen microservices and over 125,000 lines of code and was architected with feedback from hundreds of technology providers and end users to facilitate interoperability between existing connectivity standards and commercial value-add such as edge analytics, security, system management and services. This is complemented by the recent merger of the IoTX project into the EdgeX effort, which was previously supported by EdgeX Foundry members including Two Bulls and Beechwoods Software, among others. Additional supporting code contributions by EdgeX members are already underway.

“One of the key factors holding back IoT designs in the enterprise is that there are too many choices to safely and easily implement a system that will provide a return on investment in a reasonable timeframe,” said Mike Krell, Lead IoT Analyst at Moor Insights & Strategy. “EdgeX Foundry will fundamentally change the market dynamic by allowing enterprise IoT applications to choose from a myriad of best-in-class software, hardware and services providers based on their specific needs.”

Founding members include: Advanced Micro Devices (AMD), Alleantia, Analog Devices, Bayshore Networks, Beechwoods Software, Canonical, ClearBlade, CloudPlugs, Cloud of Things, Cumulocity, Davra Networks, Dell, Device Authority, Eigen Innovations, EpiSensor, FogHorn Systems, ForgeRock, Great Bay Software, IMS Evolve, IOTech, IoTium, KMC Controls, Kodaro, Linaro, MachineShop, Mobiliya, Mocana, Modius, NetFoundry, Neustar, Opto 22, relayr, RevTwo, RFMicron, Sight Machine, SoloInsight, Striim, Switch Automation, Two Bulls, V5 Systems, Vantiq, VMware and ZingBox. Industry affiliate members include: Cloud Foundry Foundation, EnOcean Alliance, Mainflux, Object Management Group, Project Haystack and ULE Alliance.

Delivering IoT at the Edge

According to a Gartner report, there will be 20.4 billion connected things in use globally by 2020. The sheer quantity of data that will be transmitted from these devices is driving adoption of edge computing, where connected devices and sensors transmit data to a local gateway device instead of sending it back to the cloud or a central data center. Edge computing is ideal for deploying IoT applications because it allows for quicker data analytics and reduced network traffic. This is essential for applications which require localized, real-time data analysis for decision making such as factory optimization, predictive maintenance, remote asset management, building automation, fleet management and logistics.

“Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions, before they can even deploy IoT solutions to address business challenges,” said Philip DesAutels, PhD Senior Director of IoT at The Linux Foundation. “EdgeX will foster an ecosystem of interoperable components from a variety of vendors, so that resources can be spent on driving business value instead of combining and integrating IoT components.”

Adopting an open source edge software platform benefits the entire IoT ecosystem:

  • End customers can deploy IoT edge solutions quickly and easily with the flexibility to dynamically adapt to changing business needs;
  • Hardware Manufacturers can scale faster with an interoperable partner ecosystem and more robust security and system management;
  • Independent Software Vendors can benefit from interoperability with 3rd party applications and hardware without reinventing connectivity;
  • Sensor/Device Makers can write an application-level device driver with a selected protocol once using the SDK and get pull from all solution providers;
  • System Integrators can get to market faster with plug-and-play ingredients combined with their own proprietary inventions.

The Linux Foundation will establish a governance and membership structure for EdgeX Foundry to nurture a vibrant technical community. A Governing Board will guide business decisions, marketing and ensure alignment between the technical communities and members. The technical steering committee will provide leadership on the code and guide the technical direction of the project.

Hannover Messe

Live demonstrations of the EdgeX platform will be on display at Hannover Messe in Hannover, Germany from April 24-28, 2017. The main EdgeX demo will be at the Dell Technologies kiosk in the Industrial Internet Consortium Pavilion (Hall 8, Stand C24).

Additional EdgeX demos will be in the following member areas:

  • ForgeRock (Hall 8, Stand F31/1): edge security
  • Opto 22/Dell/Linaro (Hall 8, Stand F31): integration with Opto 22’s control and I/O system transmitting sensor information from a scale model wind turbine to EdgeX; Linaro demo of an over-the-air firmware upgrade of a wireless sensor
  • SAP/Dell/IOTech (Hall 7, Stand B4): ingestion of OPC-UA data from a National Instruments CompactRIO

Industry Support for EdgeX Foundry

Analog Devices
“This strategic partnership with EdgeX Foundry is part of our commitment to playing a major role in providing solutions to help customers bridge the physical and digital world through IoT,” said Michael Murray, General Manager of Industrial Sensing Products at Analog Devices. “We want to reduce complexity, democratize IoT standards and provide trusted data for customers, and we look forward to working with the EdgeX community to achieve those goals.”

Canonical
“At Canonical, we have been pushing the need for standardization and commonality in the industry for a long time; the introduction of snaps being one example. We are therefore pleased to see a continuation of this with the launch of the EdgeX Foundry and proud to be one of the founding members” comments Mike Bell, Executive Vice President, IoT at Canonical. “We are obviously advocates of the open-source nature of the project and believe this will further enhance all players in the ecosystem to align to drive business growth and further innovation.”

Dell
“We think EdgeX Foundry is the key to accelerating the fragmented IoT market and are proud to have been a part of the effort from the beginning,” said Jason Shepherd, IoT Strategy and Partnerships, Dell. “We’re big believers in openness and choice, and this modular architecture is designed to help anyone easily build edge computing solutions with preferred hardware, software, standards and services while minimizing reinvention. EdgeX Foundry is not a new standard, but a way to unify standards and edge applications.”

Neustar
“As a leading provider of Identity solutions we are excited to be a founding member of The Linux Foundation’s EdgeX Foundry project. We are firmly committed to open and common frameworks for developers, and we are particularly excited to provide a highly secure trusted device identity solution for this ecosystem” said Hank Skorny, SVP of IoT at Neustar. “EdgeX combined with Neustar’s Trusted Device Identity platform will provide developers with a next generation IoT solution to help secure their IoT systems from the escalating attacks on unsecured devices.”

Collaborating with other IoT Efforts
EdgeX Foundry is collaborating with relevant open source projects, standards groups, and industry alliances to ensure consistency and interoperability across the IoT.

Cloud Foundry Foundation
“The goals and principles of EdgeX Foundry and Cloud Foundry naturally complement each other,” said Abby Kearns, Executive Director of Cloud Foundry Foundation. “We look forward to working with EdgeX Foundry to enable companies to deploy IoT strategies and applications that accelerate business growth and drive innovation.”

EnOcean Alliance
“The growing market for intelligent building control is dependent on interoperability to ensure that devices can communicate and perform as needed,” said Graham Martin, Chairman & CEO of EnOcean Alliance, Inc. “We look forward to working with EdgeX Foundry to help unify the IoT community around a platform that can deliver automation and enable companies to easily develop IoT solutions that will enable more efficient operations.”

Linaro
“The creation of a standard, secure, open, and architecture- and vendor-neutral gateway framework is a critical component of IoT based solutions. Hosted by The Linux Foundation, EdgeX Foundry’s impressive industry support and open governance model allows open collaboration on a common gateway architecture by industry leaders,” said Matt Locke, Director of the Linaro IoT and Embedded (LITE) Group. “This much needed unifying project will allow vendors to define and build a common gateway platform; a platform upon which they can build unique and compelling solutions across a wide range of market segments. We look forward to welcoming new members into LITE to work closely on the engineering needed to accelerate adoption of EdgeX Foundry. Supporting this new project complements and builds on LITE’s engineering and technical support of The Linux Foundation’s Zephyr project, which is aimed at enabling embedded and IoT devices.”

Object Management Group
“Interoperability is paramount for integrating secure and scalable IoT solutions,” said Richard Soley, CEO of the Object Management Group (OMG). “EdgeX Foundry will unify a wide array of standards and commercial offerings at the IoT edge, enabling faster ROI for industrial organizations. EdgeX is architected to enable tiered data ingestion and processing, aligning well with the various open standards for distributed computing driven by the OMG.”

ULE Alliance
“The IoT faces a major challenge with a myriad of devices that address a vast number of diversified use cases. The success of IoT highly depends on seamless interoperability of devices built on different technologies by different vendors, each using the best suited technology for the specific use case,” said Avi Barel, Business Development Director at the ULE Alliance. “EdgeX Foundry is a major step toward addressing this great challenge, and ULE, as the highly secure and reliable radio technology, fully supports this initiative.”

For more information on EdgeX Foundry including how to participate, please visit www.edgexfoundry.org.

About EdgeX Foundry

EdgeX Foundry is an open source project hosted by The Linux Foundation building a common open framework for IoT edge computing and an ecosystem of interoperable components that unifies the marketplace and accelerates the deployment of IoT solutions. Designed to run on any hardware or operating system and with any combination of application environments, EdgeX enables developers to quickly create flexible IoT edge solutions that can easily adapt to changing business needs. To learn more, visit: www.edgexfoundry.org.

About The Linux Foundation

The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and commercial adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage.
Linux is a registered trademark of Linus Torvalds.

# # #
Media Inquiries:
Emily Olin
Senior PR Manager, EdgeX Foundry
eolin@linuxfoundation.org