ENIB S3-PRG-Rust 02_Auto - Système automatisé

{} Utilisation d'un simulateur

{} Choix de l'équipement à interroger

Comme cela sera découvert dans la matière “Automatismes”, lorsqu'un automate programmable industriel doit partager des données avec les équipements environnants, il les prépare dans un espace mémoire pouvant être accédé par le protocole Modbus.
Plusieurs moyens de communication existent pour transporter les données de ce protocole ; dans le cadre de ce projet il s'agira d'interroger l'automate sur son port 502-TCP.
Il pourrait tout à fait s'agir d'un autre numéro de port ; notamment, pour travailler avec le simulateur, nous utiliserons le port 5502-TCP✍.
Le programme à réaliser doit donc être en mesure de choisir l'équipement auquel il se connecte (un automate parmi plusieurs, le simulateur...) et le numéro de port TCP à solliciter sur cet équipement.

Pour débuter cette réalisation, il faut créer une crate nommée modbus_client.
En s'inspirant de ce qui a été expérimenté dans cette section, le programme doit accepter deux arguments sur sa ligne de commande :

le premier représente le nom de l'équipement✍
Le terme approprié en matière de réseaux est un “nom de domaine”, comme www.enib.fr par exemple.
Il peut également s'agir d'une adresse IP exprimée littéralement, comme 195.221.233.6 ou 127.0.0.1 par exemple.
; il s'agit d'une chaîne de caractères,
le deuxième représente le numéro du port TCP à solliciter sur cet équipement ; il s'agit d'un entier non-signé de 16 bits (u16).

Par confort✍, il faudra considérer que :

le numéro de port sera 5502 s'il n'est pas indiqué sur la ligne de commande,
le nom de l'équipement sera "127.0.0.1" s'il n'est pas non plus indiqué sur la ligne de commande.

Si les arguments de la ligne de commande n'ont pas la forme attendue, le programme devra se terminer en fournissant une erreur explicite.

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.

{} Connexion à l'équipement

{} Lecture de l'équipement

Le protocole Modbus prévoit d'exposer quatre ensembles de données sur l'équipement :

les “coils” : des bits individuels en lecture-écriture,
les “discrete inputs” : des bits individuels en lecture-seule,
les “input registers” : des entiers non-signés de 16 bits en lecture-seule,
les “holding registers” : des entiers non-signés de 16 bits en lecture-écriture.

Dans chacun de ces ensembles, l'emplacement d'une donnée est désigné par une adresse : un entier non-signé de 16 bits.
Le protocole prévoit de les lire ou de les écrire :

individuellement, en spécifiant une adresse,
en bloc, en spécifiant une adresse et le nombre d'éléments contigus à transférer à partir de cette adresse.

Toutefois, l'automate programmable industriel qui sera interrogé n'expose que les données des catégories “coils” et “holding registers”.
Par conséquent, le simulateur se contente également des ces deux catégories, comme indiqué par les messages qu'il affiche lors de son démarrage.

Pour les obtenir, il faut utiliser les fonctions read_coils() et read_holding_registers() du Transport obtenu précédemment.
L'adresse sera 0 dans les deux cas, mais le nombre d'éléments à récupérer dépendra de l'équipement visé✍ :

le simulateur expose 20 “coils” et 5 “holding registers”,
l'automate expose 256 “coils” et 125 “holding registers”.

Remarquez que ces fonctions sont susceptibles de reporter une erreur ; le cas échéant, le programme devra se terminer en la transmettant.

L'affichage de débogage permettra de visualiser les vectors obtenus.
Remarquez que les bits des “coils” sont affichés de manière très verbeuse.
Par confort, il faudra réaliser une fonction qui produit une chaîne de caractères bien plus compacte et lisible à partir d'une slice partagée (non-mutable) de modbus::Coils, en utilisant le caractère '_' pour la valeur Off et le caractère '•' pour la valeur On, par exemple✍.
Dans ces conditions, l'affichage des deux ensembles de données obtenus depuis le simulateur pourrait être semblable à ceci :

__•___••••••••______ [748, 374, 249, 187, 149]

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.

{} Surveillance de l'équipement

