Automatización ágil

La automatización ágil hace referencia a la aplicación de determinados principios, patrones y prácticas de desarrollo de software ágil en el área de desarrollo de software de automatización industrial y control de procesos. El término fue acuñado por HAL Software (Irlanda) en 2013.

Tradicionalmente, el software de automatización industrial se ha desarrollado utilizando lenguajes que no implementan completamente la programación orientada a objetos . El ciclo de vida del desarrollo de software está en línea con el modelo Waterfall . Por ejemplo, el modelo GxP ( Buenas prácticas de fabricación automatizada ) V que está generalizado en las industrias reguladas farmacéuticas . Sin embargo, había una creencia creciente de que el modelo era demasiado rígido, no permitía cambios suficientes a lo largo del ciclo de vida del desarrollo de software y no enfocaba las pruebas en función del riesgo. La última versión del modelo GxP avanzó un poco hacia las pruebas basadas en la evaluación de riesgos.

El último modelo GxP aboga por realizar pruebas y documentarlas en función del riesgo percibido por el usuario final (el paciente, en el caso de la industria farmacéutica).

De hecho, la guía GAMP5 de 2008 menciona explícitamente la programación ágil;

"El enfoque descrito en este documento está diseñado para ser compatible con una amplia gama de otros modelos, métodos y esquemas, incluidos: métodos de desarrollo de software como RAD , Agile, RUP o programación extrema ". (GAMP5) ^[1]

Sin embargo, existe un debate sobre si los métodos ágiles pueden realmente satisfacer los requisitos regulatorios, como se describe en el artículo sobre modelos y métodos de desarrollo de software alternativos en entornos GxP, de ISAP GMAP D_A_C_H SIG ASDMM. (Ingeniería farmacéutica, enero de 2012, vol. 32, n.º 1). La industria tiene cierta experiencia en proyectos de software ágiles de sistemas de ejecución de fabricación mal ejecutados y estas experiencias han tendido a reforzar la noción tradicional de que el ciclo de vida del desarrollo de software en cascada es la forma más sencilla de aplicar el rigor de ingeniería y las restricciones presupuestarias/de cronograma en un equipo de desarrollo de software.

El desarrollo de software de automatización ágil tiene el potencial de reducir el ciclo de vida del desarrollo y, al mismo tiempo, abarcar pruebas unitarias automatizadas, algo que la industria está demandando. Además, los aspectos de "no repetirse" del desarrollo de software orientado a objetos ágil que abarcan la extensión de clases de software a través de interfaces (la clase de software está abierta a la extensión pero cerrada a la modificación) son muy atractivos en una industria regulada donde la validación de cambios de software es particularmente costosa. El desarrollo de software ágil promueve una verdadera programación de software orientada a objetos que, a su vez, da como resultado un software que es más susceptible a cambios y menos propenso a fallar. ^[2]

Los dos patrones de diseño de estrategia más utilizados en sistemas de nivel superior de automatización industrial por lotes ( SCADA , Batch y MES ) farmacéuticos y otros son ISA S88 e ISA S95. Estos patrones se pueden implementar de manera que los comportamientos de acción (por ejemplo, método de lectura/escritura o método de encendido/apagado de comando de válvula) se encapsulen como interfaces utilizando lenguajes como C# o Java . ^[3] El desarrollo de software de sistemas de control comerciales está sesgado hacia la herencia y la subtipificación, y los otros principios de OOP ( encapsulación , polimorfismo ) no están expuestos al programador en la misma medida. Esta implementación incompleta de OOP aumenta la cantidad de esfuerzo de diseño requerido. Incluso los sistemas DCS comerciales propietarios como Emerson DeltaV están sesgados hacia la subtipificación y la herencia sin una forma sencilla de implementar un comportamiento a través de una interfaz o una construcción similar. (No hay forma de implementar herencia múltiple ).

El lenguaje de programación IEC 61131-3 es el más utilizado para programar sistemas PLC y DCS . No es un lenguaje verdaderamente orientado a objetos, ya que implementa solo un principio de OOP (herencia/subtipificación) y no encapsulación ni polimorfismo. Esto limita su capacidad para realizar pruebas unitarias automatizadas y encapsular comportamientos para la extensión de clases.

Generalmente, hay menos margen para encapsular comportamientos en la mayoría de los controladores industriales, excepto en las plataformas que ejecutan un sistema operativo más avanzado (por ejemplo, la plataforma Beckhoff Twincat) que se puede programar a través de IDE de alto nivel como Visual Studio .

Existe un estándar sustituto (IEC 61499) que está más orientado a objetos, pero la industria lo ha adoptado poco. Hay avances hacia la consolidación de IEC61131-3, en particular a través del estándar PLCOpen . Este enfoque para desarrollar una clase XML abstracta puede dar como resultado una biblioteca de módulos/tipos de clase probados que posteriormente se pueden instanciar e importar a la plataforma de destino .

Existe un creciente interés en la programación ágil basada en arquitecturas basadas en modelos (MDA), en la que primero se desarrolla un modelo independiente de la plataforma. Como resultado de los requisitos de presentación de solicitudes reglamentarias y la necesidad de protegerse contra litigios, la industria farmacéutica registra y guarda datos que deben reconstituirse para su posterior presentación de solicitudes o liberación de lotes (registros electrónicos de lotes). Un modelo desarrollado en el laboratorio piloto y utilizado como guía para la ampliación de la producción puede ayudar a la presentación de solicitudes. ^{[4] [5] [6]}