Conception logicielle du Raspberry Car – Les Tâches (1/2)
Le besoin
Le plus gros problème de cette phase du projet, serra d’écrire un logiciel pour le Raspberry Pi qui doit faire plusieurs choses en même temps avec des logiques différentes.
On va donc avoir besoin en Python :
- De faire tourner tous les programmes en même temps,
- Et faire qu’ils se synchronisent bien et qu’ils ne se dérange pas mutuellement.
Descriptions des différentes tâches
Le programme qui lit la carte GPS :
- Il lit en tout ce qui vient de la carte GPS
- Il analyse toutes les données pour juste donner juste la position (quand il y en a une)
- Il met de côté la dernière position trouvée avec l’heure
- Il attend un peu pour avoir des nouvelles données de la carte
Le programme qui lit la carte OBD :
- Il demande à la carte les informations de la voiture
- Il met de côté la réponse avec l’heure
- Et il attend
Le programme qui stocke dans la base de données :
- Il récupère les dernières informations mise de côté par le programme GPS et OBD
- Il les enregistre dans la base SQL
- Et il attend
Le programme qui envoyer les données à Salesforce
- Il essaye de se connecter à Salesforce
- Si cela réussit :
- Il lit tout ce qui est dans la base SQL pour être envoyé
- Il envoie à Salesforce
- Il marque ou supprime les données déjà envoyer
- Il attend les nouvelles données (pause) produites par autres programmes.
Délais et Interactions
Il y a différents délais actifs :
- Pour ne pas toujours communiquer avec Salesforce on peut décider de se connecter et envoyer les données à Salesforce toutes les 5-10 minutes, même si on mémorise la position toutes les 5 secondes
- La carte GPS envoie plusieurs fois la position par seconde, mais on n’en garde un que toutes les 5 sec par exemples
- Etc.
Il y a des tâches qui ne doivent pas s’emmêler :
- La lecture et l’écriture dans la base de données
- La mise de côté des valeurs lues et leur utilisation pour les stocker dans la base
On a besoin d’un moyen de faire qu’un programme puisse empêcher l’autre de manipuler soit la base, soit les données le temps qu’il ait fini lui-même son travail.
Réécrivons le déroulement des programmes en indiquant les attentes et les ‘verrous’ dont on a besoin.
Le programme qui lit la carte GPS :
- Il lit en tout ce qui vient de la carte GPS
- Il analyse toutes les données pour juste donner juste la position (quand il y en a une)
- Pose le verrou
1 : je bloque la mémoire pour la dernière position GPS
- Action sécurisée : Il met de côté la dernière position trouvée avec l’heure
- Débloque le verrou 1 (cela a duré quelque millisecondes)
- Il attend un peu pour avoir des nouvelles données de la carte
Le programme qui lit la carte OBD :
- Il demande à la carte les informations de la voiture
- Pose le verrou 2 : je bloque la mémoire pour la dernière info OBD
- Action sécurisée : Il met de côté la réponse avec l’heure
- Débloque le verrou 2 (cela a duré quelque millisecondes)
- Et il attend 20 secondes
Le programme qui stocke dans la base de données :
- Pose le verrou 1 : je bloque la mémoire pour la dernière position GPS
- Pose le verrou 2 : je bloque la mémoire pour la dernière info OBD
- Action sécurisée : Il récupère les dernières informations mise de côté par le programme GPS et OBD
- Débloque le verrou 1 (cela a duré quelque millisecondes)
- Débloque le verrou 2 (cela a duré quelque millisecondes)
- Pose le verrou 3 : je bloque l’accès à la base SQL
- Action sécurisée : Il les enregistre dans la base SQL
- Débloque le verrou 3 (cela a duré presque 1 seconde, car on écrit sur le disque)
- Et il attend 60 secondes
Le programme qui envoyer les données à Salesforce
- Il essaye de se connecter à Salesforce
- Si cela réussit :
- Pose le verrou 3 : bloque l’accès à la base SQ
- Action sécurisée : Il lit tout ce qui est dans la base SQL pour être envoyé
- Débloque le verrou 3 (cela a duré presque 1 seconde, car on écrit sur le disque)
- Il envoie les informations à Salesforce. Cela peut durer plusieurs secondes : temps de réaction de Salesforce, la vitesse du réseau, etc.
- Pose le verrou 3 : bloque l’accès à la base SQ
- Action sécurisée : Il marque ou supprime les données déjà envoyer
- Débloque le verrou 3 (cela a duré presque 1 seconde, car on écrit sur le disque)
- Pose le verrou 3 : bloque l’accès à la base SQ
- Il attend les nouvelles données (pause) produites par autres programmes.
Comment fait-on en python pour bloquer un programme ?
J’ai cherché sur Internet comment faire pour avoir plusieurs parties du programme qui s’exécutent en parallèle en python et ne s’emmêlent pas.
La réponse est d’utiliser des Threads et des verrous (lock).
Cela est décrit ici
Dans le code Python, on va devoir créer les verrous :
lock = RLock()
Dans notre cas il y en aura 3 :
lockOBD = RLock()
lockGPS = RLock()
lockSQL = RLock()
Le code que l’on doit protéger, devra commencer par
with verrou:
insérer le code à sécuriser ici
Le code à sécuriser va être placé dans des objets Thread (également décrit dans l’article ; un thread sert à créer un flux de programme parallèle dans le logiciel) et encadré par l’usage du verrou.
Par exemple pour la lecture OBD, la structure du programme sera :
class LectureOBD(Thread):
def __init__(self, mot):
Thread.__init__(self)
def run(self):
Ecrire le code qui demande les infod de la voiture
with lockOBD:
Ecrire le code qui met de côté la réponse avec l’heure
Ecrire le code qui attend 20 secondes