MDS PLC

Metodología dedesarrollo software paraAutómatas Programables

Sevilla, a 8 de Agosto de 2008.

Autores: F.J. Molina, A.A. Gómez

J. Barbancho, G. Amarante

Índice

1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 1

2. Modelo V de Desarrollo Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 1

2.1 Fase de Especificación de los requisitos software. . . . . . . . . . . . . . . . . . . . . . Pag. 6

2.1.1 Análisis de requisitos software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 6

2.1.2 Diseño de un test de conformidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 8

2.2 Fase de Diseño del Sistema de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 8

2.2.1 Especificación y diseño del test de Sistema . . . . . . . . . . . . . . . . . . . . . . . Pag. 12

2.3 Fase de Diseño de la Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . Pag. 13

2.3.1 Estructuración de un programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 13

2.3.2 Descomposición de un programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 14

2.3.3 Descripción funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 15

2.3.4 Ejemplo de arquitectura software de un programa dentro de unaconfiguración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 15

2.3.5 Especificación y diseño de un test de integración . . . . . . . . . . . . . . . . . . Pag. 18

2.4 Fase de Diseño de los Módulos o Unidades de Programa . . . . . . . . . . . . . . Pag. 18

2.4.1 Diseño de un test para los módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 19

2.5 Fase de Codificación (programación) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 21

3. Referencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 1

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 23

Metodología de desarrollo software para autómatas programables

P ag. 5

1. Introducción

El objetivo académico principal que se persigue con este documento es la comprensiónde las diferentes etapas del desarrollo y documentación de un programa de automatizaciónindustrial de mediana complejidad. De forma muy resumida podemos adelantar lassiguientes:

• Concepción del comportamiento del automatismo. El desarrollo software comienzarealmente en etapas muy tempranas del proyecto, durante el diseño de la máquinao proceso industrial, o cuando se planifican sus reformas. En estas fases, medianteel diálogo con los ingenieros responsables de dichos trabajos, se definen los modosde funcionamiento del sistema de control, y sus acciones sobre el proceso. P.emodos manual, automático, avería, emergencias, etc.

• Diseño de la Estructura Hardware del Sistema de Control. La principal tarea dediseño es la de definir la arquitectura del sistema de control, decidiendo si seimplementa un sistema distribuido (DCS), una estructura multi-PLC, un SistemaCentralizado, un Maestro-Esclavo, etc. En la elección se deberá tener en cuentacriterios de carácter técnico-económico como la distancia entre elementos, elcableado necesario, y la fiabilidad o el rendimiento requeridos por el problema. Esteúltimo, es un punto normalmente olvidado por los textos de programación de PLCs,sin embargo, es imprescindible antes de decidir las tecnología de programación o laarquitectura software más adecuada.

• Diseño de la Arquitectura Software del Programa de Control. Para definir laarquitectura software deben considerarse varios factores, aunque el másdeterminante es la tecnología de programación. Actualmente existen dos grandestecnologías para el desarrollo de programas de aplicación industrial, que se basanen los estándares IEC-61131 e IEC-61499. El primero está muy asentadoindustrialmente, y es especialmente adecuado en sistemas centralizados, o redesde PLCs débilmente acoplados. En cambio, el IEC-61499 se ha concebido para eldesarrollo software en sistemas de control distribuidos. A diferencia del primero,hasta la fecha el IEC-61499 se encuentra en sus primeras etapas de desarrollo y notiene aún una implantación clara en el mercado industrial. A medio plazo será sinduda el estándar de referencia, ya que en él se integran fácilmente todos elementossoftware del programa de control, el SCADA y pruebas de simulación.

• Implementación y Validación. El desarrollo final del programa requiere laprogramación de las diferentes unidades de programa definidas en la arquitecturasoftware. Cada uno de estos bloques estará relacionado con el control de losdiferentes actuadores y con la gestión del modo de funcionamiento del automatismo.La validación del funcionamiento es esencial para ofrecer un resultado fiable.

• Mantenimiento. Cualquier sistema complejo, incluido el software, requiere ajustes ycorrecciones para lograr un comportamiento fiable, en especial, urante sus primerosmeses de funcionamiento.

2. Modelo V de desarrollo Software

Pag. 6

