Relativistic Digital Twin: Bringing the IoT to the Future

Complex IoT ecosystems often require the usage of Digital Twins (DTs) of their physical assets in order to perform predictive analytics and simulate what-if scenarios. DTs are able to replicate IoT devices and adapt over time to their behavioral changes. However, DTs in IoT are typically tailored to a specific use case, without the possibility to seamlessly adapt to different scenarios. Further, the fragmentation of IoT poses additional challenges on how to deploy DTs in heterogeneous scenarios characterized by the usage of multiple data formats and IoT network protocols. In this paper, we propose the Relativistic Digital Twin (RDT) framework, through which we automatically generate general-purpose DTs of IoT entities and tune their behavioral models over time by constantly observing their real counterparts. The framework relies on the object representation via the Web of Things (WoT), to offer a standardized interface to each of the IoT devices as well as to their DTs. To this purpose, we extended the W3C WoT standard in order to encompass the concept of behavioral model and define it in the Thing Description (TD) through a new vocabulary. Finally, we evaluated the RDT framework over two disjoint use cases to assess its correctness and learning performance, i.e., the DT of a simulated smart home scenario with the capability of forecasting the indoor temperature, and the DT of a real-world drone with the capability of forecasting its trajectory in an outdoor scenario. Experiments show that the generated DT can estimate the behavior of its real counterpart after an observation stage, regardless of the considered scenario.


I. INTRODUCTION
T HE near future of the Internet of Things (IoT) paradigm is intertwined with the novel concept of Digital Twins (DTs). DTs are digital replicas of physical assets that evolve over time in order to mimic their behavior, their reaction to events and their internal structure as closely as possible through computational models [1]. In the past years, this role was taken up by other entities, such as simulators, emulators, digital shadows, mirror systems or avatars. DTs are different from them in that (i) they constantly receive inputs from the mirrored appliance(s) to adapt to its behavioral changes, as well as (ii) they feed back their outputs into the real environment to provide guidance [2]. The capability of DTs of reproducing real devices and entities makes them extremely important for a variety of IoT scenarios that take advantage of predictive and what-if analytics. In fact, DTs find their natural applicability in manufacturing and Industry 4.0 scenarios, where putting the physical asset at risk results in a massive loss in terms of resources [3]. Because of their crucial role, DTs are, most of the times, tailored to the appliance that they reproduce. This is obviously a safe choice, however it results in additional engineering cost and effort when it is necessary to adapt the computational model to a new use case or a new asset [4]. As a matter of fact, nowadays there is a profound lack of general purpose solutions that can offer adaptable DTs or automatically generate computational models able to synthesize heterogeneous scenarios. It is clear that a zeroknowledge solution is nearly impossible to obtain, but we can envision an automatic process that is able to fit a variety of scenarios given very little initial information. Moreover, the age-old problem of IoT fragmentation still persists in most of the IoT ecosystems and exacerbates the difficulties of introducing such an automation for DTs, as devices may use different technologies and protocols to expose their data and services in a highly dynamic environment [5]. To overcome this issue, several solutions have been proposed over the last decade; one of the most supported is the Web of Things (WoT), recently standardized by the World Wide Web Consortium (W3C) [6]. The WoT abstracts each IoT device into a Web Thing (WT), a digital entity that exposes its functionalities (defined as affordances in the official documentation [6]) via standardized Web technologies and semantics that vaguely resemble the REST concepts. WTs are described via a Thing Description (TD), a machine-readable JSON-LD document that can be shared with other WTs in order to automate interactions in a WoT ecosystem. A number of Industrial IoT frameworks are now dedicated to embrace the concept of DTs, at the same time leveraging an integration with the WoT. An example is Eclipse Ditto [7] or Eclipse Arrowhead [8], which presents a one-to-one bi-directional translation between service records and WTs [9]. These solutions exploit the WoT for abstracting heterogeneous DTs of physical assets and integrating them within a single application ecosystem, however, they do not take into account a homogenized representation of their behavioral models, leaving this aspect to the third parties.
In this paper we propose a solution to the two abovementioned shortcomings of the current landscape of DTs in IoT: either (i) DTs are too specialized for the use case they operate upon, or (ii) interoperability-oriented IoT frameworks do not have the necessary expressiveness to encompass their arXiv:2301.07390v1 [cs.NI] 18 Jan 2023 model description. Specifically, we propose a framework that is based on the WoT, where all entities are abstracted into WTs and all interactions between entities are encoded as affordances. However, as an extension to the W3C WoT standard and as the main contribution of our work, each of the TDs is enriched with a parametric behavioral model that characterizes the dynamic of the target IoT appliance over time. Based on it, our framework is able to generate a DT for each of the represented WTs that presents the exact same affordances; in addition, by periodically monitoring the behavior of the real appliance, the framework fits the model parameters to mimic the physical asset over time. Eventually, the generated DTs will be indistinguishable from the real assets, as they both expose the exact same interface to other actors in the WoT ecosystem. A fully operational scenario aims to advocate a paradigm shift, where virtual entities can be queried -and acted upon -with a predictive connotation, by running them at future instants in time, as the DTs will be able to foretell the behavior of the asset. This vision is inspired by the "Twin Paradox" [10] in which one of the twins is sent forward in time and is eventually older than the other twin; in the same way here, the DT can interact with the other elements in the system without having to stick to the current moment. Despite the shared birth between the DT and its physical counterpart, and because of the independent timeline of virtual entities, we name our framework the Relativistic Digital Twin (RDT) framework.
More precisely, this paper makes the following three contributions: • We propose an extension to the WoT TD syntax, in order to introduce the concept of behavioral model as well as its interactions; because certain entities in an ecosystem may influence each other, we also take into account that certain behavioral models may be dependent on the properties of other WTs in the same environment. • We propose the RDT framework, which is able to generate DTs of each WT that includes a behavioral model in the ecosystem, by learning over time the model parameters through constant observation of the WT properties. At the end of the learning phase, the RDT framework is able to generate the Digital Twin Web Thing (DTWT), i.e., new WTs which are functionally equivalent to the real-world ones but are attached to the behavioral model rather than to the IoT physical asset. • We evaluate our proposal over two conceptually different use cases: a DT of a simulated scenario including the representation of a room with adjustable temperature and multiple sensors/actuators, and a DT of a real quadcopter drone able to reproduce its kinematic.
The rest of the paper is organized as follows: Section II reviews the state-of-the-art concerning DT frameworks and the WoT, Section III introduces the system model used in this work along with the scenario description and assumptions declaration, Section IV outlines in detail how we extend the TD syntax to include behavioral models and their interactions, Section V illustrates the framework architecture and how we implemented all the components, Section VI describes the learning module and how each behavioral model is fitted to the real observations, Section VII introduces the two use cases on which we tested the framework and their results, and, finally, Section VIII concludes the paper, outlining future works.

