Programación Orientada a Objetos (POO) en TIA Portal

Antes de comenzar, es importante destacar que la programación orientada a objetos en TIA Portal  es incompleta y rudimentaria si bien tiene algunas características de este paradigma de programación.

En este artículo, nos centraremos en la implementación de la Programación Orientada a Objetos (OOP en inglés) en los PLC y analizaremos qué partes están disponibles en TIA Portal y cuáles no.

Es importante señalar que nos enfocaremos exclusivamente en los PLC, ya que la aproximación a la POO puede variar en otros componentes y dispositivos.

 

¿Qué es la Programación Orientada a Objetos?

La POO, en términos generales, es un paradigma de programación que se basa en la creación y manipulación de objetos y clases. La idea detrás de este paradigma es que la programación se asemeje a la realidad, donde existen objetos y entidades con características y propiedades únicas, como por ejemplo coches, personas o gatitos adorables.

¿Qué es un objeto?

Un objeto será un ente con identidad propia que se distingue del resto de objetos por sus características y métodos.

Cada objeto, tendrá una serie de características o atributos (color de pelo, altura, peso, nombre..) y una serie de métodos (funciones) que pueden realizar (andar, correr, mirar, hablar, saltar…)

Así, si tienes dos gatos y un perro en casa, cada uno de ellos tendrá su propia identidad y serán un objeto dentro de este paradigma.

Llevándolo a las personas, podremos tener dos gemelos  y decir ¡¡pero si son iguales!!

Son casi iguales, porque habrá pequeñas diferencias entre ellos, y en cualquier caso, siempre tendrán un atributo que será diferente y que los distinga entre sí como es el nombre de cada gemelo.

Hasta ahí, espero que todo el mundo entienda el concepto de objeto.

Ahora bien…

¿Qué es una clase?

Una clase será la plantilla que define un tipo de objeto. Así, tendremos la clase gato, donde podremos meter todas los atributos y métodos que tienen estos animalillos que a veces dejan que vivas con ellos. Pero sería solo la descripción genérica de lo que es un gato, no de uno en particular. Es decir, tendrá atributo peso o raza, pero sin entrar en el valor de dichos atributos.

Con esta plantilla se obtendrán todos los objetos de la clase gato, independientemente de sus atributos y diferencias en los métodos.

Para crear los objetos en POO lo que haces es crear una instancia de la clase para obtener un nuevo objeto.

Esto casi lo vemos mejor aplicado a TIA Portal.

¿Y cómo se traslada las clases y objetos a TIA Portal?

Dentro de Siemens, tienes el bloque FB.

Este bloque como bien sabes trae consigo un DB donde se almacena los valores de las variables estáticas que se necesitan para un buen funcionamiento del programa.

Bien, pues si usas bien los FB, este FB será la clase, y cada llamada que hagas al FB será la instancia de esa clase, y por tanto un nuevo objeto que vendrá diferenciado por un DB diferente.

Por ejemplo, en TIA Portal tienes FB que usas normalmente tal vez sin caen en la cuenta que son FB y por tanto clases. Por ejemplo: los temporizadores IEC.

Así, cuando arrastras el bloque de un TON no estás mas que usando la clase TON para crear un nuevo temporizador con retardo a la conexión. Pero cada vez que lo arrastras, usas un nuevo DB o en el caso de estar dentro de otro FB de un área diferente dentro de las estáticas para cara TON que uses (lo que se llama multiinstancia).

Bien, esto es el concepto de clase (la caja de TON que arrastras) y cada objeto es el TON que programas con su tiempo de disparo y su DB asociado .

Luego por este lado, está claro que TIA Portal y Siemens en general sí cumple con una parte de lo necesario para una POO más o menos completa.

Ahora bien ¿Qué hay del resto de los pilares de la POO?

Los pilares de la programación orientada a objetos en TIA Portal

Además de las clases y objetos, podemos hablar que hay cuatro pilares fundamentales en la programación orientada a objetos como son:

• Abstracción
• Encapsulamiento
• Polimorfismo
• Herencia

Abstracción

La abstracción podríamos definirlo como quedarse con lo esencial dejando el restos de detalles que no son necesarios.

En programación cuando generes una clase para generar objetos, estos seguramente tendrán un montón de características que para ti no son necesarias, y por tanto, tan solo te quedas con lo esencial de ello con lo que vas a trabajar.

Abstacción en TIA Portal

En el caso de TIA Portal, podremos crear un FB que represente la clase transportador en la que programemos una tipología de transportador sin tener en cuenta cosas como de qué material está realizado o qué altura tiene, si esto no es relevante para el manejo de este.

