Mejores Prácticas de Implementación para Ignition 8
Para cualquier sistema de nivel empresarial, IA recomienda emplear todas las técnicas cubiertas en este documento.


Mejores Prácticas de Implementación para Ignition 8

Para cualquier sistema de nivel empresarial, IA recomienda emplear todas las técnicas cubiertas en este documento


  30 minutos de lectura

Tabla de contenidos

1. Introducción

2. El Flujo de Trabajo

3. Configuración de Ignition

4. Entornos de Implementación

5. Defina su Flujo de Trabajo y Proceso

6. Ejemplo de GitLab

 

Introducción

Esta guía tiene como objetivo ayudarlo a comprender mejor cómo manejar la implementación de aplicaciones de Ignition y proporciona algunas de las mejores prácticas para configurar su flujo de trabajo de desarrollo y prueba. Tener un flujo de trabajo de implementación sólido permite una mejor gestión de cambios, minimiza los errores y conduce a un equipo más productivo.

Esta guía está dirigida a los usuarios de Ignition que buscan configurar un sistema escalable, flexible y de nivel empresarial. Algunos usuarios comienzan con una arquitectura diferente o un modelo diferente y avanzan hacia esto, y es posible que algunos usuarios nunca elijan emplear todas las recomendaciones. Estas pautas no pretenden ser una propuesta de todo o nada, y muchas instalaciones podrían beneficiarse de emplear incluso un subconjunto de las recomendaciones aquí contenidas.

Para cualquier sistema de nivel empresarial, Inductive Automation recomienda encarecidamente emplear todas las técnicas cubiertas en este documento.

El Flujo de Trabajo

Las implementaciones deben tratarse como parte de un flujo de trabajo de desarrollo, no como una ocurrencia tardía. Su flujo de trabajo generalmente incluirá al menos tres entornos: desarrollo, pruebas y producción. En ese caso, el flujo de trabajo podría verse así:

Los desarrolladores trabajan en errores y funciones en un entorno de desarrollo.
Una vez que se implementan las características, se fusionan en la rama de pruebas y se implementan en el entorno de pruebas para el control de calidad y las pruebas.
Una vez que se completan las pruebas, la rama de desarrollo se fusiona en producción y luego se implementa en el entorno de producción.

Antes de examinar más de cerca cada entorno, es importante analizar la configuración de Ignition con más detalle para comprender mejor la implementación.

Configuración de Ignition

Ignition es un software basado en servidor e instalado en un servidor central. Eso significa que toda la configuración de Ignition se almacena en el servidor. Es un lugar para instalar, licenciar, configurar, realizar copias de seguridad y administrar. Las aplicaciones cliente se descargan del servidor Ignition (Vision) o son HTML nativo (Perspectiva) y, como resultado, se actualizan automáticamente a medida que se implementan nuevos cambios. De esa manera, no tenemos que preocuparnos por instalar, otorgar licencias o implementar cambios en clientes individuales, especialmente si tenemos cientos de clientes. Para nuestro modelo de implementación, nos enfocamos únicamente en el servidor.

Cuando está desarrollando en Ignition, hay 4 áreas principales de configuración:

  • Configuración de puerta de enlace
  • Etiquetas
  • Imágenes
  • Proyectos

Cada una de estas áreas se almacena de forma diferente en el servidor. La copia de seguridad de la puerta de enlace contiene la configuración para todos estos, pero algunos también se pueden manejar individualmente. Es fundamental comprender las diferencias y cómo interactuamos con ellas al implementar cambios.

Configuración de Puerta de Enlace

El área de configuración de la puerta de enlace incluye todas las configuraciones, perfiles y conexiones diferentes que edita en la sección Configuración de la página web de la puerta de enlace. Aquí es donde se configuran la mayoría de las configuraciones que afectan a todo el Gateway. Podemos agregar bases de datos y conexiones de dispositivos, usuarios y roles, ajustar la configuración de alarma, configurar la seguridad, crear un cronograma para que se realice una copia de seguridad de Gateway automáticamente en momentos específicos y mucho más. La lista de opciones de configuración en el menú de la izquierda cambia según los módulos instalados en su Gateway.

Todas estas configuraciones se almacenan dentro de la base de datos SQLite interna de Ignition. Solo son accesibles a través de la interfaz de usuario de Gateway. Fuera de una copia de seguridad completa de la puerta de enlace, no puede exportar ni importar esta configuración de la puerta de enlace a la puerta de enlace. El módulo EAM de Ignition actualmente tampoco admite mover estas configuraciones de Gateway a Gateway. Esto dificulta trabajar con él al desarrollar nuestra estrategia de implementación, ya que todos los cambios deben realizarse manualmente. También es difícil rastrear los cambios ya que todo está dentro de una base de datos SQLite.

Las copias de seguridad de la puerta de enlace no se utilizan normalmente al migrar cambios porque son todo o nada. Los diferentes entornos a menudo tienen opciones de configuración de puerta de enlace independientes para elementos como dispositivos, bases de datos y autenticación.

Recomendamos crear un proceso que todos los desarrolladores sigan para realizar un seguimiento de los cambios de estas configuraciones fuera de Ignition y para documentar las diferencias en estas configuraciones dentro de cada entorno (desarrollo, pruebas y producción).