Puisqu'il est désormais possible de recueillir les données de l'équipement, il devient envisageable de les surveiller pendant une certaine durée et de signaler chaque changement d'état✍.

Cette fonction sera utile pour surveiller le temps écoulé.

fn now_utc_ms() -> Result<u64, Box<dyn std::error::Error>> {
    let now =
        std::time::SystemTime::now().duration_since(std::time::UNIX_EPOCH)?;
    Ok(now.as_millis() as u64)
}

Elle interroge le système d'exploitation pour déterminer le nombre de millisecondes écoulées depuis le premier janvier 1970 à minuit en temps universel.

Le programme doit être complété par une boucle qui se termine après 20 secondes✍.
Dans cette boucle, il faudra obtenir les données de l'équipement (comme précédemment) et les comparer aux valeurs obtenues à l'itération précédente.
Si des différences existent, les données doivent être affichées et mémorisées pour préparer la comparaison qui aura lieu à l'itération suivante.

Exemple d'affichage produit

...
•_____••____________ [871, 435, 290, 217, 174]
_•____•••___________ [871, 435, 290, 217, 174]
_•____•••___________ [872, 436, 290, 218, 174]
__•___••••__________ [872, 436, 290, 218, 174]
___•__•••••_________ [873, 436, 291, 218, 174]
___•__•••••_________ [874, 437, 291, 218, 174]
____•_••••••________ [874, 437, 291, 218, 174]
_____••••••••_______ [875, 437, 291, 218, 175]
_____••••••••_______ [876, 438, 292, 219, 175]
____•_••••••••______ [876, 438, 292, 219, 175]
____•_••••••••______ [877, 438, 292, 219, 175]
___•__•••••••••_____ [877, 438, 292, 219, 175]
___•__•••••••••_____ [878, 439, 292, 219, 175]
__•___••••••••••____ [878, 439, 292, 219, 175]
_•____•••••••••••___ [879, 439, 293, 219, 175]
•_____••••••••••••__ [880, 440, 293, 220, 176]
•_____••••••••••••__ [881, 440, 293, 220, 176]
_•____•••••••••••••_ [881, 440, 293, 220, 176]
__•___•••••••••••••• [882, 441, 294, 220, 176]
___•__•••••••••••••_ [883, 441, 294, 220, 176]
____•_••••••••••••__ [884, 442, 294, 221, 176]
_____••••••••••••___ [885, 442, 295, 221, 177]
_____••••••••••••___ [886, 443, 295, 221, 177]
____•_••••••••••____ [886, 443, 295, 221, 177]
___•__•••••••••_____ [887, 443, 295, 221, 177]
___•__•••••••••_____ [888, 444, 296, 222, 177]
__•___••••••••______ [888, 444, 296, 222, 177]
...

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.

{} Réduction de la charge de travail

À son démarrage, le simulateur annonce qu'il fera évoluer son état toutes les 100 millisecondes.
Dans ces conditions, notre programme consacre énormément de ressources à répéter inutilement une boucle qui à chaque itération communique avec le simulateur pour finalement obtenir quasiment toujours les mêmes données.
Cette démarche n'est pas du tout sobre !

Il est possible de réduire considérablement la charge de travail en mettant notre programme au repos pendant de longues périodes.
Pour économiser les ressources, à chaque itération, il s'agit de suspendre notre programme pendant 50 millisecondes, ce qui est largement suffisant pour réagir raisonnablement aux changements d'états du simulateur✍.

Pour vérifier qu'aucun changement d'état du simulateur n'est manqué, malgré les périodes de repos du programme, il suffit de s'intéresser à la donnée fournie à l'adresse 0 des “holding registers”.
Le simulateur l'utilise comme un compteur qu'il incrémente à chaque modification de son état.
À chaque fois que le programme constate un changement dans les données obtenues et décide de les afficher, il suffit de vérifier l'écart entre ce compteur et sa valeur précédente.
Si cet écart est supérieur à un, cela signifie que le programme a manqué un changement d'état (ou plusieurs) ; il faut alors provoquer un affichage qui indique très clairement cette situation✍.

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.
⟶ Il faudra notamment prendre soin de relever la charge de travail de l'ordinateur✍
Sous Linux ou MacOSX, la commande top fournit facilement cette information.
Sous Windows, l'outil NTop émule cette commande.
, sans et avec les repos de 50 millisecondes, afin d'en constater l'effet.

