La programación orientada a objetos (OOP) es un concepto diseñado para facilitar el desarrollo de sistemas complejos mediante la introducción de nuevos conceptos que están más cerca del mundo real que los lenguajes de programación funcionales y de procedimiento. Como escribe Wikipedia, "El lenguaje humano ordinario en su conjunto refleja la ideología de OOP, comenzando por encapsular la idea de un objeto en la forma de su nombre y terminando con el polimorfismo de usar la palabra en un sentido figurado, que en última instancia desarrolla la expresión de la representación a través del nombre del objeto en un concepto completo - clase".
Pero desde el punto de vista de todos los que se encontraron por primera vez con estas abstracciones, después de los lenguajes de procedimiento clásicos no se hizo más claro, por el contrario, parece aún más confuso.
Por otro lado, hay anotaciones gráficas del programa que no están cerca del lenguaje humano, pero son mucho más comprensibles que cualquier código, no como OOP. Es posible que esto sea más claro para mí, estropeado por una educación en ingeniería, pero hay muchas personas como yo y este texto para los mismos físicos mimados que no entienden las altas abstracciones.
Aquí, por ejemplo, hay una descripción real en la notación gráfica del algoritmo de control de la válvula de compuerta NPP:
Figura 1. Ejemplo de un programa de control de NPP en notación gráficaSeñales de entrada a la izquierda, comandos a la derecha.
Me parece que incluso un niño puede leer dicho algoritmo:
- Si la bomba se enciende durante 60 segundos y el caudal es inferior a 10, abra la válvula de recirculación.
- Si la bomba está encendida, entonces dé la orden de abrir en 5 segundos a las válvulas 001 y 002.
- Si el caudal es superior a 20 y la bomba está encendida, dentro de los 5 segundos para enviar la válvula de obturación 003 para cerrar.
Cuando era estudiante, trabajaba a tiempo parcial creando una biblioteca de componentes para Delphi y estaba familiarizado con OOP de primera mano. Luego, cuando me encontré con programas reales de control de plantas de energía nuclear, me sorprendió mucho que no hubiera abstracción, encapsulación y, perdóname, polimorfismo, solo C puro y la recomendación de MISRA C que fue cortada por las reglas para que todo fuera confiable , portátil y seguro.
El pico de corte de C en mi práctica fue FIL, para sistemas de control de reactor RBMK. En él, las funciones se escribieron previamente en C, se compilaron y luego se invocaron sobre la base de un archivo de texto, donde se describieron en FIL. Como resultado, fue posible llamar solo a un conjunto limitado, pero cuidadosamente probado y depurado de funciones. Y todo esto es en nombre de la seguridad y la fiabilidad.
Pero al mismo tiempo, el sistema de control del reactor y el sistema de control de la central nuclear en su conjunto es solo el caso en el que los principios de OOP deben aplicarse a todo su potencial. De hecho, hay muchos equipos similares: válvulas, bombas, sensores, todo se clasifica fácilmente, hay objetos prefabricados que corresponden a equipos reales. Parece que aquí está: use OOP, clases, herencia, abstracción y polimorfismo. Pero no, necesita puro C y estos son requisitos de seguridad.
Y luego, aún más interesante. De hecho, el programa para administrar la planta de energía nuclear no está escrito por el programador, sino por el tecnólogo, solo él sabe qué y cuándo cerrar, abrir, encender y, lo más importante, sabe cuándo apagar la canoa para no chocar. Y el programador debe implementar cuidadosamente todo esto en código C. Y aún mejor, que no habría ningún programador, y el propio tecnólogo dibujó los algoritmos tecnológicos de los programas de control en forma gráfica, generó automáticamente el código C y lo cargó en el equipo de control. Las normas internacionales de seguridad recomiendan esto; en este caso, no se necesita un programador, como un violinista. Introduce solo errores y distorsiones adicionales en la implementación de los pensamientos del tecnólogo.
Cuál fue mi sorpresa cuando descubrí que los tecnólogos y diseñadores de NPP, independientemente de los programadores, han desarrollado y utilizado con éxito la programación orientada a objetos, e incluso en anotaciones gráficas, pero el código resultante cumple completamente con los requisitos de seguridad y no contiene artefactos de la metodología OOP .
De hecho, si observa el código que se genera desde el circuito en la Figura 1, veremos C puro sin ninguna clase allí.
Por ejemplo, la tabla de entrada del algoritmo:
state_vars->kbaalgsv0_out_1_ = kba31ap001_xb01; state_vars->kbaalgsv0_out_4_ = kba31cf001_xq01;
Solo asignando variables.
Cualquier bloque se describe como el cálculo de la salida por entrada, teniendo en cuenta los parámetros especificados en la lista de constantes. Por ejemplo, el bloque "Más" se ve así en el código:
locals->v5_out_0_ = state_vars->kbaalgsv0_out_4_ > consts->kbaalgsv3_a_;
La salida de bloque es el resultado de comparar la señal de entrada con un valor en una constante.
Por lo tanto, en otros bloques, las variables locales de las variables de entrada se calculan secuencialmente, y al final del ciclo del programa, las variables se escriben en las variables de salida.
if((action==f_InitState)||(action==f_GoodStep)||(action==f_RestoreOuts)){ kba31ey001_yb01 = locals->v8_out_0_; kba31ey001_yb11 = state_vars->kbaalgsv9_out_0_; kba31ey001_yb12 = state_vars->kbaalgsv12_out_0_; kba31ey001_yb02 = locals->v13_out_0_; };
¿Dónde están las clases aquí, preguntas?
Toda la metodología relacionada con OOP está en nombres de variables. Parece que esto podría estar en el nombre de la variable? Y puede haber todo un abismo. Por ejemplo, el nombre de la variable es kba31ap001_xb01, solo una variable en el código C que cumple con los requisitos para el nombre de las variables. Sin embargo, para un ingeniero de diseño, se ve así: "Compartimento del reactor, sistema de suministro de agua industrial, primera bomba, puesta en marcha". Toda esta magia de conversión ocurre gracias al maravilloso sistema de codificación alemán (Kraftwerk-Kennzeichensystem) KKS, cita:
“Este sistema de clasificación de codificación está diseñado para plantas de energía y tiene un gran potencial, y también tiene en cuenta las características del hardware de microprocesador programable libremente.
Junto con el marcado de equipos tecnológicos, cuerpos ejecutivos (válvulas de cierre, seguridad, cierre, etc., mecanismos auxiliares), puntos de medición, unidades de montaje, dispositivos de automatización, edificios y estructuras, el sistema KKS permite marcar algoritmos y programas de diversos tipos. y propósitos (algoritmos de procesamiento para parámetros tecnológicos medidos, señalización, regulación automática, protecciones tecnológicas, control lógico: bloqueos, ABP, programas paso a paso, - cálculo de t hniko indicadores económicos y de diagnóstico de equipo tecnológico), entrada, salida y señales intermedias de algoritmos y programas, grabaciones de vídeo de todos los niveles se muestran en los terminales de vídeo, cables, etc ... "
Pero lo más interesante en la última parte del nombre es _xb01 , que se especifica a través del guión bajo. Si observa la base de la señal para el proyecto de gestión, veremos clases allí que son comprensibles y familiares para todos los que alguna vez, en algún lugar y en algún lugar estaban interesados en la POO (ver Fig. 2).
Figura 2. Un ejemplo de una estructura base de señal para un sistema de control de planta de energía nuclear.Tenemos clases o tablas, en la figura esta es la columna "Categorías". Por ejemplo, "KD1" que tiene una tabla de señales de patrón, campos de la clase Límite superior de medición, límite inferior de medición, lectura del sensor , etc. Es una abstracción.
Y también hay una implementación de esta clase: un sensor específico, por ejemplo, TK21F02B1, ubicado en el circuito, como se puede adivinar por su nombre, en el "Compartimento del reactor, sistema de suministro de agua industrial, en la primera bomba", y el hecho de que se trata de un sensor de flujo está en este título, pero no es exacto.
Y esta instancia de esta clase tiene señales específicas y sus valores, en el proceso del programa, y se puede acceder a ellos mediante los nombres de los campos de la clase. Por ejemplo, la lectura de un sensor se indica mediante la variable TK21F02B1_XQ04.
En este punto, podemos decir, espera, esto no es OOP en absoluto, o incluso no es OOP en absoluto, es solo una estructura de datos, está en el estándar C. ¿Y dónde está la encapsulación de los métodos en la clase? El procesamiento de datos debe estar en la clase, entonces este será el verdadero método kosher OOP.
Veamos cómo se ve la subrutina de control de confiabilidad del sensor en forma gráfica. La Figura 3 es una parte del circuito de procesamiento de señal:
Figura 3. Un ejemplo de un programa de procesamiento de señal.Se puede ver que en la subrutina de procesamiento se usan los nombres de variables TK21F02B1_XQ04, formados de acuerdo con las reglas KKS y basados en la tabla de campo de clase. En el ejemplo anterior, las lecturas del sensor se calculan en porcentaje TK21F02B1_XQ03 de acuerdo con los valores establecidos de los campos de la instancia de clase, como TK21F02B1_Xmin y TK21F02B1_Xmax.
Si recurrimos al código generado a partir de este esquema, veremos una simple asignación de un valor a una variable, C puro y sin más y OOP.
state_vars->su100v12_out_0_ = tk21f02b1_ai;
Y la asignación del resultado del cálculo, también como una simple asignación de una variable (con la verificación de la validez del número, para no dejar caer el sistema si recibimos un error como resultado del procesamiento de la señal)
if(isfinite(locals->v63_out_0_)){ tk21f02b1_xq04 = locals->v63_out_0_; };
¿Y en qué momento aparece la unión de estos campos de la clase de métodos de procesamiento? De hecho, estoy familiarizado con dos opciones para este enfoque. Ahora analizaremos uno de ellos. (La segunda opción se analiza aquí .. )
Veamos cómo se configura el bloque en el que se encuentra el circuito del programa de procesamiento en el diagrama (ver Fig. 4).
Tenemos un circuito en el que colocamos bloques de un submodelo de un lenguaje de programación gráfico; dentro de estos bloques hay un circuito gráfico, parte del cual se muestra en la Figura 3, un programa para procesar señales de sensores.
En las propiedades de este bloque, vemos los campos de la base de datos de señales y una lista desplegable que contiene señales ya existentes en la base de datos, instancias de la clase, sensores específicos de este tipo. Es suficiente elegir el sensor deseado, una instancia de la clase por nombre, y sucede un milagro. En el esquema, todos los bloques de lectura y escritura reciben nombres del tipo TK21F02B1_XQ03 , (nombre del sensor de instancia de clase + nombre del campo).
Ahora, al generar el código C, todas las variables recibirán los valores del sensor deseado. Y el programador no es necesario, el tecnólogo hizo todo por sí mismo cuando desarrolló el esquema en el lenguaje de programación gráfico para el algoritmo de control NPP.
Figura 4. Un ejemplo de configuración de un circuito de procesamiento del sensor.Para asignar los nombres, se utiliza un script de automatización especial en el entorno de diseño del sistema de control, aproximadamente el mismo que en la Figura 5. Todos los bloques de lectura en el diagrama son nombres asignados que consisten en el nombre del objeto y el nombre del campo en la clase (ver Fig. 5).
Figura 5. Configuración del nombre de variables en bloques de lectura.Está claro que, de manera similar, se puede crear un número ilimitado de opciones de procesamiento de señales, esencialmente métodos para la clase en la metodología OOP. Del mismo modo, pueden formarse para el sensor, resumiéndose cuando se muestran en los cuadros de video del sistema SCADA o, por ejemplo, procesando procedimientos para cambiar la configuración. Se crea un diagrama en forma gráfica, se guarda como un bloque y se usa si es necesario.
Para resumir: en los lenguajes de programación gráfica, también se utilizan métodos OOP y son beneficiosos. Y después de generar el código fuente para los programas de control, todos los artefactos de la metodología OOP desaparecen y permanecen limpios, seguros, confiables y verificados.
Está claro que dicha aplicación de herramientas de automatización, además de acelerar el desarrollo, también puede reducir significativamente el tiempo de desarrollo, la cantidad de errores en los programas de control.