Blog

Welcome California!

Written by Jim White, Vice Chair of the Technical Steering Committee and Distinguished Engineer and Project Lead of the IoT Platform Development Team within Dell Technologies IoT Solutions Division

The second major release of EdgeX Foundry is now available!

While EdgeX is only a year old, our community is demonstrating its staying power with the second major release in its first year.  The California release, which follows Barcelona, shows the commitment and dedication of many who see the importance and potential of developing a flexible, open source, IoT software platform for the edge that provides connectivity and interoperability while still allowing value add.

So, what is new with the California release?  A lot! But before we get into the details, I want to highlight that the biggest focus of this release was to introduce a few key security capabilities and to make EdgeX smaller and faster.

Security

EdgeX began its existence without security and organizations wanting to leverage the platform had to add their own security capability. Today, EdgeX incorporates some of the first security elements.  These initial elements, while useful on their own, are essential building blocks to additional security features in the future.

The first security elements include a reverse proxy that helps protect the REST API communications and a secrets store.  With the EdgeX reverse proxy in place – as provided by incorporating an open source product called Kong – any external client of an EdgeX micro service must first authenticate themselves before successfully calling on an EdgeX API.

The secure storage facility was provided by incorporating the open source Vault (Hashicorp) product, and it allows items such as username/password credentials, certificates, secure tokens, etc. to be persisted and protected within EdgeX.  These types of “secrets” will allow EdgeX to, for example, encrypt data, make HTTPS calls to the enterprise, or connect EdgeX to a cloud provider in a secure manner.

Performance and Scalability

The EdgeX Foundry Technical Steering Committee decided early last year in the project’s formation that we would release twice a year – once in April and once in October.  You probably noticed that it’s not April.

Last year, we decided that EdgeX needed to be smaller and faster to better function effectively at “the edge”, which the largely-Java code from the seed donation was going to make difficult. To do this, we needed to rebuild the EdgeX microservices in Go Lang – and do so by our spring 2018 release.  This was not a small endeavor and it was made at a time when the EdgeX Foundry developer community was just coming on board.  We knew it would take a bit more time, but we were committed to this, and added two more months to this release cycle.

The extra time was well worth it!  With the California release, we’ve dramatically lowered the footprint, startup time, memory and CPU usage. Take a look at the statistics below, which compares services from our first community release last October (Barcelona) to our current release (California).

We still have work to do, but it’s now possible to run all of EdgeX on something like a Raspberry Pi 3.

Additional Features

In addition to the initial security capabilities and reducing the size and latency of the platform, this release includes other work – some visible to the user while some features are more hidden but improve the overall quality of EdgeX.

  • Several additions were made to the export services to provide additional “northbound” connectivity, to include connectors for XMPP, ThingsBoard IoT, and Brightics IoT
  • We improved the documentation and now have documentation stored with the code in Github – allowing it to be maintained and updated more like code by the community
  • Arm 64 is now fully supported.  In fact we worked with the Linux Foundation to add external environments and tools to create native Arm 64 artifacts.
  • We added blackbox tests for all the micro services.  These are now kicked off as part of our build and continuous integration processes.
  • Other improvements were made to our continuous integration – to help streamline developer contributions

We invite you to try out the California release today (Docker Compose file here)!  

On to Delhi

Our next release, named Delhi, will come out in October 2018.  Due to the extended release cycle for California, the Delhi release cycle is going to be short. The significant features planned for Delhi include:

  • Initial manageability services and capability
  • Device Service SDKs (Go/C) and at least one example device service
  • The next wave of security features to include access control lists to grant access to appropriate services and improved security service bootstrapping
  • Better/more unit testing and added performance testing
  • Adding the last of the refactored and improved Go Lang microservices
  • Outlining options and a potential implementation plan for alternate or additional database support
  • An EdgeX UI suitable for demos and smaller installations

Come join us!

We would like to thank the talented men and women who are working very hard to turn the vision announced when the EdgeX project launched in April 2017 into the product we see emerge and improve with each release.  In the past six months, we have seen the number of unique authors contributing to the project code base double to more than 50. We hope you’ll consider joining our growing development community to build on this momentum by contributing to the Delhi release as well as using EdgeX in your edge/IoT solutions!

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

Spreading EdgeX Foundry News in Asia

Written by Jim White, Vice Chair of the Technical Steering Committee and Distinguished Engineer and Project Lead of the IoT Platform Development Team within Dell Technologies IoT Solutions Division

Over the past couple of weeks, I have been traveling to China and Japan to attend the LinuxCon/Container Con/CloudOpen (LC3) conference in China as well as IoT meetups for EdgeX Foundry in Beijing and Tokyo.

As the name of the LC3 implies, it was actually 3 conferences in one and thus a full venue of keynotes, sessions and events spread over 3 days.  I was impressed by the overall scope and attendance of the conference. While there was a predominance of Chinese companies and speakers as one would expect, this was a global event with attendees and speakers flying into Beijing from all over the world.

Speaking at the LC3 show were the likes of Linus Torvalds, Chris Aniszczyk (Cloud Native Computing Foundation – CNCF COO), Abby Kearns (Cloud Foundry Foundation Executive Director), Dan Kohn (CNCF Executive Director), and Alan Clark (director for openMainframe and member of the CTO office at SUSE).  I presented a talk to around 50 attendees about using a microservice architecture to address the needs of edge computing – using EdgeX Foundry as an example. You can view the presentation here.

In addition to my talk on microservices and EdgeX, there were 11 talks over the three days in the IoT & M2M track.  A few of the ones I found interesting were:

Tiejun and his team are doing great work on all sorts of IoT-related matters.  I had a chance to visit with them at the VMware Beijing office and got to see one of his experimental robots using EdgeX!

Tiejun also played an integral role in orchestrating an EdgeX Foundry Meetup to occur simultaneously with LC3 – giving even more awareness to EdgeX in China.  Around 40-45 people showed up at the Meetup to hear a great roster of speakers share their experiences with our open source project and EdgeX Foundry member The Zephyr Project. In fact, Professor Yonghua Li from Beijing University of Posts and Telecommunications (BUPT), which is a member of both EdgeX and Zephyr, brought a few of his students along so they could discuss how they are using the EdgeX framework and the Zephyr RTOS in their IoT solutions. You can read more about their work in this blog post.

Another one of the speakers was Huaqiao Zhang from VMware (pictured below) speaking about the EdgeX UI he recently contributed to the project. This will be released with the Delhi release in October. Check out the roadmap.

For those not keeping up on all the EdgeX Foundry news, the Industrial Internet Consortium, (IIC) recently announced the formation of the first Optimizing Manufacturing Processes by AI (OMPAI) testbed and it will be led by Wanxiang Group out of China. Read the blog post here.

