Revue n°3

Banc de tests pour contrôleur de carrefour DIASER

Sim Trafic

1. Introduction CAMPUS TRAFIC Cahier des charges Répartition des tâches et diagrammes

2. Les fonctions DIASER

3. La base de données

4. La création et la modification d’un scénario

5. L’exécution d’un scénario

6. La gestion des rapports

7. La communication avec l’automate

8. Bilan

FARGUES W. / GOUBIN T. / BOUCHET N. / TARANTINI R. / KAMOUN A.

Mairie de ToulouseBanc de tests pour contrôleur de carrefour DIASER

8. Bilan

Introduction Campus Trafic

- Société toulousaine ;

- Rattachée à la mairie de la ville ;

- Gère le trafic routier en temps réel ;

- Partenariat avec la gendarmerie

pour un travail de prévention ;

- Partenariat avec la DDE qui

gère les ASF.

8. Bilan

Introduction Cahier des charges

Objectif : créer un logiciel de banc de test pour des contrôleurs de carrefours DIASER afin de tester les scénarios pour tout type de carrefour.

Le produit final devra répondre à ces exigences :

Gérer et exécuter des scénarios ;

Gérer et générer des documents de rapport de tests ;

Communiquer avec l’automate ;

Gérer les fonctions de la norme DIASER ;

Posséder une IHM intuitive.

Introduction Réalisation 2005-2006

Objectifs de réalisation 2006-2007

> Début du projet pendant l’année scolaire 2005-2006 ;

Base de données et 14 fonctions DIASER codées ;

Un IHM peu développé ;

Problème sur la liaison série ;

Exécution inexistante.

Un programme fonctionnel :

IHM complet, 16 fonctions DIASER codées, gestion des VTC, communication série et Ethernet, exécution des scénarios sur l’automate, gestion des rapports.

8. Bilan

Diagramme de déploiement

Introduction

- Enregistre et exécute les scénarios

- Récupère et enregistre les résultats

- Exécute les scénarios

- Renvoie les résultats pour traitement

Diagramme de contexte

Introduction

Diagramme de cas d’utilisation général

1er sous

système

2nd sous

système

Introduction

1er Sous Système : Gérer les scénarios

Introduction

2nd Sous Système : Exécuter les scénarios

Introduction

Diagramme de paquetages – Répartition des tâches

Bouchet Nicolas

Tarantini Régis

Goubin Thomas

Kamoun Alexandre

Fargues Wilfried

Introduction

8. Bilan

Les Fonctions DIASER Diagramme des Classes : PFonction

CFonction

type_application : chardescription : String

<<virtual>> export_fonction()<<virtual>> fonction_affichage()<<virtual>> get_diaser()get_string_appli()get_description()

CFonction_Q

generer_bcc()<<virtual>> creer_rep()

CFonction_R

trame : string

verifier_bcc()<<virtual>> decoder_diaser()<<virtual>> decoder_trame_export()get_diaser()

Exemple

CFonction

CFonction_Q

CFonction_R

trame : string

CIdentification_Q

CIdentification_Q()CIdentification_Q()~CIdentification_Q()get_diaser()export_fonction()creer_rep()fonction_affichage()

CIdentification_R

nom : stringversion_param : stringmarque : stringmodele : stringversion_logiciel : string

CIdentification_R()~CIdentification_R()decoder_diaser()export_fonction()decoder_trame_export()fonction_affichage()

18FARGUES W. / GOUBIN T. / BOUCHET N. / TARANTINI R. / KAMOUN A.

CFonction

(from PFctCarrefour)

CFonction_Q

CFonction_R

trame : string

CConfiguration_Panneau_R

acquittement : char

decoder_diaser()decoder_trame_export()fonction_affichage()export_fonction()

CConfiguration_Panneau_Q

unite_temps_affichage : inttemps_allumage_pour_clignotant : stringtemps_extinction_pour_clignotant : stringtemps_affichage_mess1 : stringtemps_affichage_mess2 : stringunite_temps_controle_reception : inttime_out_reception : stringunite_temps_validite_message : intseuil_defaut_pixel_un : intseuil_defaut_pixel_deux : int

get_diaser()export_fonction()fonction_affichage()creer_rep()

Les Fonctions DIASER

Situation générale du sous paquetage

Voici ce qui a été codé l’année dernière : CFonction, CFonction_Q, CFonction_R

Matrice des temps de dégagement et antagonismes

Codage des Commande/Contrôle des carrefours

Calendrier des Commutations

Retour états logiques en cours

Horodate

Identification station locale

Table des commandes d’état par BTS

Types de ligne de feux

Zone mémoire

Situation générale du sous paquetage

Voici ce qui a été codé cette année : Lectures et forçages des ressourcesEnregistrement JournalTéléconfiguration de la période de comptageAutorisation AppelConfiguration d’un évènementDiagnostic de l’application télésurveillanceCommande de configuration du panneauCommande de mise en veille du panneauCommande de gestion de la luminosité de l’affichageContrôle de l’état de fonctionnement du panneauCommande d’affichage d’un message ASCII

