Remember, you are always processing data at the edge, even if it's not obvious. The choice to sample data at a particular frequency, whether that is 1Hz or 100Khz (particularly with analogue data), is a form of edge processing. Very few scenarios will transmit data at the maximum clock cycle of the processor.
Some scenarios where explicit edge processing is useful
- Bandwidth constraints. The often-quoted example is in the oil and gas industry where a lot of telemetry is gathered, and the bandwidth from the remote location is limited.
- Low latency requirement. Especially in control systems where something needs to happen in response to data. When sub-second responses mean the difference between normal operation and failure, a second or two round-trip to the cloud is unacceptable.
- Extremely low value of data. If nothing is likely to be gained from recording data, even in the future with sophisticated analytics, you might as well summarise and drop it at the edge. For example, mains power in the EU is expressed as 'nominally 230 V ±10% at 50Hz'. Given that you can handle that range, there is no point in transmitting the precise voltage every 100ms. If is better to transmit 'from this time to this time, the voltage was nominal'.
- Ordering of events is important. Devices have a narrower scope and can perform some derivations easier than the cloud. One of these is where the derivation requires that the data is in order. For example, it is easy on a device when measuring, say voltage, when it enters the on or off state. Timestamping the voltage measurement and sending it to the cloud makes the derivation harder as data may come out of order, delayed or be completely lost.
- As a failure mode. Connectivity to the cloud, or at least some of the processing, is likely to fail. All systems should be able to perform some edge-processing, even if it is dumbed-down, as a failure mode.
- Non-IP mesh The cloud will only be accessible via a gateway for non-IP devices, such as those that communicate over a low-power network or CAN bus-type wired connection. It may be preferable for devices communicate directly with each other in a 'mesh', in which case IP connectivity isn't needed, never mind cloud connectivity. Mesh is the holy grail of edge computing, but difficult to do.
- Privacy, trust, and regulatory issues Data can be collected that may be useful and valuable for analytics, but getting customer consent to collection and storage of the data may be difficult, and the cost and risk associated with managing access to the data may be too high. Facial recognition, and most image processing, is the obvious example. Another example is that all modern vehicles have GPS and connectivity built-in for emergency call response. Vehicle manufacturers and dealers could derive valuable insights from a stream of GPS data, but location data is personally identifiable in this scenario and shouldn't be collected, transmitted, processed and stored.
- Security We are aware that IoT is currently suffering from security issues. While it is possible to create a secure environment with cloud-connected devices, security is a major issue that needs to be actively worked on. Highly secure gateways, edge-based threat detection and other as-yet unknown defense mechanisms are going to be necessary in most environments.
When considering material about edge processing, remember to consider the source. Existing IT vendors that haven't cracked the cloud market (IBM, HP, Cisco) are worried that IoT, as the next big thing, bypasses them altogether. As a result they will aggressively market edge processing. Indeed, 'fog computing' is a term created by Cisco to have a 'cloud' closer to the ground (or something). Obviously cloud vendors are marketing the reverse, for their own bottom line.