Jak korzystać ze wspólnego modelu danych

Wskazówki dotyczące przestrzegania wspólnego modelu danych i przykłady jego tworzenia.

Czym jest wspólny model danych?

Aplikacje można łączyć w celu rozwiązywania przypadków użycia, łącząc procesy produkcyjne za pomocą tabel w Tulip Common Data Model for Discrete{target=_blank} lub Common Data Model for Pharma. W przeciwieństwie do tradycyjnych modeli danych, które opierają się na zależnościach, Tulip's composable Common Data Model pozwala na dodawanie tabel w miarę upływu czasu.

Common Data Model zapewnia zbiór znormalizowanych i rozszerzalnych schematów danych. Te predefiniowane schematy obejmują różne typy danych, w tym artefakty operacyjne, artefakty fizyczne, materiały referencyjne i dzienniki zdarzeń. Reprezentując szeroko stosowane koncepcje i działania, takie jak zlecenia pracy i jednostki, schematy te ułatwiają tworzenie, kompilowanie i analizowanie danych. Ta standaryzacja pomaga usprawnić obsługę danych w różnych systemach.

Wspólny model danych w komplementarności

Tabele Tulip odgrywają kluczową rolę w obsłudze przepływów danych i utrzymywaniu połączenia między aplikacjami. Zawierają informacje, które są wyświetlane w aplikacjach, a aplikacje tworzą, aktualizują i usuwają rekordy tabeli. Jeśli wiele aplikacji korzysta z tych samych tabel, mogą one komunikować się ze sobą za pośrednictwem tabel.

Na przykład menedżer tworzy zlecenie pracy w jednej aplikacji, a operator wykonuje to zlecenie w innej aplikacji lub zestawie aplikacji.

Podczas projektowania rozwiązania dla danego problemu, zdefiniowanie tabel, które będą używane jest jednym z najważniejszych kroków. Logiczny wybór tabel może skutkować prostszymi, bardziej wielokrotnego użytku i komponowalnymi aplikacjami. Jeśli odpowiednia ilość danych jest przechowywana w tabelach, kreator aplikacji może zmniejszyć liczbę używanych zmiennych aplikacji, czyniąc aplikację mniej złożoną i łatwą do dostosowania. Jeśli aplikacje w ramach rozwiązania korzystają z tego samego zestawu tabel, aplikacje stają się wymienne lub komponowalne, bez konieczności przeprojektowywania jednej lub drugiej aplikacji.

Najlepsze praktyki

:::(Info) (Uwaga)Aby zrozumieć tabele, które składają się na wspólny model danych, ważne jest, aby znać najlepsze praktyki dotyczące przechowywania danych w Tulip:

Tabele Tulip powinny być przede wszystkim zgodne z modelem Digital Twin, co oznacza, że tabele powinny jak najdokładniej odzwierciedlać fizyczny zakład lub halę produkcyjną. Historyczne dane aplikacji powinny być ograniczone do Completion Records, zapewniając, że tabele nie są używane do przechowywania danych głównych lub duplikatów danych z Completion Records lub rekordów zewnętrznych.

Podstawowe typy tabel

Najlepiej byłoby, gdyby tabele reprezentowały fizyczne i operacyjne artefakty.

Tabele te zawsze będą zawierać pole Status, które będzie regularnie aktualizowane przez aplikacje.

Poniższy diagram przedstawia pełne tabele we Wspólnym Modelu Danych oraz tabele, których należy używać w przypadku produkcji dyskretnej i zastosowań farmaceutycznych.

Poniżej znajduje się zestawienie wszystkich typów tabel we Wspólnym Modelu Danych:

Fizyczne artefakty

Fizyczne artefakty to namacalne obiekty w zakładzie lub komponenty, które są używane lub produkowane podczas operacji. Gdy stan fizycznego artefaktu zmienia się lub aktualizuje, zmiana ta jest odzwierciedlana w rekordzie (np. zmiana statusu).

Istnieją dwie kategorie artefaktów fizycznych:

1. ZasobyZasobyobejmują komponenty, które wyposażają, zawierają lub działają w procesie, takie jak: * Urządzenia * Wagi * Lokalizacje

2. MateriałyMateriałyobejmują elementy używane lub tworzone w procesie, takie jak: * Pozycje magazynowe * Jednostki * Partie

Artefakty operacyjne

