Continuando con el tema de OOP en lenguajes de programación gráficos, examinaremos con más detalle el diseño basado en modelos. Qué es el diseño orientado a modelos (MOS), cómo cocinarlo y con qué comer.

Al describir un diseño orientado a modelos de sistemas de control, algunos autores en sus publicaciones transmiten la idea de que la palabra "modelo" significa "modelo de un sistema de control". Lo que no está bien

Por qué esto no es cierto, cómo hacerlo bien y dónde está Chernobyl, sigue leyendo.

Aquí hay un ejemplo típico: una imagen de un artículo de autores respetados sobre las "mejores prácticas en el desarrollo de software utilizando un diseño orientado a modelos":

Figura 1. Una de las opciones para MOS.

Personalmente, al mirar esta imagen, surge una pregunta indecente de inmediato, y de qué lugar, me disculpo, ¿tenía vectores de prueba?

O, por ejemplo, una imagen a la recomendación de un proceso de desarrollo de software típico:

Figura 2. Otra versión del proceso MOS.

¿Dónde está el modelo en esta imagen? Aquí está este cuadro del que se obtiene el código fuente. ¿En serio? Entonces, este es nuevamente un modelo de software de control.

Especialmente conmovedor en esta imagen es la presencia de requisitos iniciales de software.
Como usted, por ejemplo, es un requisito muy habitual, casi de libro de texto, para un sistema de control:

" Cuando la presión sube por encima del valor límite, el tiempo de cierre (apertura) de la válvula de seguridad no debe ser superior a 5 segundos ".

¿Y cómo ordena bajo este esquema para verificar cuántos segundos después de que se ha excedido la presión, se abrirá la válvula de seguridad? Al parecer, falta algo aquí. Pasamos a la fuente inagotable de verdad en el último recurso - Wikipedia:

El diseño basado en modelos proporciona un enfoque eficiente para establecer un marco común para la comunicación a lo largo del proceso de diseño, al tiempo que respalda el ciclo de desarrollo (modelo V). En el diseño basado en modelos de sistemas de control, el desarrollo se manifiesta en estos cuatro pasos:

1. modelar una planta,
2. analizar y sintetizar un controlador para la planta,
3. simulando la planta y el controlador,
4. integrar todas estas fases mediante la implementación del controlador.

El desarrollo de un modelo de un objeto es el primer punto para determinar MOS. Primero, un modelo del objeto, y luego controlarlo. Y esto es correcto: no hay un modelo de objeto, "gracias a todos, todos son libres" y este no es un diseño orientado al modelo, sino un fraude total al consumidor.

¿Por qué es esto importante y de dónde viene Chernobyl?

En Chernobyl, sucedió exactamente lo que sucedió en ausencia de un modelo de objeto. Los científicos soviéticos hicieron la pregunta: “¿Qué sucederá si se desconecta la fuente de alimentación y las bombas de enfriamiento del reactor reciben corriente de un generador que funciona en una turbina que se está agotando? "¿Cuánta agua bombearán las bombas a través del reactor antes de que la turbina y el generador se detengan?" Curiosamente, hicieron esa pregunta sobre la base de la experiencia del accidente en la central nuclear estadounidense, donde el suministro de agua no era suficiente para enfriar y el reactor estadounidense se derritió. Y para asegurarnos de que nuestros reactores no se estén derritiendo, decidimos realizar un experimento. Quizás la respuesta a esta pregunta haría que la próxima generación de reactores RBMK sea aún más segura. Queríamos lo mejor, pero resultó como siempre. Como resultado del experimento, un reactor seguro primero fue llevado a un estado peligroso y luego explotó. Y la próxima generación de reactores RBMK ya no existe y no se espera. Amén

Y si, en lugar de experimentar en un reactor, sería posible hacer lo mismo en un modelo matemático de un objeto, entonces, muy posiblemente, ahora construiríamos RBMK-2400 en todo el mundo en lugar de los reactores VVER-1200.

Después del accidente de Chernobyl en la industria nuclear, un modelo de objeto (reactor nuclear) es una parte obligatoria del proyecto. El diseñador debe mostrar en el modelo lo que sucederá si algo sale mal. Y, por lo tanto, el diseño orientado a modelos apareció entre los ingenieros nucleares mucho antes que en otras industrias, debido a los requisitos de los organismos reguladores.

Pero incluso cuando no hay requisitos de las autoridades reguladoras, el modelo del objeto facilita enormemente el diseño tanto del sistema de control como del objeto mismo. Ahora mostramos esto con un ejemplo de una industria donde "los sueños se hacen realidad".

El enfoque orientado al modelo correcto.

