27. May 2021
El shell de gestión como «gemelo digital» estandarizado
Junto a la soberanía y la sostenibilidad, la interoperabilidad es uno de los pilares del lema de la Industria 4.0, y es precisamente en este campo de acción donde es necesario tener en cuenta las normas y la integración. Sobre todo para nuestros clientes de ingeniería mecánica y construcción de plantas, la integración es un tema muy importante y, por lo tanto, también el shell de gestión (VwS, AAS: Asset Administration Shell), pues ayuda a facilitar esta integración a través de normas y a configurarla de modo que quede preparada para el futuro.
En una entrevista, Christian Heinrich, de XITASO, explica en qué consiste exactamente el shell de gestión y los casos reales en los que puede ofrecer un apoyo concreto. Un proyecto con nuestro cliente Wittenstein SE proporciona una visión de la realidad en la práctica.
¿Cómo definiría en pocas palabras en qué consiste el shell de gestión?
Explicado de forma simple, el shell de gestión es un «conector de datos», es decir, el único punto (de interfaz) a través del que es posible encontrar o almacenar los datos o la información sobre un activo, dispositivo o componente concreto. También se puede ir más allá y decir que el shell de gestión es una (algunos dirían «LA») aplicación del «gemelo digital», por lo que también representa la base de la Industria 4.0.
¿Tiene un ejemplo concreto del shell de gestión?
Por supuesto. Por ejemplo, con nuestro cliente Wittenstein SE, hemos utilizado shells de gestión para incluir los datos de los componentes del sistema SAP en el portal de servicios de dicho cliente.
Para ello, la base de datos SAP se sincroniza en un «SAP Drop» en la nube y el repositorio del shell de gestión se rellena mediante un proceso ETL (del inglés «extract, transform, load», extraer, transformar, cargar). Para este proceso ETL, tenemos una asignación de las características de SAP con el número IRDI del catálogo ECLASS, para que esas características tengan la semántica correcta y todos las entiendan con claridad. A continuación, una API REST proporciona la información de los componentes, es decir, de cada instancia individual, en el formato estandarizado del shell de gestión. Esto significa, por ejemplo, que es posible consultar la fecha de fabricación de la transmisión, que está aquí, delante de mí, a través de esta API REST.
En este ejemplo, la metáfora de «conector de datos» también resulta palpable, pues la información de un componente puede utilizarse a continuación en diferentes sistemas a través de esta API REST, lo que también mejora de forma sostenible la capacidad de integración de estos componentes.
¿Qué aspecto tiene un shell de gestión?
El shell de gestión se divide en submodelos, donde cada uno de ellos cubre un aspecto o un caso práctico. En definitiva, los submodelos son grupos de características. También puede acceder en línea a algunos shells de gestión haciendo clic aquí para obtener rápidamente su propia imagen de un shell de gestión.
Aquí puede ver una sección de la lista de shells de gestión. Un shell de gestión (AAS) tiene siempre aquí los submodelos (Sub) «Nameplate», «Document» e «Identification», aunque la mayoría tienen más.
Dentro de un submodelo, se encuentran las características (Prop, Properties), que también se pueden gestionar en listas (Coll, Collections). Una característica se compone de un valor (Value), el tipo de valor (Value Type) y una identificación semántica, lo que tiene por objeto describir claramente lo que significa esta característica. El ejemplo resaltado en la captura de pantalla es la función «ManufacturerName» en el submodelo «Nameplate» del shell de gestión «Festo_3S7PM0CP4BD». Esta característica tiene el valor «Festo AG & Co. KG» (a la derecha en la captura de pantalla) del tipo «string». El valor de SemanticID es aquí «IRDI» con el número «0173-1#02-AAO677#002». Este IRDI (International Registration Data Identifier) es un identificador único de la característica y se define en el catálogo ECLASS para que todos sepan exactamente qué significa esta característica.
Un shell de gestión no solo puede estar disponible como API REST, sino también como archivo aasx. Este archivo aasx está en formato Open XML, es decir, basta con sustituir la extensión .aasx por .zip y descomprimirlo para ver los archivos XML o JSON individuales que describen el activo. Además, también es posible guardar en esa ubicación imágenes y PDF. Haga clic aquí puede ver algunos shells de gestión en formato de archivo aasx que pueden descargarse de forma gratuita.
También puede abrir estos archivos aasx con el Explorador de paquetes Aasx y, de este modo, ver de forma sinóptica los submodelos y los datos del shell de gestión. El Explorador de paquetes Aasx está disponible como código abierto en github y se desarrolla de forma constante. En la actualidad, puede incluso proporcionar una API REST a nivel local, así como mostrar datos en directo. Definitivamente, merece la pena echar un vistazo aquí.
¿Qué submodelos o casos prácticos admite ahora el shell de gestión?
Algunos submodelos están ya estandarizados, pero cada uno es libre de crear un nuevo submodelo para su caso práctico concreto y compartirlo con su socio de integración. Los submodelos estándar son mantenidos y publicados por el «Consejo de Normalización de la Industria 4.0»
con el apoyo de la Comisión Alemana de Electrotécnica, Electrónica y Tecnologías de la Información (DKE) de la VDE. Además, el proyecto «InterOpera» pretende desarrollar 50 submodelos concretos, practicables e interoperables. Así pues, merece la pena echar un vistazo a esta página con regularidad.
Por ejemplo, un submodelo importante es la «identificación», que puede utilizarse para identificar el activo específico, pues contiene, por ejemplo, el nombre del fabricante, el número de serie y también el identificador único del activo (es decir, la instancia concreta).
Otro submodelo es la «placa de características». Se trata de un submodelo que proporciona la base para la Industria 4.0, pues permite el acceso global a la información de los dispositivos que, además, puede ser ilimitada en cuanto a tamaño y alcance. Del mismo modo, esta información también puede ajustarse de forma dinámica y mostrarse en cada pantalla, lo que convierte en superflua la documentación en papel. Sobre todo en el caso de los componentes pequeños o de bajo coste, esto elimina los costes relativamente altos de impresión y envío.
En esta página web de la Plataforma I4.0 se presentan algunos ejemplos de shells de gestión con los submodelos «Placa de características», «Identificación» o incluso «Documentación», por lo que dan una buena impresión de la información que se transporta en este caso.
¿Es posible imaginarse otros casos prácticos?
Claro que sí. Cada uno es totalmente libre para definir su propio submodelo y adaptarlo a su caso de uso concreto. La forma en la que se crea un submodelo se describe muy bien en la publicación «Verwaltungsschale in der Praxis / Wie definiere ich Teilmodelle, beispielhafte Teilmodelle und Interaktion zwischen Verwaltungsschalen?» (El shell de gestión en la práctica/¿Cómo se definen los modelos, los submodelos y la interacción ente shells de gestión?).
Como todos los elementos de un submodelo están descritos semánticamente (porque así lo exige la especificación VwS), todos entienden los nuevos submodelos creados.
Por ejemplo, puedo definir el submodelo «Perforación» y asignárselo a los activos que pueden perforar y describir allí qué materiales, qué profundidad mínima y máxima y qué diámetro pueden tener los agujeros, lo que a su vez permite encontrar automáticamente el activo correcto para un trabajo específico. Y no solo en mi empresa, sino también en todas las empresas, porque todos entienden lo que he descrito en el submodelo «Perforación».
Además, también es posible trazar el comportamiento esperado del activo en diferentes condiciones dentro de un mismo submodelo. A continuación, estos conocimientos sobre el comportamiento pueden utilizarse, por ejemplo, para realizar simulaciones junto con otros componentes con el fin de identificar cualquier problema antes de la puesta en marcha real. Asimismo, también es posible activar operaciones de mantenimiento o reparación durante el funcionamiento si el comportamiento real ya no se corresponde con el esperado.
¿Existe una comunidad de código abierto?
Así es. En septiembre de 2020, la «Industrial Digital Twin Association» alemana de la Industria de Ingeniería Mecánica), la ZVEI (Asociación Alemana de Fabricantes Eléctricos y Electrónicos), Bitkom (Asociación Alemana de Tecnologías de la Información, Telecomunicaciones y Nuevos Medios) y 20 empresas para proporcionar un punto de contacto para desarrolladores y diseñadores.
¿Dónde se puede encontrar más información sobre cómo iniciarse fácilmente en el shell de gestión?
- Un buen lugar para empezar es Home of AAS, que es el sitio web del github Repository mencionado antes.
- En el marco del evento de Bitkom «Management shell for software providers», que se celebró el 30 de marzo de 2021 presenté un informe práctico junto con Bernd Vojanec de Wittenstein SE. Para ver una transcripción completa de la ponencia, haga clic aquí.
- Para ver un conjunto completo de screencasts, haga clic aquí.
Más información de interés
He aquí una visualización a través del «Asset Administration Shell Viewer», que hemos construido en la plataforma Siemens Mindsphere como parte del proyecto Wittenstein mencionado al principio para visualizar un shell de gestión.
El shell de gestión que se muestra aquí proporciona un submodelo que contiene el historial de los ciclos de programación, lo que significa que los servicios inteligentes de Wittenstein escriben en el shell de gestión a través de la API REST y, a su vez, ponen esta información a disposición de otros servicios.
Para ver una descripción detallada del proyecto, haga clic aquí.
