Where is “The Edge” and why does it matter?

Nikunj Mehta
Apr 7, 2022

Key takeaways:

The Edge is an optimization problem - It is not a place and not a single technology.
There are several factors to consider when deciding whether and what kind of distributed computing technology to use in pursuit of solving a business problem.
The ability to support a spectrum of edge and cloud deployment options is a valuable capability in considering which vendors to work with.

The Edge is not a place – It is an optimization problem. Edge computing is about doing the right things in the right places. As with all optimization problems, getting to the “right” answer requires considering a number of tradeoffs that are specific to your situation and then applying the right technology to maximize the benefits for the cost you are willing to pay.

Terms and technology

Part of what makes Edge confusing is that definitions of “The Edge” tend to focus on technologies rather than on use cases. Since use cases span a very wide range of requirements and the boundaries between those use cases don’t map directly to technologies, definitions in terms of technology can be difficult to use. That said, here is a framework that I find helpful.

Fig 1 – One framework for thinking about edge compute

The basic idea behind edge computing is that the closer the compute hardware is to the equipment generating data, the closer to “The Edge” it is. Broadly speaking, computing domains can be divided into edge and cloud – that is, local to your network and outside of your network. Within each domain, options can be further subdivided:

Cloud – outside of your local area network
- Cloud data centers – large facilities which host computing, storage and networking resources in a central location. In general, this puts a large distance between data generators and compute resources.
- Edge cloud – smaller versions of data centers which are collocated with wireless transmission towers. This puts a minimum distance between cellular WAN (Wide Area Network) or LPWAN (Low Power WAN) receivers and compute resources. This also includes distributed cloud data centers which are strategically located to minimize distance from customer access points.
Edge – inside your local area network
- Edge servers – smaller footprint but general high-performance servers that are on premise and may or may not be close to actual equipment. There are a range placement options (from local data center to plant floor) necessitating a range of ruggedization options.
- Intelligent gateways – lower performance, very small footprint, general purpose computers that are usually placed close to the equipment that they connect to. These are frequently on the plant floor or in the field and need to be ruggedized.
- Smart sensors – special purpose, low-power, often microcontroller-based compute dedicated to data collection or processing for a specific sensor or device.

Plants will generally have a mix of compute capabilities that serve different purposes so expect to see some or all of these deployment options in any facility that you work with. The important point is that there is a range of capabilities and that those can be grouped, roughly, into categories. There is nothing inherently superior about any of the options. Rather, the choice of which one(s) to use depends on what you want to achieve.

Edge vs Cloud – Optimizing for constraints

Edge computing is important because it allows you to achieve certain performance that cloud computing cannot. Likewise, cloud computing is good at certain things which edge computing is not. Therefore it is important to consider the problem you’re trying to solve in order to select the right approach. The table below outlines some key areas to consider and under what conditions edge or cloud might be superior.

Factor	Description	Edge	Cloud
Latency	The amount of time it takes for data to make it to the compute resource and for a result to be returned.	Lower latency (few ms) due to proximity to equipment	Higher latency (100s of ms) due to distance from equipment
Intermittency	The fraction of the time that the data-generating equipment lacks the ability to transmit data to remote compute resources.	Supports highly intermittent cases. Compute can be collocated with equipment	Supports cases with low intermittency. Requires always-connected network configuration
Data transfer costs	The price per bit of sending data from the equipment generating it to compute.	Lower cost as data travels less distance and typically over LAN (Local Area Network).	Higher cost as data travels over (expensive) cellular or other WANs.
Computational power	The number, speed and bit depth of CPU cores, GPUs and memory that can be applied to computation.	Generally less powerful hardware the closer it is to the equipment due to smaller form factors and electrical power limitations	Generally more powerful hardware available due to larger form factors and higher electrical power consumption limits
Storage costs	The price per MB of stored data.	Higher price per MB due to smaller form factors and ruggedization	Lower price per MB due to larger form factors, controlled environments and storage tiering
Scalability	Ease with which compute resources can be increased.	Less flexible scaling due to capex required for edge hardware and possible redesign and requalification of equipment.	More flexible scaling due to opex-based paths for increasing resources in cloud
Sharing / Collaboration	Ease with which data and application output may be shared among widely dispersed groups (e.g. globally).	Lower level of sharing due to localized infrastructure	High level of sharing due to centralized, cloud-based infrastructure
Data retention / reporting	Ability to serve as a system of record from which compliance reports and audits can be performed.	More difficult to find data and create reports due to distributed infrastructure	Easier to find data and create reports due to centralized infrastructure with large storage capacity.

Table 1 – Some considerations for selecting cloud vs edge computing

Long story short, Edge is a good choice for applications which need results VERY quickly (low 10s of milliseconds), that generate significant amounts of data in locations that have intermittent, low-bandwidth or high-cost connections and that don’t require extremely complex calculations. Cloud-based infrastructure is better for almost everything else if not in performance, then in procurement cost and operational complexity.

