Architecture logicielle¶
L’architecture du logiciel sera la suivante
Le logiciel sera constitué d’une BDD SQLite pour les données, de divers modules/packages dont certains pour l’IHM et la Backend.
Ces deux derniers modules seront lancés dans des process différents. (module multiprocessing de Python). Il communiqueront par des Pipes et Queues unidirectionnels.Ce sont de simples tuyaux de communications à une entrées (Pipe) ou multiple, de type FIFO (Queues). Il y en aura pour les commandes (bleu foncé), pour les DATA (Jaune), ou pour indiquer le travail en cours par le backend (bleu clair). L’IHM est ainsi totalement détachée de la partie backend, tache de fond du soft.
Les queues et pipe utilmiseront des dictionnaires contenant eux-même des dictionnaires ou des listes.
Un troisieme process, se chargera de tout ce qui est communicatione externe. Le backend sera le seul à communiquer avec ce process. Le backend se chargera également de centraliser les données puis d’écrire dans le fichier de log, ainsi que de l’accès à la BDD.
Les trois process possederont une boucle qui leur permettra à interval régulier de communiquer avec les autre process.
L’IHM sera en Pygtk, et disposera d’une boucle animée par un gobject timeout add à 50 ms. Le Backend disposera lui d’une boucle animée à 20 ms.Par boucle animée, on entend une tâche, lancée toutes les X secondes afin d’analyser le contenu des pipes et queues. Les frequences sont choisies pour respecter le theoreme de SHanon, et garantir une bonne fluifdité de l’ensemble.
Les erreurs du backend seront remontées à l’IHM via les pipe/queue.
Il y aura deux IHM: une complete dediée aux professionnels, et aux amateurs avertis, et une auter, tres simple destiné aux neophites. Le choix entre les deux se fera via une constyante en BDD à “SIMPLE” ou a “COMPLETE”.
Le code commun aux deux IHM sera placé dans une lib ihm_common. Deux autres lib (ihm_pydiago_simple & ihm_pydiago_complete) heriteront de cette lib common.Côté Backend le code de lecture/analyse/init sera egalement placé dans un common. Ces fichiers common permettront de faciliter les dev futurs.
A l’occasion de ce soft, une lib maison pygtk heritant de pygtk, et une lib maison serial, heritant de pyserial seront écrites, et ce afin de faciliter les devs futurs et de mutualiser les acquis des differents dev.
Cette IHM simplifiée: un jeu d’icone gris, prenant 3 couleurs possibles si pb (rouge/orange/vert) selon type de pb (fugitif, permanent, ...). Un bouton pour effacer les pannes, selection du port, on/off,bouton simplediag.Une icone par categorie d’erreur: carosserie, moteur, ...quatre frames: un pr les categorie, un pour les grosses icones (inspirees des tablos de bords), un pour les infos principales (tension alternateur, regime moteur,t° liquide refroidissement, code VIN du vehicule+traduction partielle),un pour les boutons. icone a gauche, infos principales a droite, boutons sur ttes la largeur en bas.Pas de texte, que des images: cnx°(icone), clear(gomme),MAJ toutes les 1s
Ces deux IHM devront disposer d’une fenetre (popup ou non) permettant une MAJ aisée par le user(fichier texte avec DATA ss forme de dico de liste de tuples. Les cle sont les tables concernées. Sert a alimenter une requete dynamique
côté com serie, se termine par un rtr ligne. Donc analyser chaque caractere, et tt que diff de ce rtr ligne, alors stocker. a chaque lecture de caractere, si 0x00 alors ignorer.
Bonnes pratiques: *creation des objets dans un dictionnaire dédié (un par type d’objet, par ecran) *Utilisation d’une seule procedure, par signaux, pour gerer les evnmts signal (ex: signal_changed, signal_clicked, ...) *Passer systematiquement l’objet de la BDD au backend exclusivement. L’IHM doit passer par le backend pour acceder à la BDD *Detacher les com externe, et les peripheriques dans des process dedies. Permet d’eviter les soucis *Pour le nombre de processeurs/coeur utilisé par le soft, faire un PCU_COUNT//2. On s’assure ainsi de ne jamais utilisé plus de la moitié des ressouces CPU systeme *Tous les process utilise le même formatage: envoi d’une requete sous forme de dico, reponse sous forme de dico. La cle correspond à la requete, la valeur à la reponse. A la requete la valeur vaut None
Fd blc avec image en gris foncé par dessus de biais pour le style. rectangle avec deux coins opposés arrondis pour les boutons, et le splash screen Ajouté dans les tables soumises à evolution une colonne pr savoir si ajout logiciel ou user Possibilité pour le user de créer un fichier d’export des données insérées par lui Tables BDD pour interpreter/interroger en OBD2? Couleur de la doc sphinx pr le soft bouton de menu avec les images inspirée des images ds Download => creation d’un jeu d’icone !!! Fenetre error/warning/info en fd blc egalement ecran bloc donnee pas prioritaire Un seul ecran a la fois. Fusionner ecran 1 et config (peu de config a faire, port serie limité (juste le num), ...) Une barre de menu commune pr les courbes/tableau ac: type, start/stop, ajout au rapport, taux de rafraichissment (pas ss le 1/2s),...) On grise ou non ce qui doit servir
Logo: moteur devant, et plus on va vers le fond, plus ça devient du code binaire (type matrice), titre soft en gris foncé dessous, fd blanc.
ihm_common & backend_common: code contenant les bcles. Backend_common a des fct dedies aux process ac creation des pipes/queues/listing_process. <soft>_ihm & <soft>_backend heritent d’elles
ihm¶
ihm_common
Ds ihm_common: *1 fct pour ajouter une requete: on lui passe un mot clé et le type (CMD ou DATA). La fct envoie directement ça dans les queues *On passe à la creation un dictionnaire de dictionnaire qui decrit les mot cles pour quelles fctions appeler ex: dico_action[“”][“”]
Heritage
Backend¶
backend_common
Ds backend_common: *1 fct pour lire les requetes *On passe à la creation un dictionnaire de dictionnaire qui decrit les mot cles pour quelles fctions appeler ex: dico_action[“”][“”]
ds le backend_common, preciser par une option a passer si a lancer en process parallele ou non
[mot_cle]=[process// ou non, fonction a appeler, ...]
Heritage
Logiciel¶
soft_common
soft_core: *prend en parametre les classes <soft>_ihm & <soft>_backend *prend en entree une list d’objet/process a lancer *effectue les connections et lance les process *1 process different par type d’action: frontend, backend, com externe (1 par type de com/peripherique) *Le backend lance systematiquement ses demandes dans des process differents (permet de lancer plusieurs com serie en //, type FIFO), sans bloquer la boucle de fond *Pour pydiago: 1 process IHM, 1 process backend, 1 process com serie
soft_common: *contient un lot de fonction maison utile pour le soft *Y placer la classe path_maker
<soft>.py: *effectue toutes les inits tierces (hors ihm et backend) *appelle soft_core.
Heritage
Interaction¶
Modules tiers utilisés¶
- Pygtk: Interface graphique
- Pyserial: Communication serie
- Sqlite: Gestion de la BDD
- report: Generation des PDF de rapports
Modules maison¶
pygtk_dbt_common & pyserial_dbt_common: *heritent de pygtk et pyserial *Ajoute des fonctionnalité en sus pour simplifier le code de dev
Ds Pygtk_dbt_common: *lancement du pdf fct de l’OS *gestion des combobox *fct show & hide à partir d’un dico d’objet *fct de gestion d’image en fond *fct de creation tooltip simplifié a partir d’un objet et du texte associé
Ds pyserial_dbt_common: *listing des ports serie avec possibilité de filtre et d’un nombre max *cnx° simplifiee *choix du caractere de fin
- pygtk_dbt:
- pyserial_dbt:
- ihm_common:
- backend_common:
- soft_core:
- soft_common:
- Sensor: Gestion des interfaces hardwares (ELM327)
Ce module gerera les different adpatateur USB/OBD
Dans la class ELM327, 1 fct par parametrage, 1 fct generique (mode, pid)
Class Elm327():
- __init__(self,serial_cnx, listing/dictionnaires issus de la DB):
- obd2_mode01(): # gestion du mode 1 de l’OBD
- obd2_mode02() # gestion du mode 2 de l’OBD
- obd2_mode03() # gestion du mode 3 de l’OBD
- obd2_mode04() # gestion du mode 4 de l’OBD
- obd2_mode05() # gestion du mode 5 de l’OBD
- obd2_mode06() # gestion du mode 6 de l’OBD
- obd2_mode07() # gestion du mode 7 de l’OBD
- obd2_mode08() # gestion du mode 8 de l’OBD
- obd2_mode09() # gestion du mode 9 de l’OBD
- obd2_mode10() # gestion du mode 10 de l’OBD
- start_cnx(parametrage de la com serie): #demarre la cnx serie, renvoi si succes ou non
- stop_cnx(): #stoppe la cnx serie, renvoi si succes ou non
- com_init(): #initialise la com avec l’ELM, l’initialise, renvoi le numero de version de l’ELM
- Get_supported(): #interroge dans tous les modes les fonctions supportées, et renvois un lot de listes
- com_car(mode,pid): #appelle les fonctions adequate en fonction de ce qui est demandé
- get_voltage(): #interroge sur le niveau de la batterie et renvoi la valeur lu