Artefakty operacyjne to materialne lub niematerialne elementy lub komponenty, które umożliwiają lub wspierają operacje.

Istnieją trzy kategorie artefaktów operacyjnych:

1. ZadaniaZadaniaobejmują proces, który można wykonać, np: * Wyniki inspekcji * Karty Kanban

2. ZdarzeniaZdarzeniaobejmują coś, co się wydarzyło, np: * Wady * Korekty

3. ZamówieniaZamówieniazawierają informacje o towarach lub zobowiązaniach, takie jak: * Zlecenia pracy * Zlecenia przetwarzania

Dodatkowe (zaawansowane) typy tabel

Istnieją sytuacje, w których należy rozważyć złamanie najlepszych praktyk. W bardziej zaawansowanych okolicznościach - i tak oszczędnie, jak to możliwe - może być konieczne użycie następujących dwóch drugorzędnych typów tabel:

• Dziennik
• Odniesienie

Dane w tych tabelach będą prawdopodobnie statyczne i nie będą aktualizowane (dlatego preferowane jest przechowywanie tego typu danych w rekordach uzupełniania lub w oryginalnym, zewnętrznym systemie).

:::(Error)Secondary table types do not fit within a Digital Twin model and should only be considered by advanced users. Te typy tabel należy uwzględniać dopiero po przejściu przez proces projektowania rozwiązania i wyczerpaniu wszystkich innych opcji. Drugorzędne typy tabel NIGDY nie powinny służyć jako podstawa rozwiązania aplikacji :::

Dzienniki

Dzienniki zdarzeń to informacje, które można wyszukać i które definiują coś w produkcji. Często można je znaleźć w systemach zewnętrznych, takich jak ERP. Ponieważ dane historyczne są tradycyjnie śledzone przez App Completion i przechowywane w Completion Records, tabeli Log należy używać TYLKO wtedy, gdy:* trzeba oddzielić określone dane od rekordów ukończenia w celu wizualizacji* trzeba użyć tych danych w obliczeniach, w szczególności w zapytaniach i agregacjach.

Przykłady:

• Notatki i komentarze
• Rekordy genealogiczne
• Historia aktywności stacji
• Wyniki inspekcji

NIE należy korzystać z tabel dziennika w celu uzyskania:* Zapisów historycznych* Identyfikowalności

Odniesienia

Referencje są księgami współdzielonymi między aplikacjami. Jest to podobne do koncepcji rekordu ukończenia, z wyjątkiem tego, że jest on współdzielony między aplikacjami i udostępnia zapytania do tabel, Aggregation i zmienność tabel Tulip.

Tam, gdzie to możliwe, dane powinny być pobierane w czasie rzeczywistym bezpośrednio z oryginalnego źródła - takiego jak ERP - za pośrednictwem konektora HTTP. Może zaistnieć potrzeba użycia tabeli referencyjnej w skrajnych przypadkach, takich jak:* Tymczasowo, podczas ustanawiania połączenia z ERP.* Jeśli system zewnętrzny zawiera ograniczone dane referencyjne, które muszą zostać uzupełnione przez Tulip.

Podejście będzie ewoluować wraz z upływem czasu, w miarę jak rozwiązania będą dojrzewać, a systemy staną się bardziej zintegrowane i ściśle powiązane.

Przykłady:

• Definicje materiałów
• Zestawienie materiałów

Zbuduj swój własny wspólny model danych

Przykładowy Wspólny Model Danych Tulip został zaprojektowany jako punkt wyjścia do zbudowania własnego modelu danych. Jednak wszystkie procesy i rozwiązania są różne i, podobnie jak aplikacje, model danych można dostosować w razie potrzeby.

Mniejsze zmiany obejmują dodawanie i usuwanie pól z tabel. W niektórych przypadkach (specjalne procesy, wiele tabel potrzebnych do tego samego przypadku użycia) wymagane są większe zmiany. Można to zrobić, zastępując jedną lub więcej tabel z pobranego modelu danych lub wstawiając dodatkowe tabele.

Planowanie wspólnego modelu danych

1. Zdefiniuj fizyczne i operacyjne artefakty procesu.
2. Znajdź odpowiednie tabele dla każdego artefaktu
3. Zbadaj typy danych, które mają być gromadzone przez aplikacje i odniesienia, które muszą być używane.

Więcej informacji

• Przechowywanie danych
• Wspólne tabele Tulip
• Najlepsze praktyki przechowywania danych w Tulip