{} Préparation d'une base de données

Il sera question de mémoriser dans une base de données chaque changement d'état des données de l'équipement.
Une solution simple consiste à utiliser une base de données locale au répertoire de travail, grâce à la bibliothèque SQLite.
Pour cela, les dépendances du fichier Cargo.toml seront complétées de cette façon✍ :

[dependencies]
rusqlite = { version = ">=0", features = ["bundled"] }

La documentation de la crate rusqlite devra être consultée pour ajuster les détails : https://docs.rs/rusqlite/latest/rusqlite/.

Le début du programme peut désormais être complété en faisant usage de cette crate afin d'initialiser une base de données nommée "plc.db" par exemple.

let db = rusqlite::Connection::open("plc.db")?;
db.busy_handler(Some(|_retry_count| {
    std::thread::sleep(std::time::Duration::from_millis(1));
    true
}))?;
db.execute(
    "CREATE TABLE IF NOT EXISTS event (
        id      INTEGER PRIMARY KEY,
        utc_ms  INTEGER,
        address TEXT,
        state   INTEGER )",
    (),
)?;

L'appel à .busy_handler() permet l'éventuel usage simultané de la base de données par plusieurs programmes.
Pour cette réalisation, la base de données ne contiendra qu'une seule table nommée event✍.
Remarquez que tous ces appels sont susceptibles de reporter une erreur ; le cas échéant, le programme devra se terminer en la transmettant.

Au delà de l'absence d'erreur lors de ces appels, la seule chose à observer est l'apparition d'un fichier plc.db dans le répertoire de travail.
Si l'outil SQLite est installé dans votre système✍, il est possible de visualiser l'état initial de cette base de données avec les commandes suivantes :

# list available tables
sqlite3 plc.db '.tables'

# describe structure of "event" table
sqlite3 plc.db '.schema event'

# display content of "event" table (should be empty for now)
sqlite3 plc.db 'SELECT * FROM event'

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.

{} Sauvegarde des données

Pour l'instant, la boucle d'acquisition des données, lorsqu'elle détecte une modification d'une itération à la suivante, se contente d'afficher l'ensemble des données.
Il s'agit dorénavant de mémoriser dans la table event de la base de données chaque donnée qui a changé d'état.

Ces deux fonctions devront être réalisées selon les indications fournies plus bas :

fn store_coil_events(
    db: &rusqlite::Connection,
    utc_ms: u64,
    prev_values: &[modbus::Coil],
    new_values: &[modbus::Coil],
) -> Result<(), Box<dyn std::error::Error>> {
    // ...
    Ok(())
}

fn store_holding_events(
    db: &rusqlite::Connection,
    utc_ms: u64,
    prev_values: &[u16],
    new_values: &[u16],
) -> Result<(), Box<dyn std::error::Error>> {
    // ...
    Ok(())
}

Ces deux fonctions reposent sur les mêmes principe.
La fonction store_coil_events() sert à inscrire dans la base de données les événements qui concernent les changements d'états des “coils”.
La fonction store_holding_events() sert à inscrire dans la base de données les événements qui concernent les changements d'états des “holding registers”.
Le paramètre db désigne la base de données préparée précédemment.
Le paramètre utc_ms représente l'instant courant exprimé en millisecondes comme utilisé à cette étape.
Les paramètres prev_values et new_values sont des slices partagées (non-mutables) représentant respectivement les données détectées à l'itération précédente et à l'itération courante.

Pour compléter ces deux fonctions, il faut itérer simultanément sur prev_values et new_values.
Le moyen usuel de réaliser une telle itération est d'utiliser la fonction .zip() des itérateurs (voir le milieu de cette section).
À chaque itération, il faut tester si la valeur issue de prev_values est différente de celle issue de new_values.
Dans ce cas, cela signifie que cette donnée particulière vient de changer d'état ; il sera alors nécessaire d'inscrire cet événement dans la base de données.
L'adresse de la donnée venant de changer d'état est simplement l'indice de l'itération courante ; la fonction .enumerate() appliquée à .zip() produit cet indice (voir la fin de cette section).
Il ne reste alors qu'à réaliser cet appel :