A. Digital Twin and Learning
Adapting to behavioral changes is a prerogative of DTs, however, in a variety of scenarios, this is subject to multiobjective optimization problems that are mathematically intractable and for which only learning-based approaches and heuristics are viable solutions [11]. In some of these cases the behavior of a physical asset is discrete and can be modeled as a state machine. When this happens, most solutions in the literature opt for Reinforcement Learning (RL) techniques applied over Markov Decision Processes (MDP), so that global KPIs can be autonomously reached by tuning model parameters over time. Examples can be found in [12] and [13], however these works are solely designed for a single use case and cannot generalize. On the other hand though, we note that the need for a generalized technique for generating DTs is extremely concrete and seen as a fundamental building block of the path ahead in this field [14]. In a first proposal in such a direction, we modeled the state space of discrete DTs as MDPs and provided a generic "generator" of DTs via the WoT paradigm [15]. We used a combination of frequencybased past observation and deep neural networks to model the physical asset's behavior even in presence of unseen states. Similarly, the work in [16] is a recent proposal that aims to move from one-off implementation of DTs to a generative paradigm, where formal models represent mathematically the physical object and learn its behavior according to its state space and what is being observed in the real world by its sensors. In detail, they propose a general framework based on a graphical model that estimates the state variables probabilistically according to partially observable Markov Chains. They use then the UAV context to evaluate the framework in the real world. This work however focuses on the mathematical models and gives little space to data representation, which is instead a core part of the present work. In the same vein, we can find other proposals such as the work in [17], based on Probabilistic Digital Twins (PDTs) that are built through Bayesian probabilistic frameworks. In this case, the key concept is that DTs must rely not only on observations coming from sensing experience, but also on assumptions, as in fact it is never possible to observe every single property that affects the physical asset, therefore, some of the observations must be replaced by mathematical models in order to capture uncertainties and to provide a minimum starting knowledge to the framework. In that work, such uncertainties are modeled as epistemic and aleatory within the proposed framework, which uses deep reinforcement learning for making predictions. Similarly, in this work DTs are modeled through both assumptions (which define the base models for properties) and observations (which contribute to parameter tuning). However, we detach from state-based discrete properties, rather we take into account continuous properties that can be synthesized via regressive models. This applied to generalized DTs has not been tackled yet in literature, furthermore, we provide an accurate vocabulary for DTs representation via the WoT, introduced in the following section.

B. Web of Things
The world of IoT is known to be affected by technology and standard fragmentation, due to the rise of newer and newer technologies, to which current standards often cannot keep up the pace. This causes interoperability problems that need to be tackled at design time, at the same time tolerating the coexistence of heterogeneous systems. The WoT is a paradigm that proposes to extend IoT entities by using standard Web technologies [18], which are solid and coherent throughout history. In this paper we will make use of the W3C WoT standard [19], however we will only use the term WoT to indicate it. In detail, the WoT standard abstracts a physical asset into a virtual counterpart called Web Thing (WT), which acts as a proxy between the Web world and the physical one. A WT exposes the capabilities and properties of the physical asset just like a Web Server, by providing a set of endpoints that can be queried, furthermore it can perform actions actively against other WTs. For this reason, the software component embedding the WT is called "servient". The metadata describing all the interactions that a WT can handle is stored within a Thing Description (TD), a JSON-LD document that acts as the manifest of the WT by expressing its affordances. These are: • Properties, which correspond to state variables that can be fetched and changed at runtime. • Actions, which denote function calls to be performed by the WT, typically triggering a defined behavior. • Events, which are asynchronous and cause the WT to react to their occurrence. By nature, the WoT paradigm provides an environment that fits very well the implementation of DTs, which can easily be embedded into existing servients. However, besides our past work that we mentioned [15], these concepts have rarely been paired in literature. An example is [20], where a "Digital Twin WT" is envisioned as a virtual entity derived from the aggregation of multiple physical ones. Differently, in [21], the WoT is seen as the scaffolding to better grasp the intertwining of single components within structurally complex Systemsof-Systems, whilst in [22] DTs are WTs that are automatically generated and managed within a container middleware, however authors do not specify whether the behavior is also reproduced, as the focus is semantic interactions. DT is an extremely novel concept and very few research efforts have been directed toward automatic generation of DTs in an IoT generic context. Out of them, none implies or proposes a standard like the WoT to describe how to interact with them.

