# A Set of Tools and Data Management Framework for the IoT-Edge-Cloud Continuum
## 3 Data Management Framework
### Plugin Manager  
To provide extendable software support to the user, a plugin system is used, where different plugins can co-exist and provide distinct functionalities where needed. Each plugin has a separate configuration, and it can be customized differently for each separate deployment within the system. The users can also add their own plugins for data processing or any other needs. Each plugin has a dedicated subfolder within the plugin's directory, containing config.yml for configuration settings and plugin.py for the plugin's operational code, ensuring that each plugin is self-contained and easily manageable. Execution and Command Scripts are used to initialize and manage the lifecycle of the containers, ensuring that each component starts in the correct order and operates as expected. These are some ideas for useful plugins, but developers can easily add new plugins to the system by following the provided example code and tutorial. The energy status plugin shows the current energy consumption used during message transmission from devices within the network and the estimated lifetime of battery-powered devices. This estimate is based on the current settings and parameters of the system as well as monitored data streams for the specific device. The plugin uses configuration parameters, which the user can edit based on the specifics of the system, such as battery capacity, which diminishes over time, transmission power, data rate, battery voltage, etc. The traceability plugin allows one to monitor the data flows at certain data nodes. The developer can specify the topics and payload that they want to monitor in the configuration. The messages that match the selected topic or payload will be logged. The logs can be analyzed later with the tool of the user's choice. The traceability filter is configured in the configuration file, the section \"filter\" has three possible subsections: \"topics\", \"clients\", and \"payloads\". In these sections, one can define the lists \"include\" and \"exclude\". The patterns in these lists will be included or excluded from the matching topics, clients, or payloads, respectively. The differential privacy plugin enables the concealment of the private information of the initial dataset owners while providing general information about the data. However, this comes at the cost of reduced data usefulness. Therefore, users must choose the best option for their needs. The differential privacy plugin enables users to obfuscate local data while still providing value for further data processing, whether for machine learning model training or analysis. Users can choose between many privacy and utility settings in order to find the most suitable option for them. Additionally, the plugin validates user-configured parameters such as privacy level, mechanism type, data size, and sensitivity against \((\varepsilon,\delta)\)-differential privacy standards. This validation step reduces the risk of misconfigured or ineffective privacy mechanisms, ensuring reliable implementation and adherence to privacy-preserving practices. Differential privacy is currently one of the most widely used methods for ensuring data privacy or rather the anonymity of the initial dataset owners, overcoming alternatives such as anonymity methods, for example, k-anonymity and its successors [21, 22]. The main focus of DP is adding noise to the initial dataset taken from a chosen probability density function, e.g., Gaussian or Laplacian. DP has two main definitions: The first one is \((\varepsilon)\)-DP, proposed by [PERSON] in 2006 [23]; however, in later years, a new definition was proposed for ML use cases in order to increase the utility of the private data by adding a relaxation parameter \(\delta\). This plugin focuses on the latter definition of DP, \((\varepsilon,\delta)\)-DP, because it allows one to apply DP with a smaller utility degradation [22, 24].