Where is your Edge?

An example can help make some of these factors more concrete and highlight how different aspects of equipment operations might be better served by different combinations of Edge and Cloud technologies.

A mining operator has a fleet of mobile drilling rigs which are deployed to various locations in a mine. They are concerned about three things: 1) Emissions compliance for the rig’s exhaust, 2) Signs of very near term equipment failure during operation and 3) Condition Based Maintenance (CBM) planning. The nature of the deployment means that the drill rigs are frequently outside of WiFi range of the rig storage facility. Cellular coverage is non-existent at this location. Constructing and deploying private cell towers is cost-prohibitive and wireless LPWAN technologies lack the bandwidth for these applications. The table below shows how one might consider which computing technologies best address these three needs.

Factor Bold text indicates high relevance to technical approach	1) Emissions monitoring	2) Criticality of anticipating failure	3) CBM planning
Latency	No requirement Responses to emissions issues are manual so seconds of delay are unimportant.	No requirement There are no automated responses to warnings so seconds of delay are unimportant.	No requirement Maintenance planning is done daily. Seconds of delay are not important.
Data delay due to Intermittency	Not tolerable Violations must be dealt with in the field, away from network connections.	Not tolerable Near-term failures must be assessed and avoided in the field, away from network connections	Tolerable Important precursors to maintenance are visible weeks in advance, well within the normal schedule for drills to come within range of WiFi stations.
Data transfer costs	High Sending data in a way that meets intermittency constraints would require satellite link.	High Sending data in a way that meets intermittency constraints would require satellite link	Low Existing WiFi networks can move data in a way that meets intermittency constraints.
Computational power	Low Smart sensor solution exists which can calculate exhaust concentrations and report violations.	Low Assessment models are inference-only and run on lightweight compute hardware.	High Schedule optimization algorithms are computationally intense for the full fleet.
Storage needs (storage costs)	Low Store detailed data only on violation with limited sampling of normal operations.	Med Store multiple channels of signal data and anticipate events for several weeks.	High Store all signal data and all maintenance records from all drills in the fleet for multiple years.
Scalability	Low Little need to expand emissions monitoring approach other than when adding new drills.	Med More complex techniques and additional failure models may require additional compute resources.	Med More complex optimization techniques and additional CBM factors may require additional compute resources.
Sharing / Collaboration	Low Recovery actions are taken by the drill operator independently.	Low Recovery actions are taken by the drill operator independently.	Med Maintenance scheduling is performed by a local team. Visibility into factors and scenarios across the team is important. Limited need for global teams to see the details underlying maintenance scheduling.
Data retention / reporting	High Emissions compliance requires long term, complete records.	High Model improvement requires long term storage of signal data from across the fleet for best outcomes.	High Model improvement requires long term storage of signal data, actual maintenance reports and predicted maintenance instances from across the fleet. Maintenance cost KPIs are derived from this data.
Technology approach	Requirement for consistent reports in a disconnected environment with high data transfer costs demand an on-vehicle (edge-based) approach. Using a smart sensor with the required data collection and processing capabilities meets those needs. Data retention requirement for compliance reporting is not easily met by the smart sensor alone, so an on-vehicle storage system is needed to hold emissions data in the short term and to transfer it periodically to long term storage in a compliance DB.	Requirement for consistent reports in a disconnected environment with high data transfer costs demand on an on-vehicle (edge-based) approach. Because of the need for higher computational flexibility and larger storage capacity, a ruggedized, intelligent gateway or small industrial PC (IPC) is needed. Such a configuration will support periodic off-loading of sensor and prediction data to a central storage and learning system for long-term analysis and model updates.	Requirements for high levels of compute power and storage, the longer time frame allowable for processing data, the need to easily share on-going work and to generate consolidated reports about fleet behavior suggest that a datacenter-based approach to infrastructure is best.

Table 2 – Considerations for choice of technology (edge vs cloud) for three aspects of operating mining equipment.

Making your Edge work for you

Because The Edge is an optimization problem whose solution depends on the goals of the organization and the specifics of the questions being asked of the data, flexible deployment options are important when considering analytic solutions for your company. Falkonry understands this and has emphasized development in our Time Series AI platform to accommodate a range of capabilities supporting cloud and edge. The core of our software is designed to take advantage of cloud computing technologies and is readily deployed into a fully cloud environment. This supports both the high computational and storage loads required for model learning as well as the lower loads of inference in a well-connected environment. We also have Edge Analyzers. These are lightweight, containerized instances of the Falkonry inference engine that can run on smaller footprint compute hardware, such as gateways or IPCs, and that can function entirely disconnected from the cloud. Finally, we have an air gap version of the entire suite which packages the full capabilities of the software into a self-contained “cloud in a box.” In this configuration, functions can be deployed entirely behind firewalls or in environments where internet connectivity is not available. Contact us to learn more about how we can help you find your Edge.

Note: A version of this article first appeared on Toolbox Tech