Gemeinsames Datenmodell von Tulip
- 13 May 2024
- 6 Minuten zu lesen
- Mitwirkende
- Drucken
Gemeinsames Datenmodell von Tulip
- Aktualisiert am 13 May 2024
- 6 Minuten zu lesen
- Mitwirkende
- Drucken
Artikel-Zusammenfassung
Fanden Sie diese Zusammenfassung hilfreich?
Vielen Dank für Ihr Feedback
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.
Ü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.
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.
Stationen
Zeigt alle Stationen in der Werkstatt an.
Einheiten
Dient zum Speichern eindeutiger physischer Lose, Seriennummern und Chargen.
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.
Standorte
Physische Standorte in der Produktionsstätte. Sie können mit Standorten von Beleuchtungskörpern für Pick-to-Light verbunden sein.
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.
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.
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.
Aktionen
Enthält Ereignisse, die eine Nachverfolgung erfordern.
Kanban-Karten
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.
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.
Genealogie-Datensätze
Jeder Datensatz ist eine Eltern/Kind-Beziehung. Das Kind kann entweder eine serialisierte oder nicht serialisierte Unterbaugruppe oder ein Einzelteil sein.
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.
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.
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.
Weitere Informationen
War dieser Artikel hilfreich?
