Unlock Efficiency with High-Fidelity Replicas
System Modeling & Digital Twins service creates a high‑fidelity digital replica of your equipment or process. We use existing sensor data and system‑identification techniques to build mathematical models that mirror the real‑time behavior and conditions of your target machinery. Having a Digital Twin enables in-house designers and decision-makers to predict the behavior of the system being profiled, e.g., through numerical simulation of the system. It allows faster and cheaper what-if tests under different situations, for instance, a change of control law, more or less payload, or even a subtle change of operating reference.
Key benefits include:
- Detection of time-varying parameters that might be generating unexplained behaviors.
- Make informed decisions regarding the system operation based on data.
- Lower machinery downtime.
- Failure prediction leads to predictive maintenance.
- Optimization of control parameters without halting production.
- Test updates in the system virtually.
- Lower training costs of new personnel once the behavior of the system is documented and known.
- Tuning controllers is made easier because there are theoretical boundaries and analytical expressions to guide the task.
Our Non-Intrusive Methodology
Our approach uses already in-loco sensors, avoiding additional hardware costs to the process while accelerating time-to-value. We check the input and output sensors’ data and match them against a proposed mathematical model to identify its parameters. If the model is accepted, given a chosen metric, it becomes the Digital Twin of reference. This is a description from a high-level perspective, and a diagram with the flow can be seen in Figure 1 below. Observe that this is an iterative activity, where there is an evaluation after a model is considered ready, and in case the evaluation fails, there will be a decision on where to start the new iteration. The Digital Twin is then continuously updated with data to keep up with the real conditions of the system identified.

Sensor Reading and Input Acquisition Block
The “Sensor Readings and Input Acquisition” block covers recording meaningful data from the target system being modeled. This is a collaborative pipeline between in-house technicians and Under Control. The diagram can be observed in Figure 2.
- The Definition of Used Sensors defines the list of sensors that are available to be used and lists their characteristics. Here, we are interested in what they record, what their numerical precision is, etc. Basically, everything that would be in the manufacturer’s datasheet of the sensor.
- Calibration of Sensors gathers statistical information regarding the sensors: at least the covariance and bias of the reading. This serves to check if the sensor is precise and accurate enough to be used in the remainder of our processing pipeline. If this information is already available, we will rely on it as if it were true. Normally, we request benchmarking data, obtained by placing the sensor in a known condition and recording its signal for a period of time. Observe that this benchmarking does not generate the information that will be used for the model identification.
- Experiment Definition defines the layout of the experiments that will generate the data to be used later to identify the system structure.
- The Input and Sensor Readings signal record is the last activity in this pipeline, done in close collaboration for physical interaction with the machinery.

System Identification Block
We use the recorded data to identify the dynamic process of your system. Figure 3 shows the procedure. Given the system data, we estimate a model and evaluate it. If the identified model fails an acceptance test, we re‑evaluate whether the chosen structure is suitable or whether we need to roll back to the “Sensor Readings and Input Acquisition” block. If the model passes, it becomes the model of record. Note that multiple models can be obtained, and all will be presented.

Digital Twin continuous update
The Digital Twin must be continuously updated to accurately reflect the real system’s state. The update rate varies: it will depend on the dynamics of the plant. The key factor here is data. Data should not only be stored but also be pre-processed before being fed to the updating pipeline. This can be done before storing or before using; either approach works.
Under Control provides the service of updating the Digital Twin routinely. There is also the possibility of providing the Digital Twin update software so our client can perform the pipeline in-house. If real-time optimization is desired, then our solution should be integrated into the client’s monitoring pipeline, with our assistance. Normally we use C/C++, Python or Matlab/Simulink deliver the optimization software, but we are not restrained them. For instance, more and more we are seeing requests in Rust for its critical scenario safety.
Updating the model allows:
- Tracking certain information, such as model parameters related to key pieces of the plant, enabling preemptive maintenance, for example.
- Prediction of system behavior and energy consumption, having a starting point reflecting the real system state.
- Fast and accurate what-if tests.
- Reduce safety risks.
- Improve product quality.
- Cut downtime and energy use per unit.
- Lower failure-related costs and inventory.
- Minimize delays.
Conclusion
In summary, System Modeling & Digital Twins isn’t just about estimating a model—it’s about creating a high‑fidelity digital companion that evolves with your equipment. By combining your existing sensors and our advanced modelling expertise, we deliver a data‑driven mirror of your system that enables predictive maintenance, fast what‑if testing, and optimization without halting production. This continuous update cycle ensures that the twin remains aligned with the real plant. Working alongside your team, we tailor the Twin to your operation and keep it current, so you always have a reliable guide for strategic decisions that reduce downtime, cut energy use, and improve quality.