China is a global leader in machine-to-machine (M2M) technology, which allows devices to wirelessly exchange information and execute tasks. M2M connections can communicate in various ways, including Wi-Fi, Bluetooth, and cellular. Interoperability is an important piece to this puzzle and I think that’s why there was so much interest in EdgeX Foundry in China. We hope to continue working with our members in China like VMware and the Wanxiang Group to coordinate more meetups and continue spreading awareness for EdgeX Foundry through WeChat. If you would like to be added to the EdgeX Foundry WeChat group, please email info@edgexfoundry.org with your WeChat ID.

Next on the Agenda: Tokyo

While in Japan visiting with a number of Dell Technologies customers, I had the pleasure of presenting at a Tokyo EdgeX Foundry Meetup.  Around 50 people were at this event – making it the most well attended EdgeX Meetup at which I have had the pleasure to present. Even more impressive was the fact that more than half my audience had been up since 3 am that morning to watch the Japanese national team in elimination round of the 2018 World Cup!  Interest in IoT is palatable in Japan – especially for use in the manufacturing sector.

 

The desire to learn more about edge computing and EdgeX Foundry was considerable from the Tokyo IoT crowd with the Q&A portion of my talk lasting almost as long as the talk itself.  The Q&A discussion even spilled over into a great drink/appetizer social afterwards. It was truly an engaging group and a fun afternoon.

Questions from this community included:

-Why did EdgeX chose Go? Because of its multi-platform support, ability to compile to a native executable and run small/fast and its concurrency model among other reasons

– Is EdgeX Foundry involved in standards work? EdgeX Foundry community members are actively involved with Industrial Internet Consortium (IIC), OpenFog Consortium, IEEE and many other industry and consortia groups and will work to be an implementation of edge standards we think are beneficial to the space, but we are not trying to get EdgeX to be a standard.

– Are EdgeX and Edgecross related projects? The Edgecross Consortium is a Japanese-based organization that is currently working on a Windows-based edge platform that members of our community continue to have discussions with, but there is no relation between the two projects today.

Next year, The Linux Foundation announced LC3 will simply be called Open Source Summit China, which will be held in Shanghai. If you’re interested in IoT, open source and more, put the Open Source Summit China or Open Source Summit Japan on your conference list.  I don’t think you’ll be disappointed in what you’ll see and learn there.

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

Michael Hall Joins EdgeX Foundry

Written by Michael Hall, Project Evangelist and Developer Advocate for EdgeX Foundry

This week, I began a new chapter in my career by joining The Linux Foundation as a developer advocate and community manager for the EdgeX Foundry, an open platform for IoT edge computing.

I started using open source before I even knew what it was. Perl was my first programming language, and so installing libraries from CPAN became a routine task (as well as a routine challenge on SunOS). I posted my first open source code on SourceForge soon after, still thinking of it as a way for hobbyists to share their hobby, but not as something serious developers or companies would do. I still remember the feeling I had when Netscape announced that the next version of their browser, Netscape Navigator 5, would be released as open source. As a web developer in the late 90’s, Netscape was the killer app, the king of the hill, the virtual monopoly that was leaps and bounds ahead of IE4. For them to release their source code in a way that let other people see it, copy it, even improve on it, was revolutionary. And it changed forever the way I thought about open source.

Of course, anyone who lived through those turbulent times knows how that Netscape 5 story actually turned out, not because it was open source but because of business decisions and buyouts (thanks AOL!) that kept pulling the development one way and then the other. But my own journey into open source was much more straight forward. I dove in completely, releasing everything I could under an open license, using as much openly licensed software as possible. I bought (yes bought) my first copy of Linux from Best Buy in 1999, and switched my desktop permanently in 2006 when Canonical mailed me a free CD of Dapper Drake. Five years later I would join Canonical myself, and eventually land on the Community Team where I was building new communities and growing existing ones around Ubuntu and all its upstreams and downstreams. Last year, I was doing the same at Endless Computers, bringing the benefits of open technology to users in some of the most remote and disconnected parts of the world.

So, having the opportunity to join the Linux Foundation is a dream come true for me. I’ve seen first-hand how collaboration on common technology leads to more and better innovation across the board, and that is the core idea behind the Linux Foundation.

I’m excited to be joining EdgeX Foundry, which will play a crucial role in developing the way the rapidly expanding number of IoT devices are going to connect and communicate with the already massive cloud ecosystem. I will be working to improve the way new developers get started using and contributing to EdgeX Foundry, as well as teaching new organizations about the benefits of working together to solve this difficult but shared problem. I look forward to bringing my past experiences in desktop, mobile and cloud developer communities into the IoT space, and working with developers across the world to build a vibrant and welcoming community at the network edge.

Follow me at @mhall119  and stayed tuned at @EdgeXFoundry for more. Or, if you have questions or comments, visit the EdgeX Rocket.Chat and share your thoughts in the #community channel.

University Students Leverage EdgeX Foundry and Zephyr OS in New Projects

Written by Professor Yonghua Li with Beijing University of Posts and Telecommunications (BUPT) and active EdgeX Foundry and Zephyr Project member

The Beijing University of Posts and Telecommunications (BUPT) recently became new members of EdgeX Foundry and the Zephyr Project but students studied both projects long before then. In fact, students are currently working on IoT projects that are based on these open source technologies.

The first project uses the EdgeX platform (using the Java micro services) running on a Raspberry Pi. EdgeX Foundry core, supporting and export micro service artifacts were created in Eclipse using Java Maven.  Docker containers were created around the micro service artifacts and deployed to the Pi running Ubuntu 16.04 Linux using Docker Compose. In addition to the EdgeX export, core, and supporting micro services, the students choose to build and deploy an MQTT based device service to ingest sensor data into EdgeX which utilized CloudMQTT as the underlying broker.

For this project, the students used a random number generator to simulate sensor data on the Pi.  The simulated sensor data was passed in with an MQTT messages through the device service (again utilizing CloudMQTT) while receipt messages were sent back out from the device service through another MQTT pipe.  Because of CloudMQTT’s WebSocket user interface, students could easily view the JSON-wrapped random number data enter EdgeX as well as be acknowledged by EdgeX – demonstrating the successful establishment of an IoT edge platform.

EdgeX Foundry uses the random number as messages through the MQTT Microservice, passes it to CloudMQTT, and receives the response again through the MQTT Microservice. CloudMQTT’s WebSocket UI allows you to view JSON random number data and send data to EdgeX, demonstrating the successful establishment of it.

