## 6 Building and Provisioning an Industrial Digital Twin
In this illustration, reused components are denoted in a deep blue color, while components that the developer crafted from scratch are shown in a light blue hue. The solid lines indicate the exchange of data between pairs of components, while the dashed line represents the migration path of the ML model. Some components are deployed on an Edge node within the factory premises, while others are provisioned in the Cloud. The data backbone supporting the application's logic comprises several key components:  
* Message Broker (RabbitMQ): This component serves as a central hub for data exchange. It collects data generated in the field by various sources and ensures its delivery to the intended recipients. * Data Stores:
* InfluxDB (Time-series Database): This database is responsible for storing time-series data, which can be crucial for analyzing trends and patterns;
* MinIO (Object Storage Database): MinIO serves as an object storage database, housing data objects and making them accessible for various purposes. * RabbitMQ-to-InfluxDB Connector: this connector facilitates the transfer of data from the message broker to the InfluxDB, enabling data to be stored for further analysis;
* InfluxDB-to-MinIO Connector: this connector assists in moving data from InfluxDB to MinIO, possibly for archival or other use cases. ```
**Listing 1**. : Exert of a TOSCA blueprint for the provisioning and wiring of a RabbitMQ docker instance and a Telegraf connector instance. ``` topology_template: inputs: #paramsforRabbitMQ,TelegrafandInfluxDB #....omittedcode......# node_templates: rabbitmqnode: type: tosca.nodes.indigo.Container.Application. Docker.Marathon #....omittedcode......# artifacts: image: file: rabbitmq:management type: tosca.artifacts.Deployment.Image. Container.Docker requirements: - host:rabbitmqdockerruntime: rabbitmqdockerruntime: type: tosca.nodes.indigo.Container. Runtime.Docker #....omittedcode......# telegrafnode: type: tosca.nodes.indigo.Container. Application.Docker.Marathon properties: environment_variables: RABBITMQ_ENDPOINT: type: string value: {concat: [ \"mqtt://\", {get_attribute : {rabbitmqnode,  load_balancer_ips, 0 ] }, ':', {get_attribute : {rabbitmqdockerruntime,  host, publish_ports, 1, target}}]} #....omittedcode......# artifacts: image: file: iotwins-harbor.cloud.cnaf.infn.it/ data-services/ iotwins-connector-rabbitmq-influxdb:1.0 type: tosca.artifacts.Deployment. Image.Container.Docker requirements: - host: telegrafdockerruntime: type: tosca.nodes.indigo.Container. Runtime.Docker #....omittedcode......#The data generated in the field is first collected by the message broker and then routed to its intended destinations through these components. On the Cloud side, the ML model component, depicted as the \"Anomaly Detection (AD) Model\", retrieves data from the MinIO object storage. This data is essential for the training process of the ML model, which is a critical part of anomaly detection. On the Edge end, the trained AD model component subscribes to the message broker in order to receive fresh data generated by the sources. Based on those data, it will have to detect potential anomalies and notify with the Alarm component. Finally, the Data Polisher filter and cleans in-transit data before they get to the Cloud.