¿Qué es esto del Digital Product Passport? ¿Y por qué me interesa como ingeniero software?

Hoy por hoy, la producción de desechos en diferentes partes del mundo es significativamente alta debido a factores como el consumismo, la industrialización, el crecimiento de la población, las malas prácticas de reciclaje y eliminación de residuos, entre otros. Solo la Unión Europea genera alrededor de 2.2 billones de toneladas de residuos cada año y es probable que esta cantidad aumente en los próximos años. Por supuesto que esto genera preocupaciones relacionadas con contaminación, insalubridad, e impacto ambiental. Para abordar este problema, se requieren soluciones como la adopción de enfoques de economía circular, por ejemplo, la implementación del pasaporte digital de productosz, digital product passport en inglés (DPP).

DPP es una iniciativa europea destinada a acelerar la transición hacia una economía circular. Su objetivo principal es compartir información clave sobre los productos, incluyendo su composición, impacto ambiental durante la manufactura, emisiones generadas por el transporte, instrucciones de reparación y reciclaje, y otros datos relevantes de su ciclo de vida. DPP busca incentivar mejoras en la eficiencia energética y en el uso de materiales, prolongar la vida útil de los productos y optimizar su diseño, fabricación, utilización y reciclaje.

La información contenida en el pasaporte digital es gestionada principalmente por las empresas manufactureras del producto, quienes conocen los detalles sobre su composición, materias primas utilizadas, recursos empleados en su producción y procesos de fabricación. Sin embargo, el DPP involucra a varios actores/usuarios más allá de las empresas manufactureras. Por ejemplo, los clientes que buscan acceso transparente a información sobre sostenibilidad para tomar mejores decisiones de compra; los usuarios responsables de verificar las regulaciones gubernamentales sobre productos; o incluso a usuarios con intereses sociales en la regulación de productos.

Sin embargo, dado que el DPP es una iniciativa reciente y las implementaciones apenas están comenzando a surgir y madurar, la regulación aún deja algunos aspectos poco claros. Por ejemplo, surgen preocupaciones técnicas relacionadas con los protocolos, las arquitecturas y las tecnologías utilizadas, así como inquietudes sobre los datos: ¿exactamente quién recopila la información? ¿quién la verifica? y ¿qué información es necesaria para el pasaporte digital?

En particular, la falta de claridad sobre un esquema de datos estandarizado genera problemas de interoperabilidad entre las plataformas y soluciones tecnológicas que implementan esta iniciativa. Cada solución puede diseñar e implementar un modelo estructural de datos diferente e incompatible con otros, lo que plantea desafíos y complicaciones para la integración de los datos. En particular, es necesario garantizar la interoperabilidad semántica para lograr el intercambio de la información de forma correcta. El International Data Spaces (IDS) facilita algunas recomendaciones para mejorar la interoperabilidad semántica en espacios de datos como el de DPP. En particular, se propone la definición de una representación declarativa de los conceptos del dominio específico mediante un vocabulario usando machine-readable schemas como RDF Schema. Este vocabulario provee una vista normativa del modelo de información que puede ser utilizado tanto por los proveedores de datos como por los consumidores para mejorar la interoperabilidad.

El DPP como un caso de uso para herramientas low-code

Como parte de nuestro proyecto BESSER, cuyo objetivo es el desarrollo de una herramienta low-code que pueda ser útil en una gran variedad de dominios, nos planteamos si el dominio del DPP no podría ser justamente un buen caso de uso donde demostrar las ventajas del low-code a la hora de generar una infraestructura tecnológica para un nuevo campo. Y aunque no uses BESSER, creo que veremos muchas aplicaciones para gestionar DPPs pronto (y seguramente también alguna regulación que te obligará a hacerlas dependiendo de tu sector) con lo que esto te puede interesar.

Dicho y hecho. Nuestra contribución en esta área es:

• Proponemos un modelo estructural de datos que representa el ecosistema de DPP. Este modelo abstrae los conceptos e información relevante del DPP para cada una de las etapas del ciclo de vida del producto.
• Implementamos este modelo de estructura de datos utilizando la plataforma low-code BESSER y desarrollamos un generador de código para producir la representación declarativa del modelo estructural. Es decir, con BESSER generamos una primera versión del Vocabulario en formato RDF Turtle.
• Usamos BESSER para demostrar cómo se puede generar rápidamente una infraestructura DPP, creando el código necesario para desplegar una aplicación web para el ecosistema DPP.

Modelando el ecosistema de datos de DPP

El modelo estructural que representa el ecosistema DPP es presentado en la Figura 1. Este modelo fue basado en diferentes estándares como la propuesta ESPR de la Comisión Europea, que sugiere una lista de requerimientos de datos para DPP y la iniciativa Product Circularity DataSheet (PCDS) en Luxemburgo.

Fijaros que este modelo puede ser útil a cualquier empresa que quiera dar soporte a DPP y esté buscando una representación de los datos que esto implicaría, aunque no pretendan usar BESSER para eso.

El concepto central del modelo (Figura 1) es ProductPassport, que representa el DPP de un producto. Un ProductPassport incluye atributos de identificación esenciales (como UID, GTIN, nombre del producto, código del producto y marca), junto con el DataCarrier, que indica la tecnología (código QR, código de barras, o NFC) que permite acceder al DPP. La información sobre la composición química, peligros y materiales reciclados del producto está representada por las clases Chemical, Hazard y RecycledMaterial (tomadas del PCDS).

En este modelo, consideramos seis etapas dentro del ciclo de vida de un producto: Design, Use (donde se pueden regsitrar Reparations), Manufacture, Collect, Distribution y Recycle. Estas etapas heredan de LifecycleStage, cuyas relaciones permiten describir los siguientes aspectos:

