top of page
Search

What Is the Digital Twin in My Project?

  • Writer: Raffay Hassan
    Raffay Hassan
  • Feb 11
  • 2 min read

One of the most important conceptual clarifications in my final-year project was understanding that the Digital Twin is not a separate software application like CARLA, Unreal Engine, or a commercial industrial platform.

Instead, the Digital Twin is an architectural layer within the system.

This distinction is fundamental to understanding the contribution of the project.

Digital Twin ≠ Simulator

It is easy to assume that CARLA itself is the Digital Twin, since it provides:

  • A 3D virtual environment

  • Vehicle simulation

  • Sensor simulation

  • Real-time visualisation

However, CARLA is a simulation engine. It generates scenarios and visualises environments, but it does not maintain an independent, sensor-driven, persistent world model based on real observations.

The Digital Twin in this project is something different.

So What Is the Digital Twin?

In this project, the Digital Twin is:

A continuously updated software-based world model that represents a physical road environment using interpreted sensor data.

It exists as structured logic inside the system, not as a separate external program.

It maintains:

  • Detected object positions

  • Obstruction markers

  • Time-stamped hazard memory

  • Confidence values

  • Risk assessments

  • Time-To-Collision estimations

This internal world state mirrors the physical environment and evolves over time as new sensor data arrives.

Where the Digital Twin Lives

The Digital Twin is implemented within the central GPU server as part of the core project codebase.

Conceptually, it can be represented as:

Digital Twin
 ├── World State
 ├── Object Registry
 ├── Hazard Memory
 ├── Timestamp Synchronisation
 └── Safety Evaluation Logic

It is updated by:

  • YOLO detections (Jetson Nano)

  • LiDAR distance measurements

  • Radar velocity readings

  • Simulated sensor data from CARLA (when in simulation mode)

The twin is therefore independent of the source of the data.

Why It Is Still a Digital Twin

A system qualifies as a Digital Twin when:

  1. It mirrors a physical system.

  2. It updates continuously from real data.

  3. It maintains temporal state (memory).

  4. It supports predictive reasoning.

This project satisfies all four criteria.

The twin is not just a static map. It evolves dynamically and enables predictive safety evaluation rather than purely reactive perception.

Relationship Between CARLA and the Digital Twin

The system architecture can be summarised as:

Sensors (Real or Simulated)
        ↓
Perception & Fusion
        ↓
Digital Twin (World Model + Memory)
        ↓
CARLA (Visualisation & Scenario Testing)

CARLA visualises the environment and provides controlled testing scenarios.

The Digital Twin performs the reasoning.

This separation ensures modularity and highlights the true innovation of the project.

Why This Architectural Choice Matters

By implementing the Digital Twin as a modular software layer rather than relying on a simulation platform:

  • The system remains adaptable to different simulators.

  • The architecture remains scalable.

  • The core contribution remains research-focused.

  • The digital twin becomes the primary intellectual component.

The project therefore does not aim to build a simulator. It aims to build an intelligent environment model driven by multi-sensor perception.

Final Perspective

The Digital Twin in this project is not a commercial platform, nor a standalone program.

It is a structured, continuously updated representation of a physical environment embedded within the system architecture.

CARLA provides the environment.

Sensors provide the observations.

The Digital Twin provides the intelligence.

 
 
 

Comments


  • LinkedIn

The Burroughs, London

NW4 4BT

Autonomous Systems, Sensor Fusion, Digital Twins

 

© 2026 by Department of Science and Technology

 

bottom of page