db.execute(
    "INSERT INTO event (utc_ms, address, state)
    VALUES (?1, ?2, ?3)",
    (utc_ms, plc_addr, state),
)?;

La valeur de plc_addr est une chaîne✍ respectant le format des adresses utilisées dans l'automate :

%M0, %M1, %M2... pour les “coils”,
%MW0, %MW1, %MW2... pour les “holding registers”.

La valeur de state est directement celle la donnée provenant de new_values dans le cas de la fonction store_holding_events().
En revanche, dans le cas de la fonction store_coil_events(), la valeur de state sera le booléen résultant de la comparaison de cette valeur à modbus::Coil::On✍.

Pour faire usage de ces deux fonctions, il faut intervenir dans la boucle qui interroge l'équipement, au niveau de l'affichage qui a lieu lorsqu'on détecte un changement d'état :

store_coil_events() sera invoquée en fournissant une référence partagée (non-mutable) sur les “coils” de l'itération précédente et une référence partagée (non-mutable) sur les “coils” de l'itération courante.
store_holding_events() sera invoquée en fournissant une référence partagée (non-mutable) sur les “holding registers” de l'itération précédente et une référence partagée (non-mutable) sur les “holding registers” de l'itération courante.

Désormais, le programme doit renseigner la base de données lorsqu'il interagit avec le simulateur.
Si l'outil SQLite est installé dans votre système, il est possible de visualiser l'état de cette base de données de la façon suivante :

Exemple d'affichage produit

