232 changes. These changes are captured and then reflected in future iterations of the digital twin models (e.g., training process). These changes are validated by the similar behavior and operation of the corresponding device 222 itself. At any point in time, the models deployed to the device digital twin 232 are representative of the codification of the behavior and operational state of the corresponding device 222. New models are created which instantiate the changes to the performance, operation, and physical state of the device digital twin 232 that occur over time. These new models can then be used in a feedback loop. Based on results generated in accordance with the digital twin, one or more actions can be initiated with respect to the infrastructure. These artificial aging functionalities are further illustrated and explained in the context of FIGS. 3A and 3B.

FIG. 3A illustrates an exemplary process 300 of artificially aging a digital twin according to an illustrative embodiment. By way of example, process 300 can be executed in accordance with computing environment 200 of FIG. 2. As shown, process 300 involves digital twin management engine 210 and device digital twin 232 at a first time T1 corresponding to a first state of device 222, and at an nth (e.g., second) time Tn corresponding to an nth (e.g., second) state of device 222. Note that a counter 302 in device digital twin 232 can be used to maintain the time instance associated with each state of device 222 that device digital twin 232 is virtually representing.

Thus, as shown, assume that digital twin management engine 210 receives one or more device-related datasets from device 222. Note that one or more device-related datasets can alternatively or additionally be received from some other data source other than directly from device 222. As mentioned above, the one or more datasets can be, but are not limited to, workloads, workload patterns, and/or causal variables associated with device 222. Digital twin management engine 210 then applies all or a portion of the one or more datasets to device digital twin 232 to advance device digital twin 232 from a first time T1 corresponding to a first state of device 222 to an nth (e.g., second) time Tn corresponding to an nth (e.g., second) state of device 222. It is assumed that the goal is that device digital twin 232 represent the state (e.g., hardware, software, and/or data configurations) of device 222 at Tn. Digital twin management engine 210 then receives device-related results (e.g., results of execution of one or more physics-based models 110, the one or more AI-driven models 112, the one or more simulations 114, the one or more analytics 116, and/or the one or more predictions 118 that constitute device digital twin 232) and can initiate or otherwise take one or more actions in response to at least a portion of the received results.

In one non-limiting example, assume that device 222 being virtually represented is a storage array with an associated file system stored thereon, and that it is desired to place the device digital twin 232 into a state consistent with the storage array, e.g., so as to troubleshoot a problem being experienced by the actual storage array (as will be illustratively explained below in the context of FIG. 3B). Digital twin management engine 210 can artificially age (advance) device digital twin 232 (starting at time T1) by executing the same or similar input (write) and/or output (read) operations (IO operations) in the storage space of the file system (ending at time Tn) of device 222. In this way, at time Tn, device digital twin 232 virtually represents the file system of device 222 at its current state and thus can reveal one or more problems in the actual file system such that one or more remedial actions can be initiated by a user (e.g., administrator and/or automated system).

As explained herein, device digital twin 232 may be initially generated and then artificially aged by digital twin management engine 210 by obtaining configuration-related metadata for device 222 (one or more device-related datasets) and creating a virtualized replica of device 222 based on at least a portion of the configuration-related metadata. By way of example only, configuration-related metadata for device 222 may comprise one or more of hardware specifications, network specifications, hardware telemetry, and security information associated with a current device configuration of device 222. By way of further example only, configuration-related metadata for device 222 may comprise one or more images (e.g., backup images) generated of one or more of data, software, and system files associated with device 222.

It is to be understood that creating a virtualized replica of device 222 based on at least a portion of the configuration-related metadata may further comprise instantiating one or more virtual processing elements (e.g., VMs, containers, etc.) in which to execute the virtualized replica of the device 222 by mirroring, in the virtualized replica, at least a portion of the configuration-related metadata of device 222. Further, illustrative embodiments are configured to apply a change to device digital twin 232 to replicate application of the change to device 222. Applying a change to device digital twin 232 to replicate application of the change to device 222 may further comprise receiving the change to be applied to device digital twin 232 and then executing the change. In some embodiments, the change may be defined via a script or a command line issued by digital twin management engine 210.

It is further realized that when device 222 is an electronic device such as, by way of example, a storage array, such infrastructure degrades over time in much the same way as any complex machine which is dependent on software and hardware components. This affects the performance of customer workloads and ultimately their business. Unfortunately, there are no effective ways to address this and other like problems other than expensive replacement of the infrastructure (e.g., storage array) with costly downtime.

To address the above and other technical difficulties in infrastructure such as, but not limited to, storage arrays, illustrative embodiments are configured to obtain (periodically or otherwise) one or more measurement datasets from the infrastructure and/or from within the infrastructure environment (e.g., workloads, historical health data, vendor-provided health data, etc.), create a digital twin with a hybrid approach of physics-based and AI-driven models for each infrastructure, apply artificial aging techniques to the digital twin as described herein, monitor the digital twin behavior and output to predict degradation/downtime of the infrastructure based on usage over time, determine a solution to minimize the degradation/downtime (e.g., a different hardware, software, and/or data configuration, a different workload execution schedule, etc.), and rerun digital twin aging to determine if the solution will likely have its intended affect. The process can be iteratively performed to meet whatever solution criteria is needed/desired.

By way of example only, in a scenario where the target infrastructure is a storage array deployed at a customer location, the digital twin can monitor customer workload requirements and the impact on the storage array using workload simulation in the digital twin, wherein the derived insights can then be leveraged to optimize customer workload with respect to the actual storage array.

