Blog

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 Roman Arutyunov, Co-Founder and VP of Products for Xage Security, Inc. to discuss Industry 4.0, challenges for edge computing, security and digital twins for machines.

What does your company do?

Xage is the first and only blockchain-protected security platform for industrial IoT, creating a tamper-proof “fabric” for communication, authentication, and trust that assures security at scale. Our platform supports any-to-any communication, secures user-based and machine-to-machine access to existing industrial systems, works at the edge even with irregular connectivity, and gets stronger and stronger with every device added to the network. Customers include leaders in the largest industries, spanning energy, utilities, transportation and manufacturing.

Why is your company investing in the IoT ecosystem?

Industry 4.0 promises to bring the next big wave of economic growth, optimizing production and customer experience. As a team of security, industrial digitization, and software experts, we knew security would be foundational to such an autonomous, any-to-any, edge-heavy ecosystem. The current centralized security systems simply aren’t designed to handle the scope, nature or complexity of Industry 4.0. We saw the opportunity to build a security fabric that is distributed, redundant, flexible, and adaptive enough to provide the necessary trust and integrity for secure Industry 4.0 interactions at scale.

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

Our goal is to become the foundational and enabling security layer for IoT security across the major, evolving industries that need it––like manufacturing, transportation, utilities, and energy, among others. IoT has already had a large impact on industrial verticals ranging from robotics in manufacturing, connected cars in transportation, and integration of renewable energy sources like solar and wind in utilities. Data-driven autonomous operation with distributed intelligence is a common theme across multiple industrial verticals and has the promise of enabling significant improvement in service reliability, efficiency, and sustainability affecting our everyday lives.

Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions. What are some of the business or technical challenges you have faced when adopting edge computing technologies?

When developing edge computing solutions businesses typically face the challenge of having to deal with multiple data and control protocols, building adapters for each, and creating a data store on top of which analytics solutions can be run. Additionally, as data is exchanged and accessed by multiple applications there is a need for effective access control. The Xage Security Fabric addresses the security concerns for data storage and access across multiple distributed systems and applications at the edge.

Why did your company join EdgeX Foundry?

EdgeX Foundry and Xage are aligned in our objectives to build a converged and secure solution, spanning multiple vendors, devices, and applications for industrial IoT at the edge. There’s massive potential to transform the way industrial organizations operate, and joining the EdgeX Foundry brings us one step closer to the reality of Industry 4.0, operating efficiently and securely at the edge.

How are you going to use the framework?

Xage has created a decentralized framework for securing IoT devices, applications, and and enabling any-to-any information exchange. The Xage Security Suite enables access control at the edge enabling zero-touch device enrollment, one-click user access control, and peer-to-peer application data exchange. Even before we became a member of EdgeX Foundry – we had been working with the framework. We plan to make our Security Suite accessible through EdgeX.

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

Two decades is a very long time in technology’s terms – just think about what your cell phone looked like 20 years ago. Actually, most people used pagers back then! In 20 years, IoT will move well beyond connectivity and data, and will be a well-integrated part of our lives. Through the spread of artificial intelligence and virtual reality, we will invent “digital twins” for machines that currently power our industries, and learn to interact with them for joint machine and human decision making.

What is your favorite connected device?

I love cars, connected cars and autonomous cars. It has a been a passion of mine for some time now. One of the first connected and autonomous cars has been implemented in open-pit mining. Think large Caterpillar trucks the size of a 2-story house driving themselves.

Guest blog post by Rodney Hess, Principal Member Technical Staff at Beechwoods Software

If you missed the Open Source IoT Meetup last month, here’s a recap of the interactive meeting and where you can find details for upcoming meetups.

The Open Source IoT Meetup in Boston took place at WeWork’s North Station on February 15.  (A shout out to Wework!  Their location in the historic Bulfinch Triangle of Boston is quite cool.)  The panel included myself—I work on the northbound and southbound interfaces of the EdgeX stack—and:

• Brad Kemp (moderator), CEO of Beechwoods Software and a member of the EdgeX Foundry Governing Board
• Tony Espy, Technical Architect at Canonical and EdgeX Foundry Technical Steering Committee (TSC) member and chair of the EdgeX Foundry Devices Working Group
• Riaz Zolfonoon, an RSA Distinguished Engineer who collaborates with members of the EdgeX Foundry Security Working Group.

Our panel (L-R): Tony Espy, Riaz Zolfonoon, Rodney Hess, and Brad Kemp, our moderator and co-host.

Suffice to say, it was an excellent panel of which to ask questions.

This was our second Meetup for EdgeX, the first one was October 2017.  EdgeX Foundry had just wrapped up the Barcelona release and was in the process of defining the California release.  Since then, there’s been a lot of community feedback and discussions—we even had a TSC Face-to-Face meeting in Orlando—and finalized more details for the California release and preview.  It was time to bring our Meetup members up to speed.

Our moderator and co-host Brad Kemp introducing the group to EdgeX.

Around 25-30 participants, which is the largest audience we have had, attended the meetup and asked a lot of questions.  They were quite engaged.  They wanted to understand EdgeX and what you could do with it.  How did the microservices work together?  We delved into how the data flowed from sensors residing off of the Southbound interface to the clouds floating above the Northbound interface.

A question was raised as to whether EdgeX could handle video streams, for example video feeds from security cameras, with a follow up question as to whether one could set triggers based on values within the data stream.  The panel explained that EdgeX has been built for discrete, event based data collected from sensors and devices.  In a building automation use case, examples of discrete data include current temperature and humidity, target temperature, whether the heating system was on or off, and the like.   When a camera or audio sensor generate a discrete data point, for example, a count of people in a room, then EdgeX can work with that data.  EdgeX today does not handle raw video or audio streams.  The discussion then moved on to how the Rules Engine microservice along with the Alerts and Notification microservice can be configured to trigger actions and notifications based on data arriving from the sensors.

Rodney Hess (yours truly) providing an overview of the EdgeX architecture.

When asked about implementing support for multiple cloud services, the panel discussed the modular nature of the Export Distribution microservice; that some services were already implemented, including Azure IoT Hub and Google IoT Core, but that work supporting other cloud platforms remains.  Do they need to be clouds?  No, the Export-Distro can export data to any application or enterprise HTTP/S or MQTT/S endpoints—cloud or otherwise—that is external to the EdgeX framework with support for additional endpoint types already in the EdgeX roadmap.

When asked, how does the security framework protect sensors, especially those legacy networks that have no inherent security, the panel talked about the security initiatives the EdgeX Foundry Security Working Group is undertaking, including a reverse-proxy that all external applications must go through to access sensors off of the EdgeX southbound interface.

Riaz Zolfonoon speaking to a point on security within EdgeX.

The panel spoke to the larger IoT landscape and how EdgeX fits in and brings unique value, what the TSC has accomplished and what work lies ahead.

We are working on an agenda for the next Meetup.  Suggestions for topics or speakers are always welcome.  Find out more here and join our group:  https://www.meetup.com/Open-source-IoT/.

If you have questions or suggestions, please reach out to Brad or Geof Cohler, our Open-Source IoT Meetup hosts.  We meet every six weeks to hear from engaging industry experts, to network with other talented locals with diverse backgrounds, and to share our passions for all things IoT.

For more technical details, visit the EdgeX Foundry wiki page.

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

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

Last week, several members of the EdgeX Foundry community were at the OpenIoT Summit in Portland, OR, which was co-located with the Embedded Linux Conference.  According to Linux Foundation representatives, the attendance of the conference was around 730, which is an increase from last year.