Démarche de travail

Appropriation Norme DIASER; Conception; Code.

Mise à jour Conception.

Création Nouvelles classes dans la Conception; Codage.

Vérification Test Unitaire.

Appropriation de la norme DIASER

Nouvelles classes dans la conception

Les Fonctions DIASER - code//***********************************************************************// Génère la trame DIASER à envoyer//***********************************************************************

string CEnregistrement_Journal_Q::get_diaser(void){ string trame_diaser; //création de la trame DIASER trame_diaser="";

trame_diaser+=02; // STX trame_diaser+=type_application; // Type application trame_diaser+='R'; // Code fonction

trame_diaser+=type; // type trame_diaser+=parametre; // paramètre trame_diaser+=rang; // rang trame_diaser+=03; // ETX trame_diaser+=generer_bcc(trame_diaser); //Générer le BCC

return trame_diaser;}

TEST UNITAIRE Classe : CEnregistrement_Journal_Q No : 1

Méthode à tester : string get_diaser(void)

Description du test :La méthode de test get_diaser_Enregistrement_Q crée une instance de type CEnregistrement_Q avec les paramètres ‘0’, ‘FE’ et ’*’ puis appelle la méthode get_diaser. Pour finir, elle affiche le résultat de cette méthode.

L’utilisateur se trouve dans le programme de Tests Unitaires avec le menu principal des différentes méthodes qu’il peut tester. Il choisit la classe CEnregistrement_Journal_Q en tapant « 29 ». L’utilisateur se trouve alors dans le sous menu du TU de CAntagonisme_Q. Il tape « 01 » pour tester la méthode get_diaser.

Fonction de test :get_diaser_Enregistrement_Journal_Q

Environnement nécessaire :Windows 2000 ou XP, Visual .NET 2003

Résultat attendu :Il doit s’afficher dans la console la trame suivante : 02*0FE*0362.

RAPPORT DE TESTDate : Intervenant :04/05/07 TARANTINI Régis

Numéro de version des composants du produit : 1.0

Environnement de test : Windows 2000, Visual .NET 2003

Résultat obtenu :

Les caractères 02, 03 et 0C s’affichent en ASCII. Il est donc normal de remarquer des symboles au lieu de des chiffres.Il s’affiche bien alors la trame suivante : 02*0FE*0362.

Bilan dans le projet

Programme de tests à terminer;

Difficultés rencontrés : Appropriation des différents documents; Compréhension de la norme DIASER; Codage.

Bilan Bilan Personnel

Autonomie; Équipe (technique, personnel); Expérience positive.

Les Fonctions DIASER - VTC

Sous-système : Gérer les scénarios

Lien avec le paquetage PScénario afin de regrouper les fonctions DIASER dans un scénario à exécuter

Fonctions DIASER pour les Véhicules de Transport en Commun

Situation générale du paquetage

Ce paquetage a été conçu entièrement. Il appartient au paquetage PFonction. Il hérite donc de deux classes principales :

CFonction_QCette classe regroupe toutes les fonctions permettant de réaliser

une question en utilisant la norme DIASER.

CFonction_RCette classe regroupe toutes les fonctions et tous les attributs

permettant de réaliser une réponse en utilisant la norme DIASER.

Diagramme de classes

CFonction

CFonction_Q

CFonction_R

trame : string

Création d’une classe – norme DIASER

Création d’une classe – document récapitulatif

Création d’une classe- Diagramme de classes

Nom de la classe

Description de la classe

Création d’une classe – description de la classe

Fonctions héritées de la classe CFonction

Fonctions spécifiques à la classe CDetection_VTC_R

Fonctions héritées de la classe CFonction_R

Création d’une classe – fonctions de la classe

Création d’une classe – attributs de la classe

Nom de l’attribut

Type de l’attribut

Classe de l’attribut

Réalisation du codage

Codage des différentes classes Codage en fonction du travail effectué sous le logiciel

ROSE. Reprise du code de l’an passé pour une meilleure

intégration

Création d’un programme de tests Programme regroupant tous les fichiers de code Réalisation d’une interface pour tester chaque fonctions

DIASER.

Programme de test

Classes à tester

Méthodes de la classe à tester

Programme de test

Méthode « decoder_diaser » à tester

Différents résultats sur les trames DIASER.

Rédaction des tests unitaires

Les Fonctions DIASER - VTC Réalisation des rapports des tests unitaires

Calcul des trames Début de texte (ETX) : 02 Type application : ‘V’ (fonctions VTC) Code fonction : ‘A’ Fin de texte (FTX) : 03 Caractère de contrôle (BCC).

Vérification avec les résultats obtenus

Rédaction de la fiche de rapport de tests

Réalisation des rapports des tests unitaires

8. Bilan

La base de données

Lien avec le paquetage PihmGestionScénarios. La base de données sert à stocker les informations des scénarios récupérées dans l’IHM.

