Gemeinsames Datenmodell von Tulip
  • 13 May 2024
  • 6 Minuten zu lesen
  • Mitwirkende

Gemeinsames Datenmodell von Tulip


Artikel-Zusammenfassung

Tulip Gemeinsames Datenmodell

Anwendungen können kombiniert werden, um Anwendungsfälle zu lösen, wobei die Verbindung zwischen verschiedenen Herstellungsprozessen über Tabellen im Tulip Common Data Model{target=_blank}. Im Gegensatz zu traditionellen Datenmodellen, die auf Abhängigkeiten beruhen, ermöglicht das komponierbare Common Data Model von Tulip, dass Tabellen im Laufe der Zeit von Fall zu Fall hinzugefügt werden können.

Composability Levels Combined.png

Über Tabellen interagieren die Anwendungen miteinander. Eine Statusaktualisierung in einer Tabelle ist die Art und Weise, wie ein Bediener, der eine App an einer Station verwendet, einem Bediener, der eine App an einer anderen Station verwendet, ein Signal geben kann. Zum Beispiel erstellt ein Manager einen Arbeitsauftrag in einer App und ein Bediener führt diesen Arbeitsauftrag in einer anderen App oder einer Reihe von Apps aus.

Tulip Data Model Combined.png

Bewährte Praktiken

:::(Info) (Voraussetzungen) Bevor wir in die Tabellen eintauchen, die unser Datenmodell bilden, ist es wichtig, die Best Practices für die Speicherung von Daten in Tulip zu verstehen. :::

Tulip-Tabellen sollten hauptsächlich dem Digitalen Zwilling folgen, d.h. die Tabellen sollten so genau wie möglich die physische Anlage oder die Produktionshalle widerspiegeln. Historische Anwendungsdaten sollten sich auf Abschlusssätze beschränken und sicherstellen, dass Tabellen NICHT zur Speicherung von Stammdaten oder doppelten Daten aus Abschlusssätzen oder externen Datensätzen verwendet werden.

Idealerweise repräsentieren die Tabellen ausschließlich:

  • Physische Artefakte
  • Operative Artefakte

Diese Tabellen enthalten immer ein Statusfeld, das von den Anwendungen regelmäßig aktualisiert wird.

| Typ | Beschreibung | Beispiele | | --- | --- | | | | | Physisches Artefakt | Dies ist etwas Greifbares, das Sie in Ihrer Werkstatt anfassen können. | Dies ist ein eindeutig identifizierbares, immaterielles Element, das üblicherweise im Zusammenhang mit dem Betrieb zu finden ist. Sie werden oft als gedruckte Reisende oder Tickets gefunden. | Defektes Ereignis, Arbeitsauftrag |

Es gibt jedoch Situationen, in denen Sie von bewährten Verfahren abweichen sollten. Unter fortgeschrittenen Umständen - und so sparsam wie möglich - sollten Sie die folgenden zwei sekundären Tabellentypen verwenden:

  • Protokoll
  • Referenz

Die Daten in diesen Tabellen werden wahrscheinlich statisch sein und nicht aktualisiert werden (weshalb es vorzuziehen ist, diese Arten von Daten entweder in Abschlussdatensätzen oder im ursprünglichen, externen System zu speichern).

Secondary table types do not fit within a Digital Twin model and should only be considered by advanced users. Sie sollten diese Tabellentypen erst dann einbeziehen, wenn Sie den Lösungsentwurfsprozess durchlaufen und alle anderen Optionen ausgeschöpft haben. Sekundäre Tabellentypen sollten NIEMALS als Grundlage für eine App-Lösung dienen. :::

