La modernisation des réseaux ferroviaires et métropolitains repose aujourd’hui largement sur des systèmes de signalisation avancés, capables de répondre à des exigences croissantes en matière de sécurité, de capacité et de disponibilité. Parmi ces technologies, le CBTC (Communication Based Train Control) s’impose comme une référence incontournable.

Déployé sur de nombreuses lignes de métro automatiques ou semi‑automatiques à travers le monde, le CBTC permet d’optimiser l’exploitation tout en garantissant un niveau de sûreté extrêmement élevé. Cependant, derrière ces performances se cache une complexité technique importante, en particulier sur les aspects logiciels critiques développés selon la norme EN 50128 / 50716), le plus souvent au niveau de sûreté Safety Integrity Level 4 (SIL4).

Dans ce billet, nous proposons un panorama complet du CBTC : ses principes, son architecture, ses bénéfices, mais aussi les défis liés au développement de logiciels sécuritaires pour ce type de système.

Le CBTC : principes fondamentaux¶

Le CBTC est un système de contrôle‑commande ferroviaire reposant sur une communication continue et bidirectionnelle entre les trains et les équipements au sol. Contrairement aux systèmes de signalisation conventionnels, basés sur des blocs fixes et des circuits de voie, le CBTC s’appuie sur une connaissance précise et dynamique de la position et de l’état des trains.

Les fonctions clés assurées par un système CBTC sont généralement :

Automatic Train Protection (ATP) : protection automatique des trains, garantissant le respect des vitesses maximales et des distances de sécurité ;
Automatic Train Operation (ATO) : automatisation partielle ou complète de la conduite (accélération, freinage, arrêt en station) ;
Automatic Train Supervision (ATS) : supervision globale du trafic et gestion des incidents.

Le cœur du CBTC réside dans sa capacité à calculer en temps réel des autorisations de mouvement adaptées à chaque train, sur la base d’informations continuellement mises à jour.

Du cantonnement fixe au « moving block »¶

Les systèmes de signalisation traditionnels reposent sur le principe du cantonnement fixe. La voie est découpée en sections physiques rigides : un train ne peut entrer dans un canton que lorsque le train précédent l’a entièrement libéré. Comme l’indique la première ligne du schéma ci-dessous, la limite de l’Autorisation de Mouvement (ou MAL pour Movement Authorization Limit), matérialisée par la barre rouge, reste figée à l’entrée du canton tant que le train de tête n’en est pas totalement sorti. Ce modèle, bien que robuste, laisse un grand espace vide “gâché” derrière la première rame et limite fortement la capacité de la ligne.

Exemple de fonctionnement avec les différents types de cantonnement

Pour briser cette contrainte et resserrer les intervalles, la technologie CBTC fait migrer informatiquement cette MAL (notre barre rouge) vers la droite, selon deux approches :

Le cantonnement virtuel fixe (Ligne 2) : Solution intermédiaire ou hybride, l’infrastructure physique au sol s’efface au profit d’un découpage numérique de la voie en sous-sections beaucoup plus courtes (cantons virtuels). Grâce à la communication bidirectionnelle Train-Sol, le système valide la libération de ces mini-cantons au fur et à mesure. La MAL progresse ainsi par “sauts” successifs, permettant au train suiveur de grappiller du terrain et de se rapprocher.
Le cantonnement mobile ou moving block (Ligne 3) : C’est la rupture technologique intégrale. Le concept même de bloc (physique ou virtuel) disparaît. La MAL n’est plus contrainte par des frontières géométriques figées, mais devient un point dynamique calculé en temps réel. Elle se positionne exactement à l’arrière d’une zone de protection mobile (l’enveloppe de sécurité) qui escorte le train de tête.

Dans ce mode de fonctionnement en moving block, la distance de sécurité entre deux rames est calculée en continu par l’embarqué et dépend de paramètres réels et instantanés :

La vitesse des trains ;
Leurs performances réelles de freinage ;
Le profil et l’état de la voie.

