Introduction

In one of my previous articles I approach the Edge Computing topic: https://luism.co/critical-capabilities-for-edge-computing-in-industrial-iot-scenarios/. There it was explained the key benefits, now I’ll dive in, with some more details.

One of the good reasons to apply Edge Computing is to reduce required data bandwidth and/or data consumption, if the edge systems are connected to the data consumers (normally a cloud based services) over a mobile network. This kind of connections have some constraints compared with a cable connection that might require edge computing. Let’s see the Case Study below.

Case study example: Green house temperature regulation.

Use case: As a farmer I want to keep the temperature inside my green house above 18 ℃ and below 24 ℃ to have an optimal growth of a tomato’s plantation.

Solution Design

Equip the green house with cooling windows and water heating system.

Solution operations:

• Open half of the cooling windows if the temperature is above 20 ℃
• Open all the windows when the temperature is above 23 ℃.
• After the window open it, closed half of the windows when the temperature is below 22 ℃
• Close all windows when below 19 ℃
• Turn on the heating system if the temperature is below 18 ℃.

So far He did all the control manually by reading a simple thermometer, open and close the windows by hand and switching on and off the heating system.

The business is successful, and the farmer decide to expand by renting some additional green houses across the farming region, and soon he has 10 to manage, some in very remote places.

Soon realizes that was not possible to manage as he needs to run from one green house to the other, sometimes to late making some crops having low productivity.

Finally, He decided to automate the control system, with one of the reasons is to expand further.

After some consulting He decides what to do:

Automatic Control: Better is to automate the system with a temperature sensor, some motorized gear for the windows and change the heating system to a water pipe heated by gas controlled by electro-valves for optimal temperature.

This is a reasonable solution, for controlling the system a simple algorithm to read the temperature sensor, actuate the window motors or to switch heating system according to the temperature value can be implemented by some generic microcontroller, like an Arduino Nano, considering that the temperature sensor need on analogue input, 3 digital outputs for relays that control the window motors(one for each half) and the other for the heating system . All real-time, all local.

The farmer as a tremendous success and is ready for the next step and become a businessman in green houses, not only growing tomatoes but also bananas, kiwis and avocados. This goes to a total of 100 green houses to manage.

As the different plantations require different growing temperatures, the Farmer as the next big decision.

The current control system would be obsolete anyhow because it is not configurable (probably made in China, is this article I explain why most of the china products are cheaper on short term but having a short lifecycle) a new one need to be decided:

The New Green House control system

Option 1: Local parameterization

Use a dedicated team to update the parameters on all 100 green houses whenever it is needed. Remember that the plantation on each green house need to change time to time, to not exhaust the soil ingredients, that requires someone to change the settings.

Option 2: Central remote parameterization

In general a remote application is friendly enough that even the farmer can input the temperature parameters and press a button to deploy the information to the assigned green house.

Option 2.1: Central command and control

The temperature data is sent to the cloud services, there the farmer can define the temperate threshold for the different plantations and assign the plantations to Green Houses.

By identifying the location of the data a computational service can remote actuate the windows gear or the heating system valve according to the rules though the same communication channel as it receives the temperature data.

So far so good, but connectivity plays a fundamental role on IoT.

As the green houses are in rural areas, it would be difficult to have a cable connection like ADSL or even less probably optical fiber.

The current best approach to bring those remote sites online is using WCDMA or LTE, best known as 3G, 4G or 5G networks.

In most cases and locations around the Globe the contracts with the Mobile Network Operator (MNO) have some kind of pay per use schema: more data is sent or received more the farmer would get charged.

Data Usage Cost calculation

Let’s assume the following factors:

– Latency: the maximum latency (delay between the green house sends the temperature and the central sends back the command to control the windows and the heating) allow is 2 minutes.

– Data Packet size: each time the temperature is sent to the cloud you use $20KB$ of data

– Data usage Costs: 10 dollars per $100MB$.

Base on the conditions, a system engineer would say that for the use case we need to send the temperature to the cloud is 1 minute (round trip for read and command)…

Ok, fine, lets calculated how much the farmer would need to pay…

Costs per month calculation:

begin{equation} label{eq:Packets}
Packets/hour = 60
end{equation}

begin{equation} label{eq:Data per hour}
Bytes/hour = 60 * 20 kB = 1200 kB/h
end{equation}