The other project aims to develop a Bluetooth-enabled heart rate monitor based on Zephyr OS, which is ideal for resource-constrained systems and small IoT devices. The system implements heart rate measurement for users and transmits the user’s heart rate data to user’s mobile phone via Bluetooth, so that users can monitor his or her heart rate in real-time.

The system is mainly divided into two parts: hardware and software. The main functions of the hardware is data collection, data transmission and data display. The hardware is designed and implemented centered on the Arduino101 development board. On the other hand, the software is mainly used for data conversion and analysis. The development and implementation of software are performed under Zephyr OS.

If you’d like to learn more about the BUPT student projects, we invite you to join the IoT Meetup on Tuesday, June 26 from 6-9 pm at VMware’s office in China. There is no cost for this event but space is limited, so RSVP is required. Register now https://www.bagevent.com/event/1491965   

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

IIC announces 1st OMPAI testbed based on EdgeX Foundry

Written by Jijun Ma, Member of the EdgeX Foundry Governing Board and Industrial Internet Director at Wanxiang Group

The Industrial Internet Consortium® (IIC) announced the Optimizing Manufacturing Processes by Artificial Intelligence (OMPAI) testbed yesterday. The OMPAI testbed is led by IIC members Wanxiang Group (also a member of EdgeX Foundry) and Thingswise and supported by Dell EMC (a founding member of EdgeX Foundry), Xilinx, China Unicom, and China Academy of Information and Communication Technology (CAICT).

The OMPAI testbed, which is the first testbed based on EdgeX edge computing platform, explores the application of artificial intelligence (AI) and industrial internet technologies, deployed from the edge to the cloud, to optimize automotive manufacturing processes. It also seeks to create an ecosystem that will foster the exchange of IT/AI/OT domain knowledge and the co-development of smart manufacturing applications. For example, deep learning may be able to improve quality assurance of an automobile part to substantially increase the detection of defects and reduce the need for manual inspection.

Vincent Wang, Chief Innovation Officer of Wanxiang Holdings, said, “As a leading multinational corporation in automotive and renewable energy, with factories in Europe, North America and Asia, we believe that an industrial IoT platform will be a key enabler for our digital transformation and global synergy. We are glad to work with technology leaders to validate AI, edge-cloud collaborative computers, and high-speed cellular networks to optimize manufacturing productivity and quality. This is the first step toward an open, inclusive IIoT platform on which we will continue with further testbeds, incorporating new ideas, new data usage models and creating greater value add. We invite worldwide enterprises, innovators and entrepreneurs to enrich the ecosystem together.”

In the edge platform, AI models and edge applications are run for the local optimization of manufacturing processes. In the cloud platform, they are run to enable global and long-term optimization, e.g. across production lines and plants. The edge platform also supports connectivity to and data collection from the equipment while the cloud enables historical data accumulation and storage and supports AI model building.

The cloud computing platform also provides the capability for enabling industrial app DevOps processes supporting collaboration between AI/IT developers and plant engineers in creating, testing and running data/AI model-driven industrial applications. The following image shows the solution overview of this testbed.

Blow are the usage scenarios in our testbed.

Machine vision on-line quality assurance

The main theme of this scenario is to exploit the capability of deep learning in image pattern recognition to improve quality assurance effectiveness and efficiency by increasing defect detection accuracy, reducing dependence on manual inspection and at the end providing online feedback to the production process to reduce defect rate.

Battery Cell Welding Quality Control

In this scenario, it is going to use historical data to analyze the relationship between the welding process and environmental parameters and the product quality and use that to predict in real time quality product and provide recommendation for optimization.

Wheel Bearing Production Line Balance & Optimization

A high throughput discrete manufacturing line usually consists of many workstations involving with various equipment and processes. These workstations may have different production throughput that vary depending on their process parameters. Mismatched throughput between the workstations would impede the overall production line throughput, reducing overall equipment utilization and production capacity.

Big data analytics on data collected from the workstation equipment can be used to monitor production pace of each of the workstations and overall throughput, and to identify bottlenecks and recommend optimization solutions.

Predictive Maintenance of grinding machines

In a manufacturing environment, equipment failures interrupt production lines or cause product quality issues, aggravated by the prevailing condition that few or no spare parts are usually kept for key equipment, e.g., grinding machines and motors, resulting severe reduction of production capacity in the event of equipment failures.

The current solution of “preventive maintenance” relying on periodic manual inspection is ineffective, laborious and interruptive to production. Predictive Maintenance for the equipment enabled by machine learning will be experimented within the general framework to effectively address this common manufacturing issue.

This testbed is open to new innovative ideas and EdgeX Foundry members are welcomed to join us to widely use EdgeX for industrial internet solution.

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

Another Great F2F TSC Meeting

Written by Keith Steele, CEO of IOTech and EdgeX Foundry Board Member and the Chair of the Technical Steering Committee

Last week, we held a Face-to-Face Technical Steering Committee meeting in Palo Alto. It was another successful one and, after each meeting, my confidence grows that the EdgeX Foundry project will achieve great things.

Before reflecting on the week, I’d like to pass on my thanks on behalf of the community to VMware who hosted the event at their wonderful Palo Alto facility. California Burritos from their cool on-site restaurant was a culinary discovery for me!

EdgeX Foundry passed our one-year birthday in April, so from the EdgeX Charter standpoint, we now move from ‘start up’ phase to ‘steady state.’

While the term ‘steady state’ in the Project Charter refers to a transition to TSC members being voted from the contributing community, it’s a bit of a misnomer when you look at the project activity. This F2F TSC meeting demonstrated that EdgeX is far from static as it grew in attendance when compared to the last F2F meeting. More than 40 people showed up in person from all 4 corners of the world and many more joined by phone. We’re still very much in growth phase…

Elections were held for the TSC and we welcome new Working Group chairs Steve Osselton (Device Services, from IOTech), Trevor Conn (Core, from Dell) and David Ferriera (Security, from ForgeRock). Likewise, we thank Salim AbiEzzi, Doug Gardner and Tony Espy for their contributions on the TSC over the past year, all three will remain active participants in the project going forward.

So, on to the meeting…

The main discussion for the meeting was the status of the California Release, which is projected for early July and the roadmap for the Delhi release due in October.

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

  • Device Service SDKs in Go and C will be previewed this summer and formally released with Delhi (including some representative device services).
  • Performance targets for EdgeX are already being hit, but performance testing as part of the continuous integration and release process will be incorporated.
  • Support for binary data to be processed by EdgeX for the first time to allow for carrying video images, audio data, and the like.
  • The initial system management functionality will include an API for the management of the micro services and an agent to coordinate with other application/cloud infrastructure.
  • Refactored services to incorporate better isolation to allow for future replacement of infrastructure elements such as the local persistent store or message infrastructure.
  • The addition of an EdgeX UI which will be previewed this summer but officially released with Delhi.
  • Research and design on a new Application Services layer to replace the existing Export Services layer of EdgeX will be published with plans to have implemented with the Edinburgh release (scheduled for April 2019).