Etiquetas

Las etiquetas son una parte importante de la mayoría de los proyectos. Las etiquetas son puntos de datos y pueden tener valores estáticos o dinámicos que provienen de una dirección OPC, una expresión o una consulta SQL. Los valores se pueden usar en pantallas, en grupos de transacciones y más.

Las etiquetas proporcionan un modelo de datos coherente en todo Ignition y ofrecen la forma más sencilla de empezar a trabajar creando sistemas de control y estado en tiempo real. Sin embargo, a pesar de su rápida curva de aprendizaje inicial, las etiquetas ofrecen una gran potencia en el diseño y la configuración del sistema. La capacidad de agregar etiquetas de una variedad de instalaciones significa que puede construir sistemas SCADA ampliamente distribuidos más fácilmente que nunca con un alto nivel de rendimiento y una configuración relativamente fácil.

Las etiquetas se almacenan dentro de los proveedores de etiquetas. Las etiquetas no forman parte de un proyecto de Ignition. Más bien, los proyectos simplemente hacen referencia a etiquetas. Un proveedor de etiquetas es una colección de etiquetas (una base de datos de etiquetas) y puede ser local o remoto. Un servidor Ignition puede tener uno o más proveedores de etiquetas asociados. Los proveedores de etiquetas pueden proporcionar agrupaciones lógicas de etiquetas (almacenes separados de etiquetas). De forma predeterminada, Ignition se envía con un proveedor de etiquetas local llamado "predeterminado". Los proveedores de etiquetas locales se almacenan dentro de la base de datos SQLite interna de Ignition. Las etiquetas se configuran dentro de Ignition Designer en el panel Explorador de etiquetas.

Ignition puede exportar e importar configuraciones de etiquetas hacia y desde el formato de archivo JSON (JavaScript Object Notation). También puede importar formatos de archivo XML (Extensible Markup Language) o CSV (Comma Separated Value), pero Ignition los convertirá al formato JSON.

Las etiquetas también se pueden mover a través del módulo EAM de Ignition de Gateway a Gateway. Es mucho más fácil trabajar con las etiquetas al implementar cambios. Sin embargo, las etiquetas todavía se almacenan dentro de la base de datos SQLite interna de Ignition y se deben seguir los pasos necesarios para realizar un seguimiento de los cambios de etiquetas.

Recomendamos exportar etiquetas continuamente a un archivo JSON y enviar el archivo a un repositorio de control de fuente para realizar un seguimiento de los cambios. El proceso de exportación de etiquetas se puede realizar automáticamente usando un script de Python en Ignition (más información a continuación). Puede usar el módulo EAM de Ignition para implementar cambios desde el desarrollo hasta las pruebas y la producción o exportar / importar manualmente a través de Ignition Designer.

Imágenes

Las imágenes como PNG, JPG, GIF y SVG se pueden cargar en la Herramienta de administración de imágenes y usar dentro de Visión o Perspectiva. La herramienta Image Management, disponible en Tools> Image Management en Ignition Designer, proporciona una interfaz para cargar, descargar o seleccionar imágenes.

Estas imágenes se almacenan dentro de la base de datos SQLite interna de Ignition y no forman parte de un proyecto de Ignition. Más bien, los proyectos simplemente hacen referencia a imágenes.

Las imágenes no se pueden mover a través del módulo EAM de Ignition de Gateway a Gateway. El proceso es manual y requiere el uso de la herramienta Image Management en Ignition Designer. También se deben tomar medidas para realizar un seguimiento de los cambios de imágenes.

Recomendamos exportar imágenes continuamente a una carpeta y enviar la carpeta a un repositorio de control de fuente para realizar un seguimiento de los cambios. Este proceso no se puede realizar automáticamente y requiere una intervención manual. Debe exportar / importar imágenes a través de Ignition Designer al implementar cambios desde el desarrollo hasta las pruebas y la producción.

Proyectos

Los proyectos son la unidad principal de configuración en Ignition. Los proyectos contienen todos los elementos diseñados que hacen el trabajo real. Sus proyectos pueden contener tanto elementos interactivos (como controles, gráficos, informes, formularios de entrada y más) como elementos persistentes (como registradores históricos, informes automatizados, etc.).

En Ignition, un proyecto es una unidad de configuración que contiene:

  • Visualización de ventanas y plantillas y vistas en perspectiva: pantallas con las que los usuarios interactúan
  • Grupos de transacciones: un enlace bidireccional entre bases de datos y PLC
  • Informes: informes en PDF para mostrar y registrar datos
  • Secuencias de comandos: secuencias de comandos basadas en temporizador y eventos que se utilizan en todo el sistema
  • Canalizaciones de notificación de alarmas: canalizaciones que notifican a los usuarios sobre las condiciones de alarma
  • Configuración y propiedades generales: la configuración que controla el acceso, las conexiones de recursos, el diseño, el tiempo y más.
  • Y mucho más

