infoPLC ++ / Tecnología / Tendencias / Retos técnicos y prioridades de investigación para las plataformas

Retos técnicos y prioridades de investigación para las plataformas


La propuesta del Industrial Data Space puede ser un puente entre plataformas propietarias consiguiendo unir lenguajes y aportando modelos comunes de gobernanza

Retos técnicos y prioridades de investigación para las plataformas

El 22 de junio pasado la Big Data Value Association, organismo con sede en Bruselas, se reunió con el objetivo de definir los desafíos técnicos y las prioridades de investigación relacionadas con las plataformas de datos industriales, uno de los dominios que desde la Unión Europea se ha definido como clave para estimular la transición hacia la Industria 4.0 y otros enfoques en el ámbito de la industria inteligente.

Nunca está demás recordarlo. Tal y como nos explica Valentijn de Leeuw de ARC Advisory Group, las plataformas de datos industriales (IDPs en sus siglas en inglés ) se definen como "entornos virtuales que facilitan el intercambio y la conexión de datos con diferentes empresas y organizaciones dentro de un ecosistema de negocio seguro, a través de una arquitectura de referencia compartida y un rol común de gobierno". Son entornos abiertos y dirigidos por múltiples empresas que cumplen con los requisitos de un amplio ecosistema de usuarios de diferentes sectores industriales.

Según explica De Leeuw, la Arquitectura de Referencia para la Internet Industrial (IIRA V1.8) y su reciente actualización nos ofrece un marco para crear arquitecturas IIoT desde cuatro perspectivas diferentes: el punto de vista empresarial, el punto de vista del uso, el punto de vista funcional y el punto de vista de la implementación. "En una mirada top-down proporcionan una guía con un detalle cada vez mayor, y al al inverso, es una guía para la validación de la misma arquitectura". Desde el punto de vista de la implementación, se están discutiendo tres patrones arquitectónicos, uno de los cuales es el conocido como el layered databus pattern.

El patrón se caracteriza por sus niveles jerárquicos donde es posible una agregación creciente hacia niveles más altos con el consiguiente aumento del control. La ‘granularidad’ aumenta desde arriba hacia abajo. Estas capas se correlacionan de arriba a abajo con las capas que se encuentran habitualmente en la jerarquía de automatización: la red en tiempo real, la red de control, la red de oficina y la red empresarial. Puede sonar familiar pero no lo es tanto. Valentijn de Leeuw detalla que la diferencia respecto a la arquitectura común de hoy en la industria es el uso de un buses de datos con mecanismos de publicación y suscripción para todos los niveles. "El IIRA propone el protocolo DDS (Distributed Data Service), con su componente en tiempo real DDS-RTPS para la capa de tiempo real. DDS está orientado a datos. En la industria, el mecanismo de publicar y suscribirse a veces se utiliza como middleware entre las capas de gestión de operaciones y de sistemas de negocio". Es decir, como un bus intra capa o inter capa en el diagrama expuesto anteriormente. “Sin embargo, en las capas inferiores, OPC-UA y otros protocolos propietarios son lo más común”. OPC-UA está orientado a objetos. Según De Leeuw, dado que DDS y OPC-UA trabajan en una interoperabilidad futura, no es descabellado imaginar que en el futuro la industria pueda optar al uso de soluciones mixtas dependiendo de las inversiones y activos que tenga.

¿Cómo es aplicable este patrón arquitectónico a un IDP? Ya hay ejemplos, nos explica el experto: la Industrial Data Space (IDS) es una asociación europea que proporciona un "espacio virtual de datos que apoya el intercambio seguro y vinculación en ecosistemas empresariales sobre la base de normas y el uso de modelos en la gobernanza colaborativa". Complementa las iniciativas orientadas a la producción como es el caso de la Industria 4.0. IDS tiene su propia arquitectura de referencia, construida en capas y con perspectiva. En la capa del sistema, se describen las interacciones entre los proveedores de datos, los consumidores de datos y otras partes interesadas, como una tienda de aplicaciones y los intermediarios de datos. En términos técnicos: la parte de ejecución del conector contiene un enrutador de mensajes y un bus de datos.

El organismo propone esta arquitectura como "el método más sencillo para intercambiar datos entre conectores", pero deja al implementador la libertad de usar otros mecanismos. Esto implica que el IIRA y las arquitecturas de referencia IDS son compatibles y que un patrón arquitectónico de ‘databus’ en capas sería compatible con las implementaciones IDS que eligen para la implementación del bus de datos. Dado que los intercambios previstos por IDS ocurren a nivel corporativo o de sitio, esta arquitectura también podría ser compatible con la solución mixta de adaptación mencionada anteriormente. El IDS propone un mecanismo para intercambios de datos abiertos y seguros entre todos los socios de la cadena de valor de la plataforma. De Leeuw reconoce que su enfoque contrasta con el enfoque utilizado por las plataformas propietarias de la nube, como Predix de GE, HANA de SAP, o el futuro de Siemens Mindsphere, y que están abiertos para la colaboración entre proveedores y usuarios, sin embargo, explica, "es probable que sean sólo parcialmente interoperables cuando un usuario tiene varias de estas plataformas para gestionar intercambios con diferentes proveedores, o si el usuario necesita gestionar intercambios con usuarios que utilizan diferentes plataformas". Para el experto, todas estas plataformas de nube propietarias podrían interoperar a través de IDS.