Accordingly, illustrative embodiments apply aging techniques to the digital twin to predict infrastructure usage under specific workloads, and thereby predict performance degradation and/or downtime of the infrastructure, as well as related costs of the degradation/downtime.

FIG. 3B illustrates an exemplary process 310 of artificially aging a digital twin to predict usage and a condition over time of an infrastructure according to an illustrative embodiment. By way of example, process 310 can be executed in accordance with computing environment 200 of FIG. 2. As shown, process 310 involves digital twin management engine 210 and device digital twin 232 at a first time T1 corresponding to a first state of one of devices 222-1, 222-2, and 222-3 (individually referred to in the context of FIG. 3B as device 222), at a second time T2 corresponding to a second state of device 222, and at a third time T3 corresponding to a third state of device 222. Note that a counter 302 in device digital twin 232 can be used to maintain the time instance associated with each state of device 222 that device digital twin 232 is virtually representing.

Thus, as shown, assume that digital twin management engine 210 receives one or more datasets from device 222, i.e., referred to as one or more measurement datasets comprising workloads, historical health data and vendor-provided health data (collectively referred to as health data) measured or otherwise collected for device 222. Note that, in this non-limiting example, workloads can be any IO operations performed in accordance with a storage array, while health data can be any attributes, parameters, values, and the like, associated with the storage array that are indicative of one or more conditions or behaviors (e.g., age, active service duration, environmental operating conditions, reliability statistics, historical degradation instances and patterns, historical downtime instances and patterns, etc.). Note that one or more measurement datasets can alternatively or additionally be received from some other data source other than directly from device 222 and may include other types of data not expressly mentioned here as may be needed/desired.

Digital twin management engine 210 then applies all or a portion of the one or more measurement datasets associated with device 222 (e.g., workloads, health data, etc. referred to as first dataset) to device digital twin 232 to advance device digital twin 232 from the first time T1 corresponding to the first state of device 222 to the second time T2 corresponding to the second state of device 222. It is assumed that the goal is that device digital twin 232 represents the state (e.g., hardware, software, and/or data configurations) of device 222 at T2. More particularly, device digital twin 232 generates device-related results (e.g., results of execution of one or more physics-based models 110, the one or more AI-driven models 112, the one or more simulations 114, the one or more analytics 116, and/or the one or more predictions 118 that constitute device digital twin 232) based on the device-related dataset(s) provided by digital twin management engine 210.

For example, using at least a portion of the workloads (e.g., customer workloads) and, when applicable or otherwise available, health data obtained for device 222, device digital twin 232 is configured to artificially age or advance device digital twin 232 from a current state (at T1) to a future state (at T2) utilizing, for example, the one or more physics-based models 110, one or more AI-driven models 112, the one or more simulation modules 114, and the one or more prediction modules 118 (e.g., one or more machine learning algorithms or other available AI-based predictive methodologies) to predict a condition of device 222 based on usage over time, i.e., generate a usage prediction. By way of example only, device digital twin 232 can predict that one or more of the storage disks that constitute the storage array of device 222 will likely degrade beyond acceptable operating conditions (e.g., violate one or more customer service level agreements) based on execution of the given customer workloads over the course of a specific time duration. By way of another example, device digital twin 232 can predict that the current version of operational software running on the storage array will likely malfunction during execution of the given customer workloads over the course of a specific time duration.

Digital twin management engine 210 is configured to receive the usage prediction results, i.e., a first usage prediction, from device digital twin 232. Assume that the first usage prediction indicates that a degradation and/or downtime will occur with respect to device 222 when the given workloads are executed by device 222 over a specific time period. Digital twin management engine 210 can then apply a second dataset to device digital twin 232. More particularly, the second dataset may represent a solution determined to avoid or at least minimize the predicted degradation/downtime (e.g., a different hardware, software, and/or data configuration, a different workload execution schedule, etc.). The solution reflected by the second dataset can reconfigure physics-based models 110 and/or AI-driven models 112, as well as other modules, to cause device digital twin 232 to reflect the changed configuration. Note that solution datasets can be obtained or otherwise derived, for example, by IT personnel, automated systems, and/or some other source. Device digital twin 232 can then rerun digital twin aging to determine if the solution will likely have its intended effect to avoid or at least minimize the predicted degradation/downtime for device 222. In so doing, device digital twin 232 is artificially aged or advanced to time T3 to represent device 222 at a third state.

Digital twin management engine 210 is configured to then receive results (i.e., a second usage prediction) of the second dataset application. Assuming the solution successfully addresses the predicted condition or behavior to avoid or at least minimize degradation/downtime, digital twin management engine 210 sends some or all of the solution results (e.g., predictions, costs thereof, and recommendations) to IT personnel and/or an automated system 320 to initiate or otherwise take one or more actions in response to at least a portion of the received results, i.e., actually apply the solution to device 222 to proactively prevent the condition or behavior from occurring (e.g., apply the above-mentioned updated hardware/software/data configuration(s) and/or updated workload execution schedule to device 222). Additionally or alternatively, digital twin management engine 210 can initiate or otherwise take one or more actions in response to at least a portion of the received results.

It is to be further understood that if the solution is not successful, digital twin management engine 210 can provide another solution dataset to device digital twin 232 to simulate and predict results of the alternative solution. This iterative process can occur as many times as needed/desired to achieve an acceptable solution. Depending on the nature of the alternative solution, device digital twin