Utiliza Ignition Designer para configurar y crear proyectos. Luego, los proyectos se ven en el tiempo de ejecución (clientes de visión o sesiones de perspectiva). Puede crear tantos proyectos como desee y los usuarios pueden saltar fácilmente entre proyectos sobre la marcha o abrir varios proyectos al mismo tiempo.

Los proyectos se almacenan en el sistema de archivos como una serie de carpetas y archivos. Algunos archivos son binarios, mientras que otros se almacenan como archivos de texto sin formato. Los proyectos se almacenan dentro del directorio de datos en el servidor Ignition.

Linux

Windows

Dado que los proyectos se almacenan en el sistema de archivos, es posible utilizar las mejores herramientas de control de fuentes fuera de Ignition para realizar un seguimiento de los cambios de proyectos, como Git. Los cambios en Ignition Designer se actualizan en el sistema de archivos. Ignition también monitorea continuamente el sistema de archivos en busca de cambios y los lee automáticamente.

Los proyectos también se pueden importar y exportar a través de un archivo (extensión .zip) y mover de Gateway a Gateway usando EAM.

Recomendamos utilizar una herramienta de control de fuente externa para realizar un seguimiento de los cambios del proyecto, como Git. Puede convertir la carpeta del proyecto en un repositorio y utilizar herramientas para implementar cambios desde el desarrollo hasta las pruebas en entornos de producción fuera de Ignition.

Resumen de la Pista de Cambios


 Configuración de Puerta de EnlaceEtiquetasImágenesProyectos
Seguimiento de CambiosDocumentación Manual y Copia de Seguridad de la Puerta de Enlace, luego guardar en el Control de VersionesExportación de Etiquetas, luego guardar en el Control de VersionesExportación de Imágenes, luego guardar en el Control de VersionesNo se requiere exportación. Auto-guardado de cambios de la carpeta del proyecto en el Control de Versiones
Copias de SeguridadCopia de Seguridad de Puerta de EnlaceCopia de Seguridad de Puerta de EnlaceCopia de Seguridad de Puerta de EnlaceCopia de Seguridad de Puerta de Enlace

 

Entornos de Implementación

Ahora que tenemos una buena idea de cómo se almacena y funciona la configuración de Ignition, echemos un vistazo más de cerca a cada entorno para ver cuáles son las formas más eficientes de implementar en cada uno de ellos. En la arquitectura de referencia a continuación, verá los 3 entornos de Ignition separados (desarrollo, prueba y producción) junto con el módulo EAM de Ignition y un sistema de control de fuente como GitLab.

Ambientes

Desarrollo

El entorno de desarrollo (dev) es el entorno en el que se produce el desarrollo de Ignition activo. Este entorno es el primer paso del flujo de trabajo. Aquí, los desarrolladores están trabajando en la corrección de errores y las nuevas funciones antes de introducirlas en el entorno de producción. Es muy útil tener una rama separada en su sistema de control de código fuente llamada desarrollo para representar su entorno de desarrollo.

Hay 2 campos principales sobre cómo abordar el entorno de desarrollo: utilizar un entorno de desarrollo compartido o utilizar estaciones de trabajo individuales como su propio entorno de desarrollo. Un entorno de desarrollo compartido es donde tiene un servidor Ignition central dedicado al desarrollo en el que trabajan todos los desarrolladores. Un entorno de desarrollo individual es aquel en el que cada desarrollador tiene Ignition instalado en su estación de trabajo con su rama del proyecto. Hay pros y contras en cada enfoque. Ignition admite el desarrollo simultáneo y la mayoría de los clientes tienden a optar por un entorno de desarrollo compartido, por lo que no es necesario instalar nada en la estación de trabajo de cada desarrollador. Simplemente pueden iniciar Designer desde el servidor de desarrollo. Si se adopta un enfoque de entorno de desarrollo individual, la estación de trabajo de cada desarrollador deberá tener su Ignition Gateway configurada por separado. Independientemente del enfoque, los cambios deberán confirmarse en el repositorio de control de código fuente e implementarse a través del flujo de trabajo.

Por supuesto, esto presenta algunas preguntas reales que deben abordarse.

¿Necesito que los entornos de desarrollo y prueba tengan licencia?

No. Simplemente puede usar la licencia de prueba de Ignition para los entornos de desarrollo y prueba. Algunos clientes eligen comprar licencias para estos entornos para evitar tener que reiniciar cada 2 horas. La elección es completamente tuya.

¿Cuáles son las diferencias en la configuración de Ignition para cada entorno?

Es extremadamente importante comprender las diferencias de encendido en cada entorno. No pueden ser exactamente iguales. El entorno de producción se comunica con fuentes de datos en vivo, como dispositivos y bases de datos SQL y más. Es posible que no desee que sus entornos de desarrollo y prueba estén conectados a las mismas fuentes de datos en vivo. También puede tener diferentes fuentes de autenticación o modelos de permisos en los entornos de desarrollo y prueba. Aquí hay una pequeña lista de diferencias comunes:

  • Dispositivos o conexiones de PLC: uso de controladores nativos de Ignition
  • Conexiones OPC UA: conexión a terceros como Kepware o un PLC directamente
  • Conexiones de base de datos: conexión a una base de datos SQL como MySQL o MS SQL
  • Perfiles de autenticación: diferentes fuentes de autenticación o especialmente una contraseña de administrador o root diferente. A veces, desea bloquear el acceso a Designer y Gateway en el entorno de producción.
  • Perfiles de notificación de alarma: conexiones a correo electrónico, SMS o voz
  • Configuración de redundancia: a menudo tiene redundancia en la producción y no en el desarrollo o las pruebas.

