Digital Factory Simulator (DFS)

Installation

Download the Digital Factory Simulator for your operating system from the MaestroHub Portal.

Windows

1. Download the DFS ZIP file for Windows from the portal.
2. Extract the ZIP file to a folder of your choice.

After extraction, you will see the following structure:

factory-launcher_*_windows_amd64/
├── README.txt
├── factory-launcher.exe
├── start-launcher.bat

3. Double-click factory-launcher.exe to start the application. The application will appear in the system tray and a browser window will open automatically to http://localhost:13005.

Alternatively, double-click start-launcher.bat to run with console output visible.

Right-click the system tray icon to open the dashboard, access documentation, view logs, or shut down the simulator.

All application data is stored in %USERPROFILE%\.factory-simulator\ (logs, data, and config subdirectories).

---

macOS

1. Download the DFS archive for macOS from the portal.
2. Extract the archive:

   tar -xzf factory-launcher_*_darwin_arm64.tar.gz

After extraction, you will see the following structure:

factory-launcher_*_darwin_arm64/
├── README.txt
├── factory-launcher

3. Run the application from Terminal:

   ./factory-launcher

The application will appear in the menu bar and a browser window will open automatically to http://localhost:13005. Click the menu bar icon to open the dashboard, access documentation, view logs, or shut down the simulator.

macOS Security Settings

On first run, macOS may block the application. Go to System Settings > Privacy & Security and allow factory-launcher to run. If blocked by Gatekeeper, right-click the binary, select Open, then click Open in the dialog. For a visual walkthrough, see the video in the macOS Installation section of the Getting Started guide.

All application data is stored in ~/.factory-simulator/ (logs, data, and config subdirectories).

---

Linux

1. Download the DFS archive for Linux from the portal.
2. Extract the archive:

   tar -xzf factory-launcher_*_linux_amd64.tar.gz

After extraction, you will see the following structure:

factory-launcher_*_linux_amd64/
├── README.txt
├── factory-launcher

3. Make the binary executable (if needed) and run:

   chmod +x factory-launcher
   ./factory-launcher

A browser window will open automatically to http://localhost:13005. In desktop environments with D-Bus support, a system tray icon will appear. In headless or server environments, the application runs without a tray icon. Use Ctrl+C to shut down gracefully.

All application data is stored in ~/.factory-simulator/ (logs, data, and config subdirectories).

To run DFS as a systemd service:

[Unit]
Description=Factory Simulator Launcher
After=network.target

[Service]
Type=simple
User=your-user
ExecStart=/path/to/factory-launcher
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable factory-simulator
sudo systemctl start factory-simulator

Overview

The Digital Factory Simulator (DFS) is a software application written in Go that simulates a realistic brake caliper body manufacturing line. It runs as a single binary and exposes industrial protocols (OPC UA, Modbus TCP, MQTT), REST APIs, a web dashboard, and an embedded PostgreSQL database, allowing external systems to interact with the simulated factory as if it were a real production environment.

Product

The simulated factory manufactures Front Brake Caliper Housing - Left (product code BC-2024-A), an aluminum automotive component made from Aluminum A356-T6 with a weight of 2.4 kg. The product is manufactured for an OEM Tier 1 customer.

Production Line and Architecture

The production line (ID: LINE-BC-01) consists of four stations arranged in series. Raw aluminum castings enter the line, pass through each station sequentially, and exit as finished brake caliper housings.

Digital Factory Simulator - Production Line

Station	ID	Type	Protocol
CNC Rough Machining	OP10-CNC	Machining	Modbus TCP
CNC Finish Machining	OP20-CNC	Machining	OPC UA
Parts Washer	OP30-WASH	Wash	Modbus TCP
Leak Test	OP40-TEST	Test	OPC UA

• OP10 (Rough Machining): Performs initial CNC machining on the raw casting using a face mill and rough bore bar.
• OP20 (Finish Machining): Performs precision CNC machining using a finish bore bar and tap, bringing the part to final dimensional tolerances.
• OP30 (Parts Washer): Cleans machining residue from the part using an industrial wash cycle with temperature, pressure, and detergent concentration control.
• OP40 (Leak Test): Performs a pressure-based seal integrity test. Parts that pass are classified as finished goods.