Lien avec la bibliothèque MySQL++ en rapport avec le choix de conception.

La base de données

Paquetage de la base de données servant en tout point au logiciel. Dedans, y sont enregistrés tous les scénarios et rapports d’exécution créés/générés par l’utilisateur.

La base de données

Diagramme de classes

Rapports_FonctionsID_Rapport_ExecutionRapport_QHeure_QRapport_RHeure_R

<<TABLE_BD>>

Fonctions_QID_ScenarioDescription_Q

<<TABLE_BD>>

Rapports_Execution<<Clef primaire>> ID_Rapport_ExecutionID_ScenarioNom_Rapport_ExecutionDate_Rapport_ExecutionNom_controleurNom_carrefour

<<TABLE_BD>>

1..*1 1..*1

Scenarios<<Clef primaire>> ID_ScenarioNom_ScenarioDemande_Etat_LogiqueTemps_Etat_LogiqueDemande_Mesure_TraficTemps_Mesure_TraficTemps_Execution_Scenario

<<TABLE_BD>>

1..*1 1..*1

• Fonction dans la base de données à ajouter.

• Programme de tests à terminer.

• Difficultés rencontrées : • Compréhension de la norme DIASER• Reprise du projet

• Découverte d’une norme, donc d’une méthode de travail

• Recherches et travail personnels

• Approfondissement des connaissances• Pour le travail de conception• Pour le travail de codage

Bilan personnel

8. Bilan

La création et la modification d’un scénario

État général du paquetage PIHMGestionScenarios

Partie conçue par Thomas. Regroupe le menu principal et le menu offrant la possibilité de construction du scénario en y ajoutant des fonctions pour exécution.

PIHMExécutionScénariosPartie conçue par Wilfried. Regroupe la fenêtre d’exécution du scénario ainsi

que la gestion des rapports – génération, suppression, affichage.

Définition d’un scénarioUn scénario est un ensemble de fonctions DIASER destiné à être exécuté sur un automate.

Lien avec le paquetage PBD afin de stocker les informations récupérées dans l’IHM relatives au scénario dans la base de donnée

Paquetages comprenant l’ensemble des fonctions DIASER à exécuter dans un scénario

Scénario composé de fonctions DIASER

État général du paquetage

Réalisé l’an dernierRien n’a été réalisé concernant ce paquetage.

Réalisé cette annéeMenu principal offrant la possibilité de créer un nouveau scénario, d’ouvrir un scénario existant, d’afficher la gestion des rapports d’exécution.

Menu de gestion des scénarios offrant la possibilité d’ajouter des fonctions à un scénario, de modifier ses paramètres, de demander la demande d’états logiques, d’exécuter le scénario sur l’automate.

Menu principal

Barre de menu Windows standard

Boîte de création d’un nouveau scénario

Boîte d’ouverture d’un scénario existant

Boîte d’ouverture de la gestion des rapports

Menu représentant le « cœur » du programme. Possibilité de créer un nouveau scénario, d’en ouvrir un déjà existant, de le supprimer et d’accéder à la gestion des rapports d’exécution.

Gestion des scénarios

Liste des fonctions du scénario

Ajouter/Supprimer monter/descendre la fonction sélectionnée

Modification des paramètres.

Choix d’une fonction à ajouter au scénario

Gestion des scénarios

Options du scénario

Exécute le scénario sur le contrôleur après ajout de fonctions et sauvegarde

Permet la visualisation du dernier rapport du scénario en cours

Enregistrement et modification du nom du scénario

Situation générale

Réalisé l’an dernierCe paquetage a été conçu et codé pour les fonctions existantes.

Réalisé cette annéeDes modifications ont été apportées afin de compléter avec les nouvelles fonctions DIASER codées par Régis et Nicolas.

Création de fonctions complémentaires utiles à la gestion du scénario.

Diagramme des classes

Diagramme de séquence

Tests unitaires Ajouter une fonction dans un scénario

Méthode à tester: OnBnClicked_ajouter()Description du test: L’utilisateur lance le programme de test. Il entre un nom de scénario et clique sur le bouton « Créer… ». Après sélection de la fonction dans le menu déroulant, l’utilisateur clique sur le bouton « + ».Fonction de test:OnBnClicked_ajouter() Environnement nécessaire:Windows 2000 ou XP. DLL MFC installées.

Résultat attendu:La fonction s’ajoute à la liste sur la droite de l’application.

On clique sur le bouton après sélection.

La fonction devrait apparaître dans ce cadre.

Tests unitaires Ajouter une fonction dans un scénario

RAPPORT DE TESTDate: 20/03/07 Intervenant: Thomas GOUBINNuméro de version de la classe testée: 1.0Environnement de test: Windows 2000 avec DLL MFC.Résultat obtenu: La fonction s’est correctement ajouté à la liste sur la droite de l’application.

Tests unitaires Baisser une fonction dans la liste de fonctions