Recomendamos mantener las mismas conexiones en cada entorno pero con diferentes direcciones IP o configuraciones detrás de escena. De esa manera, cualquier recurso que dependa de conocer el nombre seguirá funcionando de un entorno a otro. Por ejemplo, puede tener una base de datos SQL dedicada para cada entorno. Los 3 Ignition Gateways tendrán la misma conexión de base de datos por nombre, pero apuntarán a su base de datos SQL dedicada que puede ser local o remota. Las pantallas o consultas con nombre que utilizan esa conexión funcionarán en todos los entornos, ya que hacen referencia a la conexión por su nombre.

Documente estas diferencias para asegurarse de no implementar un cambio en la producción que apunte a un sistema de desarrollo o prueba.

¿Cómo simulo datos de dispositivos reales en desarrollo y pruebas?

Esta es una pregunta muy común ya que desea tener acceso a datos en vivo en todos los entornos. A veces hay limitaciones o problemas de rendimiento que deben entenderse. Por ejemplo, algunos PLC no admiten más de una conexión o se saturarían con varios servidores Ignition que sondeaban las mismas etiquetas varias veces. Hay varias formas de lograr el acceso a datos reales:

  • OPC UA: puede conectar sus entornos de desarrollo y prueba a su entorno de producción a través de OPC UA. El entorno de desarrollo tendría el mismo nombre de servidor OPC pero apuntaría a producción en lugar de apuntar a sí mismo. Tenga cuidado, ya que es posible que el desarrollo y las pruebas afecten a la producción, especialmente al escribir en etiquetas.
  • MQTT: esta es la forma recomendada de llevar datos en vivo a todos los entornos. Puede hacer que su entorno de producción publique todos los datos de etiquetas en un servidor MQTT central utilizando el módulo de transmisión MQTT de Ignition. Los 3 entornos pueden suscribirse utilizando el módulo de motor MQTT de Ignition y las etiquetas se descubren automáticamente. Cada entorno puede suscribirse sin afectar al otro. Nuevamente, tenga cuidado con la posibilidad de escribir en PLC activos. Los servidores MQTT tienen ACL (listas de control de acceso) que puede definir para que los entornos de desarrollo y prueba sean de solo lectura si es necesario.
  • Gateway Network: puede conectar sus entornos de desarrollo y prueba a su entorno de producción a través de Gateway Network de Ignition y configurar proveedores de etiquetas remotos. El entorno de desarrollo tendría el mismo nombre de proveedor de etiquetas, pero apuntaría a producción en lugar de ser local. Nuevamente, tenga cuidado con la posibilidad de escribir en PLC activos. Gateway Network de Ignition tiene seguridad de nivel de servicio para hacer que los entornos de desarrollo y prueba sean de solo lectura si es necesario. Este método generalmente no se recomienda.
  • Simulación de dispositivo:
  • Simulador de dispositivo programable: esta es quizás la mejor opción si no necesita datos de PLC en vivo. En su lugar, podemos usar el simulador de dispositivos programables de Ignition para simular datos de PLC. El simulador le permite definir cualquier ruta de etiqueta que desee junto con valores estáticos o dinámicos. Sus entornos de desarrollo y prueba utilizarán el simulador, mientras que el entorno de producción utilizará el PLC real. Siempre que mantenga el mismo nombre del dispositivo, las etiquetas serán idénticas en todos los sistemas. Consulte la documentación para obtener más detalles sobre el simulador: https://docs.inductiveautomation.com/display/DOC80/Programmable+Device+Simulator
  • SFCs: si necesita una simulación de dispositivo más avanzada, los SFC ofrecen una gran flexibilidad. El Simulador de dispositivo programable proporciona señales configurables, pero las señales no cambian según las acciones de un usuario. Los SFC, combinados con etiquetas de memoria, brindan una excelente manera de simular la funcionalidad básica del PLC, como HOA y estados de válvulas, flujos y más.
  • Simulador de software de PLC: muchos fabricantes de PLC ofrecen un emulador / PLC suave que puede ejecutar un programa de PLC real. Si Ignition puede conectarse al software a través de OPC, esta puede ser una buena opción para tener el programa PLC real con todas las etiquetas ejecutándose en un sistema que está completamente desconectado del equipo real.
  • PLCs adicionales: si tiene un sistema con una pequeña cantidad de PLC, a veces puede tener sentido tener PLC físicos separados para los entornos de desarrollo y control de calidad, especialmente si los cambios en la programación del PLC pueden implementarse al mismo tiempo que los cambios en el proyecto Ignition.

¿Qué pasa con las tablas SQL personalizadas que quiero sincronizar en cada entorno?

