Lenguajes de programación PLC

El estándar IEC-61131

Los lenguajes de programación de PLCs habituales (IL, ST, FBD, LD, SCL) se regulan por la norma IEC-61131-3. Esta norma fue establecida por la Comisión Electrotécnica Internacional (IEC) en la década de los sesenta con el objetivo de estandarizar el mercado de los autómatas programables.

Los lenguajes que regula la norma se dividen en:

Lenguajes literales o textuales: Las instrucciones están formadas por letras, símbolos o números.

• Lista de instrucciones (IL): Es un lenguaje de bajo nivel, tipo ensamblador, que permite crear programas de usuario propios de hardware y con optimización de tiempo de ejecución y espacio de almacenamiento.

• Texto estructurado (ST): Se trata de un lenguaje de alto nivel que permite programación estructurada (división de tareas), facilitando la programación de procesos que requieren instrucciones complejas o grandes cálculos.

Lenguajes gráficos: Las instrucciones se representan por esquemas o figuras. 

• Esquema de contactos (LD): El lenguaje utiliza una representación gráfica de los esquemas eléctricos de control tradicionales. Es el lenguaje de programación de PLCs más utilizado. 

• Diagrama de funciones (FBD): Se trata de un lenguaje formado por un conjunto de bloques lógicos que se interconectan en cascada de forma similar a como se hace en electrónica digital. 

Lenguajes orientados a objetos: 

• Diagrama funcional de secuencias (SFC): Este lenguaje, sustituto del GRAFCET, permite representar el desarrollo en el tiempo de las distintas acciones de un proceso, describiéndolo con secuencias de pasos alternativas o paralelas. Se emplea frecuentemente en el diseño de sistemas secuenciales, donde las acciones se ejecutan en orden conforme se cumplen ciertas condiciones.

Los entornos de programación de origen alemán, como STEP7 de Siemens, utilizan las siglas en este idioma. La equivalencia es la siguiente:

FUP	FBD
KOP	LD
AWL	IL
SCL	ST
GRAPH	SFC

     

¿Y qué hay del lenguaje CFC?

El lenguaje CFC (Continuous Function Chart) es una extensión no estandarizada del lenguaje FBD.

Es también un lenguaje gráfico, muy similar al empleado en diagramas de electrónica digital en el que se interconectan elementos como bloques, entradas, salidas, etiquetas, etc. 

Su principal ventaja radica en su fácil programación. Existen una serie de bloques predefinidos que pueden ser arrastrados y colocados para posteriormente configurarlos e interconectarlos rápidamente. Por tanto, debido a su naturaleza intuitiva, no requiere de amplia experiencia en programación.

Sin embargo, uno de sus principales inconvenientes es que en programas que requieran un gran número de variables E/S o bucles, la legibilidad puede verse muy comprometida, dificultando así la labor de mantenimiento.

Se trata de un lenguaje de gran utilidad para aplicaciones con funciones aritméticas, lógica combinacional y cálculos sencillos, pero no muy eficaz para lógica secuencial.

¿Qué lenguaje usar?

La respuesta a esta pregunta no es fácil de formular, puesto que depende de muchos factores. Sin embargo, para tomar una buena decisión es necesario tener en cuenta, al menos, los siguientes puntos:

- El tipo de aplicación y su complejidad.

- Los requisitos y prácticas del cliente final y de su departamento de mantenimiento.
- El tiempo de implementación del proyecto.
- Seguimiento del proyecto.
- PLC y entorno de programación.
- Aceptación universal del lenguaje.
- Facilidad de portabilidad.
- Facilidad de aprendizaje.

La siguiente tabla recoge algunos de los puntos fuertes y débiles de cada lenguaje (aunque quizá de una forma algo subjetiva):