Méthode à tester: OnBnClicked_bas()Description du test: L’utilisateur lance le programme de test. Il entre un nom de scénario et clique sur le bouton « Créer… ». Après sélection de la fonction dans la liste, l’utilisateur clique sur le bouton « Bas ».Fonction de test:OnBnClicked_bas() Environnement nécessaire:Windows 2000 ou XP.DLL MFC installées.

Résultat attendu:La fonction se déplace d’un cran en bas dans la liste de fonctions

On clique sur le bouton après sélection.

Tests unitaires Baisser une fonction dans la liste de fonctions

RAPPORT DE TESTDate: 20/03/07 Intervenant: Thomas GOUBINNuméro de version de la classe testée: 1.0Environnement de test: Windows 2000 avec DLL MFCRésultat obtenu: La fonction s’est bien déplacée d’un cran en bas dans la liste de fonctions

Tests d’intégration CGestionScenario et CBD

TEST INTEGRATION No:1 Objectif du test: Tester l’intégration de la classe CBD et CGestionScenario. Test de la sauvegarde d’un scénario dans la base de donnée depuis l’IHM.Description du test: L’utilisateur créé un nouveau scénario, le remplit et l’enregistre. Il ouvre ensuite la base de donnée pour vérifier le résultat.Environnement nécessaire:Windows 2000 ou XP.DLL MFC, librairie mysql++.MySqlServer 5 installé avec les tables créées.

Résultat attendu:Le scénario est présent dans la base de données.

Tests d’intégration CGestionScenario et CBD

RAPPORT DE TESTDate: 19/05/07 Intervenant: Thomas GOUBINNuméros de version des composants (modules ou classes) intégrés:CGestionScenario v1.0 / CBD v2.0Environnement de test:Windows 2000 avec DLL MFC, librairie mysql++ et MySqlServer 5 installé avec les tables créées.

Résultat obtenu:Après ouverture de la base de données, on constate que le scénario est bien présent.

Tests d’intégration CGestionScenario et CFonctionQ

TEST INTEGRATION No:2 Objectif du test: Tester l’intégration des classes CGestionScenario et CFonctionQ. Tester l’ajout des fonctions dans le scénario, le renseignement des paramètres associés à la fonction sélectionnée et la bonne récupération de ceux-ci après modification.Description du test: L’utilisateur créé un nouveau scénario, choisit une fonction dans le menu déroulant et entre des paramètres après l’ajout. Il sélectionne à nouveau la fonction et vérifie que les paramètres ont bien été remis en place.Environnement nécessaire:Windows XP.DLL MFC.

Résultat attendu:Les paramètres associés à la fonction doivent être récupérés après ajout.

Tests d’intégration CGestionScenario et CFonctionQ

RAPPORT DE TESTDate: 27/04/07 Intervenant: Thomas GOUBINNuméros de version des composants (modules ou classes) intégrés: CGestionScenario v1.0 / CFonctionQ v1.0Environnement de test: Windows 2000 avec les DLL MFC.

Résultat obtenu:Les paramètres associés à la fonction ont bien été récupérés après ajout.

Bilan dans le projet Travail effectué

Enchaînement des fenêtres;

Prototypage de l’IHM;

Intégration avec la base de donnée et PFonction;

Rédaction du manuel d’aide.

Travail à effectuer

Intégration : finaliser l’intégration avec PRapport, intégrer l’aide;

IHM : entrer l’ensemble des fonctions DIASER de PFonction.

Bilan Bilan personnel

Difficultés rencontrées

Reprise du projet; Conception graphique (MFC).

Apport personnel

Mise en œuvre de connaissances acquises; Recherche d’informations; Expérience supplémentaire.

8. Bilan

L’exécution d’un scénario

IHM de la partie exécution d’un scénario.

IHM de la partie gestion des rapports.

Exécution des scénarios.

Gestion des rapports d’exécution : affichage, génération, enregistrement, filtrage, impression.

L’exécution d’un scénarioDiagramme de classes :paquetage PRapport

La classe CRapporten détails.

L’an dernier a été réalisé :

Exécution d’un scénario sur l’automate ;

Enregistrement des résultats dans la base de données ;

Génération d’un rapport d’exécution lié à son scénario.

Cette année devait être réalisé :

Exécution d’un scénario sur l’automate ;

Affichage temps réel ;

Affichage récapitulatif en couleur ;

Possibilité d’arrêt de l’exécution ;

Génération d’un rapport au format électronique avec cartouche d’en tête ;

Récupération des nomsdu contrôleur et du carrefour.

Arrêt de l’exécution.

Affichage temps réel.

Affichage récapitulatifen couleur avec heurede la transmission à lamilliseconde.

Enregistrement dansla base de données.

Génère un rapportd’exécution.

Fin de l’exécution d’un scénario

Ferme la fenêtre etrevient à la gestiondu scénario.

Choix de conception

Programmation multitâche : Séparation des tâches ; Garder le contrôle sur la programme.

Problème : tâches périodiques et apériodiques.Solution : séparation des tâches.