I was impressed by the level of content and quality in the presentations as well as the participant level and engagement at this conference.  The booth displays were low-key (not a lot of big equipment demos or flashy give-aways) yet the engagement level between participants and the booth representatives was very high.  During non-session periods, the showroom floor was packed with a constant stream of participants stopping by each booth to get background and details about the products and services shown (versus just trying to get the free t-shirt as you might see at other conferences).

From top: Janko Isidorovic and Drasko Draskovic (Mainflux), Jim White (dell) and Trevor Conn (Dell)

Several members of the EdgeX community presented talks and provided information about their work in the community.  Notably, Janko Isidorovic and Drasko Draskovic (from Mainflux) as well as Trevor Conn and I (from Dell Technologies) gave session talks (links below).

• https://elciotna18.sched.com/event/DYM7/hyperscalable-unified-iot-platform-drasko-draskovic-janko-isidorovic-mainflux
• https://elciotna18.sched.com/event/DYMD/building-open-source-iot-ecosystems-jim-white-trevor-conn-dell
• https://elciotna18.sched.com/event/DYMC/using-microservices-to-create-a-flexible-iot-software-platform-jim-white-dell

Jim White (Dell) and Tony Espy (Canonical)

Tony Espy (Canonical) and I also presented two beginner’s training labs on EdgeX.  The link to the lab session is below, and you might find the training materials (located at the bottom of the session notes) helpful in your own spin-up on EdgeX. In total, almost 100 participants attended these sessions and was introduced to or engaged with EdgeX Foundry in one way or another.

https://elciotna18.sched.com/event/DYf2/getting-started-with-edgex-foundry-a-hands-on-lab-jim-white-dell-tony-espy-canonical-ltd

Additionally, Dell Technologies’ own Patricia Flores made a good plug for EdgeX and put on a great show during her talk in one of the morning keynote sessions entitled “Federated Analytics at Scale.”

Patricia Flores (Dell) giving a keynote speech

In discussing EdgeX with the attendees, I believe EdgeX’s open, interoperable, microservice architecture is still drawing a lot of attention and consideration from companies exploring IoT solutions.  It was also clear that the current EdgeX developer focus and emphasis on targeting smaller footprint devices (with Go) was significant and left a resounding positive impression on the global IoT community.  EdgeX will also need to deliver – in measured steps starting with the California release – security and system management capabilities.

Next year’s OpenIoT Summit is in Monterey California.  Hope to see your there!

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 Jimmy Garcia-Meza, Co-Founder and CEO of CloudPlugs, to discuss architecture, the ecosystem and Industrial IoT.

What does your company do? 

CloudPlugs enables energy, utility and manufacturing companies, service providers, building managers and municipalities to i) digitize and securely connect their legacy and new device infrastructure; ii) to manage end-to-end the lifecycle of their devices, applications and data; iii) to add intelligence to the edge to gain better insights and automate actions, and to easily integrate operations technology with IT systems and 3^rd party applications and cloud services.

CloudPlugs offers a secure, fully integrated edge to cloud stack using state-of-the-art container technology in the cloud and in the edge.  Our suite of integrated tools for connectivity, fast service development and deployment enable companies to implement and deploy their digital transformation projects in record time. For example, a large electrical utility developed a smart micro-grid service and deployed it within 35 days making it an internal example of how technology should be implemented.

Why is your company investing in the IoT ecosystem?

The IIoT space is so large and complex that it is impossible for a single company to address the needs of the market.  For our customer projects to be successful, we need close relationships with the sensor, PLC, gateway and other edge device manufacturers, and upstream with the companies that provide data lakes, advanced analytics, machine learning tools and operations and business support systems.  A real, field deployable solution must provide integration on the edge side and integration on the cloud or data center side.  Only this way can companies truly integrate and digitize their vertical and horizontal value chains.

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

IoT is what we do from inception, so we live and breathe the opportunities and challenges that surround this new world.  Industrial customers tend to have 6-9-month evaluation cycles since the decisions will impact their operations and digital service and business model creation. However, what we have learned is that when they experience success, they will invest more.  Some of the benefits we saw in adding Edge One™ to Thermal and Power plants to ingest and process legacy data that is pushed to a data lake, are that the customer is now able to use data scientists to create predictive models to further optimize operations.  The confidence they gained help them venture into incorporating LoRa and sensors to transport data inside the plants and they now have an advanced material tracking system.  Other customers are building their new connected systems to change their business model from selling expensive machines to selling outcomes.  The impact of IoT and IIoT is just beginning to be felt and it will drive the Industry 4.0 initiatives in the years to come. 

Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions. What are some of the business or technical challenges you have faced when adopting edge computing technologies? How have you overcome them?

We have believed in edge computing since day one. Since then, we have built Edge One™ on top of the SmartPlug™ to deliver a container based, high performance, extensible platform for edge connectivity and computing.  Coming up with an architecture that delivers flexibility, performance, scalability and extensibility has not been easy and it requires deep understanding of 1) the problem you want to solve, and 2) the technologies available and that need to be created to create a solution that can solve most of the challenges.  Extensibility is key, and we are building an ecosystem of partners who can build and sell their own container applications and services on Edge One™ to complement the modules available from CloudPlugs.

Why did your company join EdgeX Foundry?

In many ways, EdgeX Foundry mimics what we do on the edge, but we expect to contribute to the technology and use cases and to make our Edge One™ platform compatible with EdgeX products and services.

How are you going to use the framework?

We are going to add to our products the pieces that allow interoperability with other edge devices that are EdgeX enabled.

Where do you see industrial IoT in 20 years?

I hope that in 20 years we’ll be talking about something else and that most of the industrial sector will have had great experiences in deploying their Industry 4.0 initiatives.  One of the core elements of Industry 4.0 is the implementation of cyber-physical systems with the ability to learn and make autonomous decisions.  Currently, companies are overwhelmed with the tasks of connecting everything and trying to gain better insights from the data.  In a few years, as technology evolves and more, easy to integrate and use solutions become available, the number of companies using AI as part of their daily operations will grow. I expect that this will enable new battlegrounds for increased operational efficiency and new, innovative digital service and business models will emerge.

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

In a post I made to this blog back in October, I reported that the EdgeX community was committed to reducing the original footprint, startup times and overall performance by making a move from Java to Go.  The community has been hard at work, and I am happy to report on the initial success of that effort.

California Preview

Today, we announced the availability of what we have deemed the “California Preview” that is available for exploration from the EdgeX sites.

The California Preview is a sample of what we hope to bring you in full this spring.  In the California Preview, the community has built several Go Lang micro services that are drop in replacements for the Java versions.  Specifically, the core services (Core Data, Metadata, and Command) have been re-created in Go Lang.  Additionally, a portion of the export services functionality found in the original Java Export Client and Export Distribution micro services have also been re-created in Go Lang.  Finally, the Core Config Seed, which is the initialization service that sets up the configuration/registry service, is now done in Go Lang.  Consul is our configuration/registry service and that has always been written in Go.

Team Effort

This has been a community effort with the Dell team providing the core Go services, Cavium and Mainflux teams providing the export services, and Samsung producing the new config seed.  The Linux Foundation led DevOps team is busy working a continuous integration process for our new Go micro services –even cross compiling for Intel and Arm platforms.  Last but not least, the blackbox testing provided by the IOTech team is making sure the replacement services are REST API compatible with the Java services and therefore are drop-in ready.  This is how open source gets done today – many companies and teams working together towards one dream.  Group hug.