Como comentamos anteriormente, cada entorno normalmente tiene su propia base de datos SQL dedicada. No desea que el desarrollo y las pruebas funcionen en la misma base de datos que la producción. Generalmente, esto no es un problema para el historial integrado de Ignition, los grupos de alarma, auditoría y transacciones. Sin embargo, si crea sus propias tablas personalizadas e interconecta Ignition con esas tablas, tenemos que pensar en cómo garantizar que esas tablas (estructura) y posibles datos existan en todos los entornos. Por lo general, los desarrolladores lo hacen manualmente ejecutando las mismas instrucciones DDL (CREATE TABLE, etc.) en todos los entornos. En algunos casos, existen herramientas o técnicas de replicación que el sistema de base de datos puede utilizar para automatizar este proceso. Debe elaborar un plan para asegurarse de que los 3 entornos tengan la misma estructura y posiblemente datos como tablas de búsqueda.

Pruebas

Una vez que las características se implementan y se consideran bastante estables, se fusionan en la rama de prueba y luego se implementan en el entorno de prueba. Aquí es cuando la garantía de calidad entra en acción: los probadores van a los servidores de prueba y verifican que el proyecto funciona según lo previsto.

Es muy útil tener una rama separada en su sistema de control de fuente llamada prueba para representar su entorno de prueba. Permitirá a los desarrolladores implementar múltiples sucursales en el mismo servidor simultáneamente, simplemente fusionando todo lo que necesita implementarse en la sucursal de prueba. También ayudará a los evaluadores a comprender qué hay exactamente en los servidores de prueba en este momento, con solo mirar dentro de la rama de prueba.

Producción

Una vez que la función se implementa y se prueba, se puede implementar en producción. El entorno de producción también se conoce como en vivo, en particular para los servidores, ya que es el entorno con el que los usuarios interactúan directamente.

Recomendamos implementar siempre las versiones principales en producción en un momento programado, del cual todo el equipo está al tanto.

Módulo de Administración Empresarial

El módulo EAM proporciona una forma segura e intuitiva de administrar muchas instalaciones de Ignition desde una ubicación. Es ideal para grandes empresas que implementan múltiples puertas de enlace en vastas distancias geográficas, pero incluso las empresas con algunas puertas de enlace de encendido en una sola planta pueden beneficiarse de su capacidad para monitorear el rendimiento y automatizar la copia de seguridad y la recuperación desde una ubicación central.

Con el módulo EAM instalado, una puerta de enlace de encendido puede funcionar como la puerta de enlace del controlador central que se conecta, supervisa y gestiona cualquier número de puertas de enlace de agente remotas. Utilice Controller Gateway para coordinar y automatizar muchas tareas administrativas para Agent Gateways, que incluyen:

  • Verificar el estado y el diagnóstico
  • Asignar, actualizar, activar y desactivar licencias
  • Implementar módulos nuevos y actualizados
  • Recuperación de desastres
  • Copias de seguridad remotas
  • Actualización de Ignition remoto
Pasarela del Controlador EAM y Mejores Prácticas

Recomendamos configurar una puerta de enlace de controlador EAM dedicada o utilizar el entorno de desarrollo como controlador. Se recomienda utilizar EAM para el estado y el diagnóstico, las licencias, las copias de seguridad, la recuperación ante desastres y las actualizaciones. EAM proporciona la capacidad de mover proyectos y etiquetas de un entorno a otro. Puede usar EAM para mover etiquetas de un entorno a otro, pero no se recomienda usar EAM para mover proyectos, ya que se maneja mejor a través de un sistema de control de fuente.

Sistema de Control de Fuente

Un sistema de control de fuente es un sistema de control de versiones diseñado para rastrear cambios en el código fuente y otros archivos de texto durante el desarrollo de una pieza de software, como Ignition. Esto permite al usuario recuperar cualquiera de las versiones anteriores del código fuente original y los cambios que están almacenados. Los sistemas de control de fuente brindan muchos beneficios:

  • Mantener múltiples versiones de código
  • La capacidad de volver a cualquier versión anterior.
  • Los desarrolladores pueden trabajar en paralelo
  • Auditar la trazabilidad con una imagen clara de quién, cuál, cuándo, dónde y cuáles son los cambios.
  • Sincronizar el código
  • Copiar / Fusionar / Deshacer los cambios
  • Descubra la diferencia entre versiones
  • Proporciona una copia de seguridad completa sin ocupar mucho espacio
  • Revise la historia del cambio.
  • Capaz para proyectos tanto a pequeña como a gran escala
  • Capacidad para compartir y trabajar en el código en todo el mundo.

Hay muchos sistemas de control de fuente y le recomendamos que utilice el que le resulte más cómodo. GitLab y Git es un sistema de control de código abierto muy popular.

Ignition y Control de Fuente

Recomendamos almacenar todos los recursos de Ignition en un sistema de control de origen, incluidos proyectos, exportaciones de etiquetas, imágenes y copias de seguridad de Gateway. Los proyectos se gestionan mejor a través de un sistema de control de fuentes, ya que se almacenan en el sistema de archivos. Es extremadamente fácil empujar y tirar proyectos hacia y desde un sistema de control de fuente. Sin embargo, es importante definir un proceso para almacenar e implementar etiquetas, imágenes y la configuración de la puerta de enlace, ya que se almacenan en la base de datos SQLite interna de Ignition y no en archivos individuales.

