Real-Time Mobility and Air Quality Insights
  Through an Edge-Enabled Digital Twin

Cities generate valuable information every second, but sending every raw message to a central cloud is costly and often unnecessary. Fujitsu’s ENACT pilot shows how a Digital Twin can preprocess data at the edge, run distributed stream analytics and turn mobility and environmental information into live, map-based insight.

AT A GLANCE

Why city data should not always travel to the cloud

Urban systems produce continuous streams of location and sensor data. Buses report their position, monitoring stations measure particulate matter, and weather services update local conditions. These data are useful only when they can be processed quickly enough to support decisions and presented in a form that people can understand.

A traditional architecture often sends most raw data to a central environment before cleaning, transforming and analyzing it. That approach is simple, but it creates avoidable network traffic, increases cloud storage and processing costs, and can add latency. Fujitsu’s pilot takes a different route: move part of the work closer to the source, then send only structured, relevant information into the main Digital Twin workflow.

Two services, one distributed data backbone

The pilot supports two practical urban applications. The first is public transport monitoring. Real-time vehicle locations are placed on a map alongside bus stops and timetable information, with the longer-term aim of showing expected arrivals and delays. Vehicle data may update every 20 to 30 seconds, while large timetable files are refreshed less frequently to avoid unnecessary processing.

The second application is air-quality monitoring. Measurements such as PM2.5 and PM10 are combined with weather information and smog data. The system calculates the current air-quality classification, highlights alerts and helps identify relationships between particulate levels, temperature, humidity, wind and other conditions. These insights can support future analysis of traffic patterns and environmental risk areas.

Integra presents real-time public transport and air-quality information through a shared map-based interface.

How the processing chain works

Data arrive from public APIs in different formats and at different frequencies. Kubernetes-managed Python scripts collect each source, remove invalid or unused fields, transform messages into the structure expected by the Digital Twin and send them to a Kafka topic. This preprocessing step reduces the amount of data that must be replicated and prepares the information for reliable stream processing.

The main analytics run through Apache Flink and Fujitsu’s Dracena technology, a plugin-based event-processing architecture. Different plugins handle public transport, air quality, weather and smog messages. New processing logic can be introduced through a control topic rather than rebuilding and redeploying the entire platform. Flink snapshots are stored in S3-compatible storage so that processing can resume from a known state after a failure.

The results are sent to Integra, Fujitsu’s web-based, map-oriented interface. Integra displays vehicles, monitoring stations and processed indicators, while also providing plugin and user management. Kafka, Flink, Dracena, MinIO, PostgreSQL and the visualisation layer together form the stable cloud workload; data gathering, preprocessing and selected Flink tasks can run on edge devices.

UC3 separates data collection and edge processing from the stable cloud workload and user interface.

ENACT as the intelligence behind placement and scaling

The key question is not simply whether a workload can run at the edge, but which workload should run on which node, under which conditions. ENACT addresses this through runtime policies that describe the requirements of the application. These policies can include CPU and memory, storage, bandwidth and latency, geographic preferences, encryption, GDPR constraints, energy consumption and the proportion of green energy available.

The Application Controller checks those policies and helps ensure that workloads are placed only on suitable nodes. The Orchestrator can request additional pods or nodes when the incoming data volume increases and scale them down when demand falls. Zero-Touch Provisioning supports the technical onboarding of edge nodes, while TDCME, OpenTelemetry and DGM collect and visualise metrics, logs, traces and relationships across the deployment.

For this use case, the most useful signals include the volume of data received, connection time, CPU and memory use by Flink tasks, and the length of unprocessed Kafka queues. Together, they provide the information needed to keep processing performance stable while using the smallest practical infrastructure footprint.

Early results from the experimentation environment

Several important parts of the workflow have already been tested. The preprocessing jobs successfully ingested public transport, weather and air-quality data at the same time, preserving message formats and timestamps and delivering acceptable throughput to Kafka. Dracena jobs were then launched through Apache Flink, downloaded their application artefact from ENACT’s MinIO storage, processed the input topics and wrote the expected outputs.

The team also tested real edge execution on a Raspberry Pi 4B with 4 GB of RAM. The Flink job and task pods running Dracena were scheduled on the ARM-based device, and end-to-end Kafka message processing was completed successfully. The test also exposed a practical constraint: the device did not have enough memory to run every preprocessing service at once, so some pods were returned to standard nodes. That is precisely the kind of evidence needed to tune placement policies and avoid treating all edge hardware as interchangeable.

Monitoring is already integrated across the pipeline. TDCME collects Prometheus metrics, OpenTelemetry instruments the preprocessing jobs, DGM displays the deployment topology, and Grafana dashboards provide real-time visibility into throughput, latency, resource use and component health. The geospatial plugins have also been validated through the correct display of buses and air-quality stations on the map.

What the pilot is designed to prove

The next experiments will focus on the areas that require the complete ENACT continuum: dynamic scaling, fault recovery and the optimization of how much data is processed at the edge rather than copied to the cloud. The project has defined ambitious targets that connect infrastructure decisions with measurable operational value.

VALIDATION AMBITIONS

A further objective is to maintain constant processing performance while the incoming volume changes. In practice, that means keeping Kafka backlogs stable, allocating enough Flink capacity to avoid delay, and scaling only when telemetry indicates that additional resources are justified.

What comes next

The pilot team will consolidate the deployment into a unified Helm chart, test the complete system on infrastructure containing multiple edge nodes, and validate recovery from Flink snapshots after forced interruption. Data preprocessing will be further optimised to meet the reduction target, and the sample runtime policies will be tuned against real hardware behaviour rather than theoretical specifications.

The broader value goes beyond the two applications shown here. The same architecture can support logistics fleets, environmental monitoring networks, utilities or other services that combine continuous sensor data with location and time. ENACT provides the means to decide where that data should be processed, Fujitsu’s Digital Twin turns it into a live model, and Integra makes the result visible.

By bringing together edge computing, stream processing and a map-based Digital Twin, UC3 shows how cities can move from collecting data to using it continuously – with less unnecessary transfer, better control over infrastructure and a clearer route from raw measurements to practical insight.