Architecture typique d’un système CBTC¶

Un système CBTC repose sur une architecture distribuée, généralement composée de plusieurs sous‑systèmes critiques.

Architecture fonctionnelle typique d’un système CBTC montrant les interactions entre équipements embarqués, équipements sols et supervision centrale.

Équipements embarqués ou Pilote Automatique Embarqué (PAE)¶

Les équipements embarqués sont installés à bord des trains. Ils assurent notamment :

le calcul de la position et de la vitesse du train ;
l’exécution des fonctions ATP critiques ;
l’interface avec les systèmes ATO et les actionneurs (freinage, traction).

Ces calculateurs embarqués exécutent des logiciels de niveau de sûreté élevé, très souvent SIL4, car ils interviennent directement dans la protection du mouvement des trains.

Système Sol CBTC ou Pilote Automatique Sol (PAS)¶

Les systèmes au sol (wayside en anglais) sont chargés de :

gérer des zones ou des sections de ligne ;
coordonner les mouvements de plusieurs trains ;
interfacer le CBTC avec l’infrastructure existante (aiguillages, portes palières, énergie, etc.).

Ils jouent un rôle clé dans la cohérence globale du système et dans la gestion des situations dégradées. Tout comme l’ATP embarqué, le Zone Controller (ZC) est un composant critique généralement certifié SIL4, car il garantit l’intégrité des autorisations de mouvement délivrées aux trains.

Il existe toutefois des architectures de CBTC émergentes qui rompent avec ce modèle traditionnel en adoptant une approche dite “Train-Centric” (ou Vehicle-Centric).

C’est le cas par exemple de la solution Urbalis Fluence d’Alstom. Dans ce système, la majeure partie de l’intelligence est transférée directement dans les équipements embarqués. Les trains communiquent directement entre eux, s’affranchissant ainsi du Contrôleur de zone central classique et réduisant les équipements physiques au sol au profit de simples contrôleurs d’objets à la voie.

Réseau de communication¶

La communication est un élément central du CBTC. Elle repose généralement sur :

des liaisons radio sécurisées (Wi‑Fi industriel, LTE, solutions propriétaires) ;
des mécanismes de redondance et de tolérance aux pannes ;
des protocoles garantissant l’intégrité, l’authenticité et la fraîcheur des données.

La perte ou la dégradation de la communication est systématiquement prise en compte dans la logique de sûreté, avec des stratégies de repli sûres.

Supervision centrale¶

Un système de supervision central permet :

le suivi en temps réel de l’exploitation ;
l’aide à la régulation du trafic ;
l’analyse post‑incident et la maintenance.

Les bénéfices opérationnels du CBTC¶

L’adoption du CBTC apporte des gains mesurables pour les exploitants et les autorités organisatrices.

Sécurité continue et maitrise des incidents¶

Le CBTC maintient le niveau de sécurité critique maximal du cantonnement fixe (SIL4), mais en modifie la philosophie. Par opposition aux supervisions ponctuelles antérieures, grâce à sa communication bidirectionnelle redondée et continue, le système offre un contrôle optimisé, une meilleure tolérance aux pannes et une réactivité immédiate pour circonscrire les incidents d’exploitation au plus vite.

Capacité et performance accrues¶

Le gain dépend du système de référence. Par rapport à une signalisation latérale classique, l’augmentation de capacité et performance est flagrante.

Face à des systèmes de génération précédente (type PA135 ou SACEM), le gain de temps (déjà proche des 90s d’intervalle) est plus marginal. En revanche, le gain en disponibilité est important grâce à la redondance.

Le vrai plus : la souplesse¶

Contrairement au PA135 où la performance est figée par l’infrastructure (tapis) et calée sur le train le moins performant, le CBTC permet à chaque classe de train d’utiliser son propre paramétrage.

Les calculs sont faits par l’embarqué pour optimiser la performance sans compromis sur la sécurité.

Flexibilité d’exploitation¶