| Typ | Beschreibung | Beispiele | | --- | --- | | | | | Referenz | Dies sind Informationen, die nachgeschlagen werden können und etwas in der Produktion definieren. Diese sind oft in externen Systemen wie einem ERP-System zu finden. | Materialdefinition, Stückliste | | Protokoll | Dies ist ein gemeinsames Hauptbuch zwischen Anwendungen. Es ähnelt dem Konzept eines Abschlussdatensatzes, mit dem Unterschied, dass es anwendungsübergreifend genutzt wird und Tabellenabfragen, Aggregationen und die Veränderbarkeit von Tulip-Tabellen zugänglich macht. | Station Activity History, Inspection Records |

Primäre Tabellentypen

Physische Artefakte

Physische Artefakte sind greifbare Objekte oder Komponenten, die während des Betriebs verwendet oder produziert werden.

Der Zustand eines physischen Artefakts ändert oder aktualisiert sich, und diese Änderung wird im Datensatz wiedergegeben (z. B. Statusänderung).

Die Beschreibungen der folgenden Tabellen haben Vorrang vor ihren Namen. Es steht Ihnen frei, die Namen der Tabellen zu ändern, um sie besser an Ihre Operationen anzupassen, solange sie mit dem Kern der Tabellenbeschreibung übereinstimmen.

Inventar Artikel

Enthält das Inventar nach Standort und Artikel.Common Table Inventory Items

Stationen

Zeigt alle Stationen in der Werkstatt an.Common Table Stations

Einheiten

Dient zum Speichern eindeutiger physischer Lose, Seriennummern und Chargen.Common Table Units

Ausrüstung und Anlagen

Wiederverwendbare Ausrüstung oder Geräte, die nicht Teil der Stückliste sind, aber für Verfahren benötigt werden und möglicherweise kalibriert werden müssen.Common Table Equipment and Assets

Standorte

Physische Standorte in der Produktionsstätte. Sie können mit Standorten von Beleuchtungskörpern für Pick-to-Light verbunden sein.Common Table Locations

Betriebliche Artefakte

Operative Artefakte sind nicht-physische Elemente oder Komponenten, die den Betrieb ermöglichen oder unterstützen. Sie sind oft als gedruckte Reisende oder Tickets zu finden.

Operationale Artefakte implizieren, dass Operationen an einem Datensatz durchgeführt werden (z. B. Statusänderung).

Die Beschreibungen der folgenden Tabellen haben Vorrang vor ihren Namen. Es steht Ihnen frei, die Namen der Tabellen anzupassen, damit sie besser zu Ihren Vorgängen passen, solange sie mit dem Kern der Tabellenbeschreibung übereinstimmen.

Materialanfragen

Enthält Materialnachschubanforderungen für bestimmte Artikel zwischen Abteilungen.Common Tables Material Requests

Arbeitsaufträge

Die Produktionsanforderungen Ihres Betriebs. Diese werden aus Aufträgen generiert und stellen einen Bedarf an bestimmten Materialien dar, die zur Erfüllung des Auftrags produziert werden müssen.Common Table Work Orders

Defekte

Verfolgung von Mängeln. Jede Zeile ist ein eindeutiger Fehler, der sich auf ein einzelnes Material oder die Einhaltung einer Abweichung bezieht. Linien können mehrere Mengen haben.
Common Table Defects

Aktionen

Enthält Ereignisse, die eine Nachverfolgung erfordern.Common Table Actions

Kanban-Karten

Common Table Kanban Cards

Sekundäre (erweiterte) Tabellentypen

Die folgenden sekundären Tabellentypen passen nicht in ein Digital Twin-Modell und sollten nur von fortgeschrittenen Benutzern in Betracht gezogen werden. Sie sollten Referenz- oder Protokolltabellen erst dann einbeziehen, wenn Sie den Lösungsentwurfsprozess durchlaufen und alle anderen Optionen ausgeschöpft haben. Diese Tabellen sollten niemals als Grundlage für eine App-Lösung dienen.

Protokolle

