Seven Things to Consider When Selecting Your Edge Platform

Getting Started – Seven Things to Consider When Selecting Your Edge Platform

Your organization has decided they want to create or extend their edge capability. Congratulations and welcome to Industry 4.0! How do you get started?

What ingredients do you need to create your solution? What should you look for in an edge platform? What technologies do you leverage? All good questions.

Of course, you want to begin your journey by defining what you expect to gain by putting an edge solution in place. Why are you looking to institute an edge solution? What’s the return on the investment? After having a goal, think about what is needed in order to fulfill that goal. What are the requirements of the solution in order to achieve the goal? With a goal and requirements in hand, you can create or select the technology – an edge platform - that can satisfy the requirements.

While there are many considerations, IOTech has found there are a few “abilities” that organizations should look at foremost when identifying and selecting edge platforms to use in their edge solutions.

1. Flexibility

The key ingredient to a good edge platform is its flexibility. The edge is incredibly diverse - in its equipment, network connectivity, communications protocols, latency requirements, expanse, etc. Further, your edge use case will not be my edge use case, even when we are in the same organization. The needs and use cases will change and grow. If a single-edge platform is going to tackle diversity, it must be very flexible and adapt to the many needs. 

Can your edge software run in any environment, on any hardware architecture, or on any OS? Can you remove elements not suited to your use case (reducing size and complexity and perhaps improving performance)?

Can you extend or add elements (maybe even 3rd party elements) to the platform when required? Can your edge platform be easily configured – allowing any single instance to work in a specific role with a different behavior but without requiring custom programming?

The platform architecture can be important for flexibility. A loosely-coupled, microservice-based platform with well-defined APIs and interfaces, for example, allows for features and functions to be added, removed, upgraded, and replaced more easily.

2. Openness

While not absolutely required, open-edge solutions tend to be more flexible, allow for easier incorporation of 3rd party elements such as analytics, and generally adapt better to an ever-changing landscape. When possible, look for platforms that have a foundation in an open-source community like the Linux Foundation, and/or adhere to open standards.

Openness allows everyone to see how things work and to give input for improvements. Openness enables competition and the evolution of best-of-breed solutions. Openness invites and encourages collaboration and extension. Openness helps avoid expensive vendor lock-ins. In a landscape as heterogeneous and diverse as the edge, openness allows more people, products, and organizations to be involved in helping to assemble your edge solution.

3. Incorporates Intelligence

If you are not doing some analytics at the edge – that is processing and understanding some of the edge data – then you are often missing the larger opportunity in edge computing. Organizations often start their edge journey by collecting edge data and moving it to the enterprise. But eventually, you want to get the data to some sort of analytics capability at the edge and act on it quickly (with low latency) at the edge. Or, at the very least, sift through all the data for valuable bits of information as opposed to trying to haul all the data produced at the edge to the enterprise. Sending all data to the cloud or enterprise can be very expensive and is not always necessary.

The analytics can be rudimentary and can evolve over time. Simple analytics may just be in place to filter valuable and meaningful data from data noise. Incorporating a simple rules engine or decision algorithm to detect certain sensor values and react accordingly helps to automate more – requiring fewer people or enterprise resources and often providing better reaction times. Later, incorporate more AI/ML at the edge to detect patterns, see things and take pre-emptive actions that even humans could not see before.

The analytics or knowledge you put into your edge solution is your intellectual property that you know best and which the edge platform will not, typically, automatically include. It is probably the place where you should embed your intellectual property. The trick is that your edge platform has to be constructed such that you can pick and/or add this secret sauce, and have the edge platform get data to any analytics capability and receive actuation commands from the analytics capability when action is required.

4. Southside Connectivity

In the edge/IoT world, we often refer to the “southside” as the devices/sensors connected at the farthest level of your environment. When exploring edge platform solutions, connectivity to your equipment is a key ingredient. After all, you are trying to connect your operating edge (your southside) to the enterprise (your IT environment - cloud, databases, applications, etc.). This is the whole point of your work. So obviously, you want to ensure that the platform you choose (or build) can connect the devices/sensors currently in your inventory.