Go Lang Results

Now, back to the results and benefits of all this hard work.  Because Go is compiled into an executable, the size of the application is much smaller than it’s Java counterpart – even before considering the JVM required for Java applications.  Here’s a look at the raw Java JAR versus Go executable size for the EdgeX core micro services.  The size of these same services in a Docker container is also indicated on the right side of the chart.  The Java container image size does includes the Java JVM – thus the even larger footprint when looking at Java versus Go containers.

All well and good, you might say, but what about the micro services’ use of critical resources such as memory or CPU?  Go Lang micro services used an astounding 97% less memory and generally 5 to 40 times less CPU!

Lastly, the startup time for the Go services nears 100% improvement.  We typically had to measure our Java micro service start times in seconds.  We measure our Go Lang micro services starts in milliseconds.

I have been doing Java most of my programming career.  Love Java, but in order to get EdgeX to the real edge of IoT environments, we have to put our micro services on a diet – make them small and fast.  Go Lang is helping us get EdgeX svelte.

Still Hurdles to Clear

Go is still a young programming language relative to Java.  Version 1.0 of Go was released by Google in 2012 whereas Java has been around for more than 20 years now.  The libraries, tools, frameworks, and idioms are still emerging in Go while Java has a plethora of these.  Our developer community, in some cases, is also learning that the Java-way is not necessarily the Go-way, and therefore is having to adapt to a new programming paradigm.  For example, the multiple repo approach for the Java micro services and associated share libraries doesn’t work so well in a Go Lang development environment where a single “mono” repo is preferred.  Some of our Go code will likely have to go through a refactoring exercise as lessons are learned.  That’s to be expected as even the Java micro services were refactored once or twice since being created.

The Go work is progressing but we are not done.  We need to make similar reductions to the rest of our micro service collection.  Not all the work will be done in Go Lang.  For example, we are hopeful to have a C/C++ Device Service SDK (along with a Go Lang Device Service SDK) this spring which will allow for small C/C++ micro services for some protocols/platforms at the EdgeX southern layer.  In some cases, especially for the some of the services that are more application focused and could live in bigger environments when EdgeX is distributed, Java micro services may still flourish.

However, if we are able to make similar reductions to all of our EdgeX micro services (whether using Go, C/C++, or other language), the forecast for EdgeX size and performance is quite good.  Early forecast calculations put the total memory usage (database and other infrastructure inclusive) at less than 200MB.  That compares to a 2.5GB of memory needed today.  The total containerized footprint would be around 600MB (compared to more than 1.8GB today).  And EdgeX would start up in about 5 seconds (compared to around 5 minutes today).  The concentric circle relative size diagrams for some of these metrics provide a visually compelling story that should help you soak in the differences.

Help Needed

Come help us complete this work.  Help us make EdgeX go (pun intended) smaller and faster!  In addition to the work to complete the EdgeX micro service reductions, there $is crucial work in security and system management that is to be completed for the California release.  As I already indicated, we need help completing SDKs in various programming environments.  More north and south bound connections, more testing, and more deployment / orchestration work needs to happen.  We welcome companies and individuals looking to make a contribution in the IoT landscape.

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

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 Rocket.Chat and share your thoughts in the #community channel.

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 William Diotte, President and CEO of Mocana, to discuss embedded security software, military applications and IoT analytics.

Tell me a little bit about your company.

Mocana provides mission-critical IoT security solutions for embedded systems, industrial controls and the internet of things. Today, Mocana protects more than 100 million embedded devices within military aircraft, manufacturing automation equipment, electric utility grid control systems, medical equipment and IoT devices. Our IoT security platform goes beyond traditional security approaches by making IoT and ICS devices trustworthy and enabling secure device-to-cloud communications.

Why is your company investing in the IoT ecosystem?

To deliver IoT- and connected-device-based services, it requires an entire ecosystem of connected, interoperable systems and services — from the chips to the sensors to the gateways, and up into the cloud or core systems and services tp provide “networks of systems.” Securing this “network of systems” requires a holistic approach and Mocana has developed relationships with a broad ecosystem of vendors in the IoT marketspace to develop pre-integrated solutions to ensure end customers receive robust, consistent protection when launching IoT services, while spending much less time architecting, developing and then supporting their new offerings.

How has IoT impacted your company? 

Mocana was founded in 2002 to provide security software for embedded systems in military aircraft and devices. We then extended our solution to address the needs of the industrial automation and controls market. With Mocana solutions protecting more than 100 million devices today, we are in a great position to help the IoT industry protect the billions of connected devices to ensure their security and safety.

Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions. What are some of the business or technical challenges you have faced when adopting edge computing technologies? How have you overcome them?

Computing at the edge involves placing more intelligence in devices rather than handling all of the analytics and decision-making at the core, in a remote data center. For example, today’s modern industrial-grade surveillance cameras handle much of the video analytics at the edge. This allows a remote camera on a street corner to analyze surveillance video footage locally within the camera, rather than having to backhaul all of the data back to the cloud to analyze it. There is great advantage to doing this to speed analysis and reduce the time it takes to identify characteristics, such as color, object type and direction, in real time. The challenge of embedding more intelligence into edge devices is that they are sometimes resource constrained, meaning they have limited processing power and memory relative to a full-blown computer or data center server. Mocana addresses this by working closely with silicon vendors and real-time operating system software providers to optimize the performance of our security software on minimal systems so that edge computing applications can run securely.

Why did your company join EdgeX?

Mocana joined EdgeX as a founding member in order to deepen partnerships and relationships with Dell, VMware, Ubuntu, ADI and other major organizations within the growing IoT gateway ecosystem collaborating in the EdgeX community. The membership extends Mocana’s mission as an IoT security provider for devices that are delivering high-value connected services on edge computing systems. Mocana’s interoperability with the EdgeX ecosystem is essential to ensuring end customers have access to a robust, reliable, commercially tested and supported security solution that secures their high-value services running at the edge, as well as their device-to-gateway-to-cloud network of systems. The company is focused on improving interoperability, securing gateways, and providing a chain of trust for both northbound and southbound communication and analytics.

How are you going to use the framework?

Mocana will deliver an easy-to-use plug-in to quickly migrate from the base EdgeX open-source security framework and tools to Mocana’s comprehensive, reliable, commercially tested and supported security solution that secures their high-value services running at the edge, as well as their device-to-gateway-to-cloud network of systems.

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

It’s hard to predict where the industry will be in 50 years; however, there no question that the internet of things  will transform the way we live, work and interact with our physical world. Sensors will be ubiquitous in everything, from our basic needs of what we eat and drink to what we use to do our jobs and experience the world. For example, today, sensors — tiny microcontrollers that are as small as grain of sand — are used in agricultural applications to measure temperature, moisture and pH of the soil. These sensors will decrease in size so that they can be ingested and measure various aspects of your health. In factories or even hospitals, human workers will work alongside robots that can use artificial intelligence and enhanced physical strength to improve the productivity as well as the safety of workers. In smart cities, the street lights will become beacons of information filled with sensors for weather, light, traffic, sound, proximity and surveillance. These will provide a great deal of information to make our cities safer and more efficient. As part of the Industry 4.0 revolution, industrial manufacturers are already incorporating sensors into factory equipment to measure performance and improve uptime and productivity. In the transportation sector, we will certainly see connected vehicles and autonomous driving cars. Fast progress is being made in this area. In 50 years, I could see flying personal vehicles and certainly a proliferation of drones.

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.

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 Rocket.Chat and share your thoughts in the #community channel.

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 4^th 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 3^rd 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 31^st. 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.

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 Larry Andriunas, President of Kodaro, to discuss analytics, the EdgeX ecosystem and the role software plays in the Internet of Things. 