Le CBTC s’adapte plus facilement aux extensions de ligne, aux changements d’horaires ou aux évolutions de matériel roulant. En effet, la facilité d’évolution vient de la généricité du logiciel et des processus de dataprep (préparation de données).

Modifier une ligne ne nécessite plus de lourds travaux sur la voie (pas de reprise de tapis), mais une mise à jour de la configuration logicielle (cantonnement virtuel ou mobile).

Cette souplesse constitue un atout maître lors des phases de migration : le CBTC est capable de tolérer la circulation de rames non équipées, permettant une cohabitation fluide entre anciens et nouveaux matériels.

Ce scénario de transition reste toutefois conditionné par la philosophie du système historique : il faut que ce dernier accepte la présence de trains hors de son contrôle direct (une cohabitation tout à fait possible avec un système comme le PA135, mais techniquement impossible sur un modèle intrinsèquement clos comme le VAL)

Support de l’automatisation¶

Le CBTC est un socle technologique essentiel pour les métros automatiques (GoA2 à GoA4), aujourd’hui largement déployés dans les grandes métropoles.

Développement logiciel CBTC et norme EN 50128 / 50716¶

Le logiciel est au cœur du CBTC. Il conditionne directement le niveau de sécurité du système et doit répondre à des exigences réglementaires strictes.

Les normes EN 50128 / 50716¶

La norme EN 50128 et sa remplaçante, la norme 50716 définissent les exigences applicables au développement de logiciels pour les systèmes ferroviaires de sécurité.

L’une comme l’autre imposent :

un cycle de vie structuré ;
une traçabilité complète des exigences ;
des activités de vérification et de validation adaptées au niveau de sûreté.

Le niveau SIL4 correspond au niveau le plus exigeant, avec une probabilité de défaillance extrêmement faible.

Historiquement centrée sur les logiciels de signalisation ferroviaire, la norme EN 50128 a récemment évolué vers la série EN 50716. Cette évolution vise à mieux intégrer les pratiques modernes de développement logiciel, telles que les architectures distribuées, l’usage accru d’outils logiciels complexes et les nouvelles approches d’ingénierie. Elle s’inscrit dans une continuité de la 50128, en conservant des exigences de sûreté élevées tout en apportant davantage de clarté et de cohérence avec les normes système associées.

Cycle de développement logiciel conforme EN 50128 / 50716 pour des applications CBTC de niveau de sûreté SIL4.

Le Cycle de développement logiciel décrit dans la norme EN 50716 permet de sortir du standard connu et d’insérer des itérations afin de construire de manière incrémentale les produits attendus.

Enjeux spécifiques au SIL4¶

Développer un logiciel CBTC SIL4 implique notamment :

des architectures logicielles robustes et déterministes ;
la possibilité d’utiliser les méthodes formelles ou semi‑formelles qui sont particulièrement adaptées aux exigences de ces normes pour le SIL4, bien que d’autres approches de démonstration de sécurité soient possibles ;
des stratégies de test intensives (tests unitaires, d’intégration, de robustesse) ;
des revues indépendantes et une gestion rigoureuse des configurations.

Défis techniques et retours d’expérience¶

Malgré ses avantages reconnus, le déploiement d’un système CBTC pose plusieurs défis techniques majeurs. Si les problématiques de transmission sont critiques, la complexité des logiciels est également avérée avec une densification des fonctions, sans oublier la problématique de maitrise industrielle des données de configuration.

Les défis historiques de l’architecture système

La gestion des communications intermittentes : Assurer la continuité du service et le maintien de la sécurité malgré les masquages radio, les commutations de bornes (handovers) ou les pertes temporaires de liaison sol-train.
La démonstration de sûreté dans des architectures distribuées : Justifier le niveau de sécurité requis (généralement SIL4) sur des systèmes complexes où l’intelligence est répartie entre des calculateurs sol, des équipements embarqués et des réseaux de communication hétérogènes.
La validation du comportement en situation dégradée : Modéliser et tester la réaction du système face à la multitude d’aléas de l’exploitation réelle (pannes d’aiguilles, perte de localisation d’une rame, intrusion sur les voies, etc.).