2. Modelo V de Desarrollo Software

En Ingeniería del Software se han propuesto multitud de metodologías para el desarrolloy seguimiento de proyectos de programación como los famosos modelos en Cascada o elTop-Down & Bottom Up . Para aplicaciones críticas, aquellas que requieren una altafiabilidad, la comunidad industrial ha definido estándares como el IEC-61805, donde serecomienda el modelo en V como metodología de programación. En general, la mayoría delas aplicaciones industriales no pueden clasificarse como críticas, incluso aunque sufiabilidad debe ser alta. Sin embargo, la utilización de esta metodología es considerada comouna buena práctica, y se encuentra muy extendida. En la figura 1, se muestran las fases dedesarrollo inspiradas en el modelo V.

Partiendo del conocimiento sobre el funcionamiento del proceso, el modelo V proponecuatro actividades complementarias para lograr un software fiable: (1) de diseño, (2) decodificación, (3) de diseño de pruebas, y (4) de validación. Las actividades se dividen enetapas, en las que el diseño o desarrollo, se complementa con la elaboración y ejecución depruebas de validación.

2.1 Fase de Especificación de los requisitos software.

2.1.1 Análisis de requisitos software.

De la especificación general del proceso y de la información aportada por los ingenierosque proyectan o gestionan la planta, debe elaborarse una especificación suficientementeclara para que sea comprensible a terceros, e incluso se recomienda que los técnicosresponsables del desarrollo del programa participen en la redacción de este documento.

La especificación debe contener la descripción del funcionamiento del proceso y del

Figura 1. Modelo V de desarrollo software


P ag. 7

sistema de control para los diferentes escenarios en los que debe operar: funcionamientonormal en producción, situaciones de avería, paradas de mantenimiento, etc.

No existe ningún estándar que defina un modelo general de funcionamiento para unautomatismo industrial. Sin embargo, existen guías específicas para algunos tipos deprocesos, elaboradas por consorcios internacionales, y también, una guía genérica, conocidacomo GEMMA, en las que se establecen distintos modos de operación de un automatismo(p.e modo automático, manual, avería, de preparación, etc). La guía GEMMA, además,ayuda a diseñar la interfase de control de los operadores de planta (señalizaciones,botoneras, selectores, etc).

La figura 2 ilustra con un ejemplo un automatismo basado en GEMMA. En él puedenapreciarse entre otros, un estado de parada inicial (A1) que tras una serie de accionesde preparación (F2) comienza una fase de producción cíclica (F1). Tras una orden deparada (A2), y al finalizar el ciclo de trabajo en curso, el sistema volverá a la paradainicial. Se incluyen también modos de avería (D1) a donde el sistema se dirige en casode fallo para colocarse en un modo seguro, a la espera de que sea reparado yrearmado (A5). A continuación, el automatismo reiniciará el proceso (A6), situándoloen parada inicial (A1).

Figura 2. Ejemplo de guía GEMMA


Pag. 8

Se hayan utilizado o no de diseño, los estados de un automatismo representan engeneral escenarios o problemas diferentes, independientes, ya que no se pueden darsimultáneamente. Por ejemplo, las acciones de control durante el modo normal deproducción serán distintas a las que requiere un modo manual, o una situación de avería.La descripción de requisitos debe por tanto realizarse para cada uno de estos estados deforma independiente, como si se tratara de problemas distintos.

Siguiendo el ejemplo de la figura 2, las descripciones a realizar serían:

1. Modo de parada (A1). Se trata de una situación estable y segura. Deberán definirselos estados de cada uno de los elementos del proceso. El diseño de la instalacióndebe tener en cuenta que este modo debe corresponder al estado no activo de lassalidas del sistema de control.

2. Modo de funcionamiento normal (F1). Corresponde al estado de producción delproceso. Se describirá la secuencia de trabajo del conjunto, y el funcionamiento decada uno de los elementos de control.

3. Modo de preparación (F2). En él se incluyen todas las acciones de controlnecesarias para preparar el modo de producción normal

4. Modo de reinicialización. Se describirán las acciones que permiten alcanzar el estadode parada A1 tras cualquier tipo de avería, o tras un fallo del suministro eléctrico.

5. Etc

