Digital Twin for Process Control (DTPC)

User ViewPoint

Usage Case Diagram Actors

General Description

The DTPC toolkit aims to construct, using open-source software, digital twins as abstractions of the main IoT devices. The toolkit will be able to interact with the physical devices, but it will also use the virtualized functions that are considered in the DiMAT Simulation and Optimization Suite as well as specialized simulation software. The DTPC will offer modular components for access control to the IoT devices as well as self-configuration and self-management functionalities. Moreover, different communication protocols will be supported (e.g., HTTP, MQTT, etc.) and open APIs will be provided for the users interacting with the toolkit.

Model

DTPC_UsageDiagram.png

Roles

The DiMAT’s DTPC toolkit will be used by users that assume different roles such as:

  • System administrator: responsible for the continuous operation of the DTPC toolkit, can add new equipment to be “twinned” to the platform and perform health-checks, also responsible for addressing security concerns.

  • Data scientist: responsible for analyzing the collected data that are fed to the DTPC via the appropriate functions and reaching conclusions about the manufacturing processes.

  • Materials engineer: expert on the operation of the equipment and the employed materials, responsible for sending explicit commands through the DTPC to the physical equipment, when necessary, can recommend simulation software to be used.

  • Applications developer: responsible for developing applications that utilize the digital twins managed in the toolkit.

Mockups

Activity 1

  • View Homepage

DTPC_Mockup1.png

  • View Login page

DTPC_Mockup2.png

  • Select command and parameters

DTPC_Mockup3.png

Activity 2

  • View Homepage

DTPC_Mockup4.png

  • Select Digital Twin to check

DTPC_Mockup5.png

Functional ViewPoint

General architecture

DTPC_Architecture.png

Implementation ViewPoint

Architecture of Toolkits

The Virtual Object (VO) is considered as a virtual counterpart of an IoT device. It supports interaction with the IoT device and a set of IoT management functions. It can act as a Digital Twin (DT) based on the support of a set of virtual functions. The VO can be deployed at the edge part of the computing infrastructure.

DTPC_Toolkits.png

The above figure presents the internal architecture of the DTPC toolkit. The architecture is split into three distinct tiers each aiming to address a specific functionality. These tiers are the Network Edge, the platform, and the cloud layer. The devices embedded in the mechanical equipment generate measurements that aid in identifying the current state of the equipment (Physical Twin). This data is either directly transmitted to the DT platform or aggregated via specialized network equipment. Then, they are given as input to the virtual functions specified in the DT platform. The current state of the equipment is stored in a local time-series DB such as InfluxDB. Human users can view information about the Digital Twin or issue commands through appropriately created User Interfaces (UI). Finally, Cloud based solutions offer long-term data storage as well as access to big data analytics algorithms and software libraries. Data flows among these components ensure the correct operation of the toolkit and assure the successful data analysis of the polled data from the edge as well as the control mechanisms for the physical twin.

Required components

Hardware componentes

Edge Devices

  • Sensors embedded in the Network Edge collect real-time data from the physical device concerning parameters such as temperature, humidity, pressure, energy consumption or environmental conditions and transmit them to the Digital Twin for analysis and simulation purposes. Through the continuous gathering of physical and environmental data, they enable real-time monitoring of the conditions, behavior, and performance of the physical system, detect anomalies and malfunctions and facilitate the prediction of the future state of the physical device. Moreover, they can apply some initial data processing of the collected information locally at the edge before transmitting them to the Digital Twin, reducing the consumption of the Platform resources and enhancing data quality.

  • Actuators perform real-time and remote control of the physical device by triggering actions introduced by results and observations of the Digital Twin or by direct commands applied by a user of the system. They can correct detected anomalies and risks of the physical system though emergency instructions defined by the Platform and adjust functional and control parameters, to ensure safety, health and maintenance of the system. They can also manage energy consumption of the system and contribute to the improvement of simulation processes of the Digital Twin by enforcing the recommended actions to the physical twin, enabling the platform to compare the resulting performance of the physical device with the simulated behavior and reassess the employed methods and algorithms.

  • Programmable Logic Controllers (PLC) are programmed and customized to control and monitor specific industrial and manufacturing processes and machinery and serve as an intermediate concerning the data exchange between the Digital Twin Platform and IoT devices such as sensors and actuators. Through their programmed control logic, they coordinate the performance of the Digital Twin and the physical system by transmitting input data from sensors to the Digital Twin and receiving instructions and control signals from the platform to determine the appropriate actions to be executed by actuators.

  • Radio-Frequency Identification (RFID) tags offer unique identification of physical objects of the system, enabling real-time tracking and monitoring. By combining RFID data with data collected from sensors, the Digital Twin is provided with a more accurate and synchronized representation of the physical object.

  • Raspberry Pi’s or other boards could also be employed for data acquisition, processing, and analytics purposes of sensor data at the edge and data transmission and bi-directional communication with the Digital Twin. They are also useful for rapid testing and prototyping of the Digital Twin concepts before deploying them at a larger scale.

Servers

Various types of servers can be employed in the development of the Digital Twin Platform.

  • Database Servers can handle data for short and long-term storage related to the DTPC toolkit and provide mechanisms for querying and efficient access. They also support structured data representation, provide security and access control and high-performance management of big volumes of data.

  • Servers for simulations are expected to be employed in the DTPC toolkit in order to run simulation models, implement algorithms and generate predictions concerning the behavior of the physical system.

Data Storage

Short-term

  • Real-time data, involving sensor measurements of the parameters, the current state of the physical system and short-term calculations of the virtual functions should be stored in local time-series databases inside the Digital Twin that are periodically updated.

  • Configuration data, such as system settings, control strategies, rules detailing the operation of the system or model parameters should be stored in a short-term configuration management system that needs to be frequently updated to perform punctual operational adjustments.

  • Edge computing data, such as data related to local analytics and actions performed at the edge, could be stored in gateways or edge servers for caching and quick accessing of data before transmitting them to the Digital Twin Platform. Temporary storage of data at the edge could also be employed when connection with the centralized system is unavailable or unreliable.

Long-term

  • Historical data: Data previously stored in the local time-series DB of the Digital Twin are transferred after a predefined amount of time to a long-term data storage system such as a set of relational databases, data lakes or data warehouses.

  • Simulation data concerning algorithms, parameters, results and configurations should be stored in specialized storage systems such as simulation data management platforms.
    Data for long-term storage should be better allocated to the Cloud and in collaboration with the DiMAT Cloud Materials Database.

Implementation Map

DTPC_ImplementationMap.png

The above figure provides a high-level overview of how a defined equipment control activity (send a command) issued by a user towards the physical twin (device) is implemented. First, the user interacts with the UI interface via an API such as HTTP and selects the appropriate option specifying the device and the command from a pre-defined list of available commands (e.g., shut-down, restart, increase speed, etc.). The UI passes along the information following a structured data format (JSON) and a suitable virtual function is employed to pass along the data (probably by adding more information to the JSON file, like IP addresses). Then, optionally, a Gateway receives the message and passes it along to the correct IoT device (I.e., an actuator) that enforces the corresponding action to the device.