Why might data be sent to a cloud service when it could be processed on the edge?

Question

I was recently reading Amazon's information about the AWS IoT Platform, and came across an interesting example use case:

Although they don't describe how exactly the road condition data is sensed, if the sensor can detect a wet road, why would Amazon suggest sending the data to the cloud? Wouldn't it be simpler just to directly process the sensor data on the vehicle and alert the driver, rather than sensing, sending data to the cloud, waiting for it to be processed, receiving data and then alerting the driver? I can't really see much of an advantage other than the possible analytics data you would gain.

Is Amazon's example use case only beneficial when you want to gain analytics data, or are there other reasons that they would suggest to use the cloud?

---

^{I suspect one of the reasons is simply to make people use the service they're trying to sell, but I'm interested in technical reasons, if there are any.}

Answer 1

There are many factors in choosing whether to process data on-device or in the cloud.

Benefits of processing in the cloud

1. If the algorithm uses floating-point or runs on a GPU, it might not be possible to run on the embedded processor in the sensor.

2. Even if it doesn't, if the algorithm was developed in a high-level language, it might be too expensive (in developer time) to port it to run on the sensor.

3. Offloading computation from the sensor may increase its battery life (depending on how this affects network/radio use).

4. Running the algorithm in the cloud allows it to combine the data from many sensors and make a system-level decision. In this example, that might mean filtering across different cars' sensors, so that washing one car doesn't cause a rain warning in every car.

5. Processing in the cloud allows to distribute the information to many places without having to have a mesh network, which is a complicated architecture.

6. You can log more data, which enables better analytics, audit, and development of better algorithms.

Benefits of processing on-board

1. If the raw sensor data is high-bandwidth, it might use less battery to summarise the data and send the summary (depending on what processing is needed to summarise it). This might mean that instead of sending an 8-bit moisture reading 100 times a second, you filter it and send a 1-bit wet/dry flag every 10 seconds.

2. You might go further, and only wake up the network at all when the sensor has something interesting-looking to report (e.g. the wet/dry state changes)

3. Reducing the network bandwidth at the sensor end also reduces it at the server end, so you can scale the service to more users (more sensors) very cheaply.

4. It might be possible to run the service with the same or reduced functionality even when the network is unavailable. In this example, your car might be able to warn you about slippery roads it sees itself, but not give you advance warning from other cars.

Overall

Usually, some combination of the two is optimal. You might do as much processing as you can afford to do on the device, to reduce the need for the network as much as you can, and then run more sophisticated algorithms in the cloud that can combine more inputs or use more compute power.

You might start out running all of your processing in the cloud (because it was prototyped in Matlab or Python) and port parts gradually to Rust to enable offline functionality, when you have developer time to spend on it.

You might process the data heavily on the device in normal use but also sample and log the raw data sometimes, so that you can upload it to the cloud later (when network is more available) for your analytics.

Answer 2

What may not be obvious from the graphic is that the proposed value-add seems to be passing information from one set of vehicles to another. The sensor information from cars at one location can be processed (noise rejection, pattern recognition) and passed to other vehicles which are predicted to encounter these conditions in the near future.

Maybe you could pass the information peer-to-peer in busy areas, but you loose the ability to be able to extract confidence data from the sensor prediction, and to easily combine multiple data sources

As to the value of the sensor data, I think it's self-driving vehicles that will benefit most, by being able to adjust their safety margins and stopping distances in advance of (for example) a bend which had more residual water some time after a rain shower has passed.

It seems feasible that a model could be trained on car-sourced sensor data, then run in a predictive manner based on a real-time weather feed.