Category

Blog

EdgeX F2F TSC Meeting and the evolution of the EdgeX Cadence

By Blog, EdgeX Foundry

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

By Blog, EdgeX Foundry

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.

 

 

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

By Blog, EdgeX Foundry

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

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

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

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

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

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

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

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

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

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

EdgeX Foundry Member Spotlight: Two Bulls

By Blog, EdgeX Foundry

The EdgeX Foundry community is comprised of a diverse set of member companies that represent the IoT ecosystem. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source solutions. Today, we sat down with Noah Harlan, EdgeX Foundry Board Member and Founder of Two Bulls, to discuss the IoT market, connected devices and security.  

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

Porting EdgeX to Pivotal Cloud Foundry

By Blog, EdgeX Foundry

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

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

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

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

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

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

<dependency>

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

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

<version>2.0.1.RELEASE</version>

</dependency>

<dependency>

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

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

<version>2.0.1.RELEASE</version>

</dependency>

<dependency>

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

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

<version>2.0.1.RELEASE</version>

</dependency>

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

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

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

spring.cloud.appId:    edgex-core-data

spring.cloud.data-service: mongodb-coredata

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

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

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

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

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

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

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

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

The issues I faced here were as follows:

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

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

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

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

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

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

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

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

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

Performance Vs Flexibility – EdgeX Microservices Could be Combined

By Blog, EdgeX Foundry

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

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

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

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

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

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

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

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

EdgeX Foundry Member Spotlight: IOTech

By Blog, EdgeX Foundry

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

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

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

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

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

EdgeX Momentum

What’s driving momentum?

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

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

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

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

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

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

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

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

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

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

EdgeX Commercialization

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

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

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

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

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

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

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

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

EdgeX enables Phenomenal Applications

By Blog, EdgeX Foundry

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

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

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

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

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

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

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

For more information, you can check out these resources:

EdgeX ARM64 Support

By Blog, EdgeX Foundry

Written by Gorka Garcia and Federico Claramonte from Cavium 

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

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

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

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

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

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

The Future of EdgeX is Go Go Go with Go Lang

By Blog, EdgeX Foundry

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

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

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

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

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

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

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

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

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

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