## 2 The IDIVS Concept and Application Domains
### Deployment  
The IDIVS concept should neither enforce deployment on a specific platform nor enforce deployment solely on a single platform. The idea is that a simple protocol, such as MQTT, can be used in the deployment. However, to be used across many applications,the deployment should allow for the configuration of which IDIVSs have access to information from which sensors and IDIVSs. Moreover, each IDIVS should have a mechanism, commonly implemented in the form of access control, for ensuring the confidentiality and integrity of internally used data and its input data. This is to ensure the possibility of hiding potentially sensitive, e.g., commercially or privacy-sensitive information, from limited parts of the systems and from services using IDIVS output. The IDIVS can be implemented using push or pull mechanisms. To support dynamic identification of relevant sensor data, we suggest using MQTT topics as a way to communicate relevant sensor properties, including categorizing them by, e.g., physical location being sensed and property type. Each individual IDIVS can then filter out relevant properties by parsing the messages (see Figure 2). In addition, to foster dynamic sensor selection at runtime, a meta-data repository containing the IDIVS information specified in Figure 2 needs to be maintained and updated accordingly. This is also necessary for evaluating the feasibility of directly reusing previously existing IDIVS for new use-cases or for adapting IDIVS to be better suited for deployment to a new physical environment, using techniques such as transfer learning. Providing feature stores and data versioning for the used training datasets is important to ensure continuous integration and delivery.  
The current IDIVS reference implementation is implemented as a set of Python scripts, deployed to a cloud computing environment as serverless functions (see Figure 3). In the reference implementation, functions are triggered periodically in order to update their current states, similar to how a sampling sensor would work. An application or a user can also trigger said functions manually to provoke a more recent response. Sensor data is fed to the IDIVS by being buffered in a database before being analysed by the IDIVS. However, the IDIVS architecture allows for direct input of sensor data as well as periodic polling from a database. Sensor data is transported using MQTT, which can be tunnelled over HTTPS. The IDIVS functions poll the stored sensor data using HTTPS. User feedback data is treated as any other data and is stored in the database, and analysed by the IDIVS, e.g., for improving its data fusion model by learning. The MQTT protocol allows a set-up with both a proactive learner (Machine Teacher) and a learner responding to system requests (Active Learning). Resilience and sensor discoverability are achieved by treating missing data as empty datasets, which are disregarded in calculations.  
Thanks to its low overhead, an IDIVS function can also be deployed on, e.g., a gateway or even on a sensor array with an adequate amount of memory and processing power. This allows for a more distributed deployment model, which may fit better in some application  
Figure 3: An example of a cloud-based IDIVS deployment.  
areas. An IDIVS-deployed leaf side can be coupled with announcement functionality to promote dynamic service discoverability within the local environment.