// Lancement du thread pour la // demande d'etat logique si // demandée

if ( etat )AfxBeginThread(Thread_etat,

( LPVOID )infos);

// On lance un timerSetTimer(1, 800, NULL);

Choix de conception

Problème : plusieurs tâches accèdent à la communication.Solution : restreindre l’accès à une tâche à la fois.

Utilisation d’un sémaphore :Restreint l’accès à une ressource.

// Exécution des questions du scénariofor (i = 0; i < int( questions.size() ); i+

+){infos->LockSemaphore();if( !executer_diaser(questions[i]) )

return false;infos->UnLockSemaphore();}

Choix de conception

Problème : écrire en couleur dans l’IHM n’est pas géré nativement par les MFC.

Solution : dériver une classe MFC existante.

Adaptation d’une classe déjà codée : Mise à disposition gratuitement sur Internet par Hans DIETRICH ; Lisibilité ; Ergonomie.

Ancienne classe Nouvelle classe(16 couleurs disponibles)

8. Bilan

La gestion des rapports

L’an dernier, rien n’a été réalisé sur cette partie.

Cette année devait être réalisé : Affichage de la liste des rapports d’exécution ;

Regénération d’un rapport au format électronique avec cartouche d’en tête ;

Suppression d’un rapport.

Sélection d’un scénariodepuis la base de données.

Options de filtrageOptionnelles.

Rapports liés au scénario.

Nom du rapport généréautomatiquement.

Cartouche.

Récapitulatif del’exécution duScénario.

Diagramme de séquence :

« Visualiser les résultats d’un scénario » 2ième cas

Choix de conceptionProblème : choix d’un format pour les fichier générés.Solution : type TEXTE, extension .TXT. Portable ; Géré en natif sous Microsoft Windows XP ;

Problème : choix d’un éditeur de texte pour visionner les rapports.Solution : Microsoft NOTEPAD. Prise en charge du format texte .TXT ; Installé en natif sous Microsoft Windows XP ; Suffit au besoin du client.

Problème : que faire des fichiers rapports sur le disque ?Solution : les supprimer à la terminaison du programme. Gain espace disque ; Pas de conflit dans la gestion des versions de fichiers ; Regénération possible des fichiers.

Plan de test unitaires et d’intégration :

Plan de tests d’intégration :

- PIHM et CRapport- CRapport et CBD- CRapport et CCommunication

Plan de tests unitaires :

Test d’intégration N°4:

Objectif du test : Tester l’intégration de la classe CRapport avec la base de données au travers de la classe IHM CExecutionScenario (et donc CExecutionScenarioDlg).

Description du test : L’utilisateur devra tout d’abord vérifier qu’il existe des scénarios et des rapports dans la base de données CampusTrafic en la parcourant avec Easy-PHP par exemple. Si la base de données est vide, il pourra la remplir à l’aide du fichier sql fourni en annexe. Il lance le logiciel et clique sur « Afficher » dans le menu principal ou « Rapports > Afficher » dans la barre de menu. La fenêtre de gestion des rapports s’ouvre.

Environnement nécessaire : Un PC sous Windows XP, Easy-PHP version 1.8 minimum, la base de données CampusTrafic, le fichier pour la création des tables ‘capustestsql_TI_No6sql’, bibliothèques MFC, un automate DIASER relié au PC.

Résultat attendu : Dans la partie gauche, les scénarios présents dans la base de données CampusTrafic sont affichés. Lorsqu’il choisit un scénario en cliquant dessus, dans la partie droite doit s’afficher la liste des rapports en relation avec le scénario. Il pourra vérifier que les bons noms de scénario s’affichent, ainsi que les bons noms de rapports et les bonnes relations entre un scénario et ses rapports en parcourant la table de la base de données.

On remarque qu’il y a 3 scénarios dont un, le ‘Scénar_test2’ possède un rapport ‘Rapport_test1’ et un autre, le ‘Scnéar_test1’ possède un rapport ‘Rapport99’. Le scénario ‘Scénar_test3’, quant à lui ne possède pas de rapport.

Test d’intégration N°5 – Rapport :

RAPPORT DE TEST

Date : 26 Mai 2007 . Intervenants : Mr Fargues.

Numéros de version des composants (modules ou classes) intégrés : 2.0 .

Environnement de test : Un PC sous Microsoft Windows XP avec un port série DB9, bibliothèques MFC, un automate DIASER.

Résultat obtenu :

Sélection de Scnénar_test1.

Il existe un rapport Rapport99.

Il existe un rapport Rapport_test1.

Il n’existe aucun rapport.

OK PROBLEMEx

Objectif du test : Tester l’intégration des classes Crapport et CCommunication au travers de la classe IHM CExecutionScenario (et donc CExecutionScenarioDlg).

Description du test : L’utilisateur devra entrer dans l’IHM, les paramètres de la communication série (PORT_COM, vitesse, nombre de bits de stop) et se connecter, un message l’avertira de l’état de la connexion, puis la fonction DIASER à envoyer à l’automate avec le BCC correspondant. Enfin, il cliquera sur « Envoyer ».