• environmental_impacts: esta relación permite especificar un rango de valores y consumo de recursos a lo largo de las diferentes etapas del ciclo de vida del producto. Por ejemplo, para cuantificar el uso de agua durante la fase de fabricación.
• materials: para cada etapa del ciclo de vida del producto, también es posible indicar el tipo y la cantidad de materiales utilizados. Por ejemplo, para detallar las materias primas empleadas en el proceso de fabricación del producto.
• companies: permite indicar las empresas o entidades responsables asociadas a cada etapa del producto. Por ejemplo, indicar la empresa encargada de la distribución del producto.
• issuer: la información de cada etapa es creada y atribuida a una parte responsable, como un empleado de fabricación, un revisor de regulaciones estatales u otra persona autorizada. Esta relación de issuer permite especificar a la persona responsable.

Generación del Vocabulario usando BESSER

En cualquier Espacio de Datos, es fundamental usar términos estandarizados para describir datos, servicios, contratos y otros componentes con el fin de cumplir con los requisitos de interoperabilidad. Los términos estandarizados que son específicos de un dominio (ej., los términos de nuestro modelo de datos estructural) se recogen en un documento de Vocabulario, el cual debe compartirse con todas las partes involucradas. Según IDS, este vocabulario debe ser legible por máquinas y estar disponible en un Hub de Vocabulario, donde se pueda colaborar en su definición y documentación. Para crear una primera versión de este vocabulario, hemos desarrollado un generador de código en BESSER, como se explica a continuación.

BESSER ofrece un conjunto de generadores de código para distintas tecnologías como SQL, Django, FastAPI, entre otras. Además, permite desarrollar generadores de código personalizados para necesidades específicas. En nuestro caso, creamos un nuevo generador de código que produce el vocabulario para cualquier modelo de datos estructural, no solo para DPP. Este generador es capaz de crear una versión inicial de la especificación del vocabulario en formato RDF Turtle, que luego puede ser refinada o actualizada por diseñadores de sistemas o expertos del dominio. El vocabulario, generado en formato RDF según las recomendaciones de IDSA, facilita el intercambio y la integración de información, mejorando la interoperabilidad semántica.

Nuestro generador de código RDF utiliza el motor de plantillas Jinja para generar dinámicamente clases y propiedades, tomando como base el modelo estructural de DPP (mostrado en la Figura 1) implementado en BESSER. La Figura 2 muestra un extracto del contenido RDF generado por este código para el modelo estructural de DPP. Este vocabulario incluye la definición de:

• Los prefijos que simplifican el uso de URIs en los datos RDF,
• Las clases que representan categorías o tipos (como LifecycleStage y ProductPassport),
• Las propiedades que describen los atributos o características de las clases. Por ejemplo, la propiedad ex:start_date está definida para la clase LifecycleStage y su tipo de dato es un dateTime,

Finalmente, las relaciones entre las clases, que también se representan como propiedades. Estas relaciones definen cómo se conectan las diferentes clases entre sí. Por ejemplo, ex:issuer es una propiedad que vincula LifecycleStage con Person.

En el espacio de datos DPP, los vocabularios son clave para garantizar la interoperabilidad semántica. Los proveedores de datos deben publicar un nuevo vocabulario o utilizar uno existente para describir sus conjuntos de datos. Este vocabulario se emplea luego para validar los datos durante las transacciones. Los consumidores de datos usan este vocabulario para implementar las interfaces necesarias que les permitan recibir y validar la información, asegurándose de que cumpla con los estándares esperados. Este proceso ayuda a mantener un intercambio de datos coherente y eficiente entre los distintos participantes.

Desarrollo de una aplicación web para DPP

Para validar nuestro modelo de datos estructurales y proporcionar una infraestructura que permita la creación de conceptos definidos en el vocabulario, aprovechamos nuevamente el desarrollo low-code.

El desarrollo de low-code está ganando atención tanto en la industria como en el ámbito académico, gracias a su capacidad para acelerar la creación de software. Las herramientas low-code pueden generar partes del código de la aplicación a partir de un modelo que describe el dominio. Por ejemplo, BESSER ofrece un lenguaje de modelado (B-UML) para diseñar distintos tipos de modelos y utiliza generadores de código para respaldar diferentes etapas del ciclo de vida del software. Con BESSER, puedes especificar modelos que definan el esquema de datos estructurales, el despliegue, la interfaz gráfica de usuario, las restricciones OCL y más.

Como se mencionó anteriormente, implementamos el modelo DPP que se muestra en la Figura 1 como un modelo estructural en BESSER. Ahora, vamos a utilizar el generador de código de Django para agilizar el desarrollo de una aplicación web. Específicamente, este generador puede producir el código para la capa de modelo de la aplicación web, que define la estructura y gestión de los datos en una base de datos relacional, incluyendo operaciones CRUD para las entidades o clases definidas en el modelo estructural DPP.

La Figura 3 muestra la interfaz gráfica de la aplicación web para DPP que hemos desarrollado usando el código generado. El panel izquierdo contiene la lista de conceptos del modelo estructural (como las etapas del ciclo de vida de un producto), mientras que a la derecha se encuentra el formulario para crear un nuevo pasaporte de producto.

Resumen

En busca de lograr la implementación de DPP y abordar retos como la interoperabilidad semántica, proponemos un esquema de datos estructural para el ecosistema DPP y un generador de código que crea vocabularios en un formato RDF legible por máquinas. Implementamos nuestro esquema y generador de código utilizando BESSER, una plataforma de bajo código para el desarrollo de software inteligente, con el fin de demostrar lo rápido que se puede crear y desplegar la infraestructura DPP utilizando una herramienta de bajo código como BESSER. El código fuente puede ser consultado en este repositorio.