Design of a platform to test distributed control systems

Design of a platform to test distributed control systems Miquel Perell´o Nieto Facultat d’Inform`atica de Barcelona Universitat Polit`ecnica de Catalunya Directors: Josep M. Fuertes Armengol Manel Velasco Garcia Mem`oria de Projecte Final de Carrera Enginyeria T`ecnica en Inform`atica de Sistemes Gener 2011 1. Directors: Josep M. Fuertes Armengol i Manel Velasco Garcia 2. President: Pere Mar´es Mart´ı 3. Vocal: Robert Lukas Mario Nieuwenhuis Dia de lectura: Signatura del tribunal del PFC: ii Resum El prop`osit d’aquesta mem`oria ´es el d’explicar la import`ancia que tenen els Sistemes Distribu¨ıts de Control, i els problemes que sorgeixen al controlar sistemes din`amics en temps real. Per tal de mostrar aix`o, des del departament de ESAII s’han dissenyat una s`erie de laboratoris amb els quals els estudiants poden entendre i resoldre els problemes que d’aquest tema se’n deriven. Amb la realitzaci´o d’aquest projecte es va procurar donar un pas m´es amb aquest prop`osit i d’aquesta manera es va dissenyar un sistema de monitoritzaci´o i control sobre les comunicacions entre diferents dispositius que formen lla¸cos de control en el medi compartit d’un bus CAN. La mem`oria ´es el reflex de les tecnologies que es troben en aquests Sistemes i els programes que s’han creat i/o modificat per controlar-los. Entre ells s’en destaca el programa DCSMonitor , creat ´ıntegrament en aquest projecte, i dissenyat modularment per tal de servir com a base en qualsevol entorn futur. Igualment per la part dels dispositius del bus CAN, els quals amb un disseny escalable realitzat en el projecte, poden servir per una infinitud d’objectius nous, i per la realitzaci´o de projectes enfocats a aquest tipus de sistemes. Per tant amb la finalitzaci´o d’aquest projecte, queden obertes moltes possibilitats, i s’espera que tant en l’entorn acad`emic com en l’industrial, es puguin utilitzar les seves idees. Tot el material emprat en la realitzaci´o d’aquest projecte pot ser consultat en el repositori http://code.google.com/p/pfc-platform-test/ Per la realitzaci´o de la pressent mem`oria ha estat emprat un template de LaTeX el qual es pot trobar en la bibliografia (1) iv Dedicat al meu pare, per haver-me deixat llibertat en els estudis, permetrem decidir equivocar-me i aprendre dels meus errors, i tot i aix´ı no deixar d’ajudar-me en tot moment. A la meva fam´ılia, per ensenyar-me cadascun una cosa nova a la seva manera. I a la meva mare. Agra¨ıments Agraeixo al meu tutor Pep Fuertes que un dia es deix´es veure en una conferencia sobre grans telescopis, i em captiv´es des d’ aquell instant ja fa algun any. Que el torn´es a trobar accidentalment buscant un Projecte Final de Carrera, proposant ampliar el laboratori de Sistemes Distribu¨ıts de Control i que jo accept´es sense saber ven b´e que eren, perqu`e for¸cosament havia de ser alguna cosa molt interessant. I perqu`e encara que sembl´es tenir les coses descontrolades, realment guard´es un control absolut de tot. Tamb´e haig de donar les gr`acies a l’altre tutor Manel Velasco, per poderme dedicar el temps suficient i just per tirar endavant el projecte; per fer f`acils les coses que semblaven dif´ıcils, per ensenyar-me una infinitud de tecnologies desconegudes per mi, per ferme pensar en algun moment que ell era l’inform`atic, per ajudar-me en els moments que estava perdut, i per tranquil·litzar-me quan pensava que no m’en sortiria. Gracies tamb´e al Pau Mart´ı per estar donant suport sense la seva presencia f´ısica per e-mails i una trucada sorpresa. Sobretot haig de donar les gracies a la meva novia Virg´ınia Rodr´ıguez, per obligar-me a aparcar el projecte de tant en tant, i treure’m literalment de casa per descansar. I per comprendre en certs moments que realment de tant en tant s’ha de fer feina. Gracies tamb´e a la Pantera i al Kobu, per fer-me companyia en els moments en els que estava sol en el projecte, i no demanar r´es a canvi (b´e... una mica de pinso i aigua s´ı...). ”en definitiva gracies a tothom, perqu`e sense ning´u res d’aix`o tindria cap sentit” ´ Index ´ Index de figures vii ´ Index de taules xiii ´ Index de codis xvi Glossari xvii 1 Introducci´o 1 1.1 Estructuraci´o de la mem`oria . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Motivaci´o ................................... 4 1.3 Abast ..................................... 5 1.3.1 Objectius ............................... 5 1.4 Planificaci´o .................................. 7 2 Tecnologia 15 2.1 Hardware ................................... 15 2.1.1 FLEX ................................. 16 2.1.2 dsPIC33FJ256MC710 . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.3 MCP2551............................... 18 2.1.4 ICD2/3 ................................ 19 2.2 Software.................................... 20 2.2.1 Eclipse................................. 20 2.2.2 MPLABR X ............................. 21 2.2.3 QtCreator............................... 22 2.2.4 QtLing¨uist .............................. 22 2.2.5 ERIKA Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . 22 iii ´ INDEX 2.3 Protocols de comunicaci´o . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.1 CAN.................................. 23 2.3.2 SerieviaRS232............................ 24 2.3.3 Topologiaenbus........................... 26 2.4 Conclusions.................................. 27 3 Disseny del laboratori 29 3.1 Resum del laboratori actual . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Disseny del Nou laboratori . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.1 Interficie................................ 35 3.2.2 Identificadors dels missatges CAN . . . . . . . . . . . . . . . . . 38 3.2.2.1 Missatge de control per l’Actuador ........... 42 3.2.2.2 Missatge de l’estat del Sensor per al Controlador . . . 42 3.2.2.3 Missatge de canvi de refer`encia . . . . . . . . . . . . . . 43 3.2.2.4 Missatge de l’estat del Sensor per al Supervisor . . . . 44 3.2.3 Comunicaci´o s`erie . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2.3.1 Senyals de control per monitoritzar . . . . . . . . . . . 49 3.2.3.2 Senyals de control per consultar lla¸cos . . . . . . . . . . 50 3.2.3.3 Senyals de control per generar c`arrega . . . . . . . . . . 51 3.2.4 Gr`afiques en temps real . . . . . . . . . . . . . . . . . . . . . . . 52 3.2.5 Idiomes ................................ 54 3.3 Conclusions.................................. 55 4 Implementaci´o del laboratori 57 4.1 DCSMonitor ................................ 58 4.1.1 Interficie................................ 59 4.1.2 Comunicaci´o s`erie RS232 . . . . . . . . . . . . . . . . . . . . . . 62 4.1.2.1 Obrir i tancar dispositiu s`erie . . . . . . . . . . . . . . . 62 4.1.2.2 Enviar petici´o de llistar lla¸cos de control . . . . . . . . 66 4.1.2.3 Enviar petici´o de monitoritzaci´o . . . . . . . . . . . . . 67 4.1.2.4 Enviar percentatge de c`arrega . . . . . . . . . . . . . . 70 4.1.2.5 Recepci´o de valors monitoritzats . . . . . . . . . . . . . 71 4.1.2.6 Recepci´o de llista de dispositius . . . . . . . . . . . . . 76 4.1.3 Generaci´o de gr`afiques en temps real . . . . . . . . . . . . . . . . 77 iv ´ INDEX 4.1.4 Exportargr`afica ........................... 79 4.1.5 Mostrant estad´ıstiques . . . . . . . . . . . . . . . . . . . . . . . . 87 4.1.6 Idiomes ................................ 89 4.1.6.1 PyQT4 ........................... 89 4.1.6.2 Pylupdate4......................... 90 4.1.6.3 QtLing¨uist ......................... 91 4.1.6.4 Resultat .......................... 91 4.2 dsPIC ..................................... 93 4.2.1 TasquesenErika........................... 94 4.2.2 Comunicaci´o serie RS232 . . . . . . . . . . . . . . . . . . . . . . 96 4.2.2.1 Recepci´o de senyals de control . . . . . . . . . . . . . . 96 4.2.2.2 Enviament de dades . . . . . . . . . . . . . . . . . . . . 99 4.2.3 Comunicaci´o bus CAN . . . . . . . . . . . . . . . . . . . . . . . . 102 4.2.3.1 Creaci´o de les m`ascares CAN . . . . . . . . . . . . . . . 102 4.2.3.2 Creaci´o dels filtres CAN . . . . . . . . . . . . . . . . . . 103 4.2.3.3 Recepci´o de missatges CAN . . . . . . . . . . . . . . . . 105 4.2.3.4 Pila de lla¸cos de control . . . . . . . . . . . . . . . . . . 108 4.2.3.5 Tractant missatges de control per l’Actuador ...... 110 4.2.3.6 Tractant missatges d’estat del Sensor per al Controlador ............................ 112 4.2.3.7 Tractant missatges de canvi de referencia . . . . . . . . 115 4.2.3.8 Tractant missatges d’estat del Sensor per al Supervisor 116 4.2.3.9 Tractant la resta dels missatges . . . . . . . . . . . . . 117 4.2.3.10 Monitoritzaci´o d’un lla¸c de control . . . . . . . . . . . . 118 4.3 Conclusions.................................. 119 5 An`alisi econ`omic 121 5.1 Material.................................... 121 5.2 Mad’obra................................... 122 6 Conclusions 127 6.0.1 Treballfutur ............................. 129 v ´ INDEX DE FIGURES xii ´ Index de taules 1.1 Estimaci´o de la duraci´o del projecte . . . . . . . . . . . . . . . . . . . . 7 1.2 Horesdededicaci´o .............................. 9 2.1 Pinatge del connector serie per RS232 . . . . . . . . . . . . . . . . . . . 25 3.1 Identificadors dels senyals de control enviats al Monitor per RS232. . . . 47 4.1 M`ascares per bus CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.2 Configuraci´o dels filtres . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.1 Preu del material necessari . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.2 Preus hora de cada rol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.3 Desglos del preu de la ma d’obra . . . . . . . . . . . . . . . . . . . . . . 123 5.4 Hores dedicades per rol . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 A.1 Compatibilitat dels programadors amb MplabX. . . . . . . . . . . . . . 150 B.1 Usuari i contrasenya Live CD ....................... 157 B.2 Elements de l’escriptori . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 B.3 Elements del directori ∼/workspace/Programs/ ............. 159 B.4 Compatibilitat dels programadors amb MplabX. . . . . . . . . . . . . . 164 xiii ´ INDEX DE TAULES xiv ´ Index de codis 4.1 Fragment del fitxer d’interficie dcsmmainwindow.ui . . . . . . . . . . . . 59 4.2 Creant fitxer d’interficie . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3 Fragment de codi del fitxer dcsmmainwindow.py . . . . . . . . . . . . . 60 4.4 Codi per configurar dispositiu s`erie . . . . . . . . . . . . . . . . . . . . . 62 4.5 Disparador de connexi´o de port serie . . . . . . . . . . . . . . . . . . . . 62 4.6 Codi per obrir/tancar dispositiu s`erie . . . . . . . . . . . . . . . . . . . . 63 4.7 Codi per connectar port serie . . . . . . . . . . . . . . . . . . . . . . . . 64 4.8 Disparador de bot´o llistar dispositius . . . . . . . . . . . . . . . . . . . . 66 4.9 Codi per demanar una llista de lla¸cos de control . . . . . . . . . . . . . 66 4.10 Disparador de bot´o per monitoritzar . . . . . . . . . . . . . . . . . . . . 67 4.11 Codi per demanar monitoritzar un lla¸c de control . . . . . . . . . . . . . 68 4.12 Disparador de barra de c`arrega . . . . . . . . . . . . . . . . . . . . . . . 70 4.13 Codi per demanar que saturi el bus CAN . . . . . . . . . . . . . . . . . 70 4.14 Temporitzador i disparador per rebre dades del port serie . . . . . . . . 71 4.15 Codi per reactivar l’adquisici´o de dades . . . . . . . . . . . . . . . . . . 72 4.16 Codi per rebre els valors monitoritzats . . . . . . . . . . . . . . . . . . . 73 4.17 Codi per rebre la llista de dispositius . . . . . . . . . . . . . . . . . . . . 76 4.18 Temporitzador i disparador per dibuixar la gr`afica . . . . . . . . . . . . 77 4.19 Codi per actualitzar la gr`afica . . . . . . . . . . . . . . . . . . . . . . . . 78 4.20 Disparador per exportar la gr`afica . . . . . . . . . . . . . . . . . . . . . 80 4.21 Codi per generar imatge d’una gr`afica . . . . . . . . . . . . . . . . . . . 81 4.22 Temporitzador i disparador per actualitzar les estad´ıstiques. . . . . . . . 87 4.23 Codi per generar i actualitzar les estad´ıstiques. . . . . . . . . . . . . . . 88 4.24 Exemple de text per traduir . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.25Canviantidioma ............................... 90 xv ´ INDEX DE CODIS 4.26 Crear fitxers per traduccions . . . . . . . . . . . . . . . . . . . . . . . . 90 4.27 Exemple de declaraci´o d’una tasca en el fitxer conf.oil . . . . . . . . . . 94 4.28 Codis per interactuar amb tasques . . . . . . . . . . . . . . . . . . . . . 96 4.29 Declaraci´o dels valors dels senyals de control . . . . . . . . . . . . . . . . 96 4.30 Interrupci´o buffer del port s`erie . . . . . . . . . . . . . . . . . . . . . . . 97 4.31 Alarma de supervisi´o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.32 Tasca de Supervisi´o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.33Funci´oeCAN1config............................. 103 4.34 Definicions per la creaci´o de filtres CAN . . . . . . . . . . . . . . . . . . 104 4.35 Funcio activada per una interrupci´o del bus CAN . . . . . . . . . . . . . 106 4.36 Pila d’identificadors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.37Inicialitzarpila ................................ 109 4.38 Comprovar si la pila ´es plena . . . . . . . . . . . . . . . . . . . . . . . . 109 4.39Buscaralapila................................ 110 4.40Afegiralapila ................................ 110 4.41Treuredelapila ............................... 110 4.42 Captura del missatge de control per l’Actuador .............. 111 4.43 Tasca per capturar el valor de l’actuador . . . . . . . . . . . . . . . . . . 111 4.44 Tasca per aplicar el valor al PWM . . . . . . . . . . . . . . . . . . . . . 112 4.45 Captura del missatge d’estat del Sensor al Controlador . . . . . . . . . . 112 4.46 Tasca per capturar el valor d’estat del control . . . . . . . . . . . . . . . 113 4.47 Tasca per fer els calculs del control . . . . . . . . . . . . . . . . . . . . . 113 4.48 Funci´o per enviar senyal de control per bus CAN . . . . . . . . . . . . . 114 4.49 Captura del missatge de canvi de referencia . . . . . . . . . . . . . . . . 115 4.50 Captura del missatge d’estat del Sensor al Supervisor . . . . . . . . . . 116 4.51 Tasca que emmagatzema els valors d’estat del Sensor . . . . . . . . . . . 117 4.52 Captura de la resta de missatges . . . . . . . . . . . . . . . . . . . . . . 117 4.53 Creant filtres per monitoritzar un lla¸c de control . . . . . . . . . . . . . 118 A.1 Instalar Java Runtime Environment en Ubuntu . . . . . . . . . . . . . . 132 A.2 Comprobant mplab descarregat en Ubuntu . . . . . . . . . . . . . . . . 134 A.3 Instalar MPLAB R XenUbuntu ...................... 134 A.4 Instalar compilador mplab 30 en Ubuntu . . . . . . . . . . . . . . . . . . 134 A.5 Instalar Eclipse en Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . 137 xvi Glossari .elf Sigles en Angl`es de Executable and Linkable Format (Format Enlla¸cable i Executable ); ´es un format de fitxers per executables, codi obert, biblioteques compartides i bolcat de mem`oria. Va ser dissenyat per Unix System Laboratories, i en principi va ser desenvolupat per plataformes de 32 bits, encara que actualment s’utilitza en varietat de plataformes. .qm Extensi´o d’un tipus de fitxers que utilitza la llibreria PyQT4 per traduir textos. .svg Sigles en Angl`es de Scalable Vector Graphics (Gr`afics Vectorials Escalables); ´es una especificaci´o per descriure gr`afics vectorials bidimensionals, tant est`atics com din`amics, en format XML. .ts De l’Angl`es Translation files (Fitxers de traducci´o); Tipus d’extensi´o de fitxers utilitzats per QtLing¨uist per crear traduccions dels textos d’un programa. .ui Sigles en Angl`es de User Interface (Interficie d’usuari’); ´es un format de fitxers creat per la casa QT, i amb informaci´o necess`aria per muntar la interf´ıcie visual d’un programa. Actuador L’actuador en un sistema distribu¨ıt de control ´es l’encarregat de assignar el valor calculat pel controlador a l’entrada del circuit a controlar. API Sigles en Angl`es de Application Programming Interface (Interf´ıcie de Programaci´o d’Aplicacions); ´es un conjunt de declaracions amb el prop`osit de ser usades per un altre programa com una capa d’abstracci´o. CAN Sigles en Angl`es de Controller Area Network;´ Es un protocol de comunicacions desenvolupat per la firma alamanya Robert Bosch GmbH, basat en una topologia en bus per la transmissi´o de missatges en entorns distribu¨ıts. Controlador El controlador en sistema distribu¨ıt de control ´es l’encarregat de calcular el valor a donar al actuador per tal de aconseguir un senyal desitjat. DCS Sigles en Angl`es de Distributed Control System (Sistema Distribu¨ıt de Control); s´on sistemes de control aplicats generalment en sistemes de fabricaci´o, o qualsevol tipus de sistemes din`amics, en els quals els elements de control no s´on centrals sin´o que estan distribu¨ıts en el sistema a m´es cada component del subsistema est`a connectat als dem´es mitjan¸cant una xarxa. DCSMonitor Nom del programa creat en aquest projecte per rebre totes les dades monitoritzades presents en el bus CAN. Ve de les sigles en Angl`es de Distributed Control Systems Monitor (Monitor de Sistemes Distribu¨ıts de Control) xvii GLOSSARI DMA Sigles en Angl`es de Direct Memory Acces (Acc´es Directe a Mem`oria); ´es un m`etode que permet a certs tipus de circuits integrats accedir a la mem`oria d’aquests per llegir i escriure independentment de la CPU principal. DSP Sigles en Angl`es de Digital Signal Processor (Processador de Senyals Digitals); s´on microprocesadors especialitzats amb una arquitectura optimitzada per el tractament r`apid de senyals digitals. dsPIC Fam´ılia de microcontroladors fabricats per la casa Microchip caracteritzat per comptar amb bus de dades inherent de 16 bits, i per incorporar varies operacions de DSP implementades en hardware. dsPIC33FJ256MC710 Model de microcontrolador de la casa Microchip caracteritzat per ser de la fam´ılia dels dsPIC i per comptar amb multitud d’utilitats en sistemes distribu¨ıts. IDE Sigles en Angl`es de Integrated Development Environment (Entorn de Desenvolupament Integrat); ´es un programa inform`atic composat per un conjunt d’eines de programaci´o en un o varis llenguatges de programaci´o i dedicat a ajudar en les tasques habituals de programaci´o. IPS Sigles en Angl`es de Instructions Per Second (Instruccions Per Segon); ´es una mesura de velocitat d’un processador. Indica el nombre d’instruccions que la CPU pot executar en un segon. Lla¸c de Control En els sistemes distribu¨ıts de control s’anomena d’aquesta manera a un grup de dispositius que formen part del control d’algun proces, en el cas del nostre laboratori aquests grups estan formats per un Controlador , un Sensor i un Actuador . Microcontrolador Es un circuit integrat programable, capa¸c d’executar les ordres gravades en la seva mem`oria. Est`a composat per varis blocs funcionals, els quals compleixen una tasca concreta. Un microcontrolador cont´e al seu interior les tres unitats funcionals principals de un computador: unitat central de processament, mem`oria i perif`erics d’entrada i sortida. Microprocesador Els microprocesadors compten amb les funcions d’una CPU (Unitat Central de Procesament) en un o varis circuits integrats. Monitor El monitor es un dispositiu que hem afegit en el nostre laboratori i en el sistema distribu¨ıt de control que s’encarrega de monitoritzar el bus del sistema capturant la informaci´o demanada, i poden interferir en el sistema per veure la resposta dels diferents controls. Mutex De l’Angl`es Mutual Exclusi´on (Zona d’exclusi´o mutua); tipus d’algoritmes utilitzats en la programaci´o concurrent per evitar l’us simultani dels recursos, com variables globals, per fragments de codi coneguts de manera com´u com zones cr´ıtiques. OSEK/VDX Sigles en Alem`a de Offene Systeme und deren Schnittstellen f¨ur die Elektronik in Kraftfahrzeugen (Sistemes oberts i les seves interf´ıcies per la electr`onica en autom`obils); ´es un estandart que especifica el Sistema Operatiu integrat incloent una pila per comunicacions i un protocol per l’administraci´o de xarxes per sistemes empotrats en autom`obils. PIC Sigles en Angl`es de Peripheral Interface Controller (Controlador d’Interficie de Perif´eric); s´on una familia de microcontroladors de tipus RISC fabricats per Microchip Technology Inc. originalment creats per la divisi´o de microelectr´onica de General Instruments. xviii GLOSSARI PWM Sigles en Angl`es de Pulse-Width Modulation (Modulaci´o per ampl`aria d’impuls); aquesta ´es una t`ecnica en la qual es modifica el cicle de treball d’un senyal peri`odic (una ona sinuso¨ıdal o ona quadrada, per exemple), ja sigui per transmetre informaci´o a trav´es d’un canal de comunicacions o per controlar la quantitat d’energia que s’envia a una c`arrega. RTOS Sigles en Angl`es de Real-Time Operating System (Sistema Operatiu en Temps Real); es diu dels Sistemes Operatius dissenyats per atendre aplicacions en temps real. La principal caracter´ıstica d’aquests SO ´es el nivell de precisi´o en els temps d’execuci´o de cada una de les tasques que ha de realitzar. SAE Sigles en Angl`es de Society of Automotive Engineers (Societat d’Enginyers Automotrius); ´es l’organitzaci´o enfocada a la mobilitat dels professionals en l’enginyeria aeroespacial, automoci´o, i industries comercials especialitzades en la construcci´o de vehicles. Sensor El sensor en un sistema distribu¨ıt de control ´es l’encarregat de prendre els valors de sortida del sistema, per tal de oferir-li al controlador. Supervisor El supervisor en un sistema distribu¨ıt de control ´es el dispositiu que ens dona els valors necessaris del sistema per saber el seu estat. WBS Sigles en Angl`es de Work Breakdown Structure (Estructura de Descomposici´o de Treball); en gesti´o de projectes es una descomposici´o jer`arquica orientada al entregable, del treball a ser realitzat per l’equip del projecte per cumplir amb els objectius d’aquest. XML De l’Angl`es eXtensible Markup Language (Llenguatge de Marques Extensibles); ´es un metallenguatge d’etiquetes, desenvolupat per el World Wide Web Consortium (W3C) que permet definir la gram`atica de llenguatges espec´ıfics. xix GLOSSARI xx 1 Introducci´o Aquesta mem`oria pret´en reflectir de manera clara i entenedora el proc´es que s’ha seguit per dur a terme un laboratori de ”Sistemes Distribu¨ıts de Control”(a partir d’ara SDC), aix´ı com els problemes que hagin pogut sorgir en el transcurs del projecte. La realitzaci´o d’aquest laboratori ha comportat l’adquisici´o d’una visi´o profunda del que es pret´en ensenyar des del departament de ESAII de la UPC en el tema dels SDC . Per tant en el transcurs d’aquesta mem`oria s’anir`a endinsant en aquest tipus de sistemes, es coneixeran quines s´on algunes de les tecnologies base que els conformen, els problemes que en elles esdevenen, i solucions a algunes d’aquestes q¨uestions. Amb tot aix`o es podr`a tenir una idea m´es clara del motiu de la realitzaci´o d’aquest projecte i les portes que a partir d’aquest projecte queden obertes. A m´es es poden veure com a ap`endix les dues guies realitzades en aquest projecte, una per la preparaci´o de l’entorn de desenvolupament i posterior utilitzaci´o del laboratori. I una altre per l’´us del LiveCD pel desenvolupament pr`actic del laboratori. 1.1 Estructuraci´o de la mem`oria En aquesta secci´o mirarem de donar una visi´o global de la mem`oria, perqu`e sigui f`acil de ser consultada, i d’aquesta manera tenir en tot moment una idea de on es pot trobar qualsevol q¨uesti´o. Per tant comen¸car indicant que aquesta mem`oria ha estat escrita seguint l’ordre cronol`ogic que esdev´e al desenvolupar i portar a terme un projecte. 1 1. INTRODUCCI´ O hores (taula 1.2). I tenint en compte la taula de hores di`aries vista anteriorment, ens surten els dies i hores que aqu´ı apareixen. Aix´ı doncs es va ajustar la feina al calendari i efectivament tot encaixava, per`o a finals d’Agost per problemes personals el projecte es va haver d’aturar completament, i aix`o es va allargar un mes i mig. Aix`o va causar una replanificaci´o del diagrama de gantt i l’entrega del projecte es va veure afectada en una demora equivalent a aquest temps (es pot observar en el diagrama de gantt (Principi del gantt 1.1 i 1.2) el per´ıode de demora esmentat). WBS Nom Temps 1 Estudi General 3d 4h 1.1 Buscar informaci´o RTOS 1d 4h 1.2 Mirar Erika RTOS 1d 1.3 Mirar Comunicaci´o CAN bus 1d 2 Planificar Projecte 4h 2.1 Planificaci´o general del projecte 4h 3 Laboratori Actual 28d 4h 3.1 Mirar material necessari 7h 3.2 Preparar i adaptar entorn de treball 2d 4h 3.3 Practica Encendre Led 1d 3.4 Practica Doble Integrador 2d 5h 3.5 Practica Controlador - Actuador 2d 2h 3.6 Recopilar informaci´o per la FAQ 9d 4h 3.7 Recopilar informaci´o sobre els passos seguits 9d 4h 4 Preparar Codis Lliures 6d 2h 4.1 Estudiar la comunicaci´o per RS232 amb PIC 1d 4.2 Mirar comunicaci´o per RS232 amb python 2d 2h 4.3 Mirar llibreries per fer gr`afiques amb python 2d 7h 5 Realitzar Ampliaci´o del Laboratori 26d 6h 5.1 Dissenyar primera aproximaci´o ampliaci´o 1d 5.2 Implementaci´o primera aproximaci´o 4d 5.2.1 Implementar part Sampling, Actuation 1d 4h 5.2.2 Implementar part Control, Monitor 1d 5.2.3 Implementar part Receptor (PC) 1d 4h 5.3 Replanificar i reorganitzar 1d 1h 5.4 Redissenyar ampliaci´o 5d 6h 5.4.1 Pensar resultat esperat 1d 5h 5.4.2 Dissenyar parts implicades 2d 5.4.3 Especificar protocols de comunicaci´o 2d 5.5 Implementaci´o 12d 5h 8 1.4 Planificaci´o 5.5.1 Implementar part Sampling, Actuation 7h 5.5.2 Implementar part Control 1d 5.5.3 Implementar part Monitor 3d 6h 5.5.4 Implementar part Receptor 3d 5h 5.5.4.1 Disseny de la part visual 1d 1h 5.5.4.2 Integraci´o amb comunicaci´o 1d 5.5.4.3 Mostreig de resultats en temps real 1d 4h 5.5.5 Realitzar tests 2d 5.5.6 Depuraci´o de codi 1d 2h 5.6 Documentar nou laboratori 1d 1h 5.7 Traduir al Angl`es nou laboratori 1d 6 Preparar Live CD 7d 6.1 Estudi de la creaci´o 2d 6.2 Creaci´o d’entorn 1d 4h 6.3 Implementar Live CD 7h 6.4 Revisar bon funcionament 1d 4h 6.5 Documentar ´us del CD 1d 7 Realitzar Guia Laboratori 4d 6h 7.1 Realitzar guia Catal`a 3d 6h 7.1.1 Instal·laci´o entorn 7h 7.1.1.1 Linux (ubuntu) 7h 7.1.2 Configuraci´o entorn 6h 7.1.2.1 Linux (ubuntu) 6h 7.1.3 Realitzar la guia de seguiment del laboratori 2d 7.2 Traduir guia al Angl`es 1d 8 Preparar Informe previ del projecte 3d 4h 9 Entrega Informe previ del projecte 10 Preparar Mem`oria 28d 11 Preparar Defensa 3d 4h 12 Reunions peri`odiques 78d 3h 13 Defensa del projecte Taula 1.2: Hores de dedicaci´o 9 1. INTRODUCCI´ O Estudi General 7d Buscar informació RTOS 3d Mirar Erika RTOS 2d Mirar Comunicació CAN bus 2d Planificar Projecte 1d Planificació general del projecte 1d Laboratori Actual 57d Mirar material necessari 1d 3h Preparar i adaptar entorn de treball 5d Practica Encendre Led 2d Practica Doble Integrador 5d 1h Practica Controlador - Actuador 4d 2h Recopilar informacio per la FAQ 19d Recopilar informació sobre els passos seguits 19d Preparar Codis Lliures 12d 2h Estudiar la comunicació per RS232 amb PIC 2d Mirar comunicació per RS232 amb python 4d 2h Mirar llibreries per fer gráfiques amb python 5d 3h Realitzar Ampliació del Laboratori 53d 2h Disenyar primera aproximació ampliació 2d Implementació primera aproximació 8d Implementar part Sampling, Actuation 3d Implementar part Control, Monitor 2d Implementar part Receptor (PC) 3d Replanificar i reorganitzar 2d 1h Re-disenyar ampliació 11d 2h Pensar resultat esperat 3d 1h Diseñar parts implicades 4d Especificar protocols de comunicació 4d Implementació 25d 1h Implementar part Sampling, Actuation 1d 3h Impementar part Control 2d Implementar part Monitor 7d 2h Implementar part Receptor 7d 1h Diseny de la part visual 2d 1h Integració amb comunicació 2d Mostreig de resultats en temps real 3d Realitzar tests 4d Depuració de codi 2d 2h Documentar nou laboratori 2d 1h Traduir al Anglés nou laboratori 2d Preparar Live CD 14d Estudi de la creació 4d Creació d'entorn 3d Implementar Live CD 1d 3h Revisar bon funcionament 3d Documentar us del CD 2d 2011, Ctr 3 jul ago … Nombre Trab… Figura 1.1: Principi del Gantt, esquerre : Juny, Juliol, Agost 10 1.4 Planificaci´o 2011, Ctr 4 2012, Ctr 1 oct nov dic ene Figura 1.2: Principi del Gantt, dreta : Septembre, Octubre, Novembre, Desembre, Gener 11 1. INTRODUCCI´ O Realitzar Guia Laboratori 9d 2h Realitzar guia Català 7d 2h Instalació entorn 1d 3h Linux (ubuntu) 1d 3h Configuració entorn 1d 2h Linux (ubuntu) 1d 2h Realitzar la guia de seguiment del laboratori 4d Traduir guia al Anglés 2d Preparar Informe previ del projecte 7d Entrega Informe previ del projecte Preparar Memòria 56d Preparar Defensa 7d Reunions periódiques 156d … Defensa del projecte Figura 1.3: Final del Gantt, esquerre : Juny, Juliol, Agost 12 1.4 Planificaci´o Figura 1.4: Final del Gantt, dreta : Septembre, Octubre, Novembre, Desembre, Gener 13 1. INTRODUCCI´ O 14 2 Tecnologia Una part molt important del projecte, ha estat familiaritzar-se amb una serie de tecnologies, materials i protocols que en certs casos eren totalment desconeguts. Aquestes tecnologies han comportat hores de dedicaci´o i adaptaci´o i per aquesta mateixa ra´o s’ha creat aquesta secci´o. Aix`o permetr`a que un lector que no conegui alguna d’aquestes tecnologies pugui de manera rapida fer-se una idea del seu significat o prop`osit. En el cap´ıtol Tecnologia per tant s’intentar`a donar una visi´o del tot el material que s’ha usat en el laboratori, per a que serveix cada un dels diferents dispositius i quines caracter´ıstiques tenen (tot aix`o en la secci´o de Hardware 2.1). Tot seguit s’explicar`a quins s´on els programes que es poden utilitzar per compilar els diferents codis, els programes que ens ajuden a programar els dispositius que formen els lla¸cos de control, els programes que ens han perm`es crear les interf´ıcies, o traduir-les c`omodament en el programa DCSMonitor (tot aix`o en la secci´o Software 2.2). I perqu`e es pugui entendre una mica millor tot el projecte, es dona una visi´o general sobre els diferents protocols que durant la mem`oria es veuran, i que han estat necessaris per poder realitzar els controls del laboratori (secci´o de protocols de comunicaci´o 2.3). Per tant aquesta secci´o es fa una eina b`asica necess`aria per tothom que vulgui comprendre una mica tot aix`o, o per alg´u que vulgui repassar-ho. 2.1 Hardware Com hem dit en la introducci´o d’aquest cap´ıtol, en aquesta secci´o es donar`a una visi´o del material que s’ha utilitzat en l’elaboraci´o del laboratori de Sistemes Distribu¨ıts de 15 2. TECNOLOGIA Control. Entre aquest material n’hi ha que esta ja preparat per el seu us directe com la placa FLEX (secci´o 2.1.1) i el programador ICD2 (secci´o 2.1.4). O en canvi necessita ser ensamblat en un protoboard o crear una placa per poder utilitzar-los. En el nostre cas el microcontrolador dsPIC (secci´o 2.1.2) ja forma part de la placa FLEX , i per utilitzar el transceptor (secci´o 2.1.3), si que s’ha hagut de crear una petita plaqueta que s’explicar`a en un altre cap´ıtol (secci´o 3.1). 2.1.1 FLEX Figura 2.1: Logotip de la companyia Evidence - FLEX ´es el nom amb el que han designat a una placa de prototipatge creada per la casa Evidence (logotip 2.1) per treure el m`axim partit d’un microcontrolador amb tecnologia dsPIC. Aquesta placa va n´eixer amb l’objectiu de desenvolupar aplicacions en temps real, i per aquest motiu compte amb moltes qualitats interessants per el nostre laboratori. Entre les seves caracter´ıstiques es troben: •Un disseny de la electr`onica robust. •Una arquitectura modular. •Disponibilitat d’un gran nombre creixent de guies d’aplicacions. •Tot el suport del kernel Erika Enterprise, de Evidence. El cor d’aquesta placa es composa d’un dsPIC33FJ256MC710 (veure secci´o 2.1.2), el qual ens dona moltes possibilitats a l’hora de crear diferents dispositius. 16 2.1 Hardware Figura 2.2: FLEX: placa de avaluaci´o de dsPIC de Microchip - 17 2. TECNOLOGIA •Comunicaci´o condu¨ıda per events. •Broadcast. •Iniciativa de transmissi´o a c`arrec de la font d’informaci´o. •El nom del missatge gen`ericament dessigna la informaci´o, no el node. •Resposta a petici´o remota. •Detecci´o i correcci´o d’error a nivell de missatge. •Capacitat de detecci´o d’errors a nivell del medi de comunicaci´o. •Toler`ancia a fallades. •Confirmaci´o. •Transfer`encia de missatges consistent sobre tot el sistema. •Codificaci´o de bit. •Sincronitzaci´o de bit. •Sincronitzaci´o entre nodes. •Distribuci´o del sistema. •Velocitat de transmissi´o. •Caracter´ıstiques del driver de l´ınia. •M´ultiples prove¨ıdors de xips. 2.3.2 Serie via RS232 En computaci´o la comunicaci´o serie ´es tota aquella transfer`encia de dades en la que la informaci´o va bit a bit una darrera una altra. Aquest tipus de comunicaci´o ´es usada en multiples protocols de comunicaci´o, com poden ser el USB, Ethernet, FireWire o per exemple CAN (vist anteriorment 2.3.1). Per`o usualment, quan parlem del port serie de l’ordinador, ens referim a la norma RS232 (de l’angl`es Recommended Standard 232) (veure (7)). 24 2.3 Protocols de comunicaci´o Aquesta norma determina les seves caracter´ıstiques f´ısiques, la temporitzaci´o dels senyals, les velocitats de transmissi´o, i la mida del connector i dels seu pinatge. Figura 2.14: Connector per port serie RS232 - En forma de DE-9 Normalment tots els ordinadors de sobretaula solen tenir algun connector destinat a aquest tipus de comunicaci´o, en el format d’un connector DB-9 (originalment DE-9, veure figura 2.14), en canvi els ordinadors port`atils ja no solen tenir aquest tipus de connector, per aquesta ra´o es necessita utilitzar un convertidor de RS232 a USB. Aquesta comunicaci´o va ser dissenyada per connectar equips terminals de dades amb equips de comunicaci´o de dades, per`o en ocasions (com en el cas del connexionat entre dos ordinadors) es connecten dues terminals de dades. En aquest cas es sol utilitzar un tipus de connexionat anomena null m´odem (per la no exist`encia de m´odem). El connector DB-9; com el seu nom indica; t´e 9 pins, i cada un d’ells te definit el seu funcionament, com pot ser el d’enviar dades, o el de rebre dades. S’adjunta una taula amb l’especificaci´o de cada un d’aquests pins (taula tab:tec:prot:rs232). N´umero de pin Nom 1 CD: Detector de transmissi´o 2 RXD: Recepci´o de dades 3 TXD: Transmissi´o de dades 4 DTR: Terminal de dades preparat 5 GND: Senyal de terra 6 DSR: Ajust de dades preparat 7 RTS: Perm´ıs per transmetre 8 CTS: Preparat per transmetre 9 RI: Indicador de trucada Taula 2.1: Pinatge del connector serie per RS232 25 2. TECNOLOGIA 2.3.3 Topologia en bus Aquest ´es un tipus de connexionat entre m´ultiples dispositius en els quals tots ells estan connectats a un mateix bus central (veure figura 2.15). Aix`o comporta alguns avantatges per`o tamb´e molts inconvenients que es procuren resoldre de diferents maneres. Per crear aquest tipus de xarxa ´es necessari finalitzar els cables amb resist`encies de carrega final. Aquestes resist`encies s´on calculades depenent de les senyals que hi circulen, i els metres de cable que formen el bus, i aconsegueixen mitigar l’efecte rebot que apareix en un cable tallat (amb la resist`encia ben calculada a ulls dels dispositius el bus resultaria ser de mida infinita). •Avantatges –Facilitat en la implementaci´o. –Creixement del nombre de dispositius f`acil. –Simplicitat en el tipus d’arquitectura. –Recepci´o de tota la informaci´o del bus. –No hi ha necessitat de redireccionar missatges. •Inconvenients –Existeix un l´ımit del nombre de dispositius, depenent de la qualitat del senyal. –Pot produir-se degradaci´o del senyal. –Complexitat de reconfiguraci´o i a¨ıllament de fallades. –Un problema en un canal sol degradar tot el bus. –El bon funcionament sol degradar a mesura que el bus creix. –El bus ha de ser degudament tancat. –Alta p`erdua de transmissions degut a les col·lisions entre missatges. 26 2.4 Conclusions Figura 2.15: Topologia en bus - 2.4 Conclusions En aquest punt ja ens hem fet una idea de totes les tecnologies que hi ha al voltant d’aquest projecte. Hem vist que les xarxes en bus tenen alguns inconvenients que cal resoldre, quines facilitats ens proporciona utilitzar un bus CAN, com podem rebre els valors d’estat del control mitjan¸cant la comunicaci´o serie via RS232, i quins dispositius s’utilitzen per poder connectar-se a un bus CAN, anomenats transceptor CAN. Tamb´e hem pogut con`eixer varis programes que ens ajuden en la tasca de programar tots aquests dispositius, com crear interf´ıcies per programes que corrin en varis sistemes operatius, i com generar aquests programes multiling¨ues. Per tant ja podem abordar la configuraci´o que t´e el laboratori actual, i podem comen¸car a dissenyar tot el necessari per muntar un laboratori en el que tots els dispositius comparteixin un mateix bus CAN. Tot aix`o ho podrem veure i seguir en el seg¨uent cap´ıtol. 27 2. TECNOLOGIA 28 3 Disseny del laboratori Aquest cap´ıtol comen¸ca amb l’explicaci´o de l’entorn i dels objectius que t´e el laboratori actual de Sistemes de Control Empotrats i en Xarxa. Exposarem per tant el seu proposit i les limitacions que aquest ten´ıa, i de quina manera hem dissenyat la nova plataforma per poder solventar algunes d’aquestes mancanses. Per tant entrarem en la part del disseny del nou laboratori, i veurem les raons que ens han portat a escollir els diferents camins que teniem, aix´ı com el disseny de les comunicacions que hi ha entre els diferents dispositius i el nou programa DCSMonitor . 3.1 Resum del laboratori actual L’objectiu d’aquest laboratori ´es l’analisis, el diseny i la implementaci´o d’un sistema de control empotrat i en xarxa (a partir d’ara NECS , sigles de l’angl`es Networked and Embedded Control Systems) (8, laboratori complert en el document Networked and Embedded Control Systems (NECS) Double Integrator Control Lab). En aquest laboratori es cobreixen varies fases: •Disseny de controls. •An`alisis de sistemes NECS multitasques. •Diseny de sistemes NECS multitasques. •Implementaci´o del sistema NECS . 29 3. DISSENY DEL LABORATORI La plataforma d’implementaci´o ens permetr`a controlar un circuit Doble Integrador (a partir d’ara DI de l’angl´es Double Integrator) d’un microcontrolador. Com es mostra en les figures 3.1 i 3.2. Figura 3.1: Microprecessor-based control - Figura 3.2: Network-based control - En la primera configuraci´o, figura 3.1, moltes tasques s´on executades concurrentment al cap davant del Sistema Operatiu en Temps Real Erika. Per aquesta ra´o les tasques de control del circuit doble integrador han de competir amb la resta per el temps de CPU. En la segona configuraci´o, figura 3.2, permet tancar el lla¸c de control en una xarxa, en aquest cas un bus CAN. En aquest escenari, les limitacions dels recursos ve donada per l’ampla de banda de la comunicaci´o. D’aquesta manera connectant varis lla¸cos en una mateixa xarxa ens pot permetre analitzar un sistema distribu¨ıt de control m´es realista. En les dues configuracions, les plaques estan equipades amb microcontroladors dsPIC33FJ256MC710 de Microchip . Les plaques s´on plaques FLEX de Evidence. S’han creat tres plaques amb un circuit doble integrador (figura 3.3a), comunicaci´o CAN (figura 3.3b)i un port RS232 (figura 3.3c) que s’han afegit a aquestes per tal de comunicar-se entre elles, i amb l’ordinador. La placa FLEX que porta el circuit doble integrador es l’encarregada de simular un Sensor i un Actuador , en els quals el Sensor es un conversor analogic digital (ADC) 30 3.1 Resum del laboratori actual (a) Doble Integrador (b) Transceptor CAN (c) Modul RS232 Figura 3.3: Periferics per les plaques FLEX . que llegeix els voltatges de sortida de la primera i segona integral, i l’Actuador aplica diferents nivells de voltatge a l’entrada del circuit a trav´es d’un modulador per amplada de polsos (PWM). L’objectiu del control es que la sortida del doble integrador segueixi un valor de referencia que va variant. Aquest s’aconsegueix aplicant un algoritme de control i aplicant el valor calculat a l’entrada del circuit. Un cop l’entorn est`a preparat la configuraci´o queda com a la figura 3.4. En la qual la placa superior actua com a Controlador que remotament fa el control a traves del bus CAN. En la part inferior tenim el Sensor/Actuador que compta amb la placa del doble integrador connectada, i per tal de debugar el control tamb´e compta amb la interf´ıcie RS232 (en aquesta imatge queda sota de la placa superior) la qual envia peri`odicament els valors de l’estat. 31 3. DISSENY DEL LABORATORI Figura 3.4: Lla¸c de control - 3.2 Disseny del Nou laboratori Fins aquest moment els problemes a resoldre han estat pels temps de demora que hi havia entre lectures del Sensor , accions de l’Actuador i els c`alculs que havia de fer el Controlador . En aquest apartat ens interessa que tots els dispositius estiguin en un mateix bus CAN i comprovar el funcionament dels lla¸cos en un entorn compartit, amb diferents tipus de prioritats i amb la possibilitat de saturar el bus en certes ocasions (figura 3.5). A part d’aquesta connexi´o general al bus, tamb´e s’introduir`a en la xarxa un dispositiu que anomenarem Monitor , el qual tindr`a la opci´o de monitoritzar tots els paquets de dades d’un cert lla¸c de control (un grup format per un Sensor , un Actuador i un Controlador ). Tota la informaci´o que el nou dispositiu Monitor capturi, podr`a ser enviada mitjan¸cant el port s`erie RS232 a un programa d’ordinador (DCSMonitor ) el qual mostrar`a mitjan¸cant unes gr`afiques en temps real l’estat del control de cada grup del laboratori. A m´es el Monitor tindr`a la capacitat d’incrementar la carrega del bus en quant a nombre de missatges CAN que hi circulin, dificultant el correcte funcionament dels lla¸cos, i podent comprovar en temps real la resposta d’aquests. 32 3.2 Disseny del Nou laboratori Amb aquesta idea general i tenint en compte les relacions que hi haur`a entre tots els elements que formen el laboratori es va dissenyar un esquema general en el que apareixen aquests elements i el tipus de comunicaci´o que hi ha entre ells (figura 3.6). Figura 3.5: Entorn del nou laboratori - A l’esquerra un lla¸c de control format per un Controlador (primer pis) i un Sensor/Actuador (segon pis). A la dreta un lla¸c de control format per un Controlador (segon pis) i un Sensor/Actuador (tercer pis) i un dispositiu Monitor (primer pis). 33 3. DISSENY DEL LABORATORI 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 000 Control signal ID (a) Control message 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 001 Error value ID (b) Granted sensor messages 3 bits 26 bits 0 2 3 28 010 Rest of applications (c) General purpose message 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 011 Error value ID (d) Best effort sensor message Figura 3.8: Codificaci´o de bits dels identificadors CAN per tipus de missatges - usats en l’article ”Schedulability Analysis for CAN-based Networked Control Systems with Dynamic Bandwith Management”(10) (text original). 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 Tipus Prioritat ID lla¸c XY Figura 3.9: Esquema gen`eric dels identificadors CAN pel nou laboratori. 40 3.2 Disseny del Nou laboratori Monitor/Supervisor Sensor/Actuador/Supervisor Controlador Valor calculat. Activat. Valor sortida Dob. Int. per Controlador Periodic : 50 ms Controlador Sen/Act/Sup Controlador Sen/Act/Sup Bus CAN ID llaç : 0b 0000 0001 Identificadors comunicació CAN (extended frame de 29 bits) Classe : 3 bits : ccc Prioritat : 16 bits : pppp pppp pppp pppp ID llaç : 8 bits : iiii iiii Subclasse : 2 bits : ss Classes Missatge de control : 000 Missatge de sensor garantit : 001 Missatge de proposit general : 010 Subclasse Missatge de canvi de referencia : 00 Estat del sensor per supervisor : 01 Esquema general de l'identificador \ Classe /\ Prioritat /\ ID llaç /\ Subclasse/ 0b ccc pppp pppp pppp pppp iiii iiii ss Exemples d'identificadors missatges controlador -> actuador : 0b 0000 00pp pppp pppp pppp ppii iiii iiss sensor -> supervisor : 0b 0000 10pp pppp pppp pppp ppii iiii ii01 ID llaç : 0b 1111 1111ID llaç : 0b 0000 0000 Mascares identificadors CAN Tipus de mascara Mascara 1: Guarda tots els missatges sense importar el filtre 0b 0000 0000 0000 0000 0000 0000 0000 0000 Mascara 2: Nomes del llaç i classe que indicqui el filtre 0b 0001 1100 0000 0000 0000 0011 1111 1100 Mascara 3: Nomes del llaç, classe i subclasse que indiqui el filtre 0b 0001 1100 0000 0000 0000 0011 1111 1111 Exemple de filtre i mascara per rebre missatges del llaç 34 de la classe de missatge de proposit general amb la subclasse de canvi de referencia: Mascara 3 : 0b 0001 1100 0000 0000 0000 0011 1111 1111 Filtre : 0b xxx0 10xx xxxx xxxx xxxx xx00 1000 1000 Canvi Referencia per Supervisor Periodic : 1 s Valor sortida Dob. Int. per Supervisor Periodic : 10 ms Figura 3.10: Diagrama de comunicacions i identificadors CAN - Diagrama de funcionament del laboratori, disseny dels identificadors i m`ascares per bus CAN, i tipus de missatges de comunicaci´o. 41 3. DISSENY DEL LABORATORI Tot seguit es veuran un a un tots els missatges que s’han adaptat i creat explicats a fons. 3.2.2.1 Missatge de control per l’Actuador Aquest tipus de missatge s’envia cada cop que el Sensor envia una lectura nova al Controlador (missatge de l’estat del Sensor per al Controlador explicat en l’apartat 3.2.2.2), aquest al rebre els valors de les senyals fa els c`alculs oportuns i ha de respondre lo m´es r`apid possible l’Actuador , que ´es l’encarregat de donar el valor al doble integrador. Aquests tipus de missatges han de ser d’alta prioritat i per tant, tenen assignats els primers 3 bits de l’identificador a zero, ja que en els missatges CAN els identificadors amb els primers zeros s´on els m´es prioritaris. Aix´ı que utilitzant la codificaci´o mencionada anteriorment farem servir el tipus de missatge control message, quedant l’estructura de l’identificador i el senyal de control com la figura 3.11. 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 000 Prioritat ID lla¸c (a) Identificador CAN (29 bits). 4 bytes 0123 Senyal de Control (b) Informaci´o. Figura 3.11: Missatge CAN del Controlador al Actuador . 3.2.2.2 Missatge de l’estat del Sensor per al Controlador Aquest ´es un missatge que s’envia peri`odicament cada 50ms, i ´es el responsable d’enviar l’estat en el que es troben les dues integrals. T´e com a destinaci´o el Controlador que posteriorment ´es el que far`a els c`alculs dependents d’aquests valors. En aquests tipus de sistemes aquests missatges, al igual que els del controlador, tamb´e s´on molt importants, per aquest motiu se’ls assigna el tipus 001, ja que ´es el segon tipus m´es prioritari. A part dels primers tres bits, els seg¨uents 16 bits es poden 42 3.2 Disseny del Nou laboratori utilitzar per codificar l’error que s’est`a produint, de manera que sigui m´es prioritari el que tingui el valor m´es desviat del desitjat. Aix´ı que utilitzant la codificaci´o mencionada anteriorment farem servir el tipus de missatge granted sensor message, quedant l’estructura de l’identificador i el senyal de control com la figura 3.12. 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 0 0 1 Prioritat ID lla¸c (a) Identificador CAN (29 bits). 4 bytes 4 bytes 0 3 4 7 Primera integral Segona integral (b) Informaci´o (8 bytes). Figura 3.12: Missatge CAN de l’estat del Sensor per al Controlador . 3.2.2.3 Missatge de canvi de refer`encia Aquest ´es un missatge que s’envia peri`odicament cada segon, i ´es el responsable d’enviar el valor de refer`encia que s’intenta aconseguir en cada moment. Aquest valor oscil·la de 0,5 a -0,5 i t´e com a destinaci´o el Supervisor que ha d’enviar aquest valor a l’ordinador per que pugui dibuixar la gr`afica correctament. Fins aquest laboratori el Supervisor era el dispositiu Sensor/Actuador ja que era l’encarregat de la comunicaci´o per RS232, per`o en el nou laboratori el microcontrolador que fa de Monitor tamb´e captura aquest tipus de missatge si des del programa de DCSMonitor se li ha indicat. Tot i aix´ı el dispositiu Sensor/Actuador en el nou laboratori segueix rebent aquesta informaci´o i ja pot seguir enviant informaci´o per RS232 a un altre ordinador. Com aquest tipus de missatges no t´e cap tipus d’import`ancia a l’hora de portar a terme el control, utilitzen l’identificador de tipus general purpose messages. Aix´ı no empitjoren la qualitat del control per`o no deixen de ser missatges que procuren garantir la seva recepci´o. A part d’aquest missatge que pret´en enviar el valor de refer`encia, hi ha altres missatges que voldran utilitzar el tipus d’identificador que hem mencionat, 43 3. DISSENY DEL LABORATORI per aquesta ra´o utilitzarem els ´ultims dos bits posats a zero per indicar que ´es d’aquest tipus. Aix´ı que utilitzant la codificaci´o mencionada anteriorment farem servir el tipus de missatge general purpose messages, quedant l’estructura de l’identificador i el senyal de control com la figura 3.13. 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 010 Prioritat ID lla¸c 0 0 (a) Identificador CAN (29 bits). 4 bytes 0 3 Refer`encia (b) Informaci´o (4 bytes). Figura 3.13: Missatge CAN per actualitzar el valor de refer`encia. 3.2.2.4 Missatge de l’estat del Sensor per al Supervisor Aquest ´es un missatge que s’envia peri`odicament cada 10ms, env´ıa exactament la mateixa informaci´o que se li envia al Controlador en el missatge Missatge de l’estat del Sensor per al Controlador (anteriorment explicat en l’apartat 3.2.2.2), per`o el seu prop`osit no ´es el de calcular el valor de control, sin´o purament informatiu. Com s’ha dit anteriorment en l’anterior laboratori el Supervisor era el mateix Sensor/Actuador (i encara ho pot seguir sent) i per tant al enviar la informaci´o de l’estat del Sensor primer feia la lectura i despr´es enviava els valors. En canvi en el nou laboratori el Supervisor ´es el Monitor que es troba en un altre dispositiu, aix´ı que peri`odicament hem d’enviar aquesta informaci´o, ja que d’aquesta manera es veuran les gr`afiques amb els valors reals. Com aquest tipus de missatges no t´e cap tipus d’import`ancia a l’hora de portar a terme el control, utilitzen l’identificador de tipus general purpose messages. Aix´ı no empitjoren la qualitat del control, per`o no deixen de ser missatges que procuren garantir la seva recepci´o. A part d’aquest missatge hem vist un altre missatge (Missatge de canvi de refer`encia en l’apartat 3.2.2.3) que utilitza el tipus d’identificador 44 3.2 Disseny del Nou laboratori que hem mencionat, per aquesta ra´o utilitzarem els ´ultims dos bits posats a zero i u respectivament per indicar que ´es d’aquest tipus. Aix´ı que utilitzant la codificaci´o mencionada anteriorment farem servir el tipus de missatge general purpose messages, quedant l’estructura de l’identificador i el senyal de control com la figura 3.14. 3 bits 16 bits 8 bits 2 bits 0 2 3 18 19 26 27 28 0 1 0 Prioritat ID lla¸c 0 1 (a) Identificador CAN (29 bits). 4 bytes 4 bytes 0 3 4 7 Primera integral Segona integral (b) Informaci´o (8 bytes). Figura 3.14: Missatge CAN de l’estat del Sensor per al Supervisor . 3.2.3 Comunicaci´o s`erie La part de comunicaci´o entre l’ordinador i les plaques Flex s’ha vist modificada, ja que primerament la informaci´o que s’enviava peri`odicament a l’ordinador la realitzava el Sensor/Actuador , i aquest comptava amb la informaci´o dels valors de sortida de l’integrador de primera ma. Aquesta comunicaci´o era unidireccional, aix´ı que el Supervisor enviava peri`odicament el seu temps actual, el valor de refer`encia, el valor d’entrada de l’integrador, i els dos valors de sortida d’aquest ´ultim. 1 byte 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 2 bytes 0 1 4 5 8 9 12 13 16 17 20 21 22 01 temps refer`encia primera int. segona int. entrada Figura 3.15: Trama de supervisi´o antiga per RS232 (23 bytes) Aix´ı que en el nou sistema, per tal de complir els requisits de monitoritzar diversos lla¸cos, i amb la intenci´o de no saturar el microcontrolador amb les dades de tots els 45 3. DISSENY DEL LABORATORI 1 byte 4 bytes 4 bytes 4 bytes 4 bytes 4 bytes 2 bytes 0 1 4 5 8 9 12 13 16 17 20 21 22 01 temps refer`encia primera int. segona int. entrada XXYY id1id2id3.................... ....................... .id48 Figura 3.16: Trama de supervisi´o nova per RS232 (71 bytes). Els primers bytes s’utilitzen exactament igual que en la versi´o antiga per mantenir la compatibilitat. dispositius ens veiem for¸cats a comunicar des de l’ordinador al Monitor de quin lla¸c volem la informaci´o en cada moment. A m´es es vol implementar la capacitat d’enviar diferents instruccions al Monitor, com poden ser saturar el bus fins a cert punt, demanar quants lla¸cos de control existeixen al bus, i possibles ampliacions. Per tant el sistema de comunicaci´o ha de satisfer les seg¨uents necessitats: •Realitzar una implementaci´o bidireccional. •Afegir diferents senyals de control. –Demanar un llistat dels lla¸cos de control que hi ha al bus CAN. –Demanar els valors de Sensor/Actuador iControlador d’un lla¸c. –Generar c`arrega al bus CAN. –Aturar qualsevol de les anteriors accions. Per complir la bidireccionalitat dels missatges es va estudiar la millor manera de rebre els missatges en el microcontrolador, d’aquesta manera veient com es rebien les interrupcions del bus CAN, es va seguir la mateixa metodologia per rebre una interrupci´o cada cop que el buffer d’entrada del port s`erie s’omplia. Tenint en compte que les diferents instruccions que se li demanen al microcontrolador monitor no s´on critiques en temps de resposta s’ha optat per crear aquests missatges de 8 bytes m´es que suficients per complir les especificacions actuals i mantenint un marge per possibles ampliacions (actualment en el pitjor cas s’omplen 2 d’aquests, 46 3.2 Disseny del Nou laboratori quan es demana monitoritzar un lla¸c de control, al qual ens referim amb l’ultim byte de la trama). Per tant s’ha dissenyat l’estructura b`asica de tots els senyals de control amb la seg¨uent arquitectura (figura 3.17): 1 byte 7 bytes 01234567 id senyal Informaci´o necess`aria pel tipus de senyal Figura 3.17: Arquitectura b`asica dels missatges enviats per RS232. On cada identificador t´e el valor i el significat indicat en la taula 3.1. Senyal Valor Significat SIGNAL STOP 0x01 Sumat a qualsevol altre identificador cancel·la l’acci´o principal. SIGNAL MONITOR 0x00 Per comen¸car a monitoritzar un lla¸c de control. SIGNAL PERCENT 0x02 Per comen¸car a generar c`arrega al bus CAN. SIGNAL DEVICES 0x04 Per comen¸car a llistar tots els lla¸cos que hi ha actualment al bus CAN. Taula 3.1: Identificadors dels senyals de control enviats al Monitor per RS232. Amb tots aquests punts ben clars es va crear un diagrama dels elements que formaran el laboratori, amb tots els dispositius que poden formar part d’ell, i les diferents interaccions que han de realitzar. En aquest diagrama podrem observar els per´ıodes dels diferents missatges, l’esquema d’identificadors i el tipus de m`ascares i filtres que seran ´utils per rebre els missatges. Tot aix`o es pot observar en el diagrama de la figura 3.18. 47 3. DISSENY DEL LABORATORI Monitoritzar el llaç X Activat per botó Saturar Bus al X% Activat per barra Llistar tots els dispositius Activat per botó Informació llaç X Activat i periodic : 10 ms Llista de llaços ultims 10 ms Activat i periodic : 10 ms Monitor/Supervisor Sensor/Actuador/Supervisor Serial RS232 Comandes PC -> Monitor Informació Monitor -> PC Supervisor -> DCSMonitor Capçalera : 1 byte : 0x01 Temps : 4 bytes : TTTT Referencia : 4 bytes : RRRR Primera integral : 4 bytes : PPPP Segona integral : 4 bytes : SSSS Tipus d'informació : 1 byte : I * Dependent del tipus: 48 bytes : D...D * només el Monitor Esquema informació Sensor/Actuador -> PC ( 23 bytes ) \ Capç. /\ Temps /\ Ref. /\ 1ª Int. /\ 2ª int. /\ lliure / 1 TTTT RRRR PPPP SSSS XX Esquema informació Monitor -> PC ( 71 bytes ) \ Capç. /\ Temps /\ Ref. /\ 1ª Int. /\ 2ª Int. /\ tipus /\ Dep. / 1 TTTT RRRR PPPP SSSS I D...D Llista de llaços de control Tipus d'informacio = 0x01 Primer byte dels 48 = numero de dispositius que venen en els seguents bytes. Cada un dels seguents bytes es un identificador de llaç diferent. Serial RS232 Informació del llaç al que pertany Periodic : 10 ms Aturar monitorització Activat per botó Desactiva la captura i l'enviament. Aturar llistar dispositius Activat per botó Desactiva la captura i l'enviament de tots els paquets DCSMonitor Mode PC -> Monitor DCSMonitor Mode PC -> Sensor/Actuador Missatges de 8 bytes Missatges de 71 bytes Missatges de 23 bytes Informació Sensor/Actuador -> PC DCSMonitor -> Monitor Id senyal : 1 byte : I Dependent del senyal : 7 bytes : DDDDDDD Esquema general de missatge \ id senyal /\ dependent del senyal / I DDDDDDD Senyal STOP : 0x01 Sumat a qualsevol altre Id de senyal atura l'acció principal. Senyal MONITORITZAR : id senyal = 0x00 Activa la minitorització d'un llaç de control. L'ultim byte dels dependents es el numero de llaç a monitoritzar. Senyal SATURAR : id senyal = 0x02 Activa la generació de missatges CAN en el bus amb un percentatge. L'ultim byte dels dependents es per indicar el percentatge de saturació del bus CAN. Senyal LLISTAR : id senyal = 0x04 Activa l'enviament de identificadors de llaços existents al bus CAN. Figura 3.18: Diagrama de comunicacions i missatges RS232. - Diagrama de funcionament del laboratori, amb el disseny dels diferents missatges de comunicaci´o per RS232. A la part superior es pot observar l’entorn entre un dispositiu Monitor i el programa en aquest mode, i a la part inferior connectat amb un dispositiu Sensor/Actuador . 48 3.2 Disseny del Nou laboratori 3.2.3.1 Senyals de control per monitoritzar Aquest senyal ´es l’encarregat d’indicar al Monitor que volem capturar tota la informaci´o que intercanvii el lla¸c de control especificat, i que tota aquesta informaci´o ens sigui enviada en temps real per poder dibuixar les gr`afiques del control. Aquesta informaci´o ser`a el valor de refer`encia, el valor d’entrada del doble integrador, i la primera i segona integral (En cas de no indicar-li quin lla¸c volem monitoritzar per defecte li demanarem el lla¸c 0, que ´es el primer lla¸c disponible). En el moment que vulguem aturar aquestes captures enviarem al monitor el senyal d’aturada de monitoritzaci´o amb el qual deixar`a de centrar-se en aquest lla¸c. Aquestes s´on les trames dels dos missatges relatius a la monitoritzaci´o (figura 3.19): 1 byte 6 bytes 1 byte 01234567 0x00 ID LLAC¸ (a) Comen¸ca la monitoritzaci´o del lla¸c de control ID LLAC¸. 1 byte 7 bytes 01234567 0x01 (b) Atura la monitoritzaci´o actual. Figura 3.19: Missatges de monitorizaci´o per RS232. Per tant l’esquema natural en la monitoritzaci´o i parada d’aquesta seria el seg¨uent: 1. Seleccionem el lla¸c de control que volem monitoritzar. 2. Enviem la trama ID MONITOR amb l’identificador del lla¸c de control. 3. El microcontrolador monitor rep el senyal i activa els filtres CAN i els seus respectius buffers per capturar totes les trames que el lla¸c de control intercanvi¨ın. 4. El microcontrolador activa una tasca peri`odica per enviar totes les lectures que efectu¨ı per RS232. 5. En cada missatge CAN que va dirigit a algun dispositiu del lla¸c el monitor es guarda els valors adequats. 49 3. DISSENY DEL LABORATORI 56 4 Implementaci´o del laboratori En aquest apartat aprofundirem en c´om s’ha dut a terme la programaci´o de les diferents parts que conformen el laboratori que hem dissenyat anteriorment (cap´ıtol 3), i podrem veure d’aquesta manera com podem modificar el codi per ampliar el laboratori amb una infinitud de opcions, modificant o afegint diferents dispositius, o missatges de comunicaci´o. Per implementar el laboratori hem necessitat crear l’entorn necessari per compartir el bus CAN entre varis lla¸cos de control, i tenir el programa DCSMonitor connectat al dispositiu Monitor via RS232, per tant existeix una configuraci´o b`asica formada per dos lla¸cos de control monitoritzats per un dispositiu Monitor i aquest connectat al programa DCSMonitor capa¸c de modificar el comportament d’aquest ultim. Es pot veure una fotografia de tot l’entorn preparat i configurat per tal de treballar amb aquest sistema, i amb el qual s’ha pogut dur a terme tota la fase de implementaci´o (figura 4.1). Hem dividit el cap´ıtol en dues seccions principals, la part de programaci´o en Python del programa DCSMonitor (el programa que s’executa en l’ordinador) on podrem veure els passos que s’han seguit per crear la interf´ıcie visual (secci´o 4.1.1), com hem pogut obrir el port RS232 i posteriorment enviar i rebre tot tipus de missatges (secci´o 4.1.2), com hem integrat els plots del lla¸c de control que estigu´essim monitoritzant o connectats (secci´o 4.1.3), com hem fet per exportar una gr`afica generada en diferents formats (seccio 4.1.4), com hem realitzat l’actualitzaci´o de les estad´ıstiques en temps real (secci´o 4.1.5), i finalment quins s´on els passos seguits per implementar els diferents idiomes, i per afegir-ne de nous (secci´o 4.1.6). 57 4. IMPLEMENTACI ´ O DEL LABORATORI Figura 4.1: Entorn de treball - Tot el material necessari per implementar el laboratori amb dos lla¸cos de control, un programador Mplab ICD2, un conversor de RS232 a USB, el programa DCSMonitor en marxa al monitor esquerra i codi font al monitor de la dreta. I la part de programaci´o en Cen el Sistema Operatiu en Temps Real Erika Enterprise que corre en els diferents dispositius del control (microcontroladors dsPIC33FJ256MC710, en la placa FLEX ), on es podr`a veure com implementar noves tasques en el SO Erika (secci´o 4.2.1), com hem implementat la recepci´o i enviament dels diferents missatges per RS232 (secci´o 4.1.2), i el m´es important en els sistemes distribu¨ıts la comunicaci´o mitjan¸cant el bus CAN (secci´o 4.2.3); la creaci´o de m`ascares i filtres, la recepci´o dels diferents missatges, l’enviament d’aquests, i la creaci´o de una pila per mantenir un llistat de tots els lla¸cos de control presents al bus. 4.1 DCSMonitor Com hem vist anteriorment, el programa DCSMonitor ´es l’encarregat de mostrarnos en temps real el funcionament dels diferents controls als que estem connectats via RS232. Gracies a ell podem monitoritzar un bus CAN (si estem connectats a un dispositiu Monitor ), o podem comprovar que el control que estem executant sigui correcte (connectats directament a un dispositiu Sensor/Actuador ). En aquest apartat 58 4.1 DCSMonitor s’explica com s’han programat totes les parts implicades del laboratori que formen part del programa DCSMonitor , comen¸cant per l’aspecte visual, passant per les comunicacions i el mostreig dels plots, i acabant finalment per la integraci´o amb varis idiomes. Cal indicar que per crear les gr`afiques en temps real s’ha pres com a exemple el codi de Yassine Benabbas amb Llicencia Creative Commons present en la bibliografia (11, Cre´er un graphe dynamique avec PyPlot). 4.1.1 Interficie Pel disseny de la part visual del programa es va utilitzar la eina QTCreator , el qual ´es un IDE per realitzar interf`ıcies de programes arrossegant i enganxant les diferents parts. Aix`o ens permet guanyar temps en petits programes, i en programes grans ´es quasi impossible prescindir d’aquesta ajuda. Un cop hem realitzat la organitzaci´o de tots els botons i etiquetes que formen el programa, li indiquem a QTCreator que ens generi el codi font d’aquest en format .ui (es posa un fragment de codi com a exemple, 4.1, ja que el codi complert ocupa unes 700 l´ınies, m´es o menys 25 p`agines) Codi XML 4.1: Fragment del fitxer d’interficie dcsmmainwindow.ui 1<?xml version ="1.0 " encoding ="UTF -8"?> 2<ui version=" 4.0"> 3<class >MainWindow </ class > 4< widget class ="QMainWindow" name=" MainWindow "> 5<property name =" geometry "> 6<rect > 7<x>0</x> 8<y>0</y> 9<width >752 </ width > 10 <height >790 </height > 11 </rect > 12 </ property > 13 <property name ="windowTitle"> 14 <string >Distributed Control Systems Monitor </ string > 15 </ property > 16 ... 59 4. IMPLEMENTACI ´ O DEL LABORATORI Un cop hem generat aquest fitxer ´es hora de traduir-ho a Python , per tal de que la llibrer´ıa que utilitzem PyQT4 pugui generar l’interficie. Per fer aix´o ens ajudem del programa pyuic4 que amb la comanda 4.2 genera un fitxer com el del fragment 4.3 Codi Bash 4.2: Creant fitxer d’interficie pyuic4 dcsmmainwindow.ui > dcsmmainwindow.py Codi Python 4.3: Fragment de codi del fitxer dcsmmainwindow.py 1try: 2_fromUtf8 = QtCore . QString . fromUtf8 3except AttributeError: 4_fromUtf8 = lambda s: s 5 6class Ui_MainWindow ( object ): 7def setupUi ( self , MainWindow ): 8MainWindow . setObjectName ( _fromUtf8 (" MainWindow ")) 9MainWindow . resize (752 , 790) 10 self . centralwidget = QtGui . QWidget ( MainWindow ) Finalment es pot veure a la figura 4.2 el resultat d’aquests passos, amb una captura de la pantalla de l’execuci´o. 60 4.1 DCSMonitor Figura 4.2: Interf´ıcie final del programa DCSMonitor - Captura de pantalla del programa DCSMonitor mostrant el control amb el bus CAN saturat al 89%, sense el plot de la primera integral i en angl`es. 61 4. IMPLEMENTACI ´ O DEL LABORATORI 4.1.2 Comunicaci´o s`erie RS232 Ja hem vist en la secci´o de disseny dels tipus de missatge serie 3.2.3 els diferents missatges que han de enviar-se entre el programa DCSMonitor i els dispositius, ara veurem com hem implementat aquest tipus de comunicacions per la part de l’ordinador. En aquest apartat indicarem com hem fet per configurar el port serie amb PySerial , els m`etodes que hem utilitzat per enviar els senyals al dispositiu connectat, i com hem rebut els valors necessaris per poder mostrar les gr`afiques o llistar els diferents lla¸cos del bus CAN. 4.1.2.1 Obrir i tancar dispositiu s`erie Per utilitzar aquest tipus de comunicaci´o primer de tot hem de decidir alguns dels par`ametres que porta associats el tipus de comunicaci´o serie. Com anteriorment en el laboratori ja es van ajustar aquests par`ametres el que farem ´es adaptar-nos a ells i configurar el dispositiu tal i com estava funcionant. Per fer aix`o primer de tot importem el paquet serial de Python , i tot seguit assignem els valors als diferents par`ametres (codi 4.4). Codi Python 4.4: Codi per configurar dispositiu s`erie 1# for communicate with pic 2import serial 3 4PORT = ’/ dev / ttyUSB0 ’ 5BAUDRATE = 115200 6BYTESIZE = serial . EIGHTBITS 7PARITY = serial . PARITY_NONE 8STOPBITS = serial . STOPBITS_ONE 9TIMEOUT = 10 Amb tots els par`ametres ben instanciats, ja podem esperar el senyal de connexi´o per activar aquest dispositiu. El metode que s’utilitza ´es mitjan¸cant un bot´o a la interf´ıcie del programa, la qual est`a enlla¸cada amb un senyal. En el moment en el que el bot´o sigui premut, s’activar`a la funci´o que li hem indicat (codi 4.5). Codi Python 4.5: Disparador de connexi´o de port serie 62 4.1 DCSMonitor 1QtCore . QObject . connect ( self. pushButton_connect , QtCore . SIGNAL(" clicked ()"), self. clicked_connect ) La funci´o amb la que est`a enlla¸cada el bot´o comprovar`a si s’est`a activant o s’est`a desactivant. Si es prem per activar el dispositiu, provar`a d’activar el port serie cridant a la funci´o connect serial (codi 4.7, explicat m´es endavant), si aix`o te `exit habilitar`a tots els botons que estiguin permesos segons el mode d’execuci´o en el que es trobi el programa (PC−>Sensor/Actuador o PC−>Monitor ) (figura 4.3b), en cas contrari marcar`a en vermell que no s’ha pogut connectar (figura 4.3d). En el cas en que s’estigui desconnectant el dispositiu serie, aturar`a tots els events peri`odics que estiguin activats (recepci´o de dades, dibuix de la gr`afica i calcul d’estad´ıstiques), tanca el dispositiu serie, i finalment desactivar`a tots els botons que no calen usar. Codi Python 4.6: Codi per obrir/tancar dispositiu s`erie 1def clicked_connect ( self ): 2if not self . pushButton_connect . isChecked (): 3self . timer_graph . stop () 4self . timer_data . stop () 5self . timer_statistics . stop () 6self . ser . close () 7self .ser = 0 8self . lineEdit_state . setPalette ( QtGui . QPalette ( QtGui . QColor(" gray "))) 9self . lineEdit_state . setText ( QtGui . QApplication . translate (" MainWindow ","Disconnected", None , QtGui. QApplication . UnicodeUTF8 )) 10 self . pushButton_connect . setText ( QtGui . QApplication . translate (" MainWindow ","Connect", None , QtGui . QApplication . UnicodeUTF8 )) 11 self . pushButton_monitor . setEnabled (0) 12 self . pushButton_monitor . setChecked (0) 13 self . pushButton_reload . setEnabled (0) 14 self . slider_saturation . setEnabled (0) 15 16 else: 63 4. IMPLEMENTACI ´ O DEL LABORATORI 17 if self.connect_serial(): 18 self . lineEdit_state . setPalette ( QtGui . QPalette ( QtGui . QColor (" green "))) 19 self . lineEdit_state . setText ( QtGui . QApplication . translate (" MainWindow "," Connected ", None , QtGui. QApplication . UnicodeUTF8 )) 20 self . pushButton_connect . setText ( QtGui . QApplication . translate (" MainWindow "," Disconnect ", None , QtGui . QApplication . UnicodeUTF8)) 21 self . pushButton_monitor . setEnabled (1) 22 self . slider_saturation . setEnabled (1) 23 if self. actionPC_Monitor . isChecked (): 24 self . pushButton_reload . setEnabled (1) 25 else: 26 self . lineEdit_state . setPalette ( QtGui . QPalette ( QtGui . QColor ("red "))) 27 self . lineEdit_state . setText ( QtGui . QApplication . translate (" MainWindow "," Error connecting " , None , QtGui . QApplication . UnicodeUTF8 )) 28 self . pushButton_connect . setChecked (0) La funci´o connect serial ´es l’encarregada de connectar el dispositiu serie, primer de tot comprova si el dispositiu ja havia estat engegat algun cop. Si no ho havia estat li assigna tots els par`ametres anteriorment instanciats, i posteriorment intenta connectar. En cas de error la funci´o retornar`a 0, en cas contrari retornar`a 1. En cas que el dispositiu ja hagu´es estat obert anteriorment, la configuraci´o ja est`a instanciada, per tant nom´es provarem d’obrir-la de nou. Igual que abans retornar`a zero o u segons hagi fracassat o connectat amb `exit (codi 4.7). Codi Python 4.7: Codi per connectar port serie 1def connect_serial(self): 2""" Connects to the serial device , if not return 1 """ 3if self.ser == 0: 4try: 64 4.1 DCSMonitor 5self . ser = serial . Serial (PORT , BAUDRATE , BYTESIZE , PARITY , STOPBITS , TIMEOUT ) 6# self . ser = serial . Serial ( ’/ dev / ttyUSB0 ’, 115200 , timeout =10) 7except: 8self . textBrowser . append ( QtGui . QApplication . translate (" MainWindow "," \n\t ---- Failed to connect to the device ----\n", None , QtGui . QApplication . UnicodeUTF8 )) 9return 0 10 # this code shouldn ’t be never executed 11 else: 12 try: 13 self .ser. open () 14 except: 15 self . textBrowser . append ( QtGui . QApplication . translate (" MainWindow "," \n\t ---- Failed to connect to the device ----\n", None , QtGui . QApplication . UnicodeUTF8 )) 16 return 0 17 return 1 Tot seguit es pot veure els canvis que s’efectuen durant la connexi´o del port serie, en la primera imatge abans de connectar al dispositiu /dev/ttyUSB0, despr´es un cop ja s’ha establert la connexi´o, un cop hem desconnectat correctament el port, i la ultima imatge quan hi ha algun problema de connexi´o (figura 4.3). (a) Pendent de connectar. (b) Connectat correctament. (c) Desconnectat correctament. (d) Error al connectar. Figura 4.3: Estat de connexi´o amb el Supervisor via RS232. 65 4. IMPLEMENTACI ´ O DEL LABORATORI 3# Periodical tasks 4QtCore . QObject . connect ( self. timer_data , QtCore . SIGNAL(" timeout ()") , self . get_periodical_data ) Per´o aquesta declaraci´o que hem creat no s’activa per si sola, sin´o que hem d’engegar el temporitzador quan el necessitem, per tant cada cop que necessitem rebre informaci´o de un lla¸c de control, o que volem una llista dels diferents lla¸cos que hi ha al bus CAN al clicar el bot´o adequat (i despr´es de realitzar codi que hem explicat en anteriors seccions) acabar`a cridant a la funci´o get periodical data (codi 4.15). Aquesta funci´o ´es l’encarregada de comprovar que la temporitzaci´o funciona correctament, reactivant-la o parant-la en el moment oport´u. El que fa primer de tot es comprovar que un dels botons que indiquen rebre informaci´o estigui premut (aquests botons es queden premuts fins que no es torna a clicar per segon cop), en cas contrari ha d’aturar aquesta periodicitat i per tant ja no activa el temporitzador. Un cop sap que realment es vol rebre informaci´o, comprova que s’hagi dibuixat ja la informaci´o que hi havia pendent, si ja s’ha dibuixat torna a rebre dades cridant a la funci´o recive data (codi de la funci´o 4.16). Aix`o ´es aix´ı per crear una zona d’exclusi´o m´utua (tamb´e anomenada Mutex), que evitar`a que intentem dibuixar la gr`afica de dades que estan a mig omplir. I finalment reactiva el temporitzador per tornar a executar la mateixa funci´o. Codi Python 4.15: Codi per reactivar l’adquisici´o de dades 1def get_periodical_data (self): 2""" Updates the data """ 3if not self . pushButton_monitor . isChecked () and not self . pushButton_reload . isChecked (): 4return 5 6if self. updated_data == 0 : 7# recive new serial data 8self . recive_data () 9 10 # activate the periodical reception of data 11 self . timer_data . start ( DATA_TIME ) 72 4.1 DCSMonitor Finalment la funci´o encarregada en rebre les dades pel port serie ´es la funci´o recive data (codi 4.16). Aquesta funci´o procura agafar tota la informaci´o que hi hagi pendent al buffer d’entrada del port serie. Tenint en compte que el dispositiu Monitor i el Sensor/Actuador envien aquesta informaci´o cada 10 milisegons, i nosaltres fem lectures com a m´ınim cada 5 milisegons, tenim temps per fer la lectura i seguir executant altres codis. Primer de tot busca el byte de cap¸calera; aquest byte ´es un 0x01 que est`a al principi de tots els missatges que el dispositiu ens envia. Un cop ha trobat aquest byte sap que te les dades alineades, i pot prosseguir a llegir el numero de bytes que li correspongui (segons estigui en mode PC−>Sensor/Actuador o PC−>Monitor llegir`a 23 o 71 bytes respectivament). Ja amb el numero de bytes llegits, comprova si el bot´o de monitoritzaci´o esta premut, per tal de agafar les dades per dibuixar la gr`afica o passar a rebre la llista de dispositius (el codi que falta est`a en la secci´o 4.1.2.6, codi 4.17). En la majoria de casos aquest bot´o si que est`a premut, i per tant agafa els bytes en l’ordre correcte per formar totes les variables necess`aries, prepara el text per mostrar per pantalla i l’escriu en la part inferior del programa (figura 4.5). Despr´es afegeix als arrays el nou valor, i en treu un si ha arribat al m`axim. Despr´es modifica els valors que apareixen en les estad´ıstiques i habilita la zona d’exclusi´o. Codi Python 4.16: Codi per rebre els valors monitoritzats 1def recive_data ( self ): 2""" Get messages from the serial port """ 3# read all available data 4while self .ser. inWaiting () > self. INPUT_DATA_SIZE +1: 5data = array . array ( ’c’) 6# search the header 7data . append ( self . ser .read (1)) 8while data [0] != chr (1): 9data [0] = self . ser. read (1) 10 11 # wait for all available data 12 while self .ser. inWaiting () < ( self . INPUT_DATA_SIZE -1): 13 time . sleep (0.03) ; 14 73 4. IMPLEMENTACI ´ O DEL LABORATORI 15 # recives data 16 data = self . ser. read (self . INPUT_DATA_SIZE -1) 17 18 # prove if you want graphical data 19 if self. pushButton_monitor . isChecked () : 20 # decodes the data 21 t = struct.unpack(’I’, data[3]+data[2]+data [1]+data[0]) 22 r = struct.unpack(’f’, data[4]+data[5]+data [6]+data[7]) 23 x0 = struct.unpack(’f’, data[8]+data[9]+data [10]+ data [11]) 24 x1 = struct.unpack(’f’, data [12]+ data [13]+ data [14]+ data [15]) 25 u = struct.unpack(’f’, data [16]+ data [17]+ data [18]+ data [19]) 26 27 self . time = t [0]*25e -9 28 29 # prepare the string output 30 aux_str = "t="+str ( self . time)+"\t" 31 aux_str += "r="+str (r [0]) +"\t" 32 aux_str += "u="+str (u [0]) +"\t" 33 aux_str += " x1 = "+str (x1 [0])+"\t" 34 aux_str += " x0 = "+str (x0 [0])+"\n" 35 # print string output 36 self . textBrowser . insertPlainText ( aux_str ) 37 38 # append data to the arrays 39 self . graf_t . append ( self .time ) 40 self . graf_r . append (r [0]) 41 self . graf_x0 . append ( x0 [0]) 42 self . graf_x1 . append ( x1 [0]) 43 self . graf_u . append (u [0]) 44 74 4.1 DCSMonitor 45 # remove one value if the arrays have maximum length 46 if self. graf_t. buffer_info () [1] >= NUM_SAMPLES: 47 self . graf_t . pop (0) 48 self . graf_r . pop (0) 49 self . graf_x0 . pop (0) 50 self . graf_x1 . pop (0) 51 self . graf_u . pop (0) 52 53 # reload number of samples lavel 54 self . label_samples_value . setText ( str (self . graf_t . buffer_info () [1]) ) 55 # reload number of waiting chars in serial rx buffer 56 self . label_rx_buff_value . setText ( str (self .ser . inWaiting ())) 57 58 # reload mutex area 59 self.updated_data = 1 (a) Rebent els valors d’una monitoritzaci´o. (b) Havent finalitzat una monitoritzaci´o. Figura 4.5: Espai de text per valors monitoritzats. 75 4. IMPLEMENTACI ´ O DEL LABORATORI 4.1.2.6 Recepci´o de llista de dispositius Per la recepci´o dels identificadors dels lla¸cos de control com hem vist en l’apartat anterior 4.1.2.2 s’activa la mateixa funci´o peri`odica per rebre informaci´o, per tant el codi que segueix ´es la continuaci´o de la funci´o vista anteriorment recive data (codi 4.16). Per tant seguint l’execuci´o d’aquesta funci´o abans mencionada, comprovem si el byte 20 de les dades que ens arriben est`a a valor dos. En aquest cas significa que en el seg¨uent byte ve el nombre de identificadors diferents de mida un byte que el segueixen. Aix´ı que comprova un a un si ja es trobaven a la llista, i si no ´es aix´ı els afegeix. Codi Python 4.17: Codi per rebre la llista de dispositius 1.... 2# prove if there are available id ’s 3if ( self . actionPC_Monitor . isChecked () and data [20] == chr (2)): 4# if it is true , looks how much id ’s 5i = struct.unpack(’B’, data [21]) 6 7if i [0] < STACK_SIZE : 8for zin range (i [0]): 9new_device = struct . unpack ( ’B’, data [z +22]) 10 new_string = str ( new_device [0]) 11 12 llista = self . listWidget_link . findItems ( new_string , QtCore .Qt. MatchExactly ) 13 if len( llista ) == 0: 14 self . listWidget_link . addItem ( new_string ) Es poden veure com a exemple algunes captures de pantalla de la llista abans de comen¸car a demanar-li els identificadors (figura 4.6a), actualitzant la llista en un bus amb dos lla¸cos de control (figura 4.6b), i la ultima imatge havent demanat la llista en un bus on existien varis lla¸cos de control (figura 4.6c). 76 4.1 DCSMonitor (a) Abans de demanar la llista. (b) Amb dos lla¸cos al bus CAN. (c) Amb molts lla¸cos al bus CAN Figura 4.6: Llista de lla¸cos de control al bus CAN. 4.1.3 Generaci´o de gr`afiques en temps real Generar aquestes gr`afiques ´es un dels prop`osits m´es importants del programa, i per tant ha de ser prou r`apida per no saturar el programa per`o al mateix temps donar una sensaci´o visual de moviment. Aquesta generaci´o est`a associada a un temporitzador especific, enlla¸cat a un disparador que activa la funci´o update graph (codi 4.19). Aquest temporitzador s’activa nom´es quan es prem el bot´o de monitoritzaci´o, vist en la secci´o 4.1.2.3. Codi Python 4.18: Temporitzador i disparador per dibuixar la gr`afica 1timer_graph = QtCore . QTimer () 2 3# Periodical tasks 4QtCore . QObject . connect ( self. timer_graph , QtCore . SIGNAL(" timeout ()") , self . update_graph ) Un cop s’ha activat el temporitzador que crida aquesta funci´o, primer de tot comprova que hi hagi dades noves per dibuixar i que no s’estiguin modificant en aquest prec´ıs instant (aix`o s’ha vist en la secci´o de recepci´o de dades 4.1.2.5). Si les dades que hi ha han estat actualitzades dibuixa primer les l´ınies verticals i horitzontals que hi ha darrera dels plots. I despr´es comprova un a un si hi ha marcada la opci´o de dibuixar els diferents plots (refer`encia, primera i/o segona integral i valor d’entrada; figura 4.7); segons quins estiguin activats, els crea i dibuixa o no. Finalment prova de pintar tot el que ha generat, actualitza la variable frames per second per indicar que s’ha fet un 77 4. IMPLEMENTACI ´ O DEL LABORATORI nou dibuix i es marca la variable per la zona d’exclusi´o m´utua perqu`e es puguin seguir afegint dades als arrays. Finalment comprova que encara es vulgui seguir dibuixant la gr`afica i es reactiva la temporitzaci´o. Codi Python 4.19: Codi per actualitzar la gr`afica 1def update_graph(self): 2""" Updates the graph """ 3# looks for new data 4if self. updated_data == 1: 5 6self . mplWidget . canvas .ax. set_xbound ( self .time - XLIM , self . time) 7self . mplWidget . canvas . draw () 8 9try: 10 #Draw the lines 11 if self. checkBox_R . isChecked () : 12 self . referenceLine . set_data ( self .graf_t , self . graf_r ) 13 self . mplWidget . canvas .ax. draw_artist ( self . referenceLine ) 14 if self. checkBox_x0 . isChecked () : 15 self . x0Line . set_data ( self . graf_t , self . graf_x0) 16 self . mplWidget . canvas .ax. draw_artist ( self .x0Line) 17 if self. checkBox_U . isChecked () : 18 self . uLine . set_data ( self . graf_t , self . graf_u) 19 self . mplWidget . canvas .ax. draw_artist ( self . uLine ) 20 if self. checkBox_x1 . isChecked () : 21 self . x1Line . set_data ( self . graf_t , self . graf_x1) 22 self . mplWidget . canvas .ax. draw_artist ( self .x1Line) 78 4.1 DCSMonitor 23 except AssertionError: 24 pass 25 26 try: 27 self . mplWidget . canvas . blit (self . mplWidget . canvas .ax. bbox ) 28 except AttributeError: 29 pass 30 31 self .fps = self .fps +1 32 33 self.updated_data = 0 34 35 if self. pushButton_monitor . isChecked () == 1: 36 # activate the periodical update graph 37 self . timer_graph . start ( GRAPH_REFRESH ) (a) Abans alguns plots seleccionats. (b) Amb tots els plots seleccionats. Figura 4.7: Opci´o de plots per la gr`afica. 4.1.4 Exportar gr`afica Exportar les gr`afiques que s’estiguin monitoritzant en temps real ´es molt important, ja que gracies a aix`o es pot guardar una captura de cada grup del laboratori, o generar imatges vectorials f`acilment introdu¨ıbles en articles o llibres (formats com .eps, .svg, .ps o .pdf). Per poder generar aquestes imatges s’espera que es premi un bot´o, que est`a enlla¸cat mitjan¸cant un disparador (codi 4.20) a la funci´o que genera la imatge 79 4. IMPLEMENTACI ´ O DEL LABORATORI save image (codi 4.21). Codi Python 4.20: Disparador per exportar la gr`afica 1QtCore . QObject . connect ( self . pushButton_save , QtCore . SIGNAL( _fromUtf8 (" clicked ()")) , self . save_image ) Un cop han activat aquesta funci´o primerament s’obra una finestra nova on es pot introduir el nom del nou fitxer a crear (figura 4.8). A part de poder introduir el nom, podem llistar tots els fitxers dels diferents tipus que el programa ´es capa¸c de exportar, que hi hagin en el directori que estem observant. Per aquest motiu en la creaci´o de la finestra apareixen descripcions d’aquests tipus de fitxers (figura 4.9). Figura 4.8: Finestra per posar nom a la gr`afica exportada - Un cop l’usuari ha introdu¨ıt el nom i clicat a acceptar comen¸carem a generar una gr`afica nova des de zero. Comprovarem un a un tots els plots que hem de dibuixar, afegint a la gr`afica els que calguin. Tot seguit indicarem quin rang de valors volem dibuixar, i posarem t´ıtol, subt´ıtol, i noms als diferents eixos (tots aquests textos s´on tradu¨ıts a l’idioma que hi hagi seleccionat en el programa). Despr´es assigna algunes de les mides del dibuix, i finalment intenta guardar la imatge amb el nom i format que li hagim indicat anteriorment. Si per alguna ra´o fall´es en aquesta tasca, procuraria 80 4.1 DCSMonitor Figura 4.9: Tipus de fitxer als que es pot exportar - guardar-lo en format .svg. Al acabar de generar la imatge aquesta gr`afica nova es neteja per alliberar la mem`oria. Un cop finalitzat el programa, el resultat de la captura de imatges ´es el que es pot observar en la figura 4.10, en la que apareix una gr`afica generada en angl`es, amb totes les l´ınies, i una altre en catal`a nom´es amb les l´ınies de refer`encia i de sortida del doble integrador. Codi Python 4.21: Codi per generar imatge d’una gr`afica 1def save_image ( self ): 2""" Exports the graph into an image """ 3# open the dialog and get the selected file 4file_one = QtGui. QFileDialog . getSaveFileName ( 5self, 6QtGui. QApplication . translate ( 7" MainWindow ", 8" Supported formats :", 9None, 10 QtGui. QApplication . UnicodeUTF8 )+ 11 " emf , eps , pdf , png , ps , raw , rgba , svg , svgz", 12 "", 13 " Enhanced MetaFile \t. emf (*. emf );; "+ 14 " Encapsulated PostScript \t. eps (*. eps) ;; "+ 15 " Portable Document Format \t. pdf (*. pdf );; "+ 81 4. IMPLEMENTACI ´ O DEL LABORATORI Codi Python 4.23: Codi per generar i actualitzar les estad´ıstiques. 1def update_statistics(self): 2""" Update value of labels in statistics """ 3if self . ser != 0: 4# reload number of samples lavel 5self . label_samples_value . setText (str( self .graf_t . buffer_info () [1]) ) 6# reload number of waiting chars in serial rx buffer 7self . label_rx_buff_value . setText (str( self .ser. inWaiting ())) 8 9self . label_fps_value . setText (str( self .fps *2)) 10 11 self .fps = 0 12 13 if self . pushButton_monitor . isChecked () == 0: 14 self . force_update_graph () 15 16 if self . label_Est_value . text () != ’(>_ <) ’: 17 self . label_Est_value . setText (’(>_ <) ’) 18 else: 19 self . label_Est_value . setText (’( o_o)’) 20 21 self . label_T_value . setText ( str (self . listWidget_link . count ())) 22 23 self . timer_statistics . start ( STAT_REFRESH ) Tot seguit es poden veure diferents captures del canvi que es produeix en les estad´ıstiques, primer es veu quan encara no est`a connectat al port serie, despr´es al connectar per`o no tractar les dades que ens envia el dispositiu, despr´es un cop estem tractant les dades rebudes i dibuixant la gr´afica en temps real, i per ultim un cop hem aturat la monitoritzaci´o del lla¸c de control (figura 4.11). 88 4.1 DCSMonitor (a) Pendent de comen¸car. (b) Connectat al dispositiu. (c) Monitoritzant. (d) Monitoritzaci´o aturada. Figura 4.11: Comparaci´o dels valors estad´ıstics. 4.1.6 Idiomes Un dels requisits que es buscava complir en el nou laboratori era que el programa visual fos multiling¨ue per tal de poder ser distribu¨ıt m´es f`acilment podent realitzar el laboratori en diferents pa¨ısos. Aix´ı que el programa DCSMonitor (que s’executa a l’ordinador) ´es capa¸c de mostrar tota la informaci´o en varis idiomes, i ´es f`acilment ampliable ja que s’ha realitzat de forma estructurada per tal que seguint algunes instruccions es puguin generar m´es idiomes. Com vam dir a l’apartat de disseny 3.2.5, aix`o ho hem aconseguit utilitzant una combinaci´o de diferents eines amb les quals una rere l’altre ens generen el resultat desitjat. Tot seguit s’expliquen les diferents eines utilitzades, i com s’implementa cadascuna. 4.1.6.1 PyQT4 Aquesta llibreria ´es l’encarregada de deixar-ho tot preparat perqu`e els textos del programa siguin traduits. Aix´ı que primerament, dintre de tot el codi del programa, es pot observar que tots els textos traduibles est´an envoltats amb la mateixa funci´o QtGui.QApplication.translate (veure exemple en el codi 4.24). Aquesta funci´o prepara tot l’entorn necessari per agafar tots aquests textos, i posteriorment mitjan¸cant uns fitxers de traducci´o traduir en temps d’execuci´o. En aquest exemple li indiquem que la paraula ”Sent : ”volem que pugui ser tradu¨ıda, per tant cada cop que cridem aquesta funci´o amb aquesta estructura ens retornar`a la paraula en l’idioma que tinguem carregat. Codi Python 4.24: Exemple de text per traduir 1QtGui . QApplication . translate ( 89 4. IMPLEMENTACI ´ O DEL LABORATORI 2" MainWindow ", 3"Sent : ", 4None, 5QtGui . QApplication . UnicodeUTF8 ) Un cop tenim tot el codi amb els textos a traduir envoltats de la funci´o anterior, generarem les traduccions en fitxers .qm amb els dos programes que explicarem m´es endavant (Pylupdate4 4.1.6.2 i QtLing¨uist 4.1.6.3), i un cop generats nom´es caldr`a carregar executar el codi 4.25. Per tant cada cop que des de les prefer`encies es seleccioni un idioma nom´es carregarem el fitxer .qm que desitgem. Codi Python 4.25: Canviant idioma 1QtGui .qApp . removeTranslator ( self . translator ) 2self . translator . load (’dcsmmainwindow_es.qm’) 3QtGui .qApp . installTranslator ( self . translator ) 4self . retranslateUi ( self ) 4.1.6.2 Pylupdate4 Un cop tenim tot el codi del programa DCSMonitor preparat amb els textos a traduir de la forma que s’ha comentat en la secci´o 4.1.6.1, ´es hora d’utilitzar aquesta eina. Aquest programa recorre els diferents codis que li indiquem, buscant aquells textos preparats per traduir. Un cop trobats genera un fitxer de traduccions seguint el format .ts. Aquesta acci´o s’ha de executar per cada idioma a traduir que vulguem per tant es posa el codi per generar els quatre fitxers de traducci´o que actualment tenim (codi 4.26). Els fitxers generats poden ser editats amb varis programes, i posteriorment es generar`a un nou fitxer amb extensi´o .qm. Codi Bash 4.26: Crear fitxers per traduccions pylupdate4 dcsmmainwindow .py main_dcsm .py -ts dcsmonitor_en . ts pylupdate4 dcsmmainwindow .py main_dcsm .py -ts dcsmonitor_es . ts pylupdate4 dcsmmainwindow .py main_dcsm .py -ts dcsmonitor_ca . ts 90 4.1 DCSMonitor pylupdate4 dcsmmainwindow .py main_dcsm .py -ts dcsmonitor_fr . ts 4.1.6.3 QtLing¨uist Gracies a aquest programa podem editar un a un els diferents fitxers generats anteriorment (secci´o 4.1.6.2), i un cop hem traduit totes les paraules li podem demanar que ens generi el fitxer de traduccions, que ´es capa¸c de carregar la llibreria PyQT4 com hem dit en la secci´o 4.1.6.1. En la figura seg¨uent (figura 4.12) es pot veure l’entorn d’edici´o d’un fitxer, en la part central les paraules marcades en verd ja traduides i la paraula seleccionada que apareix per traduir una mica m´es abaix. Figura 4.12: Utilitzant QtLing¨uist - Programa que ens permet editar un fitxer de traduccions .ts, i generar el fitxer .qm 4.1.6.4 Resultat Un cop realitzats tots els passos indicats en aqueta secci´o, tindrem els quatre fitxers de traducci´o seg¨uents: 91 4. IMPLEMENTACI ´ O DEL LABORATORI •dcsmonitor en.qm •dcsmonitor es.qm •dcsmonitor ca.qm •dcsmonitor fr.qm I ja podrem canviar l’idioma anant a les prefer`encies del programa (Figura 4.13) i seleccionant un dels idiomes llistats. Figura 4.13: Prefer`encies del programa DCSMonitor - Des de les prefer`encies podem seleccionar l’idioma Tot seguit es poden observar alguns dels canvis que s’efectuen al canviar l’idioma (Figura 4.14) 92 4.2 dsPIC (a) Labels en Catal`a (b) Labels en Espanyol (c) Labels en Angl´es (d) Labels en Franc´es Figura 4.14: Comparaci´o dels labels entre diferents idiomes. 4.2 dsPIC Aquesta secci´o pret´en explicar les parts del codi m´es importants dels microcontroladors dsPIC. Tot el sistema est`a basat en el RTOS Erika Enterprise, aix´ı que la majoria de les funcions s´on tasques que s´on activades, o es realitzen peri`odicament mitjan¸cant alarmes. Aquesta manera de programar permet la concurr`encia entre diferents tasques, el que comporta una major atenci´o als diferents tipus de accions que el microcontrolador ha de dur a terme. En els microcontroladors que utilitzem aquesta concurr`encia es en el mateix nucli, per tant tot s’executa en serie, per`o aquest sistema operatiu garanteix l’execuci´o de totes les tasques. Tot seguit es poden veure les diferents parts m´es importants d’aquests programes. 93 4. IMPLEMENTACI ´ O DEL LABORATORI 4.2.1 Tasques en Erika El RTOS Erika ens ofereix una serie d’eines per generar d’alguna manera tasques que s’executin peri`odicament. En el nostre laboratori ens aprofitem d’aquesta facilitat i moltes de les funcions que fem servir en els diferents dispositius estan realitzades d’aquesta manera. Per tal d’aconseguir aix`o primerament s’han de declarar les tasques que el nostre Sistema Operatiu podr`a executar. Per aix`o existeix un fitxer anomenat conf.oil en el qual hem d’avisar a RT-Druid de la creaci´o de les tasques que necessitem, a les quals se’ls pot assignar una prioritat diferent i temps m`axim d’atenci´o entre d’altres opcions. Tamb´e es necessari indicar-li quin dispositiu volem programar, amb quin programador, quins codis formaran part del SO, i altres q¨uestions que podem configurar. Tot seguit es posa a mode d’exemple el fitxer conf.oil necessari per programar un dispositiu que nom´es t´e la tasca de supervisi´o (aquesta tasca enviava informaci´o d’estat a l’ordinador via RS232). En el codi 4.27, es pot veure la declaraci´o del nostre sistema indicant-li el microcontrolador que usarem, els fitxers que formaran part del codi, i finalment la declaraci´o de la tasca TaskSupervision amb una prioritat de valor dos (valor m´es alt indica major prioritat), li donem tamb´e el m´axim de temps per ser executada i que volem que la administri completament el Sistema Operatiu. M´es abaix creem una alarma per poder executar aquesta tasca de manera peri`odica en cas de necessitar-ho. Codi C 4.27: Exemple de declaraci´o d’una tasca en el fitxer conf.oil 1CPU mySystem { 2 3OS myOs { 4EE_OPT = " DEBUG "; 5 6CPU_DATA = PIC30 { 7APP_SRC = " setup .c"; 8APP_SRC = " uart_dma .c"; 9APP_SRC = " e_can1 .c"; 10 APP_SRC = " code .c"; 11 MULTI_STACK = FALSE ; 94 4.2 dsPIC 12 ICD2 = TRUE; 13 }; 14 15 MCU_DATA = PIC30 { 16 MODEL = PIC33FJ256MC710 ; 17 }; 18 19 BOARD_DATA = EE_FLEX { 20 USELEDS = TRUE ; 21 }; 22 23 24 KERNEL_TYPE = EDF { NESTED_IRQ = TRUE ; TICK_TIME = " 25 ns ";}; 25 26 }; 27 28 TASK TaskSupervision { 29 REL_DEADLINE = "0.1 s"; 30 PRIORITY = 2; 31 STACK = SHARED ; 32 SCHEDULE = FULL ; 33 }; 34 35 COUNTER myCounter ; 36 37 ALARM AlarmSupervision { 38 COUNTER = " myCounter "; 39 ACTION = ACTIVATETASK { TASK = " TaskSupervision "; }; 40 }; 41 }; Un cop tenim ben definit l’entorn del nostre Sistema Operatiu ja nom´es cal utilitzar les tasques dintre del programa (codis d’exemple 4.28). Per poder posar en marxa una tasca RT-Druid ens dona la funci´o ActivateTask(nom de la tasca), amb la qual nom´es s’executar`a un cop. 95 4. IMPLEMENTACI ´ O DEL LABORATORI En el cas de voler activat aquesta tasca peri´odicament podem activar una alarma amb la funci´o SetRelAlarm(AlarmType AlarmID, TickType increment, TickType cycle) en la qual li indiquem el nom de l’alarma a executar, el temps d’espera per executar-la i el temps entre cicles d’execuci´o. Finalment si en algun moment volguessin aturar aquesta alarma c´ıclica nom´es haur´ıem de cridar la funci´o CancelAlarm(AlarmType AlarmID). Codi C 4.28: Codis per interactuar amb tasques 1// Active one execution of a task 2ActivateTask ( TaskSupervision ); 3 4// Data is sent to the PC every 10 ms 5SetRelAlarm ( AlarmSupervision , 1000 , 10) ; 6 7// Stops the periodiciti of a task 8CancelAlarm ( AlarmSupervision ); 4.2.2 Comunicaci´o serie RS232 En aquest apartat explicarem com s’ha implementat la comunicaci´o serie per RS232 que es va dissenyar en la secci´o 3.2.3. Recordem que els dos dispositius capa¸cos d’interaccionar mitjan¸cant aquesta tecnologia s´on el Monitor i el Sensor/Actuador , per tant s’explicaran els codis d’aquests relacionats amb la comunicaci´o serie. 4.2.2.1 Recepci´o de senyals de control Com hem explicat en la secci´o anterior 3.2.3, el dispositiu Monitor ha de ser capa¸c de rebre diferents instruccions del programa DCSMonitor per tal de poder posar en marxa certes accions. Aquestes instruccions estan numerades i les dues parts de la comunicaci´o han de coneixer-la, per tant primer de tot en el codi del Monitor cal declarar aquests valors: Codi C 4.29: Declaraci´o dels valors dels senyals de control 1#define SIGNAL_STOP 1 2#define SIGNAL_MONITOR 0 3#define SIGNAL_PERCENT 2 4#define SIGNAL_DEVICES 4 96 4.2 dsPIC Per tal de rebre els missatges per el port s`erie RS232 es va observar el mode de funcionament de la recepci´o dels missatges CAN i es va utilitzar la mateixa metodologia, creant una funci´o que s’execut´es cada cop que el port s`erie s’ompl´ıs amb 8 bytes. Aquesta funci´o seria la encarregada de comprovar el primer dels 8 bytes del missatge, i realitza una o altre acci´o depenent de la taula que s’ha mostrat anteriorment 3.1. Tot seguit es pot veure la funci´o que rep la interrupci´o del buffer d’entrada del port s`erie: Codi C 4.30: Interrupci´o buffer del port s`erie 1// Input serial buffer interrupt 2ISR2(_DMA5Interrupt) // NOTE : Disabled when IEC3bits . DMA5IE = 0; 3{ 4float * p_k0 =( float *)& InBufferA [0]; 5unsigned long id_link; 6 7/* Code to update received data */ 8k_updated [0]= *( p_k0); 9k_updated [1]= *( p_k0 +1); 10 11 switch ( InBufferA [0]) 12 { 13 case SIGNAL_MONITOR: 14 15 id_link = (unsigned long ) InBufferA [7] < <2; 16 // Generating id ’s for a control plant 17 ID_TO_ACTUATOR = CONTROL_MESSAGE | GENERAL_PRIORITY | id_link ; 18 ID_FROM_SENSOR = GRANTED_SENSOR_MESSAGE | GENERAL_PRIORITY | id_link ; 19 ID_REFERENCE = GENERAL_PURPOSE_MESSAGE | GENERAL_PRIORITY | id_link | REFERENCE_MESSAGE; 20 ID_SUPERVISOR = GENERAL_PURPOSE_MESSAGE | GENERAL_PRIORITY | id_link | SUPERVISOR_MESSAGE ; 21 97 4. IMPLEMENTACI ´ O DEL LABORATORI D’aquesta manera el dispositiu Actuador estar`a interessat nom´es en els missatges de control, per tant aquest dispositiu filtrar`a aquest tipus de missatges a un buffer en concret, el qual al estar ple activar`a una interrupci´o. El mateix passar`a amb els altres dispositius, per tant hem definit dins del codi els diferents elements que formen l’identificador, per crear els filtres m´es f`acilment. Codi C 4.34: Definicions per la creaci´o de filtres CAN 1// DEFINITIONS TO CREATE CAN ID’S 2// id CAN : 0b 000 c ccpp pppp pppp pppp ppii iiii iiss 3// ccc = CLASS 4// pppp pppp pppp pppp = PRIORITY 5// iiii iiii = ID_PLANT 6// ss = SUBCLASS 7 8// MESSAGE SUBCLASS 9#define REFERENCE_MESSAGE (0) 10 #define SUPERVISOR_MESSAGE (1) 11 12 // MESSAGE ID 13 #define ID_PLANT (1 < <2) 14 15 // MESSAGE PRIORITY 16 #define GENERAL_PRIORITY (0 xFFFF < <10) 17 18 // MESSAGE CLASS 19 #define CONTROL_MESSAGE (( unsigned long ) 0 < <26) 20 #define GRANTED_SENSOR_MESSAGE (( unsigned long ) 1 < <26) 21 #define GENERAL_PURPOSE_MESSAGE ((unsigned long ) 2 < <26) 22 #define BEST_EFFORT_SENSOR_MESSAGE ((unsigned long ) 3 < <26) 23 24 unsigned long ID_TO_ACTUATOR = CONTROL_MESSAGE | GENERAL_PRIORITY | ID_PLANT ; 25 unsigned long ID_FROM_SENSOR = GRANTED_SENSOR_MESSAGE | GENERAL_PRIORITY | ID_PLANT ; 26 unsigned long ID_REFERENCE = GENERAL_PURPOSE_MESSAGE 104 4.2 dsPIC | GENERAL_PRIORITY | ID_PLANT | REFERENCE_MESSAGE; 27 unsigned long ID_SUPERVISOR = GENERAL_PURPOSE_MESSAGE | GENERAL_PRIORITY | ID_PLANT | SUPERVISOR_MESSAGE ; 4.2.3.3 Recepci´o de missatges CAN Un cop creades les diferents m`ascares i filtres dels missatges CAN, ´es hora de crear una funci´o que capturi les interrupcions generades per el bus CAN. La implementaci´o CAN amb la que comptem ens permet definir fins a 16 filtres diferents, i assignar-los a 16 buffers. Aquests buffers posen a 1 un bit en el moment en que est`an plens, per tant aprofitem aquest comportament per definir cadascun dels diferents missatges a un sol filtre i un sol buffer, d’aquesta manera en el moment que un dels buffers estigui ple, sabrem quin tipus de missatge ´es sense haver de mirar l’identificador. Pero existeix una excepci´o; en el cas de llistar tots els dispositius que existeixen al bus CAN. En aquest cas existeixen 229 missatges diferents, i per tant hem de reunir-los d’alguna manera. Aix´ı doncs, tenint en compte que aquesta captura no ´es cr´ıtica pel control de cap lla¸c, crearem un filtre sense restriccions cap a un buffer. En el moment en que aquest buffer estigui pl´e, comprovarem l’identificador i el guardarem en una pila (m´es endevant explicarem m´es detalladament aquest funcionament). En la taula 4.2 es pot veure els diferents filtres que s’han de crear, i a quin buffer estan assignats. De totes maneres, la activaci´o o desactivaci´o o canvi d’aquests filtres es pot realitzar en temps d’execuci´o, pel que fa que per exemple el Monitor els activi i desactivi a conveni`encia, mentre que els dispositius Controlador iSensor/Actuador no els cal modificar. Num Id Extended Buffer mascara 0 ID FROM SENSOR s´ı 1 0x1C0003FF 1 ID TO ACTUATOR s´ı 2 0x1C0003FF 2 ID REFERENCE s´ı 3 0x1C0003FF 3 ID SUPERVISOR s´ı 4 0x1C0003FF 4 indiferent s´ı 5 0x00000000 Taula 4.2: Configuraci´o dels filtres Tenint clar a quin buffer es redireccionar`a cada missatge CAN, s’ha implementat la funci´o d’atenci´o a aquestes interrupcions tenint en compte el buffer activat; com es pot veure en el codi de la funci´o 4.35. 105 4. IMPLEMENTACI ´ O DEL LABORATORI Codi C 4.35: Funcio activada per una interrupci´o del bus CAN 1/* CAN bus 1 Interrupt , ISR2 type */ 2ISR2(_C1Interrupt) 3{ 4IFS2bits . C1IF = 0; // clear interrupt flag 5 6// Transmission interrupt (nothing to be done but clear flag) 7if( C1INTFbits . TBIF ) 8{ 9C1INTFbits . TBIF = 0; 10 } 11 12 /* Reception interrupt , different code for different filtered id ’s */ 13 if( C1INTFbits . RBIF ) 14 { 15 LATBbits . LATB14 ^= 1; //Toggle orange led 16 /* Filter 0( ID_FROM_SENSOR ): 17 * Sensor to controller message */ 18 if( C1RXFUL1bits . RXFUL1 ==1) 19 { 20 /* Tells rxECAN1 the buffer to pass from DMA to RAM */ 21 rx_ecan1message1 . buffer =1; 22 23 C1RXFUL1bits . RXFUL1 =0; 24 rxECAN1 (& rx_ecan1message1 ); 25 C1INTFbits . RBIF = 0; 26 27 /* Custom code to address Sensor message */ 28 ActivateTask ( TaskControllerMonitor ); 29 } 30 31 /* Filter 1( ID_TO_ACTUATOR ): 32 * Controller to Actuator message */ 106 4.2 dsPIC 33 if( C1RXFUL1bits . RXFUL2 ==1) 34 { 35 /* Tells rxECAN1 the buffer to pass from DMA to RAM */ 36 rx_ecan1message2 . buffer =2; 37 38 C1RXFUL1bits . RXFUL2 =0; 39 rxECAN1 (& rx_ecan1message2 ); 40 C1INTFbits . RBIF = 0; 41 42 /* Custom code to capture values from controller */ 43 ActivateTask ( TaskActuatorMonitor ); 44 } 45 46 /* Filter 2( ID_REFERENCE ): 47 * Controller updated reference ( supervision ) */ 48 if( C1RXFUL1bits . RXFUL3 ==1) 49 { 50 /* Tells rxECAN1 the buffer to pass from DMA to RAM */ 51 rx_ecan1message3 . buffer =3; 52 53 C1RXFUL1bits . RXFUL3 =0; 54 rxECAN1 (& rx_ecan1message3 ); 55 C1INTFbits . RBIF = 0; 56 57 /* Custom code to address the Controller message 58 * which updates the reference change */ 59 r=*( float *) (& rx_ecan1message3 .data [0]) ; 60 } 61 62 // Filter 3( ID_SUPERVISOR ): ID_SUPERVISOR 63 if( C1RXFUL1bits . RXFUL4 ==1) 64 { 65 /* Tells rxECAN1 the buffer to pass from DMA to RAM */ 107 4. IMPLEMENTACI ´ O DEL LABORATORI 66 rx_ecan1message4 . buffer =4; 67 68 C1RXFUL1bits . RXFUL4 =0; 69 rxECAN1 (& rx_ecan1message4 ); 70 C1INTFbits . RBIF = 0; 71 72 /* Custom code to address Sensor message */ 73 ActivateTask ( TaskSensor_supervision ); 74 } 75 76 // Filter 4( ALL ): all messages 77 if( C1RXFUL1bits . RXFUL5 ==1) 78 { 79 /* Tells rxECAN1 the buffer to pass from DMA to RAM */ 80 rx_ecan1message5 . buffer =5; 81 82 C1RXFUL1bits . RXFUL5 =0; 83 rxECAN1 (& rx_ecan1message5 ); 84 C1INTFbits . RBIF = 0; 85 86 char id_link = (char)( rx_ecan1message5 .id > >2) & 0 xFF ; 87 88 /* Custom code to add an id to a list */ 89 if (! search_device ( id_link )) 90 add_device ( id_link ); 91 } 92 } 93 } 4.2.3.4 Pila de lla¸cos de control Quan el Monitor necessita llistar els diferents lla¸cos de control del bus CAN primer ha de capturar aquests identificadors per m´es tard enviar-li peri`odicament al programa DCSMonitor . Per dur a terme aquesta tasca de manera modular s’ha creat un tipus 108 4.2 dsPIC d’estructura que anomenarem pila (codi 4.36 ). Aquesta pila ´es est`atica i t´e una mida de 30 identificadors, per`o per poder modificar tot aix`o sense haver de reimplementar el codi del Monitor s’han creat funcions tot un seguit de funcions b`asiques per tractar amb els valors continguts en ella. Codi C 4.36: Pila d’identificadors 1#define STACK_SIZE 30 2 3struct stack { 4unsigned char ids [ STACK_SIZE ]; 5int num ; 6int max ; 7} stack_ids ; Tot seguit es posen els codis de tractament de la pila: •Inicialitzar 4.37 •Comprovar si ´es plena 4.38 •Buscar identificador 4.39 •Afegir identificador 4.40 •Treure identificador 4.41 Codi C 4.37: Inicialitzar pila 1void init_devices_list() 2{ 3stack_ids . num = 0; 4stack_ids . max = STACK_SIZE ; 5} Codi C 4.38: Comprovar si la pila ´es plena 1int stack_full () 2{ 3return ( stack_ids . num == stack_ids .max ); 109 4. IMPLEMENTACI ´ O DEL LABORATORI 4} Codi C 4.39: Buscar a la pila 1int search_device ( unsigned char id) 2{ 3int i; 4for (i = 0; i < stack_ids . num; i++) 5if ( stack_ids . ids [i] == id) return 1; 6return 0; 7} Codi C 4.40: Afegir a la pila 1int add_device ( unsigned char id) 2{ 3if ( stack_ids . num == stack_ids . max ) return 0; 4stack_ids . ids [ stack_ids .num ] = id; 5stack_ids . num ++; 6return 1; 7} Codi C 4.41: Treure de la pila 1int get_device ( unsigned char * id) 2{ 3if ( stack_ids . num == 0) return 0; 4*id = stack_ids . ids [ stack_ids .num -1]; 5stack_ids .num - -; 6return 1; 7} 4.2.3.5 Tractant missatges de control per l’Actuador Aquests missatges com s’ha explicat en la secci´o 3.2.2.1, porten amb ells el valor a aplicar a l’entrada del doble integrador. Les dades del missatge s´on emmagatzemades 110 4.2 dsPIC en el buffer 2, per tant primer de tot es comprova que sigui un missatge d’aquest tipus (codi 4.42). Aquest codi desactiva els flags del buffer que s’han activat al omplir-se, i crida a una tasca. Codi C 4.42: Captura del missatge de control per l’Actuador 1/* Filter 1( ID_TO_ACTUATOR ): 2* Controller to Actuator message */ 3if( C1RXFUL1bits . RXFUL2 ==1) 4{ 5/* Tells rxECAN1 the buffer to pass from DMA to RAM */ 6rx_ecan1message2 . buffer =2; 7 8C1RXFUL1bits . RXFUL2 =0; 9rxECAN1 (& rx_ecan1message2 ); 10 C1INTFbits . RBIF = 0; 11 12 /* Custom code to capture values from controller */ 13 ActivateTask ( TaskActuatorMonitor ); 14 } En el cas del Monitor nom´es necessita aquesta informaci´o per poder enviar-la al programa DCSMonitor perqu`e pugui generar les gr`afiques correctament, per tant la tasca que activa nom´es guarda aquests valors per posteriorment ser enviats (codi 4.43) per RS232. Codi C 4.43: Tasca per capturar el valor de l’actuador 1/* ActuatorMonitor Task */ 2static float * p_u = ( float *)& rx_ecan1message2 . data [0]; 3static unsigned long sys_time =0; 4 5TASK(TaskActuatorMonitor) 6{ 7// sys_time = GetTime (); // Get system time (EDF Scheduler ) 8u=(* p_u); 111 4. IMPLEMENTACI ´ O DEL LABORATORI 9x0 =*( p_x0 );// Get state x [0] from rx_ecan1_message1 [0]..[3] data field 10 x1 =*( p_x1 );// Get state x [1] from rx_ecan1_message1 [4]..[7] data field 11 } En canvi en el cas de l’Actuador aquest valor l’ha d’introduir al PWM destinat a l’entrada del doble integrador (codi 4.44) Codi C 4.44: Tasca per aplicar el valor al PWM 1/* Actuator Task */ 2static float * p_u = ( float *)& rx_ecan1message2 . data [0]; 3 4TASK(TaskActuator) 5{ 6u=(* p_u); 7 8PDC1 =((*( p_u ))/ v_max ) *0 x7fff +0 x3FFF ; 9} 4.2.3.6 Tractant missatges d’estat del Sensor per al Controlador Els missatges d’estat contenen els valors de sortida de la primera i segona integral (capitol 3.2.2.2). Com hem vist anteriorment (taula 4.2) aquests missatges estan dirigits al buffer 1, per tant al activar-se la interrupci´o i comprovar que aquest buffer est`a ple activarem la tasca Controller en el cas del dispositiu Controlador , i la tasca ControllerMonitor en el cas del Monitor . Aqu´ı es pot veure el codi que detecta aquest missatge i activa la tasca del Monitor (codi 4.45): Codi C 4.45: Captura del missatge d’estat del Sensor al Controlador 1/* Filter 0( ID_FROM_SENSOR ): 2* Sensor to controller message */ 3if( C1RXFUL1bits . RXFUL1 ==1) 4{ 5/* Tells rxECAN1 the buffer to pass from DMA to RAM */ 112 4.2 dsPIC 6rx_ecan1message1 . buffer =1; 7 8C1RXFUL1bits . RXFUL1 =0; 9rxECAN1 (& rx_ecan1message1 ); 10 C1INTFbits . RBIF = 0; 11 12 /* Custom code to address Sensor message */ 13 ActivateTask ( TaskControllerMonitor ); 14 } Per tant, el dispositiu Monitor nom´es captura els valors de l’estat del doble integrador (codi 4.46). Codi C 4.46: Tasca per capturar el valor d’estat del control 1static float * p_x0 = ( float *)& rx_ecan1message1 . data [0]; 2static float * p_x1 = ( float *)& rx_ecan1message1 . data [4]; 3static float x0 =0; 4static float x1 =0; 5TASK(TaskControllerMonitor) 6{ 7x0 =*( p_x0 );// Get state x[0] from rx_ecan1_message1 [0]..[3] data field 8x1 =*( p_x1 );// Get state x[1] from rx_ecan1_message1 [4]..[7] data field 9x[0] = x0; 10 x[1] = x1; 11 } Mentre que el dispositiu Controlador utilitza aquests valors per fer els calculs del control (codi 4.47); puntualitzem que en aquest cas el control no ´es bo. Un cop ha determinat el valor d’entrada per el doble integrador, activa una funci´o per enviar aquest valor en un missatge CAN (funci´o 4.48). Codi C 4.47: Tasca per fer els calculs del control 1static float Nu =0.0; 2static float Nx [2] ={1.0 ,0.0}; 113 4. IMPLEMENTACI ´ O DEL LABORATORI Ara nom´es queda fer els c`alculs del temps que hem dedicat a tot, i realitzar un an`alisi econ`omic del conjunt, tot aix`o en el seg¨uent cap´ıtol. 120 5 An`alisi econ`omic En aquest cap´ıtol mostrem un desglos del preu que ha comportat aquest projecte, separant la part de materials necessaris per l’execuci´o dels experiments de laboratori, i la part d’hores dedicades a cada una de les fases del projecte segons el tipus de personal necessari per dur la feina. 5.1 Material Tot el material necessari per dur a terme el projecte, es b`asicament el material que es necessita per elaborar un laboratori de Sistemes Distribu¨ıts de Control com el que hem realitzat, en el que existeixen dos grups de laboratori i un professor. Cada un d’els grups de laboratori necessita per tant dues plaques FLEX per la elaboraci´o del control, i el professor en necessita una que faci de Monitor . Com realment no existeixen alumnes no necessit`avem dos ordinadors per els grups ja que amb un ordinador connectat al dispositiu Monitor ja pod´ıem realitzar totes les lectures. Tamb´e era necessari un programador per poder programar els diferents dispositius, els alimentadors (que fent ponts entre les plaques nom´es ens han calgut un parell), un convertidor de RS232 a USB ja que l’ordinador port`atil no comptava amb aquest port, i el material d’oficina que hem anat necessitant per prendre apunts, imprimir material did`actic, o realitzar els Live CD necessaris. A continuaci´o es pot veure desglossat el preu de tot el material mencionat (taula 5.1). 121 5. AN` ALISI ECON` OMIC Material descripci´o preu un. unitats preu Placa FLEX Placa de prototipat de la casa FLEX 119 5 595 Modul CAN Circuit amb transceptor CAN 8 5 40 Modul RS232 Circuit amb codificador RS232 9 1 9 ICD3 Programador Mplab de la casa Microchip 148 1,00 148 Ordinador portatil Portatil estandart 399 1 399 Alimentadors Alimentador 9VDC 500mA 12 2 24 Convertidor RS232 Convertidor de estandart RS232 a USB 9 1 9 Cables varis (cables per bus CAN, cables alimentaci´o...) 35 1 35 Material oficina (impresions, dvd’s, cd’s, fulls...) 50 1 50 TOTAL 1309 Taula 5.1: Desglos del preu de tot el material empleat 5.2 Ma d’obra Aquest es un dels aspectes m´es importants a l’hora de fer el calcul de preus del projecte, ja que en aquest cas s’emporta el 90% del pressupost total del projecte. Rol Preu Enginyer de Software 30 Enginyer Industrial 25 Director de Projecte 60 Becari 15 Taula 5.2: Preu de cada rol en Euros/hora Per fer aquest calcul s’ha estimat el preu de la ma d’obra de diferents rols que s’han tocat durant el projecte, per exemple l’Enginyer de Software que ha realitzat tots els codis relacionats amb interf´ıcies, programes, disseny d’aquests, etc. L’enginyer Industrial que s’ha encarregat dels diferents protocols de comunicaci´o, les connexions el`ectriques i el disseny del laboratori f´ısic. El director de projecte, que ha planificat els temps d’entrega, els canvis del diagrama de Gantt, i ha fet les reunions peri`odiques per controlar el bon funcionament de tot. I el becari que ha fet les proves dels sistemes, documentat l’us del laboratori i de part del Live CD . 122 5.2 Ma d’obra Per tant es posa una taula amb els preus de cada un dels diferents rols (taula 5.2), i tot seguit un desglos dels dies dedicats a cada una de les tasques, el seu equivalent en hores, el percentatge d’elaboraci´o d’aquestes feines per rol, i finalment el preu resultant de fer els calculs (taula 5.3). Tota la feina indicada en aquesta taula es pot contrastar en el diagrama de Gantt mostrat en el primer capitol (Introducci´o, 1) en l’apartat de planificaci´o (secci´o 1.4). Feina E.S. E.I. P.M. Bec. dies hores Euros Estudi General 50 50 0 0 7,00 24,50 673,75 Planificar Projecte 25 25 50 0 1,00 3,50 153,12 Laboratori Actual 35 60 0 10 19,00 66,50 1.795,50 Preparar codis lliures 70 30 0 0 12,40 43,40 1.236,90 Ampliaci´o del laboratori 50 50 0 0 53,40 186,90 5.139,75 Preparar Live CD 80 0 0 20 14,00 49,00 1.323,00 Realitzar Guies 80 0 0 20 9,40 32,90 888,30 Preparar Informe Previ 50 45 5 0 7,00 24,50 716,62 Preparar Mem´oria 49 49 2 0 15,00 52,50 1.477,88 Preparar Defensa 50 40 5 0 7,00 24,50 686,00 Reuninons peri´odiques 25 25 50 0 9,00 31,50 1.378,12 TOTAL 154,20 539,70 14.090,83 Taula 5.3: Desglos del preu de la ma d’obra, amb el percentatge de dedicaci´o per rol Tot seguit es pot observar una gr`afica de past´ıs (figura 5.1) que s’ha creat per veure visualment com s’ha distribu¨ıt la inversi´o de capital en la ma d’obra segons la feina que s’ha realitzat. Com era d’esperar una gran part del preu del projecte recau sobre l’elaboraci´o de l’ampliaci´o del nou laboratori, i la preparaci´o anterior amb el laboratori actual, que ens va servir per entendre els Sistemes Distribu¨ıts de Control. Tamb´e ´es important veure quin es el percentatge d’hores que li ha dedicat cada rol al projecte, i amb la taula 5.4 podem veure que l’Enginyer de Software i l’Enginyer Industrial s´on els que m´es hores han dedicat al projecte, donant una expectativa positiva envers el resultat del projecte. 123 5. AN` ALISI ECON` OMIC Estudi General Planificar Projecte Laboratori Actual Preparar codis lliures Realitzar ampliació del laboratori Preparar Live CD Realitzar Guies Preparar Informe Previ Preparar Memória Preparar Defensa Reuninons periódiques Figura 5.1: Distribuci´o del preu segons la feina - E.S. E.I. D.P. Bec. Figura 5.2: Percentatge d’hores dedicades al projecte per rol - 124 5.2 Ma d’obra Rol hores percentatge Enginyer de Software 283,85 53% Enginyer Industrial 213,92 40% Director de Projecte 21,00 4% Becari 23,03 4% Taula 5.4: Hores dedicades al projecte per rol, i els seus percentatges 125 5. AN` ALISI ECON` OMIC 126 6 Conclusions Amb aquest projecte hem pogut aproximar-nos als Sistemes Distribu¨ıts de Control, i veure els problemes que aquests sistemes arrosseguen. Al principi podia ser una mica desconcertant, per`o un cop ens hi endinsem les coses comencen a agafar un cert sentit i es comencen a veure d’una altre manera. En el projecte finalment hem pogut complir tots els requisits plantejats des de bon principi. Hem pogut agafar i entendre tot el codi del laboratori actual (secci´o 3.1), per d’aquesta manera crear tot l’entorn de codi lliure, el receptor dels missatges que existia anteriorment era un programa per Matlab, el qual necessitava una llicencia per ser executat, aix´ı que amb la creaci´o del nou programa DCSMonitor hem pogut resoldre aquest problema, ja que ara no es necessari comptar amb aquesta llicencia (secci´o 4.1). Hem dissenyat l’entorn de laboratori d’un Sistema Distribu¨ıt de Control real, en el qual tots els dispositius comparteixen realment el mateix bus CAN, i d’aquesta manera els alumnes poden aprendre en un entorn conflictiu real (3.2). Per dissenyar aquest laboratori hem hagut d’organitzar els diferents identificadors que hi ha permesos al protocol CAN, de manera que existeixi una jerarquia de prioritats entre els missatges CAN, que una part pugui identificar l’identificador del lla¸c de control, i una altra quin tipus de missatge ´es (secci´o 3.2.2). Tot aix`o s’ha dissenyat seguint aquests requisits, i finalment els identificadors tenen una estructura totalment ben definida. Aquest nou laboratori ha comportat la creaci´o d’un nou programa per ordinador; el qual hem anomenat DCSMonitor ; i que hem dissenyat per complir tots els objectius 127 6. CONCLUSIONS que es van plantejar. D’aquesta manera hem estudiat i creat tot el codi necessari perqu`e aquest programa fos capa¸c de comunicar-se a traves del port serie via RS232 a una placa FLEX (secci´o 4.1.2) per tal de: demanar un llistat de tots els lla¸cos de control existents al bus CAN (secci´o 4.1.2.2), demanar-li que carregu´es el bus de manera que els lla¸cos de control es veiessin amb problemes reals (secci´o 4.1.2.4), demanar-li totes les dades de l’estat d’un lla¸c de control i d’aquesta manera poder avaluar la bondat del control de cada grup del laboratori (secci´o 4.1.2.3). I tot aix`o mantenint la compatibilitat del laboratori antic, creant dos modes d’execuci´o, un en el que es totalment compatible amb les plaques FLEX de l’antic laboratori i on cada alumne pot avaluar el seu control, i un mode d’execuci´o en el que interv´e un dispositiu nou que anomenem Monitor , amb el que es poden fer totes les accions anteriorment comentades. Una peculiaritat de la comunicaci´o serie que s’ha dissenyat es que s’ha realitzat de manera que pugui ser f`acilment ampliable i reutilitzable per tal d’afegir m´es opcions per al Monitor o per el programa DCSMonitor . Amb les dades rebudes d’un lla¸c de control connectat al programa, o monitoritzat per un dispositiu Monitor , hem fet que el programa DCSMonitor sigui capa¸c de generar unes gr`afiques en temps real amb els valors del control de: refer`encia, valor d’entrada del doble integrador i valors de la primera i segona integral. A m´es aquests plots poden ser trets de la gr`afica individualment (secci´o 4.1.3). Les gr`afiques en temps real tamb´e poden ser exportades a diferents tipus d’imatge, entre d’elles imatges vectorials, molt interessants per afegir en documents o articles (secci´o 4.1.4). Un atre dels requisits del projecte era que el programa fos multiling¨ue, i ho hem complert creant l’entorn disponible en catal`a, castell`a, angl`es i franc`es (secci´o 4.1.6). A m´es hem utilitzat una metodologia de programaci´o modular que ens permet f`acilment afegir tots els idiomes que vulguem. A part del programa d’ordinador DCSMonitor , tamb´e calia crear un dispositiu que pogu´es monitoritzar els lla¸cos de control que es trobessin al bus CAN (dispositiu que hem anomenat Monitor ). Per tal s’ha dissenyat el sistema de recepci´o de missatges per RS232 del programa DCSMonitor , activant interrupcions i comprovant quin tipus de acci´o es volia portar a terme, i posant en marxa diferents tasques dependents d’aix`o (secci´o 4.2.2.1). 128 Els dispositius que ja existien en el laboratori actual s’han mantingut totalment compatibles, i s’els ha afegit el necessari per poder compartir el bus CAN sense conflictes, creant l’estructura d’identificadors de manera modular, i havent de incloure ´unicament el numero de grup al que pertanyen (veure codi 4.34). Sobre les guies, s’ha preparat una guia de laboratori per posar l’entorn de laboratori necessari per poder executar les diferents pr`actiques que des de la universitat s’imparteixen (ap`endix A). Tamb´e s’ha creat un Live CD amb un Linux Ubuntu , amb tot el codi necessari preparat per ser arrencat i provat (el pes de tot el sistema amb Eclipse i MPLAB R  X inclosos han fet que el pes total del sistema sigui de 1,4GB el que ha comportat que el Live CD s’hagi de gravar en un DVD o en un llapis de mem`oria). Gracies a aquest DVD nom´es logejar-nos podem programar el lla¸c de control, i comen¸car a fer les lectures. I la guia d’aquest CD que ens explica pas a pas com poder fer una instal·laci´o de l’entorn en un ordinador o en una m`aquina virtual, i despr´es com utilitzar-lo tant en l’entorn instal·lat com des de el Live CD (ap`endix B). Per tant un cop finalitzat han estat complerts tots els requisits proposats en un principi, quedant const`ancia de manera desglossada al llarg de tota la mem`oria. Cal destacar que l’entrega d’aquest projecte no tanca aquest laboratori, ja que el disseny que s’ha realitzat durant el projecte ha estat encaminat cap al doble integrador, per`o s’ha programat l’entorn, i s’han pensat tots els identificadors i missatges de manera que pugui ser ampliat per atendre altre tipus de controls, realitzar diferents accions des de l’ordinador, deixant espai suficient perqu`e la comunicaci´o entre el programa DCSMonitor i el dispositiu Monitor tinguin una gran varietat de senyals diferents i es pugui modificar el laboratori de varies maneres. 6.0.1 Treball futur En el transcurs del projecte han anat apareixen diverses funcions que podien ampliar el projecte per`o quedaven fora de l’abast d’aquest, aix´ı que posteriorment a l’entrega d’aquest projecte encara es poden realitzar aquestes ampliacions i/o millores: 1. Ampliar el nombre d’idiomes en el que est`a tradu¨ıt el programa per l’ordinador. 2. Traduir les guies a altres idiomes. 129