May 2018

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.

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.

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.