2.1.2 Diseño de un test de conformidad.

Es especialmente importante la definición de un plan de ensayos de conformidad quepermitan validar el resultado final. El plan debe considerar aspectos como:

• El equipamiento que requieren las pruebas

• Quién y cuándo se ejecutan

• Modos de operación que van a ser testados (arranque, modo normal, parada, reset,mantenimiento, etc)

• Condiciones anormales que pueden lograrse previsiblemente en los ensayos

• Criterios para definir si las pruebas son superadas o no.

2.2 Fase de Diseño del Sistema de Control

Existen grandes diferencias entre el desarrollo software para sistemas de propósitogeneral y sistemas de control industrial. En esta fase, comienzan ya a apreciarse esasdiferencias. En sistemas basados en PLCs, y en general, para todos los sistemas deautomatización industrial, la fase de diseño del sistema comienza por la definición de laarquitectura hardware más adecuada para el control del proceso. En la siguiente lista seindican algunas:

• DCS-Distribuited Control System. Un sistema DCS se compone de múltiples buclesde control de variables analógicas, tales como temperatura, caudal en línea, pH, etc.Son muy habituales en procesos continuos, donde se requiere mantener en todoinstante esas magnitudes dentro de un rango de trabajo (p.e en la industria química,petrolera, o en generación energética). La coordinación lógica entre bucles distintos


P ag. 9

no existe o es casi nula, y se realiza fundamentalmente en el nivel de supervisión delproceso (SCADA). Los dispositivos que ejecutan los bucles de control tienen unaescasa capacidad de programación. En realidad, tan sólo se configuran con unconjunto de parámetros de supervisión (niveles de alarma), y control (valores deconsigna, constantes PID, valores límite, etc). En esta arquitectura, sensores,actuadores y controladores se conectan habitualmente mediante buses decomunicaciones.

• Sistemas Centralizados. En ellos todos elementos del sistema de control, sensoresy actuadores se conectan a un único equipo de control. Esta conexión puede sercableada, con buses de campo, o ambas simultáneamente. Esta arquitectura esadecuada para procesos pequeños, con pocos sensores y actuadores, que sedistribuyen sobre distancias cortas. Los PLCs son una solución ideal para estaarquitectura.

• Sistemas Maestro-Esclavo. Se trata de una variante del sistema centralizado, dondepor necesidades de distancia se necesita un sistema anexo al principal (el esclavo)que ejecute las órdenes del maestro, pero que tenga la inteligencia suficiente parapoder actuar por su cuenta si la comunicación con el maestro se pierde. La mayoríade los PLCs comerciales poseen módulos esclavos. Para el programa que ejecutael maestro, el esclavo es transparente.

• Sistemas multi-Centralizados. Consisten en sistemas de estructura centralizada qurtrabajan de forma autónoma pero coordinada. Esta coordinación puedeimplementarse mediante señales de campo, o transfiriendo datos a través debuses de comunicaciones. Es una estructura muy adecuada en sistemascomplejos, donde la distancia entre elementos sea grande, o cuando existan áreasdiferentes de proceso que trabajan de forma autónoma. La existencia de variossistemas semi-independientes aumenta la disponibilidad del proceso ante un fallo delsistema de control. Los PLCs están perfectamente diseñados para soportar estaarquitectura.

• Sistemas Híbridos. Son aquellos que integran control continuo y discreto, es decirbucles de control, con secuenciamiento de acciones y control lógico. Se instalan confrecuencia en procesos de fabricación por lotes (batch), como en la industriafarmacéutica o alimentaria. La potencia de cálculo de los PLCs actuales les permiteejecutar bucles de control continuos, y por tanto, pueden integrar funciones de losDCS. Los autómatas programables son, por tanto, una tecnología más queadecuada para un sistema híbrido.

La figura 3 ilustra con algunos ejemplos la estructuras descritas. De ellos, y de lasexplicaciones anteriores se deduce que los PLCs son muy versátiles, y pueden emplearseprácticamente en todas las arquitecturas de control, si bien, los sistemas distribuidos sesuelen implementarse con controladores específicos. También se deduce que la fronteraentre un sistema DCS y otro basado en PLCs es cada vez más difusa, hasta tal punto quealgunas arquitecturas son difícilmente clasificables.