What does your company do and what is your your role?

Kodaro is a building software company primarily aimed at helping contractors and controls companies find value in building data from the edge to the cloud. We’re a company of engineers and computer programmers who believe building analytics should empower people to solve problems and make facilities more efficient. In addition to Analytics as a Service, analytics rules packages, and cloud hosting services, we make a variety of products to integrate and expand the capabilities of the Dell Edge Gateways for building systems. I’m the Founding President of Kodaro, overseeing the team as we unpack building data and turn it into actionable information for building controls managers.

Why is your company investing in the IoT ecosystem?

In a very short time the IoT has gone from something people whisper about to a keyword at the heart of countless analyst reports from here to Dubai. This has been driven by consumer-facing sectors like smart home devices and wearable technologies and we in the buildings industry are realizing it’s only a matter of time before all those people and all those devices impact the way we operate buildings. We’re investing in the IoT ecosystem because we believe that buildings of the future are connected and full of data that adds value, through energy savings, increased occupant comfort, equipment longevity and better connections.

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

The IoT essentially is our company. Without a network of connected devices transmitting data within and between each other, we couldn’t do what we do. Some of our software facilitates the data transfer, others translate and analyze the data once it gets to where it needs to go. As building controls and integrators advance into this open and connected world we as a software company will be able to find, understand and act on more information about what’s happening in buildings than ever before.

Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions. What are some of the business or technical challenges you have faced when adopting edge computing technologies? How have you overcome them?

As a software company in building automation, we’re often working between hardware and third-party applications. Each piece operates at opposite edges, and in many cases they use different languages or frameworks to conduct similar operations. So, much of our time and energy is spent bridging those gaps with software. One exciting example is our machine learning algorithms that automatically tag data so that it can be integrated into the building automation system more quickly and cost effectively.

Why did your company join EdgeX?

By creating an open source community, we believe EdgeX will attract the best minds to solve the most complex problems of the IoT. As a software company for the IoT, it was important that we part of the team that’s stitching it all together.

EdgeX Foundry Ecosystem

How are you going to use the framework?

We plan to deploy the EdgeX Framework from edge to cloud to create easier, faster connectivity so that we can better run data analytics in building systems.

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

IoT is now compartmentalized into homes, buildings, industrials. In 20 years, I see seamless integration across verticals. Our lives will be integrated into buildings, buildings will be integrated into cities and so on. As the IoT advances, it will change how our lives are connected.

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.

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 Noah Harlan, EdgeX Foundry Board Member and Founder of Two Bulls, to discuss the IoT market, connected devices and security.  

When we talk about IoT we mostly think of consumer IoT, but there is also managed consumer IoT (like security devices offered by ADT/Comcast/Verizon) and Industrial IoT. Can you talk a bit about the IoT market in general?

IoT is a marketing term for connected devices. Any edge device that connects to either a central system or makes itself available via the internet can plausibly be viewed as IoT.

Practically speaking I would bucket IoT into consumer and industrial but the edges quickly become fuzzy. A single apartment with a connected thermostat is clearly consumer IoT but if that apartment’s connected thermostat is part of a building-wide HVAC system is that now Industrial? To the company that installed the building-wide system, probably since they’re B2B2C, while the building management is in the middle (B2C), but to the apartment resident it’s a consumer product. Furthermore, when you expand outward and look at areas like smart cities which may involve a mixture of stakeholders it’s hard to differentiate. TL;DR: perspective matters. So given that, if you view it all as connected devices, then the underlying technologies need to address connectivity and devices, not an “Internet of Things.”

Can you tell us about your own solutions for the IoT world?

Two Bulls is a digital and connected product consultancy that works with some of the world’s biggest brands and most innovative startups to bring great products to market. We provide strategic, design, and development services and handle everything from embedded systems, to cloud infrastructure, to user interfaces and everything in between. We currently are working on products in the consumer IoT, smart cities, and industrial IoT spaces and our client list includes Verizon, Vodafone, Qualcomm, LIFX, and many others. 

IoT devices have earned the reputation of Insecure Internet of Things. Why do we keep hearing so many attacks and vulnerabilities in IoT device? 

Poor planning and poor design has led to some very significant security breaches or lapses, whether that was in the form of hacks like the Mirai botnet or overaggressive data gathering (always-on listening TVs and toys). While guaranteeing perfect security is extremely hard, putting in place a set of basic best practices mitigates the risks. When devices are deployed which are connected but can’t be updated or rely on hard-to-update common default security credentials, you are asking for a problem.

Furthermore, when a large company is hacked, it may include your credit card information but the breach is still relatively abstract to you as an individual whereas when you find out that a security camera in your house was breached you feel it very acutely and as more and more devices gain connectivity, the possibility of nefarious actors doing bad things grows. Hacking your email account is bad. Hacking the lock on your front door is potentially catastrophic.

There are two components of IoT devices – the Edge device and the backend server. Where do you see is the problem when it comes to security?

If you don’t worry about end to end, then you’re not thinking about security seriously. That said, we have good protocols for encryption of the upstream communications and we have a lot of experience with protecting backends. Where we have a harder problem is the device-to-device communication at the edge, particularly when there are multiple protocols involved. The protocol translation issue is a very hard security problem. If I am a router and I have a device on one side that speaks Protocol A and a device on the other that speaks Protocol B and I want to translate, I can’t generally rely on end-to-end encryption. I have to decrypt the messages from A, translate them, and then encrypt them when I send them off to B. The challenge becomes how do you determine trust for the translator so that all parties feel comfortable with a “man in the middle” being able to view everything and that the translator is both legitimate and uncompromised.

In most cases we have seen that IoT devices don’t get software updates and patches. Should IoT devices adopt an OS similar to Container OS where the systems are automatically updated? 

Any good edge operating system should have inbuilt systems for easy remote updating or they will eventually be subject to a security risk. Period. 

How much is standardized when it comes to IoT platform (the OS level) and applications?

Currently, nothing is “standardized” and thus a platform like EdgeX Foundry that can acknowledge that the proliferation of protocols and transports likely won’t consolidate for a range of reasons. It provides a system for translation, processing, and gateway security that  are essential and valuable going forward.

Do you think government and regulations can play some role in forcing IoT vendors to take security seriously?
I have worked with members of Congress on their first steps looking at IoT, in particular Cory Booker who is co-sponsoring the DIGIT Act which is making its way through Congress now. My best advice to them was to work to avoid a patchwork of security rules (one set for health, another for automotive, another for consumer, etc…) as that would lead to conflicting rules and stifle innovation. Instead, I encouraged them to establish a privacy and security spectrum which defines the requirements of each place on the spectrum (eg: at one end devices with very little security or privacy and at the other devices with very high security or privacy) and to encourage or require IoT vendors to declare their device’s “tier” in the Security & Privacy Spectrum (eg: a connected speaker with no microphone might be a level 3 device while a connected blood pressure monitor is a level 7 device while a pacemaker is a level 10 device because if it get hacked someone could die). This would mean that regulators would stay out of the minutia of defining *how* to comply and simply state what compliance means. This frees the industry to innovate and gives them a bar to measure against.

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:

