Contrôle-commande sur le projet LISA
Claude-Alban RANÉLY-VERGÉ-DÉPRÉ, Mathieu DUPONT, Éric KAJFASZ
Le projet LISA
Laser Interferometer Space Antenna (LISA) : Antenne à ondes gravitationnelles
En lien avec la thématique “la physique des astroparticules et la cosmologie” de l’IN2P3
Projet européen ESA
En collaboration avec la NASA (?)
Le projet LISA
Laser Interferometer Space Antenna (LISA) : Antenne à ondes gravitationnelles
En lien avec la thématique “la physique des astroparticules et la cosmologie” de l’IN2P3
Projet européen ESA
En collaboration avec la NASA (?)
La part de la France
IDS : Interferometric Detection System
La part de la France
IDS : Interferometric Detection System
BSIM : Beam Simulator
Le périmètre de notre action
Le contrôle-commande des instruments du BSIM
Cahier des charges
- Plusieurs sous-systèmes à piloter
- Système distribué
- Système stable
Architecture
Retour d’expériences
I
II
III
Perspectives
Différents sous-systèmes indépendants
⇨ Binaires indépendants
Architecture de notre solution
Architecture distribuée
Protocole retenu : MQTT
- Architecture pub/sub
- Fonctionnalités avancées (QoS, Last Will)
- Ouvert
- Léger
Technologie retenue : JSON
Contenu des paquets
- Flexibilité des messages
- Pas de contraintes de taille pour les messages mais BSON est une option
- Facilement intégrable dans n’importe quel langage de programmation
{
"menu": {
"id": 1,
"value": true,
"popup": {
"menuitem": [
{ "value": "New", "onclick": "CreateNewDoc()" },
{ "value": "Open", "onclick": "OpenDoc()" },
{ "value": "Close", "onclick": "CloseDoc()" }
]
}
}
}Un format flexible avec aucune spécification c'est un mal de tête pour le prochain à s'en occuper
– Albert Einstein Un ingénieur fatigué
Spécifications des messages JSON
Lors de l'écriture de nos structures dans notre langage de programmation, on les génère
1
Génération
Lors de la réception des messages, on peut valider qu'il suit le bon schéma
2
Validation
Si le schéma doit changer c'est juste un seul endroit qui contient la source de vérité
3
Extensibilité
Spécifications des messages JSON
Lors de l'écriture de nos structures dans notre langage de programmation, on les génère
1
Génération
Lors de la réception des messages, on peut valider qu'il suit le bon schéma
2
Validation
Si le schéma doit changer c'est juste un seul endroit qui contient la source de vérité
3
Extensibilité
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"menu": {
"type": "object",
"properties": {
"id": {
"type": "integer"
},
"value": {
"type": "boolean"
},
"popup": {
"type": "object",
"properties": {
"menuitem": {
"type": "array",
"items": {
"type": "object",
"properties": {
"value": {
"type": "string"
},
"onclick": {
"type": "string"
}
},
"required": ["value", "onclick"]
}
}
},
"required": ["menuitem"]
}
},
"required": ["id", "value", "popup"]
}
},
"required": ["menu"]
}Architecture de notre solution
- Langage qui est mature (+10 ans depuis 1.0)
-
Intégration avec C facile
-
Multithreading sans bugs
-
Performances quasi-égale au C avec “une syntaxe plus proche de Python”
Le langage de programmation
Langage développé initialement à Mozilla dans le cadre de Firefox pour remplacer C++
"For medium and large changes, the rollback rate of Rust changes in Android is ~4x lower than C++"
(2025)
"we think that Rust represents the best alternative to C and C++ currently available."
(2019)
Études scientifiques de comparaison de langages
Pourquoi ce langage ?
- Pas de réalisation existante
- Stabilité
- Possibilité d'utiliser le même langage pour toutes les utilisations (Binaire, GUI déportée, Application Web)
- Interaction simple avec librairies constructeurs
(écrites en C)
{
"run_id": 0,
"timestamp": 1727790724,
"data": {
"temperature_one": {
"timestamp_fine": 1727790724,
"raw_value": 50,
"value": 20.4,
"unit": "C"
},
"temperature_two": {
"timestamp_fine": 1727790724,
"raw_value": 60,
"value": 20.6,
"unit": "C"
}
}
}#[derive(Debug, Deserialize, Serialize, JsonSchema)]
pub struct Message {
/// Date at which the message was sent
pub run_id: u64,
/// The number of non-leap nanoseconds since January 1,
/// 1970 0:00:00 UTC (aka “UNIX timestamp”)
/// in the current date, time and offset from UTC.
pub timestamp: i64,
/// The JSON encoded data retrieved from the tas
pub data: Measurements,
}
/// The named aggregation of the measurements made by the system
#[derive(Debug, Deserialize, Serialize, JsonSchema)]
pub struct Measurements {
/// The payload of the measurements made by the system
/// Using a BTreeMap here to be synchronized with `DataloggerSettings`
#[serde(flatten)]
pub data: BTreeMap<String, Vec<Measurement>>,
}
Exemple
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "Message",
"type": "object",
"properties": {
"data": {
"description": "The JSON encoded data retrieved from the tas",
"$ref": "#/$defs/Measurements"
},
"run_id": {
"description": "Date at which the message was sent",
"type": "integer",
"format": "uint64",
"minimum": 0
},
"timestamp": {
"description": "The number of non-leap nanoseconds since January 1, 1970 0:00:00 UTC (aka “UNIX timestamp”) in the current date, time and offset from UTC.",
"type": "integer",
"format": "int64"
}
},
"required": [
"run_id",
"timestamp",
"data"
],
"$defs": {
"Measurement": {
"description": "Physical measurement made by the system",
"type": "object",
"properties": {
"raw_value": {
"description": "Raw value sent by the test equipment",
"type": "number",
"format": "double"
},
"timestamp_fine": {
"type": "integer",
"format": "int64"
},
"unit": {
"$ref": "#/$defs/ThermodynamicTemperature"
},
"value": {
"type": "number",
"format": "double"
}
},
"required": [
"timestamp_fine",
"raw_value",
"value",
"unit"
]
},
}#[derive(Debug, Deserialize, Serialize, JsonSchema)]
pub struct Message {
/// Date at which the message was sent
pub run_id: u64,
/// The number of non-leap nanoseconds since January 1,
/// 1970 0:00:00 UTC (aka “UNIX timestamp”)
/// in the current date, time and offset from UTC.
pub timestamp: i64,
/// The JSON encoded data retrieved from the tas
pub data: Measurements,
}
/// The named aggregation of the measurements made by the system
#[derive(Debug, Deserialize, Serialize, JsonSchema)]
pub struct Measurements {
/// The payload of the measurements made by the system
/// Using a BTreeMap here to be synchronized with `DataloggerSettings`
#[serde(flatten)]
pub data: BTreeMap<String, Vec<Measurement>>,
}
Exemple
JSON Schema
Un choix souvent peu disponible
Notre choix s'est porté sur un système :
-
léger
-
peu intrusif
-
adaptable à nos besoins (open-source)
le système d'exploitation
Un composant en particulier : systemd
Un outil (système d'initialisation) qui permet de définir un ordre de démarrage pour les applications, tout en offrant de nombreux autres déclencheurs :
- service : pour un service/démon
- socket : pour une socket réseau (de tous types : UNIX, fichier …)
- mount : pour un système de fichiers (exemple : home.mount)
- swap : comme mount mais pour les partitions d’échanges
- automount : comme mount mais pour un système de fichiers monté à la demande
- device : pour un périphérique
- timer : pour l’activation basée sur une date
- path : pour l’activation basée sur des fichiers ou des répertoires
- target : macro-unité qui permet de grouper plusieurs unités
(exemple : multi-user.target pour définir une cible)
(liste non exhaustive)
Contruire une ISO personalisée d’une machine
Bonus # 1 : Fonctionnalités inattendues — systemd-mkosi
- Fichiers de configuration
- Binaires
- Mots de passe
- ...
Interessé(e) ?
Un gestionnaire de mise à jour
avec possibilité de retour en arrière atomique (partition A/B)
Bonus #2 : Fonctionnalités inattendues — systemd-sysupdate
Une version ratée ? Redémarrez votre appareil et c'est comme si rien ne s'était passé!
Interessé(e) ?
Conclusion
Merci!
Questions?
carvd@cppm.in2p3.fr
Journées Online 2025: Contrôle-commande sur le projet LISA
By Claude-Alban RANÉLY-VERGÉ-DÉPRÉ
Journées Online 2025: Contrôle-commande sur le projet LISA
Dans le cadre du projet LISA (Laser Interferometer Space Antenna), un banc de test rassemblant plusieurs instruments doit être produit par plusieurs partenaires du consortium. L'architecture logicielle retenue pour le contrôle-commande, dont le développement a été confié au CPPM, se compose de plusieurs briques logicielles peu conventionnelles associées entre elles : Le langage de programmation système Rust, Le protocole de messagerie publication-abonnement (publish-subscribe) basé sur le protocole TCP/IP, MQTT, Le système d'exploitation libre GNU/Linux La présentation fera un retour d'expériences sur l'usage de ces technologies prises séparément et de leurs synergies prises ensemble.