Pag. 10

Figura 3. Estructuras de control


P ag. 11

La tecnología de programación y/o configuración de estos sistema ha sufrido tambiénun proceso de fusión. El estándar IEC 61131 es el marco conceptual de los sistemas decontrol basados en PLCs. Define sus características físicas, lógicas, y su conectividad.También ofrece un modelo de arquitectura que abarca desde los sistemas centralizados alos multi-centralizados.

El IEC 61804 es el estándar de referencia para sistemas DCS. En él se describe cómoestructurar un sistema de control para ofrecer una interface común a dispositivos de bus decampo.

En la actualidad, ambos estándares convergen en IEC 61499, diseñado para darsoporte a aplicaciones distribuidas, con programas que se alojan y ejecutan en variosdispositivos de forma simultánea y remota.

Los sistemas distribuidos se salen del ámbito de este texto, por lo que utilizaremos elIEC 61131 como guía en la descripción de la estructura hardware, y para el desarrollo delprograma. Al diseñar la arquitectura hardware debemos decidir aspectos como:

• Cuántos PLCs son necesarios

• Funciones del proceso que ejecuta cada PLC

• Ampliaciones necesarias

• Cómo se interconectan

• Con qué buses,

• Fabricantes, modelos y tecnología.

Al repartir las funciones de proceso entre cada uno de los PLCs hay que tener encuenta las limitaciones del modelo IEC 61131, y es que en el caso más complejo describesistemas multi-centralizados. Al contrario que en los sistemas distribuidos, con este modeloun programa sólo puede residir en un PLC, aunque un PLC sí puede ejecutar variosprogramas. En el caso más complejo, cada PLC de un sistema de control multicentralizadogestiona uno o varios subprocesos, que se ejecutan de forma coordinada entre sí y con losasignados a otros PLCs.

Los conceptos con los que IEC 61131 describe la arquitectura hardware son tres:

1. Las Configuraciones o PLCs que constituyen el sistema de control , así como suinterconexión.

2. Para cada configuración hay que definir qué Recursos incluye (CPUs o cualquierdispositivo capaz de ejecutar un programa IEC 61131).

3. Cada recurso contiene características fijas que deben declararse (capacidad dememoria, E/S integradas, temporizadores, modos de ejecución, etc), así comocapacidades ampliables que deben diseñarse de manera específica (E/S en slots deampliación, E/S descentralizadas en buses de comunicaciones, módulos de funciónespecial, etc).

La siguiente figura ? ilustra estos conceptos con un ejemplo en el que se incluyen dosPLCs (configuraciones). El primero contiene una CPU (recurso), E/S integrada y E/Sdescentralizada. El segundo sólo con E/S integrada.


Pag. 12

2.2.1 Especificación y diseño del test de Sistema

En esta fase también es especialmente importante definir pruebas que verifiquen lainterconexión hardware y la integración soft/hardware, sobre todo cuando se utilizandispositivos de diferentes fabricantes. Los test se realizaran a varios niveles, como porejemplo los siguientes:

• Comprobación del cableado con los elementos de proceso (activando manualmentelas salidas del PLC, o desarrollando un programa al efecto).

- Verificación de la configuración de todos los dispositvos

- Analizando la correcta instalación de ampliaciones y periféricos a los PLCs (p.emediante el sistema de autodiagnósticos de los autómatas)

- Comprobando las comunicaciones entre dispositivos (usando el sistema deautodiagnósticos, herramientas ofrecidas por el fabricante, o programasdesarrollados para ello).

- Verificando la integración del software dentro de las distintas configuraciones y lacoordinación de los módulos software entre distintos PLCs.

Figura 4. Programa principal.


P ag. 13

2.3 Fase de Diseño de la Arquitectura Software

A grandes rasgos, se trata de decidir cómo se organiza el software, cómo se divide yqué módulos se desarrollan, y cómo se integran formando diferentes programas oaplicaciones. La arquitectura software depende en gran medida de esa tecnología deprogramación escogida; en nuestro caso, el IEC 61131-3. De las ventajas que se logran conuna correcta estructuración, significamos las siguientes:

• Una mejor visión de conjunto del sistema, lo que es importante no sólo para losprogramadores, sino también para los operadores, y el personal de instalación ymantenimiento.