• Core-data — https://github.com/edgexfoundry/core-data
• Core-metadata — https://github.com/edgexfoundry/core-metadata
• Device-virtual — https://github.com/edgexfoundry/device-virtual

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.

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.

Keith Steele, IOTech CEO, EdgeX Foundry Board member and Technical Steering Committee (TSC) Chair gives his views on why the EdgeX Foundry project has generated so much momentum in just six months and spotlighting the importance of credible commercialization partners.

Since the April launch, the EdgeX project has evolved into a growing and vibrant ecosystem of more than 60 companies contributing to the emergence of an open, secure platform to facilitate interoperability at the IoT edge.

The project dropped its first community release, dubbed ‘Barcelona’ in October, as part of a bi-annual release roadmap established by the project TSC and recently announced an alliance with the Industrial Internet Consortium (IIC) to collaborate on best practices and test beds.

The next release called ‘California’ will focus on security and manageability features as well as very significant performance and footprint improvements driven by the availability of new Golang based microservices.  There will be a California preview release in January with a full ‘California’ release in June 2018.

Many large technology providers are spinning up plans to adopt and end users are starting to incorporate EdgeX into their deployment roadmaps. Many POCs are also in progress.

EdgeX Momentum

What’s driving momentum?

First and foremost, there’s a market need. The Industrial Internet of Things (IIoT) market is projected to grow to $195B in the next few years (source Markets and Markets) , with at least 40% IoT data stored, processed, analyzed at or near the edge (source IDC).

Secondly, there’s a technology gap as identified by the IIC’s Edge Computing Task Group, the Open Fog Consortium and many other industry-leading companies. Peter Levine from Andreessen-Horowitz has provocatively suggested that the age of edge compute is taking over the cloud.

“The current model of cloud computing is too slow. A small difference in the time it takes to refresh a machine learning model for a drone or car could be the difference between life and death. Computation will move to the edge. The same drones, cars, and IoT devices that need their models updated quickly will form a peer-to-peer network with which to distribute time-sensitive tasks…cloud servers will still be around…responsible for doing offline computation across large data sets.”

The emergence of software platforms is recognized as vital to support this new paradigm at the Edge, having a pivotal strategic role to lowering barriers to IoT adoption to the larger market prize.  This means that EdgeX has hit the market at the right time to meet the growing needs for distributed computing to support the sheer scale of devices coming on steam and advanced analytics to produce business value.

The other big attraction is that it is truly open and vendor-neutral. The platform has been carefully architected to enable significant value-add around a lowest-common denominator interoperability framework, enabling companies of all sizes to innovate rather than reinvent.

EdgeX is a loosely-coupled, polyglot architecture, agnostic to silicon and operating system, the enabling microservices can be written in any programming language to run on any hardware; this level of flexibility is very important given the heterogeneous nature of IoT.

Openness is a critical success factor for scale by enabling an ecosystem of plug-and-play components that work together compared to proprietary platforms that further fragment the landscape

The EdgeX partner ecosystem is also a key factor in EdgeX momentum; the community has driven through open collaboration a well-defined roadmap, helping deliver well thought-out and relevant solutions for foundational functionality; the security working group is a notable example of this, with at least ten of the top IoT security companies on the planet working together to define EdgeX platform API requirements.

Vertical Solutions based on EdgeX are also starting to gain traction indeed Samsung is chairing a new Vertical Solutions Working Group in which end users will sponsor industry and use-case focused projects to define requirements for the core EdgeX platform and develop and deploy test beds in their respective industries.

As part of this initiative Samsung is spinning up a project for smart factories and National Oilwell Varco recently proposed one for Oil and Gas. We will see additional projects for use cases spanning Smart Cities to Buildings to Farms to make sure the foundational platform meets the needs of a wide variety of applications.

EdgeX Commercialization

There’s also another important player in the open source ecosystem: The commercialization partner.

EdgeX is targeted at the industrial segment of the Internet of Things, many applications here are business critical requiring long lifespan, therefore a key consideration organizations face is how to leverage Open Source in a sustainable and risk-free way.

Some companies will choose to take a cut of the open source code and maybe support themselves, but many companies simply want to exploit their value-added applications and leverage EdgeX to sell infrastructure or monetize services around IIoT deployment rather than focus on supporting the foundational code base.

For this reason, many companies are prepared to pay for professional highly proactive long-term support, guaranteed roadmap evolution, influence, and specialized services on top of the open source core.

As a founding member of the EdgeX project, IOTech realized this at an early stage of project development and strived to be the key commercialization partner, helping companies to enjoy the benefits and flexibility of open source, while mitigating the risks of its use.

In addition to taking a proactive role supporting the evolution of the EdgeX open source code, IOTech is creating professionally packaged, commercially supported versions of the core EdgeX software called Edge Xpert and developing complementary licensed IP which will offer through the partner ecosystem.

In summary, the EdgeX ecosystem is growing fast and there’s clear momentum for global adoption. I don’t think that’s an accident. EdgeX has all the attributes: it’s vendor-neutral open source, it meets a real market need, and it has a modern polyglot microservices architecture. At the same time, it is backed by some of the largest IoT players and vendors in the global IoT market.  Meanwhile, it has vendors like IOTech that can take the risk out of commercial adoption.

For a more information on IOTech’s EdgeX-related product and service offerings visit www.iotechsys.com or contact Keith at info@iotechsys.com.

Written by Gorka Garcia and Federico Claramonte from Cavium 

Cavium, a provider of highly integrated semiconductor processors that enable intelligent networking, communications, storage, video and security applications, recently joined EdgeX Foundry and is already an active contributor.

We are using our OCTEON TX family of Multi-Core 64-bit ARM Embedded Processors to target the intelligent IoT Edge Gateway market.  We believe in open source technologies for this market and value EdgeX Foundry for its scalability and flexibility.

Over the past few months, Cavium has helped create a strong ARM64-based version of the EdgeX platform that is on par with the versions for other CPU platforms.  Our particular focus was on ensuring efficient execution of the platform on OCTEON TX processors using a intelligent edge gateway reference design.

As we started the port, the first issue we met was the lack of ARM64 support in EdgeX docker containers. As a first pass, we ran EdgeX without using containers and just calling the micro-services directly. This worked at first try, as the EdgeX software is written in java and it did not use any native libraries. Then, we created a new set of ARM64 containers that can be deployed to ARM64 in the same way as x86. While doing this, we simplified the docker container process creation by implementing some scripts that will handle that task. When running all the containers in our lower memory ARM64 boards, we noticed a peak of memory usage at startup. After some investigation, we managed to reduce these memory peaks by simplifying the startup process, managing to also improve the startup time of EdgeX. These are changes that benefit all supported platforms, not just ARM64. Right now we are involved in the porting of some micro-services from java to Go Lang, which will help reduce memory footprint even further as well as improve the overall performance.

All our work has been contributed to the EdgeX Foundry community as we believe interoperability is key for IoT solutions success and are committed to help grow the EdgeX ecosystem. Throughout this whole process, we had support from the EdgeX community, answering our questions and giving feedback on our work. Cavium will continue supporting the EdgeX Foundry project to make sure it runs well in our ARM64 processors as well as doing generic optimizations of the services that could benefit the whole community.

For more developer resources, please visit the EdgeX Foundry wiki page.

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