Es extremadamente fácil comenzar a utilizar un sistema de control de fuente. Recomendamos instalar un sistema de control de fuente en un servidor dedicado o VM, o usar un sistema de control de fuente existente que ya esté configurado en su empresa. Simplemente configure un proyecto en el sistema de control de fuente para cada entorno de producción de Ignition único.

Ramas del Proyecto

Una rama es una versión del árbol de trabajo de un proyecto. Creas una rama para cada conjunto de cambios relacionados que realizas. Esto mantiene cada conjunto de cambios separados entre sí, lo que permite que los cambios se realicen en paralelo, sin que se afecten entre sí.

Después de enviar sus cambios a una rama, puede:

  • Cree una solicitud de combinación para combinar los cambios de una rama a otra
  • Realizar revisión de código en línea y obtener una vista previa de los cambios
  • Discuta su implementación con su equipo

Dado que tenemos 3 entornos separados en nuestro flujo de trabajo, se recomienda configurar 3 ramas separadas para cada proyecto:

  • Maestro: La rama principal utilizada para la producción.
  • Pruebas: la rama utilizada para las pruebas. No se produce ningún desarrollo en esta rama, pero los cambios se combinan desde el desarrollo hasta las pruebas para el control de calidad.
  • Desarrollo: La rama utilizada para el desarrollo activo.

Ahora que tenemos nuestro proyecto y nuestras ramas configurados, definamos cómo confirmar nuestros cambios en el repositorio.

Confirmación e Implementación de Cambios

Se está produciendo un desarrollo activo en el entorno de desarrollo. Una vez que las características se implementan y se consideran bastante estables, es hora de fusionarlas en la rama de prueba y luego implementarlas en el entorno de prueba. Recomendamos almacenar toda la configuración de Ignition en el repositorio. Repasemos cada elemento de configuración descrito anteriormente: proyectos, etiquetas, imágenes y configuración de la puerta de enlace.

Proyectos

Los proyectos se almacenan en el sistema de archivos, lo que facilita su compromiso con un sistema de control de fuentes. Simplemente convierta la carpeta del proyecto Ignition en el repositorio. Puede encontrar la carpeta de proyectos en el servidor de Ignition en esta ubicación:

Linux

Windows

Si el repositorio del sistema de control de código fuente está vacío, simplemente envíe la carpeta existente al repositorio. Si no existen proyectos en el sistema de desarrollo, simplemente extraiga el repositorio del servidor para agregar los proyectos.

Asegúrese de ignorar la carpeta .resources en su repositorio. No desea que ese directorio se comprometa con el repositorio, ya que será único para cada sistema. Vea el ejemplo a continuación.

A medida que se realizan los cambios, confirme y envíe los cambios desde el entorno de desarrollo al repositorio utilizando las herramientas adecuadas (GUI, herramientas de línea de comandos como git).

Cuando estemos listos para implementar los cambios en las pruebas, podemos fusionar los cambios del desarrollo a las pruebas y extraer los cambios del repositorio a la carpeta de proyectos en el servidor de pruebas.

Consulte el ejemplo de GitLab a continuación para obtener más detalles.

Etiquetas

Las etiquetas se almacenan dentro de la base de datos SQLite interna de Ignition, por lo que no existen como archivos que podamos enviar al repositorio. Sin embargo, podemos exportar etiquetas a un archivo. Hay 2 métodos para almacenar etiquetas en el sistema de control de fuente: exportación manual o automáticamente usando una secuencia de comandos Ignition Python para guardar el archivo en el repositorio.

En el método manual, el desarrollador puede exportar etiquetas a un archivo JSON en Ignition Designer y guardar el archivo en la carpeta del proyecto, enumerada anteriormente, cuando esté listo para enviar sus cambios al repositorio. Con este método, podemos exportar solo cuando sea necesario en lugar de tener que hacerlo automáticamente en cada guardado en el Diseñador.

A la inversa, en el método automático, podemos agregar una secuencia de comandos de Python en la secuencia de comandos de evento de puerta de enlace "Actualizar" que se ejecuta en cada diseñador guardado para exportar etiquetas a un archivo JSON y guardar el archivo en la carpeta del proyecto. Este es realmente el mejor método. Consulte el ejemplo de GitLab a continuación para obtener más detalles sobre el script.

Independientemente del método, es importante confirmar los cambios en el repositorio para realizar un seguimiento de los cambios de una versión a otra. Recomendamos almacenar el archivo tags.json en la siguiente ubicación:

Ignition ignorará el archivo.

Cuando estemos listos para implementar los cambios en las pruebas, podemos fusionar los cambios del desarrollo a las pruebas y usar el módulo EAM de Ignition para implementar cambios de etiquetas o importar las etiquetas al servidor de pruebas en Designer.

Si usa el módulo EAM para implementar cambios de etiquetas, consulte esta página para obtener más información:

https://docs.inductiveautomation.com/display/DOC80/EAM+in+the+Designer#EAMintheDesigner-TagDistributionforDevelopmentServers

Imágenes

