Elaboración de un modelo de digitalización de activos para el mantenimiento industrial 4.0

Proyecto Fin de Carrera Ingeniería de Telecomunicación Formato de Publicación de la Escuela Técnica Superior de Ingeniería Autor: F. Javier Payán Somet Tutor: Juan José Murillo Fuentes Dep. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2013 Proyecto Fin de Carrera Ingeniería de Tecnologías industriales Elaboración de un modelo de digitalización de activos para el mantenimiento industrial 4.0 Autor: Pilar Jiménez Alonso Tutor: Antonio Jesus Guillén López Dpto. Organización Industrial y Gestión de Empresas I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 Proyecto Fin de Carrera Ingeniería de Tecnologías industriales Elaboración de un modelo de digitalización de activos para el mantenimiento industrial 4.0 Autor: Pilar Jiménez Alonso Tutor: Antonio Jesus Guillén López Profesor Titular Dpto. Organización Industrial y Gestión de Empresas I Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 Proyecto Fin de Carrera: Elaboración de un modelo de digitalización de activos para el mantenimiento industrial 4.0 Autor: Pilar Jiménez Alonso Tutor: Antonio Jesus Guillén López El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores: Presidente: Vocal/es: Secretario: acuerdan otorgarle la calificación de: El Secretario del Tribunal Fecha: Agradecimientos A mi familia, y en especial a mis padres por su paciencia y ayuda durante todo este proceso, y por enseñarme siempre con el ejemplo, como con trabajo y esfuerzo todo es posible. A mi profesor, jefe y tutor Antonio Guillén, no solo por su ayuda y guía durante la realización de este trabajo, sino también por brindarme la gran oportunidad de trabajar a su lado en este proyecto, permitiéndome aprender y adquirir tantos nuevos conocimientos y experiencia, e impulsarme a conocer este ámbito de la ingeniería como es el mundo de la investigación; además de tener la ocasión de poder conocer a grandes profesiones del sector tanto dentro de esta universidad como de fuera de ella. Sevilla, 2022 I Resumen Como consecuencia de la digitalización de procesos que se viene desarrollando en los últimos años, han ido apareciendo numerosas referencias que proponen metodologías de digitalización para las organizaciones industriales; sin embargo, destaca la ausencia de referencias generalizadas que faciliten la digitalización de nuevas empresas y permitan la interoperabilidad con el resto de sistemas. Es por dicha razón que este trabajo propone un modelo de digitalización de activos, enfocado principalmente en la fase de mantenimiento industrial, que permita la conectividad y funcionalidad industrial 4.0 de los activos. Basada en la revisión realizada de la literatura científica, se describe el desarrollo de una referencia de visión global, con el fin de estandarizar y simplificar el proceso de digitalización de activos, y facilitar la gestión de su mantenimiento, dificultada en muchas ocasiones debido a la gran variedad de conceptos y metologías, y la discrepancia entre ellos. Para la validación y justificación de la solución propuesta se plantea además una prueba de conceptos mediante un caso práctico a modo de ejemplo. III Índice de Figuras 1.1 Cronograma Proyecto INMA 7 1.2 Metodología de investigación de este trabajo. 8 1.3 Proceso de toma de decisiones de mantenimiento 14 2.1 Estructura modelo BIM 21 2.2 Ejemplo de relación IFC con los distintos elementos y sus clases 22 2.3 Componentes AIM [24] 24 2.4 Proceso propuesto por la norma PAS 1192-2: 2013 [54] 26 2.5 Proceso propuesto por la norma PAS 1192-3: 2014 [8] 26 2.6 Jerarquía del gemelo digital [31] 27 2.7 Componentes del Gemelo Digital 28 2.8 Estructura RAMI 4.0 [51] 30 2.9 Arquitectura propuesta por RAMI 4.0 30 2.10 Visión general de un ejemplo de aplicación [46] 32 2.11 Ejemplo de estructura del modelo AAS 33 2.12 Arquitectura interna RAMI 4.0 35 2.13 Estructura de núcleo propuesta por IMF 38 3.1 Conceptos básicos del modelo en mapa tridimensional 44 3.2 Fases del ciclo de vida del activo 45 3.3 Jerarquía de niveles del modelo 46 3.4 Capas de descripción de activo 47 3.5 Arquitectura de referencia ISO 23247 [52] 50 3.6 Arquitectura de referencia del CDT [59] 52 3.7 Comparación de componentes arquitecturas de referencia 53 3.8 Arquitectura de referencia propuesta 54 XI XII Índice de Figuras 5.1 Imagen de la vía a escala situada en la azotea de la escuela 71 5.2 Trayectoria de la vía en los ejes cartesianos 72 5.3 Vehículo a escala 72 5.4 Visualización de las secciones en la vía a escala 73 5.5 Estructura técnica del caso de uso 75 5.6 Ejemplo ubicación puntos de control (PCi) en la sección 77 5.7 Modelado del proceso de toma de decisiones 78 5.8 Ejemplo visualización cambios de estado 80 5.9 Arquitectura propuesta y elementos Azure 82 5.10 Ubicación de los elementos Azure en la nube 84 5.11 Proceso simplificado del transcurso de la información en la nube 85 1 BIM model structure 100 2 AIM model structure [24] 101 3 Digital Twin as “brick” of complex system’s digital twin [31] 102 4 RAMI 4.0 dimensions [51] 103 5 AAS architecture [57] 104 6 CDT dimensions [59] 105 Índice de Tablas 2.1 Definiciones de BIM 20 2.2 Definiciones de AIM 24 2.3 Análisis de E. Negri[39] de artículos de DT en la industria 29 2.4 Recopilación de referencias y normas 36 2.5 Recopilación de referencias y normas 39 2.6 Comparación de referencias según elementos IMF 40 3.1 Comparación elementos arquitecturas 57 3.2 Comparativa de las referencias con el modelo propuesto 58 4.1 Comparación elementos Azure - Google - Amazon 66 5.1 Variables de monitorización del caso práctico 76 5.2 Variables geométricas del caso práctico 76 5.3 Modos de fallo definidos 78 5.4 Relación elementos arquitectura propuesta y elementos Azure 81 1 Comparison of references on digital asset modelling 106 XIII 1 Introducción Este primer capítulo se enfoca en la presentación del trabajo y estudio llevado a cabo en la realización de este Proyecto Fin de Carrera. Para ello se describe la problemática actual que da interés a este estudio, se enumeran los distintos objetivos, y se plantean los resultados obtenidos. Asimismo, se incluye la descripción de la metodología de investigación utilizada, y una introducción al contexto del mantenimiento industrial. 1.1 Objetivos e interés del TFG Este Proyecto Fin de Carrera plantea la investigación y el desarrollo de un modelo digital completo de un activo o conjunto de activos, enfocado al mantenimiento industrial. En él, todos los datos e información disponible sobre los activos, a lo largo de su ciclo de vida completo, se estructurarán y gestionarán de manera optimizada teniendo en cuenta la interoperabilidad de todos los sistemas y tecnologías disponibles, además de los diferentes objetivos y procesos de la propia organización. Se puede afirmar como en la industria actual se viene desarrollando el proceso de digitalización de los activos físicos en gran parte de las empresas, surgiendo la necesidad de gestión de dichos activos digitales. Como consecuencia han ido apareciendo algunas referencias en un intento de dar solución a dicha gestión digital en casos concretos. La presencia de pocos estudios y referencias de soluciones generalizadas en este ámbito, y las discrepancias entre ellos, genera la aparición de dificultades, condicionando la correcta y óptima gestión del valor de la organización. Los principales retos a los que se enfrenta este estudio son: • La aparición de problemas de interoperabilidad de la información del activo, como consecuencia de la falta de concordancia entre el concepto de activo que proporcionan 1 2Capítulo 1. Introducción las distintas organizaciones. • La necesidad de estructurar de forma adecuada todos los datos, información y conocimientos de un activo, provenientes de las diferentes fuentes de información y tecnologías presentes en el propio activo o que interactúan con él. • La importancia de las funciones digitales en las que interviene propio activo, ya sean procesos o servicios que se ofrecen a partir del activo digital, y su relación con la toma de decisiones que afectan al activo físico en su ciclo de vida completo. • La falta de integración entre los sistemas, al ser la digitalización de las organizaciones, un proceso que se encuentra todavía en pleno desarrollo, y por tanto no aparece totalmente implementada en todos los aspectos de la empresa. • La ausencia de referencias durante la fase de mantenimiento de los activos, en la cuál se enfoca este proyecto. Las dificultades descritas añaden cierta complejidad al proceso; una primera conclusión previa al estudio, manifiesta la ausencia de una visión global y la carencia de modelos de referencia, que faciliten el desarrollo y la integración de las capacidades de la digitalización para la posterior gestión de los procesos de las empresas. Como consecuencia aparece la necesidad de estudio de estos conceptos, y de desarrollo y estandarización de un modelado generalizado en esta industria, que dé una nueva visión a la digitalización y gestión digital de activos más completa e integrada orientada al desarrollo sostenible de las empresas y al mantenimiento. Se busca por ello: • Una definición concreta de concepto de activo digital, y descripción práctica de cada uno de sus componentes, que permita la estandarización de conceptos y metodología, facilitando el inicio de futuras investigaciones. • La elaboración de un modelo estándar completo orientado a su uso práctico en cualquier tipo de empresa o sector industrial, a través de la revisión de los diferentes modelos de activos usados en la industria. • Una referencia que permita crear un sistema complejo de activos digitales favoreciendo la interacción entre ellos, además de la interacción a través de una interfaz de usuario, facilitando la gestión y toma de decisiones con relación a dichos activos. • La realización de una prueba de conceptos con el propósito de demostrar todas las ventajas que puede aportar el modelo de digitalización que se quiere proponer a la problemática industrial actual. 1.2 Metodología 3 • La justificación y validación del modelo mediante una serie de casos prácticos industriales de referencia, como base para la implementación y uso del modelo. La búsqueda de los objetivos enumerados, lleva este trabajo a la consecución de los siguientes resultados: • Elaboración del estado del arte de modelos de activos digitales, mediante la revisión de las referencias de la literatura científica más recientes. • Desarrollo de una arquitectura de integración para el modelo de activos digitales propuesto. • Revisión de las tecnologías necesarias para la implementación de la arquitectura desarrollada, y comparación de las diferentes plataformas disponibles para ello, con la posterior elección de la plataforma Azure que ofrece Microsoft. • Realización de una prueba de conceptos y justificación de la arquitectura desarrollada a través de la tecnología seleccionada de Microsoft. • Validación del modelo de activos digitales mediante su implementación en el caso práctico de la vía de tren. El interés de este Proyecto Fin de Carrera surge de la colaboración en el Proyecto de investigación de la Universidad de Sevilla, “INMA: Estrategias de Digitalización de Activos para el Mantenimiento Inteligente", durante los últimos 8 meses, el cual me ha permitido formarme en este tipo de tecnologías, además de participar en el desarrollo y puesta a prueba del modelado que este proyecto desarrolla. 1.2 Metodología En este apartado se describe la metodología seguida durante la realización de la presente investigación, en dos líneas de trabajo diferenciadas. En primer lugar, se explica la estrategia de investigación adoptada desde el punto de vista del proyecto INMA; y acto seguido se expone la estrategia desarrollada durante la elaboración de este Proyecto Fin de Carrera, dentro del propio proyecto de investigación INMA. 1.2.1 Estrategía de investigación del proyecto En primer lugar, se analiza a grandes rasgos la metodología llevada a cabo en el proyecto de investigación INMA por el equipo de trabajo; esta se distribuye esencialmente en 4 4Capítulo 1. Introducción paquetes de trabajo técnicos (PTi), compuestos a su vez por diversas tareas (Tij), los cuales se desglosan a continuación: 1. Definición del dominio de la investigación y requerimientos: 1.1.−Estado del arte y tecnología disponible: consistirá en una revisión actualizada de la literatura científica incluyendo, gemelos digitales, plataformas IoT, uso avanzado de BIM para el mantenimiento, analítica predictiva, modelos de simulación, ontologías para el mantenimiento o sistemas de monitorización entre otros. Asimismo se establecerá un marco general para la interpretación de los resultados del proyecto. 1.2.− Análisis inicial de aplicabilidad industrial: acotación inicial de la posible aplicación industrial, y los requerimientos del desarrollo y uso del modelo. También se llevará a cabo un análisis de los procesos de toma de decisiones de mantenimiento, la caracterización del nivel de digitalización de estos procesos, además de los diferentes desafíos y barreras de entrada para su aplicación. 1.3.− Requerimientos y especificaciones para casos de uso: análisis de los casos de uso disponibles. Se analizarán los distintos sistemas, equipos y modos de fallo a considerar, además de los datos de monitorización y operativos disponibles, y las condiciones de acceso a los mismos. 2. Modelos analíticos como soporte a la toma de decisión inteligente: 2.1.− Soluciones y proceso de mantenimiento basado en condición (CBM): Se desarrollará una metodología que ordene, por una parte, los elementos básicos de estas soluciones; y por otro, el proceso end-to-end de este tipo de soluciones aplicadas al mantenimiento. Este desarrollo facilita la construcción y gestión de estas soluciones y el acceso a toda la información generada. Es un elemento fundamental de cara a la digitalización de los sistemas. 2.2.− Modelos de salud de activos y de coste de ciclo de vida: Se desarrollará un nuevo modelo que analice la información suministrada por el activo y relacionada con: la vida prevista del activo, las condiciones operativas y ambientales requeridas en el diseño, y las condiciones operativas y ambientales reales en la explotación del activo. Para la predicción de la evolución del modelo, este cálculo se integrará en un modelo de simulación. 2.3.− Modelos sistémicos: Se desarrollará estrategias para la modelización de la degradación a nivel de sistema, teniendo en cuenta el conocimiento de los mecanismos 1.2 Metodología 5 de fallo individuales/locales, sus dependencias funcionales, los factores externos que influyen y las incertidumbres asociadas. Se emplearán métodos de cálculo y simulación en el marco de la Inteligencia Artificial como los procesos de Markov, las redes bayesianas o Petri. 2.4.− Modelo de mantenimiento oportunista: Una vez modelados los escenarios de decisión es posible que determinadas acciones puedan realizarse en planes agregados por oportunidad. Estos planes se lanzan por la necesidad de una o varias acciones, pero incluyen adicionalmente otras acciones, que por su condición no serían necesarias en ese momento, pero por cuestiones de coste y movilización de recursos resulta óptimo realizarlas conjuntamente con las anteriores. Estos modelos emplean también herramientas de simulación. 3. Digitalización de la toma de decisión y marco AIM: 3.1.− Decisión de mantenimiento a nivel de activo/equipo: Se modelarán y parametrizarán los procesos de toma de decisión de mantenimiento a nivel de equipo/activo. Para ello se emplearán técnicas de análisis funcional, riesgo y mantenimiento, y modelos de indicadores de seguridad de funcionamiento. Se modelarán con especial detalle, los procesos de toma de decisión vinculados al mantenimiento predictivo. Se plantearán también distintos niveles de digitalización de la toma de decisión, siendo el nivel más bajo aquel en el que sólo se registran los datos básicos de la decisión y su ejecución, frente a la automatización completa de la decisión que conllevará el nivel más alto de digitalización. 3.2.− Decisión a nivel sistema/flota y a nivel de ingeniería de mantenimiento: en relación al conjunto de información y datos disponibles, se pueden llevar a decisiones que no afectan sólo a un activo en particular, sino a decisiones que afectan a varios activos o a la totalidad de la flota. Los modelos sistémicos incluyen la modelización de cómo determinados fallos y efectos de los fallos pueden impactar o propagarse a lo largo del sistema. Se analizará la información necesaria y el contexto de decisión de estos departamentos. En esta tarea se incluyen decisiones con gran impacto en la empresa como pueden ser decisiones generales sobre tipos de actuaciones de mantenimiento, detalles técnicos, modificaciones en los sistemas, o cambios de proveedores entre otras. 3.3.− Marco para el diseño implementación y uso del AIM: Se analizan la información necesaria y el contexto de decisión de estos departamentos. En esta tarea se llevarán 12 Capítulo 1. Introducción La gestión de activos proporciona un soporte estratégico y práctico adaptado a las dificultades actuales de organizaciones y entornos de negocio. Este modelo converge así, el empleo de principios y métodos de los sistemas de gestión, con la integración de las innovaciones tecnológicas. Los principios estratégicos de la gestión de activos persiguen que la organización alinee y ajuste los recursos para satisfacer las necesidades de los clientes, en un entorno competitivo, y con el fin de maximizar los rendimientos para sus diferentes grupos de interés. De esta manera el gestor de activos se convierte en el respondable de los principales recursos de la organización, alineando los objetivos de su gestión con los objetivos del negocio, creando valor a largo plazo para las diferentes partes interesadas. En sistemas industriales complejos y en el actual contexto 4.0, se demuestra cómo lo anterior sólo es posible mediante el empleo avanzado de las tecnologías de la información y las comunicaciones, que están revolucionando la manera en que los sistemas se mantienen y gestionan. Entre las consideradas tecnologías habilitadoras de la Industria 4.0 destacan aquellas tecnologías centradas en el tratamiento avanzado de los datos, la información y el conocimiento. Es necesario profundizar en la búsqueda de metodologías de análisis y modos de uso que permitan abrir estas técnicas a la organización, ya que la integración con los aspectos clave de la gestión las enriquece y permite vislumbrar su verdadero potencial transformador. En un intento de dar soporte a la gestión orientada al valor de los activos, así como a los riesgos que dicha gestión conlleva, los organismos de normalización llevan a cabo su aportación con la publicación de la serie de normas ISO 55000:2014 sobre Gestión de Activos. Este conjunto de normas presenta, de forma generalizada, los requerimientos mínimos necesarios para establecer, implementar, mantener y mejorar, la gestión de cualquier tipo de activo, estableciendo un enfoque estratégico que permita incorporar las operaciones y las aplicaciones de mantenimiento para mejorar la disponibilidad y utilización de los activos. Estos requerimientos, traducen las necesidades de todas las partes interesadas de una organización, y permiten medir, y así mostrar ,la capacidad de la misma para cumplir los requisitos legales, así como los propios de objetivos estratégicos de la organización, reflejo del concepto de valor de la organización. Gestión del mantenimiento Son muchas las actividades relacionadas con la gestión de activos que se han venido realizando desde que se empezaron a utilizar bienes de capital, edificios, sistemas de transportes, o cualquier otro tipo de activo de producción o de prestación de servicios. 1.3 Contexto de Gestión de activos y mantenimiento 13 Sin embargo, una gran mayoría de ellas han estado ligadas al mantenimiento, entendido como la función empresarial encargada del control de las instalaciones, así como de los trabajos de reparación y revisión, para garantizar el funcionamiento regular y el buen estado de conservación de las instalaciones productivas, servicios e herramientas para el control de los procesos de las organizaciones. El concepto de mantenimiento aparece definido por la norma UNE EN 13306 [ 55 ] como la “combinación de todas las acciones técnicas, administrativas y de gestión realizadas surante el ciclo de vida de un elemento, destinadas a conservarlo o a devolverlo a un estado en el que pueda desempeñar la función requerida”. El mantenimiento enlaza dos aspectos que lo colocan como pieza clave de esta revolución tecnológica; por un lado, es uno de los componentes básicos de la gestión de activos; por otro lado, es además el principal campo de aplicación de la monitorización y las técnicas analíticas, y, por tanto, donde éstas están teniendo un mayor desarrollo e impacto. La gestión del mantenimiento ha pasado en los últimos años a un primer plano, convirtiéndose en una cuestión empresarial de gran importancia, como consecuencia del impacto que tiene como actividad de valor añadido, al permitir con sus acciones una mejora del estado de los activos, y por ende un aumento de su vida útil, lo que supone un mayor rendimiento del activo. Esta norma incluye también una definición para la gestión del mantenimiento: "todas las actividades de la gestión que determinan los requisitos, los objetivos, las estrategias y las responsabilidades del mantenimiento y la implantación de dichas actividades por medios tales como la planificación del mantenimiento, el control de este y la mejora de las actividades de mantenimiento y las cuestiones económicas". Existen principalmente dos estrategias de mantenimiento, según si la actividad de mantenimiento se realiza después o antes de que se produzca el fallo, como son el mantenimiento correctivo y el preventivo respectivamente. Dentro de este último se pueden distinguir además dos sub tipos de mantenimiento preventivo como son el mantenimiento programado o predeterminado y el mantenimiento basdado en la condición. La norma UNE EN 13306 [55] define estos conceptos de la siguiente forma: •Mantenimiento correctivo : "mantenimiento que se realiza después del reconocimien- to de una avería y que está destinado a poner a un elemento en un estado en que pueda realizar una función requerida". •Mantenimiento preventivo : "mantenimiento llevado a cabo para evaluar y/o mitigar la degradación y reducir la probabilidad de fallo de un elemento". 14 Capítulo 1. Introducción −Mantenimiento predeterminado : "mantenimiento preventivo que se realiza de acuerdo con intervalos de tiempo establecidos o con un número definido de unidades de funcionamiento, pero sin análisis previo de la condición del elemento." −Mantenimiento basado en la condición: "mantenimiento preventivo que incluye una combinación de la evaluación de las condiciones físicas, el análisis y las posibles acciones de mantenimiento posteriores". Figura 1.3 Proceso de toma de decisiones de mantenimiento. En relación a la primera estrategia de mantenimiento definida, su principal ventaja consiste en la amortización total de la inversión realizada de los activos, ya que este no se sustituye hasta del final de su ciclo de vida, momento en el que se produce el fallo o avería. Sin embargo, son varios los inconvenientes que esto conlleva tanto en relación a las consecuencias que producen los fallos, por ejemplo, en materia de seguridad, medio ambiente o daños colaterales provocados a otros activos; como en relación a la planificación de la propia actividad de mantenimiento, al no poder llevarla a cabo como resultado de necesitarse de manera inesperada. El mantenimiento preventivo, sin embargo, destaca por ser una actividad planificada, que permite reducir la tasa de fallos de los activos, y las averías inesperadas. Con respecto a los principales inconvenientes de esta estrategia, aparece la realización de una estimación demasiado conservadora en términos de la tasa de fallos del activo lo que podría llevar a 1.3 Contexto de Gestión de activos y mantenimiento 15 un mantenimiento excesivo, frente a una estimación demasiado optimista que podría por el contrario llevar a fallos imprevistos. Las estrategias de mantenimiento descritas, ya sea por separado o en combinación de las dos, persiguen una serie de objetivos [32]: • Objetivos de carácter técnico: vinculados a acciones operativas como la disponibilidad de los equipos o la seguridad del personal. • Objetivos de carácter legal: ligados a las diferentes normativas de obligado cumplimiento presente en cada sector. • Objetivos de carácter financiero: relacionados con la consecución de los objetivos técnicos a costes mínimos, teniendo además en consideración el rendimiento de ciclo de vida de los equipos buscando su maximización. Además de los ya descritos, otros objetivos quizás no tan esenciales, del mantenimiento, serían los propios objetivos de las organizaciones; como consecuencia de estar la gestión de los activos directamente relacionada con la propia estrategia de la organización, el mantenimiento deberá enfocarse como objetivo final al aumento de los resultados empresariales. Los modelos de mantenimiento se convierten por tanto en una herramienta realmente poderosa para la optimización, combinación e implementación de las diferentes estrategias de mantenimiento, de modo que se alcancen todos los objetivos descritos. Al ser el fin principal de la propuesta de este trabajo la gestión del mantenimiento de activos digitales, con el objetivo de mejorar la fiabilidad de los sistemas de activos, previniendo la aparición de fallos y reducir el coste global del mantenimiento; toma especial importancia en este trabajo las acciones de mantenimiento preventivo, siendo aquellas que se pueden gestionar en la toma de decisiones. A continuación se describe cómo se va a llevar a cabo la toma de decisiones de mantenimiento a través del modelo propuesto. Gestión del riesgo En primer lugar, cabe mencionar dentro de la gestión del mantenimiento de los activos, la gran importancia que tiene el concepto de riesgo, entendido como la consecuencia de multiplicar la frecuencia o probabilidad de un fallo por la severidad del mismo [ 43 ].El proceso de gestión del riesgo aparece definido en la ISO 31000 [ 16 ] como: "el conjunto de actividades coordinadas para dirigir y controlar la organización con relación al riesgo", definiendo también este último concepto como "el efecto de la incertidumbre sobre los objetivos". 16 Capítulo 1. Introducción Este proceso comienza en la recogida de datos e información mediante la ejecución de diferentes ensayos o del propio proceso de actividad del sistema. Los resultados obtenidos de estos ejercicios son los denominados eventos. Toda esa información disponible es llevada al nivel de riesgo a través de una especie de traductor universal, mediante el uso de distintas herramientas de análisis predictivo. Los eventos se entienden como aquellos momentos, registrados o programados en el que el nivel de riesgo de los modos de fallo afectados por dicho acontecimiento debe volver a analizarse, es decir, tras la obtención de una serie de medidas, mediante la observación de estos y la comparación con unos rangos o intervalos predefinidos, se interpreta esta información, pudiendo influir en cambios en los estados de los activos [ 33 ]. Existen en la industria principalmente dos tipos de eventos, por un lado, tenemos los eventos de monitorización o inspección, frente a los eventos de acción de mantenimiento. •Evento de monitoreo , son aquellos eventos o momentos que se programan a partir de la información generada por el proceso de monitorización del activo. Pueden ser eventos de detección, de diagnóstico o de pronóstico. Se pueden obtener de forma directa a través de las variables obtenidas, o mediante la combinación y cálculo a partir de diferentes datos recogidos. •Eventos de acción de mantenimiento , son aquellos que se encargan de la ejecución de tareas de mantenimiento preventivo. Las acciones preventivas son aquellas que se ejecutan antes de que se produzca un fallo con el objetivo de evitarlo. Estos eventos pueden ser programados o no planificados. Se supone que las acciones preventivas permiten controlar los niveles de riesgo de fallo, ya sea reduciendo el nivel de riesgo o garantizando que el equipo se mantenga en un estado tal que el nivel siga siendo aceptable. Se considera que tanto los eventos de monitoreo como los de mantenimiento preventivo provocan un cambio en el nivel de riesgo en los modos de fallo definidos. Es por ello que la existencia de eventos desencadena una necesidad de revisión o reevaluación del análisis de riesgo, para evaluar los efectos de dichos eventos en los estados de los activos. Se considera importante mencionar como un mismo evento puede afectar al mismo tiempo a diferentes modos de fallo, y de forma diferente para cada uno de ellos en términos de nivel de riesgo. Este riesgo se aprecia en los activos a través de la definición de una serie de estados que permiten identificar el nivel de riesgo al que se encuentra el activo que se pretende gestionar. Aparece entonces el concepto de evaluación dinámica de riesgos como un método propuesto que analiza los resultados de los eventos en cuanto a su impacto en nivel de riesgo 1.3 Contexto de Gestión de activos y mantenimiento 17 de fallo, y facilita la planificación y gestión de la toma de decisiones de mantenimiento en función de la evolución del riesgo. El proceso descrito de toma de decisiones partiendo de los datos recogidos de ensayos y eventos, pasando por su traducción a niveles de riesgo para su posterior evaluación, será el utilizado para la validación del modelo en la implantación del caso de uso, por esta razón este proceso para la toma de decisiones se desarrolla con mayor detalle en el apartado de descripción del caso de uso. 2 Estado del arte de modelos de activos digitales En este capítulo se procede siguiendo la metodología expuesta en el apartado anterior, a la realización del estado del arte de los diferentes modelos de digitalización de activos encontrados en la literatura científica. Para ello se llevará a cabo una revisión de las referencias encontradas de modelos enfocados a la gestión inteligente de los activos digitales, y la posterior comparación de sus principales elementos y retos a los que se enfrentan; además de la revisión de las diferentes normas que proponen la estandarización de los modelos analizados. 2.1 Modelado digital de activos Para llevar a cabo la importante labor de la gestión de activos digitales, surge en la industria el concepto de modelo de activos, y a su vez un gran número variantes de este tipo de modelos. Nos encontramos ante un concepto que no está estandarizado en la industria actual; la UNE ISO 29481-1 [ 26 ] define un modelo como “como la representación de un sistema que permite el análisis de las propiedades del sistema”; sin embargo, no existe en la literatura una definición estandarizada de lo que sería el concepto de modelo de activos. Esto conlleva a la aparición de numerosos modelos en la industria, que aunque con un objetivo similar, difieren en muchos aspectos, tales como las tecnologías implantadas, la forma de gestionar los datos, o la manera de definir o describir un mismo activo. Este apartado se centra en el estudio de los principales y más usados modelos de activos que se pueden encontrar en la industria actual; se analizan sus características más esenciales, 19 20 Capítulo 2. Estado del arte de modelos de activos digitales las principales dificultades o problemas a los que se enfrentan cada uno de estos modelos, además de las diferencias y similitudes que pueden encontrarse entre todos ellos. 2.1.1 Building Information Model [BIM] El Building Information Model, conocido por su abreviación como modelo BIM, es uno de los modelos más usados en la industria actual. Aunque tiene aplicación en diversos sectores, entre ellos la industria de procesos, es en la construcción, edificación e infraestructura donde tiene, hoy en día, una mayor aplicabilidad. En un principio puede parecer que el enfoque centra la aplicabilidad del BIM al comienzo del ciclo de vida de la instalación; sin embargo, se estima que la fase de operación y mantenimiento constituye aproximadamente el 60% del coste total del ciclo de vida de una instalación o edificio. Por consiguiente, BIM permite un enfoque holístico para el diseño, la construcción y la gestión de estas instalaciones. Es por ello, y por su importancia en el sector, que se establece como uno de los modelos más referenciados de la industria. Son muchas las normas y las referencias que lo definen y presentan metodologías para su uso. En la Tabla 2.1 se exponen algunas de las principales definiciones que podemos encontrar en la literatura: Tabla 2.1 Definiciones de BIM. Referencia Definición [26] Uso de la representación digital y compartida de un objeto construido (incluidos edificios, puentes, carreteras, etc.) para facilitar los procesos de diseño, construcción y operación conformando una base confiable para la toma de decisiones. [54] Proceso de diseño, construcción o explotación de un edificio o activo de infraestructura utilizando información electrónica orientada a objetos. [56] Un modelo BIM está constituido por una serie de elementos virtuales que permiten generar la representación digital de las características físicas y funcionales de un activo a partir de bases de datos de información, tanto gráfica como no gráfica, asociadas a los elementos que la componen, de acuerdo con los requerimientos y usos específicos de cada una de las fases del ciclo de vida del activo. [45] El modelado BIM proporciona a los interesados en el proyecto la capacidad de intercambiar datos e información entre diferentes tecnologías y procesos a lo largo de todo el ciclo de vida de los edificios. [30] El BIM es un proceso emergente de diseño, construcción o explotación de un edificio o infraestructura que utiliza información digital orientada a objetos. Para este tipo de modelo [ 56 ] propone una estructuración mediante la generación de submodelos siguiendo dos enfoques distintos, tal y como se muestra en la figura 2.1. 2.1 Modelado digital de activos 21 Figura 2.1 Estructura modelo BIM. Por un lado, expone la necesidad de creación de diferentes modelos según la fase concreta del ciclo de vida en la que se encuentre el activo. Estos modelos que [ 56 ] definen como una "representación tridimensional digital de una intención constructiva", podrían denominarse modelos de evolución de ciclo de vida, entre los que podríamos encontrar: modelo de infraestructura existente, modelo de proyecto constructivo, modelo de licitación de obra o modelo para mantenimiento. Por otro lado, tanto [ 56 ] como [ 24 ] coinciden en la propuesta de crear modelos de lenguaje IFC (Industry Foundation Classes) para llevar a cabo una estructuración o división del activo en objetos o elementos según las relaciones padre-hijo que hay entre ellos, y que están asociados a una clase particular para su mejor gestión, facilitando el intercambio de información, sin pérdida o distorsión de los datos. Este lenguaje consiste en una forma de intercambio neutro, que se está fomentando a nivel internacional entre las empresas del sector de la construcción. Estos modelos en formato abierto sirven para compartir y transferir información estructurada a lo largo del ciclo de vida de los activos entre los agentes y parte interesadas, permitiendo desde la generación de modelos de soluciones con herramientas ajenas al software o la integración completa de dichos elementos como referencia en otros software; hasta la exportación de información o documentación asociada a los elementos modelados. 28 Capítulo 2. Estado del arte de modelos de activos digitales elementos base que no puede desglosarse más, que al unirse conforman gemelos digitales compuestos, como una combinación de gemelos digitales discretos. Estos a su vez serán integrados como un conjunto en un sistema de gemelos digitales compuestos. La figura 2.6 muestra de forma gráfica la jerarquización descrita. El establecimiento de relaciones y conectividad entre los gemelos digitales de varias entidades de forma automática es uno de los principales retos a los que se enfrenta el diseño de estos modelos de gemelos digitales, con el objetivo de intentar evitar futuros problemas de interoperabilidad entre ellos. Esta referencia presenta además una división del gemelo digital en tres componentes principales: datos, modelos y servicios o funciones. La figura 2.7 expone dicha descomposición. Figura 2.7 Componentes del Gemelo Digital. •Datos : entendido como toda aquella información necesaria para representar y comprender los estados y comportamientos del gemelo en el mundo real. Pueden ser tanto datos del ciclo de vida completo, como datos empresariales. •Modelos : podemos encontrar entre otros modelos de visualización, AR, simulación o modelos de datos; todos ellos necesarios para permitir al sistema describir, comprender, y predecir estados y comportamientos del gemelo. •Servicios : se pueden entender como las funciones internas que tiene un gemelo digital con respecto al activo. Son muchos los servicios que un gemelo digital puede ofrecer desde Descripción, Diagnóstico o Visualización, hasta la inclusión de interfaces para la integración con otros sistemas o gemelos digitales que puedan acceder a los datos y resultados del propio modelo. 2.1 Modelado digital de activos 29 Sin embargo, a pesar de ser una de las más arraigadas, ésta es sólo, una de las muchas visiones que se pueden encontrar, ya que el Gemelo Digital es uno de los modelos con más visiones diferentes en la literatura actual tal y como muestra E. Negri[ 39 ], mediante un análisis en el que compara los principales aspectos que exponen diferentes artículos enfocados al DT en la ingeniería industrial. Este análisis se incluye en la tabla 2.3. Tabla 2.3 Análisis de E. Negri[39] de artículos de DT en la industria. Ref. Campo de aplicación Industria 4.0 Big Data Ciclo de vida CPS Modelo semántico de datos [48] Fabricación Industria 4.0, IoT Sí Ciclo de vida del sistema de producción Sí Metainformación y semántica [49] Robótica Industria 4.0 No Ciclo de vida de sistemas técnicos complejos No No [9] Informática IoT Industrial No Ciclo de vida IoT No No [17] Fabricación CPS inteligentes No Ciclo de vida del sistema de producción Sí No [50] Fabricación Industria 4.0, IoT Sí Ciclo de vida de la producción Yes Modelo AutomationML para el intercambio de datos [6] Fabricación No No No No Base de datos con modelos CAD [4] Fabricación Productos inteligentes Sí Ciclo de vida de la producción Sí Gestión de datos semánticos [20] Robótica No No No No No 2.1.4 RAMI 4.0 El Modelo Arquitectónico de Referencia Industrie 4.0 abreviado como RAMI 4.0, es un estándar impulsado por la Plattform Industrie 4.0 [ 51 ], que combina los principales elementos de la Industria 4.0 en un modelo de capas de tres dimensiones. Es una arquitectura de referencia orientada al servicio, compuesta por un mapa tridimensional que desglosa los procesos complejos en paquetes más simples, englobando por un lado, el ciclo de vida del activo al completo, por otro, los niveles jerárquicos del sistema, y finalmente la arquitectura o capas funcionales del modelo. En la figura 2.8 se pueden observar las tres dimensiones que componen el RAMI 4.0, especificadas en la norma IEC/PAS 63088 [12]. 30 Capítulo 2. Estado del arte de modelos de activos digitales Figura 2.8 Estructura RAMI 4.0 [51]. Figura 2.9 Arquitectura propuesta por RAMI 4.0. Para cada una de las capas que se muestran en la figura 2.9, la Plataforma 4.0 [ 51 ], expone la definición de sus funcionalidades: •Ciclo de vida : Representado en el eje horizontal izquierdo de la imagen 2.8 anterior, muestra el ciclo de vida de instalaciones y productos, basado en la norma IEC 62890 para la gestión del ciclo de vida. Esta referencia [ 51 ] distingue entre dos etapas dentro del propio ciclo de vida, una primera etapa denominada "tipos", y una segunda conocida como "instancias"; el cambio de "tipo" a "instancia" se produce cuando el diseño y prototipo se han completado y el producto final se encuentra ya en proceso de fabricación. •Niveles de jerarquía : En el eje horizontal de la derecha se indican los niveles jerárquicos basados en una serie de normas internacionales como son la norma IEC 62264 2.1 Modelado digital de activos 31 y la IEC 61512, enfocadas en los sistemas de control e informáticos de las empresas. Estos niveles jerárquicos representan las diferentes funcionalidades dentro de las fábricas o instalaciones, desde el activo más simple como puede ser el producto, añadiendo complejidad de activos en la empresa hasta llegar finalmente a la conexión con el Internet de las cosas y los servicios, etiquetados como "Mundo conectado". •Capas funcionales : Por último, en el eje vertical se representa lo que RAMI denomina las capas funcionales. Esta referencia propone un conjunto de seis capas, cuya función consiste en describir la descomposición de una máquina en sus principales propiedades o funciones estructuradas capa por capa, como pueden ser por ejemplo la capa de comunicación, funcional o de integración. RAMI 4.0 proporciona así un entendimiento común entre las normas y los casos de uso dentro de las dificultades de la Industria 4.0, es decir, puede considerarse una especie de mapa tridimensional de soluciones para dichas dificultades, ya que proporciona una orientación para establecer los requisitos de las diferentes organizaciones, además de un conjunto de normas nacionales e internacionales con el fin de definir y seguir desarrollando la Industria 4.0. 2.1.5 Asset Administration Shell [AAS] El modelo AAS o Asset Administration Shell, se conoce como la base de interoperabilidad de la arquitectura RAMI 4.0, y surge de la necesidad de transformar la información a otros formatos debido a la falta de interoperabilidad del DT entre las distintas organizaciones. El AAS aparece en la literatura definido como: “Representación digital de un activo relevante, que proporciona una interfaz a una red de Industria 4.0 que permite la conexión con el elemento físico, y la comunicación con otros activos, así como el intercambio de información” [ 10 ]. Este modelo tiene como objetivo principal proporcionar información sobre un activo físico durante todo su ciclo de vida; esto podría entenderse como una ficha de almacén de datos e información de un activo concreto; es por esa razón que cada activo debe tener asociado un AAS propio. Estos modelos de información pueden estar ubicados directamente en el dispositivo, en una plataforma en la nube conectada a los dispositivos; o incluso almacenada en el borde, es decir, en un dispositivo que actúe como mediador entre los dispositivos y la nube [ 46 ] . ABB [ 46 ] propone además un ejemplo de aplicación, el cual se muestra en la figura 2.10, en el que se puede observar cómo se establece una conexión con la nube, la cual recibe información de los dispositivos a través del borde. 32 Capítulo 2. Estado del arte de modelos de activos digitales En la nube se almacenarán un conjunto de modelos de información de origen, y se definirán modelos de mapeo, los cuales intercambian información con los modelos de origen, y traducen dicha información al formato AAS, conectando ambos componentes. Los atributos en los modelos de origen que fueron etiquetados según unas referencias de clases preestablecidas, se transfieren a las correspondientes referencias semánticas en el AAS. La figura muestra además un ejemplo visual del formato de los modelos de información y el ASS. Figura 2.10 Visión general de un ejemplo de aplicación [46]. La Plataforma 4.0 [ 38 ] y [ 46 ] coinciden en una propuesta de modelo AAS como un metamodelo basado en diagrama de clases UML, con el objetivo de estructurar y simplificar 2.1 Modelado digital de activos 33 la representación de información del activo. Este metamodelo propone para el AAS una estructura jerárquica compuesta por submodelos, y estos a su vez por elementos. Este modelo aparece definido en la literatura compuesto por una serie de fragmento que lo estructuran y lo definen de la siguiente forma: •Submodelos : conforman el nivel superior de la estructura jerárquica de este modelo, son utilizados para estructurar un AAS en partes diferenciables. Cada submodelo estará referido a un dominio o materia de un activo concreto. •Elementos del submodelo : cada submodelo consta de un conjunto de elementos, como nivel inferior de la estructura de dicho modelo. Los elementos de cada submodelo describen el activo; es por ello que se entienden como aquellos datos, propiedades o funciones comprendidos como entidades que se encuentran en la base de la estructura del activo, y lo definen completamente. •Identificación : por último, el modelo AAS deberá estar dotado de dos identificadores únicos; uno para el activo en concreto, es decir, para la identificación de su ubicación física; y un segundo identificador para el Asset Administration Shell del activo, como manera de distinguir la integrante digital de dicho activo. Figura 2.11 Ejemplo de estructura del modelo AAS. 34 Capítulo 2. Estado del arte de modelos de activos digitales En la figura 2.11 se puede observar un ejemplo concreto de un modelo ASS, en el que se muestran la ubicación en la "ficha" de los identificadores, submodelos y elementos definidos [57]. 2.1.6 Cognitive Digital Twin [CDT] El Cognitive Digital Twin, surge como un concepto de modelo de evolución de lo que conocemos como un Digital Twin tradicional, enfocado hacia un modelo con características más cognitivas, es decir, hacia una representación más inteligente, integral y de ciclo de vida completo de los sistemas complejos. Dicha evolución se lleva a cabo mediante el desarrollo de ciertas capacidades como la capacidad de evolución del gemelo digital a lo largo del ciclo de vida del activo, y una mayor capacidad de razonamiento y autonomía con respecto al DT tradicional. Kiritsis [ 59 ], propone una estructura compuesta principalmente por tres dimensiones, siguiendo una estructura similar a la del RAMI 4.0 ya mencionada, de manera que cubra los principales aspectos de la Industria 4.0. Estas dimensiones serían: ciclo de vida completo, niveles de jerarquía del sistema y capas funcionales internas o digitales. La figura 2.12, muestra de forma gráfica las dimensiones del Cognitive Digital Twin y los diferentes componentes de cada una de ellas. •Fases del ciclo de vida completo : esta dimensión se centra en la gestión del ciclo de vida completo. A lo largo del ciclo de vida de un sistema, se crearán numerosos modelos digitales para dar soporte a las diferentes fases del ciclo de vida: inicio de vida (BOL), vida media (MOL) y fin de vida (EOL), cada una de estas fases puede tener múltiples modelos digitales relacionados. •Niveles de jerarquía del sistema : tiene el objetivo de especificar la estructura y los límites de un CDT. Para este modelo se propone una jerarquía que, comenzando por un sistema de sistemas como nivel más alto de la jerarquía, se va descomponiendo en sistemas, subsistemas, y componentes, hasta llegar a partes como nivel más bajo que no puede descomponerse más. •Capas funcionales : Esta última dimensión especifica las diferentes funciones internas que puede proporcionar un CDT; siendo la capa de Entidad Física la que representa el sistema en el espacio físico, mientras que las otras cinco capas representan diferentes funciones del CDT en el espacio digital, como son la gestión de modelos o servicios entre otros. 2.2 Revisión de estándares y referencias de modelos digitales 35 Figura 2.12 Arquitectura interna RAMI 4.0. Por último, cabe destacar como los principales retos a los que debe enfrentarse este tipo de modelo tienen relación con la complejidad del propio sistema como son: la complejidad de representación de los datos, y la complejidad que conlleva el proceso de actualización de los datos a lo largo del ciclo de vida completo del activo; además de problemas de interoperabilidad de la información. 2.2 Revisión de estándares y referencias de modelos digitales Una vez analizados los principales modelos de activos digitales que se pueden encontrar en uso en la industria actual, en este apartado se indaga en el campo de los estándares y normas industriales existentes para este tipo de modelos. A pesar de la cantidad de modelos, y el gran uso que se le da a estos en la industria, destaca la falta de metodologías normalizadas para cada modelo, a pesar de ser muchos los documentos que llevan a cabo diferentes intentos de estandarización. Es por ello en gran parte, que hay tanta variedad y tanta diversificación con respecto a conceptos y requisitos en este ámbito, lo cual lleva a plantearse como algo que tiene tanta importancia en la industria como es la gestión y en especial el mantenimiento de los activos debería de estar estructurado y normalizado, para así poder evitar los problemas que encontramos hoy en día en cuanto a falta de integración de la información y los sistemas a la hora de intentar implementar estos modelados, o incluso problemas de interoperabilidad entre los propios modelos. Entre las normas que se pueden encontrar en la actualidad, una parte considerable de ellas están enfocadas a modelos de tecnología BIM, usados principalmente durante las primeras fases del ciclo de vida, como son sobre todo las etapas de diseño y construcción, y estando además orientadas esencialmente al sector de la construcción. Mientras que otra 36 Capítulo 2. Estado del arte de modelos de activos digitales gran parte de los organismos de normalización se centran en el intento de estandarizar la creación y uso de gemelos digitales a lo largo del ciclo de vida completo del activo; lo cual justifica la importancia de este modelo en la industria, pero también como el hecho de que haya tantas referencias y tan poca homogeneidad complica la búsqueda de un único framework [44]. En la Tabla 2.4 se incluye una recopilación de algunas de las normas más utilizadas que se pueden encontrar en la literatura, destacando la antigüedad de cada una de ellas, el modelo que normalizan y la etapa del ciclo de vida en que se centra, además de un pequeño resumen del objetivo principal de cada una de estas normas. Tabla 2.4 Recopilación de referencias y normas. Ref. Referencias Año Modelo Ciclo de vida Resumen [54] PAS 1192-2 2013 BIM BOL-MOL Objetivo de estandarizar el proceso de entrega de proyectos, es decir, la entrega de toda la información necesaria desde la evaluación de requisitos, hasta las fases de operación y mantenimiento, para proyectos constructivos con BIM. [8] PAS 1192-3 2014 BIM, AIM BOL-MOL Especifica los requisitos para la gestión de información usando BIM, mediante la creación y uso de un AIM estandarizado, además de un entorno común de datos para el mantenimiento y control de la información. [26] ISO 29481-1 2018 BIM BOL Surge de la necesidad de fiabilidad en el intercambio de información; y propone una metodología para la elaboración de un documento de referencia (IDM) que describa e identifique los procesos, información y resultados requeridos en el desarrollo o gestión de una construcción. [13] ISO 19650-1 2019 BIM BOL-MOL Presenta los conceptos, principios, y recomendaciones para definir un marco de gestión de la información para obras de edificación que utilizan BIM. [31] IIC 2020 DT Full Proporciona una guía para la creación de un DT; partiendo de su definición, propone unas relaciones de jerarquía, y una arquitectura de diseño para el modelo de gemelo digital. [25] IMF 2020 DT Full Protocolo que propone una serie de requerimientos a estandarizar para el núcleo de un DT, además de exponer 12 pasos para la creación de un gemelo digital desde cero. [52] ISO 23247 2021 DT Full Proporciona un marco de desarrollo genérico que pueda ser instanciado para implementaciones de casos específicos de gemelos digitales en la fabricación. En el conjunto de estándares estudiados, destaca la importancia de la referencia IMF, como consecuencia de su enfoque a la elaboración de un sistema interconectado e integrado que evolucione con el tiempo, lo cual podría dar respuesta a algunos de los retos descritos en la introducción; y a su énfasis en la estandarización de ciertos elementos necesarios en 2.2 Revisión de estándares y referencias de modelos digitales 37 cualquier modelo, proponiendo así la generalización de un modelo común en la industria. 2.2.1 Information Management Framework [IMF] El Information Management Framework o IFM surge de la visión y la propuesta de crear un gemelo digital nacional, es decir, una infraestructura de gemelos digitales a nivel nacional con el objetivo de proporcionar información de calidad que apoye la toma de decisiones en relación al desarrollo, operación, mantenimiento y uso de las infraestructuras y los servicios que se prestan a los ciudadanos del país. Aparece como un protocolo o esquema que sigue una filosofía enfocada en la creación de modelos que permitan una integración completa de los datos e información, más allá de un simple intercambio, con el consecuente objetivo de una mejor gestión digital de los activos. Este framework propone además la estandarización de un conjunto de requisitos para el núcleo técnico del modelo de activos, conocido por el nombre de Commons, con el objetivo de apoyar el intercambio seguro de información, la interoperabilidad, la integración y la vinculación de datos y modelos en cualquier entorno. Dicho núcleo o Commons estaría formado por tres componentes principales definidos por dicha referencia de la forma: •Modelo de datos (Foundation Data Model (FDM)): “modelo ontológico coherente y claro, del mundo de los gemelos digitales, que incluye descripciones de conceptos generales independientes”. Este modelo deberá abordar las cuestiones propias de una ontología superior, permitiendo además la descripción de conceptos generales independientemente del dominio del problema al que se enfrente. •Librería de datos de referencia (Reference Data Library (RDL)): “conjunto particular de clases y propiedades necesarios para las descripciones propias de los gemelos digitales”. El RDL supone una referencia común para las partes que deseen intercambiar datos, consistiendo en un ecosistema evolutivo de bibliotecas vinculadas entre sí, es decir, un conjunto jerárquico e integrado de bibliotecas de datos de referencia. Además, proporciona una serie normas que especifican el nivel de detalle de información necesaria para su uso dentro del modelo. •Arquitectura (Integration Architecture (IA)): "protocolos que permitirán compartir datos e información de forma gestionada y segura, la producción de modelos, la elaboración de consultas y el análisis, interpretación y aplicación de los resultados". Esta arquitectura define las reglas y mecanismos necesarios para gestionar las combinaciones de los gemelos digitales. 44 Capítulo 3. Propuesta de modelo de activos digitales El modelo elegido para llevar a cabo el desarrollo de la referencia propuesta estará compuesto por un conjunto de gemelos digitales, interconectados entre sí, debido a las posibilidades que ofrece este tipo de modelos en la solución que se busca para los problemas planteados. Dentro del modelo de Gemelo digital elegido, aparecen los conceptos básicos mencionados, distribuidos en un espacio tridimensional siguiendo la propuesta que realiza RAMI 4.0, en el que se mueven los diferentes gemelos (DTi) que componen el modelo. Dicho mapa puede observarse en la figura 3.1; una vez ubicados, se procede a la discusión de estos conceptos básicos. Figura 3.1 Conceptos básicos del modelo en mapa tridimensional. Ciclo de vida En primer lugar, este estudio se enfocó en el estudio del ciclo de vida del activo y del propio gemelo. Con respecto a la vida del activo, basándonos en la descripción que hace el AIM del ciclo de vida, se realiza una división del ciclo completo en tres fases o etapas diferenciadas en el tiempo: •Beginning of life (BOL): o inicio de vida, engloba las primeras etapas de la vida del activo, como pueden ser las etapas de diseño y construcción entre otras. 3.1 Componentes básicos del modelado 45 •Middle of life (MOL): conocido como mitad de vida, se considera la etapa de mayor extensión, y se centra principalmente en la fase de operación, pero también de mantenimiento de los activos, es decir, conlleva toda la vida útil o de uso del activo. •End of life (EOL): final de vida del activo o últimas etapas del ciclo de vida; esta fase se enfoca en los periodos de reciclaje y búsqueda de revalorización de los activos de la empresa, una vez finalizada su vida útil. Figura 3.2 Fases del ciclo de vida del activo. Sin embargo, una de las características del modelo propuesto es la gestión del activo durante todo su ciclo de vida mediante un gemelo digital que almacene y gestione su información de forma que sea un modelo que vaya evolucionando a la vez que lo hace el propio activo, ofreciendo en cada etapa los requisitos que el activo demande. Como consecuencia cada activo tiene un único modelo asociado independientemente del momento de su vida en el que se encuentre. Cabe mencionar como el ciclo de vida no afecta únicamente al activo físico, sino también al propio modelo que podrá tener un ciclo de vida propio, independiente de la vida del activo. Jerarquía del modelo En segundo lugar, se define la jerarquía del modelo propuesto. La jerarquía se entiende como una composición de elementos ordenados según su importancia. El interés de este concepto surge de la presencia de un gemelo digital para cada entidad física existente en el sistema, lo que lleva a la creación de un modelo formado por un conjunto de gemelos digitales que deben estar conectados entre sí. Como consecuencia aparece una necesidad de ordenar y estructurar todos estos gemelos de cara a facilitar la gestión de los activos a los que representan. Además, la jerarquía presenta una gran influencia con respecto a las relaciones que tienen estos modelos entre sí. Estas relaciones permiten representar cómo un gemelo digital puede estar implicado con otros gemelos digitales; de forma que lo que afecta a uno o 46 Capítulo 3. Propuesta de modelo de activos digitales varios elementos de un conjunto pueda afectar en mayor o menor medida a dicho conjunto. Las relaciones permiten también que la solución proporcione un grafo de las entidades interrelacionadas. Se decide por tanto el modelo propuesto como un sistema compuesto de un conjunto de gemelos digitales estructurados en tres niveles diferenciados, siguiendo lo que expone [ 31 ]. En el nivel más bajo se encasillan los modelos DT más sencillos, conocidos como gemelo digital discreto, siendo gemelos digitales de entidades físicas que no pueden simplificarse más. El conjunto de gemelos digitales discretos compone un gemelo digital compuesto, como el conjunto de elementos o activos físicos simples. Finalmente, varios gemelos digitales compuestos se unen formando el último nivel de esta jerarquía, que se conoce como sistema de gemelos digitales compuestos. La jerarquía comentada se puede observar en la figura 3.3. Figura 3.3 Jerarquía de niveles del modelo. Cada uno de los gemelos digitales que se creen en el modelo, independientemente del nivel en el que se encuentren, tendrán una evolución a lo largo del ciclo de vida del activo, mediante su paso por cada una de las fases propuestas, o a través del enfoque único en una de las etapas, evolucionando dentro de ella. Descripción del activo El tercer y último punto importante a considerar en la construcción de este modelo ha sido la realización de la descripción del propio activo. Para ello se propone una estructura de tres capas que almacene toda la información necesaria para definir de foma única y completa al activo. Estas tres capas las cuales se representan en la figura 3.4, englobando en ellas todos los datos y características del activo son: −Clases −Ubicación técnica −Capa de señales 3.1 Componentes básicos del modelado 47 Esta estructura, al igual que el propio modelo de gemelo digital de activos, será única para cada activo, y evolucionará a lo largo del ciclo de vida del objeto al que este asociado, mediante de la evolución de sus elementos. La descripción del activo lleva al uso de una ontología completa. Una ontología es una base de datos relaciónal, compuesto por las diferentes entidades y las relaciones que aparecen entre ellos, que permite la representación completa de todo el activo [59] [34]. Figura 3.4 Capas de descripción de activo. •Clases En primer lugar, cada activo físico necesitará de un identificador de registro o matrícula, que permita identificarlo de manera única. Esta identificación se realizará a través de un conjunto de clases y subclases previamente definidas, tal y como propone el modelo BIM, creando categorías generales de los activos físicos. Para ello, se ha decidido tomar como base la forma que tiene de definir el activo el modelo AAS comentado en el estado del arte. Este modelo propone la creación de una “ficha” para cada activo elemental, la cual englobará la información necesaria para el modelado de este activo mediante la definición del tipo de entidad al que pertecene. Dicha ficha compondrá la primera capa necesaria para la descripción del activo. •Ubicación técnica Como segunda capa, el sistema necesitará de una estructura técnica, que permita la localización del activo en relación a los demás elementos físicos. Una misma clase de 48 Capítulo 3. Propuesta de modelo de activos digitales activo puede estar ubicado en más de una ubicación técnica, sin embargo, esta define a un único activo concreto, mediante un ID de ubicación técnica que se le asignará según su funcionalidad. La estructura técnica definida determinará asimismo desde una visión funcional, las relaciones entre las diferentes clases y subclases de los activos físicos. •Capa de señales Para finalizar con la descripción del activo, este deberá contener en su estructura una capa de señales, que almacene el conjunto de datos obtenidos a través de las diferentes fuentes de información durante el proceso de monitorización, que caracterice al activo en cuestión. A partir de esta información almacenada se definirán una serie de estados, que indiquen el nivel de riesgo, y permitan observar la evolución de los activos. El concepto de estado se define como el nivel cualitativo de riesgo en un momento dado. Se considera un elemento fundamental en la descripción del activo, una vez definidos sus tres componentes elementales. Se propone utilizar cuatro estados o niveles de riesgo de mayor a menos nivel de riesgo: •Fallo : estado que se activa después de producirse el fallo. Conlleva un requerimiento de sustitución o reparación inmediata del elemento que haya provocado el fallo o haya fallado. •Alto riesgo : estado de funcionamiento más próximo al fallo. Supone la programación de actividades a corto plazo para reducir el nivel de riesgo. •Riesgo medio : estado en el que se ha detectado una anomalía, pero es posible seguir operando en condiciones normales. A medio plazo se planifican actividades para confirmar el riesgo y analizar su evolución. •Riesgo bajo: estado de funcionamiento normal del elemento. Esta capa debe incluir además un identificador del sensor que realiza la labor de recogida de datos, facilitando la definición del activo, al poder tener un mismo activo diferentes sensores. Este último concepto se ubicará en un almacén interno común y accesible desde cualquier ubicación del modelo. 3.2 Arquitectura Tal y como se ha comentado en la revisión de la referencia IMF [ 25 ], esta propone tres elementos como los principales a desarrollar en un modelo de este tipo. En este trabajo 3.2 Arquitectura 49 se sigue la filosofía propuesta por dicha referencia, al coincidir con los objetivos de este estudio de estandarizar un sistema que permita la integración de la información e interoperabilidad de sistemas. Sin embargo, debido a la complejidad que supone el desarrollo completo del modelo, suponiendo la especificación de los tres componentes que presenta el IFM, como ya se ha mencionado este trabajo se centra en el desarrollo de la arquitectura. El concepto de arquitectura, según la RAE ("Real Academia Española") consiste en la estructura lógica y física de los componentes de un conjunto, es decir la completa definición de la estructura conceptual del modelado. La referencia IMF profundiza algo más en la definición de la arquitectura de integración como “protocolos que permitirán compartir datos e información de forma gestionada y segura, la producción de modelos, la elaboración de consultas y el análisis, interpretación y aplicación de los resultados”. De esta forma la arquitectura permite entender el conjunto de componentes y funcionalidades que tendrá el sistema; y es por ello que su estandarización es posible mediante la completa definición de su estructura especificando desde los diferentes módulos o dominios que la componen, hasta su ubicación y funcionalidad. La importancia de este componente reside en la posibilidad de generar una estructura simple generalizada que facilite su posterior implementación en cualquier situación u organización, frente al reto de tener soluciones particularizadas para cada caso lo cual dificulta su uso en otros casos distintos. 3.2.1 Arquitecturas de referencia ISO 232471 La primera de las arquitecturas elegida como referencia procede de la norma ISO 23247, Sistemas de automatización e integración, enfocada a la exposición de un marco de gemelos digitales para la fabricación [52]. Este estándar propone una arquitectura de visión funcional compuesta por cuatro dominios o entidades, con el objetivo de proporcionar un marco de desarrollo genérico que pueda ser utilizado para su implementación en cualquier caso específico de gemelos digitales en la fabricación. En la figura 3.5 se puede observar el esquema de la arquitectura propuesta, compuesto por los dominios: de usuario, de núcleo, de control y recolección de datos, y un dominio externo de observación de fabricación. Cada uno de los dominios que conforman esta arquitectura aparecen definidos por la referencia de la forma: 50 Capítulo 3. Propuesta de modelo de activos digitales Figura 3.5 Arquitectura de referencia ISO 23247 [52]. •Dominio externo de observación de fabricación : dominio que proporciona un contexto para el desarrollo del gemelo digital e interactúa con el dominio de recopilación de datos y control de dispositivos. •Dominio de recopilación de datos y control de dispositivos : este dominio se encarga de enlazar las OMEs (Observable Manufacturing Elements) o elementos de fabricación observables, con sus gemelos digitales para su sincronización mediante la recogida de datos de los sensores de las OMEs y el control y actuación de las OMEs. •Dominio del núcleo : dominio responsable del funcionamiento y la gestión general de un gemelo digital. En él se encuentran alojadas distintas aplicaciones y servicios como son el análisis de datos, la simulación y la optimización para permitir el aprovisionamiento, la supervisión, el modelado y la sincronización. Este dominio también puede interactuar con los usuarios del gemelo digital y con otros gemelos digitales. •Dominio del usuario : dominio responsable de la interacción entre los usuarios y los gemelos digitales. Pon usuario se entiende persona, dispositivo, o sistema que hace uso de algunas de las aplicaciones y servicios proporcionados por los gemelos digitales. 3.2 Arquitectura 51 Cada dominio está a su vez compuesto de diferentes tareas y funciones, tal y como se puede apreciar en la figura 3.5, que se realizan a través de las entidades funcionales (EF). Destacan esencialmente 5 entidades funcionales en esta arquitectura: •OMEs : Las entidades OME consisten en entidades funcionales específicas de cada recurso. •Entidad de Recogida de Datos y Control de Dispositivos (DCDCE) : La DCDCE está compuesta por una Sub-Entidad de Recogida de Datos para la recogida de datos de la OME y alimentación con dichos datos a la Entidad Central, y por una Sub-Entidad de Control de Dispositivos para controlar y actuar en la OME. •Entidad central (CE) : El CE es una entidad de gemelo digital, que incluye la Sub- Entidad de Operación y Gestión, la Sub-Entidad de Aplicación y Servicio, y la Sub- Entidad de Acceso e Intercambio de Recursos que permite representar y mantener digitalmente las OMEs. Dentro de cada subentidad, hay varias entidades funcionales, por ejemplo, la de Simulación en la Subentidad de Aplicación y Servicio. •Entidad de Usuario (UE) : La UE proporciona interfaces de usuario para interactuar con el CE. Puede ser un operador humano o una aplicación empresarial ya existente, como un sistema de ejecución de fabricación (MES), un sistema de planificación de recursos empresariales (ERP) u otros tipos de gemelos digitales. •Entidad intersectorial (CSE) : La CSE reside en todos los dominios para proporcionar funcionalidades comunes como la traducción de datos, el aseguramiento de datos y el soporte de seguridad. Además de los cuatros dominios ya descritos, y sus correspondientes entidades, cabe destacar como este documento propone un gemelo digital conectado con el activo físico, o elemento de fabricación observable, mediante una entidad de control y recolección de datos procedentes del objeto físico. Dicha entidad se conecta a su vez con el núcleo en el cual se almacenan las diferentes funcionalidades y servicios que ofrece el modelo, y con la entidad del usuario. CDT [59] El otro documento de referencia elegido [ 59 ], presenta una arquitectura para el modelo de Cognitive Digital Twin, cuya imagen gráfica aparece en la figura 3.6. Este documento propone la integración de todos los datos, información y conocimiento disponible relacionados con el sistema durante su ciclo de vida completo. Para ello este 52 Capítulo 3. Propuesta de modelo de activos digitales modelo, tal y como ya se comentó en el estado del arte, y en concreto esta referencia propone tomando como referencia RAMI 4.0 una arquitectura compuesta por capas funcionales. Figura 3.6 Arquitectura de referencia del CDT [59]. Realizando un análisis más profundo de las diferentes capas que presenta esta arquitectura podemos encontrar: •User Interaction : capa superior que permite la interacción entre las partes interesadas y el propio modelo. •Twin Management : capa que tiene como objetivo apoyar la actualización y orquestación de todos aquellos gemelos digitales que componen el modelo a lo largo de todo su ciclo de vida, actualizándose de esta manera en función a los nuevos datos y conocimientos. En él se incluyen los gemelos digitales de las diferentes entidades físicas. •Service Management : capa encargada del registro y orquestación de los diferentes servicios empresariales como pueden ser: servicios cognitivos, servicios basados en datos o servicios basados en modelos. 3.2 Arquitectura 53 •Model Management : utiliza tecnologías semánticas, como los gráficos de conocimiento y las ontologías para gestionar los diferentes tipos de modelos de DT almacenados en el repositorio de modelos. •Data Ingestion and Processing : este proceso se ayuda de brokers y adaptadores específicos para su realización. En función de los requisitos de los correspondientes servicios, los datos pueden ser procesados y analizados mediante técnicas de minería de datos soportadas por la computación en la nube. En esta capa se produce el almacenamiento de todos los datos y metadatos del modelo. •Physical Entities: capa que representa el Sistema real en el espacio físico. Esta referencia propone un modelo que difiere del gemelo digital tradicional, debido a la inclusión de ciertas capacidades cognitivas, presentándose como un modelado más maduro. Pero también expone como una de las principales diferencias entre CDT y DT, como el DT se enfoca a un gemelo digital único, mientras que el CDT permite englobar numerosos gemelos digitales, por ejemplo, de las diferentes entidades físicas como se puede apreciar en la figura 3.6. Comparación arquitecturas de referencia Comparando las arquitecturas elegidas se puede observar cómo ambas coinciden en algunos de los elementos como puede ser la interfaz de usuario, o la entidad de procesamiento de datos, como se observa en la figura 3.7; además de la visión funcional, y la forma de definir y conectar el elemento físico o activo al modelado. Figura 3.7 Comparación de componentes arquitecturas de referencia. Sin embargo, estas dos referencias difieren en la parte central o núcleo de la arquitectura, estando la de la ISO 23247 englobado en un mismo bloque que recopila todas las funciones 4 Búsqueda de tecnología de implementación A nivel metodológico se aplica a la arquitectura propuesta en el apartado anterior, un caso de uso concreto que permita entender con mayor precisión el funcionamiento de dicha arquitectura. Para llevar a cabo la implementación del modelo será necesario el uso de una tecnología de computación en la nube. En este apartado se expone una revisión de las diferentes plataformas comerciales existentes que disponen de las tecnologías necesarias para la implementación de la solución. Una vez realizada la comparativa de las plataformas, se lleva a cabo la elección de la plataforma de Microsoft, y se incluye la justificación del uso de la tecnología Azure DT en la arquitectura propuesta, y especificada para el caso práctico elegido. 4.1 Comparación tecnologías disponibles Existen en el mercado varias plataformas que ofrecen los servicios que se buscan para la solución propuesta. En concreto destacan esencialmente tres plataformas comerciales como las más utilizadas en este tipo de propuestas: la de Azure Digital Twin de Microsoft, Google Clouds de Google y AWS de Amazon. Para comenzar se presentan cada una de las plataformas, y se incluye el conjunto de elementos, y sus correspondientes definiciones, necesarios para el desarrollo de la arquitectura. A continuación, se elabora una comparativa entre los elementos disponibles de cada una de las plataformas. Dicha comparativa se muestra en la tabla 4.1. 61 62 Capítulo 4. Búsqueda de tecnología de implementación 4.1.1 Microsoft Azure La tecnología de Microsoft Azure es conocida como un servicio de computación en la nube creado por Microsoft para construir, probar, desplegar y administrar aplicaciones y servicios mediante el uso de sus centros de datos. Azure ofrece una amplia gama de servicios, lo que incluye las funcionalidades de plataforma como servicio (PaaS), infraestructura como servicio (IaaS) y servicio de base de datos administrados. Azure es una gran colección de servidores y hardware de red que ejecuta un conjunto complejo de aplicaciones distribuidas. Estas aplicaciones orquestan la configuración y el funcionamiento del hardware y el software virtualizados en esos servidores. Se incluyen a continuación las definiciones de cada uno de los elementos incluidos en la tabla 4.1. •Power BI : Herramientas de inteligencia empresarial que permiten crear visualizaciones, hacer análisis ad-hoc y producir conocimiento empresarial a partir de los datos. Permite una fácil conexión con las fuentes de datos. •Azure Digital Twins : Servicios que sirven para crear representaciones digitales de cosas reales, lugares, procesos empresariales y personas. El uso de estos servicios permite obtener información, impulsar la creación de mejores productos y nuevas experiencias de cliente, y optimizar las operaciones y los costos. •Azure Machine Learning : Servicio en la nube para entrenar, implementar, automatizar y administrar modelos de aprendizaje automático, en base a datos ya existentes, pudiendo así predecir nuevos resultados, comportamientos y tendencias futuras para nuevos escenarios. •Azure Cosmos DB : Servicio de base de datos, que nos permite utilizar varios tipos de modelos de datos, almacenar datos y realizar consultas sobre los datos previamente almacenados. •Azure Data Lake : Servicio de almacenamiento en la nube altamente escalable que permite informar sobre conjuntos de datos grandes y complejos. •Azure Data Explorer : Plataforma de análisis de macrodatos distribuida, de baja latencia y totalmente administrada, que ejecuta consultas complejas en petabytes de datos. Altamente optimizada para los datos de registro y de series temporales. •Stream Ingestión (IoT Central): Plataforma de aplicaciones de IoT que reduce la carga y el coste de desarrollo, la administración y el mantenimiento de las soluciones 4.1 Comparación tecnologías disponibles 63 IoT. Punto de conectividad de los activos con el sistema Azure proporcionando la ingestión de datos de los distintos sensores. − Event Hub: Plataforma de streaming de macrodatos, ofrece una plataforma distribuida de procesamiento de secuencias con baja latencia e integración perfecta, con servicios de datos y análisis dentro y fuera de Azure para crear una canalización de macrodatos completa. − DPS (IoT Hub Device Provisioning Service): Asistente de IoT Hub que ofrece un aprovisionamiento Just inTime, sin intervención del usuario, de la instancia correcta de IoT Hub, lo que permite aprovisionar múltiples dispositivos de forma segura y escalable. •Stream Processing = Stream Analytics + Functions − Stream Analytics: motor de procesamiento de eventos complejos y análisis en tiempo real que está diseñado para analizar y procesar grandes volúmenes de datos de streaming con capacidad de operar con varios orígenes de manera simultánea. − Functions: Ofrece una interfaz de usuario intuitiva basada en el navegador que permite crear piezas de código programadas o activadas implementados en una variedad de lenguajes de programación. •CRUD Mantenimiento : Entorno en el que podemos crear, leer, modificar y eliminar datos de las bases de datos, así como alimentar la arquitectura implementada con información estática o simplemente con información que no es recogida por los diferentes activos de la red. •Azure IoT Edge : Servicio donde los sensores y dispositivos comunican datos en tiempo real a una red. Implementa la inteligencia en la nube directamente en dispositivos IoT para su uso en escenarios locales. 4.1.2 Google Clouds Google Cloud consiste en un conjunto de recursos físicos, como computadoras y unidades de disco duro, y recursos virtuales, como máquinas virtuales (VM), que se encuentran en los centros de datos de Google en todo el mundo. En la computación en la nube de Google Clouds, lo que se conoce en ocasiones como productos de software y hardware pasan a ser denominados servicios. Estos servicios permiten acceder a los recursos subyacentes. Se procede en este apartado a la definición de cada uno de los elementos que proporciona la plataforma de Google: 64 Capítulo 4. Búsqueda de tecnología de implementación •Looker : Servicio de análisis de datos que explora, comparte y visualiza los datos de la empresa con la finalidad de permitir tomar mejores decisiones comerciales. •Compute Engine : servicio de computación seguro y personalizable que permite crear y ejecutar máquinas virtuales en la infraestructura de Google. Acelera la transformación digital con VM de alto rendimiento. •Inteligencia artificial de vértice : Aloja los modelos de aprendizaje automático y entrenamiento con gran potencia y la flexibilidad y contenedores personalizados. •Cloud Firestore : Desarrolla aplicaciones sofisticadas de forma sencilla mediante una base de datos de documentos completamente administrada, escalable y sin servidores. •Data proc : Implementa servicios de procesamiento de estadísticas y datos de código abierto con mayor eficiencia y seguridad. •Big Query : Almacén de datos en múltiples nubes de alta escalabilidad, rentable y sin servidor, diseñado para mejorar agilidad empresarial. •Cloud Pub/Sub : Crea mensajería y transferencia escalables para sistemas basados en eventos y análisis de transmisiones. Ingiere eventos para emitir en BigQuery, lagos de datos o bases de datos operativas. •Data Flow : Procesamiento unificado en streaming, de datos por lotes y de transmisión rápida, sin servidores y rentable. •Cloud Functions : Ejecuta piezas de código sin necesidad de administrar servidores, con una oferta escalable de funciones como servicio (FaaS) y de prepago, que permite crear y conectar servicios basados en eventos con un código sencillo. •Edge TPU : Circuito ASIC de Google diseñado a medida para generar inferencias en el perímetro. 4.1.3 AWS Amazon Amazon Web Services (AWS) es una plataforma en la nube que ofrece más de 200 servicios integrales de centros de datos a nivel global. AWS cuenta con una gran cantidad de servicios y de características incluidas en ellos, ofreciendo desde tecnologías de infraestructura como almacenamiento y bases de datos hasta tecnologías emergentes como aprendizaje automático e inteligencia artificial, lagos de datos y análisis e internet de las cosas. Esto hace que llevar las aplicaciones existentes a la nube sea más rápido y fácil. AWS ofrece también una amplia variedad de bases de datos diseñadas especialmente para diferentes tipos de aplicaciones. 4.1 Comparación tecnologías disponibles 65 Finalmente, se adjunta también las definiciones de los distintos elementos necesarios de la tecnología AWS de Amazon: •QuickSight : Permite la comprensión de los datos mediante preguntas en lenguaje natural, exploración a través de paneles interactivos o la búsqueda automática de patrones y valores atípicos, impulsada por machine learning. •IoT Things Graph : Servicio que facilita la conexión visual de diferentes dispositivos y servicios en la nube para crear aplicaciones de IoT. •SageMaker : Crea, forma e implementa modelos de machine learning para cualquier caso de uso con infraestructura, herramientas y flujos de trabajo completamente administrados. •Dynamo DB : Base de datos NoSQL de clave-valor sin servidor y completamente administrada que está diseñada para ejecutar aplicaciones de alto rendimiento a cualquier escala. •Amazon Timestream : Base de datos de series temporales rápida, escalable y sin servidor •EMR : Plataforma de big data en la nube para ejecutar trabajos de procesamiento de datos distribuidos a gran escala, consultas SQL interactivas y aplicaciones de machine learning con marcos de análisis de código abierto. •Kinesis Analytics : Ofrece la manera más sencilla de transformar y analizar datos de streaming en tiempo real con Apache Flink. •Kinesis Fitehose : Servicio de extracción, transformación y carga que captura, transforma y entrega de manera fiable datos de streaming en lagos y almacenes de datos y servicios de análisis. •Greengrass : Servicio de nube y tiempo de ejecución de borde y código abierto para crear, implementar y administrar software de dispositivos. 4.1.4 Comparativa de elementos Tras el análisis individual de las plataformas seleccionadas de Google, Amazon y Microsoft, nos encontramos ante tres tecnologías de gran alcance a nivel empresarial, y una amplia oferta de componentes, aplicaciones y servicios. Cada una de las plataformas comerciales analizadas oferta una gran variedad de elementos, muchos más de los incluidos y analizados en esta sección, para un uso muy extenso de aplicaciones que disponen estas tecnologías. 66 Capítulo 4. Búsqueda de tecnología de implementación Sin embargo, debido a la gran magnitud que tienen estas tecnologías para multitud de necesidades diferentes, se decide realizar la comparativa de las plataformas directamente desde el enfoque de nuestra arquitectura propuesta, es decir, se han seleccionado para su análisis únicamente aquellos elementos de utilidad en nuestra solución propuesta, comparándolos directamente con los equivalentes en cada una de las plataformas seleccionadas. La comparativa de las plataformas mediante la elaboración de una tabla de correspondencias de elementos de cada una de las plataformas, para cada funcionalidad, se muestra en la tabla 4.1. Tabla 4.1 Comparación elementos Azure - Google - Amazon. Funcionalidad Azure Google Amazon Herramienta que permite la visualización y compartición de datos de manera sencilla. Se relaciona con la interfaz del usuario. Power BI Looker QuickSight Permite la creación de gemelos digitales o aplicaciones IoT de los activos. Azure Digital Twin Compute Engine IoT Things Graph Crea y gestiona modelos de aprendizaje automático. Azure Machine Learning Inteligencia artificial de vértice SageMaker Servicio de base de datos, que permite ejecutar aplicaciones de alto rendimien- to. Azure Cosmos DB Cloud Firestore Dynamo DB Servicio de almacenamiento en la nube y procesamiento de datos. Azure Data Lake Dataproc - Servicio de procesamiento de macrodatos, series temporales o datos en tiempo real. Azure Data Explorer Big Query Amazon Timestream EMR Kinesis Analytics Plataforma para la transmisión y mensajería de sistemas de eventos. Iot Central (Event Hub) Cloud Pub/Sub Kinesis Fitehose Plataforma de análisis de eventos o datos por lotes. Stream Processing (Stream Analytics) Data Flow Kinesis Analytics Permite crear e implementar piezas de código en una gran oferta de lenguajes y funciones Stream Processing (Functions) Cloud Functions - Entorno que permite acceder y modificar la información de la base de datos. CRUD Mantenimiento - - Servicio en la nube que gestiona e implementa dispositivos IoT. Azure IoT Edge Edge TPU Greengrass 4.2 Conclusiones y elección de la tecnología Una de las primeras conclusiones a las que se llega durante el proceso de análisis para la realización de la comparativa de la tabla 4.1 es la discrepancia de elementos entre las 4.2 Conclusiones y elección de la tecnología 67 propias plataformas. Para la elaboración de esta comparativa en primer lugar se analizó la información proporcionada por las propias plataformas, ya que tanto Google [ 19 ] como Microsoft [ 36 ] [ 37 ] proporcionan en sus servidores comparativas de sus elementos con respecto a los de sus principales competidores. Sin embargo, aparecen numerosas discrepancias con respecto a las equivalencias que cada una elabora de los elementos que ellas ofertan. Frente a esta dificultad, se decide llevar a cabo también una búsqueda de comparativas proporcionadas por referencias más objetivas que no pertenecieran a ninguna de las plataformas en cuestión [ 11 ] [ 42 ]. Comparando todas las referencias encontradas se obtiene la tabla anterior 4.1. Destaca además como a pesar de ser plataformas orientadas a una misma finalidad de creación de servicios y aplicaciones para diferentes organizaciones, son muchos y muy dispares los enfoques a los que pueden optar, no disponiendo siempre de equivalentes para los elementos de las plataformas competidoras. En este caso se ha partido de los elementos de la tecnología de Azure y se han buscado y comparado las otras dos con ella; es por ello que se pueden observar la ausencia de elementos equivalentes por sus competidores como se ha comentado, por ejemplo, con el elemento de CRUD, el cual carece de equivalente tanto AWS de Amazon como en la tecnología Google Clouds; o el elemento de Azure Data Lake, el cual si tiene elemento equivalente en Google Clouds, pero no en AWS. Se justifica de esta manera, la decisión tomada de elección de la tecnología de Microsoft Azure para la implementación de nuestra solución en el caso práctico, al adaptarse mejor a la arquitectura propuesta, como consecuencia de ser la plataforma que presenta una aplicación de gemelo digital de forma más madura, mediante el desarrollo de ontologías y lenguaje propios; lo cual la hace más potente que las demás. Finalmente, una vez finalizada la búsqueda de tecnologías de implementación, se decide llevar a cabo una prueba de conceptos de un caso práctico, sobre la plataforma de Microsoft, mediante la tecnología de Azure. Para el desarrollo de este modelo se ha usado dentro de la amplia oferta que proporciona esta plataforma, la tecnología de Azure Digital Twins, la cual consiste en una oferta de Internet de las cosas (IoT) de la plataforma como servicio, que permite la creación de grafos gemelos basados en modelos digitales de entornos completos como pueden ser edificios, ferrocarriles etc. Esta tecnología permite modelar y crear representaciones digitales de entornos conectados con un lenguaje de modelado abierto, es decir, da vida a gemelos digitales con un entorno de ejecución en tiempo real que recoge y almacena los distintos cambios que 68 Capítulo 4. Búsqueda de tecnología de implementación pueden sufrir los gemelos a lo largo de su ciclo de vida; mediante el lenguaje de definición de gemelos digitales (DTDL) que se basa en JSON – LD. Al mismo tiempo desbloquea información procesable sobre el comportamiento de los entornos modelados a través de potentes API de consulta, y se integra con los análisis de datos de Azure. Como consecuencia facilitará la eliminación de los silos de información en entornos conectados. 5 Caso de estudio La última sección de este trabajo se enfoca en la descripción y desarrollo del caso de uso que se ha utilizado y ha servido como guía para el desarrollo del modelo de activos digitales propuesto, teniendo en cuenta su importancia para el desarrollo del mantenimiento industrial. A partir de la elección del caso práctico expuesto se pretende demostrar la capacidad del modelo planteado con respecto a la proporción de soporte para este tipo de soluciones. De otro modo, este caso permitirá justificar si la estrategia de gestión del riesgo propuesta en este caso de estudio es capaz de interpretar las distintas señales en niveles de riesgos, y la propia plataforma propuesta representa adecuadamente dicha información en las acciones de mantenimiento correctas; facilitando así el completo desarrollo y validación de la propuesta planteada. En un principio, se procede a la descripción del contexto en el que se lleva a cabo este caso de uso como es el sector ferroviario, y la importancia que tiene en la actualidad este tipo de estudio en este ámbito. Una vez contextualizado, se procede a la explicación detallada del caso práctico de la vía de tren que se ha utilizado como ejemplo y justificación para la toma de decisiones de la solución propuesta, además de la descripción del proceso de implementación de la solución propuesta, y su papel en la toma de decisiones de mantenimiento mediante la gestión del riesgo. Por último, enfocado a la implementación de la arquitectura, se describe la distribución interna de los elementos de la tecnología elegida en la arquitectura propuesto, y el desarrollo y explicación del uso de dichos elementos en el proceso de gestión del riesgo, de cara al mantenimiento inteligente de los activos. De esta forma se aprecia la contribución de este apartado en el uso del caso práctico enfocado en dos caminos diferenciados, por un lado, mediante su aportación en el sector ferroviario, y por otro a través de su participación en la adaptación de la plataforma. 69 76 Capítulo 5. Caso de estudio En la tabla 5.1, destaca una diferenciación en dos grupos, del conjunto de variables que se exponen, en primer lugar aparecen el conjunto de variables que se obtienen de forma directa del proceso de monitorización como pueden ser el tiempo espacio o velocidad; frente a aquellas propiedades de definición del activo, como pueden ser el peralte o la curvatura, las cuales determinan características que definen al activo geométricamente, obtenidas de forma directa del proceso de monitorización. Tabla 5.1 Variables de monitorización del caso práctico. Variable Unidad Descripción Tiempo (t) s Momento en que se realiza la medida, desde el inicio del ensayo. Distancia (s) m Distancia recorrida desde uno de los extremos de la vía, hasta donde se realiza la medida. Velocidad (V) m/s Velocidad media que lleva el coche. Peralte (InclinoX) º Diferencia de altura entre carril derecho e izquierdo, medido en grados. Pendiente vertical (InclinoY) ºPendiente de la vía. Curvatura ρDesviación de la dirección o forma recta de la vía. Pulsos (Pulsos encoder) [−] Medida utilizada para cálculos de distancia y la velocidad. Balizas (balizas) 0/1 Elemento fijo, que marca una distancia concreta recorrida. Aceleración (aX, aY, aZ) g Aceleración del coche. Tendrá tres componentes para cada uno de los ejes de coordenadas (X, Y, Z). Velocidad Angular (wX, wY, wZ) rad/s Velocidad angular del coche. Tendrá tres componentes para cada uno de los ejes de coordenadas (X, Y, Z). A partir de las variables de monitorización obtenidas se calculan otra serie de variables, las variables geométricas o de descripción del elemento físico, también conocidas como irregularidades, que permiten gestionar los modos de fallo y su riesgo. De esta forma, estas variables estarán ligadas también a las acciones de mantenimiento promovidas por los eventos. Tabla 5.2 Variables geométricas del caso práctico. Variable Unidad Descripción Peralte m Diferencia en la elevación de la parte exterior y la interior de la vía Ancho m Distancia entre las caras internas de los carriles de la vía del tren. Nivelación m Cálculo de las alturas de distintos puntos a partir de un plano de comparación. Alineamiento m Proyección del eje de la vía sobre unos planos de referencia. Una vez definidas las variables que se usarán en la toma de datos, el siguiente paso consiste en la realización de los ensayos y su monitorización. Para ello, en el proceso de 5.3 Implementación del caso práctico 77 simplificación de la toma de medidas realizadas, se definirán en cada sección una serie de puntos de control (PCi), en concreto serán tres por sección, tal y como se puede observar en la figura 5.6, y serán aquellos puntos donde se tomarán las medidas necesarias expuestas en la tabla 5.1 anterior, con el fin de facilitar la gestión de los estados o niveles de riesgo, y el análisis de las series temporales obtenidas. La importancia de este análisis aparece en su posibilidad de mostrar cómo cambian las variables a lo largo del tiempo. Es decir, muestra cómo se ajustan los datos a lo largo de los puntos de control, así como los resultados finales, de cara a la detección de los modos de fallo. Figura 5.6 Ejemplo ubicación puntos de control (PCi) en la sección. 5.3.2 Modelado de la toma de decisiones basado en control del riesgo en el modo de fallo La idea principal de este apartado dentro del trabajo, es la realización del diseño de un modelo de organización de la información que represente el gemelo de forma que de soporte a la toma de decisión. Tal y como se ha expuesto, tanto el modelo de digitalización de activos propuesto, como el caso práctico elegido, ambos están enfocados a la gestión del mantenimiento mediante el análisis de los niveles de riesgo de los activos, basado en los modos de fallo. Para ello se enfocará el estudio en la gestión de una serie de modos de fallos que serán previamente definidos, y el riesgo de que se produzcan, con el objetivo de probar la competencia de estos modelos para su programación sencilla. Los modos de fallo aparecen definidos por la norma UNE 13306 [ 55 ] como las distintas maneras en que puede 78 Capítulo 5. Caso de estudio producirse la inaptitud de un elemento para la realización de una función requerida. Es decir, se entienden como aquellas causas físicas evidentes del fallo [ 21 ]. Pueden definirse por la pérdida de función o por un cambio de estado que se ha producido. Se definen para este caso práctico una serie de modos de fallos genéricos, los cuales se incluyen en la tabla 5.3; como por ejemplo el modo de fallo de carril roto, el cual determina como al elemento concreto del carril, le ocurre la circunstancia concreta de su rotura. En relación a estos modos de fallo en este caso de uso se definen con un subíndice i en función del tipo de modo de fallo, y un subíndice j según el número de fallo de tipo i dentro de una misma sección. Tabla 5.3 Modos de fallo definidos. i Modo de fallo 1 Pérdida geométrica 2 Carril roto 3 Carril fisurado 4 Problema de onda corta 5 Problema de onda larga De esta forma se pretende argumentar la importancia no solo del modo de fallo de cara a la toma de decisiones, sino también la gran importancia de la ubicación de dicho modo de fallo, al ser posible la existencia de más de un modo de fallo en un mismo activo, lo cual no aparece resuelto del todo en la actualidad. La toma de decisión se realiza en función del estado de los modos de fallo. Dicho estado se obtiene a partir de las interpretación de la información contenida en las variables que se han llevado hasta el gemelo. Además del estado de los modos de fallo, el propio modelo tendrá también su propio estado como interpretación de la combinación de estados de los modos de fallo. Cabe subrayar como la propia toma de decisiones de acciones de mantenimiento influye también de forma directa en los estados de modos de fallo, pudiendo modificarlos. En la figura 5.7 se muestra el proceso de toma de decisiones, desde la monitorización pasando por los diferentes estados de los modos de fallo. Figura 5.7 Modelado del proceso de toma de decisiones. 5.3 Implementación del caso práctico 79 Es decir, una vez finalizado el proceso de monitorización, del cual se obtienen el conjunto de variables de monitorización de la tabla 5.1, se calculan las variables de descripción geométrica de la tabla 5.2. El siguiente paso a llevar a cabo, es el procesamiento del flujo de datos que se recibe de manera repetida de la maqueta, la cual realiza medidas con una frecuencia de tiempo, pero también con una frecuencia espacial definida, debido al ser móvil el objeto de monitorización en este caso el coche que se desplaza por la vía; para ello la frecuencia espacial permite ubicar en el espacio el punto exacto donde se ha realizado la medida. Esta frecuencia tiene especial importancia en relación a la precisión de la toma de medidas, ya que al ser como hemos comentado un objeto móvil el que se encarga de la toma de medidas, y tener este además una velocidad que no es siempre exactamente constante debido a posibles acontecimientos, se utiliza esta frecuencia en un intento de dar mayor exactitud a la medida obtenida. Al finalizar el tratamiento y análisis de la información recogida de los sensores, se habrán obtenido los ya definidos eventos, siendo el siguiente paso su traducción a nivel de riesgo. Cada evento provoca un posible cambio en el nivel de riesgo, por ello de los tipos de eventos descritos en el apartado anterior, por ejemplo los de monitorización e inspección, una vez interpretados pueden concluir con un aumento del riesgo del activo; por otro lado, los de acción de mantenimiento, indican que en un momento temporal concreto uno de los activos tiene un nivel de riesgo lo suficientemente alto como para necesitar de mantenimiento preventivo, es por ello que se lleva a cabo la acción de mantenimiento, que permitirá volver a variar el estado del activo disminuyendo su riesgo. El modelo propuesto prevé también el tratamiento de los eventos del proceso de mantenimiento, es decir, las propias decisiones de mantenimiento; a pesar de que estas no hayan sido todavía integradas en el caso práctico que se ha centrado únicamente en la monitorización del sistema. Según los eventos obtenidos en cada punto de control, los activos tomarán un determinado estado o nivel de riesgo. Se precisa definir por tanto las reglas de estado, es decir, a la hora de gestionar el riesgo de nuestros activos, deben estar previamente definidas las reglas a seguir por el modelo en función de las variaciones de los estados de los diferentes activos con vistas a la toma de decisiones de mantenimiento. Por ejemplo, se debe definir, cuantos modos de fallos son necesarios en amarillo para que el componente al que pertenece cambie de estado y se cambie de color; o cuantos componentes tienen que estar en amarillo para que el subsistema se ponga en amarillo y así sucesivamente. Estas reglas de estado son bastante comunes en la literatura, mediante una diferenciación 80 Capítulo 5. Caso de estudio de estados de los activos por colores tal y como se puede observar en la figura 5.8, el cual representa un ejemplo gráfico [33] de solución de monitorización de activos digitales. Figura 5.8 Ejemplo visualización cambios de estado. Este ejemplo muestra cómo se llevan a cabo una serie de eventos tanto de monitorización como pueden ser los eventos 1 y 2; como eventos de acción de mantenimiento como es el evento 3 que consiste en una inspección de la tarea, o el evento 4 que implica la propia ejecución de mantenimiento preventivo sobre el activo. Se puede observar como la figura representa de forma paralela los efectos de dichos eventos en dos modos de fallos distintos, con el objetivo de justificar la posibilidad de un único evento de afectar a más de un modo de fallo, provocando además diferentes posibles consecuencias. Volviendo a la definición de riesgo, la cual era igual a probabilidad por consecuencia, en este gráfico de colores únicamente se mide la probabilidad. Es decir, el estudio del activo comienza en perfectas condiciones siendo su estado verde, y conforme ocurren eventos va variando la probabilidad del nivel de riesgo que pueda tener dicho activo, y con el el color de su estado. Una vez que se ha producido un evento y se ha asignado el nuevo nivel de riesgo, tratamos de mitigar o reducir el riesgo mediante diversas acciones. Estas acciones son el resultado del subproceso de toma de decisiones asociado a cada nivel de riesgo. Las variaciones de estado y la gestión del riesgo están ligados a las tareas de mantenimiento. 5.4 Implementación de la arquitectura sobre la tecnología Azure 81 5.4 Implementación de la arquitectura sobre la tecnología Azure Una vez expuesto los conceptos y la utilidad de cada uno de los elementos Azure en el apartado anterior, y realizada la descripción detallada del caso de uso a implementar, se procede con la implementación de la arquitectura. 5.4.1 Ubicación elementos Azure en la arquitectura Para comenzar con la implementación, se lleva a cabo una recopilación de las relaciones de los elementos Azure definidos, con los elementos de la arquitectura propuesta, la cual se muestra en la siguiente Tabla 5.4. Tabla 5.4 Relación elementos arquitectura propuesta y elementos Azure. Capa Elemento Elemento Azure User Interaction User Interface and Control Power BI Twin Management Digital Service Management Digital Process Management DT SoS., DT Sys., DT Subsys., DT Comp Azure Digital Twins Model Management Model Repository Azure Machine Learning Model Management Azure Machine Learning + Azure Cosmos DB Ontologies Azure Cosmos DB Data Ingestion and Processing Data Repository Azure Data Lake Metadata Repository Azure Data Lake + Azure Data Explorer Adapters CRDU + Azure IoT Edge + Stream Processing + IoT Central Asset/context sensorisation Sensorisation layer CRDU + Azure IoT Edge + Stream Processing + IoT Central Physical entities Sos., Sys., Subsys., Comp. En la figura 5.9 se incluye una imagen de la arquitectura propuesta junto con los elementos Azure asociados a cada entidad ubicados según con qué elementos están relacionados cada uno de ellos, según lo expuesto en la tabla 5.4. Se considera importante subrayar como la figura 5.9 discrepa de la figura 3.8 en la disposición de la capa de entidad física en la arquitectura propuesta. En esta última figura se decide ubicar dicha capa en el eje vertical, con la finalidad de representar de una forma más evidente como estas entidades están interconectadas con todas y cada una de las capas de la arquitectura. Se observa además como la relación puede no ser la misma con todas las capas, se muestra así como tendrá un mayor flujo de información con las capas de Twin Management yData Ingestion & Processing, como muestra el grosor de las flechas que 82 Capítulo 5. Caso de estudio relacionan la capa de entidades físicas con el resto de capas. Cabe destacar también como alguna de estas relaciones será bidireccional como será el caso de los gemelos digitales en la capa de Twin Management y la de Model Management. Figura 5.9 Arquitectura propuesta y elementos Azure. 5.4.2 Distribución de la arquitectura en la nube Partiendo de la figura 5.9, en la que se muestra la estructura interna, y la ubicación de los distintos elementos de la tecnología Azure en ella, se procede por último a llevar a cabo un paso más. Este avance consiste en la ubicación de dichos elementos en la nube de datos donde se almacenarán toda la información del modelo; además de la descripción de dicho proceso de recogida e interpretación de los datos. En primer lugar, se realiza una revisión de la arquitectura propuesta, a pesar de haber sido ya descrita en la sección anterior, en este apartado se enfoca al caso práctico de la vía, focalizada en la gestión del riesgo y el mantenimiento; además se describe de forma detallada el proceso que realiza el modelo a través de la arquitectura desde la obtención de datos hasta la toma de decisiones de mantenimiento. El proceso comienza con la obtención de datos, a través de los sistemas de sensorización y monitorización embarcada del coche, ubicados en la capa de sensorización del contexto; dicha información entrará a través del Azure IoT Edge al IoT Central, siendo este el foco de 5.4 Implementación de la arquitectura sobre la tecnología Azure 83 la conectividad entre las entradas o fuentes de información externas, y el propio sistema. Todo este flujo de información se almacena en el bloque de Ingesta donde se encuentra el Stream Processing, el cual se entiende como la aplicación de procesado inicial o tecnología que permitirá la creación de las funciones lógicas necesarias para cambiar los estados del activo. Las funciones que se crean aquí pueden ser de dos tipos: funciones para crear eventos o establecer indicadores, o funciones para la interpretación de los eventos. Una vez analizados los eventos, la información obtenida se almacena en el Azure Data Lake y el Azure Cosmos DB, ubicado en la Data Base (DB) o base de datos de la nube tal y como se puede observar en la figura 5.10. Tanto el procesamiento de la información como su almacenamiento se localiza completamente en la capa de Ingesta y Procesamiento de datos, ubicada inmediatamente por encima de la capa de sensorización. Además de las medidas tomadas de la monitorización embarcada, existen también otras posibles entradas de información como puede ser el CRUD Mantenimiento el cual recoge datos de distintos sistemas de gestión como el CMMS (Sistema de gestión de mantenimiento computarizado), los cuales serán procesados hasta llegar a la base de datos a través de la base de datos relacional Azure Cosmos DB. Para toda la información almacenada en la base de datos, existe la posibilidad de un segundo procesado de la información si resulta necesario al no ser suficiente el primer procesado llevado a cabo por el Stream Processing, por medio del Analytics Store. Como ya se ha comentado con anterioridad, la cantidad de datos que se obtienen de la toma de medidas es extensa, siendo necesaria su filtración para una mejor gestión de la información de cara a la toma de decisiones. Es por ello que aparece la necesidad de decisión de la persistencia de datos, es decir, se deben decidir qué datos son los que van a persistir y se van a guardar en la base de datos correspondiente para su posterior uso, y cuales no son necesarios o de utilidad y no serán guardados de forma indefinida en base de datos del modelo. A partir de toda la información almacenada, la base de datos se conecta por un lado con la interfaz de control, ubicada en la capa de interacción del usuario, a través del Power BI, permitiendo el acceso del usuario al sistema mediante la visualización e interacción con los datos; pero también con el bloque de gemelos digitales, compuesto por el conjunto de gemelos desde los de las entidades físicas, hasta los de servicios y procesos, mediante Azure Machine Learning, con el fin de facilitar el acceso a la información de los modelos de activos para su uso en su función. El manejo de dichos gemelos digitales con la información almacenada se ubica en la capa de gestión de modelos, mientras que el almacenamiento de las versiones anteriores de todos estos modelos se encasilla en la capa de gestión de modelos. 84 Capítulo 5. Caso de estudio Se estima preciso subrayar cómo el proceso descrito recorre la arquitectura al completo desde su capa más baja hasta la capa más alta, la cual se encarga de la propia interacción con el usuario; teniendo además un contacto en paralelo de todas las capas en todo momento con las entidades físicas. En la figura 5.10 se pueden observar las relaciones descritas entre los distintos elementos internos y la tecnología Azure utilizada. Figura 5.10 Ubicación de los elementos Azure en la nube. El proceso descrito y representado en la figura 5.10 consiste en la generalización detallada del transcurso de la información desde su entrada hasta su procesado y uso en los gemelos digitales. Dicho proceso detallado se puede simplificar de la siguiente forma: en primer lugar, se produce la obtención de datos, los cuales deberán pasar por un primer procesado, para la creación de las funciones necesarias. Una vez procesadas la información y funciones se almacenarán en la base de datos, sin embargo, algunas pueden necesitar un segundo procesado antes de ser almacenadas. El conjunto de información obtenida de la monitorización procesada, y la obtenida por otras fuentes como sistemas de gestión, almacenada en la base de datos, será accesible para el usuario a través de la interfaz o los propios gemelos digitales. En la figura 5.11, se representa el proceso descrito de una forma simplificada con el objetivo de facilitar el entendimiento del camino que lleva la información una vez entra en el sistema. 5.4 Implementación de la arquitectura sobre la tecnología Azure 85 Figura 5.11 Proceso simplificado del transcurso de la información en la nube. Además, esta simplificación permite visualizar las distintas etapas del proceso, facilitando así el montaje de la nube para su implementación el cual debe realizarse de forma faseada, al estar estas etapas interconectadas y necesitar de las anteriores para continuar el flujo de información y facilitar además el propio proceso de especificación para casos de estudio concretos. Por último, una vez diseñada la arquitectura y definida la ubicación de cada uno de sus elementos en la nube IoT, el siguiente paso será la configuración de la propuesta en la plataforma y su respectiva validación operativa mediante la realización de los ensayos oportunos con el caso de uso. 92 Bibliografía Elena Quatrini, Massimo Tronci, and Giuseppe Vignali, Digital twin reference model development to prevent operators’risk in process plants, Sustainability (Switzerland) 12 (2020), no. 3, 1–17. [8] BSI, PAS 1192-3:2014 Specification for information management for the operational phase of assets using building information modelling, BSI Standards Publication 1 (2014), no. March, 1–44. [9] Arquimedes Canedo, Industrial iot lifecycle via digital twins, Proceedings of the Eleventh IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and System Synthesis, 2016, pp. 1–1. [10] Salvatore Cavalieri and Marco Giuseppe Salafia, Asset administration shell for plc representation based on iec 61131–3, IEEE Access 8(2020), 142606–142621. [11] Clarcat, Comparativa: Amazon web services (aws) vs. microsoft azure vs. google cloud platform,https:// www.clarcat.com/ comparativa-aws-vs-microsoft-azure-vs- google-cloud-platform/ , 2021. [12] International Electrotechnical Commission et al., Iec pas 63088: 2017. smart manufacturing–reference architecture model industry 4.0 (rami4. 0), IEC, Genf (2017), 1–35. [13] CTN 41/SC 13, Organización y digitalización de la información en obras de edificación e ingeniería civil que utilizan BIM. Gestión de la información al utilizar BIM. Parte 1: Conceptos y principios. (UNE-EN ISO 19650-1:2018), (2020). [14] Leedeo engineering, El mantenimiento ferroviario y la gestión de riesgos,https: // www.leedeo.es/ l/ mantenimiento-ferroviario/ , 2021. [15] Asier Erguido, Adolfo Crespo Márquez, Eduardo Castellano, Ajith Kumar Parlikad, and Juan Izquierdo, Asset management framework and tools for facing challenges in the adoption of product-service systems, IEEE Transactions on Engineering Management (2019). [16] Norma Española, Gestión del riesgo, (2018). [17] Thomas Gabor, Lenz Belzner, Marie Kiermeier, Michael Till Beck, and Alexander Neitz, A simulation-based architecture for smart cyber-physical systems, 2016 IEEE international conference on autonomic computing (ICAC), IEEE, 2016, pp. 374–379. Bibliografía 93 [18] Elizaveta Gavrikova, Irina Volkova, and Yegor Burda, Implementing asset data management in power companies, International Journal of Quality and Reliability Management (2021). [19] Google, Compara los servicios de aws y azure con google cloud,https:// cloud.google. com/ free/ docs/ aws-azure-gcp-service-comparison. [20] Georgij Grinshpun, Torben Cichon, Dipika Dipika, and Juergen Rossmann, From virtual testbeds to real lightweight robots: Development and deployment of control algorithms for soft robots, with particular reference to, Proceedings of ISR 2016: 47st International Symposium on Robotics, VDE, 2016, pp. 1–7. [21] Antonio Jesús Guillén López, Diseño de soluciones avanzadas de cbm/phm en sistemas inteligentes de gestión de activos., (2018). [22] Martin Hankel and Bosch Rexroth, The reference architectural model industrie 4.0 (rami 4.0), ZVEI 2(2015), no. 2, 4–9. [23] James Heaton and Ajith K Parlikad, Asset information model to support the adoption of a digital twin: West cambridge case study, IFAC-PapersOnLine 53 (2020), no. 3, 366–371. [24] James Heaton, Ajith Kumar Parlikad, and Jennifer Schooling, Design and development of bim models to support operations and maintenance, Computers in industry 111 (2019), 172–186. [25] James Hetherington and Matthew West, The pathway towards an Information Management Framework, (2020). [26] Une-en Iso, Extracto Del, and Documento Une-en Iso, Norma Española Manual de entrega de la información Parte 1 : Metodología y formato, (2018). [27] ISO/PC 251, Asset management - Overview, principles and terminology (ISO 55000:2015), (2014). [28] Sergey Konstantinov, Fadi Assad, Wajid Azam, Daniel Vera, Bilal Ahmad, and Robert Harrison, Developing web-based digital twin for industrial cyber-physical systems. [29] M López, C Parra, and A Crespo, La gestión de activos y la pas 55”. xiii congreso de confiabilidad, primera edición, asociación española para la calidad, Tech. report, M-45074-2011, 2011. 94 Bibliografía [30] Qiuchen Lu, Xiang Xie, James Heaton, Ajith Kumar Parlikad, and Jennifer Schooling, From bim towards digital twin: strategy and future development for smart asset management, International Workshop on Service Orientation in Holonic and Multi- Agent Manufacturing, Springer, 2019, pp. 392–404. [31] Somayeh Malakuti, Pieter van Schalkwyk, Birgit Boss, Chellury Ram Sastry, Venkat Runkana, Shi-Wan Lin, Simon Rix, Garvin Green, Kilian Baechle, and Chyam Varan Nath, Digital twins for industrial applications, IIC Journal of Innovation (2020), 1–19. [32] Adolfo Crespo Márquez, The maintenance management framework: models and methods for complex systems maintenance, Springer Science & Business Media, 2007. [33] Pablo Martínez-Galán Fernández, Antonio J. Guillén López, Adolfo Crespo Márquez, Juan Fco Gomez Fernández, and Jose Antonio Marcos, Dynamic Risk Assessment for CBM-based adaptation of maintenance planning, Reliability Engineering and System Safety 223 (2022). [34] Lasse Metso and Mirka Kans, An ecosystem perspective on asset management information, Management Systems in Production Engineering 25 (2017), no. 3, 150–157. [35] Microsoft, Azure digital twins,https:// azure.microsoft.com/ es-es/ services/ digitaltwins/ #overview. [36] ,Comparación de aws con los servicios de azure,https:// docs.microsoft.com/ es-es/ azure/ architecture/ aws-professional/ services, 2022. [37] ,Comparación entre servicios de google cloud y azure,https:// docs.microsoft. com/ es-es/ azure/ architecture/ gcp-professional/ services, 2022. [38] A A S Reference Modelling, Discussion paper AAS Reference Modelling, (2021). [39] Elisa Negri, Luca Fumagalli, and Marco Macchi, A review of the roles of digital twin in cps-based production systems, Procedia Manufacturing 11 (2017), 939–948. [40] Mohamed Z Ouertani, Ajith K Parlikad, and Duncan McFarlane, Asset information management: Research challenges, 2008 Second International Conference on Research Challenges in Information Science, IEEE, 2008, pp. 361–370. Bibliografía 95 [41] Comisión Técnico Científica para el estudio de mejoras en el Sector Ferroviario, Informe de la Comisión Técnico Científica para el estudio de mejoras en el Sector Ferroviario, (2014). [42] Paradigma, Aws vs azure vs gcp: todos los servicios cloud frente a frente.,https:// www. paradigmadigital.com/ dev/ comparativa-servicios-cloud-aws-azure-gcp/ , 2019. [43] Carlos A. Parra and Adolfo Crespo, Ingeniería de Mantenimiento y Fiabilidad Aplicada en la Gestión de Activos, Ingeman 1(2012). [44] Contributing Partners, Lead Partner, and Quality Controllers, FIRST REPORT ON STANDARDS RELEVANT FOR DIGITAL TWINS, (2021). [45] João Patacas, Nashwan Dawood, David Greenwood, and Mohamad Kassem, Supporting building owners and facility managers in the validation and visualisation of asset information models (aim) through open standards and open technologies, Journal of Information Technology in Construction 21 (2016), 434–455. [46] Marie Platenius-Mohr, Somayeh Malakuti, Sten Grüner, Johannes Schmitt, and Thomas Goldschmidt, File-and api-based interoperability of digital twins by model transformation: An iiot case study using asset administration shell, Future Generation Computer Systems 113 (2020), 94–105. [47] Azzam Raslan, Georgios Kapogiannis, Ali Cheshmehzangi, Walid Tizani, and Dave Towey, A framework for assembling asset information models (aims) through permissioned blockchain, 2020 IEEE 44th Annual Computers, Software, and Applications Conference (COMPSAC), IEEE, 2020, pp. 529–534. [48] R Rosen, G Von Wichert, G Lo, and KD Bettenhausen, About the importance of autonomy and digital twins for the future of manufacturing. ifac-papersonline 48 (3): 567–572, 15th ifac symposium oninformation control problems in manufacturing, 2015. [49] Michael Schluse and Juergen Rossmann, From simulation to experimentable digital twins: Simulation-based development and operation of complex technical systems, 2016 IEEE International Symposium on Systems Engineering (ISSE), IEEE, 2016, pp. 1–6. [50] Greyce N. Schroeder, Charles Steinmetz, Carlos Eduardo Pereira, and Danúbia Bueno Espíndola, Digital twin data modeling with automationml and a communication methodology for data exchange, IFAC-PapersOnLine 49 (2016), 12–17. 96 Apéndice 6. Bibliografía [51] Karsten Schweichhart, Reference architectural model industrie 4.0 (rami 4.0), An Introduction. Available online: https://www. plattform-i40. de I 40 (2016). [52] Guodong Shao et al., Use case scenarios for digital twin implementation based on iso 23247, National Institute of Standards: Gaithersburg, MD, USA (2021). [53] TC 184/SC 4, Automation systems and integration. Digital twin framework for manufacturing . Part 1: Overview and general principles. (UNE-EN ISO 23247-1:2021), (2021). [54] The British Standards Institution, Specification for information management for the capital/delivery phase of construction projects using building information modelling: PAS 1192-2:2013, BSI Standards Publication (2013), no. 1, 1–68. [55] UNE EN, Terminología del mantenimiento, AeUNE. (2018). Terminología del mantenimiento. Aenor, 31. https://www.une.org/encuentra-tu-norma/busca-tu- norma/norma/?c=N0026303nor (2018), 30. [56] Ferrocarrils de la Generalitat Valenciana, Manual BIM Metodología Ferrocarrils de la Generalitat Valenciana,2. [57] Constantin Wagner, Julian Grothoff, Ulrich Epple, Rainer Drath, Somayeh Malakuti, Sten Grüner, Michael Hoffmeister, and Patrick Zimermann, The role of the industry 4.0 asset administration shell and the digital twin during the life cycle of a plant, 2017 22nd IEEE international conference on emerging technologies and factory automation (ETFA), IEEE, 2017, pp. 1–8. [58] Xun Ye and Seung Ho Hong, Toward industry 4.0 components: Insights into and implementation of asset administration shells, IEEE Industrial Electronics Magazine 13 (2019), no. 1, 13–25. [59] Xiaochen Zheng, Jinzhi Lu, and Dimitris Kiritsis, The emergence of cognitive digital twin: vision, challenges and opportunities, International Journal of Production Research (2021), 1–23. Paper Congreso 1 Review of asset digitalization models in the context of intelligent asset management and maintenance. Abstrac Assets digitalization is currently one of the main challenges of industrial companies in order to finally get access to Industry 4.0 promises. Over the years industry and academia have been envolved on the development of numerous references such as BIM, AIM, AAS or a great variety of DT approaches among others, with the objective of managing data and giving support to organize the use of tools allowing to improve the intelligence of the asset management and maintenance. The study of these models, the fundamental elements they handle and the application framework that each of them proposes, gives a clear idea about the complexity of the common problem that, from different approaches, these models address. At the same time, it is clear the current need to standardize the way in which assets are defined and managed in the digital world. Not only from the point of view of an isolated asset, but also establishing the basis for the interaction of different digitalized assets in complex systemic environments and management levels of greater scope. The real thing is digitalization is changing the nature of own assets, and developing methods and strategies for modeling assets, including asset data model and architecture model consideration, is a must for developing and exploiting more complex digitalization solutions. The aim of this paper is to carry out a review on the state of art of digital asset modeling approaches, analysing the description and fundamental elements considered by each of them, as well as their differences and similarities. 97 98 Capítulo . Paper Congreso 1.1 Introduction Digital transformation has a particular impact on asset maintenance and management. This is due to the increased availability of data/information/knowledge about asset condition and performance and the increased possibilities for management and risk control, in real time and throughout the lifetime of the assets. Despite the availability of large amounts of data, the reality today is that asset management and intelligent maintenance are often reduced, in most cases, to very particular and short-range applications. However, most of the key decisions still have a very low level of digitization and are not made based on the available data and information. Modern asset management and maintenance must necessarily be data-driven and digitized. This will require an appropriate digital asset model, which structures and organizes all available data, information and knowledge of the asset(s) to support maintenance decisions, allowing these to be conveniently digitized. The fundamental idea of this approach is that in a context of high level of digitization the information model of an asset has to be part of the asset itself. The data and information needed to make decisions at any point in its life cycle must be designed as a part of the asset itself. And not just any part, but one of the most critical. This is not the case today, where: there is no single vision of the digital asset but applications and/or partial models that try to take advantage of the available data, so that on the basis of a system or physical asset to be managed, isolated and partial technological solutions with a low level of interaction are superimposed. They provide data on the asset that often have no practical use or that the organization is not able to interpret. The integration of different systems or technologies ends up being very complex and involves high costs and high consumption of hours of qualified personnel. This asset digitization model involves a certain complexity in its conception and management. Giving it an entity involves simultaneously managing aspects ranging from the configuration of IoT/Cloud platforms, development of analytical and simulation models, database models and anthologies, etc., to complex functional analysis and maintenance techniques. Defining the digital asset means defining its data model but also the software/hardware architecture and the processes that run through this architecture to feed and bring to life this data model. In this sense, a great research effort is being made to generate more integrated solutions that can take advantage of asset data. The ones linked to the development of digital twins stand out for their number and long history over the years. In recent years, the number of digital twin references has only increased [ 39 ] [ 7 ][ 3 ]. However, it is still a broad concept and therefore lacks concreteness, which is used in the most diverse ways depending on the approach or the specific industrial problem to which it is applied. 1 Review of asset digitalization models in the context of intelligent asset management and maintenance. 99 For this reason, there is now a consensus in the scientific community and in industry that the very extension of digital twins requires an effort to standardize and generalize models and methods. And not only, or mainly, to support the design of solutions that can have a good performance working in isolation, but contemplating the possibility that the twins can interact with each other as fundamental elements of complex engineering systems. Regardign the standarization and generalization effort, several international institutional initiatives such as ISO 23247 [ 52 ] or RAMI 4.0 [ 22 ] that seek to standardise this issue to facilitate the level of interaction and interconnection of complex systems in this new stage of digitisation in which the industry finds itself. The British IMF initiative [ 25 ], set out a philosophy focused on the creation of models that allow a complete integration of data and information, beyond a simple exchange, which supports decision-making with regard to the development, operation, maintenance and use of infrastructures and services; and stressing the importance of their standardisation. In any case, the reality is that there are currently many initiatives that can be used as a basis for proposing an advance in the digitization of assets. This paper aims to review the main ones, comparing them and establishing basic conclusions for new research initiatives in the field of maintenance and asset management. 1.2 Review of references related to digital asset modelling The following section will focus on the study of the main references and most widely used asset models that can be found in the industry today; their most essential characteristics will be analysed, as well as the main difficulties or problems faced by each of these proposals. Driven to meet the needs demanded by industry, these references differ according to the sector or life cycle phase for which they are found, but always seeking to provide quality information that facilitates subsequent decision-making. Building Information Model (BIM) The Building Information Model, known by its abbreviation as BIM model, is one of the most widely used models in the industry, especially in the construction sector, as it is especially focused on the design and construction phases of assets, in this case buildings. It is also one of the most standardised models in the industry. The standard ISO 19650-1 [ 13 ] define BIM model as: "use of a shared digital representation of a built asset to facilitate the design, construction and operation processes, and provide a reliable basis for decision making". For this type of model [ 56 ] proposes a structuring through the generation of sub-models following two different approaches, as shown in Figure 1. On the one hand, it proposes the need to create different models according to the specific phase of the life cycle in 100 Capítulo . Paper Congreso which the asset is located. These models, which [ 56 ] defines as a three-dimensional digital representation of a constructive intention, could be called life cycle evolution models, among which we could find: existing infrastructure models, construction project model, construction tender model or maintenance model; all of them should be classified into the three main stages of the life cycle: Beginning of life (BOL), Middle of life (MOL) and End of life (EOL) Figura 1 BIM model structure. On the other hand, both [ 56 ] and [ 24 ] cioncide in the proposal to create IFC language models to carry out a structuring or division of the asset into objects or elements according to the parent-child relationships between them, which will be associated with a particular class for better management, facilitating the exchange of information. Finally, there are many references ([ 56 ], [ 24 ], [ 45 ]) that propose the development within BIM technology of a data extraction platform, from which to carry out the development of diagrams, for the creation of a database that can store the information exported from the BIM model. The exported databases are used for their incorporation in management systems (e.g., CMMS); however, there are many occasions in which there are limitations in the integration of the information with these asset management systems. Asset Information Model (AIM) The asset information model is defined among other references by [ 45 ] as "Data model that contains all digital data (graphical, non-graphical, and documentary) required to operate an asset or portfolio of assets". This model focuses on the management of quality information, and the available access and visualisation of such information, mainly during the operation phase. 1 Review of asset digitalization models in the context of intelligent asset management and maintenance. 101 The literature [ 24 ] [ 45 ] proposes its decomposition mainly into two components, which are shown in Figure 2 below. Firstly, it presents an electronic document management system (EDMS), secondly, it entails a data and information store of the asset itself; both parts are encompassed in a common data environment (CDE). This environment sometimes leads to problems of information integration, due to the lack of integration of the systems, whose data are not always compatible in type, format or quantity with the rest of the systems or with AIM itself. Figura 2 AIM model structure [24]. As stated by many authors, such as [ 47 ] or [ 45 ] the Asset Information Model uses a technology based on BIM and, like this model, proposes a data export system through a database. This is why both models are usually combined, for the optimal management of the information obtained and extracted through the BIM model, introducing it into the AIM data warehouse for its management. This combination does not always optimise the process, as there are often interoperability limitations within the CDE itself, as mentioned above, due to the incompatibility of the data extracted with the AIM management system. To this end [ 23 ] the concept of federated model appears, understood as the composition or relationship of different models, such as IFC models or databases, which allow the integration of the asset’s information and its complete visualisation. Digital Twin (DT) This model is defined by [ 7 ] as "A digital model of a given physical element or process with data connections that allow convergence between physical and virtual states at an appropriate rate of synchronisation". In other words, it involves a digital and dynamic representation of an asset, process or system, mimicking its actual behaviour. It is understood as a model based on the advanced use of data, as set out by [ 31 ], thus helping to solve the problem of information silos. A digital twin will collect data centrally for each entity, and then make that information available through integration interfaces. Paper Publicación Científica 1 Development of a digital asset model in the context of smart maintenance 4.0 Abstrac Over the years, numerous references have been developed in industry and scientific literature with the aim of managing asset data and information, and providing support for coordinating the use of tools to improve the management and intelligent maintenance of these assets. The study of these models, through the analysis of the fundamental elements that compose them and the application framework that each one proposes, predisposes the complexity of the common problem that these models address. At the same time, there is a current need to standardise the way assets are defined and managed in the digital world. Not only from the point of view of an isolated asset, but from a global vision establishing the bases for the interaction of different digitised assets in complex environments, allowing interoperability with the rest of the systems. In the absence of global standards or generalised methodologies that provide simple solutions to the imminent challenge of asset management brought about by the current process of digitisation of organisations, the aim of this work consists of proposing a model for asset digitisation, based on a review of the literature, and focused mainly on the industrial maintenance phase, which allows, with a generalised approach, the connectivity and industrial 4.0 functionality of assets. For the validation and justification of the proposed solution, a proof of concepts is also proposed by means of a practical case study as an example. 109