To begin this post, I need to give you a little history.  When my team and I started on Project Fuse (which became EdgeX Foundry) at Dell some two years ago, we knew the micro service architecture was going to be the mechanism to deliver the edge/IoT platform to satisfy our ideal platform.  What we weren’t sure about was the programming language to use to get started in writing our microservices.  As we looked around at options we knew we needed a very powerful and flexible programming platform that would provide all sorts of tools and connectors to the various protocols of the IoT world.  Many of the newly emerging languages, like Go Lang, just didn’t ring the bell on the availability of tools and connectors at the time.  So, we went with Java as our primarily programming language as it was well known to us, provided all the libraries and connectors we could want, and it seemed to be in line with the other products we wanted to integrate with at the time.  We also knew that the microservice architecture would allow us to add or replace a microservice in the future using a different language if we needed.  To be honest, our project was a proof of concept system so the choice in language was less relevant then than today.

As we fast forward to EdgeX’s introduction this spring, it was clear from the community that while the concept architecture we built with Fuse was on the mark, we needed to eventually improve EdgeX’s performance, footprint, and scalability – especially to meet the mission critical edge use cases we would encounter.  Languages like Go Lang have come a long way, and many of our community members were already seeing incredible improvements using Go Lang in their IoT solutions.  Indeed, even at Dell, as we were getting ready to introduce EdgeX into the open source community, we had started to experiment with Go Lang (and other languages) and had even developed some replacement micro services to demonstrate the potential performance/footprint improvements while also trying to understand the challenges.

Today, I am pleased to announce that the EdgeX community has formalized plans to develop preview EdgeX microservices in Go Lang and make them available by Jan 31, 2018.  This will be a preview of the California release of EdgeX scheduled for the spring of 2018.  We will release these Go Lang services but will not be making any other changes to the system’s functionality or API set – in other words, these Go-based microservices should be drop in replacements to their Java counterparts.  And for the foreseeable future, we plan to support both the Java and Go Lang versions as we know the Java and Go Lang communities are vibrant and may want/need these alternatives in their particular IoT solutions.

Specifically, we plan on releasing the following microservices in early 2018 as part of this preview release:

• Core Data, Core Metadata, Core Command microservices
• Export Client microservice
• Initial elements/libraries to a Go Lang Device Service SDK

Additional microservices and facilities may be added to this list depending on work accomplished between now and then.  Much of this work is actually already underway – in parallel to our efforts as a community to get the Barcelona release out this fall.  We hope to have some preliminary performance and footprint numbers (in comparison to the existing Java microservices) so people will have an understanding of the impact of this work by the time we showcase the Barcelona release in the fall.

We are hopeful this work will also help demonstrate the community’s commitment to drive down the size and speed of EdgeX to meet today’s edge platforms.  Much work remains, but this will help provide proof positive that the platform is heading in the right direction and will help galvanize the community around our desire to solve real world IoT/edge use cases.

By the way, don’t let this work suggest that EdgeX is going to use Go as the only development language going forward.  One of the core tenets of EdgeX is to be polyglot and use the tools of choice for each microservice to best meet the use case need.  As an example, others in our community are already on record (IoTech, Inc. for example) in their desire and focus to eventually develop a C based device service and device service SDK.  C/C++ will probably make a lot of sense when trying to operate a device service on very constrained device hardware and offers extreme performance improvements.  Go simply offers a popular alternative to Java that is seeing wide use in the IoT community and helps us get the collective footprint and performance of EdgeX down fairly quickly.

So, do you like to work in Go?  Lend us a hand!  Come join us in the EdgeX community as we try to build the best open source IoT/edge platform on the planet!

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

The EdgeX Foundry community continues to grow as does the EdgeX functionality thanks to contributions from around the world.  In this post, I’d like to highlight an exciting addition to the EdgeX “northbound” interface.  That is, a new capability built into the EdgeX export services that allows EdgeX data to be sent to Google Cloud IoT Core.

What is Google IoT Core?  It’s a Google public beta cloud service (what Google calls a fully managed service) that allows you to easily and securely connect, manage, and ingest data from millions of globally dispersed devices.  See https://cloud.google.com/iot-core/ for more details.

For those unfamiliar with the EdgeX architecture, the services responsible for organizing, formatting, transforming, etc. the sensor data collected by EdgeX and sending it to enterprise or cloud based systems are the export services.  In the EdgeX and IoT communities, we often call theses the “northbound” services or interfaces as they are typically depicted on the top end of any diagram that depicts an edge platform.  “Southside” services or interfaces are those that communicate with sensors, devices or other systems even closer to the “things” edge and are usually depicted at the bottom of any diagram.

Bernard Van Haecke from Schlumberger, Menlo Park, CA office dug into EdgeX when it was released and recently had his connector contribution approved and posted as part of the Export services.  What his addition does is allow the export services to pipe data to Google IoT Core.

EdgeX export services already allowed for sending data to any MQTT topic or HTTP REST endpoint generically and to Azure IoT Hub specifically.  We believe going forward, there will be lots of these connectors – some public and some private (perhaps you will need one to your own closed enterprise system).  But Bernard will always have the distinction of being our first new connector on the northside.  Thanks Bernard!

You can learn more about the Google IoT Core export on the EdgeX Wiki here: https://wiki.edgexfoundry.org/display/FA/Export+Services+-+Google+IoT+Core

This week, EdgeX Foundry will be on display at IoT Solutions World Congress taking place in Barcelona, Spain, from Oct. 3-5, 2017.

The EdgeX Foundry booth (Booth E541) will be filled with innovative member solutions from Canonical, CloudPlugs, Cumulocity, Dell/RSA, ForgeRock, IOTech, Linaro, NetFoundry, Neustar, RFMicron, Vantiq and VMware. Other EdgeX Foundry members will also have EdgeX on display in their own booths, including Analog Devices, Bayshore Networks, Device Authority, EnOcean Alliance, FogHorn and Opto 22.

If you’re in Barcelona, stop by Booth E541 to see the live demonstrations, chat with members and learn more about the EdgeX ecosystem. There will also be a happy hour from 3-5 p.m. on Tuesday, Wednesday and Thursday, so stop by for drinks and light snacks!

Demos in the EdgeX Foundry Booth (Booth E541):

Canonical: Canonical will show how Ubuntu and Ubuntu Core, the Operating System of Choice for smart IoT, can be used as the IoT gateway Operating System to run EdgeX on.

CloudPlugs: CloudPlugs will be displaying the Edge One™ IIoT Gateway on Dell Edge Gateway 3000 controlling Modbus devices and integrated with EdgeX. CloudPlugs is an advanced IIoT platform that uses fog computing to easily develop, deploy and manage industrial devices and applications.

Cumulocity: Cumulocity IoT scales up to geo-distributed multi-tiered cloud and on-premises high availability hybrids and down to a single node fully featured Edge platform – all with the same secure carrier grade software architecture. Cumulocity will be showcasing the Edge platform and a range of connected devices for consumer, industrial and environmental use cases. Cumulocity IoT rapidly accelerates IoT adoption.

Dell: The Dell demo will use the EdgeX platform to manage 3 devices – a people counting camera, thermostat with heat/cool fans, and Patlite signal tower running on a Dell Edge Gateway 5000 and 3000. Through EdgeX, the people counter will actuate (through EdgeX rules engine) the thermostat and fans based on the number of people it detects.

