Skip to main content

Platform Architecture

The Clea platform consists of core components, which communicate to offer all the advantages of a complete, modular and scalable solution.

The image below shows the interaction between the field devices and the Clea components.

Clea Architecture

Clea Portal​

Clea Portal implements the user-facing part of Clea. It uses the APIs (REST and GraphQL) provided by the other components Astarte and Edgehog to provide visual information about data, appliances (devices) and the whole fleet, while also embedding advanced services.

Clea Portal also allows you to create and manage users and their roles to set the proper permissions to the correct accounts granularly. You can also control the various project organizations, allowing the device vendor to assign appliances to the right organizations, such as distributors or end-users.

One of the main features of the Clea portal is that the user interface is highly customizable, allowing developers to create custom themes and even custom data visualization interfaces called Clea Portal Apps.
Clea Portal Apps interfaces can be developed with JS and HTML5 with the possibility to add custom backends in any language. Moreover, they can be hosted anywhere and loaded dynamically by Clea.
Inside the walkthrough section, you can find all the indications for using the portal.

Edgehog​

Edgehog is an Open Source IoT platform focused on device fleet management. The platform takes care of the entire lifecycle of devices, allowing fundamental operations such as deploying update campaigns, device status and connection information monitor, geolocation, file transfers, and much more.

Edgehog is built upon Astarte, and it exchanges data with it using REST API and Astarte Triggers to communicate with the devices.

Edgehog provides information to the outside world via the GraphQL API and uses PostgreSQL to store its data.

You can find more information regarding the Edgehog project on its documentation pages and in Edgehog's Github page.

Astarte​

Astarte is an Open Source IoT platform focused on Data Management. It takes care of the entire data lifecycle, from data collection from devices to delivering data to end-user applications such as Clea Portal. It uses a set of mechanisms and paradigms to store organized data and make it available via REST-APIs, to enable services such as third-party applications.

It is a native Kubernetes platform and uses standard protocols and open source components (e.g., MQTT, BSON, JSON, RabbitMQ, Grafana). Its trigger engine can also generate push events based on specific conditions that users can define for particular use cases.

You can find more information regarding the Astarte project in its documentation pages and Astarte's Github page.

Tech stack​

The Clea platform uses the following third-party components:

  • Docker: all services of the Clea platform are deployed inside Docker containers.
  • Kubernetes: a container orchestrator on which the Clea platform is deployed. It is possible to deploy the solution on compatible cloud environments such as GKE.
  • RabbitMQ: AMQP broker used for communication between the microservices part of Astarte.
  • Cassandra/ScyllaDB: NoSQL database used by Astarte for storing device status and time series, if any.
  • PostgreSQL: SQL database in which Clea Portal and Edgehog stores management information on devices.
  • VerneMQ: MQTT broker used by default by Astarte for communication with field devices. An Astarte plugin is installed inside.

The following standard protocols, formats, or conventions are also used:

  • TLS: all communications are encrypted, and SSL mutual authentication is used between devices and the cloud.
  • MQTT: for connecting devices with the cloud.
  • AMQP: for internal communication between microservices belonging to Astarte.
  • HTTP, REST: to interact with the Astarte API that allows to send data to the devices or read the device status.
  • HTTP, GraphQL: to interact with Edgehog API that allows using advanced device and fleet management functionalities.
  • JWT: access to the API is controlled using signed JWT tokens.
  • JSON: the API returns data formatted in JSON.
  • BSON: used internally in MQTT payloads to devices to provide structured data similar to JSON but saving bandwidth.