Infrastructure IT & Réseau

Les VLANs (Virtual Local Area Networks) permettent de segmenter logiquement un réseau physique unique en plusieurs réseaux isolés. En simulateur militaire :

• VLAN 100 — Temps réel DIS/HLA : trafic simulation uniquement. QoS priorité maximale (DSCP EF — Expedited Forwarding). Aucun autre trafic autorisé.
• VLAN 200 — Gestion IOS : accès instructeur, monitoring en temps réel des paramètres, injection de pannes.
• VLAN 300 — Maintenance : accès restreint par liste de contrôle d'accès (ACL). Journaux d'accès obligatoires.
• VLAN 400 — Voix/Interphone : communications radio simulées, interphone cockpit-IOS, audio de simulation.

Les switches doivent être managés (configuration VLAN, QoS, spanning tree). Des switches industriels à faible latence sont utilisés (ex : Cisco Industrial, Hirschmann, Belden). Le temps de traversée d'un switch doit être <5 µs (microseconde) pour le trafic temps réel.

# Exemple de config VLAN (Cisco IOS)
interface GigabitEthernet0/1
 description Calculateur_RT_1
 switchport mode access
 switchport access vlan 100
 spanning-tree portfast
 no shutdown

interface GigabitEthernet0/10
 description IOS_Station
 switchport mode access
 switchport access vlan 200

interface GigabitEthernet0/24
 description Trunk_vers_core
 switchport mode trunk
 switchport trunk allowed vlan 100,200,300,400

! QoS : priorité VLAN RT
class-map match-all REALTIME
 match vlan 100
policy-map SIM-QOS
 class REALTIME
  priority percent 60

DIS est le standard de simulation distribuée interopérable. Il permet à des simulateurs de constructeurs différents d'interagir en réseau comme si les entités simulées évoluaient dans le même espace.

Principe : chaque simulateur publie l'état de ses entités (avions, véhicules, missiles) sous forme de PDUs (Protocol Data Units) diffusés en multicast UDP sur le réseau.

PDUs principaux

• Entity State PDU : position (X,Y,Z), orientation (psi, theta, phi), vitesse, accélération, état de l'entité. Émis toutes les 5 secondes ou à chaque changement significatif (Dead Reckoning).
• Fire PDU : événement de tir (qui tire, quelle cible, quel armement, depuis quelle position).
• Detonation PDU : impact ou explosion (résultat d'un tir).
• Collision PDU : collision entre entités.
• Signal PDU : transmission radio simulée.
• Electromagnetic Emission PDU : émissions radar, brouillage.

PDU Header (12 octets)
├─ Protocol Version : DIS 6 / DIS 7
├─ PDU Type : 1 (Entity State)
├─ Length : longueur totale
└─ Timestamp : 32 bits

Entity Identifier
├─ Site ID, Application ID
└─ Entity ID (unique)

Entity Type
├─ Kind (avion, missile…)
├─ Domain (air, terre, mer…)
├─ Country (STANAG)
└─ Category, Subcategory

Location (World Coordinates)
├─ X, Y, Z (géocentrique ECEF)
└─ Double précision (64 bits)

Velocity : vx, vy, vz
Orientation : psi, theta, phi
Dead Reckoning (extrapolation)
Entity Appearance (état)

DIS utilise UDP port 3000 par défaut, groupe multicast 224.0.0.1 (ou configurable). Pas de garantie de livraison — les pertes de paquets sont tolérées (la suivante arrive dans 5ms).

HLA est le successeur de DIS pour les simulations complexes de grande échelle (armée entière, exercice multinational). Plus flexible et plus riche que DIS.

Concepts clés :

• Fédération : ensemble de simulateurs (fédérés) collaborant dans un exercice.
• Fédéré : un simulateur individuel (ex : simulateur Rafale, simulateur radar sol, simulateur logistique).
• RTI — Runtime Infrastructure : middleware qui gère les communications entre fédérés. Équivalent HLA du réseau DIS. Ex : Pitch pRTI, VT MAK RTI.
• FOM — Federation Object Model : schéma XML définissant les classes d'objets échangés (avion, missile, radar, météo…) et leurs attributs.
• Time Management : HLA gère la synchronisation temporelle des fédérés, permettant des simulations plus lentes ou plus rapides que le temps réel.

Le multicast IP permet d'envoyer un paquet à un groupe de destinataires simultanément, sans dupliquer le trafic sur le lien source (contrairement au broadcast ou à l'unicast répété).