Buffers between stations have a capacity of 10 parts each. The raw material buffer (before OP10) and finished goods buffer (after OP40) each hold up to 1000 parts. Each part entering the line is automatically assigned a serial number (e.g., SN-000001) and is tracked through all stations for full traceability.

Stations can be in one of the following states during operation:

State	Description
IDLE	Ready and waiting for a part
RUNNING	Actively processing a part (loading, machining/washing/testing, unloading)
FAULTED	Stopped due to a fault, resumes automatically after repair time
BLOCKED	Processing complete but the downstream buffer is full
STARVED	Ready to process but the upstream buffer is empty
CHANGEOVER	Tool change in progress (tool life limit reached)

Work Orders and Operation Modes

Production is driven by work orders. Each work order specifies a target quantity of good parts to produce. Only one work order can be active at a time. When the number of good parts reaches the target, the work order is automatically completed.

DFS provides two operation modes that control how logistics and work order management are handled:

Manual mode (default) requires the operator to perform all logistics operations through the web dashboard or REST APIs:

• Loading raw materials into the raw material buffer
• Shipping finished goods from the finished goods buffer
• Creating and starting work orders

Automatic mode enables a rule-based automation engine that handles these operations based on configurable thresholds:

Rule	Default Behavior
Raw material replenishment	When the raw material buffer drops below 100 parts, 100 parts are automatically added
Finished goods shipment	When the finished goods buffer exceeds 50 parts, 25 parts are automatically shipped
Work order start	When the current work order completes, the next planned work order starts automatically
Work order creation	When fewer than 3 planned work orders remain, a new work order for 10 parts is created

The operation mode only affects logistics and work order management. Station behavior (machining, fault handling, quality checks) remains the same in both modes. The mode can be switched at any time without restarting the simulation.

Simulation Profiles

Simulation profiles control the overall behavior of the factory, including fault frequency, repair time, cycle speed, defect rates, and energy efficiency. DFS includes seven predefined profiles. The active profile can be changed at runtime through the web dashboard or REST APIs, and the change takes effect immediately without restarting.

Profile	Expected OEE	Description
world_class	85%+	Minimal downtime (MTBF 20 min, MTTR 1 min), high efficiency (98%), and low defect rate (0.5%). Represents a well-optimized lean manufacturing environment.
typical	65-75%	Moderate fault frequency (MTBF 10 min, MTTR 3 min), 90% cycle efficiency, and 2% defect rate. Represents an average real-world factory with room for improvement.
struggling	45-55%	Frequent faults (MTBF 5 min), slow cycles (75% efficiency), and high defect rate (5%). Suitable for testing monitoring and alarm systems.
demo	Variable	Ultra-fast mode with 5x cycle speed, 1 min MTBF, and 6 sec MTTR. Produces data rapidly, making it ideal for demonstrations and quick testing.
availability_problem	Low availability	Very frequent faults (MTBF 3 min) with long repair times (MTTR 5 min), but good quality (1% defect rate) when running. Focus area: maintenance improvement.
quality_problem	Low quality	High uptime (MTBF 15 min) but 12% defect rate. Focus area: quality control and SPC systems.
performance_problem	Low performance	Reliable machines but 65% cycle efficiency (35% slower than ideal). Focus area: cycle time optimization.

Each profile affects OEE through a different component. The availability_problem, quality_problem, and performance_problem profiles are designed to isolate specific OEE loss categories for targeted analysis.

Exposed Interfaces

DFS exposes data through multiple industrial and IT protocols. The application follows a single-source-of-truth design where a central state object holds all production data. The simulation engine writes to this state while protocol servers read from it. State changes are propagated to subscribers through an event-driven mechanism.

Digital Factory Simulator - Exposed Interfaces

All ports are configurable through the YAML configuration file or CLI parameters. The values shown in DFS documentation and web dashboard reflect defaults and may differ in your deployment.

OPC UA

Two OPC UA servers are available, one for OP20 (CNC Finish Machining) and one for OP40 (Leak Test). Data points include station state, process step, part counters, sensor values (spindle speed, load, feed rate, coolant, vibration, temperature), test parameters (pressure, leak rate), energy readings, fault status, time tracking, and tool information. All OPC UA nodes are read-only.

