Skip to content
Tier0 Docs

Modeling Factory Data

Available inEdgeCloudEnterprise

Data in your factory, either machine data sending from sensors, or order data exiting in ERP/MES, can all be modeled into understandable tree structure in Tier0.

How the Demo UNS is Structured

Section titled “How the Demo UNS is Structured”

Physical Data

Section titled “Physical Data”

Industrial data from machines and equipment with physical locations is modeled based on the ISA-95 standard.

Demo Model

Section titled “Demo Model”
Terminal window
Enterprise (Level 4)
└── Site (Level 3/4)
    └── Area (Level 3)
        └── Work Center / Process Cell (Level 2/3)
            └── Equipment / Unit (Level 1/2)
                └── Control Module / Device (Level 0/1)

Business Data

Section titled “Business Data”

For business planning and process objects, such as production orders and work order plans in an ERP, model data according to its business context.

Business Data Modeling Guide

Section titled “Business Data Modeling Guide”
Terminal window
Factory / Business Domain / Business Object / Topic Type / Topic

  • Business Domain: The business process or system the data belongs to.

    Terminal window
    ERP
    MES
    WMS
    QMS
    EAM
    LIMS
    Planning
    Inventory
    Maintenance
    Quality
    Logistics
    ...

  • Business Object: The core managed object in the business domain.

    Terminal window
    ProductionOrders
    WorkOrderPlan
    MaterialInventory
    QualityInspection
    MaintenanceOrders
    PurchaseOrders
    Shipments
    ...

  • Topic Type: Metric, Action, and State.

    Topic Type Used for Examples
    STATE Current status or current facts Work order status, order status, equipment status
    METRIC Continuously changing numeric values Temperature, speed, output, OEE, energy consumption
    ACTION Commands for external executors Start equipment, stop equipment, reset alarm, request work order dispatch

Demo Model

Section titled “Demo Model”
Terminal window
DemoFactory
└── ERP
    ├── ProductionOrders
    │   └── State
    │       ├── UpsertProductionOrder
    │       └── OrderList
    └── WorkOrderPlan
        ├── Metric
        │   └── SplitCount
        └── State
            ├── PlanStatus
            └── WorkOrderList

Payload Structure

Section titled “Payload Structure”

Data to be consumed and written back must both be considered when structuring the topic payload.

  • Action

    Action payloads automatically include _timestamp, which records when the data is stored in the Tier0 database.

    Terminal window
    {
      "light_turn_on": true,
      "height_adjust": 12.5,
      "_timestamp": "2026-07-10T10:00:00Z"
    }

  • Metric

    Metric payloads automatically include _timestamp, which records when the data is stored in the Tier0 database, and _quality, which represents data quality.

    Terminal window
    {
      "production_order_id": "PO-20260710-001",
      "plan_id": "PLAN-001",
      "plan_number": "WOP-20260710-001",
      "split_count": 3,
      "updated_at": "2026-07-10T10:00:00Z",
      "_timestamp": "2026-07-10T10:00:00Z",
      "_quality": "Good"
    }

  • State

    State payloads automatically include _timestamp, which records when the data is stored in the Tier0 database.

    Terminal window
    {
      "event_id": "EVT-001",
      "event_type": "UPSERT",
      "source": "ERP",
      "production_order_id": "PO-20260710-001",
      "order_number": "PO-001",
      "product_code": "SKU-1001",
      "planned_qty": 1200,
      "unit": "pcs",
      "status": "Released",
      "due_date": "2026-07-12T00:00:00Z",
      "updated_at": "2026-07-10T10:00:00Z",
      "_timestamp": "2026-07-10T10:00:00Z"
    }

How to Avoid Topic Explosion

Section titled “How to Avoid Topic Explosion”

Tier0 uses three fixed topic types, Metric, Action, and State, to avoid topic explosion.

  • Use Metric for high-frequency real-time data

    Put high-frequency measurements and telemetry under Metric instead of expanding the namespace for every signal detail.

    Terminal window
    Factory_A
    └── SMT_Line_1
        └── Machine_001
            ├── Temperature_Value
            ├── Temperature_Unit
            ├── Temperature_Status
            └── Speed_Value

  • Use State for low-frequency status data

    Put low-frequency status, snapshots, and current business state under State. Avoid creating a new topic for every changing entity such as jobs, batches, or orders.

    Terminal window
    Factory_A
    └── SMT_Line_1
        └── State
            ├── Job_001
            ├── Job_002
            └── Job_003

  • Use Action for low-frequency action data

    Put commands, requests, and operator actions under Action. Keep action inputs as fields on a topic rather than creating one topic per parameter.

    Terminal window
    Factory_A
    └── SMT_Line_1
        └── Machine_001
            ├── Start_Command
            ├── Target_Height
            └── Light_On