Environnement nécessaire : Un PC sous Windows XP avec au moins un port série DB9, bibliothèques MFC, un automate DIASER relié au PC.

Résultat attendu : La fonction envoyée doit être affichée dans les boites de texte temps réel sous forme textuelle et dans la boite récapitulative sous forme « heure courante à la milliseconde [Q] ‘fonction_DIASER‘ ». La réponse reçue de l’automate doit être affichée sous forme DIASER dans la boite de texte temps réel et dans la boite récapitulative sous forme « heure courante à la milliseconde [R] ‘fonction_DIASER’ ». Le test devra être effectué fonctions une à une, puis un scénario tout entier.

RAPPORT DE TEST

Date : 31 Mai 2007 Intervenants : Mr Célébrin, Mr Audic, Mme Canceill, Mme Pinaud, Mr Fargues, Mr Goubin, Mr Bouchet, Mr Tarantini, Mr Kamoun.

Numéros de version des composants (modules ou classes) intégrés : 2.0

Environnement de test : Un PC sous Microsoft Windows XP avec un port série DB9, bibliothèques MFC, un automate DIASER.

Résultat obtenu :

OK PROBLEME

Travail effectuéMaquette papier de l’IHM ;

Spécification ;

Choix de conception avancés ;

Correction et débogage du code de l’an dernier ;

Ajout de nouvelles fonctionnalités ;

Intégration de mes fichiers avec tous les fichiers de l’an dernier, la base de données et PCommunication ;

Intégration : finaliser l’intégration avec PScenario et PFonctions;

IHM : finir le code pour l’exécution d’un scénario et pour la génération des rapports.

Bilan personnel

Difficultés rencontrées Reprise du projet ; Conception graphique (MFC) ; Architecture multitâche / temps réel ; Manque de temps (période d’examens).

Apport personnel Mise en œuvre de connaissances acquises ; Recherche d’informations ; Expérience supplémentaire.

8. Bilan

La communication avec l’automate

Objectif général: permettre la communication entre l’automate et le logiciel par liaison série ou ethernet.

PrésentationContenu du paquetage:

A quoi sert l’automate? Permet de gérer automatiquement les feux tricolores

Emplacement de l’automate Au niveau du carrefour, dans une armoire.

Comment s’effectue la programmation? Liaison série : sur place. Liaison ethernet : depuis le centre Capitoul.

Mairie de Toulouse

Situation générale du paquetage Réalisé l’an dernierLe paquetage PComSerie a été commencé mais la

liaison ne fonctionnait pas pour une demande d’antagonisme.

Le paquetage PComEthernet n’a pas été fait.

A réaliserLe paquetage PComSerie à revoir entiérement.

Le paquetage PComEthernet à réaliser.

Banc de tests pour contrôleur de carrefour DIASER Mairie de Toulouse

Diagramme de classe

Banc de tests pour contrôleur de carrefour DIASER Mairie de Toulouse

Objectif : permettre la communication par liaison série RS232.

Paquetage pour la liaison série.

Configuration du port : Norme RS232 Échange de données : norme Diaser Vitesse de transmission : 1200 à 9600 bauds 1 bit de start 7 bits de données 1 bit de parité paire 1, 1.5 ou 2 bits de stop Echange asynchrone

Langage imposé : C++

Utilisation des API de Windows

- De base sur les systèmes Windows

- Déjà utilisés

Configuration du port par l’utilisateurParamétrages possibles :

- Numéro du port, - Vitesse de transmission, - Nombre de bit de stop.

Configuration par défaut : - Port de communication : numéro 1,- Vitesse de transmission : 9600 bits/s, - Nombre de bit de stop : 1.

Mairie de Toulouse

Diagramme de classe :

CCom_serie : Constructeur de l’instance. Paramètres: le numéro du port, la vitesse de transmission, le nombre de bit de stop. ouvrir_port : Ouvre et configure le port. fermer_port : Ferme le port de communication. recevoir_diaser : Reçoit les trames sur le port. envoyer_diaser : Envoie une trame sur le port. obtenir_erreur Récupère et retourne les informations d’une erreur

Tests unitaires Ouvrir un port de communication

Méthode à tester: ouvrir_port()

Description du test:Deux cas à tester:

Cas 1 : Ouverture et configuration d’un port libre. L’utilisateur saisit dans le menu la fonction ouvrir_port.Cas 2 : Ouverture et configuration d’un port non utilisable. L’utilisateur aura exécuté deux consécutive la fonction ouvrir_port sans l’avoir fermé.

Environnement nécessaire : PC sous windows XP, présence d’au moins un port de communication accessible.

Résultats attendus: - Le port a bien été ouvert et configuré. Message « Port ouvert correctement » affiché. Le port n’est alors plus accessible.- Le port n’a pas pu être ouvert. Message d’erreur affiché « Erreur ouverture port Code erreur : 5 ».