Luego la abstracción sí podemos usarla en la programación de autómatas de Siemens a la hora de crear clases sin mayores problemas.

Encapsulamiento

El encapsulamiento trata de que la forma de modificar los datos de nuestras clases y objetos sea de una forma determinada. Que no se pueda acceder a ellos de cualquier forma, sino haciendo una petición mediante métodos determinados.

Esto en TIA Portal empieza a ser un poco más rebuscado, ya que no es aplicable tan sencillo como lo puedes hacer en lenguajes de alto nivel modernos y orientados a objetos como puedan ser cualquier .net o Python, por ejemplo.

En estos lenguajes la forma de trabajar con encapsulamiento sería la siguiente.

Imagina que tienes una propiedad llamada «altura».

Bien, esta propiedad al ser encapsulada no sería pública ni accesible desde fuera de la clase. Solo mediante dos métodos podrías recuperar su valor y por otro lado, fijar uno nuevo.

De esta forma, al hacer un get_altura() recuperarías el valor de dicha altura e invocando set_altura(200) podrías fijar la altura en 200mm  (por ejemplo).

Podrías decir, ¿y que diferencia hay con leer o escribir sobre la propiedad altura directamente ?

Pues muy sencillo: el control de lo que se está haciendo.

Al invocar los métodos, lo que estamos haciendo es ejecutar una función que nos devolverá la atura o fijará esta.

En el caso de fijar la altura directamente no podemos controlar que el valor no supere los 250 o que no tenga valores negativos que harían por ejemplo que el programa dejara de funcionar.

Por tanto, al hacer un set_altura(200) podemos controlar el valor pasado como parámetro para comprobar si está dentro de estos límites antes de fijar el nuevo valor, limitarlo en caso de que los supere, ignoralo, etc.

También cabría la posibilidad de realizar otras operaciones como refresco o actualizaciones de otras propiedades que a su vez, tienen que cambiar al hacerlo la altura o ejecutar ciertos métodos.

En definitiva da control sobre la interacción de la clase y por tanto sobre los objetos.

Encapsulamiento en TIA Portal

Lo que más se acerca a acceder a los datos de una forma ordenada conocida es el uso de los UDT ya que te obliga y facilita a la vez, el acceso a los datos de una instancia en concreto.

Así, si dentro de un FB que representa un variador, y dentro de este creamos un UDT con todos los fallos posibles que puede tener, podemos acceder desde fuera a su estado mediante algo similar a «Variador 1».Alarmas.Sobrecorriente.

Lo mismo si quisiéramos darle un valor a uno de los atributos de una forma externa. Lo suyo sería usar UDT en la medida de lo posible para juntar las características que se puedan aunar bajo un mismo grupo lógico.

Esto facilitará el que tengamos nombres de variables que puedan ser parecidas o iguales, pero que no signifique lo mismo y por tanto, no lleven a equivocación, que es de lo que se trata.

Así por ejemplo podremos tener:

• «Variador 1».Mando.Marcha
• «Variador 1».Alarmas.Marcha

De esta forma, a pesar de poderse llamar igual, queda claro que al pertenecer a UDT diferentes (mando y alarmas),  cada una significará una cosa diferente y quedará claro a la hora de acceder a la que necesites, el grupo al que debes hacer referencia.

Pero como digo, eso no es encapsulamiento, si bien tiene la característica de acceder de forma ordenada y clara a los datos de un objeto. Pero hasta ahí.

Herencia

La herencia es otra de las características de POO que en TIA Portal podemos decir que no existe como tal.

En los lenguajes orientados a objetos la herencia de una clase es crear una clase derivada de la primera donde hereda todas los atributos y métodos de la clase base.

Por ejemplo, tenemos la «clase animales de 4 patas», y de ahí podemos crear una clase perro que herede de la clase «animales de 4 patas» y la clase elefante, que también hereda de la misma clase base, pero que va a tener otras características y métodos diferentes a la clase perro.

Otro ejemplo podría ser la clase vehículo, y de ahí que hereden la clase coche o la clase bicicleta.

Así pues, la clase vehículo puede tener atributos como color, número de ruedas, o peso, y métodos como correr que compartirá con sus clases heredadas.

Por su parte la clase coche tendrá atributos como cilindrada o tipo de combustible que no tendrá la bicicleta, y esta tendrá características como número de piñones o de platos que no tendrá el coche, pero ambas compartirán como digo, características como el número de ruedas o el peso.

Herencia en TIA Portal

En TIA Portal esto no existe como tal. No puedes crear un FB y crear otro FB que beba del FB anterior.

El concepto no es lo mismo que la multiinstancia que es crear una clase (FB) que contenga otras clases (otros FB).