LENGUAJE	PUNTOS FUERTES	PUNTOS DÉBILES
LD	- Popular en el mundo de la automatización. - Funciones binarias y booleanas. Procesado rápido. - Fácil integración de bloques funcionales estándar. - Programación visual y fácil de interpretar. - Fácil de modificar.	- Cálculos matemáticos. - Procesamiento de datos (cadena de caracteres, E/S analógicas, rutinas de comunicación). - Bucles e instrucciones de repetición. - Lógica secuencial con gran número de secuencias. - Creación de bloques funcionales de usuario con gran número de variables.
FBD	- Funciones booleanas. - Cálculos matemáticos simples. - Procesamiento de datos analógicos. - Fácil integración de bloques funcionales - estándar. - Programación visual y fácil de interpretar.	- Lógica secuencial con gran número de secuencias. - Bucles e instrucciones de repetición. - Creación de bloques funcionales de usuario con gran número de variables. - Modificación del programa. - Seguimiento e interpretación en programas complejos.
IL	- Codificación rápida y simple introducción de datos. - Código compacto. - Rápido procesamiento y velocidad de ejecución (ciclos optimizados). - Bucles, instrucciones de repetición y saltos. - Lógica secuencial simple. - Representación ordenada. - Portabilidad, transferible a otras plataformas.	- Lógica combinacional compleja. - Cálculos matemáticos y procesamiento de datos. - Difícil seguimiento posterior (interpretación, comprensión y modificación). - Interpretación por usuarios inexpertos.
ST	- Codificación rápida y simple introducción de datos. - Programación estructurada similar a lenguajes de alto nivel de programación de PCs. - Código compacto y buena velocidad de ejecución. - Cálculos matemáticos y procesamiento de datos. - Bucles e instrucciones de repetición. - Fácil de usar y rápida asimilación por nuevos usuarios. - Creación de bloques funcionales de usuario con gran número de variables. - Portabilidad a otras plataformas.	- Lógica combinacional con una cantidad significante de variables. - Requiere mayor habilidad de programación. - Carencia de instrucciones de salto. - Peligro de bucles grandes o infinitos (error de perro guardián). - Visualización e interpretación en caso de programas complejos con gran número de variables. - Modificaciones en el programa.
SFC	- Fácil realización de aplicaciones secuenciales y tareas repetitivas. - Representación clara y precisa de las secuencias. - Incorporación de secuencias complejas (ej. GEMMA). - Mantenimiento fácil por el usuario final. - Documentación de ayuda del proyecto.	- Difícil introducción de datos y programación (gráficos, acciones, transiciones). - No puede traducirse a otros lenguajes estándar. - No es totalmente compatible con GRAFCET. - Requiere más recursos.

Por último, un gráfico orientativo que muestra el potencial de cada lenguaje según la fase del proyecto:

Última actualización: 10/06/2015

Categories: lenguajes, PLC

PLC o DCS, ¿qué necesito?

Recientemente, con la tendencia a una manufactura más flexible, muchas de las aplicaciones en la industria de procesos ahora comparten los requisitos que tradicionalmente eran exclusivos del DCS (Distributed Control System) o del PLC (Programable Logic Controller). Esta convergencia entre PLC y DCS dificulta en gran medida la elección de la tecnología adecuada. En esta entrada dejaremos de lado algunos de los viejos estereotipos de ambas tecnologías y plantearemos una serie de preguntas que nos ayudarán a tomar la decisión adecuada. Para ello, debemos tener previamente un panorama claro de los requisitos de nuestra aplicación y de las necesidades de nuestro personal de ingeniería, mantenimiento y operaciones.


Las 7 preguntas clave

A continuación analizaremos las siete preguntas que debemos hacernos antes de elegir un sistema. Debemos tener en cuenta que en este análisis haremos ciertas generalizaciones y que cada aplicación individual siempre presenta ciertas excepciones a estas "reglas".

1. ¿Qué se está manufacturando? ¿Cómo?

En procesos que puedan involucrar una o varias máquinas, así como una gran cantidad de paso de materiales de una máquina a otra, como puede ser en la fabricación y/o montaje de ítems específicos, se requiere un control lógico exhaustivo y de alta velocidad. En este tipo de procesos, el control se realiza a través de una combinación PLC – HMI, y se caracteriza porque el operario puede monitorear los ítems a medida que avanza en la línea de producción.

Por otro lado, en aplicaciones de automatización de procesos en las que se produce una transformación de la materia prima a través de reacciones químicas o cambios físicos para formar nuevos productos, suele haber una gran cantidad de controles analógicos simples y complejos (control PID o de lazo). Este tipo de procesos a menudo es controlado mediante un DCS y se caracterizan porque el operario no puede ver el producto (materia).

