Metodologa de

desarrollo software para

Autmatas Programables

Sevilla, a 8 de Agosto de 2008.

Autores:

F.J. Molina, A.A. Gmez

J. Barbancho, G. Amarante

ndice
1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 1

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

2.1 Fase de Especificacin de los requisitos software. . . . . . . . . . . . . . . . . . . . . . Pag. 6
2.1.1

Anlisis de requisitos software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 6

2.1.2

Diseo de un test de conformidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 8

2.2 Fase de Diseo del Sistema de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 8

2.2.1

Especificacin y diseo del test de Sistema . . . . . . . . . . . . . . . . . . . . . . . Pag. 12

2.3

Fase de Diseo de la Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . . Pag. 13

2.3.1

Estructuracin de un programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 13

2.3.2

Descomposicin de un programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 14

2.3.3

Descripcin funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 15

2.3.4

Ejemplo de arquitectura software de un programa dentro de una

configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 15

2.3.5

Especificacin y diseo de un test de integracin . . . . . . . . . . . . . . . . . . Pag. 18

2.4 Fase de Diseo de los Mdulos o Unidades de Programa . . . . . . . . . . . . . . Pag. 18

2.4.1

Diseo de un test para los mdulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 19

2.5 Fase de Codificacin (programacin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pag. 21

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

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

Metodologa de desarrollo software para autmatas programables

1. Introduccin
El objetivo acadmico principal que se persigue con este documento es la comprensin
de las diferentes etapas del desarrollo y documentacin de un programa de automatizacin
industrial de mediana complejidad. De forma muy resumida podemos adelantar las
siguientes:

Concepcin del comportamiento del automatismo. El desarrollo software comienza

realmente en etapas muy tempranas del proyecto, durante el diseo de la mquina
o proceso industrial, o cuando se planifican sus reformas. En estas fases, mediante
el dilogo con los ingenieros responsables de dichos trabajos, se definen los modos
de funcionamiento del sistema de control, y sus acciones sobre el proceso. P.e
modos manual, automtico, avera, emergencias, etc.

Diseo de la Estructura Hardware del Sistema de Control. La principal tarea de

diseo es la de definir la arquitectura del sistema de control, decidiendo si se
implementa un sistema distribuido (DCS), una estructura multi-PLC, un Sistema
Centralizado, un Maestro-Esclavo, etc. En la eleccin se deber tener en cuenta
criterios de carcter tcnico-econmico como la distancia entre elementos, el
cableado necesario, y la fiabilidad o el rendimiento requeridos por el problema. Este
ltimo, es un punto normalmente olvidado por los textos de programacin de PLCs,
sin embargo, es imprescindible antes de decidir las tecnologa de programacin o la
arquitectura software ms adecuada.

Diseo de la Arquitectura Software del Programa de Control. Para definir la

arquitectura software deben considerarse varios factores, aunque el ms
determinante es la tecnologa de programacin. Actualmente existen dos grandes
tecnologas para el desarrollo de programas de aplicacin industrial, que se basan
en los estndares IEC-61131 e IEC-61499. El primero est muy asentado
industrialmente, y es especialmente adecuado en sistemas centralizados, o redes
de PLCs dbilmente acoplados. En cambio, el IEC-61499 se ha concebido para el
desarrollo 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 no
tiene an una implantacin clara en el mercado industrial. A medio plazo ser sin
duda el estndar de referencia, ya que en l se integran fcilmente todos elementos
software del programa de control, el SCADA y pruebas de simulacin.

Implementacin y Validacin. El desarrollo final del programa requiere la

programacin de las diferentes unidades de programa definidas en la arquitectura
software. Cada uno de estos bloques estar relacionado con el control de los
diferentes actuadores y con la gestin del modo de funcionamiento del automatismo.
La validacin del funcionamiento es esencial para ofrecer un resultado fiable.

Mantenimiento. Cualquier sistema complejo, incluido el software, requiere ajustes y

correcciones para lograr un comportamiento fiable, en especial, urante sus primeros
meses de funcionamiento.

P ag. 5

2. Modelo V de desarrollo Software

2. Modelo V de Desarrollo Software

En Ingeniera del Software se han propuesto multitud de metodologas para el desarrollo
y seguimiento de proyectos de programacin como los famosos modelos en Cascada o el
Top-Down & Bottom Up . Para aplicaciones crticas, aquellas que requieren una alta
fiabilidad, la comunidad industrial ha definido estndares como el IEC-61805, donde se
recomienda el modelo en V como metodologa de programacin. En general, la mayora de
las aplicaciones industriales no pueden clasificarse como crticas, incluso aunque su
fiabilidad debe ser alta. Sin embargo, la utilizacin de esta metodologa es considerada como
una buena prctica, y se encuentra muy extendida. En la figura 1, se muestran las fases de
desarrollo inspiradas en el modelo V.
Partiendo del conocimiento sobre el funcionamiento del proceso, el modelo V propone
cuatro actividades complementarias para lograr un software fiable: (1) de diseo, (2) de
codificacin, (3) de diseo de pruebas, y (4) de validacin. Las actividades se dividen en
etapas, en las que el diseo o desarrollo, se complementa con la elaboracin y ejecucin de
pruebas de validacin.

Figura 1. Modelo V de desarrollo software

2.1 Fase de Especificacin de los requisitos software.

2.1.1

Anlisis de requisitos software.

De la especificacin general del proceso y de la informacin aportada por los ingenieros

que proyectan o gestionan la planta, debe elaborarse una especificacin suficientemente
clara para que sea comprensible a terceros, e incluso se recomienda que los tcnicos
responsables del desarrollo del programa participen en la redaccin de este documento.
La especificacin debe contener la descripcin del funcionamiento del proceso y del
Pag. 6

Metodologa de desarrollo software para autmatas programables

sistema de control para los diferentes escenarios en los que debe operar: funcionamiento
normal en produccin, situaciones de avera, paradas de mantenimiento, etc.
No existe ningn estndar que defina un modelo general de funcionamiento para un
automatismo industrial. Sin embargo, existen guas especficas para algunos tipos de
procesos, elaboradas por consorcios internacionales, y tambin, una gua genrica, conocida
como GEMMA, en las que se establecen distintos modos de operacin de un automatismo
(p.e modo automtico, manual, avera, de preparacin, etc). La gua GEMMA, adems,
ayuda a disear la interfase de control de los operadores de planta (sealizaciones,
botoneras, selectores, etc).

La figura 2 ilustra con un ejemplo un automatismo basado en GEMMA. En l pueden

apreciarse entre otros, un estado de parada inicial (A1) que tras una serie de acciones
de preparacin (F2) comienza una fase de produccin cclica (F1). Tras una orden de
parada (A2), y al finalizar el ciclo de trabajo en curso, el sistema volver a la parada
inicial. Se incluyen tambin modos de avera (D1) a donde el sistema se dirige en caso
de fallo para colocarse en un modo seguro, a la espera de que sea reparado y
rearmado (A5). A continuacin, el automatismo reiniciar el proceso (A6), situndolo
en parada inicial (A1).

Figura 2. Ejem plo de gua GEMMA

P ag. 7

2. Modelo V de desarrollo Software

Se hayan utilizado o no de diseo, los estados de un automatismo representan en

general escenarios o problemas diferentes, independientes, ya que no se pueden dar
simultneamente. Por ejemplo, las acciones de control durante el modo normal de
produccin sern distintas a las que requiere un modo manual, o una situacin de avera.
La descripcin de requisitos debe por tanto realizarse para cada uno de estos estados de
forma independiente, como si se tratara de problemas distintos.
Siguiendo el ejemplo de la figura 2, las descripciones a realizar seran:
1. Modo de parada (A1). Se trata de una situacin estable y segura. Debern definirse
los estados de cada uno de los elementos del proceso. El diseo de la instalacin
debe tener en cuenta que este modo debe corresponder al estado no activo de las
salidas del sistema de control.
2. Modo de funcionamiento normal (F1). Corresponde al estado de produccin del
proceso. Se describir la secuencia de trabajo del conjunto, y el funcionamiento de
cada uno de los elementos de control.
3. Modo de preparacin (F2). En l se incluyen todas las acciones de control
necesarias para preparar el modo de produccin normal
4. Modo de reinicializacin. Se describirn las acciones que permiten alcanzar el estado
de parada A1 tras cualquier tipo de avera, o tras un fallo del suministro elctrico.
5. Etc

2.1.2

Diseo de un test de conformidad.

Es especialmente importante la definicin de un plan de ensayos de conformidad que

permitan validar el resultado final. El plan debe considerar aspectos como:
El equipamiento que requieren las pruebas
Quin y cundo se ejecutan
Modos de operacin 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 Diseo del Sistema de Control

Existen grandes diferencias entre el desarrollo software para sistemas de propsito
general y sistemas de control industrial. En esta fase, comienzan ya a apreciarse esas
diferencias. En sistemas basados en PLCs, y en general, para todos los sistemas de
automatizacin industrial, la fase de diseo del sistema comienza por la definicin de la
arquitectura hardware ms adecuada para el control del proceso. En la siguiente lista se
indican algunas:

DCS-Distribuited Control System. Un sistema DCS se compone de mltiples bucles

de control de variables analgicas, tales como temperatura, caudal en lnea, pH, etc.
Son muy habituales en procesos continuos, donde se requiere mantener en todo
instante esas magnitudes dentro de un rango de trabajo (p.e en la industria qumica,
petrolera, o en generacin energtica). La coordinacin lgica entre bucles distintos
Pag. 8

Metodologa de desarrollo software para autmatas programables

no existe o es casi nula, y se realiza fundamentalmente en el nivel de supervisin del

proceso (SCADA). Los dispositivos que ejecutan los bucles de control tienen una
escasa capacidad de programacin. En realidad, tan slo se configuran con un
conjunto de parmetros de supervisin (niveles de alarma), y control (valores de
consigna, constantes PID, valores lmite, etc). En esta arquitectura, sensores,
actuadores y controladores se conectan habitualmente mediante buses de
comunicaciones.

Sistemas Centralizados. En ellos todos elementos del sistema de control, sensores

y actuadores se conectan a un nico equipo de control. Esta conexin puede ser
cableada, con buses de campo, o ambas simultneamente. Esta arquitectura es
adecuada para procesos pequeos, con pocos sensores y actuadores, que se
distribuyen sobre distancias cortas. Los PLCs son una solucin ideal para esta
arquitectura.

Sistemas Maestro-Esclavo. Se trata de una variante del sistema centralizado, donde

por necesidades de distancia se necesita un sistema anexo al principal (el esclavo)
que ejecute las rdenes del maestro, pero que tenga la inteligencia suficiente para
poder actuar por su cuenta si la comunicacin con el maestro se pierde. La mayora
de los PLCs comerciales poseen mdulos esclavos. Para el programa que ejecuta
el maestro, el esclavo es transparente.

Sistemas multi-Centralizados. Consisten en sistemas de estructura centralizada qur

trabajan de forma autnoma pero coordinada. Esta coordinacin puede
implementarse mediante seales de campo, o transfiriendo datos a travs de
buses de comunicaciones. Es una estructura muy adecuada en sistemas
complejos, donde la distancia entre elementos sea grande, o cuando existan reas
diferentes de proceso que trabajan de forma autnoma. La existencia de varios
sistemas semi-independientes aumenta la disponibilidad del proceso ante un fallo del
sistema de control. Los PLCs estn perfectamente diseados para soportar esta
arquitectura.

Sistemas Hbridos. Son aquellos que integran control continuo y discreto, es decir
bucles de control, con secuenciamiento de acciones y control lgico. Se instalan con
frecuencia en procesos de fabricacin por lotes (batch), como en la industria
farmacutica o alimentaria. La potencia de clculo de los PLCs actuales les permite
ejecutar bucles de control continuos, y por tanto, pueden integrar funciones de los
DCS. Los autmatas programables son, por tanto, una tecnologa ms que
adecuada para un sistema hbrido.

La figura 3 ilustra con algunos ejemplos la estructuras descritas. De ellos, y de las

explicaciones anteriores se deduce que los PLCs son muy verstiles, y pueden emplearse
prcticamente en todas las arquitecturas de control, si bien, los sistemas distribuidos se
suelen implementarse con controladores especficos. Tambin se deduce que la frontera
entre un sistema DCS y otro basado en PLCs es cada vez ms difusa, hasta tal punto que
algunas arquitecturas son difcilmente clasificables.

P ag. 9

2. Modelo V de desarrollo Software

Figura 3. Estructuras de control

Pag. 10

Metodologa de desarrollo software para autmatas programables

La tecnologa de programacin y/o configuracin de estos sistema ha sufrido tambin

un proceso de fusin. El estndar IEC 61131 es el marco conceptual de los sistemas de
control basados en PLCs. Define sus caractersticas fsicas, lgicas, y su conectividad.
Tambin ofrece un modelo de arquitectura que abarca desde los sistemas centralizados a
los multi-centralizados.
El IEC 61804 es el estndar de referencia para sistemas DCS. En l se describe cmo
estructurar un sistema de control para ofrecer una interface comn a dispositivos de bus de
campo.
En la actualidad, ambos estndares convergen en IEC 61499, diseado para dar
soporte a aplicaciones distribuidas, con programas que se alojan y ejecutan en varios
dispositivos de forma simultnea y remota.
Los sistemas distribuidos se salen del mbito de este texto, por lo que utilizaremos el
IEC 61131 como gua en la descripcin de la estructura hardware, y para el desarrollo del
programa. Al disear la arquitectura hardware debemos decidir aspectos como:

Cuntos PLCs son necesarios

Funciones del proceso que ejecuta cada PLC

Ampliaciones necesarias

Cmo se interconectan

Con qu buses,

Fabricantes, modelos y tecnologa.

Al repartir las funciones de proceso entre cada uno de los PLCs hay que tener en
cuenta las limitaciones del modelo IEC 61131, y es que en el caso ms complejo describe
sistemas multi-centralizados. Al contrario que en los sistemas distribuidos, con este modelo
un programa slo puede residir en un PLC, aunque un PLC s puede ejecutar varios
programas. En el caso ms complejo, cada PLC de un sistema de control multicentralizado
gestiona uno o varios subprocesos, que se ejecutan de forma coordinada entre s y con los
asignados 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 su
interconexin.
2. Para cada configuracin hay que definir qu Recursos incluye (CPUs o cualquier
dispositivo capaz de ejecutar un programa IEC 61131).
3. Cada recurso contiene caractersticas fijas que deben declararse (capacidad de
memoria, E/S integradas, temporizadores, modos de ejecucin, etc), as como
capacidades ampliables que deben disearse de manera especfica (E/S en slots de
ampliacin, E/S descentralizadas en buses de comunicaciones, mdulos de funcin
especial, etc).
La siguiente figura ? ilustra estos conceptos con un ejemplo en el que se incluyen dos
PLCs (configuraciones). El primero contiene una CPU (recurso), E/S integrada y E/S
descentralizada. El segundo slo con E/S integrada.

P ag. 11

2. Modelo V de desarrollo Software

Figura 4. Program a principal.

2.2.1

Especificacin y diseo del test de Sistema

En esta fase tambin es especialmente importante definir pruebas que verifiquen la

interconexin hardware y la integracin soft/hardware, sobre todo cuando se utilizan
dispositivos de diferentes fabricantes. Los test se realizaran a varios niveles, como por
ejemplo los siguientes:

Comprobacin del cableado con los elementos de proceso (activando manualmente

las salidas del PLC, o desarrollando un programa al efecto).

Verificacin de la configuracin de todos los dispositvos

Analizando la correcta instalacin de ampliaciones y perifricos a los PLCs (p.e

mediante el sistema de autodiagnsticos de los autmatas)

Comprobando las comunicaciones entre dispositivos (usando el sistema de

autodiagnsticos, herramientas ofrecidas por el fabricante, o programas
desarrollados para ello).

Verificando la integracin del software dentro de las distintas configuraciones y la

coordinacin de los mdulos software entre distintos PLCs.

Pag. 12

Metodologa de desarrollo software para autmatas programables

2.3

Fase de Diseo de la Arquitectura Software

A grandes rasgos, se trata de decidir cmo se organiza el software, cmo se divide y

qu mdulos se desarrollan, y cmo se integran formando diferentes programas o
aplicaciones. La arquitectura software depende en gran medida de esa tecnologa de
programacin escogida; en nuestro caso, el IEC 61131-3. De las ventajas que se logran con
una correcta estructuracin, significamos las siguientes:

Una mejor visin de conjunto del sistema, lo que es importante no slo para los
programadores, sino tambin para los operadores, y el personal de instalacin y
mantenimiento.

Una buena base de comunicacin dentro del equipo de desarrollo.

Generacin de cdigo ms comprensible, reutilizable, verificable y fcil de mantener.

Una documentacin mejor organizada.

La norma IEC 61131-3 contiene conceptos y lenguajes de programacin muy potentes

a la hora de estructurar el software. Como ya se ha mencionado en el apartado anterior, en
el nivel ms alto, donde se definen las configuraciones (PLCs) y su conexin. En este punto
debe tenerse en cuenta que segn este estndar, un programa reside en un nico PLC, de
modo que debemos dividir el software de control, como mnimo, en tantos programas como
PLCs integren el sistema. Todos ellos trabajarn de forma conjunta, empleando algn
procedimiento de coordinacin, como seales de campo, variables de red, o mediante la
transmisin de mensajes. Estas dos ltimas opciones requieren, obviamente, buses de
comunicaciones.
Dentro de cada configuracin, el programa puede ser muy complejo, y por tanto debe
organizarse adecuadamente. El IEC 61131 posee un gran capacidad de organizacin que
se basa en la estructuracin y la descomposicin de un programa.

2.3.1

Estructuracin de un programa

Segn la norma 61131-3, un programa se define como una interconexin lgica de

unidades de programa (POUs) a la que se le asocia un modo de ejecucin (tarea). La figura
5, 6 muestra un ejemplo de esta filosofa. Las unidades de programa son trozos o pequeos
programas que resuelven una parte del problema. Su interconexin permite coordinar estos
subprogramas para resolver el problema al completo.

Ejemplo: Es muy habitual asignar unidades de programa a cada uno de los actuadores
del proceso que requieran cierta inteligencia en su control como motores, vlvulas
motorizadas, bombas centrfugas, cilindros neumticos, etc. Una bombilla, por ejemplo,
no requiere un bloque de programa.

Una POU puede programarse como una interconexin de unidades de programa ms

pequeos, estructurandose, de este modo, el cdigo de forma jerrquica. Uno de los
aspectos ms importantes de las POU son su interfase, es decir, los parmetros o datos a
P ag. 13

2. Modelo V de desarrollo Software

travs de los cuales el cdigo recibe o enva informacin. La funcionalidad de una unidad
de programa se especifica claramente definiendo su interfase y describiendo la funcin de
cada uno de sus parmetros.

Figura 5. Program a principal.

2.3.2

Descomposicin de un programa

IEC 61131-3 define 5 lenguajes de programacin distintos. Uno de ellos, el SFC

(Sequential Function Chart), se disea para descomponer un programa secuencial y
concurrente en un conjunto de operaciones ms sencillas. El SFC es un lenguaje grfico,
heredero del GRAFCET con el que puede describirse de forma relativamente sencilla
secuencias complejas de operaciones, secuencias independientes que se ejecutan de forma
paralela, o incluso pueden sincronizarse secuencias paralelas.
En el SFC de la figura 6, 7, pueden observarse las principales caractersticas de este
lenguaje. El SFC consta de etapas unidas mediante transiciones. Las etapas reflejan
estados particulares del sistema. Cada etapa tiene asociadas acciones que ejecutan cierta
funcin de control. Estas acciones pueden programarse en cualquiera de los lenguajes IEC
61131-3. Las transiciones poseen condiciones que controlan la evolucin de unas etapas
a otras. Las condiciones de transicin se programan normalmente empleando lenguaje de
contactos o de funciones.

Pag. 14

Metodologa de desarrollo software para autmatas programables

Figura 6. Lenguaje de program acin SFC

2.3.3

Descripcin funcional

Una vez definida la arquitectura del programa, debe realizarse una lista de todos los
bloques de accin y unidades de programa. Para cada uno de ellos se redactar una
descripcin funcional , que en trmicos genricos, indique la funcin que ejecuta en alguno
o varios de los siguientes mbitos: sobre los elementos del proceso, en el estado del
automatismo, o en la coordinacin del programa.

2.3.4

Ejemplo de arquitectura software de un programa dentro de una configuracin

La figura ? muestra el tanque de un proceso de fermentacin. Entre los parmetros a

controlar tenemos los siguientes:

El llenado y vaciado se realizan mediante las vlvulas correspondientes (feed,

harvest).

El pH se regula haciendo uso de aditivos cidos o alcalinos

La Temperatura, utilizando la resistencia calefactora.

La Agitacin, mediante un motor con control de velocidad.

P ag. 15

2. Modelo V de desarrollo Software

Figura 7. Proceso de ferm entacin

Muchas arquitecturas son posibles. Cada equipo de desarrollo puede seleccionar alguna
de las ms conocidas, o disear una nueva.
En la figura 8 hemos mostramos la arquitectura software propuesta por PLCOPEN,
organizacin que se dedica a promover el uso del estndar IEC 61131-3. En ella se observa
que el programa principal consta de mltiples POUs que controlan los diferentes actuadores
del sistema. A su vez, estas unidades de programa son gestionadas desde una POU
principal.
En muchas ocasiones es conveniente incluir tambin bloques especficos asociados a
los sensores con el objeto de procesar los datos, convertir formatos, filtrar informacin
errnea, detectar fallos, etc.
En nuestro ejemplo, la unidad de programa principal, se encarga de ejecutar el
funcionamiento normal de fermentacin. ste incluye varias fases, como inicializacin,
llenado, calentamiento, etc. Tambin deber comenzar la agitacin, y la regulacin del pH,
mantenindose la temperatura bajo control. Al final del proceso, se ejecutar el vaciado del
depsito.
El lenguaje SFC nos permite descomponer la secuencia de operaciones de forma
sencilla, rompiendo de este modo el cdigo en pequeos programas que se ejecutan desde
los bloques de accin.
Una vez finalizado el SFC principal, debern enumerarse las POUs necesarias para
implementar los bloques de accin y el control de los actuadores. Se indicar detalladamente
las funciones que debe desarrollar. En el ejemplo, la figura muestra claramente los bloques
necesarios, y del enunciado se deduce fcilmente la funcin de cada uno de dichos bloques.

Pag. 16

Metodologa de desarrollo software para autmatas programables

Figura 8.

P ag. 17

(A) Bloque de control del autom atism o.

(C) SFC del bloque MainSequence.
(D) Bloque de control de sensores

(B) Bloques de control de Actuadores

(D) POUs de los bloques de accin del SFC

2. Modelo V de desarrollo Software

2.3.5

Especificacin y diseo de un test de integracin

El objetivo principal de las pruebas en este punto es determinar que el funcionamiento

conjunto de las unidades de programa se corresponde con el deseado. En particular, los
test debern disearse para verificar la correcta eleccin y funcionamiento de las seales
que interconectan los bloques entre s.
Siguiendo el ejemplo de la arquitectura propuesta en la figura 8, y segn el modelo de
desarrollo en V, cuando se ejecuta este test, las unidades de programa de los bloques de
accin y de los elementos actuadores ya habran sido testados de forma individual. Se trata
ahora, por tanto, de probarlos conectados, tarea que podra ejecutarse, por ejemplo, con
los siguientes pasos:

Testar uno a uno la coordinacin entre las POUs de los bloques de accin y el SFC
principal.

Verificar que las POUs de accin funcionan correctamente cuando se detiene y se

reinicia su ejecucin como consecuencia del cambio de etapa del SFC..

Testar una a una la interconexin enter el Bloque de la secuencia principal y las

unidades de programa de los actuadores.

Testar el funcionamiento completo

2.4 Fase de Diseo de los Mdulos o Unidades de Programa

El diseo de una unidad de programa comienza por la definicin de sus interfases. Para
ello es necesario tener en cuenta que, en general podemos encontrar tres tipos de seales:

Seales de campo, que provienen directamente de los sensores o actuadores.

Seales de mando, de las que se reciben rdenes de los operadores (cuadros de

maniobra o SCADAs).

Seales de coordinacin entre diferentes POUs (indicaciones de fin de ejecucin de

un trabajo, errores, etc).

En la arquitectura software propuesta por PLCOpen (figura 8) puede observarse

fcilmente que existen dos tipos de unidades de programa (ver nota1):

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 contendrn fundamentalmente seales de campo ms

alguna de coordinacin que indique si la accin se ha ejecutado satisfactoriamente o si ha
producido algn error.
En los bloques para el control del automatismo y del estado del proceso, la mayor parte
de las seales que contienen son seales de coordinacin con otras unidades de programa,
y seales que se conectan a elementos de la consola de operacin, o variables del SCADA
(botones, selectores, sealizaciones luminosas, etc).

Esta divisin es muy general, y la encontraremos con facilidad en arquitecturas software distintas de la
mencionada. Es incluso recomendable para la reutilizacin del cdigo disear las POUs con esta filisofa, incluso para
arquitecturas software propias, diseadas de forma personalizada

Pag. 18

Metodologa de desarrollo software para autmatas programables

Al definir una seal deben establecerse tres puntos:

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

Mecanismo de sealizacin. Para seales de tipo binario, especialmente las de

coordinacin, debe decidirse entre tres formas de sealizacin:
-

Activas por nivel. La informacin se indica por el valor de la variable. P.e un

detector de fuego seala con un 0 la presencia de llamas. Hasta que se extinga
completamente el detector seguir dando ese valor.

Activas por flanco. Un cambio en el valor de la seal (de 0 a 1 en flancos

positivos, o de 1 a 0 en flancos negativos) indica la ocurrencia de un suceso que
debe ser conocida. P.e en estado normal un rel trmico ofrece un valor de 1. Si
se produce el sobrecalentamiento de un motor, el rel se abre y se lee como un
0. El fallo trmico se sealiza con un flanco negativo. Para que una seal de
flanco 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 seales, existe un
estado de reposo (0 1). Cuando se desea sealar un evento, la lnea cambia
de estado, aunque ese cambio es temporal, ya que retorna al estado de reposo
transcurrido un cierto tiempo (pulso).

Terminada la interfase, la funcin que debe ejecutar la POU debe definirse con claridad
traduciendo la descripcin funcional, que se hizo en la fase de diseo de la arquitectura
(funcin general) a otra ms tecnolgica, empleando trminos que incluyan las seales de
su interfase. Por ejemplo, en lugar de decir abre la vlvula de vaciado, diremos activa (pon
a 1) la salida AbrirValvula.

2.4.1

Diseo de un test para los mdulos

Para cada una de las unidades de programa desarrolladas se disear un test que
permita validar la funcionalidad de las POUs comenzando por las ms simples, en el sentido
de que no emplean dentro de su cdigo otras POUs que deban ser testadas. S podran
contener POUs de sistema, libreras estndar, o libreras del propio equipo de desarrollo que
ya han sido suficientemente probadas y utilizadas.
Los test ms bsicos son de tipo esttico. El comportamiento del programa se verifica
forzando el cambio en alguna variable de entrada de su interfase. Este procedimiento puede
ejecutarse desde el entorno de programacin empleando un simulador del autmata sobre
el que forzamos su E/S de forma manual (figura 9, 10a). Para efectuar todo este proceso
sobre un PLC real, hay que asegurarse de que ste no est operando sobre el proceso (fig.
9, 10b).
Ms complejos son los test dinmicos, donde se generan patrones de prueba a modo
de secuencia temporal de cambios que afectan a distintas entradas de forma simultnea.
El resultado del test se obtiene del anlisis de la evolucin temporal de las salidas, y de los
cambios de estado de la unidad de programa (estado que se almacenada en sus variables
internas). Este tipo de ensayos pueden ser muy complejos, por lo que en muchas ocasiones,
es necesario ejecutarlos mediante simulaciones, o desarrollando una unidad de programa
especfica que genere esos patrones de prueba. En las figuras ?a y ?b se muestran ambas
filosofas:
Si se ha seguido un procedimiento de diseo del correcto, en este punto, las unidades
de programa deben ser muy pequeas, con pocas entradas y salidas. En este caso, la
realizacin de los ensayos es mucho ms sencilla a la vez que fiable, e incluso en algunos
casos, los test se pueden llevar a cabo dentro del entorno de programacin, sin simuladores
P ag. 19

2. Modelo V de desarrollo Software

ni programas adicionales. Esta ltima, es la forma ms bsica de ejecucin de los test. Para
ensayos ms complejos se requieren tambin arquitecturas tambin ms complejas,
empleando simuladores externos, mediante procedimientos de ensayo en fbrica, e incluso
integrando la simulacin con el proceso real con el objetivo de entrenar a los operadores.

Figura 9. Test m anual desde el entorno de program acin:

(a) con sim ulador, (b) con PLC

Figura 10. Test m anual desde el entorno de program acin: (a) con
sim ulador, (b) con PLC
Pag. 20

Metodologa de desarrollo software para autmatas programables

2.5 Fase de Codificacin (programacin)

En esta fase, se desarrolla el cdigo en alguno de los lenguajes estndar o se modifican
programas ya existentes. La mejor opcin en este caso es la reutilizacin de cdigo, es
decir, emplear programas ya utilizados en otros proyectos, y por tanto ya testados. Esto
ahorra tiempo y costes de desarrollo y validacin. En segundo lugar, la modificacin de
programa ya existentes es una opcin vlida si se trata tan slo de pequeas
modificaciones, aadir una o dos seales, o modificar una o dos de las existentes, etc. Si
los cambios son amplios, es recomendable desarrollar un nuevo programa.
El estilo de programacin es tambin importante. El cdigo debe ser legible. Cualquier
miembro del equipo debe ser capaz de comprenderlo, partiendo de las especificaciones del
mdulo, simplemente leyendo el programa. Para lograrlo deben seguirse al menos las
siguientes recomendaciones:
-

Declarar las variables internas con nombres que reflejen el significado de la

informacin que contienen. P.e en lugar de v1" utilizar falloTermico o
sobrecalentamiento.

En la mayora de los casos, es mejor emplear lgica positiva en las variables

binarias. Siguiendo el ejemplo anterior, esto significa que cuando se produce un
sobrecalentamiento, la variable sobrecalentamiento est en 1.**

Deben comentarse todas, o la mayora de las lneas de programa, explicando lo que

se pretende hacer empleando los nombres de variables internas o de la interfase,
nunca en trminos del elementos de proceso.

No emplear NUNCA variables globales. De otro modo el cdigo podra no ser

reutilizable.

El lenguaje de programacin debe escogerse en relacin con la funcionalidad del

programa y los conocimientos del programador. Por ejemplo:

P ag. 21

LADDER - Es el ms empleado. Muy adecuado para programas con pocas

seales y pocas variables internas.

FUNCIONES - Muy adecuado para estructurar cualquier unidad de programa

compuesto de otras POUs ms pequeas que se ejecutan de forma
concurrente (simultnea y coordinada). P.e. el programa principal de muchas
arquitecturas (PLCOPEN).

SFC - Adecuado para descomponer programas con complejas secuencias

de operacin. P.e para desarrollar los modos GEMMMA del automatismo.

INSTRUCCIONES - Adecuado para desarrollar cdigo muy compacto y

rpido de ejecucin, o donde conocer el tiempo de ejecucin de las
instrucciones pueder ser importante. P.e en la gestin de alarmas. Es un
lenguaje similar al ensamblador que requiere conocimientos muy
especializados. No est muy extendido.

TEXTO ESTRUCTURADO. Similar al PASCAL. Es adecuado para programar

algoritmos matemticos de todo tipo. Simples, como un comparador con
histresis, o complejos como un algoritmo de regulacin PID.

3. Referencias
Automatizacin de procesos mediante la Gua GEMMA.
Ponsa Asensio, Vilanova Arbs. Ed. Ediciones UPC. 2005. (Pag. 22)
GEMMA, Guide d'Etude des Modes de Marches et d'Arrets
Production Automatisme, ADEPA, 1981. (Pag. 22)
[1] Automatizacin de procesos mediante la Gua GEMMA.
Ponsa Asensio, Vilanova Arbs. Ed. Ediciones UPC. 2005.
GEMMA, Guide d'Etude des Modes de Marches et d'Arrets
Production Automatisme, ADEPA, 1981.

Pag. 22

Metodologa de desarrollo software para autmatas programables

Lista de Figuras
Figura 1. Modelo V de desarrollo software
Figura 2. Ejemplo de gua GEMMA
Figura 3. Estructuras de control
Figura 4. Programa principal.
Figura 5. Programa principal.
Figura 6. Lenguaje de programacin SFC
Figura 7. Proceso de fermentacin
Figura 8. (A) Bloque de control del automatismo. (B) Bloques de control de Actuadores
(C) SFC del bloque MainSequence.
(D) POUs de bloques de accin del SFC
(D) Bloques de control de sensores
Figura 9. Test manual desde el entorno de programacin: (a) con simulador, (b) con PLC
Figura 10. Test manual desde el entorno de programacin: (a) con simulador, (b) con PLC

P ag. 23