Research and recommendations on options for the placement of MongoDB as the included reference database will also be announced with Delhi with the intention of offering changes by Edinburgh release.

I was really impressed with the level of collaboration and cooperation at the meeting as there was fabulous participation from all. If you couldn’t make it, this is a timely reminder that EdgeX Foundry is an open project and the recordings of the meeting can be found here.

One thing we did at this meeting, which I thought worked well, was we held a separate Face-to-Face meeting for the Device Working Group prior to the main meeting. Doing this enabled much deeper technical collaboration on important issues before the main meeting. I think this is something we should formalize into our meeting structure across all groups in future meetings.

Additionally, Samsung sought support for updating the project positioning and received it from the TSC. The suggestion is to avoid branding that suggests EdgeX as a strictly industrial IoT platform, especially since EdgeX can be used in much broader IoT solutions to include enterprise, consumer and mobile edge environments. While we will continue to strive to make the platform suitable for industrial workloads, the project will begin to ensure EdgeX Foundry marketing and literature addresses its broader capabilities.

This will certainly lead to a growth in the scope of the Vertical Working Group activity but market positioning was referred to the EdgeX Marketing group with TSC input provided.

The next F2F TSC meeting will be held in my home town of Edinburgh on October 23-24. You can register here and find more information available on the EdgeX Wiki.

We look forward to collaborating with you there!!

Best Regards,

Keith Steele, TSC Chair

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

EdgeX is now fully ARMed

Written by Gorka Garcia, Active Contributor in the EdgeX Community and Senior Lead Engineer at Cavium Inc.

Cavium joined EdgeX Foundry last year and has been committed to get full support for ARM64 in EdgeX, as we explained in our previous blog post. One common drawback of many open source projects is the lack of both build and test in ARM platforms in their Continuous Integration systems (CI systems). This issue can affect customers – it takes time and effort from their engineering resources to work with open source projects and integrate their platform of choice. This directly affects time to market.

On March 1, the Cavium team reached a very important milestone in the process of having ARM64 support in EdgeX Foundry. We got our first EdgeX ARM64 native build and test in the CI system! Since March 1, this machine has performed more than 700 builds with their corresponding unit tests.

The Linux Foundation, which is responsible for the CI system, helped by running it on an OcteonTX platform in Cavium premises and integrating this OcteonTX platform as a build executor node in Jenkins, the CI system. With their help and comparing what was done for PC, we managed to install all the dependencies and had it working in a short time. Since March 1, this machine has performed 26 build works and there have been 141 snapshots of the ARM images built total.

Moving forward, the EdgeX community will be notified of any changes on the source code that affects ARM64 compilation and testing. The next step in this process will be getting CI system to also perform black box testing in the same platform.

Additionally, Cavium recently announced support for EdgeX on its OCTEON TX® family of products, including the CN80xx/81xx and the CN83xx series. Click here for more details.

For more information:

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

Opportunities at the Intersection of Industry 4.0 and the Edge of the Industrial IoT

The integration of physical industrial equipment and machinery with software defines Industry 4.0.

The intersection of Industry 4.0 with the Industrial IoT (IIoT) adds sensors, connectivity, cloud, applications, big data and analytics, and intelligent systems, brings to life real time automation and management across dispersed deployments. This is where real business value is being created.

The instrumentation of machinery using software has changed the nature of manufacturing. It has led to the redesign of production lines and the rethinking of the role of humans as large enterprises continue to look for ways to improve yields, ensure safety, and to save money leading to higher profit margins.

For things to run like clockwork in the manufacturing plants and factories, it’s critical to look at strategy systematically, and build hyper-intelligent capabilities that will provide sustainable improvements.

A big challenge in rolling out the combination of Industry 4.0 and the networks required to fully manifest the opportunity to “command and control” massive and multiple factories with fewer people and more predictable, positive results is getting all the moving parts to move together.

Mastering the intelligent machines is important and great progress is being made there every day. Machines are rolling off their own product lines and legacy machines are being retrofit with sensors to extend the ROI without having to rip and replace. The connectivity of these intelligent machines, including ones from different vendors, integrating software from different control systems, and securing the sessions against cyberterrorism or other attacks is a challenge. It can be very expensive with a lot of “hidden risks” if not architected and implemented wisely.

Controlling the edge of massive intelligent machines so they can be efficiently and securely registered to a private network to send data into cloud applications – where does that data becomes actionable? This may be the hardest part of all, which is why so many companies, including government agencies and critical infrastructure providers, are coming together to orchestrate standard approaches, through open source and other initiatives including EdgeX Foundry.

EdgeX Foundry is an important enabler for interested parties to freely collaborate on open and interoperable IoT solutions built using existing connectivity standards combined with their own proprietary innovations.

Last year, EdgeX Foundry formed an alliance with the Industrial Internet Consortium (IIC) given a shared vision for a highly organized and efficient development effort at the intersection of Industry 4.0 and the IIoT. The two groups work in parallel to bring top companies and organizations together to address fragmentation in two fast growing areas, to make development, testing and commercialization go faster, with less risk in service of the holy grail: commercialization.

It’s an extraordinary and balanced relationship. IIC has successfully built a healthy, active community spanning the entire world of the Industrial Internet, while the EdgeX community has remained 100% focused on solving for challenges at the edge.

EdgeX Foundry is busy working to solve for everything from security (not easy when there are potentially millions of endpoints, including multiple sensor types on the same machine), speed (compute at the edge is different from compute in the core or cloud), and sustainability (long battery life, ruggedized form factors). Additionally, above all else, economics (the edge usually brings with it a subscription business model, and with growing numbers of end-points, the related dollars can add up fast).

Beyond the basics, EdgeX Foundry is also a creative community. The members look to innovate beyond just monitoring and measuring and predictive maintenance.  Essentially, they look at one-way polling into more sophisticated applications that include “remote control,” “automated resets,” and “over-the-air updates,” which is dragging Industry 4.0 into the world of real time communications.

Being able to control millions of machines, or a smaller number of machines with mission critical functions and being able to do securely is money for enterprises and governments. When mundane tasks can be done better by software than people who may be less effective and make more mistakes than a well-designed system that runs beautifully.

