Digital Twins Designer (DTD)

At a Glance

• Category: Planning, Design & Assessment
• Primary environment: MaaS Provider
• Documentation focus: Design reference
• Maturity: TRL 4–5 (first release, M18)
• Related architecture docs: Reference Architecture Guide, Environments

Purpose

The functional architecture of the solution is composed of four main components — Frontend, Backend, Database, and Message Bus — each contributing distinct capabilities that together enable an integrated and scalable manufacturing simulation and optimization environment.

Primary Actors

The D5.2 usage viewpoint defines roles, permissions, constraints, a role-task matrix, and a use case diagram for this solution.

• Asset designer: Defines the parameters on the interface of new assets and saves them in the assets collection of the database; constraint: Can only define new assets
• Manufacturing line designer: Defines the new manufacturing lines and saves them in the manufacturing lines database; constraint: Can only define new manufacturing lines and read the previously defined assets
• Simulator: Defines the simulator based on the manufacturing line designer that has been designed previously; constraint: Can only define and simulate simulations and read assets and manufacturing line information from the database
• Optimizer: Launches the optimizer of a previously defined simulation and defines the weights of previously defined metrics. A perturbation can also be added to reoptimize the simulation.; constraint: Can only define optimizations, read simulation data from the database and send results to the database.
• Digital Twin Designer: Define assets, manufacturing lines, simulators, optimizations, launch simulations, and launch optimizations.; constraint: Cannot manage users and users’ permissions

Use-case diagram extracted from MaaSAI deliverable D5.2.

Functional Components

DTD combines asset definition, production-line modelling, simulation setup, perturbation management, optimisation, and result publication. The functional view shows how digital-twin models move from configuration to simulation and how the resulting outputs are shared with monitoring and maintenance services.

Functional components diagram extracted from MaaSAI deliverable D5.2.

Design Baseline

The Frontend serves as the main interface through which the provider interacts with the solution. It allows users to define and configure the core operational elements of the system, such as assets, manufacturing lines, and simulation metrics. Through this graphical interface, users can visualize configurations, initiate simulations, and monitor system performance. The frontend component is containerized, ensuring portability and easy deployment across cloud or edge infrastructures. It communicates directly with the backend through API calls and is designed as a stateless component, meaning it temporarily handles session states during interaction but does not persist data locally.

The Backend is the logical core of the system, managing all business logic and data processing tasks. It acts as the central hub that integrates all system components and external connections, handling both simulation and optimization of the manufacturing lines based on the data defined in the frontend. Additionally, it manages authentication processes, ensuring secure access to resources. The backend is also containerized, facilitating modular deployment and scalability. It connects to the frontend and database via direct API calls, and to other solutions via the message bus. The backend uses the database to handle persistent states and publishes events or notifications to the message bus for asynchronous communication. The Database component ensures data persistence by storing all relevant information defined or generated within the system — including assets, manufacturing line configurations, and simulation metrics. This component is also containerized to simplify deployment and maintenance. It connects directly to the backend, providing reliable data access and long-term storage. As a stateful element, the database guarantees consistency, versioning, and persistence of all operational and analytical data within the solution. Finally, the Message Bus facilitates asynchronous communication between this solution and other external or internal MaaSAI solutions. It enables scalable, event-driven integration by decoupling components and allowing messages to be exchanged reliably even when systems operate independently. The message bus is containerized for flexibility and uniform deployment. It maintains transitory states, temporarily storing messages asynchronously until they are consumed by the intended recipients, ensuring reliable data delivery across distributed environments.

Overall, this architecture integrates all four components through a modular, containerized, and interoperable design, allowing efficient simulation, optimization, and communication with the broader MaaSAI ecosystem while maintaining a balance between stateless processing for flexibility and stateful persistence for reliability.

Architecture diagram extracted from MaaSAI deliverable D5.2.

Technology Stack

DTD is implemented as a layered, fully containerised platform combining a Python backend, a React frontend, and open-source digital-twin and data-integration services.

Category	Technology
Backend	Python 3 with FastAPI + Uvicorn, Pydantic for data validation, SimPy 4.1 as the discrete-event simulation engine, SQLAlchemy/asyncpg for database access, and HTTPX as HTTP client
Frontend	Next.js 14 (React 18) with PrimeReact, Radix UI, and Tailwind CSS; Chart.js and Recharts for charting
Data	PostgreSQL 16 as application and time-series database; MongoDB 6.0 as Eclipse Ditto’s internal store
Digital twin & messaging	Eclipse Ditto (twin state management), Eclipse Mosquitto (MQTT broker), Apache NiFi (data integration)
Platform services	Nginx reverse proxy, Keycloak 22 identity management
Containerisation	Docker / Docker Compose
Licence	no licence file is included in the repository; the component is developed as proprietary software within the MaaSAI research project

Integrations & External Dependencies

Within the WP10 high-level architecture, DTD sits at the fog layer, receiving telemetry from industrial sensors and PLCs at the edge. Shop-floor data is ingested over MQTT through Eclipse Mosquitto and processed by Apache NiFi, which triggers metric calculations and stores time-series data. Eclipse Ditto keeps the digital-twin state of all manufacturing assets synchronised with MQTT things, with MongoDB as its internal persistence store. Required third-party dependencies are Eclipse Ditto, PostgreSQL, Eclipse Mosquitto, MongoDB, Apache NiFi, Nginx, and Docker; Keycloak is optional and shipped in a separate compose file.

APIs & Interfaces

The backend exposes a REST API over HTTP on port 8000.

• Assets, lines, and transport: CRUD under /api/assets/, /api/manufacturing_lines/, and /api/transport/, including attribute/feature management and import/export
• Simulation and planning: /api/simulation/ runs discrete-event simulations; /api/planning/ manages saved simulation configurations and results
• Metrics and optimisation: /api/metrics/ for KPI definition and recalculation; /api/optimization/ to start and track optimisation runs
• Results: /api/results/ to store and export results as JSON/CSV
• Real-time and history: /api/events/ server-sent event stream for feature changes; /api/influx/ for historical data and statistics; /health for health checks

The web UI (Next.js/PrimeReact) offers four modules — Production Assets, Production Lines, KPI Dashboard, and Planning — with an asset definition form, a canvas-based production-line visual designer, and an interactive Gantt-based simulation results view.

User Interface

Representative screens of the DTD web interface in the first release:

Home page of the Digital Twins Designer — MaaSAI deliverable D10.1.

Production line visual designer — MaaSAI deliverable D10.1.

Simulation results view — MaaSAI deliverable D10.1.

Deployment & Configuration

The whole platform starts with a single Docker Compose command, with two profiles: production (docker-compose.yml) and development (docker-compose.dev.yml, with hot reload). All required components are included in the repository.

Requirement	Minimum	Recommended
CPU	4 cores	8+ cores
RAM	8 GB	16 GB (Ditto and NiFi are memory-intensive)
Storage	10 GB	50+ GB
OS	Any Docker-capable OS	Linux

Recommended values target production deployments. Ports 3000, 8000, 8081–8084, 8443, 1883, and 9001 must be available.