• Una buena base de comunicación dentro del equipo de desarrollo.

• Generación de código más comprensible, reutilizable, verificable y fácil de mantener.

• Una documentación mejor organizada.

La norma IEC 61131-3 contiene conceptos y lenguajes de programación muy potentesa la hora de estructurar el software. Como ya se ha mencionado en el apartado anterior, enel nivel más alto, donde se definen las configuraciones (PLCs) y su conexión. En este puntodebe tenerse en cuenta que según este estándar, un programa reside en un único PLC, demodo que debemos dividir el software de control, como mínimo, en tantos programas comoPLCs integren el sistema. Todos ellos trabajarán de forma conjunta, empleando algúnprocedimiento de coordinación, como señales de campo, variables de red, o mediante latransmisión de mensajes. Estas dos últimas opciones requieren, obviamente, buses decomunicaciones.

Dentro de cada configuración, el programa puede ser muy complejo, y por tanto debeorganizarse adecuadamente. El IEC 61131 posee un gran capacidad de organización quese basa en la estructuración y la descomposición de un programa.

2.3.1 Estructuración de un programa

Según la norma 61131-3, un programa se define como “una interconexión lógica deunidades de programa (POUs) a la que se le asocia un modo de ejecución (tarea)”. La figura5, 6 muestra un ejemplo de esta filosofía. Las unidades de programa son “trozos o pequeñosprogramas” que resuelven una parte del problema. Su interconexión permite coordinar estossubprogramas para resolver el problema al completo.

Ejemplo: Es muy habitual asignar unidades de programa a cada uno de los actuadoresdel proceso que requieran cierta inteligencia en su control como motores, válvulasmotorizadas, bombas centrífugas, cilindros neumáticos, etc. Una bombilla, por ejemplo,no requiere un bloque de programa.

Una POU puede programarse como una interconexión de unidades de programa máspequeños, estructurandose, de este modo, el código de forma jerárquica. Uno de losaspectos más importantes de las POU son su interfase, es decir, los parámetros o datos a


Pag. 14

través de los cuales el código recibe o envía información. La funcionalidad de una unidadde programa se especifica claramente definiendo su interfase y describiendo la función decada uno de sus parámetros.

2.3.2 Descomposición de un programa

IEC 61131-3 define 5 lenguajes de programación distintos. Uno de ellos, el SFC(Sequential Function Chart), se diseña para descomponer un programa secuencial yconcurrente en un conjunto de operaciones más sencillas. El SFC es un lenguaje gráfico,heredero del GRAFCET con el que puede describirse de forma relativamente sencillasecuencias complejas de operaciones, secuencias independientes que se ejecutan de formaparalela, o incluso pueden sincronizarse secuencias paralelas.

En el SFC de la figura 6, 7, pueden observarse las principales características de estelenguaje. El SFC consta de etapas unidas mediante transiciones. Las etapas reflejanestados particulares del sistema. Cada etapa tiene asociadas acciones que ejecutan ciertafunción de control. Estas acciones pueden programarse en cualquiera de los lenguajes IEC61131-3. Las transiciones poseen condiciones que controlan la evolución de unas etapasa otras. Las condiciones de transición se programan normalmente empleando lenguaje decontactos o de funciones.



P ag. 15

2.3.3 Descripción funcional

Una vez definida la arquitectura del programa, debe realizarse una lista de todos losbloques de acción y unidades de programa. Para cada uno de ellos se redactará unadescripción funcional , que en térmicos genéricos, indique la función que ejecuta en algunoo varios de los siguientes ámbitos: sobre los elementos del proceso, en el estado delautomatismo, o en la coordinación del programa.

2.3.4 Ejemplo de arquitectura software de un programa dentro de una configuración

La figura ? muestra el tanque de un proceso de fermentación. Entre los parámetros acontrolar tenemos los siguientes:

• El llenado y vaciado se realizan mediante las válvulas correspondientes (feed,harvest).

• El pH se regula haciendo uso de aditivos ácidos o alcalinos

• La Temperatura, utilizando la resistencia calefactora.

• La Agitación, mediante un motor con control de velocidad.

Figura 6. Lenguaje de programación SFC