This is already seen in the telecom world, where networks have moved to virtualized functions and virtual machines have taken the place of traditional bespoke hardware. The administration of those networks has become easier and far less expensive with automation built in.

We will continue to see massive improvements and cost savings when Industry 4.0 becomes more pervasive. This will only happen, however, when the community comes together to work through all the moving parts, literally, and forge partnerships that enable all the contributors to a given system to build and maintain systems coherently.

IIC and EdgeX Foundry are pioneering together, and are tackling everything from open, human machine interfaces and visualization technologies, business driven smart factory applications, analytics, artificial intelligence, security innovations including blockchain technologies, secure APIs for software and networking, augmented reality for field service, and so much more.

Together with the IIC, EdgeX is rolling forward under a common vision, that no longer will vendor specific or proprietary systems be acceptable, and that creating the environment for open interoperability between connected systems, networks and machines is an imperative.

EdgeX Foundry Member Spotlight: Mainflux

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 Drasko Draskovic, co-founder of Mainflux and the main architect of the Mainflux IoT Platform, to discuss the importance of a growing ecosystem, their IoT framework, the impact EdgeX has made and what the future holds for the company.

What does Mainflux do?

Mainflux developed a full-stack open-source, patent-free IoT Platform, which serves as a middleware and software infrastructure for the development of IoT Solutions and Intelligent products.

Written in Go, deployed in Docker and orchestrated in Kubernetes as a set of microservices, the Mainflux IoT platform is capable of massive deployments (millions of connected devices) and can provide connectivity to any device and any application. The Mainflux IoT platform can be deployed anywhere and respects modern standards such as JSON Web Signature (Json Web Token) (JWT) and TLS, as well as fine-grained, policy-based authorization.

In addition, Mainflux also offers consulting services provided by a cross-functional team that covers all technological layers needed for IoT projects.

Why is your company investing in the IoT Ecosystem?

Over time, IoT has changed the paradigm of single-vendor, end-to-end methodology. Even big companies are realizing that IoT is too complex to approach alone and that fulfilling its promise requires collaboration.

As such, it is important for small IoT companies or start-up businesses to be part of an ecosystem that can deliver technology that meets the customer’s specific business needs and provide acceptable ROI. Our CMO Sasa Klopanovic describes EdgeX as a “David Befriends Goliath” relationship – since IoT giants like Dell, AMD, Analog Devices and Samsung work with startups and smaller companies. The collaboration across the ecosystem brings together the range of expertise and abilities, fostering innovation and rapid growth by allowing multiple providers to work with a common framework.

How is Mainflux involved in EdgeX Foundry?

Mainflux is very active in the EdgeX technical community. Mainflux Co-Founder Janko Isidorovic is the Chair of the EdgeX Applications Working Group and other team members contribute code for EdgeX export services.

Additionally, I am active in the project through continuous following and analyzing issues and reviewing and commenting new contributions. As a project maintainer, I am responsible for approving and merging pull requests and leading technical discussions on improving the code and architecture. I am especially proud regarding monorepo proposal and implementation, file structure and architectural and containerization improvement because it led to dramatic reduction in memory footprint and start-up time.

As a result of my contributions, I was fortunate to be nominated by the technical community and selected as a winner for EdgeX Foundry’s first annual Community Awards. I was honored with both the Innovation Leadership Award, for my technical contributions, and the Contribution Award for my leadership that has made a significant impact on growing EdgeX as an open source project and interoperability platform. I am humbled and very proud of the honor and look forward to reaching more technical milestones with the EdgeX community.

How is Mainflux using the framework?

The EdgeX framework is an essential software block running on our MFX-1 gateway, ensuring connectivity, data processing and computing on the IoT edge. Through it’s Export Services, it connects to the Mainflux IoT platform in the cloud and forms a vertical turn-key solution for IoT.

The MFX-1 gateway is based on Quad 1GHz NXP i.MX6 ARM Cortex-A9 architecture with 2GB RAM and 8GB eMMC assured by our hardware partner Solid Run. One of our focuses is to assure good performance of EdgeX Go components on this type of architecture.

Being an industrial IoT gateway, MFX-1 has a strong requirement for security: the U-Boot bootloader is based on secure boot with ARM Trust Zone and PKI signatures. The Linux kernel is specially tailored through the Yocto framework, HW anti-tampering mechanism are employed and various other types protections are used. On the EdgeX side we have worked on EdgeX Auth service that implements JWT signatures and checking, and various reverse-proxy TLS/DTLS setup needed for constrained devices and applications.

Other things we are working on include EdgeX UI applications for local configuration that will run on a gateway itself and a remote Mainflux app that will manage whole fleet of EdgeX gateways, including handling software updates, status and service information handling, IoT messaging and analytics in the cloud.

How has EdgeX Foundry impacted your company?

During the R&D and implementation process, Mainflux team members gained a lot of skills for the EdgeX architecture and deployment procedures, and became comfortable in using and expanding these technologies. This helped Mainflux build a top-notch team of EdgeX experts who are capable of working on various kinds of consultancy assignments. We know how EdgeX project was built, we were there when it launched, and because of that we believe that EdgeX Foundry will be used extensively within the industry. This will yield a lot of requirements for integration, support and consultancy and we now have a team with EdgeX expertise capable to answer to these requests. In fact, the EdgeX platform will enable new disruptive solutions and applications to be implemented on top and the Mainflux team already has some ideas in the pipeline related to blockchain and decentralized computation on the edge.

If that isn’t enough, we also included EdgeX Foundry in a recent book and won a grant to develop IoT gateways based on EdgeX.

The Book: Scalable Architecture for the Internet of Things.

Our initial proposal for the “Scalable Architecture for the Internet of Things” book published by O’Reilly did not include an EdgeX Foundry chapter. We focused most of it on cloud IoT platforms. However, we soon realized that EdgeX is an extremely important example of the IoT architecture scalability, as it covers the whole edge-fog-cloud continuum and is based on a set of containerized microservices that communicate via standard interfaces or a message busses. It seemed natural to add it in. To receive a copy of the book, click here.

Mainflux recently won a Serbian Innovation Grant.

The Government of Serbia Innovation Fund awarded Mainflux a funding grant to develop MFX-1, an IoT edge gateway powered by the EdgeX Foundry platform. An addition of the edge component to the Mainflux IoT Platform will turn it into a unique open source IoT solution capable of both server-side and edge computing.

More than 130 projects applied for the Innovation Fund and 24 projects were selected. Projects were evaluated by an independent governance structure, with a robust international peer review system and an international Expert Committee.

The combination of Mainflux’s IoT platform and its IoT Gateway based on EdgeX will provide a Mainflux IIoT System, which we’re hoping will lead to an fully-featured open source system for IoT solutions development.

