memoire de pfe – briot nicolas - Bienvenue sur Catalogue des

MISE EN ŒUVRE D’UN BANC HIL POUR LE TEST
FONCTIONNEL D’UNE ASI HAUTE PERFORMANCE
MEMOIRE DE PFE – BRIOT NICOLAS
INSA de Strasbourg – Spécialité Génie Electrique – Option Systèmes
Chez SOCOMEC Usine 3 - 11 route de Strasbourg - 67235 HUTTENHEIM
Du 01/02/2016 au 29/07/2016
Tuteurs : PLUMERÉ Éric & ROHMER Thierry
Enseignant référant : LAFONT Thomas
1 – FICHE D’OBJECTIFS
L’objectif de ce projet est de doter le département R&D de SOCOMEC – Usine 3 d’un banc de
test fonctionnel sans risque de dommages afin de pouvoir tester leurs logiciels embarqués conçus pour
leur dernier modèle d’onduleur haute performance.
Le choix est donc fait de mettre en place un banc Hardware In the Loop (HIL), c’est-à-dire
exempt de composants de puissance : on remplace toute l’électrotechnique par un boîtier de
simulation. C’est le matériel National Instruments (NI) qui est employé, nous utilisons de nombreux
logiciels dans ce projet.
Le cahier des charges fixé par SOCOMEC comporte les éléments suivants :
-
Modifier l’électronique de mesure du prototype pour pouvoir imiter les courants fort
manipulés avec des sorties du simulateur.
-
Simuler la partie puissance de l’onduleur à partir de son schéma PSIM, utilisant pour ce faire
un outil développé par OPAL-RT, un partenaire de NI.
-
Simuler les éléments connexes tels que la batterie, une charge particulière, les rebonds des
contacteurs ou encore les sondes de températures.
-
Interfacer l’électronique de commande avec le poste opérateur en reproduisant les
commandes passées par le logiciel XpertSoft de SOCOMEC via le protocole Modbus.
-
Concevoir les séquences de test permettant de vérifier que le logiciel respecte bien les
spécifications établies.
-
Développer des outils permettant de faciliter la procédure de test et d’en garantir la
maintenabilité.
Langage de programmation graphique NI
Adapter l'électronique de
mesure sur le prototype
Simuler la partie puissance
Opal-RT eHS
Interfacer l'électronique de
commande avec le poste
opérateur
Logiciel de dialogue/monitoring des produits NI
Concevoir les séquences de
test et autres outils associés
Séquenceur de test NI
Figure 1 : Liste synthétique des étapes du projet et des logiciels NI employés pour les mener à bien
1
Nicolas BRIOT (GE5)
2016
2 – RESUME
Mise en œuvre d’un banc hil pour le test fonctionnel d’une asi haute performance
La complexité des programmes embarqués dans les onduleurs SOCOMEC ne cesse de croitre
et chaque dysfonctionnement peut s’avérer coûteux. Ce projet a pour objectif d’élargir la couverture
de test des logiciels produits tout en réduisant les coûts et les délais de développement : un banc de
test « Hardware In the Loop » (HIL) doit être mis en place. La partie puissance d’un prototype sera
remplacée et émulée par des FPGA, des séquences de test exhaustives permettront par la suite la
validation du code embarqué.
HIL test bench implementation for high efficiency UPS functional characterization
The complexity of SOCOMEC UPS embedded software keeps increasing and any single fault
may prove itself costly. This project’s goal is to improve systems’ software test coverage while reducing
development costs and time: a “Hardware In the Loop” (HIL) test bench must be implemented. A
prototype’s power stage will be replaced and emulated by FPGAs and exhaustive test sequences will
ensure embedded software validation.
2
Nicolas BRIOT (GE5)
2016
3 – TABLE DES MATIERES
Table des matières
1 – FICHE D’OBJECTIFS............................................................................................................................. 1
2 – RESUME ............................................................................................................................................. 2
3 – TABLE DES MATIERES ........................................................................................................................ 3
4 – TABLE DES ILLUSTRATIONS ................................................................................................................ 5
5 – ABREVIATIONS ET DEFINITIONS ........................................................................................................ 7
6 – INTRODUCTION ................................................................................................................................. 8
6.1 – PRESENTATION DE L’ENTREPRISE............................................................................................... 8
6.2 – PRESENTATION DU PRODUIT ................................................................................................... 10
6.3 – PRESENTATION DU PROJET ...................................................................................................... 11
7 – SYNTHESE DU TRAVAIL EFFECTUÉ ................................................................................................... 13
7.1 – LES PERSONNALITES DES CARTES FPGA ................................................................................... 13
7.2 – LA MODELISATION DU RETOUR DES SONDES THERMIQUES ................................................... 15
CARACTERISATION DES SONDES ....................................................................................... 16
ETUDE DES MONTAGES DIVISEURS ................................................................................... 17
CARACTERISATION DE LA GENERATION DE PWM ............................................................. 20
CONCEPTION DU VI SIMULANT LES SONDES..................................................................... 21
GENERATION DU MODELE VERISTAND ASSOCIE............................................................... 22
MODIFICATION DE LA PERSONNALITE FPGA POUR GERER LES PWM DE FREQUENCE
VARIABLE ....................................................................................................................................... 23
7.3 – L’ETUDE DES PROTOCOLES CANOPEN ET MODBUS-TCP.......................................................... 24
LE PROTOCOLE MODBUS ................................................................................................... 25
LE PROTOCOLE CANOPEN.................................................................................................. 26
L’ENCAPSULATION MODBUS DE TRAMES CANOPEN ........................................................ 29
PRESENTATION DES PROTOCOLES A L’EQUIPE ................................................................. 31
LES VIs DE COMMUNICATION ........................................................................................... 31
7.4 – ANALYSE ET EMPLOI DES FICHIERS .INI .................................................................................... 33
LE STOCKAGE DES INFORMATIONS DANS UNE BDD ......................................................... 34
LA GENERATION DE FICHIER XML ET XSD .......................................................................... 35
3
Nicolas BRIOT (GE5)
2016
7.5 – L’AJOUT DES ACRONYMES HIL.................................................................................................. 36
REFONTE DU VI GENERANT LE FICHIER XML ..................................................................... 36
CONCORDANCE DES ACRONYMES HIL ET SOFT ................................................................ 37
7.6 – CONCEPTION DES SEQUENCES DE TEST ................................................................................... 38
SUIVI DE LA FORMATION TESTSTAND ............................................................................... 38
PRESENTATION DU LOGICIEL ET DE SON INTERFACE ........................................................ 38
CONCEPTION DES SEQUENCES ET LEUR ARCHITECTURE .................................................. 39
L’UTILISATION DES CALLBACKS.......................................................................................... 39
7.7 – DEVELOPPEMENT D’OUTILS POUR LE DEPARTEMENT ............................................................. 40
OUTIL COMPLETANT AUTOMATIQUEMENT LA MATRICE DE TRAÇABILITE ...................... 40
OUTIL DE VERIFICATION D’INI FILES (FICHIER UNIQUE) .................................................... 41
OUTIL DE VERIFICATION DE PLUSIEURS INI FILES EN COMPARAISON .............................. 42
8 – CONCLUSION ................................................................................................................................... 43
9 – BIBLIOGRAPHIE ................................................................................................................................ 44
10 – REMERCIEMENTS........................................................................................................................... 45
11 – ANNEXES ........................................................................................................................................ 46
11.1 – ANNEXE 1 : CODE LABVIEW DES OUTILS DEVELOPPES.......................................................... 46
11.2 – ANNEXE 2 : SCHEMA GENERAL DE L’ELECTRONIQUE HPP ..................................................... 47
11.3 – ANNEXE 3 : SCHEMA PSIM DE LA PARTIE PUISSANCE HPP .................................................... 48
4
Nicolas BRIOT (GE5)
2016
4 – TABLE DES ILLUSTRATIONS
Figure 1 : Liste synthétique des étapes du projet et des logiciels NI employés pour les mener à bien . 1
Figure 2 : Image de présentation de SOCOMEC ...................................................................................... 8
Figure 3 : Organisation du département R&D de l'usine 3 ..................................................................... 9
Figure 4 : Schéma de principe d'une A.S.I à double conversion SOCOMEC .......................................... 10
Figure 5 : Maquette H.I.L du HPP .......................................................................................................... 12
Figure 6 : Zoom sur le châssis PXIe_1082 contenant les cartes FPGA .................................................. 12
Figure 7 : Zoom sur les références des modules E/S ............................................................................. 12
Figure 8 : VI de configuration des E/S d'un FPGA.................................................................................. 13
Figure 9 : Extrait d’un fichier XML de listing des paquets FPGA pour VeriStand .................................. 14
Figure 10 : Chaîne de mesure de la température sur maquette ........................................................... 15
Figure 11 : Courbe caractéristique d'une thermistance CTN ................................................................ 16
Figure 12 : Mise en commun des caractéristiques des différentes CTN ............................................... 16
Figure 13 : Schéma simplifié du circuit de mesure des CTN ................................................................. 17
Figure 14 : Circuit de mesure de température du Booster-Charger ..................................................... 17
Figure 15 : Tableau récapitulatif des paramètres des montages diviseurs........................................... 17
Figure 16 : Circuit de mesure de température batterie (pas de RL) ..................................................... 18
Figure 17 : Circuit de mesure de température ambiante...................................................................... 18
Figure 18 : Circuit de mesure de température 4ème bras .................................................................... 18
Figure 19 : Circuit de mesure de température des IGBTs Inverter et Rectifier ..................................... 19
Figure 20 : Circuit de mesure de température Bypass .......................................................................... 19
Figure 21 : Utilisation des données Excel pour lier la tension d’entrée en V (abscisse) et les
caractéristiques de la PWM .................................................................................................................. 20
Figure 22 : Modèles simplifiés intégrant le point (0;0) ......................................................................... 20
Figure 23 : VI calculant la tension image des températures ambiante et batterie ............................... 21
Figure 24 : VI calculant les temps à l’état haut et bas des PWM de toutes les autres températures .. 21
Figure 25 : Comment définir une entrée d'un VI comme Required ...................................................... 22
Figure 26 : Ajout d'un modèle dans le projet VeriStand ....................................................................... 22
Figure 27 : Export d'un VI en un modèle VeriStand .............................................................................. 22
Figure 28 : Syntaxe initiale, fréquence fixe et rapport cyclique variable .............................................. 23
Figure 29 : Nouvelle syntaxe permettant de fixer les temps à l'état haut et bas de la PWM .............. 23
Figure 30 : Tableau des codes fonctions Modbus ................................................................................. 25
Figure 31 : Composition schématique d'une trame Modbus RTU (ADU) ............................................. 25
Figure 32 : Schéma de l'encapsulation Ethernet d'une trame Modbus TCP ........................................ 26
Figure 33 : Composition schématique d’une trame Modbus TCP (ADU) .............................................. 26
Figure 34 : Composition schématique d’une trame Modbus TCP-RTU (ADU) ...................................... 26
Figure 35 : Les 7 couches du modèle OSI .............................................................................................. 26
Figure 36 : Le protocole CANOpen gère les couches Network et supérieures ..................................... 26
Figure 37 : Exemple de Dictionnaire Objet............................................................................................ 27
Figure 38 : Une trame CAN décomposée bit à bit (Wikipédia) ............................................................. 27
Figure 39 : Schéma simpliste d'une trame CAN .................................................................................... 28
5
Nicolas BRIOT (GE5)
2016
Figure 40 : Composition du COB-ID en CANOpen ................................................................................. 28
Figure 41 : Extrait de spécification CANOpen précisant les codes fonction ......................................... 28
Figure 42 : Schéma de la hiérarchie dans les protocoles dans notre système...................................... 29
Figure 43 : Encapsulation de la trame CANOpen dans un PDU de trame Modbus............................... 30
Figure 44 : Analyse des paquets échangés à l'aide du logiciel WireShark ............................................ 30
Figure 45 : Support de la présentation dispensée sur les protocoles CANOpen et Modbus ................ 31
Figure 46 : VIs qui créent un Maître Modbus TCP (en haut) ou TCP-RTU (en bas) en local.................. 31
Figure 47 : Génération d'un PDU Modbus encapsulant une trame CANOpen ..................................... 32
Figure 48 : Interface de test LabVIEW permettant l'envoi de commandes .......................................... 32
Figure 49 : Interface de XpertSoft (à gauche) et extrait d'un INI file (à droite) .................................... 33
Figure 50 : Première solution de Parsing des INI Files employant l'analyse du texte ........................... 33
Figure 51 : Contenu de la base de données MySQL générée pour le projet HIL .................................. 34
Figure 52 : VI permettant l'ajout des données extraites dans une BDD ............................................... 34
Figure 53 : Aperçu du fichier XML regroupant les clés de protocole (à gauche) et du fichier XSD de
définition des règles du schéma (à droite) ainsi qu'un message d'erreur obtenu via XML Tools ........ 35
Figure 54 : Vue d'ensemble du VI permettant l'extraction des clés d'un ensemble de fichiers INI pour
générer un XML associé ........................................................................................................................ 35
Figure 55 : VI générant le fichier XML de protocole après refonte, sont encadrés (en rouge) les subVI s
permettant la correspondance des acronymes .................................................................................... 36
Figure 56 : Capture du fichier INI_Types.xml ........................................................................................ 36
Figure 57 : Aperçu du fichier XML contenant les acronymes produit et HIL ........................................ 37
Figure 58 : Structure du logiciel TestStand............................................................................................ 38
Figure 59 : Découpage de l'interface graphique de TestStand ............................................................. 38
Figure 60 : Deux possibilités pour un Process Model dit séquentiel .................................................... 39
Figure 61 : Face avant (à gauche) et vue d'ensemble du projet (à droite) de l'outil complétant la
matrice de traçabilité ............................................................................................................................ 40
Figure 62 : Exemple d'utilisation de l'outil de vérification d'un seul fichier INI dans un dossier (en bas)
et ouverture du rapport généré (en haut) ............................................................................................ 41
Figure 63 : Gestion d'erreur (en bas) et fenêtre contextuelle de fin d'exécution (en haut) de l'outil de
vérification de multiples .INI ................................................................................................................. 42
Figure 64 : Vue d'ensemble du projet commun des deux outils de vérification de fichiers INI ........... 42
Figure 65 : Code de l'outil complétant la matrice de traçabilité ........................................................... 46
Figure 66 : Code de l'outil de vérification d'un seul fichier INI ............................................................. 46
Figure 67 : Code de l'outil de vérification de multiples fichiers INI ...................................................... 46
Figure 68 : Schéma général de l'électronique de commande HPP ....................................................... 47
Figure 69 : Schéma PSIM de la partie puissance du projet HPP (avec transformateur) ....................... 48
6
Nicolas BRIOT (GE5)
2016
5 – ABREVIATIONS ET DEFINITIONS
ADU
Application Data Unit, désigne l’intégralité d’une trame Modbus
ASI (ou UPS)
Alimentation sans interruption (ou Uninterruptible Power Supply).
BDD
Base de données.
CTN
Sonde de température dotée d’un Coefficient de Température Négatif
DC
Duty Cycle, rapport cyclique d’une PWM
FIFO
First In First Out, une file de données dotée d’une structure à décalage : la
première information arrivée est la première à sortir de la file.
HIL
« Hardware In the Loop », qualifie une façon de tester/développer un
système embarqué complexe en remplaçant les éléments à risque par un
simulateur respectant son modèle.
HPP
High Power Platform, nom du dernier projet de R&D chez SOCOMEC U3
INI
Fichier de configuration, d’extension « .ini ».
Log
Rapport au format texte (.txt)
Parser
Programme recherchant un élément donné dans un contexte défini.
PDU
Protocol Data Unit, correspond à la partie centrale d’une trame Modbus
RTU
Remote Terminal Unit, protocole de transmission série (Modbus)
SVN
Subversion (abrégé), logiciel de gestion de versions
TCP/IP
Transmission Control Protocol/Internet Protocol, protocoles de transport
de donnée
VI
Virtual Instrument, sous-programme codé en LabVIEW.
XML
« eXtensible Markup Language » ou langage de balisage extensible, un
fichier « .xml » contient des informations dont la structure peut facilement
être reproduite, transmise et parcourue.
7
Nicolas BRIOT (GE5)
2016
6 – INTRODUCTION
Dans le cadre de notre PFE, Cédric SCHRAMM (CEQ) et moi-même (NGB) avons intégré le
service Firmware (FIRM) de l’usine 3 au sein de l’entreprise SOCOMEC à Huttenheim. Encadrés par
Messieurs ROHMER Thierry (TRO) et PLUMERÉ Éric (EIP) nous avons été affectés au projet Hardware
In the Loop (H.I.L) sur leur dernier modèle d’alimentation sans interruption (A.S.I) à très haut
rendement dénommée High Power Platform. Le produit « H.P.P » pour lequel nous développons le
H.I.L présente notamment un rendement proche des 98% du fait de l’absence de transformateur
triphasé dans la partie puissance.
Afin de mener à bien ce stage, nous avons été formés sur le matériel et les logiciels National
Instruments, une opportunité qui nous a permis d’acquérir rapidement de l’expérience dans ce
domaine, très recherchée par les employeurs. Nous avons également été initiés à un principe inhérent
à la R&D software : le versionning outil permettant, avec un logiciel comme TortoiseSVN, la
programmation collaborative et la sauvegarde en multiples exemplaires sur serveur.
6.1 – PRESENTATION DE L’ENTREPRISE
SOCOMEC est un constructeur indépendant offrant des solutions expertes pour la
performance énergétique des réseaux électriques BT comptant plus de 3100 collaborateurs dans le
monde cette entreprise totalise un chiffre d’affaire annuel dépassant les 420 M€.
L'usine 3 de SOCOMEC est située à
Huttenheim (67230). Avec une superficie de
13000m², l'usine comptait 243 personnes
embauchées en 2013.
Créée en 1982, elle est depuis cette date
dédiée à la fabrication d'onduleurs, de modules de
transfert de charge, de redresseurs-chargeurs et de
compensateurs d'harmoniques. Elle développe
quatre types de gammes d’ASI et continue de
développer d'autres modèles permettant de
répondre aux besoins du client.
Figure 2 : Image de présentation de SOCOMEC
L’usine 3 abrite un service R&D, une Show-Room, des plateformes de tests, une zone
expédition UPS/service après-vente, un magasin/poste de contrôle de réception, une ligne multimodèle ainsi qu’une de montage spécifique, une zone de test en bout de ligne et un Training Center.
La Show-Room est une salle de démonstration équipée de produits Socomec. Elle permet de
simuler l'installation type d'un client en partant en amont d'un inverseur de source jusqu'à une
utilisation simulée par une charge résistive par exemple, en passant par des onduleurs, les systèmes
de stockage d'énergie et les systèmes de transfert statique. Le Training Center est destiné à former des
techniciens ou clients sur l'utilisation des différentes gammes d'onduleurs.
8
Nicolas BRIOT (GE5)
2016
La plateforme de test est séparée en plusieurs secteurs tels que la zone de test de produits
finis où sont réalisés des tests de routine sur chaque produit et solution, des essais de réception de
matériel et des essais et démonstrations de qualification avant-vente personnalisés. De plus, la
plateforme recherche et développement permet de réaliser des essais de développement et de
qualification requis pour le développement des produits, comme des tests électriques,
électromagnétiques, thermiques ou acoustiques par exemple.
La zone expédition UPS permet la livraison des produits directement de l'usine vers les clients
sans passer par une plateforme logistique. C'est pourquoi SOCOMEC exporte à partir de cette usine
80% de la fabrication. Un service après-vente est aussi disponible.
Plusieurs lignes de montage sont présentes. La ligne multi-modèle est dédiée au montage des
produits standards des gammes DMX, DMP et DGP. La ligne montage spécifique permet de réaliser
d'autres montages tels que les armoires de couplage, by-pass ou de transformation. Il existe aussi une
ligne d'armoires militaires avec une équipe autonome travaillant uniquement sur la réalisation de
projets pour la DCNS. Enfin, le test en bout de ligne d'assemblage permet de tester 100% de la
production selon un processus standard. Si un problème est découvert et non réparable au bout d'un
temps fixé, l'onduleur va sur plate-forme.
J’ai intégré le département de recherche et développement (DEV) sous la direction de Pascal
BOOS, au sein de l’entité Firmware (Fig.3) et avec Éric PLUMERÉ comme maître de stage.
Cette cellule est chargée du développement de la partie logicielle des ASI SOCOMEC et
fonctionne au moyen d’outils de « versionning » permettant une collaboration efficace lors de la
création et de l’édition de code.
Figure 3 : Organisation du département R&D de l'usine 3
Un bilan sur l’avancement des différents projets pris en charge par la cellule est effectué
chaque lundi à 9h30. Ce point hebdomadaire est appelé TOP 30 car sa durée ne doit pas excéder la
demi-heure.
Lors de mon arrivée au sein de ce département, j’ai rejoint l’équipe de Thierry Rohmer sur le
projet H.I.L dont je parlerai plus en détail ci-après.
9
Nicolas BRIOT (GE5)
2016
6.2 – PRESENTATION DU PRODUIT
A ce stade du rapport, il semble judicieux de définir plus en détail le rôle et la structure d’une
A.S.I (ou U.P.S pour Uninterruptible Power Supply) souvent appelé onduleur par abus de langage.
Figure 4 : Schéma de principe d'une A.S.I à double conversion SOCOMEC
Une Alimentation Sans Interruption est un dispositif de l'électronique de puissance qui permet
de fournir un courant alternatif stable et sans coupures/microcoupures, indépendamment du
comportement du réseau électrique source.
Les deux éléments centraux d’une ASI à double conversion sont ainsi le redresseur (Rectifier),
chargé de transformer le réseau de tensions triphasées alternatives en une tension continue et un
onduleur (Inverter) assurant la génération d’un système de tensions triphasées alternatives à partir
d’une source DC. Le bus de tension continu formé en connectant l’entrée de l’Inverter à la sortie du
Rectifier peut ainsi être raccordé ponctuellement à une batterie pour assurer la continuité de service
en cas de coupure du réseau. Cette batterie peut être rechargée (Charger) lorsqu’elle n’est pas
sollicitée lors d’une décharge rapide (Booster). Un organe appelé le quatrième bras (ou 4th Leg) assure
un équilibrage entre la tension négative et positive sur le bus DC.
Par ailleurs, le système de tensions en sortie de l’onduleur se révèle être de bien meilleure
qualité /fiabilité (suppression des harmoniques, stabilité en amplitude et en fréquence) que celui
provenant du réseau. Un passage « à chaud » sur l’alimentation auxiliaire (Automatic Bypass) peut être
effectué en fonctionnement et inversement, cela s’avère notamment intéressant quand l’utilisateur
souhaite ne pas user de la double conversion afin d’atteindre un rendement supérieur ou lors d’un
défaut de l’onduleur.
On peut également choisir de passer ou non par ce système via un contacteur de dérivation
(Manual ByPass) pour en effectuer la maintenance.
10
Nicolas BRIOT (GE5)
2016
6.3 – PRESENTATION DU PROJET
Le H.I.L est un principe de développement pour systèmes embarqués complexes, on émule le
matériel de ces derniers via un modèle mathématique équivalent.
Ce procédé permet ainsi l’implémentation puis le test de nouvelles fonctionnalités dans le
code de façon rapide (et peu couteuse une fois l’achat initial des outils de simulation effectué).
Nos objectifs pour ce stage seront ainsi de reproduire le fonctionnement d’une ASI en boucle
fermée au moyen d’un châssis doté de plusieurs cartes FPGA et d’en tester les fonctionnalités, déjà
programmées ou à venir, fournies par le service de recherche et développement Firmware. Nous
disposerons pour ce faire des moyens suivants :
-
Matériel National Instruments :
o
o
o
-
NI PXIe-1082 : Châssis comportant les cartes FPGA et permettant un dialogue TCP/IP avec
un ordinateur distant (Fig.6).
Cartes FPGA FlexRIO 7961R et 7976R et carte FPGA Compact RIO 7842R : Cartes FPGA
intégrées dans le PXIe.
Modules I/O NI 5742 et 6581B : Cartes d’interface contrôlées par les FPGA et permettant
la connexion de ces derniers à notre électronique de commande, simple électronique
d’adaptation avec faibles temps de propagation (Fig.7).
Logiciels National Instruments :
o
LabVIEW : Logiciel de programmation graphique de NI
Tous les autres logiciels NI peuvent utiliser les codes générés par ce logiciel appelés VI
(Virtual Instruments)
Cédric et moi-même possédions déjà des bases sur ce logiciel mais son utilisation au cours
du stage nous a permis d’obtenir la certification CLAD.
o
VeriStand : Logiciel de monitoring de systèmes NI
Il permet d’interfacer notre électonique via le « mapping » des E/S des diférentes cartes
FPGA et modules
Nous avons suivi une formation de 2 jours pour en saisir les bases.
o
TestStand : Logiciel d’automatisation de séquences de test NI
Il permet de planifier une séquence d’opérations complexes reproduisant les cas
d’utilisations du produit testé.
Nous avons pris part à une formation de 3 jours sur ce soft pour finalement un niveau
d’utilisateur autonome capable d’assister nos maîtres de stage dans le développement.
11
Nicolas BRIOT (GE5)
2016
-
Code FPGA fourni par Opal-RT
Il simule le hardware de l’onduleur dont le schéma est généré sous PSIM, voir Annexe 3. Nous avons
été formés durant 3 jours sur ce « Custom Device ».
-
L’électronique de commande d’un onduleur H.P.P
En développement chez SOCOMEC et montée sur une maquette mobile dans le cadre du projet H.I.L
(Fig.5). Nous avons suivi des réunions internes sur son fonctionnement et sa conception.
Figure 6 : Zoom sur le châssis PXIe_1082
contenant les cartes FPGA
Figure 5 : Maquette H.I.L du HPP
Figure 7 : Zoom sur les références des modules E/S
12
Nicolas BRIOT (GE5)
2016
7 – SYNTHESE DU TRAVAIL EFFECTUE
Dans un premier temps nous avons vérifié l’interfaçage entre l’électronique de la maquette et
les cartes NI mises en place afin de corriger les erreurs éventuelles. De nombreux problèmes de
soudures ont notamment été corrigés durant les premières semaines. Les tests s’effectuaient au
moyen d’un projet LabVIEW réalisé par notre maître de stage pour tester individuellement chaque E/S
des cartes NI. Nous avons ensuite suivi la formation NI VeriStand pour découvrir les fonctions de cet
outil et les prendre en main.
7.1 – LES PERSONNALITES DES CARTES FPGA
Un des premiers travaux que j’ai réalisés fut de me documenter sur le procédé de
personnalisation des cartes FPGA pour les adapter à notre besoin.
Il ne s’agit pas de réécrire le code en VHDL pour les FPGA mais d’éditer un VI de configuration
(Fig.8) dont des exemples (Templates) sont fournis dans LabVIEW pour y ajouter, retirer ou modifier
l’affection des E/S. Ces dernières sont assemblées en un tableau qui est envoyé par le FPGA sous la
forme d’un registre à décalage ou FIFO (First IN First OUT).
La FIFO des entrées FPGA est nommée DMA_Read, celle des sorties DMA_Write. Le système
est cadencé à 40 MHz, les durées sont exprimées en nombre de ticks (un tick représente une durée
1
équivalente à la période du FPGA, soit 40 000 000 secondes = 25 ns). Une PWM de période 800 000 ticks
possèdera donc à une fréquence de 50Hz.
La compilation du VI de définition produit un fichier « .lvbitx » qui peut être interprété par le
FPGA. On appelle ce fichier un « FPGA Bitfile », toute utilisation d’une carte intégrant un FPGA de chez
NI nécessite un tel fichier. On a par cette action définit une « Custom FPGA Personality » (personnalité
FPGA).
Figure 8 : VI de configuration des E/S d'un FPGA
13
Nicolas BRIOT (GE5)
2016
L’interfaçage d’un FPGA avec VeriStand s’appuie sur un fichier « .fpgaconfig », ce dernier est
au format XML (modifiable avec Notepad++ par exemple) et renseigne le type et l’ordre de l’arrivée
des données dans les FIFO d’entrées et de sortie du FPGA : ces registres contiennent des paquets de
64 bits dont nous devons spécifier la nature et la structure (Fig.9).
Un paquet en entrée peut donc par exemple contenir les données de :
-
16 entrées digitales (1 bit chacune)
1 entrée PWM (temps à l’état bas et à l’état haut, en nombre de ticks, codés sur 16 bits chacun)
1 entrée analogique (valeur renvoyée par le convertisseur analogique-digital sur 16 bits).
Il faudra alors rédiger la description de ce paquet en y incluant :
-
16 champs entourés de balises <Boolean>…Liste_des_paramètres…</Boolean>
Deux champs <U16>…Liste_des_paramètres…</U16> car les temps sont positifs (U16 = Unsigned
Integer coded on 16 bits)
Un champ <I16>… Liste_des_paramètres …</I16> car la tension analogique lue peut être négative
(I16 = Signed Integer coded on 16 bits).
J’ai ainsi réalisé les fichiers « .lvbitx » et « .fpgaconfig » des cartes FPGA NI 7842 et NI 7961R
afin de pouvoir les interfacer sous VeriStand et tester notre électronique.
Figure 9 : Extrait d’un fichier XML de listing des paquets FPGA pour VeriStand
La fréquence de la boucle TCP s’exécutant sur la cible gérée par VeriStand n’est pas fixée
dans ce fichier mais dans la définition système. Aussi appelée boucle de contrôle principale (ou
Primary Control Loop), c’est elle qui assure le dialogue avec le PC opérateur et qui instancie les
modèles dont nous allons parler plus en détail par la suite.
14
Nicolas BRIOT (GE5)
2016
7.2 – LA MODELISATION DU RETOUR DES SONDES THERMIQUES
Sur la maquette H.I.L, un monitoring permanent des interrupteurs de puissance, de la
température des batteries et de l’air ambiant est nécessaire pour détecter un éventuel défaut
nécessitant un arrêt de l’ASI.
Afin de reproduire les températures vues par notre électronique simulée, il est nécessaire
d’analyser la chaîne de mesure de température en place sur le prototype et de la reproduire
logiciellement.
Actuellement, des sondes de températures à coefficient négatif (ou NTC pour Negative
Temperature Coefficient) sont intégrées aux IGBT ou sur des cartes de mesures et, par le biais d’un
montage en pont diviseur, renvoient une tension image de la température.
Cette tension est transformée en PWM de rapport cyclique et fréquence variable, c’est
finalement de façon logicielle qu’on mesure le rapport cyclique de cette PWM pour revenir par
linéarisation à la température approximative mesurée (Fig.10).
Mon travail est de produire un modèle VeriStand qui génère la PWM image de la température
que nous simulons. Pour une température en entrée, le modèle doit donc reproduire la variation
exponentielle de résistance de la sonde CTN, obtenir la tension sortant du montage diviseur et
finalement générer le plus fidèlement possible la PWM associé à la tension ainsi obtenue.
Chaine à modéliser
Traitement effectué par le soft HPP
Figure 10 : Chaîne de mesure de la température sur maquette
De nombreux documents sont nécessaires à la complétion de cette tâche :
-
Les datasheets mettant en évidence les coefficients propres aux différentes sondes de
températures et leur loi de variation exponentielle.
-
Les schémas de câblage des montages diviseurs de chacune des cartes intégrant une sonde CTN.
-
La loi de conversion tension-rapport cyclique et tension-fréquence de la carte générant les PWM
(identique pour toutes les différentes sondes).
15
Nicolas BRIOT (GE5)
2016
CARACTERISATION DES SONDES
Dans un premier temps, j’ai rassemblé les datasheets des différentes sondes thermiques
employées, il s’agit de capteurs thermorésistifs à coefficient négatif : leur résistance est une fonction
exponentielle décroissante de la température du matériau semi-conducteur employé.
Dans chaque cas, les trois paramètres qui
nous intéressent sont le coefficient de décroissance B
et un couple Résistance-Température de référence
RREF et TREF.
Ces trois données nous permettent ainsi de
remonter à l’expression fournissant la résistance de la
CTN pour une température donnée (Fig.11).
Figure 11 : Courbe caractéristique d'une thermistance CTN
Voici une synthèse des données collectées dans les documentations techniques sur le portail
de l’entreprise :
Semikron
SEMiX603GB066v7a
(Booster-Charger)
Vincotech
70-W212NMA600SC
(Inverter & Rectifier)
Socomec-Sicon
E221748
(Bypass, 4th Leg,
Ambient & Battery)
Figure 12 : Mise en commun des caractéristiques des différentes CTN
16
Nicolas BRIOT (GE5)
2016
ETUDE DES MONTAGES DIVISEURS
V
REF
VREF
En se basant sur le schéma électrique intégrant la CTN aux
cartes électroniques HPP, on peut établir la relation entre la résistance de
la CTN et la tension de sortie. Il s’agit d’effectuer une étude au cas par cas.
RH
RH
VT
RLL
R
CTN
Figure 13 : Schéma simplifié du
circuit de mesure des CTN
Dans chaque situation, un pont diviseur est constitué, une
résistance peut être mise en parallèle de la CTN pour linéariser la variation
de tension.
Pour chaque montage on définit trois grandeurs récurrentes :
VREF, RH et RL comme indiquée ci-contre (Fig.13).
On peut alors exprimer la tension VT comme une fonction de ces paramètres :
𝑉𝑇 = 𝑉𝑅𝐸𝐹 ∗
𝑅𝑒𝑞
𝑅𝑒𝑞 +𝑅𝐻
avec
𝑅𝑒𝑞 =
1
1
1
+ )
𝐶𝑇𝑁 𝑅𝐿
(
et
𝐶𝑇𝑁 = 𝑅𝑅𝐸𝐹 ∗ e
1
1
)
𝑇 𝑇𝑅𝐸𝐹
𝐵∗( −
On obtient finalement le tableau suivant :
Rectifier Inverter
Bypass
4th Leg
Booster-Charger
Ambient
Battery
VREF (V)
5
5
5
5
3
3,3
RH (Ω)
680
25k
15k
390
21k5
150k
RL (Ω)
1k
75k
46k4
180
54k9
sans
HPP BOARD [page]
HP7P166 [2]
HP520 [2]
HP510 [4]
HP7B506 [4]
HP400 [8]
GIO [3]
Figure 15 : Tableau récapitulatif des paramètres des montages diviseurs
Voir NOT 16 82499
La tension la plus faible l’emporte,
on conserve donc la température
la plus élevée.
RH
VREF
RL
BOOSTER
CHARGER
Figure 14 : Circuit de mesure de température du Booster-Charger
17
Nicolas BRIOT (GE5)
2016
VREF
RH
BATTERIE
Figure 16 : Circuit de mesure de température batterie (pas de RL)
RH
AMBIANTE
E
VREF
RL
Figure 17 : Circuit de mesure de température ambiante
4th LEG
VREF
RH
5V
RL
Figure 18 : Circuit de mesure de température 4ème bras
18
Nicolas BRIOT (GE5)
2016
VREF
IGBTs INVERTER
ET RECTIFIER
RH
RL
Figure 19 : Circuit de mesure de température des IGBTs Inverter et Rectifier
RH
VREF
BYPASS
RL
La tension la plus faible l’emporte,
on conserve donc la température
la plus élevée.
Figure 20 : Circuit de mesure de température Bypass
19
Nicolas BRIOT (GE5)
2016
CARACTERISATION DE LA GENERATION DE PWM
C’est la même carte de conversion qui est utilisée pour les températures de tous les éléments
du prototype HPP (carte HP500, voir Annexe 2) à l’exception des mesures de températures ambiante
et batterie qui ne sont pas converties en PWM (on mesure uniquement la tension qui sort du pont
diviseur).
Il faut caractériser la fonction de transfert liant fréquence et rapport cyclique à la tension
d’entrée. On s’appuie sur le document TempSensor Voltage Freq transform.xls, un fichier Excel de
mesures sur le portail, pour trouver des relations simples entre ces différentes grandeurs (Fig.21).
Figure 21 : Utilisation des données Excel pour lier la tension d’entrée en V (abscisse) et les caractéristiques de la PWM
On peut identifier une relation linéaire entre tension et rapport cyclique ainsi qu’une relation
polynomiale du second ordre entre tension et fréquence du signal PWM en sortie.
Excel donne une bonne approximation des équations que nous allons utiliser ; une relation plus simple
est obtenue en imposant le passage du modèle par le point (0;0) dans les deux cas. Soit VT la tension
mesurée en sortie du pont diviseur, on obtient sensiblement les mêmes courbes (Fig.22) avec les
équations simplifiées suivantes :
Frequency = -198,11*VT 2 + 1004,5*VT
DutyCycle = 19,7*VT
Figure 22 : Modèles simplifiés intégrant le point (0;0)
20
Nicolas BRIOT (GE5)
2016
CONCEPTION DU VI SIMULANT LES SONDES
Une fois que tous les paramètres sont connus, on peut concevoir un subVI incluant un bloc
équation présentant la formule établie. Pour la température ambiante et la batterie la formule est
réduite et ne comporte qu’une tension en sortie.
Ajouter de nombreux modèles dans VeriStand peut fortement réduire les performances du
système global aussi nous avons préféré limiter le nombre de modèles thermiques à deux : un
regroupant les tensions images des températures ambiante et batterie (Fig.23), un autre regroupant
toutes les PWM images des autres températures (Fig.24).
Block diagram
VI Terminals
Figure 23 : VI calculant la tension image des températures ambiante et batterie
Ces VIs comportent un grand nombre d’entrées/sorties, il apparaît donc plus simple de définir
l’ensemble des paramètres comme des constantes.
Block diagram
VI Terminals
Front panel
Figure 24 : VI calculant les temps à l’état haut et bas des PWM de toutes les autres températures
21
Nicolas BRIOT (GE5)
2016
GENERATION DU MODELE VERISTAND ASSOCIE
Il reste à configure les terminaux d’entrée et sortie des VIs de
façon à ce qu’ils soient correctement employés par VeriStand.
On les paramètre ainsi :
-
Les entrées d’un VI qui sont définies Required deviennent
des IN ports dans le modèle VeriStand (Fig.25).
-
Les entrées d’un VI qui sont définies Recommended ou
Optional apparaîtront parameters dans le modèle VeriStand.
-
Les sorties d’un VI apparaîtront toujours comme des OUT
ports dans le modèle VeriStand.
Figure 25 : Comment définir une entrée
d'un VI comme Required
On peut ensuite exporter le VI en un modèle VeriStand (Fig.26) puis l’ajouter au projet via la
définition système (Fig.27), pour que cette option soit disponible dans LabVIEW il faut avoir le
composant NI VeriStand LabVIEW Model Support installé. On importe la totalité des entrées, sorties et
paramètres des modèles.
La procédure complète de création d’un modèle VeriStand à partir d’un VI est détaillée sur le
site de NI [1].
Figure 27 : Export d'un VI en un modèle VeriStand
22
Nicolas BRIOT (GE5)
Figure 26 : Ajout d'un modèle dans le projet VeriStand
2016
MODIFICATION DE LA PERSONNALITE FPGA POUR GERER
LES PWM DE FREQUENCE VARIABLE
Pour terminer, il faut modifier la personnalité FPGA de la 7842 afin de pouvoir gérer les PWM
à fréquence variable. En effet, à l’origine une sortie PWM contrôlée par une valeur numérique de 0 à
100 correspondant à son rapport cyclique, la fréquence étant fixe (Fig.28). La modification du fichier
XML (.fpgaconfig) de la cible FPGA permet de pouvoir agir sur les deux grandeurs à la fois par le biais
du temps à l’état haut et à l’état bas de la PWM (Fig.29).
Figure 28 : Syntaxe initiale, fréquence fixe et rapport cyclique variable
Figure 29 : Nouvelle syntaxe permettant de fixer les temps à l'état haut et bas de la PWM
Le paramètre <Scale> valant 107.374182375 permet la conversion des U32 possédant une
pleine échelle de 232-1 (=4294967296) vers une période en nombre de ticks avec pour maximum
40.000.000 (1 correspondant à 40MHz et 40e+6 à 1Hz). VeriStand calcule, pour une entrée de
l’utilisateur en seconde, le temps correspondant en ticks.
Par la suite les modèles sont testés et finalement optimisé par nos consultant pour utiliser le
moins de ressource possible sur la cible embarquée.
23
Nicolas BRIOT (GE5)
2016
7.3 – L’ETUDE DES PROTOCOLES CANOPEN ET MODBUS-TCP
Dans un premier temps, il faut effectuer des recherches sur ces deux protocoles de
communication nécessaires au dialogue avec l’électronique de commande de la maquette.
En pratique, le dialogue s’effectue avec la carte de communication de la maquette HIL
(ComBoard) via Modbus et cette dernière communique avec les autres cartes en interne en CANOpen
via un bus CAN.
Il faut donc maîtriser aussi bien l’un et l’autre afin de pouvoir échanger des informations
individuellement avec chaque sous-élément du produit. Modbus et CANOpen obéissent tous deux à
des standards décrits dans des spécifications [2][3]. La documentation CANOpen officielle n’est
cependant pas accessible au public (nécessité d’adhérer au CiA).
Il s’agit donc de connaître la composition des trames de requête et de réponse ainsi que la
topologie du bus et de l’architecture de communication pour pouvoir venir s’insérer dans le réseau en
tant que client Modbus et y injecter les commandes adéquates.
Une fois les bases de ces protocoles maîtrisées, il devient possible d’étudier leur jonction : le
CANOpen Over Modbus spécifié dans le CiA 309 [4]. Ce dernier décrit l’implémentation d’un dialogue
CANOpen via une surcouche Modbus, permettant ainsi de communiquer directement avec la carte
interne de notre choix depuis un poste connecté au réseau (Modbus TCP ou TCP/RTU) ou en liaison
série (Modbus RTU).
Nous reviendrons plus en détail sur chacun de ces protocoles dans les parties suivantes.
24
Nicolas BRIOT (GE5)
2016
LE PROTOCOLE MODBUS
Elaboré par Modicon (désormais Schneider Electric) en 1979, ce protocole de communication,
s’est répandu extrêmement rapidement du fait de l’absence de royalties quant à son implémentation.
Il s’est imposé comme un standard de par sa facilité de mise en place, d’utilisation et de maintenance.
Plusieurs implémentations du protocole sont possibles, nous discuterons ici de trois d’entre
elles :
-
Modbus RTU
Modbus TCP
Modbus RTU-TCP
Dans chaque cas la topologie hardware, la composition des entête/fin de trames échangées diffèrent ainsi que le modèle de
communication (Maître-Esclave ou Serveur-Client) diffèrent. Le contenu du
message n’est cependant pas affecté par l’implémentation choisie, on
nomme cette « partie centrale » invariante le Protocol Data Unit (PDU).
Le PDU contient systématiquement un code fonction sur un octet
(Fig.30) puis la donnée relative à ce code, par exemple le code 03 permet la
lecture d’un ou plusieurs registres (mots de 16 bits), la donnée associée
contient le nombre de registres à lire et l’adresse de début de ces registres.
La fonction 43 nous intéressera particulièrement par la suite.
Figure 30 : Tableau des codes
fonctions Modbus
En Modbus RTU, une liaison série (couche physique : RS232 ou RS422 par exemple) est mise
en place entre un maître et un esclave (passif), l’en-tête du message Modbus ne contient ainsi que
l’identifiant de l’esclave sur le bus Série pour l’adresser puis vient directement le PDU et finalement
une vérification de redondance cyclique sur 16 bits (ou CRC, pour Cyclic Redundancy Check, qui
correspond à une simple comparaison de restes dans une division polynomiale) (Fig.31).
Figure 31 : Composition schématique d'une trame Modbus RTU (ADU)
25
Nicolas BRIOT (GE5)
2016
En Modbus TCP, un client va dialoguer
avec le serveur (passif) par l’intermédiaire d’une
connexion Ethernet (Fig.32). Pour ce faire, un
en-tête appelé Modbus Application Header
(MBAP) est ajouté afin de permettre l’appairage
et le bon traitement des requêtes envoyées et
des réponses reçues (Fig.33). On n’adjoint pas de
CRC en fin de trame Modbus car une vérification
d’erreur est déjà mise en place dans la trame
Ethernet (CRC 32).
Figure 32 : Schéma de l'encapsulation Ethernet
d'une trame Modbus TCP
Figure 33 : Composition schématique d’une trame Modbus TCP (ADU)
Une variante du protocole Modbus TCP appelée Modbus RTU over TCP (ou plus simplement
Modbus TCP-RTU) consiste à envoyer une trame Modbus RTU dotée d’un en-tête MBAP via une
connexion Ethernet (Fig.34). Cette solution permet ainsi de simuler une communication maîtreesclave sur un Serveur.
Figure 34 : Composition schématique d’une trame Modbus TCP-RTU (ADU)
LE PROTOCOLE CANOPEN
Initialement développé pour être intégré sur un bus CAN, ce
protocole de communication économique et efficace intègre également
le profil des éléments communiquant sur le bus.
Figure 35 : Les 7 couches du modèle OSI
L’Open System Interconnection (OSI), un modèle de
communication entre ordinateur regroupant les fonctions
nécessaires au dialogue entre ces derniers, les divise en 7 couches
(Fig.35). Du point de vue OSI, le CANOpen prend en charge les
couches de Network à Application (Fig.36) contrairement au
Modbus qui ne gère que la couche Application.
26
Nicolas BRIOT (GE5)
Figure 36 : Le protocole CANOpen gère
les couches Network et supérieures
2016
En CANOpen, chaque élément du système dialoguant sur le bus CAN est appelé « Nœud » et
est une machine à états dotée d’une bibliothèque de données permettant un dialogue normalisé avec
les différents Nœud. Il s’agit du Dictionnaire Object ou OD, pour Object Dictionnary (Fig.37). Chaque
objet de ce dictionnaire est adressé par un Index (sur 16 bits) et éventuellement un Sub-Index (sur 8
bits, valant 0 par défaut).
Figure 37 : Exemple de Dictionnaire Objet
Une trame CANOpen est peu différente d’une trame CAN standard, on étudie donc plus en
détail cette dernière dans un premier temps (Fig.38). Sur un bus CAN (d’impédance nominale 120
Ohms) le 0 logique est dominant, ce qui signifie qu’un conflit sur le bus lui donnera la priorité. Par
ailleurs aucune information n’est représentée par une tension nulle pour pouvoir repérer un défaut
électrique sur le bus.
Figure 38 : Une trame CAN décomposée bit à bit (Wikipédia)
On explicite certains champs importants :
Arbitration Field : Contient le début de trame (un bit au 0 logique) et le CAN-ID du message sur 11 bits.
L’ID d’une trame CAN défini sa priorité sur le bus : plus il est faible (et donc comporte de 0) plus il est
prioritaire.
Data Field : La donnée transmise, sa taille étant fixée dans le champs précédant (Control Field).
CRC Field : Le CRC pour cyclic redundancy check, utilise un code de détection d’erreur (basé sur une
division polynomiale de la donnée du Data Field), on obtient un mot de 15 bits permettant de détecter
une erreur dans la trame reçue.
End of frame : Un mot de 7 bit ne contenant que des 1L annonce la libération du bus.
27
Nicolas BRIOT (GE5)
2016
Plus simplement, on peut supposer que la
trame ne contient qu’un CAN-ID et la donnée
transmise (Fig.39).
CAN-ID
11 bits
DATA
0 à 64 bits
Figure 39 : Schéma simpliste d'une trame CAN
En CANOpen, les 11 bits du CAN-ID sont séparés en deux blocs formant le CAN Objet ID (ou
COB-ID) (Fig.40) :
-
Les 4 premiers bits donnent la fonction du message
(Fig.41).
-
Les 7 bits restants décomptent les Noeud sur le bus
CAN (max 127 Noeuds).
COB-ID
Figure 40 : Composition du COB-ID en CANOpen
Les différentes fonctions importantes sont :
-
Network management (NMT), les
messages pour changer les états de
chaque Noeud, détecter les nouveaux
Noeuds sur le bus et les erreurs.
-
Service Data Object (SDO) message le
plus utilisé dans notre cas, permet la
lecture/écriture dans le dictionnaire
objet d’un Noeud.
-
Process Data Object (PDO) messages
temps-réel pouvant contenir jusqu’à
64bits.
Figure 41 : Extrait de spécification CANOpen précisant les
codes fonction
Ainsi les messages CANOpen sont simplement des trames CAN dotées d’une
codification dans leur en-tête permettant d’établir une communication standardisée entre
des Nœuds tous dotée de données structurées de la même façon.
28
Nicolas BRIOT (GE5)
2016
L’ENCAPSULATION MODBUS DE TRAMES CANOPEN
Le CANOpen est utilisé en interne (via bus CAN), l’utilisateur souhaitant dialoguer avec le
produit doit s’y connecter physiquement et concevoir les trames permettant l’accès aux données
désirées. Ce procédé étant peu pratique et fastidieux, une solution alternative consiste en l’utilisation
d’un autre protocole pour communiquer avec un des nœuds du système qui se chargera de diffuser la
commande en CANOpen en interne (Fig.42). Le protocole sélectionné dans un premier temps était le
Modbus-TCP.
L’ordinateur de l’utilisateur est un Client Modbus
User PC
La carte « COM » du système est
un Serveur Modbus et un Maître
CANOpen
COM Board
Les autres cartes du système sont
donc des Esclaves CANOpen
Other Boards
Figure 42 : Schéma de la hiérarchie dans les protocoles dans notre système
29
Nicolas BRIOT (GE5)
2016
Intéressons-nous à la construction des trames et à l’élaboration du VI permettant leur envoi,
cette dernière est soumise aux spécifications du CiA-309, document détaillant le standard pour
l’encapsulation du CANOpen dans une trame Modbus [4].
L’enveloppe (En-tête et fin de trame) Modbus reste inchangée, c’est le contenu du PDU qui
contient la partie CANOpen, on utilise la fonction 43 (2Bh) et le type de MEI 13 (Modbus Encapsulated
Interface 0Dh) spécialement prévus pour cet usage. Viennent ensuite les options de protocole et
finalement la trame du Service Data Object (SDO) CANOpen (Fig.43).
MODBUS PROTOCOL DATA UNIT (PDU)
Function code
DATA
1 Byte
N Bytes
(XXh)
(N*XXh)
Function code
MEI Type
Protocol Options
CANOpen Header
1 Byte
1 Byte
2 to 6 Bytes (4 optionals)
8 Bytes
CANOpen DATA
M Bytes
(2Bh)
(0Dh)
(XX XX XX XX XX XXh)
(XX XXXX XX XXXX XXXXh)
(M*XXh)
Figure 43 : Encapsulation de la trame CANOpen dans un PDU de trame Modbus
La vérification de la conformité des
trames envoyées et la correction des erreurs
éventuelles sont facilitées par l’emploi d’un outil
analyseur de paquets comme WireShark (Fig.44).
Nous pouvons ainsi filtrer les paquets
échangés entre notre ordinateur (172.23.22.45)
et le HIL (172.23.16.176) via le port 1025.
Ici, le code fonction ABh est reçu, il
correspond à une erreur dans la fonction 2Bh car
un code erreur de réponse est généré en ajoutant
80h au code fonction de la requête client.
Figure 44 : Analyse des paquets échangés
à l'aide du logiciel WireShark
30
Nicolas BRIOT (GE5)
2016
PRESENTATION DES PROTOCOLES A L’EQUIPE
Après avoir saisi les subtilités de ces deux
protocoles de communication, j’ai pu convier tout le
service FIRM à une réunion pour y effectuer un retour
d’expérience (Fig.45). La réunion a duré une trentaine
de minutes au cours desquelles nous avons tenté
d’impliquer un maximum les participants via des mises
en situation (composition de trames de requête et
réflexion sur les trames de réponse attendues).
Il s’agit de faire profiter l’équipe un maximum
des recherches effectuées au cours du stage.
Figure 45 : Support de la présentation dispensée sur les
protocoles CANOpen et Modbus
LES VIs DE COMMUNICATION
Nous avons produit de nombreux VI pour nous interfacer avec le HIL, aussi bien pour un
dialogue CANOpen over Modbus TCP que TCP-RTU. Dans chaque cas, il s’agit d’instancier un Maître
Modbus sur notre ordinateur (Fig.46) puis de générer les trames associées aux commandes que nous
souhaitons envoyer.
Figure 46 : VIs qui créent un Maître Modbus TCP (en haut) ou TCP-RTU (en bas) en local
31
Nicolas BRIOT (GE5)
2016
Nous utilisons les librairies Modbus fournies par National Instruments mais la fonction n’est
pas nativement gérée, il faut donc concevoir le PDU Modbus en y intégrant notre trame CANOpen
(Fig.47). Par la suite, nous avons produit une interface de test permettant l’envoi de commandes
élémentaires ou personnalisées au HIL (Fig.48).
Figure 47 : Génération d'un PDU Modbus encapsulant une trame CANOpen
Figure 48 : Interface de test LabVIEW permettant l'envoi de commandes
Nous avons ainsi la possibilité d’envoyer des requêtes et de recevoir des réponses du
prototype, seulement pour cela il nous faut nous pencher sur le contenu des requêtes que SOCOMEC
envoie aux onduleurs.
32
Nicolas BRIOT (GE5)
2016
7.4 – ANALYSE ET EMPLOI DES FICHIERS .INI
En interne, SOCOMEC emploie des fichiers texte appelés « INI Files » référençant l’adressage
CANOpen et Modbus des différentes commandes, alarmes, mesures et états accessible en lecture
et/ou en écriture via leur logiciel propriétaire « XpertSoft » (Fig.49). Ce dernier permet accessoirement
le monitoring des trames échangées avec le produit : en vert les requêtes passées au H.I.L et en jaune
les réponses reçues.
Figure 49 : Interface de XpertSoft (à gauche) et extrait d'un INI file (à droite)
Ces fichiers sont peu lisibles et plutôt difficiles d’emploi, en ce sens, on nous a demandé de
proposer et générer un format plus accessible et pratique. Nous y reviendrons par la suite.
Les premières tentatives de « parser » dans les fichiers textes sont probantes mais peu
efficaces : l’analyse de chaînes de caractère (Fig.50) se révèle couteuse en ressources et donc en temps
de calcul.
Figure 50 : Première solution de Parsing des INI Files employant l'analyse du texte
33
Nicolas BRIOT (GE5)
2016
LE STOCKAGE DES INFORMATIONS DANS UNE BDD
Une première proposition soutenue par un ingénieur du service de production était d’extraire
les informations (appelées « clés ») pour les stocker dans une base de données MySQL. Après avoir
soumis à l’ingénieur un modèle de structure pour les tables de la base, nous avons entamé son
remplissage (Fig.51).
Figure 51 : Contenu de la base de données MySQL générée pour le projet HIL
Cette base est remplie au moyen d’un VI qui initie une connexion MySQL puis accède à la table
choisie pour y écrire les clés extraites des fichiers INI via un second mécanisme de « parsing » plus
performant que celui mentionné plus haut (Fig.52).
Figure 52 : VI permettant l'ajout des données extraites dans une BDD
34
Nicolas BRIOT (GE5)
2016
LA GENERATION DE FICHIER XML ET XSD
La solution retenue car appuyée par nos consultants en matière d’architecture Software,
MESULOG, est de produire un fichier eXtendable Markup Language (XML) répertoriant de façon claire
et synthétique toutes les informations nécessaires au dialogue avec le produit. Ce langage possède
notamment une structure en arborescence pour une meilleure lisibilité (Fig.53 gauche).
Une fois la structure globale de ce fichier établie, il faut définir strictement les attributs de
chaque objet s’y trouvant, leur type et leur place dans la hiérarchie. Cette syntaxe et ces critères de
validités sont fixés par un fichier XSD (XML Schema Definition) appairé au fichier XML (Fig.53 droite).
Un Plug-In de Notepad++ (logiciel d’édition et de lecture de code) appelé XML Tools permet
ensuite de vérifier que notre fichier XML respecte tous les critères imposés (Fig.53 droite-bas).
Figure 53 : Aperçu du fichier XML regroupant les clés de protocole (à gauche) et du fichier XSD de définition des règles du schéma (à droite) ainsi
qu'un message d'erreur obtenu via XML Tools
Figure 54 : Vue d'ensemble du VI permettant l'extraction des clés d'un ensemble de fichiers INI pour générer un XML associé
35
Nicolas BRIOT (GE5)
2016
7.5 – L’AJOUT DES ACRONYMES HIL
REFONTE DU VI GENERANT LE FICHIER XML
Le VI effectuant la conversion des INI files en un unique fichier XML, bien que parfaitement
fonctionnel, s’avérait complexe à débuguer, maintenir et à faire évoluer (Fig.54).
En ce sens nous avons remanié sa structure afin de permettre une meilleure lisibilité et
modularité du code : nous avons mis l’accent sur la création de SubVI et de définitions de type (Clusters
standardisés) au maximum. Nous avons par la suite ajouté un bloc de conversion des acronymes dont
nous détaillerons l’utilité et le fonctionnement ci-après (Fig.55).
Figure 55 : VI générant le fichier XML de protocole après refonte, sont encadrés (en rouge) les subVI s
permettant la correspondance des acronymes
De plus, afin de standardiser et réglementer la mise à jour des fichiers XML, nous avons mis
en place un fichier appelé « INI_TYPES.xml » qui fige les règles du parsing des fichiers .INI. Il spécifie
l’ordre d’apparition et le type de chacun des attributs de chaque type de donnée (Fig.56).
Figure 56 : Capture du fichier INI_Types.xml
36
Nicolas BRIOT (GE5)
2016
CONCORDANCE DES ACRONYMES HIL ET SOFT
Afin de pouvoir manipuler facilement les mesures obtenues sur le système, nous avons créé
une liste d’Acronymes HIL censé être plus explicites et ne pas varier d’une mise à jour des fichiers INI
à l’autre ni d’un type de produit à l’autre (Fig.57).
Le but recherché est également d’amener le département de production à employer ces
acronymes et nos fichiers XML afin de standardiser le nommage des différentes variables employées.
A terme, une uniformisation des outils de tests pourrait permettre la simple mise en commun des
séquences et sous-séquences utilitaires de tests (moyennant une légère adaptation) entre les
différents acteurs de la vérification des UPS SOCOMEC.
Figure 57 : Aperçu du fichier XML contenant les acronymes produit et HIL
Ce fichier est importé dans LabVIEW pour y effectuer le remplacement des acronymes produits
(Product) par leur équivalent HIL standardisés, un VI subVI gère la récupération des paires d’acronymes
pendant que le second effectue l’échange dans les tables de données recueillies des fichiers INI. La
transposition des acronymes est facultative : un contrôle permet de l’activer ou non.
Il est important de noter que seules les tables dont on trouve un équivalent acronyme HIL sont
conservées au terme du remplacement, puisque seules ces dernières seront utilisées pour les
communications durant les tests et la vérification et production.
L’équipe doit assurer le développement de cette table en la complétant puis en mettant à jour
le fichier XML du projet au moyen des VI développés pendant le stage.
37
Nicolas BRIOT (GE5)
2016
7.6 – CONCEPTION DES SEQUENCES DE TEST
SUIVI DE LA FORMATION TESTSTAND
Du 11 au 13 mai 2016 nous avons suivi la formation NI TestStand 1 afin d’acquérir les bases et
bonnes pratiques en matière de séquençage de tests avec les outils NI. Un ingénieur diplômé de l’INSA
de Lyon, Hugues FAYARD, nous a accompagné dans des exercices de prise en main et nous a fourni des
conseils pour la mise en place de l’architecture de test.
PRESENTATION DU LOGICIEL ET DE SON INTERFACE
Ce logiciel permet la création et l’édition de séquences de
test et les Step utilisés peuvent être codés dans de nombreux
langages tels que le C/C++, .Net ou LabVIEW (Fig.58).
Une notion importante est celle de l’identité de l‘utilisateur,
deux profils existent. « Le développeur » accède à l’éditeur de
séquence pour concevoir/débugger les séquences de test
contrairement à « l’opérateur » qui n’accède qu’à une interface de
monitoring et d’exécution.
Figure 58 : Structure du logiciel TestStand
L’interface graphique de TestStand (Fig.59) paraît complexe à première vue mais se découpe
en fait en fenêtres élémentaires qui sont individuellement très simples :
-
La liste des séquences et sous-séquences du fichier
Le déroulement de la séquence sélectionnée
Liste des variables manipulables
Paramètres du pas de test (ou « Step ») sélectionné dans la séquence
Figure 59 : Découpage de l'interface graphique de TestStand
38
Nicolas BRIOT (GE5)
2016
CONCEPTION DES SEQUENCES ET LEUR ARCHITECTURE
L’objectif du projet est d’obtenir une séquence principale regroupant l’intégralité des tests à
effectuer pour que le code embarqué respecte l’ensemble des spécifications logicielles établies pour
HPP. C’est Thierry Rohmer, notre maître de stage et architecte logiciel, qui se chargeait en partie de
leur rédaction et de leur « digestion » pour nous les communiquer.
Après discussion avec nos consultants, il nous est apparu préférable de ne pas opter pour une
structure parallèle pour nos tests : lancer plusieurs threads poserait de gros soucis d’organisation
autours de sémaphores et nécessiterait une étude bien plus poussée de la structure de nos tests.
Nous avons également défini que le rapport généré par le séquenceur serait au format XML
pour faciliter son traitement automatisé.
L’UTILISATION DES CALLBACKS
TestStand fourni plusieurs modèles de
séquenceur (ou « Process Model ») à l’utilisateur
qui édite les séquences. Comme nous ne
souhaitons pas paralléliser nos tests (pas encore)
nous utilisons le modèle Séquentiel fourni par NI.
Celui-ci nous laisse la possibilité d’effectuer un
test unitaire (Single Pass) ou des tests unitaires
successifs (Test UUTs) (Fig.60).
Dans les deux cas, le fichier séquence
que nous développons est appelé à un moment.
S’il
contient
une
Séquence
appelée
« MainSequence » cette dernière est alors
exécutée à ce moment, ce mécanisme est appelé
un Callback. Chacune des étapes présentées
dans le Process Model peut être remplacée par
une séquence du développeur portant le même
nom. D’ailleurs la plupart des séquences Figure 60 : Deux possibilités pour un Process Model dit séquentiel
présentes sont vides à l’origine car créées juste
pour que le développeur puisse les remplacer.
En ce sens, nous avons par exemple développé un Callback permettant de recommencer un
envoi de requête Modbus ayant échoué. La séquence « SequenceFilePostStepRuntimeError » teste le
code erreur reçu et dans le cas où il s’agit d’une simple erreur de timing/perte de connexion, envoie la
requête à nouveau une unique fois.
39
Nicolas BRIOT (GE5)
2016
7.7 – DEVELOPPEMENT D’OUTILS POUR LE DEPARTEMENT
Le bon déroulement du projet passe également par la mise en place d’outils facilitant
l’utilisation du HIL. J’ai passé la majeure partie de la fin de mon stage à développer ces outils tout en
restant à la disposition de l’équipe pour assister au développement des séquences de test. Chacun des
programmes inclus une gestion d’erreur poussée afin de permettre une maintenance aisée.
OUTIL COMPLETANT AUTOMATIQUEMENT LA MATRICE DE
TRAÇABILITE
La matrice de traçabilité est contenue dans un fichier Excel, elle répertorie l’ensemble des
spécifications du projet HPP et leur état de validation. Lors de la validation de ces spécifications au
cours d’un test, l’utilisateur doit aller écrire manuellement dans le fichier Excel le résultat de chaque
test au bon endroit. Cette opération est très fastidieuse.
Définition du besoin, le programme devait :
-
Ouvrir la matrice dans Excel à partir du chemin du fichier spécifié par l’utilisateur
Analyser le rapport du test (chemin spécifié) à la recherche de toutes les spécifications
mentionnées et pour chacune récupérer l’état (passed/failed) du test la validant
Indiquer ces résultats dans la matrice de traçabilité (OK/NOK) et sauvegarder
Gérer les versions des spécifications pour prévenir de l’obsolescence d’un test
Produire un rapport au format texte de l’ensemble des remarques/erreurs rencontrées
durant l’exécution
Temps de développement approximatif : 50h
Résultats : Programme fonctionnel et commenté
Code en Annexe 1 (Fig.65)
Figure 61 : Face avant (à gauche) et vue d'ensemble du projet (à droite) de l'outil complétant la matrice de traçabilité
40
Nicolas BRIOT (GE5)
2016
OUTIL DE VERIFICATION D’INI FILES (FICHIER UNIQUE)
Les INI Files regroupent l’intégralités des informations nécessaires au dialogue avec l’électronique de
commande HPP. Leur complétion s’effectue majoritairement à la main par les gens du FIRM, ils sont
donc sujet à un grand nombre d’erreurs qui s’avèrent difficiles à trouver.
Définition du besoin, le programme devait :
-
-
A l’exécution, rechercher un fichier .INI situé dans le même dossier et l’ouvrir
Analyser le .INI à la recherche de toutes les erreurs possibles à savoir :
o Un même Acronyme apparaît plusieurs fois dans le fichier
o Une variable n’est pas du type attendu (String, Numeric, Boolean)
o La taille cumulée de toutes les informations d’une table dépasse celle de la table
o Un attribut attendu est manquant (ou bien un attribut est en trop)
Produire un rapport au format texte de l’ensemble des erreurs trouvées
Temps de développement approximatif : 40h
Résultats : Programme fonctionnel
Code en Annexe 1 (Fig.66)
Figure 62 : Exemple d'utilisation de l'outil de vérification d'un seul fichier INI dans un
dossier (en bas) et ouverture du rapport généré (en haut)
41
Nicolas BRIOT (GE5)
2016
OUTIL DE VERIFICATION DE PLUSIEURS INI FILES EN
COMPARAISON
Par ailleurs, les INI Files se doivent d’avoir certaines tables en commun, de mêmes tailles ou
comportant certains éléments identiques entre les différents fichiers. On m’a donc chargé de
développer un second code vérifiant ces propriétés entre les fichiers INI.
Définition du besoin, le programme devait :
-
-
A l’exécution, rechercher tous les fichiers .INI situés dans les sous-dossiers et les ouvrir
Analyser ces .INI et s’assurer que certaines tables présentes dans les logs du prototype
respectent quelques règles, à savoir :
o Les tables dotées du même Node_ID doivent avoir la même taille, exception faite
des tables d’index 5000
o Les tables d’index 4012 doivent toutes avoir une description identique pour
chaque élément de même position dans la table
Produire un rapport au format texte de l’ensemble des erreurs trouvées
Temps de développement approximatif : 30h
Résultats : Code fonctionnel
Code en Annexe 1 (Fig.67)
Figure 63 : Gestion d'erreur (en bas) et fenêtre contextuelle de fin
d'exécution (en haut) de l'outil de vérification de multiples .INI
Figure 64 : Vue d'ensemble du projet commun des
deux outils de vérification de fichiers INI
42
Nicolas BRIOT (GE5)
2016
8 – CONCLUSION
A l’issue de ce stage, nous laissons derrière nous un projet parfaitement fonctionnel et
maintenable. Nous n’avons pas pu achever l’intégralité des séquences de test ni réaliser d’interface
opérateur mais l’équipe a assimilé toutes les compétences que nous avions à lui transmettre avant la
fin de ces six mois et la pérennité du HIL est ainsi assurée.
Les bénéfices pour l’entreprises sont clairement visibles. Le prototype possède un
fonctionnement extrêmement proche de la réalité physique, si bien que des défauts de code
apparaissant sur le produit réel ont pu être reproduit et corrigé sur le banc HIL grâce à une débug bien
plus aisée et poussée que sur plateforme. La durée du cycle de validation et de développement s’en
trouve fortement réduite, le nombre de feedbacks apportés par le HIL étant grand, des améliorations
possibles du code sont rapidement trouvées par l’expérimentation. Des défauts peuvent être
volontairement injectés pour étudier le comportement et la robustesse du produit sans présenter le
moindre danger pour l’utilisateur ou risque de dégradation du prototype. Enfin, le banc se trouve être
extrêmement adaptable à des changements de hardware : il suffit alors de modifier le schéma PSIM.
Par ailleurs, ce stage m’a apporté énormément, tant sur le plan technique qu’humain.
Le contact régulier avec les consultant dans le cadre d’une étroite collaboration est une
expérience de grande valeur pour un ingénieur en devenir, j’ai été convié à de nombreuses réunions
me permettant de nous familiariser avec les outils organisationnels clés de l’entreprise (KANBAN, TOP,
GANTT, SWOT, …) et ai également organisé des réunions dans lesquelles j’ai pris la place d’un
acteur/animateur majeur. La reconnaissance et la grande sollicitation montrées par mes collègues
m’ont donné un grand sentiment d’appartenance à l’entreprise et j’espère avoir pu leur communiquer
le plaisir que j’ai eu à travailler avec eux.
Sur le plan technique, j’ai vraiment beaucoup appris durant ces six mois, nous avons reçu trois
formations accélérées très coûteuse et obtenu une certification dans le domaine du test fonctionnel
avec les outils NI. Un tel profil est très recherché car rare pour des jeunes diplômés, aussi Cédric et
moi-même avons déjà reçus plusieurs offres dans ce domaine. Toutes les connaissances accumulées
au cours de ce stage peuvent se révéler de précieux atouts dans ma future carrière technique, des
protocoles comme le Modbus et le CANOpen sont d’usage courant et le développement collaboratif
sous SVN l’est tout autant.
Ainsi, je quitte SOCOMEC avec la conviction d’y avoir effectué un excellent travail.
La suite de ma carrière va prendre une tournure plus managériale et commerciale, j’ai en effet
signé, le jour même de la fin de mon PFE chez SOCOMEC, un CDI au sein d’Abylsen SUD en tant
qu’Ingénieur d’Affaires Junior. Je commence le 07/09/16 soit le surlendemain de ma soutenance !
43
Nicolas BRIOT (GE5)
2016
9 – BIBLIOGRAPHIE
[1] Creating Models in NI LabVIEW for Use in NI VeriStand; NI Tutorials (2016)
[2] Modbus Application Protocol Specification V1.1b; Modbus-IDA, Pages 12-50 (2006)
[3] CiA 301 CANopen application layer and communication profile V4.2.0; CiA (2011)
[4] CiA 309-2 Interfacing CANopen with TCP/IP - Part 2: Modbus/TCP mapping V1.1; CiA,
Pages 6-15 (2006)
44
Nicolas BRIOT (GE5)
2016
10 – REMERCIEMENTS
Je souhaite, en premier lieu, remercier l’ensemble de l’équipe des Ressources
Humaines de m’avoir convoqué pour l’entretien initial et accueilli au sein de l’entreprise.
Je tiens ensuite à remercier Jean-Louis SCHRICKE et Mathieu REYROLLE, société
MESULOG pour leur soutien technique et leurs conseils tout au long de ce projet qu’ils
continuent de porter après mon départ.
Je tiens à dire un grand merci à tous les professionnels qui nous ont dispensés les
formations nécessaires au bon déroulement du projet : Hugues FAYARD (STYREL), Rémi DA
SILVA (NATIONAL INSTRUMENTS) et Sébastien CENSE (OPAL-RT).
J’adresse également ma reconnaissance à tout le département R&D de l’Usine 3 et
plus encore à l’équipe FIRM au sein de laquelle j’ai vraiment apprécié travailler et me
développer durant ces six derniers mois.
Pour finir, toute ma gratitude va à mes deux maîtres de stage, Thierry ROHMER et Eric
PLUMERE ainsi qu’à mon collègue et ami Cédric SCHRAMM avec qui j’ai eu la joie et la chance
de partager un bureau et un projet pendant ce PFE, je ne connais à ce jour pas de cadre de
travail plus agréable qu’à leurs côtés.
45
Nicolas BRIOT (GE5)
2016
11 – ANNEXES
11.1 – ANNEXE 1 : CODE LABVIEW DES OUTILS DEVELOPPES
Figure 65 : Code de l'outil complétant la matrice de traçabilité
Figure 66 : Code de l'outil de vérification d'un seul fichier INI
Figure 67 : Code de l'outil de vérification de multiples fichiers INI
46
Nicolas BRIOT (GE5)
2016
11.2 – ANNEXE 2 : SCHEMA GENERAL DE L’ELECTRONIQUE HPP
Figure 68 : Schéma général de l'électronique de commande HPP
47
Nicolas BRIOT (GE5)
2016
11.3 – ANNEXE 3 : SCHEMA PSIM DE LA PARTIE PUISSANCE HPP
Figure 69 : Schéma PSIM de la partie puissance du projet HPP (avec transformateur)
48
Nicolas BRIOT (GE5)
2016