$ sqlite3 plc.db 'SELECT * FROM event'
1|1716934038900|%M3|0
2|1716934038900|%M4|1
3|1716934038900|%M15|1
4|1716934038900|%MW0|234
5|1716934038900|%MW1|117
6|1716934038900|%MW2|78
7|1716934039730|%M2|1
8|1716934039730|%M4|0
9|1716934039730|%MW0|242
10|1716934039730|%MW1|121
11|1716934039730|%MW2|80
12|1716934039730|%MW3|60
13|1716934039730|%MW4|48
14|1716934040740|%M6|0
15|1716934040740|%M7|0
16|1716934040740|%M8|0
17|1716934040740|%M9|0
18|1716934040740|%M10|0
19|1716934040740|%M11|0
20|1716934040740|%M12|0
21|1716934040740|%M13|0
22|1716934040740|%M14|0
23|1716934040740|%M15|0
24|1716934040740|%MW0|252
25|1716934040740|%MW1|126
26|1716934040740|%MW2|84
27|1716934040740|%MW3|63
28|1716934040740|%MW4|50
29|1716934042872|%M2|0
30|1716934042872|%M3|1
31|1716934042872|%M6|1
32|1716934042872|%M7|1
33|1716934042872|%M8|1
34|1716934042872|%M9|1
35|1716934042872|%M10|1
36|1716934042872|%M11|1
37|1716934042872|%M12|1
38|1716934042872|%MW0|273
39|1716934042872|%MW1|136
40|1716934042872|%MW2|91
41|1716934042872|%MW3|68
42|1716934042872|%MW4|54
43|1716934044820|%M13|1
44|1716934044820|%M14|1
45|1716934044820|%M15|1
46|1716934044820|%M16|1
47|1716934044820|%M17|1
48|1716934044820|%M18|1
49|1716934044820|%MW0|293
50|1716934044820|%MW1|146
51|1716934044820|%MW2|97
52|1716934044820|%MW3|73
53|1716934044820|%MW4|58
54|1716934046375|%M2|1
55|1716934046375|%M3|0
56|1716934046375|%M6|0
57|1716934046375|%M7|0
58|1716934046375|%M8|0
59|1716934046375|%M9|0
60|1716934046375|%M10|0
61|1716934046375|%M11|0
62|1716934046375|%M12|0
63|1716934046375|%M13|0
64|1716934046375|%M14|0
65|1716934046375|%M15|0
66|1716934046375|%M16|0
67|1716934046375|%M17|0
68|1716934046375|%M18|0
69|1716934046375|%MW0|308
70|1716934046375|%MW1|154
71|1716934046375|%MW2|102
72|1716934046375|%MW3|77
73|1716934046375|%MW4|61
74|1716934049191|%M2|0
75|1716934049191|%M4|1
76|1716934049191|%MW0|336
77|1716934049191|%MW1|168
78|1716934049191|%MW2|112
79|1716934049191|%MW3|84
80|1716934049191|%MW4|67
81|1716934050177|%M6|1
82|1716934050177|%M7|1
83|1716934050177|%M8|1
84|1716934050177|%M9|1
85|1716934050177|%M10|1
86|1716934050177|%M11|1
87|1716934050177|%M12|1
88|1716934050177|%M13|1
89|1716934050177|%M14|1
90|1716934050177|%M15|1
91|1716934050177|%MW0|346
92|1716934050177|%MW1|173
93|1716934050177|%MW2|115
94|1716934050177|%MW3|86
95|1716934050177|%MW4|69
96|1716934052309|%M2|1
97|1716934052309|%M4|0
98|1716934052309|%M10|0
99|1716934052309|%M11|0
100|1716934052309|%M12|0
101|1716934052309|%M13|0
102|1716934052309|%M14|0
103|1716934052309|%M15|0
104|1716934052309|%MW0|368
105|1716934052309|%MW1|184
106|1716934052309|%MW2|122
107|1716934052309|%MW3|92
108|1716934052309|%MW4|73
109|1716934054140|%M2|0
110|1716934054140|%M4|1
111|1716934054140|%M10|1
112|1716934054140|%M11|1
113|1716934054140|%MW0|386
114|1716934054140|%MW1|193
115|1716934054140|%MW2|128
116|1716934054140|%MW3|96
117|1716934054140|%MW4|77
118|1716934055418|%M1|1
119|1716934055418|%M4|0
120|1716934055418|%M12|1
121|1716934055418|%MW0|399
122|1716934055418|%MW1|199
123|1716934055418|%MW2|133
124|1716934055418|%MW3|99
125|1716934055418|%MW4|79
126|1716934056564|%M0|1
127|1716934056564|%M1|0
128|1716934056564|%M13|1
129|1716934056564|%M14|1
130|1716934056564|%M15|1
131|1716934056564|%MW0|410
132|1716934056564|%MW1|205
133|1716934056564|%MW2|136
134|1716934056564|%MW3|102
135|1716934056564|%MW4|82
136|1716934057944|%M0|0
137|1716934057944|%M4|1
138|1716934057944|%M10|0
139|1716934057944|%M11|0
140|1716934057944|%M12|0
141|1716934057944|%M13|0
142|1716934057944|%M14|0
143|1716934057944|%M15|0
144|1716934057944|%MW0|424
145|1716934057944|%MW1|212
146|1716934057944|%MW2|141
147|1716934057944|%MW3|106
148|1716934057944|%MW4|84

On peut constater que les adresses sont préfixées par %M ou %MW afin de distinguer les “coils” et les “holding registers”.
Si on relance plusieurs fois l'expérience, les nouveaux événements sont ajoutés à la suite des précédents ; il suffit de supprimer le fichier plc.db pour éviter d'accumuler indéfiniment de nouveaux événements.

Une observation attentive de l'affichage reproduit précédemment montre que beaucoup de changements d'états ont été manqués.
En effet, les états des adresses %MW0 évoluent de plusieurs unités à chaque enregistrement✍ alors qu'idéalement ils devraient reporter chaque changement d'une seule unité✍.
Cela est dû au fait que le disque dur du poste ayant servi à produire cet exemple est très lent et ne peut pas réaliser les multiples écritures individuelles dans la base de données au rythme imposé par le simulateur✍.
Cette problématique de performance fera l'objet des deux dernières étapes du projet.

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.
⟶ Il faudra notamment indiquer si le problème de performance évoqué se produit ou non, en justifiant par un commentaire des données recueillies.

{} Interaction avec un automate réel

La réalisation n'a jusqu'alors interagit qu'avec le simulateur.
Néanmoins, même si des problèmes de performance subsistent en l'état, il devient envisageable de l'exploiter avec un équipement de la matière “automatismes”✍.