Pag. 16

Muchas arquitecturas son posibles. Cada equipo de desarrollo puede seleccionar algunade las más conocidas, o diseñar una nueva.

En la figura 8 hemos mostramos la arquitectura software propuesta por PLCOPEN,organización que se dedica a promover el uso del estándar IEC 61131-3. En ella se observaque el programa principal consta de múltiples POUs que controlan los diferentes actuadoresdel sistema. A su vez, estas unidades de programa son gestionadas desde una POUprincipal.

En muchas ocasiones es conveniente incluir también bloques específicos asociados alos sensores con el objeto de procesar los datos, convertir formatos, filtrar informaciónerrónea, detectar fallos, etc.

En nuestro ejemplo, la unidad de programa principal, se encarga de ejecutar elfuncionamiento normal de fermentación. Éste incluye varias fases, como inicialización,llenado, calentamiento, etc. También deberá comenzar la agitación, y la regulación del pH,manteniéndose la temperatura bajo control. Al final del proceso, se ejecutará el vaciado deldepósito.

El lenguaje SFC nos permite descomponer la secuencia de operaciones de formasencilla, rompiendo de este modo el código en pequeños programas que se ejecutan desdelos bloques de acción.

Una vez finalizado el SFC “principal”, deberán enumerarse las POUs necesarias paraimplementar los bloques de acción y el control de los actuadores. Se indicará detalladamentelas funciones que debe desarrollar. En el ejemplo, la figura muestra claramente los bloquesnecesarios, y del enunciado se deduce fácilmente la función de cada uno de dichos bloques.

Figura 7. Proceso de fermentación


P ag. 17

Figura 8. (A) Bloque de control del automatismo. (B) Bloques de control de Actuadores

(C) SFC del bloque MainSequence. (D) POUs de los bloques de acción del SFC

(D) Bloque de control de sensores


Esta división es muy general, y la encontraremos con facilidad en arquitecturas software distintas de la1

mencionada. Es incluso recomendable para la reutilización del código diseñar las POUs con esta filisofía, incluso paraarquitecturas software propias, diseñadas de forma personalizada

Pag. 18

2.3.5 Especificación y diseño de un test de integración

El objetivo principal de las pruebas en este punto es determinar que el funcionamientoconjunto de las unidades de programa se corresponde con el deseado. En particular, lostest deberán diseñarse para verificar la correcta elección y funcionamiento de las señalesque interconectan los bloques entre sí.

Siguiendo el ejemplo de la arquitectura propuesta en la figura 8, y según el modelo dedesarrollo en V, cuando se ejecuta este test, las unidades de programa de los bloques deacción y de los elementos actuadores ya habrían sido testados de forma individual. Se trataahora, por tanto, de probarlos “conectados”, tarea que podría ejecutarse, por ejemplo, conlos siguientes pasos:

• Testar uno a uno la coordinación entre las POUs de los bloques de acción y el SFCprincipal.

• Verificar que las POUs de acción funcionan correctamente cuando se detiene y sereinicia su ejecución como consecuencia del cambio de etapa del SFC..

• Testar una a una la interconexión enter el Bloque de la secuencia principal y lasunidades de programa de los actuadores.

• Testar el funcionamiento completo

2.4 Fase de Diseño de los Módulos o Unidades de Programa

El diseño de una unidad de programa comienza por la definición de sus interfases. Paraello es necesario tener en cuenta que, en general podemos encontrar tres tipos de señales:

• Señales de campo, que provienen directamente de los sensores o actuadores.

• Señales de mando, de las que se reciben órdenes de los operadores (cuadros demaniobra o SCADAs).

• Señales de coordinación entre diferentes POUs (indicaciones de fin de ejecución deun trabajo, errores, etc).

En la arquitectura software propuesta por PLCOpen (figura 8) puede observarsefácilmente que existen dos tipos de unidades de programa (ver nota ):1

• Bloques dedicados al control directo de elementos de proceso.

• Bloques que gestionan el comportamiento del proceso y del automatismo.

En el primer caso, las POUs contendrán fundamentalmente señales de campo másalguna de coordinación que indique si la acción se ha ejecutado satisfactoriamente o si haproducido algún error.