III. SYSTEM MODEL
We consider a generic IoT scenario depicted in Figure 1 and composed of N ≥ 1 devices, D = {d 1 , . . . , d N }, with sensing and/or actuation capabilities. Each IoT device d i is associated to a list S i = {s i,1 , s i,2 , . . . } of time-dependent variables determining its state over time. Let s i,j (t) be the value of variable s i,j of device d i at time t, where the time t ∈ Γ ⊂ R, t ≥ 0, is continuous. More specifically, we assume that for each device d i , S i = R i W i , where: variables. An instance can be the variable storing the measurement produced by a sensor unit, e.g., the temperature value.
variables. An instance can be a tunable variable triggering an action: e.g., in the case of a led actuator d 1 having a single variable w 1,1 that defines the led luminescence, setting w 1,1 (t) equal to {True | False} corresponds to the action at time t of turning on or off the light, respectively. Another instance can be represented by a configuration parameter of the device, e.g., the sampling frequency of a sensor unit.
We assume that the IoT devices in our environment can have causal relationships with each other, i.e., the change of a writable variable for one device may affect the values of the variables of other devices. Given such premises, the overall goal of our study is how to support the automatic deployment of a DT of the whole IoT scenario, considered as a single entity. To this purpose, let R = i R i be the set of the readonly system variables, W = i W i be the set of the writable system variables, and S = R W . Moreover, let R(t), W (t), and S(t) be the value at time t for all the state variables in R, W , and S, respectively. We call Z = {z 1 , z 2 , . . . }, with Z ⊆ R, the set of output system variables that the DT is in charge of prediction. It is clear to say that it is not possible to predict the behavior of any IoT system without taking into account domain-specific information, since -for instance -the DT of a smart home may use different ML techniques than the DT of an industrial appliance. For this reason, in this paper we rely on model-based ML: each readable variable r j ∈ R is associated with a function that describes its behavior. We consider two types of functions in this study. By relating some unknowns and their rate of change, differential equations offer a powerful modeling tool to describe the evolution of physical quantities over time. Vice versa, algebraic expressions allow to model the instantaneous value of specific quantities. We highlight that the choice of using model-based ML techniques rather than other popular model-free approaches such as artificial neural networks is quite realistic since in several practical use cases (including the ones evaluated in Section VII, and also industrial environments such as [23]) the system behavior can be described with wellknown models derived from the physics and the engineering, although such models must be properly calibrated based on the specificity of each scenario. We split the set of readable variables R into two disjoint sets A = {a 1 , a 2 , . . . } and B = {b 1 , b 2 , . . . }, i.e., R = A ∪ B, A ∩ B = ∅, where A contains the variables r j ∈ R that are modeled by an algebraic function and B contains the variables modeled by a differential equation. In case the value of the variable a j ∈ A at time t can be modeled by an algebraic expression g j , then the latter is defined as follows: where B(t) defines the value at time t for all the state variables in B. Here, t is the time, B(t) and W (t) are the set of variables that a j could depend on, P j is the set of coefficients. We define G = {g j |a j ∈ A} as the set of the algebraic functions. On the other side, in case the value of variable r j depends on its evolution over time, a differential equation is defined as follows:ḃ where A(t) defines the value at time t for all the state variables in A. Similar to the previous case, t is the time, A(t), B(t), and W (t) are the set of variables that b j could depend on, and P j is the set of coefficients. Let F = {f j |b j ∈ B} be the set of all the differential equations. Both the algebraic and the differential equations defined for the variables r j depend on a set of model parameters P j . We assume that |P j P j | ≥ 0, ∀r j , r j ∈ R, i.e., some model parameters can be shared among different state variables. We indicate with P share = rj ,r j ∈R (P j P j ) the shared set of parameters.
The goal of the DT is to predict the system behavior by forecasting the values of the Z variables at time t > t, where t is the actual time. To do that, for each output variable in Z, the functions F and G are assumed to be known in the predeployment phase, except for the exact values of the model parameters P . The RDT framework allows to tune the value of the parameters P = rj ∈R P j in order to properly estimate the values of the Z variables, through the methods defined in Section VI. In the following, we indicate with F 0 and G 0 the behavioral models where the parameters are initialized with the values defined by P 0 , and withF andĜ the trained behavioral models, i.e., the functionsF andĜ in which all the parameters have been properly instantiated with the valueŝ P computed during the training phase.
Given these premises, the key contributions of our work consist in how to: (i) allow the user to describe the characteristics of the IoT systems, such as the variables in R and W , the IoT protocols to access them, and the model behavior G and F , in a domain-independent way; (ii) based on such inputs, fully automatize the data acquisition process from the IoT system in order to learn the values of the model parameters P that best fit the observed data, and hence produce the trained behavioral model (F andĜ); (iii) at the end of the learning phase, automatize the spawning of the DT which will consist in a software module enabling the user to interact with the virtual counterpart like with the original system. Regarding the first contribution, our approach is to extend the WoT standard reviewed in the previous Section, and specifically the TD, with a new vocabulary that allows to model the DT of a generic IoT system and more specifically the functions F and G previously introduced. As shown in Figure 1, the IoT system -considered as a single entity-is mapped to one WT, exposing as properties the list of readonly and writable variables (S). To this purpose, we map the read-only variables R of the IoT devices to readable WoT Properties (rProp), and the writable variables W to writable WoT Properties (wProp) 1 . We remark that the WoT is not a pre-requisite of our solution and that any IoT scenario which is not native WoT-based can be properly extended with WoT interfaces. However, the choice of the WoT is motivated by the possibility to describe -in a uniform and domain-agnostic way -the input/output and the behaviour of the DT, thanks to our TD extension described in Section IV. The WT is then passed as input to the RDT framework, which is in charge of the next two contributions presented in Sections V and VI, i.e., the generation of the trained behavioral model and then the spawning of the Digital Twin-enabled Web Thing (DTWT). The latter has the same TD as the original WT, hence external services can interact with the DTWT in the same way of the original WT, by accessing the same list of affordances. However, any property change action generates a consequence only on the virtual environment without affecting the original system, hence enabling the what-if analysis. In addition, the user can modify a time property allowing to monitor the future behavior of the system, hence justifying the parallelism with the relativistic concept.