begin{equation} label{eq:Data per month}
Bytes/month = 1200 kB/h * 24h * 30 d = frac{864000}{1024} simeq 843 MB
end{equation}

begin{equation} label{eq:Data per month per green house}
Cost = frac{843}{100} = 84.3 $
end{equation}

begin{equation} label{eq:Total cost for 100 green houses}
Cost = frac{843}{100} * 100= 843 $
end{equation}

If the gross profit margins are good it sounds reasonable. But in order to apply cost savings and keeping the resolution.

Edge computing: Filtering

Let’s apply edge computing, keeping the processing (business logic) on the cloud… For that we apply a rule of positive or negative delta threshold.

With delta thresholds the number of data points is reduced by filtering the sensor data avoiding the transmission of small oscillations or even inducted noise.

In our case it is sufficient to send data only if the positive or negative $Delta$ is $1^{circ}C$ .

Without knowing the thermodynamics of a green house but assuming the following:

– In the winter the temperature oscillation is between $-5^{circ}C$ and $8^{circ}C$

– In the summer the oscillation is between $10^{circ}C$ and $30^{circ}C$

– On average, let’s say $16^{circ}C$ of oscillation.

– In the green house the delta would be the same if no temperature control

– By the required temperature, the oscillation should not be more than $Delta T = 10^{circ}C$

– Let’s assume a worst case scenario without control that means that we need to transmit $16 values / Day$.

begin{equation} label{eq:Data per hour}
Total Cost = 16 * frac{20 kB}{1024} * 30 days * 100 Units * frac{10 ($)}{100MB} simeq 93$
end{equation}

This is 9 times less than just throwing the raw temperature to the cloud without any drawback as the relevant temperature data was sent to the remote service.

The same data can be used for monitoring and alerting, for instance if it is summer and the temperature value is $0^{circ}C$ maybe there is some issue with the sensor on the respective greenhouse.

Option 2.2: Business Logic on the Edge devices

If the goal is to save further but the farmer want to keep an eye on all greenhouses without visit them, the business logic must be moved to the edge, that can be achieved by putting some additional “intelligence” on the device that sends the data to the cloud.

Edge Computing usually use embedded computers with specific characteristics as need to be mass-produced with focus on the right balance between cost and performance

In this mode of operation the greenhouse only send notifications when the windows are close or open or when the heating is switch on or off, would also be convenient to send some sign of life a couple of times per day.

Assuming a normal temperature behaviour we should not have more than 4 events:

– In the summer:- Open windows when temperatures raise at sunrise — 2 Events

– Close windows on sundown — 2 Events

– Heartbeat — 2 Events

– Total Events = 6

– Total cost for all greenhouses $=35 $$ that is 2.6 times less than option 2.1.

Apply edge computing lead to cost reduction

Between Option 2.1 and the Option 2.2 one we need to be careful how to decide, there are at least two major factors to consider:

– Is latency an issue? If yes, what is the maximum allowed?

– Thus, the business logic change frequently? I mean does the greenhouse is used for bananas for some weeks, then change to tomatoes and later to something not defined later? — A change would need an update on the edge system that have additional data usage and additional maintenance costs. It is much easier to update a type of farming in the cloud system than to download the new temperature thresholds to the green house device.

Other factors to consider on the decision

Cybersecurity

Allowing command and control requires additional protection of the communication, not to mentioning constant security checks/updates whenever a vulnerability is found. This counts as a “con” to allow “Command & Control”

Reliability

Connected system over a public network have some single points of failure that can cause a greenhouse to be unreachable, for instance:

– Maintenance off the Mobile Network

– Data usage exceed the limit

– Application Server maintenance

– Network routing

Hopefully the offline status remains for a short time, for there are several factors that the IT team hired by the farmer can’t control, in that sense the risk is higher for “remote command and control” that the system remains uncontrollable due to unavailability, like the case with the Colonial Oil pipeline https://www.bbc.com/news/technology-57063636 cause damages more that $5m.

US fuel pipeline ‘paid hackers $5m in ransom’

Conclusion

As summary, using some kind of edge computing would lead to cost reduction in the data consumption by sending only meaning values, I wonder if in this case is there any interest of sending temperature changes of cents of degrees?

Further, moving the business logic to the edge or to the cloud requires detail study by the type of data, what added value can have that source data for further analysis or modelling.

Also bear in mind the pros and cons of being always online versus send chunks of data sporadically that can reduce the data overhead.