Janko Isidorovic, CEO and Co-founder of Mainflux,receiving the Serbian Innovation Grant at the ceremony.

How to implement an API Gateway & JSON Web Token (JWT) Based Authentication for EdgeX Foundry

Guest post by EdgeX Foundry contributors Tingyu Zeng, Senior Principal Software Engineer and Security Lead for Dell IoT platform development, and David Ferriera, Senior Director – Cloud Technology, Office of the CTO for Forgerock

EdgeX Foundry is composed of a set of micro services running inside Docker containers to provide flexible RESTful APIs for interoperable communications.

Managing and securing RESTful APIs, however, can be a challenge.  RESTful APIs expose a broad and diverse attack surface that needs to be protected. This challenge is not unique to EdgeX Foundry.  It is an issue that must be addressed by any project with a RESTful interface.

A common approach to address this challenge is to utilize SSL/TLS and some sort of authentication/authorization/access control against each individual micro service’s REST APIs.  This is essentially shifting the burden of security to the micro service developers.  Given many developers and many micro services, it is likely to see mixed implementations of the security tightly coupled with each micro service.

A better approach for protecting a set of RESTful API resources is the API Gateway model. It presents a unified interface to the outside world. Additional authentication mechanisms like OAuth2, JWT, API Key, HMAC etc. can be applied as well.

In the EdgeX Foundry project, security is designed as a service, and runs just like other services that provide valuable capability to the IoT environment. A reverse proxy/API gateway service sits between external users and all EdgeX micro services. It serves as a single point of access to external users and helps protecting the EdgeX micro services from the “wild west” of the Internet.  Some of the benefits we are gaining here are:

  1. As a centralized access point for all of the EdgeX micro services, it minimizes the attack surface even the number of EdgeX micro services increases in the future.
  2. As an independent service, the implementation can be replaced easily if needed.
  3. Code related to protecting each micro service does not have to be placed in each micro service, thereby reducing different or problematic implementations and reducing the number of code changes if the security strategy needs to be modified in the future.