IV. W3C TD EXTENSION
In order to give concreteness to all the concepts illustrated hereafter, we consider a possible IoT/WoT use case to which the overall methodology of Figure 1 can be applied. This scenario is depicted in Figure 2 and will be evaluated in Section VII. The IoT system in exam is a closed smart home environment composed of two rooms, R A and R B . The full system is mapped to a single WT, exposing as properties the variables of the sensors/actuators. More specifically, each room is hosting a temperature sensor, T A and T B , respectively. Each of the temperature sensors has a rProp that outputs their sensor value. Both rooms host a heater (H A and H B in the figure) while the first room also hosts a cooler (C). Both heaters and the cooler have a single wProp that represents their power, which can be set manually to a value from 0 to 9 for the cooler, and on-off for the heaters. Temperature values of both rooms are clearly affected by a number of factors: the power of the heaters, the power of the cooler, the temperature of the other room and, finally, the temperature of the external environment. In the scenario described so far, C} are both readable and writable. The goal of the DTWT of such a complex system is to model the way in which these components affect each other, in order to output temperature values that resemble the real ones (i.e., In this Section, we discuss how to create the WoT TD of the environment, including its read-only and writable variables and the description of its behavioral model. Regarding the structure of an ordinary rProp in the legacy W3C WoT standard, it includes the terms of the Thing Description (TD) Ontology 2 : type, description, observable, readOnly, writeOnly and uriVariables. We present below a brief recall: • type is a JSON-LD keyword to label the object with semantic tags about its type (e.g., "number"). • description is a human-readable piece of text that describes what the property is all about. • observable is a boolean value that indicates whether the property is observable and thus if the servient hosting the WT needs to support the relative protocol binding. • readOnly is a boolean value that indicates whether the property can only be read and not modified by a consumer. • writeOnly is a boolean value that indicates whether the property can only be modified by a consumer and cannot be read. • uriVariables is a data schema that indicates the list of parameters passed onto the request URI.
The behavioral model cannot be described in the current specifications of the W3C WoT standard. For this reason, in this paper, we propose to extend the existing TD with a new vocabulary allowing the general description of behavioral models for any domain, in order to support the next steps of automatic deployment of the DTWT. Specifically, we added the terms model, modelInput and valueFrom as shown in Table I and explained in the following. Since the vocabulary is not reviewed by the W3C WG yet, we use the example namespace http://example.org/2022/wot/dtwt, so the recommended prefix to use in TDs is dtwt:. 1) Model: The field model is an arithmetical expression, encoded in a Python-like syntax, that describes the behavior of the property. This is basically represented via a function that is provided by the manufacturer of the appliance. As described in Section III, this field allows to describe the mathematical function that models the state of a readable variable r j ∈ R. Indeed, we assume that the manufacturer knows such a function to some extent, obviously the actual behavior of the appliance is determined by a number of factors that are dependent on the environment and are outside the control of the manufacturer a priori (i.e., the model parameters). In order to accurately represent this, the model is defined as a continuous function of a number of parameters that will be subsequently learned. More formally, a model is defined in the following way: Let us dissect the above syntax: a) behavior: The behavior is one of self and dot(self). In the first case, it means that the behavior of the property can be described by an algebraic expression, that is, a fixed value that has no dynamics over time and depends on top of some static properties. An example might be the intrinsic power dissipated by a heater, which is dependent solely on top of its power level, manually set by the user. Here, r j ∈ A will be described by a function in G in the form of Equation 1. In the second case, it means that the behavior of the property depends on time through a differential equation, therefore the function outputs its integration over time. This includes properties that may change depending on the time passed since a certain event has occurred, even if all the other properties of the digital twin remain constant. An example can be the temperature of a room after the heater has been turned on. In fact, after such event, the values do not change instantly, rather it takes a significant transient to reach a new steady state. In this case, r j belongs to B and the function is in the form of Equation 2.
b) function: The function is an arithmetical expression, encoded in python-like syntax. Apart from common numbers, operands and parentheses, we have added a few keywords that point to definite values in our TD. First of all, the function is defined on top of the set P of parameters that, as said, are where 0 ≤ i < m. The distinction between global and local parameter is needed when this latter is shared among multiple state variables. For this reason, the global[m] array will contain the whole set P share . Furthermore, the function can use other properties of the same DTWT, which are called "model inputs" and are listed in the modelInput field of the rProp. An example may be our temperature property that takes in input the power of the heater, which is another rProp of the DTWT. The detailed interaction between a model input and the model that imports it is described in the next subsection. Finally, the function can use the keyword self, which represents the nonintegrated value of the property, and the keyword value(), which represents the actual value read from the real sensor, when available. c) constraints: The constraints is a set of preconditions regarding the params[n] and the global[m] of the model. They are read by the optimizer and respected when performing the parameter optimization. We assume that each parameter p j ∈ P is bounded by a minimum and a maximum value, i.e., p min = 0.01. The global parameters' guess, as for the constraints, is to be set only once throughout the TD (clashing assignments will lead to errors).
2) Model Inputs: The field modelInputs is a list of other rProps of the WT that are used within the model. Each of these has five fields: • title, which is a friendly name, • propertyName, which is the exact name of the rProp of the WT that this input is referring to, • type, which is the JSON-LD type, • model, which is again a model (using the same syntax as described above) that defines how this input affects the model of the property, and • modelType, which is an optional field denoting a class assigned to this input that is only valid within the scope of the property and is used to aggregate all inputs belonging to the same modelType (if there is more than one). The property model can use the modelInputs in two ways. The first is by using the construct "input({title})"; this imports the exact model of the modelInput identified by "title". The model input may have its own params[]: in this case, params[i] of the property model is not equal to params[i] of the model input, as they have different scoping. The model input may refer to the value outputted by the actual property identified by propertyName though the keyword self. Alternatively, the property model can import a group of model inputs through the construct inputType({modelType}); in this case the property model imports all the model inputs with the type modelType and aggregates them. The aggregation takes place though an aggregation function which must enclose the inputType() call (for instance sum(inputType(modelType))).
3) Value From: The field valueFrom describes whether there is a real property that can be read (e.g., a real sensor), in such case the value of this field will be set to "readProperty". Alternatively, the field can be set to "model", which instead triggers the simulation of the property value (depending on the behavior, via algebraic evaluation or integration over time) as described by the model field of the rProp. This indicates where the data comes from when querying directly the rProp via its URI, however, when the latter gets imported into a model, it is its model that always gets imported.
In the Appendix, we show the JSON code of the TD of the smart home environment, restricting our attention to the new fields which are used to describe the behavioral model of the IoT system.