RSA: Highlighting monitoring and threat intelligence for the edge (i.e. the gateway and attached devices), this demo consists of an RSA agent that runs on gateway and monitors, collects, and sends information to hosted cloud service for security evaluation/action. Dell Technologies offers the industry’s broadest IoT infrastructure portfolio including Dell gateways and RSA security, enhanced by curated partnerships and the EdgeX Foundry ecosystem.

ForgeRock: ForgeRock will be using EdgeX and the Identity Edge Controller (IEC) to demonstrate the integration on a Dell Gateway 5000. The IEC demo will deliver the following inbound services – attestation, auto onboarding at boot, authorization and token validation. ForgeRock® Edge Security offers complete end-to-end security for IoT deployments. It ensures the integrity of IoT devices and their communication using secure, standards-based tokens instead of insecure hard coded usernames and passwords, or managing thousands of individual PKI certificates. It adds a rock-solid security layer to IoT hardware used at the edge, including leveraging highly secure on-chip Trusted Execution Environments (TEE) if available, and comprehensive, policy based controls for publishing and subscribing to data streams from edge devices, making it as easy to protect data coming from IoT devices as it is to protect a web page.

IOTech: IOTech will be showcasing the new GUI they have developed to support EdgeX.  The demo will showcase how the GUI can be used to browse device and device service related information, as well as being able to visualize device generated data. IOTech is a vendor neutral middleware specialist aiming to be at the heart of the edge infrastructure opportunity by leveraging EdgeX technology to accelerate solution time-to-market and leveraging the partner ecosystem of key IoT players to facilitate a global market opportunity for the company.

Linaro: The demo will feature sensor data communication from the Zephyr microPlatform into an Edge X gateway. It also demonstrates a newly available feature in the Zephyr microPlatform, LWM2M. The Zephyr microPlatform is a minimal, secure, and OTA-enabled platform for product development that is continuously updated for the life of the product by Open Source Foundries.

NetFoundry: NetFoundry will be showing two demos. Demo 1 uses the NetFoundry we console to spin up a network to show superior application performance and security across any network, including the public internet. Demo 2 highlights NetFoundry enforcing the Neustar Trusted Device Identity (TDI) security and performance requirements from edge-to-cloud. NetFoundry enables customers to quickly and easily spin up highly-secure, performant app-specific networks at scale.

Neustar: Neustar will be showcasing two use cases of Trusted Device Identity. The first use will be demonstrating a secure firmware update to an endpoint using an edge gateway to validate payload and confirm source. The second demo will be demonstrating secure end point to app path protection over a core network and terminating in two end points (an app and a sensor). This use case will a show immediate revocation and resilience to man in the middle attacks. IoT solutions need to scale securely beyond the traditional PKI implementations. Neustar is launching Trusted Device Identity (TDI), a unique, scalable, and real-time approach, providing the means to securely communicate to and from end points with immediate revocation capability.

RFMicron: RFMicron is helping to extend EdgeX into the realm of real-world data with Smart Passive Sensing™ devices. These battery-free and maintenance-free wireless sensors can be applied in a wide variety of industrial, automotive and medical applications. The demo showcases the RfmApi software that employs edge processing to convert raw sensor data into trusted information. RFMicron helps protect people and equipment in real-time with new industrial IoT software connecting smart passive sensors into the powerful EdgeX backbone. The latest RFMicron sensors support full AES-128 encryption for secure commands and data transfers in wireless mode for blockchain applications. RFMicron helps protect people and equipment with new industrial IoT software connecting smart passive sensors into the powerful EdgeX backbone.

VANTIQ: VANTIQ’s open platform integrates with a wide range of systems and we are excited about furthering our association and integration with the EdgeX Foundry community. VANTIQ provides the only application platform-as-a-service that enables the rapid development of real-time, event-driven applications.

VMware: In partnership with SAP, VMware will be demoing the Smart Popcorn Machine which pops popcorn and monitors the temperature, pressure, etc. of the machine. The data is pushed up to the SAP Cloud and to VMware’s new IoT Pulse Center which manages, monitors, secures, and onboards the sensors within the Popcorn Machine. The demo does not currently integrate with EdgeX live but will be in the future and the value proposition will be talked about. VMware Pulse IoT Center is a secure, enterprise grade, end to end IoT infrastructure management solution that allows IT and OT to have complete control of their IoT use case, from the edge to the cloud by helping them manage broader, operate smarter, innovate faster and protect better.

If you want to see more EdgeX Foundry in action, you can visit other member booths including:

Analog Devices: Booth D485

Bayshore Networks: Booth B211

Device Authority (Booth B240): Device Authority is the leading provider of IoT IAM. Our KeyScaler™ platform provides trust for IoT devices and the IoT ecosystem, to address the challenges of securing the Internet of Things.

EnOcean Alliance (Booth B254): EdgeX is a crucial part for EnOcean based gateways which bring sensor data, provided by self-powered and wireless sensor solutions, to the cloud and thus enabling cognitive buildings. At the stand, we will demonstrate EnOcean based self-powered wireless solutions, enabling highly flexible, maintenance-free applications for the Internet of Things and supporting the transition from intelligent to cognitive buildings.

FogHorn: Booth E571/B211

Opto 22 (Booth B286): Dell Edge Gateway 5000 with EdgeX collecting and controlling operational data on a working model wind turbine. Real-time data can be accessed through EdgeX Console at public URL http://optoturbine.groov.com:4000 admin/123. Opto 22 manufacturers industrial controllers, I/O, and edge computing devices bridging the physical and digital worlds for IIoT.

Striim (Booth B221): The demo is real time predictive maintenance and predictive quality for manufacturing.

In the Industrial Internet Consortium booth (Booth E571), you can also catch Sensify Security’s demo that showcases completing porting their blockchain-based IAM system to the EdgeX platform.

If you’re not in Barcelona, stay tuned on @EdgeXFoundry for pictures and the new EdgeX Foundry Youtube channel for videos!

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 chatted with Deb Noller, CEO and co-founder of Switch Automation.

What does your company do and what is your role? I’m the CEO and co-founder of Switch Automation. Switch is committed to creating a more sustainable world, one broken building at a time. We recognize that buildings contribute 39% to CO emissions in the U.S. alone and have a massive impact on everything from climate change to employee health and productivity. Our end-to-end solution helps enterprises uncover hidden inefficiencies in their real estate portfolios and provides real-time insight to optimize building performance.

How would you describe your company in three sentences?  Switch Automation is a smart building platform that collects disjointed building data, aggregates it in a cloud-based global framework and synthesizes the data into actionable insights. From on-site IoT monitoring devices to energy metering and sub-systems, our configurable dashboards provide a single interface where a range of facilities management professionals can understand building performance, employ fault detection and diagnostics, and execute real-time control and command. The Switch Engineering Services team, in-house data scientists and integration experts work closely with customers to ensure smooth implementation and a best-in-class user experience.

Why is your company investing in the IoT ecosystem? When Apple introduced the iPhone, they didn’t set out to build every single app. The IoT industry is enormous and there is plenty of room for many companies to be successful. However, it’s a complex space and can be difficult to build an end-to-end, quick to deploy solution. My belief is that best in-class solution providers will partner together to solve this problem and deliver more flexible, scalable options for customers.

How has IoT impacted your company? What benefits have you seen or what do you expect to achieve? IoT is our business. In the last 5 years, we’ve implemented the Switch Platform in more than 70 million sf of real estate and helped a wide range of customers realize hundreds of thousands in operational and energy savings.