Logs are a secondary table type within the Tulip Common Data ModelSie passen nicht in ein Digitales Zwillingsmodell und sollten nur von fortgeschrittenen Benutzern in Betracht gezogen werden. Sie sollten Protokolltabellen erst dann einbeziehen, wenn Sie den Lösungsdesignprozess durchlaufen und alle anderen Optionen ausgeschöpft haben. Log-Tabellen sollten NIEMALS als Grundlage für eine App-Lösung dienen::: Da historische Daten traditionell über App-Abschlüsse verfolgt und in Abschlussdatensätzen gespeichert werden, müssen Sie NUR dann eine Log-Tabelle verwenden, wenn: * Sie bestimmte Daten zu Visualisierungszwecken von den Abschlussdatensätzen trennen müssen * Sie diese Daten in Berechnungen, insbesondere Abfragen und Aggregationen, verwenden müssen

Sie sollten NICHT auf Protokolltabellen zurückgreifen für: * Historische Datensätze * Rückverfolgbarkeit

Notizen und Kommentare

Benutzer können Notizen speichern, die an Arbeitsaufträge, Schichten oder andere Prozessartefakte angehängt sind.Common Table Notes and Comments

Historie der Stationsaktivitäten

Speichert eine historische Aufzeichnung der Produktionsleistung und des Status nach Station, gruppiert nach Stunden. Ähnlich in Funktion und Zweck wie die Maschinenaktivitätstabelle.Common Table Station Activity History

Genealogie-Datensätze

Jeder Datensatz ist eine Eltern/Kind-Beziehung. Das Kind kann entweder eine serialisierte oder nicht serialisierte Unterbaugruppe oder ein Einzelteil sein.Common Table Genealogy Records

Inspektionsergebnisse

Speichert die Ergebnisse von Verfahrensschritten in Bezug auf das zu prüfende Material. Dabei handelt es sich um Gut/Schlecht-Ergebnisse oder Messungen, die während eines Verfahrensschritts vorgenommen wurden, der eine Eingabe durch den Benutzer erfordert.Common Table Inspection Results

Referenzen

References are a secondary table type within the Tulip Common Data ModelReferenztabellen sind nicht sinnvoll, da sie nicht in ein Digital Twin Modell passen und nur von fortgeschrittenen Benutzern berücksichtigt werden sollten. Sie sollten Referenztabellen erst dann einbeziehen, wenn Sie den Lösungsentwurfsprozess durchlaufen und alle anderen Optionen ausgeschöpft haben. Referenztabellen sollten NIEMALS als Grundlage für eine App-Lösung dienen. :::

Wo immer es möglich ist, sollten die Daten in Echtzeit direkt aus der ursprünglichen Quelle - z. B. einem ERP - über einen HTTP-Connector abgerufen werden. Die Verwendung einer Referenztabelle kann in Ausnahmefällen erforderlich sein, z. B.: * Vorübergehend, wenn eine Verbindung zu einem ERP-System hergestellt wird; * Wenn Ihr externes System begrenzte Referenzdaten enthält, die mit Tulip ergänzt werden müssen.

Ihre Herangehensweise wird sich im Laufe der Zeit weiterentwickeln, wenn die Lösungen ausgereift sind und die Systeme stärker integriert und eng gekoppelt werden.

Definitionen von Materialien

Definitionen für alle hergestellten, gekauften oder montierten Artikel. Dies beschreibt Artikel und ihre spezifischen Eigenschaften.Common Table Material Definitions

Stückliste

Diese Tabelle wird in der Regel anstelle einer Integration mit einem Aufzeichnungssystem verwendet, das diese Daten in Echtzeit weitergeben könnte. Diese Tabelle enthält eine Stückliste und Verfahren für ein bestimmtes Produkt oder einen übergeordneten Artikel. Sie kann verwendet werden, um die erforderlichen Komponenten und Mengen aufgeschlüsselt nach Prozessschritten anzuzeigen.Common Table Bill of Materials

Weitere Informationen


War dieser Artikel hilfreich?