En los bloques para el control del automatismo y del estado del proceso, la mayor partede las señales que contienen son señales de coordinación con otras unidades de programa,y señales que se conectan a elementos de la consola de operación, o variables del SCADA(botones, selectores, señalizaciones luminosas, etc).


P ag. 19

Al definir una señal deben establecerse tres puntos:

• Tipo de variable (BOOLEAN, BYTE, INTEGER, FLOAT, TIME, etc.

• Mecanismo de señalización. Para señales de tipo binario, especialmente las decoordinación, debe decidirse entre tres formas de señalización:

- Activas por nivel. La información se indica por el valor de la variable. P.e undetector de fuego señala con un 0 la presencia de llamas. Hasta que se extingacompletamente el detector seguirá dando ese valor.

- Activas por flanco. Un cambio en el valor de la señal (de 0 a 1 en flancospositivos, o de 1 a 0 en flancos negativos) indica la ocurrencia de un suceso quedebe ser conocida. P.e en estado normal un relé térmico ofrece un valor de 1. Sise produce el sobrecalentamiento de un motor, el relé se abre y se lee como un0. El fallo térmico se señaliza con un flanco negativo. Para que una señal deflanco pueda avisar de un nuevo evento, ésta debe volver a su estado de reposo,el previo al flanco.

- Pulso. El evento se avisa con un pulso. Para este tipo se señales, existe unestado de reposo (0 ó 1). Cuando se desea señalar un evento, la línea cambiade estado, aunque ese cambio es temporal, ya que retorna al estado de reposotranscurrido un cierto tiempo (pulso).

Terminada la interfase, la función que debe ejecutar la POU debe definirse con claridadtraduciendo la descripción funcional, que se hizo en la fase de diseño de la arquitectura(función general) a otra “más tecnológica”, empleando términos que incluyan las señales desu interfase. Por ejemplo, en lugar de decir “abre la válvula de vaciado”, diremos “activa (pona 1) la salida AbrirValvula”.

2.4.1 Diseño de un test para los módulos

Para cada una de las unidades de programa desarrolladas se diseñará un test quepermita validar la funcionalidad de las POUs comenzando por las más simples, en el sentidode que no emplean dentro de su código otras POUs que deban ser testadas. Sí podríancontener POUs de sistema, librerías estándar, o librerías del propio equipo de desarrollo queya han sido suficientemente probadas y utilizadas.

Los test más básicos son de tipo estático. El comportamiento del programa se verificaforzando el cambio en alguna variable de entrada de su interfase. Este procedimiento puedeejecutarse desde el entorno de programación empleando un simulador del autómata sobreel que forzamos su E/S de forma manual (figura 9, 10a). Para efectuar todo este procesosobre un PLC real, hay que asegurarse de que éste no esté operando sobre el proceso (fig.9, 10b).

Más complejos son los test dinámicos, donde se generan patrones de prueba a modode secuencia temporal de cambios que afectan a distintas entradas de forma simultánea.El resultado del test se obtiene del análisis de la evolución temporal de las salidas, y de loscambios de estado de la unidad de programa (estado que se almacenada en sus variablesinternas). Este tipo de ensayos pueden ser muy complejos, por lo que en muchas ocasiones,es necesario ejecutarlos mediante simulaciones, o desarrollando una unidad de programaespecífica que genere esos patrones de prueba. En las figuras ?a y ?b se muestran ambasfilosofías:

Si se ha seguido un procedimiento de diseño del correcto, en este punto, las unidadesde programa deben ser muy pequeñas, con pocas entradas y salidas. En este caso, larealización de los ensayos es mucho más sencilla a la vez que fiable, e incluso en algunoscasos, los test se pueden llevar a cabo dentro del entorno de programación, sin simuladores


Pag. 20

ni programas adicionales. Esta última, es la forma más básica de ejecución de los test. Paraensayos más complejos se requieren también arquitecturas también más complejas,empleando simuladores externos, mediante procedimientos de ensayo en fábrica, e inclusointegrando la simulación con el proceso real con el objetivo de entrenar a los operadores.

Figura 9. Test manual desde el entorno de programación:

(a) con simulador, (b) con PLC

Figura 10. Test manual desde el entorno de programación: (a) con

simulador, (b) con PLC


P ag. 21

2.5 Fase de Codificación (programación)

En esta fase, se desarrolla el código en alguno de los lenguajes estándar o se modificanprogramas ya existentes. La mejor opción en este caso es la reutilización de código, esdecir, emplear programas ya utilizados en otros proyectos, y por tanto ya testados. Estoahorra tiempo y costes de desarrollo y validación. En segundo lugar, la modificación deprograma ya existentes es una opción válida si se trata tan sólo de pequeñasmodificaciones, añadir una o dos señales, o modificar una o dos de las existentes, etc. Silos cambios son amplios, es recomendable desarrollar un nuevo programa.

El estilo de programación es también importante. El código debe ser legible. Cualquiermiembro del equipo debe ser capaz de comprenderlo, partiendo de las especificaciones delmódulo, simplemente “leyendo” el programa. Para lograrlo deben seguirse al menos lassiguientes recomendaciones:

- Declarar las variables internas con nombres que reflejen el significado de lainformación que contienen. P.e en lugar de “v1" utilizar “falloTermico” o“sobrecalentamiento”.

- En la mayoría de los casos, es mejor emplear “lógica positiva” en las variablesbinarias. Siguiendo el ejemplo anterior, esto significa que cuando se produce unsobrecalentamiento, la variable “sobrecalentamiento” está en 1.**

- Deben comentarse todas, o la mayoría de las líneas de programa, explicando lo quese pretende hacer empleando los nombres de variables internas o de la interfase,nunca en términos del elementos de proceso.

- No emplear NUNCA variables globales. De otro modo el código podría no serreutilizable.

- El lenguaje de programación debe escogerse en relación con la funcionalidad delprograma y los conocimientos del programador. Por ejemplo:

• LADDER - Es el más empleado. Muy adecuado para programas con pocasseñales y pocas variables internas.

• FUNCIONES - Muy adecuado para estructurar cualquier unidad de programacompuesto de otras POUs más pequeñas que se ejecutan de formaconcurrente (simultánea y coordinada). P.e. el programa principal de muchasarquitecturas (PLCOPEN).

• SFC - Adecuado para descomponer programas con complejas secuenciasde operación. P.e para desarrollar los modos GEMMMA del automatismo.

• INSTRUCCIONES - Adecuado para desarrollar código muy compacto yrápido de ejecución, o donde conocer el tiempo de ejecución de lasinstrucciones pueder ser importante. P.e en la gestión de alarmas. Es unlenguaje similar al ensamblador que requiere conocimientos muyespecializados. No está muy extendido.

• TEXTO ESTRUCTURADO. Similar al PASCAL. Es adecuado para programaralgoritmos matemáticos de todo tipo. Simples, como un comparador conhistéresis, o complejos como un algoritmo de regulación PID.

Pag. 22

3. Referencias

Automatización de procesos mediante la Guía GEMMA. Ponsa Asensio, Vilanova Arbós. Ed. Ediciones UPC. 2005. (Pag. 22)

GEMMA, Guide d'Etude des Modes de Marches et d'ArretsProduction Automatisme, ADEPA, 1981. (Pag. 22)

[1] Automatización de procesos mediante la Guía GEMMA.

Ponsa Asensio, Vilanova Arbós. Ed. Ediciones UPC. 2005.

GEMMA, Guide d'Etude des Modes de Marches et d'Arrets

Production Automatisme, ADEPA, 1981.


P ag. 23

Lista de Figuras

Figura 1. Modelo V de desarrollo software

Figura 2. Ejemplo de guía GEMMA

Figura 3. Estructuras de control



Figura 6. Lenguaje de programación SFC

Figura 7. Proceso de fermentación

Figura 8. (A) Bloque de control del automatismo. (B) Bloques de control de Actuadores(C) SFC del bloque MainSequence. (D) POUs de bloques de acción del SFC(D) Bloques de control de sensores

Figura 9. Test manual desde el entorno de programación: (a) con simulador, (b) con PLC

Figura 10. Test manual desde el entorno de programación: (a) con simulador, (b) con PLC

Date post:	18-Jul-2016
Category:	Documents
Upload:	agrovado
View:	12 times
Download:	0 times

MDS PLC

Documents