Como ejemplo del MOS kosher correcto, consideramos el proceso de desarrollo de software de control para el sistema de control hidráulico de un complejo minero submarino (como siempre, fue absolutamente por accidente que obtuve este modelo en mi computadora).

El control de los flujos principales del gas producido por el suministro se realiza mediante accesorios hidráulicos subacuáticos. En la orilla hay una estación de bombeo, que proporciona presión en el sistema hidráulico, el aceite se suministra a través de un umbilical bajo presión bajo el agua. La apertura y cierre de válvulas se realiza mediante actuadores hidráulicos, que se controlan mediante un sistema de control distribuido. El sistema consta de:

• módulo de control de tierra para todo el campo;
• Un conjunto de módulos de control subacuáticos (PMU) que proporcionan control directo de las válvulas.

Para la conveniencia de la instalación y el mantenimiento, las tuberías se combinan en múltiples, donde las válvulas y los módulos de control necesarios se instalan en una plataforma. Si en la estación terrestre puede usar herramientas SCADA estándar, servidores de archivo y PLC con sistemas operativos convencionales y (o) en tiempo real, entonces el módulo de control subacuático es, por regla general, un microprocesador no operativo, cuyo código de control debe desarrollarse por separado del software de control costero . (Sin C ++, solo C, solo código duro) Luego, varias de estas PMU deben integrarse en el sistema común y probarse. Y al mismo tiempo, todo el sistema debería funcionar como un todo y permitir la apertura y cierre de válvulas dentro de los 30 años bajo el agua.

La tarea se complica por el hecho de que hasta ahora todo el equipo utilizado en el estante era occidental, y el estante ahora está bajo sanciones. Y, en consecuencia, es necesario crear un complejo en el que muchas soluciones técnicas sean nuevas y no hayan sido tratadas para nosotros. ¿Cómo obtener el resultado, reduciendo los errores de diseño si es posible? Bueno para los desarrolladores occidentales: ya tienen experiencia, saben sobre las trampas en la minería submarina. Y aquí el diseño orientado a modelos ayuda a los desarrolladores. En lugar de realizar experimentos en equipos caros, como los científicos nucleares soviéticos en Chernobyl, creamos un modelo del objeto y realizamos experimentos en el modelo.

Modelo integrado del sistema de control subacuático.

Para el diseño de software, se crea un modelo integrado en forma de paquete que contiene ambos modelos de flujo de fluido hidráulico bajo el agua con accesorios y proyectos de sistemas de control. (ver figura 3)

Figura 3. Un paquete de un modelo integrado del sistema de gestión SPD.

Este paquete contiene un proyecto: un modelo de una estación hidráulica terrestre (archivo 200.prt en la Fig. 3), que proporciona el modelado de los procesos dinámicos del equipo del sistema de suministro de fluido hidráulico terrestre para el agua. (ver figura 4)

Figura 4. El esquema de diseño de la estación hidráulica de tierra.

Simultáneamente con el modelo de procesos físicos, se está desarrollando un proyecto de sistema de control que permite encender y apagar el equipo y controlar los modos de funcionamiento de este equipo. La Figura 5 muestra los borradores de algoritmos de control para el módulo de control de tierra.

Figura 5. Diseño de un sistema de control de módulo de tierra.

En esta etapa, es posible dividir el desarrollo de algoritmos de control entre diferentes equipos. Por ejemplo, para los desarrolladores de una estación hidráulica terrestre, los costos de los módulos submarinos y la presión en ellos son condiciones límite. Para los desarrolladores de equipos submarinos, la condición límite es la presión creada por la estación de bombeo en tierra.

El desarrollo de módulos de control subacuáticos (PMU) se lleva a cabo sobre la base del proyecto para dividir las principales tuberías de gas entre los colectores. Primero, se forman los pozos, se determinan las tuberías y accesorios entre los pozos y la orilla, luego se desarrolla un sistema de control hidráulico para estas válvulas.

Para cada módulo subacuático, se forma un modelo de proyecto de sistema de control y un modelo de diseño del sistema hidráulico múltiple con válvulas instaladas. En el esquema de diseño del sistema hidráulico, se instalan válvulas, que se controlan desde este módulo submarino. Este diseño puede llevarse a cabo en paralelo con el desarrollo del módulo de control de tierra, mientras que el desarrollo puede llevarse a cabo de forma independiente y en paralelo. Para desarrollar los algoritmos de PMU y la operación de la válvula, el sistema externo se define mediante comandos de control y condiciones de límite para el sistema hidráulico.

Considere el módulo de control subacuático (PMU) 502. Aquí se utilizan dos proyectos:

• 502.prt - modelo de sistemas hidráulicos (Fig. 6, 7);
• 502a.prt: el proyecto del sistema de control de la UAP (Fig. 8).

Figura 6. El circuito hidráulico de la PMU.

