Automatización Minimizando costes de mantenimiento Una vez que una máquina y su aplicación HMI están en funcionamiento, incluso un pequeño ajuste puede tener consecuencias importantes. Líneas de producción enteras se detienen mientras que el desarrollador de software —que tuvo que hacer un viaje extra— intenta conseguir que el software de la máquina funcione de nuevo. Una forma efectiva de mantener los costes de mantenimiento controlados es con un software modular. Aplicaciones cuyas funciones están encapsuladas en elementos modulares son considerablemente más fáciles y menos caras de mantener. Stefan Hensel, B&R “Alo largo de la vida útil de una máquina”, explica Wolfgang Portugaller, jefe de los arquitectos de sis- temas B&R, “se gasta mucho más en la adaptación y mantenimiento del software de lo que cuesta realizar el primer desarrollo.” Además de los costes directos por cosas como lla- madas de servicio in situ, rápidamente se pueden añadir otros costes cuando hace falta apagar una máquina o una línea entera de productos, o cuando una actualización de software provoca nuevos errores en el sistema. En el intento de reducir el coste total de propiedad, los fabricantes de equipos están buscando maneras de hacer que el software sea más fácil y menos caro de mantener. Arquitectura de software moderna Hoy en día las arquitecturas de software más avanzadas per- miten desvincular la aplicación HMI de la lógica de control del equipo. “Las soluciones convencionales HMI están estrecha- mente vinculadas entre sí con la aplicación de la máquina”, explica Portugaller. “Eso significa que si se realiza un cambio en la lógica de control, también hay que actualizar la aplicación HMI. Por el contrario, si se rediseña la interfaz de usuario para ser más fácil de utilizar, también hay que adaptar la lógica de control”. “Nuestros clientes están encantados con lo fácil que es el mantenimiento del software con mapp View”, explica Wolfgang Portugaller, jefe de los arquitectos de sistemas de B&R. Para mostrar el valor de una determinada variable de proceso, por ejemplo, la propia variable a menudo esta ligada directa- mente al elemento de interfaz de usuario correspondiente. Y eso no es un problema en absoluto, siempre y cuando la máquina funcione sin cambios durante 20 años. “Por desgracia, casi nunca es el caso”, dice Portugaller. Las variables de proceso cambian de nombre; las pantallas de interfaz de usuario se rees- tructuran; se añaden nuevos usuarios. Incluso un pequeño ajuste puede suponer a menudo una gran cantidad de programación. Una manera de mitigar este problema es seguir el principio de diseño de software de separación por capas (SoC). En el contexto del software HMI, SoC significa mantener una clara separación entre el dieño de las pantallas de interfaz de usuario y los datos que se mostrarán en ellas. El intercambio de datos a través de OPC UA “Hemos aplicado este principio rigurosamente a cada aspecto de nuestra nueva solución HMI de mapp View ” explica Portugaller. Para la comunicación entre el control y las aplicaciones HMI, mapp View se basa en el estándar OPC UA independiente. Para mostrar un valor de temperatura, por ejemplo, la aplicación HMI no consulta la variable de proceso en la aplicación de control, sino más bien el valor proporcionado por el servidor OPC UA en el control de la máquina. Menor posibilidad de errores “Las ventajas de este tipo de arquitectura se hicieron particular- mente evidentes” señala Portugaller, “cuando llega el momento de volver a utilizar uno de los componentes, construir una nueva variable de la máquina o implementar cambios durante el man- tenimiento”. Para modificar el rango de valores de una variable de proceso, - incluso una en la que se visualice en 10 pantallas de interfaz de usuario diferentes —sólo hay que hacer el cambio una vez en el servidor OPC UA—. Esto prácticamente elimina 124