Kong (http://www.konghq.com), a popular open-source micro service API gateway, is chosen to secure the EdgeX micro service APIs in the upcoming California Release (June 2018) due to its flexibilities on API namespace management and plugin supports. Combined with JWT, it provides the basic security feature of authentication for EdgeX. Other authentication methods such as basic authentication, key authentication could be used in a similar way if needed.

This set of instructions below show how to setup Kong to be used with EdgeX to secure the RESTful APIs.  Once setup, those calling on the EdgeX APIs can skip to steps 15-18 to invoke the EdgeX APIs through the reverse proxy.

Step 1. Run the postgres sql database for Kong.  The postgress database is provided in a Docker container. The database will hold the configuration/policy information.

Step 2. Run the Kong database Docker container. Notice we are using Kong version 0.13.0 here since we are taking the services/routes object approach which is a preferred way based on Kong’s latest document.

Step 3. Run the Kong container. Notice in production environment we may need to minimize the listening footprint by avoid using broad interface such as 0.0.0.0:8001 and 0.0.0.0:8444.

Step 4. Start the EdgeX micro service based on the steps in the wiki

https://wiki.edgexfoundry.org/display/FA/Get+EdgeX+Foundry+-+Users

At this point we should have several Docker containers running, which include a couple of EdgeX micro services as well as the Kong and postgress database.

With the EdgeX micro services running, the APIs can be exercised as usual. Here we are using ping to check the health of the core-data micro service (core-data operates on port 48080 by default).

http://localhost:48080/api/v1/ping.

Step 5. Now we need to set up Kong to run on the same user-defined network inside Docker as the rest of EdgeX containers. The name of the user-defined network can be obtained from “docker network ls”. In the testing environment it show the name as “composefiles_edgex-network”. This can be done by running the command below:

Step 6. Here comes a tricky part– we need to get the IP address of the host for the Docker container.  A “ipconfig” command in the windows console shows it is 192.168.1.151 in our testing environment.  The IP address is the value of host parameter in setting up the redirect path of the proxy when configuring services and routes for the EdgeX micro services.

Step 7. Create a service entry for each of the EdgeX micro services. Here is an example to create a service entry for core-data of EdgeX.

Step 8. Create routes for each of the services. Below, a route is created for core-data.  Multiple routes can be associated with one service if needed.

Step 9. At this point we have finished mapping the core-data REST API with the Kong reverse proxy. In order to make the “ping” REST call to the core-data micro service of EdgeX (previously http://localhost:48080/api/v1/ping as show above) one would need to call on http://localhost:8000/coredata/api/v1/ping . With service and routes defined in Step 6 and 7, any core-data REST API is called on using the base URL of reverse proxy http://localhost:8000 as the entry point.

The hostname and port of the reverse proxy are configurable (see the Kong documentation https://getkong.org/docs/0.13.x/configuration/#admin_api_listen). With Kong and the service/route configuration complete, the only EdgeX port that need be exposed is that of Kong.

Step 10. Next,  we enable JSON Web Token (JWT) authentication to protect the core-data micro service. After doing so, any HTTP request to core-data will be denied if no JWT is associated.

Step 11. we Invoking the curl HTTP request against core-data REST API now results in an unauthorized 404 error indicating authentication is required.

Step 12. Assume we will have a user “adam” that wants to consume the protected core-data REST API. The customer needs to be defined on our reverse proxy first using the command below.

Step 13. Then we need to create a JWT credential for “adam”.

Step 14. Note: any consumer like “adam” can be removed from the associated JWT credential store later with an HTTP DELETE call as shown. Note “id” placeholder below would be replaced with the token we got from previous step.

Step 15. In step 13, we have got the JWT credential for the consumer “adam”.  We can use an HTTP GET request like below to retrieve or re-fetch that same  information.

Step 16. After obtaining the needed JWT credential we will be able to create a JWT token that can be used for authenticating “adam”.  Ordinarily, we would write code to create the JWT token.  For the sake of demonstration, we will create the JWT token manually here.

Go to https://jwt.io/  and use information in the previous step to get a JWT token. In the Payload Data elements, make sure to use the key value obtained in the previous step when creating the JWT token as the value to the “iss” field value (which is required) along with the username (optional). Replace “secret” in the Verifying Signature section with the secret value obtained in the previous step when creating the JWT token.

Step 17. Now we have JWT token associated with the consumer “adam” and it can be used it to authenticate through the proxy and access the REST API resources of EdgeX and avoid 404 unauthorized errors!

Step 18. Optionally, the JWT token can be passed with a query string instead.

In conclusion, we have implemented the EdgeX reverse proxy/API gateway and JWT authentication using Kong.  This is not the end of the EdgeX security story for sure – authorization, access control list (ACL), URL parameters filtering, URL white listing etc., can also be integrated with existing security mechanisms to provide an even better shield around the EdgeX micro service APIs down the road.  For now, Kong and JWT help to provide EdgeX with its first line of defense against inappropriate micro service access and allows us to incorporate other security capabilities in the future.  And it does so in a way that can be easily augmented or replaced in the future and it does not require implementing that security in each micro service.

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.

Hannover Messe – Innovation, Collaboration and Celebration

EdgeX Foundry joined the 210,000 visitors that spent last week at Hannover Messe.  Several member companies were on-site to help us celebrate our 1st anniversary, welcome new members and share what EdgeX can do! Check out our photo album and let us know if you have photos to add!

EdgeX Foundry had a strong showing in our booth (Hall 6: B17) with members Canonical, IOTech, IoTium, RSA, Dell EMC, SoftwareAG/Cumulocity and VMware displaying interactive IIoT demos.

More than 1,500 visitors, media and analysts stopped by the booth to learn more about EdgeX.

In addition to the EdgeX Foundry booth, other members were on hand including: Aicas, Analog Devices, CloudPlugs, FIWARE Foundation, FogHorn Systems, NetFoundry, IIC, Reply Concept and Tulip Interfaces.

One of the highlights of the show was the EdgeX Foundry and Industrial Internet Consortium (IIC) Networking Dinner, which was presented by member NetFoundry.

Another highlight was recognizing the winners of the first annual EdgeX Foundry Community Awards. Congratulations, again, to Drasko Draskovic, CEO and Founder of Mainflux, and Tony Espy, Technical Architect for Devices and IoT for Canonical, Ltd, for winning Innovation Awards  and  Andy Foster, Product Director for IOTech, and Drasko Draskovic are being honored with Contribution Awards.

We had a great time at Hannover Messe and will definitely be back next year. Thank you to everyone who stopped by our booth and help celebrate our 1st anniversary!

 

In case you missed the EdgeX Foundry news and blogs, check out these additional resources:

Happy 1st Anniversary EdgeX Foundry!

The EdgeX Foundry community is back in Hannover this year, showing off the progress our members have made in developing a common interoperability framework and platform designed to make collaboration on Industrial IoT solutions that scale happen faster – and with less risk.

Our community is exceptionally proud of the members we’ve attracted, nearly 80 members in 17 countries including representation from the United Kingdom, South Korea, Serbia, Spain, Tunisia, Canada, Israel, Germany and Japan. We are equally proud of the composition of our collective – from small, agile start-ups, to some of the largest tech companies in the world.

In fact, our ecosystem continues to grow and today we welcome the addition of five new members, including Civil Infrastructure Platform (CIP), ETRI, ISSAT Mateur, Samsung SDS and Volterra.

Award Winning

What’s great about the mix is the co-existence of so many diverse businesses, technologists, business development experts, and overall problem solvers that bring a unique perspective of leadership and innovation. In fact, this year, to mark our first anniversary, we launched the first annual EdgeX Foundry Community Awards to honor those individuals who have contributed in leadership and innovative solutions.

Community members nominated their peers and the EdgeX Foundry Governing Board selected two winners for the Contribution Award, which highlights leaders who have helped EdgeX Foundry advance momentum this year, and the Technical Steering Committee (TSC) selected two winners for the Innovation Award, which recognizes individuals who have contributed the most innovation solution.

We are excited to announce that Drasko Draskovic, CEO and Founder of Mainflux, and Tony Espy, Technical Architect for Devices and IoT for Canonical, Ltd, as winners of the Innovation Award for their extensive technical contributions. Andy Foster, Product Director for IOTech, and Drasko Draskovic are being recognized with the Contribution Award for their exemplary leadership that has made a significant impact on growing EdgeX as an open source project and interoperability platform.

Tony Espy from Canonical at Hannover Messe receiving the Innovation Award

 

Going Commercial

In addition to honoring these outstanding achievements from the EdgeX community, our first anniversary also introduces the fact that several project members, including Cavium, Cloud of Things, Dell, IOTech, Mocana, RSA and VMware, have already started to provide commercial solutions based on EdgeX, while others have embedded EdgeX technologies into their product and solution roadmaps.

More exciting news? The Government of Serbia Innovation Fund has awarded member Mainflux a grant to develop MFX-1, an IoT edge gateway powered by EdgeX platform. (For more information about the grant, click here.)

Hannover Messe

If you’re at Hannover Messe, the EdgeX Foundry booth, located in Hall 6: B17, will feature interactive demos from Canonical, Dell, IOTech, IoTium, RSA, Software AG and VMware. (Demo information can be found in this blog.) If you’re there, swing by to ask questions or congratulate Tony Espy and Andy Foster on their awards!

Follow us during Hannover Messe on Twitter, LinkedIn and YouTube.

Web Console for Multiple IoT Gateways

Guest post by Huaqiao Zhang, developer for VMware and contributor to EdgeX Foundry 

Preface

When users start using EdgeX, they could quickly run the service framework according to the official documents of EdgeX Foundry. EdgeX is a headless framework; often running in environments where there is no user interface capability or on systems that don’t have a display.  As a developer, this might be a bit inconvenient.  I decided to use an HTTP client tool and call EdgeX’s Restful APIs to become familiar with the features. However, you might desire something that is easier and more friendly to use.

This is what gave me the idea to create a Web Console where users only need to operate in the browser instead of manually typing in a lot of commands with parameters and assemble complex JSON data.  According to the EdgeX roadmap, the integration of EdgeX to various system management capabilities will soon allow those system management products, which often offer user interface consoles, to help users operate and manage EdgeX.  Importantly, these management systems will help manage multiple instances of EdgeX and the platforms it runs.  The Web Console that I created and contributed to the EdgeX, can serve as a tool for developers that want a better experience in interacting with the EdgeX microservices, or as a good starting point for those looking to create more extensive interfaces.

Why we need the Web Console

When a new user wants to add a new device to a gateway, if there isn’t a Web Console, he has to put some time and effort of learning the Restfull API of EdgeX Foundry and needs to confirm whether the relative data exist for DeviceService, DeviceProfile, DeviceAddress, etc. If not, he has to create it, then gets the ID or Name of that feature. Finally, he assembles complex JSON data and upload it. As another example, sending commands to a device could be even more complicated. All these could be hard for a new user or an on-site debugging engineer, but a Web Console would make it easier.

How to manage multiple gateway instances

When an enterprise uses EdgeX Foundry, multiple gateways can be deployed onsite. In most cases, each gateway has an internal IP address in the LAN rather than an Internet address. So, how to manage these gateways via a web console? There are two approaches:

  • A Web Console is deployed to each gateway. In this case, users need to remember the address of each gateway to operate and maintain multiple web consoles. Each gateway has to cost some resources to run its own web console.
  • Multiple gateways share one Web Console. In this case, there is a method to switch among all the gateways. All operation requests will be proxied to the selected gateway. With this approach, users only need to remember one address and maintain one Web Console.

Comparing the two options above, I prefer the later one. The limitation is that all gateways must be accessible to the host where Web Console is deployed. But in a company’s intranet, this should not be difficult.

Problems solved and basic implementation

The assumptions and expectations of multi gateway sharing Web Console are:

  • Gateways can be anywhere, but for an enterprise, they may all be in the intranet.
  • The host, which the Web Console is deployed on, can be one of the gateway or a PC that can access all gateways directly. So, the console should be very light weighted.
  • All operation requests should be dynamically proxied to the gateway selected by the user.
  • Multiple users could operate different gateways at the same time without affecting one another.

Based on these requirements, the fundamental architecture is shown below:

The basic user’s operation flow is shown as below:

  • After login, a user will be navigated to the management page of the default gateway. If there are no gateways at all or none selected, most menu items will not be permitted to operate.
  • When the user selects or creates one gateway, the metadata of gateway are stored into the local database in the web console.
  • Once one given gateway is activated, all operations will be proxied to the target gateway, then the data will be returned to Web Console.
  • Multi-user’s operations on different gateways will not affected one another.

Some necessary operations are illustrated below.

Gateway Management

 

Adding a Device

 

Device Service Management

 

Exporting Registration

 

Exporting Data Show

 

Check it out the video demo here: https://www.youtube.com/watch?v=2EOHR_gUeic.

Conclusion

This is just a prototype. I would like to gradually add some new features, such as a gateway location information using google map and video streaming. If you are interested in this web console for EdgeX Foundry, and want to join me on the effort, please ping me at https://twitter.com/Huaqiao_Zhang or the repos at GitHub: https://github.com/badboy-huaqiao/simple-local-gateway-console or https://github.com/badboy-huaqiao/edgex-foundry-web-console.

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.

EdgeX Foundry on Display at Hannover Messe

From April 23 – 27, more than 220,000 attendees, speakers and exhibitors from 75 countries will be at Hannover Messe, one of IIoT’s leading trade shows in Hannover, Germany, to share best practices, display new technology and discuss what the future looks like for industrial systems.

EdgeX Foundry will be on-site at the tradeshow with a full agenda of activities in our booth, Hall 6: B17. Members from Canonical, IOTech, ioTium, Dell/RSA, SoftwareAG and VMware will be demonstrating leading-edge industrial IoT solutions based on EdgeX. Experts from these member companies will also share keynote presentations about edge computing, smart buildings, the challenges of interoperability, open source ecosystems and more.  Stay tuned here for the schedule.

Interactive demons at the EdgeX Foundry Booth, Hall 6: Stand B17 include:

Canonical: Canonical will be demoing a snapshot of the latest EdgeX development release called ‘California’ running as a fully-confined snap on Ubuntu Core 16.  This will be demonstrated on an Arrow/Qualcomm Dragonboard 410c.

IOTech: IOTech will demonstrate the power of edge computing and the benefits of its commercial offering Edge Xpert – the Open IIoT Platform for Edge Applications.  The ‘Edge Xpert’ will run on a 32-bit embedded ARM controller and integrate with a Modbus Smart Power Meter. It will showcase a live data visualization and edge-to-cloud integration between Edge Xpert and AWS IoT Platform.

ioTium:  ioTium will present their edge-cloud infrastructure solutions. They will be showcasing ioTium OT-Edge; bridges edge and cloud computing by moving applications to data; allows mission critical data to reside on-premise in industrial and manufacturing environments. With ioTium OT-Edge, applications are moved – not the data. With a single click from ioTium’s cloud-based industrial app store, applications can now be deployed at scale, across the edge.

Dell/RSA: Dell/RSA will present the power of EdgeX as a secure IIoT platform enhanced with hardware platform from Dell and innovative security software from RSA Labs. Their demo will showcase the use of security analytics for monitoring and threat detection for the IoT Edge, secure communication using OPC-UA (an industrial automation protocol) and protection of credentials at the edge.

SoftwareAG: Cumulocity’s IoT Edge platform supports a distributed architecture, with dashboards, analytics rules, apps and integrations developed for the cloud transferable to edge deployments and Edge Real-time streaming analytics.  Their demo is a small replica of a real use case where Cumulocity IoT Edge is being used to manage the operation of wind farms.

VMware: VMware will be showcasing how to take control of the Edge through VMware Pulse IoT Center and EdgeX technology with the aim to virtualize and isolate on the edge for enhanced security, manage heterogeneous edge gateways or systems, and integrate Industry protocols.

Want to see more from EdgeX Foundry?  You can visit other member company booths including:

If you cannot make it, you can keep up to date by following us on @EdgeXFoundry for highlights and pictures from the event and the EdgeX Foundry YouTube Channel for all the latest videos!

EdgeX Foundry Member Spotlight: Xage Security

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.

Meetup: Open Source IoT Enthusiasts Unite!

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.

EdgeX Foundry @ OpenIoT Summit

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

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!

EdgeX Foundry Member Spotlight: CloudPlugs Inc.

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 3rd 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.

EdgeX Getting Skinny and Fast with the California Code Preview

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.

Simplified IoT Powered by EdgeX Foundry

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.

EdgeX Foundry Member Spotlight: Mocana

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.

 

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

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

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

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

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

EdgeX Road Map

 

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

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

EdgeX Foundry Members

 

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

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

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

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

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

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

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

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

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

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

Are we there yet?

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

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

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

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

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

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

Size (and speed) matters.

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

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

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

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

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

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

Get on the bus!

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

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

It’s all about the APIs.

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

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

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

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

What’s with that ‘X’?

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

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

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

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

It’s not just about gateways.

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

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

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

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

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

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

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

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

Putting things in perspective.

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

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

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

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

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

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

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

Running EdgeX Foundry on Kubernetes

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.

EdgeX F2F TSC Meeting and the evolution of the EdgeX Cadence

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

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

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

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

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

California Release Planned

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

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

Architectural Resolutions

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

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

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

Other Significant Work

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

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

Other highlights include:

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

And We Had Fun!!!

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

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

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

EdgeX Foundry Member Spotlight: Kodaro, LLC

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.