Las imágenes se almacenan dentro de la base de datos SQLite interna de Ignition, por lo que no existen como archivos que podamos enviar al repositorio. Sin embargo, podemos exportar imágenes a una carpeta. Aquí, el desarrollador puede exportar imágenes en la herramienta de administración de imágenes en Ignition Designer a una carpeta dentro de la carpeta de proyectos cuando estén listos para enviar sus cambios al repositorio. Asegúrese de seleccionar todas las imágenes y carpetas en la Herramienta de administración de imágenes. Recomendamos crear un directorio ".images" en el directorio de proyectos y almacenar las imágenes en el directorio recién creado:

Por lo general, no querrá crear carpetas en el directorio de proyectos, ya que Gateway asume que cada carpeta es un proyecto. Sin embargo, la puerta de enlace ignorará los directorios ocultos o aquellos que comiencen con un "." personaje.

Cuando estemos listos para implementar los cambios en las pruebas, podemos fusionar los cambios del desarrollo a las pruebas e importar las imágenes al servidor de pruebas en Designer.

Configuración de Puerta de Enlace

La configuración de la puerta de enlace se almacena dentro de la base de datos SQLite interna de Ignition y no tiene funciones de exportación e importación. Dicho esto, recomendamos almacenar la última copia de seguridad de Gateway (.gwbk) en el repositorio. Aquí, el desarrollador puede guardar una copia de seguridad de la puerta de enlace en la página web de configuración de la puerta de enlace cuando esté listo para enviar sus cambios al repositorio.

Recomendamos crear otro directorio oculto en el directorio de proyectos para almacenar la última copia de seguridad de Gateway, similar a cómo se almacenan las imágenes en la sección anterior. Llame a este nuevo directorio ".gateway_backups":

Cuando estemos listos para implementar los cambios en las pruebas, podemos fusionar los cambios desde el desarrollo a las pruebas y realizar manualmente los cambios necesarios en la configuración de la puerta de enlace en el servidor de pruebas.

Defina su Flujo de Trabajo y Proceso

Debe definir su propio flujo de trabajo y proceso que todos comprendan. Asegúrese de responder todas las preguntas enumeradas anteriormente. Documente el proceso y proporcione a cada desarrollador una hoja de trucos. También recomendamos crear una lista de verificación durante la implementación para garantizar la precisión.

Ejemplo de GitLab

1. Instalar GitLab
Siga las instrucciones a continuación para instalar GitLab en un servidor central o VM:
https://about.gitlab.com/install/

2. Configure su contraseña de root
Usarás este usuario root cuando uses Git

3. Genere un token de acceso personal
Siga las instrucciones a continuación para crear un token para la publicación automática:
https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html

Asegúrese de verificar todos los alcances.

4. Configurar nuevo proyecto (repositorio)
Desde el panel, cree un nuevo proyecto con el nombre que desee. El proyecto estará vacío por defecto.

5. Configuración del entorno de producción
Supongamos que su entorno de producción ya está configurado. Simplemente puede instalar las herramientas de línea de comandos de Git y publicar sus proyectos en el repositorio.

Instalar herramientas de línea de comandos de Git

Windows

https://git-scm.com/download/win

Linux


Identificarse en Git
Ejecute los siguientes comandos:

Publicar proyectos en el repositorio
Navegue al siguiente directorio:

Primero agregue un archivo .gitignore para ignorar el directorio .resources.

Agregue la siguiente línea al archivo .gitignore:

Guarda el archivo. Ahora ejecute los siguientes comandos para inicializar y confirmar el repositorio:

Después de la confirmación inicial, configure la rama como maestra para futuras actualizaciones.

Ahora hemos comprometido con éxito nuestros proyectos. También necesitamos exportar y confirmar etiquetas, imágenes y configuración de puerta de enlace. Para las etiquetas, podemos exportar las etiquetas del Diseñador a un archivo tags.json. Para las imágenes, podemos usar la herramienta de administración de imágenes en el diseñador para exportar todas las imágenes a una carpeta llamada "imágenes". Para la configuración de la puerta de enlace, simplemente haga una copia de seguridad de la puerta de enlace. Tome todos los archivos y carpetas y guárdelos en el directorio de proyectos. Una vez agregados, use los siguientes comandos para enviarlos al repositorio:

Ajuste la secuencia de comandos anterior para Windows. Ahora todo está guardado en el repositorio.

6. Crear sucursales de desarrollo y prueba
Utilice la interfaz web para crear una rama de desarrollo y prueba a partir de la rama maestra. Automáticamente tendrán todo comprometido con la rama maestra. Siga estas instrucciones:
https://docs.gitlab.com/ee/gitlab-basics/create-branch.html

7. Configuración de desarrollo y pruebas
Instale Ignition en máquinas de prueba y desarrollo dedicadas o máquinas virtuales. Siga las instrucciones anteriores para instalar Git. Una vez que Git esté instalado, navegue hasta el siguiente directorio:

Elimina la carpeta de proyectos que ya existe. Está vacío ya que es una instalación nueva. Una vez eliminado, ejecute los siguientes comandos en ese directorio:

Navegue a la carpeta de proyectos ahora que se crea nuevamente. Ejecute los siguientes comandos para cambiar a la rama de desarrollo o prueba:

