Un flujo, una dirección: cómo se incorporan los datos al pasaporte del producto

Un flujo, una dirección: cómo se incorporan los datos al pasaporte del producto

Los sistemas ERP, MES, PLM y PIM alimentan el pasaporte digital del producto y mantienen el control sobre los datos. El flujo de datos solo va en una dirección y lo único que se recibe a cambio son confirmaciones.

En cuanto se concreta la creación de un pasaporte digital de producto, el departamento de TI plantea una pregunta antes que ninguna otra: ¿A cuáles de nuestros sistemas debe acceder la plataforma? Es la pregunta adecuada, ya que detrás de ella hay datos de acceso, autorizaciones del cortafuegos y un concepto de seguridad del que alguien debe responsabilizarse.

Nuestra respuesta es breve: ninguno. Todos los sistemas que aportan datos al pasaporte se encuentran en el lado de origen y permanecen allí. Transpareo es exclusivamente el receptor al final de la cadena; los flujos de datos se dirigen de forma unidireccional hacia la plataforma. Este artículo traza el recorrido de los flujos: lo que aporta cada sistema, qué reglas se aplican a cada flujo y qué se recibe a cambio como acuse de recibo.

Lo que aporta cada sistema al carné

Los datos de un carné rara vez proceden de un solo sistema. En la práctica, se distribuyen entre un puñado de clases de sistemas, cada una de las cuales aporta solo unos pocos campos:

  • ERP: identidad del artículo, materiales, proveedores y origen, referencia a pedidos y lotes, cantidades. Datos maestros estables que rara vez cambian.
  • MES: historial de producción, asignación de series y lotes, certificados de calidad, trazabilidad. Datos de eventos, vinculados a un momento concreto.
  • APS: momentos de producción y asignación de recursos. Rara vez es directamente relevante para el pasaporte; lo que importa suele proceder del MES.
  • PLM: composición, listas de piezas, reparabilidad, piezas de recambio, estados de diseño. A juzgar por lo que exige el Reglamento sobre diseño ecológico, es la fuente más completa.
  • PIM: descripciones, imágenes, instrucciones de mantenimiento y uso, variantes lingüísticas. Los contenidos destinados al consumidor.
  • IoT: datos de estado y uso durante la fase de uso. Solo es necesario para determinados grupos de productos, como las baterías.
  • CRM: historial de servicio y reparaciones de clientes individuales. En principio, se trata de datos personales y, por lo tanto, no deben figurar en un pasaporte público.

La capa de administración se sitúa por encima de los sistemas, no junto a ellos

Hay una distinción más importante que todas las demás: la Asset Administration Shell no se sitúa junto a ERP, MES y PIM, sino por encima de ellos. No genera datos, sino que encapsula los existentes en submodelos interoperables. En lo que respecta a la conexión con Transpareo, esto significa que un AAS es un formato de entrega cómodo, pero no imprescindible. Quien la utilice, derivará el paquete de datos de sus submodelos; quien no lo haga, proporcionará los mismos campos por otros medios. Las razones por las que, a pesar de todo, consideramos que la «Asset Administration Shell» es una base excelente se explican en el artículo sobre la AAS.

Cinco reglas que se aplican a todos los flujos

Dirección. Todas las flechas apuntan hacia la plataforma. Transpareo no consulta ningún sistema fuente y no dispone de datos de acceso a ERP, MES, PIM ni PLM. No existe ninguna conexión con sus sistemas que deba protegerse, porque sencillamente no existe.

Desencadenante. El envío siempre se activa desde el lado de origen: por el propio fabricante, su middleware o un proveedor de servicios contratado. La plataforma espera; no va a buscar los datos.

Finalidad específica. Solo se transmite el subconjunto necesario para el «pasaporte», no el conjunto completo de datos del sistema fuente. El «pasaporte» solo necesita unos pocos campos de cada sistema; todo lo demás permanece donde está.

Autorización. La selección, el alcance y el momento de cada paquete los decide el lado de origen. Transpareo no puede recibir más de lo que se le ha entregado.

Autorizaciones. Lo que se permite hacer con los datos entregados en la plataforma se rige por credenciales de acceso específicas: derechos mínimos, y lo que no esté expresamente permitido sigue estando prohibido. Estas reglas se aplican en la plataforma, nunca con carácter retroactivo sobre la fuente.

Solo se devuelven los acuses de recibo

No es posible prescindir por completo de un canal de retorno, pero este no transporta datos, sino respuestas: la URL DPP o el GS1 Digital Link, el ID de versión, el estado de publicación y los mensajes de validación. Para la página de origen, estas respuestas son valiosas porque la referencia de la orden de entrega se puede almacenar directamente en el artículo del ERP o del PIM. No constituyen un acceso. Son el acuse de recibo de una entrega recibida.

Tres modelos que han demostrado su eficacia en la práctica

  • Directamente desde el sistema principal. El ERP o el PLM envían los datos a través de un conector. Es sencillo y práctico cuando una fuente de datos predomina claramente.
  • A través de una capa de agregación. El middleware o el iPaaS agrupan los campos del ERP, el MES y el PIM y entregan un paquete. Es lo habitual cuando intervienen varias fuentes.
  • A través de submodelos AAS. La capa de gestión ya está en uso y el paquete se deriva de sus submodelos. Resulta ventajoso en entornos de la Industria 4.0.

En el Manual de conexión con ERP hemos detallado qué patrón se adapta a cada entorno de sistemas y cómo un proyecto de este tipo puede completarse en dos semanas en lugar de tres meses.

Lo que Transpareo no es, a propósito

No es un segundo «sistema de registro». La plataforma almacena el registro de datos del Pass y su historial de versiones inalterable, no los datos operativos del fabricante. Lo que se corrige en el ERP llega al Pass a través de un nuevo envío, como una versión nueva y trazable, no como un cambio silencioso en el stock. En la entrada sobre firmas y certificados se explica cómo se firma esta cadena de versiones y cómo puede ser verificada por cualquiera.

Por lo tanto, queda poco que comprobar en tu plan de seguridad, y esa es precisamente la intención. No hay datos de acceso que debas facilitar, ni aberturas en el cortafuegos hacia el interior, ni ningún sistema externo con derechos de lectura en tu ERP. El trabajo real del proyecto se desplaza allí donde debe estar: decidir qué campos deben incluirse en el «Pass», y no quién puede iniciar sesión y dónde.

Flujos de datos e interfaces en el boletín informativo

Cómo incorporar correctamente los datos de los productos en el carné: patrones de integración, límites del sistema y guías prácticas, cada mes en su bandeja de entrada.