P ROGRAMARI DE MONITORITZACIÓ I CONTROL Introducció

Un dels grans esforços realitzats en aquest treball ha estat el disseny i escriptura d’un programari específic per a la monitorització i control del bioprocés. La principal funció d’aquest és enregistrar el seguiment temporal de les diferents variables del procés, així com a partir d’aquestes controlar el procés segons les directrius marcades per l’usuari.

Es va decidir, des d’un bon principi, realitzar l’adquisició de dades de les diferents variables mitjançant l’ordinador, aprofitant la potència que oferia en rapidesa i versatilitat. Tots els equips amb els quals s’havia de connectar ja disposaven d’una sortida digital, simplificant així l’esforç a realitzar ja que no calia emprar cap tipus de conversor analògic/digital.

Una segona decisió important era escollir quin tipus de plataforma es feia servir per realitzar el programari que gestionés la fermentació. En primer lloc, calia escollir entre la utilització d’un programari comercial o pel contrari escriure el programa des del seu inici amb un llenguatge de programació determinat.

Fent un anàlisi de les diferents possibilitats que oferia el mercat es va veure que la millor opció pel que fa a plataformes comercials, que estalviessin gran part

de l’esforç de programació, era LabView® _{(National Instuments corporation,}

Austin,USA). El principal avantatge d’aquest programa era la facilitat amb què es podia configurar un entorn gràfic per monitoritzar la fermentació. No obstant això, tot i la flexibilitat que oferia aquest programari es va creure que en algun moment no es podria fer el que es desitgés per la manca d’eines subministrades pel paquet comercial. Per exemple, el control sobre la comunicació amb els ports de l’ordinador, que per alguns dels equips no és estàndard.

Així doncs, es va optar per realitzar el programa des de l’inici emprant un llenguatge de programació que permetés més llibertat a l’hora de realitzar les tasques més o menys complexes, tot i ser l’opció més laboriosa. Prèviament es tenia experiència amb el llenguatge C per programar sobre MS-DOS (Microsoft, USA), però es va creure necessari utilitzar-ne un capaç de fer-ho en entorn gràfic, més modern i fàcil d’utilitzar per l’usuari final.

Un cop es tenia clar quin era el perfil de programari que es desitjava calia escollir el llenguatge amb el que s’havia de fer. L’experiència prèvia que es tenia amb el llenguatge C, orientava la solució per utilitzar la programació en entorn gràfic del mateix llenguatge, el Visual C+. Però, durant el primer contacte amb aquest es va veure que tot i tenir alguna similitud amb el seu antecessor (llenguatge C), l’esforç d’aprenentatge que s’havia de realitzar era el mateix que començar de nou amb qualsevol d’altre de característiques similars.

En aquest moment, es van avaluar les principals característiques de les diferents opcions de llenguatges de programació. Ràpidament va sorgir amb força

la possibilitat de realitzar el programari en Visual Basic®_{, que combinava potència,}

flexibilitat i senzillesa de programació. Altres llenguatges com el Visual C+ permetien un millor control del flux del programa però, en conseqüència, un elevat augment en la complicació de la programació.

Finalment, i basant la decisió en gran part per reduir al màxim el període d’aprenentatge necessari per realitzar una aplicació de les característiques que es

RESULTATS I DISCUSSIÓ

utilitzar l’entorn de Microsoft Visual Basic 6.0® _{amb el qual es podien crear}

programes en entorn Windows® _{de 16 o 32 bits sense la necessitat de conèixer el}

funcionament de baix nivell d’interacció entre l’aplicació i el sistema operatiu. Esquema general

La primera tasca a realitzar va ser dissenyar físicament l’esquema de muntatge. Atès el nombre d’equips perifèrics amb què s’havia d’establir comunicació, es va decidir separar físicament les tasques a realitzar en dos ordinadors. Un primer, que es va anomenar PC1, dedicat exclusivament a la comunicació amb tots els equips (Figura 4.41), amb l’única funció de recopilar totes les dades i posteriorment enviar-les, via TCP/IP, a un segon ordinador, de nom PC2, on s’havia de realitzar la resta de tasques de monitorització i control. Per tant, per cadascun dels ordinadors es va de dissenyar un programari específic per les funcions per les que s’havia destinat.

Les especificacions tècniques del material informàtic necessari per portar a terme aquesta tasca estan detallades al apartat 3.1.

FERMENTADOR B.BRAUN BIOSTAT ED RS-485 RS-232 RS-422 RS-232 TCP/IP RS-232 RS-232 ANALITZADOR DE GASOS O2 CO2 PTI INSTRUMENTS Methanol sensor ON OFF SENSOR DE METANOL MC-168 CONTROLADOR DE PRESSIÓ 25 % 10 % MI C R O B UR ET A AUTOMÀTICA 1 MICROBURETA AUTOMÀTICA 2 PC 1 (COMUNICACIONS) PC 2 (MONITORITZACIÓ I CONTROL) RS-232 MI CR OB U R E T A AUTOMÀTICA 3

Figura 4.41. Esquema de les connexions entre els ordinadors i la resta d’equipament per

portar a terme la monitorització i control del bioprocés.

Si es mostra aquest esquema segons la posició jeràrquica que ocupa cadascun dels elements (Figura 4.42), es pot apreciar quines són les funcions de cadascun dels programaris.