Este esquema de diseño proporciona una simulación del comportamiento del sistema de control hidráulico y el cálculo de caudales y presiones en un sistema controlado por 502 PMU. El circuito hidráulico calculado le permite establecer el impacto en los actuadores y obtener datos del sensor calculados en el modelo de procesos físicos. Siempre que no tengamos una estación terrestre en el bloque 502 P (esquina inferior izquierda de la Fig. 6), podemos establecer la presión creada por la estación hidroeléctrica como condición límite.

En el sistema, la figura muestra 6 válvulas hidráulicas de cierre y control (ZRA), cada una de las cuales representa inherentemente un cilindro hidráulico conectado a dos líneas de alta y baja presión. Aplicamos más presión a la parte superior del cilindro, la presión mueve la varilla hacia abajo, aplicamos más presión a la parte inferior del cilindro, la varilla se eleva.

La conmutación se controla mediante válvulas de control ubicadas dentro del bloque blanco (ver Fig. 7).

Figura 7. Bloque de válvulas de distribución en el modelo.

El principio de funcionamiento es simple: dependiendo de la posición de la válvula deslizante, las cámaras del cilindro se conectarán a diferentes líneas. Movió el carrete: cambió la dirección de movimiento de la varilla en el cilindro. (Puede encontrar más detalles sobre el modelado hidráulico aquí ... )

Figura 8. El diseño del sistema de control de PMU.

El software de gestión de proyectos para el módulo de control subacuático contiene varios bloques de cálculo, cada uno de los cuales puede ser desarrollado por un desarrollador o equipo por separado. En este caso, la separación en módulos ocurre de acuerdo con un atributo funcional, cada bloque es responsable de controlar un cierto tipo de válvula. Se aplica la metodología de programación orientada a objetos, donde el bloque es la clase OOP (más detalles aquí ... y aquí ... )

Considere el proceso de diseño de una unidad de control para bloquear y regular equipos. Este bloque en el circuito recibe 4 señales de entrada y genera 8 señales de salida. (ver figura 9)

Figura 9. Unidad de control ZRA (Tipo 1).

El diagrama de bloques interno consta de dos hojas de algoritmos. La primera hoja se muestra en la Figura 10a, la segunda en la Figura 10b.

Figura 10a. El esquema de diseño de la unidad de control de la válvula. Hoja 1.

Figura 10b. El esquema de diseño de la unidad de control de la válvula. Hoja 2.

Al desarrollar esta unidad, se utilizan los siguientes tipos de señales:

• señales recibidas a través de líneas de comunicación (bloques azules);
• parámetros y señales recibidas de la base de datos de señales (bloques de color amarillo pálido);
• señales transmitidas a la base de datos de señales (bloques azul pálido);
• señales transmitidas a la memoria (bloques amarillos brillantes);
• señales recibidas de la memoria (bloques verdes brillantes).

El diagrama de diseño de la unidad de control de la válvula es vectorial. Esto significa que no se transmite una sola señal de control en cada línea, sino un vector de señales, cuya dimensión corresponde a la cantidad de equipos de este tipo instalados en el PMP. Para la comunicación entre la unidad de cálculo y las señales, parámetros y comandos para un equipo específico, se utilizan unidades de interfaz.

Por lo tanto, después de haber desarrollado y probado un circuito de control de un elemento típico, se pueden colocar tantas unidades de interfaz en el circuito como el equipo de este tipo está conectado al módulo de control subacuático. En este caso, en la PMU hay dos unidades de interfaz para válvulas de cierre y de control tipo 1 (ver Fig. 8).

Todas las señales y parámetros variables que son necesarios para la unidad de control se colocan en la categoría correspondiente de la base de señal ZRAT1 . Parte de la categoría se muestra en la Figura 11.

La separación de una categoría separada permite formar la separación del desarrollo de módulos de software de control en partes y definir claramente la interfaz de interacción entre las diversas partes del programa. Por lo tanto, el desarrollo del módulo de control se realiza de forma aislada a lo largo de las interfaces de otros módulos en el software.

Figura 11. Grupo de señal para la unidad de control ZRAT1

Sistema de codificación del proyecto

El sistema contiene varias instancias de este tipo de equipo, lo que significa que hay incluso más variables en el software de administración. Para eliminar los errores asociados con el nombre de las variables, se utiliza un sistema de codificación de equipos. En la base de datos de señales, se forman grupos de señales cuyos nombres únicos contienen el código del sistema, el tipo de equipo y un código único dentro del sistema.

En este ejemplo, en el circuito hidráulico, tenemos dos instancias de la válvula ubicada en el sistema 502, que está controlada por el bloque ZRA TYPE 1 . (ver Fig. 12.) Sus nombres en la base de datos son 502GTVOO1 y 502GTVOO2 . La ventana de la base de datos de señales se muestra en la Figura 12.

