Early IoT applications, especially those addressing the consumer market, have been embracing cloud-centric architectures in which data is pushed up to the cloud. It is within the cloud the everything takes place before eventually pushing some data or action back to the edge. This architectural approach leverages the availability and operational maturity of the cloud but it is not generally applicable in IoT / Cyber Physical Systems (CPS).
Figure1– Cloud centric architecture.
The cloud-centric paradigm quickly shows its limitations in the context of Industrial IoT (IIoT) and in general with Cyber Physical Systems (CPS). More specifically, the following assumptions, at the foundation of cloud-centric architectures, are generally violated in IIoT applications:
- Connectivity. Cloud-centric architectures assume that things are sufficiently often connected. While this is mostly true for IoT applications, it is far from being the common case in IIoT applications. As an example, autonomous agricultural vehicles, or robots in a smart farm are often deployed in locations with very poor connectivity.
- Latency. Cloud-centric architectures assume applications can tolerate the latency associated with pushing data from things to the cloud, processing information on the cloud and eventually sending back some control information. This latency, is orders of magnitude higher of the reaction times required by several IIoT applications, such as, autonomous vehicles, smart factories and smart grids.
- Throughput. Cloud-centric architectures assume that the throughput required to push data from things to the cloud may be massive when looking at the aggregate traffic, but it is generally composed by limited individual flows. In IIoT the situation is quite different as, often, there are data flows with high individual throughput and in several applications the aggregate volume is incredibly high. This makes it unfeasible or not very effective to stream these massive volumes of data to a data centre.
- Cost of Connectivity. Consumer IoT (CIoT) commonly assumes that the cost of connectivity is negligible. This stems from the fact that consumer pays for connectivity – either via their mobile data plan or their home internet connection. In IIoT the situation is completely different, it is the owner of the system that pays for connectivity. This cost is non-negligible in applications with large number of data streams, such as Smart Grids as well as for applications deployed in remote areas such as oil exploitation rigs that can only rely on expensive satellite communication where 1MByte of data can cost as much as $8!
- Security. Cloud-centric architectures operate under the assumption that end-users are comfortable in giving away their data. While this may be true for CIoT applications, the situation is completely different in IIoT. Information is a strategic asset which the vast majority of companies, operating in an industrial, do not want to leave their premises.
Fog computing has emerged as an architectural approach to deal with the limitations exposed by cloud-centric architectures in the context of CPS and IIoT applications. fog05 is an infrastructure designed from first principle to address the needs of fog computing.
Eclipse fog05 provides a virtualised infrastructure that allows to distribute computing, storage, control and networking functions closer to the users along a cloud-to-thing continuum. From this description it should be clear that fog05 can leverage cloud infrastructure or equally function without it.
Figure2– fog05 end-to-end resource virtualisation.
fog05 makes available a set of abstractions to unify the compute, storage and communication fabric end-to-end, thus allowing applications to be managed, monitored and orchestrated across the cloud to thing continuum.
In other terms, fog05 provides the same abstraction of an elastic compute, storage and communication fabric but in a decentralised fashion. The main advantages of this architectural approach, when compared with cloud computing, is the ability to keep the data and the processing close to where it makes the most sense, which in many cases is close to where the data is produced.
Finally, it is worth mentioning that the "5" in fog05 beside representing the letter "S" in hackers jargon, it refers to 5G and specifically to Multi-access Edge Computing. fog05 addresses the needs of MEC and is compatible with ETSI MEC manifests.
The content of this open source project is received and distributed under the license(s) listed above. Some source code and binaries may be distributed under different terms. Specific license information is provided in file headers and in NOTICE files distributed with the project's binaries.
From February 19th, 2020 to June 30th, 2020
| Name | Date | Review |
|---|---|---|
| 0.2.0 | 2020-06-30 | |
| 0.1.0 (Prelude) | 2020-02-19 |