Le défi de la généricité et de la configuration par les données (Dataprep)

Au-delà de ces aspects opérationnels, l’une des clés majeures du succès d’un CBTC moderne repose sur la maturité de son process d’instanciation : la conception d’un logiciel noyau générique (le “produit”), destiné à être configuré sur la topologie et les règles d’exploitation spécifiques d’un projet donné grâce à une configuration par les données.

Cette approche introduit des défis d’ingénierie cruciaux qui conditionnent la réussite d’un projet :

Un levier majeur de vélocité : La maîtrise de la chaîne de préparation des données (dataprep) est le facteur clé pour accélérer les phases de mise au point sur site. Pouvoir ajuster la position d’un repère virtuel, modifier un profil de pente ou adapter une zone de vitesse par une simple mise à jour de la base de données — sans altérer le code source critique du système — est indispensable pour sécuriser les plannings de mise en service.
Une transformation de la stratégie de validation : Découpler le logiciel des données déplace la complexité des essais. Les équipes de validation et de sûreté de fonctionnement doivent alors arbitrer entre deux philosophies de test :
- La configuration “Cauchemar” (Nightmare Configuration) : Créer une base de données théorique « extrême », cumulant le plus grand nombre raisonnable de configurations topologiques et les pires scénarios d’exploitation, afin de pousser le logiciel générique dans ses retranchements et le valider en profondeur une fois pour toutes.
- La validation systématique : Tester intégralement chaque instance spécifique de chaque ligne, une approche hautement chronophage mais parfois imposée par les spécificités locales.
L’industrialisation des tests par l’automatisation : Face au volume de données à vérifier, la vélocité repose sur la capacité à déployer des plateformes de simulation ou de preuves capables d’automatiser massivement les activités de validation. Ces bancs de validation permettent de solliciter le fonctionnel avec les données de signalisation en usine, réduisant ainsi drastiquement le besoin d’essais dynamiques sur les voies.
La bonne maitrise du récolement : un des enjeux de l’approche « générique configuré par les données » réside dans la fidélité des données à la réalité du terrain. Cette dimension est couverte par une activité de métrologie permettant de relever la position d’un certain nombre d’objets sur la voie (des points de référence) et les distances relatives d’autres objets par rapport aux objets de référence. La cohérence des différentes passes de mesures entre elles et la cohérence des données de configuration décrivant le résultat de ce relevé peuvent être outillés par des méthodes formelles automatisant ainsi ces analyses critiques.

Ces défis interconnectés nécessitent une approche rigoureuse, combinant une ingénierie système de pointe, une culture forte de la sûreté de fonctionnement et une expertise logicielle industrielle.

Conclusion¶

Le CBTC est aujourd’hui un pilier de la signalisation ferroviaire moderne. Il permet de concilier haute performance opérationnelle et exigences de sécurité extrêmement strictes. Pour les entreprises spécialisées dans le développement de logiciels sécuritaires, la maîtrise du SIL4 selon EN 50128 / 50716 est un facteur clé de différenciation et de confiance vis‑à‑vis des grands industriels du secteur.

L’évolution du CBTC voit apparaître de nouveaux paradigmes comme l’approche ‘Train-Centric’. transférant la complexité du sol au bord pour une infrastructure sol allégée.

À mesure que les réseaux évoluent vers toujours plus d’automatisation, le CBTC continuera d’évoluer, plaçant plus que jamais le logiciel sécurisé au cœur des systèmes ferroviaires critiques.

Systerel se positionne en tant que PME experte en développements sécuritaires, jouant un rôle clé dans l’écosystème CBTC.

Elle apporte :

une expertise pointue sur le référentiel CENELEC ;
une capacité à développer des composants critiques certifiables ;
une collaboration étroite avec des acteurs majeurs comme Alstom, Hitachi et Siemens ou des gestionnaires d’infrastructures comme RATP et SNCF.