Mairie de Toulouse

Tests unitaires Ouvrir un port de communication

RAPPORT DE TEST

Date: 23/05/07 Intervenant: Alexandre Kamoun

Numéro de version de la classe testée: 1.0

Environnement de test: PC sous windows XP, présence d’au moins un port de communication accessible.

Résultat obtenu: Cas 1 : Le port a bien été ouvert, message affiché : « Port ouvert correctement ».Cas 2 : Le port n’a pas pu être ouvert. Message afiché : « Erreur ouverture port Code erreur 5 »

Mairie de Toulouse

Tests unitaires Recevoir une trame

Méthode à tester: recevoir_diaser(string &diaser)

Environnement nécessaire : PC sous windows XP, équipement pour une communication série RS-232, automate FARECO prêt.

Description du test:Deux cas à tester:

Cas 1: L’utilisateur ouvre le port si ce n’est pas le cas. Il choisit la fonction recevoir_diaser dans le menu, valide, saisit une trame de test valide au format diaser et valide.Cas 2 : L’utilisateur ouvre le port si ce n’est pas le cas. Il choisit la fonction recevoir_diaser dans le menu puis saisit et envoie une trame diaser invalide.

Résultats attendus: Cas 1: la trame a été correctement reçue. Le message « trame recue » suivie de la trame de réponse est affiché.Cas 2 : L’automate ne répond pas. Il y a une attente de 3 secondes avant que le message « Temps d’attente depasse » s’affiche.

Mairie de Toulouse

Tests unitaires Recevoir une trame

RAPPORT DE TESTDate: 23/05/07 Intervenant: Alexandre

Kamoun

Numéro de version de la classe testée: 1.0

Environnement de test: PC sous windows XP, équipement pour une communication série RS-232, automate FARECO prêt.

Résultat obtenu: Cas 1 : La trame de réponse de l’automate a bien été reçue, le message « Trame recue: » suivie de la réponse est affiché.Cas 2 : Pas de réponse de l’automate, le message « Temps d’attente depasse » est affiché au bout de trois secondes.

Mairie de Toulouse

Tests réalisés sur automate Commandes testées sur l’automate :

Commande 1: Identification de l’automate

Question : ☻*Z♥s

Réponse : ☻ZC0286 V2.0*GAY3V01.00 ♥s

Comande 2 : Demande de l’horodate

Question : ☻*Y♥p

Réponse : ☻*YB0751710032D03 ♥q

Commande 3 : Relecture du plan de feux

Question : ☻DG0♥0

Réponse : ☻DG0********************************** ♥0

Mairie de Toulouse

Réalisation Étude de faisabilité Tests Conception

Situation Tests sur automate fonctionnel Intégration partielle avec l’IHM d’exécution de

Wilfried Fargues.

Objectif : permettre la communication par liaison ethernet.

Paquetage pour la liaison ethernet.

Langage imposée : C++ Utilisation des API de windows

De base sur les systèmes windows Déjà utilisé

Choix du protocole Ethernet Choix sur le mode non connecté : UDP

Avantage :

+ Allégé et donc rapide

+ Peu coûteux

+ Très utilisé

Inconvénient

- Pas de contrôle des trames (mais faite par la norme Diaser)

Mairie de Toulouse

Configuration de la liaison Paramétrée par l’utilisateur

Adresse IP de l’automate Numéro de port pour la communication

Par défaut : Adresse IP locale: 127.0.0.1 Numéro de port 0, signifiant port choisie par le

système

Mairie de Toulouse

La communication avec l’automateBanc de tests pour contrôleur de carrefour DIASER

Diagramme de classe :

Mairie de Toulouse

CComEthernet : Constructeur de l’instance.

creation_socket : Initialise et crée une socket qui permettra l’envoi et la réception de

données.

fermeture_socket : Stoppe l’utilisation de la socket et libère les ressources utilisées.

recevoir_diaser : Reçoit la trame réponse de l’automate.

envoyer_diaser : Envoie la trame question à l’automate.

obtenir_erreur Récupère et retourne les informations d’une erreur

Mairie de Toulouse

Méthode à tester: envoyer_diaser(const string diaser)Description du test:

Cas 1 : L’utilisateur a correctement créé une socket. Il choisit dans le menu la fonction envoyer_diaser. Il saisit ensuite la trame diaser à envoyer et valide;

Cas 2 : L’utilisateur n’a pas créé de socket depuis l’exécution du programme ou l’a fermé. Il sélectionne la fonction envoyer_diaser et saisit une trame à envoyer.Fonction de test:TU_envoyer_diaser() Environnement nécessaire:Windows XP, deux PC avec liaison ethernet et le programme serveur sur l’un des ordinateurs exécuté.

Résultats attendu:Cas 1 : Le message « trame envoyé » s’affiche, et sur le programme serveur la

trame est affichée.Cas 2 : Le message « Erreur envoi de la trame » suivie du code de l’erreur est

