Portada » Blog » Asset Administration Shell

Asset Administration Shell

El Asset Administration Shell en la Industria 4.0

Nos introducimos de llenos en la Industria 4.0 con este nuevo post, en el que el objetivo es presentar lo que puede ser un concepto más o menos desconocido, el Asset Administration Shell en la Industria 4.0. La razón principal es que hasta hace poco era poco más que una idea teórica pero sin mucha implementación práctica, limitándose muchas veces a desarrollos I+D.

Partimos de que las soluciones de la Industria 4.0 requieren interoperabilidad entre todos sus actores, de modo que se puedan comunicar sin ningún tipo de problema. El AAS ha sido creado con el objetivo de ser la base esa interoperabilidad dentro de y entre empresas, basándose en un estándar abierto.

Se podría definir como un envoltorio software o una capa digital que se superpone a un objeto con el que podremos interactuar o comunicarnos, siendo el conjunto de ambos elementos lo que se denomina Componente I4.0 o también Activo 4.0 por su nombre Asset en inglés.

En principio el objeto podría ser cualquier cosa, dependiendo de como definamos la granularidad de nuestro sistema, que a su vez puede tener AAS internos. Así, nuestro elemento puede ser un sensor, un PLC, una máquina o incluso una fábrica, constituido por AAS. De todas maneras, mi opinión es que el objetivo es definir dispositivos o partes de una máquina, no definir fábricas u organizaciones enteras.

Por último, Industria 4.0 define un Asset como cualquier elemento que requiere una conexión para comunicarse dentro de o con una solución I4.0. Por lo tanto, aunque la idea es que este objeto sea algo físico, también podría ser digital, como planos, documentos o diagramas eléctricos.

Origen

El origen proviene de uno de los modelos teóricos que definen la arquitectura del concepto de Industria 4.0. Nos estamos refiriendo al RAMI 4.0 (Reference Architecture Industry 4.0). RAMI procura un marco teórico en el que todos los participantes compartan el mismo significado para cada elemento, así como su función específica y las comunicaciones que existen entre ellos. El RAMI 4.0 tiene una estructura tridimensional como vemos en la siguiente imagen.

RAMI 4.0

El eje X representa el ciclo de vida del producto desde la fabricación hasta su desecho o reciclaje. Aquí radican dos de los conceptos que después se traslada al AAS, y que se podría asemejar a lo que en programación llamamos Programación Orientada a Objetos (POO): Type e Instance. Type es nuestro producto en fases tempranas del ciclo (Diseño, simulación…), es decir, la clase sin instanciar. Mientras que una vez se empieza a fabricar pasan a ser Instancias, es decir, la pieza o producto final y real, lo que sería el objeto en POO.

El eje vertical representa las capas de interoperabilidad, describiendo las propiedades de un asset o una combinación de ellos, con un enfoque más hacia el mundo IT de la I4.0.

EjeZ-RAMI4.0

La última dimensión, el eje Y representado en la figura, representa los niveles de jerarquía. Esta representación es muy similar a la clásica pirámide de la automatización donde se muestran diferentes elementos que están presentes dentro de una fábrica: dispositivos a nivel de planta, SCADAs, PLCs… El último nivel sería el “Connected World” o mundo conectado, es decir, lo que sería el IoT o la conexión de la fábrica a Internet.

Definición de un Asset Administration Shell

Una buena definición de un AAS o componente 4.0 sería un elemento que tiene capacidades de procesamiento y de comunicación en red. Sería el primer paso para tener un gemelo digital de cada activo con su envoltorio digital y con toda la información almacenada en él disponible. Además, se tiene en cuenta también la privacidad, seguridad y la confidencialidad de la información almacenada.

Como mencioné brevemente en la introducción, se trata de una especie de envoltorio digital o wrapper, como se le conoce en inglés, que se superpone sobre un elemento de modo se pueda comunicar con la red o entorno en el que se encuentre e intercambie datos e información. No tiene porqué ser un objeto tangible o físico, ya que podría ser un documento como planos o especificaciones. Con el siguiente esquema entenderemos mejor la idea, aplicado a un dispositivo ampliamente conocido como es una Raspberry.