À cette étape il était recommandé de tester le numéro de port afin de distinguer l'usage d'un automate ou du simulateur et ainsi déterminer le nombre de “coils” et de “holding registers” à récupérer.
Pour rappel, ces nombres sont respectivement 256 et 125 pour l'automate.

Il faudra alors désigner, grâce à la ligne de commande, le nom et le port TCP de l'équipement visé✍.
Les consignes de la matière “automatismes” indiqueront les cycles de fonctionnement significatifs dont il faudra relever l'évolution avec le programme réalisé ici.

Lors de l'utilisation du simulateur, 20 secondes suffisaient à réaliser un expérience significative.
Avec l'automate, il faudra considérablement allonger cette durée✍.
Le client pourra toutefois être arrêté prématurément grâce à la combinaison de touches Control+c dans son terminal.
La base de données plc.db ainsi recueillie, devra être recopiée et conservée précieusement afin d'être exploitée dans la matière “bases de données”.

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.

Le programme sera modifié dans les étapes suivantes afin d'en améliorer les performances.
Veillez à en faire une copie à cette étape afin d'en conserver une version qui soit en mesure d'interagir avec le système automatisé réel.
Lorsque la version améliorée sera au point, elle devra également fonctionner avec le système automatisé et la copie de cette version intermédiaire ne sera alors plus nécessaire.

{} Utilisation d'une transaction

Selon les performances de l'ordinateur utilisé✍, il a pu être constaté à la fin de cette étape que certains changements d'états du simulateur n'étaient pas inscrits dans la base de données.
Il est dorénavant question d'explorer cette limitation afin de chercher à y remédier.

Pour cela, il faudra désormais exécuter le simulateur avec cette commande : cargo run --release fast.
Le mot fast demande au simulateur de changer d'état à chaque milliseconde.
Dans ces conditions très exagérées, même un ordinateur rapide devrait ne pas être en mesure d'inscrire dans la base de données tous les changements d'états du simulateur✍.
Cette situation doit être vérifiée✍ en utilisant la commande cargo run --release✍.

Une précaution classique, en matière de bases de données, consiste à éviter d'effectuer de multiples opérations d'écriture visant à modifier immédiatement le fichier✍.
Il s'agit plutôt d'inscrire dans le fichier, en une seule opération d'écriture, l'effet de nombreuses modifications successives✍ : il s'agit d'une transaction.
Cette première amélioration est le propos de cette étape.

Voici une fonction réalisant une telle transaction, ainsi qu'un type structuré utilitaire :

struct Event {
    utc_ms: u64,
    coil: bool,
    address: u16,
    state: u16,
}

fn store_events(
    db: &rusqlite::Connection,
    events: Vec<Event>,
) -> Result<(), Box<dyn std::error::Error>> {
    let mut insert_event = db.prepare(
        "INSERT INTO event (utc_ms, address, state) VALUES (?1, ?2, ?3)",
    )?;
    let transaction = db.unchecked_transaction()?;
    for event in events {
        let address = format!(
            "{}{}",
            if event.coil { "%M" } else { "%MW" },
            event.address
        );
        insert_event.execute((event.utc_ms, address, event.state))?;
    }
    transaction.commit()?;
    Ok(())
}

Remarquons tout d'abord qu'une opération décrivant une insertion dans la table event est préparée, mais n'est pas immédiatement utilisée.
La transaction commence au moment de l'appel db.unchecked_transaction().
Elle consiste en une boucle qui extrait du vector events les informations à insérer dans la table, en exploitant l'opération d'insertion préparée.
La transaction se termine par l'appel transaction.commit() ; c'est à cet instant que l'ensemble des insertions précédentes apparaît effectivement dans la base de données.

En vue d'adapter le programme pour faire usage de la fonction store_events(), les fonctions store_coil_events() et store_holding_events() devront être modifiées :

elles s'appelleront désormais detect_coil_events() et detect_holding_events(),
elles n'ont plus besoin du paramètre db: &rusqlite::Connection ; elles attendront, à la place, le paramètre events: &mut Vec<Event>,
elles ne sont plus susceptibles de renvoyer une erreur,
elles n'invoqueront plus db.execute() mais se contenteront, à la place, de compléter events pour mémoriser les paramètres du changement d'état détecté.