• Plage multicast IPv4 : 224.0.0.0 à 239.255.255.255
• Multicast local (lien) : 224.0.0.x (non routé)
• Multicast administratif (simulateur) : 239.0.0.0/8 (administrativement scopé, routable en interne)
• Inscription au groupe : protocole IGMP (IGMPv3 recommandé)
• Switch multicast : IGMP Snooping activé pour éviter d'inonder tous les ports

# Rejoindre un groupe multicast DIS (Python)
import socket, struct

MCAST_GRP = '239.0.0.1'
MCAST_PORT = 3000

sock = socket.socket(
    socket.AF_INET,
    socket.SOCK_DGRAM,
    socket.IPPROTO_UDP
)
sock.setsockopt(
    socket.SOL_SOCKET,
    socket.SO_REUSEADDR, 1
)
sock.bind(('', MCAST_PORT))

# Rejoindre le groupe multicast
mreq = struct.pack(
    '4sL',
    socket.inet_aton(MCAST_GRP),
    socket.INADDR_ANY
)
sock.setsockopt(
    socket.IPPROTO_IP,
    socket.IP_ADD_MEMBERSHIP,
    mreq
)

while True:
    data, addr = sock.recvfrom(65535)
    # Parser le PDU DIS reçu
    pdu_type = data[2]
    print(f"PDU type {pdu_type} de {addr}")

• NTP (Network Time Protocol) : précision ~1 ms sur LAN. Insuffisant pour les simulateurs haute fidélité (jitter perceptible).
• PTP/IEEE 1588 : précision sub-microseconde (<100 ns sur LAN avec hardware timestamping). Standard pour la simulation militaire.
• Modes PTP : BC (Boundary Clock), TC (Transparent Clock), OC (Ordinary Clock). Les switches doivent supporter PTP pour éviter l'accumulation de latence.
• Implémentations : linuxptp (Linux), Windows Time Service (moins précis), cartes NI avec hardware PTP.

Ces serveurs exécutent le modèle de vol, le modèle moteur et l'avionique en temps réel strict. Ils sont au cœur du simulateur.

• OS : VxWorks 7 (Wind River) ou QNX Neutrino 8. RTOS certifiés pour le temps réel strict. Pas de Windows ni Linux standard (latence non déterministe).
• CPU : Intel Xeon haute fréquence (priorité à la fréquence pour les tâches single-thread temps réel), ~3.5–5 GHz.
• RAM : ECC obligatoire (Error-Correcting Code) — une erreur mémoire non corrigée = panne simulation → ECC détecte et corrige.
• Stockage : SSD NVMe pour le démarrage rapide. Les données temps réel sont en RAM (pas d'accès disque en boucle temps réel).
• NIC temps réel : cartes réseau avec hardware timestamping PTP (Intel X710, Solarflare) et faible latence (<1 µs).

OS classique (Windows, Linux)

• Scheduler best-effort : le CPU est alloué de façon "équitable" entre les processus.
• Latences variables : une tâche peut être bloquée pendant 10–100 ms par le kernel (garbage collector, I/O, interruptions matérielles).
• Mémoire virtuelle : swap vers disque possible → latence imprévisible (page fault).
• Usage simulateur : IOS, bases de données, gestion (là où quelques ms de délai sont acceptables).

RTOS (VxWorks, QNX)

• Scheduler prioritaire préemptif : une tâche haute priorité prend immédiatement le CPU, sans attendre.
• Latence garantie : le délai maximal entre un événement et sa réponse est borné et prévisible (<10 µs typique).
• Pas de swap : mémoire entièrement résidente (mlockall). Pas de page fault.
• Tâches temps réel : chaque tâche a une priorité fixe. La tâche de modèle de vol tourne à la priorité la plus haute, jamais interrompue.
• Usage simulateur : modèle de vol (1kHz), contrôle actionneurs, acquisition capteurs.