Finalmente, en el caso de necesitarse un control secuencial o por lote, los PLC se utilizan eficientemente para aplicaciones de lotes simples, mientras que los DCS se suelen dejar para instalaciones de fabricación compleja por lotes en los que se requiere un alto grado de flexibilidad y la gestión de recetas.

2. ¿Cuál es el valor del producto que se manufactura y el costo del tiempo de parada?

Si el valor de cada producto independiente que se manufactura es relativamente bajo, y/o si sus tiempos de parada (mantenimiento, resolución de problemas, mejoras) generan pérdidas de producción, pero con un mínimo costo adicional o daño al proceso, el PLC es la mejor opción. Si por el contrario el valor de un lote es alto, ya sea en costo de materia prima o en valor de mercado, y el tiempo de parada no sólo genera una pérdida de producción sino además condiciones peligrosas y dañinas, la opción más adecuada es la del DCS.

Por ejemplo, en aplicaciones que funcionan las 24 horas del día, los 365 días del año, el tiempo de parada es algo que se intentará evitar a toda costa. En estos casos, el dinero no es el único factor determinante; el peligro que supone los tiempos de parada son indudablemente otro factor que debe considerarse en el proceso de selección. Los sistemas DCS por lo general incluyen redundancia operativa, por lo que probablemente justifique la inversión inicial adicional para este tipo de aplicaciones.

3. ¿Cuál es el "núcleo" del sistema?

Habitualmente el núcleo de un sistema de control de automatización es el controlador (PLC), que contiene la lógica necesaria para mover el producto a lo largo de la línea de producción. El HMI (Human-Machine Interface) es a menudo un panel integrado en la máquina o una estación basada en PC que provee al operario datos complementarios.

Por el contrario, en la automatización de procesos donde el entorno puede resultar volátil o peligroso, y en los que los operarios no pueden ver el producto, el HMI puede ser considerado para muchos el núcleo del sistema. En este caso, el HMI es una consola en la sala de control que ofrece una visión completa del proceso y permite al operario monitorear y controlar los procesos que ocurren en la planta. Bajo estas circunstancias, el sistema de control típico es el DCS.

4. ¿Qué necesita el operario para lograr sus objetivos?

En un entorno de PLC, el rol principal del operario es manejar excepciones. La información sobre el estado del sistema y las alarmas en casos de excepción ayudan al operario a estar consciente de lo que está ocurriendo en el proceso, que en muchos casos, puede generar una interrupción total.

Por otro lado, una planta con un DCS necesita que un operario tome decisiones e interactúe continuamente con el proceso para mantenerlo en funcionamiento. De hecho, el conocimiento del operario acerca del proceso es muchas veces crítico para mantener el proceso en condiciones óptimas. El rol del operario es entonces el de ajustar el proceso para adaptarlo a los cambios en el entorno de producción (como puede ser un cambio en la materia prima), modificando los puntos de ajuste, abriendo o cerrando válvulas o realizando acciones manuales para que un lote avance al siguiente paso en la producción.

Respecto al HMI, los paneles ofrecen una visión crítica de lo que ocurre realmente en la producción, mientras que el sistema de gestión de alarmas concentra la atención del operario en las áreas donde debe intervenir para mantener el proceso en funcionamiento. En el caso de una falla del HMI, se puede forzar una detención de la planta para proteger a los empleados y a los equipos.

En definitiva, se trata de determinar si el operario está dentro o fuera del lazo de control. El operario de una planta con DCS es el actor fundamental del sistema, cuyos aportes en el diseño inicial de la HMI son esenciales para el éxito de todo el proyecto.

5. ¿Qué rendimiento se espera del sistema?

Otro factor clave a la hora de elegir entre uno u otro es la velocidad de ejecución del sistema. El PLC fue diseñado para cubrir las demandas de aplicaciones de alta velocidad que requieren ciclos de lectura de 10 milisegundos o incluso menos, incluyendo operaciones de control de movimiento o control de motores y servos. Se requiere por tanto una frecuencia de lectura alta para controlar eficientemente estos dispositivos.