Esquema de un Asset Administration Shell

El Asset es el objeto que se encuentra en propiedad de la organización, mientras que el AAS es la representación digital del Asset. Lo identifica unívocamente y con diferentes enfoques de la información que se almacenan en los submodelos y que luego comentaremos.

Para comprender mejor la idea y donde encaja el Asset Administration Shell en la Industria 4.0, nos fijamos de nuevo en la figura de la RAMI 4.0. Comprobamos que la capa más baja del eje vertical es la llamada Asset, mientras que en la siguiente tenemos la integración. En estas capas estaría integrado el AAS, estando el elemento físico en la capa más baja, mientras que en la capa de integración estaría el envoltorio que nos permitiría comunicarnos con él.

Encaje del Asset Administration Shell dentro del RAMI

Documentación oficial

Hay 3 documentos sobre los que se está trabajando y de los que ya han sido publicados los dos primeros, siendo en su conjunto conocido como “Details of the Asset Administration Shell”. Por ejemplo, el documento “Details of AAS – Part 1” describe todas las características del AAS, además de su estructura interna y también define la información existente dentro de él:

  • Part 1. Información sobe el modelo del AAS para el intercambio de información (o el propio archivo) entre los socios de la cadena de valor. Se encuentra ya en su versión 3.0RC01, con fecha de publicación 23/11/2020. Os dejo el link. Este documento define las bases del AAS, definiciones de cada concepto, su estructura interna… y muy importante, como mapear y traducir la estructura a otros formatos.
Part 1 de la documentación oficial
  • Part 2. Interoperabilidad en runtime. Este documento se centra en el acceso a la información proporcionada por el AAS por parte de la empresa o de los usuarios mediante el uso de APIs. La versión es la 1.0 RC01, con fecha de publicación 23/11/2020. Os dejo el link.
Part 2 de la documentación oficial del Asset Administration Shell
  • Part 3. Infraestructura para contener e interconectar múltiples AAS. Se trata de un trabajo que se está llevando a cabo actualmente.

Part 3 de la documentación oficial del Asset Administration Shell

Cada uno de estos puntos se corresponden con diferentes tipos de interacción del AAS. El primero sería una interacción de Tipo 1 o Pasiva, el segundo punto sería una interacción de Tipo 2 o Reactiva, mientras que el tercer punto, habéis adivinado, de Tipo 3 o también llamada Proactiva.

Características

Un Asset Administration Shell describe un dispositivo, inteligente o no, que pueda integrarse, funcionar y comunicarse con varios sistemas sin requerir grandes cambios ni modificaciones. Es decir, está diseñado de modo que sea compatible con el mayor número de sistemas, independientemente de la tecnología del asset o del fabricante. Permite además, el acceso a todas sus propiedades y funciones.

Un activo puede tener varios AAS, dependiendo del entorno de su ciclo de vida. Por ejemplo, un fabricante puede tener su propio AAS del dispositivo que está diseñando y tener otro AAS para enviar a sus clientes. Después, el usuario del dispositivo puede usar otro AAS del mismo elemento físico, pero centrado en producción, con unas métricas diferentes. Sin embargo, todos serían compatibles entre sí y en el caso de querer usar los datos generados por el uso en línea de producción, sería fácil importarlos en el AAS del fabricante para detectar problemas o para su mejora o actualización.

La característica más importante y posiblemente el objetivo principal es que un AAS permite la interoperabilidad entre empresas. Permitiría el poder tener un formato estándar y abierto, permitiendo la comunicación horizontal, entre el fabricante del producto, el proveedor, el integrador y el usuario final.

Por ejemplo, el fabricante podría tener acceso a todos los datos generados durante la vida útil de cada una de sus piezas, permitiendo una mejora continua y un acercamiento al mantenimiento predictivo.

También tiene en cuenta los aspectos relativos a la seguridad, definiendo los permisos de acceso a la información almacenada basándose en el concepto ABAC (Attributes Based Access Control).

Identificadores

