DAQ Simulator - Event Builder / Data Acquisition Simulator

Un simulateur de système DAQ (Data Acquisition) qui simule l'assemblage d'événements depuis plusieurs sources réseau.

Fonctionnalités

• Génération de fragments : N sources génèrent des fragments d'événements à débit configurable
• Simulation réseau : Latence, jitter et pertes de paquets configurables
• Event Builder : Assemblage de fragments par event_id avec gestion des timeouts
• Métriques : Latence (p50/p95/p99), débit, taux de pertes
• Prometheus : Export des métriques vers Prometheus
• Logs structurés : Support JSON pour l'observabilité

Structure du projet

daq-sim/
├── Cargo.toml
├── config.yaml          # Configuration par défaut
├── assets/
│   ├── architecture.svg # Diagramme d'architecture
│   ├── data-flow.svg    # Diagramme de flux de données
│   ├── DAQ-Simulateur.png # Image de présentation
│   └── metrics.png       # Capture d'écran des métriques
├── src/
│   ├── main.rs          # Point d'entrée
│   ├── config.rs        # Gestion de la configuration YAML
│   ├── model.rs         # Structures de données (Fragment, Event, etc.)
│   ├── source.rs        # Générateur de fragments
│   ├── link.rs          # Simulation réseau
│   ├── builder.rs       # Event Builder avec timeouts
│   ├── sink.rs          # Consommation des événements
│   └── metrics.rs       # Collecte de métriques
├── tests/
│   ├── builder_timeout.rs
│   └── reorder.rs
└── benches/
    └── builder_map.rs

Installation

Prérequis Windows (MSYS2)

Si MSYS2 est installé (recommandé) :

# Méthode simple avec script
.\run.ps1

# Ou manuellement, ajouter MSYS2 au PATH :
$env:Path = "C:\msys64\mingw64\bin;C:\msys64\ucrt64\bin;" + $env:Path
cargo build --release

Compilation

# Avec script (ajoute automatiquement MSYS2 au PATH)
.\build.ps1

# Ou manuellement
cargo build --release

Utilisation

Lancement rapide

# Avec script (recommandé)
.\run.ps1

# Ou manuellement
cargo run

Avec configuration par défaut

cargo run

Avec fichier de configuration personnalisé

cargo run -- --config my_config.yaml

Configuration

Le fichier config.yaml permet de configurer :

• sources : Nombre de sources, débit par source, taille des payloads
• network : Latence moyenne, jitter, probabilité de perte
• builder : Nombre de sources attendues, timeout d'événement, politique de drop
• metrics : Port Prometheus, format des logs

Exemple de configuration :

run_seconds: 30
seed: 42

sources:
  count: 8
  rate_hz_per_source: 5000
  payload_bytes:
    kind: uniform
    min: 200
    max: 1200

network:
  latency_ms_mean: 2.0
  latency_ms_jitter: 1.0
  drop_prob: 0.0005

builder:
  expected_sources: 8
  event_timeout_ms: 20
  max_inflight_events: 200000
  drop_policy: oldest

metrics:
  prometheus_port: 9898
  log_json: true

Métriques Prometheus

Le serveur Prometheus est accessible sur http://localhost:9898/metrics

Visualisation des métriques

Option 1 : Page HTML interactive (recommandé)

# Ouvrir la page de visualisation dans votre navigateur
Start-Process view-metrics.html

La page HTML affiche les métriques de manière interactive avec :

• Cartes visuelles pour les métriques importantes
• Actualisation automatique toutes les 5 secondes
• Format lisible (MB, ms, etc.)
• Métriques brutes en format Prometheus

Option 2 : Format texte brut

# Dans PowerShell
Invoke-WebRequest http://localhost:9898/metrics | Select-Object -ExpandProperty Content

# Ou dans un navigateur
http://localhost:9898/metrics

Métriques disponibles :

• fragments_in_total : Nombre total de fragments reçus
• fragments_dropped_total : Nombre de fragments perdus
• events_total{status} : Nombre d'événements par statut (complete/timeout/dropped/partial)
• event_latency_seconds : Histogramme de latence des événements
• throughput_bytes_total : Débit total en bytes
• inflight_events : Nombre d'événements en cours de traitement
• builder_queue_depth : Profondeur de la file du builder

Tests

cargo test

Benchmarks

cargo bench

Architecture

Le simulateur utilise Tokio pour l'asynchrone et les channels pour la communication entre composants :

1. Sources → génèrent des fragments et les envoient via un channel
2. Network Link → simule la latence/réseau et transmet les fragments
3. Event Builder → assemble les fragments par event_id avec timeouts
4. Sink → consomme les événements et met à jour les métriques

Tous les composants s'exécutent en parallèle via des tâches Tokio.

Modèles de données

Le diagramme ci-dessus montre les principaux modèles de données :

• Fragment : Contient event_id, source_id, seq, payload_bytes, et timestamps
• PartialEvent : État intermédiaire dans le builder avec un bitset (u128) pour tracker les sources reçues
• AssembledEvent : Événement final avec statut (Complete/Timeout/Partial/Dropped) et métadonnées

Le système utilise un bitset efficace pour vérifier si tous les fragments d'un événement ont été reçus, permettant une vérification O(1) de complétude.

Détails des modèles

Fragment : Unité de base générée par les sources. Chaque fragment appartient à un event_id et provient d'une source_id spécifique.

PartialEvent : État accumulatif dans le builder qui rassemble les fragments par event_id. Utilise un bitset u128 pour tracker quelles sources ont été reçues, permettant une vérification rapide de complétude.

AssembledEvent : Événement final produit par le builder. Contient le statut final (Complete, Timeout, Partial, ou Dropped) et les métriques de performance (latence, nombre de fragments, bytes totaux).

EventStatus : Enumération qui représente l'état final de l'événement :

• Complete : Tous les fragments reçus à temps
• Timeout : Timeout atteint avant complétion
• Dropped : Événement rejeté par backpressure ou perte réseau
• Partial : Fragments reçus mais événement incomplet

Dépendances principales

• tokio : Runtime asynchrone
• metrics + metrics-exporter-prometheus : Métriques Prometheus
• hdrhistogram : Histogrammes de latence haute précision
• serde + serde_yaml : Configuration YAML
• tracing : Logging structuré
• clap : Interface CLI
• rand : Génération aléatoire