Los DCS por lo general no necesitan ser tan rápidos, ya que la regulación de los lazos de control se realiza normalmente dentro del rango de 100 a 500 milisegundos. En algunos casos, puede ser contraproducente exigir que la lógica de control se ejecute más rápido, ya que generaría un desgaste excesivo en los elementos de control finales tales como válvulas, que generaría a su vez, un mantenimiento prematuro e inconvenientes en el proceso.

En cuanto a la redundancia, ésta puede ser de gran valor en el caso de un sistema DCS, mientras que en un sistema PLC, el sobrecoste que conlleva la redundancia normalmente no está justificado.

Otro aspecto a tener en cuenta es el impacto que supone la desconexión puntual del sistema. En el caso de un sistema PLC, la desconexión para realizar cambios en la configuración o en el programa no supone un gran impacto, ya que el programa no se ejecuta continuamente o porque el proceso puede reiniciarse con facilidad. No ocurre lo mismo en un sistema DCS, ya que los cambios en la configuración y los pequeños ajustes se realizan en caliente o online, es decir, sin detener el proceso.

Por último, aunque actualmente los PLC son aptos para el control analógico y cada vez más capaces de realizar un control PID, tanto simple como complejo, el DCS sigue siendo claramente la opción más adecuada para aplicaciones avanzadas de control analógico, tales como lazos en cascada, control predictivo o lazos de prealimentación.

6. ¿Qué grado de personalización se necesita?

Las expectativas y el deseo de poder crear una aplicación personalizada varían entre los usuarios de DCS y PLC.

El PLC brinda un kit de funciones y bloques esenciales que se adaptan a medida y se enlazan para cubrir los requisitos de una aplicación. El sistema permite la integración de funciones en una arquitectura bien definida. Además, también hay disponible lenguajes de programación para facilitar la creación de códigos personalizados desde cero.

Por otro lado, las aplicaciones de DCS suelen estar basadas en estándares, plantillas y extensas bibliotecas, en la que la mayor prioridad es ofrecer fiabilidad y disponibilidad a cambio de una funcionalidad limitada. La principal desventaja de un DCS es su incapacidad para aceptar modificaciones sin crear problemas de incompatibilidad.

7. ¿Qué expectativas de ingeniería se tiene?

Las herramientas que provee un PLC normalmente están optimizadas para brindar un enfoque de ingeniería ascendente que funciona bien para aplicaciones más pequeñas, mientras que las de los DCS tienen un enfoque de ingeniería descendente, que obliga a los ingenieros a invertir mucho esfuerzo en el diseño inicial.

Por otra parte, un programador de PLCs suele exigir cierta flexibilidad a la hora de usar uno u otro lenguaje de programación y una arquitectura más abierta, mientras que los ingenieros de procesos que controlan plantas enteras con DCS necesitan plataformas de programación más intuitivas, con funciones predefinidas y ya verificadas para ahorrar tiempo y evitar la repetición de tareas.

Contar con la herramienta adecuada para la tarea también es fundamental. El diagrama de contactos es el lenguaje preferido para muchas aplicaciones de control discretas tales como enclavamientos a alta velocidad o control de motores. Por otro lado, los lenguajes basados en bloques de funciones son los de mayor interés para el control continuo y la implementación de esquemas de alarmas.



Para facilitarnos aún más la tarea de determinar qué sistema funciona mejor en nuestra aplicación, Siemens proporciona esta plantilla con una lista de verificación en la que podremos ir marcando las respuestas a éstas preguntas. Si todas las respuestas están en una de las columnas, entonces nuestra aplicación requerirá claramente este tipo de sistema. Una vez que hemos revisado los criterios clave para la selección de un PLC o DCS, tal vez podamos pensar que nuestra aplicación requiera la capacidad de ambos. Si esto es así, entonces necesitamos un sistema de control de procesos para aplicaciones híbridas que combine las funcionalidades de cada uno. Próximamente, en otra entrada veremos qué es un "híbrido" y cuáles son los requerimientos clave de su sistema de control.

Última actualización: 10/06/2015

Categories: DCS, PLC