Cada AAS tiene un identificador único, así como también lo tienen los propios assets, los submodelos o las propiedades internas del AAS. Hay dos estándares globales para la identificación y uno personalizable:

  • IRDI (International Registration Data Identifier): sería el identificador para propiedades y clasificaciones. Se usa también en los repositorios del eCl@ss.

  • IRI (Internationalized Resource Identifier): es el identificador para los assets, los AAS y otro tipo de propiedades y clasificaciones.

  • Personalizado: También se permite otro identificador pero para uso interno dentro del propio AAS y usado por el propio fabricante. Se trata del GUID (Globally Unique Identifier).

Funcionalidades

Todas estas características permiten una serie de funcionalidades, de las que nombro solo unas pocas:

  • Uso en sistemas de fabricación flexibles y reconfigurables.

  • Integración rápida, mejorando el tiempo de puesta en marcha.

  • Fácil actualización de las líneas de producción.

  • Información persistente y actualizable desde los fabricantes, a los integradores y consumidores finales.

  • Multilenguaje, con toda la información almacenada en diferentes idiomas.

Por otro lado, podemo definir el gemelo digital como una representación digital de un objeto con datos que representan las características principales y secundarias de un asset, así como su comportamiento y como se relaciona con el entorno mediante funciones. De este modo se puede decir que el AAS se podría usar como la implementación de un gemelo digital estandarizado dentro de la Industria 4.0.

Estructura interna

La arquitectura interna de un AAS se basa en lo que se llaman submodelos, y que almacenan la información del asset o activo, a la vez que integran diferentes aspectos del componente 4.0. Estos submodelos también pueden incluir capacidades o funcionalidades del propio asset, como podría ser enfriamiento, movimiento o corte. En estos submodelos se pretende usar estándares como IEC, ISO o eCl@ss para tener una definición coherente con todos los actores del entorno.

Por otro lado, cada uno de los submodelos tiene que estar perfectamente descrito, además de tener un identificador único.

Hay una serie de submodelos estandarizados como podrían ser datos técnicos o la identificación del componente, pero también es posible añadir los submodelos que sean necesarios para poder integrar el asset dentro de una empresa, organización o en la cadena de valor. Por lo tanto, los submodelos a su vez contienen diferentes elementos que proporcionan la información que tiene que ver con dicho submodelo.

Podemos entenderlo mejor con el ejemplo mostrado en la imagen. A estos submodelos podrían añadirse nuevas definiciones que interesaran a la empresa de forma específica: Archivos almacenados, estructura de carpetas…

Estructura interna del Asset Administration Shell

Por otro lado, toda la descripción del AAS está definida en UML (Unified Modeling Language). Al ser independiente de la tecnología a usar, permite que el AAS se pueda mapear o “traducir” a otros estándares como son OPC-UA, AutomationML (del que hablaré en un post aparte), RDF (Resource Description Framework) o formatos como XML o JSON.

También hay otro elemento que son los eventos, mecanismo muy útil y que puede ser bidireccional. Algunos ejemplos que se pueden implementar sería la generación de logs, alarmas de seguridad, apagado de dispositivos, actualización de firmware…

Creación y programación de un Asset Administration Shell

Quizás a la hora de ponerlo en práctica es donde surgen más dudas: ¿cómo crear un AAS?, ¿cómo implementarlo en un caso práctico?, ¿qué tipo de software o hardware tengo que usar? Básicamente nos encontramos con dos preguntas importantes: como genero un AAS y como podemos hacer para acceder a esa información de modo, digamos, online.

Creación: AASX Explorer Package

Para la creación de un AAS podemos usar el AASX Package Explorer, el cual es un visor y editor desarrollado en C# y que tenéis a vuestra disponibilidad en la siguiente página de Github: https://github.com/admin-shell-io/aasx-package-explorer

Un problema que tiene  la herramienta es que no es muy intuitiva y los conceptos que maneja no son fáciles de entender para un profano en la materia, aunque te va marcando los errores existentes o varias recomendaciones si no rellenas parte de la información necesaria.

