Tulip Common Data Model
- 25 Apr 2024
- 6 Minutes to read
- Contributors
- Print
Tulip Common Data Model
- Updated on 25 Apr 2024
- 6 Minutes to read
- Contributors
- Print
Article Summary
Share feedback
Thanks for sharing your feedback!
Tulip Common Data Model
Applications can be combined to solve use cases, connecting across manufacturing processes using tables in the Tulip Common Data Model. Unlike traditional data models that rely on dependencies, Tulip’s composable Common Data Model allows tables to be added over time on a case-by-case basis.
Through tables, apps interact with each other. A status update in a table is how an operator using an app at one station can signal to an operator using an app at another station. For example, a manager creates a work order in one app and an operator executes that work order in another app or set of apps.
Best Practices
Prerequisites
Before we dive into the tables that comprise our data model, it's important to understand Best Practices for Storing Data in Tulip.
Tulip Tables should chiefly follow the Digital Twin model, meaning tables should reflect the physical plant or shop floor as strictly as possible. Historical app data should be confined to Completion Records, ensuring tables are NOT used to store master data or duplicate data from Completion Records or external records.
Ideally, tables solely represent:
- Physical Artifacts
- Operational Artifacts
These tables will always include a Status field that will be regularly updated by apps.
| Type | Description | Examples |
|---|---|---|
| Physical Artifact | This is something tangible that you can physically touch on your shop floor. | Inventory Item, Equipment & Assets |
| Operational Artifact | This is a uniquely identified, intangible element that can be commonly found related to operations. These are often found as printed travelers or tickets. | Defect Event, Work Order |
However, there are times when you may need to consider breaking best practices. For more advanced circumstances—and as sparingly as possible—you might need to use following two secondary table types:
- Log
- Reference
The data in these tables will likely be static and will not be updated (which is why it is preferred to keep these types of data either in completion records or in the original, external system).
Secondary table types do not fit within a Digital Twin model and should only be considered by advanced users. You should only include these table types once you've gone through the Solution Design process and exhausted all other options. Secondary table types should NEVER serve as the foundation for an app solution.
| Type | Description | Examples |
|---|---|---|
| Reference | This is information that can be looked up and defines something in production. These are often found in external systems such as an ERP. | Material Definition, Bill of Material |
| Log | This is a shared ledger between applications. This is similar to the concept of a completion record except that it is shared across applications and makes accessible Table Queries, Aggregations and the mutability of Tulip Tables. | Station Activity History, Inspection Records |
Primary Table Types
Physical Artifacts
Physical Artifacts are tangible objects or components that are used or produced during operations.
A Physical Artifact's state will change or update, and this change will be reflected in the record (e.g. status change).
The descriptions of the following tables take precedence over their names. Feel free to adjust the names of the tables to better suit your operations, as long as they align with the essence of the table's description.
Inventory Items
Holds inventory by location and item.
Stations
Shows all stations on the shop floor.
Units
Used to store unique physical lots, serial numbers, and batches.
Equipment and Assets
Reusable equipment or devices, not part of the Bill of Materials, but may be required for procedures and may require calibration.
Locations
Physical locations on the production floor. They can be associated with light kit locations for pick-to-light.
Operational Artifacts
Operational Artifacts are non-physical elements or components that enable or support operations. These are often found as printed travelers or tickets.
Operational Artifact implies that operations will be performed on a record (e.g. status change).
The descriptions of the following tables take precedence over their names. Feel free to adjust the names of the tables to better suit your operations, as long as they align with the essence of the table's description.
Material Requests
Holds material replenishment requests for specific items between departments.
Work Orders
The production requirements of your operation. These are generated from orders and represent a demand of specific materials to be produced in order to fulfill the order.
Defects
Tracking of defect. Each line is a unique defect related to single material or observance of deviation. Lines can have multiple quantity.
Actions
Holds events that require follow up.
Kanban Cards
Secondary (Advanced) Table Types
The following secondary table types do not fit within a Digital Twin model and should only be considered by advanced users. You should only include Reference or Log tables once you've gone through the Solution Design process and exhausted all other options. These tables should never serve as the foundation for an app solution.
Logs
Logs are a secondary table type within the Tulip Common Data Model, as they do not fit within a Digital Twin model and should only be considered by advanced users. You should only include Log tables once you've gone through the Solution Design process and exhausted all other options. Log tables should NEVER serve as the foundation for an app solution.
Since historical data is traditionally tracked via App Completion and stored to Completion Records, you ONLY need to use a Log table if:
- You need to separate specific data from the completion records for visualization purposes
- You need to use this data in calculations, specifically queries and aggregations
You should NOT turn to Log tables for:
- Historical records
- Traceability
Notes and Comments
Users can store notes that are attached to work orders, shifts, or other process artifacts.
Station Activity History
Stores a historical record of production output and status by station, grouped by hour. Similar in function and purpose to the machine activity table.
Genealogy Records
Each record is a parent/child relationship. The child could be either a serialized or unserialized subassembly or individual part.
Inspection Results
Stores the results of procedure steps with relation to the material being inspected. These are pass/fail results or measurements taken during a process step that requires an input from the user.
References
References are a secondary table type within the Tulip Common Data Model, as they do not fit within a Digital Twin model and should only be considered by advanced users. You should only include Reference tables once you've gone through the Solution Design process and exhausted all other options. Reference tables should NEVER serve as the foundation for an app solution.
Wherever possible, data should be fetched in real-time directly from the original source—such as an ERP—via an HTTP Connector. You may need to use a Reference table in fringe cases such as:
- Temporarily, while establishing connection to an ERP.
- If your external system contains limited reference data that needs to be augmented with Tulip.
Your approach will evolve over time as solutions mature and systems become more integrated and tightly coupled.
Materials Definitions
Definitions of all items made, purchased, or assembled. This describes items and their specific properties.
Bill-of-Materials
This table is typically used in lieu of integration with a system of record that could pass this data in real time. This table holds a bill of material and procedures for a given product of parent item. It can be used to display required component items and quantities broken down by process step.
Further Reading
Was this article helpful?