affiché. Rien ne s’affiche côté serveur.

Tests unitaires Envoyer une trame

Mairie de Toulouse

Tests unitaires Envoyer une trame

RAPPORT DE TESTDate: 24/05/07 Intervenant: Alexandre KAMOUNNuméro de version de la classe testée: 1.0Environnement de test:Windows XP, deux PC avec liaison ethernet et le programme serveur sur l’un des ordinateurs exécuté.

Résultats obtenu :Cas 1 : Le message « trame envoyé » est affiché. Le programme serveur a bien

affiché la trame.Cas 2 : Le message « Erreur envoi de la trame Code erreur 10093» est affiché.

Rien ne s’affiche côté serveur.

Mairie de Toulouse

Méthode à tester: fermeture_socket()Description du test:

Cas 1 : L’utilisateur a correctement créé une socket. Il choisit dans le menu la fonction fermeture_socket et valide.

Cas 2 : L’utilisateur n’a pas créé de socket depuis l’exécution du programme ou l’a fermé. Il sélectionne la fonction fermeture_socket et valide.Fonction de test:TU_fermeture_socket() Environnement nécessaire:Un PC sous Windows XP avec une carte réseau.

Résultats attendu:Cas 1 : Le message « Socket fermee » s’affiche.Cas 2 : Le message « Erreur fermeture socket » suivie du code de l’erreur est

affiché.

Tests unitaires Fermer la socket

Mairie de Toulouse

Tests unitaires Fermer la socket

RAPPORT DE TESTDate: 24/05/07 Intervenant: Alexandre KAMOUNNuméro de version de la classe testée: 1.0Environnement de test : Un PC sous Windows XP avec une carte réseau.

Résultats obtenu :Cas 1 : Le message « Socket fermee » est affiché.Cas 2 : Le message « Erreur fermeture socket Code erreur 10093» est

affiché.

Mairie de Toulouse

Réalisation Étude de faisabilité Tests entre deux ordinateurs Conception

Situation Tests entre deux ordinateurs fonctionnels

Bilan dans le projet Travail effectué

Classe de la communication série fonctionnelle.

Classe de la communication ethernet fonctionnelle entre ordinateurs.

Finaliser les classes.

Bilan personnel Problèmes rencontrés:

Réception correcte d’une trame pour la communication série. Mise en œuvre de la communication Ethernet.

Projet qui m’a fait progresser dans différents domaines:

Domaine professionnel Organisation du travail Mener à bien un projet

Domaine informatique Communication en Ethernet sous windows Communication en série avec un automate. Programmation orientée objet C++

8. Bilan

Bilan Bilan du groupe

Etat du projet

Codage à finaliser Intégration finale en cours

Bilan général

Bonne expérience Application de notions vues en cours Difficultés relatives aux examens

Revue n°3

Documents

Revue des Energies Renouvelables Vol. 11 N°3 (2008) 329

Revue d'ArchéoPortail n°4

REVUE N°26.1997

Revue n° 13

Revue n°111

Revue isd n° spécial

REVUE PERIODIQUE N°3 du commissariat aux … · 2 "El Moudakik" N°3 - Les 4èmes assises du commissariat aux comptes Tamanrasset a revue El Moudakik, dans son 3ème numéro, déroulant

REVUE HISTORIQUE 7, 1-3, 1930.pdf · 2018-02-01 · REVUE ilISTORIQUE SUD-EST EUROPEEND1:1 PUBLitE PAR N. IORGA, PROFESSICIIR 1 L'ITNavuRsiTh DE BIIOAREST VILE ANNEE, N-OS 1-3. JANVIER-MARS

Revue de l'OCDE sur la gestion budgétiare – Vol 3 – n°3 · Volume 3 – n° 3 ORGANISATION DE COOPÉRATION ET DE DÉVELOPPEMENT ÉCONOMIQUES. ... a Revue de l’OCDE sur la

Revue des Energies Renouvelables Vol. 15 N°3 (2012) … · Revue des Energies Renouvelables Vol. 15 N°3 (2012) 451 – 463 451 Estimation du rayonnement solaire au sol par des modèles

Revue N°144

« Territoires critiques - Revue Posturesrevuepostures.com/sites/postures.aegir.nt2.uqam.ca/files/asselin_24… · Revue Postures Automne 2016, n°24 Soline Asselin 3 comprendre comment

Revue isd n° 29

N° 3 - Novembre 2003 - Banque de France · 2013-03-28 · Avant-propos Banque de France • Revue de la stabilité financière • N°3 • Novembre 2003 5 L a Revue de la stabilité

REVUE N°25.1995

Revue n° 29

N°3 - Sha‘ban 1430 - Août 2009 Lumièreslumieres-spirituelles.net/revue/lumieres_spirituelles_3.pdf · N°3 - Sha‘ban 1430 - Août 2009 2 N°3 - Sha‘ban 1430 - Août 2009

Revue Echanges n°23

Revue Echanges n°21

Revue d'ArchéoPortail n°8