Given the forecast for 70 billion connected devices by 2025 and the building-related IoT market growth to $76 billion in 2020, we will continue updating the Platform to accommodate innovative technologies, artificial intelligence and machine learning as they become operational mainstays.

Businesses currently have to invest a lot of time and energy into developing their own edge computing solutions. What are some of the business or technical challenges you have faced when adopting edge computing technologies? How have you overcome them? We had to build our own gateways and software stack to provide the interoperability, security and connectivity between systems and devices that our customers expect. Security can present a big challenge, but fortunately we’ve partnered with Dell for our hardware solution, the Switch Gateway. The Gateway utilizes TPM, Secure Boot, and Trusted App to help tamper-proof the Switch Platform. We then built a state of the art software solution on top of the Switch Gateway to reinforce protection from external threats.

Why did your company join EdgeX? For the last five years we’ve seen what a truly cohesive IoT ecosystem can do to foster connectivity, sustainability, scalability and generate huge savings for our customers.

One of our clients, a leading financial institution with 7,000+ branches, uses the Switch Platform to monitor signage, lighting, space temperatures, occupancy, energy usage and more. Prior to implementing the Platform, their operations team endured the tedious and time-consuming practice of gathering vast amounts of data from multiple disparate sources then wrestling it into actionable insights. Each branch was an isolated silo of information and by the time the information was filtered down to meaningful findings, the window for significant savings had closed.

By leveraging the Switch Platform to connect vital systems, our customer now spots problems in real time and engages the appropriate resources to repair it before incurring costly operational and capital expenses.

We want to help more businesses achieve these kinds of results and believe that supporting collaborative industry endeavors like EdgeX is a great step.

How are you going to use the framework? We already use the framework and recommend it to our customers as the best way forward for their business.

Where do you see enterprise and industrial IoT in 20 years? In 20 years, enterprise and industrial IoT will be the norm. Cars in the 1950s didn’t have electric locks–now they do. People will have devices all over their buildings and the data will be freely shared across the organization. Automated analytics, machine learning and AI will all have a seat at the table and align with evolving customer needs.

In the IoT age, what shouldn’t be connected and why? Just because you can connect to a plethora of widgets, doesn’t mean you should. I like to ask, “Does connecting to this device deliver a worthwhile and tangible benefit to the end user?”

Today, EdgeX Foundry announced Samsung Electronics has joined as a Platinum member to help accelerate open source development of their industrial IoT edge platform. You can view the complete news release here.

We had the chance to sit down with Kyeongwoon Lee, Senior Vice President for Samsung Electronics, to discuss why they joined the EdgeX community and how they will be using the framework.

What is your your role within Samsung?

I am one of the core contributors and enablers for Samsung’s IoT business in terms of connectivity with our variety of products. By working with the IoT ecosystem, I am very active in the open source community and leverage different standards such as Open Connectivity Foundation (OCF) and IoTivity.

What is Samsung’s vision for Industrial IoT? 

Our traditional portfolio includes Consumer Electronics (CE), Information technology & Mobile Communications (IM) and Device Solutions (DS). But there is a lot of potential in Industrial IoT (IIoT), such as Smart Manufacturing, Smart Building and Smart Lighting and Smart Energy Management, and we believe we need to build a synergy and true seamless interoperable IoT services across the business domains. As one of the biggest manufacturing companies around the world, we have many infrastructures and a lot of experiences but, if we collaborate with EdgeX Foundry, we believe that our IIoT efforts will be much more clear and stronger. We will be able to continue building and growing an IIoT business.

What are some of the business or technical challenges you have faced when developing IoT edge solutions? How have you overcome them?

The biggest technical challenge is interoperability. There are a variety of devices in factories that are part of proprietary solutions and aren’t talking to each other.  Even in global standardization, there are still Brownfield areas that are used by proprietary solutions which makes interoperability a challenge. The other challenges are scalability and flexibility. For example, real-time operations is very important and in order to meet performance criteria, we need scalability.

We’ve overcome some of these challenges by working with open source such as IoTivity, and leveraging some of the IoT standards like OCF. In addition to this, when it comes to the IIoT ecosystem, we need more flexibility per vertical specific use case, so that we could expect the faster and more optimized deployment. We believe that the best answer is to collaborate on a pure open source platform that is vendor neutral and can work with existing technologies and services. This will help us deploy the very best to the industry and developers. 

Why is Samsung joining EdgeX Foundry?

We are attracted to EdgeX Foundry’s value proposition and recognize that it is the best solution for several of our challenges – interoperability, scalability, flexibility and transparency to existing cloud services. EdgeX Foundry will help us create lightweight edge solutions with the support a growing community with Industrial IoT edge platform expertise.

How are you planning to use the EdgeX framework? How do you think it will help you achieve your business goals?

EdgeX Foundry will help Samsung create interoperable and lightweight edge solutions that will help us grow and strengthen our presence in Industrial IoT.

Written by Jim White, TSC Member and  Chair of Core Services Working Group

When we first introduced EdgeX to the LF community back in the spring of this year, Dell contributed more than a dozen micro services, a lot of documentation, and the start of a build process.

Since, the community has grown considerably (now more than 60 companies have signed on), we have held our first community technical meetings to set the roadmap for the first community release and direction for releases to come over the next 12-18 months.  We also have community members already contributing to the project or working on the upcoming release.

At Dell, we are still very much a part of this effort, and today I’d like to announce the contribution of six more example device microservices (we call them device services) to the open source EdgeX platform.  These are microservices we built from the device service SDK as examples of how to connect to actual devices like those using Modbus, BACnet, BLE, SNMP, and MQTT protocols.  So they serve multiple purposes in the community:

• Demonstrate more south side connectivity
• Demonstrate other implementations of the device service via the SDK
• Demonstrate connectivity to EdgeX via specific industrial Iot protocols
• Allow more real world devices to be connected to EdgeX today!

Modbus is a serial communications protocol that has been in existence since 1979 (truly brownfield!) and is used primarily in programmable logic controllers (PLC) and electronic devices.

BACnet is used in building automation and control networks that typically manage heating, ventilation and AC systems.

SNMP is an internet standard protocol that was created for collecting and organizing information about systems / devices on an IP network – most notably like modems, switches, severs, printers, etc.

If you own a smartphone or have a home smart device, you are probably already familiar with the Bluetooth Low Energy protocol which is used typically in wireless personal area networks.

And MQTT is a pub-sub messaging protocol used on top of TCP/IP in combination with a message broker that has been used in a variety of use cases and systems for a few decades.

When we first released EdgeX, we provided the device service SDK and a single device service, which was the virtual device service.  The virtual device service allowed for the simulation of any device /sensor connectivity into EdgeX through software, but did not facilitate actual devices.  With the collection of device services that Dell is contributing today, EdgeX now has open source community code to connect to real devices.

At Dell, we continue our commitment to this project and plan to contribute more of the code we created as part of our original Fuse Project.  We also join with the community to make additional contributions and commitments jointly.  Come join in the effort and help us, the entire EdgeX Foundry community, make the best open source IoT platform on the planet.

During our last F2F meeting, we had the opportunity to sit down with Brad Kemp, the President and Founder of Beechwoods Software and an EdgeX Foundry Board Member. Known as a technical “rainmaker” in the startup community, Brad believes that IoT should be a seamless experience that “just works,” which is why Beechwoods was one of the initial members of EdgeX Foundry when it launched in April. Check out the video of our chat below to learn more about common challenges his customers face and how he believes EdgeX Foundry will help solve those issues.