| Characteristics | Description | |
|---|---|---|
| C1 | System under study | A Styrofoam box containing a lid, a heating element, and fan, controlled by a Raspberry Pi, for incubating tempeh. |
| C2 | Physical acting components | fan: Circulates air throughout box heater: Raises the temperature of surrounding air controller: Controls the fan and heater power_supply: Powers electrical components |
| C3 | Physical sensing components | temp_sensor_1 temp_sensor_2 temp_sensor_3 |
| C4 | Physical-to-virtual interaction | temp_readings_trans controller_state_trans |
| C5 | Virtual-to-physical interaction | The controller in the PT sends sensor and actuator data on a periodic basis over RabbitMQ. |
| C6 | DT services | safe_adaptation real_time_viz_service anomaly_detector policy_optimization heater_state_estimation_service what_if_sim |
| C7 | Twinning time-scale | Slower than real-time Real-time The DT-to-PT synchronization occurs every time the PT sends a message to the DT (on a periodic basis). Faster than real-time |
| C8 | Multiplicities | The current implementation has no multiplicities, however, it is possible to deploy multiple DTs for the same PT. |
| C9 | Life-cycle stages | The DT supports the design and the service phases. In the service phase, it supports creating, executing, saving, analyzing, evolving, and terminating. |
| C10 | DT models and data | Model: four_para_model pt_model ANN_state_estimation_model ANN_model two_para_model controller_model env_model pt_and_env_model Data: temp_readings_streaming temp_readings_historical controller_state |
| C11 | Tooling and enablers | simulator state_estimator anomaly_detector_enabler optimization_algs dashboard_enabler godot docker influx_db rabbit_mq |
| C12 | DT constellation | The orchestration of the system-as-a-whole is carried out by micro-services. These microservices set up the multiple components from configuration files, including the models and data, tools and enablers, services, and physical-to-virtual and virtual-to-physical interaction. It is possible to leave aside some of the micro-services when initializing the DT for testing purposes.. |
| C13 | Twinning process and DT evolution | The PT-to-DT connection is done over Wi-Fi on a laptop using RabbitMQ. |
| C14 | Fidelity and validity considerations | The models have been calibrated against experimental data and the predictive accuracy of the best model is within 2°C. The models have been validated in a controlled environment. |
| C15 | DT technical connection | The PT-to-DT connection is done over Wi-Fi on a laptop using RabbitMQ. |
| C16 | DT hosting/deployment | The Incubator DT is deployed locally on a LAN. |
| C17 | Insights and decision making | dashboard_viz real_time_viz: 3D visualization of the current state anomaly_warning: anomaly detection dashboard: dashboard visualization of the current state and historical data heater_state_estimation: state estimation of the heater what_if_sim_results: what-if analysis for future behavior under different controller configurations controller_control: control policy updates to the PT commands |
| C18 | Horizontal integration | There is horizontal integration with the micro-services of the Incubator DT. The DT is able to exchange information with other information systems over RabbitMQ. |
| C19 | Data ownership and privacy | Datasets have been provided online to the public. No privacy-related data are stored. |
| C20 | Standardization | Communication is carried out using AMQP standard via RabbitMQ. Behavioral models have been produced following the FMI standard version 2. |
| C21 | Security and safety considerations | Communication can be TLS encrypted through the RabbitMQ broker. The physical controller counts with a safety consideration that turns off system if the temperature read is above 60°C or if the network connection is unstable. |