Se parece en algunos aspectos, pero no es el concepto de herencia.

En el caso de los UDT, tampoco puedes heredar como tal. Es decir, no puedes crear un UDT que sea hijo de otro UDT al que le añadas atributos. Lo que sí puedes hacer es crear un UDT que contengan otros UDT, pero eso no es el concepto de herencia.

La forma de trabajar en estos casos será dividir el programa en diferentes FB y UDT de tal forma que crees tus clases uniendo diferentes UDT/FB bajo un mismo paraguas.

Es lo más cercano que vamos a tener a la herencia, pero sin serlo.

Polimorfismo

En la programación orientada a objetos, el polimorfismo se refiere a la capacidad de los objetos de una misma clase para tomar formas diferentes y ejecutar diferentes comportamientos en función del contexto en el que se encuentren.

Esto significa que, aunque dos objetos pueden ser de la misma clase, pueden actuar de manera diferente según el método que se esté llamando y los parámetros que se le pasen.

El polimorfismo es una herramienta poderosa en la POO porque permite escribir código más genérico y reutilizable, lo que a su vez hace que el desarrollo de software sea más eficiente y escalable.

Polimorfismo en TIA Portal

Esto sí puedes hacerlo en TIA Portal en parte.

Por ejemplo, podrás hacer que en función de la longitud de una pieza, esta sea centrada en mitad de una mesa, o que si supera determinado tamaño, el centrado no es necesario y por tanto, una vez entre, se de por centrada, sin realmente estarlo.

O que dos transportadores iguales, se comporten en cuanto a velocidades de forma diferente en función de la posición dentro de la línea: ambos echaran a andar, pero las aceleraciones y velocidades pueden ser diferentes en función de su posición en la línea o la tipología de la pieza que llevan encima.

Eso es polimorfismo: tener un método común que se comporta de forma diferente en función del contexto del objeto.

Por tanto, sí es aplicable en gran medida.

Lo que no es aplicable dentro del polimorfismo que los lenguajes orientados a objetos permiten es la sobrecarga para lograr este polimorfismo.

Es decir, dentro del ejemplo vehículos, podemos tener el método «mover» en el que tanto el coche como la bici andan hacia delante.

Pero ese método mover descrito en la clase vehículo puede ser «sobrescrito» si fuera necesario por la clase hijo para que cada uno de estas clases heredadas hagan cosas diferentes ante la petición de andar.

Debido a que no existe la herencia, tampoco podemos pedir la sobrecarga de métodos en TIA Portal.

Pero sí podemos programar para que los objetos de una clase se comporten de forma diferente, por lo que se cumple parcialmente.

Resumen de la programación Orientada a Objetos

No, TIA Portal no tiene ningún lenguaje orientado a objetos. Incluido SCL que no deja de ser Pascal, un lenguaje estructurado, no orientado a objetos.

Pero hay que decir, que la aproximación existente es más que suficiente para una buena programación de las líneas de producción.

Un PLC y una máquina, no es una página web o una aplicación de móvil.

Tiene sus características y realidades que superan con mucho a lo que te puedes encontrar en una aplicación de escritorio por lo que no se puede pretender trabajar igual que si estuvieras desarrollando la web de la empresa. Las cosas no funcionan como quisiéramos.

No he conocido a nadie de mantenimiento que se queje de la falta de POO en los PLC de Siemens.  Estos son quienes pone en marcha de nuevo la máquina cuando se avería o para y están día tras día con las máquinas cuando los programadores han vuelto a su país hace varios años.

No cabe duda que la industria tiende a que cada vez haya más datos en los procesos de las máquinas. Aquí es donde sí puede crecer y desarrollarse mejor la programación orientada a objetos, pero en el tema de lógica de programa, tal vez con lo que se tiene hoy en día, y por mucho tiempo, sea más que suficiente.

Y con esto no quiero decir que esté en contra de la programación orientada a objetos, ni mucho menos, sino que las líneas de producción son otra cosa, donde los datos no son lo más importante sino parte del invento, y que la lógica del programa es la que hace funcionar todo, y esto, no siempre es instanciable.

Si quieres saber más sobre este paradigma de programación tienes referencias como estas:

• https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos
• https://www.ibm.com/docs/es/spss-modeler/saas?topic=language-object-oriented-programming

¿Qué te ha parecido?

¿Te interesa darle un enfoque de programación orientada a objetos a tus creaciones con los PLC de Siemens? ¿Ya se lo das? ¿Te gustaría aprender más sobre ello y que creara algún pequeño curso sobre ello que añadir al catálogo de cursos?

Espero tus cometarios.