El programari de monitorització i control situat a la part superior de l’estructura jeràrquica, reuneix tota la informació provinent tant de l’adquisició en línia com de l’anàlisi externa de les variables no monitoritzades. Les fletxes de connexió entre els diferents blocs indiquen la direcció de transferència.

A partir del processament d’aquestes dades, i segons les directrius marcades per l’usuari, s’actua sobre les consignes d’algunes de les variables i sobre el cabal d’alimentació de substrats.

Programari de Monitorització i control

Programari de Comunicacions Equip d’anàlisi de gasos Equip de mesura i control de pressió Fermentador Microburetes d’addició Sistema autòmatic de presa de mostres Equip de mesura de metanol Procés de Fermentació Anàlisis de mostres “off-line” “ON_LINE” “OFF-LINE”

Figura 4.42. Esquema jeràrquic del programari de monitorització i control.

Criteris de programació

La programació de sistemes d’aquest tipus no és senzilla, per tant és important des d’un bon inici seguir les mateixes pautes i metodologia de programació. En aquest cas, s’han seguit les següents directrius amb la intenció d’obtenir un programari alhora robust, versàtil i eficaç.

Menor consum de temps. Tot i que avui en dia no sol haver-hi limitacions de maquinari (“hardware”), el procés de comunicació i posterior comprovació amb alguns equips consumeix força temps. Cal optimitzar el codi per tal de que les subrutines que realitzin la funció per la qual estan destinades, ho facin en el menor temps possible. Identificació dels errors. Ha de ser capaç d’identificar el possibles errors i indicar-ho a l’usuari en forma d’alarma perquè es solucioni el més ràpid possible i en el cas que sigui possible, no aturar el flux normal del programa. El sistema ha d’estar protegit per la possibilitat de captura de dades errònies. Per tant, cal validar les dades d’entrada i sortida per comprovar si estan dins el rang del senyal desitjat.

Restauració automàtica. El sistema ha de ser capaç de posar-se en marxa automàticament davant d’una possible errada (tall de corrent, etc..) i continuar, sense canvis respecte les tasques que s’estaven realitzant anteriorment. Cal doncs, la creació d’un fitxer amb tota la configuració i que s’actualitzi constantment.

Comprovació. S’ha de testejar el sistema sota diferents situacions i veure si la seva resposta és favorable. Sobretot comprovar que la freqüència amb què es realitzen el processos és la desitjada pel

RESULTATS I DISCUSSIÓ programador i que en cap moment es produeixen endarreriments importants.

Programació modular. S’ha de programar de forma modular i clara, incloent nombrosos comentaris en el codi per facilitar la tasca al programador. Els diferents mòduls han de realitzar tasques molt específiques i senzilles. La repetició de codi és totalment desaconsellable i només s’ha de permetre en casos puntuals.

Estructuració. Cal ordenar de forma jeràrquica els diferents mòduls, facilitant així la introducció de codi nou i que el programari sigui el més flexible possible.

Comunicacions

Uns dels apartats importants a conèixer abans de començar la tasca de programació són els protocols per establir la comunicació entre els diferents equips. No s’està parlant del tipus de connexió física entre ells, explicada a l’apartat 1.6, sinó quina és i com cal interpretar la informació enviada/rebuda. Es tracta doncs, de com interpretar les cadenes de números o text transmeses entre els equips.

Normalment, les empreses dissenyen un protocol específic per cada aparell i algunes vegades empren parcialment protocols estàndard. En ambdós casos acostumen a incloure tota aquesta informació en el manual d’instruccions de l’equip.

A continuació es detalla el protocol usat en la connexió entre l’ordinador i cadascun dels equips emprats en el sistema.

Comunicació PC1 – Equip de mesura de metanol (MC-168).

La comunicació es fa mitjançant el port sèrie de l’ordinador utilitzant la connexió de tipus RS-232 i de manera bidireccional, on l’equip de mesura resta a l’escolta per respondre les peticions que s’envien des del PC. Només cal enviar un “0” pel port sèrie i la resposta de l’equipament és una cadena de text on s’indica el valor en voltatge del sensor de mesura. Així doncs, el pas del valor de voltatge a

concentració de metanol (g·l-1_{) cal fer-la posteriorment l’ordinador.}

Comunicació PC1- equip de pressió.

La comunicació és de tipus bidireccional via RS-485 utilitzant l’estructura del protocol de comunicació estàndard Modbus a través d’un dels ports configurables de la tarjeta PCL-746 (Veure apartat 3.1).

Tota la comunicació es realitza en notació hexadecimal, seguint de forma ordenada la següent estructura:

Direcció, funció, paràmetre_a, paràmetre_b, paràmetre_control

Direcció – Atès que aquest tipus de connexió (RS-485) permet la col·locació de diferents equips en sèrie utilitzant la mateixa línia, cal que el primer valor de la cadena que s’envia indiqui a quin equip va dirigit. En aquest cas només hi ha el controlador de pressió, per tant, com a primer valor sempre s’enviarà un “1” (en hexadecimal).

Funció – Aquest valor serveix per indicar la funció a realitzar, per exemple, si es volen llegir les dades o canviar alguna consigna. En aquest cas només s’utilitzen la funció amb valor 3, per a la petició de dades i la de valor 6, per fer el canvi d’alguna variable. En tots dos casos s’envien les peticions des del PC cap a l’equip, aquest realitza l’acció i finalment respon.

Paràmetre_a i paràmetre_b – El significat que tenen aquests valors