V. FRAMEWORK ARCHITECTURE AND IMPLEMENTATION
Based on the TD extension described in the previous Section, we designed the RDT framework to support the automatic generation of a DTWT. The framework allows to monitor the properties of the WT, to store their values, to fit the behavioural model till creating the trained model, and, finally, to generate the DTWT. The RDT framework architecture is micro-services oriented, with each macro-functionality mapped to a specific module. As shown in Figure 3, the architecture is composed of six main modules: a single one for the front-end functionalities, while the other five running on the back-end. More in detail, the Dashboard module provides an intuitive Graphical User Interface (GUI) through which users can easily interact with the framework. We detail a typical flow of operations in Figure 4. Three main interaction modes are supported: simulating the IoT system operations and producing simulated sensory data, uploading traces containing the measurements, or attaching a physical device to the platform via the API of the RDT framework. Using any of the previous options, the user provides the training data for the parameters' identification and then configures the training hyperparameters such as the tolerance for termination of the least squares or the algorithm itself. Once the model has been trained, a new DTWT sharing the same TD as the original WT can be spawned; the DTWT is completely detached from the physical IoT device and hence can be used for what-if analysis (i.e., the user can observe how the twin would react to future events). In addition, the framework supports re-sync operations when the properties of the DTWT can be re-initialized with the current values of the original WT. The back-end functionalities are implemented within (i) the core module, (ii) the learning module, (iii) the twin module, (iv) the thing module, and (v) the simulator module. The core module enables the communication between the dashboard and the rest of the services through a dedicated API, by translating the user's requests into proper commands to be invoked on the services. Additionally, the core module monitors the Things, collecting all the measurements and data needed for the training phase from the learning module. The latter, as better detailed in Section VI, allows to parse the TD and to instantiate the behavioural model described by our TD extension. Furthermore, it uses the data provided by the core module to derive the optimal value of the model parameters. The twin module takes in input the trained model and generates the DTWT, which forecasts the values of the properties through the trained behavioural model. The Thing module contains all the mechanisms to interact with the IoT counterpart. This can be a physical device -in this case a dedicated channel is created for the data exchange -or can be simulated through the simulator module. The latter is just a wrapper for domain-specific tools that allow reproducing the behaviour of a device, by generating the values of its properties over time and allowing to receive actions in input. As a result, any custom simulator can be connected to the RDT framework by implementing a proper connector. Clearly, the process of training, learning, spawning and simulating may be repeated over time, as the behaviour of the physical devices may change or there may be aspects that had never manifested during the previous training iteration. In such case, the newly generated DTWTs will replace the old ones. Implementation: The front-end functionalities are included in the Dashboard module which consists of a Web application written using the Angular 3 framework, as shown in Figure 5; the Apache Echarts 4 library is used to plot the results of the whatif analysis, i.e., showing the real measurements and the predictions made by the DT. The back-end functionalities are implemented within the other five modules of the architecture: each of them is implemented in Typescript and runs over NodeJS as runtime system. The Thing and the twin modules have been implemented as WTs using the Eclipse node-wot tool 5 . More in the detail, each WT runs a Servient, as indicated in the official guidelines of the W3C WoT Scripting API 6 . The learning module is a Web server that collects requests from the core module through a REST APIs. The optimization tasks are implemented as Python scripts using the SciPy library, as better detailed in Section VI. The simulator module is written in Typescript.

VI. DT LEARNING
The learning module is a crucial component of the RDT framework. It is in charge of parsing the TD of the WT, extracting its behavioral model, and generating the trained behavioral model from the data. The operations of the module can be split into three major tasks: (i) model import, (ii) model inference, and (iii) model learning. In the following, a detailed description of each task is provided.

A. Model Import
A parser module has been implemented in order to translate the arithmetical expressions that are encoded in a Python-like syntax within the TD of the WT, i.e., the algebraic functions G and the differential equations F , into an executable Python code. Listing 1 shows an example of the translation of the temperature property for the smart home example (Listing 4). In Listing 1 we can notice the differences between the algebraic variables (the y) and the differential properties (the x and the dxdt). In this specific example, the variables x[0]  [2] correspond to the heating and cooling power, respectively. The rationale of the equations is discussed in Section VII-A.

B. Model Inference
The inference task returns the history of states in a specific time interval, given the initial state, the model parameters and the control actions; i.e., it is used as a mathematical simulation engine to build past or future states. More in detail, given t in a time interval Γ T := [t 0 , t T ] ⊂ Γ from an initial time t 0 to an end time t T , the actions executed on the writable properties performed during this time interval W Γ T , some model parametersP , and an initial stateR(t 0 ), the models defined by the sets F and G (in the form of the Equations (1)-(2)) allow the prediction of the states R(t) over Γ T . To this aim, we introduce a parametric and non-autonomous ordinary differential equation (ODE) that is defined for each b j ∈ B from the executed actions and the model parameters: Solving the Cauchy -or initial value -problem results in a prediction of the DTWT behavior according to the parametrized model. In this work, we employed ODE solvers based on Runge-Kutta schemes [24], [25,Ch. 5], which provide a numerical approximation b j (t) of a solution to (3). Then, one can readily compute the approximation of a k ∈ A of the algebraic states using (1) pointwise. For our purposes 7 , the ODE solver provides B WΓ T ,P ,R(t0) (t) and A WΓ T ,P ,R(t0) (t), namely it returns the trajectories of any b j ∈ B and a k ∈ A on a time interval, given a history of actions W Γ T , a set of parametersP and an initial stateR(t 0 ).

C. Model Learning
The inference task assumes the knowledge of the model parameters P (calledP in Section VI-B). However, these values are not known a priori and need to be estimated. For this reason, this task is in charge of estimating P withP starting from the observed behavior of the WT. Let Effectively, given some past actions, we seek the optimal choice of parametersP that minimizes the deviation between observations and retrospective predictions based on the parametric model. Defining H WΓ Q ,P ,R(t0) (t) := h(t, B WΓ T ,P ,R(t0) (t), A WΓ Q ,P ,R(t0) (t), W Γ Q (t),P ) given the actions W Γ Q executed in Γ Q := [t 0 , t Q ] ⊂ Γ, with t Q ≥ t O , and the timestamped observations (t k , Ω k ), k = 1, . . . , O, we consider the following optimization problem: Where P is the hyperbox containing the lower and upper bounds of each parameter. We also define R 0 as the set of the possible initial states. In the smart room example presented so far, R 0 is composed of the constraints: −20 ≤ The resulting mathematical task is a nonlinear least squares problem, possibly with bound constraints [27,Ch. 4] 8 . Starting from some guesses P guess and R guess (t 0 ), and seeking some optimal values P and R (t 0 ), the numerical solver needs to compute H WΓ Q ,P ,R(t0) (t k ) for some tentative valuesP ∈ P andR 0 (t 0 ) ∈ R 0 . In turn, such evaluation requires to solve an initial value problem as in (3), obtaining B WΓ Q ,P ,R(t0) (·) and A WΓ Q ,P ,R(t0) (·). Then, these predicted trajectories are sampled at the time instants t k , k = 1, . . . , O, where the measurement model h is evaluated, yielding H WΓ Q ,P ,R(t0) (t k ), k = 1, . . . , O.
Given the estimatesP andR(t 0 ) of model parameters and (differential) state at time t 0 , the learning module is able to predict the DTWT state at any time for some given history of actions on the writable variables W Γ Q , effectively simulating the system dynamics and behavior according to the identified model. In this case, the W Γ Q function is needed to simulate the action executed in future times t k , i.e., for t O < t k ≤ t Q .