Some platforms (platforms written by those that do not always understand operational technology) will give you an MQTT connection or offer only a few limited, popular connectors to edge devices/sensors. This leaves you in the troublesome position of having to get the devices/sensors connected to the MQTT pipe or having to find the means of connecting your platform to some of the many native protocols. 

Look for platforms that support your need – to connect sensors/devices speaking Modbus, BACnet, OPC-UA, BLE, Zigbee, and more common protocols found at the southside as well as MQTT and REST. Even if your need today is limited to one or two protocol connectivity types, you want to use a platform that supports a large and growing list of southside protocols as your connectivity needs will likely expand as your edge expands.

Remember that connectivity at the southside wants to be, if not initially, bi-directional with edge data moving to the IT world and the IT world sending actuation commands to the devices and sensors on the southside. Ensure your edge platform supports this two-way communication.

Also, look to see that the platform provides a Software Developer Kit (SDK) to assist in creating new connectors – especially where you have a device/sensor speaking a proprietary protocol or an unusual and non-standard protocol.

5. Northside Connectivity

The “northside” is, from an edge perspective, where the edge information is directed. Typically, this is your cloud providers, enterprise applications, and databases. On the north side is your IT world – where you plan to store your data long-term, comb through it for more insights, and use it to drive future operations.

While the IT world (your northside) is dominated by TCP/IP protocols, there are still many issues in getting data to the north – especially when there are many destinations for edge data. Therefore, your edge platform needs to offer flexible connectivity options to the north as well as to the south. Make sure your edge platform can speak and stream edge data to all the major cloud providers and support data in all types of formats (JSON, XML, etc.).

Ensure that it can communicate securely (as defined by the Northside system) and filter, compress, and otherwise transform edge data as required by the Northside systems.  Ideally, the edge platform should come with much of the northside connectivity you need, but where it does not, ensure it also has an SDK to help create new northside connectivity where the platform doesn’t offer it out of the box.

In short, your edge platform has to be the Rosetta stone between the south and the north – ingesting, transforming, and dispensing edge data between many protocols, formats, and types in the communications between two worlds: OT and IT.

6. Edge Operations

When building an edge solution, many engineers think about how to collect data from a sensor and get it to the analytics package or backend cloud database. Most concentrate on the basic workflow of the edge use case. That is, they address data collection and data movement once the system is up and running, but they don’t consider installation and daily operations of the solution. Force yourself to think about before and after that first day of “normal” operations. Think about when your solution is yet to be installed.

Think about it after your solution is in place but things break. How does the edge solution get deployed and orchestrated – especially when it can involve an edge scale of thousands of nodes? What happens after the edge solution begins to consume all of its resources? What happens when the edge solution encounters issues – like a sensor going offline? How does the edge get a fix or an upgrade? How and when are you notified of issues? Would you even know when something isn’t behaving normally?

Good edge platforms must address deployment, orchestration, monitoring, and management of the edge solution as well as simply perform the normal daily operations of collecting/moving edge data and actuating devices. The edge platform must assist in getting itself to the edge and provide the means to monitor itself – alerting you when there appears to be a problem at the edge. The scale of edge and remoteness makes this task more challenging.

7. Scales

Edge scale applies to the enormity of edge solutions and their reach. Edge scale often means (depending on the use case) the solution runs on hundreds or thousands of nodes and connects to even more sensors/devices (scale of deployments), often in very remote locations (scale of distance), generating a lot of data (scale of volume), must operate in a variety of environments and connect a variety of back ends (scale of complexity). Edge platforms should address all the dimensions of edge scales effectively. Almost anyone can get a single instance of something collecting a few data points from a device sitting on their desk. Start collecting from thousands of sensors spread across the state of Texas at the rate of millions of data points a second and you have a vastly different solution to worry about. Make sure your edge platform scales to your production deployment needs.

Want to know more? Want to know how IOTech provides software to meet your edge platform needs with Edge Central? Click here to learn more.