Le programme doit alors préparer un vector correspondant au paramètre events attendu par les fonctions store_events(), detect_coil_events() et detect_holding_events().
Il n'est pas question de mémoriser l'intégralité des événements détectés par detect_coil_events() et detect_holding_events() pour n'invoquer qu'une seule fois store_events() à la toute fin.
En effet, si le programme devait fonctionner très longtemps, cela pourrait conduire à épuiser la mémoire de l'ordinateur.
Au contraire, il faut s'organiser pour que notre programme invoque store_events() toutes les secondes✍ :

l'usage de std::mem::take()✍
Voir
```
rustup doc --std 'std::mem::take'
```
.
sera nécessaire pour transmettre le contenu actuel du vector à la fonction detect_coil_events(),
il sera nécessaire de mémoriser dans une variable la date à laquelle cet appel a eu lieu pour la dernière fois, afin de savoir quand l'effectuer à nouveau (une seconde plus tard),
un dernier appel à store_events() doit avoir lieu à la fin du programme pour ne pas oublier d'inscrire en base de données les changements d'états détectés au cours de la dernière seconde.

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.
⟶ Il faudra notamment montrer la différence de performance obtenue✍
Même si cette amélioration montre toujours des changements d'états manqués, une nette amélioration doit être constatée par rapport à la situation précédente.
par rapport à la situation précédente✍
En utilisant toujours la commande cargo run --release puisqu'il est question de tester les performances de la réalisation.
.

{} Utilisation d'un thread

L'amélioration précédente, même si elle a produit un effet bénéfique, n'a probablement pas suffi à détecter tous les changements d'états au rythme très soutenu imposé par le simulateur.
En effet, pendant le court instant où le programme est occupé à inscrire de multiples événements dans la base de données (une fois par seconde environ), il ne peut pas simultanément surveiller les changements d'états qui continuent toujours au même rythme sur le simulateur.

La nouvelle amélioration envisagée consiste à utiliser un thread dédié aux écritures dans la base de données pendant que le programme principal continuera de surveiller très activement le simulateur.
Il faut commencer par étudier ces exemples et en particulier ce qui concerne l'usage d'un canal de communication

La fonction store_events() doit être adaptée de cette façon puisqu'elle constituera désormais le traitement exécutée par le thread :

fn store_events(
    db: rusqlite::Connection,
    channel_receiver: std::sync::mpsc::Receiver<Vec<Event>>,
) -> Result<(), Box<dyn std::error::Error>> {
    // ...
    Ok(())
}

Cette fonction ne sera plus invoquée à de multiples reprises mais une seule fois, par le thread démarré au début du programme, après l'initialisation de la base de données (qui lui sera confiée une fois pour toute par le paramètre db).
Cette fonction exploite également un canal de communication (qu'il faudra créer au début du programme) lui permettant d'obtenir de manière répétée un vector d'événements à inscrire dans la base de données.
À chaque nouvelle réception d'un tel vector depuis le canal de communication, cette fonction doit réaliser une transaction très similaire à ce ce qui était déjà effectué dans sa version précédente.

Dans le programme principal, aux deux endroits où la fonction store_events() était précédemment utilisée, il faut désormais substituer cet appel par l'envoi d'un vector d'événements (toujours en utilisant std::mem::take()) dans le canal de communication (afin que le thread inscrive ces événements dans la base de données).
Bien entendu, à la fin du programme, il ne faut pas oublier de fermer le canal de communication puis d'attendre la terminaison du thread afin de s'assurer de l'écriture de tous les événements dans la base de données.

Dans ces nouvelles conditions, le programme doit suivre sans difficulté le rythme très soutenu imposé par le simulateur : en effet, le thread dispose d'une seconde pour effectuer chaque transaction alors que pendant ce même temps le programme continue de détecter les nouveaux événements.
Nous pouvons même nous permettre d'insérer un pause de 500 microsecondes (la moitié de la milliseconde utilisée par le simulateur) afin de réduire légèrement la charge de travail.

⟶ Testez le bon fonctionnement de votre réalisation, et ajustez-la si nécessaire, en prenant des notes en vue de la rédaction d'un compte-rendu.
⟶ Il faudra notamment montrer la différence de performance obtenue par rapport à la situation précédente.