VII. VALIDATION
In this Section, we present a comprehensive analysis and validation of the proposed RDT framework. We assess the performance on two different case studies: (i) a simulation test where we present the results of the smart home scenario introduced firstly in Section IV, and (ii) a real test-bed consisting of a drone quadcopter which can be employed e.g., for videosurveillance applications. In the following two subsections, we describe the setup of the experiments and show the evaluation results.

A. Simulated testbed: smart home
In Section IV we introduced the smart home environment as a showcase of the WT TD extension. In this Section we detail the mathematical model characterizing the system behavior and we evaluate the performance of the learning process.
The proposed scenario is composed of two closed rooms: room R A and room R B . At time t the temperature of R A is denoted by T A (t), the temperature of R B by T B (t), and the outdoor temperature by T out (t). Inside each room (differently from our initial example) we have a heater that we assume to be connected to the same heating system, i.e., they are simultaneously either ON or OFF. The heaters' status at time t is defined by the binary variable b H (t): The heaters' power at time t are defined by H A (t) and H B (t) for the heater in R A and R B , respectively. In R A we suppose to have also a cooler whose power at time t is denoted by C(t); this depends on a user-defined setpoint C ref (t) which has 10 degrees of active powers, namely 0 ≤ C ref (t) ≤ 9, C ref (t) ∈ N for all times t. Based on our previous notation, we have the set of readable variables The following differential equations describe the system dynamics over time t; they will be used in the TD of the WT:Ṫ Herein, the linear model for the temperature dynamics is provided by Newton's law of heat transfer, whereas considering thermal inertia in the cooling system yields the first-order linear model in (10). The parameters set P is defined by P = {α R 1 , . . . , α R 10 }, where α R * are free variables and their values will be estimated by the learning module of the RDT framework, based on observations from the simulated/real environment. Given such a model, we generated the TD for the rooms as previously introduced in Section IV. In this description, we note that some parameters are shared among different properties. For example, α R 3 is connected to both R A and R B . The parameter α R 6 is shared between the two heaters but it coincides with the outdoor temperature, assumed to be constant over time, i.e., T out (t) = T out = α R 6 , ∀t. Finally, we defined a global variable for the outdoor temperature, called global [2] in Listing 4.
We set up a simulation environment to generate the temperature data acquired by the virtual sensors positioned inside the two rooms. To avoid a straightforward learning system where the proposed DTWT model mimics exactly the simulated environment, we defined a different model to simulate the rooms' temperature. Considering a thermal inertia, and thus first-order dynamics, in the heating system and not in the cooling system, the simulation model reads as follows: In the Equations above, the parameters β * are used to customize the rooms' simulations and are unknown to the user. Where not specified otherwise, their default values are indicated in Table II. The observed parameter values at time t k are represented by the set To make the simulation more re-alistic, we added a Gaussian noise to the observed temperature during the learning process, i.e.,: where ε ∼ N (µ, σ) simulates the error introduced by the devices. In the following tests, we used µ = 0 K and σ = 0.1 K. Finally, also in the simulation part, we keep the T out constant with an additive Gaussian noise, i.e., T out = 15°C + N (µ = 0 K, σ = 0.1 K).
In the experiments, we evaluated the ability of the trained behavioral model to forecast the indoor temperature. We generated two DTWTs for the two rooms, and we set up the framework in order to learn the value of T A . As described in Figure 4, we uploaded the tracks containing the temperature measurements from time t = 0 to the time of the DTWT generation t spawn . These tracks are generated using the rooms simulator described by Equations 11-17 generating the observations Ω k , for 0 < k < t spawn , using a predefined sequence of actions W Γspawn for the writable variables (shown in blue and orange lines in Figures 6a-6c). Figures 6a, 6b, 6c Figure 6c, the parameters p guess were initialized with random values. Figure 6a shows that the proposed model is able to predict the room temperature in a very accurate way. Indeed, after the training interval (equal to 34h), the line of the estimated values overlaps with the line of the observed values. In Figure 6b we reduced the training length compared to the previous analysis (t spawn =10h). As expected, the amount of training data impacts on the forecast error, which is higher than Figure 6a. However, the curve of estimated values is still quite close to the curve of the observed values, thanks to the effective initialization of the model parameters p guess . Indeed, through the guess field explained in Section IV, the user can provide the initial values of the model parameters within the TD of the WT, based on prior contextual knowledge of the use case; such assignments are then automatically loaded by the RDT framework. Vice versa, Figure 6c shows the impact of parameter calibration and training on the performance of the DT. More specifically, we plot with a yellow dashed line the estimated temperature values when no learning has been performed at all: in addition, the  model parameters are initialized with random p guess values, and not changed during the training phase. We can notice that the expected values diverge significantly from the observed ones.
In the same Figure, the red solid line depicts the case where the training is executed, but without any initial calibration of the p guess parameters. Comparing Figures 6a and 6c, we can notice that the calibration has a positive impact on the forecast accuracy; however, even without it, the module is able to learn from the incoming data and to improve its performance over time.
Finally, in Table III we summarize the performance for all the configurations considered in Figures 6a, 6b, 6c, by reporting the mean squared error (MSE) during the test phase only (i.e., t > t spawn ). The third row (0% training, Random initial guess) refers to the baseline where no parameter initial calibration and no learning phase have been performed. Vice versa, it is easy to notice that both the training time and the tuning of the initial guesses are of paramount importance to minimize the MSE metric (row 2).

