---
title: "Machine monitoring data model"
slug: "machine-monitoring-data-model"
updated: 2025-12-22T17:23:23Z
published: 2025-12-22T17:23:23Z
canonical: "support.tulip.co/machine-monitoring-data-model"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.tulip.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Machine monitoring data model

A common decision in machine monitoring is **when to use Tulip tables instead of the machine activity table**.

**In this article, you will learn:**

- **When to use Tulip tables**
- **When to use the machine activity table**
- **The strengths and limitations of each**

## Machine activity table: Built-in OEE tracking

A system table that machine triggers automatically populate and that logs:

- State (Running, Stopped, Offline)
- Start time, end time, and duration
- Downtime reason
- Part count and defect count
- Ideal run rate
- Custom activity fields (user-defined)

### Strengths

- Minimal configuration - automatically associated with Tulip machines
- Optimized for OEE calculations (Availability, Performance, Quality)
- Works seamlessly with machine triggers (headless)
- Analytics can directly query machine activity data

### Limitations

- **No Tulip Table API access** - you cannot programmatically read or write to the Machine Activity table via API
- **No table record ID** - difficult to link to other tables
- Export only via CSV archive (not real-time integration)

### Use machine activity table for OEE only

If your **only goal** is to track machine uptime and downtime and calculate OEE, use machine triggers with the Machine Activity Table. This is the simplest, most cost-effective solution.

#### Example

![Machine State by Value](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Machine%20State%20by%20Value.png)

## Tulip tables: Flexible data model for complex use cases

### When to use Tulip Tables

- You need **custom data fields** not available in Machine Activity Table (for example, Work Order ID, Operator Badge, SKU)
- You need **CRUD operations** (Create, Read, Update, Delete) via APIs
- You integrate machine data with **other business processes** (quality, inventory, maintenance)
- You want to **contextualize machine data** with work orders, batches, or production schedules

## Use both machine activity table and Tulip tables

**Machine Activity Table** (via machine triggers):

- Capture raw state changes
- Calculate OEE metrics

**Tulip Table** (via automations or app triggers):

- Enrich machine data with business context
- Enable API-based integrations
- Link to work orders, quality records, and other data

### Example architecture

Note: 'Automation' refers to Tulip [Automations](/r230/docs/automations).

![MM - Data Model for Downtime.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/MM%20-%20Data%20Model%20for%20Downtime.png)

This hybrid model provides:

- OEE dashboards from Machine Activity Table
- Root cause analysis from Tulip Table with API access for external BI tools

## Handle manual data with rework and scrap patterns

**Challenge**: Machines automatically report part counts, but human context (rework, scrap, manual adjustments) requires manual input. How do you reconcile automated machine counts with manual corrections?

### Avoid corrupting machine data

**Do not** attempt to decrement machine part count when an operator logs rework.

**Why this fails**: The machine does not understand human context. If you write back to the machine, you corrupt the raw data source.

### Separate truth sources

1. Let the machine report raw counts.
2. Use a separate table for manual adjustments.
3. Calculate net production via expressions.

#### Example data model

**Machine Activity Table** (automatic):

- Part Count: 104 (raw machine output)
- Defects: 0 (machine does not track)

**Production Log Table** (Tulip Table, via app):

- ID: 12345
- Work Order: WO-5678
- Machine ID: CNC-001
- Gross Parts: 104 (copied from machine at run end)
- Rework Count: 4 (operator input)
- Scrap Count: 0
- Net Parts: 100 (calculated: Gross - Rework - Scrap)
- Timestamp

#### App workflow:

1. Operator starts a run and selects a work order
2. Machine runs and increments part count automatically
3. Operator notices 4 parts need rework and passes them back through
4. Machine increments to 104 (the machine counts 104 parts)
5. Operator ends the run, and the app creates a Production Log record
6. App copies machine part count (104) to the Gross Parts field
7. Operator manually enters Rework Count: 4
8. App calculates Net Parts = 104 - 4 = 100

**Analytics**:

- **Machine OEE**: Uses raw part count (104) for performance calculation
- **Production Reports**: Uses Net Parts (100) for actual output

**Optional enhancement**: Log defects to a Machine Activity Field for OEE Quality calculation:

![write rework count to machine attribute](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/write%20rework%20count%20to%20machine%20attribute.png)

This allows OEE Quality % to reflect the actual defect rate while preserving raw machine counts.

## Further reading

- [Create your first machine trigger](/r230/docs/create-your-first-machine-trigger)
- [Automations](/r230/docs/automations-1)
- [Tables](/r230/docs/tables)
- [Export Tulip activity data](/r230/docs/export-tulip-activity-data)

---

Did you find what you were looking for?

You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have solved a similar topic!

**OEE (Overall Equipment Effectiveness)**

A key performance indicator (KPI) that measures manufacturing productivity by calculating the percentage of planned production time that is truly productive. **OEE** combines three factors: **Availability** (uptime), **Performance** (speed), and **Quality** (good parts produced).

**Formula:** OEE = Availability × Performance × Quality

**Scale:** Expressed as a percentage, where 100% represents perfect production (manufacturing only good parts, as fast as possible, with no downtime).