Modbus TCP

Two Modbus TCP servers are available, one for OP10 (CNC Rough Machining) and one for OP30 (Parts Washer). Register data covers station state, part counters, sensor readings (scaled integers), energy values, tool life, line counters, time tracking, and work order progress.

MQTT

An embedded MQTT broker provides event-driven and periodic topics. Event-driven topics fire on state changes, cycle start/complete, faults, part completion, work order events, and quality defects. Periodic topics publish production status, equipment status, buffer levels, and work order status every 5 seconds.

REST APIs

Two REST APIs are available:

MES API: Provides endpoints for master data (factory, products, equipment, downtime reasons, defect codes), production management (work orders, production records, counters), quality records, downtime events, real-time equipment and buffer status, energy readings, and simulation profile control.

ERP API: Provides endpoints for inventory management (raw materials, WIP, finished goods, receiving, shipping), stock movements, automation control (mode switching, rule configuration), and simulation profile management.

PostgreSQL

An embedded PostgreSQL instance contains static reference tables: departments, employees, shifts, skills, equipment, maintenance schedules/records, suppliers, materials, customers, products, BOM items, and quality specifications. PostgreSQL data is not synchronized with live simulation data and provides reference data only.

Import and Export

The DFS web application includes an API Docs page with a MaestroHub Quick Setup section. From there, you can download a pre-configured .mhub.json file that contains all OPC UA, Modbus, and REST API connections along with their functions. This file can then be imported into MaestroHub through the UI, which automatically creates all connectors and their functions with no manual setup needed.

MaestroHub Quick Setup on the DFS API Docs page

To import the downloaded file into MaestroHub, navigate to System Management > Export/Import and use the Import Configuration section. Click Start Import, select the .mhub.json file, and MaestroHub will validate and resolve any conflicts automatically.

MaestroHub Import Configuration page

Once the import is complete, all DFS connections are listed in the MaestroHub Connections page, ready to use.

DFS connections after import in MaestroHub

Use Cases

The following use cases can be implemented using DFS as the data source and MaestroHub as the integration and orchestration platform.

OEE Monitoring

OEE (Overall Equipment Effectiveness) measures manufacturing productivity through three components:

• Availability: Derived from station run time, down time, and idle time values exposed through OPC UA, Modbus, and MQTT.
• Performance: Calculated by comparing actual parts produced against ideal cycle time targets.
• Quality: Ratio of good parts to total parts produced, using the quality outcome data from each station.

DFS simulation profiles are designed to produce different OEE characteristics. Switching between profiles such as world_class (85%+ OEE), typical (65-75% OEE), and struggling (45-55% OEE) allows you to observe how each OEE component responds to different factory conditions. The availability_problem, quality_problem, and performance_problem profiles isolate individual OEE loss categories for targeted analysis.

Energy Monitoring

DFS generates per-station energy consumption data including instantaneous power (kW), cumulative energy (kWh), voltage, current, and power factor. These values change based on the station's operational state (idle, loading, processing, unloading, faulted) and are available through all exposed protocols.

Using MaestroHub, you can collect energy readings from each station, calculate total line consumption, track energy cost based on peak/off-peak rates, and build dashboards that correlate energy usage with production output such as kWh per part.

Predictive Maintenance

DFS simulates tool wear progression and its effects on sensor readings. As tools approach their life limits, vibration and spindle load values increase, and defect rates rise. Faults are generated based on MTBF with an exponential distribution, meaning fault probability increases over time since the last failure.

Using MaestroHub, you can collect tool life counters, vibration trends, and spindle load data over time to build predictive maintenance workflows. By monitoring these signals, you can detect patterns that precede tool failures or quality degradation and trigger alerts before unplanned downtime occurs.

Root Cause Analysis

Every defective part produced by DFS includes a root cause classification. Each station type has its own root cause distribution. For example, machining stations attribute defects to causes such as tool wear, vibration, thermal drift, process drift, material defects, setup errors, and operator errors, each with a defined probability.

Using MaestroHub, you can aggregate defect events from MQTT or REST APIs, correlate them with station sensor data and tool life status at the time of the defect, and build Pareto charts or dashboards that highlight the most frequent root causes per station.