B. Real testbed: quadrocopter
Differently from the previous experiment, in this Section we evaluate the proposed framework in a real testbed scenario. The case study is the DT of a quadcopter (in our case, a DJI Mini 2 drone 9 ), flying in an outdoor environment. A quadcopter is a small-scale helicopter with four rotors directed upwards and placed in a square formation from the quadcopter's center of mass. The quadcopter movements can be controlled by setting the angular velocities of the rotors which are spun by electric motors. In the literature, several models have been proposed in order to characterize the quadcopter's kinematic, at different granularity levels. Interested readers can refer to [28] for a detailed review. In this work, we used a second-order linear dynamics model in the body reference frame [28]. Specifically, let q be the target quadcopter. The latter is defined by its position in global reference frame with the triple (q x , q y , q z ) ∈ R 3 and by its attitude with (q φ , q θ , q ψ ) ∈ R 3 . Here, (q φ , q θ , q ψ ) are the three Euler angles modeling the yaw (−π ≤ q ψ ≤ π), the pitch (− π /2 ≤ q θ ≤ π /2), and the roll (− π /2 ≤ q φ ≤ π /2), which represent the orientation of the quadcopter. In the experiments, latitude and longitude are remapped to local q x , q y coordinates. The velocity of q in global reference frame is defined by q v = (q vx , q vy , q vz ) ∈ R 3 and in the body frame reference by q B v = (q B vx , q B vy , q B vz ) ∈ R 3 (see Figure 7 for a visual description of the variables). Here, we assume small angles  Figure 6a shows the observed and estimated values when the DTWT is spawned at time 34 h; Figure 6b shows the same curves when the DTWT is spawned at time 10 h; Figure 6c shows the same results when the DTWT is spawned at time 34 h but without any initial calibration of the parameter guessesp. approximation that yields to q φ = q θ = 0. The angular velocity for the yaw is defined by q vψ . Finally, the following rotation matrix RT(q ψ ) is used to convert the copter velocity from the body frame reference to the inertial frame one: The model described so far defines the actual state of the quadcopter q, i.e., its position, altitude, and velocity. The quadcopter is controlled by a remote controller whose modeled inputs are: • throttle Th, that commands climb/decent movement of the copter. Positive values of Th are for climbing request, descent otherwise. • rudder Ru, that commands the yaw movements. Positive values of Ru are for clockwise rotation of the copter. • elevator El, that commands the pitch, i.e., the forward and backward movements. Here El > 0 means forward, backward otherwise. • aileron Ai, that commands the roll, i.e., the left and right movements, where Ai > 0 means left movements, right direction otherwise.
The aforementioned user inputs constitute the set of writable variables W of the device. Following the drone's model de-scription with states and inputs, we define the system dynamics as follows:q complemented by the kinematic relationships: Notice that the dynamics are expressed in the drone's body reference frame and that the first-order models for the velocities stem from Newton's basic laws of classical mechanics and the inertial properties of the copter, namely from its mass distribution. Furthermore, although uncoupled to the body reference frame, the dynamics equations involve different axes of the inertial reference frame. The model above contains 8 free variables, α D 1 , . . . , α D 8 , which represent the set of parameters P specific of the quadcopter in use, and which must be properly tuned. Given such a proposed behavioral model, we defined the TD of the WT associated to the quadcopter; the latter will be used by the RDT framework to generate the DT of the appliance. Due to the length of the resulting TD, we report here only the most significant fragments 10 .

Listing 3. DTWT TD, x-velocity property
Another fragment of the TD is reported in Listing 3, focusing on the modeling of the quadcopter's velocity. More specifically, we show the velocityX property that corresponds to the q vx state of the quadcopter and whose dynamics are described by Equation 27. In this case, the valueFrom field is set to model which means that the property has no real sensor in the drone and hence the value is derived from the model. The model field encodes the Equation 27 using the syntax described in Section IV. Finally, the modelInput field lists the other properties used inside the model.
Using the TD described above, we deployed the WT of the DJI quadcopter and connected it to the proposed RDT framework. During the flight, we collected the drone's data thanks to the DJI APIs that allow downloading the raw data of the onboard sensors. More specifically, we measured the following quantities: latitude, longitude, and altitude for the drone position (that are remapped to local (x, y, z) coordinates); compass for the drone's attitude (where compass defines the yaw), and elevator, aileron, throttle, rudder as the joystick user's inputs. The experiments aim to validate the capability of the RDT framework related to the following aspects: (i) the overall ability of the proposed TD extension to model complex IoT systems like the proposed one, (ii) the accuracy of the learning phase and the impact of different parameters such as the training length; (iii) the effectiveness of the DT to support what-if analysis and hence to avoid harmful operations, thanks to the capability of simulating the system reactions to user's commands.
After the take-off of the quadcopter, the RDT framework starts acquiring raw data from the drone and activates the model training phase. The take-off and the landing procedures are considered special movements hence they are not taken into account during the training phase. We tested two DTWT spawning events at a distance of 10 s one from the other in order to evaluate the impact of the training length.
In Figures 8a, 8b, 8c we plot the real (q x , q y , q z ) values (got from the onboard sensors) with a dashed red line. In the same Figures, we plot the estimated position when the DTWTs is spawned at t spawn = 5 s (blue solid line) and at t spawn =15 s (green solid line). It is easy to notice that the three curves almost overlap during the training phase, i.e., when t < t spawn . Vice versa, the curves of observed values and of predicted values with t spawn = 5 s diverge significantly during the test phase when the DT is used as a standalone component: this is a clear symptom that the training phase was too short. Indeed, with t spawn = 15 s, the DT is able to forecast the trajectory of the quadcopter in a quite accurate way for all the three axes.
In the next experiment, we investigate the possibility to deploy the DT in parallel with the actual IoT system and to use it for real-time what-if analysis. More in detail, in Figure 9 we envision the usage of the RDT framework by a drone pilot to safely control his/her device. We consider a scenario with geo-fence areas, i.e., flight zones from which the drone is not allowed to leave. After the definition of such areas, the user generates a DTWT of the drone through our RDT framework, and he/she tests any pilot command on the DTWT before executing them on the real drone. In Figure, the drone is in position (q x0 , q y0 ); the user provides a sequence of throttle/rudder/elevator/aileron commands, with the relative time intervals, to the DTWT. The latter returns an alert warning since, based on the positions estimated by the trained behavioral model, the drone would be located in  position (q x1 , q y1 ) outside the geo-fence area. As a result, the user inputs another sequence of commands which are validated by the DTWT (returning position (q x2 , q y2 )). Finally, he/she issues them to the real drone which moves to the position (q x3 , q y3 ), remaining inside the geo-fence area. Let d thr be the radius of a circular geo-fence area centered on the actual position of the drone. Given a set of control commands, the DT must estimate the future position of the drone, and, in addition, detect the events in which the drone will move outside the geo-fence area. Let t la be the lookahead time that specifies the time offset in the future when the drone position must be predicted. As the evaluation metric for this experiment, we used the precision index. The latter is the ratio of correctly predicted positive observations (true positive) to the total predicted positive observations (true positive plus false positive), where high precision relates to a low-false positive rate. In this case, such a ratio is critical because it expresses the times in which the system failed to detect crossing events of the geo-fence borders. More formally the index is calculated as follows: where TP (true positive) represents the true positive values, i.e., when the DTWT correctly predicts that the drone will remain inside the geo-fence area after t la seconds. The value of FP (false positive) indicates the number of cases when the DTWT predicts that the drone will stay inside the area while the real position is outside.
In Figure 10a and Figure 10b, we plot the precision index when varying the look-ahead time t la and the geo-fence area d thr , respectively. Figure 10a shows the index for two different training time, t spawn =5sec and t spawn =15sec, where d thr = 5m. It is easy to notice that, like for the previous experiments, the training length impacts significantly on the estimation of future values. Moreover, the higher the t la look-ahead time, the lower the prediction index. This is due to the accumulated errors as the DTWT moves to future time intervals. However, when the DT is employed with t spawn =15, the number of harmful events -in our case geo-fence exit-can be considerably reduced compared to a case when the DT is not employed at all. The same trends can be observed in Figure 10b where t la = 5m. The radius of the geo-fence area impacts the precision value in a way that false positive values are less frequent when the target area is larger.
The last experiment shows the possibility for the RDT framework to continuously improve the accuracy of the DTWT model over time. As described in the previous Sections, the behavioral model for the DT is based on a set of free variables α D that must be properly tuned by the RDT framework. In the previous experiments, each training stage was initialized with the P 0 that are read from the WT TD. On the contrary, in this experiment, we used the same estimated parameters set during consecutive training phases. More formally, let P 1 ,P 2 , . . . be the trained parameters set after 1, 2, . . . training rounds that used P 0 1 , P 0 2 , . . . as initial parameters guess, respectively. To exploit previous knowledge, in each training round we used as initial guess the trained parameters of the previous round, i.e., P 0 i =P i−1 , ∀i > 1 with P 0 1 = P 0 . The rationale of this experiment is to evaluate the capability of the RDT framework to continuously train its DT model  Figures 10a and 10b by varying the look-ahead time (t la ) and the distance threshold (d thr ), respectively. Figure  10c shows the distance error dre over time for consecutive training rounds.
during its lifetime. In Figure 10c we show the distance error between the real drone and the predicted position (d re ) after consecutive training rounds. Here, the training time is set to 10 s. We can notice that the error decreases significantly over the training rounds, hence justifying the effectiveness of continuous learning mechanisms. We plan to further elaborate on this feature of the RDT framework as future works.