Figura 12. Base de datos de señales de equipos del sistema de control SPD.

El sistema de codificación determina los nombres de las variables para los módulos del software de control y le permite automatizar los procesos de denominación de señales dentro de todo el módulo de software desarrollado. Cualquier nombre de variable consiste en el nombre del grupo de señal y el nombre de la variable conectada por el signo "_".

Para cualquier válvula de cierre y control relacionada con el campo de tiro "ZRA Tipo1", el nombre de las señales de entrada, las variables de estado y las variables de salida se ven como " código de armadura " _ " nombre_de_señal ". Para la válvula 502GTV002 , hay 65 variables en la base de datos de señales, por ejemplo:

Equipos:
502GTV002_open_rem - comando de apertura remota.
502GTV002_close_rem - comando de cierre remoto.
502GTV002_open_rem_z - comando preliminar para cerrar.

Variables de estado de armadura:
502GTV002_opened - la válvula está completamente abierta.
502GTV002_no abierto : la válvula no está abierta.
502GTV002_no cerrado : la válvula no está cerrada.
502GTV002_losed : la válvula está completamente cerrada.

Parámetros de entrada y salida de fluido hidráulico:

502GTV002_XTK1 - presión en la línea de trabajo.
502GTV002_XTK2 - presión en la línea de presión.
502GTV002_XTK3 - presión en la línea de drenaje.

Si agregamos una unidad más de refuerzo a este esquema, entonces su nombre será 502GTV003, donde según el sistema de codificación aceptado

502 es el nombre del módulo.
GTV - tipo de refuerzo.
003 - número de serie de válvulas de este tipo en el módulo.

Durante el desarrollo del módulo de control, los valores de los parámetros se pueden establecer en la base de datos de señales y, por lo tanto, se verifica el estado de una unidad de control separada. En particular, el estado de las válvulas en este ejemplo está determinado por la presión en las líneas de entrada y salida de fluido hidráulico. Para probar el módulo de control por separado del resto del sistema, esta presión se puede configurar manualmente en la base de datos de señales.

Cuando la unidad está funcionando como parte de la PMU, es necesario transferir los valores de presión de los sensores respectivos a la unidad de control. Para esto, se utilizan bloques de interfaz, cuyo nombre coincide con el nombre del equipo; consulte la Fig. 13. Para la conveniencia de la depuración, el mismo bloque muestra los valores de las señales recibidas de los sensores.

Figura 13. Transmisión de señales desde sensores a la unidad de control ZRA T1.

Como resultado del funcionamiento de esta unidad, se forma un equipo para mover los carretes en las válvulas de control, que son responsables del equipo de control con el nombre 502GTV002 .

Durante el cálculo conjunto, los valores de los parámetros calculados en el modelo hidráulico se transfieren a la unidad de procesamiento de lectura del sensor (consulte la Fig. 14), donde se analizan los datos obtenidos para determinar la fiabilidad, el filtrado y la traducción a los valores de medición requeridos.

Figura 14. El esquema de diseño para el procesamiento de sensores.

El esquema de cálculo para procesar las lecturas del sensor que se muestra en la Figura 14 también es un programa completamente funcional. Para transferir este circuito al equipo de control real, es suficiente que el valor recibido de la placa de entrada / salida del sensor real se coloque en la variable "Valor estimado" en el reloj de intercambio de datos en el equipo real.

Este circuito también es vectorial y proporciona el procesamiento de todos los sensores incluidos en el circuito hidráulico 502.prt

Los bloques de diseño estándar diseñados y probados se colocan en una biblioteca de soluciones estándar y posteriormente son utilizados por otros desarrolladores para todos los equipos de este tipo.

Después de depurar y verificar todos los esquemas de cálculo necesarios de los programas típicos, el desarrollo de software de control para cualquier módulo subacuático se vuelve claro, simple y efectivo. Puede agregar cualquier equipo en dos pasos:

• Coloque la unidad de control del equipo.
• Agregue tantas unidades de interfaz como tantas instancias de equipos se conectarán a la PMU.

Metodología OOP en lenguajes gráficos en acción.

.

. . .

.

« , () 5 »

, . . . . . , , , . , , - , .

, - (. . 15).

15. .

. , 9, 10 7, 8 (. . 16).

16. .

(. . 17). , , . , , .

17. .

, , .

18 . , .

19 .

18. 2- .

19. .

, , , , 30,5 , , 32, .

« () 5 »

, 5 , . , « () 5 », , , , 8 ( ). ( ).

Conclusiones

- , !

. .

. .

, , , , . , - , .

- , !

, — .