Cambie "desarrollo" arriba con "prueba" para la rama de prueba en el servidor de prueba.

Por último, debemos asegurarnos de importar las etiquetas y las imágenes en Designer. Puede utilizar EAM para importar etiquetas o importar manualmente en Designer. También necesitamos fusionar manualmente todas las configuraciones de Gateway, como crear bases de datos o conexiones de dispositivos, configurar perfiles de autenticación y más. Desafortunadamente, este es un paso manual pero importante para realizar un seguimiento de los cambios en estas áreas.

8. Confirmación automática de cambios desde el desarrollo
Ahora que tenemos el entorno de desarrollo configurado y los proyectos se han extraído de la rama de desarrollo, debemos configurar Ignition para que confirme automáticamente los cambios cuando un desarrollador presiona guardar en Ignition Designer.

Primero, necesitamos crear un script por lotes / shell en el directorio de datos llamado "git-auto-commit.sh" o "git-auto-commit.bat", por ejemplo en Linux:

El archivo contendrá las siguientes líneas:

Ajuste la secuencia de comandos anterior para Windows. Asegúrese de que el archivo tenga permisos ejecutables. A continuación, debemos llamar a este script cada vez que un desarrollador presiona guardar en Designer. Abra Ignition Designer y seleccione Proyecto> Eventos de puerta de enlace> Actualizar. Consulte la documentación para obtener más detalles:

https://docs.inductiveautomation.com/display/DOC80/Gateway+Event+Scripts#GatewayEventScripts-UpdateScript

Agregue la siguiente secuencia de comandos:

El script llamará al script por lotes / shell y confirmará los cambios en el repositorio cada vez que se guarde. Guarde el proyecto y consulte el repositorio en GitLab para ver la confirmación.

9. Etiquetas de confirmación automática
Puede ser útil exportar etiquetas automáticamente y guardarlas en el repositorio como parte del proceso de guardado. Para eso, simplemente ajuste el script Gateway Event Update a lo siguiente:

Ajuste las rutas de las etiquetas para incluir todos los proveedores de etiquetas que desea exportar. Las etiquetas se exportarán y guardarán en un archivo llamado tags.json dentro del directorio de proyectos en cada guardado. La confirmación se produce después de la exportación, por lo que el archivo se enviará al repositorio.

10. Implementar cambios
Una vez que hayamos terminado con nuestro desarrollo, debemos implementar los cambios en el entorno de prueba. Primero, necesitamos fusionar los cambios de la rama de desarrollo a la rama de prueba dentro de GitLab. Abra la interfaz de usuario y cree una solicitud de combinación desde la rama de desarrollo a la rama de prueba. De forma predeterminada, seleccionará la rama maestra, así que asegúrese de cambiarla a la rama de prueba. Asegúrate de desmarcar la casilla de verificación "Eliminar rama de origen" para no eliminar la rama de desarrollo. Consulte la documentación de GitLab para obtener más detalles:
https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html

Una vez que se crea la solicitud de fusión, debe aprobar la solicitud y fusionar los cambios en la prueba. Una vez que se fusionan los cambios, debemos implementar nuestros cambios en Ignition en el servidor de prueba.

a. Implementación de proyectos
Para los proyectos, solo necesitamos extraer los cambios del repositorio. Ejecute el siguiente comando en el servidor de prueba:

Una vez que se eliminan los cambios, Ignition actualizará automáticamente los recursos del proyecto. Los clientes se actualizarán automáticamente. Si ya tenía abierto Ignition Designer, deberá presionar Archivo> Actualizar proyecto para extraer esos cambios del servidor.

b. Implementación de etiquetas
El archivo de exportación tags.json se extraerá del paso anterior. Puede importar manualmente las etiquetas a las pruebas o utilizar EAM para implementar cambios de etiquetas.

c. Implementación de imágenes
Las imágenes se extraerán del repositorio del paso anterior. Tendrá que importar manualmente las imágenes a la herramienta de administración de imágenes en Ignition Designer.

d. Implementación de la configuración de la puerta de enlace
Tendrá que aplicar manualmente los cambios de configuración de la puerta de enlace al entorno de prueba. Esto incluye cambiar configuraciones, agregar conexiones de bases de datos, agregar conexiones de dispositivos y más. Esta es posiblemente la parte más difícil de implementar cambios desde el desarrollo hasta las pruebas y desde las pruebas hasta la producción. NO restaure la copia de seguridad de la puerta de enlace al implementar pruebas o producción, ya que existen diferencias en cada entorno.

 

Publicado en español el 08 de Octubre del 2021.

Originalmente publicado el 02 de Abril del 2020.

Fuente original: https://inductiveautomation.com/resources/article/ignition-8-deployment-best-practices


 Facebook   Instagram   Twitter   LinkedIn  YouTube 

Últimas publicaciones del blog

Your Dynamic Snippet will be displayed here... This message is displayed because you did not provided both a filter and a template to use.


Protocolos IIoT: Comparación de OPC UA con MQTT
En este artículo compararemos dos opciones en extremos opuestos: OPC UA y MQTT / Sparkplug.