Cómo utilizar un modelo de datos común

Orientaciones para adherirse a un Modelo Común de Datos y ejemplos de cómo crearlo.

¿Qué es un modelo de datos común?

Las aplicaciones pueden ser combinadas para resolver casos de uso, conectando a través de procesos de fabricación utilizando tablas en el Tulip Common Data Model for Discrete{target=_blank} o Common Data Model for Pharma. A diferencia de los modelos de datos tradicionales que se basan en las dependencias, el Modelo de Datos Comunes componible de Tulip permite que las tablas se añadan con el tiempo caso por caso.

Un modelo de datos común proporciona una colección de esquemas de datos estandarizados y ampliables. Estos esquemas predefinidos cubren varios tipos de datos, incluidos artefactos operativos, artefactos físicos, materiales de referencia y registros de eventos. Al representar conceptos y actividades ampliamente utilizados, como órdenes de trabajo y unidades, estos esquemas facilitan la creación, compilación y análisis de datos. Esta normalización contribuye a agilizar el tratamiento de los datos en distintos sistemas.

Modelo de datos común en Composability

Las tablas de tulipanes desempeñan un papel crucial en la gestión de los flujos de datos y el mantenimiento de la conexión entre aplicaciones. Contienen información que se muestra en las aplicaciones y éstas crean, actualizan y eliminan registros de tablas. Si varias aplicaciones utilizan las mismas tablas, pueden comunicarse entre sí a través de ellas.

Por ejemplo, un gestor crea una orden de trabajo en una aplicación y un operario la ejecuta en otra aplicación o conjunto de aplicaciones.

Cuando se diseña una solución para un problema dado, definir las tablas que se van a utilizar es uno de los pasos más importantes. Elegir las tablas de forma lógica puede resultar en aplicaciones más simples, reutilizables y componibles. Si la cantidad correcta de datos se almacena en tablas, el constructor de aplicaciones puede reducir el número de variables de aplicación utilizadas, haciendo que la aplicación sea menos compleja y fácil de personalizar. Si las aplicaciones dentro de una solución utilizan el mismo conjunto de tablas, las aplicaciones se vuelven intercambiables o componibles, sin tener que rediseñar una u otra aplicación.

Mejores prácticas

:::(Info) (Nota)Para entender las tablas que componen un modelo de datos común, es importante conocer las Best Practices for Storing Data in Tulip:::

Las tablas de Tulip deben seguir principalmente el modelo Digital Twin, lo que significa que las tablas deben reflejar la planta física o el taller lo más estrictamente posible. Los datos históricos de la aplicación deben limitarse a los Registros de Finalización, asegurando que las tablas no se utilicen para almacenar datos maestros o datos duplicados de Registros de Finalización o registros externos.

Tipos de tablas principales

Lo ideal es que las tablas representen artefactos físicos y operativos.

Estas tablas siempre incluirán un campo de Estado que será actualizado regularmente por las aplicaciones.

El siguiente diagrama muestra las tablas completas del Modelo de Datos Comunes y qué tablas utilizar para los casos de uso de fabricación discreta y farmacéutica.

A continuación se muestra un desglose de todos los tipos de tablas del Modelo de Datos Comunes:

Artefactos Físicos

Losartefactos físicos son objetos tangibles en sus instalaciones o componentes que se utilizan o producen durante las operaciones. Cuando el estado de un artefacto físico cambia o se actualiza, este cambio se refleja en el registro (por ejemplo, cambio de estado).

Existen dos categorías de artefactos físicos:

1. ActivosLos activosson componentes que equipan, contienen o actúan en un proceso, como: * Equipos * Balanzas * Ubicaciones

2. MaterialesLos materialesson los elementos utilizados o creados en un proceso, como: * Artículos de inventario * Unidades * Lote

3. Artefactos operativos

Losartefactos operativos son elementos o componentes tangibles o intangibles que permiten o apoyan las operaciones.

Existen tres categorías de artefactos operativos:

1. TareasLas tareasimplican un proceso procesable, como: * Resultados de inspección * Tarjetas Kanban

2. EventosLos eventosimplican algo que ha sucedido, como: * Defectos * Correcciones

3. ÓrdenesLas órdenesimplican información sobre bienes o compromisos, tales como: * Órdenes de trabajo * Órdenes de proceso

Tipos de tablas secundarias (avanzadas)

Hay ocasiones en las que puede necesitar considerar romper las mejores prácticas. En circunstancias más avanzadas, y con la menor frecuencia posible, puede que necesite utilizar los siguientes dos tipos de tablas secundarias:

• Registro
• Referencia

Es probable que los datos de estas tablas sean estáticos y no se actualicen (por eso es preferible mantener este tipo de datos en registros de finalización o en el sistema externo original).

:::(Error)Secondary table types do not fit within a Digital Twin model and should only be considered by advanced users. Sólo debe incluir estos tipos de tabla una vez que haya pasado por el proceso de diseño de la solución y haya agotado todas las demás opciones. Los tipos de tabla secundarios NUNCA deben servir de base para una solución de aplicación:::

Registros

Los registros de eventos son información que se puede buscar y define algo en producción. A menudo se encuentran en sistemas externos como un ERP. Dado que los datos históricos se rastrean tradicionalmente a través de la finalización de la aplicación y se almacenan en registros de finalización, SÓLO necesitará utilizar una tabla de registro si:* Necesita separar datos específicos de los registros de finalización con fines de visualización* Necesita utilizar estos datos en cálculos, específicamente consultas y agregaciones.

Por ejemplo:

• Notas y comentarios
• Registros genealógicos
• Historial de actividad de la estación
• Resultados de inspecciones

NO debe recurrir a las tablas de registro para:* Registros históricos* Trazabilidad

Referencias

Lasreferencias son registros compartidos entre aplicaciones. Es similar al concepto de registro de finalización, salvo que se comparte entre aplicaciones y hace accesibles las Consultas a Tablas, Aggregations y la mutabilidad de las Tablas Tulipán.

Siempre que sea posible, los datos deben obtenerse en tiempo real directamente de la fuente original, como un ERP, a través de un conector HTTP. Es posible que necesite utilizar una tabla de referencia en casos marginales como:* Temporalmente, mientras se establece la conexión con un ERP.* Si su sistema externo contiene datos de referencia limitados que necesitan ser aumentados con Tulip.

Su enfoque evolucionará con el tiempo a medida que las soluciones maduren y los sistemas se integren y acoplen más estrechamente.

Ejemplos:

• Definiciones de materiales
• Lista de materiales

Construya su propio Modelo de Datos Comunes

El ejemplo de Tulip Common Data Model está diseñado como punto de partida para construir su propio modelo de datos. Sin embargo, todos los procesos y soluciones son diferentes y, al igual que las aplicaciones, el modelo de datos se puede personalizar según sea necesario.

Los cambios más pequeños incluyen añadir y eliminar campos de las tablas. En algunos casos (procesos especiales, múltiples tablas necesarias para el mismo caso de uso) se requieren cambios mayores. Esto puede hacerse sustituyendo una o varias tablas del modelo de datos descargado o insertando tablas adicionales.

Planificar un modelo de datos común

1. Defina los artefactos físicos y operativos de su proceso
2. Busque las tablas correspondientes a cada artefacto
3. Explore los tipos de datos que deben recopilar las aplicaciones y las referencias que deben utilizarse

Más información

• Almacenamiento de datos
• Tablas comunes de Tulip
• Mejores prácticas para almacenar datos en Tulip