Category

Blog

Welcome California!

By | Blog

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

By | Blog

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

By | Blog

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

By | Blog

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

By | Blog

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

By | Blog

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

By | Blog

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

By | Blog

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.

Mainflux

EdgeX Foundry Member Spotlight: Mainflux

By | Blog

The EdgeX Foundry community is comprised of a diverse set of member companies that represent the IoT ecosystem. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source solutions. Today, we sat down with 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

By | Blog

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.