VIII. CONCLUSIONS AND FUTURE WORKS
In this paper we presented the Relativistic Digital Twin (RDT) framework, which is able to replicate a physical asset, being it a single system or a System of Systems (SoS) into an abstract Digital Twin Web Thing (DTWT) that emulates its behavior and its reaction to events. The resulting framework has the capability of (i) generating heterogeneous and generic Digital Twins that are not necessarily tied to the use case on which they operate, and (ii) interoperate with wellknown IoT frameworks that use established standards. To this aim, we targeted an initial modeling of the real world system based Web of Things (WoT) standard promoted by the W3C. As research contribution, we proposed to extend the Thing Description (TD) component of the WoT standard in order to take into account the system behaviour as a set of algebraic expressions or differential equations. We presented the new TD vocabulary and all the components of the RDT framework allowing to generate a trained behavioural model by fitting the model parameters to the observed data. The RDT framework was evaluated in two different scenarios, namely the DT of a simulated smart home environment with heterogeneous sensors/actuators and, and the DT of a realworld quadcopter predicting its kinematic over time. In both cases, we assessed the effectiveness of the parameter training process and the capability of the RDT framework to support predictive and what-if-analysis. The work presented in this paper is pioneering and we believe it can trigger the interest of the scientific community into pursuing further extensions of the RDT framework. One of them could be making the generation of these Digital Twins federated, so that a SoS of Digital Twins can be composed by building a mashup of pregenerated Digital Twins of appliances that have not yet worked together in the real world. In addition, we plan to include support for additional ML techniques (also model-free) and to extend the evaluation to other case-studies.

APPENDIX
Here we present three code snippets that exemplify temperature-based use case 11 presented in Section III. The code below shows the three newly introduced JSON fields for the rProp that represents the temperature in one of the rooms (T A ). As the property is connected with a sensor value, we set "valueFrom": "readProperty". The model field is specified on top of three local parameters and global parameters 2 and 3. The model also depends on three modelInputs: heaterPower, coolerPower and temp1. temp1 is the temperature of the second room, which is imported into the model through input(temp1). Since the model of temp1 only specifies "self", then we can assume that the optimizer will import the model of the property temperature1 as it is. Furthermore, both coolerPower and heaterPower are summed up and imported together through sum(inputType(@heatPower)). This happens because they are responsible (one opposed to the other) for the same phenomenon, i.e., a power causing a temperature variation over time. Both the models of "heater" and "cooler" are not imported as they are: the first one is multiplied by a parameter (params[0], which is different from the params[0] in the model of the temperature) and the second one is multiplied by -1, because its power contributes negatively to the temperature rise.
The reason behind how we are treating differently heater-Power and coolerPower lies on top of how they are defined. In Listing 5 we can see how heaterPower is defined: its model only outputs the actual value of the rProp. This identifies a set of cases where the manufacturer only provides the behavior of the component independently from the environment in which it acts. In fact, in this case, the impact of the heater-Power has to be tuned via a parameter within the modelInputs in Listing 4.
Differently, the coolerPower, as it is defined in Listing 6, indicates a rProp that encloses pretty much all the information about the cooler. In fact, the value() of the cooler is never used, instead the rProp always outputs the value calculated by a model that defines how the cooler would impact an environment on top of two model parameters. Furthermore, the model imports the model of the rProp called "coolerSetPoint" as a modelInput. The latter is another rProp that only outputs the power lever of the cooler knob as a number constrained between 0 and 9.