Debido a esto, para empezar a trabajar con el Package Explorer es recomendable ver una serie de video-tutoriales donde te explican paso a paso como trabajar con el software, así como conceptos de la I4.0, seguridad o temas básicos del AAS. Os dejo el link: http://admin-shell-io.com/screencasts/. Toda la información se encuentra en inglés, aunque con un nivel medio se entiende perfectamente. Para la gente que tenga conocimientos, también se encuentra en alemán.

Si descargamos los “binaries” y ejecutamos el exe, nos encontramos con esta pantalla.

Pantalla del AAS Package Explorer

Para poder editar y crear un AAS, tenemos que ir al menú > Workspace > Edit. De este modo podemos empezar a crear un AAS desde cero. En la siguiente imagen vemos como el sistema nos está informando de la falta de un AAS.

Edición del AAS Package Explorer

Lo mejor para hacerse una idea clara de la estructura de un AAS es abrir uno previamente creado, así que vamos a abrir un ejemplo de la siguiente página: http://www.admin-shell-io.com/samples/. Ahí encontraréis bastantes ejemplos que os darán una idea real de lo que sería un AAS. Específicamente elegimos el archivo 22_Festo. Se trata de una válvula de Festo en la que se encuentra toda la información del elemento.

AAS de una válvula de Festo

Como podemos observar, tenemos varios Submodelos ya creados:

  • Nameplate.

  • Identification.

  • MCAD.

  • Documentation.

  • Technical Data.

En cada uno de ellos tenemos varios “Submodel Element”, como propiedades o colecciones de propiedades. En ellos también pueden estar embebidos otros documentos como pdf o algunos tipos de archivos CAD.

Os dejo también un link en el que podéis descargar un ejemplo de un AAS para una Raspberry 3B+: https://github.com/i40-Tools/RAMIOntology/tree/master/AssetAdministrationShell_examples

Formato del archivo aasx

El archivo que hemos abierto y que maneja el package explorer tiene de extensión *.aasx, siendo un formato estándar definido por los documentos previamente comentados para poder llevar a cabo el intercambio de datos. Está basado en el estándar ISO/IEC 29500-2:2012. Este formato de intercambio se usa para una transmisión segura de los AAS.

Realmente es un formato .zip, que podéis abrir con el programa 7Zip, por ejemplo, y que permite ver la estructura del archivo. En el caso de incluir archivos integrados como planos o 3D, en el zip están almacenados. Vemos el mismo archivo visualizado mediante 7Zip.

Visualización de los archivos del AAS

Acceso a la información

Por otro lado, ¿cómo puedo acceder a la información? Realmente este formato es un archivo, no es algo que se encuentre accesible externamente o en modo online. Nos permite intercambiar AAS e información, pero no acceder a él.

Para poder conseguirlo, básicamente lo que hay que hacer es que toda esa información esté disponible mediante un protocolo de comunicación específico, por ejemplo creando un servidor y conectándose a él. Una idea sería la de mapear toda la información a OPC-UA, generar un servidor y conectarse externamente para acceder a los datos.

Un ejemplo claro es una implementación de un servidor AASX que hace accesible la información existente en los AASX packages usando REST, OPC-UA o MQTT. En este desarrollo de github tenéis una posibilidad de como llevarlo a cabo: https://github.com/admin-shell-io/aasx-server. Tienen un servidor de ejemplo en https://admin-shell-io.com:5001/, donde si pinchamos en el elemento mostrado en la siguiente figura, comprobamos que es el mismo que he elegido previamente como ejemplo del AASX explorer.

Servidor online de un Asset Administration Shell

Otras soluciones del Asset Administration Shell en la Industria 4.0

Además del AASX Package Explorer, que podríamos decir que es la implementación “oficial”, hay varias implementaciones del Asset Administration Shell en la Industria 4.0 que se están desarrollando en código abierto. Menciono algunas:

Además, existen muchos desarrollos de empresas e instituciones que trabajan con diferentes soluciones, ya que por ahora no hay una universal. Mencionamos algunos, pero hay muchísimos más:

Por ejemplo, en el paper “Connecting PLCs with their Asset AdministrationShell for Automatic Device Configuration“ (link) utilizan BaseX (BBDD basado en XML) y XQuery como medio para acceder a la BBDD y cargar la información del AAS que previamente se mapeó a formato AutomationML.

En “Toward the Plug-and-Produce Capability for Industry 4.0”, (link), donde se explora el Plug-and-Play con el uso del AAS, utiliza como opción la creación de un servidor OPC-UA.

En el caso de “Implementing Industry 4.0 Asset Administrative Shells in Mini Factories”, (link), utilizan una plataforma IoT llamada ThingWorx y un software de Kepware para obtener la conexión entre el AAS real y la plataforma ThingWorx.

Como vemos, hay muchas posibilidades y elegir una de ellas dependerá de las características y del entorno específico en el que se quiera desarrollar e implementar un sistema basado en AAS.

Definición de APIs en el Part 2

La publicación del documento “Details of the AAS – Part 2” antes mencionado, donde se especifica y define las interfaces así como las APIs que habilitan el acceso al AAS y sus submodelos, permite tener una mayor estandarización del acceso al AAS. La razón es que son especificaciones tecnológicamente neutrales, es decir, te dicen como deberían ser implementadas, pero no con qué. Se podría utilizar REST, MQTT o OPC-UA, así como los lenguajes que los desarrolladores estimen: C#, C++, Java, Python…

Este documento define conceptos asociados para diferentes niveles: servicios, interfaces y APIS y operaciones. En la siguiente imagen, obtenida directamente del documento se muestran las relaciones existentes.

Modelo funcional del API del AAS

Por último, hay un documento que define el AAS desde el punto de vista funcional, que lo podéis encontrar en https://www.plattform-i40.de/PI40/Redaktion/EN/Downloads/Publikation/Functional-View.html. De todas maneras, hay mucha información que ya está presente en el “Details of the Asset Administration Shell: Part 2”. Además, según he comprobado, por lo menos actualmente, hay errores de maquetación y referencias de figuras que no están correctamente editadas.

Ejemplos prácticos

El concepto de Asset Administration Shell en la Industria 4.0 ha sido hasta hace poco un concepto meramente teórico, aunque con implementaciones desde el punto de vista académico y de investigación. Como hemos visto, no existe un claro ejemplo de como implementarlo en la vida real y se pueden encontrar desarrollos que hacen uso de bases de datos, plataformas IoT, servidores OPC-UA, etc. Todo en aras de encontrar una manera correcta de llevar la idea a la práctica.

Hay varios proyectos europeos que están trabajando con la base de aplicar AAS en una serie de prototipos. Podemos nombrar el DIMOFAC: Digital Intelligent MOdular FACtories, https://dimofac.eu/ o el proyecto CanvAAS: a common language for machines, https://eitmanufacturing.eu/canvaas-a-common-language-for-machines-entering-the-industry-4-0-era/

Además de proyectos europeos en los que se está trabajando para aplicar en la práctica el concepto de AAS, también hay otros desarrollos para aprovechar el potencial que tiene. Uno de ellos traslada la típica placa presente en las máquinas con información técnica o número de serie al formato digital, mediante la inclusión de toda la información en un tag RFID en la que está almacenada con el formato AAS: https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2020/November/Das_Digitale_Typenschild_-_ZVEI-Empfehlung/Digital_Nameplate.pdf

Conclusión

En este post hemos arañado solo un poco de la superficie del concepto del Asset Administration Shell en la Industria 4.0, además de lo que nos puede aportar su aplicación en la industria. Hace unos años era solo una idea teórica con pocas aplicaciones prácticas, pero que actualmente se está comprobando la potencialidad que tiene para obtener la interoperabilidad entre diferentes actores de la cadena de valor. Además, aunque se aplique dentro de una misma organización, permitiría una rápida conexión de nuevos dispositivos o envío de información estandarizada.

Si tenéis más dudas acerca de lo que supone el AAS, como implementarlo u os interesaría algún tipo de tutorial en español para poder trabajar con el AASX explorer, no dudéis en poneros en contacto conmigo o en los comentarios.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *